There are several important consequences of the design
space as discussed above. Clearly, a single hardware platform
will most likely not be sufficient to support the wide
range of possible applications. In order to avoid the development
of application-specific hardware, it would be desirable,
however, to have available a (small) set of platforms
with different capabilities that cover the design space. A
modular approach, where the individual components of a
sensor node can be easily exchanged, might help to partially
overcome this difficulty. Principles and tools for selecting
suitable hardware components for particular applications
would also be desirable.
As far as software is concerned, the situation becomes
even more complex. As with hardware, one could try to
cover the design space with a (larger) set of different protocols,
algorithms, and basic services. However, a system developer
would then still be faced with the complexity of the
design space, since each application would potentially require
the use of software with different interfaces and properties.
In conventional distributed systems, middleware has been
introduced to hide such complexity from the software developer
by providing programming abstractions that are applicable
for a large class of applications. This raises the
question of whether appropriate abstractions and middleware
concepts can be devised that are applicable for a large
portion of the sensor network design space. This is not
an easy task, since some of the design space dimensions
(e.g., network connectivity) are very hard to hide from the
system developer. Moreover, exposing certain application
characteristics to the system and vice versa is a key approach
for achieving energy and resource efficiency in sensor
networks. Even if the provision of abstraction layers
is conceptually possible, it would often introduce significant
resource overheads – which is problematic in highly
resource-constrained sensor networks.