Datapoint Concept, Process Image
The variables of the process that should be handled and monitored must also be found in the software in the control room. There has to be a variable that represents the value of every logic state, every measured value or set value within the system.
| Datapoint | Description | Unit | Value |
|---|---|---|---|
| V02.state.closed | Valve V02 response, End position closed | - | TRUE |
| V02.cmd.open | Valve V02 command open | - | FALSE |
| ... | |||
| PI09.value | Pressure measurement PI09 actual value | bar | 2,74 |
| ... |
In WinCC OA these variables of the process image are called "data points". Other names are often used, depending on the product or the region (tag, process variable, PV, item, Point, I/O point, ...)
Whereas common SCADA systems assign one datapoint to each single process variable, WinCC OA chooses a more modern way: almost all information of the process belong logically to a more or less complex ensemble: a device.
The practice shows that the number of information belonging together (of such a device) is typically between 4 and 30. Intelligent units like digital controllers, function modules or robots can easily exceed this number.
Instead of making this logically close combined values to independent variables isolated of each other, WinCC OA defines structured, device orientated datapoints. The datapoints are defined in a tree structure with arbitrary branching levels.
The values of the actual process values are saved on datapoint elements (the outer leaves of this tree structure). Each process variable corresponds to a data point element within a datapoint. In addition, the tree structure can have as many nodes as necessary for a clear organization of the data.
Each datapoint element is addressed individually by the description chain within the structure. The operating notification "Open" in the example above could for example be addressed through:
Valve.Response.OperatingNotif.Open
In practice you certainly want to save desk work and use short descriptions. WinCC OA, however, allows almost unlimited character strings.
In addition to the naming convention and a storagelocation for the actual value, specific control functionalities can be defined for a datapoint. This can be, for example, a value range check, the definition of an alert handling or a statistic calculation rule. These functionalities defined for a datapoint element are called "configs" in WinCC OA. Only configs that are also needed for a certain datapoint, are defined.
Datapoint Type and Datapoint
The user may configure an appropriate datapoint type for each real device type (drive, valve, stirring unit, controller, intrusion sensor, ...). A datapoint for each real device is derived from this datapoint type (kind of template). In the object-oriented software engineering you would call the datapoint type a "class" and the representation of an individual device (the data point) an instance.
The creation and also the configuration of numerousness process factors that represent a device is therefore limited to a single operation. Already defined datapoint types that represent a module (for example service hour counters) can be set to be a part of a new datapoint type. This kind of hierarchically built datapoints (type-in-type) offer new, efficient engineering possibilities.
Changes of the datapoint type also change the datapoints (instances).
In conjunction with the structured datapoints and their inheritance concept between type and instance we often also talk about object orientation. This is not fully comparable with the object orientation of higher languages like C++, C# or Java. It is rather a question of the general approach to define data and methods (functions) as capsuled units and therefore guarantee their easy and efficient reusability. Structured datapoints correspond to a form of "object".
