Log In
Register
Forum
Topic RSS
12:37, EET
November 11, 2020
Offline
Hello,
(this topic is actually related to both the UA Converter and the UA Client SDK)
I am using the following configuration:
– One or more backend DA and/or A&E servers
– The Prosys UA Gateway
– A UA Client that I am developing using the Prosys UA Client SDK for Java.
I have everything working fine, events arrive at my client, except that I am requested to distinguish between Simple, Trace and Condition events coming from the A&E servers. I did find code (whereClause) with which one can have an event listener filter on event type, but I need to know how the Converter maps A&E events to UA EventTypes, and what the properties of the EventTypes are if not specified by the UA standard.
Using a UA Client of a competitor (just because I had it lying around) I see in the UA Converter the following subtypes of BaseTypeEvent: ComAeSimpleEventType, TraceEventType and ConditionType. The naming suggests that the A&E events are resp. mapped to those types, but is that in fact the case?
And, if so, how do I find the NodeId of those types? For UA standard types the SDK (like ConditionType) provides predefined NodeId’s but not for the subtypes that were specially added (or so it seems) for the Gateway, the simple and trace types. I need the NodeIds to configure the event listener filter.
And then, of course, what are the additional properties of those special types. Unfortunately the competitor’s UA Client doesn’t allow me to browse those subtypes, so I cannot look them up myself. Or should I use another UA Client?
19:25, EET
November 11, 2020
Offline
Meanwhile I made some progress…
Using the Prosys UA Client, also used to configure the Gateway, in the Address Space tab, I could properly browse the Types tree and I found three event Types that are named like they represent the three types of A&E Events:
– ComAeSimpleEventType
– ComAeTrackingEventType (subtype of AuditEventType)
– ComAeConditionEventType (subtype of ConditionType/AcknowledgeableConditionType/AlarmConditionType)
And with it I also found their NodeId and properties. First problem solved.
Q1: Can I assume these NodeIds are stable, like the predefined NodeId for BaseEventType found in the SDK?
I also have some questions about how A&E event data is mapped to those types/properties (assuming they are):
Q2: EventType is a property of BaseEventType. The value is a NodeId. Sample node names I’ve seen are: Condition.Level1, Tracking.Level4. It seems these values are a composition of the A&E event type (Condition, Simple, Tracking) and the category (Level1,…,Level4). Can someone confirm this?
Q3: All ComAe… event types have a property EventCategoryId (same ns, but different numerical IDs). When I try to read them I always get null. Is that property simply never filled or am I addressing it badly? With Java SDK you specify a property by namespace+name, which in this case is not unique (see numerical IDs).
Q4: A classic A&E Condition event has a “AckRequired” attribute. I don’t see anything like it in the ComAeConditionEventType type. Is it not supported?
Q5: A classic A&E Condition event has a “Subcondition” attribute; the ComAeConditionEventType has “SubconditionName”. Similar to resp. “Condition” and “ConditionName”. ConditionName is filled by the Gateway correctly, but SubconditionName remains empty (although in the source it is present). Would this be a Gateway bug or?
11:25, EET
April 3, 2012
Offline
Hi,
I would like to clarify that we did answer to the first post by email (and also just now to the second one by mail, that should help with some of the questions).
For anyone other reading this later, I should also clarify for the “Prosys OPC UA Gateway” part (https://www.prosysopc.com/products/opc-ua-gateway/), it is the same as https://www.unified-automation.com/products/wrapper-and-proxy/uagateway.html, which we resell (and give support), i.e. there are no 2 separate UaGateway applications.
It might be better to ask the OPC UA related questions for the SDK within https://forum.prosysopc.com/forum/opc-ua-java-sdk/. In general, the old classic OPC has nothing to do with OPC UA (basically just the letters “OPC” are the same and that’s about it), so this question is a combination of 2 different technologies and an application doing conversion between them. That is to say, from OPC UA’s point of view the gateway is just an OPC UA Server and behaves as such (by the OPC UA Specification).
I personally can only help with our Java SDK questions, thus to the Q3 part:
Q3:
If you are doing a raw Read/Browse operation (via UaClient.readXXX or AddressSpace.browseXXX), you do it using the NodeId Attribute of the node, which uniquely addresses it within the address space.
IF you have fetched the node as an UaNode instance, the SDK does Read and Browse the node for you. If you then want to get the Components or Properties of that node, you use the BrowseName Attribute, which is a QualifiedName, which has a namespace index and a name part. The namespace of the BrowseName can be different than the NodeId.
Typically you do fetch a node that has it’s sub-node-structure defined by the HasTypeDefinition Reference from the node and thus it fixes some of the nodes it has, thus the BrowseNames are used. In addition, the NodeIds in general are not that well known for the sub-structure, and they would be different for each instance anyway typically, but the BrowseNames must match the TypeDefinition’s ones.
Node’s Properties must be unique (by the OPC UA Specification), https://reference.opcfoundation.org/v104/Core/docs/Part3/4.4.2/ “To easily identify Properties, the BrowseName of a Property shall be unique in the context of the Node containing the Properties”
Components do not have to be unique, there can be more than a single node referenced with HasComponent having the same BrowseName. However it should be noted that a TypeDefintion cannot have more than one (it is a long explanation), thus basically an EventType within it’s TypeDefinition must always have unique BrowsePaths if following Hierarchical ReferenceType’d references starting from the top-lvl TypeDefinition node. But technically an instance of that type later could have (but it would be really confusing, and I could check if the specification forbids that).
Also for the Q1 I guess I can say this. From OPC UA’s perspective, the NodeIds of Type nodes and their InstanceDeclarationHierarchy (the TypeDefintion node+all subnodes,i.e. InstanceDeclarations) should stay the same. It is possible that e.g. a future information model version update e.g. adds Optional ModellingRule’d InstanceDeclarations to a TypeDefinition, but otherwise changing of NodeIds would be equivalent to making a new type.
Also it should be important to note, that both NodeId and QualifiedName use the NamespaceIndex. They can change, the the Root/Objects/Server/NamespaceArray changes, but the NamespaceUri should be the same always. Therefore after a restart, the index could be different, but it should map to the same NamespaceUri that it did before via the NamespaceArray (the NamespaceIndex is the index within that array and the value for the index is the NamespaceUri). The SDK does contain nowadays classes UaNodeId and UaQualifiedName, that we did to help the situation, but is partially an ongoing issue still. They can be converted within a NamespaceTable to the NodeId and QualifiedName. That is to say, when storing a configuration, you should always store them with an NamespaceUri and not index, unless you also create a special “configuration NamespaceTable” to go with them to map them to uris when loading the configuration. Probably this might need a better explanation, ask if needed.
14:09, EET
June 3, 2019
Offline
Meanwhile I made some progress…
Using the Prosys UA Client, also used to configure the Gateway, in the Address Space tab, I could properly browse the Types tree and I found three event Types that are named like they represent the three types of A&E Events:
– ComAeSimpleEventType
– ComAeTrackingEventType (subtype of AuditEventType)
– ComAeConditionEventType (subtype of ConditionType/AcknowledgeableConditionType/AlarmConditionType)
Just to confirm, this is correct.
And with it I also found their NodeId and properties. First problem solved.
Q1: Can I assume these NodeIds are stable, like the predefined NodeId for BaseEventType found in the SDK?
I also have some questions about how A&E event data is mapped to those types/properties (assuming they are):
The nodeIds for event types should be stable.
For mapping, basically the UA Gateway queries both event categories and event attributes. These are then used to create subtypes and properties on the UA server respectively.
Q2: EventType is a property of BaseEventType. The value is a NodeId. Sample node names I’ve seen are: Condition.Level1, Tracking.Level4. It seems these values are a composition of the A&E event type (Condition, Simple, Tracking) and the category (Level1,…,Level4). Can someone confirm this?
Correct
Q3: All ComAe… event types have a property EventCategoryId (same ns, but different numerical IDs). When I try to read them I always get null. Is that property simply never filled or am I addressing it badly? With Java SDK you specify a property by namespace+name, which in this case is not unique (see numerical IDs).
Answered by Bjarne above.
Q4: A classic A&E Condition event has a “AckRequired” attribute. I don’t see anything like it in the ComAeConditionEventType type. Is it not supported?
Q5: A classic A&E Condition event has a “Subcondition” attribute; the ComAeConditionEventType has “SubconditionName”. Similar to resp. “Condition” and “ConditionName”. ConditionName is filled by the Gateway correctly, but SubconditionName remains empty (although in the source it is present). Would this be a Gateway bug or?
Will relay these back to the developers. The Q5 does look like a bug.
Aku Viitanen
Prosys OPC
20:05, EET
November 11, 2020
Offline
Thank you for your answers. They help a lot. I think I understand most of it now.
I posted my questions here because most are tied tightly to the UA Gateway.
Anyway, some remarks:
Ad Q2: I missed the fact that the three ComAe… event types actually have subtypes for each of the categories supported by the A&E server. EventType is a NodeId that refers to one those subtypes (not the ComAe.. types). The EventType’s display name is the name of the category.
Ad Q3: I am listening for events. I do not use read or browse operations, but simply add static browse-paths to the selectClauses for the properties I am interested in. As I found somewhere in the UA documentation, those browse paths are relative, which answers my question about uniqueness.
The point Bjarne makes about varying namespace-indices is what I suspected, but have not addressed yet in my code. I will.
Regarding the EventCategoryId: I found I was using the wrong namespace. Having corrected that I now see values for that propety for Tracking and Simple events, only not for Conditions. As the property is not inherited, it seems to be a bug as well.
Ad Q5: I found this document (https://reference.opcfoundation.org/v104/Core/docs/Part9/D.3.5/) suggesting that the subcondition can be found in ActiveState/EffectiveDisplayName. However I get no value there either.
So all SDK questions are answered and what remains is for the UA Gateway developers. They are all only relevant for Condition events. To sum them up:
1. (remainder of Q3) EventCategoryId is not filled for Condition events
2. (former Q4) Is AckRequired supported and, if so, how?
3. (former Q5) SubconditionName is not filled, nor can I find any other property that would contain the value.
Reinier van den Born
TriOpSys (NL)
16:16, EET
April 3, 2012
Offline
Regarding Q3, this is a a guess, but are you using anything else than Identifiers.BaseEventType for the SimpleAttributeOperand’s typeDefinitionId?
That could be the issue, though if so I would have either assumed only 1 success (not using the BaseEventType wildcard) or all of them (wildcard used), so it is possible that it is a bug.
Anyway, the specification states in https://reference.opcfoundation.org/v104/Core/docs/Part4/7.17.3/, that:
“In some cases the same BrowsePath will apply to multiple EventTypes. If the Client specifies the BaseEventType in the SimpleAttributeOperand then the Server shall evaluate the BrowsePath without considering the Type.”
In general, as far as I’m aware, our own applications always just use the BaseEventType when defining a filter. But technically it would be possible for a 2 different inheritance trees to define the same Property (as in the same QualifiedName as BrowseName) with a different DataType (e.g. String vs Int32), and thus you could define 2 different SimpleAttributeOperands that would capture both Properties (basically one of them would always be null and the other could have the value, depending which event type it was, assuming you have not filtered the event types with the filter’s whereClause). But in this case there are 3 different Properties defined, but they all use the same UInt32 DataType, thus defining it with the BaseEventType should “capture” it for all of them.
16:19, EET
June 3, 2019
Offline
Hello, we have some developments for this issue:
So all SDK questions are answered and what remains is for the UA Gateway developers. They are all only relevant for Condition events. To sum them up:
1. (remainder of Q3) EventCategoryId is not filled for Condition events
Bjarne gave an answer to this what could help from the SDK side. In case it did not help, do you have problems with any other properties of this event type, since Q5 issued seemed similar to this one.
2. (former Q4) Is AckRequired supported and, if so, how?
This functionality can be found in BaseEventType->ConditionType->AcknowledgeableConditionType->AckedState variable. When it is set to false that means you can. acknowledge it.
3. (former Q5) SubconditionName is not filled, nor can I find any other property that would contain the value.
The developer is looking in to this issue. The value should be in SubConditionName property.
Aku Viitanen
Prosys OPC
18:34, EET
November 11, 2020
Offline
Hello again,
Thanks for your thoughts.
Regarding Bjarne’s remark: I am using Identifiers.BaseEventType. I build a single filter configuration for all event types. This is what it roughly looks like:
NodeId eventTypeId = Identifiers.BaseEventType;
UnsignedInteger eventAttributeId = Attributes.Value;
….
new SimpleAttributeOperand(eventTypeId, qName, eventAttributeId, null);
where qname the qualified name/path of the property I am interested in. I coulld try building separate filters for each of the event types. Apart from adding a WhereClause should I then use the resp. ComAe…Type for the eventTypeId to force the correct property to be found?
Or can I, instead of a qualified browse path, use a namespace+numeric node ID, in a selectclause?
About AckRequired: that (should the event be acknowledged) is not the same thing as AckedState (has the event been acknowledged or not). In classic OPC the latter is encoded, together with Enabled and Active, in the NewState property.
I remember reading somewhere that the idea in OPC UA is to use different event types to distinguish between events that need to be and events that may be acknowledged. Which makes sense. But then of course you’d expect the UA Gateway to provide two ComAeCondition.. event types,
I hope there is no confusion about the name SubconditionName. According to what I see in ComAeConditionEventType I am using SubconditionName for the property name (with a lowercase c). I tried it with an uppercase C, of course, but that doesn’t make a difference.
Reinier van den Born
TriOpSys (NL)
17:41, EET
June 3, 2019
Offline
Hello,
We have some more developments for this case.
We were able to verify that the missing EventCategoryId for condition events is returning null in other client solutions as well, which leads us to believe the issue is with UA Gateway configuration or it is a bug. I have informed the developers about this and am double-checking with them if this can be caused by configuration of the UA Gateway. In case it is a bug, we are reporting it forward, but we cannot say when it can be fixed at this time.
Regarding AckRequired, I checked OPC UA specification and AckedState = False is considered to imply that acknowledgment is required. This means that if AckRequired = False, then AckedState should be True automatically. I tried to find the text about serving different event types for these use-cases, but came up short at least for UA specification and developer documentation. Perhaps this was a design difference? Anyway, let me know if AckedState is not being correctly set to True when AckRequired = False. Unfortunately since ComAeConditionEventType is having issues with other properties at the moment, this may be influenced as well.
I will update this thread when the situation develops.
Aku Viitanen
Prosys OPC
Most Users Ever Online: 518
Currently Online:
16 Guest(s)
Currently Browsing this Page:
1 Guest(s)
Top Posters:
hbrackel: 135
pramanj: 86
Francesco Zambon: 81
rocket science: 77
ibrahim: 75
Sabari: 62
kapsl: 57
gjevremovic: 49
Xavier: 43
fred: 41
Member Stats:
Guest Posters: 0
Members: 677
Moderators: 16
Admins: 1
Forum Stats:
Groups: 3
Forums: 15
Topics: 1467
Posts: 6259
Newest Members:
DonaldPooma, fidelduke938316, Jan-Pfizer, DavidROunc, fen.pang@woodside.com, aytule, rashadbrownrigg, christi10l, ahamad1Moderators: Jouni Aro: 1009, Otso Palonen: 32, Tuomas Hiltunen: 5, Pyry: 1, Petri: 0, Bjarne Boström: 983, Heikki Tahvanainen: 402, Jukka Asikainen: 1, moldzh08: 0, Jimmy Ni: 26, Teppo Uimonen: 21, Markus Johansson: 42, Niklas Nurminen: 0, Matti Siponen: 321, Lusetti: 0, Ari-Pekka Soikkeli: 5
Administrators: admin: 1
