**Reference:** SDS SRR Handout, p 25

**Title:** SDS Science Acquisition

**Action:**

I have a concern about the scope and timing of funding for field
campaign and in-situ activities for science calibration. A well-planned,
phased program needs to be put in place.

**Rationale:**

When I was at NASA HQ as SeaWifs Program Manager, launch delays caused
cancellations of campaigns and were disruptive to the science community.
On the other hand, under or late funding would delay algorithm
development and compromise algorithm integration.

**Response:**

**Status:** Rejected

**Key Words:**

**Reference:** SDS SRR Handout, p 110

**Title:** SDS Data Distribution

**Action:**

I have a concern about the requirement for an \"electronic user
interface that allows queries.\" This may be an implementation issue,
but it seems that the interface has to be carefully monitored and
selected. This is the systems \"face\" to the user and a bad one can
seriously damage utility.

**Rationale:**

The EOSDIS graphical user interface was poorly designed and badly
damaged the utility and credibility of the system. It may be better to
provide APIDs or other interface information to allow users to implement
their own interface or allow third-party interfaces to be developed.

**Response:**

A requirement will be added to the specification for the provision of
software interfaces which can be accessed by direct calls. That
capability will allow a developer to create a custom GUI using the
internal functions of the SDS. The requirement for the user interface
will be retained since it would be impossible to test the system without
a functioning interface.

**Status:** Closed

**Key Words:**

**Reference:** Requirements Spec p 3-16

**Title:** Algorithms or Code ?

**Action:**

Clarify requirement 3.5.1.2A.

**Rationale:**

This requirement specifies that the government will provide
\"algorithms\" to the SDS contractor. If this includes code, it should
specify code. If it includes only paper documentation it should probably
specify ATBD.

**Response:**

The specification will be revised to clarify that government-supplied
algorithms will be provided in the form of ATBDs and/or research code
used by the government to validate the ATBDs. If the government uses
research code to validate the ATBDs, this code will be provided to the
contractor as reference material.

**Status:** Closed

**Key Words:**

**Reference:** Requirements Spec 3.5.2.1A

**Title:** Remove \"operator\" terminology

**Action:**

Remove the term \"operator\" from requirement 3.5.2.1A (p-3-21). Also
remove the term in other requirements throughout the spec.

**Rationale:**

The term \"operator\" implies an implementation. Also most data
distribution will likely be from computer to computer.

**Response:**

The specification will be revised to delete the term \"operator\" from
the requirements addressing product subscriptions and data requests to
the CDMS, the IDPS, and the ADS. Reference to an operator will also be
removed from the requirement for order prioritization.

**Status:** Closed

**Key Words:**

**Reference:** p 3-19 Requirements Spec

**Title:** Remove \"personnel\"

**Action:**

Remove \"personnel\" from this requirement.

**Rationale:**

Using the term \"personnel\" implies implementation. Also - I assume
that the distribution will be from computer to computer; not computer to
person.

**Response:**

The specification will be revised to delete the term \"personnel\" from
the requirements in Section 3.5.1 with one exception; Paragraph
3.5.1.6.1.a will still require an electronic user interface that allows
SDS-C personnel to make queries on and place orders for SDS mission data
and EDRs. However, the specification will be revised to add a similar
interface requirement for computer to computer requests.

**Status:** Closed

**Key Words:**

**Reference:** SDS-C Requirements Spec and Conops.

**Title:** Algorithm Transition to IDPS

**Action:**

Add Requirement to handle transition of SDS-C Algorithms/software to
IDPS.

**Rationale:**

Although the ops concept specifically talks about transition of
algorithms/software from SDS-C to IDPS, there are no requirements for
this in the spec.

**Response:**

It is envisioned that the transition of the algorithms from the SDS to
the IDPS will follow a set of inter-agency Government manual processes
and configuration management procedures. This is a programmatic function
that is not levied upon the development contractor.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** Availability vs. Excess Capacity

**Action:**

Study maintainability and availability reqs vs. excess capacity cost. If
I can meet production requirements and time lines by being able to
\"catch up\" after down time it may be cheaper not to be so reliable.

**Rationale:**

Very high reliability is generally very expensive. Other reqs may be
better (cheaper) met with more capacity and less reliability.

**Response:**

The RMA numbers have been reviewed post-SRR and determined to be
reasonable for the type of data system needed for SDS. We are leaving as
much trade space to the contractor as possible in this area.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** Volume vs. CPU Requirements

**Action:**

Need to define a test suite of products and data sets (MODIS surrogate)
on which throughput tests can be done and proposer's approach measured
against.

**Rationale:**

You mix volumes and times and processing requirements. They are not
interchangeable.

**Response:**

A test suite of products and data sets based on MODIS will be
incorporated as part of the overall SDS test program. An SDS Integration
and Test Plan and the associated detailed procedures will be developed
during the course of the SDS implementation. It is envisioned that MODIS
data, to the extent practical, will be used in verifying the
requirements for the SDS, including performance requirements, i.e.,
throughput.

Regarding the comment in the rationale, the processing requirements will
be reworded to indicate volumes and timelines.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** Interface Definitions

**Action:**

Interfaces, especially formats and data distribution method (electronic
vs. media) need to be better defined. Too many interfaces are
inadequately defined.

**Rationale:**

**Response:**

Interface Requirements Definition (IRD) documents exist for the primary
SDS interfaces: IDPS, ADS, and C3S. These IRDs define distribution
methods (e.g., electronic) for data items. Interface Control Documents
(ICDs) will be generated during the SDS implementation phase. These ICDs
will specify formats and any other pertinent details. The RFA also
pertains to SDS handling of operational field campaign data. These
operational field campaign data are expected in a variety of methods
(media and electronic) and formats. CDMS has the requirement to ingest
operational field campaign data from ancillary data sources and to
enable an operator to manually input these data. Once requirements for
the specific Climate Data Records are solidified, IRDs and ICDs will be
developed with relevant ancillary data systems for ancillary data
(including operational field campaign data) needed by SDS. CDMS will be
able to handle electronic distribution; the operator manual entry
requirement will cover any hard copy data or reading of magnetic and
optical media. SDS intraelement interfaces will be defined during the
SDS design phase.

**Status:** Closed

**Key Words:**

**Reference:** 3.1.1.1.5 Data Backup

**Title:** Data Backup

**Action:**

If online storage resides also in neartime storage, you don't need
weekly backup. On loss, just retrieve from neartime.

**Rationale:**

An extra 45TB weekly full and daily incremental is very expensive,
especially if you already have copies neartime.

**Response:**

Raw measurement data will be retained in SDS in addition to the short
term cache of processed data which is used to make the 8/16/32 day
products. We are evaluating the allocation of storage to both on-line
and near-line technologies such as RAID and DLT \"jukeboxes.\" In the
case that near-line storage is used, weekly backup is not necessary. We
propose rewording the requirement to require backups only if data is not
duplicated elsewhere on independent media.

**Status:** Closed

**Key Words:** storage backup online

**Reference:** Chart p 70

**Title:** Level 1B Data Processing

**Action:**

Please validate and clarify the requirement for 45 days of cached
memory. In the context of the ability to flexibly conduct reprocessing
in multiple threads, diverse sources, etc.

**Rationale:**

MODIS ocean processing requires three 8-day weeks of data available at
the same time. A 3-x system doing ocean processing and reprocessing
would require 72 days of storage just to do that job.

**Response:**

The requirement is for 45 \"calendar days\" of storage, not 45
\"data-days\". Some data will have multiple instances within the 45
calendar day period as a result of reprocessing. Conversely, not all
data will have a 45 day life. We are considering the addition of a
requirement to provide capability to set data \"lifetimes\" for
individual data items (pending prototyping results). Short term storage
will be sized to allow the worst case of reprocessing and full data
latency.

**Status:** Closed

**Key Words:**

**Reference:** Chart p 102 & others

**Title:** Availability of system for reprocessing

**Action:**

Please explain the requirements for availability/reliability of the
system for reprocessing.

**Rationale:**

The charts repeatedly address availability/reliability of the system for
processing. This implicitly allows for the 2x reprocessing capability to
be used to assure that processing is done. There is no apparent
constraint on how much of the reprocessing capacity is used. Therefore,
the 2x reprocessing could be effectively reduced to 0.

**Response:**

Availability and reliability are defined at the system level and
therefore include the 2X reprocessing capacity.

**Status:** Closed

**Key Words:**

**Reference:** Chart p 107

**Title:** Provision of Code for Level 1B and Geolocation

**Action:**

Please modify the description of how LIB (geolocation) is implemented.
Current text says the SDS utilizes algorithms supplied by the
government. They should utilize research code (or perhaps operational
code) supplied by the government. The code cannot be created by
programmers working from ATBD's. Also, allow for use of the vendor
supplied SDR code in lieu of a government provided Level 1B.

**Rationale:**

**Response:**

The specification will be revised to specify that the
government-supplied algorithms for Level 1B data, RDR decompression, and
CDRs will be provided in the form of ATBDs and/or research code used by
the government to validate the ATBDs. The usage of vendor-supplied SDR
code is allowed by the specification as long as the code is provided to
the SDS-C contractor by the government. The original source of the code
is irrelevant.

**Status:** Closed

**Key Words:**

**Reference:** Chart #60

**Title:** Changed to L2s (2 of 4)

**Action:**

Determine requirement for electronic distribution (currently at 6x
ingest) taking into account that VIIRS data volume is much larger than
CrIS or ATMS volumes.

**Rationale:**

If 1/3 of the 20 science teams want all VIIRS data, this will take all
the 6x distribution capacity. If more than 1/3 of the science team wants
VIIRS data, this breaks the system. Need better estimate or allow for
flexibility.

**Response:**

Based on discussions with the Interim Science Panel, it is anticipated
that each CARS will have an emphasis on particular areas of available
data. For example, a CARS producing land CDRs would only require the
land bands from the VIIRS. Using MODIS as a guide, the VIIRS instrument
bands were roughly apportioned to the various Climate Data Products. The
worst case (Ocean Color) uses 9 of the 36 available bands, or 25
percent. The 6x requirement allows each of the 20 scientists to access
1/3 of the data continuously.

**Status:** Closed

**Key Words:** electronic distribution

**Reference:** Review p. 59-60; SDS Rqmt 3.6.6.3

**Title:** Level 2 for EDR Validation

**Action:**

Add a change proposal to the Level 2s to add a requirement to cover the
EDR validation being performed by SDS DCAVS.

**Rationale:**

The validation of EDRs as potential CDRs (SDS requirement 3.6.6.3) is
not traceable to a level 2 requirement.

**Response:**

**Status:** Rejected

**Key Words:**

**Reference:**

**Title:** Increase IDPS-short term storage

**Action:**

Evaluate the advantage of increasing the 24-hr storage at IDPS on
reducing long-term costs at the CDMS.

**Rationale:**

Disk space is cheap and adding 150 Gbytes to IDPS may significantly
reduce the requirements on CDMS.

**Response:**

This is a system level trade between reduced RMA and operational
requirements for SDS and increased storage in IDPS. The RMA numbers have
been reviewed post-SRR and determined to be reasonable for the type of
data system needed for SDS. The 24 hour limit on IDPS did not
significantly drive the RMA requirements. The 24x7 initial operational
requirement for SDS is derived from experiences with similar systems. It
is envisioned that, during the course of SDS operations, 24x7 staffing
requirements will be relaxed. The operational requirements were not
driven by the IDPS 24 hour storage limitation.

**Status:** Closed

**Key Words:** RMA

**Reference:** Chart 110

**Title:** Machine-to-Machine

**Action:**

\"Electronic User Interface\" should include support for
machine-to-machine data distribution functionality -- no web pages or
people in the loop.

**Rationale:**

Science processing & QA facilities will want to pull data from the SDS
archive by machine request. Solutions like unitree/ftp would be idea.

**Response:**

The specification will be revised to include a requirement for an
electronic interface that allows other portions of the SDS-C to make
queries on and place orders for specified SDS mission data and EDRs
based on metadata contents.

**Status:** Closed

**Key Words:**

**Reference:** SDS-C Segment Characteristics p.99

**Title:** COTS and Reused Software Requirements

**Action:**

Clearly specify requirements for Commercial-Off-The Shelf (COTS) and
reused software. It is very likely COTS software could be used. You may
have very limited insight into its design and reliability and it could
adversely affect System Operational Availability.

**Rationale:**

There are clear requirements (EIA/1EEE J-STD-016) for newly developed or
highly modified software, but no requirements whatever on reused or COTS
software development or documentation. This is getting other projects in
trouble. There are serious issues in developing "glue ware" to make COTS
packages interoperable.

**Response:**

The specification will be revised to add a requirement that any reusable
software products used in the SDS-C, including COTS software products,
shall be incorporated into the SDS-C in accordance with Paragraph 4.2.4
and Annex D of EIA/IEEE J-STD-016. The Statement of Work (SOW) will also
require the contractor to identify and evaluate reusable software
products (including COTS products) utilizing a list of evaluation
criteria provided in the SOW, and to support all COTS software versions
incorporated into the deliverable SDS-C at the time of delivery.
Paragraph 3.2.5.2.1 of the specification will be revised to require that
COTS software shall not be modified and shall not contain expiring keys.
Although these changes will not eliminate all of the potential problems
associated with the use of COTS software, they should reduce them.

**Status:** Closed

**Key Words:** COTS

**Reference:** Many

**Title:** Design Goals vs. Requirements

**Action:**

While design goals are very clearly identified (a good thing), they do
not belong in the requirements documents on technical specification. Put
design goals in the \"Instructions to the Bidders\" part of the
contract, if you are going to make selections based on them - or else
make them requirements.

**Rationale:**

There is no reason why a contractor will go to the extra effort and
expense to meet design goals (e.g., 900%, 0.999 availability) when the
explicit requirements require far less.

**Response:**

The SOW and the RFP (Sections L and M) will make it clear to the bidders
what the minimum acceptable performance is. The bidder\'s ability to
meet the \"Goals\" is a significant discriminator for use by the source
selection board and will be appropriately identified as such in Section
M of the RFP.

**Status:** Closed

**Key Words:**

**Reference:** SDS Context Diagram, p.33

**Title:** System - level Anomaly Resolution Flowdown to SDS

**Action:**

Describe how system - level Anomaly identification and resolution will
flow down and apply to the Science Data System. Show how anomaly data
flows through the Science Data System. Describe the role of the Science
Data System in identifying and resolving system and science data
anomalies.

**Rationale:**

The Science Data System may be useful/needed to identify or resolve some
system - level anomalies. There may be problems with science data
processing itself, affecting and end-user data. System needs to be able
to distinguish between Spacecraft, Instrument, Science Data Processing
problems, etc.

**Response:**

System level issue

**Status:** Deferred to MSDR

**Key Words:**

**Reference:** Throughout

**Title:** Scalability Definition

**Action:**

We heard numerous references to \"scalability\" used in several
different contexts and with subtle differences in meaning. Define
precisely what \"scalability\" means to the project; what the
requirement is for scalability and how it will be measured. How will
\"scalability\" be verified?

**Rationale:**

ESDIS also used \"scalability\" as a buzzword but failed to achieve it
(e.g. they have multiprocessor computers but can't \"afford\" to upgrade
the processors to achieve greater performance.

**Response:**

Scalability is the ability of the system\'s architecture to adapt to a
change (increase or decrease) in the demands being placed upon it.
Specific scalability requirements being levied on the SDS-C include the
ability of the segment to support the future incorporation of additional
CARS elements, DCAVS elements, and CCS workstations, as well as to
support the addition or deletion of Level 1B and/or CDR algorithms. It
is agreed that the requirement in Paragraph 3.2.6.d of the specification
addressing the ability of the SDS-C design to allow for development of a
SDS - Lite is not a scalability requirement, and the specification will
be revised to delete it. It is also understood that there will be
difficulties involved in measuring the scalability of the system. In an
attempt to reduce this problem, the specification will be revised to
state that: (1) the addition or deletion of algorithms shall not require
changes to the architectural design of the SDS-C, and (2) the SDS-C
design and architecture shall provide a growth path for the
incorporation of additional elements and workstations. All of the
scalability requirements will be verified by analysis.

**Status:** Closed

**Key Words:** scalability

**Reference:** SDS-C Rqmnt Spec

**Title:** Non-Functional & Performance Requirements

**Action:**

Consider moving/removing non-function or non-performance requirements
from spec. Some of these are design or SOW items (e.g. 3.5.1.8 -
workstations - not testable as written)

**Rationale:**

Operational reqs, design reqs embedded w/ F&P reqs. - becomes confusing.

**Response:**

The specification will be reviewed and, where appropriate, requirements
will either be deleted or moved to the SOW. However, the majority of the
operational and design requirements currently in the specification must
remain in the requirements section of the document. Since these
requirements affect the design of the SDS-C, they must be listed in the
specification and, since they are requirements, they must be listed in
the requirements section.

**Status:** Closed

**Key Words:**

**Reference:** SDS-C Reqs. Spec

**Title:** Level 3 Reqs Trace to Level 2s

**Action:**

Appendix 20 shows L3 SDS reqs trace to NPOESS MRS. This is incorrect.
Traces to L2s in NPP MRS.

**Rationale:**

Document indicates trace is to NPOESS vs NPP.

**Response:**

Appendix 20 will be revised to correctly reference the NPP MRS and the
NPP SDS-C Requirements Specification.

**Status:** Closed

**Key Words:**

**Reference:** SDS-C Reqs Spec

**Title:** Move \"Goals\" Out of SDS Spec

**Action:**

Consider removing \"goals\" out of spec and include them in RFP. Reqs
for reprocessing (2x - goal of 9x) and Ao (.99 - goal of .999), ingest
(.999 - goal .995)

**Rationale:**

\- Ensure specs are explicit; not confused w/ in spec

\- Relocate to RFP as goals/discriminators for bidders, become cost
trades for consideration by bidders.

**Response:**

The SOW and the RFP (Sections L and M) will make it clear to the bidders
what the minimum acceptable performance is. The bidder\'s ability to
meet the \"Goals\" is a significant discriminator for use by the source
selection board and will be appropriately identified as such in Section
M of the RFP.

**Status:** Closed

**Key Words:** RMA

**Reference:** p. 51

**Title:** ADS Fall-Back Options

**Action:**

What are fall-back options if actual ADS implementation cannot meet SDR
reprocessing rates?

Will a co-location option be maintained as a contingency?

**Rationale:**

Softness in ADS represents important project risk, as all \"definitive\"
climate data records will only be produced correctly with \"improved\",
reprocessed data.

**Response:**

Programmatic issue

**Status:** Rejected

**Key Words:**

**Reference:** page 17

**Title:** Missing Responsibility for Reprocessing EDRs

**Action:**

Coordinate with IPO to ensure that reprocessing of important EDRs will
take place to support NOAA's growing (operational) climate
responsibilities.

**Rationale:**

1\. NPP science, science team not responsible for EDRs

2\. EDRs only produced with 20-minute-timeliness data

3\. How will important climate related EDRs (e.g. SST, Temp and moisture
profiles) be corrected through a reprocessing step once calibration &
geolocation are improved and ancillary data made available.

**Response:**

**Status:** Rejected

**Key Words:**

**Reference:** p. 116 - 121

**Title:** Climate Calibration System Characteristics

**Action:**

The characteristics described in this section include development and
operational activities which mix SDS-C development contractor, SDS-C
operations contractor, government, and science team responsibilities.
The implication is that primary responsibility is on the contractors.
This is not likely to be correct.

**Rationale:**

Calibration activities will be primarily a responsibility of the science
team, and its selected calibration team.

**Response:**

The requirements in this section are to provide the tools to support the
climate calibration activities for NPP. The next step in the development
process is to allocate these "system" level requirements to the
software, hardware, operations, and analyst components of the system.
The results of this activity will be presented during the SDS-System
Design Review which will be held in early 2002.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** Requirements Verification Traceability Matrices

**Action:**

Provide complete traceability between all levels of requirements (Level
1, II, III, etc.). Provide Requirements Verification Traceability
Matrices showing each requirement and how it will be verified (method of
verification)

**Rationale:**

It is not clear whether certain requirements are slowed down, which
requirements are derived and whether some requirements are
testable/verifiable.

**Response:**

**Status:** Withdrawn

**Key Words:**

**Reference:** SDS SRR / CCS, Chart 38

**Title:** Pre-Launch Characterization of Calibration at CCS

**Action:**

Will CCS be ready early enough to prevent a large delay for the
pre-launch characterization and calibration of NPP instruments. Data
from VIIRS, CrIS, and ATMS EDUs have to be analyzed for characterization
and calibration way before launch.

**Rationale:**

**Response:**

The functionality and approximate need dates required should be included
as part of the NPP Calibration Plan. If identified early enough it may
be possible to include the needed functionality in early builds of the
system.

**Status:** Closed

**Key Words:**

**Reference:** Chart 82

**Title:** Climate Data Processing

**Action:**

Please identify the on line storage required for ancillary data in order
to support 1X processing and 2X reprocessing for typical and high volume
ancillary data.

**Rationale:**

**Response:**

Using Terra as a basis, we have sized the on-line storage to accommodate
the ingest of ancillary data. If new ancillary data is needed for
reprocessing, the CDMS will retrieve the data and place it in on-line
storage. Any ancillary data not retrieved within the prior 45 days is
available in the offline storage.

**Status:** Closed

**Key Words:** 1X, 3X

**Reference:** SDS- DCAVS Characterization

**Title:** NPP Cal Team I/Fs

**Action:**

Please provide clear interfaces and/or relationships between the NPP
calibration team, the NPOESS / NPP EMD contractor and the NPP instrument
vendors.

**Rationale:**

Completion of this action item is probably contingent upon official
contractual arrangements defined between EMD contractors and instrument
vendors. This is a pending IPO action.

**Response:**

Passed on to Science Office

**Status:** Rejected

**Key Words:**

**Reference:** SDS Reqs. Spec. Pg.3-28 Section 3.5.3.9

**Title:** CCS Location

**Action:**

Change requirement to The CCS shall not have any CDMS collocation
dependencies.

**Rationale:**

There may be better wording, but the point is that the requirement
should imply that the CCS may or may not be remote to CDMS, regardless
of where the CCDMS is. The way it is written, if the CDMS is at GSFC,
then the CCS may not be. Note: If you like it just may be easier to say:
'The CCS shall be located at GSFC.' The way I wrote the requirements
above, the resulting implementation may be more expensive than it needs
to be (i.e. when they are co-located). Unless there is room for
negotiating, a cheaper co-location solution (that means waiver the
requirement altogether.)

**Response:**

Even if the CDMS is located at GSFC as is currently being directed, it
will not necessarily be located in the same room as the CCS. For this
reason, the specification is requiring the CCS design to be based on a
remotely located (i.e., not located in the same room) CCS. Using this
approach, any future changes to the location of the CDMS will not impact
the CCS design.

**Status:** Closed

**Key Words:** collocation

**Reference:** SDS Ops Concept, Pg. 3-9, Section 3.5.1.6.1

**Title:** Data Reduction for Distribution

**Action:**

Add the following two requirements:

1\. The CDMS shall provide data reduction capabilities, such as
parameter, temporal, parameter subsetting, subsetting on-demand.

2\. The CDMS shall provide an environment in which user-supplied data
reduction software can be integrated.

**Rationale:**

With the huge amount of data available, CDMS data users will like to
work with more manageable amounts of data. These are two popular ways of
achieving data distribution management in terms of making the data more
accessible.

**Response:**

Paragraph 3.5.1.6.1.a of the specification requires the CDMS to allow
queries and orders based on metadata contents and/or browse images. In
addition to this, the specification will be revised to add a requirement
for the CDMS to provide a data subsetting capability that allows
subsetting based on geographic area coverage, channels (bands), date
and/or time of data collection, and additional metadata contents as
required. The specification will also be revised to include a
requirement for the CDMS to provide documented, callable software
interface routines that allow external graphical user interfaces or
programs to submit data queries and/or requests, and to receive data.

**Status:** Closed

**Key Words:**

**Reference:** SDS Requirement Specifications, Pg. 3-18

**Title:** Storage Specification

**Action:**

Clarify requirement 3.5.1.4e

**Rationale:**

The requirement needs to be spell out the specification of the 3.2PB
value. I understand from the presentation that this value was for 2
years of compressed data. Also note that the Conops specifies 4PB of
storage (pg. 3-1). If should be clear from the spec what the value 3.2PB
refers to, and both documents should have the same value.

**Response:**

The specification will require 2.0 petabytes (TBR) of SDS mission
storage capability upon delivery and will clarify that this capacity
allows for two (2) years\' worth of SDS mission data storage. The
remaining six (6) years\' worth of storage capability will be addressed
in a scalability requirement. The ConOps will be revised to reflect
these same values.

**Status:** Closed

**Key Words:** storage data

**Reference:** SDS Reqs. Spec 3.5.1.6.1b

**Title:** CDMS Distribution \"rate\"

**Action:**

Change the wording of requirement 3.5.1.6.1b to clarify the requirement.

**Rationale:**

The term \"rate\" is ambiguous in this requirement. (Rate usually
defined as volume per unit time.) Perhaps \"rate\" should be \"volume\"
in this requirement.

