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/.