略歴と業績 略歴 1985 年 3 月慶應義塾大学理工学部機械工学科卒業 1987 年 3 月同大学院理工学研究科機械工学専攻修士課程修了 1990 年 3 月同大学院理工学研究科機械工学専攻博士後期課程修了工学博士 1990 年 4 月より千葉大学工学部機械工学科助手 1995 年より同助教授 2

Transcription

1 SEC 高信頼化技術セミナーモデルベースシステムズエンジニアリング入門 ~ システムを考えるハンズオンワークショップ ~ 2015 年 12 月 10 日 ( 木 ) システムズエンジニアリング MBSE 概要 慶應義塾大学大学院システムデザイン マネジメント研究科 教授西村秀和 http: lab.sdm.keio.ac.jp/nismlab/ 1

2 略歴と業績 略歴 1985 年 3 月慶應義塾大学理工学部機械工学科卒業 1987 年 3 月同大学院理工学研究科機械工学専攻修士課程修了 1990 年 3 月同大学院理工学研究科機械工学専攻博士後期課程修了工学博士 1990 年 4 月より千葉大学工学部機械工学科助手 1995 年より同助教授 2007 年 2 月 ~3 月バージニア大学訪問准教授 2007 年 4 月慶應義塾大学先導研究センター教授 SDM 研究科設立準備 2008 年 4 月慶應義塾大学大学院システムデザイン マネジメント研究科教授 2011 年 4 月 ~2012 年 3 月日本機械学会機械力学 制御部門部門長 2012 年 2 月 ~2014 年 1 月計測自動制御学会総務担当理事 (2013 年度副会長兼務 ) 2013 年 1 月 ~ 日本機械学会フェロー 著書 1998 年 MATLAB による制御理論の基礎 ( 共著 ), MATLAB による制御系設計 ( 共著 ) 2007 年 運動と振動の制御の最前線 ( 共著 ) 2012 年 システムズモデリング言語 SysML ( 監訳 A Practical Guide to SysML) 2014 年 デザイン ストラクチャー マトリクス DSM ( 監訳 MIT Press 書籍 ) 2015 年 モデルに基づくシステムズエンジニアリング ( 総監修 ) 西村秀和 2

3 システムズエンジニアリング 2025 のあるべき姿 システムズエンジニアリングの基盤は, アカデミアを横断して一貫性のある形で定義され, 教授される. システムの複雑度と関連するリスクが正しく評価され, 特徴付けられ, そして管理される. システムズエンジニアリングは, 信頼でき回復力のあるシステムを設計し, そして予測するための分析的なフレームワークを与える. モデルベースシステムズエンジニアリングは標準となり, 企業体におけるデジタル機能とともにモデリングとシミュレーションが統合される. システムズエンジニアリングは, 競争力をもって新たなものを生み出し, 大きな価値を与えるように, 産業, 政府, アカデミアを横断して認められる. システムズエンジニアリングは, 技術の評価, 政策の分析を行うために必須の学問として確立される. システム思考は教育のすべてのレベルで教授される. INCOSE Systems Engineering Vision 2025 (June 2014) INCOSE: International Council on Systems Engineering 3

4 MBSE のモチベーション QCD を守りたい トレーサビリティを確保したい Better productのために Better engineeringを実現したい! そのために ドキュメントベースで複雑なシステムを扱うのは辛い! Systems Engineering システムズエンジニアリングをモデルに基づくことで効果的 効率的にしたい Model Based Systems Engineering 活動範囲が社内だけに限定されていない そのために モデルベースで行うシステムズエンジニアリングを国際的に認められた共通言語で行いたい そのために SysML による MBSE 決して SysML や MBSE がモチベーションの源泉や目的ではない 4

5 システムとは何か? システム : 相互に関連し全体として機能するコンポーネントの集まりハードウェア, ソフトウェア, 人, 設備など複数のドメインで構成 環境 境界 :boundary アクター actor: 行為者 ( 人とは限らない ) Use Case1 Use Case 2 System of interest 対象システム System of interest? 5

