6.5.1.1 Functional Flow Block Diagrams - Graphical models are used to define and depict the sequence of functions making up a higher level function necessary to fulfill requirements. Functional Flow Block Diagrams (FFBD) can be process-oriented models that represent functions as nodes and objects as the connecting links. Nodes are typically labeled but links are typically unlabeled in process-oriented FFBDs. Figure 6-21 is a FFBD for two of the functions of a digital camera. Here only one external interface is identified, i.e. the interface with light from the scene.
Figure 6-21 A FFBD developed as a process-oriented model has named and numbered functions as nodes and objects as links.
Part of the task of functional design is to decompose high level functions into the lower level functions necessary to carry out the action implied by the high level function. For example, the function “image scene” can be decomposed as shown in the FFBD of Figure 6-22. In this example the objects linking the four lower level functions are also labeled. Note that nodes are numbered as well as named with the numbers indicating the level of the functions in the overall hierarchy of functions. The numbers are selected to provide traceability; e.g. sub functions decomposed from a function 1.1 with n sub functions are numbered 1.1.1 to 1.1.n.
Figure 6-22 The function Image Scene 1.1 from Figure 6-18 can be decomposed into four lower level functions.
Notice that functions 1.1.2 and 1.1.3 in Figure 6-22 could be interchanged in the sequence and still be a logical sequence. This is a simple example of having more than one logical sequence of lower level functions. The “best” sequence is determined by conducting design trade studies when these functions are allocated to physical elements. Note also that the functions 1.1.1 and 1.1.2 are easily grouped whereas 1.1.1 and 1.1.3 or 1.1.2 and 1.1.3 are not easily grouped. Therefore the sequence shown is likely to be the preferred sequence, at least until design trade studies are complete.
An alternative to the process-oriented model of a FFBD is an object-oriented model with the nodes and links reversed. An example of an object oriented model is shown in Figure 6-23.
The decision to develop process-oriented or object-oriented models depends upon the experience of the systems engineer and the details of the system being designed. A comparison of the two approaches resulting from an analysis of both approaches is shown in the table.
Table 6-1 Selecting an Object-Oriented or Process-Oriented model depends on the details of the specific system design. From the paper Cognitive Fit Applied to Systems Engineering Models by Larry Doyle and Michael Pennotti, Conference on Systems Engineering Research, 2004.
As with context or domain diagrams it is helpful to have pattern diagrams for all levels of FFBDs representing the class of systems that includes the system being designed. This saves considerable time compared to having to generate the FFBDs for all the levels of a new system under development. The objective is that the pattern diagrams contain all possible functions, sub functions and external and internal interfaces of the entire class of systems. Then the task becomes examining each top level function and interface to determine if it belongs to the new system. If a functions does not belong it is deleted along with all sub functions decomposed from the unneeded top level function. After deleting all unnecessary functions and interfaces from the top level and the sub functions and interfaces traceable to the deleted top level functions and interfaces it is necessary to examine the sub functions in each level to ensure that only necessary ones are kept. The system being designed may include a top level function from the pattern but may not include the entire set of sub functions decomposed from the top level function. It is also necessary to examine the partitioning and grouping of functions as the best choice is likely to be system design specific and not necessarily that captured in the pattern diagrams.
