KR20010002572A - A method of installing software on and/or testing a computer system - Google Patents

Abstract

PURPOSE: An installation/test method of a software in a computer system is provided to increase a reliability of the computer system, and to increase an adaptability of the diagnosis test to various computer system, and to install a program for the diagnosis test quickly by using constituent component descriptive language for describing each constituent component of the computer system. CONSTITUTION: When ordering an order/manufacture target computer system(160) including wanted constituent components, a step maker(140) decides efficient installation method and test steps about software of the constituent components different from each other. The step maker(140) includes a sequencing program(204) in order to the efficient installation and test steps of software. The sequencing program reads plural constituent component descriptive languages from a descriptive file(96). The constituent component descriptive language describes the wanted constituent components of the computer system, and is readable by means of a computer. After reading the constituent component descriptive languages, the sequencing program(204) retrieves plural software installations/test steps pertinent to the constituent component descriptive languages from a database(100). Next, the sequencing program(204) sequences steps according to the sequence number pertinent to each step. After this, the sequencing program(204) records output files at a step file(150). At this time, the output file includes text files including instructions suitable for the retrieved plural software installations/test steps. The test is performed by using the step disk(150), or by using a file server(190) connected to the target computer system(160).

Description

A method of installing software on and / or testing a computer system}

The present invention relates to a method of installing and / or testing software on a computer system.

This application is directed to Richard D .. Amberg, Roger W. Wooong and Michael A. It is related to the co-pending Korean patent application No. 1998-28796, entitled "Software Installation and Testing for Custom Computer Systems," filed July 16, 1998, by inventor Brodridge.

This application is directed to Richard D .. Amberg, Roger W. Wooong and Michael A. It is associated with a co-pending Korean patent application No. 1998-28797 filed July 16, 1998, filed by Brundridge as inventors of "Software Installation and Testing for Custom Computer Systems."

This application is directed to Richard D .. Amberg, Roger W. Wooong and Michael A. Related to co-pending Korean patent application No. 1998-28798, entitled "Database for Facilitating Software Installation and Testing for Custom Computer Systems," filed July 16, 1998, as inventor by Brundridge .

These pending applications are hereby incorporated by reference in their entirety and the applications are assigned to the applicant of the present application.

General personal computer systems, and in particular IBM compatible personal computer systems, have become widely used to provide computing power in various fields of society. A personal computer system usually includes a system processor and associated volatile and nonvolatile memory, a display monitor, a keyboard, one or more diskette drives, fixed disk storage, and optionally a desktop, floor mount, or optionally a system unit with a printer. It can be defined as a portable microcomputer.

It is already known to install software and test it before a computer system is shipped to a business or individual customer. The purpose of software installation and testing is to efficiently produce a reliable and useful computer system that can be delivered to businesses or individuals to be operated without error. In general, tests detect and analyze errors that occur in the hardware and software portions of computer systems. Some lists of computer system hardware tests include diagnosing hardware components such as processors, memory, disk storage, audio devices, graphics devices, keyboards, mice, and printers. Software installation sometimes involves loading a package of desired software onto a computer system, preparing appropriate environment variables for the computer, and preparing an appropriate initialization file for the loaded software. Software testing often involves ensuring that the desired software version is installed on a computer system and that a suitable drive is present on the computer system.

It is known in the industry to install software and test computer systems by performing a fixed procedure before the computer system is shipped to a customer during manufacturing. For example, a diskette is created that accommodates certain diagnostic test methods for certain types of computer systems. The diskette contains a long and sometimes complex batch file that directs the software installation and diagnostics process. The diskette contains all of the executable files for testing the computer system being purchased again.

Each computer system being manufactured is provided with a copy of this diskette. These diskettes accompany computer systems that are fabricated around the factory floor during the manufacturing process and are tested for each computer system in an order specific to the batch file. If you need to make modifications to the process, modify the batch file by adding or removing some from the batch code in response. Modifying the batch file in this way also changes the test parameters (including the order in which the tests are performed) of each subsequent computer system being manufactured, because each computer system shares the same batch file diagnostic procedures. .

This kind of diagnostic measures has shown some usefulness in increasing the reliability of computer systems before shipping, but there is still room for improvement. For example, as tests continue to be complex and thorough, batch and executable files of diagnostic tests often exceed the storage capacity of the diskette. In addition, it is difficult or impossible to customize the test and software installation procedures for a single custom computer system or a specific computer system family without modifying the tests for other computer systems or computer system families. Moreover, it is difficult or impossible to modify the order of software installation and testing of a single custom made computer system or a particular computer system family without modifying the order for another computer system or computer system family. Finally, the batch file structure at that time is sometimes complex, making it difficult for the manufacturer to track down problems or maintain test and software installation procedures quickly and efficiently.

What is required, therefore, is to provide a method of installing and / or testing software for a computer system that can provide improvements to the prior art.

1 is a schematic diagram illustrating software installation and testing,

2 is a schematic diagram showing software installation and testing according to another embodiment;

3A is a flow diagram of converting a computer order into a system descriptor record in accordance with the present invention;

3B shows a portion of an example computer order, basic assembly record (BAR) file, and system descriptor record,

4 is a flowchart for creating and providing a step sequence;

5A is a schematic illustration of the relationship between FIGS. 5B and 5C;

5B is the first part of a more detailed flow chart for creating the step sequence;

5C is the second part of a more detailed flow chart for creating the step sequence;

6 shows the structure of a database,

7 is an example of a part of a step file,

8 to 13 are flowcharts of the operation of the program for executing the step sequence.

According to one feature of the invention,

Reading a plurality of component descriptors describing each component of the computer system from the computer readable file,

Reading a plurality of steps corresponding to the component descriptors from the database and including respective sequence numbers,

Sequencing the plurality of steps in a predetermined order according to the sequence number to provide a step sequence including instructions for installing and / or testing software on the computer system,

