DI-SESS-82078A

Integrated Health Management System (IHMS) Description and Data Architecture (DDA)

Describes the Integrated Health Management System (IHMS), including its data architecture, subsystem/system design, testing, and diagnostic capabilities used to monitor system health and report faults for maintenance.

Approval DateJuly 7, 2021

AMSC NumberN10259

Preparing ActivityAS

Project NumberSESS-2021-017

OPR—

DTIC ApplicableNo

GIDEP ApplicableNo

Limitation—

Applicable Forms—

Approval Limitation—

Form Version—

DID Formatfree_text

963C CompliantYes

DISTRIBUTION STATEMENT A: Approved for public release; distribution is unlimited.

Supersedes

DI-SESS-82078

—

Description & Purpose

—

Application & Interrelationship

—

Use & Relationship

The Integrated Health Management System (IHMS) Description and Data Architecture (DDA) provides a comprehensive description of the IHMS design of the system with detail pertaining to data architecture, design at the subsystem/system levels, testing, and any other detailed information critical to the full maturation of the IHMS. The IHMS is the essential functionality of the system to monitor its own health, collect all related parameters and report out failures and other maintenance related issues to the maintainer and/or operator for proper awareness of the system's functionality as well as corrective and preventative maintenance. IHMS includes, but is not limited to, all Built-In-Test (BIT) faults, mechanical diagnostics, exceedances and other health management state parameters to assess the health of the system.

This Data Item Description contains the format, content, and intended use information for the data product resulting from the work task described by the contract.

This DID supersedes DI-SESS-82078.

Preparation Instructions

1Required DocumentsNone.

2FormatContractor format acceptable.

3ContentThis data shall contain the following:

3.1Summary of IHMS capabilities and abilityto meet all Contract requirements (specification and SOO/SOW) related to IHMS and Diagnostics.

3.2Description of all tasking related tothe design and testing of the IHMS. This includes IHMS engineering tasks laid out as part of the product development schedule and all planned testing (to include planned dates) at the subsystem/system level to verify the performance of the IHMS. Also, include the layout of the IHMS engineering team during developmental testing and integration of that team with the government test team in assessing the IHMS numerical requirements (if applicable).

3.3Description of the diagnostics capabilities ofevery subsystem down to the Weapons Replaceable Assembly (WRA) level. Include mapping of diagnostic design capabilities down to lower levels of indenture.

3.4(for Air Vehicles) Description of faultdetection and isolation capabilities related to the Vehicle Management System (VMS) and integrated subsystems affecting the vehicle control function of an air vehicle. This includes analysis of how the BIT and pre-flight checks verify these systems/subsystems are operating normally and without latent failures in flight essential VMS functions prior to takeoff. Also include how detected failures to the VMS and integrated subsystems affecting the vehicle control function are reported to VMS processing computer(s).

3.5Detailed architecture of the IHMS to include

3.5.1Subsystem and system level architecture analysisthat shows the data paths for all fault/IHMS codes generated and sent within the system (between WRAs).

3.5.2Data path for all WRA fault/IHMScodes sent to a central processing center (Mission Computer, health management computer, etc.) and onboard data storage devices.

3.5.3For unmanned systems, data path forall WRA fault/IHMS codes sent to the VMS and what autonomous actions are taken.

3.5.4Architecture strategy of on-board vs off-boardportions of the IHMS.

3.5.5Data path and prioritization of allfault codes/IHMS data that is sent off board the system (i.e. maintenance computer, control station). This includes a description of the format of the fault logs that will be provided to the maintainers for proper troubleshooting and maintenance of the system as well as real time alerts to the operator.

3.5.6Hierarchy of diagnostic coverage to addressIHMS monitoring and reporting of safety and mission critical subsystems.

3.5.7Strategy/architecture to integrate GFE IHMS solutionsin to the overall system's single IHMS solution.

3.5.8Detail of the software needed toimplement the IHMS functionality including how the thresholds for each IHMS parameter and test can be changed as the system matures. Links to other software design documentation as needed. Component, Block, Class, and Activity Diagrams (under the UML standards or something similar) should be provided, wherever possible. If an API is available, detailed endpoint documentation should be required (using Swagger or something comparable). Further, providing a configuration management plan for the schema is desirable.

