by DSI Staff | Published 03/21/2007 | Systems Engineering

The awarding of DoD Programs has continued to evolve over the recent decades toward a culture that exploits the concept of “Teaming” on the development of complex products or systems for many major programs. This concept appears to allow contractors to leverage each Team member’s particular strengths in their respective areas of expertise into a unified partnering environment. To facilitate this objective, the partnering environment must agree upon a mutual acceptable means and mechanism to integrate these individual products together into the developing of a superior end-product.

This is truly a noble concept and may have the potential to harvest many broad-based benefits. However, these benefits fail to be substantially realized due to converging design areas that must bear the burden of cross-partner product development gaps. These gaps are not easy to identify or manage without strong system-level product design resulting from specific diagnostic requirements flowed and tracked down to suppliers and across to team partners via a mechanism that can effectively “communicate” with this information exchange. We are not speaking of a simple mechanism that merely addresses the exchanging of data, but rather to a much more eloquent mechanism used for the exchanging of the knowledge of the interrelationships of the design and their interrelated diagnostic characteristics as they ultimately become grouped and buried within the various complexities of the system. Additionally, this mechanism must be able to respect the sensitivities and the proprieties of lower-level design contractors and suppliers while contemporaneously enriching the overall diagnostic capabilities of the integrated system. And further, this same mechanism must be able to perform this cross-partner diagnostic development and integration role while serving as an effective means in the assessing and accounting for each partners’ or suppliers’ individual product(s) to the overall integrate diagnostic performance within the end-product or system.

To date, such mechanisms that facilitate the cross-partnering development of the diagnostic or prognostic design, have not been recognized as a practice that extends beyond the boundaries of the individual diagnostic development within each independent Systems Engineering practice adopted by each Team partner on the end-product design or Systems Integration program. Systems Engineering, with respect to the development of the diagnostics, has not been traditionally used, nor properly taught to consider the requirement to incorporate the concept of cross-partnering through the walls erected on either sides of the individual Systems Engineering practices by each individual contractor or supplier on this partnering “Team”. Each Team partner may often maintain its own Systems Engineering practice that it shall employ in the development of it’s component that it designs for the Program.

It is unlikely that any other Team partner will employ the same or an “open” and fully-interoperable Systems Engineering practice as any other partner on the Integration Program. This is obvious since it is known that many larger companies fail to share a unified Systems Engineering practice within their own divisions, sectors or activities. With so many variant and home-grown Systems Engineering practices, even within the same companies, why should we expect that any single Systems Engineering practice within one of these activities on the Program could effectively share all the Program knowledge of the diagnostics design with any other Team partner? This absolutely bolsters the reason for alarm that since industry is increasingly dabbling in so many individualized Systems Engineering practices, that the precision gained from the employment of each individual Systems Engineering practice, may be grossly compromised in the process of the honing of the information to fit the effective Systems Engineering practice institutionalized to serve the partners on the Program.

As a result, the DoD Programs that require the concept of Teaming or partnering, shall inevitably fail to share a unified Program Systems Engineering practice that truly incorporates the interchangeability and compatibility of true diagnostic and/or prognostic knowledge exchange. This inadequacy can only increase uncertainty at the System Level and thereby inviting the opportunity for such relentless experiences as System Level False Alarms, inadequate sensor utility, ineffective and ambiguous isolation capabilities, lower system availability, and uncontrollable supportability costs, etc. Eventually, over time, the experiences will likely continue to grow as new components or substitute designs/suppliers are brought into the mix that are not compelled to adopt to a Programmatic Systems Engineering structure that can adequately and completely resolve the interchangeability of the diagnostic information throughout the design, development and support of the System or end-product.

Programmatic Systems Engineering across all Team partners is essential for diagnostic and prognostics (and/or notwithstanding, FMECA/Reliability, Maintainability, etc.) sanity at the System Level. Otherwise, the extensive investment of time, effort and funding to assure precision and accuracy at the lowest levels risk becoming vacuous and expensive endeavors throughout the life cycle of the System or end-product. We have to ask ourselves if we truly are engaged in the objectives of mitigating False Alarms and any of the prior mentioned maladies that are contagious in an environment devoid of a Program-wide Systems Engineering practice targeting the entire diagnostic engineering activity across and throughout the individual Systems Engineering practices within each contributing Team partner and any relevant COTS suppliers.