バックナンバーはこちら。
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
WriteDataByIdentifierサービス
そして今回はシミュレーションする予定の中の最後のサービス、
WriteDataByIdentifierサービスについて。
これって、ReadDataByIdentifierサービスの逆なんだっけ?
ReadDataByIdentifierサービスが読み出しで、
WriteDataByIdentifierサービスが書き込み。
まずはそのイメージで良いかな?
その言い方だと、違うって聞こえるんだけど。
間違ってはいないけど、その考え方では成立しないものもあるって感じかなー。
えー!具体的には?
DIDで車速、エンジン回転数を取得できるものがあったとして、
そのDIDはReadDataByIdentifierサービスではサポートされるものだけど、
WriteDataByIdentifierサービスでは非サポートになる。
あー、確かにこんなの書き換えられるとえらいことになるねー。
というわけで、必ずしも対ではないってことだけ覚えておくと良いよ。
WriteDataByIdentifierサービスの利用シーン
これも利用シーンを説明してもらえると分かり易いかも。
ReadDataByIdentifierサービスの時もそうだったけど、
DIDの定義って完成車メーカ依存なんだよねー。
まぁ先も言ったようにReadDataByIdentifierサービスよりも制約が強いんで、
恐らくこれくらいでしょう。
って話はできそうかな?
それそれ。
フクさんの経験則で良いよ。
じゃー、経験則で。
おおよそ以下かな。
- 制御パラメータの書き込み
- 車両、ECU、ソフトウェアの識別番号の書き込み
共通しているのは、E2PROM等に格納される不揮発な情報ってところだね。
ここらへんの情報って簡単に書き換えちゃいけないような気がするんだけど。
おー!鋭いね!
まさにその通りで、
基本はセキュリティロックがサービスかDID別にかかってることが多いよ。
やっぱり!
不揮発性メモリに書き込むが故の性質
WriteDataByIdentifierサービスの性質というか、
WriteDataByIdentifierサービスが「不揮発性メモリに書き込む」ことが多いが故の性質になるんだけど。
なに?
即時レスポンスにならなくて、場合によってはNRC$78が返る。
え?なんで?
不揮発性メモリの書き込みって大きく3手順ある。
- メモリ消去
- 書き込み
- ベリファイ
あ、そうか!
すぐに書き終わるわけじゃないから、
書き終わるまでオフボードテスタ側に待ってもらう必要があるのか!
そこでNRC$78が必要になると。
まぁP2時間のUDSの推奨値は1秒、OBDの設定値は50msなんで、
基本は間に合うはずなんだけど、
絶対間に合う保証もないので、とりあえずNRC$78を返すって実装になってることもあるねー。
そうなの?
NRC$78が返ってP2*時間の5秒に延長するんだけど、
結果的には10ms程度でPositiveResponseが返るって挙動があり得るってこと?
そうね。
まぁ仕様に違反しているわけでもないし、
確実性を考えると、まぁありな仕様だとは思うよ。
まぁ方針が明確だし、その方が楽そうではあるねー。
まとめ
まとめだよ。
- WriteDataByIdentifierサービスの説明。
- 利用シーン。
- 不揮発性メモリに紐づいた通信上の特性。
バックナンバーはこちら。
コメント