For each step read from the database, further comprising the step of judging from data related to the step from the database, the step being compatible with the presence in the computer system of another component that does not correspond to the component descriptor associated with the step. Otherwise, there is provided a method of installing and / or testing software for a computer system, characterized in that it does not give up the step in accordance with additional data related to the step of the database.

According to another feature of the invention,

Reading a plurality of component descriptors describing each component of the computer system from the computer readable file,

Reading a plurality of steps corresponding to the component descriptors from the database and including respective sequence numbers,

Sequencing the plurality of steps in a predetermined order according to the sequence number to provide a step sequence including instructions for installing and / or testing software on the computer system,

For each step read from the database, further comprising determining from data related to the step from the database, if the step requires a parameter, calculating the parameter according to additional data related to that step in the database. A method of installing and / or testing software for a computer system is provided.

Hereinafter, preferred embodiments of the present invention will be described with reference to the drawings. The following description is for illustrative purposes and should not be construed as limiting. In the drawings, same or similar elements will be represented by the same part number. In the description, a module is defined as an instruction or set of instructions.

1 is a schematic diagram of a software installation and test system 90 at a computer system manufacturing site. In operation, an order 92 is placed to purchase a customized target computer system 160. Target system 160 will be manufactured to include a plurality of hardware and software. For example, target system 160 may include a brand of hard drive, a particular type of monitor, a brand of processor, and a particular version of an operating system. Before the target system 160 is shipped to the customer, a plurality of components are installed and tested. Such software installation and testing advantageously ensures a reliable utility computer system that can be operated immediately upon receipt.

Because different families of computer systems and different individual computer components require different software installation and testing steps, some tests need to be performed on the target system 160 and the tests must be performed in any order to ensure effective software installation and You need to decide whether you want to achieve the test process. Step maker 140 is a computer system configured to cause software installation and test steps to be performed sequentially on target system 160. In order to perform the software installation and / or test steps sequentially, the step program 140, more specifically, the sequencing program 204 in the step maker 140, first starts from the descriptor file 96. Read the component descriptors. The descriptor file 96 is provided by converting the order 92 corresponding to the desired computer system with the desired components into a computer readable form via the conversion module 94.

Component descriptors are computer readable descriptions of the components of the target system 160 whose components are defined by the order 92. In a preferred embodiment, the component descriptor is a descriptor called a system descriptor record, which is a computer readable file containing a list of components, that is hardware and / or software components, to be installed on the target system 160. It is included in the file. After reading the plurality of component descriptors, the sequencing program 204 retrieves a plurality of software installation and / or test steps corresponding to the component descriptors from the database 100 via the network connection 110. Network connection 110 may be any network connection well known in the art, such as logical area networks, intranets or the Internet. Information included in the database 100 may be updated through the modification indicated by the arrow 130.

After searching for software installation and / or test steps suitable for the target system 160, the sequencing program 204 sequences the steps in a predetermined order according to the sequence number corresponding to each step. After sequencing the steps required for the target system 160, the sequencing program 204 writes a series of output files to the step disk 150. In the embodiment shown in FIG. 1, the output file includes text files containing command lines suitable for performing appropriate software installation and / or test steps for the target system 160. Execution is performed in a predetermined order according to the sequence number corresponding to each step. The step disk 150 accompanies the target system 160 at the factory workshop, where testing is done directly from the step disk 150 or the file server 190 connected to the target system 160 via a network connection 180. Is done from. Preferably network connection 180 is a generic network device that fits within a corresponding network port of a target computer system. After performing the software installation and testing steps, the results of the installation and testing are stolen to the file server 190 via the network connection 180.

2 is a schematic diagram of a software installation and test system 192 according to another embodiment of the present invention. The customer places an order 92 to purchase a target computer system of order structure. Target system 160 is manufactured to include a plurality of components, which may include hardware and / or software components. Before the target system 160 is shipped to the customer, a plurality of components are installed and tested. Such installation and testing advantageously ensures a reliable and practical computer system that is ready for operation as received by the customer.

To sequence the software installation and test steps, the sequencing program 204 reads a plurality of component descriptors from the descriptor file 96. Order 92 is converted to descriptor file 96 via conversion module 94. Component descriptors are computer readable descriptors of the components of target system 160. In a preferred embodiment, the component descriptors are contained in a descriptor file called a system descriptor record, and the computer readable file includes a list of each component of hardware and software to be installed in the target system 160. System descriptor records may be stored directly in the file server 202. The sequencing program 204 retrieves a plurality of software installation and / or test steps corresponding to the component descriptors from the database 100. After retrieving the appropriate software installation and / or test steps for the target system 160, the sequencing program 204 installs and tests the software on the target system 160 in a predetermined order via the network connections 195 and 180. Instructs you to run Preferably, network connection 200 is a generic network device inserted into a corresponding port of target system 160. The network 195 may be any communication connection well known in the art. After executing the software installation and / or test steps, the results of the installation and testing are recorded over the network connection 200 to the file server 202 or stored in a suitable database. As is apparent from the example, the separate step maker computer system of FIG. 1 is not needed. In addition, step disc 150 is also not required. Only the boot disk 220 configured to boot the target system 160 needs to accompany the target system 160 on the factory floor.

Having described the software installation and test steps in general, the operation of the system shown in FIGS. 1 and 2 will now be described in more detail.

3A illustrates a preferred process for converting an order for a computer system into a computer readable system descriptor record. More specifically, item 300 receives an order for a target computer system. This order may be in one of a variety of forms. For example, different order forms are possible, as are different order delivery mechanisms. For example, orders for the target system may be made via telephone, mail, or computer network (eg, via the Internet). Regardless of the means or form of ordering, an order includes a list of types of target computer systems that the customer wants to purchase and perhaps specific components that the customer wants to include in the target computer system. After the order is received, control is passed to a transfer module 310 where the target computer system order is transferred via a computer network to a manufacturing system (not shown) that manufactures the target computer system. The target computer system order is also provided to the software installation and test system where the order is transferred to the conversion program at module 320. The computer network used in module 310 may be of any type well known in the art.

The conversion program converts the target computer system orders into records useful for the manufacturing process. More specifically, the conversion program first converts the computer order into a record called a bar file in module 330. Preferably, the BAR file contains a unique identifier that identifies the particular target computer system being manufactured. The BAR file also contains a detailed list of components, including the hardware and software to be included in the target system. On top of that, the BAR file preferably contains a manufacturer specific part number or other useful identifier for each component. Finally, the BAR file may contain customer specific information such as name, address and phone number.

After creating a BAR file in module 330, a system descriptor record is created in module 340. In this preferred embodiment, the system descriptor record is a computer readable file describing the hardware and software components to be included in the target computer system. In a preferred embodiment, the system descriptor record includes a list of components of the target system in a format that includes hardware tags, software tags, information tags, and comments. The hardware tag confirms to the sequencing program 204 that the information following the tag is about the hardware component. Similarly, a software tag confirms that the information in that tag relates to a software component. The information tag indicates that general information follows. The annotations allow various descriptions that are overlooked by the sequencing program 204 to be included in the system descriptor record. The system descriptor record is preferably a text file that is human readable and easy to understand. Such files advantageously allow for easy problem tracking and repair of the installation and testing process. The system descriptor record may be a list of any unique identifiers corresponding to the unique combination of tokens. For example, the system descriptor record may be a list of part numbers.

3B shows an example target computer system order 350, a corresponding BAR file 360, and a corresponding system descriptor record 370. Target computer system order 350 has the name of the computer family, in this example family "X". Target computer system order 350 also includes three typical components including a Pentium processor, hard drive, and monitor. The BAR file 360 is obtained by executing the target computer system order 350 through a conversion program such as that shown in module 320 of FIG. 3A. BAR file 360 includes a unique identifier for a particular target computer system in family X. The BAR file 360 also includes a manufacturer specific part number for each of the components listed in the target computer system order. The BAR file 360 then includes an identifier indicating a desired amount of each component and a textual description of each component to be included in the target computer system. System 90 uses BAR file 360 to create system descriptor record 370.

As illustrated, system descriptor record 370 also includes a unique identifier for a particular computer system in family X. On top of that, the system descriptor record 370 includes a suitable tag, here a tag indicating that the processor, hard disk, and monitor are all hardware components, not software. System descriptor record 370 describes these components in a textual description. In addition, the typical system descriptor record 370 includes a software tag that indicates which software should be installed or tested on a target computer system belonging to family X. For example, a software tag would indicate that an operating system suitable for the Pentium processor is always installed on the hard drive of a target computer system belonging to family X.

4 shows a preferred general method for sequencing software installation and test steps. In module 400, a unique identifier of the target computer system is generated for the target computer system 160. In the embodiment shown in FIG. 1, a user sitting in step maker computer system 140 provides a unique identifier (eg, a BAR identifier serving as a tracking code) to the sequencing program of step maker 140. Alternatively, in the embodiment of FIG. 2, after the target computer system order is received, a unique identifier is read into the sequencing program.

In module 410, a system descriptor record corresponding to the BAR identifier is located. In the embodiment of FIG. 1, network connection 110 or network connection 195 locates the system descriptor record. In module 420, the found system descriptor record is provided to the sequencing program 204. In the embodiment of FIG. 1, the sequencing program resides in the step maker computer system 140, while in the embodiment of FIG. 2, the sequencing program resides in the file server 202. Sequencing program 204 cooperates with database 100 (of FIGS. 1 and 2) to sequence software installation and test steps for target computer system 160.

Once the software installation and test steps appropriate for the particular target computer system are sequenced, the sequencing program 204 generates an output file as shown in module 430.

In the embodiment shown in Fig. 1, the output file (see Fig. 1) written to the step disc is a step file and a Setenv.bat file. The step file is an ASCII text file containing a list of suitable command lines for performing software installation and test steps for the target computer system being ordered. In a preferred embodiment, the step file also includes instructions that can be cycled. More specifically, the step file allows the command to be repeated a certain number of times or for a certain length of time. Such a format advantageously allows the software installation and test steps to be repeated in a calculated manner. The Setenv.bat file sets environment variables for the target computer system. The step file and the Setenv.bat file are ASCII text script files containing a list of appropriate command lines for performing installation and test steps for the target computer system. The step file includes steps for each period of manufacture, such as the rapid test (Qt), extended test 1 (ET1), extended test 2 (ET2), software installation (SI) and final test ( Ft) is subdivided into a number of individual subfiles with steps.

On the other hand, in the embodiment of Fig. 2, the output file is not written to the step disc as shown in Fig. 1. Instead, the output file resides in file server 202 or file server 190, and these files are used to instruct the target computer system 160 to perform software installation and / or test steps.

5A-5C are more detailed flow diagrams of the operation of the sequencing program 204 shown in FIGS. 1 and 2.

Decision module 500 determines the source of the order. First, think only about the left part. If desired, module 502 applies one or more patches to the system descriptor record. In a preferred embodiment, the patch is modular and patches can be made for specific target computer systems, specific computer system families or specific components. For example, if a manufacturer wants to replace the brand of one hard drive with another brand for a certain computer system family on a certain date, modify all system descriptor records containing the hard drive to be replaced and apply the module to the replacement of the module 502. Can be formed.

Module 504 then inputs (patched) system descriptor records corresponding to target computer system 160 to sequencing program 204. In module 506, component descriptors are read from the system descriptor record. Each component descriptor describes each component of the hardware or software of the target computer system.

