OPC UA for PROFINET Remote IO (see [
OPC RIO]) defines Channel Group Objects aggregating the IO Data of subordinated IO Channel Objects and organizing the channel Objects representing single IO Channels themselves. Figure 4 shows a Channel Group containing two output channel Objects, a configuration Object and Process Values.
From the Clients’ perspective, certain use cases when accessing a Channel Group Object become much more convenient and less error prone if compact representations of entire Object hierarchies or single subtrees are supported by the Server.
A Client might be interested in the Process Values provided in the “Values” array and the associated Process Value Qualifiers (see [
OPC RIO]) provided in the “Qualifiers” array. When using the “ChannelGroup” Object as SerializationStartNode (see “SerializationStartNode 1” in Figure 4), the “SerializationEntity 1” Object configures the “SerializationScope 1” by limiting the Variables belonging to the SerializationScope to those connected with HasRioProcessVariable References to the SerializationStartNode.
A Client only interested in the Channel Group configuration uses a compact representation of the components of the “ChannelGroupConfig” Object. The “SerializationEntity 2” configures a separate SerializationScope. This “SerializationScope 2” is defined using the “ChannelGroupConfig” Object as SerializationStartNode (see “SerializationStartNode 2” in Figure 4). When reading the Value of the “SerializedData 2”, Clients gain access to a consistent snapshot of the Values of all Properties which are components of the “ChannelGroupConfig” Object.
A Client only interested in the IO Data provided by channel Objects and their components uses a compact representation of the “OutputChannel_1” and “OutputChannel_2” Objects. “The SerializationEntity 3” Objects configure the “SerializationScope 3” by including only Objects connected with HasRioOutputChannel ReferenceTypes to the “ChannelGroup” Object used as SerializationStartNode as shown in Figure 4. Since the “ProcessValue” and “QualifierValue” Variables are part of this compact representation, reading the IO Data of all channels aggregated by the Channel Group Object using one single read operation is possible (see 6.3.6 and A.3 for explanations). This supports time consistency of the obtained IO Data.
The compact representation of these SerializationValues can be serialized into the JSON format by applying already established OPC UA encoding rules to support web Clients also.
OPC UA for PROFIenergy (see [OPC PE) specifies the structure of energy data provided by a Server as shown in Figure 5. The SerializationScope shown in Figure 5 comprises all MeasurementValueType Variables which are components of the EnergyMeasurementType Objects organized in the “EnergyManagement” Folder Object. The SerializationScope is configured to exclude the constant metadata contained in the Properties belonging to each MeasurementValueType Variable.
Figure 5 – PROFIenergy measurement values
When accessing the Value of the SerializedData Variable, a Client obtains all measurement values of all subordinated “Metering Point” Objects in one single read operation. This supports time consistency of the collection of measurement values the Client gains access to at once.
Especially in OPC UA PubSub scenarios, the transmission of semantic Properties like “EngineeringUnits”, “AccuracyDomain” and “PeMeasurementID” along with actual values is not desirable since this data does not change and can substantially increase the amount of transmitted data. Although the metadata constitutes an indispensable part of the data by enabling its correct interpretation, repeated transmissions of unchanged data are not necessary.
In a Client/Server scenario, Clients can obtain the metadata initially by separate browse and read operations. Metadata changes can be notified using ModelChange and SemanticChange Events.
When using Subscriptions, the Server can inform the Clients about metadata changes by setting the SemanticsChanged bit in the StatusCodes returned as part of data change Notifications. In PubSub scenarios, if the metadata of the subscribed DataSet changes, the Client receives a new ConfigurationVersion in the DataSetMetaData of the affected DataSet.
Considering possible application failure due to usage of outdated metadata, invoking the Read Service to obtain the Value of a merged compact representation not containing the associated metadata is appropriate for low-frequency data refresh scenarios imposing little additional bandwidth usage. If metadata change due to reconfiguring is possible, the metadata should be obtained by separate read accesses each time the Value of the merged compact representation is read.
Alternatively, the merged compact representation could be configured to contain the metadata in such scenarios. Another possibility is the establishment of Subscriptions comprising only the metadata(ModelChange or SemanticChange Events, see above).
To enable each of the possible scenarios for metadata handling outlined above, the SerializationScope can be adjusted in various ways (see chapter 6.2).