3.6Detailed data dictionary of the IHMS to include

3.6.1A listing of all fault codesincluding their formats at the WRA level as well as the system level. The format of the data shall be documented and exportable either in the Contractor format or as otherwise required by the Contract.

3.6.2Inter-relationships of all WRA fault codesto each other.

3.6.3Relationships of all WRA fault codesto their lower level Shop Replaceable Assembly (SRA) fault codes. (i.e. the hierarchy of the data).

3.6.4Frequency of all BIT/other diagnostics checksstored onboard or sent off-board the system.

3.6.5Listing of all other IHMS datacollected to assess the health of the system (ex. temperatures, pressures, speeds) with update rate, accuracy, and IHMS recording frequency of those signals.

3.6.6Frequency of status checks for allother IHMS indicators.

3.6.7Relationship of fault codes/exceedance indications tosafety/mission critical failure modes. Additional links should be added to Mission Essential Subsystem Matrix/List (MESM/MESL).

3.6.8Relationship of all fault codes tomessages displayed to operator/maintainer in a human readable format.

3.6.9A minimum of semi-annual updates tothe data dictionary provided to the Government once the design baseline is established (or as required by the Contract).

3.7Description of the different levels ofthe system's BIT Diagnostics (e.g. Periodic BIT, Start-Up BIT, Initiated BIT) and other IHMS diagnostics as required by the Contract. This includes a listing of all Initiated BITs available to the maintainer/operator broken out by operating phase of the system.

3.8Description of the diagnostics capabilities ofall mechanical components to include sensors used, sensor placement, sample rates, algorithms and analysis applied, frequency of the data collected and storage strategy for all mechanical diagnostics data.

3.9Description of other diagnostic capabilities for the following, as required

3.9.1Engine/Motor performance

3.9.2Structural Monitoring

3.9.3Corrosion Monitoring

3.9.4Electrical System and Generator Monitoring

3.9.5Hydraulic System/Pump Monitoring

3.9.6Flight Control Systems Monitoring

3.9.7Monitoring and maintenance of fleet adjustable items

3.9.8Exceedance Monitoring

3.9.9Any subsystem that does not haveinherent health monitoring capabilities.

3.10Additional design strategy for alternate sensormounting, spare sensors, and other algorithms/IHMS capabilities held in reserve as the need arises for safety and readiness.

3.11Description of the maintainer interface, includingdisplay of all fault codes and other displayed data in a human readable format without the use of cross reference tables.

3.12Description of the engineering organization responsiblefor the design, development upkeep, and testing of the IHMS.

3.13Numerical estimates of BIT(fault detection/fault isolation) capability thresholds as required by the Contract. All fault detection/isolation capabilities and estimates shall be tied to the Failure Modes, Effects and Criticality Analysis (FMECA).

3.14A testability analysis to identify anygaps in the system's fault detection/isolation capabilities. This also includes a fault isolation strategy for multiple/cascading failures discovered during test as well as the burn down plan to achieve appropriate levels of fault isolation. Also include the process within the Contractor organization to identify fault isolation issues, perform root cause analysis and implement corrective actions as required.

3.15False alarm mitigation strategy during systemlevel testing as well as the burn down planning for any false alarms issues that arise during operational use of the system. This includes the process within the Contractor organization to identify false alarms, perform root cause analyses and propose/implement corrective actions to false alarm issues and other IHMS software deficiencies.

3.16All necessary IHMS information to performintegration into maintenance, training and other support activities to include the development of the maintenance publications and Automated Logistics Environment (ALE) development. This includes detail of any Contractor developed pieces of the ALE as well as detailed interfaces with any Government provided portions of the ALE. If the Contractor develops the ALE then this includes off-board IHMS capabilities developed and delivered by the Contractor.

3.17Any algorithms necessary for off boardprocessing of the IHMS data for fault isolation and trending. This includes any off board processing as part of the complete system design.

3.18Description and implementation planning for anyprognostic or related condition based maintenance capability.

3.19Description of any other IHMS/BIT relatedactivities as required by the Contract.

References

—

Schema v3.0Community-maintained · Verify against ASSIST

Community-maintained — not an official government database.
Verify against ASSIST·GitHub·About·Disclaimer