The Organisational Structure of an Agent-Based Model for the Management of Wastewater Systems

Water managers have to deal with complex problems due to the intertwined characteristics of processes, in particular those that occur in wastewater systems. Existing modelling approaches are usually centred in the physical, chemical and biological aspects of the individual processes, excluding the social and organisational context that will generate the global behaviour. These also include the responsibilities and decision making of different actors in the system. This paper proposes an agent-based model with the novelty to integrate the social and organisational structure of the wastewater system from which emerges the global behaviour of the system. The modelling process allows considering the legal regulations and the technical limits that would drive the decision making. The instantiation of the model, implementing a small system, evidenced the usefulness of this approach to manage the complexity of wastewater systems and its possible contribution to prevent environmental problems.


Introduction
The management of wastewater systems shows notorious importance in the water cycle due to its impact on the quality and the ecological state of rivers. The river often acts as a water supplier of the potabilisation plants, so poorly treated wastewater will require to a greater potabilisation effort. To manage the high complexity of wastewater systems, Rendón-Sallard et al.
[1], Poch et al. [2], Cortés et al. [3], Comas et al. [4] and Benedetti et al. [5] proposed the use of decision support systems. In this context, the introduction of autonomous decision support systems, defined as agents (Wooldridge and Jennings [6]), has opened a new way in management systems (Cortés and Poch [7]). This approach allows modelling the interactions between components and stakeholders and modelling the different variable scales of the domain elements. Modelling and simulating such an integrated system is a robust means of transposing the knowledge of that system into predictions of it and will bridge the existing gap between theory and practice (see [1]).
An agent is an autonomous program capable of taking its own decisions based on its perceptions and its goals. A multi-agent system (MAS) allows representing real systems using a bottom-up approach: first, modelling the individuals and their social model; and then, letting the complexity of the system to emerge from the effects produced by their behaviours and interactions.
The literature shows different methodologies for developing a multi-agent system. Several widely referenced are examples include Gaia [8,9], MaSE [10,11], Tropos [12] and Prometheus [13]. The analysis of these methodologies shows that all (except for Prometheus) present difficulties for considering different abstraction levels [14]. However, as Zambonelli remarks in [15], generic MAS methodologies pose difficulties when developing real and

Materials and Methods
The MAS model focuses on the individual and collective responsibilities of every stakeholder of the real system, and how they depend on others to achieve individual and collective goals, to ensure an adequate global performance. The key elements which describe the organisational structure of such a system are the roles. The roles group the activities necessary to achieve organisational objectives and clearly define who shall be responsible for those actions and the dependencies among them. Hence, dependencies among those activities are solved by means of coordinated action. An essential feature of role-based MAS models is that they decouple specific actors from the roles they enact [18]. The ALIVE framework describes an iterative process to use this approach to build the model, composed of the following five steps: • Detect and name the stakeholders of the system; • Formalise roles defining them, listing their goals, who depends on whom and who is responsible for what; • Describe the interactions between the roles to handle their dependencies in terms of interaction scenes; • The interactions defined in the previous step have to be linked into a meaningful interaction structure; • Clearly state how agents are going to enact the different roles they have to play during the execution of the model.
The model was built using the OperettA editor (integrated in the ALIVE framework editor) and allows the construction of the Opera organisational model, which contains the elements described in this paper [20,21].

Organisational Structure
The ALIVE methodology describes two main models: the Organisational Model and the Social Model. The Organisational Model includes: • The Social Structure, which defines the roles and how they relate with each other. • The Interaction Structure, which describes how the roles interact and how they coordinate in terms of scenes and landmarks to achieve. • The Communication Structure, which lists the messages that agents should use-its kinds and purposes, and what words can be used as their content (i.e., pragmatics and semantics). • The Normative Structure, which represents the norms that state what behaviours are acceptable, what is permitted and forbidden.
The Social Model explains what roles are played by each particular agent of the system, making explicit how roles are grouped and instantiated in the run-time system.
The following sections focus on presenting the Organisational Model (Social Structure and Interaction Structure), as well as the Social Model. It is important to note here that our model does not include a Communication Structure, since the purpose of our model was to implement simulations whose agents are not developed by different parties and therefore, communication among them does not require a complex model to describe an agreement, or explicit convention or shared knowledge about the terms to be used in messages. Moreover, the Normative Structure is not presented in this paper; although norms are an important component of institutions, either formal (e.g., UWS) or informal (e.g., neighbourhood groups), it depends on the specific legislation of its deployment. Nevertheless, the addition of a Normative Structure is planned as future work (see Section 5) to instantiate the model in a European Mediterranean basin.
This organisation should abstract the case study features, which are described in the next section.
3.1.1. Case Study: The Wastewater System The wastewater system contains different elements which generate wastewater such as households (H), industrial activities (I), and meteorological events. Each component can (individually) generate wastewater with different dynamic and compositional characteristics. Wastewater characteristics include the volume (V) and the pollutant concentrations, with total suspended solids (TSS), biochemical oxygen demand (BOD), chemical oxygen demand (COD), total nitrogen (TN) and total phosphorus (TP) [22]. These pollutant concentrations are represented with the term C, which denotes a vector of these pollutant concentrations where C r , with r = 1, . . ., 5, denotes each specific pollutant concentration.
The system also has elements treating wastewater (Wastewater Treatment Plants W W T P), and receiving waters (e.g., a river, lake). Figure 1 shows the schema of flows for a hypothetical urban wastewater system.

