バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回は、ついにAUTOSAR-XCPでSTIMを実現。
想定よりも良い結果が得られた。
が、フクさん的に一点気になることがあるらしい。
今回はそこの気になる点について。
登場人物
博識フクロウのフクさん
イラスト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
AUTOSAR-XCPのSTIMの気になる点
前回の最後の方で、「なんか気になることがある。」
ってことを言ってたけど、結局何があるの？
うむ。
XCPスレーブがSTIMパケットを受信した際の応答についてだな。
そういえば、前回のCAN回線ログを見た感じだとなんかXCPスレーブから応答してたような？
うん。
とりあえず前回のCAN回線ログを見てみよう。
0.762839 1 1 Rx d 5 01 11 22 33 44 # STIMパケット
0.767271 1 2 Rx d 1 FF # STIMパケットに対してのRes確かにSTIMに対してレスポンスしてる動きだよね。
フクさんの所感
あくまで私の所感になるのだが、
XCPのSTIMってCTOではなくDTOなんだよね。
DTOということからCTO由来のRESパケットは発行しないって認識でいた。
CTOパケットについてはここ参照
DTOパケットについてはここ参照
つまり、
CMDはCTOでRESもCTOだから辻褄はあってそうだけど、
STIMはDTOに対してRESはCTOだから、なんか変じゃない？
ってこと？
端的に言うとそうだね。
これはフクさんが間違っているのか
AUTOSAR-XCPが間違っているのか・・・。
両方正しいってパターンもあり得るね。
そうなの？
ASAM仕様、AUTOSAR仕様を漁ってみた。
一応ASAM仕様とAUTOSAR仕様を双方確認してみたが、
STIMに対してRESを返すかについて記載はされていなかった。
強いて上げるならば、RESはCMDに対してのResponseパケットである旨ASAM仕様に書いてあったくらいかな。
と、すると、AUTOSAR-XCPが間違ってる？
さっきも言ったがどっちかが間違っているとかではないのだと思う。
というと？
ASAM仕様は欧州での計測ツールのデファクトスタンダートを、明示的にスタンダードにしたものだ。
よって、暗黙的に「こうあるべき」って仕様が隠れている可能性がある。
うーん、
具体的にどういうことかを言ってもらえるともう少し意味が分かるかもしれないけど・・・。
STIMに対するRESの考え方(あくまで推測)
とりあえず私の推測を書いておこう。
RESが有っても無くても、仕様ミスにはならないと思われる。
ただ、STIMのフレーム構成間違いや、存在しないODT entryへの書き込みを想定すると
RESパケット発行の方が、より正しい。
以下3パターンが考えられる。
- RES応答なし。(本来のDTOパケットの性質。性能重視)
- RES応答を必ずする。(エラーハンドリング重視)
- ERR応答だけする。(上記の折衷案)
ここら辺の仕様はメーカ、サプライヤの方針によって変わる可能性が高い。
ここらへんの仕様が曖昧なのは仕方のないことなのかな。
STIM自体もそうそう使われるシーンが少ないんで、
なおさら議題にも上がらないんだろう。
とりあえず、仕様として特殊なパターンがあり得るから気を付けておこう。
ソースコードとか
AUTOSAR-XCPのソースコードをGithubに上げておこう。
使用したPyXCPによるPythonコードはJupyterNotebookとしてある。
AUTOSAR-XCP ソースコード
PyXCPによるPythonコード
まとめ
まとめだよ。
- AUTOSAR-XCPのSTIMの気になる点がある。
- STIMパケットに対してRESパケットが発行されている点。
- 仕様書上は、RESパケット応答に関する振る舞いは明記されていなかった。
- 恐らくデファクトスタンダード的な仕様が紛れている。
- 上記は何が正しいというのは恐らくない。
- こういうものがあるということに気を付ける。
バックナンバーはこちら。
コメント