6 システム : 製品とそれを実現するプロセス 製品階層 System ライフサイクルプロセス 製品 製品 開発 テストプロセス 製造プロセス 販売 サポートプロセス 運用 トレーニングプロセス 廃棄プロセス サブシステム サブシステム IEEE 1220 より - 設備 - 機器 - 工程 - ソフトウェアアプリ - 計算機資源 - 人員 - サプライヤ - ベンダー - 設備 - 機器 / ツール - 工程 - ソフトウェアアプリ - 計算機資源 - 部品在庫 - 人員 - サプライヤ - ベンダー - 品質管理 - 設備 - 機器 / ツール - 工程 - ソフトウェアアプリ - 計算機資源 - スペア部品在庫 - メンテナンスサプライヤ - ベンダー - 設備 - 機器 / ツール - 工程 - ソフトウェアアプリ - 計算機資源 - オペレータ - トレーナー - 設備 - 機器 / ツール - 工程 - 人員 6

7 システムズエンジニアリングとは何か? システムズエンジニアリングの定義 システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段 システムズエンジニアリングでは 開発のライフサイクルの初期段階で顧客のニーズを明確化し 機能要求を定義し 関連する問題をすべて考慮しながら設計のための総合とシステムの妥当性確認を進める システムズエンジニアリングは ユーザーニーズに合致した品質の製品を供給することを目的とし ビジネスとすべての顧客の技術的要求を考慮する INCOSE: International Council on Systems Engineering 7

8 システムズエンジニアリングは アプローチ システムを成功裏に実現するための複数の分野にまたがるアプローチおよび手段コミュニケーションの重要性 ISO 15288:2015 システムライフサイクルステージ 8

9 システムズエンジニアリング標準の歴史 Military Standard MIL-STD- 499 MIL-STD- 499A Software & Systems Engineering Std. Cmt. IEEE Computer Society 米国国家規格協会 American National Standards Institute 電子工業会 Electronic Industries Alliance Interim standard 1994 EIA/IS IEEE 1220 Trial Use Standard 1998 ANSI/EIA IEEE 1220 IEEE Standard for Application and Management of the Systems Engineering Process ISO ANSI/EIA 632 EIA/IS 731 Others.. IEEE 1220

10 ISO 15288:2015 システムライフサイクルプロセス 合意プロセス 取得フ ロセス 供給フ ロセス 組織的プロジェクト実現プロセス ライフサイクルモデルマネジメントフ ロセス 基盤マネジメントフ ロセス ポートフォリオマネジメントフ ロセス 人的リソースマネジメントフ ロセス 品質マネジメントフ ロセス 知識マネジメントフ ロセス 技術マネジメントプロセス プロジェクト計画フ ロセス プロジェクト評価 統制フ ロセス 意思決定マネジメントフ ロセス リスクマネジメントフ ロセス 構成管理フ ロセス 情報マネジメントフ ロセス 測定フ ロセス 品質保証フ ロセス 技術プロセス ビジネス解析, ミッション解析フ ロセス 利害関係者要求定義フ ロセス システム要求分析フ ロセス アーキテクチャ定義フ ロセス 設計定義フ ロセス システム解析フ ロセス 実装フ ロセス 統合フ ロセス 検証フ ロセス 移行フ ロセス 妥当性確認フ ロセス 運用フ ロセス 保守フ ロセス 廃棄フ ロセス 10

11 モデル vs シミュレーション (SEH 4 th Ed.) モデル と シミュレーション には それぞれに意味があるにもかかわらず 間違って受け取られることがある モデル = 対象とするシステム エンティティ 現象 プロセスの抽象または表現 ( 観点 : 形状 機能 性能 ) シミュレーション = 時間に沿ってモデルを実行する特定の環境へのモデルの実装 一般には システム ソフトウェア ハードウェア 人 物理現象の複雑な動的振る舞いを解析する手段を提供する SEH: Systems Engineering Handbook 11

12 コミュニケーションの失敗? このシステムは と から構成され の運用を考えたときに 12

13 図を用いたコミュニケーション このシステムは と から構成され の運用を考えたときに 13

