木曜日, 8月 02, 2007

ステートマシン その2

ステートマシンの題材として、
エレベータのドアの制御のようなものを考えてみようと思います。

仕様は次のとおり。
実際のエレベータのドアがどのように行なわれているのか全く知らないので
以下の仕様は想像です。なので、かなり変かもしれませんがその辺は大目に。

[エレベータ ドアの制御モジュールの仕様]
・"開"ボタンと"閉"ボタンの入力
・"開"ボタンでドアが開き、"閉"ボタンでドアが閉まる
・外部にドア制御信号を出力
・ドア制御のバリエーションは「開ける」、「閉める」、「停止」の3つ
・ドア位置情報の入力
・ドア位置情報は完全に閉まった状態を"Min"、完全に開いた状態を"Max"とする
・ドアが完全に開いた状態で、5秒間"閉"ボタンが押されなければドアを閉じる


実際のモジュールの仕様であれば信号名やタイミングなど明確になっているべきですが、今回はここから始めることにします。
現実の仕事でも曖昧な仕様が渡されて、詳細は自分で定義しなければならないことは多いと思うので。。。

まずはどういう状態があるか考えましょう。
次の4つが妥当なところでしょうか?

1.ドアが完全に閉まった状態
2.ドアが完全に開いた状態
3.ドアが開いている最中の状態
4.ドアが閉まっている最中の状態

ちょっとシナリオを書いてみると、

まずドアが閉まっている。
"開"ボタンを押すとドアが開き始める。
ドアが完全に開くとその状態でドアは停止。
"閉"ボタンを押すとドアが閉まり始める。
ドアが完全に閉まるとその状態でドアは停止。

なんとなくよさそうです。
それでは早速状態遷移図を描いてみましょう。



まだ完全というわけではありませんが、なんとなくそれらしいものができていると思います。

次回はこの状態遷移図を仕様を満足させるところまで持っていって
さらにコーディングできる1歩手前までやってみたいと思います。

このシリーズは少し長くなりそう。

ところで、普段使っていたわけではないのですが、今回の状態遷移図はJUDE Communityというツールを使ってUMLのステートチャート図で描いてみました(UMLに慣れてないので変なところがあればご指摘ください)。

個人的にはハードウェアの設計にUMLを使うのはなかなか難しいところがあるなぁと考えているのですが、ステートチャート図についてはほぼそのまま使えると思います。

逆に言うと、ステートマシンでできることはソフトでできる処理とかなりオーバーラップがあります。

実際、今回のお題のようなものであれば恐らく1チップマイコン等を使うほうが多いのではないでしょうか?

最近はコンパクトなソフトマクロCPUもあるので、下手にステートマシンを設計するよりはそういうものを使ったほうが生産性・品質の両面でお得かもしれません。

0 件のコメント: