The Diagnostic System is a collection of application modules that work together to perform some software or hardware action. This collection of application modules are comprised of various distinct components.
The following figure illustrates the diagnostic architecture:
The architecture shows that the Diagnostic Controller has two main functions:
Tasks are operations that can be performed on a resource. Running Diagnostics, Displaying VPD, or Formatting a Resource, are examples of tasks. Service aids are also considered as tasks.
Resources are devices contained by the system unit. The diskette drive and CD ROM drive are examples of resources.
The Function Selection Menu contains selections allowing either resources or tasks to be displayed. When Task Selection is made and a task has been selected, a list of resources supporting that task is displayed. Alternatively, when Resource Selection is made, and a resource or group of resources are selected, then a list of tasks supporting the selected resources is displayed.
A Diagnostic Application or Task, may involve the use of Application Test Unit code, which in turn may involve the use of a Diagnostic Kernel Extension, or a Device Driver to gain access to the hardware.
The figure below illustrates the current AIX diagnostic structure that allows access to diagnostic function concurrent with system operation. AIX diagnostics for a given resource consists of an executable file containing Diagnostic Application code, which controls the execution of one or more Application Test Units. This executable is started by the Diagnostic Controller, which allows the user to select diagnostic modes and devices to test. To properly execute the Application Test Units, the Diagnostic Application currently must have detailed specific knowledge about each of the Application Test Units.
The exectu() interface is the call interface for Application Test Units, and contains all the information necessary to run the Application Test Unit against a particular device and return results. PDiagex is a special generic device driver written for use by Application Test Units, which can be used in place of the functional device driver to provide a simple direct interface to the device under test. Doing so places a greater requirement on the Application Test Unit to directly manipulate the device hardware, but in doing so, it provides earlier use of the Application Test Unit during the hardware bring-up and debug phase, since the Application Test Unit is not dependent on the availability of a working functional device driver.