It is said that data is the raw material of the 21st century. Alternatively, it is referred to as the gold of the digital age. In order to utilize the raw material or gold, the so-called artificial intelligence (AI) of machine learning obtains the required process data directly from the machines and systems in operation. However, data on the components to be installed in the application is required in the engineering phase. This information can already be found on the engineering tool manufacturers' portals - but only in the form required for the respective software tool. A general, cross-domain provision in standardized data formats would be better.

In addition to the familiar engineering environments, configurators also require article data so that they can combine several individual articles into a complete product. In doing so, the configurators take on a level of complexity that is familiar from engineering tools.

Nevertheless, they only include the article data that they need for their often very specific task. Saved configuration objects can therefore only be used for the intended tasks or can be imported into other tools via specialized interfaces.

Control of the level of detail via access rights

Currently, there are already cross-domain description formats such as AutomationML and eCl@ss Advanced, which can even be combined with each other. One example is the terminal strip configurator Clip Project from Phoenix Contact, which can be used to configure assembled mounting rails. The tool also allows data to be exchanged with engineering tools via interfaces. However, Clip Project also only stores the article data that is absolutely necessary for the configuration task and the exchange with other engineering environments. This includes the article number, width of the terminal block or number of electrical connections.

Theoretically, the configuration result is a model of the product, which should also be usable for other tasks such as automated labeling or wiring. However, the relevant information on the labeling and wiring positions is missing. It would therefore be conceivable to enter this data into the article knowledge of the configuration tool. However, this would add an additional application domain. Complete data records, such as those available in the manufacturer's master data system, would in turn unnecessarily bloat the configuration tool. An alternative to this scenario is the subsequent enrichment of article information using a web service, where the level of detail can even be controlled via access rights.

To make the result of a configuration tool applicable for a continuous engineering chain, the direct export of the configuration result to AutomationML is a good option. Alternatively, an existing export could be translated into AutomationML. Using the Clip Project terminal strip configurator as an example, it is initially sufficient to describe the items used with their article number and relative position to each other. These are, for example, the mounting rail, terminal blocks and end clamps as well as the label plates.

The first challenge now is to identify suitable system unit or role classes in AutomationML. In the best, but also very unlikely case, an eCl@ss-based system unit class library is available for this purpose, which can be read like a product catalog. However, as this is not normally the case, the use of placeholder role classes with just two attributes is sufficient in the first step: Article number and manufacturer name. In the instance hierarchy, which describes the structure of the equipped mounting rail, there are then only hierarchically organized elements of the placeholder castor class with additional position information.