1 Introduction

The “Plattform Industrie 4.0” has promoted application scenarios that illustrate the vision of the German manufacturing industry with respect to digitalization and emphasize which technical and organizational innovations should be used or are still to be developed. The application scenarios also show the key challenges for standardization, research, IT security, legal issues and workforce. The technical committee 6.12 “Integrated engineering of automated systems” of the VDI-/VDE-GMA (German Association of Measurement and Automation) has developed the application scenario “Seamless and dynamic engineering of plants” (in short: SDP), which is one of the application scenarios promoted by the “Plattform Industrie 4.0” [1]. As of July 2017, the GMA technical committee 6.12 has refined the application scenario SDP by means of two sub-scenarios [2]. The description in [2] is focused on changes of business roles involved in the value network along the life of a plant and provides a business view on the sub-scenarios. This business view is based on a business model logic, illustrating the relationships between business roles such as a plant manufacturer, a system integrator, or a plant owner.

Figure 1

Different views on the application scenario SDP (according to [7]).

The overall principle of the application scenario SDP is an integrated plant model which is initially created during the engineering phase and maintained and kept consistent throughout the entire life of the plant (thus, providing a “digital twin” of the plant [3]). Additionally, this plant model also includes boundary conditions, context information, possible variants of the plant, conceivable and implemented engineering decisions as well as the impact of such decisions. This requires repetitive exchange of information during engineering, construction, operation, and service of the plant. All created information shall be stored, and necessary information should be provided by such a plant model.

This paper provides a usage view of the application scenario SDP and focuses on the integrated plant model and the interaction of technical roles (e. g., model object creator, manufacturer of physical object) with this model. The technical committee 6.12 has analysed and structured these usage activities and herewith provides an insight into the results of this work. In Section 2, the methodological approach to the description of use cases is explained. Section 3 summarizes the need for an integrated plant model. In Section 4, the system under consideration is defined, and the activities, which are required to build, maintain and use the integrated plant model, are described. Section 5 exemplifies these activities at the example of a pump. In Section 6, possible further research directions are outlined.

2 Methodological background

In the context of Industry 4.0, both a business view and a usage view have already been described for another application scenario (named “Value-based Service”, in short: VBS), see [4], [5] and [6]. The knowledge gained from these activities was incorporated in the update of the German Industry 4.0 standardization roadmap, see [7], where a separate chapter on “Use Cases” has been added. Since the term “use case” is used in quite different contexts with different objectives, it was proposed to consider subjects under different views and then to conceptually distinguish between business scenarios and use cases (see also Figure 1):

1. Business scenarios primarily describe a business context which is addressed by the business view. The basis is a value-network of business roles where each business stakeholder is characterized by its own business model [8]. Relations between the business roles within the value-network are characterized by value propositions.

2. Use cases primarily describe the interaction of technical stakeholders (later called “roles” in this paper) with a technical system. They are addressed by the usage view. Thus, use cases describe the context of a technical system and high-level requirements how the technical system interacts with the context. Use cases can be described on different levels of detail.

The GMA technical committee 6.12 took up this recommendation. The description of the application scenario SDP [2] includes two business scenarios according to Figure 1. Recent work of the technical committee 6.12 was devoted to a use case description according to Figure 1 which is the focus of this paper.

3 Need for an integrated plant model

Model based engineering is state-of-the-art in various technical domains and has therefore often replaced document-based engineering. For the engineering of plants in process industries, for example, a variety of model-based engineering methods have been developed for various purposes. Among others, those methods support rule-based analysis and synthesis [10], model-based control code generation [11], model-based testing (e. g., for factory acceptance test [12]), or model-based production optimization during operation of the plant [13]. Yet, model-based engineering usually focuses on a dedicated phase of the engineering process, and the models applied have been particularly developed for this engineering task which causes considerable effort. Hence, only isolated applications for certain engineering activities with their own restricted models can be found, but not a comprehensive plant model that comprises the complete life of plants. The effort to create such a comprehensive plant model is often regarded as being too high, because of the unique character and the size of the plant model. The uncertainty regarding the monetary benefits to be expected from a plant model further intensifies the problem, since the creation of a plant model would have to be financed by the project. Especially for plants, subsequent modifications in the physical world are currently more effective than modelling and planning activities in advance by using a plant model, and therefore the plant model is often not maintained properly and deviates more and more from the physical plant. This also restricts the potentials of the respective methods, because the effort for the creation and maintenance of those models ascends, while the benefits cannot be accurately quantified.

