01411764

62 IEEE TRANSACTIONS ON INDUSTRIAL INFORMATICS, VOL. 1, NO. 1, FEBRUARY 2005

Service-Oriented Paradigms in Industrial AutomationFranois Jammes and Harm Smit

AbstractThis paper outlines opportunities and challenges inthe development of next-generation embedded devices, applica-tions, and services, resulting from their increasing intelligenceitplots envisioned future directions for intelligent device networkingbased on service-oriented high-level protocols, in particularas regards the industrial automation sectorand outlines theapproach adopted by the Service Infrastructure for Real-TimeEmbedded Networked Applications project, as well as the businessadvantages this approach is expected to provide.

Index TermsHolonic architectures, industrial automation, ser-vice-oriented architectures (SOA), Web Services.

I. OVERVIEW

AFTER a description of the challenges faced by the man-ufacturing community and of the opportunities resultingfrom increasing miniaturization and usage of standard commu-nication protocols (Section II), an overview is given of how theintroduction of service-oriented paradigmsin particular whenimplemented using Web Servicesmay help to address thesechallenges and to promote these opportunities (Section III).Section IV then outlines the service-oriented communica-tion framework proposed by the Service Infrastructure forReal-Time Embedded Networked Applications (SIRENA)project for networking of industrial devices, and discusses theanticipated benefits of this approach.

As the implementation of the SIRENA framework is ongoing,no information on its experimental usage can be reported as yet.

II. INTRODUCTION

A. Innovation Landscape in the Manufacturing IndustryThe environment of future manufacturing enterprises will be

characterized by frequently changing market demands, time-to-market pressure, continuously emerging new technologies and,above all, global competition. Therefore, next-generation man-ufacturing strategies must support global competitiveness, in-novation, and introduction of new products, and strong marketresponsiveness. As a result, if cost and quality remain vital con-cerns, manufacturing systems need to become more stronglytime-driven and time-oriented. This evolution requires consider-ably more flexibility and adaptability to change than present-daymanufacturing systems can afford.

Manuscript received December 24, 2004; revised January 6, 2005. Thiswork was supported by the Service Infrastructure for Real-Time EmbeddedNetworked Applications (SIRENA) project in the framework of the EuropeanResearch and Development Program ITEA.

The authors are with the Department of Corporate Science and Technology,Schneider Electric, 38050 Grenoble Cedex 9, France (e-mail: [email protected]).

Digital Object Identifier 10.1109/TII.2005.844419

Currently, one third of the total cost of a manufacturing plantover its lifetime is spent on installation and setup. Maintenancedowntime accounts for another substantial portion of the op-erating costs. If a plant has to be adapted to new products bychanging its process flow and introducing new or replacing ob-solete or noncompetitive equipment that is provided by differentmakers, then the downtime and installation costs rise consid-erably. The inflexible communication infrastructure among themanufacturing process components and the difficulty of portingexisting application software to new configurations are the prin-cipal roadblocks.

Today, machine controls are categorized according to theirphysical functionality (programmable logic controller, motioncontrol, regulators) and are programmed separately to executesequences of commands as function primitives. Communica-tion between the individual controls is facilitated by a centralsystem in a hierarchical network. This traditional design ap-proach presents major deficiencies when used as a basis for anintelligent manufacturing control structure.

An open, flexible and agile environment with plug-and-play connectivity is desperately needed. Open platforms havebeen proposed for years in the information and communicationtechnologies (ICT) domain. This movement has prompted theequipment industry to look at open solutions for manufacturingplants. Several proposals have been put forth by a variety ofconsortia and standards bodies. However, reality today stillshows the dominance of proprietary standards that severelyimpede the progress toward flexibility and agility.

As documented in [1], the fundamental requirements to besatisfied by the manufacturing plants and control systems of thefuture include the following.

Intra-enterprise dynamic integration capabilities. Cross-enterprise cooperation. Support of heterogeneous yet interoperable hardware

and software environments. Agility through adaptability and reconfigurability. Scalability by adding resources without disrupting op-

erations. Fault tolerance and graceful recovery from failures.The issues at stake far exceed the technological challenge per

se: in todays global economy, optimizing manufacturing pro-cesses is certainly more important than in the past to maintainproductivity and competitiveness.

