組込みシステムにおける 外部環境分析の提案

15
1 組組組組組組組組組組組 組組組組組組組組組 組組組組組組組組組 組組組組組組組 組組組組組組 組組 組組 組組 組組 組組 組組 ( 組 ) 組組 組組組組組組組組組組組組 組組 組 組組 組組

Upload: nikita

Post on 18-Jan-2016

34 views

Category:

Documents


1 download

DESCRIPTION

組込みシステムにおける 外部環境分析の提案. 九州工業大学大学院 情報工学研究科 情報科学専攻 金川 太俊、瀬戸 敏喜、鵜林 尚靖 ( 株 ) 東芝 ソフトウェア技術センター 鷲見 毅、平山 雅之. 研究の背景. 様々な環境で動作する組込みシステムは、置かれた環境に応じて動作する必要があり、分析者はシステムの動作環境で起こりうる異常動作を想定しなければならない システムの動作環境を分析する必要がある 本研究では、外部環境の影響により発生する異常動作を体系的に抽出する手法を提案する. 組込みシステムが受ける外部環境からの影響. - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 組込みシステムにおける 外部環境分析の提案

1

組込みシステムにおける外部環境分析の提案

九州工業大学大学院 情報工学研究科 情報科学専攻金川 太俊、瀬戸 敏喜、鵜林 尚靖

( 株 ) 東芝 ソフトウェア技術センター鷲見 毅、平山 雅之

Page 2: 組込みシステムにおける 外部環境分析の提案

2

研究の背景

様々な環境で動作する組込みシステムは、置かれた環境に応じて動作する必要があり、分析者はシステムの動作環境で起こりうる異常動作を想定しなければならない

システムの動作環境を分析する必要がある

本研究では、外部環境の影響により発生する異常動作を体系的に抽出する手法を提案する

Page 3: 組込みシステムにおける 外部環境分析の提案

3

組込みシステムが受ける外部環境からの影響

外部環境からの影響• 制御対象に影響を与え、制御 

 結果を変化させる• 観測対象そのものに影響を与え

これらを考慮して、異常動作の抽出を行う

システム

新たに考慮されるオブジェクト

観測/制御対象

直接観測/制御できないオブジェクト

影響

影響

ハードウェア

センサ観測/制御対象

アクチュエータ

ソフトウェア本研究では、センサとアクチュエータを用いて観測・制御を行い動作する組込みシステムを対象としている

Page 4: 組込みシステムにおける 外部環境分析の提案

4

ライントレーサによる具体例

ユースケース:走行する(右エッジをトレース)《正常系シナリオ》 光センサにより、直下部の反射光を観測し光センサ値がライン上を示すならば右旋回、ライン外を示すならば左旋回を行う

ユースケース:走行する(右エッジをトレース)《例外系シナリオ》?

コースアウト

コースアウトの要因は、ハードウェアの故障?風?照明?

フレーム問題

コースアウトする例外系シナリオを考える

思いつきに頼って要因を考えると、必要の無いものまで考慮してしまう

Page 5: 組込みシステムにおける 外部環境分析の提案

5

提案する手法の狙い

システムに影響を及ぼすオブジェクトを抽出したいが、思いつきで抽出していたらフレーム問題に陥る→ 抽出の基準を定めなければならない

システムの観測・制御対象に注目し、それらに影響を与える外部環境内のオブジェクトを抽出する→ これらの集合をコンテキストと定義する

Page 6: 組込みシステムにおける 外部環境分析の提案

6

手法の位置づけ本手法は、下図に示すように、要求分析終了後に使用されるよう位置づけられている.従って、システムの動作仕様や、ハードウェア仕様などは要求分析により既に明らかになっているものとする. eUML などの既存の開発プロセスに組み込んで使用することが出来る

要求分析

実装

設計

テスト

本提案手法

例外系シナリオ

Page 7: 組込みシステムにおける 外部環境分析の提案

7

手法の概要

1. コンテキスト要素の抽出

「観測対象」、「制御対象」、それらに影響を与える「外部環境内のオブジェクト」を抽出する

2. コンテキストの状態分析

システムの動作はコンテキストの状態によって決まる.その状態は各コンテキスト要素の状態を組み合わせたものである.そこで、それらの状態遷移を明確にする

3. システムに対する制約の分析

コンテキスト要素が、システム内部でどのように扱われているかを明確にし、そこから制約を導き出す

4. 例外系シナリオ作成

今までの結果を用いて、例外系シナリオを作成する

分析

分析結果の活用

Page 8: 組込みシステムにおける 外部環境分析の提案

8

