ROSETTA-NAVCAM to Planetary Science Archive Interface Control Document Prepared By: Colin Archibald Maud Barthelemy Approved By: David Heather -------------------------------------------------------- Table 1: Distribution List. ------------------------------------------------------ |Recipient |Organisation |Contact | ------------------------------------------------------ |Rosetta |ESA/ESAC |rsgs_dev@sciops.esa.int | |SGS | | | ------------------------------------------------------ Table 2: Document Change Log. ----------------------------------------------------------------- |Date of Update| Update to Document |New Version| Name | ----------------------------------------------------------------- |2010 Oct 20 |Creation of document| V 1.0 |Colin Archibald| ----------------------------------------------------------------- |2012 Jun 26 | Corrections | V 2.0 |Maud Barthelemy| ----------------------------------------------------------------- |2013 Jan 08 |Corrections; | V 3.0 |Bernhard Geiger| | |added Sections 2.5, | | | | |3.2.3, 3.2.4, 3.2.5 | | | ----------------------------------------------------------------- |2013 Aug 30 |Corrections in | V 3.1 |Bernhard Geiger| | |Sect. 2.6.1, 3.1.2 | | | ----------------------------------------------------------------- Contents *=*=*=*= - 1 Introduction - 1.1 Purpose and Scope - 1.2 Archiving Authorities - 1.3 Contents - 1.4 Intended Readership - 1.5 Applicable Documents - 1.6 Reference Documents - 1.7 Contact Names and Addresses - 2 Overview of Instrument Design, Data Handling Process and Product Generation - 2.1 Architectures and Configurations - 2.1.1 CAM-OH - 2.1.2 CAM-EU - 2.1.3 CAM-BAF - 2.2 Objectives and Operating Modes - 2.2.1 OFF Mode - 2.2.2 Initialisation Mode - 2.2.3 Stand-by Mode - 2.2.4 Imaging Mode - 2.2.5 Point Target Tracking Mode - 2.2.6 Asteroid (Extended Source) Tracking Mode - 2.2.7 Self-Test - 2.2.8 Summary of the Operating Modes - 2.3 Software for Camera Control - 2.4 Data Handling Process - 2.5 Telemetry Data - 2.6 Overview of Data Products - 2.6.1 Expected Releases - 3 Archive Format and Conventions - 3.1 Format and Conventions - 3.1.1 Data Set ID Formation - 3.1.2 File Naming Convention - 3.2 Standards Used in Data Product Generation - 3.2.1 PDS Standards - 3.2.2 Time Standards - 3.2.3 Camera Reference Frames - 3.2.4 Image Orientation - 3.2.5 Window Size and Position - 3.3 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 Data Product Design - 4.1.1 Content of *.LBL Files List of Tables *=*=*=*=*=*=*= 1 Distribution List 2 Document Change Log 3 List of contacts for the Navigation Camera (NavCam) instrument archive 4 Overview of NavCam properties 5 Summary of NavCam Operating Modes 6 NavCam operating modes and state transitions 7 Data Processing Levels for the NavCam Data 8 Description of Components of the DATA SET ID. 9 Full list of TARGET ID values for Rosetta 10 MISSION PHASE NAME and ABBREVIATION 11 File naming parameters 12 Data quality level and description 13 Mandatory keywords and standard values for the VOLUME object 14 Data set naming parameters 15 Keywords used in NavCam label files 16 Rosetta mission specific dictionary entries List of Acronyms *=*=*=*=*=*=*=*= A/D Analogue-to-Digital AIU Avionics Interface Unit AOCMS Attitude and Orbit Control Measurement System AOCS Attitude and Orbit Control System APID Application Process Identifier ASIC Application Specific Integrated Circuit BIOS Basic Input/Output System CaDH Command and Data Handling CAM-BAF Camera Baffle CAM-EU Camera Electronic Unit CAM-OH Camera Optical Head CCD Charge Coupled Device CDS Correlated Double Sampling CMOS Complimentary Metal Oxide Semiconductor CODMAC Committee On Data Management, Archiving, and Computation DDS Data Distribution System DMS Data Management System DNA Defocused imaging with No Attenuation DSP Digital Signal Processing EAICD Experimenter to (Science) Archive Interface Control Document ESA European Space Agency ESAC European Space Astronomy Centre ESOC European Space Operations Centre EU Electronic Unit FA Focussed imaging with Attenuation FIFO First In / First Out FNA Focussed imaging with No Attenuation FOV Field of View ftp file transfer protocol GSE Ground Support Equipment HC Health-check HK Housekeeping I/F Interface I/O Input / Output JPEG Joint Photographic Experts Group LED Light Emitting Diode MOS Metal Oxide Semiconductor MSPS Mobilisation Stationing and Planning System NASA National Aeronautics and Space Administration NavCam Navigation Camera OBT On-Board Time OH Optical Head PDS Planetary Data System PSA Planetary Science Archive PSA-DH Planetary Science Archive Data Handler RAM Random Access Memory RH reference hole RL Rosetta Lander RMOC Rosetta Mission Operations Centre RO Rosetta Orbiter ROM Read Only Memory RSSD Research and Scientific Support Department S/C Spacecraft S/W Software SEU Single Event Upset SSMM Solid State Mass Memory STR Autonomous Attitude Star Tracker TBC To Be Confirmed TBD To Be Defined TC Telecommand TM Telemetry TTL Transistor-Transistor Logic UTC Coordinated Universal Time 1 Introduction *=*=*=*=*=*=*=* 1.1 Purpose and Scope ====================== This Experimenter to (Science) Archive Interface Control Document (EAICD) has two main purposes. Firstly, it gives users of the Navigation Camera (NavCam) instrument data a detailed description of the product and how it was generated, including data sources and destinations. Secondly, it acts as an interface between the NavCam data producers and the data archiving authority. One point of note is that there are two identical NavCams installed on the Rosetta Spacecraft (S/C), however, for the purposes of this document the singular is generally referred to when discussing the NavCams. 1.2 Archiving Authorities ========================== The Planetary Data Standards (PDS) standard is used as the archiving standard by: - the National Aeronautics and Space Administration (NASA) for U.S. Planetary Missions, implemented by PDS; - the European Space Agency (ESA) for European Planetary Missions, implemented by the Research and Scientific Support Department (RSSD) of ESA. ESA implements an on-line science archive, the Planetary Science Archive (PSA), for several reasons: - to support and ease data ingestion; - to offer additional services to the scientific user community and science operations teams, such as, e.g.: 1. search queries that allow searches across instruments, missions and scientific disciplines; 2. several data delivery options, such as: - direct download of data products, linked files and data sets; - file transfer protocol (ftp) download of data products, linked files and data sets. The (PSA) aims for on-line 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 NavCam instrument on Rosetta from the Spacecraft (S/C) until the insertion into the PSA by ESA. It includes information on how data were processed, formatted, labelled and uniquely identified; along with discussing the general naming schemes for NavCam data volumes, data sets, data and label files. The standards used to generate such products are explained and the design of the data set structure and data products are also given within this document. 1.4 Intended Readership ======================== The staff of the archiving authority (PSA, ESA, RSSD and operations team) along with any potential user of the NavCam data. 1.5 Applicable Documents ========================= - AD1: Rosetta Archive Generation, Validation and Transfer Plan, January 10, 2006, RO-EST-PL-5011 - AD2: Rosetta Archive Conventions, Mar 25, 2010, RO-EST-TN-3372 1.6 Reference Documents ======================== - RD1: Rosetta Navigation Camera User’s Manual, January 2002, RO-GAL-MA-2008 - RD2: Rosetta Navigation Camera Design Description, January 2002, RO-GAL-RP-2007 - RD3: Navigation Camera TM/TC and Software ICD, November 2001, RO-MMTIF-2007 - RD4: Rosetta SPICE Frame Kernel, ROS V18.TF 1.7 Contact Names and Addresses ================================ -------------------------------------------------------- Table 3: List of Contacts for the NavCam Instrument. --------------------------------------------------------------------- |Address |Name | Specifics | --------------------------------------------------------------------- |SRE-OO, |David Heather | Tel.: | |ESAC, P.O. Box, 78, | | +34 91 81 31 183 | |Villanueva de la Canada,| | E-Mail: | |28691, Madrid, Spain. | | dheather@sciops.esa.int | --------------------------------------------------------------------- |SRE-OD, |Maud Barthelemy| Tel.: | |ESAC, P.O. Box, 78, | | +34 91 81 31 248 | |Villanueva de la Canada,| | E-Mail: | |28691, Madrid, Spain. | |mbarthelemy@sciops.esa.int| --------------------------------------------------------------------- |SRE-OD, |Bernhard Geiger| Tel.: | |ESAC, P.O. Box, 78, | | +34 91 81 31 169 | |Villanueva de la Canada,| | E-Mail: | |28691, Madrid, Spain. | | Bernhard.Geiger@esa.int | --------------------------------------------------------------------- |SRE-OD, |Michael Kuppers| Tel.: | |ESAC, P.O. Box, 78, | | +34 91 81 31 149 | |Villanueva de la Canada,| | E-Mail: | |28691, Madrid, Spain. | | Michael.Kueppers@esa.int | --------------------------------------------------------------------- -------------------------------------------------------- 2 Overview of Instrument Design, Data Handling Process and Product *=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=* Generation *=*=*=*=*= In order to fully satisfy the requirements and objectives regarding navigation and attitude control, Galileo Avionica developed a mission-specific Navigation Camera for Rosetta by building on the heritage of existing models. Table 4 provides an overview of some of the physical and operational parameters of the NavCam. -------------------------------------------------------- Table 4: Overview of NavCam properties. --------------------------------------------------------------------- |Parameter |Value | Comment | --------------------------------------------------------------------- | Mass CAM-OH | 6.050 kg | | --------------------------------------------------------------------- | Mass CAM-EU | 2.700 kg | | --------------------------------------------------------------------- | Mass CAM-BAF | 1.408 kg | | --------------------------------------------------------------------- | Total Mass | 10.158 kg | | --------------------------------------------------------------------- | Total Power | 16.8 W | | --------------------------------------------------------------------- | Field Of View | 5x5 deg | | ---------------------------------------------------------------------- | Sensor Type | CCD | | --------------------------------------------------------------------- | Number of Pixels | 1024 × 1024 | | -------------------------------------------------------------------- | Focal Length | 152.5 mm | | -------------------------------------------------------------------- | Pixel Size | 13 um | | -------------------------------------------------------------------- | Pixel Angular Size | 17 arcsec | | -------------------------------------------------------------------- | Aperture | 70 mm | Non-Attenuated Modes | | | 30 mm | Attenuated Mode | -------------------------------------------------------------------- | F/Number | f/2.2 | Non-Attenuated Modes | | | f/5.1 | Attenuated Mode | -------------------------------------------------------------------- | Limit Magnitude | Mv = 11 | Exposure time 5 s | | | | SNR >= 5 | -------------------------------------------------------------------- | Saturation Magnitude | Mv = 1.6 | Whole spectral range | | | Mv = 0.8 | G2 Class; | | | | exposure time = 10ms | -------------------------------------------------------------------- | Integration time | 10 ms | Minimum | | | 30 s | Maximum | -------------------------------------------------------------------- |Bias error (1 sigma) | 0.2 pixels | Mv = 11, exposure time = | | | | 5 s, Defocused mode | -------------------------------------------------------------------- | NEA (1 sigma) | 0.1 pixels | Mv = 11, exposure time = | | | | 5 s, Defocused mode | -------------------------------------------------------------------- | Commanded window size | 20 × 20 | Minimum pixel array | | | 1024 × 1024 | Maximum pixel array | -------------------------------------------------------------------- | CCD Operative temp. | -50 deg | Minimum | | Range | +50 deg | Maximum | -------------------------------------------------------------------- | CCD Performance Temp. | -25 deg | Minimum | | Range | 0 deg | Maximum | -------------------------------------------------------------------- -------------------------------------------------------- 2.1 Architectures and Configurations ===================================== The NavCam comprises of a Camera Optical Head (CAM-OH), a Camera Electronics Unit (CAM-EU) and a Camera Baffle (CAM-BAF). 2.1.1 CAM-OH ------------- The CAM-OH for the Rosetta NavCam consists of a Charge Coupled Device (CCD) detector and a set of electronics, including: - PROXIMITY ELECTRONICS: 1. CCD drivers; 2. CCD bias and phase voltage regulators; 3. the analogue signal processor: - the pre-amplifier; - the amplifier with variable gain; and, - the Correlated Double Sampling (CDS) amplifying circuit. 4. two multiplexers; 5. the Analogue-to-Digital (A/D) converter; and, 6. the interfaces for: - the temperature transducers; and, - the Light Emiting Diodes (LEDs) and photodiodes for the cover / attenuation mechanism control. - TIMING SEQUENCER and CONTROL LOGIC: 1. CCD sequencer and analogue channel control; and, 2. data interface. - DIGITAL SIGNALS and POWER INTERFACES: 1. digital lines Interface (I/F); 2. command I/F; and, 3. data I/F. All the logic operations that need to be carried out by the optical head are commanded via the Application Specific Integrated Circuit (ASIC); these include the CCD timing control and digital data and the commanded interfaces of the Optical Head (OH) with the Electronics Unit (EU). The CAM-OH supports the attenuation / cover mechanism in front of the optics. This includes three exchangeable optical elements in order to make possible the following functions - the second line of each provides the reader with the Rosetta mission specific keyword for ROSETTA:CAM COVER POSITION (Summarised in Table 16):: - Defocused imaging with No Attenuation (DNA) Specific keyword value DEFOC_NATT; - Focused imaging with Attenuation (FA); Specific keyword value FOC_ATT; and, - Focused imaging with No Attenuation (FNA) Specific keyword value FOC_NATT. All three positions of the mechanism provide protection to the internal section of the NavCam from debris in the space environment. Configuration The CCD enables the NavCam to image objects in the camera Field of View (FOV) and perform the image readout out line-by-line. As the first line of pixels are interrogated and read into the EU each following line is moved pixel-by-pixel to occupy the space of the first line, thus, freeing the row of pixels at the opposing end. By operating in such a manner the NavCam can begin the next image before the first one has completed the read-out process and, hence, reduce the image lag. This can be particularly useful when having to perform a sequence of quickly resolved images, e.g. during navigation for the Rosetta Lander (RL) descent. The CCD drivers translate Transistor-Transistor Logic (TTL) signals, produced via the timing sequencer, to the Metal Oxide Semiconductor (MOS) levels, required by the CCD, to operate correctly over the correct time-scale and drive the relatively high capacitive load presented. Charge-shifting rates of 2 musec are used for the vertical (parallel) transfers, while 250 nsec and 3.6 musec rates are used for the non-processed and A/D converted pixels in the horizontal (serial) transfers respectively. The CCD bias and phase voltage regulators supply the voltage levels to bias the CCD and the levels to which the timing signals must be translated. The analogue signal processor uses two gain levels and again the second line gives the values for the Rosetta mission specific keyword related to this parameter ROSETTA:CAM_GAIN (Table 16): 1. G_high - increases the grey signal level resolution when faint targets are imaged Specific keyword value HIGH; and, 2. G_low - used when bright targets are imaged Specific keyword value LOW. The two multiplexers (8-channel Complimentary Metal Oxide Semiconductor (CMOS) HS-508A chips) are used to acquire the CCD data and all the needed Helth-check (HC) signals. The CCD sequencer block of the OH ASIC selects, with a given sequence, the various channels to perform the readout of a given signal. The readout of all HC signals is performed before the readout of the CCD data. The A/D converter is a high speed monolithic 12-bit, 1.25 Mobilisation Stationing and Planning System (MSPS), with an on-chip sample-and-hold amplifier. The CCD sequencer and analogue channel control block produces CCD timings and (simultaneously) drives a First In / First Out (FIFO) control system for pixel storage and direct interfacing with all processor buses. It is this block that constructs the signals for the following operations: - CCD clocking; and, - analogue channel control: - clamp; - sample; - gain switch; and, - A/D conversion. The sequencer opens CCD windows, selects the window gain, and, commands the CCD operations and pixel grouping. Within the OH electronics a separate sub-block is incorporated to, solely, deal with HC signal acquisition and conversion from different sources. The sequencer can be completely re-configured by means of an external Read Only Memory (ROM); designed to store all waveforms that drive the CCD and analogue signal controls. Re-loading the external ROM and running a complete waveform sequence via the ASIC occurs at every CCD scan cycle; by doing so the possibility of a Single Event Upset (SEU) is minimized. The logic is completely synchronous and uses a single port for waveform storage in the form of a static Random Access Memory (RAM) chip with a total size of 16 Kbits. The data interface is a small FIFO based serial link, for command outputting and pixel data inputting, general purpose bus interfacing consisting of two sub-blocks: - Command I/F; and, - Pixel input I/F. The command I/F serialises a command stream (written in a small FIFO 32 by 32 processor) and sends it to the CCD sequencer. The pixel input I/F will accept the serial stream originating from the CCD sequencer and write the data in a large FIFO (1 Kb by 24 word) location, ready for reading by a microprocessor. 2.1.2 CAM-EU ------------- The CAM-EU contains: all of the digital electronics, interfaces for data I/O with the Avionics Interface Unit (AIU) and Solid State Mass Memory (SSMM), and finally, the DC/DC power converter. The ASIC used in the OH for CCD timing is designed to implement, by a dedicated section, the interfaces from the EU in the direction of the OH. Therefore, two identical ASICs are utilised in the NavCam system; one in the OH and one in the EU; to provide interfacing in both directions. The EU sends the control commands required by the OH and processes the digital signals coming from the OH to realise the target detection and tracking capabilities. In general the EU provides overall control of the instrument and comprises of three main blocks, including two Digital Signal Processing (DSP) boards: - the DSP board with NavCam processor and related interfaces; - the DSP board with Autonomous Star Tracker (STR) processor and related interfaces; and, - the power section. Configuration The common DC/DC converter module provides functioning for: conditioning, switching, conversion and distribution of the power supply from the EU and CAM-OH. It provides a common functionality that implements primary power conditioning functions and separate DC/DC conversions for both the NavCam and STR modules, including both DSPs. Another major function of this module is to provide the programmable constant-current driver for, both, the heater in the OH and the stepper motor that actuates the NavCam attenuation / cover mechanism. The NavCam DSP board controls the processing of the data from the NavCam and incorporates the following modules: - the DSP itself; - the memory banks; - the DSP peripherals; - the interfacing between the AIU, SSMM and the OH; and, - the instrument control function, including: - the thermal control for the OH; and, - the cover / attenuation mechanism position controls. 2.1.3 CAM-BAF -------------- The CAM-BAF provides protection against stray light produced by the sun and reflected from the planetary bodies and the satellite. This level of protection allows the tracking of faint objects. Configuration The CAM-BAF is mechanically supported by the S/C structure so as to avoid mechanical stress of the OH. This is done due to the required high pointing stability of the CAM-OH to its boresight in order to achieve the desired accuracies from the NavCam. 2.2 Objectives and Operating Modes =================================== The Rosetta NavCam does not have any scientific objectives, as such, to speak of. Instead, the aims of this instrument are to provide the Rosetta S/C with several capabilities through a series of operating modes. In general the camera has three major functions: 1. Point Tracking; 2. Asteroid (or Extended Object) Tracking; and, 3. Imaging and, more precisely, seven operational modes: - OFF Mode; - Initialisation; - Stand-by; - Imaging; INSTRUMENT_MODE_ID = "IMAGING" - Point-Target Tracking; - Asteroid (Extended Object) Tracking; and, INSTRUMENT_MODE_ID = "ASTEROID_TRACKING" - Self Test. Science data (i.e., images) can only be generated and downlinked to ground in the Imaging and Asteroid (Extended Object) Tracking modes. In the archived data sets, the used mode is indicated by the INSTRUMENT MODE ID keyword of the label files as indicated above (also see Table 15). The following sections give a description of each of the operational modes and the multiple abilities they provide. 2.2.1 OFF Mode --------------- In this mode the camera is dormant and devoid of all power. 2.2.2 Initialisation Mode -------------------------- In this mode the NavCam autonomously loads and runs the bootstrap into a devoted section of the RAM at switch-on, activates the interfaces and awaits a Telecommand (TC) from the AIU. The content of all RAM is left unchanged - except that of the RAM location devoted to the initialisation and Software (S/W) maintenance modes - so that it may be fully tested following a specific TC being sent from the AIU. Finally, the switch to stand-by mode (start application S/W) is commanded by the AIU. 2.2.3 Stand-by Mode -------------------- In this mode the instrument achieves and maintains the nominal operating conditions, e.g. the CCD operating temperature, in order to rapidly react to the Attitude and Orbit Control Measurement System (AOCMS) commands. While operating in stand-by mode the power consumption is minimised and S/W services can be commanded quickly and easily. 2.2.4 Imaging Mode ------------------- Allows the camera to operate as a standard camera, targeting and resolving images of: the star-field in the camera FOV, extended sources such as asteroids, comets or planets in the camera FOV, or, features of the comet 67P/Churyumov-Gerasimenko during the orbits and finally the descent of the RL. This mode can be operated independently or as a sub-mode of the Asteroid (Extended Object) Tracking mode. 2.2.5 Point Target Tracking Mode --------------------------------- The Point Target Tracking mode has several applications when addressing the Rosetta NavCam objectives: - Autonomous Acquisition of a Star-Field This will allow the NavCam to, firstly, recognise and then lock a star-field and is accomplished by the collection and processing of images in the entire FOV without priori knowledge being gained from the use of other sensors. By operating in this way the NavCam / STR can perform the coarse attitude determination and evaluate manoeuvres that may need to be performed to ensure the correct pointing of the satellite is maintained. Following from this operation is the method of Autonomous Star-Tracking. - Autonomous Tracking of Stars Autonomous Star-Tracking allows the NavCam to collect images of stars locked in the FOV (or from new stars entering the FOV) and evaluate fine attitude control manoeuvres (pitch, roll and yaw) that may need to be performed. - Commanded Star-Tracking Upon being provided with the coordinates, motion rate and magnitude of (up to) five selected stars, the NavCam can autonomously track these within the camera's FOV. - Provide the AIU with Position and Magnitude measurements The NavCam shall also be able to provide the AIU with the position and magnitude measurements of the ten brightest objects within the camera FOV. This mode can be used to provide information along with the images of deep-space; so as to allow a comparison against a catalogue of stars for determination of position and pointing direction of the Rosetta S/C. 2.2.6 Asteroid (Extended Source) Tracking Mode ----------------------------------------------- The objectives to be satisfied here are essentially the same as for the autonomous star-field acquisition and tracking modes: - Autonomous Acquisition of Extended Sources This will allow the NavCam to, firstly, recognise and then lock an extended source and is accomplished by the collection and processing of images in the entire FOV without priori knowledge being gained from the use of other sensors. By operating in this way the NavCam / STR can perform the coarse attitude determination and evaluate manoeuvres that may need to be performed to ensure the correct pointing of the satellite is maintained. Following from this operation is the method of Autonomous Extended Source Tracking. - Autonomous Tracking of Extended Sources Autonomous Extended Source Tracking allows the NavCam to collect images of asteroids, comets or planets locked in the FOV and evaluate fine attitude control manoeuvres (pitch, roll and yaw) that may need to be performed. The secondary outcome of this operational mode allows the instrument to evaluate rates of motion with a specified repetition rate. 2.2.7 Self-Test ---------------- This mode operates by providing, upon request, the health-check Housekeeping (HK)-Telemetry (TM) without destroying the contents of any memory locations. 2.2.8 Summary of the Operating Modes ------------------------------------- Table 5 demonstrates a summary of each of the operating modes and provides a brief description of the scope for each. -------------------------------------------------------- Table 5: Summary of NavCam Operating Modes. ----------------------------------------------------- |Mode |Description | ----------------------------------------------------- |OFF Mode |The NavCam is completely off and | | |devoid of power. | ----------------------------------------------------- |Initialisation |Switch-on of NavCam. | ----------------------------------------------------- |Stand-by |Minimise power consumption and | | |prepare for S/W commanding. | ----------------------------------------------------- |Imaging |Produces and transmits a solid | | |image. | ----------------------------------------------------- |Point Target |To recognise, lock and | |Tracking Mode |autonomously track a (point like)| | |star-field providing coarse and | | |fine attitude corrections to the | | |AOCMS respectively. Provide | | |position and magnitude | | |measurements to the AIU. Track up| | | to five stars within the FOV of | | |given coordinates. | ----------------------------------------------------- |Asteroid |To recognise, lock and | |(Extended Object)|autonomously track an extended | |Tracking Mode |object, providing both coarse and| | |fine attitude corrections to the | | |AOCMS. Provide position and | | |magnitude measurements to the AIU| | |along with observed rates of | | |motion with a specified | | |repetition rate. | | | | ----------------------------------------------------- |Self-test |Provide the HK-TM upon request. | |(Troubleshooting)| | ----------------------------------------------------- -------------------------------------------------------- 2.3 Software for Camera Control ================================ The camera software makes it possible to either command the NavCam from the ground or autonomously control it on board the S/C. These commands are first routed by the Data Management System (DMS) TC router then by the Attitude and Orbit Control System (AOCS) TC router to the NavCam based on the Application Process Identifier (APID) value. The on-board instrument S/W consists of the following: 1. Application Management S/W: - Initialisation S/W; and, - Application S/W. 2. Basic Input Output/System (BIOS) and Auxiliary Functions: - Power-on and initialisation function (Start-up); - device drivers (library); - EU self-test functions (library); - EU overall self-test program (library/function); and, - S/W services (library). In addition to this autonomously commanded S/W there is also a full set of TCs that can be executed by the AOCS. The initialisation S/W is used immediately after power-on (from OFF mode) and is only used during the initialisation mode. While the application S/W can be used in stand-by mode to access another mode state as well as being operated, in some instances, to transfer from one mode state to the next (if applicable), this is summarised in Table 6. Both the initialisation and application S/W can execute the following operations: - S/W program control; - Communication handling; - S/W maintenance; and, - Board handling. While the initialisation S/W can also perform the default readout sequence and the application S/W performs the specific tasks of: - Housekeeping (HK) (including: thermal control, HC and memory scrubbing); - On-Board Time (OBT) and OH handling. -------------------------------------------------------- Table 6: NavCam operating modes and state transitions ---------------------------------------------------------- |Mode |Event and Transition|Event and Transition| | |From |To | ---------------------------------------------------------- |OFF |<-All Operative |->Initialisation: | | |Modes: | | | |OFF command |ON command from RTU | ---------------------------------------------------------- |Initialisation|<-OFF: |->Initialisation: | | |ON command from RTU |after bootstrap | | | |completion | | | |after RAM check | | | |completion | | | |after S/W loading to| | | |RAM | | |<-All Operative |->Stand-by: | | |Modes: | | | |S/W reset TC |start application | | | |S/W TC | ---------------------------------------------------------- |Stand-by |<-Initialisation: | | | |start application | | | |S/W TC | | | |<-Imaging: |->Imaging: | | |Stand-by entering |Image entering | | |command |command | | |<-Point Target |->Point Target | | |Tracking: |Tracking: | | |stand-by entering |Point target | | |command |tracking entering | | |all targets lost |command | | |<-Asteroid Tracking:|->Asteroid Tracking:| | |Stand-by entering |Asteroid tracking | | |command |entering command | | |<-Self-Test: |->Self-Test: | | |Test completion |Self-test entering | | | |command | ---------------------------------------------------------- |Imaging |<-Stand-by: |->Stand-by: | | |Imaging entering |Stand-by entering | | |command |command | | |<-Imaging: |->Imaging: | | |Imaging entering |Imaging entering | | |command |command | ---------------------------------------------------------- |Point Target |<-Stand-by: |->Stand-by: | |Tracking |Point target |Stand-by entering | | |tracking entering/ |command | | |updating command |All targets lost | | |<-Point Target |->Point Target | | |Tracking: |Tracking: | | |Point target |Point target | | |tracking entering/ |tracking entering/ | | |updating command |updating command | ---------------------------------------------------------- |Asteroid |<-Stand-by: |->Stand-by: | |Tracking |Asteroid tracking |Stand-by entering | | |entering/ |command | | |updating command | | | |<-Asteroid Tracking:|->Asteroid Tracking:| | |Asteroid tracking |Asteroid tracking | | |entering/ |entering/ | | |updating command |updating command | ---------------------------------------------------------- |Self-Test |<-Stand-by: |->Stand-by: | | |Self-test entering |Self-test completion| | |command | | ---------------------------------------------------------- -------------------------------------------------------- 2.4 Data Handling Process ========================== The NavCam data will be primarily used by the Rosetta Mission Operations Centre (RMOC) team at European Space Operations Centre (ESOC), Germany, where the datawill be used to help ensure the S/C’s position, pointing and attitude are correct. However, to offer data to the scientific community, products produced under the imaging mode have been collated into relevant data sets. The data products are prepared by Bernhard Geiger and Michael K¨uppers at the European Space Astronomy Centre (ESAC), Spain. The production of the documentation to accompany and explain these products is carried out by the PSA at ESAC. The data levels (according to both PSA and Committee On Data Management, Archiving, and Computation (CODMAC) definition) considered in this documentation are described in Table 7. -------------------------------------------------------- Table 7: Data Processing Levels for the NavCam Data. ----------------------------------------------------- |PSA |CODMAC |Description | ----------------------------------------------------- |1a |1 |The level 1 data that have been| | | |separated by instrument. This | | | |is the level which is | | | |distributed by the DDS. | ----------------------------------------------------- |1b |2 |Level 1a data that have been | | | |sorted by instrument data types| | | |and instrument modes. Data are | | | |in scientifically useful form, | | | |e.g. as images. These data are | | | |still uncalibrated. | ----------------------------------------------------- |2 |3 |Level 1b with calibration and | | | |corrections applied to yield | | | |data in scientific units. | ----------------------------------------------------- |3 |5 |Higher level data products | | | |developed for specific | | | |scientific investigations. | ----------------------------------------------------- -------------------------------------------------------- 2.5 Telemetry Data ==================== For generating the product files the following telemetry data are processed: -Science Data Report: TM APID 460 (CAM1) and 476 (CAM2), Type 20, Subtype 13. This set of telemetry data contains the images as well as a number of meta data parameters. The latter are included in the label files of the generated data products. - Housekeeping and Health-Check Report: TM APID 452 (CAM1) and 468 (CAM2), Type 3, Subtype 25. From the set of available housekeeping parameters only the CCD temperature and the optics temperature are extracted and included in the label files of the generated data products. 2.5 Overview of Data Products ============================== 2.5.1 Expected Releases ------------------------ Due to the inherent nature of the NavCam instrument there will be no reason to produce any CODMAC level 5 data sets and only levels 2 and 3 (see Table 7) will become available for release. The scientific community should expect to have made available to them data products from the Imaging Mode - including images produced while operating under the Asteroid (Extended Object) Tracking mode. These images will include some basic header information. Each released volume will follow the format and structure outlined in Chapter 3. Full explanations of the parameters found in the label files and headers, along with an explanation of the camera readout frame, are provided in Chapter 4. Uncalibrated Data Raw data sets are made available, which contain meta-information on the used instrument modes and geometry in the product label files of the images. The data result from multiple mission phases (see Table 10) and include images of star-fields and extended objects: Earth, Mars, Asteroid 21-Lutetia, Asteroid 2867-Steins and Comet 67P/Churyumov-Gerasimenko. Calibrated Data (Not Yet Available) From the raw data sets the calibration software will allow for necessary adjustments to be made to the images for the production of the CODMAC level 3 data via an automatic calibration pipeline. The data sets expected for release will be calibrated versions of all the data releases for the raw data sets. 3 Format and Conventions *=*=*=*=*=*=*=*=*=*=*=*=* This chapter contains general rules for the NavCam data sets. The format and convention used for naming directories and files are specified below. 3.1 Format and Conventions =========================== The directory tree must be compatible, in terms of directory organisation and naming and file organisation, with the PDS standards and such that: - each logical archive volume shall contain one NavCam PDS data set; - data sets will contain data from both NavCams; - one data set shall be created for each separate mission phase and one for each of the n-orbits during the cometary phase; - a different data set shall be created for each processing level; - the top level directory of each logical archive volume shall match that of the NavCam data set ID; and, - the volume set name shall be as that of the data set. 3.1.1 Data Set ID Formation ---------------------------- The data set ID formation shall be done according to the following rule: DATA_SET_ID = ----- Each of the components are described, briefly, in Table 8, with a full list of options for TARGET_ID and MISSION_PHASE being given in Tables 9 and 10 respectively: -------------------------------------------------------- Table 8: Description of Components of the DATA_SET_ID. ---------------------------------------------------- |Component |Examples |Description | ---------------------------------------------------- |INST_HOST |RO |Rosetta Orbiter | ---------------------------------------------------- |TARGET_ID |A, C, E, M |Asteroid, Comet, Earth,| | | |Mars | ---------------------------------------------------- |INST |NAVCAM |Navigation Camera | ---------------------------------------------------- |CODMAC_LEVEL |2, 3, 5 |See Table 7 | ---------------------------------------------------- |MISSION_PHASE_|AST1, EAR3,|Asteroid 1 Flyby, Earth| |ABBREVIATION |CR4B, MARS |Swingby 3, Cruise 4-B, | | |etc... |Mars Swingby, etc... | ---------------------------------------------------- |VERSION |Vx.y e.g. |x and y are numerical | | |V1.0, V1.1,|values indicating the | | |V2.0 |version level and | | | |revision number | ---------------------------------------------------- -------------------------------------------------------- Examples include: - RO-E-NAVCAM-2-EAR1-V1.0 - RO-A-NAVCAM-2-AST1-V1.0 In some instances it can be viewed that there are several TARGET ID terms in the DATA SET ID naming formation. These terms come together in a list, separated by hyphens, between the and terms in the data set name. Examples include: - RO-A-CAL-NAVCAM-2-AST2-V1.0 - RO-E-X-NAVCAM-2-CR1-V1.0 -------------------------------------------------------- Table 9: Full list of TARGET_ID values for Rosetta. ---------------------------------------------------- |Abbreviation|TARGET_TYPE| TARGET_NAME | ---------------------------------------------------- | A | Asteroid | (21) Lutetia | | | | (2867) Steins | ---------------------------------------------------- | C | Comet | C/LINEAR | | | | 9P/TEMPEL 1 | | | |67P/Churyumov-Gerasimenko| ---------------------------------------------------- | CAL |Calibration| | ---------------------------------------------------- | E | Planet | Earth | ---------------------------------------------------- | J | Planet | Jupiter | ---------------------------------------------------- | M | Planet | Mars | ---------------------------------------------------- | N/A | Satellite | Moon | ---------------------------------------------------- | X | N/A | Checkout | ---------------------------------------------------- -------------------------------------------------------- -------------------------------------------------------- Table 10: MISSION_PHASE_NAME and ABBREVIATION. ---------------------------------------------------- |Phase Name |Abbr. ||Phase Name |Abbr. | ---------------------------------------------------- |STEINS FLY-BY |AST1 ||COMMISSIONING 2 |CVP2 | ---------------------------------------------------- |LUTETIA FLY-BY |AST2 ||EARTH SWING-BY 1 |EAR1 | ---------------------------------------------------- |CRUISE 1 |CR1 ||EARTH SWING-BY 2 |EAR2 | ---------------------------------------------------- |CRUISE 2 |CR2 ||EARTH SWING-BY 3 |EAR3 | ---------------------------------------------------- |CRUISE 3 |CR3 ||GROUND |GRND | ---------------------------------------------------- |CRUISE 4-1 |CR4A ||LAUNCH |LEOP | ---------------------------------------------------- |CRUISE 4-2 |CR4B ||MARS SWING-BY |MARS | ---------------------------------------------------- |CRUISE 5 |CR5 ||RENDEZVOUS |RVM1 | | | ||MANOEUVRE 1 | | ---------------------------------------------------- |CRUISE 6 |CR6 ||RENDEZVOUS |RVM2 | | | ||MANOEUVRE 2 | | ---------------------------------------------------- |COMMISSIONING 1 |CVP1 || | | ---------------------------------------------------- -------------------------------------------------------- 3.1.2 File Naming Convention ----------------------------- Each data product found in the /DATA/ directory is presented in the form of a *.IMG file, each of which has an associated *.LBL file of the same name that points to the image file. Each *.LBL file contains the camera operating parameters in the header. Every data product has a browse version in the form of a *.JPG file with an associated *.LBL located in the /BROWSE/ directory. These are provided so as to allow an easier browsing of the data. The naming formation for each *.IMG, *.JPG and *.LBL is as follows: __. Table 11 demonstrates the definitions of each part: -------------------------------------------------------- Table 11: File naming parameters. -------------------------------------- |Variable |Possible |Description | | |Values | | -------------------------------------- |MISSION |ROS |Demonstrates | | | |which mission | | | |the NavCam is | | | |being flown | | | |on. | -------------------------------------- |CAM# |CAM1, CAM2 |Denotes which | | | |NavCam | | | |produced the | | | |data. | -------------------------------------- |EXT |IMG, JPG, |Denotes the | | |LBL |file type in | | | |question. | -------------------------------------- -------------------------------------------------------- The parameter is the Coordinated Universal Time (UTC) without the fractional seconds (explained in Standards Used in Data Product Generation: Time Standards) and provides the date and time at which the image was taken on-board the S/C. 3.2 Standards Used in Data Product Generation ============================================== This section describes the fundamental standards used for the Rosetta NavCam data production. 3.2.1 PDS Standards -------------------- Each complete volume produced will be able to pass both the PDS and PSA standards. In general each individual file will be created using standards of the PDS and more specifically Version 3. The PDS format uses the ISO 9660 level 2 standard for the file names. Hence, no complete file name shall be longer than 31 characters and the "27.3" structure will be obeyed, that is, a maximum of 27 characters before the "." for the file name and 3 characters after for the extension type. 3.2.2 Time Standards --------------------- Two time standards are used in the production of the NavCam data. Firstly, the standard UTC is used in the time stamping of the data products for the following properties: - PRODUCT_CREATION_TIME; - IMAGE_TIME; - START_TIME; and, - STOP_TIME Where the START TIME = IMAGE TIME - 0.5 ×EXPOSURE DURATION and STOP TIME = IMAGE TIME + 0.5×EXPOSURE TIME. The other time standard is found in the following keywords: - SPACECRAFT_CLOCK_START_COUNT; and, - SPACECRAFT_CLOCK_STOP_COUNT. Where these time standards are defined to be: - Coordinated Universal Time (UTC): - YYYYMMDDThhmmss.fff where YYYYMMDD provides the calendar format (year, month and day) of production; T indicates the time at which the event occurred in hhmmss.fff (hours, minutes, seconds and fractions of a second). - SPACECRAFT_CLOCK_START/STOP_COUNT: - /