ETWest2015SEC先端技術入門ゼミ（一般配布用).pptx

Size: px

Start display at page:

Download "ETWest2015SEC先端技術入門ゼミ（一般配布用).pptx"

しょうことみもと
7 years ago
Views:

1 ETWest2015:SEC 先端技術入門ゼミモデルベースシステムズエンジニアリング (MBSE) 入門 2015/6/10( 水 )11:40 ~ 12:25 株式会社コギトマキナ代表取締役システムズアーキテクト鈴鈴木尚志

2 アジェンダ背景 MBSEとは何か SEとはモデルとは SysMLとは目的は MBSE の概要を把握すること 2

4 MBSE が注目を集めている!? 通常 5 年年かかる新車車開発をわずか 29 ヶ月で完了了セーフティクリティカルな鉄道信号制御ソリューションのグローバルな安全性および信頼性の標準へのコンプライアンスを促進する統合開発環境を構築太陽光発電システムのための遠隔制御管理理システムにおいてサブシステムとソフトウェアの再利利用を要求分析からテストまで一貫して促進およそ 25% の障害が減少開発時間が 60% 減少し製品ごとにおよそ 10,000 ユーロの節約が達成防衛システムの開発ではアプリケーションの信頼性と安全が改善され製品化の時間を 40 % 短縮コンシューマエレクトロニクスの分散協調設計と言う観点からの MBSE への取り組み 4

制御ソリューションのグローバルな安全性および信頼性の標準へのコンプライアンスを促進する統合開発環境を構築太陽光発電システムのための遠隔制御

5 話題になっている背景 5

6 IoT SoS M2M CPS なんだか似たような匂いのする言葉葉達を最近良良く耳にするようになったクラウド iapp,google Play ドローン? 自動運転 6

7 最近の開発製品のカテゴリーも様々システムズ開発の成果物は有形のモノと無形のサービスのようなコトに大別できる最近はモノコトつくりという言葉葉も 7

8 SoS の例例 : 交通システムの拡張 PTPS( 公共車車両優先システム ) h"p://

9 その他 SoS の例例スマートグリッド総務省省 HP より航空システム国土労働省省 HP よりスマート医療療厚生労働省省 9 HPより自動車車財団法人日本自動車車研究所 HP より

10 システムズ開発の様々な課題システムの複雑化に伴う課題システムの派生やシリーズ化に伴う課題要求の不不適切切な分析 / 定義に伴う課題要求変更更への対応に伴う課題大きな手戻りの発生に関する課題関係者間のシステム開発に対する意識識の統一や均質化に関する課題

11 様々な複雑ささまざまなややこしさ大規模化モノそのものの機能の肥大化既存システムの新規システムの組み合わせによる新たなサービスの誕生カーナビ + スマホ + 情報センタ + 交通管制システム + 信号管理理システム =? 市場の動向新たな技術領領域の発生既存システム化 +α ディペンダビリティ / セーフティ / セキュリティ IEC61508 ISO26262 IEC62304 ISO13485 ISO14971, ISO13482 ISO/IEC15408 IEC62443, IEC62366 製造 / 運用 / 管理理の環境に対する負荷軽減迅速な開発ー短命な事業 11

市場の動向新たな技術領領域の発生既存システム化 +α ディペンダビリティ / セーフティ / セキュリティ IEC61508 ISO26262

12 System of Systems 様々なシステムが複雑に関連している状態で対象とするシステムを設計することは極めて難しいシステム A 対象システム System of interest システム B システム C システム D 12

13 成功させるために相克しなくてはならないこと複雑さ不不確実さ価値観の多様性成功へ 13

14 システム開発で解くべき課題は何? 生産性の向上製品安全性の確保開発能力の向上開発コストの削減新製品の開発市場の拡大新技術の開発設計品質の向上製造品質の向上開発期間の短縮 14

15 成功を阻害する手戻りあまりに多くの欠陥が開発初期に作りこまれている! 欠陥が発見見された時点では遅すぎる! 作りこまれた障害数発見障害数開発統合 SW/HW 統合テスト運用 15

16 MBSE がめざすものできるだけ上流流で問題を解決し手戻りを減らすできるだけ早く妥当性や正当性の確認をする作りこまれた障害数発見障害数開発統合 SW/HW 統合テスト運用 16

17 システムズ開発の成功と MBSE システムズ開発の成功とは予想可能なスケジュールと予算の範囲内でエンドユーザーのニーズを満たす品質の高いシステムズの開発が行行われることけれども成功するのは困難機能は増やし品質は向上しより短い時間でそしてより少ないリソースで関係者の多様化ドキュメントの爆発的増大すりあわせ工程への高負荷 MBSE が話題になっている理理由システムズ開発の困難 ( 複雑さ不不確実さ価値観の多様性 ) を克服し開発を成功に導くものだと考えられているから 17

