OPC-UA Alarm and Event Access
Alarm and condition module of OPC-UA server can be accessed using the alarm event source info.
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 |
Property MessageMappingFile | Not supported - use [OEM Message Mapping] |
Property MessageCount | Not supported - use [OEM Message Mapping] |
Property StartAddress | Not supported - use [OEM Message Mapping] |
Property MessageFormat | Not supported - use [OEM Message Mapping] |
Property Message:Type | Not supported - use [OEM Message Mapping] |
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
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.
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.
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.)
If you change the
MessageOffset
property and you have persisted raised alarms, these will never get removed.