はじめての機能安全（その６）

6.　要件定義、設計、開発などのプロセス　

機能安全ライフサイクルの主要なフェーズについてさらに詳しく説明します。

6.1　要件定義フェーズ

顧客要求または市場要求に基づき、または、製品やシステムの種類、ユーザ、用途などを想定して要件を定義します。このとき、その製品やシステムに係る国内外の関連規制や規格にも基づいて要件を定義します。
製品やシステムの機能や使用法、関連する規制や規格に対して、想定される危険性をハザード分析しリスクを評価します。リスク評価結果に基づき、安全要件と安全性レベルを定義します。要件定義書を作成し、レビューして承認を得ます。この文書は、製品やシステムの開発において、後続の設計や開発、試験や懸賞、保守において、参照される重要な文書の一つです。

6.2　設計フェーズ

このフェーズでは、要件定義フェーズで作成された要件定義書に基づき、製品やシステムの主機能及び安全要件を満たすシステム設計仕様書を作成します。さらに、この仕様に基づき、ハードウェアとソフトウェアの設計書とハードウェアとソフトウェアのインタフェース設計仕様書を作成します。各機能が安全性に与える影響を考慮し、安全要件をハードウェアとソフトウェアで実現できるようにします。また、安全性に関連するリスク評価を実施し、リスクを最小限に抑えるために、FMEA（故障モード影響解析）などの安全性検証を行い設計を見直します。安全要件が満たされていることを確認するため、設計の段階で検証および確認を実施します。各仕様書についてはレビューを行い、承認を得てから次のフェーズに進みます。

6.3　開発フェーズ

設計フェーズで作成された仕様に基づき、ハードウェアとソフトウェアを実装します。
ハードウェアとしては、筐体の設計、PCBの設計及びワイヤーやコネクタなどの部品の選定と、組み立てとその後の評価があります。これらは、設計フェーズで作成されたハードウェア設計仕様書に基づいて実装されます。
ソフトウェアについては、OSやドライバ、ミドルウェア、アプリケーション、通信スタックなどの実装とデバックがあります。これらは、設計フェーズで決定されたソフトウェア設計書とインタフェース設計仕様書に基づき実施されます。OSS（オープン・ソース・ソフトウェア）を活用する場合は、安全性や信頼性に関する評価を行います。

6.4　試験・検証フェーズ

製品やシステムの実装後に検証およびテストを実施します。ソフトウェア、ハードウェアの主機能と安全機能のすべての要素が正しく機能することを確認します。このフェーズでは、以下のようなテストが行われます。

• 単体テスト：機能または構造モジュール単位ごとにテストします。

• 結合テスト：複数のモジュールを組み合わせた場合に正しく機能するかどうかをテストします。

• システムテスト：システム全体が仕様通りに機能するかどうかを確認します。

• 受入テスト：顧客が製品やシステムを受け入れる前に、最終的に行われるテストです

検証および安全性の確認が完了したら、検証報告書、安全証明書を作成します。製品またはシステムの設置を行い、顧客の承認を得て、製品やシステムを運用に移行します。

6.5　運用フェーズ

実際に製品やシステムが稼働している状態で、安全性を確保するための監視やメンテナンスを実施します。
定期的な点検、メンテナンス、および保守を実施し、さらに製品やシステムの運用状況を常にモニタリングし、安全性に影響する問題が発生しないようにします。

6.6 　改善フェーズ

機能安全に関する情報を収集するために、製品やシステムの監視やトラッキングを実施します。この情報には、運用中の不具合、問題や事故などがあります。さらに、機能安全に関する規制や規格の変更などが含まれます。
収集された情報は、改善点を特定するために分析されます。改善点には、運用中の問題の解決策、機能安全要件の改訂、製品やシステムの設計や構成の改良、および故障データの解析に基づく修正点などが含まれます。
改善点が特定されると、改善アクションを実施するための計画が策定されます。改善アクションには、設計や製造プロセスの変更、製品やシステムのアップグレード、およびトレーニングや文書の改訂などが含まれます。改善アクションは、製品やシステムの安全性を向上させるために、継続的に実施されます。

