シミュレーションプログラムや、Simulinkのような市販ツールのモデルを、試作機や実験結果を使って育てることで、「組込み制御ソフトウェア」の要求仕様を明確にできます。さらに、ソフトウェアのテスト時に、期待入出力データをあらかじめ準備できるます。これらの利点により、「組込み制御ソフトウェア」の完成をより確実にし、製品出荷テストを完了させるまでの期間を短縮することができるでしょう。ところが実際には、そのシミュレーションだけでは、製品の最終出荷テストで発生する問題を、事前に予測できない場合もあります。この章では、その典型的な要因として、製品組込みハードウェアを使わないと、見えてこないものについて、取り上げます。
最初に取り上げるものは、「組込み制御ソフトウェア」の実行時間です。制御の要求仕様を決めるためのシミュレーションは、PCなどの計算環境で実行しているため、そこでは実際の組込みハード上のソフトの実行時間を把握することは、簡単では無いでしょう。特に、新規の組込みハードシステムを製品に利用する場合は、その実行時間の見積もりは難しくなります。実際に「組込み制御ソフトウェア」を製品ハードウェアで動かさないと、実行時間を精度良く計測することができません。ところが、ある程度規模の大きいソフトウェアの場合は、実行時間を計測する対象のソフトウェアの作成自体に時間が掛かります。そのため、例えばもし「処理時間が規定の制御周期時間に収まらない」ことがを判明すると、組込みソフトウェアの設計を修正したり、それでも間に合わない場合は、要求仕様から見直す必要があるかも知れません。いずれにしろ、開発に無視できない手戻りが発生してしまいます。要求仕様を見直しても、規定の制御周期に収らない場合は、システムとして破綻しているので、ハードウェアの変更が必要となったり、ハードウェアの改善が出来ない場合は、プロジェクトが破綻するでしょう。これは、製品開発にとっては、大きなリスクとなります。私も設計したソフトウェアが、規定の制御周期時間に収まらないことを、何度か経験したことがあります。あれこれ設計を工夫して、何とか規定時間内に収めることができましたが、かなりストレスフルな作業でした。制御処理周期時間の他にも、「組込み制御ソフトウェア」の起動時間にも苦しめられました。想定以上に起動に時間が掛かったり、連接する他の複数の組込みハードウェアの起動時間が、それぞれ長かったり短かったり、変動したりなどして、それらの状況に対応する工夫が必要でした。
補足ですが、処理時間を計測する仕組みは、見える化の一貫として、準備しておくことは重要です。
次に取り上げるものは、「組込み制御ソフトウェア」のメモリ使用量です。制御の要求仕様を決めるためのシミュレーションプログラムでは、利用するPCのメモリ使用量を気にしないことが多いでしょう。一方で、組込みハードウェアのコンピューターで利用できるメモリのサイズは、通常PCほど大きくありません。「組込み制御ソフトウェア」のメモリ使用量を知るには、実行時間と同様に、計測する対象のソフトウェアの作成が必要となり、もしメモリ使用量が許容値を超えるようであれば、ソフトウェアの設計変更や、場合によっては要求仕様の変更、ハードウェアの変更など、開発リスクとなります。
こちらも、補足ですが、ソフトウェアの実行時に、メモリ不足が発生すると、原因究明のデバッグが著しく困難な、メモリ領域外アクセスのランタイムエラーが起きます。そのため、ソフトウェアを実行しなくても、メモリ使用量を見積もる手段を準備しておくことも、重要になります。
その他の注意点として、演算誤差があります。シミュレーションプログラムの章でも取り上げましたが、計算機ハードウェアの違いや、コンパイラーの設定の違いが、浮動小数点実数の計算結果に影響し、誤差を発生させる場合があります。PC上のシミュレーションの結果と、組込みハードウェア上で実行した結果が一致しない場合に、その原因が計算誤差によるものなのか、不具合の混入によるものなのか、判断するこが難しいこともあるでしょう。
このように、シミュレーションだけでは判断が難しく、組込みソフトウェアが無いと、必要な情報を入手できない場合があることを、事前に認識して開発に挑むべきです。一般的に、組込みソフトウェアが準備できる最初の開発工程は、関数単体テストなので、この時点で上記の必要な情報を手に入れるべきです。さらにもし、Simulinkを使って制御ソフトウェア開発している場合は、Embedded Coder®︎という製品を使うことで、シミュレーションモデルから自動で組込み用ソフトウェアを生成出来るため、開発工程のさらに早い時点で、上記情報を入手出来るでしょう。これは、上記で触れた「組込み制御ソフトウェア」の開発リスクを減らす大きな効果をもたらします。
