Making Embedded Software Development More Efficient with SOA

Abstract

SOA has been one of the most fascinating design paradigms for enterprise-level application software during the recent years. Key to its success has been the inherent support of reusability and scalability. This has brought forward significant advancements in the efficiency of SOA based software during development, deployment and runtime. As a result of the ongoing increase of computational power on embedded devices, and the ever-increasing connectivity of these, SOA has become relevant also for devices with medium computational capabilities like WiFi routers. Extrapolation suggests that SOA will soon be seen on typical embedded systems like sensors and actuators. In this paper we make a survey to outline the potential of SOA to become a key factor in embedded software development. We believe that by embracing this paradigm, current obstacles in the embedded development process can be addressed more effectively, leading to an efficient and less error prone design flow. Although some efforts in this direction have already been made, there are still areas open for research in order to optimize the development process for embedded SOA.

Full text

Page 1

Making Embedded Software Development More Efficient with SOA
Daniel Barisic, Martin Krogmann,
Guido Stromberg
Infineon Technologies AG
81726 Munich, Germany
daniel.barisic, martin.krogmann,
guido.stromberg@infineon.com
Peter Schramm
Robotics Research Institute
University of Dortmund
Otto Hahn Str. 8
44221 Dortmund, Germany
peter.schramm@udo.edu
Abstract
SOA has been one of the most fascinating design para-
digms for enterprise-level application software during the
recent years. Key to its success has been the inherent sup-
port of reusability and scalability. This has brought forward
significant advancements in the efficiency of SOA based
software during development, deployment and runtime.
As a result of the ongoing increase of computational
power on embedded devices, and the ever-increasing con-
nectivity of these, SOA has become relevant also for devices
with medium computational capabilities like WiFi routers.
Extrapolation suggests that SOA will soon be seen on typi-
cal embedded systems like sensors and actuators.
In this paper we make a survey to outline the potential
of SOA to become a key factor in embedded software devel-
opment. We believe that by embracing this paradigm, cur-
rent obstacles in the embedded development process can be
addressed more effectively, leading to an efficient and less
error prone design flow. Although some efforts in this direc-
tion have already been made, there are still areas open for
research in order to optimize the development process for
embedded SOA.
1. Introduction
In the last years, the SOA paradigm has been deployed
successfully in large, distributed software systems with
prime focus on business to business interaction. It is now
becoming more and more important also in the field of de-
vice integration. Transferring the SOA ’idea’ to the device
level is a promising approach to leverage ubiquitous intel-
ligent devices and create new synergies between software
systems and embedded devices. Key concept behind this is
to consider devices as holonic parts of a system, which by
definition are easier to manage and maintain.
The envisioned breakthrough areas of SOA for devices
are in particular the home automation and the industrial sec-
tor. In home automation, SOA helps to bridge the hetero-
geneity of products and brings new opportunities for net-
working and interaction of diverse devices. DLNA[2] is one
prominent example in the area of home automation, where
media content is shared between diverse devices like DVD
players, set-top boxes, mobile phones, etc. using SOA. For
industry applications SOA can be used for integration of
equipment or even products themselves into the enterprise
infrastructures. This allows a higher level of transparency
and opens completely new ways for optimization of busi-
ness processes.
Research activities in the last years have been dedi-
cated to apply and evaluate SOA on medium sized embed-
ded systems like embedded PC, PDAs or network routers
[10, 13, 17]. Development frameworks like gSOAP [16],
eSOAP [5], Intel Authoring Tools [8] or the aveLink suite
forUPnP[1]havebeencreatedtoprovidedevelopmentsup-
port for SOA on these devices. For smaller embedded de-
vices likes actuator and sensor nodes this is different. Al-
though multiple efforts have been undertaken to allow par-
ticipation of these devices in a SOA network [9, 20, 12, 6],
they focus on mechanisms to outsource computational load
from the devices. Thus, in the prior articles, a proxy ap-
proach is favored over direct implementation of SOA to
compensate for the computational restrictions of the small
devices.
In this survey paper we will investigate whether and how
using SOA in the embedded software development process
will help to develop code that is efficient enough for even
smallest devices. To this end, we will focus on the key el-
ements of SOA based development and link these to the
main obstacles in the development process for embedded
devices. Furthermore, we will outline the open issues that
need to be addressed to provide adequate development sup-
port for these target platforms, which we believe is missing
until now.
The remainder of this paper is structured as follows. In
Section 2 we present the benefit of SOA in device centric

