HK1071610B - An apparatus for installing and /or testing software on a target computer system - Google Patents

Description

Device for installing and/or testing software on a target computer system

The present application is a divisional application of the chinese patent application entitled "system apparatus and method for implementing software installation and testing for a customized computer system" filed 28/8/1998, application number 98118805.2.

Technical Field

The present invention relates to computer system diagnostics and, more particularly, to a method of arranging a sequence of steps for software installation and/or testing of a computer system.

Background

Personal computers, and particularly IBM compatible personal computers, have found widespread use in providing computing power to various communities. In general, a personal computer system may be defined as a desktop, floor, or portable microcomputer, including: a system unit with a system processor and corresponding volatile and non-volatile memory, a display monitor, a keyboard; one or more floppy disk drives, a fixed magnetic (optical) disk storage device, and optionally, a printer.

It is known to install software and test computer systems before they are shipped to business or personal customers. The purpose of software installation and testing is to efficiently produce useful, reliable computer systems that will not be subject to error and that will immediately operate when delivered to business customers or individuals. Typically, testing is to detect and analyze errors that occur in the hardware and software portions of a computer system. An incomplete list of computer system hardware tests may include: diagnostics of hardware components such as processors, memory, magnetic (optical) disk storage, sound devices, drawing devices, keyboards, mice, and printers. Software installation typically includes: the desired software package is installed onto the computer system, the appropriate environment variables are prepared for the computer, and the appropriate initialization files are prepared for the installed software. Software testing typically includes: it is confirmed that the computer system has been installed with the desired version of the software and that the computer system has the appropriate driver.

It is well known in the industry to install software and test a computer system during manufacture by executing a fixed program before sending the system to a customer. For example, a diskette is created that contains certain diagnostic tests appropriate for a certain type of computer system. The floppy disk contains a lengthy and often complex set of files that guide the software installation and diagnostic process. The diskette also contains all the execution files for testing the purchased computer system.

Each manufactured computer system is provided with a corresponding copy of such a floppy disk. During the manufacturing process, these disks are always accompanied by the computer system being manufactured, and the testing is performed on each computer according to the order inherent in the batch file. If modifications to the process are required, then the batch file needs to be modified accordingly by adding/deleting portions to/from the batch file code. Since the various computer systems share the same lot diagnostics, changes to the lot will cause corresponding changes to the test parameters (including the steps at which the test is performed) of each subsequent manufactured computer system.

While such diagnostic arrangements have had some degree of effectiveness in improving the reliability of the pre-shipment computer system, there remains room for improvement. For example, as testing continues to become more complex and thorough, the batch and execution files of diagnostic tests often exceed the storage capacity of the floppy disk. Moreover, it is often difficult or impossible to perform specialized tests and software installers on a single custom computer system or on one type of computer system without modifying the tests on other systems or other types. Also, it may be difficult or impossible to modify the order of software installation or testing for a single custom computer system or class of computer systems without modifying the order for other systems or classes. Finally, the often complex nature of current batch file structures makes it difficult for manufacturers to quickly and efficiently perform error finding or maintenance testing and software installation procedures. Accordingly, it is desirable to devise an improved method of software installation and testing of computer systems before they are shipped to customers.

Disclosure of Invention

The present invention provides a system apparatus including a database for use in manufacturing a customized computer system, comprising: a step table containing a set of software installation and testing steps that are common among different components of substantially all computer systems manufactured by the system apparatus, wherein during manufacture of the customized computer system, the system apparatus performs a specified software installation or testing step to facilitate a corresponding software installation or testing of the customized computer system, the step table containing a postcode attribute identifying whether to shutdown or restart after performing the corresponding step; and a parts table in combination with the steps table, the parts table containing a set of substantially all possible parts included in each computer system being manufactured, wherein a specified software installation or test step to be performed by the system device is determined based on a corresponding part included in the custom computer system.

The present invention also provides a system apparatus including a database for use in manufacturing a customized computer system, comprising: a step table containing a set of software installation and testing steps that are common among different components of substantially all computer systems manufactured by the system apparatus, wherein during manufacture of the customized computer system, the system apparatus performs a specified software installation or testing step to facilitate a corresponding software installation or test on the customized computer system, the step table containing a maximum instance attribute to indicate a maximum number of times a corresponding step is run; and a parts table in combination with the steps table, the parts table containing a set of substantially all possible parts included in each computer system being manufactured, wherein a specified software installation or test step to be performed by the system device is determined based on a corresponding part included in the custom computer system.

The present invention also provides a system apparatus including a database for use in manufacturing a customized computer system, comprising: a step table containing a set of software installation and testing steps that are common among different components of substantially all computer systems manufactured by the system apparatus, wherein during manufacture of the custom computer system, the system apparatus performs a specified software installation or testing step to facilitate a corresponding software installation or testing of the custom computer system, the step table containing a phase attribute to indicate at which manufacturing phase a step should be performed; and a parts table in combination with the steps table, the parts table containing a set of substantially all possible parts included in each computer system being manufactured, wherein a specified software installation or test step to be performed by the system device is determined based on a corresponding part included in the custom computer system.

