Guidelines for Development of a
PROJECT DATA MANAGEMENT PLAN (PDMP)
NASA Office of Space Science and Applications
March 1993

National Aeronautics and Space Administration
Office of Space Science and Applications
Information Systems Branch

Contents
Preface	1
1.0	Introduction	2
1.1	Purpose and Scope	2
1.2	PDMP Development, Maintenance, and Management Responsibility	2
1.3	Change Control	2
1.4	Relevant Documents	2
2.0	Project Overview	3
2.1	Project Objectives	3
2.2	Science Objectives	3
2.3	Spacecraft Description	3
2.4	Mission Summary	3
3.0	Instrument Overview	5
3.1	Instrument "A"	5
3.1.1	Instrument Description	5
3.1.2	Capabilities and Requirements	5
3.1.3	Data Acquisition	6
4.0	Project Data Flow	7
4.1	Mission Operations	8
4.1.1	Telemetry Services	9
4.1.2	Mission Control	10
4.1.3	Mission Planning & Scheduling	10
4.2	Science Operations	10
4.2.1	Science Control	10
4.2.2	Science Planning and Scheduling	11
4.2.3	Science Data Set Generation	11
4.2.4	Project Data Repositories	11
4.3	Continued Accessibility	12
4.3.1	Data Repositories	12
4.3.2	Directories and Catalogs	14
4.3.3	Standards and Policies	14
4.3.4	Scientific Computing Resources	14
4.3.5	Networking Requirements	14
5.0	Products	15
5.1	Science Data Product Summary	15
5.1.1	Instrument "A"	15
5.2	Associated Archive Products	16
6.0	Special Considerations	17
Glossary	18
Acronyms	21
References	22
Appendix A:  OSSA Policy on Science Data Management	23
Appendix B:  Project Summary Tables	26
Appendix C:  Examples of Project Summary Tables	29

Figures and Tables

Figure 1	OSSA MO&DA generalized architecture. 	7
Figure 2	Overall project timeline. 	8

Table 1	Mission summary parameters. 	3
Table 2	Mission data acquisition parameters. 	4
Table 3	Instrument summary parameters. 	5
Table 4	Space to ground communications parameters. 	9
Table 5	Telemetry processing parameters. 	10
Table 6	Science data set generation parameters. 	11
Table 7	Project data repository parameters. 	12
Table 8	Discipline archive parameters. 	13
Table 9	NSSDC parameters. 	14
Table 10	Science data product summary parameters for Instrument "A". 	16

Table B-1	Project summary parameters. 	26
Table B-2	Instrument summary parameters. 	27
Table B-3	Data product summary parameters. 	28

Table C-1	GRO project summary parameters. 	29
Table C-2	GRO instrument summary parameters. 	30
Table C-3	GRO data set summary parameters. 	32

Preface
In principle, the PDMP is intended to address the management of data from space science investigations, from the point of their reaching the ground, to their entry into permanent archives.  Data will typically flow from the project's sensors through "institutional facilities" not "owned" by the project (e.g., Code O telemetry acquisition systems, generic low level data processing systems) to "project-owned" systems and project-funded scientists, and finally from project systems/scientists into OSSA archives.  During this data flow, data will be transformed at multiple steps, and not all data may be appropriate for the archives.
In practice, the PDMP will be used primarily to identify data products, and those institutional facilities used during the "project data use" phase, and OSSA archives at the back end.  Data in the PDMP will be used to support the readiness of these facilities to discharge their responsibilities relative to the project's data.  The effectiveness of the data management and archiving process depends on a well-defined relationship between the project, investigators, and the archive facility.  With cooperation, NASA's data management infrastructure will continue to provide a valuable service to all and help preserve our precious space heritage through preserving the data.  The creation of the PDMP is the first step in this process.
The requirement for all space science projects to complete a PDMP was clearly defined in the recent OSSA data management policy directive.  A full copy of the policy statement is included in Appendix A, with the relevant PDMP requirements summarized below: 
•	All OSSA data being captured shall be addressed in a PDMP
•	The NAR (or equivalent) will include early assessment of data management plans
•	A formal PDMP will be prepared and approved coincident with the Project Plan 
•	PDMPs should be reviewed periodically and updated as required
•	The duration of all exclusive use periods shall be explicitly defined
The purpose of this document is to provide guidelines to assist NASA Project personnel in the preparation of plans for managing the data associated with their project.  The outline of this document is the recommended outline for all PDMPs.  In each section, the text describes the type of material which should be included, and recommended table formats are provided which summarize relevant data management parameters.  Early in the life cycle of a project, many of the parameters identified in the guidelines will not be known, and should be identified as TBD.  As a project matures and more parameters are known or change, the PDMP should be updated as appropriate.  The format provided should be general enough to be applied to all science investigations within OSSA.  These formats can be modified, depending upon the specifics of any particular discipline or project requirements.  Although the PDMP is the recommended document to be used for data management planning, other documents that fulfill the intent of the PDMP are acceptable.
Summary tables of all project, instrument, and data set parameters should be included as an appendix to each PDMP.  This will provide a concise summary of relevant data management parameters for each project.  Recommended formats for these tables are provided in Appendix B of this document, with an example of completed project summary tables for the Gamma Ray Observatory (GRO) project in Appendix C.
The intent of these guidelines is to make the assembly of PDMP's easier for the projects, and to ensure that PDMP's be in a consistent and useful format.  Any comments regarding the utility of these guidelines, or suggestions for improvement would be appreciated.

1.0	Introduction
The introduction should include the name of the project, the current status of the project.
1.1	Purpose and Scope
This section should briefly summarize the purpose of the PDMP for this project, highlighting specific purposes and applications for the plan.
1.2	PDMP Development, Maintenance, and Management Responsibility
This section should identify the organization(s) responsible for the development, maintenance and management of the PDMP document.  In addition, the individuals within those organizations who are currently accountable should be identified including locations and phone numbers.  It is important to note that a PDMP is not intended to be a static document but should be revised on an "as needed" basis.  The emphasis in the PDMP should be on advanced planning of the management of data acquired by NASA.
1.3	Change Control
This section should illustrate the plans for modifications and updates to this document over time, and how those changes will be controlled.  Such changes could be the result of updates as the project progresses in its development cycle, or from changes to operations plans or hardware capabilities once operational.  If there are planned updates, estimated release dates should be given.  If project data management documents other than the PDMP are to be used, they should include a change control strategy.
1.4	Relevant Documents
All currently available documents with information relevant to data management for the project should be referenced here, including name and location of source for documents, if not readily available.  Such documents should at least include ICD's, Project Plan, mission operations concepts and plans, and relevant documents for each instrument.  If some documents are not yet available but planned, this should be indicated, with expected availability dates and organization that will be producing document.

2.0	Project Overview
An overview of the project should be provided in this section.  It should specifically include a summary of the history of the project to its current status, including predecessor or related missions.
2.1	Project Objectives
The overall objectives of the project should be briefly described here.  This should include how the goals of the project, and how the expected results of the project may contribute to some larger goals or objectives.
2.2	Science Objectives
The specific science objectives of the project should be briefly described here.  This would include expected results to be gained in certain scientific areas, and could be related to specific instruments.
Also addressed here should be who the primary science users are expected to be, and which science objectives are expected to be met initially in the project, as opposed to those which may be met through continued accessibility by secondary investigators.
2.3	Spacecraft Description
A brief summary of the spacecraft should be provided here.  It should include characteristics such as weight, power and dimensions, and a diagram illustrating the spacecraft and principal subsystems and instruments.
2.4	Mission Summary
A mission summary should be provided in this section, addressing significant schedule and operational characteristics of the project.
The information shown in Table 1 should be provided as a minimum.
Table 1	Mission summary parameters.

	Mission Summary Parameters	Values	
	Project Name		
	Orbit Description	inclination, apoapsis, periapsis, period	
	Launch Date		
	Launch Vehicle		
	Nominal Mission Duration		
	Potential Mission Life		
Detailed information regarding overall mission summary should be included in the write-up rather than the table.  Information regarding principal data acquisition characteristics of the overall mission should also be included in this section.  The type of information to be included is shown in Table 2, to the extent known at the time of PDMP development.
Table 2	Mission data acquisition parameters.

	Data Acquisition Parameters	Values	
	On-Board Data Storage Capacity		
	Continuous Data Acquisition Rate		
	On-Board storage saturation		
	Target pointing duration		
	Target re-orientation period		
	Attitude control accuracy		
	Attitude determination accuracy		
Detailed information and descriptions should be included in the write-up.

3.0	Instrument Overview
A brief overview of the project instruments should be provided here.  This should include any relevant interactions between the instruments, and how the instruments combine to meet the overall science objectives of the project.
3.1	Instrument "A"
The following information should be provided for each of "n" instruments of the project, resulting in sections 3.1 through 3.n..
3.1.1	Instrument Description
A description of the instrument should be provided in this section.  This description should include the experimental objectives of the instrument, the instrumentation involved, and the operational aspects of the instrument and the data modes involved in its operation.
3.1.2	Capabilities and Requirements
The capabilities and requirements of each instrument should be summarized in this section in tabular form.  These should include those capabilities and requirements which are relevant to data management.  The parameters for each instrument of a project should be consistent, to the extent possible.  The parameters shown in Table 3 should be included for each instrument as appropriate, to the extent known at the time of PDMP development.
Table 3	Instrument summary parameters.

	Instrument Summary Parameters	Values	
	Geophysical Phenomenon/Parameters Measured/Derived		
	Number and Type of Detectors		
	Sensitive Area		
	Field of View		
	Energy/Wavelength Range		
	Energy/Wavelength Resolution		
	Time Resolution		
	Positioning		
	Sensitivity		
	Data Rate		
