At the end of November 2016, the ZVEI published a guide entitled 'What criteria must Industry 4.0 products meet? It shows which requirements Industry 4.0-compatible products should or must fulfill. The ZVEI guideline distinguishes between three different time horizons:

1. Product features 2017: everything that an automation product should already offer in 2017 in order to be suitable for Industry 4.0 applications.
2. Medium-term product features: The features and characteristics that would be required in the next five years can be found here.
3. Long-term product features : This period covers the criteria and product features for the next ten years.

The guideline takes up almost all of the ideas of the standardization committees. With regard to the time frame, however, it should be noted that the details for the medium and long-term requirements have not yet been fully described by the standardization committees.

A basic idea of Industry 4.0 standardization is to define the most universal rules possible for the data-centric description of any technical objects (assets) over their entire life cycle.

Reference to RAMI 4.0

The term 'technical object' has a very broad definition. From a standardization perspective, it refers to everything that has value for an organization, i.e. not just the physical drive or a sensor, but also ideas or software.

The third dimension of the RAMI 4.0 model with its six layers from asset to business serves as the actual interface to the digital world. This is where the actual communication with other systems takes place. This dimension correlates with the asset administration shell, i.e. the virtual representation of the asset, another reference model from the Industry 4.0 world. According to the standardization committees, the asset plus the administration shell form the so-called Industry 4.0 component. Such a component enables standard-compliant data access to the asset and is therefore the actual subject of the ZVEI guideline. The focus here is on the relationships between how a future product is identified and integrated into a network in order to communicate with other products in an 'Industrie 4.0-compliant' manner and the communication options themselves.

Access to assets

In other words, developers of automation modules have to deal with the two complex questions "What exactly is a management shell?" and "How and where do I implement this management shell?". But they can take their time with the answers. Bitkom, DKE, VDI, VDMA and ZVEI have not yet fully specified this asset administration shell - at present there are only vague descriptions of the requirements. In this respect, the administration shell according to the ZVEI guideline for 2017 products should only be considered to some extent. From this point of view, it is obviously sufficient at present for product developers to observe the following brief instructions:

1. Identification: stick a QR code with a URI on your product. Make sure that a product-specific website can be accessed via the QR code. Furthermore, make sure that your product is clearly identifiable in an IP network.
2. Communication: Implement an OPC UA server and create corresponding OPC UA objects to read out sensor and status data via an OPC UA client.
3. Semantics: Ensure that the QR code URI can be used to access the catalog data of the product and detailed data about the product life cycle.
4. Virtual description: Make sure that the product descriptions, 3D CAD data, data sheets, etc. can be viewed on the product-specific website via the URI of the QR code. Also ensure that service and spare parts information is also available via this link.
5. Services and statuses: Store a description of the device interface on the product-specific website. Configure the OPC UA server accordingly to make some device statuses available as OPC UA objects.
6. Standard functions: Implement at least one simple, digitally queryable monitoring function (for example, query the remaining operating time until the next maintenance).
7. Security: Ensure adequate IT security at your own discretion.

For the medium-term time horizon of the guideline, i.e. for the period up to 2021, at least one more or less complete administration shell for each component is mandatory. But before that, the standardization organizations must first deliver fully comprehensive specifications. In any case, developers must ensure that a 2017 product with the minimum functions described above can be upgraded to a complete administration shell at a later date. A product developed in accordance with the ZVEI guidelines can be integrated into a domain-based environment (see image). The individual systems are grouped into different communication domains, for example an OT, IT and CT domain.

The overall picture

There are various connections between the domains. All automation technology, such as sensors, actuators, controllers or edge gateways, can be found in the OT domain (OT = Operational Technology). ERP and MES are located in the IT domain (IT = Information Technology), external systems in the CT domain (CT = Cloud Technology).

The administration shell or the product-specific website of a 2017 product, which can be accessed via QR code URI, can be located in different places. In the simplest case, it is located directly on the respective product, for example a controller with the respective resources. Alternatively, implementations are possible on the edge gateway of an automation landscape or in any cloud. A component can have several administration shells, which can also be implemented at different locations if required - for example, one administration shell directly in the sensor, the other in the cloud.

Author:
Klaus-Dieter Walter is a member of the management team at SSV Software Systems.