**Response:**

Requirement 3.5.1.6.1.b will be reworded to state that the CDMS shall
have the capability to electronically distribute, on a daily basis, a
data volume equal to six (6) times the IDPS data ingested into the SDS-C
per day.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.1.1.1.4, items b, c and
d

**Title:** Remove planning and scheduling requirements

**Action:**

1\. Experience on ECS suggests that data processing planning and
scheduling are operationally unnecessary capabilities that result in
inefficient operations. ECS is currently evolving to a data driven
approach. Recommend that these requirements be dropped and that the
contractor be allowed to determine how best to support the other
processing and reprocessing requirements.

**Rationale:**

**Response:**

The intent of the SDS-C specification is to reflect a data driven system
as well. The requirement for planning and scheduling will provide the
capability to establish prioritization of tasks (scheduling) and the
capability to establish rules for processing in the face of incomplete
data (planning). The responders will be encouraged to propose
alternative implementations for consideration if the specified
requirements can be achieved in another manner.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.1.1.1.5

**Title:** Remove online storage backup requirements

**Action:**

2\. Data backups may not be necessary for the online storage. It may be
possible for the contractor to ensure that this data is better protected
and more available by archiving the data as it is placed in the online
storage. Recommend that online storage backup requirements be removed
and that they be replaced with a requirement that the online storage can
be recovered in 24 hours (if that is what is needed). Other requirements
already ensure that the online storage data be archived.

**Rationale:**

**Response:**

Raw measurement data will be retained in SDS in addition to the short
term cache of processed data which is used to make the 8/16/32 day
products. We are evaluating the allocation of storage to both on-line
and near-line technologies such as RAID and DLT \"jukeboxes.\" In the
case that near-line storage is used, weekly backup is not necessary. We
propose rewording the requirement to require backups only if data is not
duplicated elsewhere on independent media.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc

**Title:** Reduce overall availability requirement

**Action:**

3\. SDS Central Requirements Specification, Section 3.1.5, item a - The
overall availability requirement of 0.99 is likely to push SDS costs
unnecessarily high. Experience with ECS has shown that a much lower
availability value of 0.96 is adequate for data management from multiple
high priority missions while at the same time allowing considerable
savings. 3. Recommend adopting a lower overall availability requirement.

**Rationale:**

**Response:**

A reliability, maintainability and availability (RMA) requirements
analysis was performed for the SDS. This analysis included a review of
the SDS functional capability requirements as well as surveys of the RMA
performance for commercial off-the-shelf (COTS) computer equipment and
large commercial data centers. In the analysis it was stated that the
currently specified operational availability (Ao) requirement of 0.99
for the SDS-C represents a reasonable compromise between industrial
practice and government practice. A larger reduction of the industry\'s
availability norm (typically 0.999 for a commercial data center) to a
lower value (e.g., 0.96) would be a severe setback from industry
practice.

**Status:** Closed

**Key Words:** RMA

**Reference:** SDS Specification Doc

**Title:** Lower ingest and storage requirement

**Action:**

4\. SDS Central Requirements Specification, Section 3.1.5, item b -
Requiring that the ingest and data storage capabilities for all
interfaces have an availability of 0.999 is likely to push SDS costs
unnecessarily high, especially for lower criticality interfaces such as
the CARS interfaces. Recommend lowering the overall ingest and storage
requirement to 0.96, which ECS experience suggests is adequate, but
keeping the 0.999 availability requirement for ingest and storage of
IDPS and C3S provided data.

**Rationale:**

**Response:**

The specification requires the SDS-C as a whole to have an operational
availability (Ao) of 0.99. The 0.999 Ao requirement only applies to the
portions of the SDS-C that ingest and store data from external sources
such as the IDPS, the C3S and the Ancillary Data Systems.

**Status:** Closed

**Key Words:** RMA

**Reference:** SDS Specification Doc, Section 3.1.7, item a

**Title:** Access to data objects

**Action:**

5\. The requirement to be able to restrict each users\' access to
individual data items may result in unnecessary SDS costs. Recommend
that the requirement be clarified to allow each users\' access to be
restricted to individual system data objects, not product/data record
objects.

