120 likes | 238 Views
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.
E N D
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
Examples… (cont.) • Process Networks (PN), Dataflow (DF) • Cp-Cn: processes/threads (computations) – asynchronous messages (flow of data) • excellent for signal processingvs. 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”
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