A Homogeneous Actor-Based Monitor Language for Adaptive Behaviour

Abstract

This paper describes a structured approach to encoding monitors in an actor language. Within a configuration of actors, each of which publishes a history, a monitor is an independent actor that triggers an action based on patterns occurring in the histories. We define a monitor language based on linear temporal logic and show how it can be homogeneously embedded within an actor language. The approach is demonstrated through a number of examples and evaluated in terms of a real-world actor-based simulation.

1 Introduction

1.1 Background

Software system monitors are instruments that are added to applications in order to collect data, diagnose problems and influence behaviour, for example to collect training data [21], recognise health issues [19], control of energy networks [7], dynamically verify system requirements [14] and to adapt to environmental changes [12]. Monitors are typically orthogonal to the system that is monitored and, as such, manage their own thread of control. Our particular interest in monitors arises within the field of simulation to support decision-making [4, 20] where levers that control a simulation need to be adapted by monitoring the behaviour of system components as shown in Fig. 1.

Fig. 1.

System adaptation

Fig. 2.

Actor monitors

The actor model of computation [2] would seem to be a good candidate for representing both systems to be monitored and their associated monitors because an actor has autonomous behaviour and new actors can be added or deleted without significant architectural disruption. Figure 2a shows a simple model of a monitor actor that is attached to a monitored actor. Adaptation occurs by regularly checking the history exported by the monitored actor and taking action when monitor conditions are satisfied by the data in the history.

Several patterns emerge from the actor arrangement shown in Fig. 2a. An individual monitored actor that publishes events on its history can be monitored so that when the monitoring actor detects the event-data it can take action as shown in Fig. 2b. If the monitoring actor also takes into account the timing of events, it may compare the relative times of two or more events as shown in Fig. 2c. A single monitor may be attached to two or more actors as shown in Fig. 2d in which case we can define intra- and inter-actor relationships between events that occur over multiple actors.

1.2 Requirements and Contribution

The patterns described in Fig. 2 lead to technical requirements for actor-based monitors: (1) It must be possible to define an actor interface so that monitored actors provide a history in the correct format for monitor actors and are otherwise unaware of monitoring behaviour. (2) Events that are published via histories should have temporal information that monitor actors can use for intra- and inter-actor reasoning. (3) Monitors should be actors to allow them to be added and removed dynamically during system execution (and to support meta-monitoring where that is appropriate). (4) There should be a monitor language, whose denotation is defined in terms of actors, that is open to static analysis.

Our contribution is to show how monitors can be encoded within an actor language in a way that achieves the requirements listed above. In particular, we achieve a homogeneous representation by defining a sub-language of a broader actor language that supports monitors and define a general purpose interface for monitored actors. We perform static analysis, in terms of actor interfaces, and outline in the conclusion how we intend to check that monitors are consistent with the histories published by monitored actors. As described in [9], monitors can themselves be actors and we demonstrate this by defining the semantics of monitors as an homogeneous language embedding [23].

Section 2 describes existing work on actors, agent languages and software monitoring in general. Languages employing temporal operators are often used to specify the behaviour of actor systems, but we employ such operators to define a language of dynamic monitors in Sect. 3. Our work on simulation has led to the implementation of a new actor-based language called ESL that is used to present our contribution; Sect. 4 introduces that part of ESL necessary to understand how monitors are encoded. Section 5 describes how monitors are defined in ESL and Sect. 6 shows how ESL and monitors are used to implement a simulation for a real-world case study.

2 Related Work

The concept of a monitor that observes the behaviour of a system and detects the violations of safety properties is well studied area [16]. The early work on monitors focused on off-line monitoring where the historical data or program trace is statically analysed post-execution [13] to detect anomalies. In contrast, the recent research trend primarily addresses on online monitoring that dynamically validates the observed system execution against a specification to achieve preventive and corrective measures.

Monitoring-related research challenges include: (1) the use of an appropriate foundational model for system specification (this can be mapped to Monitoring-Oriented Programming¹); (2) an efficient implementation of monitors; (3) monitor control patterns. Existing monitor technologies are largely based on temporal logic which has led us to use the same underlying formalism. For example, the past-time linear temporal logic (PTLTL) is recommended as specification language [18, 22] where monitor properties are expressed using the notion of time, as introduced by LTL, with both past and future modalities including next, previous, eventually in the future or past, always in the future or past, etc. The PTLTL is further extended with call and returns in [24], the Eagle Logic (where the temporal logic is extended with chop operator) is proposed in [5], and the Meta Event Definition Language (a propositional temporal logic of events and conditions) is used in the Monitoring and Checking (MaC) toolset [26]. In contrast, an extended regular expression and context free grammar based language is proposed and implemented in [9].

