Using a Tense Logical Language to Handle ...

risø scenario assistant

The SCENARIO ASSISTANT: Using a Tense Logical Language to Handle Scenarios Supporting Training of Coordination and Communication Peter Øhrstrøm Dept. of Communication Aalborg University e-mail: [email protected]

and

Henning Boje Andersen Systems Analysis Dept. Risø National laboratory e-mail: [email protected] Abstract: This paper outlines a prototype system using temporal logic to describe, reason about and control training scenarios. Organisational aspects of coordination involved in training scenarios are discussed with respect to the temporal aspects of the communication and control. A tense logical specification language developed to support the planning and execution of execution and analysis of training scenarios, which has been implemented in the `SCENARIO ASSISTANT system, is characterised. The system is described using a fictitious example involving a railway accident. Finally, it is suggested that a further development of the system using tense logic may provide a logical tool for designers of training scenarios and that this may possibly be a realistic alternative to traditional testing of iterative implementations. 1. Introduction The SCENARIO ASSISTANT is a prototype system designed to illustrate the feasibility of using a flexible computer-based tool to support the planning, scenarios for emergency management. We describe the motivation for developing this type of system in the following section, but first we wish to outline briefly the project context in which the SCENARIO ASSISTANT has been developed. Risø National Laboratory has been involved in two international projects to specify and develop a computer-based training system for emergency management.[1] The work on Side 1

risø scenario assistant

the SCENARIO ASSISTANT has been inspired by the parallel work in these projects - see e.g. [Andersen and Andersen, 1995]; [Andersen, Andersen and Larsen, 1995], and [Balducelli et al., 1995]. However, the functionalities and especially the formalisms and underlying logic of the SCENARIO ASSISTANT, being based on tense logic, differ substantially from the system described in the aforementioned papers. It is therefore natural to describe the SCENARIO ASSISTANT separately. The central and generic part of the SCENARIO ASSISTANT is based on a metrical tense logic corresponding to a discrete branching time model. The system is meant to support, first, a training supervisor in setting up a specific virtual world, namely an emergency management training scenario, that allows for any one of several event trajectories; and second, the system will generate a logical database which can be used for the execution of such a scenario through controlling the i/o between trainees and 'external simulation modules' (simulation fires, plume dispersions, traffic and evacuation behaviours etc.) and allowing the training supervisor to intervene when predefined privileges permit this. The supervisor is allowed, in the planning phase, to introduce the kind of objects, places, accidents (events), and actions he wishes a given scenario to involve. In order to do so, he needs a specification language (i.e. a dictionary and a formalism) in which the properties and functional relations of the system can be described. In the following we are going to present the general features of the prototype, being a preliminary implementation of the SCENARIO ASSISTANT.[2] 2. Background There is a growing recognition that the efficiency of the response of an emergency management organisation depends crucially on communication and the coordination of actions among decision makers involved. While problems of coordination - "who is doing what, where and when" - affect the efficiency of most emergency management (EM) organisations, they are, it appears, especially pernicious in the case of major emergencies, where several EM organisations need to coordinate efforts. Large-scale emergencies will typically include heterogeneous organisational bodies such as fire brigades, civil protection authorities, police, transport authorities etc. Again, these separate bodies are known to have delivered inadequate and often belated emergency response due to coordination and coomunication problems both among and within separate organisational bodies. This is partly because EM organisations are heterogeneous, partly because they are typically involved in joint operations quite rarely (except for fire brigades and police who often work together). At the same time, it is at present a major and very complex undertaking to evaluate the EM preparedness of any medium- or large-scale organisation. Hence, it is nearly always difficult to identify what are the key areas in which EM response capability should be improved; i.e., whether resources and efforts are best spent in training specific capabilities, improving means of communication and decision system support, providing better hazard-fighting resources, revising procedures etc. Equally, it is laborious and intricate to demonstrate that the capability Side 2

risø scenario assistant

of an EM organisation meets required standards - full scale exercises involving numerous organisations are prohibitively expensive. Thus, the need for supporting collaborative training and evaluation is compelling in the context of emergency management, not least because field exercises are prohibitively expensive to plan and execute when they involve decision makers belonging to several organisations. It is therefore natural to seek a solution along the lines of a synthetic environment in which decision makers may train communication and coordination skills and procedures. The proposed solution of the MUSTER project (see note [2]) has been to develop methods and an accompanying prototype tool which support training and evaluation by running multi-user simulations of EM scenarios and other parts of the distributed EM system. The simulations are interactive in so far as their course and outcome depend on the responses of the distributed trainees (EM operators and decision makers). 3. Specification language The purpose of the specification language is, first of all, to provide a tool for the training supervisor's configuration of the system. The objects, places, accidents (events), and actions are, we assume, all named by the supervisor. (Of course the supervisor will typically introduce only such objects etc. as are realistic and essential i.e. he will typically not introduce unrealistic amounts of resources, whereas he may want to introduce very rare hazardous objects). The supervisor may interactively introduce a number of objects, places, accidents, and actions (using arbitrary strings as names). Let us assume that the finite sets OBJECTS, PLACES, ACCIDENTS, and ACTIONS have been introduced. We shall call the set theoretical union of ACCIDENTS and ACTIONS `EVENTS'. Thus, EVENTS = ACCIDENTS U ACTIONS. We also assume that each element of OBJECTS is specified as belonging to a certain category (like persons, trains, cars ...) and that each element of EVENTS relates either to an object from the specific category or to an integer. So, a basic proposition in our specification language is either of the form now(Ev,Obj,Pl) which is read: "The event Ev is now occurring at the place Pl in relation to object Obj", or on the form now(Ev,N,Pl) which is read: "The event Ev is now occurring at the place Pl in relation to N objects of the category related to Ev", where Ev belongs to EVENTS, Pl belongs to PLACES, Obj belongs to OBJECTS, and N is an integer. Let A be any basic proposition. For any integer x, we define f(x)A which will be read "A will be the case in x time units" and p(x)A which will be read "A was the case x time units ago". If A=now(e,y,s) we shall for simplicity reasons use the forms f(x,e,y,s) and p(x,e,y,s) Side 3

risø scenario assistant

corresponding to the tense logical propositions f(x)A and p(x)A. In the present version of the system only propositions on the forms f(x)A and p(x)A will be allowed as input. (In future versions more complications may be added.) In the full language corresponding to the deductions made by the system negations, conjunctions etc. are also included. The proposition f(x)A is interpreted as a 'danger proposition' (or an 'expectation') in the sense that A will occur in x time units provided no preventing actions is performed. In this way the logic involves a notion of modality since the preventing actions may or may not be performed at various instants. The dynamics of the example in question is introduced by the supervisor as a number of axioms regarding causality and prevention, respectively. The axioms are formulated in terms of a Next-operator and two databases corresponding to the predicates 'causal' and 'danger'. The general form of an element causality database is causal(A,f(x)B), where x is an integer with x>0. whereas the general form of an element in the danger database is danger(A,p(x)B), where x is an integer with x>0. The axioms used in our system are:

where prevented(A) is fulfilled if there is an element in the danger database in the form danger(A,p(x)B) so that is p(y)B is the case for some y greater than or equal to x-1. (We use p(0)B and f(0)B as equivalent with B.) From the set of propositions which hold (occur) now we can construct a new set of propositions for each of which Next(A) holds. This new set can give rise to yet another set of propositions etc. Our system is implemented using this procedure. Logically, this means that the axiom

holds along with the modus ponens and the deduction rule according to which Next(A) is a theorem whenever A is a theorem. Side 4

risø scenario assistant

4. An Example: A Train Accident We shall illustrate the design of the system by referring to a ficititious train accident near Fredericia railway station in Denmark. This example, which was developed in the MUSTER project (note 2) and used similarly to illustrate the functionalities of the MUSTER-system has been constructed as a fictitious scenario by domain experts (railway accident investigators. fire brigade leaders, police etc.). Perhaps it needs emphasis that although the example is fictitious, its elements have all been components of real events in recent years, either in Denmark or in other European countries. Indeed, it was the intention that the example would appear `realistic' to outside domain experts. The story can be presented in the following way:

The above text is included in the file 'Trains' as indicated on the screen. When running the system the trainee is supposed to be in charge of the operations immediately after the railway accident. The communication possibilities in the organisational context in which he finds himself can be modelled in a very simple way:

According to this model the trainee will receive messages from three locations and he will be able to communicate a number of orders (and thereby have the corresponding actions performed).

Side 5

risø scenario assistant

The communication possibilities as well as the dynamics of the system can be described by the supervisor in terms of the following language:

In some cases we may want to describe accidents (events) using other items than physical objects (e.g. numbers). For this reason we shall use the term 'specification' which is supposed to include 'objects'. The specifications, places, accidents (events), and actions are supposed to define a virtual world, which will also be characterised by some `dangers':

Side 6

risø scenario assistant

The meaning of this 'danger-proposition', f(1,ra,gt,f1), is that in one time unit from the present time, a railway accident (ra) will occur involving the goods train (gt) at Fredericia, track 1 (f1). When the 'Help' button is double-clicked the following window is displayed:

Note that logical language used here is a metrical tense logic. This language can also be used for the description of the causality in scenario:

Again an explanation of the formalism can be obtained by using the 'Help' button:

Side 7

risø scenario assistant

The causality relations can obviously generate new dangers. However, dangers can be prevented by certain actions:

These relations describe how certain actions can prevent certain dangers. When the 'Help' button is double-clicked the following explanation is displayed:

Side 8

risø scenario assistant

The virtual world corresponding to the scenario is supposed to be fully specified at time=0 i.e. a set of initial conditions like propositions about the present on the form now(x,y,z); propositions about the past on the form p(n)A (or: p(n,x,y,z)); danger-propositions on the form f(n)A (or: f(n,x,y,z)); are given. From this set a new set of propositions corresponding to the next instant in a discrete time series can be calculated using the causality relations and the possible preventions generated by the actions performed. The supervisor may, in a very simple way, interact with the system running the simulation of the scenario and he may choose when and which actions he will perform. The interaction with the system may look as follows: 0: Railway_accident goods_train Fredericia_track1 2: stop_train train1 Vejle 10: Poison_leakage goods_train Fredericia_track1 10: traffic_complaints Vejle 12: poison_spec_called Fredericia_track1 20: Poison_leakage goods_train Fredericia_track1 20: wounded_persons Fredericia_track1 20: Railway_accident train2 Fredericia_track1 20: traffic_complaints Vejle 22: ambulance_called Fredericia_track1 23: alt_transport_estab Vejle

All the messages are timed and the syntax of the messages themselves is fairly straight forward, although one might make them even more readable by adding a natural languages facility to the system.

Side 9

risø scenario assistant

5. Further Remarks about the Underlying Logic. There are two kinds of temporal logic, which are often termed A- and B-logic, respectively. A-logic corresponds to the tense-logical approach, which is used here. B-logic, on the other hand, involves the quantificational approach. A-logic is based on axiomatics without any need for references to branching time models (or other models of time). B-logic refer directly to times (or instants) and to the ordering of event (before and after). However, if our system is embedded in a logic for which soundness and completeness can be proved relative to a certain class of semantical models, the two approaches are in fact equivalent. The semantical models corresponding the system sketched here are branching time models, since any possible action can be seen as giving rise to a branching point in the model. It should also be emphasised that it is meaningful in the system to speak about the future as it may expected to develop if none of the possible actions are carried out i.e. there is a default trajectory in the branching time system corresponding to the assumption that the trainee is completely passive. In this sense the system can be said to be what A. N. Prior has called an Ockhamistic branching time logic cf. [Øhrstrøm and Hasle, 1995, p. 211 ff.]. One of the advantages of A-logic as compared with B-logic is that it is simpler and shorter. Another and more important advantage is that the use of tense logic makes it possible to prove general properties of the system as suggested by Amir Pnuneli [1977, 1981] and others cf. [Øhrstrøm and Hasle, 1995, p. 344 ff.]. This means that logical proofs may turn out to be a realistic alternative to traditional testing of the implementation. Future versions of the module may in this way be extended with logical tools for the investigation of the scenario which the supervisor has introduced. For example, one might want to ask questions of the following types: - Can we be sure that it will always be possible for the trainees to obtain a certain goal, G? - Can we be sure that whenever X has occurred then Y will also sooner or later occur? In addition, it would be useful to have facilities to check that the set of action rules introduced by the supervisor is consistent. Such facilities can in principle be established using tempo-modal logic. In order to investigate these possibilities it would appear to be natural to relate the present discussion to the studies within computer science of the temporal logics CTL and LTL [Bernholtz and Grumberg, 1994], for which a number of results have already been obtained. For the evaluation of the interaction with the system performed by a trainee it might also be useful to have a formal version of what the trainee ought to do in certain situations. This might be possible by the use of deontic logic. Further investigations are needed, however, to clarify how this may be carried out in details.

Side 10

risø scenario assistant

References: Andersen, H.B., V. Andersen and M.S. Larsen. 1995. "Handling emergency management training scenarios: The MUSTER SCENARIO MANAGER" . In:.J.D. Sullivan, J.L. Wybo & L. Buisson (eds.): Proceedings of the International Emergency Management and Engineering Conference:TIEMEC-95, May 9-12, 1995, Nice France Andersen, V. and H B. Andersen. 1995. "Multi-User System for Training and Evaluation of environmental Response-MUSTER". In:.J.D. Sullivan, J.L. Wybo & L. Buisson (eds.): Proceedings of the International Emergency Management and Engineering Conference:TIEMEC-95, May 9-12, 1995, Nice France Balducelli, C., S. Bologna, G. Di Costanzo, G. Vicoli, M. Boero: "A Computerized Support System for Cooperative Training in Emergency Scenario Management". In:.J.D. Sullivan, J.L. Wybo & L. Buisson (eds.): Proceedings of the International Emergency Management and Engineering Conference:TIEMEC-95, May 9-12, 1995, Nice France Bernholtz, O. and Grumberg, O.: 1994, "Buy One, Get One Free!!!", In Temporal Logic, Lectures in Artificial Intelligence 827:210-224 Pnueli, A.: 1977, "Temporal Logic of Programs", In Proceedings of the 18th Annual Symposium on Foundations of Computer Science, IEEE, New York, pp. 46-57. Pnueli, A.: 1981, "The Temporal Semantics of Concurrent Programs", Theoretical Computer Science 13:45-60 Øhrstrøm, P. and Hasle, P., 1995: Temporal Logic - From Ancient Ideas to Artificial Intelligence, Kluwer Academic Publishers.

Side 11