ETWest2015:SEC 先端技術 入 門ゼミ モデルベースシステムズエンジニアリング (MBSE) 入 門 2015/6/10( 水 )11:40 ~ 12:25 株式会社コギトマキナ代表取締役 システムズ アーキテクト 鈴鈴 木尚志
アジェンダ 背景 MBSEとは何か SEとは モデルとは SysMLとは 目的は MBSE の概要を把握すること 2
この絵を理理解しよう 株 コギトマキナ 複製及び転載禁 止
MBSE が注 目を集めている!? 通常 5 年年かかる新 車車開発をわずか 29 ヶ 月で完了了 セーフティクリティカルな鉄道信号 制御ソリューションのグローバルな安全性および信頼性の標準へのコンプライアンスを促進する統合開発環境を構築 太陽光発電システムのための遠隔制御 管理理システムにおいてサブシステムとソフトウェアの再利利 用を要求分析からテストまで 一貫して促進 およそ 25% の障害が減少 開発時間が 60% 減少し 製品ごとにおよそ 10,000 ユーロの節約が達成 防衛システムの開発ではアプリケーションの信頼性と安全が改善され製品化の時間を 40 % 短縮 コンシューマエレクトロニクスの分散 協調設計と 言う観点からの MBSE への取り組み 4
話題になっている背景 5
IoT SoS M2M CPS なんだか似たような匂いのする 言葉葉達を最近 良良く 耳にするようになった クラウド iapp,google Play ドローン? 自動運転 6
最近の 開発 製品 のカテゴリーも様々 システムズ開発の成果物は有形の モノ と無形のサービスのような コト に 大別できる 最近は モノ コトつくり という 言葉葉も 7
SoS の例例 : 交通システムの拡張 PTPS( 公共 車車両優先システム ) http://www.utms.or.jp/japanese/system/ptps.html h"p://www.seibubus.co.jp/ptps/
その他 SoS の例例 スマートグリッド 総務省省 HP より 航空システム 国 土労働省省 HP より スマート医療療 厚 生労働省省 9 HPより 自動 車車 財団法 人 日本 自動 車車研究所 HP より
システムズ開発の様々な課題 システムの複雑化に伴う課題 システムの派 生やシリーズ化に伴う課題 要求の不不適切切な分析 / 定義に伴う課題 要求変更更への対応に伴う課題 大きな 手戻りの発 生に関する課題 関係者間のシステム開発に対する意識識の統 一や均質化に関する課題
様々な複雑さ さまざまなややこしさ 大規模化 モノそのものの機能の肥 大化 既存システムの新規システムの組み合わせによる新たなサービスの誕 生 カーナビ + スマホ + 情報センタ + 交通管制システム + 信号管理理システム =? 市場の動向 新たな技術領領域の発 生 既存システム化 +α ディペンダビリティ / セーフティ / セキュリティ IEC61508 ISO26262 IEC62304 ISO13485 ISO14971, ISO13482 ISO/IEC15408 IEC62443, IEC62366 製造 / 運 用 / 管理理の環境に対する負荷軽減 迅速な開発ー短命な事業 11
System of Systems 様々なシステムが複雑に関連している状態で 対象とするシステムを設計することは極めて難しい システム A 対象システム System of interest システム B システム C システム D 12
成功させるために相克しなくてはならないこと 複雑さ 不不確実さ 価値観の多様性 成功へ 13
システム開発で解くべき課題は何? 生産性の向上 製品安全性の確保 開発能力の向上 開発コストの削減 新製品の開発 市場の拡大 新技術の開発 設計品質の向上 製造品質の向上 開発期間の短縮 14
成功を阻害する 手戻り あまりに多くの 欠陥が開発初期に作りこまれている! 欠陥が発 見見された時点では遅すぎる! 作りこまれた障害数 発見障害数 開発 統合 SW/HW 統合 テスト 運 用 15
MBSE がめざすもの できるだけ上流流で問題を解決し 手戻りを減らす できるだけ早く妥当性や正当性の確認をする 作りこまれた障害数 発見障害数 開発 統合 SW/HW 統合 テスト 運 用 16
システムズ開発の成功と MBSE システムズ開発の 成功 とは 予想可能なスケジュールと予算の範囲内で エンドユーザーのニーズを満たす品質の 高いシステムズの開発が 行行われること けれども成功するのは困難 機能は増やし 品質は向上し より短い時間で そしてより少ないリソースで 関係者の多様化 ドキュメントの爆発的増 大すりあわせ 工程への 高負荷 MBSE が話題になっている理理由 システムズ開発の困難 ( 複雑さ 不不確実さ 価値観の多様性 ) を克服し 開発を成功に導くものだ と考えられているから 17
背景 まとめ 近年年の開発は なかなか成功しない 成功のためには 手戻りを減少させる必要がある MBSE はこれに効果があると考えられているる 18
MBSE とは 19
製品開発プロセスへの効果 手戻りを防 止する 設計根拠を明確にする MBSE 導 入の効果 アーキテクチャ トレードオフ 多 人数開発への効果 情報の錯綜を減少させる 複数製品開発への効果 再利利 用の単位を明確にする 派 生開発で 手を 入れる部分を明確にする さまざまな事例例 ehealth, Smart Grids, Intelligent Transportation Systems, Smart Homes and Cities など モデルベースシステムズエンジニアリング導 入の 手引き https://www.ipa.go.jp/files/000033609.pdf 20
エレベータのサンプル モデルベースシステムズ エンジニアリング導 入の 手引き より 21
MBSE におけるモデルの例例 ( 配布資料料省省略略 ) モデルベースシステムズエンジニアリング導 入の 手引きを例例に https://www.ipa.go.jp/files000033609.pdf 22
SE の範囲 IPA ESPR より
SE とは何か?( 公式 ) システムズエンジニアリングの定義 システムを成功裏裏に実現するための複数の分野にまたがるアプローチおよび 手段 システムズエンジニアリングでは 開発のライフサイクルの初期段階で顧客のニーズを明確化し 機能要求を定義し 関連する問題をすべて考慮しながら設計のための総合とシステムの妥当性確認を進める システムズエンジニアリングは ユーザーニーズに合致した品質の製品を供給することを 目的とし ビジネスとすべての顧客の技術的要求の両者を考慮する INCOSE: International Council on Systems Engineering 24
SE の歴史と進化 システム開発の成功 エンジニアリングプロセス 1990 年年 NCOSE の設 立立 1969 年年世界初のシステムズ エンジニアリング標準 1940 年年代ベル研 システムは要素の総和ではない! エンジニアリングマネジメント オペレーションズ リサーチなど 25
システムズエンジニ ア と 言う職能 ( ハードウェアとソフトウェアの区別なく ) システム を開発する 人 システムズエンジニア SE さん 情報系システムを開発する 人 26
SE とは何か?( 解釈 ) システムズエンジニアリングの定義 手法の名前でも プロセスの名前でもなく エンジニアリング領領域のこと SE の 目的は システムズ開発の 手戻りを減らす こと システムズエンジニアリング 工程の多くは 関係者の合意を取り付けるために 妥当な 正しさを検証すること システムズエンジニアリングは 以下の 3 つの活動を繰り返しおこなうことになる 1. 要求をまとめる 2. アーキテクチャを構築する 3. 成果物を次 工程に渡す MBSE はモデルを利利 用した 効率率率のよい SE にすぎない SE そのものの歴史はとても古い 科学的な問題分析 27
なぜモデルを使うのか? 28
最近 ちょっと鬱陶しい ドキュメントの爆発的増 大を何とかしたいすりあわせ 工程への 高負荷を何とかしたい トライ & エラーを減少させたい 要求の妥当性や 上位設計の正当性を確認したい モデルを使え! 多様化した関係者間のコミュニケーション問題を解決したい 実機でしかわからない 状況をなくしたい そのために上流流レベルで検証 ( フロントローディング型開発 ) を 29
モデル 物事 ( モノ コト ) をある側 面 ( 関 心事 ) から 見見て単純化したもの M P is a model of モデル M によって P が説明できる という意味 M において論論理理的に P が真 M satisfies P 大事なことは あるモノゴト を説明するという 目的のためにモデルは作られるということ! 説明したいことは何?
モデリング = モデル化 現実に対して ある仮定をおいて単純化してから抽象的なモノに落落とし込んで 行行くこと 腕の 見見せ所は 単純化の仕 方 同じ現実を 見見ていても 人により現実の捉え 方が違うので モデル化の仕 方も異異なる!? 現実には無限の側 面がある 現実をどういった 目的で どのような側 面 ( 観点 ) から切切るか? 他 人がモデル化したものを製品設計に活 用するときなどは モデル化でどのような仮定 ( どのような観点 何を省省略略しているか? など ) がおかれているかをきちんと把握しておく必要がある
SE に なぜモデルをつかうのか 目的 理理解 特に共通理理解 理理解 認識識 定義 ( 仕様 ) と例例 示をうまく使う 外延 / 内包 開発の成功のため 手戻り をなくすため多くの関係者の合意をとるため 大事な事は 説明したい事がある ということ そのためにわかりやすい観点を設定する 32
MBSE は SE を改善したもの 成功 迅速 誤解なし 合意を確実にとりつける 手戻りを減らす 妥当性 正当性 理理解しやすく 誤りのない資料料を作る トレードオフ Arch. Decision SysML でモデルを記述 33
MBSE の利利点 (INCOSE tutorial より ) システムの要求と設計に関する共通理理解の拡 大 要求の妥当性を確認する 分析と設計の間に共通の 土台を築く リスクを発 見見しやすくする 複雑なシステムの開発における管理理性の向上 統合されたモデルに対し 複数のビューによって問題領領域を分離離 システムモデルの階層化によってトレーサビリティを 高める 要求 / 設計変更更による影響分析を容易易にする 差分的開発と漸進的な追加改善をサポートする 設計品質の改善 エラーと曖昧さを減らす 表現の正確性を 高める 初期段階 / 進 行行中の妥当性確認と検証でリスク低減 その他ライフサイクルを通じた価値 ( 例例 : トレーニング ) 現場知識識の取り込みを拡 大 34
なぜモデルを使うのか まとめ モデルは説明したいものをうまく理理解してもらうための 方便便ともいえる 近年年の開発は 複雑さ 不不確実さ 価値観の多様性 に邪魔され なかなか成功しない 明瞭で 迅速な合意のためにモデルを使う! そして合意はとれた? 35
モデリング 言語 SysML とは 36
OMG の定義 : SysML この仕様はシステムズ エンジニアリングのアプリケーション いわゆる Systems Modeling Language (SysML) のためのモデリング 言語の 一般的な 目的を定義する SysML は複雑なシステムの広範囲に及ぶ仕様化 分析 設計 正当性 妥当性の検証をサポートする これらのシステムはハードウェア ソフトウェア 情報 プロセス パーソネル 設備などを含みます * SysML はシステムズ エンジニアリングにおける問題の広い範囲をモデリングするために 単純かつ強 力力な構成概念念を提供するためにデザインされたもの 特に要求 構造 振舞い そしてアロケーション そしてシステムズ エンジニアリングの分析をサポートするためのシステムプロパティへの制約を明確化する点において効果的 ** OMG Systems Modeling Language (OMG SysML) Specification, November 2008 *Part 1 Introduction ** Scope SysML の仕様の完全版は h"p://www.sysml.org/specs.htm
SysML ダイアグラム種別 まずは 何の 目的の図 面か? を考えよう 観点 ダイアグラム名 対応するUML ダイアグラム 記述の 目的 構造 パッケージ図 モデルの整理理 ブロック定義図 クラス図 静的構成要素とそれぞれの関 係 内部ブロック図 複合構造図 静的構成要素の内部構造 パラメトリック パラメトリック図 該当なし 数式などを 用いた制約 振舞い ユースケース図 システムの提供する機能 アクティビティ図 入出 力力 処理理のフロー シーケンス図 メッセージ交換の時系列列 ステートマシン図 イベントと 状態遷移 要求 要求図 該当なし 要求項 目と それぞれの関係! 一枚の図には1つのミッションがある 38
SysML SysML の仕様の具体的内容は http://www.sysml.org/specs.htm 参照のこと
SysML モデリングのキモ SysML はあくまで 言語であり 使ったからといって成功が保証されるものではない SysML モデリングで留留意すること 分割統治 4 つの観点 要求 構造 振舞い パラメトリック制約 統合 枚挙 トレーサビリティ 40
科学的な問題分析のための規則 分割統治 明証性 わたしが明証的に真であると認めるのでなければ どんなことも真として受け 入れないこと 分析 わたしが検討する難問の 一つ 一つを できるだけ多くの しかも問題をよりよく解くために必要なだけの 小部分に分割すること 総合 分割統治 わたしの思考を順序にしたがって導くこと 単純なものから複雑なものへ 部分が終わったら全体へ 枚挙 すべての場合に 完全な枚挙と全体にわたる 見見直しをして なにも 見見落落とさなかったと確信すること 抜け漏漏れがないように デカルト 方法序説 1637( 谷川多佳 子訳 岩波 文庫 1997 年年 ) 41
MBSE の全体像 42
株 コギトマキナ 複製及び転載禁 止
全体最適 4側面からシステムを捉える システム ズ エンジニアリング 分割統治とフィードバックループ 超上流ーユーザー要求から設計要求まで 候補から根拠を持って1つを選ぶ 把握と合意 トレーサビリティ 株 コギトマキナ 複製及び転載禁 止
超上流流ーユーザー要求から設計要求まで MBSEの活動を 一 言で 言えば 1. 要求をまとめる 2. アーキテクチャを構築する 3. 成果物を次 工程に渡す そして合意はとれた?! 一枚の図には 1 つのミッションがある
システム ズ エンジニアリング システムとは 定義された 目的を成し遂げるための 相互に作 用する要素 (element) を組み合わせたものである これにはハードウェア ソフトウェア ファームウェア 人 情報 技術 設備 サービスおよび他の 支援要素を含む INCOSE システムズエンジニアリングハンドブックの定義 ソフトウェアエンジニアリングだけのためのものではない
システムズエンジニアリングの 骨 目的は開発の成功 目標は構想設計 ゴールは合意 分割統治しながら スケジュール 予算 品質を満たすような開発の全体最適を 行行なうこと Function Driven 反復復的プロセス - 慌てない ツールは使うべし トレードオフスタディ 47
全体最適 全体を考えること 部分を考える 前に 考えること 部分を考えた 後にも 考えること こうなってませんか? 部分最適の総和が全体最適である 優秀なエンジニアがそれぞれ頑張れば
分割統治とフィードバック ループ システム エンジニアリングの最 大の特徴 複雑なシステム開発では 上位レベルの問題点が下位レベルの細部検討時に明確になるという事実 サブシステムの設計時に気付いた問題点に基づき 前 工程の成果であるシステム設計を 見見直すことが可能な フィードバック ループ が必要 フィードバック ループ こそ より品質の 高いシステムを作り上げるための SE の中核プロセス 戻ってよし ただし 手遅れになる前に
IEEE 1220 systems engineering process SE プロセスへの入力 要求の分析 要求の基準要求の妥当性確認確認された要求の基準 機能の分析 機能の検証 総合 設計の検証 機能アーキテクチャ 検証済み機能アーキテクチャ 物理アーキテクチャ 検証済み物理アーキテクチャ統制 要求と制約の矛盾 要求のトレードオフと影響 分解と要求の割り当に関する候補 分解割り当てのトレードオフと影響 設計解の要求と候補 設計解のトレードオフと影響 SE プロセスの出力 要求のトレード分析と評価 システム解析 機能のトレード分析と評価 設計のトレード分析と評価 50
二元 V 字モデルとエンティティ V 入れ 子になったシステム具体 抽象のフィードバックも意識識
4 側 面からシステムを捉える 52
なぜワザワザ要求図を作るのか? トレーサビリティを 作りこむ ため 管理理するためではない 作業効率率率 例例えば USDM の Excel 表を作成する際には Excel の上で やらなければならない ということ Excel で試 行行錯誤しながら体裁を整えつつ作業をするのは 非効率率率的 53
要求と設計の関連付け 54
安全性の 目標 をモデル駆動開発で検証する 要求図を 用いた 安全 関係の要求のトレーサビリティ コンセプト 4 3 2 3 2 1 4 55
設計要素と設計要素の関連付け 振る舞いの設計要素と構造の設計要素の関連づけ 56
候補から根拠を持って 1 つを選ぶ 再利利 用性 生産性 様々なメリット間のトレードオフ 拡張性 保守性 その結果がアーキテクチャに反映される ( 株 ) コギトマキナ複製及び転載禁 止
トレードオフスタディのためのモデル 58
把握と合意 一発で的には当たらない 利利害関係者は多岐にわたる 顧客 エンジニア エレキ メカ SW 制御 知識識 関 心事は関係者ごとに異異なる インフォグラフィックスを有効利利 用 技術 用語 / 技術詳細は要注意 記録をとること 証跡をとること まずは全体像を把握する 言った 言わないの議論論をしない モデルを作って この前提で 合意
的をよく狙えば 一発必中できる? 的をよく狙えば 一発必中できる? 議論論を尽くせば 要求は固まる? 動いている的を狙う ことも多い どれが的なのか? もわからない ユーザーは気まぐれ システムは成 長し続ける 設計して初めて分かる問題点も多い モデルを使って理理解しやすくしたい
同じ要求を聞いても関 心事は異異なる 信号が 赤になったら 止まること 赤 色 の波 長の上限値 下限値は? 止まる 時は エンジンも 止める? 赤 認識識後何秒以内に 止まる? 遠くの交差点が 赤でも 止まる? どの位置で 止まる? 赤で なくなったら 走る? 赤の時 だけ 止まる?
企業における MBSE の 目的例例 システム製品開発の成功 開発業務効率率率の向上 開発 手戻りの減少 円滑滑なコミュニケーション 様々なトレードオフ分析 企画から保守までの確実なトレーサビリティの確保 機能安全基準対応 系列列製品開発の成功 車車輪輪の再発明をしない 最後は 合意! 一枚の図には1つのミッションがある 62
MBSE をざっくりと まとめ システムズエンジニアリングの 目的は 分割統治しながら スケジュール 予算 品質を満たすような開発の全体最適を 行行なうこと MBSE は 古くからのシステムズエンジニアリングを モデルを使うことで便便利利に したもの MBSE による共同作業の改善と 文書の明確化 正確化が 開発効率率率の向上 開発期間の短縮 そして製品品質の向上をもたらす SysML は システムを様々な観点でモデル化するために適した 言語 モデル化の 目的と対象を明確にしなくては MBSE の効果は出ない 一枚の図には 1 つのミッショ 63! ンがある
最後に 64
モデリング成功のために! 大き過ぎたら分割統治! 一枚の図には 1 つのミッションがある! 説明したいことは何?! そして合意はとれた? 65
よくある落落とし 穴 (SysML) SysML=MBSEではない 目的を考えてから 道具を探せ! 道具の お勉強 が 目的になると必ず! 失敗する ユースケース地獄とシーケンス図地獄 振舞い図の選択ミス フローチャートの呪い トークン駆動とイベント駆動の意味論論 シーケンス図はパラパラマンガ モードがあるときはステートマシン図 アルゴリズムはアクティビティ図 66
よくある落落とし 穴 ( 成果物 ) 一枚の図には 一枚のミッション 全てを表す 一枚の図 なんてものはない 適切切な図 面を選ぶこと 観点をしっかり持つこと 失敗パターン レビュー不不 足 自 己満 足 正当性を追求してしまいすぎること 67
目的は 開発の成功 お話したかったこと SysML が分かること ではない 最 大の敵 手戻り を削減しよう 考え 方 トップダウンで考える 分割統治 段階的に考える 抽象的に考える 理理解できる 合意 へ 説明できる モデルを作成しよう 68
お話出来ていないこと MBSEのモデルの作り 方 合意したい関 心事は組織によって異異なる 組織への導 入のやり 方など 興味のある 方はどうぞお問い合わせください hisashi.suzuki@cogito-machina.com 69
Thank you! hisashi.suzuki@cogito- machina.com 70