Building Automation Systems from Internet of Things
Professor Jerker Delsing EISLAB
Luleå University of Technology
Heathrow terminal 5
5 million connected points!!
X.XXX.XXX number of bearings
Connected bearings will support Bearing condition monitoring
Railway wagon condition monitoring
IoT Product Segments
Conveyor (Tier2) Components and Parts (Tier3)
Drive Heads LTU & Winches Belt Structure Belting
Pulleys
Feeder Breakers
Components (a.u. idlers, motors, etc.)
Suppliers of these Products are:
Potential partners, and;
Future Service Providers
One customer, KGHM, one component
• 120 km conveyers
• 720.000 idler bearings
Annual growths more than 10% and over 500 billion connected devices are expected worldwide by 2025. - Cisco 2013
Massive automation systems not possible with current technologies Not enough many engineers on the globe to do the job with current
technology
ISA-95 systems in to the cloud?
The
www.arrowhead.eu
CHP
Homes, offices &
industry
Resources Product
market
RAW MATERIAL PRODUCTS
HEAT, EL
HEAT, EL HEAT, EL HEAT, EL
PRIMARY PRODUCT CYCLE
A European Roadmap for Industrial Process Automation
based on global trends and industrial needs. www.ProcessIT.eu
Benefits to the production industry - Spire
• BeJer opKmizaKon and coordinaKon of single processes or process chains and of complete plants and sites,
• Significantly improved resource efficiency.
• BeJer coordinated control loops in one process step and improved collaboraKon of control systems of different processes along a process chain give higher process yields which results in beJer material efficiency, waste reducKon, less energy use and
reducKon of polluKon.
• Improved product quality through beJer process control and smart quality control
• Higher uKlizaKon of equipment
• New collaboraKve soluKons with integrated informaKon management offer new possibiliKes for supply chain management including price-‐based coordinaKon or opKmised market mechanisms
• Safer operaKon of plants due to improved control and shut-‐down procedures.
• PossibiliKes to integrate mulKple processes.
• Shorter delivery Kmes and lower producKon cost.
www.arrowhead.eu
Arrowhead
Process and energy system automation
4 years project 68M€
79 partners Coordinated by
an ARTEMIS CoIE
www.arrowhead.eu - jerker.delsing@ltu.se
ARTEMIS Industry Association The association for R&D actors in embedded systems
www.arrowhead.eu www.arrowhead.eu
To be demonstrated in real world applications
www.arrowhead.eu
ISA-‐95 systems in to the cloud?
The
Arrowhead approaches
TCP/IP everywhere, middleware nowhere.
Internet of Things -‐ IoT System of systems -‐ SoS The Integrating approach
Service Oriented Architectures -‐ SOA
A Survey of Commercial Frameworks for the Internet of Things. Hasan Derhamy, Jens Eliasson,
Jerker Delsing, and Peter Priller, SOCNE workshop at ETFA 2015, Luxemburg
www.arrowhead.eu
Collaborative automation in the cloud
Automation is local -‐ requirements on:
Real time
Security and safety
Continuous engineering
Local clouds are beneficial to:
Latency -‐ real time
Security -‐ supporting safety Less engineering dependencies
Inter cloud actions are necessary and possibly secure!
Automation using SOA Demonstrated in e.g.
Socrades and IMC-AESOP
projects
Classical automation system characteristics
Centralised controllers, DCS, SCADA, PLC, Pull based -‐ time slotted streaming of all data Hard real time
Design time bindings
Seams to have an upper bound of X*10 5 I/O’s
Cloud based automation systems
Choice of centralised or distributed control and data to information computations
Push on event or pull
Late binding -‐ runtime binding
Hard real time?
www.arrowhead.eu
IoT -‐ properties
Things comes and goes
May have limited bandwidth May have limited energy supply
Interoperable services at the device connected to the Internet Integration of IoT systems have to be dynamic
Based on demand and availability
Integrate any IoT device Real time
Energy consumption Engineering
Trust
Secure Safe Privacy
Migration into/from legacy systems
Cloud integration of any IoT device
Communication HW
Existing commercial technology SOA
But which SOA technology
Service Oriented Protocols -‐ A Challenge
IPv4/IPv6/IP multicast UDP
CoAP DPWS OPC-
UA
HTTP 1.1 TCP Semantics Compression/EXI
DDS uPnP
Application
Pilot A XML def
Pilot B JSON def
Pilot C XML def
Pilot D JSON def
Pilot E XML def Pilot A
Service def
Pilot B Service def
Pilot C Service def
Pilot D Service def
Pilot E Service def
XMPP MQTT
One Service Oriented Protocols -‐ Works!
IPv4/IPv6/IP multicast UDP
CoAP DPWS OPC-
UA
HTTP 1.1 TCP Semantics Compression/EXI
DDS uPnP
Application
Pilot A XML def
Pilot B JSON def
Pilot C XML def
Pilot D JSON def
Pilot E XML def Pilot A
Service def
Pilot B Service def
Pilot C Service def
Pilot D Service def
Pilot E Service def
XMPP MQTT
CoAP -> XMPP CoAP -> MQTT CoAP -> OPC-UA OPC-UA -> CoAP OPC-UA -> MQTT
Necessary semantics translation Necessary data structure translations
Service integrity over protocols, data structures, semantics etc.
Hasan Derhamy, Pal Varga, Jens Eliasson, Jerker Delsing and Pablo Punal Pereira
Translation Error Handling for Multi-Protocol SOA Systems, ETFA 2015, Luxembourg
Hard real time IoT cloud
Hard real time dependent on underlaying communication capabilities Local hard real time cloud to prescribe communication
technology
e.g. Industrial ethernet, TTTech, time slotted 802.15.4 SOA overhead eats bandwidth
Use compression EXI
EXIP: A Framework for Embedded Web Development
Kyusakov, R., Punal, P., Eliasson, J. & Delsing, J. Oct 2014
In : ACM Transactions on the Web. 8, 4, 29 p.23
www.arrowhead.eu
Real time Local cloud #1
IA SM
II
Application system Application
system Application
system
Application system
Application system
Application system
Real time Local cloud #2
Application system Application
system Application
system
Application system
Application system
Real time Local cloud #3
IA SM
II
Application system Application
system Application
system
Application system
Application system
Application system
IoT energy consumption
IoT devices may be battery powered Event orientation
Reduces cost of communication No streaming of IoT data to cloud
IoT data/info. to consumer on configured event
Distributed data -> information computation
Subscription to distributed information based on events
Enabling receiver tailored information
Information provided as a configurable services Orchestration of services
Supported by complex event processing Choreography
To be supported by the technology architecture
www.arrowhead.eu
How to build local cloud?
SOA -‐ Abstracting IoT data to services
Services are produced Services are consumed
Service Consumer Service
producer
Application service
IoT System A IoT System B
Exchange information
www.arrowhead.eu
Fundamental conceptual overview
all of its users to work in a common and unified approach – leading towards high levels of interoperability.
A. Overview of Arrowhead Framework
The Arrowhead Framework includes principles on how to design SOA-based systems, guidelines for its documentation and a software framework capable of supporting its implementations.
The design guidelines provide generic “black box” design patterns on how to implement application systems to be Arrowhead Framework compliant. Furthermore, these guidelines allow making legacy systems Arrowhead Framework compliant.
The documentation guidelines include templates for service, system and, system-of-systems descriptions (to be detailed in the following sections of this paper). Due to its complexity there is also a “Cookbook” for hands-on instructions on how to use the framework.
The software framework (Fig. 2) includes a set of Core Services which are capable of supporting the interaction between Application Services. The Core Services handle the support functionality within the Arrowhead Framework to enable Application Services to exchange information. Examples are services for Discovery, Authorization, Orchestration, and System Status. An Application Service handles the data exchange between specialized devices (those that the system is special at). Examples are services for sensor reading, billing, energy consumption, weather forecasts, etc.
The Core Services (Fig. 2) are further divided into three different groups: i) Information Infrastructure (II); ii) Systems Management (SM); and, iii) Information Assurance (IA).
The II services are the set of core services and systems in charge of providing information about the services and how to connect to them. This includes services like Service Discovery, Application Installation and Setup, Service Metadata, etc. The SM services are the set of core services and systems providing support for late binding and solving system-of-systems composition. The SM provides logging, monitoring and status functionality. It also addresses orchestration, software distribution, Quality of Service (QoS), configuration and policy.
Finally, such a software framework can only operate if the system is able provide adequate security and safety levels. Those functions are assured by the IA services, supporting secure information exchange. Example services include those for authorization, authentication, certificate distribution, security logging and service intrusion.
The software framework also addresses the design and prototype implementations of gateways/mediators for making legacy systems Arrowhead compliant.
Finally, the Arrowhead Framework provides a set of rules and principles to: i) address technical property requirements; ii) Arrowhead conformity requirements and, iii) a set of tool(s) for conformity test and verification.
Fig. 2. Arrowhead Framework core and application services
B. The Arrowhead Framework documentation approach The Arrowhead Framework states a common approach of how to document SOA-based systems. The documents structure is built on three levels, namely: System-of-Systems, System and Service level. These are depicted in Fig. 3, showing the links between documents, as well.
Fig. 3. The Arrowhead Framework documentation relationships
The approach is to apply the terms “black box” and “white box” only to the System level since it is well known what it means. However, these concepts are not used at the Service level, where such division is rather meant to be about technology independence/dependence.
At the System-of-Systems (SoS) level, a concrete “System- of-Systems type” is defined in the System-of-Systems Description (SoSD) document. Thus, the particular “system type” needed to fulfill our SoS goals can be implemented. The correct way of working is assured thanks to the “black box”
representation of all Systems in the System Description (SysD).
Therefore, each “system type” can talk to each other or identify the gateways/mediators’ needs.
In the System-of-Systems Design Description (SoSDD) a SoSD instance can be created. All the participating “white box”
Systems (SysDD) must be enumerated and the entire setup must
be explained, including infrastructure description (network
configuration, VPNs, etc.), domain structure, startup behavior
etc. This is a deployment description and it describes the SOA
installations.
www.arrowhead.eu
Core Functionalities -‐
System-‐of-‐Systems in a local cloud
ARROWHEAD FRAMEWORK
COMPLIANT
NETWORK
IA SM
II
Application system Application
system Application
system
Ap pl ic ati on sy st em
Ap plic ati on sy ste m
Application system
Core systems
www.arrowhead.eu
Local cloud #1
IA SM
II
Application system Application
system Application
system
Application system
Application system
Application system
Local cloud #2
IA SM
Application system Application
system Application
system
Application system
Application system
Application system
Local cloud #3
IA SM
II
Application system Application
system Application
system
Application system
Application system
Application system
Three mandatory local cloud services
Service registry system
Authorisation system
Orchestration system
www.arrowhead.eu
Service Registry
• supports a service registry functionality based on DNS and DNS-‐SD.
• all Systems within the network shall publish its producing service within the Service Registry by using the Service Discovery service
«CP» DNS-SD
«System»
Service Registry
«CP» DNS-SD ServiceDiscovery
The Service Registry system
consist of all active producing
services within the network.
www.arrowhead.eu
Authorisation System
• Authorisation Management service provides the possibility to manage the access rules for specific resources.
• Authorisation Control service provides the possibility to control the access for an external service to a specific resource.
• Service Discovery service uses the Service Discovery to publish the Authorisation Systems producing services within the Service Registry System.
«CP» WS-SOAP
«CP» REST_WS-TLS-XML
«CP» DNS-SD
«System»
Authorisation System
«CP» WS-SOAP
«CP» REST_WS-TLS-XML
«CP» DNS-SD
AuthorisationManagement
AuthorisationControl
ServiceDiscovery
The Authorisation System consists of access rules to system resources (i.e.
services).
www.arrowhead.eu
manage the connection rules for specific services.
• Orchestration Store service provides the possibility to fetch configuration for a system.
• Service Discovery supports the publishing of the Orchestration Systems producing services within the Service Registry System.
«CP» REST_WS-TLS-XML
«CP» REST_WS-XML
«CP» DNS-SD
«System»
Orchestration System
«CP» REST_WS-TLS-XML
«CP» REST_WS-XML
«CP» DNS-SD
OrchestrationStore OrchestrationManagement
ServiceDiscovery
The Orchestration System provides the functionality of manage connection rules
(i.e. orchestration of the system
of system composition).
www.arrowhead.eu
Startup Application System B and establish connection
37www.arrowhead.eu
Automation support services
Arrowhead core systems
Factory description system Deployment system
Configuration system Event handler system Historian system
Meta service registry system User registry system
Quality of Service system
Factory description system
The purpose of the Plant description system is to provide a way to find Arrowhead devices and systems through browsable structures based on the physical systems the Arrowhead devices are connected to.
The first specification of this system is intended as a basic interface to present hierarchies and basic information about each object. It is
intended to allow a user to find objects, physical or Arrowhead
systems, based on either their physical location or based on their place
in a functional context.
www.arrowhead.eu
Configure system
As the devices running Arrowhead compliant systems are loosely coupled and provided by different suppliers the engineering is expected to move to open or independent engineering platforms rather than those provided by hardware manufacturers. The
Configuration system allows the configuration of systems from different system suppliers through a uniform service interface.
The Configuration system is designed so that the configuration possibilities are not limited by the service interface but allows all configurations that the configurable system is set to allow.
«CP» DNS-SD
«CP» REST_WS-TLS-XML
«System»
Configure
«CP» DNS-SD
«CP» REST_WS-TLS-XML
ServiceDiscovery
ConfigureStore AuthorisationControl OrchestrationStore
www.arrowhead.eu
The purpose of the Deployment system is to automatically join pre-‐
assigned new devices to a specific Arrowhead Framework enabled cloud and save installation/engineering time.
The idea is to allow an administrator of the local cloud to set conditions under which a factory issued identification key can be used to
authenticate certain systems to allow distribution of more specific keys which then allows a system to connect to the Arrowhead framework without any detailed administration of the specific system.
«CP» DNS-SD
«CP» REST_WS-TLS-XML
«System»
Deployment
«CP» DNS-SD
«CP» REST_WS-TLS-XML
ServiceDiscovery
Deployment authentication UserSystem Discovery
www.arrowhead.eu
Event Handler
The Event Handler system searches and connects to published services of the type EventLog in the ServiceRegistry.
If a system have registered, by use of the EventNofication service, to listen on some specific type of event or system that log events, it will be notified of the specific event when it arrives at the EventLog service interface.
«CP» DNS-SD
«CP» REST_WS-TLS-XML
«System»
EventHandler
«CP» DNS-SD
«CP» REST_WS-TLS-XML
ServiceDiscovery
EventLog
EventNotification AuthorisationControl
www.arrowhead.eu
Historian
The Historian is used for storing large amounts of sensor data, as well as distributing messages from resource constrained devices to a large number of clients. The built-‐in support for Arrowhead Events enables the Historian service to log events and act as an intermediated event cache for device to device or service to service interaction. Thus the Historian behaves like a network cash for data from resource
constrained devices.
www.arrowhead.eu
Meta Service Registry
The Meta-‐Service system stores additional information about a service for offline/later access.
This system is a support system for the service registry for store additional information such as constraint information, up-‐time, or other specific information that can be valuable for the usage.
«CP» DNS-SD
«CP» REST_WS-TLS-XML
«System»
Meta Service Registry
«CP» DNS-SD
«CP» REST_WS-TLS-XML
ServiceDiscovery
Meta-ServiceStore
www.arrowhead.eu
Arrowhead Meta Service registry
The Arrowhead MSR is primarily designed to work with resource-‐
constrained and battery powered wireless devices, and contains metadata about services and devices, such as:
• Battery level, renewable energy sources
• Signal strength, network topology, current access point
• Bandwidth requirements and low-‐latency real-‐time communication using QoS
• Uptime, no reboots,
• Software and hardware revision, manufacturer
• etc.
www.arrowhead.eu
User / System Registry system
The User-‐System Registry system holds unique system identities for deployed systems within the Arrowhead network.
«CP» DNS-SD
«CP» REST_WS-TLS-XML
«System»
UserSystem Repository
«CP» DNS-SD
«CP» REST_WS-TLS-XML
ServiceDiscovery
UserSystemDiscovery
Quality of Service
The Quality of Service (QoS) approach takes care of handling requests from Service Consumers in order to guarantee the reservation of the network and/or computational resources and to give delivery
guarantees to the communications with Service Producers.
Migration into/from legacy systems
Migration of SCADA/DCS Systems to the SOA Cloud
Delsing, J., Carlsson, O., Arrigucci, F., Bangemann,
T., Hübner, C., Colombo, A. W., Nappey, P., Bony, B.,
Karnouskos, S., Nessaether, J. & Kyusakov, R. 2014
Industrial Cloud-Based Cyber-Physical Systems :
The IMC-AESOP Approach. Springer, p. 111-135 25 p.
Boliden 2011
Control over wireless link
Hydraulic control at damm in Tampere 2013 PLC in a global cloud
LKAB 2013
SCADA in a local cloud
Necessary technology for large automation systems in the cloud
Robust communication, wired or wireless IoT sensors, actuators, PLC:s, etc.
DCS and SCADA functionality’
MES and ERP functionality Cloud integration technology
Engineering tools for cloud automation systems Test tools and simulators for debugging
Migration of cloud automation into legacy production system
Suitable security
SoSD: System-of-Systems Description
SoSDD: System of Systems Design Description SysD: System Description
SysDD: System Design Description SD: Service Description
IDD: Interface Design Description CP: Communication Profile
SP: Semantic Profile
Development tools
System Management tool
IoT and cloud security
Security at service level Certificates
Tickets
Data encryption IPsec
TLS
System security validation methodologies
AAA Server CoAP NAS
user_KEY PC
Login service new request
validated Validated & Ticket
Service & Method & Ticket response Service & Method & Ticket
response
Ticket timeout Authentication
Access Control
Authentication Access Control
Figure 6: Authentication process
4.1 Authentication Method
On the authentication process the server must recognize the user as a valid user and communicate that to the CoAP-NAS. This process needs to be flexible and compatible with other standards and with this goal the propose framework creates a public login CoAP service on the CoAP-NAS. This login service must receive a PUT request with one of the following contents as a payload:
• User name and password as plain text. This option is only recommended during testing, debugging and development phases.
• User name and password hash. This is easy to implement and could be authenti- cated directly on the CoAP server (without RADIUS).
• A RADIUS packet (future work).
The possibility to run RADIUS protocol over CoAP (see section 2.4) gives to the framework a flexible authentication method usable with a standard RADIUS server.
An Authentication and Access Control Framework for CoAP- based Internet of Things,Punal, P., Eliasson, J. & Delsing, J.
2015 IECON 2014: Dallas, TX, USA , Oct. 29 2014 - Nov. 1 2014. p. 5293-5299
Test tools for cloud automation.
Automation engineering time
Automation is a service based on products
Simplicity of automation service engineering is market key Arrowhead Framework reduces engineering time
From 5-‐6 days -‐> 6-‐8 hours (Abelko)
Can we build Arrowhead automation systems today?
Robust communication
IoT sensors, actuators, PLC:s, etc.
DCS and SCADA functionality MES and ERP functionality Cloud integration technology
Engineering tools cloud automation Test tools and simulators
Migration to cloud automation Suitable security
➡ Products on the market
➡ Some products on the market
➡ First products on the market
➡ Demonstrated in industrial env.
➡ Some products on the market
➡ Demonstrated in industrial env.
➡ First products on the market
➡ Demonstrated in industrial env.
➡ First products on the market
www.arrowhead.eu
Renewable -‐ PV at building roof Recovery from lift operation Grid supply
Use of 3 shared services: energy tariffs, prediction, energy planning
Energy savings up to 65%
www.arrowhead.eu
Use of prediction service enables flexibility in energy demand Energy savings 15%
Water distribution grid
www.arrowhead.eu
Load balancing of individual building peek energy demands service Multi site optimisation service
Interacting with load balancing and the adaptive control curve
Stena (housing company) claims 5% savings in energy usage.
Arrowhead Framework
Public by fall 2015
Documentation Cookbook
Support wiki
Core system code
Tools -‐Open source and commercial
Sample automation services -‐ code
www.arrowhead.eu
Critical platform technologies
Security -‐ scalable and flexible security solutions
Latency -‐ how provide "clouds" with latency “guarantees"
Dynamics/Continuous -‐ engineering, configuration and deployment
Scalability -‐ for massive numbers of resource constrained IoT and CPS devices
Critical system properties
Trust in cloud automation systems
Real life -‐ at scale -‐ demonstrators enables Standards,
Society and political acceptance
Conclusions
Very large scale IoT system of systems is desired Critical automation trust requires
Latency control and Security Scalability
Ease of continuous engineering
Solutions enabling dynamic automation systems:
Design and Engineering
Deployment, Operation and Maintenance
www.arrowhead.eu
