SOA におけるソフトウェア アーキテクチャ設計とソフトウェアとハ​​ードウェアの分離方法論

次世代の集中型電子電気アーキテクチャでは、中央+ゾーン中央コンピューティング ユニットと地域コントローラ レイアウトが、すべての OEM またはティア 1 プレーヤーにとって必須のオプションになっています。中央コンピューティング ユニットを設計する方法には、個別の SOC、ハードウェア分離、ソフトウェア仮想化の 3 つがあります。集中型中央コンピューティング ユニットは、自動運転、スマート コックピット、車両制御の 3 つの主要ドメインのコア ビジネス機能を統合します。標準化された地域コントローラーには、電力分配、データ サービス、地域ゲートウェイという 3 つの主な役割があります。したがって、中央計算ユニットには高スループットのイーサネット スイッチが統合されます。

車両の統合度が高まるにつれて、ますます多くの ECU 機能が徐々に地域コントローラに吸収されるようになります。プラットフォームベースの地域コントローラは同じハードウェア設計と同じ IO インターフェイスを使用するため、さまざまなモデルのスケーラビリティ要件をより適切に満たすことができます。したがって、地域制御は車両全体のハードウェアを抽象化するという重要な機能も担っています。どちらも、元の CAN 通信の代わりに高速イーサネットを使用して相互に接続します。一般的に、スケーラブルな電子アーキテクチャは、車両モデル間のハードウェアの違いを隠すためのものです。通信ネットワークを形成するためにいくつの地域コントローラが使用されるかに関係なく、それらの間の通信モードは同じルールに従います。同時に、地域コントローラは、ローカル エリア ネットワーク内の ECU 機能の抽象化も担当します。

上図に示すように、中央コンピューティング プラットフォームを中核とする集中型アーキテクチャは、チップのアップグレードをサポートできる統合センサーと周辺インターフェイスを構築しており、車両のライフサイクル中にハードウェアのアップグレードを実現し、車両のインテリジェント ライフサイクルを延長することを最終目標としています。各地域コントローラには独自のオペレーティング システム ミドルウェアである SOA コア ミドルウェアがあり、分散コンピューティングおよび通信フレームワークを提供し、下部でさまざまなオペレーティング システム カーネル間の違いを保護し、上部で統一されたサービス開発フレームワークを提供できます。関連する機能には、サービス管理、ネットワーク管理、通信管理、アップグレード、診断、ログ、ステータスなどが含まれます。

この記事では、ソフトウェアとハ​​ードウェアの分離に焦点を当て、SOA 向けにソフトウェアとハ​​ードウェアを展開する方法について説明します。

01 SOAソフトウェアアーキテクチャ設計原則

次の図は、一般的な SOA ソフトウェア アーキテクチャの設計原則を示しています。このサービス指向開発アーキテクチャは、実際にはサービス指向開発のためのSOAアーキテクチャモデルソリューションであり、システムソフトウェアが製品開発プロセスに深く統合されている間に、製品マネージャーがサービス設計に集中できるようにします。これは、自動車ソフトウェア危機を解決するための大きな進歩でもあります。 SOA アーキテクチャ全体は、論理アーキテクチャによって構築されたソフトウェアとハ​​ードウェアの分離されたシステムと、サービス アーキテクチャによって完了されるサービスの抽象化と適応として要約でき、最終的に標準化されたサービス システムを確立します。

全体的な論理アーキテクチャ設計プロセスは、次のように要約できます。

電子および電気アーキテクチャ:スケーラブルなアーキテクチャ (コンピューティングおよび通信アーキテクチャとも呼ばれる) を設計するには、階層化設計、階層化テスト、階層化検証の要件を満たす必要があります。これにより、開発フェーズでのソフトウェア変更の連鎖反応や統合テスト中の問題の集中的な発生を回避し、問題の発見を容易にし、ソフトウェア バージョンの更新を迅速化できます。

ハードウェア コンピューティング プラットフォーム:スケーラブルなハードウェア プラットフォームには、SOA 基本サービス管理と SOA ハードウェア I/O 制御管理が含まれます。自律走行システムの複数のセンサーや外部デバイスと互換性があり、マルチヘテロジニアス チップとハードウェアのアップグレードをサポートします。

