ECLASS-Update

Every new ECLASS version may feature different kind of extensions and changes to the standard:

• Structure (ECLASS structure is divided into different segments)
• Classes
• Properties
• Values

This document describes the information how to update an ECLASS classified and property described material master to a new version. In general there are two procedures possible:

• only classification update (without property description)
• classification and property description update (including product properties, that are based on ECLASS)

ECLASS provides four supporting files to accomplish this goal. The following chapters will describe every procedure in detail, as there are:

• CUF (Classification Update File)
• RUF (Release Update File)
• SDF (Structure Difference File)
• TUF (Transaction Update File)

Every supporting system consists of a data structure that supports the user to update ECLASS classified and feature described material masters in a more or less automatically way. The basis for this work is also the use of the ECLASS releases, which means the old and new version of ECLASS.

The supporting systems are not tools to update ECLASS classified and feature described material masters from one version to another. The supporting systems are the basis to implement such a tool. In addition every update process demands additional user interaction, where different decision questions have to be answered.

CUF stands for „Classification Update File“.

Schema: Classification Update File
 

The main purpose of the Classification Update File (CUF) is to update classification relations for already classified products, if the classification structure has changed. This can be done by semi-automated upgrade process that uses TUF from a previous ECLASS release to a later ECLASS release (BASIC and ADVANCED versions, XML). TUF contains the results of the changes to the classification by MOVE, SPLIT and JOIN operations, but it does not contain information about new and deleted classes.

• MOVE - a class will be moved to an new location in the classification tree
• JOIN - multiple classes will be joined together into a new target class
• SPLIT - a class will be split into multiple new classes

NOTE: The activities ‘move’ and ‘join’ will be automatically applied to already classified material masters. The activity ‘split’ usually needs human decision making to determine within which new class the articles will be placed.
 

The following information will be not provided, because it can be determined by comparing the previous with the follow up ECLASS release:

• list of new classes - which classes were added in the new release (the use of new classes in the context of the update process has to be operated manually)
• list of deleted classes - which classes will be not available anymore in the new release (in this case the CUF holds a reference to another class the articles must be admitted to)

A detailed description is to be found under ECLASS Classification Update File.

RUF stands for „Release Update File“.

The Release Update Files (RUF) contain the information on what has changed in one major release compared to the one before. It is a “human readable” collection of CSV files and is only relevant for the basic release. RUF differs between classification and transaction updates. Changes are documented for classes, properties, and all other ECLASS elements regarding modifications, additions and deletions (MOVE, SPLIT, JOIN). RUF only contains modified elements.

A detailed description is to be found under Release Update File (RUF).

SDF stands for “Structure Difference File”.

Schema: Structure Difference File
 

The main purpose of Structure Difference Files (SDF) is to update from one ECLASS release to its subsequent release, if these cannot be kept parallel for technical or business reasons. If dictionary releases are kept in parallel the SDF become obsolete. SDF is an XML genericode list for Basic and Advanced of all those identifiers that were changed in a certain dictionary release. SDF shows all elements that have changed or have been added on element level (like class, property, value, etc.), information on the relations is not included.

A detailed description is to be found under ECLASS Structure Difference File.

TUF stands for „Transaction Update File“.

Schema: Transaction Update File
 

The Transaction Update File (TUF) contains all information that is needed for a semi-automatically upgrade of valuated productive data. This can be transactional data or a catalogue file (e.g. a BMEcat file) with ECLASS data (class/property/value/unit) that shall be transferred from an encoding with a previous ECLASS Release to an encoding with a subsequent ECLASS major release.

NOTE: If the subsequent release for an ECLASS upgrade is a minor release, than only version upgrade apply. In all cases the Reference algorithm shall be applied.
 

The TUF is available for ECLASS Basic and Advanced in two different XML files. It includes only information that cannot be obtained by the direct comparison of subsequent structure data releases.

NOTE: ECLASS works on a new edition of TUF, which will be described later.

A detailed description is to be found under ECLASS Transaction Update File.

• ECLASS XML

• PROLIST XML (Hd)

• how to update ECLASS catalogs
• how to update the PROLIST workflow to ECLASS

• The reference algorithm describes how an application can implement a conversion of transaction data, views, and mappings and how the information in the Transaction Update File (TUF) shall be used.

• The reference algorithm is not an executable program. It is like the blueprint for a conversion routine.

• For technical details see Reference algorithm

• support starts with ECLASS 5.1.1
• PROLIST NE 100 3.2 (target system is ECLASS 8.0)
• how to transfer other classification systems

• support starts with ECLASS 5.1.1
• (ECLASS 4.x is not supported)

The basis for a successful transition to a follow up ECLASS release will be an evaluated material master, which contains ECLASS classified articles that are described by existing ECLASS properties. Update a only classified material master is a part of the process that is described here.

Such a material master is either available as a property based article database that needs an update to a follow up ECLASS release. Or it is available as an electronic catalog, maybe as a BMEcat, that contains all mentioned information above. For a successful update not only the supporting systems mentioned above are needed, also the two ECLASS releases are necessary, as this is the only way a mapping of the appliances to the article data is possible.

The update process works on article basis, so one article at a time. In the first step the process checks the classification, then the features, and so on. The process is displayed in the following diagram.

In consideration of the use of value lists there has to be a manual check for deprecated values how another or new value can substitute the deprecated one. On the other hand it is possible according to circumstances of the use case to mark the deprecated value as a non-suggested value. ECLASS defines those values normally as suggested values, so it’s possible to commit additional values as plain text (without ID).

• description and example

• description and example

• description and example

• description and example

• description and example

• Usually not only transaction data but also views (PROLIST NE 100), Templates (ECLASS) and mappings (application specific) have to be converted.

• To convert views, the reference algorithm for transaction data can be used almost unchanged.
• The essential difference is, that instead of values ​​and units in this case visibilities etc. are transferred

• Conversion of mappings is more application specific, because mappings link information from e.g. a database of an I&C-CAE-System to properties in ECLASS.
• Also in this case the reference algorithmis a good starting point.

• value in in new release no longer available
• data type change
• new values
• unit change
• <actual only examples, must be discussed>

• compatible / incompatible

ECLASS Change Management Rules

The ECLASS Change Management Rules are transaction data centric and aim at being as simple as possible to maintain and apply.

This means that the decision criterion for assigning revisions / versions / identifiers for structure elements is how the change impacts existing product descriptions (i.e. catalog or transaction data) such that:

• A structure data change which is from product descriptions perspective upward and backward compatible implies assigning a revision. For ECLASS 7 the new released elements got a version, even if a revision would have been sufficient to provide a stable basis.

• A structure data change which is product descriptions perspective upward compatible, implies assigning a version. Existing catalogs may trust that all values remain valid or can be corrected using the Transaction Update File (TUF) . The transaction update file contains all information necessary to move or convert values appropriately such that the transaction data remains valid under the new structure data release.

• A structure data change which is product descriptions perspective not compatible and which is potentially requiring human interaction to update transaction data implies assigning a new identifier.

• Description of the XML schemas:
  • Transaction Update File
  • Structure Difference File
  • Classification Update File

• ECLASS XML

• Products