IoT@Work

16/12/2011

IoT@Work/ WP1/D1.1/1.2

IoT@Work WP 1 – PLUG&WORK IOT REQUIREMENT ASSESSMENT AND ARCHITECTURE D1.1 – State of the art and functional requirements in manufacturing and automation Reference:

IoT@Work/WP1/D1.1/1.2

Category:

Report

Deliverable Responsible:

TXT

Author(s):

D. Rotondi, A. Galipò, S. Piccione (TXT) H.–P. Huth, A. M. Houyou, J. W. Walewski (Siemens) C. Kloukinas (City) H. Trsek (inIT) J. Claessens (EMIC)

Due Date:

M6

Deliverable Date:

30/11/2010 – Revised on 20/12/2011

Project Start Date:

01/06/2010

Project Duration:

36 Months

Status:

Final (Revision of version 1.1)

Availability:

Public

Category: Report

Status: Final

Availability: Public

16/12/2011

Pag. 2


Executive Summary This document is a revision of the D1.1. IoT@Work/WP1/D1.1/1.1 delivered on November 30th 2010 to take into accounts the reviewers’ comments as reported in the 1st Technical Review Report. Full details of the changes made are available at IoT@Work/WP1/D1.1/1.2/D1.1-RevisionsDetails.doc. This document reports the first iteration of the activities envisaged in the IoT@Work WP1 “Plug&Work IoT Requirement Assessment and Architecture” and specifically on the update of the state of art for issues related to Plug&Play, from an Internet of Things point of view, in manufacturing and automation, as well as on acquiring functional requirements on which to base the architecture and functional specifications to be addressed by subsequent activities in WP1, WP2 and WP3. This 1st iteration had the objective to collect the most central and critical aspects of Plug&Work in the industrial environment. The analysis reported in this document has identified three different main scenarios (which are reported in Appendix B - Agile Manufacturing, Appendix C – Large Scale Manufacturing and Appendix D – Remote Maintenance): • Agile Manufacturing: a production approach heavily based on the availability of manufacturing support technology that can be easily reconfigured to quickly respond to market changes still providing full control of production costs and quality. Agile manufacturing is universally considered as the next step after the lean production methodology; • Large Scale Manufacturing: this scenario is representative of large production arrangements where many different production sites have to be coordinated and integrated. This scenario is comprehensive of both situations in which the different sites belong to the same producer, as well as situations in which the involved sites belong to different producers pertaining to an highly integrated supply chain; • Remote Maintenance: this scenario helps analysing situations in which external providers (e.g. robots/tools providers) have direct access to devices or data within the production sites to assure production continuity for example doing preventive maintenance. The scenarios based approach was helpful both in splitting the area of investigation and in providing priority indicators helpful in evaluating the relevance of identified needs for different production environments. This approach will provide further benefits in identifying validation contexts and in designing validation scenarios. This document, as activities related to analysis and design proceed, will be updated with new releases, in particular for the appendixes, to assure that it is always in line with the progression of the analysis activities.

Category: Report

Status: Final


16/12/2011

Pag. 3


Document History Version History Version 0.1 0.2 0.3 0.4 0.5 0.6

Status Draft Draft Draft Draft Draft Draft

Date July 2010 July 2010 Aug 2010 Sept 2010 Oct 2010 Oct 2010

0.7 0.8

Draft Draft

Nov 2010 Nov 2010

0.9

Draft

Nov 2010

1.0 1.1 1.2

Draft Final Final

Nov 2010 Nov 2010 Dec 2011

Author(s) M. Villa M. Villa H. P. Huth, C. Kloukinas M. Villa, M. Comolli D. Rotondi, H. P. Huth D. Rotondi, M. Comolli, H. P. Huth, A. M. Houyou, C. Kloukinas, H. Trsek D. Rotondi, M. Comolli, C. Seccia H. P. Huth, A. M. Houyou, C. Kloukinas, H. Trsek, D. Rotondi, C. Seccia H. P. Huth, A. M. Houyou, C. Kloukinas, H. Trsek, D. Rotondi, C. Seccia A. M. Houyou, D. Rotondi, C. Seccia A. M. Houyou, D. Rotondi, C. Seccia A. M. Houyou, D. Rotondi, C. Kloukinas, J. W. Walewski, S. Piccione, A. Galipò

Summary of Changes Version 0.1 0.2 0.3

Section(s) Initial ToC Initial ToC Chapter 3

0.4

Chapter 3

0.5 0.6 0.7 0.8 0.9 1.0 1.1

All Sections All Sections All Sections All Sections All Sections All Sections All Sections

1.2

List of Acronyms, Chapters 2-4 and 9

Category: Report

Synopsis of Change Document structure revised after Telco Added Siemens and City contributions to chapter 3 Added initial contributions from InIT to sections 3.2.1 and 3.3.1 Added Siemens and TXT contributions TXT contributions refinement Added missing contributions Refinements and cross-checking Refinements and cross-checking Refinements and cross-checking Final revisions and refinements; approval of the document Revisions according to the comments reported in the 1st Technical Review Report

Status: Final


16/12/2011

Pag. 4


Contents 1

2

Introduction ............................................................................................14 1.1

Scope of WP1 and Task 1.1 ....................................................................... 14

1.2

Scope of this Deliverable ............................................................................ 15

1.3

Relationship with other tasks and WPs....................................................... 15

1.4

Structure of this document.......................................................................... 15

Monitoring of Technological Evolution................................................17 2.1

Plan for Monitoring of Technological Evolution ........................................... 17

2.2

State of the Art Update on the topics addressed by IoT@Work .................. 17

2.2.1 Levels

Applications Enabled by Internet Technologies in the Factory Control and Field 17

2.2.1.1 2.2.1.2 2.2.1.3 2.2.1.4 2.2.1.5 2.2.1.6 2.2.1.7 2.2.1.8 2.2.2

Communication Network Technologies and Deployment.................................. 20

2.2.2.1 2.2.2.2 2.2.2.3 2.2.2.4 2.2.2.5 2.2.2.6 2.2.2.7 2.2.2.8 2.2.2.9 2.2.3

Introduction.................................................................................... 25 CORBA ......................................................................................... 26 TAO............................................................................................... 26 Java............................................................................................... 27 R-T Java........................................................................................ 27 Zen ................................................................................................ 27 Web Services ................................................................................ 27 OPC-UA ........................................................................................ 29 Data Distribution Service ............................................................... 29 Initial Conclusion ........................................................................... 30

Security Technologies in Automation Networks ................................................ 31

2.2.4.1 2.2.4.2 2.2.4.3 2.3

Factory Communication Domains .................................................. 20 Industrial Communication Technologies ........................................ 21 Wireless Extensions ...................................................................... 22 Network Planning and Deployment................................................ 22 Network Monitoring and Management ........................................... 23 Plug and Play technologies ........................................................... 23 IP-to-the-field................................................................................. 23 Device Management and Device Metadata ................................... 24 Initial Conclusion ........................................................................... 25

Middleware and Software Technologies in Automation Systems...................... 25

2.2.3.1 2.2.3.2 2.2.3.3 2.2.3.4 2.2.3.5 2.2.3.6 2.2.3.7 2.2.3.8 2.2.3.9 2.2.3.10 2.2.4

Introduction.................................................................................... 17 Device communication setup ......................................................... 18 Device and network configuration.................................................. 18 Diagnosis and status monitoring.................................................... 18 Real-time control communication................................................... 19 Process data collection.................................................................. 19 Process visualisation ..................................................................... 19 Parameterisation ........................................................................... 20

Bridging shop floor and top floor .................................................... 31 Perimeter security between top floor and shop floor ...................... 32 Towards more in-depth security..................................................... 33

Other relevant EU & National initiatives ...................................................... 35

2.3.1 2.3.2

Introduction ........................................................................................................ 35 European Projects ............................................................................................. 35

2.3.2.1 2.3.2.2 Category: Report

ITEA SIRENA Project .................................................................... 35 VAN Project................................................................................... 36 Status: Final


16/12/2011

Pag. 5

2.3.2.3 2.3.2.4 2.3.2.5 2.3.2.6 2.3.2.7 2.3.2.8 2.3.2.9 2.3.2.10 2.3.2.11 2.3.2.12 2.3.2.13 2.3.2.14 2.3.3 2.3.4

Global Megatrends and their Relevance for Automation............................. 45

2.5

Trends in Automation ................................................................................. 48

6

Overview ............................................................................................................ 48 General Trends in Automation Standards ......................................................... 48 HW Trends......................................................................................................... 50 Software Trends................................................................................................. 50 Wireless ............................................................................................................. 51 Security technology............................................................................................ 52 Disruptive technologies...................................................................................... 52

Scenarios................................................................................................54 3.1

Scenarios Definition Methodology .............................................................. 54

3.2

Collected Scenario Telegrams.................................................................... 54

3.3

Scenario Clusters ....................................................................................... 58

3.3.1 3.3.2 3.3.3 3.3.4

5

SemProM Project .......................................................................... 44 WS4Dsec Project .......................................................................... 45 inITial Project................................................................................. 45

2.4

2.5.1 2.5.2 2.5.3 2.5.4 2.5.5 2.5.6 2.5.7

4

SOCRADES Project ...................................................................... 36 HYDRA Project.............................................................................. 37 CASAGRAS Project ...................................................................... 38 flexWARE Project .......................................................................... 39 GEMOM Project ............................................................................ 39 CHAT Project ................................................................................ 39 SENSEI Project ............................................................................. 40 IoT-A Project ................................................................................. 41 IoT-i Project................................................................................... 41 Open Garments Project................................................................. 42 TIPSS Project................................................................................ 42 CoReNet Project ........................................................................... 43

IoT European Research Cluster ........................................................................ 43 National projects ................................................................................................ 44

2.3.4.1 2.3.4.2 2.3.4.3

3


Scenario Clusters Overview .............................................................................. 58 Agile Manufacturing ........................................................................................... 58 Large Scale Manufacturing ................................................................................ 58 Remote Maintenance......................................................................................... 59

Initial Requirements Specification .......................................................60 4.1

Introduction to the Requirements Collection Process.................................. 60

4.2

IoT@Work Target Facets ........................................................................... 60

4.3

Requirements Coverage............................................................................. 62

4.4

Conclusions and Next Steps....................................................................... 66

Appendix A – External Scenarios Telegram Template .......................67 5.1

Introduction ................................................................................................ 67

5.2

IoT@Work Scenario Template Objective.................................................... 67

5.3

Scenario Template Structure ...................................................................... 67

5.4

Scenario telegram Example: Brewery Automation...................................... 68

Appendix B - Agile Manufacturing .......................................................71 6.1

Scenario meta-data .................................................................................... 71

6.1.1

Suitable telegrams for agile manufacturing ....................................................... 71

Category: Report

Status: Final


16/12/2011

6.1.2 6.1.3 6.1.4

List of available references ................................................................................ 72 List of known contacts........................................................................................ 72 Urgent Questions that Need Follow-up (and Answers) ..................................... 72

Definition of Agile Manufacturing ................................................................ 72

6.3

Needs and advantages of agility................................................................. 74

6.4

Where and how to implement the agility ..................................................... 75 What can change? ............................................................................................. 75 Why does it need to change? ............................................................................ 76 When does it need to change? .......................................................................... 76 What needs to be preserved?............................................................................ 76 How does a system adapt? ............................................................................... 76 What are the security risks? .............................................................................. 76 Relevant domains & literature............................................................................ 77

6.5

CRF Automotive Plant Issues..................................................................... 78

6.6

The Lemgo Model Factory as an example for agile manufacturing ............. 78

6.6.1 6.6.2 6.6.3 6.6.4 6.6.5 6.6.6 6.6.7

Introduction to the LMF ...................................................................................... 79 LMF extension ................................................................................................... 79 The Transformation Process of the LMF ........................................................... 80 Hardware Aspects of Transformation ................................................................ 80 Automation Aspects of Transformation.............................................................. 81 Flexibility in the LMF .......................................................................................... 84 Analysis of the Lemgoer Modellfabrik agility ..................................................... 85

6.7

Requirements for Transparent Agility ......................................................... 87

6.8

Security ...................................................................................................... 87

6.9

IoT@Work Support for agility...................................................................... 89

Appendix C – Large Scale Manufacturing ...........................................90 7.1


7.1.1 7.1.2

Suitable telegrams for Large Scale Manufacturing............................................ 90 List of available references ................................................................................ 90

7.2

Definition of Large Scale Manufacturing ..................................................... 91

7.3

Scenarios and industry data on large scale manufacturing ......................... 91

7.3.1 7.3.2

7.4

Overview ............................................................................................................ 91 Problems in the current Solution........................................................................ 92

System descriptions ................................................................................... 93

7.4.1 7.4.2 7.4.3

8


6.2

6.4.1 6.4.2 6.4.3 6.4.4 6.4.5 6.4.6 6.4.7

7

Pag. 6

Network View - Physical Topology .................................................................... 93 Network View - Logical Structure (Overlays) ..................................................... 95 Size .................................................................................................................... 95

Appendix D – Remote Maintenance .....................................................96 8.1


8.1.1 8.1.2 8.1.3 8.1.4

Suitable Telegrams for Remote Maintenance ................................................... 96 List of available references ................................................................................ 98 List of known contacts........................................................................................ 99 Urgent Questions that Need Follow-up (and Answers) ..................................... 99

8.2

Definition of Remote Maintenance.............................................................. 99

8.3

Scenarios and industry data on Remote Maintenance................................ 99

8.3.1 8.3.2

8.4

Overview ............................................................................................................ 99 System descriptions........................................................................................... 99

Processes ................................................................................................ 100

Category: Report

Status: Final


16/12/2011


8.5

Responsibilities ........................................................................................ 100

8.6

Security .................................................................................................... 100

8.7

IoT@Work Support for Remote Maintenance ........................................... 101

8.7.1 8.7.2 8.7.3

9

Pag. 7

Network support (middleware, resource management)................................... 101 Auto-configuration needs ................................................................................. 101 Security requirements ...................................................................................... 101

References............................................................................................102

Category: Report

Status: Final


16/12/2011

Pag. 8


List of Figures Figure 2.1 – Paradigm shift to network-centric model ([FieldUb])............................. 17 Figure 2.2 – Automation Pyramid Focused on Communication ............................... 21 Figure 2.3 – Classification of industrial Ethernet protocols ([Jasperneite]) ............... 21 Figure 2.4 – PROFINET Device Configuration ........................................................ 25 Figure 2.5 – Example Security in Automation.......................................................... 33 Figure 2.6 – Lead Markets for Automation Industry (source [Bent]) ......................... 46 Figure 2.7 – Personnel Shortage (source [Maes]) ................................................... 47 Figure 3.1 – Scenario Driven Requirement Analysis................................................ 54 Figure 3.2 – Scenario Telegram Analysis ................................................................ 56 Figure 3.3 – Telegram Analysis Criteria................................................................... 57 Figure 5.1 – Basic bottling operation ....................................................................... 69 Figure 6.1 – Non-Stop Manufacturing Excellence (source [3])................................. 75 Figure 6.2 – Former setup of the LMF ..................................................................... 79 Figure 6.3 – LMF extended with additional modules and a control room ................. 80 Figure 6.4 – Mechanical setup of the LMF............................................................... 81 Figure 6.5 – Configuring the Bus Topology using PC WorX .................................... 82 Figure 6.6 – Current architecture of the LMF ........................................................... 83 Figure 6.7 – Assigning Variable Names to IO ports ................................................. 84 Figure 6.8 – Structure and Connection of the flexible production cell ...................... 85 Figure 7.1 – Overall Network Structure (source [4])................................................. 93 Figure 7.2 – Network topology of a site (source [1]) ................................................ 94 Figure 8.1 – Example network in factory automation ............................................... 99 Figure 8.2 – More detailed view of factory network................................................ 100

List of Tables Table 1.1 – Task 1.1 structure and outcomes.......................................................... 14 Table 2.1 Relative Comparison of different middleware technologies...................... 31 Table 2.2 – Top Floor vs Shop Floor views comparison .......................................... 32 Table 4.1 – Agile Manufacturing requirements summary......................................... 63 Table 4.2 – Large Scale Manufacturing requirements summary.............................. 64 Table 4.3 – Remote Maintenance requirements summary....................................... 64 Table 4.4 – Requirements vs Functionalities summary table ................................... 65

Category: Report

Status: Final


16/12/2011

Pag. 9


List of Acronyms ARP

ARQ

BMBF BOOTP

CCM

DCOM

DCS

DHCP

DPWS

EDDL

FDT/DTM

Foglets

HMI

IDL

Category: Report

Address Resolution Protocol is a protocol used in local area networks to translate IP addresses to Ethernet addresses Automatic Repeat reQuest or Automatic Repeat Query is an data communication error-control mechanism based on the use of acknowledgements and timeouts to achieve reliable data transmission over an unreliable service Bundesministerium für Bildung und Forschung German Ministry for Research and Education Bootstrap Protocol is a network protocol used by clients to obtain an IP address from a configuration server. The DHCP is a more advanced protocol that has superseded the use of BOOTP CORBA Component Model is part of CORBA and it describes a standard application framework for CORBA components that makes possible to use a network infrastructure to communicate with sensors, controllers, operator terminals and actuators Distributed Component Object Model is a Microsoft technology for communication among distributed software components Distributed Control System is a process control system using a network infrastructure to communicate with a set of sensors, controllers, operator terminals and actuators Dynamic Host Configuration Protocol is a protocol used on IP networks for configuring network devices. There are specific versions of DHCP for IPv4 and IPv6 Devices Profile for Web Services defines a minimal set of functionalities to enable secure Web Service messaging, discovery, description, and eventing on resource-constrained devices. It is similar to Universal Plug and Play (UPnP) with the main difference of being aligned with Web Services technology Electronic Device Description Language is used by manufacturers to describe the information that is accessible in digital devices Field Device Tool/Device Type Manager is an open framework for field device tools. FDT defines the data exchange interface between field devices and each of the control systems, engineering tools and asset management system tools. DTM is the software component that works on the framework and facilitates operation through a graphical interface Foglets or Utility fogs The term describes a collection of cooperating tiny robots to perform a specific function or achieve a specific objective [StorrsHall]. Human Machine Interface The user interface in a manufacturing or process control system. Normally the HMI provides a graphics-based representation of an industrial control and monitoring system. Sometimes it also identified as MMI (man machine interface). The HMI typically resides in a Windows based computer that communicates with a specialized computer (e.g. PLC, PAC, DCS) in the plant Interface Description Language or Interface Definition Language is a specification language used to describe, in a programming language independent way, a software component's interface. IDLs are normally used in remote procedure call software frameworks Status: Final


16/12/2011

IEEE 802

IETF

IGMP

IoT

MRP

OLE

OPC

OPC-A&E

OPC Batch Category: Report

Pag. 10


Institute of Electrical and Electronics Engineers The Institute of Electrical and Electronics Engineers is an international non-profit, professional organization for the advancement of technology related to electricity and electronics. IEEE 802 refers to a family of IEEE standards dealing with local and metropolitan area networks, e.g. Ethernet (IEEE 802.3) or Wireless LAN (IEEE 802.11) Internet Engineering Task Force It is an open standards organization, based on volunteers, that develops and promotes Internet standards, in particular the ones related to the TCP/IP and Internet protocol suite. The IETF is formally a part of the Internet Society and is overseen by the Internet Architecture Board (IAB) Internet Group Management Protocol is a communications protocol used on IP networks by hosts and routers to manage multicast group memberships Internet of Things The CERP-IoT (Cluster of European Research Projects on the Internet of Things) Internet of Things Strategic Research Roadmap (September 2009) states for IoT “... an integrated part of Future Internet and could be defined as a dynamic global network infrastructure with self-configuring capabilities based on standard and interoperable communication protocols where physical and virtual “things” have identities, physical attributes, and virtual personalities and use intelligent interfaces, and are seamlessly integrated into the information network. In the IoT, “things” are expected to become active participants in business, information and social processes where they are enabled to interact and communicate among themselves and with the environment by exchanging data and information “sensed” about the environment, while reacting autonomously to the “real/physical world” events and influencing it by running processes that trigger actions and create services with or without direct human intervention.” Media Redundancy Protocol It is a protocol used to increase the availability of a communication networks introducing redundancy. It is defined by the IEC 62439 standard suite. In particular the IEC 62439 FDIS standard defines four different solutions for redundancy: • MRP - Media Redundancy Protocol based on a ring topology, • PRP – Parallel Redundancy Protocol, • CRP - Cross-network Redundancy Protocol • BRP – Beacon Redundancy Protocol. Object Linking and Embedding is a Microsoft technology to embed and/or link documents and other objects OLE for Process Control It was originally a set of standards specification based on Microsoft OLE structuring the communication of real-time plant data between control devices from different manufacturers. Currently the OPC specifications are managed by the OPC Foundation. Since June 2006 OPC is a set of seven standards specifications (and two more in the standardization process). The original standard is currently known as OPC Data Access or OPC Data Access Specification. OPC is heavily used not only within the process industries, but also in discrete manufacturing OPC Alarms & Events provides alarm and event notifications on demand (in contrast to the continuous data flow of Data Access). These include process alarms, operator actions, informational messages, and tracking/auditing messages OPC Batch Status: Final


16/12/2011

OPC Complex Data

OPC-DA

OPC-DX

OPC-HDA

OPC Security

OPC-UA

OPC XML-DA

OpenVPN

ORB

PAC

PLC

PDA POA Category: Report

Pag. 11


