DE19922767A1 - Software installation method and/or test method for computer system, by following sequence of steps in accordance with component descriptors read from file - Google Patents

Abstract

The method involves reading component descriptors from a file, and reading steps from a database, each step being assigned to a component descriptor and comprises a corresponding sequence number. The steps are brought into a predetermined sequence in accordance with the sequence numbers, to create a sequence of steps with commands for the installation of software and/or testing the computer system. It is determined if each step is incompatible with the presence of a component other than that corresponding to the component descriptor, and rejects the step accordingly.

Description

background

The present disclosures relate to an apparatus for use with the manufacture of a computer system.

The application is included in the pending German patent application related to No. 198 36 328.1, which was filed on August 11, 1998 with titled SOFTWARE INSTALLATION AND TESTING FOR A SMALL ORDER BUILT COMPUTER SYSTEM with the inventors Richard D. Amberg, Roger W. Wong and Michael A. Brundridge.

The application is included in the pending German patent application related to number 198 36 333.8, which was filed on August 11, 1998 is entitled SOFTWARE INSTALLATION AND TESTING FOR ONE COMPUTER SYSTEM BUILT ACCORDING TO ORDER with the Inventors Richard D. Amberg, Roger W. Wong and Michael A. Brundridge.

The application is included in the pending German patent application related to No. 198 36 381.8, which was filed on August 11, 1998 with DATABASE TO EASIER THE SOFTWARE-  INSTALLATION AND TESTING FOR ONE ORDER BUILT COMPUTER SYSTEM by inventor Richard D. Amberg, Roger W. Wong and Michael A. Brundridge.

These pending applications are hereby incorporated by reference in their Whole is included and are the assignee of this invention assigned.

Personal computer systems in general and IBM compatible Personal computer systems in particular are common to many To provide areas of society with computing power. On Personal computer system can be as one on a table or the floor arranged or also portable microcomputer can be defined, the one System unit includes a system processor and associated volatile and non-volatile memory, a screen, a keyboard, one or more Floppy disk drives, hard disk space and an optional printer includes.

It is known to install software and tests on computer systems before they are shipped to companies or individual customers. The The goal of software installation and testing is to efficiently run a to produce a usable and reliable computer system that is error-free and can be delivered ready for operation to companies and individual customers. Testing discovered and analyzed in general errors, both in hardware and also occur in the software of the computer. Computer hardware tests can diagnose hardware components, such as the Processor, memory, hard drive, an audio device, a Include graphics setup, keyboard, mouse, and printer. in the Software installation is often a desired package of software  played on the computer, suitable environment variables for the computer set and appropriate initialization files for the installed software generated. Software testing often ensures that the desired one Version of the software has been installed on the computer system and that suitable drivers are available on the computer system.

It is known in the industry to install software during manufacture and test computer systems by performing a set procedure will be sent to customers before they are shipped. For example, a Floppy disk that produces certain diagnostic tests for certain types of Contains computer systems. There are long, often complicated ones on this disk Batch files (batch files), the software installation and the Control diagnostic processes. The diskette also contains all executable files to carry out tests on the purchased computer system.

Each computer system is manufactured with a corresponding copy of these disks. These disks accompany the computer systems during manufacture within the factory, being on each Computer system tests according to the order in the batch file be performed. If there is a change in this procedure the batch file is changed accordingly by Parts of the code in the batch file are added or removed. This Changing the batch file leads to a corresponding change in the Test parameters (including the order in which the tests are performed ) for each subsequently built computer system, since each Computer system the diagnostic procedure according to the same batch file goes through.  

Although diagnostic methods of this type prove to be to some extent have proven useful to demonstrate the reliability of computer systems improvements, however, are possible. So For example, the batch file and executable files exceed Diagnostic tests often use the storage capacity of a floppy disk because testing is always becomes more complicated and thorough. It is also often difficult or difficult impossible to test and software install procedures on a single, Computer system built according to an order or for a specific one Align family of computer systems without testing for others To change computer systems or families. It is also difficult or impossible the order of software installation or testing for a single computer system built to order or for one to change certain family of computer systems without changing the order for change other computer systems and families. After all, it does it often complicated nature of the structure of the batch files used sometimes difficult for the manufacturer to troubleshoot or the procedures for testing and to maintain software installation quickly and efficiently.

Therefore, there is a method of installing software and / or testing a computer system that improves the state of the art.

Summary

According to one embodiment, a method for installing software and / or for testing a computer system comprising reading a variety of component descriptors from one computer readable file, each component descriptor having a corresponding one Component of the computer system describes reading a variety of Steps from a database, each step a component descriptor is assigned and includes a corresponding sequence number and the in-  Ordering the plurality of steps into a predetermined order according to the order numbers to create a step order with commands to install software and / or test the Computer system, the method further determining each step comprises, which has been read from the database from data which this step are assigned from the database whether this step is incompatible with the Presence in the computer system of a component other than that which the Component descriptor associated with and in the step Case discard or not discard the step according to the other data assigned to the step in the database.

According to a further embodiment, a method for installing Software and / or created for testing a computer system that has reading a variety of component descriptors from one by one Computer readable file, each component descriptor having a corresponding one Component of the computer system describes reading the multitude of Steps from a database, each step a component descriptor is assigned and has a corresponding sequence number and the in- Ordering the plurality of steps into a predetermined order according to the order numbers to create a step order with commands to install the software and / or test the A computer system, the method further comprising determining for everyone Step that has been read from the database, from data included in this step have been assigned to the database whether this step requires a parameter and in this case calculating this parameter according to the other data, assigned to this step in the database.  

Brief description of the drawings

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

Fig. 2 is a schematic diagram showing the software installation and testing according to another embodiment.

Figure 3A is a flow diagram for converting a computer order to a system descriptor list in accordance with the present invention.

Fig. 3B shows a portion of an exemplary computer order, a base assembly Record (BAR) file and a Systemdeskriptorenliste.

Figure 4 is a flow chart for creating and providing a step order.

Figure 5A is a schematic illustration of the relationship between Figures 5B and 5C.

Figure 5B is a first part of a more detailed flow chart for generating a step order.

Figure 5C is a second part of the more detailed flow chart for generating a step order.

Fig. 6 shows a structure of a database.

Fig. 7 is an example of a portion of a step file.

Fig. 8 to 13 are flow charts of the operation of a program, an execution of a step sequence.

Detailed description

The description should be illustrative and should not be taken to be limiting become. In the drawings, the same or similar elements can be identified by the  same reference numerals. In the description is a module defined as a command or a group of commands.

Fig. 1 is a schematic diagram of the system 90 for installing the software, and testing at the manufacturing site of a computer system. In operation, an order 92 is placed to purchase a target computer system 160 built according to an order. The target computer system 160 is intended to be manufactured to include a variety of hardware and software components. For example, target system 160 may include a particular brand of hard drive, a particular monitor type, a specific processor brand, and a particular operating system version. Before the target system 160 is shipped to the customer, the large number of components are installed and tested. Such software installation and testing advantageously ensures a reliable computer system that is operational as soon as it is received.

Because different families of computer systems and different individual computer components require different software installation and testing steps, it is necessary to determine which tests need to be performed on the target system 160 and in what order these tests should be performed in order to have an effective software installation and testing process to reach. The step generator 140 is a computer system that is configured to order the software installation and test steps to be performed on the target system 160 . In order to order the software installation and / or test steps, the step generator 140 and in particular the sequence program 204 , which is located on the step generator 140 , first reads a multiplicity of component descriptors from a descriptor file 96 . The descriptor file 96 is provided by converting an order 92 that corresponds to a desired computer system with the desired components into a computer readable format via the conversion module 94 .

Component descriptors are computer readable descriptions of the components of target system 160 , the components of which are defined by order 92 . In the preferred embodiment, the component descriptors are contained in a descriptor file called the system descriptor list, which is a computer readable file with a list of the components, its hardware and / or software components to be installed on the target system 160 . After the plurality of component descriptors have been read, the sequence program 204 retrieves a variety of software installation and / or test steps from the database 100 over a network connection 110 that correspond to the component descriptors. Network connection 110 may be any known network connection, such as a LAN (Local Area Network), an intranet, or the Internet. The information contained in database 100 can be updated by a modification represented by arrow 130 .

After the software installation and / or test steps that are suitable for the target system 160 are retrieved, the sequence program 204 puts the steps in a predetermined order according to the sequence numbers corresponding to each step. After the steps required for the target system 160 are put in order, the order program 204 writes a series of output files onto the step disk 150 . In the embodiment shown in FIG. 1, the output files include text files with command parts that are suitable for performing the appropriate software installation and / or test steps on the target system 160 . The execution is carried out in the predetermined order according to the order numbers corresponding to each step. The step disk 150 accompanies the target system 160 in the factory, the tests being carried out directly from the step disk 150 or alternatively from the file server 190 , which is connected to the target system 160 via the network connection 180 . The network connection 180 is preferably a generic network device which is plugged into a corresponding network port of the target computer system. After the software installation and test steps have been carried out, the results of the installation and tests are logged on the file server 190 via the network connection 180 .

Fig. 2 is a schematic diagram of the system 192 for software installation and testing according to a further embodiment of the present invention. A customer places an order 92 to purchase a target computer system 160 built according to an order. Target system 160 is manufactured to include a variety of components, which component can be both hardware and software components. Before the target system 160 is shipped to the customer, the variety of components are installed and tested. Such installation and testing ensures a reliable, working computer system that is operational as soon as it is received by the customer.

In order to put the software installation and test steps in order, the sequence program 204 reads a plurality of component descriptors from the descriptor file 96 . The order 92 is converted to the descriptor file 96 via the conversion module 94 . Component descriptors are computer readable descriptions of the components of target system 160 . In the preferred embodiment, the component descriptors are contained in a descriptor file called a system descriptor list, a computer readable file that contains a listing of each component, be it a hardware or a software component, that is installed on the target system 160 should. The system descriptor list can be stored directly on file server 202 . Sequence program 204 retrieves a variety of software installation and / or test steps corresponding to component descriptors from database 100 . After the appropriate software installation and / or test steps for the target system 160 are retrieved, the sequence program 204 brings the steps into a predetermined order according to the sequence numbers corresponding to each step. After the steps required for the target system 160 are put in order, the sequence program 204 controls the execution of the software installation and test steps on the target system 160 in the predetermined order via the network connections 195 and 180 . It is desirable that network connection 200 be a generic network device that plugs into a corresponding port on target system 160 . Network 195 may be any known communication link. After the software installation and / or test steps have been carried out, the results of the installation and tests are logged on the file server 202 via the network connection 200 or stored in a suitable database. As can be seen from the illustration, the separate computer system 140 for step generation from FIG. 1 is not required. In addition, a step disk 150 is not necessary. Instead, only a boot disk 220 is required, which is configured to the target system 160 to boot and accompanied in the factory the target system 160th

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

Figure 3A shows the preferred process in which an order for a computer system is converted to a computer readable system descriptor list. More specifically, an order for a target system is received in unit 300 . This order can take one of many forms. For example, different order formats are possible as well as different order transfer mechanisms. For example, orders for a target computer system can be placed over the phone, mail, or over a computer network (such as the Internet). Regardless of the means of receiving or the form of the order, the order includes the type of target computer system that a customer wants to buy and possibly an explicit listing of the particular components that the customer wants the target computer system to contain. After the order has been received, control passes to the transfer module 310 in which the order of the target computer system is transmitted over a computer network to a manufacturing system (not shown) that manufactures the target computer system. The order of the target computer system is also delivered to the software installation and test system and then directed to a conversion program in module 320 . The computer network used in module 310 can be any of the networks known in the art.

The conversion program converts the order of the target computer system into a list that is useful for the manufacturing process. More specifically, the conversion program first converts the computer order to a list called BAR file in module 330 . Preferably, the BAR file contains a unique identifier that identifies the particular target computer system that is being manufactured. The BAR file also contains a detailed list of the components, be they hardware or software components that are to be contained in the target system. It is also desirable that the BAR file contain manufacturer specific part numbers or other useful identifications for each component. Finally, the BAR file can contain customer-specific information such as the name, address and telephone number.

After the BAR file has been generated in module 330 , a system descriptor list is generated in module 340 . A system descriptor list, in the preferred embodiment, is a computer readable file that describes the hardware and software components that are to be included in the target computer system. In a preferred embodiment, the system descriptor list contains a list of components of the target computer system in a format that includes hardware tags, software tags, information tags, and comments. A hardware tag identifies to the sequence program 204 that the information that follows the tag relates to a hardware component. Similarly, a software tag identifies that the information that follows the tag relates to a software component. The information tag indicates that general information follows. Comments allow various entries to be included in the system descriptor list that are ignored by the sequence program 204 . It is desirable that the system descriptor list be a text file that is human-readable and easy to understand. Such a file advantageously enables simple troubleshooting and simple maintenance of the installation and test process. It is understood that the system descriptor list can be any list of unique identifiers that corresponds to a unique set of labels, for example, in a simple example, the system descriptor list can be a list of part numbers.

Fig. 3B shows an exemplary target computer system order 350, a corresponding BAR file 370 and a corresponding Systemdeskriptorenliste 370. The target computer system order 350 contains the name of a computer family, in this example family "X". Furthermore, the target computer system order 350 contains three exemplary hardware components with a Pentium® processor, a hard disk and a monitor. The BAR file 360 results from the order 350 of the target computer system going through a conversion program, as shown in module 320 of FIG. 3A. The BAR file 360 contains unique identification for the specific target computer system within the X family. The BAR file 360 also contains the manufacturer specific part numbers for each of the components listed in the order of the target computer system. BAR file 360 also includes an identifier that indicates the desired number of each component as well as a text description of each component to be included in the target computer system. System 90 uses BAR file 360 to generate system descriptor list 370 .

As explained, the system descriptor list 370 also contains the unique identifier for the particular target computer system within the X family. In addition, the system descriptor list 370 contains appropriate tags that indicate here that the processor, hard drive and monitor contain all hardware and not software components are. The system descriptor list 370 describes these components in a textual description. In addition, the exemplary system descriptor list 370 includes a software tag that indicates that particular software should be installed or tested on the X family computer system. For example, the software tag may indicate that a particular operating system suitable for the Pentium processor is always installed on the hard drive of the target computer system belonging to the X family.

Figure 4 sets out the general procedure for ordering software installation and test steps. A unique identification of the target computer system for the target computer system 160 is generated in the module 400 . In the embodiment shown in FIG. 1, a user sitting at the step generation computer system 140 generates a unique identifier (e.g., the BAR identifier that works as a tracking code) in the sequence program 204 of the step generator 140 . Alternatively, in the embodiment of FIG. 2, a unique identification is automatically read into the sequence program 204 after the order of the target computer system has been taken up.

A system descriptor list corresponding to the BAR identification is sought in module 410 . In the embodiment of FIG. 1, the system descriptor list is found over either network connection 110 or network connection 195 . In the embodiment of FIG. 2, the system descriptor list is found over network connection 195 . The found system descriptor list is delivered to the sequence program 204 in module 420 . In the embodiment from FIG. 1, the sequence program is on the computer system 140 for step generation, while in the embodiment from FIG. 2 the sequence program is at the file server 202 . Sequence program 204 works in conjunction with database 100 ( FIGS. 1 and 2) to sequence software installation and testing steps for target computer system 160 . After the software installation and test steps that are suitable for the specific target computer system have been brought into an order, the order program 204 generates output files, as shown in module 430 .

In the embodiment of Fig. 1, the output files written on the step disk 150 (see Fig. 1) are a step file and a Setenv.bat file. The step file is an ASCII text file with a list of appropriate command lines for performing the software installation and testing steps for the target computer system that has been ordered. In a preferred embodiment, the step file further includes instructions that can be executed in a loop. More specifically, the step file allows commands to be repeated for a specified number of iterations or for a specified period of time. Such a format advantageously enables the software installation and test steps to be repeated in a calculated predetermined manner. The Setenv.bat file sets environment variables on the target computer system. The step file and the Setenv.bat file are ASCII text script files that contain a list of appropriate command lines to perform the installation and test steps for the target computer system. The step file is divided into a number of individual subfiles, each containing steps for a corresponding phase of production, for example for the Quick Test (Qt) -, Extended Test1 (ET1) -, Extended Test2 (ET2) -, Software Install ( SI) and Final Test (Ft) phases of manufacturing the target computer system.

In the embodiment from FIG. 2, however, the output files are not written to a step disk as shown in FIG. 1. Instead, the output files reside on file server 202 or file server 190 , where they are used to control the execution of software installation and / or test steps on target computer system 160 .

FIGS. 5A to 5C show a detailed schematic of the operation of the program sequence 204, shown in Figs. 1 and 2.

Decision module 500 determines the origin of an order. At the moment only the left branch is considered. If necessary, module 502 applies one or more patches to the system description list. In the preferred embodiment, this patch is modular and allows patches to be generated for a special target computer system, a special family of computer systems or for a special component. For example, if a manufacturer wants to exchange one brand of hard drive for another for a particular family of computer systems on a given day, a patch can be created that modifies all system descriptor lists that contain the hard drive to be replaced and performs the replacement in module 502 .

The module 504 then enters the (corrected) system descriptor list that corresponds to the target computer system 160 into the sequence program 204 . In module 506 , a component descriptor is read from the system descriptor list. Each component descriptor describes a corresponding component, be it a hardware or software component of the target computer system.

Referring to Figure 3B, the line of the system descriptor list with the Pentium® processor in module 370 is an exemplary component descriptor. In module 508 , sequence program 204 generates a plurality of derived objects that correspond to the plurality of components of target computer system 160 . In the preferred embodiment, these derived objects are used to store information (obtained from database 100 ) about the software installation and testing steps that must be performed on target computer system 160 . Correspondingly, a corresponding component of the target computer system 160 is assigned in module 510 to each derived object.

