Mission Specification Patterns for Mobile Robots: Providing Support for Quantitative Properties

With many applications across domains as diverse as logistics, healthcare, and agriculture, service robots are in increasingly high demand. Nevertheless, the designers of these robots often struggle with specifying their tasks in a way that is both human-understandable and sufficiently precise to enable automated verification and planning of robotic missions. Recent research has addressed this problem for the functional aspects of robotic missions through the use of mission specification patterns. These patterns support the definition of robotic missions involving, for instance, the patrolling of a perimeter, the avoidance of unsafe locations within an area, or reacting to specific events. Our article introduces a catalog of QUantitAtive RoboTic mission spEcificaTion patterns (QUARTET) that tackles the complementary and equally important challenge of specifying the reliability, performance, resource usage, and other key quantitative properties of robotic missions. Identified using a methodology that included the analysis of 73 research papers published in 17 leading software engineering and robotics venues between 2014–2021, our 22 QUARTET patterns are defined in a tool-supported domain-specific language. As such, QUARTET enables: (i) the precise definition of quantitative robotic-mission requirements and (ii) the translation of these requirements into probabilistic reward computation tree logic (PRCTL), supporting their formal verification and automated planning of robotic missions. We demonstrate the applicability of QUARTET by showing that it supports the specification of over 95% of the quantitative robotic mission requirements from a systematically selected set of recent research papers, of which 75% can be automatically translated into PRCTL for the purposes of verification through model checking and mission planning.


INTRODUCTION
T HE engineering of robotic applications is a complex interdisciplinary activity. Similar to many other domains, robotics requires contributions from different yet interdependent engineering roles. Robotics engineers build low-level primitives that allow higher-order control, while software engineers develop higher-level software components executed by robots [1]. As such, there is a great need for software solutions that can support the multiple activities of the engineering process -from requirements elicitation to software development and validation, e.g., [2], [3], [4], [5], [6], [7]. Mission specification is among the most important of these activities, as it entails capturing the requirements of robotic applications in a precise manner and in a form useful for automatic processing. Mission specification touches upon -and draws from -multiple aspects of development, ranging from capturing what the robot(s) should do and how it should be done to evaluating if the resulting behavior(s) indeed satisfy what was intended for the mission. Due to this multifaceted role, mission specification represents one of the main challenges in engineering robotics software [8], [9].
Typically, the engineering of robotics software is bootstrapped by requirements described in natural language, which are then translated into precise mission specifications. Such a mission requirement describes the high-level tasks that a robotic application must accomplish [10]. To be accessible, this description should use a notation that is high-level and user-friendly [10], [11]. At the same time, it should preclude misinterpretation and enable the automatic verification and synthesis of the robotics software by formally and precisely specifying what the robot(s) should do in terms of movements and actions [12], [13], [14]. We use the term mission specification problem for the problem of (automatically) generating a mission specification from a mission requirement.
The main uses of mission specifications are: (i) unambiguous communication of the mission within the engineering team developing a robotic application and to other stakeholders, (ii) verification, where the robotic software or behaviors sourced from a robotic system or its simulation are checked against the specification, and (iii) synthesis, where behaviors that provably satisfy the specification are constructed.
Mission specifications are often expressed in domainspecific languages (DSLs), many of which have been proposed over the last decades [15], [16]. These DLSs are usually integrated with development environments, enabling the generation of code that can then be executed within simulators or by real robots [17], [18], [19], [20], [21]. However, these languages are typically bound to specific types of robots, and support a limited class of missions. Moreover, these languages are procedural and therefore require a step-by-step specification of the precise tasks that the robots should perform.
Other research, especially from the robotics domain, advocates the use of temporal logics to formally specify missions and they enable to specify missions in a declarative way, i.e., to specify what should be achieved without expressing how this should be achieved [22], [23], [24], [25]. However, specifying missions in terms of temporal logic formulae is complex and error-prone for practitioners and engineers. As such, defining robotic missions is generally challenging, as widely recognized in both the software-engineering and robotics communities [26], [27], [28], [29].
Indeed, while precise specifications in logical languages enable reasoning [30], [31], their definition is difficult and prone to errors [32], [33]. Practitioners are often unfamiliar with the specification process and the complicated syntax and semantics of logical languages [34]. To ameliorate this, we recently proposed a set of specification patterns for robotic missions [35], [36], [37] which provide template solutions that support users in specifying common mission concerns. Within this pattern-based approach, requirements are expressed in a domain-specific language, and then automatically translated into logic-based specifications that can be fed into existing logic-based planners and verifiers (e.g., [31], [38], [39], [40], [41], [42], [43]). However, the patterns from [35], [36], [37] target abstract robotic mission concerns -such as constraints in the ordering of robot actions or triggers -ignoring the quantitative aspects of robotic missions.
Quantitative aspects, however, are key to practical robotics applications. Users and operators of robotic systems often require behaviors that ensure quantitative constraints such as upper bounds on the time a robot takes to perform an action, the energy consumption to complete that action, or the probability of failing to achieve a mission goal. In this paper, we introduce a catalog of QUantitAtive RoboTic mission spEcificaTion patterns (QUARTET) that bridges this gap. QUARTET provides declarative specification [44] patterns that enable the definition of quantitative constraints and optimisation objectives for robotic missions, and supports: (i) the unambiguous specification and communication of quantitative aspects associated with robotic missions; (ii) the verification of mission plan compliance with quantitative requirements; and (iii) the synthesis of correct-by-construction mission plans that meet these requirements. Moreover, we extended our previous catalog of patterns and its DSL [35], [36], [37] instead of extending an existing one (see the reference above), since other DSLs are typically tailored to a specific target specification language, e.g., the specification language of a particular model checker, and this places boundaries on their expressiveness. A key characteristic of our patterns is that they are built from data collected from research literature. Therefore, collected data shapes both the patterns and the DSL. Our patterns are language-agnostic and can be used as main building blocks for other DSLs specialized on specific needs, as has already occurred for our previous catalog of patterns [35], [36], [37], which has been exploited to build the Promise DSL [21], [45]. These aspects are detailed in the related work section.
Our main contributions lie within the area of software engineering for robotics and are as follows: We introduce a comprehensive catalog of 22 quantitative mission specification patterns, called QUARTET, for the definition of quantitative constraints and optimisation objectives for robotic missions. These patterns support the mission specification problems identified by systematically analyzing 51 quantitative robotic-mission requirements published in 17 leading software engineering and robotic venues over six years (Section 5). Our patterns focus on robot movement as one of the major aspects considered in the robotics domain [46], [47], [48], as well as on how robots perform actions as they move within their environment. We define a pattern-based DSL that supports the usage of both the existing (functional) mission specification patterns from [35] and the quantitative patterns from our QUARTET catalog, and a translation that maps the constructs of the QUARTET DSL to Probabilistic Reward Computation Tree Logic (PRCTL) formulae. These PRCTL formulae precisely define the semantics of our QUARTET language, enabling its use with existing model checking and synthesis tools (Section 6). The pattern-based DSL extends the DSL proposed for the (non-quantitative) robotic specification patterns we introduced in [35], [36], [37]. We provide the QUARTET tool that supports the use of our pattern-based DSL, enabling engineers to (i) express complex behaviors involving quantitative concepts and (ii) directly interface with the widely used probabilistic symbolic model checker PRISM [49] (Section 7). We evaluate the coverage of the QUARTET pattern catalog (research question RQ1), the applicability of our translation (RQ2), and the exploitability of the logic formulae generated by our translation (RQ3). For RQ1, our results show that our quantitative patterns were able to fully express 20 out of the 21 (\raise.17ex$95%) mission requirements of the benchmark we considered and that each pattern was useful to express at least one requirement we collected from the literature. For RQ2, our results show that our translation was applicable for 15 out of the 20 mission requirements expressible using our DSL (75%). For RQ3, our results show that the mission specifications generated by our translation can be used for synthesis and model checking, and that, based on results from the literature, these activities can be performed in practical time (Section 8). All of our artifacts are publicly available to allow for study replication [50]. The rest of the paper is structured as follows. Section 2 introduces a running example used to illustrate the QUARTET patterns throughout the paper. Section 3 presents preliminary background notions. Section 4 describes the hybrid methodology we used to identify mission specification problems, and the result of applying this methodology to collect requirements relevant for our work. Section 5 presents our catalog of quantitative patterns. Section 6 introduces the QUARTET DSL, which enables using and combining the 22 robotic mission specification patterns [35] and the new patterns from our QUARTET catalog. Section 7 addresses implementation specifics. Section 8 evaluates our approach. Section 9 positions our work with respect to related approaches in the software engineering for robotics literature, and Section 10 concludes the paper with a brief summary and a discussion of future work directions.

