04/07/2013 Pag. 1 IoT@Work/WP1/D1.3/1.0. IoT@Work WP 1 PLUG&WORK IOT REQUIREMENT ASSESSMENT AND ARCHITECTURE

Transcription

1 04/07/2013 Pag. 1 IoT@Work/WP1/D1.3/1.0 IoT@Work WP 1 PLUG&WORK IOT REQUIREMENT ASSESSMENT AND ARCHITECTURE D1.3 Final framework architecture specification Reference: Category: Deliverable Responsible: Author(s): IoT@Work/WP1/D1.3/1.1 Report Siemens 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: Status: Availability: 36 Months final Public

2 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 coexist 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 securitywise 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.

3 04/07/2013 Pag. 3 IoT@Work/WP1/D1.3/1.0 Document History Version History Version Status Date Author(s) 0.1 Draft A. M. Houyou 0.2 Draft D. Rotondi, S. Piccione, G. Altomare, A. Galipò, S.Genolini 0.3 Draft A. M. Houyou 0.4 Draft H.-P. Huth, J. Claessens, S. Piccione, 0.5 Draft H.-P. Huth, H. Trsek, J. Imtiaz 0.6 Draft H.-P. Huth, J. Gessner, C. Kloukinas, K. Mahbub, M. Krotsiani 0.7 Draft D. Rotondi, S. Piccione, G. Altomare, A. Galipò, S.Genolini 0.8 Draft D. Rotondi, S. Piccione, G. Altomare, A. Galipò, S.Genolini 0.9 Draft H.-P. Huth, S. Piccione 1.0 Final H.-P. Huth, C. Kloukinas, S. Piccione

4 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 More content, components&functions map added, orchestrated mgm More content embedded application configuration service added; , 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

5 04/07/2013 Pag. 5 IoT@Work/WP1/D1.3/1.0 Contents 1 Introduction Scope of WP Objective of this Deliverable Relationship with other tasks and WPs Structure of this document Architecture Origins Architecture Relations with s Architecture Deployment Terminology s Revision Reference Architecture Specification Layers and Planes Security Plane Management Plane Functional Decomposition of the IoT@Work Architecture Event Notification Service Overview ENS Architecture and Services AMQP broker and Virtual Host concept ENS Authorization Service ENS Namespaces Slice Management System Components Slice Manager Internal Architecture Non-Slice-Related Infrastructure Components and Deployment Issues ENS Namespace Management Service Embedded application configuration service Directory Service Purpose and Architecture Overview Read Create Update Delete Query interface Security plane Orchestrated Management CEP and System monitoring... 57

6 04/07/2013 Pag. 6 IoT@Work/WP1/D1.3/ Authorisation capability Capability Revocation Policy Decision Point Revocation Service Secure Device Identifier and Security Bootstrapping Device Integrity Assurance IoT@Work Device Evaluation and Validation of Architecture Approach Trend-scouting and Evolution since Start of the Project Reshoring Internet-of-Things Industry Industrial Security Technologies Summary Conclusions References Appendix A Generic s List s Template Catalogue Appendix B Specific s List Common specific requirements Event notification service requirements Event monitoring and reasoning system requirements Specific requirements of application configuration/orchestration Specific requirements affecting device bootstrapping Network specific requirements Security specific requirements Appendix C - Comparison IoT@Work - IOT-A Objective Communications s Functional requirements Partial fits Non-fits Non-functional requirements Partial fits Non-fits Comparison of the Functional Models

7 04/07/2013 Pag. 7 IoT@Work/WP1/D1.3/1.0 End To End Communication Functional Component Network Communication Functionality Group Hop To Hop Communication Conclusion

8 04/07/2013 Pag. 8 IoT@Work/WP1/D1.3/1.0 List of Figures Figure Architecture Definition Process Figure 3-1 IoT@Work Architecture Functional Layers (See Deliverable D1.2) Figure 3-2 IoT@Work Architecture Focus in Planes Figure 3-3 Architectural Components and Key Functions Figure 3-4 Overview of the ENS approach Figure 3-5 ENS Architectural Components Figure 3-6- ENS Authorization Service Architecture Figure An example of IoT@Work ENS namespace Figure IoT@Work ENS namespace publishing Figure 3-9: IoT@Work ENS namespace subscription to a branch Figure 3-10: IoT@Work ENS namespace subscription to a more complex subset.. 40 Figure 3-11: Communication-slice domain Figure 3-12: Slice System Layers Figure 3.13 Interaction between OPC UA devices and Directory Service Figure 3.14 Bootstrapping interaction between OPC UA devices and DS Figure 3-15 IoT@Work Directory Service Figure 3-16 IoT@Work Directory Service Data Model Figure 3-17 IoT@Work Directory Service architecture Figure 3.18 Process flow orchestrated management Figure 3.19: ENS/CEP bridging interfaces Figure 3.20 Monitoring excessive power consumption in Event Calculus Figure Authorisation Capability XML Schema - top level elements Figure 3-22 Authorisation Capability Revocation XML Schema Figure PDP Service architecture Figure 3-24 Revocation Service architecture Figure 3-25: Secure Device ID Module Figure 3-26: Manufacturer based bootstrapping Figure 3-28: NAC architecture Figure 3-27: Network Access Control Steps Figure 3-29 NAC authorisation architecture components deployment Figure 3-30: System Integrity Assurance architecture components Figure 3-31: System Integrity Assurance architecture deployment Figure 32: IoT@Work requirements relationship to IOT-A Figure 33: Synopsis of non-functional IoT@Work communication requirements

