Engineering Multi-Agent Systems, Proc. of 4th International Workshop on Engineering Multi-Agent Systems, EMAS 2016

(1)

This is the author’s final version of the contribution published as:

Matteo Baldoni, J¨rg P. M¨

uller, Ingrid Nunes, Rym Zalila-Wenkstern (eds.)

Engineering Multi-Agent Systems, Fourth International Workshop, EMAS

2016 Singapore, May 9th and 10th, 2016. Workshop Notes.

The publisher’s version is available at:

http://www.di.unito.it/~argo/papers/EMAS2016-WorkshopNotes.pdf

When citing, please refer to the published version.

Link to this full text:

http://hdl.handle.net/2318/1567314

This full text was downloaded from iris - AperTO:https://iris.unito.it/

(2)

Matteo Baldoni, J¨org P. M¨uller

Ingrid Nunes, Rym Zalila-Wenkstern (eds.)

Engineering Multi-Agent

Systems

Fourth International Workshop, EMAS 2016

Singapore, May 9th and 10th, 2016

Workshop Notes

EMAS 2016 Home Page:

(3)

(4)

Preface

The engineering of multi-agent systems (MAS) is a multi-faceted, complex task. These systems consist of multiple, autonomous, and heterogeneous agents, and their global behavior emerges from the cooperation and interactions among the agents. MAS have been widely studied and implemented in academia, but their full adoption in industry is still hampered by the unavailability of comprehensive solutions for conceiving, engineering, and implementing these systems.

Although much progress has been made in the development of multi-agent systems, the systematic engineering of large-scale MAS still poses many chal-lenges. Even though various models, techniques and methodologies have been proposed in the literature, researchers and developers are still faced with the common questions:

– Which architectures are suitable for MAS?

– How do we specify, design, implement, validate and verify, and evolve our systems?

– Which notations, models and programming languages are appropriate? – Which development tools and frameworks are available?

– Which processes and methodologies can integrate all of the above and pro-vide a disciplined approach to the rapid development of high-quality MAS? Existing approaches address the use of common software engineering solu-tions for the conception of MAS, the use of MAS for improving common software engineering tasks, and also the blending of the two disciplines to conceive MAS-centric development processes.

The International Workshop on Engineering Multi-Agent Systems (EMAS) provides a comprehensive venue, where software engineering, MAS and artificial intelligence researchers can meet together, discuss different viewpoints and find-ings, and share them with industry. EMAS was created in 2013 as a merger of three separate workshops (with overlapping communities) that focused on the software engineering aspects (AOSE), the programming aspects (ProMAS), and the application of declarative techniques to design, program, and verify MAS (DALT). The workshop is traditionally co-located with AAMAS (International Conference on Autonomous Agents and Multiagent Systems) which in 2016 takes places in Singapore.

This year’s EMAS workshop is held as a one-and-a-half day event. 14 pa-pers were submitted to the workshop and each submission received, received at least three reviews, the program committee selected 13 papers for presentation. The program also includes two invited talks. T he first “Implementing Norms Why is it so difficult?”, by prof. Frank Dignum from the Universiteit Utrecht, is held jointly with the COIN workshop. The second, by prof. Jaime Sim˜ao Sich-man, is titled “Designing and Programming Multiagent Organizations.” We are confident that the talks offer an interesting perspective of the work that has been done for conceiving sound and complex MAS, and they will also offer the opportunity for fruitful and interesting discussions.

(5)

We would like to thank the members of the Program Committee for their excellent work during the reviewing phase. We also acknowledge the EasyChair conference management system that –as usual– provided its reliable and useful support of the workshop organization process. Moreover, we would like to thank the members of the Steering Committee of EMAS for their valuable suggestions and support.

April 6, 2016 Matteo Baldoni

J¨org P. M¨uller Ingrid Nunes Rym Wenkstern

(6)

Program Committee

Natasha Alechina University of Nottingham

Matteo Baldoni University of Torino

Luciano Baresi Politecnico di Milano

Cristina Baroglio University of Torino

Jeremy Baxter QinetiQ

Ana L. C. Bazzan Universidade Federal do Rio Grande do Sul Olivier Boissier ENS Mines Saint-Etienne

Rafael H. Bordini FACIN-PUCRS

Lars Braubach University of Hamburg

Nils Bulling TU Delft

Rem Collier UCD

Massimo Cossentino National Research Council of Italy

Fabiano Dalpiaz Utrecht University

Mehdi Dastani Utrecht University

Louise Dennis University of Liverpool

Virginia Dignum TU Delft

J¨urgen Dix TU Clausthal

Amal El Fallah Seghrouchni LIP6 - University of Pierre and Marie Curie Baldoino Fonseca Federal University of Alagoas

Aditya Ghose University of Wollongong

Adriana Giret Technical University of Valencia Jorge Gomez-Sanz Universidad Complutense de Madrid

Sam Guinea Politecnico di Milano

Christian Guttmann Institute of Value Based Reimbursement System

James Harland RMIT University

Vincent Hilaire UTBM/IRTES-SET

Koen Hindriks Delft University of Technology

Benjamin Hirsch Khalifa University

Tom Holvoet K.U. Leuven

Jomi Fred Hubner Federal University of Santa Catarina

Michael Huhns University of South Carolina

Franziska Kl¨ugl Orebro University¨

Joao Leite Universidade Nova de Lisboa

Yves Lesp´erance York University

Brian Logan University of Nottingham

Viviana Mascardi University of Genova

Philippe Mathieu University of Lille

John-Jules Meyer Utrecht University

Frederic Migeon IRIT

Ambra Molesini Alma Mater Studiourum - Universt`a di Bologna Pavlos Moraitis Paris Descartes University

Haralambos Mouratidis University of Brighton

J¨org P. M¨uller TU Clausthal

(9)

Ingrid Nunes UFRGS

Juan Pav´on Universidad Complutense de Madrid

Alexander Pokahr University of Hamburg

Enrico Pontelli New Mexico State University Alessandro Ricci University of Bologna

Ralph Ronnquist Intendico Pty Ltd

Sebastian Sardina RMIT University

Valeria Seidita University of Palermo

Onn Shehory IBM Haifa Research Lab

Viviane Silva IBM Research

Guillermo Simari Universidad Nacional del Sur in Bahia Blanca

Munindar P. Singh NCSU

Tran Cao Son New Mexico State University

Pankaj Telang North Carolina State University Wamberto Vasconcelos University of Aberdeen

Jørgen Villadsen Technical University of Denmark

Gerhard Weiss University Maastricht

Michael Winikoff University of Otago

Wayne Wobcke University of New South Wales

Pinar Yolum Bogazici University

Neil Yorke-Smith American University of Beirut Rym Zalila-Wenkstern University of Texas at Dallas

(10)

Steering Committee

Matteo Baldoni University of Torino

Rafael H. Bordini FACIN-PUCRS

Mehdi Dastani Utrecht University

J¨urgen Dix TU Clausthal

Amal El Fallah Seghrouchni LIP6 - University of Pierre and Marie Curie

Paolo Giorgini University of Trento

J¨org P. M¨uller TU Clausthal

M. Birna van Riemsdijk Delft University of Technology

Tran Cao Son New Mexico State University

Gerhard Weiss University Maastricht

Danny Weyns Linnaeus University

Michael Winikoff University of Otago

(11)

Acknowledgements

Matteo Baldoni was partially supported by the Accountable Trustworthy Orga-nizations and Systems (AThOS) project, funded by Universit`a degli Studi di Torino and Compagnia di San Paolo (CSP 2014).

(12)

Implementing Norms

Why is it so difficult?

Frank Dignum

Utrecht University, The Netherlands [email protected]

Abstract. Many people have made implementations of norms or norma-tive systems over the years. However, the implementations differ widely and no uniform methodology to implement normative systems seemed to have been developed. Why is it so difficult to implement norms? Can’t we just have a Norms module that can be added to a system? I will discuss these issues and also point to some possible ways forward.

