機能安全編

株式会社制御システム研究所　森本　賢一

2012.04.23
※記事執筆時は、三菱重工業株式会社　原動機事業本部に在籍

（構想設計を支えるRequirement Baseの設計手法）
今回の機能安全のメルマガで繰り返しお話してきたのが、一番最初に行うリスク分析を源流とした安全要求（Safety Function Requirement、Safety Integrity Requirement）をいかに構想設計、ならびにその下流の詳細設計につなげ、実現するかということです。

どんなに立派な要件定義やどんなに豊かな構想設計も、安全要求が背骨のように一貫していなければ、文字通り絵に描いた餅となります。試験段階では最初に定義した要件を一つ一つ実際に試験してゆきますが、詳細設計、実装にいたるまで、要件や設計条件がつながっていなければ、試験段階での後戻りがいくつも出てしまい、開発工程の遅れや開発プロジェクトの費用の拡大を招く要因となってしまいます。

機能安全では、最初に提示した要件、さらに構想設計で示したその実現方法や打ち手を、実際に試験段階でテストします。Fault Insertion Test（故障挿入試験）と称するものです。
メルマガでお話しましたが、個々の電子部品の壊れ方（故障モード）とそれに対する打ち手を設計段階で詳細に分析し（これをFMEDAといいます）、試作が完了した後、実際に中の部品を破壊して分析どおり（設計どおり）の振る舞いとなることを証明してゆきます。この試験には、莫大な試作の費用や手間が掛かりますので、構想設計で計画した部品の故障に対する打ち手は、確実に下流の詳細設計でも実装でも反映されていなければ、とんでもない後戻り（損害）を発生してしまいます。

機能安全規格に準拠する場合以外でも、せっかくの構想設計を現実のものとするためには、安全や品質に関する要件や設計ルールなど、構想設計段階の意図をきちんと後段に伝えてゆき、必要な場合はそれを共有したり、変更することが何より大切です。

このような設計プロセスは、Requirement Base Designと称して、機能安全のみならず様々な分野で広がっています。機能安全と、機械安全を踏まえた、自動車向け安全規格であるISO-26262も、業界の様々な知見をRequirementとして蓄積されていますから、これをきちんと各設計段階が実現していることを証明することが大切です。

System Plannerでは、この仕組みを各CADツールと、要件定義（設計ルール）のデータベースの連携で実現しています。

画像をクリックすると拡大表示します。

＜Circuit DR-Naviによる要件定義管理の画面＞

Circuit DR-Naviで登録した要件や設計ルールは、これまでご紹介したSystem Plannerの各機能のオブジェクトと連携が可能になります。



現在図研さんでは、前述の自動車向け安全規格 ISO-26262をこのCircuit DR-Naviに搭載し、特に自動車向けアプリケーションの開発において、ユーザの利便性向上を図ろうと計画しています。規格書の各Requirement項目を、要件オブジェクトとして構想設計から詳細設計までの各フェーズで共有し適切な設計をすることで、試験段階の後戻りや、開発工程の遅延を防ぐのが狙いです。


（System Plannerへの期待／できれば実現して欲しい機能）
このようなSystem Plannerを活用すれば、システムの品質や安全規格への対応が効率的に行えることが期待できます。現在完成している機能を十分に使いこなすだけでも、豊かな構想設計に向けて大きな一歩が踏み出せそうです。しかしこのメルマガの主題である、機能安全の観点ではやや物足りない部分があります。それはソフトウェアの設計に関する部分です。

（ソフトウェアの構想設計）
これまでのメルマガでお話してきたとおり、構想設計段階ではハードウェア／ソフトウェアに区別をせず、サブシステムを計画することが大切です。上流のリスク分析からの安全要求を、ハードウェアで実現するのか、ソフトウェアの機能でカバーするのかを明確にするためにも、構想設計段階ではハード／ソフトの両方を計画することが大切です。

またPFD、SFFといった指標を目標の値に持ってゆくためには、検知できない危険側故障率（λ_DU）を小さくすることが必要となりますが、そのためにはソフトウェアによる自己診断が必要になってきます。つまり、ハードウェアの計画次第で、ソフトウェアで求められる要件、機能仕様が追加になってきます。

このように、機能安全を達成するシステムを開発する上では、ソフトウェアも構想設計段階で十分に計画する必要が有るのです。

このように考えた場合、ソフトウェアに求められる要件は、ハードウェアの詳細設計段階の部品が決まる段階で初めて決まる可能性もあります。



この図はIEC-61508に出てくる設計プロセスを示している図です。ソフトウェアの開発プロセス（IEC-61508 Part３）に対して、上流のRequirement（要件）からの矢印に加え、構想設計（System Architecture）からも矢印が出ています。（図は赤矢印にしています。）

これはソフトウェアの開発要件は、上流の要件定義からだけではなく、構想設計の結果からも追加されることを示しています。

機能安全を達成するためには、ハード屋とソフト屋が要件定義だけで別れてしまうのではなく、一緒に構想設計を行い適切にソフトウェアの設計要件を抽出する必要が有るのです。

このようなことから、System Plannerには是非ソフトウェアのUMLモデルを記述できる機能を搭載していただき、その上で要件定義やルールのデータベースを連携してもらいたいです。また、ソフトウェアの詳細設計から実装（コーディング）までが、ハードウェアと同じように一貫して繋がるように、設計からコンパイル／リンク、および構成管理（Configuration Management）や、バージョン管理が一元管理できるものを、是非開発していただきたいと願う次第です。

メ ルマガ連載開始時点でも図研に強くお願いしていましたが、現段階でもまだのようです。今の段階でまだ、そのような総合的な構想設計をやろうとしているユーザは多くないとの判断かもしれませんが、日本が価格ではなく付加価値で勝負しなければならない時代、機能安全と無縁な業界でも、ハードウェアとソフトウェアの総合的な構想設計環境は不可欠だと思っています。目の前のニーズを越えて日本のものづくりを変えるぐらいの意気込みで是非実現して欲しいところです。