バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO14229ことUDSの話。
今回はセッション層のタイムアウトパラメータの図解説明。
登場人物
博識フクロウのフクさん
イラスト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
P2時間の図解説明
じゃー約束の物を出してもらおうか。
(うーん、なんでこう偉そうなんだ？)
P2時間をざっと絵にするとこんなんだよ。
おー。
確かに
「リクエストメッセージ送信後のレスポンスメッセージを受信するまでのタイムアウト時間」
だ。
だから、そう言ったじゃん。
いやー、メッセージの終わりってちょっとイメージ湧かなかったけど、
冷静に考えると、
リクエストメッセージのSFか最後のCFってことになって、
次のメッセージはレスポンスメッセージのSFかFFになるんだよね。
そこのイメージが湧いてなかった。
まぁ理解できたようでなによりだよ。
ちなみにP2*タイムアウトってのもあるんだけど、
これは追々だな。
(なんかサラッと不吉なこといったぞ)
S3時間について図解説明
次はS3時間。
なんかセッションという概念があって、
S3時間立つと強制的にデフォルトセッションってのに戻るんだっけ？
具体的にはどこのタイムアウトかイメージ湧いてないけど。
絵で描くとこうなるよ。
お、これは・・・。
リクエストメッセージとレスポンスメッセージの外側のタイムアウト？
うん。
その認識はいい線いってるよ。
レスポンスメッセージを返した後に、
S3時間内にリクエストメッセージを送らないといけないのか。
なんでこういう風になってるの？
これはセッションの概念を理解しないとわからないと思うのだけど。
例えば、
車両に対して強制的にデバッグ動作さえるような機能があったとしよう。
特殊且つ悪用できるので、通常では使わせたくない。
よって、特殊な通信をした上で特定のセッションの時のみ使用可能にできるようする。
しかし、その機能がずっと有効だと困る。
有効にした人がちゃんと戻してくれれば良いけど、人為的なミスは起きることが普通。
ならば、一定時間通信が無ければ強制的にデバッグ動作を無効にできれば良い。
ってことでS3時間というのが設けられた。
おー。
なるほど。
強制的なデバッグ動作が何者かはわからないけど、
特殊なモードが自動で解除されるなら変な事故は起こらないってことか。
うん。
現時点ではその認識でOKだ。
セッションについて図解説明
次にセッションについてだけど、
これは正直分からなくても仕方ないかなーって感じがする。
え？図解でもダメなの？
うん。
そもそも
「セッション制御サービスでセッションを切り替えることでサポートするサービスが変わる。」
と言われても
- セッション制御サービスって？
- サポートするサービスって？
ってなると思うんだよね。
そっちを先に説明してもらえれば分かるかも。
各サービスはISO14229-1ことアプリ―ケーション層の話で、
結構なボリュームがあるからねー。
じゃー、とりあえず後回しって感じかな。
そーだねー。
まとめ
まとめだよ。
- P2時間について図解説明。
- P2*タイムアウトは追々説明。
- S3時間について図解説明。
- セッションについては追々説明。
- 各種サービスを知らないと難しい。
バックナンバーはこちら。
コメント