The architecture described in this document is primarily for the creation of "out-of-service" Test Units, meaning that the device being tested is not available for any other use by the operating system while it is under test. In high-availability systems, however, it is often desirable to have Test Units which can be used while the device is "in-service." This may be especially true for devices which can have partial failures; for example, DASD media, RAID, memory/cache arrays, and multi-port adapters. A variation of In-Service diagnostics can sometimes be done with an Out-of-Service Test Unit that takes over the device for such a short period of time that no service outage is detected.
Test units designed to be run truly concurrently with other operations on the same hardware component will, in general, have to perform their testing through the "normal" functional device driver installed by the operating system. Because the device driver model tends to be unique to each operating system, the Test Unit written to that interface may not be easily portable to other operating systems. However, proper structuring of the Test Unit library, as discussed below in "Recommended General Structure of Test Unit Code," will help isolate into a single source file those functions which must be modified.