1 Introduction

In [3] we already described some of the issues that come up when trying to implement norms in agent systems. Because the norms influence the behaviour of the agents, they somehow have to be taken into account during the planning and execution of their actions. It is this influence relation between the norms and the plans and actions that is difficult to capture. Let me give a simple example. There is a norm that bikes should stop for a red traffic light. In a typical Dutch city like Amsterdam it would be hard to deduce this norm from just looking at the actions of the bikes. So, there is certainly not a one-on-one relation or rule that makes bikes stop whenever the traffic light is red. From own experience it seems that the norm functions as a heuristic that states that when you are on a bike and getting to a red light you have to check whether you can cross and have to stop when there is traffic coming from the sides streets (that you cannot avoid in any way). However, bikes will also stop when there are children already waiting at the traffic light (because you have to give a good example) or when they spot a policeman that could give you a fine when passing a red light. These examples show that the way a norm influences the actions is at least partly situational. One could argue that thus one has to take both the norm and the current situation as input for the influence relation. Theoretically this is correct, but it can be quite difficult to determine how the norm and situation should be combined. Are there just a lot of special situations that give exceptions to a general rule or are there types of situations that each combine in a different way with the norm? This is not very clear and also has not been investigated in a systematic way (although this has, of course, strong links to modeling norms as a kind of default logic).

However, the situation gets even more complex as not only the present situ-ation influences the way norms influence behaviour, but also the social structure

(13)

else also stops, but ignores the light if most people do so. The biker also might disregard red lights habitually (at certain crossings or times) if he knows that in the past this never led to any danger. Finally, if the biker is a school teacher riding ahead of a class of children on the bike he will never pass a red light. So, we have to include social status, roles, practices and history in the list of aspects that should be regarded when modeling the influence of norms on behaviour. The list gets longer and longer and also involves more and more complex con-cepts. Thus it is clear that modeling the influence of norms on behavior can be very complex and will differ depending on which of these aspects are taken into account.

Of course, norms do not exist in isolation. So, besides the above norm there might be a norm that you have to come in time for a meeting with your boss. When you go on the bike to work and are a bit late it might be that you get a conflict between the norm to stop for a red light and being in time for the meeting. In a good logic tradition one could solve this problem by giving a preference order over the norms such that one will be fulfilled and the other violated when they are in conflict. This could be conveniently handled within the norms module. However, life is not as simple as that. Often the preferences of the norms are situation dependent. If I have a meeting with my boss in which I am going to ask a favor (or promotion) I certainly do not want to be late and possibly annoy him before even starting the meeting. Thus I might risk going through red in order to be in time for the meeting. But if I see a policeman near the traffic light I might stop. The reason being, not that I give priority to the traffic norm, but rather that if the policeman is going to fine me, it will take even more time than just waiting for the light! So, at this moment the planning actually influences the norm preference and which norm might be violated. To further complicate matters one might even consider that passing through the red light and being fined one certainly will be late, when you pass through the red light and not get a fine you certainly will be in time and if you stop for the red light you still have a chance of making it in time to the meeting. It is clear that in these more complex cases it does not suffice to just check which norms are applicable at a certain moment and use those as a kind of filter on the potential plans. There is a interdependence between the planning and the norms that does not (always) allow for a one way influence relation (as would be prefered for any deliberation architecture)!

2 Acting with Norms

Given the above arguments one would think it is better not to incorporate norms in agents at all. Things are not as grim as they seem though. Norms have many aspects and not all aspects are equally important in every application. The first step to take when implementing norms should thus be to determine what the function should be of the norms in the system that is developed. The aspects that relate to that function have to be modeled and implemented. In many cases

(14)

in specific circumstances, randomly in some cases, or based on another clear criteria). In this case one can have a norms module that is used to check all potential plans and orders them based on how many norms they violate and how efficient the plans are.

However, if the norms should lead to emerging behavior as perceived in reality this will not be enough. In that case more elaborate mechanisms should be designed. This will often also necessitate a more complex deliberation cycle of the agents incorporating more social concepts. This is not very easy, because it is not clear on forehand which concepts are needed exactly and there are no architectures that incorporate these concepts in a systematic way. I.e. there are all kinds of extensions of BDI architectures, but often with only one or two new concepts and usually for a very specific purpose or application area.

What is needed is a richer social model in which norms can play a role and agents have all social concepts available. Based on such a rich conceptual model designers can make choices of which parts are needed for their application and what are the consequences of choices they make (both for possible (emerging) behaviour and also for efficiency). Until such a more elaborate social model ex-ists people will have to start from scratch every time they want to implement norms with a slightly different perspective or function in mind. Although this is useful in its own right as all these implementations might support some par-ticular rich social model and give ideas on how to build this, the danger is that people get tired of using norms because they are difficult and try to circumvent the problems in current day systems with very primitive means. This will lead to poorly designed systems that are not well understood and might lead to unfore-seen or unwanted emerging behavior. The research that I have started in [1] and [2] should be seen in this light. Although norms do not feature prominently in these papers, they are the underlying motivation to take this broader perspective and start working on a more encompassing social framework. As stated in the vision paper, we hope that other researchers get inspired by this and will join the research.

3 Biography

Dr. Frank Dignum received his PhD in the previous century and has since been working in Swaziland, Portugal and The Netherlands. He is working on social aspects of software agents with applications in serious gaming and social simu-lations. He is well known for his work on norms and agent communication and lately for the combination of agents and games. His latest research focuses on creating new agent architectures to build agents that operate in real-time envi-ronments and have to cooperate with humans and other agents. He has organized many workshops and conferences on the topics and given tutorials at most major

(15)

References

1. F. Dignum, R. Prada, and G.J. Hofstede. From autistic to social agents. In AAMAS 2014, May 2014.

2. V. Dignum, C.M. Jonker, F. Dignum, and R. Prada. Situational deliberation; getting to social intelligence. In SocialPath workshop, 2014.

3. Lo¨ıs Vanhee, Huib Aldewereld, and Frank Dignum. Implementing norms? In Pro-ceedings of the 2011 IEEE/WIC/ACM International Conferences on Web Intel-ligence and Intelligent Agent Technology - Volume 03, WI-IAT ’11, pages 13–16, Washington, DC, USA, 2011. IEEE Computer Society.

(16)

Designing and Programming Multiagent

Organizations

Jaime Sim˜ao Sichman1

Laboratório de Técnicas Inteligentes (LTI) Escola Politécnica (EP)

Universidade de S˜ao Paulo (USP) Av. Prof. Luciano Gualberto, trav. 3, 158

05433-970, S˜ao Paulo, SP, Brazil [email protected]

Abstract. In the last years, social and organizational aspects of agency have become a major issue in MAS research. Recent applications of MAS on Web Services, Grid Computing and Ubiquitous Computing enforce the need of using these aspects in order to ensure some social order within these systems. One of the ways to assure such a social order is through the so-called multiagent organizations. Multiagent organizations are of two types: either the organization emerge from the activity of the indi-vidual agents or it is designed to facilitate and guide some specific global behavior. In the latter case, systems are characterized by the autonomy of the individual participants that however must be able to collabora-tively achieve predetermined global goals, within a globally constrained environment. However, there is still a lack of a comprehensive view of the diverse concepts, models and approaches related to multiagent orga-nizations. Moreover, most designers have doubts about how to put these concepts in practice, i.e., how to design and how to program them. This invited talk aims to give some possible answers to such questions.

Short Biography

Jaime Sim˜ao Sichman is an Associated Professor at University of S˜ao Paulo, from where he has obtained both his B.E. and M.E. degrees. He was one of the first students to obtain an European label to his PhD degree, developed at the Institut National Polytechnique de Grenoble (INPG), France, since part of his research was carried out at the Istituto di Psicologia del CNR (currently ISTC), Rome, Italy. He has also spent an abbreviated post-doctoral period at the Uni-versity of Utrecht, at the Netherlands. His main research focus is multi-agent sys-tems, more particularly social reasoning, organizational reasoning, multi-agent-based simulation, reputation and trust, and interoperability in agent systems. He has advised/co-advised 14 MSc, 12 PhD and several undergraduate students. With other colleagues, he was one of the founders of two subdomains in Multia-gent systems, namely Multi-AMultia-gent-Based Simulation (MABS) and Coordination, Organization, Institutions and Norms in Agent Systems (COIN), that have

