AUTOSARの最新リリース「R21-11」（その1）：新規コンセプトの他に変更や廃止も：AUTOSARを使いこなす（21）（3/4 ページ）

[櫻井剛，MONOist]

R21-11：コンセプト以外の気になる変更や廃止

　コンセプトのご紹介の前に、気になる変更や廃止が幾つかありますので、まずはそちらのご紹介と、そこから見えてくるものについて述べさせてください（コンセプトに関する説明は、次回以降行っていきます）。

　まず、国内の多くの方にはより身近なCP関連から始めましょう（注意：以下は網羅的なものではありません、またIDは便宜上筆者がつけたものです）。

• CP-1）想定するC言語規格（ISO/IEC 9899）のバージョン切り替え（R4.3.0からC90と明記されていましたが、R21-11でC99に切り替え）および64ビット変数に対するアトミックアクセスができないマイコン（一般には16ビット以下のマイコン）の事実上の切り捨て^※7）
• CP-2）SW-CやBSWが正しく動作していることの監視役を担うWdgM（Watchdog Manager）における、異常が検知された際の復旧動作としての「パーティションのリセット動作」の廃止^{※8、※9）}
• CP-3）Com（AUTOSAR Communication）における、I-PDU CounterおよびI-PDU Replication機能の廃止
• CP-4）Dem（Diagnostic Event Manager）における、Mirror Memoryに関する記述の削除（ISO 14229-1の2013年版から2020年版への改訂に伴い削除）

※7）16ビットマイコンは、小規模ECUではまだ使われているのではないかと、少々懸念しています。なお、32ビット変数に対するアトミックアクセスができないマイコン（8ビット）は、当初よりAUTOSARの想定外でした（知る限りでは明文化されてはいませんでしたが）。また、enum型が8ビットに制限されるようなコンパイラも市場に存在しましたが、そういったものも、実際のAUTOSAR CPベースのECUをインテグレーションする際には「事実上使えない」とされてきました。

※8）WdgMは、CPにおいて、SW-CやBSWが正しく動作していることの監視役を担う、安全関連BSWです（私が担当する文書の1つです）。「パーティションのリセット動作」はR4.0.1から規定されていたのですが、これはなかなかの困りものでした。安全関連系SW-Cと非安全系SW-Cが混在するような場合には、パーティショニングを行いますから、一見すればリセット動作が必要になるように見えるかもしれません。しかし、AUTOSAR CPのソフトウェアアーキテクチャ全体を眺めてみると、大問題があります。

　というのも、ある程度の時間を必要とするデータフラッシュへの書き込み（例：異常イベントをFault Memoryとして記録する場合）の最中に、アクセスが完了しているかどうかを確認することもないまま、さらに、周辺デバイスの電源制御なども行わないままで、WdgM単体の判断でいきなりパーティションリセットするのですから……。しかも、停止させるのではなく無条件で動作再開（リスタート）させてしまうという乱暴な規定です。SW-CやBSWが各Partitionに分散配置されていた場合、BSWの初期化関数（＜Mip＞_Init）や、SW-Cの初期化用Runnable関数を起動するトリガー条件が用意されているわけではありませんし、マルチコア対応BSWの各パーティション上の一部分を、全体の整合性を維持しながらリセットするような動作の規定はどこにもありませんから、ECU全体動作の一貫性は損なわれます。

　BSW/RTE群は、単一のBSWベンダーが提供するわけではなく、マイコンベンダー製のMCAL BSWを併用することが一般に行われてきましたから、「規格未定義部分の問題解決」を各BSWベンダーが単独で行うのでは、意味がないのです。異なるベンダー製の製品間での動作の一貫性（＝安全を担保する上での要因の一つ）の確保のためには、やはり「共通認識／合意を形にしたものとしての、標準規格での定義」が必要です。この問題提起を行ったのはだいぶ前なのですが、R21-11に向けての議論の過程で、「実は、誰もまともに使っていないどころか、どこも実装していない」ということが判明しましたので、この「機能としてはoverspecifyな上、その記述が著しくunderspecifyな部分」を、いったん規格上から削除するという結論に至りました（標準規格の位置付けと機能安全とを正しく理解していたなら、アタリマエといえば当たり前の結論ですが……）。

※9）WdgMに関しては、この他にも、コンセプト関連で機能拡張が行われています。安全関連のものですから、できるだけ変更は短期間に詰め込んでしまい、後は安定して運用できるようにしたいと思っていますので、次回以降、変更内容と近々解決したい課題（可能なら皆さんのご意見をいただきたいもの）についてご紹介していきたいと思います。

　次に、国内でも多くの方に注目されているAP固有のものです（注意再掲：以下は網羅的なものではありません）。

