Networked Embedded Software: Programming. Luca Mottola Politecnico di Milano, Italy and SICS Swedish ICT (home.dei.polimi.

Transcription

1 Networked Embedded Software: Programming Luca Mottola Politecnico di Milano, Italy and SICS Swedish ICT (home.dei.polimi.it/mottola)

2 Programming NES According to market research firms, the global market for NES will grow tenfold by 2020, however ease of programming is the current hampering factor and major technology enabler Programming mostly done ad-hoc at the OS level the largest coding effort devoted to communication distracts programmers from the application goal greatly hampers reuse: porting an application often requires substantial (if not complete) rewriting Fundamental problem: level of abstraction is too low

3 Level of abstraction? Cross-layer embedded software Mask complexity without sacrificing performance

4 Need for Cross-layer No radio duty-cycle Expected lifetime: ~8 days Naïve radio duty-cycle Expected lifetime: ~9 months

5 Operating Systems NES OSs often different from mainstream ones Basic run-time support for application programs No support for user interaction Programs cross-compiled and linked with the OS library Resulting binary deployed onto the node

6 nesc / TinyOS nesc provides the programming abstractions Component based programming TinyOS (TOS) manages scheduling and interactions with the hardware Split-phase execution Commands are executed, return value is asynchronously reported through an event

7 Uses Send nesc Components Components encapsulate state and processing Use or provide interfaces Interfaces list commands and events Configurations wire components together Calls sendmsg(msg) Provides Send Signals senddone() Function calls Using Providing Commands Call Command Implement Command Body Events Implement Event Handler Signal Event

8 nesc Example Provided by sensorspecific components module BlinkC { // uses interface Read<uint16_t> as ReadHumidity; implementation { // event void SenseTimer.fired() { call ReadHumidity.read(); event void ReadHumidity.readDone(error_t result, uint16_t val) { float humidity = *val+((-2.8)* )*(val*val) 4; if (humidity > 50) { // 0 On, 1 Off else { // 0 Off, 1 On interface Read<val_t>{ command error_t read(); event void readdone(error_t result, val_t val); val is the raw ADC value, it needs to be converted! Calls read() Signaled when the sensor gathered the reading Signals readdone()

9 Toolchain Complete inlining, detection of races Crosscompiled No linking

10 Middleware to the Rescue Tuple spaces proposed in the 80s (Linda) for parallel computation In TeenyLIME, each node hosts a tuple space shared with the nodes within range tuple space out(t) in(p) rd(p) < Italy, Milano > < Belgium, Leuven> < Italy, Trento>

11 Why Abstractions are Useful Maintains an array of current interests bool pendingmsg; TOS_Msg sendmsg; event TOS_MsgPtr ReceiveInterestMsg.receive(TOS_MsgPtr m) { struct InterestMsg* payload = (struct InterestMsg*) m->data; if (isrecipient(payload, TOS_LOCAL_ADDRESS)) insertinterest(payload->sender, payload->type, payload->threshold, payload->timestamp); return m; event result_t TemperatureSensor.dataReady(uint16_t reading){ Sends a message if at if (!pendingmsg && matchesinterest(reading)) { atomic { least one interest pendingmsg = TRUE; matches struct DataMsg* payload = (struct DataMsg*) sendmsg->data; msg->sender = TOS_LOCAL_ADDRESS; msg->type = TEMPERATURE_READING; Just msg->value outputs = a reading; tuple, all registered if reactions (call SendDataMsg.send(TOS_BCAST_ADDR,sizeof(struct will be triggered AppMsg),&sendMsg)!= SUCCESS) pendingmsg = FALSE; Data filtering and addressing return SUCCESS; event result_t TemperatureSensor.dataReady(uint16_t performed in the application reading){ code event result_t SendDataMsg.sendDone(TOS_MsgPtr tuple<uint16_t, msg, uint16_t> result_t temperaturevalue success) { = newtuple( if (msg == sendmsg) actualfield(temperature_reading), pendingmsg = FALSE; actualfield(reading)); return SUCCESS; call TupleSpace.out(FALSE,TL_LOCAL,&temperatureValue); return SUCCESS; Programming Wireless Sensor Networks 2008 Luca Mottola and Gian Pietro Picco

12 Problem WSNs inherently environment dependent The software must adapt Missing design and programming support

13 Example: Wildlife Tracking

14 module ReportLogs{ uses interface Collection; uses interface DataStore; implementation { int base_station_reachable = 0; event msg_t Beacon.receive(msg_t msg) { if (!acceleromenter_detects_activity()) return; if (call Battery.energy() <= THRESHOLD) return; base_station_reachable = 1; call GPS.stop() call BaseStationReset.stop(); call BaseStationReset.startOneShot(TIMEOUT); event void BaseStationReset.fired() { base_station_reachable = 0; event void ReportPeriod.fired() { switch (base_station_reachable){ case 0: call DataStore.deposit(msg); case 1: call Collection.send(msg);

15 Vol. 7, No. 3, March Aprile 2008 Context-oriented Programming Layered functions change the behavior depending on the context Lisp Java Context-oriented Programming Erlang Robert Hirschfeld, Hasso-Plattner-Institut, Universität Potsdam, Germany Pascal Costanza, Programming Technology Lab, Vrije Universiteit Brussel, Belgium Oscar Nierstrasz, Software Composition Group, Universität Bern, Switzerland Context-dependent behavior is becoming increasingly important for a wide range of application domains, from pervasive computing to common business applications. Unfortunately, mainstream programming languages do not provide mechanisms that enable software entities to adapt their behavior dynamically to the current execution Objective-C context. This leads developers to adopt convoluted designs to achieve the necessary runtime flexibility. We propose a new programming technique called Context-oriented Programming (COP) which addresses this problem. COP treats context explicitly, and provides mechanisms to dynamically adapt behavior in reaction to changes in context, even after system deployment at runtime. In this paper, we lay the foundations of COP, show how dynamic layer activation enables multi-dimensional dispatch, illustrate the application of COP by examples in several language extensions, and demonstrate that COP is largely independent of other commitments to programming style. 1 INTRODUCTION Contextual information is playing an increasingly important role for applications and services ranging from those that are location-based to those that are situationdependent or even deeply personalized. While context-awareness is already an integral part of regular business applications, it is becoming even more critical for mobile and ubiquitous computing, where devices must adapt their behavior to the services available in their current environment. Despite the fact that context is clearly a central notion to an emerging class of applications, there is little explicit support for context awareness in mainstream programming languages and runtime environments. This makes the development of these applications more complex than necessary. In this paper we argue the need for a new programming approach, called Context-oriented Programming (COP), which treats context explicitly and makes it accessible and manipulable by software. One di culty in proposing a concrete COP language is that context covers a wide range of concepts ranging from domain-specific to technology-dependent attributes, and including properties that may be spatial or temporal, or even based in hardware or software. We see personalization, sharing, location-awareness, ubiq- Python Cite this document as follows: Robert Hirschfeld, Pascal Costanza, and Oscar Nierstrasz: Context-oriented Programming, in Journal of Object Technology, vol. 7, no. 3, March Aprile 2008, pages , /article4

16 CoNesC: Example Base-station group call BaseStationG.report(msg); BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout

17 CoNesC: Example Base-station group BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout call BaseStationG.report(msg); activate BaseStationG.Reachable; //... activate BaseStationG.Unreachable;

18 CoNesC: Example Base-station group BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout call BaseStationG.report(msg); activate BaseStationG.Reachable; //... activate BaseStationG.Unreachable; context Reachable { uses interface Collection; implementation { //... layered command void report(msg_t msg){ call Collection.send(msg); context Unreachable { uses interface DataStore; implementation { //... layered command void report(msg_t msg){ call DataStore.deposit(msg);

19 CoNesC: Example Base-station group BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout call BaseStationG.report(msg); activate BaseStationG.Reachable; //... activate BaseStationG.Unreachable; context Reachable { uses interface Collection; implementation { //... layered command void report(msg_t msg){ call Collection.send(msg); context Unreachable { uses interface DataStore; implementation { //... layered command void report(msg_t msg){ call DataStore.deposit(msg);

20 CoNesC: Example Base-station group BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout call BaseStationG.report(msg); activate BaseStationG.Reachable; //... activate BaseStationG.Unreachable; context Reachable { uses interface Collection; implementation { //... layered command void report(msg_t msg){ call Collection.send(msg); context Unreachable { uses interface DataStore; implementation { //... layered command void report(msg_t msg){ call DataStore.deposit(msg);

21 CoNesC: Example Base-station group BS beacon received Reachable Unreachable on active: on active: send readings to the BS log locally timeout call BaseStationG.report(msg); activate BaseStationG.Reachable; //... activate BaseStationG.Unreachable; context Reachable { uses interface Collection; implementation { //... layered command void report(msg_t msg){ call Collection.send(msg); context Unreachable { uses interface DataStore; implementation { //... layered command void report(msg_t msg){ call DataStore.deposit(msg); context group BaseStationG { layered command void report(msg_t msg); implementation { contexts Reachable, Unreachable is default, MyErrorC is error; components Routing, Logging; Reachable.Collection -> Routing; Unreachable.DataStore -> Logging;

22 Macro-programming

23 Example: ATaG Tasks represent data processing Deployment controlled via annotations Written with imperative language Abstract channels represent information exchanges

24 Is One Abstraction Enough? makesense: an extensible language Abstractions can be plugged in Users can contribute new abstractions Java-like syntax Limited support to real OO No garbage collection

25 makesense Meta-model Meta-Abstraction <<use>> Action Modifier 1 Target Target Distributed Action <<use>> Local Action <<use>> Tell Action Report Action <<use>> 0..1 Data Operator Collective Action f(x1.. xn) Tell Collective Report Data Operator

26 What if sensors can move?

27 Challenges Physical movements become part of the application logic Spatial constraints Temporal constraints

28 State of the Art: Multiple Drones Potential for reducing execution time (and costs) with multiple drones difficult to specify coordinated behaviors! Drone-level programming Swarm programming

29 Drone-level: irobot Create API

30 Swarms: ROS Robot Operating System (ROS) An attempt at abstracting low-level/distributed interactions in robotics software A meta OS Sit on top of Linux Bindings to C/C++/Python/Java Agent-based Publish/Subscribe for coordination

31 Team-level Programming Users reason based on global state and define sensing tasks to execute spatio/temporal constraints The run-time transparently decides how to allocate resources

32 Team-level Programming Example Drones abstract machine spatial Image tiles; Spatial do { variable tilesok = true; tiles@grid = Drones.do( pic",drones.cam,handlecam); foreachlocation (Location loc in tiles){ aberr=abberationestimate(tiles@loc); Active sensing loop if (aberr > MAX_ABR &&!scenechanged) { Drones.stop(handleCam); newstep=tune(drones.get("gridstep"),aberr); Drones.set("gridStep",newStep); tilesok=false; break; while (!tilesok); Triggering adaptation

33 Open Problems What s the right abstraction level? Integration within and outside of the company s backend? What about the Internet of Things?