AUTOSAR Adaptive Platformとは?:AUTOSARを使いこなす(7)(3/3 ページ)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第7回では、AUTOSAR Classic Platformに次いで新たに登場したAUTOSAR Adaptive Platformについて説明する。
各種車載プラットフォームの性質の比較
AUTOSARのCPとAPをはじめ各種車載プラットフォームの性質の比較をまとめたのが表1です(参考文献[4]や、市場動向などに基づく私見も入っています)。少なくとも、APとIVIは、CPとはだいぶ異なる性質があることはお分かりいただけることと思います。
Classic Platform(CP) | Adaptive Platform(AP) | 一般的なインフォテインメント(IVI)向けプラットフォーム | |
---|---|---|---|
使用するOS | OSEK/VDX OSベース | POSIXベース(IEEE Std 1003.13-2003におけるMinimal Realtime System Profile:PSE51) | 各種 ※筆者の知る限りではPOSIXベースが多い |
開発言語 | C | C++ | 各種(C++など) |
アプリケーション(App.)の実行 | コードをROM上で直接実行 | App.をROMなどからRAMにロードしてから実行 | App.をROMなどからRAMにロードしてから実行 |
メモリ空間 | 単一アドレス空間で全ての処理が実行される(MMUが使用されることはまれで、MPUが使用されるのは、主に安全面の理由で必要となった場合のみ) | 各App.はそれぞれの(仮想)アドレス空間で実行される(MMU利用が前提) | 各App.はそれぞれの(仮想)アドレス空間で実行される(MMU利用が前提) |
想定する起動時間の要求 | 短 | 中 | 長 |
想定するリアルタイム性要求 | 高 | 中〜高 | 低 |
想定する利用可能な演算能力 | 低 | 高 | 中〜高 |
処理実行スケジューリング方式 | (基本的には)固定されたタスクスケジューリング | 提供するサービスやその要求が変化するたびにスケジューリングが動的に変化 | 提供するサービスやその要求が変化するたびにスケジューリングが動的に変化 |
通信 | 比較的低速のシグナル指向のコネクションレス型通信に特化(ECU間ではCAN/CAN FD、LIN、FlexRay) ※SOME/IPにも対応することで、APベースのECU群ともある程度は通信可能 |
サービス指向型通信(ECU間ではSOME/IPプロトコルなど) ※一部を除きシグナル指向型通信にも対応することで、CPベースのECU群とも通信可能 |
各種(自動車メーカー固有のプロトコルが多数となることもあり、また、AUTOSARでは対応しないMOSTなどを利用することも) |
想定する安全面の要求 | ASIL Dまで | ASIL Bまで(?) ※ASIL Dまで必要、という声も |
QM(?) ※制御に関わる場合には、より高いASILが必要という声も(例:高精度地図を用いた制御など) |
OTS/OSSの利用 | Simulinkモデルやその生成コード/オブジェクトなどの形での授受が中心 | あり〜多数 ※ただし、ブラックボックスとしての利用には不安の声もあり、意見が分かれる |
ブラックボックスとしての利用も多数 |
標準化における成果物 | 規格文書 | 規格文書およびコード(Code) | AGLやGENIVIアライアンスではOSSとして公開 |
標準規格や市場などの安定の度合い | 高 | 低 | 中 |
想定用途 | 従来型の制御系ECU | 自動/自律運転で追加されたECUや、ゲートウェイ/ドメインコントローラー | インフォテインメント系ECU、HUD、高解像度ディスプレイベースのメーター |
表1 各種プラットフォームの比較 |
なお、当初は、CPとIVIの間の別の独立した存在としてAPが位置付けられる想定で紹介されることが多かったのですが、最近はその表現を見掛けなくなりました。実際、APとIVIは相対的には近いこともあり、両者を包含する形でソリューションを提供するとしているプラットフォームのベンダーも見掛けるようになっています。
また、IVI自体の位置付けも変化しているようです(例えば、制御にどれだけ関わるかなど:制御に関わる機能が自動/自律運転専用ECUに移転され、制御に関わらないようになるのであれば、スマートフォンやタブレット端末などの持ち込み機器で十分という見方など)。機能配置の見直しや、ベンダー各社のソリューション提供形態、周辺ツールや開発ワークフローなど周辺要因の相互作用によって、APがカバーする範囲も決まっていくことになるでしょう。
次回に続く
APのソフトウェアアーキテクチャの解説までやってしまおうと思いましたが、既に結構な分量になってしまいました。今回はきりの良いところで終わりにして、次回はAPのアーキテクチャの解説を行います。
参考文献
[1]AUTOSAR Foundation Release Overview(2016年11月のFO R1.0.0以降の各バージョン)
[2]CARS @ EDCC2015 workshopでのAUTOSARによる講演資料(last access:2019年1月21日)
[3]AUTOSAR AP R18-10 Adaptive Platform Release Overview
[4]AUTOSAR Introduction(last access:2019年1月21日)
Copyright © ITmedia, Inc. All Rights Reserved.
関連記事
- ≫連載「AUTOSARを使いこなす」バックナンバー
- ≫連載「AUTOSARとは?」バックナンバー
- ≫連載「AUTOSAR〜はじめの一歩、そしてその未来」バックナンバー
- AUTOSARの歴史と最新動向に見る、Classic PlatformとAdaptive Platformの関係
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第6回では、2018年11月時点でのAUTOSARの最新動向を紹介するとともに、Classic PlatformとAdaptive Platformの関係について説明する。 - 日本の自動車業界の「当たり前」は、なぜAUTOSARの「当たり前」にならないのか
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載の第5回では、第4回で挙げた避けるべき代表例の1つ「標準をただ従うものとして捉えること」について掘り下げてみよう。 - 日本にありがちな“やらされAUTOSAR”による思考停止から解き放たれよ
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。第4回では、AUTOSARに何らかの期待を抱いて取り組みを進める上で、避けるべきことについて考えてみよう。 - AUTOSARを「使いこなす」ということを考えてみる(後編)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。第3回では、「AUTOSARに対する期待は何か?」という問いへの答えを考えてみよう。 - AUTOSARを「使いこなす」ということを考えてみる(前編)
車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。技術面の解決に取り組むだけではなく、AUTOSARを扱う際に陥りがちな思考から解き放たれることで、AUTOSARともっとうまく付き合っていくことができるかもしれない。 - AUTOSARの最新動向:2018年3月版
既に量産車への適用が始まっている車載ソフトウェア標準「AUTOSAR」。これまでMONOistでAUTOSARの解説連載を2回執筆してきた櫻井剛氏が「AUTOSARを使いこなす」をテーマに新たな連載を始める。第1回は、まず現状を確認するためにAUTOSARの最新動向を紹介する。