cordis.europa.eu · ref. 318603 - waterp, d7.2.2_implementation_of_mas_v1.0 page 2 of 79 document...

WatERP

Water Enhanced Resource Planning

“Where water supply meets demand”

GA number: 318603

WP 7: Pilots

D7.2.2: Implementation of MAS

V1.0 302926 30/04/2014

www.waterp-fp7.eu

http://www.waterp-fp7.eu/

Ref. 318603 - WatERP, D7.2.2_Implementation_of_MAS_v1.0 page 2 of 79

Document Information

Project Number 318603 Acronym WatERP

Full title Water Enhanced Resource Planning “Where water supply meets demand”

Project URL http://www.waterp-fp7.eu

Project officer Grazyna Wojcieszko

Deliverable Number 7.2.2 Title Implementation of MAS

Work Package Number 7 Title Pilots

Date of delivery Contractual M18 Actual M19

Nature Prototype Report X Dissemination Other

Dissemination

Level Public Consortium X

Responsible Author Gabriel Anzaldi Email [email protected]

Partner BDIGITAL Phone (+34) 973 193 660

Abstract

(for dissemination)

WatERP SOA-MAS architecture represents the main interaction channel between the OMP, the

pilot instantiation and integrated services available in the WatERP framework. The MAS

subsystem of this architecture provides autonomous processes to manage services orchestration

and discovery. This deliverable analyses the requirements to build a subset of the MAS

subsystem that has to be implemented once the milestone MS5 “Second vertical integration” is

reached. Hence, agent types, agents, goals, beliefs and exchanges are identified during the

document providing the necessary schemas to implement this part of the SOA-MAS architecture.

Key words matchmaking, multi-agent system, MAS-CommonKADS, SOA-MAS

mailto:[email protected]


Glossary of terms

BDI Belief Desire Intention

DF Directory Facilitator

DMS Demand Management System

DSS Decision Support System

Dx.x Deliverable x.x

FIPA –ACL FIPA Agent Communication

Language

FIPA Foundation for Intelligent Physical Agents

HF Hydrological Forecast MAS Multi Agent System

MSC Message Sequence Charts

OGC® Open Geospatial Consortium OMP Open Management Platform

SOA Services Oriented Architecture

SOS Sensor Observation Service SPARQL Protocol And RDF Query Language UML Unified Modeling Language URL Unified Resource Locator WDW Water Data Warehouse WP Work Package WPS Web Processing Service


Executive Summary

Deliverable 7.2.2 (D7.2.2) describes the part of the WatERP SOA-MAS architecture related to the Multi-

agent systems (MAS), particularly its aim and scope. This deliverable is the second one of a series of

documents that extends from M3 to M30 and follows the user in the loop strategy in the WatERP project

throughout successive deliverables. Additionally, this document focuses in the MAS implementation

planned for the MS5 ”Second Vertical Integration” milestone (M12 – M24) due in month 23 (August

2014).

Firstly, a short description of the objectives defined for the vertical integrations of the project is offered.

After, the document is focused on a new iteration to the MAS-CommonKADS methodology which was

presented on the D7.2.1 “Implementation of MAS” for the second vertical integration requirements. The

MAS-CommonKADS methodology is divided in three phases, namely: (i) conceptualisation phase; (ii)

analysis phase; and (iii) design phase.

On the first phase (conceptualization phase) the actors and user stories are identified and analysed. It

is important to remark that five new actors were identified during the second vertical integration which

are: (i) ‘OGC® WPS’ actor; (ii) ‘OGC® WPS HF’ actor; (iii) ‘OGC® WPS DMS’ actor, (iv) ‘OGC® WPS

DSS’ and (v) ‘OGC® SOS’ actor. Moreover the new user stories are: (i) ‘OGC® WPS’ server

integration; (ii) unregister ‘OGC® WPS’ server; (iii) consult a hydrological forecast; (iv) consult a

demand forecast; (v) consult water resource allocation recommendations; and (vi) consult pump

scheduling recommendations.

Moreover, the following internal agents were identified as necessary for the second vertical integration

during the analysis phase: (i) ‘OGC® WPS’ who manages the classification of the ‘OGC® WPS’ server

integrated in to HF, DMS or DSS OGC® WPS; (ii) ‘OGC® WPS HF’; (iii) ‘OGC® WPS DMS’ and (iv)

‘OGC® WPS DMS’. The ‘OGC® WPS HF’, ‘OGC® WPS DMS’ and ‘OGC® WPS DMS’ are specific

agents responsible of managing the classified ‘OGC® WPS’ servers publishing its runnable processes

on the ontology and managing the execution of them. Additionally, a functional decomposition of the

system describing the tasks performed is provided. This decomposition is useful to identify the

conversations between agents, and to define the communication scenarios and message processing

state diagrams. Issues related to the network agents are depicted on the design phase.

Finally, the conclusions and future work are presented on the last section.

To understand this document the following deliverables have to be read.

Number Title Description

D1.3 Generic Ontology for water

supply distribution chain

This deliverable summarizes the ontology including the scope, purpose and

implementation language to be used.

D1.4.1 Extension of taxonomy and Description of the improvements performed onto the WatERP general


ontology to the pilots ontology and taxonomy based on pilots’ data information.

D1.4.2 Extension of taxonomy and

ontology to the pilots

Description of the improvements performed onto the WatERP general

ontology and taxonomy based on pilots’ data information.

D2.2 Activity Plan for Work on

Standards

This delivery is an activity plan for the WatERP project is devised which

shall guide all project activities in this direction. As a main focus, it is aimed

at implementing, testing and extending the WaterML2.0 standard of the

Open Geospatial Consortium (OGC®).

D2.3 Open Interface

Specification

This document describes the analysis of the building blocks and the pilots’

interfaces in order to understand the general open interface requirements

for system integration and interoperability within the WatERP project. The

guidelines to integrate a system in the WatERP framework are also

described. It also includes the definition of the system integration road-map.

D3.3 WDW 2nd Prototype Description of the implementation, installation and usage of the Water Data

Warehouse.

D6.1

Open platform

requirements and

functionalities description

This deliverable summarizes the Open Management Platform (OMP)

including the requirements needed to define a tool able to represent and

manage different scenarios represented by ontologies instantiations,

exposing only those variables that are relevant for the selected category,

enable performing "what-if" analysis based on Decision Support System

(DSS) services, and presenting the information in a comparable and

understandable way.

D7.2.1 Implementation of MAS

This deliverable analyses the requirements to build a subset of the MAS

subsystem that was to be implemented once the milestone MS3 “First

vertical integration” was reached. Hence, agent types, agents, goals, beliefs

and exchanges were identified during the document providing the

necessary schemas to implement this part of the SOA-MAS architecture.

Moreover, different studies about methodologies to develop multi-agent

systems was studied concluding that MAS-CommonKADS methodology is

the most suitable to be applied in WatERP MAS design.


Table of contents

1. INTRODUCTION ............................................................................................................................. 11

2. CONCEPTUALIZATION PHASE .................................................................................................... 12

2.1 IDENTIFICATION OF THE ACTORS .................................................................................................................. 12

2.2 DESCRIPTION OF THE ACTORS ..................................................................................................................... 12

2.3 IDENTIFICATION OF USER STORIES ............................................................................................................... 13

2.4 DESCRIPTION OF USER STORIES .................................................................................................................. 14

2.4.1 ‘OGC® WPS server integration (Hydrological Forecast, DSS and DMS)’ user story ......................... 16

2.4.2 ‘Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ user story.......................... 19

2.4.3 ‘Request a hydrological forecast’ user story ....................................................................................... 19

2.4.4 ‘Request a demand forecast’ user story ............................................................................................. 20

2.4.5 ‘Request water resources allocation’ user story ................................................................................. 23

2.4.6 ‘Request pumping schedule’ user story .............................................................................................. 26

3. ANALYSIS PHASE ......................................................................................................................... 29

3.1 SOFTWARE AGENT IDENTIFICATION .............................................................................................................. 29

3.2 TASK MODELLING ....................................................................................................................................... 30

3.3 SOFTWARE AGENT IDENTIFICATION – SECOND ROUND .................................................................................... 44

3.4 COORDINATION MODELLING ........................................................................................................................ 47

3.4.1 Conversations .................................................................................................................................... 47

3.4.2 Scenarios ........................................................................................................................................... 57

3.4.3 Message processing state diagrams .................................................................................................. 70

3.5 ORGANIZATION MODELLING ......................................................................................................................... 75

4. DESIGN PHASE ............................................................................................................................. 76

5. CONCLUSIONS AND FUTURE WORK ......................................................................................... 78


Table of figures

FIGURE 1: “OVERVIEW OF THE USER STORIES” ............................................................................................................... 16

FIGURE 2: “’OGC® WPS SERVER INTEGRATION (HYDROLOGICAL FORECAST, DSS AND DMS)’ INTERACTIONS” .................. 18

FIGURE 3: “’UNREGISTER OGC® WPS SERVER (HYDROLOGICAL FORECAST, DSS AND DMS)’ INTERACTIONS” .................. 19

FIGURE 4: “’REQUEST A HYDROLOGICAL FORECAST’ INTERACTIONS” ................................................................................. 20

FIGURE 5: “’REQUEST A DEMAND FORECAST’ INTERACTION” ............................................................................................. 22

FIGURE 6: “’REQUEST WATER ALLOCATION’ INTERACTIONS (1/2)” ..................................................................................... 24

FIGURE 7: “’REQUEST WATER ALLOCATION’ INTERACTIONS (2/2)” .................................................................................... 25

FIGURE 8: “’REQUEST PUMPING SCHEDULE’ INTERACTIONS (1/2)” .................................................................................... 27

FIGURE 9: “REQUEST PUMPING SCHEDULE’ INTERACTIONS (2/2)” ..................................................................................... 28

FIGURE 10: “TASK DECOMPOSITION FOR ‘REGISTER OGC® WPS SERVER” ..................................................................... 31

FIGURE 11: “TASK DECOMPOSITION FOR ‘OGC® WPS PROCESSES ANALYSIS’” ................................................................ 32

FIGURE 12: “TASK DECOMPOSITION FOR ‘UNREGISTER OGC® WPS SERVER” ................................................................. 33

FIGURE 13: “TASK DECOMPOSITION FOR ‘GET AVAILABLE HYDROLOGICAL FORECAST PROCESSES” ...................................... 33

FIGURE 14: “TASK DECOMPOSITION FOR ‘CONSULT HYDROLOGICAL FORECAST” ................................................................ 34

FIGURE 15: “TASK DECOMPOSITION FOR ‘GET AVAILABLE DEMAND FORECAST PROCESSES” ................................................ 34

FIGURE 16: “TASK DECOMPOSITION FOR ‘GET WATER RESOURCES OF A TYPE” .................................................................. 34

FIGURE 17: “TASK DECOMPOSITION FOR ‘EXECUTE A DEMAND FORECAST’” ........................................................................ 35

FIGURE 18: “TASK DECOMPOSITION FOR ‘GET AVAILABLE WATER ALLOCATION PROCESSES’” ............................................... 35

FIGURE 19: “TASK DECOMPOSITION FOR ‘GET CURRENT SCENARIO STATE’” ....................................................................... 36

FIGURE 20: “TASK DECOMPOSITION FOR ‘GET BEHAVIOUR’” ............................................................................................. 36

FIGURE 21: “TASK DECOMPOSITION FOR ‘SET BEHAVIOUR’” ............................................................................................. 37

FIGURE 22: “TASK DECOMPOSITION FOR ‘GET WATER ALLOCATION RECOMMENDATIONS’”.................................................... 37

FIGURE 23: “TASK DECOMPOSITION FOR ‘GET PUMP SCHEDULING RECOMMENDATIONS’” ..................................................... 38

FIGURE 24: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN OGC® WPS SERVER” ..................................................... 57

FIGURE 25: “INTERACTIONS BETWEEN AGENTS TO DESTROY AN OGC® WPS AGENT” ....................................................... 57

FIGURE 26: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN OGC® WPS HF SERVER” ............................................... 58

FIGURE 27: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN OGC® WPS DMS SERVER” ............................................ 58

FIGURE 28: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN OGC® WPS DSS SERVER”............................................. 59

FIGURE 29: “INTERACTIONS BETWEEN AGENTS TO UNREGISTER AN OGC® WPS HF SERVER” ........................................... 59


FIGURE 30: “INTERACTIONS BETWEEN AGENTS TO DESTROY AN OGC® WPS HF SERVER” ................................................ 60

FIGURE 31: “INTERACTIONS BETWEEN AGENTS TO UNREGISTER AN OGC® WPS DMS SERVER” ........................................ 60

FIGURE 32: “INTERACTIONS BETWEEN AGENTS TO DESTROY AN OGC® WPS DMS AGENT”............................................... 60

FIGURE 33: “INTERACTIONS BETWEEN AGENTS TO UNREGISTER AN OGC® WPS DSS SERVER”......................................... 61

FIGURE 34: “INTERACTIONS BETWEEN AGENTS TO DESTROY AN OGC® WPS DSS AGENT” ............................................... 61

FIGURE 35: “INTERACTIONS BETWEEN AGENTS TO GET AVAILABLE OGC® WPS HF PROCESSES” ....................................... 62

FIGURE 36: “INTERACTIONS BETWEEN AGENTS TO EXECUTE HYDROLOGICAL FORECAST PROCESS” ...................................... 62

FIGURE 37: “INTERACTIONS BETWEEN AGENTS TO GET OGC® WPS DMS PROCESSES” ................................................... 62

FIGURE 38: “INTERACTIONS BETWEEN AGENTS TO GET WATER RESOURCES” ..................................................................... 63

FIGURE 39: “INTERACTIONS BETWEEN AGENTS TO EXECUTE A DEMAND FORECAST PROCESS” ............................................. 63

FIGURE 40: “INTERACTIONS BETWEEN AGENTS TO GET CURRENT STATE SCENARIO PROCESSES” ......................................... 64

FIGURE 41: “INTERACTIONS BETWEEN AGENTS TO EXECUTE A DEMAND FORECAST PROCESS” ............................................. 64

FIGURE 42: “INTERACTIONS BETWEEN AGENTS TO GET BEHAVIOUR” ................................................................................. 65

FIGURE 43: “INTERACTIONS BETWEEN AGENTS TO SET BEHAVIOUR” .................................................................................. 65

FIGURE 44: “INTERACTIONS BETWEEN AGENTS TO GET WATER ALLOCATION RECOMMENDATIONS PROCESSES”...................... 65

FIGURE 45: “INTERACTIONS BETWEEN AGENTS TO EXECUTE WATER ALLOCATION RECOMMENDATIONS PROCESS” .................. 66

FIGURE 46: “INTERACTIONS BETWEEN AGENTS TO GET PUMP SCHEDULING PROCESSES”..................................................... 66

FIGURE 47: “INTERACTIONS BETWEEN AGENTS TO EXECUTE PUMP SCHEDULING PROCESS” ................................................. 67

FIGURE 48: “INTERACTIONS BETWEEN AGENTS TO GET ‘VALIDATE PUMP SCHEDULING’ PROCESSES” ..................................... 67

FIGURE 49: “INTERACTIONS BETWEEN AGENTS TO EXECUTE ‘VALIDATE PUMP SCHEDULING’ PROCESS” ................................. 68

FIGURE 50: “INITIAL INTERACTION DIAGRAM AMONG AGENTS IN THE SECOND VERTICAL INTEGRATION OF MAS” ..................... 69

FIGURE 51: “MESSAGE PROCESSING STATE DIAGRAM REFERRING OGC® WPS INTEGRATION” ........................................... 71

FIGURE 52: “MESSAGE PROCESSING STATE DIAGRAM REFERRING THE PROCESSES MANAGEMENT” ...................................... 73

FIGURE 53: “MESSAGE PROCESSING STATE DIAGRAM REFERRING THE ONTOLOGY ISSUES” ................................................. 74

FIGURE 54: “AGENTS HIERARCHY” ................................................................................................................................ 76

FIGURE 55: "REGISTER OF A SERVICE ON THE DIRECTORY FACILITATOR" .......................................................................... 77

FIGURE 56: "SEARCH OF A SERVICE ON DIRECTORY FACILITATOR" .................................................................................. 77


Table of tables

TABLE 1: "MAS IMPLEMENTATION ITERATIVE DELIVERABLES" ........................................................................................... 11

TABLE 2: "MAS RELEASES" ......................................................................................................................................... 11

TABLE 3: “ACTORS INVOLVED IN THE MAS” ................................................................................................................... 13

TABLE 4: “USER STORIES INVOLVED IN THE MAS” .......................................................................................................... 14

TABLE 5: “‘OGC® WPS SERVER INTEGRATION (HYDROLOGICAL FORECAST, DSS AND DMS)’ USER STORY DESCRIPTION” .. 17

TABLE 6: “‘UNREGISTER OGC® WPS SERVER (HYDROLOGICAL FORECAST, DSS AND DMS)’ USER STORY DESCRIPTION” ... 19

TABLE 7: “’CONSULT HYDROLOGICAL FORECAST’ USER STORY DESCRIPTION” .................................................................... 20

TABLE 8: “’REQUEST A DEMAND FORECAST’ USER STORY DESCRIPTION” ........................................................................... 21

TABLE 9: “’REQUEST WATER ALLOCATION’ USER STORY DESCRIPTION” ............................................................................. 23

TABLE 10: “‘REQUEST PUMPING SCHEDULE’ USER STORY DESCRIPTION” ........................................................................... 26

TABLE 11: “FIRST DRAFT OF IDENTIFIED AGENTS” ........................................................................................................... 30

