1. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 1 Systems Engineering l Designing, implementing, deploying and operating systems which include hardware, software and people l Objectives To explain why system software is affected by broader system engineering issues To introduce the concept of emergent system properties such as reliability and security To explain why the systems environment must be considered in the system design process

2. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 2 What is a system? l A purposeful collection of inter-related components working together towards some common objective. l A system may include software, mechanical, electrical and electronic hardware and be operated by people. l System components are dependent on other system components l The properties and behaviour of system components are inextricably inter-mingled

3. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 3 What is a system? l A purposeful collection of inter-related components working together towards some common objective. l A system may include software, mechanical, electrical and electronic hardware and be operated by people. l System components are dependent on other system components l The properties and behaviour of system components are inextricably inter-mingled

4. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 4 Problems of systems engineering l Large systems are usually designed to solve ‘nasty’ problems l Systems engineering requires a great deal of co-ordination across disciplines Almost infinite possibilities for design trade-offs across components Mutual distrust and lack of understanding across engineering disciplines l Systems must be designed to last many years in a changing environment

5. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 5 Software and systems engineering l The proportion of software in systems is increasing Software-driven general purpose electronics is replacing special-purpose systems l Problems of systems engineering are similar to problems of software engineering l Software is (unfortunately) seen as a problem in systems engineering Many large system projects have been delayed because of software problems

6. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 6 Emergent properties l Properties of the system as a whole rather than properties that can be derived from the properties of components l Emergent properties are a consequence of the relationships between system components l They can therefore only be assessed and measured once the components have been integrated into a system

7. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 7 Examples of emergent properties l The overall shape and size of a physical system This depends on the composition of components. l The reliability of the system This depends on the reliability of system components and the relationships between the components. l The usability of a system This is a complex property which is not simply dependent on the system hardware and software but also depends on the system operators and the environment where it is used.

8. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 8 Types of emergent property l Functional properties These appear when all the parts of a system work together to achieve some objective For example, a bicycle has the functional property of being a transportation device once it has been assembled from its components l Non-functional emergent properties Examples are reliability, performance, safety, and security These relate to the behaviour of the system in its operational environment They are often critical for computer-based systems as failure to achieve some minimal defined level in these properties may make the system unusable.

9. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 9 l Because of component inter-dependencies, faults can be propagated through the system l System failures often occur because of unforeseen inter-relationships between components Honey-baked ham l It is probably impossible to anticipate all possible component relationships Hardware Software Operator System reliability

10. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 10 Reliability relationships l Hardware failure can generate spurious signals that are outside the range of inputs expected by the software l Software errors can cause alarms to be activated which cause operator stress and lead to operator errors l The environment in which a system is installed can affect its reliability E.g., placement of a system intended to operate at room temperature near an air conditioner

11. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 11 The ‘shall-not’ properties l Properties such as performance and reliability can be measured l However, some properties are properties that the system should not exhibit Safety - the system should not behave in an unsafe way Security - the system should not permit unauthorised use l Measuring or assessing these properties is very hard How do you know you are safe or secure?

12. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 12 System architecture modelling l An architectural model presents an abstract view of the sub-systems making up a system l May include major information flows between sub-systems l Usually presented as a block diagram l May identify different types of functional component in the model

13. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 13 Functional system components l Sensor components l Actuator components l Computation components l Communication components l Co-ordination components l Interface components  All are now usually software controlled

14. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 14 Hierarchies of Systems

15. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 15 Intruder alarm system

16. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 16 Component types in alarm system l Sensor Movement sensor, Door sensor l Actuator Siren l Communication Telephone caller l Coordination Alarm controller l Interface Voice synthesizer

17. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 17 ATC system architecture

18. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 18 Inter-disciplinary involvement

19. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 19 Embedded systems l Computing systems are everywhere l Most of us think of “desktop” computers PC’s Laptops Mainframes Servers l But there’s another type of computing system Far more common...

20. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 20 Embedded systems overview l Embedded computing systems Computing systems embedded within electronic devices Hard to define. Nearly any computing system other than a desktop computer Billions of units produced yearly, versus millions of desktop units Perhaps 50 per household and per automobile Computers are in here... and here... and even here... Lots more of these, though they cost a lot less each.

21. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 21 A “short list” of embedded systems And the list goes on and on Anti-lock brakes Auto-focus cameras Automatic teller machines Automatic toll systems Automatic transmission Avionic systems Battery chargers Camcorders Cell phones Cell-phone base stations Cordless phones Cruise control Curbside check-in systems Digital cameras Disk drives Electronic card readers Electronic instruments Electronic toys/games Factory control Fax machines Fingerprint identifiers Home security systems Life-support systems Medical testing systems Modems MPEG decoders Network cards Network switches/routers On-board navigation Pagers Photocopiers Point-of-sale systems Portable video games Printers Satellite phones Scanners Smart ovens/dishwashers Speech recognizers Stereo systems Teleconferencing systems Televisions Temperature controllers Theft tracking systems TV set-top boxes VCR’s, DVD players Video game consoles Video phones Washers and dryers

22. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 22 Some common characteristics of embedded systems l Single-functioned Executes a single program, repeatedly l Tightly-constrained Low cost, low power, small, fast, etc. l Reactive and real-time Continually reacts to changes in the system’s environment Must compute certain results in real-time without delay

23. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 23 An embedded system example -- a digital camera Microcontroller CCD preprocessorPixel coprocessor A2D D2A JPEG codec DMA controller Memory controllerISA bus interfaceUARTLCD ctrl Display ctrl Multiplier/Accum Digital camera chip lens CCD Single-functioned -- always a digital camera Tightly-constrained -- Low cost, low power, small, fast Reactive and real-time -- only to a small extent

24. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 24 Design challenge – optimizing design metrics l Obvious design goal: Construct an implementation with desired functionality l Key design challenge: Simultaneously optimize numerous design metrics l Design metric A measurable feature of a system’s implementation Optimizing design metrics is a key challenge

25. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 25 Design challenge – optimizing design metrics l Common metrics Unit cost: the monetary cost of manufacturing each copy of the system, excluding NRE cost NRE cost (Non-Recurring Engineering cost): The one-time monetary cost of designing the system Size: the physical space required by the system Performance: the execution time or throughput of the system Power: the amount of power consumed by the system Flexibility: the ability to change the functionality of the system without incurring heavy NRE cost

26. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 26 Design challenge – optimizing design metrics l Common metrics (continued) Time-to-prototype: the time needed to build a working version of the system Time-to-market: the time required to develop a system to the point that it can be released and sold to customers Maintainability: the ability to modify the system after its initial release Correctness, safety, many more

27. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 27 27 Design metric competition -- improving one may worsen others l Expertise with both software and hardware is needed to optimize design metrics Not just a hardware or software expert, as is common A designer must be comfortable with various technologies in order to choose the best for a given application and constraints SizePerformance Power NRE cost Microcontroller CCD preprocessorPixel coprocessor A2D D2A JPEG codec DMA controller Memory controllerISA bus interfaceUARTLCD ctrl Display ctrl Multiplier/Accum Digital camera chip lens CCD Hardware Software

28. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 28 Robotic System Proxímetro IR Cámara de visión (pan-and-tilt) Unidad inercial Módem Bluetooth BlueSMiRF (WRL-00582) Video

29. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 29 Robotic System Mecanica + Control + Computacion – Ingeniería de reversa (servomecanismos, controlador, programación) – Mecánicas (cabeza, tobillos), comunicación inalámbrica, hardware para control, – Sistema de programación, interfaz bidireccional para los servos… Percepción – Sensores: Visión, Infrarrojos, Unidad Inercial – Reconstrucción 3D Monocular SLAM Visual – Odometría visual, Navegación Inercial (IMU), SLAM Visual, etc. Obtención de Modelos y Desarrollo de Simulador – Geométrico, Cinemático, Dinámico Control Cinemático y Dinámico – Control articular, control cinemático, control dinámico (ZMP, FRI) Aplicaciones – Reconocer pelota, Evitar y reconocer obstáculos y marcas, Caminar hacia la pelota, conducir la pelota, Penalties (tirar y parar), coordinacion con otros robots, Pruebas RoboCup, Futbolistas.

30. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 30 Robotic System Application

31. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 31 Electric SCADA System

32. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 32 Web-Based Software System http://people.csail.mit.edu/hal/mobile-apps-spring-08/videos/flare.mpg

33. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 33 Key points l System engineering involves input from a range of disciplines l Emergent properties are properties that are characteristic of the system as a whole and not its component parts l System architectural models show major sub-systems and inter-connections. They are usually described using block diagrams l System component types are sensor, actuator, computation, co-ordination, communication and interface

34. ©Sommerville 2000, Medvidovic 2006, Mejia 2009Systems EngineeringSlide 34 l Systems engineering is hard! There will never be an easy answer to the problems of complex system development l Software engineers do not have all the answers but may be better at taking a systems viewpoint l Disciplines need to recognise each other’s strengths and actively rather than reluctantly cooperate in the systems engineering process Conclusion