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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into 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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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,
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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: .
D6.1 Service integration concept for field related data into business processes
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:
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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:
D6.1 Service integration concept for field related data into business processes
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:
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
Hosted service• Physical address
• Service description
• Service
implementation
Hosted service• Physical address
• Service description
• 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
D6.1 Service integration concept for field related data into business processes
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:
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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)
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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]
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
SOAP 1.2, WS-Addressing
Service Invocation EventingWS-Discovery
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
SOAP 1.2, WS-Addressing
Service Invocation EventingWS-Discovery
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
D6.1 Service integration concept for field related data into business processes
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,
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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).
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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.
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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
D6.1 Service integration concept for field related data into business processes
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.