TABLE 12: “TASK ‘REGISTER OGC® WPS SERVER’ DESCRIPTION” .................................................................................. 39

TABLE 13: “TASK ‘REGISTER OGC® WPS PROCESSES ANALYSIS’ DESCRIPTION” ............................................................. 39

TABLE 14: "TASK ‘UNREGISTER OGC® WPS SERVER (HYDROLOGICAL FORECAST, DSS AND DMS)’ DESCRIPTION" ........... 40

TABLE 15: "TASK ‘GET AVAILABLE HYDROLOGICAL FORECAST PROCESSES’ DESCRIPTION” .................................................. 40

TABLE 16: “TASK ‘EXECUTE HYDROLOGICAL FORECAST PROCESS’ DESCRIPTION” .............................................................. 40

TABLE 17: “TASK ‘GET AVAILABLE DEMAND FORECAST PROCESSES’ DESCRIPTION” ............................................................ 41

TABLE 18: “TASK ‘GET WATER RESOURCES OF A TYPE’ DESCRIPTION” .............................................................................. 41

TABLE 19: “TASK ‘EXECUTE A DEMAND FORECAST’ DESCRIPTION” .................................................................................... 41

TABLE 20: “TASK ‘GET AVAILABLE WATER ALLOCATION PROCESS’ DESCRIPTION” ............................................................... 42

TABLE 21: “TASK ‘GET CURRENT SCENARIO STATE’ DESCRIPTION” .................................................................................... 42

TABLE 22: “TASK ‘GET BEHAVIOUR’ DESCRIPTION” ......................................................................................................... 43

TABLE 23: “TASK ‘SET BEHAVIOUR’ DESCRIPTION” .......................................................................................................... 43

TABLE 24: “TASK ‘GET WATER ALLOCATION RECOMMENDATIONS’ DESCRIPTION” ................................................................ 43

TABLE 25: “TASK ‘GET PUMP SCHEDULING RECOMMENDATIONS’ DESCRIPTION” ................................................................. 44

TABLE 26: “TASK-AGENTS DISTRIBUTION ROUND 1” ........................................................................................................ 46

TABLE 27: “TASK-AGENTS DISTRIBUTION ROUND 2” ........................................................................................................ 47

TABLE 28: “‘INTEGRATE AN OGC® WPS SERVER’ CONVERSATION” ................................................................................. 48

TABLE 29: “‘DESTROY OGC® WPS AGENT’ CONVERSATION” ......................................................................................... 48


TABLE 30: “‘REGISTER AN OGC® WPS HF SERVER’ CONVERSATION” ............................................................................. 49

TABLE 31: “’REGISTER AN OGC® WPS DMS SERVER’ CONVERSATION” ......................................................................... 49

TABLE 32: “’REGISTER AN OGC® WPS DSS SERVER’ CONVERSATION" .......................................................................... 49

TABLE 33: “‘UNREGISTER AN OGC® WPS HF SERVER’ CONVERSATION” ......................................................................... 50

TABLE 34: “‘DESTROY OGC® WPS HF AGENT’ CONVERSATION” .................................................................................... 50

TABLE 35: “‘UNREGISTER AN OGC® WPS DMS SERVER’ CONVERSATION” ..................................................................... 50

TABLE 36: “‘DESTROY OGC® WPS DMS AGENT’ CONVERSATION” ................................................................................. 51

TABLE 37: “‘UNREGISTER AN OGC® WPS DSS SERVER’ CONVERSATION” ...................................................................... 51

TABLE 38: “‘DESTROY OGC® WPS DSS AGENT’ CONVERSATION” ................................................................................. 51

TABLE 39: “’GET HYDROLOGICAL FORECAST PROCESSES’ CONVERSATION” ....................................................................... 52

TABLE 40: “‘EXECUTE HYDROLOGICAL FORECAST PROCESS’ CONVERSATION”.................................................................... 52

TABLE 41: “’GET DEMAND FORECAST PROCESSES’ CONVERSATION” ................................................................................. 52

TABLE 42: “‘GET WATER RESOURCES’ CONVERSATION” ................................................................................................... 53

TABLE 43: “‘EXECUTE HYDROLOGICAL FORECAST PROCESS’ CONVERSATION”.................................................................... 53

TABLE 44: “’GET CURRENT STATE SCENARIO PROCESSES’ CONVERSATION” ...................................................................... 53

TABLE 45: “‘EXECUTE CURRENT STATE SCENARIO PROCESS’ CONVERSATION” ................................................................... 54

TABLE 46: “’GET BEHAVIOUR’ CONVERSATION” ............................................................................................................... 54

TABLE 47: “’SET BEHAVIOUR’ CONVERSATION” ............................................................................................................... 54

TABLE 48: “’GET WATER ALLOCATION RECOMMENDATIONS PROCESSES’ CONVERSATION” ................................................... 55

TABLE 49: “‘EXECUTE WATER ALLOCATION RECOMMENDATIONS PROCESS’ CONVERSATION” ............................................... 55

TABLE 50: “’GET PUMP SCHEDULING PROCESSES’ CONVERSATION” .................................................................................. 55

TABLE 51: “‘EXECUTE PUMP SCHEDULING PROCESS’ CONVERSATION” .............................................................................. 56

TABLE 52: “’GET VALIDATE PUMP SCHEDULING PROCESSES’ CONVERSATION” .................................................................... 56

TABLE 53: “‘EXECUTE VALIDATE PUMP SCHEDULING PROCESS’ CONVERSATION” ................................................................ 56


1. Introduction

WatERP platform releases are based on vertical integration milestones, which define the expected

status of the development of the services (building blocks), verify the overall project progress, and

evaluate the solution reached. The MAS releases are organized accordingly and documented in several

deliverables during the project evolvement as shown in the following table:

Deliverable Month

D7.2.1 Implementation of MAS M9



Table 1: "MAS implementation iterative deliverables"

Milestone Month

MS3 First Vertical Integration M12

MS5 Second Vertical Integration M23

MS6 Third Vertical Integration M30

Table 2: "MAS releases"

The first prototype of the MAS, which was described in the deliverable (D7.2.1 “Implementation of

MAS”), essentially covered the integration of the OMP and the ontology inside the MAS platform.

Moreover, this first version of the deliverable presented an overview of the agents and multi agents’

technologies previously used in the water domain with a general introduction to matchmaking. Also, the

main concepts and the different types of agents were defined and analysed, concluding that the utility-

based agents was the most suitable for the development of the WatERP SOA-MAS architecture using

the BDI model. Additionally, different methodologies to develop multi-agent systems were studied

concluding that the MAS-CommonKADS methodology (See D7.2.1 “Implementation of MAS” section

3.2) was the most suitable to be applied on the WatERP MAS design since it supports most of the

utility-based BDI agents’ characteristics.

The MAS-CommonKADS methodology is also applied in the current version of the deliverable (See

D7.2.1 “Implementation of MAS” in Section 4) to implement the second prototype of the MAS that will

be finished for the MS5 Second Vertical Integration (M23, August 2014). This second prototype will

integrate new building blocks on the WatERP framework. These building blocks are classified in two

types: (i) internal (DMS and DSS) and (ii) external (hydrological forecast).

This document has been structured following the MAS-CommonKADS methodology steps. Hence the

conceptualization phase is carried out in Section 2, and is divided in four steps: (i) identify the actors; (ii)

describe the actors; (iii) identify the user stories and (iv) describe the user stories. Afterwards, Section 3

reviews the analysis phase which is based on the following tasks: (i) identify the software agents; (ii)

model the tasks; (iii) identify the software agents (second round); (iv) model the coordination between


agents describing the conversations, scenarios and messages processing state diagrams; and (v)

model the organization. As the last step of the methodology, the Section 4 presents the results of the

design phase focusing on the network agents’ identification where the ‘yellow pages’ agent

functionalities have been modified respect the previous deliverable (D7.2.1 “Implementation of MAS”) .

Finally, Section 5 presents the conclusions and future work.

2. Conceptualization phase

The objective of the conceptualisation phase is to analyse the problem from the point of view of the

system user and elaborate a first outline of the solution by following the next steps: (i) identification of

the actors; (ii) description of the actors; (iii) identification of the user stories and (iv) description of the

user stories.

2.1 Identification of the actors

The aim of this task is to identify the actors involved in the system. In the previous deliverable (D7.2.1

“Implementation of MAS” in Section 4.1.1), the identified actors corresponds with the ‘OMP’ and the

‘Sesame’ actors. The ‘OMP’ actor represents the water resource manager that interacts with the

WatERP platform in order to make better decisions. Referring to the Sesame actor, it represents the

triple store of the WDW and provides all ontological functionalities to the WatERP platform.

The current work relies on enhancing the identification of the previous actors with the incorporation of

the DSS, DMS and HF building blocks must to be integrated by the Second Vertical Integration

milestone. Therefore, each of these building blocks is represented by an actor because they are

external software which interacts with the MAS. Moreover, data observations are stored in a relational

database and not in the ontology (See D3.3 “WDW Second prototype” in Section 2 Figure 2 “WDW

Component Layers”) and they are provided through the OGC® SOS and not through the ontology as it

was initially planned in deliverable D7.2.1 “Implementation of MAS”. Therefore, a new actor to manage

the ‘OGC® SOS’ server must to be considered.

As a conclusion, the new actors involved in the second iteration of the MAS-CommonKADS are: (i)

‘OGC® WPS HF’ who represents the hydrological forecasts systems integrated on the MAS through the

‘OGC® WPS’; (ii) ‘OGC® WPS DSS’ who represents the decision supports systems integrated on the

MAS through the ‘OGC® WPS’; (iii) ‘OGC® WPS DMS’ who represents the demand management

systems integrated in the MAS through the ‘OGC® WPS’ and (iv) ‘OGC® SOS’ who represents the

‘OGC® SOS’ server integrated in the MAS.

2.2 Description of the actors

The second step of the conceptualization phase is focused on the depiction of the actors using textual

templates containing the name and the description of each one. Moreover, the actors are classified as


passive or active. A passive actor only participates in a user story, but does not initiate it. Instead, an

active actor is the one who can initiate a user story.

Table 3 shows the type and description of the identified actors during the first (dark grey background in

the table) and second (white background in the table) evaluation of the MAS-CommonKADS. It is

important to remark that all the actors identified during the second iteration are passive actors; hence

they do not initiate user stories.

N. Actor Actor Type actor Description

1 OMP Active

The OMP is the platform used by the water manager in order to get

advice to decision-making about water allocation and energy

management

2 Sesame Passive

The logical model is an ontological instantiation and contains all the

information regarding the logical model such as the water resources,

their relations, water resource type, features of interest, observations,

etc.

3 OGC® SOS Passive Represents a ‘OGC® SOS’ server that is able to provide the available

observations and their data (it is part of the WDW)

4 OGC® WPS HF Passive

Represents an ‘OGC® WPS’ server of the hydrological forecast type

that is capable of generating hydrological forecast such as temperature

forecast, rainfall forecast, etc… Moreover, this server follows the

guidelines presented in D2.3 “Open interface Specification” in Section

3.2.

5 OGC® WPS

DMS Passive

Represents an ‘OGC® WPS’ server of the demand forecast type that is

capable of generating demand forecasts for the sink water resources.

Moreover, this server follows the guidelines presented in the D2.3

“Open interface Specification” in Section 3.2.

6 OGC® WPS

DSS Passive

Represents an ‘OGC® WPS’ of the decision support type that is

capable of generating water allocation recommendations, pump

scheduling recommendations, validate pump scheduling

recommendations, etc… Moreover, this server follows the guidelines

presented in the D2.3 “Open interface Specification” in Section 3.2.

Table 3: “Actors involved in the MAS”

2.3 Identification of user stories

This section is focused on the identification of the user stories and the actor who initiates them. To

identify them, the software engineering best practices presented in D7.2.1 “Implementation of MAS”

Section 4.1.3 has been used. Only active actors are taken into account since the passive actors cannot

initiate user stories. Moreover, the information presented in D6.2 “Open Management Platform” has

been used to identify the MAS user stories related to the OMP. This document explains the features

provided by the OMP, which must be considered as user stories.


The new user stories identified during the second iteration of the MAS development are aligned with the

‘OMP’ actor because it is the unique active actor. Table 4 contains the list of the user stories identified

during the first iteration (grey background) and the new user stories identified during the second

iteration (white background) of the MAS development which are: (i) ‘OGC® WPS’ server integration

(Hydrological Forecast, DSS and DMS); (ii) unregister ‘OGC® WPS’ server (Hydrological Forecast,

DSS and DMS); (iii) consult a hydrological forecast; (iv) consult a demand forecast; (v) consult water

resources allocation and (vi) consult a pump scheduling.

Referring to the new stories, the addition of new actors on the second vertical integration such as

‘OGC® SOS’, ‘OGC® WPS HF’, ‘OGC® WPS DSS’ and ‘OGC® WPS DMS’ give new possibilities to

the use of the WatERP framework. For instance, from the point of view of the building blocks

management, both the user story to integrate the new ‘OGC® WPS’ server in the WatERP platform and

the user story to unregister an ‘OGC® WPS’ server from the platform if no longer useful are essential.

Moreover, user stories to query the hydrological forecast, demand forecast, water resources allocation

and pump scheduling must be provided. These user stories will be depicted in the Section 2.4.

N. Actor Actor User stories

1 OMP

Obtain available logical models in WatERP framework

Obtain structure of a logical model

Obtain available observations for a feature of interest

Obtain available features of interest for a water resource

Add new logical model in WatERP framework

Remove logical model of WatERP framework

‘OGC® WPS’ server integration (Hydrological Forecast, DSS and DMS)

Unregister ‘OGC® WPS’ server (Hydrological Forecast, DSS and DMS)

Consult a hydrological forecast

Consult a demand forecast

Consult water resources allocation

Consult a pump scheduling

Table 4: “User stories involved in the MAS”

2.4 Description of user stories

The aim of this section is to analyse each user story presented in Table 4 of Section 2.3. First, the user

stories overview is shown; including a case diagram UML model to describe the relations between user

stories and actors. Later, a textual and graphical description for each user story is provided to improve

the understanding of each case. This textual and graphical description is based on the user stories

listed in Table 4 of Section 2.3. On the one hand, a table with the following fields is used to present the

textual description: (i) the story name which is used to identify user story; (ii) a brief summary of the

user story; (iii) the actors involved in the user story; (iv) the pre-conditions needed to initiate the user


story; (v) a description of the steps of the user story; (vi) the exceptions occurring in the user story and

(vii) the post-conditions of the system after executing the user story. On the other hand, the graphical

description is presented using MSC (Message Sequence Charts) notation and shows the interactions

between the actors and the MAS. The rectangle with the word “alt” at the top-left corner indicates that

the process can take two different paths which are separated by a dotted line.

Figure 1 presents the summary of the developed user stories developed during the first vertical

integration (grey background) and the user stories to be developed until the second vertical integration

milestone (white background). The ‘OGC® WPS Server integration (HF, DSS and DMS)’ user story is

initiated by OMP and it requires interacting, firstly with ‘OGC® WPS’ actor in order to detect the type of

‘OGC® WPS’ integrated (‘OGC® WPS DMS’ actor, ‘OGC® WPS DSS’ actor, or ‘OGC® WPS HF’

actor) The other ‘OGC® WPS’ management operation, ‘unregister OGC® WPS Server (HF, DSS and

DMS’), does not require any interaction with an actor because the unregister operation is managed

internally by the MAS.

The rest of the user stories such as ‘consult pump scheduling’, ‘consult a hydrological forecast’, ‘consult

a demand forecast’ and ‘consult water resources allocation’ represent the daily operation that a water

manager will do through the WatERP platform.

The first user story related with the daily operations (‘consult pump scheduling’) interacts with the

‘Sesame’ actor, ‘OGC® WPS HF’ actor, ‘OGC® WPS DMS’ actor and ‘OGC® WPS DSS’ actor. Other

daily operation’s user story is ‘consult a demand forecast’, which interacts with the ‘Sesame’ actor,

‘OGC® WPS HF’ actor and ‘OGC® WPS DMS’ actor. Instead, the third user story (‘consult a

hydrological forecast’) invokes the ‘OGC® WPS HF’ actor only. Finally, the last user story involved in

the daily operation (‘consult water resources allocation’) interacts with ‘Sesame’ actor, ‘OGC® WPS HF’

actor, ‘OGC® WPS DMS’ actor and ‘OGC® WPS DSS’ actor.

The main actors’ responsibilities are: (i) recover the ontological information from the pilot instantiation

(‘Sesame’ actor); (ii) obtain the forecasted temperature and rainfall which is essential to calculate the

demand (‘OGC® WPS HF’ actor); (iii) provide demand forecasts for the sinks involved in the pilot

instantiations (‘OGC® WPS DMS’ actor); (iv) generate pumping scheduled based on the observations

and the demand forecast, or the water allocation (‘OGC® WPS DSS’ actor) and (v) recover the data

observations of the pilot instantiation (‘OGC® SOS’ actor).


Figure 1: “Overview of the user stories”

2.4.1 ‘OGC® WPS server integration (Hydrological Forecast, DSS and DMS)’ user

story

N. User Story 1

User Story ‘OGC® WPS’ server integration

Summary Integration of ‘OGC® WPS’ server on the WatERP framework with the aim of reusing its

capabilities on WatERP.

Actors OMP, OGC® WPS, Hydrological Forecast, DSS, DMS

Pre-conditions

‘OGC® WPS’ server complies with the OGC® standards and is enriched with semantic

