Tools for Defining and Verifying Functional Interfaces

6.5.3 Define and Verify Functional Interfaces (Internal/External)

Logical interfaces with external elements are defined in the context diagram and the FFBDs and internal interfaces are defined in the FFBDs. Both types of interfaces must be analyzed to verify that all interfaces are properly located and defined. Examine each external interface and verify that the information coming from or going to the interface matches the information being handled by the parent function in the chain of lower level child functions. Similarly examine each function and verify that all information coming from or going to the function is accounted for; that no function has an output that doesn’t go to either another function or to an external logical interface; and that no function requires information that is not coming to the function from another function or external interface. This task is made easier if the links in a process-oriented FFBD are labeled. An example of a simple process-oriented FFBD of a toaster with internal and external interfaces is shown in Figure 6-26.

(Apologies to experienced designers of toasters for any mistakes by the authors who have limited domain knowledge of toaster design. We use the example of a toaster because it is simple enough that diagrams and models fit on a page and everyone has  some idea of what a toaster does and how it might work. To those “virtuous and pure” engineers whose response is “toasters don’t apply to my work so these examples are useless to me” we remind you that the authors have used these same methods on systems costing hundreds of millions of dollars to develop. Learn the methodologies illustrated by these examples and don’t be put off by errors or incompleteness in these examples or the fact that your systems are much more complex.)

Figure 6-26 An example of a FFBD for a toaster showing the internal and external interfaces for each function of the Operational mode.

A “from” “to” matrix of functions in a particular mode is an alternate tool for defining interfaces for functions. An example is shown in Figure 6-27 for a toaster in its operational mode.

Figure 6-27 A Matrix of Functions to Functions is an alternate tool for defining internal and external interfaces among functions.

N-Squared diagrams are useful tools for analyzing interfaces for systems with functions having many internal interfaces. This tool also provides verification of the grouping and sequencing of lower level functions. It’s much easier to detect sequencing problems in an N-Squared diagram than on a FFBD. An example of an N-Squared diagram used for defining internal and external interfaces is shown in Figure 6-28. The advantages of the N-Squared diagram aren’t apparent in this simple case but imagine if the functions were more randomly sequenced along the diagonal. Then there would be arrows on the left of the diagonal indicating poor sequencing.

It is good practice to develop two different tools for defining internal and external interfaces; for example a FFBD and an N-Squared diagram. The two are then compared to verify that all interfaces are defined, grouped and sequenced correctly and consistent with the definitions of functions in the data dictionary. The small amount of time it takes to verify functional interfaces via two different tools is sound risk mitigation against making a mistake that isn’t discovered until system or subsystem testing when correcting the error is very costly.

Figure 6-28 An N-Squared diagram is an excellent tool for defining, grouping and sequencing interfaces.

Functional Flow Block Diagrams

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.

  Figure 6-23 An example of a FFBD as an object-oriented model of two of the functions of a digital camera with named functions as links and named objects as nodes.

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.

6.4 Functional Analysis and Allocation

Figure 6-5, the list of 15 tasks in the post of December 29 titled Requirements Analysis, shows that Functional Analysis and Allocation is necessary to accomplish subtask 10, Define Functional Requirements. Functional analysis decomposes each of the high level functions of a system identified in requirements analysis into sets of lower level functions. The performance requirements and any constraints associated with the high level functions are then allocated to these lower level functions. Thus the top level requirements are flowed down to lower levels requirements via functions. This decomposition and allocation process is repeated for each level of the system. The objective is to define the functional, performance and interface design requirements. The result is called the Functional architecture and the collection of documents and diagrams developed is the Functional view.  

A function is an action necessary to perform a task to fulfill a requirement. Functions have inputs and outputs and the actions are to transform the inputs to the outputs. Functions do not occupy volume, have mass, nor are they physically visible. Functions are defined by action verbs followed by nouns; for example, condition power or convert frequency. A complex system has a hierarchy of functions such that higher level functions can be decomposed into sets of lower level functions just a physical system can be decomposed into lower level physical elements. A higher level function is accomplished by performing a sequence of sub-functions. Criteria for defining functions include having simple interfaces, having a single function each, i.e. one verb and one noun; having independent operations and transparency, i.e. each does not need to know the internal conditions of the others. There are both explicit and implicit or derived functions. Explicit functions are those that are specified or decomposed from specified functions or performance requirements. Implicit or derived functions are those necessary to meet other specified capabilities or constraints.

