AUTOSAR Adaptive仕様策定ワーキンググループ活動とSCSKの取組み

SCSKの綾野と申します。エンジニアブログは初の投稿となります、購読いただいている皆様、よろしくお願いいたします。

 

さて、今回のエンジニアブログでは私が約4年の間AUTOSAR Adaptiveの仕様策定ワーキンググループ（WG-AP-ST）に参加、活動してきた経験やWG-AP-STのスピーカーとして取り組んできた内容を個人の感想を交えてAUTOSARパートナー以外の方々にも分かりやすくお伝えします。AUTOSARの仕様策定活動って？ワーキンググループって何しているの？と、外からは分かりにくい情報をお伝えすることで、ワーキンググループ活動に興味を持っていただき、さらには実際に参加いただけることを期待しています。

AUTOSAR仕様とは？

AUTOSARの仕様は大きく分けて以下の3つに分類されます。
●AUTOSAR Classic(CP)
AUTOSAR Classicに関係する仕様
●AUTOSAR Adaptive(AP)
AUTOSAR Adaptiveに関係する仕様
●AUTOSAR Foundation(FO)
Adaptive Classic両方に共通する仕様

参考までに仕様の流れを図示したものは以下の通りです。

出典：https://www.autosar.org/fileadmin/user_upload/AUTOSAR_EXP_Introduction_Part1.pdf

AUTOSAR Adaptiveが策定され、ClassicとAdaptiveで共通する仕様はFoundationという仕様に切り出されています。Foundationが作られた当初は多くの共通仕様がClassicとAdaptiveの仕様書にありましたがR20-11リリースではAdaptiveからFoundationへ移行され、Foundationの文書も充実しつつあります。

 

最近ではAD/ADASの進化から、そこに必要なインターフェイスを共通化するための仕様も出てきています。Application InterfacesやSensor Interfacesがそれに当たります。このあたりは若い仕様なうえにOEM、サプライヤー、ソフトウェアベンダーで共通化の必要がある仕様ですので、注目すべきポイントの一つです。

 

AUTOSAR Adaptiveに関しては仕様だけでなくDemonstrator実装も提供されています。これはAUTOSARのパートナーのみに公開されています。基本的にはAdaptiveの仕様が実際に有効かどうかを実装ベースで確かめるためのものです。製品として利用はできませんが、Adatpiveがどういうものなのかを理解するのには非常に役立ちますのでパートナーの皆様は是非活用してみてください。

AUTOSAR Working Groupの組織図

AUTOSARの組織図は以下のようになっています。(2021年9月現在)

出典：https://www.autosar.org/fileadmin/user_upload/AUTOSAR_EXP_Introduction_Part1.pdf

上図の四角で囲まれた（WG-X）がワーキンググループです。ワーキンググーループ自体も仕様に合わせて、Cross-standard Working GroupとCP(Classic Platform)、AP(Adaptive Platform)のみの機能グループに分かれています。

 

Cross-stanrad Working GroupはCP、AP双方に影響のあるチームです。例えばWG-DIA（故障診断）はAP、CP双方に必要な機能であり、それぞれのレイヤを1つのチームで検討しています。

 

さらに、Cross Working Groupの中にも4つのリードワーキンググループというのが存在します。AUTOSAR仕様の中でも重要な機能を司るチームとなります。例えばWG-Aはアーキテクチャチームとして、CPやAPに対して仕様が正しいか、入れるべきかどうかなどの判断を統合的に行っています。コンセプト仕様を入れる際には必ずアーキテクチャチームの判断が必要です。

 

CP、APそれぞれの機能ごとにチームも存在します。例えばRTE(Runtime Environment)はCPにしか無いので、WG-CP-RTEとなっていますし、EMO(Execution Main &OS)はAPにしかないのでWG-AP-EMOという名前となっています。

WGのチーム構成

各ワーキンググループの中には下記の役割があります。

 

●PL(プロジェクトリーダー)
WGのプロジェクトの管理者。上位層のPLチームに所属しAUTOSAR全体としてWG同士の連携なども図る。
●Speaker(リーダー)
WGのリーダーとしてWGを運営する。WGの会議運営、WGのタスク管理、WGのスピーカー同士の連携などを行う。
●メンバー
WGのメンバーとして活動する。WGで行うべきタスクを実行する。

 

WGによってはサブグループというレベルまで細かいチーム分けがなされている場合もあります。例えばCPとAPにまたがるチームの場合、XX-CP、XX-APのように各プラットフォーム向けのサブグループがあることもあります。

WGに参加するには？

AUTOSARのDevelopment Partner以上のパートナーシップに参加する必要があります。パートナーシップによってかかる金額や必要な貢献度が変わります。

出典：https://www.autosar.org/fileadmin/user_upload/AUTOSAR_EXP_Introduction_Part1.pdf

 

この表のAnnual ContributionがWGへの貢献度です。
例えば、Premiumの1.5FTEというのは、年間1.5人AUTOSARのWGに参加し、仕様策定に貢献するということになります。

システムテストWG（WG-AP-ST）の活動

SCSKでは2017年よりシステムテストWGに参加し貢献を行ってきました。本WGのより具体的な活動内容に関して説明していきます。

システムテストの目的

システムテストの目的は「AUTOSARの仕様が正しいことをコードを用いて検証する」です。

各WGにて策定されたRS(Requirements)仕様がDemonstratorのコードを用いて動作し、仕様を満たしているか？を確認していきます。

 

 

先に述べたようにAPにはDemonstrator実装も公開されています。これは仕様に基づいてAUTOSARが公式に実装したコードです。通称APDと呼ばれています。

 

