Demonstration of Robust Execution on a NASA Testbed

Vandi Verma1, Vijay Baskaran2, Hans Utz3, Robert Harris2, Charles Fry2 Jet Propulsion Laboratory, California Institute of Technology 1, Perot Systems2, RIACS3: NASA vandi@jpl..gov, @email.arc.nasa.gov

Abstract A rim of Shackleton crater is one of the candidate sites for a lunar outpost, balancing requirements for This paper presents the onboard execution software power, stable thermal environment and potential for used for operating two rovers in a simulated lunar resources. Detailed surveys of the site will be needed robotic site survey at Haughton Crater in July-August to lay out infrastructure and search for resources. The 2007. The execution software consists of a language polar environment is harsh and site surveys require called Plan Execution Interchange Language systematic coverage of an area with extensive (PLEXIL) that represents the control, monitoring, and sampling. fault protection desired, and an engine called Universal Executive that executes plans written in PLEXIL and interfaces to controlled systems. PLEXIL and UE controlled two K10 rovers from NASA Ames in site survey experiments totaling 200 hours of operation, covering 45 km of moon-like terrain.

1. Introduction

The NASA vision for space exploration plans to return astronauts to the moon by 2020. “Astronauts Figure 2: Shackleton crater. Diameter=19km. will search for resources and learn how to work safely It is not unusual for site surveys to require in a harsh environment -- stepping stones to future thousands of measurements and hundreds of hours to exploration.” complete. To help reduce the number and duration of human Extravehicular Activity (EVA) sorties NASA would develop robots to perform systematic mapping or site survey. To be approved for operation alongside astronauts, these robots must meet requirements for a high level of safety and reliability. They must also significantly reduce crew workload to justify the high cost of launch and landing. It must therefore be possible to operate these rovers remotely from Earth or with minimal supervision from crew at an outpost. In addition to making the robotic hardware reliable there would be a

need for software that could provide guarantees about Figure 1: Artist's rendering representing the lunar behavior. A collaborative team from multiple NASA exploration concept. (Image credit John Frassanito centers and universities has developed verifiable and Associates) execution software to meet this challenge. This paper

1 This work was performed while the primary author was with Perot Systems at NASA Ames Research Center.

presents this technology and some results from robotic Hill”, K10 red was used to survey other areas around site survey field trials in an analog lunar environment. Haughton base camp. Simulated ground control was located at NASA Johnson Space center and at NASA 2. Lunar Robotic Site Survey Ames Research center’s Future Flight Central facility. Field operations were from a HMMWV at Drill Hill. The approach for lunar robotic site survey adopted Hab-ops were conducted from Haughton base camp. by the Intelligent group (IRG) at NASA Details on the rovers, instruments, computing, and the Ames Research Center uses multiple independent field test may be found in [5]. robots to autonomously survey different parts of a region with remote human supervision. The human supervision of these robots may be performed either from a nearby habitat/vehicle or from Earth and is nominally at a high level. In this approach, humans outline a region to survey. The software system autonomously generates a plan to survey the region, executes the plan, and sends data. Humans analyze this data and get continuous updates on rover state. They may also remotely intervene at any time. Figure 4: Drill Hill In July-August 2007 IRG conducted a field experiment to test operational concepts for systematic Figure 5 shows a high-level schematic of the site site surveys. Two K10 rovers from NASA Ames were survey software system. The remote operator specifies used to perform robotic survey of a simulated lunar a region. The coverage planner automatically generates site in Haughton crater. The rovers carried ground- a mission plan for the region. It runs off-board on the penetrating radar to map subsurface structure and a 3D operator console. The mission plan consists of scanning laser to map terrain topography. waypoints with details on data to be collected at each Haughton Crater is located on Devon Island in the location. The executive (UE/PLEXIL) executes the Canadian Arctic. It is a popular site for robotic field plan based on an operational policy, which is also tests since it provides a relevant analog for the polar called an execution plan. It issues commands to the regions of the Moon and . In addition, there is 24 navigator and to the survey instrument controllers and hours of light during the summer months and monitors progress. The executive, navigator and Haughton Mars Project [7] provides logistic support instrument controllers all run on-board as part of the for a field team. SORA [6] architecture. The operator may pause, un- pause, and abort the plan at any time. The execution plan handles these interrupts and notifies the user when errors occur.

