先日公開したこちらの記事では、AUTOSAR（Automotive Open System Architecture）の概要についてご紹介しました。
今回は、AUTOSARの規格であるAUTOSAR Classic PlatformとAUTOSAR Adaptive Platformの違いについて解説します。
| 目次 1. AUTOSARの概要（おさらい） 2. 次世代車両・車載ソフトへの要求 3. AUTOSAR Classic Platform、AUTOSAR Adaptive Platformの違い 4. 最後に |
1. AUTOSARの概要（おさらい）
最初に、AUTOSARの概要を簡単におさらいします。近年の自動車開発においてソフトウェア開発の重要度はますます高まっており、新たな要求が今後も増えていくとみられています。
大規模化・複雑化する車載ソフトウェア開発の課題を解決するために、車載ソフトウェアプラットフォーム標準仕様の開発パートナーシップであるAUTOSARが発足しました。
過去のソフトウェア資産を「再利用」し、開発工程の「自動化」を進めること、およびその再利用や自動化を進めるために不可欠な「標準化」を目的としています。
AUTOSARでは、静的OS(OSEK/VDX OSベース)を用いた規格であるClassic Platform(CP)に加え、2017年に動的OS(POSIXベース)を用いたAdaptive Platform(AP)も公開されています。
本記事でご説明しますが、APはCPの上位バージョンではないので、APが出たからと言ってCPがなくなるわけではありません。
CPとAPは、適材適所で共存し、相互に連携しあい、統合システムを形成するものです。
2. 次世代車両・車載ソフトへの要求
CPとAPの違いを解説する前に、次世代の車両や車載ソフトウェア開発のプラットフォームに何が求められているかについて触れておきたいと思います。
車載分野ではよく知られる言葉ですが、メルセデス・ベンツを擁するダイムラー社が発表した中長期戦略で「C.A.S.E」というものがあります。C.A.S.Eは、下記の言葉の頭文字を取った造語です。
Connectivity – コネクティビティ
Autonomous / automated Driving (AD) – 自動運転
mobility Sharing services－モビリティ シェアリングサービス
Electric Vehicle (EV)－電動化された乗り物
この4つキーワードが軸となり、車が再発明・再定義されていると言われています。
自動車を取り巻く環境が大きく変化してきており、ソフトウェアにおける課題を解決するための新たなソリューションが求められています。
次世代の車両や車載ソフトウェアプラットフォームに求められる課題としては、下記の4点が挙げられます。
- Shorter time to market (市場投入までの時間短縮)
- New E/E architecture （新たなE/Eアーキテクチャ）
- Embedded HPC （組込みハイパフォーマンスコンピューティング）
- Safe and secure connected-services （安全で安心なコネクテッドサービス）
それぞれ、具体的に求められる機能については下記図をご参照ください。
（※画像をクリックすると拡大します。）
このような高度な要求に応えるためには、従来の静的なOSをベースとしたCPでは実現が難しいため、動的OSをベースにしたAPが新たに登場しました。APを導入することによって、自動運転で求められるような異なるドメイン間の高度な連携や動的な機能の拡張を実現することができます。
3. AUTOSAR CPとAPの違い
では、具体的なCPとAPの違いについて見ていきましょう。
前述の通り、CPは静的なOSEK/VDX OSベースになっており、リアルタイム性を求めるが演算能力はそこまで求めないECUを想定しています。
一方APは動的なPOSIXベースで、自動運転などに対応するために求められる演算能力は高くなっています。
下記では、CPとAPの違いをまとめています。
| Classic Platform（CP） | Adaptive Platform（AP） | |
| 使用するOS | OSEK/VDX OSベース | POSIXベース（IEEE Std 1003.13-2003におけるMinimal Realtime System Profile：PSE51） |
| 開発言語 | C | C++ |
| アプリケーション（App.）の実行 | コードをROM上で直接実行 | App.をROMなどからRAMにロードしてから実行 |
| メモリ空間 | 単一アドレス空間で全ての処理が実行される ※MMUが使用されることはまれで、MPUが使用されるのは、主に安全面の理由で必要となった場合のみ |
各App.はそれぞれの（仮想）アドレス空間で実行される ※MMU利用が前提 |
| 想定する起動時間の要求 | 短 | 中 |
| 想定するリアルタイム性要求 | 高 | 中～高 |
| 想定する利用可能な演算能力 | 低 | 高 |
| 処理実行スケジューリング方式 | （基本的には）固定されたタスクスケジューリング | 提供するサービスやその要求が変化するたびにスケジューリングが動的に変化 |
| 通信 | 比較的低速のシグナル指向のコネクションレス型通信に特化（ECU間ではCAN／CAN FD、LIN、FlexRay） ※SOME/IPにも対応することで、APベースのECU群ともある程度は通信可能 |
サービス指向型通信（ECU間ではSOME/IPプロトコルなど） ※一部を除きシグナル指向型通信にも対応することで、CPベースのECU群とも通信可能 |
| 想定する安全面の要求 | ASIL Dまで | ASIL B～Dまで ※要求に依る |
| OTS／OSSの利用 | Simulinkモデルやその生成コード／オブジェクトなどの形での授受が中心 | あり～多数 ※ただし、ブラックボックスとしての利用には不安の声もあり、意見が分かれる |
| 標準化における成果物 | 規格文書 | 規格文書およびコード（Code） |
| 標準規格や市場などの安定の度合い | 高 | 低 |
| 想定用途 | 従来型の制御系ECU | 自動／自律運転で追加されたECUや、ゲートウェイ／ドメインコントローラー |
上記のポイントとしては、想定する演算能力がCPは数十MHz程度で動く制御ECUからを対象にしているのに対して、APでは自動運転や統合制御など、高い演算能力が求められるのが特徴です。よって想定用途についても、CPが従来型の制御系ECUを想定しているのに対し、APでは自動運転等で追加されたECUや、ゲートウェイ、ドメインコントローラーなどを想定しています。
APについては、加えて下記のような特長が挙げられます。
C++
・C++で開発可能となったことで、C言語で作成した過去の資産を活かしつつ、C言語では実現が難しい設計(*)が可能
(*)オブジェクト指向を活用することで、各モジュールの役割を明確化しつつ、モジュール間の結合度を下げた設計など
Safety and Security
・ SOAに基づいた分散コンピューティングにより、各モジュールの独立性を高め、意図しない干渉を発生させないアーキテクチャ
・ 独自のC++コーディングガイドラインを規定することにより、実装レベルで必要な安全性・信頼性を確保可能
Planned Dynamics
• アプリケーションのリソースや通信を動的に管理することにより、継続的なアップデートを前提としたアーキテクチャ
→アップデートによる変更の影響箇所を局所化し、ソフトウェアの検証や統合に要する労力を軽減可能
• 安全性を脅かすリスクを減らすため、Execution Manifest(*)を用いた適切なスケジューリング&リソース管理が可能
(*)Adaptive Application（AA）単位で作られ、AAを動作させるために必要な設定を自動化するための情報を含んだもの
4. 最後に
いかがでしたでしょうか。
今後の車載ソフトウェア開発において、AUTOSARへの理解、および導入はますます重要になってきます。
前回の記事でもご紹介した通り、イーソルは2016年からプレミアムメンバーとして、現在も仕様の策定など、標準化活動に深く関与しています。
AUTOSARを導入したいが何から初めれば良いかわからない、AUTOSARについてさらに詳しく知りたいという方は、ぜひイーソルまでお問い合わせください。
・お問い合わせはこちらから
・関連Webページ
・関連サービス 資料
- AUTOSAR Classic Platform(CP) 入門トレーニング
AUTOSAR CPの全体像を短期間で理解することができるトレーニング - AUBIST Classic Platform
AUTOSAR Classic Release 4.x準拠のBSW製品及びサービス - AUBIST Adaptive Platform
AUTOSAR Adaptive 準拠(追従予定)のソフトウェアプラットフォームを提供
マーケティング室 S.A