**Rationale:**

**Response:**

The specification will be reworded to require the capability to restrict
user access at the top data object level. In practice, this restriction
will most likely be imposed as a \"delete/modify\" limitation to data
items. Level 1B Data records and Ancillary Data are examples.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.1.7, item b

**Title:** Information integrity requirement

**Action:**

6\. The ADS and other IRDs do not appear to specify that these systems
will provide the information needed to support the information integrity
and source verification requirement (see ADS IRD Sections 4.7 and 4.8,
and IDPS Sections 4.5 and 4.6). Furthermore, satisfying this requirement
may result in unnecessary costs for the SDS. Recommend modifying the
requirement to state that the SDS will verify that all information are
sent by the appropriate system.

**Rationale:**

**Response:**

Paragraph 3.1.7.b of the specification will be revised to require the
SDS-C to verify that all information transferred into the SDS-C and
between SDS-C elements comes from appropriate sources.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.2, item I

**Title:** Add science quality assessment metadata

**Action:**

7\. Recommend expanding the list of metadata items to include science
quality assessment metadata or add a separate requirement for this type
of metadata.

**Rationale:**

**Response:**

Science quality assessment will be added to list of required metadata
for both the Level 1B data (Paragraph 3.5.1.2.i) and the CDRs (Paragraph
3.5.2.2.d).

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.2

**Title:** Metadata compatible with ECS

**Action:**

8\. Recommend adding a requirement that the metadata model be compatible
with the ECS metadata model to facilitate user access to the long-term
climate data record and reduce eventual issues for long-term archive of
the data.

**Rationale:**

**Response:**

The specification will be revised to include a requirement that the
metadata models for the Level 1B data and CDRs be compatible with the
ECS metadata model.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.2

**Title:** Use EOS-HDF format for L1B data

**Action:**

9\. Recommend adding a requirement that the L1B products use EOS-HDF
format. This will make it easier for long term climate researchers to
exploit L1B data across the major EOS missions.

**Rationale:**

**Response:**

The requirement to use the EOS-HDF format has not been identified at
this time. While the EOS-HDF format may provide ease in analysis of past
EOS missions, the format may not be used by the IDPS or ADS which will
be the source of data for future climate products. We have deferred
selection of a data format as an ICD issue and will be looking at the
recommendations made by the IPO TSPR contractor, ADS, and the selected
NASA science team before making a format determination.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc

**Title:** Use EOS-HDF format for CARS data

**Action:**

10\. Given the similarities between the NPP instruments and the Terra
and Aqua instruments and the demonstrated ability of the EOS-HDF format
to support the data products from these instruments, recommend adding
requirements that the data generated by the CARS and DCAVS use EOS-HDF
format. This will make it easier for scientists to use data across these
missions.

**Rationale:**

**Response:**

The requirement to use the EOS-HDF format has not been identified at
this time. While the EOS-HDF format may provide ease in analysis of past
EOS missions, the format may not be used by the IDPS or ADS which will
be the source of data for future climate products. We have deferred
selection of a data format as an ICD issue and will be looking at the
recommendations made by the IPO TSPR contractor, ADS, and the selected
NASA science team before making a format determination.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.4

**Title:** Interoperability with EOS

**Action:**

11\. Recommend adding an item to require that the CDMS support
interoperability with the EOS Data Gateway (EDG) and EOS Clearinghouse
(ECHO) systems. This will enable users to employ their standard user
interfaces in accessing the data and allow cross-mission searches and
orders for NPP users.

**Rationale:**

**Response:**

We will be working with ESDIS and NewDISS personnel in the prototyping
of the interfaces between the CARS/DCAVS/CDMS. As part of this
prototyping process, it is anticipated that the standards for future
Earth Science Enterprise data systems will emerge. We will adopt those
emerging standards.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.4, item e

**Title:** Reduce EOC data storage volumes

**Action:**

12\. Given the proposed acquisition strategy of the contract only
supporting maintenance through launch plus 12 months (see SRR
presentation, page 23) and given the rapidity with which archive
technologies are evolving, SDS will incur unnecessarily high archive
costs by requiring the contractor to procure the full 3.2 petabytes as
part of the development contract. Recommend reducing the development
contractor's requirement to storing EOC plus one year of expected data
volumes but maintaining the design goal.

**Rationale:**

**Response:**

The presentation material was misconstrued, as it was always the intent
to provide Initial Operating Capability data storage for testing plus
two years of operational storage. The SOW and instructions to bidders in
the RFP will make the intent clear.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.5, item a

**Title:** Support inter-system bulk data orders

**Action:**

13\. ECS experience suggests inter-system data transfers, such as those
SDS supports with ADS, CARS and DCAVS, should not be handled by the
usual search and order interface but should be supported by a bulk data
order interface, particularly external systems performing reprocessing.
Recommend expanding this requirement to support inter-system bulk data
orders and metered transfers to the external systems.

**Rationale:**

**Response:**

Metered or bulk data transfers are particular features of a design
implementation. The performance requirements are written to address the
data transfer rate concerns. Throughout implementation, key performance
parameters such as data transfer rates will be tracked and monitored.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.5

**Title:** Suspend/resume/cancel capability

**Action:**

14\. Recommend adding a requirement that allows an SDS operator to
suspend and later resume or cancel problem orders, possibly due to
excessive order size or data access problems.

**Rationale:**

**Response:**

The specification will be revised to require the capability for SDS-C
operators to suspend, and subsequently resume or cancel, the processing
of distribution orders and data requests.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.5

**Title:** Distribute data in the ECS format

**Action:**

15\. Recommend adding a requirement that SDS distribute data in the ECS
distribution format so that users can use one tool set in exploiting the
data they receive. Note that this is not the same as a single data
format.

**Rationale:**

**Response:**

The requirement to use the EOS-HDF format has not been identified at
this time. While the EOS-HDF format may provide ease in analysis of past
EOS missions, the format may not be used by the IDPS or ADS which will
be the source of data for future climate products. We have deferred
selection of a data format as an ICD issue and will be looking at the
recommendations made by the IPO TSPR contractor, ADS, and the selected
NASA science team before making a format determination.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.6.2, item f

**Title:** Retransmission request processing

**Action:**

16\. There may be cases where ADS will need to send retransmission
requests more than 12 hours after start of data transfer. Recommend
modifying the requirement to require the SDS be able to receive and
process retransmission requests as needed.

**Rationale:**

**Response:**

Concur. In the event of a failure at the ADS, it may be necessary for
the ADS to come back to the SDS and retrieve data that is in the long
term data storage. While this should be an infrequent event, there
should be provisions in the requirements to handle this. The 12 hour
requirement should still be maintained for nominal conditions.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.6.3

**Title:** Retransmission requests from IDP

**Action:**

17\. Given the need for retransmission support with ADS, it is not clear
why the SDS does not support retransmission requests from IDPS.
Recommend adding a requirement to support this interface.

**Rationale:**

**Response:**

The volume of data being sent to the IDPS will be significantly smaller
than that being sent to the ADS. Therefore, it is not necessary for the
CDMS to support automated retransmission requests with the IDPS.
However, a general requirement for the CDMS to coordinate data transfers
with the IDPS will be added to the specification.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specification Doc, Section 3.5.1.6.3

**Title:** Receipt confirmations from IDPS

**Action:**

18\. Given the need for receipt confirmation support with ADS, it is not
clear why the SDS does not support receipt confirmations from IDPS.
Recommend adding a requirement to support this interface.