Social Structure
The Social Structure abstracts the case study's roles, the relations among them, thus linking individual objectives and the society goals. A wastewater system's organisation's primary goal is to discharge an acceptable effluent (i.e., with low pollutant concentrations) for the receiving waters. Defining the roles allows encapsulating the stakeholders' responsibilities (see Figure 2, the roles identified, their objectives and sub-objectives).
Still, they also require specifying the dependencies between these roles to fulfil their goals. Some objectives may require another role for its fulfilment-the role interaction structure can model this kind of dependency on. It is possible to distinguish tree types of role dependencies: • Hierarchical: one of the roles acts as an authority over others and therefore, whenever a superior requests something to its related inferior, the latter has to comply with that request. These are detailed as H in Figure 2; • Network: when the roles depending on each other coordinate as peers to achieve a shared objective. This dependency is marked using an N in Figure 2; • Market: when some roles act as producers and consumers, the former being providers of services or products at a given price; it is shown as M in Figure 2. Roles can also be described as external or internal (detailed as Ex and In, respectively, in Figure 2) In the case where software components enact an internal role, this implies that it is possible for the organisation to manage its implementation (e.g., verify and validate it). In the model presented, the authorities responsible for wastewater management (or, indirectly, their computational systems) are internal roles. Contrary to internal roles, external roles are not controlled by the organisation despite being participants in it. If those external roles were implemented by software, it would imply that the organisation might not be able to check the code or validate its internal processes. In our scenario, external roles correspond to, e.g., the water generators.
In Appendix A, a complete list of the different roles is presented. An example of these roles was presented next (roles are presented in bold and goals in italics): IndustrialOperator: role enacted by actors whose primary goal is to generate profit (MakeProfit) performing industrial processes, as a collateral effect of that industrial activity (Produce). This role, to manage the resulting wastewater depends on an Industrial-WWRetainer which can store wastewater for a subsequent discharge (StoreIndustrialWW), if required.
IndustrialWWRetainer: the main purpose of this role is to store industrial wastewater generated by an IndustrialOperator (StoreIndustrialWW) and manage its content properly (ManageStoredWW), by deciding to keep it stored or release it (DischargeIndustrialWW). Wastewater discharge depends on the IndustrialWWBroker role, to arrange such discharge and its cost, and evaluate whether it is possible to do a full or partial discharge, or just hold it for later release. If a discharge is performed, IndustrialWWRetainer logs it (LogIndustrialWWDischargeCharacteristics), so a register is built to be used by SewageInspector role. This role would then verify that everything is working as expected (VerifyDischarge). Logging discharges requires knowing its characteristics, thus creating dependency on the WSensor role.
IndustrialWWBroker: its responsibility is to negotiate how much industrial wastewater can be released and the cost of doing so. The negotiation takes place with a WWReceiver (AssessAmountOfIndustrialWWDischarge). This process depends on how much I i is willing to pay (ObtainDischargeReservedCost) given the WWReceiver's price.
IndustrialWWBroker: this role is responsible for negotiating industrial wastewater discharges with a WWReceiver to assess how much wastewater can be discharged (As-sessAmountOfIndustrialWWDischarge). From the IndustrialWWBroker perspective, this assessment requires knowing its reserved cost (ObtainDischargeReservedCost) (i.e., how much I i is willing to pay according to the discharge price given by the WWReceiver).
The IndustrialWWBroker will compute this reserved cost depending on the aforementioned discharge price requested to the WWReceiver (ObtainDischargeReceiverPrice): • The reference prices are given by the CompetentAuthority with regards to volume and concentration of discharges (ObtainDischargeReferencePrice); • The characteristics of the wastewater (i.e., volume and concentrations of pollutants) to be discharged, which are provided by the IndustrialWWRetainer as part of the wastewater discharge negotiation process.
Once negotiation ends, either one of the following may happen: • An agreement is not achieved, and wastewater is kept stored until prices go down (if storage capacity allows doing so); • An agreement is achieved, and some (or all) wastewater is discharged; the actual discharge may comply or not to what was previously agreed. Figure 2 shows the dependency relation between the IndustrialWWBroker and the WWReceiver is a market dependency (M). Usually, a WWReceiver will also work with a WWTreater role to provide treatment capacity for discharged wastewater and therefore, when received wastewater is discharged later on, it will comply with the legal constraints that affect those discharges and guarantee a suitable water quality when it reaches receiving waters. The IndustrialWWBroker is consuming the service provided by actors enacting the WWReceiver role.
WWReceiver: this role is responsible for arranging the arrival of industrial wastewater discharges (NegotiateDischarge). This negotiation depends on having the discharge prices for I (CalculateIndustrialWWDischargePrices) and knowing how much treatment capacity is available (CalculateIndustrialWWAvailability). To determine wastewater discharge prices, some information is needed: • Reference prices from the CompetentAuthority; • The treatment efficiency of wwtp j (ObtainTreatmentEfficiency) and; • The characteristics of the wastewater whose discharge is being negotiated by an IndustrialWWRetainer.
In addition, treatment capacity availability requires knowing: • How much household wastewater is being received (ObtainHouseholdDemandForecast); • Whether there is any meteorological phenomena expected (ObtainMeteoDemandForecast); • Whether the CompetentAuthority has imposed any limitations on the wwtp j effluent (ObtainWWTPEffluentLimits); • Treatment efficiency in the WWTreater (i.e., WWTP ) (ObtainTreatmentEfficiency).
Once a discharge is arranged, it will eventually arrive. At the moment of the reception, WWReceiver decides its destination (EvaluateInfluentDestination). The wastewater can be accepted for treatment or, depending on current circumstances (e.g.,, unexpected rainfall), may be bypassed to the receiving waters. This decision is affected by the influent characteristics (ObtainInfluentCharacteristics), current wwtp j efficiency (ObtainTreatmentEfficiency) and how much space is available (CalculateAvailableCapacity). Similarly to WWRetainer or WWTreater, it logs received wastewater characteristics (LogInfluentCharacteristics). This information is required by the SewageInspector (to fulfil its VerifyDischarge goal) and it is also used to compute treatment efficiency.
WWTreater: a role responsible for decreasing the concentration of pollutants in wastewater (WWTreatment) before its release (usually into receiving waters such as a river). Similarly as in IndustrialWWRetainer, the effluent is analysed before its release (ObtainEf-fluentCharacteristics) and used for two reasons: to log it for any possible audit from the CompetentAuthority (VerifyWWTPEffluent), and to compute the treatment efficiency (Calcu-lateTreatmentEfficiency) which, likewise, requires knowing the characteristics of the influent (ObtainInfluentCharacteristics). Knowing its efficiency facilitates the WWTreater's task of pursuing its goal of being efficient (AchieveAdequatePerformance). Usually, this role is also needed to assist WWReceiver during the negotiation process with an IndustrialWWBroker.

