状態遷移の種類と形式検証の使いどころ · 2011年11月17日 aisin aw co., ltd. all...

２０１１年１１月１７日

AISIN AW CO., LTD. All rights reserv ed. Do not reproduce or distribute.

状態遷移の種類と形式検証の使いどころ

アイシン・エィ・ダブリュ株式会社

技術本部解析技術部

主任研究員久保孝行

２０１１年１１月１７日


はじめに

• 背景– 状態遷移を使えば、なんでも表現でき、形式検証によって安全性が確認できるという誤った情報で、状態遷移に飛びつく傾向があるが、正しい理解の下で状態遷移を使わなければ、目指した効果は得られない。

– 安全な設計を行うには、元となる正しい知識が必要である。

安全の基本は、「教育」です。

• 発表の流れ– 状態遷移図の使われ方の事例– 状態遷移図の教育方法の説明– 最後に、形式検証の有効な使いところの説明

２０１１年１１月１７日


自動販売機を例題にする

• 入力：お金：50円、100円、• 入力：ボタン：150円ジュース購入ボタン、200円ジュース購入ボタン

• 動作：お金を入れて、金額が満たされた状態で購入ボタンを押すと、ジュースが購入できる。

２０１１年１１月１７日


自動販売機の状態遷移例

要求分析：まず、どの様な流れになるのかシナリオを作る。

• ユースケースを検討– 購入金額は、50円、100円を組み合わせとなる。

150円のジュース購入例（ 200円投入 50円おつり）

1. 50円＋ 50円＋ 50円＋ 50円 ⇒ ジュース購入

2. 50円＋ 50円＋ 100円 ⇒ ジュース購入

まずは、ユースケース１についてタイミングチャートを描いてみよう。

２０１１年１１月１７日


タイミングチャート例

50円

100円

150円ジュース

200円ジュース

総額

150円ジュース

50円

ジュース出力

おつり

一次

入力

信号

中間

信号

出力

信号

ユースケース１

２０１１年１１月１７日


お金の組み合わせは、非常に多いので、タイミングチャートでは数が多くなりすぎる。状態遷移図を使うことで、複数のユースケースをまとめて表現できる。

ミーリーマシンを用いた状態遷移図の例

[50円] [50円] [50円]

意味

合計50円

意味

合計100円

意味

合計150円

/ジュース1出力

意味

合計200円[100円]

[ジュース1購入]


返金50円

ユースケース１、ユースケース２を表現

ユースケース１

ユースケース２[50円]

２０１１年１１月１７日


ミーリーマシンを用いた状態遷移図の例

[50円] [50円] [50円]

意味

合計50円

意味

合計100円


意味

合計150円


意味

合計200円

[100円]




返金50円


[100円]

[100円]

200円投入までの複数ユースケースを表現したミーリーマシン

[50円]

２０１１年１１月１７日


シナリオ表現としての状態遷移図

• ユースケースが多すぎるものは、状態遷移図を使うことで、複数のユースケースをまとめた「シナリオ」を表現できます。これによって、全体の振る舞いが解り、仕様を明確にする事ができる。

• 注意点–ただしこのような状態遷移図は、そのままソフトウェアとして実装する事はできない。

– もちろん形式手法によるチェックも意味がない。• 理由は、この状態遷移図は、要求を理解するため描かれた「シナリオ」だからです。

• ここから、実装に必要な情報を抜き出す為の、「分析」が必要である。

２０１１年１１月１７日


状態遷移図の分析観点：状態変数

• 状態変数には、下記の二つが混在していることに気をつけるべきである。

–状態（有限個）–記憶（無限個）

無限数：記憶中身の量(××ml)中身の温度（℃）発熱量（カロリー）

有限数：状態空・満水沸騰前・沸騰中・沸騰後

２０１１年１１月１７日


状態遷移図の表現：記憶の例

• ミーリーチャートはフリップフロップ（論理演算）の振る舞い説明

の為に作られたが、あくまで振る舞いを説明するためのものであり、コード生成を意識した表現方法ではない。

保持00

01（ﾘｾｯﾄ）0

101

0（不定）11

QRS

出力入力

(1,0)

(x,1)

Q1/0 Q2/1

