D1.2 – Architecture requirements, assumptions and threatshome.ufam.edu.br/hiramaral/04_SIAPE_FINAL_2016/SIAPE_Biblioteca... · further intelligence into the system in an agile manner

04/07/2013 Pag. 1 IoT@Work/WP1/D1.3/1.0

Category: Report Status: Final Availability: Public

IoT@Work WP 1 – PLUG&WORK IOT REQUIREMENT

ASSESSMENT AND ARCHITECTURE

D1.3 – Final framework architecture specification

Reference: IoT@Work/WP1/D1.3/1.1

Category: Report

Deliverable Responsible: Siemens

Author(s): D. Rotondi, S. Piccione, G. Altomare, A. Galipò, S.Genolini (TXT)

H.–P. Huth, A. M. Houyou, J. Gessner, K. Fischer (Siemens)

C. Kloukinas, K. Mahbub, M. Krotsiani (City)

H. Trsek, Jahanzahib Imtiaz (inIT)

J. Claessens (EMIC)

Due Date: 30/06/2013

Deliverable Date: 04/07/2013

Project Start Date: 01/06/2010

Project Duration: 36 Months

Status: final

Availability: Public

04/07/2013 Pag. 2 IoT@Work/WP1/D1.3/1.0


Executive Summary

This deliverable reports the final IoT@Work architecture specification, which has been revised to take into account all relevant validation outcomes and technology and trend-scouting.

The IoT@Work architecture decomposes functions into a layered structure. This ensures a clear decoupling of concerns that enhances flexibility in multiple dimensions:

Flexible business models: many stakeholders and many applications can co-exist on the same infrastructure in a loosely-coupled, yet secure way.

Flexible Infrastructure is enabled by means of decoupling resources and physical issues from applications. This greatly facilitates managing heterogeneity and allows supporting modernization and migration. Because changes can be kept local, repair, enhancements and life cycle management of the whole production becomes easier.

IoT style semantic infrastructure, complemented by powerful communication services and intelligent message processing, allows easier changes of the run time logic and thus enables future enhancements or optimizations.

The cornerstones of the architecture enabling these features are auto-configuration of industrial devices, a multi-tenancy capable network, a semantically and security-wise enriched message bus that allows a Complex Event Processor to introduce further intelligence into the system in an agile manner.

A successful architecture is not complete without a clear security concept (detailed in [6]) and it also has to provide a management concept able to cope with the complexity, without losing control over the system. The project therefore has put significant work into management functionality such as a network management and control service with a clear interface to planning tools or by providing a powerful authentication management service at the message layer. Another example are the easy to use mechanisms developed in the project for configuring the system in a way that semantic information is - at least partially - provided automatically, e.g., by means of auto-configuration or through namespaces that can encode topological information.

This deliverable not only details the final architecture, but also traces the links from requirements to the architectural structure and elements and vice-versa.

04/07/2013 Pag. 3 IoT@Work/WP1/D1.3/1.0


Document History

Version History

Version Status Date Author(s)

0.1 Draft 07.11.2012 A. M. Houyou

0.2 Draft 06.02.2013 D. Rotondi, S. Piccione, G. Altomare, A. Galipò, S.Genolini

0.3 Draft 06.07.2013 A. M. Houyou

0.4 Draft 06.14.2013 H.-P. Huth, J. Claessens, S. Piccione,

0.5 Draft 06.21.2013 H.-P. Huth, H. Trsek, J. Imtiaz

0.6 Draft 06.25.2013 H.-P. Huth, J. Gessner, C. Kloukinas, K. Mahbub, M. Krotsiani



0.9 Draft 07.03.2013 H.-P. Huth, S. Piccione

1.0 Final 07.04.2013 H.-P. Huth, C. Kloukinas, S. Piccione

04/07/2013 Pag. 4 IoT@Work/WP1/D1.3/1.0


Summary of Changes

Version Section(s) Synopsis of Change

0.1 Initial ToC Document structure

0.2 All Initial Content

0.3 All More content, review of ToC

0.4 3.2.7 More content, components&functions map added, orchestrated mgm.

0.5 3.2.5 More content embedded application configuration service added;

0.6 4.2.4, 3.2.7.2 Integration of Security (Siemens); CEP description

0.7 All content update,

0.8 All content update

0.9 All minor fixes, pre-final

1.0 All executive summary, fixes from internal review

04/07/2013 Pag. 5 IoT@Work/WP1/D1.3/1.0


Contents

1 Introduction ............................................................................................ 14

1.1 Scope of WP1 ............................................................................................ 14

1.2 Objective of this Deliverable ....................................................................... 16

1.3 Relationship with other tasks and WPs ....................................................... 16

1.4 Structure of this document .......................................................................... 16

2 Architecture Origins .............................................................................. 17

2.1 Architecture Rationale ................................................................................ 17

2.1.1 Relations with Requirements ................................................................... 18

2.1.2 Architecture Deployment ......................................................................... 19

2.1.3 Terminology ............................................................................................ 19

2.2 Requirements Revision .............................................................................. 22

3 Reference Architecture Specification .................................................. 27

3.1 Layers and Planes ...................................................................................... 27

3.1.2 Security Plane ......................................................................................... 33

3.1.3 Management Plane ................................................................................. 33

3.2 Functional Decomposition of the IoT@Work Architecture ........................... 34

3.2.1 Event Notification Service ....................................................................... 34

3.2.1.1 Overview .............................................................................................. 34

3.2.1.2 ENS Architecture and Services ............................................................ 36

3.2.1.3 AMQP broker and Virtual Host concept ................................................ 37

3.2.1.4 ENS Authorization Service ................................................................... 37

3.2.1.5 ENS Namespaces ................................................................................ 38

3.2.2 Slice Management System ...................................................................... 41 3.2.2.1 Rationale ........................................................................................................ 41 3.2.2.2 Components ................................................................................................... 42 3.2.2.3 Slice Manager Internal Architecture ............................................................... 43

3.2.3 Non-Slice-Related Infrastructure Components and Deployment Issues .. 44

3.2.4 ENS Namespace Management Service .................................................. 45

3.2.5 Embedded application configuration service ........................................... 46

3.2.6 Directory Service ..................................................................................... 48 3.2.6.1 Purpose and Architecture Overview ............................................................... 48 3.2.6.2 Read ............................................................................................................... 52 3.2.6.3 Create ............................................................................................................. 53 3.2.6.4 Update ............................................................................................................ 54 3.2.6.5 Delete ............................................................................................................. 54 3.2.6.6 Query interface ............................................................................................... 55

3.2.7 Security plane ......................................................................................... 55

3.2.7.1 Orchestrated Management................................................................... 55

3.2.7.2 CEP and System monitoring ................................................................ 57

04/07/2013 Pag. 6 IoT@Work/WP1/D1.3/1.0


3.2.7.3 Authorisation capability ........................................................................ 60

3.2.7.4 Capability Revocation .......................................................................... 62

3.2.7.5 Policy Decision Point............................................................................ 63

3.2.7.6 Revocation Service .............................................................................. 65

3.2.7.7 Secure Device Identifier and Security Bootstrapping ............................ 67

3.2.7.9 Device Integrity Assurance .................................................................. 74

3.3 IoT@Work Device ...................................................................................... 76

4 Evaluation and Validation of Architecture ........................................... 77

4.1 Approach .................................................................................................... 77

4.2 Trend-scouting and Evolution since Start of the Project .............................. 77

4.2.1 Reshoring ................................................................................................ 78

4.2.2 Internet-of-Things .................................................................................... 78

4.2.3 Industry 4.0 ............................................................................................. 79

4.2.4 Industrial Security .................................................................................... 79

4.2.5 Technologies ........................................................................................... 80

4.2.6 Summary ................................................................................................. 80

5 Conclusions ........................................................................................... 82

6 References.............................................................................................. 84

7 Appendix A – Generic Requirements List ........................................... 86

7.1 Requirements Template ............................................................................. 86

7.2 Requirement Catalogue .............................................................................. 88

8 Appendix B – Specific Requirements List ........................................... 95 Common specific requirements .................................................................................... 95

Event notification service requirements ........................................................................ 97

Event monitoring and reasoning system requirements ................................................ 99

Specific requirements of application configuration/orchestration ............................... 101

Specific requirements affecting device bootstrapping ................................................ 103

Network specific requirements.................................................................................... 109

Security specific requirements .................................................................................... 116

9 Appendix C - Comparison IoT@Work - IOT-A ................................... 121

9.1 Objective .................................................................................................. 121

9.2 Communications Requirements ................................................................ 122

9.2.1 Functional requirements ........................................................................ 122 Partial fits .................................................................................................................... 123

Non-fits ........................................................................................................................ 125

9.2.2 Non-functional requirements ................................................................. 127 Partial fits .................................................................................................................... 127

Non-fits ........................................................................................................................ 128

9.3 Comparison of the Functional Models ...................................................... 131

04/07/2013 Pag. 7 IoT@Work/WP1/D1.3/1.0


End To End Communication Functional Component ................................................. 131

Network Communication Functionality Group ............................................................ 132

Hop To Hop Communication ...................................................................................... 133

9.4 Conclusion ............................................................................................... 134

04/07/2013 Pag. 8 IoT@Work/WP1/D1.3/1.0


List of Figures

Figure 2-2-1 – Architecture Definition Process ........................................................ 18

Figure 3-1 IoT@Work Architecture Functional Layers (See Deliverable D1.2) ........ 27

Figure 3-2 IoT@Work Architecture Focus in Planes ................................................ 29

Figure 3-3 Architectural Components and Key Functions ....................................... 30

Figure 3-4 – Overview of the ENS approach .......................................................... 35

Figure 3-5 – ENS Architectural Components ........................................................... 36

Figure 3-6- ENS Authorization Service Architecture ................................................ 38

Figure 3-7 - An example of IoT@Work ENS namespace ......................................... 39

Figure 3-8 - IoT@Work ENS namespace publishing ............................................... 39

Figure 3-9: IoT@Work ENS namespace subscription to a branch ........................... 40

Figure 3-10: IoT@Work ENS namespace subscription to a more complex subset .. 40

Figure 3-11: Communication-slice domain. ............................................................. 42

Figure 3-12: Slice System Layers ............................................................................ 43

Figure 3.13 Interaction between OPC UA devices and Directory Service ................ 48

Figure 3.14 Bootstrapping interaction between OPC UA devices and DS ............... 48

Figure 3-15 – IoT@Work Directory Service ............................................................. 49

Figure 3-16 – IoT@Work Directory Service Data Model .......................................... 50

Figure 3-17 – IoT@Work Directory Service architecture .......................................... 51

Figure 3.18 – Process flow orchestrated management ............................................ 56

Figure 3.19: ENS/CEP bridging interfaces ............................................................... 58

Figure 3.20 – Monitoring excessive power consumption in Event Calculus ............. 60

Figure 3-21 - Authorisation Capability XML Schema - top level elements ................ 61

Figure 3-22 – Authorisation Capability Revocation XML Schema ............................ 62

Figure 3-23 - PDP Service architecture ................................................................... 64

Figure 3-24 – Revocation Service architecture ........................................................ 66

Figure 3-25: Secure Device ID Module .................................................................... 68

Figure 3-26: Manufacturer based bootstrapping ...................................................... 70

Figure 3-28: NAC architecture ................................................................................. 71

Figure 3-27: Network Access Control Steps ............................................................ 71

Figure 3-29 NAC authorisation architecture components deployment ..................... 73

Figure 3-30: System Integrity Assurance architecture components ......................... 74

Figure 3-31: System Integrity Assurance architecture deployment .......................... 75

Figure 32: IoT@Work requirements relationship to IOT-A ..................................... 122

Figure 33: Synopsis of non-functional IoT@Work communication requirements ... 127

04/07/2013 Pag. 9 IoT@Work/WP1/D1.3/1.0


List of Tables

Table 1.1 – Task T1.1 objectives ............................................................................. 15

Table 1.2 – Task T1.2 objectives ............................................................................. 16

Table 2.1 – Generic Requirements List ................................................................... 23

Table 2.2 – Common requirements ......................................................................... 24

Table 2.3 – Event notification service requirements ................................................ 24

Table 2.4 – Event monitoring and reasoning system requirements .......................... 24

Table 2.5 – Specific requirements of application configuration/orchestration ........... 24

Table 2.6 – Specific requirements affecting device bootstrapping ........................... 25

Table 2.7 – Network specific requirements .............................................................. 25

Table 2.8 – Security specific requirements .............................................................. 26

Table 3-1 - ENS Namespace management service RESTful API ............................ 46

Table 5.1 – Task T1.1 achievements ....................................................................... 83

Table 5.2 – Task T1.2 achievements ....................................................................... 83

Table 7.1 – Template for IoT@Work requirements .................................................. 86

Table 7.2 – Possible IDs for generic and specific requirements ............................... 87

Table 7.3 – Range of categories.............................................................................. 88

04/07/2013 Pag. 10 IoT@Work/WP1/D1.3/1.0


List of Acronyms

ABAC Attribute-Based Access Control

is an access control policy that grants rights on objects according to the attributes of the subjects submitting requests on protected objects. In ABAC-based systems, the constraints on the attributes that granted subjects must fulfil are called claims.

ACID Atomicity, Consistency, Isolation, and Durability

is the strictest approach for concurrency and transaction management focusing on consistency. It is used to handle SQL transactions and identifies the set of properties that guarantees reliability of database operation.

ACL Access Control List

is a list of permissions attached to an object; each item in the list specifies which users and/or systems are granted access to objects as well as what operations are allowed on given objects.

In ACL-based security models, operation requests on objects are checked against the entries in the ACL.

AMQP Advanced Message Queuing Protocol

is a protocol and a domain model for a message oriented middleware.

ASIC Application-specific integrated circuit

is an integrated circuit tailored to a particular use rather than being general-purpose.

BASE Basically Available, Soft state, Eventually consistent

is a weaker approach for concurrency and transaction management than ACID. A BASE-based application “… works basically all the time (basically available), does not have to be consistent all the time (soft-state) but will be in some known-state eventually …” (Bob Ippolito).

DCS Distributed Control System

is a process control system using a network infrastructure to communicate with a set of sensors, controllers, operator terminals and actuators.

DHCP 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.

DPWS 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.

DoW Description of Work

04/07/2013 Pag. 11 IoT@Work/WP1/D1.3/1.0


HMI 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.

IEEE 802 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).

IETF 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).

IoT 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.”.

MOM Message Oriented Middleware

MOM provides an asynchronous form of communication (i.e. the sender does not block waiting for the recipient to participate in the exchange), based on the exchange of messages. In MOM, messages are generally untyped and their internal structure is the responsibility of the communicating applications. To further decouple sender(s) and receiver(s), MOMs normally provide features to identify (i.e. name) the different message exchanges for example associating messages to specific topics or namespaces.

PAC 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.

04/07/2013 Pag. 12 IoT@Work/WP1/D1.3/1.0


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.

PROFINET PROFINET

is the open industrial Ethernet standard for automation. PROFINET uses TCP/IP and IT standards and supports real-time Ethernet communications

RBAC Role-Based Access Control

is an access control policy that grants rights on objects according to the role of the subjects submitting requests on protected objects.

REST 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) centred 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.

RFID Radio-Frequency IDentification

is a technology for transmitting data stored in an electronic tag (called RFID tag or transponder), which is attached to the object to be identified, to a reader using radio waves. A typical usage of the RFID technology is the identification and tracking of objects.

RPC Remote Procedure Call

is an inter-process communication mechanism that allows a process running in a specific address space to activate a sub-routine of a process running in another address space without the burden of managing the details of this remote interaction.

SAML Security Assertion Markup Language

is an XML-based open standard for exchanging authentication and authorisation data between identity and service providers.

SCADA Supervisory Control And Data Acquisition

refers to industrial control systems: computer systems that monitor and control industrial processes or infrastructures.

SOA 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 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.

UPnP 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.

04/07/2013 Pag. 13 IoT@Work/WP1/D1.3/1.0


XACML eXtensible Access Control Markup Language

is a declarative language for describing access control policies; it has been defined by the OASIS standards organization.

W3C World Wide Web Consortium

is the main international standards organization for the World Wide Web. Amongst others, it is responsible for the XML standardisation.

04/07/2013 Pag. 14 IoT@Work/WP1/D1.3/1.0


1 Introduction

1.1 Scope of WP1

Work Package 1 “Plug&Work IoT Requirement Assessment and Architecture”, and Task 1.2 “Architecture Definition Specification” in particular, has been structured in such a way to have a phased approach with a first iteration whose objectives are to collect the most central and critical aspects of Plug&Work in the industrial environment, as reported in D1.1, and quickly provide a first set of specifications so that the design and development phases can proceed giving the opportunity to anticipate both the development and the on-field validation. The second iteration has produces as outcome D1.2 that reports a refinement of the requirements, the first specification of the architecture and the contextualization of the design effort in the Internet of Things European Research Cluster (IERC) ecosystem. The last iteration envisage the revision of the architectural model according to the internal (i.e. relationships with other WPs, implementation and testing of the designed components in the selected pilots) and external feedback (i.e. stakeholder validation, cooperation and synergies with other IoT R&D projects) This approach, as stated in the Description of Work, is suggested by the complexity of the addressed scenario and the novelty of IoT solutions in the manufacturing environment. Task 1.1 deals with the definition and iterative refinements of requirements and assumptions, identification of the pilot and scenarios for the validation of the IoT@Work solutions and the analysis of the state-of-the-art that must drive the design process in order to ensure that it is actually aligned with the actual needs of the target domains and applicative scenarios and leverages the latest and best suitable technologies available in the market.

The following tables provide a summary of the objectives of WP1, divided by tasks.

04/07/2013 Pag. 15 IoT@Work/WP1/D1.3/1.0


Sub-task Title Objectives

T1.1.1 State of the art analysis refinement

Definition of operational and technological scenarios

Identification of architectural and operational needs and evaluation of architectural design, choices and assumptions

T1.1.2 Architecture requirements & assumptions

IoT impacts on factory automation

Definition of concepts for Plug&Work

Implications on the technical requirements that affects WP2 (communication) and WP3 (security)

T1.1.3 Pilot Scenario Identification Identification of the IoT@Work Pilot Scenarios

Identification of requirements, components, elements of the validation plan (WP4)

T1.1.4 Architecture requirements & assumptions refinement

Analysis of evolution of the technologies developed in IoT@Work

Feedback coming from outcomes of the implementation and validation activities

Table 1.1 – Task T1.1 objectives

Phases Title Objectives

Phase 1 Functional Reference Architecture V1

Identify the principal components of the project architecture

Specify the related features

Identify what is available and what is necessary to implement

Use as much as possible a middleware layer based on standard solutions and open technologies

Phase 2 Functional Reference Architecture V2

Take into account iterations in Task 1.1

Take into account feedbacks from WP2 and WP3

Take into account first outcomes of the validation activities

Enrich and revise the V1 specification

04/07/2013 Pag. 16 IoT@Work/WP1/D1.3/1.0


Phase 3 Functional Reference Architecture Final Version

Finalise the reference architecture

Table 1.2 – Task T1.2 objectives

1.2 Objective of this Deliverable

This deliverable reports the outcomes of the final iteration of the architecture definition process. It describes the IoT@Work final, revised architecture specification as revised taking into account all relevant outcomes of the validation activities and technology scouting and research.

1.3 Relationship with other tasks and WPs

The specific requirements defined in D1.2 have driven the technical specifications reported in WP2 and WP3 deliverables, such as D2.3, D2.4, D3.2, and D3.3. Furthermore, the implementation, testing, and validation activities carried out in WP4 have been taken into account to better shape the architectural model.

1.4 Structure of this document

This document has been organised in three main sections devoted to specific deliverable’s objectives:

Section 2 Architecture Origins is devoted to provide an overview of the IoT@Work architecture, but also its rationale and its relationships with the identified requirements. This chapter, therefore, constitutes a kind of summary of the IoT@Work architecture design approach;

Section 3 Reference Architecture Specification revises and deepens the architectural model described in D1.2;

Section 4 Evaluation and Validation of Architecture is focused on the analysis of the evolution of the state-of-the-art technologies since the beginning of the project and on the approach for evaluating the architecture.

In addition to the aforementioned sections, the document comprises: this introductory section, a section that summarises the final achievements of WP1 (section 5 Conclusions), a reference section (section 6 References) and three appendices. The first appendix (section 7 Appendix A – Generic Requirements List) details the generic requirements elicited during the project lifetime. The second appendix (section 8 Appendix B – Specific Requirements List) includes the detailed description of the specific requirements. Finally, the third appendix (section 9 Appendix C - Comparison IoT@Work - IOT-A) provides an exhaustive comparison of the IoT@Work Architectural Reference Model with IoT-A Unified Requirements.

Additionally, to improve document readability, a table of the acronyms used in the document has been included at the beginning. The table provides a short description of the abbreviations used and can serve as a quick reference to the technologies and approaches mentioned in the deliverable.

04/07/2013 Pag. 17 IoT@Work/WP1/D1.3/1.0


2 Architecture Origins

This chapter provides an overview of both the IoT@Work architectural design methodology, and the IoT@Work final architectural reference model.

The design methodology, as evident from the subsequent sections, had the aim to provide clear traceability relations among the identified requirements and the architectural functional elements. In this way it is easier for readers to follow the reasons for the introduction of a component or feature, i.e., which requirements a component serves (component requirements), identify the impact of requirements on the system, i.e., which components are serving/impacted by a requirement (requirement components) and can more easily catch the rationale and structure of the overall design.

Using these two types of traceability relations a kind of “correlation matrix” was developed among the requirements and the architectural components and functionalities which heavily simplifies both the process of refining and deepening the design (for example giving priority to elements affected by the most relevant or innovative requirements), and the process of revising appropriate architectural components or functionalities in case of changes or revisions of the requirements.

2.1 Architecture Rationale

The IoT@Work architecture has been developed through an agile process (illustrated in Figure 2-2-1) that has been adapted throughout the running of the project. In general, the methodology used could be categorized as a model-driven architecture development approach.

The starting point for the architecture design has been the use of scenario-driven requirements. These scenarios have been used to describe a system model of how the Internet of Things is expected to affect specifically the factory and automation systems in general. These requirements are also reflecting the specificities and constraints of existing systems. The resulting requirements have provided a good set of generic needs that the IoT@Work architecture has to fulfill.

In addition to this top-down architecture design approach, an initial technology testing activity has also been initiated in order to gain a deeper understanding of available techniques and mechanisms and the higher-level abstractions these can support. The technology testing activity is a bottom-up design approach that allows testing existing technologies in terms of fulfillment of IoT@Work architecture requirements or of defining the needed extensions.

04/07/2013 Pag. 18 IoT@Work/WP1/D1.3/1.0


Figure 2-2-1 – Architecture Definition Process

In parallel, additional efforts were spent in understanding the core differences that distinguish an IoT-system from existing embedded systems or automation systems. This effort has been carried out in close cooperation with the EU project IOT-A [8], whose main goal is to design IoT architecture principles or what is named an IoT architecture reference model. The current status of the project has provided a new way to develop an IoT reference model mostly based on the IEEE Standard 1471-2000 software architecture recommendations. The IoT-A project uses multiple views from all stakeholders of an IoT-system. This has resulted in several models including an IoT functional model. The latter model gathers the functions into functional groups without relying on the classical ISO-OSI layer model, where the function groups are not necessarily layered. A similar approach is adopted in the IoT@Work project when grouping the functionalities for specific functions according to what their specialties are. An example would be the group of functions running the network of things and dealing with adapting the communication to application needs. Another function group deals with managing application layer events generated by things and related to application logic.

2.1.1 Relations with Requirements

The 22 generic requirements (more high-level) which were extracted from the selected IoT@Work application scenarios, have resulted in 50 specific functional and non-functional (more low-level) along the different layers. Each functional requirement can be mapped to a function located in the architecture. There are also non-functional requirements which have influenced several functions.

The specific focus of the IoT@Work project is the management of network and communication services, which represent the aggregation of networking devices and links (as physical entities) and their offered resources and services such as bandwidth reservation, synchronization, localization services (as virtual entities). Such management includes configuration of appropriate access rights, the ability to deal with complexity by aggregating across different layers and functions, and the need to guarantee reliability and availability of key services and resources.

It is important to note that our extensive set of requirements, along with their scope and priority, must be understood in the context of this specific focus. The IoT@Work architecture provides the framework within which we are taking forward the requirements. The architecture particularly influenced the categorization of the specific requirements. The high-level layering of components has identified a set of

Stakeholder Feedback

Collect requirements

RequirementsAnalysis using

viewsArchitecture Technologies

Early implementations, test beds

Integrate & Demonstrate

Decompose & analyse

Derive solution architecture

Develop technologies

Current status

04/07/2013 Pag. 19 IoT@Work/WP1/D1.3/1.0


high-level architectural components and functions for the IoT@Work project. These functionalities and components are detailed in Chapter 4. Each of them has been linked to one or more specific requirements..

2.1.2 Architecture Deployment

The IoT@Work architecture could be depicted in a set of key functions that support the management of the “Internet of devices” found in the factory field and their related applications. Whereas within the earlier deliverables D1.2 [3], D3.2 [6] and D2.3 [2], we focused on some of these respective functions and their specification, in this deliverable we also consider the functions dealing with the programmability of the infrastructure for the needs of applications. The interfaces between the application programmer and system administrator are explored in this section in more details.

IoT@Work Deployment View: Infrastructure-related Functions, Application Supporting Functions

2.1.3 Terminology

This section addresses the key definitions used within the context of IoT@Work. It is an essential step to relate the IoT to the application area of factory automation. Although, we believe this terminology is in no way complete, it offers a starting point and an important input to the IoT research community. The terminology is inspired by the corresponding terms from the IOT-A project.

Entity:

An entity is either a physical or virtual object that can actively communicate with other entities. Entities can offer or use resources, and do so through service instances.

Device: A device is a synonym for an entity. It can be physical, e.g., a temperature sensor, or virtual, e.g., a virtual PC. A device can offer one or several resources through their respective service instance. A Legacy Device is a device without any IoT@Work specifics, consequently a Native Device is specifically designed to support IoT@Work functionality.

Resource: A resource is a passive, finite object that is either physical or virtual, and which is accessed through one or more services. Note: A thing associated with a service instance is also a resource, e.g., a parcel with an RFID tag.

Service Type: A service type is something that has an interface, a generic (possibly empty) access policy, and which is used to access resources.

Service Instance:

04/07/2013 Pag. 20 IoT@Work/WP1/D1.3/1.0


A service instance is something that has an interface, an identifier, and a specific (possibly empty) access policy. Notice: The same resource may be accessible by more than one service instance. For example a wireless network resource may be accessible by service instances that have the same interface but different identifiers and access policies.

Thing: A thing is a physical object. When associated with a service instance it becomes a (physical) resource.

System:

A system is a set of interacting or interdependent entities forming an integrated whole.

Application: An application is a software-intensive socio-technical system that makes use of resources in order to fulfil a mission or goal. Note: The same resources and entities can simultaneously be used by different applications.

Event: An event is something relevant (e.g. device/service/application start/ shutdown, configuration/ reconfiguration, connection setup/teardown, subject login/logout, faults, etc.) within and for the system (e.g. a device, software modules, etc.) in which it happened, independently from event’s overall relevance (which can change with reference to other events, the context in which the system is operating, etc.).

Additional Clarifications Notice that in this deliverable the scope of devices is limited to those that comply with the requirements. For example, a device needs to be configurable (R08), to be addressable (R09), and to adhere to security policies (R14).

According to the IoT@Work requirements, devices include at least one service interface that allows connectivity to an IP network. Devices that use a proxy to connect to an IP network are therefore not considered IoT@Work devices by themselves, but only when considered together with their proxy.

In this document, when we use the general term service we refer to a service instance, while we explicitly use service type when referring to the type of a service.

In the IoT, a system boundary is open, i.e. it can include any connected thing. A resource can be seen as an extension of the notion of an object, which is described through the way (service type) it can be used, accessed, and its relationship to its environment. In the IoT, a thing can offer a resource as soon as it is connected to a service instance. Several services may access the same resource, which is finite in nature, leading to contention and requiring some access policy. These two core concepts of a resource and a service can be seen as the building blocks of IoT applications or systems. Resources related to a specific element, such as a RFID equipped physical object or a more complex device such as a robot, follow the same principles. The robot is a complex thing that aggregates different resources and services within its physical boundary, but from the outside the complexity can be hidden through a single resource and service representation of the robot. Systems, which often can be a software system, run an application defining the way resources are accessed through services offered in both the real world IoT and their

04/07/2013 Pag. 21 IoT@Work/WP1/D1.3/1.0


virtual counterpart, such as virtual CPUs and virtual memory or a file entry describing the physical object associated with an RFID.

Using these abstract notions in the automation world, where purposed objects and systems are more rigid in nature, allows a better flexibility in composing things and applications in a more open and agile way. The system boundary is more open to include new instances of resources and services.

For example let us consider the case of running a production routine for a single robot defining the dependencies and interactions among resources within the robot and its environment. With the IoT approach the robot is no longer a closed system but can be easily extended with new things or devices connected through the IoT. An example would be the way environment sensors around the robot are described, configured and then associated with a new energy-saving service that can access both the sensors and the robot to control energy usage.

The IoT@Work architecture aims at managing the life cycle of resources accessed in an IoT factory system. The architecture deals with the creation of resources (usually after bootstrapping devices and networks), identifying and addressing the resources in both the real world and the virtual world, then creating and configuring the application logic in the open and flexible manner that the IoT-system approach would allow. These processes could occur once at a transient configuration phase for the whole automation system or through adaptation steps or changes that happen throughout the lifetime of a factory, e.g. during maintenance situations, introduction of new applications to optimize a “smart factory”, or simply for re-purposing parts of the production system for the needs of new products. The lowest level we model in our architecture is the physical world, where devices are the physical entities connected to the IoT@Work network. Then comes the first abstraction layer above the physical world aggregates, where meta-data describing resources and services embedded in the devices and entities. At this first abstraction layer there is little hierarchical organisation, which is a key characteristic of a flat IoT. However, these low-level resources and services should not be exposed to their users (i.e. applications) directly, to reduce the overall system complexity. Therefore another layer of abstraction is needed, where aggregate resources and services are created and described in a way that can be managed by users/applications easily.

The composite services hide the complexity of accessed resources and make it possible to introduce some hierarchy in describing resources. An example would be that a robot is composed of a multitude of sensors and actuators, all of which might be accessed as one composite service that is the “welding service instance”. The composite service can also hide the details of composing virtual and physical entities. Composite services rely also on the discovered physical context of certain resources, like their location, neighbours, and their availability. For these three aspects, the second architectural layer specifies how composite services deal with context collection, contention, and access rights, which forms the core of the IoT@Work functions.

An example application that requires context information is a production application, which cannot be configured unless the correct production services are invoked (i.e. one specific “pick-up robot”, another “welding robot” in its exact vicinity, etc.). The locations of the robots in this example have to match those expected or specified by the application programmer (planner).

Other applications are less tied to specific devices or their physical context. They might be more interested in an event of some type without caring about which device exactly has generated it.

04/07/2013 Pag. 22 IoT@Work/WP1/D1.3/1.0


Both aforementioned types of applications have a context and access privileges, which need to be defined through the third layer of abstraction. Applications access these resources, through a service interface, matching their needs. An example would be that of an application requiring a certain network resource such as bandwidth, which is accessed through a reservation service. The network service allows the application to specify its bandwidth needs, but it hides the complexity of the service composition and aggregation occurring within the physical and virtual entities composing the network (i.e. network nodes, links, protocol entities, etc.).

2.2 Requirements Revision

The requirements revision, as stated in the DoW, follows a phased approach. As reported in the DoW we performed three main iterations:

The first iteration was focused on collecting and analysing the most core & critical aspects of Plug&Work. This first iteration has produced the generic requirement list shown in appendix 7. The details on the operational approach we used to this end is widely are described in the specific requirement list in appendix 8.

The second iteration took into account technological advances, as well as the first developments and first experimental outcomes, and aspects other than the core and critical ones. D1.2 [1] started this iteration providing refinements and enrichments over the outcomes reported in [4].

Finally, the third iteration will take into account validation outcomes and further technological advances.

The above approach for requirements refinement mimics the Spiral Model for software development, which is a model well suited for the issues we face in IoT@Work representing a risk driven approach to software process analysis and structuring. The Spiral Model, indeed, envisages iterative development cycles (graphically represented as an expanding spiral, with inner cycles focusing on early system analysis and prototyping, and outer cycles focusing on the classic software life cycle phases as well as on further analysis and revisions of the requirements and the development). The Spiral Model envisages risk analysis occurring during each spiral cycle.

As evident this model applies quite well to our context being able to quickly take into account:

The evolving technological scenario;

A continuous assessment of approaches and technological developments;

Feedback and synergies with other contexts (e.g. IERC R&D projects).

This iterative exercise at the end improves the overall quality of an R&D activity, as well as the fulfilment of requirements in a domain, like IoT, which is strongly dynamic.

The IoT@Work requirements that have so far been published in previous deliverables [3] (and are attached here as appendices) have originated from the system model (model-driven architecture) and the technology driven analysis (mainly on constraints and goals). This document allows us to better consolidate both requirements into what we call generic requirements. These include both functional and non-functional requirements, which do not always indicate the layer and technologies they will affect. This is carried out in the detailing of these generic requirements into specific ones that are grouped according to the functionalities they are targeting.

04/07/2013 Pag. 23 IoT@Work/WP1/D1.3/1.0


The following table lists the generic requirements gathered from the requirements elicitation process.

ID Name

R01 System extensibility / Extensibility

R02 Fast re-initialization

R03 Controlled initialization

R04 On-demand path reconfiguration

R05 Fast network bootstrapping

R06 Support of device migration

R07 Auto-configuration

R08 Easy-to-use system management tools

R09 Semantic naming/addressing and identification of devices

R10 Authenticity and integrity of message datagrams

R11 Automatic system diagnosis

R12 High availability

R13 Self-sufficient operation of systems

R14 Clonability

R15 System and devices compliance with security policy

R16 Secure remote diagnosis and maintenance

R17 Company-wide access

R18 Secure inter-site communication

R19 Accountability of interactions

R20 Scalability

R21 Reliability

R22 IPv6 Support

Table 2.1 – Generic Requirements List

04/07/2013 Pag. 24 IoT@Work/WP1/D1.3/1.0


The following tables list the function-specific requirements derived from the generic ones.

Common requirements

ID Name

RC.01 Smooth scaling

RC.02 Auditability and Accountability

RC.03 Interoperability

RC.04 Provision of semantically enriched information about devices

RC.05 Standardisation of entity semantics

Table 2.2 – Common requirements

Event notification service requirements

ID Name

RE.01 Process-data provision/dissemination

RE.02 Event processing

RE.03 Provision of semantically enriched information about events

RE.04 Graphical event namespace management tool

Table 2.3 – Event notification service requirements

Event monitoring and reasoning system requirements

ID Name

RM.01 Run-time verification of system events

RM.02 Explicit representation of system set-up

RM.03 Ability to pre-compile monitoring rules

Table 2.4 – Event monitoring and reasoning system requirements

Specific requirements of application configuration/orchestration

ID Name

RO.01 Avoid undesired interference and respect operational constraints of automation system when carrying out system adaptation/update/maintenance/configuration

RO.02 Correctly carry out system adaptation/update/maintenance/configuration, respecting dependencies between individual adaptation/update/maintenance/configuration operations

RO.03 Facilitate/automate system adaptation/update/maintenance/configuration with high complexity

Table 2.5 – Specific requirements of application configuration/orchestration

04/07/2013 Pag. 25 IoT@Work/WP1/D1.3/1.0


Specific requirements affecting device bootstrapping

ID Name

RB.01 Standardized device pre-configuration (Device Requirement)

RB.02 Minimum user interaction for pre-configuration (Device Requirement)

RB.03 Availability of basic infrastructure (Environment Requirement)

RB.04 High reliability (Environment Requirement)

RB.05 High scalability (Process Requirement)

RB.06 Dead-lock avoidance (Process Requirement)

RB.07 Updatable soft- and firmware (Device Requirement)

RB.08 Network Access Control Client

RB.09 Reasonable Computing Power

Table 2.6 – Specific requirements affecting device bootstrapping

Network specific requirements

ID Name

RN.01 Managed devices (Device and Network Requirement)

RN.02 Fast re-routing and forwarding manipulations (Network Requirement)

RN.03 Fast network bootstrapping support (Device and Network Requirement)

RN.04 Scalability

RN.05 IPv6 support (Network Requirement)

RN.06 Automatic/assisted network configuration

RN.07 Rapid and deterministic network initialisation

RN.08 Seamless network re-configuration supporting system extensibility

RN.09 Smooth device replacement and restart

RN.10 Network interconnectivity and reachability of devices

RN.11 Support of arbitrary network topologies

RN.12 Clear identification and addressing of devices

RN.13 Offline and online routing along arbitrary paths

RN.14 Network and service reliability

RN.15 Quality of Service (QoS)

Table 2.7 – Network specific requirements

04/07/2013 Pag. 26 IoT@Work/WP1/D1.3/1.0


Security specific requirements

ID Name

RS.01 Secured access to services

RS.02 Graphical capability and capability revocation definition

RS.03 Secure credential management

RS.04 Secure network access of devices

RS.05 Policy enforcement for devices

RS.06 Device and system integrity assurance

RS.07 Secure device identifier

RS.08 Initial security credentials on devices

RS.09 Secure device-to-device communication

RS.10 Security mechanisms are compliant with system constraints

RS.11 Suitable security policies for automation environment

Table 2.8 – Security specific requirements

04/07/2013 Pag. 27 IoT@Work/WP1/D1.3/1.0


3 Reference Architecture Specification

This section describes the IoT@Work final architectural specification in detail.

The solution architecture consists of several functions, which are implemented by various components. To group these functions and components in a way that implementation decisions can be taken in a focused way, we provide a layered architectural view. Cross-cutting concerns are structured into planes which are orthogonal to the layers.

The final architecture presented here is an updated and revised version of the solutions and architectural principles presented in previous deliverables, mainly in D1.2 [3], D 3.2 [6] or D2.3 [2]. Security is an integral part of that architecture, but this section here will only provide an overview on the impact of security which is considered in more detail in dedicated deliverables.

3.1 Layers and Planes

The layers are defined as abstractions and function groups managing the IoT infrastructure from the lowest layer to the IoT applications running on top. In between these two, the function groups include management and orchestration functions that deal with configuration and running of applications on top of resources and services offered in the IoT infrastructure. The functional grouping has resulted into separating three functional layers discussed in D1.2 (See Figure 3-1):

Figure 3-1 IoT@Work Architecture Functional Layers (See Deliverable D1.2)

i. The device and network embedded services, which is the first abstraction of the infrastructure, and its associated management functions. These functions include assigning identifiers, collecting device semantics and context, managing communication interfaces and securing physical components, etc.

ii. The second abstraction layer deals with managing embedded resources and services in an aggregated manner, hiding some of the details of single components or devices. The functions here include service directories, network abstractions, and low-level system monitoring and security management.

04/07/2013 Pag. 28 IoT@Work/WP1/D1.3/1.0


iii. The third layer of abstraction supports directly the application through specific middleware services targeting IoT scenarios. In the automation field, these functions include a messaging bus, application resource descriptions (e.g. requesting reliable communication or security context is interpreted here). At this layer, the application logic is interpreted at configuration or runtime, and the interfaces to the different IoT management components are defined here. Semantic reasoning functions, as well as other supporting functions can be placed here.

These functional groups roughly gather at each abstraction layer a group of technologies targeted in the project to meet functional requirements that are detailed in D1.2. The IoT-centered architecture, however, is defined within the context of automation systems. Therefore, there is a focus on those functional parts that should deliver reliable and secure communication, which is required by some automation applications, for instance.

The IoT approach to embedded systems is based on the model that virtual and physical are interlinked and supported by self-organizing properties of the Internet protocols. Several functions and resources offered by embedded devices (which are a subset of smart objects or things), can be encapsulated into virtual objects that are invoked or made available to a variety of applications and services, which contend to access and use the things i.e., their physical and virtual resources. The IoT approach of purposing distributed embedded systems can be adapted to automation systems as well. The difference to a traditional automation system lies in the multitude of applications and their scope (they could run remotely) that can interact with the same production system. Also the way the system is configured and managed in a flexible and agile manner, offering more data and context information.

An important constraint of automation systems today is that they are heavily engineered and rely on detailed pre-configured physical components and protocols, making the system very rigid to changes, let alone allowing multiple services or applications to be adapted or added on the fly. An example of such detailed planning includes designing exact layout of both physical networks and logical connections or protocol parameters in the offline engineering phase. The network parameters are obtained from the communication needs of the pre-defined automated production applications. This top-down engineering of the network also prerequisites an exact choice of networking technology and protocols, so that their behaviour can be predicted and well dimensioned. This example of pre-engineering of communication solves the cross-cutting problem that involves knowing all about the infrastructure and its physical layout, but also the applications, their connectivity and non-functional requirements of reliable and deterministic communications.

In a layered and well-decoupled IoT-based architecture, these cross-cutting concerns still exist and are also important for its successful adoption for critical infrastructure in general. An IoT architecture has to deliver reliable communication and guarantee security, the way automation systems need it. It is, therefore, our task in the project to address these cross-cutting concerns at each involved layer. Since this vertical cross-cutting concerns can be pictured as planes vertical to the layer model proposed in D.1.2..

04/07/2013 Pag. 29 IoT@Work/WP1/D1.3/1.0


Automation Applications

Application level middleware services commissioning, composition, adaptation

Device resource creation & management servicesabstraction, context/dependencies

Device and network embedded servicesauto-configuration, device semantics, network management

Field/Control Infrastructure & Network

Co

mm

un

ica

tio

n P

lan

e

Se

cu

rity

Pla

ne

Ma

na

ge

me

nt

Pla

ne

Figure 3-2 IoT@Work Architecture Focus in Planes

The three orthogonal planes that IoT@Work focuses on are shown in Figure 3-2. They include:

i. Communication Plane: managing networks and communication so that multiple applications can use the same network, while delivering reliable guarantees for the applications that have high Quality-of-Service (QoS) needs.

ii. Security Plane: managing system security to make sure that different management functions at each layer include some security mechanisms.

iii. Management Plane: supporting service management and orchestration on top of an IoT infrastructure and managing devices and their configurations, and linking these to applications and services.

Structuring the problem space of the system in layers and planes allows identifying various components and functions as shown in Figure 3-3 and as detailed in the next sections.

04/07/2013 Pag. 30 IoT@Work/WP1/D1.3/1.0


Figure 3-3 Architectural Components and Key Functions

04/07/2013 Pag. 31 IoT@Work/WP1/D1.3/1.0


During commissioning of such an application (i.e. installation, bootstrapping the new application), first, the application engineer requests a communication service that is used for operating the application, then the devices interacting with each other within that application introduce further application logic after having presented valid credentials for this. The aforementioned configuration steps are supported by the following components:

The slice manager, which could be triggered by a slice request from an

application orchestration service that is capable of translating an automation

planning information into slice specifications. The function depicted in the

communication plane in Figure 3-2 is linked to the application plane in that it

allows the application programming environment to define a slice request for

an application (or aggregates). Such a slice request includes a list of end-

nodes, communication requirements, and a mapping to a slice class, as

defined in D2.3.

The interface to the embedded application configuration service allows

providing the device with the needed configuration data for the applications,

e.g., device names and communication cycle information.

In the case of a planned device (especially in the case of an engineered production system), we introduce a configuration function which:

Requires a service hosted in both device and planning/engineering tools;

Gathers device semantics upon connecting a device;

Contacts the planning tool to request the device name; and

Configures planned device name.

The planned device, together with the services it provides, is registered with the directory service as a child of the (immediately) containing device or entity (the containment relationship should be intended not only in a physical but also a logical sense: for example the energy monitoring module attached to a production unit should be registered in the directory service as a child of that production unit, and the production unit as a child of the production cell where it is deployed).

In order to manage access to events collected in the factory, we introduce a configuration service for the ENS namespaces, through which plant engineers can define as many namespaces as required.

Examples of supported applications, which are addressed in IoT@Work include:

ENS client applications (event publishers and subscribers), as introduced in

D1.2;

CEP (Complex Event Processing),which is discussed in Section 4;

NAC (Network Access Control) Client, a security-plane application introduced

in D3.2; and

State of the art controller/IO applications (e.g., Profinet, etc.), which are

further supported in the IoT@Work architecture.

We now consider the functions involved during such an orchestration of a communication service (or slice) for the purpose of a newly “plugged” IoT@Work device. Before the device is allowed to connect or initiate a new application, network connectivity has to be established and provisioned. This means:

04/07/2013 Pag. 32 IoT@Work/WP1/D1.3/1.0


The newly connected device is first auto-configured through layer-2 and layer-

3 protocols for link-up discovery, and network IP address configuration.

The Slice-Enforcement Point (SEP) is started in every network node.

The detected local-network topology is registered through each SEP with the

slice manager (SM); if authentication is needed then SM checks a pre-

configured certificate against a public key (network-access control for network

nodes is a security plane function).

The topology data-base in SM is populated with information such as active

node interfaces, direct node neighbours, network-node semantics (e.g., which

type of switch, scheduler capabilities, etc.).

The system establishes Slice0 a.k.a. “Guest Slice”, which connects all nodes and enables controlled bootstrapping of higher-layer services and applications.

3.1.1 Communication Plane

A major goal of the IoT@Work architecture is the ability to configure the network in a way that the resource requirements of applications are met without disturbing other applications. The main motivation behind this requirement is the fact that network behaviour creates some constraints on the behaviour of specific applications, especially automation systems. The latter applications, like many running safety-critical or production systems, require a real-time, deterministic and reliable behaviour of the underlying network. Now, if we talk about allowing IoT applications to access data all the way from the devices, or services at the edge, network resources become one essential resource that needs to be managed among the different application needs.

The approach adopted and advocated in the IoT@Work project is cantered on dynamically requesting, and deploying a virtualized network which can describe constraints such as those of automation applications, while offering full isolation of each application domain from unwanted interferences, non-allowed access, or greedy communication behaviour. We call the virtual network per application domain or organization a “slice”.

Essentially, this provides virtual networks which can be created on-demand laid-out next to each other on the same physical networking infrastructure, while fulfilling Quality-of-Service and security policies associated with each of them. The concept is not a priority-based approach like DiffServ, nor a per-flow reservation concept like IntServ or alikes ([14], [15]). Our idea has some similarities with an MPLS based engineered network as shown in [16]; however we borrow ideas from the DiffServ/IntServ to build a more flexible interface for applications and the network management. As such, the concept unifies and integrates current QoS approaches by providing a clear separation of the user interface, a management and control layer and the actual network.

Our approach also adds intelligence to optimize and manage the network resources on the fly and not just by means of offline traffic engineering. The result is a managed portioning of the network, with clear service guarantees and associated policies, something we call 'slice'.

The communication plane integrates, besides the network slicing system, another higher layer functions dealing with providing a semantically programmable message bus – the Event Notification Service (ENS). The way these communication services are orchestrated upon configuration of different applications is demonstrated through the bootstrapping process already discussed Deliverable 2.3 [2].

04/07/2013 Pag. 33 IoT@Work/WP1/D1.3/1.0


3.1.2 Security Plane

The security plane defines the functions that are involved in the configuration of security related policies, which are used to secure both the infrastructure (embedded security functions) and the configuration and application interactions with that infrastructure (e.g., through capability-based access control). These functions are intertwined with the management actions taking place during configuration and also making sure that the application and infrastructure are protected from security threats. In this document, we are concentrating more on the interdependencies between some of the configuration steps required for performing security checks. The bootstrapping phases and networking functions are designed in a way to also provide mechanisms to enforce security policies. Therefore, when a device is first introduced in the infrastructure, it is assigned to a limited slice0. This could be also the fallback slice when an intrusion is detected. The same applies to configuring an application: the capability-based access control for publishing and subscribing to the ENS message bus allows controlling who is listening to or is publishing the data that is produced from the factory infrastructure. This access control envisages also the definition of a Policy Decision Point and a Revocation Service to respectively check the validity and enforce the revocation of the issued capabilities (this has been explained in deliverables D1.2 and D3.2).

3.1.3 Management Plane

The IoT@Work architecture suggests that it is possible to isolate application domains so that different applications interacting with a given device or a thing do not have to influence each other neither during their configuration nor during their operation. In comparison with today’s configuration tools that detail for each machine or sensor in the factory a whole range of configuration data during design phase, we isolate each application interacting with a given device and define configuration steps separately for each single application on its own. In IoT@Work, we have focused on the cohabitation between existing state of the art applications, such as controller systems, with newer types of IoT applications. The core of the application and device plane is a set of supporting functions that enable a device to be part of both legacy systems and newer types of IoT applications at the same time. For this purpose, we could list the following enabling technologies placed within this plane:

Plug and Work functionality using a web service that allows more self-configuration of automation devices and systems, and offering a gateway technology to data originating from automation systems.

Event notification system offering a transport and distribution mechanism for semantically annotated events, enabling a new range of event-driven and semantically-aware IoT applications, decoupled from the devices providing the raw real-time data.

Complex event processing as both a subscriber to events, and publisher of new events after applying some filtering logic and using different event name spaces.

The possibility to track things and their embedded services using a directory service independent of any legacy technology and capable or presenting a common interface and intermediate point to all functions requiring to track device and service status.

Besides these specific technologies addressing the needs of IoT applications and increasing the flexibility and self-management of devices (through plug&Work functionalities), IoT@Work also addresses the interactions between the different

04/07/2013 Pag. 34 IoT@Work/WP1/D1.3/1.0


planes such as dealing with security and communication needs of both devices and applications. For instance, the application programmer or automation planning tools are offered an interface to request the creation or extension of a QoS-capable virtual network organization around the context of any application, even from a remote site. In addition to this, the specific functions securing the configuration of a device and then checking the authorization of applications to interact with a given service or access a certain resource can interfere with the configuration and operation of an application. The interdependencies between the planes are described through interactions through well-defined interfaces between given functions in different planes. Some of these interdependencies include some user-defined needs or policies. They are also dictated by the nature of the expected life-cycle of the applications, and devices in an IoT@Work-enabled system, which could include:

1) the bootstrapping of a device and several types of applications related to that device.

2) the extension of the system through the addition of a device or a new application.

3) the isolation of a device for purposes of maintenance or due to errors such as “security attacks”.

3.2 Functional Decomposition of the IoT@Work Architecture

3.2.1 Event Notification Service

Here we recall what was already provided in D1.2 regarding the IoT@Work main architectural components to give the IoT@Work complete and final architectural design. In the following the presentation is organized as the one in D1.2 starting from a point of view independent from a layer or plane structure. From this point of view the IoT@Work architecture is made up of a set of interacting components that provide a set of specific functionalities. Some components are actually an assembly of more elementary components. In the following paragraphs the components are described according to the following high-layer functionalities:

3.2.1.1 Overview

The following paragraphs will give detailed information about the components which make up the Event Notification Service (ENS Services in Figure 3-3).

The Event Notification Service (in the following ENS) is the IoT@Work functional

component that acts as a common collector and distributor of events. These events

come from disparate sources (event publishers/producers) and are dispatched to

applications that have expressed their interest to receive specific subsets of events

(event subscribers/consumers or simply Subscribers/Consumers). The publishers

and subscribers can potentially be located in disparate sites belonging both to the

manufacturer or, even, to external subjects (e.g. suppliers, maintainers, etc.) as

depicted in Figure 3-4. From a functional point of view the ENS is similar to an

asynchronous messaging middleware service, even if it could be better considered

as an active component of an Event-Driven Architecture as it fully supports the key

features of that paradigm (e.g.: Broadcast communication, Timeliness, Asynchrony,

etc.).

04/07/2013 Pag. 35 IoT@Work/WP1/D1.3/1.0


Figure 3-4 – Overview of the ENS approach

The proposed approach, therefore, brings the data to the interested parties, instead of bringing the parties to the data. This reversed approach in data provision significantly improves system scalability and security, because it allows for a fine-grained control on what data are provided to whom and decouples the event producers from the event consumers.

04/07/2013 Pag. 36 IoT@Work/WP1/D1.3/1.0


3.2.1.2 ENS Architecture and Services

The following picture sketches the architecture of the ENS.

Figure 3-5 – ENS Architectural Components

The ENS architecture has been designed by taking into account the flexibility, scalability and security requirements manufacturing contexts require as formalized in the IoT@Work requirements. Indeed, it is based on OASIS AMQP (Advanced Message Queuing Protocol) that is a vendor-neutral and platform-agnostic standard for message-oriented middleware that defines both a network application protocol and a data model that guarantees interoperability between different implementations. AMQP allows for a flexible, highly scalable and more secure approach to exchange near-real-time data streams. It is being adopted in many contexts (e.g.: Finance, Stock Exchange, Cloud Computing) and able to operate even on Wide Area Network. Furthermore, it supports several message exchange patterns and ensures payload transparency. Therefore, adopting this kind of protocol ensures the usage of an up-to-date and widely adopted technology that better suits IoT@Work requirements. The ENS adopts AMQP not only for collecting and dispatching events, but also for managing publishing and subscribing requests thus avoiding the burden of defining new transport protocols able to handle scalability issues.

In order to implement its functionalities, the ENS relies not only on the AMPQ standard, but also on the capability-based authorization, the latter for managing access to the ENS server both for publisher and subscriber applications and services.

Network

DevicesPLCs Monitoring

Application XX

MonitoringApplication YY

ENS Broker Service

Robots

Events

Monitoring App A

Monitoring App B

Event Analysis

Engine

ENS Authorization Service(ENS AuthService)

Policy DecisionPoint Service

CapabilityRevocation Service

Even

ts Even

ts

Even

ts Stream

Events Stream

Events Stream

ew

ENS Access Request

Broker Service

04/07/2013 Pag. 37 IoT@Work/WP1/D1.3/1.0


3.2.1.3 AMQP broker and Virtual Host concept

The AMQP standard envisages the Virtual Host concept that is1 “… a collection of exchanges, message queues and associated objects. Virtual hosts are independent server domains that share a common authentication and encryption environment. The client application chooses a virtual host after logging in to the server”. An AMQP physical host provides at least one Virtual Host. Virtual Hosts are therefore key elements to support scalability, reliability and clients partitioning, and are widely used within the ENS to support the following features:

o event dispatching scalability and reconfiguration flexibility: events within the ENS are aggregated in distinct namespaces. ENS namespaces are associated to a specific AMQP Virtual Host so that namespace’s resources can be easily upgraded or expanded simply moving its Virtual Host without affecting other functionalities;

o management of authentication and access control: in order to not add overhead to Virtual Hosts devoted to manage ENS namespaces, the access requests to the ENS middleware are managed by a specific AMQP Virtual Host (see ENS Access Request Broker Service in Figure 3-5). All ENS clients (i.e. publishers or subscribers) therefore firstly connect to this Virtual Host presenting a specific access request that includes the specification of the ENS namespace the client wants to access, their authorization capability, the proof of ownership and the operation the client wants to perform (i.e.: publish or subscribe). The ENS Authorization Service, which acts as a subscriber from the ENS Access Request Broker Service point of view, checks the request and replies positively or negatively. For positive answers the response conveys information the client must use to connect to the specific Virtual Host (see ENS Broker Service in Figure 3-5) managing the requested namespace. The requesting client then connects to the specific Virtual Host to publish, if it access request was as a publisher, or to receive events, in the case of a subscriber.

3.2.1.4 ENS Authorization Service

The ENS Authorization Service has the role of controlling access to the ENS checking the access requests sent via the ENS_Access_Request_Broker_Service Virtual Host. The figure below shows the internal architecture of the Authorization Service.

1 AMQP Working Group, "AMQP - A General-Purpose Middleware Standard", Version 0-10, February 2012 (http://www.amqp.org/sites/amqp.org/files/amqp0-10.zip)

04/07/2013 Pag. 38 IoT@Work/WP1/D1.3/1.0


Figure 3-6- ENS Authorization Service Architecture

The ENS Access Request Broker has a dedicated AMQP Queue that is used to encode access requests to be processed by the ENS Authorization Service; the outcomes of the access requests processing are sent by the ENS Access Authorization Service to the requesting client using the same AMQP Virtual Host (see the red bidirectional arrow between the ENS Access Request Broker Service and the ENSAuthReqProcessing in Figure 3-6).

The request is processed and evaluated using a capability-based authorisation mechanism (for more detail about the Capability authentication mechanisms see D3.2). The NSAuthSrvPDPint module in Figure 3-6 is in charge of supporting the communication with the PDP for the evaluation duties in charge of the PDP.

If the access request is accepted, the ENS Authorization Service creates ad hoc, temporary AMQP elements and corresponding access granting (e.g.: the receiving AMQP queue and AMQP binding for a subscriber) for the requesting client on the Virtual Host in charge of managing the ENS namespace indicated in the request (see the red arrow between the ENSAuthReqProcessing module and the ENS Broker Service in the figure above).

3.2.1.5 ENS Namespaces

The ENS uses namespaces to organize the published events. A namespace is devoted to organize a specific set of events independently from other namespaces and relating to specific needs and/or scenario (for example data that reports energy consumptions of production devices can be organized in a specific namespace named Energy Monitoring Namespace).

In order to provide to ENS subscribers flexibility in identifying subsets of events in a given namespace, each namespace has a hierarchical structure (see Figure 3-7) that

04/07/2013 Pag. 39 IoT@Work/WP1/D1.3/1.0


is functional to production needs only. Therefore each namespace can be represented by a tree structure.

Each publisher publishes its events for a specific namespace under a well defines leaf node. As events can be generated only by entities (e.g. shop floor devices or even applications), leaf nodes in namespaces represent “physical” entities.

Figure 3-7 - An example of IoT@Work ENS namespace

Intermediate nodes in a namespace, instead, represent aggregations or virtual entities that are useful to simplify subscribers “area of interest” within a given namespace.

The way nodes, both leaf and intermediate, are identified in different namespaces are potentially completely uncorrelated. Therefore while leaf nodes, which are tied to physical objects, are normally named in the same way in different namespaces, intermediate nodes, as well as the namespace hierarchy, can be completely different among namespaces.

Figure 3-8 highlights an example of events’ publishing by a physical object (in the figure a robot of Model NG-X1 and identified as PC1C1Rob1) under an energy monitoring namespace.

Figure 3-8 - IoT@Work ENS namespace publishing

04/07/2013 Pag. 40 IoT@Work/WP1/D1.3/1.0


The events at lower hierarchical levels are aggregated at each upper level. Therefore a subscriber to an intermediate node will receive events of all dependent nodes. Figure 3-9 for example exemplifies such kind of subscriptions; indeed a subscriber that specifies as the namespace’s subset of its interest something like “Energy Monitoring.*.Cell P1C1” will receives all events published under the leaf nodes of “Cell P1C1”.

Figure 3-9: IoT@Work ENS namespace subscription to a branch

Figure 3-10 instead exemplifies a more complex events’ subscription where a subscriber is interested to all events generated by robots of a specific model (“Model NG-X1” in the figure). To this end the subscriber declares to the ENS as the events’ subset of its interest in this namespace something like “Energy Monitoring.#.Robots.Model NG-X1”.

Figure 3-10: IoT@Work ENS namespace subscription to a more complex subset

As evident from the above discussion and examples, in IoT@Work ENS namespaces naming is a crucial elements for efficiently managing events’ filtering and aggregation, even if our system doesn’t mandate specific constraints regarding the naming hierarchical structure and name contents apart from avoiding using meta-

04/07/2013 Pag. 41 IoT@Work/WP1/D1.3/1.0


characters (i.e. characters having special meanings like “.”, for structuring the naming hierarchy, and ”*” or ”#” for expressing filtering).

3.2.2 Slice Management System

3.2.2.1 Rationale

This deliverable describes the architecture of this slice of the network, including the interface between a service enabling this virtual network, called the Communication Service Interface (CSI) and applications using it. For illustration and to prove that implementations are feasible, in many cases hints or examples are given for the Linux operating system, however the basic principles can be also implemented based on other operating systems such as Windows or MacOS as well.

An application for the purpose of this discussion is a piece of SW, distributed across a network (distributed service). The SW can be considered as a set of IP end points with the need to communicate with a certain service level. A network is a set of IP and/or OSI layer-2 devices (i.e. routers or switches) interconnected by physical links which can route messages (packets) and can apply constraints on those messages.

Now the task is to enable someone to configure the network in a way that the service level requirements of applications are met. Contrary to traditional network management and configuration interfaces, this interface shall be significantly more abstract and hide the complexity of the underlying network.

More abstract, we have a service provider (the network), a service consumer (the application) and a management instance that captures the applications request and can map it to the correct slice offered in the network. This deliverable describes and discusses the interface between these parties, namely the Communication Service Interface (CSI).

TL

LL

Application

View

Slice View

Physical

Network View

Slice

Entry

L

L

T

L

L

L

Communication

Service Interface

configuration

live monitoring

device/topology detection

Application 1

T L

Application 2

L

Slice

Intermediate

Node

04/07/2013 Pag. 42 IoT@Work/WP1/D1.3/1.0


The general idea behind the IoT@Work Quality-of-Service concept is to combine the strength of a traffic engineering approach with online (near real-time) resource management and optimizations.

CS domain controller

(slice management)

device

slice

end

points

integrated

SEP edge

SEP

Figure 3-11: Communication-slice domain.

The pillars of the IoT@Work approach are:

Guaranteed QoS by means of resource reservations instead of relative priorities (although the guarantees may be implemented by using priorities on a link).

Decoupling of concept and implementation. Unlike DiffServ/IntServ we do not mix the QoS capabilities of the IP or Ethernet layer with the interface to the higher layers. Thus we can provide a solution that works over a wide range of technologies and topologies, including existing Industrial-Ethernet standards. It also means that we can operate over a mix of layer-3 and layer-2 networks.

Central management takes into account actual resource availability as well as application networking needs such as QoS, reliability and service importance. Central management can provide optimizations that are hard or impossible to achieve using a distributed hop-by-hop reservation scheme. It should be noted that central management does not necessarily require a central implementation; distribution by means of domain controllers and device agents is possible and will be considered. A slice can be defined for aggregates rather than just-per-flow reservations.

Path manipulations as an additional means to achieving the traffic engineering goals. This means that we do not rely on underlying routing/forwarding algorithms but that the network user takes her own path selection decisions.

3.2.2.2 Components

IoT@Work’s communication infrastructure consists of several components and functions (Figure 3-12):

A 'slice' is a virtual network having QoS guarantees but also associated policies.

The 'Communication Service Interface' (CSI) provides an API for requesting and using a service. The CSI is also responsible for creation of a communication-service entry point for the application flow.

The 'Slice Enforcement Point' (SEP) is an agent which bundles policy enforcement, traffic shaping, and packet marking. A SEP is normally part of a native IoT@Work device and accessed by the device local CSI. However, in order to support unmodified legacy devices, it can also be placed at the edge of a managed network (see also Figure 3-11).

04/07/2013 Pag. 43 IoT@Work/WP1/D1.3/1.0


The 'Slice Manager' is a management station operating on an abstract network graph, which represents the real network and its resources. It is responsible for a part of the network, thus this is a centralized management.

The Physical Network is comprised of end and network devices and links. Network nodes might include their own intelligence in the sense of protocols and configurations and management interfaces. We distinguish between native IoT@Work devices and legacy devices. Native devices are equipped with at least a SEP, optionally also with a device-local CSI. They are able to participate in multiple slices simultaneously. Legacy devices do not have any IoT@Work specific parts and can only be attached to one slice.

Network Management & Control

CS Slice Management

CS API

App

Profinet other Ethernet ZigBee Drivers for various

Standards

access to the

physical devices

resource management

user management

unified view

applications and

management

consoles

Slice Enforcement Pointpolicy enforcement

traffic shaping and marking

Figure 3-12: Slice System Layers

This structure is similar to that of a file system: the file system provides the API (== CSI), which allows constructing and using files. It also provides a file system (== Slice Layer), which manages user rights and resources, and which also maps the files to the hard disks which. The file system hides internal implementations of the underlying devices. These hard disks thus have their specific low-layer drivers (== Physical Network).

A slice is a virtual network with associated resources, paths and policies. When an application (or a management station) requests a slice, it essentially establishes a service-level agreement (SLA) with the Slice Manager. That is, if the request can be fulfilled, the Slice Manager guarantees the requested QoS. The Slice Manager also establishes policies and enforces these policies. A slice features a minimum QoS and an upper bound for resource usage.

Another important feature of IoT@Work networking is that the network managed by the slice management starts with the local network interface of a device, meaning the slice, and thus the QoS engine and the policy enforcement, starts within a device. This is possible because we assume managed devices owned and controlled by the operator of the network.

3.2.2.3 Slice Manager Internal Architecture

The slice management system introduces two main components, one centralized “slice manger” (SM), which deals with a single network infrastructure, and one slice enforcement point (SEP) per managed node. Each SEP acts as an agent for collecting the internal functions and topology information of each node. The SEP also reports a node-abstraction model to the SM. This model is independent of the node-internal functions. The node could be an end device hosting applications or a networking node. This abstraction could be a list of active interfaces and neighboring SEPs. The main functions at the SM are extensions of already known networking functions, such as link-state or topology-discovery functions. Other functions and also

04/07/2013 Pag. 44 IoT@Work/WP1/D1.3/1.0


databases are introduced for creating and managing the notion of slices. They are internal elements of the SM and as such may be implementation specific and are briefly listed her to explain which information is available and used within the SM.

Topology db: detects automatically the network topology and creates a graph of nodes and links.

Link-state db: holds properties of a link (e.g., max bandwidth) and the actual state (e.g., utilization).

Reservation db: holds active reservation parameters for a slice, e.g., bandwidth and path.

Path Finder: responsible of finding a path that fits to the desired criteria for a new slice. This is the main intelligence. It can utilize optimizations when finding paths.

Slice Creator: the interface to the underlying network. Orchestrates the path defined by the Path Finding component.

User Management: the slice-management side of the CSI plus a db for active slices.

Service Management: allows controlling, managing, and monitoring the slice services, e.g. create/restart/tear down, list slices, and more.

Network Abstraction: a component that provides a unified, technology-independent interface for the above components and that contains “drivers” for various network technologies.

Visualization console: an interface for visualizing the state and the operation of the slice management (optional component).

Network Driver Layer: all protocol and device specific issues, i.e. the signaling protocols to a SEP, are bundled into separate components which provide a unified view to the SM internal functions hiding differences of external components. This is an important architectural decision to allow management of heterogeneous devices and protocols. This layer implements the "physical network layer" as described above.

The SM may contain additionally interfaces to other tools. And as said, these internal components shall not mandate a certain implementation. For example in the IoT@Work demonstrator, the topology db is not explicitly bundled in a SW component, but a so-called "adaptor pattern" provides an interface to various internal places to implicitly construct a topology view.

3.2.3 Non-Slice-Related Infrastructure Components and Deployment Issues

For normal operation, various other communication-oriented services must be available. These include IP-layer configurations (DHCP), a Domain Name Service, a time service (e.g. IEEE 1588 based), and more.

Notice that the slice concept typically leads to a much higher number of IP addresses than traditional approaches, since each slice interface will feature one or more IP addresses. This is not a really scalability problem but must be considered during DHCP and DNS configuration.

The auto-configuration of IP addresses or symbolic names of an end point can be controlled by DHCP and DNS. To assign slice-specific IP addresses, DHCP must be able to recognize the end point or the slice of this end point. This can be done if the DHCP request contains the slice ID, but this requires changes or configurations of the device-local DHCP client. A much simpler solution is to provide separate DHCP

04/07/2013 Pag. 45 IoT@Work/WP1/D1.3/1.0


servers per slide. Auto-configuration of IP addresses may encode the slice ID. This is especially easy and recommended for IPv6 addresses

Other complementary components, such as network-monitoring systems, are not discussed here, since they are not affected by slices.

3.2.4 ENS Namespace Management Service

The ENS namespaces introduced in section 3.2.1.5 are managed through a web service that provides a RESTful interface. The actions that can be performed are:

retrieving the list of all namespaces

creation and deletion of namespaces

modification of namespace data

managing the structure of a namespace (insert, modify, and delete nodes)

managing the association of X.509 certificates to the namespaces.

The following table details how the actions above are mapped onto the operations provided through the RESTful interface of the namespace management service.

URL PATTERN METHOD DESCRIPTION INPUT OUTPUT

http://ens-namespace-manager /namespaceList

GET Return the list of all namespaces

- 200(JSON, 400, 404, 500

POST Create a new namespace

JSON Object (name, description)

201, 400, 409, 404, 500

http:// ens-namespace-manager /namespaceList/ <namespaceName>

GET Return namespaceName’s data

- 200, 400, 404, 500

DELETE Delete namespace namespaceName

- 204, 400, 404, 500

PUT Update namespaceName’s data

JSON object (name, description)

204, 400, 404, 409, 500

http:// ens-namespace-manager /namespaceList/<namespaceName>(/<nodeName>)+

GET Retrieve nodeName’s data

- 200 (JSON), 400, 404, 500

DELETE Delete nodeName - 204, 400, 404, 500

PUT Update nodeName’s data

JSON object (name, description, uri, entityURI)

204, 400, 404, 409, 500

http://myHost:myPort /namespaceList (/<namespaceName>| (/<nodeName>)+) /children

POST

Create namespaceName’s root OR a new nodeName child node

JSON object (name, description, URI, entityURI)

201, 400, 404, 409, 500

http://myHost:myPort /namespaceList /<namespaceName>/CertificateList

GET

Return the list of the trusted subjects’ X.509 certificates associated with namespace namespaceName

200 (JSON), 400, 404, 409, 500

POST Add a new trusted subject’s X.509 certificate to the

X.509 Certificate

201, 400, 404, 409, 500

04/07/2013 Pag. 46 IoT@Work/WP1/D1.3/1.0


namespace namespaceName

http://myHost:myPort /namespaceList /<namespaceName> /CertificateList /<CertificateID>/

DELETE

Remove the certificate identified by CertificateID and associated with namespace namespaceName

204, 400, 404, 500

Legend: * = 0 or more + = at least 1 (A|B) = either A or B (exclusive) JSONfield = mandatory field

Table 3-1 - ENS Namespace management service RESTful API

The following list explains the meaning of the HTTP status codes returned by the namespace management service:

200, if the data retrieval has succeeded;

201, if a new entity (i.e. a namespace, a new namespace node or a new

X.509 certificate) has been successfully created;

204, if the data of an entity (i.e. a namespace or a namespace node) have

been successfully updated or an entity (i.e. a namespace, a namespace node

or a X.509 certificate) has been successfully deleted;

400, if the request body is malformed;

404, if the specified URL does not identify any entity;

409, if the new entity or the updated information is in conflict with the existing

entities;

500, if an error has occurred while fulfilling the request.

The X.509 certificates associated to an ENS Namespace are the only one that can be used to sign the root capabilities granting rights on that namespace. As the X.509 certificates are also used to prove the identity of the capability issuer, the certificate subjects are considered trusted subjects by the namespace management service. These X.509 certificates are at the start of any authorization chain as represented within an ENS access capability, and are actually the only ones the ENS has to trust even independently from the access capability delegation chain and the number of signers involved in the delegation chain.

3.2.5 Embedded application configuration service

A native IoT@Work device provides an OPC UA address space that consists of an OPC UA information model. Such an information model describes metadata and profile about the device and its application process. The model is based on hierarchical arrangements of nodes and their relationship to each other. Nodes are representing types, characteristics, configuration and behaviour of the device. It is essential to provide a mapping of device information model to the DS data model for seamless propagation of device application services throughout the system.

The DS data model, therefore, is a connected and directed graph in which nodes (vertices) represent entities, both physical and virtual ones, or primitive elements, and edges store the relationships. All concepts in the DS data model have been taken from ontologies.

04/07/2013 Pag. 47 IoT@Work/WP1/D1.3/1.0


The DS may act as a proxy to an OPC UA device in the sense that it may expose (a subset of) the OPC UA device profile, enriched with semantics according to predefined mappings. This mapping process can be performed in two ways:

On demand, when the DS is enquired for data reported in an OPC UA profile. The OPC UA client module of the DS connects to the respective OPC UA server at the production unit. It browses through the information model using

OPC UA native service primitives (see getOPCUAInformationModel

operation in Figure 3.13). Finally, an Address Space Profile is generated and returned to the client. Such OPC UA profile is semantically annotated and formatted according to the media type specified in the initial request. Finally, the formatted semantic profile is returned to the DS enquirer. This approach can employ a cache where the annotated profiles are stored: cached profiles need be updated only when the OPC UA profile changes.

On bootstrapping, during the device configuration phase (Figure 3.13). Configuration agents detect the presence of a new device and asynchronously activate the DS Client. This client, through its OPC UA client, enquires the newly plugged device to gather its Interoperable Profile (i.e., a profile compliant with an ad-hoc XML schema that defines an information model shared between the OPC UA Information Model and the DS Data Model). That profile is submitted to the DS where it is annotated semantically and stored in its own NoSQL database.

The first integration option requires an OPC UA Client module on the DS and ensures that the OPC UA-related data are always up-to-date. As the DS manages semi-permanent information, it might be awkward to enquire the OPC UA server every time a request is received, even if the usage of a cache can mitigate this issue. The second integration option is in line with the semi-permanent data storage features provided by the DS and does not require an OPC UA client on the DS. It requires that, every time the OPC UA data are updated, also the device profile on the DS must be updated. Furthermore, the second approach introduces an XML Schema defining an interoperable model, to support the translation from a subset of the OPC UA Address Space Profile into the DS Data Model.

04/07/2013 Pag. 48 IoT@Work/WP1/D1.3/1.0


Figure 3.13 Interaction between OPC UA devices and Directory Service

Figure 3.14 Bootstrapping interaction between OPC UA devices and DS

3.2.6 Directory Service

3.2.6.1 Purpose and Architecture Overview

The IoT@Work Directory Service aims at quickly provide, via a common access

point, a set of information on a given entity (or even service) deployed in the

manufacturing plant. The quickly term has been used to highlight that this service has

to be accessible not only via traditional access means (i.e. browser on a PC and

URL), but also using more intuitive means like pointing the device for which I need

the information (see Figure 3-15), so that it can be more effective in a production

Directory Service (DS)

DirectoryServiceClient RESTInterfaceManager SemanticAnnotator OPC UA Server

getOPCUAInformationModel( Entity URI )

OPC UA Address Space Profile

convertIntoRDF( OPC UA Profile )

Semantic Profile

Output Formatter

format( Semantic Profile, Accepted Content Type )

Formatted Semantic Profile

OPCUAClient

OPC UA Profile

GET( Entity URL, Accepted Content Type )

DirectoryServiceEnquirer

getProfile( Device ID )

getOPCUAProfile( Entity URI )



New deviceConfiguration Service (triggered when a new device is plugged in)

DirectoryServiceClient RESTInterfaceManager

POST( Parent URL, Interoperable Profile )

Semantic Annotator

Semantic Profile

OPCUAClient OPCUAServerProfileConvertor

getOPCUAInformationModel( Entity Point URI )

OPC UA Address Space Profile

convert( OPC UA Profile )

NoSQLDBMS

store( Semantic Profile )

annotate( Interoperable

Profile )

Interoperable Profile

Directory Service (DS)

getProfile( DeviceID )

DeviceConfigurator

OPC UA Profile

store( Parent URL, Interoperable Profile )

04/07/2013 Pag. 49 IoT@Work/WP1/D1.3/1.0


environment in which people (workers, or line supervisors) can acquire those

information while moving in their working environment using a mobile device (phone,

tablet, etc.). This system is actually made up of a service, which constitutes the more

complex and relevant part and exposes a RESTful API, and a client element. For

desktop or laptop PCs the client element can be a simple web browsers (or any other

application that can use a RESTful API), while for mobile devices an ad-hoc Android

app has been developed. This app is able to identify devices using QR codes or NFC

tags.

Figure 3-15 – IoT@Work Directory Service

The IoT@Work Directory Service was designed as a RESTful service to easy the potential reuse of the information; therefore each entity managed by the service is a resource accessible via a specific URL and the service can provide different representations (e.g. HTML, XML, JSON) of the provided data according to the needs of the requesting client.

The information provided by the IoT@Work Directory Service for each managed entity is, as it is usual for a directory service, the one that characterize and describes the objects (e.g.: its name, device type, location, available services, etc.). The managed entities can be layered as follows:

physical entities: these are objects (Things) deployed within the production environment that are characterized by having not only a digital ID (i.e. something that identifies them within the IoT@Work digital environment), but also some physical counterpart;

<<<<<<

Iden

tify

ob

ject

IoT@WorkDirectory Service

1

HTTP GET obj info

2

3

Object Info

04/07/2013 Pag. 50 IoT@Work/WP1/D1.3/1.0


virtual entities: objects that have an identity but do not have a physical counterpart. For example virtual entities can represent application services, locations, etc.;

relationships: links between objects that conveys information about objects;

primitive elements: basic data type (e.g.: numbers, strings, URLs, etc.);

For each non-primitive entity the DS envisages a set of “standard” relationships and, specifically, the following ones:

contains: to manage containment relationships (e.g.: “Production Cell A contains Robot X”, “Robot X contains Welder Xzz”);

availableService: to manage application services available for the Subject node (e.g.: “Robot X availableService Energy Monitoring”, “Robot X availableService Remote Control”).

An entity can, of course, have more than one of these relationships; while if an entity does not contain other elements or has no service active on it, one or both of these relations will be absent. Figure 3-16 sketches the IoT@Work Directory Service data model that is in line with the T-Engine Forum uCode Relation Model and W3C RDF (Resource Description Format).

Figure 3-16 – IoT@Work Directory Service Data Model

Figure 3-17 provides an overview of the architecture of the IoT@Work Directory Service whose components can be summarized as follows:

REST Interface Manager: this element manages the service’s RESTful API. It therefore receives requests (HTTP GET/PUT/POST operations) from the external entity (e.g. external application, Mobile device, etc.) and provides as output the required information according to the needs of the requesting client. Details of the RESTful interface will be presented in the subsequent chapter.

04/07/2013 Pag. 51 IoT@Work/WP1/D1.3/1.0


Request Manager: this module deals with the handling of request. Verify that the request received in input is a valid request or not and interacts with the Query Manager to retrieve the necessary information.

Query Manager: the Query Manager is the module responsible for communication with the database or with the physical external entities2. According to the data provided by the Request Manager, retrieves from the database all the necessary information to the Directory Service to provide an answer.

SNMP/OPC UA Client: these are functional elements used to actually acquire information from external devices that support one of the indicated protocols (SNMP or OPC UA).

OPC UA Data Model/SNMP MIB to OWL Converter: these functional elements map the OPC UA and SNMP MIB data models data to corresponding ontology concepts.

Semantic Annotator: in this module, the data directly acquired from the physical devices are semantically enriched.

Output Formatter: the output formatter is responsible for formatting the data according to the required format specified in the request.

Configuration Manager: module that manages the configuration parameters of the IoT@Work Directory Service. These parameters can be modified through a web application.

Figure 3-17 – IoT@Work Directory Service architecture

In our project the entities are basically network and production devices thus the set of information handled by the DS can be defined as a semantically enriched device profile.

2 In order to minimize the replication of information, some data (e.g.: exposed services for an OPC UA device) could be directly retrieved from the device instead of being replicated into the IoT@Work Directory Service database. From an architectural point of view the service envisages the possibility to directly pick up some data from the external device (even if this feature has not been actually implemented)

AJAXGUI

ServiceManagement

ExternalApplications

MobileAccess

RequestManager

ConfigurationManager

ServiceConfig

Database

Static ElementsDatabase

Browser Access

Plant Network

NAC Service

Output Formatter

REST InterfaceManager

SNMPClient

OPC-UAClient

Query Manager

SemanticAnnotator

OPC-UA Data Mod.to

OWL Converter

SNMP MIBto

OWL Converter

SNMP Query

OPC UA Query

Device Discovery Notification

OntologiesDatabase

04/07/2013 Pag. 52 IoT@Work/WP1/D1.3/1.0


In order to ease the navigation of the DS through its REST interface, we have defined some aggregating resources that include devices of the same type (e.g.: robots, conveyors, routers, etc.) and information categories that split the profile into self-consistent parts that can be separately accessed and managed. Furthermore, the DS database contains a taxonomy of the device types that allows for checking that a new device profile is inserted as child of the appropriate device.

3.2.6.2 Read

The information provided by the DS through an HTTP GET request can be divided into the following categories:

Top level information: by submitting an HTTP GET request to the URLs in the following format, the DS returns the list of the information categories for which there are data in deviceID’s profile and the list of the device types contained by deviceID.

http://iot-ds.iot-at-work.eu/<root>(/<containedDeviceType>/<deviceID>)*

* = 0 or more

List of contained devices: by submitting an HTTP GET request to the URLs in the following format, the DS returns the list of the URLs of the profiles related to the devices whose type is containedDeviceType.

http://iot-ds.iot-at-

work.eu/<root>/<containedDeviceType>(/<deviceID>/<containedDeviceType>)*

* = 0 or more

Detailed information: by submitting an HTTP GET request to the URLs in the following format, the DS returns the data related to the category categoryName. The available information categories are:

Inventory information such as name, description, model, manufacturer, etc. (GeneralInfo in the URL);

Location expressed as an absolute value (e.g.: address, name of the building, room, etc.) or coordinates related to a specific coordinate system (Location in the URL);

Services that lists the services provided by deviceID (Services in the URL)


work.eu/<root>(/<containedDeviceType>/<deviceID>)*/{GeneralInfo,Location,Services}

* = 0 or more

Service information: by submitting an HTTP GET request to the URLs in the following format, the DS returns the data related to service serviceName.


work.eu/<deviceID>(/<containedDeviceType>/<deviceID>)*/Services/<serviceName>

04/07/2013 Pag. 53 IoT@Work/WP1/D1.3/1.0


* = 0 or more

The representation types of the returned data supported by the DS are:

JavaScript Object Notation (JSON)

XML serialization of the Resource Description Framework (RDF)

HTML enriched with RDF annotations (RDFa) The HTTP response codes returned by the DS are:

200 if there are data related to the entity identified by the given URL

404 if there is no entity identified by the given URL

500 if an error occur on the DS while trying to fulfilling the request

3.2.6.3 Create

You can create new device profile by submitting an HTTP POST request whose body is a JSON file or an XML document compliant to specific formats. The URLs you can submit such requests are the one compliant to the following format:

http://iot-ds.iot-at-work.eu/<root>/<containedDeviceType>

(/<deviceID>/<containedDeviceType>)*

* = 0 or more

Furthermore you can add a new service to an existing device profile by submitting an HTTP POST request with a JSON body to the URLs compliant with the following format:

http://iot-ds.iot-at-work.eu/<root>/<containedDeviceType>

(/<deviceID>/<containedDeviceType>)*/Services

* = 0 or more

The actual type of the device has to be the last occurrence of containedDeviceType in the URL.

The HTTP response codes returned by the DS are:

201, it the device profile has been added. The response contains the URL of the newly created resource

400, if the JSON file or the XML document is not compliant with the expected document structure

404, if the device type indicated in the URL is not envisaged by the taxonomy included in the DS database

405, if the resource identified by the URL does not support POST requests (i.e. it is not a containedDeviceType or a list of services)

409, if the device profile or service has been already inserted

500, if a DS internal error has occurred while fulfilling the request.

04/07/2013 Pag. 54 IoT@Work/WP1/D1.3/1.0


3.2.6.4 Update

You can update the data related to a specific part of the device profile by submitting an HTTP PUT request with a JSON body to the URLs that are compliant with the following format.


work.eu/<root>(/<containedDeviceType>/<deviceID>)*/{GeneralInfo,Location}

* = 0 or more

You can update the data of a specific service (e.g. serviceName) by submitting an HTTP PUT request with a JSON body to the URLs that are compliant with the following format.


work.eu/<root>(/<containedDeviceType>/<deviceID>)*/Services/<serviceName>

* = 0 or more


204, it the data have been successfully updated

400, if the JSON body is not compliant with the expected structure

404, if there is no resource for the specified URL

405, if the resource identified by the URL does not support PUT requests (i.e. it does not reference the inventory information or location section of the device profile or a service provided the device)

409, if the update is in a conflict with the data already stored in the DS database.


3.2.6.5 Delete

The DS supports the deletion of the device profiles and services one by one. You can delete device profiles by submitting an HTTP DELETE request to the URLs compliant with the following format:

http://iot-ds.iot-at-work.eu/<root>(/<containedDeviceType>/<deviceID>)+

+ = at least 1

If the deleted profile points to other profiles, also the pointed ones are deleted.

You can delete a service entry by submitting an HTTP DELETE request to the URLs compliant with the following format:


work.eu/<root>(/<containedDeviceType>/<deviceID>)+/Services/<serviceName>

+ = at least 1


04/07/2013 Pag. 55 IoT@Work/WP1/D1.3/1.0


204, it the data have been successfully deleted

404, if there is no resource identified by the specified URL

405, if the resource identified by the URL does not support DELETE requests (i.e. it does not reference a device profile or a service)


3.2.6.6 Query interface

The DS REST interface supports the query indicated in the URL to filter the list of device of a specific type according to their attributes. You can enquiry the DS by submitting an HTTP GET to the URLs that are compliant with the following format:


work.eu/<root>/<containedDeviceType>(/<deviceID>/<containedDeviceType>)*?q1=<pr

opertyName>+<operator>+<value>(&qi=<propertyName>+<operator>+<value>)*

* = 0 or more

i = {2, …, n}

+ = URL encoding of the white space

<propertyName> is the name of the profile attribute, <operator> is the boolean operator to be used in the evaluation (e.g. EQUAL, NOTEQUAL, CONTAINS, etc.) and <value> is the value to be used when comparing the value of the attribute in the device profile according to operator.


200, if there are device profiles that match the selection criteria specified

404, if there no device profile that matches the selection criteria specified

500, if an error occurred on the DS while fulfilling the request

The body of the response is a JSON document that includes the list of the URLs of the devices that match the selection criteria specified.

3.2.7 Security plane

3.2.7.1 Orchestrated Management

Deliverable D3.3 details more background on the Orchestrated Management technology. We here provide an overview from an architectural perspective.

The Orchestrated Management method enables administrators to describe management operations as well as dependencies and constraints between them. In addition the Orchestrated Management engine can derive and uphold dependencies from the scenario description.

Orchestrated Management comprises:

a lightweight grammar and API for expressing management scenarios along with various constraints (ordering, timing and others)

04/07/2013 Pag. 56 IoT@Work/WP1/D1.3/1.0


a set of algorithms that produce management plans and schedule the management operations contained in those plans on the corresponding targets (both PCs and embedded devices).

Scenarios expressed in our technology are input to the Orchestrated Management engine. The engine computes and validates a management plan out of the management scenario. The plan is sent to the Orchestrated Management scheduler. The role of the scheduler is to run the tasks and monitor the outcome of the management operations, making sure that all pre and post conditions set up by the administrator are respected. The following picture shows the process flow we just described.

Figure 3.18 – Process flow orchestrated management

We can summarize the value of Orchestrated Management in the context of IoT@Work Plug&Work as follows:

IoT@Work essentially introduces an “indirection” for device configurations. Instead of directly configuring a device using some tool, we put the needed configurations on some place (e.g. slice manager for networks, PLC for automation, security, middleware...) then the device or service upon start up receives those configurations. So planning, engineering and programming tools are decoupled from the devices actually used in the field.

The Orchestrated Management technology can then help with formally capturing what the needed configurations are, how they should relate to each other, and under which conditions they should be initiated; Orchestrated Management then also comes with engine to execute on what is captured, and invoke the needed configuration interactions as+when appropriate.

Situating Orchestrated Management within the overall IoT@Work architecture, see Figure 3-3, we can find the following elements:

Orchestrated Management authoring support. Within the Security Plane, as part of the interface layer to planning, engineering, and programming, Orchestrated Management provides an API and grammar for authoring “management scenarios”, capturing dependencies between, and constraints on management operations.

Orchestrated Management scheduling service. Within the Security Plane, as a backend service in the infrastructure, Orchestrated Management provides an engine that can schedule and trigger management operations, captured in a management scenario, hereby enforcing the declared dependencies and constraints.

Management services. Orchestrated Management by itself does not provide any specific management operations. Existing management operations from the Management, Communication, and Security Planes can be wrapped inside an Orchestrated Management aware management operation such that it can be included and triggered as part of an Orchestrated Management scenario.

Orchestrated

management scenario

Dependency

resolution Management plan Runtime scheduling

04/07/2013 Pag. 57 IoT@Work/WP1/D1.3/1.0


Context services. Orchestrated Management by itself does not provide any specific context services. When one wants to author management scenarios where management operations are subject to specific constraints (e.g. “not-in-production”), then constraint values should be available from such context service (e.g. this could be parameter from a MES or ERP system).

3.2.7.2 CEP and System monitoring

As shown in Figure 3-3, the Complex Event Monitoring (CEP) service itself is part of the Backend services layer and the Management plane intersection. The use of the CEP queries/rules is part of the intersection of the higher layer that interfaces with planning/etc. and the Security plane. In complex and highly dynamic and agile systems such as these that IoT@Work targets, it is impossible to statically verify that the system will behave correctly (especially so when under attack). Unlike in the past where similar systems were more or less fixed and closed, now we aim to develop systems that are (highly) dynamic and open – allowing new devices to join and leave the system at any point of time. In order for the system to remain in a healthy state and be able to meet the objectives for which it was built, a number of rules needs to be followed, just as humans need to follow the rules of their society for the society to be able to function as a whole. The CEP service is responsible for verifying these rules at run-time and reacting appropriately whenever a violation is observed.

These rules can be used both for general safety and security goals, as long as one can decide that the goal has been violated only by examining a finite set of events – what is formally called a “safety” property [37], that something bad never happens. An example is “A robot does not hit a human”. We can decide if this property has been violated by examining a sequence of events and observing if a robot has hit a human at any point up till the present. For general system correctness one also needs to prove that the system meets “liveness” properties [37] too. These describe that something good will eventually happen, as the safest robot is one that never does anything (but it is not very useful). Liveness properties cannot be monitored at run-time, as the fact that something good has not happened so far does not imply that it will not happen in the future. For this reason the usual practice is to transform liveness properties to safety ones by the introduction of time-outs – the good event needs to occur before some deadline. This renders the property a safety one and it can be monitored. Security properties, in particular those dealing with confidentiality, are of a different nature altogether – they can be described as “hyper-properties”, split into hyper-safety and hyper-liveness ones [38]. Some of them can also be transformed into safety properties, thus making it possible to monitor them at run-time. It can be sometimes quite difficult to specify a property of interest – property patterns, in different specification languages have been specified already in [42]. The corresponding online repository contains patterns relating to event occurrence (Absence, Universality, Existence, Bounded Existence) and to event order (Precedence, Response, Chain Precedence, Chain Response), for different pattern scopes (Global, Before Q, After Q, Before Q and R, After Q until R, where Q and R are some events), thus greatly facilitating the job of the property specifier.

In IoT@Work we explored two different CEP engines: Microsoft StreamInsight [41] that is based on LINQ (Language-Integrated Query) and EVEREST [39],[40] from City University London, which uses a language based on Event Calculus called EC-Assertion. The two are fine examples of different approaches to complex event processing. StreamInsight provides a framework whereby queries and transformations on the run-time event streams can be written in a usual programming language. EVEREST on the other hand requires the use of a higher-level language, based on logic. An obvious strong point of the former and weak point of the latter is

04/07/2013 Pag. 58 IoT@Work/WP1/D1.3/1.0


programmer familiarity. On the other hand, Event Calculus (EC) can sometimes be easier to understand by non-programmers and there are some tools that allow EC rules to be analyzed statically, e.g. decreasoner 3. One can use such tools to run forward-reasoning steps (given an initial state and a set of events what is the final state?) and backwards-reasoning steps (given initial and final system states what are the possible events?). This allows one to increase their confidence in the correctness of the CEP rules, which like any other program/specification may be wrong themselves. It also allows one to identify failure scenarios involving event sequences that had not been considered before or even imagined possible.

public interface CepEventReceptor { // Wraps the CEP

void receiveEventX1(...);// receive Y1 from ENS

...

void receiveEventXn(...);

}

public interface EventBusWrapper { // Wraps the ENS, etc.

void publishEventY1(...); // publish Y1 through ENS

...

void publishEventYn(...);

void actionA1(); // initiate this action

}

Figure 3.19: ENS/CEP bridging interfaces

The added benefit of employing both of these quite different CEP technologies within IoT@Work was that it allowed us to stress-test our designs and integration interfaces, and increase our confidence that these will prove stable even if a different CEP engine is used. Here the problem is that each CEP uses its own ways for receiving and publishing events. We ended up with two interfaces – one for a wrapper of the ENS event bus and in general the environment outside the CEP, and another for the CEP itself, as shown in Figure 3.19. As can be seen in it, the CEP needs to offer an interface with one method for each event type that appears in its rules. At the other hand, the ENS event bus wrapper needs to offer to the CEP one method for each event type that may be published and one method for each system action that may need to be initiated by the CEP as a reaction to some event.

A small CEP example

Let us consider here an example from the project’s integrated demo. In this scenario, a device is measuring the energy consumption of a factory cell and we wish to raise an alarm whenever the power consumption is higher than some threshold. Using Event Calculus, we can express this as shown in Figure 3.20. In EC, the predicate HoldsAt(f,t) means that the fluent f is true at time-point t. A fluent is an element representing system state, e.g., here the value of the power threshold. Fluents are initiated/terminated by the occurrence of events using the Initiates(e, f, t) and Terminates(e, f, t) predicates, which render the fluent f true (resp. false) at time-point t+1, when event e occurs at time-point t. Finally, occurrence of an event e at some time-point t is stated as Happens(e, t).

3 http://decreasoner.sourceforge.net/

04/07/2013 Pag. 59 IoT@Work/WP1/D1.3/1.0


Our system theory has two types of fluents – one to hold the value of the power consumption threshold, which can be changed dynamically, and another to hold the fact that an alarm was set at some time-point for a particular value of power consumption measurement (in decreasoner we can do this to simulate the reaction of the CEP). There are two events, one for setting the threshold and another to represent an energy measurement. The first two monitoring rules manipulate the threshold according to the setPowerThreshold events received, while the third rule sets the alarm for a particular power measurement and timepoint when it exceeds the current value of the threshold. High-level specifications like these can sometimes be easier for non-programmers to understand and validate. This particular notation can in fact be verified statically using the tool decreasoner. One can use the theory to simulate patterns of events, as is done in Figure 3.20. This can help debug a theory – a bug can be seen in the lines marked with “XXX”, where one needs to check that the “old” threshold that is being unset is not the same as the new one. A tool like decreasoner can compute the different system configurations that result, given a theory, an initial state and a set of events. It can also compute possible event traces that are consistent with a theory and an initial and final states – essentially helping one to discover scenarios under which some condition becomes true, a valuable help when one tries to understand how the system reached a particular state. The non-highlighted part of Figure 3.20 shows the part that stays the same whether one performs forwards (as in the highlighted area of the figure) or backwards (not shown) reasoning.

The theory shown in Figure 3.20 is similar to the one implemented in EVEREST for the integration demo. However, the language of EVEREST is more complicated than that of decreasoner, mostly because it represents more information about the events and the rule types to assist the run-time system monitoring process and because the EVEREST input language is based on XML, which is not as easy to read by humans. The general structure of the two theories is nevertheless the same.

sort power: integer ;; some new type definitions.

sort current: integer

sort voltage: integer

fluent PowerThreshold(power) ;; “Variables” representing the system state.

fluent PowerAlarm(power)

event SetPowerThreshold(power) ;; Events that can be observed.

event EnergyMeasurement(power,current,voltage)

;; A SetPowerThreshold event causes the old threshold to be forgotten.

[time, power2, power]

HoldsAt(PowerThreshold(power2), time)

& Happens(SetPowerThreshold(power),time) ; XXX – bug if missing.

& power != power2 ; XXX – bug if missing.

-> Terminates(SetPowerThreshold(power), PowerThreshold(power2), time).

;; A SetPowerThreshold event sets a new threshold.

[time, power]

Initiates(SetPowerThreshold(power), PowerThreshold(power), time).

;; An energy measurement event whose power exceeds the threshold causes

;; an alarm to be raised.

[time, power, power2, current, voltage]

Happens(EnergyMeasurement(power, current, voltage), time)

04/07/2013 Pag. 60 IoT@Work/WP1/D1.3/1.0


& HoldsAt(PowerThreshold(power2), time) & power2 < power

-> Initiates(EnergyMeasurement(power, current, voltage), PowerAlarm(power), time).

;; What is true initially.

; HoldsAt(PowerThreshold(0),0).

[power] ! HoldsAt(PowerThreshold(power),0).

[power] ! HoldsAt(PowerAlarm(power),0).

;; Simulating system events.

Happens(SetPowerThreshold(2),0).

Happens(EnergyMeasurement(3, 0, 1),1).



Happens(SetPowerThreshold(2),3). ; XXX – change the threshold.


completion Happens ;; The only known events are the ones declared above (induction).

;; No models can be found if the below fact is added.

; [power] ! HoldsAt(PowerAlarm(power),6).

;; Without the fact above, only one model is found where:

;; PowerThreshold(2) becomes true at time point 1;

;; PowerAlarm(3) becomes true at time point 2; and

;; PowerAlarm(4) becomes true at time point 3.

range time 0 6 ;; Ranges of types.

range power 0 4

range current 0 1

range voltage 0 1

range offset 1 1

Figure 3.20 – Monitoring excessive power consumption in Event Calculus

3.2.7.3 Authorisation capability

The capability-based access control approach is centred on the concept of capability. A capability (known in some systems as a key) is a communicable, unforgeable token of authority. It refers to a value that uniquely references an object along with an associated set of access rights. By virtue of its possession by a process that uses the referenced object, the capability token grants that process the capability (hence the name) to interact with an object in certain ways. An authorisation capability is a XML document complaint with a specific XML schema whose top level elements and attributes are reported in Figure 3-21.

04/07/2013 Pag. 61 IoT@Work/WP1/D1.3/1.0


Figure 3-21 - Authorisation Capability XML Schema - top level elements

The most relevant elements in the schema are:

the AccessRightsCapabilityID, IssueInstant, and Version attributes that uniquely identify a capability token;

the Issuer: identifies the subject that has created the capability token (and that implicitly takes responsibility for it);

the Subject: identifies the subject to which rights (as specified in the AccessRights element) have been granted;

the ResourceID: this URI identifies the resource on which the Subject can exercise the granted rights. Using a URI we can assure high flexibility and generality in resources identification;

the AccessRightsCapabilityRevocationService: provides the URI of a Revocation Service to which revocation requests can be submitted for revoking a specific capability token (and/or its children capabilities). This URI has to be the same for all capabilities in an authorization chain but different resources or services can have different, and autonomous, Revocation Service;

the ValidityCondition: states the validity period of the capability token;

the IssuerAccessRightsCapability: is used to store the authorization capability owned by the Issuer so that the service in charge of managing the identified resource (e.g. the ResourceID) can check the correctness of the authorization chain;

the AccessRights element, finally, details the rights that a capability token grants to the Subject. This element lists one or more granted rights and, for each of them, states if the Subject is allowed to further delegate it on not and, if so, can even specify a delegation depth so that the delegation chain can be limited beforehand. For each delegated right further conditions (expressed according to the XACML standard) can be specified to be met for actually exercising the granted right (these conditions are based on the XACML condition specification).

The schema envisages a Signature element that digitally signs, by the Issuer subject, the whole capability token so that it cannot be forged. Actually there are two types of capability tokens:

04/07/2013 Pag. 62 IoT@Work/WP1/D1.3/1.0


what we call the Root Capability, which for a given resource and set of rights (1 or, even more), is the first in the authorization chain. This root capability has to be normally issued by the owner or manager of the identified resource that has to be a trusted subject by the resource provider. A Root Capability has the same value for its Issuer and Subject element and its IssuerAccessRightsCapability element is empty;

non-Root Capability token that has a parent capability (reported in the IssuerAccessRightsCapability element) and has the same ResourceID and AccessRightsCapabilityRevocationService as its parent, a ValidityCondition that is not exciding the ValidityCondition element in its parent token, and an AccessRights element that is a subset of the delegable rights in its parent capability.

our capability-based access control system, the service/operation request has to refer or include, in an unforgeable way, the authorising capability. service/operation requests are managed by the resource manager (i.e. the service provider in charge of managing the identified resource and of providing the requested service). From a capability-based access control point of view, it is in charge of validating the capability in the service request and the congruence of the request against the provided access capability. The resource manager, as normally happens, has to act like as an XACML Policy Enforcement Point (PEP) taking into account the validation outcomes of the Policy Decision Point (see section 3.2.7.5).

3.2.7.4 Capability Revocation

The authorisation capability revocation is represented by an XML document which must be valid against a specific XML schema. This section provides a description of the main elements envisaged by that XML Schema.

Figure 3-22 reports the top level structure of a Capability Revocation. The schema envisages a set of mandatory attributes (schema version, revocation ID and revocation issue timestamp) that collectively identify an instance of a Capability Revocation.

Figure 3-22 – Authorisation Capability Revocation XML Schema

In addition to the above attributes the schema envisages the following set of elements:

Issuer: its purpose is to identify who took responsibility of creating the Capability Revocation instance (i.e. this element identifies the signer of the revocation instance). This element is mandatory and of type NamedIDType as defined by the SAML specifications.

04/07/2013 Pag. 63 IoT@Work/WP1/D1.3/1.0


Signature: this mandatory element is used to hold the digital signature of the Capability Revocation that is used both to check the integrity of the revocation instance, as well as the proof of ownership of the declared identity. Its type is SignatureType as defined by the XML Digital Signature specifications.

RevokedCapabilityData: this mandatory element holds information about the revoked capability. This element is an XML sequence with a set of mandatory elements: the RevokedCapability, of type AccessRightCapabilityType, is the capability referred to by the capability revocation instance, the Reason must be used to report why a capability is being revoked, the RevokeSince, of type dateTime, must specify the UTC time, with a resolution of 1/1000 sec, from which the identified capability must be considered revoked, and the DependentTreeEffects which must be used to specify how the capability revocation affects the capability identified by the RevokedCapability element and its downstream capabilities (the revocation scope). The DependentTreeEffects element can have one of the following three values:

o IdentifiedCapabilityOnly: only the capability identified by the RevokedCapability element is revoked. Downstream capabilities issued earlier than the revocation IssueInstant are not affected and maintain their validity.

o AllCapabilities: both the capability identified by the RevokedCapability element, and all its downstream capabilities are revoked.

o DependentCapabilitiesOnly: all capabilities having as ancestor the capability identified by the RevokedCapability element, except such capability, are revoked.

ReturnReceiptTo: this mandatory element must be used to specify an email address (in a URI form) to which the resource revocation service has to send the final outcomes (capability revoked or revocation request rejected) of the processing of the capability revocation request4.

IssuerAccessRightsCapability: this mandatory element is used to store the Authorisation Capability of the Issuer.

3.2.7.5 Policy Decision Point

The Policy Decision Point (PDP) is the functional component that evaluates the revocation status of capability tokens and the applicable policies (if any) in order to

4 Actually a capability revocation request evaluation is a two phases process: in the 1st phase the received request is checked for its formal correctness (e.g. its acceptability that consists in verifying its digital signature, the correctness of elements like the IssuerAccessRightsCapability, etc.), while the 2nd phase is devoted to validate if the requesting subject is actually entitled to revoke the indicated authorization capability/capabilities. The 1st phase processing can be performed immediately and, therefore, its outcomes are returned immediately to the requestor as results of the RESTful request. The processing requested by the 2nd phase, instead, could need to be deferred if the required information are not yet available. For example if the PDP capability database does not contain the authorization capability to be revoked the revocation request cannot be processed, nor it can be dropped to avoid that a subsequent request based on the revoked capability be accepted. Therefore the Revocation Service stores not-yet-processable revocation request in a specific section of the PDP database until all necessary information become available. This is the reason behind this double notification: an immediate RESTful result (that reports if the request is acceptable) and a subsequent email (that reports if the request is correct and if the revocation has been enforced)

04/07/2013 Pag. 64 IoT@Work/WP1/D1.3/1.0


produce an authorization decision. As for an XACML PDP, the authorization decision can be either Allow or Deny. The PDP is resource-agnostic because its evaluation process does not differ according to the resource indicated in the capability.

The PDP provides a RESTful API through which it can receive requests for access capability to be checked and return its outcomes (details on the REST request/response protocol are provided below). The following figure sketches the PDP overall architecture.

Figure 3-23 - PDP Service architecture

The overall PDP logic for access capability checking is the following:

When a capability is submitted for evaluation, the PDP enquiries its local database (Capability + Revocation DB) by looking for revocation information that could affect the submitted access capability directly (i.e. it has been explicitly revoked) or indirectly (i.e. one of its ancestor has been revoked before the access capability at hand was issued or an ancestor has been revoked including its children capability). If the access capability at hand is flagged as revoked then the PDP provides a Deny answer,

If the capability is not revoked, the PDP checks if its internal DB contains a pending revocation request that could affect the access capability at hand (i.e. the database contains a pending revocation request involving the capability at hand or one of its ancestor). If a pending revocation request is found then the PDP tries to resolve it taking into account the capability at hand. If it is able to resolve the pending revocation request, the PDP informs the Revocation Service and uses the updated database status to check if the access capability at hand is still valid or no. If it is invalid (i.e. it is now revoked) then the PDP provides a Deny answer,

in all other cases the PDP provides an Allow answer.

In any case, the PDP stores in its internal database all capabilities in the authorization chain of any capability submitted for evaluation.

The PDP RESTful interface provides two operations:

submission of the capability to be checked (via an HTTP POST request);

enquiring the PDP to get the revocation status of a specific capability (identified by a unique hash code) and its descendants (up to a specific depth level).

Capability + Revocation DB

PDP Config DB

PDP Service

DPDSrvMgtGUI

PDPPendRevNotifier

PDPAuthReqProcessing PDPPendRevProcessing

from the XXX Author. Service

to the Revocation Service

04/07/2013 Pag. 65 IoT@Work/WP1/D1.3/1.0


The body of the HTTP POST consists in the list of all capabilities in the authorization chain of the capability to be checked, starting with the root capability and ending with the last-in-chain capability.

<capabilityList>

<capability>Root capability token goes here</capability>

...

<capability>Last in chain capability token</capability>

</capabilityList>

Each <capability> element contains all the elements envisaged by the XML schema of the capability but the IssuerAccessRightsCapability and Signature elements.

The response returned by the PDP has the following structure:

<Response>

<Result>

<Decision>Authorisation decision goes here</Decision>

<Status>

<StatusCode Value="StatusCodeValue"/>

</Status>

</Result>

</Response>

The value of the <Decision> element can be: Permit, Deny, and NotApplicable. Permit means the access capability is still valid and therefore the access request has to be accepted. Deny means that the rights stated in the capability cannot be exercised anymore. NotApplicable is returned if the request body is malformed or an error occurred on the PDP while fulfilling the request.

StatusCodeValue can have one of the following values as indicated in the XACML standard:

urn:oasis:names:tc:xacml:1.0:status:ok: if the outcome is Permit or Deny;

urn:oasis:names:tc:xacml:1.0:status:processing-error: if the decision is NotApplicable because of a PDP internal error;

urn:oasis:names:tc:xacml:1.0:status:syntax-error: if the outcome is NotApplicable because of a malformed request.

3.2.7.6 Revocation Service

The Revocation Service is a service for managing the requests for revoking of one or more capabilities, as well as managing the entire life cycle of a capability revocation. Its work, therefore, is to validate both the acceptability of the received capability revocation requests (i.e.: that the requests are properly structured and signed), as well as the request’s correctness (i.e.: that the requesting subject is actually entitled to revoke the indicated capabilities). Based on the outcomes of the processing of the capability revocation request, the Revocation Service updates the access capabilities status in the related PDP database.

Actually a capability revocation request evaluation is a two phases process: in the 1st phase the received request is checked for its formal correctness (e.g. its acceptability that consists in verifying its digital signature, the correctness of elements like the IssuerAccessRightsCapability, etc.), while the 2nd phase is devoted to validate if the requesting subject is actually entitled to revoke the indicated authorization capability/capabilities. The 1st phase processing can be performed immediately and,

04/07/2013 Pag. 66 IoT@Work/WP1/D1.3/1.0


therefore, its outcomes are returned immediately to the requestor as results of the RESTful request. The processing requested by the 2nd phase, instead, could need to be deferred if the required information is not yet available. For example if the PDP capability database does not contain the authorization capability to be revoked the revocation request cannot be processed, nor it can be dropped to avoid that a subsequent request based on the revoked capability be accepted. Therefore the Revocation Service stores not-yet-processable revocation request in a specific section of the PDP database until all necessary information become available. This is the reason behind this double notification: an immediate response to the HTTP request (that reports if the request is acceptable) and a subsequent email (that reports if the request is correct and if the revocation has been enforced).

The following figure depicts the architecture of the revocation Service.

Figure 3-24 – Revocation Service architecture

The incoming Revocation Requests are processed by the module RevReqProcessing that performs the following checks:

Compliance with the XML Schema;

Compliance with the revocation constraints;

Ensuring that the received revocation request was not already submitted.

For each valid incoming revocation request two records are created:

One record holding all revocation processing data is stored in the

RevocationDB (see Capability + Revocation DB in Figure 3-). It is used by the

Revocation Service;

Another one, holding all revocation data, is added to the pending revocation

partition in the CapabilityDB (see Capability + Revocation DB in Figure 3-). This

one will be used in the pending revocation resolution.

The PendRevProcessing module is in charge of solving the pending revocation. The pending revocation resolution consists in:

Checking that both the authorising and revoking capabilities are not expired

Checking that the authorising capability can revoke the capability identified in

the revocation request

04/07/2013 Pag. 67 IoT@Work/WP1/D1.3/1.0


Updating the capability database with the revocation data, if the revocation

has been proved to be valid

Due to the asynchronous pending revocation process (i.e. that a revocation request processing could be deferred till all required information is available), the pending revocation resolution can also be performed by the PDP when it is requested to provide to evaluate a capability. A revocation request processing is deferred when the affected authorization capabilities are not present in the CapabilityDB, or because the ancestor-descendant relationship between the authorization capability of the pending revocation issuer and the capabilities to be revoked cannot be established. When a capability that provides all information required for resolving a pending revocation is submitted to the PDP, it performs the resolution of the revocation, leaving to the Revocation Service only the task of completing the processing informing the revocation request issuer. In this case, the PDP notifies the Revocation Service (see the red arrow From the PDP Service in Figure 3-).

After the resolution of a pending revocation, the Revocation Service sends a notification to the e-mail address indicated in the revocation request and updates accordingly the corresponding record in the RevocationDB.

Service configuration data such as server listening port, URLs of the CapabilityDB and RevocationDB, credentials to access the databases can be managed through a GUI.

The Revocation Service REST API provides two operations: submission of revocation requests (via a HTTP POST) and notification of pending revocation resolutions (via a HTTP PUT).

This last operation is basically used by the PDP in order to notify the Revocation Service of the pending revocation resolution outcomes. Indeed, both the PDP and the Revocation Service can resolve pending revocations thus the PDP must use this operation to notify the Revocation Service because that service is the only one in charge of updating the RevocationDB and notifying the revocation issuer.

3.2.7.7 Secure Device Identifier and Security Bootstrapping

Many devices that compose an automation or enterprise network are designed for unattended autonomous operation and might not provide user authentication. If devices that access the network are not able to mutually proof their identities and to check that they are connected to authorised devices attacks like the man-in-the-middle attack or denial-of-service attacks through unauthorized access to resources may be possible. For these reasons the capability of securely proofing (device) identities has to be provided. Securely here means that the identifier embodies authentication credentials that cannot be easily removed or copied for malicious use. Secure identifiers are a pre-requisite for the objectives of IoT@Work to enable secure communication and secure Plug&Work. Protocols for configuring, managing and regulating access to a network depend on the existence of a device identifier. In addition, a secure device identifier will be the basis for various services like system inventory, authorisation, auto configuration, localisation support, anti-counterfeiting or protection of higher level (application) security layer services. Following features are provided by the secure identifier approach for IoT@Work:

A device may have one or more Secure Device IDs.

Secure Device IDs may change during the lifetime of a device.

Secure Device IDs will support device authentication.

04/07/2013 Pag. 68 IoT@Work/WP1/D1.3/1.0


Secure Device ID may be used to securely bind additional data to an ID, e. g. firmware version, installation location, license data, device specification, etc.

There is a unique secure ID per hardware device (Hardware Device ID)

Devices have to be provided with their necessary credentials for secure operation in an IoT@Work environment in a secure manner. This initial phase is called credential bootstrapping. The recommended mechanisms for IoT@Work show the following features:

The bootstrapping process provides a high level of security

Additional management efforts for security bootstrapping workflow are low compared to the overall bootstrapping workflow

Additional costs for the infrastructure are low compared to overall infrastructure costs for bootstrapping

The bootstrapping workflow supports a high number of devices As recommendation for Secure IDs in IoT@Work environments solutions according to the standard IEEE 802.1AR has been elaborated. IEEE 802.1AR defines “Secure Device Identifiers” (DevIDs) to be used as interoperable secure device authentication credentials with Extensible Authentication Protocol (EAP) and other industry standard authentication and provisioning protocols. A device with DevID capability incorporates a globally unique Initial Device Identifier usually provided by the manufacturer (IDevID) stored in a way that protects it from modification. The device may support the creation of Locally Significant Device Identifiers (LDevIDs) e. g. by a network administrator. Each LDevID is bound to the device in a way that makes it infeasible for it to be forged or transferred to a device with a different IDevID without knowledge of the private key used to establish the cryptographic binding. IEEE 802.1AR defines a device ID module (DevID module) as a logical component that stores and operates on the DevID secrets and associated DevID credentials. The components of a DevID module are shown in Figure xx.

Figure xx: Secure Device ID Module

The DevID credential in cooperation with a DevID secret are used to prove the identity of the device the DevID module is attached to. The DevID secret is protected from access by any other entity. The DevID credential is publicly available to any other device that wants to verify the identity of a device.

Management and Service Interface

towards Applications

DevID Module

Random Number Generator

Asymmetric algorithms

Hash algorithms

Secure Storage

Figure 3-25: Secure Device ID Module

04/07/2013 Pag. 69 IoT@Work/WP1/D1.3/1.0


The DevID module provides an initial IDevID and may support local device IDs (LDevIDs). The IDevID is a global unique identifier of a device. LDevIDs are identifiers that may be created and used in addition or instead of the IDevID in a local environment. IDevIDs are normally created once during manufacturing or initial provisioning. They can be generated internally in the DevID module or created externally and transferred to secure storage within the DevID module. LDevIDs can be created at any time and likewise can be created internally in the DevID module or externally and transferred to the DevID module. The Device ID secret may be either the private key of a RSA-private/public key pair or the private key of a P-256 elliptic curve cryptography private/public key pair. The DevID credential is built by an X.509v3 certificate that contains the according public key and may contain additional information. The DevID secret has to be stored on the device in such a manner that it cannot be copied or manipulated by unauthorised entities. The most secure way is to provide hardware secured storage within the DevID module. However, hardware secured storage is not mandatory. Software secured storage, for example storage protected by the device’s operating system, is also allowed but may result in a lower security level. In addition to a secure ID IEEE 802.1AR defines interfaces to the DevID module that holds the ID. The Service interface defines operations the module provides to use the ID. The Management interface defines operations for a centralised supervision of DevID modules. Following operations are currently defined by IEEE 802.1AR:

Initialization o Prepares the DevID module for use. For instance self test routines

and security checks could be performed here.

Signing o This is the basic operation that is used for device authentication.

Inventory control operations, like o Enumeration of DevID public keys and credentials

Configuration operation o Enable/disable of DevID keys and credentials o Generate, insert, delete local IDs (LDevIDs) keys and credentials o Generate a Certificate Signing Request for LDevID

Auditing operations, like o Count of signing operations for each private key o Count of key generation, insertion and deletion o Count of CSR operations o Count of credential insertion and deletion

Bootstrapping of Credentials The usage of device IDs and additional device credentials requires that these data are securely transported to a virgin device in an initial bootstrapping process. After discussion of different technical means for bootstrapping in D3.2 the so called manufacturer-based approach was identified as most suitable for IoT@Work environments: As depicted in Figure 3-26, the devices are equipped with security credentials during the manufacturing step. These credentials are issued from a trust anchor of the manufacturer (manufacturer CA). The credential may be a public/private key pair, which serves as initial credentials. The certificate is bound to an identifier of the device (may be the MAC address of the component or the serial number or similar).

04/07/2013 Pag. 70 IoT@Work/WP1/D1.3/1.0


Figure 3-26: Manufacturer based bootstrapping

These credentials generated during manufacturing are independent of the later installation location of the device (production environment). If required by the production environment, these credentials can be applied to securely negotiate or exchange additional (local) security credentials.

3.2.7.8 Network Access Control

Network Access Control (NAC) is the first security control that devices have to pass it they want access to an automation network. Network Access Control (NAC) runs before the slice management mechanisms and validates access of a device identified by a secure ID. NAC can be described as a technology that authorises automation devices and provides access to (network) resources based on device authentication and on the security status of the device according to security relevant parameters that are given by factory policies. NAC comprises the detection and assessment of the relevant

04/07/2013 Pag. 71 IoT@Work/WP1/D1.3/1.0


parameters as well as functions to bring the devices to a policy compliant status (remediation). The NAC process is divided into following steps:

Detection: Detection of devices while connecting to the network

Authentication: Identification and authentication of devices

Assessment: Verification of devices' compliance to (security) policies

Authorisation: Enforcement of assessment result

Remediation: Updating of devices for being compliant to (security) policies Network Access Control does not rely on a single technology, but rather describes a general approach to significantly improve network security. The main steps depicted above are described in more detail in the following sub-sections.

Detection and Authentication

Detection provides measures to sense devices that are attached or reattached to the network. Identification and authentication of devices trying to access the network is necessary for later assessment and policy enforcement. Today’s common approach for detection and authentication of devices in a Network Access Control solution is the combination of a Layer-2 switch based packet detection with a cryptographic authentication by IEEE 802.1X. Identification and authentication is supported by a cryptographically secure identifier. The applied authentication mechanisms are EAP based IEEE 802.1X authentication. EAP is a generic authentication framework supporting multiple authentication methods. The IETF has standardised multiple EAP methods considering different authentication protocols. The preferred EAP method for the IoT@-Work scenarios is EAP-TLS where both entities are authenticated by means of the TLS handshake. The following figure depicts the network authentication architecture of IoT@Work:

Figure 3-28: NAC architecture

Authentication

Assessment Authorisation

Remediation

Detection

Figure 3-27: Network Access Control Steps

04/07/2013 Pag. 72 IoT@Work/WP1/D1.3/1.0


The Network Access Client (in 802.1X terms the Supplicant) at one end of a point-to-point LAN segment that seeks to be authenticated by an Authenticator attached to the other end of that link. The Network Access Client is located on devices that are connecting to the automation network.

The Authenticator facilitates authentication of other entities attached to the same LAN. The access switch is acting as 802.1X Authenticator and also as Policy Enforcement Point (PEP) with regard to the assessment and authorisation phase described later in the document.

The Network Access Authority as introduced in D1.2 is responsible for authentication of devices and acting as 802.1X Authentication Server. During the assessment phase the Network Access Authority assures also that a device is compliant with given security policies. The Network Access Authority is located on a AAA server. It has a persistent storage for access to the verification credentials and an interface to the Credential Management Service for receiving updates with respect to the operational authentication credentials (e.g. distribution of new trusted certificates, device identifier lists or revocation lists). The Network Access Authority needs an interface to the System Integrity Authority acting as Policy Decision Point for the given security policy. The integrity of important files on the device could be one aspect of the security policy. The Naming & Addressing functional component can act as additional Policy Decision Point to check if a device is connected at the correct location. After a successful compliance check the Network Access Authority grants access to the operation / automation network to the device

NAC Assessment, Authorization, Remediation

After detection and authentication of devices the next step of a NAC solution is the assessment phase to determine the device’s compliance with policies valid in the respective automation environment security domain.

The collection of this information requires an agent or a client on the devices. Agent- or clientless approaches are not able to collect the necessary information.

The IoT@Work architecture for NAC assessment and authorisation is based on the following functional components:

Network Access Client: This component acts as access requestor and seeks access to the protected network resources and who needs to be compliant to given (security) policies. The Network Access Client is located on devices that are connecting to the automation network.

Policy Enforcement Point (PEP): This role is responsible to enforce the policy i.e. to grant access to the operational network or not. The necessary information is provided by the Network Access Authority. The Policy Enforcement Point is realised by the Authenticator i.e. the access switch to which the Network Access Client is connected to.

Network Access Authority: This role acts as Policy Aggregation Point (PAP) and is responsible for distributing the access request to one or multiple Policy Decision Points, to collect the results from the PDPs and to conclude the inputs to a final result. The Network Access Authority tells the PEP to grant access to the network or not.

Policy Decision Point (PDP): This role decides if the attributes and security parameters provided by the Network Access Authority are compliant to the (local) policies. The decision result is provided to the Network Access Authority as input for the final assessment result. This role is not limited to one instance and multiple Policy Decision Points may exist to decide about

04/07/2013 Pag. 73 IoT@Work/WP1/D1.3/1.0


different aspects of a security policy. The System Integrity Authority acts as one Policy Decision Point.

NAC authorisation architecture components

The deployment of the architecture components to IoT@work components is shown in the next figure.

Figure 3-29 NAC authorisation architecture components deployment

The architecture relies on a client based solution for assessment of certain device attributes. The client is realised as part of the Network Access Client, which is also responsible for the preceding authentication phase. To allow NAC for network devices the network is configured in a way that a default network slice is accessible for new devices. This slice allows communication to the

04/07/2013 Pag. 74 IoT@Work/WP1/D1.3/1.0


Network Access Authority. Depending on the result of the assessment the access to the operation network slices is granted or to slices that allow remediation or reconfiguration.

3.2.7.9 Device Integrity Assurance

NAC is responsible for assessments of devices during first connect or re-connect of a device to the network. Automation environments require, even more than office environments, continuous post-connect assessment of the devices. Reasons for that are for example that in industrial automation environments devices like programmable logical controllers or field devices are often running a long period of time without any re-start or re-connect. Without regular re-assessment it cannot be guaranteed that a device is still in a status that is expected for the considered divice. In IoT@Work the task of continuous post-connect assessment on device level is provided by the Device Integrity Assurance described in the following section.

Devices like PLCs and field devices are continuously observed and appropriate actions may be generated if differences between the actual state of the devices and the expected state has been detected. Mismatches may happen unintentionally by human mistake and wrong configuration of devices. However, the main target of the Device Integrity Assurance component is to detect intentional mismatches due to unauthorised manipulations of the devices. The IoT@Work architecture for Device Integrity Assurance relies on three actors:

Device Integrity Client: This component collects the attributes requested for assessment of device status, protects the results by cryptographic means and sends them to the Device Integrity Collector.

Device Integrity Collector: This component is responsible for collecting assessment attributes from all devices the Collector is responsible for. The attributes are collected in recurring intervals to guarantee freshness. Updated assessment results are communicated to the System Integrity Authority.

System Integrity Authority: This role gets the device attributes from the Device Integrity Collector. The System Integrity Authority verifies the integrity and authenticity of the attributes. Finally the received attributes of the devices are compared with the expected ones.

Figure 3-30: System Integrity Assurance architecture components

The following picture shows a possible deployment option.

The Device Integrity Clients are located on all field devices and PLCs.

The Device Integrity Collector is deployed on PLCs where many field devices are connected to but it is also possible to deploy it on a separate PC/server.

The System Integrity Authority is deployed on a backend server like in the NAC architecture deployment.

04/07/2013 Pag. 75 IoT@Work/WP1/D1.3/1.0


Figure 3-31: System Integrity Assurance architecture deployment

For proper operation the System Integrity Authority depends also on a:

Policy Repository

The policy repository holds the expected states of the devices. These expected states are compared with the collected actual states. If intentional changes to the devices are applied this repository needs to be updated as well.

Device Credential Repository

The device credential repository holds the verification credentials of all devices that are authorised to access the automation system the System Integrity Authority is responsible for.

Credentials are used on device side to protect the transferred states against manipulation and on the System Integrity Authority Server to check the integrity of the transferred device states.

It is important to note that the Device Integrity Collector has no knowledge of the device credentials and therefore has not to be a trusted device.

04/07/2013 Pag. 76 IoT@Work/WP1/D1.3/1.0


3.3 IoT@Work Device

A device is a combination of a HW platform with SW. As such it offers a set of functions or services. In the context of the IoT@Work architecture we distinguish between "native" IoT@Work devices and legacy devices. A broad range of very different devices is relevant in the IoT@Work context:

Automation end devices (e.g. sensors, actuators, robots),

Network devices (e.g. switches, routers),

Servers and appliances (both as real, physical instances and as virtual ones).

In our context considered devices are those devices (see definition in Section 2.1.3) that can communicate using IP protocols and have at least enough "intelligence" to implement basic interfaces for management, control and monitoring (i.e. SNMP, Web Services). This means that field bus devices, analog sensors or RFID tags are not devices in the IoT@Work sense. These "legacy" devices will be represented by proxies. I.e. a Profinet IO module or a RFID reader are proxies for the respective devices.

Description of the IoT@Work native device and the functions it must have or the constraints it should comply with:

it must be an entity described in the directory service.

it is able to run a ENS Client5.

It has an IPv6 (optional: IPv4) communication stack and all capabilities to participate in a slice system. This means it has at least one network interface and it runs a SEP. IP stack includes network near services (i.e. DHCP).

It can perform Network Access Control

It can perform the auto configuration processes

Depending on its role, additional capabilities may be required.

Legacy devices basically do not comply to any of those requirements. Due to the fine granular decomposition of functions in the IoT@Work architecture, it is however in most cases possible to include legacy devices in an IoT@Work system with minor restrictions only. This is a very important issue for migration. In most cases this means a proxy for the missing functionality of the legacy device must be placed on a native IoT@Work device which then provides the needed functions on behalf of the legacy device. An example shall illustrate this concept:

A legacy PLC is not able to perform IoT@Work auto-configuration and it is not able to connect to ENS in order to send or receive info. This PLC does not have slice functionality. Thus we need three proxies. One performs IoT@Work auto-configuration and then configures the PLC as needed. The second may use whatever interfaces the PLC offers (i.e. Profinet interfaces or SNMP) to translate ENS messages. And the edge switch adjacent to the PLC may force all traffic to/from this PLC into a slice, similar to a port based VLAN. The last example shows also that the inclusion of legacy devices may result in limited functionality; here we can't use different slices for automation, ENS or other applications as the device is not able to provide different slice end points.

5 Strictly spoken, not the device needs an ENS client, but services on that device may need to participate in ENS.

04/07/2013 Pag. 77 IoT@Work/WP1/D1.3/1.0


4 Evaluation and Validation of Architecture

4.1 Approach

The architecture and the components have been evaluated by several means. First, there is an analysis checking the project solution against key performance parameters (KPI, D4.3). Then, from the beginning on the project tested components and a sub set of the architecture in various proof-of-concept implementations (see D4.3). Early results and findings from those implementation tests where feed back into the architecture development finally resulting in what is presented in this document.

Another input to evaluate our concepts was achieved by intense discussions with external experts. Two stakeholder workshops have been organized for this purpose and successfully provided valuable input [7].

As an additional check, the trend scouting from D1.1 was updated to ensure future demands can be met and is briefly summarized in the next section.

4.2 Trend-scouting and Evolution since Start of the Project

Deliverable 1.1 [1] of the project - published at the end of 2011 - had a brief overview on global trends and automation trends which potentially could affect the way future automation systems work and those trends place additional challenges and requirements which have been addressed in the project. This paragraph will discuss new trends and - to a lesser degree - will revise some of the former findings. We will also concentrate on socio-economic trends rather than diving into details of the technological evolution.

We have briefly listed global trends affecting the area of automation, such as global warming, aging society, mega cities, globalization, terrorism/espionage, lack of skilled people, shortage of rare materials and increased number of networked devices. We also discussed the impact of several technological trends in automation.

A lot happened since then. Still these trends and the conclusions of D1.1 are mostly valid, but some remarkable new trends appeared and especially the economical crisis of the European Union had some impact on the market of industrial automation systems [EU].

The IoT@Work project did not do an extensive and complete market trend study. Still some important aspects have been monitored and will be briefly discussed here.

Reshoring: while globalization of companies is ongoing, some major vendors start to produce again "at home" in Europe or the US ("reshore") rather than going into low labour cost countries [18]. This is only possible by means of a highly efficient production and a tight integration of logistics, ERP and other IT with the production plant.

Another strong trend is the upcoming Internet-of-Things (IoT). IoT was at buzzword level back in 2010, but is going into reality with ever higher speed.

Industry 4.0 - a new buzzword on the one hand, but also a strong trend in the market and the research. This term describes attempts to enable more flexibility in production, mainly by tighter IT integration, use of IoT technologies and new planning and simulation technologies. Many aspects claimed by Industry 4.0 are core components of IoT@Work and thus are a strong hint that the solutions of this project are highly relevant for near and midterm future.

04/07/2013 Pag. 78 IoT@Work/WP1/D1.3/1.0


Security awareness in the industrial area had a strong boost after the Stuxnet virus [30]. This however did not yet have direct impact on current products.

These trends do have several implications on automation technologies which may boil down to a much higher need to tightly integrate automation with business IT in order to achieve a significant higher flexibility. It can be expected that the IoT@Work solutions will play a major role to form the "glue" between production and business IT in those scenarios. Furthermore, IoT@Work technologies potentially can help to bring existing factories into the future by means of clear modernization enablers.

4.2.1 Reshoring

Bringing at least parts of the production into the developed countries shortens the logistic chain and thus promises significant cost savings especially for goods with high transport costs. But is also reduces dependencies on other countries and sub-contractors. There are many reasons for this, rising labour costs in China, rising transport costs, higher risks in supply chains and higher innovations in developed countries to name a few [23][[20]. While this trend today mainly happens in the USA, it is also likely to become a major trend in Europe [25]:

"An overseas price advantage of some 80% a decade ago has been progressively eroded to nearer 30%, but it is the realisation once again that the flexibility of local supply, quality issues, lead times, volume demands and much easier face-to-face personal contact is driving the change to return to UK suppliers."

A key feature here is a high degree of automation and innovation. Or to cite [20]:

"The next twenty years could see a revolution in how and where things are made. Advances in automation, additive manufacturing and nanotechnology offer huge potential, particularly when combined with intelligence from ‘big data’ and the application of greater processing power. Together, these advances will gradually shift the nature of manufacturing from mass production of generic products towards efficient, localised production of personalised products."

But also mass production of e.g. mobiles again returns. Companies like Apple, Motorola or Blackberry re-establish US production sites. Another advantage is that much more individualized products can be produced [Scott].

Consequences for manufacturing and automation are that a much tighter integration with IT is needed to facilitate not only a cost efficient production, but also to allow more flexibility enabling much more personalized products. The Economist [22] says:

"In the longer term reshoring will be boosted by the use of advanced manufacturing techniques that promise to alter the economics of production, making it a far less labour-intensive process."

4.2.2 Internet-of-Things

IoT was at the beginning when this project started, but now a lot of products and services hit the market and several national and European research projects are working to improve the IoT story. So IoT becomes true with increasing speed. One major driver here where the so-called smart phones which can provide a platform for a multitude of end user services, others are tags (i.e. QR codes or RF tags) enabling several optimizations in logistics and warehouses. Still IoT does not yet play the role it could play in factory automation, but in SCADA scenarios such as environmental control the IoT technologies already are going into large scale tests or even into

04/07/2013 Pag. 79 IoT@Work/WP1/D1.3/1.0


products. And this trend holds for worldwide, as an example China demonstrated its interest in IoT by hosting the IoT 2012 conference in Wuxi (http://www.iot-conference.org/iot2012/).

One issue of present IoT is that the focus of present research or product developments was more on the tagging things and on creating services (doing something with this information). Some of these attempts are neglecting the difficulties of having an efficient, secure and semantically enriched distribution of information. IoT@Work technologies like the Directory Service or the Event Notification Service may close this gap [26].

As a remarkable side note, not only many companies started to produce and sell IoT products. Thanks to affordable and open platforms like e.g. Arduino (http://www.arduino.cc/), also a large community of amateurs started to develop things and thus contribute to the IoT trend and make the vision of intelligent, interconnected things come true and popular.

4.2.3 Industry 4.0

"Factories of the Future", "Industry 4.0", "Integrated Industry" and many other terms describe a vision of future automation where machines are much tighter coupled with IT systems. Promises here are mainly cost savings and much enhanced flexibility in production. While press releases talk about an "industrial revolution" (i.e. http://www.wiwo.de/unternehmen/industrie/hannover-messe-industrie-4-0-chance-oder-hype/8033850.html), industry fairs like the Hannover Messe 2013 showed that in the reality it is more an evolution which has already started to transform automation by recent products. Again in the light of reshoring this trend is massively supported by national and international research programs such as the German "AUTONOMIK für Industrie 4.0" (www.autonomik.de) or European research programs to enable the vision of a "Manufacturing 2.0" (i.e. ActionPlant [27]). An important European initiative, the Factories of the Future PPP [28], states:

"This initiative is expected to deliver in particular:

A new European model of production systems for the factories of the future (e.g. transformable factories, networked factories, learning factories) depending on different drivers such as high performance, high customisation, environmental friendliness, high efficiency of resources, human potential and knowledge creation.

ICT-based production systems and high quality manufacturing technologies capable of optimising their performance with a high degree of autonomy and adaptability for a balanced combination of high throughput and high accuracy production.

Sustainable manufacturing tools, methodologies and processes that have the capability of cost-efficiently shaping, handling and assembling products composed of complex and novel materials"

These goals are well in line with market observations and the first two bullet points are addressed by IoT@Work project.

4.2.4 Industrial Security

Since years, common approach of IT security in factory automation or SCADA is to have separated networks on field, control and management level with very restricted interfaces. Access from management level networks to lower level networks, if possible at all, is protected by VPNs and Firewalls at the access points. On field level security measures were not assessed as necessary as only trustworthy and

http://www.iot-conference.org/iot2012/

http://www.iot-conference.org/iot2012/

http://www.arduino.cc/

http://www.wiwo.de/unternehmen/industrie/hannover-messe-industrie-4-0-chance-oder-hype/8033850.html

http://www.wiwo.de/unternehmen/industrie/hannover-messe-industrie-4-0-chance-oder-hype/8033850.html

http://www.autonomik.de/de/1003.php

04/07/2013 Pag. 80 IoT@Work/WP1/D1.3/1.0


authorized persons get access to the field level. In many automation domains installations are not going to be changed much over the live time, so there is no need to update some SW. Then, in June 2010, Stuxnet hit Iranian nuclear facilities attacking, especially automation devices. And Stuxnet efficiently destroyed this (in)security world view. Together with some successors it had a big impact on the security in manufacturing. On the first glance there may not be big changes in automation security since then, but the awareness and willingness to increase security is definitively there [29]. [30] concludes in his article about the Stuxnet impact on automation:

"Deploying a “Defense in-Depth” approach is mandatory and corresponds to good practise. Continuing to ignore control system cyber-security is grossly negligent. A new era has begun. Stay tuned."

Major industry fairs had focus topics dedicated for security, i.e. the Hannover Messe 2013 [31] or the Embedded World 2013 [32]. In the light of this new security awareness the IoT@Work approaches can be expected to play a major role adding manageable security to the network, industrial devices and applications.

4.2.5 Technologies

For the IoT@Work related technologies we can conclude that there was and is ongoing progress, but there are no really new disruptive developments. Without going into details, some interesting trends are:

Ethernet evolution (wired) is going to ever higher bit rates and efforts are under way to bring Ethernet into racks or even into boards (IEEE P802.3bj Task Force [33] and the IEEE 400 Gb/s Study Group [34])

Good old Spanning Tree Protocol (STP) in Ethernet finally has some successors. While the underlying protocols and solutions are not new, first products hit the market now. Advanced Ethernet "routing" and management by means of Shortest Path Bridging (SPB), Transparent Interconnection of Lots of Links (TRILL) is coming into products [24]. Several OpenFlow (https://www.opennetworking.org/) enabled switches are already available which allow arbitrary control over the network forming a concept known as "Software Defined Network". All these attempts make a very good base for the IoT@Work slice management system which can act as a management tool with build-in migration capabilities.

IPV6 finally has some very first products in industrial automation, e.g. the Siemens Scalance XR-500 switch/router has initial support for IPv6 [35]. In general there is no question that IPv6 will slowly be adopted by automation networks, but the time scale is still unclear [10].

Industrial Ethernet market share is slowly growing at the expense of field bus systems, expecting a share of around 30% in 2016 for Industrial Ethernet [36]. Note, [37] shows that roughly 40% of industrial Ethernet applications are still based on standard Ethernet. Those studies also illustrate the fact that there will be no clear winner of the Industrial Ethernet standards, so again the IoT@Work slice concept promising to be able to manage heterogeneity may be a good candidate for future industry networks.

4.2.6 Summary

This trend scouting paragraph only briefly discussed some selected trends in the area relevant for the project. Many more issues could have been analyzed, Cloud Computing, Embedded Virtualization, Wireless and more. But even this small

https://www.opennetworking.org/)

04/07/2013 Pag. 81 IoT@Work/WP1/D1.3/1.0


selection of topics shows that the IoT@Work topics are highly relevant for future automation.

04/07/2013 Pag. 82 IoT@Work/WP1/D1.3/1.0


5 Conclusions

In this deliverable we have presented the specification of the final architectural reference model of the solution proposed by IoT@Work in order to efficaciously support Plug&Work capabilities in factory automation systems. Its design has been driven by the requirements that specify the needs of an IoT environment, in particular in the manufacturing domain, with reference to event notification, event monitoring and reasoning, application service configuration and orchestration, device bootstrapping, network and security.

This deliverable marks the end of WP1, and thus integrates and harmonises the outcomes produced by the architecture definition process. Furthermore, it fosters the lessons learned during the following activities carried out during the project:

Specification of the communication services and their interactions (WP2, in particular D2.3 and D2.4)

Specification of the security components (WP3, in particular D3.2 and D3.3)

Integration of the implemented components and deployment in the selected pilots (WP2, in particular D2.5, as well as WP4, in particular D4.2 and D4.3)

Validation of the architecture by using the feedback from the implementation activities and the stakeholder group (WP4, in particular D4.2 and D4.3) as well as by comparing IoT@Work Work architectural reference model and requirements with IoT-A unified requirements

Technology and trend scouting (see section 4.2).

The reference architecture described in this document constitutes a major advancement towards the modelling and development of an automation system made up of smart production and network devices and service able to interact with each other in a more automated and autonomous way.

Additionally, the IoT@Work architecture devises a set of functional elements able to support devices and application services in improving their responsiveness and adaptability to a dynamic and flexible production environment, which facilitates the development and adoption of IoT-aware or IoT-enabled applications. To this end the adopted layered approach further contributes to make the IoT@Work architecture and functional elements more flexible and able to adapt to changes both in technologies, as well as on production methodologies: the layers allows to cluster the components into self-consistent and coherent set of functionalities thus clearly separating the areas of action and easing the definition and management of the interface for interaction; the planes group the functionalities supporting the operation of the layers and avoid the duplication of functions and components across them.

The overall architecture and the functional components it envisages are able to support and significantly simplify the configuration process of the network and devices deployed on the shop floor, the device bootstrapping, as well as the acquisition and dispatching, by application services, of the information and meta-information required for a more flexible and dynamic adaptation of their processing to the changing environment. The reference architecture takes into account, since its first version, security and reliability issues because they are considered essential features that integrate and support all other functionalities (indeed one of the planes of the architectural model is centred on security features).

04/07/2013 Pag. 83 IoT@Work/WP1/D1.3/1.0


The following tables summarise the achievement of WP1.

Sub-task Title Outcome

T1.1.1 State of the art analysis refinement D1.1 (M6)

Delivered M6

T1.1.2 Architecture requirements & assumptions D1.2 (M14)

Delivered M16

T1.1.3 Pilot Scenario Identification D1.1 (M6)

Delivered M6

T1.1.4 Architecture requirements & assumptions refinement

D1.3 (M36)

Delivered M37

Table 5.1 – Task T1.1 achievements

Phases Title Outcome

Phase 1 Functional Reference Architecture V1 Internal Deliverable (M10)

Phase 2 Functional Reference Architecture V2 Internal Deliverable (M18)

Phase 3 Functional Reference Architecture Final Version D1.3 (M36)

Delivered M37

Table 5.2 – Task T1.2 achievements

04/07/2013 Pag. 84 IoT@Work/WP1/D1.3/1.0


6 References

[1]. M. Villa et al., "D1.1 – State of the art and functional requirements in manufacturing and automation", 30/11/2010, https://www.iot-at-work.eu/

[2]. A. M. Houyou et al., ”D2.3 – PLUG&WORK SUPPORT MECHANISMS”, IoT@Work, 2012, https://www.iot-at-work.eu/

[3]. D. Rotondi et al., “D1.2 – Architecture requirements, assumptions and threats”, IoT@Work, 2011, https://www.iot-at-work.eu/

[4]. A. M. Houyou et al., "D1.1. Revision Details", 20/12/2011, https://www.iot-at-work.eu/

[5]. A. M. Houyou et al., "D2.2 –BOOTSTRAPPING ARCHITECTURE", 01/06/2011, https://www.iot-at-work.eu/

[6]. K. Fischer et al., "D3.2 – DEFINITION AND EVALUATION OF SOLUTIONS FOR SECURE PLUG&WORK, SERVICE ACCESS AND COMMUNICATION", 11/04/2012

[7]. H. Trsek et a., "D5.3 – Final dissemination and clustering report", public deliverable, 30/06/2013

[8]. IoT-A, “Requirements”, http://www.iot-a.eu/public/requirements (accessed on 2013-02-11), 2013

[9]. Mahlmann, Peter; Schindelhauer, Christian; Peer-to-Peer Netzwerke; Springer-Verlag, Berlin, Heidelberg, 2007

[10]. R. Plonka, "Internet Protocol version 6 for automation technology", Industrial Ethernet Book issue 76/12, may 2013, http://www.iebmedia.com

[11]. Jourik de Loof, IoT-A, private communication, 2013

[12]. Carsten Magerkurth (ed.), “Deliverable D1.4 – Converged architectural reference model for the IoT v2.0”, http://www.iot-a.eu/public/public-documents/documents-1/1/1/D1.4/at_download/file, 2012

[13]. AMQP Working Group, “Advanced Messaging Queuing Protocol – Protocol Specification – Version 0.9.1”. Online at: http://www.amqp.org/

[14]. Rosen E., Viswanathan A., Callon R., "RFC 3031: Multiprotocol Label Switching Architecture", IETF, 2001

[15]. Rodriguez-Perez F., Gonzalez-Sanchez J., "Extending RSVP-TE to support Guarantee of Service in MPLS", Innovative Algorithms and Techniques in Automation, Industrial Electronics and Telecommunications, Springer 9/2007, DOI:10.1007/978-1-4020-6266-7_28 pp 149-154

[16]. Hoogendoorn C., Schrodi K., Huber M., Winkler C., Charzinski C., "Towards Carrier-Grade Next Generation Networks", Proc. ICCT 2003, Beijing, China, Apr. 2003

[17]. European Union DG Enterprise and Industry, "EU industrial structure 2011 - Trends and Performance", ISBN 978-92-79-20733-4, 2011

[18]. A. Regalado, "Back in the USA", Technology Review, April 2013, http://www.heise.de/tr/artikel/Back-in-the-USA-1827798.html

[19]. EU industrial structure 2011 - Trends and Performance, Luxembourg: Publications Office of the European Union, ISBN 978-92-79-20733-4

[20]. Fidelity Worldwide Investment press release, "21st Century Investment Themes, Episode 7: the revival of the west", 2013, https://www.fidelityworldwideinvestment.com/middle-east/news-insight/21-century-themes/episode7.page

[21]. J. Scott, Computer Weekly, "Could mobile manufacturing be heading back to Europe?", 31 May 2013, http://www.computerweekly.com/news/2240185105/Could-mobile-manufacturing-be-heading-back-to-Europe

[22]. The Economist, "Coming Home", Jan 2013, http://www.economist.com/news/special-report/21569570-growing-number-american-companies-are-moving-their-manufacturing-back-united

[23]. S. Jingting, Chen Limin, T. Yannan, China Daily Europe, "Homeward bound? Firms mull return", July 2012, http://europe.chinadaily.com.cn/business/2012-07/23/content_15607088.htm

https://www.iot-at-work.eu/data/D1.1_SotA_Requirements_final.pdf

https://www.iot-at-work.eu/downloads.html




http://www.iebmedia.com/index.php?id=9559&parentid=63&themeid=255&hft=76&showdetail=true&bb=1

http://www.amqp.org/confluence/download/attachments/720900/amqp0-9-1.pdf?version=1&modificationDate=1227526523000

http://www.heise.de/tr/artikel/Back-in-the-USA-1827798.html

https://www.fidelityworldwideinvestment.com/middle-east/news-insight/21-century-themes/episode7.page

https://www.fidelityworldwideinvestment.com/middle-east/news-insight/21-century-themes/episode7.page

http://www.computerweekly.com/news/2240185105/Could-mobile-manufacturing-be-heading-back-to-Europe

http://www.computerweekly.com/news/2240185105/Could-mobile-manufacturing-be-heading-back-to-Europe

http://www.economist.com/news/special-report/21569570-growing-number-american-companies-are-moving-their-manufacturing-back-united



http://europe.chinadaily.com.cn/business/2012-07/23/content_15607088.htm

http://europe.chinadaily.com.cn/business/2012-07/23/content_15607088.htm

04/07/2013 Pag. 85 IoT@Work/WP1/D1.3/1.0


[24]. S. M. Kerner, Enterprise Network Planet, "Will TRILL or Shortest Path Bridging Win Out?", May 2012

[25]. A. Allocck, Machinery, "Reshoring - fact or fiction", May 2013, http://www.machinery.co.uk/machinery-features/reshoring-fact-or-fiction/49213/

[26]. M. Ruta, F. Scioscia, E. Di Sciascio, D. Rotondi, S. Piccione. “Semantic-based Knowledge Dissemination and Extraction in Smart Environments”, International Workshop on Pervasive Internet of Things and Smart Cities (PITSaC-2013), Barcelona, Spain, March 2013

[27]. "ICT for Manufacturing The ActionPlanT Roadmap for Manufacturing 2.0", http://www.actionplant-project.eu/images/stories/roadmap.pdf

[28]. home page of the European Factories of the Future Public Private Partnership, http://ec.europa.eu/research/industrial_technologies/factories-of-the-future_en.html

[29]. J. Cusimano, Exida Inc., March 2011, http://www.exida.com/index.php/blog/indepth/the_real_impact_of_stuxnet

[30]. S. Lüders, "STUXNET and the Impact on Accelerator Control Systems - Cern", proceedings of ICALEPCS 2011, Grenoble, France

[31]. Hannover Messe 2013, Security & Product Protection, http://www.hannovermesse.de/de/ueber-die-messe/programm/leitmessen/industrial-automation/programm/industrial-security-product-protection

[32]. Embedded World 2013, press release "Safety and Security im Fokus", Nov. 2012, http://www.embedded-world.de/de/presse/presseinformationen/embedded-world-2013-safety-and-security-im-fokus

[33]. IEEE P802.3bj Task Force, http://blog.siemon.com/standards/ieee-p802-3bj-100-gbs-backplane-and-copper-cable-task-force

[34]. IEEE 400 Gb/s Study Group, http://standards.ieee.org/news/2013/400gbs_ethernet.html

[35]. Siemens Scalance XR 500 product description, http://support.automation.siemens.com/

[36]. P. Reynolds, Packaging World, "Quantifying the growth of industrial Ethernet-based automation components", March 2013

[37]. J. Morse, Industrial Ethernet Book Issue 69/42, "The world market for Industrial Ethernet components", July 2012, http://www.iebmedia.com/

[38]. Alpern, B.; Schneider, F. B.: Defining Liveness. Inf. Process. Lett. 21(4): 181-185 (1985)

[39]. Clarkson, M. R.; Schneider, F. B.: Hyperproperties. Journal of Computer Security 18(6): 1157-1210 (2010)

[40]. Spanoudakis, G.; Mahbub, K.: “Non Intrusive Monitoring of Service Based Systems”, International Journal of Cooperative Information Systems, 15 (3), pp. 325-358, 2006. Online at: http://www.soi.city.ac.uk/~gespan/ijcis06.pdf

[41]. Spanoudakis, G.; Kloukinas, C.; Mahbub, K.: Chapter 13 "The Runtime Monitoring Framework of SERENITY" In G. Spanoudakis, A. Maña, and S. Kokolakis, editors, Security and Dependability for Ambient Intelligence, number 13 in Information Security Series, pages 190-214. Springer-Verlag, 2009

[42]. Microsoft StreamInsight. http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx

[43]. Dwyer, M. B.; Avrunin, G. S.; Corbett, J. C.: Patterns in Property Specifications for Finite-State Verification. ICSE 1999: 411-420. An online repository of specification patterns is available at: http://patterns.projects.cis.ksu.edu/

http://www.machinery.co.uk/machinery-features/reshoring-fact-or-fiction/49213/

http://www.actionplant-project.eu/images/stories/roadmap.pdf

http://ec.europa.eu/research/industrial_technologies/factories-of-the-future_en.html

http://www.exida.com/index.php/blog/indepth/the_real_impact_of_stuxnet

http://www.google.de/url?sa=t&rct=j&q=stuxnet%20impact&source=web&cd=12&ved=0CDQQFjABOAo&url=http%3A%2F%2Faccelconf.web.cern.ch%2Faccelconf%2Ficalepcs2011%2Fpapers%2Ffraault02.pdf&ei=9cqxUdyhGqvc4QS3pICwAg&usg=AFQjCNEHBaLmLSnF5Ke1M_Y4W6nMSfJkZw&bvm=bv.47534661,d.bGE&cad=rja

http://www.hannovermesse.de/de/ueber-die-messe/programm/leitmessen/industrial-automation/programm/industrial-security-product-protection

http://www.hannovermesse.de/de/ueber-die-messe/programm/leitmessen/industrial-automation/programm/industrial-security-product-protection

http://www.embedded-world.de/de/presse/presseinformationen/embedded-world-2013-safety-and-security-im-fokus--pressnews--/?focus=de&focus2=nxps%3A%2F%2Fnueme%2Fpressnews%2F68ed7cfc-1abf-4443-aa75-cb1a3896a353%2F%3Ffair%3Dembedded%26language%3Dde

http://www.embedded-world.de/de/presse/presseinformationen/embedded-world-2013-safety-and-security-im-fokus--pressnews--/?focus=de&focus2=nxps%3A%2F%2Fnueme%2Fpressnews%2F68ed7cfc-1abf-4443-aa75-cb1a3896a353%2F%3Ffair%3Dembedded%26language%3Dde

http://blog.siemon.com/standards/ieee-p802-3bj-100-gbs-backplane-and-copper-cable-task-force

http://blog.siemon.com/standards/ieee-p802-3bj-100-gbs-backplane-and-copper-cable-task-force

http://standards.ieee.org/news/2013/400gbs_ethernet.html

http://support.automation.siemens.com/WW/llisapi.dll?aktprim=0&lang=en&referer=%2fWW%2f&func=cslib.csinfo&siteid=csius&load=content&groupid=4000002&extranet=standard&viewreg=WW&nodeid0=48803858&objaction=csview

http://www.iebmedia.com/?id=8595&parentid=74&themeid=255&showdetail=true&bb=true&PHPSESSID=5rj4hpmcubog5s5vlv4jkhlhd2

http://www.soi.city.ac.uk/~gespan/ijcis06.pdf

http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx

http://technet.microsoft.com/en-us/library/hh750618(v=sql.10).aspx

http://patterns.projects.cis.ksu.edu/

04/07/2013 Pag. 86 IoT@Work/WP1/D1.3/1.0


7 Appendix A – Generic Requirements List

In this appendix we report the generic requirements described in D1.2.

7.1 Requirements Template

The following template has been used in IoT@Work to specify all identified requirements. An explanation of all different fields is given below the template.

Requirement

Description

Rationale

Fit Criteria

Type Target Priority Category

Date History Reference

Table 7.1 – Template for IoT@Work requirements

Requirement

Descriptive title of the requirement

Description

A detailed description of the purpose and the objective of the requirement.

Rationale

This field applies to specific requirements only. It describes the rationale of this requirement, i.e. the reference to all relevant generic requirements.

Fit Criteria

This field describes the metric or the measure against which, the achievement of the requirement can be measured. This measure could also describe a process or test procedure.

ID

A unique identifier for the requirement that consists of two parts: the first part consists of one letter for the generic requirements and two letters for the specific requirements; the second one is a number starting with 01. The first letter is always an “R” for requirement. The second letter represents a specific functionality of the system which is addressed by this requirement.

04/07/2013 Pag. 87 IoT@Work/WP1/D1.3/1.0


Generic requirements

ID Related to

Rxx Requirement number and ID

Specific requirements

ID Related to

RC.xx Common specific requirement

RE.xx Event notification

RM.xx Event monitoring

RO.xx Application configuration and orchestration

RB.xx Device bootstrapping

RN.xx Network

RS.xx Security

Table 7.2 – Possible IDs for generic and specific requirements

Type

The type of a requirement can be either functional or non-functional.

Some metrics for non-functional requirements could be:

Size, e.g. Mbytes, Number of ROM chips

Usability, e.g. training time, number of help frames, task completion time

Portability, e.g. percentage of target-dependent statements, number of target systems

Speed, e.g. transactions per second, user/event response time, screen refresh time

Reliability, e.g. mean time to failure, probability of unavailability, rate of failure occurrence, availability

Robustness, e.g. time to restart after failure, percentage of events causing failure

Target

The target can be either Existing or IoT@Work. If it is Existing, the requirement has to be fulfilled by an existing technology, in order to be integrated in, or used by, the IoT@Work architecture. If it is IoT@Work, the requirement has to be met by new developments realized within IoT@Work.

Priority

States whether the requirement is critical for IoT@Work (Highest), less critical (High) or it simply provides enhanced features for the IoT@Work architecture (Normal)..

04/07/2013 Pag. 88 IoT@Work/WP1/D1.3/1.0


Category

The list of possible categories for a requirement and its short explanation is defined in Table 7.3. The list can be expanded on demand.

Category Short Form Description

Network NW Requirements related to the network

Production PR Requirements related to the production system

General GE Generic requirement for IoT@Work

Security SE IT-Security -related Requirement

Engineering EN Engineering-related Requirement

(requirements for interaction with engineering tools and processes)

Table 7.3 – Range of categories.

Date

Month, when the requirement was originally raised, format: mm/yyyy (e.g.: 10/2010)

History

History of all major modifications of the requirement, including the reason(s) for the changes. First the date of the modification has to be stated. Separate rows are used for different changes.

Reference

In this field, a reference to already existing requirements (either higher-level or scenario-related) is provided.

7.2 Requirement Catalogue

Requirement

System extensibility / Extensibility

Description

The system shall allow extensions and changes at run-time, while the productivity of parts of system is not affected. For instance, changes in parts of system that are not involved in production. Possible changes are: adding of new devices, network reconfigurations, or software-element changes/extensions. It shall be easy to add new services, new technologies, systems, or devices. This will, for instance, affect the number of IP addresses needed for the network.

Rationale

N/A

ID Type Target Priority Category

R01 Functional IoT@Work Highest Network/Production


01/2011 A01, B04

04/07/2013 Pag. 89 IoT@Work/WP1/D1.3/1.0


Requirement

Fast re-initialization

Description

The system shall be capable of a fast re-initialization after system extensions or changes in the off-line system state.

Rationale

N/A




01/2011 A02

Requirement

Controlled initialization

Description

The system shall be initialized in a controlled manner whenever it has been extended or changed (e.g. limited network access, limited access rights until authentication of device/software element)

Rationale

N/A


R03 Functional IoT@Work High Network/Production


01/2011 A03

Requirement

On-demand path reconfiguration

Description

The system shall support the reconfiguration of network paths in the case of a path failure. For instance, by means of redundancy protocols. Redundancy can be solved by soft-states (stand-by paths, etc) or by using fast path finding protocols.

Rationale

N/A


R04 Functional IoT@Work Highest Network


01/2011 A04

Requirement

Fast network bootstrapping

Description

The bootstrapping of the whole network shall be fast to guarantee a rapid system start-up, i.e. in the order of a few seconds. However, complexity, topology, and size have to be taken into account. The network configuration should be as autonomous as possible, including automatic routing, reservation, structuring, and optimization of network resources.

Rationale

N/A




01/2011 A05

04/07/2013 Pag. 90 IoT@Work/WP1/D1.3/1.0


Requirement

Support of device migration

Description

Configuration changes due to device migration shall be facilitated in a smooth and fast manner so that it becomes as little intrusive as feasible for the production process, i.e. it has to get immediately back into a productive state.

Rationale

N/A




01/2011 A06

Requirement

Auto-configuration

Description

Manual configuration efforts of single nodes or network components caused by any type of change should be reduced to a minimum. Automatic decision making is desired, which is able to deal with failures. An example is whether there is sufficient redundancy to deal with a certain type of failure, or whether there is the need to resort to the stop/safe state of the system.

Rationale

N/A




01/2011 A07, A08

Requirement

Easy-to-use system management tools

Description

System management tools that ease the execution of repetitive, complex, highly-error-prone actions are required. For instance, a graphical network configuration application that allows a drag & drop device configuration, or a graphical network maintenance application that highlights and localizes network failures. Another example applying remote maintenance scenarios would require a management tool that locates and accesses the root-cause device (with read-only access rights). The tools shall take into account that users of configuration and management tools have different skills (and could also have no specialized network knowledge, i.e. the tools have to be intuitive and easy to use.

Rationale

N/A


R08 IoT@Work High Network


01/2011 B06, C02, Security Requirements in D3.1

Requirement

Semantic naming/addressing and identification of devices

Description

Fast and reliable semantic naming and addressing (avoid static IP) of a device shall be possible. For instance, before maintaining a device, it has to be clearly identifiable in a distributed system.

Rationale

N/A




01/2011 C01, Security Requirements in D3.1

04/07/2013 Pag. 91 IoT@Work/WP1/D1.3/1.0


Requirement

Authenticity and integrity of message datagrams

Description

The authenticity, integrity, and validity of message datagrams in the system have to be ensured in order to detect injected false, or tampered, message datagrams.

Rationale

N/A




01/2011 Security Requirements in D3.1

Requirement

Automatic system diagnosis

Description

The actual system set-up (topology, address configuration, etc.) shall be automatically checked against an existing plan. This might support the prediction, detection, and localization of failures. Furthermore, anomalies of the system shall be detectable (e.g., traffic congestions, etc.).

Rationale

N/A


R11 Functional IoT@Work High Network



Requirement

High availability

Description

System redundancy shall be provided, as well as well-structured, independent sub networks. Fast and easy replacement of defect equipment is also related to this requirement. This requirement is more targeting system entities such as services and application redundancy since network redundancy is covered by requirement R04.

Rationale

N/A




01/2011 B01, C04, Security Requirements in D3.1

Requirement

Self-sufficient operation of systems

Description

For the installation, configuration and testing, the respective parts of the automation network shall be capable of running on their own, viz. without the backbone.

Rationale

N/A


R13 Functional IoT@Work Normal Network


01/2011 B02

04/07/2013 Pag. 92 IoT@Work/WP1/D1.3/1.0


Requirement

Clonability

Description

As smaller or larger parts of a manufacturing system will be installed multiple times in the factory (i.e. many identical welding cells), it shall be easy to copy the configuration and the control software of such cells.

Rationale

N/A


R14 Functional IoT@Work Normal Network/Production


01/2011 B03

Requirement

System and devices compliance with security policy

Description

Devices and virtual entities in an automation environment shall comply with security policies. Devices and virtual entities not complying with security policies shall be detected and handled in an appropriate way. Remote access has to be enabled for authorised people only.

Rationale

N/A




01/2011 C03, Security Requirements in D3.1

Requirement

Secure remote diagnosis and maintenance

Description

The system shall enable external support; viz. a remote access to the relevant parts (plant systems or data) shall be possible. Furthermore, remote access has to be provided in a sufficient quality (ease, promptness, etc.) to guarantee a good usability.

Rationale

N/A


R16 Functional IoT@Work Highest Production


01/2011 B07, Security Requirements in D3.1

Requirement

Company-wide access

Description

Devices and services shall be reachable from anywhere in the company. This requirement mainly addresses issues considering address rooms (NAT or flat IP address space) and the structuring of security realms.

Rationale

N/A




01/2011 B08

04/07/2013 Pag. 93 IoT@Work/WP1/D1.3/1.0


Requirement

Secure inter-site communication

Description

Reliable and highly available intercommunication providing confidentiality and integrity of data on public and enterprise networks. The robustness of internal processes of separated sites has to be always guaranteed.

Rationale

N/A


R18 Functional IoT@Work Normal



Requirement

Accountability of interactions

Description

Actions of an entity shall be traced uniquely to that entity [Ref. to NIST-IR-7298].

Rationale

N/A


R19 Functional IoT@Work Highest



Requirement

Scalability

Description

The system is able to deal with large scale of both software and physical entities. This requirement is non-functional and entails dealing with complexity for most developed functions.

Rationale

N/A


R20 Non-functional IoT@Work Highest


01/2011 D1.1 scenarios large scale manufacturing.

Requirement

Reliability

Description

This requirement goes beyond availability of the system and its functions or basic services. The latter building blocks should be reliable and the effect of their failure considered during the operation of the system (failure tolerance). Additionally, access to certain resources should be guaranteed in a reliable manner. An example would be that a bandwidth guarantee is reliable.

Rationale

N/A


R21 Non-functional IoT@Work Highest


01/2011 Additional comments from Error! eference source not found.

04/07/2013 Pag. 94 IoT@Work/WP1/D1.3/1.0


Requirement

IPv6 Support

Description

All IoT@Work devices and services shall be able to use IPv6 natively. For migration support and inclusion of legacy devices, IPv4 (and/or dual-stack) is optionally allowed. Notice that this may also require IPv6 compatibility for layer-two devices (i.e. switches).

Rationale

Many general requirements (R01, R10, R14, R17) are difficult (read: costly) to achieve with IPv4 Market trends show that IPv6 solutions must be available soon also for the automation part


R22 Functional IoT@Work High


09/2011 Additional requirement from trends in [3]

04/07/2013 Pag. 95 IoT@Work/WP1/D1.3/1.0


8 Appendix B – Specific Requirements List

In this appendix we report the specific requirements as defined in D1.2

Common specific requirements

Requirement

Smooth scaling

Description

The system shall smoothly support the addition of new devices, services, and applications.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility – run-time changes shall not affect the system and

horizontal scalability implies a smooth and easy addition of new devices as well as new services and systems. R06 Support of device migration – an effective horizontal scalability helps in shortening the time required for system re-configuration after device migration. R12 High availability – smooth scaling implies that devices and applications can change/migrate easily at run-time without affecting the overall system. R20 Scalability – same as R01.

Fit Criteria

The event notification service shall support a smooth horizontal scalability of publishers and subscribers and an effortless change/migration of publishers and subscribers. An access control mechanism such as the Capability-Based mechanism helps achieving a good level of scaling as each new/changed device holds its own capability (or just its reference) with no need to define a role and an entry in an access credentials repository for the newly created/changed device.


RC.01 Non-functional IoT@Work Normal GE

Date History

09/2011

Requirement

Auditability and Accountability

Description

Operations performed in the system shall be tracked uniquely to the entity that generated it. It shall be possible to retrieve users and/or devices that carried out or are in charge of the activities in the system.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R16 Secure remote diagnosis and maintenance – logging and audit information are necessary for detection and prevention of failures in the system. R19 Accountability of interactions – “auditability” and accountability are core system

constraints.

Fit Criteria

The event notification service shall support the definition of logging and audit namespaces, under which to publish events that are useful for achieving an acceptable level of “auditability” and accountability. The access control mechanism shall support the accountability and the “auditability” of the activities performed within the system.


RC.02 Non-functional IoT@Work High GE

Date History

09/2011

04/07/2013 Pag. 96 IoT@Work/WP1/D1.3/1.0


Requirement

Interoperability

Description

The ISO standard IEC25010 defines software interoperability as the "degree to which two or more systems, products or components can exchange information and use the information that has been exchanged". An acceptable level of interoperability requires that the communication and interaction of

system components shall be based on standard interfaces and protocols completely understood and comprehensive to work together without – or at least minimizing – any implementation restriction or legacy integration problems.

Rationale

The specification of this requirement is due to the identification of the following generic requirement: R16 Secure remote diagnosis and maintenance – interoperability allows external entities and persons to monitor the production environment by using the communication protocol common to/shared with all other components and arranged ad-hoc links.

Fit Criteria

The Event Notification Service shall be based on interoperable mechanisms of communication such as AMQP, which provides both a communication-protocol and a communication-model specification that realizes both syntactic and semantic interoperability. The access-control mechanism shall be based on widely accepted standards and interoperability mechanisms (and, if necessary, well defined extensions) such as the usage of XML and related standards for encoding and structuring the authentication tokens to be exchanged.


RC.03 Non-functional IoT@Work High GE

Date History

09/2011

Requirement

Provision of semantically enriched information about devices

Description

The system shall provide semantically enriched information about the devices in the production field to both human users and software entities.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R07 Auto-configuration – semantic information about devices can support auto-configuration

tasks. R08 Easy-to-use system management tools – semantic information about devices can support automatic decision making and detection of failures. R09 Semantic naming/addressing and identification of devices – the basic identification of a

device in a distributed system can be enhanced by semantically enriched information relating to the device itself. R16 Secure remote diagnosis and maintenance – semantic information about devices enriches the description of the current condition of devices and helps with detecting failure causes.

Fit Criteria

The system shall provide proper mechanisms to enrich device descriptions with semantics. The system shall allow to access and query the repository of device semantics.


RC.04 Functional IoT@Work Normal GE

Date History

09/2011

04/07/2013 Pag. 97 IoT@Work/WP1/D1.3/1.0


Requirement

Standardisation of entity semantics

Description

Semantically enriched information about entities (such as devices and events) shall be based on widely agreed and comprehensive standards in order to help to achieve a shared/common understanding of the system state.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R09 Semantic naming/addressing and identification of devices – semantics standard can be

used to enrich the basic identification and localization of devices.

R08 Easy-to-use system management tools – the use of standards for semantically enriched information eases the creation of tools for supporting activities as well as helps the creation of a common and well understood knowledge base.

R16 Secure remote diagnosis and maintenance – standard semantics can support interoperability between monitored and monitoring devices.

Fit Criteria

Usage of widely agreed semantics standard to enrich the description of the entities in the system.


RC.05 Non-functional IoT@Work Normal GE

Date History

09/2011

Event notification service requirements

Requirement

Process-data provision/dissemination

Description

Process-data provision/dissemination aims at providing data to both internal and external stakeholders instead of providing direct access to internal data sources or systems. In this way, data owners/providers gain full control about which data is exposed.

Rationale

The specification of this requirement is due to the identification of the following generic requirements:

R08 Easy-to-use system management tools – process data coming from the field can be used by this tool to localize and detect network failures.

R16 Secure remote diagnosis and maintenance – external entities and persons can monitor the production environment without accessing production devices.

R17 Company-wide access – data and events relating to devices and resources within the company can be delivered and consumed within the company.

Fit Criteria

The system shall have a middleware service dealing with process-data delivery based on a reversed/push approach.


RE.01 Functional IoT@Work High

Date History

09/2011

04/07/2013 Pag. 98 IoT@Work/WP1/D1.3/1.0


Requirement

Event processing

Description

The system shall be able to: Detect situations and patterns among events collected from the production field; Provide functionalities supporting business processes that monitor events and enable autonomous reactions according to the current system condition.

Rationale

The specification of this requirement is an interpretation of the following generic requirements: R07 Auto-configuration – event processing can help the automatic detection of failures and unusual conditions. R08 Easy-to-use system management tools – event processing supports automatic decision making and planning for restoring actions. R16 Secure remote diagnosis and maintenance – maintenance is based on the detection of the current condition of devices.

Fit Criteria

The system has services that collect and deliver data from the production field to the interested applications. The event processing middleware shall provide functionalities allowing/supporting the definition of rules and or patterns against which events are compared. The system should have and/or support components that analyze events originating in the field in a computing- or detection-based way (for example Complex Event Processing Engines).


RE.02 Functional IoT@Work High

Date History

09/2011

Requirement

Provision of semantically enriched information about events

Description

The system shall provide semantically enriched information about events originating from the production field to both human users and applications / services.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R08 Easy-to-use system management tools – semantic information about events in the production field can support automatic decision making and detection of failure. It can also help with understanding the semantic of events. R09 Semantic naming/addressing and identification of devices – naming and addressing

information about devices can be enriched by the semantic data relating to the events generated by such devices. Furthermore, the identification of a device in a distributed system can be enhanced by semantically enriched information relating to the events it can provide. R16 Secure remote diagnosis and maintenance – semantic information about events can

enrich the description of the current condition of devices and help in detecting failure causes.

Fit Criteria

The system shall provide proper mechanisms to enrich event descriptions with semantic information The system shall allow to access and query the repository of event semantics.


RE.03 Functional IoT@Work Normal

Date History

09/2011

04/07/2013 Pag. 99 IoT@Work/WP1/D1.3/1.0


Requirement

Graphical event namespace management tool

Description

The hierarchical structure of the event namespaces shall be defined by the user possibly through a graphical tool which renders the namespaces using a tree widget.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility – the event namespace is a hierarchical structure. Therefore, its higher levels are quite static, indeed the adding of new devices usually involves the low levels are changed to map the change of the source device. R06 Support of device migration – same as R01. R08 Easy-to-use system management tools – it helps un- and low-skilled users to define and manage the event namespaces. R14 Clonability – this tool can avoid repeating tasks when defining Event Notification Service namespaces (i.e. if a namespace reflects the configuration of a cell and such configuration is repeated for all cell within a plant, then the tool can automatically propose the same namespace structure for all cells).

Fit Criteria

Presence of a graphical tool for event-namespace management.


RE.04 Functional IoT@Work Normal

Date History

09/2011

Event monitoring and reasoning system requirements

This section describes the functional and non-functional requirements that pertain to the Event Monitoring and Reasoning System (EMS) that is part of the IoT@Work architecture.

Requirement

Run-time verification of system events

Description

The EMS shall verify system events at run-time against event rules.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R11 Automatic system diagnosis – the EMS is used to monitor that the actual system set-up is meeting the predefined properties of the system. It does so by monitoring the events that relate to system (re-)configurations and tracking through these the evolution of the system. It also uses system events to track the behaviour of the system with respect to non-functional properties, such as high response times. R15 System and devices compliance with security policy – the EMS is used to monitor that the security policies are not being violated, by matching security-related events (connections to services, logins, etc.) against rules representing the security policies.

Fit Criteria

EMS shall be able to treat events of different types. These types will be defined according to a generic schema.

EMS shall be able to process policies expressed in a generic language.


RM.01 Functional IoT@Work Normal

Date History

09/2011

04/07/2013 Pag. 100 IoT@Work/WP1/D1.3/1.0


Requirement

Explicit representation of system set-up.

Description

The EMS shall allow the representation of the system set-up.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R11 Automatic system diagnosis – the EMS is used to monitor that the actual system set-up is meeting the predefined properties of the system. It does so by monitoring the events that relate to system (re-)configurations and tracking through these the evolution of the system. It also uses system events to track the behaviour of the system with respect to non-functional properties, such as high response times. R15 System and devices compliance with security policy – the EMS is used to monitor that the security policies are not being violated, by matching security-related events (connections to services, logins, etc.) against rules representing the security policies. The aforementioned generic requirements and the requirement RM.01 imply the need for an explicit representation of the system set-up at an architectural level, so that it is possible to track the currently available components, their state (e.g., functioning, faulty, under maintenance, etc.)

Fit Criteria

EMS shall be able to represent system components and their state.

EMS shall be able to represent system connectors, i.e., the interaction protocols used among the system components.



Date History

09/2011

Requirement

Ability to pre-compile monitoring rules

Description

The EMS shall pre-compile monitoring rules, identifying rule interactions (or lack of such), structuring the tests that will be performed on each new event to ensure that all applicable rules have been covered. Pre-compilation should be able to stop after a depth D of inferences have been performed – a rule can infer some derived (i.e., non-observable) event, which causes another rule to be evaluated and so forth.

Rationale

Pre-compilation of monitoring rules is needed for the following reasons: Aid engineers in specifying correct monitoring rules by showing them how these interact and how events will be treated by the system. Facilitate the optimisation of rules. Facilitate the distribution of the monitoring logic at different nodes. Allow the bounded execution of the monitoring rules at run-time, to ensure a real-time behaviour.

Fit Criteria

A set of test sets shall be evaluated to increase confidence into the correctness of the compilation scheme.



Date History

09/2011

The EMS in its turn depends on events arriving without delays and in the order they were produced.

04/07/2013 Pag. 101 IoT@Work/WP1/D1.3/1.0


Specific requirements of application configuration/orchestration

Requirement

Avoid undesired interference and respect operational constraints of automation system when carrying out system adaptation/update/maintenance/configuration

Description

When carrying out system adaptation/update/maintenance/configuration, and generally when (remotely) accessing the system, there shall not be any undesired interference with the automation system. The constraints of the automation system, in relation to the access operations, must be understood, captured, and respected.

Rationale


Extending a system likely involves adding new devices, new configurations, new bindings to new services, as well as performing actions (management or other) to get these changes operational. Any of such actions must be done in a dependable way. This particularly includes respecting any operational constraints coming from the system that is to be extended (for instance, “do not disturb the running automation system”). R03 Controlled initialization When operational constraints coming from the system, need to be respected when extending/adapting the system, specific control mechanisms can be required to technically enforce respecting such operational constraints. R15 System and devices compliance with security policy Dependability is an important aspect here. When we access the system (e.g. for maintenance or for adaptation), we do not want (undesired) interference with the operational system. Current best practice is to deal with this in a very ad-hoc fashion, i.e. only allow forms of access that will not interfere anyway (e.g. monitoring); don't allow any access at all; only allow access in very restricted and few time windows in which the operational system is shutdown.

Fit Criteria

Ability to express the relevant operational constraints that need to be respected. Ability to monitor/track whether and when the relevant operational constraints are satisfied (or not). Ability to trigger/perform system adaptation action when expressed operational constraint is satisfied.


RO.01 Non-functional IoT@Work Normal General/Network/Security

Date History

09/2011

04/07/2013 Pag. 102 IoT@Work/WP1/D1.3/1.0


Requirement

Correctly carry out system adaptation/update/maintenance/configuration, respecting dependencies between individual adaptation/update/maintenance/configuration operations

Description

Any kind of system adaptation/update/maintenance/configuration will involve multiple, individual management and other operations. There will often be dependencies between these operations. These dependencies must be respected for dependability reasons in general, and in particular in order to ensure a correct overall system adaptation/update/maintenance/configuration.

Rationale


When adding new devices, new configurations, new bindings to new services, performing actions (management or other) to get these changes operational, then this must be done in a dependable way. In addition to respecting operational constraints from the running system (see previous requirement), dependability also includes respecting any possible dependencies between different actions (management or other). R03 Controlled initialization Control can be supported/enhanced by including individual control operations (including security management) as part of overall system adaptation/update/maintenance/configuration, with dependencies on individual system adaptation/update/maintenance/configuration access operations. Example scenario: limit network access to a set of devices, such that they can still carry out priority operations (for instance, they cannot be remotely maintained anymore); start rolling out security patch to these devices; automatically re-grant full network access to every device that got successfully patched.

Fit Criteria

Ability to express the relevant dependencies between system adaptation actions. Ability to schedule, trigger, and monitor success of system adaptation actions, in relation to expressed dependencies.



Date History

09/2011

04/07/2013 Pag. 103 IoT@Work/WP1/D1.3/1.0


Requirement

Facilitate/automate system adaptation/update/maintenance/configuration with high complexity

Description

Overall system adaptation/update/maintenance/configuration will often consist of applying the same set of management and other actions to a large amount of devices. An overall system adaptation/update/maintenance/configuration may also involve a large amount of dependencies between individual management and other actions.

Rationale


When adding new devices, new configurations, new bindings to new services, performing actions (management or other) to get these changes operational, then this must be done in a dependable way. This includes avoiding time-consuming and error-prone approaches. In other words, one needs to be able to automate this). R02 Fast re-initialization

When re-initialization requires a set of actions to be performed, then if those actions and any dependence between them and constraints upon them can be captured by declarations, an orchestration engine can automatically schedule and trigger those actions while respecting dependencies and constraints. So doing can contribute to fast re-initialization. Notice that we particularly consider speeding up an overall set of actions that can run in parallel; we do not particularly speed up a single action as such. R15 System and devices compliance with security policy Particularly, when a system adaptation/update/maintenance/configuration involves a set of similar actions on a large amount of devices, with each having specific constraints and dependencies, then care must be taken that there occur, for instance, e.g. no security misconfigurations that are introduced due to a manual and error-prone approach.

Fit Criteria

Ability to automate scheduling and triggering of system adaptation actions. Scalability of the approach.



Date History

09/2011

Specific requirements affecting device bootstrapping

The following requirements refer to devices in an arbitrary environment, especially - but not exclusively – considering the bootstrapping process. Consequently, there are four types of requirement:

those referring to the devices (i.e. things),

those referring to the network including network devices,

those referring to the environment, context, or infrastructure in which the devices are supposed to operate,

those referring to the bootstrapping process which is executed by both the devices and the infrastructure.

The scenario of the device bootstrapping, according to Deliverable D2.2 [5], is summarized in the following steps:

Offline Configuration.

This step prepares the device by means of pre-configuration and eventually tests the device – respective its services – before it actually gets mounted.

Commissioning – physical mounting of the device.

Eventually connect power supply, network cables and sensors/actuators.

04/07/2013 Pag. 104 IoT@Work/WP1/D1.3/1.0


Power On

Upon power-on, the devices may start the actual bootstrapping process, i.e. perform self-tests, start the operating system, configure defaults for addresses or service specific parameters.

Basic Connectivity – start communication services.

Middleware Booting – i.e. discovery of device external supplementary services and servers.

Application Service Boot.

Requirement

Standardized Device Pre-Configuration (Device Requirement)

Description

This requirement results from a mix of generic requirements that describe the way bootstrapping or changes occurs involving end-devices in the IoT@Work system. There has to be a standardized "one conf fits all" pre-configuration provided by the vendor of the device. All users or owners

6 of the devices can rely on that configuration. In other words: The device

vendor is not supposed to provide any customer or application specific device configuration. In the best case, even two devices of different types (e.g. a heat sensor and an acoustic sensor) or devices belonging to two different categories (a sensor and an actor) provide the same pre-configuration. This requirement implies each device to provide a certain amount of memory, an appropriate CPU, and a network interface along with a standard network protocol. This Requirement, furthermore, enables the vendor to supply devices at a better rate compared to specific pre-configuration.

Rationale

This requirement is a specification of the generic requirement R03 Controlled initialization. It also provides an indication of the type of devices considered in the IoT@Work project (at the time of writing of this deliverable).

Fit Criteria

All devices send identical default messages upon power-on and react on identical test messages in the same way.


RB.01 Non-functional IoT@Work Normal

Date History

08/2011

6 The distinction between "user" and "owner" of a device refers to the roles and competencies of

components and people: owners (may be also "providers") manage devices, users apply the related services. Therefore, owners are responsible for the bootstrap. However, in the following we will refer to the term users for simplicity.

04/07/2013 Pag. 105 IoT@Work/WP1/D1.3/1.0


Requirement

Minimum User Interaction for Pre-Configuration (Device Requirement)

Description

This requirement states that the configuration work the vendor is relieved of according to Requirement RB.01, must not be assigned to the user. In the first case, the device costs would grow while in the second case the work load for bootstrapping rise. In fact, this requirement is reasonable only if Requirement RB.01 is satisfied, too. Both requirements provide affordability of the appropriately pre-configured devices.

Rationale

This is a specification of the generic requirements R07 Auto-configuration and R08 Easy-to-use system management tools.

Fit Criteria

All devices send identical default messages upon power-on and react on identical test messages in the same way without and preceding user interaction.



Date History

08/2011

Requirement

Availability of Basic Infrastructure (Environment Requirement)

Description

The Infrastructure provides the necessary physical resources to run the device: Power supply Communication infrastructure wireless or networked (e.g. if there is too much noise in the air) Whenever a device or an entity needs to start its bootstrapping process, the environment is ready for that by providing the necessary basic functions such as the software components (services, functions) necessary for the boot process.

Rationale

This requirement is based on the generic requirement R12 High availability, which is here translated to

availability of system infrastructure around the managed device.

Fit Criteria

The bootstrapping network manager or orchestration functions can allow a soft state entry for each device that is checked at arbitrary occasions through pings and hallo messages. This requirement is a non-functional requirement affecting all function groups related to device availability and status.



Date History

08/2011

04/07/2013 Pag. 106 IoT@Work/WP1/D1.3/1.0


Requirement

High reliability (Environment Requirement)

Description

Besides pure physical availability, the bootstrap process needs to be executed in a robust, fault tolerant, and reliable environment. This holds particularly for the capacities of the networks and the power supply. This holds particularly, if a power outage causes all devices to reboot at the same time. In a more extreme situation, all devices could also execute a plug&work process at the same time, in case all devices are installed and start jointly signal on power-on. In case a huge quantity of devices is switched on synchronously or within a narrow time frame, neither the power supply must break down, nor must the communication network collapse. Furthermore, the software components providing the counterpart of the device in the bootstrapping processes are required to reliably interact with the devices. The bootstrap process must achieve the same result independently from the number of devices booting concurrently. This requirement complements the requirements RB.03 which guarantees unlimited availability of the environment resources in time and space while this one guarantees a sufficient availability.

Rationale

This requirement specifies how the generic requirement R21 (Reliability) can be interpreted. It reliability qualifies the way availability shall be guaranteed. It also requires a failure tolerance analysis, when possible.

Fit Criteria

Stress test, Simulation



Date History

08/2011

Requirement

High scalability (Process Requirement)

Description

Since automation systems may grow and hence include an increasing number of devices, the bootstrap process must be able to handle an arbitrary quantity of sensor, actors and control units. Therefore, a good adaptability of the bootstrapping process is needed. The requirement for scalability refers to the ability of a system to easily handle a growing load. If the load of the system increases by a factor N, then the N-fold of the resources will be able to handle the load. Here, the requirement is focused on horizontal scalability which refers to an expansion of the system by similar components. In other words, if the system architecture and process are able to handle the bootstrap, the same architecture and process are able to handle a hugely extended system by just multiplying the resources. This requirement complements with RB.04 which guarantees sufficient capacities regarding power, network transfer rates and software components for a fixed system size with a more or less constant number of devices. (We do not refer to vertical scalability in this place because vertical scalability always implies investment in replacing components while producing garbage: e.g. copper by fiber cable replacement or PC to Workstation upgrade.)

Rationale

Here, we address an increasing number of devices, which is mentioned in the generic requirement R20 (Scalability).

Fit Criteria

Instead of checking the system performance for an increased number of devices, check whether the systems requires half of the time and resources if half number of devices and components are booting.


RB.05 Functional IoT@Work Normal

Date History

08/2011

04/07/2013 Pag. 107 IoT@Work/WP1/D1.3/1.0


Requirement

Dead-lock avoidance (Process Requirement)

Description

In the least complex dead-lock case, two devices or components can boot only if the other one is already in operation. Such dead-lock situations cannot be excluded. So this requirement actually demands a strategy or policy for dead-lock prevention in case a component or device persists in a wait state for a certain range of time assuming a resource access is failing. This kind of dead-lock differs to others where two shared resources are requested by two users each of which has already occupied one. A useful resolution strategy for this kind of dead-lock is based on releasing resources and starting over after an arbitrary time-out. Such a resolution strategy does not work here since two components mutually wait for a certain state to be assumed. The component or device could move into an intermediate operating state which allows restricted access and service provision while later catch up with the skipped boot phase.

Rationale

Deadlocks could result from the security requirements such as generic requirements R15 System and devices compliance with security policy, R19 Accountability of interactions. These requirements define some access policies and correctness, in which case, some deadlock situation can occur.

Fit Criteria

Components shall always be in a defined state, even if errors or dead locks in the bootstrapping phase occur. Watchdogs and other means to trigger retries must ensure a re-boot of single parts of a device in case formerly not available resources are available again.



Date History

08/2011

Requirement

Updatable soft- and firmware (Device Requirement)

Description

It must be possible to update the SW on a device in order to extend functionality, fix bugs or provide security updates. It must be possible to do this stand-alone in commonly used state-of-the-art devices, i.e. by means of a locally attached programming device. But it must also be possible to do this remotely in order to enable low-effort updates in scenarios where remote management should be used or in order to support mass-updates of many devices. The device must have an interface to describe current SW/FW versions. To allow safe updates in a live system, the device must be able to tell the actual state (i.e. is it working) and to shut down and restart the device or services on it. SW/FW updates must use a secure mechanism in order to avoid unwanted changes. The device must have a mechanism to handle failures in the update process (i.e. "reset to defaults", undo).

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility – updatable SW helps in extend functionality and in

modernizing the equipment. R20 Scalability – remote management and updates are an essential enabler for highly scalable systems

Fit Criteria

a) The device has an interface which describes the updatable parts of its SW/FW b) The device has a secure interface to stop and restart services c) The device has a secure interface to upload new SW versions

Corresponding function: Orchestrated Management affecting all types of devices.


RB.07 Functional IoT@Work High

Date History

09/2011

04/07/2013 Pag. 108 IoT@Work/WP1/D1.3/1.0


Requirement

Network access control client

Description

The IoT@Work system will have security policies on various layers. If a device (respective its local services) is not capable of performing the needed steps requesting access rights to certain resources, it can only operate in a restricted and predefined mode which would limit the flexibility of a device. This is especially true for the network access. For each network interface, the device must be able to authenticate against the "network" in order to be able to use the needed communication resources (i.e. bandwidth). While basic access rights may be enforced and controlled by a proxy device (i.e. the adjacent switch), re-negotiation and on-demand resource allocation requires an entity on the device to do so. Possible implementation means include IEEE 802.1x for WLAN and Ethernet interfaces. This requirement is not only important for the bootstrapping, it is needed to refresh (and eventually change) the access control state in the running system as well.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled Initialization R15 Systems and devices compliance security policy

Fit Criteria

The device is able to "unlock" access to the network which is disabled by default. Function: Network Access Authority


RB.08 Functional IoT@Work High

Date History

09/2011

Requirement

Reasonable computing power

Description

Basically a device must be able to run a standard operating system and it must have enough computing resources for the IP network stack, security and management functionality, the agents for the event notification system and in the best case enough spare computing power for new functions (upgrades). Note, to fulfill other requirements, it will be beneficial if there is even enough power (and memory) to use byte code or script interpreters (i.e. Java or Javascript) to enable applications which are independent from the underlying processor and OS. Examples here are the Android OS or the OSGI middleware. Along with the sheer computing go requirements to have enough on-device memory, also non-volatile read/write memory. One consequence for the bootstrapping process is that the OS must allow for a fast boot (see the Fast Network Bootstrapping Support requirement). As an analogy, we demand for a shift from simple, mainly ASIC-driven phones to smart phones with standard processor and standard operating systems. Essentially this means that even smaller devices which cannot fulfill those requirements (i.e. a RFID or an analogue sensor) must use proxies (i.e. the RFID reader or an I/O module) to be integrated into the IoT@Work system.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: many, cross requirement relevance

Fit Criteria

Ability to install and run own SW on the device which is not included in a firmware image


RB.09 Non Functional

IoT@Work High

Date History

09/2011

04/07/2013 Pag. 109 IoT@Work/WP1/D1.3/1.0


Network specific requirements

The network specific requirements details the way the IoT network has to fulfil the communication needs of automation systems. The network function group includes all functions related to networked things and devices. Therefore, aspects of managing devices and things are also gathered in this section.

Requirement

Managed devices (Device and Network Requirement)

Description

A device must provide functions to monitor, control and manage it (respective its services). This is what current devices call a "managed device", which as of today basically demands for a SNMP agent. In our case a managed device shall additionally provide means for remote service management as well as a remote management of security credentials and SW/FW updates. Note: This requirement primarily targets network devices. However in some cases end devices will

have a hybrid role, i.e. in a daisy chain (line topology) an I/O device may play a role as a network device (switch) as well for its neighbors.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R06 Support of device migration R08 Easy-to-use system management tools R16 Secure remote diagnosis and maintenance

Fit Criteria

Device and service configurations and management tasks can be done over the network


RN.01 Functional IoT@Work High

Date History

09/2011

Requirement

Fast re-routing and forwarding manipulations (Network Requirement)

Description

To enable a seamless operation even in failure scenarios, the network must support very fast switching to alternate paths, be it on layer 3 (routing) or on layer 2 (forwarding). This capability is also important to enable load balancing. For the bootstrapping phase this means: a device may only start to forward packets other than the essential protocol exchange messages from routing/forwarding protocols after the respective routing/forwarding configuration has been completed there must be either an agreed set of protocols to enable self-configuration and/or an interface to a management station performing these configurations there must be a minimal preconfigured set of rules enabling the device to communicate with adjacent nodes before the routing/forwarding is stable Note: This requirement primarily targets network devices. However in some cases end devices will have a hybrid role, i.e. in a daisy chain (line topology) an I/O device may play a role as a network device (switch) as well for its neighbors.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R04 On-demand path reconfiguration

Fit Criteria

The device has a valid routing respective forwarding table after bootstrapping The device has its role in the network of other routing/forwarding devices (depends on the agreed method or protocol)



Date History

09/2011

04/07/2013 Pag. 110 IoT@Work/WP1/D1.3/1.0


Requirement

Fast network bootstrapping support (Device and Network Requirement)

Description

For the stable part of the network the time needed to integrate into that network is not essential. But in some cases devices frequently join and leave a network and then the re-connect time shall be as low as possible. Examples include: re-tooling of a robot, where the tool (which is a device or even a small network itself) must be operable in less than a second wireless nodes moving around: mobility however is a special case which is not a focus in IoT@Work devices with power-save modes wishing to temporarily leave the network and then probably come up again periodically While the lines above describe the requirement from a single devices point of view, there is also an aspect for the whole network, which is an assembly of devices. That is, the network is only fully operational if shared functions – most notably the routing or forwarding engines but also management functions – are working. Thus a device participating in the network must ensure that its role in these shared network functions are completed as fast as possible.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R05 Fast network bootstrapping

Fit Criteria

The re-tooling case: connecting an edge device to an already operational network should be completed in less than a second. Network devices shall integrate into a network in reasonable short time (concrete quantification to be done depending on the position and role of a device).



Date History

09/2011

Requirement

Scalability

Description

The system must be able to work with a high number of devices and services. There should not be a system inherent size or performance limit. A related requirement is the ability to enlarge or enhance performance of an existing system without changing too much. Affects network, addressing concept, middleware and higher layer services. Related performance parameters include number of devices and service end points, messages per second, bandwidth. Optionally, also geographical scalability (density of things per space or geographical dimension) could be considered.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System Extensibility / Extensibility R09 Semantic naming/addressing and identification of devices – without proper structuring of name spaces, address management does not scale. R14 Cloneabiltiy – assembling large scale systems demands for "mass production" of sub systems. R17 Company-wide access – large systems may use multiple geographically distributed sites.

Fit Criteria

adding new devices, sub systems or complete sites should not affect the rest of the system addressing and management should allow unlimited number of things extending the network capacity should not affect applications services must be scalable regarding performance (i.e. distributed servers, load balancers)


RN.04 Non-functional IoT@Work normal

Date History

09/2011

04/07/2013 Pag. 111 IoT@Work/WP1/D1.3/1.0


Requirement

IPv6 support (Network Requirement)

Description

All IoT@Work devices and services shall be able to use IPv6 natively. For migration support and inclusion of legacy devices, IPv4 (and/or dual-stack) is optionally allowed. Note, this may also require IPv6 compatibility for layer devices (i.e. switches).

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility trends in the market, standardisation and technology

Fit Criteria

System and devices are IPv6 compliant



Date History

09/2011

Requirement

Automatic/assisted network configuration

Description

During setting up the network, supporting means for the user when configuring the devices shall be provided. Approaches may range from a central management entity to a distributed self-organization of devices. The goal is to minimize time-consuming manual overrides and the detection of configuration errors. Three phases can be distinguished: (1) Network planning and design which belongs to the offline phase (cf. section 2.2.1), happens purely offline in engineering tools, and includes a first layout of networks (e.g. ring, trees), connecting nodes, cells, network management, control mechanisms, etc. (2) Network commissioning and basic connectivity belongs mostly to the offline phase as well. First, configuration and optimization of the network, offline or online, testing and optimizing configurations in the real network or in a tool, e.g. a simulator, are part of this phase. Afterwards, a basic connectivity is established as described in section 2.2.3. This also includes the start-up of core network services. (3) Network start-up, after having a basic connectivity established in phase 2, including that all core network services are running, the configuration can be downloaded to the network devices, followed by the start-up of the network. Phase 1 can be tool-supported; phase 2 should be widely automatic; phase 3 should be fully automated.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization R07 Auto-configuration R08 Easy-to-use system management tools.

Fit Criteria

a) Basic connectivity between all network nodes is available on powering-on the network. b) Automatic configuration of network paths without configuring protocol internal parameters in each node.

Function: “Topology & Link State Database”. Might rely on pre-configured data (i.e., generated in a planning tool – the latter tool is out of scope of this project!). Could be centralised or decentralised. For pre-configured data, a centralised part might be necessary. Function: “Authentication service” (for device level)


RN.06 Non-functional IoT@Work Normal

Date History

09/2011

04/07/2013 Pag. 112 IoT@Work/WP1/D1.3/1.0


Requirement

Rapid and deterministic network initialisation

Description

Phase 1 and 2 as explained in RN.06 are not time critical, as done in an early project phase. Phase 3 is more time-critical, as done during plant start-up. Bootstrapping the network shall be fast to guarantee a rapid system start-up. However, this start-up phase could be distinguished for 2 views. (1) Bootstrapping the whole system, for the first time (here the start-up time is not that critical and can take up to few minutes). The resulting network configuration shall be deterministic to produce a consistent scenario fulfilling all application communication needs. (2) Start-up of each single device connected to the remaining system needs to be fast including device addressing, authentication, resource allocation per device, service discovery, semantic identity/role of device, place in the application, and communication needs.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R05 Fast network bootstrapping.

Fit Criteria

The whole network could take up at most a few minutes to finish all configuration phases. This is a non-functional requirement which specifies some additional constraints on Functions “Topology & Link State Database”& “Authentication service”.



Date History

09/2011

Requirement

Seamless network re-configuration supporting system extensibility

Description

It is necessary to allow system extensions at run-time without interrupting the currently running applications. This may refer to new hardware as well as software updates. Existing bandwidth reservations must not be deleted by updates or extensions. System extensions differ if they affect: (1) Adding a single component/device related to automation, safety or a monitoring application, like a new generation sensing device, a new energy monitoring device, etc.. (2) Adding a device that offers a shared resource, e.g. CPU for more processing power, or a network device to offer a new redundant link. (3) Sub-system clones, e.g. replacing robot arm or module by another for agile manufacturing (same robot, different products) or adding a whole cell similar to existing cell by cloning it. In case (1), we want to consider those cases where extensions do not require physical interruption of the production (no need to stop the machines); in this case extensions will result in no network interruptions. In case (2), we have a similar requirement to case (1), but in case of network extensions, we might consider reconfiguring the network but with no interruptions to the system. In case (3), we want to protect the automation coordination and control system from extensions within its components in the same way as in cases (1) and (2), i.e. near-zero interruption for the remaining system.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility R02 Fast re-initialization.

Fit Criteria

It has to be distinguished whether it is: A network node (switching/routing). An end-device. A bridged end-station. This is a non-functional requirement providing constraints on the several of the network functions



Date History

09/2011

04/07/2013 Pag. 113 IoT@Work/WP1/D1.3/1.0


Requirement

Smooth device replacement and restart

Description

Fast re-initialization of all network related functionalities after device replacements is necessary to immediately get back into a productive state. This can be also referred to as the Plug-in procedure. Existing resource reservations for the services used and offered by the old device must be recovered and, where necessary, transferred to the new device. If the system is turned to a stand-by mode, system restart has to occur fast.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R02 Fast re-initialization.

Fit Criteria

a) Replacement node should be equivalently (possibly identically) configured as compared to the original failed node. b) The remaining connectivity should stay unchanged.

This depends also on whether this is an end-device or a network device. Function: “Reservation database”, (configuration copies), centralised or distributed Function: “Reservator” for anything beyond best effort connectivity, centralised or distributed (signalling the reservation message, interpreting application needs and formulating network reservation criteria) Non-functional part of the requirement should affect the fast re-initialization, the fast re-boot.


RN.09 Both functional and non-functional

IoT@Work Normal

Date History

09/2011

Requirement

Network interconnectivity and reachability of devices

Description

The considered automation network is interconnected to other network segments of the automation pyramid. Furthermore, it may be connected to corporate office networks and the Internet for remote access.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R05 Fast network bootstrapping R17 Company-wide access R18 Secure inter-site communication.

Fit Criteria

a) Multi-point communication should be possible (i.e. anycast and multicast). b) Separating network resources for different logical networks running on top of the same physical network (VLANs). c) Supporting remote access to services and devices Function: “Virtualisation and network structuring”