Page 2

applications using representative examples. After that, we
give a brief insight to cornerstones of a selection of SOA
realizations in Section 3. Within Section 4 we analyze how
different flavors of SOA address critical system parameters
and outline the specific impact of certain SOA realizations
on a system scale. Then, we take a detailed look at the
embedded software development process and the influence
of the SOA paradigm on it. Section 6 will close the paper
with concluding remarks and an outlook on future work.
2. Device centric SOA
The SOA paradigm originates in the enterprise world
where the notion of services has been introduced in order to
enhance intra- or inter-enterprise business processes. The
core idea is to network software systems using abstract and
self-contained entities called services.
In the context of our investigation however, we need to
consider SOA having autonomous physical entities in mind,
to which we refer to as devices. In one word, our focus is on
thecollaborationofautonomousphysicalentitiesincontrast
to purely functional units as in classical SOA.
Let us now investigate the key characteristics of device
centric SOA using exemplary setups in the field of industry
and home automation.
2.1. Networking home appliances
In home automation setups devices are typically domes-
tic appliances such as lighting, window blinds and air con-
ditioning. In the following we will consider a simple sce-
nario with SOA enabled switches and lamps. If one presses
a switch to turn on the light or to invoke a predefined light
scene (i.e. turn on multiple lights) the switch uses the ser-
vice of the lamp(s) to turn on the light.
In such scenarios, the use of SOA has following benefits:
• Homogeneity: Heterogeneous systems become homo-
geneous using the notion of services. Although dif-
ferent vendors may provide different lighting systems,
from the SOA point of view they will provide a ser-
vice for switching the light on or off. Different vendors
may even provide the exact same service for their de-
vices. This allows our SOA based switches to be used
for nearly arbitrary lightings.
• Dynamics: In a device centric SOA network, services
are announced when devices become available. In our
setup this means that when new lighting is installed,
the respective lighting service is advertised. Next time
a switch is pressed it can also switch the new lamp, as
it is aware of all existing lighting services.
• Self-Description:
what capabilities other devices have using the self-
descriptive notion of services. This supports dynamic
Devices are enabled to find out
behavior of a system. If a switch was supposed to cre-
ate a light scene for watching movies, it would dim all
lights that are dimmable and switch the rest off. The
lighting itself will tell the switch if it is dimmable or
not.
2.2. Monitoring of hazardous goods in a re-
cycling facility
The application case ’information management for
tracking & tracing of products for recycling’, which is part
of the EU funded research project PROMISE focuses on
optimization of processes in a plastics recycling facility
[3, 7]. Wireless SOA enabled temperature sensors are used
to monitor containers carrying milled plastic material that
inheres the risk of self ignition. Each sensor provides a
service which conveys its ability to monitor temperature to
the facility’s management system. The management system
uses these services to assign monitoring tasks to the sen-
sors with an appropriate threshold with respect to its cur-
rent load. Respectively, sensors will inform the manage-
ment system if goods enter a critical state, so that appropri-
ate countermeasures can be initiated.
• Eventing: SOA is used to translate a physical value i.e.
temperature into a system parameter. With this, the
management system is now able to even react on phys-
ical events as they are now system events. In our case
the violation of the temperature threshold will lead to
an event based notification of the system, which then
will start countermeasures.
• Dynamics: Leveraging the dynamic lookup mecha-
nisms of SOA, the management system is aware which
containers are in the monitored storage area at any
given moment and can automatically react on incom-
ing or outgoing containers.
• Distribution of responsibility: Furthermore, the intrin-
sic philosophy of SOA dictates that the sensor them-
selves are responsible to implement the actual mon-
itoring and to determine when a threshold has been
reached.This minimizes management overhead in
backend systems and prescribes adequate distribution
of responsibilities.
3. Existing SOA realizations for devices
Until now we discussed the essence of SOA for devices
and sketched the general benefit using exemplary applica-
tions. In the continuation of this paper we want to discuss
in depth what implications arise when we use SOA for de-
vices to create a complete system solution.
In reality, the SOA concept is not applied singly but
needs a framework which provides means like protocols or

Page 3

