The engineers who develop block diagrams sometimes view blocks as transforming continuous time-varying input signals to continuous time-varying output signals, at least at some abstract conceptual level. Block diagrams are useful in applications that require this sort of functionality to be implemented on digital computers. A software implementation of a block diagram operates on sequences of data samples, where each sample is supposed to represent the value of a signal at a particular point in time. This leads to some subtle but important variants in the block diagram family of architectural styles. Two important variants are data flow block diagrams and sampled data block diagrams.
In a data flow block diagram, a block is considered "enabled" when a data sample has arrived for each of its inputs. The block can then consume its input samples and produce its output data samples. In some data flow block diagram styles data samples are allowed to queue up on inputs, but in some styles only a single data sample will be held while waiting for samples to arrive at other inputs. When implementing a data flow block diagram, sometimes this behavior is dynamically implemented by an underlying executive of some sort that keeps track of which inputs have data samples and invokes blocks as they become enabled. In other cases it is possible to determine at implementation-time an order for executing blocks that will insure all the inputs for a block have been produced by the time that block is executed.
In a sampled data block diagram, each block is periodically executed at some rate, e.g. once every 100 milliseconds. Different blocks often have different periods specified. Each execution can be thought of as periodically inputting and outputting samples of some conceptual continuous underlying signal. Since executing the code for a block takes some time, there is always a delay between the time at which the inputs are sampled and the time at which the output sample is made available. Controlling how these delays cascade is important in an implementation. Where there are cycles in the block diagram (feed-back loops), some connections must be "broken" and some blocks must use as their inputs samples that were produced during earlier executions. This introduces a delay in a feed-back loop, and typically there are restrictions on which particular signals can have a delay introduced and which cannot. A sampled data block diagram style must codify these delay constraints, and the method used to transform a sampled data block diagram into an implementation must meet these constraints.
There are a large number of design analysis techniques that can be applied to block diagrams that are particular to the engineering discipline making use of those diagrams (e.g. frequency response, pole location). Liveness and safety analysis might be useful for data flow block diagrams whose firing order is determined dynamically at run-time (e.g. checking to make sure two blocks do not get stuck awaiting output from each other).
The coding guidelines for block diagrams must address the issue of insuring that blocks are executed in an acceptable order. The mechanisms used to pass data samples between blocks must be specified. In multi-rate sampled data diagrams, the mechanism used to pass data samples between blocks executing at the same rate may be different from that used to pass data samples between blocks executing at different rates. Finally, guidelines are needed for handling "state" variables as that term is used by control engineers. Each individual instance or invocation of a type of block may need its own copy of a set of persistent state variables. There are specific rules that govern when a state variable may be updated, where state update may sometimes be done externally to the actual code that implements a particular block.
It is often the case that a core set of signal types and primitive blocks can be identified, and a library of code modules can be developed for these types and blocks. Applications can then primarily be built by selecting and assembling primitive code blocks from the library. The coding guidelines may also explain how primitive code blocks can be parameterized and configured.
The ControlH architecture specification language supports a block diagram style.
A block diagram style was used to develop a reusable software architecture for flight controllers that has been applied to a number of aerospace vehicles, including F-16 and F-18 aircraft and the DC-X prototype space launch vehicle.