車両診断通信【バックナンバー】

はじめに
英訳とか
関連書籍とか
動画とか
DoCAN概要
CAN
ISO-TP
CanTpシミュレーション
UDS
Dcmシミュレーション
CAN-FD概要
python-canでCAN-FD
CAN-FDのISO-TP
CAN-FDでAUTOSAR
ここまでの振り返り

はじめに

車両診断通信についていろいろ語っていく系のバックナンバー。

Wikipedia On-board diagnostics OBD
https://ja.wikipedia.org/wiki/%E3%82%AA%E3%83%B3%E3%83%BB%E3%83%9C%E3%83%BC%E3%83%89%E3%83%BB%E3%83%80%E3%82%A4%E3%82%A2%E3%82%B0%E3%83%8E%E3%83%BC%E3%82%B7%E3%82%B9

英訳とか

海外(日本外)の方らちょいちょいリクエストがあるので、英訳中

Vehicle Diagnostic Communication back issue

IntroductionThis is a back-issue of a series that discusses various aspects of vehicle diagnostic communications.The fol...

動画とか

とりあえず、時間見ながら作っていく予定。

概要編

車両診断通信#1 概要編

車両診断通信の動画作成のリクエストをいただいたのでとりあえず作ってみました。チャンネル登録よろしくお願いします。詳細はこちら

CAN編

車両診断通信#2 CAN編

モチベーションとは無関係に車両診断通信の続きのCAN編を作成。チャンネル登録よろしくお願いします。詳細はこちら

Addressing Format編

車両診断通信#3 Addressing Format編

車両診断通信のネットワーク層について。今回は特にアドレッシングフォーマットについての解説。チャンネル登録よろしくお願いします。詳細はこちら

DoCAN概要

車両診断通信の概要情報はググればOK。
代表的な規格はISO15765-2とISO14229-1。
- 完成車メーカの方針によっては具体的な要件ではなく、規格番号が要件ということもある。

https://www.simulationroom999.com/blog/diagnostic-communication-1/

車両診断通信のレイヤはOSI参照モデルで表現できる。
- ただし、プレゼンテーション層は無い。
車両診断通信には大きく2つの軸がある。
- UDSとOBD。
- OBDは自動車排出ガス規制から参照されているため、各種パラメータが明確。
- UDSは推奨値があるだけで、実際の数値は完成車メーカ依存。

CAN

必要な規格番号復習。
CANは割と一般的になってきたのでネット上からそこそこ情報が得られる。
DoCANでは1Mbpsが使われることはほぼ無い。
- 法規の都合。
- 1Mbpsだと安定性が欠ける面がある。

基本的には「はじめてのCAN/CAN-FD」を読んでおけばOK。
CANのボーレート設定は特殊。
- いきなりボーレートを決めることはできず、1bitを分解したクウォンタム時間を先に決める。
- 総クウォンタムがボーレートになるので、設定したいボーレートから逆算する必要がある。
CANはサンプリングポイントを調整できる。
- 総クウォンタム中のどこのクウォンタムでサンプルするかで決定できる。
- [%]で表現されることが多い。
- 真ん中であれば50[%]、やや後ろ側(3/4あたり)あれば75[%]。

サンプリングポイントを決定するには各セグメントのクウォンタム数を決定する必要がある。
セグメントは4種で1bit分。
- Synchronization Segment。
- Propagation Segment。
- Phase Segment1。
- Phase Segment2。
Propagation Segment+Phase Segment1でtseg1、Phase Segment2をtseg2と表現することもある。

ISO-TP

1対1通信の物理アドレスと1対多の機能アドレスがある。
物理アドレス、機能アドレスは4種類のアドレッシングフォーマットによって構成が変わる
アドレッシングフォーマットはN_AI、N_TAtype、N_TA、N_SA、N_AEで構成される。
- ただし、アドレッシングフォーマットによって使ったり使わなかったり。

Normal Addressingは最もシンプルなアドレッシングフォーマット。
Normal fixed addressingは最も仕様として定義し易いアドレッシングフォーマット。

Extended addressingはNormal addressingのN_TA追加の拡張版。
Mixed addressingは11bitID版と29bitID版がある。
- 11bitID版はNormal addressingベースのゲートウェイ越え想定版。
- 29bitID版はNormal fixed addressingベースのゲートウェイ越え想定版。

