SDV (ソフトウェア・ディファインド・ビークル) の実現に向けた従来型自動車アプリケーションの SOA への移行

SDV (ソフトウェア・ディファインド・ビークル) は、AI、自律性、接続性、および電動化を特徴としています。最近、自動車業界では、SDV 向けの現代的なアプリケーションの設計に "サービスベース" のアプローチを採用し始めています。このアプローチは、サービス指向アーキテクチャ (SOA) として知られており、高い再利用性、更新の容易さ、およびハードウェアとの疎結合を特徴とするソフトウェア アプリケーションの開発において新しいパラダイムを提供しています。SOA の構築は、アプリケーションは実行時に動的に検出、パブリッシュ、サブスクライブ、および再構成可能なサービスの集まりで構成される、という原則に基づくものです。SOA の概念は、AUTOSAR (AUTomotive Open System ARchitecture) をはじめとする業界標準に広く組み込まれています。

SOA フレームワーク内で、サービスは自己完結かつモジュール化され、疎結合されているため、モノリシックでない複雑な分散アプリケーションの作成を可能にします。SOA ベースのアプリケーションは、トップダウン アプローチでもボトムアップ アプローチでも開発できます。標準的な SOA ソフトウェアスタックでは、アプリケーション ソフトウェアはサービス、プラットフォーム サービス、およびミドルウェアで構成され、そのすべてが高性能ハードウェアまたはバーチャルマシン上で実行されます。

レガシー アプリケーションを SOA に移行する際の課題

レガシー アプリケーションのいくつかの特徴により、SOA への移行が困難になり得ます。これには次が含まれます。

• モノリシックな設計: レガシー アプリケーションは、多くの場合モノリシックな設計になっており (図1)、コンポーネントは緊密に結合され、相互接続されています。機能が絡み合っており、モジュール化されていないため、アプリケーションを個別のサービスに分解することが困難です。

• 実行順序: レガシー アプリケーションは通常、そのコンポーネントの実行順序があらかじめ定義されています。この実行がシーケンシャルである性質により、ランタイム中に動的に検出および再構築可能な独立した複数のサービスに変換するタスクが複雑になる可能性があります。
• 信号ベースと時間ベースの通信: レガシー アプリケーションでは多くの場合、コンポーネント間の通信が信号ベースまたは時間ベースで行われています。SOA では、通信は通常、サービス インターフェイスとメッセージの交換に基づいて行われます。レガシー アプリケーションの通信メカニズムをサービス指向アプローチに適応させるには、慎重に検討し、場合により通信プロトコルを再設計する必要があります。

このような課題の克服は、レガシー アプリケーションのアーキテクチャの包括的な分析と、サービスの境界とコンポーネント間の依存関係の慎重な特定を通常伴います。SOA フレームワーク内でサービスとしてカプセル化できる、よりモジュール化された疎結合のユニットにアプリケーションをリファクタリングすることが必要な場合もあります。

レガシー アプリケーションの構成をサービスに変換するのは、複雑なタスクです。たとえば、過去に設計されたモノリシックなアプリケーション構成、たとえば、高速道路の車線追従アプリケーションは、単一のサービスに変換するか、カメラサービス、ビジョンサービス、レーダー、車線誘導サービスなどの複数のサービスに分解できます。

システムの専門知識とモデルベースデザイン (MBD、モデルベース開発) を組み合わせることで、モノリシックなアプリケーション設計をサービス機能に分解し、それぞれの論理コンポーネントをカプセル化および抽象化することができます。これにより、信号からサービスへのインターフェイスの移行や、適切な実行順序の決定が可能になります。この記事では SDV 向けの AUTOSAR Adaptive の概念に基づいた、新しいサービスのモデル化や、従来のアプリケーション構成のサービスへの変換をするためのモデルベースデザイン ワークフローについて説明します。

従来のアプリケーション ソフトウェア構成のサービスへの分解

従来のアプリケーション ソフトウェア構成を SOA アプリケーションのサービスに分解するには、モノリシックなアーキテクチャをより小さく、よりモジュール化されたコンポーネントに分解する必要があります (図 2)。これにより、SDV のコンテキストにおける柔軟性、拡張性、適応性を高めることができます。

従来のアプリケーション ソフトウェアの構成を SOA アプリケーションのサービスに分解するには 4 つの手順があります。

