SEC高信頼化技術セミナー モデルベースシステムズエンジニアリング（MBSE）入門 ～導入のポイントと適用事例の紹介～ 2015年11月26日 モデルベースシステムズエンジニアリング ～システムモデルは何に活用できるか？ 本当の話をしよう！～ 慶應義塾大学 教授 IPA/SEC 連携委員 西村 秀和 http: lab.sdm.keio.ac.jp/nismlab/ Copyright©2015 Hidekazu Nishimura. 本日のお話の内容 システムズエンジニアリングの欧米での広がり モデルに基づくシステムズエンジニアリング（MBSE） の重要性 開発ステージでのシステムズエンジニアリングプロセ スの概略の流れ システムアーキテクチャの重要性とシステムモデル の有効性 SysMLの適用事例と適用を試みた企業担当者から の評価 1 Copyright©2015 Hidekazu Nishimura. INCOSE INSIGHT Vol.18, Issue.2, 2015 2014年度 MBSE調査対象（回答）国 2 Copyright©2015 Hidekazu Nishimura. MBSE は 広 範 囲 の 産業に採用されてい る。 INCOSE INSIGHT Vol.18, Issue.2, 2015 3 Copyright©2015 Hidekazu Nishimura. MBSEの認知と採用 この3年間の変化は 極めて大きい。 INCOSE INSIGHT Vol.18, Issue.2, 2015 4 Copyright©2015 Hidekazu Nishimura. MBSEの取り組み をどこに適用して いるか？ Copyright©2015 Hidekazu Nishimura. Vol.18, Issue.2, 2015 5 INCOSE INSIGHT システムズエンジニアリング2025のあるべき姿 システムズエンジニアリングの基盤は，アカデミアを横断して一貫性のある形 で定義され，教授される． システムの複雑度と関連するリスクが正しく評価され，特徴付けられ，そして 管理される． システムズエンジニアリングは，信頼でき回復力のあるシステムを設計し，そ して予測するための分析的なフレームワークを与える． モデルベースシステムズエンジニアリングは標準となり，企業体におけるデジ タル機能とともにモデリングとシミュレーションが統合される． システムズエンジニアリングは，競争力をもって新たなものを生み出し，大き な価値を与えるように，産業，政府，アカデミアを横断して認められる． システムズエンジニアリングは，技術の評価，政策の分析を行うために必須 の学問として確立される． システム思考は教育のすべてのレベルで教授される． INCOSE Systems Engineering Vision 2025 (June 2014) http://www.incose.org/docs/default-source/aboutse/se-vision-2025.pdf?sfvrsn=4 INCOSE: International Council on Systems Engineering 6 Copyright©2015 Hidekazu Nishimura. MBSEのモチベーション QCDを守りたい。 トレーサビリティを確保 したい。 Better productのために Better engineeringを実現したい! そのために Systems Engineering ┃ ことで効果的、効率的にしたい そのために Model Based Systems Engineering ドキュメントベースで 複雑なシステムを システムズエンジニアリングをモデルに基づく 扱うのは辛い！ モデルベースで行うシステムズエンジニアリングを 活動範囲が社 国際的に認められた共通言語で行いたい 内だけに限定 されていない。 そのために ┃ SysMLによるMBSE 決してSysMLやMBSEがモチベーションの源泉や目的ではない 7 Copyright©2015 Hidekazu Nishimura. システムとは何か？ システム： 相互に関連し全体として機能するコンポーネントの集まり ハードウェア，ソフトウェア，人，設備など複数のドメインで構成 環境 アクター actor：行為者 （人とは限らない） 境界：boundary Use Case１ Use Case 2 System of interest ？ System of interest 対象システム 8 Copyright©2015 Hidekazu Nishimura. システム：製品とそれを実現するプロセス System 製品階層 製品 サブ システム 製品 サブ システム IEEE 1220より 開発・テスト プロセス - 設備 - 機器 - 工程 - ソフトウェア アプリ - 計算機資源 - 人員 - サプライヤ - ベンダー 製造 プロセス - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - 部品在庫 - 人員 - サプライヤ - ベンダー - 品質管理 9 ライフサイクルプロセス 販売・サポート プロセス - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - スペア部品 在庫 - メンテナンス サプライヤ - ベンダー 運用・ トレーニング プロセス - 設備 - 機器/ツール - 工程 - ソフトウェア アプリ - 計算機資源 - オペレータ - トレーナー 廃棄 プロセス - 設備 - 機器/ツール - 工程 - 人員 Copyright©2015 Hidekazu Nishimura. システムズエンジニアリングとは？ システムを成功裏に実現するための複数の分野にまたがる アプローチおよび手段 コミュニケーションの重要性 ISO 15288:2015 システムライフサイクルステージ 10 Copyright©2015 Hidekazu Nishimura. システムズエンジニアリングとは？ システムズエンジニアリングの定義 システムを成功裏に実現するための複数の分野にまたが るアプローチおよび手段 システムズエンジニアリングでは、開発の初期段階で顧客の ニーズを明確化し、機能要求を定義し、関連する問題をすべ て考慮しながら設計のための総合とシステムの妥当性確認 を進める。 システムズエンジニアリングは、ユーザーニーズに合致した 品質の製品を供給することを目的とし、ビジネスとすべての 顧客の技術的要求を考慮する。 INCOSE: International Council on Systems Engineering 11 Copyright©2015 Hidekazu Nishimura. ISO 15288:2015 システムライフサイクルプロセス 合意プロセス ・取得ﾌﾟﾛｾｽ ・供給ﾌﾟﾛｾｽ 組織的プロジェクト実現 プロセス ・ライフサイクルモデル マネジメントﾌﾟﾛｾｽ ・基盤マネジメントﾌﾟﾛｾ ｽ ・ポートフォリオマネジメ ントﾌﾟﾛｾｽ ・人的リソースマネジメ ントﾌﾟﾛｾｽ ・品質マネジメントﾌﾟﾛｾ ｽ ・知識マネジメントﾌﾟﾛｾ ｽ 技術マネジメントプロセ ス ・プロジェクト計画ﾌﾟﾛｾｽ ・プロジェクト評価・統制 ﾌﾟﾛｾｽ ・意思決定マネジメント ﾌﾟﾛｾｽ ・リスクマネジメントﾌﾟﾛｾ ｽ ・構成管理ﾌﾟﾛｾｽ ・情報マネジメントﾌﾟﾛｾｽ ・測定ﾌﾟﾛｾｽ ・品質保証ﾌﾟﾛｾｽ 12 技術プロセス ・ビジネス解析，ミッション解 析ﾌﾟﾛｾｽ ・利害関係者要求定義ﾌﾟﾛｾ ｽ ・システム要求分析ﾌﾟﾛｾｽ ・アーキテクチャ設計ﾌﾟﾛｾｽ ・設計定義ﾌﾟﾛｾｽ ・システム解析ﾌﾟﾛｾｽ ・実装ﾌﾟﾛｾｽ ・統合ﾌﾟﾛｾｽ ・検証ﾌﾟﾛｾｽ ・移行ﾌﾟﾛｾｽ ・妥当性確認ﾌﾟﾛｾｽ ・運用ﾌﾟﾛｾｽ ・保守ﾌﾟﾛｾｽ ・廃棄ﾌﾟﾛｾｽ Copyright©2015 Hidekazu Nishimura. システム解析プロセス (ISO 15288:2015) 目的 成果 ライフサイクル全般にわたり意志決定を補助する技術的な理解に向け てのデータと情報に関する厳格な基礎を提供する。 必要なシステム解析の特定 システム解析の仮定と結果の妥当性確認 決定のためのシステム解析結果の供給 システム解析を実現するために必要なシステムまたはサービス システム解析結果のトレーサビリティの確立 準備 システム解析を必要とする問題の特定／利害関係者の特定 システム解析のスコープ，目的，忠実度の定義 解析に必要なデータと入力の収集 手法の選定／戦略の定義 システム解析の実現に必要なシステムまたはサービスの特定と計画 システム解析の実現に必要なシステムまたはサービスへのアクセス 13 Copyright©2015 Hidekazu Nishimura. モデル vs シミュレーション (SEH 4th Ed.) “モデル”と“シミュレーション”には、それぞれに意味が あるにもかかわらず、間違って受け取られることがある。 モデル＝対象とするシステム、エンティティ、現象、プロ セスの抽象または表現（観点：形状、機能、性能） シミュレーション＝時間に沿ってモデルを実行する特定 の環境へのモデルの実装。一般には、システム、ソフト ウェア、ハードウェア、人、物理現象の複雑な動的振る 舞いを解析する手段を提供する。 SEH: Systems Engineering Handbook 14 Copyright©2015 Hidekazu Nishimura. モデリングの目的（１） (SEH 4th Ed.) 実在するシステムの特徴づけ：文書で書かれた実在システム のモデリングでそのアーキテクチャと設計を把握する。 ミッションおよびシステムコンセプトの定式化と評価：システム ライフサイクル初期の段階で、モデルによりミッションおよび システムコンセプト候補を総合（synthesis）し評価（evaluate）す る。システム設計のモデリングと重要なシステムパラメータの 影響評価からトレードオフ解析の解空間を探索する。 システムアーキテクチャとシステム要求のフローダウン：モデ ルを用いてシステム解のアーキテクティングを支援し、ミッショ ンとシステム要求（機能要求、インタフェース要求、性能要求 、物理要求の他、信頼性、保守性、安全性、セキュリティなど のいわゆる非機能要求）をシステム要素に割り当てる。 15 Copyright©2015 Hidekazu Nishimura. モデリングの目的（２） (SEH 4th Ed.) システム統合と検証の支援：システムへのハードウェア、ソフ トウェアの統合の支援とシステムが要求を充足することの検 証の支援にモデルを用いる。Hardware-in-the-loop テスト、 Software-in-the-loop テスト。モデルは、テスト計画と実行を支 援するためテストケースやテストプログラムの他の観点を定 義する。 トレーニングの支援：システムと相互作用するユーザー（オペ レータ、保守員、その他）を訓練するシステムの様々な観点を 模擬する。 知識の獲得とシステム設計の進展：システムに関する知識の 獲得と組織の知識としての維持のための効果的な手段をモ デルは提供する。 16 Copyright©2015 Hidekazu Nishimura. システムライフサイクルプロセス中の シミュレーションモデルとシステムモデル ビ ジネス 解析 とミッション 解 析 ：解決すべき状況を表す 記述モデル （ Descriptive model）は、正しい問題に対処していることを保証する。 利害関係者要求定義とシステム要求定義：要求を正当なものとし、適切 な要求の特定を行う。 アーキテクチャ定義：選択基準をもとに候補となっている選択肢を評価し、 他のシステムとの統合など、ベストのアーキテクチャを見いだす。 設計定義：必要な設計データを取得し、最適化のためのパラメータを調整 し、システム要素に対する実際のデータが得られるよう忠実にモデルを更 新する。 検証と妥当性検証：システム環境をシミュレートして検証および妥当性確 認データを評価し、（シミュレーションは、直接観察できない重要なパラメ ータの計算のための入力として観測可能なデータを用いる）、シミュレーシ ョンの忠実度の妥当性を確認する。 運用：実際の動作を反映し、計画、検証、オペレータの訓練のための実行 の前に動作を模擬する。 SEH 4th Ed. 17 Copyright©2015 Hidekazu Nishimura. システムを構築するプロセス（簡易版） システム アーキテクチャ 利害関係者 ニーズ システム要求 システム統合 システム とテスト 解決策 システム設計 と仕様 コンポーネント 要求 検証済み コンポーネント コンポーネント 設計の 設計，実装，テスト フィードバック 統合とテストからのフィードバック 18 Copyright©2015 Hidekazu Nishimura. システムズエンジニアリングプロセスの概要 システムズエンジニアリングを構成する４つのアクティビティ 1. システム設計 – 要求分析、アーキテクチャ設計を実施し、サブシステ ム（システム要素）への要求を導出する． 2. インテグレーション（統合） – 検証済みのサブシステムを統合する． 3. 評価・解析 – エンジニアリング活動における解析および検証 (verification)・妥当性確認(validation)等を実施する． 4. システムズエンジニアリングマネジメント – QCDを満たすように、各種活動の計画・実施・評価を 行う． 19 Copyright©2015 Hidekazu Nishimura. 左側の「要求の分析」から「設計の検証」に至る流れが、一方的に進むのではなく、 右側の「システム解析」の中でトレードオフ分析と評価をそれぞれのステップで行い、 IEEE 1220 systems engineering process 繰り返しが存在することに注意されたい。 SEプロセスへの入力 要求と制約の矛盾 要求の分析 要求のトレードオフ と影響 要求の基準 要求の 妥当性確認 確認された要求の基準 分解と要求の割り当に 関する候補 機能の分析 分解割り当ての トレードオフと影響 機能アーキテクチャ 機能の検証 検証済み機能アーキテクチャ 総合 システム解析 機能の トレード分析 と評価 設計解の要求と候補 設計解の トレードオフと影響 物理アーキテクチャ 要求の トレード分析 と評価 設計の検証 設計の トレード分析 と評価 検証済み物理アーキテクチャ 統制 SEプロセスの出力 20 Copyright©2015 Hidekazu Nishimura. システムアーキテクチャ システムズエンジニアリングプロセスでは、対象とするシステム （system of interest）に関してライフサイクル全体を見渡した上で 、要求分析を行い、そしてそのアーキテクチャを構築することが 極めて重要となる。システムアーキテクチャの決定には，さまざ まな観点（View，例えば，安全性，信頼性，可用性，保守性）か らの検討が必要になる． アーキテクチャの定義：ISO/IEC/IEEE 42010 「アーキテクチャは，システム要素とその関係性の中で具体 化された，ある環境中のシステムの基本概念または特性であ り，またシステムを設計し進化させるその原則である．」 21 Copyright©2015 Hidekazu Nishimura. exhibits 1 1 1 identifies expresses has interests in 1 1..* identifies Stakeholder 対象とするシステムは Academic Version アーキテクチャを明示する。 Commercial Devel Architecture 1 ビューポイントは 関心事をフレームする。 利害関係者は 利害関係者は 関心事を持つ。 SoIに興味を持つ。 System of Interest 1 Architecture Discription 1 アーキテクチャ記述は 対象システム、利害関 係者、関心事を特定す る。 1..* 1 1..* 1..* Architecture Rationale has identifies 1..* Concern 1..* 0..* 1..* 0..* Correspomdemce Rule Correspondence 1..* addresses frames 1..* 1..* 1..* Architecture Viewpoint 1..* Architecture View 1 governs 1 ビューポイントがビューを支配する 1..* Model Kind 1..* 1 1..* governs 22 Architecture Model ビューを設定することが Academic Version for Teachin アーキテクチャに重要で Commercial Development is s ある。 このビューが利害関係 者の持つ関心事に対処 する。 ISO/IEC/IEEE 42010 Copyright©2015 Hidekazu Nishimura. 二元V字開発モデル (Dual Vee Model) 要求を満足する システムの完成 Architecture Vee 利害関係者 の要求 Entity Vee Entity Veeのそれぞ れのステップで，サブ システムやコンポー ネントのインテグレー ションが繰り返される． 23 Copyright©2015 Hidekazu Nishimura. エンティティV (Entity Vee) 顧客による確認 概念設計，アーキテ クチャの選定，設計 に向けた仕様 見込み調査， リスク調査 製作，コード 化に向けた 仕様 顧客による確認 検証と妥当性確認の計画 顧客による確認 Entity要求の定義 妥当性確認 検証の計画 購入，製作， コード化 解決策の達成 24 妥当性確認の計画 検証 検査，テスト， 実証，分析 検証 検査，テスト， 実証，分析 不具合調査 利害関係者の要求 Copyright©2015 Hidekazu Nishimura. 二元V字モデルによるプロセスの理解 要求を満足する システムの完成 Architecture Vee 利害関係者 の要求 早い段階での 手戻り Entity Vee アーキテクチャの検討， 決定では，サブシステ ムやコンポーネントの 実現可能性を検討しな がら進めることがある． 25 Copyright©2015 Hidekazu Nishimura. 二元V字モデルによるプロセスの理解 要求を満足する システムの完成 Architecture Vee 利害関係者 の要求 致命的な 手戻り Entity Vee コンポーネント， サブシステムの 検証，妥当性確認 を順序行い，システム としての検証，妥当性 確認を行って行く． 26 Copyright©2015 Hidekazu Nishimura. どの部署がどこと連携して いつ、何を用いて、何をするのか？ エンジンシステムアーキテクチャ エンジンシステム検証： Hardware-in-theloop simulation （エンジンベンチ） 制御系検証： Hardware-in-theloop simulation 制御系設計： Model-in-theloop simulation ソフトウェア検証： Software-in-theloop simulation ソフトウェア設計： Software-in-theloop simulation 27 Copyright©2015 Hidekazu Nishimura. コミュニケーションの失敗 ？ このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、 28 Copyright©2015 Hidekazu Nishimura. 図を用いたコミュニケーション このシステムは、●● と××から構成され、 △△の運用を考えた ときに、、、 29 Copyright©2015 Hidekazu Nishimura. “モデルベースでシステムを考える”とは？ モデル＊に基づくシステム開発 仕様書など文書だけではすぐに理解できないことが、図的 に表現することで理解が容易になる。 協働してシステム開発をするには、共通言語が必要であり、 それをサポートするには図的な言語が有効である。 モデルを再利用することにより開発の効率化が期待できる。 モデルを用いて抽象度を上げる → 問題点を明らかにす る → 改善点や新たに取り組むべきことを理解する ＊注：実行可能ではないモデルを含む． もちろん，実行可能なモデルも含む． 30 Copyright©2015 Hidekazu Nishimura. 複雑なシステムの開発をいかに マネジメントするか？ 自動 変速 複数の機能がサブシステム間に またがっている複雑システム： トレーサビリティを確保した上で、 QCDを守って開発を進めたい。 Traction control クラスタ CAN 速度表示 ABS エンジン T/M ACC コンテキスト を明確にし、機能性 を把握した上で、要求される機 能を実現する システムアーキテ クチャを構築する。 サブシステム（構成要素） 要求される機能を分解＝機能アーキテクチャ 分解された機能を構成要素に割り当てる＝物理アーキテクチャ アーキテクチャの選定には、Viewの設定が重要となる。 システム解析による検証：トレードオフ分析と評価 31 Copyright©2015 Hidekazu Nishimura. システム境界の定義 （コンテキストレベル） 対象とするシステム：自動車 外部システム：ドライバー，ガスポンプ（燃料供給），道路 など．他にもさまざまな利害関係者が関係する． 要求：自動車はドライバーの運転により，道路上を移動 して，ある地点から目的の場所へ人や物を運ぶことがで きる．＝ユーザーに提供したい価値 自動車 ドライバー ガソリンスタンド 道路 32 Copyright©2015 Hidekazu Nishimura. システムの機能要求 自動車の機能の1つ：「加速する」 機能「加速する」を入出力の関係で記述する． 自動車はドライバーの加速指令を受けて，「加速する」と いう機能を持つ． ドライバーに対して，自動車は「速度を提示する」という 機能を持つ． 速度表示 加速指令入力 速度を 提示する 加速する 33 速度 駆動力 Copyright©2015 Hidekazu Nishimura. システムの性能要求 機能の評価：「加速する」の評価 ドライバーからの指令に対して，どれだけ加速することが 要求されているのか？ 自動車の速度 [km / h] × 100 50 O 2 4 6 時間 [秒] 34 8 Copyright©2015 Hidekazu Nishimura. 機能の分析(Analysis)と設計の総合(Synthesis) システムの機能を分析する．＜振る舞い図＞ 加速指令 加速 指令 回転力を 発生する 加速する 発生した 回転力を 調整する 加速力の発生 調整した力 をタイヤに 分配する タイヤが 回転する 加速力 の発生 機能を物理へ割り当てると，，，(Allocation) インタフェースの明確化 35 Copyright©2015 Hidekazu Nishimura. システムの構造の明確化 自動車はタイヤ，エンジン，トランスミッション，デフなど のコンポーネントから構成される． コンポーネント間のインタフェースを明確にする． 構造図としては，，， 36 Copyright©2015 Hidekazu Nishimura. システムモデルで明確にすること ライフサイクルステージ コンセプト⇒開発⇒製造⇒運用と保守⇒廃棄 それぞれについて検討する必要がある．さもなければ，システムは 実現しない． それぞれのステージについてコンテキスト（文脈，脈略）を最初に考 え，抜け漏れがないことを確認する．その際，利害関係者の要求 や懸念事項をすべて洗い出す．その上で，対象システムの境界 ， ユースケース，機能性を明確にする． 次に対象システムの内部を分析し，総合する．最初に機能を分解 して，その分解された機能をシステム構成要素に割り当てる ．これ により，システム構成要素間のインタフェース が定義され，アーキ テクチャの候補が導出できる． 要求や懸念事項に応じてView（観点）を設定し，トレードオフ分析に よりいくつかの候補の中から適切なアーキテクチャを選定する． 37 Copyright©2015 Hidekazu Nishimura. MBSEのモチベーション QCDを守りたい。 トレーサビリティを確保 したい。 Better productのために Better engineeringを実現したい! そのために Systems Engineering ┃ ことで効果的、効率的にしたい そのために Model Based Systems Engineering ドキュメントベースで 複雑なシステムを システムズエンジニアリングをモデルに基づく 扱うのは辛い！ モデルベースで行うシステムズエンジニアリングを 活動範囲が社 国際的に認められた共通言語で行いたい 内だけに限定 されていない。 そのために ┃ SysMLによるMBSE 決してSysMLやMBSEがモチベーションの源泉や目的ではない 38 Copyright©2015 Hidekazu Nishimura. MBSE＝Systems Engineering あくまでもSystems Engineeringである。 システムモデルに基づいてSystems Engineeringを行う。 Systems Engineeringの無いMBSEはあり得ない。 Systems Engineeringには大きく４つの活動がある。 システム設計 システムの解析と検証 システムの統合 システムズエンジニアリングのマネジメント 注：MBD（モデルベース開発）はMBSEの一部分である。 システムモデル＝シミュレーションモデル 39 Copyright©2015 Hidekazu Nishimura. SysMLダイアグラムの分類 SysML: Systems Modeling Language パッケージ図 要求図 SysML ダイアグラム 振る舞い図 パラメトリック図 構造図 40 ユースケース図 シーケンス図 アクティビティ図 状態機械図 ブロック定義図 内部ブロック図 Copyright©2015 Hidekazu Nishimura. システムモデルを SysMLダイアグラムで表現する（例） モデル編成の定義 パッ ケー ジ図 要 求 図 pkg req パラメ トリッ ク図 振る舞い図 act seq stm uc par SoIのユースケー スシナリオ ibd ✔ ✔ ✔ ✔ ✔ ✔ ✔ 機能および物理 アーキテクチャ ✔ システムの分析 ✔ システムの検証 bdd ✔ SoIと外部システム の関係 SoIに対する要求 構造図 ✔ ✔ ✔ ✔ ✔ ✔ 41 Copyright©2015 Hidekazu Nishimura. コンカレントデザインを促進するフレームワーク システムモデル トレーサビリティ 根拠 外部からの 要求 解析 振る舞い 構造 ダイナミクス 解析 ビュー ポイント システム 仕様書 解析モデル 性能 評価 要求 パラメトリック制約 制御システム 解析 1D-CAEなど 製品データ管理 （PDM） ・部品表（BOM） ・物理設計（CAD） ハードウェア 設計モデル 電気回路 設計モデル 42 ソフトウェア 設計モデル テスト方法 テストモデル Copyright©2015 Hidekazu Nishimura. システムモデルは組織に何をもたらすか？ システムとして考えることで得られる気付き 「システム」の重要性、ライフサイクルステージの考慮 「システムアーキテクチャ」を持つことの必要性 「システムアーキテクチャ」を検討することでシステム全体と してのトレードオフ検討、最適化を行えること 構成要素への明確な要求の規定、インタフェースの定義 要求のトレーサビリティの確保 要求および設計変更への対応 システム設計の検証 QCDを守って、システムを構築するプロセスを明確にする。 43 Copyright©2015 Hidekazu Nishimura. MBSEの適用事例 自動車のパワーバックドアシステム開発のための モデルベースシステムズエンジニアリングの適用 MBSE に基づきSysML（Systems ModelingLanguage）を利用して パワーバックドアシステムのシステムモデルを記述しアーキ テクチャを構築するまでのプロセスを示す。 部分として考えるのではなく、システムとして考えることによる 技術者の気づきや明らかになった点を示す。 44 Copyright©2015 Hidekazu Nishimura. MBSEの適用で得られた気付きと 明確になったこと 要求のトレーサビリティ コンテキスト分析におけるシーケンス図による効果 エンジニアが要求やビューを把握し、トレースを確保できる。 要求から導かれる機能を明確にすることができる。 機能の割り当て 構成要素間の関係性が明らかとなり、コンポーネント担当エン ジニア間のコミュニケーションが円滑になる。 従来の”部品ありき”の設計スタイルでは、見いだすことので きなった組織の枠にとらわれない、対象とするシステム全体と しての最適化の検討が行える。 意図しない手戻りを減らすことでQCDを守ることが可能。 45 Copyright©2015 Hidekazu Nishimura. （１）要求のトレーサビリティ 全てのシステムモデルおよび情報は要求図に示されて いる元来の要求に遡ることができるため、エンジニアは システムのすべてのビューを把握することができる。 要求に関連するシステムモデルはSysML ツールに保存 されているため、例えば、ECU を追加して新たな機能を 実現する追加開発の際には、要求およびコンポーネント 間の関係性を要求図で追いながら検討できる。 要求のトレーサビリティを確保しておくことは非常に重要 である。 46 Copyright©2015 Hidekazu Nishimura. （２）コンテキスト分析の効果１ コンテキスト分析で、絵を描き、またシーケンス図を用い た検討を行うことにより、LED 光には地面からの反射が あることに気づいた。ユーザーへの「おもてなし」あるい はLED としての機能が、地面の状態に依存することを見 いだせた。 バックドアの開閉の動作をイメージすることにより、I-key の検出を行うためのアンテナの配置に関する検討の見 逃しを防ぐことができた。 バックドアが閉まっているときと、開いているときでは、電 波環境が異なるので、I-key位置検出のチューニングをバ ックドア開閉状態それぞれで実施する必要があるという 気付きも得ている。 47 Copyright©2015 Hidekazu Nishimura. （２）コンテキスト分析の効果２ Vehicle2013 が持つべき機能と新たに追加するOSBDS が持つべき機能を明確にすることができた。 移動検出器とVehicle2013への機能の割り当てやそれら の統合の可能性、およびBD2013 CU とSonar CU の統 合の可能性をそれぞれ示唆することができた。 SysMLを用いたシステムモデルの記述により、従来の”部 品ありき”の設計スタイルでは、見いだすことのできなっ た組織の枠にとらわれない、対象とするシステム全体と しての最適化の検討が行えたことは大きなメリットとして 認識された。 48 Copyright©2015 Hidekazu Nishimura. （３）機能の割り当て１ アクティビティ図は、機能がどのようにシステムコンポー ネントに割り当てられているかを示すことができ、これは システムに関与するシステムズエンジニアだけではなく、 コンポーネントの設計者にとっても、設計するコンポーネ ントがシステムの中でどのように機能するのかを知るこ とができるため、有用である。 技術者が良く活用するステートマシン図や状態遷移表と 合わせて検討することによって、コンポーネントの機能に 漏れがないかを検討することができる。 機能のコンポーネントへの割り当てやコンポーネント間 の統合をシステムとして俯瞰して見ることができるように なる。⇒最適化の検討が行えるようになる。⇒次頁へ 49 Copyright©2015 Hidekazu Nishimura. （３）機能の割り当て２ コンポーネントに依存する形で分割された組織では、機 能の割り当てやコンポーネント間の統合を検討する際に 、技術者自身の 組織内のコンポーネント のみに影響が 留まり、自身が属する 組織外のコンポーネント に対して 影響が出ないように設計をしがちである。 そうした思考の枠にとらわれずに全体を俯瞰することで 、実プロジェクトにおけるQCDの最適化が図れる可能性 がある。 こうした検討がシステム開発の早い段階で行えることは 、試作やプロトタイプを減らすことができ、意図しない手 戻りの減少に大いに効果があるものと期待される。 50 Copyright©2015 Hidekazu Nishimura. システムズエンジニアリングの導入に向けて 成果物の形式および質の向上 エンジニア個人のスキルに依存 文書として残すべき成果物と関連するシステムモデルを明 確に区別できることの優位性 問題と課題 MBSEとSysMLの導入⇒乗り越えるべき壁がいくつかある。 システムズエンジニアリング活動を行う組織が存在しない。 システムズエンジニアリング活動を行うために組織を編成し、 SysMLを導入するためのコスト、エンジニアをトレーニングする ためのコストなどの負担への対処は大きな課題となる。また、 追加開発も含んだエンジニアリングプロセスの中での活用方 法を検討しなければならない。 51 Copyright©2015 Hidekazu Nishimura. E/Eアーキテクチャの課題 ECU（Electronic Control Unit）搭載数：50～100個／台 複数のECU をネットワークで構成するE/E アーキテクチャ 新たな機能の追加要求 ⇒ ECU の増加、E/E アーキテクチャの複雑化 追加開発 ⇒意図しない手戻り、業務上の効率低下 既存システムのどこを活かし、何を追加し、改良すれば良い かを明確にしたい。 ⇒ システムズエンジニアリングの活用 他のサブシステムやコンポーネントとどのような関係性をもつ のかを担当技術者にわかるようにする。 52 Copyright©2015 Hidekazu Nishimura. As-Is分析 非接触パワーバックドアシステム（CPBDS) Vehicle 2013 Contactless sensor detecting open request open Sensor CU BCM unlock M BD CU M Cancel SW I-key 53 Copyright©2015 Hidekazu Nishimura. ワンステップ・バックドアシステム （OSBDS）の検討 ユーザーニーズ（新たな要求の追加） “ユーザーフレンドリー（操作性の良さ）” “おもてなし” B 操作可能エリア LED 点灯エリア 54 A 受信可能エリア Copyright©2015 Hidekazu Nishimura. ユースケース図 uc[Packag [Package] Usecase case OSBDS] ] uc e] [ [Use ofof OSBDS «useCaseModel» «useCaseM odel» One-Step Back Door System (OSBDS) One-Step Back D oor System (OSBDS) AcademicVersion Versi Academic CommercialDeve De Commercial ユーザーが手を使わず ęü¶üLK’ ¸Z にバックドアを開く kŠĆÆÉ¢’‹ O ęü¶ü’ Y‹ ユーザーを誘導する Vehicle Vehicle 2013 2013 ęü¶ü ユーザー ęü¶üLK’ ¸Zk ユーザーが手を使わずに ŠĆÆÉ¢ ’‰ ‹ バックドアを閉める 0b 地面 55 Copyright©2015 Hidekazu Nishimura. LEDの点灯/消灯 [] ユースケース「バックドアを開く」 を記述したシーケンス図（コンテキスト） センサーのOn/Off Academic Version for Teaching Only Commercial Development is strictly Prohibited LEDの光の反射 LEDの光の認知 sd [Interaction] ŠĆÆÉ¢’‹O «block» : I-key’ :/Y‹ęü¶ü : 0b par [] Academic Version for Teaching Only Commercial Development is strictly Prohibited : OSBDS loop [] I-keyの受信可能エリア内での移動検出 «block» : Vehicle 2013 Academic Version for Teaching Only Commercial Development is strictly Prohibited LEDの点滅開始/停止 車両への接近 LEDの点滅の光の反射 Academic Version for Teaching Only Commercial Development is strictly Prohibited [] LEDの点滅の光の認知 I-keyの探索 Academic Version for Teaching Only Commercial Development is strictly Prohibited g Only rictly Prohibited LED点滅部へ足を踏み出す I-keyの検出 ユーザーが差し出した足の検出 探索モードの判断 ユーザーが差し出した足の検出信号の送信 alt [ [] ユーザーが差し出す足が検出される前 ] Academic Version for Teaching Only Commercial Development is strictly Prohibited Academic Version for Teaching Only Commercial Development is strictly Prohibited par [] [ ユーザーが差し出す足が検出される後 ] [else] LEDの点灯/消灯 バックドアの開閉の判断 センサーのOn/Off Academic Version for Teaching Only Commercial Development is strictly Prohibited バックドアのアンロック LEDの光の反射 バックドアを開く LEDの光の認知 loop [] I-keyの受信可能エリア内での移動検出 56 Copyright©2015 Hidekazu Nishimura. ワンステップ・バックドアシステムの システム構成要素を表すブロック定義図 bdd [Package] [ ワンステップ・バックドアシステムのシステム構成要素 ] «block» OSBDS 1 «block» LED 1 1 «block» I-key 移動検出器 1 «block» 非接触センサー «block» «block» 静電容量センサー レーザー・レーダ 57 «block» ソナーシステム «block» BD2020 CU «block» 赤外線センサー Copyright©2015 Hidekazu Nishimura. 「I-key の受信可能エリア内での 移動検出」を表すシーケンス図 58 Copyright©2015 Hidekazu Nishimura. 「ユーザーが差し出した足の検出」 を表すシーケンス図 Only tly Prohibited sd [Interaction] ęü¶üLīWśW_³nś : 0b : I-key’ :/Y‹ęü¶ü «block» «block» : ½Źü : ½ŹüCU 超音波を送信 pa r [ ] Academic Version for Teaching Only Commercial Development is strictly Prohibited 超音波を反射 反射した超音波を受信 [ ] opt [ [ユーザーがLED点滅部へ足を踏み出した場合 ] Academic Version for Teaching Only ] Commercial Development is strictly Prohibited 超音波を反射 反射した超音波を受信 受信した超音波を解析 Academic Version for Teaching Only Commercial Development is strictly Prohibited LED点灯エリアでの足の存在を判断 59 Copyright©2015 Hidekazu Nishimura. コンポーネント間のインタフェース を表すブロック定義図 ソナー インタフェース ソナーCU インタフェース１○ operations ○ operations +LED点灯エリアでの足の存在を判断() +ソナーをOn/Off() +反射した超音波を受信() ソナーCU インタフェース2○ operations +超音波を送信() +ソナーを終了() ソナーCU インタフェース3○ operations +BD2020 CUから，高頻度探索モードへの切り替えコマンドを受信() +BD2020 CUから，低頻度探索モードへの切り替えコマンドを受信() +受信した超音波を解析() LED インタフェース○ operations BD2020 CU インタフェース1○ +LED終了() +LEDの点灯を起動() +LEDの点滅を起動/終了() operations +ユーザーが差し出した足の検出信号の送信() BD2020 CU インタフェース2○ operations +移動検出器から，高頻度探索モードへの切り替えコマンドを受信() +移動検出器から，低頻度探索モードへの切り替えコマンドを受信() +LEDの点滅開始/停止，LEDの点灯/消灯() I-key 移動検出器 インタフェース 1○ operations +探索モードの判断() +受信可能エリア内でI-keyの距離情報を受信() BD2020 CU インタフェース2○ operations +LED点灯エリアからのI-keyの位置を算出() +操作可能エリア内のI-keyの位置を判断し，その位置情報のVehicle2013への送信() 60 Copyright©2015 Hidekazu Nishimura. アクティビティ図による 物理アーキテクチャの総合 act [Activity] [ アクティビティ図による物理アーキテクチャの総合 ] «allocate» «allocate» Vehicle 2013 OSBDS «allocate» «allocate» «allocate» «allocate» I-key 移動検出器 BD2020 CU ソナーCU ソナー LED LEDの消灯 [I-keyなし] 時間カウント 5秒 [高頻度 モード] [低頻度 モード] [高頻度 モード] [ 高頻度モードで1分経過 かつI-keyなし5秒継続] 低頻度探索 モードへ移行 探索モードの判断 操作可能エリア内での I-key情報を受信 バックドアのロック バックドアを開く バックドアの アンロック 移動検出器から， 高頻度探索モード への切り替え コマンドを受信 BD2020 CUから， 高頻度探索モード への切り替え コマンドを受信 ソナーを終了 超音波を反射 超音波を送信 探索頻度 時間調整 ソナーをOn LEDの点灯 LEDの点灯 を起動 LEDの点滅開始 LEDの点滅 を起動 操作可能エリア内の I-keyの位置を判断し， その位置情報のVehicl e2013への送信 LEDの光 を反射 LEDの点滅 を終了 [操作可能なエリアの内で I-keyが検出される場合] [操作可能なエリアの外で I-keyが検出される場合] バックドア を閉める BD2020 CUから， 低頻度探索モード への切り替え コマンドを受信 受信可能エリア 内でI-keyの距 離情報を受信 LED点灯エリアからの I-keyの位置を算出 受信可能エリア内で I-keyの距離を送信 移動検出器から， 低頻度探索モード への切り替え コマンドを受信 [低頻度 モード] [高頻度モードで1分未満 またはI-keyなし5秒未満] 時間カウント １分 LED終了 ソナーをOff 時間カウント １分 高頻度探索 モードへ移行 地面 «allocate» I-keyを探索する [I-keyあり] «allocate» LEDの点滅停止 受信した超音波 を解析 反射した超 音波を受信 ユーザーが差し出 した足の検出信号 の送信 LED点灯エリアでの 足の存在を判断 バックドアの開閉の判断 I-keyを持つユーザーの足 61 Copyright©2015 Hidekazu Nishimura. 低頻度探索モードと高頻度探索モード間 の遷移を表す状態機械図 stm [State Machine] [ 低頻度探索モードと高頻度探索モード間の遷移] [低頻度探索モード状態で I-keyが検出されない場合] 低頻度探索モード To Do = "I-keyを探索する() I-keyを探索する() 探索頻度時間調整（） 探索頻度時間調整() LEDの消灯/終了() LEDの消灯/終了() ソナーOff/終了()" ソナーOff/終了() [低頻度探索モードで I-keyが検出される場合] [高頻度モードで1分経過 かつI-Keyなし5秒継続 ] 高頻度探索モード To Do = "I-keyを探索する() I-keyを探索する() 探索頻度時間調整（） 探索頻度時間調整（） LEDの点滅開始/起動/停止() LEDの点滅開始/起動/停止() LEDの点灯/起動() LEDの点灯/起動() ソナーをOn() ソナーをOn() 受信可能エリア内でI-keyの距離情報を受信（） 受信可能エリア内でI-keyの距離情報を受信（） LED点灯エリアからのI-keyの位置を算出() LED点灯エリアからのI-keyの位置を算出() 操作可能エリア内のI-keyの位置を判断し，その位置情報 操作可能エリア内のI-keyの位置を判断し，その位置情報の のVehicle2013への送信（） Vehicle2013への送信（） 操作可能エリア内でのI-key情報を受信（） 操作可能エリア内でのI-key情報を受信（） ユーザーが差し出した足の検出信号の送信() ユーザーが差し出した足の検出信号の送信() 反射した超音波を受信() 反射した超音波を受信() 受信した超音波を解析() 受信した超音波を解析() LED点灯エリアでの足の存在を判断()" LED点灯エリアでの足の存在を判断() [高頻度モードで1分未満 またはI-Keyなし5秒未満] 62 Copyright©2015 Hidekazu Nishimura. 要求図によるトレーサビリティの確保 ユーザーに対して、自動車が ユーザ ーを歓迎する際、また は、ユーザーのために何かを 準備する際に、おもてなしを感 じさせること «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «derivedReqt» «performanceRequirement» «derivedReqt» «satisfy» «satisfy» «satisfy» «allocate» «satisfy» «satisfy» «satisfy» «satisfy» «allocate» «derivedReqt» «allocate» «allocate» «allocate» «allocate» «satisfy» «satisfy» 63 «allocate» «satisfy» Copyright©2015 Hidekazu Nishimura. システムライフサイクルのマネジメント プロジェクト マネジメント ここを繋ぐ 仕組みが 大変重要 になって いる。 CAD 要求 システムアーキ テクチャと同義 システム 最適化 モデル シミュレー ション/CAE ライブラリ/ 生産/サプライ チェーン データベース PLM (Product Lifecycle Management), SCM (Supply Chain Management) 64 Copyright©2015 Hidekazu Nishimura. まとめ システムズエンジニアリングの標準をもとに基本的な考え方を 紹介し、欧米で幅広い産業に採用されているモデルに基づくシ ステムズエンジニアリング（MBSE）の重要性を述べた。 開発のステージに焦点を絞り、システムズエンジニアリングプ ロセスの概略の流れを示すとともに、システムアーキテクチャ を構築するまでにシステムモデルを記述することの有効性を述 べた。 システムモデルを構造／振る舞い／要求／パラメトリック制約 の4つの柱で記述することができるSysMLの適用事例を紹介し た。また、自動車のパワーバックドアシステムへの適用を試み た企業担当者からの評価を示した。 65 Copyright©2015 Hidekazu Nishimura. 参考文献 Systems Engineering Handbook 4th Edition, INCOSE, 2015 Visualizing Project Management, Third Edition Kevin Forsberg, Hal Mooz, Howard Cotterman, John Wiley & Sons, Inc. INTERNATIONAL STANDARD, ISO/IEC 15288:2015, First edition, 2015-05-15 INTERNATIONAL STANDARD, ISO/IEC 26702, IEEE Std 1220-2005, First edition, 2007-07-15 INTERNATIONAL STANDARD, ISO/IEC/ IEEE 42010, First edition, 2011-12-01 システムズモデリング言語 SysML（A Practical Guide to SysMLの翻訳本） 西村 秀和（監訳），白坂成功，成川輝真，長谷川堯一，中島裕生，翁志強（翻訳），東京 電機大学出版局，2012 モデルベースシステムズエンジニアリング導入の手引き，情報処理推進機構， https://www.ipa.go.jp/files/000033609.pdf 15-A-14 自動車のパワーバックドアシステム開発のためのモデルベースシステムズエンジ ニアリングの適用，「先進的な設計・検証技術の適用事例報告書 2015年度版」，情報処理 推進機構，西村秀和，中本貴之，宮下真 http://www.ipa.gp.jp/sec/reports/20151118.html モデルに基づくシステムズエンジニアリング，西村秀和（総監修），藤倉俊幸（企画・監修）， 日経BP，2015 66 Copyright©2015 Hidekazu Nishimura.
© Copyright 2024 ExpyDoc
