Status Report - VDI Jahresbericht

Status Report

Industrie 4.0 Components – Modeling Examples

November 2016

Preamble This document has been elaborated in the working group “Modeling Example” of the GMA Technical Committee 7.21 “Industrie 4.0 – Terms, Reference Models, and Architecture Concepts”. The objective of

this document is to illustrate the concept and the management of data models within the asset administration based on a concrete modeling example.

Düsseldorf, November 2016

Prof. Dr.-Ing. Ulrich Epple Head of Technical Committee 7.21 „Industrie 4.0“ of the VDI/VDE Society Measurement and Automatic Control (GMA)

www.vdi.de

Authors The status report has been elaborated in the working group “Modeling Example” of the GMA Technical Committee 7.21 “Industrie 4.0 – Terms, Reference Models, and Architecture Concepts”, especially by the following members and guests: Dr. Annerose Braune; TU Dresden Markus Diesner; MPDV Mikrolab GmbH, Oftersheim Guido Hüttemann; RWTH Aachen University Matthias Klein; Universität Stuttgart Dr. Ulrich Löwen; Siemens AG, Erlangen Mario Thron; ifak – Institut f. Automation und Kommunikation e.V., Magdeburg

Guests Tobias Manger; evosoft GmbH, Nürnberg Dr. Michael Okon; Fraunhofer-Institut IOSB, Karlsruhe

www.vdi.de

Modeling Examples for Industrie 4.0

3

Inhalt Preamble

1

Authors

2

1

Summary

4

2

The I4.0 Demonstrator

4

2.1

Flexible transportation system (multi carrier system)

6

2.2

Application scenario – Adaptable factories (AF)

6

2.3

Application scenario – Value-based service (VBS)

6

2.4

Application scenario – Seamless and dynamic plant engineering (SDP)

7

2.5

Value network on company level

7

Modeling assets of the I4.0 Demonstrator 3.1 Introduction and overview

9 9

3.2

Production – Modeling the product and intermediate products

9

3.3

Order process – Buying the transportation system and carriers from the supplier 12

3.4

Design of the modular manufacturing cell

12

3.5

Analysis of data and providing data-driven services

14

3.6

Simulation of the manufacturing cell and virtual commissioning

15

3.7

Development documents

16

3

4

5

Summary of modeling of the I4.0 Demonstrator

17

4.1

Carrier

17

4.2

Transportation system

17

4.3

Virtual processing unit

17

4.4 Complete manufacturing cell

18

Statements for modeling I4.0 Components 19 5.1 Statement 1 – What is modeled as an I4.0 Component is a design decision 19 5.2

Statement 2 – Distinction between product and I4.0 Component

19

5.3

Statement 3 – For an asset there may be multiple administration shells

19

5.4

Statement 4 – The creator of an administration shell decides what information he passes to others

19

References

20

www.vdi.de

4


1 Summary As subject for illustration the so called Industrie 4.0 Demonstrator was chosen. This is a representative example of a production application. The Industrie 4.0 Demonstrator illustrates some core aspects of Industrie 4.0 (I4.0) by concretization of various application scenarios. At first glance, this task appeared quite simple. The concrete modeling however has quickly shown a high degree of complexity and associated challenges which a user in the context of I4.0 is confronted with. The target audience of this document are users who want to better understand the content and application of the Reference Architecture Model Industrie 4.0 (RAMI 4.0), specifically the concept of I4.0 Components and their administration shells, from an application perspective. Some selected concepts of RAMI 4.0 are described and concrete I4.0 Components of the I4.0 Demonstrator are proposed and modeled. These descriptions do not claim to be complete with respect to the concepts of RAMI 4.0 or I4.0 Components. It should be emphasized that the focus is on concepts. The realization of the I4.0 Demonstrator itself was done without any “guiding principle” of RAMI 4.0 or I4.0 Components. It was implemented based on currently commercially available products. The I4.0 Demonstrator was largely driven by the intended customer benefits – which are addressed by the appro-

priate application scenarios – and less by new technical concepts and solutions. The I4.0 Demonstrator is based on commercially available products. I4.0 Components are proposed by enriching the existing implementation. This was based on application scenarios, for which a qualitative benefit for the involved stakeholders can be identified. Therefore, the implementation of I4.0 does not require complete new products, but – as has been illustrated – the management of information related to the assets will be organized in a more structured way. Of course, it is assumed that in the context of I4.0 new products will emerge in the market. But which specific products this really will be, will ultimately be decided by their market success. Also, it seems not effective to transfer all the information, which today is already available in form of data sheets, (informal) engineering data, runtime data, etc., brute-force into a new formal structure. Organizing data in a more structured way results in an expense, partially in the development and production of products, but also in engineering of solutions. This will only be accepted if there this generates a benefit in total with respect to all stakeholders concerned.

2 The I4.0 Demonstrator User of I4.0 is the manufacturing industry. The manufacturing industry has to ensure the required quality of products and is driven by the challenges to increase efficiency, shorten time-to-market, and enhance flexibility, see Figure 1. In consequence, the value added processes along the entire life cycle of the product have to be reorganized. I4.0 postulates that this can be done by exploiting the opportunities of digitization. To illustrate new ways of organization of the value added processes, the platform I4.0 has developed application scenarios, see [1]. These application scenarios describe the vision of the German industry of their digital future. The I4.0 Demonstrator refines and implements selected aspects of three of these application scenarios, namely adaptable facturies

www.vdi.de

(AF), value based services (VBS) and seemless and dynamic plant (SDP), which are described in the following sections, see also Figure 2. The I4.0 Demonstrator, see [2; 3], and Figure 3, was built by companies from the management board of the Platform I4.0. It is a manufacturing cell, where a flexible transportation system is set up physically and the modular processing units are shown in the virtual world. Specifically, there are processing units for filling, closing, and labeling of bottles, which are typical production sequences in e.g. pharmaceutical, cosmetics, beverage, or food industry. Energy consumption and movement information of carriers of the transportation system are collected and analyzed centrally in the cloud.


5

Figure 1. Challenges of manufacturing industries (Quelle: Siemens AG)

Figure 2. Application scenarios of the Platform I4.0, see [1, page 6] (Quelle: Siemens AG)

Figure 3. Setup and picture of the I4.0 Demonstrator (Quelle: Siemens AG)

www.vdi.de

6


Figure 4. Topology of flexible transportation system (multi carrier system) (Quelle: Siemens AG)

2.1

Flexible transportation system (multi carrier system)

The transportation system, see Figure 4 consists of 15 linear drives, on which a carrier can be positioned (largely 1)) independently.

2.2

Application scenario – Adaptable factories (AF)

This application scenario illustrates how the owner of the manufacturing cell can respond to fluctuating market and customer requirements in a flexible way (see Figure 5). Thus addressing the driver flexibility as part of the adaptable factory. The owner designs a modular manufacturing cell based on individually exchangeable processing units and a transportation system that intelligently adapts to the manufacturing cell and can easily be integrated into the existing intralogistics. Assuming that the owner wants to produce bottles without spray nozzles instead of bottles with spray nozzles, he is confronted with the need to reconfigure his manufacturing cell. The reconfiguration itself can be done by the user by removing the processing unit for spray nozzle mounting. The manufacturing cell is intelligent in the sense that it uses the flexibility offered by the

1)

www.vdi.de

It must be ensured that there is at most one carrier on a linear drive. But the multicarrier system provides technical features to also allow groups of carrier, where are two carriers on a linear drive.

transportation system according to the new configuration of processing units.

2.3

Application scenario – Value-based service (VBS)

In the context of this application scenario the I4.0 Demonstrator illustrates, how the operator of the transportation system can increase efficiency 2) and the supplier of the transportation system can take advantage of new business models. Energy consumption and movement information of the individual carriers are collected in a cloud 3) and evaluated with regard to contamination of carriers and use of the flexibility of the transportation system, see Figure 6. Thus, based on data-driven services the operator of the transportation system can increase the availability of the transport system and thus increase productivity by planning maintenance timely. As a new business model, the supplier of the transportation system can offer and bill the transportation service to the operator based on usage.

2)

This application scenario can be easily extended to illustrate ensuring the required product quality as well.

3)

It is assumed that all operators of transportation systems provide their energy consumption and movement information to the cloud so that benchmarking between different usages of transportation systems becomes possible.


7

Figure 5. Enhance flexibility reorganization of manufacturing cell (Quelle: Siemens AG)

2.4

Application scenario – Seamless and dynamic plant engineering (SDP)

In connection with this application scenario, the I4.0 Demonstrator shows how the system integrator can decrease the time to take the manufacturing cell to operational state. Thus addressing the driver time-tomarket, see Figure 7. By coupling the real application software (and optionally automation hardware) with a model of the production process, which for example is provided by the supplier of the transportation system respectively processing units, errors in the application software can be detected and fixed prior to hardware setup. By using this virtual commissioning approach, a higher quality of the engineering deliverables is achieved and thus speeding up the ramp up of the manufacturing cell.

2.5

Value network on company level

The I4.0 D emonstrator is based on the following crosscompany value network (see Figure 8). The manufacturing cell is built by a system integrator and then provided to the operator. The system integrator integrates the deliveries of the supplier of the transportation system including the carrier and the supplier of the (here: virtual) processing units. He also connects the transportation system to the cloud so that datadriven services can be offered based on collection and analysis of energy consumption and movement information of the carrier.

