CPU coverage evaluation using automatic fault injection

Abstract

A method has been developed for evaluating central processing unit (CPU) coverage by automatically injecting faults into actual CPU hardware while it is executing relevant test software. A special hardware test fixture is used which contains the CPU under evaluation, program and data memory, and a terminal interface. The test fixture is connected to a microcomputer controller and an in-circuit read only memory (ROM) emulator. The faults injected are stuck-at-1, stuck-at-0, and open on the appropriate integrated circuit pins, plus the altered state of every microprogram memory bit. The effect of each fault is determined by observing the status of the monitor. Data reduction is performed after each run on a separate host computer, and summary results are tabulated. N digital avionics systems the central processing unit (CPU) is obviously the dominant functional element, upon which many other elements are dependent in order to perform correctly related interface and control tasks. Normally, there are arrays of system monitors, in both hardware and software, which have an inherently overlapping capability to detect CPU malfunctions. The combined effectiveness of these monitors determines the total CPU fault coverage. However, since many of these monitors are themselves dependent upon CPU operation, there is a critical topdown relationship between the monitors which must be considered. In particular, a software monitor is of little subsequent value in the presence of a CPU fault unless one of the two following conditions is present. 1) It is actually executed, and it produces the planned fault detection results, and the fault detection is properly communicated to and acted upon by the ultimate hardware control elements in the system. 2) It causes fault detection elsewhere when it is not executed, and the fault detection is properly communicated to and acted upon by the ultimate hardware control elements in the system. In simplest terms, software monitors depend upon a rational CPU; that is, a CPU which is at least able to follow the normal program flow without making addressing or branching errors. If this is not the case, then how can one guarantee that the software monitor is executed? If it is possible to detect the fault of concern without executing the software monitor, then why is the monitor present? The point is that it is critically necessary to have a CPU monitoring scheme which establishes the minimum CPU fault coverage that is required to support all other monitoring activity. Such a monitoring scheme must straddle the hardware-software boundary so that external communication is absolutely guaranteed. In the simple terms introduced in the preceding, such a monitor must be able to detect all faults resulting in irrational CPU operation. In most modern digital avionic systems, the monitor which does these things is the so-called watchdog monitor (WDM) (or alternately the heartbeat or deadman timer monitor). The WDM usually operates in relation to the timer