Computer systems are becoming increasingly complex and frequently include a suite of computers operating together. For example, a military system used to track incoming missiles can divide various tasks necessary to accomplish the desired result, i.e., tracking and destroying the incoming missile, among a plurality of computers operating with a suite of computers. Each of the computers within the suite of computers is termed an Embedded Computer System (ECS) because it is embedded within a hardware system or sub-system. The specific ECS is also referred to as a target system because it is the "target" of development and/or analysis. Reference in this application to a "target-ECS" acknowledges the central role of the computers as the controlling agent of the system.
An ECS is usually programmed to perform a specific set of tasks within the system and operates in an environment generally transparent to the user. In other words, an ECS normally executes software in which the user interface is implemented as a system interface, e.g., a user interface of a computer controlled microwave oven. Hence, if hardware, software or interface problems occur within the ECS, the user may be informed that an error occurred within the ECS but has no means to interrogate the ECS and isolate the error.
Under controlled test conditions, the problem of debugging and developing an ECS has been remedied to a degree by connecting the ECS to an In-Circuit Emulator (ICE). An ICE is physically connected to the target-ECS, e.g., by an electrical connection plugged into the central processor socket on the ECS, and includes some type of control unit to interrogate, debug and develop the ECS.
A severe limitation in using an ICE to debug and develop ECS's is the amount of data necessary to re-create real time scenarios in which problems occurred. The real time data available for such purposes is generally limited by the amount of data that can be saved from instrumented flight and hot bench tests, which has proven to be inadequate to re-create an entire real time scenario.
Moreover, in current use an ICE is connected directly to the target-ECS. Thus, in an attempt to repeat a real time scenario, the target-ECS and its stimulus system must be used. The target-ECS and its stimulus system are typically expensive and limited resources.
Existing ECS data recording systems attempting to record sufficient data to re-create a real time scenario have proven to be expensive, unreliable and time consuming. Such systems typically cannot record or re-create the internal states of a target machine; must pre-process data before they can be used to analyze the real time events; require modification of the target system hardware and/or software; and require complex and cumbersome hardware inapplicable to real time flight tests.
The development and analysis of target systems on simulation systems typically results in efforts to work around the errors and limitations of the simulation. Currently, target systems are being considered acceptable if a very limited amount of data can be processed within the target system without producing any errors. Many of these same systems which are considered successful in a laboratory environment are producing unacceptable errors when introduced into a real operating environment where the types and sequence of data received by the target system are different from the data of the laboratory test.
Thus, nearly insurmountable integration and support problems result from providing an ECS to a user which, because of the inability to debug and verify the ECS reliably, produces run-time errors during real time execution. If the ECS is tested to determine the source of error, it will not necessarily produce the error when the original test data is used in an attempt to re-create the data input to the system. There is no assurance that the set of limited test data can be used to produce the same sequential events and corresponding execution states within the ECS which produced the run-time error.