The nesC Language: A Holistic Approach to Networked Embedded Systems

Tony Chen

April 29, 2003

Paper Authors and Credits

David Gay, Phil Levis, Rovert von Behren, Matt Welsh, Eric Brewer, David Culler

http://nescc.sourceforge.net/ http://webs.cs.berkeley.edu …and yet another paper from Intel/Berkeley

Research Group

Presentation Outline

Introduction Background nesC Design Evaluation Related Work Discussion and Future Work

Introduction to nesC

With emerging technology, single chip systems that integrate low-power CPU and memory, radio/optical communications and MEMS sensors are now possible. These nodes are called “motes”.

– Motes will be low cost (~10¢/unit) and low-power consumption (last for years or even use solar power).

This papers presents nesC which is a systems programming language for networked embedded systems.

– Supports programming model that integrates reactivity to the environment, concurrency, and communication.

– nesC simplifies application development, reduces code size and eliminates bugs. Key focus of nesC is holistic system design.

– This approach yields 3 important properties: 1) Resources are known statically. 2) Rather then use general purpose OS, applications use suite of reusable system

components along with application specific code. 3) Hardware/software boundary varies depending on application and hardware platform. Must

design for flexible decomposition.

Challenges nesC Must Address

Driven by interaction with environment.– 1) Motes are event driven. React to changes in the environment (i.e. message arrival,

sensor acquisition) rather then interactive or batch processing.– 2) Event arrival and data processing are concurrent. Must now address potential

bugs like race conditions. Limited resources.

– Motes have limited resources b/c of small size, low cost, low power consumption. Moore’s law will be applied to reduce size and cost, not increase resources.

Reliability.– Need to enable long-lived applications. Hard to reach motes, therefore must reduce

run-time errors since only option is reboot. Soft real-time requirements.

– Although tasks like radio management/sensor polling are time critical, they do not focus on hard real-time guarantees.

– Timing constraints are easily met by having complete control over OS and app.– Radio link is timing critical but since radio link is unreliable, not necessary to meet

hard deadline.

nesC Contributions

1) Defines component model that supports event driven systems.

– Model provides bidirectional interfaces to simply event flow, supports flexible hardware/software boundary, admits efficient implementation that avoids virtual functions and dynamic component creation.

2) Defines simple but expressive concurrently model with extensive compile-time analysis.

– Can detect most race-conditions at compile time. Allows apps with highly concurrent behavior with limited resources.

3) Provides unique balance between accurate program analysis (improves reliability, reduces code size) and expressive power for building apps.

nesC In Use

Many applications already using nesC: TinyOS, TinyDB, Maté.

Background

Wireless sensor networks have many tiny, resource limited devices called motes, with these characteristics:

– Motes interact with environment through sensors.– Communicate via wireless network.– Long lifetime.– Physical inaccessibility.

Mote hardware evolves rapidly (as can be seen from Table 1). The sensor network OS and programming language must make it easy for application to adapt to these changes.

TinyOS– OS specifically designed for network embedded systems. Takes only 396b of code

and data total.– nesC was designed to support TinyOS programming model and re-implement TinyOS

in nesC.– TinyOS has component based architecture, simply event based concurrency model,

and split-phase operations.

TinyOS Is Component Based

Component Based Architecture– TinyOS provides set of reusable components.

App connects components using wiring specification.

Most OS components are software. Some are wrappers around hardware. Components are modular so apps can pick only services that are needed.

Task and Event Based Concurrency

Two sources of concurrency in TinyOS, tasks and events. Tasks are deferred mechanisms of computation that run to completion.

Can’t preempt other tasks.– Components post task, then the post operation returns. Task is later run by

scheduler.– Components use task when time restriction is not strict.– Tasks should be short. Long operations should be broken up into small

tasks.– Lifetime requirements of sensor networks prohibit heavy computation

(reactive). Events also run to completion. Events can preempt tasks or another

event.– Events signify completion of split-phase operation or event from

environment. TinyOS execution is driven by events representing hardware interrupts

Split-Phase Operations

Because tasks execute non-preemptively, TinyOS has no blocking operations.