**Rationale:**

**Response:**

The volume of data being sent to the IDPS will be significantly smaller
than that being sent to the ADS. Therefore, it is not necessary for the
CDMS to support automated receipt confirmations with the IDPS. However,
a general requirement for the CDMS to coordinate data transfers with the
IDPS will be added to the specification.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 98

**Title:** SDS Presentation, Chart 98

**Action:**

Investigate whether volume alone enough to spec data
processing/reprocessing? Some processing jobs are more resource
intensive in the use of CPU, etc.

**Rationale:**

Vendor may deliver system which he thinks meets the specs but which can
not handle the processing scientists require.

**Response:**

The specification requirements are in volume and time. The implementer
must derive the CPU capacity needed to meet the processing requirements.

**Status:** Closed

**Key Words:** reprocessing

**Reference:** SDS Presentation, Chart 98

**Title:** Staffed or unstaffed operational duty cycle

**Action:**

You state the operational duty cycle requirement of 24x7, but do you say
whether staffing is 24x7?

**Rationale:**

A system that is staffed only 16x5 (or 8x5) requires lots more controls,
fail-over processes/procedures, etc than one staffed 24x7. However,
operational costs usually prohibit 24x7 staffing.

**Response:**

The SDS ConOps (Section 3.6) describes the intended staffing of the
central SDS operations. Initially, staffing will be 24x7 with a goal of
reducing the staffing requirements over the life of the system.
Collocation with other operations may also provide effective 24x7
coverage while sharing costs.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 100

**Title:** Deletion of algorithm compatibility requirement

**Action:**

Why would you delete the algo compatibility requirement?

**Rationale:**

Shouldn\'t the vendor deliver software tools to help in performing this
activity, instead of being entirely a manual process? Otherwise
wouldn\'t the cost of performing this activity be prohibitive
operationally?

**Response:**

Given the NewDISS paradigm for distributed processing, it is the intent
to have the science team members be responsible for their own production
code and operations. There will be interface requirements that the PI
systems will need to meet in order to interface with the central
elements of the SDS. An interface requirements specification and ICD
will be written and, as appropriate, tools will be provided to help the
PIs meet the interface specification. However, it is not the intent to
have the contractor provide toolkits that the PI would need to utilize
since there is no intent to migrate the PI code back to a central
processing component.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 107

**Title:** ATBD or Code to be utilized?

**Action:**

Investigate how ECS, Landsat, and others have done this, pros and cons
of each.

**Rationale:**

Utilizing only ATBD may require a large programming staff and an extra
burden for integration and test on the PIs.

**Response:**

The specification will be revised to specify that government-supplied
algorithms will be provided in the form of ATBDs and/or research code
used by the government to validate the ATBDs. By specifying the
requirement this way, it provides the government with the option of only
providing ATBDs to the contractor. That way, if research code cannot be
provided, the contractor will be required to work from the ATBDs. Also,
the programming effort required to work from ATBDs should not be a
problem since the contractor will already have a programming staff in
place to support development, integration, and testing of the SDS-C.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 110

**Title:** Subsetting capability provided

**Action:**

Specifically addressed whether a subsetting capability is to be provided
to PIs.

**Rationale:**

If not specifically specified, the vendor is not likely to provide,
however users are very likely going to need. Capability will allow user
to get only what he/she needs, saving resources on his/her side, while
also leaving more capacity for other users to receive data without
bogging down system.

**Response:**

Paragraph 3.5.1.6.1.a of the specification requires the CDMS to allow
queries and orders based on metadata contents and/or browse images. In
addition to this, the specification will be revised to add a requirement
for the CDMS to provide a data subsetting capability that allows
subsetting based on geographic area coverage, channels (bands), date
and/or time of data collection, and additional metadata contents as
required.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 111

**Title:** Processed calibration data

**Action:**

Address whether processed calibration data may be needed to reproduce
the results of any processing. Make sure science teams understand
potential impact.

**Rationale:**

If products cannot be reproduced without these data, the requirement
probably cannot be deleted.

**Response:**

The Level 1B data and CDRs generated by the SDS-C can be reproduced
without utilizing \"processed calibration data.\" The science
calibration parameters will incorporate any calibration information
needed for product generation.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 112

**Title:** Sneaker-net backup

**Action:**

Investigate need/costs for emergency media ingest capability

**Rationale:**

Long-term down-times may greatly perturb processing, causing huge
back-logs.

**Response:**

Data ingest availability and capability is necessarily high to avoid the
necessity for media ingest. Given the data volumes, the only presently
known viable media would be Digital Linear Tape (DLT) which is the media
proposed for the near line archive. At present, DLT can store 40 to 50
GB in native format or approximately 80 to 100 in compressed format. The
use of DLT as a backup media would require IDPS to have the capability
to generate DLTs in a mutually agreed format. Approximately 3 tapes
would be needed per day to ensure adequate capacity. If IDPS could
generate DLT copies of SDS data on a daily basis and make them
available, then a \"sneaker-net\" backup would be viable.

**Status:** Closed

**Key Words:** emergency media ingest

**Reference:** SDS Presentation, Chart 121

**Title:** Calibration Parameter Responsibility

**Action:**

Determine ultimate responsibility for calibration, science teams or
vendor.

**Rationale:**

If tools are not specified, the science teams may not be able to do the
science they expect.

**Response:**

The Climate Calibration Characteristics section of the specification
documents the requirements that must be met for NPP with regards to the
calibration functions. The next step in the development process is to
allocate these "system" level requirements to the software, hardware,
operations, and analyst components of the system. The results of this
activity will be presented during the SDS-System Design Review. Further
decomposition of the software and tools required will be accomplished as
the requirements allocated to the software are further refined through
the development life cycle.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Chart 122

**Title:** DCAVS requirements

**Action:**

Are DCAVS required of contractor only for \"testing\" their SDS, or
should they be a set of tools/software libraries/etc that any science
team can use to perform this task?

**Rationale:**

System may not be adequately speced to encourage software reuse, etc

**Response:**

Even though the four DCAVS to be provided as part of the SDS-C will be
prototypes, it is still expected that several of the tools needed by the
Science Team to operate the production DCAVS will be developed and
provided with them. The specification will be revised as necessary to
clarify this.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation, Page varies

**Title:** Design Goals

**Action:**

Determine whether \"design goals\" should be recast as
expandability/scalability/etc. requirements. And in addition to
considering as discriminators in choosing the vendor, see what
procurement folks suggest as far as making sure that we can hold the
vendors to their estimates. For example, possibly, have main requirement
of 2x reprocessing, and \"contract options\" for each additional 1x.

**Rationale:**

Make sure spec wording cannot be easily misinterpreted and provide a
concrete test of vendor\'s proposal

**Response:**

The SOW and the RFP (Sections L and M) will make it clear to the bidders
what the minimum acceptable performance is. The bidder\'s ability to
meet the \"Goals\" is a significant discriminator for use by the source
selection board and will be appropriately identified as such in Section
M of the RFP.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation

**Title:** ISO Compliance

**Action:**

Investigate need for specific requirements to be placed upon vendors

**Rationale:**

Current GSFC and NASA PG need to be followed, otherwise retrofitting
processes may be costly and cause delays.

**Response:**

Although it was not addressed during the SRR, the SDS-C specification
does require the contractor to have a Quality Management System that is
compliant with ANSI/ASQC Q9001. This requirement was flowed down from
the Mission Assurance Guidelines (MAG) for Tailoring to the Needs of
GSFC Projects (300-PG-7120.2.2) document.

