Classic Platform

Classic Platformについて 

AUTOSAR Classic Platform のアーキテクチャでは、最上位の抽象レベルにおいて、マイクロコントローラ上で動作する 3 つのソフトウェアレイヤー（アプリケーション、Runtime Environment（RTE）、Basic Software（BSW））を区別しています。 

• アプリケーションソフトウェアレイヤーは、大部分がハードウェア非依存です。 
• ソフトウェアコンポーネント間の通信および BSW へのアクセスは、RTE を介して行われます。 
• RTE は、アプリケーション向けの完全なインタフェースを提供します。 
• BSW は、3 層の主要レイヤーと Complex Driver に分かれます。 
  • Services Layer、ECU (Electronic Control Unit) Abstraction Layer、Microcontroller Abstraction Layer (MCAL) 
• Services Layer はさらに、System Service、Memory Service、Communication Service のインフラストラクチャを構成する 3 つの Functional Group に分類されます。 

最新のリリース 

AUTOSAR Classic Release R25-11

コンセプト 

重要なコンセプトのひとつが、Virtual Functional Bus（VFB）です。この仮想バスは、アプリケーションをインフラストラクチャから分離します。通信は専用ポートを介して行われるため、アプリケーションソフトウェアの通信インタフェースは、これらのポートへマッピングされる必要があります。VFB は、単一 ECU 内の通信と ECU 間通信の両方を管理します。アプリケーションの観点では、下位レベルの技術や依存関係に関する詳細な知識は不要です。これにより、ハードウェア非依存なアプリケーションソフトウェアの開発および利用を支援します。 

AUTOSAR のレイヤードアーキテクチャは、ソフトウェアおよびハードウェア非依存性を実現するために必要なすべての機構を提供します。マイクロコントローラ（µC）上で動作する3つの主要ソフトウェアレイヤー（Application Layer、Runtime Environment（RTE）、Basic Software（BSW））を区別しています。 

異なる車載ドメインのアプリケーションは、RTE を介して Basic Software と接続します。 

AUTOSAR は、アーキテクチャやインタフェースの定義に加えて、完全な AUTOSAR スタックのコンフィグレーションを可能にし、異なるツールチェーン間の相互運用性を向上させるためのメソドロジーも定義しています。これは、開発プロジェクト内での協業を促進するとともに、開発コスト削減にも重要な役割を果たします。 

アーキテクチャ 

標準化された ECU ソフトウェアアーキテクチャの主なコンセプトは、ソフトウェア抽象化レイヤーである RTE（Runtime Environment）を介して、ハードウェア非依存のアプリケーションソフトウェアと、ハードウェア指向の Basic Software（BSW）を分離することです。RTE の上位層では、この抽象化レイヤーにより、OEM 固有の競争力あるソフトウェアアプリケーションの開発が可能になります。一方、RTE の下位層では、Basic Software（BSW）の標準化と OEM 非依存性を可能にします。さらに、AUTOSAR ソフトウェアアーキテクチャの特徴として、複数の車種ラインおよびバリアントに対応可能な ECU ソフトウェアのスケーラビリティ、アプリケーション（機能ソフトウェアモジュール）を複数 ECU 間へ分散配置できること、さらに異なる供給元のソフトウェアモジュールを統合できることが挙げられます。 

AUTOSAR ソフトウェアアーキテクチャ内の Basic Software（BSW）は、さらに Services Layer、ECU Abstraction Layer、および Microcontroller Abstraction Layer（MCAL）の各レイヤーに分割されます。RTE によって実現されるアプリケーションレイヤーと Basic Software（BSW）の分離には、これらのレイヤー間におけるデータ交換の制御も含まれます。これにより、ソフトウェアコンポーネント（SW-C）を個別単位とする、アプリケーションレベルのコンポーネント指向かつハードウェア非依存なソフトウェア構造の基盤が形成されます。ハードウェア非依存であるため、使用中または導入予定のハードウェアに関する特定知識がなくても SW-C を開発でき、さらに開発中に既存の SW-C を別 ECU へ柔軟に再配置することも可能です。

