D5.1 Individual agent communication interface design final · Individual Agent Communication Interface Design 1 September 2015 1! ... FIWARE Generic Enablers (GEs) provide a range

Deliverable D5.1 Version 1.0 Individual Agent Communication Interface Design 1 September 2015

1

Mas2tering Multi-Agent Systems and Secured coupling of Telecom and Energy gRIds

for Next Generation smartgrid services FP7 – 619682

D5.1 Individual Agent Interface Design

Author of Deliverable: Hisain Elshaafi (TSSG)

With contributions from: Hisain Elshaafi (TSSG), Nakul Wali (TSSG), Nicholas Stefanovitch (CEA), Meritxell Vinyals (CEA), Ivan Grimaldi (TI),

Steve McElveen (SMS), Sebastien Breton (CCS), Michael Dibley (CU), Monjur Mourshed (CU), Youssef Oualmakran (LAB), Yann Pankow (LAB)

Quality reviewer: Remi Pecqueur (GDF), Mario Sisini (SMS), Meritxell Vinyals (CEA)

Deliverable nature: Report (R)

Dissemination level: (Confidentiality)

Public (PU)

Contractual delivery date:

01 September 2015

Actual delivery date: 02 September 2015

Version: 1.0

Total number of pages: 44

Keywords: Multi-agent system, inter-agent communication, agent-device communication, generic enablers, communication model and standard


2

Abstract

This document provides a high level design of the inter-communication between agents and the agents’ communication with other smart grid components that are considered in the three Mas2tering use cases. The design will be further detailed in D5.3 and implemented in D5.4 and D5.5. The communication architecture will consist of a holonic organisation of the multi-agent system and will address challenges of the smart grid such as security, scalability and distributed management. In addition, the document builds on the standards’ evaluation performed in D5.2 and relates the appropriate standards to each of the Mas2tering use cases. The document discusses the use of Foundation for Intelligent Physical Agents (FIPA-ACL), Common Information Model (CIM) and other relevant standards for the message specification and communication between agents. Initial evaluation of FIWARE generic enablers was carried out as part of D2.1. This deliverable further analyses the potentially useful GEs that can enhance the non-domain specific features of the Mas2tering platform.


3

