W911W626RFIHUMS__Modular_Open-Architecture_HUMS V9.pdf

REQUEST FOR INFORMATION (RFI) /

SOURCES SOUGHT

Title: Platform-Agnostic, Modular Open-Architecture Health and Usage Monitoring System

(HUMS)

Notice Type: Request for Information (RFI) / Sources Sought

RFI Number: W911W626RFIHUMS

Response Date: Insert Due Date: 12 Oct 2026

Organization: Portfolio Acquisition Executive Maneuver Air G4

1.0 PURPOSE

This Request for Information (RFI) is being issued for market research and planning purposes only. Portfolio Acquisition Executive Maneuver Air G4 is seeking information from industry to identify capable sources and evaluate current commercial-off-the-shelf (COTS) and modified-

COTS solutions for platform-agnostic, modular, open-architecture Health and Usage Monitoring

System (HUMS).

The Government/Portfolio Acquisition Executive Maneuver Air G4 is particularly interested in solutions that facilitate Condition-Based Maintenance Plus (CBM+) across mixed fleets (e.g., rotary-wing, fixed-wing, ground, or maritime platforms) without being locked into proprietary hardware or software ecosystems.

2.0 BACKGROUND

Historically, legacy HUMS solutions have been strictly tied to the Original Equipment

Manufacturer (OEM), resulting in "vendor lock-in," proprietary decoding software, and rigid hardware architectures. As Portfolio Acquisition Executive Maneuver Air G4 modernizes its fleet, there is a critical need to transition toward a Modular Open Systems Approach (MOSA).

The objective is to implement a generic, standardized HUMS capable of integrating diverse sensor data across multiple platforms. The current platform systems are Celestica MSPU-AH-

64E, Goodrich/Collins IV-HUMS-UH-60, BOEING CPHE-CH-47. This HUMS solution must strictly align with the US Department of Defense's Modular Open Systems Approach (MOSA) directive, with a specific focus on US Army CPE Aviation mandates. To ensure future interoperability, rapid capability insertion, and the avoidance of vendor lock-in, the proposed system architecture, software components, and data interfaces must adhere to the following key standards:

• FACE™ (Future Airborne Capability Environment): The software architecture must align with the FACE Technical Standard (latest edition). Vendors must detail their approach to achieving FACE Conformance for applicable software segments to ensure portability across Army Future Vertical Lift (FVL) and enduring fleets.

• SAE JA6268 (On-Board HUMS Information Model): All diagnostic, prognostic, and platform health data generated, stored, or transmitted by the system must conform to the

SAE JA6268 standard to ensure seamless integration into Army enterprise maintenance databases (e.g., GCSS-Army) and Condition-Based Maintenance Plus (CBM+) architectures.

• Data Distribution Service (DDS): The system should utilize OMG DDS (or a FACE-conformant equivalent) for real-time, publish-subscribe data connectivity between modular components and the aircraft's mission systems.

• SAE AS7140, model-based systems engineering (MBSE)-compliant standard from SAE

International Common, Open Data Exchange Format for Rotorcraft Health and Usage

Monitoring Systems (CODEX-HUMS), universal data model application and exchange.

• ADS-79E-HDBK, AERONAUTICAL DESIGN STANDARD: HANDBOOK FOR

CONDITION BASED MAINTENANCE SYSTEMS FOR US ARMY AIRCRAFT

SYSTEMS

3.0 SYSTEM CAPABILITY REQUIREMENTS

(THRESHOLD VS. OBJECTIVE)

Respondents must detail how their proposed solutions address the following capability requirements, which are structured by Threshold (T) (minimum essential capabilities) and

Objective (O) (desired next-generation capabilities) targets:

3.1 Flight Line Data Capture & Platform Integration

• Threshold Requirement (T): The digital maintenance system must electronically pull aircraft fault logs, structural health, and engine regime data directly from the aircraft's onboard data transfer system (such as Apache or Black Hawk maintenance data loaders).

Data entry must shift away from manual paper records (e.g., DA 2408 series forms) into a digitized unit-level tracking ledger to reduce administrative overhead.