Operator

Pause/un-pause Abort signals

Request and get next waypoint/task Coverage UE/PLEXIL Planner Report completion status of task

Navigator LIDAR/GPR

Figure 3: K10 black and K10 red rovers from NASA Figure 5. Schematic of high-level software Ames in Haughton crater. interactions. The two K10 rovers were ‘K10 Black’ and ‘K10 Red’ (see Figure 3). K10 Black was assigned a site survey task on a 700x700m region called “Drill

3. Plan Execution Interchange What is unique about PLEXIL is that the Language (PLEXIL) semantics of executing a PLEXIL plan are clearly defined and formally verified [2]. Unambiguous PLEXIL is a small, well-defined language that semantics make it easier to do verification and provides a great deal of power in terms of high-level validation and to implement a lightweight executive control, while being easy to formally validate and that conforms to the semantics of execution. A simple verify. PLEXIL plans are programs that specify actions PLEXIL plan is shown below: to be performed by an execution system. These actions Example1: { may represent nominal spacecraft operations or fault Invariant:(LookupOnChange(rover_state) != "estop"); monitoring and protection handlers. The specification Repeat-while: (LookupNow(distance) != 10); of spacecraft operation plans like command sequences PostCondition: Acquire.outcome=SUCCESS has been limited to very simple control structures. This List: has largely been due to the difficulty of specifying DriveNode:{ Command: drive();} control structures like loops and event (and sensor) AquireNode:{ driven concurrent monitors in such plans, without StartCondition: Drive.outcome == SUCCESS making the expected semantics unclear and the SkipCondton: Drive.outcome==FAILED validation problem unsolvable. Existing languages Command: aquire(); } with expressive representations do so at the cost of } losing formal guarantees about execution. A PLEXIL plan is a set of processes, called nodes, 2 In this simple example the rover drives to a organized in a tree structure . The leaves are action target and acquires a sample and then repeats the nodes that initiate tasks requiring external interaction, process until it has covered a distance of 10m. The such as commanding systems, assigning values to local plan consists of a list node called Example1. The list variables, etc. Non-leaf nodes, called list nodes, node contains two nodes – Drive and Acquire – that provide scope for collections of nodes. Local variables issue commands drive() and acquire() respectively. declared in the list node may be shared by the nodes The start condition of AcquireNode ensures that the within the collection. In addition each node has node starts execution only after DriveNode has implicit variables representing the status of execution finished successfully and the skip condition ensures which may be one of a finite set of values – Inactive, that it is skipped if the drive failed. By default, Waiting, Executing, Finishing, IterationEnded, PLEXIL nodes represented in a list are concurrent. Failing, or Finished; and the outcome of node The invariant condition ensures that all executing execution – Skipped, Success, or Failure. Nodes only commands will be aborted if the rover state changes to have access to implicit variables in a parent, child, or “estop” at any time. The Repeat-while condition sibling. specifies that the sequence of drive and acquire PLEXIL is event driven, where each node has a commands iterates until the state variable distance is set of conditions that react to changes in the 10m3. The information about state variables such as environment, changes to the value of shared variables, rover_state and distance is requested from the rover and failures. Start, end, and skip conditions specify flight software via a lookup. The post condition sets when a node should start, end, and skip execution, the outcome of each iteration of node Example1. If while repeat conditions specify when the execution of AcquireNode fails during execution or is skipped the a node should be iterated. Pre- and post conditions are outcome will be FAILED or SKIPPED and the post checked before and after node execution and invariant condition will evaluate to false setting the outcome of conditions are checked during node execution. Example1 to FAILED. PLEXIL acquires input from the external world, The PLEXIL language is defined by an XML such as sensor measurements, using lookup operators. schema and a corresponding context-free grammar There are three types of lookups: LookupNow returns (CFG). Example1 was represented in CFG (with the latest value of the specified variable, abbreviated condition names). PLEXIL plans can be LookupOnChange returns a value when it has changed written with syntactic enhancements (if-then-else, by the specified amount, and LookupWithFrequency when, …), in core PLEXIL using the PLEXIL context returns a value at the specified frequency. free grammar, or in XML using the PLEXIL XML schema definition. In addition, a graphical editor for 2 There may be multiple root nodes. All parallel nodes with 3 no explicitly stated dependency execute concurrently. Units and types omitted here for clarity.

