MBDの裏表」 - IPA

©AISIN AW CO., LTD. All Rights Reserved.

「MBDの裏表」3月12日 15:40～16:20

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

解析技術部

主席研究員久保孝行


1

講演分野の説明

基本情報

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

設立 1969年5月15日

資本金 264億8,000万円

代表者取締役社長川本睦

売上高連結：9751億円

単独：8850億円 (2013年3月期)

主要製品オートマチックトランスミッション、ハイブリッドシステム、カーナビゲーションシステム

従業員数連結 22,134名（2013年3月31日現在）単独 13,837名（2013年3月31日現在）

本社所在地

〒444-1192

愛知県安城市藤井町高根10番地0566-73-1111（代表）

アイシン・エィ・ダブリュ「技術センター」

A/T・H/Vの設計で使うMBDの説明


2

目次

1. モデルベース開発とは

2. MBD導入背景

3. 事例：HILS構築

4. 教育への取り組み

5. 制御設計への展開


3

モデルベース開発：モデルとは

モデルとは数式群のことです。

Input

Output

- ギヤの数式 -

回転：Revout = Revin / rトルク：Trqout = Trqin× r Revout ：出力回転数

Revin ：入力回転数Trqout ：出力トルクTrqin ：入力トルクr ：ギヤ比

Modeling

Gear

モデルの種類

1. Plant model

- Transmission

- Motor

- Engine

- ・・・

2. Control model

ー H∞ Control

ー Self learning Control

ー Adaptive Control

ー・・・Δ

P

＝


4

MBDの領域：Vプロセスとの関係

HILS

制御モデル

ソースコード自動生成

設計検証

MILS

RCP

実車評価

実車評価

MILS

HILS RCP

ソースコード検証

仮想世界

実世界

制御対象モデル

制御対象（Plant）モデル

実制御（Control）電子制御ユニット

制御対象（Plant）車両、ｴﾝｼﾞﾝ、AT

制御（Control）モデル

ソースコード自動生成Automatic C code Generation

モデルによる仮想評価

モデルによる実車評価

シミュレータによる評価


モデルベース開発：メリット

設計評価

設計従来

MBD

不具合発生時の手戻り工数大



要求分析


単体評価


実車評価

要求分析

単体評価

結合評価

実車評価

S/W設計書作成

制御仕様書作成

手作業による制御プログラム作成

制御ソフト開発工程

不具合発生減

モデル作成

ソースコード生成準備

• 設計段階でシミュレーションが活用できることにより、手戻り工数の削減と制御ソフトの品質向上を同時に達成できる

• ソフトウェアを自動生成できるため、第３者の誤解なくソースコード作成できる。

評価設計

手戻り工数小


6

MBDはモデルベース開発の意味

Model-Based

VerificationModel-Based

Design

モデルベース開発MBD

（Model-Based Development）の意味Model-Based Designはモデルを使った設計工程だけモデルベース開発は、モデルを使った検査・検証まで行うModel-Based Verificationを含む。MBD=Model-Based Design+ Model-Based Verification

設計評価

注：この表現は存在しないモデルを用いた開発ループ



要求分析


単体評価


実車評価

不具合発生減

モデル作成

ソースコード生成準備

手戻り工数小


7

目次


2. MBD導入背景





8

0

512

1024

1536

1996 1998 2000 2002 2004 2006 2008

MBD導入の背景

MBDの導入は、HILSの採用から

きっかけは、世界初のFF5速A/Tの開発

2002

FF5AT

20041996

製品化

ソフトウェアはますます肥大化し、検査時間が増大してきた。

HILS

モデルベース開発の中のHILS装置に注目しました。

1998

8倍

4A/T 5A/T

数倍に増加

ソフトウェアサイズ

4AT

5AT

１号機導入

2000

4倍


多段A/Tの大きさ比較

9

４速

５速

６速電子制御の向上とギヤトレーン方式に変更により6速A/Tは、4速A/Tよりもコンパクトになった。


導入背景：ATの機能変更

• 従来の制御 • 新しい制御

10

従来は、機械式のアキュームレータを用いた機械制御。新方式では、専用のアクチュエータを持った電子制御。

多入力1出力従来は、油圧の高さを決める値がコントロール可能パラメータ 1個

多入力多出力新方式は、すべて自由自在。パラメータ 100以上

解放側は、OWCが担当係合、解放両方を制御


事例：HILS構築へ

• 新制御では、

自由度の高い制御が可能な

