Platform Guide

Model-Based Systems Engineering

This guide demonstrates how to use Innoslate for Model-Based Systems Engineering and builds upon the “Lesson – Autonomous Vehicle” project used in the previous guide.

Welcome to the Model-Based Systems Engineering guide!

This guide demonstrates how to use Innoslate for Model-Based Systems Engineering and builds upon the “Lesson – Autonomous Vehicle” project used in the previous guide. If you haven’t already, we recommend reading our Requirements Management and Analysis guide before proceeding with this guide.

Mercedes-Benz-Autonomous-Concept-Car (1)Photo: Mercedes Benz

At its core, Innoslate is a full Model-Based Systems Engineering tool. According to the INCOSE SE Vision 2020, “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.”

Within Innoslate, system models are formalized and capable of simulation to derive cost, schedule, and performance data. Continue to the next section to see this in action.

Functional Modeling

Functional modeling is at the heart of how Innoslate derives new requirements and ensures logical accuracy. You are probably familiar with flowcharts that depict processes or task sequences. Functional modeling is a means to create these flowcharts so that rules of logic are enforceable, and integrated performance information is derivable from these models. To begin your first functional model, follow the steps below:

  1. Click the ‘Diagrams’ button on the top navigation bar to navigate to ‘Diagrams View.’
  2. Click the ‘+ Create Diagram’ button to create a new diagram.
  3. Select ‘Action Diagram’ under ‘LML Diagrams’ as your diagram type.
  4. Click the ‘Next’ button.
  5. Type in “Metafunction” for the name of your new diagram.
  6. Click the ‘Finish’ button.

After opening the ‘Action Diagram,’ a Start and End vertex is displayed. At the highest level (root) Metafunction, each ‘Asset’ will operate on its own separate lifeline. In Innoslate's Action Diagram, this is expressed with the ‘Parallel’ construct. This allows each ‘Asset’ to operate and communicate via ‘Input/Output’ constructs independently. Utilize these three primary ‘Assets’ – “User,” “Autonomous Vehicle,” and “Environment” – to model the “Autonomous Vehicle.” To create this:

  1. Drag the ‘Parallel’ icon over to the arrow line between the Start and End nodes.

    action diagram add aprallel

  2. Click the ‘Add Branch’ button located on the toolbar to add a branch to the ‘Parallel’ construct.

    action diagram add branch

  3. Drag the ‘Branch Asset’ icon over to the top branch of your newly added ‘Parallel.

    action diagram add branch asset

  4. Type in “User” for the name of your new ‘Branch Asset.’

    action diagram name branch asset

  5. Repeat steps 3-4 for the middle and bottom branches naming the assets “Autonomous Vehicle” and “Environment,” respectively.

    action diagram add names 2 branch asset

With the parallel branches in place, we now need to add the primary actions for each ‘Asset.’ To create this:

  1. Drag the ‘Action’ icon over to the “User” parallel branch.

    action diagram add action 1

  2. Type in “Set a Destination” for the name of your new ‘Action.’

    action diagram name action

  3. Click anywhere in the white space to deselect.

    action diagram deselect

  4. Drag the ‘Action’ icon over to the “Autonomous Vehicle” parallel branch.

    action diagram add action 2

  5. Type in “Drive Vehicle” for the name of your new ‘Action.’

    action diagram name action 2

  6. Click anywhere in the white space to deselect.

    action diagram deselect 2

  7. Drag the ‘Action’ icon over to the “Environment” parallel branch.

    action diagram add action 3

  8. Type in “Exhibit Environmental Conditions” for the name of your new ‘Action.’

    action diagram name action 3

As described earlier, each parallel ‘Action’ must communicate through ‘Input/Output’ constructs. Two Input/Outputs “Destination Location” and “Environmental Conditions” which trigger “Drive Vehicle,” will be created. A trigger will block the execution of the ‘Action’ receiving the trigger until the ‘Action’ generating the trigger completes. Optional ‘Input/Outputs’ will allow the receiving ‘Action’ to execute immediately with or without the ‘Input/Output.’

To create these:

  1. Click to select the generating ‘Action’ construct named “Set a Destination.”

    action diagram add i/o 1

  2. Click and drag one of the green circles over to the receiving ‘Action’ construct named “Drive Vehicle” and release over the ‘Trigger’ option when the receiving ‘Action’ highlights green.

    action diagram add i/o 2

  3. Name the new ‘Trigger’ “Destination Location.”

    action diagram name i/o 1

  4. To create the second ‘Trigger,’ click to select the generating ‘Action’ construct named “Exhibit Environmental Conditions.”

    action diagram add i/o 1

  5. Click and drag one of the green circles over to the receiving ‘Action’ construct named “Drive Vehicle” and release over the ‘Trigger’ option when the receiving ‘Action’ highlights green.

    action diagram add i/o 2

  6. Name the second ‘Trigger’ “Environmental Conditions.”

    action diagram name i/o 2

