An Interoperable Approach for Energy Systems Simulation: Electricity Market Participation Ontologies

: Electricity markets are complex environments with very particular characteristics. Some of the main ones for this complexity are the need for an adequate integration of renewable energy sources and the electricity markets’ restructuring process. The growth of simulation tool usage is driven by the need to understand those mechanisms and how the involved players’ interactions affect the markets’ outcomes. Several modelling tools directed to the study of restructured wholesale electricity markets have emerged. Although, they share a common limitation: the lack of interoperability between the various systems to allow the exchange of information and knowledge, to test different market models and to allow players from different systems to interact in common market environments. This paper proposes the use of ontologies for semantic interoperability between multi-agent platforms in the scope of electricity markets simulation. The achieved results allow the identiﬁcation of the added value gained by using the proposed ontologies. They facilitate the integration of independent multi-agent simulators, by providing a way for communications to be understood by heterogeneous agents from different systems.


Introduction
Electricity markets (EMs) worldwide are becoming extremely complex and dynamic.The main drivers for this evolution are the EMs' restructuring and evolution into regional and continental scale markets, along with the constant changes brought about by the increasing necessity for an adequate integration of renewable energy sources [1,2].
The European approach is a reference case of this evolution.The majority of European countries have joined into a regional day-ahead coupled European EM composed of several countries [3,4].The Multi-Regional Coupling algorithm which integrates the various European EMs in a pan-European market is called EUPHEMIA [5]; it has been developed by the Price Coupling of Regions (PCR) project [6].Seven European market operators have developed together the procedures; redundant decentralized, but interlinked, IT systems; a single algorithm that calculates electricity prices; net import and export positions; and cross border electricity flows in a single run.Although several coupling initiatives have been done, significant work remains to be done [3].The Cross-Border Intraday market integration is a still in progress roadmap, which aims to implement an Intraday target model ("an evolution of continuous intraday trading, to include intraday capacity recalculation, capacity pricing reflecting congestion and the capability to trade sophisticated products") on all EU borders [7,8].
Other examples of the transformation of national EMs into Regional and Continental EMs are in the U.S., like the California Independent System Operator (CAISO) [9] and the Midcontinent Independent System Operator (MISO) [10].Brazil is another example of such, since all regions are integrated in a joint EM [11].These markets can be considered continental EMs due to these countries' size.Due to the continuous evolution of the EM environment and its participating entities, it becomes crucial for professionals in this area to rethink their behavior and market strategies.Market players are very interested in foreseeing the market's behavior and understanding its operation in order to maximize their profits, while regulators need to test rules before implementing them to detect and avoid market inefficiencies [12].Thus, EM became an attractive domain for software developers [13][14][15][16][17][18][19].
To study and better understand these liberalized markets, the need for simulation tools has increased.EM simulators must be flexible in order to handle this complex and evolving reality, providing players with proper tools to adapt to this dynamic reality and learn from experience.Various studies support the idea that multi-agent systems (MASs), with suitable simulation capabilities, are appropriate for the simulation of EM, given the complex interactions of the involved players [15,16,20].A MAS is not necessarily a simulation platform, but simulations may take advantage of this distributed system's characteristics, namely in the study of EMs, where each player has its own goals and beliefs and competes or collaborates with other players, and interacts with the respective operators.This is of crucial importance for the entities involved in EMs, concerning, namely, scenario comparison, market evolution studies and sensitivity analysis.There are some relevant tools that support the adequacy of these kind of tools, such as Agent-based Modelling of Electricity Systems (AMES) [15]; Electricity Market Complex Adaptive System (EMCAS) [16]; and Multi-Agent Simulator of Competitive Electricity Markets (MASCEM) [13,14,21], amongst several others.MASCEM is a modelling and simulation tool that allows the study of the restructured and complex EM.It provides players with a competitive advantage in the market by providing simulation and decision-support capabilities.Since market players are complex entities with particular characteristics and objectives, making their decisions and interacting with other players, a multi-agent architecture is used.Experimental results demonstrate a cohesive market behavior from the simulated environment [14,22].
Current EM multi-agent tools are focused on the study of distinct market models and mechanisms, and on the analysis of the relationships between the different market's entities.Still, they do not enable the interoperability with heterogeneous MASs of the same scope.EM agent-based platforms could gain significant added value by sharing their knowledge and market models with other agent societies.Such tools would provide the means for an actual improvement in current EM studies and development.The need to integrate different market models and platforms brings out the needs for communication capabilities which enable heterogeneous entities (such as software agents) to understand each other and cooperate/compete toward their goals.Ontologies allow agent-based systems to coexist and collaborate [23] by representing concepts and defining a common "language" that can be interpreted and understood by any software agent [24].
The main contribution of this paper is the development of two ontology modules, namely: the (i) Call for Proposal (CFP) ontology; and the (ii) Electricity Markets Results (EMR) ontology, for the inter-agent communication between heterogeneous EM agent-based simulators.The use of languages shared by distinct systems eases the communication and cooperation between them, enabling simulators, such as MASCEM, to integrate several new EM models, allowing broader study ability in this field.The integration of the diverse models and systems is achieved by the use of the proposed ontologies, as communication languages between the heterogeneous agent-based platforms, instead of by means of a specific computational model.With the use of a common communication language, software agents from different systems are able to participate in other systems' simulations, using their computational models that, until now, were only available to entities of the same system.
After this introductory section, Section 2 presents an overview of the most relevant work concerning agent-based EM simulation.Section 3 introduces the CFP and EMR ontologies, their concepts and axioms.In Section 4, a case study is presented, in which the ontologies are tested and demonstrated.Finally, Section 5 features the most relevant conclusions.

Related Work
Due to their restructuring, EMs pose several challenges to governments and companies involved in the areas of generation, transmission and distribution of electrical energy.Dealing with these challenges has led to an increase in the competitiveness of the sector, causing relevant changes and new difficulties and matters to be solved, such as the market operation rules, physical constraints of power systems and financial issues [12].As a result of the constant evolution of the EM environment, and the inclusion and change in the operation and players' participation in the market, it became imperative for professionals in the area to entirely understand the markets' principles and how to evaluate their investment under such a competitive environment [12,25].

Agent Based Electricity Market Simulation
Multi-agent-based simulators are particularly well suited for the analysis of complex interactions in dynamic and complex systems such as EMs [15,16,20,26].Simulators in this area must be able to deal with the dynamics and fast evolution of EMs and adopt the new models and constraints of the market, providing players with adequate tools to adapt to the changing environment.Some of the main advantages that multi-agent approaches provide are the facilitated inclusion of new models, market mechanisms, player types, and different types of interactions [21].
Indeed, there are some reference tools that have already demonstrated the usefulness of this kind of approach in this context.AMES [15] is an open-source computational laboratory for the experimental study of wholesale power markets, restructured in accordance with the U.S. Federal Energy Regulatory Commission's (FERC) market design.EMCAS [16] applies an agent-based approach where the agents' strategies are based on learning and adaptation to simulate the operation of complex power systems.The Genoa Artificial Power Exchange (GAPEX) [17] is an agent-based framework for modelling and simulating power exchanges.Power Web [27] is a Web-based market simulator, allowing the interaction of participants from different zones of the world.The Simulator for Electric Power Industry Agents (SEPIA) [28] is a simulator oriented for Microsoft Windows platforms and is based on a Plug and Play architecture.The Short/Medium Run Electricity Market Simulator (SREMS) [20] is a game theory-based simulator capable of supporting scenario analysis in the short/medium term and, in some situations, to evaluate the market power.
Although several works have proved the applicability of multi-agent simulation tools to study EMs, they have a common limitation: the lack of interoperability to allow the exchange of information and knowledge, to test different market models, and to allow market players from different systems to interact in common market environments.Current tools are focused in the study of different EM mechanisms and the analysis of relationships between market entities, but they do not enable the interoperability with external systems.
These limitations point out the need for the interconnection between agent-based simulators in the scope of EMs.These simulators could gain significant added value by sharing their knowledge and market models with other agent societies.Such tools would provide the means for an actual improvement in current EM studies and development.
MASCEM [13,21,29] is being improved with the goal of overcoming these challenges and overtake the limitations presented by the mentioned simulators.

MASCEM Overview
MASCEM [13,21,29] is a modelling and simulation tool which has been developed with the aim of studying the operation of complex and competitive restructured EM.It models the main complex and dynamic market entities and their interactions.Support for players' decisions in accordance with their characteristics and goals, medium/long-term gathering of data and experience is also considered. Figure 1 illustrates MASCEM's main features.MASCEM aims to simulate as many market models, players and operators as possible in order to emulate the real EM operation, allowing it, therefore, to be used as a decision support tool for short/medium-term purposes and also for long-term decisions, such as the ones taken by market regulators.
Since its first version appeared in 2003, MASCEM has come to accommodate the modelling of a huge number of different players and market types [21].However, with the several updates, the multi-agent environment has become overly complex, and this has uncovered much fragility in the old dated architecture and on the agents' development platform (OAA [30]), which has started to become barely capable of supporting the evolution of the system.For this reason, a complete restructuring has become fundamental, including the re-definition of the multi-agent model, the system's implementation architecture, and the use of proper mechanisms to deal with the highly demanding execution time requirements [29].
MASCEM's restructuring took into consideration the system's compliance with the Foundation for Intelligent Physical Agents (FIPA) [31] standards, which facilitates the interoperability with external agent-based platforms.
In order to cope with the FIPA's standards, the MASCEM development framework has been changed from OAA to the Java Agent Development framework (JADE) [32], an open source platform for the development of peer-to-peer agent based applications.It simplifies the implementation of agent-based applications by supporting and complying with the FIPA's specifications, through a middle-ware, and also by providing a set of graphical tools to support both debugging and deployment.

Multi-Agent Model
With MASCEM's restructuring, its multi-agent model has been significantly simplified, by organizing the simulation of aggregations and smart grids (SG) as a new MAS, like Multi-Agent Smart Grid Simulation Platform (MASGriP) [33,34].Besides some JADE-specific agents, such as the Agent Management System (AMS) for platform management actions, the Directory Facilitator (DF) for yellow pages' services, and the Remote Monitoring Agent (RMA) for the user interface, among other useful tool agents, MASCEM's actual version only includes five types of agents [29]:


Main Agent, which, among others, enables the user's interaction with the system and distributes the agents by the available machines, considering its features and the agents' processing needs;  Management Information Base (MIB) Agent that is responsible for reading the management information base of each machine (using SNMP-Simple Network Management Protocol), creating a report and sending it to the Main Agent so that it can decide which agents will move to each machine; MASCEM aims to simulate as many market models, players and operators as possible in order to emulate the real EM operation, allowing it, therefore, to be used as a decision support tool for short/medium-term purposes and also for long-term decisions, such as the ones taken by market regulators.
Since its first version appeared in 2003, MASCEM has come to accommodate the modelling of a huge number of different players and market types [21].However, with the several updates, the multi-agent environment has become overly complex, and this has uncovered much fragility in the old dated architecture and on the agents' development platform (OAA [30]), which has started to become barely capable of supporting the evolution of the system.For this reason, a complete restructuring has become fundamental, including the re-definition of the multi-agent model, the system's implementation architecture, and the use of proper mechanisms to deal with the highly demanding execution time requirements [29].
MASCEM's restructuring took into consideration the system's compliance with the Foundation for Intelligent Physical Agents (FIPA) [31] standards, which facilitates the interoperability with external agent-based platforms.
In order to cope with the FIPA's standards, the MASCEM development framework has been changed from OAA to the Java Agent Development framework (JADE) [32], an open source platform for the development of peer-to-peer agent based applications.It simplifies the implementation of agent-based applications by supporting and complying with the FIPA's specifications, through a middle-ware, and also by providing a set of graphical tools to support both debugging and deployment.

Multi-Agent Model
With MASCEM's restructuring, its multi-agent model has been significantly simplified, by organizing the simulation of aggregations and smart grids (SG) as a new MAS, like Multi-Agent Smart Grid Simulation Platform (MASGriP) [33,34].Besides some JADE-specific agents, such as the Agent Management System (AMS) for platform management actions, the Directory Facilitator (DF) for yellow pages' services, and the Remote Monitoring Agent (RMA) for the user interface, among other useful tool agents, MASCEM's actual version only includes five types of agents [29]:

•
Main Agent, which, among others, enables the user's interaction with the system and distributes the agents by the available machines, considering its features and the agents' processing needs; • Management Information Base (MIB) Agent that is responsible for reading the management information base of each machine (using SNMP-Simple Network Management Protocol), creating a report and sending it to the Main Agent so that it can decide which agents will move to each machine; • Market Operator, which regulates the pool negotiations by validating and analysing the players' bids, according to the type of negotiation; establishes the market price, the accepted and refused bids, and the economical dispatch that will be sent to the system operator; • System Operator that is responsible for the technical feasibility from the power system point of view and solves congestion problems that may arise.It is responsible for the system's security and stability; • Player, which represents the buyer, seller or aggregations of agents.It may be a consumer or distribution company participating in the EM to buy a certain amount of energy; or a producer, or other entity, able to sell energy in the market; or even entities that sometimes need to buy, and other times to sell energy, like aggregators, such as microgrids and smart grids.


Market Operator, which regulates the pool negotiations by validating and analysing the players' bids, according to the type of negotiation; establishes the market price, the accepted and refused bids, and the economical dispatch that will be sent to the system operator;  System Operator that is responsible for the technical feasibility from the power system point of view and solves congestion problems that may arise.It is responsible for the system's security and stability;  Player, which represents the buyer, seller or aggregations of agents.It may be a consumer or distribution company participating in the EM to buy a certain amount of energy; or a producer, or other entity, able to sell energy in the market; or even entities that sometimes need to buy, and other times to sell energy, like aggregators, such as microgrids and smart grids.Buyers, Sellers and Aggregators depicted in Figure 2 are seen as player agents from the market's point of view.
The collaboration between different MASs provides the means to achieve more complex and advanced simulation studies.The core simulation environment provided by MASCEM can be extended by the integration of complementary multi-agent simulators, such as MASGriP [29].
MASCEM allows the simulation of several market types: day-ahead and intraday pools (asymmetric or symmetric, with or without complex conditions), bilateral contracts, and forward markets.It also enables the simulation of hybrid markets by selecting a combination of the available market models.Other systems may also provide new market types for simulation, such as MASGriP.
MASCEM's players are also able to participate in SG negotiations through MASGriP.The collaboration between the agents' communities is achieved through the use of ontologies, which define the main concepts that must be understood by agents to participate in power systems and EM related simulations [29].

Ontologies for Semantic Interoperability
A MAS, using the FIPA's standards, should be able to interoperate.However, it does not mean that agents are able to exchange any useful information due to the use of different languages and vocabularies, specific to each development platform, domain and developer team [29].Thus, it is also required that they Buyers, Sellers and Aggregators depicted in Figure 2 are seen as player agents from the market's point of view.
The collaboration between different MASs provides the means to achieve more complex and advanced simulation studies.The core simulation environment provided by MASCEM can be extended by the integration of complementary multi-agent simulators, such as MASGriP [29].
MASCEM allows the simulation of several market types: day-ahead and intraday pools (asymmetric or symmetric, with or without complex conditions), bilateral contracts, and forward markets.It also enables the simulation of hybrid markets by selecting a combination of the available market models.Other systems may also provide new market types for simulation, such as MASGriP.
MASCEM's players are also able to participate in SG negotiations through MASGriP.The collaboration between the agents' communities is achieved through the use of ontologies, which define the main concepts that must be understood by agents to participate in power systems and EM related simulations [29].

Ontologies for Semantic Interoperability
A MAS, using the FIPA's standards, should be able to interoperate.However, it does not mean that agents are able to exchange any useful information due to the use of different languages and vocabularies, specific to each development platform, domain and developer team [29].Thus, it is also required that they share a common vocabulary and semantics, so the messages and their contents may be understandable by the agents of each agent society.Ontologies are used to this end, enabling the standardization of communications and interpretation of concepts between independent systems [21,29].
Currently, MASs in the Power Systems' domain are developed with their own private ontologies.These tools share common concepts, differently represented between the ontologies; and translating them automatically is not as straightforward as it seems.To solve this problem, the FIPA proposes the use of an Ontology Agent that supplies some related services [35].It still is an experimental standard and mappings between ontologies still must be performed by ontologies' designers, which increase the human effort required and the costs of implementation.
Alternatively, the use of an upper ontology representing the general concepts of the domain, ensuring a common basis for the representation of those concepts and their relations between systems, while reducing the complexity of ontology mapping, is proposed in [36].The Electricity Markets Ontology (EMO) has been proposed for the interoperability of EM multi-agent simulators, which can be extended in a way that enables the full interoperability between those systems [37].It incorporates abstract concepts and axioms referring to the main existing EM, with the aim of being as inclusive as possible in order to be extended and reused in the development of market specific ontologies.In order to facilitate its reuse and extension independently of the market's features and/or rules, the EMO was kept as simple as possible.However, some markets' constraints were also defined, given that the suggested ontologies were developed considering its use by agent based simulation tools.More details about EMO can be found in [37].
EMO is publicly available [38] in order to be used by third-party developers who wish to integrate their agent-based simulators with MASCEM, taking advantage of its simulation capabilities and market models.It may also be reused and extended for the development of new multi-agent simulation tools in the context of wholesale EM.
Two additional modules have been developed separately from EMO to enable semantic communications between the market operator and player agents: (i) the Call for Proposal (CFP) ontology and (ii) the Electricity Markets Results (EMR) ontology.While EMO defines the main concepts and axioms of EM, the CFP and EMR ontologies define Requests, Responses and Informs, enabling a semantic interaction between the participating agents.Section 3 presents, in detail, both ontology modules.

