機械を動かす「組込み制御ソフトウェア」には、不具合が事故につながる場合があるため、高い品質が求められます。ただ、ソフトウェアの品質の高さの捉え方は、ソフトウェアを開発したり、開発したシステムを利用する立場によって、異なる場合もあるでしょう。
また、ソフトウェアの要求仕様、設計、ソースコードを作成するそれぞれの立場では、自分自身の手を離れた後に、第三者によって、品質を評価されることが多いでしょう。業務で行っている作業につき、通常は、自分の手を離れて、第三者へ渡す前に、何らかの確認をするはずです。その確認行為が、適切に実施できていれば、第三者が見つける不具合を減らすことができるでしょう。すなわち、第三者の開発工程の中で、品質が高いという評価になるでしょう。反対に、十分な確認が出来ないまま、後工程に渡ってしまうと、不具合が多く発生することにより、品質が低いと評価されるでしょう。
例として、最初にまず、「組込み制御ソフトウェア」の要求仕様を受け取って、ソフトウェアの設計やソースコードを作成する、立場の人を想定します。このような人は、もし、受け取った要求仕様に矛盾があり、仕様通りにソフトウェアを作成しても動かないものになっていたり、さらには、要求仕様の表現が曖昧で、プログラムを作成できないものになっていた場合は、何度も要求仕様作成者への確認作業が必要になって、その品質が低いと判断するでしょう。
それを改善する対策として、昨今では、ブロック線図を使った制御設計ツールで要求仕様を作成し、シミュレーションで動作確認して、矛盾やミスを防ぎ、かつ明確に表現する工夫をしている開発現場も多いでしょう。モデルベース開発とも呼ばれるこの工夫は、明らかに、後工程作業の手戻りを減らせるため、「組込み制御ソフトウェア」の要求仕様の品質が高いという評価が得られるでしょう。
次に、「組込み制御ソフトウェア」のソースコード、もしくは、「ハードウェア」へ実装するコードを受け取って、テストをする立場の人を想定します。このような人は、もし、「ハードウェア」が異常な動きをし、それを修正するために、「組込み制御ソフトウェア」の修正を繰り返す状況になっていると、「組込み制御ソフトウェア」の品質が低いと感じるでしょう。
この状況を改善する対策は、既に前の章で説明したように、問題の切り分けを容易にするための、設計上の工夫をした上で、このテスト工程の前工程で、不具合の発生要因をつぶしておくことです。例えば、「ハードウェア」と「組込み制御ソフトウェア」それぞれ、単体で事前に動作確認し、ソフトウェアも、評価し易いように、複数コンポーネントに分けて、それぞれ事前に単体で動作確認しておくなどの工夫をすることです。各コンポーネントの動作確認においても、ブロック線図を使った制御設計ツールでのシミュレーション結果が大いに役に立つでしょう。ここでも、モデルベース開発の恩恵を受けることができるはずです。
このように、品質を上げようとすると、事前の動作確認作業が増えていきます。つまり、予測のつく範囲で開発に必要な時間が増えます。そもそも事前の動作確認を怠ると、次の開発工程でトラブルが多発して、開発がなかなか先に進めないなど、予測不可能な開発時間が増え、大きなリスクとなります。したがって、予測可能な範囲で開発時間が増えることや、動作確認のためのシミュレーション可能な制御設計ツールの導入については、品質を上げるためには必要と考えることが多いでしょう。
次は、さらに「組込み制御ソフトウェア」が実装された、出荷済みの「制御システム」を使う立場の人を想定します。いわるゆユーザの立場になりますが、そのような人にとっては、「制御システム」が取り扱うもので、「組込み制御ソフトウェア」やそれを実装した「ハードウェア」については、特に意識しないでしょう。「制御システム」が変な挙動をしたり、そもそも動かなかったりなどの不具合を経験すると、故障したと認識して、修理が必要と判断するでしょう。同じような不具合が何度も発生したり、修理しても不具合が再発するようであれば、「制御システム」の品質が低いと判断するはずです。 動くものである「制御システム」には、故障する可能性も容易に想像できるため、直接「組込み制御ソフトウェア」の品質には、注目を向けにくいでしょう。つまり、「組込み制御ソフトウェア」の品質を意識するのは、開発側の立場の人になるはずです。
少し本題から外れますが、「制御システム」の不具合を特定して、的確な修理を実現するために、「組込み制御ソフトウェア」を活用して、故障診断機能を組み込む工夫もあります。さらには、制御ソフトウェアが、ハードウェアの故障を検出した場合に、危険な挙動が発生することを回避する処理を組み込むこともあるでしょう。「機能安全性」を求められる「制御システム」には、このような、異常時の危険回避の処理を積極的に実装されています。一般に「機能安全性」というと、ソフトウェアに不具合が無いかどうかということに、興味を持つ人が多いように感じます。しかし実際は、私自身も経験したことですが、前に説明したように、明確な要求仕様を定義し、しっかり事前確認をするプロセスを踏みながら、評価しやすい設計のソフトウェアを開発すれば、少なくとも要求仕様通りの「組込み制御ソフトウェア」を開発することは、できるものです。モデルベース開発も有効でしょう。もちろんこれは、要求仕様通りであることが、ソフトウェアの品質が高いと言えるという仮定の上での話です。そして、次の大きな課題は、要求仕様の精度を上げることになります。もちろん、要求仕様通りに「組込み制御ソフトウェア」を開発することは、簡単では無かったはずです。ただ、それについては、今まで説明した内容で、大きく改善されていきます。要求仕様の精度を上げるには、試作を繰り返して、シミュレーションの精度を上げるなどの工夫が必要でしょう。なお、モデルベース開発で、試作して実験する効率を上げることはできる可能性があります。それでも、精度良く、再現性の高い実験をする技術力や、実験結果と一致するシミュレーション環境を作成するための技術力は必要でしょう。この辺りが、高いレベルでの製品開発における、競争領域になっているはずです。なお、この話題については、「組込み制御ソフトウェア」の話から、外れてしまうので、これ以上は取り上げないでおきます。
