=Paper=
{{Paper
|id=None
|storemode=property
|title=Managing Unavailabilities in a Dynamic Scenario Following an Agent-Based Approach
|pdfUrl=https://ceur-ws.org/Vol-741/ID17_LocoroMascardiMontaraSanna.pdf
|volume=Vol-741
|dblpUrl=https://dblp.org/rec/conf/woa/LocoroMMS11
}}
==Managing Unavailabilities in a Dynamic Scenario Following an Agent-Based Approach==
https://ceur-ws.org/Vol-741/ID17_LocoroMascardiMontaraSanna.pdf
Managing Unavailabilities in a Dynamic Scenario
Following an Agent-Based Approach
Angela Locoro and Viviana Mascardi Franco Mortara and Renato Sanna
Computer Science Dept. (DISI) SELEX Elsag,
University of Genova, Italy Genova, Italy
{Angela.Locoro,Viviana.Mascardi}@unige.it {Franco.Mortara,Renato.Sanna}@elsagdatamat.com
Abstract—The correct management of resources that can • situated, since they must be aware of the portion of the
become unavailable over time and the efficient (in terms of both environment where they are located, in order to perceive
cost and time) re-allocation of the services they provided before changes in the neighboring entities and in their own
becoming unavailable, is an open problem that arises in a wide
range of application domains. production, consumption, and/or transportation capacity;
Despite to some differences, many scenarios spanning very • autonomous, since they must be able to solve at least
different domains, from logistics to industrial automation, from “small” problems locally, before spreading to all their
telecommunication to water systems, may be considered as neighbors or throughout the entire network the informa-
instances of a more general situation, and the actions to take in tion that a problem occurred;
order to solve the unavailability problem follow similar patterns.
• flexible, namely
In this paper we discuss the implementation of a multiagent
system for solving unavailability problems in an artificial - – reactive, since they must realize that a problem
although realistic - scenario which takes inspiration from to the occurred in a timely fashion;
electricity power network domain.
– proactive, since each of them has its long-term goal
I. I NTRODUCTION (producing, consuming, moving a certain amount of
assets);
Many real scenarios where assets are produced in some – social, since real scenarios usually involve humans or
physical locations and must be delivered to other physical companies which, of course, communicate using an
locations where they are consumed, can be described in a very high level communication language, and following
abstract way as graphs of nodes of different types, connected complex interaction protocols.
by edges characterized by different transportation capacities.
Assets are created in a set of “producer nodes”, must traverse Figure 1 shows a generic scenario for unavailability man-
the graph towards “consumer nodes”, and need to use edges agement: a multiagent system that implements a scenario of
and intermediate nodes during the graph traversal. According this kind, integrates the specific features of the application
to the scenario, it may be useful to model entities specifically domain under consideration, and proposes a reconfiguration of
devoted to the physical transportation from one node to another the asset production, consumption and transportation load in
one as well (think of a logistic network where freight trucks order to face unavailabilities that dynamically show up, could
and other vehicles are in charge of moving assets in the be profitably used ad a system supporting decisions of a human
network). operator.
Producers and consumers may be further organized in hier- Many real scenarios may be seen as instances of the general
archies where each producer controls a set of “sub-producers” one, and the actions that a decision support system should
and each consumer dispatches the assets it receives to a set take in order to help solving the unavailability problem follow
of “sub-consumers”, connected by edges and intermediate similar patterns.
nodes according to different topologies. Whatever the level For example, in a logistic network the resource that becomes
in the hierarchy, nodes and edges may show some degree of unavailable might be a stretch of road and the problem to be
autonomy and may be able to manage problems arising during faced concerns to which other roads traffic should be deviated
their operation on their own – at least up to some extent, before in order to ensure the quality of service required by the client;
involving entities higher in the hierarchy. The problems we are in a ship air conditioning plant, the resource that becomes
mainly interested in, are those due to resources (nodes, edges, unavailable might be an air channel and the problem to solve
other entities relevant for the scenario) that become partially is how to re-configure junctions among available channels
or completely unavailable and whose functionalities must be so to guarantee air conditioning to at least those rooms that
redistributed among other resources in the network. must necessarily keep a pre-defined temperature; in an electric
Such scenarios are very suitable to be analyzed following power network, the resource that becomes unavailable might
an agent-based metaphor [8]. In fact, the entities belonging to be a power station or a cable transporting electricity and the
the scenarios above are problem to solve is which power stations should be required
Generic Scenario
Agent of
Type C
Agent of
Type A
Agent of Agent of
Type A Type A
Agent of
Type B Artefact
Agent of
Type B
Agent of
Type A Agent of
Artefact Type A
Agent of
Type C
Unavailability or
malfunctioning
Fig. 1. The generic scenario for unavailability management
to start producing electricity, to provide for the reduction in II. D OMAIN A NALYSIS AND M ODEL
power supply. Despite to some differences, all these scenarios Starting from an accurate look into the Italian electricity
may be considered as instances of a the more general situation network and market, an analysis of the field has been carried
that we modeled as nodes, edges, and, if it is the case, out, as the result of the following questions:
additional entities that traverse the graph.
1) What are the main entities acting in the scenario at hand?
In this paper we describe a feasibility study that the scien-
2) What are the relevant coordinative actions that such
tists of the CS Department of Genova University (DISI) carried
actors may play according to their roles and to the
out in collaboration with engineers from Elsag Datamat1 ,
physical, economical and topological constraints of the
the Finmeccanica center of excellence for the design and
real domain?
production of systems, services and solutions in automation,
3) What kind of events may compromise the system con-
security, transport and information technology.
sistency or, otherwise said, what are the main events
The purpose of this study was to assess the suitability of
that need to be simulated and managed in order to find
an agent-oriented approach to the management of unavail-
a solution, if one of them occurs in the system?
abilities in complex, distributed scenarios. In order to give
an answer to that question coming from Elsag Datamat we An overview of the domain entities and the high level
made an “academic exercise” that takes inspiration from to topological constraints that our study of the domain let emerge
the electricity power network domain: although artificial, it is depicted in Figure 2, where a Zone level topological
is almost realistic and grounds upon information publicly perspective of the Italian electricity network is sketched. As
available that we obtained from the web sites of “Gestore dei the outmost subdivision of the Italian territory in the domain
Mercati Energetici S.p.A.”, a public company whose mission is of electricity supply, a Zone contains the following elements:
that of organizing and economically managing the Electricity • a set of Power Stations, each of which has one or more
Market, and from other public information sources. output links toward one or more Power Exchange Points2
The paper is organized in the following way: Section II • a Power Exchange Points set, each of which has input
introduces the model we designed after an accurate analysis links from a Power Station subset and output links to
of existing and publicly available information, Section III 2 We refer here to the entity with the following definition “a set of points in
discusses the architecture of the UMMAS system we designed the electricity network such that, for dispatching purposes, it does not matter
and implemented and shows some details about its execution, in which point electrical power is produced and in which ones it is consumed.
Section IV provides an overview of the related work and Hence, one and only one Power Exchange Point is associated with each
production/input (resp. consumption/output) point, whereas more input (resp.
outlines some lines for our future research. output) points are in general subsumed by the same Power Exchange Point.”,
translated into English by the authors from the Italian definition, available at
1 From the 1st of June 2011, Elsag Datamat combined with SELEX http://www.mercatoelettrico.org/ in the documentation that the website returns
Communications into SELEX Elsag. The work described in this paper was as the first result of searching the key phrase: “punto di scambio rilevante”
carried out with Elsag Datamat before that date. (Power Exchange Point in English).
Fig. 2. The Italian electric power network as a specialization of the general scenario
A. Actors and their Properties
The main actors defined for modeling the Italian electricity
network scenario are:
The Power Station (PS from now on), modeled according to
the following properties:
• physical features:
– type: thermal PS, hydroelectric PS or Renewable
energy PS;
– Minimum Electrical Power (minPow) and the Maxi-
mum Electrical Power (maxPow), that represent the
PS energy supply boundaries, expressed in Megawatt
per hour (MWh);
– quantity of supplied energy at the PS full capacity
(Baseload) that is computed as a function per hour
based on the previous day MWh energy delivered by
the PS itself, and that lies between its minPow and
maxPow rates. We define it as fbl : h → M W ;
Fig. 3. Electric power network topology: the inter-zone domain and symbols
used
– power-on ramp and power-down ramp, determined
by the MW and time necessary to the PS for reaching
its Baseload from its start-up (resp. shutting down
Consume Points. Some of them may also have links with completely after being turned-off);
other Power Exchange Points of the same Zone, and one – Secondary Reserve (SR), that is the quantity of
or more inter-Zone links, that is a physical link between ready-to-use electrical power always available for
Power Exchange Points of neighbor Zones. each PS to be put in the system after its power-on
An inter-Zone level overview of the Italian electricity net- ramp time (resp. to remove from the system at its
work, together with an explanation of symbols for our domain, power-down ramp time);
as described until now, is reported in Figure 3. – Other Services (OS), that is the result computed
In the next paragraphs we are going to describe in details the as a function per hour of the following difference:
main actors and the architectural choices that we adopted for maxPow - Baseload - SR.
our system as being inspired by the topological schema shown • topological features: outward links to one or more Power
in the above figures, by the competency questions reported Exchange Points.
above, and by some simplifying assumptions made during our • economical features:
domain modeling analysis, which we will explain along with – Baseload price, calculated over the previous day
the system model itself. energy supply and based on the price established by
the energy exchange market; The inter-Zone broken link event is an event that may occur
– SR price, calculated as the above Baseload, and in the system when a damage causes the total or partial
defined as the function fsr : h → Euro/M W ; unavailability of a link between two Zones. The two Zones
– OS price, calculated as the above Baseload, and involved should reconfigure their power production in order
defined as the function fos : h → Euro/M W . to avoid that more energy than those physically chargeable
The Power Exchange Point (PEP from now on), modeled within the new transit limit is not supplied anymore.
according to the following properties: The PS unavailability or malfunctioning event is an event that
may occur in the system when a damage causes the total or
• physical features: Demanding rate, calculated as a func-
partial unavailability of a PS that stops working or supply less
tion per hour of the MW consumed. We define it as
energy than expected or needed. It is then necessary to know
fcon : h → M W
which portion of power was delivered to the PEPs involved
• topological features:
and connected to the PS. They should retrieve the missing
– inward links from connected PS; energy from other PSs, under the best available rate criterion.
– intra-Zone links that provide its connections with This event can be reduced to the first one (the More Energy
other PEPs, and are characterized by a function that Demand event) and be modeled and managed in the same way.
states their availability per hour. For each link of this
kind we define the function flinki : h → {on, of f }; III. UMMAS: THE U NAVAILABILITY M ANAGEMENT
– inter-Zone links that connect PEPs of different neigh- M ULTI -AGENT S YSTEM
bor Zones. These links are further characterized by An overview of the main features of UMMAS is presented
the so called transit limits, expressed by the function in this Section.
ftl : h → M W , representing the quantity of energy A. Purpose
that can be carried at each hour in and out from two
different Zones; The UMMAS (Unavailability Management Multi-Agent
System) purpose is to rapidly find a sub-optimal scenario
The Zone, as a geographic area fully characterized by the PSs,
(that is the cheapest solution in terms of best available price
PEPs, intra- and inter-Zone links belonging to it.
for electricity) able to maintain the whole electricity network
B. Main Simulation Scenarios configuration in a consistent state with respect to an event such
as a maintenance operation, a malfunctioning or an unexpected
An overview of the unavailabilities or malfunctioning anal- change in energy consumption that may occur in the system
ysed as part of the unexpected events that may occur into our itself.
system is reported in Figure 4. An exhaustive gloss for each UMMAS has been conceived as a decision support tool for
of them is available in the next paragraphs. planning maintenance operations. The requirement to come to
The More Energy Demand event is an event that may occur in a fast system reconfiguration has forced us to apply heuristics
the system when a PEP has a higher energy consumption than that do not guarantee to reach an optimal solution. Moreover,
expected. The situation requires that one or more PSs augment a MAS oriented approach is not by its own nature the
the quantity of energy delivery in order to fulfill the increasing best one to achieve a “global optimization” solution whereas
request of electricity. The inquired PSs may be directly or its effectiveness and flexibility represent the best choice for
indirectly connected to the PEP and may be located in another dealing with local optimization problems.
Zone with respect to those where the request comes from. In
this last case the quantity of energy that out-of-zone PSs may B. Input Topology and Data
supply should be able to respect the transit limit constraint. UMMAS works with an oversimplified model of the electric
The criterion to choose which PS needs to be activated in power topology that is embedded into the system. A future
order to supply more energy is a search over all the PSs in the extension is foreseen in order to provide more complex
same Zone or in other Zones that can deliver their SR and, topologies as input data or configuration files. All the data
among them, all those PSs that offer it at the best available available by the system are:
price. If the amount of SR available does not cover the entire • for each PS: all the fixed parameter features (that is the
energy request, than a search for AS energy is activated under type, the minPow and maxPow, the power-on ramp and
the same best available price condition. power-down ramp) and the functions per hour, that is its
The intra-Zone broken link event is an event that may occur in fbl , fsr , fos ;
the system when a damage causes the unavailability of a link • for each PEP: its fcon ;
between a PS and a PEP. This case has been reduced in our • for each intra-Zone link, its availability function flinki ;
model to the “PS unavailability or malfunctioning” one that • for each inter-Zone link, its ftl ;
is depicted in the last paragraph of this Section. A sub-case An input parameter is also given for each kind of unexpected
that has been analysed even if not modeled into our system is event (we consider that a PEP consume rate, a PS baseload,
the one in which the PS is linked to another PEP that may be an intra-Zone link availability, and an inter-Zone transit limit
used as a bridge in order to supply the energy to the original may all vary in the system) that may occur at each time slot
PEP, if a proper connection exists between the two PEPs. (we consider a time unit as one hour).
Fig. 4. Electric power scenario: an unavailability map
C. Agents in the system
The agents that have been modeled as part of UMMAS are:
• the PS Agent
• the PEP Agent
• the Zone Agent
The other elements of the domain (e.g. the physical intra-
and inter-Zone links) have not decision capabilities and hence
are not considered as agents in the system.
The PS Agent knows what are its fixed parameters, its
supply functions and the PEPs to whom it is linked.
The PEP Agent knows its fcon , the PS that are linked to it, Fig. 5. The UMMAS-Lite Electric Power Network Topology
its flink for each intra-Zone connection with other PEPs and
inter-Zone connection with other PSs, the PEPs to whom it is
connected to (either intra- and inter-Zone), the Zone Agent to E. Simplifications over the Model
whom it belongs to. The following simplification with respect to the real domain
The Zone Agent knows all the PSs and the PEPs that belong model have been foreseen in UMMAS-Lite prototype:
to it and the neighbor Zone to whom it is directly connected. Simplification over the electricity network topology: the elec-
tricity network topology given as input in UMMAS represents
D. The UMMAS-Lite prototype: Design and Implementation a simplification over the real one. Figure 5 shows the embed-
The first UMMAS-Lite prototype release represents a demo ded domain model that is part of UMMAS-Lite.
version of the potential of UMMAS model and integrates some The UMMAS-Lite Agents are:
simplifications over the so far seen domain model in order to • three Zone Agents (namely ZONE A, ZONE B and
provide the fast design, implementation and testing of its main ZONE C);
functionalities. • three PEP Agents (namely PEP A, PEP B, PEP C)
The UMMAS-Lite prototype is an event-driven simulator where the letter stands for the Zone where they are
where an input event parameter is introduced in the system located
by a human operator and a stable and consistent system re- • twelve PS Agents distributed over the three Zones as
configuration after the event input is provided as output. Only follows:
after the system has reached a newly consistent state the – Agents from PS 1 to PS 5 belonging to ZONE A,
human operator may introduce another disturbing event. all linked to PEP A;
In the next paragraphs an overview of the simplifications – Agents from PS 6 to PS 8 belonging to ZONE B,
adopted over the domain model is presented. all linked to PEP B;
– Agents from PS 9 to PS 12 for ZONE C, all linked All the simplifications introduced have the purpose of
to PEP C; maintaining the system always consistent and of assessing that
• a ClockAgent that represents the system timeline and there is enough time to reconfigure it properly after an event
has as main task that of synchronizing all agents at the is introduced and a solution strategy has been adopted.
beginning as well as at the end of each simulation.
F. UMMAS-Lite Implementation
An oversimplification on the number of PEPs, by consider-
ing only one PEP for each Zone in UMMAS-Lite prototype In this Section we are going to give an account of the design
has as consequence that we can avoid considering the intra- and implementation details of UMMAS-Lite prototype. The
Zone links that are not part of the system as it stands. This prototype has been implemented using Jade 3.7 version.3
choice does not compromise the coherence of the model with G. Agents Data
respect to the real one.
Simplification over the input: both SR and AS can be pur- Each agent data is provided in Xml format and is read by
chased with a granularity of 1 MWh. each agent at the Jade Platform startup. An example of data
Simplification over the output: the PSs that are selected for the available for the agent PS 1 is as follows:
provision of energy are the cheapest in terms of best available
SR price and, if this is not sufficient to cover the demand, the
PS selected are also those able to provide the best available PS_1
OS price. The location of PSs does not influence the choice thermic
so as the fact that a PS has a lower start-up ramp time than PEP_A
another, and hence could provide the necessary energy in a 20
shorter time. 80
When a PS is asked to provide its best offer for SR and OS
supplies, the calculation is done by considering the availability 10
and prices at the time of the request, that it at time t1 (the time 1
when the event occurs), and sends all its offers at once.
When a decreasing transit capacity affects a transit limit
towards a Zone at time t1 , the agents manage a transaction 10
to reach a stable situation at time t1 + 1 as if the decreasing 1
capacity event occurs only for that time (and hence assuming
that in the time instant t1 + 1 the event does not occur
anymore). In this way the agents do not worry about the fact 1
that the situation would have been different if the event lasted 26
until time t1 + 1 (e.g. in case the specific event does not affect 2
the quantity of energy that is traveling at time t1 through the 24
transit device, because the quantity of energy is less than the ..
transit limit - the decreasing factor, the system does not need
to reconfigure itself, even if at time t1 + 1 the same condition 24
would have implied a system reconfiguration, e.g. the quantity 28
of energy traveling through the device at time t1 + 1 results
to be more than transit limit - the decreasing factor, and vice
versa). This choice has been done for consistency reasons: we 1
consider that an event happens at time t1 and lasts until time 16
t1 + 1 excluded. And that at time t1 + 1 the situation may be 18.10
different and unpredictable before time t1 + 1 occurs. ...
Simplification over the nature and frequency of events: each 24
perturbation is introduced as a single event in each time slot for 16
a single agent. This implies that at each time one single event 20.71
may be managed by the system. An original configuration may
be restored with the old data at time t1 − 1.
If an event is notified in the system at time t1 , the 1
system will reach a stable configuration not later than at 38
time t1 + max U pRamp + 1, being max U pRamp = 19.91
max(startU pRamp(P S)) such that PS is part of the network ...
and has been selected for extra energy provision. In this 24
way two events may occur at a time interval of at least
max U pRamp + 1 time units. 3 http://jade.tilab.com.
38 sending a new event message to the agents involved. This last
22.78 functionality has not yet being automatized in the prototype.
Each PS, PEP and Zone agent has been modeled and
designed as a state machine with behaviour patterns, that is
implemented inside each Agent’s Behaviour class. Each
H. UMMAS-Lite Classes state have as name the sender of a message and, inside each
In what follows an account of the UMMAS-Lite Java state, sub-states are designed, one for each kind of FIPA
package structure and a description of the main classes inside performative4 and content of the message itself. In this way
each package is provided. the sender and performative of the message are responsible for
each Agent state, whereas transactions between Agent states
• org.ummaslite.utils. This package contains all
are the messages sent by the Agent in reply to the performative
the classes that manage the UMMAS-Lite data structures,
of the message just arrived.
e.g. the Xml parsing and their read and write utilities.
The communication protocol between agents in the system
This package is exploited either for managing agents data
reflects the network topology of the domain. Hence, for
and message contents (e.g. offers lists and so on).
example, PSs can send direct messages only to their PEP (that
• org.ummaslite.data. This package manages the
is the only entity with which they have a direct link to in the
data at agent level (PS, PEP and Zone). For each kind of
reality); the PEP may send direct messages only to its PSs and
agent a data object is instantiated.
to its Zone; a Zone can forward such messages to its directly
• org.ummaslite.message. This package contains
connected Zones, and so on.
the Message class, that models all the message types
that are exchanged among UMMAS Agents, as well J. Message-State Behaviours
as the Helpers class that simplify the ACLMessage In this Section we are going to illustrate how our state ma-
object creation and contains the method to send and chine behaviour patterns works for each Agent. Each message
visualize its content. received is responsible for a particular transaction and hence
• org.ummaslite.behaviour. This package con-
strictly drives the overall simulation case interactions among
tains the AbstractAgent class that extends the the agents.
jade.core.Agent class and is used to model the The FIPA performatives that we use in the message ex-
agents jade.core.behaviours.Behaviour class changed among the UMMAS-Lite agents are the following:
according to the domain at hand. This classes are both
• INFORM: is the performative used in the time unit
implemented for each agent type.
message, the synchronization message, and the event
• org.ummaslite.agents. This package contains the
message;
agents classes for each kind of agent foreseen in the
• CFP: is the call for proposals message sent to PSs when
specific domain (Clock Agent, Power Station Agent,
requesting an offer for energy;
Power Exchange Point Agent, Zone Agent).
• PROPOSE: is the offer message that each PS sends in
I. Prototype Architecture response to the CFP;
• ACCEPT: is the acceptance notification of the offer sent
This Section presents a technical overview of the system to PSs when accepting their offer;
from the point of view of how it works and of the agents inter- • CONFIRM: is used by the PS to confirm the energy
actions, states and transactions that structure the UMMAS-Lite delivery;
prototype. The Clock Agent state machine pattern, as depicted in Figure
The system starts a scheduled simulation with the Clock 7, is the Clock Agent behaviour modeled according to two
Agent sending a message to every agent in the platform with possible states: the InitState, where it sends the time unit
the information of the simulation time unit. A second message message to all other agents in the system and the event
is sent with the event that the user has introduced in the system message to the agent involved in the unavailability (a PS Agent
to the address of the agent directly involved in the perturbation in case the event wants to simulate a decrease in its baseload;
(e.g. if a user has introduced an increase in power consumption a Zone Agent in case a decrease in the limit transit capacity
for a specified Zone then the receiver of the event message has occurred; a PEP Agent in case an increase in energy
will be the PEP of that Zone, and so on). Based on the type consumption needs to be managed); the SynchState in which it
of perturbation inserted the system starts different interaction waits for a synchronization message from all the other agents
patterns among the agents. and, after having received it, a new event may be managed
At the end of the simulation the Clock Agent keeps waiting (we recall that this last transaction is not implemented in the
until all the agents in the system send it a synchronization prototype).
message to complete the interaction and to inform it that The Power Station Agent state machine pattern is illustrated
the system is now re-configured. Once received this syn- in Figure 8. The initial state for the two behaviour patterns
chronization message the Clock Agent will be able to start
another simulation by giving a new start time unit and by 4 http://www.fipa.org/.
Fig. 6. A Simulation Example: the Power Station Unavailability
Fig. 7. The Clock Agent state machine pattern
depicted is the Clock State, where it waits for the time unit Fig. 8. The Power Station Agent state machine patterns
message as well as the event message (in the behaviour pattern
shown on the left side of the picture), in case this affects it
directly. As the event message in this case can be only one then it sends a synchronization message to the Clock. In the
between the unavailability or the malfunctioning of the PS second behaviour pattern the PEP receives a CFP coming from
itself, it sends a failure message to its PEP and sends the its Zone (that is the case in which another Zone is requesting
synchronism message to the Clock Agent that brings it into its offers for power supply) and forwards the message to its PSs.
initial state. In the behaviour pattern shown on the right side of It waits for offers to be forwarded to its Zone (for dispatching
the picture the PS Agent receives a CFP from its PEP, sends them to the original requesting Zone), and waits for acceptance
its offers and waits for acceptance. If the proposed offer is messages (that will come from its Zone in case the original
accepted it sends a confirmation message to its PEP, provides requesting Zone receives them from its PEP, that is in charge
the extra energy and sends a synchronizing message to the of collecting all the offers it needs and accepting some of
Clock Agent. them). If accepting messages arrive it forwards them to all
The Power Exchange Point state machine pattern is shown its PSs that are involved and waits for confirmation messages
in Figures 9 and 10. In the first behaviour pattern the PEP from them. It finally forwards them to its Zone (that again is
receives from the Clock the time unit message as well as an in charge of forwarding them to the accepting Zone that will
event message about an increase in the consumption of energy forward them to its PEP in order to complete the transaction).
that involves it directly. The PEP sends a CFP message to all It then sends a synchronization message to the Clock agent.
its PSs and to its Zone and waits for energy offer proposals. The Zone Agent state machine pattern can be visualized in
When the offers arrive the PEP ranks them according to the Figures 11, 12, and 13 . The Zone may receive from the Clock
best price available and sends an accept message to each of an event relative to the transit limit damage or decreasing
its PSs of which it has accepted the offer, and to its Zone in capacity. In this case the Zone sends a message to its PEP
case an offer from a PS of another Zone has been accepted. in order to inform it of the decrease in energy supply. The
The PEP waits for a confirm message coming from all the PSs PEP will act accordingly (see PEP first behaviour pattern). In
that are in charge of supply the extra energy just bought, and the second picture the Zone forwards a CFP from its PEP to
Fig. 11. The Zone Agent state machine pattern 1
Fig. 9. The Power Exchange Point Agent state machine pattern 1
Fig. 10. The Power Exchange Point state machine pattern 2
Fig. 12. The Zone Agent state machine pattern 2
another Zone, waits for the offer message and forwards it to its
PEP. When the PEP sends an accept message it will forward
it to the original Zone that has done the requests and waits
from it the confirmation messages that it will forward to its
PEP. The third picture represents the symmetric of the previous
behaviour pattern. Here the Zone receives a CFP from another
Zone, forwards it to its PEP, waits for offers and forwards
them to the other Zone, waits for acceptance and forwards it
to its PEP, and finally waits for the confirmation message and
forwards it to the other Zone.
A third common behaviour pattern for all the agents is
determined whenever the agent does not participate at all in the
simulation case at hand. It then remains in the initial state (the
Clock State) and sends to the Clock Agent a synchronization
message.
K. A UMMAS-Lite Simulation Run
In Figure 6 a simulation example of UMMAS-Lite in
action is reported in form of Jade Sniffer Agent Snapshot. Fig. 13. The Zone Agent state machine pattern 3
The simulation case reported is that of an unavailable or
malfunctioning Power Station that sends its unavailability
message to its PEP and the transaction is conducted within a recently appeared [4], we are considering to re-design and
single Zone boundaries. The names of the agents in the upper re-implement the UMMAS system using an ABMS system
boxes of the figure are in Italian. We provide hereafter their instead of JADE.
translation in English: As a concluding remark, we may state that the academic-
• CE stands for PS; industrial collaboration was fruitful and the engineers from
• PDSR stands for PEP; Elsag Datamat were satisfied of the results obtained by the
• ZONA stands for Zone. academic partners. In particular, both the ease of analyzing
a complex scenario following an agent-oriented approach and
IV. R ELATED AND F UTURE W ORK the closeness of the architecture of the resulting MAS to the
The research collaboration activity between scientists of real scenario architecture were extremely appreciated.
DISI and engineers of Elsag Datamat has been centered upon DISI and SELEX Elsag are currently working at a gen-
whether a MAS approach and technology is a well suited eralization of both the model behind UMMAS and the im-
solution to the analysis and modeling of a high level system plemented MAS, in order to make them applicable to other
architecture where different entities with different roles, au- domains of industrial interest.
tonomous and distributed over a network, may cooperate in a
complex scenario, as also discussed in [10]. In particular, the ACKNOWLEDGMENT
synergy efforts of this activity have been focused on modeling The work of the first and second authors is supported
unavailability management simulation systems, where some by the Italian research project Iniziativa Software CINI-
unexpected malfunctioning or unavailability event may occur FinMeccanica, and in particular their work is framed within
and compromise the system consistency, until a solution to the the “Software Agents in Support of Complex Systems Inter-
problem is found and the system is restored to a consistent operability” Laboratory.
state. Because of the relevance of the electricity domain and
R EFERENCES
of the many challenging problems it raises, we opted for using
the Italian electric power market as inspiring scenario. [1] D. Briola and V. Mascardi. Design and implementation of a NetLogo
interface for the stand-alone FYPA system. In this volume.
Differently from our prototypical system which was aimed [2] G. Conzelmann, M. North, G. Boyd, R. Cirillo, V. Koritarov, C. Macal,
at a feasibility study in a quite general scenario, many fully- P. Thimmapuram, and T. Veselka. Simulating strategic market behavior
fledged agent-based tools developed ad hoc for simulating using an agent-based modeling approachresults of a power market
analysis for the midwestern United States. In Proc. of the 6th IAEE
electricity markets exist. Among them we may cite SEPIA European Energy Conference on Modeling in Energy Economics and
[7], EMCAS [2], [9], STEMS-RT [3], NEMSIM [5], [6], Policy, 2004.
whose detailed analysis and comparison has been carried [3] R. Entriken. Using automated agents with probe: interface requirements
specification. Technical Report 1012157, EPRI, Palo Alto, 2005.
out in [11]. Although most of them include agent roles [4] A. Garro and W. Russo. easyABMS: A domain-expert oriented method-
which are similar to those that we defined for UMMAS (just ology for agent-based modeling and simulation. Simulation Modelling
to make an example, in SEPIA there are Zones, Physical Practice and Theory, 18(10):1453–1467, 2010.
[5] G. Grozev and D. Batten. NEMSIM: practical challenges for agent-based
Generators, Generation Companies, Generator of Last Resort, simulation of energy markets. In Proc. of CSIRO Complex Systems
Consumer Load, Consumer Companies, Transmission System, Science Annual Workshop. CSIRO Manufacturing and Infrastructure
and Transmission Operator), the physical model for the load of Technology, 2005.
[6] G. Grozev, D. Batten, M. Aanderson, G. Lewis, J. Mo, and J. Katzfey.
individual consumers and the economic model the electricity NEMSIM: agent-based simulator for australia’s national electricity mar-
market are definitely more sophisticated than in UMMAS. ket. 2005.
Also, some of them are developed using general-purpose [7] S. Harp, S. Brignone, B. F. Wollenberg, and T. Samad. SEPIA: a
simulator for electric power industry agents. IEEE Contr. Syst. Mag.,
agent-based modeling and simulation (ABMS) tools like 20(4):53–69, 2000.
SWARM5 , Repast6 , MASON7 , and NetLogo8 , whereas UM- [8] N. R. Jennings, K. Sycara, and M. Wooldridge. A roadmap of
MAS is implemented using JADE. agent research and development. Autonomous Agents and Multi-Agent
Systems, 1(1):7–38, 1998.
The choice of JADE as the tool for carrying out the research [9] V. Koritarov. Real-world market representation with agents. IEEE Power
on UMMAS was due to the background of the academic Energy Mag., 2(4):38–46, 2004.
partners that felt more comfortable with a tool they already [10] S. McArthur, E. M. Davidson, V. M. Catterson, A. L. Dimeas, N. D.
Hatziargyriou, F. Ponci, and T. Funabashi. Multi-agent systems for
knew, but also to an experience they had in a similar domain power engineering applications – part i: Concepts, approaches, and
where the NetLogo ABMS tool proved not suitable for their technical challenges. Power Systems, IEEE Transactions on, 22(4):1743
purposes [1], and to the lack, at the time the research activity –1752, nov. 2007.
[11] Z. Zhou, W. Chan, and J. Chow. Agent-based simulation of electricity
started, of settled methodologies for ABMS. markets: a survey of tools. Artificial Intelligence Review, 28:305–342,
Since integrated methodologies able to seamlessly guide 2007. 10.1007/s10462-009-9105-x.
domain experts from the analysis of the system under con-
sideration to its modeling and analysis of simulation results
5 http://www.swarm.org/.
6 http://repast.sourceforge.net/repast 3/.
7 http://www.cs.gmu.edu/∼eclab/projects/mason/.
8 http://ccl.northwestern.edu/netlogo/.