Ⅱ 分析結果の活用ユースケース:走行する(右エッジをトレース)正常系シナリオ「直下部の反射光:強」ならば左旋回、「直下部の反射光 :弱」ならば右旋回

前提 1 光センサ値 >0x30⇒ 直下部の反射光:強前提 2 光センサ値 <0x22⇒ 直下部の反射光:弱前提 3 環境光:弱

手法によって、環境光が「光量:弱」から「光量:強」に状態遷移したときのシステムへの影響も分析しているので、次のような例外シナリオが作成できる

前提 3 を逸脱した場合:環境光:強→ 直下部の反射光が影響を受け、直下部の反射光:弱のときに直下部の反射光:強の処理を行なってしまう.つまりライントレーサがライン上にあるにもかかわらず、ライン外のときの処理が行なわれる

手法により新たに抽出

Page 9: 組込みシステムにおける 外部環境分析の提案

9

抽出した例外系シナリオ

外乱による転倒 環境光によって直下部の反射光の光量が変化する

ラインの勾配によりライントレーサの速度が変化

するラインの曲率がライントレーサの走行可能範囲を

超える

ラインの曲率は走行可能範囲であっても事前のステアリングの角度により転

倒する

手法による抽出

テスト時に抽出

分析時に抽出

分析者の思いつきによる抽出

テストによる抽出

Page 10: 組込みシステムにおける 外部環境分析の提案

10

まとめ手法適用による期待効果 オブジェクト抽出の基準を定めるため、フレーム問題に

陥ることが無い 例外系シナリオ作成までのプロセスを提供する

今後の課題 抽出にノウハウが必要である例外系シナリオに関しては、ノウハウデータベースを蓄積しなければならない

Page 11: 組込みシステムにおける 外部環境分析の提案

11

コンテキスト要素の抽出

外部環境

ソフトウェアシステム

環境光

《制御対象》ライントレーサのステアリング方向

光量を変化させる

《観測対象》直下部の反射光

反射光を検知

ステアリング方向を制御

外部環境

ソフトウェアシステム

環境光環境光

《制御対象》ライントレーサのステアリング方向

光量を変化させる

《観測対象》直下部の反射光

《観測対象》直下部の反射光

反射光を検知

ステアリング方向を制御

直下部の反射光 ステアリング方向<< 観測対象 >> << 制御対象 >>

光量 [連続量 ] 方向 [ 右|左 ]

それぞれの保持している値に注目

その値を変化させるものを抽出

環境光

クラス図にまとめる

外部環境内オブジェクト

Page 12: 組込みシステムにおける 外部環境分析の提案

12

コンテキストの状態分析

No

ソフトウェアの遷移条件

1直下部の反射光「光量:強」 ∧ 環境光「光量:強」

2直下部の反射光「光量:弱」 ∧ 環境光「光量:強」

3直下部の反射光「光量 :強」 ∧ 環境光「光量:弱」

4直下部の反射光「光量:弱」∧ 環境光「光量:弱」

環境光考慮前

1,2,3

4

環境光考慮後

環境光を考慮して遷移条件を見直す

Page 13: 組込みシステムにおける 外部環境分析の提案

13

システムに対する制約の分析

コンテキスト要素 状態 対応ハードウェア 内部表現 制約

直下部の反射光光量:強

光センサ センサ値 255段階表現光量:弱

ステアリング方向左

ステアリングモータ 左 / 右 なし右

環境光光量:強

なし なし なし光量:弱

システムでの内部表現の明確化

コンテキスト要素 システムによる状態の把握

直下部の反射光

光センサ値 >0x30⇒光量:強

光センサ値 <0x22⇒光量:弱

システムがコンテキスト要素の状態をどのように把握しているかを明確にする

Page 14: 組込みシステムにおける 外部環境分析の提案

14

例外系シナリオ作成ユースケース:走行する(右エッジをトレース)正常系シナリオ「直下部の反射光:強」ならば左旋回、「直下部の反射光 :弱」ならば右旋回

前提 1 光センサ値 >0x30⇒ 直下部の反射光:強前提 2 光センサ値 <0x22⇒ 直下部の反射光:弱前提 3 環境光:弱

ユースケース記述に、

前提条件を追記(正常系シナリオでは環境光からの強い影響は無いものとしているので「弱」となる)

これらの前提を逸脱するケースを考える

「環境光:強」のときは?

直下部の反射光:強になり、システムは車体がライン上にあろうとなかろうと左旋回を行う

Page 15: 組込みシステムにおける 外部環境分析の提案

15

質問、指摘された点

外部環境の定義 外部環境をモデリングしたとは言えないはず

状態分析の意義 無くてもいいのでは?

この手法を使えば本当に網羅できるのか?