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

自動車分野向けの機能安全規格「ISO26262」。今回は、国内でも実施されており、比較的プロセス改善に着手しやすいISO26262の“ソフトウェア開発”について詳しく解説する。

[河野喜一（NEC コンサルティング事業部），＠IT MONOist]

　前回「あらためて『ISO26262』の全体像を把握しておこう」の予告通り、今回は“ISO26262のソフトウェア開発”について紹介します。

自動車機能安全規格「ISO26262」のソフトウェア開発概要

ソフトウェアの安全とは何か？

――そもそも、“ソフトウェアの安全”とは何でしょうか？

　開発者によっては、「ソフトウェアの安全といえば、“品質”のことだ!!」と誤解される方もいますが、品質というよりは、“誤操作（入力）によって誤動作（出力）をさせないフェイルセーフや、制御中に故障しても徐々に制御を停止するといったフェイルソフトの概念”になります。

　機能安全規格では、安全レベルに従って、フェイルセーフやフェイルソフトの具体的な手法を適用することが要求されます。

	関連記事：
⇒	いまさら聞けない 機能安全入門

ISO26262のソフトウェア開発概要

　「ISO26262」のソフトウェア開発では、システム設計書の内容をソフトウェア要求に置き換え、ソフトウェアアーキテクチャを検討した後、ソフトウェア単体設計＆コーディングを実施します。

　開発後は、単体テスト、結合テストを経て、ソフトウェア安全要求検証を実施することで、ソフトウェアに不具合が含まれていないことを保証します。

　各工程には、安全レベルに従って採用する手法が定義されており、安全レベルが高ければ高いほどさまざまな種類のフェイルセーフやフェイルソフトの実装が要求され、形式手法・形式検証（注1）といった最先端の技術も要求されます。

※注1：本連載では、「Formal Notation」のことを形式手法と呼び、「Formal Verification」のことを形式検証と翻訳しています。

　しかし、ISO26262で定義されている内容は必要最低限の要求ですので、実開発では、品質特性やさらなる安全性を考慮した設計が推奨されます。

図1　ソフトウェア開発プロセス

	関連記事：
⇒	いまさら聞けない 形式手法入門
⇒	連載記事「誰でも使える形式手法」

事前に準備すること

　ISO26262のソフトウェアレベルでは、事前準備として、開発言語の評価基準を策定して、開発言語を選択します。例えば、コーディング規約で有名なMISRA-Cのように、曖昧性や誤解を招きやすいC言語よりは、Ada言語を利用するといったことが挙げられます。

　同様に開発ツールを選択＆ツール認定を行い、次の5つの手順書を作成します。

• プロセス定義書
• 開発手法適用ガイドライン
• 設計ガイドライン
• コーディング規約
• 開発ツールの操作マニュアル

　上記の準備が終わり、ソフトウェア開発を開始する際には、開発規模や開発難易度に従ってソフトウェア開発プロセスを調整（統合・分解）し、開発計画を策定します。

安全要求定義

　日本の自動車業界では、あまりソフトウェアの要求定義を実施せずに、システム開発の成果物であるシステム設計書から直接ソフトウェアの開発を開始してしまう傾向があります。しかし、システム設計書の内容は、あくまでもシステムレベルであり、ソフトウェアの世界の要求は記載されていません。

　このため、システム設計書を基にして、ソフトウェアの安全要求を定義します。システム設計書の動作シナリオや非機能要求を、演算処理を高速化するための変数のスケーリング、コンピュータの丸め誤差などを考慮してソフトウェア視点で再定義することや、OSやミドルウェアなどの要求を定義します。ISO26262では、異常を検出して制御することや、通知する要求が重要となります。

　また、安全要求定義では、安全レベルに従って表記法が指定されており、SysML／UMLといった準形式手法やテキストベースのVDM-SL（ISO/IEC 13817-1）、モデルベースのSDL（ITU-T Z.100）、Lustreといった形式手法による記述が必要になることもあります。自動車業界では、CAN／Flex Ray、OSEKなどの標準規格書がモデルベースの形式手法SDLで記述されています。

図2　UML、SysML図の例

　安全要求定義を行った後は、安全レベルに従ってレビューやシミュレーションを実施して要求の不具合やヌケ・モレを検出します。安全レベルによっては、不具合が発生しないことを公式によって証明することや、数学的に証明する手法である形式検証が要求される場合もあります。

	関連記事：
⇒	連載記事「組み込み開発にUMLを活用しよう」
⇒	モデリング言語 SysMLを概観する
⇒	連載記事「車載ネットワーク“CANの仕組み”教えます」
⇒	連載記事「次世代車載ネットワーク FlexRay入門」

アーキテクチャ設計

　実際の開発は、既存アーキテクチャの修正や流用であり、あまりアーキテクチャ設計を実施しないこともありますが、機能の追加・修正のしやすいアーキテクチャを検討しておかないと、他の人が修正できないブラックボックスとなってしまいます。

　ISO26262のアーキテクチャ設計では、全てのソフトウェア要求をコンポーネントという単位に割り当て、機能統合や機能分割を実施してソフトウェアのアーキテクチャを設計し、コンポーネントごとに外部I/F、動作シナリオ、動作状態を定義します。特に、ISO26262では、通信相手から応答がなくなった場合や異常メッセージが送られてきた場合の処理も検討する必要があります。

　コンポーネント定義後は、コンポーネントを新規開発するのか、既存のコンポーネントを流用するのか、市販のコンポーネント（OS、ミドルウェアなど）を購入するのかという検討も行います。

　アーキテクチャ設計でも安全レベルに従って表記法が指定されており、SysML／UML／MATLAB/Simulinkといった準形式手法やVDM-SL、SDL、Lustreといった形式手法による記述が必要になることもあります。

　このアーキテクチャ設計の際に、アーキテクチャ内の機能をどのCPUに配置するかの検討を行うことで、複数機能を1つのECUに統合していくことになります。

　日本では先にECUを決めてソフトウェアを載せていくことが多いのですが、欧州ではソフトウェアのメモリや処理速度の予測を行った後に、ECUに振り分けていきます。この手法を取り入れることによって、ECUにソフトウェアを実装した後で「処理速度が要求に満たない」「メモリが足りない」などといった問題が発生することを防止できます。

　アーキテクチャ設計を行った後は、安全レベルに従ってレビューやシミュレーションを実施して、機能間の状態組み合わせで異常が発生しないこと、および、機能間I/Fに誤りやヌケ・モレがないことも確認します。安全レベルによっては、不具合が発生しないことを公式によって証明することや、数学的に証明する手法である形式検証が要求される場合もあります。