The present invention also provides a system apparatus including a database for use in manufacturing a customized computer system, comprising: a step table containing a set of software installation and testing steps that are common among different components of substantially all computer systems manufactured by the system apparatus, wherein during manufacture of the customized computer system, the system apparatus performs a specified software installation or testing step to facilitate a corresponding software installation or testing of the customized computer system; a parts table associated with the steps table, the parts table containing a set of substantially all possible parts contained in each computer system being manufactured, wherein a specified software installation or test step to be performed by the system device is determined based on a corresponding part contained in the custom computer system; a category relationship table associated with the step table, the category relationship table indicating a relationship between a set of software installation steps and each category of computer system being manufactured; a category component relationship table associated with the step table, the category component relationship indicating a relationship between a category of the computer system and a set of components; a component step relationship table associated with the step table and the component table, the component step relationship table indicating relationships between a set of software installation test steps and a set of components.

In addition, the present invention provides a method for installing software onto a computer system and testing the computer system, comprising the steps of: receiving an order from a customer's desired computer system and converting the order into a computer-readable parts list containing a set of substantially all possible parts contained in each manufactured computer system; reading a plurality of components from the converted component table and retrieving from a database a plurality of software installation test steps corresponding to the components, wherein each of the software installation test steps has a serial number; generating a software installation test step table by sorting the steps retrieved from the database in a predetermined order according to the sequence numbers of the steps, the step table comprising a set of software installation test steps that can be used in common for substantially all of the different components of the computer system being manufactured; and executing the software installation testing steps in a predetermined order according to the sequence numbers of the steps in the generated step table through network connection.

The present invention also provides an apparatus for installing software onto a computer system and testing the computer system, comprising: means for receiving an order from a customer's desired computer system and converting the order into a computer-readable parts list containing a set of substantially all possible parts contained in each manufactured computer system; means for reading the plurality of components from the converted component table and retrieving from a database a plurality of software installation test steps corresponding to the components, wherein each of said software installation test steps has a serial number; means for generating a software installation test step table by sorting the steps retrieved from the database in a predetermined order according to their sequence numbers, said step table containing a set of software installation test steps that can be used together for substantially all of the various components of the computer system being manufactured; and means for executing the software installation test steps in a predetermined order by the sequence number of the steps in the generated step table through a network connection.

Thus, the described method and apparatus provide for efficient software installation and computer testing that enables straightforward error finding and customization of the custom computer. The modular design of the design advantageously enables basic maintenance of the test system and rapid generation of step sequences for new computer systems and classes.

The foregoing and other objects, features and advantages of the invention will be further explained and more readily understood by reference to the following detailed description of the preferred embodiments.

Drawings

Fig. 1 is a schematic diagram showing software installation and testing.

FIG. 2 is a diagrammatic view of software installation and testing according to another embodiment.

FIG. 3A is a flow diagram of converting a computer order into a system descriptor record according to the present invention.

FIG. 3B illustrates a portion of an exemplary computer order, a basic component record (BAR) file, and a system descriptor record.

FIG. 4 is a flow chart of a sequence of steps for generating and providing a sequence of steps.

FIG. 5 is a more detailed flow chart of generating a sequence of steps.

Fig. 6 shows the structure of a database.

FIG. 7 is a flow chart of modifying a system descriptor record and a sequence of steps.

Fig. 8 shows an example of a step file before execution.

Fig. 9 shows an example of a step file after execution.

Fig. 10 is an operational flow diagram of a program that executes a sequence of steps.

FIG. 11 is a more detailed operational flow diagram of the FIG. 10 program executing a sequence of steps.

Detailed Description

A detailed description of the best contemplated mode for carrying out the present invention is provided below. The description is intended to be illustrative and should not be taken to be limiting. The same or similar elements and modules may be referred to by the same reference numerals throughout the several views. In the description, a module is defined as a command or a set of commands.

FIG. 1 is a schematic diagram of a software installation and testing system 90. In operation, the purpose of order 92 is to purchase a customized target computer system 160. Target system 160 is manufactured to contain a number of hardware and software components. For example, target system 160 may have a certain brand of hard drive, a certain model of monitor, a certain brand of processor, and a certain version of operating system. The multiple components are installed and tested before target system 160 is shipped to a customer. Such software installation and testing will advantageously ensure that there is a reliable and properly functioning computer system that can function upon arrival.

Because different types of computer systems and different personal computer components require different software installation and testing steps, it is necessary to determine which tests need to be performed on target system 160 and in what order to perform the tests in order for an efficient software installation and testing process to be achieved. Step maker 140 is a computer system designed to arrange a sequence of software installation and testing steps to be run on target system 160. To arrange the sequence of software installation and/or testing steps, step maker 140, or more specifically sorting program 204 residing on step maker 140, first reads a plurality of component descriptors from descriptor file 96. The descriptor file 96 is obtained by the conversion module 94 converting the order 92 corresponding to the desired computer system having the desired component into a computer readable format.

The component descriptor is a computer-readable description of the components of target system 160 whose components are defined by order 92. In the preferred embodiment, the component descriptors are contained in a descriptor file, referred to as a "system descriptor record," which is a computer-readable file containing a listing of the components, including hardware components and/or software components, that are to be installed on target system 160. The sequencing program 204, after reading the plurality of component descriptors, extracts a plurality of software installation and/or test steps corresponding to the component descriptors from the database 100 via the network connection 110. The network connection 110 may be any network connection known in the art, such as a local area network, an intranet, or the internet. The information contained within the database 100 may be updated by modification as indicated by arrow 130.

