TOWARDS ENTERPRISE APPLICATIONS USING
WIRELESS SENSOR NETWORKS
Stamatis Karnouskos and Patrik Spiess
SAP Research, Vincenz-Priessnitz-Strasse 1, D-76131 Karlsruhe, Germany
Keywords: Wireless sensor networks, service-oriented architecture, enterprise services.
Abstract: Wireless Sensor Networks (WSN) have become a hot issue in research, and significant progress has been
achieved in the past few years. Recently, the topic has gained lot of momentum and has become increas-
ingly attractive for industry paving the way for new applications of sensor networks which go well beyond
traditional sensor applications. Sensor Networks is seen as one of the most promising technologies that will
bridge the physical and virtual worlds enabling them to interact. Expectations go beyond the research vi-
sions, towards deployment in real-world applications that would empower business processes and future
business cases. In this paper we look at WSNs from the business software perspective, including business
model, service-oriented architecture, integration with enterprise software systems as well as benefits and
lessons learned. As an example use-case we demonstrate the use of WSNs for hazardous goods management
in the chemical industry. Finally, based on our experiences we depict some directions that can be followed
in order to pave the road to real business applications for WSNs.
1 INTRODUCTION
A “smart item” is a device that is able to provide
data about itself or the object it is associated with
and can communicate this information to other
devices. An example of an enhanced smart item is
an environmental sensor that provides a complete
picture of a tracked object and its physical
environment. Through automatic, real-time object
tracking, smart-item technology can provide
accurate data about business operations in a timely
fashion, as well as help streamline and automate
operations. However, bridging the gap between the
physical and digital worlds requires a flexible and
scalable system architecture to integrate automatic
data acquisition with existing business processes and
to make ubiquitous computing a reality.
Wireless Sensor Networks (WSN) constitute
communities of advanced smart items and although
visions have been laid out and significant progress
has been done in the research domain (theory,
algorithms, protocols, implementations, trials etc.), a
vast number of questions still remains to be
answered: what steps need to be taken so that this
technology will not remain forever at the labs and
that it will be more than just hi-tech toys for
scientists? How can a wide economic and positive
social impact be achieved? Where are the markets?
Which will be the major drivers? How will we
progress towards a successful, secure, and open
infrastructure?
Taking into account the above challenges, our
motivation comes from real-world enterprise needs.
Our aim is to develop a novel service-oriented
approach to support business processes that involve
physical entities (goods, tools, etc.) in large-scale
enterprise environments. Software systems that
provide various services for the enterprise are
usually based on highly decentralized, manual and
thus often error-prone data collection. On the other
hand, data storage and business logic execution is
performed centrally in so called “back-end” systems.
An important intention is to apply recent advances in
the area of sensor networks, in order to distribute
not only data gathering tasks but also business logic
functionality to “smart” physical entities. In this
way, the status of enterprises, as it is represented in
business processes and in the supporting enterprise
software systems, can reflect more closely what is
actually happening in the real world.
It is state of the art to augment physical entities
in enterprise environments with embedded
230
Karnouskos S. and Spiess P. (2007).
TOWARDS ENTERPRISE APPLICATIONS USING WIRELESS SENSOR NETWORKS.
In Proceedings of the Ninth International Conference on Enterprise Information Systems - ISAS, pages 230-236
DOI: 10.5220/0002389702300236
Copyright
c
 SciTePress

technology to build automated item identification
and tracking systems. These systems can support
different processes related, for instance, to supply
chain management in intra- and/or inter-enterprise
business scenarios. Real world objects with sensors
attached reveal their identity or other dynamic/static
data for a communicating entity, e.g. another sensor.
Information gained that way can be basically used to
monitor the execution of business process tasks that
are implemented by back-end systems. In the CoBIs
project (www.cobis-online.de) our research focuses
on the development and the integrated application-
driven usage of so-called ‘Collaborative Business
Items’ (short CoBIs) that utilize a wide spectrum of
sensor networks technology.
Our vision is to delegate well-defined parts of
business logic functionality, i.e. process execution
from resource intensive back-end systems to
relatively low cost networked embedded systems
that run “at the point of activity”. These tiny systems
in our case build on sensor network technology that
enables them building collaborating ‘teams’ to work
together for a certain business relevant result
(Strohbach et al., 2004). The approach to handle
certain situations locally can lead to reduced process
execution and transactional costs, to improved
response times in business- and/or safety-critical
situations, and also to enhanced quality of process
results within a given operational environment. In
addition to improvements on existing business
processes, there is also a chance to identify new
business cases and develop corresponding useful
services based on this technology (Decker et al.,
2006). From a more technical point of view, flexible
handling of distributed process based on services
that run on CoBIs nodes can help saving back-end
systems’ resources, such as CPU-time, memory,
network bandwidth, etc., and can thus lead to
enhanced reliability, responsiveness and scalability
of the overall system.
2 BUSINESS MODEL
If WSNs are to be an integral part of commercial
applications, it is expected that the different compo-
nents that constitute a WSN infrastructure will be
driven by key players in that domain. Figure 1
depicts on the left side the service-oriented architec-
ture we used in CoBIs and on the right side a general
abstract model of the parties involved in the design,
implementation, deployment, and operation of such
an application. The business model depicted is
general enough and several other WSN approaches
can also be mapped to it.
Figure 1: Architecture and Business Model.
In detail, the following roles have been identified:
 Consumer (C): The end-user of the services
offered by the Business Service Provider. The
Consumer can be located at the edge of the ser-
vice infrastructure (and be a classical end user)
or it may be an application or other service, a
service management system etc.
 Business Service Provider (BSP): Composes
services delivered by various Sensor Network
Service Providers and Service Component Pro-
viders, and offers the resulting service to the
Consumers. A BSP may federate with other
BSPs in order to build services that are more
complex.
 Sensor Network Service Provider (SNSP):
Provides sensor network based services. It of-
fers facilities for the deployment and operation
of the respective code into the sensor network
and provides possibly generic services that run
in the sensor network nodes.
 Service Component Provider (SCP): Builds
service components and offers them (usually to
SNSP or BSP) in the appropriate form (e.g., as
binary or as source code). These components
usually run on middleware platforms delivered
by Middleware Providers.
 Middleware Provider (MP): Provides specia-
lized middleware platforms that integrate sensor
network based services
 Sensor Infrastructure Provider (SIP):
Provides managed sensor network infrastructure
and resources (bandwidth, memory, and proc-
essing power) to SNSPs. It offers a sensor
network platform over which services from
SNSP can be deployed. How a SIP offers the
underlying infrastructure depends on the ser-
vice-level-agreements (SLA) it has with the
respective partners.
 Hardware Software Provider (HSP): Sup-
plies the software to realize the basic general
Service Injector
SMART ITEMS
MODEL-DRIVEN APPLICATION
DEVELOPMENT
Application Model
Middleware
Service
Repository
System Model
System Monitor
Development
Tools
Service Mapper
Deployment
Description
RFID
Embedded
Platform
Sensor
Network
Emerging
Technology
Hardware Provider
Hardware Provider
Hardware Software Provider
Hardware Software Provider
Middleware
Provider
Middleware
Provider
Consumer
Consumer
Sensor Infrastructure Provider
Sensor Infrastructure Provider
Business Service Provider
Business Service Provider
Sensor
Network
Service
Provider
Sensor
Network
Service
Provider
Service
Component
Provider
Service
Component
Provider
TOWARDS ENTERPRISE APPLICATIONS USING WIRELESS SENSOR NETWORKS
231

execution environment capabilities including
tools for executing code in the sensor nodes is
provided by the HSP. It is usual nowadays that
the Hardware Provider also slips in this role.
This might not be always the case in the future
for commoditized hardware.
 Hardware Provider (HP): Manufactures the
