Model-Based Systems Engineering

Last modified on September 13th, 2018.


Welcome to the Model-Based Systems Engineering guide!

This guide is meant to demonstrate 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.

Photo: Mercedes Benz

At its core, Innoslate is a full model-based systems engineering tool. According 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 '+ New 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 'Next' button.
  7. 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, this is expressed with the 'Parallel' construct. This allows each 'Asset' to operate independently communicating via 'Input/Output' constructs. 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.

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

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

  4. Type in "User" for the name of your new 'Branch Asset.'

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

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.

  2. Type in "Set a Destination" for the name of your new 'Action.'

  3. Click anywhere in the white space to deselect.

  4. Drag the 'Action' icon over to the "Autonomous Vehicle" parallel branch.

  5. Type in "Drive Vehicle" for the name of your new 'Action.'

  6. Click anywhere in the white space to deselect.

  7. Drag the 'Action' icon over to the "Environment" parallel branch.

  8. Type in "Exhibit Environmental Conditions" for the name of your new 'Action.'

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 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."

  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.

  3. Name the new 'Trigger' "Destination Location."

  4. To create the second 'Trigger,' click to select the generating 'Action' construct named "Exhibit Environmental Conditions."

  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.

  6. Name the second 'Trigger' "Environmental Conditions."

We need to further decompose the model for the "Autonomous Vehicle." We will now create a decomposition 'Action Diagram' by:

  1. Within the "Metafunction" diagram, click to select the 'Action' construct named "Drive Vehicle."
  2. Click to open the 'Open' drop-down and select the 'Decomposition Diagram' menu item.

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.

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 for the "Monitor Environment" action. Open the 'Decomposition Diagram' for "Monitor Environment." Use the left sidebar to drag constructs to build the diagram below:

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:

  1. Click on the 'Open' drop-down.
  2. Select the 'Parent Diagram' menu item.

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:

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' in the toolbar.
  4. Select the 'Auto Number' menu item.
  5. Type in "A" for the prefix.
  6. Click the 'Run' button.

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.

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.'

  2. Open the 'Action Diagram' named "Metafunction."

  3. Click 'Settings' in the toolbar.

  4. Select the 'Generate Asset Diagram' menu item.

  5. This has generated our first Asset Diagram.

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 follow the same Asset Diagram Generation for the decomposition of the following 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.

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 Autonumber 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.

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.

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 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 tutorial 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 are defaulted 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.

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

The table above shows applicable wait state colors for this example. A full table of all wait states is available here. 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 more ( ) 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. Let's address this in Step 4.

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 is fully tracked. Innoslate includes relationship matrices to represent traceability relationships between entities in tabular view.

To open the requirements matrix:

  1. From 'Documents View,' open the Requirements Document: "SAE Level-5 Automation Requirements."

  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 'A Metafunction' as the 'Root Entity.'

  6. Select 'satisfied by' as the 'Relationship Type.'

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

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.

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.'

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.

Click the 'Save' button to record the change.

Requirements Generation

After modeling the system, often an engineer will derive textual requirements from the models by hand. Innoslate includes an automatic facility that generates requirements documents in a standard format (as outlined in "The Engineering Design of Systems: Models and Methods").

To run the requirements generator at the first level:

  1. Click the 'Diagrams' button on the top navigation bar to open 'Diagrams View.'
  2. Open the 'Action Diagram' named "Drive Vehicle."
  3. Click 'Settings' in the toolbar.
  4. Select the 'Generate Requirements' menu item.
  5. This has generated a requirements document from the model. These requirements are further decomposed and refined through requirements view. To complete our derived requirements documents, we will follow the same steps for the decomposition Action Diagrams: "Calculate Waypoint and Obstacles" and "Monitor Environment."

    * Note this will create three separate requirements documents. To switch between the requirements documents, click the 'Documents' button on the top navigation bar to open 'Documents View' and find/open your desired document.

    Diagrams are automatically derived from this process. For example, to access a 'Requirement Diagram:'

    1. In 'Documents View,' select the Requirement Document: "Autonomous Vehicle Requirements."
    2. Click on "1.1 Input Requirements."
    3. Click the 'Open' drop-down menu in the toolbar.
    4. Select 'Requirement Document' under "SysML Diagrams."

    This displays a hierarchy of requirements and their direct relationship to other entities in the model. To perform an Impact Analysis on a single requirement:

    1. Click to select "1.1.1 Accept Destination Location."
    2. Click the 'Open' drop-down menu in the toolbar.
    3. Select 'Spider Diagram' under "LML Diagrams."

    The 'Spider Diagram' displays all relationships to an entity up to two levels deep by default. These relationships are filtered in the left sidebar. Click 'Settings' in the toolbar and select the 'Number of Levels' menu item to observe additional levels.

    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, as seen earlier in Step 3. '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.

    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

    You have now completed your first models using Innoslate. To learn more about what you can do with Innoslate, continue to the Verification and Validation guide.

