バックナンバーはこちら
https://www.simulationroom999.com/blog/model-based-of-minimum-backnumber/
はじめに
インターフェースがいきなりCANに変更になるという大惨事。
まずは同等の環境を作るためVector社のCANoeを手配。
登場人物
博識フクロウのフクさん
イラスト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
CANoe手配完了
よし。
インストールも終わってライセンスのアクティベートもできたぞ。
お疲れ。
で、どんな感じで環境を作るの？
構成概要
以下の構成を考えている。
おー。
各信号のやり取りを本当にCANに置き換えた感じだね。
これをノードという形で表現しなおすと以下の感じ。
え？
これだと、信号が混線しない？！
CANのネットワーク構成はマルチマスタと呼ばれて
ネットワーク上の全ノードに信号が届くんだ。
ただし、受信側はCANIDで必要な情報だけフィルタして取得する。
そして、各CANフレームは衝突しないような仕組みがあるので、
概念上は混線したり、フレームが破壊されることはない。
ノード表現はあくまで物理的な構成を示しているだけで、
論理上の接続はその前の絵になるってことであってる？
その認識で良いよ。
必要な情報
概要は分かったけど、
他に必要なものってあるの？
まぁCANを使うことろから本来であれば以下の情報が必要。
- CANID
- CANフレーム内のシグナルレイアウト
- シグナルbit長、ByteOrder、符号有無
- シグナルのbit/scale
- それぞれのCANID毎の送信周期
んー。
これは分からないなー。
確認しておくよ。
では、今回は仮で以下としておこう。
| シグナル | CANID | 符号 | ByteOrder | Bit/Scale | 備考 |
|---|---|---|---|---|---|
| 速度指令 | 0x111 | unsigned | Motorola | \(1[km/h]\) | |
| 実車速 | 0x222 | unsigned | Motorola | \(0.01[km/h]\) | |
| アクセル開度 | 0x333 | unsigned | Motorola | \(2^{-15}\) | 1.0で全開 |
レイアウトは全部前詰め、
送信周期は一律で\(10[ms]\)にしておこう。
いろいろ決めないといけないことが多いんだねー。
まぁそうなんだけど、電圧、ADC/DAC、制御としての物理値変換を考えると
余り変わらないか、むしろ楽かもしれないよ。
言われてみると確かにそんな気がしてくる。
これで以下が決まったことになる。
- ノード構成
- 各ノードの送信CANID
- 各CANフレームのシグナルレイアウト
- 各シグナルのデータ長、符号などの物理変換情報
これで動かせる準備ができたってことで良い？
まだだよ。
えー。
なんかもっとサクサクっと行けると思ってたんだけど。
上記の決まったことをもとにdbcというネットワーク構成を定義するファイルを作成する必要がある。
意外と、ツールを使う敷居の高さを感じるんだけど・・・。
まぁ世の中一般的なソフトウェアと比べると前準備は多いかもね。
でも、ここでしっかり定義しておくと、あとがすごく楽できるから。
そうだね。
Simulinkの時もそうだったけど、
喰わず嫌いは良くないよね。
というわけで次回はネットワーク構成定義ファイルことdbcを作成する。
まとめ
まとめだよ。
- CANはマルチマスタなネットワーク。
- しかし概念上は個別の信号線を模しているだけ。
- CANをうまく利用するためにはネットワーク構成を明確にする必要がある。
- ノード、CANID、シグナル。
バックナンバーはこちら
コメント