Programme

Factories of the Future PPP

Strategic Objective

ICT-2010-10 Smart Factories: ICT for agile and

environmentally friendly manufacturing

Project Title

Production Logistics And Sustainability Cockpit

Acronym

PLANTCockpit

Project #

260018

TECHNICAL REPORT - EXTERNAL

INTERFACE SPECIFICATION, FIRST DRAFT

Work Package
Lead Partner

WP4 System Interfaces and Integration Logic

TUD

Contributing Partner(s)

SAP, TECNALIA, TUT, ICONICS, INTEL

Security Classification

Public

Date
Version

13/04/2012
1.0

The PLANTCockpit project (260018) is co-funded by the European Union

under the Information and Communication Technologies (ICT) theme of
the 7th Framework Programme for R&D (FP7).
This document does not represent the opinion of the European
Community, and the European Community is not responsible for any use
that might be made of its content.

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Table of Contents

EXECUTIVE SUMMARY ............................................................................................ 1

INTRODUCTION ........................................................................................................ 2

PLANTCOCKPIT SYSTEM CONNECTOR LAYER ................................................... 3

ADAPTERS FOR PLANTCOCKPIT........................................................................... 5

4.1
ADAPTER TYPES FOR PLANTCOCKPIT................................................................................... 6
4.1.1 SAP ERP / BAPI............................................................................................................. 6
4.1.2 Business Objects............................................................................................................ 7
4.1.3 SAP BW / BEx Queries................................................................................................... 9
4.1.4 Web Service ................................................................................................................. 12
4.1.5 DPWS .......................................................................................................................... 13
4.1.6 MS Excel ...................................................................................................................... 18
4.1.7 MS Project ................................................................................................................... 19
4.1.8 OPC Unified Architecture.............................................................................................. 21
4.1.9 SQL.............................................................................................................................. 23
4.2

ADAPTER ROLES ................................................................................................................ 26

4.3

NON-FUNCTIONAL PROPERTIES OF ADAPTERS ....................................................................... 26

ABSTRACT INTERFACE SPECIFICATION OF THE PLANTCOCKPIT ADAPTERS

28

ABBREVIATIONS .................................................................................................... 32

CONCLUSION ......................................................................................................... 34

REFERENCES ......................................................................................................... 35

ANNEX ..................................................................................................................... 36
9.1
INTERFACE DEFINITION LANGUAGES ..................................................................................... 36
9.1.1 OMG IDL ...................................................................................................................... 36
9.1.2 Microsoft Interface Definition Language (MIDL) ............................................................ 37
9.1.3 XPIDL .......................................................................................................................... 37
9.1.4 Apache Thrift ................................................................................................................ 37
9.1.5 Apache Etch ................................................................................................................. 38
9.1.6 Apache Avro................................................................................................................. 38
9.1.7 WSDL .......................................................................................................................... 39
9.1.8 Interface Description Language (IDL)............................................................................ 41
9.2

PLANTCockpit

COMPARISON TABLE OF INTERFACE DEFINITION LANGUAGES .................................................. 42

ii

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Table of Figures
Figure 1: The System Connector Layer of PLANTCockpit .................................................................. 3
Figure 2 Adapters as function blocks in the PLANTCockpit Function Engine ...................................... 4
Figure 3 Adapter Types and Adapter Roles in PLANTCockpit ............................................................ 5
Figure 4: Layers of an SAP Business Object comp. (SAP, 2012)........................................................ 7
Figure 5: Analyzing info cubes comp. (SAP, 2012) ........................................................................... 11
Figure 6 SOAP Envelope (Mitra & Lafon, 2007) ............................................................................... 13
Figure 7: Arrangement of DPWS Clients, Devices, and Services (Lastra & Delamer, 2006) .............. 14
Figure 8: Network Protocols and Specifications included in the Devices Profile for Web Services
(Microsoft, 2009) ............................................................................................................................. 15
Figure 9: OPC UA Stacked Architecture........................................................................................... 23
Figure 10: The PL/SQL Engine and the Oracle Database Server (Oracle, 2005) .............................. 25
Figure 11 PLANTCockpit adapters as function blocks ...................................................................... 28
Figure 12 The interfaces of the PLANTCockpit adapter .................................................................... 29
Figure 13: WSDL 1.1 and 2.0 Document Structure (Cristcost, 2007) ............................................... 40

Table of Tables
Table 1: Specifications in the Devices Profile for Web Services........................................................ 15
Table 4 IIdentification interface descriptions ..................................................................................... 29
Table 5 IConfiguration interface descriptions.................................................................................... 30
Table 6 IRuntimeData interface description ...................................................................................... 31
Table 7 Abbreviations ...................................................................................................................... 32
Table 8: Structure of WSDL 1.1 and WSDL 2.0 files......................................................................... 40
Table 9 Comparison of Interface definition languages ...................................................................... 43

PLANTCockpit

iii

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

1 Executive Summary
This document describes the first draft of the external interfaces of PLANTCockpit. The
concept of adapters is introduced. Target technologies for external systems and resulting
interfaces to these systems are identified. The interfaces to the target technologies are
defined as the adapters type, whereas the interface exposed inside the PLANTCockpit
system is assigned an adapter role. A set of interfaces of the adapters of PLANTCockpit is
given. These interfaces are to be used in an upcoming reference implementation of a
PLANTCockpit adapter. The annex contains an analysis of interface definition languages
and an example on mapping of external data sources to PLANTCockpit data structures.

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

2 Introduction
PLANTCockpit aims at providing shop floor awareness and visibility for the European
manufacturing and process industry. The project will not only provide strong use cases
which illustrate this goal through the participating industry partners, it will also show a
generic approach for usage in European industries. It is expected that the project will
leverage new approaches and innovations for data accessibility and visualisation in the
industrial domain.
When shop floor and production logistics information should be visualised, it first needs to be
made available. Industrial communication systems are still rife with heterogeneous, insular
data processing solutions. However, the demand for lean, high performance, high availability
production processes and the advent of classic IT technologies on shop floors has led to an
abundance of interfaces. Whilst this abundance is preferable to the insular situation
engineers were faced with before it does have its own complications however.
An abundance of interfaces means that integration efforts become more complicated to the
square. State of the art reflects the fact that interface integration is a time-consuming and
work-intensive process. This means whenever an end user of industrial communication
systems wants to integrate a solution with a new interface, he has to customize its
integration with all his other systems. When information from many different systems is
called for, as it is in PLANTCockpit, an effort to make this situation manageable is of
undisputed worth.
The PLANTCockpit deliverable D3.1 has addressed the challenge the PLANTCockpit
architecture faces when connecting to other systems by introducing an external system
connector layer. Work package 4 of the project is tasked with filling out this layer, providing
an in depth description of components along with prototypical implementations. The first
obstacle tackled when connecting external systems to the PLANTCockpit are the interfaces
provided on both ends. This deliverable discusses the interfaces encountered and offers a
specification. Based on this specification, implementation for data adapters for the prototype
work packages can be started. Further efforts are needed in order to make sure that not
merely data, but information is properly processed from the external systems in to the
PLANTCockpit system. The goal of minimising the manual configuration effort for this task
will be handled in D4.2 mapping and transformation framework, accompanied by an update
on the definitions provided in this deliverable to be found in D4.3 Final external interface
specification. For reference, a table of abbreviations is given in Annex 6.

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

3 PLANTCockpit System Connector Layer

The overall PLANTCockpit architecture has been described in the previously submitted
deliverable document D3.1. However, some aspects of the System Connector Layer and the
decisions leading to its design will be of relevance for this document and are elaborated
here.
Inside the PLANTCockpit architecture, a whole layer of components is dedicated to providing
connectivity to the various external systems that PLANTCockpit needs to access. This
System Connector Layer has three types of components defined. The layout of these
components, which has been described in D3.1, is illustrated in Figure 1.

Figure 1: The System Connector Layer of PLANTCockpit

The Mapping and Transformation component is not focussed on in this document. The
reason for this is that this component will handle semantic mapping in PLANTCockpit, a
topic that will be covered in more depth in D4.2. It is suffice to say at this point that the
Mapping and Transformation component will provide an interface for the Adapters, with
which mapping and data conversion services can be requested.
The Adapters and the Adapter Manager, however, are the technical implementation of
external interfaces for PLANTCockpit. Their definition is the main scope of this deliverable.
The Adapter Manager is an arbitrator of Adapter life cycles and interactions. It shall manage
the installation configuration of adapters, as well as the system configuration of their
instances. A change to the original architecture as defined in D3.1 is the following. Adapters
are not separated from function blocks in their implementation. To simplify the architecture
and to address the uniformity of message exchange between components, adapters are
designed as function blocks, which follow in principle the same internal interfaces that are
defined for the contents of the PLANTCockpit Function Engine (see D3.1 for details on this
Engine). This makes the integration of adapters into a function block network as easy as
possible. The adapter acts as just another function block.
Adapters are designed to provide the interfaces to the external systems. Thus, they cover
specific underlying interfaces and services and provide these interfaces for the overall
PLANTCockpit approach. Compared to the function blocks used in the Function Engine, the
adapters in the System Connector Layer can be seen as service interface function blocks. It
is obvious that their internal details and structure need to follow the specific requirements of
the external systems. Depending on these implementation details, different adapter types
can be defined, even for the same external system, however all the interfaces the adapter
types provide to the Function Block Engine remain uniform in structure.

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 2 Adapters as function blocks in the PLANTCockpit Function Engine