data structures to bring SOA down to the implementation
level. Over the years, so-called middlewares have been de-
veloped to implement different flavors of SOA.
Middlewares that are especially relevant in the area of
SOA for devices are Jini, OSGi, UPnP and DPWS as they
try to address the dynamic nature of device integration
and/or have specifically been designed for application in
this area. We will now briefly outline the main concepts of
these frameworks in this section. Their effect on a system
scale is analyzed in Section IV.
3.1. Jini
Jini[22] is a Java based solution which provides mecha-
nisms for distributing and discovering services and supports
migration of executable code from one computer to another.
The core of a Jini system is a lookup-service which facili-
tates the search for services throughout the Jini network.
Each service has to announce its existence to the lookup-
service and to deposit a set of attributes as description of
its features. The communication with the lookup-service
is based on RMI [21] where the communication between
server and client is defined by the drivers and may therefore
use any proprietary protocol and format. Due to the RMI-
based communication, Jini requires a participating device
to execute a Java Virtual Machine and a respective Java ap-
plication.
3.2. OSGi
OSGi[15] is targeted on the connection of various com-
ponents in home networks. It is a Java centric approach
where so-called bundles disclose capabilities of a device
and allow interaction via local method invocation. A central
device(thegateway)providesthenecessarycommunication
platform on which the bundles are executed. Additionally,
standardized mechanisms are defined to dynamically install
or remove bundles and respectively discover active bundles
during runtime. Maintenance/installation of the bundles can
be done locally on the gateway or even remotely via the
Internet. Remote communication with bundles is not sup-
ported natively. For distributed communication a mapping
between OSGi bundles and UPnP devices has been defined.
3.3. UPnP
The Universal Plug and Play (UPnP) Architecture [23]
uses open and standardized protocols based on XML to de-
scribe and control devices. Information is transferred over
TCP/IP and UDP/IP using high-level communication proto-
cols like SOAP or GENA. All interaction is done on top of
the IP layer and is thus completely hardware-independent.
In UPnP, mechanisms for Addressing, Discovery, Descrip-
tion, Control, Eventing and Presentation are defined. A
peer-to-peer philosophy is inherit in all these parts, so that
no central component is needed to facilitate interaction
among the participants of a UPnP network.
3.4. DPWS
Devices Profile for Web Services (DPWS)[14] is the ap-
proach to make the successful ’Web Services’ fit for usage
on the device level. DPWS combines a set of functional-
ities taken from the existing WS protocol suite and speci-
fies additional protocols on top of them (WS Eventing, WS
Discovery). Like Web services, DPWS uses SOAP for mes-
sage transmission and XML as data format. The projects
SIRENA [18], SODA [19] and SOCRADES [4] consider
the application of DPWS in the industrial sector and until
now have created a DPWS stack capable to be executed on
embedded devices [11].
4. System level implications of SOA
The middlewares presented in the previous section share
the benefit of SOA on a high level. But as they use differ-
ent approaches to realize services and their interaction, the
resulting networks differ in key aspects.
4.1. Integration strategies
In order to make a device accessible via services it
needs to implement the protocols defined by the middle-
ware. UPnP and DPWS require devices to communicate
using SOAP or other XML based communication proto-
cols. Supporting non-binary protocols on the device calls
for adequate computational power, resulting in higher cost
and power consumption. If it is feasible to implement the
necessary functionality on the devices, they can be accessed
directly by other network participants.
For a device to participate in a Jini network it needs to
support Java and to execute a JVM. This is not feasible for
small devices. But as services provide a form of abstrac-
tion, we have a second possibility. So-called proxies can be
used which implement the middleware compliant services
on behalf of a device and interact with the device using pro-
prietary protocols. These proxies can be outsourced to net-
work nodes with higher computational capabilities like e.g.
a PC. Thus, even small devices can participate in a Jini net-
work via their proxies. As the abstract idea of services is
inherent to every SOA middleware UPnP and DPWS also
allow a proxy approach.
In case of OSGi all services need to be executed as Java
bundles on the central gateway. The bundles then communi-
cate to the devices using proprietary means. Thus, the proxy
approach is mandatory in OSGi.
Please note that as the communication between proxy
and device normally does not follow the SOA paradigm we
will not discuss the effect of this proprietary interaction on
the system.
4.2. Topology
Topology, whichdescribesthenetworksetupofadevice-
centric SOA, is another key characteristic. As already in-
dicated above, OSGi networks consist of a central gateway