反面、検証すべきパターンが

非常に多かった。

特に変速制御中に別の変速に移動する

多重変速制御の検査は困難を極めた。

再現が難しく、実機では検証が不可能。

11

シミュレーションの活用が望まれた。

HILS装置の開発へ

途中で切り替わる


12

目次


2. MBD導入背景




２０００年ごろにHILS装置の採用！

2002

FF5AT

20041996

製品化

HILS

1998

１号機導入

2000

FF6AT


オートマチックトランスミッションのモデリング

• 回転系の計算：Dymolaを使ってモデリング

流体系はSimulinkで数式を直接表現

- 13 -

GUIの組み合わせだけでプラネタリ-

などを数式化できる。


AT全体で様々な部品を作る

14

A/T ASSY

V/B

Gear Train

調圧式

流体特性

温度特性

Oil Pump

Planetary Gear

Drive Shaft

Clutch / Brake

Other Gears

Valve

Accumulator

On/Off Solenoid

Linear Solenoid

Orifice

トルク伝達方程式

摩擦特性

温度特性

トルク効率（損失）

振動

引きずりトルク

流体特性

温度特性

摩擦特性

振動

トルク伝達方程式

T/C

Lock Up Clutch

Converter


パラメータ同定試験の例

• クラッチに油圧を流し、ピストンが摩擦材に接触するまでの時間を計測する。

15

様々な油圧の高さで、様々な温度で測定が必要。

製品には、油圧センサーはない。穴をあけたり、部品をカットして、自由に動いても試験ができる専用A/Tを作る。

実験データからパラメータを導出• 流量係数• オリフィス径• 油圧応答性


AT以外も設計する

16

インターフェース

A/T

CAN

E/G

ディスプレイ

ドライバー

環境設定

イグニッション

車両としての機械運動のモデル以外に、エンジン、ABSなどのA/T以外のECUソフトウェアも設計しなければならない。


HILSの効果があった実施例

• コーストダウン中の踏み込み試験

時速50～60km/hの定常走行からブレーキを踏み、時速20～30km/hに車両速度を下げて、再度加速する。

– 制御ステート切り替えと言う僅かな時間の間にスロットルペダルが踏み込まれた場合のショック改善

• パターン解析前実車発生率0.001%

• パターン解析後実車発生率5%

• HILSを用いた評価？％

ペダル

再現率100%

実車だけの場合、対策の効果があったのか再現しなかっただけなのか判断できない。


HILS採用の第２ステップ

第２ステップ：HILSを導入から、HILSの定着へ

• 取り組み内容の例

– 最新プロジェクトへの対応

• 人員の教育

– 環境の統一

• 異なる拠点でも最新のモデルが提供できる。

– 安心して使える

• 定期点検の実施。

18

HILSを導入して終わりではない。新しい仕組みが定着するまでの仕組みが必要です。


モデルの世界配信のイメージ図

HILS system

HILS models

タイムラグなく、全世界で共通のバージョンで検査ができる。


HILSの定期点検

• HILSはソフトウェアの検査装置なので、定期的な点検が必要です。

– 故障スイッチが故障していたら、検査はできない。

20

メンテナンス

入れ替え

機能拡張

掃除

OSアップデート


HILS他社導入事例

• 自動車メーカー

車両全体HILSの活用

• ホンダ技術研究所、三菱自動車等

• 他業界

– 特殊車両

– 鉄道

– 電力系

21

HILSは、MBDの入り口として、今後も様々な業界で使われるようになる。


22

目次


2. MBD導入背景





23

MBD教育の流れ

• 教育1

1. 講座：制御理論と共に、MATLABのコマンドを教育。

2. 講座：Simulinkを使った教育

• 教育2

1. 制御理論の教育をやめた。

2. 講座：Simulinkの使い方だけに絞る

• 教育3


2. 演習：操作演習を取り入れる

• 教育4


2. 演習：操作演習を取り入れる

3. 図を書かせる、ディスカッションを取り入れる。

講座期間短縮定着効果のアップ

教育後に直ぐにモデルが書ける。


24

教育の変更理由

課題：新人：上手に使えない。中堅：スキル習得にばらつきが多い。

新人教育３でも使えない。→

Simulink以外の基礎力がなく、開発全体の流れが解っていない。

中堅・演習量の不足によるスキル未定着→教育３で解決・その後をOJTに、依存しているので基礎より上のスキルが身に付いていない。（新たな問題）

