Agent Based Approaches to Engineering Autonomous Space Software

M. Bujorianu and M. Fisher (Eds.): W orkshop on Formal Methods for Aerospace (FMA) EPTCS 20, 2010, pp. 63–67, doi:10.4204/EPTCS.20.6 c  L. A. Dennis et al. This work is licensed under the Creativ e Commons Attribution License. Agent Based A ppr oaches to Engineering A utonomous Space Softwar e ∗ Louise A. Dennis Department of Computer Science, Univ ersity of Liv erpool, UK L.A.Dennis@liverpool.ac.uk Michael Fisher Department of Computer Science, Univ ersity of Liv erpool, UK Nicholas Lincoln Department of Engineering, Univ ersity of Southampton, UK Alex ei Lisitsa Department of Computer Science, Univ ersity of Liv erpool, UK Sandor M. V eres Department of Engineering, Univ ersity of Southampton, UK Current approaches to the engineering of space software such as satellite control systems are based around the dev elopment of feedback controllers using packages such as MatLab’ s Simulink tool- box. These pro vide po werful tools for engineering real time systems that adapt to changes in the en vironment but are limited when the controller itself needs to be adapted. W e are in vestigating ways in which ideas from temporal logics and agent programming can be integrated with the use of such control systems to provide a more powerful layer of autonomous decision making. This paper will discuss our initial approaches to the engineering of such systems. 1 Intr oduction Modern control systems are limited in their ability to react flexibly and autonomously to changing situ- ations. The limiting factor is the complexity inherent in analysing situations where many variables are present. There are many complex, real-world, control systems but we are primarily interested in the (autonomous) control of satellite systems. Consider the problem of a single satellite attempting to maintain a geostationary orbit. Current satellite control systems maintain orbits using feedback controllers. These implicitly assume that any errors in the orbit will be minor and easily corrected. In situations where more significant errors occur , for example caused by a thruster malfunction, it is desirable to modify or change the controller . The complexity of the decision task is a challenge to standard approaches, and has led, for example, to complex, e v olutionary control systems. These become very dif ficult to understand. W e approach the problem from the perspectiv e of rational agents [6]. W e consider a satellite to be an ag ent which consists of a discrete (rational decision making) part and a continuous (calculation) part. The discrete part uses the Belief-Desir e-Intention (BDI) theory of agency [5] and governs high le vel decisions about when to generate ne w feedback controllers. The continuous, calculational part is used to ∗ W ork funded by EPSRC grants EP/F037201/1 and EP/F037570/1 64 Agent Based Approaches to Engineering Autonomous Space Software deri ve controllers and to calculate information from continuous data which can be used in the decision making process; this part can be vie wed as a hybrid system. 2 Ar chitecture Agent Part MATLAB JAVA MODEL OF SYTEM Rational Agent Part Thin Environment Layer AGENT File System Real Time Control Send Data Act Data Flow Control Flow Abstraction Engine Shared Beliefs Reasoning Reason Act Sense Continuous Calculate Figure 1: Implemented Hybrid Agent Architecture Our prototype system is shown in Fig. 1. W e ha ve implemented a simulated en vironment and real time satellite control system in MatLab using the Simulink tool kit. The continuous ag ent part is also implemented in MatLab . MatLab has no easy provision for threaded ex ecution which forces us to use separate instances for the Real T ime aspects (i.e. the feedback controller and simulated en vironment) and for the Continuous Agent part. The agent also contains a discrete agent part which is currently implemented in the Gwendolen agent programming language 1 . Gwendolen [2] is implemented on top of J A V A . The real time control system sends information (which may be pre-processed) to the agent part of the system. When it acts, the discrete part of the agent may either cause the continuous agent part to perform some calculation (and wait for the results) or it may send an instruction to the real time control system to alter its controller . Since the new controller has been created “on the fly” by the continuous part, some aspects of this controller are stored in the shared file system (accessed by both MatLab processes). The discrete agent part is divided into an abstraction engine which takes continuous data supplied by the satellite simulation and transforms this data into discrete shared beliefs which are accessed by a 1 The choice of language w as dictated entirely by con venience. It is a subject for further work to e xamine more widely used BDI-languages and ev aluate which is most appropriate for the system. L. A. Dennis et al. 65 r easoning engine which mak es decisions about how to behave. The discrete part is split in two because reasoning is comparatively slo w compared to the flow of data coming in from the simulation. It can become “clogged” up with the need to react to changing information if it tries to perform both the abstraction tasks and the reasoning tasks at once. The separation of abstraction and reasoning is both theoretically clean and practical at an implementational le vel. 3 BDI Pr ogramming Aspects The architecture lets us represent the high-level decision making aspects of the program in terms of the beliefs and goals of the agent and the events it observes. So, for instance, when the agent observes the e vent that the satellite is in a ne w position (information relayed to it by the real time controller) it can call on the continuous part to calculate whether this position is within acceptable bounds of the desired orbit (i.e. whether the existing real-time controller is capable of maintaining the orbit). If, as a result of this, it gains a belief that the satellite has strayed from the orbit it can request the continuous part to calculate a ne w path for the satellite to follow using techniques described in [4]. Similarly , if the satellite has strayed from its bounds, the discrete agent part can examine its beliefs about the current status of the thrusters and, if necessary , instruct the continuous part to generate a new feedback controller which takes into account an y malfunctions or inefficiencies in the thrusters. Such programs can be e xpressed compactly in the BDI-programming style without the need for programming large decision trees to consider all possible combinations of thruster status and satellite positions. This should then reduce the probability of error in the decision-making parts of the program and opens the possibility that existing techniques for model checking such programs [1] can be adapted to verify this part. 3.1 Geostationary Orbit Case Study The agent code for the geostationary orbit is shown in code fragments 3.1 and 3.2. Fragment 3.1 shows the code for the abstraction engine. Every time it “perceiv es” the satellite position ( stateinfo ) it calls upon MatLab to calculate whether or not this position is within bounds ( comp_distance ) and then asserts and remov es shared beliefs appropriately . The code is sho wn as a series of plans of the form trigger:{guard} ← deeds where the trigger is some e vent observed by the agent, the guard is a set of facts that must be true before the plan is acti v ated and the deeds are a stack of deeds to be e xecuted. +b is the addition of a belief, b , and -b is the remov al of the belief, b . In a guard B b means that b is believ ed. Code fragment 3.1 Geostationary Orbit Control (Abstraction Engine) 1 +stateinfo(L1, L2, L3, L4, L5, L6) : 2 { B proximity_to_centre(V1)} ← 3 comp_distance(L1, L2, L3, L4, L5, L6, Val), 4 +proximity_to_centre(Val); 5 6 +proximity_to_centre(in) : { B proximity_to_centre(out)} ← 7 -proximity_to_center(out), 8 remove_shared(proximity_to_centre(out)), 9 assert_shared(proximity_to_centre(in)); 10 11 +proximity_to_centre(out) : 12 { B proximity_to_centre(in), 66 Agent Based Approaches to Engineering Autonomous Space Software 13 B stateinfo(L1, L2, L3, L4, L5, L6)} ← 14 -proximity_to_centre(in), 15 remove_shared(stateinfo(A1, A2, A3, A4, A5, A6)), 16 assert_shared(stateinfo(L1, L2, L3, L4, L5, L6)), 17 remove_shared(proximity_to_centre(in)), 18 assert_shared(proximity_to_centre(out)); Fragment 3.2 reacts to the dynamic information about whether the satellite is within bounds or not. It may call a MatLab function, plan_approach_to_centre which returns the name of a plan to mov e a satellite back within bounds. apply_controls and maintain_path are actions applied to the simulation of the satellite which apply a named plan, or continue normal operation as appropriate. The syntax +!g indicates the acquisition of a goal. Code fragment 3.2 Geostationary Orbit Control 1 +proximity_to_centre(out) : { > } ← 2 -proximity_to_centre(in), 3 +!get_to_centre; 4 5 +proximity_to_centre(in) : { > } ← 6 -proximity_to_centre(out), 7 maintain_path; 8 9 +!get_to_centre : 10 { B proximity_to_centre(out), 11 B stateinfo(L1, L2, L3, L4, L5, L6)} ← 12 plan_approach_to_centre(P, locn(L1, L2, L3, L4, L5, L6)), 13 +!try_execute(P) ; 14 15 +!try_execute(P) : { B proximity_to_centre(out)} ← 16 apply_controls(P); 3.2 Decision and Contr ol The important aspect of both the abo ve example and the architecture in general is that the (MatLab) con- trol systems take care of the detailed calculation of continuous functions (paths, etc), while the rational agent takes care of high-le vel decisions about targets and plans. This separation of concerns simplifies both parts and av oids the problems associated with large, opaque, complex, adaptiv e and ev olutionary control systems. 4 Futur e W ork W e are currently working on our prototype system and case study which will allow us to make com- parisons of this agent approach to autonomous decision-making in satellite systems to approaches based on finite state machines and standard control. W e also are interested in in vestigating the use of tempo- ral logic and model checking to generate forward planning capabilities for the agent along the lines of those in vestigated by Kloetzer and Belta [3]. W e aim to explore the possibility of using model checking to verify aspects of the agent’ s behaviour . Gi v en that we already hav e a formal verification system for Gwendolen agents [1], there is a strong possibility that we can extend this to cope with (abstractions of) the continuous part. As the diagram below shows, we already hav e model-checking tools for the L. A. Dennis et al. 67 discrete/finite parts. Our interest now is ho w far such techniques can be extended to account for other aspects of the agent’ s behaviour . Discrete and Finite Agent Part MATLAB "Real World" JAVA Rational Agent Part Thin Environment Layer Abstraction Engine Shared Beliefs Reasoning Continuous Refer ences [1] R. H. Bordini, L. A. Dennis, B. Farwer , and M. Fisher . Automated verification of multi-agent programs. In Pr oceedings of the 23rd IEEE/ACM International Confer ence on Automated Softwar e Engineering (ASE 2008) , pages 69–78, L ’Aquila, Italy , September 2008. [2] L. A. Dennis and B. Farwer . Gwendolen: A BDI Language for V erifiable Agents. In B. L ¨ owe, editor , Pr oc. AISB’08 W orkshop on Logic and the Simulation of Interaction and Reasoning , Aberdeen, 2008. AISB. [3] M. Kloetzer and C. Belta. A Fully Automated Frame work for Control of Linear Systems From T emporal Logic Specifications. IEEE T ransactions on Automatic Contr ol , 53(1):287–297, 2008. [4] N. Lincoln and S. V eres. Components of a V ision Assisted Constrained Autonomous Satellite Formation Flying Control System. International Journal of Adaptive Contr ol and Signal Pr ocessing , 21(2-3):237–264, October 2006. [5] A. S. Rao and M. Georgeff. BDI Agents: From Theory to Practice. In Pr oc. 1st International Confer ence on Multi-Agent Systems (ICMAS) , pages 312–319, June 1995. [6] M. W ooldridge and A. Rao, editors. F oundations of Rational Agency . Applied Logic Series. Kluwer Academic Publishers, Mar . 1999.