AUTOSARの最新リリース「R21-11」（その2）＋標準化活動の近況：AUTOSARを使いこなす（22）（2/3 ページ）

[櫻井剛，MONOist]

コンセプト＃3（継続）：Classic Platform Flexibility（R21-11部分）

　今回、私が多くの時間をかけたのが、こちらのコンセプトです。

　AUTOSAR CPベースのECUソフトウェアの構築を、Software Cluster（SWCL）という小分けにされた単位で行えるようにするためのClassic Platform Flexibilityコンセプトは、R20-11で第1段階の実装が行われました。ただし、その時点では、本連載の第20回でも「診断やWatchdog Stack、通信、不揮発メモリサービスなどが登場していますが、実は、R20-11時点ではそれらはまだ解決していません（R20-11は全体構想策定とRTEの解決のみということもできます）」とご紹介した通りの状態でしたので、R21-11でもその残件に対する取り組みが続けられました。

　R21-11では、診断、通信（Signal-basedおよびSOME/IP）、そして、WdgM（Watchdog Manager：SW-CやBSWの動作の監視を担う部分）を、各SWCLで利用することができるようになりました。

　せっかくですので、私が担当したWdgMに関して少しご紹介いたします。

　SWCL単位での分割コンフィギュレーションのための変更だけではなく、WdgMが全般的に変更、拡張されています。例えば、従来は監視対象（Supervised Entity）の定義を「自由気まま」に設定可能だったのですが、マルチコア／SWCLでの開発作業を想定して、定義の見直し（監視対象がSW-Cをまたがないことの明確化など）が行われました。また、それに伴い、監視動作の変更や機能拡張が行われています。Logical Supervisionでの監視に用いる制御グラフにおいて、単一のチェックポイントが、複数のグラフに属することができるようになり、また、SWCLをまたぐ形での監視メカニズム（Cross-Cluster External Graphに基づくLogical Supervision）が追加されるなど、実際のユースケースを想定した改訂が行われました^※4）。

※4）「今回、私が多くの時間をかけたのが、こちらのコンセプトです」と申し上げましたが、実は、一番時間がかかったのは、ユースケース想定を引き出すための質問の準備です。「使い手（ユーザー）視点で示される項目」と「作り手（実装者やインテグレーター）視点で示される項目」は全く異なることも珍しくありません（関心事が違うのですから当然です）。

　一般論として、作り手が必要とする情報に対する使い手側の関心が薄いのは事実ですし不可避でしょう。また、作り手側でも、使い手の手を煩わせないための配慮（忖度（そんたく）？）もあり「作り手の都合で決めてしまえ。エイ、ヤー！」となることは、特に日本国内では少なくないでしょう。しかし、その結末にたいてい待ち構えているのは「聞いてないよ、何で勝手に決めたの？」という、使い手からの不満です（「説明可能なAI」が求められるようになっている中で、開発者同士でそれはないよね？　という疑問は当然だと思うのですが、実際には説明なしで勝手に決めてしまうケースや、議論を回避したがる／煙たがる人がなんと多いこと……）。

　今回、「作り手（実装者やインテグレーター）視点の情報の不足や欠落の結末が、最終的に使い手側の使い勝手などにどう影響するのか？」の分析には、さほど大きな手間はかからないことが見えていましたし（過去の「変わったプロジェクト」でのインテグレーターとしての経験が役立ちました）、使い手側のユースケースや実現したいことが比較的明確だろうという見当もついていましたので（初期の議論で相手の出方が見えていた）、分析結果をシェアしながら早いうちに「なぜ」の連鎖まである程度たどりつき、従来、議論が足りていなかった部分があることについても認識を共有することができました（逆に、ユースケースや実現したいこと、そして優先順位付けや取捨選択に答えられず「どれも必要」というような答えしか得られない使い手に対しては、私でなくとも具体的な質問を投げようがないでしょうし、その先はたいてい「エイ、ヤー！」止まりです）。新たに明確になった問題の詳細をまだご紹介できないのは残念ですが、2022年内に策定予定のR22-11以降のリリースをお楽しみにお待ちください。

　併せて、SWS WdgMの全体構成の見直し（例えば、どう考えても章立てがおかしい部分や、明らかに重複あるいは矛盾するような記述、表記の不統一、書き過ぎていてメンテナンスに失敗している／今後も失敗するであろう部分のスリム化）なども行われています。文書を引き継いだ時点で気付いていた問題でしたし、見れば見るほどおかしいので、そんなものはパパっと直してしまいたかったのですが……そこが標準化活動のもどかしさ、複数の段階で了承を得てからでなければ直せませんし、了承を得る過程で、こういったものは「優先度が低い」と判断されてしまいやすいので、実際には着手しにくいのです。今回、全体見直しの機会に乗じて、ようやく修正することができました（ただし、途中から「やりすぎるな」とくぎを刺されるまでは、です）。

　なお、CP WdgMおよびAP PHMには、よく使われる制御構造の一部が、現状のままではうまく取り扱えないという問題があり^※5）、既に私から問題提起をしています。今後、何らかの形でそのことについても少しご紹介できればと考えています（オープンにできなかった場合には、AUTOSAR内などある程度クローズな場でのご紹介となりますが、その際にはご容赦ください）。

※5） 実は、前述の「単一のチェックポイントが、複数のグラフに属することができるようになった」のは、「ある制御構造をカバーできない」という私の指摘に対する「こういうトリックでカバーできるじゃないか」という提案もきっかけの一つになっています。しかし、残念ながらそれでは異常の検出漏れ（false negative）のリスクが増えてしまうため、根本的な解決にはなっていないことが、後の「なぜ」の連鎖の議論から明らかになっています。「メカニズムファースト（mechanism first）」や、いわゆる「プログラミング」上だけの成立性の議論ではなく、明確な目的のための議論の必要性を再認識する良い機会でした。

コンセプト＃4（新規）：Service Discovery Harmonization（SDHarmonization）

　ここまで、安全にかかわるコンセプトが3つ続きましたが、次は通信関連です。

　SOME/IP Service Discovery（SOME/IP-SD）Protocolは、サービスを提供するサーバと、利用するクライアントをつなぐためのプロトコルです（サーバ側はoffer messageを送信、クライアント側はfind messageを送信）。SDは、AUTOSAR CP R4.1.1（2013年3月15日発行）で追加されたもので、当然APでも使われます。AP登場当初は、その規格文書の開発はCPとは隔離した形で行われたという経緯もあり、各文書の内容に重複定義や矛盾が生じていました。今回、FO PRS SOME/IP Service Discovery Protocolと、CP SWS Service Discovery Protocolの整合、整理が行われました。