メソドロジーおよびテンプレート 

AUTOSAR は、ソフトウェアアーキテクチャに加えて、車載ソフトウェア開発向けの統一されたメソドロジーアプローチを導入しています。これは主に、今日の車載開発プロジェクトに関わるさまざまな関係者間の協調を改善するニーズによって推進されています。 

AUTOSAR は、ECU 上へのソフトウェアコンポーネント統合、およびさまざまなバスシステムを介したネットワーク通信全体に異なる ECUを統合するのに必要な、あらゆる側面を定義するための手段を提供します。このメソドロジーは、活動と成果物の依存関係を定義するとともに、AUTOSAR における活動、記述、およびツール利用を支援することを想定しています。 

記述（.arxml）は AUTOSAR Templates に基づいており、これらのテンプレートでは、正式なデータ交換形式（AUTOSAR Schema）と、それに付随する意味的制約が定義されています。記述（.arxml）は、AUTOSAR メソドロジーにおいて生成・利用される情報を保持するために用いられます。さまざまなジェネレータは、記述に含まれる情報を利用して、RTE および AUTOSAR Basic Software（オペレーティングシステムを含む）のコンフィグレーションおよび生成を支援できます。 

AUTOSAR Classic Platform ワークフロー例 

以前から、特に Classic Platform における AUTOSAR の具体的な活用方法について、実践的な例を提供してほしいという要望をパートナーからいただいていました。AUTOSAR は、この要望に応えました。市場には、さまざまなツールやパートナー固有のソリューションが存在することを認識しています。そのため、提供するソリューションについては、これら各種ツールや独自機能に依存しない中立的な立場を維持するよう努めています。 

そのため、この非依存性を確保するために、さまざまなツールチェーンを用いてソリューションを評価しています。また、プロジェクトごとに異なる開発の進め方についても考慮しています。AUTOSAR が提案する本来の手法はトップダウンアプローチであり、すなわち車両システム記述から開始し、車載ネットワーク内の個別 ECU への機能割り当てへ段階的に落とし込み、その結果としてネットワーク通信マトリクスを作成するというものです。しかし、このアプローチが実際の開発現場で常に適用できるとは限らないことも認識しています。一部のプロジェクトでは、既存の通信マトリクスと制御ユニット構成の手動設定のみに基づいて、個別の制御ユニットを定義している場合もあります。 

この「最も中立的な」構成を対象とした最初のイテレーション（Iteration 01）として、AUTOSAR はトップダウンアプローチの実装に必要な成果物を提供することを決定しました。これらの成果物および対応する記述は、本ページから ZIP ファイル形式で入手できます。これらの成果物をツールチェーン上で処理する方法については、ZIP ファイル内の「AUTOSAR_CP_TR_WorkflowExample.pdf」を参照してください。 

提供された System Extract を検証した後、ASW （Application Layer）の C ソースコードをリクエストすることもできます。これにより、CAN をサポートする µC ターゲットハードウェア上で実行可能な HEX ファイルを作成できます。 

ZIP ファイルのダウンロードはこちらから。 

今回の公開を通じて、パートナーの皆様にも次のイテレーション（Iteration 02）へ共同で取り組んでいただきたいと考えています。最初のイテレーションでは、CAN バスで接続された 2 つの ECU を用いた非常にシンプルな例を実装しました。次のイテレーションでは、 

1. バス上の通信に参加する ECU の数を増やす
2. Ethernet 通信も設定する 
3. AUTOSAR Adaptive Platform ECU との接続を確立する
4. あるいは、皆様のアイデア次第でさまざまな展開も可能です。

次回以降のイテレーションに共同で取り組むためのワーキンググループ設立にご興味がありましたら、Martin Lunt までメールでご連絡ください。