Having extracted software installation and/or testing steps appropriate for target system 160, sequencing program 204 arranges the steps into a sequence according to a sequence number corresponding to each step in a predetermined order. After the sequence of steps required by target system 160 is scheduled, sequencing program 204 writes a series of output files on step tray 150. In the embodiment shown in FIG. 1, the output files include text files containing command lines appropriate for performing appropriate software installation and/or testing steps on target system 160. This execution is performed in a predetermined order according to the sequence numbers corresponding to the respective steps. The step disk 150 is always associated with the target system 160 in the factory and is tested either directly from the step disk 150 or from a file server 190 connected to the target system 160 via a network connection 180. Network connection 180 is preferably a general purpose network device that plugs into a corresponding network port of the target system. After the software installation and testing steps are performed, the results of the installation and testing are logged back onto file server 190 through network connection 180.

FIG. 2 is a schematic diagram of a software installation and test system 192 according to another embodiment of the invention. The customer places an order 92 to purchase the customized target computer system 160. Target system 160 is prepared to contain a number of components, including hardware components and/or software components. A number of components are installed and tested before the target system is shipped to the customer. Such installation and testing advantageously ensures that a reliable, properly functioning computer system is operational upon receipt by a customer.

To arrange the sequence of software installation and testing steps, the sequencing program 204 reads a plurality of component descriptors from the descriptor file 96. The order 92 is converted to a descriptor file by a conversion module 94. The component descriptors are some computer-readable specifications for the various components of target system 160. In the preferred embodiment, the component descriptors are contained in a descriptor file called a system descriptor record, which is a manifest containing information about each component, including hardware and software, that is to be installed on target system 160. The system descriptor record may be stored directly in the file server 202. The sequencer program 204 extracts from the database 100 a plurality of software installation and/or testing steps corresponding to the component descriptors. Having extracted the appropriate software installation and/or testing steps for target system 160, sequencing program 204 sequences the steps in a predetermined order according to the serial numbers corresponding to the various steps. After the ordering of steps required by target system 160 has been performed, ordering program 204 directs the execution of these software installation and testing steps to target system 160 through network connections 195 and 180 in a predetermined order. Network connection 200 is desirably a general-purpose network device that plugs into a corresponding port of target system 160. Network connection 195 may be any network connection known in the art. After the software installation and/or testing steps have been performed, the results of the installation and testing are logged back onto the file server 202 via the network connection 200 or stored in a suitable database. As is apparent from the figure, a separate step maker computer system 140 as shown in FIG. 1 is not required here. In addition, the step disk 150 is also not required. Conversely, only one support disk (boot disk)220 needs to accompany target system 160 within the plant, and the support disk 220 is designed to support target system 160.

Having generally described the software installation and testing system, attention will now be directed to a more detailed description of the operation of the system presented in fig. 1 and 2.

FIG. 3A illustrates a preferred process for converting an order for a computer system into a computer readable system descriptor record. More specifically, in item 300, an order for a target computer system is received. This order may be in any of a myriad of forms. For example, a variety of different order formats and order delivery mechanisms are possible. For example, the order for the target computer system may be sent by telephone, mail, or over a computer network (e.g., the Internet). Regardless of the route by which the order is taken, and regardless of the form of the order, the order will always contain the type of target computer system that the customer desires, and may also contain an explicit listing of certain specific components that the customer desires to contain on the target computer system. After receiving the order, control transfers to the sending module 310, during which the order for the target computer system is sent over a computer network to a manufacturing system (not shown) that produces the target computer system. The target computer system order is also provided to the software installation and testing system where it is communicated to a conversion program located in module 320. The computer network for module 320 may be any known in the art.

The conversion program converts the target computer system order into a record useful for the manufacturing process. More specifically, the conversion program in block 330 first converts the computer order into a record called a BAR (basic component record) file. The BAR file preferably contains a unique identifier that identifies the particular target computer system being manufactured. The BAR file also contains a detailed listing of the components that are to be included in the target system, which may be both hardware and software. In addition, it is also desirable that the BAR file contain a part number or other useful identifier for the particular manufacturer of each part. Finally, the BAR file may also contain information about the customer, such as name, address, and phone number.

After the BAR file is generated in block 330, a system descriptor record is generated in block 340. In the preferred embodiment, the system descriptor record is a computer readable descriptive file of hardware and software to be included in the target computer system. In a preferred implementation, the system descriptor record contains a list of target system components in a format that includes hardware tags, software tags, information tags, and notes. The hardware tag indicates to sequencer 204 that information about the hardware component is located after the tag. Similarly, a software tag specifies that information about a software component is located after the tag. The information tag indicates that general information follows. The remarks are such that various statements may be included in the system descriptor record, but the sorting program 204 will not. It is desirable that the system descriptor record be a text file that is naturally human readable and easily understandable. Such a file would facilitate easy error and maintenance during installation and testing. It should be appreciated that the system descriptor record may be any list of unique identifiers corresponding to a set of unique tags, for example in a simple example the system descriptor record may be a list of part numbers.

