Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,065
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
204
Comments
0
Likes
3

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • About the use of CPU resources more efficiently See slide 23 About 2 levels of scheduling Events are executed immediately as can preempt… they don’t need scheduler. As there is no constraint, events are managed straight About “ Designed to scale with technology trends due to its support for crossover of software components into hardware ” Means that TinyOs is component based, new support for hardware can be added with rewriting or adding new low layer components, what is really convenient for future hardware implementations
  • About mote hardware affecting performance (ref. Tinyos-nsdi04.pdf) : The bit-level interface in rene requires the stack to handle interrupts at a high enough rate that the handler cannot encode or decode bytes ; encoding/decoding is deferred to tasks. Because it has a small buffer, the encoding layer (SEC DED) must run a task every byte time. This means no other tasks can run longer than a byte time (1.8ms). A larger encoding/decoding buffer would reduce sensitivity to long-running application tasks. In mica , the addition of a byte-level hardware abstraction reduced the interrupt rate. This increased the number of cycles available for each event, allowing encoding/decoding to remain in the interrupt handler. The maximum task length increases to a packet time, approximately 25 milliseconds.   Both the rene and mica2 stacks support low-power listening radio . However, it is much more efficient in the former, because the TR1000 (radio transceiver) can turn on very quickly, while the CC1000 turns on slowly. This latency determines how quickly the stack can sample the channel, and therefore how much it can reduce the cost of idle listening.
  • About FIFO task scheduling (ref. crcpress.pdf) :   Other priority-based or dead-line based scheduler can be implemented in the TinyOS framework The Scheduler puts the processor to sleep when the queue is empty, although peripherals are still on and can wake up the processor  
  • About 3 types of components (ref. crcpress.pdf) :     TinyOS distinguishes three categories of components. Hardware abstraction components map physical hardware into the component model. Mostly, this components export commands to the underlying hardware and handle hardware interrupts. Synthetic hardware components extend the functionality of hardware abstraction components by simulating the behavior of advanced hardware functions, e.g. bit-to-byte transformation functions. For future hardware releases, these components can directly cast into hardware. High level software components perform application specific tasks, e.g. control, routing, data transmission, calculation on data, and data aggregation.
  • About applications implemented already in TinyOS :   Basically system tests that can serve as an example for the developer.
  • About Blink application:   Is not true that BlinkM access directly ClockC , nor that ClockC access directly Hardware. Actually, BlinkM access SimpleTimer for the sake of clarity for the example, and SimpleTimer access TimerC that access ClockC (both as systems components). Then, depending the platform to compile, ClockC access final components with direct access to the clocks of the different devices. The TinyOS standard control interface . All components that require initialization or can be powered down should provide this interface. start() and stop() are synonymous with powering on and off, when appropriate. A nesC application consists of one or more  components linked together to form an executable. A component provides and uses interfaces. These interfaces are the only point of access to the component and are bi-directional.  An interface declares a set of functions called commands that the interface provider must implement and another set of functions called events that the interface user must implement . For a component to call the commands in an interface, it must implement the events of that interface. A single component may use or provide multiple interfaces and multiple instances of the same interface .
  •   Protocol center in lightweight transmission mechanism: 2-phase request-reply model (no acknowledgements)     See picture on Word document  
  • New implementations of AM allow 2 byte destination addresses and also implement Groups. Group’s ID allow several groups of motes to share the same radio channel without interfering each other. Group’s ID is one byte long and can be specified with an environmental variable or at compile time.
  • About “Three basic primitives are supported:” Best effort message transmission Addressing (address checking): If the message received is for me Dispatch (Handler invocation): if its for me, issue an event to invoke the handler
  • About how queries are retransmitted and identified The API for sending queries generates a globally unique identifier for each query Tuples include information about if they are to be aggregated to other nodes information or are collecting them. Also some counters are included
  • One significant advantage of TOSSIM is that, because it runs natively on a PC, you can use traditional debugging tools such as gdb. However, because TOSSIM is a discrete event simulation for large numbers of motes, traditional step-through debugging techniques only work on an event basis, and not cross-events. Unfortunately, gdb is generally designed for C and not nesC; the component model of nesC means that a single command can have multiple providers; referring to a specific command requires specifying the component, interface, and command. For example, to break on entry to the redOff command of the Leds interface of LedsC, one must type:     gdb build/pc/main.exe  // start gdb (gdb) break *LedsC$Leds$redOff Breakpoint 1 at 0x804c644: file tos/system/LedsC.td, line 97. run 1                   // run CntToLedsAndRfm with one mote The leading * is necessary so gdb can parse the function name correctly; otherwise, it looks for the function LedsC. Variables are similarly named. For example, to print the ledsOn variable of LedsC (which keeps track of on/off for the toggle commands), one types:   (gdb) print LedsC$ledsOn $3 = '' <repeats 999 times> Actually, this isn't quite correct, as the output above shows; in TOSSIM, ledsOn isn't a single uint8_t, but an array of 1000 of them. This is how TOSSIM handles the state of many motes; it compiles fields to be arrays of n elements, where n is the maximum simulation size. Whenever a mote accesses a component's state, it indexes into the array based on its node ID. Therefore, to refer to a specific mote's state, one needs to index into the array properly:   (gdb) print LedsC$ledsOn[tos_state.current_node] $2 = 0 '‘ We've supplied a simple gdb macro named VAR that handles this for you. Copy tos/ platform / pc /. gdbinit to your home directory (if there's already a .gdbinit there, just append this file).  Type quit and start gdb it again. Break in LedsC$Leds$redOff as before. Now, instead of the above command line, you can type:   (gdb) VAR LedsC$ledsOn $3 = 0 ''
  • About implemented plug-ins in TinyViz (ref. TINYOS tutorial, lesson 5) :   Debug messages: Shows a window with all of the debug messages generated by the simulation. You can select debug messages just from the selected group of motes, and also highlight messages that match a certain pattern. Note that the set of debug messages you see are controlled by the value of the DBG environment variable, just as they are when running TOSSIM in a stand-alone setting. So, if you only want to see debug messages of type DBG_USR1 and DBG_AM , start up TinyViz with: DBG=usr1,am tinyviz -run build/pc/main.exe 30 Set breakpoint: Allows you to set a breakpoint, which will pause the simulation when some condition is met. Right now, the possible conditions are (a) a substring match on a debug message, or (b) a match on the contents of a sent radio message. Multiple breakpoints can be set and they can be enabled or disabled by selecting them in the breakpoints list. ADC readings: Shows the most recent value of each ADC channel next to each mote. Sent radio packets: Shows a window with all sent radio packets, much like the Debug messages plugin. Note that the Debug messages plugin also shows this information. Radio links: Graphically displays radio message activity. When a mote broadcasts a message, a blue circle will be drawn around it. When a mote sends a message to another mote, a directed arrow will be drawn between the two motes. Note that this shows all message transmissions, regardless of whether they are successful; if a mote attempts to send a message but it is corrupted or lost, the arrow will still be drawn. Set location: Makes the virtual location of each mote available to that mote through the Location interface, found in apps/ TestTinyViz /Location. nc . This is accomplished by setting the value of three "fake" ADC channels (one each for X, Y, and Z coordinates) on each mote, which the FakeLocation component reads to determine the mote's virtual location. This is meant to act as a stand-in for a real localization service when simulating TinyOS apps. Radio model : Sets the bit error rate between motes according to their location and various models of radio connectivity. Enabling this plugin allows you to use realistic connectivity models in your simulations. There are two built-in models: "Empirical" (based on an outdoor trace of packet connectivity with the RFM1000 radios) and "Fixed radius" (all motes within a given fixed distance of each other have perfect connectivity, and no connectivity to other motes). Setting the "scaling factor" in the control panel simply scales the distance parameter of the model. Increasing the scaling factor will decrease the connectivity range of the chosen model. By selecting a mote in the display you can see its connectivity to other motes -- the number shown next to each edge is the probability of a packet getting through. Changing the scaling factor and clicking "update model" will update the model parameters, as will moving motes around in the display.
  • About Security problem in automatic spread applications (ref. Bombilla.pdf, section 5):   Capsules injected in the network with the forwarding bit set can spread without control flooding the network. The only mechanism provided now is a version number, so only capsules with a higher version number will be installed when received. Moreover, although no capsules would be installed, those ones with the forw instruction will be broadcasted, easily saturating the network. About LOCKING and SHARED VARIABLES:   Although there is an implicit lock on event handlers, this automatic procedure can be relaxed by experienced programmers to allow better parallelism
  • About Buffers     Storing and dealing with individual values is useful, but often being able to handle sets of data is needed. Bombilla provides buffers, which can hold up to ten variables. Buffers are typed. An empty buffer has no type, and takes on the type of the first variable put in it. For example, if the first variable is a light reading, then the buffer will become a light reading buffer. Attempting to put a variable of another type (e.g. a value) into the buffer will result in an error. Bombilla provides two buffers, which can be pushed onto the operand stack with bpush0 and bpush1. Variables can be placed in the buffers with the add instruction; this polymorphism of the add instruction leads to a more concise instruction set.   About Once context     There is an additional context, the “once” context. Unlike other contexts, which run their capsules many times, this context only runs its capsule once, when it is installed; this allows a user to initialize state, adjust constants, or perform other operations that only need a single execution .

