発生した問題
ある電子機器メーカーで通信端末を開発しているときのことです。試作機を操作していると，たまに通信不能になる，という問題が発生しました。常にそうなるわけではなく，100回に1回程度の割合でたまに起こります。既に量産体制が確立しつつあったので，総動員で問題の解析に当たることになりました。
原因と対策
通信ICの開発を担当していたTさんは，マイコンと通信ICのやりとりをオシロスコープで測定してみました。そこで，通信ICの初期化に使用するクロックに原因があることを見つけました（図6-1）。問題が発生するときは，規定の1/100という異常に低い周波数になり，通信ICの規定時間を満たすことができずに初期化が失敗していました。
クロックには，節電のための低速クロックと通常処理用の高速クロックの2種類があり，アプリケーション・ソフトウエアが必要に応じて切り替えることになっています。今回の原因は，クロックを低速あるいは高速に切り替える条件やタイミングを管理できていなかったことでした。
アプリケーション・ソフトウエアをチェックすると，高速クロックと低速クロックの切り替えを指示するコードが各所に散在していました（図6-2）。このため処理の順序によって，本来高速クロックで実行されなければならない通信ICの初期化が，低速クロックで実行されてしまったのです。
Tさんは，マイコンのクロックを切り替える条件の整理と状態定義，実装のやり直しを行いました（図6-3）。まず低速クロックと高速クロックを切り替える条件を列記しました。次に，状態が切り替わる状態遷移図を作成しました。実装のときは，保守しやすいようにこれらの状態を管理するコードを一つのファイルに集中させました。
技術者必修の基本
Tさんがソフトウエア担当者に話を聞いてみると，このアプリケーション・ソフトウエアは丸ごとある会社から買ってきたものでした。きちんと設計しないまま変更を繰り返していたために，今回のようなミスが起こったのでした。コードがあるからといって，設計なしで泥縄式で実装していると，このようなトラブルはいつか起こります。
デバイスの初期化のように，時間に依存する制御の要件を集約・整理しておくことは大切なので，ぜひお勧めします。パソコンのアプリケーションを作るときはほとんど意識せずに済みますが，組み込み機器では必須です。システムの状態を常に特定できるように，状態管理を徹底しなければならないからです。
ところで，現物がどうなっているのかを確認できるオシロスコープは，デバッグ・ツールとして非常に有用です。ソフトウエア技術者も，ハードウエア屋さんに頼んで使い方を教わっておきましょう。
