Modelling Ambulance Deployment with CarmaCARMA

Abstract

Carma is a process-algebra influenced language for the quantitative modelling of collective adaptive systems which involve collaboration and coordination. These systems consist of multiple components that interact to achieve certain goals and that adapt to changes in the environment. As a case study for the application of Carma, this paper presents an ambulance deployment system where ambulances go to medical incidents and either treat patients at the scene or transfer them to hospital. The Eclipse Carma Plug-in is used to simulate the system, and demonstrate its behaviour in different circumstances.

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Creating formal dynamic models of systems that can be simulated and subjected to other forms of quantitative analysis is one way in which formal methods can be used in the development and evaluation of these systems. Frequently, it is not possible to experiment with the system itself, because of the cost or disruption involved. Hence development of models that can be used for experimentation is important. This paper applies a language that has been developed to model collective adaptive systems (CAS) to an existing ambulance deployment scenario.

CAS feature frequently in modern information systems. Multiple components interact (and sometimes compete) to achieve various outcomes. The components can be individual pieces of software or different physical devices, and such systems are often characterised by local information and local action which therefore, requires a notion of space. Coordination and collaboration are features of these models because of the components communicate to achieve their aims. The language Carma and its associated software tool the Eclipse Carma Plug-in have been developed for the quantitative modelling of CAS allowing for an understanding of both functional and nonfunctional properties of models [3, 5]. Important aspects of Carma include attribute-based communication, in the sense that the possibility of a component taking part in an interaction depends on the current values in the store of the component, thus allowing for a rich representation of state. Both unicast and broadcast modes of communication are supported. Furthermore, Carma allows the environment within which the model components interact to be defined separately from the components. The development of Carma has been influenced by a number of previous process algebra including the Markovian process algebra PEPA [12], the location-focussed PALOMA [9] and SCEL [8] which uses attribute-based communication. Attribute-based communication is explored further in the process calculus AbC [2].

In this paper, the modelling and analysis of a particular system using Carma is considered. Jagtenberg et al. have proposed a new approach to ambulance deployment [14]. The general goal of such systems is to minimise the time it takes to respond to medical incidents by ensuring good base locations for ambulances together with a distribution of ambulances over bases that leads to fast response. Traditionally, deciding how to deploy ambulances across a region has been done statically, in the sense that once an ambulance has completed its current task, it returns to a predefined base, and moreover determining the best bases is done in advance of deployment. In the dynamic approach, depending on the locations of the other ambulances, an ambulance that is no longer busy can be requested to go to a specific location in a set of base locations to wait for its next task, thus allowing the system to adapt to the current circumstances. The ambulance system is modelled as a graph of locations with edges representing roads, annotated with information about how long it takes to traverse the edge, as shown in Fig. 5. Locations may be cities, towns, road junctions or other points of interest. Each location has an incident probability, and some locations have ambulances bases or hospitals. There has been much research into different aspects of ambulance response time that use a graph to represent the road network. These have considered how many ambulances to use, the best locations for bases and how to distribute vehicles over bases [1, 4, 6, 10, 15, 16]. The specific system modelled here has been chosen because of its time-based performance evaluation aspects and straightforward heuristic function. The developed model could be modified to investigate other aspects of ambulance deployment.

This paper presents a Carma model of such an ambulance system. As Carma is a new modelling language, it is necessary to evaluate it by developing interesting and complex models, and the ambulance deployment system fulfils these requirements. First, the ambulance scenario is introduced after which details of Carma are presented, followed by the ambulance model expressed in Carma. Finally results of simulation of the model are presented and a discussion of further research relating to the model discussed.

2 An Ambulance Deployment Scenario

This section describes the mathematical model that Jagtenberg et al. [14] propose, together with their heuristic for best real-time redeployment of ambulances. This model considers a scenario where there is a fairly sparse network of roads between cities and towns (as shown in Fig. 5), and hence is slightly more appropriate for a non-urban situation, where there are not many routes between each point of interest. An urban map can be transformed into a similar sparse network by focussing on major routes.

Let $N=(V,E)$ be a graph where $E \subseteq V \times V$. Four functions are associated with this graph.

