Case Study Basic Introduction V V Case Study

Case Study Basic Introduction V &V Case Study System Engineering

System Engineering approach for the design of commercial aircraft

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

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

Motivations

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

“Chaos” report - extract

NASA study (1985)

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

SYSTEMS ENGINEERING concerns

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.

The evolution of Systems Engineering standards EIA-ANSI 632 EIA 632 Systems Engineering Processes for Engineering a System 98 94 IEEE 1220 Application & Management of Systems Engineering Process 94/95 MIL STD 499 B Systems Engineering MIL STD 499 A Engineering Management 69 74 94 ISO 15288 Systems Engineering Life cycle processes > 2000

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

What “System” means in Systems Engineering Notion of End Product and Enabling Products System Consists of performs End Product performs Enabling Products Operation The diagram below (EIA 632) implicitly includes those developing, Associated producing, testing, using, supporting andal ensuring the extension of life as well as those training. . . Process Functions

The Building Block concept

Development Layer Concept

Development of “Enabling Products”

Possible product breakdown

Generic approach of requirements engineering in a “Systems” approach applied to each “layer” PURCHASER REQUIREMENTS OF OTHER STAKEHOLDERS SYSTEM REQUIREMENTS allocated LOGICAL SOLUTION REPRESENTATION derived DERIVED REQUIREMENTS allocated derived allocated PHYSICAL SOLUTION REPRESENTATION source of DESIGN SOLUTION defined by SPECIFIED REQUIREMENTS

Consistent and complete set of processes (EIA 632)

The baseline applicable to the project

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

What You’ll Find in the Guidelines 1. 0 Introduction 2. 0 Commercial Aircraft Domain 8 p 3. 0 Life Cycle Framework 7 p 4. 0 Commercial Aircraft Process Relationships 12 p 5. 0 Commercial Aircraft System Architecture 8 p 6. 0 Systems Engineering Management 6 p 7. 0 Verification Plan 8. 0 Test Plan Appendix A - Linkage to Guidelines/Standards Appendix B - Acronyms Appendix C - References Appendix D - Commercial Aircraft Functions 1 p 1 p Appendix E - Glossary Appendix F- Comments Form 12 p

Systems approach applied to the characterization of the commercial aircraft domain Commercial Aircraft 3. 0 Life Cycle Framework System 4. 0 Commercial Aircraft Process 1. 0 Introduction 2. 0 Commercial Aircraft Domain Worldwide Air Transport System Relationships 5. 0 Commercial Aircraft System Architecture 6. 0 Systems Engineering Management Places to Depart From & Return To 7. 0 Verification Plan Commercial Air Transport System 8. 0 Test Plan Commercial Aircraft Airports Things That Fly Pax & Cargo Systems Commercial Air Traffic Control Things That Handle Pax & Cargo

Decisive factors for the design of a commercial aircraft Natural, Ecological Land, Oceans Atmosphere Climate Fauna & Flora Sciences Physics Technical Capability Existing Base Operational Practices State of Technology Economic Political, Legal, Policy Economic Structure Regulatory Infrastructure of Customers: Airlines Legal Infrastructure External Suppliers, Others Political Infrastructure Distribution of Resources Commercial aircraft Cultural, Personal Public awareness Demographic features Views/biases of power brokers

Commercial Aircraft System Breakdown and System Boundary Commercial Aircraft system End Product The Aircraft World Air Transport System The Overall Environment Commercial Air Transport System Customer Airlines External Suppliers Regulatory agencies, . . . Enabling Products Development Products (Engineering, etc. ) Subsystem (Propulsion, Airframe, Avionics, Environmental Control, Crew Accommodations, Electrical, Interiors, Auxiliary) Test Products Training Products (Flight Test, Lab Test) (Pilot training, etc) Disposal Products Production Products Deployment Products Support Products (Manufacture, Assembly) (Acceptance, etc. ) (Fueling, Spares, Maintenance, Modification)

Commercial Air Transport System Architecture Commercial Air Transport System Aircraft System Environmental segment Air Conditionin g Cabin Pressure Ice & Rain Protection Oxygen Pneumatic Avionics segment Auto Flight Communications Indicating & Recording Navigation Electrical segment Electrical Power Shipside Lighting Interiors segment Other operational Elements Mechanical segment Propulsion segment Auxiliary Power System Airframe segment Crew Accommodations Flight Controls Fuel Passengers Accommodations Hydraulic Power Pylon / Structure Stablizer Landing Gears Power Plant Wing Water, Waste Lavs, Galleys & Plumbing Emergency Provisions Signs & Lights Power Control Fuselage Ground Starting Equipment Flight Deck Crew

Life Cycle Framework

Life Cycle Stages ANSI / EIA 632 JCAWG Guidelines Assessment of Opportunities and Marketing Investment Decision Investment Management System Concept Development Aircraft System Development Life Cycle Subsystem Design and Pre. Deployment, Operations, Support, and Disposal Production Sustaining Disposal System Development and Certification Subsystem Development

Commercial Aircraft Process Relationship Plans & Directives Acquisition & Supply Requirements Definition Solution Definition Assessment Process Outcomes Feedback System Production Outcomes Analysis Process Technical Evaluation Certification Verification Process Validation Process & Products Agreement Request Acquisition Planning Process Management Control Process System Technical

The Aircraft Operational Functions Top-Level Aircraft Functions Provide and Distribute Communications Plan, Generate and Control Aircraft Movement Provide Crew, Passenger, and Cargo Environment and Services Detect and Analyze Aircraft Conditions for Flight Distribute Aircraft Information Generate and Manage Internal Power and Manage Systems Materials Provide Airframe Movement and Attachment Capability Provide Containment and Internal Support

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

Status of the document – Draft Version 1. 2 a published in July 2000 ØDocument is available at http: //www. incose. org/seatc/ ØNext revision planned for Jan 2004

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.

Introduction (2) • Why capture requirements? • How? – 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? Þ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. – To reduce the risk that we may be starting • How? with an incomplete or inconsistent set of ÞThis is achieved by producing a model(s) requirements i. e. to ensure that all the of the requirements and reviewing the requirements of the proposed product are model with the stakeholders. established at each level of abstraction. ÞDecisions must be made which may – To identify the key requirements i. e. the compromise some requirements - a trade primary design drivers. off analysis is performed to balance conflicting requirements e. g. cost with performance

Introduction (3) • How? • 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. Þ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 lifecycle. Þ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

What is a requirement?

Requirement structure & richness Example: BNEY-SER-038 -1 When producing requirements in Word document, developer shall use i. SEF CARE Macro V 5 or any i. SEF tool agreed by BNE. Most requirements should have 5 -7 elements

Relation between development level and product breakdown The result of architecting the product at one level is a set of sub-products description at lower level

Thanks for you Attention Always have a SE view , if not the whole , think of the framework