FIG. 3B illustrates an exemplary target computer system order 350, a corresponding BAR file 360, and a corresponding system descriptor record 370. Target computer system order 350 contains the name of the computer class, in the figure the "X" class. The computer system order 350 also contains 3 exemplary hardware components: a Pentium (Pentium) processor, a hard drive, and a monitor. The BAR file 360 is obtained by running the conversion program on the target computer system order 350, as shown in block 320 of fig. 3A. BAR file 360 contains a unique identifier for a particular target computer system that belongs to class X. BAR file 360 also contains part numbers for the particular manufacturer of each part listed in the target computer order. In addition, BAR file 360 contains an identifier that indicates the desired number of each part and a written description of each part that is to be included in the target computer system. The system 90 utilizes the BAR file 360 to generate a system descriptor record 370.

As shown, the system descriptor record 370 also contains a unique identifier for a particular target computer system belonging to class X. In addition, the system descriptor record 370 also contains corresponding labels that here indicate that the processor, hard drive, and monitor are all hardware components rather than software components. The system descriptor record 370 also illustrates these components in a textual description. Also, the exemplary system descriptor record 370 also contains a software tag that indicates that certain software should be installed into or tested on the target computer system belonging to class X. For example, a software tag may indicate that an operating system for a Pentium processor should always be installed on a hard drive of a target computer system that belongs to class X.

In fig. 4, a preferred overall method of arranging a sequence of software installation and testing steps is given. In block 400, a unique target computer system identifier is generated for target computer system 160. In the embodiment shown in FIG. 1, a user sitting in front of step maker computer system 140 provides the unique identifier (e.g., BAR identifier acting as a tracking code) to the sequencing program 204 of step maker 140. Alternatively, in the embodiment shown in FIG. 2, the unique identifier is automatically read into the sequencing program 204 upon receipt of the target computer order.

In block 410, a system descriptor record corresponding to the BAR identifier is set. In the embodiment of FIG. 1, the system descriptor record is set either by network connection 110 or by network connection 195. In the embodiment of fig. 2, the system descriptor record is set by network connection 195. In block 420, the set system descriptor record is provided to the sequencer 204. In the FIG. 1 embodiment, the sequencer program resides on the step maker computer system 140, while in the FIG. 2 embodiment, the sequencer program resides on the file server 202. The sequencer program 204, working in conjunction with the database 100 of fig. 1 and 2, schedules a sequence of software installation and testing steps for the target computer system 160. When the sequence of software installation and testing steps appropriate for a particular target computer system is scheduled, the sequencer 204 will immediately generate an output file, as shown in block 430.

In the embodiment of fig. 1, the output files are preferably written onto the step disk 150 (see fig. 1) in the form of 6 separate files. These 6 files are: (1) a step file, (2) a setenv. bat (set environment. batch) file, (3) a qt.txt (quick test. text) file, (4) an et.txt (extended test 1. text) file, (5) an etlast.txt (extended test 2. text) file, and (6) an ft.txt (final test. text) file. Desirably, the step file is an ASCII (american standard code for information interchange) text file containing a list of appropriate command lines for performing the software installation and testing steps for the customized target computer system. In a preferred embodiment, the step file also contains commands, which may be of the cyclic type. More specifically, the step file allows the command to be repeatedly executed a certain number of times, or for a certain length of time. Such a format advantageously allows the software installation testing steps to be repeated in a computationally derived predetermined manner. The setnv. It should be noted that in one mode of operation, only the step file and the setenv. Bat files are ASCII text files that contain a list of appropriate command lines for performing the installation and testing steps of the target computer system. The Qt.txt, Et.txt, Etlast.txt and Ft.txt files are preferably all ASCII text files containing a listing of some appropriate command lines for the target computer system in the quick test (Qt), extended test 1(Et), extended test 2(Etlast) and final test (Ft) phases of manufacture, respectively, for performing the software installation and testing steps of the target computer system.

On the other hand, in the embodiment of FIG. 2, the output file is not written to the step disk of FIG. 1. Instead, the output files are resident in file server 202 or file server 190, and the output files are resident in file server 202 or file server 190, where they are used to direct the execution of software installation and/or testing steps on target computer 160.

Fig. 5 shows a more detailed flow diagram of the sort program operation 204 shown in fig. 1 and 2. At block 500, a system descriptor record corresponding to the target computer system 160 is provided to the sorting program 204. In block 510, a component descriptor is read from the system descriptor record. Each component descriptor describes a respective hardware or software component of the target computer system.

Returning to FIG. 3B, the line of the system descriptor record of block 370 containing the Pentium processor is an example of a component descriptor. At block 520, the sequencer program 204 generates a plurality of export targets (files) corresponding to the plurality of components of the target computer system 160. In the preferred embodiment, these export targets are used to store information obtained from database 100 regarding software installation and testing steps that need to be run on target computer system 160. In block 550, software installation and testing steps associated with the various components of the target computer system 160 are extracted from the database 100 and stored in the corresponding export targets. In the embodiment of fig. 1, these steps are extracted through the network connection 110; while in the embodiment of fig. 2, these steps may be taken directly from the file server 202. To clarify how these steps are extracted from the database 100 in the preferred embodiment, a description of the preferred structure of the database is first needed.

