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 Next revision Both sides next revision | ||
|
bok:eng:mbse:method [2020/09/10 08:19] anwlur [Survey of MBSE Methodologies] added gap to 2012 release of JPL SA |
bok:eng:mbse:method [2020/09/14 23:14] anwlur [JPL State Analysis (SA)] add physical system modeling ontology |
||
|---|---|---|---|
| Line 235: | Line 235: | ||
| * 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", 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]]. | * 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 |}} | {{ :bok:eng:mbse:method:jpl_sa1.png?500 |}} | ||
| Line 240: | Line 245: | ||
| * Mission Planning & Execution supplies Control Goals to State Control | * Mission Planning & Execution supplies Control Goals to State Control | ||
| * Mission Planning & Execution supplies Knowledge Goals to State Estimation | * Mission Planning & Execution supplies Knowledge Goals to State Estimation | ||
| - | * State Estimation supplies State Functions (?) to State Knowledge | + | * State Estimation supplies State Functions :?: to State Knowledge |
| * State Knowledge supplies State Values to State Control | * State Knowledge supplies State Values to State Control | ||
| * Models bridges State Estimation, Knowledge and Control | * Models bridges State Estimation, Knowledge and Control | ||
| Line 247: | Line 252: | ||
| * Actuator creates changes which influences Sensors | * Actuator creates changes which influences Sensors | ||
| * Hardware Adapter supplies Measurements & Commands to State Estimation | * Hardware Adapter supplies Measurements & Commands to State Estimation | ||
| - | |||
| - | JPL SA ... | ||
| - | |||
| - | * provides a methodology to design complex control systems | ||
| - | * extends basic concepts from control theory and software architecture | ||
| === Rationale === | === Rationale === | ||
| - | * As system complexity grown it is not possible to manage a system based on subsystem-level functional decomposition, the web of interactions are too great | + | * 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 | * 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 | ||
| Line 262: | Line 262: | ||
| * Facilitates system engineers to precisely express design intent in a tool that actively ensures consistency | * Facilitates system engineers to precisely express design intent in a tool that actively ensures consistency | ||
| * Clear distinction between Control System and System Under Control | * Clear distinction between Control System and System Under Control | ||
| - | * Model of System Under Control must be explicitly identified and used in a way that assures consensus | + | * 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 | ||
| + | === Ontology - Physical System Modeling Concepts === | ||
| + | {{ :bok:eng:mbse:method:jpl_sa_2.png?400 |}} | ||
| - | * Unordered List Item | + | {{ :bok:eng:mbse:method:jpl_sa_3.png?400 |}} |
| - | * 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 === | + | |
| + | * The //Affected// and //Affector// are both specializations :?: of //Thing//. | ||
| + | * //StateVariable// and //StateVariableGroup// are both properties :?: of //Affected// and //Affector//. //StateVariableGroup// is a modeling concept to make organization of the model easier. | ||
| + | * Only //Affected// has //Measurement// properties and is affected by 0 or more //Affector//. | ||
| + | * Only //Affector// has //Command// and affects 0 or more //Affected//. | ||
| + | * Unordered List Item | ||
| ==== Object-Process Methodology (OPM) ==== | ==== Object-Process Methodology (OPM) ==== | ||
bok/eng/mbse/method.txt · Last modified: 2020/09/18 10:38 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
