autosarとそのアーキテクチャを理解する

AUTOSAR（Automotive Open System Architecture）は、現在のオペレーティングモデルに影響を与えることなく、車両機能の適用範囲を拡大するように設計された、自動車業界全体に共通のプラットフォームとして定義できます。AUTOSARは基本的に、自動車メーカー、サプライヤー、ツール開発者が共同で開発したオープンで標準的なソフトウェアアーキテクチャです。この記事では、AUTOSARとは何か、およびそのアーキテクチャのさまざまなレイヤーについて学習します。

AUTOSARの主なモットーは、「標準で協力し、実装で競争する」です。この独自のアーキテクチャは、製造元、ソフトウェアサプライヤ、およびツール開発者の間で共通の標準を確立および維持するために開発されたため、変更を加えることなくプロセスの結果を提供できます。

AUTOSAR –すべてはどのように始まったのですか？

2003年、AUTOSARパートナーシップは、OEM（Original Equipment Manufacturer）メーカー、Tire 1自動車サプライヤー、半導体メーカー、ソフトウェアサプライヤー、ツールサプライヤーなどの提携として結成されました。彼らは、存在し、それらが結びつき、将来形成されるであろうさまざまな自動車用E / Eアーキテクチャを検討することにより、自動車用ソフトウェアアーキテクチャのオープンな業界標準としてAUTOSARを確立しました。

AUTOSARの10のコアパートナーは、BMW Group、Bosch、Continental、DaimlerChrysler、Ford Motor Company、General Motors、PSA Peugeot Citroen、SiemensVDO、Toyota Motor Corporation、およびVolkswagenです。

AUTOSARの重要性

AUTOSARのインフラストラクチャは単純ではありませんが、なぜこのような複雑なインフラストラクチャを自動車業界に導入する必要があるのでしょうか。一方で、なぜAUTOSARが必要なのですか？

インテリジェントで安全かつスマートな車両への需要が高まるにつれ、自動車業界での競争も激化するでしょう。このインテリジェンスと車両機能のすべてを単一の機関で実装することはできません。

たとえば、自動車にはエアバッグ、GPSシステム、スマートインテグレーションなどがあります。これらの機能はすべて、さまざまな自動車産業によってさまざまなECU（電子制御ユニット）に実装されているため、さまざまな自動車ユニットが連携して機能する必要があります。目的のコンセントを取得します。

これはソフトウェア開発プロセスにも役立ちます。最近まで、自動車産業向けに開発されたソフトウェアはシステムの機能を提供することにのみ焦点を当てており、システムにどのような影響を与えるかについては気にしませんでした。さまざまな車両ネットワークにまたがるさまざまなECUの多くの機能により、さらに複雑になりました。非標準の開発手順の増加に伴い、より重大な問題になりました。したがって、彼らはAUTOSARを開発しました。

AUTOSARアーキテクチャのさまざまなレイヤー

上の画像を見ると、AUTOSARのアーキテクチャが3つの主要なレイヤーで構成されていることがわかります。

アプリケーション層
ランタイム環境（RTE）
基本ソフトウェア（BSW）

これらの各レイヤーには独自の目的があり、実行する特定の操作があります

アプリケーション層

AUTOSARアプリケーション層は、指定された手順に従って特定のタスクを実行するように設計されたさまざまなアプリケーションと特定のソフトウェアコンポーネントで構成されています。アプリケーション層は、AUTOSARのソフトウェアアーキテクチャの最上位層であるため、すべての車両アプリケーションにとって重要です。アプリケーション層は、考慮すべき最も重要な3つのコンポーネントで構成されています。これらは、アプリケーションソフトウェアコンポーネント、これらのコンポーネントのポート、およびポートインターフェイスです。

ソフトウェアコンポーネントは、サブシステムの機能を保証します。これには、ソフトウェアが必要とする操作とデータ要素、およびコンポーネントが必要とするリソースが含まれます。また、アプリケーションのソースは、対話型コンポーネントの場所、コンポーネントがマップされているECUのタイプ、およびコンポーネントがシステムでインスタンス化された回数とは無関係です。

ランタイム環境（RTE）レイヤー

ランタイム環境レイヤーは、ソフトウェアコンポーネント（SWC）の操作に適した環境を作成します。SWCは、常にRTEによって提供されるインターフェイスに依存しています。

これは、ネットワーク内にあるECU間の通信センターと見なすことができます。これは、ソフトウェアコンポーネントが通信メカニズムやチャネルから独立して動作するのに役立ちます。 RTEは、さまざまなテンプレートに実装されているコンポーネント間の通信関係を、呼び出しなどの特定の内部通信メカニズムまたはCOMメッセージなどのECU間通信メカニズムにマッピングすることでこれを可能にします。

RTEは、SWCのライフサイクルを管理する責任があります。必要に応じて、機能を起動およびシャットダウンする必要があります。また、アプリケーションソフトウェア（ASW）とベースソフトウェア（BSW）の 間の分離レイヤーとしても機能し、ベースソフトウェアはAPI関数または他のモジュールを直接呼び出す権限を持っていましたが、アプリケーションソフトウェアはポートを介してのみ通信できます。

RTEは2つのフェーズで生成されます

コントラクトフェーズ：このフェーズはECUから独立しており、アプリケーションソフトウェアとRTEの間のコントラクトを提供します。つまり、ASWコンポーネントのAPIをコーディングできます。

その結果、ソースコードに含めることができるASWコンポーネント指定のヘッダーが作成されました。ヘッダーファイルは、ASWで使用できるすべてのRTE API関数で構成されており、ASWコンポーネントに必要なデータ型と構造もヘッダーファイルで宣言されています。

