Case Study System Engineering Basic IntroductionV &V Case Study.

Case Study

System Engineering

Basic IntroductionV &V

Case Study

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

Factors ofsuccess

40%

9%

23%

14%

Needs / Requirements / Specifications

Technique / Technologies

Project / Resources

Electronic data manager

Factors offailure

48%

11%

9%

8%

NASA study (1985)

-20

30

80

130

180

0 5 10 15 20 25 30

Costs during feasibility/definition phases in % of development costs

Fin

al e

xces

s co

st %

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

MIL STD 499AEngineering Management

MIL STD 499BSystems Engineering

EIA 632Systems Engineering

IEEE 1220Application & Management

of Systems Engineering Process

ISO 15288Systems Engineering Life cycle processes

94/95

98

> 2000

MIL STD 499AEngineering Management

69

74

94

EIA-ANSI 632Processes for Engineeringa System

94

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

What “System” means in Systems Engineering

Notion of End Product and Enabling Products System

EndProduct

EnablingProducts

Operational

Functions

Associated Process

Functions

The diagram below (EIA 632) implicitly includes those developing, producing, testing, using, supporting and ensuring the extension of life as well as those training ...

Consists of

performs performs

The Building Block concept

Development Layer Concept

Development of “Enabling Products”

Possible product breakdown

PURCHASER REQUIREMENTS

PHYSICAL

SOLUTION

REPRESENTATION

REQUIREMENTS

OF OTHER

STAKEHOLDERS

SPECIFIED

REQUIREMENTS

allocated

allocated

allocated

derived

DERIVED

REQUIREMENTS

derivedsource of

defined by

DESIGN SOLUTION

SYSTEM REQUIREMENTS

allocatedLOGICAL

SOLUTION

REPRESENTATION

Generic approach of requirements engineering in a “Systems” approach applied to each “layer”

Consistent and

complete set of

processes (EIA 632)

AcquisitionProcess

SupplyProcess

Acquisition& Supply

Technical Evaluation

SystemsAnalysisProcess

SystemVerification

Process

RequirementsValidationProcess

End ProductsValidationProcess

Technical Management

PlanningProcess

AssessmentProcess

ControlProcess

SystemDesign

RequirementsDefinition Process

Solution DefinitionProcess

ProductRealization

ImplementationProcess

Transition to UseProcess

Plans,Directives& Status

Outcomes&

Feedback

Requirements

Designs

Products

AcquisitionRequest

SystemProducts

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 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 1pAppendix A - Linkage to Guidelines/StandardsAppendix B - AcronymsAppendix C - ReferencesAppendix D - Commercial Aircraft Functions 12p

Appendix E - GlossaryAppendix F- Comments Form

Commercial Commercial Air Air

TransportTransportSystemSystem

Worldwide AirWorldwide AirTransportTransportSystemSystem

Systems approach applied to the characterization of the commercial aircraft domain

Things That Fly

Places to Depart From & Return To

TrafficControl

Commercial Aircraft

Airports

CommercialAir Traffic

Control

Things That Handle Pax& Cargo

Pax & CargoSystems

Commercial Commercial AircraftAircraftSystemSystem

1.0 Introduction

2.0 Commercial Aircraft Domain

3.0 Life Cycle Framework

4.0 Commercial Aircraft Process Relationships

5.0 Commercial Aircraft System Architecture

6.0 Systems Engineering Management

7.0 Verification Plan

8.0 Test Plan

Decisive factors for the design of a commercial aircraft

Commercialaircraft

Political, Legal, Policy Regulatory Infrastructure Legal Infrastructure Political Infrastructure

Cultural, PersonalPublic awarenessDemographic featuresViews/biases of power brokers

Technical CapabilityExisting BaseOperational PracticesState of Technology

Economic

Economic Structure of Customers: Airlines

External Suppliers, Others Distribution of Resources

Natural, Ecological Land, Oceans Atmosphere Climate Fauna & Flora Sciences Physics

The Overall Environment

Commercial Aircraft System Breakdown and System Boundary

CommercialAircraftsystem

DevelopmentProducts

TestProducts

TrainingProducts

DisposalProducts

ProductionProducts

DeploymentProducts

SupportProducts

EnablingProducts

(Engineering, etc.)

(Flight Test,Lab Test)

(Pilot training, etc)

(Manufacture,Assembly)

(Fueling, Spares,Maintenance,Modification)

(Acceptance, etc.)

EndProduct

TheAircraft

(Propulsion, Airframe, Avionics,Environmental Control, Crew Accommodations, Electrical, Interiors, Auxiliary)

Subsystem Subsystem

World Air Transport SystemCommercial Air Transport SystemCustomer AirlinesExternal SuppliersRegulatory agencies, ...

Commercial Air Transport System Architecture

Commercial

Air

Transport

System

Aircraft

SystemOther

operational

Elements

Environmental

segment

Avionics

segment

Electrical

segment

Interiors

segment

Mechanical

segment

Propulsion

segment

Auxiliary

segment

Airframe

segment

Air

Conditioning

Cabin

Pressure

Ice & Rain

Protection

Oxygen

Pneumatic

Auto

Flight

Communica-tions

Indicating &

Recording

Navigation

Crew

Accom-modations

Passengers

Accom-modations

Water, Waste

Lavs,Galleys

& PlumbingEmergency

Provisions

Signs &

Lights

Flight

