【CanTp】車両診断通信 その24【シミュレーション⑪】

バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/

はじめに
登場人物
FC応答のパラメータ
STminを変えてみる。
まとめ

はじめに

ISO-TPのシミュレーションをしよう。のシリーズ。
Pythonパッケージcan-isotpのマルチフレームリクエスト時のFC応答を変えてみる。

登場人物

博識フクロウのフクさん

イラスト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

FC応答のパラメータ

フクさん

FCの中のパラメータって覚えてる？

太郎くん

あー、えー、なんだっけ？

フクさん

FS(FlowStatus)、BS(BockSize)、STmin(SeparationTimeMinimum)

太郎くん

あーそれそれ！

フクさん

ちゃんと復習しておいてね。

STminを変えてみる。

フクさん

本来であれば、FS、BS、STminのすべてのパラメータを変えた実験をしたいところだけど、
現状のFC応答スクリプトをベースにするとSTminだけは超簡単なんで、
STminだけやる。

太郎くん

(メンドクサイんだな。)

フクさん

(「メンドクサイから」とか思われてるだろな。まぁそうなんだけど。)

フクさん

一応スクリプトを書くとこんなん。
ぶっちゃけFCのところが書き換わってるだけだ。

import can

# バス接続
bus = can.interface.Bus(bustype='vector', channel='0', bitrate=500000)

# 受信
while True:
	recv_msg = bus.recv(timeout=1)
	if recv_msg != None:
		print('Recv msg : %s' % recv_msg)
		break


send_msg = can.Message(arbitration_id=0x18daF110, extended_id=1, data=[0x30, 0x00, 0x0A, 0xCC, 0xCC, 0xCC, 0xCC, 0xCC])
print('Send msg : %s' % send_msg)

# 送信
bus.send( send_msg )

太郎くん

この電文だと、STmin=10ってことで、CFとCFの間を10[ms]以上空けてねって意味だね。

フクさん

そのとおり。
結果のログは以下。

Begin Triggerblock
 0.000000 Start of measurement
 0.000000 1  18DA10F1x       Rx   d 8 10 1E 01 02 03 04 05 06
 0.001622 1  18DAF110x       Rx   d 8 30 00 0A CC CC CC CC CC
 0.013967 1  18DA10F1x       Rx   d 8 21 07 08 09 10 01 02 03
 0.024928 1  18DA10F1x       Rx   d 8 22 04 05 06 07 08 09 10
 0.037134 1  18DA10F1x       Rx   d 8 23 01 02 03 04 05 06 07
 0.049070 1  18DA10F1x       Rx   d 4 24 08 09 10
End TriggerBlock

太郎くん

うん。
10[ms]以上空いてるね。

太郎くん

んー、でも

「10[ms]以上」というか「11[ms]以上」って感じの空き方だね。

フクさん

まぁcan-isotpの下層にあるpython-canの応答性の問題や、
そもそも本当に「11[ms]以上」でハンドリングしてる可能性もあるね。

太郎くん

え？
「10[ms]以上」が指定なのに「11[ms]以上」でハンドリングってありなの？

フクさん

うん。
通信関連の仕様と実装の関係性としてよくあるパターンだね。
下手に10[ms]ぴったりを狙うと自分は10[ms]なんだけど、通信相手からすると実はギリギリ10[ms]に届いていないと認識されるパターンがある。

太郎くん

え？なんで？
相対性理論的な話？

フクさん

相対性理論は関係ないな。
単純に異なるシステム間だから時間のカウントの開始タイミングとか精度が合ってない可能性高いんだよ。
だから、下手に10[ms]狙うよりかは、確実に10[ms]以上である、11[ms]を狙う方が安全ってことになる。

太郎くん

なるほど！
確かに仕様上は10[ms]以上だから、10[ms]未満になってしまう事態だけは避けたいもんね。

フクさん

ちょっと余談になるけど、
リアルタイムOSとかの時間指定型のタスクWAITING状態のAPIなんかも似たような発想になってるね。
ITRON系OSのAPIだとdly_tskってあるんだけど、
dly_tsk(1)は「1[ms]以上待つ」なんで、実際には「1[ms]～2[ms]待つ」って振る舞いになるね。
まぁOS内部の時間精度次第な部分もあるけど。

太郎くん

確かに時間の流れって割と絶対的なものだけど、
本当の意味で同一に管理するってものできないから、

こういう幅みたいなのが必要なんだねー。

まとめ

フクさん

まとめだよ。

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

バックナンバーはこちら。