品質は向上しより短い時間でそしてより少ないリソースで関係者の多様化ドキュメントの爆発的増大すりあわせ工程への高負荷

18 背景まとめ近年年の開発はなかなか成功しない成功のためには手戻りを減少させる必要がある MBSE はこれに効果があると考えられているる 18

19 MBSE とは 19

20 製品開発プロセスへの効果手戻りを防止する設計根拠を明確にする MBSE 導入の効果アーキテクチャトレードオフ多人数開発への効果情報の錯綜を減少させる複数製品開発への効果再利利用の単位を明確にする派生開発で手を入れる部分を明確にするさまざまな事例例 ehealth, Smart Grids, Intelligent Transportation Systems, Smart Homes and Cities などモデルベースシステムズエンジニアリング導入の手引き 20

ehealth, Smart Grids, Intelligent Transportation Systems, Smart Homes and

21 エレベータのサンプルモデルベースシステムズエンジニアリング導入の手引きより 21

22 MBSE におけるモデルの例例 ( 配布資料料省省略略 ) モデルベースシステムズエンジニアリング導入の手引きを例例に 22

23 SE の範囲 IPA ESPR より

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

25 SE の歴史と進化システム開発の成功エンジニアリングプロセス 1990 年年 NCOSE の設立立 1969 年年世界初のシステムズエンジニアリング標準 1940 年年代ベル研システムは要素の総和ではない! エンジニアリングマネジメントオペレーションズリサーチなど 25

26 システムズエンジニアと言う職能 ( ハードウェアとソフトウェアの区別なく ) システムを開発する人システムズエンジニア SE さん情報系システムを開発する人 26

27 SE とは何か?( 解釈 ) システムズエンジニアリングの定義手法の名前でもプロセスの名前でもなくエンジニアリング領領域のこと SE の目的はシステムズ開発の手戻りを減らすことシステムズエンジニアリング工程の多くは関係者の合意を取り付けるために妥当な正しさを検証することシステムズエンジニアリングは以下の 3 つの活動を繰り返しおこなうことになる 1. 要求をまとめる 2. アーキテクチャを構築する 3. 成果物を次工程に渡す MBSE はモデルを利利用した効率率率のよい SE にすぎない SE そのものの歴史はとても古い科学的な問題分析 27

28 なぜモデルを使うのか? 28

29 最近ちょっと鬱陶しいドキュメントの爆発的増大を何とかしたいすりあわせ工程への高負荷を何とかしたいトライ & エラーを減少させたい要求の妥当性や上位設計の正当性を確認したいモデルを使え! 多様化した関係者間のコミュニケーション問題を解決したい実機でしかわからない状況をなくしたいそのために上流流レベルで検証 ( フロントローディング型開発 ) を 29

30 モデル物事 ( モノコト ) をある側面 ( 関心事 ) から見見て単純化したもの M P is a model of モデル M によって P が説明できるという意味 M において論論理理的に P が真 M satisfies P 大事なことはあるモノゴトを説明するという目的のためにモデルは作られるということ! 説明したいことは何?

31 モデリング = モデル化現実に対してある仮定をおいて単純化してから抽象的なモノに落落とし込んで行行くこと腕の見見せ所は単純化の仕方同じ現実を見見ていても人により現実の捉え方が違うのでモデル化の仕方も異異なる!? 現実には無限の側面がある現実をどういった目的でどのような側面 ( 観点 ) から切切るか? 他人がモデル化したものを製品設計に活用するときなどはモデル化でどのような仮定 ( どのような観点何を省省略略しているか? など ) がおかれているかをきちんと把握しておく必要がある

32 SE になぜモデルをつかうのか目的理理解特に共通理理解理理解認識識定義 ( 仕様 ) と例例示をうまく使う外延 / 内包開発の成功のため手戻りをなくすため多くの関係者の合意をとるため大事な事は説明したい事があるということそのためにわかりやすい観点を設定する 32

33 MBSE は SE を改善したもの成功迅速誤解なし合意を確実にとりつける手戻りを減らす妥当性正当性理理解しやすく誤りのない資料料を作るトレードオフ Arch. Decision SysML でモデルを記述 33

34 MBSE の利利点 (INCOSE tutorial より ) システムの要求と設計に関する共通理理解の拡大要求の妥当性を確認する分析と設計の間に共通の土台を築くリスクを発見見しやすくする複雑なシステムの開発における管理理性の向上統合されたモデルに対し複数のビューによって問題領領域を分離離システムモデルの階層化によってトレーサビリティを高める要求 / 設計変更更による影響分析を容易易にする差分的開発と漸進的な追加改善をサポートする設計品質の改善エラーと曖昧さを減らす表現の正確性を高める初期段階 / 進行行中の妥当性確認と検証でリスク低減その他ライフサイクルを通じた価値 ( 例例 : トレーニング ) 現場知識識の取り込みを拡大 34

35 なぜモデルを使うのかまとめモデルは説明したいものをうまく理理解してもらうための方便便ともいえる近年年の開発は複雑さ不不確実さ価値観の多様性に邪魔されなかなか成功しない明瞭で迅速な合意のためにモデルを使う! そして合意はとれた? 35

36 モデリング言語 SysML とは 36

37 OMG の定義 : SysML この仕様はシステムズエンジニアリングのアプリケーションいわゆる Systems Modeling Language (SysML) のためのモデリング言語の一般的な目的を定義する SysML は複雑なシステムの広範囲に及ぶ仕様化分析設計正当性妥当性の検証をサポートするこれらのシステムはハードウェアソフトウェア情報プロセスパーソネル設備などを含みます * SysML はシステムズエンジニアリングにおける問題の広い範囲をモデリングするために単純かつ強力力な構成概念念を提供するためにデザインされたもの特に要求構造振舞いそしてアロケーションそしてシステムズエンジニアリングの分析をサポートするためのシステムプロパティへの制約を明確化する点において効果的 ** OMG Systems Modeling Language (OMG SysML) Specification, November 2008 *Part 1 Introduction ** Scope SysML の仕様の完全版は h"p://

38 SysML ダイアグラム種別まずは何の目的の図面か? を考えよう観点ダイアグラム名対応するUML ダイアグラム記述の目的構造パッケージ図モデルの整理理ブロック定義図クラス図静的構成要素とそれぞれの関係内部ブロック図複合構造図静的構成要素の内部構造パラメトリックパラメトリック図該当なし数式などを用いた制約振舞いユースケース図システムの提供する機能アクティビティ図入出力力処理理のフローシーケンス図メッセージ交換の時系列列ステートマシン図イベントと状態遷移要求要求図該当なし要求項目とそれぞれの関係! 一枚の図には1つのミッションがある 38

39 SysML SysML の仕様の具体的内容は参照のこと

40 SysML モデリングのキモ SysML はあくまで言語であり使ったからといって成功が保証されるものではない SysML モデリングで留留意すること分割統治 4 つの観点要求構造振舞いパラメトリック制約統合枚挙トレーサビリティ 40

41 科学的な問題分析のための規則分割統治明証性わたしが明証的に真であると認めるのでなければどんなことも真として受け入れないこと分析わたしが検討する難問の一つ一つをできるだけ多くのしかも問題をよりよく解くために必要なだけの小部分に分割すること総合分割統治わたしの思考を順序にしたがって導くこと単純なものから複雑なものへ部分が終わったら全体へ枚挙すべての場合に完全な枚挙と全体にわたる見見直しをしてなにも見見落落とさなかったと確信すること抜け漏漏れがないようにデカルト方法序説 1637( 谷川多佳子訳岩波文庫 1997 年年 ) 41

42 MBSE の全体像 42

45 超上流流ーユーザー要求から設計要求まで MBSEの活動を一言で言えば 1. 要求をまとめる 2. アーキテクチャを構築する 3. 成果物を次工程に渡すそして合意はとれた?! 一枚の図には 1 つのミッションがある

46 システムズエンジニアリングシステムとは定義された目的を成し遂げるための相互に作用する要素 (element) を組み合わせたものであるこれにはハードウェアソフトウェアファームウェア人情報技術設備サービスおよび他の支援要素を含む INCOSE システムズエンジニアリングハンドブックの定義ソフトウェアエンジニアリングだけのためのものではない

47 システムズエンジニアリングの骨目的は開発の成功目標は構想設計ゴールは合意分割統治しながらスケジュール予算品質を満たすような開発の全体最適を行行なうこと Function Driven 反復復的プロセス - 慌てないツールは使うべしトレードオフスタディ 47

48 全体最適全体を考えること部分を考える前に考えること部分を考えた後にも考えることこうなってませんか? 部分最適の総和が全体最適である優秀なエンジニアがそれぞれ頑張れば