Comments on the specifics of an instrument which do not conform to standard parameters listed above could be added, or discussed in the text. 
3.1.3	Data Acquisition
The types of data to be acquired by the instrument should be addressed in this section.  In addition, the data acquisition modes for each instrument should be addressed.  A good example of data acquisition descriptions can be found in the appendices of the GRO PDMP. 

4.0	Project Data Flow
An overview of the Project Data Flow should be given here including an overall functional Data Flow Diagram.  This diagram should identify those facilities performing various functions as the project progresses through its various mission phases.  The diagram should distinguish between those facilities which are specific to the project and those which are discipline or institutional facilities.  In addition, an overall project timeline should be developed and included, summarizing key milestones and events relevant to data management over the life cycle of the project.
Though each mission is unique, there are fundamental elements, functions, and services that are common.  In general, space science investigations can be divided into three segments of operation: mission operations, science operations, and continued accessibility.  During each segment of the project, fundamental functions and services are performed as part of the integrated investigation.  Those functions which are project specific should be distinguished from those that are not.
A diagram depicting a generalized architecture for Mission Operations and Data Analysis (MO&DA) is shown in Figure 1.  The overall project data flow diagram included in the PDMP should include each of these elements as appropriate, identifying which facilities are expected to perform basic functions.

Figure 1	OSSA MO&DA generalized architecture.

In additional to a top-level functional flow, a timeline of activities and milestones related to data management over the life cycle of the project should be provided.  An example timeline, shown in Figure 2 below, indicates the type of milestones that should be included.

Figure 2	Overall project timeline.
4.1	Mission Operations
A summary of the projects Mission Operations concept would be given in this section, including a more detailed functional flow of the mission operations portion of Figure 1.  This flow should address the space to ground communications and initial processing of telemetry, as well as the mission control and mission planning and scheduling.  The facilities associated with each function of these processes should be identified in the diagram, and the distinction made as to which are project specific and which are not.  
In addition to the functional flow, a detailed timeline of the mission operations phase shown in Figure 2 should be included.  Specifically, the timeline should address the time from mission planning and scheduling to implementation.  Issues such as real time or playback data, quick-look data processing, and real-time experimental control should be addressed as appropriate.
4.1.1	Telemetry Services
This section of the PDMP should address the overall approach to telemetry services, from the space to ground communications to the initial data processing once received.  Diagrams illustrating these functions and timelines should be provided in this section in greater detail than in higher level diagrams, as appropriate.  The organization of the telemetry format should be illustrated in this section, including frame and packet descriptions.
4.1.1.1	Space to Ground Communications
Discussion of space to ground communications should include the data acquisition mode (whether real-time, playback, etc.) and any specific characteristics of project requirements due to this mode.  In addition, the name and location of the ground based facilities involved should be provided.  Any operational or mechanical constraints on the telemetry services of the project should be briefly summarized. This could include such things as coordination with other missions.
The parameters shown in Table 4 should be provided as appropriate for the spacecraft.  If there is a single communication system for the spacecraft, then one system should be described.  If there are multiple communication systems (associated with different instruments for example) then the table should be repeated for each system.  	
Table 4	Space to ground communications parameters.

	Parameter	Values	
	S/C Link	Frequency 
Polarization 
Path		
	Data Rates [kbps]
Forward		Peak
	Average
Contact Frequency
Return		Peak
	Average
Bit Error Rate
Contact Frequency
Average Duration	
(kbps)
(kbps)
(times/day, orbital, etc.)
(kbps)
(kbps)

(times/day, orbital, etc.)
(minutes)	
If there are sources with specific information on space to ground communications available, they should be included in Section 1.4.  A pointer to the document could be included in this section as well, as appropriate. 
4.1.1.2	Telemetry Processing
The data capture strategy including requirements for special capabilities such as quick look capability should be addressed in the write-up.  If the telemetry processing will be occurring over multiple years at different volume levels or rates, the table should be repeated as appropriate.  The parameters shown in Table 5 should be included in this section.
Table 5	Telemetry processing parameters.

	Parameter	Values	
	Annual Volume Input	Gbytes	
	Throughput  [kbps]	
	Peak
	Average		
	Annual Volume Output	Gbytes	
	Data Distribution Time	(from on-ground to PI)	
The write-up should also identify the location and name of the processing facilities, the types of data products provided, as well as the anticipated rate (percentage) of effective data capture.
4.1.2	Mission Control
This section should address the approach to spacecraft command and control for the project.  This includes the overall spacecraft health and safety monitoring, and identification and location of facilities involved.
4.1.3	Mission Planning & Scheduling
The overall spacecraft approach to mission planning and scheduling should be addressed in this section.  This should include the identification and location of facilities involved.
4.2	Science Operations
This section should consist of a brief discussion of the project science operations style.  The style should be described relative to being principal investigator, guest observer, or other.  If other than PI or GO, the style should be specified and described in the write-up.  The relationship between the individual scientists and their payloads should be described also.
A more detailed diagram of the science operations functional flow shown in Section 4.0 should be included in this section.  In addition, a more detailed timeline of the science operations phase shown in Section 4.0 should be presented.  This should address the responsiveness of the system to the instrument control needs of the scientist.
4.2.1	Science Control
This section should address the following aspects of science control for the project:
•	Overall payload Command & Control approach
•	Overall payload Health & Safety Monitoring
•	Location of facilities
The resources required to support decisions regarding the real-time or near real-time operation of payloads or instruments should be described as well.  
4.2.2	Science Planning and Scheduling
The overall approach to science planning and scheduling for the project should be described in this section.  If the approach is a distributed system by instrument, then each instrument should be addressed.  The write-up should include the location and description of facilities involved..
4.2.3	Science Data Set Generation
This section should address the computing and analysis resources required to produce mission specific data products for PI's, GO's, and the general research community.  The discussion should address facilities which provide support across all instruments, as well as instrument specific support. 
Table 6 as shown below, provides a format for summarizing this information.
Table 6	Science data set generation parameters.

	Description	Location	Functions	Capabilities	
Project Resources					
Instrument "A" Resources					
Instrument "N" Resources					
In addition, the analysis software that may be used to generate the data sets, and any analysis support used should be identified.  This section should also describe project requirements and plans for data quality including validation and release of products to the archive system.
4.2.4	Project Data Repositories
Project data repositories are project specific, providing temporary storage for active data as it is being processed and analyzed.  This section should address the requirements placed on the project data repositories.  These requirements should address the needs of PI's and GO's for active storage using project specific facilities, including data volume and access characteristics such as access time and off vs. on-line access.  These requirements are not for permanent archiving, and are not for the general science community, as project data repositories are not open to public use.
Table 7 below provides a format for summarizing storage requirements by data set, over the years the project will be using project data repositories.  The data sets should be briefly described and identified as Level 0, Level 1, etc.  This format allows for aggregation of requirements at the data set level to instrument and overall project requirements.  The table shows the requirements on a yearly basis, but the information could be provided as "annual" if it remains relatively constant from year to year.  The yearly requirements are not aggregated, as the storage requirements are not permanent.  All project data repositories to be used should be identified.  If multiple project data repositories are to be used, their individual requirements should be identified using separate summary tables as appropriate.
Table 7	Project data repository parameters.

		Year "1"	Year "2"	Year "n"	
	Project Summary				
	Instrument "A" Summary				
	Level 0 Data
Data Set "A-1"				
	Level 1 Data
Data Set "A-n"				
	Instrument "N" Summary				
	Level 0 Data
Data Set "N-1"				
	Level 1 Data
Data Set "N-n"				

4.3	Continued Accessibility
Those activities and functions that are required to ensure the continued availability of data and supporting information on a timely basis for use by the science community should be addressed in this section.  This includes a more detailed diagram of the continued accessibility portion of Figure 1, and a more detailed timeline of the continued accessibility phase shown in Figure 2.
Any agreements regarding exclusive rights to data for the PIs should be stated here, with summary timelines for when the data will be released to the public.  All data sets to be permanently archived should be identified in this section.  They will be described in more detail in Section 5.0.  In addition, policies concerning security of data sets and products should be addressed in this section as appropriate.
4.3.1	Data Repositories
There are two general types of data repositories for permanent storage of data which should be addressed in this section.  These can be specific to a particular discipline as part of the discipline data system (DDS), or part of the OSSA institutional infrastructure such as the NSSDC.  All data repositories to be used by the project should be identified, including the place where the data enters the archive.
4.3.1.1	Discipline Archives
This section should address how data will transition from project to permanent discipline archives.  Table 8 below provides a format for summarizing storage requirements by data set, over the years the project will be providing data to discipline archives for permanent storage.  This format allows for aggregation of requirements at the data set level to instrument and overall project requirements.  The table shows the requirements on a yearly basis, but the information could be provided as "annual" if it remains relatively constant from year to year.  The yearly requirements are aggregated as well, since the storage requirements are permanent and accumulate over time.  All discipline archive facilities to be used should be identified.  If multiple discipline archives are to be used, their individual requirements should be identified using separate summary tables as appropriate.
Table 8	Discipline archive parameters.

		Total	Year "1"	Year "n"	
	Project Summary				
	Instrument "A" Summary				
	Level 0 Data
Data Set "A-1"				
	Level 1 Data
Data Set "A-n"				
	Instrument "N" Summary				
	Level 0 Data
Data Set "N-1"				
	Level 1 Data
Data Set "N-n"				
4.3.1.2	NSSDC
This section should address how data will transition from project to the NSSDC.  Table 9 below provides a format for summarizing storage requirements by data set, over the years the project will be providing data to cross-discipline archives for permanent storage.  This format allows for aggregation of requirements at the data set level to instrument and overall project requirements.  The table shows the requirements on a yearly basis, but the information could be provided as "annual" if it remains relatively constant from year to year.  The yearly requirements are aggregated as well, since the storage requirements are permanent and accumulate over time.
Table 9	NSSDC parameters.

		Total	Year "1"	Year "n"	
	Project Summary				
	Instrument "A" Summary				
	Level 0 Data
