RFI questions updated - CCOR Team Responses.pdf

The following are responses to questions received from the “Pre-solicitation notice” for the Space Weather Next L1 Series Coronagraph. Where changes were made to the RFP because of the questions received, the final RFP documents will reflect those changes. The Final RFP will be posted at a later date.

1) Question: Can the Government define Level 1b data product in CDRL OPS-5?

Response: Fully de-commutated and fully calibrated space weather data file

• in final units (typically scientific units, but sometimes sensor)

• in a standard fixed coordinate frame (e.g., ECI, Heliographic Inertial (HGI))

• at full resolution (per telemetered data)

• with all supplemental information to be used in subsequent processing appended.

2) Question: Can the Government define HAP in CSPEC-19 and CSPEC-20?

Response: The Spec will be updated to define the HAP (High Availability Products), for the Coronagraph, which is the “coronal white light imagery”. Here is a brief description of HAP:

High Availability Products (HAPs) are four key space-based observations (including coronal white light imagery) that must be produced continuously by the L1 mission.

The availability requirements for the Coronagraph are based on the mission HAP requirements.

3) General comment: multiple specifications reference “HAP data”, no definition of “HAP” is provided.

Response: See response to Question #2.

4) Reference: CSPEC92:

Comment: The Coronagraph instrument shall limit any change in operational power current at any time (including initial power turn-on) to no more than 0.2A/μs. (TBR).

This is not typically how we see transient specifications done. Typically, CSPEC495 is what we would see.

Response: Further review will be conducted by the project team prior to the release of the final RFP. If changes are required, it will be made in the final RFP documents.

5) Reference: CSPEC112:

Comment: The Coronagraph shall utilize no more than three analog signals to monitor critical temperature points when the Coronagraph is powered off.

Rationale: Common best practices for on-orbit operations deems that the Spacecraft will be able to monitor health and safety of the instrument if the instrument is in any configuration other than the normal operational configuration, e.g., safe or survival mode. Six signals are also deemed reasonable given the complexity of the instrument.

Question: The text of the specification says 3 analog signals, but the rationale (and other places in the spec) say 6 analog signals. Believe the 3 is a typo.

Response: That is correct, “three” is an error; the specification will be updated to reflect six analog signals as well as 12 (TBR) digital telemetry points.

6) Comment: CSPEC130: The Coronagraph shall receive all data from the spacecraft formatted per CCSDS 133.0-B-1 Section 4.1 Protocol Data Unit definition shown in the Command Source Packet Definition Figure 3. Figure 3 is missing.

Response: Figure 3 will be added to the specification.

7) Comment: CSPEC114/137: The Coronagraph Instrument shall interface for data transfer to or from the spacecraft by SpaceWire (ECSS-E-ST-50-12C-rev.1) data bus.

Rationale: SpaceWire is the preferred standard high-rate data interface.

The spacecraft will provide two data signal interface feeds to the Coronagraph Electronics Unit for command and telemetry. The spacecraft will also provide an interface line for a Pulse Per Second

(PPS)

Question: 06a - The SpaceWire standard provides a mechanism for distributing PPS without an additional signal line. Is this not planned to be used, and instead a separate physical input will be used?

Question: 06b - Clarification request: does “two data signal interface feeds” mean one SpaceWire link with 1 receive & 1 transmit, or does it mean there will be two independent (primary/redundant) SpaceWire links?

Question: 06c - CSPEC137 seems redundant with CSPEC114

Responses:

06a: The requirement text is correct. SpW PPS might be used; this will be determined in

ICD

06b: Feed is a full parallel SpW Bus.

06c: Text in Sec 4.6.2, separate from CSPEC114 itself, only explains that the spacecraft will provide a separate PPS line. CSPEC137 requires that COR receive PPS.

8) Comment: CSPEC123: The Coronagraph shall set the Telemetry Source Packet Time Code per CCSDS 301.B-4 Time Code Formats, Day Segmented format in the Time Code Format Figure 2.

Question: Is there a requirement on how accurate this timetag needs to be?

Response: Yes, CSPEC137 explains that the spacecraft will maintain Spacecraft Time correlation to within ±0.95 sec of UTC.

9) Comment: CSPEC134: The Coronagraph shall receive Command Source Packet with Secondary Header Flag set to the value 0.

Rationale: CCSDS 133.0-B-1 Space Packet Protocol, Blue Book, Issue 1, September 2003

Question: Would it be possible to add a secondary header for commands? Our legacy code uses this field.

It would be possible to modify the code to accommodate this, but it would require additional labor.

Response: This will be determined during the performance of the contract.

10) Reference: CSPEC140:

Comment: The Coronagraph shall receive from the spacecraft a time code message on the data line as defined in Spacecraft Time Message Packet Figure 4. The time code message is the time applicable to receipt of the 1 PPS.

Questions: (1) Clarification request: Do we copy the full STM (including subseconds) to our internal timekeeping at this time, or clear the subseconds to 0? Our experience has been that the STM is typically in seconds, and the PPS comes at subseconds = 0.

(2) Clarification request: Are there cases where we should reject STMs?

(3) Clarification request: is there a requirement against maximum time drift for a maximum PPS outage? This is something we are used to seeing

Response: This will be worked in the ICD development phase/process.

11) Reference: CSPEC160:

Comment: Instrument configuration data (e.g., Table Loads or Configuration Parameters) shall be reprogrammable during integration and test phases and on-orbit without computer restart.

Rationale: Common best practices dictate this capability to avoid unnecessary power cycles of the instrument.

Question: Clarification request: please define “without computer restart”. Is an instrument processor reset (see CSPEC150) considering a “restart”? The rationale implies the only desire is to avoid power cycles, a processor reset would not require a power cycle. There are certain parameters that should not be updated while the software is actively running and would prefer a clean reset to update them.

Response: An instrument processor reset is not a restart in this context. To clarify, the spec was reworded to say, “…without computer power cycle restart.”

12) Comment: CSPEC164: Instrument configuration data (e.g., Table Loads or Configuration Parameters) shall be referenced such that data can be loaded and dumped by the ground without reference to memory address.

Rationale: Common best practices dictate this capability for ease of operation and to reduce risk of loading to the wrong memory address.

Question: Is a command alias in ground software acceptable, or does the command directly into the instrument need to have the address abstracted?

Response: This question will be either clarified in the RFP release or during the ICD development process, if necessary.

13) Comment: CSPEC170: The Coronagraph flight software shall provide a restart by command with preservation of instrument configuration data and memory tables.

Question: 13a - Request clarification: is this just saying that these configuration parameters and memory tables must be stored in non-volatile memory? It is not clear what this requirement means.

How does this command differ from the on-board processor reset command?

Question: 13b - Please define reset vs restart.

Responses: 13a: Yes, the instrument must preserve configuration thru a power restart. The other requirement (CSPEC160) is about being able to reconfigure (parameters, table loads) without having to do a power restart.

13b: reset = soft reset; restart = power restart. Text changed to “…shall provide a reset…”.

14) Comment: CSPC235 states that the loads in Table 4 and Figure 8 should be applied at the “Coronagraph interface to the L1 SERIES Spacecraft structure”. However, in that same requirement (235), it goes on to state that the spacecraft will generate an attenuated shock environment for the COR to Spacecraft Interface and document those loads in the ICD. I believe that these two statements conflict. Figure 7 is reference which is a random vibration figure, not acceptance shock.

Question: My assumption is that the Table 4 loads are LV loads that will be attenuated to the Coronagraph through joint and distance attenuation, so we will eventually receive something lower than the Table 4 SRS spec.

Response: The text will be updated in the final RFP to clarify. Note that “Figure 7” is an error and should read “Figure 8”.

15) Comment: CSPC238: need additional help understanding the requirement below (italicized). The next

“curve below” is the 2000g LV shock loads which many may not deem benign. Contractor generally uses modal velocity criteria and sometimes peak g-level to determine if levels are benign or not. Regardless, we generally do not shock flight hardware and would reserve any testing for severe shock environments to be done on engineering model hardware. Waivers are typically generated for benign shock levels and the testing is deferred to the spacecraft test.

If the flight shock environment as shown on a Shock Response Spectra (SRS) plot (Q=10) is enveloped by the curve shown below, then the shock environment can be considered benign and there is low risk in deferring the shock test to the Observatory level.

Response: The text is being re-written to clarify our expectation that any component- and/or instrument-level shock testing to be done on a qualification unit. The two requirements were rewritten for the final RFP to be consistent and to explain two-joint (minimum) attenuation from the S/C-LV shock input curve given.

16) Comment: CSPEC284: The Coronagraph shall demonstrate turn on at the Minimum Survival and

Maximum Protoflight Temperature Limits.

We would anticipate demonstrating turn-on at minimum operational temperature, not survival.

Response: Agreed. This will be addressed in the final RFP release.

17) Comment: CSPEC306: All systems shall avoid or tolerate errors due to non-destructive SEE (e.g. SEUs, SETs, SEFIs, etc.)

Question: Request clarification on “tolerate” – does this mean survive? Continue to operate with diminished performance? Meet full spec?

Response: This requirement is being deleted, and much of the radiation section is being rewritten.

18) Comment: CSPEC315: The evaluation shall include the criticality and the rate of the event.

Suggest embedding context so the requirement can stand alone and remain clear. This is a general suggestion for the radiation section.

19) Comment: Again, in general, regarding the radiation and reliability: The quantitative data availability requirements suggest a full analytical SEEA, which is an atypical level of effort for a Class C mission.

The values of the quantitative data availability requirements seem at odds with a Class C level of risk.

There are many references in reliability requirements/CDRLs to “safety items” or “safety critical”.

The NASA definition of safety critical is: “Term describing any condition, event, operation, process, equipment, or system that could cause or lead to severe injury, major damage, or mission failure if performed or built improperly, or allowed to remain uncorrected.” Need to clarify what degree of event classifies as “mission failure” as it relates to the coronagraph.

