Customized Instruction Generator

Cross reference is made to U.S. Pat. No. 4,591,983 for "Hierarchical Knowledge System."

The invention relates to instructions for installing and changing systems, and in particular to the generation of instructions for installing and changing or upgrading systems.

Computer systems are made up of multiple components which a customer may be required to assemble. Sometimes, a customer may desire to expand a computer system, and may be required to add components. The assembly or addition of components usually requires the placing of components in the correct physical position relative to other components and the cabling of the components together. It can be a complex task depending on the number of components making up the computer system.

Prior computer systems have been shipped to customers with instruction manuals for installation and upgrade. The instruction manuals may provide instructions for most of the components of a basic system, and may make reference to further instruction manuals relating to still more components. An example may be seen by looking at personal computers, where one component is the personal computer box containing a system board and a card for interfacing to a monitor. Another component is the monitor, and the customer is required to connect a cable between the monitor and the computer box. If the customer orders a disk drive device, a separate instruction manual may be needed, or a section in the manual for the computer box must be found in order to determine how to install the disk drive. The disk drive may consist of two components, such as a controller card and the drive itself. There may also be a need to set switches in both the system board and the controller card, with the switch setting being dependent on the rest of the components of the system and size of the drive. This procedure can be quite confusing when multiple options must be installed, or replacement components are required. A customer must search for the appropriate manual to determine how to install the option.

New computer systems in the mid range are much more complex to install than the simple example given above. The system may be made up of one or more racks into which a large variety of cards and devices are installed. The number of options available to customers in ordering such systems is so great that no two systems ordered may look alike, and be installable in the same manner. The use of a generic installation guide is not feasible. If an installation guide set forth instructions in order for one such system, installation of another, different system would cause skipping back and forth between sections of the guide during installation. Further, the guide would be extremely large if it provided sufficient detail for one to successfully install all possible varieties of system.

Customized instructions for a computer system installation or change are generated by an instruction generator program. A system description file describes a desired set of hardware components for the computer system. Each of the components is broken down by the generator into one or more installation tasks, and the tasks are sequenced in a desired order for installation of the components. The sequence of tasks is then assembled into an installation guide which is customized to each system.

The sequencing of the installation tasks is done by an expert system, which incorporates knowledge of installation experts into a series of rules. The experts have defined a detailed sequence of goals with associated tasks. The expert system sorts on the goals according to the list of desired components. It provides a list of all tasks required, sequenced in proper order.

The installation guide is put together using detailed graphic modules and text modules associated with the tasks, making installation of or change to a system very easy. Line drawings which are modified dependent on the components to be installed are also provided in the installation guide. Since the instructions are specifically tailored to the system which is to be installed or changed, all of the instructions are applicable. The instructions may be followed straight through to completion of the installation or change, thus drastically reducing the time and skill level required to install a system.

Since each task is described using its own graphic and text modules, an engineering change is not nearly as significant an event to the people involved in generating installation instruction manuals. In the past, an engineering change after the manuals were printed would result in either a reprinting of the manuals, or at the least an insert to the manuals. With the present invention, a few modules of text, and or graphics are revised. Since the instructions are generated uniquely for each installation or upgrade, the changes will automatically be incorporated in instructions generated after the changes. Once the system is installed or upgraded, the instructions are thrown away as each further change to the system will be described uniquely in a new set of instructions which is likely much smaller than the original set of instructions. There is no huge stockpile of manuals which need to be changed due to engineering changes.

The detail of instructions is also easily controlled. In one preferred embodiment, a very detailed level of instructions is generated. The graphics modules are very detailed, and are integrated with detailed text modules which refer to the graphics. In testing of instructions generated at this detail, it was found that a person with no prior installation skills could install a system in under an hour, where with prior art instructions some prior skills were usually required to even complete the installation. In further preferred embodiments, the instructions are drastically shortened for those which already have installation skills. One need merely have two sets of text and graphics modules to accomplish a variation in the skill level of the instructions generated.

FIG. 1 is a block flow diagram of the facilities used to generate a detailed installation guide in accordance with the invention.

FIG. 2 a more detailed block flow diagram of the flow in FIG. 1.

FIGS. 3a through 3c are descriptions of topology file records which describe different types of components.

FIGS. 4a through 4e are descriptions of element description file records, which provide further information describing components.

FIG. 5 is a description of component task file records which identify tasks associated with a component.

FIG. 6 is a description of intermediate file record which identifies tasks and contains a field for a representation of the sequence in which a task is to be performed.

FIGS. 7a through 7j are tabular representations of translate table files which provide detailed positional and instruction presentation information for, and graphic artwork associated with, each task.

