At its core, eXpress enables any or all of the functional and failure propagations to be captured in its “hybrid” dependency modeling paradigm, and can be performed at any time before, during or after design development. It’s fullest capability is realized when used to “influence” design decision making as it vividly reports on the “diagnostic effectiveness” of any alternative design considerations that can be immediately shared within an MBSE or externally to a secured MBSE environment. These functional and failure propagations captured within eXpress will report on the “diagnostic value and utility” of any sensors or BIT considered within the design(s) of any of lower level assemblies cards, subsystems, etc. and/or any upper-level fully integrated systems at the operational asset level or higher.

In eXpress, all input and output definitions (flows and functions) are described and initially checked for modeling errors by the eXpress “Model Error Checker”.  As the design matures, it is validated via several collaboration tools: The eXpress Design Viewer and the internal eXpress Desktop Fault Insertion capability (“DFI”).

Diagnostic Engineering Models of systems already performed within eXpress include complex Flight Control systems, aircraft carrier launching and arresting systems, multi-spectral targeting systems, radar and countless high-end missile systems. There is no technical limit to the domain or size of the models produced in eXpress by large military and defense, so model purpose, domain(s) or Scalability are not limitations.

Data forms such as SysML or MS Excel (currently available) can be imported into the eXpress Model-based Diagnostics Engineering environment, which can be exported as “raw” data or “cooked” processed data for the diagnostic deployment or a myriad of purposes in the operational environment – including to the on-board or embedded diagnostic reasoning.

As each test and/or failure data is initially described in eXpress, in terms of its “Test Coverage” – what “Diagnostic Conclusions” are learned when any test(s) (i.e. BIT, sensor, etc.) passes, or fails. This is integral expert design knowledge that is not, otherwise captured in any MBSE or MBSA paradigm. This Test Coverage detail is considered throughout the system and full design and MBSA hierarchy (within eXpress) and can be updated or modified at any time. Any design MBSA assessments are then computed on any aspect of the design after automatically elaborating this detail, and/or any other properties. The validation of any diagnostic BIT or sensors – at any, or all design level(s), is inherent to this approach and essential to assess and ensure operational effectiveness of MBSA.

This is a core competency of eXpress as DSI pioneered, led, and still leads industry in the computation of Fault Detection and Fault Isolation for any design and for any purpose(s) to support any complex design – operationally or otherwise throughout the its full Product Lifecycle.

Since the preponderance of the raw reliability data is available as “object attributes” within most advanced Reliability Engineering processes, typically in spreadsheet form, this data can be immediately imported into the eXpress design at any time or at any intervals in a MBSA & MBSE design environment. Such object attributes may include the typical component information such as failure rates, severities, reference ID’s, port names & flow, operational states, part numbers, reference ID’s, LCN, cost data, etc., or any additional attributes specified by the program. Attribute types are unlimited.

Because eXpress is a high-end Model-based engineering tool, it is able to “auto-generate” preliminary failure modes and failure effects for any design upon completion of the functional model capture in eXpress. When more specific data is learned and desired to be “merged or swapped” into the model, the data can be easily imported, and (re)propagated whenever desired. This accentuates the agility inherent to this approach and further supports any PLM environment.

Since eXpress allows the inclusion of any type of failure probability calculation (Dormant, Weibull, Log Normal, Normal, Binomial, etc.) via a simple selection of a Failure Effect “Attribute”, the effects of these calculations are inherently considered throughout the entire design and overarching system design hierarchy.

Because eXpress is able to include and propagate the knowledge of root failure modes, failure effects and relevant component property attributes throughout the entire design hierarchy, the preliminary Functional Hazard Analysis can be auto-generated as an output product and/or described in a form that is traceable and mapped to the WBS.

Since eXpress is able to capture the functional and failure propagations within the context of discovering the diagnostic integrity of the design(s), it using any available Reliability (and Maintainability) data that also enables the automatic generation of the Traditional “standard” FMEA or FMECA’s (MIL-Hdbk 1629A) but allows full customization.

Additionally, eXpress enables any desired number of columns to be added and adjoined within the FMECA to describe such diagnostic details about each component as Failure Detected, Number of Root Failure Modes in each Fault Group and the size & constituency of that Fault Group. It can also describe if the Failure is “Uniquely Isolated” in this “Diagnostics-Informed” FMECA, as well as being identified as “FUI” in any Reliability Assessment products generated as outputs from the eXpress Model (see images of FTA below). Not fully discovering and considering the impact of FUI will have a negative impact on the operational value realized from any MBSA.

The eXpress Fault Tree Analysis (FTA) is calculated and produced as an “output” from the captured diagnostic design in eXpress (see image below). Unique to the eXpress FTA is that each node of the FTA will identify the probabilities of detecting a failure at any node (“FD”) of the FTA – and the percentage of that Failure that can be “Uniquely Isolated” (identify the “root cause” to a specific Failure Mode) at that node in the FTA – integral to a high-end MBSA process. The inability to discern the specific root cause (Failure Mode) is a heavy contributor to False Alarms and Operational Aborts.

