JULES VERNE ATV DEMONSTRATION OBJECTIVES REPORT TOOL (JADOR)

Size: px

Start display at page:

Download "JULES VERNE ATV DEMONSTRATION OBJECTIVES REPORT TOOL (JADOR)"

Jared Scott
5 years ago
Views:

1 JULES VERNE ATV DEMONSTRATION OBJECTIVES REPORT TOOL (JADOR) Fran Martínez Fadrique (1), Carlos M. Casas Cuadrado (1), José Miguel Lozano González (1), (1) GMV AD, Isaac Newton 11, Tres Cantos, Spain ABSTRACT On April 3 rd 2008, the first Automated Transfer Vehicle (ATV) Jules Verne successfully docked to the International Space Station (ISS). Being the Jules Verne the first ATV mission, it was necessary to demonstrate the correct in-flight performance of the autonomous onboard Guidance, Navigation and Control (GNC) functions, critical to guarantee the success of the mission and the ISS safety. To assess this performance, CNES, ESA, NASA and RSA agreed on a number of demonstration objectives to be incorporated into an operational report that should quantify the actual performance of the on-board system. These evaluation objectives were implemented in the Jules Verne ATV Demonstration Objectives Report Tool (JADOR) that was integrated by CNES as part of the Flight Dynamics operational system. This paper intends to provide an insight in the specific aspects of JADOR, developed by GMV under ESA/CNES contract. 1. DEMONSTRATION OBJECTIVES The demonstration objectives agreed by all relevant parties had to be verified during different mission phases, when data from ATV and ISS are compared with ATV Control Centre (ATV-CC) Flight Dynamics computed data to assess the ATV on-board performance. Typical assessments focused on attitude control, absolute and relative GPS, GNC on-board confidence, navigation coherence and trajectory behaviour. Demonstration objectives were very heterogeneous, requiring a specific set of data and processing for each of them. The main differences were: - They can be related to a single magnitude or a set of magnitudes. - They can be based on raw telemetry data, results obtained in the ATV-CC, or the comparison between both. - They can apply to a single point in time or to an interval, even to several time intervals in the course of a mission phase. - They can have one or several thresholds, not necessarily constant. In case of demonstration objectives analysing an interval, the threshold could apply to the whole interval or only some parts if it. The high number of demonstration objectives and its different nature made it unfeasible to obtain manually all the required data in an appropriate format within the tight operational schedule. A more automated approach was recommended since a process with high level of manual intervention is very error prone. The purpose of JADOR is to automatically retrieve the demonstration objective related information, to compile it in a comprehensive document, to ease the verification of the computations with respect to pre-established thresholds and pass fail criteria and to allow the homogenous exchange to all involved parties, while reducing the human interaction in the process to a minimum. 2. DESIGN CONSTRAINTS The original goal of JADOR was to ease the retrieval and comparison of all the information related to the demonstration objectives, while the generation of the document and verification of the thresholds was to be done by a human operator. Detailed analysis of the actual operational needs and the necessity to process a huge amount of information caused that the objective of JADOR to be changed into a complete end-to-end process with minimal human interaction. At the beginning of the development of JADOR, the demonstration objectives were still significantly evolving. Some studies were on-going in order to refine the variables to monitor and set their most adequate thresholds. With the development already in process, some demonstration objectives were added or changed. In addition, the format and contents of the final report wasn t completely defined at the time of the JADOR specification. During the development of JADOR, several elements such as assessment of demonstration objectives, plots, results and statistics were added to the report. The time available for the development, testing, deployment and validation in the operational environment was limited to six months; this was a hard constraint due to already fixed launch date. The main challenge in this strict development process was to

develop JADOR from scratch and to bring it to operational conditions within the prescribed schedule. Performance was also a design issue for the JADOR software.

