ロボットリスク評価は、アプリケーションライフサイクル全体で人々がどのように被害を受けるかを特定し、該当プロセスの下で残存リスクが許容されるまでコントロールを選択します。ロボットアームの故障だけでなく、工具、プロセスエネルギー、ワークピース、レイアウト、ソフトウェア、人員、操作モードが境界を共有しています。
FMEA、HAZOP、 STPA は補完的な解析手法です。 FMEA 故障モードから始まり、HAZOPは設計意図からの逸脱を探り、 STPA 安全でない制御操作や不十分な制約、個々の部品が故障していないシナリオを検証します。
このガイドは教育的なものであり、コンプライアンスの判断ではありません。 Physical AIの安全層ガイド と ランタイム安全シールドガイドと一緒に使ってください。
システム全体とライフサイクル境界を設定する
ロボット、工具、ワークピース、治具、プロセスエネルギー、制御、ネットワーク、環境、そして相互作用する人々を定義してください。輸送、設置、設置、教育、自動運転、清掃、回収、保守、廃止措置をカバーします。
意図された使用、合理的に予見可能な誤用、アクセスルート、オペレーターの能力、環境制限を記載してください。生産側が使用すべきでないモードを除外しても、予見可能な曝露が消えるわけではありません。
まず損失、危険、受け入れルールを定義します
怪我、露出、負荷の低下、制御喪失など、許容できない損失を挙げてください。スコアをつける前に、それらを危険なシステムの状態や信頼できるシナリオに結びつけてください。
リスク見積もり方法とエスカレーションルールを文書化してください。数値のランクは作業の優先順位付けに役立ちますが、不確実性を客観的な真実に変えたり、掛け算によって深刻な危険を消したりすることはありません。
| 方法 | 始まる | よく見つけた | 単独で使うと盲点があります |
|---|---|---|---|
| FMEA | コンポーネントまたは機能の故障 | 故障影響と検出 | 危険な普通のやり取り |
| ハゾップ | 設計意図からの逸脱 | プロセスおよびコマンドの逸脱 | 複雑な制御構造 |
| STPA | 損失と制御制約 | 安全でない制御相互作用 | 詳細な部品信頼性 |
| 事故のレビュー | 観測された出来事 | 実際の運用証拠 | 未知の未観察例 |
| タスク解析 | 人間の作業シーケンス | 曝露と誤用 | 潜在的な技術的故障 |
故障効果や診断には FMEA を使います
機能、故障モード、局所およびシステムへの影響、原因、既存の制御および検出を一覧にします。故障を安全機能を通じて追跡し、部品の症状にとらわれずに追跡しましょう。
共通原因の故障と依存的な故障は別々に扱いましょう。故障した機能と電力、タイミング、ソフトウェアを共有する診断は、独立したカバレッジを提供しない場合もあります。
意図からの逸脱にはHAZOPを使います
コマンドや処理変数にガイドワードを適用します:いいえ、もっと、少なめ、逆、早い、遅い、その他、または一部。ロボットの場合、逸脱は速度、力、位置、識別、順序、タイミング、権限などに関わることがあります。
原因、結果、保護、行動を記録します。HAZOPは、プロセス物理学と制御実装の両方を理解した学際的なチームと連携して最も効果的に機能します。
安全でない制御シナリオには STPA を使います
モデルコントローラー、制御されたプロセス、フィードバックおよび制御アクション。アクションが提供されていないのか、安全でない時に提供されるのか、早すぎるか遅すぎるのか、適用されすぎているのか、または早すぎる間に停止されたのかを問いかけてください。
MITSTPAハンドブックにはその方法が説明されています。定義されたプロジェクト内で適用し、証拠を保持すること;STPAという名称を使うことは、完全なシナリオカバレッジを保証するものではありません。
AIの配分シフトと権限の対立をカバーします
AIロボットの危険には、未知の観察、脆弱な言語の根付き、遅延推論、古い世界状態、そして検証済みの範囲外の動作を要求するポリシーが含まれます。これらは必ずしもハードウェアの故障部品に還元できるわけではありません。
自律、遠隔操作、安全PLC、人的介入および回収コントローラー間の対立を分析します。誰が権限を持つのか、どのように移行が行われるのか、そしてチャネル間で意見が合わない場合にどの状態が安全かを定義してください。
階層内でリスク削減を選択する
危険を排除または軽減するために本質的に安全な設計を優先し、その後に安全対策や補完的な保護措置、そして情報と研修を進めます。警告は回避可能なピンチポイントや露出したプロセスエネルギーを補うことはできません。
制御がすべての関連モードで動作し、新たな危険を生み出さないか確認してください。伝え管理すべき残存リスクを記録しましょう。
発見をテスト可能な安全要件に変える
各重要なシナリオは、トリガー、状態、応答時間、最終条件、故障挙動、受理証拠を含む所有要件を生成すべきです。「システムは安全である」「AIは信頼できる」といった表現は避けてください。
要件を設計要素および検証ケースに双方向でリンクさせます。追跡された危険のない実装された安全策と検証ケースのない危険はどちらもギャップです。
最新の基準とガイダンスを慎重に活用する
ISOカタログによると、 ISO 12100:2010 は現在発行されている機械リスク評価版であり、代替案が開発中であるとされています。プロジェクトの適用可能性および移行ルールは意思決定時に確認しなければなりません。
実際の規範文、Type-C基準、管轄規則を有能な専門家と共に活用してください。本記事では分析構造について説明しますが、必要なリスクレベルを割り当てるものではありません。
運用・インシデント・ヒヤリハットの記録を含める
現地観察では、設計ワークショップに欠けている近道、作業量、迷惑な停止、復旧手法が明らかになります。インシデント、接近事故、介入、保守結果をシナリオや管理にフィードバックします。
NIOSHは職場の証拠に関連する ロボティクス安全研究プログラム を維持しています。公的ガイダンスは申請審査の代わりにならないように、補足資料として扱いましょう。
すべての重要な変更点を再評価します
ツール、ペイロード、プログラム、速度、レイアウト、センサー、ファームウェア、AIモデル、データ、ネットワーク、オペレーターの役割や運用環境の変更後にレビューをトリガーします。この変化をハザード仮定や安全性・関数検証と比較してください。
新興の失敗を 失敗マイニングガイド に接続しつつ、保護要件は学習アップデートとは独立させましょう。
| トレースリンク | 必要な成果物 | 監査に関する質問 | 失敗 |
|---|---|---|---|
| 制御への危険性 | リスク決定 | なぜこの制御を行ったのか | 不当な設計 |
| 制御から要求へ | 仕様 | 何が起こるべきか | 曖昧な意図 |
| 検査の要件 | ケースと結果 | どのように検証されているか | 紙の管理 |
| 基準値までのテスト | 構成 | 試験内容 | バージョンギャップ |
| 再評価の変更 | インパクト記録 | 無効になったもの | 古くなったセーフティファイル |
リビングリスクの記録を公開する
境界、仮定、参加者、手法、シナリオ、推定、管理、残留リスク、要件、テスト、構成ベースライン、所有者および再評価トリガーを保持します。意見の相違や不確かな証拠は見えるように保ちましょう。
以下のチェックで詳細に確認してください。
- すべてのライフサイクルモードと予見可能な誤用を網羅します。
- コンポーネント、偏差、制御シナリオビューを組み合わせます。
- AIのシフトや権限の移行を明確に扱いましょう。
- すべての物質的危険を検証済みの管理機構に追跡してください。
- インシデントや変更の際も評価を維持しましょう。
よくある質問
FMEAだけで完全なロボットリスク評価でしょうか？
いいえ。故障モードには有用ですが、危険な相互作用や通常運転の危険を見逃すことがあります。
低いRPNは無視できますか？
自動的にではない。厳しさ、不確実性、法的要件、方法固有の規則は依然として判断を必要とします。
STPAFMEAの代わりになるのでしょうか？
いいえ。彼らは異なる質問に答え、しばしば補完的な関係にあります。
誰が参加すべきでしょうか？
設計、制御、プロセス、安全、運用、保守、影響を受けたユーザー専門知識を含めてください。
AIモデルの更新は再評価を引き起こすのでしょうか？
動作、分布の仮定、タイミング、インターフェース、または検証済みの制御が変わる場合には、はい。
ハザード・トゥ・ニーズ・トレーサビリティ境界
ロボットリスク評価は、ハザードシナリオから実施された要件、検証された証拠、制御された変化までのトレーサビリティによって成功します。単一の分析手法の名前やスコアによっては決まっていません。