RN.10 Functional IoT@Work Normal

Date History

09/2011

04/07/2013 Pag. 114 IoT@Work/WP1/D1.3/1.0


Requirement

Support of arbitrary network topologies

Description

Arbitrary network structures must be supported. Typical network structures are combinations of meshes, rings, lines, stars, combs, etc. Different topologies are typical at different levels of the automation pyramid, given the different QoS requirements each layer has, while all layers need to be interconnected redundantly.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R04 On-demand path reconfiguration R13 Self-sufficient operation of systems R14 Clonability R20 Scalability.

Fit Criteria

a) Which topology is preferred by which protocol. As starting point we make a review of existing topologies at different network levels. b) How to deal with scalability of routing/switching mechanism up to 2000 nodes.. c) Splittabily of networks and related management functions.

Non-functional requirement describing all supported topologies, affects the “Path finding” and “Network Virtualisation and net structuring” functions.



Date History

09/2011

Requirement

Clear identification and addressing of devices

Description

All devices, their functionality and their location must be clearly mapped to non-ambiguous identifiers. Devices have to be easily addressable in order to be reachable from anywhere in the factory, office, or even world-wide. There might be differences between identifying an automation device and a networking device (e.g. switch, routers, gateways, etc…).

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R06 Support of device migration. R09 Semantic naming/addressing and identification of devices R22 IPv6 Support.

Fit Criteria

Amongst others network topology and localisation information is necessary for meeting this requirement. This information can be obtained by suitable protocols (e.g. routing protocols) and made available to other components. Auto-configuration capabilities and mapping functions of IP addresses to link-layer frames are essential here. The potentials of IPv6 shall be investigated for this. Function: “Naming&Addressing” (includes mapping, assignment, changes) has an interface to the Pre-configuration data and planned IDs (done in a planning tool).



Date History

09/2011

04/07/2013 Pag. 115 IoT@Work/WP1/D1.3/1.0


Requirement

Offline and online routing along arbitrary paths

Description

The automation network may employ a combination of frame forwarding (ISO/OSI data link layer) and routing mechanisms (ISO/OSI network layer). The goal is to support a flexible routing of traffic flows along individual paths. That is, not to restrict the forwarding of traffic to a certain active tree topology as is done in Ethernet and not to impose a uniform routing of all traffic flows along a common path as is done in classical IP link state routing.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R04 On-demand path reconfiguration.

Fit Criteria

a) Existing of signalling for establishing a network path. b) Support of arbitrary paths (e.g. possibility to traffic engineer a path along an arbitrary sequence of selected network nodes, or two disjoint paths).

This non-functional requirement affects functions “Topology & Link State Database” and “Path Finding”.


RN.13 Both functional and non-functional

IoT@Work Normal

Date History

09/2011

Requirement

Network and service reliability

Description

In order to enable the network to compensate failures, such as device or link outages, it is important to implement redundancy mechanisms. Besides built-in hardware redundancy at the network devices, this topic mainly covers the securing of normal traffic routing/forwarding by an alternative backup path, which remains intact in case of a failure along the primary path. This involves the necessity to route traffic flows along disjoint paths that do not share any node or link except for the end nodes (where supplementary hardware redundancy may be necessary). Various flavours of resilience mechanisms are conceivable such as alternative end-to-end paths or backup paths for every individual link of the primary path. If ultra-short recovery times are required, it may be necessary to simultaneously transmit data on both the primary and secondary paths. Another important aspect of network reliability is the discovery of and fast reaction to failures. There shall be no impact of a failure for non-affected traffic flows.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R12 High availability R21 Reliability.

Fit Criteria

a) Redundant communication (e.g. one stream over two disjoint paths, or load-balanced communication over two paths). b) Link/node failure detection. c) Switch-over time (Grace-time of application?). d) Computation of alternative paths after failure. e) Support multi-homed hosts.

Function: “Path Finding”, Function: ”Failure detection and localisation” Non-functional constraints about the type of reservation needed (affects function “Reservator”)



Date History

09/2011

04/07/2013 Pag. 116 IoT@Work/WP1/D1.3/1.0


Requirement

Quality of Service (QoS)

Description

The automation network shall facilitate distributed closed-loop applications with real-time requirements. As a result, the communication services must fulfil certain prerequisites in terms of bandwidth, latency, jitter, and packet loss. These requirements are different for each industrial application and each level in the automation pyramid. The classification of applications requirements is based on the pyramid model of automation systems (cf. section 3.2 in [3]).

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R04 On-demand path reconfiguration R21 Reliability.

Fit Criteria

QoS-aware routing Function: “Scheduler” For the above function, two additional services need to be considered separately: Function: “Scheduler” Function: ”Synchronization”



Date History

09/2011

Security specific requirements

Requirement

Secured access to services

Description

Access on and usage of resources and services should be secured by an authorisation and authentication mechanism and specific security policies.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization – the access control mechanism should enforce restricted access on devices during system initialization or/and even when extending or changing the system. R09 Semantic naming/addressing and identification of devices – the identification of devices

affects the definition of security policies and mechanisms (policies can apply to a category of devices (semantic naming) or to a group of device in the same location such as production cell, line, or plant (addressing). R15 System and devices compliance with security policy – the access control mechanism

should grant proper access rights on devices and resources according to the roles assigned to maintainers and specific security policies. R17 Company-wide access – the access control mechanism should define access rights and policies according to the company roles in order to grant the appropriate privileges to people and devices.

Fit Criteria

Appropriate access control mechanism must be defined in order to control and protect access to system resources. The access control mechanism should support a fine-grained and distributed identification mechanism of devices and resources in the company.


RS.01 Functional IoT@Work Highest

Date History

09/2011

04/07/2013 Pag. 117 IoT@Work/WP1/D1.3/1.0


Requirement

Graphical capability and capability revocation definition

Description

Capability and capability revocation definition should be eased by using a graphical tool accessible via web or as a standalone application (desktop application).

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R01 System extensibility / Extensibility – this tool eases the definition of capability relating to an added/replaced/changed device R08 Easy-to-use system management tools –this tool eases the definition of capabilities R15 System and devices compliance with security policy – this tool makes easier the definition of capabilities for adding new authorised people and/or devices and revoking access to people and/or devices R16 Secure remote diagnosis and maintenance – this tool eases the definition of the capabilities needed to both provide and restrict/revoke access on devices to be remotely monitored

Fit Criteria

Presence of a “graphical tool” for the definition of capabilities and capability revocations.


RS.02 Functional IoT@Work Normal

Date History

09/2011

Requirement

Secure credential management

Description

The automation environment shall provide components and mechanisms to manage initial and operational credentials.

Rationale

Generally, security credentials are the base for all security functionalities. The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization R07 Auto-configuration R10 Authenticity and integrity of message datagrams R15 System and devices compliance with security policy R16 Secure remote diagnosis and maintenance R19 Accountability of interactions.

Fit Criteria

The automation environment shall provide components and mechanisms to manage security credentials to devices in a secure manner. The credential management supports the whole life cycle of the credentials (generation, distribution, update, revocation, etc.) that are used by the implemented security mechanisms.


RS.03 Functional IoT@Work High

Date History

09/2011

04/07/2013 Pag. 118 IoT@Work/WP1/D1.3/1.0


Requirement

Secure network access of devices

Description

A device shall be authenticated before access to the operational network is granted.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization – only authenticated devices are granted to the operational network. R15 System and devices compliance with security policy – verification if a device is allowed to

access the network based on a given policy.

Fit Criteria

The system provides components, mechanisms and credentials to authenticate devices and to check whether the device is allowed to access the network prior to granting access.



Date History

09/2011

Requirement

Policy enforcement for devices

Description

The compliance of a device to a given policy shall be assessed during network access and regularly during normal operation.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R11 Automatic system diagnosis – allows to check and enforce given system properties on

devices. R15 System and devices compliance with security policy – verification if a device is compliant with a given security policy, before granting access to the operational network.

Fit Criteria

The system and the devices provide components and mechanisms to check the compliance to a given policy and to enforce the remediation of the devices to become compliant prior to granting access to the network. The policy checks and enforcements are performed in a regular manner during operation.



Date History

09/2011

Requirement

Device and system integrity assurance

Description

The integrity of devices of an automation environment shall be verified during network access and regularly during normal operation.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R11 Automatic system diagnosis – ensures integrity of important device properties. R15 System and devices compliance with security policy – allows detection of manipulations

and breaches of the security policy on the devices.

Fit Criteria

The automation environment provides components and mechanisms to check the integrity of software, firmware and configuration data of devices and is able to detect manipulation on devices. The system provides a data base that contains all relevant information about the current status of the devices and the current "must" state of the devices. Checks are done on a regular basis or on demand.



Date History

09/2011

04/07/2013 Pag. 119 IoT@Work/WP1/D1.3/1.0


Requirement

Secure device identifier

Description

Devices shall provide a cryptographic secure identifier that is bound to the device in such a manner that it is hard to manipulate or clone the identity.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization – allows a secure identification of devices, e.g. during network authentication R09 Semantic naming/addressing and identification of devices – a semantic naming and identification of devices should rely on a secure identifier R15 System and devices compliance with security policy – a secure identifier is needed for verification if a device is compliant with a given security policy R16 Secure remote diagnosis and maintenance – allows to verify if the identity of the remote endpoint

Fit Criteria

A unique identifier for the devices is available that contains relevant information of the device and appropriate mechanisms for secure storage of the credentials.


RS.07 Non-functional IoT@Work High

Date History

09/2011

Requirement

Initial security credentials on devices

Description

Prior to installation of a device into an automation system it shall be equipped with security credentials.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization – initial security credentials allow network authentication and

bootstrapping of operational credentials. R15 System and devices compliance with security policy – allows to verify if a device is compliant with a given security policy.

Fit Criteria

Security credentials are available prior to installation of the device. The credentials should be either imprinted during manufacturing of the device or they are configured prior to the installation of the device into the automation environment.



Date History

09/2011

04/07/2013 Pag. 120 IoT@Work/WP1/D1.3/1.0


Requirement

Secure device-to-device communication

Description

Device-to-device communication should provide integrity protection and authentication of devices and of datagrams or sessions. Confidentiality may be supported.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R10 Authenticity and integrity of message datagrams.

Fit Criteria

Each device provides security credentials that are securely bound to the device and identify the device. The communication between devices is secured by appropriate mechanisms. Depending on the needs and the type of the communication (connectionless/connection based) the device implements mechanisms to provide authentication, integrity protection and confidentiality of datagrams or connections.


RS.09 Non-functional IoT@Work Normal

Date History

09/2011

Requirement

Security mechanisms are compliant with system constraints

Description

The implementation of the security mechanisms shall be compliant with system constraints and does not disturb "normal" operation.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R12 High Availability – one aspect of high availability of the automation system is that availability of "normal" system functionality is not disturbed by security mechanisms.

Fit Criteria

Operation of security does not reduce the compliance to "normal" system requirements like real time behavior, system availability, resource consumption, etc.



Date History

09/2011

Requirement

Suitable security policies for automation environment

Description

Automation environment specific policies should be available.

Rationale

The specification of this requirement is due to the identification of the following generic requirements: R03 Controlled initialization – a policy may specify which devices are allowed to access the

network during network authentication. R15 System and devices compliance with security policy – network access control requires a policy for verification if the devices are compliant.

Fit Criteria

Automation specific policies are defined, which are checked during initial network access and periodically during operation.


RS.11 Non-functional IoT@Work Normal

Date History

09/2011

04/07/2013 Pag. 121 IoT@Work/WP1/D1.3/1.0


9 Appendix C - Comparison IoT@Work - IOT-A

9.1 Objective

The IoT@Work project has defined an IoT architecture that refers to several concepts and models developed within the IoT-A reference model. This includes a link to the IOT-A nomenclature used to define the entities under consideration. This nomenclature is applied to the software and hardware agents in a production system.

In this section, we compare the IoT@Work communication model in details with the IOT-A reference model and we also compare communication-specific requirements.

Sources

For this report the following documents were used:

IoT-A

Unified requirements

o Mapping to functionality groups as per IoT-A D1.4. [12]

o Online requirement list. [8]

IoT@Work

Requirements: “Architecture requirements, assumptions and threats” [3]

Communication architecture: “Plug&Work support mechanisms” [2]

04/07/2013 Pag. 122 IoT@Work/WP1/D1.3/1.0


9.2 Communications Requirements

9.2.1 Functional requirements

Figure 32: IoT@Work requirements relationship to IOT-A

Synopsis Figure 32 of functional IoT@Work communication requirements (light brown) and their relationships with functional IoT-A communication requirements (light red; origin: reference architecture in [8]). Dark red: non-functional IoT-A communication requirements that are related to functional IoT@Work requirements. Blue: taken from the unabridged list of IoT-A requirements [8]. Light brown: no need/recommendation for addition to IoT-A requirements list. Purple: recommended (partial) addition of IoT@Work requirements to the IoT-A requirement list.

04/07/2013 Pag. 123 IoT@Work/WP1/D1.3/1.0


Partial fits

RN.01 Managed devices

IoT@Work IoT-A Difference in view Recommendation

Device needs to provide function for monitoring, controlling, and managing devices. Example: SMNP. Furthermore: provide means for remote service management and security credentials.

UNI.704: The system shall exhibit self-management behaviour.

IoT@Work pursues central management, which can be seen s subset of UNI.704 (self-management of systems). However, IoT-A does not provide any details on what functionality is needed in order to achieve this self-management behaviour.

The idea of a programmable IoT platform also means that we might need interfaces for pushing configurations and application specific knowledge close to things or associated services.

RN.05 IPv6 support

IoT@Work IoT-A Difference in view Recom- mendation

“All IoT@Work devices and services shall be able to use IPv6 natively.”

UNI.095: “The system shall include an interface to IP communication protocols.”

The IoT-A requirement does not explicitly mention IPv6, but it does not exclude it either. From the definition of system in D1.4, viz. “A collection of components organized to accomplish a specific function or set of functions.”, it does not become clear whether devices belong to the system or not.

Clearly state in Section 3 or 5 of D1.5 that devices are within the system scope. Also, we recommend including a statement to that effect in the glossary (Annex).

RN.09 Smooth device replacement and restart

IoT@Work IoT-A Difference in view

Recom-mendation

Advocates re-initialisation of network functionalities after replacement of devices. This encompasses cloning of

UNI.096: “The system shall support the autonomous and dynamic selection of protocols

IoT-A’s requirement does not prescribe what the dynamically chosen protocols

RN.09 reaches beyond the limited domain of factory automation and we recommend it to be adopted to

04/07/2013 Pag. 124 IoT@Work/WP1/D1.3/1.0


configurations and continuity of communication.

without human intervention.”

are or shall be used for.

the IoT-A requirement list.

RN.12 Clear identification and addressing of devices


Recom-mendation

“All devices, their functionality and their location must be clearly mapped to non-ambiguous identifiers. Devices have to be easily addressable in order to be reachable from anywhere in the factory, office, or even world-wide.”

UNI.048: “The system shall provide interoperable naming and addressing”; UNI.509: “Each IoT device shall possess a universal ID, part of it read only and part of it read/write.”; UNI.608: “Each IoT device shall possess a universal ID, part of it read only and part of it read/write.”

IoT-A’s requirements do not explicitly address whether the functionality of a device shall be clearly mapped onto identifiers.

Include the mapping of functionalities onto the ID as an option.

RN.15 Quality of service

IoT@Work IoT-A Difference in view Recom-mendation

“The automation network shall facilitate distributed closed-loop applications with real-time requirements. As a result, the communication services must fulfil certain prerequisites in terms of bandwidth, latency, jitter, and packet loss.”

UNI.028: “The system shall provide a message-prioritization mechanism”; UNI.089: “The system shall support reliable time synchronization”; UNI.614: “The system shall provide Quality of Service”; UNI.615: “The system shall provide transport layer fairness”

The fit criterion for UNI.614 reads “In networks where nodes are constrained devices with limited communication capabilities, QoS might have a new (or extended) meaning compared to the current meaning. For example, real-time, event-triggered data with high time resolution, needs to be delivered with a higher priority than other and might need to ignore the need to sleep of some devices in the network.” It is not clear, whether the “current meaning” includes jitter,

Clearly spell out what is meant by “current meaning”. Include bandwidth, latency, jitter, and packet loss either in the “current meaning” or the “new meaning”.

04/07/2013 Pag. 125 IoT@Work/WP1/D1.3/1.0


latency, bandwidth and packet loss.

Non-fits

RN.03 Fast network bootstrapping support (Device and Network Requirement)

IoT@Work Analysis an recommendation

“(…) in some cases devices frequently join and leave a network and then the re-connect time shall be as low as possible. (…) the network is only fully operational if shared functions – most notably the routing or forwarding engines but also management functions – are working. Thus a device participating in the network must ensure that its role in these shared network functions are completed as fast as possible.

Fast joining of an IoT system/network is paramount for all control-loop scenarios. Notice the IoT@Work use-case domain (factory automation) is not the only domain in which such loops are prominent. Other domains include building automation and eHealth scenarios (insulin pump, …). We therefore recommend that IoT-A ads a pertinent requirement to its list.

RN.10 Network interconnectivity and reachability of devices

IoT@Work Analysis and recommendation

“a) Multi-point communication should be possible (i.e. anycast and multicast). b) Separating network resources for different logical networks running on top of the same physical network (VLANs). c) Supporting remote access to services and devices”

