　ティア1サプライヤであるA社の責任範囲はシステム全体です。自動車メーカーと直接契約しており、開発するシステムは機械部品と電子部品で構成されています。ISO 26262の対象である電子システムは、電子部品メーカーのB社に開発を依頼していて、B社はハードウェアとソフトウェアの設計・開発・製造を請け負っています。

　A社は、技術安全要求の仕様までを作成し、ティア2サプライヤであるB社に渡します。B社は、ISO 26262におけるPart4のシステム設計以降の作業とPart5のハードウェア（HW）開発、Part6のソフトウェア（SW）開発を担当します。そして、HW－SW統合テスト、システム統合テストを経てティア1サプライヤのA社に納品するという流れになります。

図1　ティア2サプライヤB社の責任範囲とエンジニアリングプロセス

　B社が行うシステム設計では主に次のようなことを実施します。

システム設計仕様の作成と技術安全要求の配置
システマチック故障への対策
ランダムハードウェア故障への対策
HWとSWへの技術安全要求の割り付け
HW－SWインタフェースの仕様化
システム設計の検証

　システム設計とは、大ざっぱに言えばシステムをどんな構成にして、それぞれの構成要素が何をするのかを決めて、それらをHWが行うのか、SWが行うのかを割り付ける作業です。しかし、「システム設計」というプロセスは、多くの日本企業では存在していないことも多く、具体的にイメージしづらい方もおられるかもしれません。ここでは、機能安全プロセスを構築する上で、幾つか理解して頂きたい重要なポイントについて、少し掘り下げて解説してみたいと思います。

システムという目線

　システム設計は、HW設計者やSW設計者に対し、作業を開始するためのインプットを提供するという、単なる上位要求のつなぎや詳細化の作業ではありません。ここでは、HWもSWも見渡した「システム」という目線で、どのように安全を担保するのかを検討する作業を指します。つまり、上流から受け継いできた「安全コンセプト」を具体化し、設計に落とし込む極めて重要な作業を担うのが「システム設計」なのです。

　もし、B社がシステム全体を担当するのであれば、システム全体の安全コンセプトを設計しなければなりません（図2）。この場合、サブシステムごとにシステム設計が必要になりますし、場合によってはA社が担当した技術安全要求をサブシステム単位で仕様化する必要も出てくるかもしれません。

図2　分散開発の例（クリックで拡大）

　安全コンセプトとは、システム全体の目線で「合理的な安全方策を決定する」ことを言います。従って、開発フェーズの進行に合わせて引き継がれて行くものです。システム設計段階での安全コンセプトとは、システム構成要素の故障によって危険に至ることがない（安全目標を侵害しない）ように、適切な安全機構（故障診断や安全側への制御など）をシステム内に配置することであろうと思います。

　重要なことは、システム全体で手分けして、どのように合理的に安全を担保するかということですから、必ずしも全てのシステム構成要素（例えばサブシステム）が安全機構を持たなければならない訳ではありません。こうした設計方針的な要素を含むので「安全コンセプト」という言い方をしているのだと思います。つまり、単なる要求の配置ではなく、安全に対する方針を踏まえた上での要求の配置と理解すべきでしょう。

　このように考えると、HW開発、SW開発をすり合わせによって開発し、結果としてシステムができ上がるようなボトムアップ的な開発だけでは安全コンセプトは作れません。やはり、システム目線からの最適化というトップダウン的なアプローチも取り入れる必要が出てきます。

　とはいえ、組織規模の小さい中小のサプライヤでは、システム担当という役割自体が存在しない場合もあるでしょう。また、「安全コンセプト」といった抽象的な概念はなかなか理解されないという課題もあるでしょう。当面は、HW設計者やSW設計者が、システム担当を兼務するという形でもよいかもしれません。大切なのは、システム目線を持つことでよりよい設計をすることに尽きると思います。

　今後ますます複雑化するシステム作りの観点からも、そして説明責任という観点からも、さらには後継者育成という観点からも、現状の「システム設計」は日本のメーカーの抱える「弱み」であるという議論があります。この点を克服するためにも、機能安全の導入を社内の設計プロセスや役割分担を見直すきっかけにして頂くのが良いのではないかと思っています。

設計アプローチ

　　　　　　 1|2|3 次のページへ