Blogs (1) >>
POPL 2019
Sun 13 - Sat 19 January 2019 Cascais, Portugal
Sun 13 Jan 2019 18:00 - 18:20 at Sala VII - Session 4 Chair(s): Adrian Francalanza, Jorge A. Pérez

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 Jan

Displayed 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
Invited Talk: Session Types for Fault-Tolerant Distributed Algorithms
Kirstin Peters TU Berlin
Behavioral Types as a Semantic Foundation for the GDPR Notion of Purpose
Evangelia Vanezi University of Cyprus, Dimitrios Kouzapas University of Cyprus, Anna Philippou University of Cyprus
Relating Process Languages for Security and Communication Correctness
Daniele Nantes-Sobrinho University of Brasília, Brazil, Jorge A. Pérez University of Groningen, The Netherlands
Short break

Towards Legally Compliant Governmental Case Work with Dynamic Condition Response Graphs
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
Hardware Interactions as Behavioural Types
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
Day closing
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