9 04/07/2013 Pag. 9 IoT@Work/WP1/D1.3/1.0 List of Tables Table 1.1 Task T1.1 objectives Table 1.2 Task T1.2 objectives Table 2.1 Generic s List Table 2.2 Common requirements Table 2.3 Event notification service requirements Table 2.4 Event monitoring and reasoning system requirements Table 2.5 Specific requirements of application configuration/orchestration Table 2.6 Specific requirements affecting device bootstrapping Table 2.7 Network specific requirements Table 2.8 Security specific requirements Table ENS Namespace management service RESTful API Table 5.1 Task T1.1 achievements Table 5.2 Task T1.2 achievements Table 7.1 Template for IoT@Work requirements Table 7.2 Possible IDs for generic and specific requirements Table 7.3 Range of categories... 88

10 04/07/2013 Pag. 10 List of Acronyms ABAC ACID ACL AMQP ASIC BASE DCS DHCP DPWS DoW 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. 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. 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. Advanced Message Queuing Protocol is a protocol and a domain model for a message oriented middleware. Application-specific integrated circuit is an integrated circuit tailored to a particular use rather than being general-purpose. 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). Distributed Control System is a process control system using a network infrastructure to communicate with a set of sensors, controllers, operator terminals and actuators. Dynamic Host Configuration Protocol is a protocol used on IP networks for configuring network devices. There are specific versions of DHCP for IPv4 and IPv6. Devices Profile for Web Services defines a minimal set of functionalities to enable secure Web Service messaging, discovery, description, and eventing on resource-constrained devices. It is similar to Universal Plug and Play (UPnP) with the main difference of being aligned with Web Services technology. of Work

11 04/07/2013 Pag. 11 HMI IEEE 802 IETF IoT MOM PAC 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. 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 ). Internet Engineering Task Force It is an open standards organization, based on volunteers, that develops and promotes Internet standards, in particular the ones related to the TCP/IP and Internet protocol suite. The IETF is formally a part of the Internet Society and is overseen by the Internet Architecture Board (IAB). Internet 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.. 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. 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.

12 04/07/2013 Pag. 12 PLC PROFINET RBAC REST RFID RPC SAML SCADA SOA UPnP 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 is the open industrial Ethernet standard for automation. PROFINET uses TCP/IP and IT standards and supports real-time Ethernet communications 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. 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. 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. 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. Security Assertion Markup Language is an XML-based open standard for exchanging authentication and authorisation data between identity and service providers. Supervisory Control And Data Acquisition refers to industrial control systems: computer systems that monitor and control industrial processes or infrastructures. Service Oriented Architecture provides methods for systems development and integration where systems group functionality around business processes and package these as interoperable services. An SOA infrastructure allows different applications to exchange data with one another as they participate in business processes. Service-orientation aims at a loose coupling of services with operating systems, programming languages and other technologies which underlie applications. Universal Plug and Play UPnP is a set of networking protocols finalised to enable networked devices to discover other network devices and the services these provides. The UPnP technology is promoted by the UPnP Forum.

13 04/07/2013 Pag. 13 XACML W3C extensible Access Control Markup Language is a declarative language for describing access control policies; it has been defined by the OASIS standards organization. World Wide Web Consortium is the main international standards organization for the World Wide Web. Amongst others, it is responsible for the XML standardisation.

14 04/07/2013 Pag Introduction 1.1 Scope of WP1 Work Package 1 Plug&Work IoT 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 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.

15 04/07/2013 Pag. 15 Sub-task Title Objectives T1.1.1 T1.1.2 State of the art analysis refinement Architecture requirements & assumptions Definition of operational and technological scenarios Identification of architectural and operational needs and evaluation of architectural design, choices and 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 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 Feedback coming from outcomes of the implementation and validation activities Table 1.1 Task T1.1 objectives Phases Title Objectives Phase 1 Phase 2 Functional Reference Architecture V1 Functional Reference Architecture V2 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 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