However, a consistently maintained plant model that is used across all phases of the life, as described in the application scenario SDP [2], would generate high synergy potentials by means of model reuse and early integration. Hence, a comprehensive plant model is more effective than the creation and maintenance of various distinct models. Furthermore, a plant model of high quality improves the various task-specific models derived from it. Regarding the creation of the plant model, the problem remains that those who are active in the early stages of the plant’s life will have to create the plant model and those who are later active in the plants life, e. g., during operation of the plant or for brownfield modifications, will likely use the plant model, but won’t be willing to pay for it [14]. Also, a new role within the engineering organization, which focuses on the creation and maintenance of the plant model, will be needed.

The business view addresses these questions [2]. However, it was discovered that a variety of different business models can be identified and therefore no single business transformation scenario exists. For a successful implementation of an integrated plant model across the complete life of a plant, including all involved stakeholders, it is necessary to create a common understanding of the model and the benefits it provides.

For this reason, the technical committee 6.12 “Integrated engineering of automated systems” of the VDI-/VDE-GMA has developed a usage view of an integrated plant model. Certain aspects of the usage view will be introduced in the following. Note that in a usage view, an integrated plant model should be described in terms of its application perspective. Although an integrated plant model contains structural, functional and behavior-based aspects, these aspects should not be considered in a usage view, but in a functional view.

4 Usage view

To describe a usage view, the following aspects must be described:

1. System under consideration: It is important to clearly define the scope of the system which will be considered in the usage view.

2. Roles: Roles are actors outside of the system under consideration, interacting with the system under consideration. Roles may be assumed by humans or other technical systems.

3. Activities: An activity describes a specific interaction of specific roles with the system under consideration. An activity is described by a trigger, a workflow of tasks executed by some roles, and the effect caused by the execution of the tasks.

Figure 2

Overview of usage view on SDP.

4.1 System under consideration

Regarding the system under consideration, objects are assigned – because of their fundamental being – to either the physical or the model^[1] world. Regardless of this assignment, every object exists in reality and has its own life. However, the management of objects and their lives are fundamentally different. While physical objects are permanently in an aging process due to their physical presence, objects of the model world are only changed by interventions from outside.

Therefore, the system under consideration consists of the following parts:

1. On the one hand, it includes objects from the model world. The objects of the model world are divided in model objects and model object templates. Model object templates are organized in a library and can serve as templates for creating model objects. Models can be used for descriptive purposes (i. e., describing an existing object) or prescriptive purposes (i. e., describing a not yet existing object) [15]. Objects of the model world are pure information objects.

2. On the other hand, it includes objects from the physical world. These objects exist independently of the objects from the model world; however, a physical object can be represented by one or more objects from the model world, or one or several model objects can be the basis for the creation of an object from the physical world.

The following Sections 4.1.1 and 4.1.2 further describe the objects from the model world while Section 4.1.3 describes the objects from the physical world and the relation to the objects from the model world.

4.1.1 Set of model objects

The concept of model object forms the basis for modeling:

1. A model object can be associated to another model object via a relation. A specific relation between model objects is an aggregation where the existence of the sub-models is independent of the existence of the superior model object.

2. Model objects may have attributes and attributes have values. Typically, attributes may have additional characteristics like value range, unit, or default value, but these aspects are out-of-scope of our considerations.

3. Each model object has an owner which is an actor assuming a role. The concept of ownership is used to manage the interactions of actors with the system under consideration, because it is intended that some interactions are restricted to specific actors only. Ownership can be defined for model objects, attributes, values of attributes, and relations between model objects. An owner can grant ownership to another actor assuming the same role. Typically, there are different levels and kinds of ownership.

4. Each model object has a life. We assume that every model object knows its complete history since its creation. When a model object is deleted, it lives on in an “archive” world. The model object cannot be changed further, but its full history is still available.

There are various purposes intended by models (see Section 3). Therefore, model objects and/or their attributes can describe requirements, solutions, assertions, measurements, value assignment, etc. We do not distinguish here between such different purposes and descriptions. In addition, model objects can be structured according to different principles, e. g., spatial structure, logical structures, disciplines, cause-effect relations. Again, we do not distinguish here between such principles of structuring.

4.1.2 Library of model object templates

The concept of a model object template is intended to be used for the creation of model objects. A model object template describes common characteristics of model objects which are created from the model object template. The model object templates and their lives are considered as part of the system under consideration.

If a model object template is used as the basis for the creation of a model object, this may result in a relation between the model object template and the created model object. There are different kinds of possible relations, which have different effects in the case of a change of a model object template, but we do not look at the different cases in this paper in details. Examples for different kinds of relations are:

1. Model object templates are organized in an “offline” library: Here, changes to a model object template do not affect the associated model objects; only with newly created model objects will these changes take effect.

2. Model object templates are organized in an “online “library: Here, changes to a model object template take effect immediately; thus, all associated model objects are affected and will consider these changes accordingly.

3. Hybrid concepts of both approaches with an explicit authority of the user are also possible.

Furthermore, there can be relations between model object templates:

1. Model object templates can be structured by relations and can be organized in libraries.

2. Each model object template and each library have an owner and a life.

4.1.3 Physical object

Physical objects are objects in the physical world.

1. A physical object can be assigned to multiple model objects. These model objects not only represent explanations, but also, for example, requirements, descriptions, or measurements.

2. Physical objects also have a life. In order to make the life of a physical object accessible to the model world, an activity is necessary by explicitly assigning a model object to a physical object. This assigned model object must be distinguished from the physical object and has its own life, but there can be physical objects whose life are not represented in the model world.

3. The scope as well as the start and the end of life of a specific physical object is a design decision.

Physical objects may comprise executable software (for example, the process control system of a plant is part of the physical world). Physical objects may also be “intelligent” (for example, they could act autonomously or could provide “plug & produce” capabilities).

There are physical objects which are typically consistent with the associated model objects (for example, executable software), but there also are physical objects where updates in the associated model objects must be initiated to synchronize the associated model object with the physical object in the case of changes.

In various communities, the term “digital twin” is currently being discussed intensively. According to the Plattform Industrie 4.0, a “digital twin” is a virtual digital representation of a physical asset. Thus, in the sense of this paper, a model object associated with a physical object would then be a “digital twin” of the physical object.

4.1.4 Tool environment

A tool environment is a suite of software tools and applications including methods necessary to execute the various activities as described in Section 4.3 (especially, if they are executed by humans). Such a software must provide various capabilities, such as the

1. creation, management and usage of model objects and model object templates including versioning, access control, etc.

2. evaluation and simulation of model objects

3. support of engineering workflows and engineering decisions

4. interaction with physical objects by sensing and actuating.

The capabilities of such a tool environment will continue to increase. Activities which are nowadays typically executed manually will be increasingly supported or even successively automated in the future.

Figure 3

Overview of roles.

The specific capabilities of such a tool environment address more a functional view and therefore are out-of-scope of this paper.

Figure 4

Clusters of activities in connection with the system under consideration and roles.

5 Example: Installation and replacement of a physical pump

The description of the usage view, as provided in Section 4, is generic, but rather abstract. Therefore, it will be illustrated in this section by means of an example how the various activities defined in the usage view can be applied. By having considered further examples, a certain completeness of the list of activities can be postulated. However, it should be noted that this example is not intended to illustrate the content structure of an integrated plant model, because a functional view of an integrated plant model is not within the scope of this elaboration.

In this example, a physical pump is configured and installed in a plant and later replaced by another physical pump. Various model objects and model object templates are designed and used for that purpose.

Figure 5 shows that two different companies are involved. On the one hand, the supplier of a physical pump, who develops a model series of a pump model and, on request of a customer, produces and delivers a corresponding physical pump to the customer. In addition, the supplier of the physical pump also provides a simulation model of the pump to the customer. On the other hand, the operator of a plant, who first designs a plant, in which such a pump will be installed, then orders a corresponding pump and physically installs this pump in the plant. Later, the operator of a plant replaces this physical pump by another pump, for example, because the operating conditions have changed and the original pump cannot execute the intended task any longer.

Figure 5

Companies and value chains involved in the example (light orange: supplier of a physical pump, dark orange: operator of a plant).

In this context, especially the following objects should be considered:

1. The development department of the supplier of a physical pump will create a model object pump_model_series according to the activities “Creation of a model object” and “Planning activity”. This model object describes all development and production artifacts for this model series of a pump. In particular, the model object pump_model_series will comprise a product catalog product_catalogue. This is a model object template that describes the assurances that a concrete physical pump will satisfy. Furthermore, the model object pump_model_series will comprise a simulation model in form of a model object pump_simulation.

2. The engineering department of the operator of a plant will create a piping & instrumentation diagram. This piping & instrumentation diagram will comprise a model object role_pump describing the requirements that some pump, which should later implement this role in the physical plant, must satisfy.