Returning to FIG. 3B, the row of system descriptor record that includes the Pentium processor in module 370 is an example component descriptor. In module 508, sequencing program 204 illustrates a plurality of derived objects, each corresponding to a plurality of target computer system components. In a preferred embodiment, these derivatives are used to store information (obtained from database 100) regarding software installation and test steps that need to be executed on the target computer system 160. Thus, in module 510, each guide object is associated with each component of target computer system 160.

Reference is now made to the right part of module 500. In this case, the order is stored directly in the database as a record by the customer in the form of a Bill of Material, which record contains the component descriptors for the target computer system 160. Module 512, which corresponds to module 502, applies a deviation (patch) to the material list, while module 514 reads the material list from the database it is storing for use by sequencing program 204.

In module 516, software and test steps associated with each component of target computer system 160 are retrieved from database 100 and stored in a suitable guided object. In the embodiment of FIG. 1, the steps are retrieved from the network connection 110, while in the embodiment of FIG. 2, the steps are retrieved directly from the file server 202. To explain how steps are retrieved from database 100 in a preferred embodiment, a description of the preferred structure of that database is required.

6 shows a design of the database 100. The database 100 associates the order of software and / or test steps with the computer system families in a given order. The database 100 is also configured to relate components of the computer system. Furthermore, database 100 associates software and / or test steps with components of a computer system.

Database 100 is preferably a relational database. The database 100 includes several tables, each containing attributes suitable for forming the aforementioned associations.

The database 100 includes a step table 102, a family table 104, a family step order table 106, a component table 108, a family component table 112, a component step table 114, and step dependence. A table 116, a step parameter table 118, a component class table 120, a component class attribute table 122, and an operator message table 124. In the preferred embodiment, each table contains a list of attributes, with the primary attributes serving as primary keys.

Step table 102 includes all software installation and testing steps for all possible components of all computer families. In a preferred structure, step table 102 has attributes including StepID, Name, Command, CommandType, AfterActionType, MaxInstance, ClassID, and DepMask (dependency table). StepID is a unique identification number for each software installation or test step. Name is a string that specifies a name that describes the step. Command is a string that specifies an executable command line for performing a software installation or test step on the target system 160 (shown in FIGS. 1 and 2). AterActionType is an identifier that determines whether a stop or reboot is required after a software installation or test step is executed. MaxInstance is an identifier that indicates the maximum allowable number of times a step can be executed. The ClassID identifies any type or class of components (eg, hard drive, CD ROM drive, etc.) that are involved in the software installation or test step. Finally, DepMask records information about whether a particular step has step dependency and / or step parameters and determines whether step dependency table 116 and / or step parameter table 118 should be entered.

The family table 104 identifies each family of the computer system by the identification integer specified in the attribute FamilyID. The family table also contains a string that identifies the name of the family. The family step order table 106 is a relationship table that includes the relationship between the step table 102 and the family table 104. The family step order table 106 is a family identification integer defined in an attribute family ID for a particular family (from the family table 104) of the computer system, and an attribute step ID (step table) identifying a particular group of steps suitable for that family. Step identification integer and sequence number as defined in (from 102). The sequence number is contained within an attribute step sequence number that indicates the predetermined sequence in which steps associated with a particular family are to be performed. The test engineer assigns a unique sequence number within each manufacturing step in the order most effectively chosen for the specific target system. It will be appreciated that other methods of specifying sequence numbers may also be used. Finally, the family step order table 106 includes a step ID. The step ID designates in which manufacturing step the step is to be executed. For example, the step ID is an integer selected to correspond to one of the five computer system manufacturing steps described above: rapid test (Qt), extended test 1 (Et1), extended test 2 (Et2), software installation (SI) and final test. to be.

The component table 108 includes all possible components included in the computer system being manufactured. The attributes in this table are the component IDs that assign identifiers to each component, the descriptors that assign string names to each component, and the class IDs that refer to the type of component (eg, hard drive, CD-ROM drive).

Family component table 112 is a relationship table that includes a relationship between each family of computer systems and a collection of components that may be included in that family. Attributes in the family component table 112 include the computer family identification integers specified in the attribute family ID (from family table 104) and the component identifications specified in the attribute component ID (from component table 108). Integer is included.

The component step table 114 is a relationship table that includes the relationship between each component and the group of software installation and test steps appropriate for that component. The attributes of the component step table 114 include the component identification integers specified in the attribute component ID (from the component table 108) and the step identification integers specified in the attribute step ID (from the step table 102). It includes.

The step dependency table 116 includes data regarding possible conflicts. Some tests may conflict with certain classes of components, certain components themselves, or components from any manufacturer. For example, the target computer system 160 to be assembled would include a brand A hard drive and a brand B CD ROM. A brand A hard drive would normally require test C to be done, but all such dependencies are recorded in step dependency table 116, such as test C may be incompatible with CD ROM drive B. In this table, the step ID identifies a step with a dependency, the type ID indicates whether the dependency is related to the class of a component or to a specific component, and the object ID is rated according to the state of the type ID. ID or component ID, and the DepType ID indicates whether a particular step should be maintained or removed when a conflict occurs.

The step parameter table 118 identifies the parameters that a step will need, for example, some steps may need to run for a certain length of time or for a certain number of repetitions. In table 118, the step ID uniquely identifies a particular installation or test step. The parameter ID identifies each parameter associated with that step. There may be more than one parameter associated with a particular step and each variable will have its own parameter ID. For example, different brands of hard drives may be tested with the same test and with different parameters. The data type identifies the type of data to be included in each parameter. In the above example, the data type specifies whether the data will be displayed in percentage or according to the hard drive ID code. The contents are command line switches like those used in the C programming language related to commands like "printf". For example, the content may be "-% d" to indicate that a percentage is appropriate for this parameter. The step sequence number and class ID have already been described above.

The step parameter table 118 only remembers the type and number of parameters associated with a particular step but does not actually remember the values of those parameters. Thus, during the formation of the step file, which will be described later, the table 118 does not insert parameter values into the command line of the step file. In contrast, this table contains all the specifications necessary to make a command line formable. It is the sequencing program 204 that calculates the value of the parameter and inserts it into the step file command line during execution. Sequencing programs perform calculations based on the information contained in the descriptor record.