16 04/07/2013 Pag. 16 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 s List) details the generic requirements elicited during the project lifetime. The second appendix (section 8 Appendix B Specific s 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 s. 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.

17 04/07/2013 Pag Architecture Origins This chapter provides an overview of both the architectural design methodology, and the 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 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.

18 04/07/2013 Pag. 18 Stakeholder Feedback s Analysis using views Architecture Technologies Collect requirements Decompose & analyse Derive solution architecture Develop technologies Integrate & Demonstrate Early implementations, test beds Current status Figure 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 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 Relations with s 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

19 04/07/2013 Pag. 19 high-level architectural components and functions for the project. These functionalities and components are detailed in Chapter 4. Each of them has been linked to one or more specific requirements Architecture Deployment The 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 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:

20 04/07/2013 Pag. 20 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

21 04/07/2013 Pag. 21 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.

22 04/07/2013 Pag. 22 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 s 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.

23 04/07/2013 Pag. 23 The following table lists the generic requirements gathered from the requirements elicitation process. ID R01 R02 R03 R04 R05 R06 R07 R08 R09 R10 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22 Name System extensibility / Extensibility Fast re-initialization Controlled initialization On-demand path reconfiguration Fast network bootstrapping Support of device migration Auto-configuration Easy-to-use system management tools Semantic naming/addressing and identification of devices Authenticity and integrity of message datagrams Automatic system diagnosis High availability Self-sufficient operation of systems Clonability System and devices compliance with security policy Secure remote diagnosis and maintenance Company-wide access Secure inter-site communication Accountability of interactions Scalability Reliability IPv6 Support Table 2.1 Generic s List

24 04/07/2013 Pag. 24 The following tables list the function-specific requirements derived from the generic ones. Common requirements ID RC.01 RC.02 RC.03 RC.04 RC.05 Name Smooth scaling Auditability and Accountability Interoperability Provision of semantically enriched information about devices 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 RO.01 RO.02 RO.03 Name Avoid undesired interference and respect operational constraints of automation system when carrying out system adaptation/update/maintenance/configuration Correctly carry out system adaptation/update/maintenance/configuration, respecting dependencies between individual adaptation/update/maintenance/configuration operations Facilitate/automate system adaptation/update/maintenance/configuration with high complexity Table 2.5 Specific requirements of application configuration/orchestration

25 04/07/2013 Pag. 25 Specific requirements affecting device bootstrapping ID Name RB.01 Standardized device pre-configuration (Device ) RB.02 Minimum user interaction for pre-configuration (Device ) RB.03 Availability of basic infrastructure (Environment ) RB.04 High reliability (Environment ) RB.05 High scalability (Process ) RB.06 Dead-lock avoidance (Process ) RB.07 Updatable soft- and firmware (Device ) 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 ) RN.02 Fast re-routing and forwarding manipulations (Network ) RN.03 Fast network bootstrapping support (Device and Network ) RN.04 Scalability RN.05 IPv6 support (Network ) 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

26 04/07/2013 Pag. 26 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

27 04/07/2013 Pag Reference Architecture Specification This section describes the 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.

28 04/07/2013 Pag. 28 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..

29 04/07/2013 Pag. 29 Communication Plane Automation Applications Security Plane Application level middleware services commissioning, composition, adaptation Management Plane Device resource creation & management services abstraction, context/dependencies Device and network embedded services auto-configuration, device semantics, network management Field/Control Infrastructure & Network Figure 3-2 Architecture Focus in Planes The three orthogonal planes that 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. iii. Security Plane: managing system security to make sure that different management functions at each layer include some security mechanisms. 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.

30 04/07/2013 Pag. 30 Figure 3-3 Architectural Components and Key Functions

31 04/07/2013 Pag. 31 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 endnodes, 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:

32 04/07/2013 Pag. 32 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 preconfigured 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 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 safetycritical 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].

33 04/07/2013 Pag 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) 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 selfconfiguration 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

34 04/07/2013 Pag. 34 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 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: 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.).

35 04/07/2013 Pag. 35 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 finegrained control on what data are provided to whom and decouples the event producers from the event consumers.

36 04/07/2013 Pag ENS Architecture and Services The following picture sketches the architecture of the ENS. ENS Broker Service Events Stream Events Stream Events Stream Events Events Events Monitoring App A PLCs Network Devices Robots Monitoring Application XX Monitoring Application YY Event Analysis Engine ENS Access Request Broker Service Monitoring App B ew ENS Authorization Service (ENS AuthService) Capability Revocation Service Policy Decision Point Service 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 upto-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.

37 04/07/2013 Pag AMQP broker and Virtual Host concept The AMQP standard envisages the Virtual Host concept that is 1 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 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; 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 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 (

38 04/07/2013 Pag. 38 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) 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

39 04/07/2013 Pag. 39 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 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 IoT@Work ENS namespace publishing

40 04/07/2013 Pag. 40 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-

41 04/07/2013 Pag. 41 characters (i.e. characters having special meanings like., for structuring the naming hierarchy, and * or # for expressing filtering) Slice Management System 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). Application View T Application 1 L L L T Application 2 L Communication Service Interface Slice View Slice Entry Slice Intermediate Node L L Physical Network View T L configuration live monitoring device/topology detection L L L

42 04/07/2013 Pag. 42 The general idea behind the Quality-of-Service concept is to combine the strength of a traffic engineering approach with online (near real-time) resource management and optimizations. slice end points device CS domain controller (slice management) 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 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).

43 04/07/2013 Pag. 43 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. App CS API Slice Enforcement Point CS Slice Management applications and management consoles unified view policy enforcement traffic shaping and marking resource management user management Network Management & Control access to the physical devices Profinet other Ethernet ZigBee Drivers for various Standards 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 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 nodeinternal 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

44 04/07/2013 Pag. 44 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, technologyindependent 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 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

