モデルベース開発（MBD）は、従来のC言語やアセンブリによるコーディングとは異なり、人間の認知プロセスに沿った形で自動車ソフトウェア工学を変革しました。MBDは“左シフト”アプローチを可能にし、開発初期段階で問題を発見することでコスト削減を実現します。本ブログ記事では、モデルベース開発アプローチを採用すべき3つの理由をまとめています。
理由その1：抽象度が高い
初期の頃、ソフトウェアはアセンブリのような低水準言語で記述されていましたが、ソフトウェアの複雑性が増すにつれて、エンジニアたちはより高い抽象度を求めるようになりました。そこで登場したのがC言語です。エンジニアはCコードを記述し、それをコンパイラでアセンブリコードに変換して使用していました。しかし、複雑性はそれだけでは終わりませんでした。エンジニアたちは、人間の脳にさらに近く、より視覚的な手法を必要としていました。
統一モデリング言語（UML）は、再利用性、構成管理、品質、アーキテクチャといった優れた特長を備え、1997年にオブジェクト指向手法の集大成として登場し、モデルベース開発（MBD）に貢献しました。モデルベースのソフトウェア開発およびシステムエンジニアリングのアプローチでは、機械可読なモデルを通じてシステム設計と解析を支援するグラフィカルなモデリング言語などの技術が活用されています。
抽象度のレベルは時代とともにどのように変化してきたのか？
モデルベース開発（MBD）はV字開発モデルに基づいたソフトウェア手法であり、初期の頃はモデルをコードの可視化手段として使用していました。コードに変更を加えた場合、それをエンジニアが理解できるように、モデルにも慎重に反映させる必要がありました。
その後、モデルとコードの間で双方向の同期（ラウンドトリップエンジニアリング）が可能となり、コードとモデルの両方の管理が求められるようになりました。さらに開発はモデル中心へと進化し、ユーザーはモデルから自動的にコードを生成するようになりました。
理由その2：モデリングとテスト ― 分割して攻略（Divide & Conquer）
組込みソフトウェア開発の分野で、開発プロセス全体を熟知しているエンジニアを見つけるのは困難な課題です。モデルベース開発（MBD）は、「分割して攻略（Divide & Conquer）」のアプローチを可能にします。ドメインの専門家は自らの知識を活かしてモデルの開発に専念でき、一方でソフトウェアエンジニアはそのモデルを実行可能なコードへと変換する役割を担います。この役割分担こそが、開発効率の鍵となります。
自動車システムの機能安全規格であるISO 26262も、このDivide & Conquerアプローチを通じて、より迅速な開発を支援しています。その方法はいくつかあります：
モジュール開発：
ISO 26262は、階層的なシステム分解を推奨しており、安全関連機能をより小さく管理しやすいコンポーネントに分割します。これにより、異なるチームが明確に定義されたモジュールを並行して開発できるようになり、ボトルネックを減らし、開発スピードを向上させます。
要求ベースの開発と再利用：
ISO 26262は、要求、設計、テストの間のトレーサビリティ（追跡可能性）を義務付けています。この構造化されたアプローチにより、認証済みコンポーネントの再利用が可能となり、後続プロジェクトの開発時間を大幅に短縮できます。
独立して検証可能なコンポーネント：
この規格では、ソフトウェアモジュール間の安全性における独立性を明確に求めています。これにより、各チームがモジュールを個別に開発・検証できるようになり、インターフェースと安全要件が満たされている限り、変更時の手戻りを最小限に抑えることができます。
モデル中心の開発と自動コード生成への移行により、構造化された検証ステージが導入されました。
- MIL（Model-in-the-Loop）：モデルレベルで機能を検証します。
- SIL（Software-in-the-Loop）：生成されたコードをシミュレーション環境でテストします。
- PIL（Processor-in-the-Loop）：ターゲットプロセッサ上での正しい実行を確認します。
モデルベース開発（MBD）の文脈において、ISO 26262はモデルベーステストおよびバック・トゥ・バックテストに対応しています。特にセクション9.4.5では、モデルレベルでのソフトウェアユニットテストの実施と、その後にモデルとオブジェクトコード間のバック・トゥ・バック比較を推奨しています。
バック・トゥ・バックテストは、生成されたコードが高レベルのモデルと一貫した動作をすることを確認するための一般的な手法です。これは、同一の入力条件下でモデルシミュレーションの出力とコンパイルされたコードの出力を比較することで行われます。
この標準ではバック・トゥ・バックテストを義務付けてはいませんが、この手法は、ソフトウェアの設計と実装が要求仕様を満たしていることを検証するという標準の目的に合致しています。
Wolfgang Meincke氏のこのブログ記事では、「モデルのみをテストすべきか、コードも含めてテストすべきか」というテーマについてさらに深く掘り下げています。
理由その3：シフトレフト ― 早期に失敗し、安価に対処するアプローチ
現在、SDV（ソフトウェア定義車両）など急速に進化する自動車業界において、従来のV字モデルのような開発手法は大きな課題に直面しています。これらの手法は安定しており、これまでに大きな成果を上げてきましたが、ソフトウェアの提供スピードが市場の変化に追いついていないのが現状です。
V字モデルに従った自動車ソフトウェア開発には、現在次の3つの課題があります：
- テストケースの定義が手作業であり、非常に時間がかかること
- テストが開発ライフサイクルの後半で行われるため、テスト範囲が限られ、問題が見つかっても修正が困難になること
- ターゲットシステム上で例外や障害が発生しているかどうかの判断が難しいこと
これらの課題を克服するための手法の一つが、Vモデルにおける「シフトレフト（Shift Left）」です。シフトレフトの概念はシンプルで、テストや検証のフェーズを開発ライフサイクルの初期段階に移行するというものです。
従来のテスト戦略では、バグはソフトウェア開発の後半段階で検出されます。
一方で、テストを左側（開発初期）にシフトした場合、状況は大きく異なります。バグが最も多く導入されるのは依然としてコーディング段階ですが、それらを修正するコストの増加傾向も同様です。しかし、バグの検出を示すグレーの曲線は、コストが低い側で大きく、コストが高い側では小さくなっており、その結果として全体のコストが大幅に削減されていることがわかります。
シフトレフトテストアプローチを採用することで、バグは修正コストが低い開発初期の段階で特定されます。
結論
このブログ記事では、モデルベース開発（MBD）が自動車用組込みソフトウェア開発に最適な選択肢である3つの理由をまとめています。
記事では、MBDが「分割して攻略（Divide-and-Conquer）」のアプローチを活用し、アジャイルな開発プロセスにおいて迅速なイテレーションを可能にする利点に注目しています。
また、V字モデルにおける「シフトレフト（Shift-Left）」とMBDを組み合わせることで、開発ライフサイクル全体のコスト削減が可能になることについてもまとめられています。
