マルチコアマイコンへの対応で進化するAUTOSAR Classic Platform（後編）：AUTOSARを使いこなす（20）（4/5 ページ）

R20-11でのCP Flexibilityコンセプトの技術面の概要

　R20-11 Release Overview文書での本コンセプトに関する説明「to split today's monolithic AUTOSAR Classic Platform binary into several software clusters that can be independently developed, integrated, tested, and programmed.」を見ると、「バイナリがモノリシックだから」と解釈してしまうと思います。しかし、実際には、AUTOSARで既に採用しているモジュラー構造の「その先の一手」の一つとして、「バイナリに限らずさまざまな側面での各種開発活動の『塊』を砕き、小分けにしたものを独立に扱いやすくすること」、これが、本コンセプトの狙いです。

　大規模ECU上のSW-Cをグループごとに分割し（これ自体は仕分けするだけですから比較的簡単ですね）、RTEやBSWの各モジュールの中で、SW-Cのグループのそれぞれに対して依存性を持つ部分と持たない部分を切り分けての運用を円滑に行うことができるようにする。これがCP Flexibilityの基本アプローチです。もちろん、統合前のECUに相当する部分的なバイナリの差し替え更新もその結果可能になるでしょうが、それだけでは決してありません。

　図3、図4に示すように、｛SW-Cのグループ、そのグループに依存性を持つRTE断片、そのグループに依存性を持つBSW断片（High Proxy）｝をセットにしたものを、「Applicative Software Cluster（Applicative SWCL）」と呼びます。

　また、｛共通部にすると決めたSW-Cのグループ、そのグループが使用するRTE断片、各Applicative Software ClusterのSW-Cのグループに対する依存性を持たないBSW断片（Low Proxy）｝をセットにしたものを、「Host Software Cluster（Host SWCL）」と呼びます。

　1つのECUソフトウェアの中には、単一のHost SWCLと複数のApplicative SWCLを持つことが可能です。

図3　ECUソフトウェアのSoftware Cluster（SWCL）群への分割および部分差し替えの概要イメージ（クリックで拡大） 出典：AUTOSAR R20-11 CP EXP Layered Software Architecture

図4　SWCL間の接続（クリックで拡大） 出典：AUTOSAR R20-11 CP EXP Layered Software Architecture

　ここで注意すべきなのは、SWCLは、ISO 26262で要求される「パーティショニング（Partitioning）」の単位となることを直接的に想定したものではないということです（SWCL分割はFreedom from Interference（FFI）を達成しパーティショニングを実現するための手段としては適切ではありません）。

　むしろ、ランタイム性能要件が厳しい場合に対応するために、複数のSWCLが1つのパーティションを共有することも想定されています。パーティショニングの単位は、あくまでパーティション（EcucPartition）であり、CP Flexibility導入以前と同様にOsが提供するOsApplicationにより実現されるものとなります。

　各Software Cluster間は、Binary Manifest（BManif）の情報に基づき、Software Cluster Connection（SwCluC）により相互接続されます（SWCL間のI/Fのシンボル／アドレスの接続を行い、相手側が接続されていない場合には、その旨の情報を提供）。このメカニズムは、R4.4.0で導入された、RTE Implementation Plug-In Service（RIPS）の各種API関数の形で実現されます。

　これらの関数の振る舞いは、R20-11では実装依存であり標準化されません。また、その部分のコード生成方式も実装次第となります（自動コード生成されない場合には、BManifの情報に基づき手作業で実装することとなります）。

　これらの対策によって、一部のSW-Cを更新しようとした場合に影響が及ぶ範囲を限定できるようになることで、少なくとも以下のようなことが期待できます。

• RTEコード生成時間の短縮
• ビルド時間の短縮
• ビルドにより変化するバイナリ範囲の限定による、リグレッションテスト工数の削減
• ECUソフトウェアのバイナリの一部のみの更新の容易化
• 分散開発において、担当する開発部分以外のソースコードの授受や管理上の負担の低減（RTEが生成するヘッダをincludeする部分は、従来授受が必要でした）

　なお、各BSWのHigh ProxyとLow Proxyの境界は、今後標準化の議論が行われていきます。

　図4では、診断やWatchdog Stack、通信、不揮発メモリサービスなどが登場していますが、実は、R20-11時点ではそれらはまだ解決していません（R20-11は全体構想策定とRTEの解決のみということもできます）。

　例えば、私の担当するWatchdog Stackに関しては以下のような内容を決めていかなければならないでしょう^※10）。

• どのSWCLがハードウェアWDTをトリガーするのか（WDTトリガー: 安全の確認が取れたので、一定期間はマイコンに対するリセットをしなくてよい、という旨の、ハードウェアWDTへの通知）
• SWCLをまたぐ監視は必要なのか
• 異常検出時の対処は今までのままでよいのか？（例：Fail-operational）
• Applicative SWCLではどのようなサービスを利用したいのか？　全部必要なのか、一部だけでよいのか？^※11）
• FFIに関する考慮（特に時間測定）
• WdgM High Proxyとして、複数のベンダーからの製品を許容するか否か（許容しなければ、可能な限り実装依存としてリーンな標準規格になりますし、許容することになれば、これまで実装依存としていた部分の詳細を定義していく必要があります）
• 各SWCL間のタイミングのズレに対する対処は？

　なお、「異常検出時の対処（Recovery Action）」に関して補足しておきます。Watchdog Manager（WdgM）が異常を検出した場合の動作の1つとして、R20-11時点では、Partition Shutdown and Restartという選択肢が用意されていますが、実は、この機能は実質的に使い物にはなりません。

　というのも、私がこのモジュールの文書責任者を引き受けるよりもはるか以前（R4.0.1）から、異常検出後に結果的にはWdgMによるWDTトリガーを停止する状態に陥ること（WDTによるマイコンリセットにつながること）、さらには、BSW／RTE全体として「一部Partitionだけが停止している／動作していない／再開する」という状態／過渡状態への考慮が足りていないことなどの問題があるからです。

　これらの解決には、現代そして近未来のユースケースを想定しながら「システム／ECUとしてどうしたいのか？」というニーズを見極め、明確化することが必要です。

　また、この種のニーズの明確化に際しては、fail-operational／fail-degraded動作への対応戦略も関係してきます。

　欧州系の企業からはニーズや実ユースケースまたは想定、優先度付けのためのインプットが多数出てきていますが、残念ながら、現時点では日系の企業からは何も出てきていません。

　過去の経緯からしても、欧州系とニーズが同じ、とはにわかには信じ難いところもあり、懸念しています。