Figure 6. Increase efficiency analysis of data and providing data-driven services (Quelle: Siemens AG)

www.vdi.de

8


Figure 7. Shorten time-to-market – Simulation of the manufacturing cell and virtual commissioning (Quelle: Siemens AG)

Figure 8. Value network on company level in the interaction of lead market and lead supplier (Quelle: Siemens AG) The operator of the manufacturing cell uses the manufacturing cell to produce the finished goods (filled and labeled bottles) based on various intermediate products based on various raw materials (bottles, caps, spray nozzles, etc.).

Figure 9 illustrates the value chains of the I4.0 Demonstrators by positioning them in the value creation processes according to [4].

Figure 9. Value chains of I4.0 Demonstrator, based on ([3], page 3) (Quelle: Siemens AG)

www.vdi.de


9

3 Modeling assets of the I4.0 Demonstrator 3.1

Introduction and overview

Assets represent a value for a company. Assets can either be part of the real (physical) or virtual world, see [4; 6]. All assets are represented in the asset layer according to the layer axis of RAMI 4.0, see [6]. It is postulated that each feature, function, data, etc. located somewhere in the other layers of RAMI 4.0 can be assigned to an asset in the asset layer of RAMI 4.0. Therefore we focus on the asset layer of RAMI 4.0. It is distinguished between asset types and asset instances according to the lifecycle & value chain axis of RAMI 4.0, for more detail with respect to types and instances see [7]. Based on the vision of the “Internet of Things”, assets, which represent a value for a company and should be managed in the virtual world, are encapsulated by at least one administration shell. Any administration shell encapsulates representative data-models describing or characterizing one or more aspects 4) of the asset. Consequently, information on assets and the access to the information are organized in a uniform way, which is a basis for interoperability 5). The combination of asset and administration shell is called I4.0 Component, see [6]. Figure 11 illustrates selected assets of the I4.0 Demonstrator. The left side illustrates the assets of the real world and the right side illustrates their administration shell (as part of the virtual word). Note that in Figure 11, for reasons of simplicity, only assets of the real world are shown, examples for assets in the virtual world will be discussed later, too. Following sections discuss various examples of assets and information that can be assigned to these assets in the context of the I4.0 Demonstrator. This was done without any claim to completeness. The following table in Figure 12 shows an overview of these assets (column 3) with their submodels (column 4) according to [9], the other columns show an indication of the form of interaction between participants of the value network and the asset following the colour-code in Figure 8. These interactions may differ and are referred to as roles. In the interest of brevity these are referred to as “create” indicating that a participant in the value network creates the asset respectively information and “use” indicating access to the asset respectively information. Note that create/use do not reflect access restrictions. 4) 5)

A gray color in Figure 12 in the first column indicates that the asset is an asset of the real (physical) world. A gray color in the second column indicates that this is a type object according to the “lifecycle & value chain” axis of RAMI 4.0, see [7]. Figure 12 summarizes the assets and their submodels. Note that submodels were defined in such a way so that they reflect a unique perspective (e.g. two order forms, one for the supplier, one for the manufacturer). Note that it is not discussed the benefits of modeling the virtual representatives of an asset. Instead, a general concept called “asset administration shell” is considered and this general concept is considered based on selected scenarios respectively use cases illustrated by the I4.0 Demonstrator. These examples of usage of asset administration shells could be implemented straight forward, i.e. not following the guiding principles of the asset administration shell as defined in [7; 9]. The following sections describe selected scenarios respectively use cases. The sequence of scenarios respectively use cases does not follow any systematic structure, but some of the scenarios resp. uses cases build on each other.

3.2

Production – Modeling the product and intermediate products

The assets described below are localized in the “hierarchy levels” axis of the RAMI 4.0 cube on the “product” level. Note that here we apply the RAMI 4.0 cube is applied to the operator of the manufacturing cell.

3.2.1

Raw materials

Examples in the case of the I4.0 Demonstrator are the bottles, caps, or spray nozzles. These assets are only known by anonymised data, see [5; 6 and 10]. Due to quality control it is “known” that e.g. a cap was not attached correctly, but it is not known, which specific cap was affected. Thus, these physical assets have no administration shell in this example and therefore are not an I4.0 Components.

The term “aspect” is used here in a colloquial sense. The focus of this document is on the concepts only and does not consider implementation issues.

www.vdi.de

10


Bild 10. Focus with respect to RAMI 4.0 (Quelle: Siemens AG)

Bild 11. Selected assets of the I4.0 Demonstrator and their asset administration shells (Quelle: Siemens AG)

