This plugin intends at converting PIVOT data from/to OPCUA north plugin.

The filter implements the Fledge Filter plugin interface (see filter_plugins).

Filter configuration

See Plugins configuration design for examples and details

The "config" parameter of  "plugin_init" call shall include :

• A "exchanged_data" category with the same content as provided to the OPCUA north plugin. This section is mandatory so that the filter plugin can convert the PIVOT type to OPCUA type.
  

Notes :

• All types not listed in this table are not supported in current version.
• The current implementation provides a default mapping rule for each known type, but some new rules might be added in the future and configured using the "alternate_mapping_rule" option in its parameters.

Filter interface

The "plugin_ingest" call will convert each "reading" of "reading_set" as follow:

• The Reading fields "id", "TimeStamp", "userTimestamp" and "asset_name" are unchanged.
• The Reading field "reading" is updated with an JSON object {'data_object' : {...}} . The content of object under 'data_object' is given below.

The <Root> key of PIVOT object can be:

In the following table: <type> is equal to

• "SpsTyp", "DpsTyp" (for GTIS)
• "MvTyp" (for GTIM)
• "SpcTyp", "DpcTyp", "IncType" or "ApcTyp" (for GTIC)

The "BscTyp" is not supported currently.

Type of data

The pugin can receive either PIVOT readings that are converted to OPCUA readings or receive OPCUA readings that are converted to PIVOT readings.

The plugin is not responsible for checking that the conversion matches its actual role: typically if the plugin is attached to a North OPCUA service, it will be expected to convert OPCUA to PIVOT, but will anyway convert PIVOT to OPCUA if receiving PIVOT instead of OPCUA as reading. This consistency must be ensured by configuration.

Thus the ruls for the conversion is:

• For each object in the reading:
  • If the object name is "PIVOT", convert the PIVOT reading to OPCUA
  • If the object name is "control_object", convert the OPCUA reading to PIVOT 

Converting monitoring data types

For TM/TS, the filter receives PIVOT reading (from south) and creates a corresponding OPC UA reading. The created OPCUA reading has the following JSON equivalent format:

{
   "data_object":{
      "do_cot": <int>,
      "do_confirmation": <int>,
      "do_comingfrom": <string>,
      "do_id":  <string>,
      "do_type":  <string>,
      "do_quality": <int>,
      "do_ts_quality": <int>,
      "do_value_quality": <string>,
      "do_source": <string>,
      "do_ts": <int>,
      "do_ts_org": <string>,
      "do_ts_validity": <string>,
      "do_value": <depends on data type...>
   }
}

The content under <Root> will convert the pivot to a opcua object as follow:

Converting commands data types

For TC, the filter receives OPCUA reading (from north) and creates a corresponding PIVOT reading. The created PIVOT reading format is given in FLEDGE WIKI.

The reading input is expected with the following JSON equivalent format:

{
   "control_object":{
      "co_type": <string>,
      "co_test": <int>,
      "co_ts": <int>,
      "co_se":  <int>,
      "co_negative":  <int>,
      "co_qu": <int>,
      "co_cot": <int>,
      "co_id": <string>,
      "co_value": <depends on data type...>
   }
}

TBC : Something does not work. The "do_value" (reply) will be sent by a south service, is it intended to be received as a full PIVOT value? What will be the reading sent from south to North in this case? Is it supposed to be a reading that is compatible with filter and opcua?.  And in that case, should we ignore all fields except "do_value" or create a full read-only variable set on the OPC server for each TC?

The content under <Root> will convert the OPCUA command objet to a pivot object as follow: