Systems Engineering

Introduction

Engineering applies scientific principles and other forms of knowledge to design, build, and operate systems which perform an intended function. It is a broad discipline. In a simple project, such as designing a bookcase for home use, a formal engineering process is not needed. One person can calculate the shelf loads and other parameters by themselves, with the help of a calculator and some reference data. Large and complicated projects, however, need the knowledge of multiple specialists, must satisfy multiple desired conditions and functions, and involve large amounts of time and money. A need then exists to coordinate the work, and ensure the final product meets the intended goal, in the most efficient way. Systems Engineering methods have been developed for this coordination task. They have become their own specialty field and are used in addition to the other engineering specialties. Systems Engineering can be used for any type of complex project. However, space systems are usually complicated enough to benefit from it, and systems thinking and methodologies are often used in this field.

Source: https://en.wikibooks.org/wiki/Space_Transport_and_Engineering_Methods/Methodologies
This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.

1. Systems Engineering In General

1.1 What is a System?

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 has proven useful. 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 (Figure 1.5-1). A system is not a physical entity, but rather a mental construct, created because of its 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. 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.

1.2 Systems Engineering Method

A single person may have the time and knowledge to do a preliminary concept or design. A complete space project is usually too complex or would take too long for one person to do. So the Systems Engineering method can be used to help carry out such projects. Aerospace projects, including space systems, 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.

Figure 1.5-2 illustrates in general the steps within the Systems Engineering process. The 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, until a stable design solution is reached. So these tasks can happen in parallel, and applied across the different stages of the life cycle. The tasks can also be applied at different levels of detail. They are started at a general level. 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 sections 3 and 4 below and on page 2. 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 the human constraints are not directly related to design in the way physical properties of materials are. These indirect constraints include economics, laws, and safety of life and property. The process is then also outward-looking, beyond the design itself. Other engineering specialties are more focused on the internal details of the design.

1.3 Large Scale Systems

It is not required that a single organization do all the Systems Engineering tasks. Some very large systems, that 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. There is a growing understanding that such large entities are systems composed of many smaller systems, whether designed or not. Analyzing such large entities as systems can help with understanding how they function and determining if corrective action is needed. Although some attempts at designing governments have been made, they have yet to be done based on scientific and engineering principles. Climate Engineering, 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 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.

1.4 Reference Sources

As a well-developed engineering specialty, there are a number of reference books, standards, and special methods and software used by systems engineers. They are used to understand and manage the interactions, and communicate the current state, of a complex project. The remainder of Part 1 of this book summarizes parts of the systems engineering method. This includes the elements of a system, engineering tools, involvement of other design specialties, and economics. A given program also has to be understood in the context of other existing and future programs. All of these tools and knowledge must be integrated properly for a new project.

2. The System Life Cycle

Complex systems evolve through a Life Cycle much the way living things do, from conception to disposal. The life cycle is divided into a number of stages where different tasks are performed (Figure 1.5-3). The design stages (the first three boxes in the figure) 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 a typical linear sequence. A spiral process repeats stages in increasing detail, while a closed loop repeats at the same level of detail. Beyond the design stages, the process is more typically linear from production, through test, installation, operation, and retirement.

Life cycle stages are used for two important reasons. First, the design process should consider all the later stages, so that the best total solution is found, rather than optimizing for just one part of a system's life. Second, breaking down a system by time is another way to simplify the design work, along with breaking it down by subsystems and components. The stages are further broken down into internal tasks which have inputs and outputs that 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 can become disjointed.

2.1 Life Cycle Example

The names, and the task contents, of a given project's stages can vary according to the needs of the project. However, a somewhat standard linear flow is often used in aerospace engineering, including space-related projects. The stages and typical 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 a system concept - this includes the main functions, operation, and maintenance of the system.
• Feasibility analysis - can the need be met at acceptable cost, schedule, and other parameters.

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

• Design - Once broken down to a low enough level, individual elements are assigned to engineering specialties or design teams to complete. Design includes physical hardware components and facilities, as well as software, operating procedures, training, and other non-physical elements.
• Integration - Design elements are combined into larger functional units that work together, up to the system as a whole.
• Engineering Models and Prototypes - Physical partial models and complete prototypes built to validate the design.

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

• Element and System Test - At each assembly level, testing that the assembly functions, then moving up to larger assemblies to the final product.
• Verification - Proving the system meets the stated design requirements, by a combination of test, demonstration, inspection, 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

• Operation - Using the system for the purpose it was designed, in the intended environment.
• Support - which includes operator training, performance monitoring, and logistic support.
• Maintenance - includes planned maintenance and unplanned repair, and in-place 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.

Life Cycle Engineering

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.

3. Requirements Analysis

Developing a new system starts with a desire or need which cannot be satisfied by existing systems. The needs and desires are expressed by a Customer, 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. So 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".

The first major systems engineering step, Requirements Analysis, is the process of converting these 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.

3.1 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 the element that performs the function 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 engineers to meet in detailed design, 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.

3.2 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. In this case it is what features would be "better" when 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 an importance of 30% in the total score. The total scoring system becomes 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.

4. Requirements Types

The following subheadings 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 linked and somewhat overlapping. For example high reliability and high safety generally go together. Requirements set limits on a design, and overlaps between requirements in effect overlap the 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 such 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 required strength of structural elements.

When broken down 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 outside interactions and side effects become better understood, 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 rarely set in stone. Not all of them will be identified at the start of a project. 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. So the cost of changing a requirement grows later in the process, and this tends to exceed any benefit from the change.

4.1 Performance

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, the design capacity for space transport systems 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:

Cargo characteristics:

Mission Schedule:

Performance requirements 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.

So performance alone does not encompass the entire system over the entire life cycle, and other requirement types are needed.

4.2 Cost

Cost represents the net resource inputs to a project from outside the system. Space projects don't use Dollars or Euro directly, but rather use them to pay for labor, materials, and services they do use. So cost is a measure of flows across the system boundary, rather than an internal property of the system. Every system will consume some resources during its life, but funding sources are not unlimited. So cost limits are almost always considered a requirement, whether 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 accounted in much greater detail across the system elements. In addition to total cost, limits can be placed on spending rates. This is most explicit in government agency budgets, but even private projects have limits on spending per year. Some systems generate revenue to offset costs. When revenues exceed cost, the system as a whole generates a profit in financial terms. Revenue may be delayed until after the design and construction phases and the system begins to operate. The peak net cost accumulated until revenues exceed expenses is described as Capital or Development Costs. Customers generally want high performance and low cost, so the ratio of performance/cost is often a key measure for a project.

4.3 Compliance

Performance and cost requirements are set by the project's customer with the help the engineering team. Compliance Requirements are set by external 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. Other requirements are set by nature, such as the minimum altitude for a stable Earth orbit. These do not fall under compliance, but are accounted for elsewhere. In the case of altitude, this might be a performance requirement that a rocket deliver the payload to a 250 km high orbit.

4.4 Technical Risk

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 cause 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. Before these risk reduction efforts the risks will still exist, and it is necessary to account for them. Otherwise you accept 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. Technical risk is gradually retired during the design and production of a system. Once a system is operating, a small uncertainty remains for things like operating life or failure rates. These are not eliminated until the end of program operations. Even after disposal of a system, some environmental risk may remain. A prime example is nuclear waste, which is a hazard long after the reactor that created it has been demolished.

4.5 Safety

Safety is the state of being protected against adverse consequences to living things, or damage and destruction of inanimate objects. It is an inverse measure of other risks than those under the previous heading. So a higher safety level is measured by lower risks. Under the principle of "protecting the innocents", hazards to a crew that volunteers to accept a risk can be higher than those allowed to the public at large. A safe system, such as a nuclear power plant or passenger airplane, may have less than one expected accident during the system life. So safety often involves assessing low probability events. Requirements to maintain control of a system despite failures, inherent fail-safe design, design margins, backup systems, and redundancy can improve safety when properly implemented.

4.6 Reliability

Reliability is the probability the system will perform its intended function for a specified time period. The inverse is probability of failure. It is related to Resilience, which is the ability to function in the face of internal damage or external failures. It is also related to Robustness, which is the ability to function in the face of external or internal variables, such as line voltage or temperature. A closely related measure is Availability, which is the probability a system can start operating at a random requested time, or the percentage of a total time interval it can be operated. A high reliability system may require multiple units in place, so that at least the minimum required number are available at a given time. An example is passenger airplanes, which require multiple engines for high reliability, in case one stops working.

4.7 Durability

Durability is how long a system can perform its intended function. It is typically measured in terms of service life. Service life of components, and of the system as a whole, is related to their maintenance. If not enough maintenance is performed, the life is reduced. 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. Durability is related to the economics concept of a Durable Good, one that yields utility over time rather than being consumed in one use. A passenger airplane has high durability, because it can operate for decades and tens of thousands of flights. The opposite of durability is consumption. The fuel used in the airplane is consumed (used only once), and is therefore not durable.

4.8 Quality

Quality is a measure of how well a system meets expectations. One aspect of quality is a measure of the lack of variability or defects in the design and manufacturing stages of the life cycle. Variability and defects increase the chance that performance will fall outside required levels. 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 large margin above those variations in effect reduces variability and increases quality.

4.9 Sustainability

Sustainability is the capacity of a system to endure. For example, does a system consume a scarce resource or generate a waste output that limits its long term use? If so, it is not sustainable over the long term, although it may last a desired system life. A current example is hydrocarbon fueled rockets. If obtained from fossil sources, they are both limited in supply, and cause unwanted change to the atmosphere. If they are produced as a biofuel, they can be sustainable.

4.10 Community

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.

4.11 Environment

Like community, these requirements relate to impact on the surroundings, but in this case the non-human portion. For space projects a key environmental requirement is to avoid contamination, either biological, chemical, or from radiation, both forward and backward from the ends of the mission.

4.12 Manufacturing

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 produce.

4.13 Testing

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.

4.14 Maintenance

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. So the various maintenance requirements are linked. Maintenance requirements can be divided into preventive, which is before something stops working, and corrective, which is after.

4.15 Flexibility/Adaptability

This is the ability of the system to adapt to new tasks or functions, or different performance levels for 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.

4.16 Scalability

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.

4.17 Evolution

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.

4.18 Usability

Usability requirements deal with the interface between humans and system elements. When a can be used without great amounts of planning, preparation, physical strain, or training it is said to have high usability.

4.19 Interoperation

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).

4.20 Openness

This is the degree to which a system is composed of proprietary or secret elements compared to open, public, or standard elements.

5. Functional Analysis

Once requirements have been developed to a certain level, 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.

5.1 Concept Identification

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.

5.2 Functional Diagrams

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.

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.

6. Requirements Allocation

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.

7. System Modeling

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.

7.1 Input/Output Model

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.

8. 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. 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.

9. Synthesis and Documentation

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.

9.1 Work Breakdown Structure (WBS)

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

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.

WBS by Subsystem Type

This example is a typical set of subsystems for space hardware, and also lines up with design specialties: