このページは機械翻訳を使用して翻訳されました。
翻訳品質のアンケートに 1 分ご協力ください。
MathWorks インサイト
著者:
「当社は、MATLAB、Simulink、System Composer、Embedded Coder を使用したモデルベースデザインをベースに、ワークフローの改良と拡張を行っています。このワークフローは、開発の加速や手書きコードに内在する課題の最小化といった点で、すでにその価値を証明しています。」
車両が従来の機械システムから SDV (ソフトウェア・ディファインド・ビークル) へと進化するにつれて、自動車業界は大きな変革を遂げています。この変化に伴い、ソフトウェア開発に対する新しいアプローチが求められ、柔軟でスケーラブルな自動車用アプリケーションを設計するための推奨パラダイムとしてサービス指向アーキテクチャ (SOA) が登場しています。ZEEKR では、車載オペレーティング システム上で実行される SOA アプリケーションを開発するためのモデルベースデザインに基づく包括的なワークフローを確立することで、この移行を受け入れました。
従来の自動車ソフトウェア開発におけるモデルベースデザインは、主に AUTOSAR® Classic Platform の実装に焦点を当ててきました。このプラットフォームでは、ソフトウェア コンポーネント (SW-C) が標準化されたランタイム環境 (RTE) インターフェースを通じて相互にやり取りします。しかし、SOA では、クライアントサーバー呼び出しやメッセージベースの対話などの新しい通信パターンが導入されるため、確立された開発手法に大幅な調整が必要になります。課題は、これらの新しい通信パターンをモデル化することだけでなく、AUTOSAR 非標準化環境内でソフトウェア アーキテクチャの複雑性の増大を管理することにもあります。
ZEEKR の我々のグループは、SOA アプリケーション開発にモデルベースデザインをベースにしたワークフローを用いて、これらの課題に対処しました。この記事では、そのワークフローにおける以下の 3 つの主要な領域を取り上げます。
我々の経験は、エンジニアがモデルベースデザインを使用して、従来の組み込みシステムから SDV 向けの最新の SOA ベースのソフトウェア アーキテクチャへの移行を加速する方法を示しています。
SOA では、従来の組み込みシステムとは根本的に異なる新しい通信パターンが用いられます。従来の AUTOSAR アプリケーションは、シンプルな RTE インターフェイスを介して通信を行うことで、ソフトウェア コンポーネント間で緊密に結合され、かつ静的に定義されたやり取りが実現します。対照的に、リモート プロシージャ コールやメッセージ ベースの対話などの SOA 通信パターンは、より柔軟で高度なものになります。また、ハードウェアとソフトウェアの分離やソフトウェアの階層設計も可能になります。これらのパターンを最大限に活用するために、我々はモデルベースデザインをベースにした開発ワークフローを採用しています。それには、Simulink による SOA アプリケーションのモデリング、Embedded Coder® による C++ コード生成、独自に開発したラッパー ジェネレーターを用いたミドルウェア統合コードの作成、アプリケーションコードと統合コードのデプロイが可能なアプリケーション パッケージの統合が含まれます。この自動化されたワークフローでは、手書きの C++ コードは必要ありません。自動的に生成されたラッパーコードは、Simulink モデルから生成されたアプリケーション コードとランタイム環境 (ZEEKR ARK OS) を橋渡しします。
我々のワークフローにおける代表的な SOA モデルには、Simulink でモデル化されたサービス プロバイダーとクライアントが含まれます (図 1)。この構造は、分離されたサービス呼び出し、明示的なメッセージ交換、通信と計算の明確な分離といった、基本的な SOA 動作を捉えます。これにより、Simulink 内で SOA の概念を明確に表現し、分散型のサービスベース環境での展開用にそれらのモデルを準備できるようになります。
図 1. Simulink でモデル化されたシンプルなクライアントとサーバー。クライアントには、制御信号 (ステップ) によって周期的にトリガーされる受信ブロックと送信ブロックが含まれます。
当社の展開シナリオは、集中コンピューティング環境と分散コンピューティング環境の両方にわたります (図 2)。Simulink でモデル化されたサービス指向アプリケーションは、高性能な中央コンピューティング ユニット上で実行されます。一方、同じく Simulink で開発された Classic AUTOSAR コンポーネントはマイクロコントローラ上で実行され、車両アクチュエータと直接連携します。このような混在展開は、ドメイン コントローラーが高レベルの処理を担当し、エッジノードが低レベルの制御を担うという、より広範な集中型ドメイン アーキテクチャへの潮流を反映しています。Simulink を使用すると、こうしたアーキテクチャの両側面をサポートでき、統一された開発環境のもとで、多様な要素が混在する自動車システムのモデリング、シミュレーション、コード生成を実現できます。
図 2. Simulink で開発された実際の空調アプリケーション。中央プロセッサ ノードに展開された SOA ソフトウェアと、アクチュエータを駆動するためにマイクロコントローラ上で実行される AUTOSAR Classic SW-C を組み合わせています。
サービス指向アプリケーションの範囲と複雑さが増すにつれて、その構造の管理が重要な課題になります。複数のサービスが複数のソフトウェア ユニット間でやり取りを行うため、各モデルを個別に扱うだけでは不十分です。代わりに、ソフトウェア コンポーネントがどのようにグループ化され、どのように通信し、どこに展開されるかなど、ソフトウェア コンポーネントが互いにどのように関連しているかを明確にアーキテクチャで表現する必要があります。AUTOSAR オーサリング ツールを含む市販の自動車ソフトウェア アーキテクチャ ツールの多くは、AUTOSAR ベースの環境を前提としており、カスタム オペレーティング システム用のサービスベースの通信モデルを展開する柔軟性に対応していません。当社では、SOA フレームワークや車載 OS のニーズに応えるため、独自のアーキテクチャ モデリング環境を構築しました。SOA Model Composer (SOMOC) は、System Composer のモデルベースシステムのエンジニアリング機能やアーキテクチャ設計要素だけでなく、MATLAB® のオブジェクト指向プログラミング機能を基盤としています。使いやすさを考慮して、MATLAB と App Designer を使用して独自のユーザー インターフェイスを作成しました (図 3)。
図 3. アーキテクチャのツリービュー (左) とコンポーネント コンポーザーのインターフェイス (右) を含む SOMOC ユーザー インターフェイス。
SOMOC は、システム アーキテクチャ、プロセス、ソフトウェア コンポーネント、サービス定義という 4 つの主要なレベル全体で SOA を定義して管理するための構造化されたアプローチをサポートします (図 4)。この階層構造は、System Composer の参照コンポーネント機能を使用して、高レベルのシステムから個々のサービスに至るまで明確なトレーサビリティを確立します。
図 4. SOMOC のコンポーネント階層。アーキテクチャ、プロセス、SW-C、サービスの各レベルを示しています。
SOMOC は、サービス識別子、名前空間、バージョン情報などの SOA 固有のメタデータを取得するカスタム プロファイルとステレオタイプを使用してアーキテクチャ モデルを拡張します。ZEEKR のシステム アーキテクトは、SOMOC を使用して、プロセス境界、サービス インターフェイス、ソフトウェア コンポーネントを定義することにより、システム設計中に生成された ARXML ファイルからインポートされた機能要件を展開可能なアーキテクチャに変換します。これらのアーキテクチャ モデルから、SOMOC はインターフェースが統一された Simulink モデルのひな形を自動生成し、開発者が内部動作やロジックを実装する際に安心して作業を始められるようにします (図 5)。この自動化により、アーキテクチャから実装までのワークフローが標準化され、インターフェースの同期が維持され、開発全体を通じてチームに共通の参照ポイントが提供されます。
図 5. SOMOC フレームワーク内で設計、テストされるさまざまなレイヤー。
ZEEKR では、モデルレベルとコードレベルを組み合わせたテストで、サービス指向アプリケーションの検証を行っています。まず、Simulink Test™ を使用して Simulink でユニットテストとモデルテストを実行し、テストハーネスを使用して個々のコンポーネントを分離し、サービスの相互作用を検証します (図 6)。各モデルについて、エンジニアは対応するコンポーネント (コンシューマーモデルのシミュレーションされたプロバイダーなど) との通信をシミュレーションし、予想される応答とインターフェイスの動作を検証できます。この初期段階の検証は、コードが生成される前に論理エラーやインターフェースの不一致を特定するのに役立ちます。
図 6. Test Sequence エディターに表示されるテストハーネスのテストシーケンス。
アプリケーション コードを生成し、車載 OS と統合した後、Visual Studio Code 内の軽量プラグインである Service Verification Toolkit (SVT) を使用して実行時テストを実行します (図 7)。SVT を使用すると、チームは ARXML ファイルからサービス インターフェイス定義をインポートし、アプリケーション レベルでサービス通信をシミュレーションしてメソッド インターフェイスとトピック インターフェイスの両方をテストできます。また、メソッド要求の送信、応答の処理、トピックデータの公開、メッセージのサブスクライブなど、コンシューマーまたはプロバイダーとして機能します。SVT はサービス インターフェイス間で交換される値を表示し、エンジニアがデプロイされたアプリケーションがさまざまな相互作用シナリオで正しく動作することを確認できるようにします。
図 7. Visual Studio Code の SVT プラグイン。
当社では、車載展開向けの新しいサービス指向アプリケーションの開発を継続するとともに、MATLAB、Simulink、System Composer、Embedded Coder を使用したモデルベースデザインをベースにしたワークフローの改良と拡張も行っています。このワークフローは、開発を加速し、手書きのコードに伴う課題を最小限に抑えることで、すでにその価値を証明しています。アーキテクチャ モデリング、サービス モデリング、シミュレーション、コード生成、サービス指向アプリケーションと AUTOSAR ベース アプリケーションのテストを 1 つの環境で実行する能力により、自動車業界の状況が変わり続ける中で SDV 開発を支えるスケーラブルなソフトウェア基盤を得ることができました。
公開年 2025
