...

モデル駆動型製品開発 モデル駆動型製品開発

by user

on
Category: Documents
5

views

Report

Comments

Transcript

モデル駆動型製品開発 モデル駆動型製品開発
日本機械学会 設計工学システム部門 第27回 A-TS12-05 設計研究会
モデル駆動型製品開発
エレメカソフト複合製品開発の「ものをつくらない」ものづくり
Requirement
Analysis
SysML-CAD連携
モデル駆動型開発
SoftwareElectronics
Software
Electronics Mechanics
ソリューション一覧
シミュレーション
検証
IT Infrastructure
© 2008 IBM Corporation
1
モデル駆動型製品開発の背景
2
Requirement Analysis
解決1 全体システムを把握抜け漏れのない要求分析
3
シミュレーション検証
解決2 システムレベルでの事前論理検証
4
SysML-CAD連携
解決3 システムモデルをもとに変更影響範囲の確認
5
問題提起
© 2008 IBM Corporation
モデル駆動型製品開発の背景
上流設計の課題
設計変更の75%の原
因は、設計の初期段階
の検討不足
%
‹構想設計段階で、ライフサイクルコストの
66%が決定される。
‹詳細設計では14%に過ぎない
製品の問題、設計変更
の80%は製品開発の
最終段階で発見される
100
100
ライフサイクルコストの確定度合
設計変更の原因
50
設計変更の発生
80
66
0
0
構想設計
詳細設計
実機製作
発生コスト
量産
要求機能のヌケモレ
性能の誤認識
性能不十分
構想設計
総合試験
性能不十分
トライ・エラー
詳細設計
設計ミス
構想設計
詳細設計
製造
保守・回収
単体試験
製造ミス
矛盾した設計
(出所)Life-Cycle Cost and Economic Analysis
実機製作
エレメカソフト製品開発・手戻りの現状
© 2008 IBM Corporation
モデル駆動型製品開発の背景
工業製品の複雑化による影響
①メカ・エレキ・ソフトが密接に関係する
機能開発の増加
自動車設計の例
②組織や領域をまたいだシステム
の開発設計の増大
ボディー
シャシ
操舵
エンジン
運転支援システム(ACC/LKA/PCS)
Software
Electronics
Mechanics
制御システム・DIAGNOSTIC
③ソフトウエア開発量の増大
レクサスLS460
700万行のコード
http://www-03.ibm.com/solutions/plm/doc/content/bin/g510_3987_embedded_systems_overhaul.pdf?g_type=rhc
4
© 2008 IBM Corporation
モデル駆動型製品開発の背景
製品の複雑化にともない顕在化する課題
システム全体の仕様や要件を各専門領域の設計者が把握しきれない
設計変更の影響する領域や範囲がわかりにくい、変更し忘れが生ずる
ソフト開発の比重の高まりに対応する開発プロセスへ変更が困難
エレ・メカ・ソフト設計活動(メカ設計と組込システム設計)の連携が不十分
組込みソフトウエアの課題例
経済産業省:2007年度組み込みソフト実態調査より抜粋
http://www.meti.go.jp/press/20070627001/20070627001.html
5
© 2008 IBM Corporation
モデル駆動型製品開発の背景
現在の設計プロセスと課題
構想設計
課題2 構想設計レベル
での検証が不足
設計要求
顧客要求
構想設計
(メカ設計者担当)
メカ詳細設計
課題1
組込システム担当部門へ
うまく要求が伝わらない
電気回路設計
ソフト設計
詳細設計
課題3 各設計環境で
設計仕様変更の反映
や確認ができない
6
実装
課題4 設計変更の
範囲がどの専門領域まで
およぶかわかりにくい
© 2008 IBM Corporation
モデル駆動型製品開発の背景
モデル駆動型製品開発の提案
‹複雑化する製品をシステムととらえ、「製品の見取図」をもとにした製品開発のフレームワーク
‹構想設計の詳細設計の設計手順に対応した設計モデルの作成
‹要求仕様から製品設計に至る設計情報の展開を支援
顧客
要求
VOC
要求仕様
構想設計
展開
要求
モデル
要求仕様
要求仕様
製品仕様
設計部品
構成
製品機能
目標値
品質
要求
目標値
S2
論理
機能
製品全体機能
を設計し、論理
モデルを作成
S1
S1
詳細設計
展開
物理
設計
実装する部品・
コードを現す物
理モデルを作成
品質
S2
制約
S1
S2
モデル
要求仕様
S1
展開
モデル
製品に対する要
求を分析し要求
モデルを作成
要求仕様
S2
ソフト
SW開発環境
(例:Rational)
ソフト
回路 部品
回路CAD
(例:CADENCE)
物理値
物理値
メカCAD
(例:CATIA)
© 2008 IBM Corporation
モデル駆動型製品開発の背景
モデル駆動型製品開発による協調設計
‹構想設計で、エレ・メカ・ソフトの詳細設計で必要となる顧客仕様、要求、論理モデルを作成
‹詳細設計で、エレ・メカ・ソフト各担当の互いに影響する分担作業の協調設計を実現
顧客
要求
構想設計
展開
製品に対する要
求を分析し要求モ
デルを作成
設計要求・顧客要求
要求
解決ポイント1
‹全体システムを把握
‹抜け漏れのない要求分析
製品仕様構成
モデル
展開
論理
製品全体機能を
設計し、論理モデ
ルを作成
エレ・メカ・ソフトを連携した
製品システム構成
解決ポイント2
‹システムレベルでの事前論理
検証
モデル
詳細設計
展開
物理
モデル
実装する部品・
コードを現す物理
モデルを作成
組込システム設計
メカ設計
電気回路
設計
実装
| 2/20/2009 |
ソフト
設計
解決ポイント3
‹システムモデルをもとに変更
影響範囲の確認
解決ポイント4
‹システムモデルを経由した仕
様変更の反映と確認
© 2008 IBM Corporation
1
モデル駆動型製品開発の背景
2
Requirement Analysis
解決1 全体システムを把握抜け漏れのない要求分析
3
シミュレーション検証
解決2 システムレベルでの事前論理検証
4
SysML-CAD連携
解決3 システムモデルをもとに変更影響範囲の確認
5
問題提起
© 2008 IBM Corporation
Requirement Analysis
要求分析の課題とアプローチ
現在の課題
現在の課題
設計要求
顧客要求
構想設計
(メカご担当者)
組込システム設計で要求が把握できずに、
組込システム設計で要求が把握できずに、
後工程で発覚し手戻りが発生する
後工程で発覚し手戻りが発生する
課題1
組込システム担当部門へ
うまく要求が伝わらない
考えられる要因
考えられる要因
①要求文書や伝達事項をうまく整理しない
①要求文書や伝達事項をうまく整理しない
まま設計に進んでいる。
まま設計に進んでいる。
②製品システム全体の要求が見えず要件
②製品システム全体の要求が見えず要件
の根拠がわからない
の根拠がわからない
メカ
詳細設計
電気回路
設計
ソフト設計
MDSEでのアプローチ
MDSEでのアプローチ
①要求を構造化して分析し、要求の抜け漏
①要求を構造化して分析し、要求の抜け漏
れをチェックする
れをチェックする
実装
10
②システムエンジニアリングの手法をとりい
②システムエンジニアリングの手法をとりい
れ、製品全体の要求分析を行い製品全体
れ、製品全体の要求分析を行い製品全体
の要求を可視化する
の要求を可視化する
© 2008 IBM Corporation
Requirement Analysis
システムエンジニアリングの手法
V字-プロセス
設計要求・顧客要求
システム
テスト
要求分析
ユニット
テスト
論理設計
構想設計
エレ・メカ・ソフトを連携した
システム設計
顧客レベル要求分析
要求分析
制御仕様の要求分析
組込システム設計
物理設計
実装
11
単体テスト
メカ設計
電気回路
ソフト設計
設計
実装
© 2008 IBM Corporation
Requirement Analysis
要求分析
安全運転システム(仮)
顧客レベル分析の例
機能を振る舞いとして分析する
二輪車検知機能
安全制御モード中で、左折
ランプ点灯中に自動車の左
後ろに二輪車を検知した場
合、警告音を発生させる。
危険検知機能
状態の特定
安全制御モード中
左折中
きっかけの特定
後方に二輪車を検知
なにをするか
警告音を発生させる
さらに状態を分類する※
安全制御モード
さらに、二輪車に接近した
場合は、音量をあげ通知し、
ステアリング・ホイールを適
度に重くし、運転者に危険
を気づかせる
12
二輪車
検知
左折中
さらに接近
二輪車
検知中
強警告音
操舵負荷増
検知
解除
※「状態遷移図」
© 2008 IBM Corporation
Requirement Analysis
2つのレベルでの要求分析
顧客レベル
要求分析
「安全運転システム」
要求文書
要求機能
「交差点での安全機能」
2次機能
具体的
シナリオ
「二輪車巻き込み防止機能」
具体的なシナリオで
要求機能を明確化
組込設計者が
モデルを作成
組込システムレベル
要求分析
製品
振舞
構造
制約
3次機能
メカ設計者の
支援が必要
記述されている
ものを網羅する
振舞
センサー
構造
アクチュエータ
制約
ECU
要求品質
システム
モデル
顧客レベルの
要求モデル
要求品質
スイッチ
組込レベルの
要求モデル
効率よく網羅的に展開する手法をMDSEで提供
ぬけもれのない要求分析をめざす
13
Demo
組込システム
設計へ
戻る
© 2008 IBM Corporation
1
モデル駆動型製品開発の背景
2
Requirement Analysis
解決1 全体システムを把握抜け漏れのない要求分析
3
シミュレーション検証
解決2 システムレベルでの事前論理検証
4
SysML-CAD連携
解決3 システムモデルをもとに変更影響範囲の確認
5
問題提起
© 2008 IBM Corporation
シミュレーション検証
システムレベルでの検証
現在の課題
現在の課題
設計要求
顧客要求
構想設計
課題2 システムレベル
の検証不足
(メカご担当者)
メカ
詳細設計
電気回路
設計
構想段階のシステムレベルでの検証が不
構想段階のシステムレベルでの検証が不
足し、各専門領域での設計がおわったあと
足し、各専門領域での設計がおわったあと
に製品全体での仕様をみたせず、手戻りが
に製品全体での仕様をみたせず、手戻りが
発生する
発生する
考えられる要因
考えられる要因
システム全体を表現するモデルがなく、製品
システム全体を表現するモデルがなく、製品
全体としての検証、既存部品の流用性評価
全体としての検証、既存部品の流用性評価
が不十分。
が不十分。
ソフト設計
MDSEでのアプローチ
MDSEでのアプローチ
①システムモデルを利用し構想時でのシ
①システムモデルを利用し構想時でのシ
ミュレーション検証を行う
ミュレーション検証を行う
実装
15
②検証した評価値を目標値として保管し各
②検証した評価値を目標値として保管し各
ドメイン設計者が参照できる
ドメイン設計者が参照できる
© 2008 IBM Corporation
シミュレーション検証
システムレベルでの検証
設計要求・顧客要求
システム・モデル
データ構造や評価
方法をモデル化
構想設計
エレ・メカ・ソフトを連携した
システム設計
システムモデルをもとに
データ構造や制約式を
活用する
検証タスク
最適化タスク
評価
解析
システムモデルで論理検証
組込システム設計
メカ設計
シミュレーションモデル
過去の設計情報や
パラメータを用いて
シミュレーションを行う
電気回路
ソフト設計
設計
形状/寸法
CAD
実装
部品構成
MATLAB
SIMULINK
SOA基盤
BOM
製品情報
技術情報
PDM
過去の
設計情報
1
© 2008 IBM Corporation
シミュレーション検証
既存コンポーネントの流用性検討 (課題)
今度のマイナーチェンジ製品
だが、基本的に部品は変えず
にセッティングを変えることで
対処してほしい。
この部品とセッティングの組み合
わせでどんな操安性能が得られ
るかな?
タイヤ品番
駆動系部品番号
操舵系部品番号
ブレーキ部品番号
サスペンション番号
セッティング
情報
データ収集
解析
操安性能
具体的にどの部品を新規設
計する必要があるのかな?
設計/CAE資産
(既存部品の特性値)
車両緒元
タイヤ特性
PDM
既存部品だけでは思った程
の性能がでません。
やはり新規設計の必要があ
るかと・・・
駆動系の特性
操舵系の特性
BOM
ブレーキの特性
サスペンションの特性
CAE資産
過去の資産
© 2008 IBM Corporation
シミュレーション検証
既存コンポーネントの流用性検討 (「最適化」)
今度のマイナーチェンジ製
品だが、この要求仕様値を
基に、既存部品の流用可
能性を検討してほしい。
この要求仕様値を満たす
為に必要な部品の特性値
は何かな?
要求仕様
操安性能
目標値
最適化
要求を満たす為に
必要な特性値
近い特性値を持つ
既存部品のデータ
この値だと、後輪のサスペンションは既存
のものにマッチするものがあるな・・・
前輪のサスペンションは少し手を入れな
いと難しいな・・・
PDM
設計/CAE資産
(既存部品の特性値)
車両緒元
タイヤ特性
BOM
駆動系の特性
操舵系の特性
ブレーキの特性
CAE資産
過去の資産
サスペンションの特性
© 2008 IBM Corporation
シミュレーション検証
MDSE-FiPER連携
MDSEツール(SysML-Webサーバー) + CAEツール(FiPER)
・既存部品の流用
可能性を検討
・新規部品の設計
値として使用
③設計
要求を充たす特性値
(最適化計算結果)
既存部品の特性値
(設計資産)
既存部品
検索フロー
“操安性”
最適化フロー
(iSIGHT-FD)
(iSIGHT-FD)
初期値
“操安性”
特性構造モデル
“操安性”
解析モデル
“操安性”
評価モデル
(SysML)
(CarSim, SIMULINK …)
(SysML)
車両緒元
スタビリティファクター
タイヤ特性
最大横加速度
駆動系の特性
ロール角
操安性
制約式
操安性
目標値
操舵系の特性
要求
モデル
①企画#1
(商品企画)
企画要求
②企画#2
(商品設計)
ブレーキの特性
サスペンションの特性
設計目標
解析システム
Federation
CAD
PDM
BOM
CAE-DB
設計/CAE資産DB
© 2008 IBM Corporation
シミュレーション検証
Demo
MDSEシステムモデル・操安性モデル
(SysML : Block Definition Diagram)
評価モデル
要求
テストケース
解析システム
解析モデル
特性構造モデル
物理構成
20
DBシステム
戻る
© 2008 IBM Corporation
1
モデル駆動型製品開発の背景
2
Requirement Analysis
解決1 全体システムを把握抜け漏れのない要求分析
3
シミュレーション検証
解決2 システムレベルでの事前論理検証
4
SysML-CAD連携
解決3 システムモデルをもとに変更影響範囲の確認
5
問題提起
© 2008 IBM Corporation
SysML-CAD連携
MDSE SysML-CATIA連携ソリューション
現在の課題
現在の課題
ドメインをまたがった仕様変更値の伝達が
ドメインをまたがった仕様変更値の伝達が
不十分。CADでの変更を容易に組込設計
不十分。CADでの変更を容易に組込設計
に伝達できない
に伝達できない
設計要求
顧客要求
構想設計
考えられる要因
考えられる要因
①各種仕様の変更が部門をまたがるため
①各種仕様の変更が部門をまたがるため
頻繁な変更に対応する労力がかかる
頻繁な変更に対応する労力がかかる
(メカご担当者)
メカ
詳細設計
電気回路
設計
ソフト設計
課題3 ドメイン設計での
設計仕様変更の反映
や確認ができない
実装
22
②組込みシステム設計の開発環境と連携で
②組込みシステム設計の開発環境と連携で
きていない
きていない
MDSEでのアプローチ
MDSEでのアプローチ
①システムモデルをもとにCADから諸元や
①システムモデルをもとにCADから諸元や
仕様を参照・書き込みできる
仕様を参照・書き込みできる
②CADから直接組込みシステム開発環境
②CADから直接組込みシステム開発環境
を参照する仕組みを提供し利便性をはかる
を参照する仕組みを提供し利便性をはかる
© 2008 IBM Corporation
SysML-CAD連携
Demo
SysMLーCATIA連携 実行例
CATIA
②CATIAで設計
し、部品の仕様
を決める
SysML環境
①緒元・ユニット
仕様値をSysML
で確認する
Webサービス
製品=システム
④SysMLの制約
式で確認。部品
サブシステム
サブシステム
仕様に問題ない
仕様
制約 ことを確認
ユニット
ユニット
例:部品の重さ
部品
連携ツール
仕様
③CATIAから部
品仕様値をシス
テムモデルへ保
管する
SW
回路
制御仕様
部品
ソフト
SW開発環境
⑤電子制御サスペンションシステ
ム設計に反映
開発環境上のSysMLの仕様値と直接読み書きし、
組込システム設計との変更同期の効率化を行う
23
回路
がかわったので
アクチュエータの
制御仕様を変更
戻る
© 2008 IBM Corporation
SysML-CAD連携
SYSML-CAD連携を支えるモデル-トレースのしくみ
システムモデルの各ブロックの関係をたどることにより、要求がどの制約式を満たすかをトレ
ースします
① 性能要求を指定
② 性能要求をトレースする
Requirement1 +
Requirement2
② 要求からブロックをトレースする
<<satisfy>>
今回の例ではアプリケーション
としてCADを利用していますが、
Webアプリケーション、Excel、
開発環境でも連携できます
Block2
Block
Integer b = 1
③ ブロックからブロックをトレースする
Constraint
Block1
Block3
aa < bb + cc
Real a = 10
Integer c = 2
④ ブロックが使用されている拘束式パラメトリック図を探す
Parametric Diagram
Real a = 10
Block2
Integer b = 1
Block3
Integer c = 2
aa
bb
aa < bb + cc
cc
© 2008 IBM Corporation
1
モデル駆動型製品開発の背景
2
Requirement Analysis
解決1 全体システムを把握抜け漏れのない要求分析
3
シミュレーション検証
解決2 システムレベルでの事前論理検証
4
SysML-CAD連携
解決3 システムモデルをもとに変更影響範囲の確認
5
問題提起
© 2008 IBM Corporation
問題提起
●要求(Requirement )定義・展開の標準的な方法
・要求の種類
・・・VOC(顧客の要求)、製品・システムの要求機能、要求仕様、あるいは、
製品仕様も定義が不明確
・機能の種類・・・・品質機能展開、機能系統図
・・・機能の定義、機能から設計への展開方法が標準化されていない
●製品設計におけるメカの挙動を記述する標準的な方法
・エレメカソフト各担当が設計意図を共有できる記述方法がない
●構想設計段階の製品開発環境
・詳細設計段階の開発環境(CAD、PDM・・)は充実。
●フロントローデイング型設計のあるべき姿
・フロントローデイングの考え方、実施工程の範囲が決まっていない
© 2008 IBM Corporation
問題提起
製品開発環境の方向性
「ものをつくらずにつくる」モデル駆動型製品開発
開発支援プラットフォーム
トップダウン開発プロセス
開発ツール/技法
ƒ仕様-機能-製品構造・部品の関
係を管理するプラットフォーム
ƒ製品アーキテクチャーを規範に
したトップダウンの開発プロセス
ƒエレメカソフト複合製品への対応
ƒモデル駆動型製品開発
ƒツールを駆使した設計検証
ƒ脱プログラミング
ƒ要件/仕様確定ができない状況
下での変化対応
ƒ共通プラットフォームによる複数
製品共通機能実現
ƒ過去の実績を有効活用した製品
モデル上で設計品質を向上
モデル駆動型製品開発の狙い
‹エレメカソフト連携開発
‹フロントローデイング型設計
‹流用設計・編集設計
© 2008 IBM Corporation
Fly UP