hardware components of the sensor nodes e.g.
Motes, Particles, μ-Nodes etc.
It is still very early to clearly see such a model in
the market. Current market players at the moment
deliver almost all of the services depicted above,
trying to serve one-stop, turn-key solutions. How-
ever as the market matures it is expected that in the
mid-term the above roles will gradually be separated
and different players will compete at each level.
3 Service-Oriented ApproachesEnterprises are
moving towards service-oriented infrastructures.
Applications and business processes are modeled on
top of and using an institution-wide or even cross-
institutional service landscape. For any WSN
solution to be easily integrated in this environment,
it must feature a service-based approach. The overall
system architecture of the CoBIs project involves a
service-oriented architecture (Anke et al., 2006),
dividing the functionality of supported business
applications into different classes of services. The
core services include the basic, enabling capabilities
of a typical node, such as processing, storage,
sensing, actuating and communication. The base
services constitute primary functionality, mainly
focused on exchanging information within the
network reliably and efficiently. By combining base
services, more sophisticated ones can be realized.
Similar to the core services, the base services are
generally platform dependent. In order to describe
these services we have developed a service descrip-
tion language that we refer to as CoBIs Language
(CoBIL). CoBIL documents are created and edited
by service developers when they develop or com-
pose a new service. A CoBIL document will be used
to describe exactly one service. Typically, the
service description will be stored together with the
corresponding service executable(s) in the CoBIs
Service Repository.
The general architecture is depicted in the left
part of Figure 1. We can clearly distinguish three
different levels. At the bottom there are the smart
items such as the sensor networks or similar
systems. A middleware level couples them with the
services offered by enterprise systems. The platform
abstraction layer developed in this provides the
enabling technology to access all CoBIs services in a
uniform manner. It describes an open architecture
providing a service-oriented interface to the business
logic that can be adapted to different business
standards. At the same time it provides means to
integrate sensor node communication by supporting
web service proxies for services integrated on CoBIs
nodes. Therefore it constitutes a middleware layer,
which is commonly transparent for both the business
application and the underlying WSN systems. It
even allows the direct use of WSN services in
executable business process descriptions like the
Business Process Execution Language (BPEL).
The applications or business processes using the
WSN systems are based on several services running
either on the back-end enterprise system or on the
nodes themselves. This is one of the strong points of
service-oriented architecture: new services can now
be composed using generic ones as modular building
blocks. Collaboration among sensor nodes should
provide a number of substantial benefits over the
existing centralized schemes:
 Efficiency and low cost. The sensed data will be
processed within the network, communicating
only the relevant information among each other
and to the enterprise system. This only requires
modest communication bandwidth, and low en-
ergy needs.
 Scalability. Sensor data is processed locally
within the network, and those computations (if
designed accordingly) are dependent only on other
nodes nearby. Adding more nodes to the network
will not degrade the performance, since additional
processing is made available besides the increase
of sensor data. Local processing also avoids a
bandwidth bottleneck between sensor network and
back-end that would occur if all data was proc-
essed centrally.
 Fault tolerance and reliability. Nodes in the
network are in contact with each other processing
each others data and cross-verifying each other’s
results. Incorrect data samples or results will be
noticed by other nodes, and corrected if possible.
Therefore, we can avoid having a single point of
failure.
 Autonomous systems. Nodes are almost com-
pletely autonomous and require hardly any
Figure 2: Management of Hazardous Goods.
CoBIs Nodes
Enterprise Portal
Enterprise Portal
Hazardous Goods
Management System
Hazardous Goods
Management System
Environment, Health
and Safety System
Environment, Health
and Safety System
Web Browser
iView
ICEIS 2007 - International Conference on Enterprise Information Systems
232

infrastructure. No cables are needed, no installa-
tion and maintenance activity. Each node can act
autonomously or in cooperation with others based
on its internal goals.
 Enhanced accuracy. Through local cooperation,
sensor nodes can collect data more accurately.
These data can also be communicating with
neighboring nodes and deviations or errors are
easy to be pinpointed and corrected.
 Local intelligence: The decisions that need to be
made locally are needed for a multitude of rea-
sons. On the one hand, in order to provide
business logic, the nodes are to make decisions
and conversions on the information they gather.
On the other hand, in order to efficiently provide
the requested functionality, nodes need to share
information with each other. This has a tremen-
dous effect on an enterprise system since now the
intelligence does not rely on a central point but
can be distributed in the infrastructure and in
places that is really needed.
4 USE-CASE: HAZARDOUS
GOODS MANAGEMENT
Taking into account the business model and the
trends in modern enterprise systems, our motivation
was to apply WSN concepts to real world problems.
In that sense we have identified the management of
hazardous goods (Kubach et al., 2004) as a common
problem in the chemical industry. Human error
during storage and transportation of such substances
can have fatal consequences for the working
personnel as well as long-lasting effects on the
environment, not to mention the financial issues.
Although several paper-based risk management
procedures exist, all of them rely mostly on label-
ling, inventory and the worker’s experience.
However by using wireless sensor networks, we can
offer a more active and fine-grained approach. Such
a solution can provide in real time services like
conflict detection and warn the personnel about
possible safety dangers would be indispensable.
We have equipped a set of drums containing
different chemicals with wireless sensors (Particles)
and set-up the necessary infrastructure for commu-
nication with a back-end system, allowing for
remote monitoring and configuration. The back-end
system is SAP's Environment, Health and Safety
Application (EH&S), a standard enterprise applica-
tion for managing hazardous goods installed and
used by several chemical companies worldwide. The
data stored in the EH&S incorporates safety-relevant
substance information, such as chemical features,
handling and storage constraints for compliance with
international or corporate standards, etc. The sensor
nodes attached to the drums can communicate both
peer-to-peer and via a Platform Gateway with the
SAP EH&S. As this communication is real-time, we
are able to have a real-time model of the warehouse
status in the back-end IT systems.
In this way, Smart Drums act autonomously.
When the storage regulations are changed in SAP
EH&S, the new rules are automatically pushed to all
warehouses and all sensor nodes in the company. All
nodes that are currently not connected to fixed
infrastructure (e.g. during transportation) are
updated as they reconnect. We focused in the
following use-cases:
 Ensure that only a safe volume limit of a sub-
stance is stored in a storage location
 Prevent storage of incompatible chemicals in the
same storage location or at non-safe distance
 Prevent storage of chemicals in unsuitable storage
areas
 In case of a violation of the above rules, alert
warehouse staff and offer advice on how to re-
solve the situation
 Automatic suggestion of safe storage location for
each new drum arriving at a warehouse
Within this context, Smart Drums are able to
respond to dynamically changing context conditions.
Such changes can occur in their local environment,
but can also be caused by administrative changes
within the EH&S system. An overview of the system
prototype used in this lab trial is depicted in Fig-
ure 2. We can distinguish:
 Web Browser: the user connects via the browser
to the Enterprise Portal.
 Enterprise Portal (EP): The main entry point to
the CoBIs infrastructure for users. This SAP
product gives the user access to all the informa-
tion needed based on the role that has been
assigned to him/her. The prototype development
included the production of CoBIs-specific so
called iViews and the building blocks for the
portal’s role-based user interface.
 Hazardous Goods Management System (HGM):
This is an application developed in Apache’s
Tomcat that is used for managing hazardous
goods, e.g. like a simple warehouse management
system.
 Environment Health and Safety System (EH&S):
This is a standard SAP product. Via EH&S rules
for handling and storage of hazardous goods
including storage limit and incompatibilities are
managed for each substance.
 CoBIs Nodes: these are the infrastructure nodes
where CoBIs services are running on. For this
trial, we used Particle nodes.
The HGM portal monitors the warehouse status
based on the information sent by the particles nodes
attached to the drums. The hazardous goods business
TOWARDS ENTERPRISE APPLICATIONS USING WIRELESS SENSOR NETWORKS
233

Figure 3: Management GUI.
service that runs on the items continuously checks
whether the current storage conditions are compliant
with the storage rules defined in the EH&S system.
If the storage limit of one type of chemical is
modified in the EH&S system (e.g. because of
changes in official or corporate policies) this is
propagated to the particles, who store the new value
and start to verify the rules based on the new data.
The bridges located in the warehouse periodically
(with a moderate period) broadcast the current
storage limit for each chemical. This ensures that
even drums that have been out of communication
range, e.g. during transport on a truck, receive the
updated regulations as soon as they are stored in the
warehouse. Instead of using periodic rule broadcasts,
a more advanced, energy-aware protocol could be
used to disseminate rule changes.
A system management console, allows for a
uniform way of managing the CoBIs nodes. It
provides an abstraction layer for management
related tasks that hides the heterogeneity in nodes
and their services, by providing a common manage-
ment GUI. A monitoring tab provides real-time
information about the CoBIs network. As we can see
in Figure 3, the underlying network topology is
depicted. One can select a platform via the respec-
tive tabs e.g. the platform of Sindrion (Gsottberger
et al., 2004) nodes, Particle nodes (Decker et al.,
2005) or μNodes. By moving the mouse pointer over
the respective node, the user is able to acquire info
about that specific node according to the available
services e.g. battery, CPU, free memory, location,
temperature, light, acceleration, and field strength.
When a node is selected, additional info about the
node available in the Monitoring Service (if de-
ployed) is displayed, such as a complete list of
services running on the node etc.
Within our infrastructure, the sensor nodes detect
possibly dangerous situations, and inform workers
and warehouse managers via alarms. Having
business logic directly on the items allows for a
quick detection of any dangerous situation, even if
there is no network connection. Such properties
were requested by corporate end-users like BP who
want to prevent accidents on drilling platforms in the
North Sea, where a network link is not always
available. This approach also makes the complete
system more scalable, since decisions can be taken
locally, at the point of activity and the back-end is
only subsequently informed about the decision-
result. The business logic is encapsulated in services
that can be deployed to the nodes. The use of
service-oriented architecture (SOA) makes the
management of such complex systems more
responsive and brings it closer to real-world situa-
tion where they can be applied.
The direct business benefits of using WSNs as
illustrated by this trial are:
 Automatic compliance with legal or corporate
regulations concerning the storage of hazardous
goods
 Warning of security and management staff about
potentially dangerous situations
 Increased efficiency / safety of handling by
suggesting a safe storage location for each new
drum arriving in the warehouse and advice for
resolution of alert situations
 Introduction of smartness within the on-site items
increasing reliability, scalability, and autonomy of
the approach
5 THE PERSPECTIVE OF WSN
IN ENTERPRISE SERVICES
A CoBIs system, just like any other wireless sensor
or ubiquitous system will not be set up and run for
the sake of its own. It is designed to support a
business process by either providing real time data,
executing business logic on the items, or providing
decisions for the further process flow. WSNs or
ubiquitous systems will only be deployed in the
future, if the costs for setting up and maintaining it
are less than the costs that are saved (bottom-line
growth) plus the additional top-line revenue that is
generated. This fact is depicted in Figure 4.
The technology will lead to increased turnover
(because of higher process efficiency or quality or
reduced loss) and / or lower operational costs
(because of increased automation). Both effects
increase the yield. That increase caused by CoBIs
sets the upper boundary for additional money a
company would be willing to invest into the new
technology. Of course, some properties like in-
creased workplace safety or faster time to market do
not easily fit into that scheme. However, one can try
ICEIS 2007 - International Conference on Enterprise Information Systems
234

