Systems Modeling Language (SysML)

2 What is SysML? A graphical modeling language in response to UML for Systems Engineering developed by the OMG, INCOSE, and AP233 Supports the specification, analysis, design, verification and validation of systems that include hardware, software, data, personnel, procedures, and facilities SysML is Critical Enabler for Model Driven SE

3 SST Philosophy Deliver solution to the users without delay SysML 1.40 (Sep. 2015) widely regarded as an “80% solution” Systems engineering users demanding this language Reuse UML at the package level to maintain language integrity Limit fine grain selection of UML elements at this time

4 SYSML Summary Structure e.g., system hierarchy, interconnection Behavior e.g., function-based behavior, state-based behavior Properties e.g., parametric models, time property Requirements e.g., requirements hierarchy, traceability Verification e.g., test cases, verification results Other e.g., roles, views, relationship types, diagram types Optional e.g., trade studies, other behavior modeling paradigms

5 Relationship Between SysML and UML UML4SysML SysML Profile

6 SysML Diagram Taxonomy

7 Reuse of UML 2 – UML4SysML SysML Profile Retains UML Integrity

Modeling methodology Modeling starts at the highest level of the system by modeling the different top level components. Next, a behavioral SysML use case diagram is presented, to determine the different case scenarios present in the system. Following that, low level components and illustrate their relative aspects, such as behavior expressed via SysML diagrams such as state and sequence diagrams. 8

9 Model Elements Used to organize model Package diagram used to group model elements into a name space SysML extension for view and viewpoint Rational stereotype can be applied to any model element to capture decision

10 Organizing the User Model

11 Views and Viewpoints Viewpoint represents stakeholders, their concerns/purpose/intent, and construction rules for specifying a view View is a read only mechanism that captures the model subset that addresses the stakeholder concerns Realizes the viewpoint Relationships between model elements established in model and not between views

12 IEEE 1471 viewpoint contains: a) A viewpoint name b) The stakeholders to be addressed by viewpoint c) The concerns to be addressed by the viewpoint d) The language, modeling techniques, or analytical methods to be used in constructing a view based upon the viewpoint e) The source, for a library viewpoint (the source could include author, date, or reference to other documents, as determined by the using organization)

13 View/Viewpoint Viewpoint as a stereotyped class View realizes a viewpoint Relationship between Viewpoints

14 Performance View Example

15 Rationale Rationale can be attached to any Model Element or Relationship to Capture decisions Rationale can link to a trade study or analysis report

16 Blocks Unification of classes and assemblies Property subclasses Deep nesting Design values Specification of value types with units, dimensions, and probabilities Instance diagrams Resolution of Blocks Issues Resulted in Solid Structural Foundation for SST Submission

Example (industrial automation unit) the unit has been composed of three subsystems: the physical subsystem the control subsystem the supervisory subsystem the control subsystem controls the physical subsystem by means of certain smart devices 17

18

19 Power Subsystem Breakdown

20

21

the use case diagram abstract overview of system behavior through a SysML use case diagram. The use case illustrates the system behavior that is visible to the end user (actors) and external to the system. there are several use cases present, related to how the system is operated, controlled, supervised etc. 22

23

24 Top Level Use Cases

25 Operational Use Cases

26 Property Subclasses Property is a structural feature of a block which is further sub-classed in SysML Part property aka. part (typed by a block) Usage of a block in the context of the enclosing block Example - right-front:wheel Value property (typed by value type) Defines a value with units, dimensions, and probability distribution Example - tirePressure:psi {distribution=Uniform (min=27,max=29)} Reference property (typed by a block) A part that is not owned by the enclosing block Example - logical interface between 2 parts

27 ibd blockAutomotive Domain env : Environment road : Road vehicle : HSUV 2 front : Tire 2 rear : Tire Deep Nesting Provides Intuitive Modeling of Physical Systems and does not Impose Process Simple Example of Deep Nesting Connecting a Tire to a Road No need for modeler to specify intermediate connections

28 Design Values Example «part» 2 back : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=27,max=29)} «part» 2 front : [Wheel] Properties tyrePressure : psi {distribution=Uniform (min=25,max=27)} ibdSUV Car SUV Wheel tyrePressure : psi 21 back 21 front bddCar Design [] Indicates part-specific block Supports different values & distributions for each part Design Values Ease Ability to Specify Different Values/Distributions on Parts in Same Context

29 Ports Approach Ports represent block interaction points via which Blocks provide or consume data/material/energy or services Support specification of interfaces on a block independent of a specific usage (e.g. this component requires 110 volts of power input) 2 Distinct Port Types that Support Different Interface Concepts

30 two port types Flow ports Port type specifies what can flow in our out of block/part A connection point through which there is a flow of information, material, or energy (I/O) Typically asynchronous flow where producer is not aware when/who consumes the flow Client server ports Service oriented (request-reply) peer2peer interaction Typically synchronous communication Specified similar to UML2.0 ports using required/provided interfaces detailing the set of provided/required services Allow signal exchanges for compatibility 2 Distinct Port Types that Support Different Interface Concepts

