Review of “Embedded Software” by E.A. Lee Katherine Barrow Vladimir Jakobac

Roadmap Overview Programming Abstraction Limits of current Software Engineering methodologies Actor-Oriented Design Models of Computation Weaknesses of the paper Summary Future Research Challenges

Overview Embedded software differs from traditional software in that it interfaces with and is subject to the constraints of the physical world. Current software engineering methods do not satisfy the unique requirements of embedded software. Actor-oriented design is an abstraction paradigm that addresses the issues of concurrency, communication and time.

Programming Abstraction Properties of embedded software are: timeliness concurrency liveness interfaces heterogeneity reactivity –synchronous languages: Esterel, Lustre, Signal, Argos

Limitations of current design methods Object-oriented design is a procedural abstraction with passive objects Real-time operating systems use microkernels for task scheduling Scheduling techniques are not compositional Real-time CORBA –event handling –real-time scheduling

Actor-oriented Design Abstract syntax defines how a design can be decomposed into interconnected components Concrete syntax is a visual or textual representation of the abstract syntax Models of computation (semantics) –concurrency –varying latencies –abstractions over hardware

Examples of Models of Computation Time Triggered (TT) & Discrete-time (DT) Cp-Cn: indefinitely run processes – signals with data values every clock tick (Scenic) used for digital signal processing Synchronous/Reactive (SR) Cp-Cn: relations btw. I/O signals – signals (at time ticks) used for safety-critical control systems excellent for concurrent models with irregular events vs. limited platforms, limited SW support Discrete Events (DE) Cp-Cn: - signals that carry events placed in time used for specifying HW (HDL), for simulating telecommunications systems (VHDL, Verilog) expensive to implement in SW Continuous Time (CT) Cp-Cn: relations btw. signals – continuous-time signals modeling the physical systems – differential equations

Process Networks (PN), Dataflow (DF) Cp-Cn: processes/threads (computations) – asynchronous messages (flow of data) excellent for signal processing vs. awkward for specifying complicated control logic Rendezvous (CSP) Cp-Cn: processes/threads – synchronous message passing used for C/S database models, multitasking of HW resources good at resource sharing vs. deadlocks Publish and Subscribe Cp-Cn: producer/consumer of events – event streams Finite State Machines (FSM) strictly sequential (not concurrent) Cp-Cn: state/mode – transitions excellent for describing control logic (safety-critical systems) vs. number of states can get very large solution: use FSMs hierarchically combined with concurrent models  “*charts” Examples… (cont.)

Component interface Heterogeneous models Type systems, strong typing –limit component’s interface, affect framework compatibility; poor reuse of components –ensure software correctness; improved run time efficiency, high safety degree Extended types –dynamic properties of components –using automata and polymorphism Reflection on the program dynamics –communication protocols –process state

Weaknesses Components must be designed to the particular framework –limited reusability Communication protocols btw. concurrent processes – type checked or not? Poor organization –objectives of the paper were not clearly stated

Summary Standard abstractions in software development to be abandoned Concurrency and time – first-class status Goal: modules that dynamically reconfigure the system

Further research challenges Frameworks with properties that better match the application domain –reintroduce time –safety and liveness Hardware-software partnership – balance btw. their sequential and parallel execution styles –configurable hardware –networking –hardware and software design techniques that minimize power consumption Extending types –novel syntactic language support Human-computer interaction