• 検索結果がありません。

4

章、5章

• 4,5

章は、1日の講習で終えるように構成しました。その

ため教える知識を必要最小限に絞り込んでいます。

4章については、自社ではもっと広範囲の操作を教えた いという場合は少し構成を変えてください。

この章は、マスワークス社の開催する講習「自動車分野 向け

Simulink

基礎」で代用することもできます。

4

章を 別で代用した場合、

5

章から始めてください。

5章は、フィードバックというモデリングの基本と、シミュ レーションの基本的な知識を習得します。

「自動車分野向け

Simulink

基礎」は、

2

日間の構成で、

6

自動車の一輪車モデルといわれるもっとも簡単なシミュ レーションモデルを設計します。

ここでは、以下の習得を目指しています。

– Simulink

の操作を習得する。

モデルのテスト方法を習得する。

簡単なモデリングルールを習得する。(パラメータ名、信号名 を付ける。)

大きなモデルも構造化する(あるいは分割して作る)こと で自分でもモデルを作れるという成功体験を与える。

• 6

章が模倣、8章が実践と育てる過程の途中です。

チームで、テストケースが正しいのか議論させましょう。

6章:モデリング習得手順 レベル1を目指す

最初に与える要求はシンプルなの方がよいです。ここ では、簡単な物理現象のモデリングを教えます。

すべての物理式は高校物理程度の難易度の低いもの です。

要求を見て、どんな機能が必要か理解し、テストケー スを考えていきます。上級者の考え方を模倣しながら 作業を進めることでモデリングを理解していきます。

• 300

ブロック前後のモデルを作り上げるところが終了目 標となります。

演習を自動車でやりたくない人は

教育担当者へ、自動車以外のドメインにしたい

→必要でしょうか?

• 6

章は、モデリングの手法を教えています。要求をどう やって理解し、テストで何を見るのか、そういった考え方 が書かれています。

つまり、物理式を使ったモデリング手法で、

「線形の数式、非線形の数式をどのように理解して、設 計、テストを行うのか」

これはドメインが異なっても共通の技能です。

教えているのは共通技能

新たにドメインを変更したテキストを作っても、ドメインの 技術要素スキルが異なるだけ。習得できる開発技術の 技能にそれほどの違いはありません。

このテキストは、

Simulink

だけでなく、要求の理解、検 査まで含めた開発技術の技能習得が目的です。

そもそも、車両モデルというドメインに対する技術要素

の習得が目的ではなく、手段して採用しているだけです。

車両モデルという技術要素は、新たな技術領域ではなく、

物理を知っている人なら誰でも理解できる技術要素とし て簡単な領域を選択した結果です。

7章

制御モデルを設計するための基本的な機能の作り方と 習得ブロックの種類を増やす事を目的にしています。

ここも1日で講習が終わるようになっています。最初の

4

章に対しては、操作を行う部分を減らし、読み物として 知識だけを提供する部分が多くなっています。

ここで、新たなブロック以外に、最適化の手法や要求を 読み解く基礎的な手法を合わせて勉強します。

• 8

章の演習問題でスキルとして習得する色が濃くなって きています。

8章

6

章の模倣に対して、8章は実践です。

要求を理解するために図を描いてもらいます。要求理 解の為の回答例をいくつか掲載していますが、自分で 作業します。チームで、要求の図を説明し、理解が正し いのか議論させます。これによって要求を正しく理解す るためにどのように深堀していけばよいのかが習得でき ます。

この8章のもっとも重要なことはモデルを作ることではな く、要求を理解してからモデルを作るという工程の進め 方を理解し、習得してもらうことです。

9

• 9

章は読み物になっています。

レベル2以上の内容が書いてあり、将来へのスキルアッ プを目指す動機付けが目的です。

最後に

今までの作業に対する報告書を作成してもらいましょう。

まとめることでさらにスキルとしての定着が期待できま す。

最後に、

15

分程度で発表するまとめを行ってください。

まとめの資料を作る中で、自分がどのようなスキルを身 に付けたのか、きちんと理解してもらうことが大切です。

ディスカッションの重要性

前半でお話したとおり

より高い確率でスキルを定着させる取り組み

チームで議論させ、話し合うことによってより深く考え、課題に 対して真剣に取り組みます。

• 6,8

章のトレーニングを一人でやると眠くなるだけ、

3

人ぐ らいのグループでディスカッションを行うことで「考える」

「理解する」「説明する」の要求分析に必要な力が育成 され、モデリングの力が定着しやすくなります。

