MBDオートモーティブ

昨今、車載ソフトウェア業界は大きな変革の波に直面しています。特にSDV（Software Defined Vehicle）の登場により、従来のハードウェア中心の開発からソフトウェア中心の開発へのシフトが求められています。この変革は、単なる技術的な進化にとどまらず、製品の付加価値を大きく高める可能性を秘めています。しかし、この新たな潮流に適応するためには、従来の開発手法や考え方を見直し、柔軟かつ効率的なソフトウェア開発が不可欠です。

本記事では、MBD・CI・自動化など品質向上と開発サイクルの短縮を実現するためのヒントをお伝えします。

モデルベース開発を導入することで得られるメリットは大きいが…

今、車載ソフトの開発現場では、MATLAB/Simulinkによるモデルベース開発（以下、MBD）が急速に普及しつつあります。その主な理由は、MBDを導入することで、従来開発に比べて生産性と品質へのメリットが得られる点にあります。

例えば、MBDで使用されるツールであるMATLAB/Simulinkには数多くの部品が用意されており、これらをつなぐことで簡単にモデルを作ることができます。作ったモデルはその場ですぐ動きを確認できるため、モデルで記述した制御仕様の検証が容易になり早期の品質確保が可能となります。

更に、作ったモデルをそのまま実車に持ち込んで動作検証を行ったり、モデルからオートコード（自動コード生成）することにより実装工数を大幅に削減するなど、MBDの導入により多くのメリットを享受することができます。

このようにメリットの大きいモデルベース開発ですが、闇雲に取り組むだけでは以下のような問題が発生してしまいます。

「動かすこと」を重視したモデルでは量産開発や以降の派生開発で問題が…

MATLAB/Simulinkで作成するのは実装を前提とした制御モデルです。一般的なV字プロセスに当てはめると「ソフトウェア詳細設計」で作られるモデルに相当します。そのため、それよりも前の段階で混入した問題については何の手当てもできません。

例えば、要求の段階でどんな問題が混入されていようと、それに応じたモデルを作成することしかできません。要求のヌケモレや矛盾、誤解釈があった場合には、それをそのまま引き継いだモデルが作られます。

また、Simulinkモデルは、先行開発において制御仕様の正しさを確認するために効力を発揮します。しかし「動かすこと」を重視して作られているために、それまでの開発の経緯が残っていなかったり、モデルの構造についてはあまり注意を向けられていないようなケースもあります。

このようなモデルは、量産開発にそれを引き渡してもモデルの意図が汲み取れず理解するのが困難なため、以降の機能追加や派生開発まで考慮すると保守性の面で大きな問題となりえます。

品質向上のための「品質開発」を機能開発と別に行う

これまで述べてきたように、これからは単に動くだけでなく、要求を満たして開発者にとって分かりやすいモデルを作ることが重要になってきます。

このような品質の高い MATLAB/Simulink モデルを開発するためには、先行開発で作られたモデルを元に「要求に合致した（＝妥当性のある）」、「バグのない（＝動作検証済みの）」品質が担保されたモデルを量産開発向けに作成する必要があります。そのためには、下図にあるように、機能開発だけに依存したこれまでの開発のやり方を変え、品質向上のための「品質開発」の活動を行うことが有効です。つまり、正しく「仕様化」した要求を量産品質の構造に「洗練」し、仕様の正しさと実装の正しさを「検証」していくことが必要です。

以降、下図の工程①～⑥の詳細を説明します。

①「要求の可視化/整頓」が品質開発の最初の一歩

Simulinkモデルの保守性を低下させる一因として「要求」が暗黙知であることがあげられます。この状況で開発されたモデルには「仕様」のみが書かれており、機能要求や品質要求、設計制約などが十分に反映されていません。

これを解決するためには、既存の「制御仕様」を「目的」「要求」「仕様（手段）」に分けて段階的に詳細化しながら形式化することが有効です。詳細は、P42にある「要求の定義と仕様化」をご覧ください。このようにして作られた「ヌケモレのない要求と仕様」からは、動作検証のためのテストシナリオを作ります。こうすることで、ISO26262で重視される要求と実装のトレーサビリティも満たすことが出来ます。

②「モデルの整頓」のポイントは「レイヤ」と「ドメイン」による分割

