Figure A.1 shows the SerializationValue DataType structure generated by the Server for a SerializationScope with a Variable having other Variables as components, and one of these Variables also has Variables as components. The illustration shows how the descend into the depth of the subtree originating from the SerializationStartNode causes the SerializationValue DataType to exhibit nested sub-structures mapping the corresponding part of the subtree.

On top level, the Value of “MyVariable” is mapped into the “Value” field, whereas the components of “MyVariable” are mapped into the MyVariableChildrenDataType “Children” field. Since each field of this structure represents one component of “MyVariable”, the two fields are “Variable1” and “Property1”. Since “Variable1” has itself children, it is represented by the Variable1DataType structure with an Int32 “Value” field for the Value of “Variable1” and a Variable1ChildrenDataType “Children” field for the descendants of “Variable1”. This “Children” structure field has an Int32 “Variable1.1” field representing the Value of “Variable1.1” and a Duration “Property1.1” field representing the Value of “Property1.1”.

If all sub-components in turn had sub-components themselves (great depth of the subtree), the recursive descend when constructing the SerializationValue DataType is limited by the SerializationConfiguration (e.g. SerializationDepth Property, see 6.3.5), by limitations of the structure DataType or finally by the Server resources.

Figure A.1 – Nested SerializationFieldDataTypes for subtrees

Figure A.2 shows how a set of Properties belonging to a single Object as SerializationStartNode are serialized into the SerializationValue DataType, and how this DataType is serialized by the JSON encoder.

If the SerializationProperties have default values, the Properties of the ChannelGroupConfig Object (see

OPC RIO) are mapped into fields of the SerializationValue DataType which have the same DataType as the Property they represent. The JSON encoding of this structure only contains the field names as keys and the Values of the serialized fields as JSON literals when using VerboseEncoding (see OPC 10000-6) and RawData field encoding (see OPC 10000-14) in a PubSub scenario. The Enumeration Values are encoded as string literals as specified in OPC 10000-6.

Figure A.2 – JSON encoding of SerializationValue DataType Structure

Figure A.3 shows how Process Values (see

OPC RIO) belonging to RioChannelType Objects are mapped into the SerializationValue DataType.

The “SerializationEntity” referenced by the SerializationStartNode directs the SerializationProcess to follow only HasRioOutputChannel ReferenceTypes. Although the SerializationDepth is configured as “no limit” (see 6.3.5), the SerializationProcess would stop as soon as a RioChannelType Object is reached, since these Objects only have components referenced using the HasComponent ReferenceType. To include the components of the RioChannelType Objects into the SerializationScope, each Channel Object references a “SerializationEntity” Object which has the IncludeReferenceType array Property containing the HasComponent ReferenceType. The ConsiderSubElementSerializationProperties SerializationProperty of the “SerializationEntity” (see 6.3.6) referenced by the SerializationStartNode causes the settings of the “SerializationEntity” Objects referenced by the Channel Objects to be applied, effectively extending of SerializationScope with all components of the subtrees originating from the Channel Objects.

The JSON snipped shows how the Values in the SerializationScope are serialized using VerboseEncoding (see OPC 10000-6) and RawData field encoding (see OPC 10000-14) in a PubSub scenario.

In Figure A.3 the details of the generated QualifierValueStructureDataType structures are not shown in the table visualizing the nested structure DataTypes, whereas the JSON snippet shows these structures in-depth.

Figure A.3 – RIO Channel Process Values

Figure A.4 shows a SerializationScope configured to exclude the metadata Properties of the Objects and Variables reachable from the SerializationStartNode.

The EnergyMeasurementType Object has a mandatory PeObjectNumber Property which is not part of the SerializationScope since the ExcludeReferenceTypes SerializationProperty contains the HasProperty ReferenceType. The same applies to the PeMeasurementID, AccuracyDomain, AccuracyClass and EngineeringUnits Properties of the MeasurementValueType Variables (see OPC PE) The SerializationValue DataType structure contains only fields for the Values of the MeasurementValueType Variables.

The JSON snipped shows how the energy data in the SerializationScope are serialized using VerboseEncoding (see OPC 10000-6) and RawData field encoding (see OPC 10000-14) in a PubSub scenario.

Figure A.4 – PROFIenergy Energy Measurement Values

Figure A.5 shows how semantic Properties (see 5.3 also) can be added to the FieldMetaData structure (see OPC 10000-14) describing the SerializedData Variable if added to a DataSet.

As shown in A.4, the SerializationConfiguration excludes the metadata Properties attached to the EnergyMeasurementType Objects as well as to the MeasurementValueType Variables. The metadata can be conveyed to a PubSub Subscriber by coding this information into the Properties field of the FieldMetaData structure (see 6.3.7). If PubSub is configured accordingly, the information is available for the Subscriber through a DataSetMetaData Message.

Figure A.5 – Semantic Properties in the FieldMetaData

Figure A.6 shows the resulting JSON encoding for the Properties field of the FieldMetaData structure according to Figure A.5 in A.5.

The amount of metadata associated with the ‘pure’ data exceeds the data values it describes by far (the JSON snippet only shows the metadata for 2 Variables), demonstrating the usefulness of excluding the metadata from the SerializationScope especially for low-bandwidth requirements.

Figure A.6 – JSON encoding of FieldMetaData Properties

Figure A.7 shows a SerializationScope configured by the SerializationEntity referenced by the “EnergyManagement” folder (see OPC PE) which is modified by a second SerializationScope.

The ConsiderSubElementSerializationProperties SerializationProperty set to true directs the SerializationProcess to evaluate the SerializationProperties of the SerializationEntity Object referenced by the “MeasurementY1” Variable, which is already part of the “enveloping” SerializationScope.

The IncludeStatus SerializationProperty of this second SerializationEntity is set to true, causing the StatusCode of the “MeasurementY1” Variable Value to be part of the SerializationValue DataType.

The ExcludeReferenceTypes array containing one element with the value HasProperty ReferenceType excludes all Properties of the “MeasurementY1” Variable.

The JSON snipped shows how the resulting SerializationValue structure DataType is serialized using VerboseEncoding (see OPC 10000-6) and RawData field encoding (see OPC 10000-14) in a PubSub scenario. If the StatusCode of the “MeasurementY1” Variable Value is Good, an empty “Status” is generated by the encoder. If the StatusCode is Uncertain or Bad, the StatusCode and the corresponding symbol are generated by the encoder, as shown in Figure A.7. In contrast, the StatusCode of the “MeasurementX1”, “MeasurementX2” and “MeasurementXn” Variable Values is never encoded into JSON.

Figure A.7 – Combining Serialization Scopes

_________