inner banner

Diagnostic Preparedness for AIA/ASD- S5000F

Proposed AIA/ASD S5000F Standard

As the AeroSpace and Defence Industries Association of Europe/Aerospace Industries Association (AIA/ASD) continues to evolve the proposed AIA/ASD S5000F Standard, we anticipate that any data generated within DSI’s Integrated Systems Diagnostic Design (ISDD) tools can facilitate the relevant areas and forms as described in the proposed standard.

Dismissing the Benefit of Being Diagnostically Proactive?

In viewing various applicable portions of the detail of the proposed AIA/ASD S5000F as it currently exists in the public domain, it is still unclear whether any data structure is planned to be significantly robust enough to support the diagnostic engineering activities involved during the collaborative design development lifecycle for large, multi-organizationally integrated systems. To dismiss this proactive approach to designing for sustainment in the design development lifecycle can be an unfortunate lost opportunity to establish a collaborative approach to establishing the diagnostic integrity baseline for any complex system or equipment.

A collaborative set of standardized diagnostic data detail is a prerequisite for any legitimate attempt to serve as the precursor for standardizing on any living or ongoing integrated approach to implementing advanced sustainment technologies or paradigms (as described in the proposed AIA/ASD S5000F).

Avoid Costly Rework Cycles

To this objective, we need to be able to influence the design for Fault Detection and Fault Isolation—a proactive design characteristic prior to sustainment feedback. test coverage at the integrated system level (in and about variant supplied designs, including COTS, MOTS, sensitive designs, multi-organizations, etc.) for complex systems needs to be worked so early so our LSA can work to evolving maintenance paradigms (taking advantage of new design, technologies and health management/sustainment tools, etc.) without cost prohibitive (re)work cycles.

Establish the Diagnostic Capability Baseline

We need to know the propagation of any failure causes that could possibly with the fidelity of the (BIT or failed sensor-specified) reporting of any specific functional status. This will be experienced in fielded environment! This is an expected outcome when integrated system level Failure Effects are produced from the combination of lower-level subsystem designs’ failure effects. That can be easily observed from the combining of any additionally, BIT-retrieved functional status of any interdependent components and their respective and pre-described Failure Modes.

To dismiss the opportunity to influence the design for establishing a collaborative diagnostic capability during design development will result in the diminished value to be gained from analyzing an assortment of collections of failure data from the field. Without a diagnostic integrity baseline, the failure data is independent and not vetted from a diagnostic design perspective. As such, the effort will be to chase failure data trends that may not be capable of ever realizing the diagnostic deficiencies in a complex integrated system design that give birth to diagnostic ambiguity. Data trend analyses will be an ongoing, belated, tail-chasing, and costly exercise. First failures will not be prevented in a reactive approach to sustainment.

Diagnostic Certainty is a Proactive Opportunity

How accurate is the sensing and how do we know if the sensors are properly functioning? Do we have sensor corroboration in our integrated design? Too often, there are many other additional contributing diagnostic uncertainties inherent with integrating interdependent complex designs into fielded systems. That integration alone, compromises the imagined test coverage integrity regardless if any interdependent design piece was believed to be vetted for sensor-to-BIT accuracy during design development. Test Coverage interference comes in many types. Are all of these types of test coverage interference accounted, for, and how does the sustainment approach account for test coverage interference on a consistent, safe and operational basis?

Defining and Tracking Test Coverage

Test coverage is not typically known in complex systems using traditional BIT test analyses or methods. Too much of it is (unnecessarily) left to be discovered and learned from (sometimes costly) experience, which is a reactive approach that should only be applied for small “tweaking” diagnostics. As Condition-Based Maintenance (CBM) becomes part of discussions, it becomes important to know how to best balance prognostic candidates for the sustainment requirements and affordability profile. This balancing should be a simple output report from the integrated design that is based upon mixing all of the sustainment approaches (preventative and corrective) and is used with the LORA to know what non-failed components, or Fault Groups, will need to be replaced along with the presumed-to-be, or going-to-be failed components (as constrained by the current and evolving diagnostic integrity of our integrated system(s)) over the life-cycle of our system and its variants.

Minimize or Eliminate Diagnostic Ambiguity

Often BIT (on-board) tests are not repeatable in other operational states, and such diagnostic information is compromised when commencing second-tier diagnostics, which are to be supported by sustainment efforts—integrated to logistics or not—that end up in CND, RTOK and NFF due to integrated” systems’ diagnostic weaknesses that only build over time. Replacing the same component (sometimes incorrectly) faster or repeatedly does not improve mission success nor Operational Availability (OA).

Specifications and their respective control numbers are great and convey some agreed upon level of achievement ideals, but they need to be equally prevalent in both design the development (assessment) and the implemented sustainment solution(s). Such AIA/ASD standards as S5000F need to assume equal accountability tracing back to design assessment, or else they simply become another contract funding “check box” that still leaves avoidable and costly gaps in the implementation of the diagnostics, as required to enable the most effective sustainment activities at any point in the life of the fielded integrated system(s).

Having an Integrated Logistics Sustainment (ILS) paradigm that is most effective, begins far earlier in the design development process than one has typically allowed him/herself to fully understand. Every entity needs to allow design influence to truly mean just that. Such is the starting point for serious ILS.

ISDD offers a Solution Model for S5000F

Lastly, and most importantly, the diagnostic integrity of any complex design can be ascertained, leveraged, and fully realized in the design’s operational implantation—at any point in the design’s design development or sustainment lifecycle(s) when exercising DSI’s ISDD process.

Related Links:

Guides & Standards
Overview of the ISDD Process

Subscribe To Our Newsletter