![](bg2.png)
supports the service is more business (or process)
oriented (instead of being technology oriented).
SOA enables software engineers to focus more on
the business logic and less on the interconnection
details. At the device level, service-oriented
architectures are emerging as the way to deal with
the increasing amount of embedded devices present
in our homes and offices.
In manufacturing, the inherent complexity
(necessarily hidden from the user) associated with
the presence of many types of devices and machines
makes the concept of service-oriented architectures
particularly attractive (SIRENA 2005, SODA 2006,
SOCRADES 2006). In fact, it leads to the idea that
each workcell programming block (that is, not only
physical devices) should be considered as a potential
device (SOA device style) that offers programming
services.
Considering a holonic workcell structure (Gou,
1998), with holons composed by automation
devices, like an industrial robot or a vision system,
one can classify as uncommon the need to have real-
time in the communication framework. The majority
of the component connections can instead be
described in terms of coarse-grained services, with
synchronous calls for setup and asynchronous events
for operation.
Considering an industrial robotic cell ecosystem,
past work (Veiga et al, 2007) revealed that service-
oriented architectures can provide a suitable
platform to a plug-n-produce environment.
Nevertheless, there are several approaches to
SOA, namely, if we consider only the four most
relevant platforms: Jini (Jini 2006), UPnP (UPnP,
2007), DPWS (Chan, 2006) and DSSP (Nielsen,
2007).
Jini is an architecture proposed by Sun
Microsystems based on Java. This fact makes it
platform independent but language dependent. It
also carries a large memory footprint, due to the
presence of a virtual machine and extensive
libraries, making it less appropriate for very small
devices.
UPnP and DPWS rely extensively on standard
network protocols such as TCP/IP, UDP, HTTP,
SOAP, XML, and the web technology. This makes
them platform and language independent, which is a
major advantage for their adoption. XML formats
are broadly used and accepted and provide modern
data interchange mechanisms and communications.
Their style is close to the one defined in the
enterprise world with the pair WSDL/SOAP.
Although similar in many aspects, the UPnP and
DPWS architectures use different languages for
device description and different protocols for
discovery and event notifications. There is an
enormous dynamics around DPWS. Nevertheless,
the new Microsoft operating system, Microsoft
Vista, supports both technologies under the name
plug-and-play extensions for Windows (PnP-X,
2006)
DSSP is a simple SOAP-based protocol that
defines a lightweight, REST-style service model
(Nielsen, 2007) that also relies extensively on web
technology. Paired with concurrency and
coordination runtime (CCR) it constitutes the major
parts of the Microsoft Robotics Studio (MSRS)
platform.
DSSP architecture style is radically different
from the WSDL/SOAP model. UPnP and DPWS are
very similar technologies which mean that concepts
and design styles can be easily ported between each
other.
In this work UPnP was selected due to
representativeness of the platform, the quantity and
quality of the tools available, and our experience
with the UPnP based services.
3 SCXML
StateChart XML (SCXML) can be described as an
attempt to render Harel StateCharts in XML. The
aim of this standard is to provide a basis for future
standards in the area of multimodal dialogue
systems. Even though this effort is being carried by
the W3C group for voice technologies, SCXML
provides a generic state-machine based execution
environment and a modern (XML) state machine
notation for control abstraction. In fact, SCXML is a
candidate for control language within multiple
markup languages coming out of the W3C.
Harel StateCharts are an extension to finite-state
automata. These extensions are needed in order to
make finite-state automata useful, and they include:
Hierarchy
– StateCharts may be hierarchical, i.e.,
a state may contain another statechart down to an
arbitrary depth.
Concurrency
– Two or more statecharts may be
run in parallel, which means that their parent state is
in two states at the same time.
History
– A state holds information that allow a
“pause and resume” behavior.
ICINCO 2008 - International Conference on Informatics in Control, Automation and Robotics
272