20) Comment: CSPEC436: Test sensors shall be designed for flight.

Question: Please define “test sensors”

Response: Test sensors are any sensors attached to the COR instrument that are used for ground testing or monitoring and that will remain on the COR for flight.

21) Comment: CSPEC437: Unless specified to be removed before flight, test sensors shall not be removed prior to flight.

Question: Please define “test sensors”

Response20: See Response to Question 20.

22) Comments: CSPEC514: The CORONAGRAPH shall meet performance requirements when power and signal cables are subjected to an injection probe drive level of 70 dBμA over a frequency range of 10 kHz to 200 MHz per the MIL-STD-461F CS114 test method (Common Mode) as defined in GSFC-STD- 7000B, section 2.5.2.2.4.1.

The calibration limit is shown in Figure 19. Note that per the MIL-STD-461F CS114 test method, the injected level during EUT testing is 6 dB above this level.

Question: Section 8.3.2.1 states that “The conducted susceptibility requirements are applicable for the primary power wires that supply power to a unit. Conducted susceptibility requirements do not apply to the power return wires, secondary power wires or signal wires.” Please clarify if testing signal wires for [CSPEC]514 is required.

Response: Your comment is correct; the wording was corrected to remove “and signal”.

23) Comment: CSPEC557: The connector half that sources power to shall be female (socketed) to protect against inadvertent grounding prior to mating.

Question: For MDM connectors, the male/pin connectors are the ones that are shrouded. Suggest language change to “shall be shrouded”. (Note, 8.1.3 does have a “should” statement against using MDMs for power interfaces, but there are circumstances where high pin counts or size constraints lend themselves better to MDM connectors).

Response: The government will consider this change in language to better meet the intent.

24) Comment: CSPEC566: A minimum of seven hundred (700) hours of operating/powered-on time shall be accumulated on all flight electronic hardware prior to shipping the instrument.

Question: 700 hours is excessive for accumulated operating time, especially considering the required implementation timeline. Our quality management system specifies a minimum of 300 hours for instruments (system level). Recent instruments have achieved ~400 hours.

Response: This proposed requirement change will be evaluated prior to the final RFP release to determine if a change is necessary. If there is a change it will be reflected in the final RFP.

25) Comment: CSPEC570: As designed, each electronics box needed for the Coronagraph suite shall demonstrate at least 350 hours of trouble-free operations prior to shipment

Question: We anticipate testing the DPU and instrument together; we would not anticipate an additional, separate 350 hours of operations with the DPU by itself.

26) Response: An additional, separate 350 hours of operations with the DPU by itself is not required.

27) Comment: CSPEC685: The ESTE shall interface with the Spacecraft Ground Support Equipment at the

Spacecraft Contractor’s facility to extract Coronagraph science and engineering data Question: Clarification request – interface in what way? Network? Physical link of some standard?

Response: This means a physical link to a standard interface that will be specified in the ICD developed with the Spacecraft Contractor.

28) Comments: CSPEC811: Thermal vacuum testing shall be conducted in accordance with the requirements of Table 19.

Question: Our standard practice would be 6 cycles. Eight cycles is not impossible but may be difficult to fit into the required timeline.

Response: Comment will be considered.

29) Comments: CSPEC819: The component shall be powered and critical parameters monitored using an LPT as defined in 7.2.3 during chamber evacuation.

Question: We typically do not power on the instrument during pumpdown unless the instrument would be powered during launch.

Response: The intent of this requirement is test as you fly, may not be required if the COR is not planned to be powered during launch. Will review and update in final RFP.

30) Comment: CSPEC839: The instrument shall comply to the Radiation Hardness Assurance Requirement

Document.

Question: Is there a new version of the RHARD that will be made available? One does not seem to be attached to this notice.

Response: Yes, a new version exists, and the document will be made available with the final

RFP.

31) Comments: CSPEC840 (FPGAs must use TMR)

There are data availability requirements, and the method for satisfying those should not necessarily be specified.

CSEPC842 says FPGAs “shall be protected by non-destructive SEE mitigation and recovery mechanisms such as TMR to meet performance requirements during critical space weather days.”

CSPEC842 seemingly supersedes CSPEC840 and reflects the above point – TMR is an option to meet the other requirements.

Question: Could the requirement state if/that fabric-level TMR is satisfactory?

Response: The requirement for the TMR stands.

32) Comments: Regarding [Sec] 6.1 [Mechanical Factors of Safety] …

We should have more discussions on whether there is a necessity to proof test bonded joints in addition to the planned RV test.

RV safety factors are higher than what we typically use at contractor for metals, but I have seen this approach used before.

Question: Please add in the desired glass/ceramic safety factors, and whether 3σ is still acceptable there.

Response: The Coronagraph developer can pursue a different approach for verifying bonded joints through deviation / waiver process. The spec states that factors of safety for glass and structural glass bonds are specified in NASA-STD-5001.

