| Re: [4diac-dev] Support for OPC UA events |
|
Hi Matthias, >
I used the SUBSCRIBE_1 FB I’d leave SUBSCRIBE_x (where x>=1) for data subscription as it is used in 4diac right now. Events do not carry any data
per se. So I still propose to reserve SUBSCRIBE/PUBLISH_0 for them. >
OPC UA statemachines are notifying there transitions with an EventType called TransitionEventType (or subtype, for example the ProgramTransitionEventType,
of it) According to OPC UA specs, both BasicEventType and TransitionEventType are abstract. My understanding is that you can
not have their instances in your OPC UA server address spaceWhat you have to do is to create your own transition types, modelled for your state machine(s), which inherit from TransitionEventType (and TransitionEventType is a BasicEventType, by definition).
ProgramTransitionEventType is also abstract. OPC UA Programs spec that uses them for Programs State Machine define 9 Transition types that extend ProgramTransitionEventType. That’s why I think, as written in the previous mail, that you have to subscribe to
a particular event type and have a separate SUBSCRIBE FB for every transition type, without a need to “demuxing” them. >
So the EventType for all transitionEvents is the same (i=2311 or subType of it), to distinguish which transition has happened, you have
to take a look on the Transition ID. Here is what OPC UA spec says about EventId and EventType: EventId is generated by the Server to uniquely identify a particular Event Notification. The Server is responsible
to ensure that each Event has its unique EventId. It may do this, for example, by putting GUIDs into the ByteString. Clients can use the EventId to assist in minimizing or eliminating gaps and overlaps that may occur during a redundancy failover. The EventId
shall always be returned as value and the Server is not allowed to return a StatusCode for the EventId indicating an error. EventType describes the specific type of Event. The EventType shall always be returned as value and the Server is not
allowed to return a StatusCode for the EventType indicating an error. I’d say, we need to look into the type, not Id. >
opc_ua[SUBSCRIBE_TRANSITIONEVENT;<uri>;<object>;<eventType>;<TransitionId>] I believe we can get rid of Id, then it’ll be exactly the syntax I’d propose for an Event and it’ll be quite generic for
all OPC UA Events. >
opc_ua[SUBSCRIBE_EVENT;<uri>;<object>;<eventType>;<browsePathToMember1>;<browsePathToMember2>;...]
What will be the browsePathToMemberX in this case? >
We could also setup a call the upcoming week, the event model of opc ua is quite complex. I’d be definitely interested in taking part. >
It would be interesting if such an "proxy statemachine FB" could be generated out of opc ua model of the statemachine. From my point
of view there is every information there which is need. But this is another story ;) Absolutely agree on literally every sentence here. Regards, Kirill From: 4diac-dev-bounces@xxxxxxxxxxx <4diac-dev-bounces@xxxxxxxxxxx>
On Behalf Of Matthias Konnerth Hi Kirill, thanks for the detailled feedback. Sry for confusing you, I was wrong, I used the SUBSCRIBE_1 FB, here's a image how it looks like at the moment: Object: /Objects/1:OpMode EventType: i=2311 (TransitionEventType) TransitionIds: i=5015 and i=5019 The transition Ids are mapped to to RD_1 if Eventype ==2311 and TransitionId i=5015 then RD_1=0, if EventType ==2311 and TransitionId=5019 RD_1=1, otherwise the event is skipped.
I agree with you, that there should not be a fb for a statemachine. Now it gets interesting: OPC UA statemachines are notifying there transitions with an EventType called TransitionEventType (or subtype, for example the ProgramTransitionEventType, of it):
So the EventType for all transitionEvents is the same (i=2311 or subType of it), to distinguish which transition has happened, you have to take a look on the Transition ID. You can get this Transition ID when build subscribe for the event data when you explicitly specify that you want this data. So I think, the interface for subscribing to TransitionEvents could look like this: opc_ua[SUBSCRIBE_TRANSITIONEVENT;<uri>;<object>;<eventType>;<TransitionId>] That means it's no generic event implementation. The interface for a generic event implementation would like: opc_ua[SUBSCRIBE_EVENT;<uri>;<object>;<eventType>;<browsePathToMember1>;<browsePathToMember2>;...] and then map the eventData from the field browsePathMember1 to RD_x. But this get's quite complex, for example the Type of the TransitionId is a NodeId, you would have to find a way to represent a NodeId in forte. So I would vote for the SUBSCRIBE_TRANSITIONEVENT. We could also setup a call the upcoming week, the event model of opc ua is quite complex. PS: It would be interesting if such an "proxy statemachine FB" could be generated out of opc ua model of the statemachine. From my point of view there is every information there which is need. But this is another story ;) Am So., 19. Apr. 2020 um 00:29 Uhr schrieb Kirill Dorofeev <dorofeev@xxxxxxxxxxx>:
-- Matthias Konnerth |
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