14 モデリングの目的 (1) (SEH 4 th Ed.) 実在するシステムの特徴づけ : 文書で書かれた実在システムのモデリングでそのアーキテクチャと設計を把握する ミッションおよびシステムコンセプトの定式化と評価 : システムライフサイクル初期の段階で モデルによりミッションおよびシステムコンセプト候補を総合 (synthesis) し評価 (evaluate) する システム設計のモデリングと重要なシステムパラメータの影響評価からトレードオフ解析の解空間を探索する システムアーキテクチャとシステム要求のフローダウン : モデルを用いてシステム解のアーキテクティングを支援し ミッションとシステム要求 ( 機能要求 インタフェース要求 性能要求 物理要求の他 信頼性 保守性 安全性 セキュリティなどのいわゆる非機能要求 ) をシステム要素に割り当てる 14

15 モデリングの目的 (2) (SEH 4 th Ed.) システム統合と検証の支援 : システムへのハードウェア ソフトウェアの統合の支援とシステムが要求を充足することの検証の支援にモデルを用いる Hardware-in-the-loop テスト Software-in-the-loop テスト モデルは テスト計画と実行を支援するためテストケースやテストプログラムの他の観点を定義する トレーニングの支援 : システムと相互作用するユーザー ( オペレータ 保守員 その他 ) を訓練するシステムの様々な観点を模擬する 知識の獲得とシステム設計の進展 : システムに関する知識の獲得と組織の知識としての維持のための効果的な手段をモデルは提供する 15

16 システムライフサイクルプロセス中のシミュレーションモデルとシステムモデル SEH 4 th Ed. ビジネス解析とミッション解析 : 解決すべき状況を表す記述モデル ( Descriptive model) は 正しい問題に対処していることを保証する 利害関係者要求定義とシステム要求定義 : 要求を正当なものとし 適切な要求の特定を行う アーキテクチャ定義 : 選択基準をもとに候補となっている選択肢を評価し 他のシステムとの統合など ベストのアーキテクチャを見いだす 設計定義 : 必要な設計データを取得し 最適化のためのパラメータを調整し システム要素に対する実際のデータが得られるよう忠実にモデルを更新する 検証と妥当性検証 : システム環境をシミュレートして検証および妥当性確認データを評価し ( シミュレーションは 直接観察できない重要なパラメータの計算のための入力として観測可能なデータを用いる ) シミュレーションの忠実度の妥当性を確認する 運用 : 実際の動作を反映し 計画 検証 オペレータの訓練のための実行の前に動作を模擬する 16

17 システムズエンジニアリング 要求 と アーキテクチャ 要求の 2 つの鉄則 機能要求 : どのように要求を実現するか? の前に それは何か?, なぜそれが必要か? を明確にする 要求は 測定可能 で テスト可能 でなければならない 高 抽象度 低 アーキテクチャの 3 つのビュー Operational view: システムの使い方 動かし方 Functional view: システムへ要求される機能 Physical view: 機能を実現するハードウェア ソフトウエア Architecting: the art and science of designing and building systems. 17

18 見込み調査, リスク調査 不具合調査 Customer Confirmation Customer Confirmation エンティティ V: ビューの位置づけ 要求の 抽出 概念設計 アーキテクチャ 詳細設計 試験, 検証 製造, 運用 利害関係者の要求 1 Operational view SysML Entity 要求の定義 概念設計, アーキテクチャの選定, 設計に向けた仕様 2 Functional view MATLAB/Simulink 3 Physical view 製作, コード化に向けた仕様 Customer Confirmation Verification and Validation Planning Verification Planning 検証検査, テスト, 実証, 分析 妥当性確認 妥当性確認の計画 検証検査, テスト, 実証, 分析 Mechanical CAD Electronic CAD Program code 購入, 製作, コード化 解決策の達成 18

19 二元 V 字開発モデル (Dual Vee Model) Architecture Vee 要求を満足するシステムの完成 利害関係者の要求 Entity Vee 19

20 二元 V 字モデルによるプロセスの理解 Architecture Vee 利害関係者の要求 早い段階での手戻り 要求を満足するシステムの完成 Entity Vee アーキテクチャの検討, 決定では, サブシステムやコンポーネントの実現可能性を検討しながら進めることがある. 20

21 二元 V 字モデルによるプロセスの理解 Architecture Vee 利害関係者の要求 致命的な手戻り 要求を満足するシステムの完成 Entity Vee コンポーネント, サブシステムの検証, 妥当性確認を順序行い, システムとしての検証, 妥当性確認を行って行く. 21