CAN複数フレームで最大4095byteまで送信/受信可能。
- N_PCIというパラメータが各フレームの先頭にあり、うまくつなげられるような仕掛けがしてある。
送信データ数によって送信方式が大きく2つに分かれる。
- 7byte以下であればシングルフレーム送信。
- 8byte以上であればマルチフレーム送信。
マルチフレーム送信はFCでCFの送信間隔、再度のFC受信タイミング設置などでスループットをコントロールする仕掛けがある。

4種類のフレームの説明。
- 先頭N_PCItypeがあるので、受信時に即判定ができる。
それぞれ固有のパラメータを持っている。
- SF。
  - SF_DL。
- FF。
  - FF_DL。
- FC。
  - FS。
  - BS。
  - STmin。
- CF。
  - SN。

SF-SF通信とMF-MF通信の各種フレームへの分解を実施。
- MF-MF通信はFCのBSやFSで若干挙動が変わる。
DLCの都合でメッセージに含まれない部分はパディングで埋める。
- パディングで使用する値は何でも良い。
- 良く使われ鵜値は00,55,AA,CC,FF。

ISO-TPのタイムアウトパラメータは6個、
- N_As、N_Bs、N_Cs、N_Ar、N_Br、N_Cr。
シングルフレーム送信は1フレームで完結しているのでN_Asだけ。
マルチフレーム送信は全パラメータを使用する。
ISO-TPはあくまでフレームレベルのタイムアウト判定をするだけで、メッセージ単位のタイムアウトは上位のレイヤで判定している。

ISO15765-2(UDS)とISO15765-4(OBD)でタイムアウトパラメータの数値は異なる。
- UDS側が緩く、OBD側が厳しめ。
タイムアウトパラメータの中にはパフォーマンス要求として設定されているものもある。
- N_Br、N_Cs。

CanTpシミュレーション

お勉強には飽きたのでそろそろシミュレーションするよー。
AUTOSARやるかもねー。
あえてPythonを使うというチャレンジもするよー。

Vector社の無償公開のXL Driver LibraryとVector Driver Setupをインストール。
XL Driver Libraryの中にxlCANControlというアプリがあるんで、それによる動作確認が手っ取り早い。
アプリ毎にチャンネルの割り当てができるので、コントロールパネルのVectorHardwareで割り当てをしておく必要がある。

BusMasterのセットアップをした。
BusMasterでVirtual CAN Bus上のCANフレームをモニタした。

やっとPython。
Anacondaでやるけど、公式のWindows向けPythonでもOK。
ちゃんと一個ずつ動作確認しておいて方が良いよ！(自分に言い聞かせている。)

python-canのインストールをした。
python-canの動作確認をした。
- can.playerで送信してBusMasterで収録。
python-canの動作性能は1～2[ms]オーダー。
- CANoe等だともっと早い。

can.playerで再生してcan.loggerで収録した。
can.loggerの収録ファイルフォーマットは3種類。
- asc、blf、csv。

python-canがサポートしているデバイスを列挙した。
pyton-canによる送受信を実現した。

Pythonパッケージのcan-isotpでISO15765-2ことISO-TPの通信ができる。ただし、python-canも依存関係の都合上インストールされている必要がある。
とりあえずSF(SingleFrame)の送信はできた。
マルチフレーム送信はFF(FirstFrame)で止まってしまってエラー終了となった。FFのあとにFCを受信しないと次のシーケンスに進めないプロトコル上の仕様。

python-canでFCの辻褄合わせした。
python-canでちょっとしたタイミングを見計らったCANフレームの差し込みで対応。
これにより、とりあえずマルチフレームリクエストが通った。

can-isotpのデフォルト状態だとDLC最適化仕様が採用される。
CanStackに渡すパラメータでパディング、MIN_DLCを設定するとパディング仕様に切り替わる。

can-isotpのマルチフレームリクエストの振る舞いを変えるためFC相当を変えてみた。
- 指定したSTminに準拠する振る舞いにはなった。
通信上の時間パラメータはシステム間で同期が取れないことを前提として幅を持たせている。
- 10[ms]以上ならば、11[ms]を狙って、確実に10[ms]以上を満たす。