From an implementation dimension, online monitoring technologies are implemented either by adopting an inline approach [25] or a centralised approach [15]. A centralised approach is applied to the system under observation using either a synchronous [10] mode or an asynchronous mode [11]. In general, the inline monitors are computationally efficient as they have access to all system variables, whereas the centralised monitors are better in other dimensions as they enable clear separation of concerns (and thus less error-prone), facilitate distributed computation, and exhibit compositional characteristics.

As part of our work on system simulation, we propose a variant of monitor technology that can be used to evaluate agent goals (similar to monitoring safety properties) and make decisions about appropriate system adaptation. A restricted form of centralised asynchronous monitor is implemented in Akka [3] to realise the monitoring behaviour of supervisor actors of a hierarchical actor system. Recently, a prototype of asynchronous centralised monitor implementation is presented in [9]. In the context of multi-agent systems, the concept of monitor is used for one of the two purposes - (a) to support heterogeneous agent implementations, and (b) to introduce a clear separation of concerns between core agent behaviour and other aspects such as adaptation. With respect to (b) the core agent behaviour (or behavioural specification) is considered to be a black-box, and adaptation is defined as monitor that observes the execution of core behaviour and reacts to specific observations [9].

ESL, simulation and adaptive behaviour are active areas of our research. Work in this area by [28] is likely to prove useful in efforts to specify the structure of histories, perhaps using pattern based rules, and then to verify that monitors are consistent with the monitored actors to which they are applied.

Our proposed language also provides centralised asynchronous monitors. The Akka implementation monitors the occurrence of events within its sub-actors and uses a fixed set of operations such as stop actor, suspend actor as an adaptation strategy. In contrast our proposed implementation evaluates the historical data to produce adaptation without using a restricted set of operations, effectively achieving a combination of [9] with the adaptation strategy presented in [8] augmented with temporal features and the extensions presented in [22] (i.e., past and future modalities).

3 An Actor-Based Monitor Language

We have motivated a requirement for an actor-based monitor language that can be used in a variety of applications including diagnosis and adaptive behaviour. Since monitors need to reason about behaviour over time, it is reasonable to follow existing approaches to both actor behavioural specification and system monitoring that are based on linear temporal logic (LTL). We show how the proposed LTL-based monitor language can be encoded using actors. This section describes the monitor language and provides a simple example. The rest of the paper provides the semantics of the language by embedding it in an actor language called ESL, and then evaluates the language using a real-world case study.

3.1 Language Definition

Figure 3 defines a monitor construction language. A monitor is applied to a monitored actor that exposes a history as a sequence of data elements. The monitor can hold for the supplied history at a given time, where time is an integer that indexes the data in the history. Typically time will start with the first element of the history and the modal operator is used to advance time so that holds for a history starting at time when holds at time and holds at time . The formula is equivalent to .

Fig. 3.

Actor monitor language

The language allows arbitrary conditions to be applied to data in a history at a given time. In order to support actions and system instrumentation, a monitor may be an action where is a function of 0-arguments. The intention is that we use guard monitors of the form: .

In order to support multi-actor monitoring as shown in Fig. 2d we allow monitored actors to be aggregated using a binary operator. Monitors can manipulate such actors using the disaggregation operator (split) and its inverse (join). For example two monitored actors and can be aggregated to create . When such an actor is monitored by , monitors , monitors and monitors both and . Note that the operator is implicitly inserted between and thereby ensuring that the monitor types are consistent.

3.2 A Simple Application of Monitors

The monitor language is influenced by LTL since it uses modal operators to range over time within histories. LTL is used by Bulling et al. to specify agent behaviour [6] with respect to an example involving traffic queues. We will use this example to show that an LTL-based monitor language can be used to help adapt traffic-light behaviour.

Traffic flow at an east-west bottle-neck along a single-carriage road is controlled by traffic lights. The bottle-neck can only accommodate one car and therefore the job of the traffic-lights is to ensure that the queues on either side do not become too large. Furthermore, traffic approaches from the east more frequently than that from the west.

Fig. 4.

Traffic flow at a bottle-neck (Color figure online)

Figure 4 shows the situation. The approaches from east and west are represented as actors whose autonomous behaviour supplies cars to their respective queues. The traffic lights are assumed to be in-sync and are passive actors. A single monitor combines data from the cameras that detect the current queue levels at the two approaches.

