4.1 - Functional Analysis
Complex systems by their nature are too complicated to design all at once, or by one person. Functional analysis is a process to divide a system into smaller parts, called functional elements, which describe what we want each part to do. We do not include the how of the design or solution yet. At this point we don't want to limit the design choices, because it might leave out the best answer. In later steps we will identify alternatives, optimize them, and select the best ones to make up the complete system. The name Function comes from mathematical functions, which act on an input value and produce a different output value. Similarly, in the Systems Engineering method, functions transform a set of inputs to a set of outputs.
There are different ways to record and display the functions which make up a system design. A Functional Flow Block Diagram is a popular graphical method. It uses a rectangular box to represent each function (Figure 4.1-1). Arrows represent flows or states of any type to and from the function. The flows connect to other functions or to outside the system. By convention, inputs are shown on the left, and outputs are shown on the right. The function box itself transforms the inputs to the outputs. Mechanisms are the entities which perform the function, but which are not themselves transformed. They are normally shown by arrows at the bottom, and typically represent use of a device. Controls are inputs which command, limit, or direct the operation of the function, and are normally shown at the top. Function names are typically made up from an action verb and noun, like "chop wood", which summarizes the task, and are shown inside the box. A function number is usually included to uniquely identify it, since similar names may end up being used in different places in a project. The most common numbering method takes the number of a parent function, and adds a digit to that number for each sub-function. Thus 2.2 has sub-functions 2.2.1, 2.2.2, etc. This allows tracing where a function is in the overall system simply by looking at its number.
The diagrams can be sequential, such as showing the steps of a production process; parallel, where different activities can happen at the same time; or looping, where there is feedback or iteration. More generally, the output of any function can lead to an input to any other function.
Top Level Diagram - In designing a factory, we are generally concerned with the production function. The placement of the system boundary for design and analysis purposes, however, can be different. Figure 4.1-2 shows a top-level block diagram for a complete location that our example Personal Factory serves. It includes a Production function, where most of the manufacturing takes place, a Habitation function, which are the homes and other buildings the owners live and work in, and a Transport function that moves physical items from place to place. In this case the factory delivers products to the same people who own and operate the factory, and may take wastes from them to be reprocessed. This is a sufficiently integrated situation that it makes sense to place a system boundary around all of the relevant functions. A factory which only produces products for sale does not have as strong a link to the end users, so in that case you can exclude anything outside the production function. The inputs and outputs from outside the selected system boundary are shown to the left and right of the diagram, and are broken down by type. Logically this diagram is identical to one at an even higher level, where all the inputs are represented as a single flow arrow, like in Figure 4.1-1, and the entire project is reduced to a single box with no internal details.
Flow Arrows - Flow arrows represent a state of an item or the movement of any kind of resource between functions. A raw casting from a metal foundry process and a machined part made from that casting are different states of a part being made. The casting would be an input and the machined part would be an output from a "Machine Parts" function that converts one to the other. Resources are things like energy and human labor which get used up as inputs, or created as outputs from functions. Flows may divide and merge between endpoints, but it is understood that mathematically both sides of the junction are equal. Otherwise you have spontaneous creation from nothing, or an unaccounted for source or disposition of some item. When flows on lower level diagrams show more detailed components, the combination should therefore be identical to a single flow that represents them on a higher level diagram. Flows, like functions, are given names and unique numbers to identify them. Both the flows and the function boxes will be further broken down into more detail as the design progresses.
Representing Functional Relationships - Figure 4.1-2 does not show all the interior flows connecting the function boxes for two reasons. The first is that we have not defined them at this point of the design. The second is it would make the diagram unreadable because there would be too many lines. Higher level diagrams tend to have more flows because they are showing more of a system at once. One way to handle the complexity is to use large drawings with multiple sheets. It is understood that each sheet only shows a subset of the flows to the same functions, to make it more readable. Another way to deal with complexity is to track the flows in spreadsheets and data tables, which can have as many lines as needed, one for each flow. Whatever method is used to display and track the functions and flows, they represent the same relationships between parts of a system. Block diagrams are just a convenient visual starting point to understand and analyze a system.
Representing Time - Within a given diagram, a flow connecting two functions indicates the second function logically follows the first one. As a minimum it means the second function cannot start any earlier than the start of the first one. They can, however, start at the same time. For example, a portable generator and whatever equipment it powers may be started together, but the equipment can't be started before the generator, because one of it's necessary inputs, namely electricity, is not available until the generator is working. Sometimes a series of function boxes represents a strict time order, where one has to be completed before the next can start, but this is only necessary when flows include states of the same item. For example, for an airplane, the function "Take Off from Runway" has to be completed before "Fly to Destination" and "Land at Destination", because the inputs and outputs are the same airplane, in the states of "Airplane at Departure Airport", "Airplane in Flight Leaving Departure City", and so forth. When there is a loop in flow diagrams, such as a water treatment unit that takes dirty water from homes and sends back clean water, the start-up sequence should be accounted for in the design. In this case, since there is no dirty water to process at first, a starting supply of clean water must be fed into the loop at some point.
A different representation of time is required when the system as a whole evolves from one stage to another, and new functional elements and flows are added. One way to do this is to prepare different versions of the same diagrams for each stage, and marking the new items that were not present in the previous stage. This can be by highlighting or coloring the new items. More complex system representations, like simulations, can have the new items appear at the appointed time.
Beyond Flow Diagrams - A function or flow name used in a diagram is not enough to describe exactly what the item is supposed to be. It is merely a label for a part of the design. As additional details are worked out, they can be attached as notes to the diagram, or in a variety of separate documents or files. Any amount of additional data about the function can be linked to it by using the identifying name and function number. The unique tracking label helps organize all the data for a project in a consistent system.
The purpose of functional breakdown is to divide a complex system into smaller and simpler parts, so that eventually they can be individually designed. One way to divide parts is along the time axis. A large project can be divided into phases that are sequential in time, where each phase adds new capabilities or hardware. A common example is developing real estate, where each phase develops different parts of a property. Technical projects are often divided into several design phases, production, testing, and delivery, where milestones for a given phase must be completed before going on to the next phase. Within a part of a system, some tasks must happen in a sequence or process in time order. Thus each step in the sequence can be identified as a function. Another way to divide functions up is when they do different things at the same time, but have inputs and outputs that connect them. Thus the control electronics for a robot arm may send power to the motors, and read joint angles from a sensor. The electronics is different enough from the motor and joint bearings that they can sensibly be treated as different functions, with different design issues to solve.
There is no single answer for how best to divide up a system. Often different alternative designs will require different functional breakdowns. The designer should use good judgement to break up a system into elements that have internal relatedness, and that follow a logical flow from one to the next. A function should contribute to meeting some part of the overall system requirements, or else one can question the need for that function. In our Personal Factory example, the three top functions serve different purposes: changing things (Production), moving things (Transport), and using things (Habitation). The end users, who are the reason the Personal Factory is built, are included in the system design because they are strongly connected. They are expected to be the human operators of the system, their waste products are intended to be recycled, and the homes and commercial building may be physically connected to power sources and other utilities from the Production function. An Industrial Factory, which is purely designed to make items for sale, has less interaction between production and the customers. In that case you can reasonably draw the system boundary around only the production portion, and leave the end users and delivery as external flows.
The functional analysis, like all parts of a design, is not done once and then finished. It will evolve and be revised as the design progresses. Diagrams or other records represent the current state of the design at some point in time. Version numbers and dates help identify the most current state, and change histories explain why it was changed. In a small project or early stage of a larger one such formal tracking is not as necessary. In a large project, where each person can only know the part they are working on, formal tracking helps keep the overall work coordinated, and is much more important.
Functions do not have a one-to-one relationship with hardware. A given hardware item may perform multiple tasks, and a given function may need multiple hardware items in different places to be completed. Rather, functions are mental abstractions that represent pieces of the intended purpose the system is built for. When carried to a sufficiently detailed level, the pieces are then simple enough to design individually.
We will use for an example the Provide Production Capacity function for the Personal Factory.
Function and Flow Numbers - A name and a number are what identifies a particular function or flow within a system design. The numbers are intended to be unique, and are made of a series of components, each containing numbers and letters, which are separated by periods. The components represent hierarchical levels in the system design. Our example uses a longer function number than is needed at the moment, to allow for future design work without having to renumber things later. Renumbering is both extra work, and can lead to confusion. Thus a little thought and planning to reserve the numbering space is a good idea at the start of the project. In the five component number "F.22.214.171.124" for the Provide Production Capacity function, the F indicates it is a function. External Flows, Controls, Inputs, Mechanisms, and Outputs use E, C, I, M, and O as their first component, respectively. The 2nd component indicates the project level phase, with 1 for the Technology Development phase before the first full factory unit, and 2 for first generation units at actual locations. Higher numbers would be used for later generation designs. The third component indicates the design environment, since the design will change according to the outside conditions. Here 1 represents a temperate operating environment. More difficult or extreme environments would get higher numbers. The fourth digit is a location serial number, which is 1 because this is the first project location to be designed. Other locations would get sequential numbers. Thus F.2.1.1 identifies our first full Personal Factory project location. The location will expand in a series of construction phases. When we consider these phases, we will attach letters to the location serial number, thus phase 1A, 1B, etc. At the moment, we are considering the functions in general, without regard for construction timing, so the 4th component is just a 1. The final .1 represents the Provide Production Capacity function for the location.
Next Level Function Identification - Figure 4.1-3 shows the next level of sub-functions beneath this main function. They are laid out on a diagonal for convenience in drawing flow arrows between any two of them. The particular set of sub-functions is decided by the designer, so other versions are possible. We think the set shown here is logical, as it divides production into different types of tasks which are internally related in themselves, and distinct from each other. The placement and numbering order of the function boxes can be whatever is clear and logical. In this case it is approximately in the order the tasks are performed. Time ordering allows and output arrow from one task to connect to the input side of the next in left to right order. Function blocks may not strictly be in time sequence. In fact, any cycle loops, such as when waste products are recycled to an earlier stage, means they cannot be put in time order. Therefore the layout on the diagram should be whatever makes the most sense in the circumstances. Growing organics is placed last on this particular diagram because it is fundamentally different than the industrial manufacturing steps. In terms of time sequence it is more in parallel with Extract Materials.
Output Matrix - Figure 4.1-4 shows another way to display the flows between functions besides arrows. This method works for situations where too many arrows would be confusing. The functions themselves are placed on the diagonal of a grid. Any grid rectangles above the diagonal indicate a flow from the function in the same row on the left to the function in the same column below. Rectangles below the diagonal indicate a reverse flow from the function in the same row on the right back to the function in the same column above. The grid method is not as good at showing outputs that return to the same function as they start, or the relationship of control and mechanism inputs. It is helpful as an organized way to consider the relationships among the functions. Each box in the grid can be examined in turn, with the question "Is there anything that goes in this direction between these two functions? If not, that box can be marked with an "X". If there is, the flows can be entered in that box, and worked out in more detail later.
Function Descriptions - A few words and a number labeling a function box or flow arrow are not enough to completely specify what it does or contains. The same combination of number and name are therefore used consistently throughout a project to connect all the related information about that function. A description expands on the label, and can be placed as a note on the functional diagram, or in a separate document. The description can then be as long as necessary. Mathematical models, design drawings for different options, or any other data that relate to the function are marked with the same label. Section 5.2 gives descriptions for our example functions.