45 04/07/2013 Pag. 45 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 ENS Namespace Management Service The ENS namespaces introduced in section 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 /namespacelist GET POST Return the list of all namespaces Create a new namespace - JSON Object (name, description) 200(JSON, 400, 404, , 400, 409, 404, 500 GET Return namespacename s data - 200, 400, 404, ens-namespace-manager /namespacelist/ <namespacename> DELETE Delete namespace namespacename - 204, 400, 404, 500 PUT Update namespacename s data JSON object (name, description) 204, 400, 404, 409, 500 GET Retrieve nodename s data (JSON), 400, 404, ens-namespace-manager /namespacelist/<namespacena me>(/<nodename>)+ DELETE Delete nodename - PUT Update nodename s data JSON object (name, description, uri, entityuri) 204, 400, 404, , 400, 404, 409, /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 GET /namespacelist /<namespacename>/certificateli st POST Return the list of the trusted subjects X.509 certificates associated with namespace namespacename Add a new trusted subject s X.509 certificate to the X.509 Certificate 200 (JSON), 400, 404, 409, , 400, 404, 409, 500

46 04/07/2013 Pag. 46 namespace namespacename /namespacelist /<namespacename> /CertificateList /<CertificateID>/ Legend: * = 0 or more + = at least 1 (A B) = either A or B (exclusive) JSONfield = mandatory field DELETE Remove the certificate identified by CertificateID and associated with namespace namespacename Table ENS Namespace management service RESTful API 204, 400, 404, 500 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 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.

47 04/07/2013 Pag. 47 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.

48 04/07/2013 Pag. 48 Directory Service (DS) DirectoryServiceEnquirer DirectoryServiceClient RESTInterfaceManager OPCUAClient SemanticAnnotator Output Formatter OPC UA Server getprofile( Device ID ) GET( Entity URL, Accepted Content Type ) getopcuaprofile( Entity URI ) getopcuainformationmodel( Entity URI ) OPC UA Address Space Profile OPC UA Profile convertintordf( OPC UA Profile ) Semantic Profile Formatted Semantic Profile Formatted Semantic Profile format( Semantic Profile, Accepted Content Type ) Formatted Semantic Profile Figure 3.13 Interaction between OPC UA devices and Directory Service Configuration Service (triggered when a new device is plugged in) New device Directory Service (DS) DeviceConfigurator ProfileConvertor OPCUAClient DirectoryServiceClient OPCUAServer RESTInterfaceManager Semantic Annotator NoSQLDBMS getprofile( DeviceID ) getopcuainformationmodel( Entity Point URI ) OPC UA Address Space Profile OPC UA Profile convert( OPC UA Profile ) Interoperable Profile store( Parent URL, Interoperable Profile ) POST( Parent URL, Interoperable Profile ) annotate( Interoperable Profile ) Semantic Profile store( Semantic Profile ) Figure 3.14 Bootstrapping interaction between OPC UA devices and DS Directory Service 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

49 04/07/2013 Pag. 49 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. Identify object 1 2 HTTP GET obj info <<<< << 3 IoT@Work Object Info Directory Service 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;

50 04/07/2013 Pag. 50 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 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.

51 04/07/2013 Pag. 51 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 entities 2. 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. External Applications Mobile Access Browser Access Service Management REST Interface Manager Output Formatter Device Discovery Notification AJAX GUI Configuration Manager Request Manager Query Manager Semantic Annotator OPC-UA Data Mod. to OWL Converter SNMP MIB to OWL Converter SNMP Client OPC-UA Client Ontologies Database SNMP Query OPC UA Query Plant Network NAC Service Service Config Database Static Elements Database 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)

52 04/07/2013 Pag. 52 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 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. * = 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. * = 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) * = 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

53 04/07/2013 Pag. 53 * = 0 or more The representation types of the returned data supported by the DS are: JavaScript Object Notation (JSON) XML serialization of the Resource 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 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: (/<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: (/<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.

54 04/07/2013 Pag 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. * = 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. * = 0 or more The HTTP response codes returned by the DS are: 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. 500, if a DS internal error has occurred while fulfilling the request 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: + = 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: = at least 1 The HTTP response codes returned by the DS are:

55 04/07/2013 Pag , 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) 500, if a DS internal error has occurred while fulfilling the request 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: 1 =<pr opertyname>+<operator>+<value>(&q i =<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. The HTTP response codes returned by the DS are: 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 Security plane 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)

56 04/07/2013 Pag. 56 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. Orchestrated management scenario Dependency resolution Management plan Runtime scheduling 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.

57 04/07/2013 Pag. 57 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. notin-production ), then constraint values should be available from such context service (e.g. this could be parameter from a MES or ERP system) 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 runtime. 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

58 04/07/2013 Pag. 58 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 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 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

59 04/07/2013 Pag. 59 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 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 nonhighlighted 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)

60 04/07/2013 Pag. 60 & 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(EnergyMeasurement(4, 1, 0),2). Happens(EnergyMeasurement(0, 0, 1),3). Happens(SetPowerThreshold(2),3). ; XXX change the threshold. Happens(EnergyMeasurement(1, 1, 0),4). 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 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.