3.2.2 Label The label is known individually (see [4; 5 and 9]), since the printed identifier (e.g. QR-code) identifies the label unambiguously. However, it is not managed along its lifecycle, but only in conjunction with the manufactured product consisting of bottle, liquid in the bottle, cap, spray nozzle, label, etc. So the label is another example with no administration shell and therefore is no I4.0 Component. Note that whether the label is known individually or not is a design decision, see Section 5.1. For example, a batch number of the charge of the liquid and the expiry date may be sufficient.

3.2.3 Charge of liquid and finished products The charge of liquid is (possibly with reference to all relevant information from the supplier of the charge of liquid) managed by the operator of the manufacturing

www.vdi.de

cell along its lifecycle. The finished products, consisting of bottle, liquid in the bottle, cap, spray nozzle and label are managed by the operator of the manufacturing cell along their lifecycle as well. The printing of the label serves for unambiguous identification, so that the administration shells of the finished products are realized externally) 6), i.e. not attached to the physical product. After delivery a finished product is managed both by the manufacturer and the user of the product. The manufacturer will usually manage the product over the entire lifecycle, whether the user still is a design decision of the user.

6)

A finished product is a bottle with content and label. The bottle itself cannot provide an administration shell. Therefore the administration shell is external from the perspective of the bottle, for example, provided by sales, purchasing and inventory systems.

use use create use

use create

create create create

11

Supplier of data driven services

use

Supplier of sensors

Supplier of transportation system (including carrier)

use

Supplier of processing unit

System integrator

Raw material bottle Raw material spray head Rwa material cap Printed label Charge of liquid Finished products Carrier type Basis information Development documents,, e.g. internal quality control Product catalogue (Supplier) Order form (System Integrator) Order form (Operator) Information about carrier-specific programming of the transportation system Information about internal good inspection User documentation resp. inspection and maintenance plan (Supplier) User documentation resp. inspection and maintenance plan (System Integrator) Usage Analysis algorithm Physical carrier Basis information Information about manufacturing Information about order (Supplier) Information about order (System Integrator) Information about order (Operator) Information about engineering w.r.t. the transportation system Information about usage, inspection, maintenance Information about prognoses Transportation system type Development documents Configurability in the sense of considered variants Order form Information about programming, e.g. application software, association algorithm User documentation resp. inspection and maintenance plan Specific physical configuration of a transportation system Information about manufacturing Information about order (Supplier) Information about order (System Integrator) Information about engineering Information about usage, inspection, maintenance Virtual processing unit type Generic model (Supplier) Model for X (System Integrator) Modularity model Concrete model (software asset) Executable model (software asset) Physical processing unit Manufacturing cell type Modularization concept Information about programming, e.g. application software Complete manufacturing cell Information about engineering Information about test and commissioning Information about throughput, quality, etc.

Operator of manufacturing cell

Submodel

Asset

Type/Instance

Real/virtual


use create

use use create

create create use create

use

use

create

create use

use

use use create use create use

use create

create create create

use

use use

create use create

use use

use create use

use use use create

use create create use

use use

use create create use create

use use

create create

use use create

create create use

create create create create create create

use create

create

use

Figure 12. Data models of selected assets and their stakeholder (Quelle: Siemens AG)

Figure 13. Modeling and localization of products and intermediate products in RAMI 4.0 Axis “hierarchy levels” (Quelle: Siemens AG)

www.vdi.de

12


3.3

3.3.1

Order process – Buying the transportation system and carriers from the supplier Carrier

The manufacturer of the carrier provides a product catalogue for its carrier. This product catalogue describes characteristics of the carrier types. The system integrator specifies his requirements based on an order form. This order form is associated to the carrier type, and will be based on the corresponding characteristics as specified within the product catalogue 7). In case of a specific order, the manufacturer of an instance of a carrier will deliver specific information (e.g. the serial number) to the system integrator, who buys the carrier, but some information will not be disclosed (e.g. information on manufacturer-internal quality controls). The system integrator will also create specific information about the instance of the carrier (e.g. information about his incoming goods inspection). The system integrator will pass some – but not all – of this information to his customer, i.e. the operator of the manufacturing cell. 8)

The operator of the manufacturing cell will also use a carrier type, for example in order to be able to reorder a carrier from the supplier of the carrier, without having to involve the system integrator. But his carrier type also includes additional information (e.g. carrier usage). The design of the carrier-type typically will be done by the system integrator, but the information of the specific instances is not available to the system integrator.

scribes all variants considered by the development of the transportation system. Typically, the supplier will not offer all of these variants to the market, but will offer to his customer, e.g. based on a product configurator, specific variants according to the sales releases only. Some of the possible variants offered to the market are described in [10].