• $r : E \rightarrow \mathbb {R}_{>0}$ describes the time it takes to traverse an edge (when using sirens and lights – this figure increases for travel without lights and sirens).

• $h : V \rightarrow \{0,1\}$ defines the presence of a hospital at a vertex.

• $b : V \rightarrow \{0,1\}$ defines whether a vertex is an ambulance base.

• $d: V \rightarrow [0,1]$ with $\sum _{v\in V} d(v) = 1$, defines the distribution of incidences over the vertices of the graph.

There is also a set of ambulances A labelled $\{1,\ldots ,n\}$ and two functions $l: A \rightarrow V$ describing the current location of an ambulance and $w: A \rightarrow \{0,1\}$ describing whether an ambulance is currently allocated to an incident. Furthermore, a function $s : A \rightarrow V$ which describes the home station of an ambulance in the static case. There are three rates that describe how long it takes for an ambulance to treat a patient at the scene, $\lambda _p$, how long it takes for an ambulance to load up a patient at the scene for transportation to hospital, $\lambda _t$ and how long it takes to offload a patient at hospital, $\lambda _d$. It is assumed that patients are either treated at the scene or uploaded to be taken to hospital but not both. Furthermore, there is a probability m that determines whether an incident is severe, requiring the patient to be transported to hospital, or minor, meaning that the patient only needs to be treated at the scene. The operation of the system is now described.

• 1. An incident occurs at a vertex based on the distribution defined by d and its level of severity is determined using the probability m.

• 2. An ambulance is identified to go to the incident location based on distance from the incident.

• 3. The ambulance uses the shortest route to get to the scene. Since distances are deterministic and unchanging, shortest routes can be determined in advance from the network, and hence are static in the model.

• 4. The ambulance treats the patient at the scene and then proceeds with item 7, or the ambulance uploads the patient to take them to hospital.

• 5. The ambulance uses the shortest route to the hospital using sirens and lights.

• 6. The ambulance drops the patient off at the hospital.

• 7. The ambulances uses the shortest route to go to a base but taking longer as it is not using sirens and lights. In the static case, this is the base defined by s. In the dynamic case, the base is determined by the heuristic.

Once an ambulance has been allocated to an incident, it must complete the journey to the incident, and to the hospital, if necessary, and cannot be diverted. However, once an ambulance has started to return to base, it can be immediately allocated to a new incident. An ambulance that is involved in items 2 to 6 is considered to be busy, otherwise it is idle. When it is idle, it is associated either with the base it has reached or the base to which it is travelling.

2.1 Evaluation of Base Heuristic

The reason to model such systems is to investigate the performance of different deployment approaches. The proportion of ambulances that do not reach the incident within a fixed time period (denoted T) after being allocated to that incident, is often used [14] and will be used here.

In the case of static deployment where each ambulance has a fixed base, simulation can be used to assess the best distribution of ambulances, in the planning stages of a system. Different variants of the maximum expected covering location problem (MEXCLP) [6] have been used to tackle this task. The disadvantage of the static approach is that it ignores real-time information that can be used to provide better coverage [14]. Coverage describes the number of ambulances that can provide service at a specific location within the time limit. Increasing coverage means that there is a higher probability that an ambulance will be available if one is needed.

Dynamic deployment approaches can be divided into two main techniques. The first, based on lookup tables, requires dispatchers to steer the system to these optimal configurations. A better approach is based on real-time approximation. However, even using approximate dynamic programming and post-decision state is time-consuming and requires an expert to implement and choose base functions [14]. By contrast, the approach taken in [14] is moderately coarse-grained and needs little real-time information, and takes a marginal cover approach based on MEXCLP.

Consider a set of ambulances A with behaviour as described above. Also let $B = \{ u \in V | b(u) = 1\}$ be the set of vertices that are bases. It is assumed that there is a probability q which is the same for all ambulances and represents the fraction of time that the ambulance is busy. It can be determined by dividing the load of the system by the number of ambulances [14]. The expected coverage at vertex v when v is in the range of k ambulances is $E_k(v) = d(v)(1-q^k)$ and as shown in [6], the marginal coverage is $E_k(v)-E_{k-1}(v) = d(v)(1-q)q^{k-1}$. This figure can be used to determine to which base to send an ambulance once it has completed its task, by finding $u \in B$ such that the increase in coverage is maximised, and hence the maximum coverage overall is obtained. Let $\rho (v,w)$ be the time taken for the shortest route between vertices v and w, calculated from the values of individual hops given by the function r. Let $n_u$ represent the number of ambulances at $u \in B$, or moving towards $u \in B$ after completing their allocated task, and let $N = \{n_u\mid u \in B\}$ represent the current number of idle ambulances for each possible base location. The function p captures the heuristic for determining ambulance base and is defined by¹

