車載開発：AUTOSAR CLASSICのCAN通信モジュール概要
たいていの場合、CAN通信系が一番弄ることが多いんじゃないでしょうか。設定も多い印象で、主要なモジュール群の1つかと思います。この記事では、AUTOSAR Classic PlatformにおけるCAN通信関連のモジュールを、「共通系」「診断機系」「制御通信系」に分けて簡単に整理してみます。
共通系モジュール
各ID、PDUのルーティングのほか、NMや起動制御もこちらにまとめます。起動制御まわりもトラブルが多い箇所かなと思います。
PduR
上位（COMやDCMなど）と下位（CAN DriverやCanTp）をつなぐPDUルーティング担当。ルーティングテーブルに基づいてデータを中継します。
COMM (Communication Manager)
ECU起動や通信状態（スリープ/アクティブ）の制御を行います。ECUの通信状態遷移のカギを握るモジュール。
CanNm (CAN Network Management)
ネットワークマネージメント。ECUがバス上に参加しているかどうかの状態を管理・通知します。いわゆるAUTOSAR NMのNM状態管理ですね。
CanIf
CANドライバ抽象化モジュール。物理チャネルや制御チップの違いを隠蔽して、上位層に共通インタフェースを提供します。バスオフとかもここで定義されてます。
Can Driver
最下層。実際のCANハードウェアを制御します。送受信処理、バスオフ検知などもここで対応。マイコンレジスタ直下のイメージ。
バスオフなどのエラー検知は、Can Driver → CanIf → DEM に渡ってDTCイベントとして管理されることが多いです。
診断機系モジュール
私は診断機仕様でCAN TP、DCMどっちの仕様だったっけ、とよくなりました。なんか細かいとこはごっちゃになるんですよね、まあ仕様書見れば探せはするんですが。基本的にCAN TPはマルチ/シングルフレームだったり、通信の各時間、ダイムアウトとか物理に近いとこの仕様が入ってるイメージです。DCMはもっとアプリ寄りのUDS仕様系のイメージです。
通常の経路：
DCM ⇔ PduR ⇔ CanTp ⇔ CanIf ⇔ CAN Driver
CanTp
ISO-TP（ISO 15765）に対応するためのトランスポート層。フレーム分割と再構成を担当します。
DCM (Diagnostic Communication Manager)
診断通信（UDSなど）の制御・提供。セッション管理やサービステーブル定義などもここで。
DEM (Diagnostic Event Manager)
通信ていうか、な感じで今回入れるのセンス無い気もしますが。。。故障イベント（DTC）を記録・管理します。OSからのエラーやDCM経由の診断結果を統合的に管理。
制御通信系モジュール
いわゆる普通のCAN通信系のIDの制御です。
通常の経路：
COM ⇔ PduR ⇔ CanIf ⇔ CAN Driver
COM
アプリケーション層と通信スタックをつなぐインタフェース。信号単位での送受信処理を担当します。
ARXMLとID/Signal定義の役割分担
ARXMLでCANテーブルが管理されているケースは多いかと思いますが、それぞれに紐づくモジュールを整理します。
COMはあくまで論理定義を担い、CAN IDなどの物理送信情報はCanIfやCAN Driverで制御される構造です。
| 要素 | 管理モジュール | 説明 |
|---|---|---|
| Signal | COM | アプリから見える最小データ単位 |
| PDU | COM | Signalのまとまり。論理データ単位 |
| CAN ID | CanIf / CAN Driver | 実フレームで使うID。物理層寄りで管理 |
おわりに
CAN通信スタックは、AUTOSAR Classicの中でもとりわけ重要で変更頻度も高い領域です。それぞれの役割を理解しておくことで、設定・デバッグ時の混乱がかなり減るかと思います。
Discussion