We need to further decompose the model for the “Autonomous Vehicle.” We will now create a decomposition ‘Action Diagram’ by performing the following steps:

  1. Within the “Metafunction” diagram, click to select the ‘Action’ construct named “Drive Vehicle.”
    mbse pic 1
  2. Click to open the ‘Open’ drop-down and select the ‘Decomposition Diagram’ menu item.
    mbse pic 2

You will notice the ‘Input/Output’ constructs that are received and generated by “Drive Vehicle” are already placed on the diagram for convenience. The “Autonomous Vehicle” will need to loop until a destination is reached. During each iteration, the vehicle shall monitor the environment, calculate waypoints and obstacles, and navigate. “Camera” and “LIDAR” (‘Input/Outputs’) will transfer from the Sensors (‘Asset’), through the “Monitor the Environment” (‘Action’) to the “Control System” (‘Asset’). The control system will then calculate the waypoint and obstacles and transfer this data to the drive system. The drive system will then navigate the vehicle. We will construct this diagram (as we did with the “Metafunction” diagram) by drag-and-dropping from the left sidebar (as shown below in the “Drive Vehicle” diagram).

* Note: The direction of the dashed arrow lines drawn between the ‘Input/Output’ constructs and the ‘Action’ constructs is very important to get correct, otherwise the model may not be executable.

action daigram io directions

 

Use the table detailing the entities shown on the “Drive Vehicle” Action Diagram below to develop your model. The “Drive Vehicle” diagram includes a ‘Loop’ construct named “Reached Destination?” that will loop continuously until the final destination is reached.

* Note: The “Destination Location” and “Environmental Conditions” ‘Input/Output’ constructs are optional as these inputs are only generated once by the parent diagram. In order for a simulation to execute an ‘Input/Output’ completely, you must generate it for each iteration or mark it as optional.

Action Name Inputs Outputs Branch Asset
Reached Destination? (Loop) Destination Location (Optional)   N/A
Monitor Environment Environmental Conditions (Optional) Camera Data,
LIDAR Data
Sensor
Calculate Waypoint and Obstacles Camera Data (Trigger),
LIDAR Data (Trigger),
Destination Location (Optional)
Waypoint,
Obstacles
Control System
Navigate Vehicle Waypoint (Trigger),
Obstacles (Trigger)
  Drive System

 

We now need to elaborate on the functionality of the “Monitor Environment” action. Open the ‘Decomposition Diagram’ for “Monitor Environment.” Use the left sidebar to drag constructs to build the diagram below:

action daigram decompostion

 

A table detailing the “Monitor Environment” entities follows. Note the ‘Input/Outputs’ will automatically display on the diagram from the parent level. This ensures ‘Input/Outputs’ are traced properly at lower levels.

Action Name Inputs Outputs Branch Asset
Acquire LIDAR Data Environmental Conditions (optional) LIDAR Data LIDAR
Acquire Camera Data Environmental Conditions (optional) Camera Data Camera

Once you have completed the “Monitor Environment” diagram, we need to open the parent diagram named “Drive Vehicle.” To open the parent diagram:

Click on the ‘Open’ drop-down and select the ‘Parent Diagram’ menu item.
action diagram parent diagram

 

From the “Drive Vehicle” diagram we now need to open the “Calculate Waypoint and Obstacles” Decomposition Diagram to elaborate on its functionality. As before, use the left sidebar to drag constructs to build the diagram pictured below:

action diagram open

 

A table detailing the “Calculate Waypoint and Obstacles” entities follows.

Action Name Inputs Outputs Branch Asset
Transform Images Camera Data Parsed Images Main Computer
Parse for Obstacle Locations Parsed Images Obstacles Main Computer
Convert LIDAR Data to Obstacles LIDAR Data Obstacles Main Computer
Gather GPS Data   GPS Data FPGA
Accelerate / Decelerate to Reach Speed Limit GPS Data,
Obstacles
  FPGA
Update Waypoint GPS Data,
Destination Location
(optional)
Waypoint FPGA

Let’s Auto Number the entire hierarchy.

  1. Click on the ‘Diagrams’ button on the top navigation bar to navigate to ‘Diagrams View.’
  2. Open the ‘Action Diagram’ named “Metafunction.”
  3. Click  ‘Settings’ on the toolbar and select the ‘Auto Number’ menu item.
  4. Type in “A” for the prefix.
  5. Click the ‘Run’ button.