61 04/07/2013 Pag. 61 Figure 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:

62 04/07/2013 Pag. 62 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 ) 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.

63 04/07/2013 Pag. 63 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 o AllCapabilities: both the capability identified by the RevokedCapability element, and all its downstream capabilities are revoked. 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 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 request 4. IssuerAccessRightsCapability: this mandatory element is used to store the Authorisation Capability of the Issuer 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 1 st 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 2 nd phase is devoted to validate if the requesting subject is actually entitled to revoke the indicated authorization capability/capabilities. The 1 st 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 2 nd 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 (that reports if the request is correct and if the revocation has been enforced)

64 04/07/2013 Pag. 64 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. PDP Config DB PDP Service DPDSrvMgt GUI from the XXX Author. Service PDPAuthReqProcessing PDPPendRevProcessing PDPPendRevNotifier Capability + Revocation DB to the Revocation Service Figure 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).

65 04/07/2013 Pag. 65 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 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 1 st 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 2 nd phase is devoted to validate if the requesting subject is actually entitled to revoke the indicated authorization capability/capabilities. The 1 st phase processing can be performed immediately and,

66 04/07/2013 Pag. 66 therefore, its outcomes are returned immediately to the requestor as results of the RESTful request. The processing requested by the 2 nd 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 (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

67 04/07/2013 Pag. 67 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 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 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-themiddle 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.

68 04/07/2013 Pag. 68 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. Management and Service Interface towards Applications Random Number Generator Secure Storage Asymmetric algorithms Hash algorithms DevID Module Figure Figure 3-25: xx: Secure Secure Device Device ID ID Module 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.

69 04/07/2013 Pag. 69 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).

70 04/07/2013 Pag. 70 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 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

71 04/07/2013 Pag. 71 parameters as well as functions to bring the devices to a policy compliant status (remediation). The NAC process is divided into following steps: Detection Remediation Authentication Authorisation Assessment Figure 3-27: Network Access Control 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

72 04/07/2013 Pag. 72 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. Agentor 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

73 04/07/2013 Pag. 73 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

74 04/07/2013 Pag. 74 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 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.

75 04/07/2013 Pag. 75 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.

76 04/07/2013 Pag 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. 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 Client 5. 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 autoconfiguration 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.

77 04/07/2013 Pag 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 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 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.

78 04/07/2013 Pag. 78 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 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 subcontractors. 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." 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

