Model-Based Systems Engineering

Last modified on February 17th, 2017.


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.

Mercedes Benz Autonomous Concept CarPhoto: Mercedes Benz

At it's 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 the 'Action Diagram' menu item.
  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.
Add Parallel Construct

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 you 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.
  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.
Add Action Constructs

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, follow the steps below:

  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” section 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” section when the receiving ‘Action’ highlights green.
  6. Name the second trigger "Environmental Conditions".
Add Input/Output Constructs
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.

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 dropping from the left sidebar (as shown below in the "Drive Vehicle" diagram).

Create Decomposition Diagram

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?", which 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

The completed first level of the "Autonomous Vehicle" behavior diagram should appear similar to the picture below:

Autonomous Vehicle Action 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.

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:

Monitor Environment Action Diagram

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.

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:

Calculate Waypoint and Obstacles Action Diagram

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 Autonumber the entire hierarchy. To autonumber:

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

Auto Number Diagram

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.

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.

Let's proceed and create our physical models.

 

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. Now, 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 (the wrench icon)
  4. Select the 'Generate Asset Diagram' menu item.
Generate Asset Diagram

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.

Physical Hierarchy Chart

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

Let's Autonumber the entire hierarchy. To autonumber:

  1. From the hierarchy chart, click settings in the toolbar (the wrench icon)
  2. Select the 'Auto Number' menu item.
  3. Type in "P" for the prefix.
  4. Click on the 'Run' button.

Auto Numbered Hierarchy Chart

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.

Block Definition Diagram

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.

Discrete Event Simulator
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 on the upper right side.

 

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. Click the 'Requirements' button in the top navigation bar.
  2. In the toolbar, click on the 'Open' drop-down.
  3. Under the "Matrices" section, select the 'Hierarchical Comparison' menu item.
  4. In the left sidebar, under 'Target Entity', select "A Metafunction".
  5. In the left sidebar, under 'Target Relationship', select "satisfied by".
  6. Click the 'Generate' button.
Discrete Event Simulator

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.

Satisfied By Hierarchical Comparison Matrix

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. Click the 'Diagrams' button on the top navigation bar.
  2. Open the 'Action Diagram' named "Metafunction".
  3. Click on the 'Open' drop-down.
  4. Under the "Matrices" section, select the 'Hierarchical Comparison' menu item.
  5. In the left sidebar, under 'Target Entity', select "P Metafunction (Physical Context)".
  6. In the left sidebar, under 'Target Relationship', select "performed by".
  7. Click on the 'Generate' button.

Hierarchical Comparison Matrix

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 (as seen above). Click the 'Save' button to record the change.

Let's learn how to derive new requirements from the model.

 

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 (the wrench icon).
  4. Select the 'Generate Functional Requirements' menu item.

Generated Requirements

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. Click the name of the requirements and select the desired document to switch the documents in the toolbar.

Switch Documents Drop-down

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

  1. Click the 'Requirements' button in the top navigation bar.
  2. Select "Autonomous Vehicle Requirements" from the drop-down menu.
  3. Click on "1.1 Input Requirements" .
  4. In the toolbar, click on the 'Open' drop-down.
  5. Under the "SysML Diagrams" section,  select the 'Requirement Diagram' menu item.

Requirement Diagram

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. In the toolbar, click on the 'Open' drop-down.
  3. Under the "LML Diagrams" section, select the 'Spider Diagram' menu item

Spider Diagram

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 on the Settings   (the wrench icon) button and select the 'Number of Levels' menu item to observe additional levels.

How do we ensure our traceability is accurate? Let's continue to Step 6 to find out.

 

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 'Requirements 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 ran 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 Analysis' button.

Intelligence Tool

As you can see, Intelligence has analyzed our models using heuristics and machine learning language models. There are six sections assessed: "Global", "Actions", "Assets", "Conduits", "Input/Outputs", and "Requirements". You will notice that the model we created receives a 100% 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-left to modify which checks are performed and their criticality (warning/error).

This completes our first models in Innoslate. To continue learning more about Innoslate see the V&V guide.