In the manufacturing community, multiagent and holonic sys-tems have been the subject of great attention (see e.g., [2] and[3]), but despite their promise, they have not made significantinroads in manufacturing plants in use today. In addition to thelack of widely accepted standards, one of the reasons for thissituation seems to be that their implementations only cover part

1551-3203/$20.00 2005 IEEE

JAMMES AND SMIT: SERVICE-ORIENTED PARADIGMS IN INDUSTRIAL AUTOMATION 63

of the manufacturing landscape, whilst other areas remain sub-jected to the reign of proprietary standards, methods and mecha-nisms, resulting in a rigid patchwork of technology islands withpoor scalability.

The technological orientations presented in this paper intendto contribute to the creation of the open, flexible and agile envi-ronment referred to above, by extending the scope of the holonicarchitecture approach through the application of a unique com-munications infrastructure, down from the lowest levels of themanufacturing device hierarchy up into the manufacturing en-terprises higher level business process management systems.

B. Opportunities & Challenges

Internet and web technology is on its way to underpin a per-vasively networked world in which billions of people and tril-lions of devices are going to be interconnected in various ways.As part of this evolution, Internet technology is emerging as thebasic carrier for interconnecting electronic devicesused in in-dustrial automation, automotive electronics, building controls,home automation, etc. This tendency is the result of several con-verging evolutions.

The availability of affordable, high-performance,low-power electronic components allows embeddingunprecedented horsepower into very tiny components.This technology can be leveraged to build advancedfunctionality into embedded devices, thus enablingnew distributed application paradigms based on inter-connected, self-reliant smart devices.

Owing to their low cost, both wireline and wirelesslocal area networks of the Ethernet type are becomingwidely accepted as the medium of choice for devicenetworking. This migration process is quite recent inthe industrial sector, where industrial Ethernet is grad-ually replacing traditional fieldbus networks.

On top of these networks, due to their widespreadadoption Internet protocols of the TCP/IP family arebecoming the standard vehicle for exchanging in-formation between networked devices. Again, in theindustrial sector, this adoption process is ongoing andfar from being fully accomplished.

The emergence of data interchange mechanisms basedon Extensible Markup Language (XML) data format-ting paves the way for developing high-level data in-terchange standards at the device level.

The advent of the XML-based Web Services para-digm for interconnecting heterogeneous applicationsthrough a lightweight communications infrastructureopens a perspective of universal, platform- and lan-guage-neutral connectivity.

The ubiquitous presence of internet technology allowsinvisible embedded devices and user-facing devicesas well as higher-level information systems to coexiston the same network and, hence, to communicate.

As a consequence, the device networking ecosystem is ex-pected to substantially evolve in the forthcoming years. Thisevolution will pave the way for novel, cost-effective communi-cation paradigms at the level of basic industrial devices like sen-

sors and actuators. This upcoming device networking ecosystemshall address the following requirements and challenges.

Internet and web standards shall be used pervasively. A device shall provide a universal, interoperable and

secure access interface, independently of any operatingsystem or programming language.

It shall be possible to control a device from an ordinaryICT environment.

It shall be easy to integrate a device into complex sub-systems, and to do so in a scalable manner.

Such a subsystem shall itself be exposed as a devicethat can, in turn, be integrated into more complex(sub)systems.

A device shall be readily reusable at various architec-ture levels.

It shall be possible to connect devices together withoutextensive installation procedures (plug-and-play con-nectivity).

A device shall present a high-level management in-terface in order to facilitate configuration, monitoring,fault diagnosis and maintenance.

Interactions shall be made predictable (real-time de-mands).

It is advocated here that these requirements are best addressedby adopting a service-oriented architecture at all levels of amanufacturing enterprise, including at the level of network-con-nected elementary devices like sensors and actuators. The nextsection will highlight the fundamental aspects of such a ser-vice-based approach and how to transpose it into the devicespace.

III. SERVICE-ORIENTED ARCHITECTURES FORMANUFACTURING SYSTEMS

A. Service-Oriented Architecture (SOA) in a NutshellThere are many definitions of the concept of an SOA. For the

purpose of this paper, we use the following basic definition:An SOA is a set of architectural tenets for building au-

tonomous yet interoperable systems.This definition is definitely incomplete, but it includes two

key words: autonomous and interoperable.The principal characteristics setting apart autonomous sys-

tems are that they are created independently of each other; they operate independently of their environment; they provide self-contained functionality, i.e., this

