バックナンバーはこちら
https://www.simulationroom999.com/blog/model-based-of-minimum-backnumber/
はじめに
前回は仕様書の物理構成の必要性について学んだ太郎くん。
ここからソフトウェアの仕様に入っていく。
登場人物
博識フクロウのフクさん
イラスト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
制御側の論理構成
いよいよソフトウェア側の話に突入だね。
そーだね。
まずは太郎くんのイメージを言ってみて。
うん。
- ADCでGPS車速電圧とAP開度電圧取得
- AP開度電圧が一定値を超えたら制御開始
- 制御開始になったら目標値と車速の差が無くなるよう、PID制御でDACでAP開度電圧を出力
って感じかな。
まぁシンプルで分かり易いが、ちょっと問題があるかな。
え？
どんな問題？
太郎くんの想定でも、きっと動作するものは完成するだろう。
しかし、
終始電圧としてデータを扱っているので、
今後を見越した拡張の話になった際に再設計になるんじゃないかな？
あー、
そういえば、
「まずはクルーズコントロール相当」って話だったから、
今後は細かい制御が入ってる可能性は高いかも。
でも、
AP開度もGPS車速も電圧なんだから電圧としか言いようが無いと思うんだけど？
AP開度の単位は\([\%]\)、車速の単位は\([km/h]\)なんじゃない？
あー、わかった！
電圧から実際の物理値に変換した方が良いってことだね？
そういうこと。
今回の装置に特化した仕様から移植性を意識すると共通認識し易い物理値に変換しておいた方が良い。
これだと、装置が変っても移植できるし、Simulink等でシミュレ―ションする際も実際の物理値で計算できるので、あまり悩まなくて済む。
確かに、
移植やシミュレーションする場合は、
装置特化の概念は入れ込みたくないもんね。
物理値変換を加味してちょっと絵を書いてみたよ。
AP開度が2系統あるのは省略してあるけど。
いいんじゃないかな。
これだと制御のところは電圧という概念ではなく、
純粋に車速とAP開度として演算できるね。
うん。
検証する際も物理変換部と制御部に分けてできそうだし、
制御部は事前に環境非依存のシミュレーションできそう。
制御対象側の論理構成
あ！
ふと思ったんだけど。
どうしたの？
これって、疑似的な車両とGPS車速の出力装置に転用できないかな？
車両の方もAP開度を電圧で受けて、
車速がGPS車速という電圧でとってるから、
同じAPコントローラと同じインターフェースだよね？
なるほど！
つまり、
同じ装置で簡易的なHILSができそうって話だね？
そうそう。
でも、
車両の振る舞いとかわからないし、
無理かなー。
そこは私に案があるから、
論理構成だけでも書き出してみたら？
うん。書いてみる。
こんなイメージでいるんだけど。
そして、論理モデルレベルだとこのイメージ。
うん。いいと思うよ。
制御対象の詳細は後で詰めるとして、
それ以外のところはAPコントローラの仕様がそのまま利用できているね。
委託先の工数とかはまだ把握していないけど、
これも仕様に含めていいか確認してみるよ。
うむ。
こういうのは早期の検証にも使えて、
品質保証リスクを下げられるんで、
そこも含めて伝えると良いと思うよ。
じゃあ、
ちょっと調整するんで、
続きは次回ってことで！
(むぅ。最近やたらと仕切りやがる)
まとめ
まとめだよ。
- 論理構成を考える際は物理値変換部と制御に分けた方が良い。
- 物理的な制約と仕様の切り離しができ、移植性とシミュレーション可能性が引きあがる効果がある。
- 早期検証を考えることで品質保証リスクを下げる仕掛けを考えておくとよい。
- 当然、関係者との調整は必要になる。
- よって、説得材料等もそろえておいた方が良い。
バックナンバーはこちら
コメント