ソフトウェアの要求仕様から、ソフトウェアを設計する際に、いきなり詳細なロジックを考える前に、ソフトウェアの構造やインタフェースを考えることは重要です。この情報をまとめたものが、ソフトウェアの基本設計です。一方で、ソフトウェアの詳細なロジックを考え、まとめたものが、ソフトウェアの詳細設計です。英語では、ぞれぞれ、 High-Level Design （HLD)、Low-Level Design (LLD)のように、表現することもあります。この章では、この前者部分である「組込み制御ソフトウェア」の基本設計について取り上げます。
「組込み制御ソフトウェア」の要求仕様で定義された内容の実現方法は、いくつか考えられるはずです。いわゆる、ソフトウェアの設計には自由度があります。その自由度は、開発の最終テストフェーズをスムースに進めるために使うべきというのが、ここでの基本設計のコンセプトになります。つまり、これまでの章で取り上げて来た、ソフトウエアの見える化とモニタリング、問題の切り分けの容易化を目指して、ソフトウェアの構造とその間のインタフェースを設計します。
まず、ソフトウェアの要求仕様を実現する上で、コンポーネント構造を考えます。特にある程度規模が大きく複雑な「組込み制御ソフトウェア」では、開発の最終テストフェーズの作業効率化が重要なため、問題の切り分けを容易にすることを目指して、コンポーネント分割します。具体的には、既に以前の章でも説明済みですが、処理の評価に実際のハードウェアが必要な部分と、そうでないアプリケーション部分に分けます。さらに、アプリケーション部分を、制御処理レート/モニターデータの更新レートなどの、実行タイミング毎の塊に分けます。その上で、それぞれの実行タイミングの塊の中で、評価しやすい単位で、コンポーネント分割します。なお、このようにコンポーネント分割すると、要求仕様の各項目通りにコンポーネントが分かれるとは限りません。したがって、要求仕様とソフトウェアのコンポーネント部分の対応情報は、設計結果（設計書）として記載する必要があります。
ここでのポイントは、「組込み制御ソフトウェア」の基本設計で、要求仕様で定義された機能の塊を、そのままコンポーネント化せず、リアルタイム実行中の評価や不具合の特定、修正や機能変更への対応など、テストやメンテナンスのしやすさに着目して、コンポーネント化を考えるべきということです。
そして、上記の考え方で分割したコンポーネント間の、インタフェースデータも設計します。計測したいデータに、グローバル変数を利用するなどして、組込みハードウェア実行中に値をモニターできるような仕組みも設計します。モニターの再現性を確保するために、コンポーネント間のインタフェースデータの更新は、外的な要因ではなく、ユーザ側が規定したタイミングやレートで行う必要があります。そのために、明示的に各コンポーネントの実行タイミングや順序を規定する処理や、コンポーネント間のデータ更新タイミングを規定する処理を設計するようにします。
余談ですが、私が初めて「組込み制御ソフトウェア」の開発に取り組み始めたときは、まだソフトウェアの基本設計の重要さを十分理解できていませんでした。それまでは、PCで動くソフトウェアを開発していたこともあり、ソフトウェアの設計書は、最悪ソフトウェアが動くようになってから、完成したソフトコードの説明用や、メンテナンス用に必要な資料として準備すれば良いという認識でいました。PC上で動くソフトウェアで、特に外部の機械を動かすわけでもなく、期待通りの結果にならない場合は、怪しい箇所で一旦処理を止めて、デバッグできるため、ある程度時間をかければ、不具合の原因特定ができていました。一方で、動いている機械を制御している「組込み制御ソフトウェア」の場合は、止めながらデバッグすることはできません。動作している制御システムが、外から見て内部が正しく機能していることを確認したり、もし何らかの問題がある場合に、不具合の発生箇所を効率的に特定するには、そのための仕組みが必要でした。ソフトウェアの設計の自由度を、その仕組みを活かすために使うべきということは、私自身初めての「組込み制御ソフトウェア」開発の中で理解しました。