車両診断通信の大半はリクエスト-レスポンスで一つの通信。
- 例外的にリクエストのみ、レスポンスのみもあるが、かなりレアなパターン。
リクエスト側、レスポンス側ともに受信スレッドの仕組みでスクリプト肥大している。

can-isotpのリクエストレスポンスの実験を行った。
SF-SF通信→OK！
MF-MF通信→OK！

can-isotpのFCパラメータ変更実験をした。
can-isotpの完成度は高い。
- 少なくとも、そこらの構造が破綻したヤッツケ車両診断通信よりかは遥かに良い。

AUTOSAR CanTp編に突入だよー。
AUTOSARはSW-C、RTE、BSW、MCALのレイヤー構造になってる。
AUTOSAR CanTpはBSWの一つでISO15765-2を再現している。

MCAL-CANDRVを実現するには受信割り込みと送信完了割り込みの再現が必要。
XLドライバライブラリは受信、送信済み、エラーのイベントをWin32APIのイベントオブジェクト経由で通知する。
- よって、Win32APIによるスレッド、イベントオブジェクトのハンドリング知識が必要。

割り込みエミュレーションのコードを提示。
WaitForSingleObjectでシグナル待ち。
xlCanReceiveで受信、送信、エラーの各種情報を取得。
xlEvent.tagで各種処理に振り分け。

TOPPERS協会からA-COMSTACKというAUTOSARの通信スタックBSW群が公開されている。
- この中のCanTpを使用。
A-COMSTACKはAUTOSARパートナーになっていないと商用利用出来ない。
- 今回は学習目的で利用。
動作確認用のオフボードテスタ側はpython can-isotpを使用する。

A-COMSTACKのCanTpの本体はcantp.c。
多くのヘッダファイルも持ってくる必要がある。
タイマ割り込み、排他はWin32APIで実現。

AUTOSAR CanTpの仕様はAUTOSAR_SWS_CANTransportLayeで公開されている。
最低限把握する必要のあるインターフェースは以下。
- CanTp_Transmit。
- CanTp_MainFunction。
- CanTp_RxIndication。
- CanTp_TxConfirmation。
- CanIf_Transmit。
- PduR_CanTpCopyRxData。
- PduR_CanTpCopyTxData。
- PduR_CanTpRxIndication。
- PduR_CanTpStartOfReception。
- PduR_CanTpTxConfirmation。

AUTOSAR CanTpのインターフェースの復習。
AUTOSAR CanTpのインターフェースを図解してみた。
各種インターフェースはそれぞれのヘッダファイルで定義はされている。
- シミュレーション用に辻褄合わせは必要。

CanTpは送信、受信の1対で1チャンネルという概念になっている。
チャンネルは複製可能
- ただし、動的複製は不可。静的複製のみ。

CanTpのコンフィグレーション構造はAUTOSAR仕様に記載されている。
しかし、UMLによる表記無し。
- OSEK時代からの踏襲であるため更新優先度が下がってる可能性あり。
今回はコンフィグレータを使用せず、手動で該当の構造体実体を定義していく方針。

AUTOSAR-CanTpの具体的なコンフィグレーション構造体を定義した。
CanIfとやり取りする際にPduIdという番号を使用する。
- 今回の場合は以下。
  - 0：0x18DAF110 の送信。
  - 1：0x18DA10F1 の受信。
  - 2：0x18DA10F1 の送信。
  - 3：0x18DAF110 の受信。
CH_RX_CBこと受信管理ブロックとCH_TX_CBこと送信管理ブロックはワーク用。

Python can-isotpのリクエスト用スクリプトを修正。
- 一応ISO14229-1に準拠したリクエストにしている。
AUTOSAR-CanTp側も実装。
- こちらもSO14229-1に準拠したレスポンスにしている。
- 一身上の都合でコードは未公開。

シミュレーション構成の復習。
疑似ECU側のコード扱い。
- 現状は非公開で勘弁してね。
SF-SF,SF-MF,MF-MFの通信ログ確認。

FC(FlowControl)のBS(BlockSize)パラメータを弄ったシミュレーション実施。
シリーズのまとめ。
- CANoeとPythonの共存したテスト環境とか便利かもしれない。