Data Set "A-1"				
	Level 1 Data
Data Set "A-n"				
	Instrument "N" Summary				
	Level 0 Data
Data Set "N-1"				
	Level 1 Data
Data Set "N-n"				
4.3.2	Directories and Catalogs
This section should address metadata and the associated mechanisms for the identification and location of data sets and data analysis tools.  The format of multiple catalogs and any browse products should be addressed in addition to the type of information that can be obtained.
This section should define the commitment of the project to deliver the required information for inclusion in the NASA Master Directory (MD) or other directories and catalogs at the time of, or prior to, the delivery of data to the archives.
4.3.3	Standards and Policies
Projects and investigators should archive data conforming to those standards and policies which will facilitate subsequent data access and use.  This section of the PDMP should describe which standards and policies for documentation, formats, and media will be used for the data to be archived on an overall basis.  The specifics of each data set will be provided in section 5.1.
4.3.4	Scientific Computing Resources
NASA resources such as those provided by the NASA Center for Computational Sciences (NCCS) at the Goddard Space Flight Center (GSFC), the (proposed) Planetary and Space Sciences Center at the Jet Propulsion Laboratory (JPL), and non-NASA resources such as those available from the National Science Foundation and the Department of Energy are examples of the capabilities available to projects and individual researchers.
4.3.5	Networking Requirements
Networking requirements of the project should be summarized in this section, including those placed on the NASA Science Internet (NSI), and other non-project specific support.

5.0	Products 
Products resulting from the project may include science data sets, and other associated archive products such as samples or hardware.  This section should describe what the project proposes to archive, and when and where it is going to be archived.
5.1	Science Data Product Summary 
Science data products include data sets generated by the project.  This section of the PDMP should identify and describe all data sets expected to be generated.  This includes the science data itself, associated ancillary data and orbit/attitude data of the spacecraft.  The basics to be covered include what data is going to be generated, when it is to be generated, and when it is to be archived.  
The science data products for each of "n" instruments should be summarized in the following sections 5.1.1 through 5.1.n.
5.1.1	Instrument "A"
This section should summarize all science data products to be generated from instrument "A".  Included with the products should be documentation for correct and independent use of the data.  The expected range of use to be supported by this documentation should be indicated in the write-up, as well as any expected limitations.  The following types of data sets should be included:
•	Meta Data
•	Low-level Processed Data
•	High-level Processed Data
-	Intermediate Analysis
-	Scientific Results
•	Derivative Products such as Source Catalogs
•	Documentation
Each data product should be discussed briefly in the write-up, with a description of the observation phenomena and other relevant characteristics not included in the summary table.  This includes relationships to other higher or lower level data sets.
A summary table should be provided for each instrument, including all planned data products.  The products could be grouped by the types listed above.  The GRO PDMP is a good example of this.  Suggested content and format for the summary table is shown in Table 10.
Table 10	Science data product summary parameters for Instrument "A".

Data Product	Data Format	Logical granules	Data granules per Year	Data Volume per granule	Data Volume per Year	Public Release
	
Level 0
Data Set 
"A-1"							
Level 1
Data Set 
"A-n"							

5.2	Associated Archive Products
This section should include descriptions of archive products which are not included in the science data products of section 5.1.  Discussion should include what is going to be saved, when it is going to be saved, where it will be saved, etc.  If these products are associated with particular instruments or data sets, that information should be provided.  The types of products which may be included in this section include the following:
•	Operations Histories
•	Analysis Software
•	Hardware
•	Samples
•	Engineering
•	Navigation
•	Geometry
•	Calibration
All products which are expected to be archived should be identified.

6.0	Special Considerations
This section is available to address special considerations not covered in the standard structure provided in these guidelines.  Such special considerations could include Multi- Division Flights, repeated flights such as Spacelab flights, other types of Shuttle flights, etc.

Glossary
The terms in this glossary reflect terminology in the PDMP guidelines document.  Each PDMP should have a glossary terms relevant to that project.

