事例

再度DAQパケットを確認。 XCPの一連のコマンド含めてCAN回線ログとして取得。 DAQパケットだけ抽出し、タイムスタンプを確認。 狙い通り10ms周期の送信周期になっていた。 ソースコード等はGithubに上げておいた。 Python側はJupyterNotebook形式。

DAQパケット送信周期精度改善の方針を決めた。 時間精度を引き上げるためマルチメディアタイマを使用。 1ms精度の過去実績あり。 Sleepを挟んだWhileループをマルチメディアタイマによる1msコールバックに変更。 これに伴い10ms周期だけでなく、イベントチャンネル3も1ms保証ができる。

DAQパケット送信周期の精度が悪い理由を確認。 イベントチャンネルが15msになってる。 Sleepで10ms周期を作ろうとしているが、実際は15msになってる。 この部分はPC依存な面はある。 上記により小手先の回収ではどうにもならなそう。 一応対策も考えてるので次回確認予定。

XCP Basic PCシミュレーションの問題点は送信周期。 前回のCAN回線ログのDAQパケットだけを抽出し、それのタイムスタンプと元に現状の送信周期を算出。 10[ms]周期で送信されるべきところが15[ms]になっていた。 一応、原因は分かってはいるので、そこらへんを次回確認予定。

実際にSET_MTAとDOWNLOADを使ってRAM値書き換えを実施。 RAM値書き換え前にDAQを起動しておき、RAM値書き換えとDAQパケットの状況をCAN回線モニタして確認。 RAM値書き換えに合わせてDAQパケットの計測データが変化。 おおよそXCP Basicの挙動はOKだが、まだちょっと問題がある。

計測RAM値の変更方法はSET_MTAとDOWNLAOD。 SET_MTAとDOWNLOADの電文確認。 折角なので連続で投げて見る。 ただ、同じ値だと変化が分からない無いのでちょっと書き込みデータを変える。 さらにDAQパケット送出前に書き換えてしまう可能性もあるのでsleep関数を挟む。

START_STOP_SYNCHコマンドを投げて見た。 並行してcan.loggerでCAN回線モニタを実施。 DAQパケットの計測ができた。 タイムスタンプ有効設定をしていたため先頭の方にタイムスタンプが埋まっている。 タイムスタンプの後ろから計測データが続く。 今回は0値が取得されている。

DAQの開始方法は大きく2パターン。 DAQ list毎に個別開始。 開始可能状態にして複数のDAQ listを同時開始。 今回は後者で実施。 START_STOP_DAQ_LISTコマンドで個別開始/停止と開始可能状態の設定できる。 これでDAQの開始条件は揃った状態となる。

SET_DAQ_LIST_MODEコマンドでDAQの計測データ送信ポリシーを設定できる。 TIMESTAMP有無、使用するEvent channel、分周比など。 Event channelと実際の周期はECU側の実装依存。 今回は1:10ms、2:100ms、3:1msとなっている。

DAQ listの構造的な準備はできたので、実際にODT_ENTRYを更新していく。 更新するODT_ENTRYを参照するにはSET_DAQ_PTRを使用する。 実際にODT_ENTRYを更新するにはWRITE_DAQを使用する。 WRITE_DAQ実行後は参照するODT_ENTRYは自動的に一個後ろになる。