ムーアーチャート

/0

(1,0)/1

(x,1)/0

Q1 Q2

ミーリーチャート

(x,1)/0(0,0)/0

(0,0)/1

Q=(!R)&&(S||Q)

真理値表や、論理演算が正しいコード

振る舞いを説明する為に描く変換

２０１１年１１月１７日


状態遷移図からコード生成

フリップフロップ回路の振る舞いを書いて、

最適化された論理演算が出力されるか？

コード生成する状態遷移図は、

状態と記憶を区別した物を対象とする。

Q=(!R)&&(S||Q)

(1,0)

(x,1)

Q1/0 Q2/1

ムーアーチャート

/0

(1,0)/1

(x,1)/0

Q1 Q2

ミーリーチャート

(x,1)/0(0,0)/0

(0,0)/1変換

最適化されたコードは自動生成されない

２０１１年１１月１７日


状態遷移図の整理例

–状態（有限個）–記憶（無限個）

• 金額の組み合わせや、ジュースの種類は、有限個と考えるかも知れない。

• しかし、両方共に、数の設定を増減することができるので、無限と考えるべきである。

• 金額やジュースの種類は、「記憶」に分類される項目であり、状態として扱ってはいけない。

• つまり、シナリオで用意した以外にも、お金の組み合わせや、ジュースの種類があると判断すべきである。

２０１１年１１月１７日


状態遷移図の分析観点：システム

• お金の投入毎処理するのか？「お金が投入された」は、不定期なイベント

連続投入された場合は、高速な応答性が要求される。

状態遷移図のような高度な制御を、高速起動させるべきではない。

• 対応方法投入金額を高速計算する部分を外部に作る。

状態遷移は、定期的に外部へ総額を問い合わせるだけにする。

正しい状態遷移図は

正しい、システム設計の元で成立する。

２０１１年１１月１７日


AUTOSARソフトウェアプラットフォームの概念

XX制御

コンポーネント

XX制御

コンポーネント

何をアプリケーションとして何をシステム側とするのか

構造的な設計思想が必要。

高負荷・低速・定期的な処理

不定期あるいは、高速な処理

２０１１年１１月１７日


自動販売機の動作例

• 自動販売機の「状態」は、「動作の異なるポイント」として考えると、3つに切り分けができる。– 初期状態（待機）、お金のカウント（金額チェック）、ジュースの取り出し（排出）。

待機

排出

金額のチェック

[50円]

[50円] [50円]

意味

合計50円

意味

合計100円


意味

合計150円


意味

合計200円[100円]




返金50円


[100円]

[100円]

金額チェック

[50円]

２０１１年１１月１７日


タイマ成立遷移条件２

初期状態遷移先

お金の排出条件動作

状態名

内部メモリを初期化

初期状態

排出終了

対象商品を点滅させる

ジュースの取り出し

ボタンが押される

金額が満たされる

対象商品を点滅させる

お金のカウント

コイン投入

遷移条件1

ジュースの取

り出し遷移先

条件動作

遷移条件１

ボタン動作待ち

遷移先

条件動作

条件動作

遷移先

遷移条件1初期状態

表で整理して、状態遷移図へ

表を使って情報を整理し、状態遷移図へ変換する

状態遷移表は、STMだけではない。仕様検討用の表はもっとシンプルな物を使うべき。

必要最低限の事を表に書き込み、整理する。

思考速度を落とさないシンプルさが重要。検証用の表と、設計用の表は異なる。

初期状態

排出

[コイン投入]

[ボタン]

お金のカウント

[タイマー]

金額はこの中で

問い合わせ

２０１１年１１月１７日


状態遷移の書き方

• 状態遷移図は、シナリオ表現、仕様の表現とさまざまな使い方があり、「状態」と「記憶」の区別が必要であることを説明した。

• 更に状態遷移図は記述方法についても、制限が必要である。

• 状態遷移図は、自由度が高く、さまざま書き方ができる。そのため、他者からの理解度が低く、理解するのに時間が必要なケースがある。

• しかし、書き方を限定することで、他者からの理解度を上げる事ができる。

• アイシンAWでは、書き方を２種類に限定した。

２０１１年１１月１７日


