To follow on for my introduction in Part 1 in which we cover the core benefits of Model
Based Systems Engineering. We will now run over a key industry-based MBSE language SysML.
In this webinar we cover more applied MBSE by running over SysML examples. As stated earlier there are
other languages based around MBSE. However SysML is considered exemplary in this field.
As a structure for this webinar we'll look at what would term the
Four Pillars of SysML and expand on this to include other Diagram types commonly used.
Then in Part 3 we will run over the Human as well as the Computer Interpretation of these Models.
As a general overview of SysML it is expressed as having Four Pillars with the interoperability
between these. The Four Pillars are Structure, Behavior, Requirements and Parametrics.
The general industry interpretation of these four specific modeling types is more focused on the
intensity of usage rather than on any lineal time of staging view. So it does not incorporate other
stage parts of the process like Vision/Mission, Domain Model, Analysis and Verification.
However for now we will cover this from the Four Pillars SysML Specification Perspective.
Let's run over the HSUV Example supplied with the OMGs SysML 1.6 Specification, which is modeled
in the EA Example Model supplied with Enterprise Architect. As the start of the process we have
some core Requirement Models covering all the key points needed for the car design all the way
down to the Fuel Requirements. Then we have the Structural Models, the Block Definition Diagrams,
the Internal Block and Constraint Block Diagrams. In this case a Block Definition View of the
PowerSystemFuelFlow and its relation to the FuelTankAssembly. Then we have the Behavioral
Models, which includes Activity, State Machine and Interaction Diagrams. In this case we have an
Activity Diagram looking at the PowerFuelFlow in the car. Finally we have the Parametric Diagrams
that cover the Interactional Mathematical Formula and the parameters that feed it.
Let's look at the Requirements first. Although Requirements are not the primary starting point of
a Model. These are crucial and play a key part in the higher level of initiation of a large project.
These are a high level of abstraction that lay out clear points covering the features that are
to be constructed. We have here the reference to the Specification and the various Requirements
derived from that. On any Element you can update the Text and the ID in the Fields. This Diagram
format provides a brief overview. We can set the Diagram format to show the Text of each Requirement.
This includes text-based Descriptions on each Requirement and it's Identifier.
For a more document centric approach we consider to use the Specification Manager View.
As stated earlier these Requirements can also include Foundation Requirements taken
from Specifications. In this case we have some basic AUTOSAR Requirements that will provide a
foundation for the HSUV be modeled. They can also include Requirements specific to your Organization
and to any Core Requirements for the Domain that you're working on. We'll cover Traceability of
these Requirements in Part 3 with the structural side of SysML. This includes the Block Definition,
the Internal Block Definition and the Constraint Block Diagrams. A Block defines a collection of
Features used to describe a System, Subsystem, Component or other Engineering Objects that are
related to the scope of what is being designed. This includes Blocks and Part Properties.
The Objects in these Diagrams define, what is to be used. This is distinct from how these are used
as specific Instances. Which we will cover later, in the Internal Block Definition Diagram or IBD.
The core points that Blocks convey are Structural Composition, Connectivity and Classification.
Structural Composition. The Block Definition Diagram can be used to lay out the Structural
Composition. For example in the Hybrid HSUVs that was supplied with the EA Example Model.
We have the core structures including the Power Subsystem, the Brake System and the Body System.
With the Connectivity let's take a quick look at the Traceability View for the Power
Subsystem Block. Here we see a variety of Relationships. The core of this Block
of Definition we have Part Associations. Underlying these are many others as you
can see via the Traceability View of the Power Subsystem. This is just one on this plane but
there are Hierarchical Relationships down into the Internal block Diagrams or IBDs,
which we will cover later. For Classification a Block can be a specific case of a more Abstract Block.
That is it can be an inheritance of the Core Features of that Abstraction.
For instance we see this case where a FrontWheel is derived from a WheelHubAssembly Classifier
and has specific characteristics different to a RearWheel derived from the same Block.
The Block Definition Diagrams and the Internal Block Definition Diagrams work complementary to
one another. With the IBD showing the usage of the past defined in the Block Definition Diagram
that encapsulates them. For example with the BlockPowerSubsystem, breakdown by double clicking this.
We have the IBD CAN Bus Description. This includes Parts derive from the Blocks
defined in the PowerSystem Block Definition Diagram. For this we have a Core Component,
the Controller Area Network or in short CAN, which includes Connectivity Fire Ports for the
ElectricalPowerController, the Transmission, the InternalCombustionEngine and a PowerControlUnit.
All providing Network interactions between these. Let's have a quick run through the
creation process for an IBD covering some Core Connections to the CAN Bus for our car.
First we create the IBD under the PowerSubsystem, then we create a Part Property from the CAN Bus Lock.
Then we create a Part from the ElectricalPowerController.
On creating this we select the “All” on the ‘Structural Elements’ to ensure that All of
its Parts and Properties are to be shown. In order to work on what Ports are shown we only want to
show the Flow Ports, so we open the Features window and select the Ports and Parts Tab.
Then we unselect the Ports we don't want to show. We leave the Flow Port.
For Diagram Clarity we stop the Stereotype being shown in this Diagram.
Then we give the ElectricalPowerControl part a short name identifier.
Then we add in the Transmission and set that to show only the Flow Ports.
We also include the InternalCombustionEngine and the PowerControlUnit.
Then we connect each of these Flow Ports to the CAN Bus -
and that completes our IBD. For the key Parts interacting through the CAN Bus
showing the usage of Blocks, Ports and Connectors.
The Constraint Blocks are where we define the formula or equations behind the Parts
that will be used in the Parametric Models. In the example of the HSUV we have a number of Constraint
Definitions. This StraightLine VehicleDynamics is a specific group that is part of a broader group
of Constraints. These Constraints contain Equations that are used in the related
Parametric Models. Let's have a look at creating a Constraint Block using the Constraint Wizard.
From the HSUV Specification we are given a Math Formula
from the FuelFlowRate. We take that to create our Constraint.
We start in this new Block Definition Diagram. Press space bar to create a new Constraint Block.
This prompts us with the ‘Edit Constraint Block Wizard’. We add the Formula from the
Specification and on exiting this field we see the Parameters defined below, which are derived
from the Formula. The types of each of these in this case happen to be real, but they can
be easily altered. Note that the Edit Constraint Block Option is accessible in the Context Menu.
The Parametric Diagram is made to enforce the Rules that are defined in the Constraint Box.
In particular for the Mathematical Equations that are to be used. Looking back at the Block
Definition Diagram covering the PowerSystem we have a Subsidiary Block Definition for
the Fuel Flow Definition. Related to this is the Fuel Flow Constraint, we just created.
We can see that these Equations are used in the Parametric Diagram, which ties these Mathematical
Rules using Ports and Binding Connectors in other words keyword Equals between the Constraint Block
Equation and its Parameters with the Part Value Properties on the Parametric Diagram.
For a more complex example we look at the StraightLine VehicleDynamics.
Again defined in the Constraints and derived from HSUV Block Definition Diagram.
Like the convenient tools to help you create Constraint Blocks Enterprise Architect also
provides a process to set up Parametric Diagrams by parsing Mathematical Equations
to create Parameter Binding Connectors. In this case we create a new Parametric Diagram.
Name it.
Then drop on the Constraint Block that we just created. Then given an abbreviated name.
Then in the Context Menu we select ‘Edit Constraint Properties’. This brings up the
Parameter Binding Window. Then we select what Properties we want these to bind to.
In this case these are the Parameters in the Fuel Block which this Diagram is a child of.
That gives us this simple Parametric Diagram with
bindings to cover the Parameters used in the Equation. In Part 3 we will look
at how these types of Constraints and Bindings are used in Model Simulations.
Having had a brief run over the Structural Modeling. Let's now have a look at the
Behavioral Modeling side. The core set of UML Behavioral Model Types can be applied in SysML.
In the design process these can start above the Block Definitions. There's more Abstract
Models used in the Analysis. Such as under Use Cases or later they can be more tightly included
in the Block and Internal Block Diagrams with specific details including Port Definitions.
What is available are Use Case Diagrams, Activity Diagrams, State Machine Diagrams and Interaction
Diagrams. As there are numerous videos covering the standard UML Behavioral Modeling and given
System or Behavioral modeling is derived from UML, but we won't go too deeply into these.
Let's start with a more abstract Use Case Diagram. Although expressed in
UML Behavioral Diagrams these are not considered Turing complete so are not simulatable, but they
are used on the abstract level for calling more complete Behavioral Models. Here we have a layout
of the Analysis of the User's Interaction based on the Requirements defined earlier. For example -
In the Operational Use Case Diagram we have the Drive the Vehicle Use Case, which includes Accelerate,
Steer and Brake. It also has child Diagrams an Interaction Diagram and a State Machine.
Both are not being defined under a Block and so are simply expressing the Analysis Work Through
for these Use Cases. If we go into more tightly defined Behavioral Models. There are children
of Blocks such as State Machines, Activity and Sequence Diagrams. We see a very different case.
With SysML these are defined under the Blocks as owned Behaviors.
Let's look at the Function base Behavior of Activity Diagrams. With Activity Diagrams we
can use these to Define Block Functions based as Models under the Blocks. In this case we have an
Activity Diagram as an Aggregation of the Power Block in HSUV. This is defining the Human Process
of pushing the Accelerator and the parallel process of Provide Power. With the Provide Power
this is passing the Flow to use either the Battery or for Speed using the Internal Combustion Engine.
All based on the Accelerator position in the Vehicle Mode Preference to define, which to use.
We also see that it is defined as an Aggregation of the Power Block.
With a State Machine defined under a Block as an owned Behavior that states: Operation, Transition,
Guards and Effects can reference the Properties of the Parent and determine the Transition
between the States based on these Parameters. Let's look at an example that is modeling a
Humidifiers Heat Controller. This State Machine is a simple Continuous Flow with the Control Status
changing based on the Values of the Properties of the Parent Block, the Heat Control Block.
The Interaction Points we can see are defined in the Features Window. These Properties are used in
the Transition Guards with a JavaScript condition determining the Flow. This example uses SysPhS
for refining Simulator Specific Values and can be simulated in both by Modelica and Matlab Simulink.
When looking at examples of Interaction Diagrams. We go back to the HSUV Model.
We have some examples of Sequence Diagrams under the derived Use Case, where we have several
Interaction Occurrence References. Beginning with the Start of the Vehicle Black Box, which is
referencing a simple Sequence Diagram. Where we have a reference to the Start Vehicle White Box.
Each of these showing the interaction between Parts that are derived from Blocks in the Model.
In this last case the Electronic Control Unit or ECU enabling Electrical Power Controller.
What is a fundamental underlying principle of engineering is the definition of Units
of Measure and how these are defined and used consistently across a project.
The SysML Value Type is used for defining a Unit of Measure. A Quantity of Kind that is associated
with the Value or Measure and provides a fundamental reference of Quantity within the scope
of the Model. Here we have an example of this as defined in HSUV Model. This covers the core Units
of Measure used throughout the Model. To look at an example of the application of these we see that
in the Fuel Efficiency Equation Constraint Block. We have Values set with these. In this case the
Wheel Power is set to Horsepower, which can be referenced from the Element Properties under Type.
Although we have covered some of the key Diagram Types based around the Four Pillars.
There are other key Overview Diagrams such as the Domain Model and the Package Diagram.
The Domain Model clarifies the Domain in which the Model is working. Defining a Boundary to ensure
there is no Scope Creep ensuring external Features are not included in the Project.
With the Package Diagram the main Elements shown in these are the set of core Packages
that represent a summary of the complete Model. In this case it includes the Requirements Package,
the Root of the Structural Package Tree and the Behavioral Model Package Tree.
This usually includes a Model Library of commonly used Objects such as Definitions and the Value Types.
As outlined earlier. Before going on to look at other aspects of the Human and
Computer Interpretation of the modeling. Let's do a brief summary of the points covered in the SysML
presentation. In this we have covered in detail the Four Pillars of SysML including Requirements,
Structural Modeling including Block Definition Diagrams, Internal Block Diagrams, Constraint
Block Diagrams and Parametric Diagrams. Then we looked at Behavioral Model Diagrams including
Use Case Diagrams, Activity Diagrams, State Machine Diagrams and Interaction Diagrams.
In conclusion hopefully Part 2 of this series is giving you a good overview
of applying MBSE. Along with some core detail of working with SysML for Model Based Systems
Engineering in Enterprise Architect. In Part 3 we will be looking at the Human and Computer
Interpretation of the modeling including Simulation and Model Based Code Generation.