• サービスの特定と解析: SOA を構成するサービス、コンポーネント、機能、実行順序、および依存関係を特定します。エンジニアにとって特に困難なステップです。完了したら、サービスを解析して、従来のモノリシックなアプリケーションをより小さなコンポーネントに分解する必要があります (図 3)。

• サービスとインターフェイスの定義: サービスが特定されたら、サービス間のインターフェイスを定義することが重要です。これには、サービス間の通信に使用されるプロトコルとデータ形式の規定、およびサービス間のインタラクションの規約を規定するサービスコントラクトの定義が含まれます。
• サービスコントラクトの定義: この手順では、サービス間のインタラクションの規約を規定します。これらの概念は AUTOSAR の 22-11 スキーマで導入されています。サービスのバージョン管理が規定されており、これにより既存のクライアントを壊さずに、新しいバージョンのサービスをリリースできます。
• サービスの実装と展開: サービスを実装し、スタンドアロン アプリケーションとしてそのインターフェイスの記述を含むアーティファクトと共に展開します。

モデルベースデザインを用いたサービスへの移行

モデルベースデザインは、AUTOSAR 以外のフレームワークと AUTOSAR Classic フレームワークのアプリケーション開発に使用されてきました。さらに、AUTOSAR Adaptive フレームワークおよび汎用 SOA フレームワーク向けの SOA ベースのアプリケーション開発にも活用することができます。SDV アプリケーションの場合、業界では一般的に汎用 SOA または AUTOSAR Adaptive プラットフォームに基づく SOA を利用してきました。モデルベースデザインは、SOA、AUTOSAR Classic、AUTOSAR Adaptive を含むあらゆるタイプのプラットフォームの開発プロセスを効率的に処理できる統合開発プラットフォームを提供することにより、付加価値を高め、全体的な一貫性と効率性を確保しています。

モデルベースデザインを使用して、モノリシックなアプリケーション コンポーネントをサービスに分解するには、次の手順を行います。

• サービスの特定と解析: さまざまなコンポーネント、その機能、実行順序、およびコンポーネント間の依存関係を理解します。モノリシックなアプリケーションでは、すべてのコンポーネントが単一の実行可能ファイルとして展開されます (図 4)。一方、サービスに分解すると、個々のサービスは独立して展開されます。

たとえば、図 4 は、Simulink^® で開発され、モノリシックなアプリケーション構成として展開された高速道路の車線追従アプリケーションを示しています。このようなモノリシックなコンポーネントを Simulink を使用してサービスに分解するには (図 5)、単一責任の原則と依存性逆転の原則が用いられます。これらの原則を活用すると、高速道路の車線追従モデルは、レーダー、ビジョン、車線などの複数のサービスに分解されます。これらのサービスには、明確に定義された責任と疎結合な依存関係があるため、1 つのサービスへの変更は他のサービスから遮断され、影響を最小限に抑えることができます。

図 5. モデルベースデザインを用いたモノリシックなレガシー アプリケーションのサービスへの分解 (左)。モノリシックなアプリが SOA ベースのサービスに分解され、クライアントサーバー ポートで接続されている (右)。

• サービスとインターフェイスの定義: インターフェイスを使用して定義されたサービスは、そのサービスが他のサービスとインタラクションをする際の通信チャネルとして機能するサービス境界の一部です。さらに、サービス境界は、機能をカプセル化することで、再利用、保守性、バージョン制御、可視性、オーケストレーションなどの利点もたらします。System Composer™ を使用すると、関連するサービス コンポーネントのポートを構成してデータの整合性を取り、ステレオタイプとともにサービスがどのようにインタラクションするかを表すことができます。これにより、サービス間の依存関係とインタラクションが視覚的に表現されます (図 6)。

図 6. Simulink におけるサービス コンポーネントのサービス インターフェイスおよびポートの構成。

• サービスコントラクトの定義: サービスには明確な境界を確立し、その入力、出力、および動作を定義することが推奨されます。これにより、サービスをアーキテクチャの他の部分と緊密に結合させることなく、個別に開発、テスト、および展開できます。サービスコントラクトを定義することで、サービスの機能と制約を理解し、より簡単に統合できます (図 7)。さらに、サービスコントラクトによって、既存のクライアントを壊さずに、新しいバージョンのサービスをリリースできます。

図 7. 各サービスは、入力、出力、およびそのアプリケーション ロジックでモデル化されます。これらのモデルをシミュレーションして、サービス間のインタラクションを観察できます。