Fig. 5.

Actor monitors (Color figure online)

We will consider the simulation under three levels of monitor control: (1) To test the simulation we leave one of the traffic lights stuck on red and the other on green; (2) The monitor is even-handed and allows traffic to pass where there is a queue; (3) The monitor gives preference to the traffic from the east unless a queue has formed on the western approach and has not moved for a given time period.

The simulation has been encoded in ESL which includes a facility to produce a filmstrip consisting of a sequence of diagrams generated from simulation data. Figure 5 shows filmstrips generated using the three different monitor strategies. Figure 5a shows three snapshots at times 0, 6 and 40: the lights are stuck on green for east-west and red for west-east and therefore a queue soon builds up on the western approach. Figure 5b shows the situation with an even-handed monitor where, since the east-west traffic is more frequent, a queue quickly builds up. Figure 5c shows the situation at four different times where the monitor prefers east-west traffic, but attempts to prevent queues lingering for too long at the west-east approach. At time 17 a queue has developed and the monitor adapts the traffic light behaviour to clear it by time 25. At time 96 queues have built up on both approaches, but the strategy has cleared them by time 148. Based on the assumptions made by the simulation, the third monitor strategy would seem to be a good one and can be encoded in the monitor language as follows:

The definition is used to define a monitor that must hold over previous time units. The monitor consists of three rules that hold at all times and is applied to a pair of monitored actors (the west and east traffic cameras) whose histories can be indexed using the split operator . The first rule on line 3, states that if the west approach has a queue length that has been waiting for time units then the lights should be changed . The rule on line 4 gives queuing traffic on the eastern approach precedence over that queuing on the western approach. A monitor must be satisfied, so on line 6 ensures that we can move on to the next time unit.

4 ESL

The previous section has introduced a language for actor based monitors. The language has been implemented as a library using ESL² which is an actor language designed to support simulations. ESL combines functional and actor-based programming and provides a number of novel features that we believe are important when representing systems with emergent behaviour. The rest of this paper introduces ESL and uses it to define the monitor library. We will conclude with a real-world simulation written in ESL that uses monitors. Section 4.1 provides a brief overview of ESL syntax, Sect. 4.2 describes the operational semantics of ESL in terms of a system executive, and Sect. 4.3 implements a standard actor-based example and shows how it executes concurrently in ESL.

Fig. 6.

ESL syntax

4.1 Syntax

The syntax of ESL is shown in Fig. 6. It is statically typed and includes parametric polymorphism, algebraic types and recursive types. Types start with an upper-case letter. An ESL program is a collection of mutually recursive bindings. Behaviour types are the equivalent of component interfaces and behaviours are equivalent to component definitions. A behaviour is instantiated to produce an actor using in the same way that class definitions are instantiated in Java. Once created, an actor starts executing a new thread of control that handles messages that are sent asynchronously between actors. Pattern matching is used in arms that occur in -expressions and message handling rules. Uncertainty is supported by that evaluates in of cases, otherwise it evaluates . Functions differ from actors because they are invoked synchronously.

A minimal ESL application defines a single behaviour called , for example:

An ESL application is driven by time messages. The listing defines a behaviour type (line 1) for any actor that can process a message of the form where is an integer. In this case, the behaviour defines two message handling rules. When an actor processes a message it tries each of the rules in turn and fires the first rule that matches. The rule on line 3 matches at time and calls the system function which will halt the application. Otherwise, nothing happens (line 4).

4.2 Operational Semantics

ESL compiles to a virtual machine code that runs in Java. Each actor is its own machine and thereby runs its own thread of control. Figure 7 shows the ESL executive that controls the pool of actors. When the executive is called, the global pool contains at least one actor that starts the simulation. Global time and the current instruction count are initialised (lines 3 and 4) before entering the main loop at line 4; the loop continues until one of the actors executes a system call to change the variable .

Fig. 7.

The ESL executive

Lines 6–7 copy the global pool so that freshly created actors do not start until the next iteration. If an actor’s thread of control has terminated (line 9) then a new thread is created on the actor’s VM by scheduling the next message if it is available. The operation continues with the actor’s thread of control on a machine that runs a call-by-value functional language [1] extended with actor-based features such as asynchronous message passing.

The executive schedules each actor for VM instructions. This ensures that all actors are treated fairly. Once each actor has been scheduled, the existing actors are merged with any freshly created actors (line 13).