$$\begin{aligned} p(N)= & {} \mathop {arg\ max}_{w \in B} \sum _{v \in V} d(v)(1-q)q^{k(v,w,N)-1} \cdot \mathbf {1}(\rho (w,v) \le T) \qquad \text {where} \\ k(v,w,N)= & {} \sum _{u \in B} n_u \cdot \mathbf {1}(\rho (u,v) \le T) + \mathbf {1}(\rho (w,v) \le T). \end{aligned}$$

Here $\mathbf {1}$ is the indicator function. This function can also be simplified to

$$\begin{aligned} p(N)= & {} \mathop {arg\ max}_{w \in B} \sum _{v \in V} d(v)(1-q)q^{c(v,N)} \cdot \mathbf {1}(\rho (w,v) \le T) \qquad \text {where} \\ c(v,N)= & {} \sum _{u \in B} n_u \cdot \mathbf {1}(\rho (u,v) \le T) \end{aligned}$$

For each possible base of the ambulance that has just completed its task, the increased coverage is calculated for every location in the graph whenever addition of the base would increase coverage at that location, and summed. The function c counts the number of ambulances that are already in the range of each base (reachable within the limit of T time units) as defined by the set N. If it is the case that both |A|, the number of idle ambulances, and |B|, the number of bases, are small compared to the number of vertices |V|, then the algorithm is linear in |V| [14].

It is important to note that some aspects of the model are generic such as the ambulance behaviour but others are specific to the system under consideration such as the graph of locations, the functions relating to these locations, and the heuristic function p. This distinction will be used when deciding how to build the Carma model. The next section introduces Carma, after which the Carma model of the system is presented.

3 Carma 

Carma is a powerful language, influenced by process algebra, for describing systems consisting of different interacting components which allows for an explicit definition of environment. Its semantics are time-inhomogeneous continuous-time Markov chains [5] thus permitting both simulation and other analysis techniques. It is embodied in software in the Carma Eclipse Plug-in tool which implements the basic language and supports features such as function definition, enumerated types, and measures which enable quantitative behaviour of a model to be calculated and recorded.

A Carma model consists of a number of different elements. At the highest level, there is a collective that consists of different components that interact, together with an environment that contains information about the global state, as well as information about how components interact. Thus Sys is the set of Carma systems S defined by

$$ S~{:}{:}{=} ~ N~\mathbf {in}~\mathcal {E} $$

where $N$ is a collective and $\mathcal {E}$ is an environment. The set of collectives Col is defined by

$$ \begin{array}{rclr} N~{:}{:}{=}~C~~\big |~~N\parallel N\end{array} $$

A collective $N$ is either a component $C$ or the parallel composition of two collectives ($N\parallel N$). The syntax of components is

$$ C~{:}{:}{=}~\mathbf {0}~~\big |~~ (P,\gamma ) $$

where $\mathbf {0}$ is the null component, P is a process that describes the behaviour of the component and $\gamma$ is the store for the component. $\textsc {Comp}$ is defined to be the set of components. A store maps from attribute names to basic values where

• ${\textsc {{Attr}}}$ is the set of attribute names a, $a'$, $a_1$,..., b, $b'$, $b_1$,...;

• ${\textsc {{Val}}}$ is the set of basic values v, $v'$, $v_1$,...; and

• $\varGamma$ is the set of stores $\gamma ,\gamma _1,\gamma ',\ldots$, are functions from ${\textsc {{Attr}}}$ to ${\textsc {{Val}}}$.

$\textsc {Proc}$ is the set of processes that define the behaviour of components and they are specified by

$$\begin{aligned} \begin{array}{c|c} \begin{array}{rclr} P,Q &{} {:}{:}{=} &{} \mathbf {nil}\\ &{} | &{} \mathbf {kill}\\ &{} | &{} act.P\\ &{} | &{} P+Q\\ &{} | &{} P~|~Q\\ &{} | &{} [\pi ]P\\ &{} | &{} A &{} (A\mathop {=}\limits ^{ \triangle }P)\\ \end{array} &{} \begin{array}{rclr} act &{} {:}{:}{=} &{} \alpha ^{\star }[ \pi ]\langle \overrightarrow{e}\rangle \sigma &{} \\ &{} | &{} \alpha ^{}[ \pi ]\langle \overrightarrow{e}\rangle \sigma \\ &{} | &{} \alpha ^{\star }[ \pi ]( \overrightarrow{x} ) \sigma \\ &{} | &{} \alpha ^{}[ \pi ]( \overrightarrow{x} ) \sigma \\ e &{} {:}{:}{=} &{} a~|~\mathsf {my}.a~|~x~|~v~|~\mathsf {now}{}~|~\cdots \\ \pi &{} {:}{:}{=} &{} {\top ~|~\bot ~|~e_1\bowtie e_2~|~\lnot \pi ~|~\pi \wedge \pi ~|~\cdots }&{} \end{array} \end{array} \end{aligned}$$

In Carma processes can have different prefixes relating to four types of actions which are broadcast output ($\alpha ^{\star }[ \pi ]\langle \overrightarrow{e}\rangle \sigma$), broadcast input ($\alpha ^{\star }[ \pi ]( \overrightarrow{x} ) \sigma$), output ($\alpha ^{}[ \pi ]\langle \overrightarrow{e}\rangle \sigma$), and input ($\alpha ^{}[ \pi ]( \overrightarrow{x} ) \sigma$), where

• $\alpha$ is an action type in the set of action type ${\textsc {ActType}}$;

• $\pi$ is a predicate;

• x is a variable in the set of variables ${\textsc {Var}}$;

• e is an expression in the set of expressions ${\textsc {{Exp}}}$;

• $\overrightarrow{\cdot }$ indicates a sequence of elements;

• $\sigma$ is an update, i.e. a function from $\varGamma$ to $Dist(\varGamma )$ in the set of updates $\Sigma$; where $Dist(\varGamma )$ is the set of probability distributions over $\varGamma$.

A unicast communication involves two components where the sender and receiver attributes must satisfy any predicates in the prefixes, the expressions in the output prefix are assigned to the variables in the input prefix (and hence successful communication requires the two sequences are the same length), and updates are applied to both components to complete the interaction. Furthermore, there can be a probability describing whether the receiver does actually receive the communication. Unicast is blocking in that a sender cannot proceed until a receiver takes part in the interaction.

By contrast, broadcast is not blocking and the sender can proceed regardless of whether there are many, one or no suitable receivers. Again, the sender and potential receivers must satisfy the predicates in the prefixes, and additionally there is a probability that the receiver although suitable to take part in the interaction, does not receive it. Expressions from the output prefix are passed to variables in the input prefix and updates are applied to all participants on completion of their roles, in the same manner as unicast. For both unicast and broadcast, rates of actions and probabilities of receiving are defined in the environment part of the model.

Specific expressions of interest are $\mathsf {now}{}$ for the current simulation time and $\mathsf {my}.a$ which refers to the value of the attribute a in the current component.

Apart from the four different prefix types, there is choice between two processes, the parallel composition of two processes, a guarded process which requires satisfaction of its predicate before it can perform an action and definition of constant processes. There are two distinct operators for termination. The operator $\mathbf {nil}$ represents the process that can perform no further actions and it can be placed in parallel with other processes. The operator $\mathbf {kill}$, on the other hand, indicates termination of the whole component so that all processes in the component stop, and the component is transformed into $\mathbf {0}$, the null component which can do nothing and has no store.

Carma collectives interact within an environment $\mathcal {E}{}$. The environment describes the rules that regulate the system such as rates of interaction and probabilities that interaction may occur. It also contains global information. The environment has two elements: a global store $\gamma _{g}$, that records the value of global attributes, and an evolution rule $\rho$. This is a function which, depending on the current time (using $\mathsf {now}{}$), on the global store and on the current state of the collective returns a tuple of functions $\varepsilon =\langle \mu _{p}, \mu _{r}, \mu _{u}\rangle$ known as the evaluation context where ${\textsc {Act}}={\textsc {ActType}}\cup \{ \alpha ^{\star }| \alpha \in {\textsc {ActType}}\}$ and

• $\mu _{p}: \varGamma \times \varGamma \times {\textsc {Act}}\rightarrow [0,1]$, $\mu _{p}(\gamma _s,\gamma _r, \alpha )$ determines is the probability that a component with store $\gamma _{r}$ can receive a message from a component with store $\gamma _{s}$ when $\alpha$ is executed;

• $\mu _{r}: \varGamma \times {\textsc {Act}}\rightarrow \mathbb {R}_{\ge 0}$, $\mu _{r}(\gamma , \alpha )$ determines the execution rate of action $\alpha$ executed at a component with store $\gamma$;

• $\mu _{u}: \varGamma \times {\textsc {Act}}\rightarrow \Sigma \times \textsc {Col}$, $\mu _{u}(\gamma , \alpha )$ determines the updates on the environment (global store and collective) induced by the execution of action $\alpha$ at a component with store $\gamma$. The execution of an action can modify the values of global variables and also add new components to the collective.

In each of the rules, the notation $\mathsf {sender}.a$ is used to refer to the value of the attribute a in the store of the acting or sending component, and $\mathsf {receiver}.a$ refers to the value of the attribute a in the store of the receiving component.

Operational semantics of Carma specifications are defined in three stages using the following transition relations. For reasons of space, the rules are not presented here, but can be found in [5].

• 1. The relation describes the behaviour of a single component.

• 2. The relation builds on the first relation to describe the behaviour of collectives.

• 3. The relation   describes how Carma systems evolve.

All relations are defined in the FuTS style [7] and are described using a triple $(N,\ell ,\mathcal {N})$ where the first element is a component, or a collective, or a system. The second element is a transition label. The third element is a function associating each component, collective, or system with a non-negative number. A non-zero value represents the rate of the exponential distribution characterising the time needed for the execution of the action represented by $\ell$. The zero value is associated with unreachable terms. FuTS style semantics are used because it makes explicit an underlying (time-inhomogeneous) Action Labelled Markov Chain, which can be simulated with standard algorithms [11].

4 Ambulance Model

The Carma model is presented in Figs. 1, 2, 3 and 4. Each component consists of the attributes that form its local store, its behaviour defined by processes and its initial state. Additionally, the attributes of the global store are defined in Fig. 4 together with the evolution rule functions over actions (one function for the rates, one for the probabilities and one for the updates of global attributes and additions to the collective). There are four actions with non-negligible rates, and the remainder are zero or fast (since Carma does not currently support instantaneous actions). Figure 4 also includes the initial collective definition as the last item.

Th symbols $\top$ and $\bot$ as used for true and false, respectively. A broadcast action of the form $\alpha ^{\star }[ \bot ]\langle \rangle$ is an action that cannot be received (because no component can satisfy the predicate false) and hence is local to the component that executes it, although it may also update the global store or add components to the collective.

Fig. 1.

Incident queue, incident queue item and incident handler components

Fig. 2.

Return handler and idle ambulance components

Fig. 3.

Ambulance and route components

Fig. 4.

Constants, environment and collective

As mentioned previously, some aspects of the model are generic and some are specific to the network of roads and places. These two concerns have been separated in the model. The components are generic, and functions (indicated in bold in the figures) embody the knowledge of the network². The Carma Eclipse Plug-in supports function definitions, hence this separation is both possible and sensible, and also supports the design of a tool for ambulance modelling, as discussed in the further work section.

