This shows you the differences between two versions of the page.
Both sides previous revision Previous revision Next revision | Previous revision Next revision Both sides next revision | ||
bok:eng:mbse:method [2020/09/10 04:43] anwlur [Survey of MBSE Methodologies] added FAS |
bok:eng:mbse:method [2020/09/11 07:55] anwlur [JPL State Analysis (SA)] |
||
---|---|---|---|
Line 9: | Line 9: | ||
* 2010 revision to Harmony/SE | * 2010 revision to Harmony/SE | ||
* 2nd edition for Vitech MBSE Methodology (released 2011) | * 2nd edition for Vitech MBSE Methodology (released 2011) | ||
+ | * 2012 release of JPL SA | ||
* inclusion of SYSMOD | * inclusion of SYSMOD | ||
* inclusion of Functional Architecture for Systems | * inclusion of Functional Architecture for Systems | ||
Line 229: | 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 | ||
+ | |||
+ | |||
+ | |||
+ | * Unordered List Item | ||
+ | * Make system intent explicit in the design and implementation | ||
+ | * Controllers use state estimates as inputs - not direct measurements | ||
+ | * Single controller per state variable | ||
+ | * Single estimator per state variable | ||
+ | |||
+ | === Example === | ||
+ | |||
+ | |||
+ | |||
+ | === Development Activities === | ||
+ | |||
==== Object-Process Methodology (OPM) ==== | ==== Object-Process Methodology (OPM) ==== |