コンセプトフェーズで行うこと

「ISO26262」 Part3 のコンセプトフェーズでは、対象の製品を理解し、製品のハザードの識別や発生しうる危害を検討、安全を確保するための方針を決定するといったことを行います。

この段階では製品のアーキテクチャや詳細設計が決まっていないため、個々の部品の故障や、安全を確保する技術といった具体的なことは考慮せず、あくまで車両レベルの挙動を検討する必要があります。

抽象的な思考が求められる

つまり、コンセプトフェーズでは、製品の構成要素や製品に発生する故障を論理的、抽象的に捉えた上で、危険な事象や安全を確保するための方針を検討することになります。

例えば「アクセルポジションセンサの入力信号が実際よりも大きい値になる」と考えるのではなく「ドライバ要求加速度を実際よりも大きく認識する」というように考えることで、アクセルペダルによって要求される加速だけでなく、クルーズコントロール時のようにアクセルペダルを操作しない場合の加速についても包括的に検討できるようになります。

しかし、ものごとを具現化する設計・実装のような作業に慣れている人は、抽象的に思考することが苦手な場合があるので、抽象的にものごとを捉えるための訓練が必要になってきます。

トップダウンのアプローチになる

他者に対して、安全面を十分に考慮して開発したことを示したり、その組織が「機能安全」を考慮した開発を行える能力があることを示したりするためには、その根拠を論理的に説明できる必要があります。そのため、「ISO26262」 でも上流工程で決めた安全要求を設計、実装まで落としていくというトップダウンでの開発方法が規定されています。

一方、開発現場では、具体的な仕様を検討する中で安全機能を検討していくようなすり合わせ型の開発が行われている場合が多く、上流工程の成果物を作成できていないために、安全性の根拠を十分に示せないことが懸念されます。

組織に合った開発プロセスを定義する

「ISO26262」では、Part4 からPart6 でシステム開発、ハードウェア開発、ソフトウェア開発で実施すべきことが規定されており、Part8で構成管理や変更管理、検証といった支援系のプロセスに関することが規定されています。

しかし、ただ規格に規定された内容に合わせてプロセスを定義すればよいわけではなく、そのプロセスに従うことで開発がより良くなることが大事です。

また、「ISO26262」に従うために既存の開発方法を大きく変えてしまいたくなるかもしれませんが、それでは開発が回らなくなってしまうため、既存の開発方法で良い部分はそのまま流用し、不足している点や改善の必要な作業を検討することが賢明です。

プロセスに従った開発を行うには

開発プロセスは開発者が行うべき作業の手順を表したものですので、自分が行うべき作業をどのように行うかを理解するためにも開発者自身で考えるべきです。自分で決めた開発プロセスなら、その作業の意図や目的を理解しているため、そのプロセスに問題点があることが分かれば継続的に改善することができ、形骸化しにくくなります。

また、プロセス検討の専任チームが開発組織の標準プロセスを定義する場合であってでも、対象のプロジェクトに合うように標準プロセスを修正（テーラリング）するのは作業を担当する開発者自身が行う方が、プロセスに対する理解が深まり、プロセスに沿った開発も行いやすくなります。

成果物の品質を向上する機会と捉える

規格では成果物に含むべき情報や品質に関する規定が記載されています。システム開発やソフトウェア開発に限っても要求仕様書やアーキテクチャ設計書など様々な成果物を作成しなければなりません。しかし、規格に書かれているから作らなければならないというスタンスではなく、開発の質を高めたり手戻りを減らしたりするためにはどのような成果物を作るべきか、という観点を持つことが必要です。

ここでは、システムおよびソフトウェア開発における成果物の品質を向上するための情報をいくつかご紹介します。

システムアーキテクチャ関連成果物

システムアーキテクチャを構築する際には、システム要件を正しく定義し、その後、論理アーキテクチャ・物理アーキテクチャを構築します。

システムアーキテクチャ構築のプロセスおよび成果物については「システムアーキテクチャ」をご参照ください。

ソフトウェア要求仕様書

要求を正しく把握して定義するには、「USDM」のように要求を階層化して表現する手法が有効です。階層的に定義することが、成果物間のトレーサビリティ確保の最初のステップとなります。

要求や仕様をどのように定義すればよいかは「要求の定義と仕様化」をご参照くだ さい。

ソフトウェアアーキテクチャ設計

アーキテクチャ設計では、ソフトウェアコンポーネントの凝集度や結合度といった一般的なソフトウェアの設計品質が重視されます。これを実現するためには、UMLのようなモデリング技術も有効な解のひとつです。

「MBD開発支援」の記事にもアーキテクチャ設計のポイントが書かれていますのでご参照ください 。

ソフトウェア詳細設計

最近ではMATLAB／Simulink を活用したモデルベース開発が行われることも多くなってきていますが、MATLAB／Simulink モデルに関しても、品質を意識して開発することで、保守しやすいものにすることが今後の開発効率を上げるためには重要です。

詳細設計に関しても「MBD開発支援」の詳細設計のポイントに書かれています。

安全が実現されているか検証する

安全に関する要求が正しく実現されているかを確認するためには、設計レビューや開発されたシステムのテストを行う必要があります。品質を確保するためには充分なレビューやテストを実施しなければなりませんが、非常に多くの工数がかかってしまうので効率よく行える仕組みが必要になります。

ソースコードに対するテストは既存のテストツールを用いて自動化することができます。また、「モデルベース開発」の場合でもシミュレーション検証を自動化するツールを導入することで、テストを効率化することができます。

「トレーサビリティ」が重視される

製品が安全であることを示すためには、決定した安全に関する方針が製品の設計、実装に正しく反映されている必要があります。

しかし、これを確認するためには、機能安全規格・ISO26262に基づいた成果物の「トレーサビリティ」を確保できるように、要求管理ツールや設計のモデリングツール、構成管理ツールなど開発のライフサイクルを管理するためのツールが必須であると言われてい ます。

ただし、ツールをそのまま導入するだけでは、定義した開発プロセスに合わない部分も多く、思ったような効果が得られないので、開発プロセスに合うようにツールをカスタマイズすることを検討しなければなりません。

コンサルタントが教える成功の秘訣

機能安全 関連コラム

「機能安全」対応支援に関する記事を見る

他のソリューションを見る

最新コラム