AUTOSARの最新リリース「R20-11」に盛り込まれた新コンセプト（前編）：AUTOSARを使いこなす（17）（1/3 ページ）

はじめに

　前回は、SaFAD（ISO/TR 4804）についてAUTOSARを絡めてご紹介いたしました。

　ISOのWebサイトを見たところ、本稿の執筆開始時点（2020年11月22日）では、ISO/TR 4804はステージコードが60.00（発行直前の準備段階）まで進んでおり、同年12月発行予定と書かれていました。そして、本稿の最終校正時点（12月7日）には購入可能になっていました。発行は12月3日付です（実は、12月頭のある時点では1月発行予定に変わっていたので「再編集作業や発行年号変更など大変だなぁ」と思っていましたが、結局年内発行にこぎつけたようです）。中身を見るのが楽しみです。

　さて、2020年12月2日（欧州時間）にAUTOSARの最新バージョンとなる「AUTOSAR R20-11」がリリースされました。（公式のリリースは同年11月30日付ですが、今回も公式Webサイトでの公開までは数日かかりました）。

　今回も多くのコンセプト（Concept）や変更（Change Request、CR）、バグ修正対応が盛り込まれています。また、同年12月4日には、AUTOSAR R20-11のリリースイベントが開催されました（このようなイベントは初の試みとのこと。一般向け、参加費無料でのオンライン開催でした）。資料も後日ダウンロードできるようになる模様です。

⇒連載「AUTOSARを使いこなす」バックナンバー

R20-11での変更点の概要

　R20-11（Internal Release Number：4.6.0）では、16のコンセプトが導入されました（表1）。なお、コンセプトによっては、各プラットフォームのTR Release Documentationに独立したセクションが用意されておらず、一見すると関係がないように見えるものもありますが、精査するとこの表1のようになります。また、ほとんどがドラフト扱いとなっています。

　また、この他にも大きな変更が行われています。例えば安全関連であれば、E2E（End-to-End Protection）での新規プロファイル追加（Profile 4m、7m、8、44：m付きはmethod用）が行われています（私個人は、これがなぜコンセプト扱いではないのかと疑問）。一見目立ちませんが、AUTOSAR AP（Adaptive Platform）のPHM（Platform Health Management）の位置付けが「Manager」から「Monitor」に変更され、復旧のための動作をPHM主導で行うのではなく、SM（State Management）主導で行うようにも変更されています。ただ、この変更は影響が大きく、各文書には、新旧の考え方がまだ入り交じった部分が混在していますので、読む側の負担はかなり大きいと思います。

　私の担当文書のうち安全関連のWdgM（Watchdog Manager）では、タイミング規定のあいまいさの改善など比較的小さなものばかりでしたが、LinIf（LIN Interface）のLinTp（Transport Layer）部分^※1）では、LINを介した診断通信動作でのLIN通信Schedule Table切り替えに関する大きな不具合（R4.0当初からのもの）の修正が行われています。

余談：COVID-19の中でのR20-11の開発

　今回も、私は2つのWorking Group、WG-SAF（Safety）およびWG-IVC（In-Vehicle Communication）にアクティブメンバーとして参加し、さらにCP（Classic Platform）のSWS Watchdog ManagerやSWS LIN Interfaceなど4つの文書の責任者（document owner）として活動を行いました（担当文書はCPだけですが、WG-SAFではAPでの議論にも入っています）。なお、弊社（イーソルの日本拠点とフランス拠点）からは、他にWG-A（Architecture Team）やWG-AP-ST（APのSystem Test）にもアクティブメンバーとして複数人が参加しています。

　前回リリースのR19-11（2019年11月）の直後から新型コロナウイルス感染症（COIVD-19）の報道が目立つようになりましたが、特に今年（2020年）に入ってからの影響は小さくはありませんでした。毎月の対面形式の会議は、基本的にリモート開催に転換されています。正直に申しますと、現地に飛ばずに参加できることで、当初は「負担が小さくなる」と考えていました。しかし、日本から参加する私の場合にはむしろ逆でした。

　会議は欧州時間（中央欧州時間のCETまたはその夏時間のCEST）で開催されますので、時差は8時間または7時間です。日本からリモート参加するとなると、開始は夕方、終了は深夜です。しかも、地球の裏側ですから、通信の遅延時間がそれなりに大きく、発言タイミングを得るのが難しくなります（タイミングを逃すと、あっという間に他の関連トピックに議論の中心が移ってしまうこともしばしば、引き戻すのに苦労することになるものですから……）。

　一時は本当に悩みましたが、今は、アジェンダの事前調整はもちろん、他の方の発言が区切りを迎える前に、チャットウィンドウや挙手機能で「言いたいことがある！」旨の意思表明をするなどして、どうにかしのいでいます。それでも、日中は通常業務が結局入ってしまい結果として勤務時間が長くなり、運動不足もひどくなり、日本にいながら時差ボケ同様の体内時計の狂いを味わう（翌朝には日本時間に戻さねばならない）、さらには同居する家族にも遠慮が必要……ということで、今では「重い荷物をぶら下げ、時間をかけて移動し、短い乗り継ぎに神経をすり減らしながらも、現地に飛んだ方が仕事しやすい！」と半ば本気で思っています。

　何よりも、「当たり前」の共有（連載第5回を参照）の機会がほぼ失われたことが大きな損失です。現地に飛んでいたころは、昼食や夕食の際に、独占禁止法についてはもちろん気を使いつつも、本会議の中とは異なる緩い時間制約の中で「あの発言は、いったいどういうことなんだ？」という問いかけにお答えすることが多々ありました。

　「安全」の分野では、時には宗教観の違いを把握することが相互理解のカギとなることもあります（例：「人のなせるわざ、神のなせるわざ」の区分けを持つ文化圏での社会的受容性の閾値の違い）。日本という、欧米の宗教観とは異なる環境の出身であることや、あえて宗教とは距離を置く姿勢をとっていることから、会議参加者からは新たな視点を得る機会にもなる、と言われたことが少なくありません（ということは、「会議中だけだと何言ってるんだか分からないこともある」ということの裏返しでもあるので、苦笑いするしかないのですが……）。もちろん、誰もが私のように「違い」の背景について「考え込む」タイプである必要はないのですが、そういうタイプでないとできないコミュニケーションもあると思います。そこをブロックされているのは、歯がゆく感じます。

　他社からの参加者も、時短勤務などで苦労しているとのことですが、それでも皆、何とか活動の質を落とさないようにそれぞれ努力しながら進めてはいます。

　しかし、WG-SAFのようにAP／CPを区別なくWG活動を行っているところでは、APに多くのリソースと時間がとられ、CPでの活動は圧迫されています（実質自分一人で片付けなければならないことも……）。WG-IVCではAPとCPの活動を分けているのですが、そうであっても、従来の参加者の所属企業がAUTOSAR標準化活動から脱退、活動縮小してしまうことで、文書責任者にも相当数の欠員が出たものですから、兼務や代行も増え、苦労する場面もあります（運悪く、多数の文書の更新に関係する変更要求をWGを代表して作成していたものですから、リリース直前は駆け込みレビューの嵐でした）。