Embedded Software

1
Embedded Software

• Paper by Edward A. Lee
• Presented by Aniket Daptari
  Lijuan Yang
• Sep 22, 2003

2
Software v/s Embedded Software

• Software the traditional notion
• Math functions map input to output.
• Mechanism of function not as imp as the abstract
  properties.

• Embedded Software
• Interaction with physical world.
• Executes on machines not computers.

3
The problem!

• Unlike conventional software.
• Written by engineers who are domain experts, not
  CScitists.
• Current methods offered by CScitists are not
  satisfactory.
• Complexity and size of ESW is growing rapidly
  severe constraints remain.

4
Properties of ESW

• Timeliness speed up in software not hardware.
• Concurrency Current methods not reliable.
  Predictability and adaptability.
• Liveness Non terminating.
• Interfaces Processes not procedures.
  Temporal/dynamic properties in OOP reqd.
• Heterogeneity -
• Reactivity Continuously changing to adapt to
  changing environment.

5
Limitations of current SE Methods

• Object Orientation Procedures are terminating.
  Objects are passive.
• Hardware Design Highly constrained.
• RTOS Hand built microkernels for task
  scheduling.Priority based-inappropriate.
• ROOM Required parameters hard to predict
  accurately enough.

6
Authors proposed solution

• The Actor Oriented Approach
• Actors, Ports, Interface, Model of Computation.
• Syntaxes and semantics.

7
To be Contd

• Details of the approach and further

8
Actor-Oriented Design

• Actor
• Encapsulation of parameterized actions
• Interface defined by ports and parameters
• Port
• Communication between input and output data
• Without call-return semantics
• Model of computation
• Communication semantics among ports
• Flow of control
• Implementation is a framework
• Examples
• Simulink(The MathWorks)
• LabVIEW ( from National Instruments)
• Easy 5x (from Boeing)
• ROOM(Real-time object-oriented modeling)
• ADL(Wright)

9
Comparing with Object/middleware-oriented design

• Object/middleware-oriented design
• Object abstraction, class inheritance, and method
  call interfaces
• Flow of control
• Ignore system properties such as concurrency and
  communication
• Decompose the system into components, but how to
  compose the components?
• Static structure
• In term of actors and framework in actor-oriented
  design

10
Examples of Model of Computations

• Dataflow
• Connections represents data streams
• Actors compute their output data stream for input
  streams
• Useful for designing signal processing algorithms
  and sampled control laws
• Time Triggered
• Follow the principle of global progress of time
• Strong composability,diagnostically, and formal
  analysis
• Synchronous/reactive model
• Stimulated by events from the environment, but
  responds instantaneously
• Excellent for applications with concurrent and
  complex control logic
• Discrete Events
• Actors share a global notion of time and
  communication through events that placed on a
  continuous line
• Used in modeling hardware and software timing
  properties, communication networks, and queuing
  systems

11
Examples of Model of Computations(Con)

• Process Networks
• Asynchronous communication between processes
• Excellent for signal processing
• Difficult to interoperate with models including
  notion of time
• Rendezvous
• Synchronous communication between processes or
  threads
• Excellent for applications where resource sharing
  is a key element Poor in maintaining determinacy
• Difficult to interoperate with models including
  notion of time
• Publish and Subscribe
• Connections are event stream Components produce
  or consume events
• Good for distributed applications
• Continuous Time
• Connection carries a continuous-time signal
  Actors denote the relation among these signals
• Used in control system design for modeling
  physical dynamics and continuous control laws
• Finite State Machines
• Component is called state or node. The connection
  represent transitions of transfer of the control
  between states
• Sequential execution
• Excellent for describing control logic

12
Using Models of Computation

• Choosing models of computation
• Modeling of time
• Principle
• Ptolemy II
• Hierarchical heterogeneity

13
Case Study Ptolemy II

• Research project at Berkeley
• http//ptolemy.eecs.berkeley.edu
• Domain Polymorphism
• Domain
• Implementation abides by a common abstract syntax
  that underlies all Ptolemy models
• Component
• Implement an interface consisting of a suite of
  action methods
• Component is polymorphic
• Application
• Constructed by composing actors, connecting them,
  and assigning a domain.
• Formalize the approach
• Lee argues to use type theory to formalize the
  approach

14
Conclusion

• Significant difference from the prevailing
  abstractions in computation
• Time and other non-functional properties
• Hierarchically combining heterogeneous models of
  computation
• System-level type

15

• Thank you !