eFFBDs show the interaction between system functions by distributing them along a timeline. A timeline consists of a set of directed arrows, connecting functions and nodes to depict a processing sequence. The timeline effectively constitutes a flow of control. No data flows along the timeline, it simply indicates the order in which functions are processed. The timeline may branch into two or more parts at a node, described below, which must subsequently converge. An eFFBD must have a single start point for its timeline and a single end point.
Individual parts of the timeline may be named or unnamed. Named arrows are used to label alternate time line branches, either to represent alternate exit conditions from a function (such as success or failure), or in relation to the action of nodes in the control flow.
Functions represent units of work. A function becomes executable when it is reached in the timeline. It will begin to execute immediately unless it receives triggering input data, when it waits for this input data to be available. A function can consume and/or produce data to/from data items. A function can have one or more exit timelines. If it has more than one, then the alternative exits represent different exit conditions from the work done by the function, such as an OK, Warning or Error exit condition. Other functions can be placed on these exit timelines, to perform corrective or exception handling behaviour. All functions are described in function specifications and can all be decomposed into lower-level diagrams.
There are three types of function:
Nodes are used to split the timeline into two or more branches. The processing along each branch is sequential unless that branch also contains nodes which instigate concurrent or other processing.
Nodes do not have a definition: their sole purpose is to define the manner in which eFFBD functions are connected, and their behaviour over time. Some of the nodes will, however, have a label, used either to specify conditional processing, or to link associated nodes or eFFBDs together.
The nodes are intended to be used to create sequential, conditional, concurrent, replicative and iterative processing constructs.
As DFDs and eFFBDs both show functions and data, there are inevitably similarities between them. DFDs are, by definition, inherently concurrent in that all functions without prompts (control flows such as E/D and T or TRIGGER) are concurrently executable. The order in which they execute is determined by:
However, the intrinsic benefit of the eFFBD notation is the way that sequence, iteration, and concurrency are shown on the diagram by the arrangement of functions along a (possibly complex) timeline.
eFFBDs do not have an explicit concept of state as provided by the STD, nor do they provide the same degree of detail in the logic for transitioning between states. The DFD and STD combination therefore offers more expressive power in this respect.
Cradle provides the eFFBD in both Essential and Implementation Domains from two primary perspectives:
Where DFDs model the system as it is, eFFBDs model what the system does.
eFFBDs are hierarchical. Their connectivity is:
Within a hierarchy of DFDs and possibly extended Function Block Diagrams (FFBDs), eFFBDs may be used to provide detailed information on order-critical parts of the system. If much of the system relies on time-sequenced events, the complete diagram hierarchy could be made up of eFFBDs. In other cases, a particular sub-system, such as an electronic component, may be the only time order-critical section.
There is considerable flexibility in the choice of the overall structure of a diagram hierarchy for a system. The structure should be chosen based on the system aspects to be described.
They are numbered as are eFFBD symbols that can be expanded, e.g. objects on eFFBD 1 will have numbers 1.1, 1.2, 1.3 etc., which are the numbers of the eFFBDs into which they may be expanded.
An example eFFBD is:
The symbols available in an eFFBD are:
Functions can have multiple exits for alternate conditions. Shared functions are identified by the name, not the number. They have a common definition and a common child diagram.
Trigger data links can be named, when they can link functions together, or link functions to the environment. This reduces the need for discrete items, reducing the diagrams’ complexity.