How to Move Beyond the IDEF into a Simulatable Action Diagram

Published by on August 5, 2015 at 2:52 pm.

How to Use Innoslate for Intermediate Users

One of the biggest misconceptions in functional modeling is that an IDEF0 diagram is a functional flow model and thus can be functionally simulated. While the diagram does show functional components, I consider the IDEF0 diagram a data flow diagram and not a functional flow diagram.

Data Flow Diagrams vs Functional Flow Diagrams

Before I go any further, let me define the two key diagram types: data flow and functional flow. Both diagrams are very similar and in most cases show the same information (just in a slightly different format). What separates the two is functional flow diagrams have the addition of control flow logic on the diagram. This control flow explicitly adds sequencing of the function that is not found on data flow diagrams.

Innoslate has two data flow diagrams: IDEF0 and N2. Both of these diagrams show the functions and their inputs and outputs. Innoslate also has two functional flow diagrams: LML’s Action Diagram and SysML’s Activity Diagram. These diagrams are visually very similar, differing primarily in how each displays the diagram’s components (specified by the language LML or SysML).

Going forward I will be referring to the individual diagrams (IDEF0 and Action) vs the diagram type, however many of these points can be generalized to apply to similar diagrams.

Similarities Between IDEF0 and Action

As I mentioned above, the IDEF0 and Action diagram are very similar, both diagrams show functional components, inputs, enablers, outputs, and performers. Below is a table showing the components in the two diagrams.

Component IDEF0 Action

Called “functions” they are aligned diagonally across the diagram.


Called “Actions” they are aligned in sequence.


The Input arrow show a piece of data being passed into a function.

IO Optional

Input/Outputs are represented as a parallelogram and a dotted line arrow show the Action that receives it.
Input/Outputs that are only ever just inputs are shown in grey.


The control arrow show what is needed to start a given function.

IO Normal

Same as Inputs however if it is a trigger to an Action it is marked in green.

Output idef

The Output arrow show a piece of data that has be transformed from the function.


Same as Inputs however a dotted line arrow shows what Action generates the I/O.


The mechanism arrow show what system does that function.


The branch actor shows what Actions that a given asset performs.

Comparison of IDEF0 and Action Diagram’s components.

This leads us the the key defining factor between the two diagrams: control flow.

Control Flow’s Roll in Simulation

I will be using an excerpt from IDEF0 Modeling of the Engineering of a System from The Engineering Design of Systems: Models and Methods by Dennis Buede (2009) to illustrate this example. (You can import this from the dashboard under Function Analysis.)

The three big problems as to why an IDEF0 can not be functionally simulated are: no starting point, no order, and loop handling.

No Starting Point


A2 first

IDEF0 Diagram of “A2 – Perform Qualification & Integration Activities”


When you first look at this diagram your natural assumption is that “A21 – Conduct Early Validation” starts first. This assumption is based on that you are an English speaker and thus read top left to right and down. There is nothing preventing me from arranging the diagram so that “A21 – Conduct Early Validation” is at the end.


A2 second

IDEF0 Diagram of “A2 – Perform Qualification & Integration Activities” with children re-ordered.


Now the diagram reads that “A23 – Conduct Validation” starts first. There is some additional information on sequencing provided with the numbers, however relying on numbers to indicate sequencing is never a good idea.

In some cases where there is a single external control it is possible to identify the starting function. However, when three external controls are passed in, like in this example, trying to figure out which one goes first relies on the reader to understand the inputs, function, and outputs.

Lack of Order

Following along with no starting point is a lack of order. We often assume that you read an IDEF0 starting from the top and working down. Yet if we obey IDEF0 rules all that is required for a function to start is all of its controls. Take for example the IDEF0 diagram for “A11 – Perform System-Level Design Activities“. We can see that “A111“ starts first (because it is the only one with an external control), however what happens next?


IDEF0 Diagram of “A11 - Perform System-Level Design Activities” showing a lack of order.

IDEF0 Diagram of “A11 – Perform System-Level Design Activities” showing a lack of order.


Based on the read of the functions and data “A112” would start next. However, “A115” and “A116” both now have their controls and can start. So do “A112”, “A115”, and “A116” all start in parallel or should “A115” and “A116” wait to start later?

You can see how confusing this can become when you are trying to identify sequencing for functions based on the IDEF0 diagram.

Loop Handling

In an IDEF0 the concept of loops is handled by an output from one function being the input to another and then an output from the second function is an input to the first function.


IDEF loop

Simplification of how IDEF0 shows that two functions are in a loop.


This structure leads to many questions:

  • How many times does this loop?
  • Are they both happening at the same time?
  • Is this to show streaming of data between the functions?
  • Does every loop create other outputs or only on the first loop?

This abstraction of function loops can cause no end of confusion depending on how the audience reads that diagram.

The Equivalent Simulatable Action Diagram

Starting Point

The advantage of an Action Diagram is that there is a clear starting point for what is the first action.



An Action Diagram gives you a clear definition of what action starts first


You can easily see that the action immediately to the right of the Start is the first action to begin.

Control Flow Order

The Action Diagram uses the solid black lines to indicate the control flow of the actions. There are four common control structures used to represent control flow: series, parallel, or, and loop. The series one is the default control flow for most actions. A parallel control flow shows multiple paths that happen at the same time. An or is a decision action that has two or more possible outputs. A loop construct will loop everything within the branch as long as the conditions are met.

You can find out more information about control flow on the action diagram at the LML specification site:

Loop Handling

With the Action Diagram loops are shown with a loop action.



Example of a Loop in the Action Diagram


By showing loops this way it is clear what actions are repeated. Overcome the confusion over how many times a loop is repeated by changing the text on the control line to indicate the equation used for looping.


At the end of the day should you stop using the IDEF0 diagram? The answer is no. I still use both the IDEF0 and the Action Diagram depending on my audience’s preference. I tend to do most of my modeling and simulation in the Action Diagram and then translate it into a new IDEF0 diagram. This give me the ability to abstract and simplify the functions to focus on the data flow.

If you need help translating your IDEF0 diagram into an Action diagram feel free to reach out to via: