そもそも「組込み制御ソフトウェア」の開発では、なぜ、発生した「不具合」を簡単に修正できないのでしょうか。それはまず第一に、どこで「不具合」が起きているか、特定する事が難しいからです。
パソコン上で動作する、ある程度規模の大きいソフトウェアを開発したことのある人であれば、ソフトウェアの「不具合」の原因を見つけることの難しさは、理解できると思います。全て自分で開発していれば、心当たりのある箇所をしらみつぶしに調査してみると、運良く「不具合」の原因を見つける事ができるかもしれません。ベテランの人の中には、「不具合」の原因の発見が得意の人もいるかもしれません。残念ながら、そのような人は多くないのも現実です。さらに、もし多人数でソフトウェアを開発している場合、他の人の作成したソフトウェアも調査する必要も出てきます。仮に詳細な設計書があったとしても、他人の書いたソフトウェアは理解しにくいものです。「不具合」の原因を見つける難易度は、さらに上がるでしょう。
それでも、パソコン上で動作するソフトウェアでは、デバッガーを使えば、怪しい箇所にブレイクポイントを貼ったり、ソフトウェアのコードを１行ずつステップ実行させたりして、「不具合」の発生箇所を見つけるような手段が取れます。一方で、「組込み制御ソフトウェア」は「動いているもの」を扱うため、ソフトウェアを止めながらコード１行ずつ調べるようなことはできません。
さらに、組込みハードウェアには、情報を見るための、便利なディスプレイがついていない場合が多いので、パソコンのソフトウェアのデバックで使う、プリント文を使った、ソフトウェア内部の値を表示することもできません。調査に使える情報が、パソコン上のソフトウェアに比べて圧倒的に少ないため、「不具合」の原因調査の難易度がとても高くなります。
ここでは、「組込み制御ソフトウェア」の「不具合」発生箇所の特定が難しいことに触れましたが、その対策として、以下の２つを重点的に考えていきます。
- 動作中の組込みソフトウェアの内部情報を把握しやすくする事 → 見える化
- 組込みソフトウェアの問題箇所を特定しやすくする事 → 切り分け
