Systems Engineering Io Trace Diagram

← Back to Page 1

Functional Analysis [edit | edit source]

Once requirements have been developed to a certain level (see page 1), the next step is Functional Analysis. Engineering analysis in general is the breaking down of an object, system, problem or issue into its basic elements, to get at its essential features and their relationships to each other, and to external elements. Analysis includes developing abstract models or performing calculations for the component elements of a system, to help arrive at a complete and optimized design. Functional analysis is a breakdown on the basis of what a system does, in terms of the functions it performs or a sequence of operations. This is before considering how it is performed. "How" is a design solution, which we don't want to choose prematurely. Instead we want to consider all the alternatives and optimizations, which we do in later steps of the process. Prior to selecting the best design, there may be multiple functional breakdowns, at least one for each system concept, and often alternate versions within a concept. The details of these steps and their interactions are recorded in the form of diagrams and models, which can then be used for calculations and assessments.

Concept Identification [edit | edit source]

Although we don't want to prematurely select a design solution, we do have to generate alternate concepts for how the system will function. At the level of the system as a whole it is difficult to define requirements and measures without an idea of how the system will work. Concept identification involves identifying alternate approaches to how it will operate, and synthesizing one or more system concepts for each potential approach. System level concepts give the general approach to design and function, without specifying exact values of parameters or what components will be used. For the Apollo program, for example, there was a choice of "Direct to the Moon" vs "Lunar Orbit Rendezvous" as mission concepts, with the latter being the one actually chosen. System concepts may include major variables such as type of propulsion (i.e. chemical or nuclear), service life (one or multiple missions), and supply concept (i.e. closed or open loop life support). At the least it covers what main tasks the system will perform, and how it will be operated and maintained. Once the system concepts are established, the process of analysis, optimization, and selection can begin to find the best version of each competing concept, and then compare and select among the concepts to carry to the next stage of development.

At lower levels of the design process, this step is repeated when there are multiple possible approaches. An example would be thermal protection for re-entry. An ablative heat shield burns off some material each time, so checking thickness and periodic replacement would be part of the necessary operations. A metallic heat shield might not burn off, but suffer cracking from heating and cooling cycles, and require different types of inspection. So when listing design alternatives, it is not just ablative vs metallic that is important, but also how that choice affects the total flow of operations in the system.

Functional Diagrams [edit | edit source]

Figure 1.5-4: Complex Functional Flow Diagram.

Functional Diagrams are prepared during analysis to illustrate the component operations a system performs and their inputs and outputs. They are a model of how a system operates in visual form. They start at the top level with external inputs and outputs which cross the system boundary, then are broken down into multiple levels of detail. They are often in a step by step time sequence, but can be more complex networks of operations with decision points and loops (Figure 1.5-4). For example, for an airplane, the main functions would be Load Passengers and Cargo, Taxi to Runway, Takeoff, Fly, Land, Taxi to Gate, and Unload Passengers and Cargo. Each of these main functions are further divided into smaller steps, then assigned to system elements to carry out. For example, the landing gear might be assigned multiple functions such as "absorb landing loads" and "provide steering for taxiing". Those then become requirements for detailed design and testing of that element.

Figure 1.5-5: Single Functional Diagram Box

Individual functions in a diagram transform inputs into outputs (Figure 1.5-5). The diagram typically shows functions as boxes and input/output flows as arrows connecting the boxes running from left to right. Flows can contain any sort of item, including information, matter, energy, labor, etc, or a combination thereof. They may divide and combine on a diagram, but the divided flow must sum to the contents of the undivided one. This derives from the physics concept of conservation laws, where matter and energy do not arise out of nothing. Similarly the flows within a system do not arise from or vanish into nothing, they must enter from outside or be converted by a functional task. By following the Conservation of Flows logic, then all the inputs and outputs of a system will be accounted for.

Control inputs regulate the operation of a function. By convention they are shown entering the top of a function box. Mechanisms perform the function, but are not transformed themselves, and are shown entering from the bottom. A mechanism example is a stamping press, which converts flat steel blanks to shaped stampings. Tne blanks and stampings are the inputs and outputs, respectively. For a complex system, the diagrams form a hierarchy, with one box on a given level expanded to a full diagram with multiple boxes at the next level down. Developing the levels of diagrams is a continuing task done incrementally, rather than all at once. The diagrams are a way to record and communicate the structure and operation of a system. They allow numerical calculations, for example noting the time required for each step to find the total operation time, or summing staff required for each function to get total staff needed to operate the system. Functional diagrams can also be converted to mathematical simulations of system operations, typically with computer software made for that purpose. Any amount of description or other information may be attached to items in a diagram, by means of a unique function or flow reference number. By convention, expanded lower level diagrams use the same number as the parent box (i.e. 9.2), with another period followed by another number (9.2.1, 9.2.2, etc.). This is not required, but it makes tracing the connections between diagrams easier.

