日経テクノロジーonline SPECIAL

【テュフ ラインランド ジャパン】車載ソフト開発をISO 26262で効率化、上流工程を強化してテストを短縮する

ISO 26262をはじめとする機能安全の認証で多くの実績を誇るテュフ ラインランドは、2014年11月25日に開催された「Automotive Technology Forum 2014 autumn」で、「ISO 26262の適用による車載ソフトウェアのテストの効率化」と題して講演した。ISO 26262はV字開発モデルを対象とした設計プロセスおよびテストプロセスの確立に有効との見方を示し、開発規模が増大する車載ソフトウェアの開発効率向上と品質確保のためにISO 26262の導入と活用を提案した。

本多 克三氏
テュフ ラインランド ジャパン
運輸交通部 機能安全
シニアスペシャリスト

テュフ ラインランドは安全試験や認証などのサービスを提供する第三者認証機関で、ドイツのケルン市に本社を置く。機能安全についてはISO 26262やIEC 61508などの諸規格の認証サービスやコンサルティングを実施中であり、今回の講演では、ISO 26262の観点から、車載ソフトウェアの効率的な開発とテストについて取り上げた。

本多氏ははじめに、車載ソフトの開発規模が増大している現在においては、ソフトウェアのテスト漏れをなくすとともにテスト時間の短縮を図ることが重要であり、開発の上流工程でテスト効率を考慮した対策をとる必要があると欧州での事例をまじえて指摘した。とくに、ソフトウェアエンジニアの機能安全への責任は重くなってきており、欧州では、重大な責任を問われた事例もあると言う。

ソフトウェア開発の上流を考えるための具体的な方策として、本多氏はISO 26262の活用を提案した。その理由として、ISO 26262は、単に合否を判定する規格ではなく、ソフトウェアの開発からテストの完了に至る一連のプロセスを定めた規格であることを挙げた。「法規制にもとづいたパス・フェイルの規格適用だけでは自動車のリコールが減らないということで、やはりプロセスを押さえなければダメだという流れが欧州で起きている」(本多氏)。

V字開発モデルを前提としたISO 26262

続いて、ISO 26262の概要を説明した。規格は全部で10のパートで構成されており、そのうち、コンセプトフェーズを定めたパート3、システムレベルでの開発を定めたパート4、ハードウェアレベルでの開発を定めたパート5およびソフトウェアレベルでの開発を定めたパート6がソフトウェア開発に該当する。

ISO 26262の適用ではASIL(Automotive Safety Integrity Level)の決定が必要になる。そのためのハザード分析とリスクアセスメントを実施するため、車両がなんらかの状況に遭遇する「暴露確率」(E)、危害レベル(負傷度合い)を表す「シビアリティ」(S )、危険回避時の操作性を表す「コントローラビリティ」(C)という3項目から、開発するソフトウェアのASILを分類していく。

該当するASIL分類に従って最上位の安全要求となる「安全目標」を定めたのち、機能安全要求と技術安全要求を順次具体化し、開発やテストを進めていかなければならないと述べた(図1)。また、すべてのプロセスにおいて、上流から下流を辿るトレーサビリティと、下流から上流を辿るトレーサビリティの両方が重要と指摘した。その理由として、トレーサビリティが実現されると、変更などに際してテスト範囲を明確化できることに加えて、問題が発生した時に説明責任を果たせることなどを挙げた。

図1 安全要求の構造とトレーサビリティ
[画像のクリックで拡大表示]

また、ISO 26262ではソフトウェアの開発を「V字開発モデル」で行うことを推奨している。品質を作りこんでいくという観点から、パート6.6で規定される「ソフトウェア安全要求仕様作成」と、パート6.7で規定される「ソフトウェアアーキテクチャ設計」がとくに重要になる。「設計原則に則った設計と検証を繰り返して、V字開発モデルの左側に相当する上流の段階でいいソフトウェアを作るように努めれば、結果的にテスト工数を大幅に削減できる」(本多氏)。