Transcript

  • 1. TinyOS R eal-time and E mbedded S ystem L aboratory O perating System for Networked Sensors
  • 2. 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
  • 3. 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
  • 4. 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.
  • 5. Hardware Platforms
    • Hardware differences between mote platforms affect software structure, networking capabilities and performance
  • 6. Hardware Platforms Mica Mica2 Imote BTnode Mica2dot Spec Next Generation Sensor Networks? - All in one chip - “Smart Dust”
  • 7. 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.
  • 8. Design
    • In TinyOS is talked then about bidirectional interface , referring communication between components through events and commands.
  • 9. 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
  • 10. Design
    • Non-blocking requests to lower level components
    • Deposit request parameters into a component’s frame, and post a task for later execution
    • Can also invoke lower level commands, but cannot block
    • Return status to the caller
    COMMANDS
  • 11. Design
    • 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
    EVENTS
  • 12. 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
  • 13. Design
    • 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();
    • };
    Messaging Component AM_SUB_INIT AM_SUB_POWER AM_SUB_TX_PACKET AM_TX_PACKET _DONE AM_RX_PACKET _DONE Internal State AM_INIT AM_POWER AM_SEND_MSG AM_MSG_REC AM_MSG_SEND_DONE Internal Tasks Commands Events
  • 14. Implementation
    • Proprietary language based on C language called NesC
      • “ A l anguage 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.
  • 15. Implementation
    • 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
    EXAMPLE: Blink Application
  • 16. Implementation EXAMPLE: Blink Application module BlinkM { provides { interface StdControl; } uses { interface Timer; interface Leds; } } implementation { command result_t StdControl.init() { call Leds.init(); return SUCCESS; } command result_t StdControl.start() { return call Timer.start(TIMER_REPEAT, 1000); } command result_t StdControl.stop() { return call Timer.stop(); } event result_t Timer.fired() { call Leds.redToggle(); return SUCCESS; } } BlinkM.nc configuration Blink { } implementation {   components Main, BlinkM, SingleTimer, LedsC;   Main.StdControl -> BlinkM.StdControl;   Main.StdControl -> SingleTimer.StdControl;   BlinkM.Timer -> SingleTimer.Timer;   BlinkM.Leds -> LedsC; } Blink.nc interface StdControl {   command result_t init();   command result_t start();   command result_t stop(); } } StdControl.nc
  • 17. 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:
  • 18. 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)
  • 19. 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… )
  • 20. 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
        • Hop’s 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
  • 21. 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 motes’s IDs are in eeprom. An special boot loader, stored previously in processor’s program memory, executes to load and reboot the mote so new application will be run.
  • 22. Wireless Network Communication Active Messages SOME FIGURES
    • Throughput : ~800 bytes/sec (~6.5 Kbps) with 4b6 encoding
    Power Consumption
  • 23. 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
    226 3450 Total 30 16 0 172 178 82 Processor_init TinyOS scheduler C runtime 0 0 32 8 40 40 8 1 1 1 1 40 8 88 40 78 146 356 334 810 310 84 64 196 314 198 Multihop router AM_dispatch AM_temperature AM_light AM Packet RADIO_byte RFM Photo Temperature UART UART_packet I2C_bus Data Size (bytes) Code Size (bytes) Component Name Components CPU Utilization Energy (nj/Bit) AM 0.20% 0.33 Packet 0.51% 7.58 Radio handler 12.16% 182.38 Radio decode thread 2.48% 37.2 RFM 30.08% 451.17 Radio Reception - 1350 Idle 54.75% - Total 100.00% 2028.66
  • 24. Important Subsystems & Tools
    • TinyDB: The TinyDB "sensor network as database" application
    • Bombilla (Mat é ): TinyOS virtual machine
    • MatchBox: S imple mote filing system
    • TASK: The TASK "Tiny Application Sensor Kit" application
    • TOSSIM: T he TinyOS (PC) Simulation Environment
    • MIG: Message Interface Generator
    • Message Center : E asy injection of arbitrary messages into a mote network
    • TinySec : Secure communication on motes .
  • 25. 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 user’s own applications
  • 26. Important Subsystems & Tools TinyDB
    • Example:
      • Sensor equipped university building
      • Which classes are in use?  light sensor reading from sensor’s 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
  • 27. Important Subsystems & Tools TinyDB Classroom 1 B.S. Room Classroom 5 Classroom 4 Classroom 3 Classroom 2 22 12 1 49 32 5 43 55 4 56 48 2 15 10 3 22 12 1 49 32 5 43 55 4 56 48 2 22 12 1 49 32 5 43 55 4 NodeID Light Volume Query
  • 28. 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
  • 29. Important Subsystems & Tools TinyDB Query Window Command Window Status Window
  • 30. 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)
  • 31. 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.
  • 32. Important Subsystems & Tools TOSSIM
    • TinyOS simulator able to simulate thousands of nodes simultaneously, while displaying its interaction and provid ing 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 control ling the simulation as it runs, inspecting debug messages, radio and UART packets , etc
  • 33. 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(<mode>, 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
  • 34. 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
  • 35. Important Subsystems & Tools TOSSIM
    • TinyViz builds its functionality with a set of plug-ins, software module s 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 )
  • 36. 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
  • 37. 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
  • 38. 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
  • 39. Important Subsystems & Tools BOMBILLA Architecture
  • 40. 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 S ecureGenericComm , which enables authenticity. To use encryption, application must use specific sendMsg commands, exported also by S ecureGenericComm
  • 41. 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.