deliverable d6.1 service integration concept for field ... · d6.1 service integration concept for...

EUROPEAN COMMISSION

Thematic Priority:

SIXTH FRAMEWORK PROGRAM

Priority 2.5.3

INFORMATION SOCIETY TECHNOLOGIES

Unit G3 Embedded Systems

Project Acronym:

SOCRADES

Project Full Title:

Service-Oriented Cross-layer infRAstructure for

Distributed smart Embedded devices

Proposal/Contract No: EU FP6 IST-5-034116 IP SOCRADES

Deliverable D6.1

Service integration concept for field related data into

business processes

Status: Final

Dissemination Level: CO

Date: 11.04.2007

Organization Name of the Lead Contractor for this Deliverable: SAP

D6.1 Service integration concept for field related data into business processes

2/68

Status Description: Scheduled

completion date1: 28.02.2007

Actual completion

date2: 11.04.2007

Short document

description:

This deliverable focuses on the service integration concept for field related data into

business processes. The aim is to provide examples of business scenarios that benefit

from near real-time data flow, an integration architecture that can realize the coupling of

enterprise services and shop-floor devices as well as technologies/products that can be

sued to realize this goal.

Author(s)

deliverable:

Stamatis Karnouskos (SAP), Patrik Spiess

(SAP), Luciana Moreira Sa de Souza (SAP),

Oliver Baecker (SAP), Antoine Mensch

(SE), Günter Starke (APS), Radmehr

Monfared (LBORO), Mario Thron (ifak)

Report/deliverable classification:

Deliverable

Three-Monthly Activity Report

Six-Monthly Activity Report

Partner Peer rev

iews

Contrib

utio

ns

Schneider Electric

ABB

APS GmbH

Boliden AB

FlexLink Automation Oy.

Institut f. Automation und

Kommunikation e.V. Magdeburg

Kungliga Tekniska Högskolan

Loughborough University

Luleå University of Technology

Politecnico di Milano

SAP AG

Siemens AG

Tampere University of Technology

Jaguar Cars Ltd.

ARM Ltd.

Peer review approval : Approved

Rejected (improve as specified hereunder)

Date: 31.03.2007

Suggested

improvements:

1 As defined in the DoW 2 Scheduled date for approval

x

X

X X X X X


3/68

Table of Contents:

EXECUTIVE SUMMARY .............................................................................................................................................. 6

1. INTRODUCTION................................................................................................................................................... 8

1 BUSINESS SCENARIOS ....................................................................................................................................... 9

1.1 BUSINESS ACTIVITY MONITORING ................................................................................................................... 9 1.1.1 Overview ..................................................................................................................................................... 9 1.1.2 Scenario: Machine Breakdown Monitoring.............................................................................................. 11

1.2 MOBILE EQUIPMENT ASSISTANCE .................................................................................................................. 12 1.2.1 Overview ................................................................................................................................................... 12 1.2.2 Scenario: Remote Diagnosing and Plan Adaptation ................................................................................ 13

1.3 MAINTENANCE OPTIMIZATION ....................................................................................................................... 14 1.3.1 Overview ................................................................................................................................................... 14 1.3.2 Scenario: Photocopy machine maintenance ............................................................................................. 16 1.3.3 Scenario: Maintenance of automation systems......................................................................................... 17

1.4 OVERALL EQUIPMENT EFFECTIVENESS (OEE) ............................................................................................... 17 1.4.1 Overview ................................................................................................................................................... 17 1.4.2 Scenario: Well-founded buying decisions................................................................................................. 19 1.4.3 Scenario: Product line optimization ......................................................................................................... 19

1.5 CUSTOMIZED MANUFACTURING WITH LATE ORDER FREEZE ........................................................................... 20 1.5.1 Overview ................................................................................................................................................... 20 1.5.2 Scenario: Car manufacturing ................................................................................................................... 21 1.5.3 Scenario: Pre-fabricated houses............................................................................................................... 21

1.6 AUTOMOTIVE DOMAIN / REMOTE SYSTEMS ................................................................................................... 22 1.6.1 Overview ................................................................................................................................................... 22 1.6.2 Scenario: Remote Expert Assistance (REA).............................................................................................. 22 1.6.3 Scenario: Automatic Remote Expert Assistance (AREA) .......................................................................... 23

2 REQUIREMENTS ANALYSIS FOR DISTRIBUTED SMART EMBEDDED DEVICES ........................... 23

2.1 WEB SERVICE SUPPORT.................................................................................................................................. 24 2.2 SUPPORT AN EVENT DRIVEN ARCHITECTURE (EDA) ..................................................................................... 24 2.3 SERVICE LIFECYCLE MANAGEMENT............................................................................................................... 25 2.4 BUSINESS PROCESS MODELLING .................................................................................................................... 25 2.5 OCCASIONALLY CONNECTED ASSETS ............................................................................................................ 25 2.6 OCCASIONALLY DISCONNECTED ASSETS ....................................................................................................... 25 2.7 BUSINESS PROCESS MONITORING................................................................................................................... 26 2.8 ALERTING....................................................................................................................................................... 26 2.9 RISK MANAGEMENT....................................................................................................................................... 26 2.10 STANDARDISED COMMUNICATION AND INFORMATION EXCHANGE ................................................................. 26 2.11 MAINTENANCE CONTROL............................................................................................................................... 26 2.12 PREDICTIVE MAINTENANCE ........................................................................................................................... 27 2.13 ACCESS TO DEVICE STATUS ........................................................................................................................... 27

3 TECHNOLOGY.................................................................................................................................................... 27

3.1 SERVICE ORIENTED ARCHITECTURE............................................................................................................... 28 3.1.1 Service Composition ................................................................................................................................. 29 3.1.2 SCA – Service Component Architecture ................................................................................................... 30 3.1.3 BPEL - Business Process Execution Language ........................................................................................ 32 3.1.4 Scripting languages .................................................................................................................................. 33 3.1.5 Business Application Integration .............................................................................................................. 33

3.2 DEVICE LEVEL INTEGRATION TECHNOLOGIES ............................................................................................... 35 3.2.1 Web Services and the Devices Profile....................................................................................................... 35 3.2.2 WS Security ............................................................................................................................................... 37 3.2.3 WS Reliable Messaging............................................................................................................................. 38 3.2.4 WS Management ....................................................................................................................................... 38


4/68

3.2.5 OPC Unified Architecture......................................................................................................................... 39 3.3 BUSINESS LEVEL INTEGRATION TECHNOLOGIES ............................................................................................ 39

3.3.1 ERP Systems ............................................................................................................................................. 39 3.3.2 xApp Manufacturing Integration and Intelligence (xMII) ........................................................................ 40 3.3.3 NetWeaver................................................................................................................................................. 41 3.3.4 Exchange Infrastructure (XI) .................................................................................................................... 42

4 INTEGRATION CONCEPT ............................................................................................................................... 46

4.1 SERVICE INTEGRATION IN BUSINESS APPLICATIONS ...................................................................................... 49 4.2 COUPLING DEVICES WITH BUSINESS APPLICATIONS ........................................................................................ 51

4.2.1 Service Integration Pattern: Real-time data integration in enterprise system.......................................... 51 4.2.2 Service Integration Pattern: Relocated Business Process Control........................................................... 51 4.2.3 Service Integration Pattern: Distributed Business Process Execution ..................................................... 52

4.3 WEB-SERVICE ENABLED DEVICE INTEGRATION .............................................................................................. 53 4.4 NON WEB-SERVICE ENABLED DEVICE INTEGRATION ....................................................................................... 54 4.5 INTEGRATION ARCHITECTURE ........................................................................................................................ 56

4.5.1 Device Abstraction Layer ......................................................................................................................... 60 4.5.2 System Management Layer ....................................................................................................................... 61 4.5.3 Enterprise Services ................................................................................................................................... 61 4.5.4 Business and Execution System Layer ...................................................................................................... 62 4.5.5 Application Layer ..................................................................................................................................... 62

5 DEMONSTRATION FACILITY ........................................................................................................................ 62

6 CONCLUSIONS ................................................................................................................................................... 65

7 REFERENCES...................................................................................................................................................... 66

8 TERMS USED....................................................................................................................................................... 66

9 APPENDIX ........................................................................................................................................................... 68

9.1 LICENCES....................................................................................................................................................... 68


5/68

List of Figures: Figure 1: Real-time Enterprise.............................................................................................................6

Figure 2: Business Activity Monitoring.............................................................................................10

Figure 3: Industry systems integration...............................................................................................11

Figure 4: Remote Diagnosing and Plan Adaptation...........................................................................14

Figure 5: Typical predictive maintenance process flow ....................................................................15

Figure 6: Maintenance Cost vs. Risk ................................................................................................16

Figure 7: Setup of maintenance infrastructure for photocopy machines ...........................................16

Figure 8: Functions of individual parts of the system........................................................................17

Figure 9: Integrated factory floor.......................................................................................................18

Figure 10: Levels of customization in industrial production .............................................................20

Figure 11: Order process innovation using shop floor information...................................................21

Figure 12: Schematic of a remote expert assistance used for the automotive industry .....................23

Figure 13: Service composition in a hierarchy of services ................................................................30

Figure 14: Artefacts of SCA ..............................................................................................................31

Figure 15: SCA system ......................................................................................................................31

Figure 16: DPWS device architecture................................................................................................36

Figure 17: DPWS communications stack ..........................................................................................36

Figure 18: DPWS C/C++ code generation approach.........................................................................37

Figure 19: Functional blocks of xMII ................................................................................................40

Figure 20: SAP NetWeaver stack .....................................................................................................42

Figure 21: SAP XI as a hub and spoke network [10]........................................................................43

Figure 22: SAP XI components within SAP NetWeaver [11]..........................................................44

Figure 23: Integration between smart embedded devices and enterprise applications via SAP XI...45

Figure 24: The Integration Gap.........................................................................................................46

Figure 25: Architecture of a complex automation system according to ISA-95 [4].........................47

Figure 26: Scope of ISA-95 [2].........................................................................................................48

Figure 27: Integration of shop floor applications with enterprise systems using B2MML [5] ........48

Figure 28: SOCRADES Architecture (high-level overview) ............................................................50

Figure 29: real-time data integration in enterprise system.................................................................51

Figure 30: Relocated business process control .................................................................................52

Figure 31: distributed business process execution............................................................................52

Figure 32: SOCRADES service-oriented layered approach ..............................................................53

Figure 33: SOCRADES web service stack ........................................................................................54

Figure 34: Network transition via gateway solutions ........................................................................55

Figure 35: SOCRADES device adapter .............................................................................................55

Figure 36: Device Level Integration .................................................................................................57

Figure 37: Business Level Integration ..............................................................................................58

Figure 38: SOCRADES Architecture ................................................................................................60

Figure 39: Mechatronic Trial Site......................................................................................................63

Figure 40: Architecture of the SOCRADES Mechatronic Trial Site.................................................64

Figure 41: Remote access over VPN to the mechatronic trials..........................................................65

List of Tables: Table 1: Overview of BPEL4WS – Workflow Constructs [1] ..........................................................33


6/68

Executive Summary

Enterprises are moving towards service-oriented infrastructures that bring us one step closer to the vision of

real-time enterprises (Figure 1). Applications and business processes are modelled on top of and using an

institution-wide or even cross-institutional service landscape. For any solution to be easily integrated in this

environment, it must feature a service-based approach.

Currently, shop-floor intelligent systems based on distributed embedded devices concentrate the

programming of the behaviour and intelligence on a handful of large monolithic computing resources

accompanied by large numbers of dumb devices. The intelligence and behaviour are tailored and

individually programmed for each application.

However, as we are moving towards the “Internet of Things”, where millions of devices will be

interconnected, provide and consume info available on the network and cooperate, new capabilities are

opened. As these devices need to interoperate, the service-oriented approach seems a promising solution i.e.

each device offers its functionality in a service-oriented method, while in parallel it is possible for it to

discover and invoke new functionality from other services on-demand. By considering the set of intelligent

system units as a conglomerate of distributed, autonomous, intelligent, pro-active, fault-tolerant and

reusable units, which operate as a set of co-operating entities, a new dynamic infrastructure that is able to

provide a better insight to its components to the higher levels and better react to dynamic business changes

can be realised.

Figure 1: Real-time Enterprise

As depicted in Figure 1, the main aim of this document is to provide an insight how we can realise the real-

time enterprise via the strong coupling of the enterprise concepts domain and the device level service

domain. Nowadays there is a very limited cooperation among the two layers which in practice translates to

weak coupling of the Enterprise Resource Planning (ERP) with the Manufacturing Execution System (MES)

and Distributed Control System (DCS). In more detail we focus on the integration of aggregated device-level

services with higher-level Web Services and business processes situated at the level of business applications

- in particular Enterprise Resource Planning (ERP) systems - in order to demonstrate seamless integration of

device level functionality into higher-order business application scenarios in manufacturing, logistics, or

similar areas.

We consider several business domains such as Business Activity Monitoring. Mobile Equipment Assistance,

Maintenance Optimization, Overall Equipment Effectiveness (OEE), Customized manufacturing with late


7/68

order freeze, and Automotive Domain / Remote Systems. From these domains we focus on how they could

benefit from strong coupling with the device level service domain and refer to example scenarios.

Subsequently, we analyse the requirements for distributed smart embedded devices, that have to be fulfilled

in order to provide the necessary functionality required by the business layer.

There are several efforts and technologies (as depicted also in WP1) that can be (re)used to realise the

integration of business and device service layers. Here we focus on the technologies that enable us to realise

a service-oriented architecture (business layer), on technologies like web services that allow the easy

interoperation and coupling at device level, as well as on commercial products that will be used to

demonstrate this approach (e.g. ERP, xAPP, NetWeaver, XI).

A first draft integration architecture is designed that clearly shows how the several layers between the

business applications and the field devices could be interconnected. This interconnection allows business

applications to get a real-time view of the shop-floor activities, and be able to even communicate explicitly

with devices. This is done via the DPWS standard which SOCRADES will implement in all devices, allowing

them to be part of a service-oriented infrastructure. However not all devices are expected to host DPWS,

therefore the integration architecture accommodates also the integration of legacy and non-web service

enabled devices as well.

As we plan to demonstrate the integration concepts developed in SOCRADES in a real-world environment,

we depict as an example one demonstration facilities in the domain of mechatronics and robotics that will be

used.

The convergence of solutions and products towards the SOA paradigm adopted for smart embedded

devices contributes to the improvement of the reactivity and performance of industrial processes, such as

manufacturing, logistics and others. This will lead to information being available "on demand" and in

business-level applications that are able to use high-level information for various purposes, such as

diagnostics, performance indicators, traceability, etc. These future vertical integration capabilities will also

help to reduce the effort required for integration of the affected systems in the sense of the given business

scenario. The service integration concept for field related data into business processes presented in this

document, depicts our initial efforts towards realising this goal.


8/68

1. Introduction

The SOCRADES approach is to create system intelligence by a large population of small and smart

networked embedded devices at a high level of granularity, as opposed to the traditional approach of

focusing intelligence on a few large and monolithic applications. This increased granularity of intelligence

distributed among loosely coupled intelligent physical objects facilitates the adaptability and

reconfigurability of the system, allowing it to meet business demands not foreseen at the time of design.

The use of the service-oriented architecture (SOA) paradigm, implemented through Web Services

technologies, at the ad hoc device network level enables the adoption of a unifying technology for all levels

of the enterprise, from sensors and actuators to enterprise business processes. The benefits of service-

orientation are conveyed all the way to the device level, facilitating the discovery and composition of

applications by re-configuration rather than re-programming. Dynamic self-configuration of smart

embedded devices using loosely-coupled services provides significant advantages for highly dynamic and

ad hoc distributed applications, as opposed to the use of more rigid technologies such as those based on

distributed objects.

A fundamental goal is to enable the integration of device-level services with enterprise systems. This goal

will require the definition of new integration concepts taking into account the emerging requirements of

business applications and the explosion of available information from the device level. Of particular interest

is the availability of real-time event information, which will be used to specify new enterprise integration

approaches for applications such as business activity monitoring, overall equipment effectiveness

optimisation, maintenance optimisation, etc.

This document depicts our first efforts towards the integration of aggregated device-level services with

higher-level Web Services and business processes situated at the level of business applications - in particular

Enterprise Resource Planning (ERP) systems - in order to demonstrate seamless integration of device level