Controls

Hydraulic

Power

Landing

Gears

Fuel

Pylon /

Structure

Power

Plant

Power

Control

Fuselage

Stablizer

Wing

Electrical

Power

Shipside

Lighting

Auxiliary

Power

System

Ground

Starting

Equipment

Flight Deck

Crew

A /CC o n c e p t

R e v ie w

A /C P re lim in a r y

D e s ig nR e v ie w

A /CD e ta i le dD e s ig nR e v ie w

C o n c e p t S tu d y F e a s ib i li ty S tu d yP re lim in a r y D e ta i le d

D e s ig nP ro d u c t io n /S u s ta in in gP re lim in a ry D e v e lo p m e n t

D e s ig n

C ertif ica tionG o -A h ead

B u s in es sO p p o rtu n ityS tu d y

Fe as ib ilityS tu d y

P ro jec tD ef in it io n

F u llSc a le D ev e lo p m en t

B u s in es sO p p o rtu n ity

R e v ie w

P ro jec tR eq u ir em e n ts

R e v ie w

C ritic a lP ro jec tR e v ie w

E nte rp rise B ase d L ife-c yc le

E nterp rise B ased L ife C yc le R e la tio n sh ip s

S yste m L ife -c y c leD ev e lo p m e n t P ro c ess

O p e ra t io n a l D e p lo ym e n t

D is p o s a l

F irs t P r o d u c t io nA r tic le S im u la t io n P r o d u c t U p g r a d e s

E ng in ee r ing L ife -cy c leP ro c ess

P r o to ty p eD e v e lo p m e n t

F irs tD e l iv e r y

R e q u ir e m en ts D e v e lo p m e n t D e s ig n D e v e lo p m e n t

A /CD e fin i t io n

R e v ie w

Life Cycle Framework

Life Cycle Stages

ANSI / EIA 632ANSI / EIA 632 JCAWG GuidelinesJCAWG Guidelines

Assessment of Opportunities Assessment of Opportunitiesand Marketing

Investment Decision Investment Management

System Concept Development

Subsystem Design and Pre-Deployment

AircraftSystemDevelopmentLife Cycle

System Develop-ment andCertification

Deployment, Operations, Support, and Disposal

Production

Sustaining

Disposal

Subsystem Development

Commercial Aircraft Process Relationship

ControlProcess

Technical ManagementPlanningProcess

AssessmentProcess

Outcomes &Feedback

Plans &Directives Requirements

Definition

SolutionDefinition

SystemProduction

Acquisition& Supply

Agreement

Outcomes

Acq

uis

itio

n

Request

Syst

em

Pro

duct

s

Technical EvaluationAnalysisProcess

VerificationProcess

ValidationProcess

CertificationProcess

Provide and Distribute CommunicationsProvide and Distribute Communications

Plan, Generate and Control Aircraft MovementPlan, Generate and Control Aircraft Movement

Provide Crew, Passenger, and Cargo Environment and Provide Crew, Passenger, and Cargo Environment and

ServicesServices

Detect and Analyze Aircraft Conditions for FlightDetect and Analyze Aircraft Conditions for Flight

Distribute Aircraft InformationDistribute Aircraft Information

Generate and Manage Internal Power and Manage Generate and Manage Internal Power and Manage Systems MaterialsSystems Materials

Provide Airframe Movement and Attachment CapabilityProvide Airframe Movement and Attachment Capability

Provide Containment and Internal SupportProvide Containment and Internal Support

TheAircraft

OperationalFunctions

Top-Level Aircraft Functions

Relationships between Validation, Certification and Verification in the

Commercial Aircraft Domain

EndProduct

Validation

A

Requirementand/or Product

Verification

ProductCertification

RequirementValidation

B C

D

Status of the document

– Draft Version 1.2a 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?

– 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

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

What is a requirement?

REQUIREMENT

RATIONALE

ASSUMPTION

VERIFICATIONPROCEDURE

RISK

TRADE_OFF

PRODUCT

STAKEHOLDER

Supported_by

Emitted_by

Conditioned_by

Associated_with

Result_from

Allocated_to

Verified_by

Requirement structure & richness

Element definition Minimum Requiredelements

example

1 Actor/initiator ofaction

This is the subject ofthe sentence

Mandatory developer

2.Condition/Assumption foraction

This define theconditions under whichthe action takes place

when producing requirementsin Word document

3. Action This is a verb Mandatory shall use

4. Constraints ofaction

This qualifies the action

5. Object of action This is the thing actedupon by the actor

Mandatory iSEF CARE Macro V5

6. Object Refinement(or source)

This qualifies the object or any iSEF tool agreed byBNE

7. Action Refinement(or destination)

This further qualifies theaction

8. Other / additionalinfo

Non requirementmaterial

Example: BNEY-SER-038-1 When producing requirements in Word document, developer shall use iSEF CARE Macro V5 or any iSEF tool agreed by BNE.

Most requirements should have 5-7 elements

Relation between development level and product breakdown

A/CDesign process

Airlinesneeds

Major CompDesign process

ItemDesign process

Sub-itemDesign process

Productionproducts

Testproducts

Complexproduct

Developmentproducts

Deploymentproducts

Trainingproducts

Supportproducts

End-products Enabling-products

End-Product

Main Comp.or system

Main Comp.or system

Main Comp.or system

Main Comp.or system

Disposalproducts

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