Using a .net Checkability Profile to Limit Interactions between Embedded Controllers.

1
Using a .net Checkability Profile to Limit
Interactions between Embedded Controllers.
David Greaves, Atif Alvi Tope Omitola, Daniel
Gordon. University of Cambridge Computer
Laboratory
2
A Vision of Evolution for UbiComp

• A myriad of devices connected to the network.
• All devices are connected and share a common,
  all-pervasive, middleware.
• Devices contain controllable and controlling
  components.

3
Rules of the Domain

• No rule should issue a command under the same
  circumstances where another rule issues the
  counter-rule.
• Inlet and outlet valves must not both be open at
  once.
• Fire Alarm must mute all music sources.
• The front gates must always be remotely openable
  by some method or other.

4
Feature Interaction Detection

• Can we define a framework for code management in
  a UbiComp or Sensor/Actuator network that enables
  proof of safety and liveness ?
• We propose using a .net bytecode framework and
  evaluate its cost and flexibility.

5
Component Architecture

• We partition all devices and services in to
• Pebbles (sensors, actuators, software processes)?
• Applications (heating control, burglar alarm, CD
  player control...)?
• Further, we partition application code so it
  contains no device drivers, dynamic storage,
  dynamic binding and uses simple network I/O to
  all pebbles.

6
A Device A collection of Pebbles and a Canned App
Lets look at what a modern TV set contains

• 1. The following separate devices, each of which
  can be individually useful in a networked home

• IR Receiver
• Teletext Decoder
• MPEG Decoder
• Programming Memory
• Front Panel User Interface

• RF Tuner
• Colour Display
• Ni-Cam Audio Decoder
• Power Amplifier
• Surround Sound Decoder

• 2. A canned application that joins the
  components.

7
Automated Directory Systems Work

• Devices register in an ad hoc database
• eg. UPnPs SSDP, INS and O2S Oxygen system
• Devices can be found by service offered
• eg. A colour printer on floor 3 west.
• Retrieval by conjunction of predicates

(Few successful deployments. Unexpected
behaviours. Load balancing/path finding
unsupported.)?
8
Controllers Vs The Controlled

• API Reflection is now a Mature Technology
• It will be further deployed (?)?
• X-by-wire, Field Busses, Sensor Networks, CAN.
• EDDL, XDDL, Embedded Systems

• Code Reflection has seen virtually no work!
• i.e. how do devices describe their embedded
  behaviour
• and how is reactive behaviour between actuators
  and sensors captured ?

9
Code Reflection

• A device must expose the proactive behaviour of
  its canned application(s)?
• Actual source code (constrained language)?
• Proof carrying actual source code
• Summary of behaviour
• E.G. I will not send control messages when I am
  in standby mode.
• E.G. I am always off between 100 and 500.
• Device is banned from full operation within
  domain unless proof obligations are met.

10
An Example .net CD player.

• We built a CD/DVD player according to our
  component architecture.
• The application code was implemented in a pair of
  .net code bundles.
• The bytecode can be read out by a domain
  controller and checked, along with the other
  participating applications in the domain, against
  the rules of the domain.

11
(No Transcript)
12
Pebbles ProjectGeneral Flow
13
CD/DVD Player Components
14
CD/DVD Player Block Diagram
15
Software Costs

• Embedded devices have limited capabilities,
  especially RAM, but ROM is not so critical.
• XML parsing is expensive in RAM use.
• We have implemented .net interpreter, HTTP server
  and XML output all at 'reasonable' cost.

16
(No Transcript)
17
Heap and Stack Ram Use
18
Checkability Classes ?

• We have imposed a checkability profile on the
  .net bundles.
• Current profile is finite-state and strictly
  limited in IO libraries used.
• All participating applications in the domain must
  correspond to our profile.
• In the future, can define a richer class, based
  on linear integer programming, Presburg and so on.

19
Conclusions

• Running a 'complex' software stack is not a real
  obstacle, but don't parse too much XML.
• Using .net bytecode in embedded systems can be
  fast and compact enough, otherwise reflect your
  behaviour in .net while executing something else.
• We need to explore incremental model checking.
• We need to formally define our checkability
  class.

20
The End

• David.Greaves_at_cl.cam.ac.uk
• www.cl.cam.ac.uk/Research/SRG/HAN/Pebbles
• The Pebbles, AutoHAN and Oxygen O2S Teams