FIG. 8 is a description of a hardware handling file, which identifies each sequenced task, and components associated with the tasks.

FIGS. 9a-9d when placed end to end are a logic flow diagram of a task identifier routine which identifies task associated with a component.

FIGS. 10a-10c when placed end to end are a flow diagram of a sequencer for sequencing the tasks identified in FIGS. 9a-9d.

FIG. 11 is a flow diagram of a translator program which associates specific modules of text and graphics with the tasks.

FIGS. 12a and 12b when placed end to end are a flow diagram of a task to graphics manager for generating line drawings and a script file for the customized instructions.

Appendix I is a description of records and an alphanumerical listing of names of fields used for these records, including definitions of the fields.

Appendix II is a compilation of English rules used by the sequencer of FIGS. 10a-10c in sequencing the tasks in a correct order for installation.

Appendix III is a list of variables and switches corresponding to selected tasks.

Appendix IV is a task summary table which lists tasks and task variations with corresponding components of the system.

Appendix V is a topology file for an order referred to as "0630100" and includes further files shown in FIG. 2 as well as the resulting installation instructions produced for that order.

In FIG. 1, a flow diagram indicated generally at 10 provides an overview of a system for generating detailed, customized installation instructions for the installation, change, and upgrade of a computer system. A topology file is provided by a topology file generator block 12. The topology file is a list of hardware components making up a computer system. The components are preferably items such as processor cards, equipment racks, cables, power supplies, disk drives, and I/O controllers etc.. While the invention is applicable to components at a much more detailed level, such as nuts and screws, one of the objects of the invention is to make installation of a computer system easily performable by a customer where a customer is an end user, service engineer or value added retailer. The components were chosen at a level of granularity consistent with what different customers might desire to select.

The topology files contain placement and connection information for each component. In the instance of a component to be installed in an equipment rack, it identifies a slot in the equipment rack, and what the component is connected to. When a customer wishes to change an existing system for varying reasons including replacement of components or addition of components, two topology files are provided by file generator 12. The first file being a current configuration, and the second file being an upgraded configuration.

A receiver/splitter/router 14 receives multiple topology files from the topology file generator 12. Several topology files may be received corresponding to different system installations and upgrades. In the preferred embodiment, several topology files of systems to be built or upgraded are processed in a batch job. The receiver/splitter/router 14 is a conventional program that receives batches of topology files from the topology file generator 12 and splits the batch into individual topology files for initial installations, or into pairs of files for an upgrade of an existing system.

Topology files are sent from the receiver/splitter/router 14 to a task generator/sequencer program 16. The sequencing program 16 is a blend of conventional software technology and expert system software technology. In processing a topology file or topology file pair, parentage of components is established and a number of installation tasks are identified, sequenced and formatted into a hardware handling file. Tasks are small units of work required to install or update a system. The expert system software is used to sequence the tasks.

The hardware handling file is passed on to a task to graphics interface manager 18 which creates customized line drawings, and sets up variables and generates a master script imbed file for scripting and printing. Variables are values of items being specified in the text of instructions, such as: "set address to .sub.------ ". Each variable is unique to a task and its associated component.

The line drawings and variables are integrated with selected text module names and graphics modules to create a master script imbed file.

The master script imbed file is passed on to a script manager program 20, which selects the graphics and text modules identified, and generates a formatted print file of complete, system unique, installation instructions. The instructions contain text and graphics in line with each other. A graphics print manager 22 routes the formatted print file to a graphics printer 24.

In FIG. 2, a more detailed block diagram of the instruction generating system is shown. The elements in the diagram will first be described in terms of the data it receives and the data that it produces. The manner in which the elements perform the data manipulations will be described later in this Description.

The process of generating installation instructions for a particular system installation or upgrade of a system starts with one or two topology files at 40. As previously defined, the topology files contain lists of components or elements of the system. The lists are preferably generated by an expert system configurator, such as that shown in U.S. Pat. No. 4,591,983 for "Hierarchical Knowledge System." The configurator is used during initial order placement for a new system by the manufacturer of the system. A customer will order a particular model number and several options from standard literature about the computer system. The configurator will check the validity of the system and will generate the lists which include information on the physical placement of components and their connection to each other. If a customer has not specified required components, such as the case where a disk drive is specified, but the essential controller for that drive was not specified, the configurator will add it. In other embodiments, a human expert will provide the topology file based on the customer order. The human expert can provide the same topology file, but may not be able to process the volume that the expert system can.

A single topology file is used for defining the elements of a new installation. When an upgrade of an existing system is to be performed, a current topology file is first generated which describes the elements of the system as it presently exists. This information is obtained by manually inspecting the system, or preferably, the original topology file for the system as shipped from the factory is stored on the system in permanent storage. The customer will then specify new elements to add to the system, and a second, upgraded topology file is generated by the configurator, or an expert based on the current file and the additional elements ordered.

