1 / 39

Case Study

System Engineering approach for the design of commercial aircraft. . . AGENDA. MotivationSYSTEMS ENGINEERING concernsPresentation of the INCOSE document describing an application of Systems Engineering in the commercial aircraft domainCurrent status of the documentConclusions. . . Reference doc

maddox
Télécharger la présentation

Case Study

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

    2. System Engineering approach for the design of commercial aircraft

    3. AGENDA Motivation SYSTEMS ENGINEERING concerns Presentation of the INCOSE document describing an application of Systems Engineering in the commercial aircraft domain Current status of the document Conclusions

    4. Reference documents for the presentation ANSI/EIA standard 632-1998 Version 1.1: Processes for Engineering a system INCOSE document: Framework for the Application of Systems Engineering in the Commercial Aircraft Domain

    5. Motivations

    6. Control of the development of complex products Observation: Despite the progress made through the deployment of project management and program management approach since 1945 following observations have been made on many programs: major delays problems with quality overcost

    7. “Chaos” report - extract

    8. NASA study (1985)

    9. Motivations / conclusion The conventional Engineering approach leads to a vision of the product as the sum of optimized products/systems Systems Engineering relies on this knowledge to propose a vision of the product as a system optimized in its environment

    10. SYSTEMS ENGINEERING concerns

    11. What is Systems Engineering Systems engineering is an interdisciplinary approach used to control the development of complex systems. This approach starts with the definition of customer needs, the identification of product functionalities and their validation very early in the cycle. Systems engineering integrates these disciplines to place them at the disposal of specialized groups so that they can perform team work facilitated by a structured, multi-level development process integrating activities from the feasibility phase to operational support. Systems engineering simultaneously considers the technical and economic aspects of all stakeholders in order to supply the end customer with a quality product which meets his needs.

    12. The evolution of Systems Engineering standards

    13. Key Concepts for Systems Engineering System includes both End Products and Enabling Products Building Blocks are the basic unit of a System Systems are developed in “layers” Consistent and complete set of processes At each level, assess needs by considering all stakeholders to optimize the “correct” choice of any solution

    14. What “System” means in Systems Engineering Notion of End Product and Enabling Products

    15. The Building Block concept

    16. Development Layer Concept

    17. Development of “Enabling Products”

    18. Possible product breakdown

    19. Generic approach of requirements engineering in a “Systems” approach applied to each “layer” Systems engineering is based on a rigorous approach: starting with the capture and the formalization of end customer requirements, which must result in the production of a product meeting the requirements of this customer. based on the search for all types of requirements (functional, operational, cost, quality or deadlines) to be integrated to ensure the completeness of the statement of need; the analysis and the characterization of this set of requirements to determine a “logical" representation of the need. This may be the result of a functional, object or other type of analysis … Following a design activity to make the comparative evaluation of different solutions, the characterization of the target physical architecture adopted (physical solution ), through the allocation of all requirements to this architecture in particular expressing the derived requirements used to describe the interfaces between architecture elements. Lastly, for each component of this architecture, the specification of all requirements used to produce components as independently as possible, without overlooking the description of all support products required for this production (documentation, test, deployment, installation, training, support, etc.) Systems engineering is based on a rigorous approach: starting with the capture and the formalization of end customer requirements, which must result in the production of a product meeting the requirements of this customer. based on the search for all types of requirements (functional, operational, cost, quality or deadlines) to be integrated to ensure the completeness of the statement of need; the analysis and the characterization of this set of requirements to determine a “logical" representation of the need. This may be the result of a functional, object or other type of analysis … Following a design activity to make the comparative evaluation of different solutions, the characterization of the target physical architecture adopted (physical solution ), through the allocation of all requirements to this architecture in particular expressing the derived requirements used to describe the interfaces between architecture elements. Lastly, for each component of this architecture, the specification of all requirements used to produce components as independently as possible, without overlooking the description of all support products required for this production (documentation, test, deployment, installation, training, support, etc.)

    20. Consistent and complete set of processes (EIA 632)

    21. The baseline applicable to the project In a “Systems Engineering” approach, the standard baseline applicable to the project is the result of the instantiation of the Enterprise baseline. This instantiation is performed integrating the particularities of the product to be made and those of the project environment in terms of resources, schedule, organization… The quality approach and the certification process rely on this baseline.In a “Systems Engineering” approach, the standard baseline applicable to the project is the result of the instantiation of the Enterprise baseline. This instantiation is performed integrating the particularities of the product to be made and those of the project environment in terms of resources, schedule, organization… The quality approach and the certification process rely on this baseline.

    22. Presentation of the INCOSE document describing a Systems Approach for the design of commercial aircraft: Framework for the Application of Systems Engineering in the Commercial Aircraft Domain

    23. What You’ll Find in the Guidelines 1.0 Introduction 2.0 Commercial Aircraft Domain 8 p 3.0 Life Cycle Framework 7p 4.0 Commercial Aircraft Process Relationships 12p 5.0 Commercial Aircraft System Architecture 8p 6.0 Systems Engineering Management 6p 7.0 Verification Plan 1p 8.0 Test Plan 1p Appendix A - Linkage to Guidelines/Standards Appendix B - Acronyms Appendix C - References Appendix D - Commercial Aircraft Functions 12p Appendix E - Glossary Appendix F- Comments Form The Guidelines for the Application of Systems Engineering in the Commercial Aircraft Domain describe what commercial aircraft do, and what requirements they must abide by to meet Commercial Air Transport needs. For Commercial Aircraft, this Guideline addresses: Aircraft-Level Context Section 2 describes the overall commercial aircraft system and its boundaries in the context of the “system of systems” within which it exists. This section also provides the logical context that forms the basis for drawing boundaries, and for assigning requirements to the aircraft. Time Frames for Aircraft Section 3 depicts the various kinds of life cycles that need to be considered, and incorporated in commercial aircraft development, production and support efforts and activities. Commercial Processes Section 4 describes the primary processes which may be applied in the aircraft industry, and indicates what kinds of methods and tools help provide clarity to process implementation. System Description Section 5 contains a high-level summary of the commercial aircraft as an end product as well as a set of its primary subsystems. This section includes an overall description of what these systems need to contain and why, leaving application specifics to the individual enterprise. Management of SE Context Section 6 describes activities commonly used by systems engineers to control and manage technical efforts on aircraft systems. Verification Plan and Test Plan Section 7 & 8 highlight how significant the establishment of the Verification Plan and the Test Plan is. Unfortunately, these chapters are not mature and have to be improved. Document architecture, and the recent evolution of this architecture reveals the opportunity to participate and propose some major improvement s to the content and architecture of the document. The working group seems very open to any comments or proposals that make its work more effective. The Guidelines for the Application of Systems Engineering in the Commercial Aircraft Domain describe what commercial aircraft do, and what requirements they must abide by to meet Commercial Air Transport needs. For Commercial Aircraft, this Guideline addresses: Aircraft-Level Context Section 2 describes the overall commercial aircraft system and its boundaries in the context of the “system of systems” within which it exists. This section also provides the logical context that forms the basis for drawing boundaries, and for assigning requirements to the aircraft. Time Frames for Aircraft Section 3 depicts the various kinds of life cycles that need to be considered, and incorporated in commercial aircraft development, production and support efforts and activities. Commercial Processes Section 4 describes the primary processes which may be applied in the aircraft industry, and indicates what kinds of methods and tools help provide clarity to process implementation. System Description Section 5 contains a high-level summary of the commercial aircraft as an end product as well as a set of its primary subsystems. This section includes an overall description of what these systems need to contain and why, leaving application specifics to the individual enterprise. Management of SE Context Section 6 describes activities commonly used by systems engineers to control and manage technical efforts on aircraft systems. Verification Plan and Test Plan Section 7 & 8 highlight how significant the establishment of the Verification Plan and the Test Plan is. Unfortunately, these chapters are not mature and have to be improved. Document architecture, and the recent evolution of this architecture reveals the opportunity to participate and propose some major improvement s to the content and architecture of the document. The working group seems very open to any comments or proposals that make its work more effective.

    24. Systems approach applied to the characterization of the commercial aircraft domain Within the context of the Commercial Aircraft domain, the World Air Transport System is the highest level (or all-encompassing) system. The World Air Transport System (WATS) consists of four primary end products: Things That Fly (commercial, military and other aircraft) Places to Depart From and Return To (airports and other departure/landing facilities) Traffic Control (commercial, military and private/other traffic control) Things That Handle Passengers and Cargo The next hierarchical level of system - the Commercial Air Transport System - contains one subset of each of the end products of the World Air Transport System. The Commercial Air Transport System (CATS) is composed of : Commercial Aircraft (passenger, cargo and both passenger/cargo aircraft), Airports (departure/landing surfaces and airport facilities), and Commercial Air Traffic Control. Passenger and Cargo Systems The primary system of interest for these guidelines is the Commercial Aircraft System. A partial notional mapping from the World Air Transport System to the Commercial Air Transport System to the Commercial Aircraft System (CAS) is shown in Figure 2.1-1. Within the context of the Commercial Aircraft domain, the World Air Transport System is the highest level (or all-encompassing) system. The World Air Transport System (WATS) consists of four primary end products: Things That Fly (commercial, military and other aircraft) Places to Depart From and Return To (airports and other departure/landing facilities) Traffic Control (commercial, military and private/other traffic control) Things That Handle Passengers and Cargo The next hierarchical level of system - the Commercial Air Transport System - contains one subset of each of the end products of the World Air Transport System. The Commercial Air Transport System (CATS) is composed of : Commercial Aircraft (passenger, cargo and both passenger/cargo aircraft), Airports (departure/landing surfaces and airport facilities), and Commercial Air Traffic Control. Passenger and Cargo Systems The primary system of interest for these guidelines is the Commercial Aircraft System. A partial notional mapping from the World Air Transport System to the Commercial Air Transport System to the Commercial Aircraft System (CAS) is shown in Figure 2.1-1.

    25. Decisive factors for the design of a commercial aircraft

    26. Commercial Aircraft System Breakdown and System Boundary The commercial aircraft system - our primary end product - forms its boundaries inside an enterprise environment which includes many individual business entities. A clear separation between the end product itself - the Commercial Aircraft System - and its external operational environment is the pivot of subsequent efforts in engineering the processes required to build the products. For a Commercial Aircraft System, the following three systems interact: (1) the End Product (Aircraft) System (2) the Aircraft (End Product) Production System (3) the Overall Environment (in which the End Product operates) For the Commercial Aircraft System, the external environment includes: the World Air Transport System and the Commercial Air Transport System. It also includes customer airlines, external suppliers and regulatory agencies that levy requirements on the end product system and the process system within which the product is produced. This Chapter emphasizes System Interaction with the External Environment and Interaction with the Enterprise Environment (aircraft production system). Specifically, five factors are identified as critical for the definition of the context. These factors are: Natural, Ecological Economic (Profit / Loss) Political, Legal, Policy Technological Capabilities, and Cultural, Personal, Behavioral. The commercial aircraft system - our primary end product - forms its boundaries inside an enterprise environment which includes many individual business entities. A clear separation between the end product itself - the Commercial Aircraft System - and its external operational environment is the pivot of subsequent efforts in engineering the processes required to build the products. For a Commercial Aircraft System, the following three systems interact: (1) the End Product (Aircraft) System (2) the Aircraft (End Product) Production System (3) the Overall Environment (in which the End Product operates) For the Commercial Aircraft System, the external environment includes: the World Air Transport System and the Commercial Air Transport System. It also includes customer airlines, external suppliers and regulatory agencies that levy requirements on the end product system and the process system within which the product is produced. This Chapter emphasizes System Interaction with the External Environment and Interaction with the Enterprise Environment (aircraft production system). Specifically, five factors are identified as critical for the definition of the context. These factors are: Natural, Ecological Economic (Profit / Loss) Political, Legal, Policy Technological Capabilities, and Cultural, Personal, Behavioral.

    27. Commercial Air Transport System Architecture

    28. Life Cycle Framework Chapter 3 depicts the 3 different Life Cycles to be considered. If we agree that a product life cycle (operational or enabling) is the period of time that begins when a product is conceived and ends when the product is no longer available for use. Systems are engineered, developed, produced, and deployed within the framework of three basic life-cycles. These life-cycles are: Enterprise, Project and Product. Each operation system; Commercial Air Transport System (CATS), aircraft and aircraft subsystem applies these three life cycles. Each facet of the product life cycle has intrinsic associated engineering life cycles. The transparency presents a typical mapping between engineering and enterprise life cycles This chapter identifies and describes other relationships between life cycles such as: Air Transport Life Cycles Commercial Aircraft Life Cycles Aircraft Manufacture Enterprise-based Life Cycle For this Life Cycle, description is made at a lower level of detail that includes considerations on: Opportunity Assessment Life Cycle - Aircraft Sales and Marketing Investment Management Life Cycle - Aircraft Plant and Equipment Resource Management Life Cycle - Workforce and Materials Aircraft Life Cycle - Project and Product Chapter 3 depicts the 3 different Life Cycles to be considered. If we agree that a product life cycle (operational or enabling) is the period of time that begins when a product is conceived and ends when the product is no longer available for use. Systems are engineered, developed, produced, and deployed within the framework of three basic life-cycles. These life-cycles are: Enterprise, Project and Product. Each operation system; Commercial Air Transport System (CATS), aircraft and aircraft subsystem applies these three life cycles. Each facet of the product life cycle has intrinsic associated engineering life cycles. The transparency presents a typical mapping between engineering and enterprise life cycles This chapter identifies and describes other relationships between life cycles such as: Air Transport Life Cycles Commercial Aircraft Life Cycles Aircraft Manufacture Enterprise-based Life Cycle For this Life Cycle, description is made at a lower level of detail that includes considerations on: Opportunity Assessment Life Cycle - Aircraft Sales and Marketing Investment Management Life Cycle - Aircraft Plant and Equipment Resource Management Life Cycle - Workforce and Materials Aircraft Life Cycle - Project and Product

    30. Commercial Aircraft Process Relationship The process framework is directly derived from EIA-632 with the following modifications: a) The Verification process has been split into two processes: 1) a Certification Process that deals with the regulatory requirements only, as this involves the most expensive, time consuming and complicated activities in a commercial aircraft development cycle, 2) a Verification Process that deals with all other stakeholder requirements. b) The System Design Process has been expanded to include its sub-processes: Requirements Definition, Solution Definition, and System development. This is done to emphasize the extremely volatile requirements capture for commercial aircraft development. c) The Acquisition & Supply Process is moved to a parallel branch. The process framework is directly derived from EIA-632 with the following modifications: a) The Verification process has been split into two processes: 1) a Certification Process that deals with the regulatory requirements only, as this involves the most expensive, time consuming and complicated activities in a commercial aircraft development cycle, 2) a Verification Process that deals with all other stakeholder requirements. b) The System Design Process has been expanded to include its sub-processes: Requirements Definition, Solution Definition, and System development. This is done to emphasize the extremely volatile requirements capture for commercial aircraft development. c) The Acquisition & Supply Process is moved to a parallel branch.

    31. Top-Level Aircraft Functions

    32. Relationships between Validation, Certification and Verification in the Commercial Aircraft Domain

    33. Status of the document

    34. Introduction (1) In a customer focused organisation, successful product development must capture the views (i.e. the requirements) of all the interested parties (i.e. the stakeholders). In order to ensure that the developed product will satisfy the needs of the users of the product the requirements must be analysed for consistency and completeness. Requirements management is introduced to ensure that requirements are made widely available to the development team and that traceability information is maintained throughout the project hierarchy and through to verification. Requirements have traditionally been expressed using natural language and are likely to continue to be for some considerable time. The appearance of CASE tools which allow the expression of abstract or absolute engineering concepts in forms other than natural language have only served to complicate the requirements management activities, particularly in the area of traceability.

    35. Introduction (2) Why capture requirements? Because they dictate what is required of a product in order for it to be accepted by potential customers. e.g. manufacturing, maintenance, ground crew, airlines, regulatory bodies etc. We need to elicit requirements which will satisfy the customer (and end users). We need to make the requirements widely available to the project team such that there is a common understanding of the problem domain. Why analyse requirements? To reduce the risk that we may be starting with an incomplete or inconsistent set of requirements i.e. to ensure that all the requirements of the proposed product are established at each level of abstraction. To identify the key requirements i.e. the primary design drivers. How? The problem here is that customers might not know what their requirements are. To be successful in the market place we may have to guide the customers by illustration of what they could have. This is achieved by considering the views of the customers and users of the product. The provision of a common repository for requirements, distributed according to some managerial constraints ensures the project team have the necessary visibility. How? This is achieved by producing a model(s) of the requirements and reviewing the model with the stakeholders. Decisions must be made which may compromise some requirements - a trade off analysis is performed to balance conflicting requirements e.g. cost with performance

    36. Introduction (3) What is the purpose of requirements management? To ensure that a complete set of the technical and managerial requirements of the product to be developed is available throughout the project lifecycle. To provide traceability between project requirements and implementation and verification at each level of abstraction and between requirements at different levels of abstraction. To ensure and be able to demonstrate that the correct product is delivered and that the product is developed within appropriate constraints. To maintain a configured record of the requirements which are relevant to particular products and variants. How? This is achieved by providing a repository for the requirements and managing the issue status of different views of these requirements throughout the project. This allows impact analysis to be performed (forwards and backwards) which in turn facilitates the management of change, risk and non-conformance throughout the life-cycle. This is achieved by the inspection of traceability throughout the system development: between requirements at different levels between requirements and their realisation at each level between requirements and their verification at each level This is achieved by linking requirements to product variants and by baselining the requirements repository

    37. What is a requirement?

    38. Requirement structure & richness

    39. Relation between development level and product breakdown

More Related