49 分割統治とフィードバックループシステムエンジニアリングの最大の特徴複雑なシステム開発では上位レベルの問題点が下位レベルの細部検討時に明確になるという事実サブシステムの設計時に気付いた問題点に基づき前工程の成果であるシステム設計を見見直すことが可能なフィードバックループが必要フィードバックループこそより品質の高いシステムを作り上げるための SE の中核プロセス戻ってよしただし手遅れになる前に

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

51 二元 V 字モデルとエンティティ V 入れ子になったシステム具体抽象のフィードバックも意識識

52 4 側面からシステムを捉える 52

53 なぜワザワザ要求図を作るのか? トレーサビリティを作りこむため管理理するためではない作業効率率率例例えば USDM の Excel 表を作成する際には Excel の上でやらなければならないということ Excel で試行行錯誤しながら体裁を整えつつ作業をするのは非効率率率的 53

54 要求と設計の関連付け 54

55 安全性の目標をモデル駆動開発で検証する要求図を用いた安全関係の要求のトレーサビリティコンセプト

56 設計要素と設計要素の関連付け振る舞いの設計要素と構造の設計要素の関連づけ 56

58 トレードオフスタディのためのモデル 58

59 把握と合意一発で的には当たらない利利害関係者は多岐にわたる顧客エンジニアエレキメカ SW 制御知識識関心事は関係者ごとに異異なるインフォグラフィックスを有効利利用技術用語 / 技術詳細は要注意記録をとること証跡をとることまずは全体像を把握する言った言わないの議論論をしないモデルを作ってこの前提で合意

60 的をよく狙えば一発必中できる? 的をよく狙えば一発必中できる? 議論論を尽くせば要求は固まる? 動いている的を狙うことも多いどれが的なのか? もわからないユーザーは気まぐれシステムは成長し続ける設計して初めて分かる問題点も多いモデルを使って理理解しやすくしたい

61 同じ要求を聞いても関心事は異異なる信号が赤になったら止まること赤色の波長の上限値下限値は? 止まる時はエンジンも止める? 赤認識識後何秒以内に止まる? 遠くの交差点が赤でも止まる? どの位置で止まる? 赤でなくなったら走る? 赤の時だけ止まる?

62 企業における MBSE の目的例例システム製品開発の成功開発業務効率率率の向上開発手戻りの減少円滑滑なコミュニケーション様々なトレードオフ分析企画から保守までの確実なトレーサビリティの確保機能安全基準対応系列列製品開発の成功車車輪輪の再発明をしない最後は合意! 一枚の図には1つのミッションがある 62

63 MBSE をざっくりとまとめシステムズエンジニアリングの目的は分割統治しながらスケジュール予算品質を満たすような開発の全体最適を行行なうこと MBSE は古くからのシステムズエンジニアリングをモデルを使うことで便便利利にしたもの MBSE による共同作業の改善と文書の明確化正確化が開発効率率率の向上開発期間の短縮そして製品品質の向上をもたらす SysML はシステムを様々な観点でモデル化するために適した言語モデル化の目的と対象を明確にしなくては MBSE の効果は出ない一枚の図には 1 つのミッショ 63! ンがある

64 最後に 64

65 モデリング成功のために! 大き過ぎたら分割統治! 一枚の図には 1 つのミッションがある! 説明したいことは何?! そして合意はとれた? 65

66 よくある落落とし穴 (SysML) SysML=MBSEではない目的を考えてから道具を探せ! 道具のお勉強が目的になると必ず! 失敗するユースケース地獄とシーケンス図地獄振舞い図の選択ミスフローチャートの呪いトークン駆動とイベント駆動の意味論論シーケンス図はパラパラマンガモードがあるときはステートマシン図アルゴリズムはアクティビティ図 66

67 よくある落落とし穴 ( 成果物 ) 一枚の図には一枚のミッション全てを表す一枚の図なんてものはない適切切な図面を選ぶこと観点をしっかり持つこと失敗パターンレビュー不不足自己満足正当性を追求してしまいすぎること 67

68 目的は開発の成功お話したかったこと SysML が分かることではない最大の敵手戻りを削減しよう考え方トップダウンで考える分割統治段階的に考える抽象的に考える理理解できる合意へ説明できるモデルを作成しよう 68

69 お話出来ていないこと MBSEのモデルの作り方合意したい関心事は組織によって異異なる組織への導入のやり方など興味のある方はどうぞお問い合わせください 69

70 Thank you! machina.com 70

15288解説_D.pptx

15288解説_D.pptx ISO/IEC 15288:2015 テクニカルプロセス解説 2015/8/26 システムビューロシステムライフサイクル 2 テクニカルプロセス a) Business or mission analysis process b) Stakeholder needs and requirements definieon process c) System requirements definieon