These functions comprise of one to provide the distributions over location and type of incidents respectively, $\mathbf {IncidentLocation}()$, $\mathbf {IncidentType}()$; information about routes in the network, $\mathbf {RouteLength}(.,.)$, $\mathbf {NextHop}(.,.,.)$ and $\mathbf {MoveTime}(.,.,.)$; location of the closest hospital to an incident, $\mathbf {HospitalLocation}(.)$; location of the closest idle ambulances to an incident location, $\mathbf {ClosestIdleLoc}(.,N)$; and the base to which an ambulance should go, $\mathbf {GetBase}(.,.,N)$ which can be defined statically or dynamically. Note that both $\mathbf {ClosestIdleLoc}$ and $\mathbf {GetBase}$ take N, the set of the counts of idle ambulances at each base or on their way to each base as an argument. For the former, N is used to find the closest location to the incident where there are idle ambulances, so that a request can be sent to ambulances in that location. For the latter, the counts of idle ambulances are required to calculate p.

There are seven generic components in the model. The Incident_Queue generates Incident_Queue_Items using the action $\mathsf {incident}^\star$ which has the side-effect of adding a new Incident_Queue_Item to the collective (as specified by the function $\mu _{u}$ appearing in the environment in Fig. 4). Each item has a unique number, and in turn generates an Incident_Handler using the action $\mathsf {new\_handler}^\star$. The first action of the Incident_Handler is to request an ambulance from another component Closest_Idle_Ambulance. This is a separate component for clarity of structure. On receiving a request for a specific location, it calls the function to find the location with idle ambulances that is closest to that location, and take note of the current time. It then tries to communicate (via unicast) with any ambulance in that location. If that succeeds, then it, the Incident_Handler and the Incident_Queue receive a $\mathsf {confirm}^\star$ message from the ambulance that has responded. If there is no response, which is possible because there may be no idle ambulances, a timeout occurs. The timeout is defined by the rate for $\mathsf {pause}^\star$ in the environment in Fig. 4 where if insufficient time has passed the rate is zero (otherwise, it is $\lambda _ fast )$. If the timeout happens, it calls the function again and send out another request to the location that the function returns.

The Incident_Queue interacts with each Incident_Queue_Item and its associated Incident_Handler to ensure that at most one Incident_Handler at a time is contacting the closest idle ambulance (because two incidents may have the same closest idle ambulance). The use of queue numbers ensures fairness in the sense that an Incident_Handler cannot be starved of access to an Ambulance by later incidents and their associated Incident_Handlers. A queue item cannot be released and hence cannot execute $\mathsf {new\_handler}^\star$, until the Incident_Handler associated with the previous Incident_Queue_Item and its interaction with Closest_Idle_Ambulance has successfully concluded negotiations with the closest idle ambulance via communication on the $\mathsf {confirm}^\star$ action.

Each Incident_Handler has an assigned ambulance and interacts with the ambulance and generates Routes to move the ambulance to the location of the incident and then to the nearest hospital, if required. After this a Return_Handler is created using $\mathsf {tobase}^\star$. The two handlers are separate components because an ambulance cannot be diverted once it has been assigned to an incident but once it is returning to a base position, it can be called to a new incident, so Return_Handler has behaviour to allow it to remove itself from the collective if this happens, and it is no longer needed in the collective.

Once an Incident_Handler and an Ambulance have been matched, the ambulance number is used in all communication between the Incident_Handler, Ambulance and Route components to limit broadcast communication to these three components. The queue number could also have been used for these purposes but ambulance number is sufficient. Since broadcast is not blocking, the model must be constructed so that Incident_Handler and Ambulance are in a state to receive the message from Route.

The Route component works through the route hops. It is initialised with the start and end of the route, and after obtaining the length of route from $\mathbf {RouteLength}$, it works through each hop of the route³ using the function $\mathbf {NextHop}$ until the end of the route when the appropriate action occurs depending on the destination type. For pickup and treatment at the scene, an $\mathsf {arrive}^\star$ action is required followed by a $\mathsf {timecheck}^\star$ action for the global count of late and on-time ambulances to be updated, based on the time the $\mathsf {timecheck}^\star$ action happens and the time the incident was generated.

The Ambulance and Route components assume that travel times are deterministic rather than stochastic (although it is straightforward to modify the model to use stochastic durations). The Route component performs a local $\mathsf {start\_move}^\star$ action and notes the time of the action. The ambulance component responds to an $\mathsf {end\_move}$ action once sufficient time has elapsed. Since Route components can also be generated by Return_Handlers, they can remove themselves from the collective on receipt of a kill command from the associated Ambulance when it receives an incident request during going to a base location.