At this point, the right branch of module 500 is considered. In this case, the order is assumed to be stored directly by a customer as an entry in a database in the form of a list of materials, such a list having component descriptors related to the target computer system 160 . Module 512 , which is equivalent to module 502 , applies changes (patches) to the bill of materials, while module 514 reads the bill of materials from the database in which it is stored for use by sequence program 204 .

In module 516 , the software installation and test steps associated with the corresponding components of target computer system 160 are retrieved from database 100 and stored in the appropriate derived objects. In the embodiment of FIG. 1, the steps are retrieved via network connection 110 , while in the embodiment of FIG. 2, the steps are retrieved directly from file server 202 . To describe how the steps are retrieved from database 100 in the preferred embodiment, a description of this preferred embodiment of this database is necessary.

Fig. 6 shows the structure of the database 100.. Database 100 assigns a sequence of software installation and / or test steps in a predetermined order to families of computer systems. Database 100 is further configured to map components of computer systems. Furthermore, the database assigns 100 software installation and / or test steps to components of computer systems.

Database 100 is preferably a relational database. The database 100 contains several tables, each of which contains suitable attributes for generating the above-mentioned assignments.

The database 100 contains 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 , a step dependency 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 underlined attributes serving as a primary key.

The step table 102 contains all software installation and test steps for all possible components from all computer families. In the preferred structure, the step table 102 has attributes that include the step ID, name, command, command type, after action type, MaxInstance, class ID and DepMask. Step ID is a unique identification number for each software installation or test step. Name is a string that assigns a name that describes a step. Command is a string used to assign an executable command line to perform a software installation or test step. Name is a string that assigns a name that describes a step. Command is a string for assigning an executable command line to perform a software installation and test step on the target computer system 160 (shown in FIGS. 1 and 2). AfterAction-Type is an identifier that determines whether a stop or restart is necessary after the software installation or test step has been performed. MaxInstance is an identifier that indicates the maximum number of allowed repetitions that a step can run. Class ID identifies a specific type of class or component (e.g. hard disk, CD-ROM drive) that is assigned to the software installation or test step. Finally, DepMask stores information as to whether or not a respective step has a step dependency and / or a step parameter and therefore determines whether or not the step dependency table 116 and / or the step parameter table 118 must be opened.

The family table 104 identifies each family of computer systems with an identification integer specified in the FamilyID attribute. The family table also contains a string that identifies the family name.

The family step order table 106 is a relational table that contains relations between the step table 102 and the family table 104 . The family step order table 106 includes a family identification integer specified in the FamilyID attribute for a respective family of computer systems (from the family table 104 ), a step identification integer specified in the StepID attribute (from the step table 102 ) is identified and which identifies a respective group of steps which are suitable for this family and an order number. The order number is included in the step order number attribute, which represents a predetermined order in which steps associated with each family are to be performed. Test engineers assign sequence numbers that are unique to each stage of manufacture and that are selected in an order to be most effective for a particular target system. It is understood that other types of sequence number assignment can be used. Finally, the family step order table 106 includes a phase ID. The phase ID indicates in which phase of the production the step should be carried out. For example, PhasesID is an integer that has been selected to correspond to one of the five phases of manufacturing the computer system mentioned above: Quick Test (Qt), Extended Test1 (ET1), Extended Test2 (ET2), Software Install (SI) and Final Test.

The component table 108 contains all possible components that are contained in the computer systems that are manufactured. The attributes of this table are ComponentID, which assigns an identification to each component, Description, which assigns a string to each component, and ClassID, which designates the type of the component (e.g. hard disk drive, CD-ROM drive).

The family component table 112 is a relational table that contains relationships between each family of computer systems and a group of components that may be included in the family. The attributes of the family component table 112 include an integer for computer family identification that is specified in the family ID attribute (from the family table 104 ) and an integer for component identification that is specified in the component ID attribute (from the component table 108) ) is specified.