UDS

故障診断通信レイヤの復習。
レスポンスメッセージタイムアウトパラメータはP2時間。
セッションタイムアウトパラメータはS3時間。

P2時間について図解説明。
- P2*タイムアウトは追々説明。
S3時間について図解説明。
セッションについては追々説明。
- 各種サービスを知らないと難しい。

診断サービスは６つの機能単位というカテゴリに分類される。
Diagnostic and Communications Managementの説明。
- セッション、セキュリティ、通信制御。
Data Transmissionの説明。
- メモリアドレス、DIDによるデータの読み書き。

Stored Data Transmissionの説明。
- DTC及びフリーズデータの取得とクリア。
Input/Output Controlの説明。
- ECUのI/O制御。
- 便利な反面、車両状態によっては危険なこともあるので、セーフティ機能含めて考える必要があるサービス。

Routineの説明。
- 主に開発時に使用するような機能で利用される。
Upload/Downloadの説明。
- データ転送用で圧縮と暗号化も出来るサービス群。

ISO14229に対応するAUTOSAR-BSWはDCM。
A-COMSTACKにはDCMは含まれていない。
OpenSARという別のオープンソースAUTOSARがあり、それにはDCMが含まれている。

USDシミュレーションの全体構成発表。
A-COMSTACKはAUTOSAR r3.x系でOpenSARはAUTOSAR r4.x系。
- よって、違法建築。

UDSシミュレーションで実現するサービスは５つ
- DiagnosticSessionControl。
- SecurityAccess。
- TesterPresent。
- ReadDataByIdentifier。
- WriteDataByIdentifier。
リスクストメッセージとレスポンスメッセージの説明の際はCANフレームまでの落とし込みはしない。
- あくまでISO14229-1のレイヤのみでISO15765-2のレイヤの話はしない。

DiagnosticSessionControlのISOで定義されているセッションについて説明
DiagnosticSessionControlのリクエストメッセージ。
DiagnosticSessionControlのレスポンスメッセージ
- 該当セッションのP2時間とP2*時間が取得できる。

PositiveResponseの説明。
- Response SIDはRequest SIDに0x40とORを取ったものをセットする。
NegativeResponseの説明。
- 0x7F 0x10 0x12のような感じ。
- ResponsePendingのような特殊なものは次回説明。

P2時間の復習。
- P2時間は1秒
P2*時間の説明
- P2*時間は5秒。
- オフボードテスタはNRC$78を受信するとP2時間からP2*時間に切り替わる。
- オフボードテスタは再度NRC$78を受信すると、そこからP2*時間分延長。

SecurityAccessサービスは大きく2種類のメッセージパターンがある。
- requestSeed。
  - sub-functionが奇数。
- sendKey。
  - sub-functionが偶数。

SecurityAccessサービスはわざとメンドクサイ手順を踏ませており、これがセキュリティ強度になっている。
- 事前に非defaultSessionに遷移している必要あり。
- IGon後10秒待たないとダメ。
- 解除ミスをしたら一旦IGoffしないとダメ。

SecurityAccessサービスの基本フローを説明。
SecurityAccessサービスの基本フローに於ける実際のメッセージを説明。
セキュリティが掛かるのはリソース。
- サービス。
- DID。

TesterPresentサービスという何もしないサービスがある。
TesterPresentサービスは以下の利用シーンがある。
- 疎通確認。
- ノード有無確認。
- セッション維持。
TesterPresentサービスは必ずサポートしなければならないサービス。

TesterPresentサービスのメッセージについて説明。
suppressPosRspMsgIndicationBitについて説明。
- PositiveResponse抑制。
- NegativeResponseは返す。
- NRC$78後のPositiveResponseも返す。

ReadDataByIdentifierサービスの利用シーンを説明。
- 車両の状態モニタ(開発中の検証、市場に出た後の不具合解析)。
- 車両組み立て時の強制動作状態監視。
- 故障検知時のフリーズデータ取得。

ReadDataByIdentifierサービスのリクエストメッセージの説明。
- 複数DIDが設定できる。
- 設定できるDIDの個数制限がある場合があり、それを超えるとエラー。
- レスポンスメッセージが4095byteを超える場合もエラー。
ReadDataByIdentifierサービスのレスポンスメッセージの説明
- DIDとdataRecordの組み合わせ。
- 複数DIDの場合は上記組み合わせが複数一つの電文に載る。

