AUTOSARの最新リリース「R21-11」（その3）＋合意形成のための5ステップ：AUTOSARを使いこなす（23）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第23回は、「AUTOSAR R21-11」で導入された10の新規コンセプトのうち残りの5つの内容を解説するとともに、AUTOSARの標準化における合意形成のための“黄金の”5ステップを紹介する。

[櫻井剛，MONOist]

安全関連の変更：End-to-End Protection（E2E）の新Profile

　安全関連の変更として、第21回でWdgM（Watchdog Manager）における「パーティションのリセット動作」の削除（CP-2）をご紹介しましたが、安全関連では他にも変更が行われています。

　例えば、今回ご紹介したコンセプト＃6（新規）：E2E for Fieldsと併せて、幾つかのE2E Profileが追加されています。E2Eプロトコルヘッダは、シグナルベース通信用の構成要素（Length ※可変長の場合のみ、Counter、Data IDおよびCRC）だけではMethodの実現に支障があるため、Method用のProfileとして、ヘッダに3つの構成要素（Message Type、Message Result、Source ID）を加えたものが用意されています（図2、表2）。R20-11で追加されたProfile 4m／7m（P04m／P07m）および今回のR21-11で追加されたProfile 8m／44m（P08m／P44m）がこれに対応します^※3）。

図2　E2E Headerの構成要素［クリックで拡大］

表2　E2E Profile一覧［クリックで拡大］

※3）P44mで使用可能なデータ長の上限は、PRS E2E上では4KBとされていますが正しくありません（正解はP04／P04m／P44を比較してみれば明らかですので、あえてここでは申し上げません）。

まとめと私見：「方策の具体化の支援」と「安全保障」の観点からみた「プラットフォーム標準化」

　第21回、第22回、そして今回までの3回に分けて、AUTOSAR R21-11での主な変更点をご紹介してまいりました。

　ここまでご紹介してきた内容以外にも、文書名の全般的な見直しと、AP／CP共有の記述のFOへの移動（そのため、公開された規格文書だけから差分をチェックするのは、少々大変かもしれません）、トレーサビリティーに関する改善や要求／制約ID表記統一（ただしごく限定的）、AP CM（Communication Management）でのFreshness Value Management（FVM） API定義の追加、AP SM（State Management）でのUCM（Update and Configuration Management）関連API変更など、多くの変更が行われています。おなじみのCPのCAN関連でも、ハードウェアによるタイムスタンプ機能への対応などがひっそりと行われています（コンセプト以外の変更チケット数は1000を軽く超え、また、約3分の1がCP関連です）。

　SaFAD（Safety First for Automated Driving）文書をご紹介した第16回でも少し申し上げましたが、各種安全規格文書が発行されても、想定アーキテクチャや標準アーキテクチャ、あるいはその背景にある想定ユースケースに関する共通認識がなければ、方策の具体化を都度行わねばならず、運用が難しくなります。

　AUTOSARのようなプラットフォームやアーキテクチャに関する標準化の場は、実は、安全規格の運用や一層の具体的な方策に踏み込むための重要な要素でもあると私は考えます。というのも、プラットフォーム側で手段を検討し標準化するというだけではなく、安全規格の側に対して、アーキテクチャやユースケースなどの想定の情報を与えることで、一層広い範囲が考慮されるようになり、また、具体的な手段にさらに踏み込んで検討することが可能になるからです。ある意味、プラットフォームと安全規格は相補的なもの、まさにクルマの両輪だともいえると思います。

　また、第21回のR21-11のご紹介のその1で、幾つかの機能の削除をきっかけに書かせていただきました、「自分たちが使い続けたいものを、使い続けていくための安全保障の側面」も忘れてはならないと思います。

　さらに、ここで意図的に急にミクロな話に転じてしまいますが、多くの場合、標準化会合の年間スケジュールや定例会議開催の曜日と時間帯は、年末のリリースが落ち着いたころに決められます。私の所属するWorking Groupでは既にほぼ決まってしまいましたが、日本から出席をしようとすれば、どうしても欧州時間の午前となりますし、相対的に北米からの参加比率が増えれば日本から参加しやすい時間に開催してもらうことは、より一層難しくなるでしょう。もちろん、ただ参加して聞いているだけでは存在感を認めてもらうのは難しいのですが、それでも「参加していないときに決まってしまう」よりはましです。参加すらできなくなるようで、本当に良いのでしょうか？

　これらを考慮して、AUTOSAR標準化活動における合意形成のための段階的な進め方を、私なりに5ステップで書き出してみたのが、以下の図3に挙げる「AURUMプロトコル」です^※5）。

図3　AUTOSAR標準化活動における合意形成のための5ステップ−“AURUM”プロトコル

　実際にはどこからスタートしても構いません。

　でも、もしも数字の大きなステップでうまくいかないときには、1つ前に戻って打てる手を探してみること、これが重要だと考えています（数字の小さなステップが、大きなステップの土台として支えている、という構図）。

　そして、ユースケースや要件、そして実現手段の議論を重ねることで、「存在の認知」は高められます。逆に、全く参加せず認知されなければ議論にも入れませんし、しばらく休めば忘れ去られます。そうなってしまえば、後から変更や削除を知らされるだけとなり、これまで述べてきたように、「自分たちが使い続けるプラットフォームの維持」に支障が出るかもしれません。

　まずは、皆さんも、「自分たちが使い続けるプラットフォームを、使い続けられるようにする」ための第一歩として「会合への参加」から始めてみませんか？　積極的なご参加をお待ちしております。

※4）なお、SaFAD文書は、その後2020年12月にISO/TR 4804:2020として発行されました。内容は大筋同じですが、幾つか「範囲を絞りすぎていた表現」の見直しなどが行われています。

※5）これらのキーワードの頭文字を拾うと「AURUM」になります。これはラテン語で「黄金 gold」になります。前回（第22回）を書き上げた後、わが家の猫の1匹が頻繁にけいれん発作を起こすようになり、今回の原稿の締め切り（そして今から）2日前に、治療のかいなくとうとう旅立ってしまいました。AURUMプロトコルを思い付いたのは締め切り日（まさに先ほど）なのですが、たまたま「そういえば、あいつの目の色は金色だった」とぼんやり思い返していたときだったので、不思議な縁を感じます（置き土産、感謝しなければなりません）。

※6）AUTOSARの中で、「プラットフォームベンダー各社はどう考えるか？」という問いかけがなされることがあります。最近、弊社にもその声がようやくかかるようになりました（国内では弊社だけです）。認知されるようになるというのは、大変なことだとつくづく思います。

次回は……

　次回は、AUTOSAR Open Conferenceの内容をご紹介したいと考えています。開催時期が未定ですので、掲載時期についてははっきり申し上げられませんが、2022年中頃を見込んでいます。まだお伝えできない内容がいろいろありますが、そのころには、コロナ禍も含め状況が良い方向に変わっていることを願っておりますし、また、皆さまもぜひご期待ください。ご健康に、そしてご安全にお過ごしください。ではまた。