Principles of Engineering System Design

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

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

4. 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? Focus of Systems Engineering From Original Need To Final Product The Whole System The Full System Life Cycle Need Operations Concept Functional Requirements System Architecture AllocatedRequirements • Focus of Component Engineering • On Detailed Design • And Implementation Detailed Design Implementation Test & Verification

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

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

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

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

9. Function Inputs Outputs 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

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

11. Operational concepts for landing on the moon T Asokan ED309

12. Operational Concept Scenario- Example: Passenger lift Scenario 1 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

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

14. Scenario Description Input/Output Trace Passenger Elevator Up service request feedback Floor request Input/output trace for scenario 1 Exit opportunity T Asokan ED309

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

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

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

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

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

22. T Asokan ED309

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

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

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