Implementation Guide

From wiki.eclass.eu
Jump to: navigation, search
This article in other languages
Deutsch
English




                                                      IG1.jpg
The eCl@ss 7.0
Manual
IG2.jpg
Contents

Introduction

Changes often happen overnight!

For approximately 14 years now, eCl@ss has been the established international standard for the industry, trade, craft, food industry, services many other sectors. To many people, use of this 4-tier class structure to describe and exchange products between business partners has meanwhile become a daily process.

The new eCl@ss 7.0 release now offers even more users the opportunity to optimise their processes. Not only does it provide new contents but compared to previous releases, also introduces a genuine paradigm shift.

eCl@ss radically changed the ways in which people communicate. eCl@ss 7.0 meets future data exchange requirements between business partners.

By integrating the most important trade standards such as PROLIST, ETIM, proficl@ss, bau:Cl@ss, IMPT, EDMA, eCALS, and CECED, eCl@ss 7.0 is basically suitable to meet any inter-agency requirements with regard to complex data exchanges.

The BME (Federal German Association for Materials Science, Procurement, and Logistics) developed its BMEcat standard for catalog data exchange together with eCl@ss e.V. ensuring optimal support of eCl@ss 7.0.

Another important step towards worldwide acceptance is the continuous support of multilingual structures. eCl@ss, with its trade specific linguistic terminology variations will significantly improve flexibility on the one hand and professional accuracy on the other. The result is that all users will virtually be able to implement an unobstructed data exchange.

Our Implementation Guide intends offering you an initial impression of the new features available when using eCl@ss 7.0


Contents

[edit] eCl@ss 7.0 General

[edit] Basic Representation

eCl@ss 7.0 Basic Representation presents a version variant with all essential new contents in the usual format. Consequently, no users are restricted in any way when processing the advanced contents in a CSV format. In addition, the basic version is downloadable as an XML variant.

The new structural elements described under point 2 are not part of the basic version. A reference list with the structural elements of the Advanced Representation, maps the attributes contained in the basic version.

[edit] Advanced Representation

By introducing eCl@ss 7.0 Advanced Representations, the eCl@ss-Association offers an ISO conformant data structure. The data structure contains the structural elements described under point 2. The result is the following structural arrangement:

IG3 en.JPG

The 4-tier class structure is associated with the new application class (AC). This, in turn, contains all relevant structural elements such as blocks and aspects.

Integration of both the PROLIST standard and CAx elements results in additional important data model extensions. Using “Cardinality" multiplication elements (refer to 2.3) as well as variant access of special blocks by means of “Polymorphism” (refer to point 2.4) results in significant simplification.

Implementation of additional data type extensions (Level type and Axis type) results in further simplifications. Consequently, a single data type combines physical-technical links originating from various attributes.

It should therefore be possible to transfer the complex data model in a data structure configured for that purpose. That is why eClass 7.0 uses ontoML rules defined in ISO 13584 – part 32.

These rules describe the form and arrangement of the structural elements and predefine how to interpret the ontoML in order to be able to process eCl@ss 7.0 Advanced Representation from a data-technical point of view.

[edit] Export formats

Following the release of eCl@ss 7.0, the eCl@ss standard is available in two different export formats. Internationalisation required amendments of ISO standards. Significant amendments involved both a distinction between ISO-standard conformant “closed” value lists and “open” proposal lists and the introduction of standard compliant measurement units.

[edit] CSV (only Basic Representation)

The usual CSV export format of the eCl@ss-standard includes eight CSV files, which Office programs such as MS-Excel and MS-Access can process and implement. The attached ReadMe file describes the amendments, structure, contents, and associations of the CSV files.

[edit] eCl@ssXML (Basic and Advanced Representation)

With effect from eCl@ss 7.0, it will also be available as an additional export format in eCl@ssXML format for automatic eCl@ss-standard processing. This export format bases on an ISO-standardised XML format for product data exchange. Related specifications are published in ISO 13584-32:2010 (ontoML) . These specifications offer a uniform and comparable data structure for communications between machines. Consequently, two export formats are available for processing and implementing Basic Representation. Export of Advanced Representation is only available in eCl@ssXML-format.

[edit] Functionality matrix

The following matrix provides a functionality overview of both the basic and Advanced Representations.

Characteristic
eClass 7.0 Basic
eClass 7.0 Advandced
Basic functionalities
Hierarchic class structure
×
×
IRDI as unique identifier of structural elements
×
×
Keywords at class level
×
×
One-dimensional property lists for goods/product description
×
-
Two-dimensional property lists for a structured goods/product description
-
×
Possibility to use value lists
×
×
Possibility to use value suggestions
×
×
Properties have a standardised structure
×
×
Use of aspects
×
Use of property blocks
×
Use of dependent properties
×
Format display for Integer/Real optional
x
x
List of alternative units
 
