Laboratory for Atmospheric and Space Physics (LASP)
University of Colorado at Boulder
CASSINI UVIS
DATA ARCHIVING
AND
PROCESSING SYSTEM
REQUIREMENTS
Version #1 11/98
Table Of Contents
0
Introduction......................................................................................................1
1
1.1
1.2
1.3
Input Requirements.........................................................................................2
Procurement Data...............................................................................................2
Input File Formats.............................................................................................3
Data Ingest.........................................................................................................4
2
2.1
2.2
2.3
2.4
2.5
2.6
Archive Requirements.....................................................................................4
Archive Domain.................................................................................................4
Archive Consistency..........................................................................................5
Archive Completeness.......................................................................................6
Archive Correctness...........................................................................................6
Error Recovery...................................................................................................6
Archive Reporting..............................................................................................7
3
3.1
3.2
3.3
Data Access Requirements .............................................................................7
Query Capability...............................................................................................7
Data Products.....................................................................................................8
Browse Products................................................................................................9
4
4.1
4.2
4.3
4.4
4.5
Processing Requirements .............................................................................10
System Distributivity......................................................................................10
Support for Distributed Processing.................................................................10
Extensibility.....................................................................................................10
Revisibility.......................................................................................................11
Compatibility...................................................................................................11
5
5.1
Derived Ingest Requirements.......................................................................11
Ingest Log.........................................................................................................11
6
6.1
6.2
Derived Archive Requirements....................................................................12
Relational Database Requirements...................................................................12
Error Recovery Requirements..........................................................................12
7
7.1
7.2
Derived Management Requirements ..........................................................13
Revision Control..............................................................................................13
Inventory Control............................................................................................13
8
External and Operational Requirements ...................................................13
9
Referenced Documents .................................................................................14
UVIS Data Archiving and Processing System Requirements, Version 1
0 INTRODUCTION
0.1 Purpose
This document enumerates the essential characteristics of the Data Archiving and
Processing System (DAPS). These are high level requirements. The author has made an
effort to define concepts as precisely as possible; nevertheless, these definitions rely on
general knowledge when necessary in order to provide concision.
The requirements listed below fall into three categories: original, derived, and external.
Original requirements are abstract features of the system; derived requirements apply to
elements of the system that are chosen to implement those abstractions. The original
requirements listed in this document bear a resemblance to well-defined theoretical
characteristics of databases and software systems and reveal how the DAPS manifests these
characteristics. Derived requirements are traceable to original requirements and describe the
DAPS specific mechanisms for addressing the original requirements. External requirements
are those which must be satisfied by an entity outside the DAPS in order for the DAPS to
operate properly. Because of the difficulty in coordinating external requirements, those listed
here are levied exclusively on DAPS operations personnel and other UVIS elements.
Requirements have been introduced to address the needs of the science analysis and the
software development processes. Some readers may find requirements obscure, depending on
their experience and perspective. The inclusion of apparently trivial requirements serves the
purpose of providing a reminder of their relevance.
0.2 Scope
The requirements listed here apply to telemetry data taken during bench test, calibration,
ATLO (Assembly, Test and Launch Operations), and during flight. In addition, they apply
to all non-telemetry data required to manage the DAPS system, to all data products level 2
and above, and to all ancillary data contained in the archive.
0.3 Organization of This Document
Requirements are grouped according to the major components of the system and are
enumerated in a top down structure with a decreasing level of abstraction from top to bottom.
Features of the DAPS that are essential to the implementation of requirements (referred to
here as derived requirements) will be presented as a parallel level.
UVIS Data Archiving and Processing System Requirements, Version 1
1
Input
Requirements
Data
Procurement
Sec 1.1
Data
Format
Sec 1.2
Archive
Requirements
Data
Ingest
Sec 1.3
Archive
Domain
Sec 2.1
Archive
Integrity
Sec 2.2-6
Data Access
Requirements
Processing
Requirements
Query Data
Intfc
Browse
Sec 3.1 Products
Sec 3.2-3
Distributivity,
Distributed,
Revisable,
Extensible
Sec 4.1-5
Derived:
Ingest
Logging
Sec 5.1
Archive
Model
Sec 6.1
Error
Recovery
Sec 6.2
Revision
Control
Sec 7.1
Inventory
Control
Sec 7.2
Figure 1. Document Organization
0.4 Key Definitions
Ingest: the process of acquiring spacecraft and instrument data, inserting them into the DAPS
and maintaining them.
L0 data: data representing the configuration and the scientific observations of the UVIS
instrument in the form produced by the instrument; specifically, SFDU wrapped raw data.
L1 data: data derived from L0 during the ingest process; specifically, raw data extracted from
SFDU packets and maintained as a set of database records. L1 data include L1a, which are
data as ingested, and L1b, which are calibrated data.
L2-and-above data: data derived from level 1 by processing algorithms or interpretation.
Link: an set of concurrent instrument configurations and observations.
Metadata: data not taken from the spacecraft or instrument, which are necessary for correct
processing or interpretation of L0 or L1 data.
Processing history: a time series of states that describes the processing or interpretation used
in the production of data.
1
INPUT REQUIREMENTS
1.1
Procurement Data
These requirements are intended to guarantee successful acquisition of data.
1.1.0
Ingest log
Bench data
Calibration data
ATLO data
Flight data
Ancillary data
Processed (L2+) data
L1
Raw Data Ingest
DAPS archive
L2+
Data product ingest
Figure 2. Data Ingest
UVIS Data Archiving and Processing System Requirements, Version 1
2
1.1.1
1.1.1.1
1.1.1.2
1.1.1.3
1.1.1.4
1.1.1.5
1.1.1.6
1.1.1.7
1.1.1.8
1.1.2
1.2
1.2.0
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
The DAPS shall be able to ingest all data required for analysis of science and
instrument health.
The DAPS shall be able to ingest L0 data, including instrument science telemetry
data taken from the FUV, EUV, HSP, and HDAC channels and instrument
engineering (housekeeping) data, and some spacecraft telemetry data. This will
include data taken during bench, calibration, ATLO, and flight. The precise
definitions of these data are contained in references 1 and 2.
The DAPS shall be able to ingest management data, including ingest logs and
inventory data. See sections 5.1 and 7.2 for details on ingest logging and inventory
management.
The DAPS shall be able to ingest ancillary data including spice kernels, spacecraft
events, and spice kernal correlation data, and shall be extensible in order to support
ingest of new or modified ancillary data.
The DAPS shall be able to ingest level 2 and above data products created by the
DAPS and by other external sources. This includes L2 data products, which are yet
to be defined.
Raw data from ATLO and flight shall be transferred from external sources to the
DAPS as electronic files.
Level 2 data shall be transferred from external sources to the DAPS as data product
files (see sections 1.2.5 and 3.2.8), either electronically or via tape media.
The nominal mechanism for transfer of ancillary data to the DAPS shall be via tape
or electronic transfer; however, exceptions will be allowed based on characteristics
of the ancillary data.
Management data shall be a by-product of DAPS management and made available as
part of the management activity; e.g., data ingest produces an ingest log, which is
made available to the DAPS concurrently.
Raw data files delivered in response to a user-generated request shall be placed in
fixed locations for ingest into the DAPS; furthermore, these shall be the only files
that can be placed in these locations.
Input File Formats
These requirements are intended to guarantee that the DAPS can extract raw data
from the source files.
A raw data file containing instrument bench test data shall contain a time ordered
sequence of telemetry packets organized into OASIS-CC record format (ref. 3).
A raw (non-test) data file shall contain a time ordered sequence of SFDUs that
contain 0 or 1 telemetry packets.
Telemetry packets shall be organized in accordance with the specifications set out in
reference 4.
Processed (L2-and-above) data products shall be contained in files with a welldefined format (e.g., as Java serialized object files or annotated binary files).
The DAPS shall be extensible in such a way as to be capable of ingesting ancillary
data with new or modified formats.
UVIS Data Archiving and Processing System Requirements, Version 1
3
1.3
1.3.0
1.3.1
1.3.2
1.3.3
1.3.4
1.3.5
1.3.6
1.3.7
1.3.8
Data Ingest
These requirements are intended to guarantee that data can be transferred from data
files to the DAPS archive.
The DAPS shall automatically begin ingesting data within 15 minutes of the arrival
of files in the holding directory if the following prerequisites are satisfied. This
mode may be disabled under exceptional circumstances (e.g., the arrival of multiple
redundant data files).
The DAPS shall verify the availability of sufficient disk memory resources prior to
ingest.
Ingest shall be delayed until immediately after the completion of ongoing ingest
processes.
Ingest shall continue to completion even if error conditions are detected during
execution.
Ingest shall produce a log that will represent all ingest activities (see section 5.1).
Ingest of ingest logs shall be done automatically on completion of the ingest process.
Ingest of processed (L2-and-above) data shall be an automated process using
methods defined on the DAPS archive and the data product inventory component of
the DAPS. These methods will be defined as such products are specified.
The nominal mechanism of ingest for ancillary data shall be an automated procedure;
however, exceptions will be allowed based on the characteristics of some data.
2
ARCHIVE REQUIREMENTS
2.1
Archive Domain
These requirements are intended to guarantee that the archive will contain all
necessary data:
2.1.0
FUV Instrument Configuration for Obs=x
FUV Data for Obs=x
EUV Instrument Configuration for Obs=x
EUV Data for Obs=x
HSP Instrument Configuration for Obs=x
HSP Data for Obs=x
HDAC Instrument Configuration for Obs=x
HDAC Data for Obs=x
Housekeeping data at time t
Observation Links
Spacecraft and Instrument Events Time Line
Ingest Log
Data Product Inventory
Ancillary Data (tbd)
Processed (L2+) Data Products (tbd)
(DAPS and external L2 data)
Figure 3. DAPS Archive Contents
2.1.1
2.1.2
The archive shall be able to contain all science data including FUV, EUV, HDAC,
HSP, and housekeeping and microprocessor telemetry as defined in references 1
and 2. When available, this data shall be stored in the latest L1b form.
The archive shall not contain original source packet data.
UVIS Data Archiving and Processing System Requirements, Version 1
4
2.1.3
2.1.3.1
2.1.3.2
2.1.3.3
2.1.4
2.1.4.1
2.1.4.2
2.1.4.3
2.1.5
2.2
2.2.0
The archive shall be able to contain data derived from processing (i.e., L2-and-above
data).
Processed data shall include data produced by the application of DAPS methods to
level 1 data. These methods will be specified as the L2 data products are identified.
Processed data shall include data produced by the application of user built (i.e.,
non-DAPS) science analysis tools.
Processed data will be in the form of a data product as defined in 3.2 (see figure 8;
see also section 1.2.5).
The archive shall be able to contain all archive management data.
The archive shall contain the ingest log (see section 5.2).
The archive shall contain the data product inventory (section 7.3).
The archive shall contain data defining relations between observations.
The archive shall contain ancillary data including spacecraft events, spice kernels,
etc.
Archive Consistency
These requirements are intended to guarantee that the archive contains the most
recent versions of raw and processed (L2 and above) data and that the data are
properly organized in the archive:
External Consistency
L0, L1b, L2+ Sources
Internal Consistency
DAPS archive
Consistency Reports
Ingest Logs (5.2)
Figure 4. Archive Consistency
2.2.1
2.2.2
2.2.2.1
2.2.2.2
2.2.2.3
2.2.2.4
The DAPS shall be able to produce reports on inconsistencies with the sources of
raw and L2-and-above data, specifically, reports containing the latest reprocessing
date for such data in the DAPS archive.
The archive shall be internally consistent.
Internal consistency shall include a complete, n-to-1 relationship between science
data and associated instrument configuration data.
Internal consistency shall include bounds on instrument configuration data.
Attempts to ingest inconsistent data will result in (logged) rejection of the data.
Data that violate internal consistency requirements may be stored in the archive if
and only if they are flagged with a pointer to the ingest log entry that contains a
description of its ingest.
2.3
Archive Completeness
2.3.0 These requirements are intended to guarantee that the archive contains as much data as
possible:
UVIS Data Archiving and Processing System Requirements, Version 1
5
New raw data
Ingest (1.3)
New data product
Complete archive
Inventory update (sec 7.2)
Figure 5. Archive Completeness
2.3.1
2.3.1.1
2.3.1.2
2.3.1.3
2.3.2
2.4
2.4.0
The DAPS shall be able to report on the volume of data potentially available from
external sources and not contained in the DAPS archive.
A completeness report shall contain a listing of all gaps in archived data.
A completeness report shall contain a specification of the time interval between the
latest ingested data and the current time.
The completeness report can be configured to ignore specified anomalies.
Ingested data shall not be deleted except to maintain consistency of data (see section
2.2 on consistency)
Archive Correctness
These requirements are intended to guarantee that the archived data does not change
incorrectly.
Isolated
Reprocessing
Update
Internal
Inconsistency
Correct Archive
Update
Figure 6. Archive Consistency
2.4.1
2.4.2
2.4.3
2.5
2.5.0
2.5.1
2.5.2
2.5.2.1
2.5.2.2
2.6
2.6.0
The DAPS shall allow updates to inconsistent data (see section 2.2.2.4)
The DAPS shall allow updates to reprocessed data that do not effect any archived
science data (e.g., updates to the spacecraft events time line).
No other updates are allowed on science and housekeeping data.
Error Recovery
These requirements are intended to guarantee that archived data will not be lost.
The ingest process shall not terminate as a result of detectable errors.
The archive shall be recoverable.
The archive shall be backed up to a secondary media.
If an archive recovered from a back up is incomplete, it shall be possible to make it
complete by re-ingesting data specified in the ingest log.
Archive Reporting
These requirements are intended to guarantee that the archive status can be easily
monitored.
UVIS Data Archiving and Processing System Requirements, Version 1
6
2.6.1
2.6.2
The DAPS shall provide a reporting system by which the current status of the
archive can be examined.
A report shall be savable to a text file.
A report shall be displayable within a graphic user interface.
A report shall present information in a format that is independent of the underlying
organization of the archive.
The report system shall be extensible.
3
DATA ACCESS REQUIREMENTS
3.1
Query Capability
These requirements are intended to guarantee that a user can search for, understand,
and extract data from the DAPS system:
2.6.1.1
2.6.1.2
2.6.1.3
3.1.0
Channel and params
Time range
ID
Target
Query
Name
interface
Free text dscrpt
Concurrent events
List of
selected
observations
Browse
products
Data
products
Figure 7. Data Access
3.1.1
3.1.2
3.1.3
3.1.4
3.1.5
3.1.6
3.1.7
The UI shall be distributed over the internet.
The UI shall enable a user to specify desired characteristics of data; i.e., the UI shall
enable a user to query for data by specifying a data product ID, or a channel and
zero-or-more instrument-configuration parameters associated with the channel, or
by specifying a time range, or by specifying time-related data, or by specifying a
target, or by specifying an observation name, or by specifying a link name, or by
specifying some free text.
The UI shall be able to display and save in text form a list of observations having
specified characteristics.
The UI shall allow a user to display a browse product for a specific observation (see
sections 3.2 and 3.3 for more information about products).
The UI shall allow a user to download the data product associated with the browse
product on display.
The UI shall allow a user to download multiple data products selected from a list of
observations in batch mode.
The UI shall allow a user to download the most recent version of the DAPS
processing component.
UVIS Data Archiving and Processing System Requirements, Version 1
7
3.2
3.2.0
Data Products
These requirements are intended to make information required to use data available
to users and to software. They describe the organization of data into data products:
ID
M
d
GUI
a
t
Hard Copy a
d
a
t
a
H
s
t
r
y
GUI
Hard Copy
API
Figure 8. Data Product Structure
3.2.1
3.2.2
Data products shall have a unique identification.
Data products shall have a data component, a metadata component, a processing
history component, and a set of methods defined on the dataproduct.
3.2.2.1 FUV data shall contain a sequence of integer values representing counts taken during
a series of integrations. These counts shall be mappable into an x-y coordinate
system using window data contained in the FUV metadata.
3.2.2.2 FUV metadata shall include all instrument configuration data as specified in
reference 1.
3.2.2.3 FUV metadata shall include a definition of the FUV data product including a list of
all methods and attributes associated with the data product.
3.2.2.4 FUV metadata shall contain a free text description of the observation.
3.2.3.5 FUV metadata shall contain or be sufficient to produce a PDS label describing the
data component.
3.2.2.6 FUV metadata shall contain a user-specified subset of all time-related housekeeping
data.
3.2.2.7 FUV metadata shall be extensible; i.e., it shall be possible to add to the contents of
the metadata component in response to user requests.
3.2.2.8 FUV processing history shall contain a description of the steps involved in creating
a data product; in particular, a processing history shall be composed of a sequence
of ordered pairs that contain a data product identification and the method invocation
used to produce the data product.
3.2.2.9 If an FUV data product is inconsistent, its processing history shall contain a text
description of the mechanism by which it can be made consistent.
3.2.2.10 FUV methods shall include a browse product constructor; other methods are to be
described.
3.2.2.11 EUV data products shall have the same structure as FUV data products.
UVIS Data Archiving and Processing System Requirements, Version 1
8
3.2.2.12
3.2.2.13
3.2.2.14
3.2.3
3.2.4
3.2.5
3.2.6
3.2.7
3.2.8
3.3
3.3.0
3.3.1
3.3.2
3.3.2.1
3.3.2.2
3.3.2.3
3.3.3
3.3.4
3.3.5
HSP data products shall have a data component consisting of a sequence of
integers representing a time series of HSP counts. In all other respects, an HSP
data product is structured as described in sections 3.2.2.2 through 3.2.2.6.
HDAC data products shall have a data component that consists of a sequence of
integers groupable into blocks of 32 channel/voltage count values as described in
reference 1.
HDAC and HSP methods shall include a browse product constructor; other
methods are to be described.
The data component of a data product shall be exportable to a file unless explicitly
restricted.
Metadata shall be displayable in a GUI. The display shall contain at least a text
representation of all metadata.
Metadata shall be exportable to a text file.
Processing history shall be displayable in a GUI.
Processing history shall be exportable to a text file.
Data products shall be capable of being stored in and retrieved from a file.
Browse Products
These requirements are intended to specify the relationship between browse
products and data products. A browse product serves as a tool for qualitative
assessment of an associated data product.
A data product shall have 0-or-more associated browse products, and each browse
product shall have one associated data product.
A browse product shall have a data component, a metadata component, and a
processing history component.
The data component of a browse product shall be a subset of the data component
of the associated data product.
The metadata component of any browse product shall be the same as the
metadata component of the associated data product, with the addition of a text
describing how the browse product was chosen from the data product and what
the browse product is intended to reveal about the data product.
The processing history component of any browse product shall be the same as the
processing history of the associated data product with the addition of an ordered
pair containing the browse product and its construction method.
The data component of a browse product shall displayable in a GUI.
The data component of a browse product shall be exportable to a file.
A browse product shall have no user-accessible methods defined on it.
4
PROCESSING REQUIREMENTS
4.1
System Distributivity
These requirements are intended to make the DAPS readily available to users at
diverse locations.
4.1.0
UVIS Data Archiving and Processing System Requirements, Version 1
9
4.1.1
4.1.1
4.1.2
4.1.3
4.2
4.2.0
4.2.1
4.2.1.1
4.2.1.2
4.3
4.3.0
4.3.1
4.3.2
4.4
4.4.0
4.4.1
4.4.1.1
4.4.1.2
4.4.1.2.1
4.4.1.2.2
The DAPS processing software shall be portable to a wide variety of computer
hardware and operating systems.
The DAPS processing software shall be available via the transfer, placement, and
decompression of a single file.
DAPS installation shall not involve any modification, pre-processing, compilation,
nor manual linking of software.
Data product installation shall involve only the transfer and placement of a single
file.
Support for Distributed Processing
These requirements are intended to support a robust processing architecture.
The DAPS shall be capable of supporting client/server relationships on data
product methods.
The physical location of the computer processes handling a method invocation
shall be invisible to a user unless the information is specifically requested.
The physical location of resources used to process a method, other than those
supplied as parameters to the method, shall be invisible to a user under all
circumstances.
Extensibility
These requirements are intended to support the creation of new classes of data
products.
The DAPS shall support the introduction of new data products that are approved
for introduction by the principle investigator.
New data products shall be distinguishable from any other data product only by a
description of their origin in their processing history.
Revisibility
The purpose of these requirements is to support updates and additions to data
processing software.
The DAPS shall be compatible with new versions of methods currently in the
system.
Revisions of methods that have no effect on any data product in the system shall
be noted only within the processing history of the data products that contain the
method.
Revisions to methods that effect data products shall be noted in a version number
associated with every data product and in the processing history.
Data products with different version numbers shall be incompatible unless forced
to be compatible.
Revisions that produce incompatibilities shall have a reprocessing plan. This
plan shall be stored in the processing history of all data products that contain the
method.
UVIS Data Archiving and Processing System Requirements, Version 1
10
4.4.2
4.4.3
4.5
4.5.0
4.5.1
4.5.2
Adding a method to a data product shall produce no incompatibilities between
data products.
Revisions to the DAPS other than those described here shall require authorization
from the science team leader.
Compatibility
The purpose of these requirements is to guarantee that the DAPS processing
system can be integrated into pre-existing software systems.
Data product methods shall be invocable via an operating system’s command line
interface.
Metadata shall be sufficient to support the creation of a C language routine that
can read and correctly represent data exported from a data product.
5
DERIVED INGEST REQUIREMENTS
5.1
5.1.5
Ingest Log
These requirements describe the contents of the ingest log that are necessary to
support error recovery (section 2.5) and maintain archive consistency (section
2.2).
The ingest log shall contain sufficient information to repeat any step in the data
ingestion process.
The ingest log shall contain a trace of every inserted record to the raw data file
from which it was obtained.
The ingest log shall contain each record that was not successfully inserted and a
description of why the insertion failed.
The ingest log shall contain complete descriptions of all deletions from the archive.
The ingest log shall contain complete descriptions of all error recovery activities.
The ingest log shall contain complete descriptions of all exceptional archiving
activities (including manual insertion of inconsistent data).
The ingest log shall be stored in the archive, though it will not be a data product.
6
DERIVED ARCHIVE REQUIREMENTS
6.1
Relational Database Requirements
These requirements describe mechanisms that enable the DAPS archive to satisfy
requirements 2.1 through 2.5. In effect, the following items describe a relational
database implementation of the DAPS archive.
The archive shall consist of a set of relational database tables.
The archive shall be able to support integrity constraints between and within
tables.
Integrity constraints shall be used to maintain observation integrity across
multiple tables.
5.1.0
5.1.1
5.1.1.1
5.1.1.2
5.1.2
5.1.3
5.1.4
6.1.0
6.1.1
6.1.2
6.1.2.1
UVIS Data Archiving and Processing System Requirements, Version 1
11
6.1.2.2
6.1.3
6.1.4
6.2
6.2.0
6.2.1
6.2.2
6.2.3
Integrity constraints shall be used to insure data correctness unless they
contribute to violations of performance requirements.
The archive shall support access restrictions both on a table-specific and archivespecific basis.
The archive shall have an interactive and batch query interface.
Error Recovery Requirements
The following requirements describe how a tape backup system in conjunction
with the ingest log shall be used to handle error recovery.
Archive backups shall be made to tape.
When an ingest process completes, if there are no waiting ingest processes and a
tape is mounted, the DAPS shall perform a backup.
If a tape backup is insufficient to recover fully from errors, the ingest log shall be
sufficient to make recovery complete.
7
DERIVED MANAGEMENT REQUIREMENTS
7.1
Revision Control
The following requirements describe a system for supporting software version
control, which is critical to supporting software extensibility and revisibility
(requirements 4.3 and 4.4) and data consistency (section 2.2).
Every component of the DAPS processing software shall have a version number.
Any interaction between two components with different version numbers shall
produce an error.
Any modification to a DAPS component that produces effects on other
components shall result in a change to the version of the component.
Changes to a method algorithm that result in different output shall produce a new
version number.
Changes to public method signatures shall produce a new number (this is done to
maintain consistency with external processing systems).
Changes to data products resulting from reprocessing at the TDS or from other
external sources shall produce a new version.
Ingestion of reprocessed data shall not result in the creation of a new data product.
Reprocessed data shall overwrite old data in the archive.
Ingest of reprocessed data shall be noted in the processing history.
Ingest of reprocessed data shall result in an update to the data product inventory
(see section 7.2).
7.1.0
7.1.1
7.1.2
7.1.3
7.1.3.1
7.1.3.2
7.1.3.3
7.1.3.3.1
7.1.3.3.2
7.1.3.3.3
7.1.3.3.4
7.2
7.2.0
Inventory Control
The following requirements describe a mechanism by which data products are
advertised and their availability managed.
UVIS Data Archiving and Processing System Requirements, Version 1
12
7.2.1
7.2.2
7.2.3
7.2.4
The DAPS inventory shall be a set of data product IDs and associated version
numbers.
All data products available through the DAPS shall be contained in the inventory.
The inventory shall contain all valid versions of a data product (this does not imply
that the data associated with an old version of a data product reside in the archive).
The inventory shall have an inventory distribution list that contains a name, a data
product, and a version for each requested download of a data product.
8
EXTERNAL AND OPERATIONAL REQUIREMENTS
8.1
Requests for raw data shall be such that only complete observations are contained in
a raw data file.
ODC ID telemetry values shall be used to delimit observations.
The DAPS shall be kept consistent with raw and L2-and-above data reprocessing
by a system operator who has been notified of reprocessing and DAPS archive
consistency reports.
The DAPS shall be kept complete by a system operator using DAPS completeness
reports, planning and scheduling data, and TDS data availability announcements.
Browse products shall be created either automatically by a default creation process
or manually after scientific analysis of a data product.
DAPS revision plans (section 4.4.1) shall be developed by the ground system team
under the direction of the principle investigator.
Support for system backups shall be provided by a system operator.
DAPS operations shall be carried out by a full-time system administrator and a halftime system operator.
8.2
8.3
8.4
8.5
8.6
8.7
8.8
9 REFERENCED DOCUMENTS
1.
2.
3.
4.
Cassini Project Ultraviolet Imaging Spectrometer (UVIS) Science Packet Format (6/95)
Housekeeping telemetry format definitions
TBD
TBD
UVIS Data Archiving and Processing System Requirements, Version 1
13