Figure 4: Budget for installing and maintaining a SOA
WSN solution e.g. CoBIs.
to monetarize these benefits over the whole system
lifetime and treat them as saved costs.
When a company sets up a CoBIs network to
increase efficiency of its current business processes,
the dominant share of costs will not be hardware
costs (since it is expected to become very cheap in
the future) but the development of embedded
software for the embedded processors and secondary
components as well as for the integration logic to
integrate the sensors into the current enterprise
systems. The CoBIs framework already covers many
aspects of device integration like platform abstrac-
tion so that application developers can deploy their
services in a WSN-agnostic way i.e. without writing
WSN-platform specific code etc. However, it must
be ensured that the costs for the remaining develop-
ment that is needed to deploy supported hardware in
a scenario are minimal.
Having analyzed, designed, implemented and
trialed a WSN based enterprise service, we have
often come to conflicts between market needs and
technology, and we have identified some directions
which we think need to be successfully tackled
before WSNs empower future enterprise services.
Some key results include:
 The concept of collaborative smart items that can
execute business logic is worthwhile and truly
innovative solutions for real world needs can be
realized. For SMEs there is room to invent and
innovate at hardware and software level. The
industry is making some attempts to test the new
technology, however most of the projects remain
simple trials and no wide-spread real-world com-
mercial platform/solution exists; something that is
however understandable taking into consideration
the challenges that remain to be solved.
 As we move towards the “Internet of Things”, the
CoBIs approach represents a sophisticated imple-
mentation of it. The things are not passive objects
of sensors and actuators, but actually can host
intelligence and take part in collaborative scenar-
ios. The idea of distributing logic within the
network (back-end-gateway-nodes) and not only
at end-nodes enables the implementation of a fine-
grained open service infrastructure and is a prom-
ising approach that may effectively deal with
robustness, scalability, adaptability and interop-
erability.
 Openness of the infrastructure should be the
focus. We need to agree on common, open, exten-
sible interfaces at different levels, so that the
underlying parts can evolve independently. This
should be invisible to upper layers which only see
a common web-service enabled interface to any
sensor network platform. In that case we can
expect innovation at all levels in parallel and
better integration of the whole infrastructure.
 The WSN market and its economic prospects are
not clear to the wide public contrary to simple
forms like RFID tags. There is still a lot of “hype”
in the community and WSNs are still seen by
many commercial companies at the moment as
toys for scientists rather than real business oppor-
tunities. However, this might change in the mid-
/long- term especially if real world scenarios are
demonstrated successfully. For the last to happen,
the research community should not try to simply
tackle general problems in WSNs, but primarily
focus on real-world industrial problems and take
into account their requirements. In other words,
the solutions developed by the WSN community
should be built to satisfy real-world requirements
rather than building solutions first and trying to
identify problems later. We do not foresee a “one-
size-fits-all” WSN platform, but rather clusters
solving domain-dependent problems.
 Regulators and policy makers have to be consid-
ered more intensively in the WSN community
since at this early stage they provide guidelines
for interoperability, consumer protection. Adher-
ence to standards could be is still rather the
exception and not the rule and can still be a strong
value proposition. The impact of wide-spread
WSNs on traditional regulated infrastructure has
to be assessed. For instance issues like roaming,
billing, network access, radio spectrum manage-
ment etc will probably arise.
 Security, trust and privacy needs to be investi-
gated. CoBIs assumes a closed infrastructure and
at the moment the trials were conducted simply to
prove the concept. However if similar scenarios
are to be commercialized, a solution to the secu-
rity related challenges needs to be found.
TOWARDS ENTERPRISE APPLICATIONS USING WIRELESS SENSOR NETWORKS
235

 New tools that help with (also wireless) mass-
deployment of services as well as with design of
models and business process adaptation for WSN
based infrastructures need to be developed. WSN
networks are expected to be too complex and
therefore abstraction layers and tools to manage
this complexity are needed at several levels.
 One new class of tools could analyze business
