Section 1.5: Systems Engineering
Engineering applies scientific principles and other forms of knowledge to design, build, and operate systems which perform an intended function. Space systems engineering can be divided into general methods which are useful for any complex project, and specific methods relevant to particular space projects or circumstances. The remainder of Part 1 will discuss general engineering methods, and Parts 2 and 3 will discuss the more specific ones for space projects.
Systems Engineering Scope
We can define the general engineering task as follows: Given an identified need or desire, how does one select the best design to satisfy it out of the infinite number of possible solutions? For a complex project, the concept of a "system" and the process of "systems engineering" are the most useful approach.
A System is defined as a functionally, physically, and/or behaviorally related group of regularly interacting or interdependent elements. They are distinguished from the rest of the Universe by a System Boundary. A system is not a physical entity, but rather a mental construct created because of it's usefulness, by drawing a line or surface around a collection of elements. The elements have internal relationships to each other and form a comprehensible whole. The rest of the Universe outside the system is referred to as the System Environment, or simply the environment. Flows of many types enter and leave the system as Inputs from and Outputs to the environment by crossing the system boundary (Figure 1.5-1). The scope of a given engineering task is then defined by the system boundary, what crosses the boundary, and what is inside. Systems may contain smaller systems within them, which are called Subsystems. These may be nested to any level, but flows into and out of a subsystem must appear in the parent system, or at the top level in the environment. This rule may be called Conservation of Flows - that flows do not appear from or vanish into nothing. Following that rule ensures that all the required inputs and outputs are accounted for.
While a single person may do a preliminary concept or design, a complete space project is usually too complex for one person to finish. Therefore a method known as Systems Engineering has been developed to organize and carry out such projects. It can be used for any complicated engineering project, but aerospace projects are particularly suitable due to their complexity, and were among the main ones for which the method was developed. The method focuses on how projects should be designed and managed over their entire Life Cycle, that being from initial concept to final disposal. Since it applies to the whole project, it is interdisciplinary, connecting tasks performed by Systems Engineering specialists to those of other engineering branches. Key parts of the process include:
- Breaking down a complicated project in such a way that the smallest pieces are simple enough for humans to design.
- Modeling the system so it can be analyzed and optimized, and comparing the actual physical system to the models.
- Control and track the information and design of the pieces and their relationships so the total system will do what you wanted.
The tasks within the systems engineering process are usually done in parallel in an iterative closed-loop fashion, rather than a single linear process. The output of one iteration feeds back into the process for the next level of detail or refinement. It should be noted that an organization capable of designing and building complex space systems is itself a complex system. While it is not often done, Systems Engineering methods can be applied to the organization itself to design and optimize how it functions, or to any complex system of any type, not just space hardware. The systems engineering process is bounded by natural and human-made constraints, many of which are not directly related to design, as are the physical properties of materials. These indirect constraints include economics, laws, and safety of life and property. It is thus outward-looking beyond the design itself, while engineering specialties are more focused on the internal details of the design.
It is not required that a single organization do all the Systems Engineering tasks. Some very large systems which have been deliberately engineered, such as the US Interstate highway system, the Internet, and the US program to land humans on the Moon, involved many entities working together. A national system of government, human civilization, or the Earth's biosphere can be considered as very large systems in terms of having inputs and outputs, a system boundary, and an external environment. Analyzing such large entities as systems can help with understanding how they function and determining if corrective action is needed. There is a growing understanding that such large entities are systems composed of many smaller systems, whether designed or not. Although some attempts at designing governments have been made, they have yet to be done based on scientific and engineering principles. Geoengineering, which is the concept of deliberately affecting the Earth's climate, is an example of biosphere level engineering projects. Doing them deliberately, as opposed to the inadvertent side effect of civilization, is as yet still in the conceptual stage. More work has been done in the field of Economics in analyzing economic systems, and sometimes attempting to design or influence them.
As a well-developed engineering specialty, there are a number of reference books, standards, and special methods and software used by systems engineers to understand and manage the interactions, and communicate the current state of a complex project. The remainder of Part 1 of this book summarizes the Systems Engineering method, the elements of a system, engineering tools, other design specialties, economics, and existing programs. All of these must be integrated properly for a new project.
For additional detail on Systems Engineering beyond what is here, see:
- DAU Press, Systems Engineering Fundamentals, 2001.
- NASA, Systems Engineering Handbook, 2007.
- NASA, Systems Engineering Class Materials - Website developed since approx. 2008.
The System Life Cycle
The stages of a life cycle for design purposes can be organized in different ways depending on the nature of the system. These include linear, parallel, spiral, or closed loop sequences, or some mixture of these. The illustration shows an example of a linear sequence. A spiral organization repeats stages in increasing detail, while a closed loop repeats at the same level of detail. The important factor is to consider all future stages when doing the design work, so that the best total solution is found, rather than optimizing for just one part of a system's life. The major stages in a project life cycle can vary, but common examples and their major tasks include:
- Conceptual Design
- Identifying the need - what is it you want the system to do? This is embodied in goals and requirements.
- Establish selection criteria - how do you decide one design is better than another?
- Establish system concept - for main functions, operation, and maintenance
- Preliminary Design
- Functional analysis - identify and break down the complex system into smaller functions and their relationships, including alternate arrangements
- Design Allocation - subdivide and assign requirements to lower tier functions
- Formulate alternatives - develop alternate solutions - what are the range of possible options?
- System Modeling - develop mathematical models of the system so variations can be assessed.
- Optimization and selection - making each option as good as it can be, then compare options and choose the best.
- Synthesis and definition - combining the selected options into a total design, and recording the configuration and requirements details
- Detail Design
Once broken down to a low enough level, individual elements are assigned to engineering specialties or design teams to complete. This includes both physical components, as well as software, facilities, operating procedures and other non-physical elements.
- Fabrication and Assembly
- Production of components - For physical items, the step where you make the parts.
- Assembly - Putting parts together into complete elements.
- Test and Verification - At each assembly level, testing that the assembly functions, then moving up to larger assemblies to the final product. Verification is proving it meets the stated design requirements, which may be a combination of tests and analyses.
- Installation and Deployment - After production, the system elements may need delivery, installation, and activation at the location they will be used
- Operation and Maintenance - Using the system for the purpose it was designed, which includes operator training, performance monitoring, logistic support, regular maintenance, repair, and upgrades.
- Decommissioning - When the system has reached the end of its useful life, the removal, recycling, and disposal of system elements, and return of former sites to their original conditions.
The stages of a life cycle are further broken down into internal tasks which have inputs and outputs which connect them, and have decision points for when it is time to proceed to the next stage. A life cycle is a time oriented view of an entire system. Other views of the same system include functional diagrams, which show what tasks it performs and their inputs and outputs, and a work breakdown, which tabulates the elements and sub-elements which make up the system. Which view of the system is used depends on the design task at hand, though all the views need to be kept current or the design process becomes out of synch.
Systems Engineering within the Life Cycle
As a process that applies across the whole life cycle, Systems Engineering is not just used in the initial design phase. Part of good design practice is to know when to stop designing. A design can always be improved with more work, but at some point additional work does not provide enough added improvement to justify it. At that point the design should stop, and the system progresses to the next stage, which is usually fabrication and assembly. With time, the original design assumptions for a project, such as the available technology level, or launch to orbit traffic levels, will change. The systems engineering process can then be re-applied to see if a design change, upgrade, or even complete replacement of the system is warranted. Even if the system was optimally designed when first created, future events may require changes. If the system was properly modeled and documented, then monitoring of these external changes will reveal when it is time to restart the engineering.
Figure 1.5-3 illustrates in general the steps within the Systems Engineering process. The general trend is from top to bottom, but we do not show arrows connecting the steps because it is not a strict linear flow. As results are obtained in any task, they can feed back to earlier steps in an iterative fashion. Thus these tasks happen in parallel, and across the different stages of the life cycle. They are also applied at different levels of detail. The process starts at a general level of detail. Once a stable configuration is reached at one level, it then is re-applied at lower levels until detailed design can be done on individual elements. At all levels, there is communication with design specialties, and with outside entities such as the customer, suppliers, and other scientific and engineering organizations. The steps are described in more detail in the following sections.
Developing a new system starts with a desire or need, expressed by a Customer, which cannot be satisfied by existing systems. For Systems Engineering purposes the direct customer is the person or entity who is paying for a project or can direct the engineering staff. For example, in the Boeing Company, that is the engineering managers and general managers of the company. The ultimate customers, which are airline passengers, cannot express their desires directly. Therefore the company management serves as a proxy to express their desires as an input to the engineering process. Other methods, such as surveys, can be used to determine the desires of the ultimate customers.
The initial expression may be in the form of general verbal goals, system properties, levels of technical performance, and similar statements. The customer also will have some value preferences which describe what a better design is from their point of view. These can be things like "minimum cost", "minimum waste output", and "maximum efficiency".
Requirements Analysis is the process of converting general customer desires and preferences to specific measurable features which can be used for design and evaluation. Two main parts of this process are Requirements Definition and Measures of Effectiveness.
- Requirements Definition
The highest level general desires are first converted to specific measurable features and values called System Requirements. These are later broken down into more detailed lower level requirements, which are assigned to logical elements of a system called Functions to perform. The assignment ensures that somewhere in the system all the top level goals are met. At the most detailed level a subset of the lower level requirements are assigned to a single function box. This now becomes the detailed design conditions for that function. Assuming the analysis has been carried to a low enough level, the detailed design of that system element can then be done with a reasonable effort.
The first step in requirements definition is documenting the original desire or need of the customer in as much detail as they can provide. We will use as an example the Apollo program to land humans on the Moon. That was expressed by President Kennedy as a well known goal with a deadline. That very general statement was not sufficient to design the hardware. The key task is to put all the requirements in forms that can be measured so that you can tell when you meet them. Experience shows if a desirable feature or parameter is not expressed and measured, it will not happen as desired. An example of this failure is the Space Shuttle program. The original goal was to fly 60 times a year. Given a fleet of 4 Orbiters, each one had to fly 15 times a year, or one launch per 24 days. Subtracting 7 days on orbit and one day before and after flight for launch preparations and post-landing recovery, that leaves 15 days to complete ground processing. The stated goal was thus 160 hours for ground processing, composed of 2 shifts (16 hours) x 10 work days over two weeks, thus 14 days. This goal was expressed, but it may not have been included in the system requirements, and it definitely was not allocated to lower tier hardware and tracked at the lower levels like hardware weight was.
Only after the Shuttle was already flying was it noted that ground processing was taking too long, and efforts started to reduce it. At that point it was too late to make any fundamental changes in the design, and so ground processing never got below about 800 hours, about 5 times the original goal. This was a major contributor to the Shuttle never reaching its intended flight rate. In order to have reached their goal of 160 hours, processing time would have had to be allocated to sub-systems, such as landing gear or maneuvering thrusters, and then each subsystem designed to meet it's assigned time. Conversely to processing time, weight has always been a tracked parameter in aerospace systems, since airplanes cannot function if they are too heavy. The Space Shuttle had very detailed weight targets and a tracking system by component, with monthly reports. It more or less reached its design payload, which is the 1.5% of available launch weight remaining after the vehicle hardware and fuel are accounted for.
This example emphasizes why desired features must not only be stated quantitatively, but passed down for detailed design engineers to meet, and tracked so you can tell if you are going to meet them. Measurable parameters can be a simple yes or no, for example "Does this airplane design meet FAA regulations?", or it can be a numerical value, range of values, table, formula, or graph indicating the range of acceptable values for that system characteristic.
- Measures of Effectiveness
Desired features are often in opposition. For example, higher performance and reliability often come at the expense of higher cost. There are also alternate designs which have different amounts of each feature. Establishing Measures of Effectiveness is the quantitative method to account for these disparate features at the level of the whole system. Like requirements, they are derived from customer desires as to what would be "better" in comparing one design over another. Since different features typically have different units of measurement, they need to be converted to a common measuring scale. This is done by formulas that convert each different value, such as cost or performance, to a score. These scores are given relative weights based on their importance to the customer. The weighted measures can then be used in a single mathematical model or formula to determine "better" as a total score, when the component values vary across different designs.
The value scale is often in a range such as 0 to 100%, or 1 to 10, but this is arbitrary. What is more important is a definite conversion from a measurable feature to a scoring value, and the relative weights and method of combining them to a total score. As an example, a value of 0% might be assigned to a payload of 15 tons, and 100% to a payload of 45 tons, with a linear scale in between, and payload given a weight of 30% in the total score. The total scoring system is a mathematical model of the customer's desires for the system. Getting a customer to define "better" in such detailed numerical form is often difficult, because it removes their freedom to choose what they personally prefer in a design in spite of the engineering solution. It is necessary, though, if you really want an optimal answer. At the least this process makes it obvious when the customer is over-riding the engineering process.
It should always be kept in mind that a particular design solution may not be "good enough" in terms of of it's measures when compared to existing systems. This can be found by including the existing system as one of the alternative designs being scored. In that case the proper answer is to stop development of the new system and stay with the existing ones. Often the cause is not enough performance improvement relative to cost, but other measures can result in a decision to stop.
The following sections list major types of system requirements. Not all would be relevant to a given project, and others besides these might be important to the customer, so it is presented as a starting point for consideration. Each type can include more specific requirement values. The types listed here are interlinked and somewhat overlapping. For example high reliability and high safety generally go together. Requirements set limits on a design, and overlap between requirements in effect overlap in what range of limits they impose. This is acceptable as long as the designer understands the range of overlaps and interactions among the requirements. A particular design parameter will be governed by the strictest requirement when there is overlap. An example from civil engineering is that earthquake, wind, and snow loads are all requirements to meet in a building design, and they overlap in that all of them affect the structural elements.
When decomposed to lower levels of the system design the requirement types and values will become more specific and detailed. Care is needed to maintain logical and numerical consistency across system levels. Requirements, or parts thereof, should not be inserted or dropped at lower levels. Traceability is the ability to follow the chain of requirements across the system levels, and is maintained by documenting how they are connected. This is necessary so you can prove satisfying the lowest level details actually meets the top level system goals. Historically the first two requirement types, performance and cost, were the primary ones considered. As systems have grown more complex and their interactions and side effects became recognized, the number of desirable features, and thus the number of requirements, have increased. This trend is expected to continue in the future.
Aside from the Biblical Ten Commandments, requirements are not set in stone. Not all of them will be identified at the start of a project, and as a result of interaction with the customer and feedback from the design process, they can end up modified. For example, a launch capacity of 10 launches at 100 tons each might be specified for a rocket, and later analysis show that 20 launches at 50 tons each yields lower total cost. The requirements would then be modified to reflect that. At any given time, however, the current set of requirements guides the engineering work. Over time requirements become more firmly fixed, generally from the higher to more detailed levels in sequence. Changing a requirement forces rework of previous designs. Thus the cost of changing a requirement later in the process grows, and this tends to exceed any benefit from the change.
Performance requirements are measures of the primary intended function of a system. Every system must have at least one performance measure for what it does, and often there are a number of them. As an example, for space transport systems, the design capacity is often expressed as a Mission Model. The mission model quantifies the system performance in terms of multiple parameters like dates, flight rate, payload dimensions and mass, mission duration, destination orbit, type of cargo, and maximum g-level. For a space habitat, performance might be measured in number of crew supported, levels of atmosphere, food supplies, and gravity, and total living volume. An industrial system might have requirements for Throughput, in tons per day of materials processed, and Efficiency in terms of (theoretical energy required)/(actual energy used). The particular performance measures which matter will vary by system.
An example mission model for the Apollo program might have started out as follows, with more detail added as the project progresses. Even in this early version, it lists a number of different performance measures that the design needs to meet:
- Number of crew to the lunar surface: 2/mission
- Maximum Stay time: 4 days/mission
- Additional science equipment: 250 kg/flight
- Lunar samples returned: 100 kg/flight
- First Flight: as early as possible but before Jan 1, 1970
- Flight quantity: 10 to lunar surface (this was the original plan)
- Flight rate: 4 flights/year
Performance measures only address what a system does when it is operating as intended. It does not address what happens outside that context, such as
- In between active operation, such as the 80 days between Lunar missions in the mission model above.
- When the system fails, as did the Apollo 13 mission,
- Before and after the 5 years of manned missions.
- Interactions external to the program, such the supply of technical personnel for the project, environmental impact of the launches, or return of Lunar germs to Earth. The last turned out to be a needless worry, but the quarantine system for returning astronauts and moon rocks is not something covered in performance measures.
Thus performance alone does not encompass the entire system over the entire life cycle, and other requirement types are needed.
Cost represents some of the resources input to a project from outside the system. Thus they are a measure of flows across the system boundary, rather than an internal property of the system. Since every system will consume some resources during its life, cost is almost always considered a requirement, implicitly or explicitly. Total cost over the entire life of the project is called Life Cycle Cost. This can be further broken down into development, production, and operations costs, and then into much greater detail across the system elements. Costs are offset by revenues in some systems. When revenues exceed cost, the system as a whole generates a profit in financial terms. The ratio of performance to cost is often a key measure for a project.
These are requirements set by human rules such as laws, regulations, codes, and standards. Human rules often set minimum requirements in areas like safety. This does not prevent a system from adopting stricter levels. Human rules are usually designed to prevent undesirable effects. For example, speed limits on driving are intended to reduce the frequency and severity of accidents. Compliance requirements exist whether or not they are explicitly incorporated into the engineering process. It is better to incorporate them explicitly to avoid later problems.
Especially in the early stages of design, the engineering process may reveal gaps in knowledge, performance uncertainties, resources which are not available, or other issues which prevent selection, optimization, or synthesis of a design. These issues can prevent progress to the next stage of the project, or a final design which does not meet desired goals. Measures of these unknowns are given the general name Technical Risks. For example, a new technology which has not been demonstrated yet, i.e. a fusion rocket, would be rated as high risk, while a chemical rocket, which has decades of operating history, would be comparatively low risk. A mass budget considerably below past experience or with insufficient margin during preliminary design would be high risk. New research, modeling, or prototyping can be done to reduce the risks, or the system modified to avoid them, but prior to doing risk reduction the risks will exist, and it is necessary to account for them or run the alternate risk of the system not performing as desired or even at all.
Not every risk will be known at the start of a project, but sound engineering practice is to identify them as early as possible, and to allow for modifying development plans when they appear. Depending on how much new technology is included in a project, sufficient performance, time, and cost margins should be included for unexpected problems caused by technical risks.
Safety is a measure of of a different kind of risk than technical. It is the chance of injury or death to living things, and damage and destruction of inanimate objects. Under the principle of "protecting the innocents", hazards to a crew that volunteers to accept a risk can be different than the allowed hazards to the public at large. A system with good level of safety may have infrequent or less than one expected accident during the system life. Thus safety often involves assessing low probability events. Requirements to maintain control of a system despite failures, inherent failsafe design, design margins, backup systems, and redundancy can improve safety when properly implemented.
This is the probability the system will perform its intended function. It is related to Resilience, which is the ability to function in the face of internal damage or external failures, and to Robustness, which is the ability to function in the face of external or internal variables, such as line voltage or temperature.
Service life of components and of the system as a whole is related to maintenance. Once the life of the item has been reached, it will need repair or replacement. Service life can be measured in terms of number of uses, operating hours, or calendar time.
One part of quality is a measure of the lack of variability or defects in the design and manufacturing stages of the life cycle. Another way to put it is conformance to initial specifications. Wear or defects caused during normal operation are not a quality problem unless they are unexpectedly large. Normal wear would fall under maintenance requirements. Another quality factor is parameters like signal-to-noise ratio and error rates in electronic devices. Noise and quantum effects are natural variations which cannot be eliminated, but a larger ratio above those variations in effect reduces variability and increases quality.
Does the system consume a scarce resource or generate a waste output that limits it's long term use?
These are requirements to have a positive, or at least minimally negative, impact on the surrounding human community. This might mean employing local staff, or avoiding traffic problems during a shift change, or noise impact from rocket launches. Positive educational impact is another community effect.
Like community, these requirements relate to impact on the surroundings, but in this case the non-human ones. For space projects a key environmental requirement is to avoid contamination, either biological, chemical, or from radiation, both forward and backward from ends of the mission.
This type of requirement covers items such as how many sources are there for a given manufacturing method, or how exacting the tolerances are. In sum they measure how easy or hard the system is to manufacture.
These requirements deal with the types and quantity of tests required for a system. Development tests occur during the design stage, qualification tests occur during approval, and periodic inspection and testing may be needed during the operations stage.
These requirements include parameters like hours and costs to maintain the system in an operating state, probability of system failure, and levels of spares required. A system can fail without safety risk. For example, your car may not start, which is different than the brakes failing to operate. The more often that items fail to operate, the more spares are needed in stock, and the more time and money to repair or replace items. Thus the various maintenance requirements are linked. Maintenance requirements can be divided into preventive, which is before something stops working, and corrective, which is after.
This is the ability of the system to adapt to new tasks or functions or different performance levels of the original tasks than first designed for. Similar requirements come under names like Extension, which is adding new tasks or functions while keeping the original ones, or Agility, which is concerned with how fast the system can adapt. Reconfiguration is the ability to change the arrangement of a system to perform a different function. An example is the Curiosity rover, which had one physical shape and software load to cover travel to and landing on Mars, and a different arrangement of wheels, camera mast, and software for surface operations. The change of state was accomplished by a combination of mechanical design, planned sequence, and new software upload.
This is the ability of the system to change in size either by scaling the size of a unit, or by installing more units. There is always a limit to scaling imposed by some physical constraint. If the system can be scaled to meet the full demand for it without reaching scaling limits, it can be said to be scalable. Modularity is a related parameter, concerned with how separate the elements of the system are, and how easy it is to replace them with other elements of the same or different types. Instances of modularity can be horizontal - at the same level of a system, or vertical, as in the layers of the Internet Protocol stack.
This requirement type considers how well the system can change over time to a different type of system. It is related to flexibility, which is more about changes while staying the same kind of system. Redesign is concerned with the difficulty and cost of making changes.
Usability requirements deal with the interface between humans and system elements. When a system can be used without great amounts of planning, preparation, physical strain, or training it is said to have high usability.
This is a measure of how the system fits with other systems. For example, a new airplane with doors that did not fit existing gates, or a computer network that exclusively uses a new protocol that nobody else uses would fail in this parameter. Compatibility is more concerned with the direct interfaces between systems, such as the output of a computer video card matching the input to a monitor. These features are more prominent in the information technology fields because of the sheer number and variety of hardware and software elements which must work together (with varying degrees of success).
This is the degree to which a system is composed of proprietary or secret elements compared to open, public, or standard elements.
Analysis in general is the process of developing abstract models or performing calculations for the component elements of a system, to help arrive at a complete and optimized design. Functional Analysis includes breaking down a higher level system element into more detailed steps on the basis of what it does, before considering how it is performed. Prior to selecting the best design, there can be multiple such 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.
Even at the highest level of the system as a whole it is difficult to define requirements and measures without an idea of how the system will function. This step 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. 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 should cover what main tasks the system will perform, and how it will be operated and maintained. Once the system concepts are established, a 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, and 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 cyclic heating and cooling, and so require different types of inspection. Thus when listing design alternatives, it is not just ablative vs metallic, but also how that choice affects the total flow of operations in the system.
Functional Diagrams illustrate the component operations a system performs and their inputs and outputs. It is a model of a system in visual form, starting with external inputs and outputs which cross the system boundary, and then 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. For example, for an airplane, the main functions would be illustrated by (diagram here showing: Load Passengers and Cargo, Taxi to Runway, Takeoff, Fly, Land, Taxi to Gate, 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.
Individual functions in a diagram transform inputs into outputs, and 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.
By convention, control inputs which regulate the operation are shown at the top of a function box, and mechanisms which perform the function are shown at the bottom. 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 one way to record and communicate the structure and operation of a system, and allow numerical calculations, for example adding time steps to find total operation time, or summing staff required for each function to get total staff needed to operate the system.
As noted above, to ensure all the input requirements will be met, this task distributes them among the identified functions. The allocation may be by whole, or by dividing a requirement into parts and then assigning the parts to functions.
Various methods are used to model the design and configuration of the system elements.
This is a tool 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 more 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
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. 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.