Validation and Verification of Chandra Data: A New and Improved system

Previous   Contents   Next



Validation and Verification of Chandra Data:
A New and Improved system

(Adapted from ADASS05 paper titled “Validation and Verification: Combining pipelines, a Graphical Application and the Human Factor” by Janet DePonte Evans, Thomas J. Calderwood, Ian N. Evans, Kenny J. Glotfelty, Diane M. Hall, Joseph B. Miller, and David A. Plummer)

contact: janet@cfa.harvard.edu


Over the past year, Chandra observers will have noticed a new Verification and Validation (V&V) report added to the data products available from Standard Data Processing (SDP). The report is just the end product of a new and improved V&V system developed by the Chandra Data System based on mission experience and characterization of known issues by instrument scientists.
V&V is performed on each observation processed through the SDP pipelines. A V&V pipeline runs at the end of observation processing (L2). A manager component is then triggered and controls the V&V flow after the pipeline completes. A GUI provides the user interface to the operations staff for data quality review.

Validation and Verification Requirements

The V&V system provides 2 distinct checks for data quality assurance: validation and verification.
Validation applies a set of predefined tests to the SDP data products to ensure processing and calibration were performed correctly. Some validation requirements are easy to predefine (for example, searching pipeline processing logs for errors). Others require mission experience to understand the boundary between processing, calibration and performance limitations and actual anomalous behavior. If an observation fails validation, the SDP operations staff must be notified that reprocessing of the observation is required.
Verification compares the actual spacecraft and instrument configurations with the requested configurations, and checks that the scheduling properties of the observation meet the constraints
specified by the observer. If an observation fails verification, the
Chandra Director’s Office (CDO) must be notified, along with the relevant instrument scientist (if appropriate).
Secondary requirements of V&V include: (1) creating a written

report that is accessible to the observer; (2) updating an observation’s charge time in the Observation Catalog database, which is
counted against the target’s time allocation to determine if additional scheduling is required to complete the observation; (3) triggering promotion of data products in the
Chandra Data Archive to identify the data products as the default versions available to users; (4) triggering data distribution (or feedback for reprocessing); (5)~initiating the start of the proprietary period clock (for observations with proprietary data rights); and (6) enabling the reviewer to complete V&V in ~5 minutes for a successfully processed observation.

Automated Validation and Verification Design

The design goals of our post-launch efforts were aimed at encapsulating experience gathered with the live mission into automated checking. This included limit-checking only pertinent science and engineering data, identifying specific serious pipeline warnings and errors, and presenting and evaluating carefully selected data views defined by V&V and instrument scientists based on experience. Human review is minimized by identifying unexpected test results using color coding.
To improve system integrity and automation goals, the V&V software also manages all of the required interfaces and system triggers, including triggering an error recovery path - reprocessing, rescheduling, and further investigation by instrument teams. Other design goals included enabling other groups to evaluate V&V by providing an interface to CDO and instrument scientists, and allowing off-site access via a standard web browser to support rapid turnaround of fast processing requests or anomaly resolution.

Automated Validation and Verification
Implementation


The V&V software is implemented as three components: (1) a pipeline, which executes after the completion of level 2 processing for an observation; (2) a manager process that controls the V&V flow after the pipeline completes; and (3) a GUI that provides the user interface for the reviewer.
The pipeline creates the V&V data products that are displayed through the GUI, including predefined html web-pages, JPEG images, PNG plots, and key tabular information designed specifically for V&V. The pipeline also creates a template PDF format report for distribution to the user, and seeds the report with textual comments and the “most likely’’ disposition status based on the results of the tests applied by the pipeline. Finally, the pipeline computes the nominal charge time for the observation.
The manager builds and links the V&V report web-pages into the GUI for display to the reviewer, and manages any input that the reviewer may supply using the GUI, including verifying that any revisions to the calculated charge time comply with appropriate rules. State transition updates occur when a new disposition status is selected by a reviewer for an observation, and initiate further actions by the manager process, such as sending email notifications to appropriate parties, or triggering data distribution. The manager also creates the final V&V report for distribution to the user by incorporating the reviewer comments and disposition status entered via the GUI into the template report. This last action is triggered when the reviewer submits a final state as the disposition status for the observation, indicating that the review is complete.


FIGURE 23:
Sample V&V GUI observation front page.

The GUI is the interface for the reviewers and others handling
V&V. It guides the reviewers through the evaluation process byidentifying required (“must review’’) and supporting data views, and provides the capabilities to edit the comments, charge time, and disposition status seeded by the pipeline. The GUI also provides mechanisms to manage authorized users of the V&V software, including their privileges (which define the functions that they may perform) and their capabilities (which identify the types of data that they may handle). The GUI provides a selectable set of mechanisms to assign reviews to reviewers based on comparison of the actual instrument configuration and scientist’s capabilities. Finally, the GUI triggers creation of a new edition of a report if it must be revised after submission with a final state.
The new V&V software was installed in operations in January 2005. It provides a systematic evaluation of SDP results and issues, and allows operations staff to perform V&V. As a result, the data processing statistics have improved dramatically and the quality of the data products to the user has improved.


Janet DePonte Evans