Agent Based Approaches to Engineering Autonomous Space Software

03/02/2010 ∙ by Louise A. Dennis, et al. ∙ University of Liverpool 0

Current approaches to the engineering of space software such as satellite control systems are based around the development of feedback controllers using packages such as MatLab's Simulink toolbox. These provide powerful tools for engineering real time systems that adapt to changes in the environment but are limited when the controller itself needs to be adapted. We are investigating 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.

READ FULL TEXT VIEW PDF
POST COMMENT

Comments

There are no comments yet.

Authors

page 1

page 2

page 3

page 4

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

1 Introduction

Modern control systems are limited in their ability to react flexibly and autonomously to changing situations. 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, evolutionary control systems. These become very difficult to understand.

We approach the problem from the perspective of rational agents [6]. We consider a satellite to be an agent which consists of a discrete (rational decision making) part and a continuous (calculation) part. The discrete part uses the Belief-Desire-Intention (BDI) theory of agency [5] and governs high level decisions about when to generate new feedback controllers. The continuous, calculational part is used to derive controllers and to calculate information from continuous data which can be used in the decision making process; this part can be viewed as a hybrid system.

2 Architecture

Figure 1: Implemented Hybrid Agent Architecture

Our prototype system is shown in Fig. 1. We have implemented a simulated environment and real time satellite control system in MatLab using the Simulink tool kit. The continuous agent part is also implemented in MatLab. MatLab has no easy provision for threaded execution which forces us to use separate instances for the Real Time aspects (i.e. the feedback controller and simulated environment) and for the Continuous Agent part. The agent also contains a discrete agent part which is currently implemented in the agent programming language111The choice of language was dictated entirely by convenience. It is a subject for further work to examine more widely used BDI-languages and evaluate which is most appropriate for the system..  [2] is implemented on top of .

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 reasoning engine which makes decisions about how to behave. The discrete part is split in two because reasoning is comparatively slow 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 level.

3 BDI Programming 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 event that the satellite is in a new 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 new 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 any malfunctions or inefficiencies in the thrusters.

Such programs can be expressed 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 LABEL:code:geo_abs and LABEL:code:geo_reas. Fragment LABEL:code:geo_abs shows the code for the abstraction engine. Every time it “perceives” the satellite position (stateinfo) it calls upon MatLab to calculate whether or not this position is within bounds (comp_distance) and then asserts and removes shared beliefs appropriately.

The code is shown as a series of plans of the form trigger:{guard} <- deeds where the trigger is some event observed by the agent, the guard is a set of facts that must be true before the plan is activated and the deeds are a stack of deeds to be executed. +b is the addition of a belief, b, and -b is the removal of the belief, b. In a guard .B b means that b is believed.

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),
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 LABEL:code:geo_reas 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 move 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.

1+proximity_to_centre(out) : {True} <-
2     -proximity_to_centre(in),
3     +!get_to_centre;
4
5+proximity_to_centre(in) : {True} <-
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) (perform);
14
15+!try_execute(P) : {.B proximity_to_centre(out)} <-
16     apply_controls(P);

3.2 Decision and Control

The important aspect of both the above example and the architecture in general is that the (MatLab) control systems take care of the detailed calculation of continuous functions (paths, etc), while the rational agent takes care of high-level decisions about targets and plans. This separation of concerns simplifies both parts and avoids the problems associated with large, opaque, complex, adaptive and evolutionary control systems.

4 Future Work

We are currently working on our prototype system and case study which will allow us to make comparisons of this agent approach to autonomous decision-making in satellite systems to approaches based on finite state machines and standard control. We also are interested in investigating the use of temporal logic and model checking to generate forward planning capabilities for the agent along the lines of those investigated by Kloetzer and Belta [3]. We aim to explore the possibility of using model checking to verify aspects of the agent’s behaviour. Given that we already have a formal verification system for 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 have model-checking tools for the discrete/finite parts. Our interest now is how far such techniques can be extended to account for other aspects of the agent’s behaviour.

References

  • [1] R. H. Bordini, L. A. Dennis, B. Farwer, and M. Fisher. Automated verification of multi-agent programs. In Proceedings of the 23rd IEEE/ACM International Conference on Automated Software Engineering (ASE 2008), pages 69–78, L’Aquila, Italy, September 2008.
  • [2] L. A. Dennis and B. Farwer. Gwendolen: A BDI Language for Verifiable Agents. In B. Löwe, editor, Proc. AISB’08 Workshop on Logic and the Simulation of Interaction and Reasoning, Aberdeen, 2008. AISB.
  • [3] M. Kloetzer and C. Belta. A Fully Automated Framework for Control of Linear Systems From Temporal Logic Specifications. IEEE Transactions on Automatic Control, 53(1):287–297, 2008.
  • [4] N. Lincoln and S. Veres. Components of a Vision Assisted Constrained Autonomous Satellite Formation Flying Control System. International Journal of Adaptive Control and Signal Processing, 21(2-3):237–264, October 2006.
  • [5] A. S. Rao and M. Georgeff. BDI Agents: From Theory to Practice. In Proc. 1st International Conference on Multi-Agent Systems (ICMAS), pages 312–319, June 1995.
  • [6] M. Wooldridge and A. Rao, editors. Foundations of Rational Agency. Applied Logic Series. Kluwer Academic Publishers, Mar. 1999.