Ontologies for Semantic Communications
The increasing application of multi-agent technology within power engineering promotes the adoption of standards that enable the communication between heterogeneous systems, bringing future advantages [36].There is a growing need for knowledge exchange between these systems in order to take full advantage of their functionalities [39].
A requirement for systems' interoperability is usually to reuse existing ontologies.There are some libraries of reusable ontologies available online, such as Ontolingua [40] and DAML (The DARPA Agent Markup Language) [41] libraries.Some ontologies developed in the field of energy markets, such as electricity and natural gas, can be found in the literature [42][43][44].The ontology developed in [42] focuses on the Greek EM, not having been extended to any other European EM.A very extensive and interesting work has been developed, although the authors decided to consider only the domain of the ontology, leaving aside its application scenario.Given the extension and accuracy of the knowledge already represented, its reuse would be considered if the ontology was publicly available.However, the ELMO ontology [42], as it is, is not appropriate for EM multi-agent simulators [45] since it was not designed bearing in mind its application but only the representation of its domain.Unfortunately, none of these ontologies is publicly available for reuse and/or extension, which led to the development of the proposed ontologies from scratch.

Call for Proposals Ontology
The Call for Proposals (CFP) ontology has the purpose of being used by market operator and player agents to start bids submission and their specification.It is publicly available [46]; and it imports EMO and extends it by including two new classes, namely the CallforProposal and the Proposal; and a new object property: forElectricityMarket. Figure 3 shows the classes and object properties defined in CFP.
and a new object property: for Electricity Market.Figure 3 shows the classes and object properties defined in CFP.On the left side of Figure 3 (in yellow), the added classes are surrounded in red.On the right side (in blue), the new object property is also surrounded with a red ellipse.Figure 4 illustrates the relations between concepts of the CFP and EMO ontologies.The class imported from EMO is represented in yellow, while the object properties are represented in blue.For a better understanding about the EMO, please refer to [37].
The CallforProposal class is used by the market operator agent to inform Player agents that a given negotiation is about to start and they should submit their proposals if they wish to participate.In response to the call for proposal (CfP), market players, interested in participating in the market, send a Proposal to the market operator with their own bids and constraints, if any.
A CfP is sent for each market session, and each Proposal is an answer to a specific CfP session.For the CallforProposal the market operator defines its name; the Market's name; the Market Type's id and name; and the Session's id, number, date, number of periods (numberOfPeriods) and the maximum number of fractions (Offers) allowed in each Bid for the simulation (maxNumberOfFractions).In turn, the players answer with the Session's Periods, including the respective Bids and Offers in the Proposal.
The CFP ontology has expressivity ALCHIQ (D).The greater the number and variety of concepts that an ontology may represent, the greater is its expressiveness.The Attributive Language (AL) is the base language allowing (i) Atomic negation, i.e., the negation of concept names that do not appear on the left side of axioms; (ii) Concept intersection; (iii) Universal restrictions; and (iv) limited existential quantification.C is the complex concept negation extension.The H extension is related with the role Hierarchy On the left side of Figure 3 (in yellow), the added classes are surrounded in red.On the right side (in blue), the new object property is also surrounded with a red ellipse.Figure 4 illustrates the relations between concepts of the CFP and EMO ontologies.and a new object property: for Electricity Market.Figure 3 shows the classes and object properties defined in CFP.On the left side of Figure 3 (in yellow), the added classes are surrounded in red.On the right side (in blue), the new object property is also surrounded with a red ellipse.Figure 4 illustrates the relations between concepts of the CFP and EMO ontologies.The class imported from EMO is represented in yellow, while the object properties are represented in blue.For a better understanding about the EMO, please refer to [37].
The CallforProposal class is used by the market operator agent to inform Player agents that a given negotiation is about to start and they should submit their proposals if they wish to participate.In response to the call for proposal (CfP), market players, interested in participating in the market, send a Proposal to the market operator with their own bids and constraints, if any.
A CfP is sent for each market session, and each Proposal is an answer to a specific CfP session.For the CallforProposal the market operator defines its name; the Market's name; the Market Type's id and name; and the Session's id, number, date, number of periods (numberOfPeriods) and the maximum number of fractions (Offers) allowed in each Bid for the simulation (maxNumberOfFractions).In turn, the players answer with the Session's Periods, including the respective Bids and Offers in the Proposal.
The CFP ontology has expressivity ALCHIQ (D).The greater the number and variety of concepts that an ontology may represent, the greater is its expressiveness.The Attributive Language (AL) is the base language allowing (i) Atomic negation, i.e., the negation of concept names that do not appear on the left side of axioms; (ii) Concept intersection; (iii) Universal restrictions; and (iv) limited existential quantification.C is the complex concept negation extension.The H extension is related with the role Hierarchy The class imported from EMO is represented in yellow, while the object properties are represented in blue.For a better understanding about the EMO, please refer to [37].
The CallforProposal class is used by the market operator agent to inform Player agents that a given negotiation is about to start and they should submit their proposals if they wish to participate.In response to the call for proposal (CfP), market players, interested in participating in the market, send a Proposal to the market operator with their own bids and constraints, if any.
A CfP is sent for each market session, and each Proposal is an answer to a specific CfP session.For the CallforProposal the market operator defines its name; the Market's name; the Market Type's id and name; and the Session's id, number, date, number of periods (numberOfPeriods) and the maximum number of fractions (Offers) allowed in each Bid for the simulation (maxNumberOfFractions).In turn, the players answer with the Session's Periods, including the respective Bids and Offers in the Proposal.
The CFP ontology has expressivity ALCHIQ (D).The greater the number and variety of concepts that an ontology may represent, the greater is its expressiveness.The Attributive Language (AL) is the base language allowing (i) Atomic negation, i.e., the negation of concept names that do not appear on the left side of axioms; (ii) Concept intersection; (iii) Universal restrictions; and (iv) limited existential quantification.C is the complex concept negation extension.The H extension is related with the role Hierarchy (e.g., the sub properties).The I extension represents the Inverse properties.The Q extension are the Qualified cardinality restrictions, i.e., cardinality restrictions with fillers other than .Finally, the (D) refers to the use of datatype properties, data values or data types.
The Description Logics (DL) syntax [47] of the CFP ontology is defined in Table 1 (object property) and Table 2 (classes).DL are logics serving primarily for formal description of concepts and roles (relations).They are used to describe and reason about the relevant concepts of an application domain [48].The CallforProposal identifies the EM for which it is sent.In the same way, the Proposal includes the EM to which it responds to.EMO:Market or any of its subclass markets are accepted.
Both classes (CallforProposal and Proposal) make use of the same Functional (a functional property is a property that only relates the same subject to one single object/value) object property to relate the classes to the respective market, i.e., fromElectricityMarket.
The CallforProposal, the Proposal, the EMO:Area, the EMO:Operator, the EMO:Period, the EMO:Power, the EMO:Price, the EMO:Offer, the EMO:Player, the EMO:Bid, the EMO:Session, the EMO:Market, the EMO:MarketType and the EMO:BilateralContract classes are all Disjoint Classes, meaning that none of these classes has common members.In other words, an element cannot be an instance of more than one of these classes, or else it makes the ontology inconsistent.

