組込みソフトウェアは一般のソフトウェアよりもモデリングが難しい
組込みソフトウェアの開発者であれば、程度の差はあれ誰もが同意できる夢があると思います。ハードウェア構成や制御方式の変更に振り回されないようにしたい。もっと楽に追加や変更を行うことができて、しかも障害が発生しにくい開発体制を確立したい。
その夢を叶えるためのツールとしてモデリングはとても有効です。複雑な現実を整理し、多くの人が理解できる形で共有し、その知見を再利用するという考え方が、組込みソフトウェア開発でも正しく定着すれば、厳しい開発現場の改善が実現できるはずです。
ただし、現実にはそれが十分に達成されているとは言えません。その理由はいくつか考えられますが、端的に言えば抽象的・概念的な設計よりも目の前で実際に動く実装の方が尊重されるからでしょう。とはいえ、そうせざるを得ない理由があることも事実です。
一般的なソフトウェアと違って組込みソフトウェアは自然現象に大きく影響される傾向があります。例えば、自動車のブレーキを制御するABSは、運転手がペダルを踏む強さだけでなく、路面の滑りやすさや凸凹などの情報を総合的に勘案して、ディスクの油圧を調整しています。このような自然現象は机上の設計で十分に想定しつくすことが困難です。
そこへ来てコストの問題もあります。例えば、ABSの設計者は路面状況を検知するためのセンサーを望むでしょうが、そうやって必要なリソースを逐一積んでいくと車の価格が跳ね上がってしまう。製品の構成要素として設計される組込みソフトウェアは、コストなどとの兼ね合いから利用可能なリソースが常に限定されています。ABSの場合も、車輪の回転速度を測るセンサーの情報を基に路面状況などを推量します。
「予測困難な自然現象」を「限られたリソース」で制御する組込みソフトウェアの世界では、教科書に書かれた理論どおりに設計しても目的は達成されませんし、必要なデータを直接的に取得できない場合が多い。だから、「係数を調整したら挙動が安定した」「この機器の値を使えばセンサーの代わりになりそうだ」など、現場レベルで試行錯誤を重ね、その過程で得られた実践ノウハウを取り込むことが必要不可欠なのです。「理論的に正しい設計」よりも「実際に動くもの」が尊重されることはやむを得ないことでしょう。
結果として、組込みソフトウェアにおけるモデル図は単純に実装を引き写しただけのものになりがちですが、それらを見てもどのように機能が実現されているかという理屈はわかりません。「ただ単にそうなっている」という現状追認の図では、ハードウェアに縛られず、追加や変更を容易に行なうという“夢”の実現もまた難しいと言わざるを得ません。そして、まさにこれこそが、組込みソフトウェアをモデリングする難しさと言えます。