All long-latency ops are split-phase meaning op requests and completions are separate functions. Non-split phase ops don’t have completion events (i.e. toggle LED).

Commands are requests to start and operation. Events signal completion of operation.

Send a packet example: one component invokes send, another communication component signals sendDone when packet is sent.

Surge: A Sensor Network Application

Simple application that performs periodic sampling and using ad hoc routing over wireless network to deliver information to base station.

Each node listens to messages and chooses node with least depth to be parent. Base station will periodically broadcast beacon messages with depth 0.

Each node estimates parent’s link quality, if link quality falls below that, node selects new parent from their neighbor set based on link quality estimates and depth.

If node receives message from another node, it forwards that message to its parent.

nesC Design

nesC Is An Extension of C– C provides little help in writing safe code or in structuring applications.– nesC is safer (less expressive power) and helps with structure (components).

Whole Program Analysis– nesC programs are subject to whole program analysis (for safety) and to optimization

(for performance). Do not consider separate compilation in nesC design. nesC Is A “Static Language”

– No dynamic memory allocation and call-graph is fully known at compile time. This makes whole program analysis and optimization simpler and more accurate. nesC’s component model and parameterized interfaces eliminate needs for dynamic memory

allocation and dynamic dispatch. nesC Supports and Reflects TinyOS’s Design

– nesC is based around concept of component and directly supports TinyOS’s event-based concurrency model.

– In addition, nesC addresses issue of concurrent access to share data.

Component Spefication

Apps are built up of components. Components provide and use interfaces. An interface is the only point of access to a component.

Interfaces generally model some kind of service (i.e. sending message).

Interfaces are bidirectional. They contain commands and events

Split-phase operations are clearly modeled by putting their commands/events in the same interface.

Separation of interface type definitions from their use in components promotes standard interfaces, making components more reusable and flexible.

Components are a clean way to abstract the hardware/software boundary.

Component Implementation

Two types of components, modules and configurations. Modules provide application code implementing one or more

interfaces. Configurations are used to wire other components together,

connecting interfaces by components to interfaces provided by others.

Explicit wiring of components via interfaces along with removal of function pointers makes control-flow between components explicit.

Discourage sharing of data amongst components. Abstract component is used in case there is a need for multiple

instances of a component.

Examples of Components

Concurrency and Atomicity

TinyOS code runs either asynchronously or synchronously. Two types of code in nesC

– Asynchronous Code (AC): Code reachable from at least one interrupt handler.– Synchronous Code (SC): Code that is only reachable from tasks.

The fact that task run to completion leads to a key invariant: SC is atomic with respect to other SC.

Atomic meaning any shared state between the 2 will be updated automatically. 2 claims:

– 1) Any update to shared state from AC is a potential race condition.– 2) Any update to shared code from SC that is also updated from AC is potential race

condition. Atomic sections are used to reinstate atomicity in the 2 above situations. Race Free Invariant: Any update to shared state is either not a potential race

condition (SC only) or occurs within an atomic section.– This is enforced at compile time.

Concurrency In nesC

To handle events and concurrency, nesC provides 2 tools: atomic sections and tasks.

Atomicity is implemented by simply disabling/enabling interrupts (this only takes a few cycles).

– Disabling interrupts for a long time can delay interrupt handling and make systems less responsive.

If potential race condition is present and programmer knows its not an actual race condition, can specify something as “norace”.

Parameterized Interfaces

Introduces runtime command and event dispatch.

A component declares an interface with a parameter list which creates a separate interface for each tuple of parameter values.

Wires to a parameterized interface must specify a specific interface with a compile-time constant.

Evaluation of nesC

Evaluate nesC’s component model, concurrency model, whole programming in-lining with respect to a set of representative TinyOS apps including Surge, TinyDB, and Maté.

Compiler for nesC creates a single C source file for app.

Compiled with gcc3.1.1 Atmel ATmega 103, an 8-bite RISC microprocessor

used on the Mica mote.

Component Model Evalutaion

– Core TinyOS source consists of 186 components total: 121 code modules, 65 configuration modules.

– Number of modules per app ranges from 20-69 with an average of 35.