シングルDIDの送受信を見た。
マルチDIDの送受信を見た。
- 一部のDIDが未定義なパターンも。

WriteDataByIdentifierサービスの説明。
- 利用シーン。
- 不揮発性メモリに紐づいた通信上の特性。

WriteDataByIdentifierサービスのリクエストメッセージの説明。
- ReadDataByIdentifierサービスと異なりDIDは一個固定。
WriteDataByIdentifierサービスのレスポンスメッセージの説明。
- 実際にはNRC$78は挟まる可能性あり。

WriteDataByIdentifierサービスの具体的送受信例。
- NRC$78を含めた送受信例も。

Dcmシミュレーション

AUTOSAR-Dcmシミュレーション構成復習。
AUTOSAR-Dcmシミュレーションで使用するサービス確認。
- 具体的に確認したい項目も。
- responsePendingCountというNRC$78の返信回数規定も含める。

AUTOSAR-Dcmの仕様書(r3.3)を確認。
AUTOSAR-Dcmのインターフェース確認。
NRC$78はAUTOSAR-CanTpとしては単なるSingleFrame。

AUTOSAR-Dcmのインターフェース仕様図解した。
- 通信用のバッファはAUTOSAR-Dcm管理で、省メモリ省コピー型の設計実装になっている。
AUTOSAR-Dcmの中は３つのサブモジュールで形成されている。
- dsl：Diagnostic Session Layer。
- dsd：Diagnostic Service Dispatcher。
- dsp：Diagnostic Service Processing。

AUTOSAR-Dcmのインターフェース関数復習。
AUTOSAR-Dcmのインターフェース関数を実装してみた。

AUTOSAR-Dcmの中身はdsl、dsd、dspで構成される。
const定義されているものと、work用に変数で定義されているものがある。
コンフィグレーション用の構造体は全部で50個くらい。

Dsl(Diagnostic Session Layer)はセッション関連のサブモジュール。
P2時間、P2*時間、S3時間などの時間管理をする。
実際に使用するCanTpのPudIdも内包。

Dslの構造体定義のコードを書いた。
リストの終端はArc_EOLがTUREの時。
- ※ OpenSARことArcCore独自の仕様
診断サービスの開始停止、有効なサービスリクエスト時、セッション移行をトリガとしたコールバック関数が定義できる。

Dsdは各サービスへの振り分けが目的のサブモジュール。
- 同時にサポートするセキュリティレベル、セッションの判定も行う。
上記目的から以下のコンフィグレーションパラメータを保有。
- 存在するサービス定義。
- サポートサービス定義。
- サービスがサポートできるセキュリティレベルとセッションの定義。

Dsdのコンフィグレーションコードを書いた。
対応するセキュリティレベルとセッションの実態はDspにあり、Dsdからは参照するのみ。

Dspはアプリケーション層。
- ISO14229-1依存と完成車メーカ依存に分かれ、完成車メーカ依存はコールバック関数で対応。
Dspの中でDIDに関連するものが最も複雑。
- DID関連を知ってしまえば、他のコンフィグレーションは比較的たやすい。

Dspのコンフィグレーションコードを書いた。
大部分はセキュリティ、セッションの定義とDIDとの紐づけ。

AUTOSAR Dcmシミュレーション構成の復習
オブボードテスタ側のPythonコードは今まで使ったやつを使いまわし
- 必要に応じて修正は入れる。
シミュレーションを試す順番は以下。
- DiagnosticSessionControl。
- SecurityAccess。
- TesterPresent。
- ReadDataByIdentifier。
- WriteDataByIdentifier。

DiagnosticSessionControlのシミュレーション用のPythonコード書いた。
通信パターンにはエラーパターンも含めた。
- 存在しないセッション。
- DiagnosticSessionControlリクエストとしては間違ったメッセージ長。

DiagnosticSessionControlのシミュレーションの結果を確認
- メッセージレベルの確認。
- CAN回線レベルの確認。
NegativeResponseはDcmで自動判定して返すものと独自にコードを追加して返すものがある。
- メッセージ長やパラメータ異常は自動判定。
- 車両状態による拒否は独自コード。