Examples of the format of records within topology files, and the information contained therein which is utilized in the present invention is shown in FIGS. 3a through 3c. In FIG. 3a, a system topology description header record is shown. The header record is shown as a field name and a field descriptive name, and actually consists of a series of fields containing information which describes a system. There is one header record per system which describes customer information and matches a topology file to the customer order. Appendix I provides a more detailed definition of each field based on the field name.

FIG. 3b shows an element record, which describes characteristics of an element such as racks, cards, devices and other elements except cables. It contains version, parentage information, location information and further information associated with each element. There is one element record per element in the topology file. Parentage information identifies a hierarchy of components. A card cage is the parent of a card. A rack is the parent of a card cage.

FIG. 3c shows a cable record. The cable record identifies a cable, and also defines where it is connected by the use of From and To fields. There is one cable record for every cable in the system.

A task identifier 42 is preferably a procedural software program "layer 2", which receives the topology files 40, identifies tasks associated with the elements described and establishes parentage for each component. The task identifier 42 uses data from an element description file 44 and a component task file 46 and produces an intermediate file 48, which identifies tasks for installing the system.

The format of, and information contained in the element description file 44 is further detailed in FIGS. 4a through 4e. File 44 contains further information on all of the elements available to be ordered for a system. Each record provides detailed information of the element or component which is not practicable to be provided in the topology files because of the large storage requirements. Each of the FIGS. in the FIG. 4 series of figures describes a type of record which may be used to describe a particular component. FIG. 4a contains release level control information. FIG. 4b contains information relative to device to bill of materials (B/M), and conversion tables which are used for generating a list of parts for cross-checking by the installer or upgrader.

FIG. 4c is a basic element record which all elements have. It provides more detail about the component itself, including part numbers, internal names and physical characteristics.

FIGS. 4d and e are used in combination to generate a chart of communication lines to enable a customer to associate a line resource name with particular line characteristics such as communications protocols.

The format of a component task file record 46 is shown in detail in FIG. 5. It contains descriptions of installation tasks which are cross referenced with the component described in the topology file 40 and the element description file 44. Each task file is stored in accordance with the list in FIG. 5, which includes fields identifying the task type to execute, and a number of task identifiers. It also includes fields for defining the amount of time to complete the task, a field for a sequence number of the task in the installation instructions and several other fields which are also defined in Appendix I.

A TTYPE field represents the type of task. The types are divided into adding a new rack, upgrading a system, removing a component, installing a component and a universal task, which is a task associated with every upgrade o installation.

The first digit represents the type of task being performed: add, remove, modify, or Universal Tasks.

The second digit represents the class of hardware being addressed: RACK, DEVICE, CARD, etc.

A HANCD field identifies the type of handling a component is to receive, such as adding the component, removing the component or moving the component.

A HPCDN field is the unique name for a hardware element as used in software.

An ELMTP field defines the general physical class of a device, such as a tower, a tower mountable unit, a card or a cable. A tower as used here is a rack within which other elements of the computer system are mounted.

An ELMST field defines the logical class of a device within a physical type. The type of tower unit is described, such as disk drives, power interfaces, OEM reserved space . . . The types of cards and cables ar also defined.

A FILL1 field describes an expansion area which is used for future use.

A GROUP field contains a task group flag. It is used to identify tasks that are similar to other tasks and should be performed as a group to cut down the time required to perform them.

TIXRF is a general task cross reference number, and TIGRP specifies a unique number for each task description for an element.

PERSP defines a perspective to take when selecting a group of components to work on for a given task. Several perspectives are available including system, rack, extra, card cage/tail gate and pseudo tasks, which are tasks which are any actions or preparations other than physical tasks to perform an installation such as checking to determine that all components were shipped.

GLSQN is used to define tasks which belong together within a major goal sequencing group

UPDSQ is used to identify specific goal sequence points when specific tasks should be selected.

STATE defines the particular state of processing certain tasks. It has possible values of first, last, cabling, etc. Cabling is done only if cabling is required.

A DIRET field defines the direction of progressing through different perspectives of a system, rack, card cage etc. It can specify progressing from the highest location to the lowest location or from the lowest location to the highest location. It is used to sequence tasks so they do not interfere with future tasks.

POWST describes whether a system should be powered up or down when performing the task.

SUBCP identifies a particular sub component activity, such as terminator, address switch or voltage switch which is associated with installation of a component.

TCMTM is a field specifying an estimate of the task completion time. TCMTP is the primary time to complete the task, and TCMTA is an alternate time, if the task is in a group of tasks. TCMTA is usually less than TCMTP because it is assumed that performing similar tasks at the same time will reduce the time required per similar task.