annotations based on the WatERP ontology (See D2.3 “Open Interface Specification” in

Section 3.3.2)


Description

The MAS receives an OGC® WPS integration request from the OMP with the URL of the

‘OGC® WPS’ server to be integrated as input parameter. Then, the MAS evaluates the ‘OGC®

WPS‘ server in order to know the OGC® WPS type (Hydrological Forecast, DSS or DMS). The

next step, after deducting the type of OGC® WPS to be integrated is to analyse the capabilities

of the server in order to acquire them. Finally, the MAS tells the OMP if the ‘OGC® WPS’

server has been successfully integrated.

Exceptions

The URL does not point to a valid ‘OGC® WPS’ server.

The URL has been already registered.

The ‘OGC® WPS’ server does not provide semantic annotations to identify the OGC® WPS

type.

The OGC® WPS type is not supported by the MAS.

Post-conditions The ‘OGC® WPS’ server is integrated on the WatERP framework. Therefore, its features are

ready to be executed in WatERP.

Table 5: “‘OGC® WPS server integration (Hydrological Forecast, DSS and DMS)’ user story description”


Figure 2: “’OGC® WPS server integration (Hydrological Forecast, DSS and DMS)’ interactions”

alt response(registered)

fail(cause)

alt

OMP actor MAS

registerOGCWPS(url OGC WPS)

OGC WPS

actor

analyseOGCWPS()

OGC WPS HF

actor

response(service information)

OGC WPS

DMS actor

OGC WPS

DSS actor

analyseOGCWPSHF()

response(capabilities)

analyseOGCWPSDMS()


analyseOGCWPSDSS()



2.4.2 ‘Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ user

story

N. User Story 2

User Story Unregister ‘OGC® WPS’ server from the WatERP

Summary Unregistering of a ‘OGC® WPS’ server from the WatERP framework

Actors OMP

Pre-conditions The ‘OGC® WPS’ server is integrated on the WatERP framework

Description

The MAS receives an OGC® WPS unregister request from the OMP with the URL of the

‘OGC® WPS’ server to be taken out as input parameter. Then, the MAS unregisters the

‘OGC® WPS’ server and tells to the OMP if the ‘OGC® WPS’ server have been successfully

unregistered.

Exceptions The URL is not already registered in the WatERP framework.

Post-conditions The ‘OGC® WPS’ server is unlinked to the WatERP framework. Therefore, its capabilities are

taken out and are no longer accessible in the WatERP framework.

Table 6: “‘Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ user story description”

Figure 3: “’Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ interactions”

2.4.3 ‘Request a hydrological forecast’ user story

This user story is based on Section 2.2.3 of D6.2 “Open Management Platform”.

N. User Story 3

User Story Request a hydrological forecast.

Summary The water manager consults a hydrological forecast.

Actors OMP, Hydrological Forecast.

Pre-conditions At least one ‘OGC® WPS HF’ server that is able to provide a hydrological forecast is integrated

in the WatERP framework.

Description The OMP collects the hydrological forecast processes available in the WatERP framework

and presents this information to the water manager. Then, the water manager selects a

OMP actor MAS

alt

unregister(url OGC WPS)

response()

fail(cause)


hydrological forecast and provides the required input parameters (e.g. the geometry where the

forecast will be produced). When the MAS receives this information, it identifies which of the

integrated ‘OGC® WPS hydrological forecast’ servers is able to execute the query and

manages the execution of the process. Finally, the forecast received by the MAS is returned to

the OMP.

Exceptions The execution of the hydrological forecast thrown an exception.

Post-conditions None.

Table 7: “’Consult hydrological forecast’ user story description”

Figure 4: “’Request a hydrological forecast’ interactions”

2.4.4 ‘Request a demand forecast’ user story

This user story is based on Section 2.2.4 of D6.2 “Open Management Platform”.

N. User Story 4

User Story Request a demand forecast.

Summary The water manager wants to request a demand forecast for a sink.

Actors OMP, OGC® WPS DMS, Sesame, OGC® WPS Hydrological Forecast, OGC® SOS

Pre-conditions

At least one ‘OGC® WPS DMS’ server that is able to provide a demand forecast for a sink is

integrated in the WatERP framework.

A ‘hydrological forecast OGC® WPS’ server that is able to provide the needed data to

calculate the demand is integrated in the WatERP framework.

The Sesame server that provides the logical model is integrated in the WatERP framework.

Description

The OMP collects the demand forecast processes available in the WatERP framework and

presents them to the water manager. In order to execute the demand forecast process, the

OMP gathers all sinks available in the logical model trough the MAS, since a demand forecast

is always associated to a sink and it is required to execute a demand forecast process.

Afterwards, the OMP invokes the process through the MAS and provides the identifier of the

getHFprocesses()

response(HF processes)

OMP actor MASOGC WPS HF

actor

alt

getHF(HF process, geometry)

execute(HF process, geometry)

response(HF)

response(HF)

fail(cause)


process to be executed, the sink where the prediction should to be done, the starting date of

the prediction and the observations required to generate the demand. This call is managed by

the MAS who recovers the essential information to execute the process (e.g. temperature and

rainfall forecast for the sink) and provides it to the ‘DMS OGC® WPS’. Finally, the response

returned by the DMS actor is provided to the OMP.

Exceptions The execution of the hydrological forecast thrown an exception.

The execution of the demand forecast thrown an exception.


Table 8: “’Request a demand forecast’ user story description”


Figure 5: “’Request a demand forecast’ interaction”

alt response(water resources)

fail(cause)

getDFprocesses()

response(DF processes)

OMP actor MASOGC WPS

DMS actor

alt

getDF(DF process, id sink, start date)

execute(DF process, id sink,

start date, HF, observations)

response(DF)

response(DF)

fail(cause)

Sesame actor

getWaterResources(logical model, sink)

getWaterResources(logical model, sink)

response(water resources)

OGC WPS HF

actor

getHF(geometry)

response(HF)

OGC SOS

actor

getObservations([observation id])

response(observations)


2.4.5 ‘Request water resources allocation’ user story

The user story described on this section refers to the Section 2.3.1 “Decision Processes: Supply-

Demand Matching” of D6.2 “Open Management Platform 1st prototype” where the screens related to the

decision-making regarding water resources management to match the supply and demand are

presented.

N. User Story 5

User Story Request the water resources allocation

Summary A water manager uses the tool in order to make decisions regarding the water resources

allocation.

Actors OMP, Sesame, OGC® SOS, OGC® WPS DSS, OGC® WPS DMS, OGC® WPS HF

Pre-conditions

Water allocation processes are integrated in the WatERP platform.

Demand forecast processes are integrated in the WatERP platform.

Hydrological forecast processes are integrated in the WatERP platform.

Description

The OMP recovers the water allocation processes that are available in the WatERP framework

and presents them to the water manager. The source water resources, their most remarkable

observations, and the current state of the pilot instantiation are recovered and presented to the

water manager (dashboard “V018 Defining hydraulic resources status” defined in D6.2 “Open

Management Platform 1st prototype”). In the next step (“V019 Define structural system

characteristics/capacities” defined in D6.2 “Open Management Platform 1st prototype”), the

OMP allows the water manager to modify the pilot instantiation behaviour. To do so, the MAS

previously recovers this behaviour using the ‘Sesame’ actor and updates the WatERP ontology

with the changes made. Once the pilot instantiation behaviour is modified, the demand forecast

for all sinks is presented in the OMP (Dashboard “V020 Demand forecast” defined in D6.2

“Open Management Platform 1st prototype”) in order to inform the water manager. The last

step is the execution of the water allocation process, which generates a water allocation

recommendation for the pilot instantiation. With the aim of carrying out the water allocation

process, the MAS recovers the information regarding the logical model, its behaviour, the

demand forecast for each sink and the observations required to execute the water allocation

process, which is managed by the ‘OGC® WPS DSS’ actor. Finally, the response returned by

the DSS actor is provided to the OMP.

Exceptions

An exception is thrown if the water resources cannot recover for a pilot instantiation.

An exception is thrown if the data of the observations cannot be recovered from the ‘OGC®

SOS’ server.

An exception is thrown if the water allocation process fails.

An exception is thrown if the pilot instantiation behaviour cannot be recovered.

An exception is thrown if the pilot instantiation behaviour cannot be modified.

Post-conditions None

Table 9: “’Request water allocation’ user story description”


Figure 6: “’Request water allocation’ interactions (1/2)”

alt response(water allocation)

fail(cause)

* Repeat user history “Consult a demand

forecast” for each sink

alt response()

fail(cause)

alt

getCurrentBehaviour(logical model id)


response(behaviour)

response(behaviour)

fail(cause)

alt response(observations)

fail(cause)


fail(cause)

OMP actor MAS

getWaterAllocationProcesses(logical model

id)

response(Water allocation processes)

Sesame actor

getWaterResources(logical model id,

source) getWaterResources(logical model id,

source)


OGC SOS actor

getObservations([observation id]) getObservations([observation id])


getCurrentStateScenario(logical model id)

OGC WPS DSS

actor

getCurrentStateScenario(logical model id,

observations)

response(current state scenario)

setCurrentBehaviour(logical model id,

behaviour)setCurrentBehaviour(logical model id,

behaviour)

response()



getCurrentBehaviour()

response(behaviour)

getWaterAllocation(logical model id, water

allocation process ID)

getWaterAlloction(logical model,

observations, behaviour, demand forecast)

response(recommendations)

getLogicalModel(logical model id)

response(logical model)

getObservations(logical model id, id sources)



getWaterAllocationInputRequirements()

response(Input requirements)

getServices(Input requirements)

response(services)


Figure 7: “’Request water allocation’ interactions (2/2)”

alt response(water allocation)

fail(cause)



alt response()

fail(cause)

alt



response(behaviour)

response(behaviour)

fail(cause)


fail(cause)


fail(cause)

OMP actor MAS

getWaterAllocationProcesses(logical model

id)

response(Water allocation processes)

Sesame actor


source) getWaterResources(logical model id,

source)


OGC SOS actor

getObservations(logical model id, id

sources) getObservations(logical model id, id sources)


getCurrentStateScenario(logical model id)

OGC WPS DSS

actor

getCurrentStateScenario(logical model id,

observations)


setCurrentBehaviour(logical model id,

behaviour)setCurrentBehaviour(logical model id,

behaviour)

response()



getCurrentBehaviour()

response(behaviour)

getWaterAllocation(logical model id, water

allocation process ID)

getWaterAlloction(logical model,

observations, behaviour, demand forecast)

response(recommendations)

getLogicalModel(logical model id)

response(logical model)

getObservations(logical model id, id sources)



getWaterAllocationInputRequirements()



response(services)


2.4.6 ‘Request pumping schedule’ user story

N. User Story 8

User Story Request pumping schedule

Summary A water manager uses the tool in order to make decisions regarding the pumping schedule

Actors OMP, Sesame, OGC® SOS, OGC® WPS DSS, OGC® WPS DMS, OGC® WPS HF

Pre-conditions

Pumping schedule processes are integrated in the WatERP platform.

Pump schedule validation processes are integrated in the WatERP platform.

Demand forecast processes are integrated in the WatERP platform.

Hydrological forecast processes are integrated in the WatERP platform.

Description

The first dashboard of the OMP pumping schedule is “V013 Improve Energy Efficiency

Decision Process” dashboard (See D6.2 “Open Management Platform” Section 2.3.2.1), which

presents helpful information of the water resources such as the sources, sinks and storages,

and their observations. Therefore, the OMP gathers the pilot instantiation water resources

(sources, sinks or storages) from the ‘Sesame’ actor and their observations from the ‘OGC®

SOS’ actor. Afterwards, the OMP gathers all available pumping-schedule processes from the

‘Sesame’ actor. These processes are later presented to the water manager through the OMP

in order to select the most appropriated one. Once the pumping schedule process to be

executed has been chosen by the water manager, the MAS must discover: (i) the required

information, which is essential to execute the process; (ii) the services that provide the required

information, and (iii) the agents responsible to manage the services. The ‘Sesame’ actor

provides the information required for the first and second steps, since it contains the WatERP

ontology and therefore knows which are the runnable processes, their inputs and outputs and

the correspondence between runnable process and a service. Finally, correspondence

between service and agent (which is the last needed information), is known by the MAS and

hence it is solved internally without any interaction with an actor. Therefore, with the aim of

executing the pumping schedule process, the MAS recovers the sink water resources and their

demand forecasts. Then, the MAS returns the results of the pumping schedule execution

process to the OMP. There results consist of the current demand forecast, the similar demand

detected by the DSS, and the pump scheduling. To conclude, the pumping schedule proposed

can be modified and validated by the DSS. Hence, an operation to recover the validation

pumping schedule processes and an operation to execute this process are provided.

Exceptions

An exception is thrown if the water resources cannot be gathered for a pilot instantiation.

An exception is thrown if the data of the observations cannot be gathered from the ‘OGC®

SOS’ server.

An exception is thrown if the pumping schedule process fails.

An exception is thrown if the pumping schedule validation process fails.

Post-conditions None

Table 10: “‘Request pumping schedule’ user story description”


Figure 8: “’Request pumping schedule’ interactions (1/2)”

alt response(restrictions, recommendations)

fail(cause)

alt

getPumpScheduling(logical model id)

getPumpShceduling(logical model id,

demand)

response(similar demand,

pump scheduling)

response(demand, similar demand,

pump scheduling)

fail(cause)


fail(cause)


fail(cause)

OMP actor MAS Sesame actor


[source, sink, storage]) getWaterResources(logical model id,

[source, sink, storage])


OGC SOS actor

getObservations(logical model id, [id

sources, id sinks, id storages])getObservations(logical model id,

[id sources, id sinks, id storages])


OGC WPS DSS

actor

getDemand(logical model id,

[id sinks], start date)

response(demand)

validateScheduling(logical model id,

demand, similar demand, pump scheduling)validateScheduling(logical model id, demand,

similar demand, pump scheduling)

response(restrictions, recommendations)

OGC WPS DMS

actor


[sink])


getPumpSchedulingInputRequirements()



response(services)


Figure 9: “Request pumping schedule’ interactions (2/2)”

alt response(restrictions, recommendations)

fail(cause)

alt

getPumpScheduling(logical model id)

getPumpShceduling(logical model id,

demand)

response(similar demand,

pump scheduling)

response(demand, similar demand,

pump scheduling)

fail(cause)


fail(cause)


fail(cause)

OMP actor MAS Sesame actor


[source, sink, storage]) getWaterResources(logical model id,

[source, sink, storage])


OGC SOS actor

getObservations(logical model id, [id

sources, id sinks, id storages])getObservations(logical model id,

[id sources, id sinks, id storages])


OGC WPS DSS

actor

getDemand(logical model id,

[id sinks], start date)

response(demand)

validateScheduling(logical model id,

demand, similar demand, pump scheduling)validateScheduling(logical model id, demand,

similar demand, pump scheduling)

response(restrictions, recommendations)

OGC WPS DMS

actor


[sink])


getPumpSchedulingInputRequirements()



response(services)


3. Analysis phase

The objective of this phase is to identify the agents that participate on the solution of the problem and

understand how they affect the system where they act. The analysis is performed by following the next

steps: (i) software agent identification, where a first draft of the agents model is made; (ii) task

modelling, where agents tasks are identified and described; (iii) software agent identification – second

round, where a revision of agents model is carried out in order to identify improvements; (iv)

coordination modelling, to identify the messages exchange between internal and external agents; and

(v) organization modelling to classify the agents in regards to their static dependencies.

3.1 Software agent identification

This task aims to specify the agent’s characteristics and design the model which to be used as

reference by future agents. The process is based on the methodology presented in D7.2.1

“Implementation of MAS” in Section 4.2.1, where the identification of the agents is done in two steps. In

the first step the user stories (see Section 2.1) are used to obtain the external and internal agents -

internal agents are executed inside the MAS while external agents work outside of the multi-agent

system - that usually correspond to the actors and interfaces used by them inside the system. The

second step which is presented in the Section 3.3 uses the identified task (see Section 3.2) to

complete the identified agents during this section.

Table 11 presents the agents involved in the Second Vertical Integration (white background) extracted

from actors user stories (see Section 2). Moreover, the table contains the agents identified during the

first delivery (dark grey background) of D7.2.1 “Implementation of MAS”. The newly detected agents

are: (i) ‘OGC® SOS’ that is the internal agent responsible for managing the interaction with an ‘OGC®

SOS’ server; (ii) ‘OGC® WPS HF’ that is the internal agent in charge of the interaction with the ‘OGC®

WPS’ agent containing hydrological forecast processes; (iii) ‘OGC® WPS DMS’ agent, that is another

internal agent responsible for interacting with an ‘OGC® WPS’ agent that stores the demand

management processes; and (iv) ‘OGC® WPS DSS’, which is the agent responsible for managing the

‘OGC® WPS’ server that incorporates the decision support processes. All these agents exchange

information with external actors (‘OGC® WPS’ servers), but they are classified as internal. In this case,

the external actors do not insert or modify the MAS goals, mainly because the communication flows

always in one direction, from the internal agents (‘OGC® SOS’, ‘OGC® WPS HF’, ‘OGC® WPS DMS’,

and ‘OGC® WPS DSS’) to the external actors via SOAP.

Finally, it is important to note that this agents’ list constitutes a first approach which can be modified in

future steps where the methodology proposes a new revision of the agents (see Section 3.3).

N.

Agent Agent Type Description


1 OMP

External Human agent who interacts with the system requesting information such

as logical model structure, available features of interest of a node and

