バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はCANoeのシグナルジェネレータを使用して、指令器を作成。
指令値はdbcファイルで定義したTargetシグナルに対して載せることができ、
これはCANoe.IL機能の恩恵である。
FMU側を再exportせずとも指令値を作れるので実験を簡単に回せる状態になったと言える。
というわけで今回からCAPLによるFMUとCANシグナルの紐づけの話となる。
登場人物
博識フクロウのフクさん
イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1
エンジニア歴8年の太郎くん
イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1
FMUとCANシグナルの紐づけ
次こそはCAPLを弄る感じだな。
そうだね。
FMUの入出力がシステム変数経由でアクセスできるけど、
それがシグナルに乗るわけではないので、そこの調整をCAPLで行う必要がある。
雰囲気的にはそれほどややこしいことはしないとおもってはいるのだけど？
そうだねー。
イベントハンドラさえしっかりしてれば、
一個一個の関数は1行2行になると思うよ。
イベントハンドラ？
イベントハンドラ？
って何だっけ？
名前の通りでイベントが起きた時に処理される関数だね。
代表的なイベントは以下だ。
- シミュレーション開始イベント
- タイマイベント
- CAN受信イベント
- シグナル更新イベント
今回は特に以下を駆使する。
・タイマイベント
・シグナル更新イベント
まぁタイマイベントを発生させるために
・シミュレーション開始イベント
も使うんだけどね。
CAPLコード構成
で、構成としてはどうなるのかな？
CANoeでのCAPLって確かネットワークノードに割り当てられるんだよね？
その通り。
各ネットワークノード毎にCAPLを設定できるんで、
どこのノードに何を記述するか。
ってのが重要になってくる。
前回、指令器に関してはシグナルジェネレータで解決させているので、
残りの制御器とプラントに対してのCAPLが必要となる。
FMUの入出力がシステム変数に割り当てられてるから、
制御器ノードで制御器用FMUの入出力、
プラントノードでプラント用FMUの入出力
をCANのシグナルに載せ直すって感じか。
その認識でおおよそOKだが、
CANoe.IL機能のおかげで恐らくはCANの意識は不要で、
シグナルだけを意識すればOKになると思うよ。
シグナルだけを意識かー。
ちょっとイメージ湧かないなー。
ここらへんは実際にコードを見た方が早いかもしれない。
次回までにCAPLコードを仕上げてこよう。
まとめ
まとめだよ。
- FMUとCANシグナルの紐づけのためついにCAPLに手を付け始める。
- CAPLではイベントハンドラを使うことが多い。
- イベントはおおよそ以下。
- シミュレーション開始。
- タイマ。
- CAN受信。
- シグナル更新。
- イベントはおおよそ以下。
- ネットワークノード毎にCAPLを設定できるので、ノードの役割を意識する必要がある。
バックナンバーはこちら。
コメント