Anycast and multicast are core requirements for any networked system. Also, motivated by the expected heterogeneity of IoT systems and also the heterogeneity of ownership, network virtualisation will be an important feature for the IoT. We recommend thus to adopt aspects (a) and (b) in the IoT-A requirement list.

04/07/2013 Pag. 126 IoT@Work/WP1/D1.3/1.0




“The automation network may employ a combination of frame forwarding (ISO/OSI data link layer) and routing mechanisms (ISO/OSI network layer). The goal is to support a flexible routing of traffic flows along individual paths. That is, not to restrict the forwarding of traffic to a certain active tree topology as is done in Ethernet and not to impose a uniform routing of all traffic flows along a common path as is done in classical IP link state routing.”

IoT comprises many use cases in which flexible routing is of (high) interest. Examples are Smart-Grid control loops and sensor networks subject to high (but known) link variation. We therefore recommend introducing ad a requirement about flexible routing to the IoT-A requirement list.

04/07/2013 Pag. 127 IoT@Work/WP1/D1.3/1.0


9.2.2 Non-functional requirements

Figure 33: Synopsis of non-functional IoT@Work communication requirements briefly depicts the synopsis of non-functional IoT@Work communication requirements (light brown and purple) and their relationships with non-functional IoT-A communication requirements (dark red, source: reference architecture in IoT-A D1.4). Blue: taken from the unabridged list of IoT-A requirements. Light brown: no need/recommendation for addition to IoT-A requirements list. Purple: recommended (partial) addition of IoT@Work requirements to the IoT-A requirement list.

Figure 33: Synopsis of non-functional IoT@Work communication requirements

Partial fits

RN.14 Network and service reliability


Recommendation

“In order to enable the network to compensate failures, such as device or link outages,

UNI.012: “The system shall be able to handle

IoT-A’s requirement stipulates that interference shall

Addressing link failures is not only important for factory-automation scenarios. We thus

04/07/2013 Pag. 128 IoT@Work/WP1/D1.3/1.0


it is important to implement redundancy mechanisms. Besides built-in hardware redundancy at the network devices, this topic mainly covers the securing of normal traffic routing/forwarding by an alternative backup path.

interference between IoT devices (avoidance and detection)”

be handled but does not prescribe any solution. Also, link outages etc. in wired communication are not addressed.

recommend to adopt the entirety of this requirement to the IoT-A requirement list and to provide functionality in the IoT-A RA for achieving the strived for communication resilience.

RS.09 Secure device-to-device communication


Recommendation

“Device-to-device communication should provide integrity protection and authentication of devices and of datagrams or sessions. Confidentiality may be supported.”

“The system shall provide trusted and secure communication and information management”

Support of confidentiality.

Within the IoT-A framework confidentiality is probably seen as a design choice. We propose that IoT-A covers communication confidentiality both with a requirement and in its RA or the forthcoming guidelines.

Non-fits

RN.04 Scalability


“adding new devices, sub systems or complete sites should not affect the rest of the system

addressing and management should allow unlimited number of things

extending the network capacity should not affect applications

services must be scalable regarding performance (i.e. distributed servers, load balancers)”

While items (a) and (b) might be too narrow in focus for IoT-A, items (c) and (d) are requirements that, in our opinion, should also be covered by IoT-A.

RN.06 Automatic/assisted network configuration

04/07/2013 Pag. 129 IoT@Work/WP1/D1.3/1.0



“During setting up the network, supporting means for the user when configuring the devices shall be provided. Approaches may range from a central management entity to a distributed self-organization of devices. The goal is to minimize time-consuming manual overrides and the detection of configuration errors.”

One of the decisive question to be addressed by any IoT system is OPEX incurred by laborious system setups. The lower these costs the more likely it is that IoT will succeed. In an ideal world the setup for IoT communication networks will be mostly automatic. We recommend that this central requirement is added to the IoT-A requirement list.

RN.07 Rapid and deterministic network initialisation


The whole network could take up at most a few minutes to finish all configuration phases.

This requirement is and extension of RN.06 in that it provides quantification for who long network configuration and setup could take. We recommend that IoT-A considers reasonable time limits for how fast the configuration requested by RN.06 is allowed to take.

RN.08 Seamless network re-configuration supporting system extensibility


“It is necessary to allow system extensions at run-time without interrupting the currently running applications. This may refer to new hardware as well as software updates. Existing bandwidth reservations must not be deleted by updates or extensions.”

This requirement is essential for seamless operation of control-loop scenarios, which will constitute a non-negligible portion of all IoT use cases. Since “interruptive” system extension result in increased OPEX, and since a low/reduced OPEX will be a key success factor for IoT, we recommend that this requirement will be added to the IoT-A requirement list.

RN.09 Smooth device replacement and restart Is already covered in Section 0. RN.11 Support of arbitrary network topologies


“Arbitrary network structures must be supported. Typical network structures are combinations of meshes, rings, lines, stars, combs, etc. Different topologies are typical at different levels of the automation pyramid, given the different QoS requirements each layer has, while all layers need to be interconnected redundantly.”

Arbitrary network topologies are a hallmark for IoT since it covers many heterogenous use-case domains and a wide range of application scenarios. We therefore recommend to ad this requirement to the IoT-A requirements list.

04/07/2013 Pag. 130 IoT@Work/WP1/D1.3/1.0



Already covered in Section 0.

04/07/2013 Pag. 131 IoT@Work/WP1/D1.3/1.0


9.3 Comparison of the Functional Models

End To End Communication Functional Component

IoT@Work IoT-A Difference Recommendation IoT@Work uses a concept of “communication services” that defines the networking need of distributed applications (hosted in at least two or more end-devices). We call the application instance hosted in a different node an application end-point. The service is orchestrated by combining network resources between the end points.

7 The

communication service is described in the type of interaction between two or several end-points.

The End To End Communication FC takes care of the whole end-to-end-communication abstraction, meaning that it takes care of reliable transfer, transport and also translation functionalities, proxies/gateways, and of support. It also addresses tuning configuration parameters when the communication crosses different networking environments. The FC relates to an (IoT) Service and to the Network Communication FC.

IOT-A refers to the classical Internet e2e principle to describe the type of network components (proxies, gateways, etc) that are part of the network. IoT@Work presents an abstraction of the e2e interaction using a service definition that gathers the needs from the application point in an abstract manner. The orchestration of the communication service below is out of the scope of this view.

The IOT-A end-to-end model seems to be a mix of application deployment problems (such as the need of a proxy or gateway to address limited sensors, or smart things), with the issue of communication. The e2e principle is best preserved when separating the application layer issues such as the need for a proxy, mediation points or overlays from networking problems, such as communication needs, Internetworking, etc. The service-oriented approach in IOT-A in addition to a clear virtual entity models might be applied to the managed or requested networking resource.

Comparison of default function sets

Function name

Function description IoT@Work Function

Transmit Message

The function allows transmitting a message from Network Communication FC to End To End Communication FC and from (IoT) Service to End To End Communication FC. This function is executed by the End To End Communication FC and can be called by an (IoT) Service or by the Network Communication FC. The arguments for the message can be set in this function or through the Configure Message Arguments function described below.

Communication Service: represents the association between two or more application end points that communicate with each other. The communication service is delivered by the network

Configure Message Arguments

This function configures the message arguments for the Transmit Message Function. Examples of arguments include: reliability, integrity, encryption, access control and multiplexing. This function is executed by the End To End Communication FC and can be called by an IoT Service or by the Network Communication FC.

The translation of e2e protocols could resolved at application proxies or gateways. This is the case addressed within IoT@Work in sensors and actuators found in automation systems (e.g. a real I/O automation device that could be a proxy between the sampled digital automation values, and the web-service, accessed by a service-oriented application such as the semantic event notification system (ENS). The communication needs of ENS are then dimensioned for the different application elements differently (a broker needs more resources, than a simple publisher). These relationships are translated to a communication service specification that is orchestrated along the different network paths connecting

Cache and Proxy

The Cache and Proxy function allows to buffer messages in the End To End Communication FC. It’s an internal function with no exposed interface outside the FC.

Translate End To End Protocol

The Translate End To End Protocol function allows to translate between different End To End Protocols. An example would be to translate HTTP/TCP to COAP/UDP. This function is necessary for implementing a Gateway. It’s an internal function with no exposed interface outside the FC.

7 An end-point refers to a peering entity in a single distributed application hosted by a device capable of accessing an IoT resources or service

04/07/2013 Pag. 132 IoT@Work/WP1/D1.3/1.0


the different end points. We recommend to rather discuss implementation details such as COAP/UDP in Section 5 of D1.5 (Guidelines) and not in the functional view, since the latter has to be technology agnostic. Also, this discussion does not fit a pure functional-view spirit, but borders on “deployment talk” of a specific application..

Pass Context

The Pass Context function allows to transmit the context of protocol translation between two Gateways. The context could be related to addressing, methods specific for a RESTful protocol, keying material and security credentials. It’s an internal function with no exposed interface outside the FC.

The network primitives (including protocol capabilities) are structured in the slice management system, which orchestrates the resources within the network along a given path according to the protocols along that path. This however is centred around lower layers (networking and link layers) rather than on application level protocols.

Network Communication Functionality Group

IoT@Work IoT-A Difference Recommendation The concept of Network is seen as a composition of networking nodes of different type that offer heterogeneous capabilities. The IoT@Work architecture allows discovering the network capabilities by associating a SEP to each physical node. The SEP represents an agent that manages the network interfaces of an abstract network node or end-node. The node’s IDs can be mapped to the SEPs’ IDs, which could be an IP address or any kind of ID space. The mapping of end-points managed by a given SEP to the SEP ID is the key information in locating the application end-points. This can be compared to mapping of URL to an IP address.

The Network Communication FC takes care of enabling communication between networks through Locators (addressing) and ID Resolution. The FC includes routing, which enables linking different network-address spaces. Moreover different network technologies can be converged through network protocol translations.

The slice system defines one identifier for each element considered in the slice decision making. However, these identifiers could be allocated by other services, or by using any other convention. To start with each networking node, the SEP has an ID, which could any unique ID (each SEP might then have an ID for each local interface it manages). The SEPs managing end-devices, might report the associated end-device ID (which could be the IP address, or DNS name); and the associated application end-points through their IDs (which could be their URLs or local virtual interfaces). Each slice is also defined through the list of the end-points for the application view, while also listing the SEPs and their internal virtual interfaces for the network mapping view.

Allow the creation of ID spaces at each level (application instance ID, device ID, network node ID, or local interfaces IDs) and manage them through well-structured mapping functions. In IoT@Work the slice system allows other “out-of-band” naming or addressing schemes, such as IP addressing for each node, or URLs for Applications, and DNS names for devices. The slice-naming scheme only foresees identifiers of a slice and the SEPs, which then associate to the real nodes and applications through their respective physical IDs.

Default function set

Function name

Function description IoT@Work comparison

Transmit Packet

The function allows transmitting a packet from Hop To Hop Communication FC to Network Communication FC and from End To End Communication FC to Network Communication FC. This function is executed by the Network Communication FC and can be called by an End To End Communication FC or by the Hop To Hop Communication FC. The arguments for the

IoT@Work does not specify the type of packets and their format, however, it defines the information used to map an application flow to a given network path, which is in the mapping of a slice ID to some packet marking scheme. This resemble any kind of tunneling scheme, where the SEPs are aware of the different tags, whereas the node-internal mapping uses a

04/07/2013 Pag. 133 IoT@Work/WP1/D1.3/1.0


packet can be set in this function or through the Configure Packet Arguments function described below.

relevant, supported mapping function (e.g. map slice ID x to VLAN ID y. The VLAN ID y is also used for separating traffic at each network node.).

Configure Packet Arguments

This function configures the packet arguments for the Transmit Packet Function. Examples of arguments include: reliability, integrity, encryption, unicast/multicast addressing, access control. This function is executed by the Network Communication FC and can be called by the End To End Communication FC or the Network Communication FC.

Translate Network Protocol

The Translate Network Protocol function allows translation between different Network Protocols. Examples would be to translate IPv4 to IPv6 and ID to IPv4. This function is necessary to implement a Gateway. It’s an internal function with no exposed interface outside the FC.

Mapping slices to network paths is carried out in the abstract model first by associating a slice with virtual network interfaces concatenated along one or several e2e paths. The nodes’ internal interfaces can then be mapped to the virtual ones, by association of both the interface IDs and their resource mapping (e.g. max bandwidth of the virtual interface could be only enforced through a scheduler of either the source of the traffic, or in the network node through a traffic shaping specification). The network primitives are discovered along any network node of any type (e.g. router or switch).

Route Packet

The Route Packet allows finding the next hop in a network. It also allows dealing with multiple network interfaces. The function is not mandatory for all implementations of the Network Communication FC. It is required only on devices with multiple network interfaces. It’s an internal function with no exposed interface outside the FC.

Resolve Locator/ID

The Resolve Locator/ID function allows getting a Locator from a given ID. The resolution can be internal, based on a lookup table, or external via a resolution framework. It’s an internal function with no exposed interface outside the FC.

ID resolution depends on the slice-creation stage. For the slice-service request (comm. service), end-point IDs are needed. The mapping of the device ID onto the device network location is key to the slice creation. The local ID mapping is carried out according to the node capabilities. This means that end-devices can associate virtual interfaces of each slice, while network nodes map the virtual interfaces of a given slice to “real” forwarding entries or interface switching instructions. An example for such switching instructions are port-based VLAN switching tables in a managed Ethernet switch.

Manage Packet Queue

The Manage Packet Queue function allows setting up the size and priorities of the input and output packet queues. This function can be leveraged in order to achieve QoS. It’s an internal function with no exposed interface outside the FC.

Similarly IoT@Work defines a mapping from the QoS needs of each slice interface to the local QoS capabilities. Examples for such capabilities are queuing and scheduling rules.

Hop To Hop Communication

IoT@Work IoT-A Difference in view Recommendation The IoT@Work abstraction of the communication hop-per-hop path is carried out first for the virtual model of the network as whole and the associated end-points (or comm. services). The mapping of the slice “application view” or “e2e” view onto the abstracted network model is done using an optimization algorithm that can be defined for different domains. Optimization algorithms are to be chosen to that the real system constraints and application needs are both taken into account. The

The Hop to Hop Communication FC provides the first layer of abstraction from the device’s physical communication technology. The FC is an abstraction to enable the usage and the configuration of any link-layer technology.

Within IoT@Work, we rely on interfacing to several networking technologies, since the network node is first abstracted (while calculating the e2e paths for each slice), but then the exact details of the network node (including its forwarding primitives, QoS architecture, tagging options) are used to enforce the decision hop-per-hop through a specific low-level protocol “methods” per node.

While IoT@Work looks at constrained wired networks abstractions, mostly concentrating on wide and local networking technologies (Ethernet variations, and IP), IoT-A should try to look at smaller nodes with limited capabilities or with monolithic communication solutions like ZigBee. It should also look at other wireless techniques that offer more than simple networking and might even treat several application layer issues at the same time. The correct abstraction of a whole ZigBee “cloud” might be more appropriate than treating each node separately.

04/07/2013 Pag. 134 IoT@Work/WP1/D1.3/1.0


path finding per slice could apply the rule of shortest paths first for most best-effort applications, low node-stress first for jitter and delay sensitive applications or in networks of nodes with limited-resources (such as sensor networks), etc. The chosen network paths are configured by communicating directly to the SEP agents -along the paths- with instructions depending on the node’s internal implementation. We also foresee that it is possible to run a slice that traverses the boundary of a “managed network”, with the possibility to tunnel across the Internet.

Default function set

Function name

Function description IoT@Work Comparison

Transmit Frame The function allows transmitting a frame from Network Communication FC to Hop To Hop Communication FC and from a Device to Hop To Hop Communication FC. This function is executed by the Hop To Hop Communication FC and can be called by a Device or by the Network Communication FC. The arguments for the frame can be set in this function or through the Configure Frame Arguments function described below.

Transmission of frames occur per application slice in a virtual network. Packets are passed from one domain to the given where the slice enforcement point could manage protocol translator or bridge.

Configure Frame Arguments

This function configures the frame arguments for the Transmit Frame Function. Examples of arguments include: reliability, integrity, encryption, access control. This function is executed by the Hop To Hop Communication FC and can be called by the Network Communication FC or the Hop To Hop Communication FC.

Route Frame The Route Frame function allows to route a packet inside a mesh network such as for instance 802.15.4 (mesh-under routing). The function is not mandatory for all implementations of the Hop To Hop Communication FC. It is required only for meshed link layer technologies. It’s an internal function with no exposed interface outside the FC.

This is not considered in IoT@Work, as routes along mesh might not be selected for applications with higher demands on reliable and timely communication.

Manage Frame Queue

The Manage Frame Queue function allows setting up size and priorities of the input and output frame queues. This function can be leveraged in order to achieve QoS. The function is not mandatory for implementation; it is an internal function with no exposed interface outside the FC.

Depending on the technologies along a given path, a range of QoS combinations are under study for delivering the main automation applications with their required comm. service.

9.4 Conclusion

We compared sixteen IoT@Work requirements pertaining to communications with a comprehensive selection of IoT-A requirements (27 in total). For four IoT@Work requirements we found a good match with IoT-A requirements, while we proposed extensions/revisions of IoT-A requirements along the line of the remaining twelve IoT@Work requirements.

04/07/2013 Pag. 135 IoT@Work/WP1/D1.3/1.0


The majority of the differences found were due to IoT@Work stipulating a very high and interworked level of network virtualization.

The communication model in IOT-A could adopt more resource-centric approach to allocate network resources to applications through a generic service interface. The benefit of such an approach would be to address more IoT domains and not only constrained networks of “accessing things”. The ideas of treating the network as a resource accessed as a service could then allow a better functional decomposition between network-related functions (such as addressing, QoS management, or managing critical traffic and less important communications), from the application elements (such as data mediators, or proxies) which are concerned with managing the data in application-level annotators or brokers, filters, or indirection points. Both facets are important to an IoT architecture, but mixing them makes it hard to apply the same concepts to all domains.

Documents

D1.2 – Architecture requirements, assumptions and threatshome.ufam.edu.br/hiramaral/04_SIAPE_FINAL_2016/SIAPE_Biblioteca... · further intelligence into the system in an agile manner