MUPID is a model upgrade indicator. It identifies whether a component is related to a model upgrade.

PHPDN contains a descriptive name of the parent device of the component whose installation task is being described.

CABRL describes a cable end relationship to the location of the components the cable attaches to. The values are intra-rack or inter-rack.

HANLR is handler code which identifies whether the customer service person, etc. is doing the component handling.

CINTK identifies tasks which support the physical installation or removal of a component. The values are install task or disassemble task.

CLASS determines the values/variables to be set for a task.

SPCLS identifies a special class of values to be set for a task.

FIL15 is a reserved field.

The intermediate file 48 consists of a record as indicated in FIG. 6 for each task identified by the task identifier. The record is very similar to the component task file 46 records. The first few fields are exactly the same. Some fields are added from the topology file 40 and the element description file 44. Those are defined below:

TSEQN is a task sequence number. It specifies the task sequence number in relation to other tasks that must be performed.

TSKID is a task identification number which determines the task identification to graphics modules, and is made up of TIGRP and TIXRF from the component task file 46.

RPERM indicates whether a component is to be removed permanently, or temporarily if removed at all.

HPAGE identifies a hierarchical parentage of the component being handled. ELIL1-4 and LOCL1-4 are an element identifier and location code for a level 1, 2, 3 or 4 component. CORY 2-4 are vertical offsets of a device within a level. Levels refer to parent information. Level 1 is a rack, level 2 is a device, level 3, a card, and level 4 is a cable.

CPFC4 identifies a cable's parent feature code number. The feature code number corresponds to the cable's line speed, protocol, connection, and electrical interface.

The sequencer 50 is an expert system software program. It uses installation rules indicated at 52 which are written in expert system code. The rules are expressed as major task sequencing goals and detailed goal listings in Appendix II, the English sequence rules document 53. The goals embody a set of hierarchical rules. The only detailed rule is that the goals must be satisfied sequentially.

Sequencer 50 provides a sequenced intermediate file 54 consisting of records in FIG. 6 with the task sequence number field, TSEQN, filled in for each task. The file is organized with the lowest task sequence number first. The sequenced file 54 is then used by another conventional software program translator 56 to produce a hardware handling file 58. Translator 56 uses a translate table file 60 shown in FIG. 7 which contains multiple tables for translating the tasks obtained from the sequenced intermediate file 54.

The translate tables are used to enlarge the selection of text and/or graphics variations, based on record fields other than device type.

If a task requires a translation, it must have an alphabetic character in the second character position of the TIGRP field of the task ID, TSKID field in the intermediate file shown in FIG. 6. A PNLC task, as identified in a TSKID field, is used as an example. The PNLC task directs the installer to find a specified P/N cable, get 2 labels, write given information on the labels, put the labels on cable ends, select the proper end of the cable and route it into a rack.

The character in the second character position of the TIGRP field of the task ID selects an associated translate chart in the translate table. The actual task ID in this case is PNLClK. In this case, it is given that the second character is a "K", so FIG. 7a, row 1 is used. The ELMTP and ELMST fields are then examined to select a column of the chart. If the examination yields a B6, the translated task is PNLC122, where 122 is a version of the task for the inbound end of an external workstation cable. The word external is defined as meaning a cable that has only one end inside a given rack.

If the examination of the ELMTP and ELMST fields yielded a B1, the translated task is PNLCIC, and the new character "C" causes a second translation to occur. This time the DVRPQ field is evaluated to select a column in the "C" chart in FIG. 7b. If the evaluation yields 6018, the translated task is PNLC124, which is for the inbound end of an extended CEC-CEU cable. If the evaluation yields blank, then PNLC1P is the translated task, and the port chart "P" is used. The fields used for each chart are indicated next to the charts in the Figures.

Charts in FIGS. 7a through 7e correspond to particular text modules to be used for generation of instructions. Graphic charts are similarly expanded in FIGS. 7f through 7j, which include charts identifying graphics which are rotated 90 degrees to provide a better view for installation. Further charts refer to port extensions, and switch setting graphics modules.

In Appendix III, task IDs TIGRP, and an abbreviated title are listed in the left column of a table of variables and switches. The variable and switch names are listed across the top of the tables, and the definitions of the names are given on the last page of Appendix III. Tasks which may have one of the variables, are identified with an "X".

In Appendix IV, tasks (TIGRP) are again listed, and this time the rack, device product numbers, and card numbers are listed across the top of a table. The table is filled in with version numbers (TIXRF) of the different versions of text associated with each task dependent on the device, rack or card. With respect to the PNLC task--Label the Cable--previously discussed, one can see that there are multiple versions of the text.