• Objective Requirement (O): Fully automated, real-time autonomous data download upon landing. The aircraft must autonomously offload health and usage monitoring system (HUMS) data to ground maintenance networks without requiring physical card transfers or human intervention.

3.2 Predictive Logistics & Analytics

• Threshold Requirement (T): Digital logging of standard Preventive Maintenance

Checks and Services (PMCS). The software must track component historicals and provide automated alerts when Time-Between-Overhaul (TBO) or retirement-life thresholds are approached.

• Objective Requirement (O): True Predictive Maintenance (PM) and Predictive

Logistics (PL) capability. The system must utilize advanced algorithms and machine learning/AI to cross-reference real-time structural stress loads with historical component wear triggering automated supply chain requests for replacement spares. It must actively predict a specific part's failure before it occurs allowing maintenance managers to schedule the parts replacement when flagged with an impending failure.

3.3 Supply Chain & Enterprise Interoperability

• Threshold Requirement (T): The unit-level digital maintenance interface must successfully batch-upload data to the wider military/enterprise logistics architecture (e.g., transitioning from legacy STAMIS platforms into the Global Combat Support System-

Army GCSS-A or equivalent).

• Objective Requirement (O): Seamless, bi-directional integration with the platform's

Digital Twin and the enterprise Digital Thread. A maintenance action at the flight line must immediately and automatically update the component's digital record within the enterprise logistics architecture (e.g., GCSS-A). This update must flow through the entire supply chain, auto-generating shipping commands at the depot level and updating global fleet health metrics, thereby creating a complete, auditable lifecycle history for every critical component.

3.4 Vibration & Component Diagnostics

• Threshold Requirement (T): The system must continuously gather raw vibration data via distributed accelerometers across major rotating components (e.g., engines, main gearboxes, tail rotor drive shafts). It must successfully process these into basic Condition

Indicators (CIs) to flag gross structural anomalies or component exceedances when predetermined limits are breached.

• Objective Requirement (O): Advanced on-board Multi-Sensor Data Fusion. The system must dynamically filter noise out of the data using flight-state-driven algorithms to isolate micro-pitting fatigue in internal bearings or gear teeth before any visual or thermal symptoms manifest, while suppressing false alarms via intelligent automated data validation.

3.5 Operational Usage & Structural Health Tracking

• Threshold Requirement (T): Automated tracking of basic engine regime parameters and structural life limits. The HUMS must record engine starts, thermal cycles, and total flight hours, digitizing the information to replace manual logbook tracking and human estimation of component retirement lives.

• Objective Requirement (O): Full Regime Recognition paired with Prognostic Health

Management (PHM). The onboard computer must actively recognize exactly what type of maneuver the pilot is performing (e.g., high-G banking turn vs. a steady hover) and correlate that real-time load profile to actual fatigue life consumption. Instead of retiring a part arbitrarily at fixed flight hours, maintenance must be safely deferred if the aircraft was flown gently, maximizing the component's true engineering life cycle.

3.6 Rotor Track & Balance (RT&B) Automation

• Threshold Requirement (T): Support for routine, semi-automated RT&B operations.

Maintainers must be able to plug an auxiliary optical tracker into the aircraft to measure main rotor blade tracking and calculate standard weight, trim tab, and pitch change link adjustment solutions, reducing the number of dedicated, costly rotor track and balance test flights.

• Objective Requirement (O): Permanent, Continuous Onboard RT&B. Permanently embedded optical, or line-scan blade trackers must map rotor track variables on every operational flight. The system must continuously refine rotor smoothing adjustments autonomously, giving crews exact mechanical adjustment instructions at the conclusion of every single mission without requiring dedicated maintenance test setups.

3.7 Data Offload & Ground System Connectivity

• Threshold Requirement (T): All data, whether at rest on the aircraft or in transit to ground systems, must be encrypted using FIPS 140-2 (or successor) validated cryptographic modules. The system must support robust authentication and access control to prevent unauthorized data access or system modification.

• Objective Requirement (O): The system must incorporate a comprehensive cybersecurity framework, including continuous monitoring, intrusion detection, and the ability to receive and apply security patches. All autonomous data offloads must utilize protocols that ensure data integrity and confidentiality, such as Transport Layer Security (TLS) 1.3

