知財求人 - 知財ポータルサイト「IP Force」
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】特許公報(B2)
(11)【特許番号】
(24)【登録日】2025-02-25
(45)【発行日】2025-03-05
(54)【発明の名称】少なくとも１台の機械の監視
(51)【国際特許分類】
G06F 11/07 20060101AFI20250226BHJP
G06F 11/30 20060101ALI20250226BHJP
G05B 9/02 20060101ALI20250226BHJP
【ＦＩ】
G06F11/07 196
G06F11/07 151
G06F11/07 140Q
G06F11/30 140D
G05B9/02 Z
【請求項の数】
15
【外国語出願】
(21)【出願番号】P 2023200555
(22)【出願日】2023-11-28
(65)【公開番号】P2024091467
(43)【公開日】2024-07-04
【審査請求日】2024-01-15
(31)【優先権主張番号】22216057
(32)【優先日】2022-12-22
(33)【優先権主張国・地域又は機関】EP
(73)【特許権者】
【識別番号】591005615
【氏名又は名称】ジック アーゲー
(74)【代理人】
【識別番号】110001069
【氏名又は名称】弁理士法人京都国際特許事務所
(72)【発明者】
【氏名】パスカル リーギベル
(72)【発明者】
【氏名】トーマス ノイマン
(72)【発明者】
【氏名】ハイコ シュタインケンパー
【審査官】円子 英紀
(56)【参考文献】
【文献】特開２０１４－０１６９３０（ＪＰ，Ａ）
【文献】特開２０１０－０４３５３６（ＪＰ，Ａ）
【文献】特開２０１０－１２７１６２（ＪＰ，Ａ）
【文献】特開２０１５－１１８６６２（ＪＰ，Ａ）
【文献】米国特許出願公開第２０２２／０２４４９９５（ＵＳ，Ａ１）
(58)【調査した分野】(Int.Cl.，ＤＢ名)
Ｇ０６Ｆ １１／０７
Ｇ０６Ｆ １１／３０
Ｇ０５Ｂ ９／０２
(57)【特許請求の範囲】
【請求項1】
少なくとも１台の機械（１２）を監視するための安全装置（１０）であって、前記機械（１２）についてのセンサデータを生成するための少なくとも１つのセンサ（１４）と、少なくとも間接的に前記センサ（１４）及び前記機械（１２）と接続された、前記センサデータ用の処理ユニット（１６、２２）とを備え、前記処理ユニットが少なくとも１つの計算ノード（２６）を有する実行環境（２２）として構成されているとともに多数の論理ユニット（２８）を前記少なくとも１つの計算ノード（２６）上で作動させるように構成されており、少なくとも１つの論理ユニット（２８）が前記センサデータを安全確保に向けて評価するための安全機能ユニット（３２）として構成され、少なくとも１つの論理ユニット（２８）が前記安全機能ユニット（３２）を監視する診断ユニット（３４）として構成されている安全装置（１０）において、前記少なくとも１つの安全機能ユニット（３２）が前記診断ユニット（３４）に状態メッセージ（５０）と実行メッセージ（５２）を伝送するように構成され、前記診断ユニット（３４）が、状態監視（４６）において前記状態メッセージ（５０）からの状態に基づき、且つ、実行監視（４８）において前記実行メッセージ（５２）からの実行経過に基づき、前記安全装置（１０）における安全に関わる機能エラーを認識するように構成されていること
を特徴とする安全装置（１０）。
【請求項2】
前記診断ユニット（３４）が、ある機能エラーが安全に関わるものかどうか状況に応じて確認するように構成されている、請求項１に記載の安全装置（１０）。
【請求項3】
安全に関わる機能エラーが生じた場合に前記診断ユニット（３４）の指示に応じて、又は、評価したセンサデータに基づいて危険な状況が認識された場合に安全機能ユニット（３２）の指示に応じて、前記機械（１２）を安全な状態に移行させるように構成された遮断ユニット（５４）を備えている、請求項１に記載の安全装置（１０）。
【請求項4】
前記実行環境（２２）が、前記少なくとも１つの安全機能ユニット（３２）が状態メッセージ（５０）と実行メッセージ（５２）を前記診断ユニットへ伝送するための通路となるメッセージシステムを備えており、特に該メッセージシステムが状態メッセージ（５０）と実行メッセージ（５２）を並列に伝送するために２つのメッセージチャネルで構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項5】
前記少なくとも１つの安全機能ユニット（３２）が、規則的に状態メッセージ（５０）を伝送するように及び／又は事象ベースで該ユニットの安全機能の実行のたびに実行メッセージ（５２）を伝送するように構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項6】
前記状態メッセージ（５０）及び／又は前記実行メッセージ（５２）が、発信元の安全機能ユニット（３２）に関する発信者情報、タイムスタンプ、シーケンス及び／又はチェックサムを提示している、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項7】
前記少なくとも１つの安全機能ユニット（３２）が、自身のデータ、プログラム、処理結果及び／又はシステム時間との一致を検査する自己診断を行うように構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項8】
前記診断ユニット（３４）が、前記状態監視（４６）のために、前記少なくとも１つの安全機能ユニット（３２）の状態に対する所定の状態予想を呼び出し、特にそれまでの前記論理ユニット（２８）の状態、作業経過及び／又は作業結果に基づいて該状態予想を修正し、該状態予想を各状態メッセージ（５０）の状態から導出された現在の全体状態と比較するように構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項9】
前記状態メッセージ（５０）が、該状態メッセージ（５０）を伝送している安全機能ユニット（３２）が存在しているか、初期化できたか、該ユニットに必要な全リソースが利用可能であるか、及び／又は、該ユニットが機能する準備ができているかについての情報を与えるものである、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項10】
前記診断ユニット（３４）が、前記実行監視（４８）のために、前記少なくとも１つの安全機能ユニット（３２）の実行経過に対する所定の実行予想（５８）を呼び出し、特にそれまでの前記論理ユニット（２８）の状態、作業経過及び／又は作業結果に基づいて該実行予想（５８）を修正し、該実行予想（５８）を各実行メッセージ（５２）から導出された実行経過と比較するように構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項11】
前記診断ユニット（３４）が、前記実行予想（５８）と各実行メッセージ（５２）から導出された実行経過との比較を評価する際に、実行順序、実行の不生起、余分な実行、実行の時間ラスタからの逸脱、短すぎる実行継続時間、又は、長すぎる実行継続時間という諸基準の少なくとも１つを考慮するように構成されている、請求項１０に記載の安全装置（１０）。
【請求項12】
前記実行メッセージ（５２）が、前記少なくとも１つの安全機能ユニット（３２）の安全機能のその都度の最後の実行に関する実行情報、特に開始時点及び／又は実行継続時間を含む実行情報を提示している、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項13】
前記実行環境（２２）が、論理的に前記少なくとも１つの安全機能ユニット（３２）と前記診断ユニット（３４）との間に配置された集計部（５６）を備え、該集計部が、前記実行メッセージ（５２）を受け取り、該メッセージから前記少なくとも１つの安全機能ユニット（３２）の安全機能の実行の順序及び／又は継続時間を含む実行経過を、特にリアルタイムで生成するように構成されている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項14】
前記少なくとも１つのセンサ（１４）が、光電センサ、特に光遮断機、光検知器、光格子、レーザスキャナ、ＦＭＣＷ－ＬＩＤＡＲ若しくはカメラとして、超音波センサ、慣性センサ、容量センサ、磁気センサ、誘導センサ、ＵＷＢセンサとして、又は、プロセス変数センサ、特に温度センサ、流量センサ、レベルセンサ若しくは圧力センサとして構成されており、前記安全装置（１０）が特に多数の同種又は異種のセンサ（１４）を備えている、請求項１～３のいずれかに記載の安全装置（１０）。
【請求項15】
少なくとも１台の機械（１２）を監視するためのコンピュータ実装式の方法であって、少なくとも１つのセンサが前記機械（１２）についてのセンサデータを生成し、少なくとも間接的に前記センサ（１４）及び前記機械（１２）と接続された、前記センサデータ用の処理ユニット（１６、２２）が実行環境（２２）として多数の論理ユニット（２８）を少なくとも１つの計算ノード（２６）上で作動させ、少なくとも１つの論理ユニット（２８）が安全機能ユニット（３２）として前記センサデータを安全確保に向けて評価し、少なくとも１つの論理ユニット（２８）が診断ユニット（３４）として前記少なくとも１つの安全機能ユニット（３２）を監視する、という方法において、前記少なくとも１つの安全機能ユニット（３２）が状態メッセージ（５０）と実行メッセージ（５２）を前記診断ユニット（３４）に伝送し、前記診断ユニット（３４）が、状態監視（４６）において前記状態メッセージ（５０）からの状態に基づき、且つ、実行監視（４８）において前記実行メッセージ（５２）からの実行経過に基づき、安全に関わる機能エラーを認識すること
を特徴とする方法。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、請求項１及び１５のプレアンブルにそれぞれ記載の、少なくとも１台の機械の監視するための安全装置及び方法に関する。
【背景技術】
【0002】
安全技術は人の防護や機械での事故の回避と関係がある。このような種類の安全装置は、機械若しくはその周囲を監視して、危険が迫っている場合に機械を早めに安全な状態に切り替えるために、１又は複数のセンサを利用する。ある典型的な従来の安全技術的解決策では、少なくとも１個のセンサで（例えばレーザスキャナを用いて）、機械の運転中に操作者が侵入してはならない防護域を監視する。該センサは、操作者の脚等の防護域への許可なき侵入を検知すると機械の緊急停止を発動する。代わりの防護構想として、いわゆる「スピード分離監視（Speed and Separation Monitoring）」のように、周囲で検出された物体の距離と速度を評価し、危険がある場合には反応するというものがある。
【0003】
安全技術では格別の信頼性が要求されるため、例えば機械の安全に関する規格ＥＮ１３８４９や非接触型防護装置（beruehrungslos wirkende Schutzeinrichtungen: BWS）に関する機器規格ＥＮ６１４９６といった高い安全要求を満たさなければならない。そのためのいくつかの典型的な対策として、冗長性のある多様な電子機器による確実な電子的評価や様々な機能の監視（例えば前面パネルを含む光学的部品の汚れの監視等）がある。もう少し一般的には、センサから評価部を経て安全技術的な反応を開始するまでの信号の連鎖に沿って起こり得る安全上極めて重要なエラーを回避又は制御するために十分明確に規定されたエラー抑制対策を紹介することができる。
【0004】
安全技術ではハードウェア及びソフトウェアに対する要求が高いことから、従来は何よりもまず、複数チャネルとテスト手段による冗長性及び機能監視を想定した特別に開発されたハードウェアを用いたモノリシックなアーキテクチャが用いられる。それに対応して、ＩＥＣ ＴＳ ６２９９８やＩＥＣ－６１５０８－３等に従った正しいアルゴリズムの証明が行われ、ソフトウェアの開発工程は継続的な厳密なテストと検査を受ける。これに関する例は、特許文献１等から最初に知られ、その根本的特徴において今日まで広範に用いられている安全用レーザスキャナである。該スキャナでは、距離測定のための光伝播時間測定と設定された防護域における物体検出とを含む評価機能全体が統合されている。その結果、評価済みの二値的な防護信号がレーザスキャナの２重チャネルの出力（OSSD, Output Signal Switching Device）に現れ、これが防護域への侵入があった場合に機械を停止させる。この構想は有効であることが実証されているが、柔軟性に欠けたままである。なぜなら、変更は事実上、レーザスキャナの後継モデルの新規開発によってしかできないからである。
【0005】
いくつかの従来の安全アプリケーションにおいては、評価の少なくとも一部がセンサから外部のプログラム可能な制御装置（SPS：Speicherprogrammierbare Steuerung）に移される。しかしそれにはエラーの回避及び暴露のために自ら多重チャネル構造等を備える特別な安全制御装置が必要である。故にそれらはコストが高く、比較的低い記憶容量及び計算能力しか提供せず、それは例えば３次元画像処理を用いると完全に過負荷となる。
【0006】
標準の制御装置の使用は，必要不可欠な機能監視装置への埋め込みの下では確かに基本的に考え得るが、これは今日、産業的な環境においてはほとんど利用されない。なぜならそれはコストの高いアーキテクチャと専門知識を必要とするからである。それから標準の制御装置又はＳＰＳは、特定の言語を用いて、部分的に非常に限定的な言語空間でプログラミングすることしかできない。比較的単純な関数ブロックでも既に多大な開発コストとランタイムリソースを必要とするため、それを標準の制御装置内に実装することは、やや複雑なアプリケーションの場合はほとんど実現不可能であり、冗長性のような安全対策の下ではなおさらである。
【0007】
特許文献２は安全システムにおいて安全制御装置を標準の制御装置と組み合わせている。よりコストのかかる計算は依然として標準の制御装置に任され、その結果の正当性が安全制御装置により確認される。しかし、安全制御装置はそのために安全なセンサの現存の安全なデータを用い、このことが可能な応用のシナリオを制限する上、適切な安全なデータを取得し、それを用いて適切に正当性を確認するためにやはり専門知識を必要とする。加えて、ハードウェア構成は相変わらずほぼ事前に決まっており、そのアプリケーションは特別にそれに合わせて固定的に実装される。
【0008】
多くの場合、安全の監視を自動化の任務と組み合わせることは望ましいであろう。そうすれば事故が回避されるだけでなく、機械の本来の任務も同様に自動的に支援される。しかしこれまではそのために大抵全く異なるシステムとセンサが用いられている。これはとりわけ、安全センサは自動化の任務のためにはあまりに高価であり、逆に安全センサの複雑さが他の機能によって過剰になるべきではないからである。特許文献３は３次元カメラに安全領域と自動化領域を別個に定義できるようにしている。しかしこれは第一歩に過ぎない。なぜなら、確かにとにかく同じセンサが安全と自動化という２つの世界のために用いられてはいるが、これら２つの課題が空間的に及び実装面においてやはり明確に分かれているからである。ＩＥＣ ６２９９８は安全データと自動化データの共存を可能にしているが、それは規格として決して具体的な実装を提案してはいない。
【0009】
安全技術以外ではずっと前から非常に多くのより柔軟なアーキテクチャがある。モノリシックなアプローチはそこではずっと前からより現代的な構想に何歩も遅れを取っている。固定的なハードウェアを使用し、その上でオペレーティングシステムが個々のアプリケーションを調整するという、かつての伝統的な配備（Deployment）は、確かにスタンドアローン型の機器においてはなおも正当性を保持しているが、ネットワーク化された世界においてはずっと前からもはや十分ではない。更なる発展における基本的な考え方は、具体的なハードウェアからますます抽象化する追加の層を入れることであった。
【0010】
第一歩はいわゆる仮想マシンであり、そこでは追加の層がハイパーバイザー（Hypervisor）又は仮想マシンモニタ（Virtual Machine Monitor）と呼ばれる。このようなアプローチは他方で安全技術においても恐る恐るではあるが追求されている。例えば、特許文献４では安全センサにおいて、ユーザに安全センサ上で独自のプログラムモジュールを動かすことを可能にするために、保護された環境を提供している。しかしその際、このようなプログラムモジュールは安全機能から注意深く分離されており、該機能には何の寄与もしない。
【0011】
ある更に進んだ抽象化はいわゆるコンテナを基礎としている（Containervirtualisierung, Containering）。コンテナとはいわばソフトウェアアプリケーション用の小さな仮想カプセルであり、これがメモリ領域やライブラリ等を含むアプリケーション実行用の完全な環境を提供する。付属する抽象化層又はランタイム環境はコンテナランタイム（container runtime）と呼ばれる。これを用いて、ほぼ任意のハードウェアに対し、後にその上で動かすソフトウェアアプリケーションをハードウェアから独立して開発することができる。コンテナはしばしばDockerを用いて実装される。
【0012】
現代のＩｏＴアーキテクチャ（Internet of Things、Industrial Internet of Things）では、異なるソフトウェアアプリケーションを有する多数のコンテナが結び付けられる。これらのコンテナは適切に調整されなければならないが、これはこの関連でオーケストレーションと呼ばれ、そのためにいわゆるオーケストレーションレイヤが更なる抽象化として追加される。コンテナのオーケストレーションについてはKubernetes（クバネティス）が次第に定着しつつあるが、他にも、Dockerの拡張であるDocker Swarmや、rkt又はLXCといった代替物が知られている。
【0013】
このような現代的な抽象化型のアーキテクチャを安全技術で用いることは、安全規格のハードルが高いこと、そして機能的な安全の応用分野におけるアプローチがそれに応じて保守的であることから、これまで失敗している。一般に産業的な環境においてはコンテナ技術が十分に追求されており、例えば自動車産業にはKubernetesアーキテクチャを用いる計画があり、また空軍もそのようなアプローチを追求している。しかしこれらはいずれも機能的な安全には関係せず、従って先に挙げた問題を解決するものではない。
【0014】
高い可用性は普通のＩｏＴの世界においても確かに望ましいものではあるが、このような形態の故障耐性は、既にずっと前から、安全規格が要求するものとはもう比較にならないものとなっている。故に安全技術者にとって、規格に準拠した安全用のエッジ又はクラウドアプリケーションはこれまで考えられなかった。再現可能な条件を作り出し、その条件下で想定し得る機能エラーの全ての可能性に備えることは、広く知られた考え方に反する。大幅な抽象化又は仮想化は、これまで安全要求と相容れないと思われてきた余計な不確実性を生み出す。
【0015】
特許文献５は、機械を監視するための安全装置及び保安方法であって、先に挙げたコンテナとオーケストレーションの技術を用いて安全機能を基礎のハードウェアから抽象化できるものを紹介している。論理ユニットが必要に応じて生成され、削除され、又は他のハードウェアへ割り当てられる。これにより冗長度を変更したり論理ユニットの相互監視を柔軟に行ったりできる。テスト及び監視のため、診断ユニットとして構成された特別な論理ユニットが提案されている。しかし特許文献５は、診断ユニットの構想を用いて具体的にどのようにすれば、システム全体において生じる安全に関わるエラーを実際にうまく暴露できるかを説明していない。
【先行技術文献】
【特許文献】
【0016】
【文献】DE 43 40 756 A1
【文献】EP 3 709 106 A1
【文献】EP 2 053 538 B1
【文献】EP 3 179 278 B1
【文献】EP 4 040 034 A1
【発明の概要】
【発明が解決しようとする課題】
【0017】
故に、本発明の課題は、ちょうど今説明した柔軟性のある安全構想を実践的な実装のためにさらに改良することである。
【課題を解決するための手段】
【0018】
この課題は請求項１及び１５にそれぞれ記載の、少なくとも１台の機械の監視するための安全装置及び方法により解決される。監視される又は防護すべき機械はまず広く理解すべきであって、例えば加工機械、組み立てライン、仕分け設備、プロセス設備、ロボット、又は、車両の数多くの変種（例えばレール拘束型や非拘束型、運転式や自走式）がある。少なくとも１つのセンサが、機械についてのセンサデータ、即ち、機械自身に関するデータ、機械が相互作用する相手のデータ、又は機械の周囲に関するデータを供給する。センサデータの少なくとも一部は安全に関係しているが、安全とは無関係の自動化又は快適機能のための追加的なセンサデータも考えられる。センサは安全なセンサであってもよいが必須ではなく、安全は後段において初めて保証することができる。
【0019】
処理ユニットが実行環境として機能する。従って処理ユニットは構造的な要素であり、実行環境はその機能である。処理ユニットは少なくとも間接的にセンサ及び機械と接続されている。それ故、該ユニットは、場合によっては間に接続された他のユニットを通じて間接的に、センサデータにアクセスして該データを処理するとともに、機械と通信して、好ましくは該機械の機械制御装置を通じて該機械に作用することができる。処理ユニット又は実行環境は集合概念として、センサデータに基づいて安全確保に向けた機械の反応の必要条件と好ましくはその種類を決定するために用いられるハードウェアとソフトウェアを指す。
【0020】
処理ユニットは少なくとも１つの計算ノードを含んでいる。これはデジタル式計算装置若しくはハードウェアノード又はそれらの一部であって、ソフトウェア機能ブロックを実行するための計算能力及び記憶容量を提供する。もっとも全ての計算ノードが別個のハードウェアモジュールである必要はなく、例えばマルチプロセッサを用いて同一の機器上に複数の計算ノードを実現してもよいし、逆に１つの計算ノードが様々なハードウェアリソースを束ねてもよい。
【0021】
単一の計算ノードの上で又は複数の計算ノードのうち１つの上で、安全装置の運転中に複数の論理ユニットが作動する。従って論理ユニットとは一般にソフトウェア機能ブロックを意味する。本発明では少なくとも１つの論理ユニットが、安全確保に向けてセンサデータを評価する安全機能ユニットとして構成されている。安全確保に向けた評価の目的は、危険が迫っているか乃至は安全に関わる事象が認識されたかをセンサデータに基づいて判定することによる、人の防護若しくは事故の回避である。例えば機械に近すぎる場所や防護域内で人が検出された場合がそれに当たる。安全確保に向けた評価には１又は複数の論理ユニットが関与することができる。安全に関わる事象があった場合、好ましくは安全信号を機械へ出力することで、該機械において安全確保に向けた反応を発動させ、それにより、危険性がなくなる又は少なくとも容認できる水準に下がるような安全な状態に機械を移行させる。更に、少なくとも１つ論理ユニットが診断ユニットとして構成されている。これにより他の論理ユニットの機能、特に前記少なくとも１つの安全機能ユニットの機能にエラーがないか監視される。
【0022】
本発明の出発点となる基本思想は、診断ユニットを用いて論理ユニットの状態監視及び実行監視を行うことにある。そのために前記少なくとも１つの安全機能ユニットは状態メッセージと実行メッセージを診断ユニットへ送り、それらの情報が該診断ユニットにおいて評価される。前記少なくとも１つの安全機能ユニットの状態又はステータスは、該少なくとも１つの安全機能ユニットの動作準備完了状態及び同ユニットにおいて考えられる制約又はエラーについての情報を与える。実行メッセージは、安全機能の実行、又は前記少なくとも１つの安全機能ユニットが行うサービスの実行に関係しており、それらから、実行されている安全機能若しくはサービスの実行経過を知ることができる。これらを合わせることで、安全装置における安全に関わる機能エラーを認識することができるシステム診断が可能になる。その際、診断ユニットは、安全機能ユニットがどのように又はどのようなアルゴリズムで作動しているかについても、該ユニットがどの評価結果を出力するかについても特別な知識を必要としないが、この２つを補足的に用いることは可能であろう。エラーの場合、安全装置の安全な機能は保証することができず、とりわけ、安全機能モジュールにより危険が認識された場合と同じように機械が安全確保に向けて反応する結果となる可能性がある。システム診断には診断ユニットとして構成された論理モジュールが１つあれば十分であるが、状態監視と実行監視をそれぞれ独自の診断ユニットに実装すること、又はそうではなくその機能を複数の論理モジュールに分散させることも考えられよう。
【0023】
本発明には、とりわけ産業的な環境（Industrial Internet of Things: IIoT）において安全に関わるアプリケーションを調整又はオーケストレーションすることができる柔軟性の高い保安アーキテクチャが可能になるという利点がある。その際、保安と自動化を緊密に噛み合わせることができる。標準のハードウェアがあれば十分であり、高価な専用の安全なハードウェアは不要である。本発明は、全体としてメモリリソース及び計算リソースが十分に利用可能である限り、具体的なハードウェア風景から大幅に独立している。その上、論理ユニットを多様なハードウェア上で実装し、計算ノード間で移動させることができるため、頑強性が著しく向上している。考えられる重要な応用事例として、前記ハードウェア風景又は該ハードウェア風景の一部をクラウドとすることができる。つまり本発明はクラウドと安全技術というかつて互いに疎遠だった世界を結び付ける。クラウドネイティブな諸構想の枠内には大規模に作られたアプリケーションも支援する既存のオープンソースのフレームワークとツールがあるが、これまでは機能的な安全を提供していない。
【0024】
本発明に係るアプローチは安全技術における従来のやり方と根本的に違っている。これまでは、固定的で、大抵は正にこの安全機能のためにわざわざ開発されたハードウェア構造が予め与えられ、ソフトウェア機能は正にこのハードウェア構造のために開発され、その構造において固定的に実装され、テストされている。ソフトウェアの分配（配備）の事後的な変更は問題外であり、それが基礎となるハードウェアの変更によるとなればなおさらである。このような修正には従来なら、少なくとも保安の専門家による高コストの改造が必要で、普通なら完全な新規開発となる。産業界において、そして安全技術においてはなおさらであるが、典型的な保守的なアプローチでは、センサ及び制御装置のファームウェア又はソフトウェアのアップデートでさえ、せいぜい長いサイクルでしか行われず、典型的には全く行われないという結果となる。
【0025】
本明細書では「安全（Sicherheit）」又は「安全な（sicher）」という概念が繰り返し用いられる。これはとりわけその都度安全規格の意味において理解すべきものである。それに従って、例えば機械の安全、非接触型防護装置、又は人の防護における事故の回避に関する安全規格が満たされるか、あるいは更に何か別の形で規格により定められた安全水準が守られ、それ故にその都度、エラーが安全規格において又はそれと同じ様に指定された安全水準まで抑えられる。冒頭にそのような安全規格の例をいくつか挙げたが、そこでは安全水準が例えば保護クラス又は性能レベルと呼ばれている。本発明はこれらの安全規格の特定のものに規定されるものではない。それらはその具体的な番号付け及び文言が地域毎にそして時間の経過とともに変化し得るが、安全を創り出すためのそれらの基本原則は変わらない。後ほど、いくつかの実施形態においては安全の概念をコンテキストに関連した又は状況に応じた安全にまで若干拡大する。
【0026】
実行環境の実装はKubernetesにおいて行うことが好ましい。Kubernetesでは実行環境が「コントロールプレーン（Control Plane）」と呼ばれる。マスタが全体の進行を調整する、つまりオーケストレーションを行う（オーケストレーションレイヤ）。計算ノードはKubernetesではノード（Node）といい、これは少なくとも１つの下位ノード又はポッド（Pod）を備え、その内部で各論理ユニットが各々のコンテナ内で作動する。Kubernetesは、ある論理ユニットがまだ作動しているかどうか検査するために用いられるメカニズムを既に知っている。もっともこの検査は安全仕様の要求にとっては決して十分ではなく、繰り返しバイタルサインを受け取って場合によってはコンテナを再起動するということに事実上限定されている。また、いつエラーが注意を引き、再訂正されたかを決して保証しない。
【0027】
実行環境は、論理ユニットを生成する、削除する、いずれかの計算ノードに割り当てる、若しくは計算ノード間で移動させるように構成されていることが好ましい。これは一度限りではなく運転中にも動的に行うことが好ましく、しかもそれは、安全に関わる論理ユニット、すなわち前記少なくとも１つの安全機能ユニット及び／又は診断ユニットにも完全にはっきりと当てはまる。これにより、ハードウェアと評価の間の結びつきが、機能的な安全を維持しつつ流動的になる。それに対して従来は、全ての安全機能が固定的に且つ変更不能に専用のハードウェア上に実装される。変更は、およそ改造又は新規開発なしで考え得る範囲に限るとすれば、基礎となる安全構想と全く相容れないとみなされるであろう。これは一度限りの実装にも既に当てはまり、ランタイム時の動的な変更となればなおさらである。それどころかこれまでは常に、全く多大なコストをかけ、数多くの複雑な個別対策を用いて、安全機能を最初から全運転期間にわたって十分に規定された不変の環境下に置くことに全力が注がれていた。
【0028】
実行環境は、論理ユニットに割り当てられたリソースを変更するように構成されていることが好ましい。これは、より高速な処理を行う場合に論理ユニットを支援するものとすることができるが、他の論理ユニットのためにリソースを解放するものであってもよい。より多くのリソースを用意するための特別な方法として、論理ユニットを別の計算ノードへ移動させることや、論理ユニットの更に別のインスタンス又は複製を生成することが挙げられ、後者については論理ユニットを並列化可能な実行のために構成することが好ましい。
【0029】
実行環境は論理ユニットに関する設定情報又は設定データを記憶して保持していることが好ましい。設定情報に基づき、現存する論理ユニットに関して、どの論理ユニットをどのタイミングにおいてどのリソースを用いて実行すべきか、そして場合によっては論理ユニット同士がどのように互いに関係しているかを帳簿に記録すること又は予め与えることができる。
【0030】
設定情報は署名又はブロックチェーンデータセットにより改変に対して保護されていることが特に好ましい。このような改変には意図的なものも意図的でないものもありうるが、いずれにせよ安全アプリケーションにおいて論理データの設定が気付かれないうちに変わることは決してあるべきではない。
【0031】
実行環境は、各計算ノードと通信してそれらを調整する少なくとも１つのマスタユニットを備えていることが好ましい。マスタユニットは、冗長性のため及び／又は担当の分散のために、複数の下位ユニットを備えていたり、計算ノードのノード管理ユニットによる支援を受けて自身の計算ノード上又は論理ユニットと共通の計算ノード上に実装されていたりしてもよい。
【0032】
前記少なくとも１つの計算ノードは、他の計算ノード及び実行環境との通信のためのノード管理ユニットを備えていることが好ましい。このノード管理ユニットは、付属する計算ノード（特に該計算ノードの論理ユニット）の管理及び調整、並びに他の計算ノード及びマスタユニットとの協力に対して責任を持つ。このユニットはほぼ任意の配分でマスタユニットの任務も引き受けることができる。
【0033】
前記少なくとも１つの計算ノードが少なくとも１つの下位ノードを備え、前記論理ユニットが下位ノードに割り当てられていることが好ましい。これによれば、複数の論理ユニットを１つの下位ノードにまとめるために計算ノード自身が更に一度構造化される。この構想はKubernetesもポッドの形で追求している。
【0034】
前記少なくとも１つの論理ユニットはコンテナとして実装されていることが好ましい。これによれば、論理ユニットはカプセル化又はコンテナ化されており、ほぼ任意のハードウェア上で作動可能となる。普通なら安全機能と固定的なハードウェア上でのその実装との間には緊密な関係があるが、これが破られ、それにより柔軟性とプロセスの安定性が大幅に高まる。実行環境はコンテナをその内部の論理ユニットも含めて互いに調整又はオーケストレーションする。少なくとも２つの抽象化層がある。一つは各々のコンテナ層（コンテナランタイム）、もう一つはその上にある実行環境のオーケストレーション層（オーケストレーションレイヤ）である。
【0035】
実行環境は、少なくとも１つのセンサ上、プログラマブル論理制御装置上、機械制御装置上、ローカルネットワーク内の計算装置上、エッジデバイス上、及び／又は、クラウド内に実装されていることが好ましい。言い換えると、基礎となるハードウェア風景はほぼ任意であり、これが本発明によるアプローチの非常に大きな利点である。実行環境は計算ノードを用いて抽象的に作動し、その下にあるハードウェアは非常に雑多に構成することができる。特に、エッジ又はクラウドのアーキテクチャも安全技術のために利用可能となり、その際、（安全な）センサ又は制御装置の使い慣れた評価用ハードウェアを放棄する必要はない。
【0036】
実行環境は計算ノードを組み入れる及び／又は除外するように構成されていることが好ましい。これによればハードウェア環境が変化してもよく、実行環境はそれに対処して新たな又は適合させた計算ノードを生成することができる。従って、特に（一部の）故障の際の置き換えのため、並びに、追加の計算及び記憶リソースの拡張及び用意のために、新たなハードウェアを接続すること又はハードウェアを交換することができる。論理ユニットは、仮にハードウェア構成が大胆に変更されたとしても、実行環境により抽象化された計算ノード上で作動し続けることができる。
【0037】
少なくとも１つの論理ユニットが、センサデータから、自動化の任務に関連する情報及び／又は機械のための制御命令であって安全とは無関係の情報及び制御命令を生成する自動化ユニットとして構成されていることが好ましい。これによれば、実行環境は、センサデータに基づいて安全とは無関係の追加機能を提供する別の種類の論理ユニットを支援する。このような自動化の任務は人の防護又は事故の回避に関わるものではなく、従ってその点では何ら安全規格を満たさなくてよい。典型的な自動化の任務として、品質及び進行管理、把持、仕分け又は他の作業ステップのための物体認識、分類等がある。実行環境が、自動化ユニットに柔軟なリソースを割り当て、該ユニットがその任務をまだ遂行しているかどうか監視し、例えば場合によっては当該論理ユニットを新たに起動したり、別の計算ノードに移したり、その論理ユニットの複製を呼び出して活性化したりすることは、該自動化ユニットにとっても有益である。もっともその場合に重要なのは、停止を回避し、正常な進行を支援して可用性を維持することであり、これらは機械の運用者にとって非常に重要であるが、安全とは何の関係もない。自動化ユニットを診断ユニットの状態及び実行監視に組み入れることが考えられる。なぜなら、信頼できる自動化機能は、もしかするとこの箇所では過度に高い安全水準を守るものであったとしても、やはり付加価値をもたらし得るからである。
【0038】
診断ユニットは、ある機能エラーが安全に関わるものかどうか状況に応じて確認するように構成されていることが好ましい。現存する安全機能ユニットの状態若しくは実行経過は現在の環境に依存して異なる評価がなされ得る。例えば、ロボットの作業領域に身体の一部が侵入したとしても、そのときにロボットがその侵入箇所を含まない限られた座標領域に確かに留まっていることが同時に保証されているなら、それは例外的で何ら危険ではない。このような状況に応じた境界条件の下では、安全機能ユニットと自動化ユニットがそれらの役割を動的に交換することさえ考えられる。
【0039】
安全装置は、安全に関わる機能エラーが生じた場合に診断ユニットの指示に応じて、又は、評価したセンサデータに基づいて危険な状況が認識された場合に安全機能ユニットの指示に応じて、機械を安全な状態に移行させるように構成された遮断ユニットを備えていることが好ましい。これによれば、遮断ユニット若しくは遮断サービスは、診断ユニット又は安全機能ユニットが機械の防護を要求したとき、好ましくは機械又はその機械制御装置へ適宜の信号を送ることにより、機械が実際に防護されるように世話をする。状況により、安全な状態は、例えば減速、機械の特殊な動作モード（例えば運動の自由度や多様さの制限）、回避又は停止により達成される。遮断ユニットは論理ユニットとして実装して診断に取り込むことができる。好ましくは、遮断ユニットが診断ユニットから全てが正しく機能しているという信号を規則的に受け取り、この信号が途絶えたら、明示的な防護要求があった場合と同様に何らかの防護対策で反応する。
【0040】
実行環境は、前記少なくとも１つの安全機能ユニットが状態メッセージと実行メッセージを診断ユニットへ伝送するための通路となるメッセージシステムを備えていることが好ましい。特に好ましくは、そのメッセージシステムは状態メッセージと実行メッセージを並列に伝送するために２つのメッセージチャネルで構成されている。これによれば、２本メッセージの流れがあることで、状態監視と実行監視を互いに分離して維持することができる。
【0041】
前記少なくとも１つの安全機能ユニットは、規則的に状態メッセージを伝送するように及び／又は事象ベースで該ユニットの安全機能の実行のたびに実行メッセージを伝送するように構成されていることが好ましい。これによれば、最終的に所望の安全水準により設定される細粒度で安全機能ユニットの状態が連続的に監視される。「規則的に」は「周期的に」を意味し得るが、それよりも若干柔軟である。遅くとも所定の時間が経過する毎に状態が再び分かれば十分であるが、この範囲内で２つの状態メッセージ間の時間間隔が揺らいでもよい。実行メッセージはその間に何かが実行されたらその都度新たな情報をもたらすものであるから、実行メッセージのやり取りは事象ベースで行うことができる。安全機能はセンサデータに基づいており、センサ自身はしばしばそのデータを周期的に用意するから、評価事象は周期的に生じ得るものであり、そうすると事象に基づく連続も結局はこの間接的な方法で周期的になる。
【0042】
状態メッセージ及び／又は実行メッセージは、発信元の安全機能ユニットに関する発信者情報、タイムスタンプ、シーケンス及び／又はチェックサムを提示していることが好ましい。これにより、状態と実行を正しい論理ユニットに帰属させ、時間的に配列することができる。シーケンスはメッセージ若しくはその内容を整理する。チェックサム又はそれと比肩しうる手段で、メッセージの内容が正しく伝送されたことを証明できる。
【0043】
前記少なくとも１つの安全機能ユニットは、自身のデータ、プログラム、処理結果及び／又はシステム時間との一致を検査する自己診断を行うように構成されていることが好ましい。それらから該安全機能ユニットは特に自身の状態を確かめ、状態メッセージ内で通知することができる。システム時間からのずれがあると前記メッセージ内のタイムスタンプとの不一致が生じ、それにより場合によっては誤ったシステム診断に繋がることがある。論理ユニット自身は安全に構成されていないから、自己診断だけでは全体として安全を保証するには不十分であるが、自己診断は安全の１つの考え得る構成要素である。
【0044】
診断ユニットは、状態監視のために、前記少なくとも１つの安全機能ユニットの状態に対する所定の状態予想を呼び出し、特にそれまでの論理ユニットの状態、作業経過及び／又は作業結果に基づいて該状態予想を修正し、該状態予想を各状態メッセージの状態から導出された現在の全体状態と比較するように構成されていることが好ましい。これによれば、診断ユニットはエラーのないシステムの状態予想を持っており、この状態予想は、構成されるか、他の所で予め与えられるか、固定的にプログラミングされるか、メモリに用意しておくことができる。状態予想とは、概して規則的に全ての現存する安全機能ユニットから状態メッセージを受け取ること、又は、エラーを示唆しない特定の状態だけが報告されること、であるものとすることができる。状態予想は状況に応じて適合化することができる。受け取った状態メッセージから最新の状態情報を算出し、特にそれらを結合して全体状態にして、これを状態予想と比較する。逸脱があればそれは安全に関わる機能エラーを示唆している。その際、特定の安全機能に関する許容差及び時間的な許容差があってもよい。許容差、最新の状況、又は、事前に想定された他の例外により説明できない逸脱があればそれを安全に関わる機能エラーと評価し、それに続いて機械を安全な状態に移行させることが好ましい。
【0045】
状態メッセージは、該状態メッセージを伝送している安全機能ユニットが存在しているか、初期化できたか、該ユニットに必要なデータベース、コード、ライブラリ、計算リソース、センサとの接続といった全リソースが利用可能であるか、及び／又は、該ユニットが機能する準備ができているかについての情報を与えるものであることが好ましい。これらは状態メッセージの内容又はその内容から導出される諸状態の例である。状態メッセージは簡潔な「ＯＫ」で終わるものでもよく、それどころか単なる到着によって既に１つのメッセージを暗に示すものであってもよい。状態メッセージは発信者、タイムスタンプ及びチェックサムといった先に挙げた一般的な情報も含んでいることが好ましい。
【0046】
診断ユニットは、実行監視のために、前記少なくとも１つの安全機能ユニットの実行経過に対する所定の実行予想を呼び出し、特にそれまでの論理ユニットの状態、作業経過及び／又は作業結果に基づいて該実行予想を修正し、該実行予想を各実行メッセージから導出された実行経過と比較するように構成されていることが好ましい。これによれば、診断ユニットは、前記少なくとも１つの安全機能ユニットの実行の時間的及び論理的な連続に対する実行予想を持つ。これを各実行メッセージから得られる実際の実行の連続と比較する。逸脱があればそれは安全に関わる機能エラーを示唆している。既に状態監視の場合において述べたように、全ての逸脱が必ずしも機能エラーではなく、全ての機能エラーが必ずしも安全上極めて重要で結果的に機械の安全確保に向けた反応に至るものではない。比較の際には許容差があることが好ましく、また何度も述べたように場合によっては状況に応じた評価を行う。
【0047】
診断ユニットは、実行予想と各実行メッセージから導出された実行経過との比較を評価する際に、実行順序、実行の不生起、余分な実行、実行の時間ラスタからの逸脱、短すぎる実行継続時間、又は、長すぎる実行継続時間という諸基準の少なくとも１つを考慮するように構成されていることが好ましい。時間ラスタからの逸脱は実行の不生起又は追加のうち特に重要な特殊事例と理解することができる。これらの基準の多くはまだ必然的に安全に関わる監視の欠落に繋がるものではない。しかしそれらはシステムが設計とは異なる状態にあることの示唆であり、その逸脱が安全構想においては予定されておらず、該構想により確かに抑えられているなら、用心のために機械を安全な状態に移行させるべきであろう。
【0048】
実行メッセージは、安全機能のその都度の最後の実行に関する実行情報、特に開始時点及び／又は実行継続時間を含む実行情報を提示していることが好ましい。実行継続時間は当然ながら間接的に例えば終了時点により伝達することもできる。更に発信者、メッセージのタイムスタンプ及び／又はチェックサム等の一般情報も加えることが好ましい。ある安全機能ユニットが複数の安全機能を実行している場合、安全機能に対応する識別番号を補うことができる。もっとも、好ましくは各安全機能ユニットが１つの安全機能だけを担当するようにし、必要なら更に別の安全機能に対して単に更に別の安全機能ユニットを生成すればよい。実行メッセージは実行結果も含むことができる。それは例えば、試験的に入力した入力データ（センサデータやエミュレートしたセンサデータ等）が予想した実行結果に至るかどうか検査する、狙いを定めたテストの実行結果である。ただし、状態監視及び実行監視の構想は具体的な内容に左右されないことが好ましいが、一方で前記のようなテストを追加的に行うことは排除されず、その場合には分離のために独自のテスト診断ユニットとテストメッセージを用いることもできる。
【0049】
実行環境が、論理的に前記少なくとも１つの安全機能ユニットと前記診断ユニットとの間に配置された集計部を備え、該集計部が、実行メッセージを受け取り、該メッセージから前記少なくとも１つの安全機能ユニットの安全機能の実行の順序及び／又は継続時間を含む実行経過を生成するように構成されていることが好ましい。これによれば、集計部は実行監視の任務の一部を引き受けるが、この任務は代わりに診断ユニット内に実装することもできる。集計後に個々の実行メッセージは既に結合されて実行経過となっている。集計部はリアルタイムで作動することが好ましいが、これはボトルネック等の示唆を付したデータを後の手動による最適化のために用意するだけでなく、安全監視の一部、ひいては事故回避に関わることである。
【0050】
前記少なくとも１つのセンサが、光電センサ、特に光遮断機、光検知器、光格子、レーザスキャナ、ＦＭＣＷ－ＬＩＤＡＲ若しくはカメラとして、超音波センサ、慣性センサ、容量センサ、磁気センサ、誘導センサ、ＵＷＢセンサとして、又は、プロセス変数センサ、特に温度センサ、流量センサ、レベルセンサ若しくは圧力センサとして構成されており、前記安全装置が特に多数の同種又は異種のセンサを備えていることが好ましい。これらは安全アプリケーションにとって重要なセンサデータを提供できるセンサのいくつかの例である。１又は複数のセンサの具体的な選択は各々の安全アプリケーションに依存する。それらセンサは既にそれ自身が安全センサとして構成され得る。しかし本発明ではその代わりに、後段において初めてテスト、追加のセンサ系、又は（多様性を持つ）冗長性若しくは複数チャネル等により安全を達成すること、そしてセンサ原理が同じ又は異なる安全な及び安全ではないセンサを互いに組み合わせることを明確に予定している。例えば、故障したセンサはセンサデータを出力しないが、これは該センサを担当する安全機能ユニットの状態及び実行メッセージに表れ、従って状態及び実行監視中に診断ユニットにより気付かれる。
【0051】
本発明に係る方法は同様のやり方で仕上げていくことが可能であり、それにより同様の利点を示す。そのような有利な特徴は、例えば本願の独立請求項に続く従属請求項に模範的に記載されているが、それらに限られるものではない。
【0052】
以下、本発明について、更なる特徴及び利点をも考慮しつつ、実施形態に基づいて模範的に、添付の図面を参照しながら詳しく説明する。図面の各図に示すものは次の通りである。
【図面の簡単な説明】
【0053】
【図1】安全装置の概観図。
【図2】前記安全装置の実行環境の概略図。
【図3】模範例として２つの計算ノードを有する実行環境の概略図。
【図5】システム診断ユニットに対する状態メッセージと実行メッセージの２重のメッセージの流れの概略図。
【図6】状態メッセージに基づく状態監視の概略図。
【図7】実行メッセージに基づく実行監視の概略図。
【発明を実施するための形態】
【0054】
図１は安全装置１０の概観図を示している。「安全」並びに「安全な」及び「安全ではない」という概念は引き続き、該当する構成要素、伝送路及び評価部が冒頭に挙げた安全規格の基準を満たす又は満たさないということであると理解すべきである。
【0055】
安全装置１０は、監視対象である少なくとも１台の機械１２を含むブロック、監視される機械１２のセンサデータを生成するための少なくとも１つのセンサ１４を含むブロック、そして、センサデータを評価し、場合によっては安全確保に向けて機械１２の何らかの反応を発動させるための制御及び評価機能のための計算及び記憶リソースを有する少なくとも１つのハードウェア部品１６を含むブロックの３つに大きく分けられる。機械１２、センサ１４及びハードウェア部品１６は以下ではときに単数形で、ときに複数形で触れるが、これは、各ユニット１２、１４、１６がそれぞれ１つしかない又は各ユニット１２、１４、１６がそれぞれ複数ある別の実施形態を明確に含むものである。
【0056】
周囲には前記３つのブロックの例がそれぞれ描かれている。とりわけ工業的に用いられる機械１２は、例えば加工機械、組み立てライン、仕分け設備、プロセス設備、ロボット又は車両であり、車両はレール拘束型でも非拘束型でもよく、特に自走式（AGC：Automated Guided Cart、AGV：Automated Guided Vehicle、AMR：Autonomous Mobile Robot）である。
【0057】
模範的なセンサ１４としては、光電センサの代表としてレーザスキャナ、光格子及びステレオカメラがあり、加えて、光検知器、光遮断機、ＦＭＶＷ－ＬＩＤＡＲ、又は、カメラといった他のセンサであってそれぞれ投影法又は光伝播時間法等の２次元又は３次元検出を用いたものが挙げられる。センサ１４の更にいくつかの例として、ＵＷＢセンサ、超音波センサ、慣性センサ、容量、磁気若しくは誘導センサ、又は、温度センサ、流量センサ、レベルセンサ若しくは圧力センサ等のプロセス変数センサがあるが、これらに限られない。これらのセンサ１４は安全装置１０によっては任意の個数設けること、そして互いに任意に組み合わせることができる。
【0058】
考えられるハードウェア部品１６は制御装置（PLC：Programmable Logic Controller、あるいは、SPS：speicherprogrammierbare Steuerung）、ローカルネットワーク内の計算機、特にエッジデバイス、又は、独自の又は第三者により運用されているクラウドであり、全く一般的にはデジタルデータ処理用のリソースを提供するいずれのハードウェアでもよい。
【0059】
図１の内部で３つのブロックが改めて取り上げられている。機械１２は好ましくはその機械制御装置１８を通じて安全装置１０と接続されており、該機械制御装置は、ロボットの場合はロボット制御装置、車両の場合は車両制御装置、プロセス設備の場合はプロセス制御装置であり、他の機械１２についても同様である。内部でブロック２０としてまとめられた各センサ１４はセンサデータを生成するだけでなく、生形式又は（前）処理後の形式のセンサデータを出力するための個別に図示せぬインターフェイスも備えており、更に普通は独自の制御及び評価ユニット、即ちデータ処理用の独自のハードウェア部品も備えている。
【0060】
実行環境２２は、とりわけセンサデータのデータ処理を行って該データから機械１２への制御命令又はそれ以外の安全に関わる情報及び他の情報を得るような処理ユニットを表す包括的な概念である。実行環境２２はハードウェア部品１６上に実装されており、後で図２～４を参照して更に詳しく説明する。本発明ではどのハードウェア上で実行環境２２を実行するかは決まっていない。上に列挙した考えられるハードウェア部品はいくつかの例を挙げたものであり、それらは任意に組み合わせ可能である。更に、実行環境２２は機械制御装置１８及びセンサ１４のブロック２０と意図的に重ねて描かれているが、これはセンサ１４及び／又は機械１２の内部の計算及び記憶リソースも実行環境２２により利用できるからであり、他方で任意の組み合わせにおいては機械１２及びセンサ１４の外に追加のハードウェア部品１６が全くない可能性も含んでいる。以下では前提として、ハードウェア部品１６が計算及び記憶リソースを提供し、それで以て更に機械１２及び／又はセンサ１４の内部のハードウェアを加えることも意味しているものとする。
【0061】
安全装置１０及び特に実行環境２２はこれで安全機能と診断機能を提供する。安全機能がセンサデータと共に時間的に連続した測定情報及び事象情報の流れを受け取り、対応する評価結果を特に機械１２のための制御信号の形で生成する。加えて自己診断情報、センサ１４の診断情報、又は概観情報を得ることができる。これらは本来の診断機能と区別すべきものであり、後者は、後で図５～７を参照して更に詳しく説明するように、本明細書の範囲内では安全機能の監視を意味する。これら安全に関連する機能又は安全な自動化機能の他に更なるオプションとして安全ではない自動化機能も考えられる。
【0062】
安全装置１０は、安全機能をハードウェア部品１６のサービス又はサービス遂行として提供することにより、想定外の内部及び外部の事象に対して高い可用性と頑強性を達成する。ハードウェア部品１６の柔軟な組み立てと、好ましくはローカル若しくは非ローカルなネットワーク又はクラウドへの該部品の接続により、冗長性と性能の柔軟性を得ることが可能となり、その結果、中断や妨害、要求のピークに非常に頑強に対処することができる。安全装置１０は、エラーがもはや捕らえられなくなり、従って安全に関わるようになったら、すぐにそれを認識して状況に合った反応を開始し、必要ならそれにより機械１２が安全な状態に移行される。そのために機械１２を例えば停止したり、減速したり、回避させたり、危険ではないモードで作動させたりする。改めて明確にしておくと、安全確保に向けた反応を発動させる可能性がある事象には２つのクラスがある。一方はセンサデータから得られる、危険と評価される事象であり、他方は安全に関わるエラーの暴露である。
【0063】
図２は実行環境２２の概略図を示している。実行環境２２の任務は最終的に、センサデータから制御命令、特に安全確保に向けた機械１２の反応を発動させる安全信号を導出することである。実行環境２２はマスタ２４と少なくとも１つの計算ノード２６を備えている。マスタ２４と計算ノード２６のために必要な計算能力と記憶容量はハードウェア部品１６が用意し、実行環境２２は多数のハードウェア部品１６にわたって透過的に広がったものとすることができる。また、計算ノード２６は抽象的又は仮想的なものと理解すべきであって、計算ノード２６とハードウェア部品１６との間に１対１の関係が存在することは必須ではなく、１つのハードウェア部品１６が複数の計算ノード２６を用意したり、逆に１つの計算ノード２６が複数のハードウェア部品１６上に分散していたりしてもよい。この分散はマスタ２４についても同様に当てはまる。
【0064】
計算ノード２６は１又は複数の論理ユニット２８を備えている。論理ユニット２８は閉じた機能的ユニットであって、情報を受け取り、それを結び付けたり、変形したり、変更したり、一般に新たな情報に加工したりしてから、視覚化のため、制御命令として、又は他の処理のために、考えられる受け手、特に他の論理ユニット２８又は機械制御装置１２に対してその情報を利用可能にする。本明細書の枠内では主として３種類の論理ユニット２８が区別される。これは、既に簡単に触れたように、安全機能ユニット、診断ユニット、及び、安全には寄与しないものの他の自動化の任務を全体のアプリケーションに統合することを可能にする任意選択の自動化ユニットである。
【0065】
実行環境２２はその都度必要な論理ユニット２８を活性化してそれらを系統立てて駆動する。これに加えて実行環境２２は、利用可能な計算ノード２６上又はハードウェア部品２６上の所要のリソースを各論理ユニット２８に割り当てて、全論理ユニット２８の活動及びリソース需要を監視する。好ましくは、ある論理ユニット２８がもはや活動していないとき、又は、実行環境２２若しくは論理ユニット２８が中断したときに、実行環境２２がそれを認識する。それから該実行環境は、該論理ユニット２８を再び活性化することを試み、それが可能でなければ該論理ユニット２８の新たな複製を生成することで、系統立った駆動を維持する。もっともこれは機能的な安全に関する要求にとっては不十分なメカニズムであって、図５～７を参照して後に説明するシステム診断が前もって安全に関わるエラーを暴露しない場合や、例えば機械１２がいずれにせよまだ停止している初期化若しくは再起動の間に限って用いられる。
【0066】
中断は予測できることもできないこともある。模範的な原因は、基礎構造、つまりハードウェア部品１６、そのオペレーティングシステム若しくはネットワーク接続におけるエラー、更には過誤による誤操作若しくは改変、又は、ハードウェア部品１６のリソースの完全な消費がある。ある論理ユニット２８が全ての必要な情報、特に安全に関わる情報を全く処理できない又は少なくとも高速に処理できなければ、実行環境２２は該当する論理ユニット２８の追加の複製を作成することで前記情報の処理を引き続き保証することができる。このようにして実行環境２２は論理ユニット２８が所期の品質と可用性で以てその機能を提供するように手配する。このような復旧と修正の対策も、前の段落で述べたように、後で説明するシステム診断に代わるものではない。
【0067】
図３はまた、安全装置１０の実行環境２２の、有利に分化した別の実施形態を示している。マスタ２４は管理及び通信センターとなる。その中に現存の論理ユニット２８に関する構成情報又は構成データがあるため、マスタ２４は、構成に関する必要な知識、特に、どの論理ユニット２８が存在する又はすべきであるか、それらがどの計算ノード２６上にあるべきか、そしてそれらがどのタイミングにおいてリソースを受け取って呼び出されるかという知識を有している。構成データは署名、例えばブロックチェーン技術により、意図的な又は意図せぬ改変に対して保護されていることが好ましい。ここでは安全技術（Safety）をデータ完全性（(Cyber-)Security）と合わせることが有利である。なぜなら、このようにすれば、予期せぬ事故という結果を招く恐れがある攻撃が阻止される又は少なくとも認識されるからである。
【0068】
計算ノード２６はそれ自身の下部構造を備えていることが有利であり、そこには今説明した各ユニットのうち一部しか現存していなくてもよい。まず、計算ノード２６は下位ノード３０に更に分割されたものとすることができる。図では２つの計算ノード２６がそれぞれ２つの下位ノード３０を有しているが、これらの数字は模範例に過ぎず、任意の数の計算ノード２６にそれぞれ任意の数の下位ノード３０が存在することができ、計算ノード２６を渡って下位ノード３０の数が変わってもよい。論理ユニット２８はいきなり計算ノード２６のレベルではなくまず下位ノード３０内で生成されることが好ましい。好ましくは、論理ユニット２８はコンテナの内部で仮想化されて、つまりコンテナ化されている。つまり各下位ノード３０は、好ましくはそれぞれ１つの論理ユニット２８を有する１又は複数のコンテナを備えている。図３では一般的な論理ユニット２８の代わりに既に触れた３種類の論理ユニット２８、即ち２つの安全機能ユニット３２、１つの診断ユニット３４及び１つの自動化ユニット３６を示している。論理ユニット２８の種類と数は単なる例に過ぎないが、実は更に図５～７を参照して説明するシステム診断はとりわけ１つの診断ユニット３４だけで間に合う。論理ユニット２８の下位ノード３０及び計算ノード２６への割り当ては論理ユニット２８の論理的な構造及び協同から完全に独立している。従って、いずれにせよ模範的に示した論理ユニット２８の配置からは内容的な協力について全く何も推定されず、全く同じ機能性で任意に配分の変更が可能であり、それを実行環境２２が用意する。
【0069】
計算ノード２６のノード管理ユニット３８が、該計算ノード２６の下位ノード３０と該計算ノード２６に割り当てられた論理ユニット２８の調整を行う。ノード管理ユニット３８は更にマスタ２４及び他の計算ノード２６との通信を行う。実行環境２２の管理の任務は実質的に任意にマスタ２４及びノード管理ユニット３８に配分することができる。つまりマスタは分散して実装されたものとみなすことができる。しかし、マスタが実行環境２２の全体的な任務を担当し、各ノード管理ユニット３８が各計算ノード２６の局所的な任務に関わるようにすれば有利である。それでも、マスタ２４を好ましくは複数のハードウェア部品１６上に分散させたり、冗長に構成したりすることで、その故障耐性を高めることができる。
【0070】
安全機能ユニット３２の安全機能の典型例はセンサ１４のセンサデータを安全確保に向けて評価することである。ここで考えられるのはとりわけ、危険な場合に機械１２に安全確保に向けた適切な反応をさせることを目的とした距離の監視（特にスピード分離（Speed and Separation））、通過の監視、防護域の監視又は衝突の回避である。これは安全技術の中心課題であり、センサ１４及び評価法に応じて、普通の状況と危険な状況を区別する極めて多様なやり方が考えられる。各々の安全アプリケーション又は安全アプリケーション群毎に、適切な安全機能ユニット３２をプログラミングすること又は現存する安全機能ユニット３２のプールから選択することができる。動作環境２２が安全機能モジュール３２を生成しても、それは安全機能がそれにより新たに創出されることを決して意味しない。むしろ、適切なライブラリ又は専用の完成したプログラムが、データ媒体、記憶装置又はネットワーク接続の使用等の公知のやり方で用いられる。安全機能を半自動的又は自動的に既製のプログラムモジュールのキットからのように組み立てること及び／又は適切に構成することが考えられる。
【0071】
診断ユニット３４は冒頭に挙げた特許文献５に記載の意味で理解することができ、監視者（Watchdog）の役割を果たすか、様々な複雑さのテストと診断を実行することができる。これにより安全機能ユニット３２の安全なアルゴリズムと自己監視手段を少なくとも部分的に置き換えて補うことができる。そのために診断ユニット３４は特定の時点における安全機能ユニット３２の出力に対する予想を有している。それは安全機能ユニット３２の通常運転時における出力でも、テストとして入力された特定の人工的なセンサ情報に対する応答における出力でもよい。本発明では診断ユニット３４が用いられているが、これは個々の安全機能ユニット３２をテストしたりそれらから特定の評価結果を待ち受けたりするものではなく（これらも補足的に可能ではあるが）、後で図５～７を参照して説明するように、機械１２の防護に関与している安全機能モジュール３２のシステム診断を実行するものである。
【0072】
自動化ユニット３６は安全と無関係の自動化の任務のための論理ユニット２８であって、センサ１４及び機械１２又はそれらの一部（一般にアクチュエータ）を監視し、それらの情報に基づいて（一部の）進行を制御する又はそれらに関する情報を用意する。自動化ユニット３６は実行環境によって原則として各論理ユニット２８のように扱われ、従って好ましくは同様にコンテナ化される。自動化の任務の例には、品質検査、変種制御、把持、仕分け又は他の作業ステップのための物体認識、分類等がある。安全に関わる論理ユニット２８、即ち安全機能ユニット３２又は診断ユニット３４との区別は、自動化ユニット３６は事故防止、即ち安全技術的な応用に寄与しないという点にある。信頼性の高い動作と実行環境２２による一定の監視は望ましいが、これは安全性ではなく、可用性を高め、以て生産性及び品質を高めるのに役立つものである。もちろん、この信頼性は、自動化ユニット３６が安全機能ユニット３２と同様に注意深く監視されることによっても生み出されるから、それは可能ではあるが、絶対に必要というわけではない。
【0073】
実行環境２２を用いることにより、安全アプリケーションのための論理ユニット２８を、エッジネットワーク又はクラウドを含むハードウェア部品１６の非常に多種多様な環境上でもほぼ任意に分散させることが可能になる。実行環境２２は論理ユニット２８の全ての所要リソースと枠組み条件の面倒をみる。該環境は必要な論理ユニット２８を呼び出したり、終了させたり、計算ノード２６と下位ノード３０の間で移動させたりする。
【0074】
実行環境２２のアーキテクチャは更に保安と自動化のシームレスな融合を可能にする。なぜなら、安全機能ユニット３２、診断ユニット３４及び自動化ユニット３６は同じ環境内でほぼ同時に実行されるとともに同じように扱うことができるからである。衝突があった場合、実行環境２２は、例えばリソースの逼迫がある場合には安全機能ユニット３２と診断ユニット３４に優先権を与えることが好ましい。構成データにおいて、異なる３種類の論理ユニット２８の共存のための実行規則を考慮することができる。
【0075】
図４はKubernetesを用いた実施形態における実行環境２２の概略図を示している。実行環境２２はここではコントロールプレーンと呼ばれる。図４は図３を手本にしているが、計算ノード２６は見やすさのために省略され、今度は一般的な論理ユニット２８が３種類の可能なユニットを代表して示されている。Kubernetesではマスタ２４が下部構造を有している。この（Kubernetesの）マスタ２４もやはりコンテナ又は論理ユニット２８の実行を自ら担当せず、全体の進行又はオーケストレーション（オーケストレーションレイヤ）の世話をする。そのため構成データはオーケストレーションファイルと呼ばれる。更に、Kubernetes環境に関係する全データ用のデータベース（etcd）４０、KubernetesへのインターフェイスとしてのＡＰＩサーバ４２、そして、本来のオーケストレーションを行う予定及び制御管理部４４が設けられている。
【0076】
現存するハードウェアは計算ノード２６としてのノードに分割される。他方、ノード内には下位ノード３０としての１又は複数のいわゆるポッドがあり、その中に本来のマイクロサービス（いまの場合は論理ユニット２８）を含むコンテナが、それに属するコンテナランタイムと、全てのライブラリと、論理ユニット２８にとってランタイム時に必要な依存性とを含んで存在する。ローカルな管理を行うのは、いわゆるKubelet３８ａとプロキシ３８ｂを有する今度は２分割されたノード管理ユニット３８である。Kubelet３８ａはノード自身のポッドとコンテナを管理するエージェントである。他方、プロキシ３８ｂはノード間及びマスタとの通信のためのネットワーク規則を含んでいる。
【0077】
Kubernetesは実行環境２２の好ましい実装手段であるが、唯一のものではない。複数ある他の代替物の中からはDocker Swarmが挙げられよう。Dockerそのものは直接の代替物ではなく、コンテナ生成ツールであり、それ故にKubernetesともDocker Swarmとも組み合わせ可能であり、その場合はそれらがコンテナのオーケストレーションを行う。
【0078】
図５は状態監視と実行監視によるシステム診断を具体的に説明するために描いた実行環境２２の別の概略図である。これを担当するのは診断ユニット３４の特別な型であるシステム診断ユニット３４である。ここでは純粋な模範例として、センサ１４のデータを評価するために連続的に作動する３つの論理ユニット２８を監視対象とする。本発明はこれに限られず、任意の個数の論理ユニット２８を互いに任意に接続し、且つセンサ１４との独自の接続を持つ又は持たないものとすることができる。論理ユニット２８は好ましくは安全機能ユニット３２である。他の診断ユニット３４、例えばシステム診断を補って専ら特定の安全機能ユニット３２を監視又はテストするものを設けてもよい。更に、自動化ユニット３６にとって危険又は事故の回避のための安全な監視そのものは必要ないとしても、なお自動化ユニット３６をシステム診断に組み入れることは可能である。論理ユニット２８の具体的な形態は以下では重要ではなく、それ故に一般的な論理ユニット２８が描かれている。
【0079】
システム診断ユニット３４は状態監視４６と実行監視４８を担当している。これらからシステム全体の安全な状態の最終的な判定を導き出すことができる。状態監視４６については以下に図６を参照して、実行監視４８については図７を参照して更に詳しく説明する。図５にはシステム診断ユニット３４が１つだけ、状態監視４６と実行監視４８を表す独自のブロックと共に描かれている。これはとりわけ構想の理解に役立つものであり、状態監視４６と実行監視をシステム診断ユニット３４の一部と解釈することや、機能性を他のやり方で分散させることも考えられる。
【0080】
論理ユニット２８はメッセージシステム又はメッセージ伝送システムを通じてシステム診断ユニット３４と通信する。メッセージシステムは実行環境２２の一部であるか、それを拡張して実装されたものである。発信元の論理ユニット２８の内部状態について知らせる状態監視４６のステータスメッセージ又は状態メッセージ５０と、発信元の論理ユニット２８のサービス要求乃至はサービス実行に関する情報をもたらす実行監視５２の実行メッセージ５２という、２重のメッセージの流れがある。従ってメッセージシステムは２重に設けられるか、２つの通信チャネルで構成される。好ましくは各メッセージ５０、５２がメッセージの流れを防護するメタデータを含んでいる。このメタデータは例えば発信者情報、タイムスタンプ、シーケンス情報及び／又はメッセージ内容についてのチェックサムを含んでいる。
【0081】
システム診断ユニット３４は受け取った状態メッセージ５０に基づいて安全装置１０の全体状態を推定し、それに対応して、受け取った実行メッセージ５２からサービス要求の処理に関する全体的な情報乃至は安全装置１０の実行経過を推定する。該当する予想との比較により安全装置１０内のエラーを暴露し、エラーの場合は安全確保に向けた適切な反応が開始される。
【0082】
あらゆる不一致が直ちに安全に関わるエラーを意味するものではない。そこで、安全レベルに応じて一定の時間だけ逸脱を容認することができる。あるいは、再びエラーのないシステム状態に達するために復旧メカニズムを試みる。ただしその場合、どのような時間枠又は他の枠内であれば差し当たりエラーを観察するだけでよいのかは安全構想により厳密に指定される。更に、様々な思い切った防護対策を必要とするエラーを分類したり、状況に応じた条件でエラーを評価したりすることもできる。後者は最新の状況を取り入れて「安全」及び「安全な」という概念を細分化することになる。安全に関わる構成要素の故障又は安全に関わる機能の不実行は、特定の前提の下、つまり状況によっては、危険なシステム状態をまだ必然的に意味してはいない可能性がある。例えば、ロボットを含む共同作業領域を監視するセンサ１４が故障するかもしれないが、他方でそのロボットがこの領域に滞在しないことは確実であり、それはロボット自身の安全な座標制限によって保証できる、という場合である。ただし、安全確保に向けた反応を起こす必要があるかどうかをこのように状況に応じて評価するための規則も、やはり同様に安全構想と合ったやり方でシステム診断ユニット３４が知っていなければならない。
【0083】
安全確保に向けた機械１２の反応は好ましくは遮断サービス５４を通じて発動される。これは更に別の安全機能ユニット３２であってもよく、それは好ましくは図に反してシステム監視に含めることができる。遮断サービス５４は反転して作動すること、つまり、システム診断ユニット３４から機械１２の作動を許可する肯定的な信号を待ち受けて機械１２に転送することが好ましい。これにより、システム診断ユニット３４又は遮断サービス５４の故障を自動的に捕らえることができる。
【0084】
機械は、遮断サービス５４という名前に拘わらず、このサービスにより必ず電源を遮断されるわけではなく、それは単に思い切った対策に過ぎない。エラーによっては、減速や速度制限及び／又は動作空間の制限等によって既により安全な状態に到達できる可能性がある。そうすれば生産性への影響がより小さくなる。遮断サービス５４は、論理ユニット２８のいずれかにおいてセンサデータの評価により危険な状況が認識されたときに該ユニットにより要求されるものとすることもできる。これに対応する矢印は図５では見通しを良くするために省略した。
【0085】
図６は状態メッセージ５０に基づく状態監視４６の概略図を示している。好ましくは、監視対象の各論理ユニット２８から遅くとも所定時間（例えば数ミリ秒）の経過後に状態メッセージ５０が届かなければならないという意味で、状態メッセージ５０が連続的又は規則的にシステム診断ユニット３４へ伝送される。その場合、サイクル又はクロックを固定することも考えられるが、必須ではなく、所定時間の枠内での時間的な揺らぎも考えられる。
【0086】
論理ユニット２８は状態メッセージ５０の発信前に自己診断を行うことが好ましい。これは全ての実施形態でそうである必要はなく、状態メッセージ５０は単にバイタルサイン又は事前に自己診断していない内部状態の転送であってもよいし、自己診断を状態メッセージ５０の送信より低い頻度で行ってもよい。自己診断は、例えば自らのメモリに保存されたデータとプログラム部品、処理結果、及びシステム時間を検査する。それに対応して状態メッセージ５０は論理ユニット２８の内部状態に関する情報を含み、該論理ユニットがその任務を正しく遂行できるかどうか、例えば該論理ユニット２８が十分な時間内に全ての必要なデータを手元に持っているかどうかについて情報を与える。加えて状態メッセージ５０は先に挙げたメタデータを含んでいることが好ましい。
【0087】
システム診断ユニット３４は状態メッセージ５０の内容を解釈し、これをそれぞれの論理ユニット２８に割り当てる。論理ユニット２８の個々の状態を安全の観点から結合して安全装置１０の全体状態にする。システム診断ユニット３４は、どの状況におけるどの全体状態が安全を保証するかという所定の予想を有している。既に検討した許容差と状況に応じた適合化もできれば考慮しつつ、最新の全体状態と比較した結果、前記予想が満たされていないと分かったら、それは安全に関わるエラーである。それに応じたメッセージを遮断サービス５４へ送信することで、機械１２を該エラーに対する適切な安全な状態に移行させる。
【0088】
図７は実行メッセージ５２に基づく実行監視４８の概略図を示している。サービス内部の１番目の論理ユニット２８は、サービスに関与する全ての論理ユニット２８をその実行時に参照する一意のプログラムシーケンス標識（「シーケンス」と略記）を生成する。シーケンスは各実行の終了後にその次の論理ユニット２８に伝えられるから、該ユニットは実行メッセージ５２の作成の際に自らをシーケンスと関連づけることができる。実行メッセージ５２は、好ましくは先に挙げたメタデータに加えて、各実行の開始時点と継続時間を含んでいる。実行メッセージ５２の要素として他に考えられるのは、実行されたものの一意の標識、そしてシーケンスである。実行メッセージ５２は事象ベースで完全な実行の終了毎に送信することが好ましい。周期的に用意されるセンサデータを評価することがよくあるから、間接的には、事象ベースのメッセージの流れも先に定義した意味で周期的又は規則的になり得る。
【0089】
集計部５６が実行メッセージ５２を集め、各実行を、一意のプログラムシーケンス標識に基づいて論理的及び時間的な配列内又は実行経過内に入れる。従ってこの実行経過は実際の実行を記述している。システム診断ユニット３４は他方で実行予想５８、即ち期待される実行経過へのアクセスを有している。この実行予想５８は、典型的には安全の専門家が安全構想との関係で設定した基準値であるが、実施形態によってはなおシステム診断ユニット３４により修正することができる。システム診断ユニット３４が実行予想５８へのアクセスを有していなかったら、それはいずれにせよ許容時間の後で安全に関わるエラーとなり、その結果、機械１２を防護するために遮断サービス５４が要求される。集計部５６と実行予想５８は別々に描かれており、そのように実装することが好ましいが、代わりにシステム診断ユニット３４の一部と解釈することもできる。
【0090】
システム診断ユニット３４は、今度は実行監視４８の枠内で、サービス要求の処理中の時間的及び論理的なエラーを認識するために、集計部５６により伝えられた実行経過と実行予想５８とを比較する。不一致があれば安定化のためのステップを開始することができ、あるいはエラーがもはや明らかに抑制可能でなければ直ちに遮断サービス５４を通じて機械１２を防護する。
【0091】
実行監視４８の検査される側面の幾つかの例として、あるサービスを完全に果たすにはある実行が足りない、予期せぬ余分な実行が報告された（それはサービスに関与している論理ユニット２８の予期せぬ多重実行でも、サービスに関与していない論理ユニット２８の実行でもよい）、実行時間が短すぎる又は長すぎる（それが重大かどうか判定するための定量化を含む）、ある論理ユニット２８の個々の実行の実行間の経過時間、が挙げられる。これらの不一致のどれが安全に関わるか、どの枠内で且つどの状況においてそれらがまだ許容できるか、そしてそれぞれどの適切な安全対策が開始されるかは、実行予想５８乃至はシステム診断ユニット３４内に保存されている。
【図1】
【図2】
【図3】
【図4】
【図5】
【図6】
【図7】