　その基本的な記述形式は、AUTOSAR TPS ECU Configurationという文書で規定されています。そして、RTEや各種BSWの個別のconfiguration container/parameter内容は、RTEや各種BSWの詳細を規定するAUTOSAR SWS文書の、RTEであればchap.8の「RTE ECU Configuration」、BSWであればchap.10の「Configuration specification」に定義されています。

　また、固定／可変の要素とともに、BSWであれば振る舞い部分はSWS文書のchap.7の「Functional specification」と補足的にchap.9の「Sequence diagrams」、インタフェース部分はchap.8の「API specification」に記述され、公開されています^※1）。

※1）これらの文書はAUTOSARでの標準化活動を経て作成され（標準化活動への参加には一定のAUTOSAR Partner資格が必要）、一般に公開されています。なお、公開されている内容であっても、商用利用には、商用利用可能なAUTOSAR Partner資格への加入が必要です。

　なお、Adaptive Platform（AP）でも、章立てなどの差異はありますが、上記の範囲での基本的な考え方は同じと考えてよいでしょう。

おさらい＃2：SW-Cにおける固定／可変部分と、関連文書

　先に「BSWやRTEの振る舞いやインタフェースは、可変の要素もあれば固定の要素もあり、それらは標準化されている」と述べましたが、さて、SW-Cではどうでしょうか?

　SW-Cは、そもそも、「標準化された基本機能サービス」を提供するBSWとは異なり、標準化されていない範囲の各種アプリケーションを実現する部分です。

　これらについては、以下の例のように多様な論理レベルで定義／標準化が可能ですので、少々複雑です。

1）SW-C－RTE間インタフェースの基本形とインタフェース実現手段：
- TPS Software Component Template：データの授受のためのSender-Receiver Interfaceなどのインタフェース種別やSW-Cの種別それぞれについての、ARXML形式でのモデリングであり、SW-C内部の振る舞い定義（Runnable Entityと呼ばれる関数群やそれらのトリガー条件、排他制御メカニズムなど）を含む
- SWS RTE：データ授受のためのSender-Receiver Interfaceなど、インタフェース種別それぞれについて、対象データに関わらない全般的な定義（Rte_ReadやRte_WriteなどのC-API形式のプログラミングインタフェースの基本形や、RTE内部の振る舞いの定義）と、データごとに異なる／変えることができる部分の定義（実際のデータごとのAPI名がどのように決められるか、各Portに対するアクセス方法など）を記述
2）SW-C間の論理インタフェース（またはそこに現れてくる、さらに論理レベルの高いインタフェース）：
- AUTOSAR CPでのApplication Interface関連文書や、ISO 23150（自動運転用センサーとフュージョンユニット間の論理インタフェース。現行の2021年版に対し、AUTOSAR APでのプログラミングインタフェースとしてara::adi::sensoritfを提供）、JASPAR AD/ADAS車両制御インタフェース仕様書、COVESA VSS（車外から車内のデータをアクセスするためのカタログですが、当然SW-C間論理インタフェースにも影響してきます）など
3）ECU間通信インタフェース（ネットワークプロトコル）：
- AUTOSARではPRS（Protocol Specification）文書で規定

　いずれにしても、アプリケーションごとに定義していくのが基本ですが、ある範囲では同じ振る舞いとなる部分があるのであれば、もちろん再利用や標準化を考えるべきでしょう。

AUTOSAR XML（ARXML）は、何を表現しているのか

前のページへ 1|2|3 次のページへ