Introduction
The object-oriented approach of WinCC based on the type-instance concept. In types, you create central properties for an object. The instances represent local places of use for the types.
Plant objects are instances of a plant object type.
The plant object type is the central, object-oriented definition of a reusable plant component (such as conveyor robot). As instances of the plant object type, the plant objects generally map concrete, physically existing plant components (e.g. conveyor robot_A and conveyor robot_B).
If you change a property of a plant object type, the property is saved centrally and also changed in all instances.
Effect of the type instance concept on object-oriented configuration
The use of a type is called an instance. The common plant model is generated from instances. Each instance inherits all the properties of the type. The Common Plant Model with high level of standardization is characterized by the use of many instances of few types in the model.
The general types of the plant units are configured and these are reused when required in the configuration and adapted to the specific plant objects. The plant structure hereby specifies the addressing of the plant objects.
In the object-oriented approach of WinCC the following correspondences apply:
-
Type = Plant object type
-
Instance = Plant object
The following figure shows the basic structure of a plant model:
Plant objects and plant object types
A plant object is a technological unit. In a plant object, the components are stored in a typical form which is required for modeling a plant.
A valid plant object must be created from a plant object type. The plant structure is created from plant objects.
The definition of a plant object type consists of the data structure and context information:
-
Alarms
-
Logging
-
Visualization
-
Data member (internal and external)
-
Facets (e.g. performance indicators)
Type definition in terms of high reuse
A plant object type is used to describe a plant object independently of its use in the Common Plant Model. Define a plant object type as generally as possible and as specifically as required. Take into account the following aspects:
-
Identical data structure in PLC (function block or PLC UDT)
Example: Pumps that have different performance ranges are installed in a plant. The data structure in the PLC is identical for each pump. Map these pumps with a common plant object type. At each instance you configure the specific value ranges for the respective performance ranges.
A pump function block (standard FB for a pump) is available on the control side. The customer defines the plant object type "Pump" based on this function block. The data structure of the plant object type is taken over directly from the block. Only the HMI relevant properties from the function block are hereby transferred. They are automatically updated when the block changes. Simply parameterize an instance of the function block as process connection of the plant objects.
-
Similarity
When you have similar plant object types, check if it possible to map these with a common plant object type:
①
Example: A pump is installed in a plant in two different variants:
-
Variant 1 only measures the flow rate.
-
Variant 2 measures the temperature in addition to the flow rate.
Effects on the definition of the plant object types:
-
You map each of the two pumps with a single plant object type. The representation in the Common Plant Model hereby corresponds to reality.
-
There is more configuration work.
②
The common intersection of the two pumps is measuring the flow.
③
If, for example, you can do without measuring the temperature for operation, define only one plant object type:
-
There is less configuration work.
-
The two variants of the pumps are not fully represented in the Common Plant Model.
-
Effects of changes on plant object types
The following figure shows how changes to the plant object type affect its instances, i.e. plant objects:
