Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Hardware Failure Simulator Scheduling and Automation Process

IP.com Disclosure Number: IPCOM000112819D
Original Publication Date: 1994-Jun-01
Included in the Prior Art Database: 2005-Mar-27
Document File: 6 page(s) / 234K

Publishing Venue

IBM

Related People

Abreo Jr, JE: AUTHOR [+6]

Abstract

Described is the automation of the Hardware Failure Simulator (HFS) operation, through inputs provided by pre-written Bug Files and Matches Files, and through Screens Files facilitating the analysis of the results of testing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 26% of the total text.

Hardware Failure Simulator Scheduling and Automation Process

      Described is the automation of the Hardware Failure Simulator
(HFS) operation, through inputs provided by pre-written Bug Files and
Matches Files, and through Screens Files facilitating the analysis of
the results of testing.

      The HFS provides a method of simulating hardware faults for the
automated testing of a Target System.  Through an interface between
the HFS and the Target System, indications are made to the Target
System that hardware faults, or "bugs," are at various locations
within the Target System.  This capability is used for testing the
Power-On Self Test (POST) and Diagnostics routines of the Target
System, to determine if these programs can accurately diagnose the
simulated failures.

      A Bug File is a text file residing in the host system used to
execute the HFS code.  Each Bug File usually has a file name
corresponding to its purpose, together with a .BUG file extension.  A
Bug File provides the details of one or more hardware failures that
are to be simulated by the HFS.  Matches Files enable the HFS to
advance automatically anywhere through the POST and Diagnostics
routines.  Screens Files enable the user to analyze the results of
testing after it has occurred.

      Before the HFS can be operated in an automated fashion, a
number of files must be prepared.  For each Bug File, there must be a
corresponding Matches file, which typically uses the file name of the
bug file, together with a .MAT file extension.  Alternately, a
Matches File may be assigned to each Bug file by means of the Setup
statement.

      Also, for each Bug File, two "expected output" files must be
created.  The first of these, having the file name of the Bug File
with a .POS extension, telling the automation process about known
POST errors, if any, for each bug in the Bug File.  Each line in this
file corresponds to one bug in the Bug File, with the word "none" on
a line indicating that no POST errors are expected for that bug.  If
a bug is expected to produce two or more errors, codes for these must
be listed on a corresponding line, separated by space(s).  Each error
code must be at least four characters long; a shorter code in the

.POS file is considered to be part of a longer code.  For the Target
System to pass the test, all listed codes must be found inside the
Screens File, and there must be no additional POST errors.  For
example, a BUGFILE.POS file may be as follows:

     00164 00201
        00164 00201  103
          None
        00301 08603

      In this example, the first bug is expected to produce two POST
errors, the second bug is expected to produce three errors, the third
bug is expected to produce no errors, and the fourth and all
subsequent bugs are expected to produce two new errors.  For each
number, the listed numbers can be a subset of the POST error which
actually occurs.  For example,...