functionality would be useful even if it was not asso-ciated with any higher-level systems.

Interoperability is favored by clearly abstracting the interfacethat a service exposes to its environment, from the implementa-tion of that service.

Autonomy and interoperability are contradictory properties.One of the challenges of an SOA is, therefore, to reconcile theseopposing principles.

The service-oriented architectural principles for achievingcombined autonomy and interoperability can be summarizedas follows.


The design of a service interface follows an outside-inapproach: rather than deriving it from the details ofits implementation, the interface of the service is de-fined by focusing on how the service may fit in a largerbusiness process context. Indeed, an SOA is businessprocess centric rather than technology centrica ser-vice usually represents a business task. This propertyinduces the granularity of services: A service interfaceis mostly coarse-grained and stateless, and is basedon the exchange of documents. This is one of the as-pects differentiating service-oriented from object-ori-ented design; the latter usually involves a conversa-tion-style interaction pattern addressing individual ob-ject attributes.

In an SOA, communicating entities are loosely cou-pled, by virtue of the fact that a services functionalityis exposed at its boundary, in terms of service con-tracts (interfaces) together with schemas describingthe documents exchanged in a standardized, platform-agnostic format. Thus, the implementation of the ser-vice is totally opaque and may be modified without theservices users being affected. In contrast, the tightlycoupled, context-related, and stateful interactions typ-ical of distributed object architectures create artificialdependencies between the communicating entities, re-sulting in rigid and fragile systems.

SOA-based communications are of an asynchronousnature: When an action is invoked on a service, theresultif anyis returned to the invoking applicationentity without the latter suspending its operations. Thisis a departure from the synchronous remote procedurecall mechanisms underlying distributed object sys-tems, which have proven to be much less scalable thanasynchronous communication patterns, especially inthe presence of complex business processes wheremany operations with variable response times runconcurrently.

In addition to its interface description, a service canhave requirements, properties or capabilitiesex-pressed through policiesthat can be negotiatedat runtime. This is particularly useful for specifyingcharacteristics like quality-of-service (QoS) level,security support, performance requirements, etc. Re-quirements for such properties may vary dependingon how the service is used in a particular applicationcontext. The capability to negotiate their use at config-uration time helps preserving the services genericityand reusability.

It may be noted that the above architectural tenets are inter-related: richer content enables looser coupling, which in turnenables asynchronous communication.

By achieving combined autonomy and interoperability, SOAaddresses many of the above-mentioned requirements for themanufacturing system of the future.

Integration capability: services can be readily inte-grated with other services, either statically or dynami-cally. Furthermore, services can be readily composed

into higher-level services. Legacy technology can beencapsulated through service faades, according toa wrap-and-reuse rather than a rip-and-replaceapproach.

Owing to the abstraction between service interfaceand service implementation, services can be mate-rialized on heterogeneous software and hardwareplatforms. This opens an unprecedented perspectiveof being able to mix and match automation equipmentfrom disparate vendors in the same manufacturingenvironment.

Agility, flexibility, and adaptability to change aregreatly increased as services can be easily reconfig-ured or replaced, service deployment can be conductedincrementally and scaling can take place over time.Communicating entities can share and exchange re-sources and collaborate with each other through direct,peer-to-peer communication, i.e., without dependingon the assistance and control of some higher-levelentity. Decision-making can thus be driven down tothe source of the information acted upon. This inturn enhances responsiveness and efficiency, whileimproving configurability. A decentralized mode ofoperation further adds resilience against failures byeliminating single-point-of-failure hazards.

Development cost is reduced as reuse of services isfacilitated and application programming is done at thehighest possible level of abstraction.

As each service encapsulates its own complexity,scalability becomes a built-in feature. By the sametoken, manageability and maintainability are greatlyenhanced.

Building fault-tolerant systems using a collection ofself-reliant components is far less cumbersome than ifusing a set of tightly interrelated components.

B. SOA Using Web ServicesWeb Services technology constitutes the preferred implemen-

tation vehicle for service-oriented architectures.Web Services are services made available from a web server

for web users or other web-connected programs. the acceler-ating creation of Web Services is a major web trend: backed byall major players in the computing industry, it constitutes thenext wave of web-based computing, laying the groundwork fora service-centric communications infrastructure. Web Servicesare totally platform-agnostic and can communicate with and/orbe aggregated with other Web Services. besides the standard-ization and wide availability of the internet itself, Web Servicesare also enabled by the ubiquitous use of XML as a means ofstandardizing data formats and exchanging data.