原因

新人・中堅で異なる教育が必要


25

アイシンG共通MBD教育実施について

アイシンG連携教育4の取り組み

• 自社だけでMBD教育を拡充するのは、困難。

• アイシンG連携で、

MBD教育の環境を用意した。

アイシン・エィ・ダブリュ

アイシン・エーアイ

アドヴィックス

アイシンエンジニアリング

アイシン・コム・クルーズ

アイシン精機


26

2013年度新設新人用教育講座

コンセプトアイシンGr.各社で実施しているMBD教育を集約しMBD教習所を設置

ツールを使いこなせる技能を習得できるコースを設定する。

目標部署に戻ってからのOJT時間を極力減らすために

「モデル設計スキルレベル１」を完了しレベル2の途中まで育成する。

【スキルレベルの定義】

モデル設計スキルレベル１：

• シミュレーションを実行し、検査ができる。

• Simulink, Stateflowを用いて、指定された機能を、

指示された方法で実現できる。（使用するブロック、構造など、ヒントあり）

モデル設計スキルレベル２：

• Simulink, Stateflowを用いて、指定された機能を、

自らの判断で実現できる。（使用するブロック、構造など、ヒントなし）

スキルレベル３

• 最適な方法を自ら判断し、コード生成可能な完全なモデルを設計できる。


27

トレーニングテキスト


・新入社員向けに20日コース

内容形式日数該当箇所

Simulinkレベル1 講習講座 1.5 1章、2章、3章、4章、5章

Simulinkレベル1演習自習 3.5 6章

Simulinkレベル2 講習講座/自習 1 7章

Simulinkレベル2 演習グループ 6 8章、9章

Stateflow講習講座 1.5 1章、2章、3章、4章、5章

SF演習グループ 4.5 6章、7章

ガイドライン講習講座 1 20項目のIDを学ぶ

振り返り、資料作成自習 0.5 -

発表会講評 0.5 -

※青字は講座形式

アイシンG合同MBD教育日程

１２日

６日


29

研修のほとんどは考える力の育成

全体のカリキュラムで、

Simulink操作技術を教える部分は2割程度。

知識以外に演習ベースで操作を習熟させる必要があるが、その時に、Simulinkの操作習熟だけでなく、考える力の育成に費やす。

考えを補助する図・表の説明・演習

整理手法の説明・演習

適度にディスカッションを取り入れ、知識の押し付けではなく、自ら考える力の育成を重視。


30

MBDの新人教育は「Simulinkの操作」以外の教育が大切

要求の理解方法・要求の育て方を学ぶ

• ユースケースの抽出と、タイミングチャートによるユースケースの表現、その分析手法を勉強します。

• チームで、ユースケースの説明を実施。理解が正しいのか議論する。これによって要求を正しく理解するためにどのように深堀していけばよいのかが習得でき、他者と議論する為に図が重要である事が認識されます。

設計手順・手順の重要なポイントを学ぶ

• 要求を理解してからモデルを作るプロセスの習得を目指す。

要求をしっかりと定義するため、タイミングチャート作り、それをテストで活用する。

シミュレーションによって検査・検証のプロセスを体験する。

テストファーストの重要性を学ぶ。


31

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

教育に、ディスカッションを取り入れる

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

どんな話題でディスカッションするのか？• 要求

•システムの把握：何が入力で何が出力か•機能の把握：どんなユースケースがあるか

• 検証•どんなテストをしなければならないか

一人で黙々と演習を行うよりも時間が必要となるが、定着率まで考慮して、コースの時間を設定する。

3人ぐらいのグループでディスカッションを行うことで「考える」「理解する」「説明する」の要求分析に必要な力が育成され、

モデリングの力が定着しやすくなる効果がある。


32

受講者が作成したタイミングチャートの例


33

修了証書

研修の習熟度を測るため、研修中に課題を提出してもらいます。

【修了証書の発行条件】以下のモデルを作成、修正。

カテゴリ章内容

Simulink 第8章クルーズコントロール制御

Stateflow 第7章再生プレイヤー

ガイドライン - ガイドラインモデルの修正

きちんと受講した人はほぼ100%が完了講座のみ受講した人は、100%がモデルの提出ができなかった。

想定通りの結果。


34

受講者の声今後の業務で活用できること

• モデルの作り方

• ガイドラインに沿ったモデルの記述方法

• 状態遷移図の作り方

• 状態遷移表の作り方

• 仕様の読み方

