Browse Prior Art Database

Configuration State Data Disclosure Number: IPCOM000125965D
Original Publication Date: 2005-Jun-26
Included in the Prior Art Database: 2005-Jun-26
Document File: 5 page(s) / 309K

Publishing Venue



Engine and model technologies are separated from how potential orders are stored in the configuration space.

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 44% of the total text.

Page 1 of 5

Configuration State Data

The Configuration State Data (CSD) is a platform independent specification for storing configurations that are not tied to a specific rules processing engine. The definition for the CSD is contained in an XML schema.

Historically, potential orders or configurations created by users were represented in formats that are tied specifically to the technology used in the rules processing engine. From these proprietary structures, they were converted numerous times to pipe or application specific formats. This caused the following problems to arise:

Each time the document is converted; information about what the user had selected is lost.

Some standard formats (not based on XML) are rigid in nature. Modifications to the record layouts and passing addition information are problematic at best. A number of applications have resorted to passing information on comment records to send information along.

Current existing structures for storing configurations or representing them are flat or fixed depth. While this works fine for simple, single system orders, it fails in nested or clustered environment orders. In these configurations, you have the concept of machines within machines. Again, hacks to the current structures and sub-optimal product announcements (i.e. announcing part number to represent rack and drawer locations) further complicate the matter.

When a company moves from one configurator engine platform to another, configurations created in previous versions, or work in progress (WIP) files, do not migrate to the new technology.

Only when configurations are exported to a Sales Bill of Materials (SBOM, flat partnumber lists) format, can they be restored into the new configurator. Due to limitations with these formats as stated above, data is lost in the migration process. Due to the transferring of order details from application to application, product validation rules can change without the new rules being applied. If problem is found in a specific configuration of parts, those rules can be added to the configurator. The predicament comes into play on orders generated with the old rules. There is a gap of old orders that will fail or have to be rejected in manufacturing.

To negate these problems and support the future expansion, a new standardized configuration storage mechanism is defined, Configuration State Data (CSD). This is an XML based, technology neutral format that contains the definition of the state of the configured product(s) and their relationships.

The main features in the CSD that fulfill the above mentioned deficiencies are the following:

Recursive structure of nodes tied to the physical product constructs Generic extensions to the nodes above to contain configurator technology specific information
Configuration Identification number for storage in a centralized repository.

Using the CSD format, all other formats (SBOM, RosettaNet, proprietary order


Page 2 of 5

fulfillment specifications ......