Probabilistic modelling and verification using RoboChart and PRISM

RoboChart is a timed domain-specific language for robotics, distinctive in its support for automated verification by model checking and theorem proving. Since uncertainty is an essential part of robotic systems, we present here an extension to RoboChart to model uncertainty using probabilism. The extension enriches RoboChart state machines with probability through a new construct: probabilistic junctions as the source of transitions with a probability value. RoboChart has an accompanying tool, called RoboTool, for modelling and verification of functional and real-time behaviour. We present here also an automatic technique, implemented in RoboTool, to transform a RoboChart model into a PRISM model for verification. We have extended the property language of RoboTool so that probabilistic properties expressed in temporal logic can be written using controlled natural language.


Introduction
Autonomous robots must carry out their missions without human intervention. Uncertainty in real-world environments, including the physical robotic platform, presents major challenges for these robots. To address these challenges and deal with unknown aspects of the environment, robots often use probabilistic control algorithms. For example, a robot without a detailed map of its environment might resort to using a random walk to carry out its mission, overcoming the uncertainty about its position. This paper addresses modelling and Communicated by Jeff Gray.
formal verification of robotic controllers that use probabilistic algorithms to deal with uncertainty.
Robotic applications are often designed using state machines that have no formal semantics or even precise syntax. These machines can involve advanced features, including probability, real-time, and shared-variable concurrency. To model and analyse such complex systems, roboticists require knowledge of formal languages and probability theory. Our approach is to use a domain-specific notation, RoboChart [1], and model transformation to support probabilistic reasoning using a notation familiar to roboticists. Usability and automation are key considerations for RoboChart.
Previous work [2] presents the RoboChart, metamodel and semantics, and an Eclipse-based tool, RoboTool, for modelling, verification, and code generation using RoboChart. This paper covers its extension to cater for probabilistic modelling and verification: we have (1) extended RoboChart's state machines to enrich them with a construct for probabilistic choice (with our extension, RoboChart allows four forms of choice between behaviour: conditional, external or guarded by events, nondeterministic, and probabilistic), and (2) developed an automatic technique for verification by model checking using PRISM [3]. Our results are illustrated via several case studies.
The core of RoboChart is a subset of UML state machines that allows modelling of robotic applications, and has a con-strained semantics for automated reasoning. RoboChart can be regarded as a profile of UML, enriched with time constructs. In a RoboChart model, physical robots are abstracted into robotic platforms defined by variables, events, and operations. RoboChart also has a component model with notions of controller and module to foster reuse. A state machine is the basic element to model behaviour. A controller includes one or more parallel state machines. Communication between state machines in the same controller is synchronous, while communication between controllers can also be asynchronous. A module defines the boundaries of the robotic application and is composed of one robotic platform and one or more controllers.
RoboChart has a semantics for formal reasoning based on Hoare and He's Unifying Theories of Programming (UTP) [4], with the process algebra CSP [5][6][7], which has a UTP semantics [4,7], used as a front-end. RoboTool generates models written in CSP and tock-CSP [6,8], an encoding that uses an event tock to mark the passage of time, from RoboChart models [2] to enable use of the refinement model checker FDR [9,10] to verify properties, such as deadlock and livelock freedom. We can also verify specific behavioural properties, including time budgets and deadlines. We cannot, however, verify probabilistic properties.
Standard CSP and tock-CSP do not support probabilistic choice. An experimental extension of CSP included a probabilistic choice construct, and a specific version of FDR was developed to translate refinement checks in CSP to the PRISM language [3] through the WatchDog Transformation [11]. This approach, however, only supports CSP traces refinement reasoning [6] (so limited to reachability properties) and is not supported by recent FDR versions.
RoboChart also has support for semiautomated verification by theorem proving using Isabelle/UTP [12,13]. Both FDR and Isabelle/UTP verification target only proof of reactive and timed behaviours of RoboChart models, not probabilistic, as we do here.
RoboChart differs from the PRISM language in several aspects: abstraction level, data types, variable sharing, and event synchronisation. Our technique to generate PRISM scripts addresses all these issues. The technique is formalised by transformation rules that we present here, and automated in RoboTool.
A property language facilitates the writing of properties for verification in PRISM using a controlled natural language. It can express probabilistic properties that are based on temporal logic. This also improves performance, by enabling the running of multiple PRISM instances in parallel when several properties are stated.
In [2], we have described a CSP semantics for a version of RoboChart that supports standard features of statecharts and time constructs, but not probabilistic choice. In [14], we have studied the imperative, sequential action language for RoboChart, and explicated the weakest completion approach [15] to give UTP semantics to a nondeterministic probabilistic programming language. This work shows how informal proofs can be turned into formal proofs for implementation in Isabelle/UTP, which enables future application of theorem proving to verify RoboChart models. Here we cover most features of RoboChart, not only its imperative and sequential action language, and pursue support for model checking, not theorem proving.
A recent work by Conserva Filho et al. [16] interprets the probabilistic choice in RoboChart using the probabilistic CSP operator p 1− p [11]. This preserves semantics for all other constructors in RoboChart, because RoboChart's semantics is given in CSP. Verification uses refinement model checking: S T I . Here, S is the property to be verified and described by a nonprobabilistic CSP process, and I is a probabilistic CSP process under analysis, generated from a probabilistic model in RoboChart. An extended version of FDR supports probabilistic choice in CSP and translation of the refinement check to a PRISM model. Our work is different from that in [16] in several aspects. Verification in [16] covers only trace refinement and so is limited to reachability properties. Our work supports all the temporal logics in PRISM. CSP processes are used in [16] to specify properties. Consequently, users need to have knowledge of CSP. In contrast, in our work, we use a customised property language, RoboCert. Finally, their approach is only supported by one version of FDR and not by the more recent versions being used with RoboTool.
Our novel contributions here are as follows: (1) the introduction of a new construct for probabilistic choice in RoboChart's state machines for probabilistic modelling; (2) a metamodel for PRISM; (3) RoboChart's probabilistic semantics in PRISM (for a subset of RoboChart constructs), including not only the new probabilistic construct but state machines and the component model in a context where probabilities are captured; (4) the implementation of the semantics in RoboTool for automated generation of PRISM models; and (5) a property language for verification of qualitative and quantitative properties.
The remainder of this paper is organised as follows. We review related work in Sect. 2. Section 3 examines core features of RoboChart, introduces our new probabilistic choice construct through an internal mail delivery robot example, and presents extra well-formedness conditions. In Sect. 4, we describe the PRISM language and its semantics, and present a PRISM metamodel that we have developed for transformation. Section 5 formalises our technique to transform RoboChart into PRISM models, and illustrates it using the mail delivery robot. Section 6 describes how RoboTool supports probabilistic modelling and the application of the transformations to automatically generate PRISM models. The property language for probabilistic properties is described in Sect. 7. Finally, we conclude and discuss future work in Sect. 8.

Related work
In this section, we set RoboChart in context by discussing its relation to fundamental probabilistic frameworks or models in Sect. 2.1, notations for probabilistic modelling with rich expressions and high abstraction in Sect. 2.2, and modelbased domain-specific languages for robotics in Sect. 2.3.

Fundamental probabilistic frameworks
This section describes notations and formalisms that are at the same level of abstraction as PRISM, but at a different level of abstraction as RoboChart. Some of their features, however, have inspired the design of RoboChart as acknowledged below.
Segala and Lynch [17] introduce probabilistic automata as a specialised form of labelled transition system. A transition is labelled with probability values, so that they map a source state to probability distributions over (action, target state) pairs. Actions can be external, modelling interactions with the environment through events, or internal, modelling computation steps through internal events τ . If, in each probability distribution, the action is always the same for every target state, the probabilistic automaton is called simple. Two simple probabilistic automata can be composed in parallel; this is a kind of combination that is also available in RoboChart, via use of multiple machines and controllers in a model.
The probabilistic semantics of RoboChart that is embedded in PRISM, as presented later on, can be regarded as corresponding to a simple probabilistic automaton in that the actions in a probability distribution for every target state are the same. Transitions map states and actions to probability distributions over states. RoboChart also distinguishes nondeterministic choice and probabilistic choice. RoboChart, however, has more modelling constructs and is more expressive, when compared to probabilistic automata.
Hansson [18] presents an alternating model that distinguishes between nondeterministic and probabilistic choice. Either a nondeterministic choice or a probabilistic choice can be made in each state of this model, and the order of availability of these choices is strictly alternating between a nondeterministic and a probabilistic choice. For the target state of a transition originating from a nondeterministic state (that is the state where only a nondeterministic choice can be made), only a probabilistic choice can be made. Conversely, for the target state of a transition originating from a probabilistic state (that is the state where only a probabilistic choice can be made), only a nondeterministic choice can be made. RoboChart adopts the same alternation between nondeterministic and probabilistic choice, but the point where a probabilistic choice is made in RoboChart is not a state. Instead, a probabilistic choice is made within a transition originating from a nondeterministic state. RoboChart is similar to a simple probabilistic automaton in this aspect. The alternating model and the simple probabilistic automata model with respect to probabilistic bisimulation (strong bisimulation) [19] are isomorphic [20]: one model can be translated to another, and vice versa. Van Glabbeek et al.'s reactive model [21] partially corresponds to the simple probabilistic automaton model as it allows external nondeterministic choice between different actions (that is, multiple transitions with different external actions from the same state), but without internal nondeterministic choice involving the same actions. In RoboChart, on the contrary, we can model internal nondeterministic choice via transitions that have no trigger, or transitions from the same state with the same trigger.
A variety of Markov models are used for discrete probability modelling. Discrete-time Markov chains (DTMCs) [22,23], in which each state leads to a probabilistic choice directly, are purely probabilistic without nondeterminism. A DTMC is equivalent to a fully probabilistic automaton in discrete time.
Markov decision processes (MDPs) [24,25], which extend DTMCs, can be regarded as simple probabilistic automata without internal nondeterministic choices. From each state, an action is associated with a probability distribution. Transitions from the same state with the same actions are, therefore, not allowed. Similar to MDPs, RoboChart models exhibit both probabilistic and nondeterministic choice.
A variety of DTMCs and MDP-based languages have been designed to facilitate systems modelling and analysis. Additionally, labelling functions for states (called atomic propositions) and cost or reward functions for states and transitions are also introduced. The PRISM language, which is supported by the widely used probabilistic model checker PRISM and other model checking tools such as Storm [26], is one such language. It is based on reactive modules [27] and is a low-level guarded-command language.
MODEST [28,29], a modelling and analysis framework for stochastic hybrid systems, uses a comparatively higherlevel language that is inspired by process algebras. It is supported by the MODEST Toolset. 1 PRISM, Storm, and MODEST all support DTMC and MDP models for discrete probabilities.
These languages often are textual and support only basic types of variables: boolean, integer numbers, and real numbers. To use the tools, knowledge of underlying probability models, formal methods, and temporal logic is often required.
On the contrary, RoboChart is a diagrammatic notation, in line with current practice of developing robotic control software often using diagrammatic state machines [30][31][32][33]. RoboChart offers more facilities for abstraction. This includes a component model to define services of a platforms, and an architecture of controllers and parallel threads, and their connections. In addition, RoboChart offers a richer set of data types, including many mathematical data types such as relations and functions, in addition to basic data types, to facilitate reasoning. The comprehensive expression language of RoboChart is that of the Z notation (see the ISO Z Standard 2 ), albeit with a more roboticist-friendly syntax and a few syntactic-sugaring constructs. Table 1 shows a comparison between these probabilistic frameworks and RoboChart according to their support of nondeterministic choice and probabilistic choice, abstraction, and expressiveness. Those frameworks provide different mathematical accounts of probabilistic behaviour, and have a role similar to that of PRISM, rather than RoboChart, in our work.

Improved modelling languages
A probabilistic finite state machine (PFSM) [33] extends state machines with probability and real-time behaviour. It is used to describe the behaviour of an individual foraging robot in a swarm. Both simulation [33] and formal verification [34] are used to understand and analyse the behaviour of the controller. A PFSM guides the development of a simulation and a formal model, but only loose connections between the machine and the simulation or the model are claimed. RoboChart also extends state machines with probability and real-time behaviour, but it has a formal semantics that can be automatically generated for given models.
Probabilistic timed Behaviour Trees (ptBTs) [35] extend Behaviour Trees [36], a formal and graphical notation to construct a design out of a set of functional requirements in a stepwise and traceable way, with probabilistic behaviour. The meaning of a ptBT is given using probabilistic timed automata (PTAs) [37]. Verification of a ptBT model is realised through translation to a DTMC or MDP model, which is analysed using PRISM. Notations based on behaviour trees treat an individual functional requirement as a behaviour tree, and integrate all these trees into an integrated design behaviour tree that allows defect detection and is traceable to the requirements. Compared to the notations based on state machines, those based on behaviour trees are not well developed and studied. One reason is the lack of sophisticated tool support.
Among the modelling notations extended to accommodate probability, UML state machines [38] are the most popular. DAMRTS (Dependability Analysis Models for Real-Time Systems) [39,40] is an UML profile that extends UML Statecharts with time and probability. Discrete probabilities are associated with events and a discrete probability distribution is defined over (event, state) pairs. We need a construct to group all transitions that are from the same state and form a probability distribution, but it is not clear what method, if any, is used for that in DAMRTS. From an example in [39], transitions with probabilities do not form a complete cover. So it can be the case that a transition is labelled with an event and a probability p, but there are no other transitions with the same event and the complementary probability 1 − p. The semantics in this case is not clear. DAMRTS models can be automatically translated to probabilistic timed automata and analysed by PRISM. This translation is, however, not formalised. In contrast, in RoboChart, a probability distribution is associated with a single transition, which defines the target states like in a probabilistic automaton. Moreover, the probabilities in such a transition add up to 1. So, there is no ambiguity. Our translation to PRISM is formalised in this paper.
Jansen et al. [41] describe a probabilistic conservative extension of UML's Statechart notation, called P-statecharts. Since the extension is conservative, we know that all the behaviours of the original semantics are behaviours of the probabilistic semantics. A transition can lead to one of several states depending on a specified probability distribution. Each probability distribution is guarded by a trigger, either an event or no event, which corresponds to an external action or an internal action τ in a probabilistic automaton. Discrete probabilities are associated with actions and a discrete probability distribution is defined over (action, state) pairs. A P-statechart alternates between nondeterministic choices and probabilistic choices using the strictly alternating model [18,42]. Transitions that exit nondeterministic choices enter only probabilistic choices. A P-statechart deals not only with nondeterminism and probabilism, but also with priorities within Statecharts. The semantic models of P-statechart are based on MDPs. Properties of a P-statechart written in the probabilistic branching time logic (PCTL) can, therefore, be automatically checked using PRISM.
Probabilistic modelling and verification using RoboChart are inspired by Jansen et al.'s P-statecharts. Similar to P-statecharts, RoboChart also deals with nondeterminism and probabilistic choices in the same strictly alternating way: transitions that exit nondeterministic choices enter only probabilistic choices. In the probabilistic model, even if two states are connected by a transition directly, therefore without an explicit probabilistic choice, it is treated as having an implicit probabilistic choice with the probability of the outgoing transition as 1. So, since every transition is prob- A conflict arises when a transition from a composite state and a transition from a substate are both enabled. A Pstatechart assumes a given priority scheme to resolve the conflict. RoboChart has a simpler semantics, which leaves the choice nondeterministically. In this way, we treat them as another level of nondeterminism in order to avoid dealing with the complexity of priorities in the semantics. Differently from P-statecharts, RoboChart does not support AND-states within a state machine (but supports parallelism between state machines) to simplify the semantics, and, therefore, make reasoning more tractable and improve automation of verification. Regarding triggers, RoboChart supports input and output triggers in addition to simple triggers just for synchronisation.
Richer action constructs are available in RoboChart, including assignments, communications, sequential composition, and conditionals. P-statecharts only support assignments and communications. Functions and operations can be specified using preconditions and postconditions described in the rich language of Z predicates. Table 2 summarises the comparison of RoboChart with the modelling languages above.

