The concept of Design for Testability was originally pioneered by Ralph De Paul, Jr. in the mid 1960’s based on diagnostic ideas that he had first conceived during the 1950’s. Due to his involvement as an encryption specialist for the US Army during the Korean War in the early 1950’s, De Paul had experienced the traumatic loss of some of his fellow servicemen. It was later learned by De Paul that the loss of these soldiers was primarily due to the malfunctioning of their equipment, which apparently was not an uncommon scenario at that time.

As this loss clearly carried a heavy weight on De Paul’s heart, Ralph made a promise to himself that from that moment forward, he would begin a relentless pursuit to innovate a tool and/or methodology that would allow our soldiers to be able to rely on the proper functioning and operational readiness of their equipment at all times.

This pursuit became an obsession that never allowed attention to be overly drawn in the direction of the countless political and financial obstacles that Ralph endured throughout his journey in this vain. At that time, there was an abundance of obstacles at every juncture, including the lack of adequate financial resources and communication mechanisms, which was strictly limited to the use of telephones and the US Postal Service. The times were much different – no SBIR programs, no emails, no websites, no fax machines, no computers, no Federal Express and no Home Mortgage Lines of Credit were available at that time to provide any sort of small business assistance in De Paul’s efforts. This was an independent and high risk venture that individuals in industry today would never be able to attempt or consider.

Having performed significant post graduate work at the University of Southern California as well as UCLA in the fields of mathematics and philosophy, Ralph had the academic background to provide an abundance of kindle for his pursuit. Coupling this knowledge with his first-hand experience in his prior service with the US Army with his personal obsession that ignored the tremendous strife along the way, Ralph became uniquely qualified as an individual who could be totally consumed in his aspirations and ultimately resulting in the genesis of the Design for Testability discipline. One of Ralph’s greatest assets was that he was an excellent communicator and he did capture the listening ear of officials throughout all branches of the US Department of Defense. The attention to “testability” was going to be something brand new for them, but they were in a listening mode at that time. And, Ralph spoke with all of the officials every day, every evening and every early morning.

The methodology that Ralph pursued would have to work for all equipment and it would have to be able to describe the proper functionality of the equipment in a flexible, yet simple and universally consistent form. The computational assistance was not at a level much above the use of a slide rule, so careful selection of equipments for concept test systems was an instrumental factor. Gaining access or adequate detailed data to some of these systems would be another challenge. However, Ralph endured these challenges and interest in Ralph’s work steadily increased from the US Army initially, and soon the other branches began to query Ralph on his self-prescribed obsession.

After years of his own independent research, he announced his discovery of a method that allowed for the functionality of any relationship between items, events and dependencies to be exhaustively described by the use of only three symbols – circle, square and triangle. The crude form of Design for Testability was now born!

While De Paul gained the attention of the officials in the US, tremendous amount of work still lied ahead within industry as any new equipment to be built or designed would need to only follow the strict standards as decreed at that time by and as described in the US Military Standards. As a result, industry was not yet receptive to the idea of implementing any non-required techniques within the design process oriented solely toward improving the testing and “troubleshooting” of a device or system. During its first two decades, Design for Testability remained largely an “outsider” discipline, accepted only by a relatively small group of industry experts, until the idea finally began to take hold in the mid 1980’s.

The Two-Decade Journey

In the 1960’s and early 1970’s, De Paul—who would later found DETEX Systems (today’s DSI International)—began pushing for innovative ways to assure our servicemen of dependable equipment in the field. Recognizing that this was best insured during the design process, De Paul developed a way of representing design functionality as a causal model in what he called Design Disclosure Format, or DDF (later to be known as a dependency model). With DDF, Maintenance Dependency Charts (MDCs) were developed to improve troubleshooting and equipment maintenance. The DDF approach would prove to be equally effective for electronic or non-electronic systems. Emerging from this process in the mid 1960’s was military standard MIL-M-24100, co-developed by Ralph De Paul and the first precursor to future Testability standards. A careful study of this initial standard would reveal that at its core was a design description format that was nearly identical to the format used by LOGMOD—DSI’s first commercially available Testability and Maintenance tool.

With LOGMOD enjoying continual field successes through the late 1970’s, United States Department of Defense studies were conducted and William Keiner (US Navy) sought out DSI and Ralph De Paul to bring this need for Testability analysis before the U.S. congress. Keiner visited DSI on numerous occasions and was ultimately credited with authoring MIL-STD 2165, the first recognized “Testability” standard. This document, however, was heavily influenced by the ideals, techniques and writings that De Paul—ever the diagnostic evangelist—had freely shared with Keiner during this period. Please visit www.Testability.com for a closer look at the history of these events.

As a result of DSI having been intimately involved in the initial “push” of MIL-STD 2165 (now, MIL-HDBK 2165), DSI was also instrumental in the development of MIL-HDBK 1814, the Integrated Diagnostics standard. The purpose of this document was to better define the broadening scope and diagnostic responsibilities of all contributing parties, both those involved design and support activities. This was the era where Design for Testability began to branch into additional areas and the multitude of design and support disciplines began to coalesce into a more unified diagnostic engineering process that was better suited to evaluate diagnostic performance and support objectives during the design phase of large scale complex programs.

The Transition of Design for Testability to Design for Diagnosability

In 1993, IEEE recognized Ralph De Paul by posthumously awarding him the John Slattery award for his contribution to diagnostic engineering, referring to him as “The Father of Testability”. Throughout the 1990’s and early 2000’s, however, DSI continued to push industry to strive towards higher levels of commitment to Design for Testability. Industry experts remained in contact with DSI and, when the IEEE began to develop its own standard on testability and diagnosability, Eric Gould (DSI’s current subject matter expert) was recruited to aid in its development. As a member of the Diagnostic and Maintenance Control subcommittee of IEEE SCC20, Gould was heavily involved with the writing of this standard—not only drafting the metrics section of the document, but also participating in the ballot resolution process.

The resulting IEEE Std 1522 (2004) is a document that provides a formal basis for the analytical component of the Design for Testability process. Ultimately, this standard was not only the result of years of collaborative effort by many of the most resume-rich and well-known subject matter experts in the field, but the strict ballot resolution process required by the IEEE ensured that the standard withstood the “test of fire” as it was reviewed by members of the Design for Testability community at large. Because the metrics defined within this standard were intended to be applied within a wide variety of domains, care was taken not only that the metrics were computationally precise, but that the definitions were sufficiently general to ensure universal applicability.

This awareness of the full spectrum of concern is one of the areas in which this document differs from many of the more provincial descriptions of the testability process that can be found by searching the Internet. Like old-world religion has evolved into the individuality and appreciation of personal perspective, welcome to the new age of Design for Testability and Design for Diagnosability, which likewise, can be best valued by understanding its origin.