SDVは、Over-the-airでのアップデートにより車両のライフサイクル全体にわたって性能が強化されることを前提に設計されます。最新のクラウドベースの可視化技術により、シリコンが入手可能になる前や自動車が実際に路上で走行し始めた後でも、開発を行うことが可能になりました。
組込みシステムのソフトウェアおよびハードウェアは、多くの場合、非常に複雑に相互接続されています。開発者は、限られたリソースや厳格な納期といった制約の中で、完璧な統合を確保することが求められます。これが、デバイス上でテストを繰り返すことにつながっています。
こういったアプローチは、製品開発ライフサイクルの迅速化には効果的でなく、またサービス主導型ビジネス・モデルの需要にも相反します。車載OEM各社は、保守作業時のみに実施されることが多い重大または限定的なファームウェア・アップデートに代わるものとして、車両のライフタイム全体にわたって性能が進化および強化されることを前提に設計されるソフトウェア・デファインド・ビークル (SDV) の概念を積極的に受け入れています。
SDVを実現するには、プラットフォーム・アプローチが不可欠です。ハードウェアとソフトウェアをデカップリング（分離）することで、アプリケーションおよびアーキテクチャの設計の柔軟性が高まるうえ、経時的に機能を追加することも可能になります。デカップリングは、プラットフォーム間で最低限の適応を行うのみでさまざまな車両にわたってソフトウェアを再利用できるようにします。また、車両の所有者にも、安全性や車両の信頼性の向上、さらにはエネルギー消費の削減といったメリットをもたらします。
このアプローチによって、車両のソフトウェア開発が抜本的に変わります。まず、業界が「シフト・レフト」へと向かいます。これは、プロトタイプのハードウェアがなくても、製品開発ライフサイクルの早期段階でソフトウェアの開発が完了することを指します。さらに、業界は「ストレッチ・ライト」にも向かいます。これは、車両の販売後でもアップデートが可能であることを指します。これにより、車両のライフタイム全体にわたってOver-the-air (OTA) で機能を追加でき、また所有者が変わっても車両に長く乗り続けられるようになることから、クラウドベースのサービスによってOEM各社にとって新たな収益の流れが生まれる可能性があります。
シフト・レフト、ストレッチ・ライトの図
継続的インテグレーション/継続的デプロイメントの構築
継続的インテグレーション/継続的デプロイメントは、長年にわたり多くの企業によって取り入れられてきた実績のある概念です。「シフト・レフト」と「ストレッチ・ライト」はその次の論理ステップであり、開発チームが正しいソフトウェア開発手法を選択した場合には、両方の要件が概ね一致します。
SDVは、他の組込みシステムと同様に、基盤となるハードウェアからソフトウェア・モジュールを隔離して抽象化できる、可視化やソフトウェア・コンテナなどのテクノロジをサポートしています。このアプローチの利点としては、付加価値の高い多くのサービスに向けて、クラウドベースのプロセスを早期に統合できる点が挙げられます。これらのサービスでは、車のコア能力と人工知能 (AI) およびクラウドベースの分析がしばしば融合されます。
組込みシステムにとって核となる変化は、物理的なハードウェア上でのプロトタイピングが不要になるか、あるいは少なくともタイミングやハードウェアの動作に関する仮定が現実的であることを確認できる必要最小限にまで減らせることです。ただし、組込みスペースには追加のコンポーネントが必要になります。
仮想化とシミュレーションによる開発の促進
コンテナ化は、クラウド環境に継続的インテグレーション/継続的デプロイメント手法を導入する際の重要な要素であり、アプリケーションとハードウェアの依存関係を低減します。アプリケーションは、テストに用いられるサポート・ライブラリやデバイス・ドライバとともにパッケージ化でき、基盤となるOSから隔離されます。組込み環境では、さらなる隔離と保護が必要であり、これは仮想化によって実現されます。仮想化では、ハイパーバイザがI/Oメッセージを基盤となるハードウェアにマッピングします。ハイパーバイザによる仮想プラットフォームの管理は、同じプロセッサ・コンプレックスで実行される機能的に別個の各タスクをセキュアに隔離する際にも役立ちます。
コンテナ化は、柔軟性ならびにOEMによるアップデートのデプロイ能力を大きく向上させます。これは、車室内のインフォテイメント・モジュールなど、システム内でOTAアップデートが頻繁に行われる可能性が高い箇所にとって特に有益です。そのような分離がさらに進んでいく一方で、ハードウェアのインターフェースおよび依存関係は、自動車のリアルタイム制御およびセーフティ・システムの機能性にとって極めて重要であり続けます。開発者は、ハードウェアの変更がソフトウェアに与える影響を確認する必要があり、デジタル・ツインがその解決策となります。
デジタル・ツインとは、ハードウェアとファームウェアの動作を再現した仮想モデルです。デジタル・ツインを使用すると、開発者はほとんどのテストの実施時においてハードウェアにアクセスする必要がなくなります。デジタル・ツインは、デスクトップ・ツールやクラウドベースのコンテナを使用し、対話型デバッグ・モードまたは高度に自動化された一連の回帰テスト内で実行することができます。回帰では、変更が行われるたびに、品質管理チェックを加速するさまざまなテストが実施されます。また、バグを迅速に発見するための分析や機械学習手法の活用も進んでいます。
他のコード・モジュールやサブシステムに対してアップデートのテストを行い、変更によって想定外の相互作用や問題が生じないか確認することができます。デジタル・ツインは、プロジェクトのハードウェアを完全に置き換えるものではありません。デジタル・ツインのシミュレーションの動作を実世界の条件に対して検証するために、従来のハードウェア・イン・ザ・ループ (HIL) テストが依然として必要です。ただし、いったん動作の逸脱が修正されれば、デジタル・ツインはライフサイクル中のアップデートをサポートするために幅広く利用できます。広範な事前ハードウェア・テストを複数のサーバーにまたがるクラウドの速度で実施できるため、OEMは準備が整い次第、自信を持って新たな機能でのOTAアップデートを展開することができます。
SDVの仮想モデル
高精細モデルの使用
モデルの精度は重要ですが、多くのテストでは完全なタイミング精度のモデルは必要となりません。高精細モデルは一般的に、ターゲット・プロセッサでの命令のスループットやアプリケーション・ロジックの分析用に最適化された高速モデルよりも動作が遅くなります。非常に詳細なシミュレーションを必要とするコンポーネント・モデルやサブシステム・モデルのみを実行するパーティションを使用すれば、テスト時間や検証プロセスを合理化できます。
デジタル・ツイン・モデルはOEMやサブシステム・サプライヤが構築することも可能ですが、適切な半導体サプライヤとの連携を図ることには大きな利点があります。NXP Semiconductorsなどのベンダーは、製品をプロトタイプや最終製品に組み込むためにOEMに出荷する1年も前から、シリコン・プラットフォームのモデル開発に着手しています。
また、デジタル・モデルは、アーキテクチャの変革がターゲット・アプリケーションにもたらすメリットについて、OEMやサブシステム・プロバイダが理解を深めるためにも役立ちます。その良い例の1つが磁気抵抗メモリ (MRAM) です。これはフラッシュ・メモリの代替となる高い性能を備えるとともに、揮発性のDRAMやSRAMでのデータ保持の限界を克服します。基本モデルでは、フラッシュなどの不揮発性メモリとMRAMを同等に扱い、レイテンシや帯域幅も区別しません。より高精度のモデルでは、書き取りおよび読み取り時間や他の動作面の違いが反映されます。
これらの違いは、利用可能な場合にこのテクノロジを最大限に活かすようなコード・ベースへの変更に活用することが可能です。その結果、ソフトウェア・チームは、モデル中心のアプローチを開発に取り入れることで、将来のハードウェア実装の仕様を規定し、数世代にわたってパフォーマンスを向上させることができるようになります。
継続的改善
「ストレッチ・ライト」の基礎となる手法は、製品品質とサービス収益の両方の継続的改善を可能にします。OEMは、車両自体のOTAアップデートに加え、稼働中のシステムからセンサのデータを収集し、それらをさまざまな機械学習および解析システムに適用することができます。この情報をフィルタリングし、デジタル・ツインでのシミュレーションに適用して、実世界でのパフォーマンスを測定することが可能です。
これにより、新たなOTAアップデートでデプロイする前に回帰環境で改善箇所をテストできるようになり、開発からデプロイまでの時間が短縮され、製品の改良サイクルの大幅な加速につながります。これにより、既存のハードウェアが改善されると同時に、将来の世代に向けたさらなるシフト・レフトが可能になります。これは、継続的インテグレーションとデジタル・ツインを含む包括的な開発アプローチが製品設計とサポートをいかに合理化できるかをさらに実証するものでもあります。
本稿の内容は、EEtimesに掲載された過去の記事 に基づいています。
