KEI

dbcファイルが出来上がったのでCANoeのデータベースインポートウィザードを使ってみた。 dbcを読み込むことでdbc内で定義されているネットワークノードをCANoeに割り当てることが可能。 生成されたノードはdbcで定義されたCANメッセージを同じく定義された送信周期で送信可能。 CANoe.IL機能の一端。

CANdb++エディターで各種定義を実施。 シグナル、メッセージ、ノードの順番で定義していく。 メッセージの周期時間は送信周期を示す。 単位は[ms]。 属性の「GenMsgCycleTime」パラメータを修正することで変更可能。 CANoe.IL機能を使用する時に生きてくるパラメータ。

dbcファイルについて簡単に説明。 CANメッセージとそれに載せるシグナルだけでなく、ネットワークノードの定義もできる。 ネットワークノードを定義しておくと、CANoeのインポートウィザードでノードの自動生成をしてくれる。 dbcファイルを作成開始。 CANeb++エディターを使用。 プロトコルの設定まで実施。

CANoeでFMU import＆動作実験の全体構成提示。 恒例のネットワーク構成と論理構成。 FMU間の各信号の接続はCAN経由で行う。 実は以前SimulinkDLLをCANoeで駆動させた時と近似の構成。 SimulinkDLLの代わりにFMUになっただけ。

CANoeの仮想HILS化への実験ロードマップ提示。 大雑把にはFMU importとXCPマスタの2つ。 FMU importの実験をやってからXCPマスタの実験の流れ。 最初はXCPを使用せずにCANoeのシミュレーションバスを使用したFMU間連携をさせてみる。

CANoeで仮想HILSの実現が可能かを検討する間に現行の仮想HILSの機能を列挙した。 FMU import＆実行。 たぶんOK。でも要確認 各種信号のグラフ表示＆CAN受信。 間違い無くできる。 XCPマスタ 本当のXCPをするなら追加ライセンスが必要。 しかし、CAPLを駆使すれば今回の目的は達成できそう。

仮想HILSと仮想ECUの精度が上がらなかった原因を予測。 ほぼ間違いなく応答性が原因。 Pythonではこれ以上の応答性は得られそうもない。 Pythonに変わって仮想HILS側をVector社のCANoeにしたらどうかという意見あり。 本物のHILSと比べ、コスパも良さそう。