Requirements Allocation [edit | edit source]

The third major step in the systems engineering process is Requirements Allocation. To ensure all the top level requirements will be met, they are assigned to one or more functions to implement. The assignment may be the whole requirement, or by dividing it into parts and then assigning the parts to separate functions. Allocated requirements are documented in lower level requirements documents or specifications that apply to parts of a project. Traceability is being able to trace the links between lower and higher level requirements and the logic of how they were generated. At the lowest level, a subset of the requirements are assigned to a particular hardware or software item, skilled staff, procedures, facilities, interfaces, services, or other elements of the final system. With a complex project, software tools become very useful for the requirements allocation and tracking process. They can help manage the mass of details, and ensure everyone on a project has the most current information.

Requirements allocation is not a one-time task, although it is weighted towards the early stages of a project. As design and testing make progress, they can provide feedback and adjustment to the assigned requirements. These changes propagate to higher levels, and by tracing back their impacts, you can determine how they affect the top-level goals of the project. Changes can also have sideways effects at the same level. For example, an increase in weight of one part of a system may require weight-saving efforts elsewhere to not affect top level performance.

System Modeling [edit | edit source]

The next major step is to model the system and alternate approaches to the design. Various methods are used to model the design and configuration of the system elements. Traditional ones include two dimensional diagrams (blueprints) and physical scale models. These methods can help visualize a system, but are not easy to modify, derive parameters, or perform simulations. The trend is towards integrated software modeling, where software tools model and simulate multiple aspects of the system, or communicate from one tool to another. In software tools, a system is represented as data and mathematical relationships, which makes it much easier to change, optimize, and evaluate.

Input/Output Model [edit | edit source]

Input-Output Models were first developed for quantitative understanding of the total flows in an economy. They can be applied to any system, not just economic ones, for determining if all the inputs and outputs of a system add up. It can be visualized as a spreadsheet with the elements of a system as rows, and additional rows for items outside the system. Types of inputs and outputs are in columns. Each component requires inputs such as power, data, fuel, etc. It also produces some kind of output. The purpose of a model is to see if your system as a whole has closure and balance. In other words, are all the inputs matched by outputs? Are there missing components identified by missing inputs? Is the size or quantity of a particular element in the system the correct size/productivity? Will the system as a whole produce the desired output, and if so how much? These are really all questions of accounting. Rather than counting everything in money, this type of spreadsheet does the accounting of each type of input/output/resource/supply separately as categories. Note that human labor is one of the input types.

A model, such as an Input/Output Model lets you actively see how a change in any one component, such as a new design, impacts the system as a whole. By summing the flows of the component functions in a model spreadsheet (or other computer model) you can immediately find changes to the rest of the system components and the totals for the entire system. The Input/Output model and functional diagrams both model aspects of the same system, and may be combined within a single software tool or database if it can represent all the details of a system in sufficient detail. This is desirable for plotting how changes in system components affect the system as a whole.

Functional diagrams at a basic level are maintained as static drawings, and input/output models can be an actual spreadsheet. Using the same numbering system and structure for the diagrams and models maintains the relationship between them. They are both representing the same system, just different aspects.

Optimization and Trade Studies [edit | edit source]

Optimization and selection is done at all levels of engineering design. In the Systems Engineering process it is first applied at a high level to concepts before detailed design is performed. Optimization is varying parameters within a single concept or element in order to find the best values for those parameters. Trade Studies compare different concepts in order to select the best one. Different parameters like weight, cost, and risk cannot be directly compared. So they are scored by measures of effectiveness (see page 1). The concept or optimized parameters that yield the highest score is the "best option". In the early stages of design, there will be larger uncertainties in parameters like weight and performance. Finding how much effect variations in such parameters have is called Sensitivity Analysis. Knowing those will guide which areas to work on to reduce uncertainties.

If the difference in evaluation score between two concepts is sufficiently more than their uncertainties, the lower scoring one may safely be discarded. If the scores are within the range of uncertainties, both should be worked on in more detail until a clear winner emerges. If the effort to reduce uncertainty is judged more than the uncertainty reduction is worth, then one of the competing choices can be selected arbitrarily. Note that optimization of a system as a whole may not mean optimization of each individual part, since the parts can interact in a complex way. Once the optimization and selection is completed, the results are recorded and used to update the system concept and current design configuration.