Domain-specific languages for robotics
Model-driven software development in robotics has been studied [43] and several domain specific languages are available [44]. SmartSoft 3 [45], V 3 CMM [46], BRICS Component Model (BCM) [47], RobotML [48], SafeRobots [49], and the work in [50] all employ component models like in RoboChart. Although some of them, such as BCM, have a degree of formal modelling, they usually do not have a formal semantics (and, therefore, cannot support formal reasoning and verification) or have a formal semantics only for part of 3 smart-robotics.sourceforge.net/. their constructs. RoboChart, however, has a formal semantics defined for all its constructs, including its component model.
GenoM3 [51,52] is a model-based engineering framework for robotics software. It supports verification using model checking via translation to Petri Nets [53] and deadlock checking using BIP [54]. It is also an executable language. RoboChart, nevertheless, provides various levels of abstraction, and also supports theorem proving in addition to model checking.
As far as we know, none of these notations support probabilistic modelling and reasoning, as we propose here for RoboChart. Extending these notations, however, may benefit from the results we present here.
Thrun et al. [55] uses MDPs as the underlying mathematical framework to model uncertainty in robot action selection for probabilistic planning and control, and introduces the value iteration algorithm to find control policies for these models. They use partially observable Markov decision processes (POMDPs) to model uncertainty in perception because the environment is usually only partially observable through sensors. Probabilistic modelling in RoboChart, as discussed in this paper, covers uncertainty in robot action selection. Our probabilistic semantics is also based on MDPs. RoboChart, however, supports different levels of abstraction through a component model, abstract data types, and a rich action languages (see Table 2).
In summary, the probabilistic modelling of RoboChart is based on existing notations, but provides abstraction and improved modelling practice for the robotics domain. The analysis of probabilistic behaviour in RoboChart models is fully automated, and the transformation from RoboChart to PRISM is formalised.
Next, we describe and illustrate RoboChart.

RoboChart
This section gives an overview of our approach to probabilistic modelling using an example. Part of the novelty of our work is related to the component model of RoboChart, not only the novel state machine constructs. For this reason, we present an example that illustrates the use of probabilistic choices, challenging constructs of machines, such as composite states, and the core elements of the RoboChart component model: controllers, robotic platforms, and modules. In Sect. 3.1, we present our probabilistic choice operator and an informal account of its effect on the RoboChart semantics. We refer to the RoboChart reference manual [1] for a complete account of the notation. Sections 3.2 and 3.3 present the metamodel and well-formedness conditions for the probabilistic constructors.

Notation
We describe our facilities for modelling probabilistic controllers using as an example a mail delivery robot from [56]. It delivers mail to eight offices arranged in the configuration in Fig. 1. An office 0 is the station to charge its battery. A worker in an office can send mail to another, but not to the charging station. The robot can deal with only one delivery at a time. Upon receipt of a delivery request, the robot starts to fetch the mail by moving to the sending office. Upon arrival, it fetches the mail and then moves to its destination to deliver it. After delivering the mail to its destination, it is ready for the next request.
The robot is not equipped with particular cameras or sensors for dynamic route allocation. Instead, it uses a random algorithm, similar to those of vacuum cleaning robots, to choose its moves. With equal probability, it either stays where it is or moves to adjacent offices. For example, if its current location is at office 1, it remains at office 1, moves to office 2, or moves to office 4. Each choice has probability 1/3. Module and Robotic Platform. The module of our RoboChart model for this example is shown in Fig. 2. The module deliv- The notion of robotic platform is a crucial element in the definition of a module (and so, of a model). It captures the services that need to be offered by a robotic platform to enable the use of the control software. For abstraction, these services are not specified in a module. This ensures that a module is platform-independent. The robotic platform, however, is the link to connect a module to a model for a physical robot, for example. This is described in detail in [57].
A platform includes variables, events, and operations that represent sensors and actuators. It may also define constants that characterise parameters of the model. In our example, we collect in an interface ctrlVarInf variables and constants of deliverRP. The current location and battery level of the robot are recorded as variables p and c. The battery capacity bat-teryCapacity and the battery charged per update chargeStep are design parameters and treated as constants .
We use interfaces to group elements for reuse and to describe dependencies. The interface ctrlVarInf in Fig. 2 is provided by the robotic platform. The variables and constants defined in ctrlVarInf are used in the controller and all its state machines, which require the interface (see Figs. 3, 4, 5, and 6).
In addition to variables and constants, the robotic platform can communicate with controllers via connected events .
The controller deliverCTRL in Fig. 2 gets a mail delivery request including an office number that locates the mail to be delivered and a destination office number from the platform via the typed events request and dest. After delivery, the controller notifies the robotic platform via the delivered event.
Controllers. The definition of the deliverCTRL controller is given in Fig. 3. It has three state machines : movingSTM, batterySTM, and taskSTM, which correspond to three separate functionalities: movement control, battery management, and task management. The machines are defined in Figs. 4, 5, and 6.
A controller in RoboChart encapsulates one or more (parallel) state machines. Connections between a controller and its state machines are used to relay information through the events of the controller. The connections on the events request and dest of the controller in Fig. 3 pass information from the platform to the machine taskSTM. The machine taskSTM acknowledges delivery via the delivered event relayed through the event delivered of the controller.
Connections between machines represent synchronisations and interactions. The machines movingSTM and taskSTM shown in Fig. 3 synchronise with each other on a move event used to trigger movement when the current position of the robot is different from the goal (either the mail request office or mail destination office), while mov-ingSTM and batterySTM synchronise on the upstart and upend events to trigger start and end of an update of the current battery level after a move. State machines. Behaviour descriptions are given by state machines in RoboChart. They may require interfaces and declare local constants, variables, and events, like controllers. For example, the taskSTM machine ( Fig. 4) declares two variables g and fd. The variable g is a natural number: an office number where mail needs to be fetched or delivered; g is initialised to 0. We call g the goal of the robot. The variable fd is an element of the enumeration FD defined in Fig. 4. It represents three stages of a delivery task: idle, fetching, and delivering mail. The variable fd is initialised to NoTask. These variables are local to taskSTM. All declared events appear on the border of machines.
A state machine comprises states, junctions, and transitions. States may be simple or composite. A composite state itself contains a state machine. A state may also have entry, exit, and during actions, executed when the state is entered, exited, and active. Transitions connect states and junctions. A self-transition has the same source and target states. Transitions have a label with the following optional features: • A trigger event; • A guard, specifying the conditions that need to hold for the transition to be enabled; • A probability value, defining the probability of occurrence of this transition; and • An action that is executed if the transition is taken.
Actions are statements. The action constructs are skip, an action that terminates immediately, assignment (=), sequential composition (;), conditional (if), input events (of the form evt?v where evt is an event and v is a variable that records the input value), output events (of the form evt!e where e is an expression whose value is output), or synchronisations (of the form evt or evt.e).
A junction is different from a state in that the control flow of a machine cannot stop at a junction. With a junction, we can break the flow of a transition by creating points of decision in between states. Junction is a concept of UML state machines and other Statechart notations. Junctions represent decision points that must be made immediately. As a consequence, a junction must always have at least one outgoing transition enabled in order to leave the junction. RoboChart has three types of junctions: initial junctions , normal junctions , and probabilistic junctions defined here. An initial junction indicates the starting point of execution of a state machine, and cannot have incoming transitions. Normal junctions have both incoming and outgoing transitions, but these transitions cannot be labelled with probability values.
Probabilistic junctions, also used in other techniques [58,59], are a special form of junction introduced to capture probabilistic choices. Only transitions from a probabilistic junction can be labelled with probability values, which must add up to 1. This imposes a proof obligation, since probabilities can be given by expressions involving variables.
The taskSTM machine in Fig. 4 has just one state taskState with four self-transitions. The top-right transition is taken when there is a mail delivery request (trigger request?g) and the robot is idle (guard fd=FD::NoTask where FD::NoTask is a constant of the enumeration FD). If that transition is taken, its action establishes that if the goal g is an office number from 1 to 8, the robot moves to the fetching mail stage (FetchMail); otherwise, it ignores the request (skip). The bottom-right transition is taken if the robot is not idle and its current position is not the goal. If so, the machine waits for a synchronisation on the move event, as specified by the transition action move (a synchronisation action). The top-left transition is enabled if the robot arrives at the office to fetch mail (g==p) when it is fetching mail. If that transition is taken, the machine waits for an input dest?g from the platform giving the delivery destination g. If the destination office is valid (between 1 and 8), the robot switches to the delivering stage. Otherwise, it discards the request. The bottom-left transition is enabled if the robot reaches the destination when it is delivering. If so, it returns to the idle stage and sends a delivered acknowledgement.
The batterySTM machine in Fig. 5 manages the battery. It has only the state batteryState. The transition from the initial junction sets the battery level c to its capacity bat-teryCapacity to record that initially the battery is full. Two self-transitions of batteryState can be taken when the event upstart occurs. One is taken when the robot is at the charg- ing station (p==0 , where p is provided by deliverRP shown in Fig. 2 and required here through an interface ctrlVarInf), and another when the robot is not there and the battery is not empty. In the first scenario, the battery is charged and its level is increased by the constant chargeStep per update till it is full. In the second scenario, one unit of the battery is consumed. In both scenarios, the upend event is used to signal that the battery state has been updated. Both upstart and upend are synchronisations with events in the movingSTM machine to allow the battery to be updated when the robot is moving.
The movingSTM machine in Fig. 6 controls movement of the robot. The machine has two states: Stuck and Move. The transition from the initial junction sets the current position p of the robot to the charging station. The Move state is composite. Its machine has nine states (from s0 to s8). Each such state corresponds to one office and has an entry action such as p=2 that sets p to 2 upon entering of the state s2 to record in p the office in which the robot is located. The transitions from such states are connected to probabilistic junctions and are labelled with a trigger move and a guard condition (c>0). So, these transitions are taken only when movement is trig-  No matter which outgoing transition is taken, the machine updates the battery by synchronising with the batterySTM machine using upstart and upend events.
When the robot is not at the charging station and its battery is empty, the transition from the Move state with guard c==0 is taken. A junction in this transition defines a decision based on the current robot position. If it is at the charging station, the battery is charged by synchronising with the batterySTM machine and movingSTM reenters Move. Otherwise, the machine movingSTM enters the Stuck state because the robot has no battery and cannot charge. Stuck has no outgoing transitions. So the robot cannot move again.
Next, we describe the RoboChart metamodel, and return to this example later in Sect. 5.2.

Metamodel
Here, we describe the RoboChart metamodel [1] and the changes needed to include probabilistic choice.
A RoboChart model is defined by a module, whose metamodel is shown in Fig. 7. A Module comprises a collection of nodes (ConnectionNode) and connections (Connection). A ConnectionNode can be a RoboticPlatform, a Controller, or a StateMachine. A RoboticPlatform is either given by a definition (RoboticPlatformDef) or by a reference to a definition (RoboticPlatformRef). A RoboticPlatformRef refers to exactly one RoboticPlatformDef. The metamodel for controllers and state machines is similar. A node in a module can be a definition or a reference to a definition of a robotic platform or a controller, but not a state machine as specified by well-formedness conditions discussed later.
A StateMachineDef is a StateMachineBody that can be used as a ConnectionNode (in a ControllerDef). So, StateMachineDef needs to inherit from both StateMa-chineBody and ConnectionNode. We, however, have an intermediate concept of a StateMachine that inherits from ConnectionNode. StateMachineDef inherits from Connec-tionNode via StateMachine, which allows different forms of definition. In particular, a StateMachine may be defined by reference to a StateMachineDef.
Robotic platform and controller definitions may provide and require interfaces through extending Context. The class Context contains variables (VariableList), operations (Oper-ationSig), and events (Event), and refers to three kinds of interfaces: provided interfaces (pInterfaces), required interfaces (rInterfaces), and defined interfaces (interfaces). Connection links one node to another by their events. A connection can be asynchronous or synchronous, and unidirectional or bidirectional. The metamodel permits connections between any two nodes, but not every connection is valid. For example, a robotic platform cannot connect to a state machine. We connect them through a controller. Wellformedness conditions enforce such restrictions.
ControllerDefinitions, are composed of a collection of state machines and connections. The structure of a state machine is detailed in Fig. 8. A state machine is a Node-Container that includes a collection of nodes (Node) and transitions (Transition). States (State), junctions (Junction), and probabilistic junctions (ProbabilisticJunction) are possible nodes. State is also a NodeContainer, so a state can include nodes and transitions. This supports hierarchical state machines. State contains entry, exit, and during Actions. Initial is a junction and Final is a state. Transitions are directional and connect one source node to a target node. A transition may have a trigger (Communication), a guard (Expression), a probability value (Expression), and an action (Statement).
The metamodel of variables, communications, events, and operations is shown in Fig. 9. A Variable, an Opera-tionSig, and an Event all have a Name. A Variable also has a Type and an optional initial value, given by an Expression. A VariableList contains one or more variables and has a modifier (VariableModifier) from which the counterpart in a Variable derives. An operation signature (OperationSig) contains zero or more parameters (Parameter). A Commu-nication has a type (CommunicationType), and may have a parameter (Variable), a value (Expression), and refer to an Event. An Action contains exactly one Statement. A Com-municationStmt is a Statement that contains exactly one communication: that uses an Event.
The changes we have made to the original RoboChart metamodel presented in [1] to cater for probability are minor: addition of ProbabilisticJunction, and a probability value to Transition. Next, we define healthiness conditions associated with these constructs.

Well-formedness conditions
Well-formedness conditions define restrictions on models to make them meaningful. It includes typing and scope rules for expressions and actions, and imposes various conditions, such as uniqueness of names in all components. The RoboChart reference manual [1] gives a full account of these conditions.
We now present the extra well-formedness conditions imposed on transitions (Sect. 3.3.1) and on the new probabilistic junction (Sect. 3.3.2).

Transitions
PT1 The source of a transition with a probability value must be a probabilistic junction, that is, states, initial junc- We introduce PT1 because RoboChart implements an alternating model between nondeterministic choice and probabilistic choice. (This is in line with other authors to simplify the semantic model, and in particular the interaction between nondeterministic choice and probabilistic choice-see references [18,41]. This follows, for example, the reactive modules formalism of PRISM.) Therefore, it would be awkward at best to have arbitrary probabilistic transitions in state machines. The probabilistic junctions provide a syntactic mechanism to isolate the probabilistic choices. Probabilistic choice is only made and resolved at probabilistic junctions.

Probabilistic junctions
Probabilistic junctions are also junctions, but with extra wellformedness conditions. PJ1 There must be a probability value on every outgoing transition from a probabilistic junction. PJ2 There must not be a guard on an outgoing transition from a probabilistic junction. PJ3 The probability values of all outgoing transitions from a probabilistic junction must sum to 1.
PJ2 enforces construction of simple models by separating concerns. If a guard is needed, then it can be added with a preceding transition, so there is no loss of expressiveness. PJ2 is also helpful in simplifying the process of counting transitions and choice resolution; these counts are used in the notion of time in the Markov semantics and probabilistic temporal property language. Before defining our model transformation, the next section describes the target language, the notation adopted by PRISM, its semantics, and its metamodel.

The PRISM notation
In the previous section, we have described how to use RoboChart to model discrete-time probabilistic systems. Another question follows: how do we verify these systems?
As mentioned, this work enables model checking using probabilistic model checkers, specifically PRISM [3], but potentially also Storm [26] and MRMC [60], which adopt the same input notation. Section 4.1 describes the notation that supports. We then present a metamodel that we have defined for that notation in Sect. 4.2.

PRISM
PRISM 4 is a model checker for verifying probabilistic behaviour. It allows us to analyse various probabilistic models, including DTMCs and MDPs.
The PRISM language is similar to Alur's Reactive Modules formalism [27], but with a different variable model. In a reactive module, variables fall into three groups: private, interface, and external. A module M can read every other modules' interface and external variables, but not their private variables. M can write to its own private and interface variables, but not to other modules' external variables. PRISM does not have private variables: all local variables in a module are interface variables. PRISM also has global variables shared by all modules for reading or writing. Interleaving global-variable updates avoids race conditions. PRISM employs a closed-world assumption, that is, systems are not subjected to inputs from the environment. In order to take specific environmental inputs into account, another module can be added to the model to encode generation of desired inputs.
PRISM's semantics is not compositional: parallel modules are flattened into a single system module [61]. Module combinators are similar to CSP process algebraic operators, including parallel composition, action (event) hiding, and action renaming. The parallel composition operators are as follows: • M 1 A M 2 , requiring both modules to synchronise on the actions in the set A.
and A 2 are the sets of actions used in the modules M 1 and M 2 , respectively.
Communication between modules in PRISM, however, is not based on actions. These have only names and cannot carry messages (or data). So actions are used only for synchronisation. Exchange of messages is through variables: both global and local variables.
An important feature of PRISM is statistical model checking (SMC) [62,63]. This is a Monte Carlo discrete-event 4 www.prismmodelchecker.org/. To support SMC, however, the PRISM model cannot have multiple initial states and process algebraic operators in the construction of the system module. So no parallel composition can be specified. PRISM implicitly uses to define a system M 1 M 2 · · · M n from all modules M 1 , M 2 , ..., M n in the model.
The structure of a PRISM model is illustrated in Fig. 10. There are six sections in a PRISM model: S1 is mandatory and gives the model type. In Fig. 10, S1 is given on line #2, which defines DTMC as the type for this example. Other available model types are MDP, continuous-time Markov chain (CTMC), and probabilistic timed automata (PTA).
S2 declares constants used in the model. In Fig. 10, S2 is given on line #5, which declares one constant pi that is of type double and set to a real number.
S3 declares global variables. In Fig. 10, S3 is given on lines #8-#9, which declare an integer variable i and a variable j with range [0..10]. Both initialised to 0.
S4 defines formulas that give names to expressions. In Fig. 10, S4 is given on line #12, which defines a formula f1 associated with expression pi*2.
S5 defines the individual modules. Each module has two subsections: S5_1 for local variable declarations and S5_2 for commands described in the sequel. S5 is given on lines #15-#29, which indicate the definition of modules M1, M2, and Mn. S5_1 is on line #17, which declares a local boolean variable l initialised to false, and S5_2 has a single command given on line #20. The command has an action e1, a guard condition g1, and a set of updates separated by +. An update is composed of an optional probability value, such as p1 in the example, and an assignment, such as u1. S6 defines rewards associated with models. In Fig. 10, S6 is given on lines #32-#35, which define two rewards: a reward on line #33 associated with states, and another on #34 associated with transitions. Rewards, which are used in properties (but defined within models) to allow reasoning about a wide range of quantitative measures, assign particular values to certain states or transitions. If a reward has an action, then this applies to all transitions labelled by that action.
A state is a valuation of all variables (global and local) in the model. The state space S of the model is all valuations of variables. A command [e] g -> p1:u1 + ... + pn:un; defines a transition augmented with probabilities. The optional action e is available for synchronisation with other modules. The guard condition g ranges over the state space S. In other words, g characterises a subset of the state space, denoted by S g , that satisfies the condition. The collection of state updates pi : ui, where 1≤i≤n pi = 1, comprises a probability pi and a collection of assignments ui. Each pair defines the probability pi of the transition going from a source state s in S g to a target state s specified by the set of assignments ui. A command cannot update a global variable if it has an action. This avoids two commands synchronising with different updates for a global variable.

Example 1
We present below the PRISM model for a simple robot that moves along a corridor following a random walk. It randomly chooses its moving direction: either to the left or to the right with probability p or (1 − p) respectively. If, however, the robot reaches an end of the corridor, it can only The PRISM script, as shown in Fig. 11, defines a DTMC model (line #1). A constant p represents the probability described above (line #3). A constant N records half of the length of the corridor (line #4). The only module ran-dom_walker (lines #6-#14) has one local variable: x for the current location of the robot, defined over a range from -N to N, and initialised to 0 for the centre of the corridor (line #7). The commands on lines #9-#13 define the transition system of the module. In the commands, we use x' to represent the after-transition value of x. Every move event represents one step of the robot. In the left end, the robot can move only to the right (line #9), while in the right end, it can move only to the left (line #10). In locations other than the ends ((x > -N & x < N) on line #11, where & denotes conjunction), it can move to the left (line #12) or to the right (line #13) with probability p and (1-p).
The rewards on lines #17-#18 assign a reward of 1 to every state in which the robot reaches the location N/2 (line #17) or the location -N/2 (line #18). This enables us to specify reward-based properties [64] (the properties of DTMCs or MDPs augmented with rewards) that allow quantitative measures of the model at the two locations. For example, the quantitative property R=? [F (x=0 & (X (F x=0)))], where R=? denotes reward-based operator [64], and F and X stand for the eventually and next operators in PCTL, specifies a property of the expected cumulated reward that the robot receives when it passes through the two locations before it returns to the centre of the corridor.
Next, we describe the PRISM metamodel.

PRISM metamodel
We show the metamodel we have defined for the structure of a PRISM model in Fig. 12. A Model contains one or more modules (Module), and zero or more constants (Constant), global variables (VarDecl), formulas (Formula), labels (Label), and rewards (Rewards).
A Constant associates a name (Name) with a type (Type) and an optional value (Expr). A VarDecl declares a variable with a name, a type, and an initial value (Expr). Formula and Label are similar but do not have a type. Both associate a (formula or label) name with an expression. A Label requires a boolean expression (BoolExpr), but a Formula can have any expression (Expr). The complete metamodel is in [1]. Figure 13 depicts the metamodel for PRISM modules. There are two ways to specify a module: either with a Mod-uleDefinition; or by renaming (ModuleRename, omitted in the diagram for simplicity). ModuleDef defines a module by its name, local variables (VarDecl), and commands (Command).
A command contains an optional action (Action), an optional guard (BoolExpr), and one or more updates (Update). An update has an optional probability (Expr) and a collection of assignments (AbsAssignment). There are two types of assignments: Assignment associates a variable with a value (Expr); and Skip is an empty assignment, in which no variable is updated.
There are four primitive Types, as shown in Fig. 14: boolean (BoolType), integer (IntType), range (RangeType), and double (DoubleType). Figure 15 displays the reward metamodel. An action is optional. Without an action, the reward item assigns a reward (Expr) for all states satisfying the guard condition (BoolExpr). If there is no trigger event for these transitions, we assign the silent action "tau".
The next section defines our model transformation.

Model transformation
RoboChart is different from PRISM in various aspects. To deal with these differences, we structure the translation in two steps: normalisation of the RoboChart model and transformation of normalised RoboChart models to PRISM. Section 5.2 gives an overview of the translation. In Sect. 5.2.1, we define our normal form, namely restrictions on RoboChart models that ensure all transitions between two states are probabilistic, and define a strategy for normalisation. We describe a strategy to transform from a RoboChart model in normal form to a PRISM model in Sect. 5.2.2. We present formal rules used to normalise RoboChart models in Sect. 5.3 and to transform normalised models in Sect. 5.4. Extra rules are presented in "Appendix A". The complete set of rules can be found in [1]. Not all features of RoboChart are currently supported. Section 5.1 presents our assumptions.

Translation requirements
We list the conditions that need to be satisfied by a RoboChart model for our technique to be applicable. In DTMCs and MDPs, transitions occur in discrete-time steps. Every transition takes one unit of time. Time primitives [2] in RoboChart, however, capture budgets and deadlines using clocks and constructs like wait(n), which defines a waiting period of n units of time, and read?x<{2}, in which reading a value x through an event read is given a deadline of 2 units of time. DTMCs and MDPs do not intrinsically support clocks, time budgets and deadlines. Our first translation requirement, TR-TP1 below, therefore, rules out translation of time constructs for now.
TR-TP1 Time primitives are not used.
In addition to DTMCs and MDPs, the PRISM notation also supports probabilistic timed automata (PTAs) [65,66], which extend MDPs with the ability to model real-time behaviour through real-valued clocks [67]. The timed semantics of RoboChart, however, are based on time units [2], instead of real-valued time. The default verification method (quantitative abstraction refinement [68]) for PTAs in PRISM, therefore, cannot be used. Instead, we can use the digital clocks [69] method which uses an integral time model. We will extend our transformation to support PTAs to deal with time primitives in RoboChart, which is part of our future work, as discussed in Sect. 8.
TR-CN1 Connections between controllers are not asynchronous. TR-OP1 Operations cannot be defined in controllers. TR-ST1 States cannot have during actions.
To cater for these constructs, the PRISM model needs to include extra modules to deal with shared variables, buffers for asynchronous communication, operation calls, and interruptions of during actions by outgoing transitions. Dealing with these extra constructs is part of our agenda for future work.
TR-TY1 Only primitive types and enumerations, sequences of these types, or sequences of sequences of these types are used. TR-EX1 Quantification, lambda, and definite description expressions cannot be used since the PRISM notation is concrete.
PRISM supports only integer, boolean, and real numbers. Refinement techniques [70,71] are a possible solution to deal with abstract data types and constructs in RoboChart. For example, we can refine a variable of the type P T , where T is an enumeration, in RoboChart to a variable over an integer range in PRISM, and use it as a bitmap. Support of more abstract data types and expressions is part of our plans for future work.
In the next section, we give an overview of our translation strategy, which is formalised later in Sects. 5.3 and 5.4. We deal with a rich set of features: parallel controllers, with parallel hierarchical machines, nondeterminism, junctions, probabilistic junctions, synchronous connections, input and output triggers, and functions.

Overview
In this section, we first present the normal form that we define for RoboChart models and the strategy for normalisation in Sect. 5.2.1, and then we describe the strategy for their transformation to PRISM models in Sect. 5.2.2.

Normalisation
A normalised RoboChart model satisfies the following extra conditions on transitions and junctions.
NFM-1 A state has at least one outgoing transition. NFM-2 A transition that is from a state or a normal junction to a normal junction has an action. NFM-3 A transition can have a trigger or an action, but not both together.
NFM-1 is needed due to the fact that DTMCs and MDPs are stochastic. Any state in a PRISM model has to have at least one outgoing transition. If an incoming transition to a normal junction has no actions, this transition can be combined with outgoing transitions of the junction, which can be removed. The combination of transitions and the removal of junctions reduce the translated PRISM models.
For transitions with a trigger and an action, the action may a) update global variables, and b) have input and output events, or synchronisations, such as the action in the label close[g]/collect. Such transition cannot be translated to a PRISM command directly because a command a) cannot have an action and an update to global variables together, and b) cannot have more than one action. So we impose NFM-3.
To illustrate normalisation, we use the taskSTM machine in Fig. 4 and the movingSTM machine in Fig. 6 as examples. We present their normal forms, and describe how to get a normalised machine.
The taskSTM machine is not in normal form because the transition with a trigger request?g has an action as well, which does not satisfy the condition NFM-3.
A normalised version of taskSTM is shown in Fig. 16 where the changed parts are highlighted in a dashed box. The original transition is replaced by a transition to a new probabilistic junction, and a transition from the probabilistic junction to the original target. The condition of the original transition is used in the transition to the new probabilistic junction, ensuring that a transition is not taken unless the guard holds. The single transition from the probabilistic junction has probability 1 and the action of the original transition. So this new transition is always taken, and the action is executed, as in the original model.
The movingSTM machine has an initial junction, a normal junction, and two states: a simple state Stuck and a composite state Move. The machine movingSTM is not in normal form because a) the incoming transition of the junction in the machine has no action, which does not satisfy the condition NFM-2, and b) Stuck has no outgoing transitions, which does not satisfy NFM-1.
A normalised version of movingSTM is shown in Fig. 17 where the changes are highlighted in a dashed box. The junction and its corresponding incoming and outgoing transitions in the original machine are replaced by two transitions: one from Move to Stuck, and another from Move to itself. They are guarded by the conjunction of the guards of the transitions to and from the junction. The target states are the same.
In the normalised machine, the Stuck state has a new outgoing transition to a new state loop. In general, we add a state loop for each state machine or composite state that has at least one state with no outgoing transition. The new transition (from Stuck in our example) has no trigger, guard, or action. So this transition introduces no new visible behaviour. From loop, a similar transition leads back to loop itself. Overall, where the original machine deadlocked, the normalised machine livelocks. As already mentioned, this is what is required for a probabilistic analysis using DTMCs and MDPs. In the example, there is no loop state in Move because all its substates have outgoing transitions.
In Sect. 5.3, we present the rule that can be used to normalise the original model if applied exhaustively (to all its state machines). Before presenting that rule, however, we give an overview of the normalisation process, explaining how each of the transitions and junctions of movingSTM are affected by it. Each state machine is normalised by a) adding the loop state and corresponding transitions, if needed; b) combining incoming and outgoing transitions of normal junctions as illustrated for the transition out of Move in movingSTM; c) splitting each transition that has a trigger and an action together into two transitions connected via a new probabilistic junction as illustrated for a self transition of taskState in taskSTM; and d) normalising machines of composite states.
As illustrated above, the combination of transitions to satisfy NFM-2 may lead to the introduction of multiple outgoing transitions from the original source junction with stronger guards. Because there can be only one outgoing transition from an initial junction, we cannot combine outgoing transitions of initial junctions in this way. For probabilistic junctions, PJ2 forbids the presence of guards on outgoing transitions. We cannot, therefore, consider the optimisation enabled by NFM-2 for transitions from initial or probabilistic junctions.
The use of normalisation deals with all the complexity of a RoboChart model to produce a module in a form that is convenient for a direct translation to PRISM.

