EHP-10098_SW_Rev A_Final CUI.pdf

CUI

ATTENTION

Use this space to indicate categories, limited dissemination controls, special instructions, points of contact, etc., if needed.

ATTENTION

All individuals handling this information are required to protect it from unauthorized disclosure.

Handling, storage, reproduction, and disposition of the attached document(s) must be in accordance with 32 CFR Part 2002 and applicable agency policy.

Access to and dissemination of Controlled Unclassified Information shall be allowed as necessary and permissible to any individual(s), organization(s), or grouping(s) of users, provided such access or dissemination is consistent with or in furtherance of a Lawful Government Purpose and in a manner consistent with applicable law, regulations, and Government-wide policies.

Standard Form 901 (11-18) Prescribed by GSA/ISOO | 32 CFR 2002

CUI

This publication does not contain information which falls under the purview of the U.S. Munitions List (USML), as defined in the International Traffic in Arms Regulations (ITAR), 22 CFR 120-130, nor the Export Administration

Regulation (EAR), 15 CFR 730-774, and is not export controlled. Release to the public requires approval through the appropriate NASA Release Process (e.g., FOIA, NASA STI, etc.).

EHP-10098

REVISION A

National Aeronautics and Space Administration EFFECTIVE DATE: SEPTEMBER 23, 2025

LUNAR SURFACE INTEGRATION PHASE

SOFTWARE INTEROPERABILITY SPECIFICATION

Verify that this is the correct version before use.

Revision: Revision A Document No: EHP-10098 Release Date: SEP 23 2025 Page: 2 of 62 Title: Lunar Surface Integration Phase Software Interoperability Specification

This document does not contain export-controlled information. It is not approved for public release.

REVISION HISTORY PAGE

Revision No.

Change No. Description Release

Date Baseline EHP-

C0726 Initial Release – approval and authorization for release captured in EHP Directive

EHP-D0726

11/07/2024

Change 1 EHP- D0881

Processed on S2D EHP-D0881 which provides approval and authorization to release.

- Figure 2-1: Added, in order to resolve FWD-EHP-10098-009

- Appendix F: Added, in order to resolve TBD-EHP-10098-002

- Updated EHP-SW-R007 to reference new EHP NAV format (Appendix F).

- Closes multiple TBD/TBR/Forward Work items:

TBD-EHP-10098-001: Removed, as it was redundant with TBR-EHP-10098-001, TBD-EHP-10098-002: Removed, as it was resolved by the addition of Appendix F.

TBR-EHP-10098-003: Removed, as Rev A of Comm Spec (EHP-10068) drops the duplicated requirements.

FWD-EHP-10098-002: Removed, as this is standard forward work by the project as part of complying with these requirements.

FWD-EHP-10098-003: Removed, as this is standard forward work and not appropriate to carry FWD in this document on behalf of another EHP document.

EHP-10068 will reflect these changes in EHP-10068 Rev A FWD-EHP-10098-005: Removed. Any tailoring of the ISwSIS requirements will need to be adjudicated by the allocated systems and not within this document.

FWD-EHP-10098-007: Removed, as this is standard forward work and not appropriate to carry FWD in this document on behalf of another EHP document.

FWD-EHP-10098-009: Resolved with the addition of Figure 2-1.

4/21/2025

Rev A EHP- C0960

Processed on EHP-D0960 which provides approval and authorization to release.

- Changed requirement language from “EHP systems shall” to “ALSS assets shall”.

- Updated applicable documents (Table 2-1) and reference documents (Table 2-2)

- Updated document to follow EHP Document Template for Surface Specs, including removing Appendix E (Traceability Matrix)

- Renumbered EHP-10098 requirements to have another leading “0” in them.

- Added Appendix G to describe the Compact Unique Identifier (CUI) format.

- Added in Appendix H to describe the Emergency Warning Caution and Alert (EWCA) messages -- to close TBD-EHP-10098-006

- Added requirements (R-0201 to R-0223) identified as gaps in the Lunar Surface Systems (LSS) Command & Control Interoperability (LuCCI) report.

- Moved R-0004 and R-0005 requirements from “shall” to “should” -- because they were best practices and not specific to interoperability with other assets.

- Deleted requirements R-0030, R-0032, and R-0033 since they are not really an interoperability requirement, and their functionality will be covered by SRD [EHP-R- 024] “Remote Operations”

- Deleted R-0106 since it was duplicative of (and covered by) R-0001

- Deleted R-0108 since it was duplicative of (and covered by) R-0003

- Added <TBD-EHP-10098-007> for EHP-10147,EHP Artemis Lunar Surface IRD

- Added <TBD-EHP-10098-008> for EHP-SW-R-0214, Baseline the Command Response format.

- Added <TBD-EHP-10098-009> for EHP-10172 (Allocation and Effectivity Matrix)

9/23/2025

Release Date: SEP 23 2025 Page: 3 of 62

TABLE OF CONTENTS

1.0 INTRODUCTION

1.1 Purpose

1.2 Scope

1.3 Lunar Surface Phase Applicability

1.4 Mission Effectivity

1.5 Requirements Language

1.6 Measurement Units

1.7 Change Authority/Responsibility

2.0 APPLICABLE AND REFERENCE DOCUMENTS

2.1 Applicable Documents

2.2 Reference Documents

2.3 Order of Precedence

3.0 SOFTWARE INTEROPERABILITY

3.1 Concept Of Operations (CONOPS) Overview Description

3.1.1 Artemis Lunar Surface Software During DRM 4

3.1.2 Artemis Lunar Surface xEVA + LTV + HLS Communications ConOps (DRM 5)

3.1.3 Artemis Lunar Surface xEVA + LTV + PR + HLS ConOps (DRM 6)

3.1.4 Artemis Pressurized Lunar Surface ConOps (DRM 7)

3.1.5 Non-Polar Missions (DRM X)

3.1.6 Gateway Orbital EVA ConOps

3.2 Consultative Committee for Space Data Systems (CCSDS) Format

3.2.1 CCSDS Space Packets

3.3 ALSS Software System Requirements

3.3.1 ALSS Software Telemetry

