EPOC System and Work Statement Requirements Strategy Whitepaper.pdf

EPOC System and Work Statement Requirements Integrated Strategy

Introduction

The Exploration Production and Operations Contract (EPOC) will procure SLS launch services from a Commercial Provider that meets the Artemis Mission performance requirements while maintaining safety through a certified design baseline and support of the integration, test, check out, and operations. The System Requirements ensure that the flight articles, that will be used to perform the launch service, continue to be designed, manufactured, and operated to meet these safety and mission needs. The System Requirements Document (SRD) works together with Performance Work Statement (PWS) requirements to ensure that the EPOC Provider is performing the requisite functions for each mission and that changes to the system meet the standard established by the SRD. NASA’s goal for procuring these launches as a service is to enable the Provider to have control of the design and production, while retaining key requirements that provide NASA assurance that future changes to the system will be made in consideration of NASA’s proven safety standards. The following sections will provide an overview of the strategy for the requirements in the EPOC SRD, NASA’s expectations for how the EPOC Provider will build upon the SLS development efforts, and how NASA will use insight, partnered with some oversight, to ensure element changes are verified and manufacturing issues are resolved.

Requirements Strategy

A range of SRD options are being developed from the heritage SLS System Specification SLS- SPEC-032 that will be used to develop and certify the SLS Crewed Block 1B for transporting the Orion Spacecraft and accommodating co-manifested primary and secondary payloads. As the Crewed Variant is the only vehicle required to execute the initial lunar campaign, those performance requirements are the focus for the EPOC base contract. While NASA can foresee the need for a cargo version of the SLS in the future, it is expected that the EPOC Provider will serve other customers in the nearer term, and thus NASA will look to leverage the market-driven capability to the maximum extent rather than specify unique cargo requirements. While greater lift capability could be leveraged in the future, rather than set a requirement in the SRD, an evolvability plan will be requested to show a path to 130 t to LEO capability in 2032, based on prior development efforts and flight experience.

With the EPOC base contract focused on the Crewed Variant, the performance requirements ensure mass-to-LEO, mass-to-TLI, and TLI specific energy are maintained. Also, TLI accuracy is retained as a requirement, as the Orion’s ability to make up insertion errors is limited. Further performance requirements include specific payload accommodations for the large co-manifested payloads (e.g.

volume, critical dimensions, and cleanliness), as well as smaller secondary payload allocations. Finally, a minimum production rate is set at one Crewed Flight per year, to round out the performance requirements.

As safety is NASA’s top priority, the seminal Human Rating Requirements are retained, as well as the Design and Construction Standards. These serve as a check upon design changes to ensure robustness to the launch environment, new failure modes are considered and mitigated, and appropriate operational instrumentation is available to support ground and flight crew activities. While the design solutions are solely the EPOC Provider’s, the safety requirements ensure the minimum failure tolerance, margins, and testing are applied. It should be noted that the Design and Construction Standards are invoked by the statement, “shall comply with the intent” and are referred to as Tier 2 documents. This will be partnered with an activity for the EPOC Provider to submit any proposed alternates for approval by NASA. Once approved, the Provider’s alternative will supersede the NASA Standard, but the requirement to meet the alternate standard will still be held by NASA and impacts to the standard verification resulting from design changes will be evaluated.

Recognizing that the SLS is only one system in the Moon-to-Mars architecture, the interfaces with external systems will round out the minimum requirement set. Interface requirements and Interface Control Drawings are invoked by a requirement to “meet” and are referred to as Tier 1 documents. For these, no alternatives are to be submitted, rather there is an expectation that the EPOC Provider will work with the owning/joint-owning organization to partner any changes to these documents. All change requests will be reviewed in good faith for net improvements of safety, performance and affordability, and NASA will support the Provider in adopting those changes deemed, as such.

While the prior paragraph describes the minimum set, NASA is also considering levying the latest SLS-SPEC-032 in its entirety. This is a known comprehensive baseline, represents what the design is certified to at handover, and presents the lowest risk to unforeseen gaps in the needs. Figure 1 illustrates the breadth of these options and how NASA has moved the line of control it operates under today to options for a services-based approach under EPOC. In all scenarios, the strategy is to enable the EPOC Provider the greatest breadth of Design and Change Control, while retaining key elements of our safety, performance, and interface requirements, to enable NASA to certify for each flight that the changes made to the SLS since certification have been controlled to acceptable standards and meet the required performance and interface agreements. In the following section, the insight/oversight approach and how it will complement the Performance Work Statement will be described. Requirement types that could be descoped from the System Requirements Document are considered, which allows further control by EPOC Provider, but still enables NASA insight.