Transformation to PRISM
The structure of our translation is sketched in Fig. 18. The structure of a RoboChart model is illustrated at the top, and the structure of its corresponding PRISM model is given at the bottom on the left.
The RoboChart module, M, contains a robotic platform RP and multiple controllers (C1, …, Cj, …). Each controller contains various state machines (STM1, …, STMi or STMk, …). The robotic platform, controllers, and state machines all have a declaration part, which includes variables, constants, and events. We distinguish events in four groups, we use: a) a blank box for independent events that are not connected; b) a box with a C inside for the events that are connected from or to a controller; c) a box with an R inside for the events that are connected from or to the robotic platform; and d) a box with an S inside for the events that are connected from or to a state machine. Additionally, boxes drawn with the same sort of lines (solid, dashed, and so on) indicate events that are connected (either directly or indirectly). For example, the machine STM1 in C1 has a dotted box (C), a dashed box (S), and a blank box. The dotted box denotes the events of the machine that are connected to the events of its controller C1 that are represented by a dotted box too. The dotted box of C1, however, has an R, so these events are further connected to those of the robotic platform (represented by the same dotted box). The dashed box (S) of STM1 represents the events that are connected to other machines in C1, specifically STMi. Particularly, STMi of C1 contains events represented by the bold box (C) that are connected to C1, then to Cj, and finally to the events of STM1 in Cj represented also by a bold box (C).
Generally, the resulting PRISM model (see bottom left of Fig. 18) contains three parts: (a) constants that correspond to the constants of the robotic platform, denoted M.RP.C in Table 3 Summary of construct syntax in rules Form Description

Junction
The class name from the metamodel also represents a collection of objects that have the Junction type. Similarly, State, ProbabilisticJunction, Controller, and so on. Particularly, ProbJunc is an abbreviation for ProbabilisticJunction for a compact space.

Class rc
Subscripts indicate classes of different metamodels, where rc stands for RoboChart, and pr for PRISM. For example, Transition rc and ModuleDef pr denote the Transition in RoboChart, and the ModuleDef in PRISM.

PX
Power set of X .
p.n Selection of nth element from the tuple p.
obj.v Selection of value of component v from object obj.
Record where f i is a component name and v i is the value associated to that component. It represents an object of the class C with its components instantiated.

uname( par, m)
This function constructs a fresh unique identifier for a new element from the supplied construct par (of type NamedElement) and the name m (a string) of the element.
uname( par, m, n) Similar to uname( par, m), but this function has three parameters where both m and n are of type string.

