こんばんは。Photosynth の 組み込みエンジニア @ishturk です。
Akerun Adventカレンダー 7日目 の記事です。
今日は Akerun ファームウェア 特に ミドルウェア の作り方についてお話ししたいと思います(雑)
Akerunはこんな製品です。まずは動画をご覧ください。
スマホなどでサムターンを物理的に回転させて錠を操作。履歴が取れるというものです。
動画はスーパーかっこいいですが、組み込ミストの僕にはこんな風に見えます。
- LED（フルカラーイルミネーション）を30fpsくらいで制御しながら
- メモリの読み書きして
- 音声を再生し
- アクチュエータを制御しながら
- センサーをもりもり監視して
- BLEでセキュアに通信している
- (実はほかにもいろいろ。。。）
なかなかに心躍るリッチなデバイスです。設計を失敗すると一瞬で破綻する未来が見えます。
ミドルウェア設計の話
用語の定義ですが以下のイメージ図をご覧ください
今日お話しするのは、この「ミドルウェア」の部分です。
本記事ではミドルウェアを設計するのに重要な「ステートマシン」「モジュール構成」にフォーカスしてお話しします。
状態を管理する・状態で管理する : ステートマシンの話
そこそこの規模になると一つ以上のステートマシンで管理するのが設計の基本原則です。
たとえば、あける、しめる という制御の場合でも
- あいてるときにしめる要求→しめる制御
- あいてるときにあける要求→無視
- しまっているときにあける要求→あける制御
- しまっているときにしめる要求→無視
- 起動中→全部無視
とこれだけのパターンがありますね。
ステートマシンのメリットは、
「〇〇状態でXX要求がきたら△△する」という制御を書くのはもちろんですが
「〇〇状態でXX要求がきても何もしない（必要に応じて後始末）」を明確にすることです。
たとえば、以下のような感じ。わかりやすいですね。
ステートマシンの約束事として、
- 要求のことをイベント
- イベントを受けて行う処理をアクション
- アクションする条件をガード条件
と呼びます。
状態遷移が発生するイベントは→で遷移を示します。→につけるコメントは、 "イベント/[ガード条件]アクション"のような書き方をします。
状態遷移が発生しないけど何かしらの処理を行うイベントの場合は、状態のなかに "イベント/[ガード条件]アクション"のような書き方をします。
図に書かれていないイベント（起動中のあける要求 など）は全部無視です。
へぼい設計をしてしまうと、ステートマシンがスパゲッティになっていきます
そのときは、
- 状態を増やしてみる
- 階層構造にしてみる
- そもそも全体を見直す
などの対策をしましょう。
みんな大好きステートマシンのお話でした。
「状態遷移表」「状態遷移設計」というキーワードも合わせて検索してみてね。
ちなみに C言語でかくステートマシンの作り方も投稿しているので参考にどうぞ
C言語でファンクタを使ってステートマシンを実装する
## モジュールをどう切るか : 抽象度と依存関係の話
もしモジュールを分けずに実装したらどうなるか？おそらく main.c が2000000行くらいになるでしょう。
では、どう界面を切ったらいいか。
僕が意識しているのは以下の部分です。
- この人(モジュール)はどこまで知っているか
- この人がどこまで細かく指示をだすか
各モジュールがもつ情報量を極力シンプルにするのがベストです。
たとえば、あける動作をするとき、
- LEDを赤色に2秒周期で点滅させる
- モータを90度回転
- あけました！と音をならす
- あけたログを残す
と仮定します。
たとえばこんな感じ。
上位ほど抽象的な指示を出し、下位ほど限定的かつ具体的な制御をするモジュールになってます。チェックポイントとしては、
- 各モジュールが判断する情報を減らす。上から言われたことを下へ(理解出来る情報に変換して)伝えるのがミッション。
- 上下関係を明確に。下から上への指示は厳禁。 ※通知などはコールバックやイベントハンドラを使いましょ
- 依存関係は最小限に
実際にコードを書く前にモジュール関係図を書いてみると設計に失敗することがなくなりますね。
まとめ
以上、ステートマシンとモジュール構成のお話しでした。
設計するときにどちらも設計の根幹になるものなので大事にしたいですね。
これらのドキュメントがないプロジェクトは地雷の可能性が高いので気を付けましょう。
明日も自分が担当です！