Hardware Interactions as Behavioural Types
A typical IoT sensor device is built from several independent components that cooperate together to sense and actuate on the physical world. Programming these devices can easily cause hardware failures that are not usually considered in general programming languages. For instance, programs can easily run out of memory causing the device simply to reboot; a mistake in a loop can render the device unusable, as it can drain its battery. As the program runs on the bare metal (there is no operating system nor device drivers), the program can improperly use the hardware, which, in most of the cases, leads to the action to be silently ignored. For example, by loosing a message that was sent when the device was not ready to send, or by manipulating a non-existent or misconfigured LED (Light-Emitting Diode).
We use behavioural types to describe the hardware as a set of well-defined components with valid interdependencies, in the spirit of the multiparty session types [1]. Our type describes each component per se in terms of its interface and its behaviour. The former defines the actions that the device makes available and the events the device triggers; the latter specifies the order in which actions and events can occur. As usual, in behavioural type works, our goal is to verify that the components are assembled correctly as a valid component (well typed), and that the programs use the device according to the prescribed type. Additionally, we want to express temporal-logic propositions on traces, so that we can prove, for instance, that a modem is always disconnected before the device enters the sleep state. To the best of our knowledge no IoT framework incorporates such analysis.
In this talk we present a simple hardware device and use our types to describe several increasingly complex behaviours of this device, thus assessing the informal expressiveness of our types. We discuss on how to verify that the behaviour of a component is a valid composition of simpler components. Finally, we hint on how to check that programs comply with a component type.
Hardware Interactions As Behavioural Types (beat2019-presentation.pdf) | 5.65MiB |
Sun 13 JanDisplayed time zone: Belfast change
16:00 - 18:25 | Session 4BEAT at Sala VII Chair(s): Adrian Francalanza University of Malta, Jorge A. Pérez University of Groningen, The Netherlands | ||
16:00 50mTalk | Invited Talk: Session Types for Fault-Tolerant Distributed Algorithms BEAT Kirstin Peters TU Berlin | ||
16:50 20mTalk | Behavioral Types as a Semantic Foundation for the GDPR Notion of Purpose BEAT Evangelia Vanezi University of Cyprus, Dimitrios Kouzapas University of Cyprus, Anna Philippou University of Cyprus | ||
17:10 20mTalk | Relating Process Languages for Security and Communication Correctness BEAT Daniele Nantes-Sobrinho University of Brasília, Brazil, Jorge A. Pérez University of Groningen, The Netherlands | ||
17:30 10mBreak | Short break BEAT | ||
17:40 20mTalk | Towards Legally Compliant Governmental Case Work with Dynamic Condition Response Graphs BEAT Søren Debois IT University of Copenhagen, Thomas H. Hildebrandt , Hugo A. López IT University of Copenhagen, Denmark & DCR Solutions A/S Media Attached | ||
18:00 20mTalk | Hardware Interactions as Behavioural Types BEAT Carlos Mão de Ferro LASIGE, Faculty of Sciences, University of Lisbon, Francisco Martins LaSIGE, University of Lisbon, Tiago Cogumbreiro University of Massachusetts Boston File Attached | ||
18:20 5mDay closing | Closing BEAT António Ravara Department of Informatics, Faculty of Sciences and Technology, NOVA University of Lisbon and NOVA LINCS, Jorge A. Pérez University of Groningen, The Netherlands |