目次

スキルマップをエンジニア育成に活用するには

– ETSS

とは

技術要素スキルと、開発技術スキルのスキル項目

開発技術スキルのスキル項目

教育の提供

前半まとめ

エンジニア育成事例

– MBD

開発環境エンジニア育成事例

– Simulink

の教育

状態遷移の教育

状態遷移の教育

対象のエンジニア

これから初めて状態遷移制御をはじめたい人

すでに状態遷移をある程度使っている人

教育後の目標

状態遷移を使って、自ら状態を検討できるエンジニア

書籍としては、さまざまなエンジニアを対象とするので、

状態遷移の入り口から、かなり踏み込んだ部分までの 広範囲の知識を提供。

実際に演習問題でスキルを身に付ける為、少し複雑な 演習問題を3つ用意した。

書籍のコンセプト

一般的な状態遷移の本は、ツールの使い方を目的とし た誤った状態定義を用いた状態遷移ツールの使い方に 注目した説明をしている。

今回のコンセプトはツールの使い方ではなく、正しい状 態定義を勉強してもらう事を目的としている。

検証工程にフォーカスするのではなく、要求段階で要求 を膨らませていく状態遷移の使い方。最初にイベントが 決まっているのではなく、状態を定義し、イベントを探し 出して行く状態遷移検討方法を教える。

固定ステップ(一定サンプリング)のシステムを対象とし た例題で説明する。

1,2

基礎知識編

歴史:ミーリー・ムーアのシンプルな状態遷移から説明

ミーリー・ムーアの等価性ではなく、実行タイミングのず れから状態の考え方の違いを説明する。

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

状態変数状態変数 状態変数状態変数

2

状態変数 状態変数 状態変数 状態変数

1

3章 基本操作編

• Stateflow

を使って基本的な操作を中心に図・表の使い 方を説明する。信号機を例題に操作方法を教育する。

3

章は、正しい状態の考え方を勉強する のではなく、ツール習得を目指し、

簡易的な状態で説明している。

新機能:状態遷移表

• R2012b

でリリースされた状態遷移表

図で作ったものと

同じものを表で設計し、

操作を習得する

4章 応用編

内部遷移の活用

相互遷移する状態遷移図

内部遷移を活用した 状態遷移図

b

c

d

[in==2]

{out=2;

1

[in==1]

{out=1;}

2 [in==3]

{out=3;}

2

%デ フォルト(規定)遷移

[in==3]

{out=3;}

1 [in==2]

{out=2};

1 [in==1]

{out=1;}

2

1

[in==1]

{out=1;}

2

% [in==3]

{out=3;}

[in==2]

{out=2;}

2

% 状態遷移 1

状態遷移表

表も同じテクニックを使った場合の操作を説明

相互遷移する状態遷移表

内部遷移を活用した 状態遷移表

5章 状態遷移図の描き方

2種類の書き方を説明する。

全部で11モデルの演習を提供

標準と定めた図への変換は自分が作ったモデルで変更させ ると反感を買い、習得率が下がる。

他人が作ったモデルで演習を行う。

– MW

のデモモデルを使った演習を行う。

正しい書き方を覚えることで、

全員が同じルールでモデルを書けるようになる

6章:

• Stateflow

Mealy

モードと

Moore

モードの説明

内部遷移の活用で 複雑化する例を説明

安全性の高いシステムを 設計するには、

安易に

Mealy

モードを使う 事ではなく、意味論を

正しく理解する事と

くどくどと説明している。

7章 演習問題

3つの例題を使った演習です。

正しい状態を定義するため要求分析から実施

要求分析のために、タイミングチャートを沢山書いてもらう。

作成する図は、状態遷移図よりもタイミングチャートの方が多 い。

実装される状態遷移とシナリオ表現で使った状態遷移 の違いを確認しつつ、タイミングチャートを使ったシナリ オ作成方法と、要求図から状態遷移を設計する分析方 法を習得する。

誤解してはいけない注意事項

図や表は、人の好みです。どれが優れていると言うこと は絶対にありません。本書ではどの図が「良い、悪い」

を指摘しているわけではありません。

そもそも、万人が必ず同じように理解できる図や表はあ りません。使う工程、使う人、使う対象によって好きなも のを使えば良いと思います。図や表は、特に使うプロセ スによって得手不得手があります。要求から設計・検証 と徐々に形が変わっていくことはごく自然なことです。

状況やユーザーによって色々な図や表を使い分けるこ とを提案しています。

関連したドキュメント