バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO14229ことUDSの話。
WriteDataByIdentifierサービスの具体的な電文について。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
前提となるDIDリソース状態
ReadDataByIdentifierサービスの時と同じようにDIDを先に定義しておこう。
マルチDIDとかは無いから1個でいいんじゃない？
そうだね。一個だけ定義しよう。
- 0x1234：2byte
送受信
定義したDIDを使用した送受信がこんなん。
Req:0x2E 0x12 0x34 0x01 0x02
Res:0x6E 0x12 0x34うーん、驚くほどシンプルだねー。
実際はセッション移動とかセキュリティ解除が必要になるけどね。
このサービスだけの電文としてはシンプルだね。
そうか、セッションとセキュリティの存在を忘れてた・・・。
NRC含めた送受信
もう1パターンやっとくか。
え？他の通信方法もあるの？
通信としては一緒なんだけど、NRC$78が入るパターン。
あー、それは見ておきたい！
こんな感じ。
NRC$78は2回入る想定。
Req:0x2E 0x12 0x34 0x01 0x02
Res:0x7F 0x2E 0x78 // ResponsePending(P2*タイマへ移行)
Res:0x7F 0x2E 0x78 // ResponsePending(P2*タイマリセット)
Res:0x6E 0x12 0x34なるほど。
こんなイメージになるのか・・・。
これってオフボードテスタ―側もECU側も結構大変な気がするなー。
まぁNRC$78仕様はWriteDataByIdentifierサービスに限ったものじゃないで、
結構初期に解決する問題なんだよねー。
だから、あんまり大変とは思ってないかも。
え？そうなの？
明確なものは実装難度が高くても設計検証内容が明確なんで
結果的にはそれほど怖くないね。
ほー。そういうものなのかー。
一通りシミュレーションで扱うサービスは説明したから
次回から、シミュレーションの構成とかどうCanTpとDcmを繋いでいくかとかの話に突入だな。
まとめ
まとめだよ。
- WriteDataByIdentifierサービスの具体的送受信例。
- NRC$78を含めた送受信例も。
バックナンバーはこちら。
コメント