An advantage with the step parameter table 118 is that it allows greater flexibility by eliminating the need to have parameters permanently associated with the steps. Thus, table 118 allows an article to easily modify parameters without having to edit step table 102.

The component class table 120 is a simple list of all class components (class IDs) such as hard drives, CD ROMs, etc., and a brief description of their class (class name, description).

Component class attribute table 122 lists all classes and all attributes associated with each class. The attribute ID is the code assigned to each of the different attribute types such as memory size, operating speed, manufacturer, etc., while the attribute name is the name of a more descriptive attribute for the convenience of the article. A data type is an indication of the data type used to represent a particular attribute. For example, if the attribute is a manufacturer's name it may be a string or it may be an integer if the attribute is a memory size.

The component rating table 120 and the component rating attribute table 122 are not actively used by the sequencing program 204 and are primarily used by development engineers. These tables do not contain any actual values of the attributes.

Finally, operator message table 124 stores a number of messages for the test operator depending on the test being performed and the components being tested. For example, a prompt may be issued to remind the operator to insert a tape before testing the tape drive.

The example target computer system shown in FIG. 3B will be used to illustrate how the database design described above is used to retrieve software installation and test steps. The computer family record in the system descriptor record identifying family X is associated with a family ID corresponding to family X in family table 104. The component table 108 is used to check that the components of the target computer system listed in the target computer system order are legitimate. In other words, the sequencing program and database determine whether the processor, hard drive, monitor, and software included in the system descriptor record of FIG. 3B have the corresponding item and corresponding number specified by the component ID in component table 108. Determine. If the component is not legal (ie, the component in the system descriptor record is not included in the component table 108), an error flag is raised. Family component table 112 is a relational table that includes component table 108 and mappings from family table 104. The family component table 112 includes all legal components that can be included in a target computer system belonging to family X. Thus, the family component table 112 can be used to check that all components of the target system are legitimate. In other words, the sequencing program and database determine whether the processors, hard drives, monitors, and software included in the system descriptor record of FIG. 3B have a correspondence in the family component table 112. If the component is not legal (ie cannot be included in the target system belonging to family X in the system descriptor record), an error flag is raised.

In the relational family step order table 106, there is a mapping from the step table 102 and the family table 104 (resident). Family step order table 106 includes all software installation and test steps that can be legally executed for a target computer system belonging to family X. Moreover, it is within this family step sequence table 106 that sequence and step numbers are associated with each software installation and test step. Their order and step number indicate the proper order in which the steps will be executed for a particular family of computer systems. Thus, the family step order table 106 includes a list of steps to be executed in the family X target computer system and an order and step number indicating a predetermined order in which the steps are to be executed.

Component step table 114 is a relationship table that includes mappings from component table 108 and step table 102. Component step table 114 includes software installation and test steps to be executed for the processor, hard drive, monitor, and software of the target computer system.

Searching for software installation and testing steps associated with each component to be included in the target system may include the family component table 112 and component steps to obtain an intermediate set list step to be executed for the components of the target computer system 160. Performing a join command for the table 114 is included.

With the join command, a list of steps to be executed for the processor, hard drive, monitor, and software contained in the system descriptor record shown in FIG. 3B is obtained. The result of the combination of the family component table 112 and the component step table 114 is then combined with the family step order table 106 which includes all the steps for family X. The result of this joint instruction includes sequencing information in the form of sequence number and step number, the sequence number being unique for a particular step. Thus, combining the three tables of the family component table 112, the component step table 114, and the family step sequence table 106, installs and / or installs the software on the appropriate software installation and test steps and the target computer system 160. Or sequencing information in the form of a sequence and step number for testing.

If the result of the first join instruction (combination of family component table 112 and component step table 114) is an empty set, an error condition is raised, because the empty set indicates that the component to be included in the target system is a system descriptor. This implies that it does not belong to the family listed in the record. An example of this is illustrated. Assume that the system descriptor record correctly indicates that the target computer system belongs to family Y. However, suppose that the system descriptor record incorrectly indicates that a hard drive (hard drive Z) belonging only to the target system in family X should be included in the target system in family Y. In that case, component step table 114 includes the steps associated with hard drive Z. FIG. Family component table 112 includes components associated with family Y. So combining component step table 114 with family component table 112 creates an empty set, because hard drive Z is not a component associated with family Y (instead it is just a family Associated with X). As is evident from the above example, the preferred design of the database advantageously allows people to be sure that a target system of a family contains only components suitable for that family.

5A and 5C again, after the steps associated with the components to be included in the target system have been retrieved, the module 518 of the sequencing program 204 determines whether there are step dependencies for each step by examining the DepMask for that step. do. If so, module 520 reads the dependencies from step dependency table 116 and module 522 resolves the dependencies according to the DepType ID.

Next, module 524 again determines if the step requires parameters by examining the DepMask for that step. In such a case, module 526 reads the parameters from step parameter table 118 and module 528 calculates the actual values of the parameters and inserts them into the command line of that step.

Module 530 now prepares environment variables for the target computer system by reading a system descriptor record and creating an environment file corresponding to the instructions to be included in the target system. For example, the system descriptor record shown in FIG. 3B may be read and an environment variable such as "set cpu = pentium" may be created corresponding to the processor hardware component of the system descriptor record.

In module 532, a plurality of retrieved software installation and test steps, with the added and retrieved dependencies retrieved and resolved by the three-table combination described above, are sequenced in a predetermined order. This sequencing follows each sequence number and step number to provide a step sequence. Sequencing itself is performed using one of many sorting algorithms well known in the art.

In module 534, the sequencing program 204 outputs the step file and Setenv.bat file mentioned above. The step file includes a number of subs, each of which includes steps to be executed each of the quick test (Qt), extended test 1 (ET1), extended test 2 (ET2), software installation (SI), and final test (Ft) of the manufacturing of the target computer system. Subdivided into files.

