A User-Centric Approach to Wireless Sensor Network Programming Languages (position paper)

Transcription

1 A User-Centric Approach to Wireless Sensor Network Programming Languages (position paper) Atis Elsts Leo Selavo Institute of Electronics and Computer Science ( SESENA12, June 2, Zurich, Switzerland

2 Approach Facts: 1. WSN was envisioned as a tool for domain experts 2. At the moment, programming WSN for them is hard to impossible 3. Still, a significant class of WSN applications is conceptually simple: Sense-and-send; Event-detection, etc. Our idea: Create a language targeted towards novice programmers & nonprogrammers Our contributions: Identify a new, emerging class of WSN developers and cater for their needs Separate WSN programming in system and user layers at the language level Provide integrated IDE for visual programming At the moment, focus is on making node-local application logic easier 2

3 Environmental monitoring use case Environmental monitoring in precision agriculture Distributed microclimate measurements in an orchard: temperature, humidity, light The users are agroscientists in Latvia State Institute of Fruit-Growing ( Test network architecture 3

4 Mobile agent use case Sensing devices mounted to cars Communicate with other cars and road-side units Application 1: detect potholes on road surface Application 2: detect potentially dangerous weather conditions e.g. when road surface icing is a hazard The users are hardware developers and (potentially) car owners Pothole detection via acceleromenter measurements Sensor device prototype 4

5 SEAL overview SEAL Sensor Application Development Language Declarative with some imperative elements Compact and natural-language-like syntax User types code IDE generates code SEAL source file SEAL compiler C source file C compiler Executable SEAL application development process SEAL conceptual architecture 5

6 SEAL application examples Blink red LED: use RedLed, period 1s; Read light and humidity sensors & send to serial port: read Light, period 2s; read Humidity, period 2s; output Serial, baudrate 38400, aggregate; Conditions (blink blue led; faster at start): when SystemUptime.value < 2s: use BlueLed, period 100ms; elsewhen SystemUptime.value < 6s: use BlueLed, period 500ms; else: use BlueLed, period 2000ms; end 6

7 SEAL design decisions Declarative vs imperative language? Declarative: SEAL, Snlog, Logical Neighborhoods (LN), Regiment Imperative: nesc, Pleiades, Kairos Macroprogramming, group-oriented, or node-local language? Macroprogamming: TinyDB, Kairos Group: Abstract Regions, LN Node-local: SEAL, nesc Integrated solution or a building block approach? Integrated: TinyDB Building block: SEAL Free vs restrictive to the user? Free: C programming, nesc programming Restrictive: SEAL, TinyDB 7

8 Scheduling sensor readings I Different sensors require different approaches: SHTxx temperature sensor: reading is energy-wise expensive: up to 1 ma current consumption during up to 320 ms faster than 1 Hz reading leads to self-heating accelerometer sensor: reading is cheap (e.g. just sample internal ADC) 100 Hz frequency is common Problems: the application developer has to remember minimal sensor read periods what about usage in conditions? (e.g. when temperature > threshold: do something ) SEAL solution: use cache for sensor readings specify maximal reading frequency in description of each component 8

9 Scheduling sensor readings II Facts: the measurement on e.g. SHTxx or gas sensor takes up to hundreds of ms on the same sensors, reading the measurement result is fast! Classical approach (optimized!): shtxx_start_measurement(); msleep(sht_measurement_time); // enter low power mode temperature = shtxx_read_measurement(); gas_sensor_start_measurement(); msleep(gas_measurement_time); co_level = gas_sensor_read_measurement(); // etc. Problem with this approach: if the agent is mobile, reading each sensor happens at a different location SEAL solution: automatically synchronize reading multiple sensors 9

10 Results SEAL compiler partially implemented: sensing & sending OK, data processing under development Evaluated on target audiences: students and agriculture scientists with no WSN experience Figure 1. Student test results of SEAL and competing solutions Figure 2. Student evaluation of SEAL and competing solutions 10

11 Future work Add missing features (e.g. distributed processing) Show the scope of SEAL: Analyze existing WSN deployments and their requirements for programming languages Show the efficiency of SEAL: Simulate & test energy consumption of code generated by SEAL compiler Continue to evaluate the usability of SEAL: Test using focus groups Personal interviews with potential users 11

12 Conclusions A new WSN programming language SEAL proposed Aimed directly at the domain experts Motivated by real-world applications Optimizes intra-node scheduling and processing The compiler is partially implemented: Open source, available at Preliminary user evaluation results were presented as a poster at EWSN 2012 A. Elsts, J. Judvaitis, L. Selavo, Poster Abstract: SEAL: An Easy-to-use Sensor Node Application Development System, EWSN 2012 Poster and Demo Proceedings 12

13 A User-Centric Approach to Wireless Sensor Network Programming Languages (position paper) Thank you! Questions? This work was supported by European Social Fund, grant Nr. 2009/0219/1DP/ /APIA/VIAA/020.