internet of&things& 2013/2014& - politecnico di...
TRANSCRIPT
Internet of Things 2013 / 2014
Classes Objec/ves Introducing MoteRunner
Providing basics to develop simple applications
Classes time is limited: Play with MoteRunner on your own!
Useful Links Class Website
http://antlab.elet.polimi.it/index.php?option=com_content&view=article&id=254&Itemid=259
ANTLab website: http://antlab.elet.polimi.it/
MoteRunner website: http://www.zurich.ibm.com/moterunner
White Paper: http://www.zurich.ibm.com/pdf/csc/Mote_Runner_WP.pdf
Agenda Introduction to MoteRunner System overview Applications
MoteRunner What is IBM MoteRunner?
An operating system for wireless sensor nodes and a run-‐time and development environment for wireless sensor networks (WSNs)
Current status: beta version 11
Available for Linux, Windows, Mac
Key Features Programming languages: C#, Java Hardware requirements: 8K RAM, 64K Flash Supported platforms: IRIS (Memsic), RZUSBSTICK (Atmel)
Mote simulation: debugging, testing, analysis of WSN including power consumption and sensor feeds
IDE: Eclipse
MoteRunner Layered Architecture:
Layered Architecture Thin HAL written in C and ASM (hardware-‐specific) Virtual Machine (written in C) Run-‐time library (written in C and C#) 802.15.4 MAC layer (written in C) Both run-‐time lib and MAC layer expose API for application development
Features Portability Scalability and Efficiency Higher level languages
MoteRunner ToolChain
MoteRunner ToolChain Higher level source code (Java, C#) is compiled Output files are read by the converter and traslated into assembler source code (Mote Runner intermediate langues – .sil)
Assembler processes .sil files and external libraries (.sxp) and produces either a debug (.sda) or binary (.sba) assembly.
A stub files is also created to permit others to build on previously created code
Assembly Life Cycle An assembly is the unit of management to be loaded / deleted onto/from the device
The part of MoteRunner that manages the assemblies and the resources needed to store them is called Mote Manager (MOMA)
Assemblies are stored in persistent memory (FLASH). An assembly remains in memory until it is explicitly deleted by instructing the MOMA.
MoteRunner Memory Model Part of the RAM used as transient heap (shared among all loaded assemblies)
Part of the FLASH used as “cabin space” (reserved to load assemblies)
Garbage Collector Compacting GC algorithm ensure that the heap is never fragmented
The GC is only executed when the VM is not active (no event to process)
The GC takes some time to finish and, thus, it could mean the next event cannot meet its deadline
GC is a convenient but costly feature. If possible programmers should try to avoid it!
General rule: use preallocated objects and reuse them
Java Programming MoteRunner applications can be programmed in either Java or C#.
However, you cannot copy program code literally! Mote has KBs of RAM while your PC has GBs of it.
Features not supported: Float and double data types 64-‐bit or longer integer arithmetic (int 16 bit, long 32 bit) Multi-‐dimensional arrays Threads and synchronization primitives Bool/boolean arrays Strings Enums
MoteRunner VS TinyOS Topic TinyOS Moterunner
Programming Language NesC Java, C#
Min # of files per application
3 (module, configuaration, makefile)
1 (assembly)
Compilation process Ad hoc (installation VS simulation)
One for all
Simulation interface Command line GUI
# of application in simulation
1 >1
Real-‐time mote management
No Yes
First Example: Lights A MoteRunner application consists of one or more classes that import the pkg com.ibm.saguaro.system
When an application is loaded, the static initializer (Java) is executed
First Example: Lights Create the light directory and Light.java file Turn on all LEDs of a mote.
package examples.light; import com.ibm.saguaro.system.*; public class Light { // the number of LEDs for the platform static int numLeds; // static initializer static { // get the number of LEDs numLeds = LED.getNumLEDs(); for(int i = 0; i < numLeds; i++){ LED.setState((byte)i, (byte)1); } } }
First Example: Lights The LEDs can be accessed using the class LED LED API: public class LED (member of com.ibm.saguaro.system)
Static Methods: public static byte getColor(byte no) public static uint getNumLEDs() public static uint getState(byte no) public static void setState(byte no, byte state)
Compila/on and Simula/on Compile the application with the command:
Start the MoteRunner shell:
http://localhost:5000 to visit the Mote Runner Dashboard (latest Firefox required)
In the MoteRunner shell type:
mrc -‐-‐assembly=light-‐1.0 Light.java
mrsh
>mote-‐create >moma-‐load light-‐1.0
MoteRunner Dashboard Web-‐based management interface for WSN running MoteRunner
Create motes and move them Monitor mote’s status, load/unload assemblies, observe traffic,
Useful for simulation / debugging
Dashboard will be available if MoteRunner Shell (mrsh) is active!
Using Timers / Callback Timers are very important in embedded system applications
A timer provides an API to specify a point in time when the mote should perform a "task“
Mote Runner takes care of the rest: put the mote into the best sleep mode (save energy) calculate the exact wake-‐up point
Using Timers / Callback Timers are very important in embedded system applications
A timer provides an API to specify a point in time when the mote should perform a "task“
Mote Runner takes care of the rest: put the mote into the best sleep mode (save energy) calculate the exact wake-‐up point
Using Timers / Callback public class Blink { // time interval in ticks for toggleing a LED static Timer timer; // blink object required for the delegate callback static Blink blink; static { // start with LED 0 ... // initialize object required for callback blink = new Blink(); // set the callback for the timer alarm timer.setCallback(new TimerEvent(null){ public void invoke(byte param, long time){
Blink.blink(param, time); } }); ... // set system callback ... // Check and toggle the state of the LED ... }
Using the radio API Mote Runner has a low level radio API available through the Radio class (extends CDev)
It can be used to implement custom MAC layers. Further details on 802.15.4 frame layout and addressing schemes please refer to: Lecture notes on 802.15.4 (lesson 3) Mote Runner docs (Programming the Radio)
802.15.4 Frame Layout
1 1 | 1 | 0/2 | 0/2/8 | 0/2 | 0/2/8 | 0/5/6/10/14 | ... | # of bytes per field +-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+ | FCF | FCA | SEQNO | DSTPAN | DSTADDR | SRCPAN | SRCADDR | aux.security | payload | field name +-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐+ |<-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐addressing fields-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐-‐>|
Addressing schemes Each mote carries three addresses:
A 16-‐bit PAN identifier: allows coexistence of different networks sharing the same channel
A 64 bit extended address: uniquely identifies the mote A 16 bit short address: application specific, used to optimize header space.
Address filtering Incoming radio frames are checked from the MoteRunner radio stack:
If the FCF indicates a beacon, accept frame if SRCPAN matches current set PANID or PANID = BROADCAST
If the FCA indicates the presence of destination addresses: current PANID must match DSTPAN or DSTPAN = BROADCAST
DSTADDR must match current mote’s address (short or extended) or DSTADDR = BROADCAST
Using the radio Radio system has four states:
SLEEP: no activity ACTIVE: turned on and synch to some frequency RECEIVE ENABLE (RXEN): listening for incoming frames TRANSMIT (TX): transmitting data
Using the radio Frequently used primitives:
startRx(uint mode, long at, long until) stopRx transmit(uint mode, byte[] pdu, uint beg, uint len, long time)
setRxHandler() open(), close(); setChannel(byte channel) setShortAddr(uint saddr)
Using the radio
DEMO
Logging Messages can be shown in the dashboard using the log functionalities: Import also com.ibm.saguaro.logger.*; To show a message:
byte[] message = csr.s2b(“Hello world!”); Logger.appendString(message); Logger.flush(Mote.INFO)
Load also logger-‐11.0 assembly!!!! Several “channels” are available: ERROR, INFO, WARN, DEBUG
Logging
DEMO
Reading sensors Motes are usually equipped with multiple sensors E.g. MEMSIC IRIS can be coupled with the MTS300 sensorboard
Can acquire temperature, humidity, light, sound, accelerometer data
+
Reading Sensor MoteRunner provides a sensor API called SimpleDevice
Member method:
Might throw exceptions!
int read(uint mode, unit len, long /me);
Simula/ng sensors When simulating sensor read operations one can:
output random data use Sonoran
Sonoran can be used to feed simulated data into motes through simple javascript files.
MoteRunner Excep/ons In case something goes wrong, MoteRunner enables to handle special conditions with the classic try – catch paradigm
E.g. when reading data from sensors an exception is thrown in two cases: IndexOutOfRangeException if the device index exceeds the maximum number of available sensor devices for a given sensor class
SystemException if the device is not implemented / supported / not available
MoteRunner Excep/ons AccessException: access was denied to a system resource or object. ArgumentException: an argument to a method was wrong. ArithmException: division by zero. ArrayTypeMismatchException: some array element does not match
the array type. IndexOutOfRangeException: access to an array element with an
index outside the array. InvalidCastException: a run-‐time cast failed. MoteException: root class for all exceptions. NullReferenceException: trying to access a null pointer OutOfResourcesException: out of memory or some other resource
is exhausted. SystemException: some system method/feature failed.
Addi/onal features (1) MoteRunner provides a LInk Protocol (LIP) to interact with mote attached to a PC.
Simple API to send / read data.
Wireless Management WLIP.
Sometimes might be useful to store data on the mote in contrast to send it immediately to a peer: MoteRunner provides API for storing persistent data
Addi/onal Features (2) MoteRunner enables to trace power consumption during simulation. This can be extremely useful to test / optimize protocols for WSN.
THAT’S ALL!