As more fully documented in [4], the core Web Services stan-dards are the following.

WSDL (Web Services Description Language) forthe abstract description of service interfaces andtheir binding to transport protocols. Interface defini-tions are made up of messages (requests, responses,notifications).


XML Schema for the definition of the data formatsused for constructing the messages addressed to andreceived from services.

SOAP, the protocol for transporting service-re-lated messages formatted in accordance with thecorresponding WSDL definitions. The extensibilityfeatures built into SOAP make the Web Services archi-tecture highly composable, allowing the various WebService protocols to be integrated individually andincrementally, as well as to be improved and versionedin isolation, without affecting the rest of the protocolstack.

WS-Addressing is closely associated to SOAP andconcentrates all message addressing information intothe header of the SOAP message envelope, therebyallowing the message content to be carried over anytransport protocol (HTTP, SMTP, TCP, UDP, ).

WS-Policy is used to express policies associated to aWeb Service in the form of policy assertions, com-plementing the WSDL description of the service.

WS-MetadataExchange allows to dynamicallyretrieve metadata associated to a Web Service (de-scription, schema, and policy), thus providing a WebService introspection mechanism.

WS-Security is an optional set of mechanisms forensuring end-to-end message integrity, confidentialityand authentication. Depending on the particular secu-rity requirements of a given application context, it maybe complemented by WS-SecurityPolicy (policy as-sertions expressing security requirements), WS-Trust(management of security tokens), WS-SecureCon-versation (management of a security context betweencommunicating entities using shared secrets), as wellas by Transport Layer Security (TLS) in case there areno intermediaries between communicating endpoints.

C. SOA at the Device Level

The above-mentioned evolution of the device networkingecosystem paves the way for extending the SOA paradigm intothe device space, that is, implementing a high-level communi-cations infrastructure based on Web Services protocols at thedevice level, including in the lowest-level devices.

This approach to device-level SOA has already been adoptedseveral years ago by the UPnP (Universal Plug and Play) initia-tive [5]. Like the Web Services architecture, the UPnP architec-ture leverages Internet and Web technologies including IP, TCP,UDP, HTTP, SOAP, and XML. However, since the launch ofUPnP predated the widespread adoption of Web Services, thecurrent version of UPnP is not fully compatible with Web Ser-vices technology. In particular, instead of WSDL, it uses a spe-cificbut nevertheless XML-basedlanguage for service de-scription. Furthermore, it uses specific protocols for discoveryand event notification purposes.

It can be expected that UPnP will migrate to full alignmentwith Web Services, but for reasons of market strategy relatedto the lack of backward compatibility, no date is set for thistransition.

Fig. 1. Devices profile for Web Services protocol stack.

Meanwhile, the Web Services protocol suite has been ex-tended with a profile specifically targeted at the device space:the Devices Profile for Web Services (DPWS) [6]. The DPWSspecification is intended to foreshadow the next major upgradeof UPnP. The DPWS protocol stack is shown in Fig 1.

With DPWS, all messaging, whether related to discovery,control or event notification, is based on the use of SOAP.

To the above-mentioned Web Services core protocols, DPWSadds WS-Discovery and WS-Eventing.

WS-Discovery [7] is a protocol for plug-and-play discoveryof network-connected resources. Leveraging the SOAP/UDPbinding, it defines a multicast protocol to search for and locateso-called target services. In the context of DPWS, a target ser-vice is a device. Once discovered, a device exposes the servicesit provides. The primary mode of discovery is a multicast probefor devices of a given type or scope; devices matching theprobe send a unicast response. Devices can also be localizedby name, through a similar protocol exchange. WS-Discoveryprotocol messages are sent over UDP in order to minimizenetwork traffic overhead. To reduce the need for repeatedprobing, when a device joins the network, it announces itself bysending a multicast Hello message. When leaving the networkin an orderly manner, a device announces this through a Byemessage.

Multicast-based discovery is limited to local subnets. Inorder for discovery to be scalable to enterprise-wide scenarios,WS-Discovery introduces the notion of discovery proxy (DP).

If required by the application context, WS-Discovery maywork in concert with WS-Security protocols and mechanismsto secure the communications.

