ページナビゲーション
- ページの先頭へ
新しいソフトウェアを、もっと早く。
テスト駆動型開発の自動車アプリケーションへの導入
デジタル化、電動化、接続性、自動運転―。自動車メーカーとサプライヤーは空前のパラダイムシフトの只中に置かれています。バリューチェーンが急速に変化する中で、それに対応できるだけのスピードと柔軟性を既存のイノベーションや開発のプロセスは備えているでしょうか。
今のところ、市場はまだ大手自動車メーカーを中心とした従来通りの開発サイクルを受け入れています。しかし、コンシューマーエレクトロニクスの世界ではそれを凌駕する速さで技術革新が進んでおり、そのスピードを当然と考えるユーザーは増える一方です。実際、自動車会社が今後も存続していくには、かつてないほど激しく変化する市場の中で成果を上げていかねばなりません。
ソフトウェアは製品を差別化するうえでますますその重要性を増しており、自動車の世界でもソフトウェア開発がコアコンピタンスの1つとなりつつあります。テスト駆動型開発（TDD）などのアジャイル開発の手法はソフトウェアの進歩と共に自動車業界にも広がっていますが、その導入は難しさをはらむと同時に、変化に対処するための絶好の機会でもあります。
テスト駆動型開発
コストの削減とコード品質の向上
テスト駆動型開発と他のテストのアプローチとの第一の相違は、テスト駆動型開発ではプログラムコードを書く前にテストの作成が行われる点です。そのため開発者はテストケースを、コードの設計に基づいてではなく、要求とインターフェイスに基づいて検討しなければなりません。
TDDを導入すれば、開発コストの削減、ソフトウェア品質の向上、市場投入時間の短縮といった複数のメリットがプロジェクに期待できます。ヘルシンキ大学が実施した詳しい分析では、ソフトウェア開発のいくつかのカテゴリーでTDDの効果を測定した結果（図1）、TDDが従来の方法よりも有効であることが証明されました[1]。
自動車市場がハードウェアベースの車両からソフトウェア定義自動車へと移行する中、自動車メーカーとそのサプライヤーが業界の要求に対応していくには、品質と（安全性の）コンプライアンスを維持しながら、ソフトウェア開発をスケールアップできる能力が不可欠です。
マッキンゼーによると、自動車開発コストに占めるソフトウェアの割合は2030年までに30%に達すると見込まれます [2]。
この結果、ソフトウェア開発をスケールアップする一方で、コストを低く抑え、品質を高く保つソフトウェア開発の方法論を持つことが極めて重要になります。そしてこの課題に、TDDで対処できるのです。
サイバーフィジカルシステム
複雑なシステムを管理可能なコンポーネントに分解
車両に使われている最新のシステムは、しばしば「サイバーフィジカルシステム（CPS）」と呼ばれます。それは、これらのシステムが何らかの機能を遂行するだけでなく、インターネットにも接続されているためで、これによってOver The Air (OTA) でのソフトウェア更新、予防保全を目的とした車両診断用の接続、実際の使用データに基づくコンポーネントの調査研究の強化などが可能になります。このように、制御システムはシステムのソフトウェアに関連する部分を包含し、そこでは特定の機能が、大きいサブシステムコンポーネントと小さく分解されたソフトウェアコンポーネント（SWC）に分割されて存在していると考えることができます。
このように構造化された形でソフトウェアを設計および開発するアプローチは、モデルベース設計（MBD）などの従来のソフトウェアエンジニアリングの手法に相当します。しかし、自動車業界ではサイズと重量に関する考慮事項が増え、また安全性とセキュリティーのニーズも高まっています。そのため自動車メーカーの特定の要求に応じて、CPS全体とそのサブシステムをSWCというもっと小さい形に分けることも、あるいはそれらを1つのモノリシックなシステムに集約することも珍しくありません。
アーキテクチャーモデルがこのようにCPS間で絶えず変動することから、新しいアーキテクチャーモデルを設計、反復、公開できるツールを使用して、設計を正しく、迅速に、しかも効率よく実施することが非常に重要だといえます。
AUTOSARは、こういったソフトウェアアーキテクチャーを設計するための、自動車業界における標準規格です。ベクターが提供する独自のソフトウェアアーキテクチャー設計ツールには、DaVinci DeveloperとPREEvisionがあります。DaVinci DeveloperはAUTOSARソフトウェアコンポーネントの設計に主眼を置いたツールですが、PREEvisionでは、CANやEthernetなどの通信バスを含むソフトウェアアーキテクチャーを、全体的なシステム設計の一環として設計することができます。生成されるヘッダーファイルと実装テンプレートは、ソフトウェアコンポーネントをコードベースで開発するためのたたき台として使用できます。
テストピラミッド
テストを効率的に分散
トップレベルにシステムアーキテクチャー、低レベルにSWCアーキテクチャーを置くこのアプローチは、テストピラミッドの戦略に非常に適しています。「テストピラミッド」はソフトウェアのテストを粒度が異なるカテゴリーにまとめるための戦略で、ここではAUTOSARソフトウェアコンポーネントの記述ファイルをサービスとAPIのレイヤーに、生成されるヘッダーファイルと実装テンプレートを単体テストのレイヤーに、それぞれマッピングできます。
これらのツールで作成される設計要素は、TDDプロセスに沿って作業を進める際の最初の要求に的確にマッピングできます。TDDでは、プログラマーがソフトウェアプロジェクトのコードを記述する前にテストを作成することに軸足を置きますが、アジャイルのフレームワークと同様に、プロジェクトをそれぞれで成果物のユニットが作成される、小さいイテレーションに分割する必要があります。
TDDのアプローチにおいて、特定の機能やコンポーネントを担当する開発者がまずすることは、これから記述するコードの要求を検証するための自動テストの作成です。このテストは、その機能やコンポーネントで事前に定められている仕様と要求に基づいて作成されます。
初期のソースコードには、所定の機能がまだ実装されていないため、テスト実施時にFailとなります。その後開発者は、このテストにPassするようにコードを実装します。テストにPassすると、開発者はコードが引き続きテストにPassするように注意しながら、コードの「クリーンアップ」を行います。
SWCの開発
VectorCASTによるTDD
VectorCASTを使用している場合は、テストしたいAPIのヘッダーファイルが含まれているディレクトリーを指定するだけでテスト環境を構築できます。これらのヘッダーファイルはDaVinci Developerで生成できます。VectorCASTはスマートスタブ、モックオブジェクト、ドライバーコードが含まれたテスト環境を自動的に作成するため、これによってホストプラットフォームや組込開発環境で実行できる、完全な実行可能テストハーネスが生成できます。しかも特筆すべきことに、VectorCASTは開発サイクルの繰り返しに伴って実装された関数のコードを、その開発が済み次第、自動的にテスト環境に含めてくれます。
さらに詳しい情報については、以下のホワイトペーパーをご覧ください。
CPSの開発
vTESTstudioとCANoeによるTDD
vTESTstudioとCANoeを使用すれば、統合型の多角的な作業環境を構築して、組込システムのテストを開発することができます。CPSのサービスレイヤーやAPIのテスト環境を設定している場合であれば、PREEvisionやDaVinci Developerで生成したAUTOSAR SWC記述ファイルを指定するだけで環境を設定でき、CPSのSWCのパブリックインターフェイスをスティミュレーションするのに必要なすべてのデータが、これらのツールに提供されます。さらに、vTESTstudioを使用すれば、テスターは外部ポートの挙動（インターフェイスの入力メッセージと期待される出力メッセージなど）をモデル化し、CANoeでテストを自動実行することができます。
vTESTstudioとCANoeに新しい機能を追加した場合は、新しいコードの追加のたびにSWCでテストを実行するのと同様にテストを再実行し、SWCがすべての要求を満たす方向に進んでいるか、そして既存の機能が損なわれていないかを確認できます。まだ存在しない他の機能にSWCの挙動が依存している場合は、CANoeを使用し、これら機能をシミュレーションさせることも可能となるため、部門間やサプライヤー間でSWCの開発を並列化、分散させることが出来るようになります。これにはいずれも、事前に合意された設計に基づきPREEvisionで自動生成されたインターフェイスを使用できます。
継続的インテグレーション
VectorCAST/QAによる継続的なインテグレーションとテストワークフローにすべてを統合
継続的インテグレーション（CI）とテストはTDDの重要な要素です。プログラムに変更が生じると、開発者は変更箇所をソースコードリポジトリーに統合（インテグレーション）します（1）。インテグレーションは1日に何度も行われます。CIサーバは変更箇所をフェッチすると（2）、スケジュールに従って自動的にビルド（3）とテスト（4）を実行し、インテグレーションによって生じたエラーをできるだけ迅速に検出します（5）。このアプローチによってインテグレーションに起因する問題が大幅に減少し、プロジェクトチームはよりまとまった形のソフトウェアを、より短時間で開発できるようになります。
VectorCAST/QAは、継続的インテグレーションとテストをサポートするための理想的なツールです。開発チームは、以前に開発したVectorCASTとvTESTstudio/CANoeのテスト環境をリグレッションテストスイートの形にまとめ、そこから単体テスト、統合テスト、機能テストのすべてのアクティビティーを一元管理することができます。このリグレッションテストスイートに含まれる各テストの状態は、一目でわかるログ、要約レポート、色分けされた合格／不合格基準によって簡単に把握することができます。トレンドのレポートを利用して、経時的なテストの進捗を見ることもできます。
まとめ
トレンドは今、ソフトウェアを中心とした車両開発へと向かっています。そしてそれらのシステムの開発コストを低く抑えるには、TDDなどのプロセスが不可欠です。コンセプトからシステム全体のモデリング、そしてソフトウェアコンポーネントへの分解までをカバーする、自動化されたワークフローを作成すれば、サービスレイヤーとユニットレイヤーのAPIを、再利用可能な自動のプロセスを通じて定義できます。
この機能により、テスト対象のコードが存在しなくても、VectorCASTやvTESTstudio/CANoeなどのツールを使用し、要件に基づいてテストケースの仕様策定と作成を開始できます。必要なものは、AUTOSAR System Descriptionを通じて公開されるサービスレイヤー用のAPIと、ユニットレイヤー用のヘッダーファイルのみです。これらのツールはテストケースの自動解析や自動実行にも使用でき、結果の正しさの自動測定も可能です。そのため継続的なインテグレーションとテストのワークフローに非常に適しており、設計仕様の策定から、ソフトウェアの更新ごとの実装の正しさの評価までをカバーする、完全に自動化されたプロセスを実現させることができます。
--------------------
参考資料:
[1] Mäkinen, Simo; Münch, Jürgen: Effects of Test-Driven Development : A Comparative Analysis of Empirical Studies. January 14 - 16, 2014. https://helda.helsinki.fi/handle/10138/42741
[2] Aaron Aboagye, Russell Hensley, Asutosh Padhi and Danish Shafi: Facing digital disruption in mobility as a traditional auto player. December 2017. https://www.mckinsey.com/industries/automotive-and-assembly/our-insights/facing-digital-disruption-in-mobility-as-a-traditional-auto-player