action diagram auto number

 

Let’s review the entire functional model using the ‘Hierarchy Chart.’ To open the ‘Hierarchy Chart’ for the root of the functional model:

  1. From the “Metafunction” diagram, click to open the ‘Open’ drop-down.
  2. Under the “General Diagrams” section, select the ‘Hierarchy Chart’ menu item.
metafunction_hierarchy_chart

 

This ‘Hierarchy Chart’ was automatically generated from the ‘Action Diagram’ models we created. This chart displays the entire functional decomposition of ‘Action’ entities that we created earlier.

Physical Modeling

We can describe synthesizing the physical model in Innoslate with eight different diagrams, including the Asset Diagram, Layer Diagram, Block Definition Diagram, and Internal Block Diagram. In this section, we will focus on the Asset Diagram and Hierarchy Chart.

Earlier, we defined ‘Assets’ through modeling the Action Diagram; let’s now refine our physical model. In the Functional Modeling lesson, we created ‘Assets’ which perform ‘Actions’ that generate and receive ‘Input/Outputs.’ This information is used to automatically generate our physical diagrams. To begin:

  1. Click the ‘Diagrams’ button on the top navigation bar to navigate to ‘Diagrams View.’

    action diagram nav

  2. Open the ‘Action Diagram’ named “Metafunction.”

    action diagram open

  3. Click Settings’ in the toolbar.

    action  diagram settings
  4. Select the ‘Generate Asset Diagram’ menu item.generate asset daigram from action diaram
  5. This has generated our first Asset Diagram.

    asset diagram generated example

 

The ‘Asset Diagram’ describes the parts of the system represented as blocks and their connections shown as lines. Similar to Action Diagrams, Asset Diagrams are decomposable to further describe subordinate levels of the system.

To complete our physical model, we will repeat the steps above and generate Asset Diagrams  using Asset Diagram Generation from the following decomposed Action Diagrams: “Drive Vehicle,” “Calculate Waypoint and Obstacles,” and “Monitor Environment.”

Let’s review our physical model with the ‘Hierarchy Chart.’ To open the ‘Hierarchy Chart’ for the root of the physical model, follow the steps below:

  1. Click the ‘Diagrams’ button on the top navigation bar to navigate to ‘Diagrams View.’
  2. Open the ‘Asset Diagram’ named “Metafunction (Physical Context).”
  3. Click to open the ‘Open’ drop-down.
  4. Under the “General Diagrams” section, select the ‘Hierarchy Chart’ menu item.
hierarchy chart 2

 

The physical hierarchy should appear as above. If your ‘Hierarchy Chart’ differs, ensure that all four Asset Diagrams were automatically generated (see above for steps to generate the Asset Diagrams).

Now, let’s Auto number the entire hierarchy.

  1. From the hierarchy chart, click  ‘Settings’ in the toolbar.
  2. Select the ‘Auto Number’ menu item.
  3. Type in “P” for the prefix.
  4. Click on the ‘Run’ button.
hierarchy chart 3

 

With our full physical hierarchy created and related to our functional model, we will generate a ‘Block Definition Diagram (BDD).’ To generate a BDD:

  1. Click on the ‘Open’ drop-down.
  2. Under the “SysML Diagrams” section, select the ‘Block Definition Diagram’ menu item.
bdd 1

 

The BDD represents our physical hierarchy and its relationships to the functional model. Now that the primary entities of the executable model are completed, let’s execute the model.

Executing the Model

Innoslate includes a ‘Discrete Event Simulator’ to verify the Action Diagram logic, calculate the cost, compute time, and quantify performance. This simulation engine can run thousands of iterations in the ‘Monte Carlo Simulator’ to observe variance across many simulation runs. In this section, we will focus on simply running the simulation to verify logical correctness. A detailed simulation tutorials is available here.

To navigate to the ‘Discrete Event Simulator’ follow these instructions:

  1. Click the ‘Diagrams’ button on the top navigation bar.
  2. Open the ‘Action Diagram’ named “Metafunction.”
  3. Click to open the ‘Simulate’ drop-down located on the toolbar.
  4. Select the ‘Discrete Event’ menu item.

The Action Trace 3D panel displays the decomposed layers of our Action Diagram in a single 3D display. The Total Time and Total Cost panes display running totals for time and cost accordingly. Note that in this example, all durations default to 1 hour. Ideally, assign all Actions to a constant or distribution of time through the Duration attribute in every Action. Click the ‘Play’ button to begin the simulation.