– Each module is very small, averaging 144 lines of code. Small size show expressive power of nesC components.

– Bidirectional interfaces are excellent for event-driven systems since they provide a clean syntax for grouping related computation for split-phase and asynchronous operations.

Of the 186 components in TinyOS, 68% use at least one bidirectional interface.

Concurrency Evalutaion

Sample applications had on average 17 tasks and 75 events, each of which can be potentially concurrent activity.

– Also in sample applications, average of 43% of the code was reachable from an interrupt.

Implemented race detection using simple type based alias analysis to detect which variables are accessed by AC.

Analyzed TinyOS and its applications.

– 156 variables were found to have potential race conditions. 53 were false positives. 103 were real.

About 6 per thousand code statements.

Common Bugs and False Positives

Most common form of concurrency bug was non-atomic state transition.

False positives fell into 3 major categories:

– State-based guards Access to module variable that

is serialized at run time by state variable.

– Buffer swaps TinyOS communication

primitives use buffer swapping policy for memory management.

– Casual relationships Split-phase operations might

share variables.

Optimization Evaluation

Dead code trimming reduced code by 9%.

In-lining yielded another 16%.

– In-lining only created a 1% improvement in CPU utilization. CPU intensive code not dominated by function calls.

Related Work

Other Languages– Modula-2 and ADA both explicitly export and import interfaces.

Less flexible then nesC. No explicit binding of interfaces.– nesC module system is very close to Mesa’s.– Giotto, Estereal, Lustre, Signal and E-FRP are languages that target embedded, hard real-time

systems. Stronger time guarantees the nesC but not a general programming language.

– VHDL and SAFL are used to model hardware. But concurrency can’t cross component boundaries. Distributed systems components are large scale, dynamically loaded/linked and possibly

accessed remotely.– ArchJava has bidirectional interfaces but fan-out is limited.

Other OS’s– Flux OSKit/Knit lack bidirectional interfaces.– THINK does not employ program analysis and optimization.– Click, Scout, x-kernel are specialized not general like nesC.– VxWorks, QNX, WinCE are too big and provide much more functionality then is needed.

Other Code Analysis and Optimization– ESC and Sun LockLint have trouble with first-class functions and aliasing.

nesC Recap and Future Work

nesC was originally designed to express concepts embodied in TinyOS.

Focus on holistic system design by making it easy to assemble apps that include only the necessary OS parts.

Component model allows alternate implementation and flexible hardware/software boundaries.

Concurrency model allows highly concurrent programs with limited resources.

Use of bidirectional interfaces and atomic statements permit tight integration of concurrency and component oriented design.

Lack of dynamic allocation and explicit specification of apps call graph make it easier to run whole-program analysis and optimizations.

– Aggressive in-lining reduces memory footprint and static data-race detection reduces bugs.

3 areas of future work are concurrency support, enhancement to language features, and applications to other domains other then networked embedded systems.

Concurrency Support

Perhaps can build higher level synchronization mechanisms such as semaphores, condition variables, atomic queues and locks etc. Would need to prohibit blocking for some of these.

Use alternative methods for implementing atomic sections, i.e. non blocking synchronization primitives.

– Currently depend on assumption of uniprocessor and no virtual memory since page fault should not occur within an atomic section.

Mesa monitors is the closest comparable concurrency model to nesC.

Language Enhancments

Multi-client services with per-client state are not well supported.– Abstract interfaces can be used. Parameterized interfaces are

currently used. Looking for better approach to this. Split-phase operations are difficult to program. Reintroducing

the convenience of a threaded model would greatly simplify programming.

Automatically transforming blocking operations into split-phase calls would preserve lightweight concurrency without forcing the programmer to build continuations within components.

Provide explicit support for FSM-style decomposition.– Simplify component design and allow properties of FSM to be

statically verified.

Application To Other Platforms

Extended to enterprise class apps and Internet services.

Would need to extend nesC to handle dynamic memory and component allocation, as well as patterns like message buffer swap.

nesC should be extended to support multi-processors, blocking operations and threads.

Questions???

(Please don’t ask me anything.)