The homogeneity of function blocks and adapters when running in the Function Engine is
illustrated in Figure 2. Due to the different types and roles that adapters embody, however,
additional information is necessary that is specific to each of the adapters. The Adapter
Manager is dedicated to this adapter-specific information. The task of the Adapter Manager
is to marshal and make discoverable the different adapters and their associated information.
The following chapter details the adapters, their interactions with the rest of the framework,
as well as how they are meant to connect to external systems. The main idea here is that
each adapter is specific to one target technology. That way, the specifics of each technology
can be addressed. The disadvantage of this is, of course, that an adapter needs to be
written specific to each target external technology. This, however, can be turned into an
advantage, since it makes the PLANTCockpit framework flexible and expandable.
In order to keep the efforts involved manageable, relationships between the different adapter
types and roles are elaborated and illustrated. It is shown how the introduction of adapter
types and adapter roles allows one to hide connection details of the external systems from
the users of PLANTCockpit. These similarities are to be used in later steps of this work
package, where configuration efforts are to be managed. The similarities are also used for
mapping and transformation.
In chapter 5 the interfaces of the adapters are elaborated in more detail. In Annex 9.1 a state
of the art analysis of interface specification options is given.

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

4 Adapters for PLANTCockpit

As has been discussed, adapters are a key component for connecting PLANTCockpit to
external data sources. This section describes the requirements adapters for PLANTCockpit
have to fulfil. The adapters of PLANTCockpit are meant to tie into the Function Engine,
exposing a function block interface towards the framework. Towards external systems,
however, they need additional properties. In order to address different external systems,
sometimes different adapters are needed. These adapters need to adapt to the specific
requirements of each external system.
When trying to classify the adapters, the results of the requirements analysis as documented
in D 2.3.1 provide a solid basis of use case driven targets for the integration of external
systems. It became apparent that for the use case partners, the technology the external
system is based on has a secondary focus. For the use cases, the role the system is fulfilling
in the overall production process is much more important than the technical aspects.
Regarding this situation, two important properties of adapters require to be defined. One is
the adapter type. Technical aspects for connecting to an external system depend on the
adapter type, so that the types are differentiated by the addressed technology. The other is
the adapter role. The data provided by an external system is important for the usage in
PLANTCockpit for a certain reason. This reason can be conveyed as the role of the adapter.

Figure 3 Adapter Types and Adapter Roles in PLANTCockpit

The relationship of adapter types and adapter roles can be seen in Figure 3. The adapter
type exposes an external interface towards a system outside of PLANTCockpit, the adapter
role is the deciding factor on how the internal interface of an adapter is used. Other function
blocks see the adapter only as another function block according to its role.
Adapter types can be easily show-cased by describing the relevant interface technologies.

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Section 4.1 contains the description of all technologies and interfaces to external systems
that will be addressed in PLANTCockpit. This covers mostly use-case-driven approaches,
but the consortium agreed to also include OPC Unified Architecture (OPC UA) into the list.
The reason for this is that OPC UA is a key technology when connecting to shop floor
systems. Giving proof that PLANTCockpit can be used with this technology as well as the
use case technologies is a convincing validation of the overall solution.
Adapter roles will be represented by PLANTCockpit-internal elements. For example, a
production order extracted from an external system will be mapped onto a production order
element inside the PLANTCockpit KPI calculation. Because the role of an adapter carries a
lot of semantics, it is a non-trivial task to assign them. Adapter roles are described in-depth
in section 4.2.
4.1

Adapter types for PLANTCockpit

This section discusses the adapter types that are planned to be implemented in the
PLANTCockpit project. This is done by explaining the target technologies for the adapters.
The main focuses in the explanations are interfaces that can be used to access information
stored in the respective technologies.
Two important technologies have not been identified as target technologies for
PLANTCockpit, so they will not be discussed in detail. However, a short comment about both
sensor networks as well as MTConnect is needed. Sensor networks are an important area of
research for industrial applications of information technology. While this importance is
undisputed, none of the use cases of PLANTCockpit calls for a direct access to a sensor
network. This does not mean that PLANTCockpit is not for sensor networks. The adapter
approach is designed in a way that allows the writing of a sensor network adapter and
thereby addressing this important technology. The decision to not do so in the project is
based solely on a focus on the use-case-relevant technologies and OPC as aan example
proof-of-concept going beyond that. A similar assessment has to be given for MTConnect.
The use cases did not call for it, so an MTConnect adapter will not be written in the project.
However, the concept expressely allows for an MTConnect adapter to be written. The usage
of XML on both ends will make the implementation of this adapter manageable for interested
parties. Despite being open for these technologies, only those technologies to be
implemented in the project are explained in more detail here.
4.1.1

SAP ERP / BAPI

To manage an enterprise and monitor or execute business processes, software solutions

called Enterprise Resource Planning (ERP) systems exist. They can be used for nearly all
enterprise areas, for organizational or management tasks, like controlling, warehousing,
retailing, production planning, finance, logistics, sales, disposition, accounting or personal
management. Different ERP systems can be integrated with each other via the internet to
enable cross-company processes, fasten to tasks and reduce costs. In such supply chains
customers and suppliers are integrated (ITWissen, itwissen.info 2012).
The SAP ERP system is the Enterprise Resource Planning solution offered by SAP. In an
SAP ERP system all data is based on Business Objects (BOs). SAP BOs capsulate the
business data and processes stored in an SAP system. Therefore they hide the structure
and implementation details of the underlying data (SAP, 2012).

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

4.1.2

Classification PU

Business Objects

Data stored in an SAP business system is modeled as Business Objects (BOs). BOs can be
real world objects like a customer order or an employee. To encapsulate the data the BOs
are modeled in different layers:
Kernel: represents the real data.
Integrity layer: represents the business logic of an object. This layer includes
business rules as well as constraints for values and domains.
Interface layer: describes the structure and implementation of the BO. This layer
defines the external interfaces called Business Application Programming
Interfaces (BAPIs).
Access layer: defines the mechanism and technologies to access the object data.
This could be done by Remote Function Calls (RFC) or with the programming
language Java using the SAP Java Connector.
The different layers of a BO are shown in Figure 4.

Figure 4: Layers of an SAP Business Object comp. (SAP, 2012)

The Interface layer separates the data of a BO from the applications and technologies which
access the data. A BO just offers an interface with clearly defined methods (BAPIs) to
access the encapsulated data from outside. An external application can only communicate
with a BO through these BAPIs. To access the BO and receive the data, an application just
needs the information to call the BAPIs. In this way an application can call the BOs and their
BAPIs without knowing specific implementation details of the underlying object. The BAPIs
which are provided by a BO represent the behavior of the object. A BAPI can change the
internal structure of the object and therefore the capsulated data if it is executed. An
example of a BAPI for the BO ProductionOrder is the method GetDetail. Inside of a SAP
system all BO types and their BAPIs are defined and described in the Business Object
Repository (BOR).

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Each business object is referenced to a specific object class. This is dependent on the
nature and general characteristics of the object. These object classes are also called object
types. Examples are the different production orders PO001 and PO002 which belong to
the object type Production Order. The object types are descriptions or templates of the
actual SAP BO. On the other side each single BO is a specific representation or instance of
his object type. In this case the production order with the id PO001 and the name
ProdOrd1 is an instance of the object type ProductionOrder. During the implementation of
an application only the used object types are defined. Later during the runtime the
application accesses the single instances of this object type. If an instance of a BO is used
by an application it can only be accessed through the BAPIs defined by its object type.
SAP BO types are defined by the following properties (SAP, 2012):
Object type: describes the attributes that all instances of the object type have in
common, like the id, the classification or the data model.
Inheritance and polymorphism: the aim of an object oriented technology is the
reusability. The reusability can be achieved by derivation of object types from
already existing ones. The BO type ProductionOrder is a sub type of the super
type ManufacturingOrder.
Key fields: define the structure of a unique identifier. Using this identifier enables
an application to access the specific instance of the object type. An example is
the key field ProductionOrder.Number which stores the order number of the
object type ProductionOrder.
Attributes: contains data of a BO and describes a specific object characteristic
(property or attribute). An example is the ProductionOrder.ScheduledFinish
attribute which holds the scheduled finish date of the order.
Methods: a method is an operation which can be executed on the BO to access
the underlying object data. A method is defined by a name and a sequence of
required and optional parameters as well as exceptions. The required parameters
have to be filled by the calling application. BAPIs are examples of such methods.
An example is the BAPI ProductionOrder.GetDetail which returns detail order
data.
Events: an event indicates that a status change of a BO happens. An example is
the ProductionOrder.Released event.
4.1.2.1

BAPIs

