Browse Prior Art Database

Data Configurable Diagnostic Controller

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

Publishing Venue

IBM

Related People

Gross, A: AUTHOR [+5]

Abstract

A tape drive device uses diagnostic microcode to diagnose itself. The diagnostic microcode must be organized in some fashion. A possible organization utilizes Object Oriented methodologies to allow normal "stream" diagnostics as well as parallel diagnostics. Also, idle time diagnostics are easily handled using Object Oriented methods. Finally, self-modifying or "learning" diagnostics can be achieved through an Object Oriented diagnostic controller.

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

Data Configurable Diagnostic Controller

      A tape drive device uses diagnostic microcode to diagnose
itself.  The diagnostic microcode must be organized in some fashion.
A possible organization utilizes Object Oriented methodologies to
allow normal "stream" diagnostics as well as parallel diagnostics.
Also, idle time diagnostics are easily handled using Object Oriented
methods.  Finally, self-modifying or "learning" diagnostics can be
achieved through an Object Oriented diagnostic controller.

      A Diagnostic Controller using Object Oriented methods of
analysis and coding is used.  The Diagnostic Controller is
configurable by data and is able to reuse pieces of diagnostics,
saving microcode.

      Each diagnostic is broken into smaller pieces called recipes,
and each recipe is broken into smaller pieces called steps.  A step
is a small test, such as a control store memory test or a hardware
register test.  A recipe is a group of related steps; i.e., a memory
test recipe could consist of a control store memory test, a buffer
memory test, and a buffer sparing test.  A diagnostic is a list of
recipes; i.e., a diagnostic could consist of a memory checkout
recipe, a hardware register check-out recipe, and a hardware
functionality recipe.  The Diagnostic Controller consists of three
main objects to represent these ideas:  Diagnostic, Recipe, and Step
(Figure).

      There are two types of diagnostics.  One type runs in a
straight line; i.e., the diagnostic is called, and it runs through a
complete list of tests one after another, then it ends.  The other
type of diagnostic is a circular list (a loop) and runs one small
test each time it is called.  This is reflected in the Object
Oriented models in the Diagnostic object supertype/subtype structure.

      The Diagnostics and Recipe objects are similar.  They are both
supertypes, and their subtypes have the same structure (Figure).  The
supertype is broken into two main subtypes:  a Loop subtype and a
Begin-End subtype.  The Begin-End subtype is further broken into two
more subtypes called a Master and a Slave.

      To explain what the subtypes shown in the Figure mean, take the
Diagnostic structure as an example.  As stated earlier, a diagnostic
is a list of recipes.  Therefore, a Loop diagnostic is a list of
recipes with no beginning and no end (it loops back to the start).  A
Begin-End diagnostic starts at a certain recipe, works its way
through a list of recipes and finally ends at a certain recipe.  The
Loop diagnostic runs one test in its loop every time it is called,
while the Begin-End diagnostic runs every test in its list every time
it is called.  This allows two very different functions: a diagnostic
that runs through a list of recipes and then yields a final overall
result (Begin-End diagnostic), and a diagnostic that performs one
small test and yields results on the small test (Loop diagnostic).

      In the Figure, the Begin-E...