================================================================================ 01234567890123456789012345678901234567890123456789012345678901234567890123456789 ================================================================================ |GIADA | ROSETTA | Reference: RO-GIA-OACUPA-IF-011 | |Consortium | GIADA | Issue : 3 Rev. : 2 | | | | Date : 28/10/2010 | ================================================================================ Rosetta-GIADA to Planetary Science Archive Interface Control Document ================================================================================ Prepared by: Vincenzo Della Corte Luigi Colangeli Alessandro Aronica ================================================================================ Revised and Approved by: Principal Investigator Luigi Colangeli ================================================================================ ================================================================================ Distribution List Recipient Organisation Kristin Wirth ESA/ESTEC Joe Zender ESA/ESTEC ================================================================================ ================================================================================ Change Log ================================================================================ |Date | Sections Changed | Reasons for Change | -------------------------------------------------------------------------------- |03 November 2003 | | First Draft issue | -------------------------------------------------------------------------------- |14 June 2004 | All | Second Draft Issue | -------------------------------------------------------------------------------- |20 Oct 2004 | All | Third Draft Issue | -------------------------------------------------------------------------------- |16 Dec 2005 | Revisions suggested by ESA | First Issue | -------------------------------------------------------------------------------- |03 Jul 2006 | Revisions suggested by Archive | | | | Review Board | Second Issue | -------------------------------------------------------------------------------- |30 Oct 2006 | Other Revisions suggested by ESA | Third Issue | -------------------------------------------------------------------------------- |15 Mar 2007 | Revisions suggested at PDS | | | | data set revision | Third Issue - Rev. 1 | -------------------------------------------------------------------------------- |28 Oct 2010 | Revisions suggested by Archive | | | | Reviewers | Third Issue - Rev. 2 | ================================================================================ ================================================================================ TBD ITEMS ================================================================================ |Section | Description | ================================================================================ |2.2 | Software tools to produce data at level 2 and level 3 | -------------------------------------------------------------------------------- |2.3.6 | Tools for data analysis to obtain statistical information | | | about the comet dust environment | -------------------------------------------------------------------------------- |2.3.8 | Data products resulting from co-operation with other | | | instrument teams | -------------------------------------------------------------------------------- |3.4.3.4.2 | Detailed content of Geometric Index File, geoindex.lbl | | | and geoindex.tab | -------------------------------------------------------------------------------- |3.4.3.4.3 | Detailed content of Other Index Files | -------------------------------------------------------------------------------- |5 | Available Software to read PDS files | ================================================================================ ================================================================================ TBC ITEMS ================================================================================ |3.4.3.5 | Presence of Browse Directory and Browse Files | ================================================================================ ================================================================================ Table of contents -------------------------------------------------------------------------------- 1 Introduction 1.1 Purpose and Scope 1.2 Archiving Authorities 1.3 Contents 1.4 Intended Readership 1.5 Scientific Objectives 1.6 Applicable Documents 1.7 Relationships to Other Interfaces 1.8 Acronyms and Abbreviations 1.9 Contact Names and Addresses 2 Overview of Instrument Design, Data Handling Process and Product Generation 2.1 Scientific Objectives 2.2 Data Handling Process 2.3 Overview of Data Products 2.3.1 Pre-Flight and Sub-System Tests 2.3.2 GIADA Integrated Tests and Engineering Calibration 2.3.3 Instrument Scientific Calibration 2.3.4 Other Files written during Calibration 2.3.5 In-Flight Data Products 2.3.6 Steps of GIADA data deliveries 2.3.7 Software 2.3.8 Documentation 2.3.9 Derived and other data products 2.3.10 Ancillary Data Usage 3 Archive Format and Content 3.1 Format and Conventions 3.1.1 Deliveries and Archive Volume Format 3.1.2 Data Set ID Formation 3.1.3 Data Directory Naming Convention 3.1.4 File naming Convention 3.2 Standards Used in Data Product Generation 3.2.1 PDS Standards 3.2.2 Time Standards 3.2.3 Reference Systems 3.2.4 Other Applicable Standards 3.3 Data Validation 3.3.1 Data Quality 3.4 Content 3.4.1 Volume Set 3.4.2 Data Set Naming 3.4.3 Directories 4 Detailed Interface Specifications 4.1 Structure and Organisation Overview 4.2 Data Sets, Definition and Content 4.3 Data Product Design 4.3.1 Content of LABEL files 4.3.2 Content of TABLE files 4.3.3 Data Product "Conversion Factors" 4.3.4 Data Product "GDS" 4.3.5 Data Product "GDS CAL" 4.3.6 Data Product "GDS IS" 4.3.7 Data Product "HK DATA" 4.3.8 Data Product "HK SCI" 4.3.9 Data Product "IS" 4.3.10 Data Product "IS CAL" 4.3.11 Data Product "MB HEAT" 4.3.12 Data Product "MBS" 4.3.13 Data Product "MBS CAL" 5 Appendix 1: Available Software to read PDS files 6 Appendix 2: Extract from GIADA User Manual with more detailed instrument description ================================================================================ 1 Introduction 1.1 Purpose and Scope The purpose of this EAICD (Experimenter to (Science) Archive Interface Control Document) is two fold. First it provides users of the GIADA instrument with detailed description of the product and about how it was generated, including data sources and destinations. Secondly, it is the official interface between GIADA team and data archiving authority. It must be noted that the GIADA model installed on the Rosetta S/C for flight is the FS (Flight Spare) model. The PFM (Proto Flight Model), identical to FS, is available on ground and will be used during mission development for tests in preparation and support to FS operation. 1.2 Archiving Authorities The Planetary Data System (PDS) standard is used as archiving standard by: - NASA for U.S. planetary missions, implemented by PDS - ESA for European planetary missions, implemented by the Research and Scientific Support Department (RSSD) of ESA ESA implements an online science archive, the Planetary Science Archive (PSA): - to support and ease data ingestion - to offer additional services to the scientific user community and science operations teams as, e.g.: * search queries that allow searches across instruments, missions and scientific disciplines * several data delivery options as > direct download of data products, linked files and data sets > ftp download of data products, linked files and data sets The PSA aims for online ingestion of logical archive volumes and will offer the creation of physical archive volumes on request 1.3 Contents This document describes the data flow of the GIADA instrument on Rosetta from the S/C until the insertion into the PSA for ESA. It includes information on how data were processed, formatted, labelled and uniquely identified. The document discusses general naming schemes for data volumes, data sets, data and label files. Standards used to generate the product are explained. Software that may be used to access the product is explained further on. The design of the data set structure and the data product is given. 1.4 Intended Readership The staff of the archiving authority (Planetary Science Archive, ESA, RSSD, design team) and any potential user of the GIADA data. 1.5 Scientific Objectives The primary scientific objectives of GIADA are: > Measurement of the dust flux and fluence of "direct" grains, coming from the nucleus, and "reflected" grains, coming from the sun direction, under the action of the solar radiation pressure. This task is fundamental to determine the original dust size distribution. In turn, this determination is mandatory to define the dust mass loss rate. > Measurement of the momentum and velocity distribution vs. grain size and time for "direct" grains. From this information it will be possible to derive grain mass and ejection velocity from the nucleus surface. > Study of dust evolution in the coma in terms of variations in the dust size distribution and correlation with dust fragmentation and/or with emission from active areas of the nucleus. > Study of the correlation of dust changes with nucleus evolution and emission anisotropy. > Determination of dust to gas ratio (combining GIADA results with data from other experiments; e.g., ROSINA). Moreover, the data provided by GIADA about dust fluxes and grain dynamic properties are very important to support: * the interpretation of images of coma and nucleus and ROSINA data; * the selection of the landing site of the surface science package. GIADA will provide to S/C and P/L information on dust flux relevant for the health and safety of experiments and S/C parts sensitive to dust. 1.6 Applicable Documents ================================================================================ |AD.1 | Planetary Data System Data | February 1, 1995, | JPL, D-7669, Part1 | | | Preparation Workbook | Version 3.1 | | -------------------------------------------------------------------------------- |AD.2 | Planetary Data System | August 1, 2003, | JPL, D-7669, Part 2 | | | Standards Reference | Version 3.6 | | -------------------------------------------------------------------------------- |AD.3 | Rosetta Archive Generation,| October 06,2005,I2| R3 RO-EST-PL-5011 | | | Validation and Transfer | | | | | Plan Archive Conventions | January 10,2006,I1| R- RO-EST-TN-3372 | -------------------------------------------------------------------------------- |AD.4 | Requirements on GIADA EGSE | November 7,2003,I2|RO-GIA-OACUPA-RS-017-I2| | | S/W for data conversion in | | | | | PDS format | | | -------------------------------------------------------------------------------- |AD.5 | GIADA EGSE instrument | March 5, 2003, I7 | GIA-GAL-UR-501 | | | workstation software user | | | | | requirements document | | | -------------------------------------------------------------------------------- |AD.6 | GIADA EGSE template and | March 8, 2003, I7 | GIA-GAL-TN-522 | | | configuration files for | | | | | PDS converter | | | -------------------------------------------------------------------------------- |AD.7 | GIADA RSOC converter | March 18, 2003 | RO-GIA-ISL-DP-016 | | | configuration files | | | -------------------------------------------------------------------------------- |AD.8 | ROSETTA - GIADA Experiment | May 15, 2001, I2 | RO-EST-RS-3009/EID B | | | Interface Document - Part B| | | -------------------------------------------------------------------------------- |AD.9 | GIADA FS Experiment User | January 9,2003, I2| RO-GIA-MA-007 | | | Manual | | | -------------------------------------------------------------------------------- |AD.10| GIADA FS End Item Data | February, 2003, I2| GIA-GAL-ED-505 | | | Package | | | -------------------------------------------------------------------------------- |AD.11| Data Distribution Interface| June 24, 2002 | RO-MEX-VEX-ESC-IF-5003| | | Document (with appendices) | Issue C1 | with Appendices | ================================================================================ 1.7 Relationships to Other Interfaces Changes in this EIADC would affect the GIADA data products, the GES software and the AD.4, AD.5, AD.6, AD.7. 1.8 Acronyms and Abbreviations ================================================================================ | ADC | Analog to Digital Converter | | ADID | Auxiliary Data Identification | | AIV | Assembly Integration and Verification | | AUX | Auxiliary | | C&DH | Command and Data Handling | | CODMAC | Committee on Data Management, Archiving, and Computing | | CPU | Central Processing Unit | | DDS | Data Distribution System | | EAICD | Experimenter to (Science) Archive Interface Control Document | | EIDP | End Item Data Package | | EGSE | Experiment Ground Support Equipment | | EMEJ2000 | EARTH MEAN EQUATOR J2000 | | ESA | European Space Agency | | ESOC | European Space Operation Center | | EUDB | GIADA GES Experiment Unit DataBase | | HKDB | GIADA GES Housekeeping Data Base | | FS | Flight Spare | | GES | GIADA EGSE Software | | GDS | Grain Detection System | | GIADA | Grain Impact Analyser and Dust Accumulator | | GSE | Ground Support Equipment | | HK | House-Keeping | | H/W | Hardware | | INAF-OAC | Istituto Nazionale di Astrofisica - Osservatorio Astronomico di | | | Capodimonte | | IS | Impact Sensor | | ISO | International Organization for Standardization | | MBS | Micro Balance Sensors | | ME | Main Electronics | | MLI | Multi Layer Insulator | | N/A | Not Applicable | | NASA | National Aeronautic and Space Administration | | ODL | Object Description Language | | PDS | Planetary Data System | | PDSC | Planetary Data System Converter | | PE | Proximity Electronics | | P/L | Payload | | PFM | Proto Flight Model | | PSA | Planetary Science Archive | | PSU | Power Supply Unit | | PZT | Piezoelectric Transducer | | RDDB | GIADA GES Raw Data Data Base | | RMOC | Rosetta Mission Operations Centre | | RSOC | Rosetta Science Operations Centre | | RSSD | Research and Scientific Support Department | | S/C | Space-craft | | S/W | Software | | SCET | Space-Craft Event Time | | TBC | To Be Confirmed | | TBD | To Be Determined | | TBTV | Thermal Balance and Thermal Vacuum | | TC | Tele-command | | TM | Telemetry | | UTC | Coordinated Universal Time | | VC0 | Virtual Channel 0 | | VC1 | Virtual Channel 1 | ================================================================================ 1.9 Contact Names and Addresses ================================================================================ | INAF-OAC | Luigi Colangeli | Tel.: 39 081 5575504 / 39 081 298384| | Via Moiariello, 16 | | Fax: 39 081 456710 | | 80131 Napoli (Italy)| | E-mails: colangeli@na.astro.it | -------------------------------------------------------------------------------- | Univers. Parthenope | Pasquale Palumbo | Tel.: 39 081 5575504 / 39 081 298384| | Via A. De Gasperi, 5| | Fax: 39 081 456710 | | 80133 Napoli (Italy)| | E-mails: palumbo@na.astro.it | -------------------------------------------------------------------------------- | INAF-OAC | GIADA Team | Tel.: 39 081 5575111 / 39 081 298384| | Via Moiariello, 16 | | Fax: 39 081 456710 | | 80131 Napoli (Italy)| | E-mails: giada@na.astro.it | ================================================================================ 2 Overview of Instrument Design, Data Handling Process and Product Generation See also Section 0 - Appendix 2: Extract from GIADA User Manual with more detailed instrument description. GIADA is a single box shaped instrument, 230 mm x 270 mm x 250 mm in cruising mode, when the cover is closed, and 230 mm x 322 mm x 250 mm in operational mode (box only, without feet). Refer to Figure 1 for a 3-D view of the experiment in its open configuration. Three modules compose the instrument: GIADA 1 measures momentum, scalar velocity and mass of single grains entering the instrument by the Grain Detection System (GDS) and the Impact Sensor (IS), placed in cascade; it also has the purpose of opening and closing the cover that protects itself and GIADA 3 during the cruise phase. The GIADA 2 module contains the main electronics (ME); it controls the acquisition of data from the sensors and the operation of the other subsystems. It also provides the power supply for the whole experiment. The GIADA 3 module measures the cumulative dust flux and fluence from different directions by 5 microbalances (MBS's). One points towards the nucleus, while the other four cover the widest possible solid angle. The MLI that thermally insulates the experiment from the environment and the sun covers all the external surfaces of the experiment. The upper part of the GIADA 1 box houses, together with GDS and IS, the locking mechanism and the protective cover with associated PEs. The illuminator and two receiver groups form the GDS. The bottom part of the box contains GIADA 2, while the top supports the five MBS's with associated PE. The whole operational sequence of GIADA is supervised and executed under microprocessor control (RH-80C86) by means of dedicated on-board S/W. Four different operative modes of the instrument exist. These modes can be selected autonomously by the S/C control system as well as by means of ground TCs. Different operational modes correspond to different active sensors / subsystems as shown in Table 2.1. In each Mode different sensors may also be switched ON/OFF separately by proper TC. While scientific data are acquired in NORMAL or FLUX Modes only, Housekeeping data are acquired in all Modes. ================================================================================ | Mode Name | Active subsystems (nominal) | Measured quantities | -------------------------------------------------------------------------------- | Safe Mode | ME | None | | Normal Mode | ME, GDS, 5 MBSs, IS | Dust flux and fluence | | | | Grain Scattering properties | | | | Momentum of single grains | | | | Velocity of grains | | | | Mass of single grains | -------------------------------------------------------------------------------- | Flux Mode | ME, 5 MBSs | Dust flux and fluence | -------------------------------------------------------------------------------- | Cover Mode | ME, Cover or Frangibolt | N/A | ================================================================================ Table 2.1. Active sub-systems and quantities measured in different GIADA Modes In the GDS, four laser diodes with their fore-optics are used to form a thin (3 mm) light curtain (area = 100 cm^2). For each grain passing through it, the scattered/reflected light is detected by two series of four detectors (photodiodes) placed at 90 deg with respect to the sources. In front of each photodiode a Winston cone is placed to achieve a uniform sensitivity in the detection area. The IS is a thin (0.5 mm) aluminium square diaphragm (sensitive area = 100 cm^2) equipped with five piezoelectric sensors, placed below the corners and its centre. When a grain impacts the sensing plate, flexural waves are generated on the plate and are detected by the piezoelectric crystals. The maximum displacement of these systems is directly proportional to the impulse imparted, and the displacement of the crystal produces a proportional voltage output. Through calibration, the received impulse can be related to the charge produced on the electrodes of the PZT crystals. The detected signal is proportional to the momentum of the incident grain through the factor (1+e), with e = coefficient of restitution. When a grain enters GIADA-1, the GDS gives a first estimate of the grain speed and starts a time counter that is stopped when the IS detects the grain impact and the momentum is measured. In this way for each entering grain, speed, time-of-flight, momentum and, therefore, mass are measured. Micro-balances consist in two (sensor and reference) quartz crystals oscillating at a frequency of about 15 MHz, with a shift of some kHz, one with respect to the other. The measured physical quantity is the beat frequency between the two crystals. The resonance frequency of the sensor quartz oscillator, exposed to the dust environment, changes due to the variation of its mass, as a result of material accretion, while the reference crystal is not exposed to the dust flux. Thus, the output signal is proportional to the mass deposited on the sensor and dust flux and fluence are measured vs. time. The use of a reference crystal ensures extremely small dependence on temperature and power supply fluctuations and, thus, high sensitivity. GIADA is a cold-redundant instrument. Therefore the GIADA Main Electronics is based on two complete sets of S/C interfaces (data and power) including microprocessor, memory and some digital-analogue circuits, which are in cold redundancy for low power operation. The switch over to the redundant unit is under control of the S/C by switching from the Main to the Redundant power lines. The main and redundant S/C interfaces, CPU and Power supplies are physically separated in two boards (CPU-PSU) located side by side at the bottom of the GIADA-2. The other analogue and digital functions that interface the sensors are redounded circuitry and are located in a single board (the so-called ANALOGUE BOARD). This board is mechanically mounted over the two CPU-PSU boards. The three boards are inter-connected by internal cabling (connectors and wires). The measurement sensors are intrinsically redundant. In fact, each GIADA subsystem (GDS, IS and MBS's) includes various sources/detectors in parallel. For example, the GDS is still active even if two of the four laser light sources or some of the eight-photodiode detectors fail (although the sensitive area will be reduced). Similarly, the IS is equipped with 5 PZT sensors, but the detection by only three of them is sufficient to obtain the particle momentum measurement. Finally, 5 micro-balances are used; in case of failure of one or more of them, the dust flux is still measured, although on a reduced number of different directions. ========================= || PHOTO OF GIADA || ========================= Figure 1. GIADA in open configuration (without MLI) during calibration in class 100 room 2.1 Scientific Objectives The GIADA (Grain Impact Analyser and Dust Accumulator) instrument is designed to measure physical quantities related to the dust emitted by the comet nucleus during its approach to the Sun. The instrument will measure the speed, momentum and mass of single grains coming from the nucleus direction, as well as the dust mass flux and fluence from 5 directions relative to the comet nucleus. The primary scientific objectives of GIADA are: * Measurement of dust flux for "direct" and "reflected" grains Two populations of cometary grains do exist: "direct" (coming directly from the nucleus) and "reflected" grains (coming from the sun direction, under the action of the solar radiation pressure). The two populations have extremely different dynamic evolution in the coma and ejection times from the nucleus. In the case of ROSETTA, "direct" and "reflected" grains can be collected simultaneously. The relative amount will depend on the probe position along its orbit. GIADA will be able to monitor grain fluxes coming from different directions and will allow for the first time to discriminate the two dust populations. This task is fundamental to determine the original dust size distribution. In turn, this determination is mandatory to define the dust mass loss rate. * Analysis of the dust velocity distribution The dust ejection velocity depends both on the grain size and on time. Moreover, grains with a given size have a wide dust velocity distribution. GIADA will allow us to measure scalar velocity and momentum for grains coming from the nucleus direction so to give mass and impact velocity of each analysed "direct" grain. From this information it will be possible to derive grain mass and ejection velocity from the nucleus surface. For the first time we will obtain: a. the size dependence of the dust ejection velocity; b. the relation between most probable dust velocity and dust mass; c. the velocity distribution for each dust mass. * Study of dust evolution in the coma Once ejected from the nucleus, grains may change their physical properties due to several processes (e.g. fragmentation). These modifications may alter the grain size distribution. The size distribution of grains collected by GIADA in the nucleus direction should not be affected by the dust velocity dispersion. Thus, changes in the dust distribution at different nucleus distances can be linked directly to actual variations in the dust size distribution and correlation can be found with dust fragmentation and/or with emission from active areas on the nucleus. * Correlation of dust changes with nucleus evolution and emission anisotropy The dust environment characteristics depend on the comet-sun distance and on the time evolution of the nucleus. The continuous monitoring by GIADA of dust flux and dynamic properties will offer the best opportunity to characterise the time evolution of the dust environment as a function of heliocentric distance. Nucleus imaging will allow us to link observed changes to the nucleus evolution and to its spin state. * Determination of dust to gas ratio One of the crucial parameters characterising the comet nucleus is the dust to gas ratio. The dust flux monitoring by GIADA is absolutely needed to estimate the dust to gas ratio. This will be possible in combination with results of other experiments (e.g. ROSINA). * Other objectives The data provided by GIADA about dust fluxes and grain dynamic properties are very important to correctly interpret images of coma and nucleus and ROSINA data. GIADA will help in the selection of the surface science package landing site. The characterisation of dust emitting areas, and possibly of the dust population of different active areas, is necessary to choose the site according to a proper balance between safety and scientific interest. GIADA will play an important role for the health and the safety of various experiments as well as of the S/C itself, as it will be able to provide information about dust flux. Optical surfaces of experiments, and in general all the devices pointing to the nucleus, will be polluted by the dust flux. GIADA data will allow us to measure the deposition rates and to take appropriate decisions about the operation and the mission planning. Data from GIADA will be the only resource to predict and, thus, to control the degradation of performances of critical devices, such as passive radiators and solar panels. The sensitivity of GIADA sensors is compatible with the expected cometary grain physical and dynamic characteristics and dust abundance. GIADA will ensure a statistically meaningful number of detections. The characteristics and performances of GIADA are summarised in Table 2.2. ================================================================================ | Module | Sub-systems | Measured quantities | Sensitivity | -------------------------------------------------------------------------------- | GIADA 1 | GDS + IS | Speed (single grains) | 1 m s^-1 | | | | Size (single grains) | 30 micrometers diam.| | | | Momentum (single grains) | 6.5 x 10^-10 Ns | | | | Mass (single grains) | | | | | Flux and Fluence | | | | | (nucleus direction) | | -------------------------------------------------------------------------------- | GIADA 3 | MBS's | Mass accumulation | 1 x 10^-10 g | | | | Flux and Fluence | | ================================================================================ Table 2.2. Characteristics and performances of GIADA 2.2 Data Handling Process The data elaboration is generally performed by the GIADA team in Napoli (INAF - Osservatorio Astronomico di Capodimonte and Universita' Pathenope) [Luigi Colangeli, Pasquale Palumbo, Elena Mazzotta Epifani, Francesca Esposito, Alessandro Aronica - E-mail: giada@na.astro.it], with the support of Instituto de Astrofisica de Andalucia (Granada - Spain) [Jose' Juan Lopez Moreno, Julio Rodriguez - E-mail: julio@iaa.es]. The team is equipped with computers (EGSE) constantly maintained in order to run the whole software tools produced to elaborate GIADA data. Data levels considered in this document are as defined in AD.3 (Appendix B) and reported in Table 2.3. ================================================================================ | PSA | CODMAC | NASA | Description | | level | level | level | | -------------------------------------------------------------------------------- | 0 | | | The raw telemetry data as received at the ground | | | | | receiving station or ground test GSE, organised by | | | | | contacts or ground tests. | -------------------------------------------------------------------------------- | 0a | | | The telemetry data as produced by the C&DH system | | | | | on the spacecraft and passed to the telemetry | | | | | subsystem. Level 0a contains transfer frame packets | | | | | organised by contacts or ground tests. | -------------------------------------------------------------------------------- | 1 | | | Level 0 data that have been cleaned and merged, time| | | | | ordered, and are in packet format. Cleaned, merged | | | | | and time ordered means that duplicate data have been| | | | | deleted, missing packets are padded out and the data| | | | | are organised by days. The actual format of these | | | | | data is the same as level 0a. This is the level | | | | | which should be passed to the instrument GSEs for | | | | | their processing. | -------------------------------------------------------------------------------- | 1a | 1 | | The level 1 data that have been separated by | | | | | instrument. This is the level which is distributed | | | | | by the DDS. | -------------------------------------------------------------------------------- | 1b | 2 | 0 | Level 1a data that have been sorted by instrument | | | | | data types and instrument modes. Data are in | | | | | scientifically useful form, e.g. as images or | | | | | individual spectra. These data are still | | | | | uncalibrated. | -------------------------------------------------------------------------------- | 2 | 3 | 1A | Level 1b with calibration | | | | | and corrections applied to yield data in scientific | | | | | units. | -------------------------------------------------------------------------------- | 3 | 5 | 2-5 | Higher level data products developed for specific | | | | | scientific investigations. | ================================================================================ Table 2.3. Data levels The elaboration of GIADA TM to produce data in PDS format at 1b (i.e., level 2 CODMAC) level (see Table 2.3) is performed by the tools installed on this machine. The core of the software tools available on the EGSE machine is the GIADA EGSE Software (GES). Details on GES and about its requirements and capabilities are reported in AD.5. We recall that (see Section 2 of AD.5) the GES is designed in order to handle GIADA use in different configurations: - to perform test activities on the GIADA instrument, both at unit and system levels; - to handle GIADA data, at different levels, during flight operations. In the latter case the GES provides support to: - perform flight H/W testing and calibration; - perform experiment command history logging; - perform critical system command logging; - permit selected parameter logging; - permit TM logging in ASCII format; - decode important events (e.g., GIADA 'Cover Report' parameters); - regenerate the HK-science data base and logging files from raw data; - convert - read - store data streams (i.e. file) from DDS format (ESOC data streams); - allow different GIADA EGSE conversion factor configurations depending on the tested model (flight or spare) and interface (main or redundant); - handle the Auxiliary Rosetta Spacecraft data (ESOC data stream); - convert the GIADA data set (HK and Science) in PDS format; - send data request to DDS (ESOC); - receive data retrieved from DDS (ESOC). To achieve the tasks mentioned above the GES software is formed by three main blocks: - the main GES software for the GIADA TM display and handling, that is based on the use of the "access" database; - the so-called "RSOC-converter", that is designed to convert the GIADA data retrieved from DDS in the format compatible with the GES software; - the so-called "PDS-converter", that is designed to organise GIADA raw data, GIADA engineering data and Rosetta auxiliary data in PDS format. Elaboration to produce data at level 2 and level 3 (see Table 2.3) is performed on EGSE and other computer machines by TBD software tools. These steps bring to the production of GIADA data, at different levels of elaboration, in PDS format for the delivery to PSA. At each stage of elaboration data are organised in data sets in PDS format to be delivered to PSA. 2.3 Overview of Data Products This section describes the data products that will be delivered by the GIADA team. The following sub-sections give a general description of these products. 2.3.1 Pre-Flight and Sub-System Tests Several tests have been performed in preparation to the realisation of GDS, IS and MBS sub-systems on components, bread-boards and mock-up. The experiments have been performed to evaluate the capabilities of the different used techniques to perform the measurements of interest for the GIADA scientific goals. The tests have been also useful to identify critical aspects that have driven the design and realisation of the flight hardware. For the GDS, preliminary tests have been performed on laser sources, collimating optics, light collecting devices (Winston cones) and sensors (photo-detectors). For the IS, preliminary tests have been performed on aluminium sensing plates equipped with piezoelectric sensor devices. For the MBS, laboratory versions of micro-balances have been used to study characteristics such as frequency stability, temperature dependence, sensitivity to grains of different sizes, dependence of sticking efficiency on grain size and speed, with and without sticking coatings. For each sub-system, electrical tests have been performed on the relevant Proximity Electronics circuitry. Tests have been performed on various bread-boards and preparatory models of the main constituents of the Main Electronics in preparation to the design of the flight ME. The aims, procedures and results of these preparatory experiments are mainly reported in technical reports and technical notes. The data produced during the tests are collected in a wide variety of formats (e.g., excel, word or ascii files) and have been elaborated by different software tools (e.g., excel functions, Fortran programs). Therefore, these pre-flight data are available in heterogeneous formats. It is not intended to convert these data in PDS format, but to collect the relevant documents and obtained data as support documentation in the GIADA internal archive. 2.3.2 GIADA Integrated Tests and Engineering Calibration The results of all formal tests performed on GIADA during AIV campaign (including vibration and TBTV tests) are matter of reports collected in the AD.10 (GIADA FS EIDP). The Proximity Electronics and Main Electronics acquisition chains have been calibrated in order to determine the transfer functions. The relevant final data are reported in technical notes and are used in the GES software to allow the automatic conversion of GIADA raw data (ADC counts) to physical quantities (e.g., voltage). The conversion is performed through polynomial equations applied to ADC counts. For each physical quantity the parameters of the polynomial equations are identified. For each physical quantity, two sets of parameters are available, labelled with "D" = Direct (conversion from ADC to Physical Quantity) and "I" = Inverse (conversion from Physical Quantity to ADC). These "engineering calibration data" or "conversion factors" (different sets for FS and PFM and for Main and Redundant lines of each model) are part of the GES database, are converted in PDS format by the PDS Converter tool and are stored in the "CALIBRATION\ENG_CAL" directory of the PDS data sets starting with the delivery of CODMAC 2 level data. The information collected during the AIV campaign is matter of elaboration for the better understanding of GIADA sub-system performance and behaviour. The results of such elaboration are reported in technical notes and reports. It is not intended to convert these data in PDS format, but to collect the relevant documents / data as support documentation in the GIADA internal archive. Up-grade of engineering calibration data is possible, based on analysis of in-flight calibration data and further on-ground tests. The changes shall be traced by coding of the PDS files, containing engineering calibration data, with version and date (as detailed in Section 3.1.4). This up-grade can produce the revision of GIADA in-flight data products, with consequent generation of updated data sets. 2.3.3 Instrument Scientific Calibration Both flight-worthy models (FS and PFM) have been scientifically calibrated in detail. > The calibration for GDS has been executed in two main steps: - relative calibration this calibration has been performed by using a thin chromel wire (D = 13 micron) moved in the GDS beam to map the laser curtain (by means of a robotic XYZ system). By this approach, the relative variation of (voltage) signal vs. position in the sensitive area has been determined - absolute calibration the absolute calibration has been performed by shooting real grains with different composition (nontronite, andesite and carbon), diameter (from 50 to 500 micron) and speed (from a few to 70 m s^-1) in some reference points and detecting the output voltage signal for each event > The calibration for IS has been executed in a similar way, by two main steps: - relative calibration this calibration has been performed by imparting a constant impulse to a grid of points over the whole IS sensitive plate. The impulse has been produced by using a piezoelectric device, powered by a fixed square signal, connected to a round shaped tip. This has been moved on the aluminium IS plate by means of the robotic XYZ system. By this approach, the relative variation of the (voltage) signal detected by the 5 PZT sensors vs. position has been determined. - absolute calibration the absolute calibration has been performed by shooting real grains with different composition (nontronite, andesite and carbon and others), diameter (from 50 to 500 micron), shape (round vs. irregular) and speed (from a few to 70 m s^-1) in some reference points and detecting the output (voltage) signal for each event from each of the five piezoelectric sensors. > The calibration of MBS has not been executed on the sensors mounted on the flight model, to avoid contamination. For MBS, the calibration has been performed on a commercial version of the MBS, with characteristics identical to the flight devices. Grains of different sizes (from sub-micron to 10 micron), shapes (round vs. irregular) and composition have been deposited to study the dependence of the sensitivity (i.e., deposited mass vs. output frequency) on grain properties. During calibration of GDS and IS, signals have been both sampled at the PE output and acquired by the ME. By this approach it has been possible to check the transfer function of the ME on the detected voltage signals. Data acquired by the ME during calibration are directly processed by the GES. Data acquired by the PE are, instead, available in other formats (e.g., excel or ascii lists). It is not intended to convert these data in PDS format, but to collect them in the GIADA internal archive. All calibration data have been elaborated by various tools and are matter of technical notes and reports. It is not intended to convert this material in PDS format, but to collect it in the GIADA internal archive. The measurements of physical quantities (converted from ADC's to engineering units) have to be transformed into scientific quantities. In particular, the following quantities have to be determined: - speed measured by the GDS crossing time in m s^-1, - speed measured by the GDS+IS time of flight in m s^-1, - impact position on IS in cm (with respect to a reference point on the IS), - momentum measured by the IS in N s, - grain mass deduced from GDS+IS data in kg, - deposition rate deduced from MBS frequency variation (for each of the 5 sensors) in kg s^-1. The "scientific calibration data" useful for the conversion from physical quantities to scientific quantities are derived from the analysis of relative and absolute calibration tests described above. These data shall be stored in the "CALIBRATION\SCI_CAL" directory of the PDS data sets only starting with the delivery of CODMAC 3 level data. Up-grade of scientific calibration data is possible, based on analysis of in-flight calibration data and further on-ground tests. The changes shall be traced by coding of the PDS files, containing calibration data, with version and date (as detailed in Section 3.1.4). This up-grade can produce the revision of GIADA in-flight data products, with consequent generation of updated data sets. 2.3.4 Other Files written during Calibration The procedures, HW and SW tools and materials (grains) used for the calibration of GIADA are described in AD.10 and various technical notes. The information about the chemical and physical properties of the grain materials used for the calibration are reported in a data base. It is not intended to convert these data in PDS format, but to collect the relevant documents / data in the GIADA internal archive. 2.3.5 In-Flight Data Products GIADA is switched on at commissioning for: - Launch lock removal - Nominal instrument check and calibration - Execution of interference and pointing procedures GIADA is switched on periodically during cruise for: - Nominal instrument health check and calibration GIADA is an event driven experiment, i.e., the number of detected grain events depends on the environment met at the comet. For this reason it is essential that GIADA is ON since the beginning of the approach to the target comet and for the longest possible period. By this approach GIADA shall fulfil its scientific goals and shall support lander and other S/C and P/L functions by monitoring continuously the dust environment since early phases of the Rosetta mission at the comet. During nominal operation: > some key "scientific" HK data (e.g., temperatures, light source levels) are acquired at the same time of scientific data acquisition, for optimal scientific data analysis; > subsystem and main electronics calibration is performed periodically for proper check of engineering and scientific calibration data; > full HK data are acquired periodically for GIADA health check. The scientific data expected during the active mission are similar to those obtained during on-ground calibration with grains. Of course, the rate of event detection depends on the characteristics of the comet environment met. Predictions are based on comet production rates and coma models. The possible events expected during nominal operation at the comet are: o Single grain detection by the GDS only device o Single grain detection by the IS only device o Single grain detection by the GDS + IS devices in combination o Periodic reading of dust accumulation on each of the five micro-balances o Heating and reading of one of the five micro-balances (only by TC). As explained in previous sections, these results are used to describe the dust environment of the comet coma and to trace back information about the nucleus properties. Each GDS / IS / GDS+IS grain detection will be tagged with time and the main dynamic (speed, momentum) and physical (mass) properties deduced from GIADA data. Each detection will be also associated to the instantaneous S/C attitude conditions to correlate detected events with orientation of GIADA sensors with respect to coma environment, comet and Sun. A similar approach is valid for the cumulative information deduced by the MBS's. Also in this case it is essential to correlate the output frequency variations (i.e., mass accumulation) to the evolution of orientation of the sensor directions (i.e., the Rosetta S/C). 2.3.6 Steps of GIADA data deliveries For GIADA data the CODMAC 2 level (see Table 2.3) of data analysis stops at the conversion of raw data (ADC values) in calibrated physical quantities (through the engineering conversion factors). It is obvious that GIADA will not collect "dust events" during the Rosetta cruise to the comet. Therefore, delivered GIADA data shall pertain to housekeeping and checking of system and sub-systems. Therefore, data elaboration shall be limited CODMAC 2 level. Nominally, no GDS, IS or GDS-IS data shall be detected. Any of these data, reported in data sets pertaining to cruise phase, shall have to be considered as "bad data" due to spurious / noise events and not related to any real dust detection. The CODMAC 3 level (see Table 2.3) consists in the conversion of the data from calibrated physical quantities to scientific quantities (through scientific conversion parameters / tables). Since "real dust data" shall be available starting from when Rosetta will approach the target comet, data sets at CODMAC 3 level shall be consequently produced starting from that mission phase. The data sets formed by data at CODMAC 3 level shall be different from those containing data at CODMAC 2 level, as they will mainly contain data for single grains detected by GDS or IS or GDS+IS and cumulative dust mass detection by MBSs. Once the GIADA events vs. time are available together with S/C attitude information, the following higher level (CODMAC level 5 - see Table 2.3) elaboration of GIADA data is possible to derive information, such as the cumulative dust (e.g., flux and fluence) and grain (e.g., mass, speed, momentum) properties vs. coma evolution. Data at CODMAC 2 and 3 levels of elaboration are already useful for cross-instrument calibration and scientific analysis for the objectives mentioned in Section 2.1. A thorough use of the GIADA data is, of course, achieved after the higher level elaboration. 2.3.7 Software It must be recalled that GDS and MBS have no on-board calibration system, while IS is equipped with an internal (PZT) stimulator that will be used to monitor in time the sensitivity evolution to a fixed stimulus. Moreover, some on-board internal calibration of the ME is performed periodically to check the evolution of the signal transfer chain and properly tune the engineering conversion factors, if needed. Based on the previous considerations, the basic pipeline for the GIADA raw (ADC) data elaboration consists of two main steps. > Once the engineering conversion factors are determined (or modified, if needed) the conversion from ADC units to engineering units (physical quantities) of the sensor readings (first level - CODMAC 2 - of data analysis) is done by applying the transfer functions (automatically applied by the GES). Raw (ADC) data can be reprocessed, if needed, after updating of the engineering conversion parameters (a new data set is produced for each new elaboration). > The conversion from physical quantities to scientific quantities (second level - CODMAC 3 - of data analysis) is done by applying the scientific conversion factors determined during the on-ground calibrations. These factors could, in principle, be refined by further experiments in laboratory on the PFM (or other laboratory models) by extending the number of events and types of grains used for the calibration. It is useful to recall that it has been checked that the FS and PFM scientific calibration curves do match quite well (once the intrinsic characteristics of the two instruments, such as, e.g., laser source intensity, detector sensitivity, are taken into account). Any upgrade of the scientific calibration data could result in a modification of the parameters for the scientific calibration curves / tables, with consequent new elaboration of the flight data (a new data set is produced for each new elaboration). Based on the previous considerations, both for the engineering and for the scientific calibration data, file coding shall be defined to account for different possible elaborations of the same raw data. Each elaboration will correspond to a different data set, labelled also by the version of the transfer functions (i.e., calibration data set). The last (highest) step of data analysis to obtain statistical information about the comet dust environment is more complex and will require various TBD tools, based also on the use of grain dynamic models, to trace back the in situ measurements to the overall description of the comet coma and nucleus. 2.3.8 Documentation As illustrated in the previous sub-sections all documentation, such as technical notes and reports, relevant for proper use of GIADA data shall be collected also in the "DOCUMENT" directory, according to the PDS formats. The "DOCUMENT" directory shall include at least the following documents: * RO_GIA_OACUPA_IF_011_I3, the present interface document between Rosetta Project Office and GIADA Instrument Team where the data organisation is detailed, in compliance with Planetary Data System (PDS) Standards, Version 3.0, Jet Propulsion Laboratory (JPL) document JPL D-7669. The same document includes details about GIADA instrument, with an extract from the GIADA User Manual; * a Test report, with a variable name, about the analysis of data obtained during the specific cruise phase; Additional documentation shall be provided in the "EXTRAS" directory. In general, documents shall be converted in PDF format for an easy access and use. By this approach, also the use of any image incorporated in the files will be accessible for any further use. 2.3.9 Derived and other data products All the information and data that will not be included in the PDS archives shall be maintained in the GIADA internal archive, that is constantly upgraded and maintained. Data products resulting from co-operation with other instrument teams are to be agreed and are presently TBD. Any increase on scientific return from the combined use of GIADA data with results of other experiments is considered highly desirable by the GIADA team. 2.3.10 Ancillary Data Usage As mentioned above, a proper use of GIADA data requires a direct link with S/C orbit and attitude data. Primary information on these parameters is included in the files containing the GIADA events, by computing (with the software tools provided by ESOC) the geometric configuration of the S/C at the exact time of the GIADA events (see Section 4.3.2). In fact, it is essential to know the orientation of the GIADA sensors (i.e., of Rosetta S/C) with respect to comet and Sun and S/C velocity to properly interpret the meaning / origin of the detected events. 3 Archive Format and Content This chapter contains general rules and constrains for GIADA data sets. The scheme and convention used for naming directories and files is specified below, while specific information is given in Chapter 4. It shall be noted that the creation and maintenance of the PDS archive is done by the PDS Converter (PDSC) software of the GIADA EGSE software and by standard Windows directory handling. Details about the requirements on GIADA PDSC are described in AD.5 and AD.6. 3.1 Format and Conventions 3.1.1 Deliveries and Archive Volume Format The directory tree must be compatible, in terms of directory organisation and naming and file organisation, with the PDS standards (AD.1, AD.2 and AD.3). Each logical archive volume shall contain one GIADA PDS data set. Separate data sets shall be created for the two GIADA models (i.e., for PFM and FS models). One data set shall be created for each mission phase and one for each n-orbits or period of time during cometary phase (see AD.3 Appendix F - Table 2). Different data sets shall be created for each data processing level. The top-level directory of each logical archive volume shall be the GIADA PDS data set id. The volume set name shall be as that of the data set (see Section 3.4.2). Figure 2 shows the structure of a data volume, while Figure 3 shows an example of the structure of the data for the FS model, i.e. that used for the GIADA FS model calibration. The logical archive volumes are created and maintained by a standard Windows tool. --------------- | DATA SET ID | --------------- | | LEVEL 0 | --------------------------------------------------------------- | | | | | | | | --------- ---------- ------- ----- -------- ------- ---------- ------ |CATALOG| |DOCUMENT| |CALIB| |S/W| |EXTRAS| |INDEX| |GEOMETRY| |DATA| --------- ---------- ------- ----- -------- ------- ---------- ------ | | | LEVEL 1 | | | ------ ----------- --------- ------| -----------| ---------| ------|- -----------|- ---------|- |DOC1|- | ENG_CAL |- | GDS |- ------ ----------- --------- | | LEVEL 2 | | ------ ----------- ------| -----------| ------|- ------------|- |FILE|- |YYYY_MM_DD|- ------ ------------ | LEVEL 3 | ------ ------| ------|- |FILE|- ------ LEVEL 4 Figure 2 PDS archive structure of GIADA for one data set ------------- ------------ ------------ |-| DATA |--|-| GDS |----|2005_06_23| | ------------- | ------------ | ------------ | | ------------ | | |-| GDS_CAL | | ------------ | | ------------ |-|2005_06_25| | | ------------ . ------------ | |-| IS | . | | ------------ . | | ------------ . | |-| IS_CAL | . | | ------------ | ------------ | | ------------ |-|2005_07_12| | |-| GDS_IS | ------------ | | ------------ | | ------------ | |-| MBS | | | ------------ | | ------------ | |-| MBS_HEAT | | | ------------ | | ------------ | |-| MBS_CAL | | | ------------ | | ------------ | |-| HK_SCI | | | ------------ | | ------------ | |-| HK_DATA | | ------------ | ------------- ------------ |-| CALIB |--|-| ENG_CAL | | ------------- | ------------ ----------------------------- | | ------------ | RO-CAL-GIA-2-GRND-FS-V1.1 |-| |-| SCI_CAL | ----------------------------- | ------------ | ------------- |-| EXTRAS | | ------------- | ------------- |-| SOFTWARE | | ------------- | ------------- |-| INDEX | | ------------- | ------------- |-| SOFTWARE | | ------------- | ------------- ------------ |-| GEOMETRY |--|-| EROSORHR | | ------------- | ------------ | ------------- . |-| DOCUMENT | . | ------------- | ------------ |-| EROSOASW | ------------ Figure 3. Example of PDS archive structure of GIADA for FS ground calibration data set 3.1.2 Data Set ID Formation The Data Set ID name formation shall respect the following rules: DATA_SET_ID = "--- - --" where the different parameters are as reported in Table 3.1, Table 3.2 and Table 3.3. See Section 4.3.1 for an example of the "key" elements in a CONFIG file. ================================================================================ | | RO | Required | -------------------------------------------------------------------------------- | | see Table 3.2 | Required | -------------------------------------------------------------------------------- | |GIA (only for the DATA_SET_ID| Required | | | creation) | | -------------------------------------------------------------------------------- || CODMAC level: see Table 2.3 | Required | -------------------------------------------------------------------------------- | | see Table 3.33.3 | Optional | -------------------------------------------------------------------------------- | | free character string | Optional | | | containing only A-Z, 0-9 | | -------------------------------------------------------------------------------- | | e.g. V1.0 | Required | ================================================================================ Table 3.1. Conventions for DATA_SET_ID Formation ================================================================================ | TARGET_NAME | TARGET_TYPE | in | in| | | | DATA_SET_NAME | DATA_SET_ID | ================================================================================ | "67P/CHURYUMOV-GERASIMENKO | "COMET" | 67P | C | | (1969 R1)" | | | | -------------------------------------------------------------------------------- | "(2867) STEINS" | "ASTEROID" | STEINS | A | -------------------------------------------------------------------------------- | "(21) LUTETIA" | "ASTEROID" | LUTETIA | A | -------------------------------------------------------------------------------- | "EARTH" | "PLANET" | EARTH | E | -------------------------------------------------------------------------------- | "MARS" | "PLANET" | MARS | M | -------------------------------------------------------------------------------- | "CALIBRATION" | "CALIBRATION"| CAL | CAL | -------------------------------------------------------------------------------- | "CHECKOUT" | "N/A" | CHECK | X | -------------------------------------------------------------------------------- | "INTERPLANETARY DUST" | "DUST" | DUST | D | -------------------------------------------------------------------------------- | "INTERSTELLAR DUST" | "DUST" | DUST | D | -------------------------------------------------------------------------------- | "METEOROID STREAM" | "DUST" | DUST | D | -------------------------------------------------------------------------------- | "SOLAR WIND" |"SOLAR SYSTEM"| SW | SS | ================================================================================ Table 3.2. Conventions for target identification (from AD.3) ================================================================================ | Simple MISSION_PHASE_NAME | Abbreviation | ================================================================================ | "GROUND" | GRND | -------------------------------------------------------------------------------- | "LAUNCH" | LEOP | -------------------------------------------------------------------------------- | "COMMISSIONING" | CVP | -------------------------------------------------------------------------------- | "CRUISE 1", "CRUISE 2", "CRUISE 3", ... | CR1, CR2, CR3, ... | -------------------------------------------------------------------------------- | "EARTH SWING-BY 1", "EARTH SWING-BY 2", | EAR1, EAR2, EAR3 | | "EARTH SWING-BY 3" | | -------------------------------------------------------------------------------- | "MARS SWING-BY" | MARS | -------------------------------------------------------------------------------- | "STEINS FLY-BY", "LUTETIA FLY-BY" | AST1, AST2 | -------------------------------------------------------------------------------- | "RENDEZVOUS MANOEUVRE 1", "RENDEZVOUS MANOEUVRE 2" | RVM1, RVM2 | -------------------------------------------------------------------------------- | "NEAR COMET DRIFT" | NCD | -------------------------------------------------------------------------------- | "FAR APPROACH TRAJECTORY" | FAT | -------------------------------------------------------------------------------- | "CLOSE APPROACH TRAJECTORY" | CAT | -------------------------------------------------------------------------------- | "TRANSITION TO GLOBAL MAPPING" | TGM | -------------------------------------------------------------------------------- | "GLOBAL MAPPING PHASE" | GMP | -------------------------------------------------------------------------------- | "CLOSE OBSERVATION PHASE" | COP | -------------------------------------------------------------------------------- | "LANDER DELIVERY AND RELAY" | SSP | -------------------------------------------------------------------------------- | "COMET ACTIVITY LOW" | LOW | -------------------------------------------------------------------------------- | "COMET ACTIVITY MODERATE INCR" | MINC | -------------------------------------------------------------------------------- | "COMET ACTIVITY SHARP INCREASE" | SINC | -------------------------------------------------------------------------------- | "COMET ACTIVITY HIGH" HIGH "NEAR PERIHELION" | PERI | -------------------------------------------------------------------------------- | "EXTENDED MISSION" | EXT | ================================================================================ and/or: ================================================================================ | Accumulative MISSION_PHASE_NAME | Abbreviation | Corresponding simple mission| | | | phases | ================================================================================ | "APPROACH" | APPR | FAT to COP | -------------------------------------------------------------------------------- | "ESCORT" | ESCO | LOW to PERI | -------------------------------------------------------------------------------- | "COMET" | COM | FAT to PERI, i.e. APPR, SSP | | | | and ESCO | ================================================================================ Table 3.3. identification of mission phases (from AD.3) As an example the DATA_SET_ID for GIADA data obtained during calibration by the GDS sub-system and processed to CODMAC 2 level with engineering calibration factors of version 1.1 is: DATA_SET_ID = RO-CAL-GIA-2-GRND-FS-V1.1 Note that, in general, for data sets concerning CODMAC 2 level the Version shall be determined by the set of Engineering Calibration Factors, while for data sets concerning CODMAC 3 level the Version shall be determined by the set of both Engineering and Scientific Calibration Factors. 3.1.3 Data Directory Naming Convention All files containing GIADA data shall be stored in a directory called "DATA" (see Figure 2). The structure of the sub-directories of this directory shall guarantee an easy search, identification and selection of the files. To this aim, the structure shall contain a subdirectory for (see Figure 3): - each GIADA subsystem (GDS, IS, GDS_IS, MBS e MBS_HEAT), - each of the relevant calibration data (GDS_CAL, IS_CAL, MBS_CAL), - the scientific housekeeping data (HK_SCI), - the housekeeping data (HK_DATA). Within each of these subdirectories a further organisation is required, divided by year and month (name format: YYYY_MM_DD = year, month and date). 3.1.4 File naming Convention The files containing data are tables in ASCII format, containing different times, the raw (ADC) data and the data converted into engineering units. A Table (*.TAB) in ASCII format shall be created for each table in the GES scientific database. The PDS format uses the ISO 9660 level 2 standard for the filenames. Thus, the filenames shall have a maximum length of 31 characters. The format is "27.3". The characters before the point are the filename, while those after the point are the extension. According to the PDS formatting standard, each TABLE must be coupled with a descriptive LABEL in ODL to describe the table content. For the GIADA data the DETACHED format shall be used for the descriptive label. Therefore, each table shall have a label in a separate file. The extension for the files containing scientific and housekeeping GIADA data shall be: ".TAB", while the description files (LABEL) shall have ".LBL" extension. All filenames are in capital letters. Filenames are not case sensitive (note that some CD/DVD burning software simply moves all capitals in small characters). The names of the files containing the data (.TAB) shall follow the rules reported in Table 3.43.4 and shall be formed by: - the name of the corresponding access table, - a number (giving the data and time of the original file): YYYYMMDDThhmmss - a flag (I) indicating the interface (M = Main or R = Redundant) of GIADA active during the data acquisition of the session under treatment - a code (Vn_m) indicating the version of the (engineering or engineering and scientific) conversion factors used. -------------------------------------------------------------------------------- | Data type |Table in EUDB.mdb file| PDS Filename | ================================================================================ | GDS data | NM_GDS | GDSYYYYMMDDThhmmssI_Vn_m.TAB | -------------------------------------------------------------------------------- | IS data | NM_IS | ISYYYYMMDDThhmmssI_Vn_m.TAB | -------------------------------------------------------------------------------- | GDS + IS data | NM_GDS_IS | GDSISYYYYMMDDThhmmssI_Vn_m.TAB | -------------------------------------------------------------------------------- | MBS data | NM_MBS | MBSYYYYMMDDThhmmssI_Vn_m.TAB | -------------------------------------------------------------------------------- | SCI Housekeeping data| NM_SCI | HKSCIYYYYMMDDThhmmssI_Vn_m.TAB | -------------------------------------------------------------------------------- | GDS CAL data | GDS_CAL | GDSCALYYYYMMDDThhmmssI_Vn_m.TAB| -------------------------------------------------------------------------------- | IS CAL data | IS_CAL | ISCALYYYYMMDDThhmmssI_Vn_m.TAB | | | IS_CALPZT | ISCPZTYYYYMMDDThhmmssI_Vn_m.TAB| -------------------------------------------------------------------------------- |MBS f vs. heating data| MB_HEAT | MBHEATYYYYMMDDThhmmssI_Vn_m.TAB| | | MB_FREQ_TEMP | MBFREQYYYYMMDDThhmmssI_Vn_m.TAB| -------------------------------------------------------------------------------- | MBS CAL data | MBS_CAL | MBSCALYYYYMMDDThhmmssI_Vn_m.TAB| ================================================================================ | | File to be used: | | ================================================================================ | Conversion factors | SESS-hh-mm-ss.ges | CONVFACTORS_K_I_Vn_m.TAB (1) | | | (various versions) | (note: to be saved in the | | | | ENG_CAL directory) | ================================================================================ K = PFM o FS; I = M o R; Vn_m = version of calibration file (1) This Table is created by the PDSC from the ConvFactors.ini file each time the engineering calibration parameters are modified. Table 3.4. Data filenames For the naming of housekeeping data files, the same rules applied to the data files shall be used. I.e., the housekeeping data tables shall have the name reported in Table 3.5. ================================================================================ | Data type | Table in HKDB.mdb file | File coding | ================================================================================ | Housekeeping data | HK_DATA | HKDATAYYYYMMDDThhmmssI_Vn_m.TAB | ================================================================================ Table 3.5. Housekeeping data filenames For each .TAB file a corresponding .LBL file is generated according to the same name coding. The name of the files shall be generated automatically by the PDSC, but it shall be possible to modify it during the file saving, if required. Note: Each session shall contain data acquired with a fixed interface (M or R). This poses the following requirements on the download process of data from the DDS (via ftp or web): - it is necessary to know a priori (from the operative record of ROSETTA) in which phases and periods GIADA was operated by M or R interfaces; - it is necessary to download the GIADA data from the DDS in time intervals separated in coincidence of the change of interface. By this approach it is sure that each session created by the "GIADA DDS converter" will contain data acquired by one of the GIADA interfaces only. This implies the use of the correct file ConvFactors.ini (relevant for the Main or Redundant I/F) for the engineering conversion factors. The trace of the used interface shall be maintained in the file SESS-hh-mm-ss.ges, which is a copy of the ConvFactors.ini file used during the conversion of the session. Note: The 4.x version of the GES is equipped with a function to select the ConvFactor.ini file among 4 different choices: Main-PFM, Main-FS, Red.-PFM and Red.-FS, respectively, that will be reported in the file SESS-hh-mm-ss.ges. Note on PDSC operation sequence: Five keywords are present in the ConvFactor.ini files (of the GES) as 'REM' lines (note that 'REM' represents a comment line for the GES program) corresponding to: - the version of the conversion factors (Vn_m), - the interface (M = Main or R = Redundant), - the GIADA model (FS or PFM), - the date of the last updating of the file, - the author of the last modification. A typical operative sequence of the PDSC to generate the names of ".TAB" file is the following: i. from the "Data Storage" directory, of the access archive generated by the GES (or other directory), a subdirectory corresponding to a date is selected; ii. the date is recorded (to be used afterwards for the PDS output filename generation); iii. the '.ges' file relevant to the session to be converted is selected; iv. the '.ges' filename is recorded (it contains the time, to be used for the PDS output filename generation); v. in the SESS-hh-mm-ss.ges file the conversion factors used for the conversion of the raw data (DDS converter) into the GES database are recorded, together with the indication of (REM fields) version (Vn_m) of the conversion factors, interface (Main or Redundant), model (FS o PFM), date of last file modification, author. The information on interface and version shall be used to generate the filenames. The model shall address the choice of the destination root; vi. in the chosen directory of the access database, all data and information are available for the PDSC to generate the output PDS files, i.e., engineering data (EUDB and HKDB) and raw data (RDDB); vii. the '.ges' filename is saved in the directory ENG_CAL according to the naming in Table 3.43.4. If a filename with the same name is already present in the ENG_CAL a comparison of the content of the files is performed. If the content is NOT the same a warning message on the screen is generated. No overwrite operation shall be allowed at this stage. The new file can be "saved as ..." or the ongoing conversion can be aborted; viii. the PDS output filenames are generated (based on date and time of the selected session) by the PDSC as last step. It shall be possible to change filename (i.e., date and time). All operations are recorded in a log file labelled by date and time. A log file is generated each time the PDSC is used. The log file is recorded in the directory where the program is run. The PDSC shall be able to operate even if one or more of the original tables of the GES files are empty and/or when the GEOMETRY files or data are not available. In these cases the record in the PDS files shall contain "N/A". The saving of the PDS files in the final directory shall be performed as last step, while intermediate file saving shall be performed in a "temporary directory". By such approach it is ensured that any abort of the PDSC during operation shall not affect the content of the PDS directory archive. 3.2 Standards Used in Data Product Generation 3.2.1 PDS Standards The PDS standards used for the GIADA data products are compliant with AD.2. The PDS format uses the ISO 9660 level 2 standard for the filenames. Thus, the filenames shall have a maximum length of 31 characters. The format is "27.3". The characters before the point are the filename, while those after the point are the extension. 3.2.2 Time Standards The GIADA data recorded in the GES database are of three types: scientific, calibration and housekeeping. All of them shall be organised in tables and ordered according to the "Mission Time" in UTC and, in sequence, according to the event time (for the scientific events) (e.g., GDS: "GDS_Event_Time") always in UTC. This implies that all PDS tables contain the following four times: - "Mission time" (UTC): this corresponds to the time stamp of the S/C packet in UTC and is provided by ESA, - "Event Time" or SCET_Time, i.e. the time stamp of the packet in S/C time, - the time of the scientific event (e.g., GDS_Event_Time), i.e., the time of the S/C associated by GIADA to the event, - the time of the scientific event converted in UTC. All UTC times in tables shall have the following format: YYYY-MM-DDThh:mm:ss.fffff while the format used in PDS labels shall be computed at the millisecond precision and shall be: YYYY-MM-DDThh:mm:ss.fff Note: - the Mission time in UTC is the DDS time on ground and is provided by ESOC based on the "Time Conversion File"; - the conversion of the event SCET time into UTC units shall be performed by the PDSC taking into account the difference between SCET time of the packet and SCET time of the event and the UTC of the packet (i.e., the "mission time"). It is assumed, for the time being, that no correction by using the "Time Conversion File" (that will be distributed by ESOC and adjourned periodically) is required to derive the time of event in UTC. Note: the packets arriving from Rosetta could be of different qualities: - good: this happens when the GIADA time is synchronised with Rosetta; - inaccurate: this happens when the GIADA time is NOT synchronised with Rosetta but packets are transmitted to ground in near real time (VC0 line). In this case it might still be possible to correlate the GIADA event time with any S/C auxiliary data time; - bad: this happens when the GIADA time is NOT synchronised with Rosetta and packets are transmitted to ground with unknown delay (VC1 line). In this case the correlation of GIADA event time with the AUX data time is impossible. The identification of GIADA "inaccurate" or "bad" data in terms of time stamp is easy as the first digit of time will be of the type "2", quite different from the one obtained under synchronised conditions. Therefore, in general, these data shall not fall in the time window of the various mission periods. No flag of the packet quality shall be reported in the GES and PDS data formats. If needed, the check of the data quality shall be done by analysing the content of the log file generated by the ESOC converter (from ESOC format to GES format). 3.2.3 Reference Systems The reference systems is as specified in Section 4.3.2 (see also AD-11 Appendix H). In particular, the applied Fortran routines use "orbit" and "attitude" files in entry and the output depends on the coordinate system used to produce these files. The documentation explains that the values in these files are given in EMEJ2000, i.e. in EARTH MEAN EQUATOR J2000. As a consequence, the two keywords COORDINATE_SYSTEM_ID and COORDINATE_SYSTEM_NAME shall reflect this choice. 3.2.4 Other Applicable Standards N/A. 3.3 Data Validation The software tools for GIADA data elaboration (including PDS Converter) are produced based on the requirements and specifications given in AD.5 and are maintained under configuration control. The validation of the software tools is done according to well set procedures, that ensure that the software product is compatible with requirements and PDS standards. The GIADA team verifies the validity of the tool by application to real GIADA data. 3.3.1 Data Quality At each GIADA switch ON, a careful data analysis is performed to validate data quality with respect to previous on-ground and in-flight switch-on. This check is based on comparison of GIADA housekeeping data and analysis of operation conditions. The quality of GIADA data is identified based on this analysis. The approach is different for data sets at CODMAC 2 or 3 levels and for housekeeping or scientific data. For data at CODMAC 2 level, the data quality convention is as shown in Table 3.6. ================================================================================ | DATA_QUALITY_ID | DATA_QUALITY_DESC | Comment | ================================================================================ | 1 | GOOD | When all HK and SCI data in the TAB | | | | file are good | -------------------------------------------------------------------------------- | 2 | SPURIOUS EVENTS | When only some spurious SCI data are | | | PRESENT | present in the TAB | -------------------------------------------------------------------------------- | 3 | BAD | When a large amount of spurious SCI | | | | data is present in the TAB | -------------------------------------------------------------------------------- | N/A | N/A | When the file contains reference | | | | information/data which are not HK or | | | | SCI data | ================================================================================ Table 3.6. Data Quality for CODMAC 2 level data. For data at CODMAC 3 level, it is expected to perform a "grain by grain" selection so that each single event shall be tagged with a quality code or only "good" data shall be delivered. 3.4 Content This section contains information that is data product independent and is common to (most) data sets. 3.4.1 Volume Set Each logical archive volume shall contain one GIADA PDS data set. Necessary documentation for the logical archive volumes shall be provided by the GIADA team. Any other non-data file necessary for the logical archive volume will be provided by the GIADA team. It shall be possible to modify and implement the structure of the directory tree with new sub-directories, whenever needed. The creation and management of the directories shall be performed by a standard Windows tool. The PDSC tool shall be capable to address interactively the newly created files, containing the GIADA data converted from the "GES access archive" into the PDS format, into one of the sub-directories of the tree, during the file saving operation. During this phase, the filename shall be generated automatically (according to the criteria defined in AD.5), but it shall be possible to modify the name ("save as" option). Moreover it shall be possible to generate interactively and in real time a new sub-directory of the tree in which the file is finally saved. Table 3.7 lists the keywords mandatory for the VOLUME object of the Rosetta. ================================================================================ | Keyword |Req. PDS keywords strongly|Max. length| Standard value(s) | | |advised by ESA-PDS team. | | | ================================================================================ | DATA_SET_ID | req. | 40 | see Section 3.1.2 | -------------------------------------------------------------------------------- | DESCRIPTION | req. | N/A | "N/A" | -------------------------------------------------------------------------------- | MEDIUM_TYPE | req. | 30 | "ELECTRONIC" | -------------------------------------------------------------------------------- | PUBLICATION_DATE | req. | 10 | YYYY-MM-DD | -------------------------------------------------------------------------------- | VOLUME_FORMAT | req. | 20 | "ANSI" | -------------------------------------------------------------------------------- | VOLUME_ID | req. | 12 | "N/A" | -------------------------------------------------------------------------------- | VOLUME_NAME | req. | 60 | "N/A" | -------------------------------------------------------------------------------- |VOLUME_SERIES_NAME| req. | 60 | "N/A"(recommended),| | | | | "ROSETTA SCIENCE | | | | | ARCHIVE" | -------------------------------------------------------------------------------- | VOLUME_SET_NAME | req. | 60 | "N/A" | -------------------------------------------------------------------------------- | VOLUME_SET_ID | req. | 40 | "N/A" | -------------------------------------------------------------------------------- | VOLUME_VERSION_ID| req. | 12 | "N/A" | -------------------------------------------------------------------------------- | VOLUMES | req. | N/A | "UNK" | ================================================================================ Table 3.7. Mandatory keywords and standard values for the VOLUME object 3.4.2 Data Set Naming The data set naming scheme is as follows and based on the conventions in Table 3.8. DATA_SET_NAME = "--- -- -" ================================================================================ | | ROSETTA-ORBITER | Required | -------------------------------------------------------------------------------- | | See Table 3.2 | Required | -------------------------------------------------------------------------------- | | GIADA(only for the DATA_SET_NAME | Required | | | creation) | | -------------------------------------------------------------------------------- | | CODMAC level: see Table 2.3 | Required | -------------------------------------------------------------------------------- | | see Table 3.3 | Optional | -------------------------------------------------------------------------------- | | free character string containing | Optional | | | only A-Z, 0-9 | | -------------------------------------------------------------------------------- | | e.g. V1.0 | Required | -------------------------------------------------------------------------------- Table 3.8. Data set name formation As an example the DATA_SET_NAME for GIADA data obtained during calibration by the GDS sub-system and processed to level 1b with engineering calibration factors of version 1.1 is: DATA_SET_NAME = ROSETTA-ORBITER-CAL-GIADA-2-GRND-FS-V1.1 The data set naming is created and maintained by a standard Windows tool. 3.4.3 Directories 3.4.3.1 Root Directory The top-level structure of the ROOT directory of a data archive volume (= data set) corresponds to chapter 19 of the PDS Standards Reference and is summarised below: * AAREADME.TXT file: This file describes the volume (= data set) as a whole. It gives an overview of the contents and organisation of the data set, general instructions for its use and contact information. * VOLDESC.CAT file: This file contains the VOLUME object, which gives a high-level description of the contents of the volume (= data set). Each directory (except the DATA directory) shall include a file named xxxxINFO.TXT, which briefly describes the contents of that directory. In case that an important instrument characteristic can not be described with an existing PDS keyword, this information should be put into a parameter file. 3.4.3.2 Calibration Directory * This directory includes two sub-directories (see Figure 3). All engineering calibration data shall be collected in the ENG_CAL subdirectory. The data are organised in files referring to issue (version Vn_m) and creation date. Each time the engineering calibration data are updated (due to revision of engineering calibration values) a new version of the file ConvFactors.ini shall be generated and, correspondingly, a PDS file shall be created and stored in the ENG_CAL directory. Any support document explaining the choices of the calibration data shall be collected in the "DOCUMENT" directory. A similar approach is used for scientific calibration data, that shall be collected in the SCI_CAL subdirectory (available only for CODMAC 3 level data sets). The data are organised in files referring to issue (version Vn_m) and creation date. Each time the scientific calibration data are updated (due to revision of scientific calibration values) a PDS file shall be created and stored in the SCI_CAL directory. Any support document explaining the choices of the calibration data shall be collected in the "DOCUMENT" directory. The creation and management of the directories shall be performed by a standard Windows tool. 3.4.3.3 Catalog Directory This directory contains the catalog object files for the entire volume (= data set). * CATINFO.TXT: This file contains the description of the contents of the CATALOG directory. * MISSION.CAT: This file contains the PDS mission catalog information about the Rosetta mission (provided by ESA). * INSTHOST.CAT: This file contains PDS instrument host catalog information about the Rosetta spacecraft and the mounting relationship of the instruments within the spacecraft (provided by ESA). * INST.CAT: This file contains the PDS instrument catalog information about the instrument (likely to be the same in all deliveries, unless updates are needed). There will be one file for each instrument providing data to this data set. * DATASET.CAT: This file contains PDS data set catalog information about the data set currently being submitted. * REF.CAT: PDS reference catalog information about every journal article, book or other published reference mentioned in the above catalog objects or their components. * SOFTWARE.CAT: PDS software catalog information about the software submitted in the data set. * TARGET.CAT (optional): This files contains PDS target catalog information about the observation target, i.e. comet, asteroid, Earth or Mars (provided by ESA). * PERSON.CAT (optional): This files contains PDS personnel catalog information about the instrument team responsible for generating the data products. There will be one file for each instrument team providing data to this data set. 3.4.3.4 Index Directory This directory contains the index files summarising all data products in the volume (= data set) by mode, key instrument parameters or mission phase, and organised to facilitate finding the data of interest for a particular scientific question. Information about the observation geometry is included in the data products (e.g., spacecraft position and attitude, illumination conditions, etc.). Information that is not accurately known at the time of delivery and thus will probably be updated later shall be stored in the index files rather than in the data product labels. * INDXINFO.TXT: This file includes the description of the contents of the INDEX directory. * INDEX.LBL: This file includes the detached label for the index table INDEX.TAB. The INDEX_TABLE specific object should be used to identify and describe the columns of the index table. * INDEX.TAB: This file includes the index of the data set in tabular format. 3.4.3.4.1 Dataset Index File, index.lbl and index.tab The Index File (.LBL and .TAB) contains a lists all data files on the volume, the path to the directory containing the file and the name of the file in the archive. For each file information is given about time at which data in the file begin/end, number of rows and number of bytes in rows in the .TAB file. 3.4.3.4.2 Geometric Index File, geoindex.lbl and geoindex.tab Detailed content is TBD. 3.4.3.4.3 Other Index Files Detailed content is TBD. 3.4.3.5 Browse Directory and Browse Files This directory contains browse representations (quick-look, thumbnail) of the data products. Its presence is optional and TBC. 3.4.3.6 Geometry Directory This directory contains the files needed to describe the observation geometry for the data, i.e. trajectory and attitude of the spacecraft, shape model of target comet and asteroids. In addition, the description file GEOMINFO.TXT shall be present. All geometry data released by Rosetta (see AD.11 Appendix H - Table 6) and retrieved for the periods of interest for GIADA shall be collected in subdirectories (one for each type of data). The subdirectories can be named according to the ADID for each data type. The lower levels of the subdirectories shall be organised by year and month (YYYY_MM). The geometry files to be used for archiving purposes are generated by ESA-RSOC: a PDS label for each of the auxiliary data files is provided by ESOC. RSOC will make sure that for each of the mission phases there will be a logical archive volume (data set) containing this information in a PDS compatible format. The creation and management of the directories shall be performed by a standard Windows tool. The retrieval of these data from the DDS shall be performed by the user, via ftp or web, as for the GIADA data. 3.4.3.7 Software Directory This directory contains software for data calibration, visualisation and analysis. Algorithms concerning satellite information are supplied by RMOC. Only public domain software shall be included in PDS archives. Source codes shall be preferred over executable codes, when possible. The subdirectory structure shall indicate the hardware platform and operating system/environment. In addition, the description file SOFTINFO.TXT shall be present. 3.4.3.8 Gazetter Directory This directory contains detailed information about the named features on the target bodies associated with the volume (= data set). The information given here needs not to be approved by the International Astronomical Union, but is provided as a convenience for the researchers in the future. Its presence is optional. It will not be present in the GIADA data sets. 3.4.3.9 Label Directory This directory contains PDS labels and include files that are not packaged with the data products or in the data directory. Include files are files referenced by a pointer in a PDS label. Only files of type FMT, LBL and TXT shall be located in the LABEL directory. In addition, the description file LABINFO.TXT is required. Its presence is optional. It will not be present in the GIADA data sets. 3.4.3.10 Document Directory This directory provides documentation and supplementary and ancillary information to assist in understanding and using the data products in the volume (= data set). The documentation shall describe the mission, spacecraft, instrument, data sets and calibration. The EAICD shall be included. All documents shall be present in ASCII format to ensure long-term readability. Document versions in other formats (Word, PDF, Framemaker, TeX etc.) are possible. In addition, the description file DOCINFO.TXT shall be present. 3.4.3.11 Extras Directory This directory is the designated area for housing useful but non-essential information beyond the scope of the PDS archive requirements. Examples are scientific papers, HTML or XML pages, tables and figures that describe the data products. Any format may be used. In addition, the description file EXTRINFO.TXT is required. 3.4.3.12 Data Directory See Section 3.1. 4 Detailed Interface Specifications 4.1 Structure and Organisation Overview See Section 3.1.1. 4.2 Data Sets, Definition and Content See Sections 3.1.1 and 3.1.4. 4.3 Data Product Design According to the PDS formatting standard, each TABLE must be coupled with a descriptive LABEL in ODL to describe the table content. For the GIADA data the DETACHED format shall be used for the descriptive label. Therefore, each table shall have a label in a separate file. 4.3.1 Content of LABEL files The format of the labels shall follow the PDS standard both for the formatting and for the characters. The LABEL files contain 3 main parts. The first part contains general information (keywords). The character set to be used shall be ASCII 7bit and the characters to be used are from 001 to 127 (decimal values) plus the character (decimal value = 10) and the character (decimal value = 13). The characters and shall be present at the end of each line. Each line of the LABEL file shall not exceed 80 characters, including characters. Keywords used in all LABEL files are reported in Table 4.14.1. ================================================================================ | Keyword | Max. length | Values | ================================================================================ | PDS_VERSION_ID | 6 | PDS3 | -------------------------------------------------------------------------------- | LABEL_REVISION_NOTE | N/A | "Vn.m" (only in CATALOG labels) | -------------------------------------------------------------------------------- | RECORD_TYPE | 20 | FIXED_LENGTH, VARIABLE_LENGTH,...| -------------------------------------------------------------------------------- | RECORD_BYTES | N/A | | -------------------------------------------------------------------------------- | FILE_RECORDS | N/A | | -------------------------------------------------------------------------------- | FILE_NAME | N/A | | -------------------------------------------------------------------------------- | DATA_SET_ID | 40 | See Section 3.1.2 | -------------------------------------------------------------------------------- | DATA_SET_NAME | 60 | See Section 3.4.2 | -------------------------------------------------------------------------------- | PRODUCT_ID | 40 | "" | -------------------------------------------------------------------------------- | PRODUCT_CREATION_TIME | 24 | YYYY-MM-DDThh:mm:ss(.fff) | -------------------------------------------------------------------------------- | PRODUCT_TYPE | 30 | EDR, RDR, REFDR, UDR, ANCDR | -------------------------------------------------------------------------------- | MISSION_ID | N/A | ROSETTA | -------------------------------------------------------------------------------- | MISSION_NAME | 60 | "INTERNATIONAL ROSETTA MISSION" | -------------------------------------------------------------------------------- | MISSION_PHASE_NAME | 30 | See Table 3.3 | -------------------------------------------------------------------------------- | INSTRUMENT_HOST_ID | 6 | RO | -------------------------------------------------------------------------------- | INSTRUMENT_HOST_NAME | 60 | "ROSETTA-ORBITER" | -------------------------------------------------------------------------------- | INSTRUMENT_ID | 12 | GIADA | -------------------------------------------------------------------------------- | INSTRUMENT_NAME | 60 | "GRAIN IMPACT ANALYSER AND DUST | | | | ACCUMULATOR" | -------------------------------------------------------------------------------- | INSTRUMENT_TYPE | 30 | "DUST DETECTOR" | -------------------------------------------------------------------------------- | INSTRUMENT_MODE_ID | 20 | | -------------------------------------------------------------------------------- | INSTRUMENT_MODE_DESC | N/A | | -------------------------------------------------------------------------------- | TARGET_NAME | 30 | See Table 3.2 | -------------------------------------------------------------------------------- | TARGET_TYPE | 20 | See Table 3.2 | -------------------------------------------------------------------------------- | START_TIME | 24 | YYYY-MM-DDThh:mm:ss.fff | -------------------------------------------------------------------------------- | STOP_TIME | 24 | YYYY-MM-DDThh:mm:ss.fff | -------------------------------------------------------------------------------- | SPACECRAFT_CLOCK_START_COUNT| 30 | | -------------------------------------------------------------------------------- | SPACECRAFT_CLOCK_STOP_COUNT | 30 | | -------------------------------------------------------------------------------- | PRODUCER_ID | 20 | | -------------------------------------------------------------------------------- | PRODUCER_FULL_NAME | 60 | | -------------------------------------------------------------------------------- | PRODUCER_INSTITUTION_NAME | 60 | | -------------------------------------------------------------------------------- | DATA_QUALITY_ID | 3 | -1, 0, 1, ... | -------------------------------------------------------------------------------- | DATA_QUALITY_DESC | N/A | | ================================================================================ Table 4.1 Keywords used in LABEL files The second part is a pointer to the TABLE file containing the data or the conversion factors. As an example, for the LABEL File pointing to the TABLE File containing the GDS data, the pointer is: ================================================================================ | ^TABLE | ^TABLE | "GDS20020808T130339M_V1_1.TAB" | ================================================================================ The third part contains the description of all columns forming the TABLE file (see Sections from 4.3.3 to 4.3.13). In order to guarantee flexibility, the PDSC software shall use one or more: * configuration tables (CONFIG) * table skeletons (TEMPLATE). For each of the parameters/headers, values/codes are reported in the CONFIG tables. It shall be possible to update and/or implement the content of the CONFIG files with new values and/or codes, whenever needed, without affecting the PDSC operation. The PDSC tool shall read the values/codes at the moment of the initialisation, and shall present them in "curtain menus" linked to the fields. The updating/implementation of the CONFIG files shall be performed by a standard editor and is not embedded in the PDSC code. The structures of the LABEL files, where all parameters and headers forming the labels are reported, shall be identified in the TEMPLATE files. For each of the parameters/headers, values/codes are reported in the CONFIG tables. It shall be possible to update and/or implement the content of the TEMPLATE files without affecting the PDSC operation. This implies that it shall be possible to: a) introduce permanent changes to the CONFIG tables only off line by editing the file and saving the changes; b) edit and change the content of the value/text fields presented during the PDSC operation: these changes shall be reflected in the output file under preparation, but shall affect in no way the CONFIG files. This approach shall be generally valid for the headers and the description of the TABLE object. All changes to CONFIG and TEMPLATE files shall not be possible to the "user" and shall be reserved to the "administrator" only. The TEMPLATE files for all the types of LABEL files are reported in the following subsections. 4.3.2 Content of TABLE files The data TABLES shall be formed by n columns and m rows. The data in the tables shall be in ASCII format. Each row shall contain all information describing an event of the type pertaining to the table. The data tables shall have the same columns of the corresponding access files (created by the GES 4.0 software). In addition, the PDS tables shall contain additional information, such as times characterising the event and geometry information coming from auxiliary files computed for the times of the GIADA events. These data shall be computed by the PDSC tool starting from the files, downloaded from the DDS through the relevant ADID, by using the sub-routines provided by ESA. Moreover, the PDS files shall contain, together with the data converted in engineering units (through the engineering calibration data), also the values in ADC counts for the same readings. All counts shall be reported as INTEGER values. The columns of data shall be separated by commas (",") and the empty spaces shall be filled with to guaranty the column alignment. The numeric values shall be right aligned. The columns containing text shall be left aligned and the text shall be included in double quotes (i.e., "text"). The format and number of characters for the numerical values to be used in the ASCII tables shall be chosen based on the sensitivity of the reading for the various physical parameters. The format shall be defined in the COLUMN definition in the LABEL file. The tables shall contain the following times: > "Mission time" (UTC) (i.e., the time stamp of the S/C packet in UTC, provided by ESA), > "Event Time" (i.e., the SCET_Time, i.e., the time stamp of the packet in S/C time), > The time of the scientific event (i.e., GDS_Event Time, i.e., the time of the S/C associated by GIADA to the event), > The previous time in UTC. The geometry data to be included in the tables shall depend upon the Rosetta mission phase as reported in Table 4.2 (see also AD-11). ================================================================================ | Start |Time | Event |Relative |Relative | Linear and |Orientation | | |after | |Position 1 |Position 2| angular | | | |launch | | | | velocity | | | |(months)| | | | | | ================================================================================ |2004/02| 0 |LEOP/CVP|ROS vs. Earth| N/A |ROS vs. Earth|ROS vs. comet| | | | |EROSORER | |EROSORER |EROSATNR | -------------------------------------------------------------------------------- |2005/03| 13 |Earth |ROS vs. Earth| N/A |ROS vs. Earth|ROS vs. comet| | | |Swingby |1 | |EROSORER |EROSATNR | | | |#1 |EROSORER | | | | -------------------------------------------------------------------------------- |2007/02| 36 |Mars |ROS vs. Mars | N/A |ROS vs. Mars |ROS vs. comet| | | |Swingby |EROSORMR | |EROSORMR |EROSATNR | -------------------------------------------------------------------------------- |2007/11| 45 |Earth |ROS vs. Earth| N/A |ROS vs. Earth|ROS vs. comet| | | |Swingby |2 | |2 |EROSATNR | | | |#2 |EROSORFR | |EROSORFR | | -------------------------------------------------------------------------------- |2009/11| 69 |Earth |ROS vs. Earth| N/A |ROS vs. Earth|ROS vs. comet| | | |Swingby |3 | |3 |EROSATNR | | | |#3 |EROSORGR | |EROSORGR | | -------------------------------------------------------------------------------- |2014/05| 123 |RDV with|ROS vs. comet| Comet vs.|ROS vs. comet|ROS vs. comet| | | |67P/C-G | | sun | |EROSATNR | | | | |EROSORWR | EROSORHW |EROSORWR | | -------------------------------------------------------------------------------- Table 4.2. Geometry data to be included in TAB files The routines to be used to generate the geometry data are rofop.f, rofrr.f e rofcl.f (see AD-11). As example, during operation at comet the geometry data are: 1) Relative position: a) Rosetta - Comet (satellite orbit around comet) - ADID = EROSORWR - Routines to be used: rofop.f, rofrr.f e rofcl.f; b) Comet - Sun (heliocentric orbit) - ADID = EROSORHW - Routines: rofop.f, rofrr.f e rofcl.f; 2) Linear and angular velocity Rosetta - comet (from orbit data) - ADID = EROSORWR - Routines: rofop.f, rofrr.f e rofcl.f; 3) Rosetta - comet orientation - ADID = EROSATNR - Routines: rafop.f, rafrr.f e rafcl.f. Refer to AD.11 - Appendix H for meaning and definition of ADID, ADID names and routines. These data shall be added as columns in the tables of scientific data, of calibration data and of HK-SCI and HK, once computed from the geometry data for the times of the events for each subsystem (sub-system event time) of GIADA. Therefore, the geometry parameters reported in the data product label file shall be flagged as "Not Applicable" (N/A). The tables of the conversion factors shall contain the calibration parameters. Each time a new version of the conversion data is created, it shall be necessary to create a new ConvFactors.ini file and, consequently, the PDSC shall create the corresponding LABEL and TABLE files. Although the ConvFacxtors.ini file is in ASCII format, it shall be reformatted according to the standard PDS rules, in terms of character set and row length. 4.3.3 Data Product "Conversion Factors" This data product contains the Engineering Calibration Factors for conversion from ADC counts to Engineering values. 4.3.4 Data Product "GDS" This data product contains the grain detection events by GDS only. 4.3.5 Data Product "GDS CAL" This data product contains the GDS Calibration data acquired in flight. 4.3.6 Data Product "GDS IS" This data product contains the grain detection events by GDS and IS. 4.3.7 Data Product "HK DATA" This data product contains the periodic in flight acquisition of HK data. 4.3.8 Data Product "HK SCI" This data product contains the in flight acquisition of HK data connected in time to science event detection. 4.3.9 Data Product "IS" This data product contains the grain detection events by IS only. 4.3.10 Data Product "IS CAL" This data product contains the IS Calibration data acquired in flight. 4.3.11 Data Product "MB HEAT" This data product contains the acquisition of data on MBS during in flight heating. 4.3.12 Data Product "MBS" This data product contains the periodic in flight acquisition of data on MBSs. 4.3.13 Data Product "MBS CAL" This data product contains the MBS Calibration data acquired in flight. 5 Appendix 1: Available Software to read PDS files The software that can be used to read PDS files is NASAView. NASAView is a PDS archive product display program that runs on Windows 95/98/NT/2000, SOLARIS 2.6, LINUX, and Power Mac. This application was built using the Label Library Light (L3), Object Access Library (OAL) and the XVT Development Solution for C package. Label Library Light parses PDS ODL labels and creates an in-memory representation of the label information. 6 Appendix 2: Extract from GIADA User Manual with more detailed instrument description