79 04/07/2013 Pag. 79 products. And this trend holds for worldwide, as an example China demonstrated its interest in IoT by hosting the IoT 2012 conference in Wuxi ( 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. 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 ( 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 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. 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" ( 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 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

80 04/07/2013 Pag. 80 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 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 ( 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 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

81 04/07/2013 Pag. 81 selection of topics shows that the topics are highly relevant for future automation.

82 04/07/2013 Pag Conclusions In this deliverable we have presented the specification of the final architectural reference model of the solution proposed by 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 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 metainformation 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).

83 04/07/2013 Pag. 83 The following tables summarise the achievement of WP1. Sub-task Title Outcome T1.1.1 T1.1.2 T1.1.3 T1.1.4 State of the art analysis refinement Architecture requirements & assumptions Pilot Scenario Identification Architecture requirements & assumptions refinement D1.1 (M6) Delivered M6 D1.2 (M14) Delivered M16 D1.1 (M6) Delivered M6 D1.3 (M36) Delivered M37 Table 5.1 Task T1.1 achievements Phases Title Outcome Phase 1 Phase 2 Phase 3 Functional Reference Architecture V1 Functional Reference Architecture V2 Functional Reference Architecture Final Version Internal Deliverable (M10) Internal Deliverable (M18) D1.3 (M36) Delivered M37 Table 5.2 Task T1.2 achievements

84 04/07/2013 Pag References [1]. M. Villa et al., "D1.1 State of the art and functional requirements in manufacturing and automation", 30/11/2010, [2]. A. M. Houyou et al., D2.3 PLUG&WORK SUPPORT MECHANISMS, 2012, [3]. D. Rotondi et al., D1.2 Architecture requirements, assumptions and threats, 2011, [4]. A. M. Houyou et al., "D1.1. Revision Details", 20/12/2011, [5]. A. M. Houyou et al., "D2.2 BOOTSTRAPPING ARCHITECTURE", 01/06/2011, [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, s, (accessed on ), 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, [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, 1/1/1/D1.4/at_download/file, 2012 [13]. AMQP Working Group, Advanced Messaging Queuing Protocol Protocol Specification Version Online at: [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: / _28 pp [16]. Hoogendoorn C., Schrodi K., Huber M., Winkler C., Charzinski C., "Towards Carrier- Grade Next Generation Networks", Proc. ICCT 2003, Beijing, China, Apr [17]. European Union DG Enterprise and Industry, "EU industrial structure Trends and Performance", ISBN , 2011 [18]. A. Regalado, "Back in the USA", Technology Review, April 2013, [19]. EU industrial structure Trends and Performance, Luxembourg: Publications Office of the European Union, ISBN [20]. Fidelity Worldwide Investment press release, "21st Century Investment Themes, Episode 7: the revival of the west", 2013, [21]. J. Scott, Computer Weekly, "Could mobile manufacturing be heading back to Europe?", 31 May 2013, [22]. The Economist, "Coming Home", Jan 2013, [23]. S. Jingting, Chen Limin, T. Yannan, China Daily Europe, "Homeward bound? Firms mull return", July 2012,

85 04/07/2013 Pag. 85 [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, [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", [28]. home page of the European Factories of the Future Public Private Partnership, [29]. J. Cusimano, Exida Inc., March 2011, [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, [32]. Embedded World 2013, press release "Safety and Security im Fokus", Nov. 2012, safety-and-security-im-fokus [33]. IEEE P802.3bj Task Force, [34]. IEEE 400 Gb/s Study Group, [35]. Siemens Scalance XR 500 product description, [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, [38]. Alpern, B.; Schneider, F. B.: Defining Liveness. Inf. Process. Lett. 21(4): (1985) [39]. Clarkson, M. R.; Schneider, F. B.: Hyperproperties. Journal of Computer Security 18(6): (2010) [40]. Spanoudakis, G.; Mahbub, K.: Non Intrusive Monitoring of Service Based Systems, International Journal of Cooperative Information Systems, 15 (3), pp , Online at: [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 Springer-Verlag, 2009 [42]. Microsoft StreamInsight. [43]. Dwyer, M. B.; Avrunin, G. S.; Corbett, J. C.: Patterns in Property Specifications for Finite- State Verification. ICSE 1999: An online repository of specification patterns is available at:

86 04/07/2013 Pag Appendix A Generic s List In this appendix we report the generic requirements described in D s 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. Fit Criteria Type Target Priority Category Date History Reference Fit Criteria ID Table 7.1 Template for IoT@Work requirements Descriptive title of the requirement A detailed description of the purpose and the objective of the requirement. This field applies to specific requirements only. It describes the rationale of this requirement, i.e. the reference to all relevant generic requirements. 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. 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.

87 04/07/2013 Pag. 87 Generic requirements ID Rxx Specific requirements ID RC.xx RE.xx RM.xx RO.xx RB.xx RN.xx RS.xx Type Related to number and ID Related to Common specific requirement Event notification Event monitoring Application configuration and orchestration Device bootstrapping Network Security Table 7.2 Possible IDs for generic and specific requirements 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)..

88 04/07/2013 Pag. 88 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 Network NW s related to the network Production PR s related to the production system General GE Generic requirement for IoT@Work Security SE IT-Security -related Engineering EN Engineering-related (requirements for interaction with engineering tools and processes) Date History Reference Table 7.3 Range of categories. Month, when the requirement was originally raised, format: mm/yyyy (e.g.: 10/2010) 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. In this field, a reference to already existing requirements (either higher-level or scenario-related) is provided. 7.2 Catalogue System extensibility / Extensibility 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. N/A R01 Functional IoT@Work Highest Network/Production Date History Reference 01/2011 A01, B04

89 04/07/2013 Pag. 89 Fast re-initialization The system shall be capable of a fast re-initialization after system extensions or changes in the off-line system state. N/A R02 Functional IoT@Work Highest Network/Production Date History Reference 01/2011 A02 Controlled initialization 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) N/A R03 Functional IoT@Work High Network/Production Date History Reference 01/2011 A03 On-demand path reconfiguration 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. N/A R04 Functional IoT@Work Highest Network Date History Reference 01/2011 A04 Fast network bootstrapping 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. N/A R05 Functional IoT@Work Highest Network Date History Reference 01/2011 A05

90 04/07/2013 Pag. 90 Support of device migration 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. N/A R06 Functional IoT@Work High Network/Production Date History Reference 01/2011 A06 Auto-configuration 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. N/A R07 Functional IoT@Work Highest Network Date History Reference 01/2011 A07, A08 Easy-to-use system management tools 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. N/A R08 IoT@Work High Network Date History Reference 01/2011 B06, C02, Security s in D3.1 Semantic naming/addressing and identification of devices 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. N/A R09 Functional IoT@Work Highest Network Date History Reference 01/2011 C01, Security s in D3.1

91 04/07/2013 Pag. 91 Authenticity and integrity of message datagrams 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. N/A R10 Functional Highest Network Date History Reference 01/2011 Security s in D3.1 Automatic system diagnosis 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.). N/A R11 Functional IoT@Work High Network Date History Reference 01/2011 Security s in D3.1 High availability 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. N/A R12 Functional IoT@Work High Network/Production Date History Reference 01/2011 B01, C04, Security s in D3.1 Self-sufficient operation of systems 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. N/A R13 Functional IoT@Work Normal Network Date History Reference 01/2011 B02

92 04/07/2013 Pag. 92 Clonability 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. N/A R14 Functional IoT@Work Normal Network/Production Date History Reference 01/2011 B03 System and devices compliance with security policy 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. N/A R15 Functional IoT@Work Highest Network/Production Date History Reference 01/2011 C03, Security s in D3.1 Secure remote diagnosis and maintenance 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. N/A R16 Functional IoT@Work Highest Production Date History Reference 01/2011 B07, Security s in D3.1 Company-wide access 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. N/A R17 Functional IoT@Work Highest Network/Production Date History Reference 01/2011 B08

93 04/07/2013 Pag. 93 Secure inter-site communication 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. N/A R18 Functional Normal Date History Reference 01/2011 Security s in D3.1 Accountability of interactions Actions of an entity shall be traced uniquely to that entity [Ref. to NIST-IR-7298]. N/A R19 Functional IoT@Work Highest Date History Reference 01/2011 Security s in D3.1 Scalability 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. N/A R20 Non-functional IoT@Work Highest Date History Reference 01/2011 D1.1 scenarios large scale manufacturing. Reliability 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. N/A R21 Non-functional IoT@Work Highest Date History Reference 01/2011 Additional comments from Error! eference source not found.

94 04/07/2013 Pag. 94 IPv6 Support All 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). 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 High Date History Reference 09/2011 Additional requirement from trends in [3]

95 04/07/2013 Pag Appendix B Specific s List In this appendix we report the specific requirements as defined in D1.2 Common specific requirements Smooth scaling The system shall smoothly support the addition of new devices, services, and applications. 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 Auditability and Accountability 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. 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

96 04/07/2013 Pag. 96 Interoperability 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. 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 Provision of semantically enriched information about devices The system shall provide semantically enriched information about the devices in the production field to both human users and software entities. 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

97 04/07/2013 Pag. 97 Standardisation of entity semantics 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. 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 Process-data provision/dissemination 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. 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

98 04/07/2013 Pag. 98 Event processing 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. 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 Provision of semantically enriched information about events The system shall provide semantically enriched information about events originating from the production field to both human users and applications / services. 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

99 04/07/2013 Pag. 99 Graphical event namespace management tool 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. 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. Run-time verification of system events The EMS shall verify system events at run-time against event rules. 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

100 04/07/2013 Pag. 100 Explicit representation of system set-up. The EMS shall allow the representation of the system set-up. 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. RM.02 Functional Normal Date History 09/2011 Ability to pre-compile monitoring rules 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. 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. RM.03 Functional IoT@Work Normal Date History 09/2011 The EMS in its turn depends on events arriving without delays and in the order they were produced.

101 04/07/2013 Pag. 101 Specific requirements of application configuration/orchestration Avoid undesired interference and respect operational constraints of automation system when carrying out system adaptation/update/maintenance/configuration 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. R01 System extensibility / Extensibility 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

102 04/07/2013 Pag. 102 Correctly carry out system adaptation/update/maintenance/configuration, respecting dependencies between individual adaptation/update/maintenance/configuration operations 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. R01 System extensibility / Extensibility 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. RO.02 Non-functional IoT@Work Normal General/Network/Security Date History 09/2011

103 04/07/2013 Pag. 103 Facilitate/automate system adaptation/update/maintenance/configuration with high complexity 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. R01 System extensibility / Extensibility 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. RO.03 Non-functional IoT@Work Normal General/Network/Security 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.

104 04/07/2013 Pag. 104 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. Standardized Device Pre-Configuration (Device ) 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 preconfiguration. 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, furthermore, enables the vendor to supply devices at a better rate compared to specific pre-configuration. 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/ 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.

105 04/07/2013 Pag. 105 Minimum User Interaction for Pre-Configuration (Device ) This requirement states that the configuration work the vendor is relieved of according to 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 RB.01 is satisfied, too. Both requirements provide affordability of the appropriately pre-configured devices. 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. RB.02 Non-functional IoT@Work Normal Date History 08/2011 Availability of Basic Infrastructure (Environment ) 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. 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. RB.03 Non-functional IoT@Work Normal Date History 08/2011

106 04/07/2013 Pag. 106 High reliability (Environment ) 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. 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 RB.04 Non-functional IoT@Work Normal Date History 08/2011 High scalability (Process ) 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.) 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

107 04/07/2013 Pag. 107 Dead-lock avoidance (Process ) 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. 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. RB.06 Non-functional IoT@Work Normal Date History 08/2011 Updatable soft- and firmware (Device ) 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). 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

108 04/07/2013 Pag. 108 Network access control client The 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. 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 Reasonable computing power 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. 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 IoT@Work High Functional Date History 09/2011

109 04/07/2013 Pag. 109 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. Managed devices (Device and Network ) 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. 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 Fast re-routing and forwarding manipulations (Network ) 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. 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) RN.02 Functional IoT@Work High Date History 09/2011

