Image Processing Reference
In-Depth Information
software component can produce one or more types of data (usually upon the completion of their
execution).
An entity is also characterized by some functionality, meaning the sort of operation it can produce
on the input data. Based on their functionality, the entities can be classified as being part of a certain
protocol layer as in the previous description. For one given functionality, several entities might exist
inside a sensor node; to discern among them, one should take into consideration their capabilities. By
capability we understand high-level description containing the cost for a specific entity to perform
its functionality (as energy, resources, time, etc.) and some characteristics indicating the estimated
performance and quality of the algorithm.
In order for a set of components to work together, the way in which they have to be interconnected
should be specified. Most of the architectures existent up to this moment in the WSN field, assume a
fixed way in which these components can be connected, which is defined at compile time (except for
the architectures that, for example, allow execution of agents). To change the protocol stack in such
an architecture, the user should download the whole compiled code into the sensor node (via the
wireless interface) and then make use of some boot loader code to replace the old running code in it.
In the proposed architecture we are allowing this interconnection to be changed at run time, thus
making on line update of the code possible, the selection of a more suited entity to perform some
functionality based on the changes in the environment, etc. (in one word allowing the architecture
to become dynamically reconfigurable).
To make this mechanism work, a new entity needs to be implemented—we call this the data man-
ager. he data manager monitors the different kinds of data being available and coordinates the data
flow inside the sensor node. At the same time it selects the most fitted entities to perform the work
and it is even allowed to change the whole functionality of the sensor node based on the available
entities and external environment (for a conceptual schematic see Figure ..
The implementation of these concepts cannot make abstraction of the small amount of resources
each sensor node has (as energy, memory, computation power, etc.). Going down from the abstrac-
tion level to the point where the device is actually working, a compulsory step is implementing the
envisioned architecture in a particular operating system (in this case, due to the size and func-
tionality provided, maybe a better term is system software). A large range of operating systems
exist for embedded systems in general ([,] being two of the several tens of names). Scaled
down versions with simple schedulers and limited functionality have been developed especially for
WSN [].
Usually, the issues of system architecture and operating system are treated separately, both of them
trying to be as general as possible and to cover all the possible application cases. A simplistic view
of a running operating system is a scheduler that manages the available resources and coordinates
the execution of a set of tasks. his operation is centralized from the point of view of the scheduler
thatisallowedtotakeallthedecisions.Ourarchitecturecanalsoberegardedasacentralizedsys-
tem, with the data manager coordinating the data flow of the other entities. To obtain the smallest
overhead possible there should be a correlation between the function of the central nucleus from our
architecture and the function of the scheduler from the operating system. his is why we propose a
close relationship between the two concepts by extending the functionality of the scheduler with the
functionality of the data manager. he main challenges that arise are keeping the size of the code low
and the context-switching time.
4.3.3 Additional Features
As we mentioned earlier, the general concept of data is used rather than the event one. For the decision
based on data to work, there are some additional requirements to be met.
First of all, all the modules need to declare the name of the data that triggers their action, the
name of the data they need to read during their action (this can generically incorporate all the