WS-Eventing [8] defines a publish-subscribe event handlingprotocol allowing one Web Service (event sink) to reg-ister interest (subscribe) with another Web Service (eventsource) in receiving messages about events (notifications).A subscription is leased by an event source to an event sinkand expires over time. An event sink therefore has to renew thesubscription periodically.

Event notification messages themselves are one-way mes-sages, the content of which may include any data of any type.Filtering may be used in order to avoid sending unnecessarynotifications.


Fig. 2. SIRENA vision in a nutshell.

Depending on the application context, it may be necessarythat the communication between services be secured usingWS-Security mechanisms.

WS-Eventing is intended to enable implementation of a rangeof applications, from device-oriented to enterprise scale pub-lish-subscribe systems, on top of the same substrate.

IV. INDUSTRIAL DEVICE NETWORKING WITH SIRENAThe Service Infrastructure for Real time Embedded Net-

worked Applications (SIRENA) project [9] is an ongoingEuropean R&D project. SIRENA is part of the ITEA initiative[10], itself a cluster organization within the Eureka frame-work. The SIRENA consortium is made up of 15 partners fromthree European countries.

SIRENA is creating a service-oriented framework for spec-ifying and developing distributed applications in diverse real-time embedded computing environments, including not only in-dustrial automation, but also automotive electronics, home andbuilding automation and telecommunications systems. Thoughvery diverse, these domains have a lot in common as far as thebasic communications and control infrastructure is concerned.SIRENA will develop a set of common services to address thiscommon denominator, complemented with domain-specific ser-vices for each of the target domains.

Given the tendencies outlined above toward the adoption ofhigh-level communication functionality in intelligent devices,it has been decided to adopt the DPWS as the foundation tech-nology for the SIRENA framework.

The SIRENA vision is illustrated by Fig. 2, showing a sub-system made up of two SIRENA-enabled devices.

In the industrial automation sector, application of theSIRENA framework will enable new forms of device net-working, breaking away from traditional master-slave architec-tures. This chapter highlights some of the anticipated benefits.

A. InteroperabilityAs illustrated by Fig. 2, adoption of a high-level, universal

access interface enables connection of devices from differentvendors. This is a great stride forward with respect to the status

Fig. 3. Dose-maker device.

quo in the industrial sector: although there exist several commer-cially available solutions for industrial device networking basedon Ethernet and TCP/IPsuch as those based on EtherNet/IP[11], PROFINET [12] and Transparent Ready [13]there is nocompatibility whatsoever between these technologies at the ap-plication level. The proposed solution framework has a strongunifying power, in particular due to its neutrality with respect toimplementation technologies.

B. Scalable Service Composability and AggregationWe may illustrate this aspect through a very simple but real-

world example, the dose-maker device illustrated by Fig. 3.Its role is to fill small bottles with granules flowing from a

tank. It comprises a motor that causes the granules to leave thetank and a trap situated between the tank and the bottle to befilled; when the trap is opened, the granules can flow through.Sensors allow to determine when the trap is opened or closed,the tank is empty, the carter opened, etc. In order to fill a bottle,the dose-maker needs to open the trap, run the motor for a certainperiod of time, then close the trap.

When SIRENA-enabled, the dose-maker device may be or-ganized as in Fig. 4.

The Dose-maker is a composite device made up of the fol-lowing logical components:


Fig. 4. Dose-maker logical constituents.

a Smart Motor, exposing a service that includesan operation of the type RunMotor(duration), andthat asynchronously notifies the completion of thisoperation;

a Smart Trap, exposing a service that comprisesoperations like OpenTrap and CloseTrap, andthat sends asynchronous notifications when the trap isopened or closed, respectively;

a Dose-maker control that orchestrates the opera-tions of the Smart Trap and the Smart Motor, exposingitself a service that includes a command message of thetype MakeDose(volume), where volume can be ei-ther HALF or FULL, and that asynchronously no-tifies the completion of the dose making process.

In turn, the Smart Motor and the Smart Trap are themselvescomposite devices constructed in a similar manner, as illustratedfor the Smart Trap. The latter encompasses the actuator that ac-tually controls the physical mechanism for opening and closingthe trap, as well as the sensors that determine the traps actualstate.

This example illustrates how device-level services can becomposed and aggregated into higher-level services, much inthe way of Russian dolls. Its principle is congruous to theholonic structuring paradigm: the Smart Trap is a holon in thatit is both an autonomous entity (useable as such in devicesother than dose-makers) and a subsumed part of a higher-levelentity, viz. the Dose-maker.

The holonic structuring principle is greatly beneficial to scal-ability: hiding all the intricacies of dose-making and those ofcontrolling a trap behind the high-level service interfaces of theDose-maker and the Smart Trap, respectively, grants extensi-bility without interference with other system components. Scal-ability is further favored by the fact that event-driven communi-cations are substantially more efficient than polling-based com-municationsin terms of both bandwidth usage and processingdemands.

Fig. 5. Present-day physical implementation components.

C. Uncoupling of Logical and Physical AspectsIt is worth noting that the services exposed by the logical

entities shown in Fig. 4such as MakeDose, RunMotor andOpenTrapare, in fact, business processes at the device level,in the same way that order handling is a business process atthe enterprise or plant level. As noted before, this is a majorcharacteristic of SOA: a service is directly related to a businesstask.

Consequently, as soon as SOA can be applied at the lowestlevel of the device hierarchy, it will be possible to map eachof the logical elements in Fig. 4 to a physical implementationcomponent on a one-to-one basis. By the same token, it will bepossible to express the entire architecture of a manufacturing in-stallation in terms of business processes. Even if this is not yetfeasible todayfor reasons of cost-effectiveness and of respon-siveness in the presence of severe real-time constraintsthis isdefinitely the ultimate perspective of the SIRENA approach.

Nevertheless, the logical, service-based view of a device iscompletely independent of the devices physical realization. Itis therefore possible to realize a pure SOA down to a certainlevel of the device hierarchy and to use currently available tech-nologysuch as the devices of the Transparent Ready family([13])in order to emulate the SOA below this level. For ex-ample, the Dose-maker device may be implemented using theingredients shown in Fig. 5. Each of the logical entities shownin Fig. 4 can then be allocated to one of these physical entities.

A crucial aspect illustrated by this example is that, as tech-nological progress allows intelligence to be driven further downinto the lowest device levels, the mapping between logical andphysical implementation components can gradually evolve overtime without jeopardizing the architecture of the encompassingmanufacturing system.


Fig. 6. Dual protocol stack for industrial devices.

By virtue of this same property, it will also be possible to pro-gressively apply SIRENA technology to more and more devicessubjected to stringent real-time constraints.

D. Plug-and-Play ConnectivityUnder the SIRENA approach based on DPWS, devices are

able to automatically discover each others presence.In simple cases, devices can thus start to communicate once

connected. For example, if all logical entities in Fig. 4 are im-plemented as separate devices, the Dose-maker device becomesoperational as soon as it has recognized the presence of theSmart Motor and Smart Trap devices, which themselves havegone through a similar discovery phase.

In more complex scenarios, e.g., with multiple devices of thesame type, some initial configuration may be required.

E. Seamless Integration With Enterprise NetworksThe introduction of DPWS paves the way for the usage of

a unique technology base, viz. Web Services, across the entirespectrum of enterprise applications, down from the sensor/ac-tuator level up into the ERP/MES level. This perspective in-cludes the integration of device-level networks into agent-basedholonic systems built with Web Services.

Such strong integration power based on the ubiquitous useof Web Services technology does not preclude the usage ofother service-oriented technologies. For example, if the OSGiAlliance [14] defined a DPWS Service like it has defined aUPnP Service, OSGi could be used at intermediate levels inthe manufacturing system hierarchy.

F. Integration With Legacy TechnologyMigration from present-day architectures to an entirely

different architecture cannot happen instantly. Given the largeinstalled base of industrial device networks, coexistence ofexisting technology and newer ones must be planned forand migration paths must be devised that allow for gradualreplacement.

There are two ways to achieve such legacy integration: a gateway approach, in which existing equipment is ex-

tended with a gateway device or service allowing theexisting equipment to act as a member of the new de-vice architecture. This is akin to the application in-tegration paradigm in which legacy applications are

front-ended with a faade making them look and be-have like a Web Service;

a dual stack approach allowing existing and new pro-tocols to coexist. This is more expensive in terms ofmemory footprint, but provides a finer level of con-trol over which protocols to use for which functions.Fig. 6 outlines a dual protocol stack being implementedby Schneider Electric. This setup will allow to usea protocol like Modbus for real-time sensitive tasksthat cannot currently be handled satisfactorily by theDPWS stack, while preserving the possibility for fu-ture migration to full application of DPWS.