After a simulation completes, the performance measure of the proportion of late ambulances can be calculated from the two global variables ontime and $late$. The model describes a system where ambulances behave in the manner described by the seven points in Sect. 2. The next section considers results of experiments with this model.

Table 1. Parameters for model

Fig. 5.

Network configuration for experiments

Fig. 6.

Idle ambulances and proportions of late arrivals for time limits and hospital locations

5 Results

To explore the behaviour of the model and the heuristic, the network shown in Fig. 5 is used (which by contrast with [14] is a compact network rather than long and narrow). and is somewhat simpler than a real scenario. The number annotating the edges of the network gives the time in minutes that it takes to traverse the edge at the faster speed (with sirens and lights on). Locations with hospitals are indicated by double circles at vertices. The number annotating a vertex is the proportion of incidents at that location.

The parameters chosen for the model are given in Table 1. The parameter T which is used as the limit in the calculation of the late rate varies across experiments. The busy fraction q which is used in the calculation of the heuristic function $\pi$ is estimated by simulation, for the given network with three ambulances to be 0.65.

The experiments explore how the late rate varies for different values of the time limit, and furthermore, they consider how the hospital location can affect the late rate, and are illustrated in Fig. 6. The square nodes indicate the hospital locations in each case. Each combination of time limit and hospital location was simulated for 500 runs over 20 h of simulated time. The shaded circles indicate at which locations the idle ambulances were based, and all locations were considered as possible base locations. The area of the circle represents the proportion of simulations that idle ambulances are at a location (or on their way to that location as a base) at the time point of 1200 min (20 h). Since there are three ambulances, fewer than three circles indicate that multiple ambulances are idle at a location.

The results show that the heuristic does not appear to have monotonic behaviour since an increased time limit can lead to a different location with a worse late rate, and this requires further investigation. The heuristic does not use the hospital location but obviously distance from hospital back to base will impact availability, and hence late rate. The lowest late rates occur when there are two hospitals at the two cities, and an ambulance goes to the closest hospital. This experiment shows how the late rates would be affected if it was necessary to close one of the hospitals. However, for some time limits, the presence of two hospitals has little effect on the late rate when compared with just one hospital at the second city, where for others it makes a significant difference. The fact that hospital location can affect the proportion of late arrivals suggests a role for the hospital location in the heuristic function.

6 Conclusions and Further Work

This paper has demonstrated how the language Carma can be successfully used to model a system involving coordination where communication is often complex and multiway, and various components interaction to achieve goals. In this case, this is identification of an ambulance to go to an incident, movement of the ambulance to the incident using a generic component that draws on functions to give the specifics of a route, movement to hospital where required, then choice of a base to return to on completion and movement to that base. Because of the use of generic functions together with generic components, the model can be made applicable to any road network simply by substituting the appropriate functions.

Further research relating to this case study include further exploration of the parameter state space, in particular to understand the nature of the heuristic function as mean time between incidents change, as well as modifying the heuristic to take into account the current location of idle ambulances as well as their bases. Different performance measures could also be investigated that consider not just a single deadline but how late the ambulance is, in the case of late arrival at the scence. Clearly, many variations can be made to the ambulance model, including for example, switching to an ambulance closer to the incident if one becomes available when another is already on the way; investigating movement between bases as an incident occurs; and the use of different time limits depending on the severity of the incident. At the modelling level, comparison of the use of Carma with other formalisms and an assessment of its strengths and weaknesses is important.

As often is the case in modelling for performance assessment, the users who are interested in the measure often do not have the skills to work with the modelling language directly. A ongoing project is to develop a graphical front-end for general modelling of this ambulance scenario. The final goal is software which allows a user to graphically create a road network as shown in Fig. 5 with appropriate annotations, after which it will automatically generate a Carma model consisting of the seven generic components, the model parameters and the functions to implement the network. The model can then be simulated in the Carma Eclipse Plug-in. An additional step would be to take the output of a single simulation and use it to create an animation over the network, to give users an insight to what is happening during the simulation. This gives more information about the model over and above the performance measure.