id(n)
This function defines a unique identifier for an existing construct n (of type NamedElement). If n is null, it gives an empty name. One possible implementation is to use qualified names. Renaming plays an important role in the translation of a RoboChart model to PRISM because the variable model of RoboChart is different from that of PRISM. Each element in RoboChart has a given scope. For example, a variable defined in a controller is visible to its inner state machines, but not to the state machines in other controllers. Two variables of the same name in different controllers or state machines are permitted. In contrast, the PRISM language has a flat structure. If two variables in different modules have the same name, then this results in a name conflict. To address this problem, we rename all elements, with the exception of events, used in a RoboChart model to ensure that they all have unique names before translation.
In RoboChart, connections can associate events of different names. This means that a component (machine, controller, or robotic platform) can be used in any context, irrespective of the names that they use for their events. In PRISM, however, connections are realised via synchronisation based on the names of the actions. So, we must make sure that actions in different PRISM modules that need to synchronise have the same name. In our translation, we represent RoboChart events using PRISM actions and connections using synchronisation. Therefore, we ensure, before translation, that events are renamed so that all connections associate events of the same name.
For example, the independent events (represented by the blank box) in STM1 of C1 become independent actions represented in the same style in the M.C1.STM1 module. The actions represented by the dotted box in the module have the same names as the actions represented by the same type box in the robotic platform module. So the modules M.C1.STM1 and M.RP synchronise on these actions, which reflects the connection of their corresponding events in the RoboChart model. Other actions represented by a dashed box, or a bold box, or a bold dashed box are handled similarly.
To illustrate the overall structure of the translation, we use the mail delivery robot model introduced in Sect. 3. We present the structure of its PRISM script, and describe how to get it from the RoboChart model.
The PRISM script is sketched in Fig. 19, where elements not relevant to the structure are omitted, such as the naming, constant declarations, and command details. The model type is on line #1; we use the type DTMC so that we can obtain probabilities of the robot running out of power at different offices. The model type is a parameter to the translation. A translated PRISM model can also use another model type: MDP. The selection of the model type depends on the properties to be analysed using PRISM. For DTMC, PRISM randomises nondeterministic choice and regards them as uniformly probabilistic choices. So PRISM can check quantitative properties such as "what is the probability of the robot running out of power and stay stuck at office 2". For MDP models, PRISM does not treat nondeterministic choice probabilistically, and aims for establishing minimum and maximum probabilities, not exact probabilities.
Constants and global variables are declared on lines #3-#7, and four modules are defined on lines #9-#43. The module deliverRP on lines #9-#20 corresponds to the robotic platform, and the other three modules on lines #21-#27, #28-#33, and #34-#43 correspond to three state machines in the RoboChart model. Constants and variables provided by the robotic platform are translated to constants and global variables, as shown on lines #4-#7. MININT and MAXINT are placeholders for the smallest and largest integer to be included in the set to represent the integer numbers. Their values are parameters for the translation.
The robotic platform module deliverRP in PRISM represents the environment of the system modelled, and generates inputs (using a nondeterministic choice over possible input values) to the software. Two local variables on lines #10-#11 correspond to the output events request and dest of the robotic platform (see Fig. 2), that is, the inputs to the controller. They have the same type as the request and dest events. MAXNAT is similar to MAXINT but represents the largest natural number. When a synchronisation on either action (request or dest) occurs, the corresponding local variable (either EVT__request or EVT__dest) is assigned a value nondeterministically chosen. The commands on lines #13-#15 define the choice for EVT__request. The other module involved in the synchronisation (in this case, taskSTM) copies the value to a local variable (as illustrated by the command on line #39) to simulate the acceptance of input values from the environment. The actions move, upstart, upend, request, dest, and delivered in four modules correspond to the events in the RoboChart model. Since in this example only events of the same name are connected, there is no need to rename events. The actions of the same name such as move on line #23 in movingSTM and line #38 in taskSTM allow synchronisation of the two modules, as specified by the connection in Fig. 3.
The events upstart and upend are used for synchronisation between two state machines. They are not events of the robotic platform; therefore, the visible behaviour of the RoboChart module does not include occurrences of these events. In PRISM, it is possible to use a hiding operator (similar to that of CSP) to make synchronisations on given actions internal (not visible). The use of such operator, how-ever, makes statistic model checking infeasible. So, we keep these actions visible.
Two local variables (g and fd) of the taskSTM module on lines #35-#36 are translated from the corresponding local variables in taskSTM (see Fig. 4). The type of fd is a range that relates to the number of literals in the enumeration FD (see Fig. 4). The initial value of fd is NoTask that is represented by 0 (line #3).
We illustrate our approach to modelling state machines in PRISM in Fig. 20, where we present the module for the normalised taskSTM machine in Fig. 16 on lines #25-#54. We use three (sets of) variables: program counter scpc, lock, and exit variables, in addition to the local variables of the state machine. In this simple example, we have local variables fd and g, and just two variables scpc and lock. Later in this section, we consider examples with extra variables including exit variables. The required variables c and p, and the required constants batteryCapacity and chargeStep are declared globally, as shown in Fig. 19.
A program counter variable scpc records the current state of the machine. In our example, we have just the initial state and the taskState. We name the initial state i0 and declare two constants i0 and taskState to associate these states with the numbers 1 (line #12) and 2 (line #13). Extra constants declared on lines #14-#23, associated with the numbers from 3 to 12, are needed because the notion of state in RoboChart does not match that of PRISM (see Sect. 4.1), which is based on valuation of variables. So, we have constants for each action of RoboChart whose encoding in PRISM may lead to a change of the value of the variables in the scope of the machine module taskSTM.
We associate these constants with a sequence of integer numbers starting from 0 and increasing in increments of one. For convenience, we refer to these numbers as state numbers because they are used to index states in machine modules. In principle, all that is required is that the constants uniquely identify a module state. The definition of the type of the program counter variable, scpc, which needs to range over the values of these constants, however, imposes an extra challenge. In PRISM, the type of a variable must be finite, which means integer numbers (int) cannot be the type of scpc. MININT and MAXINT, previously described, are used to define the set of integer numbers in RoboChart models. The state numbers, however, might be larger than MAXINT. We, therefore, number the states sequentially, and use specifically a contiguous range of integers, starting at 0, such as [0..12] shown on line #26, to specify all values that scpc can take. The upper limit 12 of the interval is the maximum number associated with these state constants in the module. Any finite set would be appropriate for the translation, but that set needs to be identified to define the constants and the type of scpc. Our particular approach is based on an integer interval starting at 0.
In principle, the execution of the commands for each transition of the machine can lead to a change of state of the PRISM module, because a transition can have an action. So, each transition is given a set of numbers used to record the states of the PRISM module that are reached when the encoding of the transition is executed. Figure 21 presents an annotated version of the normalised taskSTM where the transitions are associated with the numbers used in the PRISM module in Fig. 20 to encode the transitions.
For example, the transition labelled t1 in Fig. 21 is associated with the state 2, for taskState, and also, with an extra state 6, due to the action move. The transition t2 is associated with states 9, 10, 11, and 12; similarly, t3 and t4 are associated with other states. The names of the constants representing the extra states are based on the name of the source state of the transition. In the example, we have taskState_3, taskState_6, and so on. When the source is the probabilistic junction, we use p0_1 and p0_2. What is essential is a mechanism to give unique names to the extra-states constants.
Since the execution of a RoboChart transition may take the PRISM module through several states, we need a mechanism to prevent the interference from other transitions when the machine module is in one of these intermediary states. For instance, if t4 is taken, and the module is in the state 4, other transitions should not be taken until t4 is completed by returning to taskState. For this reason, we introduce a lock variable (line #27) for the machine module. This variable initially takes the value 0, represented by a constant LOCK_FREE (declared on line #5). It records that there is no transition in execution, and, therefore, other transitions can be taken. In addition to 0, lock can also take other values in the range 1 to 5 (line #6-#10). Each number represents a transition. For example, 5 (represented by T4 on line #10) denotes the transition t4. For convenience, we call these numbers transition numbers because they are used to index transitions in machine modules. The need to record in lock a transition number is not illustrated in this example, but it is explained later when the example for movingSTM is presented.
In the initial state of the PRISM module, the values of the local variables scpc and lock are i0 and LOCK_FREE. The PRISM transition system simulates the behaviour of the machine. In the initial state, the single transition t0 is available and can be taken. So, when the value of scpc is i0, it can be changed to taskState as shown by the command on line #31.
When scpc records that the current state is taskState, there are four transitions available, captured by the commands on lines #33, #36, #43, and #47. They all have guard conditions to ensure scpc is taskState and lock is free. Other guard conditions in these commands are from the guards of the corresponding transitions. Particularly, the Fig. 20 The PRISM module of taskSTM transition t4 has a trigger request?g, which is recorded in the command on line #47 with an action request and an update to the local variable g from the value of the variable EVT__request to simulate a communication between the machine and the robotic platform. If these transitions are enabled and taken, the updates of these commands change the value of lock to the corresponding transition number and the value of scpc to the first state number corresponding to the transition. For example, the command on line #33 updates lock to T1 and scpc to 6 (taskState_3). After one of these commands is executed, the value of lock is not LOCK_FREE any more, therefore, none of these commands Each transition corresponds to several commands in the PRISM module. The transition t1 is encoded by two commands on lines #33 and #34. The first command deals with scpc and lock as just explained. When the current state of the machine is taskState_3, only the second command on line #34 is enabled. The action move of the command corresponds to the action move of the transition. After the synchronisation of the move action, the command changes the values of scpc and lock to taskState and LOCK_FREE to encode that the transition is completed and its target state is entered.
The transition t2 is implemented by six commands on lines #36-#41. After it is taken, scpc and lock are updated to taskState_6 and T2 on line #36. As shown in Fig. 21, a sequential composition of actions is encountered at taskState_6. The first action dest?g is encoded by the command on line #37, while the second conditional action corresponds to the subsequent commands on lines #38-#41, of which two are for the if branch and two for the else branch. In each pair, the first command is related to the branch condition and the second to its action. When the module is at the state taskState_7 because of the synchronisation on dest, if the value of g is valid (between 1 and 8), the command on line #38 is executed next, which takes the module to taskState_8. At this state, only one command on line #39 is enabled. Upon its execution, fd becomes DeliverMail. If the value of g is not valid, fd is set back to idle (NoTask) on lines #40 and #41.
The transition t3 is enabled if the destination of the delivery is reached (g is equal to p) and the robot is delivering as shown by the command on line #43. After the transition is taken, the module passes through states taskState_4 and taskState_5. Finally, the task returns to NoTask and a delivered event is signalled, shown by the commands on lines #44 and #45.
The transition t4 has an input trigger (request?g) and its target is a probabilistic junction represented by the constant p0 on line #14. The command on lines #47 and #48 corresponds to t4; it updates scpc to p0. The probabilistic junction has one outgoing transition to taskState with probability 1. The action of this transition is a conditional that involves two states p0_1 and p0_2. From p0, the next state is p0_1, as shown on line #50. The conditional action is encoded by the commands on lines #51-#53. The encoding is similar to that for the transition t2, but since the action of the else branch is skip, there is no additional state, and, therefore, only one command encodes that branch.
Since none of the states in the taskSTM machine has an exit action, its PRISM module in Fig. 20 has no exit variable. If a state has an exit action, such as the state s0 in Fig. 22, an exit variable is used in PRISM, as shown in Fig. 23. Constants s0_1, s0_2, and s0_3, declared on lines #9-#11, represent three extra states in PRISM as annotated s0_1, s0_2, and s0_3 in Fig. 22. Intuitively, we can think of the exit action as being part of the action of every transition out of the state. So, we deal with exit actions much in the same way as we deal with transition actions. The snippet in Fig. 23 encodes the exit of the transitions t1 and t2 in Fig. 22 from their source state s0. The commands on lines #18 and #20 are specific to t1, and those on lines #22 and #24 are for t2. Both transitions share an exit from s0, as encoded on lines #26-#28, using an exit variable declared on line #14. This variable records the exit states that arise by the execution of the exit action and takes three possible values in this simple example. They represent the states in which the execution of the exit action has not started (Exit_NONE), has started (Exit_Sub_ACT), and has completed (Exit_Sub_EXITED). These values are represented by three constants declared on lines #1-#3.
If t1 is taken, lock is set to T1 and an exit request is triggered by updating exit to Exit_Sub_ACT, as shown on line #18. The next command on line #20 for t1 checks the exit completion indicated when the value of exit is Exit_Sub_EXITED. The value Exit_Sub_ACT indicates an exit request to the current state of the module. Since t1 is taken, the current state is s0 (that is, scpc=s0). So the guard on line #26 is satisfied, and s0 receives the request and updates the counter to s0_1 to deal with its exit action in the commands on lines #27-#28. In the end of its exit action, s0 marks that it has exited by setting exit to Exit_Sub_EXITED (on line #28). The command on line #20, therefore, is enabled. So after exiting from its source state, t1 continues to deal with its transition action and targets, omitted in Fig. 23. The way we encode t2 is very similar.
We use this simple state s0 with an exit action to demonstrate how an exit variable is used in our PRISM models to deal with the exit of states. The extra exit variable, however, is not needed to deal with state exit. We could use the counters; in this example, we could set the value of scpc to the extra state numbers, such as s0_1, in the first command corresponding to a transition: the command on line #18 or #22, for example. The last command, such as that on line #28, then would set the counter to the state just after the exit from the source state, such as s0_3. The exit variables are, however, necessary to deal with composite states.
In the next example, in Fig. 24, we consider a transition t0 whose source state S0 is composite. The execution sequence of the transition starts with a request for S0 to exit. That state then passes the request into its inner states recursively. Upon receipt of an exit request, the innermost (simple) substate executes its exit action (if any). Afterwards, each enclosing state repeats this process up to the source state.
In Fig. 24, all states have an exit action and at least one outgoing transition. In exiting S0, the exit actions of its substates are executed sequentially: the exit action of S2, the exit action of S1, and the exit action of S0, if the current substate of S1 is S2, or the exit action of S3, the exit action of S1, Fig. 24 An example to illustrate the need of exit variables and the exit action of S0, if the current substate of S1 is S3. One possible approach to encode this uses sets of PRISM commands for each of the exiting paths, with corresponding guards to determine the current substates. This leads to duplication of extra states introduced by exit actions. In this example, the exit action of S1 is shared by both paths to exit. We could encode this by introducing an extra state in the beginning of the exit action, such as S1_exiting, and then the end of the encodings of the exit actions of S2 and S3 leads to S1_exiting. To use this approach, however, the encoding of the transition t0 needs to take into account the internal structure of S0. This is neither straightforward nor compositional.
Instead, we use a staged approach, in which the encoding of a transition (like t0) triggers an exit request to its source state (S0), and waits for it to exit. It is the encoding of the source state that reflects its internal structure. For this example, the commands for S0 deal with an exit request, relay the request to its current substate S1, and wait for S1 to exit. The commands for S1 are similar. The commands for S2 deal with the exit request from S1, execute its exit action, and exit S2 using the approach in Fig. 23 because S2 is simple. Afterwards, the command for S1 that waits for S2 to exit becomes enabled. After it is taken, the encodings for its exit action are executed, and so exit S1. In a similar way, the encoding for S0 controls its exit.
To control this exit flow in PRISM, we introduce an extra exit variable for each composite state, and define the exit of a composite state in six stages: EX-S1 it is not in an exit flow; EX-S2 it gets an exit request either from a transition or from its parent; EX-S3 it passes the exit request to its substates; EX-S4 it waits for its substates to exit; EX-S5 its substates have exited (at this point, its exit action is executed); and EX-S6 it is exited (after execution of its exit action).
To illustrate our approach to translating state machines with composite states, we present in Fig. 25 the module for the normalised machine movingSTM in Fig. 17, lines #34-#59. That module has two program counter variables: scpc and Move_scpc, one lock variable lock, and two exit variables: exit and Move_exit.
The counter scpc encodes the current state of the machine, while Move_scpc encodes the current state of the composite state Move. In the normalised machine mov-ingSTM, we have one initial junction named i0 and three states (Move, Stuck, and loop). Four constants are declared for these states (lines #17-#20). Extra constants declared on lines #21-#24 are needed for the actions in transitions or states. Since Move is composite, there are additional nodes within it: one initial junction named i0 in PRISM, nine states s0 to s8, and nine probabilistic junctions named p0 to p8 in PRISM. A set of constants is declared to associate them with numbers, as illustrated in Fig. 26. We name these constants with a prefix Move_ (see lines #26-#31). Like in the previous example, extra constants are also needed for the actions. In addition to the states, we also number the transitions in movingSTM, as shown in Fig. 26, with associated constants on lines #10-#16. We also name the transitions in Move with a prefix Move_. Besides LOCK_FREE on line #9, these are all the possible values that the variable lock can take as shown on line #37.
In addition, two exit variables exit and Move_exit are declared on lines #38 and #39. Both can take the values 0 to 6 of the constants: • Exit_NONE corresponds to EX-S1 above, • Exit_ACT_Parent corresponds to EX-S2 for the request from the parent state, if any, • Exit_ACT_Trans corresponds to EX-S2 for the request from a transition, • Exit_Sub_ACT corresponds to EX-S3, • Exit_Sub_ACT_Waiting corresponds to EX-S4, • Exit_Sub_EXITED corresponds to EX-S5, • Exit_EXITED corresponds to EX-S6.
In the initial state of the module movingSTM, the values of the local variables scpc and Move_scpc are i0 and Move_INACTIVE, which indicates the machine starts from its initial junction and the composite state Move is initially inactive. The initial value of lock is LOCK_FREE. The val- 25 The PRISM module of movingSTM ues of both exit variables are Exit_NONE, so no states are being exited. In the initial state, the single transition encoded on line #41 is available. So when the value of scpc is i0, it is changed to i0_1 and the value of lock is changed to T0. Since the value of lock is not LOCK_FREE, other transitions in the module that correspond to the transitions from a state in the machine are not available because they have a guard condition lock=LOCK_FREE.
When scpc is i0_1, the single transition encoded on line #42 is taken. The update changes the value of p, the position of the robot, to 0, which is the effect of the transition action in RoboChart, and the values of scpc and Move_scpc to Move and Move_i0.
According to the normalised machine in Fig. 17, if the current state is Move and the battery level is 0 when the robot is not in the charging station, the transition t1 from Move to Stuck in Fig. 26 is enabled. The encoding of this transi-tion is shown on line #44. When it is taken, the module is locked in T1 and the exit stage of Move is set to an exit request from a transition (Exit_ACT_Trans) to source state Move. The command on line #45 waits for Move to exit and is enabled only if the module is locked in T1 and Move has been exited (Exit_EXITED). When an exit request is recorded in Move_exit, the next available command is on lines #52-#53. Since Move is composite, the update changes Move_exit to Exit_Sub_ACT to request its substates to exit first. Depending on the current state of Move, different commands are available. If the current state of Move is s0 (that is, Move_scpc is Move_s0), the command on line #56 is enabled. Since s0 has no exit action, the update simply sets the exit procedure to the next stage: the substate of Move has been exited (Exit_Sub_EXITED). Similarly, if the current state of Move is s1, the command on line #57 After the substate is exited, the next available command is on line #54. Since Move has no exit action, the update records that the exit procedure of Move finished (Exit_EXITED), and at the same time, the counter of Move becomes Move_INACTIVE. Afterwards, the command on line #45 is available. The update changes the counter scpc to Stuck_entering, which records the start state of the entry action of Stuck. The next command on line #46 encodes the effect of the entry action (p is set to 9), the entering of the target state (the counter is at Stuck), and the completion of the transition t1 (the lock becomes LOCK_FREE).
Other transitions are encoded in a similar way, and therefore omitted in Fig. 25.
In Figs. 20, 23 and 25, we illustrate the encodings of transitions from initial junctions, states, and probabilistic junctions that have one single outgoing transition. We illustrate our approach when there are multiple transitions in Fig. 27, where we present the encodings of the incoming and outgoing transitions of the probabilistic junction p1 in Fig. 26.
The junction p1 is a node in the state Move with one incoming transition t2 from the state s1, and three outgoing transitions to the states s1, s2, and s4. Each of these outgoing transitions has an action that requires two extra states (because they are sequences of two basic actions). Along with the state for p1, there are seven states represented by the constants on lines #2-#8.
The command on lines #13-#14 encodes the transition from s1 to p1. The command on lines #17-#18 encodes the probabilistic choice and has three updates with equal probability 1/3. Each update changes the counter of Move (Move_scpc) to a state representing the start of one of the outgoing transition action. For example, the assignment in the first update changes Move_scpc to Move_p1_1, which represents the start of the action of the transition from p1 to s2 and is also annotated in Fig. 26. The commands on Next, we present the normalisation rules.

Normalisation rules
In terms of model transformations, normalisation is characterised as a rule-based, homogeneous, and declarative transformation. We present here a set of functions from a RoboChart model that satisfies our translation requirements to a RoboChart model in normal form. These functions are defined via rules.
To normalise a RoboChart model, we apply Rule 1 to each state machine. This is the rule applied exhaustively to all state machines in the normalisation process discussed previously. In the definition of all rules, we use the constructs from Z [70,72] as a meta-notation. Their syntax is summarised in Table 3.
Generally, a rule characterises a function on elements of the RoboChart metamodel. A rule definition is composed of a declaration, a body, and a where clause. The declaration gives the function name, its parameters (names and types), and its return type. In Rule 1, the function is [[-]] STM . It has one parameter stm of type StateMachineDef, that is, a state machine, and also returns a state machine: an element of the same type.
The body of a rule defines an object of the return type. For example, the body of Rule 1 is an object of the class StateMachineDef of the metamodel.
The variables used in the body may be parameters or may be defined in the where clause. The order of these definitions is not relevant.
The body of Rule 1 defines a state machine whose name, variable list, operations, events, and interfaces are the same as those of the parameter stm. The nodes and transitions, however, are different and are specified using the definitions from the where clause. The first four definitions are related to the four steps of the state machine normalisation process presented above.
(loopstates, looptrans) is a pair characterised by applying addLoopStateTrans to stm (see Rule 9 in "Appendix A"). This function is concerned with the possible need to introduce loop states. The result of addLoopStateTrans(stm) is a pair, whose first element loopstates is a set either empty or containing a new loop state for stm, and whose second element looptrans is a set of the new transitions to and from loop.
(remjuncs, deltrans, newtrans) is a triple of sets: a set of junctions, and two sets of transitions defined by an application of the function combTransJunctions. This function is concerned with the combination of incoming and outgoing transitions of normal junctions, if needed. The first argument of the application is a set of normal junctions, characterised by a function inTransCombinableJuncs (see Rule 10 in "Appendix A"). These are the normal junctions that have incoming and outgoing transitions that need to be combined. The second argument of the application is the set of transitions of stm that are to or from junctions in the first argument; this is characterised by a generalised union of a relational image. transpjunc is a set of pairs defined by applying splitTran (Rule 13 in "Appendix A") to each transition in stm (stm.transitions), to the new transitions identified by combTransJunctions (that is, in newtrans), and to the transitions from the new loop states (identified by looptrans), but not to the transitions removed by the normalisation (that is, in deltrans).
compstates is a set of normalised composite states resulting from the application of a normalisation function [[-]] S for states to each node n of the machine that is a state (n ∈ States) and has nodes itself (#(n.nodes) > 0). These are the composite states. Normalisation of composite states by [[-]] S is similar to that of state machines except that composite states do not declare variables, operations, and events. So the formalisation is simpler and omitted here; it can be found in the RoboChart reference manual [1].
intactnodes is the set of nodes n of stm that are neither the normal junctions removed by the normalisation in combTransJunctions (that is, remjuncs) nor composite states. They are unaffected by normalisation.
The nodes of the normalised machine, as defined in the body of Rule 1, include the loop states in loopstates, the new probabilistic junctions in the second element of each pair in transpjunc (obtained using generalised union ), the normalised composite states, and all other nodes as identified in intactnodes. The transitions of the normalised machine are just those in the first element of each pair in transpjunc.
Next, we present the second stage of translation from a RoboChart model in normal form to PRISM.

Transformation to PRISM
In this section, we present the translation rules used in our approach in Sects. 5.4.1 to 5.4.4.

Module, robotic platform, and controllers
The main translation function The result of the translation of the controllers is recorded in a set of quadruples ctrlrets, while that of the robotic platform is in a triple (rpconsts, rpvars, rpmodule). Each quadruple in ctrlrets records information about the translation of a controller. The first element of each quadruple r in ctrlrets, r.1, is a set of constants resulting from the translation of a controller. So the constants for the all controllers of m are combined using generalised union {r : ctrlrets • r.1} and contributed to constants. The second and third elements of r, r.2 and r.3, are sets of global variables and modules. They are combined using generalised union and contributed to globals and modules. Accordingly, rpconsts, rpvars, and rpmodule are a set of constants, a set of variables, and a module, contributed to constants, globals, and modules.
Additionally, a set of constants exitconsts is used to specify the control flow of execution of a state machine with composite states; in particular, the constants are useful to define the flow when exiting a composite state. This is discussed later on in Sect. 5.4.2.
The variables ctrlrets, rpconsts, rpvars, rpmodule, and exitconsts are defined in the where clause of Rule 2.
ctrlrets is a set of quadruples: sets of constants, variables, and modules, and a relation defined by an application of [[-]] C (Rule 4) to a controller in the set m.nodes of nodes of m. The relation establishes a mapping from operations provided by the platform and required by the controller, to PRISM actions corresponding to these operations.
rpoutevents is used in the translation of the robotic platform. It is the set of events of the robotic platform used to communicate data to a controller. These are the events c.efrom that are the source of a connection c in the set m.connections of connections of m whose source c.from is a platform and whose type c.efrom.type is not null. So, data (of type c.efrom.type) is communicated.
(rpconsts, rpvars, rpmodule) is a triple: a set of constants, a set of variables, and a module defined by an application of [[-]] R (Rule 3) for robotic platforms. This function is applied to the platform of m, identified by a unique (μ) node n that is in the set m.nodes of nodes of m and is a robotic platform. Extra arguments are the set of events rpoutevents and the relation from the translation of controllers, formed by generalised union of the relation r.4 for each controller. As said, the events used to send data to a controller are represented by a shared variable in the platform module. (Its value is nondeterministically chosen and copied in modules for state machines upon synchronisation.) So, the definition of the module for a platform requires the identification of these events, which are in the set rpoutevents. The relation identifies how the translation of the controllers (or, more specifically, of their state machines) have mapped their required operations to PRISM actions. The module for the platform synchronises on these actions.
exitconsts is a set of constants resulting from the function exitSeqCtrlConsts, omitted here.
In Fig. 19, the result of the translation of the unique controller of our example gives rise to the declaration of NoTask in the constants section and all modules except deliverRP. The declarations of two constants and two global variables in the constants and global sections and the module deliverRP are the result of the translation of the robotic platform. The constant NoTask is the result of the translation of the enumerated type FD in Fig. 4. More constants result from the translation of the controller, but are omitted in Fig. 19. The details are presented in Sects. 5.4.2 and 5.4.3. Figure 19 gives the module for deliverRP, and corresponding constants and global variables provided by it. As shown in Fig. 2, deliverRP provides two constants and two variables. Their counterparts in PRISM are two constants and two global variables, shown on lines #4-#7, of type int. The platform has two output events request and dest as identified from connections in deliverMOD in Fig. 2. Both events are of type nat, natural numbers. For each output event, we add an extra local variable of a corresponding type, such as EVT__request (on line #10 in Fig. 19) for request, and a set of commands with a corresponding action for the event name such as the commands indicated on lines #13-#15, to the module. Together, the commands characterise a nondeterministic choice of the value of the variable. Other events used for output are handled in a similar way.
As mentioned, [[-]] R defines a module like deliverRP; it has three parameters: a robotic platform rp, a set outevents of events of rp used for output, and a relation opmaps that maps operations provided by rp to PRISM actions. In Rule 3, we note the type of rp is RoboticPlatformDef, not RoboticPlatform used in Rule 2. The class RoboticPlatform is inherited by both RoboticPlatformDef and RoboticPlat-formRef. So the robotic platform identified in Rule 2 is either a RoboticPlatformDef or a RoboticPlatformRef object. For a RoboticPlatformRef rp, another rule specifies its result just as the function application [[rp.ref]] R (the unique identifiers defined by id(n) -see Table 3 -take references into account). Rules for ControllerRef and StateMachineRef are similar and omitted here.
The result of [[rp, outevents, opmaps]] R is a triple, whose first and second elements are a set of constants ( {r : constvars • r.1} where r is a pair of sets of constants and variables) and a set of variables ( {r : constvars • r.2}) defined by the constants and variables constvars (a set of pairs) provided by rp, and whose third element is the PRISM module corresponding to rp. The variables constvars and module are defined in the where clause of Rule 3 and described below.
constvars is a set of pairs of sets. The first and second elements of each pair are a set of constants and a set of variables, translated from each variable list vl in rp by the function [[vl]] VL (omitted here). The lists of variables provided by rp are identified using the function getVariableLists whose definition is omitted here. A variable list consists of a set of constant and variable declarations. The translation of variable declarations maps the RoboChart types to the PRISM types, and translates the initial value given, if any, accordingly.
localvars is a set of PRISM declarations of variables like EVT__request corresponding to the events e from outevents. In the rules, we use black typewriter font, like in true, for PRISM terms. They are abbreviations for instances of the classes of the PRISM metamodel presented in Sect. 4.2. For clarity, however, we use the PRISM concrete syntax to represent them. Each declaration in localvars is for a variable, whose name is based on the name of e in PRISM (id(e)) with a prefix (EVT__), and whose type [[e.type]] t is obtained by translating the type e.type of e using eventcmds is a set of sets of commands for each event e of rp, that are identified using the function getEvents whose definition is omitted here. If e is an output event (that is, e ∈ outevents), a set of commands is included in eventcmds to define a nondeterministic choice of the values for the corresponding variable EVT__id(e). Each command corresponds to one possible value v in the event type [[e.type]] t . The action of the command (inside square brackets) is the name id(e) of the event e, the guard is true, and the only update (between → and ;) assigns v to EVT__id(e). The commands on lines #13-#15 in Fig. 19 are obtained in this way. If e is not an event for output, a set containing one command is included in eventcmds. It has id(e) for its action and true for both its guard and its updates, which means the command is always ready for synchronisation on the action and no variable is changed upon synchronisation. The command on line #18 is obtained in this way.
opcmds is a set of PRISM commands. Each command corresponds to one PRISM action act in the range ran opmaps of the relation opmaps. As previously mentioned, opmaps records a mapping from operations provided by the robotic platform (and possibly called in state machines) to PRISM actions corresponding to these operations. We use this relation to translate calls to the operations in state machines into communications with the environment (modelled by the module for the robotic platform) that provides the operations. Our PRISM models, as explained in Sect. 4, rely on the name of actions for synchronisation. This imposes extra challenges on modelling of operations in PRISM because the calls to a same operation from different state machines must not be synchronised. We consider, for instance, an example in which an operation moveSteps with a parameter of type int is provided by the robotic platform, and required and called using an action moveSteps(1) in a state machine stm1 and moveStep(2) in another state machine stm2. The operation calls are translated to communications in PRISM through synchronisation on actions with assistance of variables. If two calls were mapped into an action of the same name such as moveSteps_act, then both state machines and the robotic platform would synchronise on this action, which is not the right semantics of operation calls. For this reason, we allocate a unique action name for an operation in each state machine, such as stm1_moveSteps_act for stm1 and stm2_moveSteps_act for stm2. So in the platform, an operation is mapped to several actions: one for each machine that requires the operation. For this example, opmaps is given below.
Since the mapping is established in the state machines, the relation is a result of the translation of controllers (which involves translating their machines) and passed to [[-]] R . For each action act in the range of opmaps (for our example, {stm1_moveSteps_act, stm2_moveSteps_act}), one command, whose action is act, is included in opcmds. This command in the platform module synchronises with the commands in a machine module whose action is also act, to allow the environment to record the calls to the operation. The arguments of these calls are recorded in local variables of the machine modules. The details of the declaration and use of these variables are presented in Rule 5. Both the guard and the updates of the command are true, so the platform module cannot refuse synchronisation on act and no variable is changed upon synchronisation. For our example, opcmds contains the commands in Fig. 28. They allow the platform module to record the call to moveSteps from both stm1 and stm2, though in different actions. module is a PRISM module with the name id(rp) of rp, localvars, and commands obtained by the generalised union of the commands in eventcmds and opcmds.
The modules in Fig. 19 other than deliverRP are defined by the function [[-]] C for a controller ctrl Rule 4. The result is a quadruple: a set of constant declarations, a set of variable declarations, a set of modules, and a relation from the operations provided by the platform and required by the machines in the controller to corresponding PRISM actions. For the moveSteps example, if both stm1 and stm2 are in ctrl, then the resulting relation is the one shown in (1). Analogous to Rule 3, we define constvars in the where clause to record the constants and variables provided by ctrl. Fig. 28 The commands in opcmds The results of the translation of all state machines of ctrl are recorded in a set of pairs stmrets, also defined in the where clause. Each pair corresponds to one state machine and includes a set of constants and a module. The constants in these pairs are combined using generalised union and are also contributed to the result of [[-]] C . Additionally, the relation is recorded in rops.
Each pair in stmrets is the result of the translation of one state machine stm in the set of machines ctrl.machines of ctrl by the function [[-]] STM (Rule 5), as defined in the where clause. The function application takes two arguments: the state machine stm and a set stmoutevents of events of stm used for output. The set stmoutevents includes events of the state machine used to communicate data to the controller or to another state machine in the controller. These are the events c.efrom that are the source of a connection c in the set ctrl.connections of connections of ctrl whose source c.from is stm and whose type c.efrom.type is not null. So data (of type c.efrom.type) is communicated. These events are used in the definition of [[-]] STM to identify variables that need to be included in the module for stm to assist communications. We consider, for instance, a state machine stm1 with one event out used for output. So stmoutevents, in this case, has one element out. The module for stm1, translated by [[ stm1, {out}]] STM , therefore has a local variable EVT__out of the same type as out for the purpose of communications.
The relation rops is also defined in the where clause. It is the result of combining the relations established for state machines by the function op2ActionMaps (Rule 14 in "Appendix A"), using generalised union. The function op2ActionMaps takes one argument: a state machine stm in the set of machines ctrl.machines of ctrl.
Next, we describe how to translate state machines.

State machines and composite states
Here, we present the rule that can be used to translate a RoboChart state machine to PRISM.
Each machine module in Fig. 19, such as taskSTM and movingSTM in Figs. 20 and 25, is defined by the function [[-]] STM in Rule 5. As mentioned previously, this function is concerned with the translation of a state machine stm, having a set outevents of events of stm used for output as an extra parameter. Its result is a pair: a set of constants and a module.
Analogous to Rule 3, we define constvars as a set of pairs to record the constants and variables required by or defined in stm. The first element r.1 of each pair r in constvars is a set of constant declarations and the second element r.2 is a set of variable declarations. Generalised union combines all these sets. A constant, named id(stm)_LOCK_FREE, such as LOCK_FREE on line #5 in Fig. 20, is associated with 0 and results from the translation of stm. Rule 5 uses id(stm) as a prefix for the constant or variable names to ensure unicity. Other constants, such as those on lines #5-#10, for the values that lock can take, and on lines #12-#23, for the states in taskSTM, are recorded in stmconsts.
The machine module is named id(stm) and contains variable declarations and commands. The variables include lock, whose type is an interval with upper limit trnumber − 1, such as that on line #27 in Fig. 20; the local variables of stm, like fd and g on lines #28-#29, as recorded in the second element r.2 of pairs r in constvars, and combined using generalised union; the variables to encode communi-cation through the events in outevents, in outeventvars; the scpc and exit variables, like those on lines #35-#39 in Fig. 25, as recorded in stmvars; and the variables to encode the arguments of calls to the operations required by stm, in ropsvars. The set of commands is recorded in stmcmds.
The where clause in the rule gives more details. outeventvars is a set of PRISM declarations of variables (similar to EVT__request for the robotic platform) corresponding to the events e from outevents. Each declaration in outeventvars is for a variable whose name is based on the name of e in PRISM (id(e)) with a prefix (EVT__), and whose type [[e.type]] t is obtained by translating the type e.type of e using the function [[-]] t .
(trnumber, stmconsts, stmvars, stmcmds) is a quadruple of an integer, and sets of constants, variables, and commands, resulting from the application of [[-]] S (Rule 6) to stm to translate its nodes and transitions. This function is concerned with the translation of a Node-Container (a state machine or composite state) given as its first argument, with the machine that owns the NodeContainer as its second argument. An extra third argument is a set of boolean expressions that records the containers for the node and defines the guard for the commands that encode the node. The guard is the conjunction of these expressions, which are equalities involving the counter variables that, together, indicate that the control flow has reached the node. For example, to translate Move in movingSTM using this function, the right argument is { scpc=Move } to indicate the control flow has reached Move. If Move has another composite substate S, then the right argument to translate S is { scpc=Move, Move_scpc=Move_S } to indicate the control flow has reached both Move and S. The corresponding guard is scpc=Move & Move_scpc= Move_S, the conjunction of both expressions. A final argument for [[-]] S indicates the first integer not yet used to declare a constant for a lock value. In Rule 5, [[-]] S is applied to the whole machine stm, which, by convention, is owned by itself. The third argument is just ∅, because the control flow is always in the machine. Finally, the final argument indicates that declarations of lock variables can use integers from 1. (We recall that 0 is used for the LOCK_FREE constant.) As a result of this function application, trnumber is the next available number that can be used to number a transition. So the maximum transition number is trnumber − 1, which is used for the upper limit of the interval type of the lock variable. For the taskSTM module in Fig. 20, the next available transition number is 6 because the numbers 1 to 5 are used in the declarations on lines #5-#10. The second and third elements identify sets of constant and variable declarations, like those on lines #6-#23 and the scpc declaration on line #26. These are the constants and variables used in the encoding of the control flow of the node. The fourth element is the set of all commands in the module.
ropsvars is a set of variable declarations for each parameter p of an operation op required by stm. The variable has a fresh name uname(stm, op.name, p.name) and is of type [[p.type]] t obtained by translating the type p.type of p using the function In Rule 6, the parameters for [[-]] S are a NodeContainer cs, the state machine stm containing cs, a set of PRISM expressions pcconstrs recording constraints on the program counters, and the next number trnumber that can be used to define a constant for a transition.
As illustrated in Fig. 25, the translation of a NodeContainer cs such as Move introduces a) one program counter variable and one exit variable; b) the encoding for exiting cs, such as the commands on lines #52-#54; c) the encoding for exiting the substates of cs, such as the commands on lines #48-#51, #56, and #57; d) the encoding for entering the substates of cs that have entry actions, such as the command on line #46; e) the encoding for the transitions of cs, such as the commands on lines #42; and f) the encoding for the composite substates of cs. There may also be constant declarations, such as those on lines #9-#31.
In the definition of [[-]] S , the declarations of the program counter and the exit variable are recorded in scpc and exit. The encoding for exiting cs, and exiting and entering the substates of cs are recorded in triples (exitcsstnumber, exitcsconsts, exitcscmds), (exitsubstnumber, exitsubconsts, exitsubcmds), and (entersubstnumber, entersubconsts, entersubcmds). The first element of each of these triples is the next available number for the states of the resulting module, such as the numbers associated with the states on lines #17-#24 in Fig. 25. The second element is a set of constants associated with the states introduced. The third element is a set of commands. The translation of the transitions in cs is recorded in a quadruple (tnsstnumber, tnstrnumber, tnsconsts, tnscmds). Finally, the encodings for the composite substates of cs are, as defined by recursion, recorded in a quadruple (sstrnumber, ssconsts, ssvars, sscmds).
The result of [[-]] S is a quadruple, whose first element is the next available transition number after the translation of cs and recorded in sstrnumber. The second element of the quadruple is a set of constant declarations including the constant const0 denoting an inactive state, such as the one on line #35 in Fig. 25, the constants in exitcsconsts, exitsubconsts, entersubconsts, nodesconsts, and ssconsts, and the constants in tnsconsts. The third element of the quadruple is a set of variable declarations including scpc, exit, and the variable declarations in the third element of ssvars. The fourth element of the quadruple is a set of commands including the commands in exitcscmds, exitsubcmds, entersubcmds, tnscmds and sscmds.
The where clause in Rule 6 gives more details about the variables in these definitions.
const0 declares a PRISM constant associated with number 0 and representing the inactive status of cs.
scpc declares the program counter variable for cs; its type is a range from 0 to the maximum state number (that is, tnsstnumber − 1). If cs is a machine, the counter is set to a state in PRISM corresponding to the initial junction i0 (that is, a node n of cs that is initial, n ∈ Initial) identified by id(i0), the name of i0 in PRISM. Otherwise, cs is a composite state and inactive initially. So the counter is set to const0.
exit is the declaration of the exit variable for cs. (exitcsstnumber, exitcsconsts, exitcscmds) is a triple containing a state number, a set of constants, and a set of commands to record the exit of cs. The first element exitcsstnumber is the first state number available. Examples include the numbers on lines #17-#24 in Fig. 25, for the state machine, and on lines #27-#31, for Move. If cs is a state machine (cs ∈ StateMachineDef), there is no need for it to exit, and, therefore, the state number is 1 to record the use of 0 for const0, making 1 the next available number for states, and the sets of constants and commands are empty (∅). Otherwise, the triple is defined by an application of the function exitCompState (omitted here) , which is used to generate the two commands of the module on lines #52-#54 of Fig. 25. More constants and commands might result if cs has an exit action. Its third argument is the name of scpc (that is, id(cs)_scpc). Its last argument 1 is the next available state number.
(exitsubstnumber, exitsubconsts, exitsubcmds) is also a triple defined by the application of the function exitSubstates (whose definition is omitted here). This function is concerned with the encoding of the exit of all substates (that is, all the subnodes s of cs.nodes of cs that are States). The fifth argument of the application is the next available state number as recorded in exitcsstnumber. The first element exitsubstnumber is the new available number. The second element exitsubconsts and the third element exitsubcmds are sets of constants and commands encoding the exit of these substates. This function is used to generate the commands on lines #26-#28 and the related constants on lines #9-#10 in Fig. 23 for exiting the state s0 in Fig. 22, and the commands on lines #48-#51 in Fig. 25 for exiting the state Move in Fig. 17.
(entersubstnumber, entersubconsts, entersubcmds) is a triple defined by applying enterSubstates (omitted) to a set of states that have an entry action (that is, whose action getEntryAction(s) is not null). The fourth argument of the application is the next available state number, exitsubstnumber. The first element entersubstnumber is the new state number, and entersubconsts and entersubcmds are sets of constants and commands used to encode the entering of these substates. This function is used for example, to generate the command on line #46 in Fig. 25 for entering the simple state Stuck in Fig. 17.
(nodesstnumber, nodesconsts) is a pair defined by the application of constantsOfNamedElems to all subnodes cs.nodes of cs and to the current available state number (entersubstnumber). This function characterises a set of constants (in nodesconsts) representing states in PRISM that correspond to subnodes of cs like i0, taskState, and p0 in the module in Fig. 20. The first element nodesstnumber is the new state number.
(tnsstnumber, tnstrnumber, tnsconsts, tnscmds) is a quadruple of the next available state and transition numbers, a set of constants, and a set of commands resulting from the translation of the transitions from the nodes cs.nodes of cs by the application of Next, we discuss how to translate transitions from RoboChart to PRISM and present the rule to do that. The function [[-]] TN has eight parameters: n is the node that identifies the transitions to be translated, namely, those with n as a source; cs is the parent of n, either a state machine or a state, of class NodeContainer; stm is the state machine containing n; exit is the declaration of the exit variable for cs; scpcname is the name of the program counter variable for cs; pcconstrs is a set of PRISM boolean expressions on the counter variables to identify the control of stm at cs; stnumber is the next available number for a state; and trnumber is the next available number for a transition.

Transitions
In Rule 7, the result of translating transitions from n is defined in the where clause as a quadruple (tsstnumber, tsconsts, tsupdates, tscmds). The first element tsstnumber is the new next available state number; tsconsts is a set of constants corresponding to the extra states for the actions of the transitions, such as those on lines #3-#8 in Fig. 27; tsupdates is a set of updates that capture the probabilities of the outgoing transitions, such as the three updates on line #18; and tscmds is a set of commands for the actions of the outgoing transitions, such as the six commands on lines #19-#24.  ] T also gives rise to an update: for our example, the three updates on line #18 for the three transitions from p1 to s1, s2, and s4. cmd is a command in PRISM encoding the choice made at n probabilistically. Its guard ensures that the counter variables indicate that the current state is that identified by the node n. We have a conjunction of two terms. The first, andExprs(pcconstrs), is itself a conjunction of the boolean expressions in the argument pcconstrs, which are equalities regarding the counter variables for all states and machine containing n. The second conjunct requires that the counter variable for the state or machine containing n, whose name is given by the argument scpcname, has the value id(n) for the probabilistic junction identified by n. The updates of cmd are those in the set tsupdates.

Rule 8 defines [[-]]
T , which is concerned with the translation of a transition t, when its source n is a probabilistic junction. Since t has no trigger or guard, its translation is the result (astnumber, aconsts, aassigns, acmds) of encoding its action t.action and the entering in its target t.target.
Precisely, the result of [[-]] T is a quintuple, whose first element is the next available state number after the translation of t as recorded in astnumber. The second element is the next available transition number: the argument trnumber. The third and fifth elements are sets of constants and commands resulting from the translation of t.action. The fourth element is a set containing only one update whose probability is the translation of the probability t.probability of t by [[-]]e, and whose assignments are the set of assignments resulting from the translation of t.action that updates the counter to the start state for the encoding of the action.
target is the name of the constant representing the final state in PRISM for the encoding of the action t.action. If the target t.target of t is a state with an entry action, the encoding of t.action leads to the start state of that entry action, represented by the constant named id(t.target)_entering, such as Move_s2_entering in Fig. 27. Otherwise, target is just the identifier id(t.target) of t.target in PRISM.
targetassigns is a set of assignments to encode entering the target of t when it is a state without entry action. If it is a composite state, we need to update the counter variable id(t.target)_scpc of that state to the constant representing its initial junction getInitial(t.target). If the target is a simple state, t is completed by entering its target, and so the lock variable id(stm)_lock is set to be free id(stm)_LOCK_FREE.
(astnumber, aconsts, aassigns, acmds) is a quadruple defined by application of [[-]] A to the action t.action of t. The fifth argument null of this function application means the start state of the encoding of t.action is not specified, and so its translation generates a fresh name for the constant for that state. For the action of the transition from p1 to s2 in Fig. 26, the constant to encode its start state in PRISM is Move_p1_1. The sixth argument is a set of PRISM assignments containing an update of the counter scpcname for the state or machine of the action to target and targetassigns.
Next, we discuss how to translate actions in RoboChart to PRISM and the definition of [[-]] A .

Actions
Previously in Fig. 20, we show that the action of t2 in Fig. 21 is modelled by five commands shown on lines #37-#41, and the action of t3 is modelled by two commands shown on lines #44-#45. Generally, an action in RoboChart is modelled by a set of commands with a set of corresponding constants to represent extra states required to encode state change in PRISM.
We The complete set of translation rules, covering all forms of action, is available in [1]. Next, we present RoboTool, which implements our translation.

Automatic model generation
RoboTool 5 supports modelling, validation, and automatic generation of mathematical definitions of RoboChart models written in CSP for use of FDR. We describe here our work extending RoboTool to generate PRISM models automatically: a set of Eclipse plugins 6 that provide textual and graphical modelling tools using the Eclipse Modeling framework (EMF). 7 We have extended RoboTool's validation facilities with checks of the well-formedness conditions in Sect. 3.3. Fig. 29 shows as an example the implementation for the condition PJ3. The code uses Xtend, 8 a dialect of Java. The method junctionWFC_PJ3 has a probabilistic junction j as parameter. It iterates over all transitions in the parent (machine or composite state) of j, whose source node is j. These are all outgoing transitions of j. The loop adds the probabilities of these transitions into an array. Afterwards, the method sumExprEq1 is called to evaluate whether the sum is 1. If not (sumExprEq1 returns false), RoboTool displays a warning. This check works for probabilities defined by a number, but not more general expressions. In general, checking PJ3 requires theorem proving.
The RoboChart PRISM Generator plugin implements the rules from Sect. 5. The implementation of the rules is the way in which models are generated automatically. The implementation uses Epsilon, 9 which provides a collection of languages and tools to support tool development. The first stage of the translation, normalisation, uses the Epsilon Object Language (EOL) 10   The transformation of a RoboChart model produces a model in the PRISM metamodel. To generate the textual model accepted by PRISM from the metamodel, we use the Epsilon Generation Language (EGL), 12 a template-based language tailored for model-to-text transformation. In the next section, we describe RoboTool facilities for verification using the PRISM model generated automatically.

Verification support
PRISM verifies properties defined in probabilistic temporal logics. To improve usability, especially for those without experience with PRISM, we have defined and implemented a property language, called RoboCert. We can specify both properties in CSP (then verify these properties against the standard RoboChart model using FDR) and probabilistic properties in temporal logics (LTL, CTL and PCTL), then verify them against the generated PRISM model using PRISM. In Sect. 7.1, we present examples for the mail delivery robot. The syntax of constructs for the probabilistic properties is summarised in Sect. 7.2. The RoboTool implementation is described in Sect. 7.3.

Constructs and examples
We present below examples of RoboCert statements, in the context of the module deliverMOD in Fig. 2.
A probabilistic property contains a probabilistic formula with an optional constant configuration to assign the constants that are either declared in the property file or from the RoboChart model with specific values. We can also define multiple constant configurations for a property, illustrated by Example 3. This feature is useful for design-space exploration (DSE) by analysing multiple designs simultaneously.

¦ ¥
In Example 3, we declare an integer constant x and then use it in the property P_stuck_loc, which quantitatively measures the probability (Prob=?) for the robot to run out of power (c=0) in p identified by x, when batteryCapacity and chargeStep are set to 20 and 4, and x ranges from 1 to 8 (where 1:8:1 denotes a set of integers that is between 1 to 8 inclusive). RoboCert also supports labels and formulas. A label is a boolean expression, while a formula can be any expression. Example 4 illustrates the usage of labels.

¦ ¥
The reward nbmove assigns 1 to each synchronisation over the move event from the machine referenced by stm_ref0 . In the property, the reward operator uses nbmove to state the average number of synchronisations over move when the robot runs out of power. Both probability and reward properties support statistical model checking in addition to probabilistic model checking. Statistical model checking uses sample-based discrete-event simulation as in Example 6.

Example 6 (Simulation)
§ ¤  Ratio Test). Information about these methods can be found online. 13

Syntax
The BNF syntax of the probabilistic constructs of RoboCert is sketched in Fig. 30.
There are six types of statements (ProbStatement) to specify probabilistic properties: constant declarations (ConstDecl), and configurations (Constants), label (Label ), formula (Formula), and reward definitions (Rewards), and probabilistic properties (ProbProperty). 13 www.prismmodelchecker.org/manual/RunningPRISM/ StatisticalModelChecking. A ConstDecl associates a constant name (N) to a RoboChart type (Type). We reuse Type in RoboChart and omit its rule here. The constants that are either declared in the property file or from the RoboChart model are configured via constructs defined on lines #4-#9 in Fig. 30. A configuration name is given and various constants (identified by QualifiedNameToElement) are set to specified values (Expr). QualifiedNameToElement on line #40 uniquely identifies a RoboChart model element through fully qualified names. In the configuration rule on line #8, the value of a constant can be chosen from a set (ConstSetExpr) that are defined by either an extension such as {1,2} or an integer interval such as a:b:c for integers ranging from a to b by step c.
The production rules for labels, formulas, and rewards as shown on lines #10-#13 are straightforward.
A probabilistic property has a name (N), and a probability formula (ProbFormula) under specific constant configurations (defined by a ConstConfigs or a reference to an existing configuration by N). A property may also have associated command options (STRING), which are passed to the PRISM tool directly.
A probability formula can be a boolean expression (BoolExpr), or a state formula (StateFormula), or a composition of two state formulas by logic conjunction, disjunction, implication, or biconditional. A state formula can refer to a defined label name enclosed within a string (at line #22), or could be a negation of another state formula, or a probability measure with a bound (Bound) or a quantitative measure (Query), or a reward measure, or a CTL universal or existential quantifier over paths. A probability measure is over a path formula (PathFormula), while a reward measure is over a reward path formula (RPathFormula). Path formulas include general LTL operators, but with optional bounded variants, where an additional time bound is imposed on the property being satisfied. Reward path formulas specify different types of reward properties: reachability rewards, cumulative rewards, total rewards, or instantaneous rewards.
Both probability and reward measures support statistical as well as probabilistic model checking. Statistical model checking uses sample-based discrete-event simulation. A state formula can specify the simulation methods to be used (UseMethod), and a simulation method is configured using SimMethod.

A RoboCert plugin in RoboTool
A plugin is available in RoboTool to generate PRISM properties from RoboCert properties. The plugin accepts a property file, parses it, translates constructors in the file to their counterparts in the PRISM property specification language or the PRISM model language, and finally generates a PRISM property file. The plugin provides a modelling environment to edit properties with syntax and error highlighting. It also has content assist through scoping for qualified names.
Translated formulas and rewards are part of PRISM models, instead of property files. Therefore, we need to update the translated PRISM model. The plugin adds the formula and reward definitions from the properties to the PRISM model, and generates the corresponding PRISM properties. RoboTool then runs multiple instances of the PRISM command line tool to verify the generated properties in parallel.
Upon a successful verification, results are shown in a report. Otherwise, error messages indicate problems in the model or properties. The plugin translates the elements in error messages from PRISM back to RoboChart. This improves traceability of errors and results. Counterexam-ples found by PRISM can be linked back to the original RoboChart model.
RoboTool has been used in the verification of several examples 14 using both probabilistic and statistical model checking. They show that the translation time does not add burden to the verification: a couple of seconds, for verifications that take minutes.

Conclusions and future work
Previous work [2] has shown modelling and verification of functional behaviour using RoboChart and RoboTool. This work covers its extension for probabilistic modelling and verification. We have introduced a new construct, probabilistic junctions, for modelling of probabilistic software systems. This new construct impose extra well-formedness conditions. We have extended RoboTool to support modelling of probabilistic systems, including checking of these conditions.
We have derived a metamodel for PRISM and developed and formalised a probabilistic semantics of RoboChart in PRISM. It covers the most challenging constructs of hierarchical state machines and the component model of RoboChart covering parallel controllers.
We have developed support for automatic verification of probabilistic RoboChart models by translating them to the PRISM notation, and then using the PRISM model checker. The translation is in two steps, normalisation of RoboChart models and transformation of normalised models to PRISM. We have formalised and presented here both steps. The translation is automated in RoboTool, and so PRISM models can be generated from RoboChart models automatically.
We have also extended the standard property language [1, Section 5.1] in RoboTool and developed probabilistic property constructs. We have based this on the PRISM property language, but favour a controlled natural language syntax. We use qualified names for references to RoboChart elements. These names are also used in error logs from model checking. This makes model checking tools transparent to RoboTool users. The property language allows RoboTool to verify each property using one instance of PRISM. For instance, RoboTool uses 10 PRISM instances to verify 10 properties in parallel. This reduces model checking time (to the longest checking time of a property).
The translation presented in this paper cannot deal with all features in RoboChart, and our immediate future work is to extend it in order to overcome current limitations. The extension includes support of time primitives, asynchronous connections, operations defined in controllers, during actions, and richer abstract data types to relax TR-TY1 and corresponding expressions. The most significant restric-tion is the handling of time primitives. The other restrictions just require an additional encoding. Regarding time, our translation is restricted to models that correspond to the Markov models we use (DTMCs and MDPs). RoboChart has a more sophisticated model of time that complements this basic model, and translation of this richer time model is our future work. Many robotic models, however, do not require the super-dense model of time that results from combining the two time-models. So our work caters for many robotic applications.
For the examples we have considered so far, the transformations take a couple of seconds. We do not expect that it raises issues of scalability. Larger case studies and physical modelling are our future work.
The translation defined in this paper is unidirectional from RoboChart to PRISM. It is also feasible to define a translation from PRISM to RoboChart; this is actually not very challenging when compared to the translation defined here. This is also part of our future work to form a bidirectional translation.
It is possible to verify generated PRISM models using other model checkers that accept the same notation, such as Storm and MRMC. Use of other tools that accept different languages, such as the MODEST Toolset, requires different translations. They can, however, capitalise on the normalisation defined here, since it simplifies the structure of models.
RoboChart supports verification of robotic systems by model checking, but the long-term plan is combined use of model checking and theorem proving to deal with larger models and collections. Our immediate future work is to establish a link between model checking and theorem proving in order to verify probabilistic systems in RoboChart complementary. One scenario is to verify a RoboChart model using both model checking and theorem proving, and then compare their results. Another scenario is to use theorem proving as a guaranteed simplifier to simplify part of a RoboChart model (such as state machines, transitions, and states) in order to reduce the complexity for model checking. This could improve model checking performance dramatically.
To support theorem proving, and to connect RoboChart's CSP and PRISM semantics, we are pursuing a unifying theory of CSP and PRISM. This is based on Hoare and He's Unifying Theories of Programming [4]. In [14], we define the probabilistic semantics of the RoboChart action language in a new theory, and use the weakest completion technique [15] to embed the theory of designs [4,73] (for total correctness) in the probabilistic semantic domain. We call this new theory this theory of probabilistic designs. We are mechanising the theory in Isabelle/UTP. This allows us to analyse non-reactive RoboChart models. Our next step is to develop a reactive probabilistic design semantics. Our proof technique is to use reactive relations and Kleene algebra-based verification of reactive programs [74] to calculate contracts for RoboChart models.
With mechanised reactive probabilistic designs semantics, we have a UTP semantics for DTMCs and MDPs (then for PRISM). With that, given that CSP also has a theory of reactive designs, RoboChart and PRISM will then have the same semantic foundation, and we can establish soundness of our transformation with respect to the CSP work.
Using reactive probabilistic designs, we can calculate contracts for RoboChart. Those cut unnecessary internal states and variables generated during transformation. This reduces the state space size of transformed models and will improve model checking performance.
In addition to RoboChart, we are also developing tools and techniques that make use of RoboChart to generate robotic simulations and tests automatically. After these lines of future work are complete, formal studies on usability of these tools and techniques in the robotics domain can be conducted.
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecomm ons.org/licenses/by/4.0/.

A.1 Normalisation
The function addLoopStateTrans defined in Rule 9 deals with a machine in which there are states having no outgoing transitions. So that the model does not satisfy NFM-1. This function specifies a new loop state and corresponding transitions from the original states to the loop state.
The first parameter of the function is a NodeContainer, the parent class of both StateMachineDef and State. So this function is applicable to both state machine definitions such as stm in Rule 1, and composite states. If the NodeContainer has one or more nodes n that have no outgoing transitions (∀t : stm.transitions • t.source = n) , then the result is a pair formed by the set {loopstate} containing a new state loopstate, and a set of transitions ({looptran} ∪ newtrans) including a self-transition looptrans for loopstate and transitions in newtrans from the states without outgoing transitions to loopstate. Otherwise, there is no need to introduce loop, and the result is a pair of empty sets. The where clause of the rule has three definitions explained below.
loopstate is a new state specified by a function newState with a fresh name specified by uname(stm, "loop"). The function newState(name) characterises a State whose name takes the value name, but whose nodes, transitions, and actions are empty. So, it is a simple state without transitions or actions. We note that it is possible to directly define what newState specifies using a class instantiation name · · · State . We define newState, however, to facilitate reuse and hide other fields of the class State that are set to empty or null for simplicity. The introduction of the function newTransition is similar.
looptran is a new self-transition for loopstate, defined by a function newTransition with three parameters: the name, the source, and the target of the new transition. Other components of the transitions are null: it has no label.
newtrans is a set of new transitions. For each state n without any outgoing transitions, this set includes one transition from n to the new state loopstate.
If a transition from a state or a normal junction to a normal junction has no action, the model does not satisfy NFM-2. Such a transition, however, can be combined with outgoing transitions from its target normal junction. We identify these transitions as combinable transitions through a function isCombinableTran defined by Rule 11. In a state machine, all normal junctions that have at least one combinable incoming transition are identified by a function inTransCombinableJuncs defined in Rule 10. Such a normal junction and its incoming and outgoing transitions are then combined by a function combTransJunctions defined in Rule 12. Details of these rules are explained next.
The function inTransCombinableJuncs takes a state machine as argument, and identifies a subset of its nodes n. They are normal junctions, that is, junctions (n ∈ Junction), but not initial (n / ∈ Initial) and not probabilistic (n / ∈ ProbJunc), and at least one transition t among their incoming transitions (t.target = n) needs to be combined.
As already mentioned, the need to combine a transition t is characterised by isCombinableTran defined by Rule 11. Such transition has no action (t.action = null) and its source node t.source is not an initial or probabilistic junction.
The function combTransJunctions has two parameters: juncs is a set of normal junctions whose incoming transitions can be combined with outgoing transitions, and trans is a set of incoming and outgoing transitions of these normal junctions. If juncs is empty, then the result is just a triple of empty sets, because there are no transitions to be combined, and so no junctions or transitions to be removed, and no new transitions. Otherwise, the result is basically the cumulative result of applying the function combTransJunction to each junction. We omit the definition of combTransJunctions here, but the complete set of rules can be found in [1].
The function combTransJunction defined in Rule 12 has two parameters: a normal junction j and the set of its incoming and outgoing transitions trans. If the set intransother of incoming transitions of j that cannot be combined is not empty, then the result is a triple containing the empty set, because j is not removed, the set intranscomb of the incoming transitions that can be combined, and do need to be removed, and the set newtrans of the transitions resulting from the combination. Otherwise, the resulting triple includes {j}, so that j is removed, the set trans, so that all transitions to and from j are removed, and the set of new transitions newtrans. All the sets are defined in the where clause.
intranscomb is a set of incoming transitions t of j that can be combined (and so removed). This is characterised by isCombinableTran(t).
intransother has all other incoming transitions of j. outtrans is the set of outgoing transitions from j. newtrans is a set of new transitions that combine each incoming transition ti from intranscomb and each outgoing transition tj from outtrans. The new transition has a unique name uname(ti, tj.name), the same source as ti, the same target of tj, the trigger of ti, and the action of tj. The condition is the conjunction of that of ti and that of tj.
If a transition has a trigger and an action, the model does not satisfy NFM-3. We, therefore, define splitTran in Rule 13 to define the result of splitting such a transition into two transitions connected via a new probabilistic junction.
The function splitTran defines the normalisation of a transition t with a trigger and an action. In this case, the transition is split into two transitions connected via a new probabilistic junction pj, defined in the where clause to have a unique name uname(t, "sp_pj"). The result of splitTran(t) is a pair including the two new transitions, and the new junction {pj}. In the set of transitions, we have a transition to pj, and a transition from pj. The transition to pj has the trigger and the condition of t, and the outgoing transition has the action of t and a probability value 1. If t does not have both a trigger and an action, the result is the set containing t itself, and the empty set, since no new junction is needed.

A.2 Transformation to PRISM
Rule 14 defines the function op2ActionMaps used in Rule 4. It has one parameter: stm of type StateMachineDef, and characterises a relation from operations to PRISM actions. This relation establishes a mapping from each operation op in the operations getRequiredOperations(stm) required by stm to a PRISM action with a fresh name specified by uname(stm, op.name). (We recall that this is used to collect information about how operations are used in each machine, so that they can be encoded in the platform module.) For the previously discussed operation moveSteps in Sect. 5.4.1, the result is {moveSteps → stm_moveSteps_act}.
Rule 15 defines the function [ [-]] ST that translates a statement. The parameter stmt is a CommunicationStmt, which contains a Communication encapsulating a synchronisation, an input or an output event. The function [[-]] ST also has the following parameters: pcconstrs records constraints on the counters that identify the state in which stmt is executed; stnumber is the next available number for states; scpcname is the name of the current counter; curstate is the optional declaration of a PRISM constant representing the state at the start of stmt; and assigns is a set of PRISM assignments that encode the change to the state after the execution of stmt. The constant curstate, if present (not null), indicates that stmt is an entry action. In this case, it is used by all transitions to the state with that entry action.
The result of [[-]] ST is a quadruple. The first element is the new available state number. The second is a set of new constants to identify extra states, of which there may be several if the action is compound. The third element stm is a set curassgns of assignments to update the state of the module to the start state for the encoding of stmt. Finally, the fourth element is a set containing one command cmd to encode stmt. If curstate is not null, the supplied curstate encodes the start of stmt, and so no new constant is needed: the new available state number is still stnumber and the result has an empty set of constants. Otherwise, a fresh constant, such as taskState_3, is declared and associated with stnumber as shown by the definition of const in the where clause. In this case, the new available state number is stnumber + 1, and the set of constants includes a single element const. For the application of [[-]] ST to translate the statement in the action of t1 in Fig. 21, the first element of the result is 7 because 6 identifies taskState_3 on line #17 in Fig. 20, the second is the declaration of taskState_3 on line #17, the third is the set containing scpc'=taskState_3 on line #33, and the fourth element is the command on line #34. The variables used in Rule 15 are defined in the where clause explained below.
const is the constant encoding the start of the statement stmt. If the argument curstate is not null, the constant is just curstate. Otherwise, it is a constant with a fresh name given by uname(stmt, stnumber) and associated with stnumber.
assgnchvar is a set of assignments. If stmt is an output event (its communication is of type OUTPUT) or a synchronisation (its communication is of type SYNC), it contains an assignment to update the event related variable EVT__id(stmt.communication.event) from the value [[stmt.communication.value]]e carried by the event, to encode communication. Otherwise, it is empty.
curassgns contains an assignment to update the counter variable to the start state for the encoding of stmt and assignments in assgnchvar explained above.
assgninvar is also a set of assignments. If stmt is an input event (that is, its communication is of type INPUT), this set contains an assignment to update the input variable id(stmt.communication.parameter) to the value of the variable used for output, to encode the input communication. Otherwise, assgninvar is empty since there is no data exchange.
cmd is a command. Its action is the name of the event of stmt given by id(stmt.communication.event). Its guard ensures that the counter variables indicate that the current state is that identified by const. We have a conjunction of two terms. The first, andExprs(pcconstrs), is itself a conjunction of the boolean expressions in the argument pcconstrs, which are equalities regarding the counter variables for all states and state machine containing stmt. The second conjunct requires that the counter variable for the state or machine containing stmt, whose name is given by the argument scpcname, has the value const.name for the encoding of stmt. The update of cmd has probability 1 and assignments containing the argument assigns to update the counters to the final state of the encoding of stmt and assgninvar explained above.