eSOL Marketing Official Blog

AUTOSAR導入で「Code Generatorのしもべ」に?

2024/11/14 13:53:51

本記事では、『AUTOSAR導入で「Code Generatorのしもべ」に?』と題し、AUTOSAR XMLの利活用について、弊社のSafety/Security シニアエキスパートでありAUTOSARの仕様策定にも参画している櫻井からご紹介いたします。



 

今回のお題:AUTOSAR XMLの利活用

9月4~6日に幕張メッセで開催されたイベント「Automotive World」の中のカンファレンス「SDV Forum X」に参加いたしました。
この2日目、「AUTOSAR Day」と銘打たれた9月5日には、計4つの講演からなるプログラム企画をお任せいただきまして、多数の方にご聴講いただきました。
ご講演・ご来場くださいました皆様、まことにありがとうございました。


この冒頭のAUTOSARによる講演枠の前半部分で、私からはプログラムの紹介と短い講演を行いました。
今回は、その講演内容をご紹介したいと思います。

 

おさらい #1:AUTOSAR CP BSWにおける固定・可変部分と、SWSの構成 (章立て)

AUTOSAR Classic Platform (CP) のBasic Software (BSW) は、さまざまな自動車メーカー向けの各種ECUで使用されていますし、最近は自動車以外の用途での利用も広がっています。

当然ながら、BSWは、差異のない (あるいは、差異を意図的に持たせない) 固定の要素もありますが、使用される場面によって以下の要素のように異なり得る・変わり得る部分があります (可変要素)。

  • a) それそのものに期待される振る舞い
  • b) それが使われるコンテキストに左右される部分 (ex. 使用するインタフェース etc.)

それらの「差異」に対応するために、多数の「設定スイッチ」(configuration parameterやcontainer) を用意しており、その設定内容は、AUTOSARが定めるXML形式であるARXML (AUTOSAR XML) として記述されます。

その基本的な記述形式は、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に対するアクセス方法 etc.) を記述

  2. SW-C間の論理インタフェース (またはそこに現れてくる、さらに論理レベルの高いインタフェース): 
    AUTOSAR CPでのApplication Interface関連文書や、ISO 23150 (自動運転用センサーとフュージョンユニット間の論理インタフェース ※現行の2021年版に対し、AUTOSAR APでのプログラミングインタフェースとしてara::adi::sensoritfを提供)、JASPAR AD/ADAS車両制御インタフェース仕様書, COVESA VSS etc.

  3. ECU間通信インタフェース (ネットワークプロトコル):
    AUTOSARではPRS (Protocol Specification) 文書にて規定。


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



AUTOSAR XML (ARXML) は、何を表現している?

よくある解説の仕方は、以下のようなものではないかと思います。

  1. BSWに関する多数の「設定スイッチ」(configuration parameterやcontainer) の情報: BSWの可変部分のコード生成に使用
  2. SW-Cのインタフェース定義や、SW-C内部の関数 (Runnable Entity) やそれらのトリガ条件などの情報: RTEコード生成に使用

しかし、その本質を見つめ直してみると、以下を機械的に処理可能な形式化されたデータ (machine readableな形) で表現しているということもできます。

  1. 再利用したい対象そのものへの期待に関する情報 (振る舞いやインタフェース) のうち「可変部分」
  2. 統合したい対象 (単発利用を想定したものか再利用を想定したものかは問わず) が投入されるコンテキストに関する情報 (統合される先の可変要素や、統合あるいは再利用した他のものに関する、振る舞いやインタフェース) のうち「可変部分」

つまり、各種検証の自動化、例えば、テスト環境のセットアップやテストシナリオの自動生成・切り替えなどの各種のテスト自動化や、テスト以外の手法による検証におけるツール支援に使える、「可変部分」に関する情報を多数含んでいる、ということもできます。
もちろん、検証の自動化のためには、「可変部分」だけではなく「固定部分」の情報も必要になります。しかし、それらは検証環境においても「固定」の部分として組み込むことができるはずです。

さて、これらの情報、「BSWやRTEのコード生成に使ってそれでオシマイ」としていたら、もったいないと思いませんか?

また、そんな形での「AUTOSAR導入」は、ある意味、

「Code Generatorのしもべ」

という状態ではないでしょうか?

実際、ここしばらくのイベントでお目にかかった方々からも、「BSW設定作業は苦痛」「そして、ちょっと設定変更したらまた検証環境をセットアップし直すのはもっと大変」というお声を多数いただいていますが、その際に

「設定データって、再利用可能なものに期待する振る舞いや、
それが投入されるコンテキストの情報を多数含んでいますよね?
それらを検証の自動化に使っていますか?」

とお聞きしたところ、残念ながら回答はいずれもNoでしたが、一方、

「その利活用の可能性は検討するに値する」

というお声もいただいています。

AUTOSAR Method

※櫻井が講師をつとめる「AUTOSAR Classic Platform (CP) 入門トレーニングコース」では通常ご紹介していない資料部分からの抜粋。
(日々増強されており、現在1100ページ以上あるのですが、時間枠の都合で1/2程度しかご紹介できません。しかし、いただいたご質問によって、それらの部分をご覧に入れることがあります。)
なお、2024年11月29日まで、キャンペーン価格で上記コースをご提供しています。



次回に続く

今回は、まずは、AUTOSAR XMLの利活用のヒントのご紹介と、それをご理解いただくための前提知識の解説を行いました。

次回は、今回の内容を踏まえて、利活用の可能性についてのより具体的な議論と、再利用性や保守性を左右する「Variant」との向き合い方について解説いたします。


イーソル株式会社 ソフトウェア事業部 エンジニアリング本部 エンジニアリング管理部
Safety/Security シニアエキスパート 

櫻井 剛


【櫻井のMONOist連載はこちら】
AUTOSARを使いこなす(MONOist)




イーソルでは櫻井が講師を務めるAUTOSAR CPの入門トレーニングを提供

以上、本記事では『AUTOSAR導入で「Code Generatorのしもべ」に?』の前編を櫻井よりご紹介しました。

イーソルでは、櫻井が講師を務めるAUTOSAR Classic Platform (CP) 入門トレーニング」を提供しています。本トレーニングでは、AUTOSARというソフトウェアプラットフォームの技術面の解説をするだけではなく、その運用に役立つ上記のようなヒント・解説も含んでおり、オプションでQ&A時間枠をご用意することも可能です。

「AUTOSARを使いこなす」ことについて、その多義性を踏まえた見直しを行うことは、SDVの時代への備えにもつながります。
すでにAUTOSARを用いた開発のご経験をお持ちの方も、さらなる「使いこなし」のために、これを機にご受講いただいてはいかがでしょうか?

 
マーケティングコミュニケーション部 N.M

最近の記事

ブログの更新通知を受け取る