　R21-11（Internal Release Number：R4.7.0）では、10のコンセプトの導入が行われています（表1）。これらのうち4つは2020年11月発表のR20-11で第1弾が導入されたものですが、続編となる今回でも引き続き多くの機能拡張が行われています（なお、前回記事ではNo.2と3の2つとお伝えしましたが、No.7と8も続編でした。訂正いたします）。


NO.	Concepts	FO	CP	AP	補足	State
1	Mode Dependent Configuration (MDC)	x	-	x	機能拡張	draft
2	System Health Monitor (SHM) ※一部文書ではManagement (表記不統一)	x	-	-	機能拡張 (続編)	draft
3	Classic Platform Flexibility (CP Flexibility)	x	x	-	機能拡張 (続編)	draft
4	Service Discovery Harmonization	x	x	-	記述改善	draft
5	Memory Stack Rework	-	x	-	機能拡張	draft
6	E2E for Fields	x	x	x	機能拡張	draft
7	Rework of PNC related ComM and NM	x	x	-	作業効率改善（続編）	draft
8	10BASE-T1S	-	x	-	機能拡張（続編）	draft
9	DDS Security in Communication Management DDS Network Binding	-	-	x	機能拡張	draft
10	DDS Enhanced Discovery	-	-	x	機能拡張	draft
表1　R21-11の新規コンセプト一覧（xは影響を受けるプラットフォーム、FO：Foundation、CP：Classic Platform、AP：Adaptive Platform）

コンセプト＃1（新規）：Mode Dependent Configuration（MDC）

　ソフトウェアが正しく動作していることの監視機能は、AUTOSARでは「Health Monitoring」と総称されています（表1）。この機能はClassic Platform（CP）ではWatchdog Manager（WdgM）というBSWモジュールが担当し、また、Adaptive Platform（AP）ではPlatform Health Management（PHM）というPlatform Foundation Functional Cluster（FC）が担当しています。

　CP WdgMおよびAP PHMのいずれも、周期的な動作の監視（Alive Supervision）、非周期的な動作の監視（Deadline Supervision、処理実行中の2点間の経過時間によるもの）、そして制御フローが意図通りであることの監視（Logical Supervision）の3種類の監視メカニズムを提供しています^※1）。

※1）なお、監視動作の詳細は、CPとAPの性質の違いなどの理由により、WdgMとPHMで異なる部分もあります（例：Internal Graph／External Graphの区別の有無や、標準化範囲の違い）。

　ただ、監視対象のソフトウェア処理（Supervised Entity）の振る舞いは常に同じとは限りません。車両やECUの状態の変化で、ソフト処理を停止させることもありますし、動作切り替えにより周期処理などが変わることもありますので、「動作モードにより監視動作を切り替えられること」が必要になります。

　前バージョンであるR20-11のAP PHMで監視動作の切り替えに対応するためには、実装レベルで工夫するしかありませんでした。しかし、今回のリリースR21-11では、監視動作をFunction Group Stateに基づき切り替えることができるようになりました^※2）。

※2）Supervision Modeに関するコンフィギュレーション仕様が追加されていますが、Machine Stateによる切り替えはできません。なおSWS PHM sec. 7.4では「Currently」という気になる表現が残されています。

　なお、CP WdgMでは、もともと動作モードに応じた切り替えができるようになっています（表2）。

表2　AUTOSAR Health Monitoringにおける動作モードと振る舞いの関係［クリックで拡大］

コンセプト＃2（継続）：System Health Monitoring（SHM, R21-11部分）

　R20-11で導入された、APでのSystem Health Monitoringの続編です（TR Release Overview上での表記が「Management」となっていますが、これは表記ブレです）。ECUの健全性に関する状態を授受するためのAPI定義（HealthIndicatorInterface、HealthInfoInterface）が追加されました（ASWS Health Monitoring, chap. 9）。

　なお、授受される情報として「何が必須か」は長い議論を経ても結局結論が出ず、「こんな情報が扱われるかもしれないね」という形の定義になっていますので、「どのように使いたい」というニーズを、自動車メーカーやシステムサプライヤー側で明確に提示しなければなりません。もしもそれが示されないと、プラットフォームベンダーやインテグレーターでは「取りあえず作ってみました」というレベルでしか作ることはできませんし、達成すべき安全要件や対処すべき故障などもあいまいになってしまいます。十分にご注意ください。

　また、対象プラットフォームがFOのみとなっていますが、実質的にはAP PHMが対象です。なお、CPに関しては、SHMのニーズは特にありませんでしたし、必須の内容が決まっていないのに専用のAUTOSAR Application Interfaceを定義するのもおかしな話ですので、API定義は行われていません^※3）。

※3）このつかみどころのなさに関しては、「そもそも、この機能や情報が必要な理由は？　その理由のさらに上の理由は何？」という疑問など、いろいろ思うところはあります。「なぜ」の問いのある程度の連鎖に答えられないメカニズムは、得てして「無目的メカニズム」となりやすく、ひいては「結局は使われなかった」ということになってしまいがちなものですから……（これ以上は控えます）

コンセプト＃3：Classic Platform Flexibility

　　　　　　 1|2|3 次のページへ