Brief introduction to system engineering approach
- 1. ENES 489P Hands-On Systems Engineering Projects Introduction to Systems Engineering Mark Austin E-mail: austin@isr.umd.edu Institute for Systems Research, University of Maryland, College Park – p. 1/3
- 2. Administrative Issues Class Web Page See: http://www.isr.umd.edu/∼austin/ense489p.html Class Syllabus Outlined on the class web page ... Assessment Project presentation and report will count for 60% of the final grade. – p. 2/3
- 3. Lecture 1: Getting Started Topics: 1. Career opportunities in Systems Engineering. 2. Our definition of Systems Engineering. 3. Case Study: Systems Engineering for Modern Buildings. 4. Systems Engineering in Mainstream US Industry. 5. End-to-end Lifecycle Development. 6. Models of Systems Engineering Development (e.g., Waterfall, Spiral). 7. Economics of development. – p. 3/3
- 4. Lecture 1: Getting Started At the end of this lecture you should be able to answer: 1. What is systems engineering? 2. What kinds of problems does the discipline try to solve? 3. Why is systems engineering important? 4. What does a typical systems engineering lifecycle look like? 5. What are the economic consequences of failing to do proper systems engineering? 6. Are there any jobs in Systems Engineering? – p. 4/3
- 5. Career Opportunities in Systems Engineering – p. 5/3
- 6. Our Definition of Systems Engineering Systems engineering is a discipline that lies at the cross-roads of engineering and business concerns. HARDWARE ELEMENTS SOFTWARE ELEMENTS HUMAN ELEMENTS CONSTRAINTS. SYSTEMS REQUIREMENTS , SPECIFICATIONS, AND ...................... ............. ............... ENVIRONMENT OPERATIONAL SYSTEMS ENGINEERING Specific goals are to provide: 1. A balanced and disciplined approach to the total integration of the system building blocks with the surrounding environment. 2. A methodology for systems development that focussed on objectives, measurement, and accomplishment. 3. A systematic means to acquire information, and sort out and identify areas for trade-offs in cost, performance, quality etc.... – p. 6/3
- 7. Practicing Systems Engineers Typical concerns on the design side: 1. What is the required functionality? 2. How well should the system perform? 3. What about cost/econmics? 4. How will functionality/performance be verified and validated? Typical concerns on the management side: 1. What processes need to be in place to manage the development? 2. What kind of support for requirements management will be needed? Learning how to deal with these concerns in a systematic way is a challenging proposition driven, in part, by a constant desire to improve system performance and extend system functionality. – p. 7/3
- 8. Understanding System Complexity To understand a system, you really need to understand: 1. The ways in which it will be used, 2. The environment in which it will operate, and 3. The knowledge, technologies, and methods that go into making it. For a wide range of engineering applications this problem is quite tractable. However as systems become more complex, we need to be strategic in the way we approach design, i.e., points to the importance of: 1. System Decomposition (to simplify design). 2. Abstractions (to simplify decision making in design). 3. Formal Analysis (our understanding of system behavior needs to be right). – p. 8/3
- 9. Understanding System Complexity Strategy: Put original problem aside and focus on understanding the collection of subsystems that make up the orginal system. Improved understanding.. 000 000 000 111 111 111 Subsystem Complex System Component Maybe we can understand this!!! Initially too difficult to understand... Understanding systems through reduction remove details Improved understanding.. Common questions include: 1. What are the subsytems and how are they connected internally? 2. How does the system interact with the surrounding environment? – p. 9/3
- 10. System Assembly via Integration of Abstractions 0000000000 0000000000 0000000000 0000000000 0000000000 1111111111 1111111111 1111111111 1111111111 1111111111 0000000000 0000000000 0000000000 0000000000 0000000000 1111111111 1111111111 1111111111 1111111111 1111111111 Subsystem Complex System Components System assembly through integration of abstractions Increasing importance of technology System functionality Observations Increasing opportunity for reuse of lower level entities Engineering Concerns Increasingly heterogeneous Increasingly homogeneous Increasing use of abstraction Increasing need for formal analysis Increasing range of functionality abstraction abstraction Integration of components Focus on technology abstraction – p. 10/3
- 11. Case Study: SE for Modern Buildings Modern buildings are: ... advanced, self-contained and tightly controlled environments designed to provide services (e.g., transportation, artificial lighting, ..etc.). The design of modern buildings is complicated by: 1. Necessity of performance-based design and real-time management. 2. Many stakeholders (owners, inhabitants), some with competing needs. 3. Large size (e.g., 30,000 occupants; thousands of points of sensing and controls for air quality and fire protection.) 4. Intertwined network structures for the arrangement of spaces, fixed circulatory systems (power, hvac, plumbing), dynamic circulatory systems (flows of energy through rooms; flows of material). – p. 11/3
- 12. Case Study: SE for Modern Buildings Framework for interaction of architectural, structural, control, and networked embedded system design activities. Performance metrics Control System Control View Spatial constraints Feasibility of implementation Security requirements Thermal requirements Electrical requirements Information requirements Networked Embedded Systems View implementation Feasibility of Scheduling of thermal comfort, security, electrical and information services. HVAC components Security components Computer components Electrical components demand. Occupancy Building envelope / structural design of spaces.... Design, layout and connectivity External Factors System Architecture Architecture / Structural View of networked embedded systems. Selection, positioning and connectivity Builiding Networks Design Spatio−temporal constraints External environment Occupant functionality – p. 12/3
- 13. Case Study: SE for Modern Buildings System Level Subsystem Level Component Level Architectural Concerns Form and functionality. Services, access, com- fort. Floor level spaces, po- sitioning of spaces, con- nectivity among spaces. Walls and spaces, por- tals, doorways, windows ... Structural Concerns Structural assemblies, overall system stability Frame, floor, and wall systems. Forces, de- flections. Beam and column el- ements, beam/column joints, material behavior. Electro-mechanical Concerns Access, comfort, safety HVAC, lighting, fire pro- tection Heat exchangers, pipes, elevators, escalators, sprinklers – p. 13/3
- 14. SE in Mainstream US Industry Traditional engineering and systems engineering serve complimentary roles: • Traditional Engineering. Focus on generation of knowledge needed to ceate new technologies and new things. • Systems Engineering. Focus on understanding how existing technologies and things can be integrated together in new ways (...to create new kinds of systems). So here’s the bottom line: ... systems engineers need traditional engineers, and vice versa. – p. 14/3
- 15. SE at the Organizational Level 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 Breadth Depth 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 00000000000000000000000 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 11111111111111111111111 Systems Engineering Simulation Modeling and Networking ..... Systems Tools ..... Strategic planning ..... Finance, Accounting ... disciplines disciplines disciplines Engineering Computer hardware and software. Business Liaison among disciplines Systems analysis and trade−off Liaison among Liaison among Liaison among Focus on: ...liaison among disciplines, supported by formal methods for systems analysis and design. – p. 15/3
- 16. SE at the Project Level Systems are developed by teams of engineers – the team members must be able to understand one-another’s work. Integration of team efforts. 0 1 competing design and market Trade−off cost and performance criteria. Reallocation of system resources. Subsystem 2 Subsystem 3 Subsystem 1 EPA Specification 1 Specification 2 Specification 3 Systems Integration Working System and Test. Team 1 Team 2 Requirements Project ..... Team 3 Req 3 / Spec. 3 Req 2 / Spec. 2 Req 1 / Spec. 1 Development Process Viewpoints Coordination of activities. team development. Separation of concerns for Test Req. EPA Test Verification Validation and Issues Abstractions criteria. Trade studies to balance – p. 16/3
- 17. SE at the Project Level Key concerns: 1. How to gather requirements that might extend beyond functionality, performance and cost (e.g., social concerns, political concerns, long-term sustainability)? 2. Partitioning of the design problem into several levels of abstraction and viewpoints suitable for concurrent development by design teams; 3. Synthesis of good design alternatives from modular components; 4. Integration of the design team efforts into a working system; and 5. Evaluation mechanisms that provide a designer with critical feedback on the feasibility of a system architecture, and make suggestions for design concept enhancement. 6. Formal methods for early validation/verification of systems. – p. 17/3
- 18. SE at the Product Level – p. 18/3
- 19. SE at the Product Level Key concerns: 1. How to describe what a product does? Can this be done formally? 2. How to describe pre-conditions for using a product? 3. How to describe a products interfaces? 4. How to describe various representations (visual, mathematical). – p. 19/3
- 20. End-to-End Lifecycle Development −− Systems Integration Build and Test −− Create Project Concept −− Generate Requirements System Architecting −− Function Analysis −− Requirements Analysis −− System Synthesis −− Validation −− Validation −− Verification Systems Engineering Development −− Physical Design −− Tradeoff Analysis −− Validation −− Verification −− Verification −− Validation System Design Planning and Analysis The principal products of systems engineering development are as follows: • Requirements specification; system (logical) architecture; system (physical) design; the physical system itself. These products are produced by the following processes: • Requirements engineering; system architecting; systems design and integration; optimization and trade-off analysis; validation and verification. – p. 20/3
- 21. End-to-End Lifecycle Development Technical process for system architecting..... System Synthesis Function Analysis Requirements Analysis Control Factors -- Requirements -- Functions -- Reuse of components Assessment of Risks and Uncertainty -- Cost estimate -- Performance estimate -- Schedule System Architecture Needs – p. 21/3
- 22. End-to-End Lifecycle Development The terms system validation and verification refer to two basic concerns, “are we building the right product” and “are we building the product right?” Satisfactory answers to both questions are a prerequisite to customer acceptance. Validation Requirements / Specifications System Design Customer Needs Verification Validation and verification concerns are a prerequisite to customer acceptance. – p. 22/3
- 23. Systems Engineering Processes Pre-defined plans of development ... ... provide the discipline to keep development activities predictable and on track. The project participants know what’s expected and when. Interaction of technical development and engineering management processes CUSTOMER REQUIREMENTS Systems engineering management plan. Specification for the engineering system. Plans and direction. Outcomes/decisions. PRODUCT / SYSTEM DEFINITION During the past 3-4 decades this approach to system development has served many industry sectors (e.g., aerospace) well. – p. 23/3
- 24. Systems Engineering Processes Engineering/Systems Engineering Activities and Artifacts Engineering Activity Systems Engineering Activity Artifact Requirements Analysis Requirements Analysis Requirements baseline and specification. Architecture Function/behavior anal- ysis Logical Architecture. Design Synthesis Physical Architecture and Design – p. 24/3
- 25. Systems Engineering Processes Systems Engineering Management Activities and Artifacts Management Activity Systems Management Activity Artifact Requirements Management Requirements Manage- ment Requirements baseline and specification. Configuration Management Planning of activities and tasks. Communi- cate compliance status Work products Baseline Management · · · · · · – p. 25/3
- 26. Waterfall Model of Development The waterfall model works well when: ... problem and solution method are well understood, requiring no large-loop corrections to development problems. – p. 26/3
- 27. Iterations of Waterfall Development Iterations of Waterfall Development..... Version 3..... Version 1 Version 2 Limitations of Waterfall Model • Changing requirements proved to be the biggest cause of cost overruns and schedule slips in the waterfall era. • Users were found to be unable to define the requirements of a complex system without having had hands-on previous experience with the system – A Catch 22. – p. 27/3
- 28. Spiral Model of Systems Development Spiral model corresponds to risk oriented iterative enhancement. Service Design Detailed Design and alternatives. Determine objectives Determine objectives and alternatives. Integration and Test Risk Analysis Risk Analysis Risk Analysis Plan next phase Plan next phase Plan next phase Testing of components Requirements validation Prototype 1 Prototype 2 Operational Prototype Requirements plan Lifecycle plan Preliminary SIMULATION AND MODELING. REVIEW Categories of risk include: technical risk, schedule risk, cost risk, programmatic risk. – p. 28/3
- 29. V-Model of Systems Development Flowdown of requirements in the V-Model of system development. Design Problem Definition Component Test Subsystem Test System Test Test Stakeholder Verify the system Validate the system Flowdown of Requirements Stakeholder Requirements System Requirements System−Level Design Subsystem Requirements Component Requirements Design Component Subsystem−Level Design Validate the system Allocate requirements to components. Implementation and Test – p. 29/3
- 30. Systems Engineering at General Electric Functional flow block diagram for the core technical process at GE. Iterate to find feasible solution Model Behavior Create Create Structure Model Measures Effectiveness Define Improve lower level defects at Assess Available Information Create Sequential Build − and Test Plan Perform Trade−off Analysis Check design for defects Reduce defects via reallocation of resources – p. 30/3
- 31. Economics of Development Funding Commitments in Product Life-Cycle 75 50 25 100 Cumulative Percentage Commence Production Funds Expended Funds Committed Product Lifecycle Preliminary Design – p. 31/3
- 32. Economics of Development Knowledge Gap in Systems Development 75 50 25 100 Cumulative Percentage Commence Production Product Lifecycle Funds Committed Funds Expended Knowledge Knowledge Gap Ease of change Preliminary Design – p. 32/3
- 33. Economics of Development Cost of Correcting Design Errors Project Phase Bug Description Relative Cost Design Design Team 1 Write and Test Designer 10-20 Quality Assurance QA Personnel 70-100 Shipment to Customer Customer Very-expensive – p. 33/3