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

WatERP

Water Enhanced Resource Planning

“Where water supply meets demand”

GA number: 318603

WP 7: Pilots

D7.2.3: Implementation of MAS

V1.0 30/07/2015

www.waterp-fp7.eu

Ref. Ares(2015)3328917 - 10/08/2015

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

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

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.3 Title Implementation of MAS

Work Package Number 7 Title Pilots

Date of delivery Contractual M31 Actual M34

Nature Prototype Report X Dissemination Other

Dissemination

Level Public X Consortium

Responsible Author Gabriel Anzaldi Email [email protected]

Partner Eurecat 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 the MAS subsystem that was

implemented totally once the milestone MS6 “Third 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.

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

mailto:[email protected]


Glossary of terms

AMS Agent Management Service

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.3 (D7.2.3) summarizes the work performed on the T7.2 Implementation of the Multi-

agent System Architecture which was performed from M4 to M30. Basically, it describes how the Multi-

agent systems (MAS) was analysed and defined in order to be implemented as part of the WatERP

SOA-MAS architecture. This deliverable is the third one of a series of documents that extends from M4

to M30 and follows the user in the loop strategy in the WatERP project throughout successive

deliverables. Moreover, it is important to note that this deliverable summarizes and enhances the

previous iterations due to its final character.

Firstly, a short description of the objectives defined for the vertical integration milestones of the project

is offered.

After, the document focuses on presenting and improving the results of the MAS-CommonKADS

iterations that were carried out during MS3 First Vertical Integration (M12), MS5 Second Vertical

Integration (M23) and MS6 Third Vertical Integration (M30) and presented in D7.2.1 “Implementation of

MAS”, D7.2.2 “Implementation of MAS” and this deliverable respectively. 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 seven actors were identified during MAS-CommonKADS iterations which

are: (i) ‘Logical Model’ actor; (ii) ‘OMP’ actor; (iii) ‘OGC® WPS’ actor; (iv) ‘OGC® WPS HF’ actor; (v)

‘OGC® WPS DMS’ actor, (vi) ‘OGC® WPS DSS’ and (vii) ‘OGC® SOS’ actor. Moreover the user

stories identified and studied are: (i) ‘obtain available feature of interest for a water resource’; (ii) ‘obtain

available observations for a feature of interest’; (iii) ‘obtain available logical models in WatERP

framework’; (iv) ‘add new logical model in the WatERP framework’; (v) ‘remove logical model of the

WatERP framework’; (vi) ‘obtain structure of the logical model’; (vii) ‘OGC® WPS server integration’;

(viii) ‘unregister OGC® WPS server’; (ix) ‘request a hydrological forecast’; (x) ‘request a demand

forecast’; (xi) ‘request water resource allocation recommendations’; and (xii) ‘request pumping

schedule’.

Moreover, the following internal agents were identified as necessary in the MAS-CommonKADS

iterations during the analysis phase: (i) ‘OMP Gateway’ who manages all received requests through the

OMP external agent; (ii) ‘Sesame’ who supervises a logical model and manages the interaction with it

within the WatERP platform; (iii) ‘OGC® SOS’ who is responsible for managing an OGC® SOS server

for getting observations and provide them to the others agents; (iv) ‘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 for managing the classified ‘OGC® WPS’

servers publishing its runnable processes on the ontology and managing their execution. 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

ontology to the pilots

Description of the improvements performed onto the WatERP general

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.


D7.2.2 Implementation of MAS

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

subsystem that was to be implemented once the milestone MS5 “Second

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.


Table of contents

1. INTRODUCTION ............................................................................................................................. 14

2. CONCEPTUALIZATION PHASE .................................................................................................... 16

2.1 IDENTIFICATION OF THE ACTORS .................................................................................................................. 16

2.2 IDENTIFICATION OF USER STORIES ............................................................................................................... 17

2.3 DESCRIPTION OF USER STORIES .................................................................................................................. 18

2.3.1 ‘Obtain available feature of interest for a water resource’ user story .................................................. 20

2.3.2 ‘Obtain available observations for a feature of interest’ user story ..................................................... 21

2.3.3 ‘Obtain available logical models in WatERP framework’ user story .................................................... 22

2.3.4 ‘Add new logical model in the WatERP framework’ user story ........................................................... 23

2.3.5 ‘Remove logical model of the WatERP framework’ user story ........................................................... 23

2.3.6 ‘Obtain the structure of the logical model’ user story .......................................................................... 24

2.3.7 ‘Request pumping schedule’ user story .............................................................................................. 25

2.3.8 ‘Request a hydrological forecast’ user story ....................................................................................... 29

2.3.9 ‘Request a demand forecast’ user story ............................................................................................. 29

2.3.10 ‘Request water resources allocation’ user story ............................................................................. 32

2.3.11 ‘OGC® WPS server integration (HF, DSS and DMS)’ user story ................................................... 35

2.3.12 ‘Unregister OGC® WPS server (HF, DSS and DMS)’ user story ................................................... 37

3. ANALYSIS PHASE ......................................................................................................................... 38

3.1 SOFTWARE AGENT IDENTIFICATION .............................................................................................................. 38

3.2 TASK MODELLING ....................................................................................................................................... 39

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

3.4 COORDINATION MODELLING ........................................................................................................................ 64

3.4.1 Conversations .................................................................................................................................... 64

3.4.2 Scenarios ........................................................................................................................................... 75

3.4.3 Message processing state diagrams .................................................................................................. 90

3.5 ORGANIZATION MODELLING ......................................................................................................................... 97

4. DESIGN PHASE ............................................................................................................................. 99

5. CONCLUSIONS AND FUTURE WORK ....................................................................................... 101


Table of figures

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

FIGURE 2: “’OBTAIN AVAILABLE FEATURE OF INTEREST FOR A WATER RESOURCE’ INTERACTIONS” ........................................ 21

FIGURE 3: “’OBTAIN AVAILABLE OBSERVATIONS FOR A FEATURE OF INTEREST’ INTERACTIONS”............................................. 22

FIGURE 4: “’ OBTAIN AVAILABLE LOGICAL MODEL FROM THE WATERP FRAMEWORK’ INTERACTIONS” .................................... 22

FIGURE 5: "’ADD NEW LOGICAL MODEL IN THE WATERP FRAMEWORK’ INTERACTIONS" ....................................................... 23

FIGURE 6: “’REMOVE LOGICAL MODEL OF THE WATERP FRAMEWORK’ INTERACTIONS” ....................................................... 24

FIGURE 7: “’OBTAIN THE STRUCTURE OF THE LOGICAL MODEL’ INTERACTIONS” .................................................................. 25

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

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

FIGURE 10: “’REQUEST A HYDROLOGICAL FORECAST’ INTERACTIONS” ............................................................................... 29

FIGURE 11: “’REQUEST A DEMAND FORECAST’ INTERACTION” ........................................................................................... 31

FIGURE 12: “’REQUEST WATER ALLOCATION’ INTERACTIONS (1/2)” ................................................................................... 33

FIGURE 13: “’REQUEST WATER ALLOCATION’ INTERACTIONS (2/2)” .................................................................................. 34

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

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

FIGURE 16: “TASK DECOMPOSITION FOR ’OBTAINAVAILABLELOGICALMODELS’” ................................................................. 40

FIGURE 17: “TASK DECOMPOSITION FOR ‘’OBTAINSTRUCTURE” ....................................................................................... 40

FIGURE 18: “TASK DECOMPOSITION FOR ‘OBTAINOBSERVATIONS’”................................................................................... 41

FIGURE 19: “TASK DECOMPOSITION FOR ‘OBTAINFEATURESOFINTEREST’” ....................................................................... 41

FIGURE 20: “TASK DECOMPOSITION FOR ‘REGISTERLOGICALMODEL’” .............................................................................. 42

FIGURE 21: “TASK DECOMPOSITION FOR ‘UNREGISTERLOGICALMODEL’” .......................................................................... 43

FIGURE 22: “TASK DECOMPOSITION FOR ‘UPDATELOGICALMODEL’” ................................................................................. 43

FIGURE 23: “TASK DECOMPOSITION FOR ‘REGISTER OGC® WPS SERVER” ..................................................................... 44

FIGURE 24: “TASK DECOMPOSITION FOR ‘OGC® WPS PROCESSES ANALYSIS’” ................................................................ 45

FIGURE 25: “TASK DECOMPOSITION FOR ‘UNREGISTER OGC® WPS SERVER” ................................................................. 46

FIGURE 26: “TASK DECOMPOSITION FOR ‘GET AVAILABLE HYDRO-METEOROLOGICAL FORECAST PROCESSES” ....................... 46

FIGURE 27: “TASK DECOMPOSITION FOR ‘CONSULT HYDROLOGICAL FORECAST” ................................................................ 47

FIGURE 28: “TASK DECOMPOSITION FOR ‘GET AVAILABLE DEMAND FORECAST PROCESSES” ................................................ 47

FIGURE 29: “TASK DECOMPOSITION FOR ‘GET WATER RESOURCES OF A TYPE” .................................................................. 47


FIGURE 30: “TASK DECOMPOSITION FOR ‘EXECUTE A DEMAND FORECAST’” ........................................................................ 48

FIGURE 31: “TASK DECOMPOSITION FOR ‘GET AVAILABLE WATER ALLOCATION PROCESSES’” ............................................... 48

FIGURE 32: “TASK DECOMPOSITION FOR ‘GET CURRENT SCENARIO STATE’” ....................................................................... 49

FIGURE 33: “TASK DECOMPOSITION FOR ‘GET BEHAVIOUR’” ............................................................................................. 49

FIGURE 34: “TASK DECOMPOSITION FOR ‘SET BEHAVIOUR’” ............................................................................................. 50

FIGURE 35: “TASK DECOMPOSITION FOR ‘GET WATER ALLOCATION RECOMMENDATIONS’”.................................................... 50

FIGURE 36: “TASK DECOMPOSITION FOR ‘GET PUMP SCHEDULING RECOMMENDATIONS’” ..................................................... 51

FIGURE 37: "TASK ‘REGISTER LOGICAL MODEL' DESCRIPTION" ........................................................................................ 52

FIGURE 38: "TASK ‘UNREGISTER LOGICAL MODEL’ DESCRIPTION" .................................................................................... 52

FIGURE 39: "TASK ‘OBTAIN AVAILABLE LOGICAL MODELS’ DESCRIPTION" ......................................................................... 52

FIGURE 40: "TASK ‘OBTAIN STRUCTURE' DESCRIPTION" .................................................................................................. 53

FIGURE 41: "TASK ‘OBTAIN FEATURES OF INTEREST’ DESCRIPTION" ................................................................................. 53

FIGURE 42: "TASK ‘OBTAIN OBSERVATIONS’ DESCRIPTION" ............................................................................................. 54

FIGURE 43: "TASK ‘UPDATE LOGICAL MODEL' DESCRIPTION" ........................................................................................... 54

FIGURE 44: “INTERACTIONS BETWEEN AGENTS IN THE ’ADD NEW LOGICAL MODEL IN WATERP FRAMEWORK’ USER STORY” .... 76

FIGURE 45: “INTERACTIONS BETWEEN AGENTS IN THE ‘REMOVE LOGICAL MODEL OF WATERP FRAMEWORK’ USER STORY”.... 76

FIGURE 46: “INTERACTIONS BETWEEN AGENTS IN THE ‘OBTAIN STRUCTURE OF LOGICAL MODEL’ USER STORY”...................... 77

FIGURE 47: “INTERACTIONS BETWEEN AGENTS IN THE ‘OBTAIN AVAILABLE FEATURES OF INTEREST FOR A WATER RESOURCE’

USER STORY” ..................................................................................................................................................... 78

FIGURE 48: “INTERACTIONS BETWEEN AGENTS IN THE ‘OBTAIN AVAILABLE OBSERVATIONS FOR A FEATURE OF INTEREST ’USER

STORY”.............................................................................................................................................................. 78

FIGURE 49: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN OGC® WPS SERVER” ..................................................... 79

FIGURE 50: “INTERACTIONS BETWEEN AGENTS TO DESTROY AN OGC® WPS AGENT” ....................................................... 79

FIGURE 51: “INTERACTIONS BETWEEN AGENTS TO REGISTER AN SPECIFIC OGC® WPS SERVER” ....................................... 80

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

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

FIGURE 54: “INTERACTIONS BETWEEN AGENTS TO EXECUTE HYDRO-METEOROLOGICAL FORECAST PROCESS” ....................... 81

FIGURE 55: “INTERACTIONS BETWEEN AGENTS TO GET OGC® WPS DMS PROCESSES” ................................................... 82

FIGURE 56: “INTERACTIONS BETWEEN AGENTS TO GET WATER RESOURCES” ..................................................................... 82

FIGURE 57: “INTERACTIONS BETWEEN AGENTS TO EXECUTE A DEMAND FORECAST PROCESS” ............................................. 82

FIGURE 58: “INTERACTIONS BETWEEN AGENTS TO GET CURRENT STATE SCENARIO PROCESSES” ......................................... 83


FIGURE 59: “INTERACTIONS BETWEEN AGENTS TO EXECUTE A DEMAND FORECAST PROCESS” ............................................. 83

FIGURE 60: “INTERACTIONS BETWEEN AGENTS TO GET BEHAVIOUR” ................................................................................. 84

FIGURE 61: “INTERACTIONS BETWEEN AGENTS TO SET BEHAVIOUR” .................................................................................. 84

FIGURE 62: “INTERACTIONS BETWEEN AGENTS TO GET WATER ALLOCATION RECOMMENDATIONS PROCESSES”...................... 84

FIGURE 63: “INTERACTIONS BETWEEN AGENTS TO EXECUTE WATER ALLOCATION RECOMMENDATIONS PROCESS” .................. 85

FIGURE 64: “INTERACTIONS BETWEEN AGENTS TO GET PUMP SCHEDULING PROCESSES”..................................................... 85

FIGURE 65: “INTERACTIONS BETWEEN AGENTS TO EXECUTE PUMP SCHEDULING PROCESS” ................................................. 86

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

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

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

FIGURE 69: INTERACTIONS BETWEEN AGENTS TO EXECUTE ‘VALIDATE PUMP SCHEDULING’ PROCESS" ................................. 87

FIGURE 70: “INTERACTION DIAGRAM AMONG AGENTS IN THE THIRD VERTICAL INTEGRATION OF MAS”................................... 89

FIGURE 71: “OGC® WPS MANAGEMENT MESSAGE PROCESSING STATE DIAGRAM” ........................................................... 91

FIGURE 72: “MESSAGE PROCESSING STATE DIAGRAM REGARDING THE PROCESSES’ OPERATION” ........................................ 93

FIGURE 73: “MESSAGE PROCESSING STATE DIAGRAM REGARDING THE ONTOLOGY MANAGEMENT” ....................................... 95

FIGURE 74: “MESSAGE PROCESSING STATE DIAGRAM REGARDING THE ONTOLOGY ISSUES” ................................................. 96

FIGURE 75: “AGENTS HIERARCHY” ................................................................................................................................ 98


Table of tables

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

TABLE 2: "MAS RELEASES" ......................................................................................................................................... 14

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

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

TABLE 5: "‘OBTAIN AVAILABLE FEATURE OF INTEREST FOR A WATER RESOURCE’ USER STORY DESCRIPTION" ........................ 21

TABLE 6: “’OBTAIN AVAILABLE OBSERVATIONS FOR A FEATURE OF INTEREST’ USER STORY DESCRIPTION” ............................. 21

TABLE 7: “’ OBTAIN AVAILABLE LOGICAL MODEL FROM THE WATERP FRAMEWORK’ USER STORY DESCRIPTION” .................... 22

TABLE 8: “’ADD NEW LOGICAL MODEL IN THE WATERP FRAMEWORK’ USER STORY DESCRIPTION” ....................................... 23

TABLE 9: ”’REMOVE LOGICAL MODEL OF THE WATERP FRAMEWORK’ USER STORY DESCRIPTION” ....................................... 24

TABLE 10: “’OBTAIN THE STRUCTURE OF THE LOGICAL MODEL’ USER STORY DESCRIPTION” ................................................. 24

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

TABLE 12: “’CONSULT HYDROLOGICAL FORECAST’ USER STORY DESCRIPTION” .................................................................. 29

TABLE 13: “’REQUEST A DEMAND FORECAST’ USER STORY DESCRIPTION” ......................................................................... 30

TABLE 14: “’REQUEST WATER ALLOCATION’ USER STORY DESCRIPTION”............................................................................ 32

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

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

TABLE 17: “FINAL DRAFT OF IDENTIFIED AGENTS” ........................................................................................................... 39

TABLE 18: “TASK ‘REGISTER OGC® WPS SERVER’ DESCRIPTION” .................................................................................. 54

TABLE 19: “TASK ‘REGISTER OGC® WPS PROCESSES ANALYSIS’ DESCRIPTION” ............................................................. 55

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

TABLE 21: "TASK ‘GET AVAILABLE HYDROLOGICAL FORECAST PROCESSES’ DESCRIPTION” .................................................. 56

TABLE 22: “TASK ‘EXECUTE HYDROLOGICAL FORECAST PROCESS’ DESCRIPTION” .............................................................. 56

TABLE 23: “TASK ‘GET AVAILABLE DEMAND FORECAST PROCESSES’ DESCRIPTION” ............................................................ 57

TABLE 24: “TASK ‘GET WATER RESOURCES OF A TYPE’ DESCRIPTION” .............................................................................. 57

TABLE 25: “TASK ‘EXECUTE A DEMAND FORECAST’ DESCRIPTION” .................................................................................... 57

TABLE 26: “TASK ‘GET AVAILABLE WATER ALLOCATION PROCESS’ DESCRIPTION” ............................................................... 58

TABLE 27: “TASK ‘GET CURRENT SCENARIO STATE’ DESCRIPTION” .................................................................................... 58

TABLE 28: “TASK ‘GET BEHAVIOUR’ DESCRIPTION” ......................................................................................................... 58

TABLE 29: “TASK ‘SET BEHAVIOUR’ DESCRIPTION” .......................................................................................................... 59


TABLE 30: “TASK ‘GET WATER ALLOCATION RECOMMENDATIONS’ DESCRIPTION” ................................................................ 59

TABLE 31: “TASK ‘GET PUMP SCHEDULING RECOMMENDATIONS’ DESCRIPTION” ................................................................. 60

TABLE 32: “TASK-AGENTS DISTRIBUTION ROUND 1” ........................................................................................................ 64

TABLE 33: “’GET AVAILABLE FEATURES OF INTEREST FOR A WATER RESOURCE’ CONVERSATION” ......................................... 65

TABLE 34: “’GET AVAILABLE OBSERVATIONS FOR A FEATURE OF INTEREST’ CONVERSATION” ............................................... 65

TABLE 35: “‘REGISTER A LOGICAL MODEL’ CONVERSATION” ............................................................................................. 66

TABLE 36: “‘UNREGISTER A LOGICAL MODEL’ CONVERSATION” ......................................................................................... 66

TABLE 37: “‘GET STRUCTURE OF A LOGICAL MODEL’ CONVERSATION” ............................................................................... 66

TABLE 38: “‘INTEGRATE AN OGC® WPS SERVER’ CONVERSATION” ................................................................................. 67

TABLE 39: “‘DESTROY OGC® WPS AGENT’ CONVERSATION” ......................................................................................... 67

TABLE 40: “‘REGISTER AN OGC® WPS HF SERVER’ CONVERSATION” ............................................................................. 68

TABLE 41: “’REGISTER AN OGC® WPS DMS SERVER’ CONVERSATION” ......................................................................... 68

TABLE 42: “’REGISTER AN OGC® WPS DSS SERVER’ CONVERSATION" .......................................................................... 68

TABLE 43: “‘UNREGISTER AN OGC® WPS HF SERVER’ CONVERSATION” ......................................................................... 69

TABLE 44: “‘UNREGISTER AN OGC® WPS DMS SERVER’ CONVERSATION” ..................................................................... 69

TABLE 45: “‘UNREGISTER AN OGC® WPS DSS SERVER’ CONVERSATION” ...................................................................... 70

TABLE 46: “’GET HYDRO-METEOROLOGICAL FORECAST PROCESSES’ CONVERSATION” ........................................................ 70

TABLE 47: “‘EXECUTE HYDRO-METEOROLOGICAL FORECAST PROCESS’ CONVERSATION” .................................................... 70

TABLE 48: “’GET DEMAND FORECAST PROCESSES’ CONVERSATION” ................................................................................. 71

TABLE 49: “‘GET WATER RESOURCES’ CONVERSATION” ................................................................................................... 71

TABLE 50: “‘EXECUTE HYDROLOGICAL FORECAST PROCESS’ CONVERSATION”.................................................................... 71

TABLE 51: “’GET CURRENT STATE SCENARIO PROCESSES’ CONVERSATION” ...................................................................... 72

TABLE 52: “‘EXECUTE CURRENT STATE SCENARIO PROCESS’ CONVERSATION” ................................................................... 72

TABLE 53: “’GET BEHAVIOUR’ CONVERSATION” ............................................................................................................... 72

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

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

TABLE 56: “‘EXECUTE WATER ALLOCATION RECOMMENDATIONS PROCESS’ CONVERSATION” ............................................... 73

TABLE 57: “’GET PUMP SCHEDULING PROCESSES’ CONVERSATION” .................................................................................. 74

TABLE 58: “‘EXECUTE PUMP SCHEDULING PROCESS’ CONVERSATION” .............................................................................. 74

TABLE 59: “GET ’VALIDATE PUMP SCHEDULING PROCESSES’ CONVERSATION” ................................................................... 74

TABLE 60: “‘EXECUTE VALIDATE PUMP SCHEDULING PROCESS’ CONVERSATION” ................................................................ 75


TABLE 61: “‘CHECK VALIDATE PUMP SCHEDULING PROCESS STATE’ CONVERSATION” .......................................................... 75

TABLE 62: “‘GET VALIDATE PUMP SCHEDULING PROCESS RESULTS’ CONVERSATION” .......................................................... 75

TABLE 63: “BDI MULTI AGENT PLATFORM CHARACTERISTICS” .......................................................................................... 99


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 Belief Desire Intention (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 was also applied in the second deliverable of the series (See

D7.2.2 “Implementation of MAS” in Section 2) to implement the second prototype of the MAS that was

finished by the MS5 Second Vertical Integration (M23, August 2014). This second prototype integrated

the rest of building blocks completing the integration of all components of the WatERP project and

providing the whole platform. Basically, the new building blocks added to the WatERP framework were:

(i) Demand Management System (DMS); (ii) Decision Support System (DSS) and (iii) Hydro-

Meteorological Forecast (HMF).

The last iteration of the MAS-CommonKADS methodology has been applied in this third deliverable with

the aim of refining the previous implementations of MAS. Mainly, this iteration has been focused on


improving previous iterations because no new building blocks have been integrated during MS6 Third

Vertical Integration (M30, March 2015).

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, Section 4 presents the results of the

design phase focusing on the network agents. 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. Basically the actors identified are the

same than in the previous deliverable (D7.2.1 “Implementation of MAS” in Section 4.1.1 and D7.2.2

“Implementation of MAS” in Section 2.2) and hence no new actors to interact with external software

were identified. The reason is that all building blocks have been fully integrated in the MS5 Second

Vertical Integration, allowing for their complete identification. These previously identified actors

correspond to the ‘OMP’, the ‘Sesame’, the ‘OGC SOS’, the ‘OGC WPS HF’, the ‘OGC WPS DMS’ and

the ‘OGC WPS DSS’ 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

third actor, ‘OGC SOS’, is responsible for managing the OGC® SOS server interaction providing

access to the available observations and their data. Finally, the ‘OGC WPS HF’, the ‘OGC WPS DMS’

and ‘OGC WPS DSS’ actors are designed to interact with the OGC WPS servers following the

guidelines presented in D2.3 “Open Interface Specification” in Section 3.2.

Below, Table 3 summarizes the results of the second step of the conceptualization phase where the

actors are described and 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.

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 hydro-meteorological

forecast type that is capable of generating hydrological and

meteorologrical forecasts 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.2 Identification of user stories

This section is focused on presenting the identified 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 were used. Only active actors were taken into account since passive actors cannot initiate

user stories. Moreover, the information presented in D6.2 “Open Management Platform” was 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 following essential user stories were identified in the previous iterations of this deliverable: (i) obtain

available logical models in WatERP framework; (ii) obtain structure of a logical model; (iii) obtain

available observations for a feature of interest; (iv) obtain available features of interest for a water

resource; (v) add new logical model in WatERP framework; (vi) remove logical model of WatERP

framework; (vii) ‘OGC® WPS’ server integration (HF, DSS and DMS); (viii) unregister ‘OGC® WPS’

server (HF, DSS and DMS); (ix) consult a hydro-meteorological forecast; (x) consult a demand forecast;

(xi) consult water resources allocation; and (xii) consult a pump scheduling. Moreover, Table 4 contains

the list of these user stories identified during the first and second iteration of the MAS development.

No new user stories were identified during the last period, since all OMP operation defined in the D6.2

“Open Management Platform” are covered by the current user stories.

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 hydro-meteorological forecast

Consult a demand forecast

Consult water resources allocation

Consult a pump scheduling

Table 4: “User stories involved in the MAS”

Below, all user stories identified during the iterations are depicted in the Section 2.3.

2.3 Description of user stories

The aim of this section is to analyse each user story presented in Table 4 of Section 2.2. Firstly, 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.2. 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 user stories developed during the iterations of the MAS-

CommonKADS methodology. The ‘OGC® WPS Server integration (HF, DSS and DMS)’ user story is

initiated by the OMP and requires an initial interaction 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 to the daily operations (‘consult pump scheduling’) interacts with the

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

Another 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

hydro-meteorological 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 schedules 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).