The executive measures time in terms of VM instructions. Each clock-time in the simulation consists of instructions performed on each actor. When actors need to be informed of a clock-tick (line 14), global time is incremented (line 16), the instruction counter is reset (line 17) and all actors are sent a clock-tick message.

4.3 Factorial

ESL Messages are sent asynchronously between actors. An actor that is at rest selects a new message and processes it in a thread that is independent of other actor threads. When the thread terminates, the actor is ready to process the next message. Consider the concurrent processing of factorials:

An actor of type receives an integer value . An actor of type receives a request for the value to be sent to the customer . The behaviour implements and is the end-point for factorial-calculations: when it receives it prints out the result.

The behaviour implements using two message-handling rules. The first handles and just passes the value to the supplied customer. The second rule receives a request for a factorial of a non-0 number . An actor with behaviour is able to handle multiple factorial requests at the same time. To do this it creates an auxiliary customer that is used to handle the return value from : this is equivalent to distributing the linked stack-frames of conventional singly-threaded computation to an equivalent number of concurrent customer actors. The behaviour implements and forwards to the pending customer .

An actor with behaviour calls three times. Figure 8 shows the resulting message traces as a sequence diagram. Each of the actors is shown as a box with a life-line. Messages sent between actors are shown as arrows between life-lines and are labelled using the following convention where is the time at which the message is sent and is a label used to identify each separate calculation of . Messages are encoded to show the different steps: is the initial message, is a message to calculate with as the intermediate customer and as the requesting customer, is the recursion termination step, and shows the return values between customers.

The sequence diagram shows that the three factorial calculations occur concurrently. The customer actors correspond to conventional stack frames in a singly-threaded language where the calls to factorials occur in sequence and are appropriately nested. Mapping actors to conventional languages has been the subject of several research projects [17, 27] where monitors such as those described in this article may be an interesting implementation consideration.

Fig. 8.

Concurrent factorial

5 Monitor Implementation in ESL

Section 3 introduced an actor-based monitor language and Sect. 4 describes the actor language ESL. This section shows how monitors can be implemented as actors by defining a pair of actor types: for a class of behaviours that export histories over type , and for a class of behaviours that monitor histories of type .

Given that actors are autonomous, we require a mechanism to synchronise monitors and actor histories. The basic mechanism is described in Sect. 5.1 and then encoded in ESL as described in Sect. 5.2.

5.1 Processing Histories

A history is a list of public state information and as such each monitor processes a list of data. For example, suppose that we want to express a monitor that causes action to be performed every time a sequence of 3 fails, , is detected:

The predicates and are defined to detect the appropriate state elements. The history formula uses the operator to compose three detectors one after another in the history. The operator is used to advance through the history. Finally, the history predicate combines the three detector with an alternative detector that skips a state value. The monitor checks first, if fails then is checked, so line 12 will use three ’s as a guard on the action , if the guard fails then the head of the history is skipped.

The history of an actor is produced incrementally over time. Therefore an expression written in the language defined in Fig. 3 must continually monitor the actor’s history. The expression can be thought of as a state machine whose nodes correspond to monitor states and whose transitions consume parts of actor histories. Each transition is triggered by a clock-tick and can proceed when there is some history to consume, otherwise the machine must stay in its current state and try again when the next tick occurs.

Figure 9 shows the machine corresponding to . Each transition is triggered by a clock-tick, the labels on the transitions are: $\epsilon$ when no history is available; occurs when the next state element in the history is an ; $\ocircle$ occurs when there is at least one element at the head of the history and causes the element to be consumed; * denotes the situation when the next state element in the history is anything but .

Fig. 9.

A monitor state machine

5.2 Monitor Implementation

The implementation of monitors in ESL has four parts: (1) An actor type for a class of monitored behaviours, (2) A compositional data type that allows monitored actors to be combined, (3) An actor type for a class of monitors, (4) The definition of the operators in Fig. 3. This section addresses each of these parts in turn.

Monitored Behaviours: An actor that can be monitored must export a list of data values called . The order of the values in the history is important since it corresponds to the temporal operators in the monitor language. The actual type of the data elements in the list is not important so the definition of the type is parametric with respect to the type :

Composition: As shown in Fig. 2, monitors may be attached to single or multiple actors. Therefore, we require a mechanism that will combine the histories of two actors into a single history. Such a binary operator, can then be used successively to compose an arbitrarily large history that can be processed by a single monitor.

The type is the type of potentially aggregated monitored actors. Given a single monitored actor , we create an aggregate singleton . Given two aggregate monitored actors: and the composition is also an aggregate monitored actor. The data type is defined below:

Monitor Behaviours: A monitor can be sent a message that causes it to check whether it holds for the monitored actor . The integer is an index into the history that is exported by and represents the current time. Checking whether the monitor is satisfied or not by at time may be delayed while waits for to produce the required amount of history. Therefore, must keep polling for its history until it can determine whether it is satisfied. At this point is either satisfied with the history or not. These two outcomes are handled by the arguments and in terms of success and fail continuations. The argument is a monitor to which will send when it is satisfied. The argument is an operation that is invoked in the case that is not satisfied with at time . The data type is as follows:

Operator Definition: The monitor behaviours are defined in Fig. 10, note that where the clock-tick handler is it is omitted. A monitor of type is created by instantiating a behaviour with type ; for example, . A monitor is activated by sending it a message where is a tree of monitored actors, is the current history-index (initially ), is a success-monitor, and is a failure-monitor. The behaviour of each type of monitor, as defined in Fig. 10, is outlined below:

Fig. 10.

ESL monitor behaviours

• immediately activates the success-monitor by sending it a message. The global actor can be used as the identity monitor.

• receives a message, performs the command , and then activates the success-monitor.

• forwards the message to and creates a new success-monitor .

• forwards the message to using as the fail-monitor. Therefore, will be tried in the case that fails. Both and will use as their fail-monitor.

• tries both and in parallel and assumes that only one will succeed.

• checks the monitored actor using p with respect to history-indices , , etc. Note that checking occurs in parallel with all other monitors and any check with respect to a particular history-index will wait, due to the definition of , until the indexed history element has been generated by the monitored actor.

• checks the monitored actor using p with respect to history-index .

• if holds then should also hold, otherwise the fail-monitor is used.

• checks the monitored actor using p with respect to history-index .

• when this monitor is activated by a message, the history element at index is checked using guard . If the result is then the success-monitor is activated, otherwise the fail-monitor is activated. Note that if an element at index is not yet available, the monitor sends itself a message that will be processed at some time in the future, thereby delaying the guard. Note also that the monitored actor is actually a tree: it is the responsibility of the monitor to use and to access a leaf of the tree when applying a guard.

• recursive monitors are created by supplying a function whose argument is a cyclic monitor. For example:

  

  is a monitor that will expect a history to contain an infinite sequence of s.

5.3 Traffic Monitoring

Section 3.2 describes a simple use of monitors to achieve adaptive behaviour at a traffic light. This section provides the ESL implementation of the simulation and shows how the adaptor language works by providing a fragment of the resulting sequence diagram.

The ESL program in Fig. 11 is a slightly simplified version of that which generates the outputs shown in Fig. 5 where the details of generating sequence diagram output have been omitted. The behaviour type is a sub-type of and exports a history of integers being the time-sequenced number of cars queuing at an approach. An approach actor is created by supplying the behaviour with an identifier, a traffic light and the probability of new car arrival. Two approaches called and are created and the operations and are used to control the traffic lights.

Each approach is autonomous and receives a message at regular intervals. When this occurs, either a new car will arrive or the next available car will move from the approach if the lights are green.

Fig. 11.

The traffic simulation

Fig. 12.

Initial messages sent by traffic monitor

The monitor defined in Sect. 3.2 is attached to the monitored actors and by creating an aggregate . Figure 12 shows the initial steps performed by the simulation and its associated monitor. The actors are labelled with their unique identifier and behaviour where stands for the behaviour , is the left approach and is the right approach. Messages of the form are represented on the sequence diagram as since the failure continuation is not particularly informative. Message passing starts at actor which is created by the monitor definition for . The behaviour creates a loop that is used to increment the history counter that starts at and is incremented twice by successive messages from to . Notice that the left and right approach actors concurrently queue and de-queue cars at the same time that the monitor is processing their histories.

6 Evaluation

Our claim is that actor-based systems can benefit from monitors that meet the requirements outlined in Sect. 1.2 and in particular actor-based simulations can use monitors to encode adaptive behaviour. We have proposed a monitor-language and shown how it can be encoded in an actor language called ESL. This section evaluates the claims by describing a real-world case study that we have implemented in ESL and that uses monitor-based adaptation to influence actor behaviour.

6.1 Case Study Overview

