Most commonly used debugging tools do not address the specific demands of real-time debugging. A few debugging tools specifically designed for real-time applications have been described in the literature, some of which focus on multi-processor debugging. For example, Remedy provides the ability to suspend the execution on all processors when a breakpoint is reached []. The DCT tool allows practically non-intrusive monitoring but requires special hardware for bus access []. Both RED [] and ART [] provide monitoring and debugging facilities at the price of software instrumentation. RED dedicates a co-processor to collect trace data and send it to the host system. The instrumentation is removed for production code. In ART, a special reporting task sends trace data to a host system for further processing. The instrumentation code is a permanent part of the application. It will never be removed to prevent alteration of the timing. Debugging is limited to forced suspension and resumption of entities, viewing and alteration of variables, and monitoring of communication messages. DARTS provides remote debugging by replaying portions of a time-stamped program trace, which is produced during program execution []. The debugging is limited to a restricted set of events and only supports a subset of the functionality of common debuggers, e.g. excluding data queries. The high volume of trace information and the associated overhead of trace generation may also limit its application to programs with short execution times.
In the absence of real-time debuggers, hardware simulators are often used, which run about three orders of a magnitude slower than the actual application []. This performance overhead commonly limits the feasibility of extensive software testing and debugging.