functionality into higher-order business application scenarios in manufacturing, logistics, or similar areas.

This deliverable is one of the first deliverables within the SOCRADES project. It focuses on the real-time

enterprise and how this can be achieved by directly coupling business processes and the shop-floor.

This document is structured as follows: First we take a look at several Business Scenarios that benefit from

the strong coupling of enterprise services and shop-floor devices. Subsequently we focus on Requirements

Analysis for Distributed Smart Embedded Devices as well as the Technology that can be used to realise this

goal. Finally we present the Integration Concept that depicts our efforts towards an integration architecture

that will be able to tackle all requirements and efficiently demonstrate the integration of both web-service

and non web-service enabled devices. Finally we refer to one Demonstration Facility that will be used to

demonstrate the results of the project.


9/68

1 Business Scenarios

The business world is highly competitive, and in order to successfully tackle everyday’s challenges

operational managers and executives demand high-dependability and wide-visibility into the status of their

business process networks. The latest is done usually via business key performance indicators (KPIs).

However in order to provide up-to-date info and be able to react in a flexible and optimal way to changing

conditions, real-time info must flow via all layers from the shop-floor up to the business process level. Here

we depict some scenarios coming from different business perspectives indicating how the integration of

devices and their bidirectional information flow in business processes can lead to a better business

infrastructure.

The domains and their indicative scenarios come from the following domains:

• Business Activity Monitoring

• Mobile Equipment Assistance

• Maintenance Optimization

• Overall Equipment Effectiveness (OEE)

• Customized manufacturing with late order freeze

• Automotive Domain / Remote Systems

1.1 Business Activity Monitoring

1.1.1 Overview

Line managers and operational decision makers need instant access to critical information. To reduce the

risks to their businesses, for example, financial institutions need real-time access to financial and other

critical information. Manufacturers and retailers also require such visibility into critical business data related

to supply chains and customers.

Business Activity Monitoring (BAM) is an SAP framework that enables users to act on significant

events/alerts and take the correct action in the right work context. It also provides tools for monitoring,

measure and improving the efficiency of business processes.


10/68

Figure 2: Business Activity Monitoring

BAM provides real time access to critical business performance indicators to improve the speed and

effectiveness of business operations. BAM draws the information from multiple application systems from

internal and external sources, therefore enabling a broader and richer view of business activities. It also

supports effective monitoring of complex processes, the real value is that it can alert the appropriate people

to relevant, significant business events and provide guidance on how best to resolve the situation at hand.

By using analytical solutions, line managers and operational decision makers can evaluate the alternatives

when making decisions. Once the plans have been made, performance management helps to monitor their

performance and benchmark it against performance metrics, highlighting exceptions and providing insight

as to why exceptions occurred. The degree of sophistication of a business activity monitoring solution comes

from its ability to process and analyze events. Its value results from its timeliness, accuracy, and alert

functionalities.

BAM is designed to be a natural extension of investments that enterprises are making on application

integration. It is easily installable and makes use of SAP infrastructure that is already present, such as XI,

SAP Business Suite, Business Intelligence (BI) and the Enterprise portal as depicted in Figure 2.

With SAP Business Suite, SAP provides the Event Infrastructure, such that when an event happens within

the Business Suite, it is propagated up to the business process via XI. XI is responsible for capturing all

messages and alerts that occur in the system. Based on the content of the messages and on milestone

monitoring an alert can be raised.

This alert is propagated through the Alert Server to the Enterprise Portal where the Event Resolution

Dashboard will guide the user in a step-by-step way so the issue can be resolved.


11/68

For process efficiency, the data that is kept as part of business process monitoring and logging capabilities, is

sent over to the BI and later on displayed on the Process Efficiency Dashboard, where the appropriate people

can analyze the information and react accordingly.

By combining BAM and xMII as suggested in Figure 2, events generated on the shop floor can also be

monitored and controlled on the Enterprise Portal with the BAM tools. With alerting and immediate access

to timely information, administrators and decision makers can manage by exception, which can increase

efficiency and effectiveness. Managing by exception allows reviewing alerts, but not intervening unless

corrective action is necessary. It enhances the effectiveness of business users by providing them with

visibility into their processes and role-specific, relevant content. Alerts can also provide guidance so that a

process can be handled when it alerts a significant event.

1.1.2 Scenario: Machine Breakdown Monitoring

In manufacturing industries, machines require regular maintenance in order to prevent breakdowns that can

lead to goods not been delivered to customers or delivered with great delay. Unfortunately not all sources of

problems can be eliminated and occasionally the production line will suffer with unexpected breakdowns.

By combining xMII, ERP systems and BAM, it is possible to detect alarm situations generated on the shop

floor in real time and react with more effectiveness.

PCSPCS

MES

Machine

Breakdown

xMIIxMII

Supplier

Planning

Sales

Planning

Sales

Customer

ERP

BAMBAM

Figure 3: Industry systems integration

Figure 3 presents a scenario where a machine breaks down on the shop floor and the request of the customer

has to be modified in real time to guarantee high performance and customer satisfaction. As soon as the

machine identifies a break down or BAM identifies an alert situation through the Milestones monitoring, an


12/68

alert is triggered. BAM displays the situation on the Event Resolution Dashboard and guides the user

through the process of solving the situation.

At first the customer is contacted to indicate the situation and a new sales order is placed. The ERP system

then sends a new production command to the shop floor and the request of the customer is then processed

with minimum delay.

1.2 Mobile Equipment Assistance

1.2.1 Overview

To stay competitive in today’s global marketplace, companies must ensure that every phase of their business

communicates with every other phase, on-site and off. This is a special challenge for mobile workforce,

which should be able to provide a high-quality service on-site and on the move. Mobile Equipment

Assistance refers to the process of using mobile devices as a mean to realise part of a business process or

even as the end-devices to be monitored. Mobile equipment assistance covers a wide range of scenarios e.g.

• The service personnel is mobile and must have access to all the information to successfully bring its

task to completion. This should be feasible regardless of the connectivity with the enterprise systems

e.g. connected / disconnected / opportunistic communication

• The devices to be monitored are mobile themselves. This means that they can provide information

about their processing depending on their context. As such a packet could provide real-time info

about its status, its content (which could by dynamic e.g. based on sensor reading) and its next

processing steps according to a business process.

• Finally a combination of both of the above would lead to scenarios where mobile workforce deals

with mobile devices in a peer-to-peer manner with or without access to the full enterprise

infrastructure.

The aim is to loosely couple the back-end systems (enterprise infrastructure) with the front-end ones

(machines and devices available to the workforce on-site), but still be able to realise the whole business

process in a flexible and dynamic way. A series of services can be realised such as remote diagnostics,

predictive maintenance, etc

Mobile Equipment Assistance provides “anywhere, anytime” access to critical business processes via mobile

devices, which now are not passive information consumers but can actively take part in the local

infrastructure and integrate devices via the DPWS interface. Therefore advanced approaches can be

considered in:

• Service Management: Streamline planning for service personnel on the move via at-a-glance

overviews of assignment times, priorities, and status. Optimizing of daily tasks, view detailed

descriptions of customer problems from any location, and notify the call centre, dispatcher, and

other relevant people of any changes – immediately. With DPWS-capability, the devices themselves

can also proactively assume some of these tasks e.g. notifying about their possible malfunction e.g.

due to heuristics or history data.

• Service Confirmation: Technicians report problem type, times, parts used, and other relevant details

back to company headquarters as they handle the problem or as soon as they complete an

assignment. This eliminates time-consuming paperwork and error-prone manual data entry.

Furthermore the enterprise service can directly connect to the end-device and get its status as well as

verify its repair/expected behavior.


13/68

• Account Management: Monitoring and tracking mission-critical information on customers,

prospects, and partners, providing detailed profiling, activity tracking, and relationship overviews is

now more fine-grained due to the active participation of the end-devices.

• Task and Activity Management: Streamline scheduling and management of activities and tasks

with a mix of back-end capabilities and on-site local infrastructure participation is possible. A

dynamic list function can list all activities or dynamically rearrange them based on the latest info

that flow in. This allows for focus on high-priority issues that can be communicated to the mobile

workforce just-in-time and since they are not static they can change to better accommodate a

dynamically changing environment. Once a task is done, automatic updating of the details of a task

and creation of new or follow-up activities is done based on information that now exists on the local

infrastructure (devices) and on back-end systems.

• Absence and Attendance Management: Service dispatchers, supervisors, and managers can plan

and assign service requests based on real-time employee availability and real-time device status.

Now service employees can be contacted directly from enterprise services or in a local-manner from

devices that need special attention directly without going via the whole backend infrastructure

communication.

• Real-time Product Catalogue Management: Field service technicians now can have easy access to a

central repository of up-to-the-minute information on product details e.g. offerings. They can list,

search, and display products from the company’s catalogue and call up customer-specific pricing

information from the customer’s premises or the service van. Furthermore now device-specific

information e.g. for the repairing of a machine can either be acquired on-demand via the backend

system, be provided by the device itself locally or a combination of them (e.g. the device points out

where the information could be retrieved from – this is critical for servicing devices whose details

are not fully available to the back-end systems).

Mobile services in the context presented are a must for modern business infrastructures and should deliver a

universal infrastructure for enterprise mobility embedded within real-time info anywhere, anytime and in

any format. Multiple devices in both, connected or disconnected modes should be supported. It also

supports multiple non-SAP infrastructures such as GSM, GPRS, Bluetooth, and wireless LAN. The business

effects are obvious, as this means a shift paradigm to an almost real-time infrastructure with real-world

awareness where both ends i.e. the backend systems as well as the end-devices are active and business

intelligence can be distributed at several layers between them for optimization. This results to:

• On-the-spot input – making valuable data (on work performed and action or materials required)

immediately available

• Automation of all service-related processes – resulting in fewer mistakes, fewer lost opportunities,

and less time and money spent on routine tasks

• Reduced costs

• Greater customer satisfaction – a by-product of your new ability to provide the right information

instantly, perform work orders faster and more accurately, and respond quickly to customers’

inquiries

• Enhanced quality – the end result of the greater accuracy and responsiveness provided by field staff

1.2.2 Scenario: Remote Diagnosing and Plan Adaptation

Transportation companies are evolving towards multi-modal service providers and provide their customers

with operational, managerial and supply-chain intelligence. The economics behind such processes are

complex, and one part of it includes the better management of the operational time of the fleet. Therefore in

case of malfunctions, problems need to be diagnosed, goods need to be rerouted and processes need to be

adjusted with the aim of meeting the best strategy.


14/68

Sensors

Driver

Imminent Failure

Warning

Remote

Diagnosis

Remote repair

Back-end

Garage

Truck status

Order

components

New route

Figure 4: Remote Diagnosing and Plan Adaptation

Figure 4 presents a typical scenario where a truck is about to break down on a highway. However, since each

component is monitored, a break-down predictive service notifies the driver of the possibility that an engine

component will be malfunctioning in the next hours. Via his mobile device (e.g. PDA) the driver is able to

see which parts of the truck are possibly affected by a possible malfunction and asses the risk for his mission.

He is able to run some diagnostics that could re-calibrate the component and can try to do some initial repair

by himself. Complete guidelines are provided to him via the mobile device while in parallel the live

communication between the PDA and the truck parts via a peer-to-peer network immediately shows him the

effects of his actions. By doing this local interaction he is able to communicate to the back-end the real-time

status of the truck. Via location based services the next repair station is identified and the repair service and

the necessary components to be exchanged are ordered. The modified route plan is sent to the truck driver,

taking now into account the modified business process that includes a repair activity. After that the driver

can go on and pursue via the guidance of his mobile device the best possible route in order to fulfill his

mission. The back-end has already notified the companies waiting for the truck delivery or has rearranged

the remaining route according to the priorities set in the system.

The strong cooperation of enterprise services running on back-end systems, the local interaction between the

mobile device and the truck’s parts and the usage of the mobile device have managed to correctly identify

the problem, minimize the repair time, re-adjust in the best possible way the original plan and therefore

reduce costs while keeping the business running.

1.3 Maintenance Optimization

1.3.1 Overview

Today, machines and other assets of a company are usually maintained on a regular basis (at regular

intervals) or in case of failure. Figure 6 depicts maintenance on a regular basis as proactive maintenance, and

maintenance on failure as reactive maintenance.


15/68

Reactive maintenance saves costs by eliminating any unnecessary maintenance. It is only done when a

system is malfunctioning. However, this mode of maintenance also incorporates the highest risk. It should

only be applied to parts of the system that are not critical for the operation of the enterprise. If applied in

critical parts, the costs of a failure of equipment can be much higher than the cost saved by avoiding

unnecessary maintenance.

The opposite approach to reactive maintenance is proactive maintenance. In this maintenance mode, the

equipment is maintained regularly, even if there are no signs of a possible breakdown. This ensures a high

availability of the system part, but also includes unnecessary maintenance cycles that introduce the cost of

the maintenance itself and may lead to additional downtime costs. As depicted in Figure 5, the real time

sensor data is analysed compared to statistical data and if any deviations are associated with known

problems the relevant parties are alerted.

Figure 5: Typical predictive maintenance process flow

With predictive maintenance, supported by field data coming from the devices themselves, attached sensor

nodes, or diagnostic systems, we expect to achieve a low level of risk (comparable to proactive maintenance)

at lower cost (only slightly higher than in reactive maintenance). A subsystem will have the task to detect

anomalies in the shop floor process and hence schedule maintenance only when the system is perceived as

likely to fail.

Depending on parameters that affect the sensitivity of the failure detection mechanism, the behaviour of

predictive maintenance can be moved either towards reactive maintenance behaviour or towards the

proactive maintenance behaviour. If the algorithm fires although already when the system behaviour is

slightly off track, the maintenance mode is similar to proactive maintenance. If it creates many false

positives, i.e. it predicts system failure when the machine is perfectly healthy, the total cost can be even

worse than for proactive maintenance – a situation that should be avoided. If it only fires when a failure is

very likely, the maintenance plan resembles reactive maintenance. A good balance has to be found, that

considers the involved risks.


16/68

Maintenance Cost

Risk

ProactiveMaintenance

ReactiveMaintenance

PredictiveMaintenance

Figure 6: Maintenance Cost vs. Risk

The maintenance process leads to additional costs due to equipment downtime. These costs can be

minimized if non-critical maintenance is included into the regular planning process (scheduling) that assigns

tasks to available assets. A necessary but non-critical maintenance task may hence be postponed to a point in

time when the equipment would be idle. Of course a mixture of approaches can be applied and the best

breed of them can be scenario specific e.g. proactive maintenance for mission critical devices, predictive for

important but not mission critical devices and finally reactive for low-importance ones etc.

1.3.2 Scenario: Photocopy machine maintenance

A manufacturer of photocopy / printing machines wants to offer his customers extended service. Since these

copiers are mostly already connected to the network, they can provide high-level usage information via web

services and announce them via DPWS. They can send maintenance events when the device detects a failure

or a part shows signs of wearing out or reaches the number of usage cycles or usage time it was designed

for. E.g., a scanning device can scan each paper after printing and compare the scanned image to the internal

representation. If the image scanned immediately after printing differs significantly from the image that

should be printed, a maintenance order could be created.

Customer’s IntranetManufacturer’sDPWS Client Manufacturer

Secure RemoteConnection

Figure 7: Setup of maintenance infrastructure for photocopy machines

That information is then collected by a gateway provided by the manufacturer of the copier and connected

to the corporate network of the customer (see Figure 7). The gateway sends the events to the manufacturer


17/68

who can automatically generate maintenance orders to check machines that have failed or are likely to fail

soon.

There are two deployment options for DPWS clients and servers in this scenario which are functionally

equivalent. Either the gateway could have a DPWS client that discovers all devices and instructs them to

report events to or the copiers could have such a client, which discovers the server.

1.3.3 Scenario: Maintenance of automation systems

Automation systems are complex installations of connected automation devices. A failure of a single device

can lead to a complete stop of the production process, the production of worthless goods, or low product

quality. The detection of such defects is not trivial and has to be part of the engineering process of the

installation. Often vendor-specific diagnostic tools are used to observe the system’s behaviour constantly.

Quality check stations are included in the process that check all goods or extract some of them for making

quality measurements. Figure 8 depicts individual parts of the system and the functions associated to them.

Business Back-end

Diagnostic System

Automation Devices

ProductionPlanning

MaintenancePlanning

FailureDetection

Quality Assurance

Figure 8: Functions of individual parts of the system

In this scenario, it is clearly out of scope of the business system to analyze any low level data coming from

field devices to detect possible faults. This task is left to custom diagnostic tools provided by the

manufacturers of the automation devices. However, the diagnostic tools should implement and offer

services, ideally using DPWS that notify the business system of possible failures. The benefit of this

approach is that the overall process can benefit from the business system’s short-term and middle term

knowledge about the production process. This allows scheduling of non-urgent maintenance to a time where

downtime does not break critical deliveries. In case of a complete machine breakdown, the business system

can immediately change the production plan, possibly using alternative or stand-by production capacity.

1.4 Overall Equipment Effectiveness (OEE)

1.4.1 Overview

Overall equipment effectiveness (OEE) is a measure that allows comparing the actual performance of a

production line or manufacturing process to the performance that would be possible under ideal

circumstances. The goal is to apply this information to improve the utilisation of assets (people, equipment,

materials) during the automation process and transform the production process towards an adaptive

manufacturing. By analyzing raw equipment usage information coming from embedded sensors,

operational inefficiencies can be identified. Examples of operational inefficiencies are rejected goods,


18/68

production delays, downtime, waste, rework, and run-time deficiencies. OEE is often used as a key

performance indicator (KPI) in Lean Manufacturing and Total Productive Maintenance (TPM). A key goal of

OEE is to enable a clear view on the effectiveness of existent assets. It defines KPIs to measure this

effectiveness and identify which areas need to be improved. Realizing that existent assets operate at only a

fraction of their potential productivity has direct business implications. For example it prevents unnecessary

investments in additional machines to increase the output. Instead an analysis of KPIs allows identifying

what needs to be improved to achieve the same productivity with assets that are already in place.

Figure 9: Integrated factory floor

The calculation of the OEE is based on the three KPIs availability, performance, and quality. Each factor is

again calculated from further KPIs. The raw information required to compute the necessary KPIs (machine

setting-up time, load, production cycle, downtime, changeover time, equipment depreciation …) comes from

sensors, which are embedded in smart devices. In the following the calculation for each KPI is stated and

influencing factors are described.

Availability: The availability factor reflects the down-time of a production system. This could be planned

down-time due to maintenance work, set up time or retooling. It could also be down-time that is caused by

unplanned breakdowns, system failures or supply chain problems. The availability factor is calculated as

follows:

TimeoductionPlanned

TimeOperatingtyAvailabili

Pr=

The actual operating time of the production line is compared to the planned production time. The planned

production time denotes the difference between the plant operating time (the time during which a

production line is open and available for operation) and the planned shut down time (e.g. breaks, scheduled

maintenance).

Performance: The performance factor reflects the speed loss of a production system. The speed of the

production process could be reduced due to a breakdown or system failure along the production line. It


19/68

could also be caused by unnecessary waiting times of work pieces on a conveyor. The performance factor is

calculated by means of the following formula:

PiecesTotalTimeOperating

TimeCycleIdealePerformanc

/=

The ideal cycle time denotes the optimal (that is minimum) cycle time the described process can achieve

under ideal circumstances. The ratio of actual operating time and the amount of manufactured pieces

describes the time it actually took to finish one production cycle. The ratio of both KPIs shows how good the

system performs in terms of speed.

Quality: The quality factor describes the quality loss of manufactured products by comparing the amount of

good pieces to the total amount of manufactured products. It is described by the following formula.

PiecesTotal

PiecesGoodQuality =

By combining all three KPIs, the OEE can be computed as follows:

QualityePerformanctyAvailabiliOEE *∗=

It is important to understand that it is the compound effect of availability, performance, and quality that

determines the overall equipment effectiveness. Based on the computed KPIs, it is possible to identify which

factors lead to a low OEE. By applying analytics on the collected data, critical areas, which cause operational

inefficiencies, can be identified and counter-actions to improve the OEE can be initiated. Therefore the

concept of OEE is not only about collecting sensor data, but also about analyzing, reasoning and the

deduction of guidelines on how to improve the OEE. OEE is an example for the integration between the

manufacturing device level (“shop floor”) and the business applications level (“top floor”). The integration

between the digital and the physical world using the concept of OEE is the basis for capturing information

about equipment usage and storing it into business systems. To enable OEE it is necessary to have access to

equipment data in near-real time and provide this information to enterprise applications that come to

decisions based on this information.

1.4.2 Scenario: Well-founded buying decisions

This scenario deals with the question how OEE can be applied to make well-founded buying decisions when

it comes to an extension of a factory’s output. If the existing assets already seem to operate at their limits, a

precipitous buying decision might be reached to extend the output. This additional investment might be

unnecessary, if the existent assets deliver less output than technically possible. Using availability,

performance and quality data about the assets in place, the OEE value can lead to the conclusion that the

available assets could deal with the increased demand, if they where used more effectively. A drill-down to

the causing parameters allows improving the OEE, e.g. by replacing a fragile mechanical part and increasing

the low production speed again. OEE can also be used during the after-sale phase, by providing constant

performance data about a new machine. This way it is possible to figure out, if the asset fulfils the

specification promised by the machine vendor. Having this control instrument at hand, companies can

negotiate output-driven contracts when buying new assets, which guarantee certain performance measures.

1.4.3 Scenario: Product line optimization

The underlying domain for the product line optimization scenario is manufacturing automation. First of all

the overall equipment effectiveness of the current production line is calculated. Therefore the data collected

from smart embedded devices that control the production process is collected and used to compute the

necessary KPIs. Based on the found data, the KPIs that are responsible for a low OEE are identified.


20/68

As an example a low performance value indicates a speed loss, which could be caused by production pieces

waiting in front of a working station without a need. Run-time deficiencies like this can be caused by a

previous restructuring of the production line or poor production line planning. One possibility to

automatically detect the denoted waste of time is to use checkpoints for equipment on a conveyor and

compare the timestamps of every checkpoint with the planned production flow. After the identification of

the responsible point(s) in the production line, the optimization takes place. To ensure that the new

configuration of the production line lead to an improvement of the overall equipment effectiveness, the same

measurements as before are used to calculate the required KPIs and a new OEE. Finally, the new data is

compared to the old KPIs to verify, if the desired improvement was achieved.

1.5 Customized manufacturing with late order freeze

1.5.1 Overview

Commercial production can occur at many levels of customization (see Figure 10). One extreme is the

production of completely customized products (engineering-to-order). An example would be the

manufacturing of dental prostheses or custom-made furniture. In both cases, every item ordered and

produced is very different and tailor-made. On the other end of the spectrum, we find mass products that

cannot be customized (being make-to-order), such as electronic chips, e.g. microprocessors. Here, only the

amount of identical items can be configured within an order.

Low VolumeHigh Price

Many Parameters

High VolumeLower Price

No Parameters

Custom Products

ConfigurableProducts

MassProducts

Engineer toorder

Assemble toorder

Make toorder

Figure 10: Levels of customization in industrial production

Of particular interest for machine integration with the business systems are all product types in between the

extremes, i.e. products that are configurable to some extent, yet still standardized enough to be produced in

lager quantities by a single production process (i.e. assembled to order). Good examples for this class of

products are cars and personal computers. By connecting the shop floor with the business system, the period

during which the customer can change a product parameter can be stretched to the point, where the

parameter is actually incorporated in the product. This point in time is referred to as the order penetration

point, the point where collective planning for a multitude of orders ends and the planning for individual

orders begins. Additionally, the customer can be informed about the production stage and the expected

completion of the order in near real-time.

Shop-floor information could also influence contracts and other legal artefacts. The manufacturer and its

consumer could e.g. negotiate a contract where the consumer has to pay a certain fraction of the price at

order time, start of production, and delivery. Or the manufacturer could charge a fee if the consumer cancels

the order that could be significantly higher after the production process has started. These transitions

between the contract phases could be supported by data coming from the shop floor.


21/68

1.5.2 Scenario: Car manufacturing

Cars are a very good example of a class of configurable products. When ordering a car, a consumer can

choose from a broad range of options. The higher the value of a car model, the more options are available to

the customer. The main sales channels today are local dealers, where cars are configured either in a dealer’s

office or at home using a web interface or a stand-alone configuration program that associates the order to a

local dealer as soon as it is completed.

Procurementcomplete

Procductionstarts

Time

Conventionalorder process

Using shop floor information

Configuration

Configuration

Cheapcancellation

Freezechanges

Monolithicprocution process

Deadline

feature 1

Deadline

feature 2

Deadline

feature n

Productioncomplete

Ordersubmitted

Invoice isissued

Invoice isissued

…

Figure 11: Order process innovation using shop floor information

Usually, once the order is submitted by the customer and the dealer, the contract is binding. The customer

cannot cancel your order. This is reasonable because it allows for a longer planning horizon of the

manufacturer and its component suppliers. However, with more flexible contracts and detailed data from

the shop floor, it would be possible to let the customer cancel the order without significant additional cost on

both sides. This period could be extended to the point where the component suppliers confirm orders and

charge a fee for cancellation themselves.

When the production process has started, there may be certain deadlines, until a variant of a feature can still

be changed. Take e.g. the colour of a car. The material for this particular feature, i.e. the different paints,

must be on stock and are not procured for each car individually. So it would not be of high cost for the

manufacturer to allow the customer to change the colour of her car just until the painting station prepares to

spray the ordered paint onto the car and informs the business system about this.

Finally, there will be a point in time, where the order cannot be changed any more and is carried out until

the production is completed. With the business systems being notified about the completed production

process immediately, they can immediately initiate any legal transactions that result from the completion.

Larger co-operations e.g. who buy many cars might have contractual obligations to pay a car once it has

been produced. The invoice could in this case be issued faster.

Regardless all these financial and legal implications of connecting shop floor systems with business software,

it is expected that the detailed insight and the option to decide on certain features at a late stage would

clearly create an outstanding buying experience for the customer. Those car manufacturers who will

implement these kinds of features first, will have a competitive advantage relative to their peers.

Customers are expected to be less cautious about signing a contract or complete an order on the internet if

they know they can cancel their order at a very reasonable cost for a certain period and are able to change

the features after completion. These more spontaneous orders might create additional sales.

1.5.3 Scenario: Pre-fabricated houses

The production of pre-fabricated houses has become very industrialized. Complete walls, including

windows, electrical wiring, and parts of the plumbing and air conditioning system, are produced in a factory

and transported to the construction site for assembly. Customers and sales employees configure the house


22/68

together, arranging e.g. the position of power outlets, doors, and windows. The integration of the

manufacturing execution system (or the shop floor automation if it offers built-in high-level functionality)

with the customer front-end of the business system could eliminate the need for manual transfer of

information between these systems, including the transformation of data formats.

On top, many of the arguments regarding customer experience described in the last section are also valid for

this scenario.

1.6 Automotive Domain / Remote Systems

1.6.1 Overview

Currently, many car manufacturers perform services and maintenance activities based on reactive

approaches. This often can cause significant financial loss due to the production downtime or variation due

to process degradation because of machine breakdowns, particularly during mass production phases.

Therefore, any resource malfunctioning is aimed to be dealt with rapidly. Significant production losses can

be associated with increasing the Mean Time to Repair (MTTR) factor, when on site support is not

immediately available. This is particularly the case during commissioning and ramp-up phases of the

automotive lifecycle.

However in many cases during the production/assembly phases, the presence of the machine vendors is still

required to identify or solve problems. This has been proved to be unacceptably time consuming and costly

for some of the automotive end users with globally distributed manufacturing and vendors’ sites.

Therefore, enhancing remote capabilities (e.g. monitoring, error handling, and maintenance) are currently

important aspects of the future plans for the majority of companies in the automotive industry.

Fault recovery, self maintenance and remote diagnostics are some of the essential features required for the

modern service engineering in automotive industry. These features are required to develop proactive

maintenance strategies to guarantee the product and process performance and ultimately eliminate

unnecessary system breakdowns.

As part of the advanced service engineering technologies, the Remote Expert Assistance (REA) system has

been developed to support domain end-users (e.g. car manufacturers) to provide a fast recovery of the

system processes.

One of the main issues of the Remote Expert Assistance is to create a new form of relationships between end

user and the suppliers in order to ensure the quality of service throughout the lifecycle.

1.6.2 Scenario: Remote Expert Assistance (REA)

Remote Expert Assistance is a technology that enables production/assembly sites staff to be given immediate

live technical assistance by the hardware/software vendors. With this technology, the remote experts would

be able to utilise web enabled manufacturing control systems to proactively monitor and assist sites

resources. A web-based manufacturing/assembly line monitoring implemented over the internet is proved to

be a fast and cost effective way to deliver real time performance and diagnostic information.

The concept used for the Remote Expert Assistance is shown in Figure 12: .


23/68

Figure 12: Schematic of a remote expert assistance used for the automotive industry

End user (i.e. persons at the shop floor level) determine the need for external assistance and contact with

appropriate remote experts (i.e. the persons from the Original Equipment Manufacturers – OEM) to invite

them for a remote expert session.

Using an online session the end user and remote expert share real time information and can view each other

activities. The end user and remote expert determine the source of problems together. A remote expert

recommends corrective actions to the end user and remains online until the issue is resolved or it is

determined that a service call is required. The remote expert (or end user) evokes the local controller's

programming software and establishes a connection to the selected machine controller.

At this point in time for the initial contacts, conventional methods such as emails and phones are used.

Further network communications are established manually to upload machine activities logs to the vendors’

sites. The information is formatted appropriately to be usable for the remote experts. However, the experts

do not have direct control or access to the machine control systems at the end-user site.

1.6.3 Scenario: Automatic Remote Expert Assistance (AREA)

Further research is being carried out to automate the remote assistance communication without the need for

human intervention. Smart error handling functions are embedded in the machine control systems to enable

machines to communicate directly with the vendors’ remote expert systems.

As a malfunctioning is detected, the automatic remote expert assistance (AREA) informs the site operators

and also a remote expert through a secure web-based communication system. The remote expert is able to

perform a remote diagnostic procedure and correct the problem by accessing and amending application

logics within the machine components. A protocol is being developed to provide a safe and secure vendors’

remote control over the machine sites.

2 Requirements Analysis for Distributed Smart Embedded Devices

In order to create and effectively integrate the smart embedded devices in a SOA infrastructure, some

requirements need to be fulfilled. An initial list of them is depicted below:


24/68

• Web Service Support

• Support an Event Driven Architecture (EDA)

• Service Lifecycle Management

• Business Process Modelling

• Occasionally Connected Assets

• Occasionally Disconnected Assets

• Business Process Monitoring

• Alerting

• Risk Management

• Standardised communication and information exchange

• Maintenance Control

• Predictive Maintenance

• Access to Device Status

2.1 Web Service Support

A Web Service is the novel way of accessing programmable application logic using standard Internet

protocols. Web Services combine the best aspects of the Internet and component-based development. As

components, Web Services provide functionality that can be reused without worrying about how the service

is implemented. This differs from current component technologies as DCOM, RMI, or IIOP since web

services are not accessed via object-model-specific protocols. Instead, Web Services are accessed via

ubiquitous Web protocols such as HTTP and data formats (e.g. XML).

Web Services have emerged as the de facto standard for connecting enterprise business application.

Coupling these applications with shop floor machinery increases the efficiency of business processes and

allows for a real time view of the network and interaction with its components.

In this context, to improve the transparency of the connection between back-end systems and shop floor

machinery, the ideal solution is to have these machines providing their services as web services. This can be

achieved by using a specification such as DPWS, however it is also necessary to keep in mind that for a

transition time legacy systems would also have to be supported via web services. Web services are the

common denominator that needs to be supported by all components participating in a service oriented

infrastructure as the one envisioned in SOCRADES.

2.2 Support an Event Driven Architecture (EDA)

In a business process, thousands of events are generated on the shop floor during normal operation. Some of

these events can provide an overview of the current status of the network and others can indicate

unexpected issues generated in the system. Although not all events provide meaningful information for

business applications, some are of interest to the business applications and should be propagated to the

back-end systems.

Therefore eventing support is a requirement for business applications to become deeply connected to the

shop floor having real time information. In addition to that, filtering mechanisms to select the messages that

are of real interest to the back-end must be implemented. This will increase the scalability of the system and

reduce the costs for gathering the data that has relevance for business processes. Processing of events (e.g.


25/68

filtering or evaluation) can be done at several layers between the back-end systems and the devices, where it

makes sense.

