INCOSE Systems Engineering Handbook Chapter10.pdf

10 SPECIALTY ENGINEERING ACTIVITIES The objective of this chapter is to give enough information to systems engineers to appreciate the significance of various engineering specialty areas, even if they are not an expert in the subject. It is recommended that subject matter experts are consulted and...

10 SPECIALTY ENGINEERING ACTIVITIES The objective of this chapter is to give enough information to systems engineers to appreciate the significance of various engineering specialty areas, even if they are not an expert in the subject. It is recommended that subject matter experts are consulted and assigned as appropriate to conduct specialty engineering analysis. The topics in this chapter are covered in alphabetical order by topic title to avoid giving more weight to one topic over another. More information about each specialty area can be found in references to external sources. With a few exceptions, the forms of analysis presented herein are similar to those associated with SE. Most analysis methods are based on the construction and exploration of models that address specialized engineering areas, such as electromagnetic compatibility (EMC), reliability, safety, and security. Not every kind of analysis and associated model will be applicable to every application domain. 10.1 AFFORDABILITY/COST‐EFFECTIVENESS/ LIFE CYCLE COST ANALYSIS As stated in Blanchard and Fabrycky (2011), Many systems are planned, designed, produced, and operated with little initial concern for affordability and the total cost of the system over its intended lifecycle… The technical [aspects are] usually considered first, with the economic [aspects] deferred until later. This section addresses economic and cost factors under the general topics of affordability and cost‐effectiveness. The concept of life cycle cost (LCC) is also discussed. 10.1.1 Affordability Concepts Improving design methods for affordability (Bobinis et al., 2013; Tuttle and Bobinis, 2013) is critical for all application domains. The INCOSE and the National Defense Industrial Association (NDIA) (the Military Operations Research Society (MORS) has also adapted these definitions) have addressed “affordability” through ongoing affordability working groups started in late 2009 and have defined system affordability through these ongoing working groups. Both organizations have defined system affordability as follows: r INCOSE Affordability Working Group definitions (June 2011): Affordability is the balance of system performance, cost and schedule constraints over the system life while satisfying mission needs in concert with strategic investment and organizational needs. INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities, Fourth Edition. Edited by David D. Walden, Garry J. Roedler, Kevin J. Forsberg, R. Douglas Hamelin and Thomas M. Shortell. © 2015 John Wiley & Sons, Inc. Published 2015 by John Wiley & Sons, Inc. 211 For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 212 SPECIALTY ENGINEERING ACTIVITIES affordability analyses. As a result of these high‐level discussions, the key affordability takeaways include: Design for affordability is the systems engineering practice of balancing system performance and risk with cost and schedule constraints over the system life satisfying system operational needs in concert with strategic investment and evolving stakeholder value. r Affordability context, system(s), and portfolios (of systems capabilities) need to be consistently defined and included in any understanding of what an affordable system is. r An affordability process/framework needs to be established and documented. r Accountability (system governance) for affordability needs to be assigned across the life cycle, which includes stakeholders from the various contextual domains. r NDIA Affordability Working Group definition (June 2011): Affordability is the practice of ensuring program success through the balancing of system performance (KPPs), total ownership cost, and schedule constraints while satisfying mission needs in concert with long‐range investment, and force structure plans of the DOD. The concept of affordability can seem straightforward. The difficulty arises when an attempt is made to specify and quantify the affordability of a system. This is significant when writing a specification or when comparing two affordable solutions to conduct an affordability trade study. Even though affordability has been defined by the INCOSE, NDIA, and MORS, in discussions at an MORS Special Meeting on Affordability Analysis: How Do We Do It?, it was noted that all industry groups have discovered that affordability analysis is contextually sensitive, often leading to a misunderstanding and incompatible perspectives on what an “affordable system is.” The various industry working groups have recommended developing and formalizing affordability analysis processes, including recognizing the difference between cost and 10.1.1.1 “Cost‐Effective Capability” Is a Contextual Attribute As defined in “Better Buying Power: Mandate for Restoring Affordability and Productivity in Defense Spending” (Carter, 2011), “affordability means conducting a program at a cost constrained by the maximum resources the Department can allocate for that capability.” Affordability includes acquisition cost and average annual operating and support cost. It is expanded to encompass additional elements required for the LCC of a system, as an outcome of various hierarchal contexts in which any system is embedded. Therefore, in the SE domain, affordability as an attribute must be determined both inside the boundaries of the system of interest (SOI) and outside (see Fig. 10.1). This defines, in practical Design for affordability – Hierarchy of alternatives Cost vs. performance Cost vs. robustness st Co Co e st lu Va e lu Va System System of systems Uncertainty Uncertainty e Co st lu Va Portfolio of capabilities Affordability trade space Uncertainty Cost vs. relevancy FIGURE 10.1 Contextual nature of the affordability trade space. Derived from Bobinis et al. (2013) Figure 1. Reprinted with permission from Joseph Bobinis. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. AFFORDABILITY/COST‐EFFECTIVENESS/LIFE CYCLE COST ANALYSIS terms, the link between system capability, cost, and what we call “affordability.” Thus, the concept of affordability must encompass everything from a portfolio (e.g., family of automobiles) to an individual program (specific car model). Affordability as a design attribute of a system versus a program versus a domain remains contextually dependent on the stakeholder’s context and the life cycle of the SOI under examination. 10.1.1.2 Design Model for Affordability As previously stated, an affordability design model must be able to provide the ability to effectively manage and evolve systems over long life cycles. The derived requirements we will focus on in this section are as follows: r Design perspective that assumes the system will change based on environmental influences, new uses, and disabling system causing performance deterioration r Causes of system and system element life cycle differences (technology management) r Feedback functions and measurement of system behaviors with processes to address emergence (life cycle control systems) r A method to inductively translate system behaviors into actionable engineering processes (adaptive engineering) One of the major assumptions for measuring the affordability of competing systems is that given two systems, which produce similar output capabilities, it will be the Functions Requirements Priorities Reliability Maintainability Supportability 213 nonfunctional attributes of those systems that differentiate system value to its stakeholders. The affordability model is concerned with operational attributes of systems that determine their value and effectiveness over time, typically expressed as the system’s “ilities” or specialty engineering as they are called in this handbook. These attributes are properties of the system as a whole and as such represent the salient features of the system and are measures of the ability of the system to deliver the capabilities it was designed for over time. “System integration, and its derivatives across the life cycle, requires additional discipline and a long term perspective during the SE and design phase. This approach includes explicit consideration of issues such as system reliability, maintainability and supportability to address activities pertaining to system operation, maintenance, and logistics. There is also a need to address real‐world realities pertaining to changing requirements and customer expectations, changing technologies, and evolving standards and regulations” (Gallios and Verma, n.d.) (see Fig. 10.2). 10.1.1.3 Impact to Affordability Managing a system within an affordability trade space means that we are concerned with the actual performance of the fielded system, defined in one or more appropriate metrics, bounded by cost over time. (“System performance” can be expressed in whatever way makes sense for the system under study.) The time dimension extends a specific “point analysis” (static) to a continuous life cycle perspective (dynamic). Quantifying a relationship between cost, performance, and time defines a functional space Performance Inherent Availability Technical Effectiveness Operation Maintenance Logistics Process Efficiency System Effectiveness Operational effectiveness and readiness Cost as an independent variable (CAIV)/LCC FIGURE 10.2 System operational effectiveness. Derived from Bobinis et al. (2013) Figure 4. Reprinted with permission from Joseph Bobinis. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 214 SPECIALTY ENGINEERING ACTIVITIES that can be graphed and analyzed mathematically. Then it becomes possible to examine how the output (performance, availability, capability, etc.) changes due to changes in the input (cost constraints or budget availability). Hence, utilizing this functional relationship between cost and outcome defines an affordability trade space. Done correctly, it is possible to analyze specifically the relationship between money spent and system performance and possibly determine the point of diminishing returns. However, it is frequently necessary to estimate the value of one variable when the values of the others are known or specified. These kinds of point solutions (which in this sense are “coordinates” within the space) are useful in examining specific relationships, including making predictions of “average” behavior. Answering questions regarding “expected value” of some parameter in terms of others, often for specific points in time, frequently falls into this category. The overall trade space can then be thought of as the totality of all such point solutions. 10.1.1.4 Affordability Trade Space throughout the System Life Cycle The affordability trade space must reflect the SE focus on meeting operational and performance characteristics and developing highly reliable systems. Supportability analysis, which should be done in conjunction with design, is concerned with developing highly maintainable systems. These disciplines share a common goal: fielding robust, capable systems that are available for use by the end user when needed. Operational availability (Ao) is then simply another performance parameter that can be examined as a function of cost within this space. It is reasonable to conclude that improvements to the design, in this case driven by a stringent Ao requirement, can lower operation and support costs in the fielded system. In fact, Ao is an implicit performance measure used to calculate expected system effectiveness. That has to be applied, along with use/market size and operational requirements, to determine the overall cost‐ effective capability of the system under study. Supporting a system throughout its life cycle requires systems engineers to account for changes in the system design as circumstances change over time, such as changes in the threat environment, diminishing material shortage (DMS) issues, and improvements in technology, SoS relationships, and impact of variables outside the system. Given that designers do not control the variables in the environment, the optimization problem for affordability is different or could be different at any point in the life cycle. This optimization problem can be managed by functional criticality, surge, and adaptive requirements or as a set of predetermined technology refresh cycles. It can be optimized for cost or performance whichever is of most value. The intention is to be able to measure both as a function of operational performance efficiency. The affordability model must enhance value engineering (VE) analysis through the ability to measure all functional contributions to operational performance. The designer must be provided with the ability to choose the range of functions to adjust for optimal impact and cost. In all cases, the affordability trade space must be able to accommodate changes but always driven by the same key concepts: what does it cost to implement such a change, and what do we get for it. Consequently, identifying “cost‐effective capability” is still the key to analysis within the affordability trade space across the system life cycle. For instance, consider a system that is unique in the inventory but is suffering an unacceptably low Ao. Then the question arises, can we upgrade this system to improve field performance and do so in a cost‐effective way? Is it possible to improve the existing reliability and maintainability characteristics of this system and increase Ao, given that the system itself has many years of service life remaining? So the trade space analysis must show that the upgrades will pay for themselves over time through lower operation and support costs, increased capability, or both. In general, the factors that must be considered within the trade space across the system life cycle include: r Cost versus benefits of different design solutions r Cost versus benefits of different support strategies r Methods and rationale used to develop these comparisons r Ability to identify and obtain data required to analyze changes From a programmatic perspective, analysis of these alternatives must also be done in conjunction with identification, classification, and analysis of associated risk and development of a costed plan for implementation. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. AFFORDABILITY/COST‐EFFECTIVENESS/LIFE CYCLE COST ANALYSIS 215 Most bang for the budget Maximum budget Cost Affordable solutions “Best” value solutions (along the curve) Low cost wins Compliant solutions Performance Minimum performance FIGURE 10.3 Cost versus performance. Reprinted with permission from Joseph Bobinis. All other rights reserved. 10.1.1.5 Affordability Implementation When one considers the entire SOI, both the primary and enabling systems should be treated as an SoS. In the example in Figure 10.3, the mission‐effectiveness affordability trade space brings together primary and enabling systems into an SoS. Note that the SoS is treated as a closed‐loop system where requirements are modified as the mission needs evolve. These iterations allow for technology insertion as the design is updated. Design‐to‐cost (DTC) targets are set for the primary and enabling systems, which ensure that affordability throughout the system life cycle is considered, even as the system evolves. Affordability measurements that feed back into the system assessment are KPPs and operational availability, which ensures that the mission can be accomplished over time (e.g., those KPPs are met across the system life cycle; see Fig. 10.4). To define affordability for a particular program or system (see Fig. 10.3 as an example of an affordability range), we must define selected affordability components. As such, the following could be specified: 1. Required capabilities (a) Identify the required capabilities and the time phasing for inclusion of the capabilities. 2. Required capabilities performance (a) Identify and specify the required MOEs for each of the capabilities. (b) Define time phasing for achieving the MOEs. 3. Budget (a) Identify the budget elements to include in the affordability evaluation. (b) Time‐phased budget, either (i) for each of the budget elements or (ii) as the total budget. At least one of the affordability elements needs to be designated as the decision criteria that will be used in either a trade study or as the basis for a contract award. The affordability elements that are not designated as the decision criteria become constraints, along with the constraints being specified. This is illustrated by an example depicted in Figure 10.3. Here, the capabilities and schedule have been fixed leaving either the cost or the performance to be the evaluation criteria, while the other becomes the constraint. This results in a relatively simple relationship between performance and cost. The maximum budget and the minimum performance are identified. Below the maximum budget line lie solutions that meet the definition of “…conducting a program at a cost constrained by the maximum resources….” The solutions to the right of the minimum performance line satisfy the threshold requirement. Thus, in the shaded rectangle lie the solutions to be considered since they meet the minimum performance and are less than the maximum budget. On the curve lay the solutions that are the “best value,” in the sense that for a given cost the corresponding point on the curve is the maximum For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 216 SPECIALTY ENGINEERING ACTIVITIES Loop until cost targets are met Need/ threat environment WBS Cost Loop until cost targets and KPPs are met Loop until cost targets and A are met Technology what if the need changes? Or the threat? Req’s Design & production Engineering tool suite System capability Key performance parameters Does it answer the need? The mission effectiveness trade space with technology as a driver. What happens when technology changes? If the need or the threat environment changes? How calculate true cost of system capability? How calculate true cost of operational availability? How calculate true cost of mission effectiveness? Ops analysis tool suite Supportability design Logistics capability Operational availability Supportablity tool suite Fundamental equation of sustainment: A=R*M+S Mission effectiveness FIGURE 10.4 Affordability cost analysis framework. Derived from Bobinis et al. (2010). Reprinted with permission from Joseph Bobinis. All other rights reserved. performance that can be achieved. (Note: In the real world, the curve is rarely smooth or continuous.) Similarly, for a given performance, the corresponding point on the curve is the minimum cost for which that performance can be achieved. Selecting the decision criterion as cost will result in achieving the threshold performance. Similarly, if the decision criterion is performance, all of the budget would be expended. Consequently, to specify affordability for a system or program requires determining which affordability element is the basis for the decision criteria and which elements are being specified as constraints. Affordability is the result of a disciplined decision‐ making process—requiring systematic methodologies that support selection of the most affordable technologies and systems. 10.1.2 Cost‐Effectiveness Analysis As mentioned in the preceding section, a systems engineer can no longer afford the luxury of ignoring cost as an SE area of responsibility or as a major architectural driver. In essence, a systems engineer must be conversant in business and economics as well as engineering. Cost‐effectiveness analysis (CEA) is a form of business analysis that compares the relative costs and performance characteristics of two or more courses of action. At the system level, CEA helps derive critical system performance and design requirements and supports data‐based decision making. CEA begins with clear goals and a set of alternatives for reaching those goals. Comparisons should only be made for alternatives that have similar goals. A straightforward CEA cannot compare options with different goals and objectives. Experimental or quasiexperimental designs can be used to determine effectiveness and should be of a quality capable of justifying reasonably valid conclusions. If not, there is nothing in the CEA method that will rescue the results. What CEA adds is the ability to consider the results of different alternatives relative to the costs of achieving those results. It does not change the criteria for what is a good effectiveness study. Alternatives being assessed should address a common specific goal For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. AFFORDABILITY/COST‐EFFECTIVENESS/LIFE CYCLE COST ANALYSIS where attainment of that goal can be measured such as miles per gallon, kill radius, or people served. CEA is distinct from cost–benefit analysis (CBA), which assigns a monetary value to the measure of effect. The approach to measuring costs is similar for both techniques, but in contrast to CEA where the results are measured in performance terms, CBA uses monetary measures of outcomes. This approach has the advantage of being able to compare the costs and benefits in monetary values for each alternative to see if the benefits exceed the costs. It also enables a comparison among projects with very different goals as long as both costs and benefits can be placed in monetary terms. Other closely related, but slightly different, formal techniques include cost–utility analysis, economic impact analysis, fiscal impact analysis, and social return on investment (SROI) analysis. In both CEA and CBA, the cost of risk and the risk of cost need to be included into the study. Risk is usually handled using probability theory. This can be factored into the discount rate (to have uncertainty increasing over time), but is usually considered separately. Particular consideration is often given to risk aversion—the irrational preference to avoid loss over achieving gain. Uncertainty in parameters (as opposed to risk of project failure) can be evaluated using sensitivity analysis, which shows how results and cost respond to parameter changes. Alternatively, a more formal risk analysis can be undertaken using Monte Carlo simulations. Subject matter experts in risk and cost should be consulted. The concept of cost‐effectiveness is applied to the planning and management of many types of organized activity. It is widely used in many aspects of life. Some examples are: 1. Studies of the desirable performance characteristics of commercial aircraft to increase an airline’s market share at lowest overall cost over its route structure (e.g., more passengers, better fuel consumption) 2. Urban studies of the most cost‐effective improvements to a city’s transportation infrastructure (e.g., buses, trains, motorways, and mass transit routes and departure schedules) 3. In health services, where it may be inappropriate to monetize health effect (e.g., years of life, premature births averted, sight years gained) 217 4. In the acquisition of military hardware when competing designs are compared not only for purchase price but also for such factors as their operating radius, top speed, rate of fire, armor protection, and caliber and armor penetration of their guns 10.1.3 LCC Analysis LCC refers to the total cost incurred by a system, or product, throughout its life. This “total” cost varies by circumstances, the stakeholders’ points of view, and the product. For example, when you purchase an automobile, the major cost factors are the cost of acquisition, operation, maintenance, and disposal (or trade‐in value). A more expensive car (acquisition cost) may have lower LCC because of lower operation and maintenance costs and greater trade‐in value. However, if you are the manufacturer, other costs like development and production costs, including setting up the production line, need to be considered. The systems engineer needs to look at costs from several aspects and be aware of the stakeholders’ perspectives. In some literature, LCC is equated to total cost of ownership (TCO) or total ownership cost (TOC), but many times, these measures only include costs once the systems is purchased or acquired. Sometimes, it is argued that the LCC estimates are only to support internal program trade‐off decisions and, therefore, must only be accurate enough to support the trade‐offs (relative accuracy) and not necessarily realistic. By itself, this is usually a bad practice and, if done, is a risk element that should be tracked for some resolution of veracity. The analyst should always attempt to prepare as accurate cost estimates as possible and assign risk as required. These estimates are often reviewed by upper management and potential stakeholders. The credibility of results is significantly enhanced if reviewers sense the costs are “about right,” based on their past experience. Future costs, while unknown, can be predicted based on assumptions and risk assigned. All assumptions when doing LCC analysis should be documented. LCC analysis can be used in affordability and system cost‐effectiveness assessments. The LCC is not the definitive cost proposal for a program since LCC “estimates” (based on future assumptions) are often prepared early in a program’s life cycle when there is insufficient detailed design information. Later, LCC estimates should be updated with actual costs from early program stages For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 218 SPECIALTY ENGINEERING ACTIVITIES subsequent production units. For an item produced with a 90% learning curve, each time the production lot size doubles (2, 4, 8, 16, 32, … etc.) the average cost of units in the lot is 90% of the average costs of units in the previous lot. A production cost specialist is usually required to estimate the appropriate learning curve factor(s). r Utilization and support costs—Typically based on future assumptions for ongoing operation and maintenance of the system, for example, fuel costs, manning levels, and spare parts. r Retirement costs—The costs for removing the system from operation and includes an estimate of trade‐in or salvage costs. Could be positive or negative and should be mindful of environmental impact to dispose. and will be more definitive and accurate due to hands‐on experience with the system. A major purpose of LCC studies is to help identify cost drivers and areas in which emphasis can be placed during the subsequent substages to obtain the maximum cost reduction. Accuracy in the estimates will improve as the system evolves and the data used in the calculation is less uncertain. LCC analysis helps the project team understand the total cost impact of a decision, compare between program alternatives, and support trade studies for decisions made throughout the system life cycle. LCC normally includes the following costs, represented in Figure 10.5: r Concept costs—Costs for the initial concept development efforts. Can usually be estimated based on average manpower and schedule spans and include overhead, general and administrative (G&A) costs, and fees, as necessary. r Development costs—Costs for the system development efforts. Similar to concept costs, can usually be estimated based on average manpower and schedule spans and include overhead, G&A costs, and fees, as necessary. r Production costs—Usually driven by tooling and material costs for large‐volume systems. Labor cost estimates are prepared by estimating the cost of the first production unit and then applying learning curve formula to determine the reduced costs of Common methods/techniques for conducting LCC analysis are as follows: r Expert judgment—Consultation with one or more experts. Good for sanity check, but may not be sufficient. r Analogy—Reasoning by comparing the proposed project with one or more completed projects that are judged to be similar, with corrections added for known differences. May be acceptable for early estimations. Utilization and support costs Development costs Production costs Costs Retirement costs Concept costs Time Note: Notional cost profiles, not to scale FIGURE 10.5 Life cycle cost elements (not to scale). Derived from INCOSE SEH v1 Figure 9.3. Usage per the INCOSE Notices page. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. ELECTROMAGNETIC COMPATIBILITY r Parkinson technique—Defines work to fit the available resources. r Price to win—Focuses on providing an estimate, and associated solution, at or below the price judged necessary to win the contract. r Top focus—Based on developing costs from the overall characteristics of the project from the top level of the architecture. r Bottoms up—Identifies and estimates costs for each element separately and sums the contributions. r Algorithmic (parametric)—Uses mathematical algorithms to produce cost estimates as a function of cost‐driver variables, based on historical data. This technique is supported by commercial tools and models. r DTC—Works on a design solution that meet a predetermined production cost. r Delphi techniques—Builds estimates from multiple technical and domain experts. Estimates are only as good as the experts. r Taxonomy method—Hierarchical structure or classification scheme for the architecture. 10.2 ELECTROMAGNETIC COMPATIBILITY EMC is the engineering discipline concerned with the behavior of a system in an electromagnetic (EM) environment. A system is considered to be electromagnetically compatible when it can operate without malfunction in an EM environment together with other systems or system elements and when it does not add to Electric and electromagnetic environmental effects analysis EMC requirements (Standards and specifications) 219 that environment as to cause malfunction to other systems or system elements. When a system causes interference, the term electromagnetic interference (EMI) is often used. In EMC, the EM environment not only includes all phenomena and effects that are classically attributed to electromagnetics (such as radiation) but also electrical effects (conduction). Successfully achieving EMC during system development requires a typical SE process, as shown in Figure 10.6. 10.2.1.1 Electric and Electromagnetic Environmental Effects Analysis An electric and electromagnetic environmental effects (E4) analysis describes all the threats (natural and man‐made) that a system may encounter during its life cycle. MIL‐STD‐464C (DoD, 2010) can be used to guide this analysis, which should contain all the information needed to determine EMC requirements of the system. 10.2.1.2 EMC Requirements (Standards and Specifications) EMC standards and specifications are used to regulate the EM environment in which a system is operating. It usually governs both the system’s ability to function within its intended EM environment (sensitivity or susceptibility) and its contribution to that environment (emissions). Standards and specifications are available for conducted emissions, conducted susceptibility, radiated emissions, and radiated susceptibility. It is rare for a system to have custom‐developed EMC requirements that do not follow existing standards and specifications. However, existing standards and EMC design and implementation EMC qualification EMC engineering tests FIGURE 10.6 Process for achieving EMC. Reprinted with permission from Arnold de Beer. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 220 SPECIALTY ENGINEERING ACTIVITIES specifications (whether commercial, military, avionic, automotive, or medical) classify a requirement into a class or category depending on the severity of the potential malfunction. It is a SE function to determine the correct EMC requirements with class or category according to the outcome of the E4 analysis. 10.2.3.1 EMC Design and Implementation The EMC requirements are inputs to the concept and development stages. It is important that the EMC requirements are fixed at the beginning of physical design as the EMC design includes both mechanical and electrical/electronic hardware implementations that are not part of the other functional requirements. For any EMC design, it is best to follow a process of zoning, where a system is divided into zones that can easily be managed for EMC. Typically, major system elements are grouped together in zones that are low in emissions or of similar emissions. Very sensitive circuits (typically analog/measurement circuits) are grouped together and protected. The interfaces between zones are controlled. Where connections interface between zones, filters are used. Where there is a change in radiated interference, screening and/or physical separation is employed. A structured approach to the control of interference during the design stage of a system is to develop an EMI control plan. The EMI control plan typically includes all EMC requirements, zoning strategy, filtering and shielding, cabling, and detail mechanical and electrical design pertaining to EMC. 10.2.1.4 EMC Engineering Tests Prequalification tests may be required during the development stage. This is typically done on a system element level and even as low as single printed circuit board assembly level. Since EMC results are difficult to predict, the best way of ensuring design success is to test at lower system levels for compliance in order to maximize the probability of system compliance. 10.2.1.5 EMC Qualification EMC qualification tests are performed to verify the EMC design of a system against its requirements. The first part of this activity is to compile an EMC test plan, which maps each requirement to a test and test setup. The EMC test setup is an integral part of EMC SE as test results can vary according to the setup. This setup can be challenging as the system or system element under test must be in operational mode during emission testing and it must be possible to detect malfunctions during susceptibility testing. Interfacing with the system or system element must be done while not compromising the EM zone in which it is tested. This may require special system‐related EMC test equipment. When it is impractical to test a large system (such as a ship, aircraft, or complete industrial plant), the qualification tests of the system elements are used to qualify the larger system. 10.3 ENVIRONMENTAL ENGINEERING/ IMPACT ANALYSIS The European Union, the United States, and many other governments recognize and enforce regulations that control and restrict the environmental impact that a system may inflict on the biosphere. Such impacts include emissions to air, water, and land and have been attributed to cause problems such as eutrophication, acidification, soil erosion and nutrient depletion, loss of biodiversity, and damage to ecosystems (UNEP, 2012). The focus of environmental impact analysis is on potential harmful effects of a proposed system’s development, production, utilization, support, and retirement stages. All governments that have legally expressed their concern for the environment restrict the use of hazardous materials (e.g., mercury, lead, cadmium, chromium 6, and radioactive materials) with a potential to cause human disease or to threaten endangered species through loss of habitat or impaired reproduction. Concern extends over the full life cycle of the system, from the materials used and scrap waste from the production process, operations of the system replacement parts, and consumables and their containers to final disposal of the system. These concerns are made evident by the European Union’s 2006 resolution to adopt a legal restriction that system developers and their suppliers retain lifetime liability for decommissioning systems that they build and sell. The ISO 14000 series of environmental management standards (ISO, 2004) are an excellent resource for organizations of methods to analyze and assess their operations and their impacts on the environment. Failure to comply with environmental protection laws carries penalties and should be addressed in the earliest phases of requirements analysis (Keoleian and Menerey, 1993). The Øresund Bridge (see Section 3.6.2) is an example of For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. INTEROPERABILITY ANALYSIS how early analysis of potential environmental impacts ensures that measures are taken in the design and construction to protect the environment with positive results. Two key elements of the success of this initiative were the continual monitoring of the environmental status and the integration of environmental concerns into the requirements from the owner. Disposal analysis is a significant analysis area within environmental impact analysis. Traditional landfills for nonhazardous solid wastes have become less available within large city areas, and disposal often involves transporting the refuse to distant landfills at considerable expense. The use of incineration for disposal is often vigorously opposed by local communities and citizen committees and poses the problem of ash disposal since the ash from incinerators is sometimes classified as hazardous waste. Local communities and governments around the world have been formulating significant new policies to deal with the disposal of nonhazardous and hazardous wastes. One goal of the architecture design is to maximize the economic value of the residue system elements and minimize the generation of waste materials destined for disposal. Because of the potential liability that accompanies the disposal of hazardous and radioactive materials, the use of these materials is carefully reviewed and alternatives used wherever and whenever possible. The basic tenet for dealing with hazardous waste is the “womb‐to‐ tomb” control and responsibility for preventing unauthorized release of the material to the environment. This may include designing for reuse, recycling, or transformation (e.g., composing, biodegradation). In accordance with the US and European Union laws, system developers and supporting manufacturers must analyze the potential impacts of the systems that they construct and must submit the results of that analysis to government authorities for review and approval to build the system. Failure to conduct and submit the environmental impact analysis can result in severe penalties for the system developer and may result in an inability to build or deploy the system. It is best when performing environmental impact analysis to employ subject matter experts who are experienced in conducting such assessments and submitting them for government review. Methods associated with life cycle assessment (LCA) and life cycle management (LCM) are increasingly sophisticated and supported by software (Magerholm et al., 2010). Government acquisitions are subject to 221 legislation for Green Public Procurement (GPP) (Martin, 2010). Consumers of commercial products are offered assistance in their purchasing decisions through Environmental Product Declarations and labeling, such as the Nordic Swan, and Blue Angel (Salzman, 1997). Another effort in the ISO community is the development of a standard for product carbon footprints as an indicator of the global environmental impact of a product expressed in carbon emission equivalents (Draucker et al., 2011). 10.4 INTEROPERABILITY ANALYSIS Interoperability depends on the compatibility of elements of a large and complex system (which may be an SoS or a family of systems (FoS)) to work as a single entity. This feature is increasingly important as the size and complexity of systems continue to grow. Pushed by an inexorable trend toward electronic digital systems and pulled by the accelerating pace of digital technology invention, commercial firms and national organizations span the world in increasing numbers. As their spans increase, these commercial and national organizations want to ensure that their sunken investment in legacy elements of the envisioned new system is protected and that new elements added over time will work seamlessly with the legacy elements to form a unified system. Standards have also grown in number and complexity over time, yet compliance with standards remains one of the keys to interoperability. The standards that correspond to the layers of the ISO‐OSI Reference Model for peer‐to‐peer communication systems once fit on a single wall chart of modest size. Today, it is no longer feasible to identify the number of standards that apply to the global communications network on a wall chart of any size. Interoperability will increase in importance as the world grows smaller due to expanding communications networks and as nations continue to perceive the need to communicate seamlessly across international coalitions of commercial organizations or national defense forces. The Øresund Bridge (see Section 3.6.2) demonstrates the interoperability challenges faced when just two nations collaborate on a project, for example, the meshing of regulations on health and safety and the resolution of two power supply systems for the railway. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 222 10.5 SPECIALTY ENGINEERING ACTIVITIES LOGISTICS ENGINEERING Logistics engineering (Blanchard and Fabrycky, 2011), which may also be referred to as product support engineering, is the engineering discipline concerned with the identification, acquisition, procurement, and provisioning of all support resources required to sustain operation and maintenance of a system. Logistics should be addressed from a life cycle perspective and be considered in all stages of a program and especially as an inherent part of system concept definition and development. The emphasis on addressing logistics in these stages is based on the fact that (through past experience) a significant portion of a system’s LCC can be attributed directly to the operation and support of the system in the field and that much of this cost is based on design and management decisions made during early stages of system development. Furthermore, logistics should be approached from a system perspective to include all activities associated with design for supportability, the acquisition and procurement of the elements of support, the supply and distribution of required support material, and the maintenance and support of systems throughout their planned period of utilization. The scope of logistics engineering is thus (i) to determine logistics support requirements, (ii) to design the system for supportability, (iii) to acquire or procure the support, and (iv) to provide cost‐effective logistics support for a system during the utilization and support stages (i.e., operations and maintenance). Logistics engineering has evolved into a number of related elements such as supply chain management (SCM) in the commercial sector and integrated logistics support (ILS) in the defense sector. Further logistics engineering developments include acquisition logistics and performance‐ based logistics. Logistics engineering is also closely related to reliability, availability, and maintainability (RAM) (refer to Section 10.8), since these attributes play an important role in the supportability of a system. 10.5.1 Support Elements Support of a system during the utilization and support stages requires personnel, spares and repair parts, transportation, test and support equipment, facilities, data and documentation, computer resources, etc. Support planning starts with the definition of the support and maintenance concept (in the concept stage) and continues through supportability analysis (in the development stage) to the ultimate development of a maintenance plan. Planning, organization, and management activities are necessary to ensure that the logistics requirements for any given program are properly coordinated and implemented and that the following elements of support are fully integrated with the system: r Product support integration and management— Plan and manage cost and performance across the product support value chain, from the concept to retirement stages. r Design interface—Participate in the SE process to impact the design from inception throughout the life cycle. Facilitate supportability to maximize availability, effectiveness, and capability at the lowest LCC. Design interface evaluates all facets of the product from design to fielding, including the product’s operational concept for support impacts and the adequacy of the support infrastructure. Prior to the establishment of logistics requirements, logistics personnel accomplish planning, trade‐offs, and analyses to provide a basis for establishing support requirements and subsequent resources. These include support system effectiveness inputs to the system specifications and goals and integration of reliability and maintainability program requirements. Consideration of support alternatives and design into conceptual programs must be initiated at this early stage for effective problem identification and resolution. Logistics personnel conduct analyses to assist in identifying potential postproduction support problems and to contribute to possible LCC and support solutions. r Sustaining engineering—This effort spans those technical tasks (engineering and logistics investigations and analyses) to ensure continued operation and maintenance of a system with managed (i.e., known) risk. Technical surveillance of critical safety items, approved sources for these items, and the oversight of the design configuration baselines (basic design engineering responsibility for the overall configuration including design packages, maintenance procedures, and usage profiles) for the fielded system to ensure continued certification compliance are also part of the sustaining engineering effort. Periodic technical review of the For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. LOGISTICS ENGINEERING r r r r r r in‐service system performance against baseline requirements, analysis of trends, and development of management options and resource requirements for resolution of operational issues should be part of the sustaining effort. Maintenance planning—Identify, plan, fund, and implement maintenance concepts and requirements to ensure the best possible system capability is available for operations, when needed, at the lowest possible LCC. The support concept describes the support environment in which the system will operate. It also includes information related to the system maintenance concept: the support infrastructure, expected durations of support, reliability and maintainability rates, and support locations. The support concept is the foundation that drives the maintenance planning process. Establish general overall repair policies such as “repair or replace” criteria. Operation and maintenance personnel—Identify, plan, fund, and acquire personnel, with the training, experience, and skills required to operate, maintain, and support the system. Training and training support—Plan, fund, and implement a strategy to train operators and maintainers across the system life cycle. As part of the strategy, plan, fund, and implement actions to identify, develop, and acquire Training Aids, Devices, Simulators, and Simulations (TADSS) to maximize the effectiveness of the personnel to operate and sustain the system equipment at the lowest LCC. Supply support—Consists of all actions, procedures, and techniques necessary to determine requirements to acquire, catalog, receive, store, transfer, issue, and dispose of spares, repair parts, and supplies. This means having the right spares, repair parts, and all classes of supplies available, in the right quantities, at the right place, at the right time, at the right price. The process includes provisioning for initial support, as well as acquiring, distributing, and replenishing inventories. Computer resources (hardware and software)— Computers, associated software, networks, and interfaces necessary to support all logistics functions. Includes resources and technologies necessary to support long‐term data management and storage. Technical data, reports, and documentation— Represents recorded information of scientific or 223 technical nature, regardless of form or character (such as equipment technical manuals and engineering drawings), engineering data, specifications, and standards. Procedures, guidelines, data, and checklists needed for proper operations and maintenance of the system, including: – System installation procedures – Operating and maintenance instructions – Inspection and calibration procedures – Engineering design data – Logistics provisioning and procurement data – Supplier data – System operational and maintenance data – Supporting databases r Facilities and infrastructure—Facilities (e.g., buildings, warehouses, hangars, waterways, etc.) and infrastructure (e.g., IT services, fuel, water, electrical service, machine shops, dry docks, test ranges, etc.) required to support operation and maintenance. r Packaging, handling, storage, and transportation (PHS&T)—The combination of resources, processes, procedures, design, considerations, and methods to ensure that all system, equipment, and support items are preserved, packaged, handled, and transported properly, including environmental considerations, equipment preservation for the short and long storage, and transportability. Some items require special environmentally controlled, shock‐isolated containers for transport to and from repair and storage facilities via all modes of transportation (land, rail, sea, air, and space). r Support equipment—Support equipment consists of all equipment (mobile or fixed) required to sustain the operation and maintenance of a system. This includes, but is not limited to, ground handling and maintenance equipment, trucks, air conditioners, generators, tools, metrology and calibration equipment, and manual and automatic test equipment. 10.5.2 Supportability Analysis Supportability analysis is an iterative analytical process by which the logistics support requirements for a system are identified and evaluated. It uses quantitative methods to aid in (i) the initial determination and establishment of For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 224 SPECIALTY ENGINEERING ACTIVITIES r Physical definition—During system design, the physical breakdown structure of a system should be developed to assist in identifying the actual location of items in the system. This breakdown structure is used as baseline at various stages throughout the life cycle of the system, and it should be continuously updated and refined to the required level of detail. r Physical failure analysis—The physical breakdown structure is used as reference to perform hardware FMECA and/or FTA and RBD analysis with the objective of identifying all maintenance tasks for potential failure modes. The criticalities of failure modes are used to prioritize corrective and preventive maintenance task requirements. r Task identification and optimization—Corrective maintenance tasks are primarily identified using FMECA, while preventive maintenance tasks are identified using RCM. Trade‐off studies may be required to achieve an optimized maintenance strategy. r Detail task analysis—Detail procedures for corrective and preventive maintenance tasks should be developed, and support resources identified and allocated to each task. A LORA may be used to determine the most appropriate location for executing these tasks. r Support element specifications—Support element specifications should be developed for all support supportability requirements as an input to design; (ii) the evaluation of various design options; (iii) the identification, acquisition, procurement, and provisioning of the various elements of maintenance and support; and (iv) the final assessment of the system support infrastructure throughout the utilization and support stages. Supportability analysis constitutes a design analysis process that is part of the overall SE effort. Functional analysis is used to define all system functions early in the concept stage and to appropriate levels in the system hierarchy. The resulting functional breakdown structure, together with the system requirements and the support and maintenance concept, provides the starting point of a supportability analysis as shown in Figure 10.7. Supportability analysis may include analyses such as FMECA, fault tree analysis (FTA), reliability block diagram (RBD) analysis, Maintenance Task Analysis (MTA), RCM, and LORA. Products and activities identified in Figure 10.7 are described as follows: r Functional failure analysis—A functional breakdown structure is used as reference to perform functional FMECA and/or FTA and RBD analysis. These analyses can be used to identify functional failure modes and to classify them according to criticality (i.e., severity of failure effects and probability of occurrence). The functional failure analysis can also provide valuable system design input (e.g., redundancy requirements). Concept stage Production stage Development stage Utilization and support stages Retirement stage Support modeling and simulation System requirements Support and maintenance concept Functional definition Support test and evaluation Functional failure analysis Physical definition Physical failure analysis Task identification and optimization Recording and corrective action Detail task analysis Support element requirements Support deliverables FIGURE 10.7 Supportability analysis. Reprinted with permission from Corrie Taljaard. All other rights reserved. For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. MASS PROPERTIES ENGINEERING r r r r deliverables. Depending on the system, specifications may be required for training aids, support equipment, publications, and packaging material. Support deliverables—All support deliverables should be acquired or procured based on the individual specifications. Support element plans describing the management procedures for the support elements should also be developed. Support modeling and simulation—RAM and LCC modeling and simulation are integral parts of supportability analysis that should be initiated during the early stages to develop an optimized system design, maintenance strategy, and support system. Support test and evaluation—The support deliverables should be tested and evaluated against both support element specifications and the overall system requirements. Recording and corrective action—Failure recording and corrective action during the utilization and support stages form the basis for continuous improvement. System availability metrics should be used to continuously monitor the system in order to improve support where deficiencies are identified. 10.6 MANUFACTURING AND PRODUCIBILITY ANALYSIS The capability to manufacture or produce a system element is as essential as the ability to properly define and design it. A designed product that cannot be manufactured causes design rework and program delays with associated cost overruns. For this reason, producibility analysis and trade studies for each design alternative form an integral part of the architectural design process. One objective is to determine if existing proven processes are satisfactory since this could be the lowest risk and most cost‐effective approach. The Maglev train contractor (see Section 3.6.3) experienced a steep learning curve to produce an unprecedented system from scientific theory. Producibility analysis is a key task in developing low‐cost, quality products. Multidisciplinary teams work to simplify the design and stabilize the manufacturing process to reduce risk, manufacturing cost, lead time, and cycle time and to minimize strategic or critical material use. Critical producibility requirements are 225 identified during system analysis and design and included in the program risk analysis, if necessary. Similarly, long‐lead‐time items, material limitations, special processes, and manufacturing constraints are evaluated. Design simplification also considers ready assembly and disassembly for ease of maintenance and preservation of material for recycling. When production engineering requirements create a constraint on the design, they are communicated and documented. The selection of manufacturing methods and processes is included in early decisions. Manufacturing analyses draw upon the production concept and support concept. Manufacturing test considerations are shared with the engineering team and are taken into account in built‐in test and automated test equipment. IKEA® is often used as an example of supply chain excellence. IKEA® has orchestrated a value creating chain that begins with motivating customers to perform the final stages of furniture assembly in exchange for lower prices and a fun shopping experience. They achieve this through designs that support low‐cost production and transportability (e.g., the bookcase that comes in a flat package and goes home on the roof of a car). 10.7 MASS PROPERTIES ENGINEERING Mass Properties Engineering (MPE) ensures that the system or system element has the appropriate mass properties to meet the requirements (SAWE). Mass properties include weight, the location of center of gravity, inertia about the center of gravity, and product of the inertia about an axis. Typically, the initial sizing of the physical system is derived from other requirements, such as minimum payload, maximum operating weight, or human factor restrictions. Mass properties estimates are made at all stages of the system life cycle based on the information that is available at the time. This information may range from parametric equations to a three‐dimensional product model to actual inventories of the product in service. A risk assessment is conducted, using techniques such as uncertainty analysis or Monte Carlo simulations, to verify that the predicted mass properties of the system will meet the requirements and that the system will operate within its design limits. MPE is conducted at the end of the production stage to assure all parties that the For INCOSE member, Corporate Advisory Board, and Academic Council use only. Do not distribute. 226 SPECIALTY ENGINEERING ACTIVITIES delivered system meets the requirements and then several times during the utilization stage to ensure the safety of the system, system element, or human operator. For a large project, such as oil platform or warship, the MPE level of effort is significant. One trap in MPE is believing that three‐dimensional modeling tools can be exclusively used to estimate the mass properties of the system or system element. This is problematic because (i) not all parts are modeled on the same schedule