要素技術調査に心血を注ぎ、手段レベルのまま放置されたモデルは、情報をまとめきれず全体的に抽象度が低いため、要素間の入出力関係が複雑で下左図のように処理の複雑化を招きやすくなります。

モデルを整頓する上でうまくアーキテクチャを設計できると、要素間の入出力が簡潔で処理も簡潔になり、各要素の役割も明確で、理解しやすく変更しやすいといったメリットが得られます。

このアーキテクチャ設計のポイントは「レイヤ」と「ドメイン」による分割です。

車両制御ソフトウェアは、抽象度に応じて機能／手段／部品の３つの「レイヤ」に分割できます。

さらにドライバの運転機能に応じて、機能レイヤには「判断」、手段レイヤには「認知」と「操作」、そして部品レイヤには「デバイス」といった「ドメイン」を割り当てることで、互いに疎な構造からなるモデルを構築することが可能になります。

なお、開発対象の規模、最適な設計手法、開発者のスキル等に応じて、他のモデリング言語の併用も有効です。例えば「レイヤ」や「ドメイン」といったレベルでの設計にはUMLの活用が効果的です。

③うまく整頓できているか「モデルメトリクス」で確認

アーキテクチャレベルでモデルを整頓した後は、MATLAB/Simulinkモデルを再構築します。再構築がうまくできているかを確認する際に有効になるのがモデルのメトリクスです。基本的な考え方はコードメトリクスと同じで、ソースコードではなくモデルを静的に解析し、定量的な値を測定します。具体的には、サブシステム上のブロック数、サブシステムの処理の複雑度を計測した経路複雑度、伝播信号の表示率、コメント率などがあります。

メトリクスはソフトウェアの品質と密接な関連性を持つため、メトリクスを評価することで品質上の問題が特定可能になります（下図）。

このように、開発したモデルに対し定期的にメトリクスを測定することにより、

　・品質改善（問題箇所の特定）
　・品質のモニタリング
　　（品質劣化防止、改善効果の可視化）
　・品質のベンチマーキング
　　（品質基準の策定、複数モデルの品質を比較 ）

などを通じて、モデルの品質向上に向けた活動を行うことができます。

このような活動を継続することで、品質低下の検出だけでなく、開発者のモラルを向上させ、品質の高いソフトウェアを作る組織風土にも繋がります。

③④「モデルの単体検証」と「統合テスト」で不具合を除去

シミュレーション検証の自動化がカギ

モデルを作成したら、その正しさを検証するために「モデルの単体検証」を行います。サブシステム単位でシミュレーション検証をすることにより、仕様の不具合を実装前に除去します。また、「統合テスト」ではサブシステム間での協調・連携動作をシミュレーションし、要求を実現できているかどうかシステムレベルで検証します。

ここで気を付けなければならないのは、MBDではツール等を使った検証手段は充実しているのですが、場当たり的にそれらを使っているだけでは十分な成果物が残らないということです。また、テストベクタや報告書をその都度つくるのは非効率的で、ヌケモレも発生しやすくなります。

これらの問題は、MATLAB/Simulinkやカバレッジ計測ツールなどと連携する自動化ツールを導入することで解決できます。テスト仕様書やテストハーネス、テスト結果報告書などの自動生成が可能になることで、再帰テストが楽になり、十分なエビデンスを残すことができます。

具体的な実施手順を説明します。

③「単体検証」でサブシステム単位でのシミュレーション検証を実施

要求仕様書とモデルからテスト仕様書を作成

まず「単体検証」でサブシステムが仕様通りに動作するか検証します。その準備として、テストの内容を示した成果物となるテスト仕様書を作成します。

初めに、テスト対象となるモデルからテスト仕様書のテンプレートと入出力信号名のリストをExcel形式で自動的に生成します。

次に、テストシナリオごとのテストケースとテスト項目を作成します。テストシナリオは要求の仕様化で作成した「要求仕様書」がベースとなります（14ページの「要求の定義と仕様化」をご覧ください）。テストシナリオ別にシートを分け、テストケースとテスト項目、入力値と出力期待値を定義します。

このようにテスト仕様書の入力に要求仕様書を利用することで、ISO26262で重視される要求と実装のトレーサビリティを満たすことができます。

テストの一括実行とテスト結果報告書の自動生成

作成したテスト仕様書からテストハーネス（シミュレーション検証用のモデル）を生成してテストを一括で実行し、その結果をテスト結果報告書として自動生成します。

報告書では、テスト結果をサブシステム単位や要求仕様単位といった観点別に確認することができ、期待値と実出力値が合致しているかどうかを判定して表示します。カバレッジ測定ツールと連携すれば、モデル内やテストシナリオ単位での網羅率を計測し表示することも可能です。

このような自動化によってミスなく効率的なテストが可能となり成果物も確実に残すことができます。

④「統合テスト」でサブシステム横断的なシミュレーション検証を実施

「単体検証」によってサブシステム単体での動作を確認した後は、サブシステム間での協調・連携が要求通りに行われているかどうか「統合テスト」を行い検証します。

作成したそれぞれのサブシステムから、他のサブシステムとの協調動作を行っている部分を抽出して結合し、「単体検証」と同様の手順でシミュレーションを行い結果を確認します。テストシナリオはシステム要求レベルとして、必要であればユースケースシナリオなども入力情報とします。

⑤システムテストとHILSの活用

テスト観点に基づくテスト仕様の作成

シミュレーション検証の後は、ハードウェアとソフトウェアの結合テストやシステムテストを実施します。ここでのテストの目的は「システム要件が正しく実現されていること」の検証です。

テスト仕様の作成では、初めにシステム要件から基本となるテストシナリオを抽出します。このテストシナリオに対し、ISO9126の品質特性や過去不具合事例などから導かれるテスト条件を付加することで、要求定義段階では定義しきれない部分まで網羅的にテストを実施することが可能になります。また、このような観点を用いてテスト仕様の設計を行うことは、ISO26262で要求されるテストフェーズでの作業を実現することにもつながります。

自動テスト環境の構築

HILSにおいても、先に述べた単体検証と同様に自動テスト環境が有用ですが、その構築には工夫が必要になります。

例えば基本のテスト仕様に対してさまざまな車両状態を掛け合わせたテストを実施したい場合、単体検証のようなテスト仕様書ではなく、マトリクス形式でのテスト仕様書が効率的です。また検証結果についても自動での結果判定が適するものとそうでないものがあります。このように、テストの目的や特性に応じたフォーマットに対応できる環境を構築する必要があります。

さらに、プロジェクトごとに自動テスト環境を一から構築することは、コストや運用性の面でデメリットがあり、環境の移植容易性も考慮する必要があります。

このように、HILSの自動テスト環境については、実施したいテストの特性や将来的な展開を考慮して、設計、構築を行うことが肝心です。

⑥MBDにおけるCI（継続的インテグレーション）の導入

ソフトウェア開発において、CI (Continuous Integration) は、効率的なコードのデプロイメントを促進するための重要な手法です。しかし、自動車業界におけるCIの実践には、一般的なソフトウェア開発といくつかの重要な違いがあります。

例えばWeb開発などCIが適用される開発現場では、開発者が自分たちでコードを書き、直接本番環境にデプロイすることができます。これに対して車載開発では、サプライヤと分業して製品を作成することが一般的なので、メーカー内だけで開発プロセスを完結させることができません。

もちろんメーカーとサプライヤとでリポジトリを共有して開発を進められるような柔軟な対応ができる現場では、モデルの作成からHILSでの動作検証までを一貫してCI環境に実装することも可能かもしれません。しかし多くの開発現場では、セキュリティなどの様々な制約により、このような環境を実現することは難しいようです。

そのような場合でも、MBDを採用している現場であれば、メーカー側でモデル単体のテストや、モデルを結合した上でのMILS環境での妥当性検証は可能です。これらをCI環境に実装していくとにより、サプライヤに提示する前にモデルの品質の確保と効率化を図ることができます。

一方、サプライヤでは、CI環境を構築し、インクリメンタルに機能を追加しながらHILS環境でのテストまで行うことも可能です。これにより製品の品質向上と開発サイクルの短縮を実現できます。

いずれの場合においても、CI環境の構築には各種自動化が必須です。自動化が十分でない場合は、まず自動化を行い、それをCI環境に実装していくことが必要です。インターネット上で紹介されているような素晴らしいCI環境を最初から完成させるのは難しいかもしれませんが、自分たちにとって最も効果的な部分から小さく始めていくことで、後に大きな成果につなげることができます。

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

MBD開発支援に関する記事を見る

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

最新コラム