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

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

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

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

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

この記事では、ソフトウェアとハードウェアの分離の方向に焦点を当て、SOA 用にソフトウェアとハードウェアをデプロイする方法を説明します。

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

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

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

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

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

ハードウェアコンピューティングプラットフォーム: スケーラブルなハードウェアプラットフォームには、SOA 基本サービス管理と SOA ハードウェア I/O 制御管理が含まれており、自動運転システムの複数のセンサーや外部デバイスと互換性があり、複数の異種チップとハードウェアのアップグレード。

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

通信アーキテクチャ: 通信アーキテクチャのスケーラビリティにより、プラットフォームベースのモデルの開発に迅速に適応できます。モデル間の違いは最小限に抑えることができ、現行世代の製品を利用して通信を拡張することで、多くの追加開発作業を行う必要がなく、その後の製品ラインのメンテナンスのプレッシャーを大幅に軽減できます。

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

サービス層/アプリケーション層: 標準化されたサービス層とオーケストレーション可能なアプリケーション層には、SOA システム機能管理、ユニットドメイン機能管理、車両機能制御管理、クラウドサービス管理が含まれます。

SOA におけるデバイス抽象化テクノロジ

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

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

デバイスの抽象化は、プラットフォームソフトウェアと基礎となるドライバーソフトウェアを介した、さまざまなハードウェアバリアント間でのアプリケーション層ソフトウェアの互換性を反映します。

表 1 プラットフォームソフトウェアと機器 (センサー) の抽象的な関係

##ノイズ除去フィルタ#入力電圧値、ピクセル、点群、温度値などの出力センサー値センサーデバイスドライバーを実行する; ·生の信号（電気信号）から物理値への変換;#センサーの意味値を入力し、輝度値などの補足後の完全な値を出力##分離されたセンサー信号補償端子·信号の元の値の補正#·機能テスト診断インターフェイス

抽象的な階層化

機能

動作原理

動作の詳細

プラットフォームソフトウェア

元の取得値、出力電圧値を入力

ソフトウェアとハードウェアの接続を切り離す

物理的特性の独自のインターフェイスを提供します

機械的特性、電気的特性、機能的特性、および手順的特性。

#電気機器ドライバー

入力電圧値、出力フィルター電圧値

センサーの測定を確認

# 電気デバイスドライバーソフトウェアの電気診断 (接地、バッテリーの短絡、開回路などの検出)

# を実行します。

センサーが外部から電源供給されている場合の電圧補償

# センサーデバイスドライバー

さまざまなセンサーの違いを分離する

センサーの物理的な動作を制御する;

·ゼロ点とオフセットの調整

·測定値のドリフト検出

·診断チェック

・物理値チェック

##・フィルタリング機能(ダウンサンプリング含む)

##仮想デバイスドライバ

#センサーの仮想デバイスドライバーは、ソフトウェアプログラムの物理的表現によって抽象化されます

·信号品質評価

·元の値の置き換え(センサーの信号品質が不十分な場合など)

#·信号の元の値の検証

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

#電気機器ドライバーソフトウェアの電気診断を実行します (アース、バッテリー、断線などの短絡の検出など)ノイズ除去フィルタアクチュエータデバイスドライバ入力 PWM、出力保護、および対応する PWM 値仮想デバイスドライバー

##抽象的なレイヤリング	機能	動作原理	作業の詳細
プラットフォームソフトウェア	入力 PWM、出力 PWM 値ソフトウェアとハードウェアの接続の分離	物理的プロパティの生のインターフェイスを提供します	機械的プロパティ、電気的プロパティ、機能的プロパティ、および手続き的プロパティ。
電子デバイスドライバー	入力電圧値、出力フィルター電圧値実行の有効性を確認するデバイス実行プロセスの		アクチュエータが外部から電源供給されている場合の電圧補償
	機械プロセスの分離された実行分離されたアクチュエータ機能の保護	センサーデバイスドライバーはアクチュエーターの物理的な動作を表します	·ドライバーの摩擦を克服するために出力値を重ね合わせます ·実行信号値を出力し、効果的な実行を保証します #·過大なダメージを防ぐために出力値を制限します #·設定値を制御します(センサーデータの閉ループで) #·提供します制限および機能情報インターフェイス
アクチュエータ要求値を入力し、PWM 値を出力します。バルブ開度として	エグゼキューターのジッター、非線形化、実行オーバーランなどの処理を分離します。の物理的表現仮想デバイス実行プログラムの抽象エグゼキュータ	・制御側の物理リクエスト値の変換	・非線形値から線形値への変換値 ·機能テスト用の診断テスターインターフェイス ·特殊モード処理 ·アクチュエータを起動して実行 ·アクチュエータの位相ジッターを除去設定値の上書きまたはフィルタリング ##・アクチュエータを調整して安全に起動 ## 要約すると、BEG デバイスの抽象的な概念と設計は次のように要約できます: アプリケーションソフトウェアは、特定の ECU に接続された特定のセンサーやアクチュエーターから独立しています。異なるセンサーとアクチュエーター間でコードを再利用可能; 異なるコード共有連携モデル (ソフトウェア共有) により、異なるビジネスモデルをサポート; 機能を異なる ECU に展開または再分配;この設計パターンもデバイス抽象化として知られています。デバイス抽象化は、機能とサービスインターフェイスを上向きに公開し、プラットフォームソフトウェアを下向きに接続する S&A レイヤーモジュールの問題を解決します。目標は、インターフェイスを可能な限り公開し、ソフトウェアとハードウェアの分離を実現することです。 S&A の変更によりソフトウェアの変更が生じることを回避します。 03 SOA でのデバイス抽象化の例ここでは、SOA アーキテクチャでデバイス抽象化を実装する方法を示す例を示します。このメソッドでは、入力生データ Rawdata を定義するためにセンサーカテゴリ (レーダー、カメラなど) のみを知る必要があります。これらのセンサーの特定の接続方法を知る必要はありません。最上位のアプリケーション層については、最後のアプリケーション層のみを知る必要があります。センシングデータを適用する必要があります。センサーのデバイス抽象化を例にとると、次のように表すことができます。まず、基礎となる物理層の MCAL が次の方法でデータを収集します。 uCポートにアクセスして生データを提供し、一定時間(10msなど)ごとに検出するため、電化製品の接続形態や対応するデータの意味を理解する必要はありません。たとえば、元の画像のピクセルデータは、基礎となる LIDAR センサーから収集され、マイクロコントローラー MCU/SOC に入力されます。第二に、MCU/SOC は、一定期間に従って対応する物理アドレスから対応する点群値を取り出し、I/O デバイスを介して I/O ハードウェア抽象化モジュールに与え、それを測定しますI/Oハードウェア抽象化ポイント検出により、データ計測ポイントの第1階層電気機器が配線に接続され、センサーは配線情報と解釈された生データに基づいて電圧値を計算し、フィルタリング処理を行います。測定データの意味を理解する必要はありません。その後、ハードウェア抽象化モジュール内の電圧値は 8 ビットドライバーに従って段階的に処理され、センサー電子デバイスドライバーによって呼び出され、基本的な元の値が生成されます。この値は、センサー仮想デバイスの歩行者、道路標識などを介して仮想デバイス Dri を駆動します。最後に、AP Autosar のアプリケーションソフトウェアは、リアルタイム実行環境 RTE を通じてセンサーセンシングのターゲットレベルのデータをリアルタイムで読み取り、アプリケーションソフトウェアのその後の計画制御と意思決定制御に使用されます。。上記の例からもわかるように、デバイス抽象化には、センサーやアクチュエーターの変更に伴うプラットフォームソフトウェアやアプリケーションソフトウェアの変更が発生しないという利点があります。変換によって引き起こされるハードウェアのデカップリング。異なるモデルのセンシングセンサーを置き換える場合、ECU の選択は、ECU がサポートする信号解析モードモデルに限定されなくなりました。たとえば、NTC モデルと PTC モデルを置き換えるには、デバイスドライバーにあるソフトウェアモジュールを変更するだけで済みます。同じタイプのセンサーとアクチュエータモジュールは、同じ処理モジュールの一部を共有できます。たとえば、サイドビューカメラの処理モードの場合、サイドビューカメラの 1 つの処理アルゴリズムを次のようにすることができます。他の 3 台に直接適用され、3 台のカメラのカメラパラメータを再調整するだけで済みます。一部のカメラを高解像度のカメラに更新する必要がある場合でも、基盤となるドライバーソフトウェアやプラットフォームソフトウェアに大きな変更を加える必要はありません。少なくとも I/O インターフェースの形式やデータ入力モードを変更する必要はなく、画像処理のアルゴリズムモジュールのみを再チューニングするだけで済みます。高解像度処理モジュールの要件に応じて、現時点ではニューラルネットワーク加速モデルの最適化方法を検討する必要がありますが、全体的なアルゴリズムアーキテクチャモデルは変わりません。 04 まとめ現在、多くの OEM が提唱する開発手法はプラットフォーム製品開発を行うことであり、プラットフォーム化ではソフトウェアとハードウェアを分離するという核心的な考え方が重視されています。製品ラインとプラットフォームラインは分業するのが便利で、製品ラインは特定の車種プロジェクトを担当し、プラットフォームラインはテクニカルセンターの構築を担当します。新しいプラットフォームの開発では、技術的なリンクが非常に長く複雑になることがよくありますが、階層化されたアーキテクチャ設計とソフトウェアとハードウェアの分離方法により、階層化されたテストと検証が容易になり、統合テストのプレッシャーが軽減され、問題をより完全に発見できます。バージョンのリリース速度が向上します。