ARTICLE IN PRESS

Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755

Contents lists available at ScienceDirect

Robotics and Computer-Integrated Manufacturing

journal homepage: www.elsevier.com/locate/rcim

Experiments with service-oriented architectures for industrial robotic

cells programming
G. Veiga a, J.N. Pires a,, K. Nilsson b
a
Mechanical Engineering Department, University of Coimbra, Polo II Campus, 3030-788 Coimbra, Portugal
b
Computer Science Department, Lund University, Sweden

a r t i c l e in f o a b s t r a c t

Article history: Integration of equipment in industrial robot cells is to an increasing part involved with interfacing
Received 17 February 2008 modern Ethernet technologies and low-cost mass produced devices, such as vision systems, laser
Received in revised form cameras, force–torque sensors, soft-PLCs, digital pens, pocket-PCs, etc. This scenario enables integrators
18 July 2008
to offer powerful and smarter solutions, more adapted to small and medium enterprises (SMEs), capable
Accepted 16 September 2008
of integrating process knowledge and interface better with humans. Nevertheless, programming all
these devices efficiently requires too much specific knowledge about the devices, their hardware
Keywords: architectures and specific programming languages, details about system communication low-level
Industrial robotic cell programming protocols, and other tricky details at the system level. To address these issues, this paper describes and
Service-oriented architectures
analyses two of the most interesting service-oriented architectures (SOA) available, which exhibit
Robotic systems adapted to SMEs
characteristics that are well adapted to industrial robotics cells. To compare, discuss and evaluate their
programming features and applicability a test bed was specially designed, and the two SOA are fully
implemented to program the test bed. Special focus is given to the way services are specified and to the
orchestration tools used to manage system logic. The obtained results show clearly that using
integrations schemes based on SOA reduces system integration time and are more adapted to industrial
robotic cell system integrators.
& 2008 Elsevier Ltd. All rights reserved.

1. Introduction The flexibility obtained today was basically achieved through

specialization within known major application areas, which today
The use of industrial robots in typical manufacturing systems are supported by highly dedicated languages and environments to
requires integration of several devices in the task of interfacing handle the devices functionality and the system integration. Since
with other systems and human operators. The challenge is to system programmers are not necessarily general programming
respond to increasing demands in terms of flexibility and agility, language experts, programming a manufacturing cell is therefore
like it is common in small and medium enterprises (SMEs) that a task for a skilled engineering team, as done in large enterprises.
manufacture short batches of several types of products without For SMEs, there are several ad-hoc ways to approach the
stocks. Within system integration for such production, experi- problem. Nevertheless the trend is to have a client–server
ences and developments have resulted in a strong desire to software environment that not only enables system architects to
improve efficiency and flexibility by combining the following distribute functionality, but also to coordinate actions from a
three approaches: integrating several types of input–output central client commanding application. This assumes availability
devices like vision systems, user interface devices, force–torque of a remote procedure calling mechanism, or several, and a
sensors, etc.; developing human–machine interface solutions that method of packaging functionality hiding from the user the
can take more advantage from the human operators although complexity inherent to the process of communicating and
hiding from them the tricky details about how to have things handling information. Supporting a human (‘‘natural’’) way of
done; developing programming facilities to allow system inte- commanding a task goes beyond simple sequencing of commands,
grators to focus on system functionality avoiding the specific so we are not talking about software components that simply hold
languages, device-dependent hardware and software details, a collection of methods and data structures. Instead, software
communication specific information, etc. blocks need to handle complex tasks that are parameterized in
terms of the production at hand.
With the advent of internet, service-oriented architectures
 Corresponding author. Tel.: +351 239 790700; fax: +351 239 790701. (SOA) emerged to increase the degree of decoupling between
E-mail address: [email protected] (J.N. Pires). software elements. A SOA relies on highly autonomous but

0736-5845/$ - see front matter & 2008 Elsevier Ltd. All rights reserved.
doi:10.1016/j.rcim.2008.09.001
 ARTICLE IN PRESS

G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755 747

interoperable systems. The definition of a service is ruled by the real-time extensions appear to be possible, but are outside the
larger context; this means that all technological details are scope of this paper.
hidden, but also that, the concept that supports the service is
more business (or process) related and less technological related. 2.2. Safety and predictability
SOA gave software engineers time to think more on the business
logic and less on the interconnection details. At the device level Safety is getting increasingly important for robotic work-cells,
service-oriented architectures are emerging as the way to deal with the intense utilization of safety sensors and the trend of
with the increasing amount of embedded devices present in our removing the fences around the machines. This might look like a
homes and offices. contradiction to the use of PC-based software for cell control, but
In manufacturing, the required (but to be hidden for the user) two facts simplify the scenario: safety sensors and controllers are
complexity together with the presence of many high-performance configured separately, based on special hardware and certification
processing devices makes the concept of service-oriented archi- procedures; safe robot work-cells are not mission critical (as an
tectures particularly suitable to use. In fact, it leads to the idea airplane control system). Therefore, occasional failure can be
that each programming block (i.e., not only physical devices) acceptable if it can be detected and handled (by stopping or
should be considered as a potential device (SOA device style) that performing another task). Thereby, we can simplify the (hopefully
offers programming or setup services. Those programming fast) development of flexible manufacturing systems, avoiding
services should also be advertised, like with a normal device, some of the issues of X-by-wire and similar systems for vehicle
inside the SOA environment, and any device offering execution technologies [4].
services should signalize availability to the programming module
that activates and uses its functionality. All the activated 2.3. Architecture
programming modules could then be used to constitute a working
program. Existing programs, from user databases or from actually
The SIRENA project (Service Infrastructure for Real-time
connected robots/devices, will be ready for execution if all the
Embedded Networked Applications) [5] pointed out the advan-
contained programming modules are activated. It can still be
tages of using SOA in industrial automation (Table 1). Both Ahn
acceptable to have an activated program that can lead to a
et al. [6] and Nielsen et al. [7] proposed using a SOA for the device
blocking situation. In that case the user should provide the
level as robot middleware of an industrial mobile platform.
required event handling. These programming modules/services as
Industrial applicability also calls for support of dumb (wired IO
can be seen has the main foundations of a high level programming
for example) and legacy devices. This subject was addressed with
(HLP) framework for industrial robots.
success by James et al. [8,9] using specially designed gateway
In the following, to confront the general SOA idea with actual
devices, and is now featured by the Microsoft Robotics Studio
manufacturing needs, two of the most promising SOA platforms
(MSRS) [10].
are analyzed and experimentally evaluated. Special attention is
There are many SOA proposed for the device level and fairly
given to the definition of services and to the development/analysis
nice revisions have been written that resume their basic features
of high-level orchestration programs. The focus in this last point
[11,12]. For the actual implementation, a SOA is in practice based
is justified by the need to cope with the ease of use of the
on a middleware platform, which can be considered a lower level
programming languages/environments of the cell subsystems.
architecture. Such platform should include suitable mechanisms
By evaluating different architecture styles and analyzing the
to support the SOA main characteristics for the device level:
applicability of the resulting systems, the aim is to contribute to
addressing, discovery, description, control and event handling
the development of future plug-and-produce solutions for SME
(eventing).
manufacturing.

3. Approach
2. Preliminaries
In this work four of the most relevant and available approaches
Since industrial cell components are getting more and more
of SOA are considered: Jini [13], universal plug-n-play (UPnP) [14],
autonomous the automation technology should integrate modern
decentralized service structure protocol (DSSP) [7] and device
networking architectures with event-driven and publish–
profile for web services (DPWS) [15].
subscribe communication. In the following, a few alternatives
Jini is an architecture proposed by Sun Microsystems based on
will be analyzed and briefly discussed.
Java. Consequently, it is platform independent but language
dependent. It also carries a large memory footprint, due to the
2.1. Components and interconnectivity presence of a virtual machine and extensive libraries, making it
less appropriate for very small devices.
Considering a holonic cell structure [1,2], with holons composed UPnP and DPWS rely extensively on standard network
by automation devices, like an industrial robot or a vision system, protocols such as transport communication protocol (TCP/IP),
one can classify as uncommon the need to have real-time in the
communication framework. Although in some special but im- Table 1
portant cases, such as visual servoing and conveyor tracking Effects on the use of service oriented architectures in automation [1]
involving feedback loops via several interconnected devices,
systems need to be able to accomplish shop–floor deterministic Today Near future

traffic, it can be claimed that those cases constitute a smaller part

System Centralised, large, intelligent Decentralised intelligent and
of the integration problem. The majority of the component controllers, dumb devices autonomous devices
connections can instead be described in terms of coarse-grained Communications Polling client–server point-to- Event-driven,
services, with synchronous calls for setup and asynchronous point publish–subscribe, peer-to-peer
Setup Long and difficult, manual No programming, plug and play,
events for operation. Additionally, there are techniques for real-
programming tedious context-aware configuration
time communication that operate along the same principles, using debugging
user datagram protocol (UDP) for the real-time events [3]. Hence,
 ARTICLE IN PRESS

748 G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755

UDP, hypertext transfer protocol (HTTP), simple object access Discovery takes place once devices are attached to the network
protocol (SOAP), extendable markup language (XML) and web and are properly addressed. Devices advertise its services to
technology. This makes them platform and language independent, control points and control points search for devices in the
which is a major advantage for their adoption. XML formats are network.
broadly used and accepted and provide modern data interchange The description step allows a control point to obtain the
mechanisms and communications. Their style is close to the one necessary information about a device. This is done using the URL
defined in the business world with generic the pair composed by provided by the device in the discovery message. At this stage, the
webservices description language (WSDL) and SOAP. control point has the necessary information about the actions and
Although similar in many aspects, the UPnP and DPWS state variables provided by a device. The control step consists on
architectures use different languages for device description and calls of actions present in a device made by a control point.
different protocols for discovery and event notification. A proposal When the state of a service (modeled in their state variables)
has been made to the UPnP foundation [15] for a convergence changes, the service publishes updates by sending messages over
between the two approaches in the next major UPnP review. the network. This is called Eventing. These messages are also
Nevertheless, the new Microsoft operating system, Microsoft expressed in XML and formatted using the general event
Vista, supports both technologies under the name plug-and-play notification architecture (GENA).
extensions for Windows [16]. Some devices may have presentation web pages. In this case a
DSSP is a simple SOAP-based protocol that defines a light- control point can retrieve a page from the specified URL, load the
weight, representational state transfer (REST)-style service model page into the browser and depending on the capabilities of the
[7] that also relies extensively on web technology. Paired with page allow a user to control the device and/or view the device
concurrency and coordination runtime (CCR) it constitutes the status.
major parts of the MSRS platform.

3.1.2. DSSP
3.1. Selection of platform The application model defined by DSSP results from the REST
model by exposing services through their state and a uniform set
From the above discussion it is clear that UPnP and DSSP of operations over that state.
should be implemented and evaluated. UPnP and DPWS are very DSSP services are fine-grained entities that can be created,
similar technologies, which mean that concepts and design styles manipulated and destroyed repeatedly with DSSP operations, and
can be easily ported between each other. On the other hand, for their orchestration forms a DSSP application. A DSSP service
the UPnP case there are more development tools available and consists of:
the past work with UPnP industrial test bed [17] is a valuable
head-start.  Identity—global unique reference of the service.
Even considering that all these architectures are service-  Behaviour—definition of the service functionality.
oriented, substantial differences between them may exist. This  Service state—current state of the service.
is the case of DSSP in comparison with the UPnP/DPWS pair  Service context—relationships the service has to other
referred above. The first is a RESTful architecture which means services.
that it relies on a limited amount of verbs (limited number of
actions) and unlimited number of nouns. The second follows the
XML–remote procedure calls (RPC) SOAP general guideline and The state of a service is a representation of the service at any
resembles many of the WS-* technology guidelines. Hence, the given point in time. Representing a motor can may consist of rpm,
DSSP and UPnP architectural styles are quite different. temperature and fuel consumption. The behaviour of a service
(the contract) is the combination of the content model describing
the state and the message exchanges that a service defines for
3.1.1. UPnP communicating with other services. The behaviour of a service is
The basic elements of an UPnP network are: devices, services identified by a globally unique URI known as the contract
and control points. A device is a container of services and other identifier.
devices. A service is a unit of functionality, that exposes actions DSSP provides a uniform model for creating, deleting, manip-
and has a state defined by a group of state variables. A control ulating, subscribing and orchestrating services independent of the
point is a service requester. It can call for an action or subscribe an semantics of those services. DSSP defines a set of state-oriented
evented variable (variable with events associated) (Table 2). message operations that provide support for structured data
Addressing occurs when a device or a control point obtains a retrieval, manipulation and event notification. DSSP operations
valid IP address. Normally the dynamic host configuration are an extension of the HTTP application model, which provides
protocol (DHCP) is used; otherwise the device or control point support for structured data manipulation, event notification and
uses de auto-IP mechanism. partner management.
An application is a composition of loosely coupled services that
Table 2
through orchestration can be harnessed to achieve a desired task.
Basic steps that compose UPnP networking DSSP achieves this by separating state from behaviour,
allowing services to expose their state and hide their behaviour.
Steps Today The behaviour of the services is described by contracts (that have
a specific URI), and determines how it can compose with other
Addressing Control point and device get an address
Discovery Control point finds device of interest services. Such composition is called partnering.
Description Control point obtains service descriptions from devices To overcome some limitations of the traditional web-based
Control Control point invokes actions on devices architecture (REST) when applied to the device level, the HTTP/1.1
Eventing Services announce changes in their state
application model was extended with structured data manipula-
Presentation Control point monitor and control device status using a
HTML user interface
tion, event notification and partner management between
services.
 ARTICLE IN PRESS