As indicated, in the case of the embodiment of FIG. 2, module 534 stores the output file in file server 202 as it is or in the database. The output file written to file server 202 may be used to direct the execution of software installation and test steps for target computer system 160.

In module 536, the step order is modified by using step order patches as needed. In a preferred embodiment, the patch is modular, so that the patch can be formed according to a particular target computer system, a particular family of computer systems, or a particular component. For example, if a manufacturer wants to run a test step for a component on a certain date before the other, then modify all step sequences including the steps whose order is to be modified and thus modify the order of execution in module 536. Can be formed. Following the patching, the module 538 outputs the modified file to the file server 202 for storage as it is or in the database.

Finally, module 540 gives the option of writing to diskette 150 in FIG. If a diskette is required, instead of writing directly to the diskette, module 542 forms a "virtual diskette" in memory and then module 544 writes the entire virtual diskette to the physical (physical) diskette in one operation, This reduces the number of operations to write to the floppy disk drive, thus facilitating the overall work of the program.

The virtual diskette is formed by the next program that forms memory corresponding to the physical diskette by allocating an array of memory blocks each corresponding to the size of the physical sector size on the physical diskette. The file system is FAT12 (used in PC-DOS, MS-DOS, Windows 95 and Windows NT operating systems). The first sector is the boot sector of the diskette. A cluster is a logical aggregation / unit of sector combination. This number is fixed once the file system is initialized. For example, one cluster size is two sectors. The file system only allows allocations by clusters, not sectors. In this case the minimum file will consume at least 1 cluster (or 2 sectors).

start

Form an array of memory blocks. The number of memory blocks is equal to the number of physical sectors on the diskette given a file system.

Initialize all memory block contents to zero.

The boot sector is initialized by copying only the external image of the boot sector. This external image is stored in a file.

Initialize the FAT table. (A sector well defined on the diskette by the file system).

If a file write operation is requested.

Read the file.

Allocate the required cluster.

If it is an error, there is not enough space to exist with the function with the error.

Update the directory and FAT table for the assigned cluster.

Write the read contents to the cluster.

If a file delete operation is requested.

Free the allocation cluster for a given file.

Update the directory and FAT tables for the released cluster.

If a physical diskette write operation is required.

From the diskette, the diskette usage count stored in the fourth byte of the boot sector is obtained.

If the coefficient is> = maximum coefficient, report an error code to indicate the reason for the error.

If the coefficient is <maximum coefficient, the coefficient is incremented by one.

Write the count value to the third byte of the boot sector on the virtual diskette.

Writes a block of memory from a virtual diskette to a physical diskette and stops when the memory block with data no longer remains.

End.

1 and 2 again, arrow 130 indicates that modifications can be made to database 100. For example, when a new family of computer systems is formed, the database 100 can be modified accordingly. More specifically, the new family is assigned a new family identifier in the family ID of the family table 104 and the name of the new family is assigned to the name attribute of the family table 104. A list of software installation and test steps is added to the family step order table 106, which indicates to the new computer system family which steps also need to be executed in what predetermined order. If a new family of computer systems shares some similarities with an existing family, the items for the existing family in the family step order table 106 are likely to be modified to create items for the new family. If any new steps need to be formed for a new family of computer systems, these steps are added to the step table 102. Similarly, if any new components are attached to a new family of computer systems, those components are added to the component table 108. The component step table 114 is updated to associate each component of the new family of computer systems with steps suitable for software installation and testing. If the new family uses only components that already exist in the database, this table does not need to be modified. The family component table 112 is updated so that the list of allowed components to be included in the new family is in the database. In particular, it will be necessary to associate the SysID of the new computer system with the Component ID (ComID) of each allowed component. Again, this can be done by copying and then modifying existing entries of the outdated family of computer systems.

It will be appreciated that some important advantages are gained when constructing a database according to a preferred embodiment. In particular, the modular design of the database advantageously allows easy setup of software installation and test steps for a new family of computer systems. In addition, software installation and testing steps for a particular family of computer systems or for particular components may be modified independently of other software installation and testing steps.

Care should be taken when executing the step sequence on the target system 160. The software installation and test steps are executed on the target computer system 160 using a program that reads, interprets, and executes the step sequence corresponding to the target computer system. In a preferred embodiment, this program is called RunStep and is located on the step disk 150 in the embodiment of FIG. 1 and on the file server 202 in the embodiment of FIG.

7 shows part of the step sequence included in the step file before any software installation and test steps are completed. As above, the step sequence includes instructions for and / or testing software installation of the custom rescue target computer system. In addition, the step order in the step file allows the command to be repeated by a certain number of repetitions or by a certain length of time. The step file will also contain comments ignored by the RunStep program. In the step file, the mark 800 is used to separate the fields of the step sequence. The instructions include, for example, instructions for testing a memory and testing a small computer system interface (SCSI) device. As can be seen from the figure, each command will include a switch such as '-o' that is suitable for the particular test environment. Item 820 is a comment ignored by the RunStep program. Item 810c is a command looped over time. In a preferred configuration, the 'start-time-loop' command indicates the start of the loop. The 'end-time-loop' command indicates the end of the loop The 'start-time-loop' command is combined with a field indicating the length of time to repeat through the loop, where command 810c is one hour 30 Item 810d is a command that loops according to the number of iterations In a preferred embodiment, the 'start-repeat-loop' command instructs RunStep to execute the iteration loop. The instruction signals the end of the loop instruction, where instruction 810d is executed three times.