The SOCRADES components need to support the envisioned Event Driven Architecture (EDA) i.e.

production, detection, consumption of and reaction to events. Building services and systems around an

event-driven architecture enhances the responsiveness of the infrastructure. An Event Driven Architecture is

seen as a complementary part of the Service-Oriented Architecture (SOA) since services can act on and react

upon events.

2.3 Service Lifecycle Management

To optimize business processes one of the key factors is to reduce the Mean Time To Repair (MTTR). This

indicates the amount of time that a system has to stop until it is ready to be used again. The system might

stop because failures have happened or because new versions of a given service have to be deployed.

From that perspective an effective Service Lifecycle Management to deploy new services or services updates,

start and stop applications, configure/parameterize running services would not only increase the availability

of the enterprise system as it would extend the possibilities of modifying the business process without

considerably influencing the efficiency of the entire system.

2.4 Business Process Modelling

Business Processes evolve and their modelling is getting challenging as more complex processes arise.

Therefore business architects are now counting heavily on business process modelling tools to envision,

design and evaluate future business processes. As we move towards a real time enterprise where the events

coming from the shop floor can be actively integrated and evaluate during the execution of a business

process, we will be able to better address the need for effective execution and optimisation. Within

SOCRADES we have to make sure that the devices, their data and their operation are easily integrated in

such tools that have now the capability to plan a business process in detail and specify its interaction from

high-level to network-based services and down to device level.

2.5 Occasionally Connected Assets

In occasionally connected assets, the devices can connect occasionally to the backend system. This could be

done periodically or even opportunistically e.g. a mobile device moves for a specific timeframe in an area

that provides network connectivity and services and then it ad-hoc discovers, connects and updates its info.

The approach taken has to make sure that the envisioned scenarios and its components can also function

while there is no permanent connection or a very limited one with the back-end system. Therefore scenarios

that require local business intelligence and local interaction should be possible. A device should be able to

locally find and cache the data it requires from the local network in a peer-to-peer way, without necessarily

be connected to the backend system (in order to do the retrieval of the necessary data). Typically in a grid of

similar devices if one fails, it should be possibly to immediately replace it with another device, which should

then get its configuration, tasks and operation data from the nearby devices.

2.6 Occasionally Disconnected Assets

Occasionally disconnected assets are usually connected to back-end systems but may suffer sudden

disconnections e.g. when moving between locations with varying quality of wireless connectivity. Despite of

their connectivity status, they have to be able to work offline for longer periods of time. In order to achieve

this, partial replication of backend data and business logic is the only way to provide continuous operation.

Issues like data propagations, conflicts, scheduling etc need to be effectively supported; therefore this

requirement implies some initial support towards the aforementioned challenges.


26/68

2.7 Business Process Monitoring

Business Process Management comprises all necessary procedures to ensure the operation and the smooth

and reliable flow of the core business processes to meet a company’s business requirements. An integral part

of it is Business Process Monitoring, which is the proactive and process-oriented monitoring of a company’s

core business processes It includes the observation of all technical and application-related functions that are

required for a smooth and reliable flow of the core business processes. It comprises detailed procedures for

error handling and problem resolution and precise definitions of contact persons and escalation paths. As

the goal is to detect problem situations as early as possible in order to solve them as fast as possible, - before

they become critical for the business - this needs to be done in close cooperation with the devices themselves.

It has to be assured that monitoring from the business process level is feasible directly for the specific device,

and vice versa, unsolicited events can be directly sent to the responsible business process component.

2.8 Alerting

Although a requirement for the support of an event driven architecture exists, alerting has also to be

supported especially from the mission critical devices. In a critical situation, messages will have to be

treated with high priority, and there will be no time to do that at a high level. Furthermore, the business

application should get only the necessary decision-critical information and not get overhauled with all

alerting data from the shop floor. Therefore support for exchange of emergency data and a common alerting

protocol have to be in place, which will regulate the communication of info between the different

architecture layers. This implies the usage of efforts such as the Common Alerting Protocol (CAP) [6] and

Emergency Data Exchange Language (EDXL) [7].

2.9 Risk Management

Decisions at business level need to be properly supported by the intermediate layers. Therefore the devices

that directly affect business processes should be able to provide a limited number of estimation capabilities

with regard to their functionality. Even if a simple malfunction occurs, the device should be able to report on

what percentage its capability is affected or if and for how long it can achieve the remaining tasks without or

with limited maintenance.

The motivation is pretty simple. Risk management makes the required decision critical information available

significantly earlier. The earlier that information about risks is available, the less significant are the effects.

Therefore strategies can be changed proactively while minimizing overall costs. Since the device itself better

knows how a failure of one of its components affects it in total this info must be encapsulated so that

business processes can take advantage of it. This will empower any risk management scenarios and will lead

to optimization and better understanding of the process.

2.10 Standardised communication and information exchange

We do not aim at creating home-grown communication and information exchange solutions in SOCRADES.

Instead the plan is to build upon existing standards. In that sense, existing protocols for communication and

information exchange in XML-similar forms will be used if they exist, or be extended to better suit our

needs. This mostly refers to the communication of the backend systems with the devices, as well as the high-

level device communication among themselves. Such support has interoperability implications as it will ease

the device integration and cooperation in a highly heterogeneous infrastructure. In that sense OASIS [8]

standards will need to be consulted first and used.

2.11 Maintenance Control

Maintenance, Repair and Overhaul (MRO) refers to all actions which have as an objective to retain a device

in or restore it to, a state in which it can perform the required function. The actions include the combination

of all technical and corresponding administrative, managerial, and supervision actions. As such any


27/68

deviation from expected business behaviour (e.g. based on sensor reading etc), should be reported ideally by

the device itself. Furthermore it should be possible not only to get notifications about the process but actively

interact with the device. Therefore it should be possible via a web service interface to initiate activities such

as tests, measurements, replacements, adjustments and repairs, intended to restore or retain a functional

device in a specified state in which the device can perform its required functions. As MRO involves working

with products, an organization’s resources, suppliers and customers, MRO-enabled devices have to interface

with many enterprise’s business software systems e.g. PLM, ERP, SCM, or CRM.

2.12 Predictive Maintenance

Predictive maintenance evaluates the condition of equipment by performing periodic or continuous

equipment monitoring with the goal to perform maintenance “just in time”, before the equipment fails. This

is in contrast to time and/or operation count based maintenance where a piece of equipment gets maintained

whether it needs it or not. Time based maintenance is labour intensive, ineffective in identifying problems

that develop between scheduled inspections and is not cost effective. Predictive maintenance leads to an

equipment usage near the limits of their maximum possible life time by prevention of production down

time. We want to support this maintenance strategy by enabling collaborations between production

equipment and enterprise wide business process control systems. Devices and control systems have to

provide prediction units and event generation systems to support predictive maintenance. The generated

messages have to be conformant to message specifications of the business process control systems. Beside

this requirement for devices it could be necessary to implement prediction units and event generation units

in the business process control system in case of supplemental algorithms and observations of a small set of

process values of interest. Multivariate approaches play a big role in context of predictive maintenance;

therefore measurement devices should publish the certainty/uncertainty of measured process values. Since

most predictive maintenance inspections are performed while equipment is in service we minimize the

disruption of normal system operations and have substantial cost savings and higher system reliability.

2.13 Access to Device Status

Since devices will be equipped with web services, these should provide a rich interface to the device status

and options that can configure it or even allow code to be downloaded to the device and executed. All

devices should provide a standardised view of their capabilities according to the project’s ontology and

scenario needs. Furthermore the device should be able to send unsolicited events to a number of services

relying at business layer as well as to expert and planning systems. Generally the device should allow full

real-time access to its status on any authorized entity. In case of devices that control other devices e.g.

SCADA systems, then correlation of the devices’ status’ could be done to hide complexity and provide an

overall status.

3 Technology

This chapter describes some of the technologies that could be used to bridge the gap between embedded

devices and enterprise applications. Traditionally, this link has been implemented using a layered approach,

each layer being responsible for interacting with the one directly above and the one directly below, the

device layer being the bottom one and the enterprise systems layer the top one. It is not infrequent to find

two or three intermediate layers in such an approach, which means that any adaptation of the overall

communication chain to new business requirements must impact a large number of layers, hence reducing

the agility of the overall system.

The advent of Web services and service-oriented architectures provides an opportunity to improve the

connection between embedded devices and enterprise applications, for several reasons:


28/68

• At the communication protocol level, the use of a common, standard protocol such as SOAP over

HTTP is a guarantee that embedded devices and enterprise systems will be able to directly

communicate together, without the need for gateways mapping one communication protocol to

another. In addition, Web services do not rely on any particular programming language or platform,

thus ensuring their availability on the widest possible range of hardware and platforms.

• At the application design level, the exposure and formal description of functionalities as stable

service interfaces and the loose coupling advocated by service-oriented approaches will ease

integration and increase flexibility and agility, as services can easily be reconfigured or replaced.

This chapter further presents in more details some of the options that can be taken when integrating

embedded devices with ERP systems.

3.1 Service Oriented Architecture

The main aspects of service-oriented architectures are described in deliverable D1.1 (State of the art). These

architectures are characterized by the following properties:

• Logical view: The service is an abstracted, logical view of actual programs, databases, business

processes, etc., defined in terms of what it does, typically carrying out a business-level operation.

• Message orientation: The service is formally defined in terms of the messages exchanged between

provider agents and requester agents, and not the properties of the agents themselves.

• Description orientation: A service is described by machine-processable metadata.

• Granularity: Services tend to use a small number of operations with relatively large and complex

messages.

• Network orientation: Services tend to be oriented toward use over a network, though this is not an

absolute requirement.

• Platform neutral: Messages are sent in a platform-neutral, standardized format delivered through

the interfaces.

Most of the above features are relevant to the business integration issues:

• The logical view, message orientation and high granularity ensure that business applications and

embedded devices will remain as loosely coupled as possible, e.g. by using asynchronous message

passing with no access to the internal state of message exchange participants. This in turn induces

greater agility, as services can be easily reconfigured or replaced. The direct; peer-to-peer

communication also ensures that no higher level entity is required to control or transform the

message exchanges, thus limiting the impact of changes to the exchange participants.

• If needed, higher-level services can be built through composition and encapsulation of existing

services, thus providing better scalability and manageability. Value-added functions usually found

in intermediate layers between devices and business applications can be encapsulated in such

services.

• The platform-neutral message format means that most devices can directly participate in message

exchanges with business applications, thus limiting the need for gateways to the smallest and the

legacy devices.

• Integration costs can be brought down, as re-use of services is facilitated and application

programming is done at the highest possible level of abstraction, using business-level operations.

• The service-oriented approach can bring major improvements with respect to existing distributed

object technologies such as DCOM, CORBA or Enterprise JavaBeans:


29/68

• The coarse-grained, message-oriented, stateless, asynchronous interaction model proposed by SOA

is more flexible, scalable and manageable than the fine-grained, object-oriented, stateful,

synchronous interaction model often induced by the distributed object technologies.

• The platform-agnostic property of SOA favours the integration of participants based on

heterogeneous hardware and software platforms, while most distributed object technologies (with

the notable exception of CORBA) are reliant on some specific, often heavyweight technologies,

which makes them hard to implement on small devices.

In the following sections we focus on:

• Service Composition

• SCA – Service Component Architecture

• BPEL - Business Process Execution Language

• Scripting languages

• Business Application Integration

3.1.1 Service Composition

Designing applications on top of service-oriented architectures is different from building monolithic

applications, as it was best practice in the past. Services are offered at various layers of the system. Some

services offer detailed functionality that is not relevant at the business level while other services are more

coarse-grained, offering rich functionality including business context.


30/68

Figure 13: Service composition in a hierarchy of services

Service composition as depicted in Figure 13 can be a way of using services of a lower layer to build higher-

value services that fit in a higher layer.

The concept of service composition is relevant for enterprise software integration, because the services used

by a single device on the shop floor, like a service that allows starting or stopping a drill, will be mostly

useless for an enterprise application. Services of a granularity as small as the mentioned example need to be

combined both within one device and across many devices to form higher-level services, such as a service

that allows instructing a machine to drill holes at a list of positions that are passed as parameters.

Figure 13 shows another example of service composition where services of parts of a machine are composed

into a machine operation service. The machine operating services of several machines are then again used to

compose a production execution service.

3.1.2 SCA – Service Component Architecture

Service Component Architecture (SCA) is a set of specifications which describe a model for building

applications and systems using a Service-Oriented Architecture. SCA (Figure 14) extends and complements

prior approaches to implementing services, and SCA builds on open standards such as Web services. SCA

encourages an SOA organization of business application code based on components that implement

business logic, which offer their capabilities through service-oriented interfaces and which consume

functions offered by other components through service-oriented interfaces, called service references. SCA

divides up the steps in building a service-oriented application into two major parts: (1) The implementation

Enterprise

Machine / device

control

Manufacturing

Execution Machine operation

Service

Push button

Service

Display

Service

Drive control

Service

Drive control

Service

Drive speed

sensor Service

Item presence

Service

Production Execution Service

Machine operation

Service Machine operation

Service


31/68

of components which provide services and consume other services; (2) The assembly of sets of components

to build business applications, through the wiring of service references to services.

SCA emphasizes the decoupling of service implementation and of service assembly from the details of

infrastructure capabilities and from the details of the access methods used to invoke services. SCA

components operate at a business level and use a minimum of middleware APIs. The component offers its

functionality as services and accesses other components via references. A component’s services are defined

either by a WSDL port type (the operations of a service) or a Java interface. In addition, a component has

settable properties that can influence its behaviour. Components can be implemented in a number of ways,

including classical programming languages such as C++ and Java, but BPEL and scripting languages

(concepts that are explained in the next two sections) can be used as well.

Figure 14: Artefacts of SCA3

Components can be grouped together into composites by wiring of service references to services. From the

outside, if seen as a black box, the composite acts just like a component offering services and having

references to services of other components or composites. Composites are the SCA realization of service

composition and serve as units of deployment for SCA systems.

Figure 15: SCA system

3 Images in this chapter used under the licence terms stated in chapter 0.


32/68

The next level of aggregation is the SCA system (Figure 15), comprising a set of services that provides a

certain class of business functionality and is under the control of one organization.

For each of the artefacts of a SCA system, there is an XML format defined, containing all configuration data

necessary. However, it is defined that a SCA runtime system may store this configuration data in a different

way, possibly specific to the programming language or framework used.

3.1.3 BPEL - Business Process Execution Language

Currently, the Business Process Execution Language is regarded as the most widely used standard for

describing business process, meaning compositions of web services, in an executable way. BPEL is defined

as an XML format that describes the parties (web services) participating in a business process, the operations

of the parties that are invoked, and the sequences, conditions, and loops in which this takes place. Further,

using process variables and simple arithmetic, the processing of input and output parameters to service

invocations are described. Finally, BPEL also contains constructs for handling errors that occurred during

the execution of the business process. Table 1 lists all XML elements used for describing a process according

to [1]. Since a BPEL process is started when a certain service is called and the result is retuned after the

process has finished, BPEL can be considered as a service composition language. On top of that, it supports

other conversational styles, including asynchronous receiving and sending of messages.

BPEL

Construct

Semantics

<receive> A business process provides services to its partners through receive activities and

corresponding reply activities. Until an appropriate message is received the process is

blocked.

<reply> A reply activity is used to send a response to a request previously accepted through a

receive activity. By combining <receive>/<reply> synchronous request-/response operations

can be modelled.

<invoke> Used by a client calling the Web Service interface of a partner; both request/response calls

and one-way-calls are supported.

<assign> The assign activity can be used to copy data from one variable to another, as well as to

construct and insert new data using expressions.

<throw> Starts an exception handling procedure within a process.

<terminate> Unconditionally terminates a workflow.

<wait> Allows a business process to specify a delay for a certain period of time or until a certain

deadline is reached.

<empty> Void operation

<sequence> A sequence activity contains one or more activities that are performed sequentially, in the

order in which they are listed within the <sequence> element, this, in lexical order. The

<sequence> element is a so-called „structured activity“.

<switch> Based on a condition exactly one operation gets selected and executed.

<while> Loop-construct. Semantics comparable to while-loop in higher level programming

languages like Java.

<pick> The pick activity awaits the occurrence of one of a set of events and then performs the

activity associated with the event that occurred.

<flow> Defines statements which are to be processed in parallel. Dependencies between these