Page 4

thathostsproxieswhichthencommunicatedirectlywithde-
vices. This results in a star topology. Such a topology is fa-
vorable for example in a home environment, where usually
at least one full featured device e.g. a PC or a WiFi router
exists that acts as gateway to which home appliances with
relatively small computational capabilities are connected to.
For Jini and DPWS (in a certain mode) services can be dis-
tributed in the network but need a central service registry
to allow dynamic device discovery. This means that a far
more open network topology is possible in comparison to
OSGi, but still these networks rely on a central component
to function. In UPnP and DPWS (in another mode) the net-
work is created on a peer-to-peer basis without the need for
any centralized responsibilities. Although Jini, UPnP and
DPWS favor a distributed network, it is still possible to use
proxies which are executed on a single machine. This way
a star topology is possible for these SOA middlewares as
well. The chosen topology has impact on the scalability
and robustness of the system, which we will address in the
following.
4.3. Scalability
Scalability refers to the capabilities of a system to com-
pensate an increase or decrease of the number of partici-
pants in the network. In this respect, an OSGi network with
only a central gateway is not able to scale with the number
of participants. The gateway is a dedicated piece of hard-
ware. When the number of services to be executed on the
gateway exceeds its capacity compensation is not possible
during runtime. The only chance to adjust to the needs is
to shutdown the network and to replace the current gateway
with more powerful hardware.
For Jini, UPnP and DPWS this is different, as they base
on distributed communication. The scalability of these net-
works primarily relies on the scalability of the underlying
physical network like e.g. Ethernet, WLAN. Fortunately,
scalability of physical networks has been well addressed in
the past. Applying extensible network topologies including
switches and routers allows for example company intranets
to scale to the number of employees. Thus Jini, UPnP and
DPWS are able to scale gracefully.
One exception for Jini and DPWS (in a certain mode) is
the central look up registry. Just like in the case of the OSGi
gateway, exceeding the capabilities of the registry is a prob-
lem. But unlike OSGi the registry is only queried to look
up a service and does not need to conduct expensive com-
puting. Thus, extension of the network has far less effect on
the service registry than on an OSGi gateway.
4.4. Robustness
The final aspect we will address is robustness. Here, we
will take a look at what will happen if devices are not avail-
able to the system due to a failure. For the chosen SOA re-
alizations, failure of a single service has only to be compen-
sated by depending services but has no effect on the SOA
system as a whole. This comes for free, when applying
the SOA paradigms. But there are also other effects to be
taken into account. In OSGi, the necessary OSGi gateway
is a single point of failure. As the services are executed
on the gateway a failure of the gateway will prevent any
further system activity. In Jini, a failure of the central ser-
vice registry is less severe. Without service registry it is no
longer possible to find a new service. But as devices in a
Jini network communicate directly with each other, already
connected services can continue to interact. An DPWS net-
work is even more fault tolerant, as mechanisms are defined
by which it is dynamically decided whether to use a service
registryor dodecentralizedlookup. Thus, failureof the ser-
vice registry in DPWS can be compensated by the network.
For a UPnP network a failure of a service has no additional
effects, as interaction is completely done on a peer to peer
basis.
4.5. Summary
Our system level analysis has shown that there are di-
verse ways to address the key system aspects using SOA
middlewares. In general, we cannot favor one middleware
over the other, as they all have advantages and disadvan-
tages depending on the field of application. However, it is
reasonable to believe that a suitable SOA middleware can
be found (or developed) for any system setup. Thus, the
SOA paradigm can be leveraged in arbitrary applications.
5. Implications of SOA on firmware develop-
ment
So far we have seen the relevance of SOA for devices,
and that middlewares exist by which SOA can be realized
in arbitrary applications. Additionally, it has been outlined
that integration of devices into a SOA network can be done
either directly or using a proxy approach.
When proxy software is used, the devices themselves
support a proprietary protocol and it is the responsibility
of the proxy to conduct SOA compliant interaction. Thus,
the software needed on the device to conduct the propri-
etary communication is not related to SOA and outside the
scope of this paper. The proxy software is basically PC soft-
ware which is subject to development issues already well
addressed in the area of enterprise SOA.
If we take a look at devices that directly support SOA,
this is different. The developed software for these devices
significantly differs from the SOA software for enterprise
systems. Main area of interest for embedded software are
development time, efficiency of code, effectivity of testing
and debugging. Reason for this are the restricted computa-
tional capabilities and significantly limited inspection capa-
bilities of the software and hardware during runtime.
Let us now take a look at the different development
phases and analyze the influence of SOA.

