1. + Overview of Embedded Systems & Embedded Software Engineering CSCI 589: Software Engineering for Embedded Systems

2. + Software Qualities Qualities (a.k.a. “ilities”) are goals in the practice of software engineering External vs. Internal qualities Product vs. Process qualities

3. + External vs. Internal Qualities External qualities are visible to the user reliability, efficiency, usability Internal qualities are the concern of developers they help developers achieve external qualities verifiability, maintainability, extensibility, evolvability, adaptability

4. + Product vs. Process Qualities Product qualities concern the developed artifacts maintainability, understandability, performance Process qualities deal with the development activity products are developed through process maintainability, productivity, timeliness

5. + Some Software Qualities Correctness ideal quality established w.r.t. the requirements specification absolute Reliability statistical property probability that software will operate as expected over a given period of time relative

6. + Some Software Qualities (cont.) Robustness “reasonable” behavior in unforeseen circumstances subjective a specified requirement is an issue of correctness; an unspecified requirement is an issue of robustness Usability ability of end-users to easily use software extremely subjective

7. + Some Software Qualities (cont.) Understandability ability of developers to easily understand produced artifacts internal product quality subjective Verifiability ease of establishing desired properties performed by formal analysis or testing internal quality

8. + Some Software Qualities (cont.) Performance equated with efficiency assessable by measurement, analysis, and simulation Evolvability ability to add or modify functionality addresses adaptive and perfective maintenance problem: evolution of implementation is too easy evolution should start at requirements or design

9. + Some Software Qualities (cont.) Reusability ability to construct new software from existing pieces must be planned for occurs at all levels: from people to process, from requirements to code Interoperability ability of software (sub)systems to cooperate with others easily integratable into larger systems common techniques include APIs, plug-in protocols, etc.

10. + Some Software Qualities (cont.) Scalability ability of a software system to grow in size while maintaining its properties and qualities assumes maintainability and evolvability goal of component-based development

11. + Some Software Qualities (cont.) Heterogeneity ability to compose a system from pieces developed in multiple programming languages, on multiple platforms, by multiple developers, etc. necessitated by reuse goal of component-based development Portability ability to execute in new environments with minimal effort may be planned for by isolating environment-dependent components necessitated by the emergence of highly-distributed systems (e.g., the Internet) an aspect of heterogeneity

12. + Software Process Qualities Process is reliable if it consistently leads to high- quality products Process is robust if it can accommodate unanticipated changes in tools and environments Process performance is productivity Process is evolvable if it can accommodate new management and organizational techniques Process is reusable if it can be applied across projects and organizations

13. + Assessing Software Qualities Qualities must be measurable Measurement requires that qualities be precisely defined Improvement requires accurate measurement Currently most qualities are informally defined and are difficult to assess

14. + Software Engineering “ Axioms ” Adding developers to a project will likely result in further delays and accumulated costs Basic tension of software engineering better, cheaper, faster — pick any two functionality, scalability, performance — pick any two The longer a fault exists in software the more costly it is to detect and correct the less likely it is to be properly corrected Up to 70% of all faults detected in large-scale software projects are introduced in requirements and design detecting the causes of those faults early may reduce their resulting costs by a factor of 100 or more

15. + Embedded Software Interaction with physical world Executes on devices, not “ computers ” Written by engineers who are domain experts Current methods offered by computer scientists are not always satisfactory Complexity and size of embedded software are growing rapidly severe constraints remain

16. + Properties of Embedded Software Timeliness speed up in software not hardware Concurrency Predictability and adaptability Liveness Non-terminating Interfaces Processes not procedures Heterogeneity Reactivity Continuously changing to adapt to changing environment

17. + What Is an Embedded System? A computer whose end function is not to be a computer Automobiles ABS “radio” Engine Digital cameras Household appliances TVs A combination of computer hardware and software, and perhaps additional mechanical or other parts, designed to perform a dedicated function.

18. + Put Another Way An embedded system is a specialized computer system that is usually integrated as part of a larger system consists of a combination of hardware and software components forms a computational engine performs a specific function constrained in its application reactive time-constrained

19. + Modern Embedded Systems Novel computing platforms Smart phones Mobile robots Motes Sensors Novel usage scenarios Search-and-rescue Environment exploration Traffic management Medicine / Assisted living Wireless sensor nets Mobile grids Novel SE challenges Distribution Decentralization Mobility Heterogeneity Resource constraints Context awareness Real-time requirements

20. + Typical Embedded System

