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/08 13:51] anwlur [IBM Rational Unified Process for Systems Engineering (RUP SE)] added content |
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 140: | Line 144: | ||
Eventually found the below source material: | Eventually found the below source material: | ||
- | * Cantor M, "RUP SE: The Rational Unified Process for Systems Engineering" IBM Rational Software (2001). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov01/RUPSENov01.pdf|here]] | + | * Cantor M, "RUP SE: The Rational Unified Process for Systems Engineering" IBM Rational Software (2001). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/nov01/RUPSENov01.pdf|here]]. Overviews RUP SE Version 1.0 |
* Cantor M, "Rational Unified Process for Systems Engineering, Part 1: Introduction RUP SE Version 2.0" IBM Rational Software (2003). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug03/f_rupse_mc.pdf|here]] | * Cantor M, "Rational Unified Process for Systems Engineering, Part 1: Introduction RUP SE Version 2.0" IBM Rational Software (2003). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/aug03/f_rupse_mc.pdf|here]] | ||
* Cantor M, "Rational Unified Process for Systems Engineering, PART II: Distinctive Features" IBM Rational Software (2001). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/dec01/RUPSEDec01.pdf|here]] | * Cantor M, "Rational Unified Process for Systems Engineering, PART II: Distinctive Features" IBM Rational Software (2001). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/dec01/RUPSEDec01.pdf|here]] | ||
Line 146: | Line 150: | ||
* Cantor M, "Rational Unified Process for Systems Engineering, Part III: Requirements analysis and design" IBM Rational Software (2003). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct03/m_rupse_mc.pdf|here]] | * Cantor M, "Rational Unified Process for Systems Engineering, Part III: Requirements analysis and design" IBM Rational Software (2003). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/oct03/m_rupse_mc.pdf|here]] | ||
- | Based on the above SUP SE is baselined as Version 2.0 | + | Based on the above SUP SE is baselined as Version 2.0, last updated in 2003. |
=== Objectives === | === Objectives === | ||
Line 155: | Line 159: | ||
* Whitebox representation is described in System Architecture | * Whitebox representation is described in System Architecture | ||
- | {{ :bok:eng:mbse:method:rup_phases.png?400 |}} | + | {{ :bok:eng:mbse:method:rup_phases.png?600 |}} |
* Apply the RUP framework to systems development | * Apply the RUP framework to systems development | ||
* Lifecycle - focus on removing risks by adopting phases (Inception, Elaboration, Construction, Transition) | * Lifecycle - focus on removing risks by adopting phases (Inception, Elaboration, Construction, Transition) | ||
* Iterations - Iterative development process | * Iterations - Iterative development process | ||
- | * Disciplines - RUP takes into account the following disciplies | + | * Disciplines - RUP takes into account the following disciplines |
* Business Modeling | * Business Modeling | ||
* Requirements | * Requirements | ||
Line 169: | Line 174: | ||
* Project Management | * Project Management | ||
* Environment | * Environment | ||
+ | |||
+ | {{ :bok:eng:mbse:method:rup_se.png?600 |}} | ||
+ | |||
* Extend the RUP 4+1 architectural model into the RUP SE model framework | * Extend the RUP 4+1 architectural model into the RUP SE model framework | ||
* RUP SE provides for the following viewpoints (can be extended to others) | * RUP SE provides for the following viewpoints (can be extended to others) | ||
Line 175: | Line 183: | ||
* Physical - concerned with physical decomposition | * Physical - concerned with physical decomposition | ||
* Information - concerned with how information is stored and processed | * Information - concerned with how information is stored and processed | ||
- | * Process - concerned with threads of control | + | * Process - concerned with threads of control |
+ | * RUP SE sets out four model levels | ||
+ | * Context - system and its actors | ||
+ | * Analysis - system partitioning in each viewpoint to establish conceptual approach | ||
+ | * Design - realization of the analysis level | ||
+ | * Implementation - realization of design level | ||
* Employ UML as modeling language | * Employ UML as modeling language | ||
- | * Provide tool assets | + | * Provide tool assets - essentially maintaining a plug in to IBM's Rational Software |
- | * Maintain all model levels as a program asset | + | * Maintain all model levels as a program asset - essentially maintaining traceability of low fidelity and high fidelity systems |
+ | |||
+ | === Development Activities === | ||
+ | |||
+ | - Start with Use Cases, i.e. how the system delivers value to / responds to Actors | ||
+ | - Treat system as a blackbox which has measures of effectiveness / budgets to meet Actor's need | ||
+ | - Develop whitebox representation of the system of how it will meet the operations defined by the blackbox representation | ||
+ | - RUP SE has Locality and Process as attributes of the whitebox representation. Locality is where the operation is hosted, Process is what executes the operation. | ||
+ | - Specify subsystem use cases. | ||
+ | - Visualize interaction of Actor with Process with a sequence diagram. Helps to identify whether processes can be combined if significant interaction between them. | ||
+ | - Visualize interaction of Actor with Localities with a sequence diagram. Shows dataflows between assets, helping to define communication protocols. | ||
+ | - Rinse and repeat. | ||
==== Vitech MBSE Methodology ==== | ==== Vitech MBSE Methodology ==== | ||
+ | The source for the Vitech MBSE Methodology is D. Long & Z, Scott "A Primer for Model-Based System Engineering", Vitech Corporation, 2nd edition (2011). This is available for download [[http://www.vitechcorp.com/resources/mbse.shtml|here]]. | ||
+ | |||
+ | === Objectives === | ||
+ | |||
+ | The design space includes three systems (a simplification of J. Martin's seven [[bok:eng:sys:intro#process|systems]]) | ||
+ | * Designing System | ||
+ | * System Under Design - solves a problem | ||
+ | * Context System - users of the system, environment, other interacting systems | ||
+ | |||
+ | === Development Activities === | ||
+ | |||
+ | Vitech Methodology describes main activities (Requirement Analysis, Functional Behavior Analysis, Architectural Synthesis) addressing, respectively, the domains of Requirements, Behavior, Architecture, Verification and Validation. | ||
+ | |||
+ | - Requirements Analysis | ||
+ | - Explore stakeholder needs creating a statement of system functionality | ||
+ | - Increase granularity of system behavior (that realizes need) and therefore increase specificity of requirements | ||
+ | - Functional Behavior Analysis | ||
+ | - Addresses (a) what the system must do in order to answer customer's need and (b) how well the system must perform these functions (i.e. measure of effectiveness) | ||
+ | - Construct logical model | ||
+ | - Architectural Synthesis | ||
+ | - Development of the physical model | ||
+ | - Allocating logical model to the physical model | ||
+ | - Trace requirements (through the logical mode) to the physical model | ||
+ | - 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 ==== | ||
+ | |||