THE SURFACE OPERATIONS FRAMEWORK – TRANSITIONING FROM EARLY ANALOGUE EXPERIMENTS TO FUTURE LUNAR MISSIONS Sebastian Martin(1), Toril Bye Rinnan(2), Mehran Sarkarati(3), Kim Nergaard(4) (1) ESA/ESOC, Robert-Bosch-Straße 5, 64293 Darmstadt, Germany, Email: [email protected] (2) Solenix Deutschland GmbH, Spreestraße 3, 64295 Darmstadt, Germany, Email: [email protected] (3) ESA/ESOC, Robert-Bosch-Straße 5, 64293 Darmstadt, Germany, Email: [email protected] (4) ESA/ESOC, Robert-Bosch-Straße 5, 64293 Darmstadt, Germany, Email: [email protected] ABSTRACT to assess the financial and technical feasibility of new mission concepts, technologies and studies before This paper provides an overview of a family of possibly advancing them to the next phases of activities performed within the European Space implementation of a mission. Operations Centre (ESOC) to prepare for future robotic As the result of one such concurrent design study in missions on the lunar surface and beyond. 2009, the METERON concept was created. METERON – the Multi-purpose End-To-End Robotics Operations Over the course of nearly a decade, ESOC has been Network – was initiated to prepare for future human and gradually building up expertise for future surface robotic exploration scenarios. These future scenarios operations activities. foresee robotic assets controlled on the surface of Moon This paper describes or Mars, with humans operating those assets from an - the activities and corresponding systems prepared orbiting vehicle or by Earth ground control. The benefit from the ground up before concrete missions were of near real-time remote asset operations is to reduce defined, human risks and cost by not having to land humans and - how we are now covering a range of activities return them from the surface, while still being able to where we have requirements from missions in the control robotic assets with short transmission delays definition phases while continuing to build on from an orbiter. Earth Mission Control with longer previous results and recommendations and explore transmission delays of i.e. 5 seconds round-trip time to new concepts, the Moon and up to 24 minutes to the surface of Mars - how we are preparing to transition to and back respectively can perform non time-critical implementation for approved missions. operations, planning, long-distance driving or pre- All this is facilitated by the composition of systems, positioning of the rovers for orbiting crew tasks, communications protocols and operational preparations supporting the orbiting crew in achieving the mission to form the Surface Operations Framework, which is goals. The main building blocks of this architecture are detailed as part of this paper. represented in Fig. 1. 1. INTRODUCTION The European Space Operations Centre (ESOC) is the centre for the engineering teams to control the Agency’s spacecraft in orbit and to build the systems on ground supporting the space missions. Since 1967, more than 70 satellites belonging to ESA and its partners have been successfully flown from Darmstadt, Germany. ESOC is operating multiple missions in parallel while continuously preparing new missions in planning and under study. This includes all operations aspects of the different phases of a mission as well as all the ground Figure 1. Reference Exploration Mission Architecture segment engineering aspects such as the mission data [6] systems for these missions. Within ESA, many new mission concepts and designs 1.1 The METERON Concept are initially assessed in the Concurrent Design Facility Within the METERON framework, assumptions were (CDF) of the European Space Research and Technology defined, studied and evaluated, covering future Centre (ESTEC) in the Netherlands. The CDF is the exploration architectures and how to remotely work on a facility to bring together experts from all technical areas planetary surface and more specifically, how to operate surface robots from multiple entities (ground and orbit) - Communications to demonstrate communication considering delays, contingencies and other limitations concepts and technologies, of the space environment. - Robotics to evaluate robotics technologies and Some METERON objectives were: operations. - Assert the maturity of crew-controlled tele-robotics Data systems engineering teams were supporting all - Identify existing technology gaps (and how these three domains to evolve and provide suitable systems can be bridged) and tools. - Evaluate operational risks (proficiency, performance, failure modes) Some key questions were: The concurrent design study showed that it is feasible to - Which operations should be conducted form implement an infrastructure that could be used for Ground and which should be conducted from the ground simulations, in-orbit demonstrations and the near-by orbiter. combination of both. - How to best leverage and decide between The ISS was used as real orbiting vehicle, with ESOC supervisory control and teleoperations of robotic acting as Mission Control and analogue sites on Earth assets. representing the remote planetary surface (Fig. 2). - What are the reference ground segment and By introducing delays on the corresponding links communications architectures to perform such between Mission Control and the ISS, and Mission operations. Control and an analogue site, realistic environments could be created, closely mimicking the reference It is not sufficient to address such questions through scenarios. However, even if the analogue sites are paper study and design. The METERON framework laboratories or controlled environments, the addition of enabled in-flight validation of the concepts and the ISS with the complexity of crew time planning, technologies under consideration. safety regulations, networks and standards was expected to be able to deliver results at a level of fidelity not 2 SETTING UP THE METERON achievable in pure ground based experiments. Many FRAMEWORK experiments in the METERON framework have been METERON was designed to allow for a flexible executed on ground, with some key experiments being environment. In order to test different concepts, selected for flight qualification using the ISS. possibly with different robotic assets, evolving systems and changing network architectures and delays, the concept of METERON was to act as an agile, “plug and play” framework with gradually increasing complexity for each project. The first initiative and obstacle to overcome was to establish an initial test network between the ISS and ESOC, which did not exist prior to METERON. In a very fruitful and appreciated collaboration, ESA, NASA and BioServe Technologies in Boulder, Colorado created the METERON “Quickstart” series of experiments in 2010 to extend the experimental Delay/Disruption Tolerant Networking (DTN) between the sites and the ISS. 2.1 Delay/Disruption Tolerant Networking (DTN) Delay Tolerant Networking (DTN) is a computer network architecture, seeking to address the technical Figure 2. Simulated Exploration Mission Architecture issues of delayed and disrupted network connectivity. DTN provides networking technologies to achieve successful data delivery, to maximize the link utilization 1.2 Operations, Communications and Robotics and to address many specific problems of space Three domains were the main elements providing communication such as high bit error rates, intermittent requirements to METERON: link connectivity, long transmission delays and - Operations to test end-to-end operations concepts asymmetric or simplex links. DTN is created as a and technologies, modern protocol to offer certain benefits known from the “Internet-World” as a replacement of current internet protocols such as TCP/IP, which do not cope directly over a python-ION interface sending and with the delays in the space environment. processing DTN bundles. One core element of DTN is the Bundle Protocol (BP), The software supports reception of data out of order, [1], [2]. The Bundle Protocol (BP) is the end-to-end delayed or in bursts after loss of signals, to make use of protocol for the exchange of messages (bundles) in the benefits of DTN. Delay Tolerant Networking, connecting multiple To allow for higher fidelity and a more immersed subnets into a single network and transmitting them experience for the operators on ground and crew, a using a store-and-forward technique. simple LEGO rover was created and equipped with a Once an application communicating via BP submits Linux board hosting the ION DTN software and control data “to the network”, the protocol ensures automatic software to steer the motors. The rover could report its storage, buffering and resending of the data in the coordinates, telemetry on battery status and provide network chain. It automatically stores the information small and highly compressed still images from an and forwards it as soon as the next “hop” is available attached webcam. (Fig. 3). Figure 3. Disruption Tolerant Networking can reduce delay and increase throughput [3] Figure 4. Lightweight MOPS user interface 2.2 Quickstart and OPSCOMs DTN data from and to the ISS assets had to be encapsulated into ISS Express Rack communication DTN was therefore chosen as one of the main protocols data, strongly limiting the bandwidth (~80 byte/s uplink to implement and test. BioServe had created a first and 400kbit/s downlink, ~5.5 sec RTT) and therefore implementation of the ION DTN software [4] between prompting the design of the simple MOPS/LEGO their control centre in Boulder, Colorado and