モデルベース開発

xcp_canクラスのCAN-FDに関係する部分を確認。 要はPyXCPをCAN-FD対応にする部分。 コンフィグレーションのJSON記述を修正すればOKっぽい。 ソースコードからのリバースエンジニアリングによる調査結果。 本当合ってるか不安なのでJupyterNoteBookで動作確認を先に実施予定。

指令器の修正範囲を確認。 CANがCAN-FDに変えることから逆算して特定。 バス初期化とメッセージ構築の部分。 バス初期化はCAN-FD有効化とDataRateの設定。 メッセージ構築はCAN-FD化とbitrate_switch有効。 bitrate_switch無効でもOKだがbitrateは切り替わらない。

仮想ECU側のPID制御の入出力定義はポインタで実施。 元々が符号付き16bit変数へのポインタだったのでこれを符号付き32bit長変数に差し替え。 上記に伴い、参照先のアドレス境界を16bitから32bitに切替。 PID制御器の入力はfloat64で、参照変数が16bitか32bitかは気にしなくてもOKなコード。

AUTOSAR-XCPのパケット長変更を実施。 MAX_CTOとMAX_DTOを8から64に変更すればOK。 CTO、DTOについては過去記事で復習。 念のためCANFD_SUPPORTで#ifdefで切り分けられるようにしておく。

AUTOSAR-XCPのCAN-FD対応に向けての方針を決める。 CanIf相当の部分とXCPのパケット長のところを修正する必要あり。 といってもCanIf相当の部分は実はすでにCAN-FD対応済み CAN-FD対応の際はDLCの仕様の特殊さに注意する必要がある。 8以下の時と8を超えた時で雰囲気が変わる。

XCPonCAN-FDに対応すべく現状の仮想ECU、仮想HILS構成を再確認。 CANのところをCAN-FD化。 XCP経由で変数のやり取りをしている部分を32bit化。 改造方針と同時に動作確認手段も模索する必要あり。 python-can、PyXCPを駆使すればなんとかなりそうという当たりだけ付けた。

XCPonCANとしての課題を明確化。 CANのデータフィールド8byteの仕様がODTの限界値を決めていた。 よって、データフィールドが長くなれば解決と言える。 CANのデータフィールドの上限が8byteに対し、CAN-FDは64byte。 よって、4byte、3変数が載っても十分な長さ。