3.4

The system integrator designs a modular manufacturing cell, where individual processing units can be replaced so that the manufacturing cell can be reorganized without requiring a reprogramming – especially of the transportation system. For this purpose the system integrator designs a modularization principle in the form of a type object of the manufacturing cell. This modularization concept describes the pre-designed possible reorganization options and defines requirements for the processing units. These requirements must be satisfied by the modularity modes of the processing units in order for them to be integrated seamlessly. For example the modularization of the manufacturing cell of the I4.0 Demonstrator is as follows, see Figure 15: n

The first linear drive is needed to identify the incoming carrier and to feed it in a targeted manner to the first processing unit. The final linear drive is needed to catapult the exiting carrier from the flex route, i.e. the 15 linear drives, out to the surrounding intralogistics. Between the individual processing units, at least one linear drive is required to disconnect two neighboring processing units with respect to the material flow and, for example, to enable other group formations of the carriers.

n

The control of the first, the last and the linear drives between the processing units is managed by the manufacturing cell. The control of the linear drives associated actuators to a processing unit are managed by the respective processing unit.

n

The overall coordination of transportation is managed by the manufacturing cell, for example by implementing a pull-principle in which a processing unit requests one (or more) carrier via the transportation system from the preceding processing unit. Other, completely different control algorithms are possible.

Note that Figure 14 illustrates a unique physical asset and each stakeholder in the value network manages its own (logical) administration shell of this physical asset.

3.3.2 Transportation system The ordering process of a transportation system follows the same principle as for ordering a carrier. However, there will be no reorder by the operator of the transportation system. The operator typically will order spare parts only, but not an entire transportation system. The transportation system is a complex system. The supplier of the transportation system will therefore manage an internal configuration model, which de7)

8)

www.vdi.de

At the moment such dependencies between submodels cannot be modeled in the context of I4.0 Components. Typically the user of a carrier does not manage an own carrier type for the ordering process, but only a reference to the carrier type of the supplier of the carrier.

Design of the modular manufacturing cell


13

Figure 14. Submodels for ordering a carrier (Quelle: Siemens AG)

Figure 15. Modularization of the manufacturing cell (Quelle: Siemens AG) unit – are necessary. Whether this will be entered manually after physical reorganization or whether this can be detected automatically after a successful physical reorganization will not be discussed here. The programming of the manufacturing cell and their constituents is as follows: n

Figure 16. Modeling of the transportation system (Quelle: Siemens AG) When reorganizing the manufacturing cell by replacing a processing unit, notifications to the manufacturing cell with respect to the new order of processing units and the assignment, which linear drive is controlled by which unit – i.e. the manufacturing cell or a processing

The application program of the transportation system has to control the linear drives and read the sensor values. The system integrator uses the engineering environment for the transportation system – here specifically SIMOTION SCOUT – to create the application program. The application program later runs on the drive control system – here specifically SIMOTION. The linear drives, sensors, drive control system, and other components according to Figure 4 may be made available by the supplier of the transportation system to the system integrator as separate assets. It is also possible that the supplier of the transportation system only pro-

www.vdi.de

14


vides dedicated interfaces to the system integrator – and not assets with uniform administration shells. This is the case here; where the supplier of the transportation system delivers appropriate libraries together with the engineering system – here specifically SIMOTION SCOUT, see Figure 16. For this reason and for the sake of clarity, the linear drives, sensors 9), drive control system, and other components of the transportation system are not explicitly listed in Figure 12. n

The programming of the overall coordination will not be described here, as there is no additional aspect on the modeling.

n

The modularity model of the processing units has to specify an interface between the commands and requests exchanged between the processing unit and transportation system as well as between the processing unit and linear drives respectively sensors. A challenge is the sharing of common resources for execution of application programs, for example, if the visualization of a processing unit has to be displayed on a central human-machineinterface station. The visualization (or for example the control code) can be modeled as a submodel of the processing unit, but there have to be considered additional requirements resulting from the runtime systems of the resources.

The type-instance concept according to [7] has some limitations when it comes to software assets, which are derived from several “class descriptions”. Strictly speaking, the level of information is disregarded and looked at at a functional level. In order to list software assets in Figure 12, software assets are assigned to submodels of type objects.

3.5

Analysis of data and providing data-driven services

Here we focus on the additional role of the provider of data-driven services. In contrast to other applications described for example in section 3.3 or 3.4, which are engineering scenarios, here we consider a runtime scenario. Note that in this sense the description in section 3.2 is a runtime scenario, too. If it comes to the implementation of an administration shell in runtimescenarios, additional requirements with respect to effi9)

www.vdi.de