The component step table 114 is a relational table that contains relations between each component and a group of software installation and test steps suitable for that component. The attributes of the component step table 114 include an integer for component identification that is specified in the attribute component ED (from the component table 108 and an integer for step identification that is contained in the attribute step ID (from the step table 102 ) is identified.

The step dependency table 116 contains data relating to possible conflicts. Some tests may conflict with certain classes of components or specific components themselves or components from certain manufacturers. For example, computer system 116 to be manufactured may have a brand A hard drive and a brand B CD-ROM drive. A brand hard drive may normally require Test C to be run, but Test C may require that the CD-ROM drive B is incompatible. All of these dependencies are stored in the step dependency table 116 . In this table, the step ID identifies the step that has a dependency, TypeID indicates whether or not the dependency relates to a class of components or a specific component, object ID is either a class ID or a component ID, depending on the status of TypeID and DepTypeID, indicates whether or not a particular step should be kept or removed when the conflict occurs.

The step parameter table 118 identifies parameters that certain steps may need; for example, a step may need to run for a certain amount of time or with a certain number of iterations. In table 118 , StepID clearly identifies the respective installation or test step. ParameterID identifies each parameter associated with this step; there can be more than one parameter associated with each step and each will have its own ParameterID. For example, the same test, but with different parameters, can be used for different brands of hard drives. DataType identifies the type of data that should be contained in the corresponding parameter. In the example above, DataType can specify that the data refer to a percentage or, alternatively, a hard drive ID code. The content is a command line switch as used in the C programming language in connection with commands such as "printf". For example, content can be "-% d" to indicate that a percentage is suitable for this parameter. The step order number and class ID are as described above.

It should be noted that the step parameter table 118 only stores the types and number of parameters associated with a particular step, but not the actual value of these parameters. During the construction of the step file described below, table 118 does not insert parameter values in a command line of the step file. Instead, it contains all the details necessary to allow the command line to be constructed. It is the sequence program 204 that calculates the value of the parameter and inserts it into the command line of the step file during execution. The sequence program performs the calculation based on the information contained in the descriptor list.

The advantage in the step parameter table 118 is that it enables greater flexibility by preventing parameters from having to be permanently assigned to steps. As a result, the table 118 enables an engineer to quickly modify the parameters without having to edit the step table 102 . The component class table 120 is simply a list of all classes of components (class ID), for example hard disk, CD-ROM drive etc., together with a brief description of these classes (class name, description).

The component class attribute table 122 lists all classes and all attributes associated with each class. AttributeID is a code associated with each different type of attribute, such as memory size, work speed, manufacturer, etc., while AttributeName is a more descriptive name of the attribute for an engineer. DataType is a display of the type of data that is used to represent each attribute. For example, it can be a string of characters if the attribute is the manufacturer's name, or it can be an integer if the attribute is a memory size.

The component class table 120 and the component class attribute table 122 are not actively used by the sequence program 204 , but are primarily used by development engineers. These tables do not include 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 an operator to insert a tape into a drive before testing the drive.

The target computer system shown in Figure 3B is used to illustrate how the database structure set forth above is used to retrieve software installation and test steps. The computer family identifier in the system descriptor list that identifies family X is mapped to the family ID that corresponds to family X in family table 104 . The component table 108 is used to check whether the components of the target computer system listed in the target computer system order are allowed. In other words, the sequence program and database determines whether the processor, hard disk, and monitor and software contained in the system descriptor list of FIG. 3 have corresponding entries and corresponding integers identified by component ID in the component Table 108 are specified. If a component is not allowed (that is, if a component in the system descriptor list is not in component table 108 ), an error flag is set. The family component table 112 is a relational table that contains images of the component table 108 and the family table 104 . Family component table 112 contains all of the permitted components that may be included in a target computer system belonging to family X. Therefore, the family component table 112 can be used to check whether all components of the target system are allowed. In other words, the sequence program and database determine whether the processor, hard drive, monitor, and software included in the system descriptor list of FIG. 3B have corresponding relationships in family component table 112 . If a component is not permitted (that is, if a component in the system description list cannot be contained in a target system belonging to family X), an error flag is set.

The relational family step order table 106 contains images of the step table 102 and the family table 104 . Family step order table 106 contains all of the software installation and test steps that may legally be performed on the target X family computer systems. In addition, in this family step order table 106, the order and phase numbers are assigned to each software installation and test step. These sequence and phase numbers represent the correct order in which steps are to be performed for a particular family of computer systems. Family step order table 106 , therefore, contains a list of steps to be performed on family X target computer systems, as well as order and phase numbers that represent the predetermined order in which the steps are to be performed.

The component step table 114 is a relational table that contains images from the component table 108 and the step table 102 . The component step table 114 contains the software installation and test steps to be performed for the processor, hard drive, monitor, and software on the target computer system.

Getting the software installation and test steps associated with the corresponding components to be included in the target computer system involves performing a join operation on the family component table 112 and the component step table 114 to obtain an intermediate set listing steps to be executed on the components of the target computer system 160 .

The link operation provides a list of steps listed on the processor, hard drive, monitor and software listed in the system description list shown in Figure 3B. The result of connecting the family component table 112 and the component step table 114 is then connected to the family step order table 106 , which contains all the steps for the family X. The result of this connection operation includes order information in the form of order numbers and phase numbers, the order numbers being unique within a respective phase. The three table connections of the family component table 112 , the component step table 114 and the family step order table 106 provide the appropriate software installation and test steps as well as the order information in the form of order and phase numbers for installing and / or testing the software the target computer system 160 .

If the result of the first connection operation (the connection of the family component table 112 and the component step table 114 ) is an empty set, an error condition is set because an empty set indicates that a component to be included in the target system is not in belongs to the family that is listed in the system descriptor list. An example should explain this. Assume that a system descriptor list correctly indicates that a target computer system belongs to the Y family. However, it is assumed that the system descriptor list incorrectly indicates that a hard disk (hard disk Z) that belongs only to target systems in the X family should be included in the target system that is in the Y family. In this case, the component step table 114 contains steps associated with the hard disk Z. Family component table 112 contains components associated with family Y. Therefore, joining the component step table 114 to the family component table 112 creates an empty set because the hard disk Z is not a component that is associated with the Y family (instead, it is only associated with the X family). As is clear from the example above, the preferred structure of the database advantageously allows to ensure that the target system of a particular family contains only components that are suitable for that family.

After the steps that are assigned to the components that are to be contained in the target system have been called (see FIGS. 5A and 5C), the module 518 of the sequence program 204 determines for each step whether a dependency for this step exists by examining DepMask for this step. In this case, module 520 reads the dependency from step dependency table 116 and module 522 solves the dependency according to the DepTypeID.

Next, module 524 determines if the step needs a parameter again by examining DepMask for that step. In this case, module 226 reads the parameter data from step parameter table 118 and module 528 calculates the actual value of the parameter and inserts it into the command line for that step.

Now, module 530 prepares environment variables for the target computer system by reading the system description list and creating an environment file that corresponds to the components that should be included in the target computer system. For example, the system description list shown in FIG. 3B is read and an environment variable, such as. B. "set cpu = pentium" can be prepared which corresponds to the processor hardware component of the system description list.

In module 532 , the plurality of software installation and test steps that have been called up, which have been called up by the three-table connection described above, are brought into the predetermined order with the resolved dependencies and the added parameters. This ordering matches the corresponding sequence and phase numbers to generate a sequence of steps. The ordering itself can be accomplished using one of many known sorting algorithms.

In module 534 , the sequence program 204 outputs the step file and the aforementioned Setenv.bat file. The step file is divided into a number of subfiles that contain the steps that are corresponding to the Quick Test (Qt) -, Extended Test1 (ET1) -, Extended Test2 (ET2) -, Software Install (SI) and Final Test (Ft ) Phases of the manufacture of the target computer system are to be carried out.

As shown, module 534 stores the output files as such or in a database on file server 202 in the embodiment of FIG. 2. The output files written to file server 202 can be used to control the execution of software installation and testing steps on target computer system 160 .

In module 536 , the step order is modified, if necessary, using a step order patch. In the preferred embodiment, the patch is modular and allows patches to be created for a specific target computer system, family of computer systems, or a particular component.

For example, if a manufacturer wants to perform a test step before another for a particular component on a given day, a patch can be created that modifies all of the step sequences that contain the steps whose order is to be modified and changes the execution order in module 536 accordingly .

Once corrected, module 538 outputs revised files for storage, again either as such or to a database on file server 202 .

Finally, the module 540 enables, on a diskette 150 , cf. Fig. 1 to write. If a diskette is needed, module 442 , instead of writing directly to the diskette, creates a "virtual diskette" in memory and module 544 then writes the entire virtual diskette to the physical diskette in one operation. This reduces the number of writes on the diskette drive and therefore significantly speeds up the overall operation of the program.

The virtual disk is created by the following program, the one Generated memory that is equivalent to the physical disk by the Allocate a field of memory blocks, each the size of a physical sector on the physical disk are equivalent. The The file system is FAT12 (used by PC-DOS, MS-DOS, Windows 95 and Windows NT operating systems). The first sector is the boot sector of the disk. A cluster is a logical grouping / unit of a group of sectors.  

This number is fixed as soon as a file system has been initialized. For example, a cluster size is two sectors. The file system allows allocation only by cluster, not by sector. In this case, the smallest Consume file at least 1 cluster (or 2 sectors).

begin
Create an array of a block of memory. The number of memory blocks should be equal to the number of physical sectors on the disk with the given file system.
Initialize the contents of all memory blocks to zero.
Initialize the boot sector by copying an external image from only the boot sector. This external image is saved in a file.
Initialize the FAT tables. (Well-defined sectors on the diskette through the file system).

When a file write is requested.
Read the file.
Allocate the required cluster.
If an error occurs, exit the function with the error because there is not enough space.
Update the directory and FAT table for the allocated clusters.
Write the read content into the clusters.

When a file delete operation is needed.
Release the allocated cluster for the given file.
Update the directory and FAT table for the shared clusters.

When the process of writing a physical disk is requested.
Take the disk usage counter stored in the fourth byte of the boot sector from the disk.
If the counter is <= the maximum number, output an error code to indicate the reason for the error.
If the counter is <than the maximum number, increment the counter by 1.
Write the count back into the third byte of the boot sector on the virtual floppy disk.
Write the memory blocks from the virtual floppy disk to the physical floppy disk, stop when there are no more memory blocks with data.

The End.  

Referring again to FIGS. 1 and 2, arrow 130 shows that modifications can be made to database 100 . For example, when a new family of computer systems is created, the database 100 can be modified accordingly. The new family is more specifically associated with a new family in identifying FamilienID the family table 104 and a name is assigned to the new family in the name attribute of the Family Table 104th A list of software installation and test steps is added to the family step order table 106 , which steps represent which steps and in which predetermined order are performed on the new computer system family. If the new family of computer systems has several similarities with an existing family, it is likely that the entries for the existing family in the family step order table 106 can be modified to create the entries for the new family. If any new steps need to be created for the new family of computer systems, those steps are added to step table 102 . Similarly, if any components accompany the new family of computer systems, those components are added to component table 108 . The component step table 114 is updated to assign appropriate steps for its software installation and testing to each component of the new family of computer systems. If the new family only uses components that already exist in the database, this table does not have to be modified. The family component table 112 is updated so that a list of allowed components that may be included in the new family is in the database. In particular, it is necessary to assign the system ID of the new computer system to the component ID of each permitted component. Again, this can be done by copying and then modifying existing entries in older families of computer systems.

It is understood that when designing a database according to the preferred embodiment certain significant advantages are provided. In particular, the modular structure of the database allows an easy one Prepare software installation and test steps for new families of Computer systems. In addition, the software installation and Test steps for a respective family of computer systems or for one certain components are modified independently of other software Installation and test steps.

The execution of the step sequence on the target system 160 is described below. The software installation and test steps are performed on the target computer system 160 using a program that reads the sequence of steps, interprets and executes according to the target computer system. In the 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. 2.

Figure 7 shows a portion of a sequence of steps contained in a step file prior to performing any software installation and test steps. As already mentioned, the sequence of steps includes commands to install software and / or to test the target computer system built according to an order. In addition, the order of steps in the step file allows commands to be repeated for a specified number of iterations or for a specified period of time. The step file also contains comments that the RunStep program ignores. Markers 800 in the step file are used to separate fields of the step sequence from one another. The units 810 are commands for testing the target computer system 810 . The commands include, for example, a command to test memory and to test the Small Computer System Interface (SCSI) device. As can be seen from the figure, each command can include switches such as "-o" that are appropriate for the particular test environment. Unit 820 is a comment that is ignored by the RunStep program. The unit 810 c is an instruction that is executed in a time loop. In the preferred construction, the "begin_time_loop" command denotes the start point of a loop. The "end_time_loop" command denotes the end point of a loop. The "begin_time_loop" instruction is combined with a field that shows the time iteration in the loop. For example, command 810 c is executed here for one hour and thirty minutes. Unit 810d is an instruction that is looped according to a number of iterations. In the preferred embodiment, the "begin_iterate_loop" instruction instructs the RunStep program to execute a retry loop. The "end_iterate_loop" command signals the end of the loop commands. Command 810 d is executed three times here.

Figs. 8 to 13 illustrate the sequence of the RunStep program. As an overview, RunStep processes each step subfile line by line rather than reading the entire step subfile into memory. RunStep performs a number of checks on each line to determine whether or not to continue processing that line. For example, if RunStep sees that an error condition has been registered since the previous line was executed, it knows that there is no point in continuing with the program. Alternatively, RunStep can check to see whether or not an operator has corrupted the step subfile (for example, to skip a tedious test) and will not continue with the program to force the operator again to start. This means that a respective line of a step subfile is only read if RunStep determines that this line should be executed correctly next - there is therefore no unnecessary reading of lines from the step subfile. This is clearly a time-saving feature.

Figure 8 is a top level flow diagram of RunStep. The first module 900 initializes the state of the system. This is done before any line of a step subfile is read. During this stage, RunStep reads the various environment variables (from the "progress.bat" file, described below) so that it knows the exact state of the system, e.g. For example, whether an error has been returned in executing the last line or whether a retry must be performed or whether RunStep can continue reading the next line.

Fig. 9 describes the initialization stage in more detail. The first module 902 overrides a control interrupt - this prevents an operator from being able to break out of the program to bypass a step. Variables are then initialized in module 904 and the program reads the environment variables from the environment in module 906 . These environment variables are mainly stored in a batch file called progress.bat, which is held in memory and written to by RunStep when it executed the previous lines in the step subfile. Progress.bat contains the current system status and, as further described (module 106 , Fig. 13), is updated each time a line is read from the step subfile. Progress.bat will include information such as the line number of the last step performed, the identification of which actual command has been executed, how much time has elapsed when a respective command is executed within a time loop; which test or software installation phase is carried out.

If the environment variables are successfully read, as determined by module 908 , module 910 reads the directory list of all files on the local drive into the memory of the computer 160 or 202 running RunStep. Therefore, if RunStep is to check whether or not a file is on the local drive (module 1002 , Fig. 13), it can do so by reading the directory list in memory and does not have to search the local drive itself. This saves time.

If RunStep successfully reads the directory list, as determined by module 912 , module 914 retrieves the current process status. At this stage, RunStep sets a number of flags in accordance with the state of the system, ie failure or repetition, etc. These flags determine the flow of RunStep through the subsequent modules 916 , 918 , 920 . Depending on the RunStep, these modules control subroutines A, B or C, see FIG. 10.

Referring to Figure 10 (a), routine A is entered when RunStep has determined in module 916 that the next step is a normal process step. The first module in routine A, module 922 , verifies various checksums. This is done to ensure that the step subfiles have not been tampered with, ie RunStep reads certain checksums and compares them to checksums stored in Progress.bat - any differences would indicate that an unauthorized person modified the step subfile Has. If all checksums are correct, as determined by module 924 , the program resets (cleans up) various variables and reads the current time in module 926 .

Routine B in Fig. 10 (b) is opened when the environment indicates that the last step must be repeated, as determined by module 918 . The purpose of routine B is to give an authorized operator a way to intervene in the program to prevent the last step from being repeated if so desired. Thus a message is displayed in module 928 that the operator can select manufacturing tools (manufacturing tools, MFGTools) within five seconds or the repetition is continued. The manufacturing tools are a suitable method with which an authorized operator can intervene in the step file with a suitable password and modify it as desired. Module 930 determines whether the last step should be repeated depending on the operator's response and module 932 may run the progress environment (progress.bat) to run MFGTools.

Routine C, cf. Figure 10 (c) simply sets the progress environment (progress.bat) to run MFGTools in module 934 .

Referring again to FIG. 9, module 936 determines if an error has been returned and if not, module 938 checks if the current phase is allowable.

After the initialization module 900 has been completed, cf. Figure 8, and if "success" has been returned, as determined by module 950 , RunStep proceeds to module 952 , which is "step file processing". When RunStep has reached this stage, it has read enough information from the environment to know whether or not to proceed to the next line of the step subfile, repeat the previous step, or cancel.

Fig. 11 shows the module 952 "Processing step file" in more detail. Module 954 determines whether or not the manufacturing tools have been selected or whether a re-run is required. If any of these conditions are true, no further preparation is necessary and this part of the program can return success. If none of these conditions is true (ie RunStep should now proceed to the next line of the step subfile), the appropriate phase step subfile is opened in module 956 . This means that RunStep opens the step sub-file that is assigned to the respective phase of testing or the software installation that is currently being executed (e.g. quick test, extended test, etc.).

Module 958 determines whether or not there is a rewind phase. A rewind phase is a special case of repetition, in which the entire testing phase must be repeated in the event of a step failure, ie RunStep must go back to the beginning of the step subfile for that phase. If RunStep determines that it is a rewind phase, module 960 prepares the environment accordingly and success is returned.

If it is not a rewind phase, module 962 reads the next line number from the step subfile and further checks that the line number it has just read is the line it expects to read by the match the line number with the one stored in progress.bat that RunStep read during the initialization stage. Again, this is a device against tampering.

In particular, when RunStep is running, progess.bat will contain information relating to the last step performed, ie information such as the line number in the step subfile, the command ID of the command that has been executed, and other checks or relevant information. In module 962 , RunStep reads the progress.bat file contained in memory and jumps down a specific number of lines from the step subfile as determined by the number of lines in progress.bat. It then checks whether or not the number of lines at which it actually is matches the number of lines it expects to be at. It also checks whether or not the command on this line is the same as the one that it was told was just executed, ie RunStep validates that the line it is now on is actually the is the last step that has been performed.

If so, as determined by module 964 , RunStep reads the step in module 966 and prepares the progress environment to execute the next step. Module 968 checks that the reading of the step was valid and returns success if it was. If no valid step has been read, RunStep checks in module 970 whether or not it has actually reached the last line of the step subfile of the last phase. In this case, RunStep returns an "all steps processed" message indicating that all testing is complete. Otherwise RunStep returns a failure.

On the other hand, if RunStep's module 964 shows that the number of lines it has just read does not match the number of lines it is expecting, RunStep proceeds to the routine shown in FIG. 12. The first module 972 checks whether RunStep has actually reached the last line of the step subfile for the last phase. In this case, a message is returned indicating that all testing is complete. Otherwise, module 974 checks whether the last line in a step subfile has been reached. In this case RunStep returns to module 956 and opens the step subfile for the next phase of testing.

On the other hand, if RunStep determines that it is not at the end of the step subfile, it checks in module 976 whether or not the number of lines it has just read exceeds the line it is expecting (from reading memory). If the line number is exceeded, RunStep indicates that the step subfile has been tampered with manually (ie, an operator has removed a step from the step subfile) and RunStep returns a failure. If the number of lines is not exceeded, RunStep returns to module 962 .

RunStep then returns to module 990 , cf. Fig. 8, and reports to the operator when the end of the step subfile has been reached. RunStep also checks whether or not a failure in module 992 has been returned. In this case, it is reported and RunStep is exited.

At this point, RunStep has determined the exact status of the system. It knows whether or not it is repeating a step, rewinding a phase, or executing the next line in the step subfile and has prepared the memory accordingly. Before proceeding, RunStep stores all the information it has learned in the previous stages. This is done in module 994 , which is shown in more detail in FIG .

First, the module 1000 takes the opportunity to clean up all files that are no longer needed. The module 1002 then determines whether or not files that are required for testing or the software installation that are to take place are stored on the local drive or must be obtained via a network and stores this information. Next, in modules 1004 , 1006 , RunStep uses the information it learned in the previous stages to set the environment variables (in progress.bat) so that the next time RunStep is run from the beginning, all environment variables have been updated to reflect the current state of the system.

After it has checked in module 1008 that the writing was successful, RunStep then writes a log file in module 1010 . If successful, module 1012 , the need for retry is determined in module 1014 and, if necessary, creates a retry file in module 1016 .

The controller is then sent to module 1020 , cf. Fig. 8, passed, and if no failure has been returned, the program exits with a 255 error level indicating that execution of the command line read from the step subfile should take place in module 966 . This happens in module 1022 . RunStep then returns to the beginning to process the next step (line in the step subfile).

It can be seen that the RunStep program is a high security system by it contains various checks to prevent one from not Authorized operator falsifies the step subfile to perform tedious tests bypass or prevent repetition. This is achieved through the Overriding the control interruption, checking the line numbers of the Step subfile in different places; and adding Checksums in the system. Another security aspect is that when a failure always occurs, as determined by RunStep at numerous points of the flowchart above, RunStep is exited and the failure in one hidden, read-only file is being written; becomes a volatile operator cannot perceive this file and may not be able to find it not trying to figure out what went wrong and how the workaround was circumvented  can be d. H. he would be forced to reject the component or the Run the test again until it is successful.

Although illustrative embodiments have been shown and described, FIG a wide range of modifications, changes and replacements in the previous revelation is possible and in some cases some may Features of the embodiments are used without the corresponding Use of other characteristics. Accordingly, it is appropriate that the subsequent claims are broadly constructed and in a way that with the The range of embodiments disclosed here is consistent.

Claims (20)

1. A method for installing software and / or testing a computer system, comprising:
Reading a plurality of component descriptors from a computer readable file, each component descriptor describing a corresponding component of the computer system;
Reading a plurality of steps from a database, each step associated with a component descriptor and comprising a corresponding sequence number;
Ordering the plurality of steps in a predetermined order according to the sequence numbers to create a step sequence with commands for installing software and / or testing the computer system;
Determine for each step that is read from the database from data associated with that step from the database whether this step is incompatible with the presence of a component other than that corresponding to the component descriptor associated with the step in the computer system ; and in this case discarding the step or not discarding it according to the further data associated with this step in the database. 2. The method of claim 1, wherein the computer system is one belongs to certain family of computer systems and being the step of reading the plurality of steps, the steps of connecting one first database table that contains all the components related to the belonging to a certain family, with a second database table included, which contains all software installation and / or test steps that are carried out on the Large number of components are to be executed, the Connection creates an intermediate set, and connecting the Intermediate set with a third database table, which all software Includes installation and / or test steps based on the particular family are to be carried out, the connection of the said plurality of Steps. 3. The method according to claim 2, wherein an error condition is set, when the intermediate quantity is empty. 4. The method according to claim 1, wherein at least one corresponding Component is a hardware component. 5. The method of claim 1, wherein at least one component Software component is. 6. The method of claim 1, further comprising the step of generating a variety of derived objects that match the variety of Component descriptors match.   7. The method of claim 1, further comprising the step of Prepare an environment variable corresponding to the variety of Components. 8. The method of claim 1, further comprising the step of writing the sequence of steps on a non-volatile storage medium, the is configured to the computer system during manufacture accompany. 9. The method according to claim 1, wherein the step sequence is suitable Provide commands that are repeated for a period of time can be. 10. The method according to claim 1, wherein the step sequence is suitable Provide commands for a certain number of Repetitions can be repeated. 11. A method of installing software and / or testing a computer system comprising:
Reading a plurality of component descriptors from a computer readable file, each component descriptor describing a corresponding component of the computer system;
Reading a plurality of steps from a database, each step associated with a component descriptor and comprising a corresponding sequence number;
Ordering the plurality of steps in a predetermined order according to the order numbers to create a step order with commands for installing the software and / or testing the computer system;
Determining for each step that has been read from the database from data associated with this step from the database whether this step requires a parameter; and if so, calculate this parameter based on other data associated with this step in the database. 12. The method of claim 11, wherein the computer system is one belongs to certain family of computer systems and being the step reading the plurality of steps, the step of connecting one includes the first database table that contains all components that belong to the certain family belong to a second database table, all Includes software installation and / or test steps based on the variety of components to be executed, the connecting one Generates intermediate set and connects the intermediate set with a third database table, all software installation and / or Contains test steps that are run on the particular family are intended, the connection generating the said plurality of steps. 13. The method according to claim 12, wherein an error condition is set, when the intermediate quantity is empty. 14. The method according to claim 11, wherein at least one corresponding Component is a hardware component. 15. The method according to claim 11, wherein at least one component is a Software component is.   16. The method of claim 11, further comprising the step of generating a variety of derived objects that match the variety of Component descriptors match. 17. The method of claim 11, further comprising the step of Prepare an environment variable corresponding to the variety of Components. 18. The method of claim 11, further comprising the step of Writing the sequence of steps to a non-volatile storage medium, that is configured to control the computer system during manufacture accompany. 19. The method according to claim 11, wherein the step sequence is suitable Provide commands that are repeated for a period of time can be. 20. The method according to claim 11, wherein the step sequence is suitable Provide commands for a certain number of iterations can be repeated.