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