The supplier of the position sensor may provide an administration shell for his product, but the supplier of the transportation system does not pass this administration shell to his customers. Therefore the supplier of the sensor is listed in Figure 12, but there is no create/use relation, because there are no submodels for the sensor in Figure 12.

cient communication and access have to be taken into consideration, but this is not in the scope of this status report. An asset of the data driven service provider is the analysis algorithm, which takes usage information as input and generates carrier prognoses with respect to contamination of a carrier. This algorithm is modeled as part of the carrier type of the data driven service provider. Note that for profound analysis results in addition to the usage information about the carrier appropriate context information must be provided, for example, if carriers are driven in groups or if special operating conditions occurr. An example of a special operating condition is the following: before a reconfiguration of the manufacturing cell, the flex route is emptied. In this case the carriers are catapulted with increased power from the flex route. Such effects need to be removed by the analysis algorithm. Thus, the data-driven service provider will not only maintain a model of the carrier, but also of the complete manufacturing cell. The system integrator will ensure that the right information is exchanged a secure way between operator of the manufacturing cell and data-driven service provider in. In our example, the system integrator will also implement an association of the energy data from a drive to the affected carrier. The carrier can only be identified when entering the flex route; therefore the transportation system has to track the positions of the carriers along the flex route and assigns the measured energy of a drive to the affected carrier. At runtime this association algorithm will execute on the drive control system (i.e. SIMOTION) according to Figure 4 and requires the collection of position information from the drives. Therefore the system integrator has to decide whether he will model the drive control system (i.e. SIMOTION) and the drives as independent assets. This has been discussed already in the context of the design of the modular manufacturing cell. The IT infrastructure of the data-driven service provider (i.e. the cloud, etc.) can be modelled also as an asset with an administration shell. Doing this, represents a move from a more conceptual modelling of technological assets to a more implementation related modelling of information technology. Therefore this aspect is not included in Figure 12.


15

Figure 17. Submodels for analysis of data and providing data-driven services (VBS) (Quelle: Siemens AG)

Figure 18. Submodels for simulation of the manufacturing cell and virtual commissioning (SDP) (Quelle: Siemens AG)

3.6

Simulation of the manufacturing cell and virtual commissioning

We assume that the system integrator purchases a physical processing unit from the supplier, which is done in analogy to the transportation system and is therefore not described in more detail. But the supplier of the processing unit also provides an executable model of the ordered physical processing unit. Therefore, the supplier of the processing unit manages internally a generic model of its processing unit, which includes the configurability in the sense of avoidable variants and further aspects. Certain aspects will be made available to the system integrator, similar as discussed in the context of ordering a transportation system. The system integrator develops a model of the processing unit, which he has derived from the model provided by the supplier and which in addition satisfies

the requirements of his modularity model; see Section 3.4. This is the basis for the engineering services of the system integrator with respect to this scenario. The supplier of the processing unit provides a concrete model of the physical and delivered processing unit, which is a software asset (see Figure 12, “Concrete model (software asset)). Via appropriate engineering services the system integrator creates an executable model from the concrete model (see Figure 18). The engineering services include e.g. a parameterization of the model, but also the preparation for using the model in a suitable simulation environment. The system integrator integrates this executable model n

the executable models for the other processing units,

n

an executable model with respect to the coordination of the processing units by the manufacturing cell,

www.vdi.de

16


Figure 19. Development documents as assets (Quelle: Siemens AG) n

and an executable model of the transportation system.

The result is a simulation environment for the complete manufacturing cell. Assume that the supplier of the transportation system does not provide a simulation model. In this case, the system integrator will create a corresponding simulation model, for example based on a hardware-in-theloop approach: n

he couples a real drive control system (e.g. SIMOTION) with a simulation tool (e.g. SIMIT),

n

he loads the application software for the drive control system – created when programming the transportation system – on the drive control system,

n

he creates a process model of the transportation process, which replicates

n

‒

via the simulation tool

‒

the actuator and sensor level of the manufacturing cell, and

3.7

Development documents

This section shortly discusses the modeling of typical development documents, such as requirement and design specifications, but also user documentation, in the form of assets 10). Typically, there are company's policies, according to which such documents have to be created. Often there exist in this context template documents, for example based on MS Word, but also on different specific software tools, which are used as a basis for a concrete development document. These template documents are assets in the form of type objects. Specific development documents are created based on a copy & modify procedure from these template documents. These specific development documents are modeled in Figure 12 as submodels of type objects, for example of the carrier or transportation system. Documents that are made available to a customer typically are created by an additional editorial process taking the development documents as basis. Here as well, the type-instance model according to [7] has its limits.

he provides the instructions between the higher control level and the drive control system over the simulation tool

This scenario provides a view only on some basic principles. Depending on the conceptual and technical approach with respect to the simulation models provided by the supplier there will be a wide variety of concepts and implementations of the simulation of the manufacturing cell. An important aspect is also the extent to which the system integrator uses the simulation only for his own purpose, or whether it is also delivered to the operator of the manufacturing cell.

10)

www.vdi.de

These explanations can be transferred and applied also to design and engineering processes, which are based on product families and lines respectively platforms.


17

4 Summary of modeling of the I4.0 Demonstrator 4.1

Carrier

The carrier is located in the “hierarchy levels” axis on the “field device” level (see Figure 10). Information about the lifecycle of each instance is managed by the supplier of carriers (e.g. information about the production of the carrier), the operator of the manufacturing cell (e.g. the energy consumption and movement information of the carrier) and the cloud provider (e.g. predicted degree of contamination). But each stakeholder in the value chain uses different type models of the carrier: For example, n

the supplier of the carrier intends to manage the development documents,

n

the system integrator intends to program the transportation system (e.g. assigning energy values from the drives to the affected carrier),

n

the operator intends to reorder carriers, and

n

the cloud provider intends to analyze contamination.

As already mentioned, Figure 20 illustrates a unique physical carrier and each stakeholder in the value network manages its own (logical) administration shell of this physical asset. The access rights for the specific (logical) submodels have to be defined and managed by the owner of the (logical) administration shell according to the principles summarized in Figure 12.

4.2

Transportation system

The transportation system is located in the “hierarchy levels” axis on the “station” level. The supplier provides the transportation system (including engineering tools, libraries, etc.) to the system integrator as an instance object. The supplier also manages the delivered configurations of the individual transportation systems over their lifecycles. He also manages – in the context of development and sales – a transportation system of a specific type (e.g. development documents or configurability in terms of released variants). The system integrator orders a specific variant from the supplier and manages his own derivative of the generic transportation system type (e.g. for ordering or programming). The operator uses the transportation system supplied by the system integrator and manages this instance through its lifecycle with respect to usage and maintenance.

4.3

Virtual processing unit

The virtual processing unit is located in the “hierarchy levels” axis on the “station” level. The basic principles are similar to those explained for the carrier and the transportation system.

Figure 20. Localization of carrier in axes “hierarchy levels” and “lifecycle & value-chain” (Quelle: Siemens AG)

www.vdi.de

18


Figure 21. Localization of transportation system in axes “hierarchy levels” and “lifecycle & value-chain” (Quelle: Siemens AG)

Figure 22. Localization of processing unit in axes “hierarchy levels” and “lifecycle & value-chain” (Quelle: Siemens AG)

Figure 23. Localization of manufacturing cell in axes “hierarchy levels” and “lifecycle & value-chain” (Quelle: Siemens AG) Only the following special aspects are noted here: it is assumed that the simulation is performed by the system integrator internally only and will not be delivered to the operator; therefore the operator is not shown in Figure 22. In addition, the focus here is on software assets; as already mentioned are modelled software assets as submodels of type objects. Modeling of the physical processing station is done similar to that of the transportation system.

www.vdi.de

4.4 Complete manufacturing cell The complete manufacturing cell is located in the “hierarchy levels” axis on the “work center” level. This I4.0 Component is designed by the system integrator. The system integrator designs type information of the manufacturing cell and delivers instance information to the operator. The operator will manage information about the usage and maintenance of the manufacturing cell over its lifecycle.


19

5 Statements for modeling I4.0 Components Based on the modeling executed by the members of the team the following statements are important:

5.1

Statement 1 – What is modeled as an I4.0 Component is a design decision

This statement has been illustrated at various points in the previous sections. The “use case” or the purpose drives the structuring of a system in assets respectively I4.0 Components. Various scenarios how on the concept of asset administration shell can be used from an application point of view have been illustrated. Nevertheless, individual decisions are necessary whether an asset is modeled as an I4.0 Component (with asset administration shell) or the asset is modeled in a traditional way. Although for each described scenario that asset administration shells are not mandatory, sometimes conventional approaches not following the guiding principles of an asset administration shell are sufficient. This depends on the benefits generated by the concept “asset administration shell” for the specific use case.

5.2

Statement 2 – Distinction between product and I4.0 Component

Not every product has to be an I4.0 Component and vice versa not every I4.0 Component has to be a product: n

Examples for products that are not I4.0 Components, are raw material (bottle, cap, spray nozzle, etc.), if they are purchased from a supplier who does not manage his products along their lifecycle.

n

An example for an I4.0 Component which is not a product is the modularity model of the processing units. This asset will be managed by the system integrator internally and will not be provided as product to the outside.

n