111 is for the outbound end of an external DFCI cable

114 is for the outbound end of an external CEC-CEU cable

121 is for the inbound end of an external DFCI cable

122 is for the inbound end of an external WS cable

123 is for the inbound end of an external COMM cable

124 is for the inbound end of an external CEC-CEU cable

211 is for the first encounter of the outbound end of an internal DFCI cable

214 is for the first encounter of the outbound end of an internal CEC-CEU cable

221 is for the first encounter of the inbound end of an internal DFCI cable

224 is for the first encounter of the inbound end of an internal CEC-CEU cable

Each version has associated graphics/line drawings/lists.

111 uses RSLD208, 209, and 006

114 uses RSLD208, 210, and 202

121 uses RSLD208, 209, and 006

122 uses RSLD0ll, 208, 270, and 006

123 uses RSLD208, 209, and 006

124 uses RSLD208, 210, and 202

211, 214, 221, and 224 do not have any graphics.

The variables used with this PNLC task are RACK, CBLPN for cable part number, and CBLAB for cable label. These can be found in Appendix III.

An example of a task which uses switches is the PNSC--setup complete--task. Variables CTIE and MRACK are used to tell the installer when to install cable ties. The PNLA variable tells when to pack a hoist adapter tool used to lift some items into place, and the PLNR variable tells the installer to pack the hoist. All covers are closed, and some general housekeeping is identified. Version 100 is for initial install, 300 for upgrade where no reconfiguration is required, and 400 is for and upgrade where reconfiguration is required. Rack is a variable, and MRACK--multiple racks, CTIE--install cable ties, TCAW--more cables to install, PNLA (300/400)--lifter adapter required, and PNLR (300/400) lifter required are switches. All versions of this task use graphics/line drawings/lists RSLD154 and 184.

The hardware handling file 58 is shown in further detail in FIG. 8. Each task is now identified by a hardware handling record. Each record is comprised of the fields indicated in FIG. 8. Most of the fields have been previously identified in references to the element description file 44, the topology file 40, the component task file 46 and the intermediate file 48, from which the hardware handling file is derived. The hardware handling file 58 now contains a detailed set of fields most of which have been previously discussed. Subfields under the field HPAGE identify parentage of the component. The parentage includes what other components the component is attached to in the form of identifiers, ELIL 1-4, CORY 2-4 and a cables parent feature code number CPFC 4.

Some fields not described before include a NCBLE field which defines the number of cable ends to sequence, with up to three specifiable. A GRAPHID field is used to identify a graphics module for the instruction guide, and FIL13 identifies further expansion area. The record also includes the STDELEMT record from the topology file of FIG. 3b.

A task to graphic interface manager 64 then uses the hardware handling file 58, and further information from the element description file 44 and the TGIF data file 68.

The TGIF data file 68 is used to create customized line drawing files 72 and a script file 74 which contains names of customized line drawings of racks, card cages, and cable lists, and a sequential set of script module names and variables respectively to control generation of integrated in-line instructions by a task to graphics interface manger executive 80.

Information from the element description files are used in defining the line drawings. The line drawings are box-like drawings used to depict what an actual system will look like. One example of a line drawing is of a rack, with the devices drawn in as squares and rectangles. Size information for the devices is used to draw the squares and rectangles to size. Names of the devices are also obtained from the element description files, and are inserted into appropriate squares and rectangles. Similar line drawings are used for such things as a card cage, to show the location of cards, with the name of each card.

Script file 74 is simply a list of names or variables corresponding to text files to be incorporated into the instructions. It is based on the tasks identified, and is ordered in the correct sequence for installation of the system. The drawing files 72 are used to define drawings and graphics. Line drawings are used to illustrate things which are unique to each system and which do not require detailed graphics. Some examples as previously mentioned, include a line drawing of a rack, with names of other components positioned to correspond to the physical location of the actual component in the system. They are useful for showing the system before and after an upgrade. A further use is the identification of cards in a rack. The lines already exist, and the names are filled in by task to graphic interface manager 64 dependent on the configuration of the particular system to be installed. Drawing files 72 also include variables to select graphics files.

Text and Graphics sources are indicated at 82 and 84 respectively. The variables contained in the script file 74 and drawing files 72 are used to access the text for instructions and the graphics for the instructions. A composer 80 retrieves the instructions and graphics based on the variables, and integrates them with the customized line drawings to generate a formatted print file of complete, system unique, in-line sequential installation instructions. These are passed on to an all points addressable printer 94 which provides an instruction guide indicated at 94.

