AUTOSAR CP入門（その4）BSWが提供するサービスの利用：AUTOSARを使いこなす（27）（3/3 ページ）

車載ソフトウェアを扱う上で既に必要不可欠なものとなっているAUTOSAR。このAUTOSARを「使いこなす」にはどうすればいいのだろうか。連載第27回は、「AUTOSAR CP入門」のその4として「BSWが提供するサービスの利用」について取り上げる。

[櫻井剛，MONOist]

2.3.2 動作監視（Watchdogスタック）

　通信以外のクラスタが提供するサービスをSW-Cから利用する際には、BSW群の中の最上位部分であるServices Layer BSWモジュール（クラスタ全体として提供するサービスの窓口役）が提供するサービスを、RTEを経由して利用することとなります。

　Watchdogスタックは、WdgM（Watchdog Manager）、WdgIf（Watchdog Interface）、Wdg（Watchdog Driver）から構成されますが、このうちServices Layer BSWに相当するのはWdgMです。

　このスタックは、その名称とは異なり、ハードウェアウォッチドッグを制御するだけではありません。

1）動作の監視（Supervision Functions）：Alive supervision（Heartbeat）、Deadline supervision（処理完了のDelay／Timeout検出）、Logical supervision（Graphに基づくControl Flow Monitoring）の3種類の基本的な監視メカニズムを持つ。主な監視対象（Supervised Entity、SE）はSW-Cであるが、監視の単位をREとすることも可能であり、また、BSW動作を監視させることも理論的には可能。監視は、監視対象からの「Checkpointへの到達通知」に基づき行われる。

• Alive Supervision：周期的な動作の監視（時間区間内の通知回数は正常範囲内か？）
• Deadline Supervision：処理完了のDelay／Timeout検出（非周期的な動作の監視−「処理の2点間の経過時間は正常範囲か？」）
• Logical Supervision：制御フローが意図通りであることの監視

2）ウォッチドッグデバイスの制御（Watchdog Handling）：監視結果に基づき、WatchdogデバイスへのTrigger信号発行制御の指示をWdgMが出し、その内容をWdgIf経由でWdgに伝え、実際のTrigger信号を発行させる。

3）異常検出時の対処（Error Handling／Failure Recovery／Recovery Action）：異常検出後の対処を行う。選択肢としては、RTEへの動作モード変更通知、Diagnostic Event記録（Dem：Diagnostic Event Managerへの通知）、Partition Shutdown ／Restart（Os APIによる ※R21-11時点ではすでに廃止予定）、ウォッチドッグデバイスへのTrigger停止（その後マイコンにリセットがかかることを想定）、マイコン即時リセットが用意されている。

　監視対象SW-C内のREから「Checkpointへの到達通知」を発行するには、Rte_Call() APIが使用されます。

　なお、実際の関数名は、Rte_Call_＜Port名＞_＜Operation名＞()となります。

• Operation名：各Service Layer BSWに対応したSWSのchap. 7 Functional Specificationの中から、使いたいサービス（Operation名）を探し出します。WdgMでの「Checkpointへの到達通知」のためのOperation名は「CheckpointReached」です
• Port Interface名：Operation名（ここでは「CheckpointReached」）をキーワードとしてSWS chap．8内「Service Interface」のsectionを検索すると、Operation「CheckpointReached」が、Port Interface「WdgM_LocalSupervision」内に含まれることが分かります
• Service Port名：Port Interface名（ここでは「WdgM_LocalSupervision」）をキーワードとしてSWSのchap．8内「Service Ports」のsectionを検索すると、「localSupervision_<各SEに設定されたCheckpoint名：皆さんがSW-Cのインタフェース定義を行う際に決定されるもの>」が標準のService Port名であることが分かります

　「SWSの読み方」の中でも、上記の部分は、SW-CからBSWサービスを利用する際の重要なポイントとなります（自力で読み解こうとすると、「こう読めばよい」と理解するまでには少々時間がかかるようです）、ご参考まで。

次回に続く

　前回、「スケジューラは分かるが、リアルタイムOS（RTOS）はいまひとつ」という皆さんに向けてのAUTOSAR CP入門のシリーズは、特にご要望がなければ次回で終了したいと思います、と申し上げましたが、原稿を書き始めてみたところ、すぐにchap．4までのボリュームを大きく見誤っていることに気付きました（疲れがたまっているせいか、目算が狂いました）。今回は区切りの良いところでいったん止め、次回に続けてまいります。

　次回は、他のクラスタのBSWの機能を簡単にご紹介してまいります（果たして、次回で終わるのでしょうか!?!?）。

• 1．処理の起動
  • 1.1 トリガーの受け取りと、トリガーに対応した処理の起動
    • 1.1.1 スケジューラ方式の場合
    • 1.1.2 RTOSを使用する場合
    • 1.1.3 AUTOSAR RTEを使用する場合
  • 1.2 トリガーの生成
    • 1.2.1 スケジューラ方式の場合
    • 1.2.2 RTOSを使用する場合
    • 1.2.3 AUTOSAR RTEを使用する場合
• 2．処理の中身（ふるまい）の実現
  • 2.1 機能、それを実現する処理実行単位と、インタフェース
    • 2.1.1 AUTOSAR CPでのSW-C間インタフェース
    • 2.1.2 AUTOSAR SW-C内インタフェースおよびSW-C内部で利用できるその他のメカニズム
      • 2.1.2.1 RE間のデータ授受用インタフェース：Inter-Runnable Variable（IRV）
      • 2.1.2.2 不揮発メモリからの読み出し／不揮発メモリへの退避対象データ：Per-Instance Memory（Pim）
      • 2.1.2.3 Calibration対象の固定値データ：Calibration Parameter（CData）
      • 2.1.2.4 RE間の排他制御：Exclusive Area（EA）
      • 2.1.2.5 RE間のTrigger：Internal Trigger
  • 2.2 SW-Cのモデリング：typeとprototype
  • 2.3 BSWが提供するサービスの利用
    • 2.3.1 ECU間の通信（送受信）、通信チャンネル制御とネットワークマネジメント（通信スタック）
    • 2.3.2 動作監視（Watchdogスタック）　←今回はここまで
    • 2.3.3（続く）
• 3．SW-Cとその他の要素（RTE、BSW、HW）とのインテグレーション
• 4．従来と同じことしかできないの？（いいえ、違います！）