(17)

orig-2

160 papers in national and international conferences and journals. He is member of the editorial board of the Journal of Artificial Societies and Social Simulation (JASSS), Mediterranean Journal of Artificial Intelligence, Computación y Sis-temas, Iberoamerican Journal of Artificial Intelligence, Knowledge Engineering Review (KER) and International Journal of Agent-Oriented Software Engineer-ing (IJAOSE). He has organized several workshops and international conferences and workshops; in particular he was the General Chair (2000) and Program Co-Chair (2006) of the Joint Brazilian/Iberoamerican Conference on Artificial Intelligence (SBIA/IBERAMIA), a member of IJCAI Local Arrangment Com-mittee (2003) and Advisory ComCom-mittee (2015), the General Chair (2014) of the World Conference on Social Simulation (WCSS) and AAMAS Tutorial Chair (2007), Program Co-Chair (2009) and Local Chair (2017). He was a member of the Brazilian Computer Society (SBC) Advisory Board between 2005 and 2009, and was the coordinator of its Artificial Intelligence Special Commission (CEIA) between 2000 and 2002. He was also the director of the Centro de Computa¸cão Eletrônica (CCE) of the University of São Paulo (USP) from 2010 to 2013.

(18)

nDrites: Enabling Laboratory Resource Multi-Agent

Systems

Katie Atkinson1_{, Frans Coenen}1_{, Phil Goddard}2_{, Terry R. Payne}1_{, and Luke Riley}1,2

(1) Department of Computer Science, University of Liverpool,

Liverpool L69 3BX, United Kingdom, {atkinson,coenen,payne,l.j.riley}@liverpool.ac.uk. (2) CSols Ltd., The Heath, Business & Technical Park, Blacon,

Runcorn WA7 4QX, United Kingdom, {phil.goddard,luke.riley}@csols.com. Abstract. The notion of the multi-agent interconnected scientific laboratory has long appealed to scientists and laboratory managers alike. However, the challenge has been the nature of the laboratory resources to be interconnected, which typ-ically do not feature any kind of agent capability. The solution presented in this paper is that of nDrites, smart agent enablers that are integrated with laboratory resources. The unique feature of nDrites, other than that they are shipped with individual instrument types, is that they possess a generic interface at the “agent end” (with a bespoke interface at the “resource end”). As such, nDrites enable the required interconnectivity for a Laboratory Resource Multi Agent Systems (LR-MAS). The nDrite concept is both formally defined and illustrated using two case studies, that of analytical monitoring and instrument failure prediction.

1 Introduction

Analytical laboratories form a substantial industry segment directed at chemical anal-ysis of all kinds (clinical, environmental, chemical, pharmaceutical, water, food etc). Supplying this marketplace is a $100B per annum industry. Laboratory instruments come in many forms but are broadly designed to undertake a particular type of chemical analysis. Examples of laboratory instrument types include: inductively coupled plasma - mass spectrometers (ICP-MS) for elemental analysis and Chromatography systems for analyte separation. Such laboratory instruments, although usually “front-ended” by a computer resource of some kind, typically operate in isolation. This is because the in-terfaces used are specific to individual instrument types (of which there are thousands) and individual manufactures. The industry acknowledges that there are significant ben-efits to be gained if instruments, of all kinds, could “talk” to each other and to other de-vices [10, 22]; an ability to support remote monitoring/managing of instruments would on its own be of significant benefit. A potential solution is the adoption of a Multi-Agent Systems (MAS) approach to laboratory resource interconnectivity: a Laboratory Resource Multi Agent System (LR-MAS).

However, at present, there is no simple way whereby the LR-MAS vision can be realised. This is not only because of the multiplicity of different interfaces for different models, but also the complex mappings, translations and manipulations that have to be undertaken in order to achieve the desired interconnectivity. Even when just consider-ing specific laboratory instruments, rather than the wider range of laboratory resources,

(19)

2 nDrites: Enabling Laboratory Resource Multi-Agent Systems

there are many thousands of models being sold at any one time and a huge variety of legacy systems still in routine use. The limited connectivity that exists is largely focused on what are known as Laboratory Instrument Management Systems (LIMS); systems that receive and store data from instruments (for later transmission to laboratory clients) and manage wider laboratory activities. Some software does exist to facilitate connec-tivity, for example the L4L (Links for LIMS) software package produced by CSols Ltd1

(a provider of analytical laboratory instrument software); but this still requires expen-sive on-site visits by specialist engineers to determine the desired functionality and the nature of the bespoke interfacing. All this serves to prevent the adoption of MAS capa-bilities within the analytical laboratory industry, despite the general acknowledgement that large scale MAS connectivity will bring many desirable benefits [10, 22].

The technical solution presented here is that of “smart agent enablers” called nDrites; an idea developed as part of a collaboration between CSols Ltd and a research team at the University of Liverpool, directed at finding a solution to allow the realisation of the LR-MAS vision. The nDrite concept is illustrated in Figure 1. As shown in the fig-ure, nDrites interact, at the “resource end”, in whatever specific way is required by the laboratory resource type in question; whilst at the other end nDrites provide generic in-teraction. Note that in the figure, for ease of understanding, the nDrite is shown as being separated from the laboratory resource (also in Figure 2), in practice however nDrites are integrated with laboratory resources. Thus nDrites provide system wide communi-cations so as to allow agents to interact with laboratory resources to (say): (i) determine the current state of an entire laboratory system, (ii) determine all past states of the sys-tem (syssys-tem history) or (iii) exert control on the laboratory resources operating within a given laboratory framework. Thus, in general terms, nDrites are a form of intelligent middleware that facilitate LR-MAS operation. The main advantage offered is that of cost. The idea is to build up a bank of nDrites, one per instrument type, that are inte-grated and shipped with the individual instruments in question. This will then alleviate the need for expensive on-site visits and provide the desired LR-MAS connectivity. The research team already have nDrites in operation with respect to two instrument types (an auto-sampler and an ICP-MS2_).

Fig. 1. nDrite smart agent enabler

The main contributions of this paper are thus: (i) the concept of nDrite smart agent enablers that facilitate multi-agent laboratory resource interconnectivity, (ii) the asso-ciated formalism that provides for the generic operation of nDrites, and (iii) two case studies illustrating the utility of the nDrite concept (the first currently in production, the second under development). The rest of this paper is organized as follows. In Section 2 some related work is presented. Our Laboratory Resource Multi-Agent System