110 04/07/2013 Pag. 110 Fast network bootstrapping support (Device and Network ) 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. 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). RN.03 Functional IoT@Work High Date History 09/2011 Scalability 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. 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

111 04/07/2013 Pag. 111 IPv6 support (Network ) 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). 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 RN.05 Functional IoT@Work High Date History 09/2011 Automatic/assisted network configuration 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 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. 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

112 04/07/2013 Pag. 112 Rapid and deterministic network initialisation 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. 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 nonfunctional requirement which specifies some additional constraints on Functions Topology & Link State Database & Authentication service. RN.07 Non-functional IoT@Work Normal Date History 09/2011 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. 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. 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 RN.08 Non-functional IoT@Work Normal Date History 09/2011

113 04/07/2013 Pag. 113 Smooth device replacement and restart 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. 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. Both functional RN.09 and nonfunctional IoT@Work Normal Date History 09/2011 Network interconnectivity and reachability of devices 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. 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

114 04/07/2013 Pag. 114 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. 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. RN.11 Non-functional IoT@Work Normal Date History 09/2011 Clear identification and addressing of devices 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 ). 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 Preconfiguration data and planned IDs (done in a planning tool). RN.12 Functional IoT@Work Normal Date History 09/2011

115 04/07/2013 Pag. 115 Offline and online routing along arbitrary paths 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. 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. Both functional RN.13 and nonfunctional IoT@Work Normal Date History 09/2011 Network and service reliability 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. 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 ) RN.14 Non-functional IoT@Work Normal Date History 09/2011

