Browse Prior Art Database

Automated Configure To Order Back End Configuration Test Case Generation and Verification Disclosure Number: IPCOM000126479D
Original Publication Date: 2005-Jul-20
Included in the Prior Art Database: 2005-Jul-20
Document File: 5 page(s) / 135K

Publishing Venue



When ordering a computer, a customer will select specific components such as hard drives, CD-ROM drives, PCI devices (example: video cards, fiber channel adaptors, RAID controllers) as well as the desired RAID configurations. This customization of a system to a customer’s specific requirements is called CTO (Configure to Order). Previously only 3-5 configurations of the possible hundreds were checked. Since there are so many possible configurations, a customer could order a configuration that would cause the ordering system to fail during generation of the data needed to assemble the computer or generate the data incorrectly. This would cause a delay in shipment and sometimes a revision of supported configurations which can be ordered by customers. The two problems I had to solve were how to create a large number of configurations and how to verify the resulting configurations from the Order Configuration System. Comparing a known good configuration to a new configuration would come later, after all the development was done. Several groups are working in parallel to prepare a system for ship support and testing at the end would cause more delays. In the beginning the resulting configuration from the Order Configuration System will evolve as requirements are changed or added. The development of the data used by the Order Configuration System evolves as well. This causes the resulting configuration from the system to change. Thus, a way to check hundreds of system configurations in the earlier stages of development was needed.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 30% of the total text.

Page 1 of 5

Automated Configure To Order Back End Configuration Test Case Generation and Verification

    The configuration data sent to the configuration system is called a BOM or Bill Of Material. The resulting configuration from the Order Configuration System is called an AOD or Additional Order Data.

BOM Configuration System AOD

    A BOM is processed by the configuration system and the configuration system processes that data and makes an AOD

    Prior to my invention, generation of the BOM was done manually. There was data available to create a BOM stored in a database, but prior to my invention there wasn't an easy way to format the data to be sent to the Configuration System. There are so many configurations and restrictions on the different possible combinations that it is impossible for a human to effectively deal with all this complexity.

    In order to verify that the AOD file was generated correctly required manually looking at the AOD scrolling back and forth in order to verify the connections of CPUs, memory, PCI devices, hard drives, tape drives, and any other device in the CTO.

    It can be very expensive when a mistake occurs in manufacturing (orders held up for days, engineering changes to allowable configuration, updating of website to handle new configuration restrictions, etc). This makes having an easy way to generate a proper test configuration (BOM) a very valuable asset.

    This invention is a comprised of two parts which can be used by companies to test orders derived from various sources of input and automates the verification of the output from the Order Configuration System.

    The first part is a tool which generates BOMs from various sources such as a spreadsheet, a database or data from the website where customers would go to place the order. The data is converted into a BOM file format which can be processed by the Order Configuration System to create the AOD file. Once they are done, they are retrieved automatically. The data retrieved from the Order Configuration System is the AOD. The data contained within the AOD is required by the floor control system in manufacturing of the system as well as testing the system to verify the system is operating, and assembled properly.

    The second partis a tool which verifies the correctness and accuracy of the AOD generated. Upon initialization of the tool, the integrity of the AOD file is verified. This checks to make sure that all devices are connected. Once the AOD is loaded, it is then possible to supply a program written in a programming language for the built-in interpreter which can check the connections between devices. This program describes how the AOD must be built. When an AOD doesn't follow the description presented in the program, the tool generates data showing where the AOD is invalid. In addition to the built-in programming language, summaries are generated showing how devices are connected based on the data contained within the AOD. This data serves as a debugging tool for the...