The cash in circulation in the Indian economy has steadily been increasing over the years. In 2001, the total cash in circulation was 2.1 trillion rupees and by early November it had reached 15.4 trillion. On November 8, 2016, the dominance of cash-based transactions and the relentless growth of a shadow economy triggered a sudden fiscal intervention by the Indian government with the withdrawal from circulation of 500 Rupees and 1000 Rupees notes. This action resulted in 87% of the total cash in the system being pulled out. The primary objective of this demonetisation was seen as a way of purging black money from the system with the key assumption that such a large amount of money would not come back to the system as holders of illicit wealth would be wary of prosecution by tax authorities. Further, cash would be slowly replenished with newly minted currency notes.

The initiative involved several financial restrictions. For example, a limitations were imposed on the exchange of old notes wherein the citizens were allowed to exchange up to 4000 rupees with the remaining deposited to their bank account; ATM withdrawal limits were reduced to 2000 rupees in a day for Indian citizens, and there was a cap of 10,000 rupees on bank withdrawal in a day along with a weekly withdrawal restriction of 20000 rupees per citizen. In addition to these restrictions, cash-less payment modes, such as mobile wallet and card payments, were incentivised. For example, on Dec 8, e-transactions for fuel included a 0.75% discount. Despite all preventative measures, the demonetisation initiative resulted into prolonged cash shortages. Citizens were inconvenienced due to non-availability of new currency notes in the banks and ATM machines. Even as recently as Feb 16, estimates indicate that at least 30% of ATMs still run dry. Overall, the initiative has faced a lot of criticism as being poorly thought through, inadequately planned, inefficiently executed and unfair to a significant segment of cash dependent citizen³.

6.2 Adaptation

When creating a simulation of the demonetisation case study, adaptation occurs in a number of ways. The banks, commercial suppliers, and citizens were continuously monitoring and adopting their behaviour to cope with the emerging situation. For example, banking transaction limits were changed multiple times to control cash flow, commercial suppliers adopted alternative payment options to stay viable, and citizens changed their behaviour to avoid undesired consequences.

The behaviour of citizens changed along multiple dimensions: (1) individuals started using alternate payment modes such as mobile wallet and credit/debit cards; (2) individuals changed their needs and suppliers catering to those needs so as to support cash-less transactions; (3) some individuals felt a greater sense of security in having cash-in-hand in excess of their requirements, i.e. hoarding behaviour emerged.

These adaptations to individual behaviour collectively impacted the overall system in a non-linear manner. In particular, the frequent changes to banking transaction limits, uncertainty in availability of cash with banks and ATM machines, circular dependencies between availability of cash and behaviour of individuals, and non-linearity in cash-in-hand of an individual and cash hoarding tendency led to an emergent system behaviour.

The use of actors and actor-monitors within a simulation can help to understand the effect of demonetisation. Actors are used to encode the individual behaviours and monitors are used for post-demonetisation adaptations.

6.3 Case Study Model

We formulate a society comprised of three key identities: Citizens, Banks, Shops, and a basic element termed Item as shown using a class diagram in Fig. 13. The term Item represents the needs of citizens that include merchandise and services; shops are the locations where items can be purchased and services can be acquired. The activities that we consider: citizens consume items to cater to daily needs; citizens purchase items from shops when the item quantity dips below a threshold value; citizens withdraw cash when cash-in-hand dips below a threshold value. A citizen may hold Cards, and a citizen who holds a card may choose to pay by cash or by card for a purchase, and may withdraw cash from ATM machine or bank counter. In contrast, a citizen without a card always pays by cash and withdraws cash from bank counters. The purchase behaviour and cash withdrawal behaviour are illustrated using state-machines in Fig. 14 (the firm lines describe the pre-demonetisation behaviour).

Fig. 13.

Structural representation of society

Fig. 14.

Citizen behaviour

We assume citizens are able to satisfy their daily needs i.e., poverty and other societal aspects are not considered in the case study. We further consider: there is sufficient cash with the banks to service citizens through ATMs and Bank counters i.e., no denial of service from bank; there is sufficient stock in shops; and citizens are able to withdraw cash when in need during pre-demonetisation phase. We replicate demonetisation by eliminating cash abruptly from banks and citizens, and replenishing cash at slow rate (around 0.7% of cash in circulation at pre-demonetisation) up to a certain percentage (e.g., 70% of cash in circulation at pre-demonetisation). The key identities of society start behaving differently during post-demonetisation phase. They adopt different strategies which are very specific to individuals. The adaptation strategies considered in this case study are:

(1) Bank: banks impose restrictions on cash withdrawals e.g., ATM withdrawal limit is 2000 rupees in a day for a citizen, bank withdrawal limit is 10,000 rupees in a day for a citizen, and the weekly withdrawal limit is 20000 rupees per citizen. These changes are deterministic and associated with the demonetisation event.