**Status:** Closed

**Key Words:**

**Reference:** SDS Presentation

**Title:** Ops costs

**Action:**

Brainstorm more concrete ways to ensure the system delivered can be
operated at a reasonable cost.

**Rationale:**

With a separation of Ops and Development Vendors, costs may be minimized
for one element at the expense of the other, increasing overall costs to
project.

**Response:**

We will be bringing the operations contractor personnel on board very
early in the design phase. One of the key reasons for this is so that
they can provide feedback on the design of the system to ensure that
life cycle costs are appropriately addressed. This has worked quite
effectively on past projects. In addition, we will be looking at the
structure of the award fee to ensure that reductions in life cycle costs
are incentivized.

**Status:** Closed

**Key Words:**

**Reference:** Chart 58

**Title:** RDR's from C3S?

**Action:**

Clarify the ability of C3S to provide RDRs to SDS.

**Rationale:**

This chart indicates that a trade study will be conducted to determine
if the SDS should ingest RDRs directly from C3S. However, chart 11
indicates that the RDRs are produced at IDPS from SMD received from C3S.
Please clarify this to indicated whether C3S can in fact provide RDRs.

**Response:**

Open trade being performed.

**Status:** Rejected

**Key Words:** ingest C3S

**Reference:** chart 96

**Title:** Ingest data volume

**Action:**

Clarify the CDR data ingest volume requirement for CDMS.

**Rationale:**

The requirement is for CDMS to ingest and store 1.4 terabytes of CDR
data per day from CARS, corresponding to 1 day's worth of products.
However, since processing capacity

is three day's worth of data per day, the CDMS ingest capacity will need
to handle this.

**Response:**

The original estimate of 1.4 TB was 3x the sum of the expected Level 2
and Level 3 products created by all of the CARS in the operational SDS.
That number has been revised to 1.6 TB based on some new product
estimates.

**Status:** Closed

**Key Words:**

**Reference:** chart 116

**Title:** CDRS needed for calibration

**Action:**

Add CDRs to the list of data types ingested from CDMS.

**Rationale:**

Most field campaign data does not represent fields which can be compared
directly to instrumental radiances. Some CDRs will be need to obtain the
derived surface measurements needed for comparison with the field data.

**Response:**

The data flow diagrams and resultant requirements are being updated to
provide CCS with the capability to request any data contained within the
mission storage, including CDRs.

**Status:** Closed

**Key Words:**

**Reference:** chart 122

**Title:** Data Storage for DCAVS

**Action:**

Add data extraction, subsetting and storage to the DCAVS capabilities.

**Rationale:**

DCAVS will need to have the ability to store extracted and subsetted
data to perform extended time-series validation of CDRs.

**Response:**

The specification will be revised to include a requirement for the CDMS
to provide data subsetting capabilities for internally distributed SDS
mission storage data. Since the DCAVS being procured as part of the
SDS-C is only a demonstration version, it does not need to provide the
storage capabilities that will be required of the production (i.e., SDS)
DCAVS elements.

**Status:** Closed

**Key Words:**

**Reference:** SDS Context Diagram - Notional Architecture, Chart 33

**Title:** Govt. Supplied Algorithms

**Action:**

Identify from where the SDS receives the Govt. Supplied Algorithms in
the SDS Context Diagram -- Notional Architecture

**Rationale:**

The architecture did not refer to the Govt. supplied algorithms (from
science team/PIs etc.) If this activity is part of SDS, show it in a box
within SDS or if the activity is external to SDS, this can be shown as
an external entity.

Govt. supplied algorithms are important inputs and should be part of the
context diagram

**Response:**

The algorithms will be supplied by the Science Team. The Science Team is
not shown as a separate entity on the notional architecture since it is
embedded throughout various components of the SDS. Subsequently, the
algorithms do not appear in the context diagram.

**Status:** Closed

**Key Words:**

**Reference:** SDS Requirements 3.5.1.4(b) Mission Storage, CDMS Chart
36

**Title:** Mission Storage Requirement for \"algorithms used in the
generation of SDS products\"

**Action:**

Include \"algorithms used in the generation of SDS products\" in the
list of items to be stored.

**Rationale:**

The information on the algorithms used will be useful for research
scientists

**Response:**

Although Paragraph 3.5.1.4.b does not require the SDS product algorithms
to be stored in SDS mission storage, they will be stored in the SDS
software library and submitted to the ADS for archival purposes
(reference Paragraph 3.1.1.4). The SDS-C will maintain a record of the
algorithm versions in the metadata for the corresponding products as
well as in a configuration log. Paragraph 3.1.1.5 of the specification
will be revised to add a requirement for configuration log
accessibility.

**Status:** Closed

**Key Words:**

**Reference:** SDS Specifications 3.5.2.2 CDR Generation, CARS, Chart
39,40

**Title:** CDR and CDP generation

**Action:**

Consider introducing a requirement for CDP generation in CDMS (by
formatting CDRs, incorporating metadata and browse data)

**Rationale:**

By definition, CDPs are CDRs that have been formatted incorporating
metadata and browse.

3.5.2.2 (e) specifies that CDRs, metadata and browse data are sent by
CARS to mission storage and CDMS has a requirement \[3.5.1.6.2 b (2)\]
to send CDPs to ADS.

CDMS is to format CDRs in the required format, incorporating metadata
and browse data

**Response:**

Paragraph 3.5.2.2 of the specification will be revised to add a
requirement for the CARS to generate CDPs. These CDPs, which include
CDRs, metadata, and browse images, will then be sent to SDS mission
storage. The requirement for formatting CDRs in Paragraph 3.5.1.6.2.a of
the specification will also be revised to require the formatting of CDPs
for distribution to the ADS.

**Status:** Closed

**Key Words:**

**Reference:** CARS, Chart 40

**Title:** Reference to L2 and L3 products, and Climate data products

**Action:**

Please review this slide as it is not supported by CARS requirements in
the SDS Specifications.

**Rationale:**

1\. There is no reference to L2 and L3 products in SDS Specifications.

2\. SDS Specifications document has no CARS requirements for i)
reprocess CDPs ii) Create, Update and Test CDP algorithms.\-- Is the
reference to CDRs ?

**Response:**

1\. SDS is responsible for producing Level 1 and higher level (Level 2
and 3) products. The higher level (Level 2 and 3) products are Climate
Data Products.

2\. Climate Data Products are Climate Data Records with the
corresponding browse data and metadata.

2(i). Requirement 3.1.1.1.3(c) provides the capability to reprocess
Level 1B and CDR products. Requirement 3.1.1.1.3b also pertains to
reprocessing of SDS products, in general.

2(ii). The algorithms referred to here are the algorithms employed in
the production of CDRs. The chart was attempting to indicate CARS users
should be able to create, update, and test new algorithms used in CDR
production. The creation of algorithms is a manual function. Requirement
3.1.4.1b requires SDS-C as a whole to allow software upgrades to be
integrated, tested and verified without interrupting processing or
degrading performance.

**Status:** Closed

**Key Words:**

**Reference:** SDS Requirements Specifications 3.5.1.2 L1B Data
Generation

**Title:** Algorithm Definition

**Action:**

Please define \"Govt. supplied algorithm\"

**Rationale:**

There was some discussion on the Govt. supplied algorithms during the
SRR and there is lack of clarity on whether the developer is supplied
with ATBDs or science software for development of robust operational
software. It is desirable to resolve this asap.