Executive summary (Communication requirements in Mas2tering1 can be classified into two categories: generic requirements and application-specific requirements. Whereas generic requirements relate to communications concerning the management of the platform, application-specific requirements relate to communications concerning services offered by applications built on the platform. In addition, the deliverable identifies the different layers of communication in the Mas2tering platform.

This document provides a high level design of the inter-communication between agents and the agents’ communication with other smart grid components that are considered in the three Mas2tering use cases. Mas2tering communication architecture consists of a holonic organisation of the multi-agent system and addresses challenges of the smart grid such as security, scalability and distributed management.

The content of exchanged messages between agents needs to conform to a common syntax and semantics. The standard language specification named “Foundation for Intelligent Physical Agents - Agent Communication Language” (FIPA-ACL) is supported in the JADE framework adopted by Mas2tering. An upper ontology based on Common Information Model (CIM) is considered a candidate to facilitate data exchange and interoperability between agents and with other components. IEC 61850 supports interoperability between Intelligent Electronic Devices (IEDs) within substations. The document discusses the use of FIPA-ACL, CIM, IEC 61850 and other relevant standards for the message specification and communication between agents.

A communication model is described that identifies communication links between the different types of agents and the characteristics of the communication. Agent types include socio-economic agents, control agents, service agents, physical agents and management agents. The model further describes protocols and other specifications that are required to facilitate the communication between agents (including communication with components outside the MAS) at different interconnection levels. Security and privacy considerations in the communication between agents and grid components including security technologies and standards to be used are also analysed.

FIWARE Generic Enablers (GEs) provide a range of non-domain specific support features that can be leveraged by Mas2tering platform. The GE evaluation described in the deliverable indicates that the most relevant GEs are in the area of enhancing communication security and privacy. One of the main challenges in using FIWARE GEs is that they can be removed from their catalogue as in the case of Content based Security GE which has been removed during our evaluation. For example, several GEs that have been used in FINESCE project2 have already been removed. This may cause serious problems if a GE is no longer supported by its developers or becomes inaccessible.

The document also discusses the design of the communication and interfaces for each of the three use cases. It describes and examines the following topics:

− The grid hardware devices that interact with the MAS components, device and agent locations, communication needs and operational constraints,

− The communication-related standards and technologies that need to be used or integrated in the implementation of communication components of the use case,

− Guidelines on the locations of agents to identify the best locations for the MAS components in the electricity network ensuring that Mas2tering can obtain required information while not affecting the operation of the grid.

1 http://www.mas2tering.eu 2 http://www.finesce.eu/


4

Document Information

IST Project

Number

FP7 -‐ 619682 Acronym Mas2tering

Full Title Multi-‐Agent Systems and Secured coupling of Telecom and EnErgy gRIds for Next Generation smart grid services

Project URL http://www.mas2tering.eu/

Document URL

EU Project Officer Patricia Arsene

Deliverable Number D5.1 Title Individual Agent Communication Interface Design

Work Package Number WP5 Title Design and Development of the MAS Components and Interfaces

Date of Delivery Contractual M12 Actual M12

Status Version 1.0 final þ

Nature prototype □ report þ dissemination □

Dissemination level public þ consortium □

Authors (Partner) Hisain Elshaafi (WIT)

Responsible Author Name Hisain Elshaafi E-‐mail [email protected]

Partner WIT Phone +353-‐51-‐30-‐6264

Abstract

(for dissemination)

This document provides a high level design of the inter-‐communication between agents and the agents’ communication with other smart grid components that are considered in the three Mas2tering use cases. The communication architecture will consist of a holonic organisation of the multi-‐agent system and will address challenges of the smart grid such as


5

security, scalability and distributed management. The document discusses the use of Foundation for Intelligent Physical Agents (FIPA-‐ACL), Common Information Model (CIM) and other relevant standards and protocols for the message specification and communication between agents. It further analyses the potentially useful FIWARE GEs that can enhance the non-‐domain specific features of the Mas2tering platform.

Keywords Multi-‐agent system, inter-‐agent communication, agent-‐device communication, generic enablers, communication model, communication standard

Version Log

Issue Date Rev. No. Author Change

15/06/2015 0.1 Hisain Elshaafi ToC agreed

17/07/2015 0.2 Hisain Elshaafi 1st set of contributions added

24/07/2015 0.3 Hisain Elshaafi Addressing initial reviewer comments

27/07/2015 0.4 Hisain Elshaafi Restructuring and updates

06/08/2015 0.5 Hisain Elshaafi Added appendices, partner updates

12/08/2015 0.6 Hisain Elshaafi Added conclusion and executive summary

24/08/2015 0.7 Hisain Elshaafi Additional review comments and updates

31/08/2015 0.8 Nicholas Stefanovitch, Meritxell Vinyals

Updates based on further comments

01/09/2015 1.0 Hisain Elshaafi Final edits and preparations

01/09/2015 1.0 Meritxell Vinyals Final quality check


6

Table of Contents Executive summary ................................................................................................................................. 3

Document Information ............................................................................................................................ 4

Table of Contents .................................................................................................................................... 6

List of Figures ........................................................................................................................................... 8

List of Tables ............................................................................................................................................ 9

Abbreviations ........................................................................................................................................ 10

1 Introduction .................................................................................................................................... 12

1.1 Relationship to Other Deliverables .......................................................................................... 12

1.2 Document Structure ................................................................................................................. 12

2 Agent Interfaces and Communication ............................................................................................ 14

2.1 Agent Communication Requirements ...................................................................................... 14

2.1.1 Generic communication requirements ............................................................................. 15

2.1.2 Application-‐specific communication requirements .......................................................... 15

2.1.3 Types of agents ................................................................................................................. 16

2.2 Mas2tering Data Model, Agent Ontology and Content Language ........................................... 18

2.2.1 Data Model and Ontology ................................................................................................. 18

2.2.2 Content Language ............................................................................................................. 19

2.3 Agent Communication Modelling ............................................................................................ 20

2.3.1 Platform communication architecture .............................................................................. 20

2.3.2 Different types of communications .................................................................................. 22

2.3.3 Agent communication Protocols ....................................................................................... 23

3 Supporting Communication Components ....................................................................................... 26

3.1 Integration of FIWARE Generic Enablers .................................................................................. 26

3.2 Agent and Grid Component Communication Security and Privacy .......................................... 30

3.2.1 Security considerations ..................................................................................................... 30

3.2.2 Security technologies and standards ................................................................................ 32

4 Mas2tering Use Case Communication and Interfaces .................................................................... 33

4.1 Use Case 1 − Secure and effective connection of commercial home energy boxes with public DSO smart meter and consumption profile optimization ................................................................. 33

4.1.1 Communication with Electric Grid and Component Locations ......................................... 33

4.1.2 Standards Usage ................................................................................................................ 33

4.1.3 Guidelines on Locations .................................................................................................... 34

4.2 Use Case 2 − District energy management .............................................................................. 36


7

4.2.1 Grid Devices Interfacing MAS and other Mas2tering Components .................................. 36


4.2.3 Standards Usage ................................................................................................................ 39


4.3 Use Case 3 − Enhancing grid reliability, performance and resilience ...................................... 41

4.3.1 Grid Devices Interfacing MAS and other Mas2tering Components .................................. 41


4.3.3 Standards Usage ................................................................................................................ 43


5 Summary and Conclusion ................................................................................................................ 44


8

List of Figures Figure 1 -‐ Agent communication ........................................................................................................... 14 Figure 2 -‐ Agent Communication Tasks ................................................................................................. 15 Figure 3 -‐ Interaction among agent types. (Note that physical agent do not appear as they are a particular subtype of control agent) ..................................................................................................... 17 Figure 4 -‐ Example of a MAS with two socio economic entities. The first is connected to one hardware device to control room temperature. The other one is connected to two hardware devices; one monitors a PV panel, the other controls a storage unit. No service agents are used in this example. Section 2.3 explains in detail the different interactions between the agents ....................................... 18 Figure 5 -‐ Communication layers for three different MAS boundaries; socio-‐economical agent, service agent and management agent boundary. ............................................................................................. 20 Figure 6 -‐ Agent communication model ................................................................................................ 21 Figure 7 -‐ Layered JADE and Mas2tering platform communication architectures ................................ 22 Figure 8 -‐ Agent Communication Model mapping on JADE platform architecture. The upper part of this figure is representing the Mas2tering MAS platform Model and the lower part is representing the JADE platform. As shown, JADE platform fits properly to Mas2tering requirements. .......................... 25 Figure 9 -‐ Agent data flow applied to personal information ................................................................. 31 Figure 10 -‐ Details of MAS components location on Smart Gateway and their connection with JEMMA platform ................................................................................................................................................. 35 Figure 11 - Grid devices and agents ...................................................................................................... 38 Figure 13 -‐ LV grid components ............................................................................................................. 43


9

List of Tables Table 1 -‐ Communication requirements ................................................................................................ 14 Table 2 -‐ Agent Interaction Model ........................................................................................................ 23 Table 3 -‐ Identity Management Generic Enabler .................................................................................. 26 Table 4 -‐ Security Monitoring Generic Enabler ..................................................................................... 27 Table 5 -‐ Content Based Security Generic Enabler ................................................................................ 28 Table 6 -‐ Authorization PDP -‐ AuthZForce Generic Enabler .................................................................. 29 Table 7 -‐ Gateway Data Handling Generic Enabler ................................................................................ 29 Table 8 -‐ User stories in use case 2 ........................................................................................................ 36


10

Abbreviations

ACL Agent Communication Language

ADSL Asymmetric Digital Subscriber Line

API Application Program Interface

AUML Agent UML

CBS Content-Based Security

CEMS Consumer Energy Management System

CEP Complex Event Processing

CHP Combined Head and Power (also known as cogeneration)

CIM Common Information Model

CORBA Common Object Request Broker Architecture

CRL Certificate Revocation Lists

DAL Device Abstraction Layer

DCOP Distributed Constraint Optimization Problem

DEMS District energy management system

DER Distributed Energy Resources

DM District Manager

DNO Distribution Network Operator

DR Demand Response

DSL Digital Subscriber Line

DSO Distribution System Operator

E Energy (kWh)

EV Electric Vehicle

FIPA Foundation for Intelligent Physical Agents

GE Generic enabler

GPL GNU General Public License

HAN Home Area Network

ICT Information and Communication Technology

IED Intelligent Electronic Device

IIOP Internet Inter-ORB Protocol

JAAS Java Authentication and Authorization Service

JADE Java Agent DEvelopment Framework

JDK Java Development Kit

JSA JADE Semantics Add-in

LEAP Lightweight Extensible Agent Platform


11

LTS Long Term Support

MAS Multi-agent system

MTS Message Transport Service

NGSI Next Generation Service Interface Context Enabler

NVD National Vulnerability Database

OAuth Open Stand for Authorization

OCSP Online Certificate Status Protocol

OID Object Identifier

OML Open Mobile Alliance

OS Operating System

OSGi Open Service Gateway Initiative

OSI Open Systems Interconnection model

OSSIM Open Source Security Information Management

OVAL Open Vulnerability and Assessment Language

OWL Web Ontology Language

P active power (W) can be positive (net load) or negative (net generation)

PDP Policy Decision Point

PEP Policy Enforcement Point

PMU Phase Monitoring Device

PKI Public Key Infrastructure

RBAC Role Based Access Control

REST Representational State Transfer

RMI Remote Method Invocation

SAML Security Assertion Markup Language

SCIM System for Cross-domain Identity Management

SIEM Security Information and Event Management

SOAP Simple Object Access Protocol

SOC State Of Charge (% of full capacity) of a battery

SSO Single Sign-On

TLS Transport Layer Security

UC1 Use Case 1

UC2 Use Case 2

UC3 Use Case 3

UML Unified Modelling Language

ZCL ZigBee Cluster Library


12

1 Introduction This document provides a high level design of the inter-communication between agents and the agents’ communication with other smart grid components that are considered in the three Mas2tering3 use cases. The communication architecture will consist of a holonic organisation of the multi-agent system and will address challenges of the smart grid such as security, scalability and distributed management. The document discusses the use of Foundation for Intelligent Physical Agents (FIPA-ACL), Common Information Model (CIM) and other relevant standards and protocols for the message specification and communication between agents. It further analyses the potentially useful FIWARE4 GEs the can enhance the non-domain specific features of the Mas2tering platform.

1.1 Relationship to Other Deliverables

WP1 will explore the definition of a framework in which actors can successfully coexist while achieving the objectives of the project. This framework includes the introduction of new actors and services. WP2, 3 and 5 aim to overcome the issue related to the possible antagonistic objectives of end consumers (who want to pay less) and DSO (who wants to reduce losses and consumption) linked to the existing tariff structure by exploring technical solutions (from telecom, ontology and algorithm perspectives) in order to build efficient and more dynamic communication between actors. The solutions are tested in WP6.

The design will be further detailed in D5.3 and implemented in D5.4 and D5.5.

The document builds on the standards’ evaluation performed in D5.2 and relates the appropriate standards to each of the Mas2tering use cases. Initial evaluation of FIWARE generic enablers (GEs) was carried out as part of D2.1.

D5.1 extends D2.1 regarding the initial requirements and analysis of the Mas2tering communications. The progress made by D5.1 on the agent communication design will contribute to the overall monitoring and management architecture that is currently being developed in tasks T2.2 and T2.3 resulting in D2.2.

This deliverable also provides an overview of Mas2tering security and privacy mechanisms between agents and grid components including technologies and standards to be used. Further analysis and development of the security and privacy components are provided in WP4 deliverables. D4.1 analyses security standards and technologies relevant to the project.

Design of the communication within each use case described in the deliverable reflects progress made in the overall plans of the use cases as part of T6.1.

1.2 Document Structure

Chapter 2 describes the communication requirements and interfaces of agents. Section 2.1 discusses communications requirements related to the management of the platform, and those on communications related to the services offered by applications built on the platform.

The FIPA Agent Communication Language is a standard language specification supported in the JADE framework adopted by Mas2tering. A review of constructs to support the use of FIPA-ACL in Mas2tering is presented in Section 2.2.

3 http://www.mas2tering.eu 4 FIWARE or FI-‐WARE is a middleware platform, driven by the European Union, for the development and global deployment of applications for Future Internet.


13

Introductory overview of the Multi-agent system (MAS) communication architecture and design is provided in Section 2.3. The architecture will be refined and detailed in D5.3. The section discusses the architecture, types of communications and interaction protocols.

Chapter 3 describes communication components that support non-functional requirements and robustness of the Mas2tering platform. Aspects covered by this chapter include FIWARE GEs which provide a range of general support features for the platform and security and privacy technologies to protect data and communications in Mas2tering.

As part of the activities in WP5, FIWARE Generic Enablers (GEs) are further evaluated in Section 3.1 based on those described in D2.1 with a view of exploiting the relevant GEs to enhance the general capabilities of Mas2tering platform.

In the context of joint work between WP4 and WP5, the security and privacy concerns of the communication across agents and grid components in Mas2tering are investigated in Section 3.2 describing also the technologies and standards involved. D4.1 and later WP4 deliverable dig deeper into these issues.

Chapter 4 deals with the design of the communication and interfaces for each of the use cases in the three sections of the chapter respectively. Each section: (i) introduces the use case; (ii) describes grid hardware devices that interact with the MAS components, device and agent locations, communication needs and operational constraints; (iii) examines communication-related standards and technologies that need to be considered for the use case; and (iv) provides guidelines on the locations of agents.


14

2 Agent Interfaces and Communication This chapter describes the communication aspects of agents and other components in the Mas2tering platform. The following sections discuss agent communication requirements and types and interfaces of agents. They then examine models for Mas2tering agent communication, content languages and ontologies.

2.1 Agent Communication Requirements

The requirements elicited in D2.1 specify a number of tasks that agents have to perform and reasons to engage in an interaction. Among these, two broad categories of communication appear, namely: (i) generic communication requirements i.e. communications related to the management of the platform; and (ii) application-specific communications requirements i.e. communications related to the services offered by a particular application built on top of the platform as part of the Mas2tering solution.

Figure 1 - Agent communication

Table 1 summarises requirements from the requirement matrix of D2.1 including different high level communication requirements and high level tasks identifying specific communication needs. The following two sections detail the requirements for each category of generic and application specific communication requirements.

Table 1 - Communication requirements

Communication requirements Communication requirement id

Related requirement ids from D2.1 Mas2tering requirement matrix

Agent management communications GC1 12, 13, 15, 85

Agent and service discovery communications

GC2 13, 86, 87, 89, 94

Holonic MAS management communications

GC3 21

Agent communication GC4 11, 13

Data in motion security GC5 14, 17, 23, 28, 32-35

Access control GC6 23, 24, 32, 35, 88, 95

Reliable communication GC7 8, 10

Scalable communications GC8 22

Low resource and low latency GC9 25, 26, 59-61


15

communications

Access to real time data from devices AC1 1, 2, 44, 45, 50, 64, 65, 73, 75

Sending commands to devices AC2 6, 9, 20

Access to stored data AC3 3, 4, 52, 62, 92, 93

Sending data to aggregator AC4 44, 46, 49, 51

Access to forecasted data AC5 46-48, 51, 63, 74, 83

Sending and receiving application signals and data

AC6 5, 7, 18, 39, 68-72, 76, 78, 90

Communication with 3rd party software and devices

AC7 16

2.1.1 Generic communication requirements

The platform-level tasks include the following: agent identification, agent registration, agent discovery, security management, and agent activity logging. Moreover the platform should provide specific support for holonic organisations and agents entering and leaving dynamically the system. Security functions include agent authentication and security management of software assets. All these tasks require communication either among different platform´s instances or between agents. As such the platform must provide the agent with the ability to communicate.

Figure 2 - Agent Communication Tasks

In relation to the performance requirements, the agent communications within the platform as well as the connection to smart meters must be reliable. The platform must be scalable, which means that an increasing number of agents and messages exchanged should not cause communication bottlenecks. Therefore, the platform must scale with the number and size of messages exchanged and the number of active agents in the system. Secure communication requirements specify that the communication channel and/or data in motion must be secured through authentication and encryption to protect data integrity and confidentiality. Access to stored data must also be protected. Communications between multiple parties both intra- and inter-organisational are also required to avoid the disclosure of private information. The protection from disclosure however needs to be further restricted by the business models and can be addressed within an application’s specific components, possibly exploiting anonymization techniques. Such issues may not be dealt with at the level of the communication design.

2.1.2 Application-specific communication requirements

Application level tasks such as forecasting, optimisation or cyber defence have specific requirements: access to real time data from devices, access to stored historical data, access to forecasted data,


16

signalling between agents and issuing of commands to devices. These requirements rely on the services enabled to fulfil the generic communication requirement: the applications to discover agents and services, communicate securely and cope with a dynamically changing environment. Application level tasks may also require exchanging data with other software components, such as a device driver, a web service or an external library.

In Mas2tering clear functionalities have been identified that will be developed as part of the Mas2tering solution: the CEMS (Consumer Energy Management System) and the DEMS (District Energy Management System). While the precise decomposition in term of economic actors and software agents is still under discussion, the technical requirements in terms of communication of these systems have been identified in D2.1.

Each CEMS communicates with all devices present in its HAN in order to monitor (i.e. devices are required to report information about their state), manage and control (i.e. the CEMS can issue commands to the devices) those devices. CEMSs must be able to communicate with users to provide them access to relevant information, allow them to provide customized preferences on power consumption and notify them in case of unexpected behaviour. CEMSs should also be aware of technical constraints from the grid and should be able to receive signals from the grid. Recent development of the use case 2 and 3 require CEMS to be able to communicate directly with surrounding CEMS.

The DEMS monitors (production and consumption) the different assets within its scope, including CEMSs, and accesses forecasting, historical and real-time energy price information. The District Manager also requires monitoring the users in order to assess the actual implementation of consumption reduction requests. It communicates signals of allowable charge to charging stations. Real-time monitoring of the voltage of different phases is expected.

Use case 1 deals exclusively with the CEMS and its connections to the DEMS. Use case 2 and use case 3 have two different approaches of DEMS decision and communication architecture. In use case 2 the DEMS is envisioned to be implemented by a set of distributed home energy boxes that communicate directly with each other, therefore requiring a change in the communication pattern from the one presented in the requirements of D2.1. In use case 3 a unique actor called the Flexibility District Manager has been identified, which will have the responsibility of ensuring the DEMS functions by coordinating with the CEMS. In both use cases, cooperative and competitive coordination are envisioned, requiring different dedicated agent interaction protocols.

2.1.3 Types of agents

Software agents deployed on the Mas2tering platform can be categorised to the following agent types with respect to communication: socio-economic agents, control agent, physical agents, management agents, and service agents. Figure 3 proposes an illustration of their interaction.

1. Socio-economic agents define legal boundaries between parts of the systems, thus defining entry and exit points for data and defining where and which privacy requirements would be taken into account. Another role of socio-economic agents is to set the objectives of the organisation or the actor they represent. In technical terms a socio-economic agent will restrict the data flow exchange between components at the architectural level. Each socio-economic agent is associated to a set of physical and control agents (see below).

2. Control agents are subordinate agents of some socio-economic agent. As such, a control agent does not have objectives on its own but rather requires its socio-economic agent to set its objectives and constraints. A control agent in charge of managing some process of its socio-economic agent and the information related to it. A control agent cooperates with other control agents belonging to the same socio-economic agent, while it also competes with the control agents belonging to other socio-economic agents. As such a control agent is involved at the same time in both cooperative and competitive social behaviours.


17

3. Physical agents are a specific type of control agents responsible for facilitating the communications with hardware. Physical agents will host monitoring services. They can also be used to encapsulate communication between the system and 3rd party components, such as web services or external libraries. Using physical agents is key to making the MAS solution usable for both simulation and piloting. Each physical agent is associated to a socio-economic agent, namely to the owner of the particular physical asset. Such socio-economic agent can assign any control agent to control the particular asset.

4. Service agents provide specific services to other agents as part of an application, such as forecasting service. Such services do not require control of devices and have no specific goals. Because a service agent cooperates with control agents while not belonging to the same socio-economic agent, it can be seen as a special type of control agent that cooperates with any other agent.

5. Management agents are responsible for management of the different application-independent services provided by the platform, and the related interaction with the agents of the system. These agents will be responsible of the different tasks identified at the platform level.

Figure 3 - Interaction among agent types. (Note that physical agent do not appear as they are a

particular subtype of control agent)

There are four different types of interactions among agents. Figure 3 illustrates interactions between different agent types. The simplest kind is of providing service (blue arrows in Figure 3). This is done by management agents, providing platform services (e.g. service discovery), and by service agents, which provide application level services (e.g. forecasting). Other interactions are not neutral in the intent of the communication, in the sense that agents either compete or cooperate with other agents or control them. In addition, Figure 4 gives an example of a simplistic configuration in which two socio-economic entities are involved.


18

Figure 4 - Example of a MAS with two socio economic entities. The first is connected to one hardware device to control room temperature. The other one is connected to two hardware devices; one monitors

a PV panel, the other controls a storage unit. No service agents are used in this example. Section 2.3 explains in detail the different interactions between the agents.

2.2 Mas2tering Data Model, Agent Ontology and Content Language

The ability for agents to communicate is a central feature in an agent society. The content of exchanged messages needs to conform to common (shared) syntax and (ideally) some level of explicit semantics. In the framework adopted by Mas2tering, namely JADE, the standard FIPA Agent Communication Language (ACL) is directly supported, which saves overhead in implementation effort. The semantics of ACL are based on speech act theory that models communication as actions that lead to state changes of the participants that could be for example a request to perform an action or to promote a change of beliefs. The theory separates message semantics from that of the content allowing that content to be flexible. Brief reviews of constructs to support the use of FIPA-ACL in Mas2tering are presented next.

2.2.1 Data Model and Ontology

For application in Mas2tering a minimal shared core model or ontology is required in order to support dialog. The adoption of partial or complete external ontology internally will be left as an option for the agent implementer. However reusing representations where possible has the advantage of reusing the knowledge base and not requiring mappings to the internal constructs and representations.

The Common Information Model (CIM) is a candidate for the primary content of the shared model in Mas2tering, consistent with the recommendations in deliverable 5.2. The scope of the recommendations covers its use for inspiring design, facilitating generic communications, guiding the architecture specification and facilitating interoperability. The CIM is widely reported in the context of the (semantic) smart grid and it describes the smart grid domain but not its ‘logical’ semantics, instead relying on implied semantics. Lack of semantic definitions may be adequate in some use cases in Mas2tering and for that purpose a limited model with limited expressivity constructs can be used to


19

avoid complicating the model in those contexts. However, where appropriate, richer models can be formulated using a consistent representation but with the addition of higher expressivity constructs. The exchange of richer models allows richer communication and exchange of information without cumbersome overhead. Not enough details exist yet for the dialog to support the identified use cases. As development proceeds UML sequence diagrams will be used to drive the requirement of ACL content to be modelled. Agent UML (AUML) notations can extend the capture for modelling agent interactions where necessary.

2.2.2 Content Language

The use of FIPA Semantic Language (SL) is proposed as it has various levels of expressivity and the chosen JADE framework for Mas2tering directly supports it. The content language specified in SL for example, forms the informational part of the ACL messages and of course the content is consistent with the performative part which states the pre-conditions and rational effect. The FIPA reference model captures the syntax of SL and some semantics. The ‘profiles’ SL/0, SL/1 and SL/2 capture increasingly expressive statements up to first order predicate and modal logic and action operators but with some decidability restrictions. The various levels of expressivity will allow rich and adequate support of Mas2tering agents’ communication within the identified dialogs, without burdening the implementer with overly complex statement formulations. The schema for message construction is defined by a content reference model which comprises of a class taxonomy. These classes describe entities that include predicate, concept and agent action. In the Mas2tering implementation, where deemed beneficial, those can be further elaborated by ontological descriptions. For statements which include referential expressions and aggregates, the schema also specifies additional term specialisations. The reader is invited to refer to the widely published ACL Content Language Reference Model for the full definitions of the class relationships which capture the language syntax and, to the complete ACL content specification which defines the semantics.

The selected agent framework for Mas2tering i.e. JADE, provides libraries for the construction and parsing of expressions based on the FIPA-ACL reference model for the serialisation and de-serialisation of message content compliant to the SL schema. Message content will be formulated in combination with a Mas2tering ontology specification, the requirements for which will evolve during analysis, driven by the need for common semantics in identified contexts. Similar to the adoption of particular SL profiles in different contexts the particular ontology used can be flexible but has the constraint that it should be shared among participating Mas2tering agents. That ontology will probably be constructed by extending plain JAVA library classes or by generating classes from an OWL. Messages can be encoded into XML or a platform independent binary format known as LEAP. Alternatively simple JAVA classes could be serialised or simple ‘atomic’ strings could be used as message content but both impose design constraints and given the scalability of FIPA-SL the overhead of using SL is not excessive.

In the adopted framework the JADE Semantics Add-in (JSA)5 provides a further option in Mas2tering for the realisation of SL messaging providing some ‘built in’ inferencing for SL. JSA can interpret events perceived by the agent through the use of rule sets called semantic interpretation principles. SL message formulation leveraging the semantics allows the recipient agent to infer the intent instead of needing to implement protocols which could constrain the interaction of agents, thereby introducing flexibility. It remains to be determined if the increased complexity is worth the benefits in the Mas2tering implementation. To evaluate that the pre-defined ‘free’ semantic interpretation principles including those to support intention conveyance, belief transfer (add or remove facts while preserving belief base integrity) will be examined to find if they are relevant to the Mas2tering use cases. JSA also offers more general rules to interpret ‘raw’ messages including the generation of semantic representations of the precondition and rational effect of the ACL message, which are processed other semantic interpretation principles. The adoption of JSA would encroach on the agents internal

5 http://jade.tilab.com/download/add-‐ons/


20

architecture and in particular its ‘belief base’ but would not constrain the implementer to adopt that, i.e. JSA and non JSA agents in Mas2tering can still communicate.

An alternative content language could be OWL. OWL (or other serialisable formalisms) can be used as content in FIPA-ACL and message metadata can be used it identify it. OWL is attractive as a wide range of high quality tools are available for development and deployment: authoring tools, testing environments and resources for use in the deployment such as reasoners and interface frameworks. However due to the lower expressivity of OWL compared to SL messages, OWL would only capture propositions and referential expressions and not modal expressions. Until the details of agent communication use cases are detailed it remains uncertain whether any advantage can be gained from the use of OWL as a content language. Therefore OWL will not be used in the first instance but can be utilised if required and agent designs are not constrained to utilise a single language.

2.3 Agent Communication Modelling

Agents in MAS engage in high-level interactions of different kinds requiring communication links. The kind of interactions agents are engaged in depends on their type. Such interactions are driven by agent interaction protocols, specific for each application and interaction nature. The data format used by these protocols is based on the ontologies described in Section 2.2. Actual message transfer between agents is performed by the Mas2tering MAS platform on behalf of the agents and the transfer protocol is selected depending on the location of the agents. Communication between agents’ physical hosts is encapsulated by the platform and is performed through Internet over any available communication link at the host level. Figure 5 summarises these different layers of interconnection for three different boundaries: socio-economical agent, service agent and management agent. Socio economic agents, control agents and physical agents are all within the same boundary as these elements belong to the same entity. Communication with hardware or third party software is encapsulated by Physical agents. Service agent need to communicate at the application level but not directly with hardware, while the management agent does not need to communicate at application level. All agents share a core of common communication capabilities, over dark blue background on the figure.

Figure 5 - Communication layers for three different MAS boundaries; socio-economical agent, service

agent and management agent boundary.

2.3.1 Platform communication architecture

A running MAS platform is the set of local instances of the platform running on computers located in different physical locations, each hosting a subset of the agents of the system. Local instances of the MAS platform can be connected with each other over the Internet through a variety of communication protocols and physical links. The MAS is the set of agents hosted by the MAS platform. The MAS platform provides agents with facilitated communication capabilities (requirement GC4) over the


21

standard API provided by the OS and Java at the Transport layer of the OSI model. One needs to distinguish between four aspects of communication: communication between agents within the platform (agent communication), communication between platform instances (platform communication), communication between platforms hosts (host communication), and communication between agent and software outside the platform (3-rd party software and hardware communication). Host communication is outside the responsibility of the platform design and requires support at the host level.

Figure 6 - Agent communication model

The canonical communication model behind agent communication is asynchronous message passing. Asynchronous message passing has the following properties: (1) sending a message is a non-blocking action for an agent; (2) a message is not guaranteed to be delivered; (3) messages are not necessarily received in the order they have been emitted; and (4) a received message is not guaranteed to be treated and replied to. Each agent stores received messages in a message box, which is periodically checked. As autonomous entities, agents can freely decide to consider or not a message and process them in any order. In practice communication is reliable (requirement GC7) when transmitting data over a protocol with delivery guarantee, such as TCP (Transfer Control Protocol). The development of applications with specific performance guarantees imposes restriction over the given freedom to the agent not to process messages; however this aspect is not related to the MAS platform itself. While the number of messages that agent send is dependent on specific algorithms implemented, using an asynchronous messages passing model facilitates the implementation of scalable MAS (requirement GC8).

JADE (Java Agent Development Framework) is a popular MAS platform developed by Telecom Italia Lab. It has been chosen as the basic building block for developing the Mas2tering MAS platform. Our approach is to rely on JADE as a basis, extend it to fit specific requirements not already covered by the platform, and ultimately to develop application-level services for smart grids based on such an extend platform. In JADE each instance of the platform running locally on a computer can host one or several containers, each of which can host agents. In JADE, agents have a unique identity within the platform that is independent of their location, called the GUID. This enables agents to communicate with each other regardless of their physical locations and regardless of the communication protocols used to actually transport messages. It also make possible to directly get access to services provided by other agents with the creation of reserved agent identities.


22

In JADE, the services provided by the platform could either be provided by a kernel service or an agent. Communication between agents in JADE is implemented by a kernel service, the MTS (Message Transport Service), which selects the appropriate communication method to transmit the messages depending on the respective location of the agents involved in the communication. If both agents are in the same container, a JAVA event is used, if they are on the same machine but in different container RMI is used, and if they are on different machines CORBA IIOP or HTTP can be used.

Figure 7 presents the different layers of interconnections in the Mas2tering platform. Each layer is an enabler for the upper layer and is independent from the other ones. The uppermost layer is agent interaction. The next layer is platform interconnection between containers located on platform instance running on different hosts. The lower level contains communication protocols and links that are outside the platform, and which correspond mostly to OSI layers 1-4.

Figure 7 - Layered JADE and Mas2tering platform communication architectures

2.3.2 Different types of communications

Services are functionalities provided by agents to other agents and therefore, they require the capability to communicate. These services are of two categories: platform level and application level. Platform level services deal with the agents regardless of any specific application while application level services are directly related to the application. A specific application requires the development of specific agents and services. Instances of application domain specific services for smart grids are forecasting, optimisation and monitoring.

Platform services in JADE that are provided by two different agents, namely: the agent management (requirement GC1), which deals with the naming of agents, arrival and removal of agent; and the directory facilitator agent (requirement GC2), which allows to discovers agents on the platform given a description of the service they provide. Other platforms services needed as part of Mas2tering, such as holonic group support (requirement GC3), logging (requirement AC3) and security need to be either added from existing JADE extensions or developed. Among these, cybersecurity and logging already have some support within JADE. Part of the security can be managed outside the agent space by providing the MTS with encryption of the communication (requirement GC5), which is already supported by the JADE security plugin; part of it should be dealt in the space through a dedicated cybersecurity agent, e.g. for agent access control purposes (requirement GC6).

In order to cleanly interact with hardware devices (requirements AC1-2) and 3rd party software (requirement AC7) from inside the platform, Physical agents are used as an abstraction of such elements. These agents implement interaction with specific pieces of hardware, using web-services, ad-hoc drivers or standardised communication protocols. As such they encapsulate them from the


23

point of view of the platform. Calls to any third party software can also be encapsulated this way, for instance simulation tools such as Open DSS6, solvers or access to web services.

Table 2 outlines the nature of communication between different types of agents as described in Section 2.1.3.

Communication for application specific purposes (requirements AC3-6) is performed by Control agents and Service agents. In chapter 2.1 two of the sub-types of agents identified are: socio-economic agents, which are in charge of taking into account the goals of the owner of assets, and control agents which are in charge of performing the computations to take the decisions on behalf of their respective socio-economic agent in order to reach their goals. Communications between these two types of agents are of different nature and target different needs: Socio-Economic agents generally compete with each other using specific protocols for competitive interaction targeting at limiting the information disclosure. Control agents generally cooperate and use protocols aiming at facilitating information exchange while at the same time making communication more efficient. Service agents provide services to any other agent irrespective of their ownership, for instance forecasting (requirement AC5).

Table 2 - Agent Interaction Model

Type of agent Type of component it communicates with

Nature of the communication

All agents Management Agent Platform level

Socio-economic Agent

Socio Economic Agent Application level (competition)

Control Agent Application level (control)

Service Agent Application level (service)

Control Agent

Service Agent Application level (service)

Control Agent Application level (cooperation)

Physical Agent Application level (cooperation)

Physical Agent

Hardware device Ad-hoc (web service, driver)

3-rd party software Ad-hoc (3-rd party software data format)

2.3.3 Agent communication Protocols

This section describes protocols and other specifications that are required to facilitate the communication between agents (including communication with components outside the MAS) at different interconnection levels.

2.3.3.1 Host communication

Hosts are the devices running Mas2tering MAS platform instances. HAN in use case 1 will be based on ZigBee to support wireless communication between CEMS and smart devices and appliances. This communication protocol must therefore be supported at the level of the platform. Implementing such a connection is part of the smart gateway development, but it is outside the scope of the Mas2tering MAS platform communication design. The connection between CEMS and a district manager will use the public Internet, requiring TCP/IP protocol to be supported by the host and a physical link connection such as ADSL. Implementation of these connections is outside the scope of Mas2tering. Direct local connection between different CEMS is envisioned and is under study.

6 http://smartgrid.epri.com/SimulationTool.aspx


24

2.3.3.2 Platform communication

Transport of message between different platform instances are done in JADE using an MTP (Message Transfer Protocol) that can be either the CORBA IIOP or the HTTP protocol, by default HTTP is used. Fulfilment of communication requirement regarding the security of data in motion can be enforced at this level. While the exact security strategy is going to be provided in document D4.1, it is expected to use a JADE security extension configuring the MTP to be HTTPS, using TLS (Transport Layer Security), thereby providing authentication and encryption of messages. Section 3.2 of this document provides more details on the architecture to be used to secure platform communications.

2.3.3.3 Agent communication

Agent interactions are framed in the context of specific application needs, for instance reporting data from a house to a district manager. A protocol is the specification of an address format, a data format, and flow control primitives. In JADE the underlying message format behind agent interaction is the FIPA-ACL standard. FIPA-ACL messages are used to transfer semantic data between agents. Semantic information is attached thanks to the use of communication act performatives, specifying the intention of a message, and ontologies specifying the data format of the message content. A sequence of message exchanges in JADE is called a conversation. A protocol in JADE defines the rules governing the message sequence of a conversation. Implementation of a protocol is done in JADE using finite state machines, which are represented in JADE using a dedicated JADE composite behaviour. Each initiator and responder in the protocol has to implement its part of the protocol in different classes. JADE already provides a set of basic protocols that can be extended, such as the Contract Net Protocol or the English Auction Interaction Protocol.

The definition of message content and the protocol manipulating them depend on the targeted application. As such the definition of protocols for specific applications will rely on the data model discussed in Section 2.2. Application specific protocols need to be defined based on existing literature and solutions. The services provided in Mas2tering at application level include cybersecurity, optimisation, forecasting and self-healing.

We identified in Table 2 based on the use case refinement, four different types of interactions between agents at Application level i.e. service, competition, cooperation and control. Each type of interaction has different requirements in terms of privacy and persistence of communication. Specific applications can also have additional requirements on efficiency. Detailed requirements of the use case scenarios are yet to be finalized. A certain number of generic services are provided in JADE at agent level, among which agent management, service discovery, and logging. Additional generic services required in Mas2tering are the holonic agent support and specific security features. The development of these generic services also requires extending FIPA-ACL and using a specific ontology.

Figure 8 shows the mapping level from the Agent Communication Model into JADE communication Model. The Agent Communication model is represented in JADE by the Agent Communication Channel, the JADE container maps indirectly to the hardware devices. The Security Management described from the generic communication model in Figure 1 is available as a JADE extension.


25

Figure 8 - Agent Communication Model mapping on JADE platform architecture. The upper part of

this figure is representing the Mas2tering MAS platform Model and the lower part is representing the JADE platform. As shown, JADE platform fits properly to Mas2tering requirements.

2.3.3.4 Third party software communication

Interaction with software outside the Mas2tering MAS platform (e.g. hardware driver devices, external libraries or Web services) is performed by physical agents. Depending on the application, specific communication protocols that are non FIPA-ACL will be used at the level of JADE agents. Communication with specific hardware must follow the applicable standards, for instance OSGi in the case of HAN. Communication with web services will also be implemented at this level, requiring specific agents to be able to communicate through SOAP or REST over HTTP protocols. Specific needs are to be defined based on the use case scenarios implemented.


26

3 Supporting Communication Components This chapter describes communication components that support non-functional requirements and robustness of the Mas2tering platform. Aspects covered by this chapter include FIWARE GEs which provide a range of general support features for the platform and security and privacy technologies to protect data and communications in Mas2tering.

3.1 Integration of FIWARE Generic Enablers

Initial evaluation of FIWARE GEs 7 was carried out as part of D2.1 in terms of their features and relevance to the use cases. This section further analyses the potentially useful GEs the can enhance the non-domain specific features of the Mas2tering platform. One of the main challenges in using FIWARE GEs is that they can be removed from their catalogue as in the case of Content based Security GE which has been removed during our evaluation. Several GEs that have been used in FINESCE project8 have already been removed. This may cause serious problems if a GE is no longer supported by its developers or becomes inaccessible. Table 3 to 7 examine selected GEs from a number of aspects in order to evaluate their relevance to Mas2tering use cases and their integration into the platform. The evaluated GEs include Identity Management GE, Security Monitory GE, Content Based Security GE, Authorization PDP GE and Gateway Data Handling GE.

The GEs are software components usually available as a web application deployed in a web server such as Tomcat or as an online service. Which of the GEs are going to be integrated into Mas2tering platform are yet to be determined. Some of the GEs may be complex with many dependencies or they may not be reliable enough. However, in terms of how it can be envisaged that a physical agent can add features to the GEs as required by the platform e.g. logging, reporting security events. Therefore, from the multi-agent system view GEs are software components that can interact with the agents as external components.

Table 3 - Identity Management Generic Enabler

Identity Management – KeyRock

Chapter Security

Overview & Relevance

Identity Management covers a number of aspects involving users' access to networks, services and applications, including secure and private authentication from users to devices, networks and services, authorization & trust management, user profile management, privacy-preserving management of personal data, Single Sign-On (SSO) to service domains and Identity Federation towards applications. The KeyRock IdM is a free/open source software which code can be found at https://github.com/ging/fi-ware-idm. It can be integrated with any development, especially with any Cloud service.

Documentation The IdM Keyrock GE provides satisfactory documentation regarding the integration and usage of the GE. http://catalogue.fiware.org/enablers/identity-management-keyrock/documentation

Installation Requirements

The documentation describes installation of KeyRock on Ubuntu 12.04 (LTS) server.

Both Horizon (based on Openstack Horizon, https://github.com/ging/horizon), for the front-end, and Keystone (based on Openstack Keystone, https://github.com/ging/keystone), for the back-end, must be installed in order for the generic enabler to run correctly.

7 http://catalogue.fiware.org/ 8 http://www.finesce.eu/


27

Supported Protocols, technologies and Standards

OAuth 2.0, OpenID, OpenID Connect9, SCIM 2.0, SAML 2.0

Relevant Use Case(s)

UC1, UC2, UC3

The GE can be used to support user authentication and identity management in any of the use cases.

Table 4 - Security Monitoring Generic Enabler

Security Monitoring

Chapter Security


The main concerns of Security Monitoring are:

• Normalize and correlate events, raise alarms

• Collect vulnerabilities and evaluate the potential threats

• Identify attacks and score element impact

• Assess risk and propose remediation solutions

• Deliver a user-oriented security visualisation service.

The Security Monitoring GE is part of the overall Security Management System in FI-WARE and therefore is part of every FI-WARE instance. The services offered by the Security Monitoring include:

1. MulVAL Attack Paths Engine

It conducts vulnerability analysis on a network. The engine can be accessed using web browser, allowing a user to generate attack graphs. Attack graph presents a qualitative view of security discrepancies: - It shows what attacks are possible, - It captures the interactions among all attack possibilities.

2. Scored Attack Paths

These are based on the Attack Graph provided by the Mulval Attack Paths Engine, and the individual scores of each step. The score of each path reflects the risk associated to the path as a whole, based on the individual scores of each step that have been previously calculated by the MulVAL Attack Paths Engine.

3. Remediation

Remediation provides tools to security operators for proposing cost-sensitive remediations to attack paths. To calculate the remediation to the chosen attack path, the tool first extracts the necessary information from the attack path to be corrected. Then, it computes several lists of remediations that can reduce the attack path. Finally, it estimates the cost of each list of remediations and proposes all the lists of remediations, ordered by cost.

Documentation http://catalogue.fiware.org/enablers/security-monitoring/documentation

9 http://openid.net/


28


The documentation describes the installation of each of the three components which have varying environment (Linux distributions, runtime container, eclipse, browser, etc) and resource requirements.


The GE incorporates or requires support of the following:

• Open Source OSSIM SIEM10,

• NESSUS11 and OVAL (Open Vulnerability and Assessment Language)12 vulnerability scanners

• Vulnerability databases e.g. NVD13


UC1, UC2, UC3

Since the GE reuses some open source software, Mas2tering may choose to use those software components directly from their original source.

Table 5 - Content Based Security Generic Enabler

Content Based Security (CBS)

Chapter Security


Content-Based Security (CBS) GE protects data and its metadata at its source and integrates access control to the data. The data is protected by encrypting or signing at the time of its generation. Access to the encrypted data is controlled by restricting access to the cryptographic keys needed to remove protection from the data. This function can be used in Mas2tering to ensure secure communication of sensitive data. The GE has been removed recently from FIWARE Website. This reflects the risk of losing support for the FIWARE GEs.

Documentation CBS GE provides documentation on the installation as well as on the architecture of the GE. It also provides description of unit testing of the GE security features. The documentation quality and level of detail can possibly be improved. GE developers do respond to enquiries regarding its installation and usage.

http://catalogue.fiware.org/enablers/content-based-security-cbs/documentation


The CBS GE runs in Tomcat server. The CBS GE requires the following Generic Enablers:

- Access Control GE: This is used to make policy-based decisions on whether the user can access the protected data. Note that the CBS Broker contains a hardcoded policy decision point for use in the end to end test, so that the installation can be verified independently. However, the Access Control GE is required for a full deployment.

- Identity Management GE - This is used to manage the identities of users and their roles. Note that it is not needed to run the end to end test, so that the CBS installation can be verified independently. However, it is needed for a full deployment.

Supported Not enough information accessible regarding encryption algorithms and other

10 https://www.alienvault.com/products/ossim 11 http://www.tenable.com/products/nessus-‐vulnerability-‐scanner 12 https://oval.mitre.org/ 13 National Vulnerability Database, https://nvd.nist.gov/


29

Protocols, technologies and Standards

security mechanisms implemented.


UC1, UC2, UC3

This function can be used in Mas2tering to ensure secure non-real-time communication of sensitive data. CBS GE aims to ensure access control and protection of sensitive data through encryption and digital signature. This helps protect confidentiality and integrity of data. Authentication relies on the Access Control GE. Assurance regarding those security functions requires wider user community and feedback regarding potential vulnerabilities.

Table 6 - Authorization PDP - AuthZForce Generic Enabler

Authorization PDP – AuthZForce

Chapter Security


Authorization PDP (formerly Access Control GE) helps externalize the authorization logic and provides Attribute-Based Access Control features. Combined with the Identity Management GE and the PEP proxy, the GE gives a complete access control solution. The GE provides an API to get authorization decisions based on authorization policies.

Available Documentation

http://catalogue.fiware.org/enablers/authorization-pdp-authzforce/documentation


CPU frequency: 2.6 GHz min CPU architecture: i686/x86_64 RAM: 4GB min Disk space: 10 GB min Operating System: Ubuntu 14.04 LTS JDK 7 Tomcat 7.x AuthZForce can be downloaded and installed using Ubuntu installation commands. For further configurations, the admin needs to address a number of issues including server security, certificate authority, server SSL certificate, user and role management, and domain role assignment. These are described in the GE’s documentation.


RESTful web services, HTTP/1.1, OAuth 2.0, XACML 3.0, XML data serialization format.


UC1, UC2, UC3

The GE can be used together with the required GEs to support attribute based access control in any of the use case.

Table 7 - Gateway Data Handling Generic Enabler

Gateway Data Handling GE - EspR4FastData


30

Chapter Internet of Things Services Enablement


The Data Handling GE addresses the need to process data in real time. EspR4FastData is a servlet application. It provides a REST management API, and a partial implementation of the standardized NGSI API. It collects NGSI data in real-time from compliant IoT protocol adapters, transforms them to value-added application relevant events and propagates them towards subscribers. Subscribing applications can then collect filtered-relevant real-time data, thus externalizing the responsibility for dedicated development of asynchronous data analysis. CEP processing rules are described in a SQL-like language, they are completely dynamic and therefore they can be updated or deleted on the runtime. Gateway Data Handling GE is integrated with the other enablers of FIWARE, using the Open Mobile Alliance (OMA) Next Generation Service Interface Context Enabler (NGSI 9 / NGSI 10) which is used to encapsulate data and events from RFID tags, Zigbee or IETF devices, as many other smart things.

Available Documentation

http://catalogue.fiware.org/enablers/gateway-data-handling-ge-espr4fastdata/documentation


§ Min 100 MB disk space

§ Min 512 MB RAM

§ 1Ghz CPU

§ EspR4FastData runs in a servlet container environment such as Tomcat.


§ RESTful web services

§ HTTP/1.1 (RFC2616)

§ XML data serialization format

§ Esper: EspR4FastData uses Esper java library from EsperTech. It supports a dedicated CEP rule (EPL) language. It’s an open-source software available under the GNU General Public License GPL.

Relevant Use Case

UC1

The GE could be used for real-time data processing and generation of events at the energy gateway.

3.2 Agent and Grid Component Communication Security and Privacy

This section describes the consideration of the role of security and privacy between agents and grid components including technologies and standards to be used. Further analysis and development of the security and privacy components are provided in WP4 deliverables.

3.2.1 Security considerations

Home agents may locally collect and process (personal) raw data, but also exchange it either with local instances of the MAS platform or with other agents hosted remotely, prior to any anonymization process. Furthermore, physical agents may interact with hardware components, such as the smart meters, using web services.


31

Figure 9 depicts the personal data flow from its inception to its storage at various locations, where different security considerations shall apply since either the level of trust is different or the information crosses several security domains.

The security domain 1 is represented by the home physical boundaries. All raw data is generated from this location. This is the most sensitive area where all personal data is created.

CLOUD STORAGE

AGGREGATOR SITE

HOME

GATEWAY

SMART METER JADE AGENT

LOCAL (IN-‐HOME) RAW DATA

JADE AGENT PRIVACY

ANONYMIZED DATA

[1] [2]

[3]

[6](4]

PUBLISHED RAW DATA

[5]

[8]

[7]

EXTERNAL STAKEHOLDER

3RD PARTY

[9]

[A]

[B]

[C]

[D]

[E]

EXCHANGED DATA

SECURITY DOMAIN 1

SECURITY DOMAIN 2

SECURITY DOMAIN 3

SECURITY DOMAIN 4

Figure 9 - Agent data flow applied to personal information

The security domain 2 may be considered as an extension of the security domain 1, and as such being considered as being sensitive, where personal raw data may be stored. Besides providing a reliable storage capacity, it delivers additional service to the home user, through a graphical user interface (not represented in the diagram). For instance, it could allow remotely managing the home smart appliances through the energy management system. The personal raw data stored in the security domain 2 is exclusively accessible to the home user only.

The security domain 3 is related to the aggregator site where clients’ personal raw data is centrally stored, then anonymized. A first repository contains all personal raw data that are directly published from the home site. This raw data is not intended to be processed by any application but the anonymization process. Then an anonymized repository is made available to all trusted applications that require manipulating the collected data. The security domain 3 is in charge of ensuring the privacy and anonymization of the collected data.


32

The security domain 4 is a third-party security domain, which can have access to anonymized data. Access to the anonymized data is restricted to some trusted remote stakeholders. This is not to be confused with a public access.

All data exchanged between assets is protected in terms of confidentiality and authenticity. This means that communication links from [1] to [9] inclusive are protected against eavesdropping, i.e. an encryption channel is established.

3.2.2 Security technologies and standards

For a distributed system, such as the MAS, the security must be deployed both at the infrastructure and application levels. Depending on observed performance issues, the JADE agent running on the security domain 3 could delegate the security service to an external security proxy in charge of implementing the encryption/decryption functionalities, acting thus as a TLS accelerator.

The security enforced in the agent is threefold:

• Message authenticity (integrity and confidentiality),

• Certificate-based authentication,

• Role-based or attributed-based access control (RBAC, ABAC)

Message authenticity is provided by the JADE framework. Even though information exchanged between containers is transferred over a secure TLS v1.2 channel, it is not signed. A malicious agent could then issue a fake command in order to force a remote container to behave in a way that differs from the original purpose. Therefore, message signature could be required to guarantee message (command) authenticity and to ensure confidence that data has not been tampered with during transmission.

Certificate-based authentication could be used in the event of establishing a secure TLS connection between a client and a server application. Either server certificate-based authentication or mutual certificate-based authentication could be enforced, depending on the considered data flow to be secured. Using X.509 v3 certificates implies relying on a Public Key Infrastructure (PKI), which issues certificates and publishes certificate revocation lists (CRL). The latter can be accessible through an HTTP interface or through an Online Certificate Status Protocol (OCSP) responder. It has to be observed that revocation pointers are hard-coded in the certificates, and the unavailability of the CRL could interrupt the verification process enforced when establishing a secure connection. Object Identifier (OID) for version 3 certificate extensions may be set in the certificates to have application specific policy constraints, such as the distinction between management agents versus ordinary agents.

Attribute-based access control could be enforced by the PANDA (Policy Authoring and Analysis System) prototype developed in TSSG in order to support privacy protection. PANDA is a policy authoring, analysis and evaluation framework that ensures regulations and best practices are strictly adhered to at all times during data exchange and online collaboration. It may be used to secure and privacy preserve consumer data stored in the different data stores introduced in the previous figure. It could rely on the JADE authentication mechanism based on JAAS (Java Authentication and Authorization Service) API. In addition, RBAC or ABAC may be used to enforce fine-grained access control list.


33

4 Mas2tering Use Case Communication and Interfaces This chapter deals with the design of the communication and interfaces for each of the use cases individually. Each section (1) introduces the use case, (2) describes grid hardware devices that interact with the MAS components, device and agent locations, communication needs and operational constraints, (3) examines communication-related standards and technologies that need to be considered for the use case, and (4) provides guidelines on the locations of agents.

4.1 Use Case 1 − Secure and effective connection of commercial home energy boxes with public DSO smart meter and consumption profile optimization

Smart Main Meter: it is the meter provided by the local DSO. It is already installed in customers’ houses and can be interfaced with the Smart Gateway through a supported protocol (ZigBee HA for the Enel Smart Info, ZigBee SEP for EDMI Mk7B meter provided by SMS Ltd). This component provides:

• energy consumption data;

• instantaneous power currently used in the house;

• energy production data;

• instantaneous power produced by the photovoltaic system or other domestic RES.

Smart Appliances: appliances that are able to be scheduled and to provide energy consumption information to the Smart Gateway;

Smart Gateway: an embedded system connected to the home broadband router via an Ethernet cable. It provides standard APIs to interact with devices through the JEMMA open source software, which coordinates the ZigBee wireless low power network used by HAN devices (Smart appliances and Smart meters) to communicate with the gateway.

4.1.1 Communication with Electric Grid and Component Locations

In this use case, the communication between electric grid components located in the HAN and the MAS platform is enabled through the Smart Gateway, which on one side is able to interact with HAN devices using ZigBee protocol and on the other side allows a physical agent to monitor and perform actuation of those devices through OSGi Device Abstraction Layer specification services. These services can be referenced by the physical agent via the OSGi Service Tracker if the Physical Agent is an OSGi app, or through HTTP REST and WebSocket APIs in case the Physical agent is a non-OSGi app or it is hosted in a remote environment.

4.1.2 Standards Usage

• ZigBee HA 1.2: A low power wireless sensor network protocol. It is designed for HAN devices, relying on:

• 802.15.4 protocol specifications for MAC level, and

• a comprehensive ZigBee Cluster Library (ZCL); a list of functions already modelling and providing a lot of the required interactions between energy boxes and HAN devices such as the exchange of consumption profile and energy cost and the possibility to perform instantaneous demand.


34

• OSGi specification: this specification is used on gateway software. The scope of the specification is to provide service-oriented, modular, dynamic and manageable gateway software components. The specification also offers some tools to support software provisioning ensuring a clean and adequate lifecycle for software running on gateways.

• OSGi Device Abstraction Layer: The scope of this layer (defined in RFC0196 and RFC0210) is to define a uniform layer to access devices independently from the technology and protocol supported by the device.

• CEMS: Customer Energy Management System is the name used to identify a physical component which enables the management of energy consumption, production and load scheduling inside the HAN. This definition has been provided by the CEN-CENELEC-ETSI Smart Grid Coordination Group and has been implemented in JEMMA open source software component running on the Smart Gateway.

• Rest over HTTP: Representational State Transfer (REST) refers to software architecture used to address resources in a distributed service oriented software environment. The Smart Gateway uses this paradigm to address devices exposed by the OSGi DAL layer exploiting HTTP operations to provide a standard and simple way to access device functions.

• WebSocket: A W3C standardized Web technology enabling full-duplex communication between client and server. It is used in the Smart Gateway to implement a publish/subscribe pattern in order to provide an adequate and scalable way to access device notifications originated in OSGi Device Abstraction Layer.

4.1.3 Guidelines on Locations

There are three types of agents of the MAS platform playing a role in use case 1 (Figure 10):

• Physical agent: this MAS component is in charge of monitoring and controlling the hardware (e.g. issuing commands to smart appliances, monitoring energy usage). This agent uses JEMMA DAL APIs via Web (REST/WebSocket) or references DAL functions using OSGi Declarative Services. Because of this the physical agent resides on the gateway hardware and can be installed in both OSGi runtime environment (using JADE OSGi14) or as a runnable JAR in a separate process.

• Control agent: this agent has the responsibility of making decision on the required control operations that are going to be performed to achieve a goal that has been given by a socio-economic agent.

• Socio-economic agent: this agent is in charge of setting the goals of control agents according to user preferences and constraints modelled inside its own business logic.

Both control and socio-economic agents can run either on the Gateway or on a server cloud platform and the location depends on the functionality that needs to be implemented by the agent and on the need of an active internet connection to accomplish the required task.

14 http://jade.tilab.com/doc/tutorials/JadeOsgiGuide.pdf


35

Figure 10 - Details of MAS components location on Smart Gateway and their connection with

JEMMA platform


36

4.2 Use Case 2 − District energy management

Use Case 2 aims to demonstrate the benefits of local district management at the services of the end consumers and of the DSO.

Day to day coordination at district level between energy supplier, end consumers15 and DSO, regarding the way their energy flexibility is used, is currently limited. Due to new digital techniques, the grid can be more precisely monitored at the cheapest cost. It opens door to new services for end consumers by utilities, for a more dynamic management of the grid and consequently a reduction of grid capex (i.e. capital expenditure).

To enhance this management, Mas2tering aims to explore devices and techniques to create a framework for efficient interactions between devices and actors.

Considering the complex relationships between grid actors, the existing energy markets in various countries and the related constraints, WP1 explores the definition of a framework in which actors can successfully coexist while achieving the objectives of the project. This framework includes the introduction of new actors and services.

WP2, 3 and 5 aim to overcome the issue related to the possible antagonistic objectives of end consumers (who want to pay less) and DSO (who want to reduce losses and consumption) linked to the existing tariff structure by exploring technical solutions (from telecom, ontology and algorithm perspectives) in order to build efficient and more dynamic communication between actors.

Use case 2 will focus on the services that can be provided by competing actors of the energy sector, with consideration of smart devices owned by end consumers, sold for instance by a utility within a global services package (installation, maintenance, energy efficiency and dynamic management with valorisation of flexibility over energy markets).

In order to explore and identify solutions that overcome ‘hardware’ bottlenecks, lab tests will be performed for use case 2 in WP6. The user stories will involve the coordination between two or three buildings, linked to different power flexibility sources (including among others CHP, charging station and hybrid boiler units).

4.2.1 Grid Devices Interfacing MAS and other Mas2tering Components

The DEMS (district energy management system) communicates with a residential component (the CEMS known as energy box), district components (district charging stations, district storage and district cogeneration), and substations as illustrated in Figure 11. These devices are useful for the user stories defined for use case 2 (see Table 8). User stories are number based on D2.1.

Table 8 - User stories in use case 2

Story Goal Hardware Location Communication Constraints

4.1 DER managed by DM DEMS District CEMS-DEMS: power

- update: 15 min

4.2 DM manages

- district storage - district EV charging

DEMS District district storage –DEMS: power, state of charge

15 End consumer is a residential or business entity consuming energy and using devices that allow their energy flexibility to be managed remotely.


37

stations - district CHP

district EV storage – DEMS: power (max and min for both charge and discharge), energy (required energy for each moment)

district CHP-DEMS

4.3 DM manages

- district EV charging station

DEMS District district EV charging station – DEMS: power (max and min for both charge and discharge), E (required)

4.4 Asset maintenance by DM

DEMS District DEMS – other district actors and DSOs: Various information (transformer load e.g. battery charge/discharge cycle information)

4.5 DM detects automatically new devices and services

DEMS and CEMS

District CEMS – DEMS

District components (storage, charging stations, RES) – DEMS

4.6 DM forecasts district consumption and production

DEMS District District components (storage, charging stations, RES) – DEMS: power (forecasted)

4.7 Consumer classification

DEMS District CEMS – DEMS: power

15 min or lower resolution (e.g. one houre)

4.8 DM manages power quality

DEMS District District components (storage, charging stations, RES) - DEMS: Various information

The identified required signals are: power, state of charge (SOC) of the battery and required energy (for the electric vehicles).


38


Figure 11 - Grid devices and agents

The communications between the different components is illustrated in Figure 11. Components of use case 1 (i.e. that are out of scope of use case 2) are drawn in light blue. The central element is the DEMS (district energy management system) that communicates with the different CEMS (consumer energy management system), the district level components (in green) and the substation.

Substation DEMS

District charging station

District storage

District CHP

CEMS

PA, CA

PA

PA

PA

Smart Appliances Home Charging Station

Home CHP Home PV Traditional Appliances

PA PA PA PA PA

Home Storage

PA

PA

CEMS CEMS

CEMS

PA, CA


39


Today, there are no standards that both cover the needed electric and DR signals. The most mature standard for electric signals is IEC 61850 and for demand response is OpenADR.

IEC 61850 is one of the six standard families that are considered as core standards by the IEC. This standard is widely implemented in IEDs (intelligent electronic devices). Smart substations (and consequently smart grids) rely on these intelligent devices. They combine monitoring, protection and control functions. Thanks to their microcontroller and internal memory they can be programmed and perform automatic function such as reporting measurement or operating switches when some conditions are met. Moreover, IEDs include communication interfaces (e.g. Ethernet) that enable communication. Finally, the use of IEC 61850 eases the engineering work for the integration with other devices. IEC 61850 is a set of different standards that defines:

• Electric signals (e.g. voltage, current, active power, harmonics, etc.) and important signals for substations devices (overvoltage, undervoltage, temperature, etc). These are defined in IEC 61850-7-3 and IEC 61850-7-4

• Configuration and description of devices at the substation. This is defined in IEC 61850-6

• A communication protocol. IEC 61850 is based on Ethernet. Two protocols over Ethernet are used: Generic Substation Event (GSE) and Sampled Value (SV). They are defined in IEC 61850-8-1 and IEC 61850-9-2

IEC 61850 is an evolving standard with new object models that have been added or under development for electric components such as photovoltaic, batteries and electric vehicles. The use of XML and Ethernet in IEC 61850 contributes to an easier combination with the ICT asset. However IEC 61850 does not define demand response signals such as prices or curtailment signals.

For DR signals, OpenADR is the most widespread standard for the home area and distribution level.

OpenADR supports signals for electricity, energy prices, demand charges (the contracted power), customer bids, load dispatch, and storage. OpenADR is based on IP and uses either Simple HTTP or XML. Although OpenADR has been approved as IEC/PAS 62746-10-1 by IEC in February 2014, it is

CEMS

DEMS

District charging station

District storage

Substation

District CHP

openADR

IEC 61850

?

openADR

IEC 61850

openADR

IEC 61850

openADR

IEC 61850

Figure 12 - Standards in use case 2


40

not considered as a core standard by the standardization body16. There is currently work to adapt OpenADR to the CIM that is a core standard17. That would make demand response compatible with utility standards.

Other standards worth to be considered are CIM (IEC 61970 and IEC 61968) and Zigbee SEP 2.0. We recommend IEC 61850 and OpenADR (see Figure 12).


DR agent should be located at DEMS. There should be a “master” DR agent per DEMS that communicate with the district resources (CEMS, district charging station, district storage and district CHP) that also have each a master DR agent. The DR agent of the DEMS is in turn connected to the DR agent of the DSO. The DR agent at the DEMS can be subdivided into sub-agents according to different criteria (e.g an agent per customer or an agent per type of resource). Thanks to this kind of encapsulation, the district manager can change its architecture without any impact on the other stakeholders as long as the interfaces with the DEMS remain the same (i.e. same monitoring/DR signals and DR command are sent). The DR agent at the resources and DSO are described respectively in the section about use case 1 and use case 3.

16 OpenADR, IEC Approves OpenADR Specification, http://www.openadr.org/index.php?option=com_content&view=article&id=92:iec-‐approves-‐openadr-‐specification&catid=21:press-‐releases&Itemid=121, February 25, 2014 17 OpenADR, Enabling The Standard for Automated Demand Response, http://www.pointview.com/data/files/6/5221/2712.pdf, September 3, 2014


41

4.3 Use Case 3 − Enhancing grid reliability, performance and resilience

Use Case 3 aims at enhancing grid reliability, performance and resilience through a more active monitoring of the LV grid and smart devices to enable automation or self-healing of the grid (e.g. power distribution grid reconfiguration in case of default, over/sub tension) and can be considered as an extension to UC2.

As for UC2 (more details in Section 4.2), the general context is that there is currently limited day to day coordination at district level between energy supplier, end consumers and DSO, regarding the way their energy flexibility is used. Technical opportunity for advanced energy flexibility services is quite new. DSOs used to be mainly focused on capital expenses for grid reinforcement. As a result of new digital techniques, the grid can be more precisely monitored at the cheapest cost. It opens door to new services for end consumers by utilities and for a more dynamic management of the grid and consequently a reduction of grid CAPEX.

To enhance this management, Mas2tering aims to explore devices and techniques to create a framework for efficient interactions between devices and actors.

Use case 3 will focus on the power distribution grid (Low voltage). Smart devices such as link boxes will be owned and managed by DSOs. The value brought by the devices to the grid management (losses, self-healing ability to reduce non distributed energy) will be simulated by WP6.

4.3.1 Grid Devices Interfacing MAS and other Mas2tering Components

In order for monitoring of the grid to be effective, there will be a requirement to install measuring equipment at sufficient and appropriate points within the DSO network(s). Depending on the balancing methods selected, there may also be a need for the measuring equipment to be utilised to provide automatic control and operation of switchgear and other network devices.

Such devices may be required to measure voltage, current and power flows, and to be intelligent enough to differentiate between transient and sustained changes in power levels and/or direction, in order to protect the network (and customers) from nuisance supply interruptions or fluctuations.

Given that the topology of the low voltage grid can be comprised of underground, overhead, or a combination of construction types, the optimum location of monitoring equipment may ultimately be compromised by the need to ensure the safety and operational effectiveness of the network, and the prevention of unauthorised or malicious access to the equipment.

Main components are as follows:

• IED (see use case 2) including PMU (Phase Monitoring Devices).

• PMUs are being deployed in smart substations because they enable accurate knowledge of the state of the network (magnitude and angle of voltage and current, active power, reactive power and frequency) in real time. PDCs (Phasor Data Concentrators) aggregate PMUs. IEEE C37.18 and IEC 61850-90-5 are used for communications.

• Automatic power switching and routing devices, such as specially adapted cable link boxes (or Underground Distribution Box – UDB) and feeder pillars (or Distribution Cabinets). Whilst the hardware has been used in LV distribution networks for many years (providing ‘dumb’ protection and requiring manual intervention for maintenance and load management etc.), the retro-fitting of automation devices can allow the network to become smart and responsive to the bi-directional load flows increasingly experienced due to localised and micro generation.


42

• Storage managed by DSO: detailed network (and customer) analysis will be required to establish whether localised storage presents a viable operational and commercial alternative to conventional network upgrades on a case by case basis. However, demonstration trials by

several DSO’s, working closely with manufacturers and suppliers, have enabled the technology to be developed and improved, providing several alternative options depending on the level of storage required and the operational land available.

• The Low Voltage grid itself needs to be designed and built (or adapted) to facilitate the smart grid technology. There will be physical and financial constraints on this, including the ability to mesh and interconnect the grid, the current capacity of the interconnecting cables and equipment, and the availability of suitable locations for housing the smart apparatus at optimum points on the network.


It is highly unlikely that a DSO will allow full automation or self-healing of any part of their network without there being sufficient monitoring and remote operation protocols being established. There may be situations whereby upstream or downstream activities on the network require any automation to be rendered inactive for operational or safety reasons, so communication with each automated component will be required. There are established standards and protocols for communication with apparatus within and between substations including IEEE 1615:2007.

The physical communication between substations and associated network apparatus will typically be via PLC (Power Line Carrier/Communication), rented or private phone lines, or private telemetry systems. Radio systems are also used, but will rarely be used where remote operation and control is critical to the safety of the system or the public.

The siting of automated equipment on the network therefore needs to take account of the availability and access to such control systems.

Figure 13 below reports a schematic of the grid components location and their communication. Please note that in this case each district is characterised by one substation and that substations are connected using link boxes. District level and domestic levels follow instead the same communication patterns reported in the previous sections (4.1 and 4.2).


43

Figure 13 - LV grid components


As for use case 2, IEC 61850 and OpenADR are identified for use in use case 3.

There are no defined standards for communication with network apparatus such as link boxes or feeder pillars. There are, however, standards relating to the monitoring of electrical power quality (IEEE 1159:1995), the environmental and testing requirements for communications networking devices (IEEE 1613:2009), and delivery time performance requirements (IEEE 1646:2004), each of which will need to be considered.


As for use case 2, the architecture can be simplified by using only one master agent at the DSO. The internal structure of the agent (i.e. subagents) is irrelevant for Mas2tering. The DSOs should be free to organize their agents as they wish: e.g. an agent per DM or per type of signal. What is important is to keep standard monitoring signals and DR signals. Work is also done to harmonize the goals of demand response programs and reduce the complexity.


44

5 Summary and Conclusion Communication requirements in Mas2tering can be classified into two categories; first, generic communication requirements which relate to communications concerning the management of the platform; and second, application-specific requirements relating communications concerning services offered by applications built on the platform. In addition, the deliverable identifies the different layers of communication in the Mas2tering platform.

This document provides a high level design of the inter-communication between agents and the agents’ communication with other smart grid components that are considered in the three Mas2tering use cases. Mas2tering communication architecture consists of a holonic organisation of the multi-agent system and addresses challenges of the smart grid such as security, scalability and distributed management.

The content of exchanged messages between agents needs to conform to a common syntax and semantics. The standard language specification FIPA-ACL is supported in the JADE framework adopted by Mas2tering. An upper ontology based on CIM is considered a candidate to facilitate data exchange and interoperability between agents and with other components. IEC 61850 supports interoperability between IEDs within substations. The document discusses the use of FIPA-ACL, CIM, IEC 61850 and other relevant standards for the message specification and communication between agents.

A communication model is described that identifies communication links between the different types of agents and the characteristics of the communication including socio-economic agents, control agents, service agents, physical agents and management agents. The model further describes protocols and other specifications that are required to facilitate the communication between agents (including communication with components outside the MAS) at different interconnection levels. Security and privacy considerations in the communication between agents and grid components including technologies and standards to be used are also analysed.

FIWARE GEs provide a range of non-domain specific support features that can be leveraged by Mas2tering platform. The GE evaluation described in the deliverable indicates that the most relevant GEs are in the area of enhancing communication security and privacy. One of the main challenges in using FIWARE GEs is that can be removed from their catalogue as in the case of Content based Security GE which has been removed during our evaluation.

The document also discusses the design of the communication and interfaces for each of the three use cases. It describes the grid hardware devices that interact with the MAS components, device and agent locations, communication needs and operational constraints. It examines the communication-related standards and technologies that need to be used or integrated in the implementation of communication components of the use case. Finally, based on the analysis of the use cases the deliverable provides guidelines on the locations of agents to identify the best locations for the MAS components in the electricity network ensuring that Mas2tering can obtain required information while not affecting the operation of the grid.

Documents

D5.1 Individual agent communication interface design final · Individual Agent Communication Interface Design 1 September 2015 1! ... FIWARE Generic Enablers (GEs) provide a range