Automated System Analysis using Executable SysML Modeling Pa8erns

Transcription

1 Automated System Analysis using Executable SysML Modeling Pa8erns Maged Elaasar* Modelware Solu<ons h8p://magedelaasar.com CEA LIST, Paris, France March 2016 *In collabora<on with Robert Karban (JPL) and Nerijus Jankevičius (NoMagic)

2 Maged Elaasar Ph.D. in Computer Systems Engineering (Canada) Senior SoWware Architect at NASA s JPL (USA) Leads R&D work in MBSE Formerly Senior SoWware Architect at IBM Led R&D work in MDE (e.g., RSA, DM) Founder of Modelware Solu<ons Consults on MDE technologies Affiliated with several interna<onal research labs Leading modeling standards at OMG

3 Systems Analysis Decomposing the system into its components for the purpose of studying how well those components work together and interact to meet some objec<ves or sa<sfy some constraints

4 Requirements Verifica<on A kind of systems analysis that assesses whether a system design meets the objec<ves and sa<sfies the constraints that are implied by the system requirements

5 Model Based Systems Engineering MBSE is the formalized applica<on of modeling techniques to support system requirements, design, analysis, verifica<on, valida<on and documenta<on ac<vi<es MBSE expresses a system using a Systems Modeling Language (SysML), a profile of UML MBSE is owen applied with a method like Object Oriented System Engineering Method (OOSEM)

6 Project Ques<on How to perform requirements verifica<on on systems models using vanilla SysML?

7 Proposed Approach An extension of OOSEM named Executable Systems Engineering Method (ESEM) ESEM produces executable SysML models that verify requirements ESEM provides a set of analysis pa8erns that are specified with various SysML structural, behavioral and parametric diagrams

8 Executable Models Most SysML models today are created for documenta<on purposes The focus is on syntax and nota<on Some SysML models are created to gain system understanding, explore and validate desirable or undesirable behaviors of a system The focus is on seman<cs

9 Model Execu<on Executable SysML models are defined with a subset of the language with well defined execu<on seman<cs The subset is called Founda<onal UML (fuml) SysML inherits the fuml subset from UML SysML models are executed with the help of an execu<on, or simula<on, engine Ex.: MagicDraw s CST Ex.: Papyrus s MOKA

10 Cameo Simula<on Toolkit (CST) A plugin to MagicDraw SysML modeling tool A simula<on plagorm based mostly on fuml but plugs in addi<onal execu<on engines State Chart XML (SCXML) Scrip<ng for the Java Plagorm (JSR 223) Precise Seman<cs of Composite Structures (PSCS)

11 CST Parametric Solver Executes SysML parametric diagrams based on the PSCS seman<cs At object instan<a<on <me, it analyzes the causality of a8ributes, i.e., determines which a8ributes are given (pre-bound) and which are target (unbound) Allows the given values to immediately propagate and update any target values awer constraints evaluate (with a math solver) Whenever the value of an a8ribute that is bound to constraint parameter changes, the constraint is reevaluated and updates all related variables, crea<ng a cascade effect

12 Object Oriented Engineering Method Defines the architecture in terms of: Domain: the context of the solu<on Enterprise: the ecosystem of the solu<on System of Interest: the solu<on being specified» Black Box: externally visible specifica<on» Conceptual: white box func<onal specifica<on» Physical: white box realiza<on specifica<on

13 Running Example Thirty Meter Telescope (TMT) h8p:// Alignment and Phasing System (APS) Sensor responsible for pre-adap<ve op<cs wavefront quality Developed by TMT Interna<onal Observatory (TIO) JPL par<cipates in several subsystems of TMT JPL delivers the APS based on requirements from TIO APS team uses MBSE to analyze requirements, produce design, and performs analysis

14 Running Example Objec<ves Use MBSE to define executable SysML model that captures requirements, opera<onal scenarios (use cases), system decomposi<on, rela<onships and between subsystems, etc. Use the model to analyze the system for power consump<on Also mass and dura<on analysis (but out of scope) Produce documents like Design Descrip<on Document Requirement Flow Down Document Opera<onal Scenario Document Goals: use standard languages and techniques, avoid custom sowware development

15 Executable System Engineering Method (ESEM) Step 1: Formalize Requirements Step 2: Specify Design Step 3: Characterize Components Step 4: Specify Analysis Context Step 5: Specify Opera<onal Scenarios Step 6: Specify Analysis Configura<ons Step 7: Run Analysis Step 8: Evaluate Requirement Sa<sfac<on

16 Step 1: Formalize Requirements Requirement Pa8ern Customer Side Define the textual requirement with a Requirement Op<onally define a design black box specifica<on with a Block with relevant value proper<es Op<onally refine the Requirement with a Constraint Block on the black box design Block Supplier Side Define a design black box specifica<on with a Block (that refines the customer s black box Block if any and provides <ghter property values) Refine the textual Requirement by a Constraint Block (if not already defined by the customer)

17 Step 1: Formalize Requirements

18 Step 2: Specify Design Follow OOSEM to define two white box Blocks that specialize the black box Block Conceptual Block (out of scope for brevity) Physical Block Decompose the white box designs with Blocks represen<ng the subsystems

19 Step 2: Specify Design System Decomposi<on Hierarchy

20 Step 3: Characterize Components Add relevant pa8erns to the design Block to make it executable Example: Roll-up Pa8ern Constrained value represents an aggregate value that is propaga<ng up a hierarchy of subcomponents Sta<c roll-up (e.g., mass roll-up) Dynamic roll-up (e.g., power roll-up)

21 Step 3: Characterize Components Power Rollup Pa8ern

22 Step 3: Characterize Components Power Roll-up Pa8ern Varia<on

23 Step 4: Specify Analysis Context Analysis Context Pa8ern Abstract analysis context Block composes both the design black box Block and white box Block Analysis proper<es defined on the analysis context Block (e.g., peak power, power margin) Analysis parametric model on the analysis context that computes and binds analysis values

24 Step 4: Specify Analysis Context Analysis Context Pa8ern

25 Step 4: Specify Analysis Context Analysis Context Parametric Model

26 Step 5: Specify Opera<onal Scenarios Opera<onal Scenario Pa8ern Concrete analysis context Block that Represents one opera<onal scenario (e.g., power configura<on) Specializes the abstract analysis context Block Redefines context s proper<es with scenario-specific values Defines an owned behavior (sequence diagram) as scenario driver» Changes the states of the different components, by sending them signals, causing the rolling-up to occur automa<cally» Can specify dura<on constraints to <me the injec<on of signals thus controlling <me spent in a certain state» Can use state constraints (on components) to verify during execu<on if a component is actually in expected state

27 Step 5: Specify Opera<onal Scenarios Opera<onal Scenario Pa8ern

28 Step 5: Specify Opera<onal Scenarios Opera<onal Scenario Driver

29 Step 6: Specify Scenario Configura<ons Scenario Condi<on Pa8ern A decomposi<on tree of instance specifica<ons represen<ng the state of the scenario Can be presented in tabular form Rows represent the instance specifica<ons (e.g., component) Columns represent values (e.g., opera<ng power) from the instance specifica<ons Issues Hard to keep instance specifica<ons in sync with BDDs Mi<ga<on: tool automa<on Instance specifica<ons cannot be displayed in IBDs Mi<ga<on: use full specializa<on tree of singleton Blocks for each scenario

30 Step 6: Specify Analysis Configura<ons Scenario Condi<on Pa8ern

31 Step 6: Specify Scenario Configura<ons Scenario Configura<on Pa8ern Scenario configura<on is an Instance Specifica<on of the scenario s concrete analysis Block References an ini<al scenario condi<on with an <<analyzes>> rela<onship References a final scenario condi<on with an <<explains>> rela<onship

32 Step 6: Specify Analysis Configura<ons Scenario Configura<on Pa8ern

33 Step 7: Run Analysis Run the configured analysis with a simula<on engine on the ini<al condi<ons to get the final condi<ons: Produce the following views on final condi<ons Table showing final analysis values (e.g., peak power) and the constraint s pass/fail status for each scenario Timelines: state changes for components over <me Value profiles: total rolled up values over <me

34 Analysis Result Views Step 7: Run Analysis

35 Step 8: Evaluate Requirement Sa<sfac<on Requirement Sa<sfac<on Pa8ern Requirement sa<sfac<on Block aggregates the black box Block[1] (customer) and white box Block[*] (one for each opera<onal scenario) from supplier A parametric model on the requirement sa<sfac<on Block checking that all the supplier values conform to the customer value (have lower power level) Instance Specifica<on of requirement sa<sfac<on Block that <<analyze>> all final scenario condi<ons and <<explain>> a <<sa<sfy>> rela<onship from the design black box to the textual requirement

36 Step 8: Evaluate Requirement Sa<sfac<on Requirement Sa<sfac<on Pa8ern

37 Step 8: Evaluate Requirement Sa<sfac<on Requirement Sa<sfac<on Parametrics

38 Summary It is possible to automate requirements verifica<on in SysML models Introduced a new Executable System Engineering Method that consists of a set of pure SysML analysis pa8erns The method can be executed using an over the shelf simula<on engine for SysML

39 Reference Karban, R., Jankevičius, N., Elaasar, M. ESEM: Automated Systems Analysis using Executable SysML Modeling Pa8erns, (to appear in the proceedings of INCOSE Interna<onal Symposium (IS), Edinburgh, Scotland, 2016.) Karban, R., Jankevičius, N., Elaasar, M. Crea<ng System Engineering Products with Executable Models in a Model Based Engineering Environment. (to appear in proceedings of Modeling, Systems Engineering, and Project Management for Astronomy VI, Edinburgh, UK, 2016)