processes, expressed e.g. in BPEL that make use
of sensor network services and automatically
identify sub-processes that can be processed
autonomously by the WSN. The sensor network
could be augmented with execution capabilities
for efficiently encoded business process descrip-
tions.
 The hardware used needs to be reduced in size,
cost and energy consumption, increased in com-
puting power and able to act reliably. This is
expected to be solved in the mid- / long-term.
 Both industry and academia should work towards
developing appropriate business models, stan-
dards for several levels in WSNs, and tackle the
security issues. Integration of the semantic web
and a service based infrastructure (as followed by
CoBIs) provide a really promising approach.
The WiSeNts Research roadmap (Marron et al.,
2006) provides an excellent source for a more
general view of the challenges, trends and roadmap
for WSNs.
CONCLUSIONS
We have presented our opinions and experiences
from the design, analysis and realization of a WSN
based service solution for the management of
hazardous goods. We have investigated from the
business perspective focusing on aspects such as
service-oriented architecture, better support for
business processes etc and laid out the motivation
behind our decisions. We have also presented a
business model for WSNs while in parallel we have
provided some directions that from the business
perspective need to be tackled if WSN technology
should transform from a mere toy for scientists to a
powerful tool, enabling real-world business applica-
tions. There is still a long way to go, however initial
efforts are promising and we expect that the whole
area will be radically reshaped within the next years.
REFERENCES
Anke, J., Müller, J., Spiess, P., Weiss Ferreira Chaves, L.,
2006. A Service-Oriented Middleware for Integration
and Management of Heterogeneous Smart Items Envi-
ronments, proceedings of the 4th MiNEMA workshop
in Sintra, July 2006.
Decker, C., Krohn, A., Beigl, M., Zimmer, T., 2005. The
Particle Computer System, IPSN Track on Sensor
Platform, Tools and Design Methods for Networked
Embedded Systems (SPOTS), Proceedings of the
ACM/IEEE Fourth International Conference on In-
formation Processing in Sensor Networks (IPSN05),
pp 443-448, Los Angeles, 25-27 April 2005.
Decker, C., Spiess, P., Moreira sa de Souza, L., Beigl, M.,
Nochta, Z. 2006. Coupling Enterprise Systems with
Wireless Sensor Nodes: Analysis, Implementation,
Experiences and Guidelines, Pervasive Technology
Applied @ PERVASIVE, May 7, 2006.
Gsottberger, Y.; Shi, X.; Stromberg, G.; Weber, W.;
Sturm, T.F.; Linde, H.; Naroska, E.; Schramm, P.,
2004. Sindrion: A Prototype System for Low-Power
Wireless Control Networks. IEEE Conf. on Mobile Ad
hoc and Sensor Systems, 25-27 Oct. 2004.
Kubach, U., Decker, C., Douglas, K. 2004. Collaborative
control and coordination of hazardous chemicals,
Proceedings of the 2
nd
international conference on
Embedded networked sensor systems 2004 (SenSys
2004), Baltimore, MD, USA, November 03 - 05, 2004.
Marron, P.J., Minder, D., 2006. Embedded WiSeNTs
Research Roadmap, Logos Verlag Berlin, ISBN: 3-
8325-1424-4, www.embedded-wisents.org
Spiess, P., Vogt, H., Jütting, H. 2006. Integrating Sensor
Networks with Business Processes, Real-World Sen-
sor Networks Workshop at ACM MobiSys, Uppsala,
Sweden, June 19, 2006.
Strohbach, M., Gellersen, H., Kortuem, G., Kray, C. 2004.
Cooperative Artefacts: Assessing Real World Situa-
tions with Embedded Technology, Proceedings of the
6th International Conference on Ubiquitous Comput-
ing, Nottingham, UK, September 7-10, 2004.
ICEIS 2007 - International Conference on Enterprise Information Systems
236