Fig. 6 shows a design of the database 100. Database 100 associates a predetermined sequence of software installation and/or testing steps with various computer system categories. In addition, database 100 is also designed to associate various computer system components with various computer system categories. Also, database 100 associates software installation and/or testing steps with components of the computer system.

The database 100 is preferably a relational database. The database 100 contains several tables, each containing some attributes suitable for generating the above-mentioned associations.

The database 100 contains: step table 102, system class table 104, system step sequence table 106, component table 108, system component table 112, and component step table 114. In the preferred embodiment, each table contains a list of attributes, with the next-lined attribute used as the primary index (primary key).

The step table 102 contains a set of software installation and testing steps that are common among the various components of all kinds of computers. In the preferred configuration, the attributes of the step table 102 include: step ID (ID: identifier), phase, name, command type, after code (Aftercode), and maximum case. The "step ID" is a unique identifier code for each software installation or test step. The "stage" indicates at which stage of manufacture the step should be performed. For example, "stage" is a corresponding integer selected from 4 stages of manufacturing a computer system, the 4 manufacturing stages being: (1) quick test, (2) extended test 1, (3) extended test 2, and (4) final test. The "name" is a string that specifies a name that describes the step. A "command" is a string that specifies an executable command line for performing a software installation or test step on target system 160 (see FIGS. 1 and 2). "post code" is an identifier that specifies whether to pause or to re-support (reboot) after the software installation or testing step is performed. The "maximum case" is an identifier that specifies the maximum number of times the step is allowed to run. Finally, the "class ID" identifies a certain type of component that is associated with the software installation or testing step.

The system class table 104 identifies a class of computer system using an identifying integer specified in the attribute "system ID". The system category table also has a string indicating the name of the category.

The system step sequence table 106 is a relational table that contains some of the relationships between the step table 102 and the system category table 104. The sequence table of system steps 106 contains: a class identification integer specified in the attribute "system ID" that indicates a particular class of computer system (according to the system class table 104); a step identification integer (according to table 102) specified in the attribute "step ID" that specifies a particular set of steps corresponding to the category; and a sequence number. The sequence number is preferably included in the attribute "sequence number" which indicates that the various steps corresponding to a particular category are ready to run in a certain predetermined order. The test engineer specifies individual serial numbers that are unique during the various manufacturing stages, and the order of the serial numbers should be selected to be most efficient for a particular target system. It should be noted that other methods of assigning sequence numbers may be used.

Parts table 108 includes all parts that may be included in a computer system under manufacture. The attributes of this table are preferably: "part ID" which assigns an identifier to each part; "name description" which assigns a string name to each component; and a "class ID" that corresponds to the type of component (e.g., hard drive, CD-ROM drive, etc.).

System component table 112 is a relationship table that contains a computer system class and a set of relationships between components that can be contained in that class. The attributes of the system component table 112 are: the computer type identification integer specified in the attribute "system ID" (from the system type table 104) and the component identification integer specified in the attribute "component ID" (from the component table 108).

Component step table 114 is a relationship table that contains relationships between a component and a set of software installation and testing steps for that component. The attributes of the parts step table 114 are: the component identification integers specified in the attribute "component ID" (from component table 108) and the step identification integers specified in the attribute "step ID" (from step table 102).

How the above-described database design is used to extract software installation and testing steps will now be described with reference to the exemplary target computer system shown in FIG. 3B. A computer class identifier in the system descriptor record that specifies class X results in the system ID in the system class table 104 to correspond to class X. The component table 108 is used to check whether the target computer system components listed in the target computer system order are "legal" (allowed). In other words, the sequencing program and database check whether the processors, hard drives, monitors, and software contained within the system descriptor record of FIG. 3B have a corresponding entry in the component table 108 and the corresponding integer specified by the component ID. If a component is illegal (i.e., if a component is not contained in the system descriptor record in the component table 108), an error flag is raised. The system component table 112 is a relational table that contains mappings from the component table 108 and the system class table 104. The system components table 112 contains all of the legal components that can be included in the target computer systems belonging to category X. The system component table 112 may be used to check whether all components of the target system are legitimate. In other words, the sequencing program and database will determine whether the processors, hard drives, monitors, and software contained in the system descriptor records of FIG. 3B all have a correspondence in the system component table 112. If a component is illegal (i.e., if a component in the system descriptor record cannot be contained in the target system belonging to category X), an error flag is raised.

The relationship table in the system step sequence table 106 contains the mapping relationships from the step table 102 and the system seed table 104. System step sequence table 106 contains all software installation and testing steps that can be legally run on a target computer system belonging to category X. Furthermore, it is in this system step sequence table 106 that a sequence and phase number is associated with each software installation and test step. These sequence and phase numbers represent the proper order in which the steps should be performed by a particular type of computer system. Thus, the system step sequence table 106 contains both a list of the individual steps that are to be run on the class X target computer system, as well as a sequence and phase number that represents a predetermined order to be followed in executing the individual steps.

The parts step table 114 is a relationship table that contains mappings from the parts table 108 and the step table 102. The component step table 114 contains software installation and testing steps to prepare the processor, hard drive, monitor, and software running for the target computer system.

