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.
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
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.
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?
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.
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.
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
The advantage of an Action Diagram is that there is a clear starting point for what is the first action.
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: http://www.lifecyclemodeling.org/
With the Action Diagram loops are shown with a loop action.
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: https://www.innoslate.com/contact-us/
Topics: How to Use Innoslate Series