DSI has focused on design data interoperability for more than thirty years. We realized that, should programs or organizations make an investment into the creation of any data artifacts during the design development or the design sustainment lifecycle(s) they’re covered in either or both lifecycle(s)!
We understand that there’s an investment in generating a shared design data base within the design disciplines that, through ISDD, could be leveraged to serve more collaborative objectives in support of the development of the design, and then later during sustainment.

Design Data Interoperability Using eXpress

In the Design Development paradigm, eXpress has a robust and unique capability that permits it to exchange component attributes, functionality and testing data effectively through its robust and unmatched diagnostic design data capture, organizing and structuring capabilities.

Data Interoperability in Design for Test environments

Once captured in eXpress, many lower level designs can be fully brought right into the test environment from the design. Whether this is a capability that is suited for the lab environment to work with common Automatic Test Equipment or later in the field to maximize operational objectives, ISDD leverage data interoperability for test and far beyond!

Attacking the product development and sustainment areas using ISDD

When the complex or large integrated system is developed along with multiple design partners (activities and/or organizations) it will likely include a mixture of independently developed designs. These designs will, at a minimum, describe the functionality of each design that is to be included in the integrated system, or fielded product. Frequently, the “systems’ integrator” will have functional design requirements that are often allocated to the contributing partnering design activities or suppliers. As the functionality of the designs are “incorporated” through the sharing of functional design data, we can infer that the functional relationships between design pieces are associated with other contributing designs. If we can establish a robust method to trace these functions, then we can determine the functional interrelationships and interdependencies throughout all of these contributing designs.

Design Data Interoperability through Component Functional Interrelationships

Going a step further, if we could establish a robust method to track and propagate the causes for any failures and their resultant failure effects (as causes) at the next higher levels of the “integrated design”, then we can determine the interdependent propagation of these failures throughout the “integrated” design or system(s).
With this method, which we refer to as “Integrated Systems Diagnostic Design”, or ISDD, we can effectively “integrate”, the designs and the “design data” contained within each component contained within the design. As a result, “data interoperability” through and across “integrated” systems can be fully established, tracked, validated, and leveraged to serve many design and support objectives.

Data Interoperability Using COTS or GOTS through “Diagnostic Highways”

Large Scale DoD Systems typically “incorporate” Commercial or Government off-the-shelf components (COTS or GOTS). As such, ISDD is still able to fully manage the interoperability of component data throughout the integrated system(s) by establishing interrelationships and data exchange mechanisms into diagnostic hierarchies. These data exchange mechanisms can be thought to behave like their own data exchange “Diagnostic Highways”.

Data Interoperability through Functional Design Hierarchies

Through ISDD, we will discover wasted design data that can be newly or better leveraged, if the Systems’ Integrator and the (DoD) Customer were onboard with a more progressive approach in the Requirements derivation and allocation endeavors. While many pieces of data may be interoperable in the pursuit of serving other sustainment objectives, ISDD is a process that gains substantially more knowledge of the best sustainment alternatives based upon the constraints of the diagnostic integrity of the design. The lack of the ability for complex designs to actually “integrate” diagnostic design data from multiple disciplines turns out to be a glaring shortcoming and major cost driver that is totally avoidable.
Many complex designs fail to reuse much of the design data artifacts already produced and stored away as a property to a specific design discipline. This avoidable waste is typically unknown to the Systems Integrator and the customer. Sustainment requirements are maintenance biased and are not adequately associated to the Diagnostic constraints of the fielded complex system. As such, even extensively interoperable design data that is used for sustainment activities is still caught in a trap until it is able to benefit by sharing the “integrated design data” or “knowledge” that is easily able to be created and contained by using ISDD.
When complex designs require multiple organizations to share in the design development of the integrated system(s), data interoperability is not traditionally vetted for anything more that data exchange objectives. Without ISDD data interoperability will not vet the data for “data fitness” nor extend the value of the data for sustainment acumen. Instead, data simply collects, stores and reports. Without ISDD, data interoperability is totally dismissing the opportunity to enrich its value with very little or no extra effort.

Data Interoperability through Sustainment

Traditional design data interoperability methods, schemas and requirements ensure data is reused in a rather benign manner due to popular exchange forms that are limited by less ambitious sustainment expectations. Design hierarchies contained within a complex fielded product will often contain COTS or GOTS components characterized by insufficient diagnostic integrity. The diagnostic hierarchies may not necessarily follow closely with the functionally described system(s) hierarchies. Functional and/or failure propagation (e.g. failure effects not necessarily staying “in-hierarchical bounds” to design architecture) can simply skip and slip across levels, vertically & horizontally, of integrated system(s) design hierarchical structures.

Failure Data Interoperability Restructured into Diagnostic Knowledge

From a lower-level FMEA or FMECA development perspective, by propagating the failure attributes upward and outward through the integrated design (subsystems included), by cross-integrating many interdisciplinary & inter-organizational design aspects typically unknowingly discarded, we can determine what FE are still detectable, isolatable & the appropriate remediation action is matched to the loss of that function based upon the severity. The FR from the design, although inherently allocated upwardly in most paradigms, can be directly and immediately simulated over time (see “STAGE” below) to see what the impact will be – given the impact of the maintenance actions based upon the fielded design’s limitation on failure detection & isolation. Any changes to FR or any other component attribute(s) can be swapped (typical cut & pasted macro’s or global swapping) facility that allows for these design’s interrelationships to be re-organized, re-processed immediately able to view the impact upon any of these attributes in terms of the larger integrated system(s).

Diagnostic Integrity Baseline is essential for on-going sustainment interoperable value

We have noticed for over 35 years, that most complex integrated systems, with the use of today’s common, company preferred, standard or individually customized tools have fairly good fault detection, but suffer tremendously on their fault isolation capability (too many examples to enumerate). Industry has traditionally resorted to such arcane approaches to “mature” the accuracy of the diagnostic conclusions (e.g. Fault Codes, etc.) in the field. The data for maturing the BIT, or diagnostic conclusions from onboard test results has traditionally been to circumvent diagnostic design in favor of waiting for data to be gathered from the fielded systems and hope to learn from data analytics to improve future diagnostic capability in the field.
Using an approach to learn from collecting data from field maintenance activities is always a belated approach to attempt to improve inadequate diagnostic performance. ISDD opens the opportunity to use design “knowledge” to anticipate sustainment inadequacies without the waiting for first failures that could be otherwise indetified during design development with ISDD. As often relearned, waiting for the occurrences of first failures to be observed before its inclusion in a heuristic-based sustainment paradigm, the preventative measures were unnecessarily dismissed. What exacerbates the lack of integrated diagnostic interoperability integrity between the integrated systems’ design components without ISDD, is that the integrated system level has, in reality, no accurate method to objectively assess which functions or failure propagations can be observed, and those that are not “accurately” observed at the integrated system(s) level. That said, however, this is easily solvable in a much more robust design capture model-based environment – an environment that can generate integrated system(s) FD/FI assessments, and companion “turnkey” FMECAs (that can perform “unique isolation” – to a single function on a failed component) and automatically – upon demand, generate/assign/manage Fault Code(s) mappings to fault group(s) to synchronize on-board to off-board diagnostic “interoperability”. Need to synchronize off-board to include FAR more than “empty” simple fault code diagnostic entry points.

Tom, may I suggest that we can think more broadly, and, at the same time, more specifically. We can/have captured very large DoD designs (US Aircraft Carrier Electromagnetic Launching & Arresting with far over 1,000,000 test dependencies, 25,000 LRU’s, per integrated system, etc.), as well as many other very highly sensitive/complex systems are fully worked in this same diagnostic paradigm
But the “interoperable” integrated model(s) allow for unlimited technological flexibility and design variant scalability. Want to use a new IETM technology in the field in 2-40 years from now, then simply only substitute the “back-end” implementation.

Relevant videos :

Introduction to ISDD
COTS-Based Solution for Through-Life Support
Introduction to STAGE