Data point 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.
| Data point | 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 data point 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 data points. The data points are defined in a tree structure with arbitrary branching levels.
The values of the actual process values are saved on data point elements (the outer leaves of this tree structure). Each process variable corresponds to a data point element within a data point. In addition, the tree structure can have as many nodes as necessary for a clear organization of the data.
Each data point 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 data point. 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 data point element are called "configs" in WinCC OA. Only configs that are also needed for a certain data point, are defined.
Data point Type and Data point
The user may configure an appropriate data point type for each real device type (drive, valve, stirring unit, controller, intrusion sensor, ...). A data point for each real device is derived from this data point type (kind of template). In the object-oriented software engineering you would call the data point 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 data point types that represent a module (for example service hour counters) can be set to be a part of a new data point type. This kind of hierarchically built data points (type-in-type) offer new, efficient engineering possibilities.
Changes of the data point type also change the data points (instances).
In conjunction with the structured data points 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 data points correspond to a form of "object".