3. At some time, the engineering department will select and order a specific pump. For this purpose, the product catalog product_catalogue is made available by the supplier of a pump according to the activity “Transfer of a model object from a model user to another model user”. From this catalogue, a suitable pump satisfying the requirements is selected. With the selection, the engineering department creates a model object virtual_pump0 according to the activity “Creation of a model object”, which is made available to the supplier of the pump in the form of a model object virtual_pump0_supplier. The engineering department also refines the model object role_pump according to the activity “Modification of a model object” by associating the model object virtual_pump0.

4. We assume that for each model object in the piping & instrumentation diagram, a corresponding model object described in a simulation language is provided. Thus, in this example, there is a model object pump_simulation which is made available by the supplier of a pump according to the activity “Transfer a model object from a model user to another model user”. Based on the piping & instrumentation diagram, the engineering department will parametrize all these model objects for simulation and, by aggregating them, will create a model object plant_simulation, which can be simulated using a suitable simulation tool environment according to the activity “Evaluation/simulation of a model object”. The simulation based on the simulation tool environment configured by the model object plant_simulation is a physical object plant_simulator.

5. Based on the model object virtual_pump0_supplier and with reference to the model object pump_model_series, the supplier of a pump will manufacture a physical pump physical_pump0 according to the activity “Creation of a physical object”. In doing so, the supplier will enrich the model object virtual_pump0_supplier according to the activity “Modification of a model object” based on information relevant to him resulting from the manufacturing of the physical pump physical_pump0. In this context, the model object virtual_pump0_supplier is associated with the physical object physical_pump0 according to the activity “Creation of a descriptive model”.

6. The supplier of a pump will deliver the physical pump physical_pump0 to the operator of a plant and will also provide parts of the model object virtual_pump0_supplier according to the activity “Transfer a model object from a model user to another model user” in the form of a model object virtual_pump0_operator.

7. The operator of a plant will install the physical pump physical_pump0 in the plant and will modify the model object virtual_pump0 based on the model object virtual_pump0_operator according to the activity “Modification of a model object” and will associate the physical pump physical_pump0 with the model object virtual_pump0 according to the activity “Creation of a descriptive model”.

8. During operation of the plant, the operator of the plant will use the physical object plant_simulator, which has been configured by the model object plant_simulation, to compare some results of the plant_simulator with values provided by the plant. This comparison can be done tool supported. If there are any discrepancies, he can conclude that the physical pump physical_pump0 may have some defect and, for example, initiate suitable maintenance measures.

9. After a certain period of operation, the operating conditions of the physical pump physical_pump0 may have changed. In this case, the model object role_pump is changed according to the activity “Modification of a model object” so that role_pump now describes the new requirements. If the physical pump physical_pump0 cannot meet these new requirements any longer, a new physical pump must be selected according to a model object virtual_pump1 and ordered from the supplier of a pump. The supplier of a pump will then provide to the operator of a plant a physical pump physical_pump1 including a model object virtual_pump1_operator. The association between role_pump and virtual_pump0 is deleted according to the activity “Modification of a model object” and instead role_pump is associated with the model object virtual_pump1 according to the activity “Modification of a model object”. Usually, the physical pump physical_pump0, including the associated model object virtual_pump0, will continue to exist, for example, (temporarily) in a spare parts warehouse.

Figure 6

Overview of main physical objects, model objects and model object templates in this example (light orange: supplier of a physical pump is the owner of the object or object template, dark orange: operator of a plant is the owner of the object or object template).

6 Conclusion and future work

The usage view of the application scenario SDP describes all main roles and activities regarding the model objects, the model object templates, and the physical objects which are in the focus of this application scenario. Thus, the various approaches to create a model, change, maintain and apply a plant model can be described on a common, abstract level. This applies to, among others, the approaches developed in the GMA technical committees 6.11 (which focuses on virtual commissioning), 6.16 (which develops engineering data exchange formats) and 6.23 (which is concerned with plant asset management). This common description of plant-model-related activities can serve as a basis to link the various model-based approaches along a plant’s life.

More generally speaking, beyond the model of a plant, this usage view could be applied also to products, e. g., to describe the activities in Product Lifecycle Management (PLM).

The necessary engineering tools have not been dealt with in this paper, but can be analyzed on this basis. According to Figure 1, the level below the usage view is the functional view. To derive the required tool functions from the activities of the usage view seems to be a promising, systematic approach.

How to implement the activities is again one level below the functional view, according to Figure 1, and thus out of the scope of this paper. In the implementation view, e. g., the advantages of Artificial Intelligence (AI) methods could be analyzed, as they offer promising possibilities to create, maintain, and apply plant models.