システムテストチームではAUTOSARの各FC(Functional Cluster)のRSをベースにユースケースに基づいたテストケースを作成し「システムテスト仕様」を作成、さらにそのテストケースをDemonstrator実装を使って正しく動作するかを検証するための「テスト実装」を作成し、提供しています。

システムテストWGの活動内容

システムテストWGでは大きく分けて以下のような流れでテスト仕様の作成、実装を進めています。

 

テスト仕様作成フロー

●ソフトウェア要求(RS)解析
FCのソフトウェア要求(RS)を分析し、システムテストチームで対応すべきかどうかを判断します。すべてのRSを満たすことを目的としていないため、基準を設けて必要性を判断しています。
●ソフトウェア仕様(SWS)トレース分析
対象のRSから紐づくソフトウェア仕様(SWS)を分析します。トレース可能であればValidationSets（AUTOSAR内部で利用している機能検証の単位）と紐づけます。
●テスト仕様の記載
RS解析結果をもとに想定されるユースケースを作成し、それをベースにテストケースを作成します。テストケースは前提条件やコンフィグ項目、テストシナリオ、確認項目等で構成されます。
●テスト実装
テスト仕様をもとに、Demonstrator実装を使ってテストアプリケーションとテスターアプリケーションを実装します。詳細なテストアプリケーションの構成は後述します。
●テスト結果確認
実装したテストを実際のターゲットボードにデプロイし、ローカル環境でテスト結果を確認します。最終的なテスト結果はAUTOSARがオフィシャルに用意しているCI/CD環境にデプロイし、動作確認を行います。

 

 

システムテストでは上記のフローの役割をFCごとに「RS解析、SWSトレース分析、テスト仕様の記載」までを「Spec Writer」、「テスト実装、テスト結果確認」までを「Test Implementor」が担当しています。

テストアプリケーションの構成

では、システムテストで実装しているアプリケーションはどのように構成されているのでしょうか。
下記にCM（Communication Management）のテスト構成を例に説明します。

 

 

テストアプリケーションは「テスト対象アプリケーション」と「テスターアプリケーション」の2つで構成されます。

 

●テスト対象アプリケーション
ECU上で動作する、テスト対象のアプリケーションです。Demonstrator実装のSDKを使って特定のFCのAPIをコールしたり、SerivceベースのアプリケーションであればARXMLのコンフィグレーションをし、サービス同士のコミュニケーションを実現します。

 

アプリケーション内にはアプリケーションから出力されるテスト結果をテスターアプリケーションから得るためにDiag通信を用いたテストの受け口を用意しています。

 

●テスターアプリケーション
Google Test Frameworkを使ってテストシナリオを実装し、テスト対象のアプリケーションが正しく動作していることを確認するアプリケーションです。Demonstrator実装とは関係なく、シンプルなLinux上で動作するアプリケーションとして実装しています。
テスターアプリケーションはDiag通信経由でテストアプリケーションからテスト結果を取得し、テストシナリオが合格するかを確認します。

国際仕様標準化活動の壁

さて、ここまでAUTOSARのWG活動の内容と、システムテストグループでの具体的な活動内容について説明してまいりました。

しかし、実際に参加するとなるといくつか壁を感じるのではないでしょうか？
例えば以下のようなものが考えられます。

 

コミュニケーション(英語)の壁

AUTOSAR標準化策定のコミュニケーションに利用される言語はドキュメント、会話含めすべて英語です。多くの日本人の皆様にとってはハードルの高いものだと感じる方も多いでしょう。

システムテストグループにはヨーロッパ、日本（アジア）、インドなど様々なロケーションの方が参加してくださっています。そして、ほとんどの国の方は第一言語が英語ではありません。AUTOSAR全体を見てもヨーロッパの方が多いとはいえ、英語が第一言語の方はそう多くありません。
従って、比較的外国語に対する許容度は高く、多少間違った英語であっても意思を伝えたいという思いがあればくみ取ってもらえます。筆者も帰国子女でもなければ留学経験もない、純粋な日本人ですが、何とか意思を伝えられてきているつもりです。

最初は100%意思を伝えるのは難しいかもしれませんが、絵を多用したり、事前に文章で書き留めておいたりすることで、ハードルは下がりますので、いろんな手段を試してみることをお勧めします。

 

技術の壁

AUTOSAR Adaptiveに初めて取り組まれる方も多いと思います。そういう方にとって、いきなり標準化に取り組むというのは技術的なハードルが高いと感じるのではないでしょうか。

システムテストでは特定のFCに対して、Demonstrator実装を活用しながらテスト仕様策定、実装、確認までを行います。既存のRSを読み込んだり、コンセプトドキュメントを読み込んで理解したりと、既存のドキュメントを活用していくというのがメインの活動です。

この活動は、コンセプトから仕様書に落とし込む（ブレークダウン）という正攻法な仕様策定活動と比べると初めの技術的なハードルは低くなります。テスト仕様は単純に1つのFCのみを知ってていれば良いというわけではなく、複数のFCと連携するようなテストも想定されるため、広い仕様理解が可能です。

さらにDemonstrator実装を活用することで実装面での理解を進めることも可能です。技術の壁が感じられる場合は、実際の動きを見ながら仕様理解を進められるシステムテストチームへの参画をお勧めします。

 

仕様策定WGに参加しよう

AUTOSAR仕様は日々アップデートされています。リリースごとに新たなコンセプトも追加され、より複雑な仕様になってきていると感じています。実際にその潮流の中に身を置いてみると、仕様の変化の流れをより実感できます。

正攻法の仕様策定活動への参加のハードルを感じるようであれば、我々の取り組んでいるシステムテストワーキンググループからでも良いと思いますのでぜひご参加ください。自分の書いた仕様がリリース内容に反映されていると、嬉しいものです。