Simultaneous Auto-generation of eXpress “Critical Failure Diagnoses Chart” (Diagnostics-Informed FMECA: second image above) and the interdependent eXpress Fault Tree Analysis (FTA) at any point during design development. This critical Reliability Assessment product ensures cross-validation between the FMECA and the FTA. Both the FMECA and FTA assessment products are generated using the same diagnostic knowledgebase from the eXpress Model. The typical “Cut Sets” are also co-identified within the FMECA and/or the FTA. Concurrently, automated detailed “Cut Set” reports produced by eXpress for any FMECA/FTA generated in eXpress along with the full breadth of traditional Safety Assessment reports (Cut Set Details, Important Measures, etc.) but also a “Failure Mitigation Report” to discover mitigated single-point failures.

Furthermore, and since all of these companion assessment products are generated as co-dependent outputs from any model or system model within eXpress, any variation, change or update to the eXpress model(s) during the development process can be immediately reported back into the PLM or high-end MBSE design development processes for SME validation and further MBSA trade study analyses. Refer to an example of the eXpress FMECA/FTA toggle capability and the FTA Cut Set outputs in the image below:

Without equally high-end Diagnostics Engineering, any investment into MBSA within an MBSE environment, will not be able to ensure that the operational level (or any ensuing maintenance level continued thereafter) implementation of the Health Monitoring/Managing will be able to be fully realized. To discover the strengths and weaknesses of the MBSA as it corresponds to the operational environment it would require that the MBSA be compared to results learned from the performing of an operational support simulation whereby any failures can be simulated during any mode or operational state of operational vehicle or asset.

The simulation of failures will allow us to examine if the critical failure(s) can be detected or decisively isolated to any critical root cause (failure mode) as declared in the MBSA within the companion FMECA, at the operational System’s level. While the eXpress FMECA/FTA identifies such Safety Assessment metrics to be determined and included within any selection of static report forms, the “STAGE” operational support simulation will determine the impact of the occurrence of any possible failure(s), including critical failures, during any specified “Sustainment Lifetime”. The “STAGE” Simulation will allow the assessing of any mixture of maintenance paradigms of Run-to-Failure (RTF), Preventative (RCM), Conditioned-Based (CBM) and Predictive (PdM) to analyses operational trades, benefits, degradations and costs in over 100 graphs.

The MBSA must be able to consider the “impact of Prognostics Design” at any time during the Development Lifecycle.

To this end, MBSA must be able to consider the operational effectiveness of very low-level Physics of Failure (PoF) analyses for Safety and Risk Mitigation objectives. This area of PHM can become extravagant or ineffective if not strictly worked within the structure of a full MBSE process that is around an MBSA, and is accountable to the operational effectiveness in the sustainment environment. This accountability can be examined, once again, by using Diagnostics Engineering as a means to provide operational and maintainability effectiveness assessments during design development.

The first step is to determine the best candidates for Health Monitoring or Health Management at the operational asset level. With this approach to using MBSA, investment into development of advanced sensor technologies is based upon the “diagnostic effectiveness” of the proposed BIT to be used for any PHM application. PHM candidates can be selected on the basis of safety, risk mitigation and operational value (high non-recurring development costs), rather than solely on the size of the corresponding PHM budget.

Since the high-end Diagnostics Engineering capability is able to determine the Test Coverage of any (proposed or deployed) sensors or BIT (per operational mode, etc.) and is fully cognizant of the propagations of any failure to the lowest root cause, it is able to immediately generate turnkey outputs of the FTA that considers PHM in the MBSA – per cut set.

In the images above, the top image easily identifies the single-point failures in a mode where the FTA fills the region with an orange color, which signifies that PHM may benefit by drawing attention to these areas. Then, when the results from any PoF analysis (or using, less specifically, historical data) are able to be factored into the captured Diagnostic Engineering knowledgebase, their contribution to the reduction in the likelihood of experiencing a critical failure is immediately computed for each impacted cut set.

The most overlooked contribution that Diagnostics Engineering brings to this FTA portion of the MBSA is that it determines the capability of the PHM to detect and identify the root failure cause(s) within each specific branch or cut set of the FTA. Too often, the Safety Analysis is performed and there’s no “certainty” to the actual portion, if any, of critical failure(s) is able to be observed by the on-board BIT used with or without specifically developed PHM-targeting sensors.

In this solution, the BIT Fault Codes can be associated directly to the fault group and/or the root failure mode during MBSA. By using the full hierarchical knowledge of the system’s diagnostic constraints, this approach uniquely determines which root failures are observed by the BIT, those that are not, and when certain root failures may not be covered in the BIT (see “FUI”).

Additionally, when performed in a high-end MBSA application, BIT codes enable the diagnoses to be “continued” from the on-board PHM capability to the off-board Automatic or Manual Testing implementation(s). This is performed without losing any diagnostic integrity in the transitioning from one paradigm to the next. Replacing the correct failing component(s) in any ensuing maintenance activity provides an optimum method to mitigate safety risks due to mis-isolation of critical failures.

DSI is an active (2019) participant in the IEEE SCC20 for developing an Industry Standard in support of PHM.

Existing MBSA Tools Identified in this document

Below is a chart that identifies the commercially Licensable Software tools mentioned throughout this document. While any “Product Lifecycle” ambitions will ultimately be constrained by its effectiveness to transfer such detailed design assurance to the operational environment, restricting to the scope of this inquiry, DSI has thereby not described its commercially available Diagnostic Reasoning tools to accommodate these integral objectives.