Systems Modeling Language (SysML)

Systems Modeling Language (SysML)

・モデルは様々な形をとる　例えば物理モデル、抽象モデルなど
・複数のモデリング言語が存在する。それらはしばしばコンフリクトすることもある
・sysmlは、モデリング言語の中でも主要なもの
・sysmlは、UMLを拡張したモノ

この講座の著者は、sysmlのことを、モデリングでも言語でもないと言っている。
sysmlは、図表現の方法（記法）に過ぎないと言っている。

What's my requirements picture?
What's my behavior picture?
What's my interaction picture?
What's my physical picture?
What's my parts list? ..etc

・XML Metadata Interchange、XMIのいずれかを使用してモデルとデータの交換をサポートします。

SYSMLの図の説明
・アクティビィティ図→制御された一連のアクションを通じて、入力から出力への変換を指定します
・シーケンス図→メッセージベースの動作の表現を提供します。たとえば、部品間の相互作用や制御の流れなどです
・ステートマシン図→ブロックおよびイベントベースの動作のライフサイクルを表すために使用されます。ライトをオンまたはオフにするのと同じです
・ユースケース図→アクターによるシステムの使用法や目的の観点から基本的な機能を説明するための手段を提供します
・ブロック定義図→ブロック間の関係を記述しています
・内部ブロック図→プロパティとコネクタの観点からブロックの内部構造を説明します
・パラメトリック図→内部ブロックダイアグラムのサブタイプです。また、値の特性を関連付ける制約や方程式を表すために使用されます
・パッケージ図→モデルの編成に使用されます。通常、システム階層、ダイアグラムの種類、またはビューポイントによって異なります
・要求図→テキストベースの要件を表しています。また、検証方法や要件のカテゴリなどのユーザー定義プロパティを追加できます

sysmlを徐々に製品開発に組み入れることが大切

Model-Based Systems Engineering Methodologies

Model-Based Systems Engineering Methodologies

model based systems engineering
・概念設計から製品開発終了までをサポートする
・従来のシステム工学は、システムに関する文書の作成と管理に焦点を当てていたのに対し、「モデル」が主要なアーティファクトであるという点が異なる