This specification carries the OPC philosophy to the specialized needs of batch processes. It provides interfaces for the exchange of equipment capabilities (corresponding to the S88.01 Physical Model) and current operating conditions OPC Complex Data A companion specification to Data Access and XML-DA that allows servers to expose and describe more complicated data types such as binary structures and XML documents OPC Data Access Used to move real-time data from PLCs, DCSs, and other control devices to HMIs and other display clients. The Data Access 3 specification is now a Release Candidate. It leverages earlier versions while improving the browsing capabilities and incorporating XML-DA Schema OPC Data eXchange This specification takes us from client/server to server-to-server with communication across Ethernet fieldbus networks. This provides multivendor interoperability! And, oh by the way, adds remote configuration, diagnostic and monitoring/management services OPC Historical Data Access Where OPC Data Access provides access to real-time, continually changing data, OPC Historical Data Access provides access to data already stored. From a simple serial data logging system to a complex SCADA system, historical archives can be retrieved in a uniform manner OPC Security All the OPC servers provide information that is valuable to the enterprise and if improperly updated, could have significant consequences to plant processes. OPC Security specifies how to control client access to these servers in order to protect this sensitive information and to guard against unauthorized modification of process parameters OPC-UA A new set of specifications that are not based on Microsoft COM that will provide standards based cross-platform capability OPC XML-DA provides flexible, consistent rules and formats for exposing plant floor data using XML, leveraging the work done by Microsoft and others on SOAP and Web Services OpenVPN is a free and open source software application delivered under the GNU General Public License that provides virtual private network (VPN) features for creating secure point-to-point or site-to-site connections. It uses SSL/TLS for encryption and is able to cross network address translators (NATs) and firewalls. OpenVPN allows mutual authentication of peers using pre-shared secret keys, certificates, or username/password Object Request Broker in Common Object Request Broker Architecture (CORBA ORBs manage the transformation (called marshalling/serialization and un-marshalling/deserialization) of in-process data structures to and from the byte sequence transmitted over the network Programmable Automation Controller is a programmable microprocessor-based device used in discrete manufacturing, process control and remote monitoring applications. PACs combine the functions of a PLC with the greater flexibility of a PC, and are able to provide in a single system the functionalities of a DCS and PLC Programmable Logic Controller A programmable microprocessor-based device used in discrete manufacturing to control assembly lines, machinery or other types of mechanical, electrical and electronic equipment on the shop floor Personal Digital Assistant A kind of palmtop computer Portable Object Adapter Status: Final


16/12/2011

PROFIBUS

PROFIBUS GSD

PROFIBUS GSDML PROFINET

PROFINET-IRT

PROFIsafe

REST

SCADA

SOA

Category: Report

Pag. 12


An object adapter is a mechanism to connect a request submitted to an object reference to the code able to service that request. The POA is a particular type of object adapter that is defined in CORBA Process Field Bus is a standard for field bus communication in automation technology. There are two variants of PROFIBUS currently in use: • PROFIBUS DP (Decentralized Peripherals) is used to manage sensors and actuators via a centralized controller in production (factory) automation applications. This is the most commonly variant; • PROFIBUS PA (Process Automation) is used to monitor measuring equipment via a process control system in process automation applications The initial version of PROFIBUS, PROFIBUS FMS (Fieldbus Message Specification) was not flexible enough. Even if PROFIBUS FMS is still in use, the majority of users find newer solutions to be useful. PROFIBUS Generic Station Description is used to describe device capabilities. These descriptions are normally arranged in files (so called GSD files). With a GSD file, system integrators can determine basic data such as the communications options and the available diagnostics PROFIBUS Generic Station Description XML GSDML is an XML format of GSD PROFINET is the open industrial Ethernet standard for automation. PROFINET uses TCP/IP and IT standards and supports real-time Ethernet communications PROFINET Isochronous Real Time is a PROFINET profile supporting real time communication for systems requiring sub-microsecond synchronization, like high-performance motion control systems. PROFINET-IRT can provide cycle times of 1 ms, with 1 µs jitter accuracy, and guaranteed determinism PROFIBUS safety or PROFINET safety is an open functional safety communication technology for distributed automation systems that integrates safety into the PROFIBUS/PROFINET fieldbus technologies as a separate layer on top of the fieldbus application layer and reduces the error probability of the data transmission to the level required by the relevant standards. PROFIsafe can be used in safety applications up to: Safety Integrity Level 3 according to IEC 61508, Performance Level "e" according to ISO 13849, or Category 4 according to EN 954-1. PROFIsafe is standardized in IEC 61784-3-3 Representational State Transfer is a software architecture for distributed systems in the context of HTTP (even if it can be based on other applications protocols that provide support for meaningful resources representational states) centered around the transfer of representations of resources, where a resource is potentially any coherent concept that can be addressed and a representation is normally a set of information that capture the state of the corresponding resource. A system or service REST complaint is referred to as a RESTful system/service. Supervisory Control And Data Acquisition refers to industrial control systems: computer systems that monitor and control industrial processes or infrastructures Service Oriented Architecture provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different Status: Final


16/12/2011

UPnP

VTP

W3C

WS&AN

Category: Report

Pag. 13


applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications Universal Plug and Play UPnP is a set of networking protocols finalised to enable networked devices to discover other network devices and the services these provides. The UPnP technology is promoted by the UPnP Forum VLAN Trunking Protocol VTP is a Cisco proprietary protocol, acting at layer 2, used to manage switched network using VLANs. When a new VLAN is added on one VTP server, the VLAN is automatically configured on all switches in the domain. Comparable IEEE standards used by other manufacturers are: GVRP (GARP VLAN Registration Protocol) or the more recent MVRP (Multiple VLAN Registration Protocol). World Wide Web Consortium is the main international standards organization for the World Wide Web. Amongst others, it is responsible for the XML standardization Wireless Sensor and Actuator Network refers to a group of sensors and actuators linked by wireless communication facilities to perform distributed sensing and actuation tasks

Status: Final


16/12/2011

Pag. 14


1 Introduction 1.1

Scope of WP1 and Task 1.1

WP1 “Plug&Work IoT Requirement Assessment and Architecture” has been structured in such a way to have an internally phased approach. Indeed the analysis and specification work envisages a first iteration whose objectives are to collect the most central and critical aspects of Plug&Work in the industrial environment and quickly provide a 1st set of specifications so that the design and development phases can proceed giving the opportunity to anticipate both the development and the onfield validation. Subsequently the analysis and specification will be reiterated taking into account both advances in the technological scenario, as well as, and more significantly, first outcomes of the development and experimentation results. This 2nd iteration will also cover less central or critical aspects therefore providing a complete set of specifications to be used to have a functionally complete implementation to be validated in the case study. Finally there will be a final revision of the specifications which takes into accounts the outcomes of the validation of the complete system. Within WP1 Task 1.1 “Assessment of Assumptions and Architecture Requirements” has the specific objective to monitor technological evolution in the field, as well as to structure and manage requirements specifications. To provide a better understanding of the activities to be performed within this task it has been structured in a set of sub-tasks as detailed below. Subtask

Title

Objectives

Deliverable

T1.1.1

State of the art analysis refinement

Near term scenarios and envisaged operational and technological scenarios Identify architectural and operational needs and evaluate architectural design, choices and assumptions.

D1.1 (M6)

T1.1.2

Architecture requirements & assumptions

Definition of concepts for Plug&Work Implications on technical requirements WP2/3

D1.2 (M14)

T1.1.3

Pilot Scenario Identification

Devise the IoT@Work Pilot Scenario Identify requirements, components, elements of the validation plan (WP4)

D1.1 (M6)

T1.1.4

Architecture requirements & assumptions refinement

Based on technologies evolution Based on the outcomes of the implementation and validation activities

D1.3 (M30)

Table 1.1 – Task 1.1 structure and outcomes

Category: Report

Status: Final


16/12/2011

1.2

Pag. 15


Scope of this Deliverable

As stated in the IoT@Work DoW, the objectives of deliverable D1.1 are: • describe how the project plans to monitor technological evolution along the IoT@Work lifecycle (see §2.1 on pag. 17); • update the State of the Art reported in the DoW, adding or revising aspects and issues that may have changed since the preparation of the IoT@Work proposal (see §2.2 on pag. 17); • devise an initial IoT@Work Pilot Scenario (see §3 on pag. 54). The operative approach adopted in WP1 to perform the analyses activities and identify the relevant issues is based on the identification of three scenario areas (Agile Manufacturing, Large Scale Manufacturing”, and Remote Maintenance) and of a set of specific production scenarios (which have been called scenario telegrams and provided, and will provide, the input for the three scenarios) in order to better identify issues and collect information. The analyses performed for the telegram scenarios was currently finalised to collect specific information for the kind of work envisaged in this initial phase of the project (i.e. the initial activities in WP1-WP3), so that to be able to quickly identify priority issues on which to focus this initial activities. This operative approach will be pursued for the future also both as a way to operatively monitor the technological evolution, and as an instrument to improve the future activities of design and specifications. The three scenarios were also used to drive the state of the art update, so that we had an initial assessment of the critically of the different technological areas and of suitability of the analysed technologies. Finally, these scenarios have also provided input for the initial pilot identification. Activities that will be finalised in the immediate future as indicated in the previous page.

1.3

Relationship with other tasks and WPs

The activity performed in this initial phase of WP1 was synergic with the ones in WP2 and WP3. As already highlighted the operative approach adopted in WP1 based on a set of specific application scenarios (the scenario telegrams) and on the three specific areas, was also helpful in collecting the information required for the initial threat analyses (reported in D3.1 - Threat Analysis) and for identifying issues and aspects related with naming in the application contexts addressed by IoT@Work (reported in D2.1 - IoT Addressing Schemes Applied To Manufacturing). The appendixes in this deliverable are thus relevant also for the mentioned deliverables.

1.4

Structure of this document

This document has been organised in three main sections devoted to specific deliverable’s objectives: • the 1st section (§2 Monitoring of Technological Evolution) is focalised in detailing both the technology monitoring approach that has been set-up and will be pursued in the future, and on a revision of the state of art provide in the DoW. Additionally this section provides a review of relevant national and European R&D projects (see §2.3 on pag. 35) in the immediate past of currently active,

Category: Report

Status: Final


16/12/2011

• •

Pag. 16


the 2nd section (§3 Scenarios on pag. 54) provides detail on the addressed scenarios and constitute a first analysis of possible pilot scenarios, the 3rd section (§4 Initial Requirements Specification on pag. 60) is devoted to summarise the outcomes of the analysed scenarios in terms of initial requirements. This analysis will be prosecuted in the future with further revisions of the following deliverable and providing input for deliverable D1.2.

There is also a set of appendixes providing details on the scenario telegrams and on each scenario areas. These appendixes, which have to be considered as the collection of a distinct set of working documents, have been added to provide more details on the performed activities, and some additional elements to substantiate what is reported in the main sections. Indeed, references to papers or other external material is numbered and managed autonomously in each of the telegrams and scenarios collected in the appendixes. As working documents these appendixes have incomplete parts (most of them because they were not considered critical in this initial phase) and will quickly evolve in the envisaged updated of this document. Care has been put in highlighting the parts to be analysed in the immediate future. Additionally, to improve document readability, a table of the acronyms used in the document has been inserted at the beginning. The table provides a short description of the mentioned abbreviations and can be used as a quick reference to the technologies and approaches mentioned in the deliverable. Finally the deliverable reports an extensive reference section.

Category: Report

Status: Final


16/12/2011

2

Pag. 17


Monitoring of Technological Evolution

2.1

Plan for Monitoring of Technological Evolution

To ensure that the IoT@Work results can take advantage from recent developments outside of the project, a monitoring process runs in parallel to the technical developments. Starting by identifying the topics relevant for the project, this process will then report important trends and regularly update those reports. The first step is to identify current State of the Art in Automation (see §2.2) and relevant bodies or initiatives driving those issues (see §2.3 on pag. 35). A trend in technical evolution - as we understand it - is an already ongoing course or tendency a certain technology takes. As such the following study is inherently rooted in the state of the art and the ultimate goal is to understand the different directions a certain technology may take, to estimate time schedules and probabilities for foreseeable development steps. In the introduction the role and objective played by the scenario’s telegrams and the scenario areas have been already clarified within the scope of this chapter on the monitoring approach.

2.2

State of the Art Update on the topics addressed by IoT@Work

2.2.1

Applications Enabled by Internet Technologies in the Factory Control and Field Levels

2.2.1.1 Introduction For several years now, factory automation has benefited from the use of internet technologies. Although initially applied mostly at the information level where there were no real-time requirements, Ethernet and Internet technologies are nowadays used to enable applications at the control and field levels. This is due to technological developments such as switched Ethernet, higher throughput (Fast Ethernet) and the extensive suite of Internet protocols that enable, for instance, multicast filtering and other advanced tasks. From a very high level perspective, this is a paradigm shift from specialized solutions towards Internet technologies [FieldUb].

Figure 2.1 – Paradigm shift to network-centric model ([FieldUb]) The Internet protocols that support factory automation applications range from link layer to application layer protocols. Broadly speaking, the types of applications supported can be categorised as real-time control, process data and maintenance information collection and device/system configuration. The following paragraphs briefly describe some key applications that are enabled by one or more protocols of the internet suite [PNIT]. Category: Report

Status: Final


16/12/2011

Pag. 18


2.2.1.2 Device communication setup Ethernet enabled automation devices need to be set up for proper communication within a network segment before they can even be configured to perform their intended task. First and foremost, a valid IP address needs to be assigned to the device (a subnet mask and gateway address can also be assigned). For this purpose, several methods are available. It is not uncommon that the same device supports more than one method. • HTTP/Telnet: one such method uses a web interface (or a command line one accessed via Telnet or remote login), embedded within the device. In this case, an already working IP interface is mandatory for this configuration process. The automation device is therefore usually shipped with a default IP address that is made available to the user so that the IP settings can be set according to his/her needs. • DHCP: this auto configuration protocol eliminates the need for a network administrator to assign IP addresses. It can also assign the net mask, gateway address, DNS server addresses and more. Due to the need of IPdependant mapping of some control level networks, this method is barely used in such applications but very common in enterprise or some SCADA networks. • BOOTP: the Bootstrap protocol is also used as a convenient way to quickly assign IP addresses to devices such as PLCs and IO modules. It can be seen as a predecessor of DHCP. 2.2.1.3 Device and network configuration Once an automation component has a valid address, it can be accessed by means of HTTP or simply using custom applications based on TCP/IP and FTP to download or upload device configuration files. Downloading, uploading PLC programmes, configuration parameters to automation components such as adjustable frequency AC drives, solid state motor starters, electronic operator interfaces, motor management devices, etc, is considered a non real-time task and therefore TCP/IP is a preferred network transport mechanism. Furthermore, the automation network uses several protocols from the internet suite in order to start-up the control network. In most Ethernet based field buses, it is usually the case that a controller class device, which has the information of the entire IO mapping within a network segment may start to detect link layer or hardware addresses by using ARP, only when IP addresses are known. Afterwards, custom UDP and TCP messages between controller and IO class devices are used to establish an automation connection between components. Once communication between automation devices has been established, protocols such as ICMP aid in detecting an unreachable automation component. 2.2.1.4 Diagnosis and status monitoring By diagnosis and status monitoring we refer to several different components and uses. They can be classified as diagnosis and status monitoring of automation devices, communication infrastructure components and of the control process itself. Using TCP/IP and HTTP it is possible to gather information about the current status of a specific automation component. For instance, an AC drive may include a variable that represents the internal temperature of the device. Such information may be available for preventive maintenance purposes and be accessed on demand or an alarm may be automatically generated.

Category: Report

Status: Final


16/12/2011

Pag. 19


Beyond traditional network infrastructure components such as switches and routers, automation devices also support SNMP. This network protocol, based on UDP, is used in automation network management systems to monitor network-attached devices for conditions that permit administrative attention. Device specific information, i.e. a temperature, can be made available using SNMP. To do this, SNMP supports the inclusion of vendor specific information blocks, the so-called private Management Information Base (MIB). The automation process itself thrives on the use of internet technologies in the case, for example, of event-triggered messages using email services based on protocols such as SMTP, IMAP or POP3. A process variable going of its range can be used to generate an Email addressed to the maintenance group at some facility. Also frequently used are alerts using the "Trap" feature of SNMP, which sends standardized messages to a network management centre. An extended solution based on SNMP is the Remote Monitoring (RMON) standard from the IETF. 2.2.1.5 Real-time control communication For real-time delivery of messages (e.g. between PLCs and IOs), the UDP transport protocol is preferred due to it being leaner when compared to TCP. Also, UDP does not slow down communication in the presence of transmission errors, as opposed to TCP that uses retransmissions (ARQ) for reliability. Prominent Ethernet-based field busses that rely on UDP for real-time communication are Ethernet/IP and PROFINET RT-UDP. Because this transport mechanism is unconnected, it is possible to use multicast and broadcast as a more efficient way to distribute real-time data across an automation system. For instance, one single message may be sent by an IO module to update the status of a sensor on a PLC and an HMI device, thus dramatically reducing network traffic. In order to truly reduce network traffic when using multicasting, Ethernet switches must support the IGMP protocol to ensure that messages are propagated only to its intended recipients. Multicast groups can be set automatically through the use of IGMP Snooping and Querying. TCP is also used for real-time communication with relaxed constraints; an example is the Modbus TCP/IP protocol which uses a client server communication model. Under this model it is possible to use the server´s response to implicitly acknowledge the client´s query. Furthermore, TCP/IP has been used for a long time now to exchange real-time messages between controllers, also referred to as peer-to-peer messaging. The advantage of TCP in this case is its enhanced reliability due to its ARQ mechanism. Real-time traffic over Internet protocols is typically supplemented by layer 2 mechanisms (i.e. priorities) and sometimes controlled by some means to differentiate between real-time priorities also on layer 3 (IP). 2.2.1.6 Process data collection By process data collection we refer to the non-real-time process of a host or hosts gathering process data for simple monitoring or storing massive amounts of records needed for compliance or quality (batch). For this, both TCP and UDP can be used to collect large amounts of process variables. However, an application protocol often used for such tasks known as OPC (Ole for Process Control) typically uses TCP/IP in order to ensure reliability. 2.2.1.7 Process visualisation In the same way data collection does, many HMI hosts use OPC communication with the underlying TCP/IP in order to link together controllers and SCADA software. Category: Report

Status: Final


16/12/2011

Pag. 20


A later trend in HMI uses an embedded web server on the controller to allow a lean HMI based on Java technology for instance. As usual, TCP/IP is used to communicate between hosts and clients. However, due to shortcomings in these technologies, this solution is only suitable in small applications where slow screen refresh rates can be tolerated by the operator. 2.2.1.8 Parameterisation Within the realm of process control it is often needed to adjust control loop setpoints and or change times and other variables in order to execute a different batch, this is often referred to as recipe management. For this purpose FTP and TFTP are often used, since FTP provides a simple yet effective way to change such settings regardless of the location. Downloading a specific set of parameters on some discrete control applications that require fine tuning for manufacturing different products using the same machinery can also be performed using FTP.

2.2.2

Communication Network Technologies and Deployment

2.2.2.1 Factory Communication Domains Networking requirements, in and around the factory floor, differ depending on the needs of the various applications running at each level of the automation pyramid (illustrated in Figure 2.2). Local and wide area networking technologies are sufficient to connect the Enterprise Resource Processes (ERP) with the Management Execution Systems (MES) (Level 3 in the illustrated pyramid) to the SCADA system (at Level 2), where typically the required network performance is moderate. The coordination and monitoring of the whole production takes place through a distribution network that connects the SCADA system to the Production and Field level (Level 1), where local on-site controllers with high requirements concerning QoS, including real-time capability and failover behaviour, exist. Finally, the local on-site controllers are connected with the components at the field level next to the technical process, where the most stringent communication requirements are found. Standard Ethernet/IP can be used at the enterprise management and manufacturing execution levels. Today, to fulfil the more stringent requirements of networked control systems, some special Ethernet variants are typically used. Even so-called Isochronous Real-Time (IRT) communication, which is characterized by a maximum jitter of 1 microsecond for data delivery, is often required. Today IRT-quality only can be achieved either with a field bus type of technology, such PROFIBUS, INTERBUS, Devicenet, CAN, etc. - which both have significant restrictions in terms of scalability and maximum available bandwidth - , or some significantly adapted Ethernet, such as EtherCAT or PROFINET (further details are given below).

Category: Report

Status: Final


16/12/2011

Pag. 21


Figure 2.2 – Automation Pyramid Focused on Communication 2.2.2.2 Industrial Communication Technologies In recent years packet-switched Ethernet has found its way into the field level of automation and control systems replacing specific bus systems ([Decotignie]). Since the common Ethernet technology cannot fulfil all the industrial automation requirements, various adaptations (see Figure 2.3) have been developed ending in a large number of Industrial Ethernet types, like PROFINET, EtherCAT, Ethernet/IP, Modbus/TCP and more ([Rostan]).

Figure 2.3 – Classification of industrial Ethernet protocols ([Jasperneite]) Examples of improvements of the original standard include adding real-time and isochronous real-time communication capabilities, or advanced failover mechanisms to minimize outage times. When looking closely at the improvements, they could be separated in two groups: Category: Report

Status: Final


16/12/2011

Pag. 22


technologies that obtain highly deterministic communication by synchronizing the network nodes and thus synchronizing the scheduling throughout the network, • technologies that focus on over-dimensioned networks with advanced packet scheduling schemes in the nodes but without synchronization of the network nodes. In general the second approach will not deliver determinism due to its pure packet-based architecture but in a large number of cases, this approach is expected to deliver sufficient communication network quality. The wide range of more or less incompatible solutions is due to a wide range of requirements - from long distance, low rate SCADA networks to real-time capable machine control, from tiny analogue sensors to powerful servers, from simple monitoring to complex automation processes. The common denominator of those solutions is the use of Ethernet (in many cases with special extensions) and the use of standard TCP/IP (IPv4). However, the different variants are not compatible when it comes to real-time or other specific features. In some cases even special hardware is required for full functionality (e.g., the ERTEC ASIC for PROFINET IRT communication shown in [Rostan]). •

2.2.2.3 Wireless Extensions Wireless networks are currently used mainly for remote sensing, industrial plant monitoring and for extending the reach of where wire line communication cannot be used. The often unpredictable behaviour of wireless links is handled by a strict frequency and radio planning, which restricts the flexibility of wireless systems and results in inefficient bandwidth usage. A more intensive adoption of wireless networks for industrial automation is still missing because they still cannot fulfil requirements like reliability and end-to-end latency in the order of several milliseconds. However, these requirements may be met in the near future by new technical wireless solutions and standards, like the recently developed WirelessHART ([WHart]). Currently, wireless links are handled similarly to wired ones and mobility of devices is handled at OSI layer 2 ([FlexWare]), thus hiding the mobility aspect from the applications. Higher layer mobility concepts such as e.g. Mobile IP or presence services are typically not used since they are not ready to fulfil the stringent industrial requirements. 2.2.2.4 Network Planning and Deployment After the planning of an automation application has happened, the requirements on the communication relationships are identified. These requirements are the basis for selecting network technologies, topology and protocols. The required redundancy is also to be considered accordingly in this network planning process. The configuration of the network details both device level and intermediate networking devices. The development of a detailed network configuration is today typically done with the help of a vendor-specific tool for the chosen industrial networking technology (e.g., the “Step 7”-tool provided by Siemens is used for a planning and configuration of PROFINET networks). All this requires a good knowledge of the network details (from the details of the topology to the standards and protocols used) and involves very high effort for network configuration, intelligent parameter choice, and predeployment testing. Moreover, when setting up the communication network, many actions are to be performed manually: • pairing of a physical device with a name or network address used in the Programmable Logic Controller (PLC). This step is typically done mostly manually after mounting the device. The device ID used for this purpose can be an Ethernet (MAC) address;

Category: Report

Status: Final


16/12/2011

•

•

Pag. 23


configuration of the respective device for network access (i.e. assignment of an IP address) and application specific parameters. This step may use some protocols, such as e.g. DHCP ([RFC2131]) and/or DNS ([RFC5395] and [RFC3646]) in conjunction with semi-automatic configurations, e.g., using memory cards holding additional configuration parameters or by a tool-based remote configuration after the network is operational. This process may differ significantly from standard to standard or between various solutions; resource allocation for QoS set-up, i.e. configuration of the communication paths between various nodes of an automation network. An example could be the reservation of Industrial Ethernet transmission cycles in network switches.

After initial installation and initialization, today's automation applications assume a stable network without changes. In case of changes of the communication network topology, device replacements or failures, the steps above must be at least partially repeated. As of today, all these steps again include many manual actions and they are error-prone if some manual reconfigurations are required. 2.2.2.5 Network Monitoring and Management An important part of deployment is monitoring and management of the running network. Today's tools are already able to automatically detect connectivity and many network related parameters of devices using SNMP ([RFC1157], [RFC1441], [RFC3410], and [RFC3584]). In case of failures, alerts can automatically inform a supervisor. However to make SNMP secure even for remote administration and maintenance either IPsec or Access Control Lists need to be used which typically is quite cumbersome. Thus, today's devices with more intelligence (i.e. an I/O module) may also provide some additional remote login or Web-based interface for this purpose. SNMP is also not well suited for a fast and frequent polling of device properties. 2.2.2.6 Plug and Play technologies Many network protocols (e.g., Rapid Spanning Tree Protocol, Media Redundancy Protocol, Interior Gateway Protocols) are defined in a way that after some basic configuration (i.e. activation and basic parameter setting) they automatically start the negotiation process with their neighbours and e.g. start to exchange reachability information. But to realize an end-to-end communication service, typically many protocols are involved and need to be used in an intelligent way. Thus the orchestration of numerous such communication services fulfilling a given traffic matrix with specific requirements on the communication relations needs to be done manually today. On the application layer in the enterprise/home network scenarios UPnP ([UPnP1], [UPnP1.1]) - which is built on a stateless broadcast protocol (HTTP over UDP) - is used for auto-configuration or for service location. But even on the higher layers this technology does not fulfil the industrial requirements and thus cannot be directly used in the automation environments. 2.2.2.7 IP-to-the-field Today the model is a pure hierarchical one: the field level devices (actuators and sensors) are only seen by the on-site controller and hidden to the functions on the upper part of the pyramid. Therefore across all the layers, gateways are required to connect the different levels. This approach ends up in a high configuration effort when setting up specific automation processes, since a detailed manual configuration needs to be performed on every involved level through a suitable management system. To significantly reduce this effort and to also allow for fast changes of the Category: Report

Status: Final


16/12/2011

Pag. 24


production processes, there are a lot of investigations ongoing on so-called “IP-tothe-field” approach, the first step of which is really an “IP-to-the-field” [FieldUb] [WSIoT]. Simplified, the idea there is to equip each and every tiny device with an IP-address and let it provide its basic service as a web service. Using some SoA (Service oriented Architecture) approach these tiny web services can be combined then much more easily to a complex automation process. But there are many open issues with this approach, like assuring scalability, performance limitations on the device side, security, and so on [RTComm]. 2.2.2.8 Device Management and Device Metadata An abstract view on an automation device is a set of services, state info and capabilities which are bound to a specific hardware instance. Thus the first problem is to get a complete view on a device. As of today, many standards are used for this purpose. • SNMP: the ‘Simple Network Management Protocol’ (SNMP) ([RFC3411]) has gained importance due to vast amount of already standardized network related - but not automation specific - info. As such, management capabilities are available on many IP-capable platforms. SNMP can be extended using so-called ‘private MIBs’ (Management Information Base) to include nonstandard, vendor-specific information. SNMP specifies both syntax and semantics for management information, as well as the access method. SNMP can read and modify device configuration parameters. A mechanism called ‘traps’ enables management station to subscribe for certain events. SNMP is supported by many IP enabled devices. Unfortunately, the main scenario was network management, so that most configuration options apply to networkrelated parameters. SNMP follows a client-server approach, where devices implement a so-called ‘agent’ and are managed by a management station; • EDDL: for automation specific parameters und functions, the ‘Electronic Device Description Language’ ([EDDL]) technology is used by major automation equipment manufacturers to describe and set the information that is accessible in digital devices. EDDL is mainly used in the planning and initial commissioning phase. It is not meant to provide live state of the devices, but more to provide a standardized description how to access the device and on what functionality can be accessed on a device; • PROFIBUS GSD/GSDML: the ‘General Station Description’ (GSD) and its mark-up language based descendant GSDML are meant to specify parameters of cyclic data exchange of I/O modules in the PROFINET/PROFIBUS world (see Figure 2.4 and [ProfinetIO]). It allows configuration of communication parameters, i.e. the bandwidth needed for isochronous real time. Both EDDL and GSD are typically not present in the device itself, but rather can be loaded from vendor data bases so they are more an electronic data sheet. The respective standard bodies however do discuss the possibility to at least partially store those descriptions on the devices; • FDT industry standard of the FDT Group ([Takeuchi]): it specifies parameterization of field devices. A work to integrate EDDL, OPC-UA and FDT into a common framework is under way, led by a joint group called ECT ([FDT]).

Category: Report

Status: Final


16/12/2011

Pag. 25


Figure 2.4 – PROFINET Device Configuration 2.2.2.9 Initial Conclusion There is a shift of industrial solutions towards a unified network solution based on standard Ethernet and Internet technologies, a process which is still on-going. Specific requirements lead to a great variety of add-ons and variants. As such, there is a need for enhancing interoperability and handling of the complexity of those systems. A preliminary guess is that future solutions will re-use the various protocols and technologies but will have to add abstraction layers to provide a better integration, thus being a stepwise evolution of existing solutions rather than a completely new set of solutions. 2.2.3

Middleware and Software Technologies in Automation Systems

2.2.3.1 Introduction Here we consider only Object-Oriented and Service-Oriented middleware solutions, not considering Transaction-Oriented (e.g., Tuxedo), Message-Oriented (e.g., Microsoft Message Queue or JavaSpaces) or P2P middleware (a definition of P2P middleware is available at http://ants.etse.urv.es/wiki/P2P_Middleware). Main communication protocols – all identify a client and a server: • Remote Method Invocations (a pull/request-response protocol), • Notifications (clients sending information to servers without waiting for a response), and • Events (essentially a push protocol, whereby the server uses callbacks to asynchronously inform the client of events of interest, which are treated by the client’s callback/event handler). Basic functionality: • Common representation of data, data structures and method signatures/interfaces, usually achieved through an Interface Definition Language (IDL) such as the CORBA IDL or the Web Service Definition Language (WSDL), to achieve interoperability among heterogeneous (software and hardware) components. • Client and server side proxies (sometimes called client stub and server skeleton) that provide location and access transparency by hiding the remote Category: Report

Status: Final


16/12/2011

•

Pag. 26


communication aspects, e.g., marshalling of local method parameters to a network format, transmission of messages, unmarshalling of a message and delivery to the recipient. A set of basic services, such as naming, i.e., the identification of a remote server object through a name.

2.2.3.2 CORBA CORBA (Common Object Request Broker Architecture) is an object-oriented middleware platform that is portable and usable across different operating systems and languages. Thus one can easily develop a distributed system where a client implemented in C/C++/Fortran/Java/Ada/Lisp/etc. and running on top of Microsoft Windows/Unix/Linux/R-T OS’s/etc. interacts with a server implemented in a different language and running on top of a different operating system. Services are described using CORBA’s IDL which shares similarities with C/C++. The IDL compilers produce client stubs and server skeletons for some specific language, i.e., proxies that respectively receive client requests at the client side and forward them to the server skeleton at the server side, where requests are delivered to the server object; responses are collected and forwarded back to the client stub to be finally delivered to the client. Each computer has its own ORB (Object Request Broker) that marshals and forwards messages from one component to the other. The ORB also has an interface of its own to allow components to initialise themselves and obtain references to some standard services, e.g., a Naming service. While the main CORBA ([CORBA]) standard seems to have fallen out of grace, the specification for embedded devices – CORBA-e ([CORBAe]) – is being used in many systems, with implementations of it even in hardware. CORBA-e is widely used in telecommunications, aerospace systems and the military. CORBA-e has two profiles: Compact and Micro. The Compact profile merges the general CORBA specification ([CORBA]) with Real-Time CORBA ([RTJava], [CORBART]), while removing the dynamic aspects of the general CORBA specification (e.g., the Dynamic Invocation Interface – DII, which provided reflection capabilities in CORBA systems, allowing components to discover new interfaces and perform requests on objects supporting these) and the support for the CORBA Component Model (CCM). It also supports only a lightweight version of CORBA Valuetypes and the Any type. The Micro profile is smaller still, removing Valuetypes, the Any type, most of the options of the Portable Object Adaptor (POA – part of the interface of an ORB) and all the R-T functions apart from the R-T Mutex interface ([Giddings]). Work on R-T CORBA seems to be continuing, as evidenced by the R-T OMG workshop1. R-T CORBA provides support for priorities, remote mutexes and priority inheritance protocols, thread pools (at the same or different priorities, called lanes), global scheduling, different communication protocols and binding of services to objects that can provide them. 2.2.3.3 TAO TAO ([Schmidt98]) is a widely used Open-Source, R-T CORBA system implemented in C++. Its developers claim that it is highly portable. As such TAO is of particular 1

See http://www.omg.org/news/meetings/workshops/presentations/realtime_emb_presentations/ag enda.htm

Category: Report

Status: Final


16/12/2011

Pag. 27


interest to the IoT@Work project since it could be a potential middleware on top of which the IoT@Work solutions would be developed. 2.2.3.4 Java Java is one of the first widely-used programming languages that was designed with specific support for concurrent programming and allows the use of Remote Method Invocations (RMI) to other Java Virtual Machines (JVM). Since both communicating entities reside in a JVM, they share the same data and interface representation, so there is no need for using an IDL to represent the interfaces of objects – these interfaces are described directly in Java. The other benefit is that data do not need to be marshalled to and from some network standard representation, since all communicating entities share the same data representation (all of them running on a JVM). The obvious disadvantage of the Java RMI solution is that it can only be used by Java code – thus it is not possible to connect C++-based clients to a Java-based server (unless one uses the Java Native Interface to call C/C++ code – a solution that is error prone and decreases the portability and type-safety of the code). 2.2.3.5 R-T Java R-T Java ([RTJava]) has introduced mechanisms through which developers can control the CPU allocation (and thus the temporal behaviour of their application) and partially control the memory allocation, as well support not only for heap-allocated objects but also for statically allocated ones (immortal memory) and objects allocated in memory regions (scopes) that behave like stack-allocation, i.e., when the last thread associated with a region exits it, the whole region is de-allocated immediately. The current problem with memory allocation is that the existing Java standard library allocates memory in a way that is not controllable; for that reason there was another specification underway for a Safety Critical Java ([JSR302] currently inactive). RMI has not been given an R-T version and as such offers no R-T characteristics. The Distributed Real-Time specification [JSR50] is also inactive. 2.2.3.6 Zen ZEN ([Klefstad]) is an Open-Source, R-T CORBA system implemented using R-T Java ([RTJava]), also from the developers of TAO ([Schmidt98]). ZEN is of particular interest because it combines the features of R-T CORBA for distributed R-T applications with those of R-T Java. This is of particular importance because the use of R-T Java increases the dependability of the middleware – Java’s type safety, direct support for concurrency and R-T computation and memory allocation make it easier to develop correct systems. Currently work on ZEN seems to have stopped, though the code is available2 and other commercial implementations of R-T CORBA exist as well. 2.2.3.7 Web Services DPWS ([OASIS09]) has as a goal to introduce WS in devices and to use it to support the following functionalities: • service discovery (devices are assumed to have valid IP addresses through a protocol such as DCHP ([RFC2131]) or IPv6 Autoconfig ([RFC2462])Ethernet; • service description; 2

https://github.com/kraman/RTZen

Category: Report

Status: Final


16/12/2011

• •

Pag. 28


subscription to and reception of events; secure message exchange.

In order to reduce the overhead associated with service discovery, services are divided into hosting and hosted services. Each device has a single hosting service that can be discovered by other devices. The hosting service can be queried to provide the list of its hosted services. Thus, hosting services serve as local name services and the hosted services are the ones implementing the functional behaviour of the device. DPWS has support for efficient message exchange but these are still SOAP messages. Thus, they still require considerable parsing at the receiving end to transform to binary requests that can be serviced. DPWS does not provide any explicit support for R-T. An interesting idea may be the use of DPWS for device discovery and then use the hosting service to export a list of CORBA object identifiers and their interfaces. That way, the initialisation phase, whereby the device is discovered and connected with the rest of the system, can utilise the slower but easier to use DPWS standard, while the operating phase, with its R-T constraints, can use the more predictable and more efficient R-T CORBA protocols. Security-wise, DPWS supports the optional signing of discovery messages and the, again optional, creation of a secure channel between a client and a server through TLS/SSL (though the secure transmission of the metadata, i.e., device/hosted services descriptions, is mandatory). A number of European research projects have had important results in the introduction of DPWS in automation. SIRENA (see §2.3.2.1 on pag. 35 and other projects in §2.3) developed one of the first DPWS implementations for embedded devices, and open-source C and Java implementations of it are available from SOA4D.org and WS4D.org (more details in §2.3.2.1 on pag. 35). Projects SODA (more details in §2.3.2.1) and SOCRADES (see §2.3.2.3 on pag. 36) have continued the work of SIRENA in the development of a DPWS stack for embedded devices and associated tools for it, as well as in the introduction of DPWS enabled devices into industrial automation systems. Another implementation of WS for embedded devices is Gsoap ([vanEngelen]). An interesting comment made by van Engelen and Gallivan ([vanEngelen]) in their introduction is “SOAP is not a competitive technology to component systems and object-request broker architectures such as the CORBA component model ... and DCOM, but rather complements these technologies. CORBA, DCOM, and Enterprise Java ... enable resource sharing within a single organization while SOAP technology aims to bridge the sharing of resources among disparate organizations possibly located behind firewalls”. Indeed, one of the reasons for which CORBA proved difficult to use across organisations was that firewalls tend to not allow its connections. WS were designed to use HTTP messages (mainly) since firewalls generally allow these. Unfortunately, none of the DPWS approaches has attempted to provide direct support for R-T WS’s like R-T CORBA has done for the CORBA middleware. The only work we are aware of that has attempted to directly support R-T WS is SOAP4IPC ([Mathes09a]) & SOAP4PLC ([Mathes09b]), which were developed during Markus Mathes’ PhD work. Interestingly, Mathes developed these on top of RT Java.

Category: Report

Status: Final


16/12/2011

Pag. 29


2.2.3.8 OPC-UA OPC-UA (OPen Connectivity – Unified Architecture, see [OPCUA], [Mahnke]) is an enhancement of the older OPC (OLE for Process Control) specification. The original OPC was a transfer of Microsoft’s COM/DCOM middleware in a factory automation setting. OPC-UA provides a framework for interoperability to be used over the next 10 years and beyond (published also as IEC 62541). An additional goal of OPC-UA is to provide a path forward from the original OPC communications model (COM/DCOM) to a model based on a service-oriented architecture (SOA). OPC-UA is expected to enhance security and to provide an information model for crossplatform architecture in the process control domain ([Mahnke]). Since Microsoft has largely replaced COM with its new .NET middleware platform and OPC vendors wish to offer products on non-Microsoft platforms, the OPC Foundation has developed the OPC-UA specification and as also provided an OPCUA communication stack for C, .Net and Java. There are also some commercial/noncommercial OPC-UA SDKs available. If we consider Engelen and Gallivan’s comment ([vanEngelen]), one could consider the C/C++/Java/.Net bindings as expected to be used within a factory behind its firewall and the WS bindings to be used for connecting with systems that are outside the firewall, e.g., “to visualise the factory process on a PDA” ([vanEngelen]). The OPC Foundation has been working with other standard organizations to gear UA as a medium for conveying and transporting data defined by these other specifications. With the acceptance of UML based models and XML schema to define and render complex data, many information model specifications are emerging. Some of the organisations OPC is working directly with include ISA S95 and S88, MIMOSA, EDDL, OAGi and IEC TC57 ([Burke]). The OPC-UA security model has been designed to meet the requirements of many different systems while using the same infrastructure. In order to accommodate different security and administrative requirements the OPC-UA security model offers four tiers for application authentication and two tiers for certificate management. It is up to the administrators to decide which tiers best match their needs. Applications should support all of them. Applications must allow administrators to configure the level of security they must enforce just like web browsers allow administrators to configure the security level enforced by the browser ([Armstrong]). 2.2.3.9 Data Distribution Service The Data Distribution Service (DDS) is another standard from OMG (the organisation behind CORBA) describing a middleware infrastructure that works in an event-based, publish-subscribe manner, instead of a remote procedure/method call one [DDS]. DDS features fine control of real-time QoS parameters, including reliability, bandwidth control, delivery deadlines, and resource limits. The standard is geared toward addressing the challenges of real-time communications. There is ongoing work to render DDS suitable for large scale dynamic systems [Wang], among which is to resolve its current unfriendliness with regard to firewalls [Corsaro]. Schneider and Farabaugh ([Schneider]) summarise DDS features as follows “Data flows directly from source to sink without requiring intermediate servers. DDS supports a “discovery”, an intent registration process that allows nodes to join and leave topics at any time. Discovery also provides an opportunity to specify per-datastream Quality of Service (QoS) requirements such as reliability, deadline, and resource usage”.

Category: Report

Status: Final


16/12/2011

Pag. 30


Multiple source and sink support allows redundancy and fault tolerance. DDS middleware delivers the right data to the right place at the right time, while handling startups, shutdowns, errors, and specific communication needs. It has been implemented in the field of Industrial Automation by companies such as Schneider Electric (which has set up a partnership “... to provide the RTPS on-thewire protocol specification to the automation industry as an open, standard control protocol. Schneider deploys the RTI Data Distribution Service as its Global Data solution in its high-end Quantum and Premium PLCs”, see [RTI]) and some opensource implementations exist as well3,4.

2.2.3.10 Initial Conclusion The DPWS technology seems to be the most appropriate for discovery and initialisation of devices. CORBA based solutions tend to require the use of known Naming Services. These could be set up in a factory, either having a single Naming Service for the whole factory or one per manufacturing line/cell. It is not however trivial to pre-configure devices so that they try to contact their respective Naming Service, something that DPWS seems to overcome. Again, for interaction among systems that are at opposite sides of a factory’s firewall, WS solutions have an advantage – SOAP messages are generally allowed by firewalls while CORBA ones are not. However, it is not so clear whether a WS/DPWS solution would be the most appropriate for systems operating within a factory. Apart from the discovery/initialisation phase, where DPWS would be useful, the operating phase usually has hard R-T constraints. These cannot be met easily by WS middleware. Parsing of the SOAP messages alone is an activity that introduces unpredictability and consumes a lot of resources. Also, unlike R-T CORBA, DPWS does not offer any direct support for R-T concepts. Currently the implementations of DPWS for R-T are either academic prototypes like [Mathes09a],[Mathes09b] or ones whose focus is a small memory footprint, to allow their use in embedded devices like SOA4D.org, WS4D.org and Gsoap [vanEngelen]. For this reason it seems that R-T CORBA is far more appropriate for use behind a factory firewall for the operational phase of the devices. It would be interesting to see if it is possible to combine the two solutions, using DPWS for device discovery and initialisation and interaction with systems outside the factory firewall, and something like R-T CORBA for accessing their services during their operational phase. Another option is to consider event-based solutions like the one supported by DDS [DDS]. Indeed, there seem to be both open-source and commercial implementations of this standard that already supports R-T behaviours. Event-based solutions would also help improve system agility, since it is much easier to replace components in an event-based system than it is to do so in a system built around a middleware infrastructure based on remote procedure/method calls. Table 2.1 presents a short summary of the main features of the different middleware technologies that have been discussed so far. The second column states whether the middleware is mainly oriented towards remote method invocations (RMI) or eventbased interaction (Events). The third column considers whether R-T versions of the middleware exist and if so, whether they are prototypes or commercially-supported solutions. Finally the fourth column considers whether the middleware has a version that supports embedded devices (i.e., a small memory footprint). Note that a middleware may have implementations of it that support either R-T or embedded 3 4

www.opendds.org www.prismtech.com/opensplice

Category: Report

Status: Final


16/12/2011

Pag. 31


devices but not both. The R-T Java (RTSJ RMI) is considered to not support R-T or embedded devices because the RMI part of RTSJ is not R-T and we are not aware of an RTSJ implementation for a small memory footprint. (*) “P” stands for (research) prototype, “O” for open-source projects, and “C” stands for commercial availability. For OPC-UA we mainly focus on its web-service aspects. Middleware RMI/Events R-T (*) Embedded (*) Firewall-friendly CORBA RMI Y (O/C) Y (O/C) N RTSJ RMI RMI N N N DPWS RMI Y (P) Y (P/O/C) Y OPC-UA RMI N Y Y DDS Events Y (O/C) Y (O/C) N Table 2.1 Relative Comparison of different middleware technologies 2.2.4

Security Technologies in Automation Networks

2.2.4.1 Bridging shop floor and top floor Traditionally, automation systems are either isolated from the outside world, or shielded through proprietary communication mechanisms and protocols. The direct information exchange between automation networks and office networks was minimal. Today, the strong separation between top floor (office and enterprise) and shop floor (automation) systems has various disadvantages5: the market forces production companies to quickly adapt to emerging market demands and products need shorter product cycles and reduced time to market. Therefore, production companies need more accurate and up-to-date shop floor process information inside their enterprise planning tools. Planning tools and decision support systems must be able to dynamically adapt production processes on the shop floor. Applications like remote maintenance demand access to the shop floor in a secure, manageable and flexible way6. To address these business requirements, the industry needs systems that securely bridge the gap between shop floor and office systems in a way that does not negatively impact the capabilities and properties of the automation systems, such as the ability to quickly capture and handle faults, monitor and predict maintenance needs, as well as support for real time communications. Connections between top floor and shop floor are increasingly based on open standards, typically based on Internet protocol (IP) technologies. For a long time, automation systems, with their reliance on proprietary network protocols and hardware, have been considered immune to security issues that threatened Enterprise and Internet systems7. Adoption of IP technology on the shop floor in conjunction with connectivity to the office networks and therefore a potential connection to the Internet exposes the shop floor to previously unknown or ignored security challenges. As a result, IT security became a more important topic in the industry automation domain over the past years. Recent EU research projects such as SOCRADES (see §2.3.2.3 on pag. 36) investigated communications between factory floor and back 5 6

7

White paper “Making sense of E-Manufacturing: A Road map for manufacturers Industry” Rockwell Automation, November 2000. H.K.Shivanand, Nanjundaradhya N. V, P. Kammar, D. Shree, Keshavamurthy YC, “E Manufacturing a Technology Review,” in Proceedings of the World Congress on Engineering WCE, July 2008. Treytl, T. Sauter, C. Schwaiger, “Security measures for industrial fieldbus systems - state of the art and solutions for IP-based approaches,” in proceedings of IEEE International Workshop on Factory Communication Systems, September 2004.

Category: Report

Status: Final


16/12/2011

Pag. 32


end ERP systems and improved interoperability of proprietary and legacy mechanisms. SOCRADES is fully in line with the notion of pushing Ethernet and TCP/IP into the shop floor, but it does not address the naturally resulting security problems in a holistic way. While security incidents can have safety-related consequences, safety and security need fundamentally different approaches for assessment and mitigation of issues. Safety issues typically have statistically describable behaviour, because the ‘opponent’ is not a human being. Security issues on the other hand cannot be handled using statistical assessments, but need different approaches. The opponents are intelligent human beings that communicate, coordinate, learn and adapt their behaviour dynamically to countermeasures. Factory automation experts traditionally have a very strong background in safety (partially justified by the need to assure humans safety and by normative constraints and law responsibilities), but lack expertise and mind set on the IT security side. The following table compares the traditional views of the Enterprise and office world with the automation systems view. Terminology

Shop floor / Automation systems

Top floor / Enterprise

1) Confidentiality Security objective 2) Availability priorities 3) Integrity

