User Tools
bok:eng:mbse:method
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
bok:eng:mbse:method [2020/09/09 06:10] anwlur [Vitech MBSE Methodology] added dev activities |
bok:eng:mbse:method [2020/09/18 10:38] (current) anwlur [JPL State Analysis (SA)] |
||
|---|---|---|---|
| Line 6: | Line 6: | ||
| <WRAP center round info 60%> | <WRAP center round info 60%> | ||
| - | Gaps to the 2008 survey include a 2010 revision to Harmony/SE and the inclusion of SYSMOD | + | Gaps that the below survey seeks to address to the 2008 survey include |
| + | * 2010 revision to Harmony/SE | ||
| + | * 2nd edition for Vitech MBSE Methodology (released 2011) | ||
| + | * 2012 release of JPL SA | ||
| + | * inclusion of SYSMOD | ||
| + | * inclusion of Functional Architecture for Systems | ||
| </WRAP> | </WRAP> | ||
| - | |||
| ===== Ontology ===== | ===== Ontology ===== | ||
| Line 226: | Line 230: | ||
| - Validation & Verification | - Validation & Verification | ||
| ==== JPL State Analysis (SA) ==== | ==== JPL State Analysis (SA) ==== | ||
| + | |||
| + | Sources for this methodology include | ||
| + | |||
| + | * D. Wagner, "An Ontology for State Analysis: Formalizing the Mapping to SysML", IEEE (2012). Accessed on September 10th, 2020 [[http://www.omgsysml.org/State_Analysis_Ontology%20_in_SysML.pdf|here]]. | ||
| + | * D. Wagner, "An Ontology for State Analysis: Formalizing the Mapping to SysML", Presentation to IEEE Aerospace Conference (March 2012). Accessed on September 10th, 2020 [[https://trs.jpl.nasa.gov/bitstream/handle/2014/42601/12-0881.pdf|here]]. | ||
| + | |||
| + | JPL State Analysis... | ||
| + | |||
| + | * provides a methodology to design complex control systems | ||
| + | * Typical architecture is as below | ||
| + | |||
| + | {{ :bok:eng:mbse:method:jpl_sa1.png?500 |}} | ||
| + | |||
| + | * Mission Planning & Execution supplies Control Goals to State Control | ||
| + | * Mission Planning & Execution supplies Knowledge Goals to State Estimation | ||
| + | * State Estimation supplies State Functions :?: to State Knowledge | ||
| + | * State Knowledge supplies State Values to State Control | ||
| + | * Models bridges State Estimation, Knowledge and Control | ||
| + | * State Control supplies Commands to Hardware Adapter | ||
| + | * Sense (sensors) and Act (actuators) are ports to Hardware Adapter. Hardware Adapter is child to System Under Control | ||
| + | * Actuator creates changes which influences Sensors | ||
| + | * Hardware Adapter supplies Measurements & Commands to State Estimation | ||
| + | |||
| + | === Rationale === | ||
| + | |||
| + | * As system complexity grows it is not possible to manage a system based on subsystem-level functional decomposition, the web of interactions are too great | ||
| + | * There is a gap between requirements on SW specified by system engineers and the implementation of these requirements by software engineers, leaving open the possibility of misinterpretation of system engineer's intent | ||
| + | |||
| + | === Objectives === | ||
| + | |||
| + | * Facilitates system engineers to precisely express design intent in a tool that actively ensures consistency | ||
| + | * Clear distinction between Control System and System Under Control | ||
| + | * Provide a methodology for | ||
| + | * Discovering and documenting states of a system | ||
| + | * Modeling behavior of state variables and relationships between them | ||
| + | * Capturing mission objectives in detailed scenarios motivated by operator intent | ||
| + | * Keep track of system constraints and operating rules | ||
| + | * Describing methods by which objectives will be achieved | ||
| + | |||
| + | === Development Activities === | ||
| + | |||
| + | - The foundation of the JPL SA methodology is the control system and the //system under control// are explicitly different. This separation is formalized in an //ontology// which is written in OWL2. JPL used [[https://protege.stanford.edu/|Protege]] as the editing environment. | ||
| + | - This ontology is mapped to SysML artifacts using Query/View/Transformation (QVT), a model-to-model transformation standard by OMG. | ||
| + | - A context diagram (block diagram) includes //Analysis Context// with parts //System Under Control// and //Control System// | ||
| + | - In a state effects diagram (=internal block diagram) map the relationship between different state variables contained within the context. Use //affects// and //affectedBy// relationships. | ||
| + | - Define mathematical relationships between State Variables with parametric diagrams | ||
| + | - Control System is designed. A State Variable has only 1 //Controller// and (may) have only one //Estimator// | ||
| + | - The //HardwareAdapter// is modeled to be an interface between the Control System and System Under Control. Measurements flow from System Under Control to Control System, Controls flow the other way. | ||
| + | - Goals are elaborated as (typically) stereotyped use cases whilst the temporal aspect of goals is defined as constraints and analyzed in parametric diagrams. | ||
| ==== Object-Process Methodology (OPM) ==== | ==== Object-Process Methodology (OPM) ==== | ||
| ==== SYSMOD ==== | ==== SYSMOD ==== | ||
| + | |||
| + | ==== Funcational Architecture Methodology ==== | ||
| + | |||
bok/eng/mbse/method.1599631857.txt.gz · Last modified: 2020/09/09 06:10 by anwlur
Page Tools
Except where otherwise noted, content on this wiki is licensed under the following license: CC Attribution-Share Alike 4.0 International