×
Units are DIN conformant
×
×
Dynamic functionalities
 
 
Polymorphism
-
×
Cardinality
-
×
Data types
 
 
Integer Count
×
×
Real Count
×
×
Integer Measure
×
×
Real Measure
×
×
String translatable
×
×
String non translatable
×
×
Boolean
×
×
Timestamp
×
×
Time
×
×
Currency
×
×
Level type
×
Axis type
×
Download
 
 
CSV
×
eCl@ssXML
×
×
Update support
 
 
Transaction Update Files (TUF)
×
Release Update File (RUF)
×
×
Languages
 
 
German
×
×
English
×
×
Content
 
 
3 new segments
×
×
Harmonised contents of ETIM 4.0
×
×
Harmonised contents of Proficl@ss 4.0
×
×
Harmonised contents of PROLIST NE100 3.2
×
Harmonised contents of Ecals
×
×
Complete re-structure of segment 34 medical technology
×
×

[edit] Selection suggestion

[edit] New structural elements of Advanced Representation

[edit] Block

A block is defined as the total of various attributes under a single name.

For detailed descriptions of devices with classes, a structure like this is extremely helpful.

Using a car as an example, the block “wheel” would contain all attributes to describe the wheel: Rim diameter, tyre size etc. Another block would then describe the “axle” properties. In addition, apart from attributes, a block can also contain additional sub-blocks with attributes and more blocks: In this example the “wheel“ block is subdivided into “rim” and “tyre”.

In order to create a block, a so-called reference property has to be created in the Advanced Representation.

see more under Block

[edit] Aspect

An aspect, is a special block variant that cannot be represented by cardinality or polymorphism (refer to sections 0 and 2.3) and is located in the top level of a class. The advantage of an aspect as opposed to a block is the aspect’s universal use in a random number of classes without being a direct part of a class. Consequently, it is not subject to any product specific restrictions.

An aspect, therefore, does not describe the product specific property itself (like ordinary blocks and class attributes), but it includes attributes for that class under certain conditions or additional attributes for a class under certain view points.

For instance, our “car” example might have a “manufacturer” aspect. This aspect includes attributes such as manufacturer’s name, manufacturer’s article number, model description etc. These attributes depend directly on the manufacturer and are not subject to any product specific restrictions.

Another example is the aspect “Operating conditions”. It describes under which conditions the car is to be operated: Central Europe, the Arctic or desert. The resulting properties, however, such as minimum starting temperature or operational altitude are attributes of the “car” class and aspect elements!

IG4 en.JPG

[edit] Cardinality

For structuring class attributes one can also use, apart from blocks, so-called cardinality. “Cardinality” refers to the property allowing dynamic multiplication of a block within the scope of the property values to be managed.

In the case of our “car” example, one could use cardinality to describe the doors. For instance, the attributes colour, door type, and electric window levers describe the doors. A „door attributes“ block combines these attributes, which can be assessed at random using the reference property “number of doors”. When we wish to describe a 3-door vehicle, we will have to click on “3” on the reference property “number of doors”. As a result, the “door attributes” block is accessed 3 times.

The attributes are entered as follows:


Cardinality.png


Within the contents of data description, cardinality is therefore a means to determine the number of identical blocks.


[edit] Polymorphism

Polymorphism implies that the block content (section 2.1) is not assigned within a class but that only after an allocation of values to the attributes it is dynamically decided, which block content is actually required (only at this stage it is determined, data-technically, which block is to be selected from a number of blocks).

In the case of our “car” example, one could use polymorphism to describe the type of doors. The driver’s door attributes differ compared to the hatch attributes. For instance, the driver’s door could have the attributes, electric window lever, automatic lock, loudspeakers etc., whereas the hatch door would sooner have attributes such as windscreen wipers available, rear heated windscreen etc.

IG6 en.JPG

In the “wheel” example of the “car” class, you will find that the attributes for a wheel with double tyres will be quite different from a wheel with single tyres. Therefore, if values are to be allocated to a “wheel” block one will first have to decide which type of wheel is to be described: Single tyre or double tyre. Following the decision for “double tyres”, the block “wheel with double tyres” is accessed and related attributes made available (Data-technically, the block “wheel” is replaced by a specialisation “wheel with double tyres”).

The properties of this multiple (“poly”) substitutability (“morphism”) resulting from this special variant are therefore used to describe various details of a product structure keeping the number of total attributes manageable and free of redundancies.

[edit] Units

Each unit-associated property may express values (numbers) with regard to its basic unit and dosage unit.

Consequently, attributes are used quite universally and do not require multiple definitions should the scale of data volumes differ considerably. In addition, common usage units can be used.

One example is the pressure range, varying from Pa (overpressure in compartments) to mbar or hPa (air pressure) to bar (Pressure in tyres and technical installations) involving six different scales. Moreover, Anglo-American regions still use the psi unit.

Convertibility of figures to various units is a prerequisite for using different units for an attribute. An attribute cannot have the unit kg/m³ (density) and kg/m² (surface density).


[edit] New data types

New data types such as Time, Date, Timestamp, and URL were introduced ensuring a high quality data exchange.

Level-Type, specifies common technological values such as minimal, maximal, nominal and typical. The Axis-Type specifies location references within a system of coordinates.

[edit] Release – Update - Support

By means of eCl@ss 7.0, eCl@ss e.V. supports standard users with additional information making it possible to update from eCl@ss Release to Release more or less automatically. The result, a significant saving in data processing costs. Updating from 6.2 to 7.0 will make this possible for the first time.

Below please find a description of the Release-Update-Files and Transaction-Update-Files made available by eCl@ss:


[edit] RUF (w.e.f. 6.2 to 7.0)

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 eCl@ss elements regarding modifications, additions and deletions (MOVE, SPLIT, JOIN). RUF only contains modified elements.

[edit] TUF (w.e.f. 6.2 to 7.0)

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 eCl@ss data (class/property/value/unit) that must be transferred from a previous eCl@ss major release to a later eCl@ss major release. TUF is available for eCl@ss 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.

[edit] Implementation time and effort

A global indication of the time and effort involved in implementing eCl@ss cannot be given. It is dependent on many factors that can be different for each user. These include, for instance, the available master data quality, the product volume (for catalogs, procurement, or sales), product complexity, number of language versions etc. In addition, the possibilities of the ERP-system used are as important as the basic goal of eCl@ss implementation. The deeper eCl@ss’ integration into internal or cross-company processes, the bigger the required effort, but also the expected Return on Investment (ROI). If required, you can use eCl@ss-experienced IT service providers, whose addresses are available through info@eclass.eu.

[edit] eCl@ss export format CSV (Basic Representation)

Implementation of the eCl@ss – export format CSV (Basic) is easy and requires relatively little effort. Office programs can open, filter, copy relevant content of the CSV files, and convert them to formats best suitable for processing by following IT-systems. The attached ReadMe file describes the contents and relations.

[edit] eCl@ss export format eCl@ssXML (Basic Representation)

Implementation of eCl@ss – export format eCl@ssXML Basic is likely to require more time and effort. On the other hand, investment security and having chosen and realised an implementation route that is internationally conformant and allowing a later change-over to the Advanced Representation, makes life easier.

eCl@ss will provide a free viewer to display and control data in eCl@ssXML format.

[edit] eCl@ss export format eCl@ssXML (Advanced Representation)

The increased implementation efforts of the Advanced Representation are, depending on corresponding application scenarios, offset by an expected higher Return on Investment (ROI).

eCl@ss will provide a free viewer to display and control data in eCl@ssXML format.


[edit] Additional support

[edit] FAQ

[edit] eCl@ss – User - Community

Regular online meetings and webinars

  • Exchange of user experiences
  • Professional knowledge provided by consultant to user

Ask us when you have any questions

[edit] eCl@ss – Viewer (Advanced)

[edit] Related literature

[edit] Typical use cases

[edit] Engineering – Tools

Apart from classic E-Procedure processes, eCl@ss 7.0 is becoming more and more important for process integration into electronic planning processes because it also allows transfer of E-CAD planning data from the manufacturer to the customer.

Nowadays, companies wishing to make planning data available for ECAD systems have to use numerous target formats. Something, which is costing companies a considerable investment in resources. eCl@ss 7.0 provides a data model that simplifies transfer of planning data and subsequently accelerates planning processes.

Example: The industrial enterprise “ABC LTD” provides its customers with product information and planning data. At ABC LTD, two people are working on preparing data for E-CAD system 1, E-CAD system 2, E-CAD system 3, and E-CAD system 4 because each planning system has quite different requirements. By introducing eCl@ss 7.0, ABC LTD provides its software partners with only a single electronic catalog in BMEcat format, which contains both product information and planning information for the E-CAD-systems. A single person can now create this catalog at ABC LTD.

