Engineering System Design Principles of Engineering System Design Dr T Asokan asok@iitm.ac.in

Engineering System Design Principles of Engineering System Design Lecture 4: System Design Process Dr T Asokan asok@iitm.ac.in 044-2257 4707 T Asokan

What needs are we trying to fill? What is wrong with the current situation? 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 consistent? 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? Can we reuse existing pieces? What is our evidence of success? Will the customer be happy? Will the users’ needs be met? Need Focus of Systems Engineering From Original Need To Final Product The Whole System The Full System Life Cycle Operations Concept Functional Requirements System Architecture Allocated Requirements Focus of Component Engineering On Detailed Design And Implementation Detailed Design Implementation Test & Verification

Six functions of Design Process Define system level design problem : Originating requirements development 2. Develop the system functional architecture 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

Operation, Maintenance Operation, Maintenance Define Requirements Investigate Alternatives Full-Scale Design Implementation Integration & Test Operation, Maintenance & Evaluation Retirement, Disposal & Replacement The system life cycle Define Requirements Investigate Alternatives Full-Scale Design Implementation Integration & Test Operation, Maintenance & Evaluation Retirement, Disposal & Replacement The system life cycle Life cycle Development phase, manufacturing phase, deployment phase, training phase, operation or maintenance phase, refinement, retirement phase.

Define System Level Design Problem Operational Concept External Systems Originating Requirements Objectives hierarchy Documentation Requirement management

Define System Level Design Problem Major Input: Stake holders’ inputs Major output: Originating requirements, Operational concept

Function Inputs Outputs Define system boundary with Ext. systems Develop operational concept Stakeholders’ input Operational concept Define system boundary with Ext. systems System boundary, inputs, outputs. Develop system objectives hierarchy Oper. Concept, stakeholder input Objectives hierarchy Develop, analyse and refine requirements. (originating and system) Originating and system requirements Ensure requirements feasibility System engg. Team input Design feasibility Define qualification system requirements Test system requirements Obtain approval of system documentation Originating and system requirements documents

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.

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. T Asokan ED309

Scenario 2 Emergency situation Fire Auto-close Breakdown Overload maintenance Scenario 3 Scenario 4 Scenario 5

Input/output trace for scenario 1 Scenario Description Input/Output Trace Passenger Elevator Up service request feedback Floor request Input/output trace for scenario 1 Exit opportunity 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. T Asokan ED309

Systems/Mechanisms Elevator System Passengers Maintenance personnel Building System Function Provide elevator services Request and use elevator services Maintain elevator services Provide structural support

External Systems Diagram Building regulations Request Elevator Services Provide Elevator Services Use Elevator Services Maintain Elevator Services Provide structural support Elevator system Maintenance Personnel Building Passengers T Asokan ED309

Objectives Hierarchy The hierarchy of objectives that are important to the system’s stakeholders in a value sense. 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 T Asokan ED309

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

Originating requirements Requirements categories Originating 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 requirements Defined by system engineering team in engineering terms during the design process. Mission requirements Originating requirements T Asokan ED309

Emergent Requirements Implied Requirements Requirements not specifically identified in the OR but can be inferred based upon the available information. Emergent 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. System Requirements Derived requirements Component Requirements Configuration Item Requirements

Originating requirements Mission requirements Originating requirements System Requirements Derived requirements Component Requirements Configuration Item Requirements