Ancillary Data	Non-science data needed to generate Level 1 data sets.  Consists of instrument gains, offsets; pointing information for scan platforms, etc.	
Catalog	The instrument source catalog is a compilation of derived parameters and scientific results about observed sources.	
Continued accessibility	The derivation and dissemination of useful science knowledge and insight resulting from the data collected.  The functions and services provided during continued accessibility include directory and catalog services, scientific computing resources, discipline data archives, and other archives and databases.	
Correlative data	Other science data needed to interpret spaceborne data sets.  May include ground-based data observations such as soil type or ocean buoy measurements of wind drift.	
Data Analysis	Process by which higher-level data products are derived from basic data acquired by instruments. Data analysis functions include modeling, manipulation, data interpretation, and data presentation.	
Data Directory	Top-level index containing information about location, ownership, contents of data.  Used as first step in determining what types of data exist for given time, period, location, etc.	
Data Handling	The process of data acquisition including onboard encoding and compression of data generated by flight sensors, data preprocessing on the ground to remove the artifacts of data transmission and conversion of raw data to Level 0 data, and management of this process to assure completeness and accuracy of 	
Data Set	The accumulation of data products, supplemental data, software, and documentation that will completely document and support the use of those data products.  A data set can be part of a data set collection, can reside on a single physical volume or across multiple volumes.	
Decommutation	Process whereby the downlink data stream is split into data streams that contain data from only one or from select payloads or systems.	
Discipline Data Archive	Long-lived collections of science, operational and related ancillary data, maintained as a national resource at a discipline data center, supported with adequate cataloging, protection, and distribution functions.  It provides long-term access to data by the general space science community.	
Guest Observer	Has access to observation, to generate specific space science data to conduct independent investigations, although seldom participate in initial mission planning or instrument design.	
High-Level Processed Data	Products of detailed processing including instrumental calibrations and background corrections.	
Level 0 Data	Reconstructed unprocessed instrument data at full resolution.  Edited Data corrected for telemetry errors and split or decommutated into a data set for a given instrument.  Sometimes called Experimental Data Record.  Data are also tagged with time and location of acquisition.	
Level 1A Data	Reconstructed unprocessed instrument data at full resolution, time-referenced, and annotated with ancillary information including radiometric and geometric calibration coefficients and geo-referencing parameters (i.e., platform ephemeris) computed and appended but not applied to the Level 0 data.  Calibrated Data - Level 0 data that are still in units produced by instrument, but that have been corrected so that values are expressed in or are proportional to some physical unit such as radiance.  No resampling, so Level 0 data can be reconstructed.	
Level 1B Data	Level 1A data that have been processed to sensor units (i.e., radar backscatter cross section, brightness temperature, etc.). Not all instruments will have a Level 1B equivalent.  Resampled Data - have been resampled in the time or space domains in such a way that the original edited data cannot be reconstructed.  Could be calibrated in addition to be resampled (can also meet Level 1A definition).	
Level 2 Data	Derived environmental variables (e.g., ocean wave height, soil moisture, ice concentration) at the same resolution and location as the Level 1 source data.	
Level 3 Data	Variables mapped on uniform space-time grid scales, usually with some completeness and consistency (e.g., missing points interpolated, complete regions mosaiced together from multiple orbits)	
Level 4 Data	Model output or results from analyses of lower level data (i.e., variables that are not measured by the instruments, but instead are derived from these measurements)	
Low-Level Processed Data	Data products of "automatic" pipeline processing.  These data are generally produces within a few months of acquisition.	
Metadata	Descriptions of database contents in sufficient detail to allow retrieval of subsets of data.	
Mission Operations	The safe and efficient operation of the spacecraft and associated payloads during the active flight portion of the investigation.  The principal functions and services associated with mission operations include telemetry services, mission planning and scheduling, and mission control.	
Non-Science User	General public, Public Affairs/Outreach or curious individuals seeking data for information purposes rather than further scientific investigation.	
Primary User	Includes science investigators who plan and design the experiments, and have an immediate need for access to the data being generated.  This includes principal investigators, guest observers, and investigator team members.  They represent the first scientists with access to the data.	
Principal Investigator (PI)	Often work with co-investigators, are responsible for planning, development, and integration of experiments and instruments, data analysis, and the selection and preparation of the analyzed data for archiving.  Principal Investigators are usually tied to a particular instrument.	
Production Time	This is the processing time required to generate a data product in usable form after data acquisition.	
Project Data Repository	Short-term data base that serves as a way station or clearinghouse for data - such as a mission data base to support operations and compilation of initial results.  Temporary buffers for new data, usually existing only as long as the mission producing the data.	
Public Release Time	This is the time when a data product becomes public domain after its production and can be accessed by a researcher exclusive rights to the data.  	
Raw Data	Telemetry data with data embedded	
Science Operations	The functions and services required to ensure the production of valuable science data or samples during the active flight portion of the investigation.  Principal functions and services provided as science operations include science planning and scheduling, science control, project data archive, and science data analysis.	
Secondary User	General science community could include discipline peers, or interdisciplinary scientists.  Usually conduct their analysis using data that has been archived, as well as data provided or published by the PI.  Secondary users also work in collaboration with primary users.  A researcher not involved with instrumentation design, development, or data acquisition.  A secondary user would normally go to a data archive to obtain the required data set.  Also referred to as retrospective investigator.	
Telemetry Services	Those activities required to convert the spacecraft downlink into data that is useful to the experimenter or investigator.	

Acronyms
The acronyms provided in this list reflect terminology in the PDMP guidelines document.  Each PDMP should have an acronym list of terms relevant to that project.

