【上流検証】最小構成のモデルベース開発事例 その38【Bypass④】

DTOパケット構成なんだけど、地味にバリエーションが多い。

うんにゃ。構成が多い。

そこが共通じゃないんで厄介。
XCPの仕様で最初につまづくのかここら辺なんじゃないかなって思ってる。

とりあえず、どういったバリエーションがあるか言ってくよ。

DTOパケットは大きく4パターン。
①絶対PID (1byte構成)
②相対PID_BYTE (2byte構成)
③相対PID_WORD (3byte構成)
④相対PID_WORD_ALIGNED (4byte構成)

ここはDAQ、ODT(Object Descriptor Table)とODT entryの概念を把握しないと理解できないと思う。
とりあえず、たぶん今回はこれだろうと思われる④のパターンを張っておく。

今回はXCPの実装をするわけではなく、

ツールに設定するのに必要な知識を得るのが目的なので、
まずは4パターンあるよってだけ覚えておいて。

そして、

TimeStampフィールドも4種類あって、

前述の4パターンとは非依存に定義されている。

仕様上はそうなるね。
実際は2パターンくらい収まるとは思うけど。

TimeStampフィールドのパターンは至ってシンプルで以下。

• なし
• BYTE
• WORD
• DWORD

DAQリストが複数のフレームに分かれることが、あり得るんだけど、
複数のフレームに分かれたとしても、ECU内のデータ取得タイミングは同一なんだ。
ツール側はこのTimeStampフィールドを見て、前回取得したデータの時間差や周期の判定に使う。

ツールの仕様依存ではあるが、
たぶん、DAQリストの先頭フレームを受信したタイミングを起点にするんじゃないかな。

使用する回線依存だったり、

ECUの実装難度を下げる目的だったりするかな。

たとえば、CANの場合、1フレームのデータフィールドが8byteしかない。
8byteしかない中で、データと関係ない情報が4byte以上あったらどうなる？

そういうこと。
Ethernetの場合は１フレームが1500byteくらいあるので、4byteや8byte使ってもそれほど影響はない。
よって、全部ありありな仕様を選択することが多い。

ただ、昨今だと、CANの上位仕様のCAN-FDっての出てきて、

これがデータフィールドが最大で64byteなんだ。
64byteだとどう転ぶかはちょっと予測できなくて、

結構使われて無かった微妙なパターンが出てくるかも。

まぁ今回はEthernetってことで全部ありありパターンと予測している。

そうだね。
TCPとUDPのどちらを使うのかってものあるし。

大きく変わる部分としてはセッションの確立のさせかたが変るかな。
UDPだと、明示的にCONNECT、DISCONNECTというコマンドでセッション制御するが、
TCPの場合はTCPとしてのセッションを確立する。という違いがある。
まぁ絶対とは言えないけど、UDPであることの方が多いかな？
他の物理層があまりTCPっぽいのが無いし、実装形態を合わせようと思うとUDPになり易い。

まとめだよ。

• DTOパケットのパターンは4パターン。
• TimeStampフィールドのパターンも4パターン。
• 使用する物理層で使用できるデータ領域に依存しておおよそ2パターンに集約される。
  • 最小構成版と最大構成版の2パターン。
  • しかし、CAN-FDの台頭に伴い、中間のパターンが乱立する可能性あり。