2 develop JADOR from scratch and to bring it to operational conditions within the prescribed schedule. Performance was also a design issue for the JADOR software. After the data is available in the Flight Dynamics databases (FDB), the amount of time before the demonstration objectives had to be delivered to the analysis experts was really reduced due to operational requirements. This constraint imposed performance requirements in the software to execute all analysis tasks, generate all textual and graphical information and compile and format the final report. Although the processing implemented in JADOR is not extremely complex, the number of demonstration objectives to process and the big amount of graphical information to be generated causes that the processing time has to be taken into consideration within the operational timeline. To optimise the development process and minimise the risk, JADOR was conceived as a simple collection of command line tools. A Man-Machine Interface (MMI) should be incorporated should sufficient time be available. For this purpose the design of the configuration files and interfaces reused the formats and data structures from an already existing MMI application that could be overlaid on the command line version of JADOR. 3. ARCHITECTURE The following paragraphs define the main system architecture details that made JADOR a success MODULAR ARCHITECTURE Every element in the JADOR production chain had well specified and encapsulated tasks. Also, a clear definition of interfaces between those elements was established. This guaranteed that all the elements could be developed in parallel, reducing the development time to a minimum. ATV-FDS FDB R1 FDBLIB JADOR PRODUCTION P2 P1 Timeline Generation (J-TML) D9 Flow Retrieval (J-RGE) Configurati on D8 D1 Timeline & Range Flow/File Dumps D11 Thresholds Config. P3 D10 Flow Merge (J-MER) Config. D2 D3 D4 Threshold Data (MADONA) Plot Data (MADONA) Demo Numeric Description (XML) P5 D6 JADOR Generator (J-DOC) JADOR (XHTML) P4 D5 Plot Generator (J-DOC) Plots (PNG) Figure 1. High level architecture of JADOR D7 JADOR Template The main tasks of JADOR, represented in Figure 1, are: - Flow retrieval (J-RGE): this element is in charge of retrieving from the ATV-FDS database all the required data flows and data files and convert them into MADONA (CNES specifications) formatted ASCII files. These files are stored in the JADOR local area. - Timeline and range generation (J-TML): this component generates the actual ATV mission timeline (events relevant to the JADOR generation) and a representation of range as a function of time using the flows retrieved from the ATF-FDS database. - Flow merge (J-MER): this is the core of the system: the data flows are combined according to the different descriptions corresponding to each demonstration objective to produce derived data adequate for plotting and ancillary data required for the demonstration objective evaluation and document production (e.g. comparison statistics, thresholds, etc). - Document generation (J-DOC): actual plots and tables are produced using the data generated by J- MER and merged into the final JADOR document REDUCTION OF EXTERNAL INTERFACES The only data obtained from an external source in the JADOR generation was the retrieved data from the FDB. In order to reduce the dependency of JADOR on the FDB, all the accesses to it were concentrated in a single task, the Flow Retrieval. In addition, all the flows needed for all the subsequent tasks in the generation of the report are retrieved at the very beginning of the process and stored locally, to reduce the impact of an external contingency (e.g. FDB not reachable). All the subsequent tasks use the local data to do the computations TWO LAYER TASKS Each of the tasks in which JADOR was divided had a similar internal structure, which made it simpler to develop and to adapt possible changes: - A core program in FORTRAN 90, performing a simple unitary task. - A wrapper script in TCL that executes the core program as many times as needed. The core of each task was developed in FORTRAN 90 consistently with the supporting flight dynamics libraries from ATV-FDS. Those libraries provide access to the FDB and to a set of routines to easily manage and process the retrieved data. Those programs were designed to perform a very specific simple task each time they are executed, implementing the intelligence of the specific demonstration objective tailored with the input configuration. This way, the recovery time in case the program ends unexpectedly is reduced to a