Model-Based Systems Engineering

Last modified on September 13th, 2018. 


Welcome to the Model-Based Systems Engineering guide!

This guide is meant to demonstrate 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.

Photo: Mercedes Benz

At its core, Innoslate is a full model-based systems engineering tool. According 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 ‘+ New 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 ‘Next’ button.
  7. 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, this is expressed with the ‘Parallel’ construct. This allows each ‘Asset’ to operate independently communicating via ‘Input/Output’ constructs. 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.

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

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

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

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

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.

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

  3. Click anywhere in the white space to deselect.

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

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

  6. Click anywhere in the white space to deselect.

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

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

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 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.”

  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.

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

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

  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.

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

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

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

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.

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 for the “Monitor Environment” action. Open the ‘Decomposition Diagram’ for “Monitor Environment.” Use the left sidebar to drag constructs to build the diagram below:

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:

  1. Click on the ‘Open’ drop-down.
  2. Select the ‘Parent Diagram’ menu item.

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:

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’ in the toolbar.
  4. Select the ‘Auto Number’ menu item.
  5. Type in “A” for the prefix.
  6. Click the ‘Run’ button.

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.

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.’

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

  3. Click ‘Settings’ in the toolbar.

  4. Select the ‘Generate Asset Diagram’ menu item.

  5. This has generated our first Asset Diagram.

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 follow the same Asset Diagram Generation for the decomposition of the following 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.

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 Autonumber 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.

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.

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 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 tutorial 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 are defaulted 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.

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

The table above shows applicable wait state colors for this example. A full table of all wait states is available here. 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 more ( ) 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. Let’s address this in Step 4.

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 is fully tracked. Innoslate includes relationship matrices to represent traceability relationships between entities in tabular view.

To open the requirements matrix:

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

  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 ‘A Metafunction’ as the ‘Root Entity.’

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

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

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.

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.’

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.

Click the ‘Save’ button to record the change.

Requirements Generation

After modeling the system, often an engineer will derive textual requirements from the models by hand. Innoslate includes an automatic facility that generates requirements documents in a standard format (as outlined in “The Engineering Design of Systems: Models and Methods“).

To run the requirements generator at the first level:

  1. Click the ‘Diagrams’ button on the top navigation bar to open ‘Diagrams View.’
  2. Open the ‘Action Diagram’ named “Drive Vehicle.”
  3. Click ‘Settings’ in the toolbar.
  4. Select the ‘Generate Requirements’ menu item.
  5. This has generated a requirements document from the model. These requirements are further decomposed and refined through requirements view. To complete our derived requirements documents, we will follow the same steps for the decomposition Action Diagrams: “Calculate Waypoint and Obstacles” and “Monitor Environment.”

    * Note this will create three separate requirements documents. To switch between the requirements documents, click the ‘Documents’ button on the top navigation bar to open ‘Documents View’ and find/open your desired document.

    Diagrams are automatically derived from this process. For example, to access a ‘Requirement Diagram:’

    1. In ‘Documents View,’ select the Requirement Document: “Autonomous Vehicle Requirements.”
    2. Click on “1.1 Input Requirements.”
    3. Click the ‘Open’ drop-down menu in the toolbar.
    4. Select ‘Requirement Document’ under “SysML Diagrams.”

    This displays a hierarchy of requirements and their direct relationship to other entities in the model. To perform an Impact Analysis on a single requirement:

    1. Click to select “1.1.1 Accept Destination Location.”
    2. Click the ‘Open’ drop-down menu in the toolbar.
    3. Select ‘Spider Diagram’ under “LML Diagrams.”

    The ‘Spider Diagram’ displays all relationships to an entity up to two levels deep by default. These relationships are filtered in the left sidebar. Click ‘Settings’ in the toolbar and select the ‘Number of Levels’ menu item to observe additional levels.

    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, as seen earlier in Step 3. ‘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.

    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

    You have now completed your first models using Innoslate. To learn more about what you can do with Innoslate, continue to the Verification and Validation guide.