Remote Data Concentrator (RDC) Requirements for Diverse Mission Applications JSL-2651-6232026

The California Institute of Technology s (Caltech s) Jet Propulsion Laboratory (JPL), located at 4800 Oak Grove Drive, Pasadena, CA 91109, is issuing the subject RFI to obtain information from spacecraft operators, mission planners, and system integrators regarding requirements for Remote Data Concentrators (RDC) for modern avionics platforms. This information will inform the development of RDC architectures and support subsequent vendor engagement. This RFI is to also gather information of potential qualified sources and to obtain your business size relative to the following NAICS code: 336413 - Other Aircraft Part and Auxiliary Equipment Manufacturing with a size standard of 1,250 employees. Responses to this RFI may be used by JPL to make appropriate decisions regarding a Small Business Set-Aside procurement. Purpose As NASA continues to advance avionics technologies used in a wide range of applications, new, higher-bandwidth intercommunications buses are becoming available. TSN Ethernet is being evaluated as an alternative to heritage avionics bus technologies, due to its combination of fault tolerance features, deterministic timing to support for high-rate real-time control loops, high bandwidth, and large commercial off-the-shelf (COTS) ecosystem. However, it is likely that missions will need to fly legacy non-Ethernet devices such as UART, MIL-STD-1553, I2C, and CAN, as well as more modern high-speed interfaces such as USB 3.x or MIPI CSI-2. There is a need for products allowing flight computers, which will typically natively support either PCI-Express or TSN Ethernet, to communicate with devices on these other interfaces, while meeting strict fault tolerance, latency, and jitter guarantees. The purpose of this RFI is to assess RDC requirements across a wide range of avionics architectures, mission applications, and certification levels to inform the design of a flexible RDC architecture. The insights gathered may lead to an RFP soliciting RDC development or procurement from qualified vendors. Overview The RDC is part of a broader NASA effort to modernize spacecraft avionics through reusable, standards-based components. By developing RDC platforms that embrace open standards and interoperability, NASA aims to: Leverage commercial ecosystems: Benefit from ongoing advances in open standards for middleware, device configuration, electronic data sheets, auto-coding tools, and other approaches that would allow the RDC to easily evolve to support new capabilities and interfaces. Reduce development risk and cost: Build RDC platforms that can be adapted across multiple missions rather than developing one-off solutions. Integrate complex avionics platforms: Ease integration / interoperability between modern and legacy products from a variety of vendors with a variety of interfaces. Remote Data Concentrator Specifications Mission Applications Human safety critical applications (e.g. attitude control & life support) Mission critical applications (e.g. navigation) Engineering applications (e.g. thermal sensor sampling) Payload applications (e.g. low rate instruments, high rate radars and cameras) Telecom applications (e.g. uplink, downlink, telemetry) Distributed avionics (e.g. multiple applications across multiple computers needing access to the same data) Mixed criticality applications (e.g. a single RDC handling multiple classes of data with different levels of certification needed) Host Interface Ethernet, TSN Ethernet, PCI-Express, or other preferred option Data Rate, cable type (copper / fiber) Port redundancy (Frame Replication and Elimination (FRER), automatic failover, external control of primary port) Dedicated management interface(s) or combine with application data Test/development interfaces (e.g. USB, Ethernet) Bridged Interfaces and Protocols Legacy interfaces (e.g. SpaceWire, SPI, CAN, I2C, UART, MIL-STD-1553) Modern interfaces (e.g. MIPI CSI-2, CoaXPress, NVMe, CXL, USB 3.x) Analog interfaces (e.g., PRTs, voltage monitors, configurable sampling schedules, channel counts, resolution, sampling rate) Performance desired & acceptable latency, jitter, throughput, closed loop control rates Custom interfaces Software Abstraction Simple, custom message formats that encapsulate device and interface specific protocols which more easily bridge to legacy software applications (e.g. like FC-AE-1553 standard) Or, use of middleware and techniques to abstract out device and transport specific knowledge (e.g. provide gyro samples in a standard format) which can reduce cost and schedule to develop new applications Preferred middleware (e.g. DDS, SOME/IP, gRPC) Preferred abstraction approach (e.g. XML electronic data sheets, customer or vendor supplied plugins / Docker containers) Physical Constraints (Size, Weight, Power - SWaP) Form-factor / dimensions (e.g. SOSA SpaceVPX 3U, VNX+, standalone box) Mass budget Power consumption (operating and standby modes), input voltage Connector Types Management and Control Capabilities Telemetry/visibility (e.g. transport layer error statistics) Diagnostic and test modes Management and configuration (e.g. YANG, CORECONF) Runtime reconfiguration of interface parameters (e.g. baud rate, sampling schedules, QoS, telemetry reporting frequency) Fault Protection Needs Internal fault handling capabilities vs APIs to support external logic Handling of corrupt data, timeouts, babbling transmitters Automatic retries Bridge health monitoring (e.g., watchdog/heartbeat mechanisms) Redundancy/arbitration between redundant RDCs Redundancy/arbitration between redundant bridged devices Requested Information To understand spacecraft RDC requirements and inform flexible RDC architecture design, NASA seeks the following information from spacecraft operators, mission planners, and system integrators that want to procure RDCs for future missions: Provide sample requirements for representative use cases from your missions. For each use case, please provide: (1) a brief mission or system description, (2) desired RDC specifications using the previous section as examples. Feel free to add additional needed capabilities that were not listed. Indicate which specifications are must have, desired, not interested, or would prevent you from considering the product if it were present (e.g. due to making it more difficult to safety certify your application). Additional Information The requested information is for preliminary planning purposes only and does not constitute a commitment, implied or otherwise, that JPL will solicit development of such a product in the future. Neither JPL nor the Government will be responsible for any costs incurred by you in furnishing this information. Responders are advised that any information provided shall be deemed to be furnished with unlimited rights to JPL, with JPL assuming no liability for the disclosure, use or reproduction of such data. Please provide the requested information by July 23, 2026 via email to: JPL Technical Manager, Mike Thielman at Michael.R.Thielman@jpl.nasa.gov JPL Acquisition Division personnel, Jane.Lee@jpl.nasa.gov. If you have any questions about this RFI, please contact the undersigned. Sincerely, Jane Lee Group Supervisor Acquisition | Jet Propulsion Laboratory Office: 818-354-1586 | Mobile: 818-928-9581 4800 Oak Grove Drive Pasadena, CA 91109-8099