Figure 1: Shift in Requirement Control under EPOC

While most of NASA’s effort will be ascertaining risk through this insight, NASA will require verification updates to System Requirements impacted by design or operational changes. These updates will be made with methodologies proposed by the provider but must meet the intent of the existing SLS Verification Plan. This will offer some flexibility while maintaining minimum expectations for these activities.

NASA Insight/Oversight Strategy

While the prior section illustrated the shift in Provider control over the requirements baseline, the transition of this baseline will be managed through the hand-off by ensuring 1) Provider processes are adequate to manage the requirements and risk throughout the product hierarchy, 2) the Provider is starting with NASA’s Artemis IV Block 1B certified baseline, 3) common expectations for data access and NASA insight activities to support risk assessments, and 4) Clear milestones for demonstrated work completion in support of a flight. NASA has adopted an approach for minimizing requirements and deliverables with the expectation of relying on insight guided by its experience with the design to implement a risk-based approach to risk identification and mitigation. NASA believes that while its requirement set is narrower under EPOC, the requirements retained provide sufficient coverage to ensure design changes and the flight build are managed effectively.

Early in the contract, the Provider will hold a Certification Baseline Review to demonstrate processes are defined, mission integration and cross program integration plans are defined, agreements with supporting and associate contractors and programs are in place, and the plan to the first mission is well-defined. Of Particular importance is recognizing that much of the mission integration work occurs across programs and partnering a system that is flexible enough to jointly resolves issues is paramount.

Opportunities for further reduction of requirements from the baseline SLS-SPEC-032 hinge on an understanding of the EPOC Providers technical management processes in key areas. These processes will focus on requirements and change management plans that will provide NASA confidence that as requirements move from above the line of NASA control to below the line, that the required functions are covered. If these requirement types are descoped from the SRD, while not within NASA control, the capabilities remain within the design at transition, and NASA will rely on alternative requirements or processes to ensure top-level capabilities are reliably delivered. A few examples of how the requirements could change in EPOC:

- Internal (Primitive) functions to the SLS would not be held at the NASA-level. If the provider wants to maintain a trace of these functions in their specification, the top-level performance might be the best parent. An example would be to provide timekeeping synchronized with the ground. While required for DDT&E to reach the current architecture, under EPOC, the timekeeping is a primitive function for operation to be maintained by the Provider, and the synchronization with the ground is enforced through the Tier 1 GSDO-to-SLS ICD. A software development plan will be a required CBR product and be used to support NASA insight into how software changes are implemented and verified to ensure timekeeping integrity.

- Similar to primitive functions, general external functions such as, Accept and Execute Commands from Orion, GSDO, Mission Systems and Range could be removed. The rationale is that the specific agreed to Commands have been articulated and levied via the IRD’s and ICD’s, which remain Tier 1 requirements.

- Since the overarching Safety requirements (e.g. failure tolerance, detect and isolation of faults) were retained, further derived requirements for specific controls could be removed.

Current requirements preclude the accumulation of hazardous gases. The design features that accomplish this will be in the design and operation at transition. Rather than manage this through a requirement, there will be a general PWS activity for the EPOC provider to maintain the hazard analysis and hazard reports for the life of the program. Through insight, NASA will evaluate whether the Provider is identifying impacts to hazard controls and maintaining compliance with top-level requirement to not only control hazards but show failure tolerance to those controls. An S&MA Plan that in-part addresses how hazard analyses are maintained will be a CBR deliverable.

- Several of the Tier 1 documents, such as the design environments, are necessary to support requirements in the IRD’s, as well as, standards, such as SMC-S-016 Test Requirements for Launch Vehicles and Upper Stages (i.e., the qualification and acceptance standard).

However, rather than mandate these design environments, they could be delegated to the Provider to maintain within their loads control process. A Loads Control Plan will be a deliverable at CBR to ensure it has been integrated across programmatic stakeholders and highlights the authoritative source that has been agreed to by all parties for future missions.

This ensures a low-risk starting point, while allowing the EPOC Provider to work changes directly with stakeholders rather than through NASA/SLS Program approval.

- Several design requirements used to ensure operational robustness and mission availability could be de-scoped from the SRD, if NASA can rely upon financial incentives of on-time reliable launches to motivate the provider to make the right trades in maintaining these design features. Examples are support of a launch ready hold, generally used to troubleshoot problems that could clear a vehicle for on-time launch or provision of internal access to enable on-pad removal and replacement of LRU’s. Both capabilities are in the design today but could be delegated to the EPOC Provider to manage.

- There are many system-level allocations to the SLS Elements that guided the overall design and integration. Control masses and usable propellant are necessary to ensure overall flight performance and controllability. While NASA will leverage the top-level performance requirement verification to ensure the system remains controllable and capable, it should not dictate how those masses will be managed. Either a standalone plan or an element of the risk management plan will describe how the Provider manages margins, so that NASA can follow changes and assess risks as the design evolves.

- In the vein of element management, many of the current requirement allocations are reliability targets that support the overarching NASA safety thresholds for mitigating probability of Loss of Crew and Loss of Mission. NASA will have certified these elements to their reliability requirements prior to transition. However, after transition, while NASA will continue to evaluate the overall probabilistic safety analysis of the mission, NASA could use insight to maintain the SLS model consistent with any design changes. NASA is confident that the provider will use industry best practices of reliability engineering to ensure the best possible design outcomes but could consider this reviewing this through insight rather than a deliverable codifying that work.

Achieving a Robust Insight Capability:

Because NASA’s assessment and management of risk is heavily reliant upon insight, the Provider will be required to submit an Insight Implementation Plan that will detail the cooperative environment that ensures completion of the work and resolution of the issues. Particularly, this will describe how timely and open access will be made to technical data and plans, insight into technical management, and technical issue resolution.

Insight provides the Government an understanding of the Provider’s activities and data, particularly an understanding of technical progress, schedule performance, and how the Provider is managing risks while successfully completing contract requirements and achieving final NASA certification. Insight is not approval or disapproval authority but may provide information for the Government to use in, and expedite, approvals otherwise contemplated by this contract.

The Insight Implementation Plan will document the partnered approach to how NASA will perform insight and gain access to data and physical locations without being encumbered by narrow definitions of what constitutes insight or surveillance activities. The plan should include an authoritative POC that provides an interface to ensure the quick coordination required to eliminate any risk to cost or schedule. The plan will require a clear pathway for communication to ensure insight is robust and may include effective strategies such as broad data access, resident office support, or streamlined relationships between key Provider and NASA engineers. These strategies are currently being used effectively in commercial manned spaceflight and should be benchmarked to develop a strong insight plan.

To Enable this, the Provider needs to provide NASA access to: (1) Any aspect of the design, analysis, testing, schedules, performance metrics, risks, and management processes of the SLS and its individual elements, integrated systems, subsystems, or components; (2) Launch vehicle and launch site operations such as, spacecraft-to-launch vehicle integration, launch commit criteria; (3) products and data in support of flight and mission operations, flight plans, trajectory and mission design, real-time operations, and any non-NASA services performed by the Provider.

Insight Implementation for NASA participation in Provider activities will include the following to ensure insight:

(1) Sufficient notification to enable NASA participation in program events, or development, test and build activities.

(2) Notification of qualification or test anomalies, as well as problem or discrepancy reports on vehicle systems’ failures and anomalies. This includes insight into issues such as, fleet-wide problems, anomalies, Material Review Board actions, component or element deviations, and test equipment including those used on non-NASA missions.

(3) In the event of an anomaly, launch or mission failure, the Provider will support NASA’s mishap investigation, or will allow NASA to fully participate in the Provider’s Mishap Investigation Board or equivalent entity, including those for non-NASA missions that utilize the same space transportation vehicles

If, through insight, the NASA Insight Team observes any of the following: Provider noncompliance with requirements or the other elements of the contract; a difference in interpretation of test results; or disagreement with the Provider’s technical approach, the NASA Insight Team will elevate the issue through the appropriate control boards. Through an effective, functioning relationship, the Government and Provider should strive to resolve issues at the lowest working level and minimize issues elevated to program boards. Program boards will disposition recommendations in a timely manner and provide oversight resolution if necessary. Resulting board decisions and direction will be transmitted to the Provider through the Contracting Officer. If disposition results in a requirement change, the contract changes clause will govern. If the Provider and Contracting Officer disagree on whether the board disposition provided is within the requirements of the contract, the contract disputes clause will govern.

Flight Operations Support

The provider will support flight operations through: Mission planning and trajectory assessments, including timelines, DOLILU and Aborts Integration; Delivery of a Mission Operations Data Package that documents SLS system behavior, performance and limits; Contribute to the development and maintenance of Flight Operations products (Flight rules, procedures, etc.); Support Crew and Flight Control Team training and simulations, to include maintaining Block 1B simulator; an Operational Readiness Assessment; Engineering support of Mission Execution; and A post-flight report of mission performance, flight anomalies, and anomaly resolution actions.