Networking Reference
In-Depth Information
Consider for instance an environmental river-monitoring scenario where mul-
tiple entities may leverage a WSN to gather temperature, pollution, and water
level data. Both governmental agencies as well as ecological scientists from uni-
versities are interested in pollution and temperature data, whereas local govern-
ment is interested in flooding data to protect the livestock of the community
along the river. During commissioning, certain activities are executed: first and
foremost the application is composed out of subprograms. These programs are
then deployed. Finally an initial configuration defining fixed sensor sampling and
reporting rates is established. From this scenario, we can identify three drivers
for run-time customization:
1. Since at commissioning time, ecologists do not know what base pollution
values to expect, the alerting threshold will need updating. In fact, this value
will change frequently with evolution of water quality. Within a long-lived
application, customization happens frequently reflecting tuning or changing
2. The data gathering activities of the government and the scientist are funda-
mentally similar yet subtle differences in level of detail need to be accommo-
dated. Large eciency gains (footprint, programming effort) can be made in
the WSN by using customized variants of the same application, for exam-
ple with different operational parameters. Within a multi-actor setting, the
possibility to customize greatly facilitates reuse and resource eciency.
3. Alerting thresholds need to be adjusted depending on the location of the
sensor and time of season, for example in extreme rainfall events pollution
will typically be very high because of sewerage overrun. Customization rules
describe change in system behaviour in response to system dynamics.
Due to dynamism in many of these scenarios, WSN customization is not solely
aone-timeprocessaspreviousrealworldWSN deployments [16] have revealed,
but rather a continuous process. Many operational parameters of the WSN (or its
constructing system or application parts) will change continuously in response to
changes in objectives of applications users, system administrators or in response
to internal change such as mobility or available energy. In addition, the change
cycle of above customizations is closely related to the type of abstraction which
is used to realize that particular part of the application that is impacted by
this change. For instance, pure business functionality, such as a generic sensing
component, is changed less often compared to the rules governing the sampling
behaviour of that component during extreme rainfall.
Finally, since the above customizations are performed by both application end-
users or system administrators during the run-time phase of the application, it
should be recognized these users prefer to express their goals differently than
developers [2]. Abstractions offered for run-time customization must therefore
be intuitive and suciently high-level. In this context, rule-based declarative or
imperative approaches are typically considered to be appropriate abstractions
From this, the requirements of the mechanism to support these run-time
customizations can now be identified:
Search MirCeyron ::

Custom Search