21. + Reactive Systems Respond to the environment via sensors Control the environment using actuators Must achieve performance consistent with the environment periodic vs. aperiodic eventse

22. + Embedded Systems Functions Monitor and react to environment Control the environment Process information Application-specific behavior Optimization Resource-economy Real-time performance Multi-rate performance

23. + Interfacing with the Environment

24. + Car Window Lift Aided by Sensors

25. + Car Window Lift – Software Design

26. + Car Front Light Mgmt System

27. + More Cars

28. +

29. + Real-Time Computing

30. + Car Shift Control System - HRTC

31. + Traditional vs. RT Systems System capacity High throughput vs. Schedulability and ability to meet deadlines Responsiveness Fast average vs. Ensured worst-case latency and response time Overload Fairness to all vs. Stability, priority to important tasks

32. + RT Events Asynchronous unpredictable Synchronous predictable and precisely regular Isochronous regular within a time window

33. + RT System Design Challenges Response time factors Suitability of architecture Processing element power Communication speed Adequacy of scheduling system Failure recovery causes processor failures board failures link failures invalid behavior of external environment interconnectivity failure

34. + Building an Embedded System DesktopEmbedde d

35. + Ferrari’s Build Process

36. + Embedded vs. Desktop Systems Energy efficiency Custom power requirements Security Reliability Environment extremes Efficient UI

37. + Hardware Abstraction Layer (HAL)

38. + Embedded System Development

39. + Challenges for SE Resource constraints Demand highly efficient computation, communication, and memory footprint Demand unorthodox solutions e.g., off-loading components Hardware and software heterogeneity Proprietary operating systems Dialects of programming languages Device-specific data formats Lack of support for inter-device interaction Lack of support for code mobility

40. + From Design to Implementation Architectures provide high-level concepts Components, connectors, ports, events, configurations Programming languages provide low-level constructs Variables, arrays, pointers, procedures, objects Bridging the two often is an art-form Middleware can help “ split the difference ” Existing middleware technologies Support some architectural concepts (e.g., components, events) but not others (e.g., connectors, configurations) Impose particular architectural styles End result  architectural erosion Architecture does not match the implementation

41. + How do we get from

42. +

43. + to How do we get from

44. + to ? How do we get from

45. + Architectural Middleware Native support for architectural concepts as middleware constructs System design support via an accompanying ADL Quality assurance via analysis and simulation of architectural models Round-trip development from architecture to implementation and back Automated transformation of architectural models to implementations

46. + Prism-MW An architectural middleware for ES Supports architecture-based software development Implementation of a software system in terms of its architectural elements Efficient Scalable Flexible and Extensible Allows us to cope with heterogeneity Supports arbitrary architectural styles

47. + Architectural Middleware Architecture

48. + Prism-MW Design

49. + Architecture – Ar1 class DemoArch { static public void main(String argv[]) { Architecture arch = new Architecture (”Ar1"); // create components Component a = new CompA ("A"); Component b = new CompB ("B"); Component c = new CompC (“C"); // create connectors Connector d = new Connector(“D"); // add components and connectors arch.addComponent(a); arch.addComponent(b); arch.addComponent(c); arch.addConnector(d); // establish the interconnections arch.attach(a, d); arch.attach(b, d); arch.attach(d, c); } } Using Prism-MW Comp BComp A Comp C Connector D Comp AComp B Comp C

50. + Architecture - DEMO Component B handles the event and sends a response public void handle(Event e) { if (e.equals("Event_C")) {... Event e1= new Event("RSP_to_C “, REPLY); e1.addParameter("response", resp); send(e1); }... } Send (e1) Using Prism-MW Component C sends an event Event e = new Event ("Event_C “, REQUEST); e.addParameter("param_1", p1); send (e); Send (e) Comp BComp A Comp C Connector D

51. + Event Dispatching Comp B Comp A Comp C E 1 E 2 E 3 E 4 E 5 send Event handle Event Thread Pool E X E X Scaffold Topology-based routing Easy redeployment and redistribution of components onto different hardware configurations 2 E

52. + Prism-MW Performance Efficiency 1750 SLOC 4600 B for the core 160 B per component 240 B per connector 70 B per weld 160 B per event 240 B per event parameter 100 001 components 100 000 connectors Total event roundtrip time 2.7 sec … Scalability Numbers of devices, threads and events not limited by Prism-MW Numbers of components and connectors available_memory – middleware_size average_element_size

53. + Prism-MW Benchmarks on a PC

54. + External Adoption Troops Deployment Simulation US Army MIDAS Bosch Research and Technology Center

55. + MIDAS Architecture