The eXpress Diagnostics Model is effective for all levels of the design architecture and can be expanded or enriched to facilitate the Diagnostic Design or the Sustainment objectives at any time.
The approach for initiating towards the goal of achieving diagnostic effectiveness for any design begins with identifying where we are in the design development or design support lifecycles, while also considering the diagnostic or sustainment requirements or objectives. The eXpress model captures and extends diagnostic expertise regardless of where we are in the design or sustainment lifecycles and for any sustainment implementation.
The contextual usage of the terms “System”, “System Level” and “Integrated System” become relevant in this discussion to associate a sense of “when” and “where” any contributing design piece (replaceable component or entity grouping) or collection of design pieces (assemblies, sub-systems, etc.) are “integrated” into the diagnostic hierarchy of the “Integrated System”, or fielded design or product.
Functional Design Requirements Flow Down – Failure Data (causes or effects) Propagate Upward
Top-Down eXpress Diagnostics Engineering
New Designs create the highest opportunity for extracting maximum short term and long term value from applying eXpress within the ISDD Process. When started up very early during the design development process, functional requirements can be allocated to lower levels of the design long before the parts are selected enabling many diagnostic trade-off analyses to be performed.
As the design development proceeds, the diagnostic assessments can be “pinged” from the evolving eXpress model(s) at any time. This unmatched capability fully accommodates iterative design development, offering unmatched opportunities to spot diagnostically troubling areas in both the design and in the operational environments long in advance to provide valuable feedback into the design development lifecycle.
Using eXpress at its fullest form, enables the ISDD process to fully exploit the data fitness and the interdisciplinary design data regiments throughout the related design and sustainment disciplines.
“Pushing Down” Requirements from the Higher Levels of Design
Inside the eXpress modeling paradigm, functional (diagnostic) requirements can be established at the system level and flowed down to lower levels of the design. This is typically performed from the system level using unique facilities within eXpress to aid in the validating of the lower-level detail mapping correctly to the next higher-level requirements, and to the System-Level Requirements.
Bottom-Up eXpress Diagnostic Engineering
New Designs that begin later during Design Development can still add value to the design development and sustainment lifecycles. While the infusion of ISDD after the parts have already been selected compromises the extensiveness of the design influence capability, which is a factor that is determined by how far along the design decisions have been frozen, there is still much to be gained. For example, the diagnostic capability of the design and any lower level contained in the integrated systems’ design can be evaluated and fully assessed. This will still allow for diagnostic strategy alternatives to be weighed and many turn-key system level assessment products to be produced with a push of a button!
And if that wasn’t enough, many interrelated turn-key assessment products can be produced (including FMECA’s, FTA’s, etc.), provided that the supporting detail of the data has been captured or imported into the eXpress model(s) for the relevant pieces of the design architecture.
Bottom-Up eXpress Diagnostic Engineering
For legacy, or existing designs that are currently fielded, folks underestimate the value of discovering the diagnostic capability of their existing design. There is still tremendous opportunity for value, even though the design is not able to be influenced for maximum diagnostic effectiveness. A very brief look at the design will still increase sustainment effectiveness with scalable alternatives, including determining the diagnostic integrity baseline for the legacy system.
The eXpress models are relatively quick to establish since the documentation is fixed and the fielded design is not expecting to be in a state of flux. The eXpress models will typically expose many unknown diagnostic design gaps between the various levels of the design hierarchy or within any contributing piece of the design. But this is an important purpose for capturing the diagnostic integrity baseline, enabling the pathway towards understanding how to gain benefit from any further investing into improving the design for reduced sustainment cost and operational success.
Discovering the Diagnostic Integrity “Baseline”
Discovering the Diagnostic capability of the design is the first and most important step to undertake if one is serious about truly improving the sustainment costs in terms of operational cost, availability (“up-time”), operational success (“system reliability”), and safety. The Diagnostic Integrity or “Diagnostic Capability” of a fielded system or equipment can be determined for any design.
When the fielded design is captured in the eXpress diagnostic engineering application, many facilities within the tool enable any desired diagnostic assessment – in any design piece within, or the entire integrated design, or “fielded product”. This is why it becomes imperative that the diagnostic integrity of the design is determined at any and all levels of the functional “integrated” design:
Since the core strength of eXpress is to provide the canvas for the engineering of true systems diagnostic development, it has extensive facilities to represent the collection of objects and the functional and failure interrelationships of all the objects contained within or “acting upon” that design. The first step, however, is simply to represent any piece of that design, knowing that other detail beyond the boundaries of that specific design piece, may include some lower-level designs that provide some “inputs” to the functional operation of the design. Else, this specific design may be included as a replaceable or maintainable design within a larger, higher-level, or “system-level” design.
The system-level designs are a collection of each lower-level designs in a manner that fully represents the functional or failure interrelationships that may impact the operation at the higher level, or system-level. This is the initial data that is described and captured into the design to establish the operational, and by inference, the diagnostic interrelationships contained within the design or integration of many other designs in the forming of a “system level” design.
Typically, any design can therefore, be (re)used or can be integrated into the “next-higher level” of the diagnostic design, to represent any desired “replacement level”, as deemed by the maintenance philosophy of the fielded product or operational support requirements. This is an approach that “system-integrators” for larger-scale programs, frequently prefer. System Integrators will typically integrate lower-level designs from suppliers. These lower-level designs may be complex subsystems, or may be also be complex or less-complex designs, such as the flight control systems comprising of yet lower-level digital designs such as specific on-board computer chips on circuit boards, etc.
Diagnostic Design Hierarchy
Since the building of more complex eXpress models is often performed by the adjoining of any other “integrated” replacement design pieces, a diagnostic hierarchy is established within the eXpress diagnostic modeling paradigm. This hierarchy may be determined by the functional architecture of the fielded design or System, but it may also reflect the maintenance level (replacement level, or replaceable Unit). The diagnostic hierarchy must be able to adapt to any desired diagnostic or maintenance paradigm. This flexibility enables the assessing of the diagnostic integrity (FD/FI) of any contributing design within the over-arching diagnostic design and in accordance with any required or preferred product maintenance hierarchy.
The diagnostic design hierarchies typically consist of groupings of eXpress models relating to any replaceable or serviceable components contained within a “higher level” of the diagnostic design. This sorting of diagnostic design levels typically forms the basis to determining the Fault Detection and Fault Isolation capability of each design piece or collection of design pieces contained within any higher-level of the Diagnostic Design.
The highest level of the Diagnostic Design is the “System Level”, which consists of several complex “sub-designs” or “subsystems” that perform specific or multiple major system functions. The subsystems may must follow by being as permeable as the functional interrelationships systemic to any design, regardless of size or complexity.
Crossing Design Domain Barriers
A “fielded design” or “fielded product”, may contain many designs that may or may not be constrained to a single design domain (e.g. electronic, mechanical, hydraulic or optics, etc.). While some advanced CAD design tools today are attempting to provide insight diagnostic inferences with some chip, board or multiple-board designs, they are confined to that specific digital design domain. This is not an impediment in the eXpress diagnostic engineering environment. Yet can be further included and leveraged within the eXpress models to step up the diagnostic effectiveness in the sustainment lifecycles.
Crossing Diagnostic Engineering Barriers
In fact, breaking perceived diagnostic engineering barriers has been an everyday lifestyle for eXpress and for the diagnostic engineering experts at DSI International, Inc. for over 40 years.
In always having an eye towards designing for the sustainment of the fielded or deployed products, DSI already succeeded in supplying industry with the most robust and trusted, model-based Diagnostics Engineering tool, eXpress!
Prior to 2010, however, industry was disappointed by its inability to take full advantage of the superior Diagnostics that could be generated in eXpress. DSI was partnering with companies to fill portions of this void, but we knew that it could always be so much better. DSI then invested our funds and attention to industry demands. We were successful at breaking through this “barrier” with the augmenting of the diagnostic engineering acumen of eXpress with high-powered and versatile diagnostic reasoning capability of DSI Workbench for the deployment of a wide variety of run-time diagnostic applications. Industry has already latched onto these run-time tools for leveraging their diagnostic engineering investment directly into the deployed environments for such purposes as:
Capture the diagnostic designs in the eXpress model for future (re)use for:
Diagnostic impact of COTS or GOTS components
Any COTS (Commercial-Off-the-Shelf), or GOTS (Government Off-the-Shelf) components can be (initially) represented as a simple box containing inputs to the box and outputs from the box in an eXpress model. As such, eXpress will generically treat the outputs as dependent upon every input to the box, ensuring that any loss of functionality is always considered within the eXpress Fault Detection and Fault Isolation calculations and any operational or deployment of the eXpress models’ run-time diagnostics.
Sensitive or proprietary designs can also be captured in a manner similar to the COTS or GOTS components in the eXpress modeling environment. The establishing of diagnostic interrelationships that pass through a sensitive design are not disclosed, but are modeled as all design outputs depending on all design inputs. This enables the sensitive designs to also be integrated into any higher-level eXpress models containing this sensitive design piece. Ultimately, diagnostics will only diagnose to the design piece and no further diagnostic capability is supplied, rendering the sensitive design to be a “replaceable component”. Later, this design piece can be further diagnosed, if desired, by the authorized OEM with the benefit of retaining any diagnostic detail from the original diagnostic interrogation(s).
BIT in Health Management or on-board Reasoning implementations
For example, a flight controls system in an air vehicle will typically use “embedded” BIT (Built In Test) to interrogate and report the operational status (“pass” or “fail” test results) in order to determine which functions of the flight control subsystem are working properly at the subsystem or system level (vehicle level) of the design. As such, the “health” or “operational” status of the flight control subsystem would be determined at that split second of the BIT interrogation.
The designing for the diagnostic inferences that are associated with any BIT results can be fully captured and validated in the eXpress subsystem or system level models. This is a benefit of employing Diagnostic Engineering with and for any extended Integrated Vehicle Health Management (IVHM or “PHM”) application.
Establish alternatives for the Run-Time implementation of the Diagnostics
It is important to understand that the BIT results will be affected by the integration with other designs, the test coverage of the sensors, the ability to corroborate the accurate reporting of the sensor(s) and the operational mode of the system at the time of the failed BIT results. All of these constraints, at a minimum, impact the diagnostic clarity resulting from any diagnostic activities continuing to a subsequent Diagnostic endeavor after relying on the test result reported from the BIT. The eXpress Maintenance Module ensures that extensive diagnostic inferences can be fully transferable between multiple diagnostic levels or sessions through a highly advanced “Fault Code” assignment and management paradigm.
This is a valuable approach that can immediately significantly improve the bridging of diagnostic conclusions from the operational run-time environments to a next level diagnostic interrogation when attempting to continue to isolate the failures, such as in Guided Troubleshooting or Automatic Test Equipment (ATE) applications.