状態遷移図の記述ルール制定について

• アイシン・エィ・ダブリュでは、1995年から状態遷移表を用いた制御開発を行ってきた。当時から拡張された意味論を使用しており、現在のStateflowと同等である。（ムーアーをベースにハレルヤ以上の拡張がされていた）

– 状態の階層化、並列化が可能

– イニシャライズと通常実行の区別– 遷移条件と条件アクションが使用可能

– 自己遷移、インナートランジションが使用可能– タイマーによる強制遷移が標準ルール残念ながら、自動生成ツールではない。⇒Stateflowへ

• 表⇒図：状態遷移図の描き方は、15年間の状態遷移に関する設計的な考え方を継承している。

２０１１年１１月１７日


A型：ウォーターフォール型状態遷移図

状態は上から下に流れるように、記述する。

下へ遷移する条件は

左側へ記述する。

遷移条件は真ん中より

上側へ記述する。遷移線よりも左側に

記述したほうが

全体のバランスが良い。

状態の大きさには意味は持たせない。状態の大きさが状態の優先度を示したり、

状態の重要度を示す事はない。

初期、中期、終了の３つに分けて図を描く初期

中期は、初期遷移から流れる

系統で並列に並べて描く

終了

上へ遷移する条件は

右側へ記述する。

遷移条件は真ん中より

下側へ記述する。遷移線よりも右側に記述したほうが

全体のバランスが良い。

リセット

制御は、不安定から安定へ⇒ウォータフォール同様、上流に戻すのはリスクがある

２０１１年１１月１７日


B型：多状態・多遷移

hasChange(ST)状態変数をチェック

状態変数と一致した

状態へ遷移する

function f1

function f2

function f3

function f4

function f5

{function f1}

{function f2}

{function f3}

{function f4}

{function f5}

[in(A)]

i[n(B)]

[in(C)]

[in(D)]

[in(E)]

A

B

C

D

E

[ST==A]

[ST==B]

[ST==C]

[ST==D]

[ST==E]

２．遷移条件が多い場合は、

パラレルチャート化し、外へ出す。

１．インナートランジションを活用し

遷移線をまとめる。

２０１１年１１月１７日


A,B混在型：状態遷移図の描き方

• 状態遷移図は、A型ウォーターフォール型を基本に多遷移のB型を組み合わせ事で全ての表現が可能。状態遷移は適切な記述を行えば、爆発しない。

２０１１年１１月１７日


具体的な事例説明

拡張階層構造化状態遷移表設計手法 Ver2.0

状態遷移表から状態遷移図へ変換する

参考資料

P54から

２０１１年１１月１７日


B型を使った状態遷移表現

MainS2

S0

S1

ON

S2

S3

S4

S5

S6

S7

S8

S9

subCartMainS1

function

fcn_ S2

function

f cn_ S3

function

f cn_ S4

function

f cn_ S5

function

f cn_ S6

function

f cn_ S7

function

f cn_ S8

[Button==E1]

[Button==E0]

[Button==E2] [Button==E3]

[Button==E4]

1

[hasChanged ( enum_ MainS) ]

2 [enum_MainS==S3]1

2

[enum_MainS==S4]1

2

[enum_MainS==S5]1

2

[enum_MainS==S6]1

2

[enum_MainS==S7]1

2

[enum_MainS==S8]2

1

[enum_ MainS==S9]

[in( MainS.S2) ]{fcn_ S2( ) ;}

1

2

[in( MainS.S3)]{f cn_ S3( ) ;}

1

2


1

2


1

2


1

2


1

2


1

2

1

2

表どおりの遷移条件を記載する

遷移しない場合も記述は、

何もしない事を示すために記述だけ残す。

B型は、状態遷移表と1対1で全てのケースを表現できる。表の段階で、最適化されていれば、それをB型でそのまま表現できる。

本当は、⇒9 も同一に描けるが、録音は、特殊操作として分けた

２０１１年１１月１７日


A型で表現：インナートランジション活用

インナートラインジションでまとめられる遷移を一箇所で集約

２０１１年１１月１７日


A型で表現：状態の考え方がおかしい部分

状態遷移表の指定どおりに

変換すると、状態定義がおかしいところがある。

外部から、子の状態へ直接遷移する遷移ができる場合は、

状態の考え方がおかしい

状態内部は独立性が必要！

２０１１年１１月１７日


A型で表現：親子依存関係の見直し

親から子への直接遷移を防止した場合

赤枠の中に状態が８個

独立性を保持した状態遷移ただし、状態数が多く、

同じような制御内容の状態が

複数個あるのがわかる。

２０１１年１１月１７日


A型で表現：状態を記憶に変更

早送り、逆送りは、速度が異なるだけで、

状態ではないと定義した場合

赤枠の中は、状態が２個

２０１１年１１月１７日


実際の教育方法について

• 状態遷移図は、分析、整理する事で、A型、B型によって表現が可能である。

• しかし、状態遷移図の描き方を限定しても、多様な状態表現が可能である為、ルールの徹底には教育しかない。

• しかし、描き方を制限するような教育は教え方を誤ると、受けいれてもらえず、効果がでてこない。

２０１１年１１月１７日


実際の教育方法について

• 教育内容を肯定的に受け入れさせる点を注意しなければならない。

• 自らが書いた状態遷移図を、強制的にフォーマットに従った書き方に変更させると、最初に自分が書いた図の方が理解度が高いと感じるので、反感を買い、教育効果が薄まってしまう。

• フォーマットへの変換方法を指導する場合、他人が書いた状態遷移図を共通フォーマットへ変換する演習を行うべきである。

２０１１年１１月１７日


演習例

問題点：横型になっている。

状態の中にある状態へ他の親から子へ直接遷移している。

修正点：縦型に修正。

Waitは使用していないので、

削除する。

この教育では、状態遷移図の制御内容は簡単に説明するが、

内容を正確に理解する部分には力を入れない。形の修正を学ぶところに力を入れる。

形を修正してから、状態の流れを理解してもらう。

２０１１年１１月１７日


B型適応例

変更前先ほどの状態遷移図をよく見ると、

同一条件で状態変化しているので、B型で描けば、最小化される。

全ての状態へ遷移線があり、

ディフォルト遷移の場所がおかしい

標準フォーマットの教育他人の作った状態遷移図を標準フォーマットに修正する演習を繰り返す

A

A

BB

C

C

C

B

A

２０１１年１１月１７日


最後に、形式手法の使いどころ

1. 「シナリオ表現」として設計した状態遷移図に形式検証を行っても意味がない。

2. 制御系では、必ずタイマーによる強制終了の遷移を作る事を心がけます。従って、デッドロックの検査は必要ありません。

3. 「要求の例外検証」を形式検証によって調べる場合、命題を作るのが非常に困難で、実際には使われません。

4. 状態遷移図は、一度作ったものを必ず分析し、最適化され、図が変更されます。最適化前後のモデルの振る舞いが同一であるか形式検証によって一致性検証を行うと効果が高くなります。

２０１１年１１月１７日


形式検証

最適化前

最適化後

出力結果の一致性をSimulink Design Verifierを用いて形式検証で調べる。

１．フルカバレッジのテストは、時間もかかる。形式検証で一致性を確認すると、検証時間を節約できる。２．第3者がモデルを変更した場合、見た目や、動作結果だけで、最初の設計者に説明するだけでは、なかなか変更を受けいててくれないが、形式検証によって一致性が証明された事を伝えると、設計者が簡単に納得してくれる。

２０１１年１１月１７日


状態遷移の使い方まとめ

• シナリオ表現として使われている場合がある。– シナリオ表現は、そのままでは、仕様ではない、ソフトウェアに実装することはできない。

– 分析・最適化が必要である。

• 分析・最適化（きちんと設計すれば、状態爆発は起きない）– 記憶と、状態を区別する。

– インナートランジションを活用し、遷移線をまとめる。

– パラレルチャートを活用し、状態数を削減する。– 図は、決まったフォーマットに統一する事を心がける。

• 形式手法は– 最適化を標準として、最適化前後の振る舞い一致性検証を行うとその威力を発揮できる。

• 状態遷移を使いこなすには、教育が必要である！

状態遷移の種類と形式検証の使いどころ · 2011年11月17日 aisin aw co., ltd. all...

Documents