As the simulation runs, a prompt will be displayed. Type in “10” for the number of loop iterations and click the ‘Submit’ button. The Status Panel records which Action is currently running or blocked for execution. The color of the progress bar in the Status pane indicates the current status. The same colors are used in the Action Trace 3D to indicate which Actions are currently queued.

discrete sim 1

 

Color State Description
Yellow Input/Output Wait The Action is waiting for an Input/Output(s).
Green Executing The Action is currently executing.
Blue Complete The Action has completed execution.

The table above shows applicable wait state colors for this example. The Gantt Chart displays the order of execution in a familiar format to project managers. This Gantt Chart is easily exported to Microsoft Project by clicking the "more" tab and selecting “Export to Project.”

After the simulation has run, reports are available to export to Excel for further analysis. Additional panes for Cost, Time, Resources, and General (ex. Console), as needed.

We have yet to trace our model to the original requirements.

To return to the ‘Action Diagram,’ click the ‘Innoslate’ button located below the Innoslate logo in the upper left-hand corner.

Relating Requirements to Diagrams

Requirements traceability ensures that the lifecycle and origin of a requirement are fully tracked. Innoslate includes relationship matrices to represent traceability relationships between entities in a tabular view.

To open the requirements matrix:

  1. From ‘Documents View,’ open the Requirements Document: “SAE Level-5 Automation Requirements.”

    docs dashboard

  2. Click the ‘Open’ drop-down menu.

    open docs view

  3. Click ‘Traceability Matrix’ under ‘Matrices.’

    nav to traceability matrix

  4. Ensure ‘Hierarchy’ is selected for the ‘Top (X Axis).’

    traceability matrix 1

  5. Select ‘A Metafunction’ as the ‘Root Entity.’

    traceability matrix 2

  6. Select ‘satisfied by’ as the ‘Relationship Type.’

    traceability matrix 3

 

We are now viewing a matrix displaying the traceability between the requirements and the functional model we developed earlier.

traceability matrix 4

 

Note that traceability is not yet defined. To add a relationship, simply click the box in the cell between an Action and its associated requirement. These relationships express the traceability between the requirements and the functional model. Repeat this process until the matrix appears as below.

traceability matrix 5

 

Matrices can display any relationship within Innoslate. For example, a matrix between “Metafunction” and “Metafunction – Physical Context” is displayed below using the ‘performed by’ relationship.

  1. From ‘Diagrams View,’ open the Action Diagram “A Metafunction.”
  2. Click the ‘Open’ drop-down menu.
  3. Click ‘Traceability Matrix’ under ‘Matrices.’
  4. Ensure ‘Hierarchy’ is selected for the ‘Top (X Axis).’
  5. Select ‘P Metafunction (Physical Context)’ as the ‘Root Entity.’
  6. Select ‘performed by’ as the ‘Relationship Type.’
traceability matrix 7

 

Through this matrix, we will notice that “Reached Destination?” is not performed by any assets. Let’s add a ‘performed by’ relationship between “Autonomous Vehicle” and “Reached Destination?” by clicking the cell at their intersection.

traceability matrix 8

 

Click the ‘Save’ button to record the change.

Ensuring Overall Model Quality

As an Innoslate project grows in size and complexity, so does ensuring model quality. In the software domain, many tools exist to maintain quality: compilers, static code analysis tools, and even automatic graders. The value of these tools is increased accuracy and significantly reduced cost.

Innoslate includes three tools to ensure models developed are of high quality. The “Quality Check” feature of ‘Documents View’ is utilized to assess the quality of textual requirements, as covered earlier in the Requirements Management and Analysis guide. The simulators can validate the logic of a functional behavior model. ‘Intelligence’ analyzes the model to assess traceability, model construction, naming conventions, and more.

To run an ‘Intelligence’ analysis:

    1. Open the ‘MENU’ drop-down and click the ‘Intelligence’ menu item under the “Tools” section.
    2. Once in the ‘Intelligence’ tool, the analysis will begin automatically the first time you open the view. To re-run the analysis (after model changes), click on the ‘Run’ button.
traceability matrix 9

 

As you can see, Intelligence has analyzed our models using heuristics and machine learning language models. There are six sections assessed: “Global,” “Action,” “Asset,” “Conduit,” “Input/Output,” and “Requirement.” You will notice that the model we created receives a 100 percent in each category based on the default settings.

You may wish to enable additional checks or remove checks that are unimportant to your use case. To do this, click on the ‘Settings’ button on the top right to modify which checks are performed and their criticality (warning/error).

Further Reading

Now that you’ve been properly introduced to Model-Based Systems Engineering, we encourage you to further your knowledge by reading our next guide: Verification and Validation