MBSEの利点(潜在的なものも含む）
・システム(モデル）の再利用がしやすくなる
・コミュニケーションの向上
・開発タイムの短縮

モデルという用語には様々な定義がある

国防総省の観点
・引用、システム、実体、現像、またはプロセスの物理的な数学的または論理的表現

model from Friedenthal, Moore and Steiner define
・物理世界で実現可能な1つ以上の概念の表現

Bellinger definition
・実システムを理解しやすいように、ある特定の時間や空間でのシステムを単純現したもの

definition of a model comes from Dori
・抽象概念である。システムを、理解できるように、説明しやすいように、コミュニケーションしやすいように、といった面での。

Object Management Group pulls in relationships via mapping
・it's a selective representation of some system whose form and content are chosen based on a specific set of concerns. The model is related to the system by an explicit or implicit mapping.

MBSEを用いる目的（意図）
・現存しているシステムを表現することができる
・文書化が不十分な現存するシステムを、モデルとしてきちんと反映させることができる
・システム開発の早い段階で、MBSEを用いることで、別のミッションとシステムコンセプトを定式化、評価することができる

モデルには、バージョン管理と、変更管理プロセスがある

Model-Based Definition (MBD)

Model-Based Definition (MBD)

・MBSEは、成熟の初期段階にある
・モデル構築の重要な面は、妥当性確認と、検証である

INCOSE System Engineering Handbookにある、非公式の定義
・Verification ensures you built the system right.
・Validation ensures you built the right system.

Verification
システムの各要素が、仕様を満たしているか確認すること

validation
・ステム全体が利害関係者のニーズを満たすかどうか確認すること
・システム階層の最上位レベルでのみ行われる

ASMEの定義

verification
計算も出るが基礎となる数学モデルとその買いを正確に表していることを確認するプロセスのこと

validation
モデルが実際の世界をどの程度正確に表現しているのかを判断するプロセスのこと

つまり、velificationは数学に関することで、validationは物理学に関すること

verificationとvalidationの意味合いの違いは、エンジニアがどういったバックグラウンドを持っているかによって少しずつ異なる

これまでのシステムエンジニアリングでは、concurrent practice がうまく理解されてこなかった。
優れたシステムエンジニアリングでは、要件定義、論理的解決策、ふるまいの確認、物理的解決策、品質検証、検証などのどれか一つを深ほりし、次の一つを深堀する、というやりかたではなく
高次（おそらく抽象度の高いという意味、つまり上流？）のanswerを設計するところで、横方向の探索をしている
そして、そのアーキテクチャが抽象的ではあるが問題を解決すると分かった時に、より詳細な検討をしていく。
つまり、v&vは常に行われる。

このような concurrent intent はウォーターフォールの考え方とは対照的である。
この考え方を組織に根付かせるのは、時間がかかる

(following passages are from coursera)

model based design's definition

The Digital Manufacturing and Design Innovation Institute defines a model based definition as:

“a complete 3D Digital Product Definition created at the beginning of the product lifecycle to be used throughout the enterprise, reducing costs, improving system performance, and enabling future systems.

the difference between validation and verification

Verification is the determination that each element of the system meets the requirements of a documented specification. Validation is the determination that the entire system meets the needs of the stakeholders. Validation only occurs at the top level of the system hierarchy.

Business Impacts of Systems Engineering

Business Impacts of Systems Engineering

・狭いドメインで、かつ単純な問題に対しては、システムエンジニアリングはそこまで必要とされない。

・今日の私たちが取り扱っている問題は、クロスドメイン問題であり、複雑である。

・エンジニアリングのなるべく早い段階で、バグを見つけ修正したほうが、修正にかかるコストは小さくなる。

・PJに対するシステムエンジニアリングの理想は、総プログラムコストの訳14%である。

・あるプロジェクトが何もないプロジェクトにシステムエンジニアリングの取り組みを追加すると、7：1のROIが得られます。 中央レベルのシステムエンジニアリング努力を伴うプロジェクトでは、システムエンジニアリングへの追加投資に3.5：1のROIがあります。

推薦図書
The INCOSE Systems Engineering Handbook, fourth Edition; the ISO/IEC IEEE 15288 Standard;
the Systems Engineering Body of Knowledge or SEBoK located at sebok.wiki.org.
the 2015 video from the Chesapeake Incose meeting that includes a presentation by Garry Roedler provides an excellent perspective on the recent evolution of systems engineering.

Systems Engineering Process Overview

Systems Engineering Process Overview

agreement process
組織、プロジェクト、機能のそれぞれの担当範囲についての双方が理解(合意）することが、このプロセスで期待されること

organizational processes enabling processes
・プロジェクトを成功に導くための、人的、財的資源に焦点を当てている

technical management processes
・割り当てられた資産を、同意した事柄を達成するために管理することに焦点があてられる。

technical processes
・製品ライフサイクルのあらゆる時点におけるタスクに焦点を当てている。
・利害関係者の要求を製品やサービスに転化させることに重点を置いている。
・このプロセスのゴールは、利害関係者の要求を満たすシステムを作り、使うこと。

Systems Engineering and the LifeCycle

Systems Engineering and the LifeCycle

iteration(反復)
新しく利用可能な情報を使って、デザインを改善するために複数のプロセスを繰り返すこと

recursion(再帰)
反復のプロセスを、より細かいレベルで適用するもの
システムエンジニアリングにおける、再帰的プロセスの例は、システムを要素に分解すること

waterfall
・全てのプロセスを下向きに流れる
・スケジュール化が容易
・システムへの要求がきちんと定義されており、プロジェクト実行の間はその要求が変化しないことが大切

class of methods（incremental and iterative methods)
・要求が明確でないプロジェクトで有効
・プロジェクトの詳細は追加される（許容可能な場合）
・漸増的かつ、反復的な方法は小規模で単純なシステムに要素に対して有効
・利害関係者からのフィードバックがアプローチに組み込まれ、よりアジリティのある開発手法である

V
・設計と検証を頻繁に行う
・

Introduction to Systems Engineering

Introduction to Systems Engineering

The international counsil on systems engineering (incose) systems engineering handbook

The systems engineering body of knowledge(sebok)

Iso/iec/ieee 15288:2015

Natinal aeronautics and space administration(Nasa) systems engineering handbook

System

An integrated set of elements, sub-systems, or assemblies that accomplish a defined objective” -appendix c, incose system engineering handbokk- 4th edtion

System boundary

Defines the scope of a system, creating a distinction between the system and the environment, or context, in which a system exists

System architecture

The fundamental concepts or properties of a system in its environment embodied in its elements, relationships, and in the principles of its design and evolution;

Atomic

Unable to be broken down a system

Decomposable

Able to be broken into smaller elements

どこまでシステムを分解するべきか、という問には２つの答えがある。

１つは、そのブロックをブラックボックスとして利用できる状態である。そのシステムの要素を可視的に理解する必要がない時。

もしくは、もうそのシステムを理解する必要がない場合である。それはつまり、自信を持ってシステムを作り、利用できる場合は、システムをこれ以上分解する必要がないと言える。

A system hierarchy

The system life cycle processes are described in relation to a system that is composed of a set of interacting system element, each of which can be implemented to fulfill its respective specified requirement. 15288 standard, section 5.2.2