Building Automation Systems from Internet of Things · Building Automation Systems from Internet of...
Transcript of Building Automation Systems from Internet of Things · Building Automation Systems from Internet of...
Building Automation Systems from Internet of Things
Professor Jerker Delsing EISLAB
Luleå University of Technology
What about London railway then?
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
The automation challenge
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
www.arrowhead.eu
Collaborative automation
CHPHomes, offices & industry
Resources Product market
RAW MATERIAL PRODUCTS
WASTE
HEAT, EL
HEAT, EL HEAT, ELHEAT, EL
URBAN ENERGY INTEGRATION
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
10
Arrowhead Process and energy system automation
4 years project 68M€79 partnersCoordinated by
an ARTEMIS CoIE
www.arrowhead.eu - [email protected]
ARTEMIS Industry Association The association for R&D actors in embedded systems
www.arrowhead.euwww.arrowhead.eu
CollaboraKve automaKon
To be demonstrated in real world applications
13
Arrowhead approachesTCP/IP everywhere, middleware nowhere.
Internet of Things -‐ IoT
System of systems -‐ SoS
The Integrating approach
Service Oriented Architectures -‐ SOA
14
The global cloud approach
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
15
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!
17
Classical automation system characteristicsCentralised 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*105 I/O’s
18
Cloud based automation systemsChoice 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
19
IoT -‐ propertiesThings 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
20
Expectations on IoT automation
Integrate any IoT device Real time Energy consumption Engineering Trust
Secure Safe Privacy
Migration into/from legacy systems
21
Cloud integration of any IoT deviceCommunication HW
Existing commercial technology
SOA
But which SOA technology
22
Service Oriented Protocols -‐ A Challenge
IPv4/IPv6/IP multicast
UDP
CoAP DPWS OPC-UA
HTTP 1.1TCP
SemanticsCompression/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
23
One Service Oriented Protocols -‐ Works!
IPv4/IPv6/IP multicast
UDP
CoAP DPWS OPC-UA
HTTP 1.1TCP
SemanticsCompression/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
24What about service protocol interoperabilityIs it possible to make machine assisted translation like
CoAP -> XMPPCoAP -> MQTTCoAP -> OPC-UAOPC-UA -> CoAPOPC-UA -> MQTTNecessary semantics translationNecessary data structure translationsService 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
25
Hard real time IoT cloudHard 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 DevelopmentKyusakov, R., Punal, P., Eliasson, J. & Delsing, J. Oct 2014 In : ACM Transactions on the Web. 8, 4, 29 p.23
www.arrowhead.eu
26
Real Kme local cloud automaKon & inter cloud automaKon
Real time Local cloud #1
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
Real time Local cloud #2
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
Real time Local cloud #3
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
27
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
28
Engineering of IoT automation systems System of systems, SoS, approach
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
29
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
30How to build local cloud? 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
31
Core Functionalities -‐ System-‐of-‐Systems in a local cloud
ARROWHEAD FRAMEWORK COMPLIANT NETWORK
IASMII
Application system
Application system
Application system
App
lication
system
Application system
Application system
Core systems
www.arrowhead.eu
32
AutomaKon orchestraKon local & inter cloud
Local cloud #1
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
Local cloud #2
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
Local cloud #3
IASM
II
Application system
Application system
Application system
App
lication
system
Application system
Application system
33
Three mandatory local cloud servicesService registry system
Authorisation system
Orchestration system
www.arrowhead.eu
34
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
35
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
36
Orchestration System• Orchestration Management service provides the possibility to 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).
39
Arrowhead core systemsFactory description system
Deployment system
Configuration system
Event handler system
Historian system
Meta service registry system
User registry system
Quality of Service system
40
Factory description systemThe 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
41
Configure systemAs 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
ConfigureStoreAuthorisationControlOrchestrationStore
www.arrowhead.eu
42
Deployment SystemThe 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 authenticationUserSystem Discovery
www.arrowhead.eu
43
Event HandlerThe 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
EventLogEventNotificationAuthorisationControl
www.arrowhead.eu
44
HistorianThe 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
45
Meta Service RegistryThe 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
46
Arrowhead Meta Service registryThe 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
47
User / System Registry systemThe 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
48
Quality of ServiceThe 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.
49
Migration into/from legacy systems
Migration of SCADA/DCS Systems to the SOA CloudDelsing, 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.
Experiments made Socardes and IMEC-AESOP projects
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
51Necessary technology for large automation systems in the cloudRobust 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
52Engineering tools for cloud automation systems Development support, documentation.
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
54Service security IoT and cloud securitySecurity at service level
Certificates
Tickets
Data encryption
IPsec
TLS
System security validation methodologies
4. Authentication Process 121
AAA ServerCoAP NASPCuser_KEY
Login service new requestvalidatedValidated & Ticket
Service & Method & Ticketresponse
Service & Method & Ticketresponse
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 andcommunicate that to the CoAP-NAS. This process needs to be flexible and compatiblewith other standards and with this goal the propose framework creates a public loginCoAP service on the CoAP-NAS. This login service must receive a PUT request withone of the following contents as a payload:
• User name and password as plain text. This option is only recommended duringtesting, 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 theframework 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
56
Automation engineering timeAutomation 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)
57
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
58
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%
Lift micro grids
www.arrowhead.eu
59
Use of prediction service enables flexibility in energy demand Energy savings 15%
Water distribution grid
www.arrowhead.eu
60
Load balancing -‐ Luleå SwedenAdaptive control curve service
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.
61
Arrowhead FrameworkPublic by fall 2015
Documentation
Cookbook
Support wiki
Core system code
Tools -‐Open source and commercial
Sample automation services -‐ code
www.arrowhead.eu
62
Critical platform technologiesSecurity -‐ 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
63
Critical system propertiesTrust in cloud automation systems
Real life -‐ at scale -‐ demonstrators enables
Standards,
Society and political acceptance
64
ConclusionsVery 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
Arrowhead.eu an Artemis and ProcessIT.EU project
65