基本設計と詳細設計の違い（組み込み編）
基本設計と詳細設計の違いを解説する記事は数多く公開されています。ですがその大半は、画面設計や帳票設計を基本設計の中心に据えた、業務システム開発を前提とする説明です。組み込み機器の多くには、そもそも画面も帳票もありません。あってもLCDやLEDだけという製品が大半です。では組み込みソフトの基本設計には、何を書けばよいのでしょうか。本記事では、組み込み特有の設計書に書くべき内容を、詳細設計との違いとあわせて整理します。
- 基本設計と詳細設計とは何か - 一般的な定義を整理する
- 組み込み機器には画面も帳票もない - 外部設計に何を書くのか
- 組み込みの基本設計（外部設計）に書くべきもの
- 組み込みの詳細設計（内部設計）に書くべきもの
- ハード仕様に引きずられる設計の難しさ
- 設計書を書く目的と、実機を待たずに始める検証
- まとめ
基本設計と詳細設計とは何か - 一般的な定義を整理する
基本設計と詳細設計という用語は、システム開発の現場で広く使われています。基本設計は「外部設計」と呼ばれることもあります。詳細設計は「内部設計」と呼ばれることもあります。基本設計では、ユーザから見える部分を決めます。画面のレイアウトや帳票の書式、操作の流れなどが対象です。詳細設計では、基本設計で決めた内容を、どのようなプログラム構造で実現するかを決めます。
この整理は、業務システム開発を前提とした説明です。検索上位に並ぶ多くの解説記事も、画面設計や帳票設計を基本設計の中心に置いています。要件定義から基本設計、詳細設計へと進む開発の流れそのものは、業務システムでも組み込み機器でも大きくは変わりません（「開発の全体像と手戻りを防ぐ設計」参照）。違いが表れるのは、基本設計の中身です。
この区別を意識しないまま設計書を書き始めると、外部設計に内部の実装詳細が混ざったり、逆に内部設計で外部仕様の説明を繰り返したりします。粒度がそろわない設計書は、レビューする側にとって読みにくく、指摘もかみ合いにくくなります。基本設計と詳細設計の境界をどこに引くかは、組み込みソフトでも変わらず重要な観点です。
組み込み機器には画面も帳票もない - 外部設計に何を書くのか
組み込み機器の多くは、ユーザが直接操作する画面を持ちません。産業用センサや制御ユニット、家電製品の内部に組み込まれる基板などが代表例です。画面があっても、小さなLCDや数個のLED、ブザーだけという製品が少なくありません。帳票を出力する機能も、多くの組み込み機器には存在しません。
たとえば、工場の生産ラインで使われる制御ユニットや、自動車に搭載されるECU（Electronic Control Unit）、医療機器に内蔵される基板などは、いずれも単体では画面を持たずに動作します。操作は上位の制御システムや、別に用意された操作パネルから行われ、機器そのものはスイッチとランプだけを備えているケースが一般的です。
業務システムの基本設計は、画面設計と帳票設計を中心に組み立てられます。しかし組み込みソフトには、その中心となる対象そのものがありません。ここで一つの問いが生まれます。画面も帳票もない組み込み機器において、外部設計には何を書けばよいのでしょうか。
この問いの背景には、組み込みソフトと汎用ソフトの根本的な違いがあります（「組み込みソフトと汎用ソフトの違い」参照）。組み込みソフトは、ハードウェアと一体になって動作します。外部設計が扱う対象も、画面ではなくハードウェアとのやり取りに置き換わります。
スイッチやLEDだけでは操作性に限界があるため、設定用のパソコンツールやスマートフォンアプリを別途用意する製品もあります。ただしその場合も、画面設計が必要になるのはツール側のソフトウェアです。機器に組み込まれるファームウェア自体の基本設計に、画面設計が含まれるわけではありません。
組み込みの基本設計（外部設計）に書くべきもの
業務システムの外部設計書では、画面遷移図や帳票レイアウトが主要な成果物になります。組み込みの外部設計では、機器の外部から見える振る舞いのすべてが設計対象です。画面設計のかわりに、次のような要素を記述します。
- 外部インターフェース仕様：スイッチの入力条件、LEDの点灯パターン、ブザーの鳴動条件、表示器がある場合はその表示内容を定義します（「主要外部インターフェースの種類」参照）。
- 通信仕様：通信相手の機器、使用するプロトコル、送受信するフレームの構造、応答までの許容時間などを定めます（「通信におけるI/Oの堅牢化とタイムアウト設計」参照）。
- 状態遷移：機器がどのような動作モードを持ち、どの条件で別のモードへ移るかを整理します。モードの数が増えるほど整理は複雑になります（「状態爆発を防ぐステートマシン設計」参照）。
- ハードとソフトの機能分担：どの処理を回路側で行い、どの処理をソフトウェア側でおこなうかを切り分けます。
- タスク構成と処理周期：どのような単位で処理を分割し、それぞれをどの周期で実行するかを決めます（「RTOSのタスク設計」参照）。
- 異常時の振る舞い：通信が途切れた場合やセンサが異常値を返した場合に、機器がどう振る舞うかを規定します。
これらはいずれも、ユーザや接続先の機器から見える「外部の振る舞い」です。画面や帳票という具体的な形がなくても、外部設計が扱う対象は業務システムと同じく、外から見える部分だといえます。画面設計に画面ごとの項目一覧があるように、組み込みの外部設計にも、インターフェースごとの仕様一覧が必要になります。
たとえば、スイッチについては操作方法や反応時間、チャタリング対策までを一覧化します。通信については、上位機器との送受信フレームを一件ごとに定義しておきます。ここまで具体化しておけば、実装を担当する開発者が仕様を読み違える余地は小さくなります。
組み込みの詳細設計（内部設計）に書くべきもの
詳細設計では、基本設計で定めた外部の振る舞いを、内部でどう実現するかを記述します。業務システムの詳細設計がプログラムの内部構造を記述するのと同じように、組み込みソフトの詳細設計にも、実装に踏み込んだ項目が含まれます。
- モジュール分割と依存関係：ソフトウェアをどのような単位に分割し、モジュール同士がどう依存し合うかを整理します。
- 関数単位の処理フロー：個々の関数が何を入力とし、どのような手順で処理し、何を出力するかを記述します。
- データ構造、変数の型と範囲：扱うデータの構造、変数の型、取り得る値の範囲を定義します。組み込みでは使えるメモリが限られるため、この定義が特に重要です。
- レジスタ設定、割り込み設計：マイコンのレジスタにどんな値を設定するか、どの割り込みをどんな優先度で扱うかを決めます。
- 排他制御の方針：複数のタスクが同じデータへ同時にアクセスする場合、どのように競合を防ぐかを定めます。
モジュール間のインターフェースも、詳細設計で明確にすべき項目です。どの関数を、どのヘッダファイルで公開し、呼び出し側にどんな前提条件を課すかを定義しておけば、モジュールを分担して実装する際の認識のずれを防げます。
株式会社ソフテックの技術レポートでも、内部設計書にはモジュール分割図やアドレスマップ、状態遷移図、関数仕様といった項目を記載すべきだと述べられています。組み込みの詳細設計は、業務システムのプログラム設計に比べ、ハードウェアに近い情報を扱う点が特徴です。とくにレジスタ設定と割り込み設計は、使用するマイコンが変わればそのまま書き直しになる項目であり、基本設計以上にハードウェアへの依存が強く表れます。
ハード仕様に引きずられる設計の難しさ
組み込みソフトの設計には、業務システムにはない難しさがあります。それは、ハードウェアの仕様が確定しないと、ソフトウェアの設計も固まらないという制約です。使用するマイコンやセンサ、通信モジュールが変われば、外部インターフェース仕様も、レジスタ設定も書き直しが必要になります。
開発の途中で部品変更が起きることも珍しくありません。たとえば、採用を予定していたセンサICが供給停止となり、後継品に切り換えたケースを考えます。後継品で通信プロトコルやサンプリング周期が変わっていれば、通信仕様だけでなく、そのセンサの値をもとに判定していた状態遷移の設計まで見直しの対象になります。ピン配置やタイミング特性が変わっていれば、確定していたはずの基本設計や詳細設計を部分的にやり直すことにもなります。
この制約があるからこそ、組み込みの設計書には、ハードウェアの前提条件を明記しておくことが重要です。前提を明記しておけば、部品変更が生じた際に影響範囲を素早く特定できます。
設計書を書く目的と、実機を待たずに始める検証
設計書を書く目的は、大きく三つあります。
- レビューによって手戻りを防ぐことです。設計段階で誤りを見つければ、実装後に見つかるより修正の手間が小さく済みます。
- 後任の開発者が読んで理解できるようにすることです。設計の意図が記録されていれば、担当者が変わっても保守を続けられます。
- 各種規格に対応する際のエビデンスとして残すことです。機能安全や品質管理の規格では、設計の根拠を文書として示せることが求められる場面があります。
組み込みの設計書は、ソフト担当者だけでなくハード担当者もレビューに加わることで、価値が高まります。外部インターフェースの仕様に齟齬があれば、両方の視点を突き合わせてはじめて発見できることが多いためです。
設計書に記した状態遷移やタイミング仕様が正しいかどうかは、最終的には実機で確認するしかありません。設計段階でどれほど注意深く検討していても、実際のハードウェア上で動かしてはじめてわかる不具合が残るからです。
ただし、実機の完成を待たなければ検証を始められないわけではありません。ハードウェアの動作を模擬する環境を使えば、実機がそろう前から、通信のやり取りや状態遷移の妥当性を確かめられます。こうした検証環境は、一般にHILS（Hardware-in-the-Loop Simulation）と呼ばれています。設計の段階から検証の手段を意識しておくことが、手戻りの少ない開発につながります。
まとめ
組み込みの基本設計は、画面や帳票のかわりに、外部インターフェースや通信仕様、状態遷移、ハードとソフトの機能分担を記述します。詳細設計では、モジュール分割やレジスタ設定、割り込み設計など内部構造を記述します。ハード仕様に設計が左右される制約を理解し、レビューや引き継ぎといった目的を意識した設計書を作成することが、手戻りの少ない開発につながります。