31 FlowPorts Additional considerations Simple (natural) way for SEs to specify I/O via the port Address the common case of atomic FlowPorts Allow both signal flow and data/block instance flow FlowPorts Specification I/O is specified using an interface stereotyped FlowSpecification FlowSpecification consists of properties stereotyped FlowProperties FlowProperty has a direction attribute: in, out, inOut FlowProperties can be typed by ValueTypes, Block, and Signals isConjugate promotes reuse of flowSpecifications Atomic FlowPorts It is common that a FlowPort flows a single item type In this case the port is directly typed by the item type (Block or Value) Direction property specify the direction Compatibility rules on ports facilitate interface compatibility

32 Power Subsystem IBD Client server port Flow port Item flow Specifying Interfaces on an IBD in Terms of Connectors, Ports and Flows in Terms of Connectors, Ports and Flows Connector

33 Parametrics Used to express constraints (equations) between value properties Provides support to engineering analysis (e.g. performance, reliability, etc) Reusable (e.g. F=m*a is reused in many contexts) Non-causal (i.e. declarative statement of the invariant without specifying dependent/independent variables) Parametrics Scalability & Integration with Engr Analysis Validated by Georgia Tech

34 Parametrics Constraint block defined as a simple extension of block Packages UML constraint so they are reusable and parameterized Constraint and constraint parameters are specified Expression language can be formal (e.g. MathML, OCL …) or informal Computational engine is defined by applicable analysis tool and not by SysML Parametric diagram represents the usage of the constraints in an analysis context Binding of constraint usage to value properties of blocks (e.g. vehicle mass bound to F= m * a)

Modeling the arithmetic functions block using SysML constraint blocks, we will first define the relationships between the ARTH module and various other arithmetic equations that are used in this functional block, as shown in the figure. 35

36

37 Defining Vehicle Dynamics Defining Reusable Equations for Parametrics

38 Evaluating Vehicle Dynamics Using the Equations in a Parametric Diagram to Constrain the Value Properties

39 Evaluating Measures of Effectiveness MOE’s and objective function provide flexible support for trade study analysis that is fully integrated with parametrics

Using activity diagrams We are now going to model the control strategy action. This action is expressed by means of a SysML activity diagram that focuses on the input, output, sequences and related conditions. The control strategy is related to the global system and is among one of several strategies that the system can implement. 40

41

42 SysML Profile Aligning SysML with Proven Systems Engineering Techniques

43 Distill Water Activity Diagram (Initial) Representing Distiller Example in SysML Using EFFBD Profile

44 Interactions Sequence diagrams provide representations for message based behavior Represents flow of control Less effective than activities for representing inputs from multiple sources Timing diagrams provide representations for typical system timelines and value properties vs time

45 Black Box Interaction (Drive) UML 2 Sequence Diagram More Scalable by Supporting Control Logic and Reference Sequences

46

47 Black Box Sequence (StartVehicle) Simple Black Box Interaction References Lifeline Decomp For White Box Interaction

48 White Box Sequence (StartVehicle) Decomposition of Black Box Into White Box Interaction

49 State Machines Supports event based behavior (generally asynchronous) Transition with event, guard, action State with entry, exit and do-activity Can include nested sequential or concurrent states Two types of state machines Behavior state machines is typical use Protocol state machines used to specify sequence of operations or signals Can be used as a specification on a port

50 Operational States (Drive)

51 Allocations Provides general relationship to map one model element to another Includes specific subclasses of allocation with constraints on their usage Behavioral Structural Flow Explicit allocation of activities to swim lanes (e.g. activity partitions) Graphical and/or tabular representations

52 Different Allocation Representations (Tabular Representation Not Shown) Explicit Allocation of Activity to Swim Lane Allocate Relationship Callout Notation Compartment Notation

Modeling system requirements the requirements applied to the system specifically, the requirements are related to the level control strategy. The different requirements are satisfied by system blocks. The SysML allocation mechanism also enables system designers to map/allocate different elements, activities or other aspects. 53

54 Requirements Requirements represents a text based requirement Minimal properties specified for id and text based on user feedback Able to specify constraints on what design elements can satisfy the requirement Requirements containment used to specify requirements hierarchy as a collection of requirements (e.g., a specification) Requirements relationships based on subclasses of dependency

55

56 Dependencies Used to specify relationships among requirements (other uses as well) Different concept for SE’s with arrow direction reversed from typical requirements flow-down Refer to next slide Represents a relationship between client and supplier elements Client depends on supplier A change in supplier results in a change in client Application to requirements: A change in requirement (supplier) results in a change in design element that satisfies it (client) or requirement derived from it (client) Dependency Relationship Is New Concept for Some SE’s

57 Example of Derive/Satisfy Requirement Dependencies Client Supplier Client Supplier Arrow Direction Opposite Typical Requirements Flow-Down

58

59

60

61

62

63

64