1 / 20

Using a Checkability Profile to Limit Interactions between Embedded Controllers.

Explore how checkability profiles can limit interactions among embedded controllers, ensuring safety and efficiency in networks. Learn about component architecture, feature interaction detection, and more.

rhondathornton
Télécharger la présentation

Using a Checkability Profile to Limit Interactions between Embedded Controllers.

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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 myriad of devices connected to the network. All devices are connected and share a common, all-pervasive, middleware. Devices contain controllable and controlling components. A Vision of Evolution for UbiComp

  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. UPnP’s 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 1:00 and 5:00. • 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. Pebbles ProjectGeneral Flow

  12. CD/DVD Player Components

  13. CD/DVD Player Block Diagram

  14. 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.

  15. Heap and Stack Ram Use

  16. 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.

  17. 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.

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

More Related