1) Integrity / Authorization 2) Availability 3) Confidentiality

Roots

Information Technology (IT)

Industrial Control (IC)

Domain priority

Security

Safety

Compliance

Based on generic standards

Site-specific and risk-based

Consequence management

Suspicion of threat requires intervention

Intervention must not disrupt process control functionality

ISO/IEC 17799

IEC 62443 (draft)

5 years

10-25 years

Accountability

Global

Local

Performance

High throughput and consistent response

Low throughput and time-critical response

Availability

Planned outages are acceptable

Short outages cause very long process delays

Security focus

Data and the servers

Equipment used for control of processes

Systems management

Centrally managed

Vendor-managed

Security standards Equipment lifetime

Table 2.2 – Top Floor vs Shop Floor views comparison 2.2.4.2 Perimeter security between top floor and shop floor In the past, the primary focus when securing automation systems has been on protecting existing legacy systems that were deployed a long time ago, when IPbased connectivity and the associated security risks did not exist. The typical security approach to protect automation systems is to restrict access to the network by Category: Report

Status: Final


16/12/2011

Pag. 33


deploying network perimeter protection mechanisms such as packet filters and firewalls. In this approach, the automation equipment itself is not secured, so that devices inside the shop floor communicate without additional security measures (see Figure 2.5).

Figure 2.5 – Example Security in Automation Quite a few initiatives have started over the past five years to produce guidance based on consensus and proven practices. This advice is available from various sources, including government organisations such as the US ‘National Institute of Standards and Technology’ (NIST) and the UK ‘Centre for the Protection of National Infrastructure’ (CPNI), vendors, industrial associations, and national and international standardization organisations. The standardization initiative that seems best positioned to gain general acceptance is the work of ISA SP99. The ISA SP99 committee, whose members represent plant owners, vendors, government institutions, integrators, and consultants, already produced two technical reports. The first, which was updated once in 2007, describes technical measures, and the second explains the elements of a security management program. The committee is now working on a new standard-ISA S99, "Security for Industrial Automation and Control Systems”8. 2.2.4.3 Towards more in-depth security As mentioned previously, it is not meaningful to transfer the concept of statistical, numerical safety levels to security levels. Opening internet ports on devices on the factory floor creates a risk that needs to be properly addressed. The trade-off here is between interoperability and enhanced communication on one hand and security on the other hand. Adopting TCP/IP and Internet-related protocols exposes the factory floor to previously unknown security threats. Addressing these issues by bringing 8