RUNNING EXAMPLE
Our running example concerns a robotics company developing general-purpose mobile robots. After the production of the robots, the engineers can customize their behaviors by defining different types of missions the robots can perform. These missions are defined depending on customer needs. Since the company provides general-purpose robots deployed in customer facilities, customers frequently ask the robotic company to add, remove, or change robotic missions based on their specific needs. This customization can be performed either on-site or remotely after the deployment of the robots.
For our running example, the customer is an electronics store that purchased two robots (rob1 and rob2) and deployed them in their store. The store is organized in three areas: the computer-phone (CP), the tv-audio (TA), and the household appliance (HA) areas. The robots have to perform the following mission: Example 1. "After closure, the robots shall clean the electronics store. After cleaning, they shall visit a set of predefined store locations, each at least once, to record the items present on shelves after closure. The robots must minimize the time required to perform this activity. The robots should also patrol the store for security purposes, following any intruder while raising an alarm. The robots should interleave cleaning and security patrolling so that intruders do not remain undetected while the robots are cleaning continually for long periods of time. The robots should monitor their battery, optimize its usage, and recharge when needed. They should avoid recharging simultaneously and leaving the store unmonitored." This task, or mission requirement, is a natural-language description of the activities that the robots have to perform [35]. Robotics engineers typically use a planner that computes the set of actions the robots should perform to accomplish a mission from a machine-processable description of that mission, i.e., from a mission specification. Therefore, software tools are required for (a) expressing mission requirements and (b) translating mission requirements into mission specifications.

PRELIMINARIES
This section summarizes the robotic mission specification patterns [35] (Section 3.1), that will be extended in this work to express mission requirements, and Probabilistic Reward Computation Tree Logic (PRCTL) [51] (Section 3.2), the logic that will be considered for expressing mission specifications.

Mission Specification Patterns
Robotic mission specification patterns [35] allow engineers to tackle the mission specification problem. A pattern maps a recurrent mission requirement (or parts of a mission requirement) to a template specification. For simplifying its usage, a pattern is associated with a description of the usage intent, known uses, and relationships to other patterns. Mission specification patterns are organized in a mission specification pattern catalog: a collection of patterns organized in a hierarchy aiding browsing and selecting patterns to support decision making during mission specification. Given a mission requirement, the 22 mission specification patterns [35] support the automatic generation of a mission specification. The mission specification is an unambiguous description of the mission requirement, often expressed in a logic-based or programming language that supports robotic planning.
The (non-quantitative) patterns defined in [35] and leveraged by our complementary quantitative QUARTET patterns are summarised in Table 1. The table contains the name of the mission specification problem that each pattern is solving and a natural language description of that problem. In addition, the table contains the constructs of the DSL that enable the usage of the patterns that are introduced by this work, and will be described in Section 6.1. The table is partitioned into three parts that respectively contain the Core Movement, Avoidance/Invariance, and Trigger patterns. Core movement patterns describe how robots should move within their environment. Avoidance/Invariance patterns capture constraints that can be added to avoid the occurrence of a specific behavior. Trigger patterns express a robot reactive behavior based on stimuli, or the robot's inaction until a stimulus occurs.

Probabilistic Reward Computation Tree
Logic (PRCTL) The target logic we consider in this work to express mission specifications is Probabilistic Reward Computation Tree Logic (PRCTL) [52]. PRCTL provides support for the specification of temporal properties that contain probability and rewards. Let AP be a set of atomic propositions and a 2 AP , J R !0 , n 2 N, p 2 ½0; 1, N N [ f1g, and E 2 f < ; > ; ; !g, the syntax of a PRCTL formula f is defined as follows:

HYBRID METHODOLOGY TO IDENTIFY QUANTITATIVE MISSION SPECIFICATION PATTERNS
This section presents the hybrid methodology employed in this work to identify quantitative mission specification patterns. The hybrid methodology combines the benefits of the bottom-up and top-down methodologies used in literature for defining patterns. The bottom-up methodology (e.g., [34], [35], [59], [60]) follows the intuition that patterns are solutions for recurrent problems within some specific domain. Therefore, it defines patterns by (i) performing a literature analysis to identifying recurrent mission specification problems, and (ii) formulating solutions for those problems. The top-down methodology (e.g., [61]) follows the intuition that experts can propose patterns by relying on their experience and use existing mission requirements to validate them.  [35] and Constructs of the DSL Addressing the Problem Therefore, it defines patterns by (i) proposing the patterns upfront, and (ii) using existing mission requirements to assess whether the proposed patterns are appropriate and useful in practice.
The bottom-up and top-down methodologies are complementary. The former exploits the data provided by the users, i.e., mission requirements collected from the literature, for the definition of the patterns, the latter defines patterns upfront and uses the data provided by the users (i.e., mission requirements) for assessing their applicability. Both solutions have pros and cons. Since patterns are defined by considering data, i.e., the mission requirements from the literature, the bottom-up methodology is more likely to lead to patterns that are applicable in practical scenarios. However, if the set of mission requirements is limited, the catalog of patterns will only support the specification of a narrow set of missions. The top-down process is more speculative since missions are defined based on experts' experience. This may lead to a larger set of patterns. However, some of these patterns may have limited applicability. Therefore, we use a hybrid methodology that exploits the benefits of both bottom-up and top-down methodologies (Fig. 1). This hybrid methodology combines the bottom-up (gray shadowed area) and the top-down (purple shadowed area) methodologies as follows: Collection of Mission Requirements. This activity uses the literature to collect the mission requirements that will be used to extract the patterns (according to the bottom-up methodology). Definition of Mission Specification Problems. This activity uses the mission requirements to extract the recurrent mission specification problems (according to the bottomup methodology). It also allows the upfront addition of mission specification problems that are likely to be relevant (according to the top-down methodology). Pattern Formulation. This activity requires the formulation of solutions, in terms of patterns, for the mission specification problems (according to both the top-down and the bottom-up methodologies). Analysis of Applicability. This activity requires the evaluation of the applicability of the patterns in practice (according to the top-down methodology). Steps , , and (collection of mission requirements, definition of mission specification problems, and pattern formulation) are described in the following.
Step , the analysis of applicability, is part of our evaluation (see Section 8). All data and artifacts produced in these steps can be found in our publicly available replication package [50].

Collection of Mission Requirements
Our mission requirements were collected as follows: We considered all papers published in the software engineering, robotics, and formal methods venues presented in Table 2 from 2014 to 2019. The list of venues includes a subset of the top software engineering, robotics, and formal methods venues. We subsequently adopted papers published in the software engineering, robotics, and formal methods venues in 2020 and 2021 for validation purposes (see Section 8.1). Each venue/year combination was assigned to one of three authors tasked with the collection of mission requirements, so that each of them handled a similar number of venue/year combinations. Authors selected papers satisfying the following criteria: The paper title contains a movement-related concern related to the robotic domain. For example, the papers "Reconfigurable Motion Planning and Control in Obstacle Cluttered Environments under Timed Temporal Tasks" [62] and "Dynamic Routing of Energy-aware Vehicles with Temporal Logic Constraints" [63] were selected since their titles contain movement-related concerns, respectively "reconfigurable motion planning" and "dynamic routing" of "Vehicles". The paper contains at least one formulation of a mission requirement involving a movement notion and additionally including a portion of the requirement related to one or more quantitative concerns (e.g., probability or time). Finally, authors extracted from the paper all natural language requirements involving movement notions and quantitative concerns.

Identification of Mission Specification Problems
We identified mission specification problems starting from the mission requirements as follows: We divided the collected mission requirements among three of the authors. Each mission requirement was labeled with two types of keywords: Keywords that describe the mission specification problems the robot has to achieve. Whenever a mission refers to one of the baseline mission specification patterns for robotic missions that are extended in this work, we use the name of the pattern as a keyword. Keywords describing the quantitative behavior associated with the pattern. We created a graph structure representing semantic relations between keywords. Each keyword is associated with a node of the graph structure. Two nodes were connected if their keywords identify two similar mission specification problems. Nodes that were connected through edges and contained keywords that identify the same mission specification problem were merged. We allowed each author to propose additional mission specification problems according to the topdown methodology. We finally organized the mission specification problems into a catalog represented through a graph structure that facilitates browsing the mission specification problems.

Pattern Formulation
To formulate our mission specification patterns, we analyzed each mission specification problem. For each, we formulated a mission specification pattern following established practices [34], [60], [61]. Specifically, we define a pattern by: a name that uniquely identifies the pattern; an intent that captures the purpose of the pattern, i.e., a description of the mission requirement related to the corresponding mission specification problem; a template instance that contains the mission specification associated with the pattern; variations describing possible minor changes that can be applied to the pattern; examples and known uses describing examples collected from the literature; relationships describing connections between different patterns, and occurrences describing usages of the pattern in the research literature. We defined the mission specification of the template instance by consulting the specifications presented in the papers we surveyed and by cross-checking them.
In the next section, we describe our quantitative mission specification patterns catalog.

QUANTITATIVE MISSION SPECIFICATION PATTERNS CATALOG
This section presents QUARTET, our catalog of quantitative mission specification patterns. First, we detail the recurrent quantitative mission specification problems addressed by our patterns (Section 5.1). Then, we describe our proposed quantitative mission specification patterns to solve these problems (Section 5.2).

Quantitative Mission Specification Problems
For each venue that contained at least one paper satisfying our selection criteria, Table 3 contains the number of mission requirements collected for each year between 2014 to 2019 following the methodology described in Section 4. The remaining seven venues from Table 2 contained no relevant papers. The mission requirements corresponding to the years of 2020 and 2021 are set aside to be later used for validation (see Section 8.1). An example of mission requirement collected is: "In an emergency scenario, robots shall guide the evacuees to the exit so that minimum time is spent to escape out of the indoor environment". This mission requirement was considered by Tang et al. [64] in a Transactions on Human-Machine Systems (HMS) paper from 2016. In total, we collected 51 natural-language mission requirements which involve quantitative measures on concerns related to robotic   NA in a cell indicates that an edition was not held/published on that year. Ã The remaining seven venues from Table 2 contained no relevant paper.
applications, such as energy consumption, the probability of succeeding or failing in accomplishing missions, and the time required for completing the missions. While these quantitative measures are significantly different from a mission requirement perspective, they share similarities from a specification perspective. For this reason, in the following, we do not treat such measures separately, but instead provide a set of patterns that can be applied to any of those quantitative measures.
The mission specification problems addressed by our mission specification patterns are summarized in the pattern catalogs illustrated in Figs. 2a and 2b. They present elementary and composite mission specification problems, respectively. Elementary mission specification problems capture fundamental quantitative measures directly sourced and identified from the mission specification phase. Composite mission specification problems express higher-order robotics concerns. Observe their compositional nature -composite problems are a form of syntactic sugar over elementary patterns, yielding higher-order constructs. Specifically, composite mission specification problems consider cases in which the quantitative measure represents specific robotic concerns, such as time and resources. While for these cases the elementary mission specification patterns still apply (e.g., the mission designer can use the pattern that will be proposed for the 'minimize' problem when the quantitative measure represents time), additional problems referring to specific needs were identified (e.g., the need to pause the robot for a given time). The leaves of the tree represent mission specification problems. The mission specification problems identified by following the bottom-up procedure are graphically indicated with a solid border, while the mission specification problems added by the authors according to the top-down procedure are graphically indicated with a dashed border. We added mission specification problems that are strictly related to other problems covered by the patterns in the catalog. For example, we have added the mission specification problem "Less than" that is the dual of the mission specification problem "At least". The intermediate nodes facilitate browsing within the hierarchy and aid pattern selection and decision making. We summarize our mission specification problems in the following. Table 4 provides a sample mission requirement for each mission specification problem identified by following the bottom-up procedure and provides the reference of the paper from which the requirement has been extracted.

Elementary Mission Specification Problems
The elementary mission specification problems are depicted in Fig. 2a and described in the following. The elementary mission specification problems are grouped into three categories: Objective, Bounds, and Intervals. The Objective category contains problems concerning the achievement of a goal. The Bounds category contains problems requiring the value of the quantitative measure to remain below or above certain thresholds. The Intervals category contains problems requiring the quantitative measure to be within certain intervals. The top part of Table 5 (column "Description") contains a description of the respective elementary problem.

Composite Mission Specification Problems
The composite mission specification problems are depicted in Fig. 2b and described in the following. Composite patterns are grouped into four categories: Time, Performance & Dependability, Space, and Resource. The Time category contains problems where the quantitative measure reflects time-related requirements. The Performance & Dependability category contains problems where the quantitative measure refers to probabilistic, reliability or performance aspects of the missions. The Space category contains problems where the quantitative measure represents spatial concerns within missions. The Resource category contains problems where the quantitative measure represents some resource involved. The bottom part of Table 5 (column "Description") contains a description of each composite problem.
The solution to each of these recurrent mission specification problems is provided by a quantitative mission specification pattern. Our quantitative mission specification patterns are detailed in the following section.

Quantitative Mission Specification Patterns
This section presents the QUARTET catalog. Each mission specification pattern addresses a mission specification problem; for example, the pattern addressing the Maximize problem is reported in Fig. 3. The pattern contains a description of the intent ("the robotic application shall maximize the value of the quantitative measure m while performing a mission"), template specifications, variations of the pattern, examples and known uses, relationships with other patterns, and occurrences of the pattern in the literature. Examples and known uses provide exemplar usage scenarios and describe the applications of the patterns in the broad sense. Differently, occurrences provide references to works from the research literature using the patterns. Typically, occurrences contain references to works that led to pattern identification. Notice that for each pattern, alternative specifications can be provided depending on whether the quantitative measure represents time, probability, reward, or other quantitative measures. In Fig. 3, two template specifications Ã Our interpretation of this requirement is that "the rover shall travel at least a minimum distance".  [52] are reported. The first concerns the case in which the quantitative measure represents the probability of achieving a certain mission: the PRCTL specification scopes the PRCTL formula s encoding the robotic mission with the PRCTL operator P max¼? requiring the probability to be maximized while ensuring the satisfaction of the formula s. The second concerns the case in which the quantitative measure represents the reward collected while performing a certain mission: the PRCTL specification scopes the PRCTL formula s encoding the robotic mission with the PRCTL operator E max¼? requiring the reward to be maximized while ensuring the satisfaction of the PRCTL formula s.
A logic that provides constructs capable of expressing the mission specification of all the QUARTET patterns does not exist: neither a target logic supporting "generic" quantitative measures nor a comprehensive logic supporting (explicit) time, space, probability, and rewards is available in the literature. Therefore, we opted for selecting an interpretation for the quantitative measures and one of the logic languages proposed in the literature supporting that interpretation. Notice that the proposed patterns can be extended in the future when more expressive logics become available and that additional mission specifications targeting other languages can be proposed depending on users' needs.
In this work, we considered probability and rewards as quantitative measures interpretations. For this reason, we selected PRCTL [52] (see Section 3.2) as the target logic since it provides support for the specification of temporal properties that contain probability and rewards. We used PRCTL for expressing the mission specifications of all the patterns of the QUARTET catalog except the patterns belonging to the Space category and the Proportionality pattern since we were unable to specify these patterns in PRCTL. For the patterns of the Space category, we use a logic proposed by Wolter and Zakharyaschev [77] that enables reasoning about numerical distances. For the Proportionality pattern we used the Hybrid Logic of Signals (HLS) [78], a logic-based language that enables the specification of complex CPS timerelated requirements. Specifically, the equidistance pattern was defined in the logic proposed by Wolter and Zakharyaschev by exploiting the binary distance operator d and by forcing the distance between the robot rob and rob 1 and the robot rob and rob 2 to be equal to the value v. We forced this formula to hold during the execution of the mission miss. The trail pattern was defined by a formula forcing the distance between the robot rob and the object o to be equal to the value v and by requiring the formula to hold during the execution of the mission miss. The proportionality pattern was defined in HLS by using (a) two signal variables m 1 and m 2 indicating that the missions miss 1 and miss 2 are accomplished, (b) two existential operators that check for the presence of two timestamps t 1 and t 2 at which missions miss 1 and miss 2 are accomplished, and (c) a constraint requiring the proportionality relation between t 1 and t 2 by a factor v. All the patterns of the QUARTET catalog are available online [50].

PATTERN-BASED DSL
This section presents QUARTET, a DSL that enables using and combining the previously introduced 22 robotic mission specification patterns [35] and the QUARTET catalog. We present the syntax of our DSL (Section 6.1) and its semantics (Section 6.2). The terminals of the language are loc, rob, condition, act, m, and v. The terminal loc represents a location: either a logical location, e.g., a room of the building, or a physical location, e.g., position x; y; z. The terminal rob indicates a robot. The terminal condition represents a Boolean condition that is true or false. The terminals act, act 1 , act 2 , ..., act n indicate actions. The terminal m represents a quantitative measure. The terminals v, v 1 ,v 2 are values.

Syntax of the DSL
A robotic mission can be specified as the conjunction of two missions (miss and miss), disjunction of two missions (miss or miss), negation of a mission (not miss), a nonquantitative pattern describing the task to be executed by a robot (rob shall pat), an elementary quantitative pattern (e_qpat), or a composite quantitative pattern (c_qpat).
The usage of the non-quantitative robotic mission specification patterns that QUARTET builds on (introduced in Section 3.1) is enabled by the term pat. Each alternative in the rule of the term pat enables the use of one of the elementary patterns. The construct associated with each of the 22 non-quantitative robotic mission specification patterns from Table 1 is reported in the DSL column in the table.
Usage of the elementary and composite patterns of the QUARTET catalog is enabled by the terms e_qpat and c_qpat. Each alternative in the rule of the term e_qpat enables using one of the elementary patterns. Each alternative in the rule of the term c_qpat enables using one of the composite patterns. The construct associated to each mission specification problem is reported in Table 5 (column  DSL).
Example 2. Referring to our running example, let us consider for space economy reasons the following portion of where m1: defines the robotic mission, close is an event indicating that the shop closure time is reached, record is an action that records the content of the shelves in a given area of the shop. We made the complete formalization of the requirement of the Example 1 available online [50].
A robotic mission (R), expressed using the DLS specified in Fig. 4, is automatically translated into a mission specification using a translation function (t) that compiles a robotic mission (R) into a mission specification (S) and defines its semantics.

Semantics of the DSL
This section defines the semantics of our DSL by proposing a translation that maps the constructs of the DSL that refer to patterns from the QUARTET catalog into PRCTL formulae. The interested reader can find the semantics of the constructs of the DSL that refer to the 22 non-quantitative robotic mission specification patterns from Table 1 in [35]. We do not report the semantics of the DSL constructs corresponding to the patterns belonging to the Space category and the Proportionality pattern since we were unable to specify these patterns in PRCTL (see Section 5.2). The specifications for these DSL constructs corresponding to these patterns obtained by using the logic proposed by Wolter and Zakharyaschev [77], and HLS [78] are available online [50]. The table is divided into three parts containing respectively the semantics of the mission, elementary patterns, and composite patterns constructs. The translation t defines the conversion of each operator from our language into PRCTL. For example, the PRCTL formula obtained by applying the mapping function t to the formula miss and miss is the formula tðmissÞ^tðmissÞ, i.e., the conjunction of the PRCTL formulae obtained by applying the translation t to the left and the right operands of the and operator.
For mission constructs, the definition of the translation t specifies how to convert the Boolean operators that define the mission into the corresponding PRCTL operators. For the construct rob shall pat, the PRCTL formula generated by the translation (tðpat½r robÞ) is obtained by applying the translation to the term pat and by associating the value of the term rob to the variable r, that will be later defined, during the translation.
For elementary patterns, the definition of the translation t defined in Fig. 5 behaves differently depending on whether the quantitative measure refers to probability or rewards. For probability, the translation of the minimum and maximum constructs relies on the PRCTL operators P min¼? and P max¼? , respectively. For the other operators, the translation of the DSL constructs uses the PRCTL operator P E p by setting the value for the operator E to f < ; > ; ; !g depending on the operator to be translated. For rewards, for the minimum and maximum constructs, the translation relies on the PRCTL operators E min¼? and E max¼? . For rewards, the translation of the DSL constructs uses the PRCTL operator E J ðfÞ by setting the interval J to ½0; v, ½0; vÞ, ½v; 1Þ or ðv; 1Þ depending on the operator to be translated.
For composite patterns, we consider reward and probabilities as metrics to define the patterns that belong to the resource and performance and dependability categories. The translation for the Conservation pattern relies on the operator E min¼? that calculates the minimum reward. The translation for the Preservation pattern relies on the operator E J and keeps the reward within the interval ½v 1 ; v 2 . The translation for the Pause pattern specifies that the mission is not executed (i.e., ð:missÞ holds) within the interval ½0; v (i.e., G ½0;v tð:missÞ holds) and its execution re-starts at time instant ½v þ 1; v þ 1 (i.e., F ½vþ1;vþ1 ðtðmissÞÞÞ holds). The translation for the Timeout pattern specifies that the mission is not executed (i.e., ð:missÞ holds) within the interval ½v; 1 (i.e., G ½v;1 ð:tðmissÞÞ holds). The translation for the Repeat pattern specifies that the formula tðmissÞ holds initially, and globally if the mission miss holds (i.e., tðmissÞ holds), it will not hold for the next v À 1 time instants (i.e., G ½1;vÀ1 ð:tðmissÞÞ holds), and it will hold again at time instant v (i.e., F ½v;v ðtðmissÞÞ holds). The translation for the End pattern specifies that the mission miss is in execution until the time instant v (i.e., G ½0;vÞ ðtðmissÞÞ holds), and its execution stops at time v (i.e.,G ½v;1 ð:tðmissÞÞ holds). We do not provide a translation for the Proportionality pattern since there is no construct in PRCTL that enables the specification of proportionality between time instants. The translation for the Simultaneously pattern specifies that eventually all the actions are performed at the same time instant. Notice that the translation proposed for the patterns belonging to the "Time" category does not follow the PRCTL syntax (i.e., the temporal formula is not preceded by the P E p operator). Therefore, to ensure that our translation generates formulae within the PRCTL syntax, we constrain the patterns belonging to the "Time" category to be used within elementary patterns translated using the rules proposed for the probability metric previously presented. The translation for the Accrue pattern relies on the operator E max¼? that enables maximizing reward measure while performing the mission miss. The translation for the Reliability pattern relies on the operator E J where the interval J is set to ðv; 1Þ or ½0; vÞ depending on whether the greater or less than construct is used. The translation for the Confidently pattern relies on the operator L E p where E is set to " > " or " < " depending on whether the greater or less than construct is used. We do not provide a translation in PRCTL for the patterns that belong to the Space category since PRCTL does not explicitly support the specification of space properties.

IMPLEMENTATION
This section presents our proof-of-concept QUARTET tool, which supports the usage of the quantitative robotic mission specification patterns introduced in this paper. The tool is publicly available online [50] as an Eclipse plugin.
QUARTET provides a graphical user interface (GUI) that allows engineers to define mission requirements using the DSL presented in Fig. 4. The GUI is developed using Xtext [79], a software framework for developing DSLs. A screenshot of QUARTET containing the mission requirement m1 from Example 2 is reported in the top part of Fig. 6, alongside two more missions, m2 and m3. These quantitative and qualitative formulae, respectively, are derived from mission requirement m1, and are later translated into the property specification language of the probabilistic model checker PRISM.
QUARTET automatically translates mission requirements into PRCTL properties according to the translation reported in Fig. 5. The translation is implemented in Xtend [80], a general-purpose programming language based on Java and commonly used with Xtext [79]. We selected the property specification language of PRISM [81] as a mission specification language. Our choice was made for three different reasons. First, the only publicly available tool supporting the entire PRCTL logic we found is the Markov Reward Model Checker (MRMC) [82] publicly available online [83]. However, we decided to not consider MRMC since, differently than PRISM, MRMC is not currently maintained nor largely used by the academic/industrial community: the last update was made in 2011 [84]. Second, the property specification language of PRISM provides increased expressiveness compared to other existing logics: it subsumes several probabilistic logics, including PCTL [51], CSL [85], probabilistic LTL [86], and PCTL* [87]. Therefore, while not being able to express all the formulae of the PRCTL logic, our conjecture is that many of our requirements could be expressed using the property specification language of PRISM. The validity of our conjecture is assessed by our evaluation (see Section 8.2). Third, the property specification language of PRISM is used by many other tools, such as EvoChecker [88], [89], a searchbased approach that employs evolutionary algorithms to automate model synthesis. Therefore, the mission specifications generated by QUARTET can be fed into various model checking and synthesis tools.
To ensure that our tool generates mission specifications expressed in the property specification language of PRISM, we constrained the DSL in Fig. 4 to (a) prohibit nested probabilities, (b) accept only LTL properties for the reward and probability operators, and (c) prohibit the definition of specifications that lead to the conjunction of quantitative and non-quantitative PRISM formulae since such formulae can not be processed by PRISM. The first constraint forbids the creation of formulae that nest probabilities operators, such as the formula P max¼? ðP min¼? sÞ that is nesting the operator P min¼? within P max¼? . The second constraint forces the formulae used within the reward and probability operators to be LTL formulae, such as f 1 Uf 2 , i.e., it does not enable the exploitation of the values assumed by J and N within formulae of the form f 1 U N J f 2 . Finally, the third constraint forbids the definition of formulae of type f 1^f2 where one of f 1 and f 2 uses probabilistic operators and the other does not. For example, the formula f 1 Uf 2^Pmax¼? f 3 Uf 4 , which can be generated by our translation, is not supported by PRISM.
If these constraints are not satisfied, QUARTET generates a warning indicating that the mission specification in the property specification language of PRISM cannot be generated. If the constraints are satisfied, QUARTET outputs the mission specification in the property specification language of PRISM. The mission specification generated by QUAR-TET for the portion of the mission requirement of Example 2 (m1), and its derived missions (m2, m3) is reported in the bottom part of Fig. 6. For mission m1, our tool generates a warning since constraint (c) is violated: the translation leads to a conjunction of a quantitative and a non-quantitative PRISM formula. Such formulae can not be processed by PRISM.

EVALUATION
This section assesses our quantitative robotic mission specification patterns by considering the following research questions: RQ1 (Coverage of the patterns). What is the coverage of the QUARTET patterns? (Section 8.1) RQ2 (Applicability of the translation). In how many cases can the translation be applied? (Section 8.2) RQ3 (Exploitability of the mission specification). How can the mission specification generated by the translation be used in practice? (Section 8.3) RQ1 assesses the coverage of our patterns (see Section 5) according to our hybrid methodology and as mandated by the top-down methodology (see Section 4). Our patterns are designed to cover recurrent robotic mission specification problems. Therefore, they are not exhaustive. Given a set of mission requirements, RQ1 verifies whether our patterns can express these requirements.
RQ2 assesses the applicability of our translation method in practice (see Section 5.2). Since our translation considered probability and rewards as quantitative measures interpretations and PRCTL as target logic, it does not support some of the DSL constructs (see constructs labeled 'NA' in Table 5). In addition, due to the limitations of the property specification language of PRISM, we added a set of constraints (see Section 7) to ensure that our mission specification is within the PRISM input language. RQ2 assesses how these factors limit the applicability of our translation in practical cases.
RQ3 assesses the usefulness of our mission specification in practical scenarios. The mission specification generated by our translation (e.g., the PRCTL formula) supports automated reasoning (e.g., as an input for model checking and synthesis tools). All relevant material, data, and results of our evaluation are publicly available [50].

RQ1 -Coverage of the Patterns
To assess the coverage of our mission specification patterns, we first collected a set of mission requirements from the literature, and then we assessed whether our patterns enabled expressing these requirements.
Dataset. We considered a benchmark of 21 requirements (see the Validation column of Table 2) collected from the years 2020 and 2021 by following the same methodology used to define the QUARTET patterns (see Section 4.1). We followed a train-test split approach, popular in evaluation of machine learning and data science research, by considering collection of six years of requirements for the bottom-up pattern formulation, and subsequently evaluating coverage against requirements collected the last two years.
Methodology. We considered each of the 21 mission requirements of the dataset and proceeded as follows. Three of the authors analyzed each of the mission requirements and attempted to use the DSL in Fig. 4 to express it. If it was possible to formulate it using the constructs provided by the DSL, the patterns were deemed sufficiently expressive to capture the mission requirement. If it was not possible to completely express the mission requirement using the constructs provided by our DSL, we identified the portion of the requirement that could not be expressed.
Results. The QUARTET patterns were able to completely express 20 out of the 21 requirements (\raise.17ex$95%), and to partially express 1 requirement (\raise.17ex$5%). This coverage is acceptable for practical applications since the patterns are (by definition) not intended to be exhaustive. Therefore, these mission requirements were formalised using our DSL. The requirement we could not express prescribed the robot to "adapt the velocity profile of the robot, according to the wireless channel measurements" [90]. This requirement relates the values of two measures: "velocity" and "wireless channel measure". However, each pattern captures a mission specification problem related to one quantitative measure. Extending our pattern catalog to support mission specification problems that relate two quantitative measures is one of our future work directions (see Section 10).
Recall that to express one mission requirement, the DSL allows more than one pattern to be used. The number of times each of our patterns was used to express a (part of) a mission requirement from our dataset is reported in Table 6. The results show that to express these mission requirements, we used 14 patterns out of the 22 mission specification patterns in our catalog (\raise.17ex$64%). The patterns Pause, End, Confidently, Equidistance, Trail, Proportionally were not used to specify any of the requirements of the benchmark (demonstrating over-coverage of the patterns catalog). This result is not surprising since we only collected instances of mission requirements occurring in papers published in the two years considered. It is worth noting that patterns introduced via the bottom-up procedure have been defined according to mission requirements that have been found in literature, as shown in Table 4. So, the fact that we have not found additional instances may imply that these patterns are less popular than, for instance, Minimize, which has the highest occurrence.
The patterns defined through the top-down procedure (depicted with dashed borders in Fig. 1) require special attention since they are based on a hypothesis and are not sourced from examples collected from the literature. The results in Table 6 show that the QUARTET patterns Less than and Greater than were not used to specify any of the mission requirements. Therefore, to confirm the usefulness of these patterns, we performed a dedicated search for mission requirements that require these patterns for being specified. The purpose of our ad-hoc search was to confirm patterns' usefulness -we were searching for mission requirements that required specified patterns. To this end, we used snowballing techniques and queried search engines, such as Google Scholar, with search strings that were pattern specific. Our procedure is sound: if we found a mission requirement that required the pattern, then the pattern was useful to specify at least one mission requirement. Table 7 provides a portion of an example mission requirement from the literature for each of these patterns. The complete natural language description of the mission requirements is available online [50].
The answer to RQ1 is that our quantitative patterns were able to fully express 20 out of the 21 mission requirements of the benchmark ($95%), while 1 ($5%), partially. To do so, 14 ($64%) out of 22 patterns of the catalog were employed. Additionally, for each pattern identified and defined through a top-down procedure, we were able to locate examples in the literature, indicating its usefulness and appropriateness.

RQ2 -Applicability of the Translation
To evaluate the applicability of our translation, we considered the requirements defined for RQ1 and verified the number of cases on which our translation (Table 5) could be applied. Our goal is to evaluate how the applicability of our translation in practical cases is influenced by the lack of support for some of the DSL constructs (NA labeled entries in Table 5) and the constraints added to ensure that our mission specification is within the PRISM specification language (see Section 7). Dataset. We considered the benchmark of 20 mission requirements from RQ1 that were expressible in our DSL. This dataset contains 14 patterns out of the 22 mission specification patterns of our catalog (see Table 6).
Methodology. We considered each of the 20 mission requirements of our dataset. We applied our translation by running the automated support provided by QUARTET. We recorded whether the translation was applicable or not. When the translation was applicable, we stored the mission specification generated by QUARTET.
Results. Our translation was applicable for 15 out of the 20 mission requirements expressible using our DSL (75%). For the 5 remaining cases, the lack of support for some of the DSL constructs (which are labeled 'NA' in Table 5) prevents the application of the translation. Among the 15 cases for which our translation was applicable, in seven cases our translation lead to a warning, since the constraints added to ensure that our mission specification is within the PRISM specification language (Section 7) were not respected. In these cases, the PRISM tool does not support the PRCTL formulae generated by our translation. In the other cases, our translation produced a mission specification that could be processed by PRISM.
Our results show that our translation provides reasonably large applicability: it was applicable to 75% of our requirements. When our translation was applicable, in more than 50% of the cases, the mission requirements could also be processed by PRISM. Notice that our applicability will increase over time as (a) more expressive logics are defined by the research community, and (b) efficient tools that support more complex logic formulae are proposed.
The answer to RQ2 is that our translation was applicable for 15 out of the 20 mission requirements expressible using our DSL (75%). When our translation was applicable, PRISM could process the mission specifications generated by our translation in a reasonably large number of cases (more than 50%).

RQ3 -Exploitability of the Mission Specification
This question aims to assess the exploitability of the (PRISM) mission specifications generated by QUARTET, i.e., to assess how researchers and engineers can use these specifications. To assess the exploitability of mission specifications (e.g., for synthesis or model checking) one would need to assume some type of underlying model, e.g., discrete-time Markov reward models, used as input for synthesis or model checking. However, manually devising models would introduce significant threats to the validity of our results. For this reason, we opted for collecting mission requirements from the literature that were accompanied with a PRISM specification already proposed by the respective authors. Then, we analyzed the mission requirements considered by the authors, and we checked if the mission requirements could be expressed using our DSL. If the mission requirement was expressible using our DSL, we used our DSL to model the mission requirement. We verified whether QUARTET generated the PRISM mission specification defined by the authors. If this was the case, we considered the results reported in the publication and discuss how the specification was exploited by the authors for automated reasoning (e.g., model checking or synthesis). Dataset. Our dataset consists of 16 requirements. Out of these 16 requirements, 2 are robotic requirements collected from the PRISM Case Studies webpage [95], and 14 were collected by the authors using search engines. Specifically, we searched for publications containing both the mission requirements and the corresponding PRISM specifications that were exploiting them (for any purpose). Requirements from RQ1 could not be reused, since PRISM specifications were not included in the corresponding publications. Methodology. We considered each of the 16 mission requirements of our dataset. First, we checked if we were able to express the requirement using our DSL. If this was the case, we modeled the mission requirement using our DSL. We used QUARTET to automatically generate the mission specification. We checked whether the mission specification matched the one considered by the authors of the paper. Specifically, we checked whether the specifications entail the same functional behavior by manually analyzing and comparing the semantics of the specifications. If this was the case, we extracted from the publication the objective for which the mission specification was used (e.g., synthesis or model checking) and we analyzed the results obtained by the authors using the automated support provided by PRISM. We discussed how the specification was exploited for automated reasoning.
Results. All the requirements of our case studies were expressible using our DSL. The mission requirements, the DSL formulations and the mission specifications are publicly available [50]. The mission specifications obtained using QUARTET matched the ones reported by the authors within their papers. In 25% of the cases (4 out of 16) the specifications were used for model checking tools, in 75% of the cases (12 out of 16) the specifications were used for synthesis. The mean model checking and synthesis times reported in the publications using these specifications are 222s and 1688s, respectively. This shows that the mission specifications produced by QUARTET could be exploited effectively.
The answer to RQ3 is that the specifications generated from 16 mission requirements can be used for synthesis and model checking. Based on the publications surveyed, these activities can also be performed in reasonable time: the average of the maximum times required to perform model checking and synthesis were respectively 222s and 1688s.

Discussion and Threats to Validity
The proposed quantitative patterns were able to express \raise.17ex$95% of the 21 requirements of the benchmark dataset (Section 8.1). This is an extensive coverage for practical applications since patterns are (by definition) not meant to be exhaustive: they target recurrent mission specification problems. Additionally, new specification problems and patterns may be defined and the catalog can be extended over time. Observe that elementary constructs express fundamental concerns within quantitative specification, as well as their encoding in typical languages. Composite patterns are intended to bring specifications closer to the robotics domain at hand. The number of mission requirements analyzed is in line with other approaches in the field [34], [37], [59], [60]; however, we acknowledge the possible presence of bias in requirements collection since humans were involved in this (non-automated) process. We counter this by making our dataset available to serve as a reproduction kit [50].
Formal mission specification is a difficult and errorprone process [27], and facilities that enable mission designers to employ high-level reasoning -instead of low-level but precise specifications -are highly desired. A recent study [96] provided empirical evidence that pattern-based languages, such as the DSL proposed in this work, are easier to understand than logic-based languages. Such is the rationale of the composite patterns: a designer can utilize composite patterns for specification, while enjoying the benefits of their precise and unambiguous formal specification under the hood. Translation of composite pattern DSL formulations to low-level specifications in formal languages allows the use of planners and automated engineering techniques such as code generation or software synthesis, while avoiding ambiguities that might exist in informal representations, since the semantics of composite patterns are precisely defined. If some application demands it, coverage can be extended by specifying additional application-specific patterns over the elementary ones.
Our translation was applicable for the 75% of the mission requirements expressible using the DSL (see Section 8.2). For the five cases in which the translation was not applicable, the hindrance was the limited expressiveness of PRCTL that did not enable us to propose a translation for some of the constructs of our DSL (entries labeled 'NA' in Table 5). When our translation was applicable, PRISM could process the mission specifications in more than 50% of the cases. This problem is caused by the current limitations of PRISM, which does not support the full PRCTL logic, thus forcing us to introduce syntactic constraints for definition of the mission requirements. We believe such problems will be addressed over time: our translation will be extended as more expressive logics -and tools with more expressive input languages -become available. Finally, we note that in the present work we provided translations only in PRCTL. Other translations that target other logics may be developed as well. We showed that the mission specifications generated from 16 mission requirements can be used for synthesis and model checking (see Section 8.3) and that based on the publications surveyed, these activities can be performed in reasonable, practical time. We acknowledge that additional uses of the mission specifications generated by QUARTET are possible, and that the list we presented in Section 8.3 is not exhaustive.
Our patterns do not currently support multi-robots, robotic arm tasks, and swarms of robots. However, they can be used as building blocks for DSLs tailored to the specification of these types of missions.
An empirical investigation should be performed to assess in an end-to-end manner whether the approach helps in practice robotics engineers -as target users of QUARTETin specifying and reasoning about their quantitative mission requirements, and whether the concepts it implements are captured in language constructs. Such an assessment should include not only the coverage of the DSL but also auxiliary aspects such as usability, providing valuable future extension directions.
QUARTET is integrated with PRISM, an existing model checker and synthesis tool. PRISM can process the mission specifications produced by QUARTET. It can use the mission specifications for model checking, i.e., the mission specifications produced by QUARTET are properties that can be verified on a system model. PRISM can also use the mission specifications for synthesis via PRISM-games [97]. PRISM-games extends PRISM by supporting the synthesis of stochastic multi-player games representing competitive and collaborative behaviors. Specifically, PRISM-games synthesizes optimal player strategies which ensure that a property holds. The mission specifications produced by QUARTET can be considered as properties that the synthesized component has to ensure. Finally, our translation (Section 6.2) can be extended to support the languages of other synthesis tools, such as Uppaal Stratego [98].
In certain mission-critical domains, robots may not be able to accomplish the full-fledged mission. A typical scenario specifies one or multiple degraded versions of the mission. In some scenarios, the robot may need to change its configuration to continue a mission or a behavior. These reactive behaviors can be specified by using the "Trigger patterns" specified in Table 1. These patterns, which express a robot reactive behavior based on stimuli, or a robot's inaction until a stimulus occurs, are presented in our previous work [35].
Threats to Validity. The selection of the venues from which the mission requirements were collected is subject to a selection bias that may impact the external validity of our results as it influences their generalizability to applications not covered in these venues. The selection of the mission requirements used for answering our research questions is also a threat to external validity since it influences the extent to which our results can be generalized. Specifically, in this work, we considered mission requirements involving movement-related concerns (see Section 4.1) since specifying robotic movement is a critical aspect for robotic mission specification. To mitigate this threat, we collected requirements by considering both robotic mission requirements codesigned with robotic application stakeholders (including researchers, developers, operators, and end-users) and papers (from diverse authors) from different venues (software engineering, robotics, and formal methods). Empirical studies will consider over time larger and more diverse sets of requirements as done with property specification patterns for temporal properties [96].

RELATED WORK
This section presents related work that supports engineers in expressing system requirements and generating specifications by either defining patterns or by proposing Domain Specific Languages (DSL) for the robotic domain.
Pattern Definition. Specification patterns to support engineers in writing logic-based formulae are present in the research literature. Dwyer et al. [34] defined specification patterns for LTL formulae. Konrad and Cheng [59] defined patterns that consider real-time properties. Grunske et al. [60] defined patterns that considered probabilistic properties. Autili et al. [61] combined and extended the previous catalogs patterns. While these patterns target generic logicbased formulae they are not tailored for the robotic domain.
Specification patterns were applied in a large variety of domains, such as security [99] and safety [100], servicebased applications [101], decentralized systems [102], cyberphysical systems [103], [104], and Machine Learning (ML) [105]. Specification patterns were also largely applied in the robotic domain. For example, patterns were proposed for supporting the development of code for robotic software components [106], predicting human activities in humanrobot collaborative assembly tasks [107], exploring and prototyping human-robot interactions (e.g., [108], [109], [110]). However, these patterns do not target generic robotic missions. In an earlier work [36], [37], three of the authors of this paper proposed a set of robotic mission specification patterns. However, these patterns do not enable the specification of the quantitative aspects of the robotic mission.
DSLs for the robotic domain. There is a large variety of DSLs for the robotic domain. The interested reader can refer to existing surveys from the literature (e.g., [15], [111], [112], [113], [114], [115]). Most of the existing DSLs are procedural (or imperative using the terminology in [15]), and therefore require their users to model explicitly the control flow of the robot [15]. Instead, a declarative specification of the mission is more convenient since the control flow is implicit and the users just need to model the goal of the mission. This is the case of specification languages that have been built on top of some temporal logic. In these languages, the specification of the goal of the mission is then given as input, e.g. to a logic-based planner, which then computes automatically the control flow of the robot. The drawback of logic-based languages is their usability and limited user-friendliness. Specification patterns contribute to solving this problem. They typically offer a structured English grammar enabling the natural-language-like formulation of mission requirements. The need for supporting engineers in writing natural-language-like mission requirements and automatically generating mission specifications is also highlighted in the recent survey by Dragule et al. [15]. An interesting DSL that combines the procedural and declarative style is Promise [21], [45]. This language builds on top of our previous mission specification patterns [35], [36], [37]. The patterns are the main building blocks of the language, and the DSL introduces operators (fallback, alternatives, sequence, parallel, etc.) that enable the composition of patterns to build complex missions involving one or more robots. The DSL we propose in this paper builds on top of the DSL proposed in [35], [36], [37]. We anticipate that our catalog of patterns can be exploited to build DSLs that can further contribute to advancing the area of robotic mission specification. Examples of such DSLs include DSLs enabling the specification of mission for multirobots, DSLs conceived to enable verification, as will be discussed later, and DSLs focusing on specific application domains, such as agriculture or healthcare. Indeed, existing DSLs are specific to the service robotic domain, but there can be another step of specialization of the languages, towards application domains, as envisioned in [116]. Our patterns represent an important step towards the construction of this envisioned ecosystem of DSLs, by providing the main building blocks, with clear and welldefined semantics, on which to build. Moreover, the patterns are built on collected examples from literature, and therefore their expressiveness is anchored into the actual needs of users from this domain, as documented in their papers. Also, unlike existing DSLs, which are usually obtained starting from a target specification language (e.g., some logic language supported by a model checker), our patterns are language agnostic. New translations targeting other specification languages can be added in the future.
Finally, most of the DSLs proposed by the literature do not support the specification of quantitative aspects such as probability and rewards.
Patterns Usage. Patterns within robotics have been employed for communication, production and analysis of behavior descriptions, verification and synthesis. Efforts to provide support for mission specification have also focused on graphical tools that simplify the specification of temporal logic formulae [12], [13], [14], for which integration of pattern-based tools for robotics have also been proposed [36]. Finally, synthesis -generation of a correct-by-construction reactive system from a temporal logic specification [117], is highly relevant to robotics applications, for which patterns can be readily used -patterns previously devised by the authors have GR(1) options. GR(1) is a fragment of LTL with an efficient polynomial time synthesis algorithm. Cho et al. [118] relies on signal temporal logic to develop a control strategy synthesis method for dynamical robotic systems.

CONCLUSION
This paper presents QUARTET, a novel catalog of 22 specification patterns for the specification of quantitative robotic missions developed using a hybrid methodology that combines the benefits of bottom-up and top-down approaches. It further defines a pattern-based DSL to support the usage of both existing mission specification patterns and the QUARTET quantitative mission specification patterns. We proposed a translation that maps the constructs of the DSL into Probabilistic Reward Computation Tree Logic (PRCTL) formulae, precisely defining the semantics of the language and enabling the usage of existing model checking and synthesis tools. We developed a tool that supports the usage of our pattern-based DSL, enabling engineers to express complex behaviors involving quantitative concepts and directly interface with PRISM. We evaluated the coverage of the patterns of the QUARTET catalog, the applicability of our translation, and the exploitability of the logic formulae generated by our translation. Our results show that the coverage of our quantitative patterns supports the practical usage of our catalog, our translation is largely applicable, and that the mission specifications generated by our translation can be used for synthesis and model checking in practical applications. Finally, we make all of our artifacts publicly available to enable study replication [50].
In future work, we will extend our pattern catalog to further increase its coverage by supporting additional specification problems, such as relating two different quantitative measures (see Section 8.1). In addition, a promising avenue of future work entails proposing alternative specifications for the QUARTET patterns by considering other logics that can address the limitations of our translation (see NA fields of Table 5 and Section 8.2), such as ones with spatio-temporal features [119]. Finally, as has been done for specification patterns for temporal properties [96], empirical studies can assess the applicability of the mission specification patterns over additional case studies and benchmarks (see Section 8.3).
Christos Tsigkanos received the PhD degree from Politecnico di Milano (Italy), in 2017 and the Habilitation degree in 2022. He is senior researcher with the University of Bern and the Software Engineering Group. He is joining the University of Athens, Department of Aerospace as assistant professor. He was Lise Meitner fellow and previously postdoctoral researcher with TU Vienna (Austria) and with Politecnico di Milano. His research interests lie in the intersection of software and (software) systems engineering, and include aspects of dependable systems as well as applied formal methods.
Mehrnoosh Askarpour is an adjunct assistant professor with the Department of Computing and Software, McMaster University (Canada). Her current research interests include verification of safety-critical system properties and application of formal methods for safe robotics and autonomous vehicles.
Patrizio Pelliccione received the PhD degree in computer science from the University of L'Aquila (Italy). He is director of the Computer Science area and Professor in Software Engineering with Gran Sasso Science Institute (GSSI, Italy). His research topics are software engineering, software architecture modeling and verification, and autonomous systems. Thereafter, he worked as a senior researcher with the University of Luxembourg in Luxembourg, then assistant professor with the University of L'Aquila in Italy, and then associate professor with both Chalmers j University of Gothenburg in Sweden and University of L'Aquila. He has been on the organization and program committees for several top conferences and he is a reviewer for top journals in the software engineering domain. He is very active in European and National projects. In his research activity, he has collaborated with several companies. More information is available at http:// www.patriziopelliccione.com.
Gricel V azquez received the MSc degree in computational intelligence and robotics from the University of Sheffield with distinction. She is currently working toward the PhD degree in computer science with the University of York (UK). Her research interests include formal methods, multi-robot systems (MRS), task allocation and planning, domain-specific languages for MRS, autonomous systems ethical concerns, selfadaptive and critical systems.
Radu Calinescu is Professor of Computer Science with the University of York (UK). His main research interests are in formal methods for selfadaptive, autonomous, secure and dependable software, cyber-physical and AI systems, and in performance and reliability software engineering. He is an active promoter of formal methods at runtime as a way to improve the integrity and predictability of self-adaptive and autonomous systems and processes.
Sergio García received the PhD degree in software engineering from the University of Gothenburg (Sweden). He works as a software architect and function designer with Volvo Cars Corporation (Sweden). His research lies in the intersection between software engineering and service robotics with a special emphasis on empirical studies, software architecture, and domain-specific languages development.