ID: 2234 Date Recvd: 1/16/96 Status: Closed
Reference:
Annex A 1.1, 1.2.2
Sensor Payload and EDR Algorithms
Recommendation:
In the CrIS SRD it states that the contractor will be responsible for the development of the CrIS operational algorithms. During the Phase I PDR and Risk Reduction effort, the contractor will develop a sensor (payload) and will develop algorithms. Should the development of associated algorithms, validation test bed and sensor/algorithm validation be reported separately from sensor development effort (PWBS 1.1)? Should it be recorded under PWBS 1.2.2 EDR Algorithms, or PWBS 1.4 System Test and Evaluation?
Rationale:
Response:
1) The SRD is being revised to indicate sensor contractors will be responsible for science algorithms only. (2) Yes, the development of associated algorithms, validation test bed and sensor/algorithm validation be reported separately from sensor development effort (PWBS 1.1). (3) Algorithms should be reported under 1.2.2, EDR Algorithms, Test bed should be reported under 1.4.1, DT&E, if you choose to build a Test bed. There is no requirement for a "formal" validation effort during this phase of the contract. Any in-house debugging should be included under 1.2.2.
------------------------------------------------------------------
ID: 1655 Date Recvd: 12/20/96 Status: Closed
Reference:
Annex A Pages 4-20
Program Work Breakdown Structure
Recommendation:
PWBS outlined on page 4 does not correspond to PWBS Dictionary (pp. 5-20). The Program Office could provide the PWBS for entire NPOESS program. Those elements which are part of the Sensor Payload and Algorithm Development procurement should then be indicated in both the PWBS and the dictionary. Another option would be for the Program Office to provide only a top level CWBS and dictionary for the sensors contractors to use.
Rationale:
In order for contractors to construct a meaningful CWBS, the relationship of the elements in this procurement to the overall NPOESS program must be clear. It is suggested that the PWBS Dictionary mention specifically when a particular element is part of the Sensor Payload and Algorithm Development procurement. The other suggestion is to provide a top level CWBS to all bidders.
Response:
The WBS is being changed to a Sensor/algorithm development WBS. The Dictionary will be modified accordingly.
------------------------------------------------------------------
ID: 1633 Date Recvd: 12/19/96 Status: Closed
Reference:
Annex A Program WBS and Dictionary
WBS Numbering
Recommendation:
The WBS Dictionary numbering appears to be inconsistent with the Program WBS.
Rationale:
Response:
The WBS is being revised. The Dictionary will be modified to reflect the Sensor WBS.
------------------------------------------------------------------
ID: 1560 Date Recvd: 12/19/96 Status: Closed
Reference:
Annex A Program WBS and WBS Dictionary
Program Work Breakdown Structure
Recommendation:
Dictionary attached to PWBS does not match PWBS by element item number. Request the PWBS Dictionary be changed to match the PWBS.
Rationale:
PWBS better reflects the nature of this procurement.
Response:
Accept. Both the dictionary and the WBS will be revised.
------------------------------------------------------------------
ID: 2229 Date Recvd: 1/15/97 Status: Closed
Reference:
Annex A, PWBS Page 3, paragraphs 1.1 and 1.2.2
Sensor Payload and EDR Algorithms
Recommendation:
In the CrIS SRD it states that the contractor will be responsible for the development of the CrIS operational algorithms. During the Phase I PDR and Risk Reduction effort, the contractor will develop a sensor (payload) and will develop algorithms. Should the development of associated algorithms, validation test bed and sensor/algorithm validation be reported separately from sensor development effort (PWBS 1.1)? Should it be recorded under PWBS 1.2.2 EDR Algorithms, or PWBS 1.4 System Test and Evaluation?
Rationale:
Response:
1) The SRD is being revised to indicate sensor contractors will be responsible for science algorithms only.
(2) Yes, the development of associated algorithms, validation test bed and sensor/algorithm validation be reported separately from sensor development effort (PWBS 1.1).
(3) Algorithms should be reported under 1.2.2, EDR Algorithms, Test bed should be reported under 1.4.1, DT&E, if you choose to build a Test bed. There is no requirement for a "formal" validation effort during this phase of the contract. Any in-house debugging should be included under 1.2.2.
------------------------------------------------------------------
ID: 1656 Date Recvd: 12/20/96 Status: Closed
Reference:
Annex B 1.0, 2.0, and 3.0
IMP and IMS Instructions
Recommendation:
Ambiguity concerning requirement for a Statement of Work (SOW) should be removed. References to SOW in Paragraph 1.0 (first and fourth paragraphs), Figure 1, Paragraph 2.0 (title), and Paragraph 3.0 (first paragraph) should be deleted.
Rationale:
We assume that the second sentence of Paragraph 2.0 is correct, and that the listing of tasks in the IMP will replace the SOW. Furthermore, Paragraph 3.0 (1)-Task- states that "The task section replaces the effort descriptions usually contained in a Statement of Work."
Response:
The task section in the IMP will replace the SOW. References to a SOW in para 1.0 and the para 2.0 title is in the context that it will be included as part of the IMP tasks section. Normally, the SOW is a separate document from the IMP.
------------------------------------------------------------------
ID: 1657 Date Recvd: 12/20/96 Status: Closed
Reference:
Annex B 3.0, (2) Event
Scope of IMP/IMS
Recommendation:
The CLIN structure and the SOO seem to define the program as including all efforts through delivery of flight sensors. The IMP instructions imply that detailed program planning information (IMP/IMS) is only desired for the Risk Reduction Phase. The scope of the IMP/IMS needs to be clarified. We recommend that IMP/IMS concentrate on the period through PDR with only placeholder major tasks/ milestones for period after PDR. The IMP/IMS can be expanded with the "Call for Improvements" to define the program through the production phase.
Rationale:
The last of the minimum Government required events for the IMP is the Preliminary Design Review. This implies that the CWBS, IMP and IMS required in the proposal should only cover the period up to and including the PDR ( i.e. Risk Reduction Phase). The SOO, however, outlines a "Detailed Design and Fabrication Phase" which continues through delivery of flight sensors. Since traceability is required from SOO through the CWBS to the IMP/IMS, this apparent disagreement should be clarified.
Response:
The SOO covers the total sensor development activities with its two phases. This proposal will cover the first phase in much greater detail than the second phase which will now be covered in some detail. The government is not only interested in the systems engineering and design capabilities but also the production capabilities of the contractor. The IMP/IMS instructions will be revised to clarify that greater detail is expected in the IMP tasks and the IMS up to downselect. Details after PDR to sensor integration onto the spacecraft are still expected. This will be consistent with a revised Sec L para 3.0.
------------------------------------------------------------------
ID: 1577 Date Recvd: 12/19/96 Status: Closed
Reference:
Annex B Page 7
Risk Management
Recommendation:
Add "reducing" in the thrid line following "prioritizing"
Rationale:
Consistent with risk management/mitigation.
Response:
Agree. "reducing" added to sentence.
------------------------------------------------------------------
ID: 1958 Date Recvd: 12/20/96 Status: Closed
Reference:
Appendix D
Recommendation:
Please identify which heritage algorithms, such as those currently being developed for MODIS or in operation with NESDIS, belong in the algorithm analysis, or will likely be recommended for implementation?
Rationale:
Insight into which algorithms the Operational Algorithm Teams (OATs) are considering for implementation will greatly influence the selection of bands and other instrument attributes. The contractor can arbitrarily select a set of EDR algorithms, which might depend on different physics than those the OATs have in mind. This would impact VIIRS design, as well as the algorithm designs and designs for instrument models to simulate specific effects (e.g., scattering/stray light).
Response:
No timelines have been established for OATs activities.The OATS may provide recommendations anytime up until the requirements freeze date (SFR). The contractor is ultimately responsible for ensuring the sensor and algorithms meet EDR performance thresholds regardless of external recommendations.
------------------------------------------------------------------
ID: 1959 Date Recvd: 12/20/96 Status: Closed
Reference:
Appendix D 40.6.1 Land Surface Temperature
Recommendation:
There appears to be no distinction between the land surface temperature and emissivity. Is the emissivity product expected to be separate or is it just an intermediate database for the temperature calculation?
Rationale:
The physical and apparent land surface temperatures can vary significantly depending on the emissivity of the surface. The separation of temperatures and emissivities is a significant algorithm in the EOS ASTER science team's product algorithm system. Recovery of the physical temperature, as opposed to the apparent temperature (the product of the physical temperature
Response:
Emissivity in and of it self is not an NPOESS requirement. If you can satisfy the requirement without it, fine. If it is needed and you can get the emissivities without measuring them yourself, that is also acceptable. If the only way to satisfy the requirement is to measure the emissivity yourself, then that is what must be done.
------------------------------------------------------------------
ID: 1960 Date Recvd: 12/20/96 Status: Closed
Reference:
Appendix D 40.6.2 and 40.6.4
Recommendation:
For many of the EDR's the temporal update period is not given. (Appendix D, 40.6.2 Normalized Difference Vegetation Index (NDVI), table). What is the requirement? Similarly, for the land cover change EDR. (Appendix D, 40.6.4 Vegetation Index/Surface Type, table).
Rationale:
For instance, a composited NDVI could be produced once every day, every 8 days, every 10 days, monthly, etc. Similarly, Land Surface type might be a weekly, monthly, or quarterly product.
Response:
The temporal update period for the physical measurements that support an EDR is in general constrained by two attributes, the maximum local average revisit time and the maximum local refresh. The maximum local average revisit time is specified for both of the EDRs cited, and the maximum local refresh is TBD for both. The time lag between the issuance of an EDR and the physical measurements supporting it will be constrained by a Data Availability requirement imposed at the system level (See TRD, Sec. 3.2.1.2).
------------------------------------------------------------------
ID: 1658 Date Recvd: 12/20/96 Status: Closed
Reference:
Attachment 8 1.0
Award Fee Plan Introduction
Recommendation:
As options are exercised how will the award fee periods and pools be changed to reflect the additional effort? We would recommend the award fee periods be at 6-month intervals.
Rationale:
Clarification
Response:
As options are excercised, the Government is considering making the Award Fee Periods 6 month periods.
------------------------------------------------------------------
ID: 1822 Date Recvd: 12/20/96 Status: Closed
Reference:
Attachment 8 ANNEX 2
Award Fee Payments
Recommendation:
Will the government permit provisional award fee billings on a monthly basis?
Rationale:
Provides fee prior to the completion of the award fee evaluation process.
Response:
The Government will not allow the prepayment of Award Fee. Award Fee will not be paid until earned.
------------------------------------------------------------------
ID: 1674 Date Recvd: 12/20/96 Status: Open
Reference:
Attachment 8 page (9), ANNEX 2, AWARD-FEE ALLOCATION BY EVALUATION PERIODS, last sentence of paragraph 1.
Transfer of Unearned Fee
Recommendation:
The last sentence of the first paragraph states, Any unearned portion of award fee for a period is not transferable to a subsequent period. Please consider allowing the Government flexibility to carry forward unearned fee at its discretion.
Rationale:
The IPO may desire to have flexibility to further incentivize the contractor in subsequent periods to achieve results of benefit to the Government.
Response:
The Government is considering including an option to include roll-over award fee to improve Contractor performance.
------------------------------------------------------------------
ID: 1553 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 8 Page 11, Annex 4, "Note", last sentence
Award Fee Plan
Recommendation:
This provision specifies that zero award fee will be earned if the contractor's "overall performance" is rated 50% or below. It is not clear how the overall performance rating will be evaluated. Recommend using a weighted average as being most equitable
Rationale:
This will be consistent with weightings assigned in the award fee plan
Response:
A sample computation using a weighted average will be included in the Award Fee Plan.
------------------------------------------------------------------
ID: 1552 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 8 Page 7, Paragraph 6.0, "Contract Termination"
Award Fee Plan
Recommendation:
This clause does not expressly cover the disposition of award fee earned for fee periods completed prior to the termination. It is recommended that the following text be added as the first sentence of this paragraph: "Award fee earned by the contractor for award fee evaluation periods completed prior to the effective date of termination will not be affected by the termination."
Rationale:
It would be unfair to penalize satisfactory performance for completed award fee periods.
Response:
When an Award Fee period is completed, the Award Fee plan defines how the Contractor will earn award fee for that period. The clause in question does not contradict the award fee process; in fact, it expressly covers the disposition of award fee if termination occurs after a new award fee period begins. It specifically states, "If the contract is terminated for the convenience of the Government after the start of the award fee period...." Therefore, this clause defines how award fee will be paid in the presense of a partial award fee period.
------------------------------------------------------------------
ID: 1554 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 8 Page 9, Annex 2
Award Fee Plan
Recommendation:
Eliminate references to ATP, SRR, SDR and PDR in Award Fee Plan
Rationale:
The DRFP specifies that Phase 1 is CPFF, not CPAF
Response:
While it is the IPO's intention to award competing contracts for each sensor, the inclusion of the pre-PDR contract milestone dates is appropriate for the RFP in the event that only a single award is made for any of the sensors. In the case of single award for any of the first phase efforts, the contract will be issued on an award fee basis.
------------------------------------------------------------------
ID: 1551 Date Recvd: 12/19/96 Status: Open
Reference:
Attachment 8 Page 9, Annex 2, first paragraph, last sentence
Award Fee Plan
Recommendation:
This provision precludes earn-back of lost award fee for Phase 2 and beyond. In contrast, we believe it to be in the best interests of the Government to have this tool in the "toolbox" of available incentives that could be used to provide additional positive motivation to the contractor to resolve any long-term problems or for other special accomplishments. Therefore, it is recommended that the reference sentence be deleted and that the following, or similar language, be adopted:
"The Government may, at option, award all or any part of the award fee that was not awarded for performance during the period to which it was allocated, if the Government determines that the additional award is merited, for example, by the contractor's overall performance, or the achievement of specific goals or objectives. Any such opportunities to earn back previously unearned fee may be allocated to evaluation periods, program events, exceptional performance or other items as deemed appropriate."
Rationale:
This change will provide further positive motivation to contractors.
Response:
The Government is considering including an option to include roll-over award fee to improve Contractor performance. [This issue will likely remain open until the final RFP; we require IPO mgt. direction on whether to allow this.]
------------------------------------------------------------------
ID: 1567 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 8 Paragraphs 4.0 and 5.0
Award-Fee Processes and Award-Fee Change Procedure
Recommendation:
Reference to Annex 2 in paragraph 4.0, sub-paragraph b, appears to be a typographical error. Recommend changing reference to Annex 5. Paragraph 5.0 references Annex 2. Recommend reference be changed to Annexes 5 and 2, respectively since both the criteria and periods are affected.
Rationale:
Clarification of requirements
Response:
Comments will be implemented.
------------------------------------------------------------------
ID: 1640 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 8 Part I - The Schedule
Award Fee
Recommendation:
The Award Fee plan, Attachment 8, does not address issues such as base fee, the percentage of fee available for on-orbit performance (if any), or provisional interim billing. Will this be defined by the IPO or is it the responsibility of each offeror to submit an implementation plan? If the latter, at what time will this plan be required?
Rationale:
Common issues associated with award fee implementation.
Response:
The Government has decided not to include base fee which can be determined by by review of the CLIN structure. The determination regarding on-orbit performance incentives will be reviewed and decided at a later date. The Government will not allow the prepayment of Award Fee. Award Fee will not be paid until earned. The IPO will further refine the implementation plans regarding award fee and incentive fees as required through each phase of this acquisition.
------------------------------------------------------------------
ID: 1639 Date Recvd: 12/19/96 Status: Closed
Reference:
Attachment 9 11c and i
TEMPEST
Recommendation:
(1) What is the expected scope of the TEMPEST requirements identified in the DD Form 254 (e.g., single dedicated TEMPEST workstation)?
(2) What generic types of classified data will need to be received and generated?
Rationale:
Response:
(1) The TEMPEST requirement applies to the classified survivability requirements contained in SRD Appendix B which will not be made available until after contract award. At this time, the IPO does not anticipate that more than one TEMPEST workstation would be necessary.
(2) The generic types of data consist of reports and presentations to address survivability requirements.
------------------------------------------------------------------
ID: 1587 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 1, 1.3
Document Overview
Recommendation:
Content of Appendix C is stated to be "sounder/imager frequency ranges that will be displayed as SDR/TDR imagery for operational weather forecasting." In document SRD Appendices "A" through "H" the title of Appendix C is given as " Raw Data Record (RDR) Characteristics". Please clarify.
Rationale:
Clarification
Response:
TRD Para 1.3 changed to read "...Appendix C contains SDR/TDR requirements including potential sounder/imager frequency ranges that will be displayed as SDR/TDR imagery for operational weather forecasting." Note change in Appendix C also. SRD Appendix C will be tailored as it applies to each sensor.
------------------------------------------------------------------
ID: 1532 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 1.2, Page 1
Sensor Overview
Recommendation:
Delete the word "radiometry" in the first sentence. The recommended sentence is, The purpose of the CMIS is to collect global microwave and sounding data.
Rationale:
Consistent with the sensor title, CONICAL SCANNING MICROWAVE IMAGER/SOUNDER (CMIS).
Response:
One implication of a radiometeric system is a fully calibrated system, which is a requirement for CMIS. The term radiometeric will not be deleted from the reference.
------------------------------------------------------------------
ID: 1539 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 2, Pages 3-6
Applicable Documents
Recommendation:
In lieu of specifying standards and specifications, we recommend that all specs, standards, etc., be deleted from (or imposed as guidelines only), and the following be added to section 2. :
"To provide a cost-effective solution, the contractor may use industry, contractor, commercial, national or international standards and procedures or government specifications as appropriate. Offerors shall provide, as Annexes to their proposals, copies of existing industry/commercial/company/etc. practices or standards tailored for use on the CMIS Program. The Annexes will not count against the proposal page limit. Untailored, public-domain documents proposed for use upon CMIS need not be included in the Annexes, but shall be made available upon request by the Government. In the narrative sections of the Management Proposal the offeror shall identify and describe the standards and procedures that will be applied to each of the following areas:
i) System engineering, including system requirements analysis, and associated cost and performance trades and risk assessments
ii) Software development, management, documentation, quality assurance
iii) System reliability and maintainability
iv) Product assurance, configuration management, quality assurance, parts, materials, and processes management, survivability
v) Logistics support and documentation
vi) System safety
vii) Manufacturing and test planning and verification"
Rationale:
To ensure system continuity and backward compatibility when existing equipment/software is upgraded as part of NPOESS, the Government may still require the use of specific applicable standards to ensure equipment and software usability.
The approach above simplifies program compliance and reduces cost. It avoids the imposition of Military specifications that are on the list for cancellation (e.g., MIL-STD-1547B) and permits the offeror to bid the use of common methods thus increasing quality and reliability.
Response:
See comment # 2176.
------------------------------------------------------------------
ID: 1588 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 24, 3.2.1.17.1.1.1
Main Beam Efficiency Definition
Recommendation:
Referenced section 3.2.1.24.1 for HPBW should be 3.2.1.17.1.2.
Rationale:
Clarification
Response:
Yes, our reference is incorrect and needs to be fixed. (SDG 1/6/97).
------------------------------------------------------------------
ID: 1589 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 25 & 26, 3.2.1.17.2.2 & 3.2.1.17.2.2-1
Individual beam offsets
Recommendation:
Section numbers 3.2.1.17.2.2 and 3.2.1.17.2.2-1 are incorrectly numbered. Section numbers should be should be 3.2.1.17.2.4 and 3.2.1.17.2.4-1.
Rationale:
Clarification
Response:
Yes, this is incorrect and needs to be fixed. (SDG 1/6/97).
------------------------------------------------------------------
ID: 1590 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 27, 3.2.1.20.2-1
Earth Location Requirements - Allocations
Recommendation:
In the first sentence "for meeting the meeting the EDR Earth location requirements." should read "for meeting the EDR Earth location requirements as listed in Table 3-5."
Rationale:
Clarification
Response:
Section has been revised. Reference to the table is corrected. Note the table is a placeholder for the contractor flowdown which will take in account the spacecraft allocations (which have been inserted in the SRD).
SRDC3.2.1.12.2.1-1
The CMIS contractor shall be responsible for meeting the EDR Earth location requirements, based on the allocations from the spacecraft level as specified specified in Section 3.2.4.2.1.3.
------------------------------------------------------------------
ID: 1491 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.1.1 (Dec. 3 Update)
Other EDR's
Recommendation:
What is the implication of the category "Other EDR's ? Are they considered less important than the preceding EDR's?
Rationale:
Response:
Definitions of primary and secondary EDRs have been added to the glossary. The SRD has been revised to levy only those EDR attributes for which the sensor has primary EDR algorithm responsibility (primary EDR) as requirements on that sensor contractor. Requirements for the sensor to provide data as a secondary input to an EDR alorithm assigned to another sensor (secondary EDR) are TBR and will be established prior to SFR. Though not yet specified as requirements, the secondary EDRs are listed in the SRD to encourage investigation of secondary EDR capabilities in the sensor design. Note also that a sensor contractor shall identify specifications for any data required from other sources in order to meet the attribute requirements of the primary EDR assigned to their sensor.
Primary EDR
------------------------------------------------------------------
ID: 1533 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.1.1-1, Page 8
Sensor Description
Recommendation:
Delete the word "radiometric" in the first bullet. The recommending bullet is "Microwave imaging."
Rationale:
Consistent with the sensor title, CONICAL SCANNING MICROWAVE IMAGER/SOUNDER (CMIS).
Response:
Resolution/Answer: See answer to ID 1532.
------------------------------------------------------------------
ID: 1495 Date Recvd: 12/19/96 Status: Open
Reference:
CMISS SRD 3.2.1.1.1.1 ( Dec. 3 Update)
Swath Width and Vertical Measurement Column
Recommendation:
The requirement is for specified points along a local vertical. The CMIS will collect data along a slant path. There are two issues:
1. Interpolation between scans and beam positions, to allow data along a vertical to be obtained, will be very computationally intensive.
2. The available swath width for a complete vertical profile is somewhat narrower than the swath on the surface. Is the 1700 km swath width requirement applicable to the top of the profile, or to the surface?
Rationale:
1. A new beam location will be required about every 3.8 km height change in order to meet the 5 km mapping uncertainty requirement (for an incidence angle of 53.1 deg) prior to any interpolations. The interpolations themselves, although straightforward, impose an additional computation load.2. For example, to achieve a 1700 km swath width for an 80 km vertical profile, the resulting surface swath will be about 1880 km.
Response:
The swath width is currently defined as the arc-length, in meters, along a segment of a great circle on the surface of the Earth, which is locally perpendicular to the satellite ground track and extends equally on either side of the ground track. The swath width requirement is specified at the EDR level, which means that the 1700 km swath width is applicable to the top of the profile as well as the surface. The implication of defining the swath width at the EDR level is still under review.
------------------------------------------------------------------
ID: 1492 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec 3 Update)
EDR Requirements that Must be Satisfied by the Sensor Alone
Recommendation:
Sea Surface Temperature, Land Surface Temperature, and Vegetation Index/Surface Type are listed under the heading of "Other EDRs". Is this intended to distinguish them from the "Primary Allocated EDRs"? If so, what is the significance of being "Other" rather than "Primary"?
Rationale:
Response:
Yes, the intent is to distinguish them from the "Primary Allocated EDRs" as EDRs that the sensor contractor is not required to meet but that he may want to see what his sensor design will do toward allowing these EDRs to be met. Note that this section has been rewritten. See comment #1491.
------------------------------------------------------------------
ID: 1494 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec 3 Update)
Horizontal Cell Size
Recommendation:
Is the previously given definition of "Horizontal Cell Size", as the size of a square over which a parameter is estimated, still applicable? Is it intended that all EDRs except Imagery (40.2.3) will continue to be specified according to Horizontal Cell Size instead of Horizontal Spatial Resolution?
Rationale:
Response:
Yes, the definition given in the TRD for HCS is the current and correct definition.
Yes, only the Imagery EDR is specified by HSR and there are no plans at this time to change that specification.
------------------------------------------------------------------
ID: 1498 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Atmospheric Vertical Temperature Profile (40.2.2)
Recommendation:
Was it really intended to change the requirement for Horizontal Cell Size to 20 km, clear or cloudy, nadir or worst case? The change from 40 km to 20 km for the cloudy case is likely to be a significant design driver.
Rationale:
Response:
The change to 20km is a typo; it has been changed back to 40 and 50km.
------------------------------------------------------------------
ID: 1505 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Surface Wind Stress (40.7.10)
Recommendation:
The measurement range appears to be excessive. A stress of 50 N/m2 corresponds to a friction velocity near 7 m/s and a wind speed near 100 m/s at a height of 19.5 m. The maximum stress should be reduced by more than an order of magnitude. Adjustments to the required measurement accuracy and precision should also be made.
Rationale:
The wind stress may be considered to be a derived parameter from wind speed measurements. Using the experience with the SSM/I as an example, there appear to be little or no measurements matched with ground truth buoy winds available for speeds greater than 30 m/s at a height of 19.5 m. There is even a question as to whether any known wind speed algorithm would be valid at speeds near 100 m/s.
Response:
A TBR has been inserted on the measurement range to invite contractors to demonstrate what range is feasible during risk reduction.
------------------------------------------------------------------
ID: 1504 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Cloud Liquid Water Measurement Uncertainty (40.4.5)
Recommendation:
Cloud liquid water is easier to measure over ocean than over land in the microwave range. Are the thresholds reversed?
Rationale:
Response:
The uncertainty threshold over ocean has been changed to 0.25mm, and over land to 0.5mm.
------------------------------------------------------------------
ID: 1503 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Pressure Profile Measurement Accuracy (40.3.5)
Recommendation:
It is expected that the measurement accuracy will decrease with increasing height. Therefore, the 1% values in the 10-30 km region do not appear consistent with the 5% values in the 0-10 km range.
Rationale:
Response:
Per coordination with the JARG, the pressure profile specification has been revised as follows:
h. Measurement Accuracy
1. 0 - 2 km 1 % (TBR)
2. 2 - 10 km 5 % (TBR)
3. 10 - 30 km 10 % (TBR)
------------------------------------------------------------------
ID: 1502 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Consistency of Precipitable Water, Total Water Content, ...
Recommendation:
These are related EDR's with 40.3.3 being the vapor part of 40.3.6 and 40.4.5 the liquid water part of 40.3.6. However, there are inconsistencies.Horizontal cell size- 25km for 40.3.3 but 20km for 40.3.6 and 40.4.5Vertical Coverage- TBD for 40.3.6 but 0-30 km for 40.4.5Measurement Range- 0-75 mm for 40.3.3 but TBD for 40.3.6Measurement Accuracy- greater of 10% and 2 mm in 40.3.3 but 2 kg/m2, 1 kg/m2 global average for the TIWV part of 40.3.6Measurement Accuracy- 0.2 kg/m2 (ocean only) for the CLWC part of 40.3.6 but 0.5 mm over ocean and 0.25 mm over land for 40.4.5
Rationale:
Response:
Different EDR products are often required by different users, and the specifications for independent products need not be consistent. Note the following:
XSRD40.1.1-1
If a derived requirement conflicts with an explicit requirement and/or another derived requirement, the most stringent requirement shall be satisfied.
------------------------------------------------------------------
ID: 1501 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Soil Moisture (40.2.6)
Recommendation:
The measurement range is stated to be 0 - 100 cm/m. This means that the soil is totally flooded or over-saturated. Is this the intent? We recommend changing the units to percent saturation.
Rationale:
Response:
For volumetric soil moisture measurements the units are usually specified as cm3/cm3 or g/cm3. Gravimetric soil moisture is dimensionless and it typically given as a percentage (%). When the IPO requested clarification, the JARG reiterated the requirement for 1-100cm/m measurement range. The units of measure are, therefore, assumed to be the correct units for the user of this data. However, the value is flagged with a TBR to enable further investigation during risk reduction.
------------------------------------------------------------------
ID: 1499 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Wind Speed and Direction (40.2.5)
Recommendation:
The height at which the wind speed is to be reported is not specified. To remove ambiguities, it should be specified.
Rationale:
Response:
The SRD has been revised to specify that Ocean Surface winds are to be reported at 19.5 meters. The standard height for buoys is usually 10 meters, whereas the SSM/I and SSMIS use 19.5 meters for the wind speed height (the Navy specified 19.5 meter winds for the SSM/I). The wind speed should NOT be specified at the surface for several reasons. There are boundary conditions which depend on the local currents which are not included in the wind speed retrievals. The winds are usually desired in the near surface region where there is little or no turbulence and neutral stability. In the past the buoy winds have been used for algorithm validation by adjusting the 10 m buoy winds to the 19.5 m values using agreed upon algorithms. The 19.5 meter windsets are then used to tune the algorithms.
Action SE & CMIS RECOMMENDATION:
Revise the SRD and TRD AppD to specify that Ocean Surface winds are to be reported at 19.5 meters.
------------------------------------------------------------------
ID: 1497 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Vertical Moisture Profile Measurement Uncertainty (Cloudy) (40.2.1)
Recommendation:
The mixing ratio immediately outside a cloud may be very different than its value inside a cloud. In view of the fact that cloud base heights are not expected to be determined with accuracy much better than 2 km, is the threshold accuracy (20% and 40% for paragraphs 40.2.1-12 and 40.2.2-13 respectively) realistic?
Rationale:
Response:
Note first that there is no requirement for independent EDR products to be consistent. One user might require cloud height EDR product, while another requires the moisture EDR product. If the latter EDR requires specifying clouds better than the cloud EDR product specification, then that becomes a driver for cloud specification.
XSRD40.1.1-1
If a derived requirement conflicts with an explicit requirement and/or another derived requirement, the most stringent requirement shall be satisfied.
To specifically address the comment, even though uncertainty is an average over the HCS and VCS, it is likely, as the comment suggests, that imprecise knowledge of a cloud base height may result in a measurement uncertainty outside the required threshold for the vertical cell containing the cloud boundary. Per XSRD 40.1.7-1, the contractor can specify the conditions under which an EDR attribute cannot be met, such as at cloud boundaries.
------------------------------------------------------------------
ID: 1496 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Vertical Moisture Profile Measurement Uncertainty (40.2.1)
Recommendation:
The mixing ratio measurement uncertainty is expressed as a percent. Would it not be better to specify it in units such as gm/kg?
Rationale:
The vapor density may be extremely small in some situations (e.g. a very cold atmosphere or in the pressure range 300-100 mb). A percentage specification of the mixing ratio may be impossible to meet.
Response:
Note that the uncertainty above 300km is already TBR. The contractor is encouraged to recommend a minimum value below which uncertainty is specified as a recommeded absolute value rather than a percentage.
Note that for any EDR, the contractor is required to specify the conditions under which an EDR attribute cannot be met (in this case, as it's currently specified, the condition could be a minimum value of the mixing ratio).
------------------------------------------------------------------
ID: 1493 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
EDR Requirements that Must be Satisfied by the Sensor Alone
Recommendation:
Recommend that all EDR threshold values be indicated as TBR.
Rationale:
Many of the current threshold values pose substantial development risks, and virtually all should be considered as subject to cost/performance trade studies to be performed under contract. Especially risky are the accuracy requirements for moisture profiles (40.2.1), upper air temperature profiles (40.2.2), and precipitation (40.3.4). It would therefore be preferable to delay the establishment of all EDR threshold requirements until SRR.
Response:
The "threshold" values for the EDRs reflect the capabilities of the costed, notional baseline system as determined from Phase 0 studies. TBRs have already been inserted for those attributes considered to be higher risk. While the government does not want to discourage contractors from questioning baseline capability assumptions for all those "non-TBR" EDR attributes, the contractor should recongnize that the government considers these values to be within costed capabilities.
------------------------------------------------------------------
ID: 1500 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1 (Dec. 3 Update)
Soil Moisture (40.2.6)
Recommendation:
Are the thresholds rms uncertainties? Also, why are they higher for the clear case than the cloudy case. Cloud presence is expected to degrade the accuracy of soil moisture retrievals.
Rationale:
Response:
Yes, threshold uncertainties are RMS as per the glossary definition of measurement uncertainty. The clear and cloudy uncertainty specifications have been revised (reversed) to reflect better retrievals under clear conditions.
------------------------------------------------------------------
ID: 1591 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1-1 and 3.1.1-1
EDRs Required to be Measured by CMIS
Recommendation:
Land Surface Temperature and Vegetation Surface Type are listed as CMIS requirements in Section 3.1.1-1 but not in 3.2.1.1.1.1-1. Which is correct? (These are both given under the "Other EDR" category in 3.1.1-1 along with Sea Surface Temperature. The latter is, however, specified as a requirement in 3.2.1.1.1.1-1.)
Rationale:
Clarification needed.
Response:
The SRD will be revised to define "Other EDRs" as "Secondary EDRs" in 3.1.1-1 and 3.2.1.1.1.1. Land surface temperature and vegetation surface type are listed as Secondary EDRs. (See comment #1491)
------------------------------------------------------------------
ID: 1586 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.1.1-2 and -3
EDR Requirements that Must be Satisfied by the Sensor Alone
Recommendation:
-2 Recommend first sentence be changed to the following: Contractor shall be required to identify information required from other sources to satisfy EDR requirements. This information shall be supplied by the government.
-3 Recommend deletion of first sentence.
Rationale:
Absence of a contractual relationship with the other sensor and algorithm development contractors makes implementation as written not feasible.
Response:
Accept. See comment #1491.
------------------------------------------------------------------
ID: 1506 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.1.5
Algorithms
Recommendation:
The statement that the OATs will "provide the definition of the spectral bands and instrument sensitivities..." appears to give the OATs the primary responsibility for sensor requirements allocations. It would be more appropriate to assign this responsibility to the Contractor, with advice from the OATs. Such a revision would also be more consistent with paragraph 3.2.1.3.1, which states that "specific frequencies ... are TBD" (i.e. to be determined by the contractor). We recommend the following revision: "These teams, established and funded through the NPOESS IPO, will provide advice regarding the definition of the spectral bands and instrument sensitivities..."
Rationale:
Since the Contractor is held accountable for end-to-end performance of the proposed sensor and algorithms, the Contractor should have the final word on proposed allocated sensor requirements (during the preliminary design phase).
Response:
OATS role is advisory only.
------------------------------------------------------------------
ID: 1508 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.13.1.2
Absolute Radiometric Accuracy Requirement
Recommendation:
Recommend changing the calibration standard from TBD to TBR: "The CMIS calibration shall be traceable to a TBR calibration standard."
Rationale:
The government should be responsible for determining certain common requirements that will be applicable to all contractors.
Response:
Reject. The calibration standard will be left as TBD. (SDG 1/15/97).
------------------------------------------------------------------
ID: 1509 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.17.1.1.2
Main Beam Efficiency
Recommendation:
It appears that "Beam Efficiency" and "Main Beam Efficiency" have different definitions. Beam Efficiency (greater than 90% for all channels) is averaged over the channel bandwidth. Does this imply that Main Beam Efficiency, which is 92 to 95%, need not be averaged over the channel bandwidth ( ie; a single frequency measurement)? Main Beam Efficiency, as presently defined, is required to be greater than 95% for sounding channels and for all channels including imaging channels, above 12 Ghz. Is this the intent? We recommend that Beam Efficiency, for all channels, be TBD (as indicated by the reference to Table 3-4).
Rationale:
Further clarification of definitions, and consistency of requirements is needed. Since other sensor requirements contributing to overall scene brightness temperature measurement accuracy are to be allocated by the sensor contractor, it seems appropriate that Beam Efficiency should also be "TBD", based on end-to-end simulations performed during the contract.
Response:
There are several typos and a few inconsistencies with this section. We are in the process of revising this section. However, the Beam Efficiency will not be changed to TBD, but rather a minimum value is specified in order to obtain good SDR data as well as insure that the EDR requirements are met. This is essential for radiometric calibration and inter-sensor comparisons. (SDG 1/15/97).
------------------------------------------------------------------
ID: 1689 Date Recvd: 12/20/96 Status: Closed
Reference:
CMISS SRD 3.2.1.17.1.1.2-5
Main Beam Efficiency
Recommendation:
The main beam efficiencies should be TBR. This is a derived requirement that is dependent on the instrument design and should at this time be left as trade space.
Rationale:
Allow the contractor to perform trades and optimize the design.
Response:
No. We want to require at least a minimum value for the main beam efficiency in order to have good SDRs in addition to EDRs. In some instances this may require performance to be better than EDR threshold requirements. (SDG 1/16/97).
------------------------------------------------------------------
ID: 1534 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.2.2-1, Page 17
CMIS Channels
Recommendation:
Modify the last sentence on the bottom of page 17. The recommended sentence wording is, The types and numbers of channels shall be sufficient to satisfy the EDR requirements.
Rationale:
Consistent with the requirements of RFP Annex C, Statement of Objectives (SOO), page 3 2.0 and 2.2, Risk Reduction Phase Objectives.
Response:
We do not agree that the current language is "inconsistent" with the SOO and, therefore, do not see a reason to make a change.
------------------------------------------------------------------
ID: 1592 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.24, 3.2.1.1.1.2.1
Government Supplied Test Scenes
Recommendation:
(1) At what date will the government supplied test scenes be made available to the contractors?
(2) Will the supplied scenes contain horizontally homogeneous scenes or will they contain scenes of typical or extreme spatial variability?
(3) Will truth data be supplied (except of course for the five scenes reserved by the government)? Are working sessions anticipated between the contractor and the government in terms of defining the modeling approach, selecting the models to be used in generating the scenes, etc.?
Rationale:
(2) It is noted that section 3.2.1.1.1.2.1 only requires meeting of the EDR requirements for quasi-spatially-homogeneous scenes. Meeting the requirements for spatially varying scenes is a goal. To the extent the latter is to be addressed a top-hat spatial response function (as specified in this section) may not be sufficient to model the sensor spatial response especially for the higher spatial resolution channels. Also for the lowest frequency channels depending on the sensor design, this data may contain less than 10 x 10 pixels. This may not be adequate coverage to test certain aspects of the algorithms.
Response:
1. Standard datasets (scenes) will be made over a period of time, starting when the contractors supply specific bands for their sensor design. First dataset delivery can be expected 3 months (TBR) after sensor bands are provided. All standard datasets for any given sensor will be delivered to the contractor at least one year prior to PDR, i.e. the last dataset will be completed 1 year (TBR) before the sensor PDR.
2. The supplied standard datasets will contain both horizontal and vertical variability which is characteristic of real environmental conditions. We will include datasets which represent typical and extreme real conditions; specifically, horizontal variation represented over distances equal to the horizontal cell size will reflect underlying typical or extreme variations of the parameter in question, and will not be smoothed. (Section 3.2.1.1.1.2.1 will either be revised to clarify this point or deleted altogether.) Similar conditions will apply to vertical variations: variability will be representative of actual atmospheric conditions. Furthermore, standard datasets will provide at least 2X2 sample elements (pixels) for each parameter's threshold spatial resolution, e.g. if the horizontal cell size for a parameter is 4 km, the dataset will contain samples at 2 km resolution. Note that the top-hat response function referred to in the description in the SRD is for the spectral response across the sensor band, NOT a spatial response function of any kind. Thus we will model in-band radiance for each pixel as if the sensor responded equally to all wavelengths (frequencies) in the band, rather than, for example, as if the sensor response was Gaussian across the band.
3. The intent of the datasets given to the contractors is to allow them to test their designs against realistic data. Thus, truth data will be provided with all datasets released to contractors. We intend to describe our modeling process in detail to contractors, and may solicit comments on the approach and the specific models selected for use, but the IPO reserves the right to use whatever input data and model(s) it decides is most appropriate for the government's purposes.
------------------------------------------------------------------
ID: 1507 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.3.2.1.2
Frequency band exceptions
Recommendation:
Recommend changing TBD to TBR.
Rationale:
The government should be responsible for ultimately determining common constraints that will be applicable to all contractors.
Response:
What we really wanted to allow was that either the contractor or the government could propose exceptions. If the contractor submits a proposed exception it must be approved by the IPO.
This will not be changed to TBR. In order to better clarify our intent we plan to add wording similar to the following:
Additional exceptions requested by the contractor are subject to the approval by the IPO. The IPO reserves the right to modify the list of exceptions at any time. (SDG 1/15/97).
------------------------------------------------------------------
ID: 1596 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.1.8 through 3.2.1.12
Detailed specifications for RF channels
Recommendation:
The topics covered under these paragraphs (Dynamic range, linearity, quantization, channel gain, sensitivity, and measurement accuracy ) are allocations of the delta T specification to ensure the accuracy of the EDR's. These paragraphs should be deleted.
Rationale:
Different implementations may require different error allocations to the RF channel requirements. The CMIS contractor should be given the freedom to allocate these RF specifications in an error budget to provide a better product.
Response:
DO NOT AGREE. These are NOT all allocations to the NEDT specification. For example we want to specify a linear radiometer transfer function over the required dynamic range, independent of any NEDT requirements. The requirements listed in the SRD DO NOT preclude any trade off design optimization by the contractor. They do, however, provide guidance as the what system parameters are considered important and those for which the contractor will be held accountable.
------------------------------------------------------------------
ID: 1510 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.2.5.1
Reliability
Recommendation:
The CMIS Sensor Suite reliability is specified as 0.84 minimum. Over what operational interval does the 0.84 probability of CMIS performing it's intended function apply?
Rationale:
The probability of performance is a function of the operating interval.
Response:
See comment #1762.
------------------------------------------------------------------
ID: 1540 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.3.1.2, Page 41
Parts Selection
Recommendation:
Delete the last sentence of paragraph 3.3.1.2 and replace with the following: "Parts for space usage shall be chosen to meet the CMIS reliability and operational service life requirements. Parts shall be selected in accordance with the contractor's Parts Management Plan and the contractor shall be able to demonstrate via data or analysis that all parts meet the CMIS reliability and operational service life requirements."
Rationale:
The RFP requires parts to be selected "in accordance with MIL-STD-1547B"; (also references NASA PPL-21). Most parts suppliers are unwilling to meet MIL-STD-1547B special testing requirements; when suppliers will perform the special testing it is at an enormous cost impact (cost delta of up to 20:1 for many parts). MIL-STD-1547B is scheduled for cancellation March '97.
Response:
Concur. Requirement rewritten as suggested and MIL-STD-1547B deleted from Section 2. MIL-STD-1547B added to Reference documents.
------------------------------------------------------------------
ID: 1541 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.3.1.4, Page 42
Finishes
Recommendation:
Change second sentence to read: "Neither cadmium nor zinc nor tin platings for sensors shall be used."
Rationale:
Prohibition of "tin coatings" poses problem with industry-wide solder styles: most are tin based and involve solder-coated leads. Suspect that the wording is in error: should be "tin plating" not "tin coating."
Response:
Sections on finishes and coatings merged and revised as follows:
SRD3.2.4.6-4
The sensors shall not use cadmium or zinc platings.
SRD 3.2.4.6-5
Pure tin or tin alloy (>98% Sn TBR) plating shall not be used on electrical devices and hardware for launch and space vehicles. The guiding document for this prohibition is MIL-STD-1547B, "Electronic Parts, Materials, and Processes for Space and Launch Vehicles."
------------------------------------------------------------------
ID: 1572 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.3.12.7.5
Sensor disturbance allocations
Recommendation:
Recommend that static & dynamic imbalance requirements be provided in paragraph 3.3.12.7.5.1.
Rationale:
Preclude conflict with spacecraft contractor
Response:
A new figure defining allowable transmitted torque requirements has been added.
------------------------------------------------------------------
ID: 1542 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 3.3.6, 3.3.6.1, Page 44
Safety Requirements
Recommendation:
Delete references to EWRR 127-1 in 3.3.6, and replace with "EWR 127-1". Delete the first sentence of 3.3.6.1 (which deletes reference to ERR 127-1, WRR 127-1 or CSTCR 127-1)
Rationale:
Offeror standardizes on EWR 127-1 for range safety requirements (suspect that "EWRR 127-1" may be typo). EWR 127-1 replaces ERR 127-1 and WRR 127-1 (CSTCR 127-1 is obsolete).
Response:
EWRR 127-1 replaced with EWR127-1 in the TRD. Correction will be made to SRDs. Ref. TRD para 3.3.6
------------------------------------------------------------------
ID: 1688 Date Recvd: 12/20/96 Status: Closed
Reference:
CMISS SRD 3.3.9.1
COMSEC
Recommendation:
From an instrument perspective, it would appear that this requirement should be deleted.
Rationale:
Currently encryption of data, commands or telemetry is not done in the sensor packages. It would have cost and design impacts on all of the sensors. If required, it would more effectively be done at the vehicle level.
Response:
Agree. This requirement has been deleted. Encryption is a spacecraft command and data handling subsystem function and there is no requirement allocated to the sensor.
------------------------------------------------------------------
ID: 1543 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 4, Page 58
Quality Assurance Provisions
Recommendation:
Replace Section 4.1 with the following. "The contractor shall prepare a CMIS Product Assurance (Quality) Plan and a CMIS Test Plan. These plans will serve as the requirements documents to be implemented by the Contractor, Subcontractors and suppliers. All quality requirements and test specifications to be used on the program shall be referenced in this plan. Contractors need not modify their standard plans but should provide a cross-reference table to show implementation of the following subsections."
Rationale:
Recent initiatives by the government have emphasized the idea of single processes for contractor activities. Offeror has already received approval on a Single Process Initiative that converted from a Quality Management System based on Military Standards and the elements/criteria of ISO 9001 to a Common Process of an ISO 9001-based system.
Response:
The government is not precluding that the contractor submit tailoring of internal procedures. However, note that these plans should not be called out at this time; they will not be required until the Call For Improvement. The processes for developing the plans are asked for in the IMP instructions.
------------------------------------------------------------------
ID: 1574 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 4.2.1.1.3.12
Shock
Recommendation:
Recommend the contractor be permitted to tailor the test requirement spec and a desired test plan
Rationale:
Allows the Customer to evaluate the acceptability of the test in accordance with current industry practices for lower level testing (tailoring).
Response:
This paragraph allows for the contractor to establish his own test program as long as he can demonstrate that he can survive the levels shown in Figure 4-3, which are the predicted launch values that will be encountered. The IMP instructions under Test and Evaluation process asks for the contractor's test approach and processes.
------------------------------------------------------------------
ID: 1573 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 4.2.1.1.3.9
Thermal
Recommendation:
Reference states thermal vacuum test is not required, but if performed, requires 65 cycles
Recommend the contractor be permitted to tailor the test requirements spec and propose a desired test plan.
As I mentioned above, this could be a deliverable for the risk reduction phase. That would let the contractors develop their own approaches, and let the customer evaluate the approaches as part of the downselect criteria. (i.e.; we may be able to show analysis/test/performance verification methodology that are more cost-effective or innovative than what is in MIL-STD-1540C or other places)
Rationale:
Allows the Customer to evaluate the acceptability of the test in accordance with current industry practices for lower lever testing (tailoring).
Response:
The entire section on thermal testing was revised. The levels and duration will be left up to the contractor as long as it conforms to 1540C. The statement was a typo and thermal vacuum is required at 6.5 cycles, not 65. The offeror is encouraged in the IMP instructions to tailor specifications or offer alternatives. In addition, the offeror's test and evaluation process is to be described as part of the IMP.
------------------------------------------------------------------
ID: 1513 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD 6.2
Definition/Glossary
Recommendation:
The definitions of Alignment Knowledge and Alignment Accuracy appear to be interchanged. Knowledge should be relative to estimated orientation, and Accuracy relative to desired orientation.
Rationale:
Response:
We don't understand the question. There is no Section 6.2. The SRD glossary is identical to that used for the TRD, but the terms Alignment Knowledge and Alignment Accuracy are not included. In the CMIS SRD, this topic was covered in para 3.2.1.20.1, but the contractor comment is not applicable.
------------------------------------------------------------------
ID: 1593 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Appendix D 40.4.5
Cloud Liquid Water
Recommendation:
The specification for cloud liquid water measurement uncertainty over land is less than that over water. Is this correct?
Rationale:
In general, this parameter is measured more accurately over water than land (i.e., the land value should be greater). Please clarify.
Response:
See response to Comment Number 1504.
------------------------------------------------------------------
ID: 1594 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Appendix D Ð 40.2.4
Sea Surface Temperature
Recommendation:
(1) The preface to this EDR states that the requirements pertain only under clear conditions. Do any requirements pertain under cloudy conditions which is when section 3.2.1.1.1.1-1 specifies that the CMIS is to make this measurement.
(2) Is a skin temperature or a bulk layer temperature required? Or are both required?
Rationale:
(1) By comparison to the VIIRS requirements, one might assume that all requirements except Measurement Uncertainty and Mapping Accuracy apply.
(2) Land and Ice Surface Temperature EDRs specify skin temperature (at least for the thresholds).
Response:
(1) The specific EDR attribute requirements allocated to CMIS have been clarified in the revised CMIS SRD Primary EDR section.
(2) The text has been clarified as follows: Sea surface temperature (SST) is defined as the skin temperature of the of ocean surface water. The measured radiances should enable the derivation of both skin and surface layer (1 meter depth) sea surface temperature to the specifications listed below, though an EDR algorithm is only required for skin temperature.
------------------------------------------------------------------
ID: 1646 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Page 24, para. 3.2.1.16.2
CMIS Horizontal Spatial Resolution
Recommendation:
Does the Nyquist criteria hold for both the along track as well as the along scan sampling?
Rationale:
Requirements clarification.
Response:
Currently, the SRD only requires Nyquist sampling in the cross track (along scan) direction. The requirement for Nyquist sampling in the along track direction is TBR. (SDG 1/16/97).
------------------------------------------------------------------
ID: 1645 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Page 24, para. 3.2.1.16.2
CMIS Horizontal Spatial Resolution
Recommendation:
Nyquist can be defined as 1/2 the dwell time, where the dwell time is a function of the along scan instantaneous field of view (IFOV) and the scan rate. Is this the intended definition of Nyquist criteria?
Rationale:
Requirements clarification.
Response:
No this is not the intended definition. Nyquist is defined in terms of the highest spatial frequency required to be passed by the pre-sampling filter based on the EDR requirements. The above statement can be derived from this definition so they are not inconsistent.
------------------------------------------------------------------
ID: 1576 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Para 3.2.1.15
Sensor structural dynamics
Recommendation:
The deployed frequency requirement is left open in this spec, and left to the spacecraft prime contractor. Recommend that the deployed frequency be TBR as an accommodation may be needed.
Rationale:
Issue requires a systems solution
Response:
Agree, will be changed to TBR.
------------------------------------------------------------------
ID: 1585 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Para. 3.1.6.2.2
Launch
Recommendation:
Recommend sensor be in inert condition during launch.
Rationale:
Avoids inadvertent response to erroneous command; reduces probability of improper deployment; etc.
Response:
Good point. The SRDs do not preclude the sensor(s) being off during launch. We don't see any need for a power-on condition during launch, but we are leaving leaving this to the determination of the contractor.
------------------------------------------------------------------
ID: 1566 Date Recvd: 12/19/96 Status: Closed
Reference:
CMISS SRD Pg 13, SRDC3.2.1.1.1.1-1
Key EDRs
Recommendation:
EDR list on page 13 is inconsistent with change page for section 3.1.1, SRDC3.1.1-1. Key EDR inconsistencies are; Sea Temperature and Cloud Base Height. Other EDRs are not included on page 13.
Rationale:
Clarification
Response:
Yes this section needs to be cleaned up. We are revising these lists. (SDG 1/15/97).
------------------------------------------------------------------
ID: 1701 Date Recvd: 12/20/96 Status: Closed
Reference:
CMISS SRD Appendix D 40.2.3
Imagery, Horizontal Spatial Resolution
Recommendation:
The HSR requirement for 20 km @ 19 Ghz drives the CMIS reflector diameter to be very large. Is the HSR requirement of 20 km @ 19 Ghz correct?
Rationale:
Verification of intent in view of significant impact on sensor size.
Response:
For Imagery, Horizontal Spatial Resolution of 20 km @ 19 GHz is correct. [JSB1]Above 700mb this information is known to within 5% at all times RC.
------------------------------------------------------------------
ID: 1961 Date Recvd: 12/20/96 Status: Open
Reference:
Common VIIRS, CrIS SRDs
System Operations Concepts
Recommendation:
Philosophy of sensor operations is different, as embodied, for instance, in the definition of modes and states for sensors. Will there be any attempt to standardize sensor concepts across suits, or is each suite to be uniquely defined by its SRD?
Rationale:
Significant benefits of consistent operational philosophies and conceps across multiple instruments
Response:
The intent is to have a mimimum level of standardization across the sensors. We started out this way and seem to have diverged. The documents will be reviewed and a minimum set of modes called out for each. This set will include On, Off, and SafeHold as a minimum. In addition to these, there may be specific modes, such as a calibration mode, which are instrument specific. An example would be that a visible radiometer might be required to go into a sun-viewing calibration mode, while a microwave sounder would clearly not have such a mode.
------------------------------------------------------------------
ID: 1962 Date Recvd: 12/20/96 Status: Open
Reference:
Common VIIRS, CrIS SRDs
System Concepts
Recommendation:
Level of detail and visibility into system concepts, definitions, approaches are not consistent among the various SRDs. How can, or should, the Payload Developer develop a consistent view of the system and development concept for NPOESS?
Rationale:
Understanding of customer directed concepts.
Response:
Not VIIRS/CrIS specific. (Ideally, the SRDs should provide a common view of any system concepts or constraints that the government wishes to convey at this time to the payload contractors. Inconsistencies among the SRDs can only arise in the suite-unique sections. Recommend that all material conveying system concepts, approaches, etc., be identified in all the suite-unique sections, removed from these sections, and any material which the government wishes to retain can be placed in the generic section of the SRD. This should resolve the inconsistency problem.)
Replace the existing response with the following: Agree. The intent of the IPO is to have consistency among all of the documents regarding the system description, concept and constraints. The documents are currently under review to remove any such inconsistencies.
------------------------------------------------------------------
ID: 1660 Date Recvd: 12/20/96 Status: Closed
Reference:
Cover Letter and Part I- The Schedule first page of cover letter
Pricing of CLINs
Recommendation:
The cover letter states that initial proposals will only be required to price the first phase of this effort. Please define specifically which CLINs are to be priced for this effort.
Rationale:
Clarification
Response:
Initial proposals must price the CLINs associated with the Definition & Development of Preliminary Design for each of the sensors being bid. For the VIIRS, for example, this set of CLINs consists of CLINs 0001 & 0002. The Option CLINs represent the CLINs to be priced in conjunction with the subsequent Call for Improvements proposal and the down-selection.
------------------------------------------------------------------
ID: 1571 Date Recvd: 12/19/96 Status: Closed
Reference:
Cover Letter Memorandum dated 11/18/96 Page 1, paragraph 3, first sentence
Contract Type
Recommendation:
Recommend that the cover letter be modified to reflect the CPFF nature of the first phase and CPAF nature of subsequent phases.
Rationale:
Clarify RFP.
Response:
The cover letter will be revised for formal RFP release to include all appropriate information.
------------------------------------------------------------------
ID: 1843 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-1543B, Reliability Program Requirements for Space and Missile Systems be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-1543B will have significant impacts to both cost and schedule. While MIL-STD-1543B provides excellence guidance, it should be tailored to allow cost effective reliability engineering. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
See comment #1702
------------------------------------------------------------------
ID: 1844 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-1546B, Parts, Materials and Processes for Space and Launch Vehicles, be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-1546B will have significant impacts to both cost and schedule. While MIL-STD-1546B provides excellence guidance for the selection of parts for space systems, it should be tailored to allow for a cost effective Processes, Material, and Parts (PMP) program. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
See comment #1702
------------------------------------------------------------------
ID: 1845 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-1547B, Electronics Parts, Materials, and Processes Requirements for Space Vehicles be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-1547B will have significant impacts to both cost and schedule. While MIL-STD-1547B provides excellence guidance for the selection of parts for space systems, the commercial communications satellite business has demonstrated that in many applications, non-MIL-SPEC parts perform just as well as the MIL-SPEC parts over long lifetimes (>10 Years) and are significantly lower in cost and can be procured in shorter times. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
See response to #2176.
------------------------------------------------------------------
ID: 1846 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that ERR 127-1 and WRR 127-1 be either deleted or made reference documents
Rationale:
EWRR 127-1, Eastern and Western Range Safety Requirements, replaces both ERR 127-1 and WRR 127-1.
Response:
ERR 127-1 and/or WRR 127 will be replaced with the current document designation of EWR 127-1, 31 Mar 95.
------------------------------------------------------------------
ID: 1847 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that EWRR 127-1 be tailored to the NPOESS instruments or program needs.
Rationale:
The EWRR 127-1 is a top level safety regulation that was intended to be tailored to fit each programs needs. Compliance with all contractually imposed requirements of the EWRR 127-1 is mandatory if it is not tailored. Tailoring of the EWRR 127-1 can only be done by the Range User and Range Safety. Obtaining Range Safety tailoring now will reduce throughout the program and avoid costly modifications/deletions later on.
Response:
The contractor may recommend tailoring or substitution of any of the required compliance documents (see comment #1702). The program office will negotiate any contractor recommended tailoring with the Range User and Range Safety.
------------------------------------------------------------------
ID: 1842 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-83577B, Moving Mechanical Assemblies, be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-83577B will have significant impacts to both cost and schedule. While MIL-STD-83577B provides excellence guidance for the design of moving mechanisms, some commercial practices have been successfully demonstrated. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
See comment #1702
------------------------------------------------------------------
ID: 1723 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.1, 3.2.1.1.1.1 (comment is relevant to both)
Sensor description (Michelson Interferometer) and EDR requirements (Atmospheric Temperature Profile).
Recommendation:
The EDR listing in section 3.2.1.1.1.1 of the CRIS SRD does not contain the requirement for atmospheric temperature profiling between 30 mb and 0.01 mb. This limitation to the measurement range of the CRIS effectively rules out consideration of infra red solutions for this measurement requirement including a well proven infra red technique which has extensive flight heritage and is well matched to this altitude regime. It is considered that at this early stage on NPOESS development it may be to IPO's advantage to have alternatives open to it for this important measurement. It is respectfully suggested, therefore, that the CRIS SRD should be modified to permit techniques additional to Michelson Interferometry to be included in the CRIS package and to reflect the full atmospheric temperature profiling EDR.
Rationale:
The reason for IPO s recent change to the acquisition strategy for NPOESS is to permit the US Government to select the best sensor combination for the programme. However, it is noted from the DRFP that while both CRIS and CMIS are jointly tasked with retrieving atmospheric temperature profiles only the CMIS is required to offer performance at pressures below 30 mb. In the light of IPO s overall objectives this restriction of the upper atmospheric temperature profiling requirement to the microwave rules out consideration of alternative solutions including a proven infra red technique which has a long and successful flight heritage over 20 years (NIMBUS, NOAA, UARS & planetary missions) in high altitude terrestrial and planetary atmospheric observations. This technique, for which the UK has the IPR, is the basis of an instrument concept which has been the subject of discussion between MMS (UK) and a number of major US contractors over the past two years in respect of the NPOESS programme. It is considered that it would be to the distinct advantage of the IPO to modify the CRIS SRD to expand the temperature profiling performance requirement to cover the entire range (ie to 0.01 mb) and to permit, in principle, additional technique(s) to Michelson Interferometry to be incorporated in the infra red sounding package. This would permit the IPO to have visibility of both microwave and infra red solutions to the measurement requirement below 30 mb and would allow it to compare the effectiveness, risks and costs of two very different technologies. It would also appear to be fully in line with the stated objectives of the revised acquisition approach. In support of the rationale for examining approaches to the upper atmosphere temperature profiling requirement in the infra red as well as the microwave, it is relevant to note that the weighting functions for infra red sounders are unaffected by the terrestrial magnetic field. Microwave sounding, however, is affected and while the affects can be modelled, it may be particularly difficult to do this to the required accuracy at higher latitudes. In such circumstances, localised magnetic field fluctuations which could produce very significant changes to brightness temperature may not be readily detectable from the satellite itself or may be difficult to model. These difficulties would be wholly avoided in the infra red.
Response:
Item 1 -- Assertion that CrIS SRD does not contain EDR requirements for AVTP between 30 mb to 0.01 mb is incorrect. All EDR requirements derived from Appendix D and assigned to CRIS will be incorporated into CrIS SRD Section 3.2.1.1.11 for clarity.
Item 2 -- Recommendation to revise text in CrIS SRD Sections 3.2.1 and 3.2.1.1.1.1 to permit techniques other than Michelson Interferometry runs counter to the approved NPOESS acquisition effort which is predicated upon building upon Phase 0 study efforts to further reduce risk and provide an alternate technology path over other related USG efforts in this area. However, note that the RFP does allow for alternate solutions and contractor proposed innovation. See Section L.2.
------------------------------------------------------------------
ID: 1756 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.1 Satellite Interface Adapter
Figure - Crls System Diagram
Recommendation:
The figure suggest that the sensor will interface with the spacecraft via an interface plate. Recommend changing the label "satellite interface plate" to "spacecraft interface" to avoid misunderstanding.
Also, recommend changing the label "satellite bus" to "spacecraft".
Rationale:
Standard terminology
Response:
Concur. The interface plate is being dropped and will change 'satellite bus' to spacecraft.
------------------------------------------------------------------
ID: 1851 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.16
Signal Processing
Recommendation:
Please clarify paragraph wording; there appears to be a grammatical mistake.
Rationale:
Response:
Concur. Subject text to be revised to read as follows: '.... stream, so that there will be no information loss ....'
------------------------------------------------------------------
ID: 1852 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.18
Command and Control
Recommendation:
There is reference to paragraph 2.1.5 which does not exist in the CrIS SRD. Should the referenced paragraph be 3.2.4.10?
Rationale:
Response:
Concur. Subject reference paragraph numbering to be changed from "2.1.5" to "3.2.4.10".
------------------------------------------------------------------
ID: 1757 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.3 Optical Bench
SRDK3.1.2.3-1 The optic bench orientation with respect to the satellite bus shall be known to 10% of the ground pointing error.
Recommendation:
Recommend following specification:
SRDK3.1.2.3-1-The optic bench orientation with respect to the satellite bus shall be known to 10% (TBR) of the ground pointing error knowledge requirement.
Rationale:
The addition of the TBR to the 10% requirement would let system error budget analyses determine what is the actual required alignment. A restrictive requirement may have unnecessary cost impact.
Also, it should be pointed out that the requirement is for pointing knowledge, not pointing accuracy.
Response:
Concur. Text to be revised to reflect the equirement is for pointing 'knowledge', not pointing 'accuracy'' along with the addition of '10% (TBR)' value to be added to the specification for subsequent refinement.
------------------------------------------------------------------
ID: 1848 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.7
Moving Mirror Servo Subsystem
Recommendation:
Request that the word "saw-tooth" be deleted.
Rationale:
Whether the interferometer servo is saw-tooth or bi-directional should be a design option traded by the contractors early in the program. Does it matter that the servo be a saw-tooth as long as it is linear?
Response:
Concur. The word "sawtooth" to be deleted.
------------------------------------------------------------------
ID: 1849 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.2.9
Fixed Mirror Arm
Recommendation:
Request paragraph wording be changed to "Use of an adjustable fixed mirror, a mirror which is nominally stationary during interferometer scan but requires initial alignment, must be adjustable on orbit using ground commands."
Rationale:
The need for an adjustable fixed mirror should be decided by the contractor and be based on overall interferometer design and performance. There may be interferometer designs which do not require initial adjustments or use adjustable mirrors. Requirements will be established during SRR and SFR. Design trades will then follow in support of PDR.
Response:
Entire section being revised to ensure greater clarity. Sextion text to be revised as follows: Section Title 'Fixed Mirror Arm' to be replaced by 'Alignment Monitor Subsystem'. Figure text to replace 'Fixed Mirror Alignment' with 'Alignment Monitor'. Seciton 3.1.2.9 replacement text to read: 'The dynamic alignment monitor subsystem shall measure mirror alaignment continuously during interferometer operation.' Editorial Note: Bringing the instrument into alignment and providing means and procedures to realign it periodically are left to the contractor as an open design issue to be addressed as part of their proposed concept through PDR.
------------------------------------------------------------------
ID: 1854 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.1.4
Top Level Sensor Functions
Recommendation:
It is not clear whether or not the CrIS is to transmit raw interferogram data or on-board processed spectral data. Please specify.
Rationale:
Data can be transmitted to the ground in several formats; some examples: raw interferogram data, FFT processed spectral data, or decimated and bit trimmed interferogram data. The type of transmitted data will have a large effect on the sensor design, especially the electronics.
Response:
Whether Raw data or processed spectral data gets processed on-board and transmitted from the S/C is a trade that needs to be considered by the contractor during SRR and SFR. For clarification purposes, the text in this section will be revised to include this additional information. Note: The following text will also be added under 3.12.1.: "The downlink data stream should include all data required to apply a proper calibration on the ground and housekeeping data required to determine the health and operational state of the instrument as defined in 3.1.2.17. Data compression either using filtering and decimation of the interferogram or FFTs is desireable."
------------------------------------------------------------------
ID: 1855 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.2.1
Definition, SRDK3.2.1.1.2.1-1
Recommendation:
"Sensor Data Records shall be provided." Shall sensor data Records shall be provided by the CrIS contractor, or are they supplied in some other manner (OAT, IPO, NESDIS, AFGWC, etc.)?
Rationale:
Statement is unclear as to whether the SRDs are to be provided by the contractor. The CrIS appears to be a specified sensor with algorithms.
Response:
The sensor contractor is responsible for providing operational RDRs and the scientific algorithms for processing SDRs and EDRs. Government agencies, through OATS, may only recommend SDRs to the sensor contractors.
------------------------------------------------------------------
ID: 1857 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.2.2.1
Earth Location Requirements
Recommendation:
The second sentence may be in conflict with the first sentence.
Rationale:
The CrIS SRD should be very clear with no ambiguity and therefore it is recommended that the second sentence be eliminated.
Response:
Non-concur. In cases of ambiguity the more stressing of two requirements must be satisfied. The hard requirement is the more stringent of the two - i.e. temperature/humidity or support to another product where coregistration of observations is required.
------------------------------------------------------------------
ID: 1856 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.2.2.1
Earth Location Requirements, SRDK3.2.1.1.2.2.1-1
Recommendation:
There are several methods of defining mapping accuracy. Please provide a clear definition of Mapping. Is it the earth location/geo location error characteristics.
Rationale:
Unclear definition.
Response:
Mapping Uncertainty (as defined in Appenidix A glossary) is the RMS error (one sigma) in the geolocation of measured or derived data samples expressed in geodetic coordinates based on a large number of repetitions of the measurement and/or derivation under identical conditions. An "error" is defined as the difference between the measured or derived value and the true value of a parameter. Mapping uncertainty is due to the combined effect of all systematic and random errors affecting geolocation. The SRD text will be revised to clarify use of the term.
------------------------------------------------------------------
ID: 1858 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.4.1
RDR definition
Recommendation:
Since RDRs have met their requirement when they are of an appropriate format and quality, then can the IPO define the format, and quality of the RDRs, or have they been considered to be in the appropriate format and quality if the EDRs that are constructed from them meet the thresholds.
Rationale:
The quality and format of the RDRs need better definition
Response:
No revision necessary. The RDRs are considered to be in the appropriate format and quality if the EDRs constructed from them meet the thresholds.
------------------------------------------------------------------
ID: 1859 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.5
Algorithms
Recommendation:
Operational EDR retrieval algorithms shall be provided by the contractor. If the operational algorithms are supplied by the CrIS contractor, are they supplied to all the IDPSs of DOD and NOAA/NESIS? Are the operational algorithms provided in software form such as operational quality software or R&D software?
Rationale:
Not clear as to what exactly is to be provided and to whom.
Response:
The reference definition of "operational code" has been deleted and the text revised to clarify that the sensor contractor is responsible for the operational RDR algorithms (sensor output) and for the science (R&D code) which processes RDRs into SDRs and EDRs. The IDPS contractor (System contractor) is responsible for the operational IDPS code which processes RDRs into SDRs and EDRs.
------------------------------------------------------------------
ID: 1860 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.1.5-1
Algorithms
Recommendation:
Operational is defined here as retrieval algorithm approaches that when translated into convertible processing code are capable of producing subject EDR's within the timeline specified. What or where is the timeline specified?
Rationale:
Information required to produce specification.
Response:
Text will be revised. Processing timeline is a requirement for operational code which is the responsibility of the IDPS contractor (system contractor), not the sensor contractor. See response to comment #1859.
------------------------------------------------------------------
ID: 1861 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.18
Spectral Resolution
Recommendation:
The conventional definition for unapodized spectral resolution is one over twice the maximum optical path difference, whereas apodized spectral resolution is defined as one over the maximum optical path difference. Depending on the type of apodization some other fraction might be used. Which definition is intended?
Rationale:
Response:
For clarity section heading will be changed from "Spectral Resolution" to 'Spectral Range" and the text "The unappodized ... in the table below." will be replaced by "The minimum spectral range and maximum unapodized spectral resolution are tabulated below." Note: Spectral resolution is defined in section 3.2.1.20.4 (see comment ID 1862).
------------------------------------------------------------------
ID: 1862 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.20.4
Unapodized Spectral Resolution
Recommendation:
As mentioned above for Paragraph 3.2.1.18, Spectral Resolution, the definition provided is not the conventional definition.
Rationale:
The conventional definition for unapodized spectral resolution is one over twice the maximum optical path difference, whereas apodized spectral resolution is defined as one over the maximum optical path difference. Depending on the type of apodization some other fraction might be used. Which definition is intended?
Response:
For clarity following text will be inserted in Section 3.2.1.20.4: 'The Unapodized Spectral Resolution is defined as the reciprocal of the maximum optical path difference, i.e. if the OPD change is +/- L, the total double sided maximum OPD change is 2L and the wavenumber step size is 1/(2L).' This is the definition that is intended.
------------------------------------------------------------------
ID: 1863 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.23
System Linearity
Recommendation:
This requirement should be deleted.
Rationale:
The SRD should specify the required spectral and radiometric accuracy and precision only. Channel linearity is an internal sensor characteristic that should be decided by the sensor contractor.
Response:
Concur. Issue/concern is "knowledge of linearity" which itself will be reduced in Section 3.2.1.23 to a measurement requirement (i.e. a requirement for a measurement) by the insertion of the following text: 'The nonlinearity of the spectral channels must be measured and demonstrated to be stable enough to meet all radiometric requirements.'
------------------------------------------------------------------
ID: 1864 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.25.1
NEDT / SNR Requirements Definition
Recommendation:
NEDT is defined at 250K in this paragraph. This does not agree with Table 3-2 which specifies the NEDT performance requirements. Paragraph 3.2.1.25.1 should be deleted to eliminate confusion.
Rationale:
Response:
Section currently under revision. The next draft of the CrIS SRD will define the Earth scene temperature at which NEDN (w/cm2-sr-cm-1) values are to be measured. These NEDN values will be for given ground scenes, and more appropriately for ground testing, at a given black body temperatue.
------------------------------------------------------------------
ID: 1894 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.25.2
Recommendation:
The IPO will provide scene-derived spectral radiances given contractor-specified band passes and IPO-specified forward models. Any retrieval algorithm (inverse models) not wholly compatible with the forward models will yield erroneous results. These errors could dominate over instrument errors and fundamental errors in the retrieval algorithm.
Rationale:
There is not general community consensus over many aspects of a scene description. For example, cloud definitions can vary widely. Subtleties in multiple scattering for atmospheric correction over the ocean, atmospheric correction over Case 2 waters, the selection of Lambertian or anisotropic bi-directional reflectance distribution models for the land surface, choice of surface emissivities, and tens to hundreds of other attributes all affect the retrieval.
The process of IPO provided scene radiances will drive the contractors towards selecting retrieval algorithms optimized for the simplifications in the scene radiances, not refined toward the actual Earth. The OATS-provided algorithms may become of little practical use if they are not defined consistently with the IPO simulations, as they will yield incorrect solutions. The end result may be to negate the benefit of using simulations to test the instrument/algorithm end-to-end EDR system solution.
There are two possible solutions: (1) accept that scene simplifications are inevitable, and permit the retrieval algorithms to be simplified to be inverses of the forward models -- in this case, the testbedding process does not permit solutions to be optimized for the real world, and the instrument and algorithm designs cannot be refined to meet subtle physical effects; (2) facilitate the joint development (involving the IPO, the contractor, and the OATs) of consistent scene simulations, retrieval algorithms, and sensor designs -- as necessary withhold subtleties of the EDR solution from the contractor within a predefined set of blind tests.
Response:
The IPO will model all first order effects as well as most of the major second order effects associated with the radiative transport portion of standard dataset creation, as appropriate for each sensor type. In some cases selected third order effects may be included also. Contractors are encouraged to submit to the IPO lists of the effects they consider to be first and second order for their particular sensor / algorithm combination(s). These inputs will be reviewed by the IPO and by the relevant OATS group and changes in the IPO modeling strategy may result. However, joint development of scene simulations tuned to specific algorithms or radiative inversions will make it impossible to test EDR performance across competing designs, and this will not take place.
------------------------------------------------------------------
ID: 1867 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.26.1
Absolute Radiometric Accuracy
Recommendation:
Second paragraph, should "tractability" be "traceability"?
Rationale:
Response:
Concur. Typographical error in second paragraph. "Tractability" to be replaced by "Traceability".
------------------------------------------------------------------
ID: 1868 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.1.28
CrIS Sensitivity Validation and Calibration
Recommendation:
Subparagraph numbering is in error.
Rationale:
Subparagraphs include 3.2.1.29.1.1 through 3.2.1.29.2.6 ("29" should be "28").
Response:
Concur. Subparagraph numbering error. Subparagraphs that include 3.2.1.29.1.1 through 3.2.1.29.2.6 will be updated with "29" replaced by "28".
------------------------------------------------------------------
ID: 1871 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.1
Mass Properties
Recommendation:
A not to exceed mass value should be established.
Rationale:
A not to exceed mass value will assist the sensor contractor in the optimization (performance, cost, risk, size) of the sounder and will minimize the risk of developing a heavy sensor that becomes a burden to the overall payload.
Response:
The use of the PAD is being deleted from the SRDs and this section is being reviewed and will be changed.
------------------------------------------------------------------
ID: 1872 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.2
Dimensions
Recommendation:
A not to exceed size should be established.
Rationale:
A not to exceed dimension will assist the sensor contractor in the optimization (performance, cost, risk, size) of the sounder and will minimize the risk of developing a too large of sensor that becomes a burden to the overall payload.
Response:
Concur. Dimension allocations for the CrIS will be addressed/contained in the next draft release of the CrIS SRD.
------------------------------------------------------------------
ID: 1873 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.3
Power
Recommendation:
Not to exceed power values (peak, average, launch, and end-of-life) should be established.
Rationale:
Not to exceed power values will assist the sensor contractor in the optimization (performance, cost, risk, size) of the sounder and will minimize the risk of developing a power starved sensor that becomes a burden to the overall payload.
Response:
Concur. The not-to-exceed power value will be provided as TBR in the next revision. The actual value will be incorporated in the final release.
------------------------------------------------------------------
ID: 1875 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.6
Endurance
Recommendation:
Is the design service lifetime (7 years on-orbit and 4 years in storage) for the flight of opportunity sounder also 11 years?
Rationale:
There could be some cost savings for the flight of opportunity unit if its design lifetime were reduced, perhaps 2 years in storage plus 5 years on-orbit.
Response:
See comment #1676. The current IPO position is that all instruments should be the same so that flight units can be interchanged if necessary.
------------------------------------------------------------------
ID: 1877 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.9.16
MLI Other Considerations
Recommendation:
Thermal control surfaces of the radiative cooler assembly are not cleanable. They must be kept clean from inception by strict environmental controls.
Rationale:
Response:
Don't understand the comment that thermal control surfaces of the radiative cooler assembly are not cleanable. Such assemblies have been cleaned in the past. I agree very much with the statement that they must be kept clean from inception by strict environmental controls which is why we are asking for your plans and recommendations for contamination control in the RFP.
------------------------------------------------------------------
ID: 1876 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.4.9.4
Radiation
Recommendation:
Radiation loads to the sensor need to be supplied to the sensor contractor by SRR so all system requirements can be fully understood and the PDR design can proceed in a low risk fashion.
Rationale:
If radiation loads are not supplied in a timely fashion (by sensor SRR) then the sensor preliminary design will proceed under high risk which can result in a significant redesign and adverse cost and schedule impacts.
Response:
The IPO agrees that the radiative loads to the sensors need to be supplied. Since there will not be a spacecraft contractor until after PDR, the Government will have to provide an initial allocation of these loads. A TBS will be added to this requirement.
------------------------------------------------------------------
ID: 1878 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.2.5.1
Reliability
Recommendation:
A reliability requirement of 0.84 for 11 years along with redundancy to assure "availability" will most likely require extensive redundancy which in turn drives up cost, size, and weight. "Availability" and allowed operational degradation should be clearly defined.
Rationale:
Many sensor components such as scan mirrors and focal plane arrays are too large and/or too expensive to effectively implement full redundancy. Some level of risk must be assumed to keep the overall budget and sensor size reasonable.
Response:
See comment #1762.
------------------------------------------------------------------
ID: 1879 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.3.1.4
Finishes
Recommendation:
ESD coatings are normally not used on flight sensors because of contamination concerns.
Rationale:
Response:
Covered by TRD3.2.4.7-3. The SS of the NPOESS shall have special coatings for electrostatic discharge suppression in all environments.
------------------------------------------------------------------
ID: 1882 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.3.15.1
Processes and Controls for Space Equipment
Recommendation:
Request that SRDX3.3.15.1-14 be changed to "All changes to the baseline processes used, or the baseline documents used shall be recorded by the supplier following the manufacture of the first flight unit. It is recognized that many factors may warrant making changes to this documented baseline; however, these changes provide the basis for flight accreditation of manufactured or of subsequent flight items."
Rationale:
The baseline should be established per the first flight unit manufactured, not the first item or lot of items manufactured. There will be some non-flight test items manufactured prior to the flight hardware. Baselining non-flight hardware adds to the overall program cost.
Response:
Accept. SRDs will be revised.
------------------------------------------------------------------
ID: 1881 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.3.15.1
Processes and Controls for Space Equipment
Recommendation:
Request that SRDX3.3.15.1-13 be changed to "Manufacturing flowchart shall reference specifications and drawings reflecting the manufacturing process control baseline and shall be retained by the supplier for reference."
Rationale:
The manufacturing process should reference and be controlled by the engineering documentation (specifications and drawings) only. Adding other references unnecessarily increases the difficulty of maintaining the manufacturing flowchart.
Response:
Reject. Procedures and supporting documentation needed for traceability.
------------------------------------------------------------------
ID: 1883 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.3.15.1.1
Assembly Lots
Recommendation:
Request that SRDX3.3.15.1.-3 be changed to "Each lot shall be manufactured, tested and stored with sequential lot numbers that indicate the date of manufacture assigned to each lot. (Typically, use three digits for the day of the year and two digits for the year."
Rationale:
This will ease the storage requirements of the lots without losing any control.
Response:
Concur. Change will be made to SRDs.
------------------------------------------------------------------
ID: 1880 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.3.6
Safety Requirements
Recommendation:
SRDX3.3.6-3 states that sensor suites shall comply with EWRR 127-1 in areas of design safety, flight termination, launch integration and ground operations. While it obvious that the sensor contractors have control over design safety, it is unclear how much control the sensor contractors will have over range operations or ground operations. Please clarify level of effort/responsibility at the range and ground operations.
Rationale:
Response:
Sensor contractor responsibility is to insure their sensor design and test /checkout procedures at the launch site comply with Range Safety regulations.
------------------------------------------------------------------
ID: 1884 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 3.4.2
Interface Control Documents
Recommendation:
The sensor contractor should be responsible for developing the CrIS ICD.
Rationale:
The sensor contractor will have passed both PDR and CDR by the time that the spacecraft contractor is selected. It will be more efficient (cost and schedule) for the spacecraft contract to accommodate an already designed sensor than for the sensor contractor to implement post-CDR design changes. It is assumed that the Pre-TSPR spacecraft contractors will have the opportunity to provide inputs to the sensor contractor on the ICD.
Response:
The sensor contractor will have passed PDR but not CDR. IRD para 1.1 says, "Sensor development contractors shall define their sensor's detailed interface design in an Interface Design Description (IDD) document. The IDD will be used by potential spacecraft integration contractors to evaluate interface and accommodation for their proposed spacecraft. After award of the spacecraft integration contract, each sensor developer and the spacecraft contractor will jointly write an Interface Control Document (ICD) which defines the details of the sensor-to-spacecraft interface and sensor accommodation information (i.e. mechanical, electric, and thermal interfaces)."
------------------------------------------------------------------
ID: 1870 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 30
Interface Requirements SEE IRD
Recommendation:
Interface requirements should be contained in one document (IRD) only, not both the SRD and an IRD.
Rationale:
One document will avoid confusion and precedence issues, and will minimize laborious book keeping and the change control process.
Response:
The IPO intent is that the SRD be a stand alone requirements docoment.
------------------------------------------------------------------
ID: 1885 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 4.2.1.1.1.3
Nonconforming Material
Recommendation:
Request last sentence be changed to: "Nonconforming material or assembled units that do not satisfy these rework criteria may be considered in non-conforming material review for use-as-is acceptance or considered scrap."
Rationale:
Response:
Accept.
------------------------------------------------------------------
ID: 1886 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 4.2.1.1.3.1
Structural Analyses
Recommendation:
There appears to be a grammatical error in the first sentence. Should it read "The sensor developer will receive the mission-specific information for maximum equivalent loads."? If so, will this information come from the Government or spacecraft contractors directly? The information should be in a timely fashion, perhaps by SFR.
Rationale:
Response:
Equivalent loads will be provided by the integrating contractor. This sentence revised to read "The integrating contractor will provide mission-specific information for maximum equivalent loads to the sensor contractor for his static loads analysis."
------------------------------------------------------------------
ID: 1887 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 4.2.1.1.3.9.1
Sensor Level Thermal Testing
Recommendation:
Please confirm 65 thermal cycles are required for sensor protoqualification.
Rationale:
Thermal vacuum protoqualification of 65 cycles is excessive and will be very costly. Typically, between 6 and 8 cycles are performed.
Response:
This is a typo. The number should be 6.5 cycles. However, this section will be moved to the SRDs and revised to require testing in accordance with 1540C and not to any specified levels.
------------------------------------------------------------------
ID: 1888 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD 4.2.1.1.3.9.1.2
Thermal Balance
Recommendation:
The first sentence should read "The first sensor shall be subjected to a thermal balance test as specified in Paragraph 6.2.8 of MIL-STD-1540C."
Rationale:
Traditionally, thermal balance testing is only need to be performed on the first flight article and is used to verify the thermal modeling. Thermal vacuum testing is traditionally performed on all flight units.
Response:
Agree. The sentence will be changed to read "The first sensor.......MIL-STD 1540C."
------------------------------------------------------------------
ID: 1853 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD Figure 3-1
Specification Tree
Recommendation:
The Specification Tree in Figure 3-1 should reflect terminology used in paragraph 3.1.3 Specification Tree.
Rationale:
Figure 3-1 does not show the NPOESS IORD as referenced in paragraph 3.1.3.
Response:
The only inconsistency seems to be that the paragraph heading says, "Partial" Specification Tree. Paragraph heading changed to "Specification Tree".
------------------------------------------------------------------
ID: 1865 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD Table 3-2
Maximum Allowed NEDT (K)
Recommendation:
Are the NEDT values for T=233K and T=287K reversed?
Rationale:
For a constant set of sensor parameters the NEDT will decrease with increasing reference temperature. Table 3-2 does not depict this effect. Please clarify what NEDT values are required in each band for the Cool, Nominal, and Hot conditions.
Response:
No. The NEDT values for T=233K and T=287K are not reversed. The lower NEDT requirement is associated with the lower scene radiance level.
------------------------------------------------------------------
ID: 1732 Date Recvd: 12/20/96 Status: Closed
Reference:
CRIS SRD, TRD 3.2.1.26
Absolute radiometric accuracy
Recommendation:
The statement "The design shall reflect the absolute accuracy goal of less than 1%" seems incomplete. To what physical quantity does the 1% accuracy refer? At what statistical level does the 1% goal apply? What is the standard for comparison?
Rationale:
A high degree of absolute radiometric accuracy can be a difficult and costly requirement to meet and verify. Therefore, it requires a precise definition.
Response:
Concur. Specification under review for major revision. Editorial Note: Strictly speaking, compliance to an absolute accuracy specification is not demonstrable by measurement; but rather requires a detailed error analysis to establish the radiometric error in the traceability to some primary radiometric standard. Conventional calibration processes identify and compensate for systematic biases; the repeatability specification will limit the drift between calibrations; but the error that remains, apart from random precision or repeatability error in any particular measurement, is the unknown bias, the residual of the best calibration, the gist of accuracy which can only be estimated by those most familiar with the instrument and the calibration procedure (i.e. the instrument manufacturer).
------------------------------------------------------------------
ID: 1815 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A
Recommendation:
Mention is made in the IRD that sensor modes are to be defined in an ICD (e.g., see section 3.2.1.1.4, Sensor Mode Documentation, page 7). However, no ICD is identified in the CDRL list. In the SRDs is mentioned that the contractors should provide data to the spacecraft integrator for inclusion in a Sensor/Spacecraft ICD. At present, the only interfacing contractors identified are LMMS, TRW, and Hughes as ATSP contractors. Is it the Government's intent that the contractors develop an ICD input as part of the sensor suite specifications and provide these independently to the three ATSP contractors? Or is it the Government's intent that since the Government has assumed TSPR until 4Q00, the contractors should provide inputs to a Government-written ICD for each of the sensor suites? CDRL Data Item A002 (Technical Report-Study/Services) mentions sensor suite mission and requirements analyses, sensor suite requirements allocations documents, and preliminary functional level design documents. Is it the Government's intent that the ICD material perhaps be included among these documents rather than a stand-alone document?
Rationale:
Response:
Interface Requirements will be specifically added to the CI Development Specification (CDRL A007). An Interface Design Description (IDD) has been added to the list of potential additional CDRLs in conjunction with CFI. The ICD will be a CDRL requirement for the spacecraft integrating contractor.
------------------------------------------------------------------
ID: 1654 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A A009- Block 16
Cost Performance Report deadlines
Recommendation:
Continuation of Block 10, item d, requires report of formats 1-4 in 10 days, format 5 in 15 days. Continuation of Blocks 12,13, item b, requires report of formats 1-4 in 5 days, format 5 in 20 days. Suggest leaving Block 10 as is and making Blocks 12,13 agree with it.
Rationale:
10 working days is a more realistic deadline, especially since data from subcontractors must also be included for the same month.
Response:
Concur. Submittal dates have been changed for consistency
------------------------------------------------------------------
ID: 1910 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A CDRL
Deliverables
Recommendation:
Crucial to the development of a System of measurements, sensors and algorithms is the verification of the end to end performance. Should the Government require that contractors provide, as CDRLs, their Performance Verification and Calibration Plans? Due to the significance of these, we recommend the additional CDRLs be in sufficient detail to allow detailed analysis and verification of adequacy by SETA contractors and Government Representatives
Rationale:
Visibility into plans for end to end Verification and Calibration, allowing Government to ensure compliance with requirements
Response:
The program office requests information on such processes in Section 3 of the IMP instructions. We will include requests for more comprehensive plans in the IMP instructions for the Call for Inprovements (CFI) prior to sesnor downselect.
------------------------------------------------------------------
ID: 1630 Date Recvd: 12/19/96 Status: Closed
Reference:
Exhibit A CDRL A001, Blk. 16, (Blk. 13)
Integrated Master Schedule (IMS)
Recommendation:
Recommend subsequent submission dates be consistent with CDRL A009.
Rationale:
Can be combined with CDRL A009, Cost Performance Report for regular monthly program status report submission.
Response:
Concur. Submission dates has been changed to be consistent with CDRL A009.
------------------------------------------------------------------
ID: 1957 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A CDRL A002
Research Grade Code
Recommendation:
This CDRL description for the Technical Report CDRL mentions delivery of Research Grade Code. This delivery is extremely significant, and should, we believe, be defined as its own CDRL, with requirements for delivery, definition of environment in which it must operate, etc., defined. It also references a Government Weather Test Bed. Where and when will this be defined?
Rationale:
Significant impact of host environment on software development. Significant difficulties with software deliveries without detailed definition of requirements
Response:
The Research Grade Code will stay under the Technical Report CDRL. The government Weather Product Test Bed is not yet adequately defined to specify the operating environment etc, though IDL will probably be adequate for delivery of research grade code. The IPO will provide more information on the government test bed architecture after contract award and prior to SFR.
------------------------------------------------------------------
ID: 1632 Date Recvd: 12/19/96 Status: Closed
Reference:
Exhibit A CDRL A009 Block 16
Cost Performance Report submission dates
Recommendation:
Block 16 of the CDRL shows two conflicting submission due dates (5 and 10 days for the flash report and 15 and 20 days for the formal report). Recommend 10 working days for the "Flash report" and 20 working days for the "Formal report".
Rationale:
Response:
Concur. Submittal dates have been changed for consistency.
------------------------------------------------------------------
ID: 1830 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A CDRLS
Recommendation:
Data requirements in the first phase of the program (prior to CFI) do not include any monthly reports. What type of monthly cost, schedule, or technical reports be required?
Rationale:
Response:
CDRLs requiring monthly submittals are stated in Block 13 of the 1423-1.
------------------------------------------------------------------
ID: 1570 Date Recvd: 12/19/96 Status: Closed
Reference:
Exhibit A Items to note in Reviewing the Draft CDRLs
Future CDRLs
Recommendation:
Recommend the government supply a completed draft DD Form 1423-1 with this RFP for those CDRLs that are likely to be required in conjunction with the CFI.
Rationale:
Clarification of requirement
Response:
Non concur. Detailed data delivery instructions for the follow on contracts are not necessary at this time. The proposed follow-on CDRLS will be IAW standard DIDs. Data, if any, beyond that described in Exhibit A which may be required in conjunction with the CFI is not defined at this time.
------------------------------------------------------------------
ID: 1836 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A note 11
Integrated Master Schedule
Recommendation:
CPR is not CDRL A012. A012 is Product Baseline Spec (C Spec).
Rationale:
Response:
Concur. Reference has been corrected.
------------------------------------------------------------------
ID: 1631 Date Recvd: 12/19/96 Status: Closed
Reference:
Exhibit A Page 19 of 20, CDRL A009 Blk. 16, b.
Cost Performance Report, Direct vs. Indirect
Recommendation:
With regard to cost reporting, recommend reporting direct at the WBS level, and summarizing overhead and G&A at the program level.
Rationale:
Indirect rates can be addressed and analyzed more readily as groups (i.e. overhead, and G&A) vs. by WBS. Direct costs can be more readily addressed and analyzed by cost account managers at the WBS level.
Response:
Concur. CDRL has been changed.
------------------------------------------------------------------
ID: 1841 Date Recvd: 12/20/96 Status: Closed
Reference:
Exhibit A para 5, subpara (b)
Data items submitted for approval will not automatically be approved after a certain elapsed time limit.
Recommendation:
While the Government recognizes its obligation to respond within a time limit, it provides no relief to the contractor (such as cost, fee, schedule or specification) where the Government fails to respond within the specified time limit. Please clarify.
Rationale:
Where the contractor's performance is "gated" by the customer's prior approval, and that approval is not forthcoming within an agreed-to time span, the contractor's progress is impacted -- through no fault of its own. Relief in such cases is necessary to account for the delay.
Response:
The contractor is not precluded from seeking appropriate relief for any perceived adverse impact of Government actions under the standard terms of the contract.
------------------------------------------------------------------
ID: 1568 Date Recvd: 12/19/96 Status: Closed
Reference:
Exhibit A Supplemental Data Approval Requirements pg 6
CDRLs
Recommendation:
Recommend adding this statement: "Regardless of whether there is an 'A' in Block 8 or not, all deliverable data is subject to disapproval via a PCO letter if it does not meet contractual requirements."
Recommend adding this statement: "All documents shall be marked with Distribution Statement 'D' unless the contractor determines the appropriate Distribution Statement to be assigned to the document is something other than 'D'". Either way, the contractor is ultimately responsible for correctly marking the data using Mil-Std-1806 as reference. If the data is determined, by the government, to be improperly marked, it will be rejected via a PCO letter.
Rationale:
Clarification of requirements
Response:
Non concur. First comment - CDRL instruction 5d specifies this already. Second comment - Different CDRLs require different distribution statements. It is up to the contractor to decide the appropriate statement.
------------------------------------------------------------------
ID: 1569 Date Recvd: 12/19/96 Status: Closed
Reference:
General Comment
DRFP Requirements
Recommendation:
We recommend that the Phase 2 & 3 related reference material such as the CLIN structure, model contract, CDRLs and Award Fee Plan should be enclosed as a separate attachment and marked as Phase 2 & 3 information.
Rationale:
Clarification of requirements
Response:
There are only 2 phases in this acquisition. Section L asks for items required for this proposal phase. Items not specifically listed will be part of the CFI and will not be submitted at this time. Unpriced option CLINs are a necessary part of the RFP and resulting contract. No change is necessary.
------------------------------------------------------------------
ID: 1772 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 1.2
Sensor Overview
Recommendation:
The text reads "the receivers, when used together, can remotely sense Earth limb rise and set occultations of GPS and GLONASS satellites that yield electron density profiles, in situ plasma density, auroral boundary information and ionospheric scintillation." This statement involves apparent errors or misrepresentations. GPS occultations cannot yield in situ plasma density and would be very poor indicators of auroral boundary information. We suggest deleting in situ plasma density and auroral boundary information from this text. Note that there is continued confusion on this subject in the SRD. Later in the SRD there is a suggestion that the GPSOS will require other ancillary sensors. Perhaps the in situ plasma density and auroral boundary information requirements make reference to what is expected to be adjunct sensors. This needs clarification.
Rationale:
N/A
Response:
1) Section 1.2 is being rewritten to discuss six data types as follows:
See response to question 1602 for exact EDR specifications. To satisfy the EDRs, the specific data elements derived from the GPSOS sensor instrument are described below. The GPSOS sensor makes observations of navigation signals from the GPS and GLONASS satellite constellations. The GPSOS provides six main data types:
GPS navigational data which consists of position accurate to 15-m , velocity accurate to 1 m/s, and time accurate to 10ns. This data is provided to the on-board spacecraft flight computer .
2) GPS occultation event data
3) GLONASS occultation event- data
4) GPS non-occulting satellite data
5) GLONASS non-occulting satellite data
6) Ionosphere scintillation parameters for occulting GPS & GLONASS satellites
------------------------------------------------------------------
ID: 1773 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.1.1
Sensor Description
Recommendation:
The text reads "The host spacecraft system for the GPSOS will be the NPOESS system with early flight opportunities on the DMSP, POES, and METOP satellites." Please describe which specific spacecraft in the DMSP and POES series. This same text bears reference to the need for in situ plasma density and auroral boundary. These parameters or EDRs cannot be provided by the GPSOS sensor and the reference to these EDRs should be deleted from this text.
Rationale:
Further clarifications are necessary: (1) What spacecraft resources will be available to GPSOS? (2) The IPO presentation at the Industry Day Briefing opening the category of alternate proposals. Subsequent discussions suggested that an alternate proposal could be submitted only if a given team also submitted a proposal directly responsive to the RFP (e.g. GPSOS). The alternate proposal would represent special value-added features (e.g. supplementary sensors) that enhanced the primary instrument (e.g. GPSOS) deliverables. Is this interpretation correct? What spacecraft resources will be available to alternate proposal sensors?
Response:
Early flight opportunities on DMSP 18, 19, and 20 and POES N' are anticipated. Nominal values have been given for size, weight, power, and data rates for the instrument. The antennas have not been included since they are dependent on proposal.
GPSOS EDR requirements have been clarified.
------------------------------------------------------------------
ID: 1774 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.1.6
Operational and organizational concept.
Recommendation:
The text here is unclear, misleading, wrong, or perhaps incomplete. It suggests that GPSOS will make in situ measurements of electron density and measurements of auroral boundaries. GPSOS cannot provide in situ measurements or measurements of the auroral oval boundary.
Rationale:
N/A
Response:
See response to ID: 1602 & 1772.
------------------------------------------------------------------
ID: 1775 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.1
EDR Requirements
Recommendation:
It is not clear what the EDR requirements are for GPSOS. It appears that the primary requirements of GPSOS bear only on electron density profiles and scintillations, and perhaps total electron content, depending on one's interpretation. It is necessary that this be clarified. If the GPSOS EDRs involve electron density profiles, ionospheric specifications, and scintillations, are they the same EDRs as currently expressed in Appendix D? Collectively, the EDRs within 40.8 are taken to represent the requirements on SES.
Rationale:
N/A
Response:
GPSOS EDR requirements have been clarified in the revised SRD. GPSOS will be responsible for providing some of the same ionospheric EDR attributes that the SES suite must provide.
------------------------------------------------------------------
ID: 1776 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.1.1
EDR requirements that must be satisfied by the sensor alone.
Recommendation:
The text reads "the ionospheric EDRs that must be supported include electron density profiles, ionospheric specification, auroral boundary." GPSOS alone cannot define the auroral boundary. "Auroral boundary" must be deleted from the statement or further clarified.
Rationale:
N/A
Response:
See response to ID: 1602 & 1772. This paragraph will be changed.
------------------------------------------------------------------
ID: 1777 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.1.2 and 3.2.1.1.1.2.1
(3.2.1.1.2) EDR Requirements that must be satisfied by the Sensor in conjunction with other Sensors. (3.2.1.1.1.2.1) Sensor performance requirements for these other sensors.
Recommendation:
There is no text entry under these headings. Clarification is necessary. The issue of "other sensors" and associated requirements needs to be clearly elucidated.
Rationale:
Response:
This section is being revised. See comment #1491.
------------------------------------------------------------------
ID: 1778 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.1.3.
EDRs supported as a goal by the Sensor Alone
Recommendation:
The text reads "goal EDRs include plasma density, ionospheric scintillation, and auroral boundary". Auroral Boundary must be deleted and plasma density must be qualified. Is it plasma density profiles?
Rationale:
N/A
Response:
See response to ID: 1602 & 1772. This paragraph will be changed.
------------------------------------------------------------------
ID: 1779 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.2
SDR Requirements [TBR]
Recommendation:
In the text "Retrospective Processing" needs some clarification. Is there no real-time EDR deliverable? Does this statement in the document simply guarantee the archiving of intermediate level data files? Some clarification is necessary.
Rationale:
N/A
Response:
No revision necessary. NPOESS is not required to archive data. The user may desire to archive the intermediate NPOESS TDR/SDR products in order to investigate improved processing techniques ("restrospective processing"). All NPOESS data products (RDRs, TDR/SDRs, and EDRs) are required in real-time.
------------------------------------------------------------------
ID: 1809 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.1.2-1
GPSOS Capability
Recommendation:
The statement of GPSOS ability to earth-locate the satellite to within 0.5 meters should be part of the primary sensor description, section 3.1.1.
Rationale:
Earth-location is critical for all EDR accuracy capabilities, especially the stringent goals we hope to achieve with NPOESS.
Response:
Agreed. Phase accuracy and precision processing specifications will be added consistent with a velocity specification of 0.5mm/s using post-processing.
------------------------------------------------------------------
ID: 1758 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.1.10 Real-time Data Downlink Transmission Capability, 3.2.1.11 Stored Data Downlink Transmission Capability
3.2.1.10-1
The sensor shall conform to the DMSP/METOP system format ...
3.2.1.11-1
The sensor shall conform to the DMSP/METOP system format...
Recommendation:
Is the same data format used on both DMSP and METOP systems? NPOESS uses CCSDS data formats. If the sensor has to produce 3 different formats for the 3 systems we recommend specifying the CCSDS format.
Rationale:
Clarification
Response:
CCSDS format is specified for NPOESS sensors. Unique data format for requirements for flights on DMSP and METOP systems are TBS.
------------------------------------------------------------------
ID: 1781 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD 3.2.4.1, 3.2.4.2, and 3.2.4.3
Nominal Mass, Nominal Dimensions, Nominal Power
Recommendation:
These can be construed as lock-out specifications.
Rationale:
N/A
Response:
Don't understand the comment. Any specification can be contrued as "locking-out" any design which is noncompliant.
------------------------------------------------------------------
ID: 1780 Date Recvd: 12/20/96 Status: Closed
Reference:
GPS SRD SRDG 3.2.1.1.5-3
Operational Algorithm Teams (OATS)
Recommendation:
The statement under this item needs some clarification. Does this statement suggest that OATS will provide inversion algorithms for Ne profiling from occultations? Suppose the contractor feels OATS' algorithms are inferior, inaccurate, or otherwise inappropriate compared with what is necessary, what may be available from the contractor, or what can be developed by the contractor himself.
Rationale:
N/A
Response:
Text will be clarified. The OATS will make recommendations only. The sensor contractor is responsible for ensuring algorithms and sensor specifications will meet the EDR requirements.
------------------------------------------------------------------
ID: 1831 Date Recvd: 12/20/96 Status: Closed
Reference:
IBriefing to Industry, 21 Nov 96 Page 16 - First of Viewgraph
Comment on Proposed Government 15 Month SES Study
Recommendation:
We have great interest in participating in the forthcoming RFP for the NPOESS program. We attended the Briefing to Industry presentation in Silver Spring, MD on November 21st and were greatly encouraged by the present guidelines for the majority of the NPOESS Optimized Convergence. However, we are somewhat dismayed by the currently proposed strategy for the NPOESS Space Environment Suite (SES) procurement outlined on page 16 of the briefing. Our major concern is the chosen form of the proposed 15 month Government study prior to issue of competitive sensor contracts. Although an in-house Government study may well be the best way to address the particular non-civilian requirements for the monitoring of space weather, we would wish some clarification on how the NPOESS IPO views the roles of both Industry and Academia in this open forum.
Rationale:
In particular, we have recently developed a novel concept for an auroral spectral imaging instrument that uses state-of-the-art technologies with no moving parts!
In addition, we are currently teamed with the another group of individuals who are the acknowledged leaders in the development of model upper atmosphere algorithms. Unless the Government study team is wholly appraised of new instrument (and algorithmic) developments in a timely and open fashion, we do not believe that the SES EDR's will be fully clarified and quantified to produce the best NPOESS instrumentation and resultant data.
We would welcome a more integrated approach to the proposed SES study in which Government, Industry and Academia were all involved on an equal footing and propose open-forum studies on the subject. We believe that we can play a major role in the development of novel instrumentation for the NPOESS program, and we would welcome any offer for assistance with the proposed 15-month SES study.
Response:
The 15 month Internal Government Study which was initiated in October is comprised of three phases. The first, which leverages off a SpaceCommand initiative already underway, is to re-assess the end user applications. The second phase, working cooperatively with Space Command, is to establish an optimized concept of operations (CONOPS) for supporting that user operational need. Some needs might be best supported with data measured directly from ground based instruments in the area of interest, others might require data measured directly from GEO, HEO, or LEO space based instruments, and it may be necessary to feed data, ground or space based, into central or localized models to produce a product for some operational needs.The requirements which are allocated to the polar orbiting component (NPOESS) of the total Space Environment Support System (SESS) as a result of an optimized SESS CONOPS, could revise the current set of NPOESS Space Environment Suite (SES) requirements. Once this is established, in the Sept 97 timeframe, Phase 3 will be intiated in which the program office will establish the sensor performance requirements for the SES RFP to be released in the Mar 98 timeframe. Based on industry interest thus far, the program office plans to conduct a SES Industry Day between Phase 2 and 3, to present both the overall the SESS CONOPS and the resulting prioritized (and possibly revised) NPOESS SES requirements and invite comment and recommedations to consider for Phase 3.
------------------------------------------------------------------
ID: 1806 Date Recvd: 12/20/96 Status: Closed
Reference:
IBriefing to Industry, 21 Nov 96 Slide 70
WPTB
Recommendation:
Will the WPTB conform to the DII COE Standards?
Rationale:
N/A
Response:
The WPTB will not conform to the DII COE to the extent that any of the required model software is not supported under the COE. In addition, some of the government or university organizations which are part of the distributed WPTB currently use Apple Mac computers, and thus to that extent the WPTB will not conform to the DII COE.
------------------------------------------------------------------
ID: 1956 Date Recvd: 12/20/96 Status: Closed
Reference:
Industry Day Vugraphs MTPE Cooperation
P109
Recommendation:
How will the current suppliers of MTPE instrument be involved in this cooperative activity? Will selected sensor contractors be invited to attend?
Rationale:
Response:
The IPO does not have any current plans for third-party contractors to participate in the IPO's monitoring of MTPE instrument developments. This is an internal Government activity, which was discussed at the recent briefing to industry for informational purposes only.
------------------------------------------------------------------
ID: 1955 Date Recvd: 12/20/96 Status: Closed
Reference:
Industry Day Vugraphs Risk Reduction Activities Initiated During Phase 1
P105
Recommendation:
Please provide a reference to learn about the MOLS activity
Rationale:
Response:
References detailing MOLS activity are not considered necessary to the current NPOESS RFP and have not been included in the NPOESS contractor library. Please contact the DMSP office for additional information.
------------------------------------------------------------------
ID: 1954 Date Recvd: 12/20/96 Status: Closed
Reference:
Industry Day Vugraphs Slide 77 and Slide 68
Recommendation:
Is the concept definition portion of the VIIRS Schedule (p77) intended to end at the SFR, requirements freeze portion of the Specification Development Schedule (p68)?
Rationale:
Response:
Yes, the IPO's current program schedule projects that the concept definition portion of the VIIRS effort will end at SFR.
------------------------------------------------------------------
ID: 1667 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 1.1 Introduction, paragraph 4, sentence beginning Sensor development
CDRLs and DIDs for IDDs and ICDs
Recommendation:
The referenced IRD paragraph defines requirements for both Interface Design Descriptions (IDD) and Interface Control Documents (ICD) which are presumably deliverable under CLIN 0002. Do you intend to impose CDRL and DID requirements for such documents?
Rationale:
Clarification.
Response:
The draft Interface Design Descriptions (IDD) will be deliverable prior to PDR. It will be made a part of CDRL A007, Config Item Development Spec and tailored and developed as one of the sections in the draft B-spec. Thus, a new CDRL item will not be necessary.
------------------------------------------------------------------
ID: 1736 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 1.2 Program Overview, 3.1.3 Orbit Parameters
Paragraph 1.2: "It is anticipated that operational data"
Para 3.1.3, The NPOESS spacecraft shall operate in a near...
Recommendation:
Recommend rewording as:
Paragraph 1.2 - ...It is anticipated that operational data will be collected by satellites flying in sun-synchronous near-polar orbits at approximately 833 km altitude with the following nominal nodal crossing times - 0530 (ascending), 2130 (ascending), and 1330 (ascending). Satellites in the 0530 and 1330 orbits are considered U.S. assets and will be developed, acquired, deployed, and operated by the U.S. Satellites in the 2130 orbit are European assets and will be developed, acquired, deployed, and operated by the Europeans...
Where : "1930" is replaced by "2130" and "ascending" is added as shown in ( )
Paragraph 3.1.3 - The NPOESS satellites shall operate in a near circular, sun-synchronous orbit. The nominal orbit for the satellites is 833 km altitude, 98.7 (TBR) degree inclination. The orbit will be a "precise" orbit (i.e., altitude maintained to ± TBD km, nodal crossing times maintained to ± 10 minutes throughout the mission lifetime ) to minimize orbital drift (precession). NPOESS must be capable of flying at any equatorial node crossing time. However, the nominal configuration is with the satellite orbits equally spaced, with 0530 (ascending) and 1330 (ascending) nodal crossing times for the U.S. Government satellites and 2130 (ascending)for the METOP satellites.
Where : "1930" is replaced by "2130" and "ascending" is added as shown in ( )
Rationale:
To make the IRD consistent with the TRD.
Response:
The direction of flight has been deleted to avoid confusion. The requirement is to be able to support a nodal crossing time at any time of day.
------------------------------------------------------------------
ID: 1668 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 2.0
Specificity of Applicable Documents
Recommendation:
Recommend adding statements at beginning of this section similar to those found in the SRDs, such as "The following documents of the exact issue shown form a part of this IRD to the extent specified herein. In the event of conflict between the documents referenced herein and the contents of this IRD, the latter shall be the superseding requirements."
Rationale:
Clarification.
Response:
A precedence statement will be added.
------------------------------------------------------------------
ID: 1652 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 2.0
Applicable Documents
Recommendation:
The following applicable documents are not listed in paragraph 2.0, but are specifically called out in the body of the IRD:
CCSDS 701.0-B-1 referenced in paragraph 3.2.1.5.2 and 3.2.1.11.3.
CCSDS 203.0-B-1 referenced in paragraph 3.2.1.9.
FED-STD-209E / ISO 209 referenced in paragraph 3.3.2.9.
MIL-STD - 1815A, ANSI STD X39-1978 or ANSI STD X3/159-1989 are referenced in paragraph 3.3.4.1.
The following applicable documents are listed in paragraph 2.0 but are not specifically called out in the body of the IRD:
MIL-STD 462, ICD GPS060, MSFC/SPEC/5228, MIL-STD 498,
MIL-STD-1246 Aerospace Thermal Control, MIL-STD 882, MIL-STD-1522 Handbook, MIL-STD 1543, MIL-STD-1773, AFR 127-100,
MIL-STD 1546, MIL-STD-1629, Title 40 Fed Reg., MIL-STD 1547, RINEX, ESD-TR-91-212 MIL-E-6051, NASA GEVS-SE, USSPACECOM Reg. 57-2, DOD-E-83578A, NASA TP 3227, FCM-S2-1990
Rationale:
All documents called out in the IRD should be listed in 2.0 Applicable Documents. All documents listed in 2.0 Applicable Documents should be called out in the IRD to indicate the area and extent of applicability.
Response:
Agree. The government will correct any inconsistencies with the applicable documents.
------------------------------------------------------------------
ID: 1813 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 2.1, 3.2.4
Applicable Compliance Documents and Environmental Requirements
Recommendation:
There is no provision for specifying the natural space radiation environments. It is recommended that as a minimum MIL-STD-1809, Space Environments for USAF Space Vehicles be identified. Other possible references/documents include: NASA SP-8013 (Meteoroids) and NASA TM 100471 (Man-made Orbital Debris).
Rationale:
The sensors must withstand the on-orbit environment and still be able to deliver EDR/TDR/SDR performance. These requirements are mentioned in the SRDs. The spacecraft should also be subject to the same requirements for balanced design. The recommended specifications should be included in the Government documents and environmental requirements sections for completeness.
Response:
The radiation environment will be specified using the NPOESS altitude, inclination, and design life. The IRD has been changed to a reference document.
------------------------------------------------------------------
ID: 1651 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 2.2
Reference Documents
Recommendation:
Replace: 'AFR 127-100' with 'MAN91-2010002'
Rationale:
AFR 127-100 is superseded by MAN91-2010002.
Response:
Changed as suggested.
------------------------------------------------------------------
ID: 1681 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.0 & 4.0
3.0 Requirements & 4.0 Testing Provisions
Recommendation:
There are many TBDs in these sections. The Definition/Glossary (IRD 6.2) has different definitions for TBD and TBR than is found in 1.3 of the SRDs. The IRD definition of TBD does not differentiate between spacecraft contractor responsibility, sensor contractor responsibility, and joint responsibility of spacecraft contractor & sensor contractor. The IRD definition of TBR is between the sensor and spacecraft contractor rather than between the sensor contractor and the Government as in the SRDs. Many IRD constraints on the sensors that are now TBD (and not under the control of the sensor contractor) would appropriately bound the sensor trade space if quantified. Recommend that:
1) There be a distinction made between TBD responsibility. (e.g., TBD1 = spacecraft contractor responsibility, TBD2 = sensor contractor responsibility & TBD3 = spacecraft contractor & sensor contractor responsibility)
2) Adopt in the IRD the SRD definition of TBR which is resolution between the contractor and the government again distinguishing between which contractors have responsibility. (e.g., TBR1, TBR2, & TBR3).
3) Quantify constraints on sensor design concepts and implementation where constraint determination is not assigned to the sensor contractor (at least with best estimates and a TBR)
Rationale:
Recommendations 1) & 2) would eliminate confusion by having definitions remain consistent between documents in the RFP. They would also add information better identifying responsibility in the IRD. Recommendation 3) would provide better definition of the constraints on the sensor design concepts and implementation.
Response:
The definition for TBD and TBR will be made consistent with the TRD. Distingusihing between different responsible parties with different labels makes this a more complex process than necessary. With the IPT approach, the team should decide what is necessary and who is responsible for a product if a specific responsibility is not assigned. We will also try to quantify as many of the sensor design constraints as we can at this time.
------------------------------------------------------------------
ID: 1680 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.1.3
Orbit Parameters
Recommendation:
The 'all beta' requirement for noon/midnight orbit sun angles (beta = -5 degrees) is reasonably far removed from the nominal closest case sun angle incurred in the 13:30 nodal crossing time (beta = 22.5 degrees). The size of shades to protect thermal radiators from solar inputs is a strong function of the sun angle in the near noon/midnight orbit. Recommend that consideration be given to limiting the sun angle range to exclude the region where beta is less than a reasonable minimum expected value in the 13:30 nodal crossing time orbit.
Rationale:
Cost / benefit trade of excess capability relative to nominal requirements in the near noon/midnight orbit may not be favorable.
Response:
This is a user requirement to provide any nodal crossing time. Therefore, the system need is to be able to have an "all beta" angles capability implemented to satisfy this requirement. The offeror is encouraged to provide analysis that would demonstrate the cost/performance impacts.
------------------------------------------------------------------
ID: 1769 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.1.3
Orbit Parameters
Recommendation:
Is it necessary that the three spacecraft have the equatorial crossings at 0530, 1330, 0930?
Rationale:
The question is addressed because item 40.8.1, the EDR for the SES and for the GPSOS instruments, requests or suggests that the optimum model inputs are derived from crossings at the midnight auroral oval. This suggests that the optimum orbit would be at noon - midnight. In that framework, would there be any opportunity to reconsider that the orbit times of equatorial crossings be changed to 0800, 1200, 1600 hours, respectively? These would satisfy the SES optimum need for a midnight crossing of the auroral oval and would still provide the equal spacing between and among the three spacecraft.
Response:
These nodal crossing times at 0530, 0930, and 1330 are nominal. The requirement is to be able to fly the sensors at any nodal crossing. However, these three nodal crossings are optimized to meet key EDR requirements and/or user needs. Although other nodal crossings may provide equal spacecraft spacing, the need to get key EDRs at these specific times are the overriding factor.
------------------------------------------------------------------
ID: 1814 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.1.3, page 6
Orbit Parameters
Recommendation:
The current wording is: "The orbit will be a 'precise' orbit (i.e., altitude maintained to ± TBD km, nodal crossing times maintained to ± 10 minutes throughout the mission lifetime." We recommend the wording be changed to: "The spacecraft shall maintain a 'precise' orbit (i.e., altitude maintained to ± TBD km, nodal crossing times maintained to ± 10 minutes during normal operations throughout the mission lifetime. For autonomous operations, the spacecraft orbit should be maintained to ± TBD km, nodal crossing times maintained to ± TBD minutes."
Rationale:
It is unclear that the Government specification includes only normal operations, includes autonomous operations, or both. Adding this wording would clarify what orbital performance parameters apply to normal and autonomous operations.
Response:
The IPO believes that the orbit maintenance can be the same for both normal and autonomous operations for sixty days. There is no need to specify differences for autonomous operations.
------------------------------------------------------------------
ID: 1737 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.1.1
Recommendation:
The same number is given to two consecutive paragraphs: Notional Functional and Performance Description
3.2.1.1 Sensor Modes
Recommend renumbering.
Rationale:
Consistency
Response:
Agree. The paragraphs will be renumbered.
------------------------------------------------------------------
ID: 1738 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.1.2.4
Recommendation:
Paragraph existed in the September version and was deleted from the present, but the following paragraphs where not renumbered. Recommend renumbering.
Rationale:
Consistency
Response:
Paragraphs renumbered.
------------------------------------------------------------------
ID: 1669 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.1.2.5 Pulse Commands
Momentary Discrete Commands
Recommendation:
Recommend that commanding by momentary discrete commands be specifically avoided.
Rationale:
Noise from either internal (e.g., transients) or external (e.g., lightning at launch site) can cause inadvertent power state or mode commands that can be undesirable. This occurred on Apollo 11 LEM Landing Radar almost aborting the descent (radar locked in low altitude search gate at initial acquisition) and on one of the Viking Mars Orbiters at the launch site (lightning pulse advanced switch draining batteries). Long duration pulses or DC level changes should be used.
Response:
The use of pulse commands will remain in the IRD for now. The IPO will reevaluate the need for pulse commands in the course of the first phase efforts. The pulse command characteristics are now TBR.
------------------------------------------------------------------
ID: 1739 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.1.3.1.b Bus Functions
b. Sensor/remote terminal to spacecraft transfers consisting of:
- sensor/subsystem health and status ...
Recommendation:
Recommend deleting "subsystem" from the subparagraph b.:
b. Sensor/remote terminal to spacecraft transfers consisting of:
- sensor/subsystem health and status telemetry
- sensor/subsystem diagnostic data
- low rate science data
Rationale:
This is a requirement on the spacecraft bus and is to be specified in the spacecraft bus specification. It does not belong in the IRD.
Similar comments apply to the following paragraphs wherever the word subsystem appears:
Pulse Commands
Bus Configuration
Sensor/Subsystem Commands and Memory Loads
Command Types
Frame Sync and Time Code Data
Health and Status Telemetry Data
Telemetry Diagnostic Data
Response:
Agree. The word "subsystem" will be deleted from the applicable sentences.
------------------------------------------------------------------
ID: 1741 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.1.4 General Command and Telemetry Data Bus Requirements
Recommendation:
Change paragraph title to "General Command, Telemetry and Low-Rate Data Bus Requirement" in order to conform to the new terminology introduced in paragraph 3.2.1.3, page 9.
Rationale:
Consistency.
Response:
Changed paragraph 3.4.5.4 to read "General Bus Requirements" since this subparagraph already fall under section 3.4.5 for the General Command, Telemetry and Low-Rate Data Bus Requirements.
------------------------------------------------------------------
ID: 1670 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.2.12 Spacecraft/Sensor Interface Simulator
Spacecraft/Sensor Interface Simulator CLIN
Recommendation:
The sensor contractor is to provide the subject device to the spacecraft contractor, and vice versa. Will these devices have CLINs assigned to them?
Rationale:
Clarification.
Response:
No. The sensor interface simulator will not be a deliverable to the contract. It is intended to be used as part of the test and integration equipment in the course of sensor integration. Thus, no CLINs will be added. We are also deleting the requirement for the spacecraft contractor to provide a spacecraft interface simulator to the sensor contractors since it will too costly to provide each sensor (can be up to 10) a spacecraft simulators.
------------------------------------------------------------------
ID: 1742 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.2.2 Electrical Voltage
The electrical power supplied at the sensor interface shall be regulated 28 + 1.0 Vdc.
Recommendation:
Recommend retaining the original tolerance by replacing "1.0" with "6.0 (TBR) " to read:
The electrical power supplied at the sensor interface shall be regulated 28 + 6.0 (TBR) Vdc.
Rationale:
±1 Vdc regulation is too restrictive and will cause additional cost for the spacecraft electrical power subsystem. Moreover, sensor needs for this kind of regulation are not yet established. If there is substantiated need from a sensor for better regulation, the requirement will be documented in the corresponding spacecraft/sensor ICD after IPO/Spacecraft Contractor/Sensor Contractor approval. Providing this tight regulation "up front" will eliminate the sensor/spacecraft trades which should be conducted to provide the most cost effective satellite design.
Response:
Having a tightly regulated power source will allow sensors to more easily meet EMI/EMC requirements and improve the efficiency of spacecraft and sensor electronics. However, to allow greater lattitudes in spacecraft designs, a "TBR" will be added.
------------------------------------------------------------------
ID: 1743 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.2.3.1 Current Rate of Change
The current rate of change shall be limited to 200 amps/sec.
Recommendation:
200 amps/sec is a very low limit for the rate of change of the current at sensor switching. The industry practices are in the order of amps/msec (106 amps/sec). The corresponding METOP GICD limit is 2 x 106 amps/sec. We recommend soft switching to avoid switching transients (noise).
Rationale:
Consistency with current practice.
Response:
Agree. Paragraph will be revised to require 100 amp/msec. Soft switching is a design feature that should be left to the contractor and should not be specified as an interface requirement.
------------------------------------------------------------------
ID: 1744 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.3.4.2 Thermal Uncertainty Margin
A margin of 11 °C for thermal uncertainty shall be applied to determine acceptance ranges...
Recommendation:
In industry practices "protoflight" and "protoqualification" testing are identical. Paragraph 4 of the TRD seems also to be in accordance with this understanding. Please clarify.
A right parenthesis ")" should be added at the end of the paragraph.
Rationale:
Clarification
Response:
The NPOESS test philosophy is to use a protoqualification approach. The protoflight unit (normally the first flight unit) will be tested at the protoqual levels. Protoqual levels are tested at 5 degrees above the max/min predicted environment. Subsequent units will be tested at the acceptance test levels. Paragraph 3.2.3.4.2 will be reworded to delete the reference to the 11 degree uncertainty margin and the 10 degree C additional margin.
------------------------------------------------------------------
ID: 1683 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.5
Launch Vehicle Environments
Recommendation:
Need to add the launch pressure profile
Rationale:
All other launch environmental factors seem to be listed here except the pressure profile during launch.
Response:
Pressure profile is now provided.
------------------------------------------------------------------
ID: 1745 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.2.5.1 Sensor Fairing Dynamic Envelope
There are three standard minimum sizes for sensor fairing envelopes …
Recommendation:
The title should read: "Payload Fairing Dynamic Envelope" instead of "Fairing Dynamic Envelope" and in the paragraph "payload" should replace "sensor" to read:
There are three standard minimum sizes for payload fairing envelopes (actual fairing envelopes may be larger). These envelopes define the useable volume inside the fairing and forward of the Standard Interface Plane (SIP). However, there will be some stay-out zones in the envelope which currently are TBD. Payload fairings must accommodate transitioning sensors.
Two sizes of standard fairing envelopes have been defined for MLV, as shown in...
The paragraph states there are 3 standard sizes for the payload fairing envelope but defines only 2 of them. Please provide description of the third payload fairing envelope.
Rationale:
The word "payload" here refers to the launch vehicle payload.
Response:
Agree. "Sensor" will be changed to "payload" in this paragraph. The number "3" will be deleted from the sentence. Only 2 standard sized fairings are defined for the EELV medium launch vehicle. The other was for the heavy launch vehicle.
------------------------------------------------------------------
ID: 1597 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD 3.3.1.10, 3.2.5.6-3.2.5.10, 4.0
Mechanisms & Deployables, Environmental test information, and Testing provisions
Recommendation:
The referenced paragraphs are also called out in the CMIS SRD.
Rationale:
Specifications should only be called out in one document.
Response:
We feel that all sensor requirements should be made available in one location (the SRD) without having to rely on the IRD.
------------------------------------------------------------------
ID: 1750 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.13.2 General Access
All items to be installed, removed, or replaced at the spacecraft level shall be accessible without disassembly of the unit.
Recommendation:
Recommend the replacing "spacecraft " with "satellite " to read:
All items to be installed, removed, or replaced at the satellite level shall be accessible without disassembly of the unit.
Rationale:
Specification should be made at satellite level.
Response:
Agree. Wording changed to apply to satellite level: ".. replaced at the satellite level shall be.."
------------------------------------------------------------------
ID: 1687 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.16
Sensor to Spacecraft Integration and Test Mounting
Recommendation:
Change to "Sensors shall be designed to minimize and as a goal to be mounted and removed without disturbance and/or removal of any other component or sensor."
Rationale:
System trades of mounting location, performance, weight, volume, reliability could result in a configuration that might optimize the design but with the small impact of having to remove another spacecraft component in order to remove the sensor..
Response:
Keep wording as is. The baseline is to be able to mount or remove sensors without moving another item. If we find that optimal system design might preclude this requirement, then the ICD can be used to reflect the true configuration.
------------------------------------------------------------------
ID: 1748 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.3.2.2 Interface Design Limit Load Requirements
Recommendation:
The paragraph number is out of sequence and should be 3.3.1.7.3.
Rationale:
Consistency.
Response:
Agree. Numbers changed.
------------------------------------------------------------------
ID: 1746 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.5.1 Mounting Method
The method by which each sensor is mounted...
Recommendation:
The method by which each sensor component is mounted to the spacecraft shall be defined in the ICD, but will follow the approach of using customized secondary plates or kinematic mounts as appropriate.
Recommend deleting all after "ICD" to read:
The method by which each sensor component is mounted to the spacecraft shall be defined in the ICD.
Rationale:
The requirement is too restrictive. For instance, it precludes direct mounting of the sensor to the spacecraft. Recommend letting the spacecraft contractor determine the mounting method with the sensor contractor/IPO approval.
Response:
Agree. Added "The mounting method shall accommodate manufacturing tolerances, structural, and thermal distortions." In addition, the phrase "..but will follow the .. mounts as appropriate." will be deleted.
------------------------------------------------------------------
ID: 1684 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.5.4
Mounting Location and Documentation
Recommendation:
Change to "The integrating contractor and the sensor developer shall work together to determine the optimal location of the sensor on the spacecraft. This location shall be documented in the ICD."
Rationale:
The location of the sensor on the spacecraft is an extremely critical factor in the overall system design and sensor performance. The sensor developer must have input to the location in order to assure the sensor will meet its specification.
Response:
Agree. Change to read "The integrating contractor working with the sensor contractor shall determine the optimal location of the sensor on the spacecraft. This location shall be documented in the ICD."
------------------------------------------------------------------
ID: 1685 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.5.5
Drill Templates
Recommendation:
Delete all references and need of the drill templates. Use tightly toleranced dimensions on the Interface Control Drawing to control alignment, mating etc.
Rationale:
With today's CNC machining and Coordinate Measurement System capabilities the need for drill templates is diminished. Moreover the accuracies achievable with direct machining and inspection are typically better than what can be achieved with the drill templates.
Response:
No. This section was kept but reworded. The intention is to define requirements for drill templates only in those cases where they are appropriate, ie. simple planar interfaces.
------------------------------------------------------------------
ID: 1747 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.7.2 Sensor Structural Dynamics; 3.3.1.7.4.2, Combined Structural/Dynamic Analysis; 3.3.1.7.4.5 Structural Analysis
Paragraph 3.3.1.7.2
When the sensor is in its launch-locked configuration ...
Paragraph 3.3.1.7.4.2
A test-verified model is preferred ...
Paragraph 3.3.1.7.4.5
"In addition, those sensors under 50 Hz"
Recommendation:
Paragraph 3.3.1.7.2 specifies that sensors must have no frequencies below 50 Hz (in their stowed configuration). Paragraphs 3.3.1.7.4.2 and 3.3.1.7.4.5 seem to allow frequencies below 50 Hz. Please clarify.
Also, recommend rewording 3.3.1.7.2 as follows in order to generalize the requirement to sensors which are not locked "with a rigid clamped interface" in their launch configuration:
Rewrite Paragraph 3.3.1.7.2:
replacing "configuration with a rigid clamped interface " with "configuration " , replacing "sensor will not saturate" with "sensor is consistent"
replacing " satellite's control authority " with "satellite's control capability" to read:
When the sensor is in its launch-locked configuration, the fundamental natural frequency of the sensor shall be 50 Hz or greater, axial and lateral. For a deployable, the spacecraft integrating contractor shall specify a deployed frequency such that the sensor is consistent with the satellite's control capability. The sensor supplier shall ensure that the sensor control authority (e.g. a gimbaled sensor) will accommodate the specified deployed frequency.
Rationale:
Clarification.
Response:
When the sensor is deployed, it can have natural frequencies below 50 Hz. Thus, the requirement is to perform structural analysis for these deployed cases when the sensor has a natural frequency of less than 50 Hz. The term "with a rigid clamped interface" will be deleted. The term "will not saturate" is a stronger statement than "is consistent", thus that statement remains as is. The "satellite's control authority" will be changed to "satellite's control capability".
------------------------------------------------------------------
ID: 1672 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.7.2 Sensor Structural Dynamics
Deployed Lowest Natural Frequency
Recommendation:
Recommend that a TBR value for the deployed lowest natural frequency, e.g., 8 Hz (TBR), be put into this paragraph.
Rationale:
The value for this parameter could become a design driver if it is too high.
Response:
Agree. The objective is to keep the natural frequency of the sensor outside of the control band of the altitude control system. Change to read "The lowest natural frequency of the deployed sensor shall be greater than 6 Hz (TBR)".
------------------------------------------------------------------
ID: 1686 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.8
Pressurized System Design
Recommendation:
Change to "Sensors with pressurized systems shall follow the requirements of MIL-STD-1584C."
Rationale:
Existing paragraph only references itself.
Response:
Agree. However, MIL-STD-1522 is the compliance document for pressurized systems, not 1584.
------------------------------------------------------------------
ID: 1749 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.1.8 Pressurized System Design
Sensors with pressurized systems shall follow the requirements for the design of pressurized systems
Recommendation:
Please add requirements or reference to a document containing the requirements. The previous version invoked MIL-STD-1522.
Rationale:
Completeness.
Response:
MIL-STD-1522 will be added as a reference document.
------------------------------------------------------------------
ID: 1751 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.3 ElectroMagnetic Interference/Compatibility (EMI/EMC) Considerations
Data and telemetry signals shall be segregated from any power circuitry via a separate connector.
Recommendation:
Recommend deletion.
Rationale:
Redundant with paragraph 3.2.2.10
Response:
Keep paragraph 3.3.3 as is and moved to under 3.2.2.6. The first sentence of paragraph 3.2.2.10 will be deleted instead.
------------------------------------------------------------------
ID: 1752 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.3.2 Signal Cabling
Data signals shall be segregated to a connector separate from power-supply circuitry. The voltage drop ...
Recommendation:
Recommend deletion.
Rationale:
Duplicate of paragraph 3.2.2.10
Response:
Agree. Deleted paragraph 3.3.3.2 as suggested.
------------------------------------------------------------------
ID: 1753 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.3.3 Electromagnetic Interference Filtering of Space Vehicle Power
The sensor shall have EMI input filters installed on the sensor side of the power interface. This does not apply ...
Recommendation:
Recommend deletion.
Rationale:
Duplicate of paragraph 3.2.2.11
Response:
Agree. Deleted paragraph.
------------------------------------------------------------------
ID: 1770 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 3.3.3.4.3.1
External RF Environment
Recommendation:
Are these frequencies radiated by sources on the spacecraft? Are they always present? Please clarify.
Rationale:
Issue is relevant to sensor design and its measurement integrity.
Response:
These specifications are intended to cover the range of frequencies that may be encountered during the launch and ascent environment.
------------------------------------------------------------------
ID: 1771 Date Recvd: 12/20/96 Status: Open
Reference:
IRD 3.3.3.4.3.3
Spacecraft charging from all surfaces
Recommendation:
All efforts need to be exercised to control spacecraft surface potential at known low levels. The 10 kilovolt, two mJ discharge needs to be more completely described.
Rationale:
The spacecraft potential and the surface materials, as well as the 10 kilovolts 2 mJ discharges, are expected to have substantial impact on the integrity of the in situ measurements that will be part of the SES complement. It will also impact any in situ techniques that might be viewed as necessary complements to GPSOS.
Response:
The reference to the specific resistive test level has been deleted. A reference to using the levels specified in MIL-STD-1541A (a compliance document) was added with tailoring out of the resistive test specified. The IRD has been changed to a reference document.
------------------------------------------------------------------
ID: 1754 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 4.1 Random Vibration
The random vibration test levels are dependent on the Sensor Fairing internal acoustic environment and design of the spacecraft bus …
Recommendation:
Replace "sensor" with "payload" to read:
The random vibration test levels are dependent on the payload fairing internal acoustic environment and design of the spacecraft bus...
Rationale:
The word "payload" here refers to the launch vehicle payload.
Response:
Agree. The word "sensor" will be replaced by "payload" in this instance.
------------------------------------------------------------------
ID: 1673 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD 4.1 Random Vibration; p44 Protoqualification Level Acoustics
Acoustic versus Random Vibration Testing for Large Sensors
Recommendation:
Please consider allowing acoustic testing for large (e.g., > 200 kg) sensors instead of random vibration testing. Low level modal surveys could still be performed without jeopardizing the hardware.
Rationale:
For large sensors, random vibration testing can cause excessive levels in the unit under test that are unrepresentative of launch loads and can cause unnecessary damage to flight hardware. Vibration exciters have nearly infinite impedance and excite the frequencies in phase. This is unrepresentative of the more compliant spacecraft interface and nearly random phase of the launch excitation. Placement of control accelerometers for a large and complex sensor can cause some portions of the unit under test to be over stressed and vice versa. An acoustic test for such large sensors can demonstrate margins and workmanship without exposing hardware to unrealistic environments.
Response:
Yes. Paragraph will be rewritten to allow substitution of acoustics testing for sensor > 200 kg in lieu of random vibration testing. This requirement will be moved to the Protoqualification Level Acoustics section 4.5.
------------------------------------------------------------------
ID: 1755 Date Recvd: 12/20/96 Status: Open
Reference:
IRD 4.10 EMC/EMI, 4.10.1 EMI Testing
4.10 EMC/EMI
Electromagnetic verification testing undergo the following EMI/EMC tests:
1...
Recommendation:
There is no CS102 test described in MIL-STD 461D. The CS02 test of MIL-STD-461C is replaced with CS114 in the D version. Recommend deletion of CS102.
There is a requirement for a CS116 test in 4.10.1 (line before last, first paragraph) but the test does not figure in the series mentioned in 4.10. Should it be added there?
Should the last sentence of 4.10.1
"This segment level testing is independent of the space vehicle level testing, which also must be performed."
read:
"This satellite level testing is independent of the spacecraft-level testing, which also must be performed."
Rationale:
Clarification.
Response:
------------------------------------------------------------------
ID: 1740 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD Figure 2
Recommendation:
Recommend changing the word "Payload" to "Sensor" (on the right hand side of the Figure) and adding the lines which show data transfer paths.
Rationale:
Consistency with standard IPO terminology; completeness.
Response:
Changed as suggested.
------------------------------------------------------------------
ID: 1671 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD Figure 7. Maximum PLF Inner Temperatures
Units of Ordinate on Graph
Recommendation:
What are the units for Temperature for the ordinate of the graph?
Rationale:
Clarification.
Response:
The units are degrees F.
------------------------------------------------------------------
ID: 1575 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD Para 3.3.1.4.1
Sensor mass
Recommendation:
This document tells you to look in the SRD for the mass requirement; the SRD (section 3.2.4) tells you to look here.
Rationale:
Clarification of requirements
Response:
The allocations will be specified in the SRD, not in the IRD.
------------------------------------------------------------------
ID: 1582 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD Para. 2.1
Compliance Documents
Recommendation:
Contractors should be encouraged to propose internal or industry standards in place of listed MIL-STDs. Specifically, recommend retaining only MIL-STD 1553 and WRR 127-1 as compliance documents.
Rationale:
Most listed compliance documents either have been or are in the process of being canceled or revised as handbooks. It can be anticipated that all will be significantly redone before the CFI. Contractors should use the study time frame to acquaint the IPO with their internal practices to fully implement acquisition reform.
Response:
Acquisition streamlining dictate that we minimize our applicable documents and this specified list are the minimum set deemed necessary by the IPO. However, the offeror may recommend tailoring these documents, or substituting equivalent commercial U.S. or international standards, as appropriate for his sensor, as indicated in the Annex B, IMS instructions. Company internal standards are not acceptable since changes to the process are not controllable by the government and cannot be standardized between contractors. While many of these documents are being looked at for cancellation and conversion into handbooks, we will make every attempt to maintain an up-to-date list. The IRD has been changed to a reference document.
-----------------------------------------------------------------
ID: 1584 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD Sect. 4
Testing Provisions
Recommendation:
Test requirements should be developed during the study and depend on design maturity, design features, etc. Suggest Sect 4 be heavily streamlined to delete, for example, reference to the number and range of thermal cycles, etc.
Rationale:
Test programs should reflect a Òbest valueÓ approach and be consistent with acquisition reform principles. The program should reflect evolution so that later sensors receive substantially less testing as earlier test results show stability in manufacturing and related processes.
Response:
These test requirements provide guidance to the contractors and reflect the best testing practices to date. With up to 10 contractors developing test programs, baseline standards are needed to maintain an integrated, orderly testing approach. If, during the course of the sensor definition phase we find that a change to these requirements is beneficial, the requirement will be updated. The protoqual testing strategy reflects an approach of testing to a lower level than qualification for the first flight unit and then testing subsequent units at an acceptance level.
------------------------------------------------------------------
ID: 1583 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD Section 3
Requirements
Recommendation:
While most requirements are expressed functionally, a few are given specific values. In general, these should be re-expressed functionally at this stage of Phase 1 (through PDR).
Rationale:
Specific interface requirements will be developed jointly with the spacecraft manufacturer (through IPO).
Response:
Since there is not an established integrating contractor nor spacecraft contractor at this time, having a specific set of interface requirement values is necessary to establish a baseline for all sensor developers to follow. Otherwise, it would be difficult for the up to 10 sensor contractors to establish a functional baseline without the expection of some common values available across the sensor/spacecraft interface.
------------------------------------------------------------------
ID: 1563 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD, CMIS SRD IRD pg 4, para 2.1; CMIS SRD pg 5, para 2.3
Compliance Documents; Reference Documents
Recommendation:
In the IRD, MIL-STD-498 is listed as a compliance document whereas in the SRD it is listed as a reference document. Recommend that MIL-STD-498 be listed as a reference document in the IRD. This would be consistent with the intent of the IPD.
Rationale:
Clarification of requirements
Response:
Agree. MIL-STD-498 will be made a reference document instead of compliance. The IRD has been changed to a reference document.
------------------------------------------------------------------
ID: 1837 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD, SRD
Redundancy
Recommendation:
Much contained in the IRD is also included in the payload SRD, but frequently at a different level of detail. Will subsequent versions be made identical or will the redundant information in the SRD be removed? The goal is to have one document with interface requirements.
Rationale:
Response:
The intent is to have identical interface requirements in the SRD and IRD. The intent is to have the SRD a standalone document as much as possible.
------------------------------------------------------------------
ID: 1511 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD; CMISS SRD 3.2.5.4; 3.2.6.3.1.2
Heat Flux
Recommendation:
Recommend changing the TBD to TBS
Rationale:
The government should be responsible for providing external environment requirements to the sensor contractors.
Response:
Agree. Changed TBD for Heat Flux to TBS. The government will also specify the Thermal and Shock environments as it becomes available.
------------------------------------------------------------------
ID: 1512 Date Recvd: 12/19/96 Status: Closed
Reference:
IRD; CMISS SRD 3.2.5.6; 3.2.6.3. 2
Shock
Recommendation:
Recommend changing the TBD to TBS
Rationale:
The government should be responsible for providing external environment requirements to the sensor contractors.
Response:
Agree. Change to TBS.
------------------------------------------------------------------
ID: 1700 Date Recvd: 12/20/96 Status: Closed
Reference:
IRD; VIIRS SRD; CMIS SRD 3.3.4.1; 3.3.11.1.3.2; 3.3.11.1.3.2
Software Programming Language Requirements
Recommendation:
The paragraphs as currently written would appear to disallow using C++. We recommend that the standards be broaden to include C++ and other developing languages that will be supported in the commercial marketplace.
Rationale:
It is to early to define absolute software standards. Computer technologies and software development are proceeding at a rapid rate in today's marketplace. Considering that CDR is not until FY 01, there is plenty of time to adopt a standard yet take advantage of these new developments.
Response:
Accept. Section has been revised to indicate that a standard for operational flight software will be determined after sensor preliminary designs are completed.
------------------------------------------------------------------
ID: 1634 Date Recvd: 12/19/96 Status: Closed
Reference:
OMPS SRD Para. 1.2
NPOESS Nadir Crossing Time
Recommendation:
This section lists nodal crossing time for C1, C3 and C5 as 1300. This appears to be inconsistent with the TRD.
Rationale:
The TRD (TRD 3.7.1.1-1) states: NPOESS satellites shall be flown at a nodal crossing time of approximately 0530 LST (ascending), approximately 1330 LST (ascending), and 2130 (ascending) to optimize satisfaction of DoD and DOC requirements.
Response:
The nodal crossing time outlined in the SRD is a misprint The correct nodal crossing time for C1, C3, and C5 is 1330, consistent with the TRD.
------------------------------------------------------------------
ID: 1637 Date Recvd: 12/19/96 Status: Closed
Reference:
OMPS SRD Para. 3.2.4.1-1
OMPS Mass
Recommendation:
Recommend that the mass of the suite, 30 kg +/- TBR% be a guideline instead of a requirement, at this phase of the program.
Rationale:
An optimal solution for the ozone suite may not have a mass of 30 kg +/- TBR%.
Response:
The mass of 30 kg is a guideline. Reduction or growth of payload mass is implied by. Contractors are encouraged to provide detailed mass/performance data for designs that satisfy threshold requirements.
------------------------------------------------------------------
ID: 1636 Date Recvd: 12/19/96 Status: Closed
Reference:
OMPS SRD Para. 3.2.4.2-1
OMPS Dimensions
Recommendation:
Recommend that the dimensions of the suite, 47x49x20 cm +/- TBR% be a guideline at this phase of the program.
Rationale:
An optimal solution for the ozone suite may not have dimensions of 47x49x20 cm +/- TBR%.
Response:
The dimensions in the SRD are a guideline. Reduction or growth of dimensions is implied by "+/- TBR%". Contractors are encouraged to provide detailed size/performance data for designs that satisfy threshold requirements. This section has also been re-written to reflect new payload allocations.
------------------------------------------------------------------
ID: 1635 Date Recvd: 12/19/96 Status: Open
Reference:
OMPS SRD Para. 3.2.4.3-1
OMPS Power
Recommendation:
Recommend that the power of the suite 30 W +/- TBR%, be a guideline at this phase of the program.
Rationale:
An optimal solution for the ozone suite may not have power of 30 W +/- TBR%.
Response:
The power of 30 W is a guideline. Reduction or growth of payload power requirements is implied by "+/- TBR%". Contractors are encouraged to provide detailed power requirement/performance data for designs that satisfy threshold requirements. This section has also been re-written to reflect new payload allocations.
------------------------------------------------------------------
ID: 1951 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule continuation of H.3
Interfacing Contractor Relationships
Recommendation:
Subparagraphs (a), (d) indicate that each successful bidder must establish his own confidential relationships with the SETA and ATSP contractors. Why is this approach being followed as opposed to more traditional protection of development contractors by the government with respect to SETA contractors?
Rationale:
Seems inefficient to require separate negotiation of six NDAs
Response:
There are two relationships to consider, one with the governments SETAs and the other with the ATSP contractors. Paragraph H.3 should deal with the exchange of information just with the SETA contractors. The ATSP contractors will be deleted from this list. SETA contractors normally have clauses within their contracts to execute non-disclosure agreements for access to sensitive information, it is not an automatic protection.
------------------------------------------------------------------
ID: 1952 Date Recvd: 12/20/96 Status: Open
Reference:
Schedule H.5
Interaction with ...OATS & ...IGS Teams
Recommendation:
This section indicates that each successful bidder must establish his own confidential relationships with the multiple OATS and IGS teams. Why is this approach being followed as opposed to more traditional protection of development contractors with respect to SETA contractors by the government? Will an agreement be required with each individual member of each OATs team?
Rationale:
Seems inefficient to require separate negotiations for multiple OATS team members and IGS contractors or agencies.
Response:
OATS members are members of the government payload acquisition team and will interact with the contractors like any other government member of the acquisition team. However, there are cases where OATS members are private consultants or in academia and it is in those cases where non-disclosure agreements are necessary to protect any proprietary or sensitive information. These will be needed only for non-government personnel. The government personnel are handled by application of the Procurement Integrity regulations.
------------------------------------------------------------------
ID: 1953 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule H.6 TIMs with ATSP Contractors
Technical Interchange Meetings
Recommendation:
This section indicates that ATSP contractors will be precluded from access to proprietary and competition sensitive information at technical meetings. This is in conflict, it appears with H.3
Rationale:
Need to understand the intention of Government, and how to plan for contract startup.
Response:
Section H.6 is intended to protect sensor contractor's proprietary and competition sensitive infomration from ATSP contractors. ATSP contractors do not have the same status as SETA contractors. Section H.3 was to provide the means to sharing technical information with just the SETA contractors. The ATSP contractors will be deleted from this list in H.3. Section H.6 fourth sentence will be revised to read ". . required non-disclosure agreements for data of a non-proprietary nature with the ATSP contractors."
------------------------------------------------------------------
ID: 1889 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule Item Number 0033
CrIS Flight Unit #1
Recommendation:
Since this unit is delivered prior to the CrIS Prototype Unit (Item Number 0032), is Flight Unit #1 the Flight of Opportunity sensor? Also, the descriptive data section refers to a Conical Microwave Imager Sounder (CMIS). Please clarify.
Rationale:
Response:
The CrIS Protoflight Unit is really Flight Unit #1, the unit tested to protoqualification levels. While this unit is being refurbished, Flight Unit #2 will be built and acceptance tested and delivered as the potential Flight of Opportunity sensor. The CrIS Flight Unit #1 CLIN will be deleted. Also, the descriptive data will be changed from CMIS to CrIS.
------------------------------------------------------------------
ID: 1890 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule Item Number 0034
CrIS First Article Testing
Recommendation:
Please clarify the relationship between the CrIS Prototype Unit (Item Number 0032) to be delivered 04JAN02, and CrIS First Article Testing to be delivered 04JAN06.
Rationale:
Response:
The CrIS Protoflight Unit is Flight Unit #1, the unit tested to protoqualification levels. The CLIN for First Article Testing is nominally for testing the first flight unit (or the protoflight unit). This testing effort was separated from a specific unit because there may be situations where problems may cause the first article testing to be done on another flight unit other than the protoflight unit.
------------------------------------------------------------------
ID: 1891 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule Item Number 0035
Risk Reduction Flight of Opportunity for CrIS
Recommendation:
The descriptive data refers to the Conical Microwave Imager Sounder. Please clarify.
Rationale:
Response:
Editorial error will be corrected to refer to the CrIS.
------------------------------------------------------------------
ID: 1950 Date Recvd: 12/20/96 Status: Closed
Reference:
Schedule Option VIIRS-2, CLINs 0007 - 0014
Production Deliverable Instruments
Recommendation:
Paragraph 5 indicates that the government may select one or more of the referenced CLINs individually or in combination. Since pricing is heavily dependent on quantity to be procured, what pricing approach would provide best visibility to the government?
Rationale:
Best value to the government needs to be evaluated according to a common reference frame.
Response:
This question is premature as the RFP requires only the effort to PDR be priced. These options are to be priced at the CFI.
------------------------------------------------------------------
ID: 1531 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec B (3) OPTION CMIS-1 (Continued)
Clin 0018
Recommendation:
descriptive data: Contractor shall perform all required effort necessary to demonstrate the capability of a Conical Microwave Imager Sounder (CMIS) by delivering a prototype unit in accordance with Attachment 2 entitled "Integrated Master Plan (IMP), Attachment 3, Annex B entitled "Sensor Requirements Document (SRD) for Conical Microwave Imager Sounder (CMIS)," and Attachment 4 entitled "Interface Requirements Document (IRD)" (CPAF - Completion). This unit will be refurbished upon completion of protoqualification testing to replace non flight level parts and parts which may have been over-stressed during testing in order to return it to flight worthy condition.
Rationale:
The requirement to test and refurbish the prototype unit needs to be fully addressed. The revised commentary allows for a complete understanding of the efforts required to ensure flight worthiness. This CLIN must be exercised with CLIN 0017 in order to be fully effective.
Response:
The original descriptive data accurately reflects the IPO's requirements. Because the proto-qualification units are flight units, they should incorporate only flight-level parts and be built as flight-worthy units. The required test level should not result in over-stressing parts and require only minimal refurbishment of the unit. Added sentence "This unit will be refurbished upon completion of protoqualification testing to return it to flight worthy condition."
------------------------------------------------------------------
ID: 1816 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec B CLIN 0068, L2, 3.2.1.6.1
Cross-Sensor Algorithm Development
Recommendation:
The draft RFP does not seem to specify exactly how cross-sensor algorithm development will be handled. There are several important issues which the government needs to clarify. Who will be responsible for cross-sensor algorithm development? Who will co-ordinate between the sensor developers involved? What role will the OATS play? How and when will cross-sensor requirements be developed? It seems that cross-sensor development in any substantive form is currently absent from the RFP. We recommend strongly that it be included in the final solicitation.
Rationale:
Cross-sensor algorithm is crucial in achieving desired threshold/objective performance for certain EDRs.
Response:
The cross-sensor algorithm development CLIN has been deleted.
------------------------------------------------------------------
ID: 1665 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec B page (2) and following
Supplies or Services, Ground Support Equipment (GSE)
Recommendation:
No CLINs exist for electrical or mechanical GSE. Please consider adding CLINs and attendant requirements documents and specifications for GSE.
Rationale:
GSE will typically consist of two or more sets to support sensor factory, satellite vehicle integration, and launch site testing. One set could be tied to the Protoflight sensor with subsequent unit(s) time phased to support multiple site use.
Response:
At this time, the IPO has not identified a Ground Support Equipment (GSE) requirement. If a need for GSE is identified prior to the down-selection, the requirement will be included in the Call for Improvements.
------------------------------------------------------------------
ID: 1555 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec B Para (4)
CMIS-1 Prices
Recommendation:
Recommend changing the following apparent typographic error. "In the event the Government exercises Option OMPS-1 CMIS-1...."
Rationale:
This change will clarify the administrative requirements of the contract.
Response:
Editorial error will be corrected.
------------------------------------------------------------------
ID: 1536 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec B - Supplies or Services and Price/Costs Item No 0068, Page 135
Descriptive Data
Recommendation:
Add an additional paragraph at the end of the descriptive data. The recommended wording is, An early risk reduction study is required to define data fusion algorithms, demonstrate improved EDR performance, optimize sensor suite and algorithms and feedback results to the sensor suite and cross-sensor algorithm development.
Rationale:
Select the best NPOESS sensors and algorithms.
Response:
The IPO has determined that cross-sensor algorithm development effort is not a separate CLIN requirement for this RFP.
------------------------------------------------------------------
ID: 1819 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec B and Section L2 CLIN 0015, 0017, 0018 and Section L-2, para 1.8,
Schedule Information
Recommendation:
Please verify that the schedule information provided in the Proposal Preparation Instructions take precedent over those identified in the CLINs.
Rationale:
Consistency in proposal pricing.
Response:
In the event of a discrepancy, the sample schedule information in the model contract has precedence over Section L. Note that Section L, paragraph 1.8, states that the schedule information is provided for informational purposes only and does not reflect the Government's requirements. The inclusion of these dates is not intended to substitute for the offeror's independent determination of the appropriate schedule in its proposal.
------------------------------------------------------------------
ID: 1666 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec B, Briefing to Industry, 21 Nov. 96 page (10) and (38) of RFP; p IB 76 and IB 88 of Briefing
Flight Unit 1 CLIN for VIIRS (CLIN 0005) and CMIS (CLIN 0019)
Recommendation:
The CLINs in RFP Section B for VIIRS and CMIS indicate that a Flight Unit number 1 will be procured in addition to the Protoflight Unit. The schedules in the Briefing to Industry indicate no Flight Unit 1. Which is correct?
Rationale:
Resolve apparent discrepancy.
Response:
The DRFP CLIN structure incorrectly shows separate protoflight and first flight units and will be revised to show that the protoflight unit is flight unit no. 1.
------------------------------------------------------------------
ID: 1526 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec F CLIN 0016: (2) Period of Performance
The second listing for CLIN 0020
Recommendation:
The second listing of CLIN 0020 should be changed to CLIN 0021.
Rationale:
Response:
Corrected as noted (typographical error).
------------------------------------------------------------------
ID: 1556 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec F CLIN 0021, (2)
Period of Performance
Recommendation:
Please provide the date for exercise of Option CMIS-2 as soon as possible before the release of the RFP.
Rationale:
Improve industry ability to plan and execute the program
Response:
The RFP will be updated to reflect the Government's estimated dates for the option CLINs.
------------------------------------------------------------------
ID: 1557 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec F CLIN 0022-0028, (2)
Period of Performance
Recommendation:
Should Option CMIS-6 instead read Option CMIS-2. Also CMIS-7-12 in CLINs 0023-0028.
Rationale:
Clarification of requirements
Response:
Noted. Typographical error will be corrected.
------------------------------------------------------------------
ID: 1547 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec G Paragraph (2) INVOICE INSTRUCTIONS
Invoice Instructions
Recommendation:
It is not clear from the RFP which invoices are to be billed to NOAA and which are to be billed to DoD. Recommend this be clarified in the RFP.
Rationale:
This change will clarify the administrative requirements of the contract.
Response:
The invoice instructions will be revised to provide greater clarity. Note that obligation amounts will be tracked in the contract using the InfoSubCLINs established for DoD and NOAA funds.
------------------------------------------------------------------
ID: 1659 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec G- Part I- The Schedule Part I- The Schedule, Contract Administration Data
Invoice Instructions
Recommendation:
The CLIN schedule calls for generation of two invoices one for NOAA and one for DOD. The contractor is directed to send invoices to DOD until funding is expended and then to NOAA for the remainder. How will this work? What determines the level of DOD or NOAA funding for the CLINs? How will the contractor know when DOD funding is expended?
Rationale:
Clarification.
Response:
The model contract contains InfoSubCLINs for each CLIN which will be used to track the obligation of DoD and NOAA funds. Starting with the basic contract, and in subsequent modifications which obligate funds, the affected InfoSubCLINs will be revised to reflect changes to the amount of DoD and NOAA funds obligated. See also the payment instructions in Section G for each CLIN.
------------------------------------------------------------------
ID: 1641 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H SF30, Part I - The Schedule- Special Contract Requirements
5352.216-9002, Award Fee
Recommendation:
There is a minor contradiction between the award fee clause, which provides for a 5 page self-evaluation and the award fee plan (Attachment 8) which provides for a 10 page evaluation.
Rationale:
Response:
The 5 page limit stated in Section H clause 5352.216-9002, Award Fee, will be changed to 10 pages, consistent with Attachment 8.
------------------------------------------------------------------
ID: 1707 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec H Clause AMFC 5352.245-9000 pg. 140
ADVANCE CHANGE ADJUSTMENT AGREEMENT
Recommendation:
Delete this clause in its entirety.
Rationale:
Additional work is deserving of fee.
Response:
The use of an advance agreement can eliminate numerous urgent change orders in a procurement with complex requirements, in accordance with the clause prescription at AFMC FARS 5342.205(90). The purpose of this clause is not to reduce the contractor's potential for cost or fee for additional work. Thus, use of the clause is appropriate for this effort. The IPO assumes that the contractor estimates a certain number of such changes will occur and that the cost will be captured in the original contract price.
------------------------------------------------------------------
ID: 1527 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H H.4 Compliance With OCI
Mitigation Plan. See also Section L.3.
Recommendation:
The sensor contractor believes OCI does not apply to us. It appears that only ATSP contractors will be involved in OCI clauses. If an ATSP contractor is competing for an instrument, the other non-ATSP contractor should review and/or have copies of the OCI plans.
Rationale:
Non-ATSP contractors who compete for instruments will not have a need for the OCI clause since their involvement will be limited to only what they are producing.
Response:
The clause applies to the ATSP contractors and will be revised to clarify its application. The clause also will be revised to provide that copies of ATSP contractor OCI plans will be shared with the sensor contractors.
------------------------------------------------------------------
ID: 1528 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H H.6 TIMs with ATSP Contractors
Technical Interchange Meetings with ATSP Contractors
Recommendation:
Recommend that instead of segregating competition-sensitive information, that there be a segregation of information directly applicable to spacecraft interfacing. The information is likely to be competition-sensitive, but it would be shared on a "need-to-know" basis. We recommend revising the second and third sentences as follows:
"The Government intends that ATSP Contractors will have access only to data that are relevant to sensor-to-spacecraft interfacing and integration. The ATSP Contractors will not be present during the general presentation and discussion sessions. The sensor Contractor will, however, segregate data relevant to spacecraft interfacing, and reserve this data for sessions where the ATSP Contractors will be present. The Contractor will be responsible for executing ..."
Rationale:
It is likely that any useful technical interchange will require the exchange of competition sensitive data. This seems to be accepted and assumed in H.3 paragraphs (b) and (d). But it would be preferable to not reveal everything about the sensor and algorithm designs.
Response:
The IPO desires a broad range of opportunities for the exchange of data between participants in the NPOESS program and does not intend to restrict flexibility with regard to data rights and the exchange of data required to meet program objectives. However, the section has been clarified.
------------------------------------------------------------------
ID: 1820 Date Recvd: 12/20/96 Status: Open
Reference:
Sec H page 140, 5352.219-9001 Supplement
Subcontracting Plan
Recommendation:
Are the small business and small disadvantaged business goals applicable to the first phase of the contract, Preliminary Design?
Rationale:
SB and SDB goals are most often satisfied during the instrument development, manufacturing, and test phases.
Response:
Yes, the small business clause and goals are applicable to all phases of the effort, both prior to and after the down-selection, in accordance with FAR 19.708, as supplemented. The specific goals will be determined prior to release of the final RFP.
------------------------------------------------------------------
ID: 1578 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H Page 146, paragraph H.6
Technical Interchange Meetings w/ ATSP Contractors
Recommendation:
In the second line of the requirement, SCR H.4 should be H.3.
Rationale:
Typographical error.
Response:
Typographical error will be corrected.
------------------------------------------------------------------
ID: 1558 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H Pg (145), para H.3
Interfacing Contractor Relationships
Recommendation:
Recommend addition of clarifying language to define the process of working with the Interfacing Contractors which is through the IPO.
Rationale:
Clarification of requirements.
Response:
The language in SCR H.6 will be reviewed and revised, if appropriate, for greater clarity.
------------------------------------------------------------------
ID: 1838 Date Recvd: 12/20/96 Status: Open
Reference:
Sec H Part I, The Schedule,. 3.b, last sentence:
Down-Select Approach. "Proposal preparation costs will not be allowed as direct charges against the contract."
Recommendation:
It is understood that the CFI proposal is a required task within the Phase I contract. Given this, it is not understood why the Government has taken the position that the cost for this contract task should be unallowable as a direct charge to the contract. Please clarify.
Rationale:
All such costs are allowable, to the extent that they meet the criteria for cost allowability within the FAR Part 31
Response:
The IPO intends that CFI proposal preparation costs should be an indirect cost covered by bid and proposal funds, and not a direct cost to the contract. This position is based on the potential that new offerors may seek to compete when the CFI is issued, and it reflects the IPO's obligation to afford all potential offerors equal opportunity in this regard. The IPO is considering adding a Section H Special Contract Requirement to clarify this issue.
------------------------------------------------------------------
ID: 1643 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec H-3 H-4, H-5, H-6 Part I - The Schedule
When are enabling agreements required?
Recommendation:
At what point in the acquisition process, will enabling agreements be required by the PCO?
Rationale:
Clarification
Response:
Enabling agreements should be executed immediately upon award to facilitate contract performance.
------------------------------------------------------------------
ID: 1821 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec H.2 CLIN0016, Section B(4)
Option CMIS-1 Prices
Recommendation:
What is meant by the statement that the Option CMIS-1 price is increased if the Government exercises Option OMPS-1?
Rationale:
It appears to be a typographical error.
Response:
Noted (typographical error).
------------------------------------------------------------------
ID: 1580 Date Recvd: 12/19/96 Status: Open
Reference:
Sec H.2 and Sec M Para. (c)(2) and para 2.0 respectively
Basis for downselection
Recommendation:
The referenced paragraph does not provide any description of how past performance will be used in the down-selection process. Para. (d) provides specific down-selection criteria, but does not discuss past performance.
Rationale:
Weighting of past performance data versus other down-selection criteria can influence bid decision.
Response:
The discussion of past performance in Section H & Section M will be reviewed and, if appropriate, revised.
------------------------------------------------------------------
ID: 1529 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec I (5) AFMC FAR SUP 5352.243-9002
Not-to-be-less-than amount / NTE amount
Recommendation:
The not-to-be-less-than amount and/or NTE amounts should be stated in terms of fee only for cost CLINs.
Rationale:
The requirement for a not-to-exceed cost estimate on cost reimburseable CLINs is contrary to FAR. In accordance with FAR, and if the CLIN is a cost type CLIN, a contractor cannot expend more than the amount obligated and must stop work.
Response:
The use of Alternates III & IV for CPFF and CPAF CLINs is consistent with AFMC FAR Supplement 5343.205(92) and is not contrary to FAR. The purpose of the clause is to bound unpriced Change Orders and other undefinitized contractual actions by requesting a Not-to-Exceed (or Not-Less-Than) price. Accordingly, no change to the RFP is required. See AFMC FARS 5317.74, Undefinitized Contractual Actions, for an explanation of the context of the clause.
------------------------------------------------------------------
ID: 1546 Date Recvd: 12/19/96 Status: Open
Reference:
Sec I DFARS 252.227-7030, Page (151)
Technical Data-Withholding of Payment
Recommendation:
This clause authorizes a withhold of up to 10% of the total contract price for a contractor's failure to deliver technical data in a timely manner. Recommend that paragraph (a) of this clause be modified to delete the words "ten percent (10%) of the total contract price" and substitute the amount of "$100,000" in lieu thereof.
Rationale:
This clause permits a lesser withholding amount. The proposed amount of $100,000 is equivalent to the maximum withholding amount specified in FAR 52.216-8, "Fixed Fee," paragraph (b). Also, the Government can use the expected award fee provisions of the contract to ensure the timely delivery of contract-compliant data.
Response:
The IPO agrees that, given the expected value of the contracts, that a lesser withholding amount will be sufficient to protect the Government's interest. The specific dollar amount or lower percentage will be determined by the IPO prior to release of the RFP.
------------------------------------------------------------------
ID: 1544 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec I FAR 52.243-6, Page (148)
Change Order Accounting
Recommendation:
Recommend that the threshold specified in the clause for implementing change order accounting be raised from $100,000 to $500,000.
Rationale:
This revision would make this requirement applicable only to major contract changes (i.e. only those that require certified cost or pricing data) and can, we believe, be implemented locally by the PCO because the implementation guidance for this clause states that the Contracting Officer Òmay insert substantially the same clauseÓ as the referenced clause.
Response:
The comment is accepted and will be reflected in the final RFP.
------------------------------------------------------------------
ID: 1638 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec I Part II, Contract Clauses
252.234-7001, CSCSC
Recommendation:
Will formal CSCSC be required in the first phase of the contract. We recommend formal CSCSC only be required after the downselect at PDR?
Rationale:
Clarification and simplification of program business functions
Response:
We are requiring that Earned Value Management be implemented during all phases of the sensor contracts. C/SCSC is the current means of implementing Earned Value Management. The requirement will be clarified in the final RFP.
------------------------------------------------------------------
ID: 1708 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg 147
FAR 52.227-, Alternate 1 and FAR 52.227-12
Recommendation:
Please insert the above FAR clauses in Section I.
Rationale:
The clauses are required for development work that is not under Cost-Type CLINs
Response:
(a) FAR 52.227-1, with Alternate I, does not apply to all CLINs, but to the cost-type development effort and will be moved within Section I to the appropriate sub-set of clauses. The basic clause without Alternate I applies to CLINs for the delivery of development units (flight units acquired on a cost-type contract basis).
(b) Use of FAR clause 52.227-12 is appropriate, as prescribed by FAR 27.303(b).
------------------------------------------------------------------
ID: 1711 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg. 147
Far 52.232-9 LIMITATION ON WITHHOLDING OF PAYMENTS
Recommendation:
Include this clause.
Rationale:
To limit the total amounts to be withheld at any one time to the greatest amount that could be withheld under any one clause or Schedule term.
Response:
The clause is already included, under the subset of clauses applicable to all CLINs.
------------------------------------------------------------------
ID: 1710 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg. 148
FAR 52. 246-23 LIMITATION OF LIABILITY and 52.246-25 LIMITATION OF LIABILITY SERVICES
Recommendation:
Include these clauses.
Rationale:
They are required if a deliverable CLIN is valued for less than $200k and for Services.
Response:
The use of FAR clause 52.246.24, Limitation of Liability--High-Value Items, already included in the RFP, is appropriate and sufficient. This clause will cover the delivery of flight units, if the option CLINs are exercised.
------------------------------------------------------------------
ID: 1709 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg. 148
FAR 52.243-7 NOTIFICATION OF CHANGES
Recommendation:
Delete.
Rationale:
This is not a mandatory clause and imposes additional reporting requirements on the Contractor.
Response:
The IPO believes that the notice this clause requires serves the interests of both parties by preventing constructive changes and disputes. The limited administrative effort associated with the clause is substantially outweighed by this mutual benefit.
------------------------------------------------------------------
ID: 1713 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg. 149
FAR 245-2 GOV'T PROPERTY
Recommendation:
Please add Alternate I.
Rationale:
Alternate I defines the responsibility.
Response:
In Section I, the application of FAR clause 52.245-2 will be revised by adding Alternate I.
------------------------------------------------------------------
ID: 1712 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION I Contract Clauses, pg. 149
FAR 52.211-11 LIQUIDATED DAMAGES
Recommendation:
Delete this clause in its entirety
Rationale:
This clause is not appropriate for the effort to be performed.
Response:
Use of the clause is appropriate in view of the importance of timely delivery of the sensors, as prescribed in FAR 11.504(a).
------------------------------------------------------------------
ID: 1715 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION II Contract Clauses page 153
FAR 52.245-5
Recommendation:
This was identified as subparagraph (6). Delete in its entirety.
Rationale:
The deviation cited is not generally acceptable to industry
Response:
At this time, the IPO believes the use of this deviation is appropriate.
------------------------------------------------------------------
ID: 1718 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION II Contract Clauses page 161
ENABLING CLAUSE FOR GENERAL SYSTEMS ENGINEERING AND INTEGRATION
Recommendation:
Modify this clause to add the requirement that Aerospace Corporation will execute a non-disclosure agreement with the contractor prior to receipt of any of the contractor's proprietary/competition sensitive/privately developed information.
Rationale:
To protect the contractor's data.
Response:
We do not believe that a revision of the clause is necessary to satisfy your concern. As an FFRDC, the Aerospace Corporation is obligated to protect contractor proprietary data by the terms of their contract with the Air Force. For this reason, the IPO perfers to use the enabling clause in its original form. However, you may execute specific non-disclosure agreements you believe are necessary directly with Aerospace.
------------------------------------------------------------------
ID: 1716 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION II Contract Clauses, pg. 158
AFMC 5352.216-9001
Recommendation:
Delete in its entirety
Rationale:
This clause provides for an arbitrary reduction in fee.
Response:
The clause stipulates that the fee amount will be stated in Section B of the contract. It is not intended to reduce fee in any manner. In particular, the clause states that the fee "may be increased or decreased only by negotiation and modification of the contract." Accordingly, use of the clause is appropriate for this solicitation.
------------------------------------------------------------------
ID: 1717 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION II Contract Clauses, pg. 159
AMFC 5352.235-9002 KEY PERSONNEL
Recommendation:
Delete in its entirety
Rationale:
Use of this clause can limit contractor ability to effectively manage its personnel.
Response:
The IPO does not believe that this clause interferes with the contractor's management of their personnel. The intent of the clause is to encourage the contractor to ensure that the key personnel included in the proposal are available to perform the effort as proposed. Because key personnel are a significant in the evaluation of the proposal, the use of this clause is appropriate.
------------------------------------------------------------------
ID: 1714 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I SECTION II Contract Clauses, pg.151
DFARS 252.227-7000 NON ESTOPPEL
Recommendation:
Delete this clause .
Rationale:
This clause is to be used for patent releases, license agreements and assignments
Response:
Noted. The clause is not applicable and will be deleted.
------------------------------------------------------------------
ID: 1839 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I Part II, Contract Clauses, Para (5), 5352.216-9001 - Payment of Fee (Jul 1992)
The applicable fixed fee or target fee may be increased or decreased.
Recommendation:
It is assumed that this acknowledges such changes can only result from bilateral changes to the subcontract. Please clarify.
Rationale:
Response:
The clause simply directs that the estimated cost and fixed fee (for a CPFF CLIN) are to be stated in Section B of the contract and, except in unusual circumstances, such changes are typically bilateral.
------------------------------------------------------------------
ID: 1840 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec I Part II, Contract Clauses, Para (5), 5352.243-9002
Not-To-Exceed / Not-Less-Than Agreements
Recommendation:
PCO clarification is requested regarding the objective of this clause. Are the anticipated limitations imposed on the contractor for the purpose of limiting the negotiated fee during the definitization process, or is there to be a fixed limit on allowable incurred cost and allocated fee, after the negotiation?
Rationale:
Response:
The purpose of the clause is to bound unpriced Change Orders and other undefinitized contractual actions by requesting a Not-to-Exceed (or Not-Less-Than) price. It is not intended to impose a limitation on the cost or fee associated with such changes. See AFMC FARS 5317.74, Undefinitized Contractual Actions, for an explanation of the context of the clause.
------------------------------------------------------------------
ID: 1892 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L 1.8 Schedule Information
EMD/Production Call for Improvement July '98 date too early
Recommendation:
The required 1st unit availability for CrIS is Jan 02, three years after go ahead for the build of the unit, as authorized by the PDRs complete, and EMD/Production Downselect. The call for improvement date, July '98 is six months before the PDR complete date and only 12 months after contract award.
Recommend slipping this date four months to November '98, still allowing two months before PDRs complete for evaluation.
Rationale:
Response:
The CFI date is being considered for revision. The PDR and CDR complete, Downselect, and first unit availability dates have been changed. The CFI date may move closer to the PDR date and will be reflected in the final RFP.
------------------------------------------------------------------
ID: 1514 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.1.2
Proposal Delivery Information
Recommendation:
Paper copies: . . .One of the paper copies shall contain all required original signatures (the cover page of the proposed contracts, the proposal model contract, representations and certifications (Section K), and GFP Written Authorization). The "Additional Documentation as Appendices to Volume V" shall be submitted with the proposal. Does this mean that the Appendices to Volume V will only be submitted electronically?
Rationale:
File Directory 2 - Model Contract (Section L, page 195, paragraph 2.3.5.3) list file names for the Appendices to Volume V.
Response:
The appendices to Volume V will be submitted both electronically and in paper copy. Only one of the paper copies need to have original signatures.
------------------------------------------------------------------
ID: 1896 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L 2.2 Proposal Format, (b)
Exceeding minimum technical, performance, reliability requirements
Recommendation:
Offerors are encouraged to "exceed requirements whenever feasible, providing there is no penalty in program schedule, risk, or cost..." There is always a cost for extra performance above some level, except perhaps where an item is available off the shelf, and even then a reduction in performance could still save cost, schedule, or risk. We recommend that where performance is exceeded, contractors be required to justify why cost, schedule, or risk are not affected by return to threshold performance.
Rationale:
Technical, performance, reliability, etc. requirements are never present without cost, schedule, or risk implications.
Response:
Agree. The wording will be changed to have the contractors consider "a balanced approach" to impacts.
------------------------------------------------------------------
ID: 1524 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.2.2
Page Format Restrictions and Limitations
Recommendation:
Does this format apply to all of Volume III-Cost Volume and the unreproduced sections of Volume V-Model Contract?
Rationale:
Response:
Yes. The PDF documents in Vol III and the DOC documents in Vol IV will need to be submitted according to the format restrictions listed in 2.2.2. The Excel XLS files do not have to conform to the margin restrictions; however, the font size should be at least 8 point in height. Since there is no page restriction for the XLS files, this should not be a factor.
------------------------------------------------------------------
ID: 1520 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.2.2
PAGE FORMAT RESTRICTIONS AND LIMITATIONS
Recommendation:
Assuming that a compliance matrix included in the "front matter" of Volume II would not count towards the page count, would that file be submitted electronically as a PDF file?
Rationale:
All front matter e.g., transmittal letter, cover pages, tables of contents, lists of figures, etc. appears to be exempted from the page count.
Response:
Volume II alaready contains an Appendix C for a IMP Cross Reference Matrix that ties the SOO, CWBS, CLIN, SRD, IRD, and CDRLs to the IMP tasks. If there is a need to have another "compliance" matrix, include that as part of this appendix. The IRD has been changed to a reference document.
------------------------------------------------------------------
ID: 1515 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.3.1
Submission of Electronic Proposals, General
Recommendation:
Expand definition of "thumbnails".
Rationale:
Section L states: . . . Offeror shall submit portions of the proposal files in the Adobe Portable Document File (PDF) format. The Offeror shall generate "Thumbnails" within each PDF file.
Response:
"Thumbnails" are miniature views of each page in a PDF document. They are used to help navigating through a long document. "Thumbnails" and "bookmarks" have to be specifically created as part of the PDF document for it to display properly. The IPO is planning to use Adobe Reader to view the proposals since it represents a document in a manner independent of the application software, hardware, and operating system used to create it.
------------------------------------------------------------------
ID: 1516 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.3.5 and 2.3.5.1
CD-ROM Format and Structure, CD-ROM Root Directory
Recommendation:
The root directory will include all proposal files, two separate cover pages for file directories 1 and 2, two separate tables of content for file directories 1 and 2, one overall acronym list in file directory 1, a table of contents for the entire proposal, a proposal assistance file used to navigate through the proposal, and a "tab delimited ASCII file" containing offeror address and POC information.
Rationale:
Section L states: 2.3.5 CD-ROM FORMAT AND STRUCTURE. Each CD-ROM shall include proposal files in the root directory as well as two separate file directories as outlined in paragraphs 2.3.5.1-2.3.5.3. Each file directory shall include a cover page (DIR*CVR.PDF) and a table of contents (TBLCONT*.PDF) for that directory where * is 1 or 2 based on the file directory. Additionally, the Offeror shall provide a glossary of abbreviations and acronyms used, with an explanation of each (ACRONYM.PDF) in File Directory 1. The Offeror shall use the appropriate file extensions for each file corresponding to the proper format (i.e., FILE.DOC is a Word file). 2.3.5.1 CD-ROM Root Directory. Provide three files in the root directory of the CD-ROM. The first is a PDF file (TBLCONT.PDF) that serves as a table of contents for the entire proposal. The Offeror shall provide the capability to "jump" from this file using hypertext links to other files found on the CD-ROM. The second file (PROPINFO.PDF) shall contain information to assist the Government evaluators in navigating through the proposal files. For example, the Offeror should explain any hypertext links above the Government's minimum requirements in this file. The third file is a "tab delimited ASCII file" (KTRINFO.TXT) containing the following information in exact order with a tab between each entry. For blank entries, put in an extra tab.
Response:
Agree that the descriptions could be made simpler. Section 2.3.5 will be rewritten.
------------------------------------------------------------------
ID: 1522 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 2.3.5.2
File Directory 1 - Proposal Information
Recommendation:
File Name: COSTS.XLW should be COSTS.XLS
Rationale:
Microsoft Excel 5.0 uses the extension .XLS.
Response:
Agree. Excel 5.0 uses the extension XLS for their workbooks. The file COSTS.XLS should include the minimum of 5 worksheets specified in para 3.3.6.3.2.
------------------------------------------------------------------
ID: 1817 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 2.3.5.2, page 195 and L2, para 3.4.3
Relevant Past/Present Performance
Recommendation:
The Draft RFP indicates that contracts indicating performance by subcontractors on the offeror's team may be included. Is this required? Is it desirable? If so, would it be possible to expand the number of contracts which are allowed to be discussed from 10 to 15 if subcontractor experience is used?
Rationale:
The performance of a major subcontractor should be of some concern to the government and 10 contracts are simply not sufficient to account for the experience of the prime and one or two major subcontractors.
Response:
There are now no limits on the number of contracts that can be discussed. The only restriction is that these discussions including the Experience Matrix and narrative is limited to 20 pages.
------------------------------------------------------------------
ID: 178 Date Recvd: 9/30/96 Status: Closed
Reference:
Sec L 3.1.6.3.3.3
"The IDP segment will receive RDRs and process them as necessary into EDRs"
Recommendation:
Reword to state: "Elements of the IDP segment will receive RDRs and process them as appropriate for their missions into EDRs"
Rationale:
Clarifies IDP mission
Response:
Accept.
------------------------------------------------------------------
ID: 1519 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 3.2.1.4.8
Chapter 4 - Sensor and Sensor Subsystem Design
Recommendation:
Should this be paragraph 3.2.1.4.7.
Rationale:
Paragraph listing skips over 3.2.1.4.7.
Response:
Yes. Paragraph will be renumbered.
------------------------------------------------------------------
ID: 1897 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.2.1.5 Risk Identification and Mitigation
Operation of the OATS with respect to contractors
Recommendation:
How do the instrument teams, which will supply the retrieval algorithms, interact with the OATS? The sensors will be designed for flexibility. However, if the OATS provides new or changing algorithms/requirements well into the design phase of the sensor/algorithms it is possible to impact the design costs and schedule for the EDRs/sensors.
How are the changes in the functional and calibrational requirements to be incorporated? How are timely interactions fostered?
Rationale:
The interaction of the OATS and the Contractor teams can create a risk in the development of the products.
Response:
OATs members are members of the payload acquisition team and will interact with the contractos just like the other team members: meetings, comments, questions, suggestions are all controlled by the PCO and COTR. It is not the OATs' job to be providing algorithms or requirements to the contractors, so the concern about late submission of these inputs is unfounded. Any suggested changes in requirements will be handled just like any other requirements change for NPOESS.
------------------------------------------------------------------
ID: 1525 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 3.2.1.5.3
Chapter 5 - Risk Identification and Mitigation
Recommendation:
It is stated that design and performance requirements ... will be established prior to SDR. There appears to be no mention of an "SDR" anywhere else in the DRFP. Is this supposed to be SFR?
Rationale:
It would seem appropriate to establish these design requirements prior to SFR
Response:
Yes. The minimum required events are a tailored System Requirements Review (SRR), System Functional Review (SFR), and a Preliminary Design Review (PDR). "SDR" will be changed to "SFR".
------------------------------------------------------------------
ID: 1902 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.2.2.2, Risk Management
Risk Management
Recommendation:
Section 3.2.1.5, in Chapter 5, Risk Identification and Mitigation, seems to cover similar subject matter to this section. Is this intended due to separate review of Technical and Management Volumes?
Rationale:
Minimization of duplication and proposal effort.
Response:
No. Paragraph 3.2.1.5 addresses only the technical aspects of risk reduction while paragraph 3.2.2.2 addresses the management approach in handling a risk management program.
------------------------------------------------------------------
ID: 1903 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.2.3.1, Appendix II-A
Integrated Master Schedule
Recommendation:
Does not indicate time period over which IMS is required. Does the phase 1 proposal require an IMS to PDR/Downselect, or through delivery of CLINs?
Rationale:
Clarification of request
Response:
The instruction will be clarified to require the IMS to contain detailed schedule information for activities up through downselect. However, the IMS should also contain activities in lesser detail from downselect through delivery rather than in only general terms.
------------------------------------------------------------------
ID: 1898 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.4 Experience Matrix
Recommendation:
Will the "critical areas" of experience matrix be identified by the IPO? Will they be more detailed than the chapter titles of the technical volume?
Rationale:
Response:
No. These areas are the minimum areas that the contractor must address, additional relevant categories may be added by the contractor.
------------------------------------------------------------------
ID: 1521 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 3.4.1
Relevant Past/Present Performance
Recommendation:
Where does offeror cite company awards and certifications in Volume IV.
Rationale:
paragraph 3.4.1: The Offeror is cautioned that the Government will use data provided by each Offeror in this Volume and any data obtained from other sources in the development of performance risk assessment.
Response:
Any awards or certifications that the offeror feels should be mentioned should be included in either the narrative description of critical experiences (para 3.4.4) or in the 2 page information for each cited contract under sections (e), (g), or (h).
------------------------------------------------------------------
ID: 1523 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 3.4.4
Relevant Past/Present Performance
Recommendation:
The inclusion of contracts that were awarded, and continue to be worked on, or completed more than five years ago and are still relevant.
Rationale:
Response:
The NOTE will be changed to "Only information pertaining to contracts still in development, completed, or awarded during the past five years (July 1992 to present) will be considered relevant."
------------------------------------------------------------------
ID: 1517 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 3.5.1
Model Contract
Recommendation:
Offeror shall submit ten paper copies of its proposal (Section L, paragraph 2.1.2) not four copies. The original model contract will be clearly marked and identified as containing original signatures and will remain Volume V.
Rationale:
Section L states: . . . This original model contract must be clearly marked as containing the originals and will be Volume II. The original model contract will count towards the overall number of four copies delivered.
Response:
Agree. Ten paper copies of the proposal will be submitted. The original model contract will be marked as Volume V, not II.
------------------------------------------------------------------
ID: 1899 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.5.1 Model Contract
Clarify Model Contract
Recommendation:
The original model contract must be clearly marked as containing the originals and will be Volume II. Should this be Volume V?
Rationale:
Response:
Yes. See comment 1517. The reference will be changed to Volume V.
------------------------------------------------------------------
ID: 1832 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.5.2.3, Sensor Requirements Document
Proposed changes to IPO provided SRD
Recommendation:
Does the IPO expect a completed SRD as part of the model contract at the time the proposal is submitted?
Rationale:
Response:
No. The SRDs are draft documents that will evolve as we progress through the Risk Reduction phase with the help of the sensor and ATSP contractors. The contractor should identify any proposed changes he deems necessary as Atch 3.
------------------------------------------------------------------
ID: 1833 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L 3.5.2.4, Interface Requirements Document
Proposed changes to IPO provided IRD
Recommendation:
Does the IPO expect a completed IRD as part of the model contract at the time the proposal is submitted?
Rationale:
Response:
No. The IRD is a draft document that will evolve as the program progresses through the Risk Reduction phase with the help of the sensor and ATSP contractors. The contractor should identify any proposed changes he deems necessary as Atch 4.
------------------------------------------------------------------
ID: 1545 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L 5352.232-9002, Page (188)
Government Rough Order of Magnitude (ROM) program estimate by fiscal year.
Recommendation:
It is recommended that the Government provide the "TBS" values specified to industry as soon as possible prior to the formal release of the RFP.
Rationale:
This information is essential to facilitate proposal planning and execution by allowing the early allocation of cost targets to IPTs and to each team member.
Response:
The Governement is still considering whether the ROM budget estimate will be released in the final RFP.
------------------------------------------------------------------
ID: 1895 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L Continuation of L.2 Evaluation of Alternate Proposals
Alternate Proposals
Recommendation:
These requirements state alternate proposals (such as for combined proposals for 2 or more instruments) must be complete. This is a significant burden on a bidder. Could delta proposals be considered in this case?
Rationale:
Complete stand-alone alternate proposals, in addition to baseline proposals, are likely to be unaffordable by bidders. Government may lose significant benefit to the program from contractors unable to internally justify an additional, full proposal
Response:
The Government is still considering the requirements for alternative proposals. These questions will be answered in the final RFP.
------------------------------------------------------------------
ID: 1518 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L L-1(5)
Make-Or-Buy-Plan
Recommendation:
Offeror is required to submit a Make-Or-Buy-Plan with the proposal. Where does it go in the proposal?
Rationale:
Tables 2.3.5.2 and 2.3.5.3 (proposal directories) do not indicate where the plan is to go in the proposal.
Response:
The Make or Buy Plan will be submitted as Attachment II-E to the Management Volume.
------------------------------------------------------------------
ID: 1729 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, 1.2 Oral Presentations
Structure of the Oral Presentations
Recommendation:
Request additional details on the form of the presentation
Rationale:
To prepare for the oral presentation some ground rules would be helpful: Will questions from the government be permitted? Will facing page text be permitted? Will more than one briefer be allowed? Will the session be recorded for wider dissemination? Will the compositions of the audience be made available before the briefing?
Response:
The oral presentations are to present an overview of the offeror's proposal with an emphasis on the Technical and Management approaches. Since the Government will evaluate these presentations as part of the overall proposal, specific criteria are not necessary. Additional guidance on conduct of the oral presentations will be provided in the final RFP.
------------------------------------------------------------------
ID: 1725 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, 3.4
Relevant Past/Present Performance
Recommendation:
Do the experience matrix (3.4.3) and narrative description of past experience (3.4.4) count against the 20 page limit?
Rationale:
The example matrix in the draft RFP included several contracts. We suggest that a 2 page summary matrix listing all relevant contracts be included in addition to the 20 pages of marrative (i.e., Volume IV page limit increases to 22 pages).
Response:
The Experience Matrix with the narrative descriptions describing experiences in the critical areas will not be given an additional page limit. The number of contracts is now unlimited with no restrictions on page limits on each contract. The total page count will remain at 20 pages.
------------------------------------------------------------------
ID: 1721 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, para's. 3.5 and 3.5.3.2 , pg. 210 & 212
RFP exceptions
Recommendation:
The referenced paragraphs appear to be in conflict. Section 3.5 states that offerors that take exceptions to the T's & C's will be considered to be ineligible for award. Section 3.5.3.2 defines a specific appendix to document exceptions to the RFP and Model Contract.
Rationale:
Need clarification on how exceptions will be evaluated.
Response:
Agree. The sentence in Section 3.5 will be deleted. Exceptions will still be listed in Appendix V-B.
------------------------------------------------------------------
ID: 1719 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, para. 1.3,pg.190
Debriefings
Recommendation:
Request deletion of the word "Unsuccessful" in the first sentence
Rationale:
Successful offerors should be provided the opportunity to get a debriefing to enhance their future proposal preparation skills.
Response:
No change. The successful offeror will receive a post award briefing that can also serve to provide feedback on the strengths and weaknesses of the offeror's proposal.
------------------------------------------------------------------
ID: 1720 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, para. 2.2.2, pg. 192
Page format restrictions
Recommendation:
Please add the following statement to the end of the main paragraph in Section 2.2.2:
"These page format restrictions shall not apply to the viewgraphs that are provided in the Executive Summary."
Rationale:
The format restrictions and limitations are not appropriate for the preparation of viewgraphs which are designed to be readable after projection and magnification.
Response:
Agree. Para 2.2.2 will be changed to allow viewgraphs to have no format restrictions.
------------------------------------------------------------------
ID: 1722 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, para. 5352.232-9002, pg. 188
ROM Program Estimate Profile
Recommendation:
Request that when the table is completed in subsequent versions of the RFP, the estimated FY funding profiles be provided by sensor and/or sensor suites.
Rationale:
Having insight into Government estimated FY expenditures will facilitate the development of affordable best value offers for the sensors and/or sensor suites.
Response:
The Government is still considering if the funding profiles will be provided. This will be resolved in the final RFP.
------------------------------------------------------------------
ID: 1735 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, paragraph 2.3 (Submission of Electronic Proposals)
Evaluation Hardware/Software Configuration
Recommendation:
The referenced section of the RFP does not indicate whether the government is planning to allow offerors to test their electronic proposals in the government's electronic source selection environment. Will the offerors be allowed to test their electronic proposals in the environment that will be used for source selection and if so, when will the test period occur?
Rationale:
Software and hardware incompatibilities could cause difficulties reviewing and evaluating the proposals. These problems could significantly impact the government's schedule for source selection
Response:
We anticipate that a "test period' will be made available to test the electronic proposals for readibility. That period has not yet been established but will probably be about two weeks after the RFP is released.
------------------------------------------------------------------
ID: 1734 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, paragraph 2.3 (Submission of Electronic Proposals)
Evaluation Hardware/Software Configuration
Recommendation:
The referenced section of the RFP does not indicate whether the proposal can be submitted using self-extracting archive files (e.g., Zip files). Will this approach cause difficulties when electronically reviewing/evaluating the proposals?
Rationale:
Submitting the proposals on diskette using self-extracting files may be an acceptable alternative to CD-ROM submittal if the government's approach to electronic source selection is compatible.
Response:
Use of self-extracting files (using PKUNZIP, WinZip, or other such products) is allowed. As long as the extracted files are found in the appropriate directories as requested, this should not cause any difficulties viewing the proposal. We are planning to use Acrobat Reader to read the PDF documents, Word 6c for the DOC documents, and Excel 5 for the XLS files.
------------------------------------------------------------------
ID: 1733 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L L-2, paragraph 2.3 (Submission of Electronic Proposals) and Annex D (NPOESS Network Guide)
Evaluation Hardware/Software Configuration
Recommendation:
It is not clear whether the referenced portions of the RFP describe the exact hardware and software environment that the IPO will use to conduct the electronic source selection. (For example: Will laptops be used during the source selection to review the proposals? Also, what version of Word will be used--6.0a or 6.0c?) Will the IPO specify the exact environment that will be used for source selection so that offerors can prepare effective proposals?
Rationale:
The Network Guide at Annex D describes the electronic environment for pre-proposal communications with the IPO but does not indicate the environment for source selection. Providing this information to the offerors will allow us to adequately prepare the electronic proposals.
Response:
Section 2.3 provides information on submission of the electronic proposals. The government is planning to use Adobe Reader to read the PDF documents since it displays the document in a manner independent of the application software, hardware, and operating system used to create it. Word 6.0c, Excel 5.0, and Project 4.0 are the application software that will be used to view the other files not in PDF format.
------------------------------------------------------------------
ID: 1581 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Para (5)
Make or buy program
Recommendation:
Delete requirement for submittal of make-or-buy program with proposal for the first phase and change the not applicable threshold for future phases to $1,000,000 without reference to percentage of total estimated contract.
Rationale:
Minimize program cost and provide effective level of control.
Response:
The submission of a Make or Buy Plan is required and will be submitted as Attachment II-E of the Management Volume. The IPO needs to determine the offeror's intent and understand their approach to the eventual sensor development and fabrication processes.
------------------------------------------------------------------
ID: 1550 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Part IV - Paragraph 2.2.2, page 192
Page Format Restrictions and Limitations
Recommendation:
Paragraph 2.2.2 does not specify whether page counts will be determined on the submitted hard copy or viewed electronic submittal. We recommend page counts be determined by the submitted hard copy due to inconsistencies in Microsoft Windows printer drivers and fonts. Also recommend that if inconsistencies are evident between hard copy and soft copy, the hard copy submittal shall take precedence over the soft copy. Offeror agrees no pen and ink changes are allowed to hard copy.
Rationale:
Offeror has had experiences where documents produced on one type of platform and viewed on another type of platform sometimes have font display and print anomalies. Section L2 indicates Times Roman or equivalent is to be used for text and Arial for illustrations and tables. Subtle differences in font characteristics of the same name font by different font manufacturers or font substitutions by a different platform's operating system, print driver or printer can sometimes alter page breaks and special character encoding.
Response:
Agree. Paragraph 2.2.2 will be changed to specify that the page count will be determined from the hard copy. However, by using PDF documents, the inconsistencies with print drivers and fonts are minimized.
------------------------------------------------------------------
ID: 1623 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Part IV, L-(5) 5352.215-9006
Make or Buy Plan
Recommendation:
Although a Make or Buy Plan is specified, its location within the proposal is not given. Recommend assigning a location such as Appendix II-D of the Management Volume. This will allow for uniformity in proposal submission.
Rationale:
Response:
The Make or Buy Plan will be submitted as Attachment II-E to the Management Volume.
------------------------------------------------------------------
ID: 1727 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L Part IV, L-(5) 5352.215-9006, Make or Buy Plan
A Make or Buy Plan is specified and instructions provided.
Recommendation:
Although a Make or Buy Plan is specified, its location within the proposal is not given.
Rationale:
For uniformity in proposal submission, recommend assigning a location such as Appendix II-D of the Management Volume.
Response:
The Make or Buy Plan should be submitted as Attachment II-E to the Management Volume.
------------------------------------------------------------------
ID: 1564 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Pg (195), para 2.3.5.2
File Directory 1 - Proposal Information
Recommendation:
Table indicates that Executive Summary is limited to 15 pages. Paragraph 3.1 states that the Executive Summary is to be submitted in viewgraph format with facing text. It is assumed that the 15 page limit applies to the number of view graphs without facing text pages. Change Executive Summary page limit in table to 30 pages to accommodate both viewgraphs and facing text.
Rationale:
Insufficient page limit to satisfy proposal requirements.
Response:
Agree. The page limit will be reduced to 10 viewgraphs with facing page text for a total page count of 20. Para 2.2.2(a) indicates that when printed material is displayed on both sides, it is counted as 2 pages.
------------------------------------------------------------------
ID: 1559 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Pg (195), para 2.3.5.3
File Directory 2
Recommendation:
Recommend change page limit on Atch 8 - Award Fee Plan from none to N/A or delete the attachment from the directory.
Rationale:
Proposed contract type is CPFF for this phase of the program. (Also see comment CMIS1032).
Response:
No change necessary. The award fee plan will be submitted as requested. Only in the case of a single award will the award fee plan take effect. Otherwise, the plan will not be attached as part of the contract. This saves us time by not having to request the plan be submitted during proposal evaluations for the single award case.
------------------------------------------------------------------
ID: 1565 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Pg (201), para 3.2.3.1
APPENDIX II-A, INTEGRATED MASTER SCHEDULE (IMS)
Recommendation:
Requests offeror to provide an IMS for the sensor development program. This statement infers that both phases of the program, i.e., Risk Reduction and Detailed Design/Fabrication should be included in the IMS. Instructions for the IMP and CWBS address only the Risk Reduction Phase. Recommend that paragraph 3.2.3.1 be changed to indicate providing an IMS for the Risk Reduction Phase only.
Rationale:
Clarity
Response:
Para 3.2.3.1 will be changed to request the IMP and IMS provide the tasks and schedule for the entire sensor development effort. The proposal should follow the instructions in revised para 3.0 by describing the Risk Reduction phase activities in much greater detail than the Detailed Design and Fabrication phase activities. However, the latter phased activities will now be required in some detail rather than only in general terms. This will help us evaluate the proposal for para 3.2.2.4 on program execution.
------------------------------------------------------------------
ID: 1561 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Pg (204), para 3.3.6.2.2
Person Loading Schedule and Basis of Estimate (BOE) Sheets
Recommendation:
Following reference appears to have typographic error."(See paragraph 3.3.7.3 below for format)". Recommend changing reference to "3.3.6.3"
Rationale:
Clarification of requirements
Response:
Agree. The reference will be changed to 3.3.6.3.2.2
------------------------------------------------------------------
ID: 1562 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L Pg (211), para 3.5.2.8
Award Fee Plan
Recommendation:
This phase of the contract is CPFF. Award fee plan is not applicable for this phase Recommend that development of an award fee plan for subsequent phases be an IPT task for this phase.
Rationale:
Clarification of requirements
Response:
The first phase of the effort (prior to the down-selection) will be Cost-Plus-Fixed-Fee unless the Government elects to make only a single award for any of the sensors. In this case, the Government will award the initial phase on an award fee basis. The government is requesting an award fee plan be submitted and attached to the model contract in case of a single award. Otherwise, the award fee plan will not be attached. This saves time during proposal evaluation if the government does not have to go back and request award fee plans from the single contractor.
------------------------------------------------------------------
ID: 1825 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L Section L-2 3.4.4
Recommendation:
Expand the time frame criteria for relevant experience from the past five years to all relevant experience.
Rationale:
For example, most of the space-flight IR nadir and limb sounding experience precedes the draft RFP criteria. Constraining the relevant experience will significantly limit competition and preclude innovative solutions.
Response:
The criteria was changed to add "contracts currently in development." This permits listing of contracts awarded more than five years ago. Any other contracts completed more than five years ago would not be considered relevant because of the many technological and acquisition streamlining changes.
------------------------------------------------------------------
ID: 1824 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L Section L.2 (a)
Recommendation:
If a baseline proposal that is fully responsive to the most demanding SRD is submitted, submission of an alternate proposal that is fully responsive to the baseline SRD plus a second SRD should be allowable.
Rationale:
Preparation of each proposal will require significant Contractor and IPO resources and time. Most likely, alternate proposals will address innovative approaches to problem solutions. If one fully responsive proposal is submitted, why not allow submission of an alternate that demonstrates how the baseline can be expanded to meet the requirements of a second SRD? Requiring submission of multiple, fully responsive proposals before the most innovative solution is submissable may preclude submission.
Response:
The IPO is still considering what constitutes an alternative proposal and thus can be submitted as such. This should be clarified for the final RFP.
------------------------------------------------------------------
ID: 1823 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L Solicitation, Offer and Award Sheet; Cover Sheet, para 2.0
Recommendation:
Expand proposal response period from 30 days to 60 days.
Rationale:
Our standard software used in our Technical Publications group is Adobe Frame Maker. We are able to submit our proposal in Word, although this will require substantially more time for preparation. Nevertheless, since our standard software (and therefore our standard proposal process) is quite different from what is required, response to multiple instrument proposals within 30 days after release of the final RFP is likely to present a serious hardship to proposal teams.
Response:
The purpose of having our briefings to industry, draft RFP releases, and clarifications through comment feedback is to give enough time for contractors to anticipate and plan for meeting the proposal requirements. We feel 30 days is sufficient given the amount of insight into the RFP already being provided to the contractors.
------------------------------------------------------------------
ID: 1548 Date Recvd: 12/19/96 Status: Open
Reference:
Sec L and Annex B IMS/IMP Instructions 3.2.3.1, last sentence, Annex B, page 10, 2nd paragraph
IMS Resource Loading
Recommendation:
Paragraph 3.2.3.1 reads: "The IMS shall be based on an integrated network schedule that the contractor will resource load in hours by skill type."'
Page 10 2nd paragraph, second sentence reads: "The offeror shall provide a resource loaded Gantt chart...." and starting with the seventh sentence reads: "The resource loading shall be represented by functional and skill level hours for labor and by material content. These hours shall be time phased by quarter with a recurring/non-recurring breakout for each quarter using the attached resource loaded Gantt chart."
Recommend removing resource loading of the IMS as a proposal and contract deliverable. If not removed, need clarification or samples of requested formats in referenced paragraph.
Rationale:
Resource loading of the IMS is a duplication of similar effort in preparation of the cost volume and its associated formats, i.e. person loading, unpriced basis of estimates and realism information(see Section L2 3.3.6.2.2 and 3.3.6.2.3). Maintaining two separate resource systems (pricing and IMS) will add time, cost and complexity to the proposal preparation. IMS tools such as MS Project require very low levels of detail entry to obtain accuracy. It would be very difficult to change this level of detail in a timely manner during the dynamics of a proposal.
As a more effective alternative, summary level WBS Gantt bar charts could be provided in the proposal to compare the related cost volume formats to the IMS. The bar chart could be added to the Realism information section (L2 3.3.6.2.3.)
It is assumed that the resource loading of the IMS is for the proposal only and not a requirement for the contract. This would be inconsistent with the IMS data item description (CDRL A001, DI-Misc-81183) and the contractor's systems that support the current DID.
If resource loading of the IMS remains as a proposal requirement, samples of the requested charts/formats and information(ref. Annex B paragraph 2) would be helpful in ensuring that the offeror responds with the desired output.
Response:
------------------------------------------------------------------
ID: 1598 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L and RFP Attachment 1 Sec L. File Directory 2.3.5.3
Contractual Implementation of CWBS
Recommendation:
The instructions require the submittal of a Contract Work Breakdown Structure (CWBS) as Attachment 1 to the contract. This is also a CDRL requirement. We recommend that the CWBS not be incorporated as an attachment to the contract and that the CWBS be a CDRL item only, which can be updated through periodic submittals by the contractor requiring Customer approval.
Rationale:
If the Contract Work Breakdown Structure is an attachment to the contract, the contract will have to be formally modified to reflect any contractor-generated changes to the work breakdown structure. This would be administratively burdensome for both parties. This approach is consistent with other recent Government procurements.
Response:
The CWBS Attachment to the model contract is the actual contractual requirement to maintain the WBS. The CDRL is just the deliverable data item to be submitted to reflect the contract requirement. The IPO does not anticipate many, if any, changes to the CWBS that would require contract modifications to any extent. No changes to the RFP is necessary.
------------------------------------------------------------------
ID: 1579 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L2 198
3.2.1.5.2
Recommendation:
Add: "interfaces" following "design" in first sentence
Rationale:
Completeness
Response:
The specific risk reduction actiivites "sensor/algorithm architecture, design, and development" has been deleted. The IPO wants to have risk areas identified for any risk reduction activity the offeror feels is appropriate. If "interfaces" need to be addressed, include it in the proposal.
------------------------------------------------------------------
ID: 1901 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.2.1.1.
Performance Against EDR Requirements
Recommendation:
Asks for description of how conceptual design approach meets EDR thresholds. Should recognize that this is an estimate of performance, based on a new sensor concept and expanded, extended algorithms (in some cases). Since this is an estimate, the IPO should also require some analysis of "error bars" on these estimates, or at least a discussion of estimation error sources and uncertainties.
Rationale:
Best value for the government cannot be substantiated without a consistent basis for evaluating alternatives. High performance estimates with large error bars are not necessarily better than lower performance levels with high confidence.
Response:
The contractor is asked to describe how his approach meets EDR thresholds. Whatever method is used to convince the government that this is the "best' approach is left up to the contractor.
------------------------------------------------------------------
ID: 1869 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.2.1.6.5
Algorithm performance on a stand alone basis
Recommendation:
Suggest both "stand-alone" and Fallback modes be specified.
Rationale:
Various Fallback modes could exist that relate to loss of other payloads, the current instrument itself, or data access problems. Versus stand-alone which could just be radiometric data used to derive EDR's with static set of coefficients or initial provided data.
Response:
It seems we are defining "stand-alone" and "fallback" to mean the same thing. This is further described in the next sentence of the paragraph. Our intent to define the stand-alone mode as the condition when we have lost access to the sensor, other supporting sensors, and the data itself. No change is necessary.
------------------------------------------------------------------
ID: 1549 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L2 3.2.3.4 Appendix 2D , 3.2.2.1.6, Exhibit A CDRL A004 and A009, DFARS 252.234-7000
Earned Value Management Approach, Notice of Cost/Schedule Control Systems
Recommendation:
C/SCSC (DFARS 252.234-7000) is a requirement for the first phase of the program. Because the proposed value of the first phase will be below the C/SCSC threshold, the following is recommended:
a) Remove C/SCSC, and CDRL's A004 and A009 as a requirement for the first phase of the program.
b) The offeror will propose alternate cost effective business management approaches and deliverables for the first phase in support of paragraph 3.2.2.1.6. A section could be added in the IMP to cover this contractually.
c) Appendix 2-D will be used by the offeror to provide supporting documentation of an acceptable system to be used for the design and fabrication phase, which may exceed the C/SCSC threshold.
Rationale:
The proposed price for the first phase will be well below the C/SCSC threshold. By removing the requirement, you will allow the offeror more flexibility in proposing a cost effective management system given the size and scope of the first phase. The proposed first phase system should still provide the Government early insight into contractor's performance.
To provide confidence to the Government for future program phases, the contractor can still provide documentation/support on their full C/SCSC system in Appendix 2-d.
A full description of the system to be utilized on the second phase can be described in the CFI response.
Response:
We are requiring that Earned Value Management be implemented during all phases of the sensor contracts. C/SCSC is the current means of implementing Earned Value Management. The requirement will be clarified in the final RFP.
------------------------------------------------------------------
ID: 1818 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.3.6.1.5.1, page 203
Rates
Recommendation:
Will subcontractors be allowed to submit separate cost information directly to the government?
Rationale:
This avoids the problem of passing proprietary information through another contractor.
Response:
Yes. Paragraph 3.3.6.1.5.1 was revised to permit the subcontractors to send rates directly to the PCO.
------------------------------------------------------------------
ID: 1662 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L2 3.3.6.3.2.2
Person Loading Schedule
Recommendation:
At what WBS level is this cost format submitted?
Rationale:
Clarification
Response:
At the 3rd level.
------------------------------------------------------------------
ID: 1663 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L2 3.3.6.3.2.4
Schedule of Probable Subcontractors
Recommendation:
Is there a dollar threshold for subcontracts reported on this form? Please define "subs price", "prop hrs", and "prop price" on this form.
Rationale:
Clarification
Response:
The dollar threshold will be $100K. Subcontractor efforts can be lumped together if costs are under $100K. Costs over $100K, we want to have the subcontractor efforts separated. "Subs price" is the dollar value of the subcontractor's proposal to the prime. "Prop hrs" and "Prop price" are the hours and price of the subcontractor's proposal that are submitted by the prime as their proposedl hours and price for subcontractor efforts. We are interested in the changes that occur between the subcontractor's proposals and the prime's.
------------------------------------------------------------------
ID: 1664 Date Recvd: 12/20/96 Status: Open
Reference:
Sec L2 3.3.6.3.3
Structure of Cost Models
Recommendation:
Recommend this file be provided at a high level WBS and use average composite rates.
Rationale:
This should provide sufficient detail for analyses .
Response:
Agree. Level 3 of WBS is acceptable and average composite rates can be used.
------------------------------------------------------------------
ID: 1619 Date Recvd: 12/19/96 Status: Open
Reference:
Sec L2 3.4
Relevant Past/Present Performance
Recommendation:
Does the experience matrix (3.4.3) and narrative description of past experience (3.4.4) count against the 20 page limit?
Rationale:
Response:
Yes, the experience matrix and corresponding narrative descriptions of past experience will count toward the page limit for the Volume IV, Relevant Past/Present Performance. However, the IPO will consider whether the 20 page limit should be revised.
------------------------------------------------------------------
ID: 1622 Date Recvd: 12/19/96 Status: Open
Reference:
Sec L2 3.4.3
Relevant Past/Present Performance (experience matrix)
Recommendation:
Does the IPO intend to provide the experience categories which must be accounted for in the experience matrix called out in 3.4.3?
Rationale:
Response:
The minimum relevant experience categories are the Factors for the Technical, Management, and Cost Areas stated in Section M, paragraph 2.0, Specific Criteria. The matrix shown in Section L, paragraph 3.4.5 will be revised in the final RFP to include the experience categories taken from Section M which were not listed in the draft RFP.
------------------------------------------------------------------
ID: 1904 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.4.4
Past Performance
Recommendation:
Designating programs awarded from July 1992 to the present as the only relevant past performance is very limiting, since most ongoing space sensor developments last well beyond 5 years. Perhaps this could be replaced with "programs with significant activity in the last 3 years..." or some other reference to program activity rather than award.
Rationale:
There is generally a long period between award and delivery or termination of effort on space sensor developments. All relevant activity in recent years, regardless of award date should be included. This also helps avoid the dangerous practice of awards given to a contractor with no negative past performance in a certain period because they had no past performance.
Response:
The phrase "..currently in development, .." has been added.
------------------------------------------------------------------
ID: 1905 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.5 Volume V
Proposal Documentation
Recommendation:
Allowing no exception to anything in Sections A through K seems excessively stringent. Referenced Section 15.606 of the FAR, relating to program changes, seems to offer no clarification. Could this reference be in error? Some requirements could have a significant cost impact without providing concomitant value added to the Government. Should at least allow exceptions to be discussed in terms of changes benefiting the Government.
Rationale:
Clarification of requirements or assumptions under which this program is to be bid.
Response:
Agree. This sentence has been deleted. Exceptions, when properly substantiated, are allowed.
------------------------------------------------------------------
ID: 1906 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 3.5.2.5 Attachment 5
Government Furnished Property
Recommendation:
Requiring written permission for use of GFE for potentially hundreds of items as a part of a proposal may place significant burden on program management of the providing programs. Perhaps an agreement in principle, signed by the providing program, would be more cost efficient as a part of the proposal process.
Rationale:
Proposal activity efficiency. Minimum disruption to ongoing programs during a proposal activity.
Response:
Written permission is only expected for additional GFP items that are not already identified in Atch 5. If there are GFP on other contracts that the offeror wants to use in the course of this acquisition, then permission from the PCO or approving authority is expected.
------------------------------------------------------------------
ID: 1599 Date Recvd: 12/19/96 Status: Open
Reference:
Sec L2 Par. 3.3.6.1.5.1
Request for detail rate information
Recommendation:
Recommend deletion of the following requirements if the offeror has a government approved estimating system and proposes approved bidding rates (indirect and direct):
- Direct Labor rate escalation factors, the basis of the factors and method of application
- Data to support all indirect rates used in calculating the proposed costs
Rationale:
Simplifies the proposal evaluation process. Reduces the volume and time required by the government to evaluate the proposal.
Response:
The Section L cost proposal instructions will be revised, as appropriate, for clarification.
------------------------------------------------------------------
ID: 1625 Date Recvd: 12/19/96 Status: Open
Reference:
Sec L2 Para. 1.2
Structure of the Oral Presentations
Recommendation:
To prepare for the oral presentation additional guidance would be helpful:
-Will questions from the government be permitted?
-Should the presentation cover the entire proposal or selected sections?
-Will facing page text be permitted?
-Will more than one briefer be allowed?
-Will the session be recorded for wider dissemination?
-Will the composition of the audience be made available before the briefing?
Rationale:
Response:
Additional guidance for oral presentations will be provided in the Final RFP.
------------------------------------------------------------------
ID: 1538 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L2 Part IV
File Directory 1 - Proposal Information
Recommendation:
Paragraph 2.3.5.2 shows the file name for Section 3 - Cost Formats as "COSTS.XLW." Is the ".XLW" a typo and should this file really use the ".XLS" extension instead?
Rationale:
Typographical error.
Response:
Yes. Excel 5.0 uses the extension XLS for their workbooks. The file COSTS.XLS should contain the 5 minimum worksheets specified in para 3.3.6.3.2
------------------------------------------------------------------
ID: 1537 Date Recvd: 12/19/96 Status: Closed
Reference:
Sec L2 Part IV - 2.3.5, page 193
CD-ROM Format and Structure
Recommendation:
Paragraph 2.3.5 states ÒEach CD-ROM shall include proposal files in the root directory as well as two separate file directories as outlined in paragraphs 2.3.5.1 - 2.3.5.3.Ó The naming convention for the two separate file directories mentioned above is not specified in paragraphs 2.3.5.1 - 2.3.5.3. What specific directory names are to be used for the two separate file directories mentioned in section 2.3.5?
Rationale:
Recommend a consistent directory and file naming convention.
Response:
For lack of a better or more creative name, use DIR_1 and DIR_2 as the two separate file directory names.
------------------------------------------------------------------
ID: 1900 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 Section 1.2 Oral Presentation
Presentation evaluation
Recommendation:
What evaluation criteria will be used to evaluate the oral presenttion?
Rationale:
Response:
The Government will provide additional guidance with the final RFP. The criteria is already specified in Section M. The presentation is considered part of the overall proposal and not separately evaluated with different criteria.
------------------------------------------------------------------
ID: 1653 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec L2 Part IV- 3.5.2.1
CWBS Instructions
Recommendation:
Paragraph states "The CWBS must encompass the reporting level to the government requirements in CDRL A007." Should refer to CDRL A004 and/or CDRL A009 instead of A007.
Rationale:
CDRL A007 is Configuration Item Development Spec, not a report. Both CDRLs A004 (Cost Item Summary Report) and A009 (Cost Performance Report) refer to reporting in accordance with the WBS.
Response:
The reference has been corrected. It now refers to A005.
------------------------------------------------------------------
ID: 1834 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 1.0 General Basis for Contract Award
Page 214, Offeror's Capabilities
Recommendation:
". . . but will consider the ability and capabilities of the offeror to execute the Detailed Design and Fabrication Stage." Is this information presently explicitly requested in the Draft RFP in a particular format with area ratings and factors? What criteria will be used?
Rationale:
Response:
The criteria relating to the abilities and capabilities of the offeror to execute the program is listed in para 5.4.
------------------------------------------------------------------
ID: 1835 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 1.0 General Basis for Contract Award
Past Performance
Recommendation:
"Past performance of the offeror will be considered equally with other aspects of the evaluation as part of the Source Selection Authorities decision."
What are the scale factors for evaluation for Technical Approach, Management Approach, Cost, Past Performance and others such as "the ability and capability of the offeror to execute the Detailed Design and Fabrication Phase" and "the offeror CWBS Integrated Master Plan (including SOW) Integrated Master Schedule and Offeror proposed changes to the CDRL."
Rationale:
Response:
The importance of each area is specified in para 2.0: The Technical and Management Approaches will be have different ranking for importance. Cost is significantly less important than either Technical and Managment. Past performance is equal to all these areas.
------------------------------------------------------------------
ID: 1907 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 2.0
Specific Criteria
Recommendation:
Relative importance of areas "Technical and Management Approaches...are of equal importance, Area 3, Cost, is significantly less important than Areas 1 and 2 combined" leaves much room for mis-interpretation. For instance, if Technical and Management are both 30%, their sum is 60%. This still leaves 40% for Cost, which is larger than both Technical and Management, but "significantly less important than Areas 1 and 2 combined." Clarification is requested.
Rationale:
Clear understanding of Government priorities in the proposal response.
Response:
Agree. Changed to read ".. Area 3, Cost, is significantly less important than either Areas 1 or 2."
------------------------------------------------------------------
ID: 1908 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 4.0 Area
Technical Approach, 4.1 Factor 1: Performance...
Recommendation:
Refers here and elsewhere to "satisfaction of suite specific requirements" in the SRD. The EDR requirements, by and large, are in the TRD. They are referenced in the SRD, but defined in detail in the TRD. Given that requirements should not be defined in more than one place, shouldn't EDRs referenced in the SRD be defined in the TRD, unless superseded in the SRD?
Rationale:
Understanding the relationship between SRD and TRD. The SRD is intended to be a Sensor Requirements document, and as such should contain sensor requirements, not EDR requirements.
Response:
The TRD is not a contractual document for this RFP, it is only a reference document. Only the SRDs and IRD are contractual documents. Appendix D of the TRD was placed in the SRD Appendix D so the stand-alone SRD would have a list of all the EDRs. Unless we included the EDRs in the SRD, there would be no other mechanism to convey the EDR requirements. Any changes or modifications to an EDR that are specific to a sensor suite are stated internally to that SRD and will supercede values in the TRD Appendix D.
------------------------------------------------------------------
ID: 1661 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 6.1
Instant Contract Cost
Recommendation:
Please define the term "instant contract cost"
Rationale:
Clarification
Response:
The term "Instant Contract Cost" is used to define either the negotiated cost of the contract or the cost of the proposed effort. In this case, since this is a factor in the Cost Area, we are referring to the proposed cost.
------------------------------------------------------------------
ID: 1909 Date Recvd: 12/20/96 Status: Closed
Reference:
Sec M 6.1
Factor 1: Instant Contract Cost
Recommendation:
In determination of Adequate Price Competition, the Government will determine whether this exists. When will this be accomplished, as it impacts the requirement for certified cost of pricing data?
Rationale:
Understanding of proposal requirements
Response:
The government has anticipated that Adequate Price Competition will exist. Thus, no certified cost or pricing data is required (See Section L, (5)). If after receipt of proposals, we determine that APC does not exist, then the data will be requested and submitted for evaluation. The paragraph will be reworded to make this clearer.
------------------------------------------------------------------
ID: 1620 Date Recvd: 12/19/96 Status: Closed
Reference:
SF33 and Briefing for Industry (BFI) Section 9
Proposal Due Date
Recommendation:
The SF33 indicates the proposals will be due on 21 April 1997. This appears to be inconsistent with the 35 day turnaround mentioned in the BFI (assuming a 24 March 1997 RFP release).
Rationale:
Response:
The dates contained in the the industry briefing and the DRFP are tentative dates, though the IPO expects to provide 30 days for proposal preparation. This 30 day period reflects the IPO's belief that the information provided through briefings to industry and the DRFP process will facilitate a prompt presponse to the final RFP.
------------------------------------------------------------------
ID: 1535 Date Recvd: 12/19/96 Status: Closed
Reference:
SOO 1.0, Page 3
NPOESS Program Objectives
Recommendation:
Add an additional objective at the end of the paragraph. The recommended objective is, Conduct an altimeter risk reduction study to investigate EMI/EMC with passive NPOESS Sensors, develop improved altimeter measurement accuracy, extend tracking capability over ice and land, and improve spacecraft accommodation.
Rationale:
Early altimeter risk reduction activities are needed to define sensor improvements, reduce risk, and reduce cost.
Response:
Not needed. This is a specific objective to meet a technical requirement for an altimeter, more like a SOW rather than an objective. The SOO is a general program set of objectives. If risk reduction studies are needed in the course of developing a particular sensor, this activity should be outlined in the IMP/IMS as part of the contractor's proposed set of tasks.
------------------------------------------------------------------
ID: 1810 Date Recvd: 12/20/96 Status: Closed
Reference:
SOO 2.0
Risk Reduction Phase Objectives
Recommendation:
The current wording is: "The objectives of the Risk Reduction Phase are to reduce program risk prior to sensor downselect by performing the necessary requirements analysis; sensor definition; preliminary design; science algorithm development; risk identification and mitigation; technology demonstrations; and sensor cost analyses."
We suggest the following recommended wording: "The objectives of the Risk Reduction Phase are to reduce program risk prior to sensor downselect by performing the necessary requirements analysis; sensor definition; preliminary design; science algorithm development; risk identification, reduction, and mitigation; technology demonstrations; and sensor cost analyses."
Rationale:
Risk is a measure of the likelihood of an undesirable outcome and the consequence of that outcome. To mitigate risk is to lessen the consequence of the outcome; to reduce risk is to lessen the likelihood of the outcome. Adding the word "reduction" completes the thought and ensures all aspects of risk minimization are addressed.
Response:
Agree. The word "reduction" will be added.
------------------------------------------------------------------
ID: 1811 Date Recvd: 12/20/96 Status: Closed
Reference:
SOO 2.0
Risk Reduction Phase Objectives
Recommendation:
The current wording is: "Reduce or mitigate risks (programmatic, technical, supportability, cost and schedule) to a level sufficient to proceed into sensor detailed design and fabrication."
We recommend changing the wording to: "Identify all risks and risk reduction and mitigation strategies. Reduce or mitigate risks to a level sufficient to proceed into sensor detailed design and fabrication."
Rationale:
Enumerating types of risks in this context has the unintentional effect of limiting the scope of the risk analysis activity. Including "risk reduction" and adding "strategies" expands the ability to control risk.
Response:
The types of risks listed cover most of the standard risk areas that the IPO considers critical. Reducing risks assumes that all risks are identified as part of that process and it is not necessary to specifically list every activity in the SOO. The suggested wording is more appropriate for a SOW.
------------------------------------------------------------------
ID: 1728 Date Recvd: 12/20/96 Status: Closed
Reference:
SOO 2.1(a)
Flexible and Innovative Management
Recommendation:
The SOO calls for flexible and innovative management yet a number of government standards are specified in Section 2 of each Sensor Requirements Document.
Rationale:
The standards contain excellent guidance and information and capture years of hard earned experience. Dictating full conformance without tailoring or substituting "best commercial practices" may make the program more rigid and costly. Recommend the Applicable Documents of each SRD be made informational rather than directive in nature.
Response:
The specified government standards are the minimum set deemed necessary by the IPO. However, the offeror may recommend tailoring these documents, or substitute equivalent commercial U.S. or International standards, as appropriate, for his sensor, as long as the supporting justification is included in his proposal. This flexibility is provided under Section L, para 3.2.2.3.1 and 3.2.2.3.3. The IMP/IMS Instructions also provide further guidance on tailoring standards in para 3.0 (5) and Section.
------------------------------------------------------------------
ID: 1812 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 2.1
Applicable Document, Government Documents, Specifications
Recommendation:
There is no provision for specifying the natural space radiation environments. It is recommended that as a minimum MIL-STD-1809, Space Environments for USAF Space Vehicles be identified. Other possible references/documents include: NASA SP-8013 (Meteoroids) and NASA TM 100471 (Man-made Orbital Debris).
Rationale:
The sensors must withstand the on-orbit environment and still be able to deliver EDR/TDR/SDR performance. These requirements are mentioned briefly in paragraph 3.2.6.1 and should be included in the Government documents section for completeness and so that potential bidders do not gloss over the need to meet these requirements.
Response:
Documents are already listed in Section 2.3 Reference Documents.
------------------------------------------------------------------
ID: 1850 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.1.2.12
Cold Optics
Recommendation:
"The aft optics including a field stop shall be as cold as possible to minimize background radiation on the detector."
We recommend replacing this sentence with: The aft optics, including a field stop, shall be cooled to minimize background radiation on the detector.
Rationale:
Response:
Concur. Subject text to be revised to read: 'The aft optics, including a field stop if required, shall be cooled to minimize background radiation on the detector'
------------------------------------------------------------------
ID: 1921 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.1.4
On-orbit Monitoring of Calibration Sources
Recommendation:
Section 3.1.4 simply states the "Each VIIRS instrument shall perform the following functions:
On-orbit monitoring of calibration sources and instrument response changes."
Section 3.1.1 states, "In addition, a means for on-orbit monitoring of the quality of the on-orbit calibration and any temporal changes in the instrument response should be provided, if necessary to meet the EDR requirements."
Section 3.1.4 identifies a required feature. Section 3.1.1 allows the contractor to decide if the feature is needed. Please clarify.
Rationale:
Response:
See response to comment ID 1918.
------------------------------------------------------------------
ID: 1925 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.1.5
Operational Modes
Recommendation:
There are many spacecraft/sensor interactions required in the description of operational modes. How will sensor studies be influenced by Advance Technology Support program tasks conducted by the system primes.
Rationale:
Response:
Once sensor contracts are awarded, the ATSP prime contractors will review non-proprietary sensor data and identify interface issues to the government. The government will then determine whether further analysis is required by the sensor contractors to address the interface issues. There will be no direct interaction between the sensor contractors and the ATSP personnel at the primes without government oversight.
------------------------------------------------------------------
ID: 1927 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.2.1.1
Generation and delivery of EDRS
Recommendation:
The statement, "The generation and delivery of operational EDRS will be the responsibility of the IDPS contractor, not the VIIRS contractor," opens up a new IPO strategy to the payload sensor/algorithm development phase of the program. It hints that winning a Phase 1 study as part of a payload team does not provide a downselect opportunity to the algorithm developer for Phase 2 efforts. What is the role and responsibility of the IDPS? Who are they and how are they to be selected? Why is this not shown on your "optimized convergence Acquisition Schedule", "Architecture, Payloads & System Contractors" (Vugraph 15 -- Nov 21 Industry Day Briefing or Relationships and Interactions Vugraph 24 -- Nov 21 Industry Day Briefing).
Rationale:
Response:
The IDPS is the responsibility of the TSPR contractor, as briefed on the 21 Nov Industry Day. The VIIRS SRD language has been modified to make this clear.
------------------------------------------------------------------
ID: 1931 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.2.1.1.1.2.1
Requirements Verification
Recommendation:
How does a sensor contractor validate EDR requirements "from photons into the VIIRS instruments to EDRs out of the NPOESS IDPS" contractor. Separate references of responsibility (see 3.2.1.1, 3.2.1.1.2.1, 3.2.1.1.3) should be delineated and general statements like 3.2.1.1.1.2.1 should be structured to apply to sensor contracts or IDPS contractors in a more specific way.
Rationale:
Response:
The quoted text has been modified so that the responsibilities of the VIIRS contractor vice the IDPS (TSPR) contractor are clear.
------------------------------------------------------------------
ID: 1866 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.2.1.26
Absolute Readiometric Accuracy, Precision, Repeatability, Independent Calibration Review Board
Recommendation:
This section announces the IPO appointment of an independent calibration review board. Its make-up and "standards" should be disseminated as soon as possible and their S00/S0W and IMP/IMS should be made available to potential CrIS contractors, so that tasks relating to calibration can be incorporated into the sensor supplier's Phase 1 IMP/IMS, etc.
Rationale:
Response:
Section undergoing major revision. Section 3.2.1.26.1 sub-text to be replaced by: 'The absolute radiometric accuracy is the estimate of the bound of the unknown bias error of the calibration process root-mean-squared averaged with any random precision or repeatability component in a specific measurment. The manufacturer shall develop a detailed radiometric error analysis of the instrument, calibration sources, and calibration procedures and minimize errors in traceability to absolute NIST standards and estimate the bound on such errors.' SRDK3.2.1.26.1-1 subtext 'In support of this judgement' to be deleted.
Editorial Note: The intent here is that the specification reflect the fact that compliance to an absolute accuracy specification is not demonstrable by measurement; it requires detailed error analysis to establish the radiometric error in the tracability to some primary radiometric standard. Conventional calibration processes identify and compensate for systematic biases; the repeatability specification will limit the drift between calibrations; but the error that remains, apart from random precision or repeatability error in any particular measurement, is the unknown bias, the residual of the best calibration, the gist of accuracy which can only be estimated by those most familiar with the instrument and the calibration procedure (i.e. the manufacturer).
------------------------------------------------------------------
ID: 1874 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD 3.2.4.6
Endurance for 1st Unit (Flight of Opportunity)
Recommendation:
Will an alternate endurance requirement be recommended for the 1st unit?
Rationale:
The TIROS Flight of Opportunity unit appears to be an NPOESS pathfinder/prototype providing data to the community in advance of NPOESS C1. Specifying the endurance requirements of the NPOESS configuration may delay its availability. Is an alternate philosophy under consideration?
Response:
The sensor contractor is responsible for demonstrating that the sensor will meet the SRD endurance requirements. At this time we do not anticpate seperate requirements for the 1st unit.
------------------------------------------------------------------
ID: 1624 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Page 3, para. 2.1(a)
Compliance Documents
Recommendation:
Will the applicable documents section of each SRD be tailored during Phase I of this effort?
Rationale:
Yes, the applicable documents section of each SRD may be tailored during Phase I of this effort?
Response:
Agree. This section will be changed or deleted and wording will be provided that is sensor specific.
------------------------------------------------------------------
ID: 1600 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Para 1.2 page 1
Receiver definition
Recommendation:
The overview proposes to use two receivers to track both setting and rising occultations. Add one as option.
Rationale:
This should be possible to do with only one receiver.
Response:
Agree, the number of receivers will not be specified. However, the high accuracy reference oscillator should be in a separate box, and the instrument should be able to operate, with reduced clock accuracy, without the high accuracy clock.
------------------------------------------------------------------
ID: 1601 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Para 3.1.5.5 page 8
Payload WAIT Mode
Recommendation:
This is not much of a power saving mode, since with GPS + GLONASS an occultation even will always be present.
Rationale:
Response:
Agree. We will delete wait mode and define safe mode as "unit responds only to low level commands from ground for debugging and "upload commands" to replace high level code with new code image from ground."
------------------------------------------------------------------
ID: 1602 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Para 3.2 Page 9
Sensor Charateristics
Recommendation:
The draft RFP for the GPSOS is virtually 100% devoid of sensor specific performance specifications, but extremely detailed on boilerplate such as how the sheet metal must finished, connectors grounded, etc. Rather, the focus is on providing EDR's (environmental data records) that meet specific specifications. They do include basic spec's as follows:
Operation 5 standard modes, including autonomous operation (up to 60 days without gound intervention) Rcv cap. GPS AND GLONASS (L1 & L2 on both) No.Tr. Ch. 4-6 plus??? occultation channels Pos. Accuracy 1 km RT; 0.5 m after post processing
Mass: 9.3 kg
Size: 27X25X14 cm receiver
19X12X8 cm clock
15X15X2 cm antenna
power: 14 W (@28VDC)
com dual redundant 1553; 20kb's to 40 kb/s
temp -20#161#C to +50#161#C (+5 to 40#161#C operational)
reliability no single point failures
ION. EDR's TEC
(Required) electron density profiles
auroral boundaries
plasma density
ion. scintillation
N. Atm. EDR's Temp
(Goals) Pres
Moisture
Rationale:
Response:
The contractor is responsible for meeting the GPSOS primary EDR requirements and to interface with GPS and GLONASS satellites to provide NPOESS spacecraft POD and timing. The government has levied some minimal design specification requirements to keep the sensor within the cost constraints of the notional baseline system, but the sensor contractor is responsible for determining the sensor performance specifications required to meet the primary EDR and other requirements levied on the sensor.
------------------------------------------------------------------
ID: 1603 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Para 3.2.1.1.2 Page 9
SDR Requirements
Recommendation:
"permit realtime position determination of the DMSP/METOP mounted payload to within 0.5 meters". Delete or change requirement.
Rationale:
In our experience there is no need for a real time accuracy of 0.5 m to obtain the EDR's.
Response:
Agreed. Phase accuracy and precision processing specifications will be added consistent with a specification of 3.0mm (see Table 3.1.1.1 in revised SRD).
------------------------------------------------------------------
ID: 1604 Date Recvd: 12/19/96 Status: Open
Reference:
SRD para 3.2.1.10 page 11
Real-time Data Downlink Transmission Capability
Recommendation:
"The sensor shall conform to the DMSP/METOP system format and data rate." Does this mean HRPT?
Rationale:
Response:
Unique interface requirements, such as data rate and format, for GPSOS units which will fly on spacecraft other than NPOESS are TBS. (Instruments are being built to NPOESS requirements and any differences in meeting DMSP, METOP or POES may be handled by an interface box which would not be the responsibility of the sensor contractor.)
The SRD has been revised as follows:
SRDG3.2.1.5-1
The sensor shall conform to the POES/DMSP/METOP system format and data rate (TBS).
SRDG3.2.1.5-2
For NPOESS satellites, the sensor shall conform to the Consultative Committee for Space Data Systems (CCSDS) packetization per the (TBS) real-time interface specification and the (TBS) stored-data interface specification.
------------------------------------------------------------------
ID: 1605 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.25-1 page 12
Beam Alignment or Field-of-view Alignment
Recommendation:
The requirement to receive 4-6 non-occulted GPS/GLONASS vehicles, on a single S/C requires 3 antennas.
Rationale:
Response:
The number of antennas will be specified by the vendor.
------------------------------------------------------------------
ID: 1606 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.25-2 page 12
Beam Alignment or Field-of-view Alignment
Recommendation:
The requirement for 0.5m accuracy should be post processing only.
Rationale:
Response:
Agreed. See response to ID: 1603
------------------------------------------------------------------
ID: 1607 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.26 page 12
Minimun number of channels
Recommendation:
The requirement to receive 4-6 non-occulted GPS/GLONASS vehicles simultaneously, is very low. For combined realtime GPS/GLONASS navigation, at least 5 are required. For precise orbit determination in post-processing there should be at least 5 channels for GPS and 5 for GLONASS (non-occulted)
Rationale:
Response:
Agreed.
------------------------------------------------------------------
ID: 1608 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.27 page 13
Center frequency or wavelegth
Recommendation:
For GPS the capability to track the L5 signal to be introduced in GPS Block II F. For GLONASS, capability to track GLONASS N signals.
Rationale:
Response:
Agreed. The IPO wants ability to add L5 if and when it becomes officially available.
------------------------------------------------------------------
ID: 1609 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.29 page 13
Polarization
Recommendation:
Does the requirement for 30 dB below main lobe mean that the antenna shall provide 30 dB rejection of LHCP?
Rationale:
Response:
Agreed. Nominal specification of -10 dB min. It should be minimized to extent practicable.
------------------------------------------------------------------
ID: 1610 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.32 page 13
Doppler Correction
Recommendation:
Sensor should be able to give predictions of Doppler, but precise Doppler estimation can only be done on ground with ground network support.
Rationale:
Response:
Agreed.
------------------------------------------------------------------
ID: 1611 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.1.36.4 page 13
Instantaneous field of view
Recommendation:
Only one occultaiton event at a time? There can be up to 4 events (Rise + set) at the same time.
Rationale:
Response:
Agreed. Up to 4 simultaneous occultations are possible. The IPO will specify "up to 2 rising and 2 setting (all at the same time) for GPS. The same for GLONASS"
------------------------------------------------------------------
ID: 1612 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.4.1 page 14
Mass Properties
Recommendation:
9.3 kg. Does this include the antennas? Is this an internally redundant unit? (No single point failures)
Rationale:
Response:
Yes this includes antennas. Nominal mass is 9 kg or less.
The requirement regarding single point failures enables the contractor to determine where redundancy is pratical.
SRDX3.2.5.1.2-3
Single-point failures of the sensors shall be eliminated where practical on new or existing designs if they cause critical or catastrophic failures.
------------------------------------------------------------------
ID: 1613 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.4.2 page 15
Dimensions
Recommendation:
receiver/processor; 27 cm x 25 cm x 14 cm. rather small for an internally redundant unit.
antenna; 15 x 15 x 2. too small for good measurements of stratosphere and troposphere.
Rationale:
Response:
Agreed. Nominal sizes are provided and the final RFP will have updated values, but note that the values are TBR. Rising/Setting antenna will be constrained to interface (within volume and weight margins) to the NPOESS system. A nominal antenna area (assuming planar array) is 10" x 40". Note in the revised SRD that the GPSOS contractor is not required to meet stratospheric or tropospheric EDRs.
------------------------------------------------------------------
ID: 1614 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.4.3 page 18
Power
Recommendation:
Increase power figure.
Rationale:
14 watts is a low allocation for a sensor that has to track both set and rise occultations.
Response:
Agreed. Nominal values provided. The final RFP will have updated values.
------------------------------------------------------------------
ID: 1615 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.2.8.1.1 page 36
Computer Resource Reserves for Operational Space Elements
Recommendation:
the requirements for 100 or 200 % margin or growth capacity throughout this section has a sever impact on the GPSOS sensor and its resources (e.g.power), since this sensor will contain a considerable amout of S/W.
Rationale:
Response:
The requirement flows down from the system level TRD3.2.8.1.1-2.
The data processing subsystems of the space elements shall have 100 percent growth margin while meeting the original functional and performance computional requirements, including timing. This requirement allows the growth margin to be used if the government adds additional requirements.
The additional computing capacity and memory is necessary, given the life of the instrument and potential for code changes over the life. The government wants to to know the impact of requirement before considering deleting it for this instrument.
------------------------------------------------------------------
ID: 1617 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.3.12.10 page 47
Components
Recommendation:
How will exceptions/waivers be handled ? What about components from other PPL (e.g. ESA) ?
Rationale:
Instruments from both Europe and USA on both NPOESS and Metop.
Response:
Exceptions and waivers will be handled as per the Parts, Materials, and Processes Plan to be developed by the contractor and apporved by the government.
------------------------------------------------------------------
ID: 1616 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD para 3.3.2.4.1 page 38
Electromagnetic Compatibility
Recommendation:
The Radiated Emission/Susceptibility interface is very critical. It has to be specified in detail. (Compatibility with S&R, HRPTetc.)
Rationale:
Response:
Agreed.
------------------------------------------------------------------
ID: 1913 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD Payload Allocation Document
Figure 3-1 Specification Tree
Recommendation:
Page 7, Section 3.1.1 VIIRS description indicates that the VIIRS architecture will maximize performance while remaining within the overall weight, power, Volume and data rate limits specified in the PAD. Is the PAD available for review? Will it be listed as an Applicable Document? Will its requirements be included in the RFP's SRD?
Rationale:
Response:
The PAD is an internal government document and will not be available to contractors for review. Weight, power, volume, and data rate requirements will be provided in the VIIRS SRD.
------------------------------------------------------------------
ID: 1627 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Appendix B
Survivability Requirements
Recommendation:
(1) What is the relationship between Appendix B of the SRD and the AFOSI Multi-Disciplinary Intelligence (MDI) threat assessment, the NPOESS/DMSP system threat Assessment Report (STAR), and MIL-STD-1809 (Space Environment for USAF space vehicles)?
(2) Is Appendix B available? If not, when will it be available for review?
Rationale:
Response:
AFOSI MDI has been deleted as a reference. The DMSP/NPOESS STAR describes the threats to the system and Appendix B contains the classified survivability requirements which have been levied on the system as a result of the threats. The documents are classified and will not be made available until after contract award.
------------------------------------------------------------------
ID: 1802 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD Appendix D 40.2.1-3, second paragraph
Vertical cell size
Recommendation:
The vertical cell size is 2 km, and the reporting requirement is increments of 20mb, or less. Is this cell size sufficient to generate the requested vertical structure of the atmosphere?
Rationale:
In the lower atmosphere, 20 mb changes occur more often than every 2 km
Response:
Vertical cell size and vertical reporting interval are independent requirements. The fact that 2 km layers will overlap at the pressures at which a parameter is to be reported in the lower atmosphere does not imply a desire or requirement for greater resolution of vertical structure in the atmosphere than is entailed by the 2 km vertical cell size requirement.
------------------------------------------------------------------
ID: 1893 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD Appendix D 40.2.2 Atmospheric Vertical Temperature Profile
Horizontal cell size
Recommendation:
Clear worst case, is that the worst off-nadir case?
Rationale:
Understanding of definition
Response:
It is "off-nadir" worst case since nadir is specfied in the table. See para 40.1.6 Specification of Attributes at Nadir.
------------------------------------------------------------------
ID: 1783 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8
Space Environment EDRs
Recommendation:
The 17 EDRs deal primarily with the ionosphere and thermosphere the latter primarily affecting skywave and transionospheric C3I system users and the former primarily affecting ballistic missile defense and satellite tracking system users. From this perspective there are only two primary user EDRs: (1) ionospheric specification, i.e., electron density profiles from 100 to 700 km, and (2) thermospheric specification, i.e., neutral density profiles from 100 to 700 km. The users of all other EDRs (i.e., Te, Ti, drift velocity, auroral oval boundaries, solar flux, electric fields, etc., defined here as "secondary EDRs") are government modellers trying to develop a predictive capability. In order to sustain competition and bring maximum benefit to the government, the choice of predictive models and associated "secondary" EDRs should be left to the competing contractor teams. Current "government supplied models" could be made available through the OATS but would (should) compete (i.e. be tested) against the contractor supplied models for best accuracy, resolution, and near-to-mid-term predictability. The RFP should, in addition to calling out the two primary EDRs specified above, specify the time frame over which predictions are required (i.e. hours, days, etc.).
Rationale:
N/A
Response:
Space environment alerts/warnings and satellite anomaly resolution are two additional user applications driving SES requirements. The IPO does not intend to fund NPOESS contractors to compete with SES centers such as SFC or SEL to develop model based architectures to provide SES support. If a concept of support is already implemented which includes modeling, it might be more cost effective to levy the model input requirement on NPOESS rather than a new data requirement which requires substantial modifications to user support software to implement. These are trades that only those with insight into current and future support operations of the SES centers can make.
------------------------------------------------------------------
ID: 1782 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.1-4
Auroral Boundary
Recommendation:
This element of the EDR refers to the longitude. It appears that this is a restrictive specification implying the demand for an imaging requirement. Some domains of the auroral oval are more important than others and there is no need to call out for a full 0 - 360° specification in longitude. A reference, for example, is made to EDR 40.8.1 where the text suggests that the most important region or the region of highest priority in the specification of the auroral oval boundary is the equatorward boundary in the noon-midnight meridian.
Rationale:
N/A
Response:
This comment questions the validity of a current Space Environment Sensor EDR requirement. It will be referred to the ongoing SES Internal Government Study for consideration in Phase 2. See response to comment #1831.
------------------------------------------------------------------
ID: 1784 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD Appendix D 40.8.1-5
Auroral Oval Boundary, measurement uncertainty
Recommendation:
This specification is better if stipulated in terms of ÆMLT and ÆLat.
Rationale:
ÆMLT and ÆLat are physically more meaningful (i.e., more directly traceable to the underlying rationale for this EDR).
Response:
For some applications (e.g., use as input to a geophysical model) specification in terms of magnetic local time and latitude is probably more physically meaningful, as stated by the contractor. However, for other applications (e.g., a radar site wants to know whether the auroral boundary is anywhere within its field-of-view) a specification in terms of distance seems more appropriate. Since it is relatively easy to convert from distance to MLT/Mlat, no change to the requirement is considered necessary.
------------------------------------------------------------------
ID: 1795 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.10
In Situ Plasma Temperature
Recommendation:
Should be deleted and considered only as a secondary EDR. See comment on 40.8.
Rationale:
N/A
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1796 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.11
Ionospheric Scintillation
Recommendation:
We suggest changing the phase fluctuation index called for, "sigma-f," to two parameters that specify the phase fluctuation spectrum - namely, the power spectral density (rad2 per Hz) at a fluctuation frequency of one Hz (T) and the power-law spectral index in a two-decade (or so) frequency range that includes one Hz (p).
Rationale:
Scintillation arises fundamentally from phase modulation of a signal transmitted through an assembly of plasma-density irregularities. A one-dimensional cut through the three-dimensionally anisotropic spatial spectrum of ionospheric plasma density is imposed directly on the temporal spectrum of phase as the line of sight scans across the irregularities.
Intensity scintillation builds via focusing/defocusing and diffraction as the wave subsequently propagates. Its spectrum is cut off at the low-frequency (large-scale) end by "Fresnel filtering," which reflects the fact that the wave does not have sufficient propagation distance between the altitude of phase modulation and the receiving plane (typically the Earth's surface) to produce foci and diffraction patterns arising from the largest phase structures. The scintillation index, S4, called for on the document page referenced above is the square root of the integral across the entire normalized (by the mean) power spectrum of intensity, and it is a very appropriate and meaningful measure of intensity scintillation.
The power spectrum of phase does not undergo anything akin to Fresnel filtering. It propagates with little change (very slightly modified at the high-frequency end by diffraction) to the receiver. Thus it offers a very direct signature of the ionosphere's spatial spectrum of scintillation-producing irregularities. It has no natural cutoff, however, within the operating bandwidth of scintillation-measuring instruments nor within the modulation bandwidth of typical users of scintillation information. In principal, it is cut off by the outer scale of ionospheric irregularities, but this scale size is well outside the band of scintillation interest and measurability. In practice, it is cut off by the temporal length of the data-processing window employed for scintillation measurement. Thus, its integral, which is the square of "sigma-f," is ill-suited to characterizing the inherent strength of ionospheric irregularities.
Both "sigma-f" and T (as defined in the comment above) vary with the scan velocity of the radio line of sight across the narrowest dimension of the ionosphere's plasma-density irregularities, which in turn depends strongly on the scan direction across those highly anisotropic irregularities (extended greatly along the geomagnetic field). By performing spectral analysis of the recorded phase fluctuations, one can obtain the spectral index, p (also defined above), as well as the strength parameter, T. This is necessary in order to translate scintillation measurements to an appropriate (km-scale) portion of the (cross-field) spatial spectrum. Such a translation is needed to obtain the height-integrated irregularity strength parameter, CkL, alluded to in Section 40.8.9 (p. D-56) of the document referenced above. The phase spectrum should be characterized by means of a least-squares fit over a substantial band of fluctuation frequencies (0.1 to 10 Hz, say).
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1797 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.12
Neutral Density Profiles/Neutral Atmospheric Specification - Individual
Recommendation:
Requirements for identifying individual species densities (N2, O2, O). Species should be deleted as per comment on 40.8. If this requirement does appear in the final RFP "N2, O2, and O" should be changed to read "N2, O2, O, NO and metallic species."
Rationale:
NO and metallic species are critical components of the E- and F1-region of the ionospheric thermospheric domain and without their inclusion it would be impossible to develop predictive capabilities or full specification for that altitude regime.
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1798 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.15
Solar Extreme Ultra Violet Flux
Recommendation:
Delete. This should be considered a secondary EDR and left to the discretion of the competing contractor teams. See comment on 40.8.
Rationale:
N/A
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1799 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.16
Supra-thermal through Auroral Particles
Recommendation:
This should be deleted and left to the discretion of the competing contractor teams. See comment on 40.8.
Rationale:
N/A
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1800 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.17
Upper Atmospheric Airglow
Recommendation:
This item should be deleted. This is not an EDR per se. It is specification for an instrument. What instrument is to be used and whether or not remote sensing techniques are the ones that are most applicable should be left to the discretion of the proposing industrial teams. The primary EDRs are electron densities and neutral densities in the altitude range 100 to 700 km. These should be the drivers. Whether there is an optical technique that is appropriate or a contributing in situ technique should be left to the discretion of the proposing contractors.
Rationale:
N/A
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1785 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.3
Auroral Imagery
Recommendation:
Delete this EDR. Let EDR 40.8.1 be the driver, and let it be decided by the contract whether or not it is imagery that is necessary to meet the auroral oval boundary requirements. With respect to "inferences" dealing with auroral particles inputs - this is problematical at best. EDRs should not deal with "inferences".
Rationale:
N/A
Response:
The NPOESS Space Environmental Sensor requirements are ultimately derived from DoD and DoC end-user needs for space environmental specification and predictions. NPOESS is only one component of the systems currently evolving to meet these needs. For this reason, the NPOESS SES suite cannot be considered the sole source of data for meeting requirements, and requirements for SES EDRs which are not "fundamental", but are derived from the needs of the overarching system, are appropriate. While the SES contractor is free to suggest NPOESS-only means for meeting the underlying requirements, the development of the total system to completely meet end-user needs is not within scope of the NPOESS SES procurement. However, the IPO recognizes that the area of operational SES requirements is still in a state of evolution. This comment will be referred to the ongoing SES Internal Government Study for consideration in Phase 2. See response to comment #1831.
------------------------------------------------------------------
ID: 1786 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.4
Electric Fields
Recommendation:
Delete.
Rationale:
See comment on 40.8.
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1790 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.5-12
Density at an arbitrary altitude below NPOESS
Recommendation:
The threshold of 3x105 cm-3 implies a ±100% uncertainty at night and approximately ±15% uncertainty in the day at the F-region peak. Such a specification is not consistent with 40.8.5.-13 which calls out an uncertainty of 20%.
Rationale:
Contractor correctly identified an inconsistency in the specifications.
Response:
It is the IPO's understanding that the approximately 15-20% uncertainty during the daytime represents the minimum observational accuracy requirement for NPOESS electron density profile data to be operational useful. Hopefully, the eventually selected SES instrument suite will be able to improve upon the threshold and approach the goal. These requirements will also be reviewed by the Internal Government Study dealing the SES (see comment #1831). The specifications have been changed to remove the inconsistency identified by the contractor.
------------------------------------------------------------------
ID: 1787 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.5-3
Electron density profiles/ionospheric specification, Horizontal cell size 0-30 degrees latitude
Recommendation:
The threshold is specified as 200 km. That threshold should be changed to 100 km since 200 km is too big to resolve some of the important morphological features in the ionosphere. With this change the "objective" should also be changed to TBR.
Rationale:
N/A
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1788 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.5-4
Horizontal Cell Size in the 30-50 Degree latitude regime
Recommendation:
The threshold of 500 km is much too large. It should be changed to 100 km. See comment on 40.8.5-3.
Rationale:
N/A
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1789 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.5-6
Vertical cell size (for profiles)
Recommendation:
(A) "10 km within 100 km of the E/F peaks" should be changed to read "20 km from the F-region peak to the altitude of the NPOESS spacecraft". (B) "20 km elsewhere" should be changed to 5 km between the E- and F-region peaks, and (C) the 5 km objective should be changed to TBR.
Rationale:
(A) The lowest resolution required is on the topside. (B) The bottomside (i.e., the region between the E- and F-layer peaks) is often populated by intermediate, descending or otherwise sporadic layers that can have dimensions or vertical widths anywhere from 4 to perhaps as much as 15 km. If this resolution does not meet those types of dimensions, the specifications would be incomplete, inaccurate, and misleading.
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1792 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.6
B-Field
Recommendation:
Delete. B-Field should be considered as a secondary EDR left to the determination of the proposing contractor team. See comment on 40.8.
Rationale:
N/A
Response:
See response to comment #1785. However, it should also be pointed out that the requirement for this EDR is primarily derived from the need for global magnetic measurements to support improvements to the World Magnetic Model, not from Space Environment considerations.
------------------------------------------------------------------
ID: 1791 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.7
In Situ Ion Drift velocity
Recommendation:
Delete this EDR. Maintain the position in which the primary EDRs are the ionospheric specification of electron density profiles in the altitude range 100 - 700 km and the specification of neutral densities between 100 and 700 km. All other EDRs are secondary and should be left to the competitive judgments of competing contractors. See comment on 40.8.
Rationale:
N/A
Response:
See response to comment #1785.
------------------------------------------------------------------
ID: 1793 Date Recvd: 12/20/96 Status: Closed
Reference:
SRD Appendix D 40.8.8
In Situ Plasma Density
Recommendation:
The statement should read "used as an input and definitive boundary condition on uniqueness of remote sensing techniques for determinations of electron density profiles. Also used as an input and the boundary condition in determining and defining the accuracies and ultimate predictive capabilities of models."
Rationale:
Specification models and remote sensing techniques hinge critically on a large number of assumptions and/or simplifications which must be quantitatively constrained. An accurate "in situ" measurement of plasma density is one of the most accepted approaches to establishing this quantitative boundary condition.
Response:
The following has been added: "used to improve the accuracy of remotely sensed electron density profiles at altitudes near the NPOESS altitude and as a minor input to ionospheric specification models. Also used to quantitatively assess ionospheric model performance."
------------------------------------------------------------------
ID: 1794 Date Recvd: 12/20/96 Status: Open
Reference:
SRD Appendix D 40.8.8-4
Measurement Uncertainty ("in situ" plasma density)
Recommendation:
20% uncertainty should be changed to 15% to be consistent with 40.8.5-12.
Rationale:
N/A
Response:
See response to comment #1782.
------------------------------------------------------------------
ID: 1626 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Appendix D Generic to several EDRs
Mapping Uncertainity
Recommendation:
The EDRs have mapping uncertainty requirements specified at the threshold and objective levels. What portion of the mapping uncertainty requirement is allocated to the spacecraft?
Rationale:
When assessing compliance to this requirement, a portion of the error budget will need to be allocated to the spacecraft. By providing a spacecraft allocation, the IPO ensures that all offerors are providing comparable performance assessments.
Response:
The spacecraft characteristics that affect mapping uncertainty are specified in the Section 3.1.5 of the IRD. How these characteristics affect mapping accuracy depends on the specific geolocation algorithm utilized, and this algorithm is the responsibility of the sensor contractor. The IRD has been changed to a reference document.
------------------------------------------------------------------
ID: 1642 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Appendix D Page D-3
Atmospheric Vertical Moisture Profile, Measurement Uncertainity, 300 - 100 mb
Recommendation:
Recommend the measurement uncertainty requirement be specified as either:
(a) a percent of average mixing ratio (with average mixing ratio defined as either a global average or with respect to a mid-latitude standard atmosphere).
or
(b) the greater of a percent of average mixing ratio or .2 (TBR) grams per cubic meter
Rationale:
The atmosphere in polar regions at 300 to 100 mb is typically very dry. As such, specifying measurement uncertainty as a percentage of absolute humidity may be impractical.
Response:
See response to comment 1496. Also, where a percentage is specified, it is with respect to the true value of the parameter that is being measured, not with respect to a global average or a parameter associated with a model. See Appendix D, Section 40.1.4.
------------------------------------------------------------------
ID: 1644 Date Recvd: 12/19/96 Status: Closed
Reference:
SRD Appendix D Page D-39, 40.3.6
Total Water Content Measurement Uncertainty
Recommendation:
Two numbers appear in the TIWV measurement uncertainty requirement.
Rationale:
Clarification required.
Response:
The requirement has been modified so that one value refers to TIWV and the other value refers to the global average TIWV.
------------------------------------------------------------------
ID: 1759 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 2.3 Reference Documents
Duplicate document identifier.
Recommendation:
NAIC-1571- 727-95 National Telecommunications and Information Administration, 11 Sep 95 Manual of Regulations for Federal Radio Frequency Management, May 1989 NAIC 1571-727-95 Space Systems Threat Environment Description (TED) 11 Sep 1995 S/NF/WN/RD.
Rationale:
Correction
Response:
NAIC-1571-727-95 is the Space Systems Threat Environment Description, dated 11 Sep 95.
The National Telecommunications and Information Administrations "Manual of Regulations for Federal Radio Frequency Management" has been changed to the Sept 95 edition.
------------------------------------------------------------------
ID: 1760 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 3.2.4 to 6.1.4 (end of SRDs)
Recommendation:
These paragraphs are copied from old versions of the TRD and IRD. Recommend updating with new versions.
Rationale:
Completeness
Response:
Accept. The documents will be reviewed and corrected as needed.
------------------------------------------------------------------
ID: 1827 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 3.2.4.10.8 - High Rate Bus
Recommendation:
What is the maximum data rate constraint from the sensors? What is the capacity of the Mass Storage Unit.
Rationale:
Response:
The sensor data rate constraint will be defined in the SRD allocations. The capacity of the Mass Storage Unit is not yet determined but should not impact the sensor development. The storage requirement will be allocated to the spacecraft contractor when the sensors are designed and the needs are established.
------------------------------------------------------------------
ID: 1761 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 3.2.4.6 Endurance
3.2.4.6-1 The on-orbit design...
3.2.4.6-2 The design of the satellite ...
3.2.4.6-3 The design service life ...
Recommendation:
SRDC3.2.4.6-1
replace "satellite " with "sensor "
replace "mechanical wearout, battery life, solar array life " with "mechanical " to read:
"The on-orbit design life of the sensor, as may be limited by mechanical wearout or the exhaustion of expendables, shall be no less than 7 years."
SRDC3.2.4.6-2
replace "satellite " with "sensor" to read:
"The design of the sensor shall be such that satellite storage, under controlled conditions, may be planned for as long as 4 years."
SRDC3.2.4.6-3
replace "satellite" with "sensor" to read:
The design service life of the sensor shall be at least 11 years. This includes the time allowed for test, storage, prelaunch checkout, launch and injection, on-orbit, recovery, and contingency time.
Rationale:
Although the satellite incorporates the sensors and all satellite requirements apply to sensors, as appropriate, it is better practice to flow down the requirement to the sensors. The same comment applies to several other paragraphs copied from the TRD and IRD and not specified directly for sensors.
Response:
Accept and changes made.
------------------------------------------------------------------
ID: 1762 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 3.2.5.1 Reliability
3.2.5.1-1 Each Sensor Suite's reliability shall be no less than 0.84. TBR.
Recommendation:
SRDX3.2.5.1-1 Each Sensor Suite's reliability shall be no less than 0.84 at the end of 7 years on orbit life (TBR).
Rationale:
Per our analysis a reliability of 0.84 at the end of 7 years orbital lifetime, is necessary to ensure space segment operational availability of 95%. Any lower level of reliability will fail satisfying the availability requirement or will necessitate additional satellites.
Response:
Accept. Notice we have changed the .84 to .86 based on the our latest system availability analysis.
------------------------------------------------------------------
ID: 1621 Date Recvd: 12/19/96 Status: Closed
Reference:
SRDs 3.2.5.1.2-7, 8 and 3.2.1.3
Reliability and Redundancy Management/Antonomous Operations
Recommendation:
(1) What is meant by "a capability for automatic switchover to a backup component and/or circuit shall be provided. . .". Is this a requirement for the payload to perform autonomous redundancy management independent of the spacecraft and/or ground segment?
(2) What is the relationship between this requirement and the autonomous operations capability requirement?
Rationale:
Payload complexity driver.
Response:
This has been revised along with definitions of modes. The sensor is assumed to operate the same during satellite autonomous operations as during normal operations. The requirements now read as follows:
SRDX3.2.5.1.2-7
For instances of on orbit failure of a sensor suite, the sensor suite shall place itself into safe mode to await further commands by the spacecraft.
SRDX3.2.5.1.2-8
The contractor shall perform failure analysis to determine failures for which automatic switchover to redundant components is appropriate
------------------------------------------------------------------
ID: 1828 Date Recvd: 12/20/96 Status: Closed
Reference:
SRDs 4.1.1
Recommendation:
Are the sensor performance Acceptance Test for each individual instrument based on tests for and meeting the criteria set forth in the EDRs or SDRs?
Rationale:
Response:
Acceptance of the complete sensor/science EDR algorithm "system" for which the sensor contractor is responsible is based on validation at the EDR level. The SRD requirements which flow down from this are validated with sensor hardware acceptance tests.
------------------------------------------------------------------
ID: 1628 Date Recvd: 12/19/96 Status: Closed
Reference:
SRDs para. 3.2.5.5.3
Probability of meeting all requirements after a specified period of operational time on orbit (TBD).
Recommendation:
What is the relationship between this requirement and the reliability requirement of 0.84?
Rationale:
Response:
The reference is redundant with the reliability requirement and will be deleted.
------------------------------------------------------------------
ID: 1618 Date Recvd: 12/19/96 Status: Closed
Reference:
SRDs Para. 3.3.9.1-1, 2, 4, 5, 6, 7
Communications Security (COMSEC)
Recommendation:
(1) Does the sensor need to incorporate the capability to encrypt and authenticate data or is this a spacecraft command and data handling subsystem function?
(2) Does the sensor and/or spacecraft need to be able to have encryption that is commandable on/off or is there select data that is always encrypted?
Rationale:
Payload complexity driver (recommend allocation to the spacecraft).
Response:
See comment #1668.
------------------------------------------------------------------
ID: 1629 Date Recvd: 12/19/96 Status: Closed
Reference:
SRDs Para. 4.2.1.2.3-7
Requirement for a maintainability demonstration test
Recommendation:
What is the government's intention relative to the scope of this requirement?
Rationale:
The level of required maintainability may affect payload complexity.
Response:
The reliability and maintainability demonstrations have been deleted from the TRD para 4.2.1.2.3. They will be deleted from the SRDs. The requirement is to conduct life cycle tests on assemblies and subassemblies that are potentially life limiting and to demonstrate that the design life requirement can be met.
------------------------------------------------------------------
ID: 1801 Date Recvd: 12/20/96 Status: Closed
Reference:
The Schedule Descriptive Data for each sensor suite.
IMP
Recommendation:
The Integrated Master Plan (IMP) is to be provided, yet each sensor suite contractor is required to demonstrate their sensor suite's capabilities at PDR IAW the IMP.
Rationale:
N/A
Response:
Each sensor contractor will provide an IMP with the proposal and will be applicable only to that sensor contractor's activities. The sensor contractor will use the IMP as the roadmap to get to the PDR.
------------------------------------------------------------------
ID: 1765 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD 3.2.1.2.1 Data Availability to the Centrals
The percentage of time for preemption of NPOESS data downlink by a higher priority mission in a system that utilizes government resources is (TBR).
3.2.1.2.1-5
Ninety-five percent (95%) ...
Recommendation:
Recommend deleting the following: "The percentage of time for preemption of NPOESS data downlink by a higher priority mission in a system that utilizes government resources is (TBR)."
TRD3.2.1.2.1-5 add " This percentage is based on no preemption of NPOESS data downlink by a higher priority mission." to read: Ninety-five percent (95%) of the time, the elapsed time from the time of observation until all of the required EDRs have been processed at the Centrals shall be no greater than 1.25 times the length of an orbital period plus 30 minutes. This percentage is based on no preemption of NPOESS data downlink by a higher priority mission.
Rationale:
The capability of NPOESS should be defined independently from the other systems that use government resources. Therefore it is most suitable to specify the capability intrinsically, i.e., in the absence of interference from other missions. Please note that the requirement is quite stringent without preemption of downlink by higher priority missions and there is no room to make it more constraining.
Response:
Reject: The government wants the contractor to help establish the percentage of time we can be pre-empted and still meet the requirements.
------------------------------------------------------------------
ID: 1766 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD 4.2.1.1.2.1.3 Modal Survey
4.2.1.1.2.1.3-1
An appropriate test shall be performed ...
4.2.1.1.2.1.3-2
A modal survey test shall be required ...
Recommendation:
Suggest the following wording:
TRD4.2.1.1.2.1.3-1
replace "subsystem and subassemblies" with "physically separable assembly such as sensors and spacecraft appendages (solar arrays, antennas, ...) and subassemblies " to read:
An appropriate test shall be performed on each physically separable assembly such as sensors and spacecraft appendages (solar arrays, antennas, ...) and subassemblies, to identify the primary resonant frequencies. If the measured frequencies are greater than the upper frequency of the model required for the launch vehicle, then those frequencies may be the only data needed.
TRD4.2.1.1.2.1.3-2
replace "required for " with "performed on a satellite simulator and "
replace " subsystems" with " subassemblies" to read:
A modal survey test shall be performed on a satellite simulator and all systems/subassemblies whose primary resonant frequencies are not greater than the upper frequency of the model required for the launch vehicle.
Rationale:
Subsystems in general do not exist as separate entities on which a test could be run. The purpose is to determine the fundamental frequencies of the major pieces of hardware and spacecraft appendages, such as solar arrays and antennas, which contribute to the overall vibrational frequencies of the satellite. A modal survey, run on a satellite simulator (for example, the spacecraft outfitted with sensor mass simulators), will provide the exact satellite modes for incorporation in launch vehicle coupled load analyses. The modal survey will also allow verifying the accuracy of the satellite finite element model.
Response:
Concur with part 1 and TRD4.2.1.1.2.1.3-1 wording revised as suggested. Clarification is needed on the second suggestion (TRD4.2.1.1.2.1.3-2)) is not a correct sentence and can be read several ways.
------------------------------------------------------------------
ID: 1767 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD 4.2.2.1.4 Mass Properties
Actual weight, moment of inertia, and center-of-gravity (cg) measurements shall be made ...
Recommendation:
Recommend deletion of this paragraph and addition of the following requirement to 4.2.1.2.2.1 Single Configuration Item (CI) Compliance Tests:
4.2.1.2.2.1.4 CI Mass Properties TRD 4.2.1.2.2.1.4
Each hardware CI weight shall be measured and its moments of inertia and center of gravity determined to verify predictions and to ensure that the installed equipment meets final weight, moment of inertia, and cg requirements.
Rationale:
This paragraph is a subparagraph of 4.2.2.1 Satellite Prelaunch Validation Tests. No such measurements are performed at the launch integration site.
In industry practices, the hardware CI are usually weighed after manufacturing and in preparation for sell-off but the moments of inertia and cg locations are, most often, analytically determined.
Response:
Do not concur. Para 4.2.2..1.4 covers reporting results while 4.2.1.2.2 covers Qualification and Acceptance testing
------------------------------------------------------------------
ID: 1768 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD 4.2.2.1.5 High Pressure
4.2.2.1.5-1 Tests of all pressure subsystems of the integrated equipment shall be performed in accordance with MIL-STD-1540C (Paragraph 6.2.6).
Recommendation:
Recommend transfer of the paragraph to 4.2.1.1.2.1 Engineering tests.
Rationale:
This paragraph is a subparagraph of 4.2.2.1 Satellite Prelaunch Validation Tests. No such tests are performed at the launch integration site.
Response:
Concur: Wording in para 4.2.2.1.1-1 tranferred to para 4.2.1.1.2.1. Para 4.2.2.1.1-1 rewritten to cover Propulsion Subsystem Leakage in accordance with MIL-STD-1540C. SRDs will be changed accordingly.
------------------------------------------------------------------
ID: 1948 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD 40.2.1.3-2
Imagery, Horizontal Spatial Resolution
Recommendation:
The table and associated text implies that the threshold requirement for imaging at nadir is 0.4 km and 0.8 km at end of scan (worst case). Is this the correct interpretation?
Rationale:
EDR discussion is unclear.
Response:
The worst case may occur at edge of scan or may occur prior to edge of scan depending on the sensor design. The government intent is to not preclude pixel aggregation designs.
------------------------------------------------------------------
ID: 1764 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD Figure 3-1, A Partial Specification Tree
Recommendation:
Recommend adding lines from the boxes representing the SS Spec. and the IRD to the line from which the Sensor Spec. boxes trace down to show the traceability of the sensor requirements. Also, the old specification tree is still on page 9. Recommend deletion.
Rationale:
Completeness; consistency.
Response:
Lines added to new diagram showing flow down from the Space Segment and the IRD. The old diagram was deleted in TRD.
------------------------------------------------------------------
ID: 1763 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD Headers
Recommendation:
Except on the title page, the date of publication and the version indicator is not changed in the headers. Recommend changing to appropriate date and version number.
Rationale:
Consistency
Response:
Date and version number added to the 15 Nov. 96 TRD pages and will be added to all pages in future versions.
------------------------------------------------------------------
ID: 1698 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD Appendix A 10.1
System Line Spread Function (LSF)
Recommendation:
Add new definition in place of (or in addition to) 'System Point Spread Function (PSF)' to read as follows:
System Line Spread Function (LSF). The end-to-end system response due to a line source at infinity in a given bandpass. For a linear system, the system LSF can be expressed as a multiple convolution of the LSFs associated with all system components that contribute to the conversion of input radiance to the system output, e.g., the optics, detectors, signal and data processing.
Rationale:
The MTF and System Spread Function definitions are used in the RFP in TRD Appendix A 10.1 to define the Horizontal Spatial Resolution (HSR) which is specified in one of two orthogonal directions, whichever yields the greater value. The value desired is the one which defines the resolution in the prescribed direction averaged over the response along a line in the orthogonal direction. This provides the resolution in the selected direction averaged over the sensitivity footprint on the scene that is used to take a data sample. This is precisely what the line spread function Fourier transform provides, but the point spread function Fourier transform does not.
Response:
See response to comment 1697.
------------------------------------------------------------------
ID: 1697 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD Appendix A 10.1
Modulation Transfer Function
Recommendation:
Change definition from:
'The magnitude of the Fourier transform of the end-to-end system point spread function (PSF).'
to: 'The magnitude of the Fourier transform of the end-to-end system line spread function (LSF).'
Rationale:
The MTF and System Spread Function definitions are used in the RFP in TRD Appendix A 10.1 to define the Horizontal Spatial Resolution (HSR) which is specified in one of two orthogonal directions, whichever yields the greater value. The value desired is the one which defines the resolution in the prescribed direction averaged over the response along a line in the orthogonal direction. This provides the resolution in the selected direction averaged over the sensitivity footprint on the scene that is used to take a data sample. This is precisely what the line spread function Fourier transform provides, but the point spread function Fourier transform does not.
Response:
The IPO agrees that the MTF could be defined in terms of the system line spread function (LSF) rather than the point spread function (PSF), but there does not appear to be any advantage to doing so. The MTF defined in terms of the PSF is a function of two spatial frequencies associated with the mutually orthogonal in-scan and cross-scan directions. The HSR requirement imposes a constraint on this function at two points, one point on one axis and the other point on the other axis. These points are where the MTF equals 0.5 along these axes. Each of the two LSF Fourier transforms is equal to the two-dimensional MTF on one of the two axes. Whether we use two one-dimensional functions, the two LSF Fourier transforms, or one two-dimensional function, the PSF Fourier transform, to frame the HSR requirement, the requirement remains exactly the same. The definitions of PSF and MTF have been modified to be more explicit with respect to the two-dimensional character of the PSF and MTF. The definition of HSR has been modified to make clear that one of the two spatial frequencies is set equal to zero in defining the point where the MTF equals 0.5.
------------------------------------------------------------------
ID: 1690 Date Recvd: 12/20/96 Status: Closed
Reference:
TRD Appendix A 10.1
Horizontal Spatial Resolution
Recommendation:
In the last line, change: '...in the in-scan or cross-track direction, whichever is greater.'
to: '...in the in-track or cross-track direction, whichever is greater.'
or: '...in the in-scan or cross-scan direction, whichever is greater.'
Rationale:
Correct error, since in-scan and cross-track are two ways of describing the same direction
Response:
Accept.
------------------------------------------------------------------
ID: 1595 Date Recvd: 12/19/96 Status: Closed
Reference:
TRD, CMISS SRD Appendix D _ 40.4.5 and 40.3.6
Recommendation:
Thresholds for the cloud liquid water EDR (40.4.5) is not consistent with these for the CLWC EDR (40.3.6). Do these two EDRs relate to the same physical quantity?
Rationale:
Clarification of requirements
Response:
The defintion of Total Water Content (TWC) (40.3.6) has been revised. It is defined as the water vapor, cloud liquid water, and cloud ice liquid equivalent in specified segments of a vertical column of the atmosphere. TWC EDR 40.3.6 threshold is for a profile; CLWC EDR 40.4.5 threshold is for total column. The same physical property involved in CLWC is a component of TWC except that the former is required total column and the latter is required as a component of a profile. There is no requirement for consistency between EDR specifications since different EDRs may be required by different customers. The more stringent is always the driver.
------------------------------------------------------------------
ID: 1914 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 2
Applicable Documents
Recommendation:
Is any tailoring of the referenced directive documents allowed? If so, how should this be accomplished in the proposal.
Rationale:
Best value to government may require tailoring of compliance documents
Response:
See comment #1702
------------------------------------------------------------------
ID: 1911 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-83577B, Moving Mechanical Assemblies, be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-83577B will have significant impacts to both cost and schedule. While MIL-STD-83577B provides excellence guidance for the design of moving mechanisms, some commercial practices have been successfully demonstrated. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
See comment #1702
------------------------------------------------------------------
ID: 1912 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 2.1
Government Documents
Recommendation:
Request that MIL-STD-1547B, Electronics Parts, Materials, and Processes Requirements for Space Vehicles be made a Reference Document instead of an Applicable Document.
Rationale:
Imposing strict adherence to MIL-STD-1547B will have significant impacts to both cost and schedule. While MIL-STD-1547B provides excellence guidance for the selection of parts for space systems, the commercial communications satellite business has demonstrated that in many applications, non-MIL-SPEC parts perform just as well as the MIL-SPEC parts over long lifetimes (>10 Years) and are significantly lower in cost and can be procured in shorter times. The contractor should be held to delivering quality space sensors that meet performance and reliability requirements via on-orbit performance award fees, not by imposing costly specification.
Response:
MIL-STD-1547B changed to reference.
------------------------------------------------------------------
ID: 1917 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1
VIIRS Description
Recommendation:
The VIIRS is indicated to consist of two sensors; one an Imager/Radiometer, the other a Low-Light Visible Imager. Is it necessary for these two sensors to have the same scan geometry?
Rationale:
Depending on the design, the two scan geometries may be quite different, although covering the same ground swath.
Response:
The VIIRS is indicated to consist of one or more instruments in Sec. 3.1.1, not two instruments. The scan geometries of different instruments in the suite may be different.
------------------------------------------------------------------
ID: 1920 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1 VIIRS Description
On-orbit calibration
Recommendation:
This section says on-orbit calibration and monitoring of calibration quality should be provided. The later Section 3.1.4 references these capabilities with a shall. Which is correct? Does on-orbit mean while the sensor is operating in orbit, or does it imply more, such as that all functionality to perform the calibration must be on-orbit with the instrument that is explicitly precluding calibration strategies using ground truth with acquired imagery ?
Rationale:
Clarification of intent.
Response:
See response to comment ID 1918. Vicarious calibration strategies using ground truth are acceptable to augment the on-orbit end-to-end calibration, but may not replace it or be construed as being a part of it. However, if the contractor can demonstrate meeting all requirements using just vicarious calibration, the government would evaluate the presentation.
------------------------------------------------------------------
ID: 1915 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1 VIIRS Description
Adherence to weight, power, Volume, and data rate limits specified
Recommendation:
A document referred-to as PAD Payload Accommodation Document? is indicated as the reference to these resource parameters. However, it appears that other documents within the system such as ICD, IRD, SRD, etc. also may contain these parameters. Clarification is requested
Rationale:
Avoidance of multiple definition of requirements. Clarification of system documentation structure and requirements
Response:
Reference to PAD has been deleted. Weight, power, volume, and data rate constraints will be supplied in the VIIRS SRD.
------------------------------------------------------------------
ID: 1916 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1 VIIRS Description
Scan Geometry
Recommendation:
The comment regarding the scan geometry for all instruments in the suite should be the same. This is a should, and thus a goal, rather than an absolute requirement. If followed, it would severely limit the ability of the contractors to optimally satisfy the requirements and provide best value to the Government. The issue here is the ability to combine data from different physical sensors in the VIIRS suite while still meeting critical requirements such as mapping accuracy. That requirement should be a shall.
Rationale:
Clarification of what is important, versus design alternatives.
Response:
A "should" requirement provides greater freedom to the contractors than a "shall" requirement. If the contractor believes that the optimal VIIRS design has the same scan geometry for all instruments in the suite, then the contractor is free to propose and, if selected, pursue such a design. The government does not wish to overly constrain the design space with respect to the scan geometry of different instruments within the VIIRS suite. No change in the SRD is recommended.
------------------------------------------------------------------
ID: 1699 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1 & Figure 3-1
PAD as an Internal Government Document
Recommendation:
The VIIRS SRD 3.1.1 refers to limits specified in the PAD while Figure 3-1 indicates that the PAD is an internal government document. If the PAD is not to be released to contractors, an addition to 3.1.1 is suggested:
Change last sentence of first paragraph from: '...limits specified in the PAD.'
to '...limits specified in the PAD and enumerated in paragraph 3.2.4 of this SRD.'
Rationale:
Adds reference that is available to the contractor.
Response:
Reference to the PAD will be deleted in the SRDs.
------------------------------------------------------------------
ID: 1918 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1 and page 8, 3.1.4
On-orbit, end-to-end calibration and on-orbit monitoring of calibration quality.
Recommendation:
Paragraph 3.1.1 uses the word "should", while paragraph uses the word "shall" in connection with on-orbit calibration and on-orbit monitoring. What context is intended?
Rationale:
The type and accuracy/precision of on-orbit calibration should depend on the flow down of calibration requirements to the sensor, rather than being a mandatory requirement.
Response:
The shall context is intended for on-orbit, end-to-end calibration of all bands and the should context applies to on-orbit monitoring of the calibration system. The specific implementation of the calibration system and the need for, and implementation of, a monitoring system are left to the contractor to decide. The SRD has been modified to indicate these points consistently.
------------------------------------------------------------------
ID: 1696 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.1; pg.24, 3.2.4.1-1; 3.2.4.2-1;.3.2.4.3, 3.2.4.10.6; 3.2.4.10.8
Overall weight, power, volume, and data rate limits
Recommendation:
The VIIRS SRD 3.1.1 refers to the overall weight, power, volume, and data rate limits specified in the PAD. Since the PAD has not been released and the para.3.2.4 values are either TBS or blank, values for all sensors are requested. (The values in the library Phase 0 contractor studies are not necessarily valid because of updated requirements).
Rationale:
Notional values for these parameters for all instruments would provide guidance to prospective sensor contractors as to the relative preciousness of these spacecraft resources. An early release of these data (prior to the final RFP) would provide time to determine the impact of any significant changes that would drive designs or tradeoffs.
Response:
Agree. References to PAD have been deleted in the VIIRS SRD text. Design constraints will be included in SRD.
------------------------------------------------------------------
ID: 1922 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.4
Top Level VIIRS Functions
Recommendation:
LRPT and HRPT data packets are referenced. These are existing formats, defined for sensors with much lower data rates than for NPOESS. What are the expected or allowable changes to these formats and their implied data rates for NPOESS. Should the contractor define what these must be to satisfy RDRs and EDRs which must be transmitted to field terminals?
Rationale:
Understanding of requirements, interfaces, and obligations of the contract
Response:
See response to comment ID #1694. The contractor should define the NPOESS-specific High Data Rate (HDR) and Low Data Rate (LDR) formats within the constraints entailed by the SRD.
------------------------------------------------------------------
ID: 1919 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.4
Top-Level VIIRS Functions
Recommendation:
It is not clear from the material presented whether raw data is to be processed on-board the satellite into the various required formats such as HRPT and LRPT. Please clarify how and in what form data are to be transmitted by the spacecraft.
Rationale:
The VIIRS contractor must design the appropriate signal processing and formatting capability
Response:
The data and command interface to the spacecraft is specified in detail in Sec. 3.2.4.10. Any additional data processing, formatting, and routing performed by the spacecraft on data received from a sensor will be the responsibility of the spacecraft contractor, not the sensor contractor.
------------------------------------------------------------------
ID: 1923 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.4
Top Level VIIRS Functions
Recommendation:
Mentions "gain adjustments to meet dynamic range requirements." This is a design requirement which may not be needed in order to meet requirements. Perhaps a "as required, or if required" clause should be added, perhaps referencing globally such design requirements stated unequivocally within the SRD?
Rationale:
Performance versus design clarification.
Response:
Agree. SRD language has been altered as recommended.
------------------------------------------------------------------
ID: 1694 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.4, 3.2.1.1.2.1, 3.2.1.1.3.1, 3.2.1.10
Definition of LRPT & HRPT
Recommendation:
The acronyms LRPT & HRPT are not defined in the TRD Appendix A nor in std-def.doc. The intended VIIRS real time data format specified by these acronyms is unclear since the existing LRPT & HRPT formats for the current NOAA POES are inadequate to downlink either VIIRS spatial resolution or number of channels and do not conform to the CCSDS standards called out in the IRD. Recommend replacement of 'LRPT' & 'HRPT' with words or acronyms which better reflect the intent, such as 'real-time low data rate' or 'RLDR' and 'real-time high data rate' or 'RHDR'.
Rationale:
Clarification is needed to prevent confusion of VIIRS real time downlink formats with the formats for the current NOAA POES.
Response:
Agree that meaning of LRPT and HRPT will be different for NPOESS. The terms High Data Rate (HDR) and Low Data Rate (LDR) are used in the TRD, and have now been adopted in the VIIRS SRD as well, in lieu of HRPT and LRPT.
------------------------------------------------------------------
ID: 1924 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.5
VIIRS Operational Modes
Recommendation:
Depending on calibration strategy and requirements, a separate mode for calibration may not be necessary. What is the intention here. See SBRS - GTE - 23 comment for recommendation.
Rationale:
Functional requirement versus design clarification.
Response:
Agree. SRD language will be modified to make a separate calibration mode optional.
------------------------------------------------------------------
ID: 1926 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.1.6.3
On-orbit Operational Concept
Recommendation:
Refers to automated switching of modes, and pre-programmed actions. Wording implies that VIIRS itself must meet these requirements, when in fact, programs for mission and autonomous modes may be stored in the spacecraft computer and not within the instrument itself.
Rationale:
Understanding of pre-defined System Architecture Baseline, and implications on instrument.
Response:
Sensor modes have been revised. The sensor is in normal operational mode when the spacecraft is in autonomous mode. Also, note the following revised sensor maintainability requirements:
SRDX3.2.5.1.2-5
For instances of on orbit failure of a sensor suite component, the sensor suite shall place itself into safe mode to await further commands by the spacecraft.
SRDX3.2.5.1.2-6
The contractor shall perform failure analysis to determine failures for which automatic switchover to redundant components is appropriate.
------------------------------------------------------------------
ID: 1928 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1, (new)
Primary EDRs
Recommendation:
Allocation of EDRs. What visibility into the allocation process will be provided to the VIIRS contractors, either pre-proposal or following. Some EDRs allocated to VIIRS now are new, relative to Phase 0 activities. Some EDR definitions have been modified. Clarification of this process would be helpful to the proposal activity.
Rationale:
Understanding of requirements and the rationale for allocation to Instrument Suites.
Response:
The allocation of EDRs to the various sensor suites has been accomplished primarily as a government internal activity. However, the results of the Phase 0 activities were utilized to support the allocation. Also, the current ATSP contractors have reviewed the proposed allocation and provided inputs. The entire contractor community is now invited to comment on the EDR allocation, like any other part of the RFP package.
------------------------------------------------------------------
ID: 1929 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1-3, (new)
Recommendation:
This requirements makes the VIIRS contractor responsible for meeting EDR thresholds, even though data may be required from non-VIIRS or other sources. Saying this cannot make it so. This is a system problem, requiring cooperation of primes and contractors for other Instrument Suites. The VIIRS contractor can attempt to negotiate agreements on non-VIIRS instrument requirements, or other system capabilities, but has no authority to guarantee performance in this case. Review of this requirement is requested by the Government.
Rationale:
Responsibility without authority is a recipe for failure.
Response:
As stated in VSRD 3.2.1.1.1.1-2, the VIIRS contractor is responsible for informing the government of any and all data required from other sensor suites. The government will then determine if the requirements already binding upon the pertinent non-VIIRS contractor(s) are adequate to ensure that the data required by the VIIRS contractor will be available. If not, the government will either (a) negotiate with the non-VIIRS contractor(s) to modify their requirements to ensure that the data required by the VIIRS contractor will be available, or (b) negotiate with both the VIIRS and non-VIIRS contractors to modify the requirements of both sensor suites to ensure that data adequate to meet VIIRS primary EDR thresholds will be available from the non-VIIRS contractor(s).
The intent of VSRD 3.2.1.1.1.1-3 is to hold the VIIRS contractor responsible for the VIIRS primary EDRs, whether or not data are required from another sensor suite. It is presumed that via the negotiation process described above a set of requirements for all the sensor suites will ultimately be evolved which will satisfy both the supply and demand requirements for data for each sensor suite. The VIIRS contractor will of course not be liable to the government if a VIIRS EDR requirement is not met as a result of a failure to perform by a non-VIIRS contractor. The VIIRS SRD language has been modified to make this clear.
------------------------------------------------------------------
ID: 1930 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.1-2
Data from Non-VIIRS Sensors
Recommendation:
The DRFP requires that the VIIRS contractor shall identify the data content, quality and timeliness required from other sensors. How is this knowledge to be acquired?
Rationale:
It would be difficult, if not impossible, to determine what capabilities other sensors might or might not have, especially during development.
Response:
Knowledge of the data required from other sensors is acquired in the process of developing an overall sensor design and algorithm solution to the problem of generating the required EDRs. Minimizing reliance on data from other sensor suites should be a factor in determining the optimal overall design solution for any given sensor suite. The process by which requirements on different sensor suites will be balanced to ensure that each suite receives the data needed from other suites is described in the response to comment ID 1929.
------------------------------------------------------------------
ID: 1804 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.2.1-1
NPOESS IPDS
Recommendation:
The NPOESS IPDS has not been defined yet. The sensor contractors cannot develop a sensor suite which can be tested by the IPDS without first knowing the functional and physical configuration of the IPDS. Output formats and media are not defined. This could be a major problem for the developers and the government if the IPDS is not identified, quantified, and publicized very soon.
Rationale:
N/A
Response:
There is no intent to test the sensor suite using the IDPS under the VIIRS contract. The VIIRS contractor is, however, responsible for validating performance from photons into the sensor to EDRs out of the system. This will be accomplished by analysis, modeling, and simulation using non-operational or scientific algorithms for the processing of RDRs into EDRs. The language in the cited paragraph has been modified to make this clear.
------------------------------------------------------------------
ID: 1805 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.2.1-1
IPDS
Recommendation:
Will the IPDS conform to the DII COE standards?
Rationale:
N/A
Response:
The Interface Data Processor Segment (IDPS) is not the responsibility of the sensor contractor. The government is considering the DII COE standards.
------------------------------------------------------------------
ID: 1932 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.2.1-1, 3.2.1.1.1.2.1-2, (new)
Recommendation:
VIIRS contractor must validate EDR requirements from photons in to EDRs out of the NPOESS IDPS. This requires significant knowledge of spacecraft systems, communication subsystems, IDPS characteristics and performance. In addition, as noted in SBRS - GTE - 27, it may include reference to non-VIIRS sensor data. To do the complete analysis implies understanding of 3 spacecraft/communications systems concepts, 2 IDPS concepts, and possibly 2 or more non-VIIRS sensor suites, representing the multiple contractors in each area. This is a potential for at least 12 combinations of requirements allocations for the purpose of analysis, modeling, or simulation. It will be very expensive and time consuming, as well as extremely risky to accomplish this as we interpret the RFP. Is this really how the Government wants this program to be prosecuted?
Since IDPS operational algorithms are to be redeveloped by the IDPS contractor, and may have different uncertainties and characteristics, should the VIIRS contractor's analyses, modeling and simulation assume characteristics of the Research Algorithms and Code only, or should it be done after discussion/negotiation with the IDPS contractors regarding his implementations and algorithms?
Rationale:
Clarification of the real intent of the RFP.
Response:
The VIIRS contractor's requirements validation analyses will be based only on his own research algorithms. This decouples the analysis from the IDPS implementation and level of performance, and from the spacecraft/communications concept. (However, note that the research algorithms must be convertible into operational algorithms and code that can meet the data availability requirements, per VSRD 3.2.1.1.5.4. The VIIRS contractor must therefore make a reasonable allocation of the EDR timeliness requirement to the time available for data processing as opposed to data routing and communications.)
Also, the VIIRS contractor's requirements validation analyses will be based only on a single set of performance requirements per sensor suite for any sensor suites from which data are required. This decouples the analysis from the actual capabilities of the other sensor suites, either before or after downselect.
------------------------------------------------------------------
ID: 1933 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.2.2-3
Validation of Algorithms
Recommendation:
Requires verification that EDR requirements are met for "any value of the geophysical parameter within the specified measurement range." It is assumed that this can be done by analytical methods and deductive logic from limited test cases, and that it does not require an actual demonstration for each possible value of geophysical parameter.
Rationale:
Understanding of requirements.
Response:
The assumption within the recommendation is correct. (Note that performance verification requirements have been revised and consolidated in Section 4. QUALITY ASSURANCE AND TESTING PROVISIONS.)
------------------------------------------------------------------
ID: 1934 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.1.2.5 1
EDR Requirements Applying Under Daytime Conditions Only
Recommendation:
Delete Albedo (surface), Normalized Differential Vegetative Index, Ocean Color/Chlorophyll from the list. The text currently reads:
"Requirements for the following EDRs...should be fully or partially met under non daytime conditions, if feasible, using sensing data from the VIIRS alone:
Albedo (surface)
Normalized Differential Vegetative Index
Ocean Color/Chlorophyll"
Rationale:
These products are obtained from measurements using the visible solar radiation channels. "Non daytime" usually means no sun, so it is unlikely that partial requirements can be met under those conditions.
Moreover, there is an inconsistency in Appendix D where the EDRs are defined. In particular, on page D 33, Section 40.5.2 Albedo, it states "this EDR is required under daytime only." Also, on page D 45, Section 40.7.6 Ocean Color/Chlorophyll, it states "The EDR is required under clear, daytime conditions only."
Response:
The intent is to make available these and all other EDRs under as broad a range of environmental conditions as possible, even if the EDR is incomplete and/or degraded. Per VSRD 3.2.1.1.1.2.3-2, the contractor must define "daytime" as an in-band radiance level, and this definition may be different for different EDRs. It is expected that the contractor will define daytime for these two EDRs consistently with the minimum illumination conditions for which some useful data can be provided to the users. Also, there is no inconsistency with the Appendix D sections cited, since the SRD clarifications have precedence, per VSRD 3.2.1.1.1.2. No change is recommended.
------------------------------------------------------------------
ID: 1807 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.2.1
RDRs, SDRs, EDRs
Recommendation:
The VIIRS contractor is responsible for RDRs and EDRs, but the IPDS contractor is responsible for the SRDs content and format. This could lead to big problems since the IPDS contractor is sandwiched in-between the VIIRS Contractor's efforts on RDRs and EDRs. Is this true?
Rationale:
N/A
Response:
The VIIRS contractor is responsible for RDRs that can be processed into EDRs that meet requirements, not for the operational EDRs themselves or for operational intermediate data products such as SDRs. See VIIRS SRDV3.2.1.1.1-1 and SRDV3.2.1.1.1-2. The VIIRS contractor is responsible for operational RDRs. The IDPS contractor is responsible for higher level operational products such as SDRs and EDRs. The efforts of the IDPS contractor are in no sense "sandwiched" between the VIIRS contractor efforts on RDRs and EDRs. The VIIRS contractor must demonstrate that EDR requirements can be met based on sensor design and scientific algorithms. The IDPS contractor will have an independent responsibility to develop a physical and functional data processing configuration, including operational code, which allow EDR performance requirements to be met at or possibly above the performance level demonstrated by the VIIRS contractor. (Note that the TSPR contractor has responsibility for the IDPS.)
------------------------------------------------------------------
ID: 1935 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.2.1
SDR Content
Recommendation:
The content of the SDRs is all-important in meeting the EDR requirements in system operation. The VIIRS contractor may recommend the content of operational EDRs. The Government may or may not provide this recommendation to the IDPS contractor. This appears to divorce meeting operational EDRs from the VIIRS EDR verification. What is to happen if VIIRS contractor recommendations are not passed on to the IDPS?
This appears to conflict with SRDV3.2.1.1.1.2.1-1 which requires the VIIRS contractor to validate EDR requirements from photons in to EDRs out of the NPOESS IDPS.
Rationale:
Understanding of obligations and operating environment for VIIRS contractor activities.
Response:
Meeting operational EDRs is intentionally divorced from VIIRS EDR verification. The responsibility of the VIIRS contractor is to verify EDR performance based on his sensor design and on his scientific or research algorithms. The VIIRS contractor does not have responsibility for operational EDR performance.
------------------------------------------------------------------
ID: 1808 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.2.1
RDRs, SDRs, EDRs
Recommendation:
The VIIRS contractor is responsible for RDRs and EDRs, but the IPDS contractor is responsible for the SRDs content and format. This could lead to big problems since the IPDS contractor is sandwiched in-between the VIIRS Contractor's efforts on RDRs and EDRs. Is this true?
Rationale:
Response:
The VIIRS contractor is responsible for RDRs that can be processed into EDRs that meet requirements, not for the operational EDRs themselves or for operational intermediate data products such as SDRs. See VIIRS SRDV3.2.1.1.1-1 and SRDV3.2.1.1.1-2. The VIIRS contractor is responsible for operational RDRs. The IDPS contractor is responsible for higher level operational products such as SDRs and EDRs. The efforts of the IDPS contractor are in no sense "sandwiched" between the VIIRS contractor efforts on RDRs and EDRs. The VIIRS contractor must demonstrate that EDR requirements can be met based on sensor design and scientific algorithms.
The IDPS contractor will have an independent responsibility to develop a physical and functional data processing configuration, including operational code, which allow EDR performance requirements to be met at or possibly above the performance level demonstrated by the VIIRS contractor. (Note that the TSPR contractor has responsibility for the IDPS.)
------------------------------------------------------------------
ID: 1936 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.3
RDR requirements
Recommendation:
The VIIRS contractor shall be responsible for generating operational RDRs. Does this include computer software, documentation, and test results? Does "operational" include all IDPS (DOD, NOAA/NESDIS, and other) sites?
Rationale:
Clarification
Response:
The VIIRS contractor is responsible for generating operational RDRs. The government does not foresee a need to define RDRs differently for different IDPS destination sites as the operational RDR is defined at the output of the sensor.
------------------------------------------------------------------
ID: 1937 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.3.1
RDR Content
Recommendation:
The term "Scan Set" is used but not defined. Please provide definition.
Rationale:
Understanding of requirements.
Response:
The term "scan set" has been deleted.
------------------------------------------------------------------
ID: 1938 Date Recvd: 12/20/96 Status: Open Pending CCB Review
Reference:
VIIRS SRD 3.2.1.1.3.1
RDR Content
Recommendation:
"Data necessary for geolocation of samples" is a component of RDRs. Is this assumed to be all inclusive, or only that relevant to the sensor. Spacecraft orientation is to be appended every 5 minutes. What about spacecraft ephemeris and other system level information required for geolocation. Will the IDPS contractor have separate access to system information or should everything be supplied via the RDR?
Rationale:
Clarification of requirements.
Response:
The intent is that all spacecraft related data necessary for geolocation be appended every 5 minutes, and the document has been modified to capture this intent. All data necessary for generation of EDRs and intermediate-level data products are to be provided to the IDPS via RDRs.
------------------------------------------------------------------
ID: 1939 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.5.1-2
Algorithms
Recommendation:
Indicates VIIRS contractor "shall adopt or adapt...or develop new algorithms for all intermediate level data products used to generate the primary EDRs, such as SDRs and..." In the course of verifying the end to end performance, photons in to [Research] Algorithms output, the conversion to SDRs may not need to be done. Given that the IDPS may not base its SDRs on the VIIRS contractor SDRs, what is the value added in requiring the VIIRS contractor to develop SDR algorithms which may not be eventually utilized?
Rationale:
Understanding of program strategy and required activities for VIIRS contractor.
Response:
Even if the SDR algorithms developed by the VIIRS contractor are not adopted and utilized "as is" by the TSPR (IDPS) contractor for the operational SDRs, these algorithms will provide a useful basis or point of departure for the development of the operational SDR algorithms. From this perspective, the value added in requiring the development of non-operational SDR algorithms by the VIIRS contractor lies in the provision of an adequate baseline to the TSPR contractor which will save operational algorithm development time and provide a benchmark for further performance improvement.
Also, it is anticipated that the sensor requirements documents generated by the contractor will specify performance at the SDR level, not at the EDR level. Therefore, the VIIRS contractor will need the non-operational SDR algorithms to verify that his own performance specifications are met.
------------------------------------------------------------------
ID: 1695 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.5.2.2
Algorithm Performance Baseline
Recommendation:
In the parenthetical at the end of this section which reads: [Subsections containing current operational algorithms and algorithmic accuracy and precision per EDR are TBD.], the concluding TBD appears to be a typo. Rather than TBD it should read TBS or TBR.
Rationale:
Since the baseline becomes the reference for VIIRS sensor contractor performance, the government should assure a common baseline for all VIIRS sensor contractors.
Response:
Agree. TBD has been changed to TBR.
------------------------------------------------------------------
ID: 1940 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.5.3-1
Performance Validation
Recommendation:
The constractor. Should be contractor.
Rationale:
misspelled.
Response:
Accept.
------------------------------------------------------------------
ID: 1942 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.5.4-1
Convertibility to Operational Code
Recommendation:
Requires that VIIRS scientific code be convertible to operational code to meet "Data Availability" requirements in 3.2.1.2. Requirements for this operational environment are undefined, even though certain high level performance requirements are identified in 3.2.1.2. What other requirements differentiate between the converted science code and the real operational code? Is this requirement intended as a backup or early version of the algorithms forming a phased delivery of capability? If either is the case, will the VIIRS contractor be required to support operations if the science code is actually converted to run in the operational environment?
Rationale:
Understanding of program strategy and required activities for VIIRS contractor.
Response:
See response to comment ID 1941. The sensor contractor's responsibilities are limited to validating that EDR requirements are met with his sensor design and scientific algorithm, and to validating in a manner that is TBR that his scientific algorithm is not so complex that its implementation will stress or exceed the available time for EDR delivery in the operational environment.
------------------------------------------------------------------
ID: 1941 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.1.5.4-1
Convertibility to Operational Code
Recommendation:
"The scientific algorithms delivered by the VIIRS contractor shall be converted into operational code that can meet the NPOESS "Data Availability" requirements specified in sec 3.2.1.2. Suggest more definition, how will this be demonstrated? (e.g. test plans, test results, code and operations walk-through)
Rationale:
Unclear definition
Response:
The intent of this requirement is to preclude a scientific algorithm that is so computationally intensive that the run time of any operational code implementing the algorithm will stress or exceed the EDR availability timeline. The means for validation of this requirement is TBR, and the SRD has been modified to reflect this.
------------------------------------------------------------------
ID: 1944 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.25.2
Recommendation:
The IPO will provide scene-derived spectral radiances given contractor-specified band passes and IPO-specified forward models. Any retrieval algorithm (inverse models) not wholly compatible with the forward models will yield erroneous results. These errors could dominate over instrument errors and fundamental errors in the retrieval algorithm.
Rationale:
There is not general community consensus over many aspects of a scene description. For example, cloud definitions can vary widely. Subtleties in multiple scattering for atmospheric correction over the ocean, atmospheric correction over Case 2 waters, the selection of Lambertian or anisotropic bi-directional reflectance distribution models for the land surface, choice of surface emissivities, and tens to hundreds of other attributes all affect the retrieval.
The process of IPO provided scene radiances will drive the contractors towards selecting retrieval algorithms optimized for the simplifications in the scene radiances, not refined toward the actual Earth. The OATS-provided algorithms may become of little practical use if they are not defined consistently with the IPO simulations, as they will yield incorrect solutions. The end result may be to negate the benefit of using simulations to test the instrument/algorithm end-to-end EDR system solution.
There are two possible solutions: (1) accept that scene simplifications are inevitable, and permit the retrieval algorithms to be simplified to be inverses of the forward models -- in this case, the testbedding process does not permit solutions to be optimized for the real world, and the instrument and algorithm designs cannot be refined to meet subtle physical effects; (2) facilitate the joint development (involving the IPO, the contractor, and the OATs) of consistent scene simulations, retrieval algorithms, and sensor designs -- as necessary withhold subtleties of the EDR solution from the contractor within a predefined set of blind tests.
Response:
The IPO will model all first order effects as well as most of the major second order effects associated with the radiative transport portion of standard dataset creation, as appropriate for each sensor type. In some cases selected third order effects may be included also. Contractors are encouraged to submit to the IPO lists of the effects they consider to be first and second order for their particular sensor / algorithm combination(s). These inputs will be reviewed by the IPO and by the relevant OATS group and changes in the IPO modeling strategy may result. However, joint development of scene simulations tuned to specific algorithms or radiative inversions will make it impossible to test EDR performance across competing designs, and this will not take place.
------------------------------------------------------------------
ID: 1943 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.4
Standard Earth Scenes
Recommendation:
What information will be available for the standard earth scenes, such as simulation uncertainties, models used, etc.? Why was the number of bands, 10, identified as a soft maximum, when the notional sensor provided by the program has at least 13 bands (2 visible, short wave, mid wave, long wave, split long wave, 6 ocean color). How will the complexity of geophysical parameters in the atmosphere, and their conversion to radiances at the sensor be modeled?
Rationale:
Understanding of program requirements and assumptions.
Response:
1. The IPO will provide complete ground truth related to each of the standard datasets which are made available to the contractors, and none of the related information for those scenes retained by the IPO for use in PDR evaluation. In addition, the methodology, models, and underlying data sets for standard scene development will be described to the contractors to the extent that the IPO and the OATS determine is beneficial to the sensor / algorithm design process.
2. As noted in VIIRS SRD Section 3.2.1.4, the IPO will not place arbitrary limits on the number of bands for which standard datasets are created; however, the intent is to provide only those bands which are specifically required in the algorithm for one or more of the EDRs assigned to the VIIRS. This is also the intent for the other sensors. In other words, standard datasets are not to be provided to the contractor as algorithm development aids, but to help verify EDR performance for the combined sensor and algorithm. Algorithm development and comparison activities conducted internally by the contractor before settling on a set of bands for the sensor design can be performed with much more limited datasets. The specific limit of 10 was chosen as a notional order of magnitude, i.e. the IPO expects that VIIRS will contain of order 10 bands (rather than 50 for example). By contrast, the notional VIIRS has a specific set of bands (13), which was chosen based on Phase 0 studies, and was intended to aid in developing a conservative POE for VIIRS.
------------------------------------------------------------------
ID: 1829 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.1.4
Recommendation:
Will some of the "standard scenes" be made available to the contractors before the proposal? Will the "standard scenes" be used to test the sensor performance against all 26 EDRs required for the VIIRS?
Rationale:
Response:
Standard datasets will be provided to contractors in the specific bands associated with their sensor designs and thus will not be available until sensor bands are provided to the IPO, and datasets have been tailored to those bands. All standard datasets for any given sensor will be delivered to the contractor at least one year prior to PDR . Standard datasets may be used to test some or all of the EDRs required of a given sensor, such as VIIRS, at the discretion of the IPO. Contractors are required to supply science algorithms as well as sensor designs to accomplish EDRs, and thus all EDRs may be tested.
------------------------------------------------------------------
ID: 1826 Date Recvd: 12/20/96 Status: C
Reference:
VIIRS SRD 3.2.4 - Physical Interface Characteristics.
Recommendation:
What are the latest estimates on size, weight and power constraints for VIIRS? Is there a difference in power consumption among the different modes of operations? What are the constraints on placement of apertures?
Rationale:
Response:
Overall constraints on size, weight, power, and data rate will be provided in the SRD. Individual power requirements for the different modes will be TBR. Constraints on placement of apertures will also be TBR.
------------------------------------------------------------------
ID: 1946 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.4.10.3
General Data Bus Requirements
Recommendation:
This section appears to place requirements on the spacecraft bus structure, to which the VIIRS must interface. These requirements should really appear in the spacecraft specification and those applicable to VIIRS in an interface specification, not in the VIIRS specification.
Rationale:
Clarity.
Response:
The VIIRS SRD does contain a subset of the IRD requirements, identically stated, and the government recognizes and accepts this overlap between the two documents. Interface requirements may appear to apply to the spacecraft only, but should provide information essential to the sensor contractor and should be binding on the sensor contractor in the sense that the sensor design must be compatible with the specified aspect of the spacecraft design. If the contractor can identify any requirement in the VIIRS SRD which appears to apply to the spacecraft only and does not impact the sensor design in any way, it is requested that the contractor so inform government.
------------------------------------------------------------------
ID: 1945 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.2.4.9.6
Thermal Control System
Recommendation:
This requirement calls for minimization of heater power requirements. This may cause a design that is sub-optimal from a system perspective. A tradeoff may result in higher orbit energy or peak power just to meet this requirement.. What should be considered is the overall orbit average energy consumption, and, perhaps peak power. Consider rewording of this requirement to reflect either orbit energy and/or peak power.
Rationale:
Definition of most significant system implications.
Response:
Agree. The SRD has been modified to promote a design which is optimal from a system standpoint.
------------------------------------------------------------------
ID: 1947 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD 3.3.9.1
Communications Security
Recommendation:
How does this apply to the VIIRS. Is VIIRS or the spacecraft going to handle encryption or decryption and authentication? This is typically a spacecraft function, not an instrument function. Given that encryption and communications bit errors may affect data quality, how is the VIIRS contractor to factor these into end to end performance verification?
Rationale:
Understanding of requirements.
Response:
See comment #1688.
The sensor contractors are responsible for verification of what is sent from the s/c to them.
------------------------------------------------------------------
ID: 1731 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD Appendix D, Attribute Long Term Stability
Long Term Stability
Recommendation:
Many of the EDRs have a requirement for "long term stability", this requirement is unclear.
Rationale:
This requirement has a broad meaning. It can be interpreted as a sensor requirement, or an algorithm requirement. We define "long term stability" as entire system performance implying a capability to adjust for any long term system or sensor changes.
Response:
Long term stability is unambiguously defined in the TRD as applying to EDRs, and therefore entails lower level requirements on both sensor performance, including the capability to detect temporal changes in sensor performance, and on algorithms. The allocation of the EDR-level long term stability requirement to the sensor and algorithm is left to the sensor contractor.
------------------------------------------------------------------
ID: 1949 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD None
Continuity and/or Transition
Recommendation:
Review of the DRFP has not provided any requirements or discussion of continuity, compatibility, or transition requirements as the DMSP and POES programs evolve into the planned NPOESS system concept. Are there any specific requirements for data continuity, data compatibility, or transition activities that are a part of the VIIRS procurement?
Rationale:
Understanding scope of VIIRS program and its requirements.
Response:
Specific requirements on the sensors which would facilitate data continuity, compatibility and transition activities have not been identified at this time. However, one of the objectives of the OATs involvement is to ensure these issues are considered as the sensor design evolves.
------------------------------------------------------------------
ID: 1678 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD & IRD 3.2.4.9.4.2-1 IRD, pg. 18, 3.2.3.4.2
Thermal Uncertainty Margins
Recommendation:
The SRD & IRD call out a subset of margins from MIL-STD-1540C. MIL-STD-1540C calls out thermal uncertainty and heat-load margins to be used for different control techniques and the various phases of the development program. For passive cryogenic systems, the thermal uncertainty margins are reduced, since carrying a large margin of 11°C drives the design away from the optimal solution. Since there may be different requirements within the instrument design, the margins should not be dictated with such a narrow description. Recommend that the SRD replace the calling out of margins with direct references to the specification MIL-STD-1540C so that all cases (especially for cryogenic systems) are covered. Change paragraph to read: "Thermal uncertainty margins used during the design and validation shall be per MIL-STD-1540C."
Rationale:
Since MIL-STD-1540C calls out thermal uncertainty and heat-load margins to be used for different control techniques and various phases of a development program, direct reference covers all of these circumstances.
Response:
Agree. The first 2 sentence in paragraph 3.2.3.4.2 will be changed to read "Thermal uncertainty margins used during the design and validation shall be applied per MIL-STD-1540C. If heaters are used, a 25% heater control authority can be used in place of the thermal uncertainty margin."
------------------------------------------------------------------
ID: 1803 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD Appendix D 40.2.3.1
Other EDR Requirements
Recommendation:
If the VIIRS is developed against one set of requirements to generate specific EDRs, then how can other sensor suites levy requirements for VIIRS data they need for their EDRs, if the VIIRS contractor is unaware of their need. The VIIRS might not be generated in the configuration required by the other sensor suites.
Rationale:
N/A
Response:
Each sensor suite contractor is required to identify the content, quality, and timeliness of any data required from another sensor suite. The government will then determine whether or not a requirement to provide such data will be imposed on the sensor vendors for the other suite. This issue is addressed in Section 3.2.1.1.1.1 of the VIIRS SRD. No action required.
------------------------------------------------------------------
ID: 1682 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD Appendix D 40.6.4-10
40.6.4 Vegetation Index/Surface Type
Recommendation:
Does the 'Correct Typing Probability' refer to each of the types individually or to the aggregate over all types?
Rationale:
Clarification of requirements.
Response:
Correct typing probability refers to each type individually. The probability of correct typing is defined as the probability that a horizontal cell or area reported as being of type x is in fact of type x, where x is any of the specified possible types. (This definition should be incorporated in our standard list. It appears in essentially the same form in the TRD, Sec. 40.2.3.2.1.2, Cloud Type.) Note that this probability is calculated by dividing the number of correct type x reports by the number of type x reports for a large number of typed horizontal cells or areas. A related probability is the probability that an area in fact of type x is reported as being of type x. The latter probability is calculated by dividing the number of correct type x reports by the number of areas in fact of type x. This latter probability is not recommended because the user generally does not have access to the truth. With the recommended definition of probability of correct typing, and a requirement that this probability be greater than 80%, for example, the user can be confident that for any large set of type x reports, 80% or more of these reports will be correct, for any type x.
------------------------------------------------------------------
ID: 1703 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.2.5.1
Reliability
Recommendation:
The conditions for the reliability calculations need to be clarified.
Rationale:
Clarification
Response:
See comment #1762.
------------------------------------------------------------------
ID: 1704 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.2.5.1.2-6
Redundancy/Single Point Failures
Recommendation:
Redundancy shall be provided where practical to eliminate critical single point failures in the sensors and to assure the reliability requirements are met.
Rationale:
Certain areas may not be able to have redundancy, all prior Single-Point-Failure clauses included the "where practical" qualifier. Also, no availability requirements have been specified.
Response:
Accept. SRDs will be revised as recommended. 3.2.5.1.2-6 Deleted.
------------------------------------------------------------------
ID: 1705 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.2.5.1.2-7
Redundancy / Automatic Switchover (SRDX3.2.5.1.2-7, -8)
Recommendation:
It is recommended that all redundancy switchovers be controlled by the ground station to assure no external problem caused the postulated failure (such as a high voltage on the +28 volt bus, or a vehicle thermal problem).
Rationale:
While an automatic switchover capability may be included in the design, it may not be desirable. Automatically implementing the redundant option when the external problem has not been corrected may cause the redundant option to also fail.
Response:
See response to comment #1621.
------------------------------------------------------------------
ID: 1649 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.3.12.10
Electronic Components
Recommendation:
Revise to read: 'Electronic parts for sensor applications shall use MIL-STD 1546B and MIL-STD 1547B as guidelines. GSFC PPL-21 may be used as a reference.
Rationale:
Using MIL-STD 1546 and Mil-STD 1547 as guidelines is consistent with the new government philosophy of procurements. Under this methodology a PMPCB (Parts, Materials and Processes Control Board) develops a part procurement and screening philosophy which will insure only Space Qualified Parts, Materials and Processes are used. See 5.1 and 5.2 of MIL-STD 1546.
Response:
This requirement rewritten.
SRDX3.3.1.2-1
Parts for space usage shall be chosen to meet the reliability and operational service life requirements. (use MIL-STD-1547B and the Preferred Parts List PPL-21, Goddard Space Flight Center, as guides).
SRD3.3.1.2-2
Parts shall be selected in accordance with the contractor's Parts Management Plan.
SRDX3.3.1.2-3
The contractor shall be able to demonstrate via design and test or analysis that all parts meet the reliability and operational service life requirements.
------------------------------------------------------------------
ID: 1679 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.3.12.7.4 and 3.3.12.7.5.4 CMIS SRD, pg.50, 3.3.12.7.4 and 3.3.12.7.5.4
Uncompensated Momentum and Angular Momentum
Recommendation:
The SRDs have TBD for the uncompensated momentum and angular momentum maximum values. These values should be TBR rather than TBD.
Rationale:
Agreement on maximum values is needed by those who have responsibility for both sides of the affected interfaces.
Response:
Agree. Wording changed to have the uncompensated momentum values defined and agreed to in an ICD (IRD paragraph 3.1.8.4). In addition, we have added limits for the maximum transmitted torque.
------------------------------------------------------------------
ID: 1650 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.3.15.1.2.5
Device Cleanliness
Recommendation:
Replace: '...MIL-STD 1246B.' with '...MIL-STD 1246C.'
Rationale:
2.1: Government Documents, STANDARDS:, Military lists .'MIL-STD 1246C', not .'MIL-STD 1246B'
Response:
Correct reference shown in TRD. Replace: '...MIL-STD 1246B.' with '...MIL-STD 1246C.'in SRDs.
------------------------------------------------------------------
ID: 1648 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 3.3.4-Workmanship
Workmanship
Recommendation:
ISO-9001 and MIL-STD 1586 are called out as examples of Government approved Quality Control Plans. Neither of these specifications address Workmanship. (MIL-STD 1586 is canceled by Notice 1 dated 31 May 1995). A relevant example of a Government approved Quality Control Plan covering Workmanship should be cited or the reference example dropped.
Rationale:
Workmanship requirements should have a reference document which can be used for guidance to ensure consistent requirements among sensor contractors.
Response:
Accept. Reference deleted.
------------------------------------------------------------------
ID: 1706 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD 4.2.1.2
Inspections and Tests of Computer Software
Recommendation:
Some of the subparagraphs appear to be out of place and ,therefore, confusing. Furthermore, the sections on Integrated Sensor Test particularly the list of required tests appear to be overly stringent.
Rationale:
Clarification.
Response:
TRD paragraph is 4.2.1.2 Inspections and Tests of Ground Equipment and Computer Software. SRDs will be changed to the correct title for this paragraph. Additional information needs to be provided specifying which tests are overly stringent.
------------------------------------------------------------------
ID: 1675 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD Figure 3-1, Specification Tree
Flowdown of Requirements to/from SRD
Recommendation:
The SRDs in the figure are not tied to higher or lower level documents. Please clarify the relationship of the SRD to those documents.
Rationale:
Clarification.
Response:
Specification Tree revised.
------------------------------------------------------------------
ID: 1677 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD Figure 3-10; CMIS/SRD p 35, Figure 3-4; Maximum PLF Inner Temperatures
Units of Ordinate on Graph
Recommendation:
What are the units of temperature for the ordinate of the graph?
Rationale:
Clarification.
Response:
Units are deg F. Corrections will be made.
------------------------------------------------------------------
ID: 1676 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD VIIRS p 40, CMIS p 33, SRDX3.2.5.1.1-1, Operational Service Life
Operational Service Life
Recommendation:
Does the Operational Service Life include either ground testing or storage?
Rationale:
Clarification.
Response:
Yes. SRD will be revised to read: " The design service life of the sensor shall be at least 15 years. This includes the time allowed for test, storage, prelaunch checkout, launch and injection, on-orbit, recovery, and contingency."
The following requirement has also been added: The sensor storage life shall be 7 years. This allows for storage of one year prior to integration on the spacecraft.
------------------------------------------------------------------
ID: 1692 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD, CRIS SRD 3.2.1.1.2; CMIS SRD, p14, 3.2.1.1.2.1; CrIS SRD, p15, 3.2.1.1.2.1
SDR Definition
Recommendation:
In the VIIRS SRD no specific definition is given for SDRs implying that the definition given in the TRD Appendix A 10.1 Sensor Data Records (SDRs) and repeated in std-def.doc applies). In the CMIS SRD 3.2.1.1.2.1 it states: 'The Sensor Data Record (SDR) is defined as TBD' In the CrIS SRD 3.2.1.1.2.1 a definition of the SDR is given that is somewhat different from that given in the TRD Appendix A 10.1 Sensor Data Records (SDRs) and repeated in std-def.doc. Is the definition of SDRs 1) as defined in the TRD Appendix A 10.1 Sensor Data Records (SDRs) and repeated in std-def.doc, 2) to be defined by the contractor, or 3) individually assigned by each SRD? Recommend that the definition of SDRs every where be as defined in the TRD Appendix A 10.1 Sensor Data Records (SDRs) and repeated in std-def.doc.
Rationale:
Clear and consistent definition of SDR desired. Such a definition exists in TRD Appendix A 10.1 Sensor Data Records (SDRs) and should be applied everywhere.
Response:
Agree. See #1691.
------------------------------------------------------------------
ID: 1693 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD, CRIS SRD 3.2.1.1.2; CMIS SRD, p14, 3.2.1.1.2; CrIS SRD, p15, 3.2.1.1.2
SDR Requirements
Recommendation:
In the VIIRS SRD the IDPS has the responsibility for providing operational SDRs. In the CMIS SRD the responsibility for providing operational SDRs is not specifically stated implying that the sensor contractor has responsibility. In the CrIS SRD 3.2.1.1.2.1 it states: 'Sensor data records shall be provided' thereby assigning responsibility to the sensor contractor. Is the responsibility for providing operational SDRs 1) assigned to the IDPS, 2) assigned to the sensor contractor, or 3) individually assigned by each SRD? Recommend that responsibility for providing operational SDRs be everywhere assigned to the IDPS contractor, but that responsibility for algorithms to generate SDRs from RDRs be everywhere assigned to the sensor contractor.
Rationale:
Clear and consistent definition of SDR responsibility desired. The IDPS contractor is most appropriate for working the operational user interface, but the sensor contractor is most appropriate for providing the algorithms to generate SDRs from RDRs.
Response:
Accept. Referenced inconsistencies have been resolved. The sensor contractor is responsible for operational RDR code (output from the sensor) and the science algorithms to process RDRs into EDRs/SRDs. The IDPS contractor is responsible for the operational EDR, SDR/TDR code. (As the program is currently concieved, the IDPS contractor is the System contractor.)
------------------------------------------------------------------
ID: 1691 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD, CRIS SRD 3.2.1.1.3; CMIS SRD, p 15, 3.2.1.1.4.1; CrIS SRD, p 16 3.2.1.1.4.1
RDR Definition
Recommendation:
In the VIIRS SRD no definition paragraph exists, implying that the definition given in the TRD Appendix A 10.1 Raw Data Records (RDRs) and repeated in std-def.doc applies. In the CMIS SRD 3.2.1.1.4.1 it states: 'The RDR is defined as TBD'. In the CrIS SRD 3.2.1.1.4.1 it states: 'The RDR is defined as TBS'
Is the definition of RDRs: 1) as defined in the TRD Appendix A 10.1 Raw Data Records (RDRs) and repeated in std-def.doc, 2) to be defined by the contractor, or 3) to be specified by the government? Recommend that the definition of RDRs be everywhere as defined in the TRD Appendix A 10.1 Raw Data Records (RDRs) and repeated in std-def.doc,
Rationale:
Clear and consistent definition of RDR desired. Such a definition exists in TRD Appendix A 10.1 Raw Data Records (RDRs) and should be applied everywhere.
Response:
Agree with recommendation and inconsistencies in the text have been corrected to agree with most current glossary defintions. The SRD glossary is identical to the TRD glossary.
------------------------------------------------------------------
ID: 1702 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD, IRD 2.0
Applicable Documents - Tailoring
Recommendation:
There is a significant benefit to be derived from tailoring applicable documents to the unique characteristics of the specific application so that the most cost-effective approach is specified. Some of the documents listed have the expectation of tailoring built into the document while others do not. Recommend that the tailoring process be part of the activity after sensor contract award and prior to SRR.
Rationale:
The sensor design and call for improvements costing at PDR should be based on tailored applicable documents so that the most cost-effective approach is specified.
Response:
The specified government standards are the minimum set deemed necessary by the IPO. However, the offeror may recommend tailoring these documents, or substitute equivalent commercial U.S. or International standards, as appropriate, for his sensor, as long as the supporting justification is included in his proposal. This flexibility is provided under Section L, para 3.2.2.3.1 and 3.2.2.3.3. The IMP/IMS Instructions also provide further guidance on tailoring standards in para 3.0 (5) . The provision for tailoring documents has also been added to SRD para 2.1.
------------------------------------------------------------------
ID: 1647 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CMIS SRD, IRD 2.3: Reference Documents, 3.2.4.3.3.6.1-3-Electrical Connectors
Applicable Documents
Recommendation:
CMIS SRD-Page 4 -2.3: Reference Documents, STANDARDS CMIS SRD- Page-50-3.3.12.7-1-Moving Mechanical Assemblies
IRD-Page 4-2.1 Compliance Documents
IRD Pages 4 & 5-2.2 Reference Documents IRD-Page 16-3.2.2.6.1 Electrical Connectors
Three of the listed specifications have been canceled and should be deleted. DOD-W-83575 is canceled by Notice 2 dated 01 June 1996. MIL-A-83577B is canceled by Notice 1 dated 31 May 1996. MIL-STD 490A is canceled by Notice 1 dated 31 August 1995. (SRDs only)
Rationale:
Canceled specifications are removed from the standard reference databases and can only be accessed via a special database or paper-copy library which increases cost.
Response:
See comment # 2176.
------------------------------------------------------------------
ID: 1726 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CRIS SRD 3.2.5.1.2-7 and 8
Reliability/Redundancy Management
Recommendation:
(1) What is meant by "A capability for automatic switchover to a backup component and/or circuit shall be provided. . ." Is this a requirement for the payload to perform autonomous redundancy management independent of the spacecraft and/or ground segment?
(2) What is the relationship between this requirement and the autonomous operations capability requirement?
Rationale:
Payload complexity driver
Response:
See #1621.
------------------------------------------------------------------
ID: 1724 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS SRD, CRIS SRD 3.3.9.1-1, 2, 4, 5, 6, 7
Communications Security (COMSEC)
Recommendation:
(1) Can it be assumed that the encryption and authentication will be allocated to the spacecraft command and data handling subsystem?(2) Is encryption intended to be commandable?
Rationale:
(1) Does the sensor need to incorporate the capability to encrypt and authenticate data or is this a spacecraft command and data handling subsystem function?(2) Does the sensor and/or spacecraft need to be able to have encryption that is commandable on/off or is their select data that is encrypted?
Response:
See comment #1688.
------------------------------------------------------------------
ID: 1730 Date Recvd: 12/20/96 Status: Closed
Reference:
VIIRS, CRIS SRD Appendix B
Survivability Requirements
Recommendation:
When will Appendix B available?
Rationale:
Response:
Flow down of the classified requirements in Appendix B will not be made available until after the contract is awarded.
------------------------------------------------------------------
ID: 1530 Date Recvd: 12/19/96 Status: Closed
Reference:
WBS PWBS Tree and Dictionary
Creation of a CWBS using the PWBS Tree and Dictionary
Recommendation:
The numbering system for the PWBS Tree and Dictionary is different, e.g., on the Tree PWBS Element 1.1 is Sensor Payload whereas in the Dictionary Payload is Element 1.2.3. Recommend that the Tree be changed to be in agreement with the Dictionary. However, this will result in a discontinuous WBS structure for the payload contractors, e.g., Payload is at level 3 but System Engineering/Program Management is at level 2 (Element 1.5), and there is no PWBS element allocated for the Payload contract.
Rationale:
If the objective is to segregate program costs according to MIL-STD-881B, wherein all product costs are accumulated in one PWBS level 2 element and all Systems Engineering/Program Management from any contractor or government costs are in another single level 2 element, changing the Tree to agree with the Dictionary is the logical approach.
Response:
The Dictionary will be modified to reflect the PWBS.
------------------------------------------------------------------