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 their assets. Due to security restrictions for ISS uplinks, CGBA Payload (Commercial Generic Bioprocessing telemetry and position updates of the rover and images Apparatus), a temperature-controlled incubator for had to be manually uplinked instead of streaming, experiments on cells, microbes, and plants on the ISS which took around 3-5 minutes from issuing commands [5]. As “Quickstart” project, the DTN network with its to the crew receiving the image. overlay features was expanded from the control centre OPSCOM-1 took place October 2012 with astronaut in Boulder to ESOC, and an experiment laptop was Sunita Williams operating the rover from the ISS. The deployed on the ISS, connected to the CGBA, and experiment was a success with many lessons learned on equipped with DTN nodes. the software used, communications and operational preparation of such experiments. More is detailed in [7]. 2.2.1 OPSCOM-1 Several key aspects to mention are: To validate the concept of commanding an asset from - In order for ground to be most supportive to crew space for the first time and receiving a stream of inquiries, a camera was pointed at the MOPS screen telemetry, “OPSCOM-1” was termed as the validation to allow observation of the crew screen. This of “Quickstart”. prompted the creation of the MOE (METERON Operations Environment) for successive The Multi-purpose Operations Software (MOPS) was experiments as described in the next section (see created as a simple graphical software user interface section 2.2.2). written in Python to allow basic commanding and - File-based uplink limitations strongly decelerated receipt of telemetry of a rover. MOPS is capable to the flow of the activity and were mitigated for the transmit commands and highlight command execution next experiment. status to the operator (Fig. 4). In addition, it offers a - DTN proved to be an effective means to simple map of x/y coordinates and the marking of communicate between ground and ISS. Due to its waypoints and paths travelled. Communication is overlay-network characteristics, it was extensible for future experiments.
This marked the availability of the first METERON - Support for planning of experiments and generation framework on the ISS - a combination of lightweight of command schedules, ISS software, interfacing via space and terrestrial - Archiving and retrieval of all operations data. networks to ground assets for conducting robotic experiments, and the corresponding knowledge gathered All development was executed in an agile manner using in the teams how to prepare and execute them. sprints to deliver fast software prototypes to users who in experiments continuously evaluated the system. 2.2.2 The METERON Operations Environment The ingestion of data into MOE is made possible by the and OPSCOM-2 use of the Robotic Services (MRS), which abstract from the proprietary software interfaces of specific systems. One main consideration (that still exists today) was to These services were designed as a set of web services create an environment where ground operators are following the CCSDS Mission Operations (MO) aware of the activities performed by crew and the status Services [9]. of the execution on the rover platform and all the other systems. It was also planned that rovers and rover The combination of ingesting the ISS data from e.g. control systems would change over time but that the MOPS via robotic services to the ground operators ground operators should feel familiar using their tools using MOE, in addition to allowing command and independent of the surface rovers used. This resulted in control from ground via MOE directly over the the creation of the METERON Operations interconnected DTN networks provided the Environment (MOE – since renamed to Multi-Purpose infrastructure as envisaged for the reference architecture Operations Environment) and its corresponding services in Fig. 1. architecture [8].
OPSCOM-2 Stepping up from the rollout of the first infrastructure, OPSCOM-2 focused on establishing full two-way DTN communication (automatic up and downlink of DTN traffic from/to the station). A node network closer to a realistic future network with multiple ground sites and paths was setup and utilized for a more sophisticated rover control of the EUROBOT rover from ESA/ESOC and the ISS. The rover was located at ESA/ESTEC. The EUROBOT rover with its size of a small car lead to a significant increase in the level of robotic control Figure 5. MOE user interface complexity as compared to the small OPSCOM‐1 LEGO robot. The network performance and usability The implementation of MOE was heavily based on the was evaluated in a series of test sessions executed by reuse of the existing ESA Ground Segment Test and ground operators, and was finally demonstrated by Validation Infrastructure (GSTVi) and selected robotic tele-control of the EUROBOT rover, where elements of the ESA EGOS infrastructure. The Eclipse crew member Alexander Gerst on board the ISS RCP-based application allowed for faster tailoring for participated in OPSCOM-2 in August 2014. In the each experiment and provided functionality used in scenario, he drove the rover under supervision of Earth Spacecraft monitoring and control that could be re-used Mission Control to various targets within a given period for the robotic monitoring and control case, such as to evaluate several aspects of control systems, command verification, telemetry displays and databases procedures, visual awareness and operations support. and is now used for: - Monitoring of the experiment execution covering the state of the robot(s) and of MOE elements as well as activities performed by all actors involved; - Reception, storage, and display of TM and data produced by the robot including pictures and video; - Monitoring and Control of one or more robotic assets via connections to their respective robotic control software (e.g. on ISS); - Monitoring and Control of the MOE framework components, the network status, as well as the health and status of operational hardware; Figure 6. Alexander Gerst performing OPSCOM-2
For the OPSCOM-2 experiment, various changes had to robotic assets to the ISS operators and to Mission be made to the architecture. The BioServe infrastructure Operators on ground. was replaced by a new NASA DTN Gateway node. The ESA DTN network was extended to include BUSOC Supvis-E and SDM deployed a rover control system to (the Belgian User Support and Operations Centre) as an the ISS, targeted at exercising goal-oriented objectives. additional DTN node before uplink to the ISS, and The EUROBOT rover was again used in ESTEC, ESA/ESTEC was added for access of EUROBOT. MOE automatically approaching a lunar lander mock up, was used in all ground centres involved, allowing inspecting panels and deploying communication following the different steps and commands executed by equipment. A rover driver in ESOC commanded a small crew in real time. MOPS was used on the ISS, providing “scouting rover” in parallel to ISS crew Andreas information on crew activities to MOE. Following the Mogensen commanding and supervising the execution crew activity, the infrastructure was used over several of the rover goals. The “scouting rover” provided weeks without crew involvement to perform remote additional camera views to crew with the experiment controlled test campaigns of the DTN network, exercising a collaborative scenario of multiple rovers retransmission capabilities, path finding over multiple with shared control working in concert. routes deepening the knowledge of future exploration protocols and providing feedback to the standardization Supvis-M [11] was designed as a lunar surface group. exploration scenario with ESOC as Mission Control, Timothy Peake as orbiter crew and Airbus-UK as the 3 TRANSITIONING TO THE SURFACE robotics Co-Investigator. The project simulated a OPERATIONS FRAMEWORK scenario in which humans are orbiting the Moon, with a rover already deployed on the lunar surface. During the The OPSCOM experiments had the main goal to Supvis-M supervisory control session, the astronaut establish, advance and demonstrate new capabilities operated a rover located in the Airbus Defence and within the METERON framework – to increase Space Marsyard in Stevenage, UK, using an updated complexity of the robotic asset, to widen the version of MOPS for rover control and an additional communication network and to expand to more centres ISS laptop for displaying the video stream from the with different roles. After the OPSCOMs, the teams rover camera. transitioned to cover and address wider surface operations aspects. The focus of the upcoming activities shifted from technical aspects towards the experiment architectures and wider operational use cases, such as end-to-end multi-asset distributed operations. An important factor was the definition of In- and Out- of-Scenario teams. The in-scenario work and preparation were the activities that a real operational team would perform in a surface mission, with access only to information and systems that they would have in a real mission. The in-scenario teams were only allowed to focus on the exploration scenario exercised within the experiment and were shielded from ISS and analogue site-specific issues. Experiment preparation of the ISS, the analogue sites and ancillary infrastructure were out- of-scenario work. This separation was kept and intensified with every experiment.
3.1 Supervisory Experiments Figure 7. The Bridget Rover and its path inside the In 2015 and 2016, Supvis-E, SDM (Short Duration simulated lunar cave Mission) and Supvis-M were conducted. A large improvement was introduced from the technical upgrade In the scenario, the exploration rover was positioned of the ISS connectivity with their Ku Forward. NASA using discrete rover telecommands from ESOC to arrive added the Ku Forward [10] capability allowing wider at the edge of a cave entrance (Fig. 7). The orbiting access from ground to payloads. In addition, up and crew took over the control of the rover to perform an downlink bandwidth was increased to 1Mbit per inspection of the zone in penumbrae, identify potential payload, allowing comprehensive exchange of telemetry science targets, perform simulated scientific activity, and telecommands and live streaming of video from and drive out of the penumbrae. With the low latency, crew was able to steer the rover via the rovers’
Ackerman driving mechanism (continuous driving recommendations of the Global Space Exploration mode) with the arrow keys of the control system. The Roadmap to “advance deep space exploration ground operators took back control of the rover and capabilities and create innovative opportunities for completed the operations, exercising the handover exploration of the Moon through human-robotic between crew and ground. MOE, with its system of partnership” [13]. systems architecture, allowed all parties to have a complete overview of all the systems involved in the experiment scenario and facilitated remote recovery options when needed.
As previous infrastructure elements such as the DTN network were used routinely at this point, situational awareness of all parties and end-to-end operations by geographically dispersed engineering teams working together became a strong focus. Supvis-M could demonstrate the effectiveness of system-of-systems operations in these time-critical, real-time operations. With all teams observing common maps and information, planning and communication throughout Figure 8. Baseline HERACLES Mission Operations the campaign was facilitated and the extensive use of Scenario [15] the system resulted in numerous requirements to the MOE software. Requirements such as collaborative and HERACLES will land an ascender element (LAE), a shareable marking of waypoints, path planning, shared descent element (LDE) and a rover on the lunar surface. command stacks and handover of point of control were Surface operations of the rover will be carried out by recommendations leading to subsequent iterations of the shared Earth and Orbiter control; samples will be software. collected and returned to the LAE. The samples will The same comprehensive set of requirements and then be returned to Earth via the Lunar Gateway to methods were gathered on the side of the rover Earth [14]. This will strongly contribute to enable future operations teams, contributing to lessons learned human presence on the Moon by certifying key catalogues for the future missions. technologies and operations for a human lunar mission while maximising scientific return and opportunities to 4 PREPARING SURFACE MISSIONS demonstrate and test technologies. HERACLES is a fitting example highlighting the Since completion of the OPSCOM and SUPVIS validity of the METERON initiative in preparation for experiments, we have transitioned to the next and final an exploration mission architecture. Since early 2017, set of METERON activities, now in support of missions our surface operations activities have become closer in the definition phase. We continue to build on linked to HERACLES by including specific previous results and recommendations and keep HERACLES considerations, objectives and exploring new concepts to be added to the framework. requirements into the upcoming surface operations Previously, the mission scenarios came from reference activities. scenarios and high-level descriptions of exploration cases. Yet, with a worldwide rising interest and focus 4.2 HOPE-1 towards lunar exploration for the coming decade on the side of Space Agencies and industry, scenarios that are The Human/robotic Operations Preparation Experiment more concrete are being devised and are looking for (HOPE) series of experiments is derived from the needs validation. of HERACLES. HOPE-1, the first in this series of experiments, was a collaboration with the Canadian 4.1 HERACLES Space Agency (CSA). HOPE-1 was conducted as a ground only experiment without ISS involvement, since One such project in the definition phase is the the objectives focused on ground operations and their HERACLES (Human-Enhanced Robotic Architecture interactions, the primary surface operations mode for and Capability for Lunar Exploration and Science) HERACLES. project, a mission designed to implement and All systems were re-used from previous ESA and CSA demonstrate key elements and capabilities for activities, including simulators to model the delays lunar sustainable human exploration of the Moon and human- communications would entail. robotic exploration of Mars while maximising opportunities for unprecedented scientific knowledge Experiment operations took place in October 2017, gain [12]. HERACLES is following the using a setup comprised of a CSA rover located in a
rock quarry, chosen in order to resemble a lunar The activities listed previously made extensive re-use of environment, as well as operations teams located at both knowledge and infrastructure gained in the previous CSA and ESOC representing the operations teams on experiments and from ESOC’s experience in flight Earth operating in shifts. One key element in the operations. This not only streamlined and greatly experiment design was a clear separation between facilitated the setup of increasingly complex scenarios, performing the rover operations (“in-scenario but also spilled over into multiple related areas. operations”), and the experiment execution itself (“out- All centres involved are actively working on preparing of-scenario operations”. For the teams involved in rover future missions and are now in a position to substantiate control, their tasks were realistic for a lunar mission like proposals and inputs with tested recommendations. HERACLES. In contrast, the out-of-scenario team These flow directly to standardization groups for handled any logistical and technical issues and ensured protocols and services, operations concepts, the in-scenario team’s immersion in the lunar scenario. requirements and recommendations to industry. In All in-scenario operators were exposed to addition, upcoming questions of maturing missions are communication delays appropriate for a lunar mission directly addressable within the environment. when exchanging data with the “lunar” rover. No such HERACLES is a focal point that is further supported constraints applied to the out-of-scenario teams in order during the activities currently being prepared and to have a full real-time experiment overview and a outlined hereafter. ESOC is a part of the inter-agency complete dataset for post-experiment analysis. collaboration on the cis-lunar station. The surface operations team at ESOC is defining and preparing the Different team compositions and team interactions were field of operations and monitoring and control of tried out, with special focus on distributed operations surface assets including rovers. Industry is also taking across multiple centres. The general principle of having an increased interest in the exploitation of the Moon. two rover team members, providing “a second pair of eyes” for preparing and executing any activity was 5.1 Commercial access to the Moon upheld throughout the experiment. The opportunity to ESA has two objectives: To accomplish ESA space discuss plans with another person or team was missions and to support the competitiveness of the appreciated by the in-scenario operators. Collaborative European space industry. All surface operations traverse route planning between the teams located in domains of engineering, operations and robotics are Canada and Germany was an important aspect of the working closely with industry to intensify and spread experiment. The distributed nature of the in-scenario expertise required for the future. We support manifold operations team highlighted the need for suitable tools projects for industry to cooperate and participate in facilitating to share and discuss the relevant data. In surface operations activities and to mature technical addition, a distributed command history shared among readiness levels (TRL) of different components for its all systems across sites was crucial in a distributed own usage. In addition, we are supporting private, operations environment. commercial initiatives for missions to the Moon.
For us, engaging into the private sector to kick-start It was also noted that 3D views of the scenario could their own activities or jointly exploit the Moon is substantially increase situational awareness, and are playing a growing role. considered useful for planning trajectories. Hence, mostly through student projects and studies, augmented 5.2 METERON Analog-1 and HOPE-2 and virtual reality components were added to the framework. A clear benefit provided the usage of the METERON was the main driver to prepare the Surface services architecture of the ESA infrastructure to Operations Framework. At the end of this year, in interconnect CSA and ESA systems. November 2019, METERON will conclude with a large ISS analogue experiment called ANALOG-1. 5 TRANSITIONING TO APPROVED MISSIONS The ANALOG-1 experiments will consist of the simulation of a HERACLES end-to-end surface At the time of writing this paper, there is a focus on exploration scenario with a rover located at a preparing for future lunar exploration missions. Lunar representative analogue site in Lanzarote. The exploration is one of the stepping-stones beyond the ANALOG-1 activity will be based on a lunar mission International Space Station to advance human presence scenario including control of lunar surface assets from in the solar system. Either with the various commercial ground and the Lunar Gateway. Three surface phases actors in this space or the space agencies collaborating for this robotic demonstrator precursor activity are on the cis-lunar station and their exploitation, the being demonstrated: Ground control (including rover knowledge gained so far and in the future will directly commissioning and initial surface operations), Crew support and further substantiate planning, preparation control (including sample selection and retrieval), and and execution of future missions.
surface mobility (including long-range navigation and 7 REFERENCES surface operations via ground control). 1. Bundle Protocol Specification, RFC5050: ANALOG-1 will involve the ESOC surface operations https://tools.ietf.org/html/rfc5050 team with experience from the experiments described in this paper in cooperation with the telerobotics teams 2. CCSDS 734.2-B-1, CCSDS Bundle Protocol providing matured haptics devices for the ISS. Specification. Blue Book. Issue 1. 2015. Geological activities will be performed with the support of a geology science team. The European Astronaut 3. Disruption Tolerant Networking, Centre will coordinate the crew activities who will https://www.nasa.gov/directorates/heo/scan/en perform the on-orbit activities of using force feedback gineering/technology/txt_dtn.html devices to fetch samples from the surface. 4. ION DTN Software, https://sourceforge.net/projects/ion-dtn/ In parallel to ANALOG-1, the HOPE-2 experiment will be carried out in June 2019. HOPE-2 will be performed 5. Bioserve, http://bioserve.colorado.edu utilizing ESOC and Canadian Space Agency (CSA) 6. Image credits: ESA/Foster + Partners, ESA – J. infrastructure, and will address requirements of the Mai HERACLES mission not covered by ANALOG-1. The HOPE-2 activity will also be a ground-only experiment. 7. Nergaard, K., et al. Demonstration of As for HOPE-1, distributed teams will control a rover communications systems for future human by carrying out various sampling tasks. exploration during the OPSCOM-1 test using Both ANALOG-1 and HOPE-2 combine all the the ISS. Paper number. IAC-13, A5, 3- experience gained in all domains of operations, B3.6,2,x20182. 2013. communications, robotics and the corresponding 8. Cardone, M., et al. (2016). The METERON systems. We employ and interface the infrastructure that Operations Environment and Robotic Services, steadily evolved with each activity and draw on a wide a plug-and-play system infrastructure for catalogue of lessons learned for all teams involved. Robotic experiments. SpaceOps 2016 Conference, http://dx.doi.org/10.2514/6.2016- The comprehensive analogues for HERACLES and the 2474 supporting of industry mark our last transition point from exploratory analogues to real applications and 9. CCSDS 520.0-G-3, CCSDS Mission missions. Operations Services Concept Green Book, 2010. 6 CONCLUSION 10. Cecil, A.J., Pitts, R.L., Welch, S.J., Bryan, J.D. This paper has shown how the Agency has – in small (2014). Enhanced International Space Station steps of increasing complexity – created knowledge and Ku-Band Telemetry Service. SpaceOps 2014 infrastructure to support surface operations missions. Conference, http://dx.doi.org/10.2514/6.2014- The work grew steadily from a simple rover to running 1654 full analogue campaigns in representative environments 11. Taubert, D., et al. METERON SUPVIS‐M ‐ an with a variety of complex rovers. Creating all software Operations Experiment to Prepare for Future systems agile has delivered working tools to users who Human/Robotic Missions on the Moon and were faced with changing challenges and requirements. Beyond, Astra 2016 The plug-and-play architecture designed from the start relying on certain standards for communication and 12. Landgraf, M. et al. HERACLES Concept – An interfaces was the long-term enabler to cooperate with International Lunar Exploration Architecture different system owners and agencies. The iterative Study, https://www.hou.usra.edu/ approach has greatly reduced risks and increased meetings/leag2015/pdf/2039.pdf confidence. 13. ISECG (2018), Global Exploration Roadmap Having such an environment has proved invaluable, not only to support the core purpose, but also to generate 14. Hiesinger, H., et al; Returning to the Moon spin-off engagement in standardization, next generation with HERACLES: An ESA-JAXA-CSA Joint communications protocols and future operations Study. Geophysical Research 2019. concepts. https://meetingorganizer.copernicus.org/EGU2 ESOC has demonstrated its readiness to support future 019/EGU2019-9274.pdf lunar surface operations missions. We now support 15. Landgraf, M., Carey,W., Hipkin V, Carpenter surface operations definition phase activities for future J., Hiesinger H.,. HERACLES – Exploring the lunar missions and we are looking forward to support Moon in an International Context. European the decade of lunar exploration and beyond. Planetary Science Congress 2018