Electricity Markets Results Ontology
The Electricity Markets Results (EMR) ontology has been developed considering the output data each market provides for its participants.Given the similarity of the several EM results, it has been decided to gather this knowledge into a single common ontology.It is also publicly available [49].
The EMR ontology imports EMO and includes seven new concepts (BidResult, BlockResult, FlexibleResult, HourlyResult, PlayerResult, TradedPower and MarketPrice); three new object properties (fromPlayer, fromSession and gotResult); and six data properties (blockId, flexibleId, hourlyId, periodNumber, removalJustification and removed).These concepts and properties are surrounded with red ellipses in Figure 5. Figure 6 illustrates the concepts and properties of EMR and its relation to the EMO ontology.Observing Figure 6, the objects imported from EMO are visible in yellow, while the object properties are represented in blue.The data properties are identified within each class and the prefix "EMO:" identifies EMO's imports.This ontology is used by the market operators to inform the players about their outcome in the market.Each PlayerResult corresponds to a player and identifies the several BidResults of that player.For each submitted Bid there is a corresponding BidResult, and the result depends on the type of the presented bid.TradedPower and MarketPrice identify the amount of power traded by the player and the market's clearing price respectively.Figure 6 illustrates the concepts and properties of EMR and its relation to the EMO ontology.Observing Figure 6, the objects imported from EMO are visible in yellow, while the object properties are represented in blue.The data properties are identified within each class and the prefix "EMO": identifies EMO's imports.Figure 6 illustrates the concepts and properties of EMR and its relation to the EMO ontology.Observing Figure 6, the objects imported from EMO are visible in yellow, while the object properties are represented in blue.The data properties are identified within each class and the prefix "EMO:" identifies EMO's imports.This ontology is used by the market operators to inform the players about their outcome in the market.Each PlayerResult corresponds to a player and identifies the several BidResults of that player.For each submitted Bid there is a corresponding BidResult, and the result depends on the type of the presented bid.TradedPower and MarketPrice identify the amount of power traded by the player and the market's clearing price respectively.This ontology is used by the market operators to inform the players about their outcome in the market.Each PlayerResult corresponds to a player and identifies the several BidResults of that player.For each submitted Bid there is a corresponding BidResult, and the result depends on the type of the presented bid.TradedPower and MarketPrice identify the amount of power traded by the player and the market's clearing price respectively.
The EMR ontology has expressivity ALCHIQ (D) and its DL syntax in demonstrated in Tables 3-5, presenting its object properties, data properties and classes, respectively.TradedPower is a subclass of EMO:Power, inheriting its EMO:unit and EMO:value data properties.In the same way, the MarketPrice is a subclass of EMO:Price.
A BidResult includes a TradedPower and a MarketPrice, making use of the object properties EMO:hasPower and EMO:hasPrice, respectively.
As mentioned above a BlockResult, a HourlyResult and a FlexibleResult are subclasses of BidResult.The BlockResult and HourlyResult are defined by an id (blockId and hourlyId respectively), a periodNumber, a removalJustification and a removed data property with range "yes" and "no".Both blockId and removed data properties are Functional.The FlexibleResult, in turn, is only defined by a flexibleId and a removed data property.
A PlayerResult includes the removed and the removalJustification data properties, the respective EMO:Player, the considered EMO:Session and the corresponding BidResults.The EMO:Player is set by the object property fromPlayer, the EMO:Session is set by the object property fromSession and the BidResults by the object property gotResult.The three object properties are Functional.
Finally, the BidResult, the PlayerResult, the EMO:Area, the EMO:Operator, the EMO:Period, the EMO:Power, the EMO:Price, the EMO:Offer, the EMO:Player, the EMO:Bid, the EMO:Session, the EMO:Market, the EMO:MarketType and the EMO:BilateralContract classes are all Disjoint Classes.
The specification of CFP and EMR ontologies supports the interoperability between agents from different MAS tools interacting in the same market environment.Section 4 will present a case study that illustrates how this can be achieved in a real and challenging Iberian market context.