PLEXIL plans4 (PPEVEM) [9], and lisp and python sub-tree. PLEXIL also provides syntax for restricting versions with syntactic enhancements are also access if needed. Similarly the waypoint variables available. There is an automatic translation from all waypt_x, waypt_y, ..are available to nodes GetWaypt, these representations to the Extensible Markup DriveNode, and SampleNode. List nodes in PLEXIL Languge (XML)[8], and all are equivalent when provide scope for local variables. They do no operate executed in XML. Verification of PLEXIL is on declared local variables directly. Only leaf nodes performed at the CFG level. Because the core PLEXIL directly operate on local variables. With this language is small, state-of-the-art V&V tools can mechanism PLEXIL provides shared local variables, tractably analyze plans. Details on the syntax and but unlike many execution languages [10] these semantics of the PLEXIL language may be found in variables are not required to be global. This makes [1]. A formal analysis of the semantics of PLEXIL is PLEXIL plans modular and scalable. PLEXIL also available in [2]. semantics guarantee against deadlocks and race The Universal Executive (UE) is a lightweight conditions when writing to the same variable and efficient execution system that executes PLEXIL simultaneously. Details my be found in [1] and [2]. plans according to PLEXIL semantics. All the demonstration and tests described in this paper were Example2 :{ performed using the UE. The UE also has a Boolean is_aborted=false lightweight simulation script for testing purposes. EndCondition: LoopOverWaypoints=FINISHED List: LoopOverWaypoints :{ 4. PLEXIL plan for site survey Real waypt_x, waypt_y, …waypt_type…timeout… RepeatUntil: lookup-now (waypt_type) = “end_of_plan”; The goal for PLEXIL in the first year of the Invariant : is_aborted=false project was to execute plans generated by a coverage SuccessSequence: planner. Furthermore, the PLEXIL plan was to reliably GetWaypt: { handle situations where operations fail, systems behave Command: [waypt_x…waypt_type..] = off-nominally, and the operator intervenes at any time. get_next_waypoint(); } Coverage plans consisted of a list of waypoints DriveNode: { with labels indicating whether the waypoint was a via Command : drive(waypt_x,…) point used purely for navigation or inspection point } where the rover was expected to conduct scientific SampleNode:{ observation either using the LIDAR or GPR. PLEXIL Start: waypt_type= “sample” loops provide a natural representation for repetitive Skip: waypt_type=”navigation” operations. The PLEXIL plan for site survey was Command : acquire(); implemented with 187 lines of PLEXIL with syntactic } enhancements. } Example 2 below demonstrates concepts from the MonitorAbort : { Start: LookupOnChange(abort_plan)=true loop in site survey. The loop iterates over a sequence Assign: is_aborted=true; of waypoints acquired via the get_next_waypoint } command. For each waypoint it issues a drive } command. If the waypoint is marked for sample collection it issues a command to collect a sample else LoopOverWaypoints has a repeat condition and is it moves onto the next waypoint. If at any time during therefore a looping node. The node iterates as long as execution an abort plan event is issued the execution the repeat-until condition is true the node iterates. of the plan is aborted. Every iteration begins by resetting all variables in the Example2 is a list node consisting of the collection sub-tree rooted at the list node, including internal node of nodes -- LoopOverWaypoints and MonitorAbort. state variables. PLEXIL loops do no dynamic memory LoopOverWaypoins is also a list node consisting of the allocation and are stateless. Any state maintained collection of nodes – GetWaypt, DriveNode, and between iterations is maintained in a shared local SampleNode. Local Boolean variable is_aborted variable declared in a parent. declared in Example2 is visible to all the nodes in its Sibling nodes LoopOverWaypoints and MonitorAbort may execute concurrently since there is

4 no ordering or temporal constraint specified. As This tool also allows real time visualization of execution specified by its start condition, MonitorAbort starts for debugging and supervision.

execution when the external state variable PLEXIL plan was required to resume execution of the “abort_plan” is set to true by a human operator. remainder of the tasks. In case a un-pause signal was SuccessSequence is a syntactic enhancement. It issued by the operator without having been preceded specifies that nodes GetWaypt, DriveNode and by a matching pause signal, the signal was deemed SampleNode must execute in order with subsequent spurious and ignored. In the case of an abort signal, the nodes executing only if the previous nodes succeeds. requirement was to abort the current waypoint, discard SuccessSequence is equivalent to adding multiple and stop any further execution of the plan. These start and skip conditions. In this case a start condition monitors are very similar to the MonitorAbort node in DriveNode that starts when GetWaypt has outcome shown in Example 2. SUCCESS and a skip condition that skips it if it is not, In order to facilitate a post mortem analysis of the and a similar start condition in SampleNode that activities of the day, the execution system was required depends on DriveNode. In addition to this ordering, to log the status of completion of every task. For every SampleNode depends on the state of the variable single waypoint the PLEXIL plan was required to sample. The SampleNode start condition would inform a log sever with the result. The possible therefore be a conjunction of the ordering constraint outcomes included success, drive failure, sample and state of sample variable. collection failure, waypoint abortion in response to a The EndCondition specifies that Example2 is pause signal, waypoint abortion in response to abort eligible to complete execution when signal, In addition to recording that a command failed, LoopOverWaypoints is FINISHED. List nodes finish the reason for failure as reported by the commanded when all children finish execution. When the end module was also registered. condition of a list node is satisfied and if some of its The requirement to log the result of each waypoint child nodes are still waiting to start, the node cleanly is a simple behavior but it demonstrates the utility of skips these child nodes. This is necessary here since well-defined semantics. In the simple case where an Example2 contains a floating contingency/monitor – abort is issued all executing commands need to be MonitorAbort, which may or may not execute and the aborted and the plan must finish, but not until it logs plan should not wait indefinitely for it to complete if the cause for skipping any remaining waypoints. In the nominal plan is complete. Floating monitors are PLEXIL specifying an invariant condition at the right- invaluable for fault monitoring, handling, and level level in the node tree guarantees that the sub-tree opportunistic activities. PLEXIL provides a unified will be aborted. Every path does not need to be way of representing the context in which the monitors specifically tested. The language is already formally apply. The context is easily encapsulated in a list node. verified. When the list node ends, all corresponding monitors The site survey plan demonstrates that PLEXIL is are cleanly skipped. PLEXIL semantics guarantee this an expressive language and can represent simple and a human plan developer does not have to waste branches (e.g. if waypt_type=”sample” acquire sample, time writing and testing this feature for independent else…), floating branches (e.g. if the external variable contexts. abort_plan ever becomes true, abort the plan) , loops The PLEXIL site survey plan handled some off- (drive and sample each of a list of points by repeating nominal situations as well. It monitored six error a node list), time- and event- driven activities (e.g. if conditions. While some of the benign errors were duly local variable is_aborted ever becomes true, abort noted and then reported back to the operator while still execution if external variable abort_plan, when continuing to execute the plan, there were a handful of GetWapt finished successful execution start errors for which the current plan had to be aborted. DriveNode), concurrent activities (e.g. Loop over a set In addition to handling the synchronous error of waypoints to perform a site survey and reported by the module, the plan also handled two simultaneously monitor for a change in the value of asynchronous events. At any time during execution the variable abort_plan), sequences (e.g. execute operator was permitted to issue a signal to pause/un- GetWaypt then execute DriveNode and then execute pause or abort the task that the execution system was SampleNode), and temporal constraints(e.g. Start the currently performing. Such asynchronous events were drive 10 minutes after turning the heater on). What is handled using two monitors. In response to a pause unique is that the core syntax of the language is simple signal sent by the operator, the PLEXIL plan was and uniform which makes plan interpretation simple required to first send an abort command to any module and efficient. For example, many simple branches, currently executing a scheduled task and then refrain floating branches, time- and event- drive activities, from issuing any new commands. As soon as a un- current activities sequences, and temporal constrains pause signal was received from the operator, the may all be represented using the simple and unified