Extraction of software installation and testing steps for preparing the various components contained in the target computer system to run involves performing a join operation on the system components table 112 and the component steps table 114, by which a neutral list of a set of steps to be performed on the various components of the target computer system 160 is obtained.

The result of the join operation is a list of steps that will be performed on the processors, hard drives, monitors, and software listed on the system descriptor record of FIG. 3B. The combined results of system component table 112 and component step table 114 will then be combined with system step sequence table 106 containing all steps of category X. The result of this joint operation is ordering information in the form of sequence numbers and phase numbers, where each sequence number is unique within a particular phase. Thus, the union of the three tables of system component table 112, component step table 114, and system step sequence table 106 produces the appropriate software installation and testing steps and sequencing information in the form of serial numbers and stage numbers for installing and/or testing software on target computer 160.

If the result of the first join operation (the join of system component table 112 and component step table 114) is an empty group, then an error condition will be indicated because an empty group means that some component that is to be included in the target system does not belong to the category listed in the system descriptor record. An example of this is explained below. Assume that a system descriptor record correctly indicates that a target computer system belongs to the Y category. It is also assumed that the system descriptor record incorrectly specifies that a hard drive (hard drive Z) belonging only to class X target systems is to be included in class Y target systems. In this case, the part step table 114 contains steps corresponding to the hard drive Z. The system component table 112 contains components corresponding to the category Y. The association of the component step table 114 with the system component table 112 will then produce an empty group because hard drive Z is not a component corresponding to class Y (in fact it only corresponds to class X). As is evident from the above example, the preferred design of the database advantageously allows one to ascertain: a target system of a certain kind will only contain components suitable for that kind.

Referring again to FIG. 5, after steps have been taken with respect to preparing components for inclusion in the target system, the sequencer program 204 in block 560 prepares environment variables for the target computer system by reading the system descriptor records and generating an environment file corresponding to the components to be included in the target system. For example, reading the system descriptor record in fig. 3B, and corresponding to the processor hardware component in the system descriptor record, may prepare an environment variable like "set CPU (central processing unit) set to Pentium".

In block 570 of FIG. 5, the plurality of software installation and test steps extracted by the above-described "three-table join" are ordered in a predetermined order. This ordering is based on the respective sequence numbers and phase numbers used to provide the sequence of steps. The ranking itself is accomplished using any of a number of classification algorithms well known in the art.

At block 580, the sorting program 204 outputs a number of files. As previously described, these output files are preferably written onto the step disk 150 (see FIG. 1) in the embodiment of FIG. 1 as 6 separate files. These files are: (1) step file, (2) setenv. It is desirable that the step file is an ASCII text file. In a preferred embodiment, the step file also contains commands that may be cyclic. More specifically, the step file allows the command to be repeated or iterated a determined number of times, or for a determined length of time. Bat document sets some environmental variables for the target computer system. The step file contains steps to be executed at each manufacturing stage of the quick test (Qt), the extended test 1(Et), the extended test 2(Etlast), and the final test (Ft) of the target computer system, respectively. On the other hand, in the embodiment of FIG. 2, the output file is not written to the step disk of FIG. 1. Instead, the output files will reside on file server 202 or file server 190 where they can be used to direct the execution of software installation and testing steps on target computer system 160.

Returning again to fig. 1 and 2, arrow 130 indicates that modifications may be made to database 100. For example, if a new class of computer systems is present, one may modify the database 100 accordingly. More specifically, an identifier of a new category is specified in the system ID of the system category table 104, and a name is specified for the new category for the name attribute of the system category table 104. A list of software installation steps and test steps is added to the system step sequence list 106 that represent what steps need to be run on the new class of computer system and in what predetermined order. If the new computer system class shares some similarity with the existing class, it is possible to generate some entries for the new class by modifying the entries for the existing class in the system step sequence list 106. If it is necessary to generate any new steps for a new computer system class, these steps should be added to the step table 102. Similarly, if a new computer system class is accompanied by any new components, those components should be added to the components table 108. The component step table 114 should also be updated so that each component of the new class of computer system is associated with the steps corresponding to the software installation and testing of that system. If the new category uses only existing components in the database, this table does not need to be modified. The system component table 112 is also updated so that a list of the various components that may be included in the new category appears in the database. In particular, it may be necessary to associate the system ID of the new computer system with the component ID of each enabled component. Again, this may be accomplished by copying and modifying existing entries for a native computer system class.

It should be noted that there are certain significant advantages in building a database according to the preferred embodiment. In particular, the modular design of the database facilitates easy setup of software installation and testing steps for new computer system types. Furthermore, software installation and testing steps for a particular computer system class or a particular component may be individually modified without affecting other software installation and testing steps.

