System or Vehicle “Health Status” is Reported by BIT

When the Start Up Built-In-Test (SBIT)reports back to the operator, or at the system or fielded product level, it is conveying the operational status, or health status of those specific subsystems that are involved in the proper functioning of the preliminary checkout of that equipment using the SBIT. Ultimately, we’ll need to examine precisely which functions are being examined by the SBIT or any other BIT, while the system or vehicle is operating in that particular state of operation, and as constrained by the functional test coverage by the specific SBIT.

During the operational performance of the system, vehicle or fielded product, as referred to hereinafter, the objective of the BIT is to continue to monitor the health status of the vehicle and to report back to the operator, pilot, or technician when an operational failure is observed, or being sensed by one or more of the sensors.
Other forms of BIT, like Continuous BIT (CBIT), or perhaps Periodic BIT (PBIT), may be running throughout the entire operation of the fielded product instead of just during the start-up phase. This CBIT will often have a wider variety of sensors used to monitor the functional operation or health status of specific sets of subsystems contained within the fielded product. In this manner, the system’s operator will be able to have an on-going health status updates regarding various subsystems so the performance expectation of the fielded product can be ascertained at all times.

Vehicle Health Monitoring

As the fielded product (referred from here forward as vehicle) is operating and is assumed to have all of the sensors and BIT capability that it requires to operate effectively. The BIT will be running in the background to continuously monitor the health of the vehicle. This can be described as Vehicle Health Monitoring.

Cursory look at the FMECA, Fault Signature and Fault Codes

If the reliability engineering teams have completed their Failure Modes Effects and Criticality Analysis (FMECA) design requirement, then an expected signature of BIT failures (a Fault Signature is usually assigned an Error Code or a Fault Code) would be indentified that would first be observed by the on-board BIT indicating any loss of operation by any subsystem that would happen to occur. At that point, the fault signature is determined by the combining of passing or failing of sets of fault codes and then reported at the Vehicle level. The fault signature indicates what functions are no longer able to be operable at the vehicle level. Heath monitoring would not attempt to fix or remediate the lost functions, nor would it report the specific root cause of the loss of operation(s). Therefore, vehicle health monitoring would not identify: the root cause of the failure(s), the severity of failure(s), nor the corrective action to remediate or reconfigure from the loss of operational function(s).

The severity of any failure is determined by the specific (groups of) failure(s) detected. Typically, each specific primary failure, or Failure Mode is described by the reliability engineer and the related Failure Effect is identified for each failure mode. Each failure effect is assigned a severity designator so that the severity of the failure would be instantly identifiable. As such, any failure effect can be assigned a unique fault code, and any collection of fault codes will designate a fault signature with an assigned Corrective Action.

Vehicle Health Management System

If the vehicle design requirement was to establish an ntegrated Vehicle Health Management (IVHM), then the vehicle would be able to autonomously perform remediation alternatives as a corrective action based upon the severity of the sensed (failed fault codes) failure by its fault signature. The IVHM system is capable of detecting or sensing this failure, while determining, or more precisely, localizing the failure, and, based upon the severity of the failure, autonomously perform instant remediation.

The instant remediation is a predetermined alternative. That is due to the ability of the design team or the systems engineer to be made aware of the utility or criticality of such an alternative or design redundancy that was ascertained early during the design development lifecycle. This is achieved if the design assessments were able to show a safety or cost benefit during the design development that enable the avoidance of experiencing of the most severe consequence resulting from that sensed failure. Typically, such IVHM systems are designed to be able to remediate by switching to redundant or comparably less optimal operational performance paths given the IVHM’s ability to observe any particular failure(s).

Constraints of Failure Observation or Fault Detection

Because a lower-level design is determined to be fully capable of verifying the functionality of the design piece at the output of that specific design piece, it does not ensure that such verification can be achieved with the inclusion of other design pieces at any other levels of design contained in the fielded product.

Functional Test Coverage Compromised when Conjoined with Independent Designs

The Functional Test or BIT Coverage (e.g. on-board or embedded BIT) becomes an uncertainty when independent designs are “conjoined”. We would prefer to use the label, “integrated” to infer that these independent designs simply resume with their combined Fault Detection capability, but in reality, the proper term is “conjoined” until such time as the functional and failure propagations between the designs are exhaustively interrelated and validated. This is a simple exercise in eXpress by using the incredibly robust, DFI (Desktop Fault insertion) capability. But without this process, the task will not resort to being a conventional or non-intrusive process, regardless of which such traditional methods will always be plagued with uncertainty and thus be a undetermined cost driver throughout the production or sustainment lifecycles.

Functional Test Coverage Compromised by “Test Coverage Interference”

There are three (3) types of Test Coverage Interference:
Creation – “Upstream” from Test Coverage
Propagation – “Downstream” from Test Coverage
Observation – “Upstream” from Test Point, but neither Upstream or downstream from Test Coverage

Functional Test Coverage Compromised by Operational Modes

Anytime a complex or large scale system (e.g. missile or aircraft launching systems, flight controls, Unmanned Air Vehicles or UAS, etc.) the on-board BIT may have a variance in the Test Coverage and Test Coverage “Interference” depending on the operational mode that the system is operating. For IVHM and ISHM Systems, particularly, the instant and correct corrective actions (autonomous remediation, reconfiguration etc.) must be executed, which is constrained by the “on-board BIT Test Results” initially. Provided the IVHM design has been “influenced” by the diagnostic prowess of eXpress or DSI’s ISDD, the proper balance of redundancy and BIT Test location vs. Tet Coverage can be determined in advanced and also validated with the eXpress Diagnostic Validation capability (using the eXpress DFI feature) capability. This will also enable the immediate discovery of diagnostic gaps per operational mode and determine the cost/benefit of adding sensors to corroborate sensor precision while still minimizing diagnostic complexities – in design development.

Traditional IVHM, ISHM or even “PHM” (Prognostics Health Management”) development in organizations is too quick to dismissed diagnostic influence because the IVHM design is complex and is essentially an effort burdened by a design group of just two or three (if not one individual) IVHM or PHM designers. Unfortunately, this sort of individualism in the design of such highly complex capabilities creates a single-point failure for the systems integrator and eventually, the ultimate customer, unless the functional interdependencies of the expert IVHM design knowledgebase is able to be fully captured and scalable. When the IVHM or ISHM is captured in eXpress, this expert design knowledgebase is captured and scalable in the context of DSI’s ISDD.

Related Links

Influence the Design for DFT
Influence the IVHM Design for Enhanced Sustainment Capabilities

Related Documents and Videos

Technical Brief – Built-In-Test, A Designers Handbook
Diagnostic Validation through Fault Insertion
COTS-Based Solution for Through-Life Support