syntax of a start condition. By designing a language which included conditionals, branches, loops, and specifically for execution the grammar can be kept concurrent event-driven monitors. small. Desired behaviors can be represented at the The PLEXIL site survey plan was translated into right level of abstraction with the guarantee that all the java state-charts and the desired properties into nodes in the sub-tree will respond in conformance with assertions in java, JPF then automatically checked for PLEXIL semantics. assertion violations, data races, and deadlocks. Another novel feature of PLEXIL that makes The properties required from the site survey plan it desirable for rover applications is the mechanism were derived from requirements specified by the K10 PLEXIL uses to access information from the rover team. Examples of the properties that were underlying functional layer. The PLEXIL approach checked are listed below: supports different ways of accessing state information and does not require a telemetry database. The lookup • After the “plan abort” event is received all feature and the ability to perform internal storage and executing commands nodes finish immediately calculations (via declared local variables) make it and no new commands are issued possible to replicate most any behavior of database- • After the “plan abort” event is received no loops driven systems. Not requiring a database simplifies the in the plan repeat implementation of an executive for PLEXIL and can, • After the "pause plan” event is received no new in many cases, make an executive significantly faster. commands are issued until a “un-pause plan” For site survey the UE was integrated into the K10 signal is received Service Oriented Rover Architecture (SORA) [6]. In • If a "pause plan” event is followed by a “plan SORA each rover function (such as navigation, GPR, abort” all the properties listed for “plan abort” are LIDAR, execution, state-estimation, etc.) is true encapsulated in a service offered to the rest of the • If the drive command fails for any reason then the system through a public interface. The architecture sample acquisition command should never be relies on the use of middleware software for inter issued for that waypoint process communication. Every command and lookup • For every waypoint received by the executive it in the PLEXIL plan had a 1-to-1 correspondence with must send out a result regardless of success, a function defined in the corresponding rover process’ failure, abort, or any other event interface definition. • The plan will finish only if the last waypoint has been processed or a “plan abort” is received, or a 5. Verification & Validation command has a “critical” failure.

The PLEXIL plan for site survey was validated Formal verification of PLEXIL plans can using the Java Pathfinder (JPF) verification tool [3][4], guarantee that all possible executions of a command which was a recipient of the 2003 NASA "Turning sequence will not violate desired properties. The state- Goals into Reality Award". JPF performs a systematic of-practice uses simulation and manual test cases to exploration of all possible paths in a program to validate a single path through conditionals (scenario) determine possible outcomes. It operates on Java state at a time. This is time consuming, and there is no chart representations of programs and Java statements guarantee that all possible situations have been on desired program behavior. checked. Static checking of PLEXIL plans makes it The verification problem is intractable for most easier to write error free plans and provides plan programming languages commonly used in robotics developers with tools that can be used to statically such as C and C++. PLEXIL was designed to be detect errors in plans so that they may be corrected. verifiable using existing V&V tools: It is deterministic This reduces human planning time. given a sequence of events, compositional, and has run-to-completion semantics. 6. Field test Formal verification is performed on PLEXIL plans to establish guarantees that a command sequence will During the Haughton field demonstration the two not violate desired properties. The state-of-practice rovers performed approximately 200 hours of survey uses simulation and manual test cases to validate a operations that covered a combined distance of single at a time. This is time consuming approximately 45 km returning 25GB of survey data. JPF was used to perform a systematic exploration of all The PLEXIL plan and Universal Executive never possible paths through the PLEXIL site survey plan,