8 to 13 show a flow chart for the RunStep program. In general, RunStep processes each step subfile one line at a time without reading the entire step subfile into memory. In each row, RunStep performs a lot of checks to evaluate whether it will continue processing that row. For example, if RunStep finds that an error condition has been registered after the previous line has been executed, it knows that there is no point in continuing the program. Alternatively, RunStep can check to see if the operator has negated the step subfile (e.g. to skip tedious tests), and if so, allow the operator to restart all without continuing the program. Thus, a specific line of the step subfile is read only when RunStep determines that the line is suitable to be executed immediately afterwards, so that a line is not unnecessarily read from the step subfile. Clearly this is a time-saving feature.

8 is a top level flow chart of RunStep. The first module 900 initializes the state of the system. This is done before any row of the step subfile is read. During this step, RunStep tells you the exact state of the system, for example, has an error been reported in the execution of the last row? Read several environment variables (from the "progress.bat" file to be described) to see if you need to rerun or whether RunStep may continue reading the next line.

9 shows the initialization step in detail. The first module 902 prevents control brakes, which prevents the operator from stepping out of the program. The variables are then initialized (904), and the program reads the environment variables from the environment (906). These environment variables are often stored in a batch file called progress.bat, which is stored in memory that you may have written to when RunStep previously executed a line in the step subfile. progress.bat contains the current system status and updates are made for each row read from the step subfile as described later (module 106, FIG. 13). progress.bat is the row number of the last step executed; An indication of which actual instruction was executed; How much time has passed if a particular instruction was executed within a time loop; It may include information such as which test or software installation steps are performed.

If the information variable is successfully read as determined by module 908, module 910 reads a directory listing of all files on the local drive into memory of computer 160 or 202 on which RunStep is executed. So when RunStep checks if the file is on the local drive (module 1002, Figure 13) it can do this check by reading a directory listing in memory and does not need to search the local drive itself. This saves time. If RunStep successfully reads the directory listing as determined by module 912, module 914 will determine the current progress. During this step, RunStep sets a flag several times depending on the system's situation, such as a failure or rerun. It is these flags that will determine the flow of RunStep through subsequent modules 916, 918, 920. These modules will guide RunStep into the subroutines A, B or C of FIG. 10 as needed.

In Fig. 10 (a), routine A is input when RunStep determines that the next step is a normal process step. The first module 922 of routine A verifies several check sums. This purpose is to ensure that there is no negation in the step subfile, for example RunStep reads any checksums and correlates them with the checksums stored in the progress.bat file. This will indicate that an unauthorized person has modified the step subfile. If all the check sums are correct as determined by module 924, the program resets (clears) some variables and reads the current time (module 926).

Routine B, FIG. 10 (b) is input if the environment indicates that the last step needs to be executed as determined by module 918. The purpose of routine (B) is to give an opportunity for a qualified operator to intervene in the program and not to rerun the last step if desired. The module 928 thus displays a message that the operator can select the manufacturing tools (MFGTools) within 5 seconds or else the rerun will proceed. The manufacturing tool is an approved method by which a qualified operator can modify as needed by intervening a step subfile with a suitable password. Module 930 determines, according to the operator's response, whether the last step will be re-executed, in which case module 932 causes the progress environment (progress.bat) to run MFGTools.

Routine C, FIG. 10 (c) simply causes the progress environment (progress.bat) to execute MFGTools, module 934.

In Fig. 9, module 936 determines if the fault has been repaired and module 938 checks to see if the current step is legitimate.

Returning to FIG. 8, once initialization module 900 is terminated and "success" reported as determined by module 950, RunStep proceeds to module 952, which is a "process step file". When RunStep reached this step, enough information was read from the environment so that it knows whether it would proceed to the next line in the step subfile, redo the previous line, or abort.

11 shows module 952, “Process Step File” in more detail. Module 954 determines whether a manufacturing tool has been selected or if a rerun is required. If either of these is true, no further setup is needed and the program in this section can report success. If none of these conditions is true (ie RunStep will now go to the next line of the step subfile), the appropriate time period step subfile is opened in module 956. This means that RunStep opens a step subfile associated with a particular step (ie, quick test, extended test, etc.) of the test or software installation being executed.

Module 958 checks if there is a rewind step. A rewind step is a special case of a rerun where one of the steps has a fault that the entire step of the test needs to be repeated, i.e., RunStep must return to the beginning of the step subfile for that step. After confirming that RunStep is a rewind step, module 960 sets the environment accordingly and reports success.

If it is not a rewind step, the module 962 reads the next line number from the step subfile and further compares the line number with that stored in progress.bat that RunStep reads in the initialization step to the line just read by the module. The number is checked to see if it is the row it was expecting to read, which is again a fraud prevention device. In particular, when RunStep is running, progress.bat will contain information about the last step executed, that is, the line number in the step subfile, the command ID of the executed command, and other checks and related information. . In module 962, RunStep will read the progress.bat file contained in the memory and skip over the specific number of lines in the step subfile determined by the line number in progress.bat. It then checks that the line number where it is actually located matches the line number it expected. It also checks to see if the command on this line is the same command we just heard of being executed, that is, RunStep verifies that the row it is currently on is the actual last step executed.

If so, as determined by module 964, RunStep in module 966 reads the step and sets the progress environment to execute the next step. Module 968 checks if the step read is valid and reports success if valid. If there is no legitimate step read, RunStep checks in module 970 if the last line of the step subfile of the last time period has actually been reached, and if so, RunStep returns a "All Steps Processed" message to indicate that all tests have completed. Give off. If not, RunStep reports a failure.

On the other hand, if RunStep's module 964 shows that the line number just read does not match the expected line number, RunStep proceeds to the routine shown in FIG. The first module 972 checks whether RunStep actually reached the last row of the step subfile for that last step. If so, a message is reported indicating that all tests have been completed. If not, module 974 checks whether the last row of the step subfile has been reached. If so, RunStep returns to module 956 to open the step subfile for the next test step.