statements can be modelled with so-called „Links“.

<scope> Defines an area within a workflow with its own local variables, its own exception handling

and transaction management.


33/68

<compensate> Defines a compensation handler for an already completely processed inner scope.

Table 1: Overview of BPEL4WS – Workflow Constructs [1]

3.1.4 Scripting languages

Scripting languages are typically interpreted thus, scripts are often distinguished from programs, because

programs are converted permanently into binary executable files before they are run. Scripts remain in their

original form and are interpreted command-by-command each time they are run. Scripts were created to

shorten the traditional edit-compile-link-run process.

Modern scripting languages, such as Perl, Python, TCL/TK, VB script, and PHP contain comprehensive

support for web services. They allow to both consume and provide web services. Since service composition

is mostly about waiting for incoming service calls (since the composite is also a service), calling other

services and mapping input to output parameters, using an imperative approach such as scripting languages

is a valid option for realizing service composition. Listing 1 shows an example for creating an RPC style

service in PHP that is composed (i.e. uses) other services.

<?

# offering a service in PHP that uses other services

include("xmlrpc.inc");

include("xmlrpcs.inc");

# the function implementing the service

function method($par){

# call to other services

$format=new xmlrpcmsg('service2.method2',

array(new xmlrpcval($amount, "double")));

$client=new xmlrpc_client("/xmlrpc-server.php", "localhost", 80);

$request=$client->send($format);

$value1=$request->value();

$format=new xmlrpcmsg('service3.method3',

array(new xmlrpcval($amount, "double")));

$client=new xmlrpc_client("/xmlrpc-server.php", "localhost", 80);

$request=$client->send($format);

$value2=$request->value();

# return the composite value

return new xmlrpcresp(new xmlrpcval($value1 + $value2 , "string"));

}

$server=

new xmlrpc_server(array("service1.method"=>array("function"=>"method")));

?>

Listing 1: Example for service composition in PHP

3.1.5 Business Application Integration

Business Application Integration is an infrastructure for connecting heterogeneous business control software

systems like ERP, CRM or CMMS. Some implementations are based on middleware solutions. Goals of most

implementations are:

• lower cost by collaboration of software systems and thus less manual intervention into business

workflows

• a higher data consistency


34/68

• a higher flexibility for integration of additional software systems

• integration of software systems instead of migration

The costs for such systems are determined by the need for adapters, middle-ware, workflow control systems

and so on. The flexibility is determined by the possibility to easily integrate new software systems into the

system at runtime but also at features for automatic data conversion.

A Service Oriented Architecture is a very flexible infrastructure concept. It provides basic functionality for

information exchange, but there are no functional interface definitions. Because of the great variability of the

SOA it is possible to build a variety of business application integration topologies on it:

• Point-to-Point / Peer-to-Peer: Applications are directly connected to each other. This approach is

applicable only on integrated systems with a small amount of connections. It is very inflexible and to

exchange a system causes a lot of configuration work in other systems. The implementation of such

a topology causes small initial costs but high consequential costs.

• Point-to-Point with Yellow Page support: This approach improves the flexibility of the simple

point-to-point approach. A service component registers at a central yellow page repository with a

formal description of services it provides before connection establishment. The client may look-up a

type of service in the yellow page system and selects one appropriate service component for

communication peer-to-peer at the time of connection establishment. The following information

exchange will be point-to-point. The W3C defines this to be the original Service Oriented