In practice, both approaches to legacy integration may beadopted at the same time for different application scenarios.

G. Simplified Application DevelopmentIn current industrial automation application practice, a Pro-

grammable Logic Controller (PLC) periodically scans sensors,processes their inputs, and periodically sends outputs to actua-tors. In this scheme, illustrated by Fig. 7, the sensor and actuatordevices are modeled as a collection of variables. Thus, all intel-ligence is concentrated in the PLC and a high cost is associatedto the development, testing and maintenance of the PLC pro-gram, particularly on account of all the error handling it mustincorporate.

In contrast, under the SIRENA approach (Fig. 8) the com-plexity of operating the trap device is entirely concentratedinside the Smart Trap and programming the Dose-maker isdone at the level of service invocations like OpenTrap andRunMotor and is essentially reduced to the orchestration (orchoreography) of the corresponding business processes. Thisregards both operational control and manageability aspects, asfurther discussed below.

Thus, providing the service interface of a given device typeshould be sufficient in order to:

program the application; configure a particular device of that type, and; test and debug the application.Furthermore, describing device operations through high-level

service interfaces shall considerably facilitate the creation oftools for simulating the operation of a complex manufacturingsystem or subsystem.

H. ManageabilityIn present industrial automation practice, substantial effort

is spent on diagnosing and repairing device malfunctions. TheSOA-based SIRENA device architecture holds the promise ofenabling significantly better device diagnostics capabilities thanis achievable with current architectures. Indeed, under this ap-proach the intricacies of a devices management functionalityshall be an integral part of the complexity encapsulated withinthe device, with only high-level, synthetic information beingcommunicated to the outside. Thus, in the case of a compositedevice made up of several lower-level devices, the correct func-tioning of the composite device as a whole (e.g. the Dose-maker)can be based on the management functionality provided by eachof the embedded devices (Smart Motor and Smart Trap). Such


Fig. 7. Present-day application development.

Fig. 8. Service-based application development.

health-checking or fault diagnosis functionality can be moreor less sophisticated, depending on the capabilities of the em-bedded devices, but in any case its implementation will be facili-tated by the fact of each embedded device providing a high-levelmanageability service interface.

Such manageability functionality may be supported by ageneric manageability framework and it is anticipated that theSIRENA framework will evolve in this direction. Such a genericmanageability framework should be highly extensible so as tocover the broad spectrum of device complexity to be coped


with. For higher-level devices, management functionality maygo as far as to include provisions for reliability engineering,self-reconfiguring or self-healing. Over time, the sophisticationbarrier may gradually shift as embedded processing capabilitiesevolve.

The recently published WS-Management specification [15]is expected to provide a valuable foundation for defining sucha generic manageability framework. Its basic functionality islightweight and resembles that provided by SNMP, which it isdestined to replace.

V. CONCLUSIONThe evolution of and the convergence between computing

and networking technology, fuelled by advances in semicon-ductor and transmission technology, are bound to revolutionizethe way communications are organized between systems anddevices, in particular, embedded devices. Indeed, the emer-gence of increasingly powerful, network-connected deviceswill allow to drive the intelligence of computing and commu-nications down to the device level, introducing possibilitiesfor new, higher-level communication paradigms supported byopen Internet protocol standards. Homing in on this tendencyand leveraging the widespread adoption of service-orientedarchitectures using Web Services standards, the SIRENAproject is implementing a high-level framework for communi-cation and data exchange between devices, as well as betweendevices and applications. This approach will enable noveldevice networking architectures and will allow to seamlesslyintegrate device-level networks and enterprise-level networks.It thus holds the promise of prolonging the paradigm of holonicmanufacturing systems across the entire spectrum of industrialautomation networks.

REFERENCES[1] W. Shen and D. Norrie, Agent-based systems for intelligent manufac-

turing: a state-of-the-art survey, Int. J. Knowl. Info. Syst., vol. 1, no. 2,pp. 129156, 1999.

[2] A. W. Colombo, R. Neubert, and R. Schoop, A solution to holonic con-trol systems, in Proc. IEEE-ETFA, 2001, pp. 489499.

[3] M. Ulieru and R. Unland, Enabling technologies for the creation andrestructuring process of emergent enterprise alliances, Int. J. Inform.Technol. Decision Making, vol. 3, no. 1, pp. 3360, Mar. 2004.

