　後述するR21-11のリリースイベントの中では、ポルトガル・リスボンでの現地開催に向けて準備中とのアナウンスがありました。ですが、この状況ですから、2021年に続きオンライン参加という選択肢も用意されるはずです。私も、オンライン参加可能な場合のみ参加の予定です（現役かつ高齢者に分類される医療従事者が身内にいることもあり、慎重にならざるを得ませんので）。

　本稿執筆時点では、参加受付がまだ開始されていませんが、近いうちに始まるものと思いますので、ぜひ参加をご検討ください。

（2）R21-11リリースイベント（2021年12月）

　次に、既に終了したイベントのご紹介となってしまいますが^※1）、R21-11発行の直後、2021年12月7日にはリリースイベントが開催されました。

⇒R21-11リリースイベントの告知Webサイト

　今回も、無償かつリモート形式で、また、AUTOSAR会員以外の方も参加可能な形でした。前回同様、AUTOSAR公式Webサイトで動画を後日一般公開する予定とのことです（2021年12月12日時点では未掲載）。

※1）近年は、規格文書の発行から1週間程度でリリースイベントが行われます。リリース時期（当面は毎年11月）になりましたら、ぜひご自身でAUTOSAR公式Webサイトをご確認ください。本連載シリーズでもご案内の機会があればそうするのですが、リリースイベントの告知開始後に掲載の機会があるとは限りませんし、守秘義務の関係で、新リリースの内容をご紹介できるのは、AUTOSAR公式Webサイト上で規格文書群を一般向けに公開してからとなります（今回の一般公開は、ドイツ時間で2021年12月6日でした）。ですから、皆さまご自身で、あらかじめカレンダーやTO DOリストにご登録いただくなどするとよいと思います。次回のリリース（R22-11）は、2022年11月の予定であることが既に公表されています。

　このイベントでは、今回新たに導入されたコンセプトだけではなく、今後導入が進められていくコンセプトについても、簡単に紹介されました。

　Classic Platform（CP）／Adaptive Platform（AP）共通のものとして、MACsec対応やFirewallなどが挙げられています。CP固有では、CAN XL対応、Fuel Cell System、V2Xの拡張、Secured Time Synchronizationなどが、AP固有では、Suspend to RAMや、昨今話題のVirtualizationやVehicle API^※2）などがあります。特にVehicle APIは、AUTOSARの次の柱となる可能性がある旨の発言もありましたし、リリースイベントの翌日から開催された「第9回自動車機能安全カンファレンス 2021」でも何度も触れられていました。

※2）AUTOSARは「AUTomotive Open System ARchitecture」から取られた団体名そして規格名です。国内では「ソフトウェアの規格」（特に基本ソフトウェアモジュールの規格）と認識されていることが多いようですが、実際には、ECUシステム間のI/Fや、そこで使用される通信プロトコルなども定めていますし、ドイツのHerstellerinitiativ Software（HIS）から引き継いだSecure Hardware Extension（SHE）関連文書も扱っています。そこにさらに「クルマと、その先につながるものの間」のI/F定義が加わることとなるなら、少なくとも、「AUTOSARは（狭義の／これまでの）“ソフト”のことしか扱わない」という認識は改める必要があるでしょう。もともと、組み込みソフトの先には、必ずリアルな世界（物理、社会、環境、etc.）がありつながっているわけですし、開発サイドも「社会」を構成しているわけですから、厳密には「互いに完全に独立したもの」と扱うことができるわけではありません。

　最近、「software first（ソフトウェアファースト）」「software defined architecture（SDA：ソフトウェア定義アーキテクチャ）」という言葉が自動車業界でも騒がれていますが、その一方で「ソースコードだけがソフトだ」（制御モデルや、概念レベルのアルゴリズム／シーケンス、さらには上位の設計指針・プロセスなどは、ソフトではない）という、昔ながらの思い込みも根強く残っているようにも思います。「ソフトウェア」という言葉が指す意味において、場面や個人差によるバラツキが広がっていることが見てとれます（さすがに、「ソフトはいつでも自由に変えられる」という誤解は、だいぶ減ったようにも思いますが、それでもいまだに「ハードが格上で、ソフトは格下／従属的／付属品」という意識が透けて見えてしまう場面には出くわします）。