To ease the integration effort BAPIs are developed. BAPIs are methods to execute defined
business tasks on SAP BOs. BAPIs can be seen as APIs in object-oriented programming
languages. They provide interfaces to access BOs to execute SAP processes, functions or
retrieve data. BAPIs can be also enabled to be accessed and executed by external client
applications. BAPIs are usually accessed by synchronous communication and provide an
answer or result set for the calling client application. BAPIs pursue the goal to separate the
business content and data from the communication mechanism. Consequently BAPIs are
independent of the accessing technology and programming language. In general BAPIs do
not provide user dialogs to the calling application.
Using BAPIs provides the following advantages:

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Standard Interface: BAPIs describe the standard interface of business data stored
in an SAP business system. They enable the technical as well as business
integration of different SAP systems and software components.
Stability and downward compatibility: if a BAPI is established and released SAP
guarantees to keep the interface definition stable. A change of the underlying SAP
system is therefore independent of the access. Subsequently already
implemented client applications remain valid.
Object orientation
Openness
Synchronous and asynchronous communication
Data base consistency: a BAPI which creates a new BO or changes an existing
one remains always a consistent data base state. All data base changes are
entirely executed (as a transaction) or rejected (roll back).
Security: without explicit permissions it is not possible to call BAPIs.
To call a BAPI the following information are needed:
BAPI name: to identify a BAPI it consists of the name of the corresponding BO
followed by the BAPI name. Both names are separated by a dot ..
Import parameter: data which transfers the calling application to the BAPI
Export parameter: data which returns the calling application from the BAPI
Import/export (table) parameters: for importing and exporting data
It exists as a series of BAPIs which are implemented for most BO types. Those BAPIs
provide basic functions. They implemented certain design rules. They have for example the
same name across all BOs. If possible they also have the same sequence of parameters.
Examples are:
GetList: to retrieve all existing instances of the corresponding BO type.
GetDetail: to retrieve detailed information of an instance of a BO type. The BO is
referenced by its key field.
Create: to create an instance of a BO type.
Change: to change an existing BO.
Delete: to delete an existing BO.
To support a wider range of users and to employ the concept of SOA and web services, the
interface of a BAPI can be also modeled as a web service (Enterprise Service). Therefore a
wrapper is needed which exposes the interface as a standard WSDL file and can be
accessed by common web service clients. This is possible through the SOA manager of an
SAP system. By using the product SAP NetWeaver Gateway it is also possible to expose
BAPIs using the newer REST technology. The disadvantage of both possibilities is the
required customization of the SAP system. Instead of using the already available and
accessible BAPIs, Web Service or REST wrappers have to be written or at least configured.
4.1.3

SAP BW / BEx Queries

4.1.3.1

Data Warehousing

Data warehousing is used by the management for analytics and decision support, so that in

PLANTCockpit

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

most cases all data generated in a company is stored in a data warehouse system. The data
spans from customer-oriented supply chain data up to data about the companys own
offered products. This data is processed to get information and knowledge about customers,
the market and internal company processes. The knowledge is used to trigger dedicated
actions like the development of new products or services (ITWissen, itwissen.info 2012).
The SAP Business Information Warehouse (BW formerly BI) is the Enterprise Data
Warehouse system of SAP. It provides data warehousing functionality, a Business
Intelligence platform as well as Business Intelligence tools. It also allows integrating data
warehousing with other SAP standard products like the SAP ERP system. The provided
tools allow the integration, transformation and consolidation of business data from productive
SAP applications and external data sources in the SAP BW.
The following components build SAP BW (SAP, sdn.sap.com 2012):
Data Warehousing: classical functionality of a data warehouse system. This
includes the integration, transformation, consolidation, data cleaning and storage
of data for interpretation and analytics. The Administrator Workbench is the
central tool for data warehousing tasks.
BI Platform: technology platform of the SAP BW system. It provides the
infrastructure like OLAP processing, metadata repository, planning and simulation
possibilities, analytics functionality like data mining and reporting.
BI Suite: including Business Explorer.
4.1.3.2

Business Explorer

The Business Explorer (BEx) is the Business Intelligence Suite of the SAP BW. It is used for
analytics to support the strategic management as well as for the operational reporting and
decision support. The Business Explorer has tools to create reports, data queries and to
analyze the data. It enables analysis of real-time data as well as historical data in different
detail levels and perspectives.
With the BEx Information Broadcasting it is possible to extract historical data in form of
preprocessed documents out of the SAP BW. That information can be sent via mail or made
available for the Enterprise Portal. (SAP, 2012).

BEx Query Designer

The BEx Query Designer is an application of the Business Explorer to define queries on data
stored in the SAP BW. The business data stored in databases is defined as info cubes (also
called InfoProviders). With the Business Query Designer it is possible to define queries on
those info cubes. By the selection and combination of attributes and key figures, so called
info objects, it is possible to view and analyze the information stored in info cubes (SAP,
2012). The process is illustrated in Figure 5.

PLANTCockpit

10

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 5: Analyzing info cubes comp. (SAP, 2012)

4.1.3.3

BEx Queries

The BEx Query Designer provides a querying mechanism for data stored in info cubes. By
using BEx queries the data of info cubes can be quickly and directly analyzed (SAP,
help.sap.com 2012).
Queries provide following functionalities:
Queries can be parameterized by using variables for hierarchies, attributes,
characteristic values and formulas.
Queries can be filtered: selection of characteristic values for one or more
characteristics or key figures is supported. The queried data of an info cube is
aggregated to the filter selection. Filter selection is not navigable.
Queries can be navigated: selection of user defined characteristics and content
definition of the rows and columns of queries is supported as well as definition of
data ranges of an info cube which can be navigated. Generally a query has a
predefined start view. Using navigation of a query allows the creation of different
views on the data stored in info cubes.
The queried data from info objects can be limited, filtered and elaborated by definition of:
Characteristic values, characteristic intervals, hierarchy nodes
Formulas
Selections
Calculated and limited key figures which can be reused
Reusable or local structures

PLANTCockpit

11

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Exceptions
Conditions
4.1.4

Web Service

According to the W3C Web Services Architecture Working Group, a web service is defined
as a software system designed to support interoperable machine-to-machine interaction
over a network (Haas & Brown, 2004).
Generally, a Web Service provider exposes its capabilities as an interface, abstracting away
the implementation details. The interface specifies a set of operations, with input and output
parameters. An operation invocation involves an exchange of messages between the
service requester, and service provider.
The interface, or contract, is described in an XML-based machine-readable format, called
Web Services Description Language (WSDL). Machines interact with the Web Service by
exchanging SOAP messages, typically using HTTP, in a manner described by the service
description.
Web Services technology can be used to implement a service-oriented architecture, where
SOAP messages are the basic unit of communication.
SOAP
SOAP is an XML-based protocol for exchanging structured, typed information between
machines in a distributed environment. SOAP was once an acronym for Simple Object
Access Protocol, but this meaning has been dropped in SOAP 1.2. SOAP is a key
component in the implementation of Web Services.
Raw SOAP is fairly lightweight compared to other distributed computing standards, because
it provides only the messaging framework, and relies on other standards to provide other
features, such as registry/discovery, location, transport, security, and guaranteed delivery.
SOAP is based on XML, a familiar and widely-used standard, and retains all the extensibility
and machine-readability advantages. It is language and platform independent, and does not
define any constraints on the transport protocol to be used, so it is possible to pass through
corporate firewalls without the need to open ports. An incomplete summary of the relevant
components of the standard is provided in the following paragraphs.
The SOAP specification defines a stateless, one-way message transmission between SOAP
nodes, but it is expected that applications can define more complex Message Exchange
Patterns (MEPs) by combining one-way exchanges. A message exchange pattern is defined
by providing
A URI to name the MEP
Describe the lifecycle of the exchange with a state machine
Describe the temporal/causal relationships between the messages
Describe the normal and abnormal termination of the MEP
Rules for generating SOAP Faults during MEP operation
The specification provides a framework for conveying application information in an
extensible manner, but does not constrain the application-specific message content, or
specify anything about the underlying routing or transport protocol. A SOAP document

PLANTCockpit

12

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

consists of three key elements; the envelope, the header, and the body. Figure 6 shows the
structure of a SOAP Message.

Figure 6 SOAP Envelope (Mitra & Lafon, 2007)

Web Services Description Language (W3C, 2001)

To make effective use of Web Services, clients need an unambiguous, machineinterpretable description of the interface to the Web Service. The Web Services Description
Language (WSDL) specification from W3C was created to provide a mechanism for
describing the Web Service interface, including:
All supported operations
Input and output parameters for each operation
Types for all parameters, described in XML Schema format
Binding address information for each Web Service, including location (URL) and
transport protocol
A WSDL file is a form of service contract. Through its WSDL file, the Web Service is
providing an outwardly-descriptive interface, consistent with SOA principles. By locating and
parsing a WSDL file, a client has all the syntactic information required to use the operations
provided by a Web Service. For more details please refer to Section 9.1.7.
4.1.5

DPWS

To promote interoperability between resource-constrained devices, the Devices Profile for

Web Services (DPWS) defines a minimal set of implementation requirements for dynamic
discovery, service description, secure messaging, and events and subscriptions. The goals
of the standards are to provide interoperability analogous to Universal Plug and Play (UPnP)
for networked devices, fully aligned with Web Services technology. The profile defines
constraints on formats and protocols so that Web Services can be implemented on
peripheral and consumer electronics-class devices.
The general layout of DPWS clients, devices, and services is described in Figure 7.

PLANTCockpit

13

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 7: Arrangement of DPWS Clients, Devices, and Services (Lastra & Delamer, 2006)