A system integrator can create an asset, this asset is provided as an I4.0 Component to a user, but this I4.0 Component cannot be bought on its own as a product, but only in the context of an overall solution. As example the system integrator could provide the executable models of the processing units as an I4.0 Components, but the user can use

these I4.0 Components only in the context of an appropriate simulation environment supplied by the system integrator. n

5.3

Even the complete manufacturing cell could be delivered not as an I4.0 Component, but nevertheless the manufacturing cell contains several I4.0 Components.

Statement 3 – For an asset there may be multiple administration shells

This statement is already illustrated in the previous section using the example of the carrier. In particular, the various stakeholders in the value network can specify individual administration shells for their specific purposes. After the production of a product, there are usually (at least) two administration shells: on the one hand an administration shell held by the producer of the product and on the other hand an administration shell held by the user of the product. “The one and only” administration shell, in this respect for an asset does not exist. Just as models are always specific representations of an original driven by a specific purpose, this also applies to the administration shell.

5.4

Statement 4 – The creator of an administration shell decides what information he passes to others

For example, a system integrator decides – typically in negotiation with his suppliers and its customers – what information of an administration shell will be provided to others. As a consequence, the administration shell of assets, which have been composed to an overall system, may not be accessible for the user of the overall system. The sensors of the transportation system could be provided by the supplier of the sensors as an I4.0 Component with an administration shell, but the supplier of the transportation system does not provide these administration shells to a system integrator of the complete production cell, see Figure 16.

www.vdi.de

20


References [1]

Aspects of the Research Roadmap in Application Scenarios, http://www.plattform-i40.de/I40/ Redaktion/EN/Downloads/Publikation/ aspects-of-the-research-roadmap.html (02.11.2016)

[2]

Industrie 4.0-Demonstrator, https://www.youtube.com/watch?v=4dmA1QtAUzo (02.11.2016)

[3]

[4]

[5]

VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: VDI-Statusreport Industrie 4.0 Wertschöpfungsketten, April 2014, https://www.vdi.de/ fileadmin/vdi_de/redakteur_dateien/sk_dateien/ VDI_Industrie_4.0_Wertschoepfungsketten_2014.pdf (02.11.2016) VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: VDI-Statusreport „Industrie 4.0 – Gegenstände, Entitäten, Komponenten“, April 2014, https://www.vdi.de/fileadmin/vdi_de/redakteur _dateien/sk_dateien/VDI_Industrie_4.0_Komponenten _2014.pdf (02.11.2016) VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: VDI Status Report Industrie 4.0 – Technical Assets – Basic terminology concepts, life cycles and administration models March 2016 (02.11.2016)

[6]

Das Referenzarchitekturmodell RAMI 4.0 und die Industrie 4.0-Komponente, http://www.zvei.org/Themen/Industrie40/Seiten/ Das-Referenzarchitekturmodell-RAMI-40-und-dieIndustrie-40-Komponente.aspx (02.11.2016)

[7]

Life-Cycle-Management for Automation Products and Systems, ZVEI 2012, http://www.zvei.org/ publikationen/guideline_lifecycle_en.pdf (02.11.2016)

[8]

VDI/VDE-Gesellschaft Mess- und Automatisierungstechnik: VDI-Statusreport Fortentwicklung des Referenzmodells für die Industrie 4.0 – Komponente – Struktur der Verwaltungsschale, https://www.vdi.de/ fileadmin/vdi_de/redakteur_dateien/gma_dateien/ 6146_PUB_GMA_ZVEI_Statusreport_-_RAMI _4-0_Struktur_der_Verwaltungsschale_Internet.pdf (02.11.2016)

[9]

M. Diesner: CP-Klassifizierung – Benennung von Komponenten im Industrie 4.0-Umfeld, Automation 2015

[10] Multi Carrier System, http://w3.siemens.com/ mcms/mc-solutions/en/mechanical-engineering/ packaging-machine/mcs/Pages/multi-carriersystem.aspx (02.11.2016)

The VDI Speakers, Designers, Network Engineers The fascination for technology drives us forward: For 160 years, the VDI Association of German Engineers has provided vital impetus for new technologies and technical solutions for improved quality of life, a better environ-ment and greater standard of living. With some 155,000 personal members, the VDI is the largest technical and scientific association in Germany. As a voice for engineers and technology, we actively help shape the future. Each year, more than 12,000 volunteer experts process the latest findings to promote our technology base. As the third largest issuer of technical regulations, the VDI is a partner for the German economy and science.

www.vdi.de

VDI Verein Deutscher Ingenieure e.V. VDI/VDE Society Measurement and Automatic Control (GMA) Dr. Heinz Bedenbender Phone. +49 211 6214-485 [email protected] www.vdi.de