22 Customer Confirmation Customer Confirmation エンティティ V : 検証と妥当性確認 要求の 抽出 概念設計 アーキテクチャ 詳細設計 試験, 検証 製造, 運用 利害関係者の要求 Entity 要求の定義 アーキテクチャの選定とシステム仕様 製作, コード化に向けた仕様 Customer Confirmation Verification and Validation Planning Verification Planning 購入, 製作, コード化 検証検査, テスト, 実証, 分析 シナリオ妥当性確認 妥当性確認のHuman in 計画 the Loop Simulation 検証 検査, テスト, オフノミナル 実証, 分析 HILS/SILS ノミナル 22

23 IEEE 1220 systems engineering process SE プロセスへの入力 要求の分析 要求の基準要求の妥当性確認確認された要求の基準 機能の分析 機能の検証 総合 設計の検証 機能アーキテクチャ 検証済み機能アーキテクチャ 物理アーキテクチャ 検証済み物理アーキテクチャ統制 要求と制約の矛盾 要求のトレードオフと影響 分解と要求の割り当に関する候補 分解割り当てのトレードオフと影響 設計解の要求と候補 設計解のトレードオフと影響 SE プロセスの出力 要求のトレードオフ分析と評価 システム解析 機能のトレードオフ分析と評価 設計のトレードオフ分析と評価 23

24 モデルベースでシステムを考える とは? モデル * に基づくシステムズエンジニアリング 仕様書など文書だけではすぐに理解できないことが 図的に表現することで理解が容易になる 協働してシステム開発をするには 共通言語が必要であり それをサポートするには図的な言語が有効である モデルを再利用することにより開発の効率化が期待できる モデルを用いて抽象度を上げることにより革新に導く * 注 : 実行可能ではないモデルを含む 24

25 システムモデルの記述 システムモデル表記法 :SysML(Systems Modeling Language) システムを構造, 振る舞い, 要求, パラメトリック制約の観点で図的に表現することができる 図的表現により 開発者の思考を支援できる 複数のドメインにまたがる開発 分業化された開発環境で 共通言語として利用できる システム開発プロセスの中で要求のトレーサビリティが確保される 構成管理 変更管理が容易になる ーあるサブシステムやコンポーネントの要求の変更や設計の変更が生じた際に 他のサブシステムやコンポーネントにどのような影響が及ぶかを判断できる 25

26 SysML で何ができるのか? システムを構成するサブシステムに対する機能要求とその振る舞いを把握できる 設計変更があった場合にも 要求のトレースが可能なため その影響を容易に把握できる SysML を用いることで 開発者の思考を支援し ドメインをまたがる協働作業が可能となる コンカレントデザインを促進するフレームワークが実現可能となる ただし 組織の硬直化などが弊害となり得る 参考資料 : システムズモデリング言語 SysML (A Practical Guide to SysML 翻訳本 ) 西村秀和 ( 監訳 ) 訳者 : 白坂成功, 成川輝真, 長谷川堯一, 中島裕生, 翁志強 著者 :Sanford Friedenthal, Alan Moore, Rick Steiner 出版社 : 東京電機大学出版局 (2012 年 5 月 10 日 ) 26

27 システムモデルを支える 4 つの柱 構造 ibd act 振る舞い 要求 req par パラメトリック制約 数式表現 運動方程式 パラメータによる性能評価など 27

28 SysML ダイアグラムの分類 SysML: Systems Modeling Language パッケージ図 SysML ダイアグラム 要求図振る舞い図パラメトリック図構造図 ユースケース図 シーケンス図アクティビティ図状態機械図 ブロック定義図 内部ブロック図 28

29 コンカレントデザインを促進するフレームワーク トレーサビリティ外部からの根拠要求 システム仕様書 ビューポイント 構造 要求 システムモデル 振る舞い パラメトリック制約 解析 性能評価 解析モデル ダイナミクス解析 制御システム解析 1D-CAE など ハードウェア設計モデル 電気回路設計モデル ソフトウェア設計モデル テスト方法テストモデル 29

30 システムモデルを SysML ダイアグラムで表現する ( 例 ) パッケージ図 要求図 振る舞い図 パラメトリック図 構造図 pkg req act seq stm uc par bdd ibd モデル編成の定義 SoI と外部システムの関係 SoI のユースケースシナリオ SoI に対する要求 機能および物理アーキテクチャ システムの分析 システムの検証 30