Figure 7 shows how modular modification of the software installation and test process according to the invention can be achieved by patching a system descriptor record and a sequence of steps. In block 600, a system descriptor record is generated. In block 610, the system descriptor record is modified with a fix-up to the system descriptor record. In the preferred embodiment, the patching is modular, such that patching can be performed for a particular target computer system, for a particular class of computer system, or for a particular component. For example, if a manufacturer wishes to replace one brand of hard drive with another brand of hard drive for a certain computer system class on a certain day, a patch may be made in block 610 that will modify all system descriptor records containing the hard drive to be replaced and complete the replacement. In block 620, a sequence of steps is determined as briefly described above. In block 630, the sequence of steps is modified with a fix-up to the sequence of steps. In the preferred embodiment, the patching is modular, such that patching can be performed for a particular target computer system, for a particular class of computer system, or for a particular component. For example, if a manufacturer wishes a certain test step on a certain component to be performed before another step on a certain day, a patch may be created that will modify all the sequence of steps that contain the step in order to be modified and change the order of execution accordingly in block 640.

Attention is now directed to performing the sequence of steps on target system 160. The software installation and testing steps are performed on the target computer system using a program that reads, interprets (interpret), and executes a sequence of steps corresponding to the target computer system 160. In the preferred embodiment, this program is called Runstep, which is located on step disk 150 in the embodiment of fig. 1 and on file server 202 in the embodiment of fig. 2.

FIG. 8 shows a portion of a sequence of steps contained in a step file before any software installation and testing steps are performed. As previously mentioned, the sequence of steps contains a number of commands for installing software and/or testing on the custom target computer system. Furthermore, the sequence of steps in the step file allows for commanding the repeated execution of a determined number of iterations or a determined length of time. Also, the step file may contain notes that the Runstep program will override. In this step file, a token 800 is used to separate the fields of the sequence of steps. Item 810 is some command for testing target computer system 160. These commands include, for example, a command to test memory (memtest) (810a) and a command to test Small Computer System Interface (SCSI) devices (scsitest) (810 b). As can be seen, each command may contain a switch, e.g., -0 ", that is appropriate for the particular test environment. Item 820 is a comment not justified by the Runstep program. Item 810c is a command that cycles through time. In the preferred structure, the "begin-time-loop" instruction indicates the start of a loop. The end-time-loop instruction indicates the end of a loop. The "begin-time-loop" instruction incorporates a field that indicates the length of time for loop iteration. For example, command 810c here would run for 1 hour and 30 minutes. Item 810d is a cycle command (SCSI drive test) based on the number of iterations. In the preferred embodiment, the "begin-iteration-loop" command tells the Runstep program that a loop will be executed. The end-iteration-loop command indicates the end of the loop command. Here, command 810d will run three times.

When the Runstep program executes a sequence of steps, it will set time stamp information into the step file, which will facilitate easy error finding and tracking of the software installation and testing process.

Fig. 9 shows a portion of the sequence of steps of fig. 8 after the steps have been performed. As shown, the Runstep program inserts some time stamp information into the sequence of steps. Item 830 shows when the memory test begins and item 832 shows when the test ends. Item 834 shows when the last iteration of the test begins. Items 836 and 838 show when the SCSI HD (SCSI hard drive) test begins and ends, respectively. Item 840 confirms that the repeat cycle has been performed three times. Finally, items 842 and 844 show when the last iteration of the SCSI CD (SCSI drive) test started and ended, respectively. Inserting time stamp information in the vicinity of executed commands facilitates efficient error finding and tracking of software installation and testing processes.

Figure 10 shows a preferred overall flow chart of the Runstep program. The runtest program 860 operates in a loop with a runtest (run step) batch file 870. The Runstep program 860 reads and interprets a step from a sequence of steps and writes a command from the sequence of steps to be run to the batch file 870. The lot file 870 is then run, performing this step on the target computer system 160. After completion of a step, control is returned from the batch file to the Runstep program 860, which then reads and interprets the next line of the sequence of steps.

Figure 11 shows a more detailed flow chart of the Runstep program. The Runstep program first checks if there is a file named Re-run. Bat files are generated before any command is executed according to the sequence of steps and are deleted after the command is successfully completed. Bat presence indicates to the Runstep program at block 900 that the run of the previous command has not been successfully completed. Bat serves as a performance start indicator. Bat, if Re-run does exist, the operator will be asked in block 904 whether the software installation and test process is to continue or whether a mistake is to be made. If the operator chooses to continue processing, control transfers to the execute module 928 to re-execute the runstep. (if no positive selection is made, this is the default selection). If error finding is selected, it is performed as is well known in the art.

Bat. if Re-run is not present, the Runstep program can confirm that the previous command was completed correctly, so control proceeds to block 910 where a row of the sequence of steps, preferably contained in the step file, is read. After reading a row, the Runstep program determines in block 912 whether a start or end time stamp exists. If there is a start or end timestamp, the Runstep program determines in block 914 whether the line just read has only a start timestamp. If there is only a start time stamp, the Runstep program assumes in block 916 that a software installation or test step has just ended and populates in block 918 an end time stamp. After the end time stamp is filled, control returns to block 900.

If there is not only one start timestamp in the line read by the runtest program, the runtest program determines in block 906 whether there are both start and end timestamps. If so, the Runstep routine will assume in block 908 that the step has been performed, and control returns to block 900. If the Runstep program encounters a condition of neither a start nor end time stamp at block 912, the Runstep program populates the start time stamp in block 920 and prepares to run the steps on the line of the sequence of steps it just read.