Model-Based Systems Engineering

Last modified on February 17th, 2017. 


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.

Mercedes Benz Autonomous Concept CarPhoto: Mercedes Benz

At it’s 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 the ‘Action Diagram’ menu item.
  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.
Add Parallel Construct

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 you 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.
  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.
Add Action Constructs

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, follow the steps below:

  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” section 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” section when the receiving ‘Action’ highlights green.
  6. Name the second trigger “Environmental Conditions”.
Add Input/Output Constructs
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.

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 dropping from the left sidebar (as shown below in the “Drive Vehicle” diagram).

Create Decomposition Diagram

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?”, which 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

The completed first level of the “Autonomous Vehicle” behavior diagram should appear similar to the picture below:

Autonomous Vehicle Action 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.

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:

Monitor Environment Action Diagram

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.

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:

Calculate Waypoint and Obstacles Action Diagram

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 Autonumber the entire hierarchy. To autonumber:

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

Auto Number Diagram

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.

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.

Let’s proceed and create our physical models.

 

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. Now, 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 (the wrench icon)
  4. Select the ‘Generate Asset Diagram’ menu item.
Generate Asset Diagram

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.

Physical Hierarchy Chart

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

Let’s Autonumber the entire hierarchy. To autonumber:

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

Auto Numbered Hierarchy Chart

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.

Block Definition Diagram

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.

Discrete Event Simulator
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 on the upper right side.

 

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. Click the ‘Requirements’ button in the top navigation bar.
  2. In the toolbar, click on the ‘Open’ drop-down.
  3. Under the “Matrices” section, select the ‘Hierarchical Comparison’ menu item.
  4. In the left sidebar, under ‘Target Entity’, select “A Metafunction”.
  5. In the left sidebar, under ‘Target Relationship’, select “satisfied by”.
  6. Click the ‘Generate’ button.
Discrete Event Simulator

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.

Satisfied By Hierarchical Comparison Matrix

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. Click the ‘Diagrams’ button on the top navigation bar.
  2. Open the ‘Action Diagram’ named “Metafunction”.
  3. Click on the ‘Open’ drop-down.
  4. Under the “Matrices” section, select the ‘Hierarchical Comparison’ menu item.
  5. In the left sidebar, under ‘Target Entity’, select “P Metafunction (Physical Context)”.
  6. In the left sidebar, under ‘Target Relationship’, select “performed by”.
  7. Click on the ‘Generate’ button.

Hierarchical Comparison Matrix

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 (as seen above). Click the ‘Save’ button to record the change.

Let’s learn how to derive new requirements from the model.

 

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 (the wrench icon).
  4. Select the ‘Generate Functional Requirements’ menu item.

Generated Requirements

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. Click the name of the requirements and select the desired document to switch the documents in the toolbar.

Switch Documents Drop-down

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

  1. Click the ‘Requirements’ button in the top navigation bar.
  2. Select “Autonomous Vehicle Requirements” from the drop-down menu.
  3. Click on “1.1 Input Requirements” .
  4. In the toolbar, click on the ‘Open’ drop-down.
  5. Under the “SysML Diagrams” section,  select the ‘Requirement Diagram’ menu item.

Requirement Diagram

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. In the toolbar, click on the ‘Open’ drop-down.
  3. Under the “LML Diagrams” section, select the ‘Spider Diagram’ menu item

Spider Diagram

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 on the Settings   (the wrench icon) button and select the ‘Number of Levels’ menu item to observe additional levels.

How do we ensure our traceability is accurate? Let’s continue to Step 6 to find out.

 

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 ‘Requirements 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 ran 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 Analysis’ button.

Intelligence Tool

As you can see, Intelligence has analyzed our models using heuristics and machine learning language models. There are six sections assessed: “Global”, “Actions”, “Assets”, “Conduits”, “Input/Outputs”, and “Requirements”. You will notice that the model we created receives a 100% 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-left to modify which checks are performed and their criticality (warning/error).

This completes our first models in Innoslate. To continue learning more about Innoslate see the V&V guide.