It is important to note that the number user stories identified during first and second year has not

increased during the third year because the whole integration of the building blocks during the second

year allowed for a complete identification of all the stories. The only modifications are related to their

sequence diagram, which has been enhanced. Mainly these changes are: (i) fix the logical model agent

involvement on ‘add new logical model in the WatERP framework’ user story and (ii) support to

asynchronous execution of the pumping schedule validation in order to assure the user experience and

improve the usability of the platform.


Figure 1: “Overview of the user stories”

2.3.1 ‘Obtain available feature of interest for a water resource’ user story

N. User Story 1

User Story Obtain available features of interest for a water resource

Summary OMP asks the MAS available feature of interest for a water resource

Actors OMP, Logical model

Pre-conditions None

Description

The OMP requests to the MAS the available features of interest for a water resource using the

specific water resource identifier and the logical model identifier passed as a parameter. Then

MAS recovers and returns the features of interest of the water resource using the logical

model. If the logical model does not exist or the water resource does not exist in the logical

model, an exception is thrown.


Exceptions

Not existent logical model exception is thrown if the logical model does not exist in the

WatERP framework

Not existent water resource exception is thrown if the water resource does not exist in the

logical model

Post-conditions None

Table 5: "‘Obtain available feature of interest for a water resource’ user story description"

Figure 2: “’Obtain available feature of interest for a water resource’ interactions”

2.3.2 ‘Obtain available observations for a feature of interest’ user story

N. User Story 2

User Story Obtain available observations for a feature of interest

Summary OMP asks the MAS for the available observations for a feature of interest


Pre-conditions None

Description

The OMP requests the available observations for a feature of interest to the MAS. The OMP

provides the MAS the specific feature of interest and the logical model to consult, and then

MAS recovers and returns observations of the feature of interest. If the logical model does not

exist or feature of interest does not exist in the logical model an exception is thrown.

Exceptions

Not existent logical model exception is thrown if the logical model does not exist in the

WatERP framework

Not existent feature of interest exception is thrown if the feature of interest does not exist in the

logical model


Table 6: “’Obtain available observations for a feature of interest’ user story description”

OMP actor MAS Logical model actor

alt

getFeaturesOfInterest(logical model, water

resource)

getFeaturesOfInterest(water resource)

response(features of interest)

response(features of interest)

fail(cause)


Figure 3: “’Obtain available observations for a feature of interest’ interactions”

2.3.3 ‘Obtain available logical models in WatERP framework’ user story

N. User Story 3

User Story Obtain available logical model from the WatERP framework

Summary OMP asks the MAS for all available logical models registered in the WatERP framework

Actors OMP

Pre-conditions None

Description The OMP requests all available logical models registered in the WatERP framework to the MS.

The MAS knows the registered logical models and reply it to the OMP.

Exceptions None


Table 7: “’ Obtain available logical model from the WatERP framework’ user story description”

Figure 4: “’ Obtain available logical model from the WatERP framework’ interactions”


alt

getObservations(logical model, feature of

interest)

getObservations(feature of interest)

response(observations)


fail(cause)

OMP actor MAS

obtainLogicalModels()

response(list logicalModels)


2.3.4 ‘Add new logical model in the WatERP framework’ user story

This user story has been modified respect previous versions because a mistake was identified during

the last iteration of the MAS-CommonKADS methodology. Basically the logical model actor, which is

needed to check if the new logical model exists or not, was missing. It has been added in this iteration.

N. User Story 4

User Story Add new logical model in the WatERP framework

Summary MAS registers a logical model in the system so that it can be used in the future


Pre-conditions None

Description The OMP registers a logical model in the system. If the logical model does not exist in the

system, it is registered and integrated. Otherwise, an exception is thrown.

Exceptions Existent logical model exception is thrown if the logical model exists in the system

Post-conditions The logical model is integrated in the system hence it is available for request

Table 8: “’Add new logical model in the WatERP framework’ user story description”

Figure 5: "’Add new logical model in the WatERP framework’ interactions"

2.3.5 ‘Remove logical model of the WatERP framework’ user story

N. User Story 5

User Story Remove logical model of the WatERP framework

Summary MAS unregisters a logical model from the system

Actors OMP

Pre-conditions None

OMP actor MAS

alt

register(logical model)

response()

fail(cause)

Logical Model

actor

access()


Description The OMP unregisters a logical model from the system. If the logical model exists in the system,

it is removed. Otherwise, an exception is thrown

Exceptions Not existent logical model exception is thrown if the logical model does not exist in the

WatERP framework

Post-conditions The logical model is removed of the WatERP framework

Table 9: ”’Remove logical model of the WatERP framework’ user story description”

Figure 6: “’Remove logical model of the WatERP framework’ interactions”

2.3.6 ‘Obtain the structure of the logical model’ user story

N. User Story 6

User Story Obtain the structure of the logical model

Summary The OMP asks the MAS for a logical model’s structure and it is returned


Pre-conditions None

Description

The OMP requests to the MAS the logical model structure of a particular ontological instance.

The MAS recovers the structure and returns it with all water resources, their relations and

water resources types. If the logical model does not exist, an exception is thrown.

Exceptions Not existent logical model exception is thrown if the logical model does not exist in the

WatERP framework


Table 10: “’Obtain the structure of the logical model’ user story description”

OMP actor MAS

alt

unregister(logical model)

response()

fail(cause)


Figure 7: “’Obtain the structure of the logical model’ interactions”

2.3.7 ‘Request pumping schedule’ user story

This user story is based on Section 2.3.2.1 of D6.2 “Open Management Platform” and it has been

modified because the validation operation of the pumping schedule was carried out in a synchronous

way previously. The implementation and tests of the DSS (see 7.5.2 “Implementation of the Water DSS”

in Section 5.3) has shown large execution time periods, between five and ten minutes, hence an

asynchronous execution is more appropriated because it allows a parallel use of the OMP during the

execution of the process. Basically, two operations have been added to the MAS, one to check if the

execution of the asynchronous process has been finished by using its asynchronous execution

identifier; and another to get the asynchronous result of the execution by using its asynchronous

execution identifier.

N. User Story 7

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.

Pumping schedule validation processes are integrated in the WatERP platform.

Demand forecast processes are integrated in the WatERP platform.

Hydro-meteorological 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, 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


alt

getStructure(logical model)

getStructure()

response(structure)

response(structure)

fail(cause)


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 which is executed in an

asynchronous way. Hence, an operation to check if the process has finished, other to recover

the asynchronous 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.


Table 11: “‘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)

alt response(observations)

fail(cause)

alt response(water resources)

fail(cause)

OMP actor MAS Sesame actor

getWaterResources(logical model id,

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

[source, sink, storage])

response(water resources)

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(Input requirements)

getServices(Input requirements)

response(services)

response(asynchronous execution id)


getAsynchronousExecution(asynchronous

execution id) getAsynchronousExecution(asynchronous

execution id)

isFinished(asynchronous execution id)isFinished(asynchronous execution id)

isFinished(finished)isFinished(finished)


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)



getAsynchronousExecution(asynchronous

execution id) getAsynchronousExecution(asynchronous

execution id)

isFinished(asynchronous execution id)isFinished(asynchronous execution id)

isFinished(finished)isFinished(finished)


2.3.8 ‘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 8

User Story Request a hydro-meteorological forecast.

Summary The water manager consults a hydro-meteorological forecast.

Actors OMP, Hydro-meteorological Forecast.

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

integrated in the WatERP framework.

Description

The OMP collects the hydro-meteorological forecast processes available in the WatERP

framework and presents this information to the water manager. Then, the water manager

selects a hydro-meteorological 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 hydro-meteorological 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 hydro-meteorological forecast thrown an exception.

Post-conditions None.

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

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

2.3.9 ‘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 9

User Story Request a demand forecast.

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)


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 ‘hydro-meteorological 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

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

precipitation 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 hydro-meteorological forecast thrown an exception.

The execution of the demand forecast thrown an exception.


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


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


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)


OGC WPS HF

actor

getHF(geometry)

response(HF)

OGC SOS

actor

getObservations([observation id])



2.3.10 ‘Request water resources allocation’ user story

The user story described on this section refers to 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 about water resources management to match the supply and the demand are

presented.

N. User Story 10

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 be recovered 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.


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