available observations of a feature of interest

2 OMP Gateway Internal Software agent who manages all received requests through the OMP

external agent.

3 Sesame Internal Software agent that supervises a logical model and manages the

interaction with it within the WatERP platform.

4 OGC® SOS Internal Software agent who is responsible for managing an OGC® SOS server

for getting observations and provide them to the others agents

5 OGC® WPS HF Internal

Software agent responsible for managing an OGC® WPS HF server and

is able to detect newly inserted hydrological forecast processes that can

be provided as service to be consumed by the rest of the agents

6 OGC® WPS

DMS Internal

Software agent who manages a OGC® WPS DMS server and detects

new inserted demand forecast processes to be made available to the rest

of the agents as a service

7 OGC® WPS

DSS Internal

Software agent who is responsible for managing an OGC® WPS DSS

server and executing its processes to obtain recommendations and alerts.

8 OGC® WPS Internal

Software agent responsible for classifying an integrated OGC® WPS

server in order to delegate the supervision to a more specific agent

(OGC® WPS HF, OGC® WPS DMS, OGC® WPS DSS)

Table 11: “First draft of identified agents”

3.2 Task modelling

The aim of this step is creating a functional decomposition of the system providing the goals for each

task, as well as the beliefs and the problem-solving methods to solve each goal. Tasks are split in a tree

hierarchy using a top-down approach and providing a description of each of them.

Task 1 ‘Register OGC® WPS Server’ (Figure 10). Represents the tasks subdivision of the ‘OGC®

WPS Server integration (HF, DSS and DMS)’ user story (See Table 5 and Figure 2). The task ‘Register

OGC® WPS server’ is divided in 4 subtasks which are sequential: (i) ‘receive request’; (ii) ‘check

existence of OGC® WPS server’; (iii) ‘check OGC® WPS server type’; (iv) ‘register’ and finally (v)

‘return response’.

‘Receive request’. All main tasks start with a request where, the petition shall be managed and

the input parameters shall be extracted.

‘Check existence of OGC® WPS server’ which is necessary because if an ‘OGC® WPS’ server

is already registered in the WatERP framework, it shall not be registered again and an

exception shall be thrown.

‘Check OGC® WPS server type’ task is responsible to analyse the integrated ‘OGC® WPS’

server in order to identify its type (DSS, DMS or HF) through the semantic annotations.


‘Register’ is a subtask made up of three subtasks:

o ‘register’, is responsible for registering the new ‘OGC® WPS’ server in the WatERP

framework for being accessible.

o ‘instantiate a specific OGC® WPS’ instantiates a new agent which fits with the type of

the integrated ‘OGC® WPS’ server (‘OGC® WPS HF’ agent, ‘OGC® WPS DSS’ agent

or ‘OGC® WPS DMS’ agent) for delegating the function of supervising and managing

the specific ‘OGC® WPS’ agent.

o ‘update cache’, whose purpose is to improve the performance of the WatERP platform

by reducing the response time. The most important characteristics of each ‘OGC®

WPS’ server are cached after being registered.

‘Return response’ is the last subtask. Like the ‘receive request’ subtask, this subtask is part of

all tasks which need to return information.

Figure 10: “Task decomposition for ‘Register OGC® WPS Server”

Task 2 ‘OGC® WPS Processes Analysis’ (Figure 11) is focused on registering the processes of

OGC® WPS in the WatERP platform. It is a consequence of the ‘OGC® WPS Server integration (HF,

DSS and DMS)’ user story (See Table 5 and Figure 2). The task ‘Register OGC® WPS server’ is

divided in 4 subtasks that are sequential: (i) ‘read processes’; (ii) ‘read process description’; (iii)

‘evaluate process’; and finally (iv) ‘register process’.

‘Read processes’ task that accesses the supervised ‘OGC® WPS’ server using the

‘getCapabilities’ operation with the aim of achieving all available processes on the server.

‘Read process description’ task obtains the description of each process that is part of the

integrated ‘OGC® WPS’ server using the ‘describeProcess’ operation of the ‘OGC® WPS’

server.

The ‘Evaluate process’ is an essential task, since it evaluates each process in order to decide if

it is runnable or non-runnable. A runnable process is a process that can be executed by the

WatERP platform because all required input parameters are present, that is, it exists another

registered process that is able to generate the required input parameter as an output. Instead, a

non-runnable process is a process where one or more input parameters are missing on the

WatERP platform. It is important to notice that a runnable process can be later classified as

non-runnable process due to process-related changes registered, such as removing a process.

Moreover, it is also possible that a non-runnable process is later classified as runnable if a new

RegisterOGCWPSServer

ReceiveRequest-1 ReturnResponse-5Register-4CheckExistenceOGCWPSServer-2

InstantiateSpecificAgent-4.2 UpdateCache-4.3

CheckOGCWPSServerType-3

Register-4.1


process is registered on the WatERP platform and it is able to provide the needed information

to it.

The last task is ‘Register process’ and it is subdivided into two subtasks:

o The ‘Register on WatERP ontology’ task registers the runnable and non-runnable

processes on the WatERP ontology with the aim of carrying out the orchestration using

semantic queries. Therefore, information about the inputs and outputs of the processes

is annotated on the ontology.

o ‘Register on yellow pages’ task registers the processes offered by the agents (also

called services in Jadex language) in the yellow pages in order to know who is the

agent responsible for executing it once the required service is detected.

Figure 11: “Task decomposition for ‘OGC® WPS processes analysis’”

Task 3 ‘Unregister OGC® WPS Server’ (Figure 12) is a consequence of the ‘Unregister OGC® WPS

server (Hydrological Forecast, DSS and DMS)’ user story (See Table 6 and Figure 2). The task

‘Unregister OGC® WPS server’ is divided in 3 sequential subtasks: (i) ‘receive request’; (ii) ‘unregister’;

and finally (iii) ‘return response’.

‘Receive request’. The same concept that in task 1.

‘Unregister’ is a subtask based in three subtasks:

o ‘Check existence OGC® WPS Server’ checks if ‘OGC® WPS’ Server to be removed

exists in the WatERP framework. Furthermore, if the ‘OGC® WPS’ Server does not

exist, an exception is thrown.

o ‘Unregister processes’. If the ‘OGC® WPS’ Server exists, that is, the previous subtask

has been successfully executed the processes that are part of this ‘OGC® WPS’

Server are unregistered of the runnable and non-runnable processes cache since they

are no longer part of the system. Therefore, after the execution of this subtask these

processes will not be available in the WatERP framework to be executed.

o ‘Evaluate processes’. Moreover, the removal of the processes provided for an

unregistered ‘OGC® WPS’ server of the runnable processes cache implies that other

processes may become unusable because they need as input the output of one of the

processes removed. Therefore, a new evaluation of the processes is carried out on the

runnable processes cache in order to eliminate the non-runnable processes of the

system which are moved to the non-runnable processes cache.

o

OGCWPSProcessesAnalysis

ReadProcesses-1 RegisterProcess-4ReadProcessDescription-2

RegisterOnYellowPages-4.2

EvaluateProcess-3

RegisterOnWatERPOntology-4.1


‘Return response’. The same task concept that in task 1.

Figure 12: “Task decomposition for ‘Unregister OGC® WPS Server”

Task 4 ‘Get available Hydrological Forecast Processes’ (Figure 13) is a consequence of the

‘Consult a hydrological forecast’ user story (See Table 7 and Figure 4). The task ‘Get available

hydrological forecast processes’ is divided into three sequential subtasks: (i) ‘receive request’; (ii)

‘obtain available hydrological forecast processes’; and finally (iii) ‘return response’.


‘Get available hydrological forecast processes’ is responsible for retrieving the runnable

hydrological processes stored on the runnable processes cache.


Figure 13: “Task decomposition for ‘Get available hydrological forecast processes”

Task 5 ‘Get Hydrological Forecast’ (Figure 14) is a consequence of the ‘Consult a hydrological

forecast’ user story (See Table 7 and Figure 4). The ‘execute hydrological forecast’ task is divided into 4

sequential subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS server’; (iii) ‘execute hydrological forecast

process’ and finally (iv) ‘return response’.


‘Get OGC® WPS Server’ is aimed at finding the ‘OGC® WPS’ server that is responsible for

managing the process to be executed using the runnable processes cache.

‘Execute hydrological forecast process’ is a subtask made up of two subtasks and it is

responsible for executing the hydrological forecast process.

o ‘Get input parameters’ is the first subtask and it is aimed at obtaining the required input

parameters to execute the process. This task is carried out analysing the runnable

processes cache, where the information about the inputs and outputs of all available

processes is stored.

o ‘Execute’ which is responsible for invoking the operation ‘execute’ of the ‘OGC® WPS

server’ using the input parameters retrieved by the previous task ‘Get input

parameters’.

OGCWPSProcessesAnalysis

ReceiveRequest-1 ReturnResponse-3Unregister-2

UnregisterProcesses-2.2 EvaluateProcesses-2.3CheckExistenceOGCWPSServer-2.1

GetAvailableHydrologicalForecastProcesses

ReceiveRequest-1 GetAvailableHydrologicalForecastProcesses-2 ReturnResponse-3



Figure 14: “Task decomposition for ‘Consult hydrological forecast”

Task 6 ‘Get Available Demand Forecast Processes’ (Figure 15) is a consequence of the ‘Consult a

demand forecast’ user story (See Table 8 and Figure 5). The ‘Get available demand forecast

processes’ task is divided into three sequential subtasks: (i) ‘receive request’; (ii) ‘obtain available

demand forecast processes’; and finally (iii) ‘return response’.


‘Get available demand forecast processes’ is responsible for retrieving the runnable demand

forecast processes stored in the runnable processes cache of the platform.


Figure 15: “Task decomposition for ‘Get available demand forecast processes”

Task 7 ‘Get Water Resources’ (Figure 16) is a consequence of the ‘Consult a demand forecast’ user

story (See Table 8 and Figure 5) and ‘Consult water allocation’ user story (See Table 9, Figure 6 and

Figure 7). The ‘Get water resources of a type’ task is divided into three sequential subtasks: (i) ‘receive

request’; (ii) ‘obtain available demand forecast processes’; and finally (iii) ‘return response’.


‘Get water resources’ is responsible for retrieving the water resources which are part of a

logical model and of a particular type from the ontology.


Figure 16: “Task decomposition for ‘Get water resources of a type”

Task 8 ‘Execute Demand Forecast’ (Figure 17) is a consequence of the ‘Consult a demand forecast’

user story (See Table 8 and Figure 5). The ‘execute a demand forecast’ task is divided into four

sequential subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS server’; (iii) ‘execute demand forecast

process’ and finally (iv) ‘return response’.

GetHydrologicalForecast

ReceiveRequest-1 ReturnResponse-4ExecuteHydrologicalForecastProcess-3getOGCWPSServer-2

GetInputParameters-3.1 Execute-3.2

GetAvailableDemandForecastProcesses

ReceiveRequest-1 ReturnResponse-3GetAvailableDemandForecastProcesses-2

GetWaterResources

ReceiveRequest-1 ReturnResponse-3GetWaterResources-2



‘Get OGC® WPS Server’ is aimed at finding the ‘OGC® WPS’ server that is responsible for

managing the demand forecast process to be executed using the runnable processes cache.

‘Execute demand forecast process’ is a subtask made up of two subtasks and it is responsible

for executing the demand forecast process.

o ‘Get input parameters’ is the first subtask and is aimed at obtaining the required input

parameters to execute the process (e.g. recovering the temperature and rainfall

forecast provided by the hydrologic forecast systems to carry out a more accurate

demand forecast). This task is carried out analysing the runnable processes cache,

where the information about the inputs and outputs of all available processes is stored.


DMS’ server using the input parameters retrieved by the previous task ‘Get input

parameters’.


Figure 17: “Task decomposition for ‘execute a demand forecast’”

Task 9 ‘Get Available Water Allocation Processes’ (Figure 18) is a consequence of the ‘Consult

water allocation’ user story (See Table 9, Figure 6 and Figure 7). The task ‘Get available water

allocation processes’ is divided into three sequential subtasks: (i) ‘receive request’; (ii) ‘obtain available

water allocation DSSs’; and finally (iii) ‘return response’.

‘Receive request’. The same concept that in ¡task 1.

‘Get available water allocation processes’ is responsible for retrieving the runnable OGC® WPS

water allocation processes stored on the runnable processes cache of the WatERP platform.


Figure 18: “Task decomposition for ‘get available water allocation processes’”

Task 10 ‘Get Current Scenario State’ (Figure 19) is a consequence of the ‘Consult water allocation’

user story (See Table 9, Figure 6 and Figure 7). The task ‘Get current scenario state’ is divided into four

sequential subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS Server’; (iii) ‘execute get current scenario

state’ and finally (iv) ‘return response’.

ExecuteDemandForecast

ReceiveRequest-1 ReturnResponse-4GetOGCWPSServer-2

Execute-3.2

ExecuteDemandForecastProcess-3

GetInputParameters-3.1

GetAvailablewaterAllocationProcesses

ReceiveRequest-1 ReturnResponse-3GetAvailableWaterAllocationProcesses-2



‘Get OGC® WPS Server’ is aimed at finding the OGC® WPS DSS that is responsible for

managing the water allocation DSS used by the water manager.

‘Execute get current scenario process’ is a subtask made up of two subtasks and it is

responsible for executing the demand forecast process.


parameters to execute the process (e.g. recovering the essential observations to

evaluate the current state). This task is carried out analysing the runnable processes

cache, where the information about the inputs and outputs of all available processes is

stored.


DSS’ server using the inputs parameters retrieved by the previous task ‘Get input

parameters’.


Figure 19: “Task decomposition for ‘get current scenario state’”

Task 11 ‘Get Behaviour’ (Figure 20) is a consequence of the ‘Consult water allocation’ user story (See

Table 9, Figure 6 and Figure 7). The task ‘Get behaviour’ is divided into three sequential subtasks: (i)

‘receive request’; (ii) ‘get behaviour’ and finally (iii) ‘return response’.


‘Get behaviour’ is aimed at obtaining the behaviour of a logical model.

‘Response’. The same task concept that in task 1.

Figure 20: “Task decomposition for ‘get behaviour’”

Task 12 ‘Set behaviour’ (Figure 21) is a consequence of the ‘Consult water allocation’ user story (See

Table 9, Figure 6 and Figure 7). The task ‘Set behaviour’ is divided into three sequential subtasks: (i)

‘receive request’; (ii) ‘set behaviour’ and finally (iii) ‘return response’.


Set behaviour’ is aimed at adding the new behaviour of the logical model used during the water

allocation decision-making in the ontology.

GetCurrentScenarioState


Execute-3.2

ExecuteGetCurrentScenarioProcess-3


GetBehaviour

ReceiveRequest-1 ReturnResponse-3GetBehaviour-2


‘Response’. The same task concept that in task 1.

Figure 21: “Task decomposition for ‘set behaviour’”

Task 13 ‘Get Water Allocation Recommendations’ (Figure 22) is a consequence of the ‘Consult

water allocation’ user story (See Table 9, Figure 6 and Figure 7). The task ‘Get water allocation

recommendations’ is divided into four sequential subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS

Server’; (iii) ‘execute water allocation recommendations process’ and finally (iv) ‘return response’.


‘Get OGC® WPS Server’ is aimed at finding the ‘OGC® WPS DSS’ responsible for managing

the water allocation DSS used by the water manager.

‘Execute water allocation recommendations process’ is a subtask made up of two subtasks and

it is responsible for executing the demand forecast process.


parameters to execute the process responsible for generating water allocation

recommendations (e.g. recovering the essential observations, the demand forecast for

each sink of the logical model and the behaviour of the logical model to execute the

water allocation process and get the recommendations). This task is carried out

analysing the runnable processes cache, where the information about the inputs and

outputs of all available processes is stored.

o ‘Execute’ which invokes the operation ‘execute’ of the ‘OGC® WPS’ server returned by

the previous task ‘Get OGC® WPS Server’. Moreover, the process that is able to

generate the water allocation and its required input parameters (retrieved by the

previous task ‘Get input parameters’) are provided to the ‘execute’ operation.


Figure 22: “Task decomposition for ‘get water allocation recommendations’”

Task 14 ‘Get Pump Scheduling Process’ (Figure 23) is a consequence of the ‘Consult pump

scheduling’ user story (See Table 9, Figure 6 and Figure 7). The task ‘Get pump scheduling

recommendations’ is divided into four subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS Server’; (iii)

‘execute pump scheduling recommendations process’ and finally (iv) ‘return response’.

SetBehaviour

ReceiveRequest-1 ReturnResponse-3SetBehaviour-2

GetWaterAllocationRecommendations


Execute-3.2

ExecuteWaterAllocationRecomProcess-3




‘Get OGC® WPS Server’ is aimed at finding the ‘OGC® WPS DSS’ server responsible for

managing the pump scheduling DSS chosen by the water manager.

‘Execute pump scheduling recommendations process’ is a subtask made up of two subtasks

and it is responsible for executing the demand forecast process.


parameters to execute the process responsible for generating pump scheduling

recommendations (e.g. the demand forecast for each sink of the logical model). This

task is carried out analysing the runnable processes cache, where the information

about the inputs and outputs of all available processes is stored.

o ‘Execute’ which invokes the operation ‘execute’ of the ‘OGC® WPS’ server returned by

the previous task ‘Get OGC® WPS Server’. Moreover, the process that is able to

generate the pump scheduling and its required input parameters (retrieved by the

previous task ‘Get input parameters’) are provided to the ‘execute’ operation.

‘Return response’. The same task concept depicted in task 1.

Figure 23: “Task decomposition for ‘get pump scheduling recommendations’”

The following tables detail each task through the identification of the following fields: (i) task goal; (ii)

task description; (iii) inputs of the task; (iv) the output of the task; (v) pre-conditions that indicate the

initial state required to execute the task; (vi) post-conditions that detail the state after executing the task;

(vii) the associated subtasks; and (viii) the beliefs.

N. Task 1

Name Register ‘OGC® WPS’ server.

Goal Register an ‘OGC® WPS’ server in order make it available in the WatERP framework.

Description

This task checks if ‘OGC® WPS’ server exists in the WatERP framework. If the server does

not exist, then it is analysed to discover its type. Afterwards, a specific new agent capable of

managing the ‘OGC® WPS’ server (HF OGC® WPS, DSS OGC® WPS and DMS OGC®

WPS) is instantiated with the aim of supervising it.

Input URL of the ‘OGC® WPS’ server to be registered.

Outputs True if the ‘OGC® WPS’ server has been successfully registered in the WatERP framework.

False otherwise.

Pre-conditions Received request to register an ‘OGC® WPS’ server.

Post-conditions The ‘OGC® WPS’ server is integrated in the WatERP framework.

Super Task None.

GetPumpSchedulingProcesses


Execute-3.2

ExecutePumpSchedulingRecomProcess-3



Sub Task

Receive request-1, Check existence of OGC® WPS Server-2, Check OGC® WPS Server

type-3, Register-4 (Register-4.1, Instantiate a specific OGC® WPS-4.2, Update cache-4.3),

Return response-5.

Belief URL ‘OGC® WPS’ server.

Table 12: “Task ‘Register OGC® WPS server’ description”

N. Task 2

Name OGC® WPS processes analysis.

Goal Register the executable processes of the specific ‘OGC® WPS’ server in the WatERP

platform.

Description

This task analyses the processes of a specific ‘OGC® WPS’ server to identify the executable

and non-executable processes. The executable processes are the processes that can be run

using the knowledge integrated in the platform. Instead, the non-executable processes are the

processes that do not have all the needed information to be executed.

Input None.

Outputs None.

Pre-conditions Received request to evaluate the supervised processes.

Post-conditions

The supervised processes are classified in executable and non-executable processes.

The executable processes are available to be executed on the WatERP framework through the

orchestration.

Super Task None.

Sub Task Read processes-1, Read process description-2 Evaluate Process-3, Register Process-4.

Belief Runnable processes (inputs and outputs), Non-runnable processes (inputs and outputs).

Table 13: “Task ‘Register OGC® WPS processes analysis’ description”

N. Task 3

Name Unregister ‘OGC® WPS’ server (Hydrological Forecast, DSS and DMS).

Goal Unregister an ‘OGC® WPS’ server of the platform.

Description

This task unregisters the ‘OGC® WPS’ server of the WatERP framework and removes the

integrated processes that are part of the unregistered OGC® WPS. Moreover, a new

evaluation of the runnable processes available in the WatERP framework is carried out since

the eliminated processes that belong to the unregistered ‘OGC® WPS’ server can cause that

runnable processes become non-executable processes.

Input URL of the ‘OGC® WPS’ server to be unregistered.

Outputs True if ‘OGC® WPS’ server has been successfully unregistered of the WatERP framework.

False otherwise.

Pre-conditions Received request to unregister an ‘OGC® WPS’ server.

Post-conditions

The ‘OGC® WPS’ server is unregistered.

Its processes are eliminated of the runnable and non-runnable processes knowledge.

The processes that used some of the deleted process as input are moved to the non-runnable

processes.


Super Task None.

Sub Task Receive request-1, Unregister-2, Check existence OGC® WPS Server-2.1, Unregister

processes-2.2, Evaluate processes-2.3, Return response-3.

Belief Runnable processes (inputs and outputs), Non-runnable processes (inputs and outputs).

Table 14: "Task ‘Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ description"

N. Task 4

Name Get available hydrological forecast processes.

Goal Get the runnable hydrological forecast processes.

Description This task retrieves the runnable hydrological processes stored in the runnable processes

cache of the WatERP platform.

Input None.

Outputs Hydrological forecast processes.

Pre-conditions Received request to obtain the available hydrological forecast processes.


Super Task None.

Sub Task Receive request-1, Get available hydrological forecast processes-2, ReturnResponse-3.

Belief Runnable processes.

Table 15: "Task ‘Get available hydrological forecast processes’ description”

N. Task 5

Name Execute Hydrological forecast process.

Goal Execute a hydrological forecast process.

Description

First, this task obtains the ‘OGC® WPS’ Server that is able to execute the hydrological forecast

process. After, the input parameters required to run the process are obtained from the WatERP

platform. Once the server responsible for executing the process and the required parameters

are retrieved, the process is executed.

Input Hydrological forecast process identifier, geometry.

Outputs Result of the executed hydrological forecast process.

Pre-conditions Received request to execute a hydrological forecast process.


Super Task None.

Sub Task Receive request-1, Get OGC® WPS Server-2, Execute hydrological forecast process-3 (Get

input parameters-3.1, Execute-3.2), Return response-4

Belief Runnable processes, URL of the ‘OGC® WPS’ server

Table 16: “Task ‘Execute Hydrological forecast process’ description”

N. Task 6

Name Get available demand forecast processes.

Goal Get the runnable demand forecast processes.

Description This task retrieves the runnable demand forecast processes stored in the runnable processes



Input None.

Outputs Demand forecast processes.

Pre-conditions Received request to obtain the demand forecast processes.


Super Task None.

Sub Task Receive request-1, Get available demand forecast processes-2, ReturnResponse-3.


Table 17: “Task ‘Get available demand forecast processes’ description”

N. Task 7

Name Get water resources of a type.

Goal Get all water resources that are part of logical model and of a specific type.

Description This task obtains all water resources of a logical model that are of a specific type.

Input Logical model identifier, water resource type.

Outputs Water resources.

Pre-conditions Received request to obtain all water resources of a concrete type.


Super Task None.

Sub Task ReceiveRequest-1, Get water resources-2, Return response-3.

Belief Logical model cache.

Table 18: “Task ‘Get water resources of a type’ description”

N. Task 8

Name Execute a demand forecast.

Goal Execute a demand forecast.

Description

First, this task finds the ‘OGC® WPS’ server that is responsible for executing the demand

forecast process. Afterwards, the input parameters required to run the process are obtained

from the WatERP platform. Once the server responsible for executing the process and the

required parameters are retrieved, the process is executed.

Input

The identifier of the demand forecast process to be executed.

The identifier of the sinks for which the demand forecast will be computed.

The date from which to generate demand forecasts.

Outputs Demand forecast.

Pre-conditions Received request to execute a demand forecast.


Super Task None.

Sub Task Receive request-1, get OGC® WPS Server-2, execute demand forecast process-3 (get input

parameters-3.1, execute-3.2), return response-4.

Belief Runnable process, URL of OGC® WPS server.

Table 19: “Task ‘Execute a demand forecast’ description”


N. Task 9

Name Get available water allocation process.

Goal Get the runnable water allocation processes.

Description This task retrieves the runnable water allocation processes stored on the runnable processes


Input None.

Outputs Water allocation processes.

Pre-conditions Received request to obtain the water allocation processes.


Super Task None.

Sub Task Receive request-1, Get available water allocation processes-2, ReturnResponse-3.


Table 20: “Task ‘Get available water allocation process’ description”

N. Task 10

Name Get current scenario state.

Goal Get current scenario state.

Description This task obtains the current state of the pilot instantiation.

Input Logical model identifier

Outputs Current state

Pre-conditions Received request to obtain current scenario state.


Super Task None.

Sub Task Receive request-1, get OGC® WPS Server-2, execute get current scenario process-3 (get

input parameters-3.1, execute-3.2), return response-4

Belief None.

Table 21: “Task ‘get current scenario state’ description”

N. Task 11

Name Get behaviour.

Goal Get the current behaviour used on the logical model.

Description

This task obtains the current behaviour of the infrastructures of the basin (e.g. minimum (Qmin)

and maximum (Qmax) flow of the infrastructure to work, minimum production if the infrastructure

is working (QWorkMin), etc...).

Input Logical model identifier.

Outputs Behaviour.

Pre-conditions Received request to obtain the current behaviour of a logical model.


Super Task None.

Sub Task ReceiveRequest-1, Get behaviour-2, Return response-3

Belief None


Table 22: “Task ‘Get behaviour’ description”

N. Task 12

Name Set behaviour.

Goal Get the current behaviour used on the logical model

Description

This task modifies the current behaviour of the infrastructures of the basin (e.g. minimum (Qmin)

and maximum (Qmax) flow of the infrastructure to work, minimum production if the infrastructure

is working (QWorkMin), etc…).

Input Logical model identifier, behaviour.

Outputs True if behaviour has been changed on the WatERP ontology. False otherwise.

Pre-conditions Received request to change the current behaviour of a logical model.

Post-conditions The behaviour of the logical model is substituted by the new behaviour.

Super Task None.

Sub Task ReceiveRequest-1, Set behaviour-2, Return response-3

Belief None.

Table 23: “Task ‘Set behaviour’ description”

N. Task 13

Name Get water allocation recommendations.

Goal Get recommendations regarding the water allocation in order to facilitate the decision-making.

Description

First, this task finds the ‘OGC® WPS’ server responsible for executing the water allocation

recommendations process. Afterwards, the input parameters required to run the process are

obtained from the WatERP platform. Once the server responsible for executing the process

and the required parameters are retrieved, the process is executed.

Input Logical model identifier, water allocation recommendations process.

Outputs Water allocation recommendations.

Pre-conditions Received request to get the water allocation recommendations.


Super Task None.

Sub Task Receive request-1, get OGC® WPS Server-2, execute water allocation recommendations

process-3 (get input parameters-3.1, execute-3.2), return response-4.

Belief Runnable process.

Table 24: “Task ‘Get water allocation recommendations’ description”

N. Task 14

Name Get pump scheduling recommendations

Goal Get recommendations regarding the pump scheduling in order to facilitate the decision-making.

Description

First, this task finds the ‘OGC® WPS’ server responsible for executing the pump scheduling

recommendations process. Afterwards, the input parameters required to run the process are

obtained from the WatERP platform. Once the server responsible for executing the process


and the required parameters are retrieved, the process is executed.

Input Logical model identifier.

Outputs Pump scheduling recommendations.

Pre-conditions Received request to get the pump scheduling recommendations.


Super Task None.

Sub Task Receive request-1, get OGC® WPS Server-2, execute pump scheduling recommendations

process-3 (get input parameters-3.1, execute-3.2), return response-4.

Belief Runnable process.

Table 25: “Task ‘Get pump scheduling recommendations’ description”

3.3 Software agent identification – second round

Once the main system tasks have been identified, the next step of the MAS-CommonKADS

methodology is to assign these tasks to the internal agents in order to check if the identified internal

agents can accomplish the tasks defined in section 3.2 and hence, ensure that all functionalities of the

system are covered.

The following table represents the assignation between internal agent and task/subtask providing an

overview of the assignation.

Tasks - Subtasks \ Internal

agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS DSS

Ta

sk

1

1 Receive Request Yes

2 Check existence of OGC®

WPS Server

Yes

3 Check OGC® WPS Server

type

Yes

4 Register Yes

4.1 Register Yes

4.2 Instantiate a specific

OGC® WPS

Yes

4.3 Update Cache Yes Yes Yes

5 Return response Yes

Ta

sk

2

1 Read processes Yes Yes Yes

2 Read process description Yes Yes Yes

3 Evaluate process Yes Yes Yes

4 Register process Yes Yes Yes

4.1 Register on WatERP

ontology

Yes



agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS DSS

4.2 Register on yellow pages

Ta

sk

3

1 Receive Request Yes

2 Unregister Yes

2.1 Check existence OGC®

WPS Server

Yes

2.2 Unregister Yes

2.3 Evaluate processes Yes Yes Yes


Ta

sk

4

1 Receive request Yes

2 Get available hydrological

forecast processes Yes


Ta

sk

5


2 Get OGC® WPS Server Yes

3 Execute hydrological

forecast process

Yes

3.1 Get input parameters Yes

3.2 Execute Yes


Ta

sk

6


2 Get available demand

forecast processes Yes


Ta

sk

7 1 Receive request Yes

2 Get water resources


Ta

sk

8



3 Execute demand forecast

process

Yes


3.2 Execute Yes


Ta

sk

9


2 Get available water

allocation processes Yes




agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS DSS

Ta

sk

10



3 Execute get current scenario

process

Yes


3.2 Execute Yes


Ta

sk


2 Get behaviour Yes


Ta

sk


2 Set behaviour Yes


Ta

sk

13



3 Execute water allocation

recommendations process

Yes


3.2 Execute Yes


Ta

sk

14



3 Execute pump scheduling

recommendations process

Yes


3.2 Execute Yes


Table 26: “Task-agents distribution round 1”

As it is shown in the Table 26, not all tasks have the minimum of one agent assigned (see Task 2 – 4.2

Register on yellow pages). Therefore, another internal agent is necessary to fulfil all tasks defined in the

“MS5 Second Vertical Integration”. The internal agent suitable for this task is the ‘Yellow Pages’ agent.

Moreover, it is an internal agent provided by the Jadex platform and therefore it does not need to be

implemented. For more information regarding the ‘Yellow Pages’ agent, see Section 4. Consequently,

the previous table has been altered to add the ‘Yellow Pages’ agent who is able to carry out task 4.2

Register on yellow pages (see Table 27).


Tasks – Subtasks \ Internal

agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS

DSS

Yellow

Pages

Ta

sk

2

1 Read processes Yes Yes Yes

2 Read process description Yes Yes Yes

3 Evaluate process Yes Yes Yes

4 Register process Yes Yes Yes

4.1 Register on WatERP

ontology

Yes

4.2 Register on yellow pages Yes

Table 27: “Task-agents distribution round 2”

Moreover, it is important to remark that this deliverable is iterative and hence this agent list can be

modified in further versions of this document.

3.4 Coordination modelling

As it was previously presented in D7.2.1 “Implementation of MAS” in Section 4.2.4, the coordination

between agents is essential in a MAS development. Therefore, the MAS-CommonKADS architecture

includes different tasks to analyse the coordination of the MAS, namely: (i) identify the conversations

between agents; (ii) describe the prototypical scenarios between agents; and (iii) represent the events

between agents in event flow diagrams.

3.4.1 Conversations

The aim of this section is to group the interactions between agents in conversations in order to identify

the different situations where an exchange of messages or events between agents occurs. The current

conversations which are aligned with milestone MS5 ”Second Vertical Integration”, will be added to the

conversations that were already identified in D7.2.1 “Implementation of MAS” in Section 4.2.4.1.

Following the same format that in previous deliverable, each conversation consists of one single

interaction and the possible answer, and they are described using tables containing: (i) name of the

identified conversation; (ii) objective of the conversation, that is, which is the goal of the agents with this

conversation; (iii) agents involved in the conversation; (iv) starter, which identifies the agent that initiates

the conversation; (v) description; (vi) pre-condition, which is the description of the WatERP MAS initial

state needed to start the conversation; (vii) post-condition , which is the WatERP MAS state expected;

and finally (viii) ending conditions which describe the cases where the conversation is finished

prematurely.

The conversations identified during the user stories’ analysis are presented below. Based on Figure 2 of

Section 2.4.1, the following conversations are identified: (i) register an ‘OGC® WPS’ server; (ii) register


an ‘OGC® WPS HF’ server; (iii) register an ‘OGC® WPS DMS’ server; and (iv) register an ‘OGC® WPS

DSS’ server.

N. Conversation 1

Name Integrate an ‘OGC® WPS’ server.

Objective Integrate an ‘OGC® WPS’ server in order to make it available for the WatERP framework.

Agents OMP Gateway, OGC® WPS.

Starter OMP Gateway.

Description When ‘OMP Gateway’ agent receives a petition to integrate an ‘OGC® WPS’ server, it

instantiates a new ‘OGC® WPS’ agent and delegates to it the register task.

Pre-condition None.

Post-condition The ‘OGC® WPS’ server is instantiated and is responsible of managing the integrated ‘OGC®

WPS’ server.

Ending condition The ‘OGC® WPS’ server has already been registered or the ‘OGC® WPS’ server is not

accessible.

Table 28: “‘Integrate an OGC® WPS server’ conversation”

N. Conversation 2

Name Destroy ‘OGC® WPS’ agent

Objective Destroy ‘OGC® WPS’ agent

Agents OMP Gateway, OGC® WPS.


Description

After to delegating the supervision of the integrated ‘OGC® WPS’ server to a more specific

agent (‘OGC® WPS HF’, ‘OGC® WPS DMS’ or ‘OGC® WPS DSS’), the ‘OGC® WPS’ agent is

not necessary, hence the ‘OMP Gateway’ agent sends a message to destroy the ‘OGC® WPS’

agent.

Pre-condition Supervision of the ‘OGC® WPS’ server has been delegated to a more specific agent.

Post-condition The ‘OGC® WPS’ agent is eliminated of the WatERP platform.

Ending condition The ‘OGC® WPS’ server is destroyed.

Table 29: “‘Destroy OGC® WPS agent’ conversation”

N. Conversation 3

Name Register an ‘OGC® WPS HF’ server.

Objective Register an ‘OGC® WPS HF’ server in order to make it available for the WatERP framework.

Agents OGC® WPS, OGC® WPS HF.

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (the ‘OGC® WPS HF’ agent) to supervise

