Towards Verifiable Multi-Agent Interaction Pattern Specification

Smart cyber agents play a crucial role in software-intensive systems by monitoring their physical surroundings and making impactful decisions. This paper addresses the challenge of specifying multi-agent patterns, which include interactions with human agents in possibly safety-critical environments. To this end, we introduce the foundations of a domain-agnostic and flexible Domain-Specific Language (DSL) called LIrAs. The language is designed to be accessible to users without programming expertise. LIrAs' semantics are mapped to Deterministic Finite-state Automata, making specifications amenable to formal verification. The DSL is exemplified through an illustrative scenario from the service robotics field.


INTRODUCTION
Software-intensive systems are growingly pervasive due to rapidly developing technologies such as assistive robotics, IoT, and intelligent manufacturing systems.Smart cyber agents realize such systems by monitoring their physical surroundings and making decisions that impact the environment in which they operate.Complex systems often feature multiple agents (i.e., multi-agent systems) interacting or synchronizing with each other or the environment (e.g., with human agents) to perform their tasks.Such systems are often safety-critical (for example, due to the presence of humans), and failing to complete a specific task may incur significant costs.

Envisioned Toolchain
Specifying interactive multi-agent tasks is a long-standing software engineering challenge [6].Specifications should be sufficiently highlevel to preserve accessibility and unambiguous to guarantee the dependability of the resulting software components.
This paper addresses this issue by presenting the foundational features of a DSL-based toolchain (see Fig. 1) called LIrAs 1 for specifying multi-agent interaction patterns.LIrAs is developed to be domain-agnostic and flexible with respect to the number and nature of agents involved (e.g., software-based or human) and the number and type of actions constituting the pattern.Agents differ based on the primitive skill set they offer (e.g., moving for a robot or switching on the engine for a quadcopter).In LIrAs, such skills are arranged into patterns.As per Fig. 1, defining the skill set requires the intervention of an expert practitioner, while pattern specification is designed to be accessible to non-expert users.
In LIrAs, the semantics of the synchronization dynamics between agents is based on Deterministic Finite-state Automata (DFA), making this aspect of the specifications amenable to model-to-model conversion and formal verification.Specifically, properties concerning the well-definedness of the synchronizations can then be verified through the Uppaal tool [11].This stage of the toolchain targets only properties concerning the logical and structural soundness of the pattern (e.g., skills with conflicting goals), thus not involving the physical component of the corresponding cyber-physical system.
Several LIrAs specifications constitute a pattern library.In the following, we intend term mission as a sequence of patterns.A so-defined and verified library of patterns can be used in a wider mission specification and formal analysis toolchain external and decoupled from LIrAs, such as the one presented in [12].The latter envisages a textual DSL (separate from LIrAs) to specify missions involving human and robot agents with a particular focus on human-robot interaction.Such DSL currently exploits humanrobot interaction patterns from a pre-determined and fixed set, thus limiting the framework's applicability to real-life scenarios.This shortcoming could be overcome by importing a LIrAs pattern library for specifying the mission.We remark that the specification of the operational environment (e.g., the layout and the points of interest) is assumed to be done independently of LIrAs (i.e., LIrAs patterns are parametric w.r.t. the environment).
Within the broader framework, the resulting mission specification is automatically converted into a formal model based on Stochastic Hybrid Automata [5].Should custom LIrAs interaction patterns be imported, automated generation of the formal model would imply drafting the formal model of each custom skill employed in the newly defined pattern, which requires the input of an expert user.The resulting formal model of the mission is subject to Statistical Model Checking [5] to compute quality metrics concerning the mission (e.g., time to completion and physical effort required on the humans' side) and apply reconfiguration measures, if necessary.In this later stage of the toolchain, given the hybrid nature of Stochastic Hybrid Automata, both the cyber and physical components of the corresponding system can be involved in the formal analysis.Properties to be verified may concern, for example, relevant physical variables with continuous dynamics (e.g., a robot's battery charge) or the incompatibility between the custom-defined patterns and the environment.