In Appendix V, a sample installation guide generated by the instruction generator is presented. Tasks are numbered in the upper left corner. This particular instruction is for a simple system installation. Most of the devices have already been installed in the rack, as seen in the line drawing used in task 3 to verify the content of the rack from the front. A back view of the rack is presented in task 12.

Also in Appendix V, is an updated copy of the translate table, including information used to perform the pseudo task processing block 242 in FIG. 11.

Appendix V shows a topology file consisting of multiple records having the formats identified in FIGS. 3a, 3b, and 3c, and corresponding to components for a system. Each row of characters is a record. The first row, where the fourth and fifth digits are "10", is a header record. "10" is in the RCDTP field, which is the record type field. There is only one header record for the topology file. A number in the first row "0630100" corresponding to the SYNUM field, is the system number of the topology file.

The fourth and fifth characters of each record identify the record type, "40" being an element record, "44" being a cable record, and "60" being a specify record. The next file is the intermediate file for the same system. Each line of alphanumeric characters corresponds to a task identified by the task identifier 42. The format for each task is indicated in FIG. 6.

The hardware handling file for the system is shown next. Again, each task is represented by one line of characters having the format shown in FIG. 8. The script file is shown next in Appendix 5 having script commands such as SE for setting variables and IM for imbedding modules. Finally the instructions resulting are shown for the system identified as "0630100".

One can easily trace from the script commands what text and graphics resulted in the instructions. Commands 15-22 resulted in the System Identification, Processor type-model number, and processor serial number being inserted on page 1 of the instructions. The next two commands indicating that TIME =1.4 and STIM =1.4 resulted in estimates on page 1 of 1.5 hours to install, and 1.5 hours that the system will not be available during installation. The second time may be less than the first for upgrades, since some tasks may be performed while the system is still running, such as checking to determine if all the components are correct. 1 hours is added to time in the commands for a fudge factor.

Each text module imbedded further imbeds the associated graphics files and line drawings required by the text module.

In FIGS. 9a through d, a flow diagram is detailed for task identifier 42. Task identifier 42 identifies tasks associated with elements described in topology files. It does this for both upgrades and initial installations, the difference being that two topology files are associated with an upgrade, and task identifier 42 determines which components are to be moved and which are merely to be added. It also establishes parentage for components. Then, it determines the tasks that need to be performed.

Initialization occurs at block 102 in FIG. 9a, including loading the program and allocating required resources. The element description file 44 is then read into an element description table at 104 from secondary storage. The element description file will be used from the element description table rather than from secondary storage to improve performance of the task identifier 42. There are easy references into a table format rather than from a straight file list and no further I/O activity is required.

The component task file 46 is also read at 106. An IDELTA (intermediate file 48) record is written for each "do always" task. "Do always" tasks are included, based on whether an upgrade, initial install or relocate is to be performed. All other tasks are placed into a component task table. At 108, the target element topology file is read from 40 and placed into a topology table. A list of added or moved elements is then built. The target cable topology file is read at 110, and a list of added or moved cables is built. If the instructions to be generated relate to an upgrade, as determined at 112, the current element and cable topology files (114-116) are read in and further lists of moved or removed elements and cables are determined.

Flow continues in FIG. 9b with initial installation flow starting at 120, and upgrade flow at 122 in separate paths. Much of the function is similar for both paths. Initial installation will be described first. A series of blocks are performed for each rack as indicated at 124. Blocks 126, 128, 130, 132, 134 and 136 select tasks for adding racks, for factory installed devices in new racks and for factory installed cards in new racks for each card in each card cage. Factory simply refers to those components already installed prior to receipt by a customer. For each task, an IDELTA record with parentage is written out. Tasks are also identified for each inter-rack cable starting at 138, 140, and 142, with IDELTA records for each task with parentage being written.

The flow is more complex for upgrades starting at 122 in FIG. 9b. At 144, the lists created in 114, and 116, referred to as a change table, are used to perform steps 146, 148, 150, 152, 154, and 156 on each rack in the change table. Tasks are selected for adding a rack, for factory installed devices in new racks and for each removed rack. An IDELTA record is built for each task with parentage information included, and is written to the intermediate file 48. Starting at 158, the same is done for each device in the change table. Again, at 160, 162, 164, and at 166, tasks for each new field installed or moved device, each removed or moved device, and at 168 and 170 for model changes are selected, with an IDELTA record built and written.

The steps are repeated starting at 172 for each card in the change table. Task selecting and IDELTA record build and writing occurs at 174, 176, 178, 180, 182, and 184 for new field installed cards or each card moved between card cages, for each removed card or for each card moved between cages, and for each card moved within a card cage. Starting at 186, the same steps are done for cables identified in the change table. At 188, 190, 192, and 194, the IDELTA files are generated and written for removed or moved cables, and for new field installed o moved cables. At 196, 198, and 200, the IDELTA files are generated and written for each modified device, and at 202, 204, and 206 for each modified rack. At 208, the task identifier 42 is ended, and the sequencer 50 continues with processing of the intermediate file generated by the task identifier.

As previously stated, sequencer 50 is an expert system software program which uses installation rules indicated at 52. The English language rules embodied in the rules 52 are expressed as major task sequencing goals and detailed goal listings in Appendix II. A short flow diagram is also presented in FIG. 10, which shows initialization at 210 during which, as for any program, external declares, flags, arrays, file definitions, selectors, and working memory are set up. At block 212, an ON ENTRY expert system rule is done for initialization for further control rules, such as setting a control working memory element flag to "ON". This initialization includes initialization and allocation of working memory into which files will be written.

A REQUEST rule at 214 is a control rule that is executed based on the control working memory element flag being turned "ON". In block 214, a next intermediate file to sequence is read into an area of working memory, and card addresses are calculated. A subroutine RCVRQST, block 218 in FIG. 10c is used to retrieve the next intermediate file's name. REQUEST block 214 is written to process a batch of intermediate files, and after reading each file, the working memory element flag is set "OFF", and SEQUENCE RULES indicated at 215 are executed. Since the sequencing rules are set forth in detail in Appendix II, the flow is abbreviated in FIG. 10a.

After sequence numbers have been assigned, a CLEANUP block 216 in FIG. l0b searches for the lowest sequence numbered record, and writes it into the sequenced intermediate file. After all the records have been found and written, the intermediate file is closed, and flow is returned to REQUEST block 214 for the next intermediate file. If all are done, an ON IDLE block 217 terminates processing of sequencer 50.

In a further embodiment of the expert system software program the task identifier 42 and the formatter 56 are incorporated into the program to form one common program. This eliminates the intermediate files 48 and 54, the delta hardware handling file 58, the TGIF data file 68 and the translation files 60. The task to graphic interface manager 64 is also broken up into routines and pulled into the common program.

The flow is thus modified so that all flags, arrays, and variables associated with the routines pulled into the common program are initialized. On entry, the reading of the element description and component task files is done. The request reads in the topology files into working memory, and calls a new routine to create working memory element tasks. The sequencing rules then sequence the working memory element tasks as before, and a cleanup routine calls the TGIM routines to build the flat drawings from the topology file/working memory elements. Then the cleanup routine then calls the TGIM routing that builds the script imbed file from the working memory element tasks for scripting and printing of the resulting instructions.

The rules in Appendix II precisely define the operation in terms better than that which applicants can envision by means of more detailed flow charts. A shorter statement of the rules follows:

1. Tasks which can be performed without powering-off the system will precede the tasks which require system power-off.

a. Load any new code into the system before powering-down the system.

b. If a direct access storage device (DASD) is being removed from the system, instructions on how to `back-up` the DASD are to be called out and the customer is to be advised to perform that function BEFORE taking the system down to make any changes.

c. If a change will require a system power-down, remove all AC power and remove the line cord from the outlet.

2. whenever possible, "Remove" tasks will precede "Add" tasks. This rule will facilitate an "Add" at a location previously occupied. (The "Move" task is accomplished by "a Remove followed by an Add".)

3. The task of "Power-On" and related steps will always be last. The only acceptable exceptions are tasks requiring an operational system.

4. A "Perspective" relationship will be established by Text and Graphics. The "Perspective" ordering is:

a. System perspective.

b. Rack perspective.

c. Device perspective.

d. Card Cage perspective.

e. Extra perspective.

f. Pseudo perspective.

5. Whenever possible, "Perspective" related tasks will be group together. (Do all tasks behind the RACK before moving to the front of the RACK)

a. Tasks from a "System" related perspective will have precedence over tasks from a "RACK" related perspective.

(1) IPL DASD back-up

(2) RACK Positioning.

b. For multi-RACK upgrades, RACKS will be sequenced beginning with the RACK farthest away from the RACK containing the CEC.

c. For multi-RACK upgrades, tasks relating to the first RACK will be completed before beginning the next RACK in sequence.

6. Within a "perspective area", "positional" sequencing must avoid scheduling tasks that make subsequent tasks more difficult.

a. When doing device REMOVES, work from the top to the bottom.

b. When doing device ADDs, work from the bottom to the top.

c. When doing card REMOVES, work from the right to the left.

d. When doing card ADDs, work from the left to the right.

7. Within "positional" sequencing, "like" tasks should be grouped. (ie-within RACK E, Unlock all DASD shipping clamps.) This rule, when invoked, will temporarily override the "positional:" rule during the sequencing of one task only.

