AUTOSARの最新リリース「R19-11」とは（中編）：AUTOSARを使いこなす（15）（4/4 ページ）

[櫻井剛，MONOist]

R19-11におけるClassic Platformの主な変更点

　では、R19-11でのCPの変更点のうち、主なものを見ていきましょう。

• BSW全般
  • API Service ID見直し（ある時点から値が誤って変化し、一部は重複もしていましたので、それを修正しました）
  • 各BSWからDet（Default Error Tracer）やDem（Diagnostic Event Manager）に通知される、Development Error、Runtime Error、Transient Faults、Production Error、Extended Production Errorの分類の見直しも行われています
  • また、ヘッダファイルにどのような宣言を持たせるかについてのR4.4.0での変更（header file cleanup）で生じた、標準ヘッダファイル名に関する混乱が修正されています。これは、「見れば／少し考えれば分かる」（自然の誤り訂正機能が働く可能性が高い）という類の問題ではありますが、単一モジュールの開発段階では見過ごされ、インテグレーション段階で露見するようなものですので、ある意味では性質が悪いといえるかもしれません
    • StandardTypes.h→Std_Types.h
    • ComStackTypes.h→ComStack_Types.h
    • PlatformTypes.h→Platform_Types.h
  • Validation作業が終わったものは、draftのステータスが消えています。なお、変更履歴にはValidationが終わったものが書かれていることがありますが、多くの場合、内容の変更はありません
• AdcおよびPwm
  • R4.3.1で幾つかのAPIがsynchronousからasynchronousに変更され、前者はobsolete扱いになっていましたが、今回削除されました
• BswM（Basic Software Mode Manager）
  • 条件が成立したことにより一連のアクションを実行する際の、アクションリストに優先度が設定できるようになりました
  • また、動作を周期関数内で行うか（deferred）、あるいは、BswMへのイベント通知時点で行うか（immediate）の内部であえて遅延を持たせる場合にimmediateを選択した場合の振る舞いが明確化されています（計時は周期関数で行いますので、当然deferred扱いとなります）
• CanSM（CAN State Manager）およびComM（Communication Manager）
  • 内部ステートマシンが再度見直されています
• Eth（Ethernet Driver）および EthSwt（Ethernet Switch Driver）
  • 2500Mbpsに対応しました
• RTEおよびCom
  • ECU間Client/Server通信でのServerは、Clientが複数あった場合にはそれぞれを識別しなければなりません。また、J1939通信でも送信元を区別しての対処が必要になります。これらの識別に使われる情報であるメタデータへのアクセスのためのAPI拡張などが行われています
• SecOC（Secure Onboard Communication）
  • 診断通信をSecOCで保護する場合の振る舞いを明確化しました。なお、診断通信で長大なデータをやりとりする際のRAM消費量を節約するために使用されるon-the-fly（paged buffer）動作については、現時点では保護できません（［SWS_SecOC_00058］）
• StbM（Synchronized Time-Base Manager）
  • StbM_GetCurrentTimeRaw APIなどのobsoleteとなっていたものが削除されています
  • また、「Time Validation Support」という新たな機能がdraft扱いで追加されています。Time MasterとTime Slaveが同期できているかをValidatorが監視するのですが、実装依存とされている部分が多く、SWS上には、具体的な説明があまりありません
• WdgM（Watchdog Manager）
  • せっかくですので、自身が担当するこの文書についてだけは、少し細かくご説明いたします
  • WdgMが持つ監視アルゴリズムには、Alive Supervision（ゲートタイム内のAlive通知回数が、指定範囲内に収まっているか否かの監視）、Deadline Supervision（ある区間の開始点到達通知から終了点到達通知までの時間長が、指定範囲内に収まっているか否かの監視）、Logical Supervision（想定外の処理シーケンスが行われていないかどうかの監視）の3つがあります。しかし、従来のDeadline Supervision機能では、終了点にいつまでも達しないこと（タイムアウト）を検出する能力がありませんでしたので、その能力が追加されています
  • また、この終了点を参照するパラメータ名のスペルが、章によって異なっていたため、統一されました。実はパラメータ名に古くからスペルミスがあったのですが、既存のconfigurationの流用ができなくなるとそれもまた困りますので、苦肉の策ではありますがスペルミスを容認する形となりました（あまりすっきりはしませんが、まあこんなこともあります）
  • 他のパラメータでは、ある機能に関するパラメータ設定が、その機能を使わない設定になっているにもかかわらず必要になるという、多重度制約に関するおかしな部分がありましたので、修正してあります
  • 初期化中に、ウォッチドッグのハードウェア制御が失敗した場合の動作が未定義でしたが、明確化されました。即座にMCU Reset APIをcallするように設定されていればそうなりますし、その後はウォッチドッグのハードウェアに対してトリガ信号を一切出さずにリセットを待つことになります
  • また、監視アルゴリズムのうち、特にAlive SupervisionやDeadline Supervision（タイムアウト監視部分）については、初期化後いつ監視を開始するかという問題が常に付きまといます（計時の起点をいつにするか、通知をいつから受け付けるか）。このため、全ての監視について、初期化後初の周期関数のcall時点から開始することを明確にしました
  • 各種監視アルゴリズムの結果を基にした、ステートマシン（Local Supervision Status／Global Supervision Status）内部のカウンタ操作や閾値判定用パラメータの取り扱いについても、記述内容に矛盾が見られましたので見直されました。従来の実装の際にどう解釈したかによっては、閾値の解釈が振る舞いを変えねばならなくなります（これは、あいまいな点を独自解釈に基づき対処した際に生じるリスクの典型的なものです）
  • 他にも、そもそも文書構造が壊れていた部分もありましたし、API名の誤記（コピペミス）など、多数の誤記もありました（正規の手順で発行された規格文書ではあるのですが、まあ、こんなものです）
  • 網羅的に書き出すときりがないことがお分かりいただけると思います

次回に続く

　次回はAdaptive Platform（AP）側の変更です。また、2020年3月3〜4日に、ポルトガルのリスボンで「AUTOSAR Open Conference」が開催されますので、その内容も可能な範囲でご紹介いたします。