実際にソフトウェアに起因する障害の大半が開発の初期フェーズで発生しているといった業界の経験則を挙げ、テストを予定期間内に終わらせるためにも上流での対策が重要であると強調した。

ASIL分類ごとに行うべき項目を規定

具体的な手順として、モデリングおよびコーディングのガイドラインを定めたパート6の表1を取り上げた(図2)。表1では、ソフトウェアのASIL分類ごとに、「低複雑性の厳守」、「言語サブセットの使用」、「強い型付けの厳守」、「命名規則の使用」などの項目に対し、「強く推奨」を定めている。ASILが上位ほど「強く推奨」に指定される項目は当然ながら多くなる。

図2 ISO 26262のパート6 表1で規定されるモデリングとコーディングのガイドライン
[画像のクリックで拡大表示]

このうち「低複雑性の厳守」については「McCabeのサイクロマチック数」のようなソフトウェアメトリック(指標)を取り入れて定量化し、あまりにも複雑な構造の場合はソフトウェア全体を作り直すなどの思いきった判断が必要になると指摘した。

次のパート6の表2で規定するのが、安全要求の検証方法である。「ソフトウェアの安全要求がきちんとソフトウェアアーキテクチャとして構築されていれば、その後の作業が効率化できる」(本多氏)。具体的には準形式手法(UML)などで記述し、その後、パート6の表2にもとづいてアーキテクチャの検証を行う。

ソフトウェアアーキテクチャ設計の原則(表3)としては、コンポーネントの階層構造化、コンポーネントサイズやインタフェースサイズの制限化、凝集度の向上など、設計に当たって順守すべき事項がASIL分類ごとに規定されている。

また、上述の設計原則にもとづいて設計したアーキテクチャの検証についても、パート6の表6で規定されている。ソフトウェア安全要求の順守や対象ハードウェアとの互換性も重要な検証対象であり、具体的な手法としては、設計のインスペクションや制御フロー分析、データフロー分析の実施が推奨されている。

工程のプロセス化で機能安全を実現

アーキテクチャ設計の次がソフトウェアのユニット設計だが、達成すべき特性としては、一貫性、複雑さの回避、テスト容易性などが挙げられる。また、ISO 26262では、ユニット設計に関してモデルベース開発を強く推奨している。

ソフトウェアユニットの設計および実装に関する設計原則をまとめたものが表8にあるが、サブプログラムや関数での単一の入口と出口、変数の初期値化、グローバル変数の回避などが設計手法として挙げられている。ASIL分類によらず、ほとんどが「強く推奨」に指定されていることもあり、本多氏は「MISRA-Cのような、よく知られた設計ガイドラインの適用を規格も推奨しているので、これを活用するといいのではないか」と提唱した。

続くパート6の表9では、ソフトウェアユニットの設計および実装の検証方法がまとめられている。ツールを利用して静的なコード分析を実行し、タングルやローカルハブなどのアンチパターン(設計上好ましくない構造)を洗い出すなどの工夫も必要だという。

ソフトウェアのユニットテストの手法を規定しているのがパート6の表10である。ソフトウェアユニット仕様を満足するとともに、望まれていない機能が含まれていないことを証明しなければならない。合わせて、「作成したテストケースが100%パスした時点でソフトウェアが100%正しいと判断できるようにするため、テストケースの作成が重要になる」と本多氏は述べ、テストケースの導出方法を規定したパート6表11の活用も推奨した。とくに同値クラスや境界値などを分析し、その結果をテストケースに反映する必要性を強調した。

本多氏は最後にまとめとして、ISO 26262の規格を上手に活用しながら、設計原則にもとづいて設計し、設計が終わったら検証する、という一連の繰り返しを、一回だけで終わらせずにプロセスとして定義し、かつ開発者間で共有・定着を図ることで、車載ソフトウェアのテスト効率向上と品質確保に努めて欲しいと呼びかけた。

お問い合わせ
  • テュフ ラインランド ジャパン株式会社


    〒222-0033 横浜市港北区新横浜 3-19-5
    新横浜第二センタービル
    TEL:045-470-1860
    FAX:045-473-5221
    URL:http://www.jpn.tuv.com