(2) Shop: shops may (a stochastic behaviour) adapt themselves to accept alternate payment options such as mobile wallet and card payment whenever they observed a drop in sales record.

(3) Citizen: a citizen, as an individual, may adopt (as a stochastic behaviour) an appropriate strategy (with multiple options selected based on personal intuition and experience) to avoid entering an undesired state. The strategies can be visualised along two independent dimensions: Payment Pattern: Citizens start using mobile wallet and/or card as a payment option to save cash for the future. However, not everyone will start using alternate option, an individual’s decision will be based on several factors such as availability and familiarity with payment technology, and whether the citizen is an early or late adopter. Cash Withdrawal Pattern: A group of citizens may start making attempt to withdraw cash (from ATM machine and/or Bank counter) even when the cash is not required (temporary hoarding behaviour) to safe guard from future consequences.

6.4 Case Study Monitors and Adaptation

The case study exhibits a variety of adaptive behaviour each of which is realised using monitors of the types shown in Fig. 2. For example, a shop tries to understand the situation in terms of its sales target, and adapts if the sales target is not met. A citizen observes the financial status (of itself and others) and adapts depending on circumstances; for example, one citizen may choose an alternate payment option as a mobile wallet, whereas another citizen may adapt to cash hoarding behaviour to avoid a cash shortage.

Fig. 15.

Case study adaptors

In this case study, the shops and citizens exhibit significant individualistic behaviours and often adapt new strategies to deal with changing situations. A set of shops may change their behaviour proactively immediately after the demonetisation event, whereas another set of shops may wait until they observe a significant decline in sales before changing their behaviour. We attach a single event based monitor to represent the former scenario, and a simple history based monitor to represent latter.

A citizen may adapt their behaviour (a) right after the demonetisation event, (b) on demonetisation followed by several consecutive failures to authorise transactions, (c) when they observe low cash-in-hand for a given number of days and are unable to withdraw cash, or (d) when they observe a given number of citizens with multiple authorisation failures. Thus we see the need for all types of monitors to represent citizen adaptation. In contrast to citizen and shop actors, the bank actor primarily follows standard regulations that are defined by a government actor. Hence we associate a monitor actor with the government actor and allow government to control banks through their event interactions.

6.5 Simulation Organisation

We set up a simulation by forming a society with actors representing the government, citizens, shops, and banks. Monitors are attached to shop and citizen actors for specifying the individualistic adaptation. The simulation progresses with a time event that represents a ‘day’. Each day, citizen actors consume items, buy items from shops if any item is below a certain threshold, pay for the purchases, and make an attempt to withdraw cash if needed. Similarly, bank actors try to stock up cash to fulfil ATM and Bank withdrawal requests, and shop actors stock up the items for their customers. The government actor triggers ‘demonetisation’ at specific day of a simulation run.

We divide a simulation run into three phases: setup, pre-demonetisation, and post-demonetisation. Figure 16 shows part of the simulation: the levers are displayed in the top left hand corner and the measures are displayed in real-time as the simulation progresses. Pre-demonetisation is an observation phase to validate conditions that include (a) cash at banks are adequate to serve all citizens i.e., no denial of service at ATM machines and Bank counters; (b) the stock are sufficient at each shops to serve their citizens; and (c) citizens can buy items and withdraw cash as needed. This phase also monitors the cash-flows to the banks, and cash in circulation.

Fig. 16.

Case study dashboard

Fig. 17.

Case study results

In this simulation setting, we firstly observe the impact of demonetisation by removing cash and reducing cash-flows. We then explore various what-if scenarios by changing the parameters and/or by attaching different actor monitors to understand the impact of courses of action. For example: the impact of demonetisation if the government replenishes cash at a faster rate, or the impact if the government decides to replenish 60% cash instead of 70%. Similarly, one can explore the impact if none of the citizen exhibits cash hoarding behaviour by detaching the monitors that are responsible for cash hoarding behaviours. In this paper, we limit our analyses to two scenarios (a) understand the effect of demonetisation for standard setting that closely represents the real Indian demonetisation event, and (b) understand the positive/negative effect on overall society when there is no hoarders. We have chosen these two relatively intuitive scenarios to illustrate the efficacy of using actors and monitors.

6.6 Simulation Results