DPWS defines a service as a software system that exposes its capabilities by receiving
and/or sending messages on one of several network endpoints. Messages in DPWS are
always transmitted in a SOAP envelope, generally transported via HTTP and TCP/IP, or
SOAP-over-UDP in the case of discovery services.
From a SOA perspective, a DPWS-compliant device is a type of service that hosts other
services. The device acts primarily as a resource for device-wide metadata, and for
metadata about the services it hosts. A hosted service is outwardly visible, not encapsulated
by the hosting service, and is addressed separately from the host.
DPWS specifies a set of built-in services that the device must implement:
Discovery services, for clients to discover devices, and for devices to announce
themselves in a network
Services to retrieve device and hosted service metadata
Eventing and Subscription Management services, for asynchronous notifications
A client can discover devices in the network that match specified criteria, retrieve and
interpret metadata, invoke operations available in the hosted services, and subscribe to and
receive notifications.
The web service specifications and transport protocols that are part of the Devices Profile for
Web Services are shown in Figure 8.

PLANTCockpit

14

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 8: Network Protocols and Specifications included in the Devices Profile for Web
Services (Microsoft, 2009)

DPWS assembles a set of core web standards, and extends or constrains them to provide a
base set of capabilities for resource-constrained devices:
Table 1: Specifications in the Devices Profile for Web Services

SPECIFICATION

DESCRIPTION

WSDL 1.1

The WSDL describes the messages each hosted service is

capable of sending and receiving.

SOAP 1.2

All messages are transported in a SOAP envelope, and

additional specs make use of SOAP headers.

WS-Addressing (Box D.
, 2004)

This Specification standardizes endpoint references and

message information headers, to convey information typically
provided by transport protocols and information systems. A
Web Service endpoint is a referenceable entity that can send
and receive messages. An endpoint reference can be used
to provide information for accessing a Web Service endpoint,
or to provide an address for an individual message inside a
message information header, along with message
characteristics, source and destination addressing, and
message identity.
DPWS should rely solely on WS-Addressing 1.0, with added
restrictions for device identifiers.

WS-Transfer (Alexander,

PLANTCockpit

Specification that defines a mechanism for acquiring XMLbased representations of entities using the Web Services

15

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

SPECIFICATION

DESCRIPTION

2006)

infrastructure. It defines two operations for sending and

receiving resource representations (Get, Put), and two for
creating and deleting (Create, Delete) a resource using a
resource factory.
DPWS uses the WS-Transfer Get operation as a means for
the Client to retrieve resource representation data for a
device, which includes relationship metadata for itself and
hosted services, and addressing data for the hosted
services.

WS-MetadataExchange
(Daves, 2011)

This specification is intended for the retrieval of Web Service

Description Information. It defines an encapsulation format
for metadata, and treats the metadata about a web service
endpoint as a WS-Transfer resource. The specification
defines two mechanisms that clients can use to ask a WSMetadataExchange endpoint for its metadata:
GetWSDL/GetWSDLResponse, and GetMetadata/
GetMetadataResponse.
DPWS uses the GetMetadata operation to retrieve metadata
for a hosted service, which includes the WSDL document.
The hosted service can return either the WSDL document, or
a reference to the document in a GetResponse envelope.

WS-Policy (Vedamuthu,
2007)

This specification provides a general framework for

specifying a variety of capabilities, requirements, and
characteristics of entities in a Web Service-based system. A
policy assertion identifies a behavior that is a requirement of
a policy subject. A policy alternative is a set of policy
assertions. Generally, a policy is used to convey conditions
on interaction between two endpoints. A provider exposes a
policy to describe the conditions for providing the service. A
requester uses policies when deciding whether to use the
service.
DPWS defines the dpws:Profile policy assertion, indicating
that compliance with the profile is required.

WS-PolicyAttachment
(Baraj, 2006)

PLANTCockpit

This specification provides two generalized mechanism for

associating policies with the subjects to which they apply. It
also specifies how the mechanisms can be used to associate
WS-Policy with WSDL and UDDI descriptions. The global
attribute wsp:PolicyURIs and child elements wsp:Policy
and wsp:PolicyReference are defined, so that resources

16

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

SPECIFICATION

Classification PU

DESCRIPTION
can reference applicable policies.
DPWS uses this to attach the dpws:Profile policy assertion to
a binding in the WSDL file.

WS-Discovery
(Microsoft, 2009)

This specification describes how to announce availability of

services, search for services, and locate previously
referenced services on a local network using a multicast
discovery protocol based on SOAP-over-UDP. Two one-way
messages are defined, Hello and Bye, as well as two twoway search messages, Probe and Resolve. Two discovery
modes are defined.
In ad-hoc mode, clients send probes to a multicast group,
and target services matching the search criteria send unicast
responses back to the client. The specification also defines
multicast hello messages that target services send when they
join a network.
In managed mode, a discovery proxy receives unicast hello
messages from target services, and unicast resolve
messages from clients.
DPWS specifies that devices must be compliant WSDiscovery target services, but hosted services should not.
The profile also specifies additional discovery-related
behaviors for devices.

WS-Eventing (Box D. ,
2006)

It is often useful for web services to receive messages when

events occur in other services. This specification provides a
means to create and delete subscriptions, manage
subscription expiry and renewal, and define a preferred
delivery mechanism.
WS-Eventing provides an extension point called Delivery
Modes, and defines a default delivery mode called Push
Mode.
DPWS requires full support for WS-Eventing, including Push
Mode, where the hosted service pushes Notifications to the
Event Sink (the client). It also specifies fault behavior,
appropriate for distributed, low-resource devices, and support
for event subscription filtering by action.

DPWS also recommends a security model based on WS-Security, but support is optional,

PLANTCockpit

17

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

and other security models are permitted. DPWS also overrides global constants from other
specifications to suit devices, such as packet size limits, timeouts, and delays.

4.1.6

MS Excel

4.1.6.1

Description

Microsoft Excel is a spreadsheet application included in the Microsoft Office package. An

Excel document, called workbook, consists of several sheets.
Every sheet contains a grid of cells, in which rows are identified by numbers and columns by
letters. This way, a cell can be uniquely identified by a letter and a number. Excel allows to
enter numerical values or data into these cells and to use them to perform calculations or to
create graphs.
It includes several predefined functions to carry out statistical, financial and engineering
operations. As for graphs, it can display line graphs, histograms, charts, etc.
4.1.6.2

Data import and export

Microsoft Excel is designed as a stand-alone user application. However, as part of the Office
suite, Excel files need to be accessible from outside the application as well. This is possible
through two major solutions, Apache POI and OLE Automation, which are described in the
following paragraphs. A third alternative, using comma-separated values (CSV), is also
wide-spread. Accessing information in that format is done by simply parsing an output file.
Since files need to be saved in a format different from the standard format, this approach is
not always feasible.
Apache POI
Apache POI is a Java library which allows reading and writing Excel files (both XLS and the
new XLSX format) among other office applications formats.
The API to access to XLS files is called HSSF, while the one related to the XLSX format is
called XSSF. Both of them provide:
Direct access to low-level structures of those formats.
A high level event-based API for efficient read-only access.
A full API for creating, reading and modifying files.
The following example shows how to iterate over the cells of a workbook:
sheet sheet = wb.getsheetat(0);
for (iterator<row> rit = sheet.rowiterator(); rit.hasnext(); ) {
row row = rit.next();
for (iterator<cell> cit = row.celliterator(); cit.hasnext(); ) {
cell cell = cit.next();
// do something here
}
}
Listing 1 MS Excel Apache POI code example

OLE Automation

PLANTCockpit

18

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

OLE Automation is a technology from Microsoft that allows establishing an inter-process

communication by using COM objects. Excel, as well as all Office applications, provides
automation objects to be able to interact with it from other programs.
This is an example about how to perform several actions in Excel using Visual Basic Script:
Dim excelApp as Object
Set excelApp = CreateObject("Excel.Application")
excelApp.Workbooks.Add
excelApp.Range("A1:C6").Select
excelApp.ActiveCell.Formula = "Hello World!"
excelApp.Visible = True
Listing 2 MS Excel OLE Automation code example

A drawback of OLE Automation is that Microsoft Excel has to be installed in the computer in
which its files are going to be read, while Apache POI is a platform-independent standalone
solution.
4.1.7

MS Project

4.1.7.1

Description

MS Project is a project management tool included in the Microsoft Office package. It is

designed to help project managers plan project stages and tasks. Among other features, it
allows to:
Manage a list of activities in a hierarchical way.
Assign resources and costs to the different activities.
Track the project status.
Analyze workloads.
Generate Gantt and network charts.
Print reports.
The key elements in a project are:
Tasks: A project is broken down into several tasks, which are the steps needed to
complete it. They can be parallel or sequential. Besides, a task can be repetitive if
it arises at a regular interval during the project. A task is composed of an
identifier, a name, duration and a date.
Milestones: Milestones represent intermediate goals, events or conditions that
affect to a group of tasks. In contrast to tasks, milestones do not have an
associated duration or effort.
Resources: They include the people, materials and equipment necessary to carry
out the project tasks. Resources are defined in a resource sheet and they are
assigned to tasks. It is also possible to share them between several projects.
4.1.7.2

Data import and export

Microsoft Project is not primarily designed with the goal of data exchange between
applications. There are possibilities to access the information inside a MS Project file,
however. These possibilities are based on the MPXJ library and OLE Automation, which are
described in the following paragraphs.