Case Study
This case study aims to demonstrate the applicability and advantages of using the proposed ontologies for the interoperability between MASs in the EM domain.For this, the interaction between MASCEM and MASGriP is addressed.The case study is focused on the Iberian electricity market (MIBEL), which is composed by Portugal and regions of Spain, including offers from all players of the day-ahead market concerning the 1 January 2012.It is based on real data extracted from MIBEL's market operator (Operador del Mercado Ibérico de Energía-OMIE) website [50] and regards 826 distinct players, from which 714 are sellers and the remaining 112 are buyers.Among the sellers, 397 have wind power generation in their portfolio mix.A windy day was chosen with the wind reaching very high speeds, which leads to a much greater production offer than the demand.
For the analysis of this case study, special focus is given to the SG 821 agent, as it represents a Smart Grid, simulated by MASGriP, with wind based generation.In the first scenario, SG 821 participates in the day-ahead market with 75% of its total production, reserving the remaining 25% to participate in the first session of MIBEL's intraday market.

Day-Ahead Market Simulation
From the point of view of the market operator, SG 821 is a common player of MASCEM.The communications exchanged by these two agents are similar to those exchanged between the market operator and any other player from MASCEM. Figure 7 features the call for proposal sent by MASCEM's market operator to all registered players.It is represented in RDF (Resource Description Framework), a standard model for data interchange on the Web, respecting a formal semantics.After receiving the call for proposal sent by MASCEM's market operator for the daily market, player SG 821 gathers all the needed information from its aggregated players, in order to define the bid to submit in the market.Figure 8 presents a snippet of the proposal sent by SG 821 to the OMIE market operator.A full representation of the proposal is available online [51].After receiving the call for proposal sent by MASCEM's market operator for the daily market, player SG 821 gathers all the needed information from its aggregated players, in order to define the bid to submit in the market.Figure 8 presents a snippet of the proposal sent by SG 821 to the OMIE market operator.A full representation of the proposal is available online [51].After receiving all the proposals or after finishing the available time for the reception of bids, the market operator validates the proposals and executes the session of the daily market.At the end of the market simulation, market results are converted into RDF and sent to the respective players.The RDF that contains the market results of SG 821 is shown in Figure 9.The full RDF results of SG 821 are available online [52].After receiving all the proposals or after finishing the available time for the reception of bids, the market operator validates the proposals and executes the session of the daily market.At the end of the market simulation, market results are converted into RDF and sent to the respective players.The RDF that contains the market results of SG 821 is shown in Figure 9.The full RDF results of SG 821 are available online [52].By analyzing the last lines of the RDF excerpt from Figure 9, it is possible to see the definition of the traded power for period 11 with an approximate value of 976.65 and unit MW (between lines 29 and 33).The results of player SG 821 in the day-ahead market can also be visualized graphically, as in Figure 10.By analyzing the last lines of the RDF excerpt from Figure 9, it is possible to see the definition of the traded power for period 11 with an approximate value of 976.65 and unit MW (between lines 29 and 33).The results of player SG 821 in the day-ahead market can also be visualized graphically, as in Figure 10.Analyzing the results of SG 821 from Figure 10, it is visible that all of the energy available for sale in the market has been negotiated.As the player's production is wind based, he has offered a price of 0 €/MWh in each period, in order to dispatch all of the available generation.
Making use of MASCEM's public ontology, MASGriP players have the opportunity to participate in the simulations of the wholesale EM of MASCEM.The publicly available ontology of MASCEM allows players from any MAS, or individual agents, to participate in its simulations as any MASCEM own agent.Therefore, through MASCEM's ontology, the interoperability between MASCEM and agents from external systems, willing to participate in the simulations of EM as a market player, is enabled.