G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755 749

4. Experiments develop an extra software layer to integrate these devices,

advertising in this way the discovered devices and services over
Given the selected architectures/platforms the following the UPnP network.
objectives are persued in the rest of this paper: The RobotIRC5 UPnP device was implemented in a software
application that communicates with the robot controller via a
1. Validate SOA as a general solution for programming industrial TCP/IP-based network. The robot controller runs a server applica-
robotic cells. tion developed in RAPID [19] as an independent task, similar to
2. Test concepts that support the service definition. the one presented in [22]. This UPnP device provides one service:
3. Develop general software to program industrial robotic cells. PickAndPlaceService (Fig. 3). This service has two different actions:
4. Evaluate different SOA styles for industrial robotic cell one that allows picking all identified pieces, and another that
programming. picks a single piece properly parameterized. It also includes an
5. Test strategies for the automatic generation of UPnP devices. evented state variable (busy) that indicates the state of the robot,
and publishes an event each time the robot finishes picking. This
device uses the Intel C# UPnP stack.
4.1. Test-bed description The Conveyor UPnP device was also implemented as a software
application that communicates with the conveyor commanding
The robotic cell used in this demonstration is composed of an PLC through a serial port [23]. Two services are also available
ABB IRB 140 robot, equipped with the latest IRC5 controller, a (Fig. 4): the HighLevel Prog service provides actions and variables
conveyor controlled by a programmable logic controller (PLC) with process related meanings; the Maintenance_Setup service is
(Siemens S7-200) and a universal serial bus (USB) web camera. more technology related, and is intended to be used during
Basically, the conveyor transports sample pieces over the development or maintenance stages. This strategy of dividing
machine vision system (Fig. 1), which calculates the number pieces process related and technology related services enhance the
and the correspondent position. The results are sent to the robot advantages of the SOA in the HighLevelProg service, without
controller for the pick-and-place operation. A detailed description of compromising some technology know-how needed for finding IO
this setup is available in [22], where an alternative solution based problems in the installation stage, for example. This device uses
on a general TCP/IP client–server application was used. also the Intel C# UPnP stack.
Since only the robot controller has built-in support for The SmartCamera UPnP device (Fig. 5) was implemented using a
sockets communications, earlier work [22] used several personal commercial USB web camera, and special purpose vision software
computer (PC)-based applications to distribute services over the developed using C++ and the Intel OpenCV vision libraries [20].
network. Two different clients were developed to operate the cell: The application determines the number and position of the
a PC-based graphical human–machine interface (GHMI) and a pieces on the conveyor, and provides an UPnP action (getPos())
personal digital assistant (PDA) interface. There was also a speech that returns these positions in a string format.
recognition interface. Speech recognition systems (SRS) evolved significantly in the
last couple of years. Actual SRS can even be used in industrial
environment (see [21]). This type of technology can be seamlessly
4.2. UPnP
integrated in a SOA due to the fact that they are extensively event
driven. To achieve this integration a software application was
The architecture proposed in this paper replaces the client–
developed to allow the automatic pairing of voice recognition
server architecture with a SOA and provides some tools to support
events with UPnP events (Fig. 6).
the creation of the software components necessary for the SOA.
The SRS selected to use with this research was the Microsoft
Consequently, five software applications were developed as
speech engine included with the Microsoft speech Application
described in Fig. 2.
Protocol Interface MSAPI 5.1 [18]. This system includes an automatic
These applications correspond to five UPnP devices of the
speech recognition (ASR) engine and a text-to-speech (TTS) engine.
network.
To create an UPnP device that can publish events correspond-
Since both the industrial components of the system (PLC and
ing to ASR events an application was developed (using C#, Fig. 6)
robot) do not have native UPnP support, it was necessary to
that implements the following strategy:

 First, the XML grammar was parsed and an XML–document

object model (DOM) tree document created.
 Then this tree was traversed and UPnP state variables were
dynamically created and added to the RecognitionService of the
voice interface device. All combinations implemented with
grammar tags /LS/S (List) are listed, and a Boolean state
variable is created for each one of them. The name of the state
variable is the recognized sentence without spaces. Nevertheless,
if this traversal method goes through each rule reference, a very
high number of variables would be created. To avoid these
difficulties and to express the real mean of the recognized
number, an integer state variable was associated with each of the
recognitions that may contain a number. It is important to notice
that the UPnP events are fired every time a new value is assigned
to the state variable, even if the value is the same.

Grammars are used to define what the ASR should recognize.

Fig. 1. Experimental setup at the laboratory. Each time a sequence defined in the grammar is recognized an
 ARTICLE IN PRESS

750 G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755

Fig. 2. UPnP devices and designed interconnections.

Fig. 3. UPnP device developed for the industrial robot.

Fig. 5. UPnP device developed for the smart camera.

to call other rules. In the example presented in Fig. 2, a rule

(‘‘NUMBER’’) was created to support the recognition of numbers
(0–99). This rule is composed by several secondary rules (UNIT,
SETSOFTEN,y) that have properties associated.
These properties allow the easy recovery of a value when a
number is recognized, because they are sent as an argument of the
delegate call when a recognition event occurs (Fig. 7).
This application provides a very interesting approach to link
the meaning of both dictated numbers and UPnP state variables.
Fig. 4. UPnP device developed for the conveyor. This approach could be extended to terms like Conveyor and
Robot, which could be associated with the respective devices, or
even linked to ontology on robotics.
event is fired by the SRS. The Microsoft SAPI allows three different The Cell Programmer Interface (Fig. 8) is a software application
ways for specifying grammars: included in the code (program- developed to control the flow of high level tasks in a manufactur-
matic grammars), using XML files, or using CFG files. Since XML is ing cell. Basically, it is an UPnP control point, with some tools
a well accepted standard it was used to specify speech recognition suitable to build a generic stack. This stack represents the control
grammars. flow of process related tasks. In the left side of this interface a tree
Grammars define a TopLevel Rule that includes all the shows all UPnP devices found on the network (notice the presence
necessary commands. From each of these commands it is possible of a ‘‘stranger’’ gateway device). Clicking over them it is possible
 ARTICLE IN PRESS

G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755 751

Fig. 6. Voice recognition interface.

Fig. 7. Recognition handling delegate: retrieving semantic properties.

to get additional information (access the presentation page, for The simple case depicted in Fig. 8 is a pick-and-place case.
example). Using the ‘‘arrow’’ button, actions or events are added The setup should wait for a speech recognition event that
to the stack. Furthermore, when running the resulting program commands the conveyor to start. When the event occurs
and the program counter is pointing to an event, it means that the an action is called commanding the conveyor to enter the
program is ‘‘waiting’’ for that event to occur. Inversely, if the automatic mode. The next action is to obtain information about
program counter is pointing to an action, it means that it is calling the number of pieces and respective position from the camera
that action and waiting for the return. There is also the possibility server.
of defining auxiliary variables to store values that can be used as The obtained information is used to pick-and-place the pieces
arguments in later stack steps. calling the robot pick service.
 ARTICLE IN PRESS

752 G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755

Fig. 8. UPnP control point: CellProgrammer interface.

When the last piece is removed the conveyor starts auto-

matically, so in this simple example the next element of the stack
is a speech recognition event that waits for the command to stop
the conveyor.

4.3. DSSP

The implementation of DSSP was made with the objective of

allowing a precise comparison with UPnP counterpart: the MSRS
package is used. Consequently, 3 services were developed
which resemble the UPnP services: ConveyorMRSR, Abbirc5 and
SmartCam. All these services were developed using the C#
programming language from the scratch not using any of the
MSRS supplied services. This enables a more precise comparison,
since it is done using similar services (built in the same way).
Nevertheless, one exception has been allowed for the VoiceUPnP
service. The speech recognition was developed using the MSRS
provided speech recognition service and the recognition logic
programmed using the Microsoft Visual Language Programming
(MVLP) [10]. This allowed also evaluating MVPL.
MSRS services are specified by contracts. These contracts
specify which are the message ports available and which type of
messages are available. Like any RESTfull approach the DSSP
operations involves exchanging message of specific types which in
this case are: CREATE, DELETE, DROP, GET, INSERT, LOOKUP,
QUERY, REPLACE, SUBSCRIBE, SUBMIT, UPDATE and UPSERT. For
the robot the following contract is available (Fig. 9).
Comparing this service with the one presented in the UPnP
implementation, it is obvious to conclude that the UpdatePick
operation is not a real Update operation but a way to accomplish
to emulate the Pick method. On the other hand the UpdateMotor-
State is a nice substitute for the UPnP MotorOn( ) and MotorOff( )
methods.
The contract information is available via HTTP since the service
is running and the state can be retrieved via the HTTP get
operation (Fig. 10).
To improve the interaction with the services an extensible
stylesheet language transformations (XSLT) transformation was
developed. This transformation gives the html look to the
extensible markup language (XML) state and provides a user
interface to update the service state (Fig. 11).
The orchestration in the DSSP has been implemented using the
MVPL (Fig. 12). Fig. 9. Abbirc5 contract.
 ARTICLE IN PRESS

G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755 753

As already mentioned, the speech recognition logic is exposed thing is a message, and everything is driven by (or driving) state
here to promote the visibility of MVPL capabilities. This data/ changes. This is an immediate consequence of the RESTful flavor
message driven language is very powerful to orchestrate complex of the architecture. Of course that every RPC call can always be
services. As with the UPnP’s CellProgrammer application, the use replaced by a specific message and most of the times by a CRUD
of MVPL as orchestration language is motivated by the need to message (Create, Retrieve, Update and Delete) without the need of
facilitate integration of devices, rather than programming them. creating a specific message. The questions are if this model is the
best way to express what the programmer has in mind, and if the
4.4. UPnP/DSSP comparison actual procedural programming model of most of the industrial
robots will cope well with the REST style.
For example, consider the action ‘‘Pick’’ from the AbbIrc5 from
Experiments using UPnP and DSSP with the designed industrial
the UPnP setup. This method represents the operation of picking
test bed provided valuable information that can be used to select
pieces and has as arguments the position of the pieces and the
the most adequate SOA style for industrial robotic cell program-
number of pieces to pick. This operation does not fit in any of the
ming. The proposed comparison considers two main topics:
DSSP message operations and the update-message used seems an
architecture style and actual platform.
unnecessary workaround.
An important issue to consider regarding the industrial
4.4.1. Architecture style comparison automation integration is the way services will be specified. Most
The architecture styles are radically different between DSSP industrial robots still define their tasks using a procedural
and UPnP. This is particularly visible in MSRS since there are no language (object oriented in some cases). These languages seem
RPC-like methods in Microsoft’s DSSP. In this architecture every- very adequate to specify services to the network, using one
approach similar to the one used with Web Services (SOAP/WSDL)
and languages like Microsoft Visual C# or Microsoft Visual Basic.

4.4.2. UPnP/DSSP platforms comparison

The following discussion is based on the experienced gained
with implementing both architectures with the presented test
Fig. 10. Abbirc5 state. bed. The idea here is to point out the main differences and
highlight the interesting features of each technology.

4.4.2.1. Language/platform independence. In terms of language/

platform independence UPnP takes the lead. Built over common
standards there are toolkits available for every major platform
(Windows, Linux) and languages (C#, Java, C++). Moreover, the
MSRS relies exclusively on the .NET platform.

4.4.2.2. Concurrency support. Even if we consider coarse-grained

services as stated before, the availability of powerful tools (library,
SDK, etc.) to help the deployment of concurrent programs is very
Fig. 11. Abbirc5 XSLT/HTML interface. important. Considering for example the UPnP experiment, it is

Fig. 12. Orchestration using MSRS.

 ARTICLE IN PRESS

754 G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755

considered very useful to have support for concurrent stack pro- useful to industrial cell programming. On the other hand UPnP
grams in the CellProgrammer application. This could be provided does not have similar tools available.
just by adding graphical support to some concurrent features
(semaphores p.e.) from an existing library (Lund Java-based real-
time library would be a suitable example [24]). DSSP and CCR 5. Conclusions
constitute the core of the MSRS Runtime. Both technologies are
tied up which means that DSS has an extensive and modern The main objective of this paper was to review some of the
concurrency support. recently proposed SOA technologies, and confront the most
promising approaches with experimental setups reflecting real
4.4.2.3. High level orchestration programs. MSRS default package applications, i.e., using the selected SOA to control a real
includes the MVPL, which is a very interesting solution for manufacturing cell and evaluating the results. Furthermore, some
the orchestration of services. In fact, this environment can be used novel concepts were introduced, like automatic UPnP generation
to perform the same function of the CellProgrammer used in from a speech XML grammar specification. This will be further
the UPnP setup, with several advantages, namely related to the developed in the near future. A test bed was designed to
coordination of features using a graphical interface. implement two of the most promising SOA technologies: UPnP
and DSSP, the SOA present in MSRS. The idea was to make a
4.4.2.4. Discovery. The UPnP discovery is processed on a peer-to- comprehensive comparison of both technologies and in the
peer basis. Every control point has the ability to discover devices. process discuss the utilization of SOA for system integration and
In the Microsoft Runtime, services can discover each other HLP of robotic manufacturing cells. These architectures represent
through a simple discovery service that acts as a rendezvous point in the device level two major architectural styles originating from
between services running on a runtime and between runtimes. the office/enterprise software world which means that advantages
This can be a problem since a failure with discovery service may and disadvantages pointed in this work can be of major
stop the discovery mechanism. importance for the definition of future domain-specific (industrial
robotics) SOA platforms.
4.4.2.5. Security. Although many industrial networks are divided Focusing on industrial automation and specifically on indus-
from the outside office network, it is always good to have security trial robotics cell programming, SOA can support automation
mechanisms in the SOA platform. UPnP does define a security engineers to focus on their expertise (machine vision, force
mechanism [14] but it is not mandatory and add arrived far control, etc.), allowing them to keep their favorite platform/
later than the first specification, which led to many proprietary language, to rely on the standard technologies, and to reduce their
security protocols, and to the absence of security in many pro- attention on the interconnection tricky tasks.
gramming stacks. The DSS runtime has a set of infrastructure Programming industrial robotic cells using SOA as framework
services to deal with security issues. This solution is better than and friendly graphical interfaces for specification of system logic
that presented in UPnP since once you have the runtime you have has proven to be less time consuming than traditional object
standard security. oriented techniques applied against similar setup [22,25].
Planned developments include the implementation of built-in
4.4.2.6. HLP support. One of the things that a SOA should be solutions for the most important cell components like robots,
cameras, PLCs, intelligent sensors, etc. This approach enables also
is a suitable platform for the development of HLP features. One
of the keys for HLP is environment sensibility (please see to extend the plug-and-play concept, based on SOA, to plug-and-
produce just by adding to the devices a set of services that
Section 4.4.2.8), which is easily reached with a ‘‘hot plug-
and-play’’ discovery as we found in UPnP. In this scenario UPnP correspond to particular cell functionalities. The manufacturing
system must then be prepared to use the new services, with the
discovery (peer-to-peer) takes advantage. On the other hand, the
mechanism that allows the composition of services provided by necessary adaptations done automatically, to start or keep
producing.
DSSP (called ‘‘partnering’’) seems a very powerful way of defining
dependencies between services. Considering the HLP perspective The comparison effort also showed that both technologies have
interesting features that suit well the industrial environment and
these dependencies require a service to run in an HLP perspective
that represent devices and services representing programming the request for HLP approaches. This means that a merging effort
is worthwhile, namely focusing on the good discovering features
modules.
of UPnP and the advantages of the graphical orchestration
interface of the MSRS. One way to this end could be the adoption
4.4.2.7. Maintenance services. Major advantages were pointed to of graphical state–machine definition schemes (like State Chart
the existence of maintenance services in the UPnP discussion. XML) for the orchestration of services [26].

4.4.2.8. Services available. Community dynamics momentum. Both References

technologies under test were not specifically designed to use with
cell integration. UPnP is more suitable for home automation [1] Gou L., Luh P., Kyoyax Y., Holonic manufacturing scheduling: architecture,
(specially the media rendering profiles) and DSSP from MSRS cooperation mechanism, and implementation, IEEE/ASME international
seems more suitable for fine-grained services (typically found conference on advanced intelligent mechatronics ’97, vol. 37, 1998. p. 213–31.
[2] El-Kebbe Salaheddine DA. Towards a manufacturing system under hard
inside a mobile robot: for example, controlling a motor with
real-time constraints. In Informatik 2000: 30. Jahrestagung der gesellschaft-
events from sensors), which means that it is not easy to reuse fu̇r Informatik, Berlin, September 2000.
services. [3] XML-basiertes kommunikationsprotokoll für Industrieroboter und prozessor-
MSRS intends to be an end-to-end solution for robotics and gestützte peripheriegeräte, Stand 17.10.2005. Information sheet download-
able from /http://www.vdma.org/xirpS.
there is an enormous dynamics in developing new services with [4] AUTOSAR. Werner Zimmermann/Ralf Schmidgall, ‘‘Bussysteme in der fahr-
very interesting features. Services like speech recognition, or hand zeugtechnik-protokolle und standards (in German, Eng title: Bus systems in
gesture recognition are shipped with the main installation of the vehicles—protocols and standards), Vieweg, ISBN 978-3-8348-0235-4, Specs
at /http://www.autosar.org/find02_ns6.phpS.
runtime. These tools facilitate enormously the deployment of [5] SIRENA Project. Service infrastructure for real-time networked applications,
applications based on building blocks and many of them are Eureka Initiative ITEA. /www.sirena-itea.org.sadasdS, 2005.
 ARTICLE IN PRESS

G. Veiga et al. / Robotics and Computer-Integrated Manufacturing 25 (2009) 746–755 755

[6] Ahn SC, Kim JH, Lim K, Ko H, Kwon Y, Kim H. UPnP approach for robot [16] PnP-X: plug and play extensions for windows specification. Available at:
middleware P. In: Proceedings of the 2005 IEEE international conference on /www.microsoft.com/whdc/Rally/pnpx-spec.mspxS, 2006.
robotics and automation, Barcelona, Spain, April 2005. [17] Veiga G, Pires JN, Nilsson K. On the use of SOA platforms for industrial robotic
[7] Nielsen H, Chrysanthakopoulos G. Decentralized software services proto- cells. Intelligent manufacturing systems proceedings IMS2007, Spain, 2007.
col—DSSP/1.0, July 2007. [18] Microsoft, speech application programming interface (API) and SDK, version
[8] James F, Smit H. Service oriented paradigms for industrial automation. IEEE 5.1, microsoft corporation, /http://www.microsoft.com/speechS, 2007.
Trans Ind Inf 2005;1(1). [19] Abb: ABB IRC5 documentation, ABB flexible automation, Merrit, 2005.
[9] James F, Smit H. Service oriented device communications using the devices [20] OpenCV. Available at: /http://sourceforge.net/projects/opencvlibrary/S, 2007.
profile for web services. ACM Int Conf Proc Ser 2005;115(1). [21] Pires JN. Experiments on commanding an industrial robot using human voice.
[10] Robotics Studio, Microsoft Robotics Studio /msdn.microsoft.com/robotics/ Ind Rob: Int J 2005;32(6) [Emerald].
2007S. [22] Pires JN, Godinho T, Araújo R. Controlo e Monitorizac- ão de Células
[11] Rekesh J. UPnP, Jini and Salutation—a look at some popular coordination Robotizadas Industriais: Revista Robótica. Abril. 2006.
frameworks for future networked devices, California Software Labs, 1999. [23] Siemens PLC S7-200 System Manual, 2000.
[12] Bettstetter C, Christoph R. A comparison of service discovery protocols and [24] Robertz SG, Henriksson R, Nilsson K, Blomdell A, Tarasov I. Using real-time
implementation of the service location protocol. In: Proceedings of EUNICE Java for industrial robot control. In: Proceedings of the fifth international
open European summer school, Twente, Netherlands, September 13–15, workshop on Java technologies for real-time and embedded systems. Vienna,
2000. Austria, September 26–28, 2007.
[13] Jini. The community resource for Jini technology: /http://www.jini.orgS, [25] Pires JN. Industrial robots programming building applications for the
2007. factories of the future. Berlin: Springer; 2007.
[14] UPnP forum, available at /http://www.upnp.orgS, 2006. [26] Veiga G, Pires JN. Plug-and-produce technologies: on the use of statecharts
[15] Schlimmer J, Chan S, Kaler C, Kuehnel T, Regnier R, Roe B, et al. Devices profile for the orchestration of service oriented industrial robotic cells. ICINCO 2008,
for web services: a proposal for UPnP 2.0 device architecture. Available at: International Conference on Informatics in Control, Automation & Robotics.
/http://xml.coverpages.org/ni2004-05-04-a.htmlS, 2004. Madeira, Portugal, 11–15 May 2008.