31 システムモデルで明確にすること ライフサイクルステージ コンセプト 開発 製造 運用と保守 廃棄 それぞれについて検討する必要がある. さもなければ, システムは実現しない. それぞれのステージについてコンテキスト ( 文脈, 脈略 ) を最初に考え, 抜け漏れがないことを確認する. その際, 利害関係者の要求や懸念事項をすべて洗い出す. その上で, 対象システムの境界, ユースケース, 機能性を明確にする. 次に対象システムの内部を分析し, 総合する. 最初に機能を分解して, その分解された機能をシステム構成要素に割り当てる. これにより, システム構成要素間のインタフェースが定義され, アーキテクチャの候補が導出できる. 要求や懸念事項に応じて View( 観点 ) を設定し, トレードオフ分析によりいくつかの候補の中から適切なアーキテクチャを選定する. 31

32 SysML による MBSE のサポート システム仕様の決定 以下の活動の反復 ブラックボックスのシステム要求の取得と分析 ( コンテキストレベル ) 要求管理ツールでの文書ベースでの要求の獲得 SysMLモデリングツールへの要求のインポートシステムのユースケースからシステムレベルでの機能の特定ユースケースと要求間のトレーサビリティの獲得ユースケースシナリオの実現 : アクティビティ図, シーケンス図, 状態機械図システムコンテキスト図の創出システム検証をサポートするシステムのテストケースの特定 要求を満たすシステムアーキテクチャ候補の開発 ブロック定義図を用いたシステムの分解アクティビティ図またはシーケンス図を用いたパート間の相互作用の定義内部ブロック図を用いたパート間の相互接続の定義 32

33 SysML による MBSE のサポート ( 続き ) 所望のアーキテクチャの評価と選択のためのエンジニアリング解析と トレードオフ分析の実行 性能, 信頼性, コスト, その他の重要なプロパティの分析をサポートするためのパラメトリック図を用いたシステムプロパティの制約の獲得 システムプロパティの予算を決定するためのエンジニアリング解析の実行 ( 通常, 別のエンジニアリング解析ツールで行われる ) コンポーネント要求の規定とシステム要求に対するコンポーネント要求のトレーサビリティの規定 アーキテクチャにおける, 各コンポーネント ( ブロック ) のための機能要求, インタフェース要求, 性能要求の獲得 システム要求へのコンポーネント要求のトレース システムレベルでのテストケースの実行 システム設計に関する要求の充足の検証 33

34 ユースケース図 システムの使われ方と動作 対象とするシステムはどのように使われ, どのような動作をするのか? 対象システムの境界はどこか? 境界 :boundary 外部システム 1 System of interest 対象システム ユースケース 1 ユースケース 2 外部システム 3 外部システム 2 34

35 効果指標 (Measures of Effectiveness) の把握 ミッションレベルの性能要求 : パラメトリック図 利害関係者 ( 顧客など ) の価値 <<moe>> 運用コスト oc 運用の目的関数 avail ert eop <<moe>> 運用の可用性 <<moe>> 緊急時の応答時間 35 <<moe>> 緊急事態の発生確率

36 機能の明確化とインタフェース (1) コンテキストレベルでの外部システムとのインタフェース システムのユースケース ( 使われ方 動作 ) をシーケンス図により記述する. パート間の相互作用 外部システム 3 システム メッセージ ( 相互作用 ) 自己メッセージ 機能を記述するユースケース 2 をシーケンス図で記述し システムの機能の抽出を行う システムは 外部システムからメッセージを受けるという機能 1 をもつ システムは 自己メッセージを処理するという機能 2 をもつ 次に 抽出された各機能を実現するシーケンスを考える 36

37 内部ブロック図システムコンテキスト図 外部システムと対象システムとのインタフェースの把握 アイテムフロー コネクタ ポート ibd [ システムコンテキスト ] 外部システム 1 外部システム 2 対象システム 外部システム 3 37