Figure 12: “’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)


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([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(services)


Figure 13: “’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.3.11 ‘OGC® WPS server integration (HF, DSS and DMS)’ user story

This user story is based on Section 3.3.2 of D2.3 “Open Interface Specification”.

N. User Story 11

User Story ‘OGC® WPS’ server integration

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

capabilities on WatERP.

Actors OMP, OGC® WPS, HF, 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 (HF, 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 in the WatERP framework. Therefore, its features are

ready to be executed in WatERP.

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


Figure 14: “’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.3.12 ‘Unregister OGC® WPS server (HF, DSS and DMS)’ user story

This user story is based on Section 3.3.2 of D2.3 “Open Interface Specification”.

N. User Story 12

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 in 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 the OMP if the ‘OGC® WPS’ server has been successfully

unregistered.

Exceptions The URL corresponding to the ‘OGC® WPS’ server is not registered in the WatERP

framework.

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

are removed and are no longer accessible in the WatERP framework.

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

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

OMP actor MAS

alt

unregister(url OGC WPS)

response()

fail(cause)


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 consists of the following 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 depending on 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 Section 3.3, uses the identified task (see Section 3.2) to complete

the identified agents during this section.

In the same way of previous section, the software agent identification has not been modified, hence the

presented results are a summary of the previous versions of this iterative deliverable.

Table 17 presents the agents involved, which are extracted from actors’ user stories (see Section 2).

Basically, the table contains the agents identified during the first and second iterations, since the third

iteration has been focused on refining the MAS as it was initially commented in the deliverable. The

detected agents during the iterative process are: (i) ‘OMP’ that is an external agent who represents the

water manager; (ii) ‘OMP Gateway’ that is an internal agent which is responsible for managing the outer

interactions generated by the ‘OMP’ agent; (iii) ‘Sesame’ that is the internal agent responsible for

interacting with the logical model; (iv) ‘OGC® SOS’ that is the internal agent responsible for managing

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

the interaction with the ‘OGC® WPS’ agent containing hydro-meteorological forecast processes; (vi)

‘OGC® WPS DMS’ agent, which is another internal agent responsible for interacting with an ‘OGC®

WPS’ agent that stores the demand management processes; and (vii) ‘OGC® WPS DSS’, which is the

agent responsible for managing the ‘OGC® WPS’ server that incorporates the decision support

processes. All specific WPS agents (‘OGC® WPS HF’, ‘OGC® WPS DSS’ and ‘OGC® WPS DMS’) and

‘OGC® SOS’ agent exchange information with external actors (‘OGC® WPS’ servers and ‘OGC® SOS’

server respectively). It is important to note that the ‘OGC® WPS’ and ‘OGC® SOS’ external actors do


not insert new MAS goals nor modify them, 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, Table 17 presents the final draft of the identified agents, 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 hydro-meteorological 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 17: “Final draft of identified agents”

3.2 Task modelling

The aim of this step is to create 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 for each of them.

In this final version of the deliverable the tasks have been modified with respect to the tasks presented

in D7.2.1 and D7.2.2 “Implementation of MAS”, mainly by adding the interactions with the Directory

Facilitator and Agent Management Service agents’ (see Section 4) in the tasks. Moreover, the

asynchronous process execution has been added to facilitate the execution of long process such as


‘validate pump scheduling’ task. Finally, minor changes have been introduced in order to solve the bugs

detected on previous versions of this deliverable.

Task 1 ‘Obtain available logical models in WatERP framework’ (Figure 16) is focused on recovering

the current registered logical models (see Table 15 and Figure 14). The task ‘Obtain available water

logical models’ contains 3 subtasks which are sequential: (i) ‘receive request’; (ii) ‘obtain logical models’

and (iii) ‘return response’.

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

the input parameters shall be extracted.

‘Obtain logical models’ which asks the Directory Facilitator network agent (see Section 4) to

recover the current registered logical models.

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

all tasks which need to return information.

Figure 16: “Task decomposition for ’ObtainAvailableLogicalModels’”

Task 2 ‘Obtain structure’ (Figure 17) is a consequence of the ‘obtain structure of logical model’ user

story (see Table 15 and Figure 14). The task ‘Obtain structure’ contains 4 subtasks which are

sequential: (i) ‘receive request’; (ii) ‘obtain logical model agent’; (iii) ‘obtain structure’ and (iv) ‘return

response’.

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

‘Obtain logical model agent’ which asks the Directory Facilitator network agent (see Section 4)

who is the agent responsible for managing a logical model.

‘Obtain structure’ which obtains the structure of the logical model using the agent identified

previously.

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

Figure 17: “Task decomposition for ‘’ObtainStructure”

Task 3 ‘Obtain observations’ (Figure 18) is a consequence of the ‘obtain available observations for a

feature of interest’ user story (see Table 15 and Figure 14). The task ‘Obtain observations’ contains 4

subtasks which are sequential: (i) ‘receive request’; (ii) ‘obtain logical model agent’; (iii) ‘obtain

observations’ and (iv) ‘return response’.

ObtainAvailableLogicalModels

ReceiveRequest-1 ObtainLogicalModels ReturnResponse-3

ReceiveRequest-1 ReturnResponse-4

ObtainStructure

GetStructure-3ObtainLogicalModelAgent-2





‘Obtain observations’ which obtains the available observations of the logical model using the

agent identified previously.


Figure 18: “Task decomposition for ‘ObtainObservations’”

Task 4 ‘Obtain Features of Interest’ (Figure 19) is a consequence of the ‘obtain available feature of

interest for a water resource’ user story (see Table 15 and Figure 14). The task ‘Obtain Features of

Interest’ contains 4 subtasks which are sequential: (i) ‘receive request’; (ii) ‘obtain logical model agent’

(iii) ‘obtain features of interest’ and (iv) ‘return response’.




‘Obtain observations’ which obtains the available observations of the logical model using the

agent identified previously.

‘Obtain features of interest’ which obtains the available the features of interest for a water

resource using the agent identified previously.


Figure 19: “Task decomposition for ‘ObtainFeaturesOfInterest’”

Task 5 ‘Register Logical Model’ (Figure 20) is a consequence of the ‘Add new logical model in

WatERP framework’ user story (see Table 15 and Figure 14). The task ‘Register logical model’ is

divided in 3 subtasks which are sequential: (i) ‘receive request’; (ii) ‘register’ and finally (iii) ‘return

response’.


‘Register’ is a subtask based in three subtasks:

o ‘Check existence logical model’ which is necessary because if a logical model is

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


ObtainObservations

ObtainObservations-3ObtainLogicalModelAgent-2


ObtainFeaturesOfInterest

ObtainFeaturesOfInterest-3ObtainLogicalModelAgent-2


exception should be thrown. This task uses the search operations of the Directory

Facilitator network agent (see Section 4).

o The following subtask, ‘register’, is responsible for creating a new logical model agent

to supervise the logical model using the Agent Management Service network agent.

o The ‘register’ task, is responsible for enlisting the new logical model service through

Directory Facilitator network agent in the WatERP framework with the aim of being

accessible for WatERP platform.

o The last subtask of ‘register’ is ‘update cache’, whose purpose is to improve the

performance of the WatERP platform by reducing the response time. All logical models

are cached after being registered. The agent responsible for this task needs semantic

capabilities in order to ask for the logical model instantiation.


Figure 20: “Task decomposition for ‘RegisterLogicalModel’”

Task 6 ‘Unregister Logical Model’ (Figure 21) is a consequence of the ‘remove logical model of

WatERP framework’ user story (see Table 15 and Figure 14). The task ‘Unregister Logical Model’

contains 3 subtasks which are sequential: (i) ‘receive request’; (ii) ‘unregister’; and (iii) ‘return response’.


‘Unresgister’ is a subtask that is based in the next two subtasks

o ‘Check existence logical model’ checks if a logical model to be removed exists in the

WatERP framework. Furthermore, if the logical model does not exist, an exception is

thrown.

o ‘Unregister’. If the logical model exists, that is, the previous task has been executed

successfully, then the logical model is unregistered of the WatERP framework using

Directory Facilitator by the ‘unregister’ task. After the execution of this task the logical

model will not be available in the WatERP framework.



RegisterLogicalModel

Register-2

CheckExistenceLogicalModel-2.1 CreateLogicalModelAgent-2.2 Register-2.3 UpdateCache-2.4


Figure 21: “Task decomposition for ‘UnregisterLogicalModel’”

Task 7 ‘Update Logical Model’ (Figure 22). This task has 2 subtasks, which are sequential: (i) ‘receive

request’ and (ii) ‘update cache’.


‘Update cache’. It creates and stores a cached copy of the logical model in the MAS in order to

speed up the access to the semantic information.

Figure 22: “Task decomposition for ‘UpdateLogicalModel’”

Task 8 ‘Register OGC® WPS Server’ (Figure 23) represents the tasks subdivision of the ‘OGC® WPS

Server integration (HF, DSS and DMS)’ user story (See Table 15 and Figure 14). 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. This check operation is performed through Directory Facilitator

network agent who manages the available services in the WatERP platform.

‘Check OGC® WPS server type’ task is responsible for analysing 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’, which is responsible for registering the new ‘OGC® WPS’ server in the

WatERP framework for being accessible through Directory Facilitator network agent.

o ‘instantiate a specific OGC® WPS’, which instantiates a new agent using by Agent

Management Service agent network which fits with the type of the integrated ‘OGC®

WPS’ server (‘OGC® WPS HF’ agent, ‘OGC® WPS DSS’ agent or ‘OGC® WPS DMS’

UnregisterLogicalModel

ReceiveRequest-1 ReturnResponse-3Unregister-2

CheckExistenceLogicalModel-2.1 Unregister-2.2

UpdateLogicalModel

ReceiveRequest-1 UpdateCache-2


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 that need to return information.

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

Task 9 ‘OGC® WPS Processes Analysis’ (Figure 24) 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 15 and Figure 14). 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 parameters 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 registered changes, such as removing a process.

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

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

RegisterOGCWPSServer

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

InstantiateSpecificAgent-4.2 UpdateCache-4.3

CheckOGCWPSServerType-3

Register-4.1


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. The registering

process is performed by using Directory Facilitator network agent.

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

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

server (HF, DSS and DMS)’ user story (See Table 16 and Figure 14). The task ‘Unregister OGC® WPS

server’ is divided in 3 sequential subtasks: (i) ‘receive request’; (ii) ‘unregister’; and finally (iii) ‘return

response’.


‘Unregister’ is a subtask based in three subtasks:

o ‘Check existence OGC® WPS Server’ checks if ‘OGC® WPS’ Server exists through

Directory Facilitator network agent to be removed of 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.

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

OGCWPSProcessesAnalysis

ReadProcesses-1 RegisterProcess-4ReadProcessDescription-2

RegisterOnYellowPages-4.2

EvaluateProcess-3

RegisterOnWatERPOntology-4.1


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

Task 11 ‘Get available Hydro-meteorological Forecast Processes’ (Figure 26) is a consequence of

the ‘Consult a hydro-meteorological forecast’ user story (See Table 12 and Figure 10). The task ‘Get

available hydro-meteorological forecast processes’ is divided into three sequential subtasks: (i) ‘receive

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


‘Get available hydro-meteorological forecast processes’ is responsible for retrieving the

runnable hydro-meteorological processes stored on the runnable processes cache.


Figure 26: “Task decomposition for ‘Get available hydro-meteorological forecast processes”

Task 12 ‘Get Hydro-meteorological Forecast’ (Figure 27) is a consequence of the ‘Consult a hydro-

meteorological forecast’ user story (See Table 12 and Figure 10). The ‘execute hydro-meteorological

forecast’ task is divided into 4 sequential subtasks: (i) ‘receive request’; (ii) ‘get OGC® WPS server’; (iii)

‘execute hydro-meteorological 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 hydro-meteorological forecast process’ is a subtask made up of two subtasks and it is

responsible for executing the hydro-meteorological 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. Moreover, the Directory Facilitator network agent is used in order

to link the inputs with the corresponding agent.

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 27: “Task decomposition for ‘Consult hydrological forecast”

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

demand forecast’ user story (See Table 13 and Figure 11). 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 28: “Task decomposition for ‘Get available demand forecast processes”

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

story (See Table 13 and Figure 11) and ‘Consult water allocation’ user story (See Table 14, Figure 12

and Figure 13). 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 29: “Task decomposition for ‘Get water resources of a type”

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

user story (See Table 13 and Figure 11). 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 precipitation

forecasts provided by the hydro-meteorological forecast systems to provide 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. Moreover, the Directory Facilitator network agent is used in order to link the

inputs with the corresponding agent.


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

parameters’.


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

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

water allocation’ user story (See Table 14, Figure 12 and Figure 13). 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 31: “Task decomposition for ‘get available water allocation processes’”

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

user story (See Table 14, Figure 12 and Figure 13). The task ‘Get current scenario state’ is divided into

ExecuteDemandForecast

ReceiveRequest-1 ReturnResponse-4GetOGCWPSServer-2

Execute-3.2

ExecuteDemandForecastProcess-3

GetInputParameters-3.1

GetAvailablewaterAllocationProcesses

ReceiveRequest-1 ReturnResponse-3GetAvailableWaterAllocationProcesses-2


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

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


‘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 32: “Task decomposition for ‘get current scenario state’”

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

Table 14, Figure 12 and Figure 13). 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 33: “Task decomposition for ‘get behaviour’”

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

Table 14, Figure 12 and Figure 13). The task ‘Set behaviour’ is divided into three sequential subtasks:

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


GetCurrentScenarioState


Execute-3.2

ExecuteGetCurrentScenarioProcess-3


GetBehaviour

ReceiveRequest-1 ReturnResponse-3GetBehaviour-2


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

allocation decision-making in the ontology.

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

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

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

water allocation’ user story (See Table 14, Figure 12 and Figure 13). 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. Moreover, the Directory Facilitator is used

in order to link the inputs with the corresponding agent.

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 35: “Task decomposition for ‘get water allocation recommendations’”

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

scheduling’ user story (See Table 14, Figure 12 and Figure 13). The task ‘Get pump scheduling

SetBehaviour

ReceiveRequest-1 ReturnResponse-3SetBehaviour-2

GetWaterAllocationRecommendations


Execute-3.2

ExecuteWaterAllocationRecomProcess-3



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


‘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. Moreover, the

Directory Facilitator is used in order to link the inputs with the corresponding agent.

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 36: “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 RegisterLogicalModel

Goal Register a logical model in order to be accessible in the WatERP framework

Description

The task checks if logical model exists in the WatERP framework. If this does not exist, then it

registers the logical model and updates the semantic knowledge about the registered logical

model.

Input Logical model

Outputs True or false. If the logical model has been registered in the WatERP framework

Pre-conditions Received request to register a logical model

GetPumpSchedulingProcesses


Execute-3.2

ExecutePumpSchedulingRecomProcess-3



Post-conditions The logical model is integrated in the WatERP framework.

The semantic cache of logical model is updated

Super Task None

Sub Task ReceiveRequest-1, Register-2 (CheckExistenceLogicalModel-2.1, CreateLogicalModelAgent-

2.2, Register-2.3, UpdateCache-2.4), ReturnResponse-3

Belief Logical model identifier

Figure 37: "Task ‘Register Logical Model' description"

N. Task 2

Name UnregisterLogicalModel

Goal Unregister a logical model of the WatERP framework

Description

The task checks if logical model exists in the WatERP framework. If this exists, then it

unregisters the logical model and updates the semantic knowledge deleting logical model

information of the unregistered logical model.

Input Logical model

Outputs True or false. If the logical model has been unregistered in the WatERP framework

Pre-conditions Received request to unregister a logical model

Post-conditions The logical model is unregistered in the WatERP framework hence it is not accessible through

the platform

Super Task None

Sub Task ReceiveRequest-1, Unregister-2 (CheckExistenceLogicalModel-2.1, Unregister-2.2),

ReturnResponse-3

Decomposition

type The OMP requests the logical model


Figure 38: "Task ‘Unregister Logical Model’ description"

N. Task 3

Name ObtainAvailableLogicalModels

Goal Recover all available registered logical models

Description The task obtains all registered logical models which have been registered in the WatERP

framework.

Input None

Outputs List of available logical models

Pre-conditions Received request to obtain the available logical models


Super Task None

Sub Task ReceiveRequest-1, ObtainLogicalModelAgent-2, ObtainLogicalModels-3, ReturnResponse-4

Belief None

Figure 39: "Task ‘Obtain Available Logical Models’ description"


N. Task 4

Name ObtainStructure

Goal Recover the structure of logical model

Description First, the task obtains the logical model from which the structure wants to be recovered. Then,

that logical model is used to obtain its structure.

Input Logical model

Outputs Structure of the logical model

Pre-conditions Received request to obtain the logical model structure


Super Task None

Sub Task ReceiveRequest-1, ObtainLogicalModelAgent-2, ObtainStructure-3, ReturnResponse-4


Figure 40: "Task ‘Obtain Structure' description"

N. Task 5

Name ObtainFeaturesOfInterest

Goal Recover the features of interest for a logical model

Description First, the task obtains the logical model from which the features of interest want to be

recovered. The logical model is used to obtain its available features of interest.

Input Logical model, water resource

Outputs List of features of interest

Pre-conditions Received request to obtain the logical model features of interest


Super Task None

Sub Task ReceiveRequest-1, ObtainLogicalModelAgent-2, ObtainFeaturesOfInterest-3,

ReturnResponse-4


Figure 41: "Task ‘Obtain Features of Interest’ description"

N. Task 6

Name ObtainObservations

Goal Recover the observations for a feature of interest

Description

First, the task obtains the logical model from which the observations of a feature of interest

want to be recovered. The logical model is used to obtain its available observations for a

concrete feature of interest.

Input Logical model, feature of interest

Outputs List of observations

Pre-conditions Received request to obtain the observations for a feature of interest


Super Task None

Sub Task ReceiveRequest-1, ObtainLogicalModelAgent-2, ObtainObservations-3, ReturnResponse-4


Belief Logical model identifier and feature of interest

Figure 42: "Task ‘Obtain Observations’ description"

N. Task 7

Name UpdateLogicalModel

Goal Refresh semantic knowledge of a logical model

Description

This task updates the semantic knowledge of a logical model refreshing the information about

its water resources, features of interest, observations if it is required. This information is used

to improve the response time of the MAS due to the acquired knowledge of the logical models

which reduces the communications overhead.

Input None

Outputs None

Pre-conditions Received request

Post-conditions The semantic cache of logical model is updated

Super Task None

Sub Task ReceiveRequest-1, UpdateCache-2


Figure 43: "Task ‘Update Logical Model' description"

N. Task 8

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.

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 18: “Task ‘Register OGC® WPS server’ description”

N. Task 9

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 19: “Task ‘Register OGC® WPS processes analysis’ description”

N. Task 10

Name Unregister ‘OGC® WPS’ server (HF, 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 20: "Task ‘Unregister OGC® WPS server (Hydrological Forecast, DSS and DMS)’ description"

N. Task 11

Name Get available hydro-meteorological forecast processes.

Goal Get the runnable hydro-meteorological forecast processes.


Description This task retrieves the runnable hydro-meteorological processes stored in the runnable

processes cache of the WatERP platform.

Input None.

Outputs Hydro-meteorological forecast processes.

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


Super Task None.

Sub Task Receive request-1, Get available hydro-meteorological forecast processes-2,

ReturnResponse-3.

Belief Runnable processes.

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

N. Task 12

Name Execute Hydro-meteorological forecast process.

Goal Execute a hydro-meteorological forecast process.

Description

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

meteorological 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 Hydro-meteorological forecast process identifier, geometry.

Outputs Result of the executed hydro-meteorological forecast process.

Pre-conditions Received request to execute a hydro-meteorological forecast process.


Super Task None.

Sub Task Receive request-1, Get OGC® WPS Server-2, Execute hydro-meteorological forecast process-

3 (Get input parameters-3.1, Execute-3.2), Return response-4

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

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

N. Task 13

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

cache of the WatERP platform.

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 23: “Task ‘Get available demand forecast processes’ description”

N. Task 14

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 24: “Task ‘Get water resources of a type’ description”

N. Task 15

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 25: “Task ‘Execute a demand forecast’ description”

N. Task 16

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

cache of the WatERP platform.

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 26: “Task ‘Get available water allocation process’ description”

N. Task 17

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 27: “Task ‘get current scenario state’ description”

N. Task 18

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 28: “Task ‘Get behaviour’ description”

N. Task 19

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 29: “Task ‘Set behaviour’ description”

N. Task 20

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



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 30: “Task ‘Get water allocation recommendations’ description”

N. Task 21

Name Get pump scheduling recommendations

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

process

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



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 31: “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 improvements performed in the previous section (Section 3.2) with the addition of the network

agents, such as Directory Facilitator and Agent Management Service and the identification of new

subtasks have implied a new review of the current section. Moreover, this revision has allowed refining

the assignation table between internal agents and tasks/subtasks fixing minor errors.

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

Directory

Facilitator

Agent

Management

Service

Ta

sk

1

1 Receive request Yes

2 Obtain Logical

Models

Yes

3 Return response Yes

Ta

sk

2


2 Obtain Logical

Model Agent

Yes

3 Obtain Structure Yes


Ta

sk

3


2 Obtain Logical

Model Agent

Yes

3 Obtain

Observations

Yes


Ta

sk

4


2 Obtain Logical

Model Agent

Yes

3 Obtain features of

interest

Yes


Tasks - Subtasks \

Internal agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS

DSS

Directory

Facilitator

Agent

Management

Service


Ta

sk

5

1 Receive Request Yes

2 Register Yes

2.1 Check Existence

Logical Model

Yes

2.2 Create Logical

Model agent

Yes

2.2 Register Yes

2.3 Update Cache Yes

3 Return Response Yes

Ta

sk

6


2 Unregister Yes

2.1 Check Existence

Logical Model

Yes

2.2 Unregister Yes Yes

3 Return Response Yes

Ta

s

k 7


2 Update cache Yes Yes

Ta

sk

8


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


Ta

sk

9

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 Yes


Tasks - Subtasks \

Internal agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS

DSS

Directory

Facilitator

Agent

Management

Service

pages

Ta

sk

10


2 Unregister Yes

2.1 Check existence

OGC® WPS Server

Yes

2.2 Unregister Yes Yes

2.3 Evaluate

processes

Yes Yes Yes


Ta

sk

11


2 Get available

hydrological forecast

processes

Yes


Ta

sk

12


2 Get OGC® WPS

Server

Yes

3 Execute

hydrological forecast

process

Yes

3.1 Get input

parameters

Yes

3.2 Execute Yes


Ta

sk

13


2 Get available

demand forecast

processes

Yes


Ta

sk

14 1 Receive request Yes

2 Get water resources Yes


Ta

sk

15


2 Get OGC® WPS

Server

Yes

3 Execute demand

forecast process

Yes


Tasks - Subtasks \

Internal agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS

DSS

Directory

Facilitator

Agent

Management

Service

3.1 Get input

parameters

Yes Yes

3.2 Execute Yes


Ta

sk

16


2 Get available water

allocation processes

Yes


Ta

sk

17


2 Get OGC® WPS

Server

Yes

3 Execute get current

scenario process

Yes

3.1 Get input

parameters

Yes Yes

3.2 Execute Yes


Ta

sk


2 Get behaviour Yes


Ta

sk


2 Set behaviour Yes


Ta

sk

20


2 Get OGC® WPS

Server

Yes

3 Execute water

allocation

recommendations

process

Yes

3.1 Get input

parameters

Yes Yes

3.2 Execute Yes


Ta

sk


2 Get OGC® WPS

Server

Yes


Tasks - Subtasks \

Internal agents

OMP

Gateway

Sesame OGC®

SOS

OGC®

WPS

OGC®

WPS

HF

OGC®

WPS

DMS

OGC®

WPS

DSS

Directory

Facilitator

Agent

Management

Service

3 Execute pump

scheduling

recommendations

process

Yes

3.1 Get input

parameters

Yes Yes

3.2 Execute Yes


Table 32: “Task-agents distribution round 1”

As it is shown in Table 32, all tasks have a minimum of one agent, hence no other internal agents are

necessary to cover the tasks defined for milestone MS6 “Third Vertical Integration”.

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

information is presented following a format where 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, 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.3.1, ‘get available features of interest for a water resource’ conversation

is identified.

N. Conversation 1


Name Get available features of interest for a water resource

Objective Obtain available features of interest for a water resource of a registered logical model in the

WatERP framework

Agents OMP Gateway, Logical model

Starter OMP Gateway

Description

The aim of the ‘OMP Gateway’ agent is to obtain available features of interest for a water

resource of a logical model. Then, the ‘OMP Gateway’ contacts with all ‘logical model’ agents

with the intention of obtaining the available features of interest of a water resource for a logical

model.

Pre-condition Information of the current registered logical models

Post-condition Return the available features of interest

Ending condition The logical model is not registered in the WatERP framework

The water resource does not exist in the logical model

Table 33: “’Get available features of interest for a water resource’ conversation”

Based on Figure 3 of Section 2.3.2, ‘get available observations for a feature of interest’ conversation is

identified.

N. Conversation 2

Name Get available observations for a feature of interest

Objective Obtain available observations for a feature of interest of a registered logical model in the

WatERP framework


Starter OMP Gateway

Description

The aim of the ‘OMP Gateway’ agent is to obtain available observations for a feature of interest

of a logical model. Then, the ‘OMP Gateway’ contacts with all ‘logical model’ agents with the

intention of obtaining the available observations of a feature of interest for a logical model.


Post-condition Return the available observations


The feature of interest does not exist in the logical model

Table 34: “’Get available observations for a feature of interest’ conversation”

Based on Figure 5 of Section 2.3.4, ‘register a logical model’ conversation is identified.

N. Conversation 3

Name Register a logical model

Objective Register a logical model in order to be accessible in the WatERP framework

Agents OMP Gateway, Logical model, Agent Management Service, Directory Facilitator

Starter OMP Gateway

Description The aim if the ‘OMP Gateway’ agent is to register a logical model in order to make it accessible

in the WatERP framework. Then the ‘OMP Gateway’ agent creates a ‘logical model’ agent


using ‘Agent Management Service’ network agent and contacts with the new agent in order to

check if the logical model is available. If the logical model is available, then ‘logical model’

agent enlist its services using ‘Directory Facilitator’ network agent.

Pre-condition Information of the current registered logical model

Post-condition The logical model is registered hence it is accessible from WatERP framework

Ending condition The logical model has already registered or the logical model is not accessible.

Table 35: “‘Register a logical model’ conversation”

Based on Figure 6 of Section 2.3.5, ‘unregister a logical model’ conversation is identified.

N. Conversation 4

Name Unregister a logical model

Objective Unregister a logical model in order to be accessible in the WatERP framework

Agents OMP Gateway, Logical model, Agent Management Service, Directory Facilitator

Starter OMP Gateway

Description

The aim of the ‘OMP Gateway’ agent is to unregister a logical model of the WatERP

framework. Then the ‘OMP Gateway’ agent contacts with the ‘logical model’ in order to remove

this agent from the WatERP platform. The agent unregisters all its services using ‘Directory

Facilitator’ and after it is self-destructed through ‘Agent Management Service’ network agent.


Post-condition The logical model is unregistered hence it is not accessible from WatERP framework


Table 36: “‘Unregister a logical model’ conversation”

Based on Figure 7 of Section 2.3.6, ‘unregister a logical model’ conversation is identified.

N. Conversation 5

Name Get structure of a logical model

Objective Obtain structure of a logical model


Starter OMP Gateway

Description

The aim of the ‘OMP Gateway’ agent is to obtain the logical model structure. The agent

contacts with the ‘logical model’ agent with the intention of obtaining the structure for a

concrete logical model.


Post-condition Return the logical model structure


Table 37: “‘Get structure of a logical model’ conversation”

Based on Figure 14 of Section 2.3.11, 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 6

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, Agent Management Service

Starter OMP Gateway.

Description

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

instantiates a new ‘OGC® WPS’ agent through ‘Agent Management Service’ agent network

and delegates to it the register process 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 38: “‘Integrate an OGC® WPS server’ conversation”

N. Conversation 7

Name Destroy ‘OGC® WPS’ agent

Objective Destroy ‘OGC® WPS’ agent

Agents OMP Gateway, OGC® WPS, Agent Management Service


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 using ‘Agent Management Service’

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 39: “‘Destroy OGC® WPS agent’ conversation”

N. Conversation 8

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, Agent Management Service, Directory Facilitator

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (the ‘OGC® WPS HF’ agent) using ‘Agent

Management Service’ to supervise the ‘OGC® WPS hydrological forecast’ server. Moreover,

this agent is capable of analysing the integrated server and registering the runnable processes

using ‘Directory Facilitator’ in the WatERP platform.

Pre-condition The integrated ‘OGC® WPS’ server is of hydro-meteorological 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 40: “‘Register an OGC® WPS HF server’ conversation”

N. Conversation 9

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, Agent Management Service, Directory Facilitator

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (‘OGC® WPS DMS’ agent) using ‘Agent

Management Service’, to supervise the ‘OGC® WPS DMS’ server. Moreover, this agent is

capable of analysing the integrated server and registering the runnable processes using

‘Directory Facilitator’ 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 41: “’Register an OGC® WPS DMS server’ conversation”

N. Conversation 10

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, Agent Management Service, Directory Facilitator

Starter OMP WPS

Description

The ‘OGC® WPS’ agent instantiates a new agent (‘OGC® WPS DSS’) agent using ‘Agent

Management Service’, to supervise the ‘OGC® WPS DSS’ server. Moreover, this agent is

capable of analysing the integrated server and registering the runnable processes using

‘Directory Facilitator’ 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 42: “’Register an OGC® WPS DSS server’ conversation"

Based on Figure 15 of Section 2.3.12, the following conversations to unregister OGC® WPS servers

are identified: (i) unregister an ‘OGC® WPS HF’ server; (ii) unregister an ‘OGC® WPS DMS’ server;

and (iii) unregister an ‘OGC® WPS DSS’ server.

N. Conversation 11

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, Agent Management Service, Directory Facilitator

Starter OMP Gateway

Description

The ‘OMP Gateway’ agent notifies to the ‘OGC® WPS HF’ that its processes shall be

unregistered from the WatERP platform. Then, ‘OGC® WPS HF’ unregisters all its processes

using ‘Directory Facilitator’ and self-destroy using ‘Agent Management Service’.

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 HF’ server and its processes are unregistered.

Table 43: “‘Unregister an OGC® WPS HF server’ conversation”

N. Conversation 12

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, Agent Management Service, Directory Facilitator

Starter OMP Gateway

Description

The ‘OMP Gateway’ agent notifies the ‘OGC® WPS DMS’ that its processes shall be

unregistered from the WatERP platform. Then, ‘OGC® WPS DMS’ unregisters all its processes


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 44: “‘Unregister an OGC® WPS DMS server’ conversation”

N. Conversation 13

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, Agent Management Service, Directory Facilitator

Starter OMP Gateway

Description

The ‘OMP Gateway’ agent notifies to the ‘OGC® WPS DSS’ that its processes shall be

unregistered from the WatERP platform. Then, ‘OGC® WPS DSS’ unregisters all its processes


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 45: “‘Unregister an OGC® WPS DSS server’ conversation”

Based on Figure 10 of the Section 2.3.8, two conversations have been identified, one to recover the

available hydro-meteorological forecast processes integrated in the WatERP platform and another to

execute one of these processes.

N. Conversation 14

Name Get available hydro-meteorological forecast processes.

Objective Obtain all runnable hydro-meteorological forecast processes.

Agents OMP Gateway, Directory Facilitator


Description The ‘OMP Gateway’ agent asks the ‘Directory Facilitator’ agent for all runnable hydro-

meteorological forecast process available in the WatERP platform.

Pre-condition None.

Post-condition None.

Ending condition The available runnable hydro-meteorological forecast processes are returned.

Table 46: “’Get hydro-meteorological forecast processes’ conversation”

N. Conversation 15

Name Execute hydro-meteorological forecast process

Objective Execute an hydro-meteorological forecast process

Agents OMP Gateway, OGC® WPS HF

Starter OMP Gateway

Description The ‘OMP Gateway’ agent invokes ’OGC® WPS HF’ agent to execute the hydro-

meteorological forecast process of the supervised ‘OGC® WPS’ server.

Pre-condition The hydro-meteorological forecast process is a runnable process and is registered on the

WatERP platform and it is executable.


Ending condition The response of the executed hydro-meteorological forecast process has been returned.

Table 47: “‘Execute hydro-meteorological forecast process’ conversation”

The following conversations related to ‘consult a demand forecast’ (see Figure 11 in Section 2.3.9) are

identified: (i) get demand forecast processes; (ii) get water resources; and finally (iii) execute demand

forecast process.

N. Conversation 16

Name Get demand forecast processes.

Objective Obtain all runnable demand forecast processes.

Agents OMP Gateway, Directory Facilitator.


Description The ‘OMP Gateway’ agent asks the ‘Directory Facilitator’ 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 48: “’Get demand forecast processes’ conversation”

N. Conversation 17

Name Get water resources.

Objective Get all water resources of a specific type for a logical model.

Agents OMP Gateway, Sesame.


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 49: “‘Get water resources’ conversation”

N. Conversation 18

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 50: “‘Execute hydrological forecast process’ conversation”

The next user story to be analysed is ‘consult water resources allocation’ which is presented in Figure

12 and Figure 13 of Section 2.3.10. 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 19

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

processes available in the WatERP platform.

Pre-condition None.


Ending condition The available runnable current state scenario processes are returned.

Table 51: “’Get current state scenario processes’ conversation”

N. Conversation 20

Name Execute ‘current state scenario’ process.

Objective Execute ‘current state scenario’ process.

Agents OMP Gateway, OGC® WPS DSS

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

platform and it is executable.


Ending condition The response of the executed ‘current state scenario’ process has been returned.

Table 52: “‘Execute current state scenario process’ conversation”

N. Conversation 21

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 53: “’Get behaviour’ conversation”

N. Conversation 22

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 54: “’Set behaviour’ conversation”

N. Conversation 23

Name Get ‘water allocation recommendations’ processes.

Objective Obtain all runnable ‘water allocation recommendations’ processes.



Description The ‘OMP Gateway’ agent asks the ‘Directory Facilitator’ 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 55: “’Get water allocation recommendations processes’ conversation”

N. Conversation 24

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 56: “‘Execute water allocation recommendations process’ conversation”

Finally, the ‘consult pump scheduling’ user history is analysed (see Figure 8 and Figure 9 in Section

2.3.7), 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; (v) check ‘validate pump scheduling’ process state and (vi) get ‘validate

pump scheduling’ process results.

N. Conversation 25

Name Get ‘pump scheduling’ processes.

Objective Obtain all runnable ‘pump scheduling’ processes.




Description The ‘OMP Gateway’ agent asks the ‘Directory Facilitator’ agent for all runnable ‘pump

scheduling’ processes available in the WatERP platform.

Pre-condition None.


Ending condition The available runnable ‘pump scheduling’ processes are returned.

Table 57: “’Get pump scheduling processes’ conversation”

N. Conversation 26

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

platform and it is executable.


Ending condition The response of the executed ‘pump scheduling’ process has been returned.

Table 58: “‘Execute pump scheduling process’ conversation”

N. Conversation 27

Name Get ‘validate pump scheduling’ processes.

Objective Obtain all runnable ‘validate pump scheduling’ processes.



Description The ‘OMP Gateway’ agent asks the ‘Directory Facilitator’ agent for all runnable ‘validate pump

scheduling’ processes available in the WatERP platform.

Pre-condition None.


Ending condition The available runnable ‘validate pump scheduling’ processes are returned.

Table 59: “Get ’Validate pump scheduling processes’ conversation”

N. Conversation 28

Name Execute ‘validate pump scheduling’ asynchronous process.

Objective Execute ‘validate pump scheduling’ asynchronous 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 asynchronous 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 60: “‘Execute validate pump scheduling process’ conversation”

N. Conversation 29

Name Check ‘validate pump scheduling’ asynchronous process state

Objective Check ‘validate pump scheduling’ asynchronous process state


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to check if the ‘validate pump

scheduling’ asynchronous process has finished its execution providing asynchronous


Pre-condition The ‘validate pump scheduling’ asynchronous process has been executed on the WatERP

platform.


Ending condition The response returns the state of the execution.

Table 61: “‘Check validate pump scheduling process state’ conversation”

N. Conversation 30

Name Get ‘validate pump scheduling’ asynchronous process results.

Objective Get ‘validate pump scheduling’ asynchronous process results.


Starter OMP Gateway

Description

The ‘OMP Gateway’ agent invokes the ’OGC® WPS DSS’ agent to recover the results of the

‘validate pump scheduling’ asynchronous process execution providing the asynchronous


Pre-condition The ‘validate pump scheduling’ asynchronous process has finished its execution.


Ending condition The result of the ‘validate pump scheduling’ process is returned.

Table 62: “‘Get validate pump scheduling process results’ conversation”

3.4.2 Scenarios

The aim of this section is to depict the messages exchanged between internal agents based on the

identified conversations (see Section 3.4.1) and user stories (see Section 2.3) that are used to build the

scenarios.

Basically, this section lists the scenarios presented in the D7.2.1 and D7.2.2 “Implementation of MAS”.

Moreover, these scenarios have been enhanced with the addition of the ‘Agent Management Service’


and ‘Directory Facilitator’ network agent which are responsible for providing agent creation/destruction

and service enlist/unregister/search operations respectively. Finally, the asynchronous execution of

processes introduced previously has also been added to the ‘Execute validation pump scheduling’

scenario.

Regarding the ‘Add a new logical model in the WatERP framework’ user story (see Table 12), Figure 49

shows the internal interactions, which are initiated after receiving a ‘register logical model’ event from

the external agent ‘OMP’. This event is received by the ‘OMP Gateway’ agent who creates a new

logical model through ‘DF’ and registers the processes using ‘AMS’. In order to register the logical

model, the ‘logical model’ agent receives the necessary information (URI, username and password)

from the ‘OMP Gateway’.

Figure 44: “Interactions between agents in the ’Add new logical model in WatERP framework’ user story”

Figure 51 represents the interactions between agents of the ‘Remove logical model of WatERP

framework’ user story (see Section 2.3.5). The communication is initiated after receiving a ‘unregister

logical model’ event (see Figure 6) from the external agent ‘OMP’. Hence, it is received by the ‘OMP

Gateway’ agent, who sends an event with the necessary information (agent identifier) to the ‘DF’ agent

in order to destroy the agent. Then, when ‘Logical model’ agent receives the message, it unregisters its

services using ‘DF’ agent and dies.

Figure 45: “Interactions between agents in the ‘Remove logical model of WatERP framework’ user story”

OMP Gateway

agent Logical model agent

create(uri, username, password)

Inactive

AMS

create(uri, username, password) create(uri, username, password)

Logical model agent DF

Agent created

Logical model registered

register(name, description, owner)*

Inactive

OMP Gateway

agentAMS agent

ask(destroy(agent))

Inactive

Inactive

Logical model agent DF agent

ask(destroy())

Logical model unregistered

unregister(name)*

Agent destroyed


Figure 46 exemplifies the interactions between agents of the ‘Obtain structure of logical model’ user

story (see Table 13). In this case, the interaction is initiated after receiving a ‘get structure’ event (see

Figure 11) from the external agent ‘OMP’. This event initiates the communication process with a call to

the ‘logical model’ agent in order to obtain the structure. Finally, the ‘OMP Gateway’ returns the

obtained structure using RDF or OWL formats, which are able to encapsulate the semantic data

returned by the ontology.

Figure 46: “Interactions between agents in the ‘Obtain structure of logical model’ user story”

The next interaction diagram corresponds to ‘Obtain available feature of interest for a water resource’

user history (see Table 14). Figure 47 shows an example of the interactions between the agents. ‘OMP

Gateway’ agent is activated when receiving a ‘get features of interest’ event (see Figure 12) from the

external agent ‘OMP’. Then, the ‘OMP Gateway’ agent initiates the communication process calling the

‘logical model’ agent in order to obtain the features of interest for a concrete water resource. In order to

obtain features of interest to a logical model, the ‘logical model’ agent receives from ‘OMP Gateway’

agent the necessary information (the water resource) to obtain the features of interest. Finally, the

‘OMP Gateway’ returns the features of interest list using either RDF or OWL format, which are able to

encapsulate the semantic data returned by the ontology.

OMP Gateway agent Logical model agent

alt

ask(structure())

fail(cause)

Inactive

Requested structure

Inactive

tell(structure)


Figure 47: “Interactions between agents in the ‘Obtain available features of interest for a water resource’ user

story”

The following interaction diagram corresponds to ‘Obtain available observations for a feature of interest’

user history (see Section 2.3.1) and it is represented in Figure 48. A ‘get observations’ event (see

Figure 2) activates ‘OMP Gateway’ launching the communication process of the ‘OMP Gateway’ agent.

Then, the ‘OMP Gateway’ agent asks the ‘logical model’ agent by the observations of a feature of

interest. In order to obtain the observations to a feature of interest, the ‘logical model’ agent receives

from the ‘OMP Gateway’ agent the necessary information (the feature of interest. Finally, the ‘OMP

Gateway’ agent returns the observations list using either RDF or OWL formats, which are able to

encapsulate the semantic data returned by the ontology.

Figure 48: “Interactions between agents in the ‘Obtain available observations for a feature of interest ’user story”


alt

ask(features of interest(water resource)

tell(features of interest)

fail(cause)

Inactive

Requested features of interest

Inactive


alt

ask(observations(feature of interest))

fail(cause)

Inactive

Requested observations

tell(observations)

Inactive


The internal interactions resulting from the ‘OGC® WPS server integration (HF, DSS and DMS’ user

story (see Table 15 and Figure 14) 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

using ‘AMS’ 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 49: “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 50: “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 specific ‘OGC® WPS’ agent, for instance ‘OGC®

HF WPS’, ‘OGC® DSS WPS’ or ‘OGC® DMS WPS’. The communication is started after analysing the

‘OGC® WPS’ server and verifying the type of specific OGC® WPS server. Afterwards, the ‘OGC®

WPS’ agent instantiates an specific ‘OGC® WPS’ agent (‘OGC® HF WPS’, ‘OGC® DSS WPS’ or

‘OGC® DMS WPS’) using ‘Agent Management Service’ agent to supervise the OGC® WPS server

which analyses the processes of the server and classifies them in runnable and non-runnable

processes. Finally, these processes are enlisted through ‘Directory Facilitator’ agent.

OMP Gateway

agentAMS agent

create(url ogc wps server)

Inactive

Inactive

tell(registered)

OGC WPS agent


Agent created

OMP Gateway

agentOGC WPS agent

ask(destroy())

Specific OGC WPS (HF, DMS, DSS) instantiated

DestroyedInactive


Figure 51: “Interactions between agents to register an specific OGC® WPS server”

Based on Figure 15 of Section 2.3.12, the following interactions have been identified: (i) unregister an

‘OGC® WPS HF’ server; (ii) unregister an ‘OGC® WPS DMS’ server; and (iii) unregister an ‘OGC®

WPS DSS’ server.

Figure 52 shows the internal interactions resulting from the ‘unregister an OGC® WPS HF server’

conversation (see Table 43). 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. Then, the ‘OGC® WPS HF’

agent unregisters all its processes from the WatERP platform using ‘DF’ agent and finally, it self-

destroys through ‘Agent Management Service’ network agent. It is important to note that this process is

the same for the ‘unregister an OGC® WPS DSS server’ and ‘unregister an OGC® WPS DMS server’

conversations but changing the involved specific agent.

Figure 52: “Interactions between agents to unregister an OGC® WPS HF server”

The following internal interactions regarding the ‘Consult a hydrological forecast’ user story (see Figure

10) are identified: (i) get available hydro-meteorological forecast processes and (ii) execute hydro-

meteorological forecast process.

Figure 53 shows the internal interactions resulting from the ‘get available hydro-meteorological forecast

processes’ conversation (see Table 46). This interaction is started after receiving a ‘get hydro-

OGC WPS agent AMS agent

create(agent, url ogc wps server)

OGC WPS server analysis

Inactive

Detected specific OGC WPS server

Analyse OGC WPS processes

Specific OGC WPS

agent DF agent


Classify OGC OGC WPS processes

register(process)*

OMP Gateway agent OGC WPS HF agent

ask(unregister())

tell(unregistered)

Inactive

Inactive

DF agent AMS agent

unregister(process)*

Unregister OGC processes

Destroy

destroy(agent)

destroy(agent)


meteorological forecast processes’ event from the ‘OMP’ external agent. The event is received by the

‘OMP Gateway’ agent, who asks for the runnable hydro-meteorological forecasts to the ’DF’ agent,

which are later returned to the ‘OMP Gateway’ agent.

Figure 53: “Interactions between agents to get available OGC® WPS HF processes”

The last interaction, ‘execute hydro-meteorological forecast process’, which is part of the ‘Consult a

hydro-meteorological forecast’ user story is presented in Section 2.3.8. It is started when a ‘execute

hydro-meteorological 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 54: “Interactions between agents to execute hydro-meteorological forecast process”

The next user story analysed is ‘consult a demand forecast’ which is presented in Figure 11 of Section

2.3.9. The following internal interactions are identified: (i) get demand forecast processes; (ii) get water

resources and (iii) execute demand forecast process.

Figure 55 shows the internal interactions resulting from the ‘get demand forecast processes’

conversation (see Table 48). 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 ’DF’ agent by the runnable demand forecasts, which are later returned to the ‘OMP

Gateway’ agent.

OMP Gateway agent DF agent

ask(hydrological forecast processes())

tell(hydrological forecast processes)

Inactive

Inactive

OMP Gateway agent OGC WPS HF agent

ask(execute(hydrological forecast process,

parameters))

tell(hydrological forecast)

Inactive

Inactive

Find responsible to execute HF process


Figure 55: “Interactions between agents to get OGC® WPS DMS processes”

The second internal interaction based on the ‘get demand forecast processes’ conversation (see Table

48) is presented in Figure 56. 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 56: “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 57. 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 57: “Interactions between agents to execute a demand forecast process”


ask(dms processes())

tell(dms processes)

Inactive

Inactive

OMP Gateway agent Sesame 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


The ‘Consult water resources allocation’ user story, which is described in Figure 12 and Figure 13 of

Section 2.3.10, 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.

Figure 58 shows the internal interactions resulting from the ‘get current state scenario processes’

conversation (see Table 51). 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,

and asks the ’Sesame’ agent by the runnable current state scenario processes, which are later returned

to the ‘OMP Gateway’ agent.

Figure 58: “Interactions between agents to get current state scenario processes”

The second internal interaction based on the ‘execute current state scenario process’ conversation (see

Table 51) is presented in Figure 59. 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 59: “Interactions between agents to execute a demand forecast process”

Figure 60 is based on the ‘get behaviour’ conversation (see Table 53). 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


ask(state scenario processes())

tell(state scenario processes)

Inactive

Inactive

OMP Gateway agentOGC WPS DSS

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


current behaviour for a specific logical model, which is later returned and encapsulated in WatERP

ontology format.

Figure 60: “Interactions between agents to get behaviour”

The opposite functionality to the previous internal interaction is presented in Figure 62, which is based

on the ‘set behaviour’ conversation (see Table 54). 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 61: “Interactions between agents to set behaviour”

Figure 62 shows the internal interaction resulting from the ‘get water allocation recommendations

processes’ conversation (see Table 55). 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, who asks the ‘DF’ agent for the runnable water allocation recommenders, which are

then returned to the ‘OMP Gateway’ agent.

Figure 62: “Interactions between agents to get water allocation recommendations processes”


ask(behaviour())

tell(behaviour)

Inactive

Inactive


ask(behaviour(behaviour))

tell(inserted)

Inactive

Inactive


ask(water allocation processes())

tell(water allocation processes)

Inactive

Inactive


The last internal interaction is based on the ‘execute water allocation recommendations process’

conversation (see Table 56), which is presented in Figure 63. This interaction is started when the ‘OMP’

external agent generates a ‘execute water allocation recommendations 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 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 63: “Interactions between agents to execute water allocation recommendations process”

The last user story identified on this deliverable is ‘consult pump scheduling’ (see Section 2.3.7) and the

conversations extracted from 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 64 shows the internal interactions resulting from the ‘get pump scheduling processes’

conversation (see Table 57). This interaction is started after receiving a ‘get pump scheduling

processes’ event from the ‘OMP’ external agent. The ‘OMP Gateway’ agent receives the event and

asks the ’DF’ agent for the runnable pump scheduling processes, which are later returned to the ‘OMP

Gateway’ agent.

Figure 64: “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 58) and presented in Figure 65. This interaction is started when the ‘OMP’


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


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

process stored in the ‘OGC® WPS DSS’ server supervised by the agent. Finally, the returned

information is encapsulated on WaterML2 format.

Figure 65: “Interactions between agents to execute pump scheduling process”

Another internal interaction resulting from the ‘get ‘validate pump scheduling’ processes’ conversation

(see Table 59) is presented in Figure 66. 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 66: “Interactions between agents to get ‘validate pump scheduling’ processes”

The ‘consult pump scheduling’ user story is defined for the three interactions shown in Figure 67, Figure

68 and Figure 69. All of them are based on the ‘execute ‘validate pump scheduling’ process’

conversation (see Table 59). This first 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 in an

asynchronous way the process stored in the ‘OGC® WPS DSS’ server supervised by the agent. Finally,

the returned information is an identifier to recover the state the execution and the results.


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 67: “Interactions between agents to execute ‘validate pump scheduling’ process”

This second interaction is started when the ‘OMP’ external agent generates an ‘check ‘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 check if the asynchronous process has

finished the execution. Finally, the returned information is the state of the execution.

Figure 68: ”Interactions between agents to execute ‘validate pump scheduling’ process”

This last interaction is started when the ‘OMP’ external agent generates a ‘recover ‘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 recover the asynchronous process results.

Finally, the returned information is encapsulated on WaterML2 format.

Figure 69: Interactions between agents to execute ‘validate pump scheduling’ process"

Finally, Figure 70 shows a summary of previous figures, unifying in a single illustration the interactions

between agents that were fully implemented in milestone MS6 “Third vertical integration”. All these

interactions are a summary of the interactions presented in D7.2.1 “Implementation of MAS” in Section

4.2.4.2 and D7.2.2 “Implementation of MAS” in Section 3.4.2. Basically, the picture contains two


agent

ask(execute(validate pump scheduling process,

parameters))

tell(asynchronous process identifier)

Inactive

Inactive

Find responsible to execute validate pump scheduling process

Find parameters to execute validate pump scheduling process


agent

ask(is executed(asynchronous process identifier))

tell(is executed)

Inactive


agent

ask(asynchronous process(asynchronous

process identifier))

tell(pump scheduling validation)

Inactive


different types of rectangles which represent 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 hydro-meteorological forecast processes; (ix) execute hydro-meteorological 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; (xxii) execute

‘validate pump scheduling’ process; (xxiii) check ‘validate pump scheduling’ process and (xxiv) get

result ‘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.


Figure 70: “Interaction diagram among agents in the third 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(is executed(asynchronous process identifier))


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(pump scheduling validation)

tell(validate pump scheduling processes)

ask(water resources(type))


ask(execute(HF process, params)

tell(HF)

ask(execute(DF process, params)

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, parameters))

tell(asynchronous process identifier)

ask(execute(HF process

, params))

tell(HF)

ask(execute(DF

process, params) 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())

AMS agent

DF agent

register(name,

description, owner)

destroy(agent)create(agent)

unregister(name)

create(agent)destroy(agent)

register(name,

description, owner)

unregister(name)

unregister(name)

register(name, description, owner)

unregister(name)

register(name,

description, owner)


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 below describe all the functionalities defined throughout the WatERP

project, that is, the functionalities defined in the MS3 “First Vertical Integration”, MS5 “Second Vertical

Integration” and MS6 “Third Vertical Integration” milestones. The behaviour of the network agents such

Directory Facilitator and Agent Management System are not defined because these agents are

provided by the Jadex platform and hence its behaviour is already defined. Moreover, the state

diagrams have been grouped into the following categories in order to facilitate its description: (i) OGC®

WPS management; (ii) process operation; and (iii) ontology management; and (iv) ontology operation.

The state diagrams corresponding to the OGC® WPS management are presented in Figure 71. This

figure contains five diagrams, one for each possible message received by the agent related to each

specific topic. The messages are: (a) register OGC® WPS; (b) analyse OGC® WPS; (c) register

processes; (d) unregister OGC® WPS; and (e) unregister processes.


Figure 71: “OGC® WPS management message processing state diagram”

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.

Moreover, the processes are enlisted as services through the Directory Facilitator to facilitate its

subsequent identification. 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 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 response telling whether the unregister process has been successful or not.

Figure 72 presents the state diagrams regarding the processes’ operation. The figure contains five

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; (b) execute a

synchronous process; (c) execute an asynchronous process; (d) check state of an asynchronous

process execution; and (e) get the result of an asynchronous process execution.

Figure 72: “Message processing state diagram regarding the processes’ operation”

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

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

Inactive

ask(executeAsynchronousPr

ocess(process id, params))

Inactive

do:

getRequiredInputParameters

()

(c)

tell(asyncrhonous process

identifier)

do:

executeAsynchronousProces

s(process id, params, input

params

Inactive

ask(state(asyncrhonous


Inactive

do: getState(asyncrhonous

process identifier)

(d)

tell(state)

Inactive

ask(result(asyncrhonous


Inactive

do: getResult(asyncrhonous

process identifier)

(e)

tell(result)


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 process list is returned.

The second sub-picture (b) describes the state diagram corresponding to the execution of a

synchronous 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 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 facilitate 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 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 third sub-picture (c) describes the state diagram corresponding to the execution of an

asynchronous process by the agent. Notice that this state diagram is suitable for any specific agent

(‘OGC® WPS HF’, ‘OGC® WPS DSS’ or ‘OGC® WPS DMS’) because all of them can contain long

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 an

asynchronous 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 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). Again, 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 during the integration part. Therefore, the returned sub-processes are executed. Finally, the

response of the sub-processes is used as the input to execute the requested asynchronous process

and its process execution identifier is returned to recover its execution later.

Sub-picture (d) describes the state diagram corresponding to the check of the state of an asynchronous

process execution by the agent. Similarly to the previous state diagrams, the agent waits until it

receives a message to check an asynchronous process belonging to the supervised server. When the

message is received, the specific agent asks to the OGC WPS server by the process state and finally, it

returns true if the process have been finished and false in otherwise.

The last sub-picture (f) describes the state diagram corresponding to the recovery of the results of an

asynchronous process execution by the agent. Similarly to the previous state diagrams, the agent waits


until it receives a message to recover the asynchronous process results belonging to the supervised

server. When the message is received, the specific agent invokes the OGC WPS server to recover the

results and finally, these results are returned by the agent.

Figure 73 presents the state diagrams regarding the ontology management. The figure contains two

diagrams, one for each possible message received by the agent about this subject. The messages are:

(a) register logical model; and (b) unregister logical model.

Figure 73: “Message processing state diagram regarding the ontology management”

In reference to sub-picture (a), initially the agent remains in an inactive state waiting for a message to

carry out the register. When a register message with a location of a logical model is received by the

‘OMP Gateway’ agent, it checks the logical model existence in the system. If the logical model is

integrated in the WatERP framework, it should not be registered and therefore an error message is

returned as response. Otherwise, the ‘OMP Gateway’ agent automatically instantiates a new ‘Logical

model’ agent who will be responsible of managing the logical model associated with it. In the next step

of the process, the ‘OMP Gateway’ agent registers the new logical model in the WatERP framework in

order to have the logical model and its semantic characteristics always available. Finally, the ‘OMP

Gateway’’ agent sends a response telling if the logical model has been successfully integrated in the

WatERP platform. The registering system provides a simple way to integrate logical models which are

semantically analysed by MAS, with the aim of exploiting its knowledge in the WatERP platform.

The second sub-picture, (b), 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 logical

model introduced as parameter. Then, if the logical model is integrated in the WatERP system, it can be

Inactive

ask(register(logical model))

tell(is registered)

do: register

Inactive

do: check exist logical model

do: create logical model

agent

Inactive

ask(unregister(logical model))

tell(is unregistered)

do: unregister

Inactive

do: check exist logical model

(a) (b)

do: destroy logical model

agent


unregistered. Moreover, the ‘logical model’ agent is removed because it will not be used anymore.

Finally, the ‘OMP Gateway’’ agent returns a message indicating whether the logical model has been

successfully unregistered or not.

The last state diagrams presented correspond to the ontology management issues and they are shown

in Figure 74. It contains seven diagrams, one for each possible message received by the agent related

to this topic. The messages are: (a) obtain available logical models; (b) obtain logical model structure;

(c) obtain features of interest for a water resource of a logical model; (d) obtain observations for a

feature of interest of a logical model; (e) obtain water resources of a type; (f) get the behaviour of a

logical model; and (g) change the behaviour of a logical model.

Figure 74: “Message processing state diagram regarding the ontology issues”

Sub-picture (a) represents the executed process when the ‘OMP Gateway’ agent receives a message

to obtain the available logical models. The ‘OMP Gateway’ provides the registered logical models.

Sub-picture (b) illustrates the executed process when the ‘OMP Gateway’ agent receives a message to

obtain the logical model structure of a concrete logical model. Hence, the concrete element is

Inactive

ask(logical models)

tell(logical models)

Inactive

do: obtain the registered

logical models

Inactive

ask(structure(logical model))

tell(structure)

Inactive

do: ask by structure of a

logical model

(a) (b) (c) (d)

Inactive

ask(features of

interest(logical model, water

resource))

tell(structure)

Inactive

do: ask by the features of

interest of a water resource

Inactive

ask(observations(logical

model, feature of interest))

tell(structure)

Inactive

do: ask by the observations

of a feature of interest

Inactive

ask(obtainWaterResources(pi

lot intantiation id, type))

Inactive

do: getWaterResources(type)

(e)


Inactive

ask(obtainBehaviour(pilot

intantiation id))

Inactive

do: getBehaviour()

(f)

tell(behaviour)

Inactive

ask(setBehaviour(pilot

intantiation id, behaviour))

Inactive

do: setBehaviour(behaviour)

(g)

tell(inserted)


transmitted as a parameter. In order to achieve its goal, the agent asks to ‘logical model’ agents which

is the structure of the concrete water distribution chain. The ‘OMP Gateway’ obtains the response of

responsible ‘Water supply distribution agent’ of the concrete logical model. Finally, the ‘OMP Gateway’

agent returns the obtained structure.

The third sub-picture (c) describes the process when a ‘obtain features of interest’ message is received.

In the same way that in the previous state diagram, the ‘OMP Gateway’ agent asks to all ‘Logical model’

agents for the features of interest of a water resource contained in a concrete logical model. All ‘logical

model’ agents reply to this request, but only the agent who supervises the demanded logical model

returns a response with the list of features of interest. Finally, this response is transferred by the ‘OMP

Gateway’ agent.

The sub-picture (d) exemplifies the process carried out by the ‘OMP Gateway’ when a ‘obtain

observations’ message is received. It works similarly to the previous state diagram; the question is sent

to the agents and the responsible agents’ replies with the appropriate content. Finally, the obtained

response is returned by the agent.

Sub-picture (e) 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 sixth sub-picture, (f), 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

Section 2.2.1 in D3.3 “WDW Second prototype“)). The behaviour information received is then translated

to WatERP ontology format and returned.

The last state diagram (g) 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 the second iteration (D7.2.2 “Implementation of MAS”), a new class was 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.

Finally, no new agents were identified in this third iteration (see Section 3.1), thus the list of identified

classes has not been extended. Below, Figure 75 shows in a single figure the classes defined

throughout the WatERP project.

Figure 75: “Agents hierarchy”

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]


4. Design phase

Basically, the content of this section is focused on two key issues: (i) platform selection and (ii) network

agents’ identification which were solved during the first and second year of the project and hence, they

were published in the previous private deliverables D7.2.1 “Implementation of MAS” and D7.2.2

“Implementation of MAS”. Then, a summary of the most relevant content is offered in order to

summarize the work performed throughout the WatERP project regarding the MAS and hence, transfer

the knowledge to the community.

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 mainly 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 (see Table 63).

Platform License Last

release

Implementation Distributed

agents

Documentation

/ tools

Communication

language

Industrial-strength

application

Jason1 GNU LGPL 14/03/2013 Java Using Jade

or Saci

Yes / Yes KQML Animated embodied

agents in virtual

environments

AF-APL2 GNU LGPL 07/03/2013 Java Yes Yes / Yes FIPA-ACL No

3APL3 GNU GPL 19/11/2007 Java and Prolog Yes Yes / Yes FIPA-ACL No

Jack4 Commercial Continuous

releases

Java Yes Yes / Yes FIPA-ACL Unmanned vehicle

Jadex5 GNU LGPL 17/02/2013 Java Using Jade Yes / Yes FIPA-ACL Yes

Table 63: “BDI Multi agent platform characteristics”

As for the network agents’ identification, two agents were identified: (i) yellow pages agent -also named

as Directory Facilitator (DF) on Jadex platform; and (ii) white pages -also named as Agent Management

Service (AMS) on Jadex platform.

Basically, the aim of the DF agent is to provide support during the identification of the responsible agent

for managing a service. Therefore, this agent is able (i) to enlist services in the yellow pages with the

1 http://jason.sourceforge.net/wp/

2 http://www.agentfactory.com/index.php/AFAPL

3 http://www.cs.uu.nl/3apl/

4 http://www.agent-software.com.au/products/jack/

5 http://www.activecomponents.org/bin/view/About/Features

http://jason.sourceforge.net/wp/

http://www.agentfactory.com/index.php/AFAPL

http://www.cs.uu.nl/3apl/

http://www.agent-software.com.au/products/jack/

http://www.activecomponents.org/bin/view/About/Features


responsible for performing the service; (ii) to modify existent services and their responsible; (iii) to

unsubscribe services of the yellow pages; (iv) to search who is the agent responsible for a execute a

service (see D2.6 “Multi-agent Architecture Prototypes” in Section 3.2.3).

Instead, the aim of the AMS agent is to provide the necessary goals to manage agents, allowing: (i) to

create new agents inside the Jadex platform which is essential during integration tasks such as the

incorporation of OGC® WPS, OGC® SOS servers or logical models (see Section 2.3.4 and 2.3.11); (ii)

to destroy agents from the Jadex platform using the unregistering tasks and eliminating the agents that

are responsible for managing the unregistered services (see Section 2.3.5 and 2.3.12); and (iii) search

an agent inside the Jadex platform in order to know the address to communicate with the agent (see

Section 2.3.1, 2.3.2, 2.3.3, 2.3.4, 2.3.6, 2.3.7, 2.3.8, 2.3.9, 2.3.10 and 2.3.11).


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 finished in

month 30 (M30) and is focused on the MAS developments that were implemented by milestone MS6

“Third vertical integration”. The implementations presented in this deliverable are a summary of the

ones reported in D7.2.1 “Implementation of MAS”, which corresponds to the first vertical integration

(MS3 “First vertical integration”), milestone and D7.2.2 “Implementation of MAS”, which corresponds to

the second vertical integration (MS5 “Second vertical integration”) milestone. Moreover, this summary

have been enhanced with the last improvements such as the implementation of an asynchronous

process execution for the processes that require a long time to complete, the addition of the networks

agents such as Directory Facilitator and Agent Management Service in the diagrams, and finally the

correction of minor errors detected during the last iteration of MAS-CommonKADS methodology.

With respect to the agents and multi agents’ technologies, utility-based agents based on BDI model

were used to implement the WatERP SOA-MAS architecture. Additionally, different methodologies to

develop multi-agent systems have been studied concluding that the MAS-CommonKADS methodology

is the most suitable to be applied on the WatERP MAS design since it supports most of the utility-based

BDI agents’ characteristics.

On the other hand, the integration of the complete set of building blocks done in task T7.2

“Implementation of the Multi-Agent System Architecture” consisted on the integration of one Sesame

Repository, one OGC® SOS server, and three OGC® WPS server, which can be classified as OGC®

WPS HF, OGC® WPS DSS and OGC® WPS DMS. With the aim of managing all building blocks and

orchestrate them, nine agents have been designed and implemented. Those are: (i) ‘OMP Gateway’

agent; (ii) ‘Sesame’ agent; (iii) ‘OGC® WPS’ agent; (iv) ‘OGC® WPS HF’ agent; (v) ‘OGC® WPS

DMS’ agent; (vi) ‘OGC® WPS DSS’ agent; (vii) ‘OGC® SOS’ agent, (viii) ‘Agent Management

Service’ agent and (ix) ‘Directory Facilitator’ agent.

Moreover, this document provides a list of the different tasks that shall be carried out by each agent,

including the mappings between tasks and agents. In order to facilitate the implementation, the

conversation diagrams to show the interactions needed to satisfy the MAS requirements are provided.

Future work to be accomplished is focused on supporting the validation of the whole platform through

the MAS in order to corroborate the goodness and robustness of the WatERP solution, which will be

presented in deliverable D7.7 “General Validation” due on month 36.

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

Documents