On the other hand, if RunStep confirms that it is not the end of the step subfile, RunStep checks in module 976 to see if the line number just read exceeds the line it was expecting (from a read of memory). If the line number is exceeded, this tells RunStep that there was an artificial dishonesty in the step subfile (for example, the operator removed a step from the step subfile) and RunStep reports a failure. If the line number is not exceeded, RunStep returns to module 962.

RunStep then returns to module 990, Figure 8, and when it encounters the end of the step subfile, it reports this to the operator. RunStep again checks if a failure was reported in module 992. If so, this is reported and RunStep is retired.

In this step, RunStep has already determined the exact state of the system, and soon knows if you want to redo the step, rewind the phase, or execute the next step in the step subfile and set the memory accordingly. Before continuing, RunStep saves all the information it learned from the previous steps. This is done in module 994, which is illustrated in more detail in FIG.

First of all, module 1000 has the opportunity to erase all files that are no longer needed. Module 1002 then determines whether the file (s) needed for the test or software installation to be run now are stored on a local drive or need to be acquired over the network and store this information. The next module (1004, 1006, RunStep) then uses the environment variables (progress.bat) to obtain the information obtained in the previous step so that all the environment variables are updated to reflect the current state of the system the next time RunStep is run. It is used for setting of).

After checking in module 1008 if writing is successful, RunStep writes the log file in module 1010. If this is successful, module 1012, it is determined in module 1014 whether a redo is needed and module 1016 creates a redo file if it is needed.

Control then returns to module 1020, FIG. 8 and if no failure is reported, the program exits to a 255 error level indicating that execution of the command line read from the step subfile in module 966 should be made ( Evicted). This is done in module 1022. RunStep then returns to the start to process the next step (the line in the step subfile).

The RunStep program can be considered a high-level security system in that several checks are included to prevent unauthorized operators from illegally handling step subfiles and to avoid tedious tests or to avoid reruns. This is accomplished by disabling control brakes, checking the number of lines in the step subfile at various intervals, and entering a checksum into the system. Another security feature is that whenever a fault (failure) determined by RunStep occurs at various points in the flow chart above, the RunStep is retired and the fault is described in a read-only concealment file, where an accidental operator may modify the file. You will not know it and you will not find it, so you will not know what is wrong and how you can avoid the obstacle, that is, he will be forced to dismiss the component or re-execute until it is satisfied.

Although exemplary embodiments have been shown and described, a wide variety of modifications, changes and substitutions may be envisioned in the invention and in some cases some features of the embodiments may be utilized without the use of corresponding other features. It is therefore appropriate that the appended claims be interpreted broadly and in a manner consistent with the scope of the foregoing embodiments.

As described above, a method of installing and / or testing software for a computer system that can provide improvements to the prior art is provided.

Claims (20)

Reading a plurality of component descriptors describing each component of the computer system from the computer readable file, Reading a plurality of steps corresponding to the component descriptors from the database and including respective sequence numbers, Sequencing the plurality of steps in a predetermined order according to the sequence number to provide a step sequence including instructions for installing and / or testing software on the computer system, For each step read from the database, further comprising determining from data related to the step from the database, Computer system, characterized in that if the step is incompatible with the presence of other components in the computer system that do not correspond to the component descriptor associated with the step, the step is not given up according to additional data relating to the step in the database. Installation and / or testing methodology for the software. The computer system of claim 1, wherein the computer system belongs to a particular family of computer systems, and wherein reading the plurality of steps includes: executing and installing a first database table on the plurality of components, the first database table including all components belonging to the particular family; And / or combining with a second database table containing all the software to be tested, wherein the combining generates an intermediate set, which includes all software installation / testing steps to be executed for a particular family. Combine with a third database table, said combining creating said plurality of steps. 3. The method of claim 2 wherein an error occurs if the intermediate set is empty. The method of claim 1 wherein at least one each component is a hardware component. The method of claim 1 wherein at least one component is a software component. 2. The method of claim 1, further comprising generating a plurality of derived objects corresponding to the plurality of component descriptors. The method of claim 1, further comprising preparing an environment variable corresponding to the plurality of components. 2. The method of claim 1, further comprising the step of writing the step sequence to a nonvolatile storage device intended for accompanying computer system during the manufacturing process. 2. The method of claim 1, wherein the step sequence is adapted to provide instructions that can be repeated for a predetermined time. The method of claim 1, wherein the step sequence is adapted to provide an instruction that can be repeated for a predetermined number of times. Reading a plurality of component descriptors describing each component of the computer system from the computer readable file, Reading a plurality of steps corresponding to the component descriptors from the database and including respective sequence numbers, Sequencing the plurality of steps in a predetermined order according to the sequence number to provide a step sequence including instructions for installing and / or testing software on the computer system, For each step read from the database, further comprising determining from data related to the step from the database, And if the step requires a parameter, calculate the parameter according to additional data related to that step in the database. 12. The computer-readable medium of claim 11, wherein the computer system belongs to a particular family of computer systems, and wherein reading the plurality of steps includes executing and installing a first database table on the plurality of components, the first database table including all components belonging to the particular family. And / or combining with a second database table containing all the software to be tested, wherein the combining generates an intermediate set, which includes all software installation / testing steps to be executed for a particular family. Combine with a third database table, said combining creating said plurality of steps. 13. The method of claim 12, wherein an error occurs if the intermediate set is empty. 12. The method of claim 11, wherein at least one each component is a hardware component. 12. The method of claim 11, wherein at least one component is a software component. 12. The method of claim 11, further comprising generating a plurality of derived objects corresponding to the plurality of component descriptors. 12. The method of claim 11, further comprising preparing an environment variable corresponding to the plurality of components. 12. The method of claim 11, further comprising the step of writing the step sequence to a nonvolatile storage device intended for accompanying computer system during the manufacturing process. 12. The method of claim 11, wherein the step sequence is adapted to provide instructions that can be repeated for a predetermined time. 12. The method of claim 11, wherein the step sequence is adapted to provide instructions that can be repeated for a predetermined number of times.