Case Study System Engineering Basic IntroductionV &V Case Study.
Post on 20-Dec-2015
235 Views
Preview:
Transcript
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
top related