生成フェーズ： このフェーズでは、特定のECUの具体的なコードの生成に焦点を当てます。契約フェーズで作成されたASWコンポーネントとヘッダーファイル、および必要なすべてのBSWコードを使用して、生成されたコードをECUの実行可能ファイルにコンパイルできます。

基本ソフトウェア（BSW）

Basic Softwareレイヤーは、AUTOSARソフトウェアコンポーネントにサービスを提供できる標準化されたソフトウェアとして定義でき、ソフトウェアの機能部分を実行するためにも使用されます。基本ソフトウェアには、標準化されたECU指定のコンポーネントが含まれています。

基本ソフトウェア層はさらに、サービス層、ECU抽象化層、マイクロコントローラー抽象化層、および複雑なドライバーの4つの主要部分に分かれています。

I.サービスレイヤー

これは、基本ソフトウェア層の最上位層であり、アプリケーションソフトウェアに基本ソフトウェアモジュールを提供し、マイクロコントローラーおよびECUハードウェアから独立しています。

サービス層は、次のような機能を提供します

メモリサービス（NVRAM管理）
診断サービス（UDSを含む）通信およびエラーメモリ）
車両ネットワークの通信と管理
ECUの状態管理
オペレーティングシステム（OS）

この層の取り付けは、マイクロコントローラー（MCU）、ECUハードウェアの部品およびそれらのアプリケーションに特化しています。

II。ECU抽象化レイヤー

このレイヤーは、外部デバイスのいくつかのドライバーも含むマイクロコントローラー抽象化レイヤーのインターフェイスとして機能します。マイクロコントローラの内部または外部のどこに配置されていても、周辺機器やデバイスにアクセスできます。また、マイクロコントローラーとインターフェイスするためのAPIも提供します。

III。マイクロコントローラー抽象化レイヤー（MCAL）

マイクロコントローラー層は、ハードウェアと通信するためのアクセスルートです。この層は、マイクロコントローラーレジスタへの直接アクセスを回避するためにフレーム化されました。マイクロコントローラ抽象化層（MCAL）は基本ソフトウェアの構成要素への標準インターフェースを確実にするために設計されたハードウェア層です。基本ソフトウェアのコンポーネントにマイクロコントローラーに依存しない値を提供し、マイクロコントローラー周辺機器も管理します。

MCALには通知メカニズムが備わっているため、コマンド、応答、および情報のさまざまなプロセスへの配布をサポートできます。これとは別に、MCALには、デジタルI / O（DIO）、アナログ/デジタルコンバーター（ADC）、パルス幅（De）変調器（PWM、PWD）、EEPROM（EEP）、フラッシュ（ FLS）、Capture Compare Uni（CCU）、ウォッチドッグタイマー（WDT）、シリアルペリフェラルインターフェイス（SPI）、I2Cバス。

IV。複雑なデバイスドライバー（CDD）

この層には、複雑なセンサーやアクチュエーターを処理するための特別なタイミングと機能要件があります。CDDは複雑な機能を処理するために使用され、他のレイヤーにはなく、マイクロコントローラーに直接アクセスする機能を備えています。複雑な機能には、噴射制御、電気的値の制御、位置増加検出などが含まれます。

AUTOSARの目的

AUTOSARは、現在のところに役立ち、将来的にも役立つ特定の理由で作成されました。目的のいくつかを以下に示します。

業界全体の「標準コア」ソリューションとしての基本機能の実装と標準化。
さまざまなサプライヤの機能モジュールの統合。
ライフサイクル全体を通してプロセスを維持するのは簡単です。
プラットフォームに関係なく、さまざまな車両をスケーリングする機能。
冗長性のアクティブ化。
可用性と安全性の要件の考慮。
ネットワーク内のあるECUから別のECUへの機能の簡単な転送。
市販の（COTS）ハードウェアをさらに使用する。
車両の寿命を通じて定期的なソフトウェアの更新とアップグレード。

AUTOSARのメリット

AUTOSARは、車両のライフサイクルのさまざまな段階でさまざまなメリットをもたらします

OEM： AUROSARを使用すると、異なるOEMに対して同じソフトウェアコードを何度も使用できます。さまざまな設計に適応するための柔軟性が高まり、製造の時間とコストも削減されます。

サプライヤー：サプライヤーは、機能開発の効率を高め、自分に適した独自のビジネスモデルを作成できます。

ツールプロバイダー： AUTOSARには、ツールプロバイダーが開発プロセスを標準化するのに役立つ共通のインターフェイスがあります。

新規市場参入者：新規参入者にとって、AUTOSARは、業界標準を理解し、独自のビジネスモデルを作成するのに役立つ透過的で定義されたインターフェイスとして機能します。

AUTOSARを通じて何を期待できますか？

AUTOSARは、自動車業界のさまざまな部門にさまざまな目的を果たすように設計されています。用途が広く柔軟性があるため、それ以外にも多くのことができます。AUTOSARが提供できる基本的な成果のいくつかは、その中のソフトウェアを複数のユニットで再利用できることであり、使用するソフトウェアはいつでも交換できます。 AUTOSARは、すべての車両ソフトウェアの標準プラットフォームとして機能し、独自のアプリケーションはありません。

基本的な機能とインターフェースソフトウェアを備えたOSを備えており、主な利点は、すべての基本的なソフトウェアで同じインターフェースを使用できることです。AUTOSARの機能はソフトウェアコンポーネントとして提供され、関連するすべてのコンポーネントはハードウェアに依存しません。