　「ソフトウェア」という言葉の解釈の幅が広いことはもはや明らかだと思います。議論や方針の提示などの場面においては、対象／スコープをきちんと示さないと、その先にある活動や結果に大きなズレが生じてしまいますので意識して明示することが必要でしょう。また、今はまさに、ソフトやそれにまつわるさまざまなことが「変化」している時（安定期ではなく過渡期）ですから、いわゆる昔ながらの「プログラム」だけではなく周りも見るようにすることが不可欠だと思います。

　「範囲を絞って」は、安定期にはよく機能するかもしれませんが、過渡期にはよほど周囲とのバランスを取っていないと、短命かつ各所でのつじつま合わせに手間のかかる「局所最適化解」になってしまいます。もちろん権限の壁はあるでしょうが、権限の範囲を越える課題があるなら、上に報告して解決責任を移転するのが正しいエスカレーションであり、自分のところで未解決のまま抱え込んだり、ブロックしてしまったりするのは、プロジェクトマネジメントの観点からも適切ではありません。

　個社で独自に開発や問題解決を進めてきたのに、後日改定された規格の内容と一致しなくなってしまうことや、あるいは、似て非なる規格が異なる団体で制定されてしまうことは^※3）、マクロ視点での投資効率の観点などからは好ましくありません。こういった情報を把握し共有することも重要ですので、実は、私が副主査を務めるJASPAR AUTOSAR標準化WGでは情報の収集や取りまとめも行っています。しかし、AUTOSARパートナー種別の違いによる情報アクセス権限が異なることにより、情報伝達にも限界があります（WG外には情報提供が難しい）。

※3）余談ですが、JASPARでは、これを長年にわたり「ダブルスタンダード」と表現しています。しかし、その語に対する辞書上の一般的な説明よりも少し広い意味で使われていることから、違和感を抱き続けています（途中からの参加の身ではありますが、担当WGの副主査としてはいずれ直したいところ）。どちらかといえば「非互換の同種規格の並立」（意図的な対立の有無や、アンフェアさの有無は問わないもの）が実質的なスコープになっていると考えます。

⇒JASPARの各WGの活動内容

　実際、イベントのQ&Aセッション内では、コンセプトや計画の有無に関する参加者からの質問に対して、AUTOSAR側が回答を避けた場面もありました。もともとそれらは守秘義務の対象なので当然です。ですから、こういった貴重な情報収集の場を、AUTOSARのパートナーになっていない方々（特にエンジニアリングサービスや周辺ソリューションを提供しておいでの方々^※4）や、アソシエイトパートナーにとどまっておいでの方々（特にJASPARなどでの標準化活動に関わっておいでの方々）は、活用していくべきでしょう。

※4）なお、AUTOSARの規格文書は一般公開されていますが、だからといって、AUTOSARの技術・各種知財が自動的に無償で誰にでも利用許諾されているわけではありません（以下のAUTOSARのFAQをご覧ください）。

⇒AUTOSARのFAQ

　パートナーになるなどしてライセンスを受けなければならないということをご存じではない方々を時折お見掛けしますが、ビジネス展開の際には必要となるライセンスがあることについて、あらためてご注意いただきたいと思います。なお、「公開されているのだから、誰でも手続きや費用なしで利用できるべきだ、櫻井の解釈はおかしい」と食ってかかられたことも一度ならずありますが、その方々の主張が正しいのであれば、存続期間内の特許でさえ、特許広報として公表されているのですから、自動的にライセンスされるということになってしまいます。主張の根拠を疑うべきです（が、やんわり示唆して差し上げても、「自分の主張が正しい」という前提を変えず、こちらの主張の根拠（法令など）の提示まで求めてくる方も少なくないことに、少々いら立ちを覚えます）。

AUTOSAR R21-11の概要

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