Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • 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:

...

  • While converting from PIVOT to OPCUA, the PIVOT object is "standalone" and the plugin does not need any configuration from this transformation. The "Exchanged Data" section is only used by conversion from OPCUA to PIVOT.

Filter interface

The <Root> key of PIVOT object can be:

Reading keyContent
PIVOT.GTISTele Signal
PIVOT.GTIMTele Measurement
PIVOT.GTICTele ControlNot supported

In the following table: <type> is equal to

...

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 rules for the conversion is:

  • For each object in the reading is modified as follow:
    • If the object name is "PIVOT" and contains the "GTIM"or "GTIS" key, then the reading must be converted from a PIVOT object to an OPCUA "data object".
    • If the object name is "PIVOT" and contains the "GTIC" key, then the reading must be converted from a PIVOT object to an OPCUA "reply object"., convert the PIVOT reading to OPCUA
    • If the object name is "controlopcua_objectoperation", convert the OPCUA reading to PIVOT then the reading must be converted from an OPCUA control request (operation) to a PIVOT object.
    • Otherwise the reading is not modified.

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"):

Code Block
languagepy
{
   "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...>
   }
}

...

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:

Code Block
languagepy
{
   "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:

Converting commands implies two different use case:

  • While sending a Fledge "operation" (from North to South). In that case the filter converts an operation with asset_name = "opcua_operation" into a "PIVOTTC" object with an asset_name = "PivotCommand".
  • While receiving an acknowledgement for a previous "operation" (from South to North).  In that case, the filter converts a "PIVOT.GTIC" into a "opcua_reply" object.

The conversion rules are details below.

Conversion from opcua_operation to PIVOT.GTIC

tsTBCBooleanfalsese<Root>Confirmation.stValFloatFor SpcTypTBC!!  same as above
opcua_operation.<...>PIVOT field ("PIVOT.GTIC".<...>)TypeDefault valueNote
co_idIdentifierString
PIVOT identifier.
co_seSelect.stValBooleanfalse

- 0 is mapped with false, for Execute

- 1 is mapped with true, for Select before Execute

N.A.ComingFromString"opcua"This plugin always uses the value "opcua" when converting to PIVOT
co_type<type>String

"opcua_spc" | "opcua_dpc".

co_test
KeyTypeDefault valueopcua.control_object.<...>Note
<Root>.IdentifierStringco_idPIVOT identifier.<Root>.<type>Stringco_type

(see <type> conversion table above)

<Root>.<type>.q.testBooleanfalse
co_testts<Root>.<type>.t.SecondSinceEpochInteger

co_value

ApcTyp.ctlVal

Float
Float 32
co_value

DpcTyp.

ctlVal

Booleanco_negativeTBCBooleanfalseco_qu<Root>.ComingFromString"opcua"N.A.<Root>.Cause.stValIntegerco_cotSee Cause of TransmissionString
intermediate-state | off | on | bad-state
co_valueIncTyp.ctlValInteger
Int 32
co_valueSpcTyp.ctlValBoolean
0 or 1

<Root>.ApcTyp.ctlVal

co_valueFor ApcTyp<Root>.ApcTyp.mxValFloatdo_value

For ApcTyp

TBC!! This cannot be part of the reading sent from north to south.
Instead the do_value should be a "normal" TS/TM PIIVT data

<Root>.DpcTyp.ctlVal

Stringco_valueFor DpcTyp<Root>.DpcTyp.mxValStringdo_valueFor DpcTyp TBC!!  same as above<Root>.IncTyp.ctlValIntegerco_valueFor IncTyp<Root>.IncTyp.stValIntegerdo_valueFor IncTypTBC!!  same as above<Root>.SpcTyp.ctlValBooleanco_valueFor SpcTyp<Root>.SpcTyp.stValBooleando_valueBscTyp.ctlValString
stop | lower | higher | reserved

Conversion from PIVOT.GTIC to "opcua_reply"

PIVOT field ("PIVOT.GTIC".<...>)opcua_reply fieldTypeDefault valueNote

Identifier

ro_idString
PIVOT identifier.
Confirmation.stValro_replyBoolean

Converts the values as follow:

  • confirmation.stval = false then ro_reply = 0 (positive confirmation)
  • confirmation.stval = true then ro_reply = 1 (negative confirmation)
<All other fields are ignored>