PLANTCockpit

19

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

MPXJ library
MPXJ is a Java library which allows to access project information from several file formats:
Microsoft Project Exchange (MPX), Microsoft Project (MPP, MPT), Microsoft Project Data
Interchange (MSPDI XML), Microsoft Project Database (MPD), Planner (XML) and
Primavera (XER and database). The native MS Project file format (MPP) can only be read; it
does not support writing.
The same API can be used to access to all the supported formats. In order to allow this,
MPXJ defines a set of classes that encapsulate the key entities that make up a project:
Project, Resource, Task, Resource Assignment and Calendar.
The following example shows how to iterate over the resources defined in a MS Project file:
ProjectReader reader = new MPPReader();
ProjectFile project = reader.read("example.mpp");
for (Resource resource : project.getAllResources()){
System.out.println("Resource: " + resource.getName() + " (Unique ID=" +
resource.getUniqueID() + ")");
}
Listing 3 MS Project MPXJ library resource iteration example

This example demonstrates how to read the task hierarchy:

public void listHierarchy(ProjectFile file){
for (Task task : file.getChildTasks()) {
System.out.println("Task: " + task.getName());
listHierarchy(task, " ");
}
System.out.println();
}
private void listHierarchy(Task task, String indent){
for (Task child : task.getChildTasks()){
System.out.println(indent + "Task: " + child.getName());
listHierarchy(child, indent + " ");
}
}
Listing 4 MS Project MPXJ library task reading example

