D5.4 Executive Summary
Mas2tering is developing a multi-agent system (MAS) based ICT solution that enables flexibility management within the low-voltage part of the electricity distribution network where decentralized decision making will bring value and competitiveness. In this vision, communications and in particular agent-to-agent communication play a key role. In the core of the Mas2tering solution, there is a distributed multi-agent platform in which agents, representing different stakeholders, deployed in different locations, need to communicate with each other. Also, special attention needs to be paid to the connection of this multi-agent platform with non-agent components such as forecasting and monitoring services and Home Area Network (HAN) devices.
This deliverable documents the software communication components that were developed as part of the Mas2tering project to enable the agent communication following the design specifications previously provided in D5.3.
The first part of the deliverable documents the agent-to-agent components that are part of the global Mas2tering communication architecture. This global communication architecture is built from the integration of three main components:
· The generic JADE agent-to-agent protocols that are used in the Mas2tering solution, instantiated for protocols in the different use cases. Among these generic protocols, two protocols are extended to cover the Mas2tering needs (the Subscribe protocol to create the Publish-Subscribe protocol and the Contract Net protocol to cover the Flexibility negotiation protocols in Mas2tering).
· The secure smart control component in the Mas2tering JADE platform which adds encryption and authentication capabilities to agents (i.e. needed when agents are deployed on different machines).
· A JADE ontology generator, an Eclipse plugin that takes as an input a Web Ontology Language (OWL) and creates an Eclipse project containing a JADE-compliant ontology class and associated JADE beans.
The second part of this deliverable documents the implementation of the agent-to-agent communication protocols (i.e. instantiation of the generic ones) implemented for each use-case. This implementation includes the specification of the messages exchanged and its mapping to the Mas2tering ontology.
Finally, this deliverable documents the implementation of the communication software components needed to perform physical tests in UC1 (at the home level). These communication components include: (i) the Device agent interface with JEMMA that enables the communication between the Device agent and real devices; (ii) the connection between the Device agent and the forecasting web-services that allows the Device agent to have access to the forecast of the home and of any generation device; and (iii) the connection with the access control component that provides data access control for the Prosumer premises.
D5.4 Table of Contents
- Executive summary
- Document Information
- Table of Contents
- List of figures
- List of tables
- 1 Introduction.
- 2 Summary of the Mas2tering communication components
- 3 Global Agent Communication Architecture.
- 3.1 Agent Interaction Protocols
- 3.1.1 AchieveRE Protocol
- 3.1.2 Propose Protocol
- 3.1.3 ContractNet Protocol
- 3.1.4 Subscription Protocol
- 3.2 Integration with the secure smart control component
- 3.2.1 Secure Communication Module Integration.
- 3.2.3 Security Manager Integration.
- 3.3 A Java bean ontology generator for data model exchange generic components
- 3.4 Implementation of JADE-compliant agent-to-agent protocols
- 4 UC1 communication components
- 4.1 Agent-to-agent interaction protocols
- 4.2 ACL messages
- 4.2.1 SubscribeToDeviceFlexibilities message.
- 4.2.2 DeviceFlexibilityNotification message.
- 4.2.3 DevicePowerSchedules message.
- 4.3 Generated JADE ontology classes that support UC1 communication protocols
- 4.4 Communication components for physical tests in UC1.
- 4.4.1 Device agent interface with JEMMA..
- 4.4.2 Forecasting web services
- 4.4.3 Access control services component
- 5 UC2 communication components
- 5.1 Agent-to-agent interaction protocols
- 5.2 ACL messages
- 5.2.1 SubscribeToPPlan message.
- 5.2.2 PPlanNotification message.
- 5.3 Generated JADE ontology classes that support UC2 communication protocols
- 6 UC3 communication components
- 6.1 Agent-to-agent interaction protocols
- 6.2 ACL messages
- 6.2.1 SubscribeToDPrognosis message.
- 6.2.2 DPrognosisNotification message.
- 6.2.3 FlexRequest message.
- 6.2.4 FlexOffer message.
- 6.2.5 FlexOrder message.
- 6.3 Generated JADE ontology classes that support UC3 communication protocols
- 7 Conclusions
- Annex A Mas2tering Data Structures
Summary of the Mas2tering communication components
This section presents the different Mas2tering communications components whose implementation is documented in this deliverable. The design document D5.3 identified and designed a list of MAS communication components that needed to be developed in order to satisfy the Mas2tering requirements. Those MAS communication components were classified into two categories: (i) agent-to-agent protocols that regulate the interaction among agents; and (ii) communication components between an agent and 3rd party software that enable the interaction between one agent and some external component (i.e. a physical device or the Energy Box).
Figure 1 shows the Mas2tering MAS communication schema with the different agent-to-agent interactions arranged by their use cases. Table 1 below describes for each protocol the types of agents involved and the types of message exchanged. In the figure agents are represented by blue boxes whereas agent-to-agent communication is represented by blue lines with the identifier of the corresponding protocol(s). As detailed in previous deliverables, Mas2tering solution relies on the underlying Java Agent Development Framework (JADE) platform. JADE is an open source middleware developed by Telecom Italia Lab (TILAB) which simplifies the implementation of agents and their communication by providing a framework that supports their development and debugging. The JADE agent platform can be distributed across multiple machines, regardless of the underlying operating system. The 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 locations 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 containers, Remote Method Invocation (RMI) is used. If they are on different machines, CORBA IIOP or HTTP can be used.
Interactions among agents in JADE are regulated by protocols. These protocols standardise the interactions among agents since they provide detailed rules to be complied with by individuals involved in the interaction (e.g. one need to increment the current price of the offer in order to participate in the following round). Therefore, protocols constitute a particularly relevant coordination with regard to Mas2tering. Indeed, the Mas2tering solution complies with USEF in which interactions are well-standardized and can be directly casted as protocols.
Chapters 4, 5 and 6 of this deliverable describe the implementation of the agent-to-agent protocols for UC1, UC2 and UC3 including the definition of messages and its mapping to the Mas2tering ontology.
Figure – 1 Mas2tering communication schema with the different agent-to-agent interactions divided by use case
Table – 1 UC1, UC2, UC3 agent-to-agent protocols with the types of messages exchanged
|UC||Id||Protocol Name||Initiator||Receiver||Type messages exchanged|
|UC2||P4||InPortfolioOptimisation||AGR||CEMS||FlexRequest, FlexOffer, FlexOrder|
|UC2||P5||TradeFlexibilityForPortfolioOptimisation||AGR||AGR||FlexRequest, FlexOffer, FlexOrder|
|UC3||P7||TradeFlexibilityForCongestionManagement||DSO||AGR||FlexRequest, FlexOffer, FlexOrder|
As stated in D6.1, Mas2tering focuses on local communities (i.e. of the size of a district) supplied by a single MV/LV transformer and in this case the only congestion point coincides with the MV/LV substation that supplies the local LV grid. Therefore, all the UC3 agent-to-agent protocols that are related to publishing long term congestion points and registering connections (i.e. RegisterLongTermCongestionPoints, RegisterConnections, QueryCongestionPoints and QueryActiveAggregators) have not been implemented and hence not described in the current deliverable. Nevertheless, notice that for the sake of completeness and compliance with USEF these protocols have been defined in the design document D5.3.
Regarding communication components that need to be implemented to connect agents with non-agent based software (e.g. the Energy Box or the forecasting services), as already stated in D5.3, all of these components are included in UC1, at the home level (i.e. for UC2 and UC3 all the communication takes place among agents and hence using the JADE communication framework). Figure 2 depicts the deployment of the Mas2tering solution at TI premises highlighting the connections not only among agents but also between agents and non-agent services. Note that for UC1, the functionality of the TI Energy Box, which runs an open software component technology (JEMMA) providing a basic CEMS functionality, is enhanced by the deployment of two Mas2tering agents: the CEMS agent and the Device Agent. In addition to the UC1 agent-to-agent protocols that are listed above, the physical tests at TI premises also involve the development of the following communication components:
Figure 2 – Deployment schema of the Mas2tering communication components at TI premises
Device agent interface with JEMMA (Section 4.4.1). As depicted in Figure 2, the TI Energy Box provides standard APIs to interact with devices through the JEMMA open source software, which in turn communicates with the ZigBee wireless low power network used by HAN devices (Smart appliances and Smart meters). The Device agent can reference these services through HTTP Rest and WebSocket APIs.
Device agent interface with the Access Control Component (Section 4.4.3). As depicted in Figure 2, access control to prosumer premises will be performed by PANDA (provided by TSSG). PANDA will be used to intercept requests for data and action commands from the CEMS agent to the devices in the HAN. Therefore, an integration between the Device agent and PANDA is needed in order for the agent to verify the access control are respected for the in-home devices in presence of a CEMS petition. Although for the demonstration in the project PANDA will be executed in TSSG premises and the communication among PANDA and the Device agent will be performed through web services in a commercial version, PANDA is expected to be executed in the TI Energy Box with TSSG licensing the software for this.
Forecasting services integration with the Device agent (Section 4.4.2). As depicted in Figure 2, the Device agent will need to communicate with the Forecasting services (hosted at CU premises) in order to retrieve: (1) the house forecasted consumption for the next day (i.e. this is consumption that is not subject to any kind of flexibility) and (2) the forecasted production for any in-home production unit. This communication is performed via web-services.
Forecasting services integration with the TI historical data server (Section 4.4.2). The CU forecasting service will need to communicate with the TI cloud storage platform (where the data from each TI house has been stored by a software module called Cloud synchronization bundle) in order to collect historical data of the house (and be able to compute the forecasts requested by the Device agent). This communication is performed via web-services.
This deliverable has described a range of MAS communication components which were implemented as part of the Mas2tering project. Taking as input the design specification provided in deliverable D5.3 “Global MAS Communication Design”, this deliverable documented the implementation of the agent interaction protocols.
To this end, JADE generic interaction protocols were revised and mapped to the relevant Mas2tering protocols. In particular, the SubscribeFlexibility, SubscribePPlan and SubscribeDPrognosis protocols have been implemented as instances of a modified version of the JADE generic Subscribe protocol (i.e. the so-called Publish-Subscribe protocol). Similarly, the ProposeDevicePowerSchedules protocol has been implemented as an instantiation of the JADE generic Propose protocol. Furthermore, the deliverable implemented a generic Mas2tering 1:N negotiation flexibility protocol along with its two main roles: (i) the initiator, that starts and regulates the flexibility negotiation rounds, issuing flexibility pricing information and flexibility requests; and (ii) the participants, that communicate their expected power profiles as offers to the negotiation requests. This protocol is implemented as an instantiation of the generic JADE Contract Net protocol. The three Mas2tering negotiation-based optimisation protocols (i.e. InPortfolioOptimisation, TradeFlexibilityForPortfolioOptimisation and TradeFlexibilityForCongestionManagement) that negotiate flexibilities at different levels have been implemented as instances of this protocol. These protocols are now ready to be completed with the optimisation behaviours developed as part of deliverable D3.3 “MAS-based grid optimization and self-healing components”. Moreover, agents participating in these protocols can perform encryption and authentication as a result of the integration of the secure smart control component (developed by Cassidian CyberSecurity) with the JADE-based Mas2tering platform.
This deliverable also describes the implementation of the ACL messages exchanged for each agent interaction protocol, which are based on the Mas2tering ontology. The code generation process of these messages uses a JADE ontology generator that takes the Mas2tering OWL ontology as input and generates a JADE-compliant ontology class and associated JADE beans.
Finally, this deliverable documents the communication components that have been developed in order to cover the physical tests that will take place as part of UC1 validation (at the home level). These components are aimed at enhancing the communications of the Device agent with the Energy Box and the real devices present at the prosumer premises. In particular, communication components based on web services have been implemented in order for the Device agent to interface with:
(i) The Device Abstraction Layer (DAL) API so that it can interact with the real devices through the Energy Box.
(ii) The Access Control Component (i.e. the PANDA software provided by TSSG) to control the access to the prosumer´s premises.
(iii) The Forecasting services to retrieve the consumption and production forecasts related to the in-home devices.
In a nutshell, as a result of this deliverable, the Mas2tering platform is ready to be first, integrated with the optimisation algorithms developed as part of WP3, and later to be validated as part of WP6 activities.