• 実装と展開: モデルベースデザインでクライアント/サーバー インターフェイスを活用することにより、SOA ソフトウェア アーキテクチャ モデルを作成できます。Simulink でサービスとして実装された LaneGuidanceApp、DetectionApp、レーダー、およびビジョンのアルゴリズムを図 8 に示します。

さらに、Embedded Coder^® を使用して、汎用 SOA アプリケーションの C++ コードを生成できます。

AUTOSAR Adaptive アプリケーションへのサービスの構成

これらのサービスは、Simulink のモデル構造を使用して、AUTOSAR Adaptive 用にシームレスに構成できます。図 9 に示すように、System Composer の直観的な AUTOSAR エディターを使用して、すべてのサービスが AUTOSAR Adaptive サービスとして機能するように統合できました。その後、各ポートとインターフェイスに必要なマッピングを確立し、該当する AUTOSAR Adaptive プロパティとの整合性を確保しました。

図 9. AUTOSAR Adaptive アプリケーションの設計、開発、および C++ コードの生成 (左)。
Simulink で AUTOSAR Adaptive アプリケーション用の C++ コードを生成する方法を示すビデオ (右)。

たとえば、レーダーサービスについて考えてみましょう。レーダーサービスは、モデルのルートレベルで Simulink Function ブロックを使用して Adaptive メソッド (3:50) サービス インターフェイスを作成する Simulink モデルにリンクされています。ここで、AUTOSAR サービス インターフェイスのメソッドは、インターフェイスを提供するサーバーとしてモデル化されたソフトウェア コンポーネントと、そのインターフェイスを必要とするクライアントとしてモデル化された別のソフトウェア コンポーネントとの間のインタラクションを定義します。

Simulink では、クライアント/サーバー間の通信は、同期または非同期の呼び出し動作のどちらでもモデル化できます。同期クライアントモデルでは、クライアントがサーバーにリクエストを送信し、レスポンスを待つ間、クライアントの実行はブロックされます。非同期クライアントモデルでは、クライアントがリクエストを送信し、リクエストの送信後も実行を継続します。そして、サーバーからのレスポンスが受信された際に処理するという形で、クライアントの実行はブロックされません。

レーダーサービスは、クライアント/サーバー通信を使用するサーバーです。図 9 のコードマッピング UI は、Simulink Function ブロックおよび Function Element ポート (radarCtrl.Adjust、および radarCtrl.Calibrate) とそれぞれの Adaptive ポートとのマッピングを示しています。

さらに、AUTOSAR ディクショナリで、"Methods" サービス インターフェイスの AUTOSAR プロパティを表示および編集できます (図 10)。

LaneGuidanceApp サービスはクライアントとして機能し、非同期呼び出しを通じてクライアント/サーバー通信を利用します (図 11)。この例のクライアントは非同期通信を使用し、サーバーにリクエストを送信した後もノンブロッキング実行により、継続的な実行を可能にしています。Simulink モデル内では、関数呼び出しを非同期で実行するために、Function-Call Subsystem ブロックを Message Triggered Subsystem ブロックと組み合わせて使用します。コードマッピング UI は、Simulink 関数呼び出しと、それに対応する AUTOSAR Adaptive ポートとのマッピングを示しています。

同様に、他のすべての SOA サービスも Simulink で AUTOSAR Adaptive の概念にしたがって構成されています。

各 AUTOSAR Adaptive サービスは検証とシミュレーションの後に、C++ コードと、Machine ファイル、Execution ファイル、および ServiceInstanceManifest ファイルを含めた AUTOSAR インターフェイス記述を独自のアーティファクトとして提供するスタンドアロン アプリケーションとして展開できます。最後に、AUTOSAR Adaptive C++ コードと、それに対応するソフトウェア記述ファイルおよびマニフェストファイルは、Embedded Coder を使用して生成され、ワークフローでさらなる統合に活用されます (図 12)。

まとめと今後の課題

モデルベースデザインは、システム開発に対する構造的なアプローチを提供し、アプリケーションのアーキテクチャ、コンポーネント、およびインタラクションを表すモデルの作成を可能にします。この記事では、モデルベースデザインを使用して従来のモノリシックなアプリケーションをサービスに分解し、それらのサービスを AUTOSAR Adaptive アプリケーションとして構成する方法を、高速道路の車線追従の参照例モデルを使って紹介しました。これらのモジュール化されたサービスは、エンジニアが C++ コードとマニフェストファイルを作成、シミュレーション、生成できるブループリントの一部となり、ワークフローにおけるさらなる統合に活用できます。