Architecture (http://www.w3.org/TR/2002/WD-ws-arch-20021114/). Message transformation is not

possible as in Hub & Spoke systems or in Message Bus systems. The final selection of the distinct

service has to be done manually in most cases since the yellow page request is for service types and

not for service instances. Thus dynamic binding of message sources to message targets becomes

difficult.

• Hub & Spoke: This is a message driven topology. Systems send their messages to a central

middleware component. This hub is able to transform message dialects. Thus it is much more

flexible than the point-to-point topology even on the semantic layer. If an additional message

language dialect has to be included in the enterprise application integration framework, then the

hub has to be feed with the transformation rules. After that application speaking the new message

dialect may take part in the enterprise information flow. The disadvantage of this topology is that

the hub becomes the bottleneck of information exchange since every message passes this

component. The definition of transformation rules causes high initial cost, but small follow-up costs.

In case of SOA the information exchange between hub and spoke components is done via client-

server mechanisms. The hub is considered to be the server in case of sending a message from a

spoke component to the hub. The addressed spoke component is the server in case the hub

distributes the message. The messages are passed as service parameters.

• Message Bus (Publisher & Subscriber): In that approach a software component subscribes

messages of specified message types at a publisher component. The publisher provides the messages

to each registered subscriber. The pattern of guaranteed data delivery is easy to implement here

since the publisher holds persistent message queues. An advanced version of this approach is the

introduction of a central component, which manages topics (message types). This facilitates the

implementation of message providers since they don't have to implement the subscriber

management. The registration, publishing and messaging services may run on top of SOAs. The

subscriber (or central components) has to provide services for messaging and the publisher (or

central components) has to provide services for message subscription. Messaging systems provide

high performance and are flexible solutions. They allow data broadcasting (1:n) and data collection

(n:1). The disadvantage of such system is the complex distributed architecture which leads to high

start-up costs and low follow-up costs.


35/68

• Service Orchestration: The service orchestration has a similar topology like Hub & Spoke, but in

contrary to that architecture the central component plays an active role. A workflow may be initiated

from services outside of the service orchestration engine. But then the orchestration engine takes

over the control by interpreting descriptions of business workflows (programs) for invocation of

other services. It is able to invoke different services asynchronously and to wait for results before

ongoing in workflows. BPEL is an example description language for service orchestration. The

orchestration approach is a quite flexible solution, but the operators company needs a programmer

in that case. This comes from the fact that some business logic is situated outside of the services but

inside of the orchestration engine. The solution leads to high start-up costs and medium follow-up

costs.

3.2 Device Level Integration Technologies

In order to support business integration based on a service-oriented architecture, embedded devices should

be able to expose their functionalities as services that can participate and contribute to the overall system.

For that purpose, SOCRADES devices will use the SIRENA project [15] results, and more precisely the

DPWS communication stack. This section provides a description of the existing software stack components,

and their applicability to the business integration issues. Additional device-level technologies that could be

deployed on top of the existing communications stack are also introduced.

In the following sections we focus on:

• Web Services and the Devices Profile

• WS Security

• WS Reliable Messaging

• WS Management

• OPC Unified Architecture

3.2.1 Web Services and the Devices Profile

Web services have originally been developed for enterprise applications, which can usually rely on high-

performance servers, benefiting from powerful processors and vast amounts of memory. One of the

challenges successfully met by the SIRENA project was the demonstration that a Web services stack could be

embedded on devices with very limited resources. This stack can be used by an application developer to

expose device capabilities as services.

In addition, devices have specific requirements that are not necessarily covered by standard Web services.

This has led a consortium of industry vendors, led by Microsoft, to specify extensions that are useful for

devices. These extensions are grouped into a separate specification, called the Devices Profile for Web

Services (DPWS). DPWS is built on top of the SOAP 1.2 standard, and relies on additional Web Services

specifications, such as WS-Addressing and WS-Policy, to further constrain the SOAP messaging model. The

Profile defines the following built-in services:

• Discovery services (WS-Discovery): those services are used by a device connected to a network to

advertise itself and to discover other devices and services.

• Metadata exchange services (WS-MetadataExchange): those services provide dynamic access to a

device’s available services and to their metadata, such as WSDL or XML Schema definitions

• Event publish/subscribe services (WS-Eventing): those services are extensions of functional Web

services, and allow other devices to subscribe to asynchronous messages (events) produced by a given

service.


36/68

DPWS defines an architecture that distinguishes two types of services: devices (hosting services) and hosted

services. Devices play an important part in the discovery and metadata exchange protocols. Hosted services

provide the functional behaviour of the device and depend on their hosting device for discovery. The typical

architecture for a DPWS device is shown in Figure 16:

Device• Logical address

• Device type

• Model and device description

DPWS

Hosted service• Physical address

• Service description

• Service

implementation



• Service

implementation



• Service

implementation

Discovery

Metadata

Services

Events

Figure 16: DPWS device architecture

The Web services stack resulting from the SIRENA project is shown below:

Platform (OS/Java)

IP v4/v6

UDP TCP HTTP

SOAP 1.2, WS-Addressing

Service Invocation EventingWS-Discovery

WS-Metadata

Device and hosted services

(application software)

Native code

(C, Java…)

Development tools

Figure 17: DPWS communications stack

The bottom layers represent the core software that is expected to be available on each device in order to

deploy the Web services stack. The only exception is the HTTP server, which can be provided by the stack if

required.

The next layers are the mandatory features that must be supported by the stack to be compliant with the

DPWS specification.

The top layer represents the application-specific services that can be developed, in the SIRENA

implementation, in native code only (either C/C++ or Java). In order to ease the development and allow the

developer to focus on application-level issues, rather than communications issues, the SIRENA toolkit

provides a set of tools for generating proxy, event handler (client-side) and skeleton (server-side) code from


37/68

service descriptions (WSDL files), as shown in Figure 18. The figure describes the behaviour of the tools for

the C/C++ version; a similar approach is used for the Java version.

Client

WSDLWSDL

.h+gsoap.h+gsoap

DPWS runtimeService

implementation

.h .c

Service

implementation

.h.h .c.c

Generated

proxy (client)

.h.h .c.c

Generated

skeleton (server)

.h.h .c.c

Client

implementation

.h .c

Client

implementation

.h.h .c.c

Generated

marshalling

.h.h .c.c

Developer

Optional

Generated

Generic

Server

Generated

handler (client)

.h.h .c.c

Handler

implementation

.h .c

Handler

implementation

.h.h .c.c

Figure 18: DPWS C/C++ code generation approach

Although not specifically developed for business application integration, the DPWS stack already provides a

number of features that can be useful in such a context:

• All application services exposed by a device can be accessed from any client on the network, provided

that this client supports the SOAP 1.2 protocol. Therefore, any business application able to use a SOAP

1.2 connector should be able to interact with a DPWS device.

• The WS-Addressing protocol provides support for transport-independent addressing and routing

mechanisms. This protocol could be used for business integration to address specific resources within a

device, and to support intelligent routing through network gateways.

• The discovery and metadata exchange protocols (WS-Discovery, WS-MetadataExchange and WS-

Transfer) currently supported by the DPWS stack are useful to support the plug-and-play and dynamic

reconfiguration requirements of devices. However, the basic discovery mechanisms provided by WS-

Discovery are limited to the local network, and may therefore not be very useful for business integration.

Discovery Proxies, acting as service registries providing discovery services beyond the local network, are

also defined by the WS-Discovery specification and will be developed during the SOCRADES project.

• The DPWS stack supports a general purpose publish/subscribe mechanism, through the use of WS-

Eventing. However, the default event delivery mechanism defined by WS-Eventing, based on a simple

push model, could be too limited for the business integration use cases. Therefore, the SOCRADES

project will need to develop alternative event delivery mechanisms.

3.2.2 WS Security

The connection of the device-level network, which is traditionally considered as an isolated and therefore

secure network, to the enterprise-level network, which is much more open, can be considered as a security

threat to both the device-level network and the enterprise systems. In order to reduce this threat, a possible

approach is to secure all communications between the device network and the enterprise network.

Two solutions can be used to secure the communications:


38/68

• Securing the communications channel, using technologies such as SSL/TLS and HTTPS: the main

issue with this approach is that a communication channel must be secured from end to end, which is

not always possible when heterogeneous network media and protocols are in use.

• Securing the message contents, using WS-Security: this protocol, which is described in more details

in the D1.1 (State of the art) document, supports both the signature and the encryption of arbitrary

parts of a SOAP message, thus securing the message contents while allowing the message to be

routed across the network.

The second approach seems better suited to business integration. However, as implementing the complete

WS-Security protocol on small devices may not always be feasible, due to resource limitations, more

complex architectures may be required, involving security gateways in charge of securing all incoming and

outgoing messages entering and leaving the device network.

3.2.3 WS Reliable Messaging

Reliable messaging is another issue which is relevant in the context of business integration. Due to the

complexity of a network spanning the various layers from the devices to the business applications, it is likely

that devices will not always be able to receive messages from or deliver messages to business applications in

a synchronous manner. However, in some cases (for instance alarms), it may be required that a message be

delivered reliably to its recipient.

A reliable message delivery system may therefore be required for connecting embedded devices to business

applications. Such a system should support WS-ReliableMessaging, as this specification is currently being

implemented in most enterprise development frameworks, including those provided by Microsoft, IBM and

Sun. From the device point of view, it means that the existing stack should be extended to support the

interactions with reliable message sources and destinations.

3.2.4 WS Management

There are two competing proposals for defining a general-purpose protocol for managing resources

(creating, accessing, updating and deleting them) using Web services: WS-Management and WSDM, which

are pushed by two different industrial consortia and standardization bodies. From a technical point of view,

the two proposals are quite similar, with WS-Management being slightly simpler and WSDM slightly richer.

In the longer term, it is likely that the two specifications will eventually merge, as the main actors behind the

proposals have agreed upon a convergence strategy. In the context of the SOCRADES project, WS-

Management should probably be preferred, as it relies on WS-Eventing, which is already available in the

existing device stack.

Using a simple and standardized resource access protocol to achieve business integration could make sense,

as it would allow business applications to connect to devices and services or subscribe to events without

having to use a specific protocol for each device or service that needs to be accessed. On the other hand, for

such a scheme to work, a resource model should be defined, that is both generic and rich enough to account

for the wide variety of devices and services that will have to be modelled and accessed.

Several candidate models could be considered: in the management domain, the Common Information Model

(CIM) has been used successfully for a long time. Alternatively, a new proposal from the main industry

vendors (Microsoft, IBM, BEA…) called “Service Modelling Language” (SML) could also be considered.

Another source could be the IEC standards used for device descriptions.

In any case, if WS-Management is selected as the preferred means to interact between embedded devices

and business applications, additional work will be required to analyse in depth the various resource models

described above, and select or define the most appropriate one for the SOCRADES project.


39/68

3.2.5 OPC Unified Architecture

The OPC Unified Architecture is the new version of the well-known OPC architecture originally designed by

the OPC Foundation to connect control devices to control and supervision applications.

The OPC UA architecture is based on widespread Web standards, including XML, WSDL, SOAP and some

WS-* specifications:

• WS-Policy is used to negotiate protocol and encoding.

• WS-SecureConversation (based on WS-Security and WS-Trust) provides secured sessions.

OPC UA could therefore be considered in the context of the SOCRADES project as a possible extension of

the existing DPWS stack, as an alternative to WS-Management, as both approaches try to provide a generic

protocol to access device resources.

One important and innovative aspect of OPC UA, notably with respect to WS-Management, is the common

information model that unifies the previously distinct OPC data models. The model uses a tree-based

hierarchical representation, using references to relate different parts of the tree, thus providing a full-meshed

network of nodes. Nodes in the tree can be of different types, including Objects for structured representation

and Variables for dynamic data representation.

This model can be accessed, browsed and manipulated by generic service sets, which include:

• Service sets for establishing a (secure) communication channel and a session.

• Service sets for reading, writing and subscribing to data.

• Service sets for browsing, querying and modifying the tree representation.

• A service set for calling arbitrary methods.

OPC UA thus provides a homogeneous and generic information model and a set of Web Services to

represent and access both structure information and state information in a wide range of devices.

3.3 Business Level Integration Technologies

The aim of SOCRADES project is to design, implement, evaluate its concepts within a real world

environment. In that sense there will be strong integration with existing commercial products, in order to

show the benefits to existing business solutions. Examples of commercial products that will be used for the

integration include:

• ERP Systems

• xApp Manufacturing Integration and Intelligence (xMII)

• NetWeaver

• Exchange Infrastructure (XI)

3.3.1 ERP Systems

Enterprise Resource Planning systems (ERPs) are concerned with the integration of all data and processes of

an organization. They are typically composed of and use multiple componentsin order to achieve the

integration. Key goal is the efficient planning of enterprise-wide resources. Although the acronym ERP

originated in the manufacturing environment, today's use of the term ERP systems has much broader scope,

typically covering a great number of functions of an organization. Examples of ERP include Manufacturing,

Supply Chain, Financials, Customer Relationship Management (CRM), Human Resources, and Warehouse

Management.


40/68

One of the motivations is to strongly couple ERP systems with the factory shop-floor, which could lead to

better business efficiency. Today’s ERP systems are only weakly integrated and rarely in real time with all

the layers between the business and operational device level.

There are several vendors providing ERP systems, e.g. SAP, Oracle Applications, Infor Global Solutions, The

Sage Group, Lawson Software, Microsoft Dynamics (Formerly Microsoft Business Navision), BizAutomation

CRM, Unit 4 Agresso, Industrial and Financial Systems, Visma, QAD, Epicor, NetSuite, SIV.AG,

24SevenOffice etc Also a number of free software / open source ERPs are available e.g. Adempiere, Apache

OFBiz, Compiere, ERP5, GNU Enterprise, Openbravo, SQL Ledger, Tiny ERP, DYNAMIC 3i Free Edition

etc. SAP is a leader in providing ERP solutions and the integration of SOCRADES results with a leading

commercial system will allow us to evaluate in a real-world environment the concepts developed within the

project.

3.3.2 xApp Manufacturing Integration and Intelligence (xMII)

SAP xMII is a product of SAP that can integrate plant floor data with any business system, especially the

SAP ERP product built on the NetWeaver platform.

It provides manufacturing integration (through a single, standards-compliant connection between shop-floor

activities and enterprise systems for ERP, manufacturing execution, and sales-force automation) and

manufacturing intelligence (using real-time analytics to aggregate, calculate, and deliver a single view of

relevant events, alerts, key performance indicators, and decision support) as depicted in Figure 19.

xMII

S95

Others

Open O&M

Analytics

Alerts

KPI

Visualization

Web Services

Business

Logic

Manufacturing

Intelligence

Manufacturing

Integration

Data Service Layer

Connectors

Figure 19: Functional blocks of xMII

Currently, xMII does not support the whole of DPWS, i.e. the discovery and eventing features of DPWS, but

could of course connect to the web services offered by a device if the addressing is hard coded. xMII

supports the following protocols to interact with devices:

• OPCDA (communicate using COM)

• OPCHDA (communicate using COM)


41/68

• Intouch (Native API)

• PI (Native API)

• GE iFix (Native API)

• GE Historian (Native API)

• RSView (Native API)

• Citech (Native API)

• OLEDB: Microsoft’s generic database connection which allows connection to any database

• JDBC: Allows connection to any database through Java

3.3.3 NetWeaver

SAP NetWeaver is an application builder platform from SAP for integrating business processes across

various systems, databases and sources. It is a web-based, open integration and application platform that

serves as the foundation for enterprise service-oriented architecture (enterprise SOA) and allows the

integration and alignment of people, information, and business processes across business and technology

boundaries. It utilizes open standards to enable integration with information and applications from almost

any source or technology. SAP NetWeaver is the foundation of SAP xApps and SAP Business Suite

solutions, and also powers partner solutions and customer custom-built applications.

SAP NetWeaver is provided as a general-purpose platform. Its capabilities are delivered by the following

components:

• SAP Enterprise Portal provides a complete portal infrastructure along with knowledge

management and collaboration software.

• SAP Business Intelligence makes information actionable by helping companies identify, integrate,

and analyze disparate business data from heterogeneous sources.

• SAP Master Data Management is the foundation for providing harmonized, consistent information

to heterogeneous applications across the enterprise.

• SAP Exchange Infrastructure provides open integration technologies that support process-centric

collaboration among SAP and non-SAP components both within and beyond enterprise boundaries.

• SAP Mobile Infrastructure supports multi-channel access through voice and mobile technology, so

people can stay connected to the information they need, offline or online.

• SAP Auto-ID Infrastructure provides a complete auto-ID middleware solution. It connects radio

frequency identification (RFID) data directly from auto-ID data capture sources, such as RFID

readers, and integrates the data directly into enterprise applications.

• SAP Web Application Server is a development and deployment platform that supports Web

services, business applications, and standards-based development based on key technologies such as

J2EE and ABAP™.

SAP NetWeaver also includes the following tools:

• SAP Solution Manager provides centralized management for all stages of the software life cycle,

from design to development, deployment, implementation, versioning and testing, and ongoing

operations.

• SAP Composite Application Framework provides the environment for building composite

applications and comprises design tools, methodologies, services and processes, an abstraction layer

for objects, and user interface patterns.


42/68

• SAP NetWeaver Developer Studio enables a model-driven development methodology for building

professional Web user interfaces.

The complete SAP NetWeaver stack is also visualised in Figure 20.

Figure 20: SAP NetWeaver stack

SAP NetWeaver can serve as a service oriented platform for the development and execution of the

SOCRADES middleware. This integration platform offers several components, such as the Exchange

Infrastructure, Web Application Server, Business Intelligence and the Enterprise Portal, that already provide

some of the functionality required by the SOCRADES middleware.

These components and the integration platform can be applied in order to achieve a high degree of

performance and reliability. Nevertheless, further improvements are required due to the specific

characteristics of the SOCRADES devices, such as DPWS support, event based message distribution and a

different approach to service discovery.

3.3.4 Exchange Infrastructure (XI)

The SAP XI component provides open integration technologies that enable process-centric collaboration

among SAP and non-SAP components, both within and beyond enterprises. The goal is to provide a

middleware where different enterprise applications communicate synchronously and asynchronously

through SAP XI without knowing the interfaces of possible communication partners in advance. The SAP XI

communication concept can therefore be seen as a paradigm shift from a direct peer-to-peer communication

to a hub and spoke network as depicted in Figure 21.


43/68

Figure 21: SAP XI as a hub and spoke network [10]

As a component of the SAP NetWeaver technology platform (see Figure 20), SAP XI supports business

processes that are spread across heterogeneous systems and company boundaries, providing integration at

reduced costs. This way, SAP XI removes the barriers and costs associated with integration between systems

of different companies. The solution allows for a cross-component and cross-company business process

management (BPM) and enables the development of integration scenarios based on the definition of

appropriate messaging interfaces, mappings and routing rules. SAP XI therefore provides a common central

repository for the necessary interfaces. SAP XI is based on the SAP Web Application Server (SAP Web AS)

component and a part of the process integration layer of the SAP NetWeaver stack as depicted in Figure 22.


44/68

Figure 22: SAP XI components within SAP NetWeaver [11]

The following key capabilities of SAP XI can be identified:

• Business process integration based on standards: Business processes running on distinct IT systems

can be integrated using standards-based XML messaging. The necessary information is described by

means of Web Service standards.

• Management of integration knowledge: The knowledge and data required for the integration of

heterogeneous systems is centrally stored by SAP XI. The corresponding integration definitions are

separated from the functional application coding to allow for an upgrade of functionality while the

integration definitions remain untouched. The required data types, message types, interface

descriptions, business scenarios, and process patterns are readily available for all SAP Business Suite

solutions and SAP NetWeaver components, and the integration repository can be extended to

support third-party applications.

• Cross-component business process management: SAP XI allows establishing and controlling

business processes across application and company boundaries. The integration between

heterogeneous system landscapes can be described from a top-down, high-level perspective instead

of hard-coding it into existing components. Using the appropriate adapters, virtually any application

can be connected to SAP XI.


45/68

Figure 23: Integration between smart embedded devices and enterprise applications via SAP XI

In the context of the SOCRADES project, SAP XI can be used to enable the communication between

SOCRADES middleware components and SAP as well as non-SAP systems that reside on the application

layer. For the integration of Web Service-enabled components, the SAP XI provides a standard technical

adapter, the so-called “SOAP Protocol Adapter” [12]. This adapter allows exchanging XML messages with XI

using the SOAP protocol. In addition, the SOAP Protocol Adapter, a component of the XI Adapter Engine,

supports the sending of SOAP messages with attachments, which allows attaching binary data to a SOAP

message [14]. In order to use SAP XI, a component has to create messages that the SOAP Protocol Adapter

can process. On the one hand this would allow connecting not even SOCRADES middleware components to

the Exchange Infrastructure, but also DPWS-enabled smart devices. On the other hand quantitative research

showed that the SAP XI has scalability problems when it comes to the consumption of huge amounts of

small and parallel messages [13]. This is caused by the design of SAP XI, which was built for small amounts

of large messages. A typical scenario for this is the communication of enterprise systems, while the

integration of smart embedded devices most likely leads to an increased amount of messages, which are

typically rather short like sensor data.

To prevent a flooding of SAP XI by low-level events, aggregation / filtering concepts and propagation rules

are necessary. In addition, smart devices should only communicate with the Exchange Infrastructure under

certain conditions, if at all. In an example where a smart embedded device could send a message directly to

the SAP XI, an Alert Resolution Dashboard is connected to SAP XI and consumes mission-critical alerts

raised by embedded devices. In this case a propagation of the alert through the SOCRADES middleware

might unnecessarily consume precious time while it does not provide added value. As certain data that

could be relevant to business processes running in distinct enterprise systems is not available until the

SOCRADES middleware layer added some semantics to raw device data and because the middleware can

also perform filtering and reasoning on the data, it makes sense that the SOCRADES middleware interacts


46/68

with the SAP XI in most use cases. The described integration between smart embedded devices and

enterprise applications via SAP XI is visualised in Figure 23.

4 Integration Concept

This chapter focuses on an overall architecture presenting a concept that can integrate via a service oriented

infrastructure field related data into business processes. Our motivation is derived from the integration gap

between the business level and the production control level. Existing manufacturing execution systems

(MES) and enterprise resource planning (ERP) systems are disconnected or in the best case very loosely

connected. Therefore the exchange of data between the “shop floor” and the “top floor” is done manually or

at most semi-automatically. Such exchange of data is not timely, is also error-prone, and leads to poor

information visibility and dissemination. In addition, it results in business process delays and a lower

responsiveness to problems because e.g. plant managers learn about critical issues too late. The described

integration gap is visualised in Figure 24.

Figure 24: The Integration Gap

To enable an integration of control and enterprise systems, the international standard ISA-95 is under

development by a consortium of members, knowledge partners and technology partners including for

example DuPont, SAP, ABB, Oracle, Siemens, and Rockwell. The standard consists of models and

terminology, which can be used to determine, which information has to be exchanged between enterprise

and control systems. The information is structured in UML models, which are the basis for the development

of standard interfaces between ERP and MES systems. The ISA-95 standard can be used for several

purposes, for example as a guide for the definition of user requirements, for the selection of MES suppliers

and as a basis for the development of MES systems and databases. The main objectives of ISA-95 are a

consistent terminology, consistent information models, consistent operation models, and consistent message

contents that improve the communication between enterprise and control systems, clarify application

functionality and show how information and data are used [2]. The ISA-95 standard consists of the following

five parts:

• ISA 95.00.01 Models and Terminology

o Also IEC/ISO 62264-1

• ISA 95.00.02 Object Models and Attributes


47/68

o Also IEC/ISO 62264-2

• ISA 95.00.03 Activity Models of Manufacturing Operations Management

• ISA 95.00.04 Object Models and Attributes of Manufacturing Operations Management

• ISA 95.00.05 Business to Manufacturing Transactions

The standard distinguishes between five different layers of a functional hierarchy model which are business

planning & logistics, manufacturing operations & control, and batch, continuous, or discrete control. The

model defines hierarchical levels at which decisions are made. The interface between layer 4 and layer 3 of

the hierarchy model aims at closing the integration gap between enterprise and control systems illustrated in

the previous section (see Figure 24). The ISA-95 Functional Hierarchy Model is visualised in Figure 25.

Field Devices

e.g. sensors, actuators

Field Devices

e.g. sensors, actuators

Controllers

e.g. PLC, DCS, etc

Controllers

e.g. PLC, DCS, etc

ERPERP

Quality

Quality

Production

Production

Maintenance

Maintenance

Inventory

Inventory

Layer 1: Field

Layer 2: Control

Layer 3: MES

Layer 4: ERP

Figure 25: Architecture of a complex automation system according to ISA-95 [4]

Typical automation and control systems in manufacturing are organized in a layered structure as shown in

Figure 25. The lower layers 1 and 2 contain field devices and controllers. The layer 3 contains a

manufacturing execution system (MES) which controls the manufacturing process and the underlying parts

of the manufacturing system, its core functionality being production scheduling and production workflow.

Layer 4 comprises the ERP system providing enterprise-wide functions for planning and scheduling of

resources.

It is important to understand that ISA-95 does not define a concrete implementation or any APIs for the

integration between enterprise and control systems. The idea is rather that companies can align with ISA-95

and define their implementations. ISA-95 itself focuses on terminology, models and an architectural concept

as visualized in Figure 26.


48/68

Figure 26: Scope of ISA-95 [2]

An example of a concrete implementation of the ISA-95 standard is the Business To Manufacturing Markup

Language (B2MML). B2MML is an XML implementation and consists of a set of XML schemas that

implement the data models in the ISA-95 standard. It can be used to integrate business systems such as ERP

and supply chain management systems with manufacturing systems such as control systems and

manufacturing execution systems [3]. As an example B2MML messages can be used to integrate control

systems or shop floor applications with enterprise systems as shown in Figure 27.

Figure 27: Integration of shop floor applications with enterprise systems using B2MML [5]


49/68

Figure 27 shows how the Production Planning for Process Industry (PP-PI) protocol is translated into a

B2MML production schedule message to integrate enterprise and control systems. Other examples of

exchanged data shown in Figure 27 are reports about the production performance and maintenance

requests. In this conceptual drawing, the SAP ERP system is linked to a control system using SAP

NetWeaver XI as a mediator.

Section 4.1 discusses the integration of device-level services into business applications with respect to the

requirements analysis for networked smart devices carried out in chapter 2, while section 4.2 presents three

integration patterns used for coupling devices with business applications. In section 4.3 and 4.4, the

integration of both web-service and non web-service enabled smart embedded devices into business

processes is discussed. The concluding section 4.5 provides a comprehensive approach to integrate field

related data coming from smart embedded devices into business processes based on the SOA paradigm. The

concept will show how the integration can be accomplished from a holistic perspective, while the concrete

architecture will be defined in deliverable D6.3 as part of the early integration prototyping.

4.1 Service Integration in Business Applications

One fundamental goal of the SOCRADES project is to integrate device-level services with business

applications running on the enterprise level using Web Services technology. In this context we define a

SOCRADES service as a reusable software component that encapsulates device-specific functionality and

makes it available in an interoperable and self-descriptive way over a network. It advertises this

functionality to other networked smart devices or further entities and enables them to locate and invoke the

service. Thereby the invoker is not aware of how the service functionality is implemented. A SOCRADES

service

• supports a given, well-defined functionality for the service user,

• provides a well-defined interface that the service can be called / invoked through,

• runs transparently from the user’s point of view (Black-Box),

• can be composed of several other SOCRADES services (compound service).

The service-oriented architecture (SOA) approach allows for an increased flexibility and reusability when it

comes to the provisioning of data and functionality coming from smart embedded devices. One key

advantage of using services is that functionality provided by different smart devices can be composed to

allow for more sophisticated application behaviour. The use of services is also desirable because today’s

business software is more and more built in a service-oriented way based on Web Services. Therefore the

SOA approach of the SOCRADES architecture allows for an easy integration of smart embedded devices

with business applications. A high level overview of the SOCRADES architecture is visualised in Figure 28.


50/68

Web Services communication

Figure 28: SOCRADES Architecture (high-level overview)

Figure 28 shows that the integration of services provided by smart embedded devices in business

applications can happen via different layers. First of all, smart embedded devices can offer services to

process and automation control systems, which in turn use the SOCRADES middleware to provide services

to business applications. As a second option smart embedded devices can offer their functionality to the

SOCRADES middleware, which provides the corresponding services to business applications. In the last

option devices communicate directly with business applications. On the device layer of the SOCRADES

architecture, smart embedded devices are integrated and networked using wireless and wired technologies.

They interface with a variety of process and automation control systems like SCADA or MES, which enable

the access to services offered by the devices and consume events and data coming from the devices. The

control systems, interface with a manufacturing integration component of the SOCRADES middleware layer

to allow for the eventing of data coming from the devices and the control systems themselves. In addition,

the manufacturing integration allows to route service invocations to the correct subsystems and devices. To

integrate services with business applications the SOCRADES middleware layer contains a service integration

component, which exposes Web Services to interested business applications like Event Resolution

Dashboards or Manufacturing Intelligence Dashboards and support further business processes modelling,

execution and monitoring. These SOCRADES middleware components seek to provide required

functionality to manage shop floor devices and to integrate them with back-end applications such as ERP

systems. Following this idea, one of the main goals of this project is to enable devices with DPWS. This

specification allows applications to communicate directly with devices using Web Services. Nevertheless it is

reasonable to imagine that until all devices are enabled with such specification, legacy devices would also

have to be connected to back-end systems.


51/68

4.2 Coupling devices with business applications

With respect to the integration of services into business applications, three integration patterns can be

distinguished:

• Real-Time Data,

• Relocated Process Control, and

• Distributed Process Execution.

Each pattern describes how the integration of services allows improving an existing business process and

helps bridging the integration gap. The following sections discuss the patterns in more detail.

4.2.1 Service Integration Pattern: Real-time data integration in enterprise system

Of particular interest for business applications is the access to real-time data collected by sensors that are

part of smart embedded devices. In this service integration pattern the focus lies on embedded sensors and

data is either provided to a business application via eventing or a device-level service is called to retrieve

data. From a business process perspective smart embedded devices play a more passive role in this pattern.

Typical business applications interested in real-time data are Event Resolution Dashboards that show data

related to the manufacturing process like temperature or pressure measurements. The service integration

pattern “Real-Time Data” is visualised in Figure 29, which also shows how services offered by different

devices or systems can be combined to allow for more sophisticated application behaviour.

Enterprise Software System

ServiceService

SOCRADES

Middleware

ServiceService

ServiceService

ServiceService

ServiceService

Real-time

messaging,

Events,

Alerts…

Figure 29: real-time data integration in enterprise system

4.2.2 Service Integration Pattern: Relocated Business Process Control

A second service integration pattern is the relocation of process control. In this pattern data provided by

services influences the flow of business processes running on an enterprise system. For example, at a

decision point where different subsequent process steps are possible, information provided by device-level

services can determine the flow of the corresponding business process. Since device-level services have the

potential to provide workflow-relevant decisions in this use case, they are considered to play a more active


52/68

role than in the “Real-Time Data” pattern. The service invocation pattern of “Relocated Process Control” is

visualised in Figure 30.

ServiceService

SOCRADES

Middleware

ServiceService

ServiceService

ServiceService

ServiceService

??

ServiceService

Supported Business Process

ServiceService

Figure 30: Relocated business process control

4.2.3 Service Integration Pattern: Distributed Business Process Execution

The third service integration pattern is denoted as “Distributed Process Execution”. In this pattern discrete

steps of a business process are distributed at several layers between the business layer and the device layer

and executed by a SOCRADES service.

Passive participation in Business Process Active participation in Business Process

Business Process Execution Today Business Process Execution in

an Smart Item Infrastructure

Distributed

Business

Intelligence

Internet

Service

Backend Systems

Smart Item Infrastructure

Figure 31: distributed business process execution


53/68

Although in existing business environments the devices only passively participate in a business process e.g.

they are interrogated (usually indirectly via a DCS) and their data is used to advance a business process, by

putting web services on the devices themselves we allow the business layer to directly get in contact with the

devices and outsource steps of the business process to the device itself or other intermediate layers (e.g. an

internet service) via a common approach. This allows for devices to play an active role in the business

process and provides more flexibility at the enterprise level. Putting the process execution at the place of

action (e.g. device) has profound implications that can lead to more sophisticated approaches.

4.3 Web-service enabled device integration

The integration of Web Services-enabled devices with business applications will be based on the service-

oriented approach outlined in section 4.1. The overall service-oriented architecture proposed by SOCRADES

is shown in Figure 32.

GatewayGateway

Field busProcessProcess

ControllerController

DeviceDevice DeviceDevice

Peer-to-peer

Real-time

messaging

Peer-to-peer

Real-time

messaging

Composite

device

Composite

deviceIndustrial

PC

Industrial

PC

Control

Supervision

Control

SupervisionMaintenance

Management

Maintenance

ManagementManufacturing

Business

Manufacturing

Business

Device layer

Composition layer

Application layer

Web services

Eventing

Dynamic

deployment

Discovery

& Metadata

Agent-based

control

Orchestration

Resource

management

Security

Reliable

messaging

Real-time

extensions

Semantic

Web services

Real-time

control

Configuration

Data access

Configuration

Work orders

Alarms

Data accessConfiguration

Work orders

Alarms

Data access

SOCRADES

infrastructure

Figure 32: SOCRADES service-oriented layered approach

In this architecture, the following features are most relevant to business integration:

• Web services and eventing support at the device level: this support is the prerequisite that will allow

devices and business applications to communicate.

• Dynamic deployment: this allows new services to be deployed on devices, hence favouring the

adaptation of the system to new business requirements.

• Resource management: the definition of a common protocol and a common resource model to access,

describe and manage the devices will ease the homogeneous access to a wide range of devices from the

business application.


54/68

• Secure and reliable messaging: value-added protocols will be used to secure and guarantee the delivery

of messages exchanged between devices and business applications, thus meeting typical requirements of

business applications.

In order to support the above list of features, the existing DPWS stack will need to be extended with

additional capabilities, as shown in Figure 33.

Platform (OS/Java)

IP v4/v6

UDP TCP HTTP



WS-Metadata

Native hosted services

Extensibility

WS-Security

Dynamic deployment

WS-Management

OPC UA

Code

generation

…

Service interpreters

Interpreted

hosted services

IEC 61131 languages

Orchestration languages

Scripting languages

…

Native code

(C, Java…)

WS-ReliableMessaging

Figure 33: SOCRADES web service stack

The main extensions include:

• Addition of an extensibility mechanism to the existing stack to allow new functionalities and protocols,

such as the ones mentioned below, to be seamlessly integrated.

• Support of dynamic deployment of interpreted services. This will require both the addition of a dynamic

deployment service, as well as the integration of one or several service interpreters in the stack.

• Support for WS-Management, or a similar protocol providing access to the device and service resources.

If WS-Management is selected, this will require some extensions to WS-Eventing, in order to support all

the event delivery modes required by WS-Management.

• Support for WS-Security, and if required for WS-ReliableMessaging.

4.4 Non web-service enabled device integration

The equipment used in production systems is often in long-term use. Therefore legacy devices must be

included into business processes. The most likely network structure will be a heterogeneous one, even if the

SOCRADES project becomes very successful and all devices manufactured in the future will include the

defined SOCRADES communication stack. Such integration may be done in principle by using gateway

solutions. A gateway transforms between network protocols unlike routers which tunnel lower protocols

only. It is also possible that one service from network 1 to network 2 causes more than one service to be

initiated by the gateway. Thus a gateway may contain a transformation rule interpretation engine in

combination with a workflow engine.


55/68

network 2

gateway (adapter)

network 1

address translation

protocol transformation

service content transformation

limited workflow organisation

Figure 34: Network transition via gateway solutions

According to the SOCRADES communication framework, the non Web-service enabled devices will reside

in one network and all SOCRADES aware applications will be situated in another network. A gateway

solution will then adapt information content of the device network to the SOCRADES network. Figure 35

shows a SOCRADES adapter in more details.

Device

Communication

Interface1

Device

Communication

Interface 2

Device

Communication

Interface 3

Common adapter

(implementation/transformation of logics and workflows)

SOCRADES communication interface

(SOCRADES protocol stack)

SOCRADES network / middleware

device

network1

device

network2

device

network4

SOCRADES

device adapter

device device device device device

device device device device device device device device device device

field gateway

device

network3

device device device device device

device

proxy

device

proxy

device

proxy

device

proxy

device

proxy

device

proxy...

- each field device is represented

by a device proxy

- additional proxies may represent

virtual higher-order devices like

machines or plants, which aggregate

devices

- each proxy communicates via

SOCRADES protocol stacks

- device access is done via

field bus interfaces

or direct digital / analog IO

Figure 35: SOCRADES device adapter

Of course the adapter will contain a SOCRADES communication interface. This interface will include a

protocol stack to be defined in scope of the project. This means that it has to be implemented only once and

will be shared among the project partners. In future it has to be implemented once per manufacturer of

appropriate device adapters.


56/68

Devices reside on the other side of the adapter. The adapter communicates with them by using device

communication interfaces. If for example the adapter is PC based, then the device communication interface

will consist of communication hardware, hardware drivers for the operating system and possibly

intermediate client-server systems, like the widely used OPC server technology. The device communication

interface has to solve additional semantic transformation, which includes data type conversion and

parameter renaming. This is usually necessary since the device networks are not all of the same type (e.g.

various field bus systems like PROFIBUS, MODBUS, FF ... or Ethernet based communication). The field bus

organisations have defined parameter sets for devices (device profiles), which differ in syntax and semantics.

But not all devices are equipped with modern communication systems. They usually provide only process

values and in best case a limited set of binary diagnosis signals. They are either directly connected to the

adapter hardware or are integrated via field gateways. Examples for such gateways are PLC systems with

network connections to the adapter but digital or analogue interfaces to the devices. Another kind of field

gateways are those which enable crossover communication between different kinds of field bus systems.

The core of the adapter is a common adapter system, which transforms semantics of the devices to fit the use

cases defined in scope of the project. Each field device, which has to be adapted, is represented by a device

proxy. There is the possibility to implement virtual devices, which represent summary information of

aggregated devices. For example a machine is a composition of single devices - the machine may therefore

be represented as a virtual device proxy, which sends an alert if one of the composed devices indicates an

error. A special kind of a SOCRADES gateway will be a gateway, which adapts a single device to the

SOCRADES middleware. It could be used to make a legacy device SOCRADES aware.

If we consider predictive maintenance for example, then this common adapter would include state

monitoring units, prediction units and event generation systems. Therefore it possibly includes databases for

process value histories and appropriate scheduling rules. But also more simple applications have to be

supported. Some business processes will need device type information in a standardized manner. The

adapter could then identify the device type either by introspection of the devices or by lookup in a network

address table and deliver the appropriate type information to the SOCRADES business process. The same

could be done with instance information.

4.5 Integration architecture

This section discusses an approach for the integration of smart embedded devices with business applications

running at the enterprise level. It shows which of the technologies from chapter 3 are combined to enable a

service-oriented cross-layer infrastructure for distributed smart embedded devices. The integration involves

two main areas:

• Device Level Integration: The integration approach on a device level is based on the technologies

presented in section 3.2.

• Business Level Integration: The integration approach on a business level is based on the

technologies presented in section 3.3.

In the following both integration areas are described briefly followed by the presentation of a detailed and

comprehensive integration approach.

At the device level, integration is based on a layered approach (Figure 36):

• At the bottom layer, all devices are assumed to be connected to an IP-capable network. Devices that

are not should be encapsulated by a gateway.

• The next layer includes the standard Web Services (SOAP) and the DPWS extensions, such as WS-

Addressing, WS-Eventing and WS-Discovery. This layer allows all devices to be reached through the


57/68

standard Web Services protocols. In this case also, devices that cannot host the DPWS stack should

be encapsulated by gateways.

• The third layer provides support for optional protocols, such as WS-Security and WS-

ReliableMessaging. While those protocols may not be always necessary, they are likely to be useful

in many real-world situations.

• The fourth layer provides the integration services that will allow business applications to interact

with the device level.

Extensibility

Platform (OS/Java)

IP v4/v6

UDP TCP HTTP



WS-Metadata

Ad-hoc servicesWS-Management

+ Resource modelOPC UA

WS-Security, WS-ReliableMessaging

Integration

extensions

Business applications

Application server

Figure 36: Device Level Integration

The integration services could be of three different types:

• Ad-hoc services: All devices provide a set of services exposing their functionalities. In many cases,

these services provide either direct or indirect access to most device state variables. Additional

services could also be specifically defined for integration purposes, providing access to additional

information not exposed by existing services. The main drawback of this approach is its complete

lack of standardization, which imposes on the business applications the burden to understand the

specific Web Services interface used by each different device type.

• WS-Management services: WS-Management services support resource creation, access,

modification and deletion through a simple set of Web Services. In many cases, these services will

provide enough capabilities to support integration with business applications. However, an

important aspect must be considered before WS-Management can be used as an integration

technology: the definition of an appropriate and generic resource model, rich enough to support the

representation of a wide variety of devices. In addition, the exclusive use of resources to model

devices from the integration perspective may be considered as a breach of encapsulation, and could

thus create unnecessary dependencies between devices and business applications.

• OPC UA services: OPC UA provides another simple set of Web Services to access and modify

resources, usually modelled as a set of related variables. The advantage of OPC UA over WS-

Management is in its existing resource model, which has been used quite extensively for modelling

automation applications. The drawbacks of the technology could be its perceived lack of generality

compared to WS-Management (which is totally domain-independent), as well as some limitations in


58/68

the modelling of complex devices through plain variables. As for WS-Management, use of variables

for modelling devices may also be considered as a breach of encapsulation, and therefore not

consistent with SOA best practices.

While the first option is certainly the simplest to implement in the short term, as well as the most compatible

with the SOA philosophy of implementation encapsulation through services, it could create many

difficulties from the business applications point of view, as it requires a specific adaptation (for instance

through scripting) for each new device type to be integrated. The two other approaches have the advantage

of using simple and standard communication protocols, although the business applications will still need to

be able to cope with the various resources exposed by devices through those protocols. The choice of the

approach for the SOCRADES project is still under discussion.

For the business level integration the SAP xApp Manufacturing Integration and Intelligence (xMII) and the

SAP Exchange Infrastructure (XI) are used to connect the plant floor with enterprise systems. The services

offered on the device layer can be integrated with SAP xMII, which is described in detail in section 3.3.2. The

manufacturing integration component of SAP xMII allows for an integration with control systems like a

manufacturing execution system (MES) by means of pre-packaged connectors. The manufacturing

intelligence component of xMII feeds data to Manufacturing Intelligence Dashboards, the SAP BI or other

SAP business solutions. In addition, it interfaces with the SAP XI, which was introduced in section 3.3.4. The

combination of SAP XI and SAP xMII connects the SAP ERP solution to the plant floor in (near) real-time

and extends the functionality of the SAP NetWeaver platform. The business level integration approach is

visualised in Figure 37.

Figure 37: Business Level Integration

The following sections combine the integration areas of device and business level into a detailed and

comprehensive integration approach. Figure 38 presents the SOCRADES architecture where three types of

devices are connected to the back-end system:

• DPWS enabled devices,


59/68

• DPWS Gateway enabled, and

• Legacy devices (no support to DPWS).

The layout of the current architecture design comprises five main layers: the application layer, the business

and execution system layer, the enterprise services layer, the middleware layer, and the device layer. The

middleware layer itself is further divided into two sub-layers, one system management layer and one device

abstraction layer.

The layers comprise the following components:

• Application layer: Business and management applications, and external clients accessing services

running on the devices.

• Business and execution system layer: Business Process Execution Engine, Business Process Monitor.

• Enterprise services layer: All the additional services that run in the back-end and that offer

additional functionality to the system.

• Middleware layer: In the system management sub-layer: Service Lifecycle Management, Service

Mapper, Service Repository, Device Monitor, Device Manager, Service Discovery and Integration,

Logging and Tracing. In the device abstraction sub-layer: Proxy Pool (incorporating dynamically

generated web service proxies), Connector Dispatcher, Eventing, Pull Point, Legacy Systems

Connectors and Invoker.

• Device layer: Embedded devices.

The system management sub-layer of the architecture consists of all the components that are independent of

the underlying hardware platforms. Most of these components offer their functionality to the above layers

using a web service interface. These components are described in more detail in the following subsections.

The device abstraction sub-layer contains all the components required for supporting legacy devices. Their

core functionality comprises the conversion of messages into the platform-specific format, support to

occasionally connected devices, and the propagation of events generated in the shop floor.


60/68

Gateway

DPWSDPWS

Legacy Systems Connector

Invoker

Synchronous

Request

Processor

Asynchronous

Buff

Service Lifecycle

Management

Connector Dispatcher

Pull Point

Services

Repository

Service

Mapper

Device Manger

Service Discovery

and Integration

Device Abstraction

Layer Eventing

Notification

Broker

Management Interface

Alert Resolution

Dashboard

Process Efficiency and

Risk Analysis DashboardBusiness Process

Modeling

System Management

Layer

Device Monitor

Logging &

Tracing

SOCRADES MIDDLEWARE

Proxy Pool

Service

ProxyServiceProxy

Service

Proxy

Enterprise Services Service

ProxyServiceService

Service

ProxyServiceService

Service

ProxyServiceService

Service

ProxyServiceService

Business and Execution System Layer

Business Process MonitoringAlert

Web Services communicatio

n

Application

Layer

Composition

Layer

Device

Layer

DPWS

Controller

Controller

Figure 38: SOCRADES Architecture

4.5.1 Device Abstraction Layer

To connect all the devices present in the shop floor with enterprise applications in a transparent way, the

middleware proposed makes use of a device abstraction layer. This layer provides the required components

for invoking services operations in a synchronous or asynchronous way, propagating events and connecting

to different device protocols.

Synchronous invocations mean that applications would expect an immediate response from the device, in

case that the device cannot respond, the invocation would fail returning an error. This is mostly applicable

for permanently connected devices. Asynchronous invocations give support to occasionally connected

devices; for the latter, the application would submit a request to the middleware and request the response

periodically until it becomes available. The middleware then takes the responsibility to communicate with

the device when it is reconnected.

The abstraction from the protocol used by the devices is achieved by implementing a connector. A connector

is a component that translates back-end requests (web services) into the device specific protocol. The same is


61/68

true for transforming the events coming from the devices into a standardized event that the enterprise

applications can comprehend. This connector is only necessary for legacy systems given that DPWS devices

already support web services.

To provide a complete web service support to legacy systems, the middleware proposes a proxy pool where

a set of web services proxies implement the interface of the services that are provided by the legacy systems.

The function of these proxies is to allow back-end applications to access the functionalities present in the

legacy systems via web services. This component achieves that by forwarding the requests it receives to the

Invoker using either synchronous invocations or asynchronous. Finally, the invoker forwards the requests to

the Connector Dispatcher that selects the appropriate Legacy Systems Connector and performs the invocations.

It is simple to realize the improvements that the adoption of DPWS by all devices would provide: there

would be no need to have components to support legacy systems given that all devices are web services

enabled by default.

Also in the Device Abstraction Layer two additional components are responsible for handling events

propagated from the shop floor: Notification Broker and Pull Point. These components are inspired by the WS-

Brokered Notification [9], the former manages subscriptions and propagates events directly to the

consumers and the later provides the alternative for applications that do not support web services to retrieve

their events periodically from a component.

4.5.2 System Management Layer

On top of the Device Abstraction Layer is the System Management Layer. This layer provides additional services

that enable the management of the shop floor. Service Life Cycle Management is one of the additional

functionalities that this layer brings. By storing a description of the services into the Service Repository a

component called Service Mapper can identify the requirements of a given service and the available

implementations. With this information it is possible to automatically identify the devices that should run a

given service or automatically update the services as soon as a newer version is available. Removing,

stopping and resuming services are also functionalities that the Service Life Cycle Management provides.

Another important functionality that this layer brings is the ability of identifying the current status of the

network, the devices that are available and their capabilities and all the events, errors and warnings that

were triggered by the system. These functionalities are provided by several components that together offer a

broad possibility to analyze from a more technical perspective the current situation of the shop floor. The

components that support these functionalities are: Device Manager, Device Monitor and Logging & Tracing

respectively.

We also foresee that given the amount of service that would be available in a company an efficient way of

discovering the available services would be necessary. DPWS offers mechanisms that overcome this

challenge. Nevertheless, given that legacy systems might also be present additional mechanisms that unify

these technologies will be required.

4.5.3 Enterprise Services

On top of the SOCRADES middleware we envision that several services will be available to give support to

enterprise applications. One of these services is the Maintenance Control. This service contains a history of all

the activities performed on a machine either for maintenance or production. Based on this information and a

set of rules, this service can assert when the next maintenance will take place. Additional techniques can also

improve maintenance control, for instance, based on sensor readings this service can predict machine break

downs. Maintenance Control is one example of the services that can be available on the back-end, other

examples are mentioned in Chapter 1 (Business Scenarios).


62/68

4.5.4 Business and Execution System Layer

In this layer the business process is executed and monitored. The business process execution consists in

orchestrating the services that are used. These services can run either in the back-end or on the shop floor

devices. Given that the SOCRADES middleware together with DPWS provide a transparent integration of

the devices with the back-end systems, the monitoring and execution of processes using only web services

become possible.

During the modelling of business processes, milestones are defined that indicate stages and rules that the

system must achieve to be considered correct. The Business Process Monitoring is responsible for analyzing

these milestones and generating alerts in case that an irregular situation is encountered. These alerts can be

distributed to several applications including the Alert Resolution Dashboard.

4.5.5 Application Layer

The supervision of the shop floor is made through management applications that are placed on the top layer

of the system. These applications include Risk Analysis and Process Efficiency Dashboard, Alert Resolution

Dashboard and Business Process Modelling tools.

The Risk Analysis and Process Efficiency Dashboard analyzes the current situation of the processes indicating

performance issues and providing input regarding risk evaluation.

The Alert Resolution Dashboard receives events generated in the lower layer of the system and presents it to

the process supervisor guiding him through the process of solving the situation. In a machine breakdown

situation this dashboard gives the detailed information of the machine, guides the user through the process

of requesting appropriate maintenance and also trough the process of requesting a review of the ERP taking

into consideration the amount of hours that the machine will be unavailable.

Finally with the Business Process Modelling tools, process engineers indicate how their processes interact in

order to produce the desired output. They also indicate additional analysis that must be performed during

the process to ensure that the output is in accordance with the specifications. Once the process is defined it is

partially deployed to the shop floor and partially deployed into the Business and Execution System Layer.

5 Demonstration Facility

To study the applicability of SOCRADES research results in the field of mechatronics and robotics APS

intends to develop and implement a “mechatronic trial site” with an integrated open SOA–based IT

infrastructure. The “site” will be used as a platform to test, evaluate and demonstrate the interoperability of

smart networked mechatronic devices and systems based on embedded service-driven functionality. This

will include for example plug & play, self organization, reconfiguration and monitoring capabilities as well

as functionality for collaborative automation and control.

Basic hardware components of the trial site are heterogeneous mechatronic systems and devices. Envisaged

is to integrate robots of different type, process- and positioning sensors for local and global sensing tasks,

RFID systems, tools, as well as peripheral equipment, safety guards, and selected work pieces. As a special

option it is planned to integrate also mobile objects into the SOA-based IT infrastructure. In this context

consideration will be especially given to human interaction inside the test scenarios as indicated in depicted

in Figure 39.


63/68

Tools

SensorsRobot

Robot

Cognitive

Control

Event

Broker

Reconfig.

Tool

Monitoring

Tool

Service

Manager

Planning &

SimulationServices

Operator

Parts

Machines

Parts

RFID

RFID

Appl. Platform: Device-Level

Appl. Platform:

Enterprise-Level

Figure 39: Mechatronic Trial Site

The SOCRADES test facilities at APS will be capable of modelling and simulating business processes and

manufacturing automation scenarios and situations close to reality by building application-oriented

reconfigurable clusters of:

• networked machines, mechatronic devices and cooperating systems,

• application-oriented sensor infrastructures,

• ad-hoc networks,

• and human-machine collaboration.

Heart of the APS test site will be a new IT-based communication and control infrastructure which is built up

from the SOCRADES service-oriented networking paradigm with cross-layer capabilities by means of web

services. In this context it is envisaged to combine both wired as well as wireless networking technologies as

enabling technologies to assist in supervision and collaborative control activities on device level but also to

support communication and information exchange with selected business processes. This can include for

instance real-time data acquisition from process sensors or machine aggregates with embedded sensing

capabilities to enable process monitoring, quality supervision, diagnostic services, failure prevention,

maintenance, event and safety management, or work flow control.

The link between device level, application level, and business process level will be provided by appropriate

middleware solutions based on tools that enable the routing of service invocations, the access to services

offered, and the use of services with encapsulated data and information provided by the various devices. To

cope with the web service paradigm inside the mechatronic trial site, robots, tools, sensors and other

mechatronic systems involved in selected trials are engaged to DPWS as shown in Figure 40.


64/68

Device

Control

Device

Control

Device

Control

Device

Control

Device

Control

Device

Server

Device

Server

Device

Server

Device

Server

Device

Server

DPWS DPWS DPWS DPWS DPWS

Middleware

Business Process and Execution Layer

Application 1 Application 2 Application 3

Application Execution Layer

Mobile

Terminal

DPWS

Web serv

ice based

inform

ation flo

w

Wired

/wireless co

mmunicatio

n In

frastructu

re

Figure 40: Architecture of the SOCRADES Mechatronic Trial Site

On the device level DPWS will support the description and exchange of services to enable mechatronic

devices to be discovered by the others and to interact and collaborate with them across a network in

accordance to a certain application. To run configured or reconfigured applications in parallel, DPWS will

also serve to exchange services with a device-application and execution layer and to support the integration

of device level services with business processes running on the enterprise level.

As most of the device controllers – especially those of robots and complex sensors - are controllable

externally only by means of proprietary communication protocols, device-specific modules e.g. will be

introduced to enable networking and interaction via DPWS.

As Figure 40 shows the mechatronic trial site is open to test SOCRADES results with a changing focus. Trials

can be performed in accordance to applications on device level like for instance the sensor/actuator

interaction or the collaboration of cooperating robots and mechatronic devices. Alternatively, the

architecture of the mechatronic trial site is also designed and prepared to work and run tests in the cross-

layer domain.

In this context special opportunities will be available to run trials on basis of simulated business processes.

Here two options are to consider. The first option is to interact with robots and mechatronic devices on

device level via the APS enterprise network. The second option is to be invoked from distributed external

run time platforms through web services via Internet as illustrated in Figure 41.


65/68

Figure 41: Remote access over VPN to the mechatronic trials

Apart from the presence at the APS labs, the web service approach via internet enables opportunities to run

also tests from the outside. They can be related for example to remote control, remote services, or remote

computing applications.

The communication infrastructure provided to run the mechatronic trial site is not yet specified and open to

the demands of the SOCRADES users. However, Ethernet, WLAN, ZigBee , and NanoNet are planned to be

implemented as basic elements of the infrastructure. To communicate and control the trials from outside via

Internet we intent to provide VPN (already installed in APS facilities) access; as with it secure access over the

Internet in a cost-effective way can be realised. This offers global networking opportunities and enables

numerous opportunities for SOCRADES partners to participate and benefit from the mechatronic trials.

6 Conclusions

In this document our aim was to investigate the integration of smart devices with the business processes. In

order to do that, we have taken a look on business domains that would benefit from such integration such as

Business Activity Monitoring. Mobile Equipment Assistance, Maintenance Optimization, Overall Equipment

Effectiveness (OEE), Customized manufacturing with late order freeze, and Automotive Domain / Remote

Systems. Based on these we have derived the requirements for distributed smart devices that are needed to

support this infrastructure. Subsequently we focused on technologies that can/will be used to realise the

integration of the devices in business processes, as well as on commercial products that will be used to

demonstrate this feasibility in real-world. Finally and most importantly we have designed an integration

architecture that takes into consideration requirements from all levels and will be used to realise the

SOCRADES concepts e.g. the integration of both web-service and non web-service enabled devices.

Future work will be to further design the proposed integration architecture, check its feasibility by

implementing parts of it and testing it in real-world environments. More specifically, in the next months we

plan to expand the integration concept of non-web service enabled devices in order to allow easy migration

from legacy infrastructures and further refine the web-service enabled device integration. We will focus on

detail in the information model that will effectively support this infrastructure.


66/68

7 References

[1] Georg E. Paulusberger, July 2004, BPEL-Editor,

http://suntrec.salzburgresearch.at/projects/bpeleditor.pdf

[2] Bob Mick, November 2003, Getting Started with ANSI/ISA-95 ISO/IEC 62246, http://www.isa-

95.com/downloads/Engels/Getting_started.PDF

[3] WBF, August 2005, B2MML V03 XML Schemas and Documentation,

http://www.wbf.org/associations/2718/files/B2MML-V03-ProductDefinition.doc

[4] ISA, July 200, ANSI/ISA–95.00.01–2000,

http://www.isa.org/Template.cfm?Section=Buy_Standards&template=/Ecommerce/ProductDisplay.c

fm&ProductID=2612

[5] SAP AG, 2006, ANSI/ISA-95 Support in SAP ERP in SAP Manufacturing,

http://www7.sap.com/usa/solutions/business-suite/erp/operations/pdf/ANSI_ISA_95.pdf

[6] Common Alerting Protocol, v. 1.1. April 28, 2005, http://www.oasis-

open.org/committees/download.php/12649/CAPv1-1.pdf

[7] Emergency Data Exchange Language (EDXL), http://xml.coverpages.org/edxl.html

[8] Organization for the Advancement of Structured Information Standards (OASIS), http://www.oasis-

open.org

[9] OASIS Web Services Notification TC, http://www.oasis-open.org/committees/wsn/charter.php

[10] iWay Software, 2007, Solutions for SAP Exchange Infrastructure (XI) Integration,

http://www.iwaysoftware.com/products/sap/images/sapnetweaver2.jpg.

[11] SAP AG, 2006, SAP Exchange Infrastructure,

http://help.sap.com/saphelp_nw04/helpdata/en/0f/80243b4a66ae0ce10000000a11402f/content.htm.

[12] SAP AG, 2007, Components & Tools of SAP NetWeaver: SAP NetWeaver Exchange Infrastructure

Partner Adapters, http://www.sap.com/platform/netweaver/components/xiadapters.epx.

[13] Ulf Brackmann, April 2006, Integration of Ubiquitous Technologies in Enterprise Software Systems.

[14] W3C Note, November 2000, SOAP Messages with Attachments, http://www.w3.org/TR/SOAP-

attachments.

[15] Services Infrastructure for Realtime Embedded Network Applications (SIRENA) Project,

http://www.sirena-itea.org

8 Terms used

Abbreviation Explanation

xMII SAP xApp Manufacturing Integration and Intelligence

xApp Composite Application built on SAP NetWeaver

BAM Business Activity Monitoring

PLM Product Lifecycle Management

XML eXtensible Markapu Language

ROI Return of Investment


67/68

MES Manufacturing Execution System

KPI Key Performance Indicator

ERP Enterprise Resource Planning

DCS Distributed Control System

CRM Customer Relationship Management

BI Business Intelligence

XI SAP Exchange Infrastructure


68/68

9 Appendix

9.1 Licences

The images from the SCA specification (available under http://www.osoa.org/download/abttachments/35/

SCA_AssemblyModel_V096.pdf) are copied according to the following licence:

BEA, Cape Clear, IBM, Interface21, IONA, Oracle, Primeton, Progress Software, Red Hat, Rogue Wave, SAP,

Software AG., Sybase, TIBCO (collectively, the “Authors”) agree to grant you a royaltyfree license, under

reasonable, non-discriminatory terms and conditions to patents that they deem necessary to implement the

Service Component Architecture Specification.

THE Service Component Architecture SPECIFICATION IS PROVIDED "AS IS," AND THE AUTHORS

MAKE NO REPRESENTATIONS OR WARRANTIES, EXPRESS OR IMPLIED, REGARDING THIS

SPECIFICATION AND THE IMPLEMENTATION OF ITS CONTENTS, INCLUDING, BUT NOT LIMITED

TO, WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, NON-

INFRINGEMENT OR TITLE.

THE AUTHORS WILL NOT BE LIABLE FOR ANY DIRECT, INDIRECT, SPECIAL, INCIDENTAL

ORCONSEQUENTIAL DAMAGES ARISING OUT OF OR RELATING TO ANY USE OR DISTRIBUTION

OF THE Service Components Architecture SPECIFICATION.

The name and trademarks of the Authors may NOT be used in any manner, including advertising or

publicity pertaining to the Service Component Architecture Specification or its contents without specific,

written prior permission. Title to copyright in the Service Component Architecture Specification will at all

times remain with the Authors.

No other rights are granted by implication, estoppel or otherwise.

The images from the WSBPEL specification (available under http://www.oasis-

open.org/committees/document.php?document_id=18714&wg_abbrev=wsbpel) are copied according to the

following licence:

This document and translations of it may be copied and furnished to others, and derivative works that

comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and

distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice

and this paragraph are included on all such copies and derivative works. However, this document itself may

not be modified in any way, such as by removing the copyright notice or references to OASIS, except as

needed for the purpose of developing OASIS specifications, in which case the procedures for copyrights

defined in the OASIS Intellectual Property Rights document must be followed, or as required to translate it

into languages other than English.

deliverable d6.1 service integration concept for field ... · d6.1 service integration concept for...

Documents