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

写真拡大

■巨大化する制御プログラム

 自動車産業において現在では常識ともいえる「モデルベース開発(MBD)」の有効性は、「自動運転車開発」には欠かせないものと言ってよいだろう。この点について、「日本企業は遅れている」「現場・現物主義など時代遅れだ」と叫ぶように記述している専門家が存在するようだ。結論から言えば、「モデルベース開発」は必要不可欠な「ツール」と言えるが、現場・現物主義を否定することにはならない。つまり、「モデルベース開発(MBD)」は全てを検査できるものではなく、「最終的には現物で確かめることは必須」であり、「正確に作るのは現場の作業」なのだ。

【こちらも】【AT車のエンストを甘く見るな(上)】整備士に分からない故障「制御プログラム」

 クルマの電子制御は年々「巨大化」していると、あえて表現する。クルマの制御が、部品ごとにその関連性が求められ、ついにはネットを介して全世界とつながるシステムに拡大しつつある。その巨大化の中で、制御プログラムの開発が追いつかない問題がある。「バグ(プログラムの間違い)」「ハッキング」は、現状では避けられない危険だ。その制御プログラム開発を効率化しないと、人類は完全自動運転まで到達できないと見積もられている。つまり、「モデルベース開発」のシミュレーション機能を使わない限り、シミュレーション回数をこなせないということのようだ。

■そもそもコンピュータは0と1しか分からない

 コンピュータは0と1しか分からないことはご存知であろう。機械(マシン)語は0と1なのだ。だからどのような開発言語を使っても、最終的には0と1に翻訳されている。プログラム言語は、人間が分かりやすい言語に置き換えて開発され、プログラムによって機械語に翻訳しているのだ。コンパイル言語とは翻訳プログラムなのだ。

 私がプログラム開発していたころ、「アセンブラ」と呼ばれる機械語に近い言語が使われていた。その後、もっと人間の言葉、つまり英語に近い記号であらわした「コンパイル言語」が開発され、プログラムが簡単になり、開発時間も短縮されてきた。C言語は、元はコンパイル言語の中では機械語を制御できる部分があり、機械を制御するプログラム開発に向いた言語だ。

 しかし、デバッグ(試験)をしていると、どうしても機械語そのものを理解することが部分的には必要となってしまう。それでは開発は進まなくなる。半世紀ほど前のことだが、0と1の羅列されたリストを見て、プログラムを進められるベテランプログラマーの姿があった。彼らは本当に機械語を理解していた。でもそのプログラムの規模はきわめて小さなもので、機械語では、手数がかかりすぎて大きなシステムは組めなかったのだ。

 45年ほど前だったか、NC工作機械の導入責任者となったとき、制御コンピュータを起動するときのことを思い出す。現在のパソコンと比較すると、その手数の多さは考えられないほどだった。まず、電源を入れてもコンピュータは何の反応も示さない。最初は機械的にスイッチを使ってプログラムを入力する。I/Oを理解できるプログラムだけをボタンを使って入力する。その後、パンチカードテープを使って、アプリケーション・プログラム部分を読み込ませる。これで部品ごとのデータプログラムを読めるようになる。

 しかし、これでも刃先の基準点は出ていない。刃物をセットして基準点を出し、ようやく刃物の軌跡が追えるようになる。それでも誤りがあると、材料との刃物の衝突の懸念が残る。実際に幾度か衝突をした。こんな機械で自動化を進めてきたのだった。

 もちろん、「モデルベース開発」のようにシミュレーションなんてできない。頭の中と図面上だけでデバッグしていた。危険極まりない状態だった。実際に高速で回転する材料と刃物との衝突が起きることをさけられなかった。また余談だが、そのころのMM(メインメモリー)は「磁気コア」だった。1ビットが目に見える状態だった。