ISA S99 Group. (URL: http://www.isa.org/MSTemplate.cfm?MicrositeID=988&CommitteeID=6821/)

Category: Report

Status: Final


16/12/2011

Pag. 34


them forward and prescribing solutions will fulfil the requirements of a more flexible factory floor to be realised. The deployment of firewalls and packet filters between top floor and shop floor and VPN-style dial-in appliances that allow secure tunnels into automation network are clearly an advancement compared to unprotected and uncontrolled network bridges (as shown in Figure 2.5). Nevertheless, these approaches carry multiple major problems: • Lack of ‘defence in depth’: the factory floor is still in the ‘stone age’ of enterprise security, where centralised firewalls were seen as THE solution to perimeter protection. Looking at today’s enterprise security landscape, deperimeterisation and fully distributed security enforcement are state of the art, and provide endpoint security which is more independent from centralised perimeter security components such as the company’s firewall. • Lack of ‘fine-grained authorization’ support and expensive security management: perimeter firewalls typically have a very coarse-grained authorization policy; for example, they enable certain management computers to access the shop floor, typically based on the originating IP address. VPN appliances support user authentication, but are not integrated into the company’s identity and access management systems, such as Active Directory. In contrast, enterprise mechanisms for identity and access management have been refined significantly over the past years. For example, single-sign-on mechanisms, centralised authorization management, as well as cross-organisation access management and federation enabled companies to significantly reduce their identity and access management costs, while raising the quality of security to a new bar. • Interference of traffic flows: with many different systems requiring access, precautions must be taken that traffic flows from different systems to devices in the field do not affect each other, especially in the case of critical real-time traffic. Security in depth: the first step is to bring firewall down to the level of a production cell, i.e. enforcing access control between the automation network and a production cell. Communication within the production cell is not affected by this. In this first step, intra-cell communication does not utilize any security measures, so that real-time traffic is not affected in any way. This security concept is promoted by the ‘PROFINET International’9, the organisation for the industrial real-time Ethernet ([Brooks]). A similar picture is given by the Energy automation standard IEC62351 that covers secure communication between sub-station controllers, but not down to the control level of field level devices. Additionally, security in depth has to also deploy at the shop level approaches and technologies able to enforce enterprise or plant security policies. For example, the recent discovery of the Stuxnet worm ([Matrosov]) made clear the need of shop floor security policies enforcing mechanisms that control the usability of USB devices (USB infected devices were the initial Stuxnet spreading vector) on PLCs or other shop floor systems. As widely report in the press, Stuxnet is a worm targeting Windows systems running SCADA applications (specifically Siemens' PCS 7 SCADA software). Stuxnet makes use of a set of Windows zero-day attacks vulnerabilities and its normal spreading vector is via infected USB devices. Once active on a system it is able to infect other network accessible systems. 9

PROFINET/PROFIBUS International (PI). (URL: http://www.profibus.com/)

Category: Report

Status: Final


16/12/2011

Pag. 35

2.3

Other relevant EU & National initiatives

2.3.1

Introduction


This chapter summarises a set of national or European projects that can be relevant for IoT@Work, both as possibility to reuse/enhance their outcomes, or for possible synergies and cooperation activities. For each project the most relevant issues from an IoT@Work point of view have been highlighted in addition of a short description of the project’s objectives able to position it within the overall scenario. 2.3.2

European Projects

2.3.2.1 ITEA SIRENA Project SIRENA10 (Service Infrastructure for Real-time Embedded Networked Applications) was a European R&D project funded within the ITEA initiative, with the objective to develop a Service Infrastructure for Real time Embedded Networked Applications. The project, run in the period 2003-2005, played a pioneering role in using the SOA paradigm to communications and interworking between components at the device level to be awarded in 2006 with the ITEA Achievement Award and be used as a starting point for new projects (ITEA SODA11 and FP6 SOCRADES projects, see §2.3.2.3) and initiatives (SOA4D-SOA for Devices12 and WS4D-Web Services for Devices13). The SIRENA project produced an early DPWS implementation for embedded devices. This implementation was used as a starting point for the collaborative, open source development promoted via the SOA4D website. SOA4D provides C and Java implementation of the DPWS stack and of its add-ons (e.g. WS-Management and WS-Security implementations). WS4D has objectives similar to the SOA4D initiative providing DPWS implementations and development toolkits. In particular WS4D provides: • WS4D-gSOAP14: a C/C++ development toolkit, based on the gSOAP web services toolkit, for DPWS compliant web services consumers and providers. The toolkit enables developers concentrate on the implementation of device’s functionalities, and generates the code on service and device level. WS4DgSOAP offers multi-platform support; • WS4D-uDPWS15: is a C implementation of DPWS for highly resourceconstrained devices and wireless sensor networks. It is designed to work on microcontrollers with small amounts of memory. WS4D-uDPWS is based on the Open Source operating system Contiki (see [Contiki] and its home page16), therefore supporting 6LoWPAN ([RFC4919]), TCP and UDP network stack; • JMEDS17: is a Java Multi Edition DPWS Stack that allows to implement and run DPWS Services, Devices and Clients; 10 11 12 13 14 15 16 17

See SIRENA home page: http://www.sirena-itea.org/ See SODA home page: http://www.soda-itea.org/ See http://cms.soa4d.org See http://www.ws4d.org See http://ws4d.e-technik.uni-rostock.de/gsoap/ See http://ws4d.e-technik.uni-rostock.de/udpws/ http://www.sics.se/contiki/ See http://ws4d.e-technik.uni-rostock.de/jmeds/

Category: Report

Status: Final


16/12/2011

•

Pag. 36


WS4D-Axis218: is a toolkit for developing Java DPWS compliant web services consumer and provider using the Apache Axis2 framework.

The SODA project objective was to create a service-oriented ecosystem based on the foundations laid by the SIRENA framework. The SODA project was able to embed DPWS web services in five different devices. This integration led to a significant reduction of time to market for innovative services. 2.3.2.2 VAN Project VAN19 (Virtual Automation Networks) was an FP6 IP project focused on local and wide area communication infrastructures for flexible manufacturing automation. VAN developed an open platform that integrates heterogeneous networks able to fulfil fast and flexible manufacturing processes needs. The VAN platform is based on Web Services to support communication among industrial applications and devices; additionally the VAN platform provides facilities for flexible and fast-configuration of devices, network infrastructures and applications. These facilities, for example, support distributed applications discovery even among remote sites. At the application architecture layer the VAN project envisaged Web Services and OPC-UA as the most suitable technologies to bring the Service Oriented Architecture into the automation domain. At the lower communication layers the VAN project envisaged IEC61158 (PROFINET), and wireless solutions (W-LAN, Bluetooth and ZigBee) as the best solutions to enhance Ethernet and wireless system to meet the needs of automation. In addition PROFISafe was envisaged as the safety technology for PROFINET thanks to its functionalities to support safe environments within both wired and wireless industrial networks. The VAN project implemented secure communications by means of OpenVPN tunnels, and web services security using an Access Control Layer. Finally, VAN adopted FDT/DTM to support configuration and parameterisation of field devices. 2.3.2.3 SOCRADES Project SOCRADES20 (Service Oriented Cross-Layer Infrastructure For Distributed, Smart, Embedded Devices) was an FP6 IP project, exploiting results of the SIRENA project, focused on the development of new methodologies, technologies and tools for modelling, designing, implementing and operating networked smart embedded devices for different applications domains (industrial automation systems, automotive electronics, telecommunications equipment, building controls, home automation, telemetry, medical instrumentation, etc.), even if the main focus was on manufacturing and process automation. In SOCRADES SOA plays a central role in supporting embedded software and applications in the automation world across wired and wireless Ethernet networking technologies, thanks to the use of open interfaces enabling interoperability at the semantic level. In SOCRADES services encapsulate device-specific functionalities that are advertised to the outside world. Other devices or applications can discover functionalities they require and invoke them without any constraint related to how the functionality is implemented. 18 19 20

See http://ws4d.e-technik.uni-rostock.de/axis2/ See VAN home page: http://www.van-eu.eu/ See SOCRADES home page: http://www.socrades.eu/

Category: Report

Status: Final


16/12/2011

Pag. 37


The umbrella paradigm of SOCRADES is called collaborative automation: that is a service-oriented ecosystem where networked systems are composed from smart embedded devices interacting with the physical environment and with the enterprise environment, carrying on specific system goals. Taking into account intelligence at the device level allows intelligent system behaviour to be the result of the ad-hoc composition and configuration of devices (and of their representative web services) that incrementally contribute to the overall intelligence. SOCRADES developed and made extensive use of: • a comprehensive device-level SOA infrastructure, based on DPWS, to encapsulate as services the intelligence, sensing or actuating capabilities of devices; • a methodology for describing services with semantic mark-up (Semantic Web Services), which can be easily interpreted and processed by agents, to support discovery, selection and composition of resources. • a specification of a framework for service-enabled intelligent physical agents. Finally, SOCRADES contributed to the OASIS DPWS Technical Committee and its SOAP-over-UDP ([SOAPUDP]) has been approved as an OASIS Standard. 2.3.2.4 HYDRA Project The Hydra21 (Middleware for Networked Devices) project was an FP6 4-year IP project focused on the development of a SOA complaint middleware for networked embedded systems. Even if the Hydra approach was general, its developments were specifically focused on three different applications domains: building automation, healthcare and agriculture scenarios. The Hydra middleware makes possible to incorporate heterogeneous physical devices into applications thanks to easy-to-use web service interfaces for controlling different types of physical devices irrespective of the network technology (e.g. Bluetooth, RF, ZigBee, RFID, WiFi, etc.). Hydra provides features for device and service discovery (supported also via semantic technologies), peer to peer communication, and a publish/subscribe mechanism to further decouple components. The Hydra middleware is constituted by so called Hydra Managers that cooperates to support the communication and cooperation among networked, heterogeneous devices and applications using a peer to peer communication infrastructure. The Hydra managers play also a key role in assuring the self-* capabilities to the Hydra platform. The Hydra middleware is also in charge of assuring Security, Trust and Privacy which have specific relevance for the application domains Hydra focuses on. Hydra therefore defines a security meta-model ([Hydra]) having the following objectives: • be interoperable with existing security models, and extendable, • support semantically defined security requirements, • support virtualisation of end-users, services, and devices, even if to simplify implementation. The Hydra security meta-model is based on the following concepts: • security context: is a logical security boundary between the middleware and devices/applications/users; • semantic security: Hydra security is a model and rules driven framework. The semantic security approach enable not only to formalise security models and 21

See project home page: http://www.hydramiddleware.eu/

Category: Report

Status: Final


16/12/2011

•

Pag. 38


rules, but also assure interoperability and proper translation between heterogeneous entities, as well as delegation of security decisions and dynamic adaption according to the specific contexts; virtualisation or separation between the physical and logical representations to correctly manage the security requirements as dictated by the contexts.

The resulting Hydra access control mechanism can be considered a Context-Based Access Control (CBAC) system able to support more dynamic and unforeseen scenarios, and as an enhancement of a more traditional Role-Based Access Control (RBAC) system. The follow-up project of HYDRA is the EBBITS22 Project (Enabling the businessbased Internet of Things and Services) that “... does research in architecture, technologies and processes, which allow businesses to semantically integrate the Internet of Things into mainstream enterprise systems and support interoperable end-to-end business applications”. 2.3.2.5 CASAGRAS Project CASAGRAS23 (Coordination And Support Action for Global RFID-related Activities and Standardisation) is an FP7 project, ended in 2009, focused on the development and the standardisation of a framework to support radio frequency identification (RFID) and the emerging "Internet of Things". In particular the CASAGRAS project focused on the provision of: • a platform for international collaboration on all aspects of standards and regulations relating RFID; • a framework to support analytical review of international RFID standards; • recommendations with respect to international standardisation and regulatory developments for RFID; • recommendations with respect to applications methodologies; • recommendations for future research and development and international collaboration; • recommendations to encourage participation of SMEs; • a collaborative research platform for RFID. Even if CASAGRAS’s focus was mainly on RFID technologies, anyway it has promoted a view of the Internet of Things as a “metaphor for the universality of communication processes, for the integration of any kind of digital data and content, for the unique identification of real or virtual objects and for architectures that provide the ‘communicative glue’ among these components” ([CASAGRAS]). Specific issues addressed in CASAGRAS are related to: objects identification, use of semantic technologies for exploiting the semantic capability of objects (devices, sensors, etc.) or to improve information interoperability, and for Web 2.0 concepts applied to the IoT world (mashup of data and functionalities). As a follow-up to CASAGRAS in June 2010 a new FP7 Coordination and Support Action (called CASAGRAS224) has started with the objective to foster both European and international cooperation in the IoT domain. 22

See project home page: http://www.ebbits-project.eu/ See project home page: http://www.rfidglobal.eu/ 24 See project home page: http://iot-casagras.org/ 23

Category: Report

Status: Final


16/12/2011

Pag. 39


2.3.2.6 flexWARE Project flexWARE25 (Flexible Wireless Automation in Real-time Environments) is an FP7 project focused on the development of a platform providing real-time communication based on different wireless technologies (and specifically on IEEE 802.11) for factory automation. The project start from considering that communication systems for application automation inside factories have evolved from purely dedicated fieldbus to Ethernet based technologies and that the wide adoption of wireless networking in offices and other contexts will foster the use of wireless communication for application automation in factories. The flexWARE scenario envisages sensor and actuator nodes communicating and cooperating with other wired or wireless nodes, therefore meeting tomorrow’s factories requirements, where production lines could not have statically defined path of goods through production machinery. The flexWARE middleware will provide security features in line with the flexibility, mobility and real-time requirements of the communicating nodes. In addition flexWARE envisages localization services that enable dynamic, network reconfiguration coping factory of the future needs. The flexWARE middleware interfaces available to applications will be open to foster a rapid and wide adoption of its solutions by third parties. 2.3.2.7 GEMOM Project GEMOM26 (Genetic Message Oriented Secure Middleware) is an FP7 project, ended in June 2010, with the objective of develop a prototype of a publish/subscribe messaging platform providing advanced evolutionary, self-organising, self-healing, scalable and secure features. The GEMOM self-healing, self-organising and security features (see [AbieIJAS] and [AbieCP1281]) are based on the concerted usage of system monitoring and adaptive features supported by specific metrics (e.g. for QoS, security). Information regarding system status and behaviour (e.g.: number of client sessions, transferred data, bandwidth usage, etc.) are continuously collected and analysed by specific system components and evaluated against specific metrics. The outcomes of these analyses are used to tune the system or to raise its security bar (e.g. require a stronger authentication to gain access to the system, renew encryption keys, etc.). The system therefore is able not only to identify faults, performance issues or security attacks, but also forecast potential performance or security problems. The availability of adaptive capabilities (e.g. Adaptive Authentication, Adaptive Authorization, Adaptive end-to-end Confidentiality, topology reconfiguration) enable the system to react to existing or envisaged problems and try to assure the expected quality of services. 2.3.2.8 CHAT Project CHAT27 (Control of Heterogeneous Automation Systems) is an FP7 project which is developing next-generation distributed control systems, able to meet the both supervision and control needs for larger and more complex automated industrial 25 See project home page: http://www.flexware.at/ 26 See GEMOM web site http://www.gemom.eu/ 27 See project home page: http://www.ict-chat.eu/

Category: Report

Status: Final


16/12/2011

Pag. 40


plants, and, at the same time, drastically reduce the required infrastructure, maintenance and reconfiguration costs. The project aims at providing both a unified design methodology, and a set of specific tools and technologies able to support the project’s view for industrial automation. The CHAT research activities are focused on achieving advancements in the following areas: • mastering the complexity of large-scale distributed implementation of algorithms (e.g.: optimization via price mechanisms and market game theory, consensus on logical functions); • harnessing the temporal and spatial uncertainties of networked industrial automation and cope with stringent real-time control requirements (e.g.: control with shared limited resources, anytime control); • designing a generic, but functional and effective, middleware architecture for automation components, supporting composability, connectivity, and dynamic reconfigurability (e.g.: encapsulation and modularization for automation components); • coping with the fragility of networked systems (due to component failures and potential malicious attacks) providing for safety and security of operations compatible with resource constraints at each node (including intrusion detection in distributed systems). 2.3.2.9 SENSEI Project SENSEI28 (Integrating the Physical with the Digital World of the Network of the Future) is a large FP7 IP project under the Challenge 1: Pervasive and Trusted Network and Service Infrastructures: ICT-2007.1.1: The Network of the Future. The project started in January 2008 and will end in 2010 involving 19 partners from 11 European countries. The SENSEI objective is to develop an open, business driven framework able to integrate heterogeneous wireless sensor and actuator networks (WS&AN). The SENSEI framework provides the required network and management services to reliably retrieve detailed context information and to support interactions with the physical environment. The SENSEI framework envisages mechanisms for accounting, security privacy and trust in an open WS&AN environment. Even if the SENSEI focus is different from the IoT@Work one, there are still interesting and synergic aspects. In particular, SENSEI analyses and correlates the physical and digital worlds. The physical world hosts sensors, actuators and processing elements organised in islands of wireless sensor and actuator networks. The digital world, instead, is made up of resources (which represent the objects, sensors/actuators/processing elements, of the physical world), entities of interest (which represent people, places and things) and resources users (which represent people or applications that interact with resources or entities of interest; In the SENSEI view resource user can interact with resources both directly (for situation in which the interaction context is irrelevant or very simple and, in any case, in charge of the interacting application), or via the SENSEI context model services (relieving applications from context management). The SENSEI system model identifies and characterises both entities and their corresponding relationships. To this end the SENSEI model differentiates between the (physical) instances of system resources (called Resource) and the software components implementing the interaction endpoints from the user perspective (called Resource End Point). In addition the SENSEI model differentiates between the 28

See SENSEI web site http://www.ict-sensei.org

Category: Report

Status: Final


16/12/2011

Pag. 41


devices hosting these resources (Resource host) and the network devices hosting the respective interaction end points (REP host). This differentiation improves SENSEI capability to deal with real world dynamics, as well as its efficiency and efficacy, while at the same time allowing different deployment models able to more efficiently address the scalability problems of large distributed WS&AN systems. 2.3.2.10 IoT-A Project IoT-A29 (Internet of Things Architecture) is a large FP7 IP project, started in September 2010, with the objective to be29 “the European Lighthouse Integrated Project addressing the Internet-of-Things Architecture”. IoT-A aims at defining and developing an architectural reference model and a set of building blocks providing the most basic and crucial functionalities. IoT-A plans to foster the European future Internet of Things moving from the current fragmented architectures and solutions (that lack unifying concepts, cross-sectorial reusability and interoperability, and are domains tied) to a scenario having: • unified architectural foundations able to assure interoperable Internet of Things (moving from Intranet-of-Things to an effective Internet-of-Things); • an architectural reference model together with common basic, building blocks; • support to federate existing technologies in order to not re-invent the wheel; • the capability of federating heterogeneous IoT technologies into an interoperable IoT fabric; • no deployment barriers even for large scale solutions and domains; • specific mechanisms to efficiently integrate IoT-A based IoT networks within Future Internet service layer; • a protocol suite, below the service layer, based on open protocols (new IoT-A developed protocols or protocol’s enhancements will be submitted to standardisation bodies); • a novel resolution infrastructure allowing scalable look-up and discovery of IoT resources and entities. The IoT-A approach and solutions will be validated and demonstrated in real, significant application domains via the implementation of specific use cases. Currently the most relevant ones are related to Health & Home, and Retail & Automation. Even if in its initial phase, IoT-A has relevance for IoT@Work both for commonalities of some research areas, and for commonalities between IoT@Work application domain and one of the IoT-A use cases. 2.3.2.11 IoT-i Project IoT-i30 (Internet of Things Initiative) is an FP7 Coordination and Support action, started in September 2010, with the objectives to: • create a European, joint strategic and technical vision for the IoT; • contribute to the creation of a European, economically sustainable and socially acceptable environment for IoT technologies and related R&D activities; • promote international adoption of European IoT technology. 29 30

See IoT-A web site http://www.iot-a.eu/ See IoT-i web site http://www.iot-i.eu/

Category: Report

Status: Final


16/12/2011

Pag. 42


IoT-i and IoT-A, even if formally independent, can be considered as parallel projects, where IoT-A focuses on the development and validation of an integrated IoT network architecture and supporting building blocks, while IoT-i focuses on the promotion of IoT solutions, catching requirements and interests, involving stakeholders and promoting international cooperation in the IoT domain. 2.3.2.12 Open Garments Project Open Garments31 is a 36 months FP7 project, started in 2008, funded under the Theme 4 – NMP - Nanosciences, Nanotechnologies, Materials and new Production Technologies whose objective is to31 “... empower the consumer as designer, producer and retailer for individual garments”. Relevant aspects of the Open Garments, from an IoT@Work point of view, project are related to the focus of the project on the adoption of an Open Manufacturing approach in which existing, and new, technologies for design and production are integrated and finalised to produce individual garments (i.e. highly customised goods). Open Manufacturing ([Fujimoto]) is a new concept for the production of customised physical goods that requires a flexible network of production units aligned to mass customisation and rapid manufacturing for fast and flexible fulfilment of small size orders. 2.3.2.13 TIPSS Project TIPSS32 (Tools for Innovative Product-Service-Systems for Global Tool and Die Networks) is an FP7 project funded under the Theme 4 – NMP - Nanosciences, Nanotechnologies, Materials and new Production Technologies whose objective is to support “changing the role of injection machines toolmakers from producers to service-providers on global business networks”. The project is innovating the production process of injection moulding machines both in plant, via the use of injection machines equipped with smart tools, and enabling toolmakers to extend their presence and services both locally and internationally thanks to the availability of a web based platform through which real-time production data and supporting services are provided. The smart tools are injection moulds equipped with state of the art sensor technology able to acquire real-time production data and provide them through the project’s software platform. These smart tools provide their monitoring data via DPWS and/or REST interfaces. The TIPSS software platform is a SOA compliant, distributed system providing a middleware able to distribute in a controlled way the real-time production data, and a set of web applications devoted to support the producers, the toolmakers, their partners, and their collaboration. The TIPSS platform supports data/service mashup, management of the real-time data streams carrying the production data, their distribution to authorised subjects, as well as services for the on-line analysis of the gathered production data. 31 32

See project’s web site: http://www.open-garments.eu/ See TIPSS web site http://www.tipss-fp7.eu/

Category: Report

Status: Final


16/12/2011

Pag. 43


These enable an optimized mix of both condition-based and preventive maintenance services, which directly lead to an increase of the overall operational availability of the production cell. The platform capability to provide on request the same set of real-time data to different subjects and applications, without impacting already active services and applications, is one of the key characteristics of the TIPSS solution. Indeed, based on the current conditions (including contractual ones among the producer, the toolmaker and its partners), different algorithms and methods can be activated to process the production data to intelligently interpret the gathered data minimizing the response and/or repair times. 2.3.2.14 CoReNet Project CoReNet33 (Customer-ORiented and Eco-friendly NETworks for health fashionable goods) is an FP7 project, started in June 2010, funded under the Theme 4 – NMP - Nanosciences, Nanotechnologies, Materials and new Production Technologies whose objective is to develop methods, tools and technologies for sustainable small series productions of healthy fashionable clothing, footwear and accessories for consumer with health problems. Also this project will adopt, and adapt, an Open Manufacturing approach to be able to support the required customisation and create sustainable small series production processes. CoReNet issues related to: • get and manage consumer needs, • involve consumer into the product design and configuration phases, • exchange consumer data through secure systems, • manage the collaboration with suppliers in order to plan and distribute on time, • implement innovative manufacturing machines in particular for Digital Printing and Laser Engraving, • monitor the quality and sustainability of products and production processes, have synergies with IoT@Work research topics. 2.3.3

IoT European Research Cluster

The IERC Cluster34 (IoT European Research Cluster, previously named CERPIOT Cluster) is a coordination initiative, promoted by the DG INFSO D4 unit that brings together EU-funded projects to define and promote a common vision of the Internet of Things. The main objectives of the cluster are: • facilitate networking of, and synergies among, different European RFID and IoT projects; • coordinate European research activities in IoT domain, and with similar international initiatives and projects; • maximise projects’ impacts and optimise the development and use of expertise, talents, and resources. The cluster, apart for coordination meetings and activities, is also actively contributing to European Commission IoT strategies and actions definitions via the contribution of specific documents analysing the IoT issues. In particular: 33 34

See CoReNet web site: http://www.corenet-project.eu/ See cluster home page: http://www.rfid-in-action.eu/cerp

Category: Report

Status: Final


16/12/2011

Pag. 44


the Internet of Things Strategic Research Roadmap ([IoTSRA]) that proposes a list of IoT research areas and a roadmap on future R&D activities using three temporal visions: until 2010, before 2015 and beyond 2020; • the Vision and Challenges for Realising the Internet of Things ([IoTClBook]) cluster book presenting the projects activities and approaches, reporting the Fall 2009 CERP-IoT SRA ([IoTSRA]), and identifying specific areas of cooperation between research projects. The mentioned documents, and specifically the cluster book, report an interesting and wide analysis of Internet of Things issues related to: identification technologies, massive deployment of simple and smart devices, increasing connection between objects and systems. •

IoT@Work is one of the projects of the IERC cluster and counts as one of the EU projects, where the focus is made on exploiting the IoT technologies for the needs of a specific application area, namely industrial automation. As a result, the coordinator of the project is also now the leader of the “Exploitation Activity Chain”, which focuses on applications areas and the way to maximize the use of Io Technologies into real products. The contacts to other related industries and players within the cluster have already resulted into the first interactions on application needs and scenarios. More concretely, IoT@Work was represented in the stakeholder meeting of the IOT-A project, and in a dissemination workshop on using the HYDRA platform. Both projects have, and will, deal with architecture issues that are closely followed and taken into account by IoT@Work. Similarly, requirements identified in the area of factory and industrial automation are communicated and provided to the architecture teams within IOT-A. The follow-up IP project of HYDRA, EBBITS, has also been contacted. The view provided by COMAU (a robot and line supplier for FIAT) has been taken into account during the scenario-driven requirement collection. 2.3.4

National projects

2.3.4.1 SemProM Project SemProM35 (Semantic Product Memory) is a German project funded under the IKT-2020 research program of the German Federal Ministry of Education and Research (BMBF) and started in the spring of 2008. SemProM is a project covering a wide set of application domains for which next generation of mobile, embedded, and wireless elements (smart labels) play, or will play, a relevant role. The project technologies will therefore be implemented, standardised and customised for sectors like trade, logistics, health care, and automotives. The SemProM platform is based on semantic technologies, man-machine communication (M2M), intelligent sensor networks, instrumented environments, RFID technology and multimodal interaction. By the use of integrated, smart sensors, relations in the production process become transparent and supply chains, as well as environmental influences, retraceable. The producer gets supported and the consumer better informed about the product. The project, therefore, makes possible to place data and programming logic in a more flexible and efficient way to support production or business processes for the entire product life cycle and beyond system boundaries. 35

See project web site: http://www.semprom.org/semprom_engl/

Category: Report

Status: Final


16/12/2011

Pag. 45


SemProM smart labels support the detection and processing of data in the industrial field during each phase and step of the production process, as well as the access with user- and application-specific mobile end devices. 2.3.4.2 WS4Dsec Project WS4Dsec36 (Reliably Secure Web Services for Devices) is a German project funded by the DFG (German Research Foundation) and starting in November 2010. The project aims at developing reliable, secure data communication services for small, distributed and spontaneous interacting devices. The project starts from considering that current embedded systems are powerful enough to provide web services and thus enabling ad-hoc device connections as interoperable cross domain solutions. The project WS4Dsec will enhance WS4D solutions on security aspects, developing a specific toolkit, called WS4Dsec that enables a combined development and verification process for WS4D-enabled devices ensembles. Moreover, it will include capabilities for automatic code generation to reduce the complexity for the development of reliably secured service interactions. 2.3.4.3 inITial Project inITial37 (Higher productivity by model based design and operation of complex automation systems) is a German project funded in the context of the Hightech.NRW initiative of the government of North Rhine Westphalia and the EU. It started in January 2010. This project is going to address one of the key challenges in automation technology: The optimization of construction and operation of complex distributed plants using modern information technology methods; e.g. by early tests of automation systems and a system wide diagnosis. Since plants and machines are getting more and more complex, the diagnosis and error detection based on expert knowledge and observed symptoms becomes harder and is sometimes even impossible. Especially a creeping degradation cannot be detected by operators. For instance, such errors might cause a gradual degradation of the product quality which must be avoided under any circumstances. In the worst case they cause a complete stop of the system and a corresponding loss of production. This project aims at enabling a software based identification and diagnosis of errors and problems. Furthermore, a model based design of automation systems is addressed in this project.

2.4

Global Megatrends and their Relevance for Automation

The innovation speed for technologies is ever increasing. While the project concentrates on the automation field, or more specifically on IP/Ethernet issues regarding auto configuration and security, it cannot neglect what is happening in other areas of the world [EIF] [OECD] [Delphi2030] [BergerAut]. To estimate how popular global mega trends (i.e. global warming, aging society) influence the automation world, it is important to identify and analyse drivers and inhibitors which will change the way we make business. This is true for technical issues, i.e. miniaturization, marketing issues and socio-economic trends. For this paper, the level of detailing will increase towards technical issues (see §2.5 on pag. 48), but is important to first cover a broad range of important global trends herein and describe the impact on the core automation field. 36 37

See project web site: http://www.imd.uni-rostock.de/index.php?id=ws4dsec See project web site: http://www.initial-projekt.de

Category: Report

Status: Final


16/12/2011

Pag. 46


Figure 2.6 – Lead Markets for Automation Industry (source [Bent]) As this project runs until 2012 and potential products are expected another two years later, the main focus will be in the time frame of now to roughly 2015. The world market for automation in 2008 had a size of around 290 billion € (see Figure 2.6). Thus it clearly will play a major role in the global challenges of the presence and the future. Major trends include: • Global Warming: this trend has a major impact for the automation industry. Due to the increasing need to save energy, reduce the CO2 footprint and other environmental impact of production and modern society, the automation industry must reduce its own environmental impact and the lead markets for automation products will change. As of today, the automotive industry in Europe holds the largest portion of the market, but will be outperformed by "green" technologies (i.e. SCADA systems for water or smart energy, see [VDI_VDE]). • Aging Society: apart from home automation as a mean to support elder people, this trend is not expected to have a major impact on automation. • Mega Cities: there are estimations that in 2030 more than 60% of the world population will live in cities. Many of these cities will be so called "Mega Cities" having more than 10 million inhabitants. The effects of this trend for the automation are increased need for SCADA systems in the area of traffic control and security, but also for water, gas, energy and building control. There are however regional differences, for example especially in Asia a huge invest for both clean and waste water controlling automation is expected. And these are not only new installations, but also modernization of existing systems. • Globalization: in this context we collect several trends: outsourcing of various parts of an automation process - from engineering to production leads to a complex network of business partners forming an industrial value chain; building sites in countries across the world where the customers are, where costs for workers are low or where the materials origin lead to a globally distribution of manufacturing sites. These impose significant challenges on all layers of production control - logistics, marketing, production of local variants and more. It also means that the established companies in Category: Report

Status: Final


16/12/2011

Pag. 47


Germany, Europe and US have to face more and more the competition of China, India and other emerging countries. As a consequence, European vendors must be able to produce fast and cost efficiently and must keep an eye on export issues ([Pinto]). There are some other important global trends which have impact on the automation but are in general not termed "Mega Trend": • Terrorism/Espionage: criminal and terror activities are expected to have a significant impact on automation industry. On the one hand this may be a driver for automation solutions in the security context, on the other hand automation systems are more and more also a target for attackers. • Lack of skilled people today (see Figure 2.7) is becoming a problem especially (but not only) in the western world. Because this mainly is a lack of medium to higher skilled people, one obvious consequence is to provide means to allow unskilled people to handle complex products ([AWNC], [Maes]). Other strategies to overcome this are remote service concepts, where few skilled people can handle many support cases.

Figure 2.7 – Personnel Shortage (source [Maes]) •

•

Shortage of rare materials: today's high-tech industry increasingly depends on the availability of certain rare materials, i.e. antimony, beryllium, cobalt and more. This will become a major driver for recycling and modernization (rather than complete new products). Ever increasing number of networked devices: digitalization and network access is a still ongoing trend. Namely formerly analogue sensors are nowadays interconnected to the automation network by means of gateways ("I/O-module"), but standards like i.e. Zigbee show that even small and lowpowered sensor can and will be connected directly to the network. And there's the demand from higher-layer services such as ERP systems to interact tightly with those devices and other services. This trend however creates significant threads for security, reliability and usability. Another aspect here is the huge number of mobile devices which may also interact with automation devices in some scenarios (i.e. public spaces such as trains, buildings).

Category: Report

Status: Final


16/12/2011

Pag. 48


In sum, future automation will have a stronger focus on SCADA systems for utilities. In order to remain competitive, the manufacturing and machine building industry are in need of innovations enabling cost’s reduction, problems’ handling with the lack of skilled people and the flexibility to take fast advantage of the situation in the market. System architectures must ensure high robustness against criminal attacks and should provide ease-of-use even for less skilled workers. Modernization of existing installations (or retro-fitting) is important both in developed countries and elsewhere in the world. Being able to provide remote support without - or with less - costly onsite work will be essential. IoT@Work will address those issues by industrial security, auto configuration and clear migration means.

2.5

Trends in Automation

2.5.1

Overview

http://www.real-time-Ethernet.de/ currently lists 29 industrial Ethernet solutions. They all have their own strength and weaknesses, and the sheer number of often competing solutions can be taken as an indicator that there is always room for specific and often innovative solutions. Rostan ([Rostan]) briefly compares the most important ones with a focus on real time performance. However those performance numbers are only one of many properties of a successful system. Important for solutions capable of playing a major role in a future Internet-of-Things environment is the ability to cover new requirements, to adopt new technologies and to follow market trends. While §2.4 (see pag. 45) briefly describes the so-called mega trends and their impact on IoT technologies and automation, this chapter concentrates more on already ongoing short and mid-term trends in automation. §2.5.2 lists the "hot topics" which are addressed now and in the near future in the respective standard bodies, while the remaining sub-chapters concentrate on general technology and market trends which will have an impact on automation. The last section (§2.5.7) is a try to identify potentially disruptive issues. 2.5.2

General Trends in Automation Standards

As a general trend, the automation standards since years try to adapt general purpose technologies to their needs and to re-use mainstream components. This also means a re-use of Internet-related standards from the IETF, IEEE 802 and W3C. While those standards have their origins in LAN and telecommunication world, industry specific issues are more and more addressed although the fraction contributions from the automation or manufacturing industry is still very low. Increased use of Ethernet and IP based technologies will also lead to a reduced use of field bus systems [Profibus]. The current hot topics are [Mitchell]: • implement industrial real-time networks by means of standard "legacy" technologies from the IETF and IEEE standard bodies rather than use specific technology. One candidate here is the Audio/Video Bridging (AVB) set of standards developed by the IEEE 802.1 Audio Video Bridging Task Group. AVB, originally meant to transport audio/video, is currently investigated as a mean to enhance real-time capabilities of Ethernet. The original approach of AVB cannot easily handle industrial requirements [Imtiaz], but recently industry experts joined the IEEE AVB TG to eventually influence this standard; Category: Report

Status: Final


16/12/2011

Pag. 49


•

wireless legacy technologies are also a topic for industrial scenarios and an ongoing activity for improvements (see also §2.5.5 on pag. 51);

•

Service oriented Architectures are still an ongoing topic and a strong trend. The OPC Foundation for example recently published the "OPC Unified Architecture” ([OPCUA]), a web service variant of the older OPC protocols. As of today, not everything can be controlled by OPC-UA and not all industrial automation standards use it. There are also still issues with real time support;

•

concepts for energy savings in automation or SCADA networks are a big issue. But it is difficult to power down parts of a network in a controlled manner and then restart them again fast and in the right order. Power saving modes on the network (i.e. the Energy Efficient Ethernet defined by IEEE 802.3az) or in devices may not easily be used in a real-time scenario. The Profinet was the first Standardisation Body which recently published its ProfiEnergy Profile, but other standards are expected to follow;

•

integration of various applications such as automation, safety, SCADA, condition monitoring, surveillance, audio (telephony, i.e. for maintenance) in one infrastructure is currently one of the main drivers for new standards and products. This is still and ongoing development, several issues regarding security, quality-of-service and especially for the planning, commissioning and maintenance are not yet mature and lean enough;

•

PLC-as-a-Service: industrial PCs, equipped with modern multi-core processors and operating systems with real-time and virtualisation support, are becoming a modern platform for SW-based PLCs, sophisticated HMIs and other services. As a countertrend - or as a complement - distribution of control and pre-processing in the field comes by means of intelligent, programmable I/O devices [AddiData] which then only require standard Ethernet (without tight real-time constraints) to communicate with the MES and ERP level;

•

IPv6 is becoming an urgent issue in the public Internet. But only few companies are providing IPv6-ready industrial products and the current standards are not IPv6 capable. Starting in Asia, IPv6 is coming very soon in the public Internet, Europe and America are following. On the other end, sensor networks based on the Zigbee Standard are already using IPv6 only. At the moment those IPv6 networks can only be interfaced to automation networks by means of costly gateways. Thus it is clear that IPv6 will come into the industrial world, but it is yet unclear when it will have a significant share of the market. It is worth noting that IPv6 will also affect most of the commissioning and planning tools. And most industrial standard bodies are not yet addressing IPv6 ([Moxa], [Batke] [IPv6adapt]);

•

enhancements of the performance, real-time capabilities and reliability are an ongoing issue. As an example, Kontron, a German component vendor, just announced the first 10 Gbps industrial switches. As another example, the Profinet User Organisation (PNO) will specify performance optimisations and faster start-up procedures in its Version 2,3 of the Profinet protocol and next steps may try to enhance reliability by means of redundancy mechanisms;

•

retrofitting as a driver: to reduce costs for new equipment, to overcome challenges from shortages regarding components or to modernize stepwise an existing installation, retrofitting is a major driver on the market. Products affected by these trends are simulation tools (including virtual commissioning) to ensure proper operation after update of components, multi-protocol devices

Category: Report

Status: Final


16/12/2011

Pag. 50


or protocol-converters (i.e. to upgrade existing field bus systems to industrial Ethernet); •

the need for well designed security for mission critical systems in times of cyber attacks or physical terrorism is an ongoing and well accepted issue. But especially since the infamous Stuxnet virus attacking PLCs, the awareness also for (physically) separated factory networks has grown and demands for secure solutions.

•

enhancing semantic knowledge and automatic understanding of processes and technical installations is one of the Internet of Things technologies, which e.g. is addressed by the German SemProm research project ([Semprom]) (see §2.3.4.1 on pag. 44).

2.5.3

HW Trends

Since many years, the most important trend on the HW side is the ongoing increase in processing power (Moore's law). This is not only true for server and desktop machines but also for embedded devices. There are anyway other important observations: • multi-core processors (e.g. based on the Intel Atom) are coming in small industrial devices such as I/O modules. Those processors have been developed for mobile devices and will bring more processing power and better real-time support with less energy consumption. Many of them also have already HW support for virtualization. This trend is not only true for general purpose processors like the Intel Atom but also for ASIC embeddable processor cores, i.e. the brand new ARM Cortex-A15 ("Eagle") ([ARM]). As of today it must be stated that virtualization support is still a high-end feature not found in small controllers or smaller embeddable cores. However one can expect that this will change soon; •

human-machine-interfaces (HMI) are important components. It can be expected that recent innovations from the consumer world will be adopted, i.e. multi-touch and multi-gesture touch pads, brilliant OLED displays, a multitude of orientation sensors and eventually 3-D displays.

Network technologies in LAN/WAN/Mobile world are also driving new products in industrial networks. The Quality-of-Service concept from the IEEE 802 AVB TG has been mentioned above; the battle of those AVB versus special concepts from Profinet or other standards has just begun and will most likely end up by using AVB as an enhancement to non-isochronous (non-motion-control) network traffic but not as a replacement of those special concepts. Second issue adopted by industrial networks is the use of new high speed standards, such as e.g. 10 Gbps or 40 Gbps. First products for these speeds are meant for server and imaging scenarios or to bundle multiple 1 Gbps links. While the general trend is to re-use communication technology with few enhancements and let others do the standardisation work, this is not true for wireless standards. Here, automation experts can be found in (mainly) IEEE driven topics like Wireless Hart, Zigbee and more. 2.5.4

Software Trends

Similar to other technologies, industrial SW adopts and re-uses trends of the nonautomation world: • on the operating systems side, this is mainly virtualization and the use of standard, mainstream operating systems from small sensors to powerful servers. Examples include on the open source side embedded Linux, TinyOS Category: Report

Status: Final


16/12/2011

Pag. 51


(http://www.tinyos.net/) or eCos (http://ecos.sourceware.org/). Successful commercial examples are VxWorks or Microsoft Windows (various versions); •

development tools, processes and languages will follow standard trends as well but they will still be specific to the automation domain. While object oriented programming of automation systems using IEC 61499 is not new (standard from 2005), this trends continues by using e.g. standard IDEs (Microsoft Visual Studio) and will clearly move away from "PLC Programming" to standard SW development as soon as web services are used;

•

cloud computing is another important trend infiltrating the industrial world, but mainly on the enterprise level and not yet in the factory floor;

•

Open Source is a well accepted license form (not only) in the embedded world. However due to the high quality requirements or very specific needs (i.e. real-time capabilities) Open Source SW will not threatening vendors of those SW and will be most likely have their focus on not-so-specific multipurpose and less mission critical topics, i.e. network management, visualisation frameworks and in general on topics where mature and wellproven SW is available (i.e. operating systems). A second well accepted niche for Open Source is the mid-range sized embedded devices (i.e. I/O devices).

2.5.5

Wireless

Increased use of wireless technologies is a major trend in automation, SCADA and manufacturing networks. On the one hand legacy technology is frequently used, on the other hand specific wireless standards and technologies are developed and used, many of them being proprietary: • the IEEE 802.11 WLAN standards family and are already used for industrial purpose but still lack the reliability and real-time capabilities needed for some automation tasks (i.e. no motion control). To enhance the usefulness for industrial applications, first products of low-power 802.11n WLAN are in the market making WLAN also useful for battery-powered or battery-less devices ([Ultra]); •

the Bluetooth short range standard got some new features in the latest release 4.0 introducing fast connection set-up (less than 5 msec) and power saving techniques making it interesting also for industrial sensors or RFID-like scenarios;

•

wireless industrial standards such as Wireless HART, Zigbee are driven by the automation/SCADA industry and thus an example of specific standards not derived from legacy technologies. Both are based on the IEEE 802.15.42006 physical layer and will play a role for low-power sensor networks. Wireless IO Link is on the agenda of the PNIO for the next years;

•

Radio Frequency Tags (RFID) in the public press are a core technology for the Internet-of-Things. Apart from the normal evolution bringing better reliability or longer range one notable trend is to introduce improved computing power even in passive RFIDs. This will open the way to much smarter applications ([Yeager]). Under the term Near Field Communication (NFC) new active sensors together with new antenna technologies will arise with vastly improved detection speed, higher reliability and more memory and processing power;

Category: Report

Status: Final


16/12/2011

•

Pag. 52


for sensors and small actuators several trends apply today: standardised digital interfaces for wired devices, such as the IO-Link standard from the PNIO will slowly replace analogue and proprietary interfaces. They also provide means to get live state and a device description and thus fit very well into future automation networks, o energy consumption is especially a critical issue for wireless sensor. Here, battery-less devices (i.e. from EnOcean) using some mean of energy harvesting or very low power devices with long living batteries are a major trend; M2M and other outdoor scenarios as of today predominantly use GPRS. With the growing availability of UMTS and the upcoming LTE much higher data rates here will enable new applications, i.e. wireless video monitoring. o

•

Many, if not all wireless scenarios today, are not mobile in the sense that devices do not change their point-of-attachment in the network while communicating. That is, industrial wireless often is just used as a cable replacement. This may change in the future if more self-driving robots occur, i.e. in logistics or for surveillance. 2.5.6

Security technology

The first trend is deperimeterization. In the past it was possible to secure a network perimeter and have no security measures inside this frontier. With the increasing interconnection of automation networks, both among them and with other networks (e.g. office network), frontiers more and more dissolve. Hence, security in depth is needed. Another trend is the increasing vulnerability of systems and the resulting increasing number of attacks on implementations. One reason for the increasing number of vulnerabilities is the increasing complexity of the software used. The increased use of cryptographic integrity checkers that allow validating the system integrity is another trend. Cryptographic integrity checkers help to avoid vulnerability exploitation and are useful to ensure that systems only use allowed components. As security becomes more and more important even for resource-constraint devices, hardware support for security functions becomes more common. Security functions are usually computationally expensive; hence hardware support helps to reduce the execution time as well as the energy consumption of security functions. Last but not least, Role Base Access Control gains importance for authorization of execution of options on devices 2.5.7

Disruptive technologies

There are many remarkable, truly innovative developments which may result in a disruptive business impact. We present here a selection of technologies which may play a major role in future computer or communication systems and especially in embedded and industrial applications: • http://www.lyricsemiconductor.com/ develops a processor type specifically designed for probability calculations. It is said to be orders of magnitude faster than traditional processors for certain problems in i.e. pattern recognition, error correction and more. This technology - embedded in smart sensors (acoustics, video, vibration ...) - may have significant impact on condition monitoring or security systems; • new ways to produce parts, technologies coming from the rapid prototyping, like e.g. digital fabricator, may evolve to a useful tool to produce small series of products by means of sophisticated 3D-printers or alike [3DPrint]. Probably even more "science fiction" ideas like the "utility fog" (also called foglets, Category: Report

Status: Final


16/12/2011

•

•

Pag. 53


http://www.nanotech-now.com/utility-fog.htm), small (nano or almost nano size) robots could self-organize to assemble the required products; nano-sensors and nano-communication are basically technologies to assemble a nano-sized sensor with (at least) RFID intelligence. Such a thing will have means to communicate wirelessly; it may have signal processing and sensing capabilities and can form small networks ([Patawardahn]). First applications are targeted for the medical market (i.e. medical sensors in the blood), but those sensors could also play a role automation, i.e. to mark and monitor parts; CMOx technology (www.electronicsweekly.com, www.unitysemi.com/) is a potential killer for Flash memory technology: 10 times fast compared to NAND technology, but still non-volatile, less power consumption, lower prices and less space requirements. This for sure will boost all embedded devices and enables storing large data sets in the field even on small low-cost sensors.

Category: Report

Status: Final


16/12/2011

Pag. 54


3 Scenarios 3.1

Scenarios Definition Methodology

The early collection of scenarios has been defined as the way to approach both requirement collection and, in a later stage, the definition of an initial pilot scenario. For this purpose brief telegram-style scenarios have been collected. The purpose of what we called scenario telegrams is to identify related topics that are found in both literature or have been addressed by project partners in different internal projects. The process defined for dealing with the telegrams is shown in Figure 3.1.

Figure 3.1 – Scenario Driven Requirement Analysis This approach and process will prosecute in the immediate future as an effective way to both refine the performed analysis and, in parallel with the architectural and services design activities, to expand/deep investigation areas and aspects. The outcomes of these refinements will be used to update this deliverable so that to maintain it aligned with the analysis and investigations.

3.2

Collected Scenario Telegrams

The template used for collecting the scenario telegrams can be found in §5 (Appendix A – External Scenarios Telegram on pag. 67). The resulting telegrams originated from the following industrial domains or sectors: • Automotives Industry, • Infrastructure SCADA, • Food & Beverage, • Light-weight industries (textile, plastics, etc.). The resulting 18 telegrams have resulted into a multitude of views of the different industrial fields. The initial analysis of the scenarios showed that the scenarios were very heterogeneous in the problems addressed, the system descriptions, or the level addressed (process level).

Category: Report

Status: Final


16/12/2011

Pag. 55


Although the IoT@Work project addresses mostly the control and field levels in the manufacturing pyramid, the telegrams were driven by manufacturing scenarios that addressed different levels. This approach was initially chosen to widen the use cases and aspects where the IoT@Work technologies will have either a direct or indirect improvement. The analysis of the manufacturing processes and applications can be split into four categories (see Figure 3.2): • control and monitoring, • maintenance, • distributed manufacturing, • process chains. The scenarios analysis was carried out according to different criteria including: • The relation to the manufacturing scenarios available at FIAT and inIT research facilities; • The relation to the IoT@Work technical topics and general addressed problems; • The level of complexity of the automation scenario and addressed problems; • The availability of the information and access to external experts. The remaining criteria are illustrated in Figure 3.3.

Category: Report

Status: Final


16/12/2011

Pag. 56


Figure 3.2 – Scenario Telegram Analysis

Category: Report

Status: Final


16/12/2011

Pag. 57


Figure 3.3 – Telegram Analysis Criteria

Category: Report

Status: Final


16/12/2011

•

• •

Pag. 58


After a careful analysis of the telegram scenarios we decided that the following application areas provided a concise but also comprehensive representation of the scenarios analysed. Agile Manufacturing, Remote Maintenance, Multi-Site and Large Scale Manufacturing.

The current status of analyses and definition of these three clusters are reported in the appendixes. In the future these clusters’ analyses will be further refined, as already stated, to take into account further aspects coming from the future WPs activities. The refinements will be reported in future new versions of this deliverable in order to assure a single point of reference both within and outside the project.

3.3

Scenario Clusters

3.3.1

Scenario Clusters Overview

The scenario clusters are a selection of where the pilot could concentrate on. The three scenario clusters were used to provide initial high level requirements which are reported in §4 (pag. 60). The scenario clusters are also used to describe the system model assumed in the project. This system model can then define the implementation steps to initiate the “agile implementation” tasks in both WP2 and WP3. All scenario analyses, as reported in their corresponding appendixes, have an almost similar structure: • scenario meta-data: is a section providing essential information on the involved telegrams, specific references and other issues; • definition section: where an analysis of the addressed area is reported, as well as key aspects and issues; • scenarios and industry data: quickly depicts what is currently used or available in the analyzed scenario. Each scenario has additional sections as required to better analyze it and report the outcomes. 3.3.2

Agile Manufacturing

As reported in the executive summary, Agile Manufacturing “is a production approach heavily based on the availability of manufacturing support technology that can be easily reconfigured to quickly respond to market changes still providing full control of production costs and quality. Agile manufacturing is universally considered as the next step after the lean production methodology”. Manufacturing may need to be agile both for internal reasons, e.g., faults, and external reasons, e.g., change in the type of products that should be produced or in the production volume. Agility can therefore be required at many different levels – from the network level (adapting network resources for network faults or increased load), to the process level (adapting processes to new requirements). §6 “Appendix B - Agile Manufacturing”, on pag. 71, details the current status of this scenario analyses. 3.3.3

Large Scale Manufacturing

As reported in the executive summary, Large Scale Manufacturing “… is representative of large production arrangements where many different production sites have to be coordinated and integrated. This scenario is comprehensive of both Category: Report

Status: Final


16/12/2011

Pag. 59


situations in which the different sites belong to the same producer, as well as situations in which the involved sites belong to different producers pertaining to a highly integrated supply chain”. We use the term Large Scale Manufacturing, therefore, for scenarios where the automation network is structured into multiple physically (and in many cases also administrative) separated networks, often operated and owned by one holder. Typically, this will be a large manufacturer having many sites across the world that are interconnected via high-level logistic and ERP processes. As such, the large scale manufacturing consists out of a set of automation network "islands" and an enterprise backbone network. Additionally, but not necessarily, other parties such as subcontractors and service providers may be loosely integrated into the manufacturing IT. §7 “Appendix C – Large Scale Manufacturing”, on pag. 90, details the current status of this scenario analyses. 3.3.4

Remote Maintenance

The executive summary states for the Remote Maintenance: “this scenario helps analysing situations in which external providers (e.g. robots/tools providers) have direct access to devices or data within the production sites to assure production continuity for example doing preventive maintenance”. Under this label, therefore, we collect aspects that do not pertain to specific manufacturing approaches (like Agile Manufacturing) or relevant for the dimension or numbers of involved networks and/or partners. Indeed this scenario try to factor together issues that are common in almost all manufacturing processes related to the need of external subjects to access systems or data within the production environment. §8 “Appendix D – Remote Maintenance”, on pag. 96, details the current status of this scenario analyses.

Category: Report

Status: Final


16/12/2011

Pag. 60


4 Initial Requirements Specification 4.1

Introduction to the Requirements Collection Process

The requirement collection phase is seen as the trigger to the architecture design. IoT@Work has opted for an iterative approach rather than a cascade model for developing the architecture. The first step was to look into the addressed problems and the proposed approaches detailed in the project proposal, then, broaden the understanding of the problem domain by looking specifically at use case scenarios. For this purpose the scenarios, first generated in the form of specific industrial domains’ telegrams (see §3.2 on pag. 54), and afterwards aggregated in scenario clusters, have triggered a deeper analysis of the problems that need be addressed by IoT@Work and their importance. As already reported, the initial requirement collection is centered on the three scenario clusters “Agile Manufacturing”, “Large Scale Manufacturing”, and “Remote Maintenance”. These scenarios provided some details of the system model and underlying infrastructure found in common practice and state of the art. Based on the initial description of the system details, a first list of improvements, needs, and detailed changes have been extracted and formulated as requirements. Deliverable D1.1 focuses on the scenario driven generic requirements, whereas, the two other deliverables D2.1-IoT addressing schemes applied to manufacturing and D3.1-Threat analysis analyze and report complementary lists of requirements focused on their specific topics and technological aspects: naming and addressing issues for D2.1, and security requirements for D3.1. Even those technologically focused requirements have been extracted on the basis of the indicated scenarios. In the following sections a summary is provided of both the functionalities identified at this stage of the IoT@Work iterative approach, as well as of the generic (i.e. not specifically related to the technological issues addressed in D2.1 and D3.1) requirements collected till now. The analyses activities will be pursued in the immediate future both along the devised lines, as well as with additional and complementary initiatives as reported in section §4.4 Conclusions.

4.2

IoT@Work Target Facets

During the analyses of the three scenarios the below facets were found to be common to all of the scenarios, and they thus form the core of the IoT@Work design and specification activities. •

(Re)Configuration costs: the setup of a new system and changes (upgrades, replacements, modernization) must be significantly cheaper in terms of shorter time to configure, less outage times and less manual steps. Since there is a tight coupling between configuration costs and the particularities of the specific network setups, it is, due IoT@Work finite resource, not feasible to provide an analysis based on comprehensive empirical data. The proof of this savings will be thus be achieved through a qualitative analysis and, alternatively, through simulations. Selected and important aspects of this will be demonstrated in the pilot.

Category: Report

Status: Final


16/12/2011

Pag. 61


•

Decoupling network and automation: decoupling between communication networks and automation applications, and developing an orchestration plane for communication services as described in Objective 1 of the DoW.

•

Communication network resource abstraction and clear interface to a network-agnostic application: the configuration effort has to cater for the application needs, on the one hand, while removing the need to be an expert in both networking and automation programming. This separation means that the requirements of the supported applications are translated into requests pertaining to the network management level. The networks are managed in an application-aware manner, while the application is kept unaware of the details of the network itself as much as possible.

•

Realization of Communication Services: development of concepts and eventually protocols to realize the mandatorily required communication services based on recent IoT / communication network approaches.

•

Plug&Work: By the term Plug&Work we refer to the ability of devices and network components to auto-configure themselves according to the needs of the automation applications. Plug&Work shall work in multivendor environments and massively reduce the manual actions required, and, by so doing, it will also reduce both the overall downtime and the number of errors. o Self-configuring Networks: auto-configuration techniques are relied on when bootstrapping the network. Identifying network resources leads to a successful orchestration step. Both steps will be automated relying on network and topology recognition mechanisms, and on automated triggering of reservation protocols. o Graceful network level Plug&Work: if an automation device is replaced, re-authenticating, seamless configuration of naming and addresses has to occur. These changes and related ones in the network devices shall lead to as little interruption of the communication as possible. Network routing, service discovery and security mechanisms are needed when introducing, removing or replacing any device in the system. o IoT-based Naming and Addressing: the development of a semantic naming and addressing scheme, where application names and semantic roles of the devices influence the mapping between application level functionality, services and IP and MAC addresses. These techniques are inspired by the IoT naming and addressing efforts.

From the security perspective, IoT@Work will address selected security facets in three security technology areas: •

Secure Service Access: Define mechanisms for secure service access of third parties in a protected domain such as the factory floor. Investigate technologies and components involved for remote service access.

•

Secure Plug&Work: Develop security for Plug&Work mechanisms developed in WP2. The mechanisms contribute to the security bootstrapping as defined in the security architecture. Define an initial set of security parameters to be bootstrapped. Investigate procedural dependencies (e.g., production process) for the bootstrapping of security credentials. Define a secure Plug&Work solution.

•

Secure Communication: Analyze the applicability of currently used and deployed security protocols or security frameworks in industrial environments. If necessary, define extensions for use of protocols in industrial networks. Adapt candidate protocols to industrial communication if needed by developing bridging technologies.

Category: Report

Status: Final


16/12/2011

Pag. 62


The challenge is to demonstrate how we can enable Internet applications to connect with different roles and access rights to running devices and machines, without compromising the running system and fulfilling the requirements of automation. This will require a security framework that will take into account the security requirements needed at different phases of the systems’ life-cycle. This will also require security mechanisms that are integrated into resource allocation mechanisms. In addition to these functionalities, the following categories of cooperating components can be identified in manufacturing and automation: •

production equipment (PLC, HMI, robots, welders, conveyors, etc.) that is relevant by itself even if it has to work within an integrated environment. Availability of these kinds of components has to be assured by each single device (for example, no availability of spare devices – especially for the most expensive ones -, or being normally difficult a fast replacement of defective devices). Therefore from an IoT@Work point of view the objective is to act on their (re)configuration, (re)boot time and monitoring/maintenance, while still guarantee the safety requirements a production environment has to maintain;

•

network components, or better, layers of networks. Indeed we have different networks: cell level, production line level, automation plant level, backend plant level, enterprise level. For each of these networks the network functionalities come out from the collective cooperation of a set of devices, not from a single one (apart for very simple network). This is even more true as we move from the cell level to the plant (or enterprise) one. For these components (and the related networks) what is normally relevant are the collective behavior and the collective available resources. From an IoT@Work point of view, therefore, the networks not only have issues similar to the ones reported in the previous point, but offer (and require) the opportunity of managing spare resources (e.g.: bandwidth, paths, etc.) or even spare components (e.g.: redundant connections, redundant devices);

•

production islands: including in this category production cells and production lines. Even if each production island availability heavily depends on the components reported in the previous points, its actual availability and use does not only depend from factors IoT@Work can manage or cover (e.g.: product customization, production organization, etc.). Indeed, production islands are normally under the control of area controllers and/or MES. From an IoT@Work point of view, therefore, the focus in on assuring operativeness of the components within the production island and of its reachability and accessibility within the plant and within the enterprise.

As it is clear from the facet descriptions above, some of them apply to all components’ categories, while others apply specifically to the network components.

4.3

Requirements Coverage

In the following we provide a summary of the primary requirements identified within each of the three scenarios in this phase of the IoT@Work iterative process. The rationales of the identified requirements are provided in each of the scenario’s appendix. In the following the requirements highlighted in each of the three scenarios have been slightly restructured and a Relevance indication has been specified. All requirements, as reported in the appendixes, have high importance (a logical conclusion for the 1st iteration of the requirements analysis); the Relevance indication tries to give a priority among them.

Category: Report

Status: Final


16/12/2011

Pag. 63


According to this classification approach the requirements coming out from the Agile Manufacturing scenario are the following ones: Req. Requirement ID A01 System Extensibility

A02 Fast re-initialization A03 Controlled inizialization

A04 On demand Path reconfiguration A05 Fast network bootstrapping A06 Device migration support A07 Reduced manual configuration A08 Automatic Decision Making

A09 A10

A11 A12

Comment

Relevance

Allow system extensions, changes at run-time, if the production sub-system is not affected (e.g., changes at sub-system which are not involved in production, the changes could be in form of devices, network reconfiguration, or software element change/extension) Support fast re-initialization after systems extensions or changes in off-line system state Allow controlled initialization when extending/changing the system (e.g. limited network access, limited access rights until authentication of device/software element) Support reconfiguration of network paths in the case path failure, through redundancy protocol (but more on-demand) Fast network bootstrapping

Highest

Highest High

Highest

Highest

Fast device configuration changes for migration High

Less manual configuration effort due to any type of changes Automatic decision making to deal with failures (e.g. is there sufficient redundancy to deal with the type of failure, or resort to system stop/safe mode?) Graphical Network Graphical network configuration system (e.g. Configurator drag & drop device configuration) Grapfical Network Graphical network maintenance system (e.g. Maintenance Tool highlight and localize network failure: port, wire, etc.) Semantic Naming and Fast and reliable semantic addressing (avoid Addressing static IP) Remote Maintenance Remote maintenance: Root-Cause component discovery (read only access)

Highest Highest

High High

Highest Highest

Table 4.1 – Agile Manufacturing requirements summary

Category: Report

Status: Final


16/12/2011

Pag. 64


The requirements coming out from the Large Scale Manufacturing scenario are the following ones: Req. Requirement ID B01 High availability

Comment

Relevance

Includes redundancy and well-structured, independent sub networks but also aspects such as fast and easy replacement of defect equipment.

Highest

B02 Self-sufficient operation of sub systems

Highest

B03

High

B04

B05 B06

B07

B08

For the installation, configuration and testing, the respective parts of the automation network should be capable of running on their own without the backbone. Cloneablility As smaller or larger parts of the installation will be installed multiple times in the factory (i.e. many identical welding cells), it should be easy to copy the configuration and control SW. Extensibility It should be easily possible to add new services, new technologies, sub systems or devices. This will e.g. affect the number of IP addresses needed for the network. Security The enterprise should not be affected by a malfunctioning automation part and vice versa. Easy-to-use Taking into account that users of configuration and management tools have different skills (and could also have no specialised network knowledge), the tools have to be easy to use. Remote diagnosis For external support, a remote access to the relevant parts (plant systems or data) should be possible. Companywide access Devices and services should be reachable from anywhere in the company. This requirement mainly addresses issues considering address rooms (NAT or flat IP address space) and probably structuring of security realms.

High

Highest High

Highest

Highest

Table 4.2 – Large Scale Manufacturing requirements summary Finally the requirements coming out from the Remote Maintenance scenario are the following ones: Req. Requirement ID C01 Identification of devices C02 Detection of failures/maintenance needs C03 Secure and remote access C04 Replaceability of devices

Comment

Relevance

Before maintaining a device, it needs to be clearly identified in a distributed system

Highest

Maintenance is always based on the identification of the condition of devices

Highest

Remote access needs access of authorized people only After identifying the need for device replacements, reintegration into the distributed system should work smoothly

Highest High

Table 4.3 – Remote Maintenance requirements summary

Category: Report

Status: Final


16/12/2011

Pag. 65


The following table provides a cross-check among requirements and the IoT@Work envisaged functionalities as described above: Functionalities

Req. ID A01 A02 A03 A04 A05 A06 A07 A08 A09 A10 A11 A12 B01 B02 B03 B04 B05 B06 B07 B08 C01 C02 C03 C04

(Re)Configuration costs

X

Decoupling network and automation

X

X

X

Realization of Communication Services

X

Plug&Work

Security

Secure Plug&Work Secure Communication

X

X

X

X

X X

X X

X

X

X X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X

X X

X

X X X

X

X

X

X

X

X

X

X X

X X

X

X

X X

X

X

X X

X

X

X

X

X

X

X

X

X

X

X

Communication network resource abstraction

Self-configuring Networks Graceful network level Plug&Work IoT-based Naming and Addressing Secure Service Access

X

X

X

X

X

X

X

X

X X

X

X X

X

X

X

X

X

X

X X

X

X

X

X

Table 4.4 – Requirements vs Functionalities summary table The above table highlights the most relevant functionaries affected by each of the identified requirements and will be used as a further guideline in the forthcoming analyses and design & specification activities to be carried out in the immediate future both in WP1 as well as WP2 and WP3.

Category: Report

Status: Final


16/12/2011

4.4

Pag. 66


Conclusions and Next Steps

In the previous sections we have provided an updated view of the state of art of technologies that are used, or are under evaluation for future use, in factory and Industrial automation, as well as a description of the methodology and the process we have adopted for requirements collection and functionalities identification in this 1st iteration step. Further outcomes of this initial analysis phase are provided in D2.1-IoT addressing schemes applied to manufacturing and D3.1-Threat analysis for issue related to naming and addressing issues, and security requirements. The previous sections provide also a broad overview of relevant projects in the areas addressed by IoT@Work. The IoT@Work immediate future envisages the following steps and actions:

38

•

Extend the three scenarios to refine and deepen our requirement analyses. The outcome of the step will be a revised version of this deliverable, as well as input for the design & specification activities;

•

The refinement process envisages also the organization of a stakeholders meeting (to be held before the end of project’s first year) to collect experts’ feedbacks and cross-check requirements (the planning of the stakeholder meeting will be reported on in D5.1 and the results from the meeting in D5.2);

•

strict cooperation with currently active R&D projects in the area (and in particular with IOT-A and EBBITS), also taking the opportunity offered by the IoT European Research Cluster;

•

the organization, within the European Conference on Wireless Sensor Networks38 (EWSN 2011), of an Exploitation Activity Chain Meeting with invited experts;

•

the compilation of a mapping along functional blocks based on the 2nd round of requirements collection and analysis (see D2.1);

•

start of architecture specification activities, and related teams, focused on identification and specification of functional blocks fulfilling IoT@Work identified functionalities;

•

start of implementation works based on identified technologies and common practice, both to start the implementation of IoT@Work functional components, as well as of the framework for testing. These first implementation activities will provide further input and feedbacks to the architecture specification activities.

EWSN2011 February 23-25 2011, Bonn, Germany (http://www.nes.uni-due.de/ewsn2011)

Category: Report

Status: Final


16/12/2011

Pag. 67


5 Appendix A – External Scenarios Telegram Template 5.1

Introduction

As stated in previous sections, the analyses performed in this initial phase of the project were based on a set of specific automation scenarios that have been analysed using the template that is reported in this section. The resulting telegrams were used as input for the three scenario areas reported in the appendixes, as well as for the outcomes reported in deliverables D1.1, D2.1 and D3.1. The template is provided to highlight the areas and issues covered in each of the addressed scenarios.

5.2

IoT@Work Scenario Template Objective

Brief telegram-style description of an IoT@Work scenario. Purpose is to collect scenarios and to enable an early prioritization. From these telegram scenarios we will choose the best ones to detail and analyse them. Thus we can avoid putting much work in scenarios we later on do not use. See also the annex to get an idea which questions we might have in the next steps. Size should not exceed 1 - 2 pages plus optional drawings, keywords only are fine for the start. Don't fear your gaps: if some information is not yet available, leave it out!

5.3

Scenario Template Structure

Title: Overview: Brief description: Application domain (i.e. energy control, food, logistics, manufacturing...), structure of the installation and network topology, functions...; important requirements. optional: drawings, i.e. topology

Applications, Processes, Use Cases brief overview on "what's going on" in the scenario who are the personas/users involved? specific contexts and environment that may be important

Security Any security, dependability, availability issues that may require specific attention? What issues would cause huge costs, and would need to be protected against?

Category: Report

Status: Final


16/12/2011

Pag. 68


Meta: Author: Source: More Information available

View point:

IoT@Work topics:

5.4

Interviews, literature, own observations Do we already have everything at hand, or is it difficult to further get details? What do we have to do to get more (internal / external interviews, literature...)? Expected granularity and view point, e.g. Network view, device view, software component view? See Annex Which topics are best covered by this scenario?

Scenario telegram Example: Brewery Automation

N.B.: References to papers or other sources in this section are detailed in the “Meta” section.

Title: Brewery Automation Overview One part of the beer production process is the bottling; basic steps: washing of bottles, filling, packaging, loading into beer crates. Application domain: logistics (storage). Structured along: conveyor belts, control (perhaps based on fieldbus) of the washing machine, filling station, labelling machine and conveyors; mostly optical sensors for control, SPS (S7-xxx) controlling the process; manual off-site quality testing. Potential real-time constraints for the conveyors, but their availability is critical. No on-site automation experts. The automation network is not connected to the internet; SMS signalling for alerts and status reports are possible. Factory exists since ten years (in this form) and continues, so replacements, upgrades or retro-fits must be integrated smoothly into the live system.

Category: Report

Status: Final


16/12/2011

Pag. 69


Figure 5.1 – Basic bottling operation

Applications, Processes, Use Cases Integration into overall kanban process: on-site brewery supervisor wants live view on the factory state to ensure in-time delivery of new bottles, crates and beer as well as co-ordination with the transport of filled crates. Normal operation consists of an operation phase, a cleaning phase and an over-night stand-by phase. Before starting, a self-test ensures correct operation. Faults leading to interruptions must be signalled to external experts (with whom brewery has a service contract) as fast as possible, currently no automatic alerts and error reports are generated. Personas/users: on-site brewery supervisor, external expert. Security issues: Guided tours through the factory may enable vandalism which must also be detected by the self test. Brewery may not want to share too many insights about the process parameters to external experts.

Category: Report

Status: Final


16/12/2011

Pag. 70


Meta Author: Source: More Information available

View point: IoT@Work topics:

Category: Report

H.-P. Huth (Siemens AG), C. Kloukinas (City University) guided tour, web research, rough guesses No detailed information available, but interviews with the factory owners and Siemens internal experts should be possible. Potential contacts: • BrauKon GmbH (http://www.braukon.de/) • Ayinger Brewery (http://en.ayinger-bier.de/?pid=263) • Siemens (http://www.automation.siemens.com/MCMS/FOODBEVERAGE/INDUSTRY/Pages/Default.aspx) • MM MaschinenMarkt (http://www.maschinenmarkt.vogel.de/themenkanaele/autom atisierung/fertigungsautomatisierung_prozessautomatisierun g/articles/269335/?icmp=aut-artikel-artikel-60) Literature: Solarnavigator.Net, “Soft Drink Canning Process” (http://www.solarnavigator.net/solar_cola/soft_drink_canning_p rocess.htm) mainly network and device view availability, self-tests (both consistency checks and predictive maintenance), remote management.

Status: Final


16/12/2011

Pag. 71


6 Appendix B - Agile Manufacturing N.B.: (1) As stated scenario’s definition and analysis is a continuous activity that will periodically produce updated versions that will also take into account issues and aspects coming out from other WPs as the design and specification activities prosecute. This chapter could therefore be revised in the future! (2)

References to papers or other sources in this chapter are detailed in the §6.1.2 “List of available references” section.

6.1

Scenario meta-data

6.1.1

Suitable telegrams for agile manufacturing

The goal of this table is to identify scenarios that fit in the application area “agile manufacturing”. No. 2 3

Name Agile Factory for Mechanical Parts Data collection for corrugated and conduits extrusion

Reason Defining agility at robot and automation unit level ERP level pre-ordering and logistics for agile manufacturing; Industry example

6

Individualization of products and services

Reasons for agility

9

Retrofitting

Reasons for agility

11

Production of Small Series of Complex Products

Industry examples Industry example (automotives supplier) Check whether there are similarities between the two scenarios; Check get system descriptions

12

Automotive Industry (Tier Supplier) – Continental

18

Automotive OEM Industry

Category: Report

Industry example (FIAT)

Status: Final


16/12/2011

6.1.2 [1]

[2]

[3]

6.1.3

Pag. 72


List of available references Reference R. D. Quinn, G. C. Causey, F. L. Merat, D. M. Sargent, N.s A. Barendt, W. S. Newman, V. B. Velasco Jr., A. Podgurski, Ju-Yeon, L. S. Sterling, Y. Kim, "Design of an Agile Manufacturing Workcell for Light Mechanical Applications", Proceedings of the 1996 IEEE International Conference on Robotics and Automation, April 1996 W. S. Newman, F. L. Merat, M. S. Branicky, V. B. Velasco Jr., N. A. Barendt, A. Podgurski, Y. Kim, Ju-Yeon Jo, R. D. Quinn, G. C. Causey, "Technologies for Robust Agile Manufacturing", 1998 IEEE International Conference on Robotics and Automation, July 1998

Comment Rapid software changeover is facilitated by the use of a real-time, object-oriented software environment, modular software, graphical simulations for off-line software development, and an innovative dual VMEbus controller architecture The paper discusses: 1) a modular software architecture that supports real-time feedback, process scheduling, and workcell extensions; 2) a generic robot API permitting plug-and-play of heterogeneous robot controllers/networks; 3) and agile gripper design methods enhancing speed and reliability of parts handling

Siemens, “Non-Stop Manufacturing Excellence - Automotive”, April 2008 (http://www.automation.siemens.com/mcms/ automotivemanufacturing/Documents/br_cca_en.pdf)

List of known contacts

The following table lists contacts for agile manufacturing. Please provide detailed information. This section could be revised in the future! Name

6.1.4

Contact Details

Comment

Urgent Questions that Need Follow-up (and Answers)

This table lists questions that arise from discussion. This section could be revised in the future! Question

6.2

Answer

Definition of Agile Manufacturing

D3.1 defines Agile Manufacturing as “manufacturing may need to be agile both for internal reasons, e.g., faults, and external reasons, e.g., change in the type of products that should be produced or in the production volume. Agility can therefore be required at many different levels – from the network level (adapting network resources for network faults or increased load), to the process level (adapting processes to new requirements)”.

Category: Report

Status: Final


16/12/2011

Pag. 73


Up to now three different examples for agile manufacturing have been identified for further considerations: • The “Lemgoer Modellfabrik” (referred to as LMF in the following) of inIT is a hybrid adaptive manufacturing system which allows to adding and removing a certain. This case has an impact primarily on the middleware (distributed OPC / web services process control), secondarily on the process application itself (PLC code switching from one configuration to another, and thirdly perhaps on the network resources (if a specific module is plugged in, then this may require another network setup?). • Moving a system from one location in the overall network to another location. This will have primarily an impact at the network layer and secondarily should be kept abstract for the process and application on top of it. • Another example below is a module that remains plugged into the system, but the module is plugged out of one network and plugged into another network (e.g. goes from fixed to wireless). The impact is similar to the example above. Based on our internal experience and the widely accepted terminology in the literature the following terms have been defined: 1. Manufacturing System: is composed of several sub-systems that run either independently (i.e., on separate resources or devices), or sharing the same resources or devices (or a subset of them). The manufacturing system often includes a production process sub-system, a monitoring sub-system, and a safety sub-system, etc. 2. Sub-system: is a software and hardware combination supporting a complex task like: - Production Process: for this a sub-system could be constructed in a modular expandable form or highly integrated, but still hierarchical production line. This sub-system has often high demands for reliable communication, robustness, response to failure, redundancy. - Safety: the task of keeping a safe manufacturing environment is run on a parallel hardware or physically separate network to fulfill the higher availability demands than the production sub-system. - Monitoring sub-system: there are different ways to run such a subsystem. The current state of the art relies on accessing data gathered at the production process, and processed for monitoring purposes. The agility addressed by IoT@Work could be structured as follows: • Production process sub-system is running as distributed process. The production sub-system remains the same; some parts of the other subsystems change. o Run-time changes: these changes can be applied to the system for some special purposes like: (1) setup a temporary connection to the whole system to remotely access some log-data, (2) setting up a new monitoring process for diagnosis purposes by adding hardware (e.g. vibration sensors are modified, extended, or simply adding a video camera in run-time); (3) replacing monitoring devices/sensors in runtime if the production process is not affected. o Off-line changes: System interventions such as device replacement, or hardware modification/changes that require stopping the production task (e.g., adding a sensor inside the motor of a robot arm), but do not affect the production sub-system itself.

Category: Report

Status: Final


16/12/2011

•

•

6.3

Pag. 74


Overall system setup remains the same; some application running in one of the sub-system changes (e.g. the application running on top of the production sub-system changes). o If the process application changes, verify the mapping between variables and connections? Are there new connections? New communication profiles (changing the delay end2end between device pairs?) o What type of application that has changed? Monitoring process? PLC application? Production Process Control Details? Parts of the manufacturing system remains the same including the running application; but either the whole system or a sub-system moves or are turned into a safe-mode or energy hibernation mode. o System hierarchy is important: are we moving a sub-system or part of the sub-system, e.g. the inIT moveable module is part of the production sub-system. A wireless PLC is part of production subsystem but can be accessed by another production process. A monitoring portable device is part of a monitoring process and can attach to different production sub-systems or parts of the sub-system. o What are the effects of sub-system changes on components, modules, and networks (complexity, aggregation, or grouping of subsystem configurations)? For instance, the inIT module has its own PLC and its own energy cable. It is just attached wirelessly to the remaining setup, could we use the central PLC only? Turn energy supply off if the module is not attached? What happens when we turn the module on again? o The whole system could be moved physically to another location and turned on again – Reboot of the system should be faster than the first boot. o If parts of the system are turned off or put into standby, either for energy-saving, or due to manufacturing stop, or safe-mode, need to restart fast and in a reliable way.

Needs and advantages of agility

Other examples of where agility and flexibility can be helpful are mentioned in the “non-stop Manufacturing” innovation slides ([3]). • Produce more flexibly: For automobile manufacturers, not only profitable, but also flexible production counts, i.e. on demand, different models are produced on one line. Increased competition in the international automobile markets has clearly increased the dynamics in manufacturers’ portfolios over recent years. Production has to adjust faster and faster to new models and a large number of individual feature variants. The consequence: complexity is growing in production and logistics. There is also a wish for greater model diversity within one and the same production line, i.e. for being flexible. Just-in-Sequence is a further key issue of modern automotive production. To optimally fulfill individual customer wishes, the right component has to be ready for installation on the respective body at the right time and in the right place. This logistical challenge can only be mastered with an appropriately dimensioned Manufacturing Execution System (MES). If you procure materials, assemblies or whole assembly units from external suppliers, you need a cross-location solution. And precise identification of each individual component is crucial.

Category: Report

Status: Final


16/12/2011

Pag. 75


Figure 6.1 – Non-Stop Manufacturing Excellence (source [3]) •

•

•

6.4

Reduce complexity: With real-time information, there are RFID solutions which help to reliably locate every single component within a production, providing the user with the appropriate documentation for tracking and tracing and enhanced efficiency production control. To make sure that the right component is in the right place at the right time. Wireless networking, easy and reliable industrial Wireless Communication might offer considerable potential for boosting flexibility in production and for cutting both complexity and costs at the same time. Wireless communication makes it possible to interface automation cells despite complex space conditions. An example of flexibility is the integration of Safety Integrated technology in PROFINET via industrial WLAN. Very fast changes and addons are possible and life cycle costs are reduced. Engineer digitally for acting more flexibly: The digital factory also supports flexible and time-saving production. Thanks to digital plant engineering, new or changing production processes can be simulated and implemented more easily and faster. Recurring partial steps can be standardized, stored digitally and, in the future, integrated quickly and easily in new system structures. Thanks to virtual commissioning in combination with a system which enables data to be transferred from the digital factory, future production changes can take place much faster.

Where and how to implement the agility

Process planning and resource management level, modularity at machine and mechanical level, smart product flows in a multi-level agile system, network agility needs and requirements. Agility is the ability of a system to change/adapt quickly. As such, it includes flexibility (also referred to as maintainability), i.e., the ability of a system to change/adapt easily.

6.4.1 • • • •

What can change? Implementations of components. Interfaces of components. Architecture (usually changes in the number of components rather a change in the general structure/protocols), e.g., for scalability, fault-tolerance. Processes/tasks.

Category: Report

Status: Final


16/12/2011

6.4.2 • • • 6.4.3 • • • • 6.4.4 • • • 6.4.5 • • • •

6.4.6 •

• •

Pag. 76


Why does it need to change? Maintenance reasons (predictive or corrective). Optimisation. Changes in requirements.

When does it need to change? When a fault is identified. When the system is in a state where a fault is highly probable and/or the system has already had almost as many faults as it can tolerate. When the system does not operate as efficiently as desired. When new interfaces are developed. What needs to be preserved? Safety. Very difficult – safety of the adapted system is difficult to verify quickly. Compatibility of components. Security. How does a system adapt? It needs to have a way to observe the possible reasons for adaptation (faults, efficiency, and introduction of new implementations/interfaces/processes). It needs to have a model/representation/context of the current system. It needs to have a model/representation of the effects of the changes, both to enact the changes themselves and to update the system model/context. It needs to have the mechanisms for enacting the changes. These are effectively proxies (disentangling the implementations from the interfaces, separating a contact point from the point of service, e.g., a component that routes service calls to different servers so that the system can scale) and negotiation protocols, e.g., to agree to the version of an interface that should be used. This is the case irrespectively of whether one uses a client-server architecture or a tuple-space/event-based one. In an event-based system, the event structure is the equivalent to an interface. A server proxy is essentially implementing an event-channel. What are the security risks? The observation can be compromised. o Faulty/false observations can be injected. o The observation mechanism may be disabled, e.g., by a DoS attack. o So we need to answer: Is an observed event genuine? If so, is it correct? The changed entity (interface, component implementation, process) may be introduced by a non-authorised agent. The changed entity may be faulty/incompatible/malicious.

Category: Report

Status: Final


16/12/2011

•

• • 6.4.7 •

•

•

Pag. 77


The current system model may be out of sync, thus leading to wrong changes – usually achieved by injecting false faults (observed events in general) to cause the system to adapt even though that is not in its users’ benefit. The adaptation process may be compromised – e.g., to ensure that changes do not happen or that they happen in a manner different to what is required. The verifier (of safety/security/compatibility/etc.) is compromised. Relevant domains & literature Agile systems. o Agile SYSTEMS ENGINEERING versus AGILE SYSTEMS engineering o Fundamental Principles for Agile Systems Engineering Autonomic systems. o Self-Managed Systems: an Architectural Challenge o Foundations of Autonomic Computing Development o Middleware: Middleware Challenges and Approaches for Wireless Sensor Networks o Software Engineering for Self-Adaptive Systems: A Research Roadmap o A Survey of Autonomic Communications o On Death, Taxes, and the Convergence of Peer-to-Peer and Grid Computing o A Survey of Autonomic Computing Systems o Feedback Control Applied to Survivability: A Host-Based Autonomic Defence System o A survey of manufacturing flexibility: Implications for e-business flexibility o Defining Autonomic Computing: A Software Engineering Perspective o Research Challenges of Autonomic Computing o Autonomic Computing o Autonomic Computing: Emerging Trends and Open Problems o Security in an autonomic computing environment o Self-healing systems – survey and synthesis o Trust Modelling for Peer-to-Peer based Computing Systems o A survey of Autonomic Computing – Degrees, Models, and Applications o The dawning of the autonomic computing era o A Survey of Context Adaptation in Autonomic Computing o Space related: Autonomous and Autonomic Systems: A Paradigm for Future Space Exploration Missions Self-* Properties in NASA Missions “Next-generation” automation systems. o Service-Oriented Paradigms in Industrial Automation o Distributed real-time embedded systems: Recent advances, future trends and their impact on manufacturing plant control o A component-based control system for agile manufacturing o Intelligent Component-based Automation of Baggage Handling Systems with IEC 61499 o Next-generation manufacturing systems: key research issues in developing and integrating reconfigurable and intelligent machines

Category: Report

Status: Final


16/12/2011

Pag. 78


Requirements and solutions to software encapsulation and engineering in next generation manufacturing systems: OOONEIDA approach o Next generation of industrial automation: Concepts and architecture of a component-based control system o Use of Web Services for next-generation automation systems o Web Services-Based Control Devices for Future Generation Distributed Automation Systems o Next Generation Industrial Automation – Needs and Opportunities Context-aware systems (lots of publications – just listing a very recent one that seemed interesting since it also deals with faults). o Context-Aware Adaptive Applications: Fault Patterns and Their Automated Identification o

•

6.5

CRF Automotive Plant Issues

Devices connection within an automotive plant requires a significant amount of human resources efforts and is often the heart of plant and equipment network. In such environment there are many connections that sometimes, due to a close contact badly oxidized or bad, produce some malfunctions that are difficult to exactly diagnose, producing breakdown on the production line with consequently maintenance cost. The cost of network problems are often much greater than it may seem at first, especially if the equipment is exposed to harsh factory conditions such as in the automotive sector and in most installations. In addition, the current manufacturing plant network solutions are rigid ones, and as the number of new devices within the plant increases, their configuration and maintenance cost is increasing substantially. This despite the fact that there exist network protocols and solutions that are sufficiently "smart" and allow us to drastically reduce the total amount of hours needed to configure and manage the plant network and the devices, without reducing the overall functionality. However, it is not currently possible to both provide a very high availability of network connections and at the same time reduce the configuration time required to expand the system when adding new devices, without adding more cost in the set-up and maintenance phase. Therefore some new smart network “mechanisms” of dynamic connection of such devices are needed. Even if such solution can be realized economically with a proprietary protocol, dealing with complex systems, like the automotive plant, there are specific needs to create open systems or use one of the industry standards. Currently the OEMs are away from the governance of one standard over others, because each has its strengths and weaknesses that make it preferable to the others in certain areas, notably the use in automotive of CAN. Profibus usage has spread in industrial automation that involves the exchange of information across the distributed I/O, Interbus-S is more oriented for distributed systems of medium complexity, while ASI provides a low-level interface for I/O programmable. In the development of a new solution the choice of such appropriate standard should be also linked to the automotive environment in which they should work.

6.6

The Lemgo Model Factory as an example for agile manufacturing

The Lemgo Model Factory (LMF) is a hybrid manufacturing process, i.e. with process and factory automation elements, in a small scale. It is used at the inIT - Institut Industrial IT - to test new automation technologies in a real industrial manufacturing Category: Report

Status: Final


16/12/2011

Pag. 79


process. In its first configuration the complete LMF was comprised of five individual production cells. Each of which providing a certain functionality for processing corn which serves as an illustrative example. 6.6.1

Introduction to the LMF

The first module is used for delivery of raw material and as a storage cell for bulk goods. Using a compressed air transport system, the corn can be moved to the subsequent modules.

Figure 6.2 – Former setup of the LMF From the first cell, the raw material is transported into another storage container, where a conveyor belt is used to transport the corn further. These components form the second production cell. The third cell includes a proportioning device based on a scale that can portion the amount of corn very precisely by using a feeding screw. Afterwards the corn is fed into a pipe that again transports the corn by means of compressed air. In the following cell, the raw material is processed. This means in the LMF case, hot air is used to heat up the corn until it becomes popcorn. In the last production cell, the product (popcorn) is filled either into a large storage container or into cups. The complete process of the former LMF can be seen in Figure 6.2. 6.6.2

LMF extension

Recently, the LMF was extended to show additional applications. Therefore, some components were replaced and new components were added. The first three modules remained untouched in the sense of order and functionality. Between the third and fourth module three new modules were inserted. The first two following cells fill the raw material into small bottles and transport them by means of a conveyor belt to a pick and place robot. This empties the bottles and fills the corn into a tube that transports the corn by compressed air into the hot air processing cell. From this stage, the material process is the same as in the classical device. An overview of the production area after rearrangement is provided in Figure 6.3. On the left part of the picture, the production facility can be recognized, whereas on the right hand side, the control room for the plant is located.

Category: Report

Status: Final


16/12/2011

Pag. 80


Figure 6.3 – LMF extended with additional modules and a control room This rearrangement is a classical application of a transformation process in a plant. Before the transformation process was applied, the LMF was able to produce popcorn and fill them into a large tank or into cups. In the second stage, the LMF is able to produce the same product. In addition it can provide customers with raw material in bottles. Since the LMF was not planned to be modified in the way it was done, several problems rose up during modification. Those problems will be described and investigated in the following sections. Moreover, this description will be used to describe solutions to overcome different aspects and problems during rearranging production facilities. 6.6.3

The Transformation Process of the LMF

The description of the rearrangement process will be done in two different parts since both are handled by different engineering disciplines. The first part will describe the mechanical aspects of transformation. In the second part, all necessary steps regarding automation aspects, i.e. control software and communication structure, are described. 6.6.4

Hardware Aspects of Transformation

An obvious part of providing the ability to rearrange modules is based on the mechanical structure. Hence, the production facility must be separable into individual mechanical blocks. This requirement has to be handled mainly by the mechanical planning department. Individual functions must be identified that can be grouped under the condition, to have as less as possible mechanical interconnections between two cells. This is mandatory to support flexibility and the ability to reuse a production cell. First of all, it requires an identification of separable production tasks. Secondly, a structuring of the production into different cells fulfilling these tasks is necessary. In addition, reusability of individual cells is an important aspect while structuring the facility. Figure 6.4 shows the mechanical structure with its interconnections of the initial version of the LMF. Each module is connected to its consecutive module by a mechanical connection which is used to transport the raw material.

Category: Report

Status: Final


16/12/2011

Pag. 81


Figure 6.4 – Mechanical setup of the LMF The LMF uses corn as an example for this raw material. Compressed air is used to transport the corn from one to the next cell. The last connection is done by using a slide to transport the popcorn either into a cup or a tank. In addition to material supply, each module requires compressed air supply. The connection is plug-able by using a compressed air coupling. The compressed air is produced by an air-compressor and distributed using a switch. The control of all functions of the LMF is done by a centralized PLC. The PLC is connected to IO modules, where each IO module is used for one production cell in the LMF. Since the IO modules are located outside the production cells, IO signals were transported to the modules by a simple wiring. As already mentioned, this classical structure was enhanced which resulted in the new LMF (cf. Figure 6.3). Therefore, three new modules were introduced between the old module three and four. Due to the modular mechanical structure, those modules were not modified in their mechanical components or internal structure to fulfil the modified production task. 6.6.5

Automation Aspects of Transformation

The second part of the transformation process covers the automation aspects of the plant. A complete production facility is typically realized in hierarchical structure. Every manufacturing cell is controlled by one main PLC which executes control software. The overall production process is controlled by a manufacturing execution system (MES). The connection between PLCs and IO devices in the manufacturing cell is realized with an industrial communication network, commonly referred to as Category: Report

Status: Final


16/12/2011

Pag. 82


fieldbus, which provides deterministic communication with real-time guarantees. During the rearrangement process, the bus structure will change, since new components are attached, whilst others are removed. Further, the modification of the LMF with a new hardware structure requires two steps of engineering. These are (i) a new import of the modified fieldbus topology including the assignment of variable names, and (ii) a modification of the PLC program to provide new sub-functionalities regarding the process to be controlled. This is caused by the fact that the software executed is always specialized to a particular production facility and its corresponding physical process. The software is implemented by an automation engineer or a technician, using hardware vendor specific tools. Typically these programming tools are based on the standard IEC 61131. This standard describes the programming methodologies of PLCs and the widely accepted usual workflow. For example, the available programming languages are defined in IEC 61131 part 3. Applying this standard helps to avoid very specialized programming languages and programming workflows that are different between PLC vendors. The typical workflow of automation software development is shown in the following list. • Read bus configuration • Assign IO ports to variable names • Modify the current PLC program/project • Compile the modified PLC program/project • Download PLC program/project to PLC In the first step of programming the control software of a plant, all available devices must be included in the programming tool. This is necessary to get detailed knowledge about the attached devices and to make the inputs and outputs of the all IO devices controlled by this PLC available in the programming tool. The device structure can either be automatically read by the engineering station or can be assembled manually by the programmer using graphical tools. In Figure 6.5 the IEC 61131 programming tool PC WorX of Phoenix Contact is shown as an example. The area highlighted in red shows the bus configuration.

Figure 6.5 – Configuring the Bus Topology using PC WorX

Category: Report

Status: Final


16/12/2011

Pag. 83


For a manually configured bus structure, the programmer can add devices to the bus structure which is shown on the left side of the programming tool. The available devices are shown on the right side in Figure 6.5. This structure contains all devices involved in the project opened in PC WorX. It includes at least one PLC, called Resource in accordance to IEC 61131. Involved components, like digital-input and -output devices are also listed. In a PROFINET environment, the description of those devices is provided by the device vendors in the form of a GSD-file. This file describes the device with its digital IO connections and other important parameters. These files can be imported to the library of the programming tool to make new devices available. During restructuring of the LMF, new PLCs were included, resulting in a new hardware structure. The new structure of the LMF is shown in Figure 6.6. It involves one main PLC and two additional local PLCs for control tasks inside a specific module, whereas in the first version of the LMF only one PLC was used.

Figure 6.6 – Current architecture of the LMF If all devices connected to the bus are available in the bus structure of the programming tool, variable names have to be assigned to the ports of each device. This is necessary to make data available in the PLC programs. The red marked area in Figure 6.7 shows the dialog for assigning variable names to IO ports. Since each available device provides only a general naming of its IO ports, a meaningful name will be used to make programming easier and also easier to understand for later changes or maintenance. In addition to the variable names, also a description regarding the function of the variable can be provided. This step of engineering can take a long time, depending on the number of involved devices on one hand and on the other hand also the documentation of the plant structure. A detailed documentation will help to associate devices with its functionality in the plant and avoid additional effort for figuring out the responsibility of a device.

Category: Report

Status: Final


16/12/2011

Pag. 84


Figure 6.7 – Assigning Variable Names to IO ports The next step of setting up the plant is to develop the software responsible for controlling the plant. For the LMF, code was already available which was used in the first version of the LMF. The reuse of this code became difficult, since it was developed using Step7 which is an engineering tool from Siemens. Due to incompatibility, PLC programs were not exchangeable between PC WorX and Step7. Therefore, the control software of the LMF had to be re-implemented using PC WorX. Therefore the language Structured Text (ST), defined in IEC 61131-3, was used. Additionally, the software was structured following the hardware structure of the plant. For each production cell, one software component was developed for fulfilling its functionality within the overall production process. Finally, a process control system within a control room should be attached to the LMF which was not available in the first version of the plant. Using this control system, the whole plant can be monitored and controlled from a central control room. The complete rearrangement process of the LMF from the first to the current, more complex version took approximately three months. However, the mechanical rearrangement of the production cells and adding new cells was done in a few days. The most effort had to be put into the software modification of the plant. Since all functionality had to be re-implemented for Phoenix Contact PLCs, programs had to be written for the new modules and finally an additional manufacturing execution system had to be integrated into the plant. This implementation process took approximately three person months. This evidently showed that most of the efforts, also in this laboratory sized plant, had to be invested for programming the control systems. Since such a modification is very cost intensive, i.e. many engineers and technicians are needed and the plant cannot produce anything during the downtime, it is highly desired to reduce this downtime significantly. 6.6.6

Flexibility in the LMF

During the development of the enhanced version of the LMF, the option of transformability was integrated. The last two production cells which are responsible for popcorn production and filling of the product are attached in a flexible way. This means, either both cells are connected or both cells are disconnected to the plant. If Category: Report

Status: Final


16/12/2011

Pag. 85


both cells are connected, the previous cell can empty the bottles that contain the corn. This raw material is than hand over to both production modules. In case of disconnected production cells, the full bottles arriving at the robot cell will be sent to a storage area until they are processed. The mechanical connection was enhanced by using a connector which includes the Profinet bus wiring and compressed air in a single connector. The modules and its connection to another module are shown in Figure 6.8.

Figure 6.8 – Structure and Connection of the flexible production cell Beside the mechanical connection, the software aspect is more complex. As typical for the flexible manufacturing paradigm, different states of the plant have to be considered during development. In the LMF, states including and excluding both manufacturing cells are planned. Therefore, the PLC that controls the LMF is able to distinguish between both states by detecting an IO signal that is set if the plug for the fieldbus of both flexible modules is connected. In this case the control software recognizes the changed plant structure and adjusts the program flow to a new flow. Based on this concept, a flexible production can be achieved. The LMF shows this production paradigm by being able to produce corn filled in bottles in case of unconnected production modules. In a second state, the plant is able to process the corn further to receive popcorn out of the corn, transported in the bottles. 6.6.7

Analysis of the Lemgoer Modellfabrik agility

The modules of the Lemgoer Modellfabrik have been analysed with respect to their agility. The current results of this analysis are presented below. However, some of the items of interest are not yet clarified and have to be further investigated as this project is progressing.

Category: Report

Status: Final


16/12/2011

Pag. 86


•

inIT stakeholder view: o agility through modular process, o Modules are moveable and can be added to an existing setup depending on production needs

•

Technological view point: o Module is connected through wireless network to main PLC o Module has its own PLC, which makes it independent of the rest of the setup o Agility is currently faked? What does this mean? – e.g. How much Plug&Play is pre-configured; restricted through PLC/SPS programming, variables and code words are pre-engineered and preconfigured with the exact setup of the mobile module. Currently it works as follows. Once the new module is added and establishes its connections, the PLC program can call the process of the mobile module and trigger it to start working. This is achieved by introducing a library of function blocks for the expected component classes. A function block should encompass communication interfaces, services, data structures (object models), and could be dynamically instantiated. A lower end new component has to register to its virtual function block instance, in order to subscribe to certain services and publish its own. All existing components need to know the changes in the system in order to correspondingly use available services and to ignore unavailable services. Initially, the manufacturing process of the modular “Lemgoer Modellfabrik” achieves this by extending PCWorX (the utilized engineering software) by a function block (AR). This function block encompasses the Profinet configuration of a single unit. Currently, a specialized firmware at the IO controller is required, that enables the PLC to sense continuously if the function block is in an active or inactive state. In case of a dynamic configuration change, this function block will be either enabled or disabled for the running project. o Other data-centered applications like events or process monitoring have to keep track of the availability of the mobile module o How to trigger the monitoring application running in the local PLC? o How to initiate the connections between the local monitoring application and the central PLC?

•

Network view point: o Wireless connection has to deliver the same reliability or wired Profinet o Real-time communication can be supported o Auto-configuration supported at network level, involving mapping variables of the PLC program to TCP connections. Currently the modules are hierarchical building blocks, whose complexity (variables, connections, controller/actuator/sensor interactions) is hidden from the main PLC. The number of variables that are manipulated by the central PLC is limited. o Can mobility lead to IP domain change? For instance moving to another NAT subdomain?

•

Research view point: o What is restricting full agility technologically? PLC programming? Can this be solved by a more service oriented-architecture? Can we encapsulate a PLC software in a web service?

Category: Report

Status: Final


16/12/2011

Pag. 87

6.7


Can we enable invoking PLC services in a more service oriented? (i.e., less detailed knowledge of the function blocks and variables of both sensors/actuators/controllers) Network services are pre-configured using engineering tools that results into configuration files that need to be made available to the mobile module in advance? Could this be replaced by an on-the-fly negotiation with network manager that provides the communication services requested by higher layers?

Requirements for Transparent Agility

IoT@Work Agile Manufacturing targeted requirements: Req. ID A01

A02 A03

A04 A05 A06 A07 A08

Title Allow system extensions, changes at run-time, if the production sub-system is not affected (e.g., changes at sub-system which are not involved in production, the changes could be in form of devices, network reconfiguration, or software element change/extension). Support fast re-initialization after systems extensions or changes in off-line system state Allow controlled initialization when extending/changing the system (e.g. limited network access, limited access rights until authentication of device/software element) Support reconfiguration of network paths in the case path failure, through redundancy protocol (but more on-demand) Fast network bootstrapping Fast device configuration changes for migration Less manual configuration effort due to any type of changes Automatic decision making to deal with failures (e.g. is there sufficient redundancy to deal with the type of failure, or resort to system stop/safe mode?)

Importance High

High High

High High High High High

Additional, and complementary, requirements coming from the automotive scenario described above (see §6.5) are the followings: Req. ID A09 A10 A11 A12

6.8 •

Title Graphical network configuration system (e.g. drag & drop device configuration) Graphical network maintenance system (e.g. highlight and localize network failure: port, wire, etc.) Fast and reliable semantic addressing (avoid static IP) Remote maintenance: Root-Cause component discovery (read only access)

Importance High High High High

Security What are the important “assets” in the system? (Especially consider instances of the system that have a need for one of the following: o confidentiality, o integrity, o availability, o authenticity o authorization,

Category: Report

Status: Final


16/12/2011

Pag. 88

o o o


accountability, dependability, regulatory requirements, …)

•

What are the entry points to the system (and to these assets)? Which parts of the system are exposed to the public (i.e. WLAN, SMS, VPN across public networks, etc.)? Where there are specific required interactions across trust boundaries (i.e. simply blocking access is not sufficient, there is a need for allowing yet constraining access)?

•

Which security problems did occur so far in current system and how often (i.e. but not limited to virus/worm attacks, hacking, unauthorized management operations, etc.)?

Category: Report

Status: Final


16/12/2011

No. 2

Name Agile Factory for Mechanical Parts

3

Data collection for corrugated and conduits extrusion Individualization of products and services

6

9

Retrofitting

11

Production of Small Series of Complex Products

Pag. 89


Reason Reconfiguration: Reconfiguration really means ‘selecting an existing configuration’; there is also the idea of ‘macro programming’ (reconfiguration is putting existing functional blocks together in a different way) of robot. Observation: identified threat is possibility for malfunction; a real security threat would be the possibility for an attacker to configure the robot in such a way that parts are assembled with ‘hidden faults’ which would case quality or safety issues later; there is a need to ensure that the integrity of the routine is preserved from the simulated environment to the robot. Question: isn’t ‘possible raw materials stock-out’ a threat to prevent? “Guarantee hardware [and associated software?] reconfiguration” Hardware and software reconfiguration should be addressed in this scenario (manufacturing industries where high flexibility is needed) A rearrangement of hardware components in a highly modular manufacturing process has to be supported by software services (e. g. automated recognition of hardware partners) Observation: use case "Individual treatment of patients" may involve protection of data privacy? assure deployment of new components and software precisely in the way as simulated and virtually tested Question: integration of suppliers and partner technologies and processes => how much of that is between back-ends, and what specific use cases go into the device infrastructure? Specific example from PLM perspective: Supplier and third-party manufacturer management also requires sharing of Production and Delivery Plans as well as technical data (design, specifications, and process settings) that implies strong security requirements. Plans are generated at a central level but provided to suppliers that can use them at different level of integration by simply getting data to more interactive processes involving the IT systems Also on remote maintenance: Some production environments are opening their internal IT infrastructure to external subjects (service partners) for activities like periodic maintenance. A correct and proper management external subjects access to internal IT systems, services and devices has to be based on the use of federated Id&Auth management in order to reduce the burden of account administration and potentially security holes (e.g. a technician leaving his job in a supplier company, without a proper communication to disable his access to the production IT systems)

6.9

IoT@Work Support for agility

This section will be completed in future revisions!

Category: Report

Status: Final


16/12/2011

Pag. 90


7 Appendix C – Large Scale Manufacturing N.B.: (1) As stated scenario’s definition and analysis is a continuous activity that will periodically produce updated versions that will also take into account issues and aspects coming out from other WPs as the design and specification activities prosecute. This chapter could therefore be revised in the future! (2)


7.1

Scenario meta-data

7.1.1

Suitable telegrams for Large Scale Manufacturing

The following table identifies main scenarios that fit in the application area “large scale manufacturing”. No. 1

8

12

18

7.1.2 [1] [2] [3] [4] [5]

Name Automotive Automation Vertical Integration Plug & work in a digital factory spanning businesses Automotive Industry (Tier Supplier) – Continental Automotive OEM Industry

Reason interconnection of many physically distributed manufacturing sites for the automotive industry

Integration and collaboration of distributed production sites (OEM + suppliers). Businesses and responsibilities comprise the whole product life cycle. Domain: automotive (as an example) A tightly integrated automation system, capable of communicating with design and testing engineering is desirable

Tight coupling of logistics, MES and production of suppliers and automotive factory. Are parts of a car pre-produced in different sites by the manufacturer? I.e. motor produced in site A, car assembled in site B?

List of available references "Industrial Ethernet im Unternehmensnetz", German press article from 2008; refers to a study by Daimler Benz (http://www.pdv.reutlingenuniversity.de/rte/schwager2009.pdf) "Folgen der Offenheit - Warum die Daimler AG allein für Industrial Ethernet 1,72 Mio. IP-Adressen bräuchte" (http://www.spsmagazin.de/?inc=artikel/article_show&nr=51158) German BMWI funded project Laendmarks (http://www.laendmarks.com/index.php?id=154&L=1) “Profinet and IT”, White Paper, december 2008, PROFIBUS Nutzerorganisation e.V Huth, Zirkler, Klagge, “Survey on Real-World Industrial Networks”, March 2009, Background study from the German BMWI funded project HOMEPLANE.

Category: Report

Status: Final


16/12/2011

7.2

Pag. 91


Definition of Large Scale Manufacturing

We use the term "Large Scale Manufacturing" for scenarios where the automation network is structured into multiple physically (and in many cases also administrative) separated networks operated and owned by one holder. Typically, this will be a large manufacturer having many sites across the world which are interconnected via highlevel logistic and ERP processes. As such, the large scale manufacturing consists out of a set of automation network "islands" and an enterprise backbone network. Common characteristics of one of those automation islands are: • one administrative domain, • in many cases this is one Ethernet domain without internal IP routing, • security-wise shielded from the outer world (only controlled access by means of firewalls), • mostly homogenous regarding standards (i.e. only one Industrial IP standard within one site). Additionally, but not necessarily, other parties such as subcontractors and service providers may be loosely integrated into the manufacturing IT. The following section uses an artificial story based on various real-world scenarios from literature and many internal resources from the project partners to provide a concrete large scale manufacturing scenario.

7.3

Scenarios and industry data on large scale manufacturing

7.3.1

Overview

The big European car manufacturer (here called EUROCAR) has a large enterprise network spread across many sites in Europe. The network is structured physically into an enterprise network (on-site and intra-site) and a factory floor network per site. Further on, it is structured into sub networks (i.e. automation cell) and logically into virtual LANs for various services such as e.g. motion control, safety, voice-over-IP or surveillance. Apart from field bus systems at the lowest machine level, Ethernet and IP are used across the system. Four big and 17 smaller manufacturing sites are mostly interconnected using leased lines (i.e. MPLS-based) or - in rare cases - using encrypted VPNs the public Internet. The various sites are more or less independent from each other on the automation level, but they share several services (resp. servers) and are tightly coupled via the ERP system. In few and exceptional cases, a closer coupling between sub systems is required, e.g. for the emergency button (safety system). One can assume that the automation parts of the network will not have significant data traffic directly to other automation sites. The traffic mainly will "go up" from the automation to some services in the enterprise part and vice versa. Not surprisingly, the major driver for using an Ethernet/IP based industrial IT is cost reductions, both CAPEX and OPEX. More specifically, high level requirements include: • high availability: includes redundancy and well-structured, independent sub networks but also aspects such as fast and easy replacement of defect equipment. • self-sufficient operation of sub systems: for the installation, configuration and testing, the respective parts of the automation network should be capable of running on their own without the backbone.

Category: Report

Status: Final


16/12/2011

•

•

• • • •

Pag. 92


cloneable: as smaller or larger parts of the installation will be installed multiple times in the factory (i.e. many identical welding cells), it should be easy to copy the configuration and control SW. extensible: it should be easily possible to add new services, new technologies, sub systems or devices. This will e.g. affect the number of IP addresses needed for the network. secure: the enterprise should not be affected by a malfunctioning automation part and vice versa. easy-to-use configuration and management tools. remote diagnosis: for external support, a remote access to the relevant parts should be possible. companywide access: devices and services should be reachable from anywhere in the company. This requirement mainly addresses issues considering address rooms (NAT or flat IP address space) and probably structuring of security realms.

This scenario proposes the following use case stories to further investigate the situation: • Remote Second Level Support: GOLEM Inc., a big robot vendor produces, and then supervises many welding robots across the world. EUROCAR installs many of their robots in various sites. To allow secure access to the remote maintenance facilities of those devices, the network (firewalls, VLANS etc.) must be prepared to grant access for the GOLEM support. This is done by the DoIT GmbH, a large network and IT administration company operating the EUROCAR network. • Merger/Acquisition: Following the recent hype of electric cars, EUROCAR decides to buy a small vendor of electric scooters. The new site uses different standards for the automation network and the MES or ERP systems. Protocol gateways should allow a fast integration. • Predictive Maintenance: the factory operates in a well defined sequence of steps - each failure results in significant impact for the next steps. A small Ethernet switch detects a rising failure rate in one of its ports and warns the network management system (NMC) in advance. A potential failure of this switch would affect a conveyor which servers some of the painting robots. In this case, the internal flow of parts would stop after a short time. This scenario is an artificial state-of-the-art scenario based on the literature and (preliminary) guesses based on experience with other similar networks. It is meant to integrate and to detail mainly scenario telegrams 1 and 18, but will use information and parts from others as well. 7.3.2

Problems in the current Solution

The Daimler Benz study ([1]) mentions especially the following problem spaces where potential optimizations could be applied: • IP address management is costly due to the need of NAT together with DHCP/DNS. In many cases a global routable address space could have been the better solution, but there are not enough IPv4 addresses available and common automation products are not IPv6 enabled. •

Availability: NAT/Firewall at the border of a factory network is a single point of failure and redundant solutions will require more effort.

•

Solutions which require external access to the private address space behind the NAT require more effort (i.e. remote maintenance or conferencing systems).

Category: Report

Status: Final


16/12/2011

Pag. 93

7.4

System descriptions

7.4.1

Network View - Physical Topology


The company network consists of 4 big and 17 smaller manufacturing sites across Europe plus many office sites. Pure office sites will not be analysed further on.

Figure 7.1 – Overall Network Structure (source [4]) A manufacturing site has a redundant Ethernet backbone and many automation sub networks for various tasks (see Figure 7.1 and Figure 7.2), we will further on call this part "automation network". Servers and services are mostly on the enterprise part of the network, further on called "enterprise network".

Category: Report

Status: Final


16/12/2011

Pag. 94


The automation network and the enterprise network are interconnected via NAT and firewall. Connection between different sites on enterprise level uses secure tunnels over the public internet and leased lines.

Figure 7.2 – Network topology of a site (source [1]) The automation network (Figure 7.2) is solely based on industrial Ethernet, mostly PROFINET. Other important protocols here include OSPF, rapid spanning tree (or variants thereof, i.e. MRP) and SNMP for the element management. The Ethernet can and does support VLANs (IEEE 802.1q) including the LLDP and VLAN management protocols such as VTP. Ethernet security (IEEE 802.1X) is not used. On the physical layer, all variants from 10Mbps to 100 Mbps are used, electrical and optical. Wireless is used at the borders and includes mainly Industrial WLAN and sensor protocols (i.e. Zigbee). For motion control, islands with PROFINET IRT and field busses are used on the field level. While these sub systems at the field level in general are independent from each other, there are several exceptions using PN-PN coupler to create short cuts which are invisible to the Ethernet or IP layer. One example of a closer coupling is a welding cell with many robots (= self sufficient sub system) working together. The backbone of the network uses redundancy by means of ring topologies and redundant components (i.e. redundant firewalls/routers) to achieve a high reliability. No isochronous real-time traffic (i.e. Profinet IRT) runs in the backbone, but standard real-time traffic (i.e. Profinet RT) is supported and used. All switches are managed39, that is, they have an IP address and an SNMP agent. There are no IP routers within the automation network, only the gateway to the enterprise part uses a firewall/NAT router. Some components have remote access for maintenance purpose by the respective vendors. In most cases (i.e. the welding robots) this will use a VLAN and a Layer-3 VPN to go through the factory floor and the firewalls. The remote management 39

In rare cases, unmanaged switches are used to increase the number of ports of a managed switch.

Category: Report

Status: Final


16/12/2011

Pag. 95


infrastructure is a Cloud Service based on Microsoft Azure and the Common Remote Service Platform from Siemens (who also operates this platform as a service for the support of the robot vendor). Unfortunately, some devices still have older GSM/GPRS based modems for remote management, creating uncontrolled access to those devices. Further references: • Siemens “Secure remote service with the common Remote Service Platform” ([SiemCRSP]) • Microsoft “Windows Azure Customer Solution Case Study - Siemens Expands Software Delivery Service, Significantly Reduces TCO” ([MsAzCSC]) 7.4.2

Network View - Logical Structure (Overlays)

As explained above, the automation network has a redundant backbone on the Ethernet level. From the point of view of end devices or services, the network therefore is a single Ethernet segment per factory floor and a routed IP network across the company. The redundancy is invisible for the end systems. The routing is also transparent due to the fact that there is one address space in the company and all services which need access to the outer world have a transparent mapping in the network address translators (NAT) at the borders of the company. Several different services share the same infrastructure. Those services create their own logical structure on top of the factory floor network using VLAN techniques and partially using their own middleware components (i.e. message forwarder, multicast services, caches and more). Examples include the safety systems (Profinet Safety), a Voice-over-IP (in some sites) but also the SNMP based network management runs in its own VLAN. Building Automation and Surveillance uses dedicated networks (do not run over the automation network). Planning and documentation of the respective VLANs was done using Excel and hand written notes; some of the responsible persons for planning the VLANs have already left the company. As they did foresee spare VLANs for future use, no one at the moment has a full and consistent view on the network. The network administrators try to overcome this by use of a SNMP based management tool. 7.4.3

Size

A large site may have between 500 and 2.500 sub systems, a smaller one will have between 50 and 500 sub systems. A small sub system has at least one switch and typically a CPU and some I/O modules, according to the Daimler Benz study ([1]), on average 200 Ethernet devices are in a subsystem. Given the fact, that those sub systems are interconnected in a tree or line topology to a - typically - optical backbone ring, one can easily estimate that there are several hundred additional switches needed. Note, even if every device has a MTBF of 40-50 years, the sometimes harsh conditions and the sheer number of devices will make failures of devices a statistically very likely case. The study references in [2] estimates the need for 1.72 Million IP addresses over the whole company. To ensure easy communication across all sites, the company uses IP addresses which are routable in the whole company. Because there are not enough public routable IP addresses available, they use the 10.x.x.x private address space. This however makes address translators and gateways for remote maintenance mandatory.

Category: Report

Status: Final


16/12/2011

Pag. 96


8 Appendix D – Remote Maintenance N.B.: (1) As stated scenario’s definition and analysis is a continuous activity that will periodically produce updated versions that will also take into account issues and aspects coming out from other WPs as the design and specification activities prosecute. This chapter could therefore be revised in the future! (2)


8.1

Scenario meta-data

8.1.1

Suitable Telegrams for Remote Maintenance

The goal of this section is to identify scenarios that fit in the application area “Remote Maintenance”. Also, this section identifies some of the reasons to use remote maintenance as well as a ranking of scenarios available at the moment of writing. Requirements of remote maintenance applications that have to be addressed by the telegrams/scenarios: No.

Requirement

1

Identification of devices Detection of failures/maintenance needs Secure and remote access Replacement of devices

2

3 4

IoT@Work issues matched Naming & addressing --

Security Plug & work

Comment

Before maintaining a device, it needs to be clearly identified in a distributed system Maintenance is always based on the identification of the condition of devices Remote access needs access of authorized people only After identifying the need for device replacements, reintegration into the distributed system should work smoothly

There are 3 main reasons where one can benefit from remote maintenance: • SC: Supply chain is physically extended, distributed (many distributed manufacturing sites) synergies for remote, centralized maintenance • CA: Costly access of experts to production sites (wind parks, etc.) • HE: Hazardous environments The following ranking shows, which scenario telegram best fits to remote maintenance. Our ranking based on these 4 aspects: • Having a reason for remote maintenance (see above) • Addressed industries are attractive for partners • Requirements addressable (see above) • Benefits of the scenario

Category: Report

Status: Final


Pag. 97


Benefits of the scenario or reasons for misfitting

Automotive Automation - Vertical Integration

Automotive Large scale manufacturing Logistics

1, 2, 3, 4

2

CA

10

Wind park control

1, 2, 3, 4

3

CA

7

Oil & gas drilling

Distributed energy generation Oil & gas

4

HE

17

Remote Maintenance

Manufacturing

1, 2, 4

5

HE

15

Mining & metals – Grupo Penoles

Mining & Metals

1, 2, 3, 4

6

SC, CA

8

Plug & work in a digital factory spanning businesses

Automotive Manufacturing

1, 2, 3, 4

7

4

Brewery automation

Process industry

8

5

Management and protection of crucial infrastructure

Water supply Energy supply

1, 2, 3, 4 1, 2, 3, 4

9

18

Automotive OEM industry

Automotive

1, 2, 4

1 0

2

Agile factory for mechanical parts

Mechanicals Manufacturing

1, 2, 4

1 1

13

Food & beverage industry – Grupo Modelo

Food & beverage

1, 2, 4

Centralized Maintenance from remote has the potential to lower costs (many distributed sites!) Need for remote control, monitoring and maintenance Need for remote control, monitoring and maintenance Maintenance in a hazardous environment needs to be done remotely Maintenance in a hazardous environment needs to be done remotely Centralized Maintenance from remote has the potential to lower costs (many distributed sites!) Messaging failures to external experts Remote maintenance of components that are distributed in extensive areas Misfit: Predictive maintenance, but no remote access necessary Misfit: Mechanical wear is pretty high predictive maintenance would lead to competitive advantages, but no remote access necessary Misfit: monitoring, but no maintenance

Category: Report

Name

1

Telegram No.

SC, CA

Reason for remote maintenance

1

Ranking

Requirements (No.) addressable

Addressed industries

16/12/2011

Status: Final

1, 2, 3, 4


Food & beverage

1, 2, 4

1 3

12

Automotive industry Continental

Electronics Manufacturing

1, 2, 4

1 4

6

Individualization of products and services

Manufacturing

1, 2, 4

1 5

11

Manufacturing

1, 2, 4

1 6

3

Production of small series of complex products Data collection for corrugated and conduits extrusion

Plastics manufacturing

2

1 7

9

Retrofitting

all

4

1 8

16

Industrial video SCADA

Process industry

-

Ranking

8.1.2 [1]

[2]

[3]

Name Food & beverage – Grupo Bimbo

Telegram No. 14

Reason for remote maintenance

1 2

Benefits of the scenario or reasons for misfitting


Requirements (No.) addressable

Pag. 98

Addressed industries

16/12/2011

addressed here Misfit: predictive maintenance, but no maintenance addressed here Misfit: predictive maintenance, but no need for remote maintenance Misfit: Predictive maintenance, but no remote access necessary Misfit: No need for remote maintenance Misfit: Data analysis for predictive maintenance, but no remote access necessary Misfit: No remote maintenance necessary Misfit: monitoring scenario, but no need for maintenance

List of available references

Title G. Anders, “Beitrag zur Verhaltensanalyse und Synchronisation von steuerungstechnischen Prozessen durch verteilte echtzeitfähige Kommunikationssysteme“, PhD Thesis, Freiberg, Technische Universität Bergakademie, December 2006 Microsoft, "Windows Azure Customer Solution Case Study - Siemens Expands Software Delivery Service, Significantly Reduces TCO", November 2009 Microsoft, „Embedded Device Management with System Center Configuration Manager 2007“, June 2010 (http://msdn.microsoft.com/enus/library/ff769910.aspx)

Category: Report

Status: Final

Comment Among others: describes the update of firmware of automation devices via web services


16/12/2011

8.1.3

Pag. 99


List of known contacts

The following table lists contacts for agile manufacturing. Please provide detailed information This section could be revised in the future! Name

8.1.4

Contact Details

Comment

Urgent Questions that Need Follow-up (and Answers)

This table lists questions that arise from discussion. This section could be revised in the future! Question Discussion necessary: Where has REMOTE maintenance real benefits compared to local maintenance?

8.2

Answer

Definition of Remote Maintenance

Under this scenario we collect all those situations in which external providers (e.g. robots/tools providers) need direct access to devices or data within the production sites to assure production continuity for example doing preventive maintenance.

8.3

Scenarios and industry data on Remote Maintenance

8.3.1

Overview

8.3.2

System descriptions

A factory automation system in an automotive factory may look like shown in Figure 8.1 and Figure 8.2. Several separate networks exist: a conventional LAN and a separate network for each production line. Production lines may communicate with each other by a PN/PN coupler.

Figure 8.1 – Example network in factory automation

Category: Report

Status: Final


16/12/2011

Pag. 100


HMIs are reachable in each production line as well as from the LAN (two separate networking cards are used). VLANs are used in the LAN to separate office traffic from traffic of the MES, remote maintenance traffic, or other shopfloor high-level activities.

Figure 8.2 – More detailed view of factory network

8.4

Processes

Remote Maintenance Setup in Automation: o remote diagnostics o OEM or Service Provider can remotely ‘login’ (or see screen) o For safety reasons, often only if ‘triggered’ by local operator o Local operator logs into HMI, VNC connection to view screen of HMI. o Remote Control of HMI??? o Data is not really stored or aggregated at service provider side (only “on the spot” diagnostics)

8.5

Responsibilities

8.6

Security

Secure and dependable remote device management Scope: OS updates, security patches, updates to PLC runtime environment, install / updates of software components other than PLC applications, hardware and software inventory, etc. Out of scope (for now): updates of PLC applications and other software components specific to manufacturing process Customers do not want to frequently update this and/or this is done via specific engineering tools Motivation: Device manufacturers clearly have a need to manage software on their devices after deployed at customer sites; Customers want to have proper device management solutions (e.g. cloud-based management of Siemens devices see [2]).

Category: Report

Status: Final


16/12/2011

Pag. 101


In current solution: o how is VNC connection secured? o How are credentials for VNC connection deployed? o Seems to be only easy because Comau has access to Fiat LAN. Systems become more open, so urgent need from a security perspective: devices need to be kept healthy just as PCs and servers (e.g. Stuxnet) A possible concrete approach could be exemplified by the Microsoft System Center technologies and its use with embedded device management software ([3]). Additional examples and information of usage of Microsoft system management products in manufacturing are available at: http://www.microsoft.com/industry/manufacturing/automotive/solutions/manufacturing _operations.mspx Technology elements: o Access control o Interaction between management infrastructures o Interaction between device management and process control/context => capture dependability and other constraints to be respected o E.g. allowed time window, trigger/approval by local operator, enforced test operation, enforced collective update to multiple devices, ... o Reuse security and dependability functionalities for continuous remote monitoring

8.7

IoT@Work Support for Remote Maintenance

Several future scenarios for Remote Maintenance exist: o Future #1: continuous monitoring o More continuous and aggregated data gathering to have info on reliability etc. o The robot vendor and integrator has clear interest in this: “Customers want more info on total cost of ownership over the lifetime of our solutions” o Future #2: device updates o I.e. updates of device-level software (new firmware, OS patches, etc.) o firmware updates only each 2-3 years (when lines are reconfigured for other models) o Future #3: application updates, remote engineering o Always require visual access (preferably by local operator)! o factory owner and integrator don’t need “Agile Manufacturing” in this sense o But: discussion implies that they actually do some software update/maintenance (HMI PC has backups of PLC software; new backups are regularly made, implying that the software is changed?) 8.7.1

Network support (middleware, resource management)

This section will be completed in future revisions! 8.7.2

Auto-configuration needs

This section will be completed in future revisions! 8.7.3

Security requirements

This section will be completed in future revisions! Category: Report

Status: Final


16/12/2011

Pag. 102


9 References [3DPrint]

R. A. Guth, "How 3-D Printing Figures To Turn Web Worlds Real", Wall Street Journal, Dec. 12, 2007

[AbieIJAS]

H. Abie, R. Savola, J. Bigham, I. Dattani, D. Rotondi, G. Da Bormida, “Self-Healing and Secure Adaptive Messaging Middleware for Business Critical Systems”, in International Journal on Advances in Security, Vol. 3, No. 1&2, 2010

[AbieCP1281] H. Abie, R. Savola, J. Wang, D. Rotondi, “Advances in Adaptive Secure Message Oriented Middleware for Distributed Business Critical Systems”, Algorithmic Aspects of Wireless Communication and Distributed System Conference (ICNAAM 2010), in: CP1281, ICNAAM, Numerical Analysis and Applied Mathematics, International Conference 2010, edited by T. E. Simos, G. Psihoyios, and Ch. Tsitouras, (c) 2010 American Institute of Physics 978-0-7354-0831-9 /10/ [AddiData]

Addi Data, “Process optimization made easy”, White Paper (http://www.addi-data.de/)

[Altera]

Altera Corp., “Roadmap of Ethernet FPGAs“ (http://www.altera.com/)

[ARM]

press announcement, ARM A-15 (http://www.arm.com/products/processors/cortex-a/cortex-a15.php)

[Armstrong]

R. Armstrong, P. Hunkar, “The OPC Security Model for Administrators”, 2010, The OPC Foundation [Online] (http://www.opcfoundation.org/)

[AWNC]

American WorkKeys National Conference, “Lack of Skilled Workers Poses Threat to Current and Future Economy”, ACT's Activity Publication Vol 47/3, Autumn 2009 (http://www.act.org/activity/autumn2009/workers.html)

[Batke]

B. Batke, P. Brooks, “IPv6: The views from industry”, Industrial Ethernet Book Issue 27 / 31, 2010 (http://www.industrialnetworking.com)

[Bent]

R. Bent, “Automation ist Zukunft”, open automation 4/10, Sept. 2010 (http://www.openautomation.de/1819-0-automation-ist-zukunft.html)

[BergerAut]

"Automation – Time to find your true north - Global view on the automation industry", think act study, Roland Berger Strategy Consultants, 2010

[Bollella]

G. Bollella, J. Gosling, “The real-time specification for Java”, IEEE Computer, vol. 33(6), pp. 47-54, June 2000 (http://dx.doi.org/10.1109/2.846318)

[Brooks]

P. Brooks, “Ethernet/IP-industrial protocol”, in Proceedings of the 8th IEEE International Conference on Emerging Technologies and Factory Automation, October 2001

Category: Report

Status: Final


16/12/2011

[Burke]

Pag. 103


T. Burke, “The Magic of OPC Unified Architecture”, 2008, The Industrial Ethernet Book [Online] (http://Ethernet.industrialnetworking.com)

[CASAGRAS] CAGRAS Project, “CASAGRAS Final Report – RFID and the Inclusive Model for the Internet of Things”, October 2009 [Contiki]

A. Dunkels, B. Grönvall, T. Voigt. "Contiki - a lightweight and flexible operating system for tiny networked sensors", in Proceedings of the First IEEE Workshop on Embedded Networked Sensors (Emnets-I), Tampa, Florida, USA, November 2004

[CORBA]

OMG, CORBA (http://www.corba.org/)

[CORBAe]

OMG. “CORBA/e - Common Object Request Broker Architecture - for embedded”, May 2006 (http://www.omg.org/cgi-bin/doc?ptc/06-0501.pdf)

[CORBART] OMG, “Real-time CORBA specification - Version 1.2 - formal/05-0104”, January 2005 (http://www.omg.org/spec/RT/1.2/PDF) [Corsaro]

Angelo Corsaro, Sara Tucci-Piergiovanni, “Scaling the Data Distribution Service to Global Networks”, presentation. Oct. 2009 (http://www.omg.org/news/meetings/GOV-WS/pr/rte-pres/ultra-largescale-dds.pdf)

[Delphi2030] "Zukunft und Zukunftfähigkeit der Informations und Kommunikationstechnologien und Medien, Internationale DelphioStudie 2030", German National IT Gipfel 2009, Stuttgart [DDS]

OMG, “Data Distribution Service for Real-time Systems - Version 1.2”. January 2007 (http://www.omg.org/spec/DDS/1.2/)

[Decotignie]

J. D. Decotignie, "Ethernet-Based Real-Time and Industrial Communications," Proceedings of the IEEE, vol.93, no.6, pp.11021117, June 2005

[EDDL]

EDDL. “Electronic Device Description Language (EDDL)” (URL: http://www.eddl.org)

[EIF]

"The Digital World in 2025 - Indicators for European Action", European Internet Foundation, conference report Sept. 2009 (http://www.EIFonline.org)

[FDT]

EDDL. FDT Group and EDDL Cooperation Team (ECT) agreement. (/www.eddl.org/about/basics/Pages/EDDLCooperationTeam.aspx)

[FieldUb]

N. Akira, S. Jirou, O. Tetsuya, "Visions and Activities on Fieldubiquitous Computing", Yokogawa Technical Report English Edition No. 47 ,2009 (http://www.yokogawa.com/rd/pdf/TR/rd-tr-r00047002.pdf)

[FlexWare]

FP7 European Project, “FlexWARE: Flexible Wireless Automation in Real-Time Environments” (URL: http://www.flexware.at/)

[Fujimoto]

FUJIMOTO Takahiro, “Theory of Open Manufacturing and its Application”, Keizai Sangyo Journal, November 2007 (http://www.rieti.go.jp/en/papers/research-review/043.html)

Category: Report

Status: Final


16/12/2011

Pag. 104


[Giddings]

V. Giddings,”Not your father’s CORBA – An architecture for embedded and real-time systems”, RTC Magazine, October 2006 (http://rtcmagazine.com/articles/view/100752)

[Hydra]

M. Hoffmann, A. Badii, S. Engberg, R. Nair, D. Thiemert, M. Matthess, “Security, Trust and Privacy supported by Context-Aware Middleware”, Second 18th WWRF Meeting - Multimedia Goes Mobile, June 2007

[IEC]

“IEC 61499 Overview”, http://knol.google.com/k/

[Imtiaz]

J. Imtiaz, J. Jasperneite, Han, “A performance study of Ethernet Audio Video Bridging (AVB) for Industrial real-time communication”, inIT Inst. Ind. IT, Lemgo, Germany, ETFA 2009

[IoTClBook]

CERP-IoT Cluster (now IERC Cluster), “Vision and Challenges for Realising the Internet of Things”, March 2010

[IoTSRA]

CERP-IoT Cluster (now IERC Cluster), “Internet of Things Strategic Research Roadmap”, September 2009

[IPv6adapt]

H. Miyata, K. Miyazawa, Y. Akisada, M. Endo, "The analysis of IPv6 adaptation to the industrial network protocol", Yokogawa Electr. Corp., 7th IEEE International Conference on Industrial Informatics, 2009

[Jasperneite] J. Jasperneite, “Echtzeit-Ethernet im Überblick”, in atp Automatisierungstechnische Praxis(3), March 2005 [JSR302]

C. Douglass Locke et al., “JSR 302: Safety Critical JavaTM Technology” (http://jcp.org/en/jsr/detail?id=302)

[JSR50]

J. J. Hunt et al., “JSR 50: Distributed Real-Time Specification” (http://jcp.org/en/jsr/detail?id=50)

[Klefstad]

R. Klefstad, A. S. Krishna, D. C. Schmidt, “Design and performance of a modular portable object adapter for distributed, real-time, and embedded CORBA applications”, CoopIS/DOA/ODBASE 2002, pp. 549-567 (http://dx.doi.org/10.1007/3-540-36124-3_38)

[Maes]

B. Maes, “Skills Shortage EU”, February 2010 (http://bertmaes.wordpress.com/report-skills-shortage/)

[Mahnke]

W. Mahnke, S- H. Leitner, “OPC Unified Architecture - The future standard for communication and information modeling in automation”, ABB Review, Issue 3, pp. 56-61, 2009 (http://www.abb.co.uk/review)

[Mathes09a] M. Mathes, J.n Gartner, H. Dohmann, B. Freisleben, “SOAP4IPC: A Real-Time SOAP Engine for Industrial Automation”, Proc. of the 17th Euromicro Int. Conf. on Parallel, Distributed and Network-Based Processing (PDP’09), p. 220-226, Weimar, Germany, 2009 [Mathes09b] M. Mathes, C. Stoidner, S. Heinzl, B. Freisleben “SOAP4PLC: Web Services for Programmable Logic Controllers”, Proc. of the 17th Euromicro Int. Conf. on Parallel, Distributed and Network-Based Processing (PDP’09), p. 210-219, Weimar, Germany, 2009 [Matrosov]

Category: Report

A. Matrosov, E. Rodionov, D. Harley, J. Malcho, “Stuxnet Under the Microscope - Revision 1.2”, ESET LLC, November 2010 (http://www.eset.com/resources/whitepapers/Stuxnet_Under_the_Microscope.pdf) Status: Final


16/12/2011

Pag. 105


[Mitchell]

G. Mitchell, “Automation Innovation: Where We've been, Where We're Headed”, January 2010 (http://www.automationworld.com/)

[Moxa]

Moxa Corp., “Is your network IPv6-ready? White Paper”, June 2009 (http://www.moxa.com/)

[MsAzCSC]

Microsoft, "Windows Azure Customer Solution Case Study - Siemens Expands Software Delivery Service, Significantly Reduces TCO", November 2009 (http://www.microsoft.com/casestudies/ServeFileResource.aspx?4000 012213)

[OASIS09]

OASIS, “Devices Profile for Web Services Version 1.1”, July 2009 (http://docs.oasis-open.org/ws-dd/dpws/1.1/os/wsdd-dpws-1.1-specos.pdf)

[OECD]

"The Future of the Internet Economy - A Statistical Profile", OECD Ministerial Meeting on the Future of the Internet, Seul, Korea, June, 2008

[OPCUA]

OPC Foundation, “OPC Unified Architecture” (http://www.opcfoundation.org/UA)

[Patawardahn] J. P. Patawardahn, C. Dwyer, A. R. Lebeck, D. J. Sorin, “NANA: A Nano-scale Active Network Architecture”, 2006 ACM 10730516/01/0300-0034 [Pinto]

J. Pinto, “The Future of Industrial Automation”, Automation.com, December 2004 (http://www.jimpinto.com/writings/automation2005.html)

[PNIT]

"PROFINET AND IT", Whitepaper, PROFIBUS Nutzerorganisation e.V., Haid-und-Neu-Str. 7, 76131 Karlsruhe, Germany, 2008

[Profibus]

“Guide to efficient changeover from Profibus to Profinet, white paper”, HMS Industrial Networks AB, May 2010 (http://www.anybus.com/)

[ProfinetIO]

"PROFINET IO - Another Innovative Distributed Automation Solution", white paper, 2008, http://www.rtaautomation.com

[RFC1157]

J. Case, M. Fedor, M. Schoffstall, J. Davin, “A Simple Network Management Protocol (SNMP)”, May 1990 (http://tools.ietf.org/rfc/rfc1157.txt)

[RFC1441]

J. Case, K. McCloghrie, M. Rose, S. Waldbusser, “Introduction to version 2 of the Internet-standard Network Management Framework”, April 1993 (http://tools.ietf.org/rfc/rfc1441.txt)

[RFC2131]

R. Droms, “Dynamic Host Configuration Protocol”, March 1997 (http://www.ietf.org/rfc/rfc2131.txt)

[RFC2462]

S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration”, December 1998 (http://www.ietf.org/rfc/rfc2462.txt)

[RFC3410]

J. Case, R. Mundy, D. Partain, B. Stewart, “Introduction and Applicability Statements for Internet Standard Management Framework”, December 2002 (http://www.ietf.org/rfc/rfc3410.txt)

Category: Report

Status: Final


16/12/2011

Pag. 106


[RFC3411]

D. Harrington, R. Presuhn, B. Wijnen, “An Architecture for Describing, Simple Network Management Protocol (SNMP) Management Frameworks”, December 2002 (http://www.ietf.org/rfc/rfc3411.txt)

[RFC3413]

D. Levi, P. Meyer, B. Stewart, “Simple Network Management Protocol (SNMP) Applications”, December 2002 (http://www.ietf.org/rfc/rfc3413.txt)

[RFC3584]

R. Frye, D. Levi, S. Routhier, B. Wijnen, “Coexistence between Version 1, Version 2, and Version 3 of the Internet-standard Network Management Framework”, August 2003 (http://tools.ietf.org/rfc/rfc3584.txt)

[RFC3646]

R. Droms, “DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)”, December 2003 (http://tools.ietf.org/rfc/rfc3646.txt)

[RFC4919]

N. Kushalnagar, G. Montenegro, C. Schumacher, "IPv6 over LowPower Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", August 2007 (http://www.ietf.org/rfc/rfc4919.txt)

[RFC5395]

D. Eastlake 3rd, “Domain Name System (DNS) IANA Considerations”, November 2008 (http://tools.ietf.org/rfc/rfc5395.txt)

[Rostan]

M. Rostan, “Industrial Ethernet Technologies: Overview” (http://www.ethercat.org/)

[RTComm]

G. Moritz, S. Prütter, D. Timmermann, "Real-Time Service-oriented Communication Protocols on Resource Constrained Devices", Proceedings of the International Multiconference on Computer Science and Information Technology, pp. 695 – 701, 2008

[RTI]

Real-Time Innovations, “DDS for Real-time Systems” (http://www.rti.com/industries/control-systems.html)

[RTJava]

RTJEG, “The Real-Time Specification for Java”, 2000 (http://www.rtsj.org/specjavadoc/book_index.html)

[Schmidt00]

D. C. Schmidt, F. Kuhns, “An overview of the real-time CORBA specification”, IEEE Computer, vol. 33(6), pp. 56-63, June 2000 (http://dx.doi.org/10.1109/2.846319)

[Schmidt98]

D. C. Schmidt, D. L. Levine, D. Mungee, “The design of the TAO realtime object request broker”, Computer Communications, vol. 21(4), pp. 294-324, April 1998 (http://dx.doi.org/10.1016/S0140-3664(97)001655)

[Schneider]

S. Schneider, B. Farabaugh, “Is DDS for You?”, Whitepaper by RealTime Innovations, April 2009

[Semprom]

http://www.semprom.de/semprom_engl/

[SiemCRSP] Siemens IT Solutions and Services, "Secure remote service with the common Remote Service Platform - White Paper", July 2010 (http://www.siemens.com/it-solutions/cRSP)

Category: Report

Status: Final


16/12/2011

Pag. 107


[SOAPUDP] OASIS, “SOAP-over-UDP - Version 1.1 - Committee Specification 01”, May 2009 (http://docs.oasis-open.org/ws-dd/soapoverudp/1.1/cs01/wsdd-soapoverudp-1.1-spec-cs-01.pdf) [SPS]

press article, “Startklar für den Einsatz: 10Gigabit-Technologie für Industrial Ethernet”, SPS-Magazin, 3/2010 (http://www.spsmagazin.de)

[StorrsHall]

John Storrs Hall “Utility Fog: The Stuff that Dreams Are Made Of” Originally published 1993 by J. Storrs Hall. Published on KurzweilAI.net July 5, 2001 (http://www.kurzweilai.net/utility-fog-thestuff-that-dreams-are-made-of)

[Takeuchi].

T. Takeuchi, “FDT/DTM Framework for new field devices”, Yokogawa Technical Report English Edition, No. 44 (2007). (http://www.yokogawa.com/rd/pdf/TR/rdtr-r00044-004.pdf)

[Ultra]

“An Ultra Low-Power 802.11n (Wi-Fi(R)) Wireless Sensor Module”, press release January 2010 (http://www.semiconductorstore.com/)

[UPnP1]

ISO/IEC, “Information technology -- UPnP Device Architecture -- Part 1: UPnP Device Architecture Version 1.0”, IS ISO/IEC 29341, December 2008

[UPnP1.1]

ISO/IEC, “Information technology -- UPnP Device Architecture -- Part 1-1: UPnP Device Architecture Version 1.1”, DIS 29341-1-1, October 2010

[vanEngelen] R. A. van Engelen, K. A. Gallivan “The gSOAP Toolkit for Web Services and Peer-To-Peer Computing Networks”, Proc. of the 2nd IEEE Int. Symp. On Cluster Computing and the Grid (CCGrid2002), p. 128-135, Berlin, Germany, 2002 [VDI_VDE]

VDI/VDE-Gesellschaft, “Automation 2020 - Bedeutung und Entwicklung der Automation bis zum Jahr 2020 - Thesen und Handlungsfelder”, June 2009 (http://www.vdi.de/fileadmin/vdi_de/redakteur_dateien/gma_dateien/A T_2020_INTERNET.pdf)

[Wang]

Nanbor Wang; Schmidt, D.C.; van't Hag, H.; Corsaro, A., "Toward an adaptive data distribution service for dynamic large-scale networkcentric operation and warfare (NCOW) systems," Military Communications Conference, 2008. MILCOM 2008. IEEE , vol., no., pp.1-7, 16-19 Nov. 2008 DOI: 10.1109/MILCOM.2008.4753364

[WHart]

HART Communication Foundation, “WirelessHART Technology” (http://www.hartcomm.org/protocol/wihart/wireless_technology.html)

[WSIoT]

D. Christin, A. Reinhardt, P. S. Mogre, R. Steinmetz, "Wireless Sensor Networks and the Internet of Things: Selected Challenges", Technische Universität Darmstadt, conference 8. GI/ITG KuVS Fachgespräch "Sensornetze", 2009, Hamburg, Germany

[Yeager]

Daniel J. Yeager, Alanson P. Sample, Joshua R. Smith, “WISP: A Passively Powered UHF RFID Tag with Sensing and Computation”, March 2008 (http://www2.seattle.intel-research.net)

Category: Report

Status: Final


16/12/2011

[Zirkler]

Category: Report

Pag. 108


H. Zirkler, T. Klagge, "Background Survey for the HOMEPLANE Project - Survey on Real-World Industrial Networks", March 2009

Status: Final