33) Comment: Regarding 6.3.1 fundamental frequency… 100 Hz may be hard to achieve, so we may need to perform a CLA with the Spacecraft. We have done this on other projects. Our goal is to minimize stress induced into the COR tube/baffle so it’s a tradeoff between stiffness for launch and compliance for STOP.

Response: Understood.

34) Comment: Regarding Section 6.6 acoustics…. Contractor does not generally perform acoustic tests or analyses of instruments, occasionally for instrument sub-components. Use of GEVS is generally considered adequate for covering the acoustics environment. Also, acoustic responses are generally driven by high aspect ratio structure such as spacecraft paneling, so performing a test at the instrument level does not necessarily simulate the correct flight environment. Acoustic analysis at the spacecraft level should inform the RV spec at the instrument interface.

Response: This section will be updated in the final RFP.

35) Comment: CSPEC852: “The Coronagraph shall function after exposure to the worst 5-Min peak fluxes listed in Figure 17 and Table 12 (solar particles) and Figure 18 and Table 13 (solar protons).”

Questions: Request clarification on “shall function after” – do we need to recover autonomously (and can that recovery include S/C intervention, or just instrument)? Is there a time limit for recovery?

Same comment regarding CSPEC854

Response: Recovery time needs to be included in the overall availability of the instrument but is not specified specifically.

36) Comments: Comments on (c), the MAR REL_17 “The developer shall perform and maintain qualitative fault tree analyses (FTA) (CDRL MA 4-3), as deemed necessary by the Chief Safety and Mission Assurance Officer (CSO) and the Mission Systems Engineer (MSE).”

- It is difficult to anticipate the associated amount of work given the open-ended nature of this requirement.

Response: The requirement is to perform a FTA. We will remove “as deemed necessary by the Chief Safety and Mission Assurance Officer (CSO) and the Mission Systems Engineer (MSE).”

There are additional requirements in MAR Section 4.2.2 that define the scope of FTA work.

37) Comments: REL_30 – Worst Case Analysis. - WCA is uncommon for a Class C mission; this should be restricted in scope to only safety critical circuits (in conjunction with the earlier comment about defining criticality).

Response: The requirement states “the developer shall perform Worst-Case Analyses (WCA) for circuit designs that are new or significantly modified”. The requirement is consistent with a 5-year mission lifetime.

38) Comments on (e), the CDRLs SW-2: Software Delivery Packages

Question:

1a – will a template be provided for the Software Delivery Letter?

Response: The software delivery letter should be in contractor format and should follow the instructions and include the data requested in the DID.

39) Comments: FW-1: FPGA Development Plan

- 2c – for our process we would typically not define FPGA part choice in this document, the development plan defines how design is performed/design choices are made, it does not define what the design choices are.

- 2g – similar comment for the tools & versions as 2c

Response: The FPGA Development Plan is an overall development plan and includes more detail than a general development plan. For the preliminary plan, the part types and tools may be a list of potential candidates. The plans will be updated once selections have been made.

40) Comment: FW-2: FPGA Design Data Package

Questions: - 1 – does “each design used by the vendor for the L1 Series Project” mean flight FPGAs or GSE as well? GSE is typically subject to substantially lesser process than flight designs (ie 2g would not apply)

- Due date – these due dates seem too early in the design cycle. For reprogrammable FPGAs it is not uncommon for the design to not be finalized by CDR. A more typical deadline would be a preliminary design by CDR and a final flight design by PER.

Response: The FPGA Design Data package is to ensure FPGAs can withstand the on-orbit environment, specifically radiation. The CDRL will be updated to require FW-2 only for flight FPGAs and the delivery dates will be adjusted so the preliminary delivery is due 30 days before CDR and the final due 30 days prior to PER.

41) Comment: SE-14: Digital Image and Video Records.

- Describing each individual photograph in detail could be time consuming. Frequently this is done at the folder level (i.e. all photographs for a specific test setup or work execution document).

Response: Documenting photographs and videos at the folder level is acceptable. However, if there is something remarkable for an individual photograph or video within a folder, the artifact will be individually annotated.

42) Comments on (f), the Statement of Work

- General comments on reviews: our typical practice is to distribute materials 7 calendar days in advance;

this is flexible for peer/tabletop review.

Response: The CDRL delivery table indicates when Instrument review material is required. There is some flexibility for peer/tabletop and test data reviews with prior agreement by the government.

43) Comment: For all references to notification of anomalies:

Question: Is there a threshold for what constitutes an anomaly that cannot be resolved internally?

Response: The Coronagraph MAR states in QMS_14: The developer shall have a documented process for the establishment and operation of an anomaly review board (ARB) to process (report and disposition) major anomalies, which are those that have resulted in hardware or software test failures and damage or potential damage to hardware, require a software change, affect safety or where there is a violation of a Government requirement.

44) Comment: - 4.5.7: Test Data Reviews.

Question: Requiring 10 days’ notice of a Test Data Review which precludes the breakdown of a test setup could cause schedule delays. I&T schedules can frequently change.

Response: 10 business days are necessary to facilitate contacting subject matter experts to travel to the contractor’s location. The government will review each situation on a case-by-case basis during performance of the contract.

45) Comment/Reference: - 6.1.2:

“The contractor shall perform an analysis of unnecessary and/or unreachable code, as defined per GSFC- STD-1000 (Rev G) Table 3.02-1, on the intended flight load for launch. The analysis shall identify all instances (areas) of unnecessary/unreachable code, the general functionality associated with the code, the reason each is intended to be left within the flight load, and the justification (e.g., mitigating action) that explains why the included code does not provide a risk to the mission.”

Question: This is not part of our typical contractor FSW Development Process

Response: The requirement is necessary to mitigate unintended instrument behavior and be compliant with GSFC STD-1000 (Rev G).

46) Question: - 6.2.1:

Does “NASA Independent Peer Review” mean inviting a NASA representative to existing reviews, or a separate independent review process? Contractor has typically not done a separate independent peer review for FPGAs.

Response: The SOW states the requirement that, the Contractor shall provide for one NASA independent peer review, prior to programming the flight parts (pre-burn review) for each new, modified, or re-used FPGA design. This is a peer review attended by NASA. It can be part of an existing review depending on the scope of that review.

47) Question:

- 6.3.2.2 Structural and Mechanical Testing Requires we report moments and products of inertia within +/-5% by analysis about CG; it is typical to report inertia values to +/-10% via calculated models from CAD modeling; is 5% a true requirement? If so, calculated values are likely not that accurate and the direct mass properties measurement will be required to provide this level of accuracy.

Response: The requirement is to determine by analysis the launch and on-orbit moments and products of inertia to an accuracy of ±5.0 percent of the maximum principal moment of inertia, referenced to the coordinate axes with an origin at the center of gravity.

48) Reference: - 7.2 MGSE

Question: Please clarify what all MGSE is required to be delivered vs. used and maintained by the Contractor.

Response: All MGSE developed by the contractor will be maintained by the contractor. The Contractor will design and develop sufficient MGSE to facilitate testing within their facility. For each Coronagraph FM under contract, the instrument Contractor will develop and deliver to the Observatory Contractor one Lifting/Handling Fixture, one Shipping / Storage Container, Shipping Containers for FM GSE as required, one Purge Cart; and any other instrument specific MGSE required to support the instrument. These items will remain at the Observatory Contractor’s facility until Observatory shipment to the launch complex at which point, they will be returned to the instrument provider for disposition.

49) Comment: Number of TBDs/TBCs still a potential threat to cost and schedule for our planed program.

Response: The Final RFP version will reduce the number of TBDs and TBCs.

50) Reference: CSPEC16:

Comment: The requirement for 99.9% probability of operating continuously on orbit is not consistent with a class C instrument and has the potential to severely drive cost, mass and schedule. We recommend deletion or reducing the reliability level and limiting scope.

Response: This requirement was deleted.

51) Reference: CSPEC20:

Question: HAP is not defined Response: See response to question #2

52) Reference: CSPEC20:

Comment: Class X50 flare conditions seem extremely demanding and requires designing a 5 year mission around a once every 50 year event. We recommend either dropping the flare condition to a level likely to be encountered a few times per cycle (such as X5), or specifying a recovery/reboot time after an X50 event, as guaranteeing operation during an X50 event is likely to drive cost unnecessarily.

Response: Yes, it is very demanding and drives the design. The reason for the mission is to take these measurements during these storms. Recovery time is driven by 99% requirement.

53) Reference: CSPEC476:

Comment: We recommend deletion of the following EMC test as they represent a significant risk to the instrument with limited benefit:

- Conducted Susceptibility, Bulk Cable Injection tests:

o CS114CM: This conducted susceptibility test is relatively high risk, and the EMI filtering on the power inputs and isolation on the comms provided should demonstrate performance through a combination of analysis and component-level testing. We recommend elimination of this method.

o CS114DM: This is the same as above with a different routing for wiring. We recommend elimination of this method.

o CS115: The same rationale for the above. Recommend elimination.

- Radiated Susceptibility:

o RS103 Launch: We will be off during launch and should have no concerns.

Response: Thank you for your comments, however, these requirements will remain.

54) Question: Also, there are references to MIL-STD-461C/462, MIL-STD-461F and MIL-STD-461G.

Is this intentional?

Response: No, it isn’t. The spec will be updated to reflect rev G everywhere.

55) Reference: SOW 4.2:

Question: Please clarify the structure of any incentive fee.

Response: The contract will be Cost Plus Fixed Fee (CPFF), with no incentive fees.

56) Reference: SOW 4.2:

Comment: Private office space at subcontractors may drive subcontracting costs; we suggest negotiating the amount and type of space (private vs. visitor) at time of award, based on subcontractor role and Program Office interest level for each subcontract.

Response: Office space is only required for major subcontractors as required in the SOW.

57) Reference: SOW 7.1.2:

Comment: Please clarify what is meant by COR emulator: software/controls/telemetry function only, or mechanical/optical function as well? If the requirement is for controls/telemetry function only, then we suggest stating that the vendor may choose either software or hardware emulation.

Response: The COR emulator is a Coronagraph (COR) simulator that is not form or fit but does provide the functionality of the Command & Telemetry (C&T) and science data interfaces of the instrument. Power load simulation via HW is not required.

58) Reference: SOW 4.2:

Question: Will IPMR be required (as called out), or IPMDAR?

Response: IPMDAR is required, SOW and CDRL will be updated for the Final RFP.

59) Reference: SOW 4.2:

Comment: If possible, would like to see an option to use alternative scheduling tool for the generation and reporting of project schedules (for example, Primavera P6), as well as an option to submit monthly schedule deliverable in format other than MS Project file.

Response: The requirement is “The Contractor shall use Microsoft Project (latest version) as the scheduling tool for the generation and reporting of project schedules.”

60) Reference: SOW 6.3.2.5:

Question: Please confirm that it is the customer’s intent that acceptance level testing is allowed for exact duplicate FM2 and FM3 builds in all cases except thermal testing, where Proto-flight levels are required (current language).

Response: Paragraph will be updated: Acceptance level testing is acceptable with prior Government approval.

61) Reference: SOW 4.5.9:

Comment: If possible, we would like to see the requirement language for subsystem PDRs/CDRs adjusted to allow peer reviews, so long as the subsystem is then represented at instrument PDR/CDR.

Response: The language allows for what you’ve asked.

62) Reference: SOW, general:

Question: Can a notional schedule be provided for mission simulations and times when 24/7 staffing is required for observatory integration and test support?

Response: Additional BOE guidance will be provided in the RFP, and was included in the Draft Section L&M.

63) Reference: MAR GEN 15:

Comment: Please limit Facility Operations and Quality Metric Reporting to SOW product and scope of work and permit internal and supplier quality audits.

Response: The status of facility operations and quality metrics are as stated in the Coronagraph

MAR.

64) Reference: MAR GEN 25:

Comment: Please clarify (and limit the scope of) pre-shift meetings to flight hardware assembly.

Response: The requirement states, prior to performing work on flight hardware, the performing organization shall hold a meeting to identify a list of items, if any, that are sensitive to normal handling environments.

65) Reference: MAR SWA 08:

Question: We are not confident that we can provide all source code due to IP considerations, particularly for subcontracts or for software packages. Consider limiting to custom software developed “on contract”.

(E.g., JPG2000 is a commercial FPGA core and source code may not be available) Response: The requirement is to provide source code for software funded by and developed on the project.

66) Reference: CDRL table 5:

Comment: While we understand the motivation for setting FM-2 PSR and FM-3 PSR as early as they are, these represent a significant challenge and may not be achievable. The FM2 and FM3 PSR dates are to be proposed by the contractor.

Response: Final RFP Table will be updated. The requirement will be updated as follows “Pre-ship/Pre-storage Review No Later Than at least one month prior to shipment and storage, date to be proposed.”

67) Reference: CDRL SE-15 –

Comment: Test plan final copy due 90 days before test (prelim at CDR). Our concerns hinge on definition of ‘plan’, vs procedure. Regardless, some requirements are going to be very difficult to finalize so far in advance on an aggressively scheduled program (i.e. instrumentation figures, and sample data analysis). We suggest either reducing the required level of detail.

Response: The SE-15 is for Test Plans, not Test Procedures.

68) Reference: CDRL PM-1 –

Comment: Program Management Plan preliminary draft is due 30 days ACA. This seems somewhat aggressive and would require work during the unfunded bridge phase. We Suggest PMP, SEMP and EEEPCP should be due in draft form 60 days ACA, with the final plans due at PDR Response: The requirement is for the draft to be due 30 days ACA and the final to be due after PDR. Adjustments to the required delivery dates can be made during project execution with prior Government approval.

69) Reference: CDRL SE-1 – Systems Engineering Management Plan – same as above

Response: See response to question #68.

70) Reference: CDRL MA 7-1 EEE Parts Control Plan – (final?) due 30 days ACA – same as above Response68: See response to Question #68.

71) Reference: CDRL MA 5-1

Question: Software Assurance plan final copy moved from 15 days before CDR to 15 days before PDR.

Is this a typo? If not, that seems very early for a final SWAP. We suggest that the final copy be due 60 days post PDR.

Response: The Software Assurance (SA) Plan is needed by PDR to support SW development.

72) Reference: CDRL FW-1 – final FPGA development plan moved up from CDR to 45 days before PDR.

Question: Is this an overall development plan or detailed design and test plan? If the former, then this is acceptable, but PDR-45 days will be very hard to achieve and almost guarantees significant edits.

Response: The FPGA Development Plan is an overall development plan and applies to all flight FPGAs used by the Contractor for the L1 Series Project. The preliminary version of the plan is due at SRR and the final is due 30 days prior to PDR.

73) Comment: There are 2 CDRL MA 4-4s Response: Correction will be made in the final RFP documents.

74) Reference: CDRL MA 2-2 Non-Conformance Reports – Comment: This is listed in the table of contents but there is no information in the actual document.

Response: CDRL MA 2-2 has been deleted. The Table of Contents (TOC) has now been updated.

75) Question: Will it be possible to provide a Draft of Sections L & M of the RFP prior to issuance of the final RFP? This would allow bidders to develop draft proposal documents and provide feedback to the government in advance of the final RFP, reducing the time needed from the issuance of the RFP to final submission ofproposals.

Response: A draft section of L&M was posted on SAM.gov

76) Reference: Title "Weekly Status Reports and Minutes”:

Comment: Suggest deleting occurrences that fall during bi-monthly Program Management Status Reviews (CDRL 022) and other major reviews/meetings.

Response: This is common practice, and it may be done with prior agreement by the Government on a case-by-case basis.

77) Reference: Updated SDR Package:

Comment: Suggest eliminating updated SDR package and keeping preliminary and final deliverables.

Response: The updated SDR/SRR package will remain. This is to support dry-runs and ensure maturation of the presentation material.

78) Reference: Title "Pre-Mishap Plan:"

Comment: Suggest that Preliminary is due 45 days prior to PDR instead of 45 days prior to SSR.

Response: Agree, the CDRL has been updated to reference this information.

79) Reference: Title "Monthly and Quarterly Financial Report" :

Comment: Suggest delivery be due 2 weeks AFTER period being reported, instead of "The report is due 2 weeks prior to the period being reported."

Response: The requirement is to provide the previous month’s data no later than the 15th calendar day of each month.

80) Reference: Program Scope and Management: T Comment: The SOW states: "The L1 Series Observatories are targeted to launch as individual primary payloads, December 2028, and October 2032." and "The period of performance for the contract is from contract award through fifteen (15) months (TBR) after launch of the second mission." Fifteen months after 10/2032 is Jan 2034. This conflicts with the Pre-solicitation Notice which states a 9 year Period of Performance from Sept 2024 which implies the Period of Performance end is Sept 2033.

Response: The 9 years was an approximation in the pre-solicitation notice and nowhere else, the SOW is correct, and it reflects the correct information.

81) Reference: Conflict:

Comment: The SOW states that two ESTE deliveries are required instead of 3 as stated in the SOW and CDRL documents.

Response: There will be 4 sets of ESTE required to support the ETU and 3 FMs. The SOW will be updated to clarify the quantity of ESTEs required.

82) Reference: Project Management Reviews:

Comment: "The status reviews shall be held at the Contractor's facility through successful completion of the CDR, then alternate between a Government designated facility and the Contractor's facility." Suggest that PMRs continue only through the Pre-storage Review of FM-3.

Response: This is the requirement but can be evaluated during the project on a case-by-case basis based on Government approval.

83) Reference: Instrument Design Reviews, Dry Runs:

Comment: Suggest Dry run and Preliminary Slides due 1 week prior to all Instrument Design Reviews to streamline program schedule and maximize schedule margin. This is especially critical for the SRR, which occurs early in the program.

Response: The requirement is to provide slides and perform dry-runs 2 weeks prior to SRR, PDR and CDR. An additional delivery is required for SRR one week prior to the review.

84) Comment: Average power for survival heaters is [TBD-6]W over 60 minutes –

Question: What is the maximum power limit?

Response: The Spec will be updated to provide a quantity in place of the TBD and provide peak power limit.

85) Reference: CSPEC52 provides the requirement for the average data rate over 5 seconds.

Question: What is the maximum clock frequency (which will determine the peak data rate)?

Response: This information will either be provided in the final RFP or be specified in the ICD.

86) Reference: CSPEC67:

Rationale: The rationale for this spec states that the spacecraft will monitor up to 6 (TBR) analog instrument health and safety parameters.

Question: Can faults also be communicated over the digital bus?

Response: Yes, the spec will be updated to include 12 (TBR) digital telemetry points.

87) Comment: CSPEC74 requires operation during all spacecraft maneuvers. CSPEC75 requires recovery of performance within 300 seconds (TBR) of maneuvers.

Question: Please define the constraints on S/C maneuvers to ensure instrument thermal stability recovery can be achieved within the required timeframe.

Responses: A note was added to the latest CSPEC so that the requirement now reads “CSPEC75:

The instrument shall meet all performance requirements within 300 seconds (TBR-9) after the spacecraft interface has returned to being within specification following spacecraft maneuvers. This requirement assumes that no direct sunlight illuminates the Coronagraph radiator during the maneuver. “

88) Comment: HAP details are not provided. Please provide HAP definition and/or reference document and/or specification.

Response: See Response to question #2.

89) Comment: The current wording of CSPEC16 could be interpreted as a reliability requirement. Suggest rewording to: "The availability of the data collected shall be 99.9%" or providing additional rationale on what is specifically intended.

Response: This requirement was deleted.

89) Reference: Specification Section 4.4.3 Missing Spec ID

Response: The requirement cites specific figures in MIL-STD-461.

90) Reference: Specification Section 4.4.5 Missing Shall Statement

Response: This has been added

91) Reference: CSPEC105 Should "Mag Electronics Unit" be "Coronagraph"?

Response Yes, and it has been corrected.

92) Reference: CSPEC112 and CSPEC67

Comment: There are three analog signals specified in the requirement, but the rationale says six is reasonable. CSPEC67 also refers to 6 analog signals.

Question: Which is the correct number?

Response: The spec will be updated to reflect six analog signals.

93) Question: What is the physical signal type of the PPS signal (RS-422, LVDS, Discrete?)

Response : This is TBD; to be defined in ICD.

94) Reference: CSPEC114:

Comment: There are two data signal interfaces called out.

Question: Why two? Are they redundant C&C and data, or are they command and control and data output on separate spacewire interfaces?

Response: Either option is acceptable.

95) Comment: Specification 4.6.2.2 Figure 3 is missing

Response: Figure 3 will be added.

96) Reference: CSPEC182 requires metric units to be used.

Comment: SOW specifies metric units for spacecraft interface only. Suggest clarifying that this requirement applies only to Spacecraft Interfaces.

Response: The SOW will be updated to be consistent with the spec, which describes several conditions for which use of English units is acceptable.

97) Comment: Please clarify CSPEC219 applies only to launch configuration. ("Launch" is in paragraph title, but not in text of requirement.)

Response: Clarification will be added to text in the Final RFP.

98) Comment: CSPEC219 states "Requirements for the submitted finite element model are shown in the Coronagraph SOW." No reference to submitted finite element model was found in the SOW. Suggest adding reference in SOW.

Response: Agreed. Reference will be added in the SOW.

99) Reference: Please clarify CSPEC235:

Comment: Requirement text indicates that shock environment is to be applied at spacecraft to coronagraph interface, but rationale text indicates this is the shock environment between the spacecraft and the launch vehicle adapter, and that the coronagraph shock environment will be provided in the spacecraft to coronagraph ICD. Please clarify that the shock at the instrument interface to the spacecraft interface will be provided and supersede the graph currently in the spec.

Response: The section will be rewritten to correct the error and clarify the information in the Final

RFP.

100) Reference: CSPEC238

Comment: The text references "curve shown below" for shock susceptibility assessment, but no curve is provided.

Response: The curve is the one in Figure 8; and Table 4 is equivalent.

101) Reference: CSPEC248 requires protoflight levels for acoustic testing for all units.

Comment: Please confirm, as this is not consistent with the language in section 6 of the SOW regarding test levels for subsequent units.

Question: Which is correct, the CSPEC or the SOW?

Response: It depends, however, the SOW wording has been updated to require government approval for acceptance levels on subsequent units.

102) Reference: Please clarify CSPEC 268:

Question: What is the center of rotation for this requirement?

Response: The center is at the instrument CG since this is superimposed on the linear acceleration requirement.

103) Reference: In CSPEC270, Question: Is "conductively coupled" meant to be "conductively isolated"? This is consistent with <5W heat transfer to the spacecraft (CSPEC272).

Response: The spec has been updated to reflect electronics coupled and sensor unit isolated to ≤0.04W/°C [TBR]. The revised spec will be posted with the final RFP.

104) Reference: CSPEC274

Question: Please clarify: what kind of validation is required for thermal coatings properties? Does this requirement mean that life testing of coatings is required?

Response:

Validated means that coatings properties (1) have been verified for flight thru a qualification process (either previously or as planned/executed on this project) and (2) are valid for L1-Series mission (e.g., temperature, radiation, and lifetime regimes).

All coatings selections will be reviewed along with all materials used on the mission as part of the normal material review process with the contractor and the Government.

105) Reference: CSPEC284:

Comment: This requirement implies that the low-end survival temperature will be controlled to the minimum Protoflight operating temperature.

Question: Please clarify if the low-end survival temp the same as the Protoflight min operating temperature?

Response: The flight survival interface temperature is specified in CSPEC-4099 in the specification to be released in the final RFP. The protoflight min operating temperature is shown in Figure 12 with CSPEC-279.

CSPEC-284 is a separate requirement to demonstrate turn on at minimum survival temperature and maximum protoflight temperature limits. This is in accordance with GEVS (GSFC-STD-7000) practices.

106) Request: Please provide the referenced Radiation hardness Assurance Requirement document.

Response: A new version of the document will be made available with the Final RFP.

107) Question: 1Specification Table 13 Should "MAG" be "COR"?

Response: Yes, and that is now Table 14. Corrected.

108) Question: Can materials be incorporated in the Coronagraph that allow the system to meet all contamination requirements, even if they are not compliant with these specifications?

Response: For CSPEC380, yes, as the requirement says, “…unless specific steps are taken to minimize or eliminate the possibility of particulate generation”. For CSPEC382, a waiver would have to be submitted.

109) Comment: CSPEC495 Change "figure 15" to "figure 21"

Response: This section will be rewritten.

110) Reference: CSPEC784

Comment: Suggest allowing a low-level random survey as an alternative to a sine sweep survey.

Response: This can be discussed during I&T planning during performance of the contract.