the ‘OGC® WPS hydrological forecast’ server. Moreover, this agent is capable of analysing the

integrated server and registering the runnable processes in the WatERP platform.

Pre-condition The integrated ‘OGC® WPS’ server is of hydrological forecast type.

Post-condition The ‘OGC® WPS HF’ server is registered on the WatERP platform, thus its processes are


accessible from WatERP framework.

Ending condition The ‘OGC® WPS HF’ server has already been registered and these runnable processes have

been registered on the WatERP platform.

Table 30: “‘Register an OGC® WPS HF server’ conversation”

N. Conversation 4

Name Register an ‘OGC® WPS DMS’ server.

Objective Register an ‘OGC® WPS DMS’ server in order to make it available for the WatERP framework.

Agents OGC® WPS, OGC® WPS DMS.

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (‘OGC® WPS DMS’ agent), to supervise the

‘OGC® WPS DMS’ server. Moreover, this agent is capable of analysing the integrated server

and registering the runnable processes on the WatERP platform.

Pre-condition The integrated ‘OGC® WPS’ server is of DMS type.

Post-condition The ‘OGC® WPS DMS’ server is registered on the WatERP platform, thus its processes are


Ending condition The ‘OGC® WPS DMS’ server has already been registered and these runnable processes

have been registered on the WatERP platform.

Table 31: “’Register an OGC® WPS DMS server’ conversation”

N. Conversation 5

Name Register an ‘OGC® WPS DSS’ server.

Objective Register an ‘OGC® WPS DSS’ server in order to make it available for the WatERP framework.

Agents OGC® WPS, OGC® WPS DSS.

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (‘OGC® WPS DSS’) agent, to supervise the

‘OGC® WPS DSS’ server. Moreover, this agent is capable of analysing the integrated server

and registering the runnable processes on the WatERP platform.

Pre-condition The integrated ‘OGC® WPS’ server is the DSS type.

Post-condition The ‘OGC® WPS DSS‘ server is registered on the WatERP platform hence its processes are


Ending condition The ‘OGC® WPS DSS’ server has already been registered and these runnable processes

have been registered on the WatERP platform.

Table 32: “’Register an OGC® WPS DSS server’ conversation"

Based on Figure 3 of Section 2.4.2, the following conversations to unregister OGC® WPS servers are

identified: (i) unregister an ‘OGC® WPS HF’ server; (ii) destroy ‘OGC® WPS HF’ agent; (iii) unregister

an ‘OGC® WPS DMS’ server; (iv) destroy ‘OGC® WPS DMS’ agent; (v) unregister and ‘OGC® WPS

DSS’ server; and (vi) unregister an ‘OGC® WPS DSS’ server.

N. Conversation 6

Name Unregister an ‘OGC® WPS HF’ server.


Objective Unregister an ‘OGC® WPS HF’ server and unregister its runnable and non-runnable processes

of the WatERP platform.

Agents OMP Gateway, OGC® WPS HF

Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies to the ‘OGC® WPS HF’ that its processes shall be

unregistered from the WatERP platform.

Pre-condition The ‘OGC® WPS HF’ server is registered on the WatERP platform.

Post-condition The ‘OGC® WPS HF’ server is unregistered of the WatERP platform and hence its processes

are deleted from the WatERP platform.

Ending condition The ‘OGC® WPS HS’ server and its processes are unregistered.

Table 33: “‘Unregister an OGC® WPS HF server’ conversation”

N. Conversation 7

Name Destroy ‘OGC® WPS HF’ agent.

Objective Destroy the agent responsible to manage an unregistered ‘OGC® WPS HF’ server.


Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies the ‘OGC® WPS HF’ that it shall be destroyed because it

has been unregistered.

Pre-condition The ‘OGC® WPS HF’ server processes are unregistered of the WatERP platform.

Post-condition The ‘OGC® WPS HF’ agent is destroyed.

Ending condition The ‘OGC® WPS HS’ agent is destroyed.

Table 34: “‘Destroy OGC® WPS HF agent’ conversation”

N. Conversation 8

Name Unregister an ‘OGC® WPS DMS’ server.

Objective Unregister an ‘OGC® WPS DMS’ server and unregister its runnable and non-runnable

processes of the WatERP platform.

Agents OMP Gateway, OGC® WPS DMS

Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies the ‘OGC® WPS DMS’ that its processes shall be


Pre-condition The ‘OGC® WPS DMS’ server is registered on the WatERP platform.

Post-condition The ‘OGC® WPS DMS’ server is unregistered from the WatERP platform and hence its

processes are deleted from the WatERP platform.

Ending condition The ‘OGC® WPS DMS’ server and its processes are unregistered.

Table 35: “‘Unregister an OGC® WPS DMS server’ conversation”

N. Conversation 9

Name Destroy ‘OGC® WPS DMS’ agent.

Objective Destroy the agent responsible for managing an unregistered ‘OGC® WPS DMS’ server.


Agents OMP Gateway, OGC® WPS DMS

Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies the ‘OGC® WPS DMS’ that it shall be destroyed because it


Pre-condition The ‘OGC® WPS DMS’ server processes are unregistered of the WatERP platform.

Post-condition The ‘OGC® WPS DMS’ agent is destroyed.

Ending condition The ‘OGC® WPS DMS’ agent is destroyed.

Table 36: “‘Destroy OGC® WPS DMS agent’ conversation”

N. Conversation 10

Name Unregister an ‘OGC® WPS DSS’ server.

Objective Unregister an ‘OGC® WPS DSS’ server and unregister its runnable and non-runnable

processes of the WatERP platform.

Agents OMP Gateway, OGC® WPS DSS

Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies to the ‘OGC® WPS DSS’ that its processes shall be


Pre-condition The ‘OGC® WPS DSS’ server is registered on the WatERP platform.

Post-condition The ‘OGC® WPS DSS’ server is unregistered from the WatERP platform and hence its

processes are deleted from the WatERP platform.

Ending condition The ‘OGC® WPS DSS’ server and its processes are unregistered.

Table 37: “‘Unregister an OGC® WPS DSS server’ conversation”

N. Conversation 11

Name Destroy ‘OGC® WPS DSS’ agent.

Objective Destroy the agent responsible for managing an unregistered ‘OGC® WPS DSS’ server.


Starter OMP Gateway

Description The ‘OMP Gateway’ agent notifies the ‘OGC® WPS DSS’ that it shall be destroyed because it


Pre-condition The ‘OGC® WPS DSS’ server processes are unregistered from the WatERP platform.

Post-condition The ‘OGC® WPS DSS’ agent is destroyed.

Ending condition The ‘OGC® WPS DSS’ agent is destroyed.

Table 38: “‘Destroy OGC® WPS DSS agent’ conversation”

Based on Figure 4 of the Section 2.4.3, two conversations have been identified, one to recover the

available hydrological forecast processes integrated on the WatERP platform and another to execute

one of these processes.

N. Conversation 12

Name Get available hydrological forecast processes.

Objective Obtain all runnable hydrological forecast processes.


Agents OMP Gateway, Sesame.


Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable hydrological forecast

process available in the WatERP platform.

Pre-condition None.

Post-condition None.

Ending condition The available runnable hydrological forecast processes are returned.

Table 39: “’Get hydrological forecast processes’ conversation”

N. Conversation 13

Name Execute hydrological forecast process

Objective Execute an hydrological forecast process


Starter OMP Gateway

Description The ‘OMP Gateway’ agent invokes ’OGC® WPS HF’ agent to execute the hydrological

forecast process of the supervised ‘OGC® WPS’ server.

Pre-condition The hydrological forecast process is a runnable process and is registered on the WatERP

platform and it is executable.


Ending condition The response of the executed hydrological forecast process has been returned.

Table 40: “‘Execute hydrological forecast process’ conversation”

The following conversations related to ‘consult a demand forecast’ (see Figure 5 in Section 2.4.4) are

identified: (i) get demand forecast processes; (ii) get water resources; and finally (iii) execute demand

forecast process.

N. Conversation 13

Name Get demand forecast processes.

Objective Obtain all runnable demand forecast processes.



Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable demand forecast

processes available in the WatERP platform.

Pre-condition None.


Ending condition The available runnable demand forecast processes are returned.

Table 41: “’Get demand forecast processes’ conversation”

N. Conversation 14

Name Get water resources.

Objective Get all water resources of a specific type for a logical model.




Description The ‘OMP Gateway’ agent asks ’Sesame’ agent for all water resources of a specific type for a

logical model instantiation (e.g. all available sinks for an ACA pilot).

Pre-condition The logical model instantiation exists.


Ending condition The agent returns the water resources.

Table 42: “‘Get water resources’ conversation”

N. Conversation 15

Name Execute demand forecast process.

Objective Execute a demand forecast process.

Agents OMP Gateway, OGC® WPS DMS.


Description

The ‘OMP Gateway’ agent invokes ’OGC® WPS DMS’ agent to execute the demand forecast

process of the supervised ‘OGC® WPS’ server providing the required parameters to carry out

the execution.

Pre-condition The demand forecast process is a runnable process and is registered on the WatERP platform

and it is executable.


Ending condition The response of the executed demand forecast process has been returned.

Table 43: “‘Execute hydrological forecast process’ conversation”

The next user story to be analysed is ‘consult water resources allocation’ which is presented in Figure 6

and Figure 7 of Section 2.4.5. The identified conversations are: (i) get ‘current state scenario’

processes; (ii) execute ‘current state scenario’ process; (iii) get behaviour; (iv) set behaviour; (v) get

‘water allocation recommendations’ processes and finally; (vi) execute ‘water allocation

recommendations’ process.

N. Conversation 16

Name Get ‘current state scenario’ processes.

Objective Obtain all runnable current state scenario processes.



Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable current state scenario


Pre-condition None.


Ending condition The available runnable current state scenario processes are returned.

Table 44: “’Get current state scenario processes’ conversation”

N. Conversation 17


Name Execute ‘current state scenario’ process.

Objective Execute ‘current state scenario’ process.


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to execute the ‘current state

scenario’ process of the supervised ‘OGC® WPS’ server providing the required parameters to

carry out the execution.

Pre-condition The ‘current state scenario’ process is a runnable process and is registered on the WatERP



Ending condition The response of the executed ‘current state scenario’ process has been returned.

Table 45: “‘Execute current state scenario process’ conversation”

N. Conversation 18

Name Get behaviour

Objective Obtain the current behaviour of a pilot instantiation.



Description The ‘OMP Gateway’ agent invokes the ‘Sesame’ agent in order to recover the current

behaviour of the pilot instantiation.

Pre-condition The pilot instantiation exists.


Ending condition The current behaviour is returned.

Table 46: “’Get behaviour’ conversation”

N. Conversation 19

Name Set behaviour

Objective Change the current behaviour of a pilot instantiation.



Description The ‘OMP Gateway’ agent invokes the ‘Sesame’ agent to insert the new behaviour for the pilot

instantiation.

Pre-condition The pilot instantiation exists.

Post-condition The behaviour of the pilot instantiation is changed.

Ending condition The behaviour of the pilot instantiation is changed.

Table 47: “’Set behaviour’ conversation”

N. Conversation 20

Name Get ‘water allocation recommendations’ processes.

Objective Obtain all runnable ‘water allocation recommendations’ processes.




Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable water allocation

recommendations processes available in the WatERP platform.

Pre-condition None.


Ending condition The available runnable ‘water allocation recommendations’ processes are returned.

Table 48: “’Get water allocation recommendations processes’ conversation”

N. Conversation 21

Name Execute a ‘water allocation recommendations’ process.

Objective Execute a ‘water allocation recommendations’ process.


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to execute the ‘water

allocation recommendations’ process of the supervised ‘OGC® WPS’ server providing the

required parameters to carry out the execution.

Pre-condition The ‘water allocation recommendations’ process is a runnable process and is registered on the

WatERP platform and it is executable.


Ending condition The response of the executed ‘water allocation recommendations’ process has been returned.

Table 49: “‘Execute water allocation recommendations process’ conversation”

Finally, the ‘consult pump scheduling’ user history is analysed (see Figure 8 and Figure 9 in Section

2.4.6), resulting in the following conversations: (i) get ‘pump scheduling’ processes; (ii) execute ‘pump

scheduling’ process; (iii) get ‘validate pump scheduling’ processes and finally; (iv) execute ‘validate

pump scheduling’ process.

N. Conversation 22

Name Get ‘pump scheduling’ processes.

Objective Obtain all runnable ‘pump scheduling’ processes.



Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable ‘pump scheduling’


Pre-condition None.


Ending condition The available runnable ‘pump scheduling’ processes are returned.

Table 50: “’Get pump scheduling processes’ conversation”

N. Conversation 23

Name Execute ‘pump scheduling’ process.


Objective Execute ‘pump scheduling’ process.


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to execute the ‘pump

scheduling’ process of the supervised ‘OGC® WPS’ server providing the required parameters

to carry out the execution.

Pre-condition The ‘pump scheduling’ process is a runnable process and is registered on the WatERP



Ending condition The response of the executed ‘pump scheduling’ process has been returned.

Table 51: “‘Execute pump scheduling process’ conversation”

N. Conversation 24

Name Get ‘validate pump scheduling’ processes.

Objective Obtain all runnable ‘validate pump scheduling’ processes.



Description The ‘OMP Gateway’ agent asks the ‘Sesame’ agent for all runnable ‘validate pump scheduling’


Pre-condition None.


Ending condition The available runnable ‘validate pump scheduling’ processes are returned.

Table 52: “’Get validate pump scheduling processes’ conversation”

N. Conversation 25

Name Execute ‘validate pump scheduling’ process.

Objective Execute ‘validate pump scheduling’ process.


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to execute a ‘validate pump

scheduling’ process of the supervised ‘OGC® WPS’ server providing the required parameters

to carry out the execution.

Pre-condition The ‘validate pump scheduling’ process is a runnable process and is registered on the

WatERP platform and it is executable.


Ending condition The response of the executed ‘validate pump scheduling’ process has been returned.

Table 53: “‘Execute validate pump scheduling process’ conversation”


3.4.2 Scenarios

The aim of this section is to depict the exchanged messages between internal agents based on the

identified conversations (see Section 3.4.1) and user stories (see Section 2.4) that are used to build the

scenarios.

