next up previous contents
Next: Addressing Scheme Up: Representing the IGUANA Interface Previous: Representing Datapoint Values with   Contents

Data Encoding, Data Types and Type Conversions

The IGUANA gateway encodes fieldbus data in various ways, such as encoding a sensor value with the SCALARBIN or BINHEX encoding. [OPCXMLDA] does not address encoding issues at all but defines 20 simple data types and also provides enumerations and 14 different array types that may be associated with OPC Item values as partially shown in figure 46.

Figure 46: Available Simple OPC XML-DA Data Types for Item Values as Specified in [OPCXMLDA].
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/xmlda-datatypes.eps}\end{figure}

The best way seems to represent encodings with OPC Items, as depicted in figure 47101. This way, fieldbus data may be provided in multiple encoding styles.

Figure 47: Representing IGUANA encodings as OPC Items.
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/xmlda-encoding-items.eps}\end{figure}

[OPCXMLDA] assigns to every OPC Item a so-called ``canonical data type'' which is the default data type associated with a fieldbus value. The IGUANA gateway does not provide such information, however encodings may be mapped to certain data types as shown in figure 48. An OPC XML-DA compliant server on the IGUANA gateway would therefore implement three canonical data types, namely ``string'', ``float'' and ``dateTime''.

Figure 48: Associating data types to IGUANA encoding styles.
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/xmlda-enc-type.eps}\end{figure}

The BINHEX encoding is mapped to a simple string, as the OPC specification does not include the XML Schema data type ``hexBinary'' that would be suitable for this encoding style. Another approach would be to re-encode the data into the Base64 encoding102. This approach would reduce the network load due to a reduced size of Base64 encoded data compared to BINHEX but would also increase the load on the IGUANA gateway due to the re-encoding.

Data types implemented by an OPC server have a certain range and precision. For example, a dateTime data type could be implemented as a UNIX timestamp which can only store dates between 1902 and 2038. [OPCXMLDA] specifies the minimum range and precision for OPC data types. In case the precision or the range is lower, the client must be informed about this fact. The OPC specification defines three specific properties for this task, called ``minimumValue'', ``maximumValue'' and ``valuePrecision''. In case the range is exceeded, the OPC server returns a specific ``E_RANGE'' error. If the precision of a value is higher than supported, the OPC server silently rounds it.

With the exception of the ``dateTime'' data type, all other canonical data types of an OPC Server on an IGUANA gateway support the default ranges and precisions. For these data types, the minimum, maximum and precision properties may be omitted. OPC Items of the data type ``dateTime'' have to provide the minimum and maximum properties, as depicted in figure 49.

Figure 49: Range Item Properties for the ``dateTime'' data type
\begin{figure}\centering
\includegraphics[scale=0.7]{graphics/xmlda-range.eps}\end{figure}

Values from OPC XML-DA compliant servers may be retrieved in various data types. For instance, the canonical data type of an OPC Item may be ``float'' and an application wants to retrieve this data as a ``string''. [OPCXMLDA] specifies which data conversions must be implemented. However, not all conversions have to be implemented for an IGUANA OPC server as it provides only a limited set of data types. Moreover, some data types such as ``duration'' cannot easily be implemented on the IGUANA Gateway as they have no corresponding counterpart. Such data types will be omitted. Figure 50 illustrates all necessary type conversions.

Figure 50: Data Conversions During a READ Requests from Canonical Data Types to the Requested Type
\begin{figure}\centering
\includegraphics[scale=0.6]{graphics/xmlda-dtype-conv.eps}\end{figure}


next up previous contents
Next: Addressing Scheme Up: Representing the IGUANA Interface Previous: Representing Datapoint Values with   Contents
Hermann Himmelbauer 2006-09-27