116 04/07/2013 Pag. 116 Quality of Service (QoS) 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]). 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 RN.15 Functional IoT@Work Normal Date History 09/2011 Security specific requirements Secured access to services Access on and usage of resources and services should be secured by an authorisation and authentication mechanism and specific security policies. 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

117 04/07/2013 Pag. 117 Graphical capability and capability revocation definition Capability and capability revocation definition should be eased by using a graphical tool accessible via web or as a standalone application (desktop application). 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 Secure credential management The automation environment shall provide components and mechanisms to manage initial and operational credentials. 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

118 04/07/2013 Pag. 118 Secure network access of devices A device shall be authenticated before access to the operational network is granted. 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. RS.04 Functional IoT@Work High Date History 09/2011 Policy enforcement for devices The compliance of a device to a given policy shall be assessed during network access and regularly during normal operation. 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. RS.05 Functional IoT@Work High Date History 09/2011 Device and system integrity assurance The integrity of devices of an automation environment shall be verified during network access and regularly during normal operation. 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. RS.06 Functional IoT@Work High Date History 09/2011

119 04/07/2013 Pag. 119 Secure device identifier 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. 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 Initial security credentials on devices Prior to installation of a device into an automation system it shall be equipped with security credentials. 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. RS.08 Non-functional IoT@Work High Date History 09/2011

120 04/07/2013 Pag. 120 Secure device-to-device communication Device-to-device communication should provide integrity protection and authentication of devices and of datagrams or sessions. Confidentiality may be supported. 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 Normal Date History 09/2011 Security mechanisms are compliant with system constraints The implementation of the security mechanisms shall be compliant with system constraints and does not disturb "normal" operation. 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. RS.10 Non-functional High Date History 09/2011 Suitable security policies for automation environment Automation environment specific policies should be available. 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

121 04/07/2013 Pag 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 IoT@Work Unified requirements o Mapping to functionality groups as per IoT-A D1.4. [12] o Online requirement list. [8] s: Architecture requirements, assumptions and threats [3] Communication architecture: Plug&Work support mechanisms [2]

122 04/07/2013 Pag Communications s 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.

123 04/07/2013 Pag. 123 Partial fits RN.01 Managed devices 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 selfmanagement behaviour. 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 selfmanagement 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 Recommendation 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 Advocates reinitialisation UNI.096: The IoT-A s of network system shall requirement functionalities after support the does not replacement of devices. autonomous and prescribe what This encompasses dynamic selection the dynamically cloning of of protocols chosen protocols Recommendation RN.09 reaches beyond the limited domain of factory automation and we recommend it to be adopted to

124 04/07/2013 Pag. 124 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 IoT-A Difference in view All devices, their UNI.048: The system IoT-A s functionality and shall provide requirements do their location must interoperable naming not explicitly be clearly mapped to and addressing ; address whether non-ambiguous UNI.509: Each IoT the functionality identifiers. Devices device shall possess a of a device shall have to be easily universal ID, part of it be clearly addressable in order read only and part of it mapped onto to be reachable from read/write. ; UNI.608: identifiers. anywhere in the Each IoT device shall factory, office, or possess a universal ID, even world-wide. part of it read only and part of it read/write. Recommendation Include the mapping of functionalities onto the ID as an option. RN.15 Quality of service IoT@Work IoT-A Difference in view Recommendation 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.

125 04/07/2013 Pag. 125 latency, bandwidth and packet loss. Non-fits RN.03 Fast network bootstrapping support (Device and Network ) IoT@Work ( ) 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. Analysis an recommendation 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 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 Analysis and recommendation 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.

126 04/07/2013 Pag. 126 RN.13 Offline and online routing along arbitrary paths 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. Analysis and recommendation 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.

127 04/07/2013 Pag Non-functional requirements Figure 33: Synopsis of non-functional communication requirements briefly depicts the synopsis of non-functional 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 requirements to the IoT-A requirement list. Partial fits Figure 33: Synopsis of non-functional communication requirements RN.14 Network and service reliability IoT-A Difference in view In order to enable the UNI.012: IoT-A s network to compensate The system requirement failures, such as shall be able stipulates that device or link outages, to handle interference shall Recommendation Addressing link failures is not only important for factory-automation scenarios. We thus