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

Category: Report Status: Final Availability: Public

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

Category: Report Status: Final Availability: Public

End To End Communication Functional Component ................................................. 131 Network Communication Functionality Group ............................................................ 132 Hop To Hop Communication ...................................................................................... 133 9.4 Conclusion ............................................................................................... 134

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

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

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

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.

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.

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.

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

Internet das Coisas

O CERP-IoT (Cluster de projectos europeus de investigação sobre a Internet das Coisas) Internet das Coisas Strategic Research Roadmap (setembro de 2009) afirma para a Internet das coisas "... uma parte integrante da futura Internet e pode ser definida como uma infra-estrutura de rede global dinâmico com auto configurar capacidades com base em protocolos de comunicação padrão e interoperáveis onde físicos e virtuais "coisas" têm identidades, atributos físicos, e personalidades virtuais e usar interfaces inteligentes, e estão perfeitamente integradas na rede de informação.

No IoT, "coisas" devem se tornar participantes ativos no mundo dos negócios, informações e processos sociais onde eles são capazes de interagir e se comunicar entre si e com o meio ambiente através do intercâmbio de dados e informações "percebidas" sobre o meio ambiente, ao reagir de forma autônoma para os eventos " mundo reais / físicas" e influenciá-la por meio de processos que desencadeiam ações e criar serviços com ou sem a intervenção direta da execução humana. ".

Sumário Executivo

Esta entrega relata a final especificação de arquitetura IoT @ Work, que foi revisto para ter em conta todos os resultados de validação relevantes e tecnologia e tendência-scouting.

A IoT @ Work arquitetura decompõe funções em uma estrutura em camadas. Isso garante uma dissociação clara de preocupações que aumenta a flexibilidade em múltiplas dimensões: modelos de negócios flexíveis: muitas partes interessadas e muitas aplicações podem coexistir na mesma infra-estrutura de forma fracamente acoplado, mas seguro. Infra-estrutura flexível é ativado por meio de dissociação recursos e problemas físicos a partir de aplicações. Isso facilita muito a gestão heterogeneidade e permite que apoiam a modernização e migração. Como as alterações podem ser mantidos locais, reparo, melhorias e gestão do ciclo de vida de toda a produção torna-se mais fácil. Infra-estrutura semântica estilo IoT, complementado por serviços de comunicação poderosos e processamento de mensagens inteligente, permite mudanças mais fáceis da lógica tempo de execução e, portanto, permite melhorias ou otimizações futuras.

Os pilares da arquitetura ativar esses recursos são auto-configuração de dispositivos industriais, uma rede capaz multi-tenancy, um barramento de mensagens semanticamente e segurança-wise enriquecido que permite que um processador de eventos complexos para introduzir uma maior inteligência no sistema de forma ágil.

A arquitetura de sucesso não é completa sem um conceito de segurança clara (detalhado em [6]) e também tem de fornecer um conceito de gestão capaz de lidar com a complexidade, sem perder o controle sobre o sistema. O projeto, portanto, colocou um trabalho significativo para a funcionalidade de gerenciamento, tais como gerenciamento de rede e serviço de controle com uma interface clara de ferramentas de planejamento ou pelo fornecimento de um poderoso serviço de gerenciamento de autenticação na camada de mensagem. Outro exemplo é o fácil de usar mecanismos desenvolvidos no projeto para configurar o sistema de uma forma que a informação semântica é - pelo menos parcialmente - fornecida automaticamente, por exemplo, por meio de auto-configuração ou através de espaços de nomes que podem codificar informação topológica.

Este objectivo não só detalhes da arquitetura final, mas também rastreia as ligações a partir de requisitos para a estrutura arquitectónica e elementos e vice-versa.

(ROTONDI et al., 2013)

(LEE et al., 2014)

bilbiografia

LEE, E. a., Rabaey, J., Hartmann, B., Kubiatowicz, J., Pister, K., Simunic Rosing, T., … Rowe, A. (2014). The swarm at the edge of the cloud. IEEE Design and Test, 31, 8–20. doi:10.1109/MDAT.2014.2314600

ROTONDI, D., Piccione, S., Altomare, G., Houyou, A. M., Gessner, J., Kloukinas, C., … Trsek, H. (2013). IoT @ Work WP 1 – PLUG&WORK IOT REQUIREMENT ASSESSMENT AND ARCHITECTURE D1.3 – Final framework architecture specification, 1–135.