Principles of Principles of

Engineering System DesignEngineering System Design

Dr T Asokan

asok@iitm.ac.in

T Asokan

Principles of

Engineering System Design

Dr T Asokanasok@iitm.ac.in044-2257 4707

Lecture 4: System Design Process

• F ocus of S ystems E ngineering

– F rom O riginal Need

– T o F inal P roduct

• T he Whole S ys tem

• T he F ull S ys tem L ife C ycle

• F ocus of S ystems E ngineering

– F rom O riginal Need

– T o F inal P roduct

• T he Whole S ys tem

• T he F ull S ys tem L ife C ycle

Need

Operations Concept

Functional Requirements

System Architecture

Allocated Requirements

Detailed Design

Implementation

Test & Verification

NeedNeed

Operations ConceptOperations Concept

Functional RequirementsFunctional Requirements

System ArchitectureSystem Architecture

Allocated RequirementsAllocated Requirements

Detailed DesignDetailed Design

ImplementationImplementation

Test & VerificationTest & Verification

• F ocus of C omponent E ngineering

• O n Detailed Des ign

• And Implementation

• F ocus of C omponent E ngineering

• O n Detailed Des ign

• And Implementation

• What needs are we trying to fill?• What is wrong with the current s ituation?• Is the need clearly articulated?

• Who are the intended users?• How will they use our products?• How is this different from the present?

• What specific capability will we provide?• T o what level of detail?• Are element interfaces well defined?

• What is the overall plan of attack?• What elements make up the overall approach?• Are these complete, logical, and cons is tent?

• Which elements address which requirements?• Is the allocation appropriate?• Are there any unnecessary requirements?

• Are the details correct?• Do they meet the requirements?• Are the interfaces satisfied?

• Will the solution be satisfactory in terms of cost and schedule?

• C an we reuse existing pieces?

• What is our evidence of success?• Will the customer be happy?• Will the users ’ needs be met?

• What needs are we trying to fill?

• What is wrong with the current s ituation?

• Is the need clearly articulated?

• Who are the intended users?

• How will they use our products?

• How is this different from the present?

• What specific capability will we provide?

• To what level of detail?

• Are element interfaces well defined?

• What is the overall plan of attack?

• What elements make up the overall approach?

• Are these complete, logical, and cons is tent?

• Which elements address which requirements?

• Is the allocation appropriate?

• Are there any unnecessary requirements?

• Are the details correct?

• Do they meet the requirements?

• Are the interfaces satisfied?

• Will the solution be satisfactory in terms of cost and schedule?

• C an we reuse existing pieces?

• What is our evidence of success?

• Will the customer be happy?

• Will the users ’needs be met?

• F ocus of S ystems E ngineering

– F rom O rig inal Need

– T o F inal P roduct

• T he Whole S ystem

• T he F ull S ystem L ife C ycle

• F ocus of S ystems E ngineering

– F rom O rig inal Need

– T o F inal P roduct

• T he Whole S ystem

• T he F ull S ystem L ife C ycle

Need

Operations Concept

Functional Requirements

System Architecture

AllocatedRequirements

Detailed

Design

Implementation

Test & Verification

•F ocus of C omponent E ng ineering

•O n Detailed Des ign

•And Implementation

•F ocus of C omponent E ng ineering

•O n Detailed Des ign

•And Implementation

Six functions of Design Process

2. Develop the system functional architecture

1. Define system level design problem : Originating requirements development

3. Develop the system physical architecture

4. Develop the system operational architecture

5. Develop the interface architecture

6. Define the qualification system for the system

Development phase, manufacturing phase, deployment phase, training phase, operation or maintenance phase, refinement, retirement phase.

Life cycle

DefineRequirements

DefineRequirements

InvestigateAlternativesInvestigateAlternatives

Full-ScaleDesign

Full-ScaleDesign

ImplementationImplementationIntegration

& TestIntegration

& Test

Operation, Maintenance& Evaluation

