Pr

1
Case Study
Basic Introduction
V V
System Engineering
Case Study
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 ENGINEERINGconcerns
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
EIA-ANSI 632 Processes for Engineering a System
EIA 632

Systems Engineering
ISO 15288
98
Systems Engineering
94
Life cycle processes
gt 2000
IEEE 1220
Application Management
MIL STD 499B
of Systems Engineering Process
94/95
Systems Engineering
94
MIL STD 499A
Engineering Management
74
MIL STD 499A
Engineering Management
69
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
Consists of
performs
performs
The diagram below (EIA 632) implicitly includes
those developing, producing, testing, using,
supporting and ensuring the extension of life as
well as those training ...
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
PURCHASER REQUIREMENTS
REQUIREMENTS OF OTHER STAKEHOLDERS
SYSTEM REQUIREMENTS
allocated
allocated
allocated
PHYSICAL SOLUTION REPRESENTATION
LOGICAL SOLUTION REPRESENTATION
source of
derived
derived
DERIVED REQUIREMENTS
DESIGN SOLUTION
allocated
defined by
SPECIFIED REQUIREMENTS
20
Consistent and complete set of processes (EIA
632)
21
The baseline applicable to the project
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 Youll 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

24
Systems approach applied to the characterization
of the commercial aircraft domain
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
25
Decisive factors for the design of a commercial
aircraft
26
Commercial Aircraft System Breakdown and System
Boundary
World Air Transport System Commercial Air
Transport System Customer Airlines External
Suppliers Regulatory agencies, ...
Commercial Aircraft system
27
Commercial Air Transport System Architecture
Commercial Air Transport System
Aircraft System
Other operational Elements
Environmental segment
Mechanical segment
Propulsion segment
Auxiliary segment
Airframe segment
Avionics segment
Electrical segment
Interiors segment
Flight Controls
Hydraulic Power
Landing Gears
28
Life Cycle Framework
29
Life Cycle Stages
ANSI / EIA 632
JCAWG Guidelines
Assessment of Opportunities
Assessment of Opportunities and Marketing
Investment Decision
Investment Management
System Develop- ment and Certification
System Concept Development
Aircraft System Development Life Cycle
Subsystem Design and Pre-Deployment
Subsystem Development
Production Sustaining Disposal
Deployment, Operations, Support, and Disposal
30
Commercial Aircraft Process Relationship
31
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

32
Relationships between Validation, Certification
and Verification in the Commercial Aircraft
Domain
33
Status of the document

• Draft Version 1.2a published in July 2000
• Document is available at http//www.incose.org/sea
  tc/
• Next revision planned for Jan 2004

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)

• 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

• 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.

36
Introduction (3)

• 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 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.

37
What is a requirement?
38
Requirement structure richness
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
39
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
40
Thanks for you Attention Always have a SE view
, if not the whole , think of the framework