In block 922, the Runstep program determines whether the command to be run is stored on the local drive (step file controls which drive in the system is the local drive). The local drive may be, for example, a step disk, a hard drive of the target system, a RAM (random access memory) drive of the target system, or a network drive. If the command is not located on the local drive, the Runstep program will assume that the test to be run is contained on a file server somewhere on the network. The Runstep program determines whether it is itself connected to the network in block 932. If not, the Runstep program will implant a login command to the network in Runstep. Bat is therefore networked prior to performing this step on target computer system 160 via network connection 180.

Following the block 936, control passes to a block 926. If the Runstep program has logged onto the network, the Runstep program will delete the command to log onto the network from Runstep. Control then passes to block 926. If the ready-to-run step is exactly on step disk 150, the Runstep program does not need to log on to the network. The Runstep program deletes the command to log on to the network from Runstep. Control then passes to block 926. In block 926, the Runstep program implants the appropriate commands to run into Runstep. The commands thus implanted are taken from a sequence of steps preferably contained in a step file. In block 928, the step is performed by running runstep. Bat is not deleted if the step is not performed successfully, and control transfers to fail state 929. Control then returns to block 900 to enable another row to be read from the sequence of steps. This process continues until all software installation and testing steps are completed.

After the sequence of steps is performed, the target system is tested and the software is installed. In the embodiment of FIG. 1, some selected number of tests may run directly from the step disk 150, but most tests are also run from the file server 190 over the network connection 180. Running the test in accordance with the file server 190 advantageously eliminates the limitations imposed by the storage capacity of floppy disks such as the disk 150.

In the embodiment of fig. 2, the steps are performed in accordance with a file server 190 over a network connection 180. Only one floppy disk, here support disk 220, is required to support target computer system 160. Such a system advantageously simplifies the software installation and testing process.

Returning again to fig. 1 and 2, arrow 210 indicates that the results of the software installation and testing may be logged back onto file server 190 or file server 202. The results preferably include whether all steps completed successfully, and what type of failure, if any, was encountered. The login result may simply be a modified form of saving or writing the step file after the execution of the sequence of steps, since the step file is time-stamped by the Runstep program, as described above. Such a system advantageously allows for improved error detection capabilities during the manufacturing of the computer system.

While particular embodiments of the present invention have been shown and described, it will be obvious to those skilled in the art that changes and modifications may be made without departing from the invention in its broader aspects and, therefore, the appended claims are to encompass within their scope all such changes and modifications as fall within the true spirit and scope of this invention.

Claims (16)

1. An apparatus for installing and/or testing software on a target computer system, comprising:

means for receiving a component list for the target computer system;

a database comprising a step table containing a set of software installation and/or test steps for different components of a possible computer system, the step table containing command attributes corresponding to executable command lines for performing the software installation and/or test steps, and a component table containing a set of possible components contained in the possible computer system;

a step maker computer system for generating a sequence of steps for installing and/or testing a component of the target computer system from a step table and a component table of the database and a component table of the target computer system, each component having an associated executable step; and

a non-volatile storage medium and/or file server adapted to store an executable file that can execute the sequence of steps on the target computer system.

2. The apparatus of claim 1, wherein said step table contains a step identification attribute that is a unique identification for each software installation step or test step.

3. Apparatus according to claim 1 or 2, wherein said step table contains a stage attribute indicating at which stage of manufacture a step should be performed.

4. The apparatus of claim 1 or 2, wherein the step table contains a command attribute corresponding to an executable command line for performing the software installation step.

5. The apparatus of claim 1 or 2, wherein the step table contains a postcode attribute identifying whether to be halted or restarted after the respective step is performed.

6. Apparatus according to claim 1 or 2, wherein said step table contains a maximum instance attribute indicating a maximum number of times a corresponding step can be run.

7. Apparatus according to claim 1 or 2, wherein said step table contains class identification attributes identifying components associated with a software installation or test step.

8. The apparatus of claim 1 or 2, wherein the parts table contains a parts identification attribute identifying each part in the parts table.

9. A device according to claim 1 or 2, wherein said component table contains a class identification attribute identifying a class of a component.

10. The apparatus of claim 1 or 2, wherein the target computer system manufactured corresponds to a class of computer systems; and the database further comprises:

a category relationship table indicating a relationship between a set of software installation steps and a category of each computer system being manufactured;

a category component relationship table indicating relationships between categories of the computer system and the component groups; and the number of the first and second groups,

a category step relationship table that indicates a relationship between the component and a set of software installation steps applicable to the corresponding component.

11. The apparatus of claim 10, wherein said class relationship table contains a class identification attribute that indicates a particular class of computer system.

12. The apparatus of claim 10, wherein said class relationship table contains a step identification attribute that indicates a particular set of steps that are appropriate for a particular class.

13. The apparatus of claim 10, wherein said category relationship table contains a sequence number corresponding to each category, the sequence number representing a predetermined order in which steps associated with the category are to be performed.

14. The apparatus of claim 10, wherein the category component relationship table specifies a relationship between attributes specifying a category of the computer and attributes specifying the component.

15. The apparatus of claim 10, wherein the category component relationship table specifies a relationship between a component identification attribute and a step identification attribute.

16. The apparatus according to claim 1 or 2, said database further comprising:

a category table that identifies categories of computer systems by name.