We simulated the demonetisation case study with one government, one bank, 15 shop and 1710 citizen actors for 150 days, where the first 15 days are considered for setup phase, next 30 days are the pre-demonetisation phase, and 105 days are the post-demonetisation phase. A snapshot of ESL simulation dashboard at the day of 115 (i.e., after 70 days of demonetisation) is depicted in Fig. 16. The dashboard shows useful states of the society and its identities: the ‘Citizen Type’ table describes the citizens and their card/wallet usage capabilities, (b) the ‘Payment Distribution’ pie chart shows distribution of Card (green), Wallet (blue) and Cash (red) payments, (c) the ‘Payment Transaction Volume’ chart describes the history of overall payment transactions where card transactions are green, wallet transactions are blue, and cash transactions are red, (d) the ‘Cash Availability in Bank and ATM’ graph shows the history of cash availability at Banks and ATMs using red and blue respectively, (e) the ‘Transaction Declined Rate’ graph describes the denial of service at Banks and ATMs using red and blue respectively. In addition, the ‘Citizen with no Cash’ and ‘Citizen with excess Cash’ charts describe the financial condition of the citizens: the former chart describes the number of citizens having considerably less cash, and the latter represents the number of cash hoarders (the red, blue, green and yellow colours signify the cash dependent citizens, cash and wallet dependent citizens, cash and card dependent citizens, and citizen with all facilities respectively as classified in table). The ‘Citizens without essential commodities’ and ‘Citizen facing inconvenience’ charts represent the number of citizens starving for essential items and luxury items respectively.

We observe that the graphs are unstable for first 15 days of the simulation runs as the simulator is trying to set the values based on actor behaviours and their interactions. The simulation outcomes for pre-demonetisation phase is stable: no bank withdrawal request is denied, no citizen is facing any financial crisis, and citizens are not having any deficiency for essential or luxury items. The demonetisation event is triggered at day 45, causing a sudden reduction of cash from the bank and ATM machines. Subsequently, the withdrawals from bank and ATM decline whilst wallet payment and card payment increase significantly: the citizens have started facing a financial crisis and the citizens who are solely dependent on cash have started starving for essential and/or luxury items. The adverse effects continue for almost 50 days and then the situation returns to normal.

As we can observe in graph with title ‘Citizen with excess cash’ in Fig. 16, 115 citizens started hoarding cash when the situation is on the verge of returning back to normal. One may hypothesise that cash hoarding behaviour is significantly slowing down the stabilisation process. We validate the hypothesis on hoarding behaviour by removing the monitors that are responsible for turning a citizen into a cash hoarder. We simulated the same society with no hoarders, and relevant simulation results are depicted in Fig. 17. We observe improvements in ‘cash in bank and ATM’ and ‘transaction declination rate’ for the society with no hoarders. The cash condition is returning back to normal in 40 days instead of 50 days. Thus the result is supporting the hypothesis regarding hoarding behaviour and also providing an indication of possible improvement.

7 Conclusion

This paper has proposed a homogeneous actor-based language for monitors that achieve adaptive behaviour. It is interesting because we have used the prevailing LTL-based approach to expressing behaviours in actor and multi-agent systems in order to define monitors that are also actors and therefore can be freely mixed with other actors at run-time. The language has been given a semantics by defining it using ESL which is a function-oriented actor language and we have demonstrated the utility of the approach using a real-world case study based on the recent demonetisation event in India. The case study demonstrates how monitors are used in the context of a simulation that exhibits emergent behaviour.

A number of limitations are identified in this work. The example described in Sect. 6 involves several thousand actors, and completes a simulation in roughly 30 s. We recognise the need to scale up to more realistic actor configurations which may then require further investigation in how to make actor behaviour, including adaptation, more efficient. A larger simulation model of our case study would also allow us to calibrate more precisely the simulation results with real world events as documented in the Indian national newspapers. As with all actor based simulations, the results need to be carefully interpreted given the underlying assumptions which we make given the complexity of the example. Regardless, the ability of the language to define actors with their own behaviours and adaptations and the flexibility for testing different conditions provide a means evaluating different policies and options. The ability to visualise and quantify the simulations results is also promising but again, we recognise that much more work on visualisation is required. Time in this simulation remains challenging however, we are similar in our approach to other efforts to map simulation time with real world time. Our monitor language semantics is currently defined using ESL which is currently in use in our research groups. It may be appropriate to document other options for defining the semantics of the monitor language to demonstrate other external validity routes.

ESL, simulation and adaptive behaviour are active areas of our research. An interesting extension of this work would be to specify the structure of histories, perhaps using pattern based rules, and then to verify that monitors are consistent with the monitored actors to which they are applied. Other case studies are also being explored to validate the technology and to produce a simulation development method based on ESL.