CODMAC	Committee on Data Management and Computation	
DDS	Discipline Data System	
EOS	Earth Observing System	
GO	Guest Observer	
GRO	Gamma Ray Observatory	
GSFC	Goddard Space Flight Center (NASA)	
ICD	Interface Control Document	
ISB	Information Systems Branch	
ISSP	Information Systems Strategic Planning Project	
JPL	Jet Propulsion Laboratory (NASA)	
kbps	Thousand bits per second	
MD	Master Directory	
MO&DA	Mission Operations & Data Analysis	
NAR	Non-Advocate Review	
NASA	National Aeronautics and Space Administration	
NCCS	NASA Center for Computational Sciences	
NMI	NASA Management Instruction	
NSF	National Science Foundation	
NSI	NASA Science Internet	
NSSDC	National Space Science Data Center	
OSO	Office of Space Operations	
OSSA	Office of Space Science and Applications	
PDMP	Project Data Management Plan	
PDS	Planetary Data System	
PI	Principal Investigator	
PSCN	Program Support Communications Network	
S/C	Spacecraft	
SIRD	Support Instrumentation Requirements Document	

References
The references shown here are relevant to the PDMP guidelines document.  Each PDMP should have a list of references relevant to that project.

1)	"Guidelines for the Development of a Project Data Management Plan," James L. Green and Joseph H. King, NSSDC 88-16, July 1988
2)	"Report of the Information Systems Strategic Planning Project", NASA OSSA/OSO, January, 1990
3)	"Data Management and Computation, Volume 1: Issues and Recommendations", COD-MAC, 1982
4)	"Issues and Recommendations Associated with Distributed Computation and Data Management Systems for the Space Sciences", COD-MAC, 1986
5)	" Space and Earth Sciences Information Systems: Issues and Opportunities for the 90's", January, 1992
6)	"Office of Space Science and Applications Strategic Plan 1991", April, 1991
7)	"Gamma Ray Observatory (GRO) Project Data Management Plan", July 1990
8)	"Office of Space Science and Applications Strategic Plan 1990", May 1990
9)	"A Guide to the National Space Science Data Center", NSSDC 90-07, June 1990

Appendix A:  OSSA Policy on Science Data Management

OFFICE OF SPACE SCIENCE AND APPLICATIONS PROGRAM DIRECTIVE
Responsible Offices:
Life Sciences Division
Earth Sciences and Applications Division
Solar Systems Exploration Division
Flight Systems Division
Microgravity Science and Applications Division
Space Physics Division
Astrophysics Division
Subject: Policy for the Management of the Office of Space Science and Applications' Science Data
1.	Purpose
The purpose of this Program Directive is to establish NASA's policy for, and delineate responsibilities and authorities relative to, the continuing management of the Office of Space Science and Applications' science data.  It replaces NASA Management Instruction (NMI) 8030.3A, "Policy Concerning Data Obtained from Space Science Flight Investigations", dated May 2, 1978, in satisfying this function which was first established in a NASA Policy Directive, dated January 7, 1967 (NPD 8030.3).  Among other important modifications, NMI 8030.3A established the requirement for all space flight projects to develop Project Data Management Plans (PDMPs).  As defined in NMI 8030.3A, the PDMP was essentially conceived as a data archiving plan.  The increasing complexity of NASA science investigations and the volume of data that they generate (among other factors) emphasizes the need for increased emphasis and priority for data management planning early in the project's life.  Additionally, these data management planning activities must address the total flow of research data not just archiving.  This Program Directive expands the scope of the PDMP to include planning for data management throughout the project planning and implementation phases.
2.	Scope
This program directive is applicable to the management of all science data resulting from Office of Space Science and Applications sponsored research missions and programs.
3.	Policy
a.	Science data generators and users shall serve as a primary source of requirements, as well as final judge of the quality and value of scientific data.  Advice and guidance shall be obtained from the science and applications research community in the planning and implementation of NASA's data management systems.
b.	NASA shall establish and maintain archives to preserve and make accessible all valuable NASA science data and information.  This system of data archives shall include easily accessible information about NASA's data holdings, guidance, and aids for locating and obtaining the data.  A review process, including scientific community representation, shall be established to determine what data should be archived and to assure conformance with completeness and quality standards.  
c.	National and international standards for media, formats, and communication of data sets shall be used to the greatest extent possible.  NASA shall participate in the development and implementation of standards.   NASA unique standards shall be used only if adequate national or international standards are lacking.  The intent of this policy is to standardize the interfaces between the users and NASA's data and information systems, not to standardize the systems themselves.
d.	Project, discipline, and OSSA-wide data management activities shall be reviewed periodically to assess status and progress relative to Agency and OSSA goals, objectives and standards, and the needs of the science community.  Once archived, data sets and supporting information shall be periodically reviewed to assess their value for continued retention by NASA.  This process shall also prevent the loss of important data sets.  
e.	All data being captured by NASA science projects and space flight missions shall be addressed in a Project Data Management Plan (PDMP) to assure the availability of data and supporting information on a timely basis for use by the science community.  The formal definition (non advocate) review or equivalent mechanism conducted prior to a project receiving new start approval will assess data management plans as well as spacecraft development, instrument plans, operations plans, etc.  After new start and budget approval a formal Project Data Management Plan will be prepared and approved coincident with the Project Plan signed by the Associate Administrator and Field Center Director.  Project Data Management Plans must be updated as significant changes occur that impact the project's plans for data management, and PDMPs should be reviewed periodically to determine if updates are required.  For programs in which selected investigators have initial periods of exclusive data use, data should be made openly available as soon as that period expires.  In such cases, the duration of all exclusive use periods shall be explicitly defined.
f.	NASA shall periodically conduct a review of its data repositories and archives to determine the state of data and to assure conformance with applicable government standards for data storage.
g.	Recognizing the pivotal importance of technology in meeting its future needs for data and information systems, OSSA shall establish an active process to maintain an awareness of emerging applicable technologies, infuse them into its systems, and stimulate new technology development where warranted. 

