OPC XML-DA properties and IGUANA datapoint properties

IGUANA datapoints and OPC Items have different properties that may not match each other, or are simply missing.

The OPC XML-DA standard does not specify mandatory properties, which means that in theory an Item does not need any properties at all¹⁰⁹. However, some of these properties are needed for certain services, which makes these properties mandatory¹¹⁰. Therefore some important OPC Item properties have to be available, moreover, it makes sense to implement properties that have a corresponding counterpart in the IGUANA gateway. This may be done by mapping certain OPC Item properties to IGUANA datapoint properties, as depicted in Figure 54.

Figure 54: Mapping OPC Item Properties to IGUANA Datapoint Properties

Some mappings of Properties between OPC and IGUANA cannot be done directly. Possible solutions to these mappings are as follows:

dataType:

OPC Items have a so-called ``canonical data type'', which outlines in which data type the fieldbus data is encoded by default. The IGUANA gateway does not directly provide such metadata¹¹¹, however IGUANA encoding styles may be associated with appropriate data types, as stated above.

quality:

OPC specifies the property ``quality'' for informing client applications about the status of the fieldbus data. Possible values are ``Good'', ``Bad'' and ``Uncertain''. The IGUANA gateway does not provide information about the data quality and does not implement a corresponding property. However, if the ESD returns an error which is mapped to an appropriate OPC result code, the quality must be set to ``Bad''. [OPCXMLDA] also defines that the property is only mandatory if the quality is other than ``Good''. The most suitable solution seems to be to entirely omit the quality property except ESD returns an error¹¹².

timestamp:

[OPCXMLDA] states: ``The servers will provide the most accurate timestamp to associate with a value. The timestamp should indicate the time that the value and quality was obtained by the device or the time the server updated or validated the value and quality in its cache.''

The IGUANA gateway does not provide timestamps from underlying fieldbus systems. Therefore the only way to implement this OPC property is to set the timestamp by the OPC server itself. As figure 55 shows, the actual fieldbus read, which is the most accurate time where the data is valid¹¹³, will be somewhere between the ESD read request and its read response.

Figure 55: Possible Fieldbus Data Reads Between the ESD READ-Request and READ-Response

The timestamp may therefore be set somewhere between these two points. One way to approximate the time would be to calculate an average value, such as by $timestamp = (t_{request} + t_{response}) / 2$. However, a jitter still remains, moreover, there may be cases where the timestamp is set to a time before the data was valid, which may be inappropriate for various applications. Therefore it may be best to simply set the timestamp to the time the response message is received.

accessRights:

This OPC property specifies the accessibility of the OPC Item. Valid options are ``unknown'', ``readable'', ``writeable'' and ``readWritable''. ESD on the other hand implements the property ``Access'' that is mandatory and may be mapped to its OPC counterpart. The string format, as specified in section 5.13 in [LOB02] is slightly different and has to be translated¹¹⁴.

scanRate:

[OPCXMLDA] states: ``This represents the fastest rate (in milliseconds) at which the server could obtain data from the underlying data source.''

Although such information is not available from the IGUANA gateway, this property may be used to limit the gateway load by informing the client what response times can be expected through this parameter. Therefore this property may be set to a very rough approximation, such as ``1000ms'', so that clients do not query the gateway too often. However there is no guarantee that this property will be regarded by IGUANA gateway clients.

[OPCXMLDA] defines many other Item properties, such as engineering units, maximum/minimum values, its precision and many more. These additional properties are not required for an XML-DA compliant OPC server, moreover, they don't have a counterpart at the IGUANA gateway. Therefore these properties will not be addressed.

The IGUANA gateway itself provides the following datapoint and node properties which are not addressed by the OPC specification:

DataType:

This is the FAN-specific data type of the data point.

SetOfEncodings:

This property provides information about possible encoding styles of underlying fieldbus data. This information is more or less represented by according OPC Items. Nevertheless this property may be provided as an OPC property¹¹⁵.

dp_name:

The name of the datapoint as defined in the node.

dp_num:

A property that specifies the number of datapoints that are connected to a node.

nsid_str:

This property contains an optional self identification string of the node.

opt1_str/opt2_str:

These are optional properties which may be used for the node location and the program ID of a fieldbus node. These properties are only available from an underlying LonWorks fieldbus and are encoded in the BINHEX format.

The OPC specification allows to define custom properties, therefore these IGUANA specific properties may be simply implemented into the OPC server like all properties specified by OPC. Nevertheless it makes sense to outline that these properties are IGUANA specific. This could be done by prefixing them with the string ``IGUANA'', such as ``IGUANA_nsid_str''.