Operation, Maintenance& Evaluation

Retirement,Disposal &

Replacement

Retirement,Disposal &

Replacement

The systemlife cycle

The systemlife cycle

DefineRequirements

DefineRequirements

InvestigateAlternativesInvestigateAlternatives

Full-ScaleDesign

Full-ScaleDesign

ImplementationImplementationIntegration

& TestIntegration

& Test

Operation, Maintenance& Evaluation

Operation, Maintenance& Evaluation

Retirement,Disposal &

Replacement

Retirement,Disposal &

Replacement

The systemThe systemlife cyclelife cycle

The systemThe systemlife cyclelife cycle

Define System Level Design Problem

• Operational Concept• External Systems• Originating Requirements• Objectives hierarchy• Documentation• Requirement management

1. Define System Level Design Problem

Major Input: Stake holders’ inputs

Major output: Originating requirements, Operational concept

• An operational concept is a vision for what the system is (in general terms). It is a statement of mission requirements, and a description of how the system will be used.

It includes:

•Information about how the system will be developed, operated and retired (from the perspective of the system’s stakeholders).

•A collection of scenarios.

•Systems interaction with other systems.

T Asokan ED309

Operational concepts for landing on the moon

T Asokan ED309

Operational Concept Scenario- Example: Passenger lift

Passengers (including mobility, hearing, visually challenged) request up service, receive feed back that their request was accepted, receive input that the elevator car is approaching, and then that an entry opportunity is available, enter elevator car, request floor, receive feedback that their request was accepted, receive feedback that the door is closing, receive feedback about what floor the elevator is stopping, receive feedback that an exit opportunity is available, and exit elevator with no physical impediments.

Scenario 1

Scenario 2

Scenario 3

Scenario 4

Scenario 5

Emergency situation

Fire

Auto-close

Breakdown

Overload

maintenance

T Asokan ED309

Scenario Description

Input/Output Trace Passenger ElevatorUp service request

feedback

Floor request

Exit opportunity

Input/output trace for scenario 1

T Asokan ED309

External Systems Diagram

It is the Model of the interaction of the system with other systems (external) in the relevant contexts, thus providing a definition of the system’s boundary in terms of the system’s inputs and outputs.

Purpose: Explicitly define the systems boundary and needed interfaces.

Systems/Mechanisms

1. Elevator System

2. Passengers

3. Maintenance personnel

4. Building

System Function

Provide elevator services

Request and use elevator services

Maintain elevator services

Provide structural support

T Asokan ED309

External Systems Diagram

Provide Elevator Services

Request Elevator Services

Use Elevator Services

Maintain Elevator Services

Provide structural support

PassengersElevator system

Maintenance Personnel

Building

Building regulations

T Asokan ED309

Objectives Hierarchy

• Stakeholders would be willing to pay to obtain increased performance on any of these objectives.

• Developed by defining the natural subsets of the fundamental objectives

The hierarchy of objectives that are important to the system’s stakeholders in a value sense.

• Usually has two to five levels. Additional information like value weights, value curves etc. are added for each objective.

• Acts as a corner stone for trade-off studies • To be developed for each phase of the life cycle of the system.

• An important tool in the decision making process

T Asokan ED309

T Asokan ED309

Requirements categoriesOriginating requirements (OR): Derived from operational needs, operational requirements are those top-level statements defined in language that is understandable to stakeholders, leaving substantial room for design flexibility.Derived requirementsDefined by system engineering team in engineering terms during the design process.

Mission requirements

Originating requirements

Implied RequirementsRequirements not specifically identified in the OR but can be inferred based upon the available information.

Emergent Requirements

System RequirementsComponent

Requirements

Configuration Item Requirements

Derived

requirements

Requirements that are not even hinted at in the OR but whose presence is made known by stakeholders later in the system engineering process.

Mission requirements

Originating requirements

System Requirements

Component Requirements

Configuration Item Requirements

Derived

requirements