ISO26262 Part.6 ソフトウェア開発（手法）：自動車分野の機能安全規格「ISO26262」とは何か？（5）（1/2 ページ）

自動車分野向け機能安全規格「ISO26262」のソフトウェア開発（手法）概要

　これまで自動車分野向けの機能安全規格「ISO26262」の概要について解説してきましたが、今回は最終回として、ソフトウェア開発における“手法”にフォーカスし、その内容を紹介したいと思います。

ISO26262の準形式手法、形式手法

　機能安全規格では、要求や設計を「準形式手法」や「形式手法」で記載することがあります。

　ここで使用する準形式手法は、ISO26262FDIS（最終ドラフト）版により、「UML」や「SADT」が推奨されており、汎用性や準形式検証（シミュレーション）を考慮するような場合には、UMLを利用することが多いと考えられます。

　一方のSADTは、次のような図を用いた手法となります。

図1　SADT

　UMLについては他の連載や関連する情報が多く存在するので、本稿では、これまであまり紹介されてこなかった形式手法について解説したいと思います。

実は日本でも実績が多い形式手法

　形式手法というと「Z」「VDM」「SCADE」などが有名ですが、実は日本での適用実績が一番多い形式手法は、通信系の国際規格「ITU-T Z.100 SDL（Specification and Description Language）」（以下、SDL）です。

　SDLは、日本国内でも固定電話や携帯電話の“通信プロトコル開発”に使用されているなど、利用実績が多い形式手法です。少し前の話になりますが、ESEC2002が開催された当時、NECテレコムシステム社（現：NEC通信システム）の公演の中で“1997年より導入されている”と発表されています。また、この公演では、形式検証（SPINの改良版）も併用することで、結合テストまでに“不具合の99％を除去した”と発表されています。

　SDLは、もともと通信系規格として定義されましたが、ソフトウェアに通信機能が必須になってきたこともあり、UML 2.0からはUMLにも取り込まれています。

　また、SDLは携帯電話の3GPP規格書といった通信系の規格書に採用されているだけではなく、車載システムのCAN、FlexRay、OSEKの規格書にも採用されているなど、車載系での採用事例も多い形式手法となります。

SDLの構成

　SDLは、「システム図」「ブロック図」「プロセス図」「プロシージャ図」で構成されており、プロシージャ図以外は、UML 2.xにほぼそのまま取り込まれています。

　UML 1.xでは、状態遷移図以下の詳細処理を記述できなかったり、システム構造をクラス図による階層構造で表現していたため、直感的に分かりづらかったのですが、UML 2.xでSDLが導入されたことによって、状態遷移図での詳細処理を記述できるようになり、システム構造が直感的に分かりやすくなりました。この詳細処理を記述できるようになったことから、UML 2.x以降のUMLツールでは100％のコード自動生成ができるツールも出現してきたのです。

　図の使い方としては、システム図・ブロック図で、抽象度の高いブロックから外部設計をしていくことになります。次に、プロセス図・プロシージャ図で内部設計をするという流れになります。

　以降では、SDL図の概要について説明していきます。

システム図（コンポジットストラクチャ図）

　SDLのシステム図では、システム全体の中に、どのようなブロックが含まれているか、そして外部・ブロック間でどのようなやりとりをするのかを示します。

　MVCモデルやOSI基本参照モデルなどのデザインパターンを採用することで、各階層の役割を明確にし、外部・階層間のイベントのやりとりを定義するように使っていくこととなります。

　このシステム図に含まれるブロックの数とやりとりする通信チャネルの数が多い場合は複雑性が高いということになりますので、ブロックの抽象化を行う必要があります。

　この場合、まずは“外部（ユーザー）”とのやりとりだけをシステム図で記載すると分かりやすくなります。

図2　システム図例

　実際のシステム図を見ることで、クラス図より直感的に中に含まれているブロックを理解できるのではないでしょうか？

ブロック図（コンポジットストラクチャ図）

　SDLのブロック図は、1つのブロックの内部を示しますが、さらにブロックを定義して階層化する場合と、実際に振る舞いがあるプロセス（UML 2.x以降のアクティブクラス）を定義する場合の2種類の使い方があります。

　定義の方法は、システム図と同じで、ブロックに含まれるブロック・プロセスを記述し、これらのイベントのやりとりを定義します。外部とのやりとりは、システム図や1つ上のブロック図に記載されている外部とのやりとりと同じ内容になっている必要があります。

　このブロック図を定義していく段階で、アーキテクチャメトリクスを採用することによって、保守性やテスト性の観点で最適なアーキテクチャを実現できることになります。

図3　ブロック図例