【未知との遭遇は必須(中)】「モデルベース開発」は「開発統合環境」

■「モデルベース開発」は「開発統合環境」

　昔に比べて、コンピュータのソフトは巨大になった。半世紀前とはくらべものにもならない。プログラム開発言語も進歩を続け、C言語もマクロになり、デバッグ環境も開発が進み、コンピュータ上でシミュレーションできる範囲は広がり続けている。その延長線上に「モデルベース開発」ソフトがあると言える。

【前回は】【未知との遭遇は必須（上）】「モデルベース開発」の落とし穴　巨大化する制御プログラム

C言語ソースコードも自動的に作られ、実物テストもできる環境が作られるようで、人為的間違いを大幅に少なくできる。つまり、それは「設計開発統合環境」であり、アプリケーションソフト領域まで広がっている大きな「マクロ言語」と見ることが出来る。これで制御プログラムの開発期間は大幅に短縮できるであろう。また「バグ（プログラムミス）」の減少が進み、品質は大幅に向上できる見込みがある。

■「モデルベース開発（MDB）」ソフトは、現場・現物主義から解放してはくれない

　しかし、「モデルベース開発（MDB）」ソフトは、クルマ本体のメカニカル部分を作る設計モデルを計算式で示している。つまり、実車と計算式の間に、実際に作る工程があり、加工精度などの多くの問題が立ちはだかっている。実物テストができることから、メカニカル部分まで開発できるように言われているが、実際に走るメカニカルの部分の「製造」には、直接に関与はできない。だから誤解のないようにしてほしい。計算式で表現できる範囲でシミュレーションできるので、製造を知らない人は全てがコンピュータ上で出来てしまうと誤解している。たとえ制御プログラムは実機でテストできても、設計通りに実機が出来ているとは限らない。

　1例を簡単に言えば、モデルと実物の間に「公差」が必要であり、モデル開発では問題が出ない「公差」の蓄積も起きる。実際のメカニズムでは、動く物体には幾分かの隙間が必要だ。その隙間が偏ると大きな誤差となって現れる。それも計算式の中に収められれば、モデルは実車に近づく。それでも製造段階で「公差に収まっているのか？」は疑問だ。先日の「新幹線のフレーム亀裂事故」のように、モデルの計算式に収めきれないような歪みもあるのが通常だ。「モデルベース開発」に頼るようになっても、いつでも「計算式に当てはまらない未知の概念が存在する」と覚悟してかかる必要がある。

　新幹線の台車の亀裂が起きた事故内容を見ると、製造工程での歪の集中や、それによる各工程での仕上がり寸法の「ばらつき」が激しい。その「ばらつき」を計算式であらわせるとすれば、シミュレーションで全ての問題をチェックできて、「現場・現物主義」を必要としない。実際に試作してみる「手間暇を削減する」ことはできるのだが、現物で問題を確認しなくてもよいことにはならない。（記事：kenzoogata・記事一覧を見る）

続きは:【未知との遭遇は必須（下）】「モデルベース開発」AIは万能ではない、現場・現物主義の必然性