LFS_DraftRFP_Questions and Answers.pdf

Ques-tion #

Page # Subject/ Section

RFP Language Question/Comment NASA Response

1 C-33 4.5.1 The Contractor may produce drawings in the Contractor’s drawing system but shall provide hardware drawings and CAD solid models in ProE format and electrical/electronic schematics and printed circuit board layouts in OrCAD format.

Are universal formats (e.g. .step) acceptable?

Also DRD RV-03 referenced in SOW 4.5.1 conflicts with OrCAD format and requests "compatible with Altium".

The Contractor shall provide hardware drawings and CAD solid models either in Creo or as *.step files.

Electrical drawings shall be submitted in either Autocad, a non-editable PDF, *.step or *.stp format for cable and assembly drawings. For PCB design files, Altium should be used.

2 J-72 All What is the due date for the Risk Management Plan? The Initial Risk Management Plan (SQ-15) is due with the proposal. The final Risk Management Plan is due within 45 days of contract award.

The DRD and solicitation language will be updated to reflect the Risk Management Plan due dates.

3 J-8 Scope "The Contractors submitting an initial Property Management Plan as part of their reply to the Request for Proposal in accordance with Contracting Officer direction."

It is unclear if the Property Management Plan is due with proposal, or due when requested by CO. Pg L-33 of the draft RFP file shows it as a required document in the Model Contract.

The "Initial" Property Management Plan (PMP) is not due with the proposal, but due upon direction of the CO (after). Then, the "Final" PMP would be due 30 days after contract award.

4 L-10 Table L-2 Past Performance -20 Pages The past performance page limitations are not clear. Is the 1 page Introductory Material included in the 20 page total?

Can more detail be provided as to what is considered Introductory Material?

Is all of Section L.9.6 (i) not part of the 20 page limit? The Not Limited pages should be more explicitly identified by section number [e.g. Past Performance Matrix L.9.6 (e)].

The Introductory Material - 1 page, is NOT included in the 20 pages and solicitation wording will be updated to reflect this clarification.

The introductory material detail is up to the offeror. This is for the offeror to introduce the section, potentially identify the past performance vendors, segwaying into discussing the specifics of Past Performance. This 1 introductory page is not part of the 20 page Volume that follows.

Table L-2: Overview of Proposal Volumes, Page Limitations, Copies, and Format, has been updated to identify the unlimited pages by section numbers of L.9.6.

5 A-2 Draft PTRS Applicable Documents

Missing GP 10037 Gateway Payload Interface Document

Will the LFS be developed as a typical Payload system or as a facility subsystem?

From a flight hardware development and certification standpoint, the LFS is considered Government Furnished Equipment (GFE) and is planned to be certified using GFE flight hardware certification processes.

From a vehicle interface standpoint, the LFS is also considered a Payload or Utilization/Science since it interfaces with the Payload Banks (physical interface, power and data interface, etc.).

GP 10037 is listed as a Reference Document in the LFS PTRS; M2M 30035 is provided in the LFS Technical Library and provides a mapping of requirements between GP 10037. Reference Documents are not provided as part of the RFP process, but may be provided to the LFS vendor on contract as needed.

LUNAR FREEZER SYSTEM - DRFP QUESTIONS & ANSWERS

6 A-2 Draft PTRS Applicable Documents

LFS Applicable Documents Many of the applicable documents listed in the Draft PTRS have not been provided for proposal development and cost analysis. Will all of the applicable documents listed in Table 1 be provided with the Final RFP?

All of the documents listed as "Applicable Documents" in the Draft PTRS (Table 1: Applicable Documents) are included in the LFS Technical Library. Documents not available are noted in the table. Most of the Applicable Documents are in the "Controlled" access files on sam.gov (technical documents that are not available to the public).

Please confirm that a representative of your organization has access to the controlled documents in the sam.gov Attachments/Links. All documents in the sam.gov Controlled files must be treated as CUI or as specified by the designated coversheet markings.

"Reference Documents" listed in the PTRS (Table 2) are not provided for proposal development.

7 A-20 Draft PTRS 5.3.2.1

The LFS shall provide a cold volume with usable sample space of at least 66.0 x 25.4 x 25.4 cm (26 x 10 x 10 inches) (TBR).

Do the cold volume dimensions need to be continuous?

i.e. Does qty (2) x 13" x 10" x 10" or any other set of dimensions that preserve the volume work?

The cold volume dimensions must be continuous to accommodate large lunar sample containers.

Requirement 5.3.2.4 "Maximum Sample Dimensions" was added to the PTRS to provide additional clarification. The freezer cold volume and the freezer door shall be large enough to fit a lunar rock sample container.

8 A-60 Draft PTRS 5.7.2

Table 4 gives 330mm as the max Z-dimension. M2M-30035-PLD-R-2000 Table 3.3.1-1 gives 500mm as the max z-dimension.

Please clarify.

PTRS Table 4 provides the maximum external dimensions for the Lunar Freezer System. The dimensional requirements are defined by the maximum size that the Orion vehicle can accommodate.

M2M-30035-PLD-R-2000 Table 3.3.1-1 is listed as reference, and provides the maximum dimensions of "Payload Bank" hardware for the Moon to Mars Program. Due to volume limitations inside the Orion vehicle, the LFS will not utilize the full depth of a M2M Payload Bank location.

9 L-18 L.9.6i Environmental Data

Copies of any and all environmental non-compliance correspondence and citations from federal, state or local agencies or authorities with explanatory remarks.

Is a statement that there have been no environment non-compliances in the past ten years sufficient?

Yes, that is sufficient.

10 L-18 L.9.6i Health and Safety Data

Copies of any and all OSHA citations with explanatory remarks.

Our parent organization, as an institution of the state, is not subject to, and is exempt from OSHA regulations. Therefore, we have no citations from OSHA. Is further documentation required to show proof of this?

Please provide verbiage (for Government documentation) stating that your company is not subject to, or exempt from OSHA regulations, and please provide the exemption citation.

11 L-18 L.9.6i Health and Safety Data

Records of the company’s occupational injuries and illnesses. These records shall include, for each worksite, as a minimum, number of occupational injuries and illness (broken down by days away, restricted or transfer, and other OSHA recordable), injury logs (you may redact employees’ names).. The format may be a copy of each year’s OSHA logs (Forms 300 and 300A) or equivalent occupational injury and illness data

For our parent organization, occupational injuries and illnesses are maintained by a third-party and the collected data is not permitted to be submitted as part of a proposal.

We have been instructed by our Office of Sponsored Programs to submit OJI information specific to our department as opposed to organization-wide data. This would be provided in a signed statement on formal letterhead from our Department's director as our parent organization is exempt from OSHA regulations. Please respond with concerns, if any.

On-the-job injury information specific to the department or organization should be acceptable if it includes records for the department that will be performing the work for the LFS contract, and therefore relevant to the LFS contract. The company should ensure that the applicability of the health and safety data (e.g. department-specific data, etc.) is clearly defined in the proposal. The offeror is responsible for ensuring that all requested information in the solicitation is provided in the proposal. If your company has exemption to OSHA, it is expected you please reference and explain the exemption, otherwise the general OSHA log is expected.

12 A-32 Draft PTRS 5.4.7

Are there any constraints on programming languages or frameworks to develop the flight software?

There are no hard requirements on programming languages defined at the NPR 7150.2D level. At this time, within the Gateway Program, there are no constraints or requirements with regard to programming languages or software development environments/frameworks.

It is possible that certain programs, projects, or organizations could implement language requirements, or that specific requirements may be applicable based on safety or other design and/or flight software factors. Additional requirements for flight software will be determined during the System Requirements Review (SRR) phase of the project.

Please list any assumed/planned flight software programming language as part of the proposal.

13 A-32 Draft PTRS 5.4.7

Are there any constraints on the use of open source software?

Open source software (OSS) may potentially be used, assuming the licensing of the software in question allows for usage in the desired purpose or application. There are requirements specific to OSS in NPR 7150.2, and one of the main requirements that discusses OSS is SWE-

027. In addition, the JSC Spacecraft Software Engineering Team (SSET) processes have assets that cover open source software selection processes. Open source software for use in flight hardware must also be assessed for risk to long-term utiliziation and security.

https://swehb.nasa.gov/display/7150/SWE-027+- +Use+of+Commercial%2C+Government%2C+and+Legacy+Software

14 A-32 Draft PTRS 5.4.7

Are widely-used coding standards for embedded systems, such as MISRA C, required (other than NPR 7150.2D)?

To clarify, NPR 7150.2 is not a coding standard itself, but does have a requirement to follow a coding standard. It does not specify which coding standards to use, but depending on the software classification and safety criticality, some of the more established coding standard will be encouraged.

https://swehb.nasa.gov/display/SWEHBVD/SWE-061+- +Coding+Standards#tabs-3

The JSC Spacecraft Software Engineering Team (SSET) has established a FSW C coding standard, that can be made available to the Contractor, upon request, after contract award.

The Gateway Program has also developed software standards for data exchange (GP 10098 Space Packet Protocol Standard (SPP)) and Payload Interface Requirements (GP 10121 Gateway to Payloads Software Interface Requirements Document). GP 10098 establishes the message header format based on CCSDS standards for space packets, which enables seamless data routing and exchange within Gateway. GP 10121 is a two-part IRD that integrates Payloads into Gateway. For LFS, the Payload System Manager (PSM) interface would be the side of the IRD to focus on. PSM provides a set of services to all payloads including command, control, data offload/storage, and general management of the payload through a scripting engine. PSM would be the LFS’s integration point.

15 C-12 SOW Table 2:

Preliminary Milestone Delivery Schedule

Engineering Development Unit & Flight Support Equipment (FSE) Complete

What Flight Support Equipment does the Customer envision will be needed to support LFS and will this be a necessary delivery at EDU completion (CLIN 2)?

Flight Support Equipment includes any ancillary hardware that is necessary for the operation of the Lunar Freezer System. Examples of Flight Support Equipment may include power cables, data cables, fasteners, unique tools, gloves for handling cold samples, trays, special inserts, removable items that enable the freezer to be reconfigured (if relevant), hardware to support sample transfers, etc.

PTRS Section 6.0 "Ancillary Flight Hardware" provides requirements and information about Unique Flight Support Equipment; however the actual FSE that is required will be dependent on the LFS design.

Flight Support Equipment will need to be delivered with the Flight Units, Qual Unit, not upon initial completion of the Engineering Development Unit (EDU). Table 2 on page C-12 will be updated to clarify.

16 C-13 2.3 NASA Insight and Approval

Upon request, the Contractor shall provide all NASA designated personnel (including support contractors) access to all project related data, including but not limited to technical and management data. This includes all technical data related to the projects, such as software programs and code, drawings, models, procedures, analysis, and test plans. This includes access to risk management systems, quality management systems, configuration management systems, approval systems, requirements management and verification systems, and procurement information. This is applicable to data and systems used by and generated by the Contractor and its subcontractors in support of the LFS Contract.

Does the LFS Contract require NASA and support contractors direct access to Contractors IT systems? Historically, NASA sites were used for specific data submittals. Small organizations will incur significant cost impacts for this type of implementation and execution, in addition to IT Security compliance.

No, the LFS Contract does not require direct access to Contractor IT Systems; the requirement is for the Contractor to provide technical and management project related documentation upon request, or as detailed in the contract (e.g. Statement of Work and DRDs).

17 C-37 5.0 Flight Integration and Operations (CLIN 3)

Support ICD development and provide mission specific verifications and Certificate of Compliance (CoC) Letters as identified in the Orion, Gateway and HLS Programs ICD/Payload Verification Plan (PVP)

There are no references to the Launch vehicle requirements.

Assume that the LFS will launch powered or unpowered (Soft stowed) in the Gateway Logistics Module (SPX Vehicle which falls under the Gateway Program requirements. GP 10037 is referenced as the IDD for Gateway Payloads (i.e. LFS). Can this document be supplied for LFS requirement assessment?

Currently there are no payload interface specifications for this vehicle, only interface requirements for the vehicle to Gateway and Human requirements. The launch vehicle may be the structural driver for LFS design.

M2M-30035, Artemis Payload Interface Definition Document (PIDD), is provided in the LFS Controlled Technical Library. The relevant requirements for the freezer derived from M2M-30035 and GP 10037 are specified in the LFS PTRS. However, the launch vehicle(s) and loads applicable to the LFS are not available at this time.

GP 10037 page 121, section 3.3 Launch Environments for Payloads states:

The Gateway elements, including internal and external payloads, will be launched on a variety of commercial rockets and the NASA Space Launch System (SLS). The range of launch load characteristics across potential Launch Vehicles is not bounded at this time; therefore, the launch loads to which all payload hardware will be subjected are not fully characterized. However, heritage experience from the International Space Station (ISS) Program provides realistic boundary conditions relevant to initial Gateway Payload Design.

18 SOW

J-86

DRD RV-05 Per reference documents (See Scope, Content, and Format)

There are no reference documents listed in the References section. What exactly is meant by reference documents here?

DRD will be updated with correct reference documents.

19 SOW

J-86

DRD RV-05 Submission: As required Analysis models shall be provided to NASA and shall be in the following formats:

a. Thermal/Fluid: SINDA-FLUINT, FLUENT, TRASYS, Thermal Desktop® or TSS.

b. Structural: NASTRAN, and FLAGRO/NASGRO.

Analysis software/solvers are listed in this section rather than file formats. I assume this means that if required to submit analysis models, they must be in formats that are compatible with the listed software/solvers. Is this correct?

Correct. If required to submit analysis models, they must be in formats that are compatible with the listed software/solvers.

20 SOW

J-95 J-102 J-108

DRD TD-04

DRD TD-08

DRD TD-15

In the Content section DRD TD-04 lists the EEE Parts List and Analysis as DRD TD-15 and the Engineering Analysis as DRD TD-08. However, the DRD Title of TD-08 (pg. J-102) is Electrical, Electronic, and Electromechanical (EEE) Parts List and Analysis Report. Additionally, the DRD Title of TD-15 is Government Certification Approval Request (GCAR), and isn't related to engineering analysis.

Comment is correct and call outs will be updated in the DRDs.

21 PTRS

A-12

Table 3: Lunar Freezer/Vehicle Interface Requirements

Launch Hard Mounted from Earth* Table 3 indicates that there is a possibility that the LFS may require the capability of powered, hard mounted launch from earth. This decision will have significant impacts on the design of the LFS particularly, if the Freezer must safely withstand vehicle launch abort loads while hard mounted.

Reaching a determination of this TBR capability as early as possible would prove most beneficial.

Concur, the potential for LFS to withstand hard-mounted, powered launch from Earth will significantly impact the freezer design.

The launch vehicle(s) and loads applicable to the LFS are not available at this time. The anticipated timeline to determine the required vehicle interfaces and launch capabilities is during the System Requirements Review (SRR) phase of the LFS project.

For the purposes of the LFS proposal, the Contractor may assume that the LFS will launch soft stowed from Earth. Table 3 in the PTRS will be updated, along with the footnote, to indicate this guideline for the LFS proposal.

22 PTRS

A-63 A-64

LFS-GWY-3.10-

M2M-PLD-

SHOULD-9000

LFS-GWY-3.10-

M2M-PLD-R-9001

Table 10: Soft Stowed Payload Acceleration Loads During Launch

Table 11: Hard Mounted Payload Acceleration Loads During Launch

How likely is it that these acceleration loads will increase beyond the generic 57000 loads prior to delivery of the first unit or during the units' expected lifetime?

The launch vehicle(s) and loads applicable to the LFS are not available at this time. The anticipated timeline to determine the required vehicle interfaces and launch loads is during the System Requirements Review (SRR) phase of the LFS project. Guidance at this point from the Gateway Program indicates "heritage experience from the International Space Station (ISS) Program provides realistic boundary conditions relevant to initial Gateway Payload Design" (GP 10037 page 121, section 3.3 Launch Environments for Payloads).

23 PTRS

A-63 A-65

LFS-GWY-3.10-

M2M-PLD-

SHOULD-9000

LFS-GWY-3.10-

M2M-PLD-R-9002

Table 10: Soft Stowed Payload Acceleration Loads During Launch

Table 11: Hard Mounted Payload Acceleration Loads During Launch

There are rotational loads in Table 10 for Soft Stowed payloads, however, they are not applicable for Hard Mounted (Table 11). Historically, the rotational loads have not been applicable in either case, though they exist in the 57000. Will these rotational loads have to be considered for the LFS? If so, what vehicle is driving the requirement?

Detailed launch vehicle(s) acceleration loads applicable to the LFS are not available at this time. The anticipated timeline to determine the required vehicle interfaces and launch loads is during the System Requirements Review (SRR) phase of the LFS project.

24 PTRS

A-63

LFS-GWY-3.10-

M2M-PLD-

SHOULD-9001

Soft Stowed Hardware Random Vibration Environment During Launch (TBR)

Will the TBD random vibration environments possibly be considered negligible for analysis during launch? With the focus of the random vibration environment for soft stow payloads focused more on qualification/acceptance testing?

Random vibration environments are not known at this time; SSP 57000 ISS Pressurized Payloads IRD Section D.3.1.2 is to be used as reference for anticipated soft stowed payload random vibration environment during launch.

The PTRS will be updated with the random vibration levels to be used at this time for soft stowed payloads.

25 CEV-LD-

11-047

(Referred to in

PTRS

IF.FREEZ.SC.015)

5.4

Figure 5.4.1: X Axis Component Acceleration vs.

Weight

Figure 5.4.3: Lateral Axis Component Acceleration vs.

Weight

The axial and lateral static landing loads here are significantly higher than the requirements in the 57000

(57000 -- X: ± 9.3, Y/Z: ± 1.8/± 1.8 | CEV-LD-11-047 -- 20-50

g's in either direction). How conservative are these values?

Are they expected to drop any closer to the values in the 57000 prior to delivery of the LFS?

The landing loads data in CEV-LD-11-047 was provided by the Orion subject matter experts as the loads requirements for the LFS in the designated location within the Orion capsule. No additional data is available at this time to determine if the values will change.

26 C-32 Hardware Deliverables

LFS Flight Units 4 Based on the Con-Ops presented in the SOW and PTRS, will 4 units be sufficient to support 1-2 permanent Gateway units and logistical units returning from orbit or units being prepared to launch to the Gateway?

With the current Con Ops having the LFS soft stowed for launch, and possibly having 1 unit on Gateway, 4 units will be sufficient.

Rationale: Since the LFS will be soft stowed for launch, there will not be a need for a backup unit at launch which allows for 1 unit soft stowed, one unit on Gateway, 1 unit possibly being refurbished and one unit on a shelf.

27 SOW

C-53

Testing Requirements

Off-gas Testing - NASA WSTF Can MSFC be a test facility for Off-Gas testing? A Marshall Space Flight Center (MSFC) facility may be utilized for off-gas testing, but test facility usage will be dependent on NASA Program agreements, scheduling, etc. The Contractor will be responsible for determining the final testing schedule to meet the hardware testing and delivery milestones.

28 SOW

C-53

Testing Requirements

Pre-delivery Acceptance (PDA) - Qual Unit Table indicates Qual unit delivery to KSC. This should be Flight Units

The comment is correct. Table 6 will be updated to indicate Flight Units as the applicable hardware for Pre-Delivery Acceptance (PDA) testing.

29 PTRS

A-31

5.4.6.8 Radiation

Tolerant Electronics

"Requirement will be reviewed at a later data to capture specific requirement and applicable verification methods. There will likely need to be further clarification on radiation tolerant versus fully radiation hardened electronics, and the associated risk trades for technical, cost, and schedule impacts."

Are proposers expected to provide details for the risk trades associated with selecting radiation-tolerant vs. fully radiation-hardened electronics in their proposal (e.g. as part of the Management and Technical Approach for a detailed description of the mitigation approaches being incorporated to address this technical risk)? Or is this expected to be part of the initial design work after the contract award?

If expected as part of proposal, should the SLS-SPEC-159 DRM "Lunar Surface Sorties" be used when referencing Total Dose and Single Event Effects?

If expected as part of proposal, can any additional guidance be provided for how best to represent these specific trades in the proposal?

A fully radiation hardened architecture is not expected; however, as part of the proposal, the offeror should demonstrate an initial evaluation of hardware that may be sensitive to radiation impacts, identify critical electronics and components, and propose risk mitigation strategies.

Detailed risk trades for radiation-tolerant versus fully radiation-hardened electronics are not expected as part of the proposal. As the design matures, the Government expects a risk-based tailoring of radiation hardened components that take into account mission success, hazard controls, and other programmatic factors (cost, schedule, etc.).

30 SOW

F-1

Delivery Schedule 49 Months after Date of Contract -all items Delivery dates are not consistent with Table 2 Delivery Schedule on page C-12

The Table on page F-1 is for the "delivery" of all completed units. The table on page C-12 specifies that all deliveries should be occuring on month 49. Please do not confuse milestone completion with delivery of hardware. Table 2 on page C-12 will be updated for the Engineering Development Unit (EDU) milestone specifying that is when the "Build" is complete; not to confuse with the delivery of the EDU.

31 SOW

C-53

APPENDIX C:

ANTICIPATED

TESTING AND

VERFICATION

REQUIREMENTS

Radiation (TBD) - Not currently required Should proposers include any descriptions of proposed verification methods for design features/decisions used to mitigate risk to payload due to radiation effects (e.g. as part of the Management and Technical Approach for qualification testing)? Or should proposers wait for further guidance from NASA on anticipated testing & verification methods?

Radiation testing and verification methods are not required as part of the proposal; however, as part of the proposal, the offeror should demonstrate an initial evaluation of hardware that may be sensitive to radiation impacts, identify critical electronics and components, and propose risk mitigation strategies.

Detailed requirements for mitigation of radiation effects as well as radiation testing are anticipated to be further refined during the Systems Requirements Review (SRR) phase of the project.

32 PTRS

Table 2 A-5

Reference Documents

M2M-30038 Is M2M-30038 the common transport Requirements document levied on and across all platforms (HLS, LM, Gateway, Orion) for Payload accommodations? Can this reference document be provided?

M2M-30035: Artemis Payload Interface Definition Document (PIDD) is provided in the LFS Controlled Technical Library on sam.gov. Relevant vehicle interface requirements for the LFS (as a Utilization payload) were derived from M2M-30035 and are provided in the LFS PTRS.

M2M-30038: Moon to Mars Utilization Interface Requirements Document contains requirements specific to the vehicle interfaces (what the vehicle will provide) rather than the Payload (or "user") interfaces.

M2M-30038 is a Reference Document, and "Reference Documents" listed in the PTRS (Table 2) are not provided for proposal development.

33 PTRS

A-60

5.7.2

LFS-GWY-3.3-003

Mounting plate dimensions are un-readable in the M2M- 30035 document. Pg 62

Upon contract award, the latest revision of all applicable technical documents will be provided to the Contractor. The PTRS and vehicle interface requirements will be reviewed and finalized as part of the System Requirements Review phase of the LFS project.

34 PTRS

A-52

5.7.1

LFS-GWY-3.2-015

The LFS shall adhere to the requirements and guidelines in NIST Special Publication 800-53, Security and Privacy Controls for Federal Information Systems and Organizations.

Can a defined list of specific controls be provided?

Complying with all controls in 800-53 would likely have significant cost and schedule impacts.

A specific subset of the controls will be provided during the SRR phase of the project based on the Gateway implementation package currently being worked at the Moon to Mars Program level.

35 A-58

AND

A-84

LFS-GWY-3.2-043

AND

LFS-HLS-006-009

Payloads shall maintain surface temperatures within the habitable volume to at least 5°C greater than the internal atmospheric dew point within the pressurized cabin.

AND

The LFS shall operate within the habitable volume temperature and humidity during all nominal pressurized operations when crew occupies Integrated Lander cabin per Operating Limit in Figure 11 .

Is the intent that the LFS payload shall provide the capability to heat the external surface above the ambient dry bulb temperature or is it acceptable for the external surface temperature to always be slightly below the ambient dry bulb temperature?

LFS-HLS-006-009 states that the maximum dry bulb temperature of the gas inside the cabin is 25.7C with a maximum relative humidity of 75%. The dewpoint at these conditions, assuming 15, psia is 20.9 C. LFS-GWY-3.2-043 states that the surface temperature must be at least 5C greater than the dewpoint. This means the surface temperature must be at least 25.9C which is greater than the ambient dry bulb temperature (25.7 C).

The intent is of requirement LFS-GWY-3.2-043 is to prevent condensation on the outside of the hardware, not that the LFS payload shall heat the external surfaces. The method for preventing a significant temperature delta between the LFS hardware surface temperature and the pressurized cabin atmospheric temperature will be dependent on the freezer design.

Since the LFS will utilize air cooling, and the LFS cold volume will be exposed to ambient air during sample insertions or transfers, the intent of requirement LFS-HLS-006-009 is to show the range of temperatures and relative humidity that the Integrated Lander will operate.

36 A-83 LFS-HLS-006-006 The LFS shall ... annunciate these conditions Does this mean audibly announce, or via local and remote notification (i.e., through the display screen)?

The LFS hardware should provide the option for both audible alarms/annunciations, as well as via local and remote notifications though the display screen. More definition for the requirements will be determined during the System Requirements Review (SRR) phase.

Rationale: There will be times during the missions where ground teams may not have telemetry between the vehicle and ground. Therefore, ground teams may not receive the data or remote notification, and will not be able to notify crew. Due to the criticality of the conditioned lunar samples, the audible annunciation is expected, with the option to disable the feature as needed or desired during certain phases of the mission.

37 A-25 5.4.1.4 The LFS shall maintain conditioned samples at a specified temperature, while operating with a heat output of no more than 100W using air-cooling.

Is the 100W of heat rejection a peak thermal power limit or is this the time averaged thermal rejection limit?

The 100W of heat rejection is a time-averaged thermal rejection limit, as the power draw and heat rejection may vary over time (TBR).

Rationale: The LFS heat output should minimize the impact to the crew cabin air temperature (e.g. significant warming over time), especially during transit inside the Orion Crew Module.