モデルベース開発

CANoeが32bitFMUを要求する理由の調査結果。 CANoe内に２つのアプリケーションが動作しているもよう。 描画担当で64bitプロセス。 計測/演算担当の32bitプロセス。 FMUは計測/演算担当のプロセス側が読み込んでるっぽい。 CANoeの内部構成についていろいろ考察したので次回説明予定。

ついにCANoe上でFMUを動作させる実験を開始・・・したが・・・。 謎エラー発生。 32bitアプリケーションから呼ばれるFMUの場合はwin32向けFMUである必要がある。 しかし、今回使用しているCANoeは64bitアプリケーションのため辻褄が合わない。 なぜこのようなことになっているか要調査。

仮想HILS向けCAPLコード公開。 イベントハンドラは関数先頭に「on」が付く。 その後ろに以下が続く。 start：シミュレーション開始。 timer：タイマ。 signal：シグナル更新。 CAPLのコツはシンプルに書く。 複雑な処理はライブラリに逃がすなどがコツ。

FMUとCANシグナルの紐づけのためついにCAPLに手を付け始める。 CAPLではイベントハンドラを使うことが多い。 イベントはおおよそ以下。 シミュレーション開始。 タイマ。 CAN受信。 シグナル更新。 ネットワークノード毎にCAPLを設定できるので、ノードの役割を意識する必要がある。

FMUの中に指令器もあったが、CANoeから指令値を変えられた方が便利なのでシグナルジェネレータ機能を使用する方針となる。 dbcファイルで定義したシグナルに対して自由は波形を載せることが可能な機能。 シグナルジェネレータで台形波を作成しTargetシグナルとして出力できるように設定。 さまざまは波形を設定可能。

CANoe.IL機能でシグナルを簡単に叩けるようにはなったが、FMUとの接続が無いとCAPLを実装してもイマイチ。というわけでFMUインポートから実施。FMUインポートの手順確認。最終的にはCANoeシステム変数と紐づいて、そのシステム変数を読み書きすることで結果としてFMUのInput、Outputにアクセスできる。

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になっただけ。