Sometimes inexperienced engineers ask why they have to decompose and allocate  functions for design elements at the subsystem or lower levels; they believe once they know the top level function, the performance requirements and any constraints defined in the requirements analysis task they can design the hardware and software without formal functional analysis/allocation. One simple answer is that items like time budgets and software lines of code are not definable from hardware or software; they are defined from the decomposed functions and sequences of functions. This is because hardware or software does not have time dimensions, only the functions the hardware or software performs have time attributes. Similarly the question of how many lines of code or bits of memory only have meaning in terms of the functions the software code is executing. Other reasons become more apparent as we describe functional design and design synthesis.

A diagram, simplified from Figure 6-4 and shown in Figure 6-19, helps understand both the question asked by inexperienced engineers and the answer to their question.

Figure 6-19 Developing a hardware/software system design is iterative and has multiple paths.

Figure 6-19 illustrates that although the primary design path is ultimately from requirements to hardware/software design; primary because when the design is complete the resulting hardware/software design fulfills the requirements, other paths are necessary and iteration on these paths is necessary to achieve a balanced design. The paths between requirements and functional design and between functional design and hardware/software design are necessary to:

• Validate functional behavior
• Plan modeling and simulation
• Optimize physical partitioning
• Facilitate specification writing
• Facilitate failure analysis
• Facilitate cost analysis and design to cost efforts
• Facilitate concept selection
• Define software budgets and CON-OPS timelines.

Although the path from requirements analysis to design synthesis isn’t formally shown in Figure 6-4 it is used when a team elects to design a product around a particular part, such as a state of the art digital processor or new and novel signal processing integrated circuit chip. However, having preselected a part doesn’t negate the need to define the functions performed by the part and verify that the performance requirements and interfaces are satisfied.

6.4.1 Decompose to Lower-level Functions – Decomposition is accomplished by first arranging the top level functions in a logical sequence and then decomposing each top level function into the logical sequence of lower level functions necessary to accomplish the top level functions. Sometimes there is more than one “logical” sequence. It is important to examine the decomposed functions and group or partition them in groups that are related logically. This makes the task of allocating functions to physical elements easier and leads to a better design, as will be explained in a later section. When more than one grouping is logical then trade studies are needed. Although the intent is not to allocate functions to physical entities at this point functions should not be grouped together if they obviously belong to very different physical elements. The initial grouping should be revisited during the later task of allocating functions to physical elements and this process is described in more detail in a following section.

The DoD SEF has an excellent description of functional analysis/allocation and defines tools used to include Functional Flow Block Diagrams (FFBD), Time Line Analysis, and the Requirements Allocation Sheet. N-Squared diagrams may be used to define interfaces and their relationships. Spreadsheets are also useful tools and are used later in various matrices developed for validation and verification. A spreadsheet is the preferred tool for developing a functions dictionary containing the function number, the function name (verb plus noun) and the detailed definition of each function and its sub functions. The list of function numbers and names in the first two columns of the functions dictionary can be copied into new sheets for the matrices to be developed in the design synthesis task.

Spreadsheets do not lend themselves to identifying the internal and external interfaces as well as FFBDs so the FFBD is the preferred tool for decomposition. Time Line Analysis and the Requirements Allocation Sheet are well described in Supplement 5 of the DoD SEF and need no further discussion here. Similarly the Integration Definition for Function Modeling (IDEFO) is a process-oriented model for showing data flow, system control, and the functional flow of life cycle processes. It is also well described in Supplement 5 of the DoD SEF. The collection of documents, diagrams and models developed using all of the tools is the Functional view. The functional architecture is the FFBDs and time line analyzes that describe the system in terms of functions and performance parameters.

Although the FFBD is discussed in the DoD SEF there are some additional important aspects of this tool that are covered in the next posting.