ロボット安全制御アーキテクチャ：デュアルチャネルとウォッチドッグ

ロボット安全制御アーキテクチャは、危険な状態を検知し、対応を決定し、物理的な機械を定義された安全状態に導く完全な機能連鎖です。安全PLCや監視タイマーの2つのセンサーでは、その分離を確立することはできません。

エンジニアはチャネル独立性、診断カバレッジ、応答時間、最終スイッチング、ブレーキおよびエネルギー挙動、リセットおよび再起動を指定しなければなりません。共通原因障害と系統的故障は、一見冗長に見えるハードウェアを同時に無効化できるため重要です。

このガイドは教育的なものであり、適合性を確立するものではありません。ロボット 機能安全ガイド および ロボットリスク評価ガイドと併用し、現在の規範基準と適格な検証を適用してください。

コンポーネントを選ぶ前に、安全機能全体を定義する

開始条件、動作モード、必要な応答、最大応答時間、最終物理状態、リセット条件、意図的な再起動動作を書き出します。センシング、入力モジュール、論理、通信、ドライブセーフティ機能、コンタクター、ブレーキ、アクチュエータ、フィードバックを一つの境界に含めます。

各機能が制御する危険な運動やプロセスエネルギーを追跡します。製品証明書は、サブシステムの主張をその設定および条件内でのみ支持します。インストールされたアプリケーションの機能を証明するものではありません。

信頼できる故障を許容し診断するためにデュアルチャネルを活用する

独立したチャネルは、1つの開回路、ショート、詰着接触、センサーの故障を意見の不一致によって見えるようにしてしまうことがあります。設計では、チャネルの開始地点、比較場所、検出された不一致がどのように出力や再起動許可を変化させるかを定義しなければなりません。

診断タイミングのない冗長性は、最初の故障を潜在的な状態にし、2つ目の故障が発生するまで待つことがあります。実際の接触およびセンサー挙動からの不一致ウィンドウを指定し、迷惑なトリップを抑制するためだけにウィンドウを延長できないか確認します。

チャネルをカウントする代わりに、共通原因故障を制御する

同じケーブル、電源、コネクタ、キャビネットホットスポット、ソフトウェアコンポーネント、座標の仮定を通る2つの経路が同時に故障することがあります。電力の過渡現象、汚染、熱、振動、電磁干渉、保守エラー、共有要件をレビューします。

正当な分離、独立した保護、環境評価、適切な配線の多様性、そして管理された配線の実践を用いましょう。残った共有部分を記録し、計算やテストが静かに不可能な独立性を前提にしないようにしましょう。

安全鎖要素	信頼できる故障	診断的証拠	必要な反応
フィールドセンサー	開いている、ショート、または固まっている	脈拍検査と不一致検査	安全状態と故障
論理	タスク、メモリ、またはプログラムの故障	自己テストとクロスチェック	影響を受けた出力を無効にする
通信	敗北、遅延、または再試合	シーケンス、整合性、タイムアウト	定義されたフォールバック
最後の要素	スイッチが固着するかブレーキの故障	EDMとモーションフィードバック	再起動禁止
共有リソース	電力か環境か	独立監視または分析	安全対応のエスカレーション

監視犬を明確な死角を持つタイミング監視器として扱う

プロセッサのウォッチドッグはオーバーランや停止されたタスクを検知でき、ハートビートはピアの欠落を検知できます。どちらも、妥当な値で固定されたセンサー、誤った座標変換、または誤ったコマンドを繰り返しタイミング通りに送信するアルゴリズムを必ずしも検出するわけではありません。

故障モデルが要求するところでは、合理性、新鮮さ、航続距離、チャネル間および物理的フィードバックを追加してください。ROS 2リアルタイム制御ガイドは締め切りやジッター測定を説明していますが、通常のリアルタイム監視が自動的に安全機能であるわけではありません。

メッセージの送信元、順序、年齢、完全性の検証

安全関連の通信経路は、現在のメッセージと遅延、繰り返し、挿入または誤ルーティングされたメッセージを区別しなければなりません。識別子、カウンター、時間または年齢ルール、整合性チェック、損失や無効状態に対する限定反応を定義します。

認証や認可などのサイバーセキュリティ制御は悪意あるアクセスに対応し、機能安全通信メカニズムは定義されたランダムかつ体系的な通信の失敗に対応します。分析をつなげるだけでなく、どちらか一方を他方の代替と見なさないでください。ROS 2とDDSセキュリティガイドをご覧ください。

安全PLCは認証されたアプリケーションの範囲内に収めてください

正確な安全PLC、ファームウェア、I/O、ファンクションブロック、スキャン時間の仮定、環境限界、証明試験条件を確認してください。通常の変数、オンライン編集、強制関数、バイパスビットは安全ロジックを損なったり、アクセス制御から逃れてはなりません。

公式IECページでは、 IEC 62061:2021 1:2024 修正案を機械の安全関連制御システムの設計、統合、検証を対象としています。プロジェクト固有の機能安全計画を通じて、現在の範囲と選択したアーキテクチャを適用してください。

命令された出力と物理的な結果を検証する

「セーフトルクオフ」を要求したという論理的な部分だけでは、すべてのドライブが反応したり、溶接されたコンタクターが開いたり、ホールディングブレーキが作動したり、危険な圧力が消えたという証明にはなりません。出力読み取り、外部機器監視、関連する動きやエネルギーフィードバックを活用してください。

重力軸は、モータートルクを外すと動きが許されるため、特別な注意が必要です。シーケンスを ロボットのジョイントブレーキとセーフストップガイド にリンクし、実際のペイロード、姿勢、悪循環の供給条件をテストします。

セーフステートの定義、リセット、再起動は別々の決定です

安全状態とは、停止運動、位置維持、排気圧力、孤立したプロセスエネルギー、またはその他の危険特有の状態を指します。安全を守るために何が電力を保つべきか、そして優先制御停止が完了できない場合に何が起こるかを明記してください。

故障を除去したり安全装置をリセットしたりすることが、危険な動きを引き起こすべきではありません。可視性、プレゼンスチェック、モード選択、そして別の意図的な開始を指定し、その後、電力と通信の喪失と復旧をテストします。

制御系統的故障と構成ドリフト

誤った要件、重複されたソフトウェアの欠陥、誤ったチャネルマッピング、未確認のパラメータ変更は、コンポーネント破損なしに冗長性を失わせる可能性があります。バージョン管理、独立審査、制限変更、再現可能なビルド、署名またはハッシュ化された構成ベースラインを使用してください。

すべての安全要件を図、プログラムオブジェクト、パラメータ、テストケースにリンクさせてください。ファームウェア、ツール、ペイロード、ネットワーク、コントローラー、AIポリシーの変更は影響評価や選択的または完全な再検証を引き起こします。

チェーン全体に故障を注入する

承認された安全なテスト計画のもと、入力開回路、スタック、クロスショート、凍結心拍、繰り返しシーケンス、プロセッサオーバーラン、出力スタック状態、溶接コンタクタ、フィードバックミスマッチをシミュレートします。アラームメッセージだけでなく、物理的な動きやエネルギーを観察してください。

検出時間、達成状態、診断コード、オペレーター情報、再起動抑制の記録。偶発的な理由で停止した機械は、指定された故障反応を示していません。

適用範囲内で最新の安全管理基準を適用すること

公式ISOカタログでは、ISO 13849-1:2023安全関連制御システム部品の設計および統合に関する第4版として掲載されています。現在公開されている検証版はISO 13849-2:2012年であり、後継版の開発中です。

法的およびプロジェクトの文脈から、該当する版、必要なPLまたは SIL、機械固有のType-C規格を選択してください。公開要約やコンポーネントマーケティングは、規範文書や有能な工学的判断に代わるものではありません。

監査可能な安全管理証拠ファイルを公開する

安全要件仕様、チャネルおよび依存関係図、故障解析、計算、証明書および制限、ソフトウェアおよび構成バージョン、故障インジェクション手順、タイミングトレース、物理結果および残留リスクを保持します。

以下のチェックで詳細に確認してください。

受容地域	必要な証拠	不合格パターン	再認証トリガー
要件	トリガー、時間、安全状態	曖昧な停止コマンド	ハザードまたはモード変更
建築	チャネル、診断およびCCF	共有隠れ依存	ハードウェアまたは配線の変更
論理	レビュー済みバージョンとパラメータ	制御されていないバイパス	ファームウェアやプログラムの変更
物理出力	測定された運動とエネルギー	ビットのみの確認	駆動、ブレーキ、またはペイロードの変更
故障試験	注入されたケースアンドトレース	安全な結果がないアラーム	テスト方法またはインターフェースの変更

• トリガーから物理的なセーフステートまでの各機能を定義してください。
• 番組のチャンネル独立性と共通原因管理。
• 監視犬が検出できるものとできないことを明示してください。
• 最終要素、ブレーキ、残留エネルギーを確認しましょう。
• コントロールリセット、再起動、バイパス、そして関連するすべての変更を。

よくある質問

2つの安全センサーは自動的にデュアルチャンネル機能を作り出しますか？

いいえ。独立性、診断、共通原因制御、論理、出力および検証は、機能全体を支えなければなりません。

ウォッチドッグはすべてのソフトウェアエラーを検出できますか？

いいえ。選択されたタイミングやライブの失敗を検出できますが、誤った数値や要件の不備については他のチェックが必要です。

安全PLCはPLや SILを保証できますか？

いいえ。正確なアプリケーションアーキテクチャ、コンポーネント、プログラム、配線、計算、検証が要件を満たしていなければなりません。

暗号化されたメッセージは自動的に安全メッセージになるのでしょうか？

いいえ。セキュリティは特定の脅威から守ります。安全通信には、損失、遅延、リプレイ、ミスルーティングの有界検出も必要です。

故障注入は実際のハードウェアにダメージを与えるべきでしょうか？

いいえ。制御不能な危険を生じさずに故障経路を明らかにする承認されたシミュレーション、テストインターフェース、製造手順を用いてください。

安全管理証拠の境界

搭載アプリケーションに対して、センサーから作動までの完全な経路、診断限界、セーフステート、リセット、再起動、故障応答が実証された場合にのみ、ロボット安全制御アーキテクチャを受け入れてください。