OPC-UA Alarm and Event Access

Alarm and condition module of OPC-UA server can be accessed using the alarm event source info.

Alarm and Events from OPC-UA A&C

The address is the node id of the main object providing A&C.

{
  "AlarmEventPool": {
    "Id": "FA1611AB-B6C9-4FF4-B34D-BF35E6A44232",
    "Name": "AlarmEventPool",
    "Tasks": [
      {
        "Id": "E669AF07-0991-4A40-A7A4-9D2B2B881D07",
        "Name": "Standard Messages",
        "Address": "ns=2;g={ece37fdf-4862-4543-af23-48ffdb8203c7}"
      }
    ],
    "HistoryMode": {
      "Retention": 1,
      "SampleRate": 1000
    }
  }
}

Accessor	Description
Id	Unique Id for each task
Name	A name for the task
Address	Alarm address in opc ua
AdditionalAlarmTypes	Additional alarm event types, e.g. ns=8;i=39

Alarm Filters

Standard alarm types supported by this connector are:

• OffNormalAlarmType);
• SystemOffNormalAlarmType);
• AlarmConditionType);
• DiscreteAlarmType);
• ExclusiveLimitAlarmType);
• ExclusiveDeviationAlarmType);
• ExclusiveLevelAlarmType);

With the property AdditionalAlarmTypes additional event ids can be specified to be handled as alarms.

Example:

Following example subscribes the events from Machine1.Notification.Messages (umati). Additionally, the alarms are specified by node-id ns=8;i=39. All other events are handled as events only.

  "AlarmEventPool": {
    "Id": "526be8a8-8746-4839-a937-8faf3b979c49",
    "Name": "AlarmEventPool",
    "Tasks": [
      {
        "Id": "2fea134e-b0aa-4fee-b72a-c7a04252ab22",
        "Name": "AlarmTask",
        "Address": "ns=2;s=Machine1.Notification.Messages",
        "Properties": [
          {
            "Name": "AdditionalAlarmTypes",
            "DataType": "System.String",
            "Value": "ns=8;i=39"
          }
        ]
      }
    ]
  }

OEM Message Mapping

The driver supports PLC alarms by mapping source. It is possible to declare multiple alarm sources (tasks) for one alarm address (pool).

Following data types are possible as source address:

• System.Byte[]
• System.Byte
• System.Int16
• System.UInt16
• System.Int32
• System.UInt32
• System.Int64
• System.UInt64
• System.Single
• System.Double

This example shows three alarm sources with a mapping file:

  "AlarmEventPool": {
    "Id": "FA1611AB-B6C9-4FF4-B34D-BF35E6A44232",
    "Name": "AlarmEventPool",
    "Tasks": [
      {
        "Id": "66d0a44d-83e8-494d-9e15-5af16df60d55",
        "Name": "Alarm Messages",
        "Address": "OEMAlarmEvent",
        "Properties": [
          {
            "Name": "MessageMappingFile",
            "Value": "OEMBitMessages.json"
          },
          {
            "Name": "MessageCount",
            "Value": 8,
            "DataType": "System.Int32"
          },
          {
            "Name": "MessageOffset",
            "Value": 0,
            "DataType": "System.Int32"
          },
          {
            "Name": "SourceName",
            "Value": "OpcUa",
            "DataType": "System.String"
          },
          {
            "Name": "StartAddress",
            "Value": "ns=2;s=Demo.Static.Arrays.Byte"
          },
          {
            "Name": "MessageFormat",
            "Value": "BitMessage"
          },
          {
            "Name": "Message:Type",
            "Value": "Raise"
          }
        ]
      }
    ]
  }

Accessor	Description
Id	Unique Id for each task
Name	A name for the task
Address	Alarm address (pool) - always OEMAlarmEvent
Property MessageMappingFile	The mapping file to load (copy to .\Config\HumanOS.UHAL.OpcUaControl\)
Property MessageCount	Amount of messages which are mapped (depends on the Property MessageFormat)
Property MessageOffset	Alarm Id offset number - this is optional, default value is 0. See Message Offset
Property StartAddress	The corresponding source address with offset and length (depends on the Property MessageFormat)
Property MessageFormat	BitMessage or Channel32Message
Property Message:Type	Type of each message that occurs from this source

A property which starts with Message: is attached as property to the alarm item (e.g. message) which means additional fields are added with this data and can be used later on.

Mapping Bits

Given a value of 19'636, the bitwise assignment would look like this

NOTE

If a message is missing in the [Mapping file], nothing is processed (in this example message with id 27).

Mapping File

Mapping means, the alarms and events are defined by the data given and not the data that the alarm source provides.
The mapping source must be of type JSON and must be structured like this example:

{
  "Messages": [
    {
      "Id": 0,
      "AlarmType": "Alarm",
      "OemId": "Alarm 1",
      "Text": "PU Sammelfehler",
      "Properties": [
        {
          "Name": "MyProperty",
          "Value": "Some other info"
        },
        {
          "Name": "EnableRmq",
          "Value": "1"
        },
        {
          "Name": "EnableRest",
          "Value": "0"
        }
      ]
    }
  ]
}

Accessor	Description
Id	Specifies the bit number (absolute starting at 0)
AlarmType	Specifies the Alarm type, see Alarm Types in Alarm and Event Source
OemId	The Condition name of the alarm or event
Text	Specifies the message
Properties	Specify properties which are attached to this alarm or event and can later be accessed
Properties:Name	Property name
Properties:Value	Property value

Message Offset

The message offset is used to offset the alarm Id in the mapping file. The offset is independent of the message count. It can be any positive number.

NOTE

MessageOffset helps to maintain only one Mapping File for all alarm tasks by shifting the id offset.

Example

Lets look at this with an example. We have following configuration:

  "AlarmEventPool": {
    "Id": "FA1611AB-B6C9-4FF4-B34D-BF35E6A44232",
    "Name": "AlarmEventPool",
    "Tasks": [
      {
        "Id": "66d0a44d-83e8-494d-9e15-5af16df60d55",
        "Name": "Alarm Messages",
        "Address": "OEMAlarmEvent",
        "Properties": [
          {
            "Name": "MessageMappingFile",
            "Value": "OEMBitMessages.json"
          },
          {
            "Name": "MessageCount",
            "Value": 16,
            "DataType": "System.Int32"
          },
          {
            "Name": "MessageOffset",
            "Value": 32,
            "DataType": "System.Int32"
          },
          {
            "Name": "SourceName",
            "Value": "OpcUa",
            "DataType": "System.String"
          },
          {
            "Name": "StartAddress",
            "Value": "ns=2;s=Demo.Static.Arrays.UInt16[1]"
          },
          {
            "Name": "MessageFormat",
            "Value": "BitMessage"
          },
          {
            "Name": "Message:Type",
            "Value": "Raise"
          }
        ]
      }
    ]
  }

So, we are accessing the second UInt16 value (index 1) out of an array (here Demo.Static.Arrays.UInt16[1]). We want to map our oem data from the Mapping File at id 32-47 to that UInt16 value.

Normally, the mapper would start mapping our oem data from id 0 for every bit in our UInt16 value. Since we specified a MessageOffset though, it will start from the id 32 in our case.

The result is: All 16 bits from Demo.Static.Arrays.UInt16[1] are mapped the the oem messages with ids 32 to 47 from the Mapping File.

IMPORTANT

The MessageCount must be larger than 0 and smaller or equal to the maximum bits read by the StartAddress (in this case Uint16 has max. 16 bits for messages.)

IMPORTANT

If you change the MessageOffset property and you have persisted raised alarms, these will never get removed.