The nesC Language: A Holistic Approach to Networked Embedded Systems - PowerPoint PPT Presentation

Loading...

PPT – The nesC Language: A Holistic Approach to Networked Embedded Systems PowerPoint presentation | free to view - id: 8ec0a-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

The nesC Language: A Holistic Approach to Networked Embedded Systems

Description:

2) Defines simple but expressive concurrently model with extensive compile-time analysis. Can detect most race-conditions at compile time. ... – PowerPoint PPT presentation

Number of Views:41
Avg rating:3.0/5.0
Slides: 31
Provided by: wwwcsa
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: The nesC Language: A Holistic Approach to Networked Embedded Systems


1
The nesC Language A Holistic Approach to
Networked Embedded Systems
  • Tony Chen
  • April 29, 2003

2
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

3
Presentation Outline
  • Introduction
  • Background
  • nesC Design
  • Evaluation
  • Related Work
  • Discussion and Future Work

4
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.

5
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. Moores 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.

6
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.

7
nesC In Use
  • Many applications already using nesC TinyOS,
    TinyDB, Maté.

8
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.

9
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.

10
Task and Event Based Concurrency
  • Two sources of concurrency in TinyOS, tasks and
    events.
  • Tasks are deferred mechanisms of computation that
    run to completion. Cant 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

11
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 dont 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.

12
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 parents 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.

13
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.
  • nesCs component model and parameterized
    interfaces eliminate needs for dynamic memory
    allocation and dynamic dispatch.
  • nesC Supports and Reflects TinyOSs Design
  • nesC is based around concept of component and
    directly supports TinyOSs event-based
    concurrency model.
  • In addition, nesC addresses issue of concurrent
    access to share data.

14
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.

15
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.

16
Examples of Components
17
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.

18
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.

19
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.

20
Evaluation of nesC
  • Evaluate nesCs 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.

21
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.

22
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.

23
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.

24
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.

25
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 Mesas.
  • 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 cant 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 OSs
  • 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.

26
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.

27
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.

28
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.

29
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.

30
Questions???
  • (Please dont ask me anything.)
About PowerShow.com