**Response:**

The specification will be revised to clarify that government-supplied
algorithms will be provided in the form of ATBDs and/or research code
used by the government to validate the ATBDs. If the government uses
research code to validate the ATBDs, this code will be provided to the
contractor as reference material.

**Status:** Closed

**Key Words:** algorithm science software

**Reference:** SDS Req Spec 3.5.1.2 (h), 3.5.1.3 ( a) and (b), 3.5.2.2

**Title:** Utilizing algorithms approved by Govt.

**Action:**

Please define \"algorithms approved by the Govt.\" or give some
additional details of the requirements with (TBS), if considered
necessary.

**Rationale:**

The requirements referred to above require the developer to use
algorithms approved by the Govt. A clear definition / explanation is
appropriate. At what stage will the Govt. approve? It is desirable to be
more specific about the requirements by providing detailed
specifications of the browse images (horizontal / vertical resolution,
area, gray shades/ calibration etc) or details of parameters to be used
for quality assessment.

**Response:**

When released, the RFP and SOW will identify algorithms as: (1) GFI to
the vendor, or (2) Developed by the vendor. In the response, the vendor
will propose a need date for the various GFI. During contract
negotiation, the Government and the vendor will establish a mutually
agreed date for the GFI. The SDS team will provide the ATBD on or before
the need date. When GFI is provided to the vendor it is de facto
\"approved.\" Algorithms developed by the vendor will be documented in
an Algorithm Description Document which will be on the Contract Data
Requirements List (CDRL) and will require Government approval. Approval
of the Algorithm Description Documet is approval of the algorithms
contained within.

**Status:** Closed

**Key Words:** algorithm government approved

**Reference:** SDS CRS 3.5.4.1d

**Title:** Format of Field Campaign Data

**Action:**

Specify the formats to be supported in 3.5.4.1.c & d - both media and
file types.

**Rationale:**

\"Field campaign data\" can mean almost any data types available, from
single point data to aerial overflight imagery to filed notes. Either
narrow down what you mean, or state the system will provide \[DLT,
CD-ROM, ftp, etc.\] to allow manual staging of information.

**Response:**

Interface Requirements Definition (IRD) documents exist for the primary
SDS interfaces -- IDPS, ADS, and C3S. These IRDs define distribution
methods (e.g., electronic) for data items. Interface Control Documents
(ICDs) will be generated during the SDS implementation phase. These ICDs
will specify formats and any other pertinent design details. Operational
field campaign data are expected in a variety of methods (media and
electronic) and formats. CDMS has the requirement to ingest operational
field campaign data from ancillary data sources and to enable an
operator to manually input these data. Once requirements for the
specific Climate Data Records are solidified, IRDs and ICDs will be
developed with relevant ancillary data systems for ancillary data
(including operational field campaign data) needed by SDS. CDMS will be
able to handle electronic distribution; the operator manual entry
requirement will cover any hard copy data or reading of magnetic and
optical media.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** Acquisition and Ingest Reporting

**Action:**

Add a requirement to the CDMS that it must allow the operator to view
SDS-Archived data versus data that the instrument was scheduled to
acquire. This may imply additional information in the C3S to SDS ICD --
I haven't read this.

**Rationale:**

In the SRR, it was stated that the SDS folks would be tracking to verify
that all mission data gets into the SDS. I did not see a requirement to
support this; and after a few years using Excel to do this can be
cumbersome. (I know, I've done it.)

**Response:**

The SDS/CDMS will be receiving mission status information from the C3S.
This will contain information regarding schedules of operations of the
instruments and spacecraft (among other things). The information will be
used to compare data received and processed at the SDS with the data
that is expected. There are requirements to create production reports
which will include information on data received versus expected so that
an operator will know if anomaly resolution procedures need to be
initiated. The functionality requested is already covered in the
requirements.

**Status:** Closed

**Key Words:**

**Reference:** SDS CRS 3.1.1.5

**Title:** Backup of 45 day cache

**Action:**

Modify 3.1.1.1.5b) to specifically exclude the 45-day cache.

**Rationale:**

The 45 data cache is already backed up in the offline storage device.
If, I calculate correctly, this cache will be about 70TB, a very
cumbersome volume for traditional backup technology (therefore
expensive).

**Response:**

Raw measurement data will be retained in SDS in addition to the short
term cache of processed data which is used to make the 8/16/32 day
products. We are evaluating the allocation of storage to both on-line
and near-line technologies such as RAID and DLT \"jukeboxes.\" In the
case that near-line storage is used, weekly backup is not necessary. We
propose rewording the requirement to require backups only if data is not
duplicated elsewhere on independent media.

**Status:** Closed

**Key Words:**

**Reference:** SDS CRS 3.1.3, 3.1.4, 3.1.5

**Title:** Sparing

**Action:**

Clarify what level of sparing is required. Must 100% spares be provided?
Also, the note about \"administrative time, logistics supply time, and
delays\" from 3.1.4 makes me nervous. Does this apply to the
specifications of M(max) and A(o)?

**Rationale:**

**Response:**

The SOW requires the proposer to provide a list and quantity of
recommended spares. The government typically purchases what is prudent
within the maintenance budget. M(max) and A(o) do not include the times
mentioned. It is the responsibility of the maintainer (government or
contractor) to ascertain that spares are readily available and ensure
that hard to get items are locally stocked.

**Status:** Closed

**Key Words:**

**Reference:**

**Title:** System Administrative Guides

**Action:**

The contractor should be required to furnish system administration
guides for all SDS-C computer systems, to include at a minimum:

1\. all COTS H/W and S/W on the system

2\. all license information

3\. configuration information (RAID, security, etc.)

4\. backup / restore procedures.

**Rationale:**

If they don't write this, you will be.

**Response:**

The SOW for the SDS will identify the needed data items which will be
placed on the Contract Data Requirements List (CDRL).

**Status:** Closed

**Key Words:**

**Reference:** SDS CRS 3.1.1.1.1a,b,c; 3.1.1.1.3d

**Title:** Reprocessing Capacity clarification

**Action:**

This (3.1.1.1.3d) should be more clear - does this apply only to the CPU
throughput? How about I/O between CDMS and CARS? Or the media output of
5%, does that become 5% of the \[200%\] volume?

**Rationale:**

**Response:**

The reprocessing capacity of 200 percent specified in Paragraph
3.1.1.1.3.d of the specification only applies to the CPU throughput. In
regards to media output, the CDMS must be capable of generating media
output for five (5) percent of the daily volume ingested into SDS
mission storage. The daily volume referenced here does include
reprocessed data. All the noted requirements are separate and distinct.
Each has to be individually and collectively met. It is the proposer\'s
responsibility to identify how the I/O will be accomplished to support
the reprocessing requirement.

**Status:** Closed

**Key Words:**

**Reference:** SDS CRS 3.5.1.7c & d

**Title:** Statistics and Reporting

**Action:**

Add \"for any user-specified period from start of SDS operations to
present\"

p.s. 3.5.1.7(6) is a weenie requirement.

**Rationale:**

**Response:**

Suggested wording will be incorporated in requirements 3.5.1.7(c) and
(d).

Regarding the post-script comment \-- Requirement 3.5.1.7(a.6) enables
users to generate SDS reports containing statistical performance data.
We will add examples of such reports including (1) volume of products
generated (bytes) and (2) time to fill an order.

**Status:** Closed

**Key Words:**