• 構造化の考え方

• 仕様を読み解く際に、タイミングチャートを作成し、テストケースを考えること

Simulink以外の力が強化できた事が受講者のアンケートから解った。（狙い通り）


35

Page 35

そもそも制御開発ってなんなの

良くある質問：制御理論の教育をやめて、大丈夫なのか？

企業では、高度な制御理論による精度向上よりも、その他の方が設計工数

が多い。したがって、制御理論を駆使するエンジニアも少数で良い。

MBDに携わるエンジニア全員が制御理論を知っておく必要はない。

（0はダメです。）

それよりも、ユーザー視点で制御開発できる事が大切です。

• 戦略・戦術・行動（動作）上位を意識した制御開発が重要！

「2軸のロボットアームで指定された板に色を塗る。」

で説明


36

Page 36

指定された板に色を塗る制御装置

最も簡単な制御例

ロボットアームの軸をどう動かすか

全てのモータの速度、角度を時間ごとに指定する。

初歩的なシーケンス制御で実現された工作機械の例• プログラムの規模は小さい。• 試行錯誤によってデータを設定する。• 誤差を見込んだデータ設定を行う。• 形が変わるごとに、全てのデータを作り直す。

データを設定して、指定時間に指定位置に移動させて、色を塗る。


37

Page 37

指定された板に色を塗る

最も簡単な制御例

ロボットアームの軸をどう動かすか

全てのモータの速度、角度を指定する。

フィードバック制御を考えよう！

指定どおりにモータを動作させるにはどうする。

二つのモータに対する角速度、角度を用いた２自由度問題。二つを同じ重みでフィードバックすると、目的の位置に制御できない。


38

Page 38

ロボットアームの高度な制御理論

WEB上に幾つかの事例があります。

確かに難しい制御問題です。


39

Page 39

初歩的なシーケンス制御

先ほどの制御では、形が変わるごとに、全てのデータを作り直す。

部品ごとにデータを全て作り出すのは非常に困難

高度なフィードバックの実現が、ユーザーにとって本当に重要なのだろうか？


40

Page 40

ユーザーインターフェースの改善

1. ロボットの先端部分の経路を指定すれば、モータの速度、角度を自動的に計算できるプログラムを追加する。

→ ユーザーは経路を指定するだけで済む

2. 形から、最適な経路を計算し、自動的に経路を計算するプログラムを追加する。

→ ユーザーは、形をCADからコピーするだけ。


41

Page 41

指定された色を塗る

• CADの形を入力するだけの装置と、入力データを入れるの

は大変だが、設定どおりに塗れる装置。同じ開発工数ならどちらが良い製品なのか？

ここで、上位の要求までさかのぼる

上位要求：色が綺麗に塗れれば良い。

下位要求：先端位置を指定の時間に指定の場所に持ってくる。

• 色を塗るロボットアームの角速度・角度のフィードバックを突き詰めれば本当に綺麗に色が塗れるのか？

– そもそも、いつも色は均一に噴射されるのか？

• ロボットアームの位置は、そもそも色を綺麗に塗る為の代用変数でしかないのではないか？


42

Page 42

そもそも何をフィードバックすべきか

• 画像処理して、自動で色を塗る方が良いのでは？

• 画像処理を入れれば、腕の細かいフィードバックは必要ないかも知れない。

ミクロな現象にとらわれず、物事をマクロ的に捉え

本質的には何がしたいのか、上位視点で問題解決すべき

企業の製品開発において、高度な制御理論を駆使する部分は少ない。大多数の人間がその他の開発に従事している。魅力ある製品開発と、高度な制御理論は直結しない。

しかし、現実的には、制御理論を知っている人ほど、MBDで活躍できるという事実はある。だから、制御理論を教えれば、同じような人材が増えると事を期待している教育担当者が多い。


制御工学はなぜ必要なのか？

では、制御理論あるいは制御工学は何を教えているのか。

制御理論のコントローラ設計手法

1. 制御対象を把握し、数式で表現する。

– システム同定→プラントモデルの設計

2. 数式を用いて仕様を検討する。

シミュレーション行い要求を確認する。

– ステップ応答→制御モデルとプラントモデルでMILS

タイミングチャートを使ったり、シミュレーションを活用する事

＝制御工学は、MBDの王道的問題解決手段

• MBDを教える場合には、理論を教えるのが大事ではなく、手法を教える事が大切ではないか？

• そもそも何を教えているのか、教える側が理解しなければ、受講者に重要なポイントが伝わらない。

