Solutions
Data Interoperability throughout Design Development and Sustainment Lifecycle(s)
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
By establishing 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. The next, and most critical step, would be to represent the “Test Coverage” for each Point of Test that could be used for Fault Detection, and ultimately, diagnosability.
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 owned by each specific design discipline. This occurs simply because most Design Development activities are woefully not cognizant of the alternative reuses of the data that can be repurposed. A thorough study on ISDD will provide substantial background enabling the exposing of avoiding such cost and waste, otherwise unknown to the Systems Integrator and the customer.
Sustainment requirements are maintenance biased and typically are not adequately reflective of the Diagnostic constraints of the fielded or operational complex system. As such, even extensively interoperable design data that targets sustainment activities, is still far too constrained by the inherent diagnostic acumen forged into the independently-developed design. The diagnostic constraints become much more transparent when the design is able to benefit by sharing the “integrated design data” or “knowledge” that is easily able to be discovered and leveraged by 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 failure effects are still detectable, isolatable & the appropriate remediation action is matched to the loss of that function based upon the severity. The failure rates from the design, although inherently allocated upwardly in most paradigms, can be directly and immediately calculated and then simulated over time in “STAGE”. Unique to the STAGE operational support simulation, is that it considers the impact of the maintenance actions based upon the fielded design’s limitation on failure detection & isolation. Should there be updates to the design, any changes to the failure rates 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, is 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 (i.e. FRACAS, Case-based Reasoning, etc.) to learn from collecting data from field maintenance activities is always a belated approach to attempt to improve inadequate diagnostic performance. Furthermore, the diagnostic integrity of the design will forever limit the diagnostic integrity and the sustainment effectiveness.
ISDD is a proactive approach that opens the opportunity to use design “knowledge” to anticipate sustainment inadequacies without the waiting for first failures that could be otherwise identified during design development with ISDD. As often relearned in any reactive approach in seeking additional diagnostic data from experiences in the field, waiting for first failures to be “realized” before being included into a heuristic-based sustainment paradigm, can be extremely costly and, of course, – unpredictable.
ISDD maximizes diagnostic data interoperability during both the design development and sustainment lifecycle. If initiated even before components or parts are selected, ISDD can be ruthlessly proactive and data interoperability can seed exceptional diagnostic validation and facilitate unprecedented value to system safety assessments. However, as the design development progresses, diagnostic savvy becomes gradually less capable as the characteristics of a fixed design no longer is able to be influenced for maximum diagnostic value.
Without ISDD, the integrated system level has, in reality, no accurate method to objectively assess which functions or failure propagations can be observed, nor a method of determining which of those will likely not be “accurately” observed at the integrated system(s) level. If the data is truly interoperable, then the same data should be reusable across interrelated disciplinary boundaries. ISDD takes this challenge to an unprecedented level.
Fortunately, ISDD can be used to be as proactive as your program could possible care to consider. Data reuse can be a much more robust capability when the eXpress model is able to capture the design, restructure it, and reorganize it to bring your program to a whole new level of “data fitness”. This is the beginning of truly establishing a “knowledge share” environment for the entire, and evolving integrated system(s). At any time, produce cross-compatible FD/FI assessments, and companion “turnkey” FMECAs (that can perform “root function 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”.
When the design is ready for operational deployment after being “juiced” with ISDD savvy, it’ll be ready to leverage a wealth of design-based diagnostic knowledge that otherwise would have never been placed on the table. Get proactive – Get ISDD.
