3) Callia ICT

CALLIA ICT:

To fulfil the Callia objectives (link to block 1 section) the Callia project makes use of a novel multi-agent ICT architecture to:

• collect energy flexibility capabilities of energy systems and devices
• offer this flexibility as products on the market
• distribute and allocate the market clearing results to the systems and devices

Systems and devices can be flexible in their consumption or production of energy. In Callia, device agents act on behalf of their devices and manage this flexibility. Multiple devices may form clusters, controlled by a cluster manager which collects and optimizes the individual flexibilities into a strong, reliable product. They present their flexibility profile to aggregator agents. Aggregator agents in turn convert the offered flexibility into trading products to trade on flexibility markets. After the market clearing the reverse flow takes place to allocate the offered resources in the most optimal way.

At the lowest level the device agent is able to read out the state of the device and convert it into a generic flexibility representation. For each type of device, a specific device agent has to be developed, responsible for converting the device state information into a generic flexibility representation. For instance for a battery device the state of charge (SoC), battery energy capacity, battery power charging and discharging capabilities are used to model the device and its current state.

A flexibility profile is defined by one or more fundamentals. Fundamentals are actually power profile forecasts created by the device agent based upon the devices’ model and its current state. Each fundamental can be companioned by a number of samples/traces to express the uncertainty of the forecast. The number of fundamentals and accompanying samples to be provided are defined during the configuration stage. A flexibility profile is always provided on request of an agent at a higher level, being a cluster manager agent or an aggregator agent. A flexibility request can contain a target profile, which the receiver should try to match as closely as possible, or the requester can omit the target profile. In that case the receiver will provide a flexibility (baseline) profile based upon its own optimization objectives.

The cluster manager collects all the flexibility profiles provided by the device agents, aggregating them into one large profile, using a technique called ‘scenario reduction’. The scenario reduction is performed using an objective: for instance ‘provide flexibility profile(s) to the aggregator with the least uncertainty level’, or ‘try to match the target power profile mentioned in the flexibility request’. Actually, the cluster manager can also use more sophisticated objectives by combining them with for example a local objective like ‘balancing supply and demand at this level, and offering the remaining flexibility to the aggregator’.

The aggregator will perform a task similar to the cluster managers’ task but here the objective is economical. The aggregator will provide a smart bid based upon the available flexibility profiles it collected, but always with the objective to get the most profitable return.

At fixed intervals the market will clear and return the clearing results as a response to the smart bids. This is the beginning of the allocation phase. The aggregator will disaggregate the requested allocation profile and send allocation requests to all relevant cluster managers. An allocation request is always referencing a flexibility profile previously offered by the agent. The cluster manager will act the same as the aggregator for allocation requests coming from the aggregator disaggregating them into allocation requests to the device agents.

The application protocol and flexibility representation format are the same for the interaction between the device agent and the cluster manager, and between the cluster manager agent and the aggregator agent. This means the cluster manager level can be omitted or several layers of cluster managers can be added to the architecture, depending on the scale and complexity of the system.

 

Figure 2: Flex-Chain Animation

Robust, Reliable, Scalable and Secure Agent Interaction and Communication

The agents participating in the Callia flexibility trading scheme are implemented as software agents in Java or Python, respectively.

For information and data exchange, a broker-based messaging system based on Apache Kafka was developed.

• An at-least-once guarantee for message delivery is provided by the system for reliability, ensuring that each message is delivered to its recipient at least one or more times.
• Messages can be replicated and hard-drive-persisted over multiple broker instances for redundancy.
• Hard-drive-persisted messages together with configurable retention times also provide a means of system recovery, e.g. crashed agents have the possibility to restore their internal state after a system failure by reprocessing old messages.
• In terms of security, TLS-secured connections are used between agents and brokers. Additionally, access control lists (ACLs) specifying access rights (read, write) can be configured.

For efficiency of data transfers, Apache Avro has been used for serializing and deserializing application level messages into highly compact binary representations.

In order to further increase robustness and scalability in real-life systems it was decided to allow the deployment of separate message brokers at the border between two vertically neighboured layers of the system architecture for upstream and downstream data exchanges between corresponding agents. This is especially important for large-scale deployments where potentially thousands or more agents at each layer and from multiple geographical regions participate in flexibility trading.

The deployment of the messaging brokers and the connections between agents and the brokers within the Callia system architecture is shown in Figure 2. In Callia each logical connection between two agents only requires at most two queues for incoming messages. One queue for all messages incoming from bottom-up (upstream), one queue for messages incoming from top-down (downstream).

An API for inter-agent data transfers for flexibility trading was developed. This allows agent developers to focus on developing agent logic without the need to know specifics regarding messaging details. The complexity of the underlying communication system can almost be completely hidden from agent application developers as only two lines of code are necessary to send or receive messages (configuration loading and a send or receive command).

Regarding performance and scalability initial measurements have resulted in latency values in the 10-millisecond range, sub-second failover times in case of server failures, and the ability of a single broker system to support thousands of agents.

More information is available in the paper ‘An Agent-based Flexibility Trading Architecture with Scalable and Robust Messaging’, F. von Tüllenburg, G. Panholzer, J. L. Du, A. Soares, F. Spiessens, D. Geysen, D. Ectors, IEEE SmartGridComm 2017.