The internal interactions resulting from the ‘OGC® WPS server integration (Hydrological Forecast, DSS

and DMS’ user story (see Table 5 and Figure 2) are presented below.

The first interaction is started after receiving a ‘register OGC® WPS’ event from the ‘OMP’ external

agent. This event is received by the ‘OMP Gateway’ agent, which creates a new ‘OGC® WPS’ agent

and delegates the supervision of the ‘OGC® WPS’ server to it. In order to initialize the ‘OGC® WPS’

agent, it receives the necessary information (URL OGC® WPS server) from the ‘OMP Gateway’ agent.

Figure 24: “Interactions between agents to register an OGC® WPS server”

The next interaction is started after instantiating a specific ‘OGC® WPS’ agent (HF, DMS or DSS) to

supervise an ‘OGC® WPS’ server. In this interaction the ‘OMP Gateway’ agent notifies the ‘OGC®

WPS’ agent through an event that it should be destroyed.

Figure 25: “Interactions between agents to destroy an OGC® WPS agent”

Regarding to the interactions to instantiate specific agents, they can be divided into three interactions:

(i) OGC® WPS HF; (ii) OGC® WPS DMS; and (iii) OGC® WPS DSS.

This interaction is aligned with the instantiation of the ‘OGC® WPS HF’ agent. The communication is

started after analysing the ‘OGC® WPS’ server and verifying that it is an ‘OGC® WPS hydrological

forecast’ server. Afterwards, the ‘OGC® WPS’ agent instantiates an ‘OGC® WPS HF’ agent to

OMP Gateway

agentOGC WPS agent

create(url ogc wps server)

Inactive

Agent created

Inactive

tell(registered)

OMP Gateway

agentOGC WPS agent

ask(destroy())

Specific OGC WPS (HF, DMS, DSS) instantiated

DestroyedInactive


supervise the ‘OGC® WPS HS’ server which analyses the processes of the server and classifies them

in runnable and non-runnable processes.

Figure 26: “Interactions between agents to register an OGC® WPS HF server”

The second interaction related to the specific agents’ instantiation is shown in the Figure 27 an it

illustrates the interaction started after analysing the ‘OGC® WPS’ server and verifying that it is an

‘OGC® WPS DMS’ server. This event initiates the communication process with the instantiation of the

‘OGC® WPS DMS’ agent and the specification of the URL of the server to be supervised. Finally, the

instantiated agent analyses the processes of the server and classifies them into runnable and non-

runnable processes.

Figure 27: “Interactions between agents to register an OGC® WPS DMS server”

The last interaction of the instantiation interaction is presented in Figure 28. The communication is

started after analysing the ‘OGC® WPS’ server and verifying that it is an ‘OGC® WPS DSS’ server.

Afterwards, the ‘OGC® WPS’ agent instantiates an ‘OGC® WPS DSS’ agent which is responsible for

managing the integrated ‘OGC® WPS DSS’ server. Finally, this agent analyses the processes of the

server and classifies them in runnable and non-runnable processes.

OGC WPS agent OGC WPS HF agent


tell(registered)

OGC WPS server analysis

Analyse OGC WPS processes

Inactive

Detected OGC WPS HF server

Classify OGC OGC WPS processes

OGC WPS agentOGC WPS DMS

agent


tell(registered)



Inactive

Detected OGC WPS DMS server



Figure 28: “Interactions between agents to register an OGC® WPS DSS server”

Based on Figure 3 of Section 2.4.2, the following interactions have been identified: (i) unregister an

‘OGC® WPS HF’ server; (ii) destroy an ‘OGC® WPS HF’ agent; (iii) unregister an ‘OGC® WPS DMS’

server; (iv) destroy an ‘OGC® WPS DMS’ agent; (v) unregister an ‘OGC® WPS DSS’ server; and (vi)

destroy an ‘OGC® WPS DSS’ agent.

Figure 29 shows the internal interactions resulting from the ‘unregister an OGC® WPS HF server’

conversation (see Table 33). This interaction is started after receiving an ‘unregister OGC® WPS HF’

event from the ‘OMP’ external agent. The event is received by the ‘OMP Gateway’ agent and notifies

the corresponding ‘OGC® WPS HF’ agent that it shall be unregistered. Finally, the ‘OGC® WPS HF’

agent unregisters all its processes from the WatERP platform.

Figure 29: “Interactions between agents to unregister an OGC® WPS HF server”

The next interaction, which is based on the ‘destroy an OGC® WPS HF agent’ conversation (see Table

34) is shown in Figure 30. After to unregistering all processes from an ‘OGC® WPS’ server, the

interaction is started by the ‘OMP Gateway’ agent who notifies the ‘OGC® WPS HF’ agent that it should

be destroyed.

OGC WPS agentOGC WPS DSS

agent


tell(registered)



Inactive

Detected OGC WPS DSS server


OMP Gateway agent OGC WPS HF agent

ask(unregister())

tell(unregistered)

Inactive

Unregister OGC processes

Inactive


Figure 30: “Interactions between agents to destroy an OGC® WPS HF server”

Figure 31 shows the internal interactions resulting from the ‘unregister an OGC® WPS DMS server’

conversation (see Table 33). The interaction is started when the ‘OMP Gateway’ agent receives a

‘unregister OGC® WPS DMS’ event’. Afterwards it notifies the corresponding ‘OGC® WPS DMS’ agent

that it should be unregistered. Finally, the ‘OGC® WPS DMS’ agent unregisters all its processes from

the WatERP platform.

Figure 31: “Interactions between agents to unregister an OGC® WPS DMS server”

Figure 32 presents the internal interactions carried out to destroy an ‘OGC® WPS DMS’ agent. This

scenario is based on the ‘destroy an OGC® WPS DMS agent’ conversation (see Table 36). Once all

OGC® WPS processes have been unregistered, the ‘OMP Gateway’ agent notifies the ‘OGC® WPS

DMS’ agent that it should be destroyed.

Figure 32: “Interactions between agents to destroy an OGC® WPS DMS agent”

Figure 33 shows the internal interactions resulting from ‘unregister an OGC® WPS DSS server’

conversation (see Table 37). This interaction is started after receiving an ‘unregister OGC® WPS DSS’

event from the external agent ‘OMP’. The event is received by the ‘OMP Gateway’ agent and notifies


ask(destroy())

tell()

Unregistered processes

Inactive Destroyed

OMP Gateway agentOGC WPS DMS

agent

ask(unregister())

tell(unregistered)

Inactive


Inactive

OMP Gateway AgentOGC WPS DMS

agent

ask(destroy())

tell()


Inactive Destroyed


the corresponding ‘OGC® WPS DSS’ agent that it should be unregistered. Then, the ‘OGC® WPS

DSS’ unregisters all its processes from the WatERP platform.

Figure 33: “Interactions between agents to unregister an OGC® WPS DSS server”

The ‘destroy an OGC® WPS DSS agent’ conversation (see Table 34) is illustrated in the Figure 34. The

‘OMP Gateway’ agent starts it after unregistering all processes of an ‘OGC® WPS’ server and notifies

to the ‘OGC® WPS HF’ agent that it should be destroyed.

Figure 34: “Interactions between agents to destroy an OGC® WPS DSS agent”

The following internal interactions regarding the ‘Consult a hydrological forecast’ user story (see Figure

4) are identified: (i) get available hydrological forecast processes and (ii) execute hydrological forecast

process.

Figure 35 shows the internal interactions resulting from the ‘get available hydrological forecast

processes’ conversation (see Table 39). This interaction is started after receiving a ‘get hydrological

forecast processes’ event from the ‘OMP’ external agent. The event is received by the ‘OMP Gateway’

agent and requests by the runnable hydrological forecasts to the ’Sesame’ agent, which are later

returned to the ‘OMP Gateway’ agent.

OMP Gateway agentOGC WPS DSS

agent

ask(unregister())

tell(unregistered)

Inactive


Inactive


agent

ask(destroy())

tell()


Inactive Destroyed


Figure 35: “Interactions between agents to get available OGC® WPS HF processes”

The last interaction, ‘execute hydrological forecast process’, which is part of the ‘Consult a hydrological

forecast’ user story is presented in Section 2.4.3. It is started when a ‘execute hydrological forecast

process’ event from the ‘OMP’ external agent is received. Afterwards, the ‘OMP Gateway’ agent

invokes the ‘OGC® WPS HF’ agent to execute the process stored in the ‘OGC® WPS HF’ server

supervised by the agent.

Figure 36: “Interactions between agents to execute hydrological forecast process”

The next user story analysed is ‘consult a demand forecast’ which is presented in Figure 5 of Section

2.4.4. The following internal interactions are identified: (i) get demand forecast processes; (ii) get water

resources and (iii) execute demand forecast process.

Figure 37 shows the internal interactions resulting from the ‘get demand forecast processes’

conversation (see Table 41). This interaction is started after receiving a ‘get demand forecast

processes’ event from the ‘OMP’ external agent. The event is received by the ‘OMP Gateway’ agent

and asks the ’Sesame’ agent by the runnable demand forecasts, which are later returned to the ‘OMP

Gateway’ agent.

Figure 37: “Interactions between agents to get OGC® WPS DMS processes”

OMP Gateway agent Sesame agent

ask(hydrological forecast processes())

tell(hydrological forecast processes)

Inactive

Inactive


ask(execute(hydrological forecast process,

parameters))

tell(hydrological forecast)

Inactive

Inactive

Find responsible to execute HF process

OGC Gateway agent Sesame agent

ask(dms processes())

tell(dms processes)

Inactive

Inactive


The second internal interaction based on the ‘get demand forecast processes’ conversation (see Table

41) is presented in Figure 38. This interaction is started when the ‘OMP’ external agent generates a ‘get

water resources’ event which is managed by the ‘OMP’ external agent. Afterwards, the ‘OMP Gateway’

agent asks the ’Sesame’ agent by all water resources of a specific type (sink, storage, source, transport

or transformation) and that are part of a specific logical model. Finally, the returned information is

encapsulated in WatERP ontology format.

Figure 38: “Interactions between agents to get water resources”

The last interaction, ‘execute demand forecast process’, which is part of the ‘Consult a demand

forecast’ user story is presented on the Figure 39. It is started when a ‘execute demand forecast

process’ event from the ‘OMP’ external agent is received. Then, the ‘OMP Gateway’ agent invokes the

‘OGC® WPS DMS’ agent to execute the process stored in the ‘OGC® WPS DMS’ server supervised by

the agent.

Figure 39: “Interactions between agents to execute a demand forecast process”

The ‘Consult water resources allocation’ user story which is described in Figure 6 and Figure 7 of

Section 2.4.5 allows identifying the following conversations: (i) get current state scenario processes; (ii)

execute current state scenario process; (iii) get behaviour; (iv) set behaviour; (v) get water allocation

recommendations processes and (vi) execute water allocation recommendations process.

The Figure 40 shows the internal interactions resulting from the ‘get current state scenario processes’

conversation (see Table 44). This interaction is started after receiving a ‘get current state scenario

processes’ event from the ‘OMP’ external agent. The event is received by the ‘OMP Gateway’ agent,


ask(water resources(type))

tell(water resources)

Inactive

Inactive

OMP Gateway agentOGC WPS DMS

agent

ask(execute(demand forecast process,

parameters))

tell(demand forecast)

Inactive

Inactive

Find responsible to execute DF process

Find parameters to execute DF process


and asks the ’Sesame’ agent by the runnable current state scenario processes, which are later returned

to the ‘OMP Gateway’ agent.

Figure 40: “Interactions between agents to get current state scenario processes”

The second internal interaction based on the ‘execute current state scenario process’ conversation (see

Table 44) is presented in Figure 41. This interaction is started when the ‘OMP’ external agent generates

a ‘execute current state scenario process’ event, which is managed by the ‘OMP’ external agent.

Afterwards, the ‘OMP Gateway’ agent invokes ‘OGC® WPS DSS’ agent to execute the process stored

in the ‘OGC® WPS DSS’ server supervised by the agent. Finally, the returned information is

encapsulated in WatERP ontology format.

Figure 41: “Interactions between agents to execute a demand forecast process”

Figure 42 is based on the ‘get behaviour’ conversation (see Table 46). The ‘get behaviour’ event sent

from the ‘OMP’ external agent to the ‘OMP Gateway’ agent is the trigger to initiate the internal

interaction. Once the ‘OMP Gateway’ agent receives the event, it asks the ’Sesame’ agent by the

current behaviour for a specific logical model, which is later returned and encapsulated in WatERP

ontology format.


ask(state scenario processes())

tell(state scenario processes)

Inactive

Inactive


agent

ask(execute(scenario state process, parameters))

tell(scenario state)

Inactive

Inactive

Find responsible to execute scenario state process

Find parameters to execute scenario state process


Figure 42: “Interactions between agents to get behaviour”

The opposite functionality to the previous internal interaction is presented in Figure 44 which is based

on the ‘set behaviour’ conversation (see Table 47). In the same way, it is started when the ‘OMP

Gateway’ agent receives a ‘set behaviour’ event from the ‘OMP’ external. Then the ‘OMP Gateway’

agent invokes the ’Sesame’ agent overwriting the behaviour of the logical model which is transferred in

WatERP ontology format.

Figure 43: “Interactions between agents to set behaviour”

Figure 44 shows the internal interaction resulting from the ‘get water allocation recommendations

processes’ conversation (see Table 48). This interaction is started after receiving a ‘get water allocation

recommendations processes’ event from the ‘OMP’ external agent. The event is received by the ‘OMP

Gateway’ agent, and asks the ’Sesame’ agent by the runnable water allocation recommenders, which

are later returned to the ‘OMP Gateway’ agent.

Figure 44: “Interactions between agents to get water allocation recommendations processes”

The last internal interaction is based on the ‘execute water allocation recommendations process’

conversation (see Table 49) which is presented in the Figure 45. This interaction is started when the

‘OMP’ external agent generates a ‘execute water allocation recommendations process’ event which is


ask(behaviour())

tell(behaviour)

Inactive

Inactive


ask(behaviour(behaviour))

tell(inserted)

Inactive

Inactive


ask(water allocation processes())

tell(water allocation processes)

Inactive

Inactive


managed by the ‘OMP’ external agent. Afterwards, the ‘OMP Gateway’ agent invokes ‘OGC® WPS

DSS’ agent to execute the process stored on the ‘OGC® WPS DSS’ server supervised by the agent.

Finally, the returned information is encapsulated in WaterML2 (See D2.3 “Open interface specification”

section 3.2.1.1).

Figure 45: “Interactions between agents to execute water allocation recommendations process”

The last user story identified on this deliverable is ‘consult pump scheduling’ (see Section 2.4.6) and the

conversations extracted of it are the following: (i) get pump scheduling processes; (ii) execute pump

scheduling process; (iii) get validate pump scheduling processes; and (iv) execute validate pump

scheduling process.

Figure 46 shows the internal interactions resulting from the ‘get pump scheduling processes’

conversation (see Table 50). This interaction is started after receiving a ‘get pump scheduling

processes’ event from the ‘OMP’ external agent. The event is received by the ‘OMP Gateway’ agent,

and asks to the ’Sesame’ agent by the runnable pump scheduling processes which are later returned to

the ‘OMP Gateway’ agent.

Figure 46: “Interactions between agents to get pump scheduling processes”

The second internal interaction is related with the previous interaction, and it is responsible for

executing the pump scheduling processes. It is based on the ‘execute pump scheduling process’

conversation (see Table 51) and presented in Figure 47. This interaction is started when the ‘OMP’

external agent generates a ‘execute pump scheduling process’ event which is managed by the ‘OMP’

external agent. Afterwards, the ‘OMP Gateway’ agent invokes ‘OGC® WPS DSS’ agent to execute the


agent

ask(execute(water allocation process,

parameters))

tell(water allocation)

Inactive

Inactive

Find responsible to execute water allocation process

Find parameters to execute water allocation process


ask(pump scheduling processes())

tell(pump scheduling processes)

Inactive

Inactive


process stored in the ‘OGC® WPS DSS’ server supervised by the agent. Finally, the returned

information is encapsulated on WaterML2 format.

Figure 47: “Interactions between agents to execute pump scheduling process”

Another internal interaction resulting from the ‘get ‘validate pump scheduling’ processes’ conversation

(see Table 52) is presented in Figure 48. The ‘get ‘validate pump scheduling’ processes’ event which is

generated by the ‘OMP’ external agent starts the internal interaction. The event is received by the ‘OMP

Gateway’ agent, and asks to the ’Sesame’ agent by the runnable validate pump scheduling processes

which are later returned to the ‘OMP Gateway’ agent.

Figure 48: “Interactions between agents to get ‘validate pump scheduling’ processes”

The last internal interaction related with the ‘consult pump scheduling’ user story is shown in the Figure

49 and it is based on the ‘execute ‘validate pump scheduling’ process’ conversation (see Table 52).

This interaction is started when the ‘OMP’ external agent generates a ‘execute ‘validate pump

scheduling’ process’ event which is managed by the ‘OMP’ external agent. Afterwards, the ‘OMP

Gateway’ agent invokes the ‘OGC® WPS DSS’ agent to execute the process stored in the ‘OGC® WPS

DSS’ server supervised by the agent. Finally, the returned information is encapsulated on WaterML2

format.


agent

ask(execute(pump scheduling process,

parameters))

tell(pump scheduling)

Inactive

Inactive

Find responsible to execute pump scheduling process

Find parameters to execute pump scheduling process


ask(validate pump scheduling processes())

tell(validate pump scheduling processes)

Inactive

Inactive


Figure 49: “Interactions between agents to execute ‘validate pump scheduling’ process”

Finally, Figure 50 shows a summary of previous figures, unifying in a single illustration the interactions

between agents which will be implemented in milestone MS5 “Second vertical integration”. All these

interactions increases the implemented interactions presented on the D7.2.1 “Implementation of MAS”

in Section 4.2.4.2. In the picture, two different types of rectangles have been drawn, external agents

(dotted rectangles) and internal agents (solid rectangles). External agents provide the functionalities

needed for the interaction with the MAS, which are: (i) integrate an ‘OGC® WPS’ server; (ii) register an

‘OGC® WPS HF’ server; (iii) register an ‘OGC® WPS DMS’ server; (iv) register an ‘OGC® WPS DSS’

server; (v) unregister an ‘OGC® WPS HF’ server; (vi) unregister an ‘OGC® WPS DMS’ server; (vii)

unregister an ‘OGC® WPS DSS’ server; (viii) get available hydrological forecast processes; (ix) execute

hydrological forecast process; (x) get demand forecast processes; (xi) get water resources; (xii) execute

demand forecast process; (xiii) get ‘current state scenario’ processes; (xiv) execute ‘current state

scenario’ process; (xv) get behaviour; (xvi) set behaviour; (xvii) get ‘water allocation recommendations’

processes; (xviii) execute a ‘water allocation recommendations’ process; (xix) get ‘pump scheduling’

processes; (xx) execute ‘pump scheduling’ process; (xxi) get ‘validate pump scheduling’ processes; and

(xxii) execute ‘validate pump scheduling’ process. In reference to the internal agents, they have all

necessary intercommunications with the purpose of solving all received petitions through the external

agents.


agent

ask(execute(validate pump scheduling process,

parameters))

tell(pump scheduling validation)

Inactive

Inactive

Find responsible to execute validate pump scheduling process

Find parameters to execute validate pump scheduling process


Figure 50: “Initial interaction diagram among agents in the second vertical integration of MAS”

OMP

interface

Sesame agent

OMP Gateway

agent

ask(unregister(OGC SOS(url))

tell(is unregistered), fail(cause)

ask(register(OGC WPS(url)))

tell(is registered), fail(cause)

ask(unregister(OGC WPS(url))

tell(is unregistered), fail(cause)

ask(observations(water resource))

tell(observations), fail(cause)OGC SOS Agent

create(ogc sos(url))

ask(register(OGC SOS(uri)))

tell(is registered), fail(cause)

OGC WPS Agent

OGC WPS HF

Agent

OGC WPS DMS

Agent

OGC WPS DSS Agent

create(ogc wps(url))

ask(destroy())

create(ogc wps HF(url)) create(ogc wps DMS(url))

create(ogc wps DSS(url))

ask(unregister())

ask(unregister())

ask(unregister())

ask(destroy())

ask(destroy())

ask(destroy())


tell(HF processes)

ask(execute(HF process, params)

tell(HF)

ask(DF processes)

tell(DF processes)

ask(execute(DF process, params)

tell(DF)

ask(state scenario processes)

tell(state scenario processes)

ask(execute(state scenario process,

params)

tell(state scenario)

ask(behaviour(logical model))

tell(behaviour)

ask(behaviour(logical model, behaviour))

tell(inserted)

ask(water allocation processes)


ask(execute(water allocation process,

params)


ask(pump scheduling processes)

ask(execute(pump scheduling process,

params)



ask(validate pump scheduling

processes)

ask(execute(validate pump scheduling

process, params)


tell(validate pump scheduling processes)

ask(water resources(type))


ask(execute(HF process, params)

tell(HF)


tell(DF)

ask(execute(state scenario process, params)

tell(state scenario)

ask(execute(water allocation process, params)


ask(execute(pump scheduling process, params)


ask(execute(validate pump scheduling process, params)


ask(execute(HF process

, params))

tell(HF)


tell(DF)


tell(HF processes)

ask(DF processes())

tell(DF processes)

ask(water allocation processes())


ask(pump scheduling processes())


ask(validate pump scheduling processes())

tell(pump scheduling validation processes)

ask(observations())

tell(observations)

tell(observations)

ask(observations())


3.4.3 Message processing state diagrams

The aim of this section is to provide a vision of the process that the WatERP agents will carry out after

receiving each of the messages introduced in the previous section (3.4.2). It is important to remark that

the state diagrams presented only describe the new functionalities to be integrated by the MS5 “Second

Vertical Integration” milestone. The functionalities integrated in the MS3 “First Vertical Integration”

milestone can be consulted in deliverable D7.2.1 “Implementation of MAS” in Section 4.2.4.3. Moreover,

the state diagrams have been grouped into the following categories in order to facilitate its description:

(i) OGC® WPS integration; (ii) process management; and (iii) ontology management.

The state diagrams corresponding to the OGC® WPS integration are presented in the Figure 51. This

figure contains five diagrams, one for each possible message received by the agent regarding this

subject. The messages are: (a) register OGC® WPS; (b) analyse OGC® WPS; (c) register processes;

(d) unregister OGC® WPS; and (e) unregister processes.


Figure 51: “Message processing state diagram referring OGC® WPS integration”

Sub-picture (a) illustrates how initially the ‘OMP Gateway’ agent remains in an inactive state while

waiting for a message to carry out the register. When the ‘OMP Gateway’ agent receives a register

message with an OGC® WPS URL, it checks the URL existence in the system. If the URL is integrated

in the WatERP framework, it shall not be registered and therefore an error message will be returned as

Inactive

ask(register OGC WPS(url))

Inactive

do: check(url)

Inactive

ask(analyseOGCWPS())

Inactive

do: invokeGetCapabilities()

(a)

(b)

(c)

(d)

Inactive

ask(registerProcesses())

tell(resgistered)

Inactive

do: invokeGetCapabilities()

Inactive

ask(unregisterOGCWPS(url))

tell(unregistered)

Destroy

do: check(url)

(e)

Inactive

ask(unregisterProcesses())

tell(structure)

Inactive

do: unregisterProcesses()

do:

instantiateOGCWPSAgent(url)

tell(registered)

do: classifyOGCWPSServer()

do:

instantiateSpecificAgent(url)

do: invokeDescribeProcess()

do: evaluateProcesses()

do:

registerRunnableProcesses()

do: unregisterProcesses()

tell(classified)


a response. Otherwise, the ‘OMP Gateway’ agent will automatically instantiates a new ‘OGC® WPS’

agent that will be responsible for managing the OGC® WPS related to it. In the next step of the

process, the ‘OMP Gateway’ delegates the server registration to the ‘OGC® WPS’ agent the server

register. Finally, the ‘OMP Gateway’ agent sends a reply telling if the OGC® WPS has been

successfully integrated in the WatERP platform. This registering system provides a simple way to

integrate the OGC® WPS that follows the guidelines presented in D2.3 “Open Interface Specification” in

Section 3.2.2. Moreover, it enables the MAS to analyse semantically the integrated ‘OGC® WPS’

servers with the aim of exploiting its knowledge in the WatERP platform.

In the second sub-picture, (b), the ‘OGC® WPS’ agent remains in an inactive state until it receives a

message to analyse the ‘OGC® WPS’ server being supervised. Afterwards, the supervised server is

analysed using the getCapabilities operation provided by the ‘OGC® WPS’ server. The response of this

operation contains semantic annotations (see Section 3.2 in D2.3 “Open Interface Specification”), which

allows the agent to identify the ‘OGC® WPS’ server type (OGC® WPS HF, OGC® WPS DMS or OGC®

WPS DSS). The agent uses this server type to instantiate a more specific agent to manage the ‘OGC®

WPS’ server (OGC® WPS HF, OGC® WPS DMS or OGC® WPS DSS). Moreover, the ‘OGC® WPS’

agent delegates the processes’ registration to the specific agent. Finally, the ‘OMP Gateway’ agent

sends a reply telling if the OGC® WPS processes have been successfully integrated in the WatERP

platform.

The third sub-picture, (c), describes the state diagram for a specific agent (OGC® WPS HF, OGC®

WPS DMS or OGC® WPS DSS) that receives a petition to register its processes. Then, this petition

initiates the sequence to register the OGC® WPS processes. The first task of the specific agent is to

obtain all available processes through the getCapabillties operation and then obtain the description for

each process returned using the describeProcess operation. This information allows the agent to

evaluate each of the processes and classify them as runnable or non-runnable. This classification is

stored in the WatERP ontology so that it can be used in the future to orchestrate the processes. Finally,

when the evaluation process is finished, the specific agent returns a response telling if the processes

were successfully classified.

Sub-picture (d) represents the process performed by the ‘OMP Gateway’ agent when it receives an

unregister message. First, the ‘OMP Gateway’ agent checks the existence of the OGC® WPS URL

introduced as parameter. If the OGC® WPS is integrated in the WatERP system, then it can be

unregistered. Moreover, the specific ‘OGC® WPS’ agent (OGC® WPS HF, OGC® WPS DMS or OGC®

WPS DSS) will be destroyed because it will not be used anymore. Finally, the ‘OMP Gateway’ agent

returns a message indicating whether if the ‘OGC® WPS’ server has been successfully unregistered or

not.

Last sub-picture (e) describes the process carried out in order to unregister the processes published in

the WatERP platform by an agent. This task is done by a specific ‘OGC® WPS’ agent such as ‘OGC®

WPS HF’, ‘OGC® WPS DMS’ or ‘OGC® WPS DSS’. When one of these agents receives a message to


unregister its processes, they are deleted from the WatERP ontology. Finally, the specific agent sends

a reply telling if the unregister process has been successful or not.

Figure 52 presents the state diagrams regarding the processes’ management. The figure contains two

diagrams, one for each possible message received by the agent related to this topic. The messages

are: (a) obtain all available processes that are able to generate the expected output; and (b) execute a

process.

Figure 52: “Message processing state diagram referring the processes management”

The first sub-picture, (a), is the state diagram corresponding to the ‘recover all available processes’

message processing. Initially, the ‘OMP Gateway’ agent remains in an inactive state waiting for a

message requesting the available processes that are able to generate an output (e.g. processes to

generate pump scheduling, processes to generate demand forecast, etc.).. When a message to obtain

the processes is received, the ‘OMP Gateway’ agent looks for the runnable processes that are able to

generate the requested output in the ontology. Finally, the processes list is returned.

Last sub-picture (b) describes the state diagram corresponding to the execution of a process by the

agent. Moreover, it is important to remark that this state diagram is suitable for any specific agent

(‘OGC® WPS HF’, ‘OGC® WPS DSS’ or ‘OGC® WPS DMS’) because all of them contain processes

that have been integrated on the WatERP platform and therefore the MAS orchestrates them. Similarly

to the previous state diagrams, the agent waits until it receives a message to execute a process

belonging to the supervised server. When the message is received, the specific agent checks on the

WatERP ontology if the process requires input parameters. If so, the specific agent asks the WatERP

Inactive

ask(obtainProcesses(type))

Inactive

do:

getRunnableProcesses(type)

(a)

tell(processes)

Inactive

ask(executeProcess(process

id, params))

Inactive

do:

getRequiredInputParameters

()

(b)

tell(result)

do: executeProcess(process

id, params, input params


ontology for the runnable processes that are able to generate the expected inputs (from now on, we will

refer to runnable processes as sub-processes in order to facilitates the understanding). Notice that the

WatERP ontology will always be able to find processes capable of generating the expected inputs since

the processes were previously classified as runnable or non-runnable processes during the integration

part. Hence, the returned sub-processes are executed. Finally, the response of the sub-processes is

used as the input to execute the requested process and its output is returned.

The last state diagrams presented correspond to the ontology issues and they are shown in Figure 53.

It contains three diagrams, one for each possible message received by the agent related to this topic.

The messages are: (a) obtain water resources of a type; (b) get the behaviour of a logical model; and

(c) change the behaviour of a logical model.

Figure 53: “Message processing state diagram referring the ontology issues”

Sub-picture (a) corresponds to the state diagram of the ‘Sesame’ agent, which processes the ‘obtain

water resources of a type’ message. Initially, the ‘Sesame’ agent remains in an inactive state waiting for

a ‘obtain water resources of a type message’ message. When the message is received, then the

‘Sesame’ agent asks the ontology for all water resources of a specific type that pertain to a pilot

instantiation. This interaction is carried out through SPARQL queries (see Section 2.2.1 in D3.3 “WDW

Second prototype“) and the response is formatted in WatERP ontology format (see D1.3 “Generic

Ontology for water supply distribution chain”).

The second sub-picture, (b), describes the state diagram of the sequence where the ‘Sesame’ agent

obtains the behaviour of a pilot instantiation. Initially the agent waits until it receives a message to get

the pilot instantiation behaviour. Afterwards, when the message is received, the ‘Sesame’ agent gathers

this information from the WatERP ontology using the SPARQL interface provided by the WDW (see

Inactive

ask(obtainWaterResources(pi

lot intantiation id, type))

Inactive

do: getWaterResources(type)

(a)


Inactive

ask(obtainBehaviour(pilot

intantiation id))

Inactive

do: getBehaviour()

(b)

tell(behaviour)

Inactive

ask(setBehaviour(pilot

intantiation id, behaviour))

Inactive

do: setBehaviour(behaviour)

(c)

tell(inserted)


Section 2.2.1 in D3.3 “WDW Second prototype“)). The behaviour information received is then translated

to WatERP ontology format and returned.

Last state diagram (c) represents the activity flux of the ‘Sesame’ agent after receiving a ‘set behaviour’

message. The ‘Sesame’ agent inserts the new behaviour in the WatERP ontology so that it can be used

in the decision-making. Finally, the agent returns ‘true’ if the behaviour has been correctly inserted in

the WatERP ontology or ‘false’ otherwise.

3.5 Organization modelling

On the previous section, the dynamic relations between agents providing the communication protocols

between agents in order to achieve their goals have been identified. However, the inheritance relations

were not defined. Hence, these relations will be identified in this section with the aim of grouping the

agents with similar characteristics.

Two classes were identified in D7.2.1 “Implementation of MAS”: (i) ‘User Agent’ class, which provides a

gateway between the MAS and the involved actors; and (ii) ‘Semantic Agent’ class, which corresponds

to the supervisor agent that monitors the services / resources integrated in WatERP such as the

ontology instantiation.

In this second iteration (D7.2.2 “Implementation of MAS”), a new class has been identified: ‘OGC®

WPS’. This class consists of the ‘OGC® WPS HF’, the ‘OGC® WPS DMS’ and the ‘OGC® WPS DSS’

agents since they share their goals and beliefs. These agents are designed to monitor and manage

OGC® WPS servers, which have some differences depending on the server type (HF, DMS or DMS).

However, these minor differences such as the type of process deployed do not affect the agent's

behaviour. This behaviour involves the following: (i) obtain all available processes; (ii) obtain the

process description for each process; (iii) evaluate the process to classify it on runnable or non-

runnable processes; (iv) register the processes on the WatERP platform; and finally (v) execute

processes.

Figure 54 shows in a single figure the classes identified in Section 4.2.5 of deliverable D7.2.1

“Implementation of MAS” (grey background) and the classes identified in this document (white

background).


Figure 54: “Agents hierarchy”

Since the development of the WatERP SOA-MAS architecture is iterative, new scenarios as well as

new classes agents can be defined in next iterations of this deliverable depending on the pilot needs.

4. Design phase

In the previous deliverable, D7.2.1 “Implementation of MAS”, this section was focused on two key

issues: (i) platform selection and (ii) network agents’ identification.

The platform used to implement the MAS system was selected in the previous deliverable (D7.2.1

“Implementation of MAS” in Section 4.3.2). Summarizing, Jadex was chosen as the platform to develop

the utility-based BDI agents because: (i) it is free and open, (ii) updated regularly, (iii) supports a

standardized language as FIPA-ACL; and, (iv) is presented in the industrial market which demonstrates

its maturity.

In this deliverable the efforts in the design phase have been focused on the network agents’

identification. In Section 4.3.1 of D7.2.1 “Implementation of MAS” the use of yellow pages agents (also

named as Directory Facilitator (DF) on Jadex platform) was proposed as a solution to carry out part of

the WatERP orchestration providing the most suitable service able to provide a parameter. However, a

deeper analysis carried out as part the work reported in this deliverable has revealed some deficiencies

that do not facilitate the orchestration process by the Directory Facilitator. The main lacks are the

restricted stored information of the service and the limited search system to find services.

BasicAgent

UserAgent SemanticAgent

service[api-knowledge]service[interactMAS]

goal[improvePerformance,

identifyKnowledge]

OGCWPSAgent

service[get processes]

service[get process description]

service[evaluate process]

service[register process]

service[execute process]

goal[superviseOGCWPS,

manageOGCWPS]


Referring to the restricted stored information of the service, Figure 55 shows an example of how to

register a service in the Directory Facilitator. The ‘createDFServiceDescription’ method is used to insert

the service information and the DF only is able to store the following information: service name, service

type and service ownership, which are strings.

Figure 55: "Register of a service on the Directory Facilitator"

Therefore, the service type or service name should be used in order to characterize the service

including information such as the needed inputs to execute the service and the outputs generated by it.

Moreover, the search service provided by the Directory Facilitator is based on the matching of string

patterns, which minimizes the matchmaking search potential. Figure 56 shows an example of how to

find a service on the Directory Facilitator. The Service description object is defined with the type and

ownership as ‘null’ because they are not used during the search. Therefore, the search is carried out by

matching the name of the service against the services defined in the WatERP platform

Figure 56: "Search of a Service on Directory Facilitator"

The combination of both characteristics complicates the use of the DF search service to carry out the

matchmaking because the characterization of a process in a string can be a complex task and the

matching of string patterns to characterize the process is inefficient and almost unusable. Therefore, the

matchmaking of the services will be supported by the ontology reasoning, which is able to answer

questions like “What service can provide me “something” ?” (e.g. What service can provide an


temperature forecast?, What service can provide water allocation recommendations? ). Moreover, the

ontology will boost the matchmaking potential because it is able to return indirect knowledge regarding

the services definition and the observation and measurement types (e.g. if the agent asks for a service

that is able to generate temperature forecast, the ontology can return a service that is able to generate

a temperature prediction if both concepts, forecast and prediction, are aligned on the ontology). Finally,

the Directory Facilitator will be present on the WatERP platform, although its functionalities will be

reduced to provide the agent that is able to execute a service but is also easily affordable with the DF

characteristics.

5. Conclusions and future work

This section summarises the conclusions and results obtained from the work developed in “Task 7.2 –

Implementation of the Multi-Agent System Architecture”, which started on month 3 (M3) and will finish in

month 30 (M30) and is focused on the MAS developments that will be implemented by milestone MS5

“Second vertical integration”. The implementations presented in this deliverable are an extension of the

ones reported in D7.2.1 “Implementation of MAS” which corresponded to the first vertical integration

(MS3 “First vertical integration”) milestone.

The WatERP MAS MS5 “Second vertical integration” milestone consists of the integration of the

OGC® WPS server, which can be classified as OGC® WPS HF, OGC® WPS DSS and OGC® WPS

DMS, as well as upgrading the existing developments by adding new features to satisfy new

requirements like the semantic query adaptation to support new ontology concepts (see Section 3.1.1 of

D1.4.2 “Extension of taxonomy and ontology to the pilots”) or the data observations publication through

‘OGC® SOS’ server (see Section 2.2 of D3.2 “WDW 1st Prototype”).

During the second iteration of the MAS-CommonKADS methodology, five new internal agents have

been identified and added to the agents designed during the first iteration of the methodology (see

D7.2.1 “Implementation of MAS”). They are: (i) ‘OGC® WPS’ agent; (ii) ‘OGC® WPS HF’ agent; (iii)

‘OGC® WPS DMS’ agent; (iv) ‘OGC® WPS DSS’ agent; and (v) ‘OGC® SOS’ agent.

Moreover, the document offers a list of the different tasks that shall be carried out by every OGC® WPS

agent, including the mappings between tasks and agents. In order to facilitate the implementation, the

conversation diagrams to show the interactions needed to fulfil the MAS requirements are provided.

It is important to remark that the yellow pages (Directory Facilitator) operation, defined in the first

deliverable (D7.2.1 “Implementation of MAS” in Section 4.3.1), has been modified because of the

restricted ability of the searches provided by Jadex. The Yellow pages operation has been reduced

only to find the agents that are responsible for carrying out a service, leaving complex searches (such

as the matchmaking searches) to the WatERP ontology. In this way, semantic features can be

exploited for the agents in order to carry out more powerful and accurate matchmaking searches.


Future work to be accomplished will be focused on the integration of new or not covered functionalities

required by the rest of WPs.

cordis.europa.eu · ref. 318603 - waterp, d7.2.2_implementation_of_mas_v1.0 page 2 of 79 document...

Documents