38 機能の明確化とインタフェース (2) システムの分解を検討する ブロック定義図 システム サブシステム 2 はサブシステム 1 から同期メッセージを受け 自己メッセージを処理する サブシステム 2 はサブシステム 1 にメッセージを返信する サブシステム1 サブシステム2 機能 1, 2を実現するシーケンスを検討サブシステム間の相互作用を明確にする 各サブシステムの生存線上にそれぞれの機能が抽出される サブシステム 1 サブシステム 2 同期メッセージ 返信メッセージ 38

39 機能のコンポーネントへの割り当て (1) アクティビティ図でさらに信号のフローを検討する コンポーネントとインタフェースを明確化する システム In : パラメータ 開始ノード : アクション 1-1 制御フロー オブジェクトフロー : アクション 2 : アクション 1-2 ピン Out : パラメータ アクティビティ終了ノード 39

40 機能のコンポーネントへの割り当て (2) アクティビティ図でさらに信号のフローを検討する コンポーネントとインタフェースを明確化する サブシステム 1 サブシステム 2 開始ノード In : パラメータ : アクション 1-1 : アクション 2-1 制御フロー オブジェクトフロー Out : パラメータ : アクション 1-2 ピン アクティビティ終了ノード : アクション

41 機能のコンポーネントへの割り当て (3) アクティビティ図でさらに信号のフローを検討する コンポーネントとインタフェースを明確化する サブシステム 1 サブシステム 2-1 開始ノード サブシステム 2-2 アクティビティ終了ノード In : パラメータ : アクション 1-1 : アクション 2-1 制御フロー : アクション 1-2 オブジェクトフロー : アクション 2-2 ピン Out : パラメータ 41

42 ブロック定義図 シーケンス図とアクティビティ図での検討により サブシステム 2 は サブシステム 2-1, 2-2 に分解された システム サブシステム 1 サブシステム 2 サブシステム 2-1 サブシステム

43 内部ブロック図 内部ブロック図によるコンポーネント間のインタフェースの記述 [ サブシステムの内部構造 ] ibd [Block] システム [ システムの内部構造 ] サブシステム 2 サブシステム 11 サブシステム サブシステム

44 状態機械図 ( ステートマシン図 ) イベントで生じる状態の遷移 状態 1 トリガー 1[ ガード条件 ]/ 遷移効果 イベント =sd: メッセージ =act: アクション 状態 2 entry/ 振る舞い 1 do/ 振る舞い 2 exit/ 振る舞い 3 トリガー 3 トリガー 2 状態 3 44

45 要求の詳細化とトレーサビリティの確保 <<Requirement>> 対象システムの要求 対象システムは xx の状況で へ すること + <<Requirement>> R1 外部システムが xx の状況で すること <<Requirement>> R2 に対応すること <<derivedreqt>> <<derivedreqt>> <<derivedreqt>> <<Functional Requirement>> 機能要求 1 <<satisfy>> <<activity>> アクション 1 <<allocate>> <<block>> サブシステム1 IPA/SECセミナー <<Functional Requirement>> 機能要求 2-1 <<allocate>> <<block>> サブシステ 2-1 <<satisfy>> <<activity>> アクション <<Functional Requirement>> 機能要求 2-2 <<allocate>> <<block>> サブシステム 2-2 <<satisfy>> <<activity>> アクション 2-2

46 SysML の活用で見えてくること システムをモデルで表現する アーキテクチャ 構造 / 振る舞い / 要求 / パラメトリック制約 - What そもそも 何をしなければならないのか? 革新に導くことに繋がる オペレータや外部システムとの相互作用の明確化 サブシステム間のインタフェース 最適化 問題 やトレードオフ 問題 の設定 定義 アーキテクチャと仕様決定までの要求のトレース 46

47 コンカレントデザインを促進するフレームワーク トレーサビリティ外部からの根拠要求 システム仕様書 ビューポイント 構造 要求 システムモデル 振る舞い パラメトリック制約 解析 性能評価 解析モデル ダイナミクス解析 制御システム解析 1D-CAE など 製品データ管理 (PDM) 部品表 (BOM) 物理設計 (CAD) ハードウェア設計モデル 電気回路設計モデル ソフトウェア設計モデル テスト方法テストモデル 47