4.	Responsibilities and Authorities
a.	Associate Administrator for Space Science and Applications 
	The Associate Administrator for Space Science and Applications is responsible for maintaining and ensuring the implementation of NASA's data management policy, including issuing implementing instructions and guidelines.
b.	Assistant Associate Administrator for Science and Applications 
	The Assistant Associate Administrator for Science and Applications shall serve as chairperson of the Information Systems Management Board, which is chartered to coordinate OSSA's data management activities, and to identify issues, set priorities, and provide recommendations to the Associate Administrator for Space Science and Applications on these activities.    
c.	OSSA Discipline Division Directors 
	The Directors of OSSA's Science Discipline Divisions are responsible for the overall administration of their Division's data management activities in accordance with this Program Directive and the decisions of the Information Systems Management Board.  Data acquired from both flight projects and non-satellite programs will be addressed as part of this responsibility.  The primary objective of this activity is to assure the continuing value of OSSA's science data by providing data management procedures, systems and services that are responsive to the needs of the project, discipline, NASA, and broad research communities.
d.	OSSA Flight Systems Division Director 
	The primary responsibilities of the Information Systems Program within OSSA's Flight Systems Division are to formulate and coordinate OSSA wide data management policy and to provide the supporting infrastructure across the discipline efforts.  This includes providing a broad range of data management capabilities which transcend discipline-specific data management activities and serving as OSSA's point of contact for data management activities.  

Appendix B:  Project Summary Tables

The following tables are the recommended formats for presenting summary data of the project.  They are organized into three tables, one each for parameters for the overall project, for each instrument, and for each data set.  For an example of data entered in these tables for an existing project, refer to Appendix C.  Table B-1 presents the suggested format for overall summary of parameters at the project level.
Table B-1	Project summary parameters.

	Mission Summary	Parameter Values	
	Project Name		
	Orbit Description	inclination, apoapsis, periapsis, period	
	Launch Date		
	Launch Vehicle		
	Nominal Mission Duration		
	Potential Mission Life		
	Data Acquisition		
	On-Board Data Storage Capacity		
	Continuous Data Acquisition Rate		
	On-Board storage saturation		
	Target pointing duration		
	Target re-orientation period		
	Attitude control accuracy		
	Attitude determination accuracy		
	Space to Ground Communications		
	S/C Link	Frequency 
Polarization 
Path		
	Data Rates [kbps]

Forward		Peak
	Average
Contact Frequency

Return		Peak
	Average
Bit Error Rate
Contact Frequency
Average Duration		
	Telemetry Processing		
	Annual Volume input		
	Throughput [kbps]	
	Peak
	Average		
	Annual Volume output		
	Data Distribution Time		
	Support Facilities		
	Identification	Description	

A recommended format for summarizing parameters relevant to all instruments for the project is shown in Table B-2 below.  This includes summaries of the instruments themselves, and the science resources required for each instrument.
Table B-2	Instrument summary parameters.

	Instrument Summary	Instrument "A"	Instrument "N"	
	Detectors
Geophysical Phenomenon/ Parameters Measured/Derived			
	Number and type of Detectors			
	Total Sensitive Area			
	Field of View			
	Energy/Wavelength Range			
	Energy/Wavelength Resolution			
	Time Resolution			
	Positioning			
	Sensitivity			
	Data Rate			
	Science Resources	Instrument "A"	Instrument "N"	
	Facility			
	Organization			
	Location			
	Functions/Capabilities			

The recommended format for summary of data products, which can be aggregated as appropriate to the instrument and project levels, is shown below in Table B-3.
Table B-3	Data product summary parameters.

Appendix C:  Examples of Project Summary Tables

This appendix provides examples of actual data entered into the project summary tables.  The project summary tables shown are for the Gamma Ray Observatory (GRO).  The overall project summary table will be shown first in Table C-1, followed by the instrument summary in Table C-2, then data set summary in Table C-3.
Table C-1	GRO project summary parameters.

Table C-2	GRO instrument summary parameters.

Table C-3	GRO data set summary parameters.