Model-Based Systems Engineering Methodologies J. Bermejo Autonomous Systems Laboratory (ASLab)
Contents Introduction Methodologies IBM Rational Telelogic Harmony SE (Harmony SE) IBM Rational Unified Process for Systems Engineering (RUP SE) JPL State Analysis (JPL SA) Vitech Dori Object-Process Methodology (OPM) Fernández ISE & Process Pipelines in OO Architectures (ISE&PPOOA) Weilkiens System Modelling Process (SYSMOD) INCOSE Object- Oriented Systems Engineering Method (OOSEM)
Introduction
Introduction A few names! Process: a logical sequence of tasks performed to achieve a particular objective. Method: the techniques to perform a task. Tool: an instrument that, applied to a method, can enhance the efficiency of the task.
Introduction A few names!
Introduction What is a Methodology? A collection of related processes, methods and tools applied to a class of problems that all have something in common.
Introduction What is Systems Engineering? An interdisciplinary approach and means to enable the realization of successful systems. It focuses on defining customer needs and required functionality early in the development cycle, documenting requirements, then proceeding with design synthesis and system validation while considering the complete problem: Operations Cost & Schedule Performance Training & Support Test Disposal Manufacturing Systems Engineering integrates all the disciplines and specialty groups into a team effort forming a structured development process that proceeds from concept to production to operation. Systems Engineering considers both the business and the technical needs of all customers with the goal of providing a quality product that meets the user needs. (INCOSE dixit)
Introduction What is Model-based System Engineering? Model-based systems engineering (MBSE) is the formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases (INCOSE dixit)
Introduction What is then a Model-based System Engineering Methodology? A collection of related processes, methods and tools applied to model-based systems engineering (MBSE), i.e., the formalized application of modeling to define customer needs and required functionality as to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later life cycle phases (ASLab dixit)
EXISTING MBSE METHODOLOGIES
Harmony-SE IBM Telelogic Harmony-SE: Description Subset of Harmony (an integrated systems and software development process). Development process: requirements, functional analysis, design. Uses a service request driven approach. Based on OMG SysML: System structure: BDD diagrams. Service requests: Sequence diagrams. Tool and vendor neutral
Harmony-SE Harmony-SE: Development Process
Harmony-SE Harmony-SE: Development Process
Harmony-SE Harmony-SE: Service Request Approach
Harmony-SE Harmony-SE: Approach Concept Considered Rationale Model-based Service-request modeling SysML diagrams Lifecycle Yes Requirements analysis System functional analysis Architectural design Ontology Not exactly Model repository Requirements repository Test data repository Views No Socio-technical No Functional Yes Functional decomposition Activity operational contracts Architecturecentric yes Allocation of functions to structure
RUP-SE IBM RUP-SE: Description Derivative of RUP (methodology for software development projects) to address systems engineering projects. Development process: a combination of phases and disciplines as in RUP. Uses model levels (context, analysis, design and implementation) and viewpoints (worker, logical, information, distribution, process and geometric). Based on OMG UML and SysML RUP SE plugin for Rational Method Composer (RMC) by IBM.
RUP-SE RUP SE: Development Process
RUP-SE RUP SE: Lifecycle
RUP-SE RUP SE: Approach Concept Considered Rationale Model-based Yes UML and SysML Lifecycle Yes RUP: Inception, elaboration, construction, transition Ontology Views and viewpoints No Yes Socio-technical Not really Actors Model levels: context, analysis, design, implementation Viewpoints: Worker, logical, information, distribution, process, geometric Functional Not quite Functional requirements Architecturecentric Yes Strong focus on this concept
JPL-SA JPL State Analysis: Description Based on MDS Control Systems Architecture. Leverages model- and state-based control architecture. Uses an iterative process: to identify the states of a system and their relationships to other states, the knowledge about these states, the control objectives, the response mechanisms to achieve the objectives. It can be combined with functional analysis. It can use UML. MDS Frameworks (not clear if JPL SA can use them).
JPL-SA JPL SA: Description 1..* Goal 1..* executes executes 1..* constrains 0..1 0..1 1..* 1 1..* 0..1 0..1 0..* 0..* State Estimator determines controls consults Controller delegates Variable consults 0..* 0..1 1 0..* 0..* 1 supplies 0..* 0..* 1 0..* distills produces 0..* issues State Value 0..* produces 1..* 1..* State Function 0..* 0..* 0..1 0..* Measureme nt 0..* evidence 1..* produces 1 Value History {xor} Hardware Adapter 0..1 accepts 1 0..* 0..* Command evidence 0..* 0..* 21
JPL-SA JPL SA: Approach Concept Considered Rationale Model-based State and control Focus on states A control-based perspective Lifecycle Ontology Not quite Models of states Patterns Views and viewpoints No Just the opposite Socio-technical No Just the opposite Functional No Just the opposite Architecture-centric Yes Physical states of control system
Vitech Vitech: Description MBSE methodology that considers 4 concurrent SE activities maintained through a common System Design Repository. Each SE activity is linked to an associated domain. Engineer the system horizontally before vertically. Development process: Onion Model (peeling off layers to increase detail). Based on System Definition Language (SDL). Not specific tool, but CORE product suite.
Vitech Vitech: Domains and Development Process
Vitech Vitech: Approach Concept Considered Rationale Model-based Yes SDL (System Definition Language)? Lifecycle Incremental Process Onion model Ontology Yes SE schema or ontology + System Definition Language (SDL) Views and viewpoints Socio-technical Not exacly Not quite Domains Functional Yes Behaviour domain (Functional allocation) Architecturecentric Yes Architecture Domain (Physical Architecture Definition)
OPM Object-Process Methodology (OPM): Description Object-Process Diagram (OPD): diagrams with things and links. Things: Object: a thing that exist or will exist. Process: a pattern of transformation an object undergoes. State: a situation an object can be at. Link: Procedural: consumption, result, effect, input, output. State-related: condition, agent-condition. Structure: aggregation, generalization, exhibition, instantiation. Tool: OPCat (can export OPD in UML)
OPM OPM: Description Object-Process Language (OPL): A subset of English that expresses textually the OPM specification that the OPD set represents graphically. Uses reserved words attached to each one of the graphical notation in the OPD. Uses non-reserved words that refers to user-defined names for Objects, Processes and so.
OPM OPM: Description
OPM OPM: Development Process (detail)
OPM Concept Considered Rationale OPM: Approach Model-based Yes OPDs, OPM Metamodel Lifecycle Yes Initiating (identifying, conceiving, initializing) Developing (analyzing, designing, implementing) Deploying Ontology Yes OPM Metamodel Views and viewpoints No Yes Agents: intelligent enabler which can control the process it enables by common sense or goal-oriented considerations. Instruments: non-human physical or informational enabler. Functional Somehow Considers function set in the lifecycle model Sociotechnical Architecturecentric No Defines structural links only (mereology and topology)
ISE&PPOOA Fernandez ISE & Process Pipelines in OO Architectures: Description It provides an integrated process, methods and a tool for systems engineering of software intensive mechatronic systems. The ISE subprocess: first steps of a systems engineering process applicable to any kind of system, not only the software intensive ones. It integrates traditional systems engineering best practices and MBSE. The PPOOA subprocess: emphasizes the modeling of concurrency as earlier as possible in the software engineering part of the integrated process. The integration of both subprocesses is achieved by using a responsibility driven software analysis approach supported by CRC cards. ISE&PPOOA provides a collection of guidelines or heuristics to help the engineers in the architecting of a system. It uses SysML. Tool- and vendor- neutral (add-on for Microsoft Visio 2003).
ISE&PPOOA ISE&PPOOA: Development Process
ISE&PPOOA ISE&PPOOA: Approach Concept Considered Rationale Model-based No SysML (and UML) Lifecycle Ontology Views and viewpoints Socio-technical No No Yes No? Software subsystem: static and dynamic Functional Yes Functional hierarchy Functional allocation Architecturecentric Yes Physical (as SysML BDD and IBD) Software subsystem architecture
SYSMOD Weilkiens System Modelling Method (SYSMOD): Description User-oriented approach for requirements engineering and system architectures Allows different levels of modeling intensities Guidelines and examples provided for each process activity SYSMOD Includes the following activities: o Identify stakeholder o Elicit requirements o Define system context o Analyze requirements, e.g. with use cases o Define domain model Define system architecture on different levels (functional, logical, physical) Provides additional activities, e.g., for functional architectures or variant modeling Tool vendor independent methodolog (SysML based).
SYSMOD SYSMOD: Approach Concept Considered Rationale Model-based Yes Lifecycle Yes Identify stakeholder Elicit requirements Define system context Analyze requirements, e.g. with use cases Define domain model Define system architecture on different levels (functional, logical, physical) Ontology Views and viewpoints No No Socio-technical Somehow Actors and Stakeholders Functional Architecturecentric Yes No
OOSEM INCOSE Object-Oriented Systems Engineering Method: Description Integrates top-down (functional decomposition) approach with model-based approach Leverages object-oriented concepts Uses OMG SysML (formerly UML) to support specification, analysis, design and verification of systems Intended to ease integration w/object-oriented S/W development, H/W development, and test Includes following activities: Analyze Stakeholder Needs Define System Requirements Define Logical Architecture Synthesize Candidate Allocated Architectures Optimize and Evaluate Alternatives Validate and Verify System Tool- and vendor-neutral
OOSEM OOSEM: Development Process
OOSEM OOSEM: Approach Concept Considered Rationale Model-based Yes SysML model and diagrams Lifecycle Yes Analyze Stakeholder Needs Define System Requirements Define Logical Architecture Synthesize Candidate Allocated Architectures Optimize and Evaluate Alternatives Validate and Verify System Ontology Views and viewpoints No No Somehow Actors Functional Yes Functional decomposition Sociotechnical Architecturecentric Yes Logical Physical
ASAP Alstom Advanced System Architect Program : Description Top-down approach by using Requirement Based and Model Based System Engineering (SysML) with an emphasis on railway operations. Requirement Based: organize all the requirements in a database to be able to derive and allocate requirements to different modules which are linked to a specific part of the system architecture (Train or sub-system). Model Based: depicting the System operational analysis (environment and needs), the functional vision and the constructional vision of System and Subsystem architecture. No tool support.
ASAP ASAP: Development Process
Concluding Remarks All methodologies share (in general): Use of models (MOSTLY SYSML). Lifecycle with similar phases (FROM REQUIREMENTS TO IMPLEMENTATION). Some kind of views (VIEWS OR MODELLING ASPECTS). Ontology-based (SOME KIND OF ONTOLOGY OR DATA REPOSITORY). Socio-technical aspects as actors (NOT MUCH). Pay attention to functional aspects (FUNCTION, FUNCTIONAL DECOMPOSITION, FUNCTION ALLOCATION). Architectural issues (STRUCTURE, ARCHITECTURE, INTERFACES). Distinguish between: requirements, function, behaviour. No autonomy-related ideas whatsoever. Exceptions: JPL SA (state-based control). OPM (combines objects, processes and states altogether).
ASLAB