violated any requirements and operated the rover kms and K10Black, traversed a distance of 3 kms with reliably for all survey operations. a total of 20 commands issued to activate the GPR Some statistics collected from the field test are unit. Complete distance statistics by day may be found summarized in Table 1. Short surveys were omitted in [5]. from the table since they were often performed for Figure 6 shows the survey of Drill Hill survey debugging purposes. in Google Earth. The coverage plan is showing in The table gives an idea of the number of green and the path traversed by K10 while executing waypoints that were issued via the PLEXIL plan to the this plan is showing in black. It took 32 hours of rover navigational and the instrument controller modules. operations over four days (between Juy 23-28) to The last two columns show a tally of the number of complete the survey of Drill Hill. The distance covered times the “abort” or “pause/unpause” signals were was 20.5 km. issued during the course of plan execution. Operators occasionally annotated the log with reasons for their requests, but this was not universally done. Table 1: Statistics from Haughton field test

Number of waypoints Date Rover Abort Pause/unpause Nav Lidar GPR Jul 15 K10 red 6 2 0 1 Jul 15 K10 red 3 0 1 2 Jul 18 K10 red 11 0 0 0 Jul 18 K10 red 45 3 0 0 Jul 19 K10 black 20 0 0 2 (unsafe waypts) 1(aborted Jul 19 K10 black 25 14 to end the 0 run) Jul 19 K10 red 9 0 0 0 Jul 19 K10 red 21 2 0 1 Jul 20 K0 red 14 0 2 0 Jul 20 K10 red 35 4 1 0 Jul 24 K10 black 1 1 0 0 2 (first pause to 1(sopped switch laptop Jul 24 K10 black 20 20 run for he battery. Second day) unknown.) Jul 24 K10 red 30 2 0 3 Figure 6: Google Earth image showing the surveys Jul 25 K10 red 6 1 0 0 performed by K10 black to cover the Drill Hill region. Jul 27 K10 black 4 4 0 1 1 (mechanical Jul 27 K10 black 3 3 0 problem) In the field, rover operators ended up using Jul 27 K10 black 3 3 0 0 the pause/un-pause feature in innovative ways. Remote Jul 27 K10 black 9 9 0 1 Jul 27 K10 black 12 12 0 1 (joystick rover) human operators provided the input survey region by Jul 28 K10 black 1 1 0 0 drawing it in Google Earth, as shown by the bright Jul 28 K10 black 22 22 0 4 (bad stereo) green outline in Figure 6. In a few cases this region On one occasion K10 black lost was roughly specified and resulted in inspection points communication to HabOps after descending into a being generated in hazardous boundary regions by the ravine to survey a location specified in the coverage coverage planner. K10’s obstacle avoidance kept it plan. The remote operators could not see the rover or safe, but it started taking a circuitous path to achieve send commands to it, but it continued to drive the inspection point. The operators paused and un- nominally, so the emergency-stop operator following paused the rover repeatedly to skip waypoints since a the rover let it keep running. After 15 minutes the pause aborts the current destination and an un-pause rover emerged on the other side of the ravine after resumes with the next waypoint. successfully acquiring the requested data and started Pause, un-pause, and abort signals had very re-sending updates back to HabOps. It finished the specifically defined requirements as detailed in section entire survey 45 minutes later. 4. During the field test responses to these On another occasion, K10 red also lost asynchronous events were found to be dependable and connection to base camp when the remote operator predictable regardless of where in the plan the workstation crashed one day. The rover continued to executive was. During engineering tests in the conduct the lidar survey without interruptions. Two Marscape these events were also tested in various hours later the rover arrived back at base camp . combinations and the behavior was found to be On the 24th of August the rover equipped predictable given the sequence of events. with the K10Red traversed a total distance of about 1.5

