Selected Works on the Application of Systems Engineering to the Commercial Aviation Domain Scott Jackson, PhD Burnham Systems Consulting Greater Los Angeles Area
[email protected] 1-949-726-2003 1 January 2018 Report BSC-2018-01
Preface This report is a collection of works prepared by the author over several years in his work in systems engineering for commercial aircraft. This report can be considered a companion document to the book Systems Engineering for Commercial Aircraft – A Domain-Specific Adaptation, Second Edition, published by Ashgate Publishing Ltd in 2015. The individual chapters are available for general distribution and are not held under any copyright protection. However, references to its contents should be properly acknowledged. In the years prior to the publication of this report, Dr. Jackson was under contract to both Embraer and COMAC. However, none of the material in this report was produced under either of those contracts. This document is a work in progress. Readers are encouraged to comment and ask questions. Updates will be provided on a periodic basis. Some of the contents have been previously published on ResearchGate.com and on Academia.edu. The author’s ORCID number is 0000-0003-3386-4561. Some articles have been published as conference papers for the International Council on Systems Engineering (INCOSE). The primary author on two of the papers was Wellington Oliveira of Embraer of Brazil.
Biography Scott Jackson, PhD is Principal Engineer with Burnham Systems Consulting in the Greater Los Angeles area. He has worked in various capacities on systems engineering for Boeing, NASA John Glenn Center, Embraer of Brazil, COMAC, the Commercial Aircraft Company of China, Nanjing University, and Beihang University. He is a corresponding member of the Commercial Aviation Safety Team (CAST). He is a Fellow of the International Council on Systems Engineering (INCOSE) and a member of the International Society for the Science of Systems (ISSS). His book Systems Engineering for Commercial Aircraft – A Domain-Specific Adaptation, Second Edition, was published by Ashgate Publishing Ltd in 2015. This book is available in both English and Chinese. The first edition was published in 1997. He holds a BS in Aeronautical Engineering from the University of Texas (at Austin), an MS from UCLA in engineering, and a PhD from the University of South Australia.
Contents 1. Systems Engineering for Commercial Aircraft: The Vision 2. Systems Engineering for Commercial Aircraft (a summary of the 2015 book) 3. Voice of the Customer 4. Checklist for Procurement Specifications 5. A Systems Approach to Developing the New Aircraft (a summary of a chapter in the book published by Ashgate and edited by Rod Baldwin) 6. Adapting Systems Engineering to the Development of Regional Jets (Olivera and Jackson) 7. Developing Quality Aviation Systems through Rigorous Specification Development (Olivera and Jackson)
Chapter 1 Systems Engineering for Commercial Aircraft: The Vision An aircraft, including the pilot, is a system, that is a collection of parts that act together (the principle of holism) to achieve a stated purpose, that is, to deliver passengers and cargo to a destination safely and economically. The parts acting together achieve powered flight. The aircraft, including the pilot, is part of a larger system called the world aviation system. Even the aircraft with pilot and passenger loaded can’t achieve its purpose without the support of enabling subsystems like the navigation system, the ground support system and the loading and unloading support system. To accomplish the purpose, the parts must individually be qualified by test, demonstration, analysis or inspection to achieve its performance level and constraints, such as electromagnetic interference (EMI) and durability, and environments during all phases of the life cycle to include purchase, deployment, operation, support, and retirement. The qualification of the parts must also include the interaction among the parts (the principle of interactions). Stakeholders for the aircraft include, at a minimum, the airline customers, the passengers, the aircraft manufacturer, and the regulatory agencies. The airline customers will define the minimum expected performance and cost goals. The regulatory agencies will establish the minimum acceptable safety levels. The aircraft manufacturer will demonstrate compliance with these safety levels (the process of certification). Definition of the aircraft to achieve both performance and certification levels requires the coordinated and integrated efforts of all technical and managerial organizations. Technical efforts include the definition and qualification of all parts of the aircraft including the interaction among the parts. The definition of each part includes the development of requirements for all life cycle phases. These requirements are the result of a flow-down of requirements from the aircraft level (the principle of hierarchy). Aircraft level requirements are the result of analysis and trade-offs of customer needs. This task is normally the product of the advanced design organization. Lower level requirements are the result of flow-down and derivation of requirements at lower levels of the aircraft hierarchy. The requirements data base that results from the parts requirements analysis is a major deliverable for the certification of the aircraft. The requirements data base is normally a product of the systems engineering organization with inputs from design engineering and other technical organizations, such as the reliability organization, the production organization, and the maintenance organization. Design engineering also identifies the appropriate verification method for each requirement and assigns the methods to the appropriate organizations, such as the test organization. The safety organization plays a major role in establishing safety levels. The net result of the requirements effort described above is quality requirements specifications without which a quality aircraft cannot be designed or built. The quality specification defines both the parts of the aircraft and the relationship of each part with all other parts, without which the aircraft as a whole entity cannot be defined. An inadequately defined single part or interface can result in an inadequately defined aircraft which may not meet its performance or certification goals. Managerial efforts include program management to assure that all technical and managerial functions are performed and performed together in an integrated way to achieve
the aircraft purpose. Hence, integration is required for both the aircraft and the organization. Program management is also responsible for tracking technical and managerial risks and identifying and executing mitigation steps. Managerial efforts also include negotiations with airline customers to determine customer needs and to convert these needs into aircraft level product requirements. These needs typically include range, speed, operating cost, durability and other needs such as dispatch reliability. Managerial efforts also include management of the supply chain to include allocation of requirements to the suppliers and contractual supplier tasks (the supplier statement of work) and to validate supplier verification tasks. The contracts organization plays a major role in establishing contracts with suppliers which address both technical requirements and supplier tasks. In summary, the vision is that systems engineering of a commercial aircraft is an integrated effort from a product (the aircraft) point of view, the technical effort point of view, the managerial point of view and the organizational point of view. All of the above are required to define a quality aircraft.
Chapter 2 Systems Engineering for Commercial Aircraft: A Domain-Specific Adaptation (2nd Edition) *
This book is an elaboration of the 2015 eponymous book. The 2015 book can be ordered from Ashgate from the following site: http://www.ashgate.com/isbn/9781472439215 The table of contents is as follows: Contents Acknowledgements Figures and tables Preface 1 Introduction 1.1 Definition of a system 1.2 Definition of systems engineering 1.3 Historical background 1.4 Overview of this book 1.5 Roadmap for applying systems engineering to commercial aircraft 1.6 Summary of themes 2 Commercial aircraft 2.1 The commercial aircraft industry 2.2 Levels of SE application 2.3 Aircraft architecture
2.4 Advanced technologies on aircraft 2.5 Aircraft manufacturing processes 2.6 Trends in commercial aviation 3 Functional analysis 3.1 The SE life-cycle functions 3.2 Aircraft system level functions 3.3 Aircraft level functions 3.4 Functional aspects of safety 3.5 The cluster model 3.6 The swim lane model 4 Requirements and needs 4.1 Requirements definition 4.2 Requirements types 4.3 Requirements development 4.4 Requirements sources 4.5 Requirements allocation to system elements 4.6 Derived requirements 4.7 The principle of top-down allocation 4.8 Requirements trade-offs 4.9 Requirements categories for certification 4.10 Requirements validation 4.11 Avoiding requirement creep 5 Constraints and specialty requirements 5.1 Regulatory requirements 5.2 Mass properties 5.3 Dimensions 5.4 Reliability 5.5 Human factors 5.6 Environments 5.7 Maintainability 5.8 Design standards 5.9 Emitted noise 5.10 Emitted electromagnetic interference (EMI) 5.11 Cost 5.12 Transportability 5.13 Flexibility and expansion 5.14 Producibility 6 Interfaces 6.1 Functional interfaces 6.2 Physical interfaces 6.3 External interfaces 6.4 Internal interfaces 6.5 Operational interfaces 6.6 Interface management 6.7 The interface control drawing (ICD) 6.8 Development fixtures (DFs) 6.9 The N2 diagram 6.10 Interface requirements 6.11 Interface verification 7 Synthesis 7.1 Aircraft architecture 7.2 Initial concept 7.3 Trade-off studies 7.4 Quality function deployment (QFD)
7.5 Safety features 7.6 Introduction of new technologies 7.7 Preliminary design 8 Top-level Synthesis 8.1 The aircraft system 8.2 Top-level aircraft sizing 8.3 Other top-level requirements 8.4 System architecture 8.5 Top-level constraints 8.6 Economic constraints 8.7 Top-level trade-offs 9 Subsystem Synthesis 9.1 Environmental segment 9.2 Avionics segment 9.3 Electrical segment 9.4 Interiors segment 9.5 Mechanical segment 9.6 Propulsion segment 9.7 Auxiliary segment (ATA 49) 9.8 Airframe segment 9.9 Allocation to software 9.10 Subsystem constraints 10 Certification, Safety, and Software 10.1 Certification 10.2 Safety 10.3 Software development and certification 10.4 Commercial Aviation Safety Team (CAST) 10.5 Failure rate history 11Verification and Validation 11.1 The verification matrix 11.2 Traditional SE verification 11.3 Verification of regulatory requirements 11.4 Verification of customer requirements 11.5 Verification sequence 11.6 System validation 11.7 Qualification 12 Systems engineering management and control 12.1 Management Responsibilities 12.2 The Chief Systems Engineer 12.3 Integrated product development (IPD) 12.4 Design reviews 12.5 Documentation 12.6 Automated requirements tools 12.7 Technical performance measurement (TPM) 12.8 Software management 12.9 Supplier management 12.10 Configuration management 12.11 Integration planning 13 Adapting Systems Engineering to the Commercial Aircraft Domain 13.1 Adapting the process 13.2 Adapting the process to the existing organization 14Large-Scale System Integration 14.1 The system of systems view 14.2 Outsourcing 14.3 Complexity and how it increases risks
14.4 Managing the risks of a large-scale system 14.5 Other large-scale system principles to apply to commercial aircraft 14.6 Summary 15Risk Management 15.1 Overview of risk management 15.2 Types of consequences 15.3 Root causes of risks 15.4 Risk mitigation steps 15.5 Issues 15.6 Independent review 15.7 The risk management process 15.8 Risk management tools 15.9 Opportunities 15.10 Challenges for risk management 16 Resilience of the Aircraft System 16.1 The history of resilience 16.2 The definition of resilience 16.3 Is resilience measureable? 16.4 Design rules and example solutions 16.5 Other rules 16.6 A final word on interdependency Final comments Appendix 1The mathematics of reliability allocation A1.1 Basic reliability A1.2 Allocation for generically similar components A1.3 Allocation for generically different components A1.4 Redundancy A1.5 The whole airplane Appendix 2 Example supplier specification outline A1.0 Scope A2.0 Applicable documents A3.0 Requirements A3.1 Functional and performance requirements A3.2 Interface requirements A3.3 Design and construction A3.4 Documentation A3.5 Precedence of requirements A3.6 Major component characteristics A4.0 Verification A5.0 Preparation for delivery A6.0 Notes A10.0 Appendices Appendix 3 Systems engineering automated tools A3.1 Features of automated SE tools A3.2 Benefits of automated SE tools Bibliography Acronyms, Abbreviations, and Symbols Glossary Index
Chapter 3 Voice of the Customer The following points are a summary of key aspects of eliciting and implementing customer and stakeholder needs for commercial aircraft. • According to Wikipedia (2017) Voice of the Customer (VOC) is a term used to “to describe the in-depth process of capturing customer's expectations, preferences and aversions.” This document will describe how those needs are captured and flowed down into the system hierarchy and documented in procurement specifications. A popular tool for capturing and implementing VOC is quality function deployment (QFD) to be discussed later. • Customer requirements are sometimes called customer needs for the simple reason that that they cannot be verified as part of the verification program like product requirements, even though they may be quantitative. Sometimes they may be called customer requirements. Even so, they will be considered needs in the current context. Customer expectations and aversions can be considered to be parts of customer needs. • The Voice of the Customer process applies to a broader range of interested persons and organizations called stakeholders. The point is that the needs of the stakeholders should be taken into account at all phases of the development process. The FAA Systems Engineering Manual (SEM) (2014) does not have a comprehensive list of stakeholders; however, it mentions many of them in the text, such as operations, maintenance, management, NASA, DoD, DHS, DOT, other project teams, outside organizations, test and evaluation, supplier management, and suppliers. • Customer needs are usually solicited from the customer by organizations outside engineering such as Marketing or Customer Engineering. For this reason Marketing and Customer Engineering personnel need to be trained by Systems Engineers on how to solicit needs. • The key events at which stakeholder needs are taken into account are the design reviews, often called decision gates. The decision gates are considered reviews but more important than reviews, decision gates are considered as a milestones too because the decision gates address the following questions: o Does the project deliverable still satisfy the business case? o Is it affordable? o Can it be delivered when needed? These questions allow the OEM to make major decisions, such as, modify the aircraft, change the contract, make schedule modifications, and so forth. Jackson (2015) (pp. 170-175) provides a summary of the major design reviews. • A common way to capture customer operational requirements is through the operational requirements document (ORD). The elements of the ORD as specified by Blanchard and Fabrycky (2006) (pp. 59-60) are as follows: o Operational distribution – where will the system be used? Siberia, Saudi Arabia, etc.? o Mission profile or scenario - describes the “dynamic” aspects of a mission. Landing, take off, etc.? o Performance and related parameters - How well must the system operate? Temperature, pressure, lightning, etc.?
•
•
•
WEIGHTING
•
WHATs
•
o Utilization Requirements - describes the duty cycles of operation. How many take offs and landings per day? o Effectiveness Requirements - describe reliability, maintainability, etc. requirements. Dispatch reliability is important to airline customers. o Operational life cycle - describes the total life cycle requirements, that is, the durability. Very important, describes resistance to metal fatigue or delamination. o Environment - describes the environment in which it will operate: temperature, altitude, etc, These operational requirements will be treated as customer needs as described above and entered into DOORS or other data base. The key principle of soliciting needs is that needs should be separated from solutions. Customers often see their needs in terms of solutions, so the challenge for Marketing, or other organization, is to determine the true needs the customer is trying to express. o As an example, one customer asked for an extra door in the cargo department. After continued questioning it turned out that the customer’s true need was additional ventilation. This revelation allowed the OEM the opportunity to explore other ways to provide ventilation. Needs can be documented in traditional report format or in modern tools such as DOORS (Dynamic Object Oriented Requirements System). One advantage of DOORS is that the customer needs can be linked to the top-level system (aircraft) requirements. DOORS also allows the requirements to be mapped to the aircraft architecture. Component procurement specifications can be created directly from DOORS. DOORS is structured so that for each architectural element of the aircraft, the following information can be recorded: o The name and level of the element o The performance requirement (or the customer need) o The functional requirement o Constraints o The verification method So using the above information the customer need can be linked to the performance requirement at the appropriate level of the aircraft architecture. The organization responsible for converting customer needs into top-level requirements is known in most companies as Advanced Design. The conversion from customer needs to top-level product requirements will require considerable trade studies involving initial estimates of the aircraft’s weight, performance and other characteristics. This organization can then flow these requirements down (either allocated or derived) to subsystem organizations, such as Avionics. (In FAA terminology these sub-systems are known as systems.) A popular way to convert customer needs to product requirements is the Qualify Function Deployment (QFD) process. Some aspects of QFD are as follows: o It is much faster than tradition trade study processes. + + HOWs o QFD must not be regarded as a scientific process. It is more accurate to call it an intuitive process. If the results are not intuitively correct, then it would be SCORES better to try an alternative approach. o However, QFD is extremely transparent; that is, it is FILTERING RANKING easy to see what needs are driving the system design. The house of quality o An overview of the QFD process can be found on pp. 100-102 of Jackson (2015).
•
•
•
•
•
o It is not advisable to conduct a QFD analysis as an individual; a group setting will result in a more acceptable solution. o QFD can either be applied to the aircraft as a whole or to a subsystem of the aircraft. In practice the latter is probably more common. Referring to the figure on the right, following is a brief summary of the QFD process: o Whats – This is the starting point of the QFD process. The Whats are the customer and stakeholder needs. In a group setting they can be listed in a column and mixed together. It is important to remember not to put solutions in this column. Quantitative requirements will be treated as needs as described above. o Hows – These are quantitative requirements that may be affected by the Whats. o Weighting – These are the relative importances of the Whats. Any scale may be used. Assigning weights to the Needs is a way of prioritizing the stakeholder need. o Scores – Normally a non-linear scale is used to show how each What pertains to a How. The scale of 1-3-5 is common as described below: ▪ 5 indicates a direct relation between a What and a How. ▪ 3 indicates and indirect relation between a What and a How. ▪ 1 indicates a slight relation between a What and a How. o Filtering is simply the sum of the product of the Scores and Weightings. o The Roof indicates the need for a trade-off between two requirements when there is a conflict. o Ranking – This is simply the ranking of the Filtering scores to show which requirements are really necessary. If a score is really low, it can be eliminated from consideration. o If the House of Quality is used as the top-level of system, the process for the next level can be worked by using the Rankings as the Whats. o Once the requirements have been established from the QFD process, they can be entered into the DOORS tool for formal processing. From the sub-system level the requirements can be flowed to individual components for which procurement specifications are written. The separate document called Procurement Specification Checklist can be used to determine the completeness of the requirements in those documents. This checklist will assure that component requirements can be traced to the customer needs. For requirements in specifications the paper by Carson (2015) reflect the policy by Boeing and is also the accepted way to capture requirements. The requirements in this policy reflect the completeness criteria in the Procurement Specification Checklist above. Note that this paper is copyright protected. In addition to the airline customer, there are also other stakeholders whose needs need to be satisfied. These include the FAA and the CAAC in China. For the FAA and CAAC the primary need is safety. The Specification Checklist shows how the safety needs can be incorporated into the component design. Since safety is a stakeholder need, it will be a the top level and all component requirements will trace to it. There are other stakeholder needs such as noise limits, both internal and external. Regarding top-level product (aircraft) requirements there are two that are of particular importance. They trace to the stakeholder needs of total aircraft life and safety. They are durability and EMI (electromagnetic interference). These are important because of the difficulty of verifying compliance and the difficulty of implementing them. o Regarding durability there are very few aircraft that have ever been built that have not experienced metal fatigue in the structure. It has been suggested that
•
•
composite structures may avoid these failures, but composite structures have difficulties of their own. o Regarding EMI this is a neglected requirement also. There are EMI standards, but specification writers often forget to include them. In addition, there is the consideration that the distances between EMI sources and vulnerable components, such as data lines, should be documented and incorporated in the requirements. Regarding customer needs there are other needs that are not at the top of the aircraft hierarchy of components. These can be called special needs. The reader is referred to the Vee model on page 47 of Jackson (2015). So let’s say that the customer has a special need at the component level rather than the aircraft level. The key point is that the Systems Engineering organization must assure that the requirement for that component do not violate the aircraft level requirements, such as weight, range, and so forth. Two examples are described below. o One customer had a special need for a shower on the aircraft. While not an impossible request from an engineering point of view, this need added an addition demand on the water system on the aircraft. The OEM in this case had to consider the impact on such parameters as aircraft weight, range, c. g. (center of gravity), payload capacity, and so forth. Hence this is an example of a special need having an impact on top level requirements. o Another customer had a special need for a coffee pot in the galley of a particular brand. When the aircraft was in flight the coffee pot exploded. This incident illustrates the necessity first of focusing on needs rather than solutions, and secondly the necessity of determining whether particular solutions are in violation of airworthiness requirements. Finally there is the issue of system validation. You may need to review the difference between system validation and requirements validation. Requirements validation confirms that the system (product) requirements are correct. System validation confirms that the customer is satisfied with the product. System validation normally occurs when the aircraft has been built and the customer has test flown the aircraft. The customer compares the aircraft against the needs that were originally documented. If the delivered aircraft is overweight (which often happens), the customer may require monetary compensation. (Note: The FAA SE Manual does not explain this difference very well.)
Acknowledgements: The author acknowledges the comments and suggests of Professor Sean Pan in China, Ricardo Moraes in Brazil, and Dr. Benjamin Wu in the United States for material related to this chapter. Blanchard, Benjamin, and Wolter J. Fabrycky. 2006. Systems Engineering and Analysis. Edited by Wolter J. Fabrycky and J. H. Mize. 4th ed, Prentise Hall International Series in Industrial and Systems Engineering. Upper Saddle River, NJ: Prentise Hall. Original edition, 1981. Carson, Ronald S. 2015. "Implementing Structured Requirements to Improve Requirments Quality (copyrighted)." IS 2015, Seattle, 15 July. FAA. 2014. FAA Systems Engineering Manual. edited by Kimberly Gill. Washington, DC: Federal Aviation Administration. Jackson, Scott. 2015. Systems Engineering for Commercial Aircraft: A Domain Specific Adaptation. Edited by Guy Loft. Second ed. Aldershot,, UK: Ashgate Publishing Limited. Textbook. VOC. 2017. "Voice of the Customer." Wikipedia, accessed 30 December. https://en.wikipedia.org/wiki/Voice_of_the_customer.
Discussion: This document was created at the request of Professor Pan at Beihang University. Burnham Systems has waived fees for this task. If other universities, companies, or government agencies wish to have an elaboration on these points, Burnham Systems is open to a contractual arrange at the standard rates. Comments and questions regarding the above text are welcome. Subsequent versions may appear as a result of these comments and questions. Scott Jackson, PhD, Principal Engineer
Chapter 4 Procurement Spec Checklist Caveat: The situations and recommendations discussed in this paper are entirely hypothetical. They do not represent processes or products of any particular organization or any particular domain, either military or civilian. Although the references cited in this paper pertain to the commercial aviation domain, the recommendations can apply to any domain. Readers of this paper may copy and circulate it as they wish. Clarification of this list will be provided without charge. Responses to more detailed questions may be billable. The question is often asked: What is the minimum essential task that Systems Engineering (SE) should accomplish when resources are limited? The answer is simple: SE should review all procurement specifications (specs) (both performance and build-to) and supplier contracts and report any recommendations to management (both SE management and design management). The material in this document can be used either as training material for design engineers or for the SE organization for their review purposes. The concepts and terminology in this paper are consistent with the FAA Requirements Engineering Management Manual (2009) except as noted in this paper. Two types of items are discussed. The primary type is a new item being designed and installed on a system. In this case all of the review items should be examined for applicability. The second type is an aircraft modification either for a customer need, to replace a failed item, or to replace an item that has become obsolete. In these cases all of the review items may not be applicable. For aircraft modifications the reader may want to tailor the checklist based on the risks reflected in Figure 13.1 of Jackson (2015). This tailoring will be discussed later in this paper. This paper also discusses hybrid specs, that is specs for which both a suggested solution and a performance requirement are specified. Rationale: The paper Oliveira and Jackson (2016) points out that the procurement spec is the final product in the SE process. It contains all information required to make a quality product (subsystem, component, etc.) and that it is the combination of all of these products that make a quality system. The SE understands how the requirements, constraints, and verification methods cited in the spec are developed by flow down from higher levels of the system hierarchy. Spec authors very rarely have much training in SE. The book Jackson (2015, p. 195) states that it is a primary responsibility of the SE organization to “review supplier specifications for completeness and accuracy.” These two sources taken together form the basis of this paper. In FAA (2009) a supplier is called a subcontractor. The premise of this note is that all requirements given to a supplier in the procurement spec are complete, that is, they will be sufficient for the supplier to design an item, either a subsystem or a component of an aircraft. That has been found to the true for all requirements except Safety requirement as will be explained in Section (4) of this list. For Safety requirements, some degree of design has to be completed by the supplier before the final detailed requirements can be identified. In this case the aircraft manufacturer must update the spec before the supplier can begin the final design of the item. The Spec Review So what does the SE review the spec for? Following are a few examples. This list is divided into two groups. The first group is called the first-level review, that is, information that can be gathered without reading any further documents are asking the spec author any questions. The second-level review demands further investigation and may not be necessary or feasible.
The types of specs discussed in this paper are generally called Development Specs, also called Type B specs, as defined by the FAA (2014, pp. 82-83) systems engineering manual. Part 1 - Item Type 1 – New Items Being Designed and Installed on the Aircraft First-Level Review: (1) Does the spec have at least one performance requirement? Discussion: SE principles agree that all components should have at least one performance requirement. Depending on perspective this viewpoint may not apply to structural components. Performance requirements should be phrased in the form of “The [item] shall provide at least TBD level of performance in the specified environment.” FAA (2009, pp. 45-51) summarizes ways to capture performance requirements and states that although the traditional way to specify requirements is by means of statements, requirements can also be expressed by figures and tables. Whatever way is chosen the method will have to be compatible with the format of the configuration database. (2) Does the spec reference the environment of the item over the full flight cycle? Discussion: The flight cycle should include the period between take-off and landing and should include other flights such as training flights, etc. In short the spec should cover all environments the aircraft is expected to encounter in its operational life. FAA (2009, pp. 22-27) explains how to identify environments. (3) Does the spec contain any constraints, such as human factors, dimensions, durability, etc.? EMI (electromagnetic interference) is an often neglected constraint. All electrical components and data links should contain at least one reference to EMI. All structural components should contain at least one reference to durability. Discussion: There may be hundreds of constraints covered in this category. EMI and durability are mentioned because they are two requirements most neglected in the commercial aircraft domain. FAA (2009, pp. 36-42) explains how to describe and specify system constraints. (4) Does the spec address all Safety requirements? Safety requirements can be found in ARP 4754A (SAE 2010), the FAA Systems Engineering Manual (FAA 2014), and the FAA Requirements Engineering Management Manual (FAA 2009). According to 4754A (SAE 2010) there are six types of analysis and assessments that may be performed by the aircraft manufacturer before the spec is written and provided to the supplier. They are as follows: a. The functional hazard assessment (FHA) b. The common cause analysis (CCA) which includes he zonal safety analysis (ZSA) and the probabilistic risk assessment (PRA) c. The common mode analysis (CMA) d. The fault tree analysis (FTA) e. The preliminary system safety assessment (PSSA) f. The failure modes and effect analysis (FMEA) The outputs of these analyses and assessments fall into six categories that are direct inputs to the spec. These categories are: a. Dimensional constraints (size, volume, shape, etc.) b. Environmental constraints (qualification to operate in specific temperature, pressure, vibration, EMI, etc.) This is usually applied to system components and fluids.
c. Measurement requirements (monitoring aspects: temperature, pressure, vibration, position, etc.) d. Data requirements (temperature, pressure, vibration, displays, etc.) e. Interfaces (inter-monitoring between signal provider(s) and users, fault alerts between two or more systems in order to establish a health-monitoring, timing, rate, speed, pressure, protocols, etc.) f. Functional aspects (independence requirements, fault detection/correction capabilities, annunciation of failures, safety interlocks which may be logical or mechanical/safeguards, etc.) (5) Does the spec contain interface requirements? Discussion: This category covers both physical and functional interfaces. If the item in question interacts with any other item both physically or functionally, it should be covered. This item does not cover undesirable interactions such as EMI. Those are covered in item (3) above. FAA (2009, p. 13) describes interfaces. (6) Is the spec free of solutions? An ideal spec only documents requirements. It is up to the supplier to design the item to meet the requirements. Discussion: Although this item is logical, it is one most neglected in the commercial aircraft domain. It is tempting to insert in the spec aspects of the design. This insertion should be avoided for the simple reason that inserting design characteristics in the spec may cause conflicts within the spec. FAA (2009, p. 45) explains that design decisions should be left out of the requirements specification. (7) Is the spec free of task statements? These are the responsibility of the supplier contract. Discussion: This is similar to item (5). The spec should not have any statements such as “The designer shall . . .” in it. The function of the spec is to explain what he item should do, not what the designer should do. FAA (2014, p. 183) explains that the requirements spec and the statement of work (SOW) are two completely different products and should be treated separately. (8) Is the supplier contract free of technical requirements? They are the responsibility of the spec. Discussion: It is not the responsibility of the supplier contract to provide technical requirements. The contract should be focused on the design task. For example, the contract should not say, “The supplier shall design an item of TBD kw.” Rather the supplier contract should say, the “The supplier shall design a TBD item. The performance requirements can be found in the spec.” The reason for this is that the contract does not contain a verification table. That can be found in the spec.” (9) Does the supplier contract reference the spec? Discussion: See item (7) for why the spec should be referenced in the contract. (10) Does the supplier contract specify who performs the verification tasks (analysis, etc.)? Discussion: It is important for the contract to state who performs the verification tasks, such as test. It is either the supplier or the aircraft company. (11) Does the supplier contract specify who validates the verification results?
Discussion: it is important for the contract to state who verifies the test results. If the supplier performs the test, for example, the aircraft company should reserve the right to validate that the test results were correct. (12) Does the spec have a verification table? Discussion: This table states how each verification method should be performed. It must be remembered that for certification, test will be the most common verification method. (13) What is the next higher level requirement from which the requirement in the spec is derived (or flowed down)? Discussion: A basic principle of SE is that all systems can be viewed as a hierarchy. A component is part of a larger subsystem or assembly. So the requirement for the component can be derived from the requirement for the larger subsystem. For example, a brake pad is a component which is part of the entire brake system. So the energy which a pad must absorb can be derived from the energy which the entire brake system must absorb. [See Notes.] Report to Management It is the responsibility of the SE to report the results of the First Level spec review to management. This report may be very brief, for example, one page. Management should include both SE management and design management, that is, the management of the group that wrote the spec. If either management decides not to act on the review, that is their responsibility. A typical review item might be as follows: (1) This spec has no performance requirements. (2) This spec does not specify the environment. Recommendations may be as follows: (1) A performance requirement should be formulated and inserted in the spec. (2) An environmental reference should be inserted. Second-Level Review If first-level reviews are well-received, a second level review is recommended. Second-level reviews cover topics for which additional questions are required. Following are typical second-level review topics: (14) What is the function from which the performance requirement was derived? Discussion: All experienced SEs know that all performance requirements are derived from functions. A typical function is “The pump shall provide hydraulic pressure.” The performance requirement is “The pump shall provide TBD of hydraulic pressure.” FAA (2009, pp. 27-33) explains how to develop the functional architecture. (15) What is the system (aircraft) level requirement from which the current requirement is derived? Discussion: Continuing with the example of the brake pad from item (1) above the system level requirement is the stopping distance of the aircraft. (16) Are the requirements achievable? that is, do they present risks when not achieved? Discussion: The answer to this question will depend mostly on the final design. If it is known, for example, that the aircraft cannot stop on a 1000
(17)
metre wet runway, there will be a risk and the requirements and the design must be revisited. Are there conflicts among the requirements? How are the conflicts resolved? Discussion: Returning to the example of the brake pads, the requirements for the energy the pads must absorb may conflict with the requirements for the space allocation for the brake system. Redesign may be required.
Updates As pointed out in Item (4) above it is normal for the aircraft manufacturer to provide updates to the requirements in the spec after it has been sent to the supplier especially when Safety is concerned. This is because certain Safety analyses cannot be conducted until after some design of the procured items has been accomplished. In practice the same is true of nonSafety requirements. The aircraft manufacturer may provide updates to the spec after initial design has been accomplished. Notes on Second Level View Item (1): Hierarchy. First the reviewer and all engineers should understand the principle of hierarchy, that is, the concept that all systems, for example an aircraft can be viewed in layers. The aircraft itself is the top layer and other subsystems are lower level layers. The component itself can be called layer N. The layer above it, for example, a subsystem is layer N+1. So the question is: if the requirement is at layer N, what is the requirement at layer N+1 from which the first requirement was derived or flowed down? Ultimately all requirements should trace to the aircraft level, layer by layer. The requirements at both layer N and N+1 and all other layers should be in the configuration data base. Derivation and Flow Down. Much of Chapter 4 of Jackson (2015, pp. 53-58) explains how requirements are flowed down or derived. That is, if you know a requirement for layer N+1, how do you determine the requirement for layer N? The task in this review list is to do just the opposite: If you know the requirement at level N, what is the requirement at layer N+1? That is, you are working up rather than down. There are several methods of derivation and flowing down. We will review them right here. Derivation. In the example above we showed how the energy requirement for a single brake pad could be derived from the energy to be absorbed by the entire brake system. So in this review we want to show that the requirement for the brake pad was derived from the requirement for the entire brake system. This process can be followed for many different requirements. Allocation. Many lower level requirements are allocated from higher level requirements including weight and reliability. So this review question is asking: If the reliability of the component is X, what is the reliability of the entire subsystem? This can be done by standard reliability equations. Direct Flow Down. Many requirements do not change when they are flowed down from one layer to the other. Durability is one. So if the durability of the component is known, it may be the same as for the entire subsystem or the entire aircraft. Part 2 - Item Type 2 – Aircraft Modification - Items Being Designed and Installed on an Aircraft to Replace an Existing Item There are three typical situations in which aircraft are modified to install new items. In all three cases the check list above may be modified or shortened prepare the spec: (1) Situation 1 – The customer is requesting a new capability or perhaps a regulatory agency has mandated a new capability. This situation demands that all 17 review items be examined for compliance. For example, (a) The new item will have a new performance capability that was not
documented in any existing specification. This new performance capability will have to be included in the new spec to be created as in Review Item (1). (b) Since the new item will be installed in an existing aircraft, the interfaces and interactions must be documented as in Review Items (3) and (5). FAA (2009, p. 42) discusses the need to consider how the new item may interface with legacy equipment and how this interface may affect the system architecture. (c) Are Safety requirements complete as in Review Item (4)? (2) Situation 2 - A prior item has failed In this case the number of review items may be reduced to the 17 above. However, all review items should be examined for applicability. The first step is to examine why the prior component failed. Here are two examples: (a) The prior component failed because the environmental conditions were exceeded. In this case Review Item (2) should be re-examined to assure that the correct environmental conditions are included. As an example, the pitot tube may experience a higher than expected temperature. As another example, the item may not have been designed to the extreme temperatures in the nacelle. (b) The prior component failed because its design was inadequate. In this case many Review Items should be examined for compliance; of particular importance are performance in Review Item (1). In addition Review Items (2), (3), (11), and (12) are of particular importance. This case also assumes that a spec exists for the previous component. That being the case, it is of utmost importance to review the previous spec for Review Items (1) through (17). NB: It is not sufficient to assume that requirements in the prior spec are correct. All requirements must be re-examined for validity. (3) Situation 3- The prior item is no longer available because the supplier has either gone out of business or has decided not to make that item any more. This may be the simplest case since a specification exists for the prior component. Once again, it is not sufficient to assume that all the requirements in the previous spec are correct. They should all be reviewed in accordance with Review Items (1) – (17) for correctness. The reviewer should pay particular attention to items (3) and (5) for interactions and interfaces. For example, if the replacement item contains any electrical components, compliance with EMI requirements are paramount. Part 3 - Tailoring the Checklist for Aircraft Modifications The reader may wonder why it is necessary to consult the entire checklist when the item being designed is replacing an item that has worked well in the past and has had no problems. This could be called a low-risk situation. In this case the reader is advised to consult Figure 13.1 in Jackson (2015). This is a notional figure that shows that steps can be eliminated from the SE process, for example, the checklist discussed in this paper, without incurring excessive risk. For readers who do not have the book, the figure is shown here. This tailoring is not discussed in FAA (2009). Nevertheless, spec tailoring is widely practiced in industry.
R ISK
Typical situations are as follows: (1) The intended replacement item is identical to the item being replaced. (2) There are no anticipated changes in performance of the replacement item. (3) There are no anticipated changes in interfaces. (4) There are no anticipated changes to the environment. SE STEPS PERFORMED (5) There are no anticipated changes to the constraints. In these situations the tailoring may be significant. Some of the possible tailoring is as follows: (1) No changes to physical constraints (2) No changes to performance requirements (3) No changes to interfaces (4) No changes to environment (5) No changes to other constraints (6) No need to perform traceability to customer requirements (this is a major tailoring step) (7) No need to perform functional analysis Caution: This section on tailoring should not be taken as a reason to sacrifice rigor. All of the above considerations should be analysed thoroughly and the entire checklist should be invoked when changes have been made. Part 4 – Hybrid Specs A hybrid spec is a spec that is part performance and part build-to and is far more common in industry than one might expect. This type of spec is appropriate when the developer (for example, the aircraft manufacturer) has a specific performance in mind but also has a solution or at least a part of a solution in mind. Hybrid specs are not discussed in FAA (2009). Nevertheless hybrid specs are common in industry. When this situation occurs, the developer and the spec writer should keep the following principles of spec writing in mind: (1) As a general rule, hybrid specs should be avoided. If there are both performance requirements and design solutions, the performance requirements should prevail and the supplier’s solution should be the preferred solution. (2) The build-to part of the spec and performance part of the spec must not be in conflict, that is to say, the item designed by the developer must be able to meet all performance requirements and constraints appropriate to the item. (3) The build-to part of the item must at a minimum comply with all physical characteristics and constraints of the item. (4) The build-to item must be capable of performing the performance requirements of the item. (This may be the most challenging principle) (5) The performance part of the item must still be checked against the 17 checklist items listed above and furthermore must not conflict with the physical aspects of the buildto item. (6) When the build-to part of the spec conflicts with the performance part of the item, it is usually preferable to let the supplier design the item rather than presenting a build-to solution to them.
Summary I hope this suggested review process is helpful. Please contact me if you have any comments or suggestions for improvements to this review process. Work has already begun on a third edition to the 2015 book listed below. The above review list may appear as an appendix to that edition. Scott Jackson, PhD References FAA. 2009. Requirements Engineering Management Manual. In NexrGen and Operations Plannning, edited by David L. Lempia and Stephen P. Miller. Wasington, DC: Federal Aviation Administration. FAA. 2014. FAA Systems Engineering Manual. edited by Kimberly Gill. Washington, DC: Federal Aviation Administration. Jackson, Scott. 2015. Systems Engineering for Commercial Aircraft: A Domain Specific Adaptation. Edited by Guy Loft. Second ed. Aldershot,, UK: Ashgate Publishing Limited. Textbook. Oliveira, Wellington, and Scott Jackson. 2016. "Developing Quality Aviation Systems through Rigorous Specification Development " Regional Mini-Conference, Los Angeles, April 10 SAE. 2010. Guidelines for the Development of Civil Aircraft and Systems ARP4754A. edited by John Dalton: Society of Automotive Engineers.
Chapter 5 A systems approach to developing the new aircraft Scott Jackson, PhD Chapter in the book
Developing the Future Aviation System Edited by Rod Baldwin The book is available from the following web site: http://www.ashgate.com/isbn/9780291398437 Following is a summary of the book: •
•
The major changes taking place in technology have some of the greatest effect in the world of aviation. Yet, in an industry which started with the concept of 'open skies', each sector has traditionally developed on its own and adjusted to developments in other areas as and when required. The need for integration is particularly important as the skies become increasingly crowded. More intense commercialization dramatically increases the interlocking between technological developments and the size of the financial investments required. For maximum efficiency the aviation system thus has to develop as an integrated whole with a greater awareness of events in other sectors. This book is intended to meet this requirement by addressing the breadth and depth of the aviation system and looking at some areas where significant advances are happening. While following the processes of development, the reader will see where the results might lead in the new century. Its three parts concentrate on areas of great significance – in integration as well as in technological progress – especially for their impact on human and social aspects. The editor and the invited contributors are amongst the foremost experts, researchers and industry leaders in their fields in the global aviation community, many with hands-on experience of massive change. The intended readership includes those who are moving into management functions in air traffic management, airplane manufacturing and airline operations; in training centres, colleges and institutions. Contents: New Concepts for Aircraft and Airports: A systems approach to developing the new aircraft; New generation airports; The airport business and information technology; Airport security. Human Factors and Training: Human Factors in the cockpit; Laws for the design of the Universal cockpit displays; Creating a culture of safety; Human Factors in Air Traffic Control; Training issues in Air Traffic Flow Management. Managing the Aviation System: The Air Traffic Management System – present and future; Improving capacity – implementation of the FANS CNS/ATM system in the Asia/Pacific region; The new IATA international passenger liability regime; Developments in aircraft interior design
Chapter 6 Adapting Systems Engineering to the Development of Regional Jets Wellington Martins de Oliveira Embraer S.A. São José dos Campos, Brazil
[email protected] Scott Jackson, PhD Burnham Systems Consulting Los Angeles, California, USA
[email protected] Copyright © 2014 by Wellington Oliveira and Scott Jackson . Published and used by INCOSE with permission.
Abstract. Regional jet developers, like those for mainline jets, must strive to meet the needs of their customers while complying with rigid regulatory requirements. These are the dual challenges of the commercial aircraft domain. To meet these goals, developers face factors both in the industrial context and in the operational demands of these jets which require judicious adaptation of the systems engineering process to this domain. These demands result from a more severe life cycle environment compared to mainline jets and from factors which give regional jets an advantage in their target market. This adaptation requires the developer to consider the risks associated with the selection of which systems engineering processes are most critical to the successful development of an aircraft Systems engineering aspects receiving special treatment in this paper include the treatment of requirements to deal with the severe life cycle environment and with requirements creep, the existence of large numbers of requirements, many of which may be in conflict. A second area of focus is the discussion of organizational responsibilities and how each department within an aircraft company, whether technical or not, may understand their role in systems engineering.
Introduction Many sources, such as (INCOSE 2010) have documented the systems engineering methodology for adding rigor to the engineering and associated management processes for the creation of systems, such as commercial aircraft. The System Engineering Body of Knowledge (SEBoK) edited by (Pyster 2012) elaborates on the systems engineering concept and defines three types of systems engineering: First product systems engineering (PSE) deals with the systems engineering of products such as commercial aircraft. Next, enterprise systems engineering (ESE) has to do with an entire enterprise, such as a commercial aircraft enterprise. Finally, service systems engineering (SSE) has to dos with the systems engineering of a system of services, such as the maintenance of an aircraft. Both ESE and SSE place systems engineering in the realm of “soft systems” as defined by (Checkland 1999). For the most part, these sources are domain-independent, that is, the principles described in them can apply to any domain, such as aircraft, rail, energy and so forth. In
addition, they provide a complete description of systems engineering without any significant adaption to a particular domain. With regard to the commercial aircraft domain, the Society of Automotive Engineers (SAE 1996) published a set of guidelines focused on the certification of commercial aircraft. These guidelines included a number of systems engineering aspects, especially functional analysis. Next, (Jackson 1997) describes the complete systems engineering process in the terms of the parameters of the commercial aircraft domain. This book also provides guidance relative to the adaptation of the systems engineering process to the commercial aircraft domain. This book is available in both English and Chinese. Next, the Federal Aviation Administration (FAA 2014) published a complete manual that describes systems engineering process as applied to the commercial aircraft domain. Once again, this is a complete manual that does not address adaptation, or tailoring, of the process. Next, the Society of Automotive Engineers (SAE 2010) published an update to their previous document. This latter document provides a sound framework for applying systems engineering in the commercial aircraft domain from which adaptation can be considered. Finally, (Jackson 2015) is an extensive second edition of the prior work which treats adaptation in more detail. This book also discusses supply chain management in the context of systems engineering. This discussion falls more into the realm of enterprise systems engineering (ESE) discussed above. This book also provides guidance on how all departments in a typical aircraft organization can understand their role in systems engineering whether or not they are a technical or managerial department. This is a topic not normally treated in the systems engineering literature. Many aspects discussed in this paper apply to both regional and mainline jet development. For example, supply chain management is a universal issue. Regional jet manufacturers are unique in several respects. More importantly, regional jets have a more severe life cycle environment than mainline jets performing far more takeoffs and landings than mainline jets. In addition to the more severe environment, the designers of regional jets can take advantage of the fact that the market for these aircraft is smaller, secondary airports. The need for smaller aircraft bodies allows for a more efficient seat arrangement.
Adaptation To execute all the process in a manual such as the FAA Systems Engineering Manual (FAA 2014) might be perceived as an onerous and burdensome task. (Jackson 2015) provides guidance on how these processes can be performed more efficiently without sacrificing quality. For example, requirements can be screened to determine which requirements are important and which ones can be ignored. The essence of requirements screening is risk, that is, the risk of ignoring requirements. (Jackson 2015) also suggests ways to reduce the costly and time consuming process of design reviews. In short, all SE processes can be streamlined if appropriate attention is given to the risk of streamlining them. The following section discusses adaptation to minimize requirements creep. In this context the risk of adaptation can normally be measured in terms of cost, either the cost overrun in the design and production or the cost of a catastrophic failure.
Requirements and Requirements Creep The commercial aircraft domain suffers from a plethora of requirements, often called requirements creep. Whether other domains suffer from this phenomenon is not clear, but certainly this domain does. First, almost every component on an aircraft has at least one functional or performance requirement. Most of the sources listed above explain how to create this requirement; the functional or performance requirement results from the function
the component must perform, regardless of whether the component is a valve or a flight control module According to (Wasson 2006), requirements should be minimally sufficient to specify and bound the user’s intended operational needs. A common tendency is to specify design details rather than its function. The practice often occurs when requirements are specified in terms of past design solutions that have proved acceptable even though they may not be adequate for the new design. The preferred approach is to have a rigorous design process starting with functional and performance requirements. However, to rely on performance requirements alone would violate a basic systems engineering principle, the principle of holism. Holism holds that all the components must be defined concurrently, that is, within the same analysis. Otherwise, defining one component in isolation would be reductionism, which most authorities, for example, (Checkland 1999) view as not the development of a true system, but rather a collection of objects with no true unity. For example if you designed a component on the performance requirement alone and forgot the constraints, you would get an incomplete design. Similarly you cannot design a component based on constraints alone. You must also consider the interface requirements between the components. Yes, if the two components are at the same level of system hierarchy and are subordinate to the same parent system, they will have the same parent requirement. Requirements for Severe Operation Conditions - The requirements process starts with the performance requirements. Every system element, that is, a component or subsystem, has a performance requirement. This requirement is derived from the element’s function and has special importance for regional jets. The performance requirement has the traditional form: The [system element] shall perform the [TBD requirement] under [specified conditions]. It is the “specified conditions” that give this requirement it importance. This is because of the severe operational conditions that regional jets encounter in their life cycle compared to mainline jets. In addition to the increased durability requirements mentioned above, the increased cycling of all the components of the aircraft must be taken into account. Even subsystems, such as the cargo loading system, must take the increased cycling into account. These are the “specified conditions”. Durability - A salient requirement in the regional jet domain pertaining to the severe operational condition is durability. The question is how many takeoffs and landings can the aircraft make before cracks begin to appear in the structure or before composite structures begin in delaminate? The reason this requirement is important is because regional jets make far more takeoffs and landings than mainline jets, as many as a factor of 10 or more. Another reason this is important is because metal fatigue and composite delamination are notoriously difficult to predict. For composite structures the issue is delamination, which is also difficult to predict. Either way, the only path to having a durable aircraft is to use the best data and the best prediction methods available and then add a good design margin. Other than the structure, other parts of the aircraft are affected by the increased landings and takeoffs. The most notable example is the wheels and brakes. As mentioned above, even the cargo loading system is affected by the severe life cycle. Another aspect affected by the more severe life cycle is the current trend towards leasing aircraft components as described by Jackson (2015). It is important to assure that these leased components have been qualified to the same severe life cycle as other components. In addition, it cannot be assumed in the verification by similarity process that a leased component used on a mainline aircraft, such as an actuator or a pump will automatically verify the requirement.
An issue on regional jets is whether commercial off-the-shelf (COTS) equipment used on mainline jets can also be used on the regional jets. The reason this is an issue is that COTS equipment on mainline jets have often been qualified in less severe environments. Hence, it is incumbent on the regional jet developer to assure that the COTS equipment will survive and perform as well as it did on mainline jets. Screening of Requirements - The rest of the requirements are called constraints; they emanate from many sources, for example, production, maintenance, operations, safety, interfaces, and so forth. There may be dozens or perhaps even hundreds of possible constraints. The saving grace is that not all of Exterior them apply to every component. For example, if Requirements: the component does not have any software, then Production, Requirements Operations, System A the constraint of software standards do not apply. Flow-down Maintenance, etc. The result of so many constraints in addition to the functional and performance requirements is Subsystem Subsystem that many of them may be in conflict with each A1 A2 Interface other. Figure 1 shows how this can happen. Let’s Requirements say we are designing Subsystem A1 or Figure 1 Conflicting Requirements Subsystem A2. The performance or functional requirements flow down from System A. It is the same with the constraints; the durability requirements are established at the System A level. The same requirement also applies to Subsystems A1 and A2. This flow down may occur in various ways; for example, some constraints, such as maintainability may be allocated to the various subsystems, such as A1 and A2. The constraints at the second level may also be derived whenever there is a solution posed at the top level. For regional jets the implementation of some constraints may different from that for mainline jets. For example, the smaller size of the aircraft will limit the options for electrical wire spacing to comply with EMI requirements. In addition, the options for component spacing to comply with common cause analysis (CCA) requirements will be limited. The Resolution of Conflicting Requirements - Conflicting requirements can be resolved in several basic ways as discussed by (Jackson 2015): • Linear addition – The requirements can be added together. • Modeling – Sometimes computer models exist that will show how the different requirements interact • Weighting – Some requirements will affect the design more than others. • Absolute limits – Some requirements will be constrained by quantitative limits. • Reallocation – Requirements can be reallocated; reliability and weight are examples. So the question at hand is; how do you know which constraints are important and which ones can be ignored? There are two answers to this question. The first answer has to do with the physical characteristics of the subsystem. For example, as stated above, if the subsystem has no software components, the software standards can be ignored. If there are no electrical components or no data links, then EMI (electromagnetic interference) constraints can be ignored. The second answer to this question has to do with risk, that is, the risk of ignoring a constraint. So the question has to be asked, if this constraint is ignored, is there a possibility of a serious consequence? The best person to answer this question is the technical specialist. Figure 2 is a notional diagram having to do with deleting systems engineering steps, in this case, deleting constraints. The idea is that in the end the supplier specification, for example, will have only the most essential constraints, not the entire list.
Risk
The final question associated with the issue of requirements creep is who makes these decisions? The suggestion is that the minimum number of people be involved in this process. The technical specialist (for each specialty) and the systems engineer may be enough. Requirements and the Supply Chain - The commercial aircraft domain is heavily supply chain driven both for regional jet manufacturers and for mainline jets. The reasons are manifold; among them is the fact that the makers of primary components, such as engines, are located in many different countries. The second is manufacturing components is a factor in the negotiations for buying and selling aircraft. Jackson (2015) provides a comprehensive list of other reasons. That book also discusses the risks associated with an over-extended Figure 2 Adaptation of the SE stepsEngineering performed supply chain also known as outsourcing. Since regional jet Systems Process companies are generally smaller, the supply chain factor puts an extra strain on them. While the following discussion does not provide any new approach to dealing with the supply chain, compliance with the basic principles is paramount to the goal of achieving a quality product and reducing the risks associated with it. The first point is that supply chain management is a combination of both technical and managerial processes that are inextricably complementary. Treating them as separate processes may lead to excessive risk. The technical process is, of course, providing the suppliers with precise and high quality requirements to which they can design a product. The managerial process is the contract that explains what they are expected to do. Figure 3 illustrates these two processes and how they connect the supplier to the developer. Figure 3 also shows the connection between the first level supplier and the second level supplier which is just as important. Figure 3 Multi-tier Supplier Relations Although in most organizations different departments write contracts and technical requirements, the important thing here is that they must be written in close cooperation so that there is no overlap of function or conflicts between them. The following rules should prevail: • Contracts, in particular the statement of work (SOW), should state precisely what work is to be done. There should be no technical requirements embedded in the contract. The reason is that technical requirements in the contract cannot be verified. • Specifications should state what the technical requirements are on the products. There should be no implied work statements in the specification. The reason is that tasks embedded in the specification cannot be priced for the contract. Although the above rules may seem obvious, the complexities of organizational processes often prevent them from being executed as well as they might be. A particularly difficult task is specifying high-quality requirements for the second-tier suppliers. Normally, the first-tier supplier would be responsible for writing these requirements and first-tier suppliers do not often understand the rigor required in writing these requirements. To mitigate the risk of poor quality requirements for the second-tier supplier, the developer should retain the right to review and correct the second-tier specifications.
Organizational Roles A subject not frequently treated in the literature is what the specific roles of departments within a commercial aircraft organization are with respect to systems engineering. (Jackson 2015) provides a comprehensive discussion of these roles from a generic organizational point of view. Since most companies will have specific organizational functions in common, this discussion should apply to most organizations regardless of whether they are manufacturers of regional jets or larger jets. The point not always appreciated is that almost all departments, whether technical or managerial have some role in systems engineering. Following are a few of the salient organizations and their roles: Program Manager – The most important roles of the Program Manager is to assure all organizations understand their roles in systems engineering and perform them as required whether they are traditionally technical organizations or managerial.. The Program Manager is responsible for understanding all program level risks and assuring that they are properly addressed. Since the Program Manager oversees both technical and managerial functions, it is paramount that the Program Manager be able to see and act on technical risks that may have cost or schedule impacts, and vice versa. Chief Engineer – The Chief Engineer is responsible for assuring the participation of the technical functions, for tracking the technical metrics, and taking action. Design Engineering – All Design Engineering departments are responsible for writing the specifications pertaining to their product, collecting all functional, performance, and constraint requirements, and resolving all conflicts between these requirements. In addition, they are responsible for assigning verification methods and confirming the verifications performed by suppliers and within the company. Design Engineering is responsible for conducting trade-offs to fit the best design balanced between the requirements needs on each hierarchical level with the aim of avoiding “optimum local” solutions driven by a predominant discipline. Marketing – This is a department that may not consider itself to have a role in the systems engineering process. However they have an important role in collecting customer requirements, expressing them in an acceptable form, and providing them to Advanced Design or Design Engineering. For regional jets customer requirements may be different from those for mainline jets. For example, the size and characteristics of airports and the desired ranges may be different. The main difference is that regional jets make more flights per day. This increased flight frequency makes aircraft functions more time constrained. Customer Engineering has an important role in the development of regional jets. As the organization responsible for defining support operations during the product life cycle, Customer Engineering is responsible for defining the requirements for life cycle operations. As described by (Carson and Sheeley 2012), top level functions provide the basis for requirements related to operational scenarios. Customer Engineering works closely with the airline operators to determine the operational functions in terms of the environmental conditions. These functions are helpful in determining the maintainability and operability requirements for self-fault diagnosis. Advanced Design – This department has the primary responsibility for the top level requirements, the flow down to lower levels, and the architecture of the aircraft. • Systems Engineering – Finally, Systems Engineering is the one department that often does not exist in traditional commercial aircraft organizations. This department has the most important role in overseeing the systems engineering process. In addition, it oversees the risk management and requirements screening. The FAA Systems Engineering manual (2014) outlines the roles of Systems Engineering. These roles include such activities as
conducting a life cycle analysis, functional analysis, safety assessment, and requirements analysis, among others. These roles are largely advisory in nature. However this paper suggests two roles that can have immediate and tangible benefit to the program: First, Systems Engineering can be given the responsibility for conducting reviews of supplier specifications. As discussed below, this responsibility will have the direct effect of significantly reducing the duration and cost of conducting design reviews. Secondly, Systems Engineering can be given the primary role of requirements screening. This responsibility promises to provide significant improvement in the quality of supplier specifications and the products that result from them. In short, the added responsibilities of the Systems Engineering organization promise to reduce cost and provide significant improvement in product quality. Other departments have important roles, for example, Procurement, Test, Configuration Management, Production, Flight Operations, Maintenance, and so forth. The important point is that participation by all departments is necessary for the successful execution of systems engineering.
Design Reviews Design reviews are a standard part of systems engineering that often perceived to be onerous and time consuming. This paper does not advocate the elimination of these design reviews but rather the execution of steps to make them more efficient. With respect to requirements, and most design reviews involve requirements, the process can be made much more efficient by a thorough review of requirements, led by and conducted by the Systems Engineering organization, before or even instead of a regular design review. These off-line requirements reviews would include, for example, the examination of the validity of the requirements, the correct flow down of the requirements, correct derivation of requirements, the correct screening of requirements, and the resolution of the conflicts among requirements. The Systems Engineering department can conduct similar off-line reviews for other aspects of the systems engineering process including verification, trade studies, and so forth.
Conclusions The execution of systems engineering in the regional jet domain requires the adaptation of the process to that domain considering the unique characteristics of that domain. A driving consideration in the development of regional jets is the severe life cycle environment compared to mainline jets. One of the important tasks is the management of the large number of requirements, especially constraint requirements, imposed both by potential customers and regulatory agencies. Only in this way will the developer be able to provide a product satisfactory to the customer and to satisfy the regulatory requirements with a focus on safety at the same time.
References Carson, Ronald S., and Barbara Sheeley. 2012. "Functional Architecture as the Core of Model-Based Systems Engineering." National Defense Industrial Association Systems Engineering Conference, San Diego, California, 23-25 October. Checkland, Peter. 1999. Systems Thinking, Systems Practice. New York: John Wiley & Sons. FAA. 2014. FAA Systems Engineering Manual. edited by Kimberly Gill. Washington, DC: Federal Aviation Administratiosn.
INCOSE. 2010. Systems Engineering Handbook. edited by SE Handbook WG. Seattle, CA: International Council on Systems Engineering. Jackson, Scott. 1997. Systems Engineering for Commercial Aircraft. Aldershot, UK: Asgate Publishing Limited. Jackson, Scott. 2015. Systems Engineering for Commercial Aircraft: Second Edition - A Domain Specific Adaptation. Edited by Guy Loft. Second ed. Aldershot,, UK: Ashgate Publishing Limited. Textbook. Pyster, Arthur, ed. 2012. Systems Engineering Body of Knowledge. 1.0 ed: Stephens Institute and the Naval Postgraduate School. SAE. 1996. Certification Considerations for Highly-Integrated or Complex Aircraft Systems Solciety of Automotive Engineers. SAE. 2010. Guidelines for the Development of Civil Aircraft and Systems. edited by John Dalton: Society of Automotive Engineers. Wasson, Charles S. . 2006. System Analysis, Design, and Development. Edited by Andrew P. Sage, Wiley Seies in Systems Engineering and Management. Hoboken, NJ: John Wiley & Sons.
Biographies Wellington Martins de Oliveira is the Systems Engineering (SE) Focal Point at Embraer S.A. in Sao Jose dos Campos, Brazil specializing in Systems Engineering Management. He is INCOSE Brazil Chapter CoFounder. Since 2001 working at Embraer S.A on the development of commercial and military aircrafts and nowadays deploying the processes of Systems Engineering (SE) to the development of Aircraft and Defense Systems and has worked on adapting systems engineering to the regional jet domain. Scott Jackson, PhD is the Principal Engineer at Burnham Systems Consulting in Los Ángeles, California specializing in advising clients in the commercial aircraft industry on how systems engineering can be adapted to that domain. He is the author of the book Systems Engineering for Commercial Aircraft (1997) (in both English and Chinese), the second edition of that book entitled Systems Engineering for Commercial Aircraft: A Domain-Specific Adaptation (2015), and numerous other papers on the subject. Scott is formerly with Boeing and has worked with Embraer S.A. of Brazil on adapting systems engineering to the regional jet domain. Scott is an INCOSE Fellow.
Chapter 7 Developing Quality Aviation Systems through Rigorous Specification Development Wellington Martins de Oliveira (
[email protected]) and Scott Jackson, PhD (
[email protected]) (1) This paper shows that the procurement specification is the focal point of requirements development for most aircraft systems. (2) It is axiomatic that quality supplier products cannot be achieved without quality specifications. Furthermore, (3) quality requirements between aircraft elements assure the stability of the supply chain system of systems. For this reason, the (4) requirements lead must be totally familiar with all the aspects of requirements development that are reflected in the spec. For example, this person must be (5) familiar with the structured requirements statement as described by Carson (2015) that reflect the product requirements for the entire life cycle of the aircraft. Furthermore, this person should be (6) conversant with abstract hierarchical levels of the complex aircraft architecture through which requirements are flowed down and which are used to conduct important trade-off decisions. (7) This flow-down assures that requirements for all aircraft subsystems are traceable to stakeholder requirements. (8) This person must understand the organizational responsibilities associated with constructing the process which must be adapted to each hierarchical level of the aircraft. To meet these goals, (9 ) systems engineering processes face factors both in the internal process context and in the supplier domain which require judicious elaboration of the systems engineering process to assure that the requirements are well understood and correctly flowed down to lower level affected areas. (10) In the end the requirements in the spec will strongly determine the stability of the relationships among the subsystems and how well this stability reduces the complexity of the aircraft system. According to the INCOSE handbook (2015) (11)technical processes enable systems engineers to coordinate the interactions among engineering specialists, other engineering disciplines, systems stakeholders and operators. (11,5) Due to systems engineers see the big picture, pay attention on performance and think on the whole, the flow down is the natural process of link requirements from the whole to the part. (12)They create a set of requirements by an interactive and recursive process, crossing top down the hierarchical systems levels in a complex system like an aircraft. (13)System hierarchy presents different level of knowledge on flowing down a stakeholder requirement and respective system capability. (14)These different levels sometime pass first by the systems engineers’ coordination at one primary upper level but still remain necessary to be coordinating at a subsequent next lower level due it present again an interdisciplinary characteristic. (15)For example, at the stakeholder level the Customer Engineering organization captures the stakeholder needs. (16) At the aircraft level the Advanced Design organization converts these needs into top-level aircraft requirements. (17) Then at the subsystem levels (can be more than one) the Design organizations flow down these requirements to the levels of the aircraft hierarchy. (18) This process implies more detailed validation and verification processes that create a valid set of requirements that guides a systems solution at a certain level with its own desired capabilities, bounds of performance, environment, interfaces and properly design constraints. (19) According to Ryan reprinted in the INCOSE handbook (2015), the system requirements definition process is applied at all levels of the systems hierarchy and also to the system element level. (20) A tailoring is necessary to identify levels and apply the process on it, specifically defining roles and responsibilities to validate, make the requirements and traceability, allocate requirements to lower leach level and construct the specification which states the quality of the products from supplier. (21) A quality specification has to avoid
requirements creep, considering the performance spec as result of stakeholder performance requirements flow down. (22) To create quality specifications the requirements lead must have an understanding of what a specification is and what it is not. (23) To begin, a specification is a document given to a supplier to explain what the supplier product must do and how well it can do it. (24)A specification states the requirements for a product at one level of the aircraft hierarchy. (25) Jackson (2015) provides a tailored template for a commercial aircraft specification. First, the specification should state clearly in the structured format described by Carson (2015) how well each supplier produced element or subsystem must perform. (26) Hence, each specification must have at least one performance requirement. (27) Many sources, for example, Stevens et al (1998) explain how a performance requirement can be traceable to the product’s function. (27,5) Recursion sometimes requires different responsible due to specialist can not have the white and the black box perspective of the system. (28) Hence, a rigorous functional analysis is required. One type of functional analysis is the IDEF0 method described by Buede (2000). (29)A specification is not a design document, that is, it does not contain detailed characteristics of the product, for example, dimensions. (30) In can, on the other hand contain limits on the design, for example, if the product needs to fit into a constrained space, the specification will contain this information. This is one type of constraint. (31) In addition, it does not contain information on how to design the product. That is the task of the statement of work (SOW). Buede (2000, p. 39) provides examples of the design process. (32) An understanding of the difference between a specification and a statement of work is important. Two rules are paramount: (1) The specification will contain no design information or design process information, and (2) The SOW will contain no requirements, only information on what is to be designed. Both the specification and the SOW are important and both must be written, but they are distinctly different documents and overlap should be avoided. (33) Quality specifications require rigorous flow down through the aircraft architecture as described by the FAA (2014). Hence the requirements lead will need to document the requirements at every level of the architecture. (34) This does not mean that a specification needs to be developed for each level, but it does mean that a tool, such as DOORS, can be used to document the performance requirements at all levels including the stakeholder level. (35) Then the requirements lead needs to create the specification only at the level of the product in question. (36) Documenting constraints in a specification can be considerably more challenging. This is because there may be hundreds of such constraints and the failure to identify all these constraints can lead to a flawed or incomplete specification or even to flawed products. (37) Typical constraints are physical or environmental constraints, electromagnetic interference (EMI), or durability. (38) This large number of constraints is called requirements creep. For this reason, requirements screening is extremely important and often ignored. Jackson (2015) provides guidance on how to screen these requirements. This guidance involves thorough review of all requirements by knowledgeable engineers. (39) Screening needs to be performed at all levels of the aircraft hierarchy. Some constraints identified at the highest level of the architecture may affect requirements at the lowest levels. Durability is an example; Oliveira and Jackson (2015) show that durability requirements can affect aircraft design at all levels of the aircraft hierarchy. (40) Another way the requirements lead can achieve quality requirements is by resolving conflicting requirements. Most standards for example ARP4754A (2010, p. 59) warn against conflicting requirements. (41) Jackson (2015, pp. 59-60) suggests five different ways to resolve conflicting requirements including linear addition, modeling, weighting, absolute limits, and reallocation.
Before requirements can be flowed down through the architecture, an understanding of what architecture is important. The concept of architecture is poorly understood in industry. First of all, it must be understood that architecture is an abstract concept, that is, it does not necessarily represent the physical arrangement of the components. According to Stephens et al (1998, p. 359), an abstraction is “a view of a system that has a consistent level of behavioral and compositional detail in each branch of the architecture and hides finer, lower level detail.” The philosopher Lonergan (1992) puts it more succinctly: “An abstraction is a simplified replica of the concrete.” According to Jackson (2015) an abstract architecture is an anthropocentric (human view) of a system. Abstract architectures already exist within the aircraft industry; they are called specification trees, reliability trees, and drawing trees. Jackson (2015, p. 12) provides an example of the architecture of an aircraft based on the Air Transport Association (ATA) breakdown of aircraft elements. Most of the abstract architectures in the aircraft industry are hierarchical in structure that is layered. Some subsystems, such as avionics, are often depicted using a network structure. The elements of the aircraft architecture created by the designer needs to be entered into the requirements data base, for example, DOORS. For a new aircraft this architecture will be a direct result of the functional analysis. For existing aircraft the architecture will already exist and can be entered into DOORS as it exists. This would be a logical first step before entering any requirements into the data base. Flowing requirements down through the system hierarchy is one of the primary tasks of the requirements lead. In some cases this process will start even in the middle of the hierarchy or even at the lowest level. The middle level case occurs when a component at that level needs to be modified for part obsolescence or other reasons. The bottom level case occurs when the airline customer specifies a piece of COTS (commercial off-the shelf) equipment, perhaps even a coffee pot. In both cases the requirements lead will need to flow up the requirements to the stakeholder level to assure that the new equipment does not conflict with stakeholder level needs. The FAA Systems Engineering Manual (SEM) (2014) shows this process. The key point is that trade-offs are made at every level of the hierarchy. These trade-off tasks result in a design solution at each level. For example, the requirements for an aileron cannot be made unless the next solution for the wing is identified at the next higher level. Once a solution is found at each level, requirements need to be flowed down to lower levels. In some cases the flow down will be direct, that is, the requirement will be the same at all levels. Durability is an example. In other cases requirements at lower levels will need to be analytically derived as described by Wasson (2006, p. 359). In the commercial aircraft domain one example of an analytically derived requirement is the energy absorbed by brake pads. This requirement can be derived from the required stopping distance (a stakeholder requirement) and the energy absorbed by the entire braking system (the solution). A second example is the current absorbed by individual connectors following a lightning strike. This requirement can be derived from the current absorbed by the aircraft and the geometry of individual conduits (the solution). Another method of flow down is the allocation of requirements at the next lower level of the hierarchy to several components at that level. Weight limits are an example. Another important role of the procurement specification is to maintain the stability and functionality of the supply chain system of systems and to reduce the risk of excessive outsourcing. As explained by Jackson (2015, pp. 201-213) the supply chain is a complex system of systems in which each supplier is a component system. This analysis builds on the work of Sillitto (2010) in the context of large scale system integration (LSSI). According to many sources, for example, Giachetti (2010, p. 36), Jackson and Moraes (2015), and Shannon (1948), a driving factor in system complexity is its information entropy which is a measure of
the uncertainty in the relations among the component parts. When the requirements between these component parts are rigorously stated, the information entropy is low and complexity is reduced. The concept of information entropy is also important in minimizing the complexity of the aircraft itself. That is if the relations among the aircraft elements are stable, the complexity will be a minimum. Many organizations in a commercial aircraft enterprise have important roles in the creation of quality specifications. Following are a few: • Design Engineering is the focal organization for the creation of a procurement specification. This person is responsible for understanding and coordinating all the processes described in this paper and creating the specification. The requirements lead is normally a member of this organization. Design Engineering is also responsible for assigning verification methods and confirming the verification results especially those conducted by suppliers. • Customer Engineering also called Marketing is responsible for determining customer and other stakeholder needs and framing them in a form useful for specification creation. • Advanced Design is the primary organization responsible for translating the stakeholder needs into and aircraft architecture and creating the hierarchy for flowing down requirements to the level necessary for the procurement specification. This organization is also responsible for validating the requirements so that traceability can be established at all levels. Top level requirements pertain to such issues as flight performance and ETOPS. • The Contracts organization is responsible for creating the statement of work in accordance with the criteria listed earlier in this paper. • Procurement, also called Supplier Management, is responsible for providing both a rigorous specification and a statement of work to the supplier. • The Test and Evaluation organization is responsible for conducting the tests assigned to the product as part of the verification process. Conclusions: The principles in this paper are consistent with a broad range of authoritative sources for systems engineering. It has gone beyond standard sources to place them in the context of a commercial aircraft enterprise and to show how all of these processes converge to produce a quality specification and also a quality aircraft system and a quality supply chain system of systems. Buede, D. M. (2000). The Engineering Design of Systems. Hoboken, NJ: John Wiley & Sons, Inc. Carson, R. S. (2015). Implementing Structured Requirements to Improve Requirements Quality. Paper presented at the INCOSE. FAA. (2014). FAA Systems Engineering Manual. Washington, DC: Federal Aviation Administration. Giachetti, R. E. (2010). Design of Enterprise Systems: Theory, Architecture, and Methods. Boca Raton, Florida: CRC Press. International Council on Systems Engineering (INCOSE). (2015). INCOSE Systems Engineering Handbook: A Guide for System Life Cycle Processes and Activities: 4th Editionpp. 304). Jackson, S. (2015). Systems Engineering for Commercial Aircraft: A Domain Specific Adaptation (Second ed.). Aldershot,, UK: Ashgate Publishing Limited.
Jackson, S., & Moraes, R. (2015). Minimizing the Complexity of Systems through Structural Optimization and Reduction in Variability. Paper presented at the IS 2015. Lonergan, B. (Ed.). (1992). Insight: A Study of Human Understanding (5 ed. Vol. 3). Toronto: Univeristy of Toronto Press. Oliveira, W., & Jackson, S. (2015). Adapting Systems Engineering to the Development of Regional Jets. Paper presented at the INCOSE International Symposium. Retrieved from https://www.academia.edu/11662603/Adapting_Systems_Engineering_to_the_Develo pment_of_Regaional_Jets SAE. (2010). Guidelines for the Development of Civil Aircraft and Systems: Society of Automotive Engineers. Shannon, C. E. (1948). A Mathematical Theory of Communication. The Bell System Technical Journal, XXVII(3), 379-423. Sillitto, H. G. (2010). Design Principles for Ultra-Large-scale Systems. Paper presented at the International Council on Systems Engineering International Symposium. Stevens, R., Brook, P., Jackson, K., & Arnold, S. (1998). Systems Engineering: Coping With Complexity. London: Prentice Hall. Wasson, C. S. (2006). System Analysis, Design, and Development. Hoboken, NJ: John Wiley & Sons.
