Goal-Based Operations: An Overview
---
paper_title: On-board planning and scheduling for the exomars mission

paper_content:

Deep space exploration with surface based robotic elements presents a number of significant challenges, not least of which is the lack of real-time, high bandwidth communication between a surface element and mission control. The lack of timely data combined with the unstructured and potentially hazardous nature of the terrain creates a difficult mission planning environment. Given the paucity of up-to-date data it is difficult to construct robust timelines at the task level. As a consequence such missions can be characterised by recurrent safe-modes, significant downtime and reduced science return. Lag in the communications cycle exacerbates this problem by increasing operational workload and delaying return to active science operations. It is worth noting that even in mid 2005 with a reduced and mature approach for the NASA MER rovers, operations costs are in the region of $2.5M/month. A conservative planning approach is often adopted to improve timeline robustness but inevitably science return is lower as a result. The use of greater on-board autonomy is therefore a critical consideration for such a mission. In particular it is essential to determine just what level of autonomy is appropriate, whether a suitably mature technology implementation exists and to validate these conclusions in a representative way. The current suite of Packet Utilisation Services (PUS) as defined in ECCS-E-70-41 [1] provides an appropriate starting point for the development of an operational autonomy concept for the forthcoming ExoMars mission. Although PUS services such as event monitoring, event action coupling and OBCP’s provide the backbone implementation for FDIR and operational autonomy concept, additional functionality is required to meet the requirements of deep space operations. In particular there is a need to accommodate timeline management from a global perspective in response to variability (during execution) and uncertainty (at mission planning time) with regard to on-board resources such as memory and power. For example the actual power or memory used during payload activity will often be different from that predicted by mission planners. In the pessimistic case this will halt the timeline as there will be insufficient resources to carry out the planned tasks which remain. Alternatively execution may result in a relative abundance of resources if estimates were overly conservative. These could of course be used to carry out additional science. Greater on-board autonomy, which extends the level currently supported by existing PUS services, has been proposed as a means of alleviating this inefficiency. Autonomy in this sense is defined as having software element which can modify or create a rover timeline. The motivation being that an on-board element, with access to actual on-board state is
---
paper_title: Mission Planning and Execution Within the Mission Data System

paper_content:

Not only has the number of launched spacecraft per year exploded recently, but spacecraft are also getting progressively more complex as instruments become more capable and flyby missions give way to remote orbiters, then to rovers and other in situ explorers. To address the software issues in this expanding mission set, JPL started the Mission Data System (MDS) project – an effort to make engineering flight software more straightforward and less prone to error through the explicit modeling of spacecraft state. This paper presents how MDS performs mission planning and execution in the context of managing explicit spacecraft state.
---
paper_title: Non-linear sequencing

paper_content:

Spacecraft are traditionally commanded using linear sequences of time-based commands. Linear sequences work fairly well, but they are difficult and expensive to generate, and are usually not capable of responding to contingencies. Any anomalous behavior while executing a linear sequence generally results in the spacecraft entering a safe mode. Critical sequences like orbit insertions which must be able to respond to faults without going into safe mode are particularly difficult to design and verify. The effort needed to generate command sequences can be reduced by extending the vocabulary of sequences to include more sophisticated control constructs. The simplest extensions are conditionals and loops. Adding these constructs would make a sequencing language look more or less like a traditional programming language or scripting language, and would come with all the difficulties associated with such a language. In particular, verifying the correctness of a sequence would be tantamount to verifying the correctness of a program, which is undecidable in general. We describe an extended vocabulary for non-linear sequencing based on the architectural notion of cognizant failure. A cognizant failure architecture is divided into components whose contract is to either achieve (or maintain) a certain condition, or report that they have failed to do so. Cognizant failure is an easier condition to verify than correctness, and it can provide high confidence in the safety of the spacecraft. Because cognizant failure inherently implies some kind of representation of the intent of an action, the system can respond to contingencies in more robust and general ways. We will describe an implemented non-linear sequencing system that is being flown on the NASA New Millennium Deep Space 1 Mission as part of the Remote Agent Experiment.
---

Title: Goal-Based Operations: An Overview

Section 1: Introduction
Description 1: Introduce the traditional time-based command sequencing for space missions and explain the need for a new operational paradigm due to increasing mission complexity, unpredictability, and the benefits of goal-based operations.

Section 2: A Brief History of Goal-Based Operations
Description 2: Provide a historical overview of goal-based operations, including significant achievements and examples of its application in space missions and other domains.

Section 3: Goal-Based Operations across the Project Lifecycle
Description 3: Discuss how the concept of goal-based operations influences various phases of the space mission project lifecycle, from initial engineering activities to final mission operations.

Section 4: Software Architecture
Description 4: Describe the software architecture needed for goal-based operations, including the representation of goals, state variables, layered control architecture, goal elaboration, and the interaction between flight and ground systems.

Section 5: Operations Process, Tools, and Workflow
Description 5: Explain how goal-based operations affect the operations process, tools, and workflow, including the shift from a product-flow paradigm to a work-flow paradigm and how goals enable seamless decomposition of activities.

Section 6: Operator Interaction with Goal-Based Systems
Description 6: Detail the mechanisms and displays required for operators to interact with goal-based systems, including various views to provide context for goals and their execution.

Section 7: Challenges for Goal-Based Operations
Description 7: Address the technical and cultural challenges for the deployment and adoption of goal-based operations, such as system observability, reliability, software maturity, operations processes, and performance concerns.

Section 8: Conclusion and Outlook
Description 8: Summarize the benefits of goal-based operations, emphasize the need for standards, and discuss the outlook for future missions and interoperability.