DSI has focused on design data interoperability for more than thirty years. This has enabled us to be aware of the investments that programs or organizations make into the creation of any data artifacts during the design development or the design sustainment lifecycle(s) . The objective with ISDD, is to remove any traditional boundaries that limit or constrain the value that can be otherwise realized in both the Design Development and Sustainment lifecycles.
We understand that there’s an investment in generating and sharing a design data base within the design disciplines (Systems Engineering, Reliability Engineering, Maintenance Engineering and Diagnostics Engineering) that, through ISDD, could be leveraged to serve more collaborative objectives in support of the development of the design, and then later during sustaining that design.
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.
Once captured in eXpress, many lower level deigns can be transferred directly into the test environment. This is a capability that can be well suited for the production lab environment where it can be used to enrich common Automatic Test Equipment (ATE) with diagnostic acumen. As a companion benefit, this diagnostic knowledge can then be immediately transferred to the maintenance paradigm for the fielded system. This will help to maximize operational objectives as well. This is just scratching the surface on the use of ISDD as a means to leverage traditional data interoperability far beyond the test environment.
Once captured in eXpress, many lower level designs can be immediately transferred for use from the design environment. Whether this is a capability that is suited for the lab environment to work with common ATE, or later in the field to maximize operational objectives, ISDD leverages data operability for test, and later for a myriad of perceived or evolving sustainment objectives.
When the complex or large integrated system is developed along with multiple design partners (internal or external 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.
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.
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”.
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.
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.
From a lower-level FMEA or FMECA development perspective, by propagating the failure causes upward and outward through the integrated design (subsystems included), we can determine what faults are still detectable and isolatable. This is a snap because the eXpress FMEA and “FMECA Plus” are “outputs” from the design or integrated system(s) design. Before the design is fielded the failure effects that are determined to be at BIT locations can be fully validated using the eXpress DFI capability. Such diagnostic savvy, yields proactive diagnostic clarity when ensuring that the appropriate remediation action(s) is/are matched to the intended loss or failure of any function based as upon its severity in any specific operational mode(s).
The component failure effects at the subsystem or design level, can be accurately inherited and integrated along with other designs in most paradigms. The integrating of the diagnostic characteristics along with other designs enables the integrated design to be immediately simulated over time using “STAGE” to simulate the impact of the diagnostic capability will be on the fielded system, while also considering the impact of maintenance actions based upon the (operational and inherent constraints) diagnostic constraints owned by the fielded design. Any updates to failure effects or any other component attributes can be (re)captured, (re)assessed and (re)exported to STAGE for continued simulations to observe an abundance of data analytics showing the impact diagnostic constraints, maintenance philosophy and maintenance actions on the field system. As such, the STAGE simulation considers inherent design failure propagation along with any new failure interrelationship as may occur and evolve as the fielded design may change as a consequence of maintenance actions over time.
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 not fully considered the significant impact of high-end diagnostic engineering. Instead, it has resorted to many outdated and ineffective approaches to avoid addressing the need to be proactive with diagnostic engineering. STAGE enables new insight that underscores the effectiveness of any maintenance philosophy while considering the diagnostic integrity of the design and produces unprecedented detail for unmatched data analytics.
Diagnostics engineering is the only discipline that can be truly engaged as a “Digital Twin” throughout the entire lifecycle of the fielded design. Why not extract every benefit if offers rather than dismissing it as a cost driver when instead, diagnostics engineering is a tremendous value and ROI maximizer.
As often relearned, waiting for the occurrences of first failures to be realized from operation before its inclusion in a heuristic-based sustainment paradigm, can have undesired consequences. Without ISDD, the preventative measures were unnecessarily dismissed. What is the cost of experiencing the failure(s) in terms of failure severity or in terms of future contract awards lost based upon the occurrence of such failures?
Without ISDD, the integrated system level has 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”. There is a much greater need to investigate the perpetual cost avoidance that can be realized by synchronizing the on-board the off-board sustainment paradigm rather than be complacent with attempting to make diagnostic inferences from using diagnostically-incoherent fault codes as second level diagnostic entry points.
Understanding the far reaches and impact of diagnostic engineering, ISDD provides us with a new window of opportunity. It not only enables, but also compels us to (re)think more broadly, and at the same time, more specifically.
ISDD carries value to the next opportunity as well. It enables vetted diagnostic models to be (re) used on new variant designs, and thereby, enabling continued reducing of future development lifecycle costs. ISDD defines a new level of “interoperable”, as its integrated model(s) allow for unlimited technological flexibility and design variant scalability. Want to use Guided Troubleshooting or IETM technology in the field in 2-40 years from now, then simply only substitute the “back-end” implementation. Unselfishly, ISDD provides “agile” cost avoidance capability in design development as it also targets the evolving sustainment implementation(s).