SASS II DRFP Questions and Answers.pdf

5 Section M Evaluation Criteria

M.1 M-2 Clarity The DRFP offers no qualifying language to understand Cost/Price advantage required to overcome a difference in Past Performance confidence ratings. Cost should be at least as important as Past Performance to allow for efficiencies to be considered.

According to M-1 (f), "Past Performance is more important than Cost." NASA has carefully considered its evaluation scheme and believe the existing criteria appropriately reflects the importance of the factors in the

DRFP.

6 Section M Evaluation Criteria

M.2 M-2 Clarity No technical or management capabilities or approaches (“Mission Suitability”) can be considered for scoring or comparison in the evaluation model (see comments on Technical Acceptability).

The technical and management capabilities are evaluated as Pass/Fail in Subfactor A:

Specific Technical Understanding and Resources of the STO and Subfactor B:

Management Approach. This Pass/Fail approach will determine whether an Offeror has the requisite ability to perform the requirements of the Statement of Work (SOW). Regarding the trade-off between Past Performance and Cost, the evaluation scheme allows an offeror's past performance on contracts of similar size, scope, and complexity to be considered.

7 Section M Evaluation Criteria

Attachment J-2

J-7 Clarity Key personnel are evaluated as part of Past Performance providing incumbent with an inherent advantage using existing key personnel: Program Manager, Advanced Software Technical Lead, Simulation and Graphics Technical Lead (Simulation and Graphics are not typically bundled into a single key person in industry and appears to presuppose an organizational structure (and likely personnel) skewed to the current arrangement with the incumbent).

According to M-3 (a), "The evaluation team will evaluate the past performance of the offeror, team members, proposed Program Manager, Advanced Software Technical Lead, and Simulation and Graphics Technical Lead as defined in L.18.5."

To accommodate the stated concern that "Simulation and Graphics are not typically bundled into a single key person in industry," the government anticipates the Contract Management Plan Data Requirements Description (DRD) Section. B-2 (g) will be updated in the FRFP to reflect the following update, "The contractor may propose the same individual or any combination of individuals for all Key Personnel positions identified in Section H.4. "

8 Section M

Criteria

M.3 M-3 Clarity Key personnel evaluation criteria should focus on applicable skills, not existing specific contract content execution.

According to M-3 (a), "The evaluation team will evaluate the past performance of the offeror, team members, proposed Program Manager, Advanced Software Technical Lead, and Simulation and Graphics Technical Lead as defined in L.18.5."

According to L.18.5 (b), "For those individuals proposed as Program Manager, Advanced Software Technical Lead, and Simulation and Graphics Technical Lead listed in Clause 1852.235-71, Key Personnel and Facilities, the Offeror shall provide their résumé details as prescribed in Attachment L-4, Key Personnel Resume.

Provide information from organizations and companies for which the Program Manager, Advanced Software Technical Lead, and Simulation and Graphics Technical Lead have previously performed work relevant to the SASS II SOW from the past 3 years in order for the Government to obtain appraisals of past performance via the Key Personnel Resume in Attachment L-4.

References with Government contracts are preferred, but not required.

Key Personnel with no past performance experience shall so state."

Proposed key personnel applicable skills will be evaluated based on demonstrated past performance in the applicable contracts identified, key personnel resumes, past performance questionnaires, and interviews.

9 Section L Proposal Instructions

Attachment L-2

L-51 - L-63 Clarity Section L Past Performance Questionnaire includes very specific technical content relevancy that places greater weight on the incumbent contract which is the only effort that can meet all relevancy criteria.

The purpose of the past performance questionnaire is not to focus on the current Simulation and Advanced Software Services (SASS) Contract. The past performance questionnaire focuses entirely on the work required of the SASS II Contract. Past performance questionnaires will be reviewed to determine if an Offeror has similar experience that will allow the Offeror to successfully perform the SASS II requirements.

10 Section L Proposal Instructions

L.18.5 L-23 Clarity No explicit evaluation language indicating non-incumbent offerors can aggregate their past performance across multiple contracts to demonstrate piecewise relevance to the entire SOW and Very High Confidence Level with contracts of smaller size while separately demonstrating the proposed Prime’s ability to manage this size and complexity of contract to a Very High Confidence Level.

- Very unlikely there are any other single contracts with nearly identical SOW content, size and complexity to achieve highest relevancy rating;

consideration for aggregating Past Performance citations is necessary.

Section L 18.5 (e) requires offerors to submit relevant contracts where the offeror and subcontractors demonstrate past performance for the SASS II work. Therefore, the DRFP explicitly calls for multiple contracts to demonstrate relevance to the entire SOW.

Section L 18.5 (f) provides a past performance matrix (Attachment L-5) for the explicit purpose of providing an aggregate view of total past performance. The DRFP does not expect or require a single past performance contract covering the complexity of the entire SASS II SOW. The DRFP specifically calls for multiple contracts for the purpose of evaluating past performance.

11 Section L Proposal Instructions

L.18.5 L-22 Clarity Major subcontractor threshold of $8M eliminates minor subcontractors that could add to a non-incumbent offeror’s SOW relevancy and coverage (especially for aggregation toward total SOW coverage).

- Effectively "forcing” all partner company workshare contributions to $8M threshold in order to be eligible for consideration in Past Performance would require mismatching allocated content because it is inconsistent with contemplated SASS II contract work scope distribution and specific partner company skills and capabilities; this would result in arrangement that does not offer the government the best possible solution or value and effectively discourages niche skill contributors from being included.

- Incumbent can claim Past Performance of all currently (and previously) performing subcontractors regardless of major/minor subcontractor threshold because of their Prime status.

The definition of a major subcontractor, per the DRFP, is $8M of the total Not-to-Exceed $150M value of the SASS II contract. This definition equates to less than 6% of the total $150M contract. This percentage is already lower than the nominal definition of a major subcontractor at 10% of the total contract in most NASA contracts. NASA has carefully considered altering this definition and believes the existing definition demonstrates a deliberate good faith effort to open competition to all interested offerors.

12 Section M Evaluation Criteria

L.18.4 L-15 - L-21 Clarity Pass/Fail criteria of Technical Acceptability approach combined with Past Performance emphasis doesn’t allow for innovations to receive credit or consideration (i.e., NASA is seeking status quo understanding which is best presented by incumbent rather than considering opportunities for change).

The SLPT approach requires that the technical acceptability be evaluated as pass/fail. This evaluation of technical acceptability is entirely separated from past performance and cost evaluation. The NASA Acquisition Strategy for this acquisition was determined to be an SLPT approach by the source selection authority. The SLPT approach was considered of more benefit to the government in the form of a streamlined acquisition than focusing on innovation.

13 Section M

Criteria

L.18.4 L-15 - L-21 Clarity For a complex SOW, evaluation approach should allow for consideration and scoring of technical and management capabilities as well as commercial approaches, opportunities, efficiencies and other innovations (“Mission Suitability”).

- NASA, and the space industry have drastically changed since SASS I was competed and awarded, including available technology, greater emphasis on commercial practices and partnerships, and the need for greater efficiency.

See response from Question 12.

14 Sample Task Order (STO) requirements

STO L-41 - L-50 Other 2 of the 5 STOs have similar titles and content to STO from previous SASS competition giving incumbent inherent advantage in compliance and preparing submission.

- SASS II STO 3 is substantially similar in content (over ~75%) to

SASS I STO 2.

- SASS II STO 5 is substantially similar in content (over ~80%) to SASS I STO 8 (one new bulleted item).

- Government Resource Estimate (GRE) for STOs not provided in

DRFP.

The STOs were developed to represent the overall scope of the SASS II SOW. The STOs are realistic and representative of the SOW. Because they cover such a wide range of SOW elements, they are not task orders that would be executed. The Government anticipates modification of STO 3 and 5 to be less similar to SASS. The government anticipates addition of the GRE for all STOs.

15 Sample Task Order (STO) requirements

STO 1 L-41 Clarity 1.2 is poorly defined. The purpose isn’t clear, is this an engineering sim to evaluate Gateway design, or a dummy-vehicle sim to interface with an Orion or Human Landing System (HLS) sim?

Or both? The list of required components is vague:

Guidance Navigation & Control (GN&C) – in what context? GN&C flight software? GN&C interfaces?

Power and propulsion system – there’s no context for the anticipated fidelity, which is relevant to both and especially relevant on the power system.

Habitat – is there an implied Environmental Control and Life Support System (ECLSS) requirement?

Or just the presence of the hab-module as part of the stack?

Functional Flight Software (FSW) – unclear whether this implies the sim needs its own generic FSW (dummy-vehicle sim), or an interface to Gateway’s FSW (gateway-evaluation sim).

The purpose of 1.2 is for the offeror to demonstrate how it would develop a simulation of the Gateway vehicle stack in the specific orbit stated. There are no additional requirements to simulate, and the Gateway vehicle sim design selection will not be evaluated as part of the technical criteria for this STO response. However, Subtask 1.3 calls for the Gateway vehicle sim to interface with HLS sim. Systems such as GN&C, FSW, etc should be addressed in relation to the offeror's proposed simulation.

Per the DRFP, the offeror shall state its assumptions when proposing. The assumptions may address GN&C, Power and Propulsion system, and Habitat requirements, etc. As for the habitat, the offeror shall assume the vehicle is inhabited.

16 Sample Task Order (STO) requirements

STO 1 L-41 Clarity 1.3 similar questions as 1.2 except for the presence of Human-in-the-loop ( HITL) controls and displays; are HITL controls required for controlling vehicle or all aspects of crew interactions?

See response from Question 15. Regarding HITL controls and displays, the intent for the STO1 Subtask 1.3 is for HITL controls to address all aspects of controlling the vehicle with respect to the Rendezvous and Proximity Operations, Docking and Undocking (RPODU) with the Gateway Vehicle Stack simulation described in Subtask 1.2 above, Descent, Deorbit, and Landing (DDL), and Ascent flight phases identified in Subtask 1.3.

17 Sample Task requirements

STO 1 L-42 Clarity 1.5 is “a vehicle” to be interpreted as a generic vehicle (proof of concept) or a specific vehicle?

1.3 and 1.5 specifically call for a Trick-based simulation but 1.2 and 1.4 do not. 1.5 implies an extension of 1.2 or 1.4. Are all simulations to be “Trick-based”?

With regard to Subtask 1.5, the "vehicle" can be a generic vehicle or specific vehicle at the offeror's discretion.

The government anticipates modifying subtask 1.2 to include "Trick-based". All simulations in STO 1 are Trick-based.

The government anticipates removing subtask 1.4.

18 Sample Task Order (STO) requirements

STO 1 L-41 Clarity Is it NASA's expectation that the HLS Vehicle Simulation (1.3) be fully developed within nine months (October 1, 2025 - June 30, 2026)?

The government anticipates to modify the delivery of the 1.3 HLS vehicle simulation to be updated from October 1, 2025 - June 30, 2026 to October 1, 2025 - September 30, 2026.

19 Sample Task Order (STO) requirements

STO 1 L-41 - L-42 Clarity Please clarify if any proprietary models, datasets, or assumptions are referenced that could give certain offerors unequal access to information.

If so, we request these materials or standardized assumptions be made available to all bidders to ensure fair competition.

There are no proprietary models, datasets, or assumptions referenced for STO 1. Per the DRFP, the offeror shall state its assumptions when proposing their response to demonstrate their technical understanding of the STOs.

20 Sample Task Order (STO) requirements

STO 1 L-41 Request for additional information

For Section 1.3 HLS Vehicle Simulation, could NASA provide more detailed information about the expected integration with existing simulation environments, such as compatibility with specific tools or models?

Specific tools that are called out are Trick and JSC Engineering Orbital Dynamics (JEOD). These tools are open source and are identified in the technical library. For graphics rendering, Graphics for Exploration (EDGE) and DOUG are also called out as possible tools which are also detailed in the technical library. However, as specified in STO 1, any commercial graphics rendering tools will be acceptable. For STO 1, no specific models are required. For STO 1, the offeror does not have to integrate with any existing simulations.

21 Sample Task requirements

STO 1 L-41 - L-42 Clarity Could NASA confirm whether all bidders will have equal access to datasets, modeling software, and proprietary information referenced in the STO?

NASA confirms that no datasets are required in the Sample Task Orders. NASA confirms that no modeling software is required in the Sample Task Orders with the exception of Trick and JEOD. Trick, JEOD, EDGE, and DOUG are all referenced in the technical library. Trick and JEOD are open source.

EDGE and DOUG can be acquired through a software usage agreement per the technical library. However, all graphics rendering can be accomplished with any commercial graphics rendering tool. NASA confirms that no proprietary information is referenced in the STO.

22 Sample Task Order (STO) requirements

STO 1 L-42 Clarity For Section 1.5 In-Orbit Robotic Operations Simulation, are there assumptions or limitations on orbital dynamics, structural flexibility, or coupling models that bidders must adhere to?

Regarding Section 1.5, the orbital dynamics requirements are related to the "lunar near rectilinear halo orbit" specified in the STO.

There are no STO structural flexibility or coupling models requirements that the offeror need to adhere to. Per the DRFP, the offeror shall state its assumptions when proposing. The assumptions may address any considerations regarding structural flexibility or coupling models as desired by the offeror to demonstrate their understanding of the

STO.

23 Sample Task Order (STO) requirements

STO 1 L-41 - L-42 Clarity Will NASA provide access to prior deliverables or reference materials related to HLS and Gateway simulation development to establish a baseline for bidders?

NASA cannot provide deliverables related to HLS and Gateway simulation development.

The purpose of specifying the HLS and Gateway vehicles is intended to provide context for STO 1. The information needed to respond to the STO is in the public domain (e.g. context for the spacecraft and mission requirements) and technical library (e.g. analyses tools to perform the task).

24 Sample Task Order (STO) requirements

STO 1 L-41 - L-42 Clarity For task orders that require integration with external systems (e.g., Gateway), could NASA provide specific Application Programming Interface (API)s or interfaces to be used during development?

No STO requires integration with any external systems.

25 Sample Task requirements

STO 1 L-41 - L-42 Request for additional information

Would NASA consider adding a list of assumptions to each STO to ensure consistency in bidder responses?

No specific assumptions are needed for any of the STOs. All information needed for each STO is provided in the task order description. Per the DRFP, the offeror shall state its assumptions when proposing to demonstrate their understanding of the STO.

26 Sample Task Order (STO) requirements

STO 2 L-43 Clarity 1.1 not clear whether the “motion platform” is included in here, or whether this task ends with the interface to a “motion platform”.

The government anticipates amending STO 2 to remove "motion platform." The new language is anticipated to be "This simulation shall also output data including but not limited to simulation time, position, vehicle attitude, velocity, and acceleration."

27 Sample Task Order (STO) requirements

STO 3 L-45 - L-46 Request for additional information

Overview - Are there examples of existing engineering tools that are being referenced that could be provided?

Could additional tools be introduced if they offer novel or improved solutions in context of the existing portfolio of work and this task order?

Examples of existing engineering tools that are being referenced to this STO 3 can be found in the system descriptions from the technical library. "OpenSim" can be found on https://simtk.org/projects/opensim and https://opensim.stanford.edu/. "Trick" can be found on https://github.com/nasa/trick.

The offeror may offer novel or improved solutions as long as those novel or improved solutions meets the requirements specified in the STO.

28 Sample Task Order (STO) requirements

STO 3 L-45 Clarity 1.1 Requests contractor to demonstrate a basic understanding of motion capture and force plate data capture and ability to account for artifacts in inherent facility, without indication of specific data of interest. This becomes important for section 1.2, as 1.2 portion of the task requires the output from 1.1.

The specific data of interest required in the motion capture of Subtask 1.1 is the data necessary to generate the biomechanics modeling of Subtask 1.2. Part of demonstrating technical understanding of Sample Task Order 3 is for the offeror to determine what data is necessary from Subtask 1.1 to be used in Subtask 1.2. For example, markers placed on the arm of the test subject could be used to motion capture the movement of the elbow at the test subject exercises with the Exploration Exercise Devices (EED).

29 Sample Task requirements

STO 3 L-45 Clarity 1.2 Unclear what output from task 1.1 would indicate successful demonstration, given the dependency for data output to support tasks in 1.2, item 1.1 isn’t really a demonstration, it expects a product.

Subtask 1.1 deliverable is a demonstration of a process that produces a product. The successful demonstration of Subtask 1.1 is providing a technical understanding of the process by which the data is collected. The process by which the data is collected must produce data of sufficient quality for the Biomechanics Modeling required for Subtask 1.2.

30 Sample Task Order (STO) requirements

STO 3 L-45 Clarity 1.3 For this task order does NASA have an expectation that the contractor will have structural analysis (loads and acceleration) skills, or would this data/expertise be supported by NASA personnel with the task focused on the integration of the human considerations for the modeling and determination of forces and moments?

The STO does not require the contractor to have structural analysis skills. The STO requires a simulation that captures the loads (forces and moments) of the Vibration Isolation and Stabilization (VIS) System imparted on the vehicle. For the purpose of this STO, structural analysis is a government function.

31 Sample Task Order (STO) requirements

STO 3 L-45 Clarity 1.4 It reads as if this task is intended to consider/focus on the human use/impact of EEDs because vehicle is not to be simulated. If this is the case, how would 1.3 be fully integrated into

1.4 if the vehicle is not simulated?

How would the effects of EEDs be depicted on the vehicle in this scenario to be able to demonstrate integrated simulation?

STO 3, Subtask 1.4, integrates the modeled human as described, the EED, and the VIS.

The fully integrated simulation is between these three elements. The vehicle itself is not simulated and is part of the integrated demonstration only to provide visual context to the human/EED/VIS integrated elements.

For the purposes of visualization, the interface between VIS and the vehicle is fixed (i.e., rigid).

32 Sample Task Order (STO) requirements

STO 3 L-45 - L-46 Clarity Given the previous question, what would constitute a successful demonstration if not all aspects of each element are being simulated in an integrated fashion and the vehicle is visualization only. Would there be a heavier focus on the data vs. the simulation?

Successful demonstration of the STO 3, Section 1 is the integrated nature of the human/EED/VIS interacting together. The visualized vehicle is the background/context for the active parts of the simulation. There is no heavier focus with regards to data vs.

simulation. Since the data drives the simulation and visualization, and the simulation is used to address loads imparted by the EED/VIS as well as states, both the data and the simulation together are instrumental to providing the validated output.

33 Sample Task requirements

STO 3 L-46 Clarity Section 2 - There is an expectation to develop tools as well as maintain, does NASA have specific ideas/expectations as to what tools would be developed?

It is unclear if this is merely a reference to the integration work in both sections that would be an outcome of all these tasks or if this is something else.

The tools to be developed are integrated models of human biomechanics with upper extremity offload systems. The tools can be developed in OpenSim or the simulation environment of the offeror's choice. There is no integration requirement between STO 3, Section 1 and 2. Per the DRFP, the offeror shall state its assumptions when proposing to demonstrate their understanding of the STO.

34 Sample Task Order (STO) requirements

STO 3 L-46 Clarity 2.2 Is the contractor’s focus to provide the impact of the suited crewmember to the vehicle vs. managing the vehicle simulation development to account for the suited crewmember or both?

Would the contractor be supported by NASA existing data/tools and or expertise or be expected to supply engineering expertise? Dependency

STO #2, 1.2

There is an error in the DRFP, STO 3 Subtask 2.2. The references to STO 2 should be Subtask 1.1 instead of Subtask 1.2. The government anticipates making this correction with the release of the FRFP.

STO 3 Subtask 2.2 requires analysis of the suited crew member affects vehicle stability and handling. The offeror must address the incorporation of their human model with the vehicle simulation development in STO 2 Subtask 1.1. Regarding the interaction between the human model and the vehicle simulation developed in STO 2 Subtask 1.1, the offeror is responsible for interaction between human model and the effect of the vehicle simulation. The government is responsible for analysis beyond this interface. For example, any structural analysis of the impact of the human model on the structural integrity of the vehicle is a government function.