オペレーティング システム カーネル/サービス ミドルウェア:ファイルのスケジュールと駆動の中核として、オペレーティング システムは、ソフトウェアとハ​​ードウェアの分離とハードウェアへのソフトウェアの展開をサポートする上で最適な制御機能を実現できます。

通信アーキテクチャ:通信アーキテクチャのスケーラビリティにより、プラットフォームベースの車両モデルの開発中に迅速な適応が可能になります。車両モデル間の差異を最小限に抑えることができます。車両モデル開発の次の段階では、多くの追加開発作業を必要とせずに、現在の製品世代に合わせて通信を拡張できます。これにより、その後の製品ラインのメンテナンスの負担が大幅に軽減されます。

車両制御のリアルタイム要件を満たすために、コアネットワークではTSNなどの信頼性の高い通信技術を採用します。地域コントローラの管轄下にあるローカル エリア ネットワークでは、CAN や LIN などの従来の通信方法が引き続き使用されます。ローカル エリア ネットワーク内の通信は従来の信号モードで実行できますが、コア イーサネット バックボーン ネットワークでは、データのやり取りはサービスの形式で実行されるため、DDS などの通信ミドルウェアが必要になります。

サービス層/アプリケーション層:標準化されたサービス層とプログラム可能なアプリケーション層には、SOA システム機能管理、ユニットドメイン機能管理、車両機能制御管理、クラウド サービス管理など、いくつかの重要な部分が含まれます。

02 SOAにおけるデバイス抽象化技術

集中ドメイン制御を中核とするソフトウェア アーキテクチャ展開のコア テクノロジーを詳細に分析する前に、いくつかの重要な関連概念を詳しく説明する必要があります。 Autosar のセンサー/アクチュエータ設計パターンは、全体的なアーキテクチャのコンテキストで、ECU がループ内のセンサー/アクチュエータを処理する方法を記述します。

BEG デバイス抽象化は、RTE (テスト実行環境) の上にあります。これは、特定の ECU に接続されたセンサーとアクチュエータから抽象化されたソフトウェア コンポーネントのセットです。これは、センサーまたはアクチュエータ ソフトウェア コンポーネントを使用し、ECU 抽象インターフェイスへのアクセスを許可する RTE より上の唯一のコンポーネントです。デバイス抽象化は、ピクセル、ポイント クラウド、電圧、PWM 信号、デジタル信号/メッセージ、周波数などのセンサーとアクチュエータからの生の信号を抽出し、アプリケーション層ソフトウェアに物理インターフェイス (ピクセル、ポイント クラウド、圧力、質量、温度など) を提供します。実際には、デバイス抽象化によって、電圧値、デジタル信号、ポイント クラウドなどが物理値に変換されます。

デバイスの抽象化は、プラットフォーム ソフトウェアと低レベルのドライバー ソフトウェアを通じて、アプリケーション層ソフトウェアを他のさまざまなハードウェア バリアント間で交換できることを反映します。

表1 プラットフォームソフトウェアとデバイス抽象化の関係（センサー）

表2 プラットフォームソフトウェアとデバイス（実行者）の抽象的な関係

要約すると、BEG デバイスの抽象概念と設計は次のように要約できます。

アプリケーション ソフトウェアは、特定の ECU に接続された特定のセンサーやアクチュエータからは独立しています。

コードはさまざまなセンサーやアクチュエータ間で再利用できます。

さまざまなビジネス モデルをサポートするためのさまざまなコード共有協力モデル (ソフトウェア共有)。

機能をさまざまな ECU に展開または再配布します。この設計パターンは、デバイス抽象化とも呼ばれます。

デバイスの抽象化は、S&A 層モジュールが機能とサービス インターフェイスを上方に公開し、プラットフォーム ソフトウェアを下方に接続するという問題を解決します。目標は、インターフェイスを可能な限り公開し、ソフトウェアとハ​​ードウェアの分離を実現し、S&A の変更によるソフトウェアの変更を回避することです。

03 SOAにおけるデバイス抽象化の例

