5.6 DataTypes

5.6.1 Overview

Following is a description of the DataTypes defined in this specification.

DataTypes like String, Boolean, Double or LocalizedText are defined in OPC 10000-3. Their representation is specified in OPC 10000-5.

5.6.2 Range

This structure defines the Range for a value. Its elements are defined in Table 19.

If a limit is not known a NaN shall be used.

Its representation in the AddressSpace is defined in Table 20.

5.6.3 NumberRange

This structure defines the NumberRange for a value. Its elements are defined in Table 21.

If a limit is not known

In case of Floating-Point DataTypes: a NaN shall be used

In case of Integer DataTypes: minimum or maximum value of the DataType should be used, e.g. Byte: 255

Its representation in the AddressSpace is defined in Table 22.

5.6.4 EUInformation

5.6.4.1 General

EUInformation contains information about the EngineeringUnits.

The intention of the OPC UA standard is not to define a set of units but a way to expose units based on existing systems. Since there is not a single worldwide set of units used in all industries, the EUInformation structure includes a separate field (the namespaceUri) to identify the system on which the exposed unit is based.

The default OPC UA mapping is based on UN/CEFACT as defined in 5.6.4.4, because it can be programmatically interpreted by generic OPC UA Clients. However, the EUInformation structure has been defined such that other standards bodies can incorporate their engineering unit definitions into OPC UA. If Servers use such an approach, then they shall identify this standards body by using a proper URI in EUInformation.namespaceUri.

5.6.4.2 Extented Unit information and Quantity

Servers can enhance EUInformation by providing the Quantity and Unit model (see 6) and referencing from EUInformation instances to the appropriate instances for quantity and unit. See Figure 5 for an example.

5.6.4.3 Definition of EUInformation

The EUInformation elements are defined in Table 23.

Its representation in the AddressSpace is defined in Table 24.

5.6.4.4 Mapping of UN/CEFACT to EUInformation

This clause specifies how to apply the “Codes for Units of Measurement” published by the “United Nations Centre for Trade Facilitation and Electronic Business” (see UNECE). This recommendation establishes a single list of code elements to represent units of the International System of Units (SI Units) like units of measure for length, mass (weight), volume and other quantities and in addition covers administration, commerce, transport, science, technology, industry etc. It provides a fixed code that can be used for automated evaluation.

Table 25 contains a small excerpt of the relevant columns in the UNECE recommendation:

The UNECE recommendation in several cases defines multiple instances of the same unit (same name and symbol) for different quantities. Therefore, the relevant information for EUInformation.unitId, EUInformation.displayName, and EUInformation.description has been extracted by eliminating duplicates. This extract is available here:

https://reference.opcfoundation.org/files/UNECE_to_OPCUA.csv?u=http://opcfoundation.org/UA/

This mapping has been generated as follows:

• The namespaceUri shall be http://www.opcfoundation.org/UA/units/un/cefact

• The Common Code (represented as an alphanumeric variable length of up to 3 characters) has been converted into a 32 Bit Integer and is used for the unitId. The following pseudo code specifies the conversion algorithm:

		Int32 unitId = 0;		Int32 c;		for (i=0; i<=3;i++)		{
			c = CommonCode[i];		if (c == 0) break;		// end of Common Code		unitId = unitId << 8;		unitId = unitId | c;	}

• The Symbol field shall be used as invariant locale for displayName. Servers can configure multiple additional locales for each displayName. However, if none of the LocaleIds specified by the Client for the Session matches these additional locales, the Server shall return the invariant locale.

• The Name field shall be used as invariant locale for description. Servers can configure multiple additional locales for each description. However, if none of the LocaleIds specified by the Client for the Session matches these additional locales, the Server shall return the invariant locale.

5.6.4.5 Mapping of IEC 62720 to EUInformation

This clause specifies how to apply the Common Data Dictionary (IEC CDD) published as IEC/TS 62720 by the “International Electrotechnical Commission - IEC” to the EUInformation Structure.

The units and their identifiers, along with their relationships, is maintained in the IEC Common Data Dictionary (CDD): https://cdd.iec.ch/cdd/iec62720/iec62720.nsf/TreeFrameset. Specific units can only be found via search. A ‘*’ as search string will return all units.

Figure 6 specifies the dialog to search for units and optionally export them.

Table 25 contains a small excerpt of the relevant columns in IEC 62720:

All units in the IEC CDD have been extracted and mapped to the EUInformation fields. The list is available here:

https://reference.opcfoundation.org/files/IEC62720_to_OPCUA.csv?u=http://opcfoundation.org/UA/

This mapping has been generated as follows:

• The namespaceUri shall be http://www.opcfoundation.org/UA/units/cdd/IEC62720

• The Code is the data identifier of the IRDI. It is represented by 3 uppercase characters and 3 digits. This code has been converted into a 32-Bit Integer and is used for the unitId. The following pseudo code specifies the conversion algorithm:

	Int32 unitId = 0;	Int32 c;	for (i=0; i<6;i++)	{
		c = UnitCode[i] 0x1f;	 	unitId = unitId << 5;		unitId = unitId | c;	}
		

• The Short Name field shall be used as invariant locale for displayName. Servers can configure multiple additional locales for each displayName. However, if none of the LocaleIds specified by the Client for the Session matches these additional locales, the Server shall return the invariant locale.

• The Preferred Name field shall be used as invariant locale for description. Servers can configure multiple additional locales for each description. However, if none of the LocaleIds specified by the Client for the Session matches these additional locales, the Server shall return the invariant locale.

5.6.5 ComplexNumberType

This structure defines float IEEE 32 bits complex value. Its elements are defined in Table 27.

Its representation in the AddressSpace is defined in Table 28

5.6.6 DoubleComplexNumberType

This structure defines double IEEE 64 bits complex value. Its elements are defined in Table 29.

Its representation in the AddressSpace is defined in Table 30.

5.6.7 AxisInformation

This structure defines the information for auxiliary axis for ArrayItemType Variables.

There are three typical uses of this structure:

1. The step between points is constant and can be predicted using the range information and the number of points. In this case, axisSteps can be set to NULL.

2. The step between points is not constant, but remains the same for a long period of time (from acquisition to acquisition for example). In this case, axisSteps contains the value of each step on the axis.

3. The step between points is not constant and changes at every update. In this case, a type like XYArrayType shall be used and axisSteps is set to NULL.

Its elements are defined in Table 31.

Its representation in the AddressSpace is defined in Table 32.

When the steps in the axis are constant, axisSteps can be set to “Null” and in this case, the Range limits are used to compute the steps. The number of steps in the axis comes from the parent ArrayItem.ArrayDimensions.

5.6.8 AxisScaleEnumeration

This enumeration identifies on which type of axis the data shall be displayed. Its values are defined in Table 33.

Its representation in the AddressSpace is defined in Table 34.

5.6.9 XVType

This structure defines a physical value relative to a X axis and it is used as the DataType of the Value of XYArrayItemType. For details see 5.3.4.3.

Many devices can produce values that can perfectly be represented with a float IEEE 32 bits but, they can position them on the X axis with an accuracy that requires double IEEE 64 bits. For example, the peak value in an absorbance spectrum where the amplitude of the peak can be represented by a float IEEE 32 bits, but its frequency position required 10 digits which implies the use of a double IEEE 64 bits.

Its elements are defined in Table 35.

Its representation in the AddressSpace is defined in Table 36.