We consider it a validation of the formal This research is supported by the NASA specification and clarity of PLEXIL that in each test Exploration Technology Development Program and the PLEXIL plan worked in the field exactly as Mars Technology Program. Collaborators include the expected. There were no surprises and side effects PLEXIL team, the Intelligent Robotics group at NASA from multiple simultaneously executing control Ames; and Corina Pascareanu and Mihaela Gheorghiu structures that may be triggered by uncertain events in from the Robust Software Engineering group at NASA the environment. Ames. Publication support was provided by the Jet Propulsion Laboratory, California Institute of 7. Future Work Technology, under a contract with National Aeronautics and Space Administration. Although the PLEXIL/UE performed well during the site survey experiment both in terms of usability 9. References and robustness, several new enhancements can be added to the execution plan. The highest priority is to [1] V. Baskaran, M. Dalal, T. Estlin, C. Fry, M. Iatauro, R. expand on the list of faults that can be monitored and Harris, A. Jonsson, C. Pasareanu, R. Simmons, V. handled. Verma, “Plan Execution Interchance Language (PLEXIL) Version 1.0”, NASA Technical Furthermore, work is currently being done to Memorandum, Nov 2007. include resource arbitration which will be very [2] G. Dowek, C. Munoz, C. Pasareanu, “Formal Semantics effective when multiple rovers need to share a single of a Synchronous Plan Execution Language”, Workshop resource or if several modules running on the same on Planning and Plan Execution for Real-World rover vie for common resources such as battery power, Systems: Principles and Practices for Planning in instruments, computing cycles and communication Execution at the International Conference on bandwidth. Automated Planning and Scheduling (ICAPS) 2007. Although the asynchronous events handled in the [3] W. Visser, K. Havelund, G. Brat, S. Park and F. Lerda. site survey plan were fairly simple (pause, un-pause, “Model Checking Programs”. Automated Software and abort) they demonstrated the utility of handling Engineering Journal.Volume 10, Number 2, April 2003. [4] http://javapathfinder.sourceforge.net/ asynchronous events in a well-defined and reliable [5] T. Fong, M. Allan, X. Bouyssounouse, M. Bualat, M. manner for providing greater supervisory control to Deans, L. Flückiger, L. Edwards, S. Lee, D. Lees, L. humans. In the future these events can be extended to a Keely, V. To, H. Utz, “Robotic Site Survey at Haughton wider range of human-robot interactions where an Crater”. International Symposium on Artificial astronaut can inject input and alter behavior during Intelligence, Robotics and Automation in Space execution. (iSAIRAS), 2008. For site survey all of the control logic was [6] L. Flückiger, V. To, H. Utz, “Service Oriented Robotic encoded in the PLEXIL plan by a human. The plan Architecture Supporting a Lunar Analog Test”, was essentially a static contingent plan with loops, International Symposium on Artificial Intelligence, Robotics and Automation in Space (iSAIRAS), 2008 parameters, local variables, and floating contingencies [7] P. Lee, “A unique Mars/Early Mars analog on Earth: (monitors). The same version of PLEXIL and the UE The Haughton impact structure, Devon Island, Canadian were used in other ongoing projects to encode Arctic”, 1st Conference on Early Mars: Geologic and dynamically-generated plans from an automated hydrologic evolution, physical and chemical planner. During execution the execution monitors state environments, and the implications for life. LPI Contrib. variables and sends updates to the automated planner. No. 916, 50., 1997 The planner uses these to make projections and detect [8] T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. potential future violations. The planner may then send Yergeau, “Extensible Markup Language (XML) 1.0 an updated plan. Hence in the future the site survey (Fourth Edition)” , 2006. [9] K. Tso, Plexil Plan Editor and Execution Monitor application could gradually be extended to use the full (PPEVM), http://www.ia-tech.com/plexil-editor. range of spacecraft autonomy available. [10] C. Grasso, “The Fully Programmable Spacecraft: Procedural Sequencing for JPL Deep Space Missions 8. Acknowledgments Using VML (Virtual Machine Language)”, IEEE Aerospace Applications Conference Proceedings, 2002