ここでは、SOA アーキテクチャでデバイス抽象化を実行する方法を示す例を示します。この方法では、センサーの特定の接続方法を知らなくても、入力生データ Rawdata を定義するためにセンサー カテゴリ (レーダー、カメラなど) を理解するだけで済みます。最上位のアプリケーション レイヤーでは、最終的なセンサー データのみを適用する必要があります。

センサーのデバイス抽象化を例にとると、次のように表現できます。

まず、基礎となる物理層で、MCAL は uC ポートにアクセスしてデータを収集し、生データを提供し、一定期間 (10 ミリ秒など) ごとに 1 回検出します。デバイスの接続方法や対応するデータの意味を理解する必要はありません。たとえば、元の画像ピクセル データは、基盤となる LiDAR センサーから収集され、マイクロコントローラ MCU/SOC に入力されます。

次に、MCU/SOCは、一定の周期に従って対応する物理アドレスから対応するポイントクラウド値を取り出し、I/Oデバイスを介してI/Oハードウェア抽象化モジュールに与え、I/Oハードウェア抽象化ポイントを介して測定データ測定ポイントの第1レベルの電気接続ルートを検出します。センサーは、ルーティング情報と解釈された生データに基づいて電圧値を計算し、フィルタリング処理を実行します。このプロセスでは、測定データの意味を理解する必要はありません。

その後、ハードウェア抽象化モジュール内の電圧値は、8 ビット ドライバーに従って段階的に処理され、センサー電子デバイス ドライバーによって呼び出されて基本的な生の値が生成されます。この値は、センサー仮想デバイス Virtual Device Dri 歩行者、道路標識などによって駆動されます。

最後に、AP Autosar のアプリケーション ソフトウェアは、リアルタイム ランタイム環境 RTE を介してセンサーが認識したターゲット レベルのデータをリアルタイムで読み取り、後続のアプリケーション ソフトウェアの計画制御と意思決定制御に使用します。

上記の例からわかるように、デバイスの抽象化には、センサーとアクチュエータの変更によってプラットフォーム ソフトウェアとアプリケーション ソフトウェアが変更されないという利点があります。まとめると、次の変換によって発生するハードウェアとソフトウェアの分離には、おおよそ次の種類があります。

異なるモデルの感知センサーを交換する場合、ECU の選択は、ECU がサポートする信号解析モードのモデルに限定されなくなりました。たとえば、NTC モデルと PTC モデルを置き換えるには、デバイス ドライバーのソフトウェア モジュールを変更するだけで済みます。

同じタイプのセンサーおよびアクチュエータモジュールは、同じ処理モジュールの一部を共有できます。たとえば、サイドビューカメラの処理モードの場合、サイドビューカメラの1つの処理アルゴリズムを他の3つに直接適用でき、3つのカメラのカメラパラメータのみを再調整する必要があります。一部のカメラをより高解像度のカメラにアップグレードする必要がある場合、基盤となるドライバーソフトウェアとプラットフォームソフトウェアに大きな変更を加える必要はありません。少なくとも、I / Oインターフェイス形式とデータ入力モードを変更する必要はありません。画像を処理するアルゴリズムモジュールのみを再調整する必要があります。たとえば、元の低解像度処理アルゴリズムは、高解像度処理モジュールのリアルタイム要件を満たさない可能性があります。この時点で、ニューラルネットワークアクセラレーションモデルの最適化方法を検討する必要がありますが、全体的なアルゴリズムアーキテクチャモデルは変更されません。

04 結論

現在、多くのOEMはプラットフォームベースの製品開発を提唱しています。プラットフォーム開発は、ソフトウェアとハ​​ードウェアの分離という中核的な考え方に基づいています。SOAアーキテクチャモデルは、製品ラインとプラットフォームライン間の分業を促進するために使用されます。製品ラインは特定の車両プロジェクトを担当し、プラットフォームラインは技術的な中間プラットフォームの構築を担当します。新しいプラットフォームを開発する場合、技術的なチェーンは非常に長く複雑になることがよくあります。階層化アーキテクチャ設計とソフトウェアとハ​​ードウェアの分離により、階層化されたテストと検証が容易になり、統合テストの負担が軽減され、問題がより完全に発見され、バージョンリリースが高速化されます。​