Presentation on theme: "TinyOS Real-time and Embedded System Laboratory Operating System for Networked Sensors."— Presentation transcript:
TinyOS Real-time and Embedded System Laboratory Operating System for Networked Sensors
Outline O verview M ain Properties H ardware Platforms D esign I mplementation W ireless Network Communication: Active Messages I mportant Subsystems & Tools TinyDB TASK TOSSIM Bombilla TinySec C onclusions
Overview Component-based OS for sensor Networks modularity Developed at UC Berkeley for their original sensors called Motes Its open-source approach and has achieved a big community and tenths of side projects. Also its open and promising design have helped Developed in their own language NesC Optimised in terms of memory usage and energy efficiency, while supporting concurrency-intensive operations
Main Properties Event Model Perfect solution for high concurrency and small amount of memory space Use CPU resources more efficiently Division among events (short and with preemption capabilities) and tasks (longer and deferred, but can't preempt) Two level scheduling Designed to scale with technology trends due to its support for crossover of software components into hardware.
Hardware Platforms Hardware differences between mote platforms affect software structure, networking capabilities and performance
Hardware Platforms Next Generation Sensor Networks? - All in one chip - Smart Dust
Design Architecture of TinyOS consist of interacting components and a task scheduler 3 entities exist that allow components to execute code and communicate among them: Commands and Command Handlers Events and Event Handlers Tasks Also a fixed-size and statically allocated frame exist per each component, representing its internal state and being operated by the 3 previous entities. Components declare commands used and events signalled, creating a layers of components, where upper layers issue commands to lower layers and handle events coming from them.
Design In TinyOS is talked then about bidirectional interface, referring communication between components through events and commands.
Design Perform the primary computation work Atomic with respect to other tasks, and run to completion, but can be preempted by events Allow the OS to allocate a single stack assigned to the currently executing task Call lower level commands Signal higher level events Schedule other tasks within a component Simulate concurrency using events Are queued in FIFO task scheduler TASKS
Design COMMANDS Non-blocking requests to lower level components Deposit request parameters into a components frame, and post a task for later execution Can also invoke lower level commands, but cannot block Return status to the caller
Design EVENTS Event handlers deal with hardware events (interrupts) directly or by lower layer components Deposit information into a frame and post tasks to the scheduler (similar to commands) Signal higher level events Call lower level commands
Design Three type of components Hardware abstraction components Synthetic hardware components High-level software components Interesting similarities of components with hardware modules in hardware description languages (i.e. VHDL) benefits for future hardware designs
Implementation CNesC Proprietary language based on C language called NesC A language for programming structured component-based applications, primarily intended for embedded systems such as sensor networks Two types of components in NesC: Modules: Application code, implementing one or more interfaces Configurations: Wires components and, on a top level, assembles applications to produce and executable TinyOS provide a wide variety of system components and some pre-built applications. Application development can start immediately.
Implementation EXAMPLE: Blink Application Simple application that causes the red LED on the mote to turn on and off at 1Hz Two components. A module called BlinkM.nc and a configuration called Blink.nc Access to system components (ClockC and LedsC) which access the hardware Main is the first component executed in any TinyOS application and must be indicated in its configuration file
Active Messages Wireless Network Communication Active Messages Motivation: Existing solutions not applicable (bandwidth intensive, too complex packets, computational and energy demanding, stop & wait…) Active Messages: Simple, extensible paradigm Widely used in parallel and distributed systems Distributed event model matching TinyOS design Tiny Active Messages:
Active Messages Wireless Network Communication Active Messages Messages contain the handler ID (globally unique byte) to be executed at destination. Special handlers: Handler 0: Routing handler. Handler 255: List installed handlers Mote handlers are invoked through events Base Station mote (node connected to PC host) has the special destination address 0x7e (126)
Active Messages Wireless Network Communication Active Messages Data payload (up to 28 bytes) is passed to the handler as an argument Event-based architecture enables network communication to overlap with sensor interaction Three basic primitives are supported: Best effort message transmission Addressing (address checking) Dispatch (Handler invocation) Sufficient for operation. Applications can build other functionality on top (encryption, flow control, fragmentation, error correction/detection… )
Active Messages Wireless Network Communication Active Messages INTERESTING USABILITY Routing: Handler 0 forwards to next hop Each hop decreases N and forwards the packet Last hop (N=1) inserts destination handler (HF) into H0 Hops addresses are stored (up to 4) Broadcasting Address 255 allows message broadcasting 2-hope messages will discover all closest neighbors Returned packets hold those neighbors addresses Permits a method of route discovery
Active Messages Wireless Network Communication Active Messages INTERESTING USABILITY Radio Reprogramming: Mica2 and Mica2dot platforms can be reprogrammed (change the running application) by radio connection using AM A Java application on the base station is used to send the program to one or several motes A special & reserved handler is used in the motes to receive AMs for reprogramming A special module has to be wired with applications. Program is stored in external flash and motess IDs are in eeprom. An special boot loader, stored previously in processors program memory, executes to load and reboot the mote so new application will be run.
Active Messages Wireless Network Communication Active Messages SOME FIGURES Power Consumption Throughput: ~800 bytes/sec (~6.5 Kbps) with 4b6 encoding
TinyOS SOME OTHER FIGURES Small Size: Scheduler just 178 bytes Complete applications need only around 4 Kb + application code Concurrency: Low Overhead :Cost of posting and event = cost of copying 1 byte of data Even during periods of active communication with bite level processing, CPU is sleeping 50+% of the time Component NameCode Size (bytes)Data Size (bytes) Multihop router AM_dispatch AM_temperature AM_light AM Packet RADIO_byte RFM Photo Temperature UART UART_packet I2C_bus Processor_init TinyOS scheduler C runtime Total ComponentsCPU UtilizationEnergy (nj/Bit) AM0.20%0.33 Packet0.51%7.58 Radio handler12.16% Radio decode thread2.48%37.2 RFM30.08% Radio Reception-1350 Idle54.75%- Total100.00%
Important Subsystems & Tools TinyDB: The TinyDB "sensor network as database" application Bombilla (Maté): TinyOS virtual machine MatchBox: Simple mote filing system TASK: The TASK "Tiny Application Sensor Kit" application TOSSIM: The TinyOS (PC) Simulation Environment MIG: Message Interface Generator Message Center: Easy injection of arbitrary messages into a mote network TinySec: Secure communication on motes.
TinyDB Important Subsystems & Tools TinyDB Query process system SQL-like for extracting information from a network of TinyOS sensors TinyDB provides an interface in the base station for query input The query is spread and collected back to the base station A set of attributes can be selected for the query TinyDB component must be installed in each node to collect those attributes An API is provided to embed TinyDB on users own applications
TinyDB Important Subsystems & Tools TinyDB Example: Sensor equipped university building Which classes are in use? light sensor reading from sensors room is above threshold l and volume sensor above v Writing an application in nesC to read network light sensors and route results to base station would be difficult With TinyDB, we run its component on each sensor and equip them with a room number (i.e. node ID): SELECT nodeID, AVERAGE(light), AVERAGE(volume) FROM sensors GROUP BY nodeID HAVING AVERAGE(light) > l AND AVERAGE(volume) > v EPOCH DURATION 5min
TinyDB Important Subsystems & Tools TinyDB Components Overview Sensor Network Software Sensor Catalog and Schema Manager Query Processor Memory Manager Network Topology Java-based Client Interface Network Interface Classes to build and transmit queries A class to receive and parse query results A GUI for result display, query construct and visualize dynamic network topologies …
TinyDB Important Subsystems & Tools TinyDB Query Window Command Window Status Window
TinyDB Important Subsystems & Tools TinyDB Features: Multiple Queries: Allowance of multiple queries over the same motes at the same time Triggers: Local command execution on some result (i.e. alarm sound on temperature over t) Even-Based Queries: Queries starting on when a low-level event occurs. Queries over Flash: Creating, inserting, retrieving and deleting tables in Flash memory Power Management and Synchronization: Each sensor is on for the same period of time of every sample period. Allow power saving and long time battery life of sensors (i.e. 60 days for sampling periods of 30 seconds)
TASK Important Subsystems & Tools TASK TinyDB is included into a toolkit called Tiny Application Sensor Kit (TASK) Apart from TinyDB, TASK offers: TASK Server: server process running on a sensor network gateway that acts as a proxy for the sensor network on the internet. TASK DBMS: A relational database that stores sensor readings, statistics… (currently only accepting PostgresSQL) Task Client Tools: including TASK Deployment Tool that helps users record sensor node metadata, TASK Configuration Tool that helps users choose data collection intervals and data filtering and aggregation criteria, and TASK Visualization Tool that helps users monitor the network health and sensor readings. TASK Field Tool: running on a PDA that help users diagnose and resolve problems in certain areas of the network in the field.
TOSSIM Important Subsystems & Tools TOSSIM TinyOS simulator able to simulate thousands of nodes simultaneously, while displaying its interaction and providing run- time configurable debugging output, allowing a user to examine the execution of an application from different perspectives without needing to recompile PC application (executable) compiled directly from TinyOS with the option pc TinyViz is a Java-based GUI that allows visualization and controlling the simulation as it runs, inspecting debug messages, radio and UART packets, etc
TOSSIM Important Subsystems & Tools TOSSIM TOSSIM runs originally in text mode, showing events output and debugging information that can be configured. Accepts one single parameter: number of nodes to simulate, which will run the same application Apart from the possibility to shift debugging modes, 4 debugging modes are reserved for user-specific messages: dbg(, const char* format,...); As TOSSIM runs natively in the PC, traditional debugging tools, such as gdb (GNU debugger), can be used. However, event based nature of TinyOS (programmed with NesC and not C) makes debugging process not standard
TOSSIM Important Subsystems & Tools TOSSIM TinyViz is a Java based GUI for graphical simulations of nodes running TinyOS applications, behaving as a front-end for the TOSSIM simulator
TOSSIM Important Subsystems & Tools TOSSIM TinyViz builds its functionality with a set of plug-ins, software modules that watch for events coming from the simulation and react by drawing information on the display Main plug-ins are provided with TinyOS installation, and the implementation is opened to user-made plug-ins that can be included later in the GUI. Implemented Debug Messages: Generated by simulation and can be filtered Set Breakpoints: On a pattern matching bases on debug or radio messages Sent radio packets: Display only radio packets (also in debug messages) Radio links: Highlight active radio motes and sets arrows between communicating nodes Set location: Simulates node location for possible location services applications. Radio model: Sets the bit error rate according to simulated location and two radio models (empirical and fixed radius)
BOMBILLA Important Subsystems & Tools BOMBILLA Bombilla is a bytecode interpreter running on TinyOS, composed of several components that sit on top of several system components. Bombilla is an stack-based architecture: no embedded addresses are required Condensed high-level assembler instructions makes programs very short: getvar 0 # Get heap variable 0 pushc 1 # Push one onto operand stack add # Add the one to the stored counter copy # Copy the new counter value setvar 0 # Set heap variable 0 pushc 7 and # Take bottom three bits of counter putled # Set the LEDs to these three bits halt
BOMBILLA Important Subsystems & Tools BOMBILLA Additionally, Bombilla has an automatic network forwarding mechanism that allow programs installed in one mote spread eventually to every node of the network security problem Errors are caught at run time. When an error is triggered, system is stopped and debugging information sent through the UART Bombilla also has a 16 variable heap to provide a shared variable workspace (to be accessed only by special instructions): Event handlers implicitly lock all shared resources they use, so no race conditions are possible
BOMBILLA Important Subsystems & Tools BOMBILLA Bombilla programs are broken into capsules of 24 instructions, small enough to be retransmitted in a single radio message (AM) and eliminating the need of partial capsule buffering, saving RAM Two kinds of capsules: event handlers (in response to an event) and subrutines (called from another capsules). Each instruction is executed as a TinyOS task, allowing execution interleaving at instruction granularity. Three execution context: clock, send and receive. Each context is associated with different events Each context has two stacks: operand stack (instructions handling data) and return address stack (for subrutines). Architecture
BOMBILLA Important Subsystems & Tools BOMBILLA Architecture
TinySec Important Subsystems & Tools TinySec Link layer encryption mechanism for motes running TinyOS: Access control and confidentiality: Only authorized nodes can participate in the network Integrity: Against man-in-the-middle attacks Ease of use: Just an interface change Each node participating in the communication has the same key specified at compile time. That key is used for data encryption and verification, applied to every AM leaving the node An script is used to able TinySec on motes GenericComm (TinyOS radio stack) is replaced with SecureGenericComm, which enables authenticity. To use encryption, application must use specific sendMsg commands, exported also by SecureGenericComm
Conclusions AND FINALLY… TinyOS is a highly modular software environment tailored to the requirements of sensor networks needed of an efficient concurrency management Its design makes possible an easy evolution to support new hardware features and architectures coming with new times Its flexibility and popularity makes from TinyOS a safe solution to invest in. New features are constantly developed and new versions of the OS are being released every month. Only certain limitations, such a simplistic Scheduling or lack of memory protection, exist. However, TinyOS, as the most popular (and open source) OS for sensor networks, assures a future fix of virtually any issue due to its extensive communicity.