The following example enumerates the resources assigned to the project tasks:
for (Task task : file.getAllTasks()){
System.out.println("Assignments for task " + task.getName() + ":");
for (ResourceAssignment assignment : task.getResourceAssignments()){
Resource resource = assignment.getResource();
String resourceName;
if (resource == null)
resourceName = "(null resource)";
else

PLANTCockpit

20

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

resourceName = resource.getName();
System.out.println("

" + resourceName);

}
}
Listing 5 MS Project MPXJ library resource enumeration example

OLE Automation
As Microsoft Project is a member of the Office package, it can also be controlled with OLE
Automation by using COM objects.
This is an example about how to add a new task to a project and save it to a file using Visual
Basic Script:
Dim pjApp As Object
Set pjApp = CreateObject("MSProject.Application")
pjApp.Visible = True
pjApp.FileNew
pjApp.ActiveProject.Tasks.Add "New task"
pjApp.FileSaveAs "ProjectFile.mpp"
pjApp.FileClose
pjApp.Quit
Listing 6 MS Project OLE Automation code example
4.1.8

OPC Unified Architecture

OPC UA is a relatively new specification from the OPC Foundation for data exchange
between systems in industrial applications, based on web-service concepts. OPC UA is
designed for accessing large amounts of real-time device data using standard network
infrastructure, while maintaining sufficiently high performance. OPC UA specifies a clientserver model for information exchange, where a client can access, read, and modify the
address space of a server. The specification defines an object model for information
representation on a server, and a pre-defined set of services for browsing, querying,
creating, and manipulating objects in the address space. Information is communicated using
OPC UA- and vendor-defined data types, encodings, and transport mappings
OPC UA evolved from classic OPC, which was a data access for Windows-based systems,
using Microsofts OLE, COM, and DCOM technologies. OPC was formerly an acronym for
Object Linking and Embedding (OLE) for Process Control, but this acronym has been
dropped. The standard was developed to bridge Windows systems and process control
devices, and defines standard objects, methods, and interfaces for retrieving field data from
devices on the factory floor. A vendor would implement an OPC server for their hardware,
which would provide a method for any OPC client to access device data for use in any MES,
ERP, HMI/SCADA, or other system.
The OPC UA specification eliminates the reliance on COM/DCOM, and specifies a platformindependent, service-based communication model, and a richer, integrated address space
model. In the interest of security and performance, OPC UA defines two data encodings:
UA Binary: The specification defines a non-portable binary message encoding,
optimized for message size, and fast encoding and decoding. The specification
relies on a set of primitive data types, for which binary encodings are defined. The
encoding excludes type and field name information, because applications are
expected to have advance knowledge of the services and data structures being

PLANTCockpit

21

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

transmitted.
UA XML: The specification also defines a plain text XML representation of
elements in the object model for SOAP/HTTP web services. The UA XML
encoding uses the formats defined in the W3C XML Schema specification.
Furthermore, two transport mappings are defined:
UA TCP (UA Native): A TCP-based OPC UA-specific protocol for establishing a
full-duplex channel for transmitting binary data between an OPC UA client and
server. Unlike HTTP, responses can be returned in any order, and allows
responses to be returned on a different socket, if communication failure causes an
interruption. OPC TCP is designed to work secure SecureChannel, implemented
at a higher layer.
SOAP/HTTP (Web Service): OPC UA messages are serialized to XML, wrapped
in a SOAP envelope, and exchanged using the request-response model defined
in the SOAP specification. HTTP or HTTPS transport bindings are used. A
message is sent in the body of a POST request, and the response comes in the
HTTP response.
The client-server communication paradigm of OPC UA lends itself well to hierarchical
application architectures. A higher level client application retrieves data and writes values to
a lower-level server. Application layers can be stacked by having an OPC UA server and
client running on the same component, as shown in Figure 9.
Each component running an OPC UA Server manages its own address space. The server
can map nodes in the address space to IOs on devices in a connected fieldbus network or
PLC memory, or expose data from a database. A single OPC UA server integrates data,
type definitions, alarms and events, and historical data into its address space. The server
supports a set of web services, which a client can use to establish a session, browse and
query the address space, subscribe to notifications, and invoke object methods.

PLANTCockpit

22

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 9: OPC UA Stacked Architecture

OPC Unified Architecture is fundamentally about data modelling and transport. In classic
OPC, only pure data was provided, such as raw sensor values, with only limited semantic
information, such as the tag name and the engineering unit. OPC UA offers more powerful
capability for semantic modelling of data.
OPC UA uses object-oriented techniques, including type hierarchies and inheritance, to
model information. Type information is stored on servers and accessed in the same way as
instances, similar to relational database systems. The OPC UA node model allows for
information to be connected in various ways, by allowing for hierarchical and nonhierarchical reference types. This facilitates exposing the same information in many ways,
depending on the use case. Both the type hierarchies and references types can be
extended, allowing information models of existing systems to be exposed natively, without
the need for mapping between models. Information models are always contained in an OPC
server, so an OPC client is not required to have an integrated OPC UA information model.
The base OPC UA specifications provide only the infrastructure to model information, and
encourage additional, industry specific information model specifications to be defined by
vendors and standards organizations. Development has begun on a base model for
exposing device information and device types in OPC UA (UA Devices), which can be
extended with vendor-specific information. Also, efforts are underway to expose the ISA 95
(also known as IEC 62264 (International Electrotechnical Commission, 2003)) model in OPC
UA to provide information to MES and ERP systems.
4.1.9

SQL

The SQL (Structured Query Language) (ISO/IEC 9075:1992, 1992) is a programming

language designed especially for access to relational database management systems
(RDBMS). SQL belongs to the family of data manipulation languages (DML). It is used to
retrieve and manipulate data in RDBMS - inserting, deleting and updating data in a
database. There are several approaches to get or manipulate data in database, as described

PLANTCockpit

23

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

in the following sections.

4.1.9.1

SQL Statements

SQL is the most widely used database language and offers the following base queries and
statements for data retrieval and data manipulation:
SELECT ... FROM ... WHERE ...: this query statement retrieves data from one or
more database tables, or expressions. The returned data are a result set of
records. It is the most complex SQL statement and provides a lot of optional
keywords and clauses that make possible the more granular data retrieval. The
standard SELECT statement does not change the data in the database and is
purely read-only query.
INSERT INTO ... VALUES ...: this statement adds rows to an existing database
table.
UPDATE ... SET ... WHERE ...: this statement modifies a set of existing rows in
the database table.
DELETE FROM ... WHERE ...: this statement removes existing rows from a
database table.
4.1.9.2

Stored procedures

Instead of using the SQL statements directly, the RDBMS usually offer the stored
procedures or functions that wrap them. This means that for a SQL statement that is often
used, a stored procedure can be created and stored in the database and such a procedure
can be executed in the SQL database to manipulate the data or to retrieve some data from
the database. The stored procedure can contain several SQL statements and its big
advantage is that all the SQL statements in the stored procedure are done in a single
transaction, so in case of any error all the changes in the database can be reverted.
4.1.9.3

Procedural languages support

The RDBMS also offers to execute the code written in procedural languages. Examples
could be PL/SQL and Java used in Oracle database server (Oracle, 2005) or CLR .NET
Framework procedures used in Microsoft SQL Server (Microsoft, 2011).

4.1.9.4

PL/SQL

PL/SQL (Oracle, 2012) is a procedural language extension to SQL provided by Oracle. It

provides a server-side, stored procedural language that is easy-to-use, seamless with SQL,
robust, portable, and secure. PL/SQL enables mixing of SQL statements with procedural
constructs. With PL/SQL, a PL/SQL program can define and run units such as procedures,
functions, and packages. PL/SQL program units generally are categorized as anonymous
blocks and stored procedures.

PLANTCockpit

24

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 10: The PL/SQL Engine and the Oracle Database Server (Oracle, 2005)

4.1.9.5

Java

A Java stored procedure (Oracle, 2012) is a program written in Java to run in the Oracle
server, exactly as a PL/SQL stored procedure. It is invoked directly with products like
SQL*Plus, or indirectly with a trigger. It can be accessed from any Oracle Net client OCI,
pre-compiler, or JDBC.
In addition, Java can be used to develop powerful programs independently of PL/SQL.
Oracle provides a fully-compliant implementation of the Java programming language and
JVM.

4.1.9.6

SQL CLR

The common language runtime (CLR) (Microsoft, 2011) is the heart of the Microsoft .NET
Framework and provides the execution environment for all .NET Framework code. Microsoft
SQL Server integrates the CLR component of the .NET Framework for Microsoft Windows.
This means that SQL Server users and application developers can write the stored
procedure, triggers, user-defined types, user-defined functions, and user-defined aggregates
in managed code using any .NET Framework language, including Microsoft Visual Basic
.NET and Microsoft Visual C#. The major benefits of the CLR integration are:
Better programming model
Improved safety and security

PLANTCockpit

25

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Ability to define data types and aggregate functions

Streamlined development through a standardized environment
Potential for improved performance and scalability.
4.1.9.7

Transactions

Transaction is a logical unit of work that contains one or more SQL statements (Oracle,
2005). It is an atomic unit and the effects of all the SQL statements in a transaction can be
either committed (applied to the database) or rolled back (undone from the database).
The transactions are very important to ensure the integrity of the data. It means that
transactions help to keep all the data in the RDBMS in a valid, consistent, complete form.
4.2

Adapter roles

The adapter roles that have been defined in the beginning of section 4 need to be defined in
more depth in order to make them usable for the PLANTCockpit project. The use cases of
PLANTCockpit offer a typical set of example adapter roles that warrant a closer inspection.
The role of an adapter needs to be identified, though. In order to prepare a model of adapter
roles that can be applied to the external systems of the PLANTCockpit use cases, the roles
need to be structured and described according to their semantics. Since the exact semantics
of data are not yet fully defined, this document will only offer a grid of subdivisions of the
general role of an external system. The work on the Mapping and Transformation Layer will
detail the concrete roles that are used in a PLANTCockpit system. The list of roles that the
use case systems identified as relevant to PLANTCockpit can be divided into four main
areas of interest. These four areas are production planning, resource planning, logistics and
energy management. Naturally, depending on the partners use case, the focused area
differs.
4.3

Non-functional properties of adapters

Apart from the obvious task of acquiring data from external systems, there are additional
properties of the PLANTCockpit adapters to be considered. These non-functional properties
are discussed in this section. The first issue to be addressed is the fact that in addition to
adapter types and adapter roles, there is the adapter instance. The instance is a separate
program entity that is the intersection point between adapter type and adapter role. Each
instance of the PLANTCockpit adapter has a specific configuration that adds to the role and
type of the instance.
This configuration information has to provide data on crucial operations of the adapter. First
of all, the adapter needs to be properly identifiable through its configuration information. This
is in addition to the functional necessities imposed on the configuration information, which
encompasses the information needed to retrieve the data the adapter is meant to acquire.
An important design decision for the PLANTCockpit adapters was the separation of systems
for security purposes. Granting only limited access to a system can help prevent exploitation
of information and other attacks. The security issues regarding adapters are named in D3.2.
Another important property is the computing performance of adapters. Depending on the
connected external system, the frequency of data acquisition can vary widely. Data
throughput, also, has a varying dimension depending on the adapter instance. It is not

PLANTCockpit

26

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

possible to formulate general guidelines for computing performance of adapters per se,
except that each adapter has to make sure that its computing power consumption is
optimised.
For implementing the adapters, different philosophies can be applied. One possibility is to
make an adapter type as flexible as feasible. Then one adapter type covers a wide range of
applications that are related on an access-technical level. This reduces the number of
adapter types that have to be implemented. It does, however, make each adapter instance
heavy-weight, with a lot of configuration to be held just to differentiate between different
possible applications. In the opposite case, a highly specialised adapter type can be tailored
towards accessing a well-defined piece of data in an external system. This can reduce the
amount of configuration to be maintained to zero. The effort for implementing a lot of new
specialised adapter types whenever a change in the data focus occurs makes this approach
unfeasible, though. Hence, a balance between the two extremes should be sought when
implementing adapter types.
The importance of configuration information for the adapter instances makes it necessary to
differentiate the external interfaces of an adapter. For one, there needs to be a runtime
interface, where other function blocks can request data from external systems from the
adapter. In addition, there needs to be a configuration interface. This interface should allow
access to an adapters configuration information. When setting up a function block network
in PLANTCockpit, the user will need access to the configuration information and also will
need to manipulate it.
PLANTCockpit should be as flexible as possible regarding its data acquisition. It is
impossible to prepare the framework for every possible data source in advance. New data
sources must be filled with meaning during the run time of PLANTCockpit, if need be.
Therefore, adapters need to receive their configuration information from flexible data
structures. These data structures should be able to carry the semantics of data sources.
That way, when a new system is connected to PLANTCockpit, it can be mapped onto the
semantics easily and from there the mapping on the PLANTCockpit-internal formats can be
done automatically.
All these considerations have been a factor in deciding the draft for the interface
specification of the PLANTCockpit adapters. The following section describes these
interfaces.

PLANTCockpit

27

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

5 Abstract interface specification of the PLANTCockpit Adapters

As has been established in D3.1, the data processing logic of PLANTCockpit is structured on
function blocks. While the Function block engine is not in the scope of this deliverable, a
concept for combining adapters and function blocks has been developed that will be
introduced henceforth. From the view of the Function Engine, an adapter is just like any
other function block. The adapter passes on data just like any other function block would.
What makes the adapter different, however, is its hybrid nature. While one end of the
adapter is linked into the Function Engine, the other end is specific to the addressed
technology and directly accesses the corresponding external system.
The concept of adapters as function blocks can be seen in Figure 11. Note that a colourcoding has been applied that matches the one found in D3.1, where elements of the
Function Engine are blue, elements of the External System Connector Layer are green and
elements that do not belong to PLANTCockpit are white. The illustration of the data flow
given in the figure matches typical data flow illustrations found in function block concepts
from the manufacturing domain, such as the one given in IEC 61499 (International
Electrotechnical Commission, 2005), e.g.

Figure 11 PLANTCockpit adapters as function blocks

Note that the adapters have two characteristics, as described in section 4. The upper
labelling identifies the adapter role, as exposed to PLANTCockpit. The lower one identifies
the adapter type, which is the critical property for access to the corresponding external
system. In the example shown, both the Database and the Excel file contain a production
order. Therefore, two adapters expose the same role towards PLANTCockpit. For the
function blocks interacting with both adapters, there is no technical difference between them.
The heterogeneity of the data source is masked by the adapters.
In addition to this definition of adapters as function blocks, more details need to be specified

PLANTCockpit

28

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

in order to allow interface implementation for the adapters. While a first draft is given here, a
more detailed specification for use by programmers in general will be given in D4.3.
Adapters in general need to expose three interfaces that allow querying and manipulation.
The first interface to be exposed is an interface used for querying identification information
from the adapter. The second interface is used for configuration of the adapter. The third
interface is a runtime interface for triggering the performance of the adapters data
acquisition routine. Figure 12 shows the three interfaces of the PLANTCockpit adapter,
which will be described in more detail hereafter.

Figure 12 The interfaces of the PLANTCockpit adapter

The Identification interface of the adapter allows acquiring information about the adapter
type, the adapter role and the adapter instance. An identification constant can be used to
unambiguously identify the adapter type. This is meant to help the configurator in making
sure that a fitting adapter is used for a specific data source. The same method used for the
adapter role allows verifying that a specific adapter is used correctly in PLANTCockpit. The
identification of the adapter instance can be used in the message broker as described in
D7.1. The operations exposed by the IIdentification interface are listed here:
Table 2 IIdentification interface descriptions

IIdentification interface

Description

getAdapterTypeID()

Returns an ID tag specific for the adapter

type that is implemented by this adapter
instance

getAdapterTypeName()

Returns a name tag specific for the adapter

type that is implemented by this adapter
instance

getAdapterTypeVersion()

Returns a version number identifying the

version of the adapter type definition
implemented by this adapter instance

PLANTCockpit

29

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

getAdapterRoleID()

Returns an ID tag specific for the adapter

role that is assigned to this adapter instance

getAdapterRoleName()

Returns a name tag specific for the adapter

role that is assigned to this adapter instance

getAdapterInstanceID()

Returns an ID tag specific for the adapter

instance

getAdapterInstanceName()

Returns a name tag specific for the adapter

instance

The configuration interface of the adapter allows access to the configuration information
stored for each adapter. This covers acquisition and writing of the data access specifics for
the external system as well as PLANTCockpit-specific addressing and sophisticated
information about the semantics of the adapter. The message IDs accessible here can be
used in the message broker as described in D7.1. The operations exposed by the
IConfiguration interface are listed here:
Table 3 IConfiguration interface descriptions

IConfiguration interface

Description

getInstanceConfiguration()

Returns an XML construct that contains the

configuration information of this adapter.
Specifically, information about how to
access the external data source and what
data is focused there is contained

setInstanceConfiguration()

Passes an XML construct that contains the

configuration information for this adapter.
Specifically, information about how to
access the external data source and what
data to select from it is contained

getMessageIDList()

Returns a list of message IDs corresponding

to the messages that are generated
whenever the execute operation (see below)
is successfully run

setMessageIDList()

Passes a list of message IDs corresponding

to the messages that have to be generated
whenever the execute operation (see below)
is successfully run

getAdapterSemantics()

Returns a data struct that contains semantic

information about the adapter, e.g. the role
of the source system and the corresponding
meaning of the data that is acquired through

PLANTCockpit

30

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

the adapter
setAdapterSemantics()

Passes a data struct that contains semantic

information about the adapter, e.g. the role
of the source system and the corresponding
meaning of the data that is acquired through
the adapter

The runtime data interface allows the execution of the data acquisition routine defined in the
adapter. This interface can be triggered in three ways. First, a function block can trigger the
interface from the PLANTCockpit side of the adapter, generating a response message on
demand. Second, an internal timer in the adapter can trigger the interface, generating a
message in a set time interval, ready for all subscribers to the outgoing message queue to
consume. Third, an external system, to which the adapter subscribed, can trigger the
interface by sending an event or alarm. Then a message is generated and passed into the
PLANTCockpit message queues, where all subscribers to the adapter receive it by means of
the PLANTCockpit message queue. (See D7.1 for more details on message queues.)
Table 4 IRuntimeData interface description

IRuntimeData interface

Description

execute()

This operation is the central data acquisition

activity that can be triggered in different
ways and ends up generating an outgoing
message with the specified data wrapped in
a PLANTCockpit-compatible way

The interfaces described in this section will become part of a reference implementation of
adapters for PLANTCockpit. The reference implementation and an update on the interfaces
will be given in D4.3.

PLANTCockpit

31

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

6 Abbreviations
The following table lists the abbreviations used throughout the document.
Table 5 Abbreviations

Abbreviation

Long Version

B2MML

Business to Manufacturing Modelling

Language

BAPI

Business Application Programming Interface

BEx

Business Explorer

BO

Business Object

BW

Business Information Warehouse

COM

Component Object Model

DCOM

Distributed Component Object Model

DPWS

Devices Profile for Web Services

ERP

Enterprise Resource Planning

GUI

Graphical User Interface

HTTP

Hypertext Transfer Protocol

ID

Identifier

IDL

Interface Definition Language

IEC

International Electrotechnical Commission

IO

Input/Output

IP

Internet Protocol

ISO

International Organization for

Standardization

KPI

Key Performance Indicator

MES

Manufacturing Execution System

MS

Microsoft

OPC

Openness, Productivity, Collaboration

(formerly Object Linking and Embedding

PLANTCockpit

32

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

(OLE) for Process Control)

OPC UA

OPC Unified Architecture

PLC

Programmable Logic Controller

RPC

Remote Procedure Call

SOA

Service-Oriented Architecture

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

TCP

Transmission Control Protocol

UDP

User Datagram Protocol

W3C

World Wide Web Consortium

WP

Work Package

WS

Web Service

WSDL

Web Services Description Language

XML

Extensible Markup Language

PLANTCockpit

33

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

7 Conclusion
This document describes the adapters of PLANTCockpit, which serve as connectors to
external systems. It offers a first draft of the specification of external interfaces, which will
receive mapping and transformation support in D4.2 and will be specified more concretely
after the initial implementation experience has been gathered in D4.3.
The main achievements of this document are the identification of adapters as function blocks
with additional capabilities, as well as the differentiation between adapter types on the
technical and adapter roles on the semantic level. While the defined interfaces offer a basis
for the implementation of reference adapters as well as use case specific adapters, the
considerations regarding semantics are the basis for the design of the mapping and
transformation framework in the upcoming period of the project.
The section on adapter types provides an overview of the technologies that have to be
addressed with PLANTCockpits external interfaces. Extensive discussions and examples
provide a guideline for programmers who want to implement adapters.
The identification of requirements for adapters is taken to the non-functional level as well.
This is expanded by the Annex, where an example for mapping of data is given.
Tying the adapters seamlessly into PLANTCockpit is a critical step towards a success of the
overall project. External data is the foundation of everything else PLANTCockpit wants to
achieve. Making the connection as easy for the users as possible is a goal that will have to
be kept in mind during the future work in the project.

PLANTCockpit

34

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

8 References
Alexander, J. (September 2006). Web Services Transfer (WS-Transfer). Von World Wide Web
Consortium (W3C) Submission: http://www.w3.org/Submission/WS-Transfer/ abgerufen
Baraj, S. (April 2006). Web Services Policy 1.2 - Attachment (WS-PolicyAttachment). Von World Wide
Web Consortium (W3C) Submission: http://www.w3.org/Submission/WS-PolicyAttachment/
abgerufen
Box, D. (2004). Web Services Addressing. Von World Wide Web Consortium (W3C) Submission:
http://www.w3.org/Submission/ws-addressing/ abgerufen
Box, D. (March 2006). Web Services Eventing (WS-Eventing). Von World Wide Web Consortium
(W3C) Submission: http://www.w3.org/Submission/WS-Eventing/ abgerufen
Cristcost. (December 2007). Wikimedia Commons Image. Abgerufen am 31. 1 2012 von
http://en.wikipedia.org/wiki/File:WSDL_11vs20.png
Daves, D. (September 2011). Web Services Metadata Exchange (WS-MetadataExchange). Von
World Wide Web Consortium (W3C) Submission: http://www.w3.org/Submission/WSTransfer/ abgerufen
Haas, H., & Brown, A. (February 2004). Web Services Glossary, World Wide Web Consortium (W3C)
Working Group Note. Abgerufen am 31. January 2012 von http://www.w3.org/TR/ws-gloss/
International Electrotechnical Commission. (2003). IEC 62264 - enterprise - control system
integration.
International Electrotechnical Commission. (2005). IEC 61499 - Function blocks.
ISO/IEC 9075:1992. (30. July 1992). Database Language SQL. Von
http://www.contrib.andrew.cmu.edu/~shadow/sql/sql1992.txt abgerufen
Lastra, J., & Delamer, M. (2006). Semantic web services in factory automation: fundamental insights
and research roadmap. Industrial Informatics, IEEE Transactions on, vol.2, no.1, 1-11.
Microsoft. (July 2009). Additional WS-Discovery Functionality. Von MSDN Library:
http://msdn.microsoft.com/en-us/library/bb736556(v=VS.85).aspx abgerufen
Microsoft. (2011). Overview of CLR Integration. Abgerufen am 29. 02 2012 von Microsoft Technet:
http://technet.microsoft.com/en-us/library/ms131045.aspx
Mitra, N., & Lafon, Y. (April 2007). SOAP Version 1.2 Part 0: Primer (Second Edition), World Wide
Web Consortium (W3C) Recommendation. Abgerufen am 31. 1 2012 von
http://www.w3.org/TR/soap12-part0/
Oracle. (2005). SQL, PL/SQL, and Java. Abgerufen am 29. 02 2012 von Oracle Database
Documentation Library: http://docs.oracle.com/cd/B19306_01/server.102/b14220/sqlplsql.htm
Oracle. (2005). Transaction Management. Abgerufen am 29. 02 2012 von Oracle Database
Documentation Library: http://docs.oracle.com/cd/B19306_01/server.102/b14220/transact.htm
Oracle. (2012). Oracle Database Java Developer's Guide. Abgerufen am 29. 02 2012 von Oracle
Database Documentation Library:
http://docs.oracle.com/cd/B19306_01/java.102/b14187/toc.htm
Oracle. (2012). Oracle Database PL/SQL User's Guide and Reference. Abgerufen am 29. 02 2012
von Oracle Database Documentation Library:
http://docs.oracle.com/cd/B19306_01/appdev.102/b14261/toc.htm
SAP. (2012). help.sap.com. Von http://help.sap.com abgerufen
Vedamuthu, A. (September 2007). Web Services Policy 1.5 Framework. Von World Wide Web
Consortium (W3C) Recommendation: http://www.w3.org/TR/ws-policy/ abgerufen
W3C. (March 2001). Web Services Description Language (WSDL) 1.1. Von W3C:
http://www.w3.org/TR/wsdl abgerufen
World Batch Forum. (October 2008). Business to Manufacturing Markup Language. Abgerufen am 31.
January 2012 von http://www.wbforg.affiniscape.com/associations/12553/files/B2MMLV0400.zip

PLANTCockpit

35

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

9 Annex
In order to specify the interfaces of the PLANTCockpit adapters, an analysis of interface
definition languages has been performed. The results of this analysis have been deemed
useful for the project, and therefore are given in this Annex.
An IDL is a programming language independent notation to describe the services offered by
a software component. They are commonly used in RPC (Remote Procedure Call), Web
Services and Component Software technologies, like Microsofts COM/DCOM, Mozillas
XPCOM, etc.
9.1
9.1.1

Interface definition languages

OMG IDL

OMG IDL is a well-known interface definition language created for the Component Object
Request Broker Architecture (CORBA) standard. It has a simple and easy to learn syntax,
very close to C++ or Java.
This is an example of how an OMG IDL interface looks like:
module Servers {
interface TCPServer {
// Attributes
attribute long port;
readonly attribute string hostname;
// Operations
void listen(in long port, out boolean success);
};
interface HTTPServer : TCPServer {
void handleGet();
void handlePost();
};
};
Listing 7 OMG IDL interface example code

Apart from operations and attributes, OMG IDL supports the following primitives:
Modules: Interfaces can be grouped in modules. This is useful to avoid name
clashes.
Oneway operations: These are special non-blocking operations.
Exceptions: Operations can raise exceptions to indicate error situations.
Inheritance: An interface can inherit from others, in a similar way as inheritance
works in object-oriented programming languages.
Types:
o Basic types: It supports the most common basic types, like float, double,
long, char
o Constructed types: It provides three mechanisms to create new types from
others, similar to the ones provided by the programming languages:
Structs: They allow to group together several related items.

PLANTCockpit

36

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Unions: They are utilized to group several items, but only one of
them can be used.
Enumerated types: They allow to group a set of related constants.
Arrays.
Template Types:
Sequences: They are used to represent lists of objects.
Strings: A string is a sequence of characters.
Constants.
Type declaration.
Forward declaration.
Scoped names.
o
o

9.1.2

Microsoft Interface Definition Language (MIDL)

MIDL is an interface definition language developed by Microsoft, though is basically based

on OMG IDL. It only adds some small features to support COM/DCOM interfaces.
It was mainly created to support RPC and COM/DCOM interfaces, though it also generates
type libraries for OLE automation. Therefore, the provided tools are oriented to work with
those technologies.
9.1.3

XPIDL

XPIDL (Cross Platform Interface Description Language) is an interface definition language

developed by Mozilla. Its main purpose is to specify XPCOM interfaces.
As MIDL, it is based on OMG IDL. It is extended with syntax to handle IIDs and some
additional types.
9.1.4

Apache Thrift

Thrift is not only an interface definition language, but also a complete software stack that
includes a code generation tool to develop RPC services.
Thrift uses C-style syntax to define the interfaces. A Thrift interface looks like this:
struct TemperatureSensor {
1: i32 busAddress,
2: string name,
3: bool enabled
}
service SensorService {
void addSensor(1: TemperatureSensor sensor),
TemperatureSensor getSensor(1: i32 busAddress)
}
Listing 8 Thrift interface code example

The language provides the following items:

Basic types: bool, byte, i16, i32, i64, double, string and binary.
Structs.
Containers: ordered lists, unordered sets and maps.

PLANTCockpit

37

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Exceptions.
Services: They are equivalent to interfaces in object oriented programming.
9.1.5

Apache Etch

Etch, as Thrift, is a cross-platform RPC framework developed by Cisco Systems. To

describe those services, it includes an interface definition language called Etch IDL.
Etch IDL uses Java-style syntax and looks like this:
module test
@Direction(Both)
service TemperatureService
{
@Authorize(isLoggedIn)
int getTemperature( )
@Authorize(isLoggedIn)
int getUnits( )
void checkStatus() throws BadSensorException
}
Listing 9 Etch IDL interface code example

The language provides the following elements:

Basic types: Boolean, byte, short, int, double, string
Extended types: Datetime, List, Set and Map.
Object data type.
Constants.
Enumerations.
Arrays.
Exceptions.
Messages: They are equivalent to functions in programming languages.
Includes.
Services: They are used to group messages.
Annotations: They are used to alter the behavior of the following statement, for
example, to implement authorization, to express message direction, to indicate
timeouts
Modules: They work in a similar way as Java packages.
9.1.6

Apache Avro

Apache Avro is a data serialization system that also provides RPC mechanisms. It includes
an interface definition language called Avro IDL.
An Avro IDL document consists of one protocol definition, which may include definitions of
messages, data types or imports of external protocols. It uses Java-C++ style notation.
This is how an Avro IDL document looks like:
@namespace("org.plantcockpit.test")

PLANTCockpit

38

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

protocol Sensor {
enum Kind { TEMPERATURE, HUMIDITY }
record Sensor {
string name;
Kind kind;
Int busAddress;
array<long> lastValues;
}
error SensorError {
string message;
}
string getSensorDeviceType();
int getTemperature(int units);
void `error`() throws SensorError;
void ping() oneway;
}
Listing 10 Avro IDL interface code example

The language provides the following items:

Protocols: A protocol is used to group messages and type definitions.
Imports: An Avro IDL document can import protocols defined in other files.
Enumerations.
Records: They are similar to C structs.
Primitive types: It includes support for int, long, string, Boolean, float
Messages: They are equivalent to functions in programming languages.
Annotations: Annotations are used to add additional properties to types and fields.
9.1.7

WSDL

The current W3C recommendation is WSDL 2.0, but WSDL 1.1 is still relatively widely used.
The structure of the documents is quite similar for both versions, as illustrated in Figure 13.

PLANTCockpit

39

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Figure 13: WSDL 1.1 and 2.0 Document Structure (Cristcost, 2007)
Table 6: Structure of WSDL 1.1 and WSDL 2.0 files
WSDL 1.0
Description
(WSDL 2.0)

definition

The root element of the WSDL document. It defines the service

name, and the namespaces used in the document.

(description)
types
(types)

message
(N/A)

portType

The types section describes the input and output parameters of

operations in XML Schema format. This is all the type information
needed for the information exchange between the service
consumer and provider. External XML Schemas (.xsd files) can
also be imported.
Messages contain the information required to complete the
operation, and contain zero or more message parts, representing
parameters. The parts have name attributes, unique within the
message, and reference elements in the types section. Messages
do not specify direction. In WSDL 2.0, messages are eliminated,
and the input and output parameters of the operations simply
reference the types directly.
This defines the Web Service and each operation that the port
exposes.

(interface)

PLANTCockpit

40

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

WSDL 1.0
(WSDL 2.0)

operation
(operation)

Binding

Classification PU

Description

This defines SOAP actions and the message encoding, as well as

the input and output parameters for the operation. If the input is
omitted, the operation represents an event. If the output is
omitted, no response is expected. If both input and output are
specified, the operation is a standard request-response operation.
This element specifies the SOAP binding style and transport
protocol for the Web Service (portType or interface). The binding
style can be either rpc or document. One binding is specified
for each protocol that a Web Service supports.

(binding)

service

The service element groups related ports together. None of the

ports communicate with each other, and if the ports have the
same portType and different bindings, then each provides
semantically equivalent behavior. A client can choose which port
to communicate with based on whatever criteria.

(service)

port

This defines the connection point to a Web Service, typically an

HTTP URL string.

(endpoint)

9.1.8

Interface Description Language (IDL)

IDL is a specification language created in Queens University (Canada) in 1980. Some of its
remarkable features are:
IDL can be used to define complex data structures in a formal way easily.
There are tools that can generate the source code skeleton from IDL documents.
IDL is independent from the programming language, so data can be exchanged
between programs written in different languages or platforms.
This is an example of the syntax of this language:
temperatureData => currentValue : integer,
units: string;

This language includes mechanisms to specify the following concepts:

Names (or identifiers)
Node types
Classes
Graphs

PLANTCockpit

41

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

Attribute types
Structures and instances
Membership, narrowing and widening
9.2

Comparison table of interface definition languages

In order to identify an interface definition language that can be used for the external
interfaces of PLANTCockpit, a comparison of the described interface definition languages
has been performed. Table 7 lists the criteria of this comparison.
Name

Technology
for which it is
designed

Creator /
Maintainer

Based
on

Supported primitives

Syntax
type

OMG
IDL

RPC

Object
Management
Group

Modules, operations,
exceptions, attributes,
exceptions,
inheritance, basic
types, structs, unions,
enumerated types,
arrays, sequences,
strings, constants,
type declaration,
forward declaration,
scoped names.

C++/Java
style

MIDL

Designed for
COM/DCOM

Microsoft

OMG
IDL

Adds support for

COM/DCOM features.

C++/Java
style

XPIDL

Mozilla
XPCOM

Mozilla

OMG
IDL

Adds support for IIDS

and some additional
types.

C++/Java
style

Apache RPC
Thrift

Apache

Basic types, structs,

containers (ordered
lists, unordered sets
and maps),
exceptions, services.

C style

Etch
IDL

RPC

Apache

Basic types, extended C++/Java

style
types (datetime, list,
set, map), objects,
constants,
enumerations, arrays,
exceptions, messages,
includes, services,
annotations, modules.

Avro
IDL

RPC

Apache

Protocols, imports,
enumerations,
records, primitive

PLANTCockpit

C++/Java
style

42

Project - No 260018
Date 13/04/2012
Technical Report - External interface specification, first draft

Classification PU

types, messages,
annotations.
WSDL

Web Services

W3C

Types, message,
operation, port type,
binding, port, service.

IDL

RPC

Queens
University
(Canada)

Names (or identifiers), Own

node types, classes,
syntax
graphs, attribute types,
structures and
instances,
membership,
narrowing and
widening.

XML

Table 7 Comparison of Interface definition languages

Due to the adjustment of PLANTCockpit towards web services and the widespread use of
XML as a syntax element in the project, it becomes apparent that WSDL is the most feasible
language to use. It therefore seems reasonable to use WSDL for the specification of the
external interfaces of PLANTCockpit.

PLANTCockpit

43