Interaction Structure
The Interaction Structure allows the description of abstract patterns of interaction which are the way that the roles coordinate their behaviour, managing their dependencies while they pursue their individual and collective objectives. The interaction structure (see Figure 3) defines interaction patterns composed of a set of scenes and transitions among them [18]. Each scene represents a meaningful subset of the interaction between the system stakeholders, that is, an interaction pattern between two or more roles to coordinate their behaviours to achieve one or several (social) goals. On every scene, one or more role dependencies (identified in the previous phase) are managed. Table 1 summarises the role dependencies shown at every particular scene. Transitions mark the valid interaction paths for actors. Depending on the role(s) they enact, they may move from one scene to another. They may enter the scene at any time or only after meeting some conditions (e.g., there are enough actors from all roles to run the scene).  The structure's entry point is represented by a circle (init label), while the triangles represent exit points (end label). Rectangles represent scenes, and they are connected by lines (scene transition arcs) that allow the system to navigate from scene to scene. Scenes are connected through red semi-circles or green triangles to represent that the scene flow will move on once all scenes have been completed (for semi-circles), or at least one of them has been completed (for triangles). The landmark patterns describe the protocol used by actors to achieve the scene result [18]. Figure 4 shows the process of industrial wastewater discharge. The figure depicts the internal landmark patterns for the IndustryWWGenerate and IndustryManageWWTank scenes; as a result of the industry's production process (Produce), wastewater is generated (IndustrialWWGenerated) and stored in retention tanks. As retention tanks have limited capacity, they have to be managed (IndustrialWWManaged) to determine the best moment for releasing their contents into the WWTPs . To determine the cost of treating generated wastewater, whenever wastewater is available on the tank (IndustrialWWInTank), it is analysed (IndustrialWWCharacteristicsObtained). I also starts a negotiation with W W T P to determine the discharge price for wastewater reception (DischargeNegotiationStarted). The I also needs the reference price from the CompetentAuthority (DischargeReferencePriceAsked), to be used as a criterion. The negotiation requires the provision of wastewater characteristics to W W T P (IndustrialWWCharacteristicsSent), so the discharge receiver price can be effectively asked (DischargeReceiverPriceAsked).
Description Scenes for industrial wastewater generation. Industrial wastewater is produced and temporarily stored while the industry agent negotiates with WWTP as to when to perform a discharge, and its price.

Results
IndustryWWManaged results in profit being generated for Industry and wastewater stored. IndustryManageWWTank results in discharge prices obtained (for both, the reference price from CompetentAuthority and the current price from a WWReceiver). See the landmark patterns for other processes in Appendix B.

Social Model
The Social Model describes which organisational roles play each agent. These roles drive agent's behaviour and support agents to coordinate by complying with the scenes defined in the Interaction Structure. An agent can play any number of roles; it depends on the goals of these roles. In addition, more than one agent can play the same role. For the purpose of the case study, the UWS's objectives are the main criteria to assign roles. Figure 5 depicts the social model for the case study. The square-shaped elements are the agent types: Household, WWTP , Industrial, River Council and Meteorological. The round-shaped elements are the roles. The directed links represent which agents enact each role.

