With today's systems, multiple operating systems are typically supported on a single hardware platform. Since these systems usually share the same hardware features, diagnostics need to be written to support hardware failure analysis that works within any of these operating environments. For this reason, all TU packages must be designed with portability in mind.
Besides the operating environment differences, there is also the need for different types of user interfaces for the different execution environments. For instance, system diagnostics for the field may use a different interface than the hardware exerciser used in the design verification test.
By ensuring that the TU package performs no interaction with the user (output to screen and input from keyboard), one third of the problem will have been solved. Then all the invocations of the TUs will be made through one interface, and different types of user interfaces can be developed with no need to change the TU package.
Another third of the problem concerns how the device gets accessed through the operating environment. Since different operating environments have different device drivers (for example, UNIX drivers, DOS/WIN drivers, Firmware based, or generic I/O, there must be a way to isolate the functional test from the burden of knowing what driver/environment is being used for access. Therefore, standard device-access routines are needed to perform the device accesses on the functional test's behalf. The device accesses typically needed for functional tests are:
The interface of these routines must be independent of the underlying device-access method (that is, execution environment) by design, and must not change across operating environments. The internals of these routines will change per operating environment, using the appropriate system/driver calls to accomplish the device-access requests on the functional tests' behalf.