Aspect NesC/TinyOS

TinyOS is a popular micro-operating system in the embedded systems circle. With it is a special, component-based adaptation of C called nesC. TinyOS and nesC tightly work together to help build smart sensory devices (called "motes") which often include tiny radios for inter-mote communications. Much of the work by individual programmers has been contributed back to the source tree (at SourceForge) for others to use, offering the neophyte at least 11MB of data and program source to start from.

Embedded systems requires "tight" programming in tiny spaces, because the target device only has a few K bytes available for the program and less for variables and/or stack. There is only so much that dead-code elimination can do to reduce the size of a program executable. Aspect-oriented software design (AOSD) can help identify crosscutting concerns that affect components and even whole systems. The goal, then, is to apply AOSD tools and modularize crosscutting concerns and save program space and time.

Identifying and isolating embedded aspects can:

Focus efforts on core functionality increasing product maintainability,
Define feature boundaries enabling productline stratafication,
and Identify product constraints like program size and battery life which have become more entangled than ever.

Initially, we are researching questions that could directly benefit embedded systems development and indirectly AOSD in general:

How does AOSD have to change to accomodate extra-programming entities like "component wiring" or "interface" definitions?
What are the implications of "command" (call down) vs. "events" (callback) in aspect advice?

Progress

Here are a few items that have been discovered:

Concern	Locus	Effect
Initialization	Interrupt re-enabling in interrupt handler	Start up process; ensure safe state
Initialization	StdControl(s)	Broadcasting messages to start up devices
Repetitive Actions	Potentiometer must have finalize() be called after each action	This is a technique that allows for external registers to fluxuate during computation. The data registers is "fixated" when computation is complete.
Repetitive Actions	Component Linkage	Linking in specific components like communications requires always pulling in several pieces... aspect?
Power Management	Power() in Timer.Start()	Power() needs to be called in unexpected locations: could be related to sleep modes(?)
Atomicity	"atomic"	In a conconcurrent environment locking critical section is imperative but is not "core" to the algorithms and may be removed if concurrency is omitted.
???	timer	Some components require (?) a timer tick -- something that might be outside the purvue of their core responsibilities.


Copyright © 2001-2006 Intelligent Algorithmic Solutions and Sean Walton	eMail