Page 5

5.1. Requirements Analysis
At the beginning of any software development process
the requirements have to be specified. These requirements
willbuildthebasisforthefollowingphasesofdevelopment.
The sole requirement for SOA software is to implement
a specific set of services. For every middleware it is defined
how to specify a service in a formal manner. For example,
UPnP and DPWS provide XML-Schemes to allow unam-
biguous definition of services which can be used throughout
the development process. Thus, the basis for the embedded
SOA software development is a formal specification of re-
quirements. This is beneficial for every software to be de-
veloped.
Additionally, enterprise and embedded SOA both use
service descriptions as basis for the development. Thus,
tooling and philosophy that is already in place for enter-
prise systems to create these descriptions can be reused for
embedded SOA.
5.2. Design
In the design phase we need to specify the structure of
the program. For SOA this means to design code which
implements a set of services.
The immediate benefit we gain from implementing em-
bedded SOA software is the partitioning of code.
vices are self-contained logical entities which are reflected
in code modules. Each module is responsible for imple-
menting a single service. The result is well partitioned code
which increases the maintainability of the sources.
In a first step, adoption of SOA therefore helps in the
higher level design of the software. In the next section we
will see, that SOA has even a bigger influence on the lower
level design and implementation.
Ser-
5.3. Implementation
SOA middleware implementations define formal service
descriptions and communication mechanisms between ser-
vices. These application-independent features can be im-
plemented in frameworks. If such a framework is used, the
lines of newly developed code will rapidly decrease and the
developer can focus on application specific code develop-
ment. Assuming that the number of errors inside newly de-
veloped code is proportional to the number of lines, using a
framework will decrease the number of lines and therefore
the number of errors.
Besides this general benefit, the implementation phase
can further leverage programming models to simplify soft-
ware development. A programming model defines what the
developer has to implement. One programming model is
that a library aids the developer by providing an implemen-
tation of a convenient interface to access the functionality
of the used framework. The framework provides functions
for handling the implementation of a service and also pro-
vides some function e.g. to send responses to the caller of
a service. This is a convenient way to create new services
with an existing framework. But this approach would not
fully exploit the advantages given by SOA.
Since the structure of the application is already given by
the service descriptions, the framework can exploit this in
order to provide the user with an even more convenient pro-
gramming model. A code generator like included into the
Intel Authoring Tools [8] implements such a programming
model. The code generator creates C source code for a cer-
tain platform from a given set of service descriptions. It
uses the service descriptions to create stub functions in the
source code in which the developer has to insert an imple-
mentation of the service. Hence, the developer has to write
less code which typically decreases the number of errors
and shortens the development time. After the implemen-
tation of the services has been inserted, the application is
working straight away. Even without adding an implemen-
tation, the framework compiles and provides dummy imple-
mentations for the specific services.
5.4. Testing
During and after implementation of the embedded soft-
ware, testing has to be done. Using the service philosophy
also brings added value in this phase.
As outlined in the first section, service descriptions pro-
vide the complete requirements specification for our soft-
ware. Existing tools like e.g. the Device Validator [8] offer
the functionality to conduct automated testing by repeatedly
invoking a given service using a specific value range for the
parameters. Therefore, it can be tested easily if the imple-
mented code formally complies with the service.
If an error occurs, SOA helps us to identify a faulty code
segment quickly. As there is a direct link between a ser-
vice and a code module, only a confined area of code has
to be debugged. Especially for embedded software, a faster
localization of the error source is of great value due to the
reduced insight into the system.
SOA furthermore allows rapid prototyping to signifi-
cantly simplify testing. Using the service descriptions pro-
totypeimplementationscanbecreated. Thisallowstosimu-
late device functionality during tests. In addition to that, the
development timeline for different devices does not need to
be synchronized any more, as missing functionality can be
simulated. This is especially beneficial for embedded soft-
ware development as its development timeline is less pre-
dictable than enterprise software development.
5.5. Deployment
The final step in the development process is the delivery
of the software. For each embedded device specific mech-
anisms are defined by which the code is delivered to the