Differences

This shows you the differences between two versions of the page.

--- bok:eng:mbse:method [2020/09/08 06:09]
116.236.117.198 [Object-Orientated Systems Engineering Method (OOSEM)]
+++ bok:eng:mbse:method [2020/09/18 10:38] (current)
anwlur [JPL State Analysis (SA)]
@@ Line 6: / Line 6: @@
 <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>
 ===== Ontology =====
@@ Line 136: / Line 140: @@
 ==== IBM Rational Unified Process for Systems Engineering (RUP SE) ====
+It was not easy to find a document that lays out what RUP SE is about. I found [[https://www.ibm.com/developerworks/rational/library/content/03July/1000/1251/1251_bestpractices_TP026B.pdf|"Rational Unified Process"]] Rational Software White Paper TP026B, Rev 11/01 but it is a generalization of RUP //SE//.
+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]]. 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 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: System architecture" IBM Rational Software (2003). Accessed on September 8th, 2020 [[https://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep03/m_systemarch_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, last updated in 2003.
+=== Objectives ===
+  * Follow industry standard definition of systems
+    * Adopt blackbox and whitebox representation
+    * Blackbox representation is described in System Specification
+    * Whitebox representation is described in System Architecture
+{{ :bok:eng:mbse:method:rup_phases.png?600 |}}
+  * Apply the RUP framework to systems development
+    * Lifecycle - focus on removing risks by adopting phases (Inception, Elaboration, Construction, Transition)
+    * Iterations - Iterative development process
+    * Disciplines - RUP takes into account the following disciplines
+      * Business Modeling
+      * Requirements
+      * Analysis & Design
+      * Implementation
+      * Test
+      * Deployment
+      * Configuration & Change Management
+      * Project Management
+      * Environment
+{{ :bok:eng:mbse:method:rup_se.png?600 |}}
+  * 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)
+      * Role (RUP SE calls this 'Worker') - concerned with roles and responsibilities
+      * Logical - concerned with logical decomposition
+      * Physical - concerned with physical decomposition
+      * Information - concerned with how information is stored and processed
+      * 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
+  * Provide tool assets - essentially maintaining a plug in to IBM's Rational Software
+  * 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 ====
+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) ====
+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) ====
 ==== SYSMOD ====
+==== Funcational Architecture Methodology ====

Model of Knowledge by Fitzgerald Systems

User Tools

Site Tools

Differences

Page Tools