A prerequisite for making product information available for the various business processes is implementation of the eCl@ss data model in the user's management system for product information.


[edit] Master data management (ERP)

Depicting internal processes in manufacturing companies showing competency allocation and related reporting, requires a classification of one’s own product spectrum. Depicting distribution processes of these companies also requires portfolio structuring towards the customer. Procurement, production, and distribution processes are becoming increasingly intertwined, viewed from a SCM (Supply Chain Management) perspective. Therefore, use of a cross-industry standard offers a basis for data exchange between the areas involved.


[edit] Category management

eCl@ss product classification allows companies to include their products and services in a standardised category structure, easily and efficiently. It can be used for the organisation of procurement processes as well as in-house reporting.

The advantages:

  • eCl@ss covers a broad range of procurement subjects for both manufacturing and trade.
  • Nowadays, many suppliers can already make eCl@ss-classified product data available – additional in-house classification is no longer required reducing processes and increasing procurement efficiency at the same time.
  • On top of that, eCl@ss is available in several languages and can therefore be used internationally.


[edit] Product data for eProcurement and PIM systems

eCl@ss 7.0, being the descriptive standard, allows efficient linking of e-Procurement processes beyond the boundaries of individual companies: under ideal circumstances the manufacturer, to be precise, classifies each product or service only once. Any other participant in the process then uses the classified data. Procurement as well as master and product data management benefit in particular because investment in classification and data maintenance can be minimised.

[edit] Marketplaces

Marketplaces offer the user an advantage because it allows them to compare many suppliers and their respective product portfolios. If a proper overview of manufacturers and their own product structures is insufficient, then an overall structure is required whereby manufacturers have to categorise their products in order to be of any service to the user.

For such purposes, eCl@ss and its version 7.0 in particular, provide an excellent basis because it not only allows a hierarchic product search but also product selection using the attributes. Use of eCl@ss 7.0 Advanced Representation also gives users the opportunity to make relevant engineering data immediately available.

[edit] (Public) Procurement

Using eCl@ss 7.0, procurement organisations can easily conclude tender-based framework contracts with their suppliers. Procurement operators draw up specifications based on eCl@ss 7.0 in respect of products to be purchased and submit these to their suppliers so they can put in a bid.

Requirements

  • regarding products are taken from (reference) details based on attributes laid down in eCl@ss 7.0,
  • regarding description details of catalog products and services are laid down in “templates”.

In turn, suppliers manage their product information based on industrial standards regardless of the applying procurement organisation and integrate the product information of their sub-suppliers. Avoiding different product description standards increases data quality and data security.

Example:


Procurement operator ABC defines a partial eCl@ss segment relevant to the actual procurement e.g. laptops.

The procurement operator, using segment details, defines the “laptop” requirements, for example hard disk capacity > 500 GB.

Procurement organisation ABC defines the descriptive details required from the expected catalogs i.e. the attributes (and proposal values) which the supplier is obliged to provide, for instance manufacturer, manufacturer's article number, CPU-type, guarantee period.

Procurement organisation ABC distributes its segment details, covering the requirements and requested descriptive details expected from the catalogs, to its suppliers.

Supplier XYZ creates a BMEcat for his products together with the required descriptive details and enters his product data in the catalog. To make sure everything is correct, the supplier checks the BMEcat to see whether:

  • the data are correctly coded in accordance with eCl@ss,
  • the data requirements of the corresponding catalog included in the templates and
  • the article requirements are met.

Using this catalog, the supplier offers his products to procurement organisation ABC enclosing the catalog at the same time.

Procurement organisation ABC carries out its commercial selection and downloads the catalog on its IT-system to ensure product access under the agreed conditions.

[edit] eCl@ss as an in-house data model

eCl@ss 7.0 can assist in optimising in-house data management. Many companies find that providing product information is becoming more and more complex. Apart from the ever-increasing complexity of data processing, demands placed on master data management are growing continuously. Systems have to be able to save master and product data in such a way that they can serve virtually any publication channel. Company officials responsible for the products are often not aware of which product properties to describe in order to cover any business event. In such cases, eCl@ss 7.0 would also be an obvious choice when looking for an in-house data model to describe products.


[edit] Catalog data exchange (e.g. BMEcat)

A uniform catalog data exchange format is a prerequisite for standardised master and product data exchanges. This is where the BMEcat-format comes into it. BMEcat is able to display eCl@ss 7.0 in full; it allows description of classified products, which can then be transferred to a business partner in the form of a complete catalog.

Personal tools