Sensors as Software TinyOS - polito.it · Sensors as Software TinyOS Dario Rossi...
Transcript of Sensors as Software TinyOS - polito.it · Sensors as Software TinyOS Dario Rossi...
1
TinyOSTinyOS
Sensors as SoftwareTinyOSTinyOS
Dario [email protected]
TinyOSTinyOS
Motivation
• Sensor networks– Radically new computing environments– Rapidly evolving hardware technology
• The key missing technology…– …is system software to manage them efficiently
• TinyOS original goals – Prototype current generation sensors constructed from
off the shelf components.– Identify key requirements that an operating system for
such a sensor must satisfy.– Build an operating system meeting the requirements– Evaluate the operating system’s performance while
running a real application.
2
TinyOSTinyOS
Operating System Requirements
1. Small physical size and low power consumption
2. Concurrency intensive operation
3. Limited hardware parallelism and controller hierarchy
4. Diversity in design and usage
5. Robust Operation
TinyOSTinyOS
Operating System Requirements
1. Small physical size and low power consumption– Constrained processing, storage,
interconnection– Efficiently manage memory and CPU– Allow low power communications
2. Concurrency intensive operation– Little storage capability– Simultaneous data flows (sensing-data
gathering, manipulation and transmission)– Need to be able to service packets on-the-fly
3
TinyOSTinyOS
Operating System Requirements
3. Limited hardware parallelism and controller hierarchy– Limited number, and capability of controllers– Unsophisticated processor-memory-switch level
interconnect
4. Diversity in design and usage– Sensor will tend to be application specific, not general
purpose (use only required hardware)– Wide range of application -> large number of device– Need for modular architecture: build an application out
of a spectrum of reusable components– Migrate components across the hardware/software
boundary as the technology evolves.
TinyOSTinyOS
Operating System Requirements
5. Robust Operation– OS should be robust
• Devices will be numerous and largely unattended• Application are expected to be operational 24/7• OS failures will require to reboot the mote
– OS should ease the development of reliable distributed applications• Individual sensor failure should be tolerated• Assist applications in surviving individual device
failures
4
TinyOSTinyOS
The Solution: TinyOS
• A micro-threaded OS… – that draws on previous work… – done for lightweight thread support… – and efficient network interfaces
• Small, tightly integrated design– Convenient hardware abstractions– Crossover of software/hardware components– Scaling forward to future technology
TinyOSTinyOS
The Solution: TinyOS• An open-source development environment
– Features a set of common services– Thightly tied to the nesC programming language– Features several programming tools
• java• Makefile system• TOSSIM simulator• nesC
• Main Ideology– Make best use of most constrained asset: battery
• Hurry up and sleep !!– High concurrency, interrupt driven
• Two-levels scheduler
5
TinyOSTinyOS
TinyOS: Models and Performance
• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model
• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance
TinyOSTinyOS
TinyOS: Models and Performance
• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model
• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance
6
TinyOSTinyOS
Data Model• Static memory allocation
– No heap (malloc), function pointers– Static frame, fixed sized– Memory requirements known at
compile time– Increase runtime efficiency
• Global variables- Available on a per-frame basis
• Local variables– Saved on the stack– Declared within a method
TinyOSTinyOS
Thread Model
• Power-Aware Two-levels Scheduling– Long running tasks and interrupt events– Sleep unless tasks in queue, wakeup on event
• Tasks– Time-flexible, background jobs– Atomic with respect to other tasks– Can be prempted by events
• Events– Time-critical, shorter duration– Last-in first-out semantic (no priority)– Can post tasks for deferred execution
7
TinyOSTinyOS
Programming Model• Separation construction/composition• Construction of Modules
– Modules implementation similar to C coding– Programs are built out of components– Each component specifies an interface– Interfaces are “hooks” for wiring components
• Composition of Configurations– Configuration similar to VHDL desing– Components are statically wired together– Increases programming efficiency (code reuse)– Increases runtime efficiency (static defs.)
TinyOSTinyOS
Components Model: Terminology• Components
– Use and provide bidirectional interfaces– Call and implement commands– Signal and handle events
• Components – Must handle events of the used
interfaces (and can call commands) – Provide interfaces that must implement
commands (and can signal events)• Components
– Handle the events they are signaled– Implement the commands they provide
8
TinyOSTinyOS
Component Model: Scheme
• Component Interface– Command and Event– Frame (storage)– Tasks (computation)
• Component declares– The commands it uses – The events it signals
• Components– Handle the events they are signaled– Implement the commands they provide
Component FrameTask
Commands Events
Provides
Uses
Signals
Handles
TinyOSTinyOS
Component Model: Hierarchy• Commands
– Flow downward– Non blocking requests– Control returns to caller
• Events– Flow upwards– Post task, signal higher level
events, call lower level cmds– Control returns to signaler
• To avoid cycles– Events can call commands– Commands can NOT signal events
RFM (bit level)
Radio Byte
Radio Pkt
Commands Events
9
TinyOSTinyOS
Component Model: Hierarchy• Commands
– Flow downward– Non blocking requests– Control returns to caller
• Events– Flow upwards– Post task, signal higher level
events, call lower level cmds– Control returns to signaler
• To avoid cycles– Events can call commands– Commands can NOT signal events
RFM (bit level)
Radio Byte
Radio Pkt
Commands Events
Hardware Interrupt
TinyOSTinyOS
Component Model: Types• High level software
– Control, routing, data manipulation/aggregation.
• Synthetic hardware– Simulates advanced hardware– Could be cast in hardware– Need for flexible boundary
• Hardware abstraction– Map physical hardware into
TinyOS component model– Frame contains hardware state
RFM (bit level)
Radio Byte
Radio Pkt
Commands Events
10
TinyOSTinyOS
Component Model: Commands
• Goals and Means– Inter-component communication – Perform non-blocking requests to lower-level
components• Rules
– Can NOT signal events (to avoid cycles)– Can invoke lower level commands– Deposit request parameters into a frame…– … then post a task for later execution– Return status to the caller
TinyOSTinyOS
Component Model: Events
• Goals and Means– Directly deal with hardware interrupts– Propagate event-chain to upper components
• Rules– Can signal higher level events– Can invoke lower level commands– Deposit information into a frame… – …then post a task for later execution– Control returns to signaler– Can preempt events and tasks
11
TinyOSTinyOS
Component Model: Tasks
• Goals and Means– Intra-component primary computation work– Single OS stack assigned to the current task– Asynchronous with respect to events
• Rules– Can signal higher level events– Can invoke lower level commands– Can schedule other tasks within a component– Atomic with respect to other tasks– Can be pre-empted by events
TinyOSTinyOS
Component Model: TinyOS Code
Messaging Component
AM_S
UB_I
NIT
AM_S
UB_P
OWER
AM_S
UB_T
X_PA
CKET
AM_T
X_PA
CKET
_DON
E
AM_R
X_PA
CKET
_DON
E
Internal State
AM_I
NIT
AM_P
OWER
AM_S
END_
MSG
AM_M
SG_R
EC
AM_M
SG_S
END_
DONE
Internal Tasks
Commands Events
//AM.comp//TOS_MODULE AM;ACCEPTS{
char AM_SEND_MSG(char addr, char type,
char* data);void AM_POWER(char mode);char AM_INIT();
};SIGNALS{
char AM_MSG_REC(char type, char* data);
char AM_MSG_SEND_DONE(char success);};HANDLES{
char AM_TX_PACKET_DONE(char success);char AM_RX_PACKET_DONE(char* packet);
};USES{
char AM_SUB_TX_PACKET(char* data);void AM_SUB_POWER(char mode);char AM_SUB_INIT();
};Slide courtesy Jason Hill et al
12
TinyOSTinyOS
Network Model: General Idea
• Active Messages (AM)– Every AM triggers a specific event handler – Application-specific receiver-side action
TinyOSTinyOS
Network Model: Active Message
• Message is “active” because it contains – Destination Address
• 0xFFFF: broadcast• 0x007E: UART
– Message Type– Group ID
• Message format – 5 bytes header– 29-36 bytes payload– 2 bytes CRC
13
TinyOSTinyOS
Network Model: Message Exchange
TinyOSTinyOS
Putting It All Together
• Within a sensor– Scheduler is a power-aware FIFO queue– Peripherals can wake up the processor– Communication across components takes
the form of a function call. • Within the network
– Communication between components takes the form of Active Messages (AM)
– AM can wakeup/instruct/query sensors
14
TinyOSTinyOS
TinyOS: Models and Performance
• TinyOS Models– Data Model– Thread Model– Programming Model– Component Model– Network Model
• TinyOS Performance– Simple multi-hop monitoring application– Check if requirements are met– Validate system peformance
TinyOSTinyOS
TinyOS: Models and Performance
TinyOS Performance• Simple multi-hop monitoring application• Check if original requirements are met
1. Small physical size and low power consumption
2. Concurrency intensive operation3. Limited hardware parallelism and controller
hierarchy4. Diversity in design and usage5. Robust Operation
15
TinyOSTinyOS
Test App: Goal
• Monitor temperature and light conditions• Periodically transmit measurements to a
base station•Sensors can act as relay(forward data for behalf of other sensors)
•Dynamically determine the correct routing topology
Image courtesy Jason Hill et al
TinyOSTinyOS
Test App: Ad hoc Routing
0Base
1
1
2
2
3
• Base sensor– periodically broadcasts route updates
• Any sensor in range of this broadcast– record the identity of the base station– re-broadcast the update
• Each sensor– remembers the first update received in an era– uses the source of the update as destination
Image courtesy Jason Hill et al
16
TinyOSTinyOS
Test App: Graph Component
Slide courtesy Jason Hill et al
RFM
Radio Byte
Radio Pkt
UART
Serial Pkt
I2C
Temp Photo
Active Messages
ClockBit
Byte
Packet
Ad hoc Routing Application
Application
HW
SW
ADC
TinyOSTinyOS
Evaluation: Small Physical Size
0
500
1000
1500
2000
2500
3000
3500
4000
Multihop RouterAM light
AM TempAMPacket
Radio ByteRFM
Photo
TempUART Packet
UART
i2cInit
TinyOS SchedulerC Runtime
• OS Scheduler• Code: 178 Bytes• Data: 16 Bytes
• Complete application• Code: 3 KBytes• Data: 226 Bytes • less than 50% of
the 512 Bytes totally available
• Only 3 components are required
17
TinyOSTinyOS
Evaluation: Small Physical Size
2263450Total
30160
17217882
Processor_initTinyOS schedulerC runtime
00
328
404081111
408
884078
1463563348103108464
196314198
Multihop routerAM_dispatchAM_temperatureAM_lightAMPacketRADIO_byteRFMPhotoTemperatureUARTUART_packetI2C_bus
Data Size (bytes)
Code Size (bytes)
Component Name
• OS Scheduler• Code: 178 Bytes• Data: 16 Bytes
• Complete application• Code: 3 KBytes• Data: 226 Bytes • less than 50% of
the 512 Bytes totally available
• Only 3 components are required
TinyOSTinyOS
Evaluation: Concurrency Intensive
12.259Interrupt (hardware cost)
17.75
2.52.5
11.512.75
2
Time (µs)
971Interrupt (software cost)
1.251.25
66
10104651
Post an EventCall a CommandPost a task to schedulerContext switch overhead
18Byte copy
Normalized to byte copy
Cost (cycles)
Operations• Low overhead: essential for modular efficiency
• Posting event: as copying 1 byte of data
• Cost of posting a task or context switchingis the same as copying 6 bytes of data
• Direct hardware-interrupt handling requires saving and storing registers
18
TinyOSTinyOS
Evaluation: Efficient Modularity• Packet transmission event (focus on last bit) • 5-layers propagation delay: 80 cycles, 40+55µs• 0: interrupt, 1-4: events, 5: command, 6: task
Timing diagram of event propagationSlide courtesy Jason Hill et al
TinyOSTinyOSEvaluation: Limited Hardware
Parallelism and Controller Hierarchy
• Multiple flows of data running through a single microcontroller
• Mostly idle even during RX/TX
ComponentsPacket reception work breakdown CPU Utilization Energy (nj/Bit)
AM 0.05% 0.02% 0.33Packet 1.12% 0.51% 7.58Radio handler 26.87% 12.16% 182.38Radio decode thread 5.48% 2.48% 37.2RFM 66.48% 30.08% 451.17Radio Reception - - 1350Idle - 54.75% -Total 100.00% 100.00% 2028.66
Slide courtesy Jason Hill et al
19
TinyOSTinyOSEvaluation: Diversity in Design and
Usage, Robust Operation
• Diversity in Usage– Created several sample applications that exploit
the modular structure of the system– Source based multi-hop routing applications– Active-badge-like location detection applications– Sensor network monitoring applications
• Diversity in Design– Portability: target multiple CPU architectures– Modularity: accommodate future systems
• Robustness– Compile-time check reduces human error (nesC)– Part of the burden is left to the application
Slide courtesy Jason Hill et al
TinyOSTinyOS
Architectural Implications
• Feedback from TinyOS– Separate microcontroller for each I/O device
• is an option, not a requirement
– Bit-level processing cannot sustain high rates• RadioByte need real non-synthetic hardware • Byte level hardware would save 690 nJ/bit
– Inclusion of hardware support for events• Need for additional set of register • Would save 20µs per event and up to 20% CPU
20
TinyOSTinyOS
Related Works• Real-Time Embedded OSs
– From hand-held to high-end PCs– WinCE, PalmOS, QNX, WxWorks, ... – Cool in principle, far from sensor constraint
• QNX: context switch 2400 cycles @ 33Mhz• VxWorks: 100-1000 Kbytes memory footprint
• Real-Time Executives OSs– Small OS for moto-controller, microwave ovens– Cream, pOSEK, Ariel, ...– Meet only constraint requirement
• Control-centric rather than dataflow centric
TinyOSTinyOS
Conclusions
• TinyOS – highly modular software environment – tailored to the requirements of Sensors Network– power-efficient and concurrency-intensive– able to support new devices as they evolve.
• Running an application on TinyOS– can help reveal the impact of architectural changes – feedback to design hardware that is optimized for a
particular application• Writing an application on TinyOS ?
– Let’s move to nesC