Intraday Market Simulation
Once the day-ahead market negotiations finish, each player reviews its results and decides whether it will participate or not in the intraday market, in order to meet the required adjustments of the feasible daily program and of the last scheduling.Agents who have not sold all their energy in the daily market, or players that have to make adjustments in their sale/purchase needs because of differences from the day-ahead to the (near) real time forecasts, and/or players that kept power strategically to negotiate later (such as SG 821), will participate in the intraday market.Therefore, in the second scenario of this case study, only 307 agents participate in the intraday market.From these, 269 are sellers and the remaining 38 are buyer agents.To easily interpret the results of this scenario, only the first session of the intraday market is considered (from the six established in MIBEL).
The intraday market starts with the call for proposal sent by the market operator to the market players.Figure 11 shows the call for proposal received by SG 821 for the first session of the intraday market.
By analyzing Figure 11 it is possible to see the definition of a call for proposal for the electricity market MIBEL (from line 27 to 31), with market type INTRADAY (between lines 16 and 22), operated by the market operator OMIE (line 40 to line 43), concerning the first session (session's "number" equals to 0 in line 36) of the intraday market (from line 32 to line 39), considering 27 hourly periods (the 24 hourly periods of the following day: 1 January, 2012, and the last three periods of the current day: 31 December, 2011 [53], see line 35).Since this study concerns the day of 1 January, 2012, the player does not make any offer for the three first periods of this intraday session.Analyzing the results of SG 821 from Figure 10, it is visible that all of the energy available for sale in the market has been negotiated.As the player's production is wind based, he has offered a price of 0 €/MWh in each period, in order to dispatch all of the available generation.
Making use of MASCEM's public ontology, MASGriP players have the opportunity to participate in the simulations of the wholesale EM of MASCEM.The publicly available ontology of MASCEM allows players from any MAS, or individual agents, to participate in its simulations as any MASCEM own agent.Therefore, through MASCEM's ontology, the interoperability between MASCEM and agents from external systems, willing to participate in the simulations of EM as a market player, is enabled.

Intraday Market Simulation
Once the day-ahead market negotiations finish, each player reviews its results and decides whether it will participate or not in the intraday market, in order to meet the required adjustments of the feasible daily program and of the last scheduling.Agents who have not sold all their energy in the daily market, or players that have to make adjustments in their sale/purchase needs because of differences from the day-ahead to the (near) real time forecasts, and/or players that kept power strategically to negotiate later (such as SG 821), will participate in the intraday market.Therefore, in the second scenario of this case study, only 307 agents participate in the intraday market.From these, 269 are sellers and the remaining 38 are buyer agents.To easily interpret the results of this scenario, only the first session of the intraday market is considered (from the six established in MIBEL).
The intraday market starts with the call for proposal sent by the market operator to the market players.Figure 11 shows the call for proposal received by SG 821 for the first session of the intraday market.
By analyzing Figure 11 it is possible to see the definition of a call for proposal for the electricity market MIBEL (from line 27 to 31), with market type INTRADAY (between lines 16 and 22), operated by the market operator OMIE (line 40 to line 43), concerning the first session (session's "number" equals to 0 in line 36) of the intraday market (from line 32 to line 39), considering 27 hourly periods (the 24 hourly periods of the following day: 1 January 2012, and the last three periods of the current day: 31 December 2011 [53], see line 35).Since this study concerns the day of 1 January 2012, the player does not make any offer for the three first periods of this intraday session.After completing the proposal definition, player SG 821 sends it to the market operator, MIBEL.An excerpt from the proposal sent by the player is shown in Figure 12.A full version of this player's proposal is available online [54].After completing the proposal definition, player SG 821 sends it to the market operator, MIBEL.An excerpt from the proposal sent by the player is shown in Figure 12.A full version of this player's proposal is available online [54].For the intraday market, SG 821 considers the reserve of 25% of the generated energy, also including the unsold energy of the day-ahead market.With this strategy, agent SG 821 tries to be able to sell the remaining power at a higher price than in the spot market.This player expects that the buyer agents in the intraday market are willing to raise the value of their offerings, to ensure the purchase of the required energy.Although the excerpt from Figure 12 shows a rather limited version of the SG 821 proposal to the intraday market, it allows the identification of the definition of offers and prices for some periods (from line 10 to line 43).
After receiving and validation of the proposals, the market operator carries out the execution of the first session of the intraday market.At the end of the simulation, the market operator sends results in RDF to the participant players.An extract of SG 821's RDF results is shown in Figure 13.A full version is available online [55].For the intraday market, SG 821 considers the reserve of 25% of the generated energy, also including the unsold energy of the day-ahead market.With this strategy, agent SG 821 tries to be able to sell the remaining power at a higher price than in the spot market.This player expects that the buyer agents in the intraday market are willing to raise the value of their offerings, to ensure the purchase of the required energy.Although the excerpt from Figure 12 shows a rather limited version of the SG 821 proposal to the intraday market, it allows the identification of the definition of offers and prices for some periods (from line 10 to line 43).
After receiving and validation of the proposals, the market operator carries out the execution of the first session of the intraday market.At the end of the simulation, the market operator sends results in RDF to the participant players.An extract of SG 821's RDF results is shown in Figure 13.A full version is available online [55].By analysing the excerpt of the results achieved by agent SG 821, provided in Figure 13, it is possible to see the definition of HourlyResults for periods 12 (from line 17 to line 22), 20 (between lines 23 and 28), and 24 (from line 11 to 16).
Figure 14 shows a graphical representation of agent SG 821's results in the first session of the intraday market.Due to a very high wind generation, market prices tend to decline considerably, even assuming the value of 0 €/MWh in some periods.
It is possible to verify that agent SG 821 could not negotiate all the energy available in eight of the 27 trading periods (periods 5, 7, 15, 17, 19, 22, 24, and 26).From these eight periods, SG 821 failed to transact any of the available energy in four periods (17, 19, 24, and 26).In the other four periods (periods 5, 7, 15, and 22), SG 821 has been able to sell only a partial amount of its available power.This has occurred because the established market price has been equal to the bid price submitted by the player.The tendency for very low market prices is verified throughout the entire intraday market session, with more than half of the trading periods having 0 €/MWh market prices, or very near this value.The absence of power to negotiate during the first three trading periods (as they refer to the last three hours of the day prior to the studied simulation day) should also be noticed.By analysing the excerpt of the results achieved by agent SG 821, provided in Figure 13, it is possible to see the definition of HourlyResults for periods 12 (from line 17 to line 22), 20 (between lines 23 and 28), and 24 (from line 11 to 16).
Figure 14 shows a graphical representation of agent SG 821's results in the first session of the intraday market.Due to a very high wind generation, market prices tend to decline considerably, even assuming the value of 0 €/MWh in some periods.
It is possible to verify that agent SG 821 could not negotiate all the energy available in eight of the 27 trading periods (periods 5, 7, 15, 17, 19, 22, 24, and 26).From these eight periods, SG 821 failed to transact any of the available energy in four periods (17, 19, 24, and 26).In the other four periods (periods 5, 7, 15, and 22), SG 821 has been able to sell only a partial amount of its available power.This has occurred because the established market price has been equal to the bid price submitted by the player.The tendency for very low market prices is verified throughout the entire intraday market session, with more than half of the trading periods having 0 €/MWh market prices, or very near this value.The absence of power to negotiate during the first three trading periods (as they refer to the last three hours of the day prior to the studied simulation day) should also be noticed.The supply is significantly higher than the demand in all trading periods, as it is possible to observe in Figure 15.Despite the bid prices proposed by agent SG 821 always being 0 €/MWh, the player is not always able to sell all the available energy.Since it was not the only agent to submit offers with the price of 0 €/MWh, the market operator orders the offers with the same price in order of arrival which means that this agent did not submit its offers in a timely manner to ensure the complete trading of all its available energy in all periods.In the periods in which this agent negotiated only part of its supply, this agent was located in the intersection of the supply and demand curves of the symmetrical auction mechanism, so this agent was the one imposing the market price.
MASCEM's public ontologies have allowed agent SG 821 of MASGriP to participate in the simulation of the electricity market MIBEL.From the market operator's point of view, the MASGriP agent is viewed as a regular MASCEM player, despite MASGriP being an independent MAS.The supply is significantly higher than the demand in all trading periods, as it is possible to observe in Figure 15.Despite the bid prices proposed by agent SG 821 always being 0 €/MWh, the player is not always able to sell all the available energy.Since it was not the only agent to submit offers with the price of 0 €/MWh, the market operator orders the offers with the same price in order of arrival which means that this agent did not submit its offers in a timely manner to ensure the complete trading of all its available energy in all periods.In the periods in which this agent negotiated only part of its supply, this agent was located in the intersection of the supply and demand curves of the symmetrical auction mechanism, so this agent was the one imposing the market price.
MASCEM's public ontologies have allowed agent SG 821 of MASGriP to participate in the simulation of the electricity market MIBEL.From the market operator's point of view, the MASGriP agent is viewed as a regular MASCEM player, despite MASGriP being an independent MAS.The supply is significantly higher than the demand in all trading periods, as it is possible to observe in Figure 15.Despite the bid prices proposed by agent SG 821 always being 0 €/MWh, the player is not always able to sell all the available energy.Since it was not the only agent to submit offers with the price of 0 €/MWh, the market operator orders the offers with the same price in order of arrival which means that this agent did not submit its offers in a timely manner to ensure the complete trading of all its available energy in all periods.In the periods in which this agent negotiated only part of its supply, this agent was located in the intersection of the supply and demand curves of the symmetrical auction mechanism, so this agent was the one imposing the market price.
MASCEM's public ontologies have allowed agent SG 821 of MASGriP to participate in the simulation of the electricity market MIBEL.From the market operator's point of view, the MASGriP agent is viewed as a regular MASCEM player, despite MASGriP being an independent MAS.

Conclusions
This paper presented the development of ontologies for the interoperability of EM multi-agent simulation platforms.There are inherent difficulties in integrating independently developed agent-based systems, especially to access and map private ontologies.To overcome these difficulties, this work contributes with the development and dissemination of interoperable multi-agent simulators in the EM research area, thus enabling knowledge exchange between them in order to take full advantage of their functionalities, and promote the adoption of a common semantic that enables the communication between heterogeneous systems.
The Multi-Agent Simulator of Competitive Electricity Markets-MASCEMis-linked with other MASs developed within the Research Group on Intelligent Engineering and Computing for Advanced Innovation and Development (GECAD) research group, namely Multi-Agent Smart Grid Simulation Platform (MASGriP).With these systems being independent platforms, it is necessary to interconnect them in order to enable the study of broader and complex scenarios.As such, it is mandatory that the messages exchanged by the involved agents may be properly interpreted by both MASs.The cooperation between the different platforms can benefit, on a large scale, the realism and depth of EM and power systems' studies.
To achieve systems interoperability, the Electricity Markets Ontology was the first to be developed.It is the base ontology from which the Call for Proposal and Electricity Markets Results ontologies were extended.The ontologies are public and available so they can be easily accessed, reused and extended by Ontology Engineers or MAS developers in the scope of EM.
The description and analysis of a case study, with real data from the Iberian Market, demonstrates the advantages of using the proposed and publicly available ontologies for the interoperability between MASCEM, MASGriP and other multi-agent or single agent systems, in the scope of the wholesale EM.
MASCEM's restructuring resulted in an enhanced and FIPA compliant multi-agent simulator, which is able to interact and cooperate with other multi-agent societies through the use of ontologies.

Figure 3 .
Figure 3.Call for Proposal Ontology classes and object properties.

Figure 3 .
Figure 3.Call for Proposal Ontology classes and object properties.

Figure 3 .
Figure 3.Call for Proposal Ontology classes and object properties.

Figure 5 .
Figure 5. Electricity Markets Results Ontology classes, object and data properties.

Figure 5 .
Figure 5. Electricity Markets Results Ontology classes, object and data properties.

Figure 5 .
Figure 5. Electricity Markets Results Ontology classes, object and data properties.

Figure 8
Figure 8 shows the definition of a Bid placed in Period 1 (visible from line 21 to line 51), of transaction type sell (see line 30), for which 25 Offer fractions are defined (in lines 22 to 25; 27 to 29; 31 and 32; and 34 to 49).After receiving all the proposals or after finishing the available time for the reception of bids, the market operator validates the proposals and executes the session of the daily market.At the end of the market simulation, market results are converted into RDF and sent to the respective players.The RDF that contains the market results of SG 821 is shown in Figure9.The full RDF results of SG 821 are available online[52].

Figure 8
Figure 8 shows the definition of a Bid placed in Period 1 (visible from line 21 to line 51), of transaction type sell (see line 30), for which 25 Offer fractions are defined (in lines 22 to 25; 27 to 29; 31 and 32; and 34 to 49).After receiving all the proposals or after finishing the available time for the reception of bids, the market operator validates the proposals and executes the session of the daily market.At the end of the market simulation, market results are converted into RDF and sent to the respective players.The RDF that contains the market results of SG 821 is shown in Figure9.The full RDF results of SG 821 are available online[52].

Figure 9 .
Figure 9. Results achieved by SG 821 in day-ahead pool.

Figure 9 .
Figure 9. Results achieved by SG 821 in day-ahead pool.

Figure 14 .
Figure 14.SG 821's results for the first session of intraday market.

Figure 15
Figure 15 illustrates the results of the first session of the intraday market from the market operator perspective.

Figure 15 .
Figure 15.OMIE's results for the first session of the intraday market.

Figure 14 .
Figure 14.SG 821's results for the first session of intraday market.

Figure 15
Figure 15 illustrates the results of the first session of the intraday market from the market operator perspective.

Figure 14 .
Figure 14.SG 821's results for the first session of intraday market.

Figure 15
Figure 15 illustrates the results of the first session of the intraday market from the market operator perspective.

Figure 15 .
Figure 15.OMIE's results for the first session of the intraday market.

Figure 15 .
Figure 15.OMIE's results for the first session of the intraday market.

Table 1 .
Call for Proposal Ontology object property DL syntax.

Table 2 .
Call for Proposal Ontology classes DL syntax.

Table 3 .
Electricity Markets Results ontology object properties DL syntax.

Table 4 .
Electricity Markets Results ontology data properties DL syntax.

Table 5 .
Electricity Markets Results ontology classes DL syntax.