3.8 Data Ownership, Open Formats, and Technical Data Rights

• Threshold Requirement (T): Complete Government ownership of all raw and processed sensor telemetry, parametric logs, and maintenance metadata. The system must support the export of all collected database registries in non-proprietary, open-standard data formats

(e.g., CSV, JSON, XML, or Parquet) using standard protocols without requiring third-party licensing or OEM-specific proprietary extraction decoders.

• Objective Requirement (O): Government retains unlimited technical data rights. The system must provide a secure, containerized environment (e.g., using Docker/Kubernetes) with a well-defined Software Development Kit (SDK) and API. This environment must allow the operator to independently develop, test, and deploy third-party or government-owned diagnostic and prognostic algorithms (e.g., those written in Python, MATLAB, or

C++) directly on the edge processor without vendor intervention or voiding system warranties. The software architecture must allow the operator to independently host, modify, or replace analytical algorithms, or integrate third-party custom health-monitoring applications directly onto the HUMS hardware processing suite without voiding hardware system warranties.

4.0 REQUESTED INFORMATION

Interested parties are requested to submit a white paper addressing the following areas:

1. Company Profile: Company name, point of contact, CAGE code, and business size standard.

2. Platform Integration & Decoupling: Describe your proposed HUMS architecture.

Detail how your system decouples physical hardware sensors from the software diagnostic layer to maintain a platform-agnostic stance.

3. Threshold vs. Objective Capabilities: Provide a compliance matrix demonstrating how your current system meets or plans to meet the Threshold (T) and Objective (O) criteria outlined in Sections 3.1 through 3.8.

4. Edge Diagnostics & Bandwidth Management: Explain your approach to processing high-frequency data (such as gearbox or rotor balance metrics) at the edge. How does your system reduce bandwidth while still delivering actionable state-of-health summaries?

5. Standards & Enterprise Interoperability: Detail your system's compliance and integration strategy for key Army Aviation open architecture and data standards.

Specifically, address the following:

• Describe your approach to aligning with and achieving conformance to the FACE™ (Future Airborne Capability Environment) Technical Standard for applicable software segments.

• Explain how your platform health and usage data models comply with the SAE

JA6268 standard.

• Describe your system's utilization of Data Distribution Service (DDS) for real-time modular connectivity.

• Detail your strategy for seamless bi-directional data integration with Army enterprise logistics information systems (LIS), encompassing both tactical/retail and national/wholesale (entirety of the Enterprise Business Systems- Consolidated

(EBS-C))

• Describe how your solution leverages commercial ERP/PLM and Digital

Twin architectures to support the Army's broader Digital Thread, including how proprietary commercial data models are securely translated for government use.

6. Real-World Precedents: Provide examples of previous deployments (e.g., defense innovation hubs, DND/CAF challenges, US Army Future Vertical Lift initiatives, or commercial equivalents) where your OEM-agnostic CBM platform has been successfully fielded.

7. Data Ownership & Intellectual Property Approach: Clearly state your policy on data rights and ownership. Confirm that the operator will retain 100% ownership of all raw and derived fleet telemetry. Detail any software licensing fees, API usage limits, or intellectual property restrictions associated with your database schemas, configuration files, and custom diagnostic/prognostic algorithms.

5.0 SUBMISSION INSTRUCTIONS

• Format: Responses should be submitted in PDF format.

• Page Limit: White papers should not exceed 12 pages, excluding the cover page.

• Submission Email: Submit responses to lindsey.m.pavelchak.civ@army.mil with the subject line "W911W626RFIHUMS - HUMS RFI Response - Company Name".

• Deadline: All responses must be received by Insert Time on Insert Date.

6.0 DISCLAIMER

This RFI is issued solely for information and planning purposes and does not constitute a

Request for Proposal (RFP), Request for Quotation (RFQ), or a promise to issue a solicitation in the future. This RFI does not commit the Government/Organization to contract for any supply or service whatsoever. Respondents are advised that the Government/Organization will not pay for any information or administrative costs incurred in response to this RFI.