3 minimum. The wrapper is a TCL script that reads the high level configuration file and executes the core as many times as requested in a safe way. Since the core program only performs a simple task each time it s executed, the wrapper has the control on the load of the JADOR system (e.g. slow down data retrieval to avoid FDB overload) SEQUENCED PROCEDURE The selection of the tasks was done in such a way that it can easily allow the definition of a sequenced procedure. Each step of the procedure was done by a different task. This procedure was simply defined as: - Retrieve data from ATV-FDS database. - Generate timeline for required period. - Merge data flows and calculate statistics. - Generate report. Tasks were also designed to be checkpoints. An unexpected event in one of the tasks doesn t force the user to execute the whole procedure again. The process could be continued from the last successfully executed task. The final goal of this simplified procedure was its automation. The most demanding document contains more that 100 charts and their corresponding statistics, and the only way to respond in time and with sufficient confidence that all data is consistent is to process automatically end-to-end HIGH ADAPTABILITY One of the most demanding constraints on the design of JADOR was the possibility to add, edit or remove features without a major re-design of the system. Those features had a diverse nature, such as modifications in the demonstration objective definitions, addition of new events, use of new data flows and addition of new statistics or new plotting features. The use of software technologies that allowed easy integration of new elements, tailoring of the already existing ones and growth of the tool capabilities was required. In order to achieve this goal, while keeping the modular architecture and its well-defined interfaces, JADOR had an object orientated high level design, where all the elements in the system were assigned an entity (e.g. data files, plots, reports). Those entities were created at a particular point in the system and travelled all the way to the end. If a new feature was requested in any of the tools, the information contained in a particular entity could be extended to account for it. At this point, the entity acts as a configuration file for the tool, which reacts differently depending on the information contained in the entity. Tools only use the information they need from each entity, so the additional information in an entity for a particular tool doesn t impose changes in any of the other tools. As a result, an object oriented language with growing capabilities was needed. The chosen mechanism was the use of XML files. The entities created in such a format can incorporate new information while maintaining backwards compatibility. In addition, their syntax can be easily validated anytime by means of XSD schemas. On the other hand, pure numerical data coming from the FDB or as a result of the data flow merge was stored in MADONA files. Its column-wise format allowed a nice handling by the plotting tools DECOUPLING OF DATA GENERATION AND DATA PRESENTATION All data generated by the computational generation tools are either XML or MADONA files. Both of them are very easy to manage and they allow nice generation and evolution of the datasets, meeting the high adaptability criteria. Moreover, the presentation of those data files was under the same adaptability criteria. Some changes in the document layout were to be expected during the final stages of the development process, when a change in the tools could make a big impact. In order to avoid this, JADOR has a complete decoupling of data generation and data presentation: - In a first step, all the needed data is obtained, processed, computed and stored. This data doesn t contain any formatting information. - In a second step, those data files are processed together with files containing the presentation details, to generate the necessary plots and the final report. Using the data in the XML and MADONA files, the plots are automatically generated. The structure is similar to the other tasks: a TCL wrapper processes the files and executes GNUPLOT to obtain the final image file. Those files are locally stored in PNG format for further use in the report. The final report generation is performed in a single step using also XML technologies (XSL and CSS transformation to XHTML). Thus, a change in the format would only imply a change in the associated style sheet. The XHTML format allows the presentation of the reports in a web browser with full browsing capabilities, which is a must due to the length of the document. Additionally, the final reports in XHTML could be

imported into a document processor to edit, post-process and formalise the final document. 4.

If the available time allowed for it, a MMI should be added later. The initial design intentionally allowed for the easy integration of the MMI with minimum design guidelines in the data architecture.

focussuite is a generic MMI framework that provides the basic capabilities for creation, editing, and save of the configuration files (see Figure 2).

Those templates could be modified to account for the last minute details before actually running the whole document generation process. Figure 3.

4 imported into a document processor to edit, post-process and formalise the final document. 4. MAN-MACHINE INTERFACE ESA s initial requested approach was to minimise the tool availability risk, meaning that JADOR should be developed for command line usage. If the available time allowed for it, a MMI should be added later. The initial design intentionally allowed for the easy integration of the MMI with minimum design guidelines in the data architecture. This proved to be a good approach and the integration of GMV s focussuite was done with minimum effort at the end of the project with sufficient time for qualification before launch. focussuite is a generic MMI framework that provides the basic capabilities for creation, editing, and save of the configuration files (see Figure 2). focussuite allows the definition of different workspaces, each of one set-up to contain the basic configuration for each of the phases in which a JADOR report was necessary. Those templates could be modified to account for the last minute details before actually running the whole document generation process. Figure 3. EBRO under focussuite GRAFOS (see Figure 4) is a tool that allows the graphical representation of a set of data. This tool allows the representation of several plots and subplots. It was configured such that, for each particular demonstration objective, the plots for each phase were shown in a different tab. Figure 4. GRAFOS under focussuite Figure 2. focussuite configuration panel edition In the MMI there were links to all the tasks for each of the demonstration objectives and to its input configuration files. Additionally, several plug-ins designed to be run under focussuite could be used in JADOR. EBRO (see Figure 3) is a tool created to show a graphical representation of a list of events. It was used to show a quick graphical overview of the most important events in the timeline. The JADOR man-machine interface was also used to provide a graphical layer to the visualisation of telemetry coming directly from the ATV-CC. In many cases during the analysis of the demonstration criteria it was necessary to go back to the reference raw data to identify the cause of observed behaviours. In this sense, having all graphical functionality integrated in a single tool proved being very useful. Figure 5 contains a sample of raw ATV-CC telemetry plotted using GRAFOS Figure 5. Raw telemetry display with GRAFOS.

5. REPORT The final report shows the assessment of all the demonstration objectives for a particular phase. The following paragraphs define the different chapters on it.

COVER This page contains the main title, the reference of the document, the reference of the ICD containing all the demonstration objectives and some space left for signatures.

DEMONSTRATION OBJECTIVES JADOR document contains a report for each particular demonstration objective to be assessed.

Figure 6. Cover in JADOR report 5.2. TIMELINE The timeline paragraph contains all the significant events that influence in the assessment of the demonstration objectives.