Behaviour and Decision-Making
In previous model (Social Model), the RiverCouncil agent is in charge of affairs concerning the collection, treatment and disposal of wastewater. The WWTP agent represents a given wwtp j ⊂ W W T P, who has to reduce pollutant concentration in wastewater before releasing it. The release of wastewater needs an agreement between an industry and the WWTP that will receive it for treatment. For such an agreement to take place, wwtp j needs to know if it can properly handle the wastewater. The agreement process works as follows: wwtp j checks whether it can accept a discharge from I i (a mass represented as V i , C i . This means warranting there is sufficient volume capacity available (volume availability) and that the WWTP can treat the wastewater pollutants (pollutant concentration admissibility). The volume available is determined (see Equation (1)) by the design volume of the plant (V capacity ) minus the amount of household wastewater (V d ) and meteorological forecasts (i.e.,, rain) (V m ), which the WWTP is obliged to accept. It also has to take into account any agreements already made to other industries (V scheduled ).
Then, if V i ≤ V available , it means there is sufficient capacity in the WWTP to accept the industrial wastewater.
However, to achieve an agreement, it is also necessary that the plant can admit its pollutant concentration. This condition depends on how much pollutant concentration the plant can effectively cope with, which is determined by the plant's design parameter ( C admissible ). Although it is not something desired, sometimes admissibility may be overlooked; which implies that process will incur an additional cost, depending on the specific pollutant (C r ) and the amount exceeded. This will affect the price given by wwtp j accordingly (see Equation (2)): There are two elements in Equation (2): VC (volumetric cost) and PC (pollutant cost). On the one hand, the VC component represents the cost of allowing the entrance of a given wastewater volume (V i ) released by I i given the status of wwtp j . On the other hand, the PC component represents the cost of treating a given wastewater mass (WW i ), with certain pollutant concentrations, released by I i . These costs could have additional taxes, which are imposed by the responsible authority.
Volumetric cost is defined as The first part of Equation (3) is developed as GT corresponds to the general tax paid by industries while ST(i) is the specific tax that depends on the type of industry where I i belongs. This formula expresses the industry's taxes paid to discharge a specific wastewater volume (V i ). These taxes are defined by the competent authority. The second part of (3) is an exponential function that measures how much volume is available in the wwtp j from its total capacity. The potential factor, x, expresses the fact that the price increases as the wwtp j becomes fuller.
The following formula, based on [22], defines the pollutant cost: where: • q r is the reference price for discharging a mass unit of pollutant r and the competent authority determines it; • g r i is a peak coefficient that expresses the deviation between the pollutant r concentration in the wastewater mass sent by the industry I i and the pollutant concentration limits agreed with the competent authority.
The coefficient g r i allows industries to deal with unforeseen situations that force them to discharge more pollutant concentrations than they are entitled to, by paying a higher price for doing so. It is calculated as where X r i corresponds to the maximum concentration of pollutant r in a discharge, agreed between industry I i and the competent authority. In this way, Equation (2) considers the permits given by the responsible authority to industries in terms of allowed pollutant concentration and taxes for discharging wastewater, and the current status of wwtp j (in terms of volume occupancy). This will also enable industries to overpass pollutant concentration to deal with unforeseen situations as long as they can pay for the extra cost it implies.
Finally, wwtp j communicates the price and available volume to the industry. Then, I i decides to to either keep storing the wastewater in its internal storage tanks or to proceed with a full or partial discharge.

Negotiation
The negotiation protocol allows for I i to negotiate with wwtp j , in a peer-to-peer fashion, in order to reach an agreement for treating industrial wastewater in a decentralised way. This protocol is initiated by I i , and will occur typically when their wastewater tanks are full, looking for the lower wastewater treatment price and therefore the maximum benefit, which is the ideal situation from I i 's perspective. In addition, the protocol allows for wwtp j to negotiate with I i providing offers for wastewater treatment. This scenario will typically occur when a plant's demand is low, with respect to the plant's treatment capacity, and will allow to any wwtp j to balance its treatment capabilities, offering to treat wastewater at a lower cost when their demand is lower in valley hours.

Results and Discussion
To check the model feasibility, the conceptualisation has been used to build an agentbased simulation. The simulation has been implemented using Repast Symphony [23]. The execution followed the indications depicted in the model: • Linking goal-driven behaviours; • Allowing them to choose which scene they will navigate to (i.e., discharge wastewater to a WWTP or store it in a retention tank), and how (which WWTP or tank to use in either case); • Selecting among the set of actions available to transition from landmark to a landmark (within scenes) and from one scene to the next one.
In this way, the simulation can reproduce the behaviour of the most important stakeholders (e.g., industries, WWTPs or households) as well as the impact of their decisions and actions in the receiving waters, evidencing feasible environmental problems.
A complete execution trace of the simulation is presented in Appendix C. It represents a simple hypothetical scenario: no rainfall at all, a WWTP (with a storage capacity of 60.0 volume units) and two industries (Industry 1 and Industry 2, with a storage capacity of 40.0 and 20.0 volume units, respectively). This trace was focused on checking that interactions and processes modelled are performed correctly. This means having a deterministic scenario that verifies the correctness of expected interactions and protocols. In addition, a set of unitary tests have been implemented with the collaboration of domain experts. These tests include each atomic action (e.g., produce, store, discharge, water treatment) and the scenes that involve a WWTP and industry. Finally, an integration test that composes the flow of scenes that simulate the interaction between these two industries and a WWTP has also been coded. This test has been the basis to produce the trace. Figure 6 summarises the trace visually. The first ticks are for warming up the system, and after eighteen ticks, a pattern emerges. We set up the treatment process to last four ticks, and each industry produces ten-volume units of wastewater. This means that Industry 2 cannot store all wastewater, and it is spilling it (orange line, with up-pointing triangle symbol). As a result of this, the WWTP cannot hold off all the incoming water, and it has to bypass it to the river (the dark red line, with down-pointing triangle symbol, and the peaks in the dark blue line, with square symbol, which represent the volume being held in the basin). In contrast to this, Industry 1 is generally performing since it has enough storage capacity so the WWTP can treat water and allocate new space.
In addition to this simulation execution, the model has also been used to feed a normmonitor system, NoMoDEI [24] Figure 7a is a snapshot of the norm-monitor screen showing a bird's eye view of the scene diagram. This includes information of what scenes have been selected by agents, that is, after agents performed their intended actions, which states of the world were achieved. Moreover, as seen in Figure 7b, it is possible to retrieve detailed information for each scene, such as the number of agents currently participating in that scene, how many agents have been engaged in it (history of past scene engagements), how many active norms have been instantiated, and how many of these norms are currently violated. Nodes are coloured as follows: • Orange nodes stand for blocked scenes (i.e., scenes no agent has participated in, neither in the past nor at the present moment). • Blue nodes stand for paused scenes, nodes that have been participated in by some agent in the past but not currently. • Green nodes stand for active scenes, with actual participating agents.
Edges between nodes denote transitions between scenes. An edge contains a colouredsquare at its destination side. Red squares represent a blocked scene transition (i.e., never been used by any agent), and blue ones represent active scene transitions (i.e., the agent has used them).  This visualisation tool allows to contrast the social model with the dynamic simulation data, thus monitoring in real-time which scenes are taking place, which scenes ones are the most performed, or if some are never visited. This capability allows detecting potential design flaws in the social model or in the design of the agent's behaviour (i.e., via scenes that are never visited by agents). It is also possible to monitor norm activation and violation with regards to the scenes, that is, whether a scene is producing norm violations [24].

Conclusions
In this paper, we present a novel modelling approach for wastewater management systems that is able to model the expected behaviours of the overall system via the definition of the social and organisational responsibilities from different stakeholders and the patters of interactions to be followed by the different stakeholders to deal with the water disposal and treatment in a distributed, effective way, and contribute to watershed's protection. Our model is based in ALIVE, a flexible methodology we used to model the complex interactions among different actors via the description of the roles they play, the goals they are expected to achieve and the dependencies on other stakeholders.
The Social and Interaction Structures presented in this paper (see Sections 3.1.2 and 3.1.3) allowed us to model a significant group of heterogeneous agents (representing different stakeholders in the water management system) with diverse individual responsibilities, interests, and behaviours and an emerging global behaviour. For each scenario, non-technical experts can assess the state of the abstract society that the system represents by checking the set of landmarks traversed by the different actors (see Figure 4 as an example; also see [24] and Figure 7 as an example on how the model presented is used to create a visual representation that eases logging the agents' behaviour in terms of the scenes). Moreover, using the proposed methodology, the user can easily modify the scenario to introduce new actors, augmenting its complexity. Thus, the methodology demonstrates its applicability at a regional scale and targeted at evaluating long-term scenarios. By using this methodology, both domain experts and policy makers can model the system as a whole, indicating the overall dependencies and the societal objectives of the stakeholders independently of their individual behaviours, thus allowing great flexibility to run different scenarios or integrate third-party implementations as long as they comply with the organisational model. Furthermore, the MAS paradigm has demonstrated its usefulness in managing the complexity of wastewater systems and its feasible contribution to preventing environmental problems-in addition to being an approach applicable to other aspects of water management.
The ALIVE framework allows to enrich the Organisational Model with the definition of its Normative Structure, defining permissions, obligations and prohibitions, applied to role definitions or scene descriptions. The Normative Structure significantly depends on the local legislation of the place where the model was to be implemented. In this paper, we did not included a model of the Normative Structure for this scenario (but the interested reader can find examples of norms applied to an earlier version of the model presented in this paper in [19,24], showing how domain experts can easily add normative constraints relevant to their needs). We plan to perform a full normative analysis on a specific regulatory scenario, such as the Mediterranean basin in a European country. As a next step, we plan to do a normative analysis involving different legislative levels, including: European (Water Framework Directive), national (e.g., Spanish) and local (e.g., Catalonia). This analysis will allow to further refine the model by incorporating the body of regulations that would affect the roles, scenes and interactions in actual deployment.
Measuring the volume of water (ObtainVolume); • MeteoRetainer: role responsible for storing water coming from meteorological conditions (e.g., rain) (StoreMeteoWW). This stored water is analysed (ObtainMeteoWWCharacteristics) and its destination is assessed (AssessMeteoWWDestination) (e.g., the storage tank is overflown and it cannot retain more water). Depending on the assessment result, water is either: -Discharged to a WWReceiver (DischargeMeteoWW); -Bypassed to the river (BypassMeteoWW), which also requires informing the Com-petentAuthority of such event (InformBypassMeteoWW); -Kept stored, if possible.
The relation between the MeteoRetainer and WWReceiver is a network dependency. Both roles act as equals since none of them have an authoritative power over the other nor they are consuming any service provided as in a market. This relation is motivated by the willingness to coordinate their actions and achieve the system's goal of providing a certain level of water quality which emanates from the CompetentAuthority goals. • HouseholdWWDischarger: This role generates wastewater produced by residential areas and discharges it to the sewage system (DischargeHouseholdWW). It provides the wastewater characteristics that it generates to roles that may need it (ObtainHousehold-WWCharacteristics) such as WWReceiver as part of its goal ObtainHouseholdDemand-Forecast. • WWReceiver: this role takes care of negotiating the reception of wastewater masses (NegotiateDischarge). This includes providing discharge prices for I (CalculateIndustri-alWWDischargePrices) and the treatment capacity available for industrial wastewater (CalculateIndustrialWWAvailability). To calculate discharge prices, actors enacting the WWReceiver role use the discharge reference prices provided by the CompetentAuthority, the current treatment efficiency in wwtp j (ObtainTreatmentEfficiency) as well as the characteristics of the industrial wastewater that a given I i wants to discharge, which are provided by the IndustrialWWRetainer as part of the wastewater discharge negotiation process. Concerning treatment capacity availability, it depends on:

-
The wastewater being received from households (ObtainHouseholdDemandForecast); Once the influent is received, the WWReceiver determines its destination, either to be sent for treatment or bypass it directly to the river. This decision depends on the (EvaluateInfluentDestination) wastewater characteristics (ObtainInfluentCharacteristics), wwtp j current treatment efficiency (ObtainTreatmentEfficiency) and available capacity (CalculateAvailableCapacity). Finally, it also keeps a record of the influent characteristics received (LogInfluentCharacteristics) for the SewageInspector (as part of the VerifyDischarge task) and WWTreater (in order to calculate treatment efficiency). • WWTreater: a role responsible for processing the wastewater to reduce its pollutants concentration (WWTreatment). Once the treatments ends, treated water is discharged as an effluent to the river. This effluent is analyzed (ObtainEffluentCharacteristics) and information is logged so the CompetentAuthority can audit it (VerifyWWTP-Effluent). Given the effluent and influent characteristics (ObtainInfluentCharacteristics/ObtainEffluentCharacteristics), WWTreater can calculate treatment efficiency (Cal-culateTreatmentEfficiency). This calculation is used to keep W W T P as efficient as possible (AchieveAdequatePerformance). It is also used to support WWReciever during the discharge price negotiation described before. • CompetentAuthority: this is the role that takes care of ensuring the river has a certain quality level determined by applicable legislation (EnforceWaterQualityPolicies). To do so, it should assess river water quality continuously (AssessRiverWaterQuality) by means of collecting river sensor data (CollectRiverSensorData); these data are requested by entities playing the WSensor role. Such entities are expected to be physically located along the river basin. According to the results of this assessment, it may request a SewageInspector to verify that every I i is compliant with what they agreed with wwtp j concerning wastewater discharges (VerifyDischarge). Depending on the current status or even exceptional meteorological conditions, it is possible that the CompetentAuthority requires establishing exceptional restrictions on the system (EstablishExceptionalRestrictions) to ensure river water quality. The Com-petentAuthority also uses the above mentioned assessment for two main purposes: First, providing discharge limits for the industry set I (CalculateIndustryPermissionLimits) and effluent limits for the W W T P set (CalculateWWTPEffluentLimits). In this way, the CompetentAuthority can establish pollutant reductions in certain river sections and in general, in the river as a whole. Second, determining reference prices for wastewater discharges (CalculateDischargeReferencePrices). These elements are used by both IndustrialWWBroker and WWReceiver as part of their negotiation process when discharging industrial wastewater. Finally, CompetentAuthority also checks W W T P are compliant with the effluent limits established (VerifyWWTPEffluent). Given that the CompetentAuthority has to ensure that the rest of roles are compliant with water quality legislation, all the dependencies that are related to this role are hierarchical ones, since the system requires the CompetentAuthority to have a power relation on all the roles to oblige them to coordinate appropriately. • SewageInspector: actors enacting this role are responsible for monitoring activity in the urban sewage system: verifying industrial discharges (VerifyDischarge) that are being produced; checking that the influents that are received by the WWReceiver (ObtainLogWWTPInfluents) that the effluents sent by IndustrialWWRetainer (ObtainLogIndustrialDischarges) match and that there is no strong deviation that places W W T P into a hazardous or unsuitable state (e.g.,, too many industries discharging more water or with more pollutant concentration than that which was previously agreed, thus affecting W W T P processes negatively). The result of this verification is reported to the CompetentAuthority to act accordingly.
Description The scene starts with household wastewater being generated. It is managed by a HouseholdWWDischarger role which collects the wastewater from households in a city/town. The role obtains the wastewater characteristics and sends them to a WWReceiver (e.g., the assigned WWTP ), and discharges it (not necessarily in that order).

Results
Wastewater discharged. Description The negotiation started in Figure 4 (in article) and continues in this scene. With all the forecasted discharges, the current efficiency of the treatment, limits on the effluent, the current availability of WWReceiver and the reference price established by the Compe-tentAuthority, the WWReceiver determines what is the price of accepting a given industrial wastewater mass.

Results
Price calculated for accepting a given industrial wastewater mass by WWReceiver. Figure A3. Landmark patterns for the industry price negotiation. This shows how the price to handle an industrial discharge is determined according to household and meteorological demand forecasts, limitations imposed by norms, volume availability and the wastewater characteristics.
Description Left scene shows how WWRetainer assesses if it keeps the wastewater it stores or discharges it according to the price obtained by the WWBroker. Right scene occurs when WWRetainer decides to discharge all or part of the wastewater stored.

Results
IndustryAssessWWDischarge: WWRetainer decides how much wastewater is kept in its storage and how much is discharged. IndustryWWDischarge: Wastewater mass is discharged and its characteristics are logged. WWRetainer either informs WWReceiver about the agreement or stores the agreement for future verification with logged discharge. Figure A4. Landmark patterns for the industry discharge. It shows the decision process carried out by the Industry agent to manage its wastewater: keeping it stored or discharging it so a WWTP can process it. Such a decision depends on the processing price and the agent's reserved cost.
Description The SewageInspector obtains the industrial discharges logs as well as the masses received by WWReceivers, and checks for any inconsistency that may incur in a sanction.

Results
The SewageInspector assesses the results of its verification; this may imply sanctions. Figure A5. Landmark patterns show how logged information (influents previously received by WWTP) is double-checked against agreed industrial discharges.
Description WWTPReceiveInfluent: Once a wastewater arrives, its characteristics are obtained and logged. Depending on the available space, it is accepted or bypassed to the river. If the wastewater mass is bypassed, it has to be reported to the CompetentAuthority. If the mass is accepted, the WWTreater logs its characteristics, treats it, logs the treated mass characteristics and updates the treatment efficiency.

Results
WWTPReceiveInfluent: Wastewater arrives, its characteristics are logged, and it is either accepted or bypassed. WWTBypassInfluent: Wastewater is discharged to the river and its characteristics are reported to the CompetentAuthority. WWTPTreatInfluent: Wastewater is treated, eventually discharged and its characteristics are logged to update treatment efficiency. Figure A6. Landmark patterns for WWTP influent treatment. Both diagrams show how wastewater is processed in a WWTP. The left diagram shows the treatment process carried out by WWTP agent: the influent is treated and the effluent characteristics and process efficiency are logged. The right diagram shows how wastewater is bypassed and directly thrown to the river; such a bypass has to be reported to the Competent Authority.
Description Independent scenes that are mainly performed by a Competen-tAuthority to update restrictions, limits and reference prices.

Results
Each scene updates a specific element that affects the system as a whole: effluent limits for the WWTP, limits for industrial discharges, reference prices for wastewaterdischarges and raising any exceptional restriction (e.g., heavy rainfall).