2011年8月2日火曜日

僕たちのファームウェア戦略 (LPCXpresso Clockを使って、組み込み機器開発特有の問題解決を楽しもう！)

戦略なしではいられない

LPCXpresso Clockは、現状でほぼ全てのLPCXpressoにドッキングする事を考えています。
この時、LPCXpressoの各モデルに対するライブラリを個別に提供しても構わないのですが、管理や設計から見ると美しいとは言えません。

例えば・・・

「このウルトラミラクル輝度制御機能は全モデルに搭載されている機能なんだけど、あのモデルでは"ABC"になっていて、このモデルでは"DEF"になっている。」
「あぁ、そのモデルは全然保守されていなくて、別のインターフェースになっているんだ。」
「え？このモデルでしか動かせないハッピータイマー機能を加えたけどだめだった？」

など、実際の製品開発においては、シリーズとして相応しいインターフェースを提供しているのかなどの検討も欠かせないのです。
「あのモデルのためにABCインターフェースを追加したら、別のモデルで致命的な矛盾が生じた。」なんて笑うに笑えないわけです。

今回の設計に関して言うと、殆どの機能は共通なのですから、アプリケーションロジックは共通にしておきたいところです。そのためには、下層ライブラリを適切なインターフェースで切って、実体を抽象的に扱う事が欠かせません。これは今後触れていくであろう「僕たちのクロスプラットフォーム戦略」にも関連があります。

考えられる様々な要求を簡単に箇条書きにしてみましょう。

使いやすいライブラリを提供して欲しい。(ユーザ要求)
インターフェースの学習コストを最小限にしたい。(ユーザ要求)
アプリケーションロジックは共通化して、開発コスト対効果を最大限に高めたい。(ユーザ要求)
優先度の高いモデルや機能から実装して、要求に応じて他のモデルも開発したい。(開発者要求)
「私はCで書きたいんだ。」、「私はC++で書きたいんだ。」(ユーザ要求)
その他

他にも様々な要求が考えられるわけです。
要求は、顧客から来るもの、設計から来るもの、実装から来るもの、様々です。

いずれにせよ言えるのは重複するような内容が物事に含まれている場合、何かと問題が生じるという事実です。

ここを美しく解決する事が「僕たちのファームウェア戦略」であり、１つの製品設計で複数のラインナップを揃える事のできる土台となるわけです。

設計の土台を作る(分割し、整理し、統治する)

では、具体的にどうすれば良いのかという話になります。
基本的には「分割し、整理し、統治する」という流れです。

分割(あるいは統合)

同じものと違うものを分割します。あるいは同じものを統合します。
分類に迷ったら、基準となる視点を定めて分割するか統合するかを判定します。

例えば、LPCXpresso Clockの場合、分割可能な要素の例には以下の２つがあります。

LPCXpresso Clock基板固有の機能。 (時計のインターフェースを実現するハードウェア。)
ドッキングさせるLPCXpresso基板固有の機能。 (時計の制御を実現するハードウェア。)

簡単ですね？
ドッキングして使用するのですが、2つの基板の役割は明確にわかれています。

LPCXpresso Clock基板+LPCXpresso基板=LPCXpresso Clockですから、上記の視点は非常にシンプルなものです。
(一見下らない要素を大げさに取り上げているように見えるかもしれませんが、これが後々の設計と綿密な関わりを持ってきます。)

整理(あるいは破棄)

分割した要素の詳細を整理します。
詳細といっても実装レベルの詳細ではなく、「だいたいこんな感じかなぁ？」程度の整理で構いません。

例えば、LPCXpresso Clockの場合、以下のような感じです。

LPCXpresso Clock基板

7セグメントLED (出力)
赤外線受信回路 (入力)
照度センサ (入力)
スイッチ (入力)

LPCXpresso基板

GPIO (入出力)
RTC (入力) - 無いモデルもある。

統治(あるいは留保)

統治の段階でインターフェースを定義してみます。

Cならヘッダファイルにインターフェースを定義します。
C++ならヘッダファイルにクラスを定義します。

この時点で統治できないような内容があっても構いません。
意味不明な物体は、この時点で無理して統治する必要はありません。
少し変な名前を付けて残したりすれば良いです。

これは検討の方向性を確認するためのプロトタイプ実装です。
実際に動作させるところまで持っていく必要はありません。

これが「僕たちのファームウェア戦略」における実用的な出発点です。

そ・れ・で・？

子供騙しのような整理をしてどうなるのか？と感じる方もいるでしょう。
でも、上記の３ステップの整理をするだけで

システムが何を提供しようとしているのかが明確になる。
シリーズ並行展開の視野を身につける事ができる。
自身の設計が何のプラットフォームに依存しているのかを明確に認識できる。
その他

様々な効果が得られます。

今回は「僕たちのファームウェア戦略」の出発点を示し、その効果について概略を解説しました。

CuBeatSystems