(LR-1_{http://www.csols.com/wordpress/.}

2_The _autosampler _is _manufactured _by _Teledyne _CETAC _{Technologies,}

http://www.cetac.com, while the ICP-MS is manufactured by Perkin-Elmer, http://www.perkinelmer.com/.

(20)

nDrites: Enabling Laboratory Instrument Multi-Agent Systems 3

MAS) framework, including the nDrite concept, is presented in Section 3. In Section 4, we detail the communication method for our LR-MAS and how nDrites handle com-munication aspects. The operation of the framework is then illustrated using two nDrite application case studies. The first (Section 5) is an analytical monitoring case study agent, the second (Section 6) is a resource monitoring application agent that operates using a data stream classifier. The paper concludes with some discussion in Section 7.

2 Previous Work

The notion of the pervasive, service rich and interconnected scientific laboratory has long appealed to scientists and laboratory managers of all kinds [10, 22]. Many scien-tific laboratory processes have traditionally involved using a number of separate, but interconnected tasks, performed by different systems and services (often bespoke) with little support for automated interoperation or holistic management at the laboratory level. To facilitate this interconnectivity, early work was directed at service oriented in-frastructures using Grid (and later, Cloud) computing [8, 9, 15, 24], whereby laboratory equipment, high-performance processing arrays, data warehouses, and in-silico scien-tific modelling was wrapped, and managed, by a service-oriented client [8, 9]. The main focus was that of a “service marketplace” used to discover different services [19] and to schedule or provision their use, as well as to provide support for tasks such as: security [2], notification [17], and scheduling [24]. The need for intelligent, autonomous support for such Grid infrastructures has been well documented [8, 9, 14, 18, 24, inter alia].

The Grid Computing based laboratory infrastructure idea has now been superseded by the emergence, and wide-scale adoption, of Web Services, and consequently MAS, which exploit many of the standards used for the web, and resolved many problems of interoperability between organisations that can effect grid based approaches. This migration was essential to mitigate some of the pragmatic challenges with the inter-connection of services within an Open Agent Environment [29]; however, the flexible interoperation of systems and services (developed by different stakeholders with differ-ent assumptions) is still a challenge. This motivated the adoption of a wrapper-based approach to support wide spread usability within the nDrite concept.

The laboratory instrument MAS vision thus provides for the automation of process models and workflows [28, 19]; sequences of processes that can occur both serially and in parallel to achieve a more complex task. The laboratory workflow concept has been extensively researched. The fundamental idea is that of a collection of software services, whereby each service is either a process (often semantically annotated [8, 19, 14]), or manages and controls some laboratory resource. Such workflows are typically orchestrated using editors or AI-based planning tools [19], resulting in either an instan-tiated workflow (one where the specific service instances are identified and used) or in an abstract workflow (one where the instantiation of the services themselves is delayed until execution time). Stein et al. [24, 25] explored the use of an agent-based approach to automatically discover possible service providers where abstract services are defined within a workflow, by using probabilistic performance information about providers to reason about service uncertainty and its impact on the overall workflow. The idea was that by coordinating their behaviours, agents could “re-plan” if the providers of other

(21)

services discovered problems in their provision, such as failure, or unavailability. An interesting aspect of this workflow planning approach was the use of autonomously requesting redundant services for particularly critical or failure-prone tasks (thus in-creasing the probability of success). However, to facilitate the notion of autonomous control, the services themselves need to be endowed with the necessary capabilities to be self monitoring (and thus self aware), discoverable, and communicable [20].

The notion of agents supporting the management of laboratory services through in-teroperation and workflow (either defined a-priori or dynamically at runtime) is only possible if the agents describe and publish their capabilities, using some discovery mechanism [7]. Although many formalisms (such as UDDI, JINI, etc) have been pro-posed to support white and yellow page discovery systems, the discovery of agent-based capabilities based on knowledge-based formalisms describing inputs, outputs, precon-ditions and effects was pioneered by Sycara et. al. in the work on LARKS [26], and later with the Profile Model within OWL-S [1] and the machinery required to discover them [21]. However, before these descriptions and their underlying semantics can be defined, a formal model of the agent capabilities, and their properties should be modelled.

In the above previous work on the automation of process models and workflows using MAS technology, it was assumed that communication services would either be provided by some common or standardised interfaces or through some kind of mediator [27]. However, as noted in the introduction to this paper, there is no agreed commu-nication standard currently in existence, nor is there likely to be so; whilst currently available mediators are limited to bespoke systems such as CSols’ L4L system. Hence the nDrite concept as proposed in this paper.

3 The Laboratory Resource Multi-Agent System Framework

A high level view of the proposed nDrite facilitated Laboratory Resource Multi-Agent System (LR-MAS) framework is presented in Figure 23_{, where various laboratory}

re-sources are connected to nDrites, including: (i) two laboratory instruments (laser ab-lation systems, auto-samplers, mass spectrometers, etc.), (ii) a Laboratory Instrument Management System (LIMS) and (iii) a “links for LIMS” system (CSols’ legacy mech-anism for achieving instrument connectivity to LIMS, but still in operation). The figure also shows two users and a number of agents; for of which are connected directly to one or more nDrites. Two provide linkages between pairs of laboratory resources, and another two others are simply “front ends” to resources. The two remaining agents are application agents, not directly connected to nDrites: one is an Instrument Failure pre-diction agent and the other an Analytical Monitoring agent. We introduce Ag to denote the set of all possible agents in a LR-MAS, where Ag = {ag1, ag2, . . . , agn}.

As noted in the introduction to this paper the interconnectivity between agents and laboratory resources in our LR-MAS is facilitated by the nDrite smart agent enablers (see Figures 1 and 2). The nDrites can be considered to be wrappers for laboratory resources in the sense that they “wrap” around a laboratory resource to make the labo-ratory resource universally accessible within the context of a MAS (LR-MAS). As such,

3_{This figure represents a high level vision; in practice the connectivity/operation will be more}

(22)

Fig. 2. nDrite facilitated Laboratory Resource Multi-Agent System (LR-MAS) configuration

nDrites can be viewed as being both the agent actuators and sensors for the laboratory resources with which they may be paired. This section provides detail of the nature of nDrites. More specifically, a formalism is presented to enable the LR-MAS vision given above. The section is organised as follows. Sub-sections 3.1 and 3.2 present the formalism with respect to laboratory resources and nDrites (in their role as actuators and sensors), respectively.

3.1 Laboratory Resources

As already noted, individual laboratories comprise a number of laboratory resources. We introduce the set of laboratory resources as L = {L1, L2, . . . , Ln}. Each laboratory

resource has a set of one or more actions that the laboratory resource can perform. The complete set of possible actions that laboratory resources can perform is denoted by Ac = {α1, α2, . . . , αn}. To find the set of actions an individual resource Li can

perform we use the partial action function LRact : L 7→ 2Ac_{. Given that there are many}

different types of laboratory resources (laboratory instruments, robots, data systems, and so on) resources can be grouped into a set of categories T = {T1, T2, . . . , Tn},

where each Tiis some subset of L (Tj={Lp, Lq, . . . , Lz}). Each category is referred

to as a laboratory resource type. Thus ∀Tj ∈ T , Tj ⊆ L and ∀Li ∈ Tj, Li ∈ L.

The intersection of the actions of all laboratory resources of a particular laboratory resource type are called the critical actions for that type, denoted Ac∩Tjwhere for type

Tj:T_∀Li∈Tj LRact(Li) = Ac

∩Tj. Note that individual resources can feature other

individual actions that are not shared through the critical action set. 3.2 nDrites

The principal function of nDrites is to provide MAS connectivity without exposing the detailed operation of individual laboratory resources of many different kinds and the many different data formats. Recall that laboratory instruments are produced by

(23)

many different vendors each using proprietary data formats; there are no standardised language or communication protocols for these different resources. Therefore, nDrites are used as wrappers for laboratory resources to provide a standardised method for communicating data from, and exerting control over, every nDrite enhanced laboratory resource. As such, nDrites can be viewed as both actuators and sensors. A formal defi-nition of the operation of nDrites is presented below: initially in the context of nDrites as actuators and later in the context of nDrites as sensors.

nDrites as Actuators The set of nDrites are denoted as Den = {D1, D2, . . . , Dn},

and the set of possible nDrite actions that the complete set of nDrites Den can expose is Dc = {δ1, δ2, . . . , δn}. The following partial nDrite action function defines the set

of nDrite actions that a given nDrite can expose DenAct: Den 7→ 2Dc_{. Some nDrite}

actions may only be possible with respect to particular laboratory resources, others will be critical actions shared across a single laboratory resource type or a number of types. To find the set of laboratory resource types to which an nDrite action may be applied we use the function pos : Dc 7→ 2T_{. Actions may also be sequenced to define workflows.}

Each nDrite action δirequires a corresponding action object, which details all the

necessary parameters for δito operate successfully. The set of nDrite action objects is

Oa = {oa1, oa2, . . . , oan}. Each nDrite action object has a class type whereby each

object belongs to a class which in turn defines the nature of the object. The set of nDrite object class types is given by Ot = {ot1, ot2, . . . , otn}. The class type of each nDrite

action object is found by the following function type: Oa 7→ Ot. To find out which class type is required for each nDrite action δi, we use the object requirement function

req: Dc 7→ Ot (we assume only one object type is required for each nDrite action). Recall that individual laboratory resources are likely to perform individual actions in different ways. Hence, at the resource end, nDrites have bespoke interfaces (see Figure 1). As such, nDrites are paired with individual laboratory resources (recall Figure 2). An nDrite Djand a laboratory resource Lithat are connected together are thought of

as an agent enabling pair: AEPk = (Li, Dj). The set of all agent enabling pairs is

defined as AEP = {AEP1, AEP2, . . . , AEPn}.

Consequently, given an nDrite-laboratory resource pairing, the nDrite functionality can be mapped onto the resource functionality. Additionally, note that an nDrite action δifor an nDrite may also include additional software only actions. A software only

ac-tion is an operaac-tion performed internally to the nDrite itself with no engagement with its paired laboratory resource (for example “return the nDrite identification number”). The set of software only actions are S = {s1, s2, . . . , sn}. Therefore nDrite actions

map onto zero, one or many laboratory resource actions and zero, one or many soft-ware only actions4_{. To find the set of laboratory resource and/or software only actions}

that occur when an nDrite action is called, we use the partial nDrite exposure function exp: Aep × Dc 7→ 2Ac_{∪ 2}S_{. Given L}

i ∈ Tk then ∀δkwhere Tk ∈pos(δ/ k), the

following holds: exp((Li, Dj), δk) =∅. That is, zero laboratory resource and software

only actions occur when an nDrite action δkis attempted to be invoked on an nDrite

that cannot perform it. Should an nDrite Dj want to perform an action ac ∈ Ac on

4_{Note that the number of exposed nDrite actions can therefore be greater than the number of}

(24)

its paired laboratory resource Li, then it calls the function Perform(ac, Li). Should

an nDrite Dj want to perform an action ac ∈ S on itself, then it calls the function

Perform(ac, Dj). In both cases a Boolean is returned to indicate whether the action

was successful (true) or not (false). We do not describe in detail what occurs in the Performfunction due to the bespoke interface with the laboratory resource.

To summarise, nDrites can expose all possible actions that a laboratory resource can provide, as well as expose more software only actions. Additionally, nDrites can lower the computational burden for associated agents by exposing sequences of software and laboratory resource actions (workflows). In this manner, nDrites enhance the capabili-ties of the laboratory resources that they are attached to. Of course, for agents to trigger nDrites to perform functions, the agents must know what nDrite actions each nDrite provides. We assume this discovery capability is provided by a yellow pages agent (see [4]), which sits in the LR-MAS (not shown in Figure 2).

nDrites as Sensors For agents to work correctly with nDrites (and therefore the labo-ratory resources they are connected to), nDrites need to not only be actuators but also sensors. Therefore nDrites map laboratory resource actions into objects that can be un-derstood in our LR-MAS. Previously we mentioned that nDrites, in their actuator role, receive nDrite action objects, which are required for nDrites to perform actions. Con-currently nDrites act as sensors and produce nDrite sensor objects. The set of nDrite sensor objects are Os = {os1, os2, . . . , osn}. Each object has a class type, where the

set of object class types are defined as Ot = {ot1, ot2, . . . , otn} (note that this is the

same definition as object types for nDrite action objects). The type of each sensor ob-ject is found by the following function type : Os 7→ Ot. The set of sensor obob-jects that an nDrite maps a set of laboratory resource actions onto, is found using the function Sen: 2Ac_{× N 7→ 2}Os_{, where the natural number represents the current time point.}

Every nDrite Dj collects the nDrite sensor objects it generates in an associated

nDrite sensor database (SDBj)5that grows monotonically over time (timepoint t = 1

occurs when the nDrite is turned on). Depending on the end users needs, nDrite sensor databases can be local to the nDrite itself, sit on a laboratory server, or be in the cloud. The sensor database is defined as:

Definition 1: nDrite Sensor database. : The database SDBjfor an agent enabling

pair (Li, Dj)holds a set of nDrite objects Osi (where Osi ⊆ Os), that have been

generated by Djbecause Lihas performed the actions LAc (where LAc ⊆ Ac).

SDBit=

∅ iff t = 0,

SDB_it−1∪ Sen(LAc, t) iff t > 0 and Sen(LAc, t) 6= ∅, For nDrites to be sensors for agents, an agent needs to be able to access the objects in the nDrites database. Therefore, included in the software only actions of each nDrite are the following database access functions:

– GetObjectsByOccurancesi(2Ag× 2Ot× N) 7→ 2Os.Returns the most recent

nobjects of the given object types that occurred in the SDBiwhere n ∈ N.

5_{Additionally there exists an nDrite action database for an nDrite D}

j, denoted ADBj, which

(25)

– SubscribeToObjectsi(2Ag×2Ot×N). Causes ag ∈ Ag to subscribe to

receiv-ing automatic updates concernreceiv-ing sensor objects, saved by nDrite Diin its database

SDBi, which are of the desired object types, until the given timepoint n ∈ N.

– UnSubscribeFromObjectsi(2Ag×2Ot×N). Causes ag ∈ Ag to unsubscribe

to receiving automatic updates concerning sensor objects, saved by nDrite Diin

its database SDBi, which have the desired object types, until the given time point

n∈ N. If n = 0, then the agent is completely unsubscribed.

Additional functions required for the nDrites to operate successfully as agent sensors are as follows:

– GetSubscribersi(2Ot)7→ 2Ag. Receives a set of object types and returns the

set of agents that have subscribed to these object types.

– GetNextAction(L×N) 7→ Ac. Receives a single laboratory resource and a time limit n ∈ N, and returns the next laboratory action that occurs before the timelimit. If the laboratory resource performs no recognised action within the time limit then nullis returned.

– Connected(2Ac_×2Ac₎_{7→ {true, false}. Returns whether the first set of}

labora-tory resource actions are connected to the second set of laboralabora-tory resource actions (true) or not (false). The two sets are connected if: (i) they form a series that can be converted into an nDrite sensor object; or (ii) they form a series that, when fur-ther nDrite sensor objects are added, can be converted into an nDrite sensor object. Also, true is returned if the first set of laboratory resource actions are the empty set. F alse is returned if the second set of laboratory resource actions are the empty set or if both sets are empty.

– nDriteAdvertisingObjectsi(2Ot)→ {true, false}. Returns whether Di

is advertising that it can update the agents on the given set of object types (true) or not (false). Again, it is assumed that this advertisement is performed using a yellow pages agent.

– CollectSensorObjectsi(N) → 2Os. Returns the objects from the database

SDBithat have occurred since the time point n ∈ N.

4 LR-MAS Communication

So far we have shown that nDrites have the available functionality to be agent actuators and sensors. Note that the nDrite concept isn’t simply allowing an agent to perform an action and then observe the result. nDrites allow agents to subscribe to nDrite ob-jects, which may be generated from real world actions (e.g. a user turns an instrument off), or from other agents (e.g. another agent requests the instrument to analyse some samples). Different agents maybe interested in different actions, and so a complicated LR-MAS occurs. As nDrites are separate software entities to agents, there needs to be a communication mechanism available for the agents to utilise the actuator and sensor capabilities of the nDrites. In 4.1, we detail the message syntax between nDrites and agents. Note that the associated message syntax for agent to agent communication is considered to be out of the scope of this paper, however this can clearly be achieved us-ing a FIPA compliant agent communication language. Sub-sections 4.2 and 4.3 show:

(26)

(i) how nDrites, in their role of agent actuators, handle incoming messages; and (ii) how nDrites, in their role as agent sensors, produce messages that get sent to agents. Finally, Sub-section 4.4 gives a brief definition for LR-MAS agents.

4.1 nDrite Message Syntax

The LR-MAS given in Figure 2 features a set of communicating entities (agent-nDrite pairs). Messages are sent between these entities, from the set of possible messages, denoted by M = {m1, m2, . . . , mn}. Each message contains meta deta (denoted by

M D), a set of nDrite actions and nDrite action objects pairs6_{(NAP , where a single}

pair is indicated by the tuple hδi, oaki), and a set of nDrite sensor objects (NSO). We

assume that the meta data must include two functions Sender and Receiver that returns an entity in either the set of nDrites Den or the set of agents Ag.

Definition 2: An nDrite system message is a tuple denoted mi=hMD, NAP, NSOi

where the following holds:

1. Receiver(MD) ∈ Ag ∪ Den 2. Sender(MD) ∈ Ag ∪ Den

3. If Receiver(MD) ∈ Ag then Sender(MD) ∈ Den 4. If Receiver(MD) ∈ Den then Sender(MD) ∈ Ag 5. If NAP 6= ∅ then ∀hδi, oaki ∈ NAP the following holds:

(a) δi∈ Dc; (b) oak∈ Oa; (c) oak∈ req(δi)

6. NSO ⊆ Os

Thus an nDrite system message must have a designated receiver and sender (conditions 1 and 2). One out of the sender and receiver one must be an agent, while the other must be an nDrite (conditions 3 and 4). For each nDrite action object pair (NAP ), the nDrite action called for must be valid (condition 5(a)), the paired nDrite action object must be valid (condition 5(b)) and the paired nDrite action object must be required by the nDrite action they are paired with (condition 5(c)). Finally, the nDrite sensor objects N SOthat are provided must be part of the sensor object set Os (condition 6). 4.2 Sending messages to nDrites

In the agent actuator context, the nDrites will have to deal with many incoming messages from agents. In Algorithm 1, we present our general nDrite procedure for dealing with an incoming message. The algorithm starts with the message being un-packed (line 5). Then two sets are initialised, one for the set of nDrite actions that complete successfully (line 6) and another for the nDrite actions that do not complete successfully (line 7). As nDrites are providing wrappers for laboratory resources (in-struments, LIMS, etc), an nDrite action can fail through no fault of the nDrite software. For example, a laboratory instrument message could be blocked, or the server that hosts a LIMS could fail. Therefore each nDrite records which actions have succeed and which have failed (so as to help the error recovery process for the agents within our LR-MAS).

(27)

Algorithm 1: The nDriteReceive algorithm that handles an incoming mes-sage for the nDrite Djthat is paired with the laboratory resource Li.

1: function nDriteReceive(mi)

2: Input: hmii; where miis the received message.

3: 4: begin;

5: mi=hMDi, N APi,∅i; // Unpack the message. No sensor objects from agents

6: succ = ∅; // Set of successful actions 7: fail = ∅; // Set of failed actions

8: p = 0; // Integer count variable for nDrite actions 9: t = 0; // Current timestamp that automatically updates

10: complete = false; // Boolean that notes whether the last action completed or not 11: osj⊂ Os; // nDrite sensor object defined

12:

13: if Receiver(MDi) 6= Djthen

14: return null; // If this nDrite is not the intended recipient then quit 15: end if

16: while p < |NAP | do 17: hδ, oakip∈ NAP ;

18: if δ ∈ DenAct(Dj)and (oak= req(δ))then

19: q = 0; // Integer count variable for individual actions 20: ADBt

j= ADBtj−1∪ hδ, oakip;

21: while q < |exp((Li, Dj), δ)| do

22: acq∈ exp((Li, Dj), δ);

23: if acq∈ S then

24: complete =Perform(acq, Dj); // I.e. acqis a software only action

25: else

26: complete =Perform(acq, Li); // I.e. acqis a laboratory resource action

27: end if

28: if complete = true then 29: hδi,error informationi ∈ fail;

30: else

31: hδ, success informationi ∈ succ; 32: end if

33: q + +; 34: end while 35: else

36: hδi,error informationi ∈ fail;

37: end if 38: p + +; 39: end while

40: fail, succ ∈ osj; // Add the success and fail information to an nDrite sensor object

41: mj=hMDj,∅, {osj}i; // Add sensor object to return message

42: Receiver(MDj) = Sender(MDi);

43: Sender(MDj) = Receiver(MDi);

44: Send mj;

(28)

The first thing an nDrite should check when a message is received, is whether it was the intended receiver (line 13 in Algorithm 1). If it was not the intended receiver the message is ignored (line 14), otherwise the message is processed (line 16 onwards). When processing the message, the nDrite takes one nDrite Action-object Pair (hδ, oaki)

at a time (line 17). If this nDrite can perform the required nDrite action δ, and the required nDrite action object has been received (line 18), then δ is processed. When-ever an nDrite action object pair is to be processed, this is saved into the nDrite action database (line 20), so that a record of the system history is available. The nDrite pro-cesses δ by converting it into a sequence of laboratory resource and software actions via the exp function (line 20). If the next action acq is a software action, then it is

performed on the nDrite (line 24), otherwise it is performed on the laboratory resource (line 26). The boolean complete stores details on whether acpcompleted successfully.

If any of the actions from the exp function are unsuccessful, then the original nDrite action δ (and information on the error) are added to the list of nDrite actions that failed (line 29), otherwise the original nDrite action δ is added to the list of nDrite actions that succeeded (line 31). This process continues until all the nDrite actions in the NAP set have been dealt with (line 16)7_{. Finally, the nDrite builds and sends a message m}

jto

inform the agent of what actions succeeded and what failed (lines 40 to 44). 4.3 Sending Messages to Agents

In the context of nDrites operating as sensors for agents, Algorithm 2 presents the general nDrite sensor algorithm. The algorithm takes as input the laboratory resource Lithat is pared with the nDrite Dj. Therefore the agent-enabling pair is set as (Li, Dj).

The algorithm begins by launching a database monitoring thread (line 9), the purpose of which is to monitor this nDrite’s sensor database and send updates to the subscrib-ing agents once sensor objects of the correct type appear in the database (this thread is described in more detail later). The main function then processes sequences of labora-tory resource actions (describing a workflow) until termination (line 10). The Φ variable holds the current laboratory resource action series (workflow) that is being recorded8_.

This action series is initially set to empty (line 8).

When processing an action series (workflow) the first laboratory resource action is added to the current laboratory action series, as the Connected function always re-turns true when the current series is empty (line 12 and 13). Next the nDrite checks whether it advertises that it can update agents on the nDrite sensor objects that would appear from the conversion of the current action series (line 23). If so, these converted objects are added to the nDrite’s sensor database (line 24), as monitored through the nDriteMonitorDBfunction. Next the nDrites waits until timelimit for the next

7_{Note that if the instrument is currently busy, then the perform function will return false and}

the agent will be alerted through the error information stored in fail.

8_{A laboratory resource action sequence (workflow) can be processed by the nDrite as a}

col-lection; for example a sample analysis by a laboratory instrument. Single instrument actions can be: move to the next sample; send this sample for analysis; record sample results; move to next sample; etc. Some of this information maybe useful to some agents who want real time updates but other agents maybe “happy” to just have information on a collection of actions.

(29)

Algorithm 2: The nDriteMonitor algorithm allows the nDrite Dj to

mon-itor the laboratory resource Liand convert any laboratory resource actions into

LR-MAS understandable nDrite sensor objects. Once converted, the nDrite will update any agents that have subscribed to these nDrite sensor object types.

1: function nDriteMonitor(Li)

2: Input: hLii; where Liis the Laboratory resource to monitor.

3: 4: begin;

5: p = 0; // Integer count variable for nDrite action 6: t = 0; // Current timestamp that automatically updates

7: timelimit // A predefined integer to wait for the next lab resource action 8: Φ = ∅; // Laboratory action series initialised

9: start nDriteMonitorDB() in new thread 10: while nDrite not terminated do

11: αp= GetNextAction(Li, timelimit)

12: if Connected(Φ, {αp}) then

13: Φp= αp; // Action is added to action series

14: p + +;

15: else if αp6= null then

16: Φ =∅; // This action series has ended

17: Φ0= αp; // A new action series is initialised with the last action

18: p = 1; 19: else

20: Φ =∅; // This action series has ended 21: p = 0; 22: end if 23: if nDriteAdvertisingObjects(type(Sen(Φ, t))) then 24: SDBjt= SDBjt−1∪ Sen(Φ, t); 25: end if 26: end while 27: end; 28: 29: function nDriteMonitorDB() 30: begin;

31: Integer s = 0; // Last timestamp checked 32: while nDrite not terminated do

33: Γ = CollectObjects(s); 34: s =current time;

35: for each osi∈ Γ do

36: for each agj∈ Subscribers(type(osi))do

37: mk=hMD, ∅, {osi}i; 38: Sender(MD) = Dj; Receiver(MD) = agj; 39: send mk; 40: end for 41: end for 42: end while 43: end;

(30)

laboratory resource action in the series occurs (line 11). If it does not occur before timelimitthen the laboratory resource action will be set to null (the current workflow has been completed), so Connected will return false (line 12) and the actionSe-quence will be broken (line 20 and 21). Conversely if another laboratory action is found within the time limit (line 11), then if Connected returns true, the new action αpis

added to the sequence Φ and the process continues (lines 13 and 14). If Connected returns false, then αpis not added to the current sequence, which completes (line 16),

and instead, αpbecomes the first action of a new sequence (lines 17 and 18).

The nDriteMonitorDB thread continues to run until the nDrite terminates. The first part of the continuous loop collects nDrite sensor objects into Γ , which have oc-curred in this nDrite’s database since the last time it checked (line 33). The last check time is then updated (line 34). For every nDrite sensor object osifound (line 35), and for

each agent agjthat subscribes to updates concerning the objects of the type type(osi)

(line 36), a message is sent to each agent agjto inform it of the update (lines 37 to 39).

4.4 Definition of LR-MAS Agents

As discussed, there are extensive possibilities for LR-MAS agents, so we make no as-sumptions regrading their structure. At a highlevel, LR-MAS agents are defined as: Definition 3: An nDrite enabled LR-MAS agent is an autonomous software compo-nent that:

– Takes as input messages of the form hMD, NAP, NSOi – Sends messages of the form hMD, NAP, NSOi

How agents interpret nDrite sensor objects, and why they would build nDrite action objects is entirely up to them. Individual agents can perform a variety of tasks limited only by the nDrite actions implemented. The current classes of agent focused on for production are: (i) Discovery Agents, (ii) System Configuration Agents, (iii) Analytical Monitoring Agents and (iii) Instrument Monitoring Agents. We now provide two real world examples of nDrite usage (the two App agents in Figure 2). As Figure 2 shows, these two agents can be present in the same LR-MAS and connect to the same nDrites.

5 The Analytical Monitoring Case Study (Case Study 1)

Our first case study is focused on the “AutoDil agent” currently in operation (Figure 2). AutoDil uses two nDrites: (i) an Inductively Coupled Plasma Mass Spectrometer (ICP-MS) nDrite, denoted Dicp, and (ii) an autosampler nDrite9, denoted Das. The purpose

of the AutoDil agent is to ensure any samples from the autosampler found to be “over-range” by the ICP-MS instrument are rediluted and sent for reanalysis. An ICP-MS analyses many samples, one after the other. A collection of samples is know as a run. When a run has been completed many laboratory resource actions have been performed, which are converted by the ICP-MS nDrite Dicp(through Dicp’s nDriteMonitor

function), into a run results nDrite sensor object osrxof the type otrr.

(31)

For the AutoDil agent agad to do its job, it must subscribe to nDrite sensor

ob-jects of the type otrr from the ICP-MS instrument nDrite Dicp. Note that Dicp will

have advertised that it can update agents with respect to objects of the type otrr, thus

nDriteAdvertisingObjects({otrr}) = true. When agad receives an nDrite

sensor object osryof type otrr, then it should analyse osryto see if any samples in

the results run need redilution. Whenever agadfinds samples that require redilution, it:

1. Builds an nDrite action object oaxthat includes information on the dilution amounts

for each sample and calls the AddDilutions nDrite action in Dasby

construct-ing the message mp=hMD, h AddDilutions, oaxi, ∅i, where Receiver(mp)

= Dasand Sender(mp) = Agad.

2. Builds an nDrite action object oaythat includes information on which samples to

be reanalysed and calls the SetupRun nDrite action in Dicpby constructing the

message mp=hMD, h SetupRun, oaji, ∅i, where Receiver(mp) Dicpand

Sender(mp) = Agad.

After performing both (1) and (2), the agadwaits for new objects from the ICP-MS

nDrite, which may including information on samples that required further dilution. The nDrites will deal with messages (1) and (2) through their nDriteReceive function. The nDrite Daswill convert the nDrite action AddDilutions through the

expfunction, to actions that its paired autosampler can understand. The purpose of these converted actions will be to tell the autosampler which samples require what level of dilution. The nDrite Dicpwill convert the nDrite action SetupRun, again through

the exp function, to actions that its paired ICP-MS instrument can understand. The purpose of these actions will be to tell the ICP-MS instrument what samples it should load from the autosampler (and therefore what data it will be collecting). The nDrites will then report to agadwhat actions were successful. If all were successful then the

autoDil agent knows that it should soon expect another run results nDrite sensor object osrzof type otrr, which will hold information on the diluted samples.

6 The Instrument Failure Prediction Case Study (Case Study 2)

The second case study is an instrument failure prediction scenario where a dedicated agent (see Figure 2) is used to predict instrument failure using a data stream classi-fier trained for this purpose (as proposed in [3]). This agent is currently under devel-opment. Instrument failure within analytic laboratories can lead to costly delays and compromise complex scientific workflows [23]. Many such failures can be predicted by learning a failure prediction model using some form of data stream mining, which is concerned with the effective, real time, capture of useful information from data flows [11–13]. A common application of data stream mining is the analysis of instrument (sensor) data with respect to some target objective [5, 6]. There is little work on using data stream mining to predict the failure of the instruments (sensors) themselves other than [3] which describes a mechanism whereby data stream mining can be applied to learn a classifier with which to predict instrument failure. In our LR-MAS, an instru-ment failure prediction app agent impleinstru-ments the mechanism of [3] by communicating with other agents that are connected to nDrites (referred to as Dendrites in [3]).

(32)

7 Conclusions

We have described a mechanism to realise the benefits of MAS in the context of an-alytical laboratories where laboratory resources are not readily compatible with the technical requirements of MAS. Our solution is the concept of nDrites, “smart agent enablers”, that at one end feature bespoke laboratory resource connectivity while at the other end feature a generic interface usable by agents of all kinds. The vision is that of a Laboratory Resource MAS (LR-MAS). The operation of nDrites was fully described in the context of: laboratory resources, nDrites as agent actuators, nDrites as sensors, the communication mechanisms and the associated agents. The utility of nDrites was illus-trated in two case studies: (i) an analytical monitoring case study for an “AutoDil agent” currently in operation; and (ii) a instrument failure prediction case study, featuring mon-itoring agents, that is currently under development. We believe that the proposed nDrite concept will enable the interconnected scientific laboratories of the future.

Acknowledgements

This work was conducted as part of the “Dendrites: Enabling Instrumentation Connec-tivity” Innovate UK funded knowledge transfer partnership project (KTP009603).

References

1. Ankolekar, A., Burstein, M., Hobbs, J. R., Lassila, O., Martin, D. L., McDermott, D., McIl-raith, S. A., Narayanan, S., Paolucci, M., Payne, T. R. and Sycara, K. DAML-S: Web Service Description for the Semantic Web. Proc. of ISWC, 2002.

2. Ashri, R., Payne, T. R., Luck, M., Surridge, M., Sierra, C., Aguilar, J. A. R. and Noriega, P. Using Electronic Institutions to secure Grid environments. 10th International Workshop on Cooperative Information Agents. p461-475, 2006.

3. Atkinson, K., Coenen, F., Goddard, P., Payne, T and Riley, L. Data Stream Mining with Lim-ited Validation Opportunity: Towards Instrument Failure Prediction. 17th Int’l Conference on Big Data Analytics and Knowledge Discovery, Springer LNCS, p283-295, 2015. 4. Bellifemine, F. L., Caire, G. and Greenwood, D. Developing Multi-Agent Systems with JADE

(Wiley Series in Agent Technology) John Wiley & Sons, 2007.

5. Cohen, I., Goldszmidt, M., Kelly, T., Symons, J. and Chase, J.S. Correlating Instrumentation Data to System States: A Building Block for Automated Diagnosis and Control. Proc 6th Symposium on Operating Systems Design and Implementation, p231-244, 2004.

6. Cohen, L., Avrahami-Bakish, G., Last, M., Kandel, A., and Kipersztok, O. Real Time Data Mining-Based Intrusion Detection. Information Fusion, 9(3), p344-354., 2008.

7. Decker, K., Sycara, K. and Williamson, M. Middle-agents for the Internet. 15th International Joint Conference on Artificial Intelligence (IJCAI’97), p578-583, 1997.

8. De Roure, D., Jennings, N.R. and Shadbolt, N. The Semantic Grid: A Future e-Science In-frastructure. Grid Computing-Making the Global Infrastructure a Reality, p437-470, 2003. 9. Foster, I., Jennings, N. R. and Kesselman, C. Brain meets Brawn: why Grid and Agents need

each other. In Proc of. AAMAS, p8-15, 2004.

10. Frey, J.G., De Roure, D., schraefel, M.C., Mills, H., Fu, H., Peppe, S., Hughes, G., Smith, G. and Payne, T. R. Context Slicing the Chemical Aether. 1st International Workshop on Hypermedia and the Semantic Web, Nottingham, UK, 2003.

(33)

11. Gaber, M. M., Zaslavsky, A. and Krishnaswamy S. Mining Data Streams: A Review. ACM SIGMOD Record, 34(2), p18 - 26, 2005.

12. Gaber, M. M., Gama, J., Krishnaswamy, S., Gomes, J.B. and Stahl, F. Data Stream Mining in Ubiquitous Environments: State-of-the-Art and Current Directions. Wiley Interdisciplinary Reviews: Data Mining and Knowledge Discovery; 4(2), p116-138, 2014.

13. Gama, J (2010). Knowledge Discovery from Data Streams. Chapman and Hall.

14. Gil, Y. From data to knowledge to discoveries: Artificial intelligence and scientific work-flows. Scientific Programming 17(3): p231-246, 2009.

15. Hamdaqa, M. and Tahvildari, L. Cloud Computing Uncovered: a Research Landscape. Ad-vances in Computers 86: p41-85, 2012.

16. Jacyno, M., Bullock, S., Geard, N., Payne T. R., and Luck, M. Self-Organising Agent Com-munities for Autonomic Resource Management. Adaptive Behaviour Journal. 21 (1), p3-28, 2013.

17. Lawley, R., Luck, M., Decker, K., Payne, T. R. and Moreau, L. Automated Negotiation Be-tween Publishers and Consumers of Grid Notifications. Parallel Processing Letters, 13 (4). p537-548, 2003.

18. Merelli, E., Armano, G., Cannata, N., Corradini, F., d’Inverno, M., Doms, A., Lord, P., Mar-tin, A., Milanesi, L., Moller, S., Schroeder, M., Luck, M. Agents in Bioinformatics, Compu-tational and Systems Biology. Briefings in Bioinformatics, 8(1), p45-59, 2007.

19. Oinn T., Greenwood M., Addis, M., Alpdemir, M. N., Ferris, J., Glover, K., Goble, C., Goderis, A., Hull, D., Marvin, D., Li, P., Lord, P., Pocock, M. R., Senger, M., Stevens, R., Wipat, A., and Wroe, C. Taverna: Lessons in Creating a Workflow Environment for the Life Sciences. Concurrency and Computation: Practice and Experience, 18(10), p1067-1100, 2006.

20. Payne, T. R. Web Services from an Agent Perspective. IEEE Intelligent Systems, 23(2), 2008. 21. Paolucci, M., Kawamura, T., Payne, T. R. and Sycara, K. Semantic Matching of Web Services Capabilities. Proceedings of the 1st International Semantic Web Conference (ISWC), 2002 22. Schraefel, M. C., Hughes, G., Mills, H., Smith, G., Payne, T. and Frey, J. Breaking the Book:

Translating the Chemistry Lab Book into a Pervasive Computing Lab Environment. SIGCHI Conference on Human Factors in Computing Systems, April 24-29, Vienna, Austria, 2004. 23. Stein, S., Payne, T.R. and Jennings, N.R. Flexible QoS-Based Service Selection and

Provi-sioning in Large-Scale Grids. UK e-Science All Hands Meeting, HPC Grids of Continental Scope, 2008.

24. Stein, S., Payne, T. R. and Jennings, N. R. Flexible Selection of Heterogeneous and Unre-liable Services in Large-Scale Grids. Philosophical Transactions of the Royal Society A: Mathematical, Physical & Engineering Sciences, 367 (1897). p2483-2494, 2009.

25. Stein, S., Payne, T. R. and Jennings, N. R. Robust Execution of Service Workflows using Redundancy and Advance Reservations. IEEE Trans. Services Computing. 4(2), 2011. 26. Sycara, K., Widoff, S., Klusch, M. and Lu, J. LARKS: Dynamic Matchmaking Among

Het-erogeneous Software Agents in Cyberspace. AAMAS, 5(2), 173-203, 2002.

27. Szomszor, M., Payne, T. R. and Moreau, L. Automated Syntactic Medation for Web Service Integration. In: IEEE International Conference on Web Services, Chicago, USA, 2006. 28. Wassink, I., Rauwerda, H., Vet, P., Breit, T., and Nijholt, A. E-BioFlow: Different

Perspec-tives on Scientific Workflows. Bioinformatics Research and Development: Second Interna-tional Conference, Vienna, Austria, July 7-9, 2008.

29. Wens, D., Michel, F. Agent Environments for Multi-agent Systems - A Research Roadmap. Agent Environments for Multi-Agent Systems IV: 4th International Workshop, E4MAS 2014 - 10 Years Later, p3-21, 2014.

Engineering Multi-Agent Systems, Proc. of 4th International Workshop on Engineering Multi-Agent Systems, EMAS 2016

This is the author’s final version of the contribution published as:

Matteo Baldoni, J¨rg P. M¨

uller, Ingrid Nunes, Rym Zalila-Wenkstern (eds.)

Engineering Multi-Agent Systems, Fourth International Workshop, EMAS

2016 Singapore, May 9th and 10th, 2016. Workshop Notes.

The publisher’s version is available at:

http://www.di.unito.it/~argo/papers/EMAS2016-WorkshopNotes.pdf

When citing, please refer to the published version.

Link to this full text:

http://hdl.handle.net/2318/1567314

Matteo Baldoni, J¨org P. M¨uller

Ingrid Nunes, Rym Zalila-Wenkstern (eds.)

Engineering Multi-Agent

Systems

Fourth International Workshop, EMAS 2016

Singapore, May 9th and 10th, 2016

Workshop Notes

Preface

Table of Contents

Program Committee

Steering Committee

Acknowledgements

Implementing Norms

Why is it so difficult?

1

Introduction

2

Acting with Norms

3

Biography

References

Designing and Programming Multiagent

Organizations

nDrites: Enabling Laboratory Resource Multi-Agent

Systems

1 Introduction

2 Previous Work

3 The Laboratory Resource Multi-Agent System Framework

4 LR-MAS Communication

5 The Analytical Monitoring Case Study (Case Study 1)

6 The Instrument Failure Prediction Case Study (Case Study 2)

7 Conclusions

Acknowledgements

References