バックナンバーはこちら
https://www.simulationroom999.com/blog/model-based-of-minimum-backnumber/
はじめに
前回はMicroAutoBoxで使用されているSimulinkモデルの主要ロジックだけを抜き出して単体テストをしてみた。
シミュレーションした結果、想定される振る舞いであった。
今回は、多回線出力の問題について取り扱う。
登場人物
博識フクロウのフクさん
イラスト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
ネットワークMILSと一緒？
前回からの流れで今回のやることを予想すると、
ネットワークMILSのシリーズでやったCANoeI/OブロックをつないでSimulinkDLLを作成するってことになるのかな？
いいね。
まさしくその通り。
ん？
とすると今回はあんまり新しい話は出てこない感じ？
むしろSimulinkDLL作成については飛ばして、
例の多回線出力の対策の話がメインになる。
ちょっとややこしんで、
概念的な話で終わってしまうと思うけど。
多回線化の方法
あー、そういえばそうだった。
モデルの出力を２つのCANにそれぞれ\(10[ms]\)周期、\(100[ms]\)周期で出力するんだった。
でも、これって、
CANoeI/OのSignal Outputブロックを二つ繋げばOKとか言ってなかったっけ？
うん。それでも良いよ。
”それでも”ってことは別の方法があるの？
うん。
CANoe自体にCANのシグナル定義とは別にシステム変数というものを独自に定義できるんだ。
システム変数自体は特にどこかに出力されるわけではないのだけど、
CANoe内でプログラミングするCAPLという言語で読み書きができる。
あー、CAPLはネットワークMILSの時にも話には出たね。
テスト自動化する時に利用すると良いとかなんとか。
うん。
テスト自動化以外に、
今回のようなちょっとした信号の伝達の調整に使用することも多い。
なんとなくわかってきたぞ！
バッファとしてシステム変数を定義して、
SimulinkDLLからシステム変数に一旦出力。
それをCAPLで読み出して、それぞれの回線のシグナルにコピーする感じか！
正解。
一つのノードに二つのインターフェース
ここで一つ問題がある。
どんな？
SimulinkDLLはCANoe上で定義したノードと一対になる。
ノードは回線毎に定義される。
普通にやると1ノードが複数の回線を制御することはできない。
え？じゃあ2回線出力ができないんじゃない？
そこでゲートウェイノードというのを設置する。
ほう？
まぁそんなに難しい話では無く、
dbcで回線毎のノード定義をする際に、ノード名を同一にしておけば、自動的にゲートウェイノードとして認識される。
以下の感じになる。
ということは、
このゲートウェイノードってのは複数の回線のシグナルにアクセスできると思って良い？
うん。
よって、SimulinkDLLを割り当てるならば、このゲートウェイノードに割り当てると良い。
ちなみにCAPLもノード毎定義なんで、このゲートウェイノードに信号分配用のCAPLを割り当てることになる。
このノードって概念はややこしいねぇ。
便利な概念なんだろうけど、
どうしても物理的な回線ベースで考えちゃうんで、頭がこんがらがってしまいそう。
具体的な回線に対して、抽象的なものだからね。
こればっかりは慣れるしかないね。
まとめ
まとめだよ。
- SimulinkDLLの出力を2つのシグナルに渡すには2つの手法がある。
- Signal Outputブロックを2つ使用。
システム変数に書き込んでからCAPLで各シグナルへ分配。
- Signal Outputブロックを2つ使用。
- 複数の回線のシグナルを扱うにはゲートウェイノードを定義する必要がある。
- SimulinkDLL、CAPLのどっちを使うにしても同様の対応が必要。
バックナンバーはこちら
コメント