Related Work
Several formal notations have been exploited over the years to model the workflow of agents' tasks, such as Petri Nets [17], automata [10], and Linear Temporal Logic [19].However, these approaches are meant for automated development toolchains and are, thus, inaccessible to users lacking expertise in formal modeling.When a human-in-the-loop approach is required, a common practice consists in using a high-level DSL to define specifications that would otherwise be excessively ambiguous in natural language.DSLs for task specification can either be general-purpose [4,16,20], or target specific categories of agents, such as autonomous vehicles [18], aerial [14] and medical rehabilitation robots [7].Specifically, concerning robotics, Nordmann et al. in 2014 surveyed 137 DSLs [15], and significant progress has been made in the field ever since.For example, PsALM [13] is a structured grammar-based DSL that defines 22 patterns for robotic missions.PROMISE [8] envisages the specification of concurrent robot missions through sequences of basic actions instead of predefined patterns.PGCD [2] combines message-passing and motion primitives for robots in a fleet.The MutRoSe framework [9] automates the decomposition of a mission into valid task sequences allocated to different robots in a fleet.PuRSUE [3] envisages a modeling language for human-robot interactions whose specifications are compiled into Timed Game Automata.The language, however, contains lower-level primitives since it targets users with a stronger technical background and could be considered complementary to LIrAs.
LIrAs allows for more flexible specifications by combining agents' primitives into patterns rather than relying on a predetermined set thereof.Therefore, a LIrAs specification is not tied to a specific type of agent: any set of agents (including humans) offering the required skills is compatible with a LIrAs pattern.The latter feature also targets a shared shortcoming of existing languages, i.e., the limited or absent support for patterns involving human agents.Finally, LIrAs targets a level of abstraction high enough to avoid the description of architectural details (patterns are parametric w.r.t., for example, a robot's angular and translational velocities).

Paper Contributions
In this research idea paper, we lay the foundations for the LIrAs toolchain, presenting: -the fundamental features of the LIrAs syntax; -their formalization through DFA; -an illustrative application of LIrAs to a use case from the assistive robotics domain.
LIrAs syntax and semantics are outlined in Section 2 and exemplified through the illustrative example; Section 3 concludes and discusses future research directions.

LIRAS SYNTAX AND SEMANTICS
We present the foundational features of LIrAs's syntax and its semantics based on DFA.