5 5. REPORT The final report shows the assessment of all the demonstration objectives for a particular phase. The following paragraphs define the different chapters on it. from the summary to a particular demonstration objective analysis. A sample summary report can be found in Figure COVER This page contains the main title, the reference of the document, the reference of the ICD containing all the demonstration objectives and some space left for signatures. A sample cover page can be seen in Figure 6. Figure 8. Summary in JADOR report 5.4. DEMONSTRATION OBJECTIVES JADOR document contains a report for each particular demonstration objective to be assessed. A general part contains, its description, thresholds and status for each phase (see Figure 9). Then, for each phase to be assessed, all the results, plots and statistics are shown (see Figure 10). Figure 6. Cover in JADOR report 5.2. TIMELINE The timeline paragraph contains all the significant events that influence in the assessment of the demonstration objectives. It allows the JADOR user or analyst to identify the ATV mission events and those generated specifically for the assessment of the demonstration objectives. A sample timeline can be seen in Figure 7. Figure 9. General analysis of demonstration objectives in JADOR report Figure 7. Timeline in JADOR report 5.3. SUMMARY The summary gives an overview of the demonstration objectives assessed through the document and their status with respect to their threshold. It allows at first sight to discover any anomaly in the results. Thanks to the browsing capabilities, it s possible to go directly

successful completion of the activity, even with margin for extensive validation and implementation of additional useful operational features.

6 successful completion of the activity, even with margin for extensive validation and implementation of additional useful operational features. The use of modern software development and data representation technologies was one of the most relevant aspects in the success of the activity. Using XML and extensive object orientation at application level permitted the evolution of the software to its final operational stage with minimum regression during the process and permitting the smooth integration of new requirements and modifications. The use of off-the-shelf building blocks also proved that the concept was adequate and minimise the risk of the development allowing to focus on the JADOR specific issues, while relying that the other components (plotting with GNUPLOT, data representation with XML, etc.) would just work out of the box. Figure 10. Detailed analysis of demonstration objectives in JADOR report 6. USE DURING OPERATIONS JADOR was operationally used during several phases along the mission, verifying the good behaviour of the ATV during Phasing, GPS navigation, Demo Day 1, Demo Day 2 and Rendez-vous. In all of them, it proved to be a very reliable tool, with a fast response time. All the data included in the report was used to discuss the behaviour of the ATV with the involved parties and prove the success of the mission. Thanks to the generation of the report in XHTML format, it could be uploaded to the ATV-CC web server as soon as it was generated. The report at this point wasn t public, so only the experts from FDS could access it via username and password. This proved to be a very useful feature, since the experts could review the report from their terminals just a few minutes after the data was available in the FDB. The addition of a focussuite MMI brought many advantages in the operational aspect. Apart from the ease of use and the reduction of typing errors, it gave JADOR a professional look and provided the operator with some tools to graphically analyse the intermediary data and the final results. JADOR was operated during the ATV Jules Verne mission successfully during all operational phases, fulfilling all expected requirements in the ATV performance assessment Demonstration Days. 8. FURTHER IMPROVEMENTS Although the implementation of JADOR is very unique, given the specific nature of the demonstration objectives and their structure, there are several components that are subject for further reuse in the reporting and activities where data structure is the key in the analysis process. Although the validation principle defined for the Jules Verne mission will not happen again for further ATV missions, JADOR can always be subject of reuse for online or off-line analysis in flight dynamics contexts where a robust and simple-to-use tool is required, also in non-atv or not even space related scenarios since the underlying principle is really generic. 9. REFERENCES ATV Jules Verne Demonstration Objectives and Success Criteria Plan, OPS-PL ESA, 2.2D, June 26th, 2007 JADOR Subsystem Architecture Description, GMVSA 21089/07, 1.0D, October 18th, CONCLUSIONS JADOR was a really challenging project where, in very short time and with several evolving requirements and constraints, it was necessary to bring to operational status a software system with deep operational implications. The selected approach, where incremental development on the evolving design was possible, was key for the

GNCDE: AN INTEGRATED GNC DEVELOPMENT ENVIRONMENT FOR ATTITUDE AND ORBIT CONTROL SYSTEMS

GNCDE: AN INTEGRATED GNC DEVELOPMENT ENVIRONMENT FOR ATTITUDE AND ORBIT CONTROL SYSTEMS Fernando Gandía (1), Luigi Strippoli (1), Valentín Barrena (1) (1) GMV, Isaac Newton 11, P.T.M. Tres Cantos, E-28760