機能安全ライフサイクルの各フェーズは、製品やシステムの安全性を確保するために不可欠な手順です。これらの手順は、設計や製造プロセスにおいて機能安全要件を満たし、製品やシステムが安全に運用されることを保証します。また、継続的な改善活動によって、製品やシステムの安全性を向上させることができます。

6.7　機能安全マネジメント

機能安全マネジメントとは、機能安全を達成するために必要なプロセスを定義し、実行するための管理システムです。このマネジメントシステムは、組織全体での機能安全に関する方針と目標を策定し、それを実現するための手順や責任を明確にすることを目的としています。
機能安全マネジメントには、以下のような要素が含まれます。

• 方針と目標と計画の策定：

機能安全の重要性や目的を明確にし、それを達成するための具体的な方針と目標を定め計画を策定します。

• リスクアセスメントとリスクマネジメント：

機能安全に関するリスクを特定し、それらを評価して、適切なリスクマネジメント手順を定めます。さらにリスクが安全にかかわる問題として発現した場合は、その問題を解決します。

• ライフサイクルとプロセス：

製品の機能安全性を確保するために製品のライフサイクルを明確にし、要件定義、設計、開発、試験、検証、保守などのプロセスを定めます。

• 作業成果物：

製品の機能安全性の確保を証明するために、各プロセスで行った作業の成果物を明確にして作成をリードし、規格に準拠しているか確認します。

• 組織・人員：

組織内での機能安全に関する責任と役割を明確にし、適切な人員を配置することで、機能安全の確保を図ります。人員配置に際しては、その人物がもっているスキルで役割を担うことが可能かどうかを確認します。役割が困難な場合は、主担当のもと作業を担当させながら教育を実施しスキルアップを図ります。また、教育の実施に際しては、記録をとります。なお、機能マネジメントを行う人物も機能マネジメント教育を受けかつスキルを持つ人物が担当しなければなりません。

• コンプライアンス：

規制や規格に対するコンプライアンスを確保するために、内部監査や評価を実施し、適切なレポーティングを行います。内部監査または評価は社内、部、課に於いても利害関係のない第３者によって実施します。監査または評価はプロジェクト外の人物によって実施されるよう規格で規定されています。

これらの要素を統合的にマネジメントすることで、製品の機能安全性を確保することができます。機能安全マネジメントは製品のプロジェクトマネジメント内で行うことも可能ですが、安全がスケジュールやコストに対して優先されるようマネジメントされなければなりません。そのため、機能安全マネジメントはプロジェクトマネジメントとは異なる人物が行った方がよいとされています。

6.8 ハザード分析とリスク評価

ハザード分析とリスク評価は、機能安全の中で非常に重要なプロセスです。これらは、機能安全マネジメントの一部であり、製品の開発や運用において、危険を特定し、評価し、管理するために行われます。
ハザード分析は、システム、製品、プロセスなどに関連する潜在的な危険を特定するプロセスです。これには、システムの構成要素、機能、および環境条件などを評価し、危険な状況やイベントを特定するための手法が含まれます。ハザード分析には、様々な手法があり、代表的なものには、FMEA（故障モード影響分析）、FTA（故障木解析）、HAZOP（ハザードおよび操作性解析）などがあります。
一方、リスク評価は、特定された危険に対して、その発生の可能性とその結果の深刻度を評価するプロセスです。リスク評価には、単純な定性評価から量的な評価まで、多様なアプローチがあります。一般的に、リスクは、発生の可能性と深刻度に基づいて、高、中、低などのレベルで評価されます。リスクのレベルによって、適切な対策が決定され、リスクを最小限に抑えるための計画が策定されます。

ハザード分析とリスク評価は、製品の設計や開発の初期段階から、その後の試験や運用に至るまで、継続的に行われる必要があります。これらのプロセスは、製品の機能安全性を保証するために不可欠であり、機能安全ライフサイクルの中で、最も重要なステップの一つです。

コラム：ChatGPTとの対話６

安全関連系以外の主機能については、ISO 9001に基づいて開発すればよいと考えますが、業界ごとに品質管理規格を制定しているケースがあるため質問しみました。

質問１：主機能についての品質、信頼性に係る規格

質問２：安全以外の自動車業界と鉄道業界の要件