Syntax
LIrAs's syntax is exemplified through Listing 1 and Listing 2. Agents are the actors realizing LIrAs's specifications.Each agent is characterized by an id and is indicated in the rest of this paper as a id ∈ AG.In the following, the term action refers to an atomic skill an agent possesses.Actions are the foundational building blocks of the language and are denoted as <action{i}>.An action may be parametric w.r.t. the environment (e.g., moving to a specific point of interest in the environment), and the actual value of each parameter must be specified through an identifier (e.g., moveTo poi1).
Actions can be declared within conditional blocks, which, based on their type, capture premature termination, introduce dependencies between agents, and impose time constraints.Table 1 details the grammar for a conditional action block.The DSL assumes that a set AP of atomic predicates (e.g., indicating an agent being in possession of a resource) and a set W of real-valued variables (e.g., capturing the position of an agent) are available.In the following, we use the generic token <condition> to indicate conditions consisting of atomic predicates and constraints of the form  ≶  (where  is a variable and  is a threshold), possibly combined Listing 1: Abstract example of LIrAs' syntax, reporting the fundamental elements.through the usual Boolean operators (¬, ∧).There are two types of conditional action blocks: • <action> until <condition>, stating that <action> is interrupted as soon as <condition> is true; • <action> if <condition> else <action'>, stating that if <condition> is true, then <action> is executed, otherwise <action'> is.
Actions executed by the same agent are grouped into sequences.The declaration of agent a id 's sequence begins with <agent_{id}>.Sequences are composed of an ordered list of sub-sequences, each syntactically identified by a label of the form <l{i}>, where i is a strictly increasing index.Formally, sub-sequence  executed by agent a id is represented through notation a id .si .Sub-sequences contain one or more actions that must be executed sequentially.Notation a id .si .xj refers to action  of sub-sequence a id .si .Action a id .si .xj+1 can start only if a id .si .xj has been completed.Similarly, a id .si+1 can only start if a id .si has been completed.In Listing 1, a 1 's sequence includes two sub-sequences labelled as <l1> and <l2>.Sub-sequence <l1> only contains <action1>, while <action2> and <action3> both belong to <l2>, and are executed sequentially.
Sub-sequences belonging to different agents' sequences can share the same label.Synchronization between different agents, indeed, occurs by having sub-sequences with the same label start simultaneously.In Listing 1, Lines 3 and 7 start simultaneously, and the same happens for Lines 4 and 8.By default, a id .s 1 begins simultaneously for all agents.If a sub-sequence contains no action, it can either be declared empty or omitted entirely.Both cases correspond to the agent performing a default action (e.g., waiting or moving freely), which can be redefined through the default keyword.
The example from the service robotics domain demonstrates how a pattern can be specified using LIrAs (see Listing 2) starting from a natural language specification.We assume that a set of predicates is available: time() is true if at least  time units have elapsed since the beginning of the pattern; position(, ) is true if agent 's position equals  while dist(, ) returns the Euclidean distance between  and ; possess(, ) is true if agent  holds resource ; finally, tired() is true if agent  requires rest before moving again, and SoC() returns the state of charge of agent .
The scenario involves three agents: two robots (indicated as Robot1 and Robot2) and a Human.The robots' skill set includes stopping, moving to a target, fetching a resource, and delivering a resource.The human's skill set includes moving to a target, following another agent, stopping, and receiving a resource from another agent (the latter must synchronize with a delivering action).We assume that the environment features two points of interest (referred to as room1 and room2) and one resource named item1.Initially, Robot1 waits for the Human to approach (Line 4).Concurrently, Robot2 moves to room1 for patrolling (Line 15).Upon completing Table 1: Grammar for a conditional action.
Listing 2: LIrAs interaction pattern for the three agents from the service robotic example.
1 P a t r o l F e t c h D e l i v e r ( Robot1 , Robot2 , Human , 2 room1 , room2 , i t e m 1 , d_th , t _ t h , c _ t h ) 3 R o b o t 1 : Throughout this interaction, the robot monitors the distance with the Human, stopping if it exceeds a certain threshold and resuming when the Human gets closer.Human follows Robot1 (Line 10); if tired, it stops and resumes following the robot only when rested.When both Human and Robot1 reach room1, Human waits (Line 12) for Robot1 to fetch item1 and deliver it (Lines 6, 7, and 8).Since its presence in room1 is not necessary once Human is there (Line 16), Robot2 moves to room2 (Line 17).The pattern is successfully completed when Human is in room1 and has item1 (note that the pattern can be completed before Robot2 reaches room2).The pattern fails if it takes more than time t_th to complete or if Robot1's charge (SoC) falls below a threshold.
Listing 2 shows a broader range of synchronization dynamics among sub-sequences.Sub-sequences can also be grouped into a continuation, labeled as <l{i}-{i+k}> (see Listing 2, Line 12).This sub-sequence set starts synchronously with   and is only required to end for  ++1 to start (i.e., no further synchronization is enforced with sub-sequences in the range [ +1 ,  + ]).This feature captures the cases when more than two agents are involved and not all sub-sequences must start synchronously for all the agents.In the example in Listing 2, Line 12 features a continuation because the human does not need to synchronize with Robot1 when it has picked up the item and starts moving back to the human to deliver it.Similarly, Robot2 only needs to synchronize with the human when they enter room1, thus Lines 16 and 17 are part of a continuation.
A set of sequence declarations, one for each agent a id ∈ AG, with |AG| ≥ 1, constitutes a pattern, whose identifier is indicated through token <pattern> in Listing 1.The execution of a pattern is considered complete when the last subsequence of each agent has been completed.It is also possible to specify sufficient conditions for successful (e.g., each agent's goal has been achieved) or unsuccessful (e.g., an agent is unable to proceed due to exhausted battery) termination of the pattern through tokens <success> and <failure> followed by a condition expressed according to Table 1.

Semantics
As detailed in the following, the semantics of synchronization among agents in LIrAs patterns defined according to this syntax can be mapped to DFA.DFA are defined as follows.
Definition 2.1.A DFA is a 5-tuple (, ,   , , ) where  is the alphabet (i.e., a set of symbols);  is the set of states, with   ∈  as the initial state;  ⊆  is the subset of final states;  :  × →  defines the state transitions labeled with symbols in .
A LIrAs pattern can be converted into a DFA network.The conversion is exemplified through the DFA network in Fig. 2, modeling the pattern in Listing 2.
Each agent in set AG corresponds to a standalone DFA, and the DFA in the network synchronize over symbols in .DFA modeling agent a id ∈ AG has an initial state a id . modeling the situation in which no subsequence has started and a final state a id . modeling the case in which all subsequences have ended.For each subsequence a id .si , the DFA has two states (indicated as a id ., and a id ., ), modeling a id being busy executing a id .si and a id having completed a id .si and waiting for the following synchronization, respectively.Notice that a (a id ., , a id ., ) pair is defined even when a id .si consists only of the default action, but not for continuations (e.g., for subsequence a 2 .s 3 ).In the latter case, state a 2 .3, is not necessary because, due to the continuation, a 2 does not need to synchronize with other agents to start a 2 .s 4 .
Symbols   ∈  are defined for each index  ∈ N such that subsequence a id .si is defined for some a id ∈ AG.Internal action  and symbol end marking the end of a sequence are also available.Transition function  then defines, for all (a id ., , a id ., ) pairs, a transition labeled with internal action  from a id ., to a id ., capturing the completion of a id .si .Furthermore, a transition labeled with   is defined between each (a id ., , a id ., ) pair such that no other subsequence a id .sk with  <  <  exists, marking the start of a id .sj .If a id .si is the last for a id , an edge labeled with end from a id ., to a id . is defined.
In this preliminary stage, guard conditions deriving from conditional action blocks (including time constraints) are not involved in the mapping to DFA.The same holds for early termination conditions due to success and failure.In the future, we plan on incorporating all these aspects into the model-to-model conversion of LIrAs Human: Robot2: patterns, thus requiring an extension of the semantics to Timed Automata.In light of this, we use Uppaal for our analysis2 , even if the models do not currently capture time.Also, the properties regarding the well-definedness of patterns that are verified on DFA networks are expressed in Timed Computation Tree Logic (TCTL), although the temporal features of the logic are not currently exploited.As a result, Uppaal considers all the transitions in the DFA networks non-deterministic w.r.t. the firing time.
Figure 2 shows the DFA specification for the illustrative example.Notice that, due to the continuations of Human and Robot2, the former does not need to synchronize over symbol  4 , and the same stands for the latter and symbols  3 ,  4 , and  5 .For the network in Fig. 2, the TCTL property captured by Formula (1)-which states that there exists a path such that eventually all agents reach the final state-is verified. EF The property captured by Formula (2) (i.e., "for all paths, eventually all agents reach the final state"), instead, does not hold for the network since an agent can remain indefinitely in any state other than   . AF Including timing constraints and conditional action blocks in the model extends the range of verifiable properties, potentially highlighting issues arising from unsatisfiable action completion conditions (e.g., a location being unreachable).For the network in Fig. 2, examples of issues that may arise from the verification of well-formedness properties are item1 being in an unreachable position (thus, the action on Line 6 never terminates) or the entire pattern always failing to complete within time t_th.

FUTURE RESEARCH OUTLOOK
In the future, we plan on releasing LIrAs as a fully-fledged toolchain by implementing all the steps envisaged in Fig. 1.To this end, it is necessary to extend LIrAs's semantics to Timed Automata, incorporating guards and timing constraints in the model-to-model conversion and significantly extending the range of verifiable properties.State-of-the-art testing techniques could be employed to explore the domain of the involved variables in the absence of a specific environment definition.
We also plan on assessing the effectiveness of LIrAs when serving as the basis for a broader mission analysis framework through realistic scenarios (see, for example, those collected in [1]).This requires developing an automated approach to compile LIrAs patterns into Stochastic Hybrid Automata, potentially starting from formal model snippets corresponding to individual skills.
Finally, a user study is necessary to ascertain the user-friendliness of the language to non-expert users with a technical skillset (e.g., practitioners without a background in programming) and domain experts (e.g., logistic experts in need of deploying a multi-agent mission in their facility).

123
Authorized licensed use limited to the terms of the applicable license agreement with IEEE.Restrictions apply.

4 l1: s t o p 5 l2:
moveTo room1 i f d i s t ( Human , Robot1) < d _ t h e l s e s t o Robot1 u n t i l d i s t ( Human , Robot1) < d _ t h 11 l2: f o l l o w Robot1 ( room1 ) i f !t i r e d e l s e s t o : s t o p u n t i l !p o s i t i o n ( Human , room1 ) c c e s s p o s i t i o n ( Human , room1 ) && p o s s e s s ( Human , i t e m 1 ) 20 f a i l u r e t i m e ( t _ t h ) | | SoC ( Robot1) < c _ t h this initial movement, Robot1 must guide Human to room1 (Line 5).

Figure 2 :
Figure 2: DFA network representing the illustrative example scenario.