What is Sneak Analysis?
Sneak Analysis is an analysis methodology which examines Electronics Hardware and Software for anomalies NOT caused by component failures. Sneak Analysis uncovers Sneak conditions, conditions where the control system does not respond as intended. These responses could either be outputs that are unexpected when specific input events occur or outputs that are inhibited due to a specific set of conditions. The Sneak Analysis methodology consists of recombining the drawings, schematic diagrams, and system software used to manufacture the system into a functional representation of actual system Hardware and Software code called Network Trees. These Network Trees allow an experienced Sneak Analyst to examine the "as-built" system at an electrical, functional, and system level for Sneak conditions. The Network Trees are further grouped into Network forests, which combine all the Network Trees that affect a single system output into a seamless topological representation of the output. The Network Forests can include software code to allow the Sneak Analyst a complete system view of the output being analyzed. The Network Trees and Forests, along with an extensive clue list which links specific topological, technological, and functional representations on the Network Trees to Sneak Conditions, are the tools to the Sneak Analyst for discovering Sneak conditions. With today's technology, most Sneak conditions occur between within the interface between Hardware and Software. The following will provide a brief overview of the history of Sneak Analysis.

Sneak Analysis was initially called Sneak Circuit Analysis, or SCA, when it was developed by Boeing company over 30 years ago. The Boeing Co. was contracted by NASA to uncover the cause of an aborted launch of a Redstone rocket. NASA had already achieved fifty previous successful launches on this launch platform with this rocket, however, this launch attempt caused the rocket engine to shutdown after to lifting off the pad a few inches. The escape tower rockets fired which separated the Mercury capsule from the rocket and deployed the reentry parachutes. The rocket and launch control electronics, mostly designed using relays, diodes, and resistors, showed no failure indications. No one would approach the rocket for 28 hours because the cause of the engine shutdown was not known. Boeing Engineers were called into help figure out why this happened.

Boeing encountered the same problems analyzing the electronics that one would today even though the electronics back in the 1960's only used simple relays and diodes. The schematics and hardware layout drawings were arranged in a format to manufacture the equipment, not ascertain the functions of the electronics. A new concept called Network Trees was devised to represent the "as-built" system hardware functionally and topologically so an analyst can identify the actual electrical current paths for each function regardless of how many pieces of equipment the function's signals traveled through. Using the Network Trees, Boeing identified a "Sneak Circuit" path to the rocket's engine cutoff coil that was not intended. The sneak current path that shutdown the engine existed because the tail plug that connects the rocket to the launch assembly that is intended to be the last cable to disconnect during a launch, pulled out prematurely. This tail plug was rebuilt after every launch by cutting back the burned wire and insulation and reinstalling the connector. Eventually, the cable became too short and pulled out after the rocket first lifted off the pad while the control cables were still connected. The current path that caused the engine to shutoff was clearly seen by the analyst on the Network Trees.

After this incident, NASA continued the funding the Sneak Circuit effort to develop software that would assist an analyst in searching out all possible current paths throughout an electronics system. Boeing developed the software and NASA made it public in the early 1970's to share this new technology with the world. After Boeing delivered the software and Network Tree methodology to the government, Boeing continued to develop Sneak Circuit Analysis in house and kept it's findings proprietary. Eventually, Sneak Circuit Analysis became Sneak Analysis because it now included functional and system level analysis of the electronics that included software. The following chart summaries the history of Sneak Analysis as technology advanced.

What Sneak Analysis is NOT
Another way of describing IDA's Sneak Analysis approach is by defining what it is not. Sneak Analysis does not repeat the designer's efforts by using purely design-aided tools. Sneak Analysis does not simulate the system using a simulation software program. A thorough Sneak Analysis is not accomplished through failure-oriented analyses such as Worst Case Analysis or Fault Tree Analysis. Sneak Analysis does not use predefined time lines to play what-if scenarios that may overlook abnormal, but possible, modes of operation that create sneak conditions.

Sneak Analysis does not just look for the "reverse current" path in hardware which was the first sneak condition discovered in the late sixties. Since then, hundreds of other sneak types have been uncovered and more are being found as technology changes. IDA maintains this information in a sneaks clue list and continually updates the list as each project is analyzed. Our latest clues now encompass Programmable Array Logic (PAL), Complex Programmable Logic Devices (CPLD) and Application Specific Integrated Circuits (ASICs) as well as software languages such as Ada and C.

More Interesting Topics On Sneak Analysis:

The Difference Between "Sneak Circuit Analysis" and IDA's Sneak Analysis Approach

The Limitations of Sneak Circuit Analysis Software

IDA's Sneak Analysis Approach Vs. Static Code Analysis

Technical Papers on Design Analyses