3.3.2 ALSS Software Commanding

3.3.3 EHP Time Requirements

3.3.4 Automation Requirements

3.3.5 EHP Data Logging Requirements

3.3.6 EHP Interoperability Requirements

3.4 EHP Project Specific Software Requirements

3.4.1 xEVA Specific Software Requirements

3.4.2 LTV Specific Software Requirements

3.4.3 PR Specific Software Requirements

4.0 ALSS SOFTWARE VERIFICATION

4.1 Responsibilities

4.2 Verification Approach

4.3 Verification Methods

4.4 Verification Matrix

5.0 RISKS

APPENDIX A: ACRONYMS, ABBREVIATIONS AND GLOSSARY OF TERMS

A.1 Acronyms and Abbreviations A.2 Glossary Of Terms

APPENDIX B: OPEN WORK

B.1 To Be Determined B.2 To Be Resolved B.3 Forward Work

APPENDIX C: ALLOCATION MATRIX

APPENDIX D: EFFECTIVITY MATRIX

APPENDIX E: [DELETED]

Release Date: SEP 23 2025 Page: 4 of 62

APPENDIX F: COMMON NAVIGATION MESSAGE FORMAT

APPENDIX G: COMPACT UNIQUE IDENTIFIERS (CUI) FORMAT

APPENDIX H: EMERGENCY, WARNING, CAUTION AND ADVISORY (EWCA)

MESSAGES

TABLES

Table 1-1: Convention and Notation Descriptions Table 2-1: Applicable Documents Table 2-2: Reference Documents Table 3-1: Telemetry Types Table 3-2: ISwSIS Applicability Matrices Table 4-1: Verification Matrix Table 5-1: Risks Associated with EHP-10098 Table B-1: To Be Determinded Items Table B-2: To Be Resolved Items Table B-3: Forward Work Table C-1: Allocation Matrix Table D-1: Effectivity Matrix Table H-1: Metadata

FIGURES

Figure 2-1: Relationship of EHP-10098 to Other EHP Documents Figure 3-1: Unique Software Formats for Each ALSS Project Figure 3-2: Common EHP Software Format Used for Each ALSS Project Figure 3-3: Artimis Lunar Surface XEVA + HLS CONOPS EHP Surface Links and Data Flows 14 Figure 3-4: Artemis Lunar Surface XEVA + LTV + HLS CONOPS Surface Links and Data Flows with XEVA at HLS Figure 3-5: Artemis Lunar Surface XEVA + LTV + HLS EHP CONOPS Surface Links and Data Flows with XEVA at LTV Figure 3-6: Artemis Lunar Surface DRM6 Surface Links and Data Flows with XEVA at PR Figure 3-7: Artemis Lunar Surface DRM6 Surface Links and Data Flows with XEVA at LTV Figure 3-8: Gateway Earth Links and EHP RF Links and EHP Data Flows Figure 3-9: IPv4 CCSDS Space Packet Message Format Figure 3-10: CCSDS Space Packet Figure 3-11: Space Packet Primary Header Figure 3-12: Space Packet Secondary Header (Telemetry / Command) Figure 3-13: Artemis APID Bit Allocation Figure F-1: PNT Flags Structure Figure F-2: Common NAV Structure Figure G-1: Breakdown of CUI Telemetry Fields Figure H-1: EWCA_Message Structure Definition Figure H-2: Light_and_Tone_States Structure Definition Figure H-3: Single_EWCA_Event Structure Definition Figure H-4: Alarm_Status Structure Definition

Release Date: SEP 23 2025 Page: 5 of 62

1.0 INTRODUCTION

The Lunar Surface Integration Phase is responsible for integrating Extravehicular Activity (EVA) and Human Surface Mobility Program (EHP) and Human Landing System (HLS) Program assets that will be utilized for exploration or science on the lunar surface. The EHP projects include eXploration EVA (xEVA) System, Lunar Terrain Vehicle (LTV), and Pressurized Rover (PR). The HLS projects include (Integrated Lander, Human Class Delivery Lander (HDL), and Multi-Purpose Habitat (MPH). EHP is the delegate lead for the Lunar Surface Integration Phase. In leading this phase, EHP will integrate with other programs that interface with EVA suits and mobility assets on the surface. The EHP Surface Phase Specifications contain requirements for all Artemis Lunar Surface System (ALSS) that will be operating on the Moon, which ensures core functionality, interoperability, and compatibility across the lunar surface architecture as it evolves with each Artemis mission.

1.1 PURPOSE

Due to the multi-lateral nature of interfaces on the lunar surface (each ALSS may interface with every other ALSS in some capacity), managing interface requirements by traditional Interface Requirement Documents (IRDs) is not viable (exception is the common EVA interfaces captured in EHP-10029, Extravehicular Activity and Human Surface Mobility Program (EHP) Exploration EVA (xEVA) System to Artemis Systems Interface Requirement Document IRD). For that reason, Lunar Surface requirement specifications serve multiple purposes, including specifying performance requirements to successfully meet Moon to Mars (M2M) campaign objectives, ensuring interoperability and establishing common interfaces for the Lunar Surface Architecture.

This is accomplished by deriving system- and subsystem-level performance requirements from parent-level functional requirements, tailoring international interoperability standards, and establishing interface requirements that ensure compatibility between any systems that meet the Specification.

1.2 SCOPE

The scope of the Lunar Surface Integration Phase Software Interoperability Specification is to provide additional context and break down the Lunar Surface element software system requirements captured in the M2M Surface Program/Project System Requirements Documents (SRDs), tailor the HEOMD-003-08 International Software System Interoperability Standards (ISwSIS) and establish common interfaces for the software systems within lunar surface architecture.

Requirements within this specification that drive common interfaces are identified in Appendix C:

Allocation Matrix. Therefore, these requirements are expected to be implemented in interface control documents (ICDs) between all the applicable interfacing systems. This may also drive joint interface verification between interfacing systems, as described in Section 4.0 Verification.

This document contains a description of common software specifications for ALSS assets, followed by the high-level requirements and core functionality for software used by ALSS assets (e.g., Extra Vehicular Activity (EVA) suits, LTV, HLS, and PR). These ALSS assets should use the common software standards defined in this document to ensure they can communicate with other ALSS assets as well as communicate back to Earth. This document will not focus on the details of how data moves between Mission Control Center (MCC) and the Human Landing System (HLS) – only on how the data moves between ALSS assets on the Moon. While the specifics of software implementation on each ALSS project is left to that element, this document provides the reference telemetry formats to be used when communicating with other assets on

Release Date: SEP 23 2025 Page: 6 of 62 the surface of the Moon. In other words, this document is not applicable to “internal” software (i.e.

software used internally onboard a single ALSS asset). This document does not cover hardline communications between the Human-class Delivery Lander and the Pressurized Rover from launch through deployment of the PR on the lunar surface. In a similar way, the umbilical connections to the EVA suits may use methods of communication other than those described here, in EHP-10098. This document will be updated to be consistent with the latest M2M-30025, Artemis Communications Network Tracking (CNT) Positioning Navigation Timing (PNT) Architecture Description Document (CPADD) and EHP-10033, Extravehicular Activity and Human Surface Mobility Program (EHP) Integrated Concept of Operations (CO). Interoperability information for Models and Simulations as detailed in EHP-10016, Extravehicular Activity and Human Surface Mobility Program (EHP) Modeling and Simulation Plan. The scope of this Software Interoperability Specifications document includes ALSS Surface Operations where an ALSS project is involved; EHP to HLS communication; EHP Surface-to-Orbit and EHP Surface-to-Earth Communications; Audio; Video; EHP Surface Hardline Communications where an ALSS project is involved; and Communications between Gateway and orbital xEVA suits. This document is not intended to cover International Space Station (ISS) EVAs although some software may be demonstrated/tested on ISS as part of its development process (or as a Detailed Test Objective).

Specific crew health and safety related standards are found in NASA-STD-3001 V2, NASA Spaceflight Human-System Standard, Human Factors, Habitability, and Environmental Health.

ALSS assets tailor NASA-STD-3001 through their respective Program/Project documents.

1.3 LUNAR SURFACE PHASE APPLICABILITY

The requirements in this specification are applicable to the development of Lunar Surface Integration Phase Programs/Projects. Each requirement contains the Allocation to the Artemis Lunar Surface System along with first design reference mission (DRM) effectivity. For the purposes of this document, “ALSS” is considered to include the following:

• EHP: xEVA System, LTV, PR

• HLS Program: Integrated Lander, HDL, MPH <TBD-EHP-10098-009>

Government Furnished Equipment (GFE) hardware is included in the respective Program/project documentation responsible for completing its certification.

Reference Appendix C <TBD-EHP-10098-009> for the Allocation Matrix that includes the requirements outlined in Section 3.0 and provides details on future project allocation documentation.

Additional details on the definition of each Artemis System are documented in EHP-10147, Extravehicular Activity and Human Surface Mobility Program (EHP) Artemis Lunar Surface Interface Requirements Document ( IRD) <TBD-EHP-10098-007>.

1.4 MISSION EFFECTIVITY

Since Lunar Surface Phase requirements can be allocated to multiple Artemis Systems, each Artemis System will have its own Artemis Effectivity associated with it. Effectivities are aligned to DRMs (indicated by a number in Table D-1) and identify when Lunar Surface Phase must first verify implementation of the requirement.

DRM effectivity is different than DRM applicability, which is not captured in Table D-1. DRM applicability is where a requirement's verified capability is needed to support an Artemis Campaign. If the implementation of it has already been verified on a previous mission, then no re-verification is needed.

Release Date: SEP 23 2025 Page: 7 of 62

Lunar Surface DRMs are found in EHP-10033, EHP Integrated Concept of Operations. For easy reference, they are briefly summarized below:

DRM 3 (Initial Surface Capability): Lunar surface sortie configuration at the south pole consisting of only HLS (Initial Capability) and xEVA, with two crew members on the lunar surface.

This is the expected DRM for Artemis III.

DRM 4 (Initial Gateway Capability): Lunar surface sortie configuration at the south pole consisting of only HLS (Sustained Capability) and xEVA, with two crew members on the lunar surface. This is the expected DRM for Artemis IV.

DRM 5 (LTV Operations): Lunar surface sortie configuration at the south pole consisting of HLS, xEVA, and LTV, with two crew members on the lunar surface. This is the expected DRM for Artemis V and possibly VI.

DRM 6 (Pressurized Rover Operations): Lunar surface sortie configuration at the south pole consisting of HLS, xEVA, LTV, and PR, with two crew members on the lunar surface. This is the expected DRM starting with Artemis VI or VII.

DRM 7 (Initial Pressurized Surface Habitat): Lunar surface sortie configuration at the south pole, consisting of HLS, xEVA, LTV, PR, and initial pressurized surface habitat (MPH). This mission involves four crew members on the lunar surface.

DRM X (Non-Polar Sortie Mission): Lunar surface sortie configuration elsewhere on the Moon consisting of only HLS and xEVA, and consisting of two crew members on the lunar surface.

1.5 REQUIREMENTS LANGUAGE

The convention used in this document which indicates requirements and statements of facts is as shown in Table 1.5-1, Convention and Notations Descriptions. This table and its conventions and descriptions only apply to designations employed in requirement statements in Section 3.0. It does not apply to designations employed in verifications in Section 4.0.

TABLE 1.5-1: CONVENTION AND NOTATION DESCRIPTIONS

Designation Description “Shall” Used to indicate a requirement that is binding, which must be implemented, and its implementation verified in the design.

“Should” Used to indicate good practice or a goal which is desirable, but not mandatory and does not require formal verification; "should" requirements will not be included in Section 4.0.

“Will” Used to indicate a statement of fact or declaration of purpose on the part of the government that is reflective of decisions or realities that exist and are to be taken as a given and not open to debate or discussion; "will" requirements will not be included in Section 4.0.

"Will" statements are often employed to identify where there may be overlap with externally-levied duplicative requirements on systems, and this relationship will be noted in the requirement rationale.

Rationales, included for many of the requirements, are intended to provide clarification, justification, purpose, and/or the source of a requirement. In the event of an inconsistency between a requirement and its rationale, the requirement always takes precedence.

Release Date: SEP 23 2025 Page: 8 of 62

Allocations listed under each requirement in Section 3.0 identifies the Program and Project's obligations to that requirement. Allocations are further reflected in Appendix C <TBD-EHP-10098- 009>.

1.6 MEASUREMENT UNITS

In accordance with NASA Procedural Requirements NPR 7120.5, NASA Space Flight Program and Project Management Requirements and the international partnerships that will participate in the program, EHP will utilize the International System of Units (commonly known as SI units or metric system of measurement) unless it is found that obtaining components in SI units would result in a substantial increase in cost or unacceptable delays in schedule. In addition, ALSS assets will utilize, for data exchange purposes, National Institute of Standards and Technology (NIST) SP811, Guide for the Use of the International System of Units (SI) for standardization and conversion of the units of measure. NIST SP811 provides guidance on the use of SI units, including the notation and conversion. At the discretion of the providing organization, English units may be provided in parenthesis for clarity if applicable.

All telemetry and commands transferred between ALSS assets will have their interfaces defined (see Section 3.0) as described in CCSDS 660.0-B-2, XML Telemetric and Command Exchange.

Part of this XML(Extensible Markup Language) Telemetric and Command Exchange (XTCE) description will include the “units” for each parameter in each message, as well as definitions for any enumerations (i.e. OPEN=0, CLOSED=1) used. Providing the units for all exchanged messages will minimize the chances of miscommunication or misunderstanding. Anytime a value is displayed by an ALSS asset, the value should be labeled with its respective unit (to minimize misunderstandings).

1.7 CHANGE AUTHORITY/RESPONSIBILITY

The Extravehicular Activity and Human Surface Mobility Program (EHP) Board Authority for Approval of this product is the EHP Lunar Surface Control Board (LSCB). Board Authority for future revisions of this product is not delegated. Board Authority for changes is the LSCB.

The administration of future revisions will be managed by the Office of Primary Responsibility (OPR). The EHP Requirements Working Group (RWG) will be used to bring updates for community and stakeholder review prior to a Change Request (CR) release. Proposed changes to this product shall be submitted via Change Management Workflow (CMW). All such requests will adhere to the EHP-20000, Extravehicular Activity and Human Surface Mobility Program (EHP) Configuration and Data Management Plan.

The appropriate NASA OPR identified for this document is the EHP Systems Engineering and Integration (SE&I) Office (DI mail code).

2.0 APPLICABLE AND REFERENCE DOCUMENTS

The following documents include specifications, models, standards, guidelines, handbooks, and other special publications. The documents listed in Table 2-1, Applicable Documents List, are applicable to the extent specified herein. The EHP specific applicable documents and standards revisions listed are in accordance with EHP-10012, Extravehicular Activity and Human Surface Mobility Program (EHP) Systems Requirements Document, Section 2.3.1. Reference HLS-RPT- 006, Human Landing System (HLS) Program Document Control List, for the HLS applicable document revisions. For Payloads, Applicable Document lists are managed by their responsible Program. Any notation of a NASA approved alternate standard in the text of a requirement requires Cross Program Technical Authority approval, which entails agreement between all

Release Date: SEP 23 2025 Page: 9 of 62 applicable Chief Engineers (CEs), Chief Safety Officers (CSOs), and Chief Health and Performance Officers (CHPOs).

Applicable Document criteria are defined as:

a. Must be cited somewhere in this product to be considered ‘applicable’

b. Only applies to the extent that it is called out

c. Must be a requirement

If citing a document as a requirement, it will be invoked with “shall” verbiage as defined in section

1.5. Anything else is considered a ‘reference’.

2.1 APPLICABLE DOCUMENTS

2.2 REFERENCE DOCUMENTS

The following documents contain supplemental information to guide the user in the application of this document.

Reference Documents may be called out in any section or as a part of a requirement rationale and are not binding. Table 2-2 only lists the reference documents and revisions for this product.

TABLE 1-2: REFERENCE DOCUMENTS

Document Number

Document Revision Document Title

CCSDS 133.0-B-2 June 2020 Space Packet Protocol CCSDS 133.1-B-2 October 2009 Encapsulation Service CCSDS 876.0-B-1 April 2019 Spacecraft Onboard Interface Services-XML Specification for

Electronic Data Sheets CCSDS 876.1-R-2 June 2016 Spacecraft Onboard Interface Services- Specification for Dictionary of

Terms for Electronic Data Sheets CCSDS 660.0-B-2 February 2020 XML Telemetric and Command Exchange—Version 1.2

EHP-10013 Baseline Extravehicular Activity and Human Surface Mobility Program (EHP) Verification and Validation Plan

EHP-10016 Baseline Extravehicular Activity and Human Surface Mobility Program (EHP) Modeling and Simulation Plan

TABLE 2-1: APPLICABLE DOCUMENTS

Document Number

Document Title

EHP-10012 Extravehicular Activity and Human Surface Mobility Program (EHP) Systems Requirements Document (SRD)

HEOMD-003-08 International Software System Interoperability Standards (ISwSIS)

Release Date: SEP 23 2025 Page: 10 of 62

Document Number

Document Revision Document Title

EHP-10029 Baseline, Change 1

Extravehicular Activity and Human Surface Mobility Program (EHP) Exploration EVA (xEVA) System to Artemis Systems Interface

Requirement Document (IRD)

EHP-10033 Rev C, Chg 1 Extravehicular Activity and Human Surface Mobility Program (EHP) Integrated Concept of Operations (CO)

EHP-10068 Baseline, Chg

Extravehicular Activity and Human Surface Mobility Program (EHP) Communications Specification

EHP-10108 Baseline Extravehicular Activity and Human Surface Mobility Program (EHP) Command & Data Handling (C&DH) Interoperability Specification

EHP-10111 Baseline Extravehicular Activity and Human Surface Mobility Program (EHP) Mission Systems Interface Definition Document (IDD)

EHP-10147 <TBD-

EHP-10098-007>

Draft Extravehicular Activity and Human Surface Mobility Program (EHP) Artemis Lunar Surface Interface Requirements Document (IRD)

EHP-10172 <TBD-

EHP-10098-009>

Draft Lunar Surface Integration Phase Specification Allocation and Effectivity Matrix

EHP-20000 Baseline Extravehicular Activity and Human Surface Mobility Program (EHP) Configuration and Data Management Plan

GP-10098 Rev C Artemis Extension for Space Packet Protocol GP-10100 Rev B Artemis XML Telemetric and Command Exchange (XTCE)

Standardized Application GSDO-SPEC-1134 Rev K Ground Systems Development and Operations Program Compact

Unique Identifier Definition Specification HLS-PLAN-005 B Human Landing System (HLS) Verification & Validation (V&V) Plan HLS-RPT-006 B Human Landing System (HLS) Program Document Control List

IEEE Std 754-2019 July 2019 IEEE Standard for Floating-Point Arithmetic

LNIS V005 Version 5 LunaNet Interoperability Specification Document M2M-30025 Baseline +

Admin Artemis Communications Network Tracking (CNT) Positioning Navigation Timing (PNT) Architecture Description Document

(CPADD)

M2M-30038 Rev C Moon to Mars Utilization Interface Requirements Document (IRD)

NASA-STD-3001 Vol

Rev E NASA Spaceflight Human-System Standard Volume 2: Human Factors, Habitability, and Environmental Health

NIST SP811 Version 3.2 Guide for the Use of the International System of Units (SI) NPR 7120.5 F, Change 4 NASA Space Flight Program and Project Management Requirements

OSTP Celestial Time Standardization

Memo

4/2/2024 Memorandum for Departments and Agencies Participating in the White House Cislunar Technology Strategy Interagency Working

Group RFC 791 STD 5, Sept

Internet Protocol (IP) Specification

Because the Lunar Surface Integration Phase Software Interoperability specification has significant overlap with other ALSS interoperability specs (for Communications, C&DH, and Imagery), Figure 2-1 may help show how requirements flow from the parent EHP documents

Release Date: SEP 23 2025 Page: 11 of 62 down to the interoperability specification documents and then how the interoperability documents flow to the EHP projects.

FIGURE 2-1: RELATIONSHIP OF EHP-10098 TO OTHER EHP DOCUMENTS

2.3 ORDER OF PRECEDENCE

In the event of a conflict between the requirements of this document and references cited herein, the requirements of this document take precedence over any Program or Project levied requirements document that are considered children to this document, including an external Program’s documents. If a child requirement exceeds the threshold of a parent requirement, this is not considered a conflict. Resolution of any precedence conflicts are accomplished using variances. Nothing in this specification, however, supersedes applicable laws and regulations, unless a specific exemption has been obtained.

3.0 SOFTWARE INTEROPERABILITY

3.1 CONCEPT OF OPERATIONS (CONOPS) OVERVIEW DESCRIPTION

Specifying the protocols/standards to be used by all assets on the surface of the Moon will be critical to having them communicate successfully when they arrive on the Moon. Specifying software interfaces is also necessary to allow ALSS assets to verify that they can communicate with other ALSS assets successfully. Designating the software interfaces ahead of physical integration allows most of the interface checkout to be done without requiring actual flight hardware checkout and will also minimize the time spent debugging issues during integration testing with representative hardware.

Release Date: SEP 23 2025 Page: 12 of 62

FIGURE 3-1: UNIQUE SOFTWARE FORMATS FOR EACH ALSS PROJECT

FIGURE 3-2: COMMON EHP SOFTWARE FORMAT USED FOR EACH ALSS PROJECT

If each of the “N” ALSS projects were to develop their own software interfaces, then each asset could potentially need to verify “N” different interfaces, resulting in approximately “N-squared” total potential interfaces to be verified across all programs. But if each individual project were to send

Release Date: SEP 23 2025 Page: 13 of 62 out its data in a single format (i.e., the suit sends the same “green” message regardless of whether it is destined for the HLS, PR, or another suit), then the integration verification (for output messages from that asset) only needs to be done for one interface (instead of “N” unique outputs).

This would only require “N” unique data formats/interfaces to be validated across all of ALSS programs (instead of “N2” interfaces). All this would require is that each ALSS asset (a suit, for example) send the same message to all other assets (say PR and LTV). This same principle would apply to commands coming into an asset; for example, the LTV would accept the same command format from HLS as from the PR. This would simplify Figure 3-1 (with 7 unique message types shown in different colors) down to Figure 3-2 (with only 1 message format to verify). The advantages of adopting a common ALSS standard becomes even more drastic as the number of assets increase on the surface. For instance, adding just 1 more asset (say MPH) into Figure 3-1 increases the number of different colors from 7 to 11!

To further simply interface verifications, this document will also advocate for further standardizing the message format between all ALSS assets (e.g. have the suits, PR, and LTV send out their navigation information in a similar message format). This would mean there would only be one data exchange format used to send out all lunar surface data, and therefore, there would only need to be one interface verified for each asset. Of course, getting multiple loosely coupled projects to agree on the standard will take effort and coordination, but will greatly lower integration risks/costs for all ALSS assets. The definition of the “ALSS standard message” will be further described in Section 3.2.

The following Communications ConOps are derived from M2M and EHP ConOps, but with additional details to specify the content/format of the messages that will be exchanged between ALSS assets. This specification covers data sent on both hardline and wireless links, regardless of the exact path the communication will go over. This document covers the specifications that will be used by all ALSS assets when they communicate to another asset.

Examples of “common” messages that could be sent between ALSS assets include Commands, Telemetry, Audio, Video, and Time synchronization, as well as generic file transfers. The ConOps outlined below is intended to expand on the Moon2Mars (M2M) CPADD, M2M ConOps, and EHP ConOps, but does not replace them as official Artemis Concept of Operations.

Any desired software standards can be used by a ALSS project (internally) when that project’s subcomponents are communicating with themselves. The internal communication systems are not constrained by this document.

3.1.1 Artemis Lunar Surface Software During DRM 4

Artemis Lunar Surface missions for DRM 4 will use wireless Ethernet data (Wi-Fi and/or Third Generation Partnership Project (3GPP)) as well as the Ultra High Frequency (UHF) Space to Space Communications System (SSCS) format from ISS. However, from a software standpoint, the UHF data will not be described by this document, as the UHF will be used for a safety critical voice with limited telemetry communication. HLS will have the ability to relay all the wireless Ethernet xEVA data (telemetry, voice, and video) to Mission Control Center Houston (MCC-H), and data from MCC-H (voice, text messages, updates to procedures, and possibly commands) can be routed from HLS to xEVA. The path from HLS to MCC-H communications can take many possible forms, but the data messages being transferred would be agnostic as to the path (other than needing to stay within the bandwidth limits of each pathway back to Earth). This document will not focus on the details of how data moves between MCC and the HLS – only on how the data moves between the HLS and other lunar surface assets. In the same way, a direct umbilical connection to the suit would simply allow a hardline channel to send the same

Release Date: SEP 23 2025 Page: 14 of 62 commands/telemetry, and would not be critical to describing the message interface for an ALSS asset (other than ensuring that that physical communication link is able to transfer data).

In addition to commands and telemetry being sent to the ALSS assets, there will also be other data transfer mechanisms in place (video, audio, file transfer) that will not use the ALSS software standard format described in Section 3.2. These alternate communication methods are discussed in EHP-10108, Extravehicular Activity and Human Surface Mobility Program (EHP) Command and Handling (C&DH) Interoperability Specification. Additionally, the data sent along with the UHF SSCS voice system is not covered in this document. See EHP-10029 section 3.5.2 for more details on the UHF SSCS system.

Artemis Lunar Surface xEVA + HLS Comm ConOps are part of DRM 4. Figure 3-3 shows the Lunar Surface RF links and data flows for other ALSS assets to HLS.

FIGURE 3-3: ARTIMIS LUNAR SURFACE XEVA + HLS CONOPS EHP SURFACE LINKS

AND DATA FLOWS

3.1.2 Artemis Lunar Surface xEVA + LTV + HLS Communications ConOps (DRM 5) Artemis Lunar Surface xEVA + LTV+ HLS Communications ConOps will be similar to Artemis xEVA + HLS, except that LTV excursions will be added and LunaNet providers will be available

Release Date: SEP 23 2025 Page: 15 of 62 to provide Navigation and Timing services similar to Global Positioning System (GPS) here on earth (as described in LNIS V005, LunaNet Interoperability Specification Document). The lunar surface crew size is still expected to be two. Like HLS, LTV can act as a comm relay during EVA excursions. Under what conditions each potential EVA comm path (LTV vs HLS) back to Earth will be used is forward work. However, the commands sent to (and telemetry from) ALSS assets will be similar to DRM 4 – The only salient change will be in how messages are repackaged when transferred to Earth. The internal payload formats will be the same as in DRM 4. More details on the data paths back to Earth are found in EHP-10068, Extravehicular Activity and Human Surface Mobility Program (EHP) Communications Specification.

Artemis Lunar Surface xEVA + LTV + HLS Communications ConOps are part of DRM 5. Figure 3-4 (xEVA near HLS) and Figure 3-5 (xEVA near LTV) show the Lunar Surface RF links and data flows for EHP.

FIGURE 3-4: ARTEMIS LUNAR SURFACE XEVA + LTV + HLS CONOPS SURFACE LINKS

AND DATA FLOWS WITH XEVA AT HLS

Release Date: SEP 23 2025 Page: 16 of 62

FIGURE 3-5: ARTEMIS LUNAR SURFACE XEVA + LTV + HLS EHP CONOPS SURFACE

LINKS AND DATA FLOWS WITH XEVA AT LTV

3.1.3 Artemis Lunar Surface xEVA + LTV + PR + HLS ConOps (DRM 6) Artemis Lunar Surface xEVA + LTV + PR + HLS ConOps will be similar to Artemis Lunar Surface xEVA + LTV + HLS, except that PR will be present in DRM6. PR is habitable, capable of recharging EVA suits consumables, and will be provided by Japan Aerospace Exploration Agency

(JAXA).

The EVA astronauts will be able to drive up to 10km away from HLS using LTV, or 20km away using PR. LTV or PR will provide communications (Wi-Fi, and/or 3GPP) when the crew is out of comm range of HLS, but the max required comm range from xEVA to LTV will be 200m (Wi-Fi) and 10 km (3GPP). If LTV is disabled during an EVA, the EVA crew will do a contingency traverse back to HLS. If PR is disabled during an excursion activity, then crew will be able to either perform a contingency walking traverse back to HLS, or LTV will be available to assist in the return to HLS.

ConOps of when LTV and PR should travel together vs separately are still being developed. Like HLS and LTV, PR will be capable of relaying all EVA telemetry, voice, and video to/from the MCC- H. Using PR or LTV as a communication relay for the xEVA suits is shown in Figure 3-6 and Figure 3-7, respectively. Note: If commands are sent between assets the format is the same whether via direct (“local commanding”) or pass through commanding (relaying of remotely generated commands). Note: there are only 2 astronauts on the surface in these diagrams – the spacesuits will either communicate with HLS (when nearby), and with PR/LTV (when far away from HLS). The path from PR / LTV to MCC-H could be direct via Lunar Exploration Ground Sites

Release Date: SEP 23 2025 Page: 17 of 62

(LEGS) or Deep Space Network (DSN), relayed through Lunar Communications relay and Navigation Systems (LCRNS), relayed through Gateway, relayed through LTV/PR, or relayed via HLS. It is not yet known whether a JAXA Mission Operations Center (MOC) will be in the path between networks and MCC-H.

This phase is where lunar surface commonality and software format standardization will really provide value to ALSS assets. Since there are so many possible paths, if the data being sent along each path utilized a unique format, then each of those data paths would need to be validated and verified. That testing cost would become larger, and require many more integrated testing campaigns (Joint Extravehicular Activity and Human Surface Mobility Test Team (JETT)-type activities) in order to verify that all the pieces would actually “talk” when the assets being built around the globe are put together to operate together on the Moon.

FIGURE 3-6: ARTEMIS LUNAR SURFACE DRM6 SURFACE LINKS AND DATA FLOWS

WITH XEVA AT PR

Release Date: SEP 23 2025 Page: 18 of 62

FIGURE 3-7: ARTEMIS LUNAR SURFACE DRM6 SURFACE LINKS AND DATA FLOWS

WITH XEVA AT LTV

3.1.4 Artemis Pressurized Lunar Surface ConOps (DRM 7)

Artemis Lunar Surface xEVA + LTV + PR + MPH+ HLS ConOps will be similar to Artemis Lunar Surface xEVA + LTV + HLS + PR, with the exception that the addition of MPH allows for the growth to four crewmembers on the lunar surface and extended operations. MPH will be contributed by the Italian Space Agency/Agenzia Spaziale Italiana (ASI). But from a Software standpoint, the content of the messages being sent to and from each ALSS asset will be the same as in DRM6 (although the underlying communication links may change).

3.1.5 Non-Polar Missions (DRM X)

The Non-Polar DRM includes the same lunar surface assets a as DRM 4: xEVA and HLS. The main difference is that the landing location will not be at the South Pole, and some additional orbital assets may be available (i.e. LCRNS satellites and Gateway) which are not part of DRM 4.

3.1.6 Gateway Orbital EVA ConOps

Gateway EVA ConOps will be similar to ISS EVA ConOps. Gateway EVAs will use the UHF SSCS system, external Wi-Fi system, and airlock hardline interface. Gateway relays all xEVA telemetry, voice, and video from external xEVA suits to crew inside Gateway and to the MCC-H. Gateway also relays audio from crew inside Gateway and MCC-H to xEVA suits.

xEVA Wi-Fi uses 5 GHz Wi-Fi to send both ~33kbps of data (same as UHF SSCS, but at 5 GHz) and xEVA helmet camera streaming to Gateway.

A Gateway airlock hardline is used during suit donning until SSCS and Wi-Fi connections are established, and during suit doffing after SSCS/Wi-Fi connections are lost. Hardline is also used

Release Date: SEP 23 2025 Page: 19 of 62 to download recorded data (including video) after an EVA, and potentially for xEVA suit software or database updates.

Two-way Audio communications is provided by the xEVA suit avionics and uses the G.711 audio format (pending surface comm architecture change decision). Audio routing includes EVA-EVA, EVA-Gateway, and EVA-MCC-H (via Gateway).

xEVA Video consists of a camera on each helmet that simultaneously locally records, and streams video to MCC-H via Gateway external Wi-Fi.

Figure 3-8 shows the shows the RF links and data flows for EHP during Gateway EVAs.

FIGURE 3-8: GATEWAY EARTH LINKS AND EHP RF LINKS AND EHP DATA FLOWS

Release Date: SEP 23 2025 Page: 20 of 62

3.2 CONSULTATIVE COMMITTEE FOR SPACE DATA SYSTEMS (CCSDS) FORMAT

All ALSS standard messages transmitted/received by ALSS assets will be in Internet Protocol version 4 (IPv4) Ethernet (See EHP-10108 [EHP-CDH-0002] and RFC 791, Internet Protocol (IP) Specification). The “payload” of the message will be the same regardless of if the message is sent via a hardline connection, Wi-fi, 3GPP, or another communication link.

Each ALSS asset will send telemetry and receive commands using CCSDS Space Packets. This message format (shown in Figure 3-9) is a 20-byte IPv4 header, followed by an 8-byte User Datagram Protocol (UDP) Header, and finally a CCSDS Space packet (see Section 3.2.1). Other data transfers (real time audio/video streaming, and background file transfers) are also allowed, assuming they follow the standards specified in EHP-10108 (C&DH Specification).

FIGURE 3-9: IPV4 CCSDS SPACE PACKET MESSAGE FORMAT

3.2.1 CCSDS Space Packets

Command and Telemetry messages sent between ALSS assets will be sent out using the CCSDS space packet format (Specified by HEOMD-003-08, International Software System Interoperability Standards (ISwSIS) [SWS-002]). The payload content of each space packet is dependent on the Application Process Identifier (APID) value for each space packet as outlined in Section 3.2.1.3.

CCSDS Space Packets are composed of three sections: packet primary header, packet secondary header, and the user data field as shown in Figure 3-10. The CCSDS primary header is 6 bytes, and the ALSS secondary header will be 14 bytes in size (see Section 3.2.1.2). The size of the user data field section of a Space Packet (for telemetry or commands) will vary depending on the message APID being sent (see Section 3.2.1.3). However, since the total CCSDS message is limited to be 65,542 bytes (see CCSDS 133.0-B-2, Space Packet Protocol), that means the size of the “user” section is limited to a maximum of 65,516 bytes. By definition, the CCSDS headers must have all their data sent in Network Byte Order (i.e. “Big Endian”) format where the most significant byte of a multi-byte item is sent first. For “user” data, Network Byte order (“Big Endian”) will be used as well – as proscribed by ISwSIS [SWS-006].

Release Date: SEP 23 2025 Page: 21 of 62

FIGURE 3-10: CCSDS SPACE PACKET

3.2.1.1 CCSDS Space Packet Primary Header

The CCSDS Space Packet primary header is 48 bits (6 bytes) in length as shown in Figure 3-11.

The fields of the primary header will be set according to the standard CCSDS 133.0-B-2, Space Packet Protocol.

FIGURE 3-11: SPACE PACKET PRIMARY HEADER

3.2.1.2 CCSDS Space Packet Secondary Header

All ALSS space packets (both Command and Telemetry) will use the same “Space Packet Secondary Header” shown in Figure 3-12. The APID is a 36-bit long item made from combining 11 bits from the primary header with 25 bits from the secondary header as outlined in Section 3.2.1.3.

This secondary header also contains a 6-byte timestamp (sent as three 2-byte items) and will contain the time since the EHP epoch (Note: the EHP epoch will likely be the LTC (Coordinated Lunar Time) epoch, once LTC is defined: See Office of Science and Technology Policy (OSTP) Celestial Time Standardization Memo, Memorandum for Departments and Agencies Participating in the White House Cislunar Technology Strategy Interagency Working Group). This EHP epoch time is referred to as LRT (Lunar Reference Time) throughout this document. Further information on each field in the secondary header can be found inside GP-10098, Artemis Extension for Space Packet Protocol.

Release Date: SEP 23 2025 Page: 22 of 62

FIGURE 3-12: SPACE PACKET SECONDARY HEADER (TELEMETRY / COMMAND)

3.2.1.3 Artemis APID Bit Allocation

The allocation of the bits in the APID are shown in Figure 3-13. The Message ID portions of the APID allocation have been expanded to include additional fields that enable a global addressing strategy for Gateway, Visiting Vehicles, and ALSS assets. Each field of the APID is described in detail in GP-10098. But for ALSS purposes, a separate spacecraft ID would be reserved for each astronaut (EVA1/EVA2/EVA3/EVA4) and each asset (i.e. Gateway, PR, LTV, HLS (Blue Origin), HLS (SpaceX), etc.). If multiple versions of an asset are in use (i.e. two LTV’s), they will each have a separate spacecraft ID. The module ID and Processor ID portions of the Artemis APID can then be allocated by each project to differentiate the source of data (for example, the xEVA suits on subsequent Artemis missions could use different Module ID values as “tail numbers”.

That would allow a unique ID for the 2 suits that are used as “EVA1” on Artemis 3 and Artemis 4 missions).

The 2 bit “TIME STAMP TYPE” field encodes what sort of clock the timestamp from Figure 3-12 is relative to (i.e. 0 for UTC, 1 for LTC, and 2 and 3 are reserved for future formats).

FIGURE 3-13: ARTEMIS APID BIT ALLOCATION

3.2.1.4 Space Packet Payloads

The payload of each CCSDS Space Packet is dependent on the APID for that message. Since each message could have a unique payload format, the format of each “user” payload will be described using XTCE – as described in ISwSIS [SWS-009] and required for displays used in the MCC by EHP-10111, Extravehicular Activity and Human Surface Mobility Program (EHP) Mission Systems Interface Definition Document (IDD), GP-10100, Artemis XML Telemetric and Command Exchange (XTCE) Standardized Application, and CCSDS 660.0-B-2. This will allow MCC and

Release Date: SEP 23 2025 Page: 23 of 62 other ALSS users to know what is inside the message (as well as how to extract the data). This information will include the “units” for each parameter, as well as any limits for the telemetry.

Data that is sent in floating point standpoint (4-byte floats or 8-byte doubles) should be encoded using the Institute of Electrical and Electronics Engineers (IEEE) Standard 754 Floating Point Numbers, and sent in Network Byte Order (“Big Endian”).

3.3 ALSS SOFTWARE SYSTEM REQUIREMENTS

The ALSS architecture must cover requirements in the categories: Telemetry, Commands, Time, Data Format, and required services.

3.3.1 ALSS Software Telemetry

[EHP-SW-R-0001] ALSS Telemetry Format

ALSS assets shall transmit telemetry messages using the CCSDS message format documented in Section 3.2.1.

Rationale: Standardizing the telemetry format is important for mission success because it will simplify integration testing and make development of common displays that support multiple ALSS assets.

This definition of data format will be IPv4, Big Endian format for multibyte data parameters, and CCSDS header format (primary header and secondary). The details of the format are described in Section 3.2.1.

Allocation: EVA Dev, LTV, PR, HLS

[EHP-SW-R-0002] Emergency, Warning, Caution, and Advisory (EWCA) Messages

ALSS assets shall transmit EWCA messages to other Artemis Lunar Systems and/or MCC-H in the common format described in Appendix H.

Rationale: Important alarms and alerts should be sent to alert people/systems when there are issues present on an ALSS asset. The EWCA messages should utilize the same message format as a telemetry messages (i.e., EWCA messages can be thought of as a special type of telemetry). The specific types and number of caution and warnings that can be sent are obviously asset specific, but the need for them is universal across all Artemis programs. This will likely be levied via declaring NASA-STD-3001 Vol 2 as at least a Type 2 standard (including requirement 10114 in it), but until that is finalized, this specific aspect is carried here due to its importance. Note: this requirement is only for the issuing of the EWCA messages, not for producing the tones/alarms associated with the alerts.

Allocation: EVA Dev, LTV, PR, HLS

[EHP-SW-R-0201] Provide Telemetry

ALSS assets should send the health and status telemetry listed in Table 3-1.

Rationale: When sending telemetry needed for remote operations, there are several types of data that need to be provided by an ALSS asset to the remote operator. The specific details on

Release Date: SEP 23 2025 Page: 24 of 62 telemetry message will need to be specified in a ICD provided by the individual project, but the types of information listed in Table 3-1 need to be provided by each ALSS asset.

TABLE 3-1: TELEMETRY TYPES

Type Applicability Notes/example

Overall System Info

EVA Dev, LTV, PR, HLS

Computer load (%), application execution counters, command and error counters, memory usage, and number of memory bit errors detected/corrected

File System Info

EVA Dev, LTV, PR, HLS

Percent use on disk, bytes used, byte available

Faults/Errors Information

EVA Dev, LTV, PR, HLS

Faults/Errors detected. Status of automated procedures started in response to detected faults

Nominal Operations Data

EVA Dev, LTV, PR, HLS

Standard information needed for monitoring system during nominal operations

Diagnostic Data EVA Dev, LTV, PR, HLS

Auxiliary information needed to diagnose/troubleshoot the system remotely during anomalies (Hardware and/or software)

Root Cause Info

EVA Dev ,LTV, PR, HLS

If a system is generating root cause information (see [EHP-SW-R-0216]) then it should send out that information to help with fault analysis/troubleshooting.

Autonomy Status

LTV, PR, HLS planner/scheduler state, mode identification/response (MIR), procedures in execution

Allocation: EVA Dev, LTV, PR, HLS

[EHP-SW-R-0203] Accept Telemetry From Multiple Sources

ALSS assets shall be capable of simultaneously accepting telemetry messages from at least two external sources.

Rationale: All ALSS assets need to accept telemetry information from other assets so that those remote assets can be…