Synthesis and Documentation [edit | edit source]

The last major step in the systems engineering design cycle is synthesis and documentation. In systems engineering, "System Synthesis" is assembling the results of completed analysis and studies into a coherent design. The design for a complex system typically includes multiple items of hardware, software, facilities, etc. Each separate item is referred to as a Configuration Item, and the current state of that item's design at any given time is called a Configuration. Configuration Management is the task of documenting the current state of the design and analysis work. This is necessary to coordinate the work for a complex design with many people involved. Otherwise some work would be based on obsolete data or incorrect assumptions. Other documents included in recording the work are Requirements, Specifications, Study Reports, Simulation code and results, 3D Models, and any other data and notes created in the course of the work. All of this is kept as a base for further work, if later changes are needed, or if questions or problems come up. Design data is also needed for later project stages like production.

Work Breakdown Structure (WBS) [edit | edit source]

Figure 1.5-6: Example WBS Drawing.

A common method to document a system is to index all the requirements, plans, drawings, analyses, reports, budgets, work logs, and other data by a numbering system called a Work Breakdown Structure, which covers all the elements of the system across it's life cycle. In modern projects the actual data is mostly stored electronically, but a WBS helps organize and find particular items in the same way classification systems for books are used to organize libraries.

A WBS is a hierarchical table or drawing showing all the parts of a complex system and their successive division into smaller parts until you reach the level that specialty engineers can do the detailed design. It gives structure to what would otherwise be an amorphous mass of design work. The WBS serves as a tracking method and index, so that people working on different parts of the project tell they are talking about the same items. It also serves as a method to collect and file the engineering data as it accumulates, assign tasks to individuals and groups, and track progress and costs. The WBS is often derived from the functional analysis of the system.

In theory a WBS can be structured in any way you choose, but usually each level of division within the structure has a common basis. Examples include:

By location on Earth or in Space
By type of function, such as Production, Operation, and Transportation
By type of element, such as Data, Software, Hardware, Facilities, and Staff.
By end item product, such as a launch vehicle or lunar base
By Subsystem, such as structures, mechanical, or electrical
By time sequence, such as Phase I, or Version 2 Upgrade
By type of data such as drawings, analyses, or reports

The basis to use depends on what makes sense for the project, but a consistent structure, such as all second level divisions are by end item, makes the overall structure easier to understand and use. It is more important that everyone on the project use the same structure than exactly how it is divided up. Maintaining the structure is often assigned to systems engineering specialists because it is related to the other tasks they perform. Each part of the structure is given a number or identifying key, typically using decimal points to distinguish levels, i.e 1,2,3, ... for the top level, then 1.1, 1.2, 1.3, ... for the parts that make up the next level below item 1, and so on. This is not the only way to do such structuring, but it is commonly used and easy to understand. The following section illustrates some of the ways to arrange a given WBS level. It is not an exhaustive list.

WBS by Item Type [edit | edit source]

This example is for an automated factory that consists of operating data, software, and hardware, facilities, and staff:

1.0 Operating Data Components

1.1 Design Standards
1.2 Manuals and procedures

2.0 Software Components

2.1 Design Software - A great deal of design software already exists. The specific need for advanced manufacturing is to design parts so they can fit the production capability of given machines, and supply processing and assembly instructions for individual and collections of parts. This may required modifying or adding to existing software.
2.2 Work Order Software - Takes an incoming product design in the form of CAD files, compares it to the factory capabilities and inventory, and generates a work order list of tasks for each machine, parts and materials to order, etc. Work orders are then scheduled among the various components.
2.3 Machine Driver Software - Each type of automated machine requires specific driver software to control how it operates, and to collect data back to track progress and other purposes.

3.0 Hardware Components

3.1 Storage - Materials, parts, and assemblies need to be stored when not actively being worked on.
3.2 Materials Handling - To transport items from one location to another.
3.3 Production Machines - Turn raw materials into inventory stock or finished parts, possibly using several machines for different steps.
3.4 Assembly Machines - Convert a collection of parts into a finished item. This will generally involve one or more robots.
3.5 Inspection and Observation Hardware - To test items and oversee operations.

4.0 Facility Components - This includes modification of the surroundings, controlling the factory environment using buildings, and supplying utilities, but not specifically producing any items.

5.0 Staff Components - Humans are not components to be designed, but rather selected and trained for required skills, and then supplied in needed numbers.