8. Cabling Rules:

All cables will be treated as two "connect/disconnect cable end" tasks associated with the appropriate device(s)/card(s).

All cable tasks must have the cable identified number (EID) supplied in the task text. (This is the same cable identifier number used in the cable chart)

Intra-RACK cables will be treated as RACK elements. ie - The two "connect cable end" tasks will be consecutively sequenced, following installation of the associated device(s)/card(s).

For Inter-RACK cables, the two tasks will of necessity fall into separate "perspective" areas. When the initial cable end is installed, the instructions must state that the other end will be installed at a ater step.

For each "Remove cable end" task, if the cable end will not be re-attached before another cable is encountered, suggest that the cable be labeled.

For each "Install cable end" task, if it is the first end, and the other end will not be installed before another cable is encountered, suggest that the cable be labeled.

Returning to the structure described in FIG. 2, sequencer 50 provides the sequenced intermediate file 54 to the translator 56.

The translator program 56 flow is shown in FIG. 11. The translator program 56 is used to vary the text and graphics associated with the task. The text and graphics are varied dependent on the particular view desired, which end of a cable, and the type of cable to be installed. Further variation is dependent on the type of view desired in the graphics. Some views are rotated 90 degrees for better view for the installation of a component.

At 220 in the translator program 56 flow, the translation and pseudo task information from the translate table file 60 is read, and put into table form as seen in FIG. 7 for quicker access by the translator program. The pseudo task information is seen in a listing of the translate table file in Appendix V for a further preferred embodiment. A record corresponding to a task is then read from the intermediate file at 222 and it is determined if the last record has been read at 224. Processing is transferred for each record at 226 to a main loop processing section and then the next record is read at 228 and flow returns to 224 to check for the last record.

The main loop processing section starts at 230. Checks are made at 232 and 236 with the resulting actions indicated at 234 and 238. In both cases, nothing is done by the main processing section 230 with the task. If the task cleared the checks at 232 and 236, then cable labeling and table driven pseudo task processing is performed at 240 and 242. This is done substantially as described earlier, using different fields to cross reference into the tables to determine which variations of text and graphics to use for the task. At 244, the hardware handling record is made, and at 246, further translation tables are used to translate the task group's number and complete the graphic identification number, and output the result to the final hardware handling file.

Processing is then returned to 228 at 248.

Task to graphics interface manager TGIM 64

The TGIM 64 uses the hardware handling file 58, and further information from the element description file 44 and the TGIF data file 68 to create customized line drawing files 72 and a script file 74 which contains the names of customized line drawings, and a sequential set of script module names and variables to control generation of integrated in-line instructions by the composer 80. The logical flow of the procedural code used is shown in FIG. 12a and 12b.

Following initialization at 250, the IDELTA file is read through at 252 to perform look ahead functions (such as calculating the total installation time and system time, the number of people required, determine the special tools required, etc.).

At 254, an element description file is read into an element description table. Next, the target topology file is read into a target topology table, 256, a loose part list of field installed parts is built at 258, a flat drawing of the card cages is built at 260, both front and back drawings of each rack are built at 262 and 264, and a list of cards in each cage is built. The line drawings are done by building a script file which defines start and end points for lines to create different size boxes dependent on the size of the component. The boxes are then filled in using script commands with information such as name of the component, its location and logical address.

If the instructions are to be for an upgrade, 268, then the sequence of steps from 270 on is performed before flow is merged back together. There are no corresponding steps under 272 for initial install. At 274, the target topology file is read into the target topology table and a table is built at 276 for each element type such as rack, device card and cable. Flat drawings at 278, 280, and 282 are built for card cages and both the front and rear of each rack.

Both initial install and upgrade steps are the same for building charts for various cables at 284, 286, 288, 290, and 292. Finally the TGIM master file is built from the IDELTA file, setting script variables and flags. Flow is ended at 296, with the result being the list of script commands used to generate the customized instructions.

The customized installation instructions, as can be seen in Appendix V are very detailed, and provide even an installer with little technical experience sufficient guidance to install a system very quickly. By customizing the instructions to the particular system to be installed, an installer need not make any cross references to other manuals, thus reducing the chance for confusion and error. Detailed graphics of the components of the system are provided, clearly illustrating each step of the installation process. The line drawings are effectively utilized to give the installer positional information for installing specific components. In some cases, the graphic views are rotated dependent on which view more clearly illustrates the installation steps. Once the system is installed a rack configuration list, and cable list are provided for future reference, and the installation instructions are thrown away, as they only relate to the installation of the system they were generated for. Further upgrades, modifications, and even system moves will result in a new customized set of instructions detailing the steps involved in adding and removing components or moving the system. ##SPC1##