【高度な制御理論は、選別した人材に教育すべき。】 43


44

目次


2. MBD導入背景




– MBDの採用前に取り組んでいた

制御開発技術の紹介

– MBDの制御導入ポイント

– MBDの制御導入で失敗する例

実例は説明できない。ポイントを抜粋して説明する。


制御開発へのMBD採用：状態遷移表を活用

状態名ラベル名赤、赤 T01 遷移条件前回A：3秒後

A01 条件アクション→ 遷移先 →赤、青

T02 遷移条件前回B：3秒後A02 条件アクション→ 遷移先 →青、赤

赤、青 T03 遷移条件 60秒後A03 条件アクション→ 遷移先 →赤、黄

赤、黄 T04 遷移条件 7秒後A04 条件アクションモードAで動いた→ 遷移先 →赤、赤

青、赤 T05 遷移条件 40秒後A05 条件アクション→ 遷移先 →黄、赤

黄、赤 T06 遷移条件 7秒後A06 条件アクションモードBで動いた→ 遷移先 →赤、赤

45

油圧制御の開発に状態遷移表を活用。

状態遷移表状態遷移図（ハレル形式）

参照元：組込みエンジニアのための状態遷移設計手法

UMLに定義された状態遷移マトリクスとは異なる。検証観点ではなく、要求を作り上げていく事に注目した表状態遷移の概念を採用したのは、HILSよりも先。形式的に表現できるので、仕様の誤解が生じにくい。


R2012bで導入された状態遷移表

• 2012年末にマスワークス社のStateflowに導入された

AW方式の状態遷移表

46

状態遷移表状態遷移図

紙に書いてもシミュレーションできない。（半MBD?）ツール化によって、MBD（シミュレーション）採用になった。


モデルベース開発導入の流れ

47

HILS導入

HILSの定着制御へ展開

自動コード生成

一般的なMDB

導入パターン

制御系への展開は、自動コード生成採用までに様々なハードルがある。

実例は説明できない。ポイントだけを抜粋して説明

• ガイドライン• 開発環境改善ツール• プロセス


MBDの制御導入ポイント（効果を出すために）

• 導入前（準備）

– AUTOSAR等の近年提案されている開発技術は、そもそ

も人がミスを起こしやすい原因を排除するための技術。それらのリスクを低減する取り組みはAUTOSARやMBDを採用することとは無関係に実践すべき。

• 導入初期

– Cソースの事をあまり意識せず、やりたい機能の実現に注視する。RCPの活用が効果的。

– １回の開発プロセスだけに注視せず、Vプロセス全体が無理なく連携し、何回も回せるプロセスの流れを構築する。

ウォーターフロー型よりも、スパイラル型に近い。

• 自動コード生成導入時

– モデルは、抽象化されたものである。従来のC言語のルールや仕組みを引き継つがない。

48


MBDの制御導入で失敗する例

• シミュレーションを活用せず、ソースコードの自動生成だけを採用する。

– シミュレーションを活用しないと、実車評価まで行った後に、要求が変わり、毎回自動生成用のモデルを作り直すことになる。自動生成の採用だけで、工数は削減されない。シミュレーションを活用していないので、品質もあがらない。

• シミュレーション不可能な領域に手を出す。割り込み処理など、Simulinkが苦手な領域です。やっても効果は出ない。

• テストのために、やたらに小さな規模で関数設定をする。

– RAM効率が悪くなる。ツールの特徴を理解せず、従来方式を押しつけても上手くいかない。

→シミュレーションの活用がMBDのキー。それを活用しない、

あるいはできない領域はやるべきではない。ハンドコードの方が良い領域は沢山ある。メリットの出る部分で活用すべき。

49


まとめ

• MBDの導入効果に夢を追い求めるな。

– ツールを採用すれば、それだけで品質が上がり、工数が削減されるわけではない。

– ツールの導入は手段であり、目的ではない。MBDは、ツールの導入ではなく、シミュレーションの導入である。

• 導入して終わりではない

– ツール導入で、MBDが終わるわけではない。新しい仕組みは定着させるために様々な取り組みが必要になる。

• MBDの採用理由は、コストや開発期間の短縮ではない。

– 品質の向上、性能アップが目標で、コストや開発工数の低減はおまけ。正しくやらなければ何もメリットはない。

50

MBDの裏表」 - IPA

Documents

Transcript of MBDの裏表」 - IPA