SecurityAccessのシミュレーション用のPythonコード書いた。
SecurityAccessの動作確認はいろいろありすぎる。
- サポートセッション。
- シーケンス。
- セキュリティアンロック状態のSeed。
- セッション遷移に伴うロック状態への遷移。
- S3タイムアウトに伴うセッション遷移。

SecurityAccessのシミュレーションの結果を確認。
- メッセージレベルの確認。
- CAN回線レベルの確認。
SecurityAccessはセッション状態、セキュリティ状態によって挙動が変わる。
- セッション状態に紐づく形でS3タイムアウトにも依存する。

TesterPresentsのシミュレーション用のPythonコード書いた。
TesterPresentsの主目的から考えて、SessionControl、SecurityAccessも実施する。
- S3タイムアウト抑制が主目的。

TesterPresentsのシミュレーションの結果を確認。
- メッセージレベルの確認。
- CAN回線レベルの確認。
suppressPosRspMsgIndicationBitありのTesterPresentsはAUTOSAR-Dcm仕様としては特別扱い。
- DslでS3時間延長をしたあとはメッセージ破棄して、Dsd、Dspには渡さない。
- ISO14229-1と異なる結果になるが、実用性の方を重視されている。

ReadDataByIdentifierのシミュレーション用のPythonコード書いた。
ReadDataByIdentifierのマルチDIDに関連したテストパターンメイン。
- マルチDID。
- 未サポートDIDを混ぜる。
- レスポンスメッセージ長が最大値を超えるようなDID指定。

ReadDataByIdentifierのシミュレーションの結果を確認。
- メッセージレベルの確認。
- CAN回線レベルの確認。
マルチDID仕様が厄介
- 存在しないDIDのリクエストはエラー。
  - しかし、マルチDIDで存在するDIDがあればエラーにはならない。
- DIDが存在していればエラーにはならない。
  - しかし、レスポンスメッセージ長都合でエラーになることもある。

WriteDataByIdentifierのシミュレーション用のPythonコード書いた。
WriteDataByIdentifierはセッションとセキュリティで保護されていることが多いのでそのテストがメイン。

WriteDataByIdentifierのシミュレーションの結果を確認。
- メッセージレベルの確認。
- CAN回線レベルの確認。
書いたあとの読み出しのためにReadDataByIdentifierを併用して動作確認することが多い。
NRC$78返答の雰囲気を出した。
- 実際は3回もNRC$78が続くことは少ない。

NRC$78(ResponsePending)が一定回数を超えるとNRC$10(generalReject)を返すパターンを見た。
この仕様はISO14229-1では規定されていない
しかし、デファクトスタンダードである可能性が高い。
- よって、AUTOSARの仕様として取り込まれていると推測。

CAN-FD概要

物理層、データリンク層をCANからCAN-FDに切り替える。
CAN-FDはVector社の「はじめてのCAN/CAN-FD」にそこそこ書いてる。

シミュレーション手順と勘所説明。
- python-canによるCAN-FD制御。
- can-isotpでCAN-FD診断通信(ISO15765-2)。
- AUTOSAR-CanTpでCAN-FD診断通信(ISO15765-2)。
- AUTOSAR-DcmでCAN-FD診断通信(ISO14229-1)。

python-canでCAN-FD

BusMasterはCAN-FDには対応していない。
CAN-FDのascフォーマットはCANとは異なる。
- FDFビットとBSRビットのパラメータが増えている。

can.playerとcan.logger復習。
CAN-FD,CAN混合の再生用ascファイル作成。
- CANを混ぜているのは異常時の影響範囲特定用。

can.playerとcan.loggerがCAN-FDに対応していないことが発覚。
- 即行でCAN-FD対応に修正してみた。
can.loggerはまたちょっと別の問題あり。

改造版のcan.playerとcan.loggerの使用方法説明。
- ともに”–fd”というオプションを追加しただけ。
can.player、can.loggerで再生＆収録した。
- can.loggerが内包しているascwriterがCAN-FDフォーマットに対応していないためCANとCAN-FDの区別がつかない。
- とりあえず、シミュレーションする上では気にしない方針。