48 SLIM (System Lifecycle Management) プロジェクトマネジメント SLIM by intercax CAD 要求 システムアーキテクチャと同義 最適化 システム モデル シミュレーション /CAE 生産 / サプライチェーン ライブラリ / データベース PLM (Product Lifecycle Management), SCM (Supply Chain Management) 48

49 INDUSTRIE 4.0 に向けて... システムズエンジニアリングと Cyber Physical System の意味 ライフサイクル全般にわたるモデリング それぞれのステージに応じて適切なデジタルモデルを持つ デジタルモデルは実システムと整合し 正しい情報を持つ必要がある INDUSTRIE 4.0 では サプライチェーン 生産の効率化にデジタルモデルを活用することの重要性を強調 2030 年の実現を目指す 車両横変位 車両 駆動 制動トルク信号 要求抽出 コントローラ (DYC) 車両ハンドル角車速ヨーレート横滑り角 概念設計 アーキテクチャ 詳細設計 試験 検証 製造 運用 保守 廃棄 開発 49

50 エレベータに対する要求 ( 例 ) エレベーターは ビルの各階から コール ( 呼び ) を受けること ( 入力に関する要求 ) エレベーターは 想定される乗員に対して エレベーターを呼んでいることを表示すること ( 出力に関する要求 ) エレベーターは 緊急コールに対してビルにある標準電話を利用すること ( 外部インタフェースに関する要求 ) The Engineering Design of Systems, - Models and Methods -, 2 nd Edition, Dennis M. Buede, John Wiley & Sons, Inc. 50

51 ユースケース図 51

52 シーケンス図 ( コンテキストレベル ) ライフライン上に機能が並んでいる 52

53 シーケンス図 ( コンテキストレベル ) 53

54 コンテクストレベルでの機能分析 エレベータシステムの機能 54

55 ユースケース ドアを開く シーケンス図 55

56 アナリシスレベル 01 での機能分析 エレベータコントローラの機能 56

57 ブロック間のインタフェース 57

58 要求を詳細化したユースケース テストケース 詳細化 58

59 サブ機能 エレベータを呼ぶ 59

60 サブ機能 目的階に移動する 60

61 サブ機能 ドアを開く 61

62 サブ機能 ドアを閉じる 62

63 ブロック定義図 ( アナリシスレベル ) 63

64 エレベータシステムの状態機械図 64

65 ブロック定義図 : フロアでのエレベータ待ち時間 65

66 パラメトリック図 : フロアでのエレベータ待ち時間 待ち時間は何によって決まるのか? 乗客の操作はどの程度頻繁か? 66 緊急時のドア開停止などを決める要因は何か?

67 まとめ 複数のドメインで構成されるシステムや オペレータの介在する複雑なシステム (System of Systems (SoS) の一つ ) を設計するために MBSE( モデルベースシステムズエンジニアリング ) の活用が重要であることを述べた モデルを用いたシステム開発では システムモデルの記述に際して 構造 / 振る舞い / 要求 / パラメトリック制約 の 4 つの柱で考えることが重要である SysML はこれをサポートしている SysML の適用手順を概説するとともに エレベータ開発の事例を紹介し MBSE で思考する過程を示した 67

68 参考文献 Systems Engineering Handbook 4 th Edition, INCOSE, 2015 INTERNATIONAL STANDARD, ISO/IEC 15288:2015, First edition, Visualizing Project Management, Third Edition Kevin Forsberg, Hal Mooz, Howard Cotterman, John Wiley & Sons, Inc. IEEE 1220: For Practical Systems Engineering, Teresa Doran システムズモデリング言語 SysML(A Practical Guide to SysML の翻訳本 ) 西村秀和 ( 監訳 ), 東京電機大学出版局,2012 The Engineering Design of Systems, - Models and Methods -, 2 nd Edition Dennis M. Buede, John Wiley & Sons, Inc. The Art of Systems Architecting, Second Edition, Mark W. Maier, Eberhardt Rechtin, CRC Press, 2002 MBSE wiki: 複雑化する統合システム (SoS) の開発方法論モデルベースシステムズエンジニアリング導入の手引き,IPA/SEC: モデルに基づくシステムズエンジニアリング, 西村秀和 ( 総監修 ), 藤倉俊幸 ( 企画 監修 ), 日経 BP,2015 IPA/SECセミナー 68