• AP-1）RESTful communication対応の廃止
• AP-2）C++コーディングガイドラインの切り替え。今後はGitHub上で展開される「C++ Core Guidelines」を参照。内容は随時アップデートされる予定
• AP-3）PHM（Platform Health Management）で、これまで未定義だったハードウェアウォッチドッグの制御に関するAPI定義やその利用者の明確化（＝PHMに限定）

※10）余談ですが、2021年12月より、MISRA C++:202x public reviewの告知が行われています。この文書は、MISRA C++の新版（2008年版の次版）であり、AUTOSARからMISRAに両団体の合意の下で移管された、AUTOSAR C++ Guidelineの内容をカバーするものとなります。

⇒MISRA C++:202xのpublic reviewの告知Webサイト

　ここでご紹介したのはごく一部です。実際、先にご紹介したリリースイベントでは、1819件のChange Request（変更要求）が議論されたことが、公表されています。

R21-11：変更や廃止から見えてくる懸念

　さて、前項では、機能などの「廃止」や「互換性やユースケースに影響のある変更」を意図的に多くご紹介してきました（例：16ビットマイコン対応の切り捨てや、REST対応廃止、APでのハードウェアウォッチドッグ制御箇所の限定、etc.）。というのも、そこからは、標準化活動への向き合い方に関する懸念が見えてくるからです。

　「使っている／使うから存続を」「互換性のない変更は困る」という声があれば、たとえその声が少数であっても、標準規格からの削除や、互換性がなくなるような変更となることはほとんどありません。ですから「これら従来機能の実際の利用や今後の利用ニーズの存在が確認されなかった」と読み取ることができます。特に、使用されることのない機能は、規格文書群の保守性を下げないためにも、削除されるのが自然です。特に、これだけ規模が大きく、相互に入り組んだところのある規格文書群であれば、なおのことです。

　ただ、このことから見えてくるのは「標準化活動に参加していなければ、改訂版リリースの際に、突然、機能削除や非互換の変更を知らされる」という懸念です。Working Groupでの規格文書開発活動に参加し、状況をよく見て、必要な時には声を上げるということを継続していないと、改訂版リリースの際に突然「自分たちが使っている機能が、使われていない機能扱いされて、削除されることになった！」と慌てることになるのです。繰り返し申し上げていますが、標準化活動に参加し続けることは、そのような事態を防ぐという、リスクマネジメントの面からはとても重要なことです。

　標準規格の積極的な採用は、これまでしばしば、特定ツール製品などを使い続けることによるベンダーロックインのリスクへの対処の1つとして挙げられてきました。

　しかし、オープンな規格やそれらに基づく製品への依存度を高めるようにしたとしても、その規格に振り回されるのでは、結局同じことです（規格策定に参加する企業と、規格に基づく製品のベンダーによるロックインであり、意思決定の場が、個別企業の中ではなく、各社が集まる場に変わるだけ、結局利用者は「中の人」になれず、従うだけ）。標準規格と、声を上げない人の間の関係は、それこそ、目をそむけたくなるような「master/slave」の構図になってしまいかねないのです。皆さんは、本当に、制定の過程に関わることのできない標準規格に、「支配」されたいのでしょうか？　標準規格は決して聖なる銀の弾丸ではありませんし（むしろ、妥協の固まり）、標準化活動に関わるメンバーも聖人君子ばかりでは決してないのですが……。

　なお、規格文書は、PDFのファイル数だけでも約300あります。これを約160人で手分けして執筆していますが、そのうち、お名前から日本の方と分かるのは、弊社（イーソル）の権藤と私を含めて6人だけです。もちろん、WG参加メンバーには、執筆しないメンバーも含まれますし（その是非はいろいろな意見があります）、日本企業の欧州拠点からは日本以外の方のご参加がそれなりにあります。しかし、今回ご紹介したような情報が「積極的に把握して、報告してほしい対象だ」ということが、うまく伝わっているのでしょうか？

　伝わっていなければ、そもそも不意打ちを避けることは難しいでしょう。「なぜ報告しなかった？」と誰かに問いたくなったら、「どんな情報を報告するよう、具体的に指示したか？」（あるいは、必要な情報の背景にある、達成失敗しては困る要件や、さらにその上の目的を伝えたか？）をまずは自問する。これもプロジェクトマネジメントでのコミュニケーション計画の観点からは当然のことです。

　そもそも「企業活動に関係のありそうな情報を報告せよ」というような指示しかされていないことは少なくありません。それでは、報告しなかった人を責めても意味はありません。報告がなかった理由をきちんと分析し（目的や要件の整理を含む）、必要な対処を組織として実装していくしかないのです。そして、その過程では、標準化活動への参加者のミッションと、その上位にあるはずの標準化活動に参加する理由の明確化を、ともに避けて通ることはできないはずです。