[4] An introduction to the Web Services architecture and its specifica-tions. [Online]. Available: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwebsrv/html/introWSA.asp

[5] The UPnP forum. [Online] Available: http://www.upnp.org[6] (2004, August) Devices profile for Web Services. [Online]. Avail-

able: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/devprof.asp.

[7] (2004, Oct.) WS-Discovery. [Online]. Available: http://ftpna2.bea.com/pub/downloads/ws-discovery.pdf

[8] (2004, August) WS-eventing. [Online]. Available: ftp://www6.software.ibm.com/software/developer/library/ws-eventing/WS-Eventing.pdf

[9] The SIRENA project. [Online] Available: http://www.sirena-itea.org[10] The ITEA initiative. [Online] Available: http://www.itea-office.org[11] EtherNet/IP. [Online] Available: http://www.ethernet-ip.org[12] PROFINET. [Online] Available: http://www.profinet.com[13] Transparent ready. [Online]. Available: http://www.transparentready

.com[14] The OSGi alliance. [Online] Available: http://www.osgi.org[15] (2004, Oct.) WS-Management. [Online]. Available: http://developers.

sun.com/techtopics/webservices/management/WS-Management.pdf

Franois Jammes received the degree in engineeringfrom Ecole Suprieure dElectricit, Paris, France,in 1976.

He is currently a Research Project Manager withthe Corporate Science and Technology Department,Schneider Electric, Grenoble Cedex 9, France. Hisresearch projects include network communicationtopics such as Ethernet, IP, protocols, and solutionsdedicated to industrial automation applications. Heis leading the European ITEA/SIRENA project.

Harm Smit received the degree from the TechnicalUniversity of Delft, Delft, Holland, in 1965.

He has extensive experience in system and soft-ware design and implementation, with emphasis onoperating systems, real-time systems, and communi-cations protocols. He is currently with the CorporateScience and Technology Department, SchneiderElectric, Grenoble Cedex 9, France, working onthe European ITEA/SIRENA project, and the appli-cation of service-oriented architectures for devicenetworking.

tocService-Oriented Paradigms in Industrial AutomationFranois Jammes and Harm SmitI. O VERVIEWII. I NTRODUCTIONA. Innovation Landscape in the Manufacturing IndustryB. Opportunities & Challenges

III. S ERVICE -O RIENTED A RCHITECTURES FOR M ANUFACTURING S YSTA. Service-Oriented Architecture (SOA) in a NutshellB. SOA Using Web ServicesC. SOA at the Device Level

Fig.1. Devices profile for Web Services protocol stack.Fig.2. SIRENA vision in a nutshell.IV. I NDUSTRIAL D EVICE N ETWORKING W ITH SIRENAA. Interoperability

Fig.3. Dose-maker device.B. Scalable Service Composability and Aggregation

Fig.4. Dose-maker logical constituents.Fig.5. Present-day physical implementation components.C. Uncoupling of Logical and Physical Aspects

Fig.6. Dual protocol stack for industrial devices.D. Plug-and-Play ConnectivityE. Seamless Integration With Enterprise NetworksF. Integration With Legacy TechnologyG. Simplified Application DevelopmentH. Manageability

Fig.7. Present-day application development.Fig.8. Service-based application development.V. C ONCLUSIONW. Shen and D. Norrie, Agent-based systems for intelligent manufA. W. Colombo, R. Neubert, and R. Schoop, A solution to holonic M. Ulieru and R. Unland, Enabling technologies for the creation

An introduction to the Web Services architecture and its specifiThe UPnP forum . [Online] Available: http://www.upnp.org(2004, August) Devices profile for Web Services . [Online] . Ava(2004, Oct.) WS-Discovery . [Online] . Available: http://ftpna2.(2004, August) WS-eventing . [Online] . Available: ftp://www6.soThe SIRENA project . [Online] Available: http://www.sirena-itea.The ITEA initiative . [Online] Available: http://www.itea-officeEtherNet/IP . [Online] Available: http://www.ethernet-ip.orgPROFINET . [Online] Available: http://www.profinet.comTransparent ready . [Online] . Available: http://www.transparentThe OSGi alliance . [Online] Available: http://www.osgi.org(2004, Oct.) WS-Management . [Online] . Available: http://develo

01411764

Documents