Reading Event MO by means of SmartREST

strasser.manfred · July 5, 2022, 4:29pm

Hi Community,
please see my following doubts.

What product/components do you use and which version/fix level?

Cumulocity
Backend: 1011.0.12
UI: 1010.0.24

Are you using a free trial or a product with a customer license?

License

What are trying to achieve? Please describe in detail.

We have installed communication between machine/gateway (south) and tenant (north) by means of the
thin-edge.io <–> MQTT bus <–> thin-edge-io Agent - solution.

In the gateway we need to read an Event MO from the tenant.
And we want to use SmartREST.
Further information - this Event MO gets transfered via OPC-UA channel from the machine/gateway to the tenant. In EPL it is manipulated and we need to read it back to the machine via MQTT/SmartREST (not OPC-UA!).

Is it possible?

Any input, idea how to implement this, is highly appreciated.
Thanks in advance.
BR Manfred

Philipp_Emmel · July 5, 2022, 4:58pm

In order to transfer information from the platform to a device we use operations. Technically it is possible to read event data from a device but then the device needs access to the event and it also needs to know when the data will be available. I would not recommend creating a solution like this because it will become a complex mess that works around our built in functionalities and our typical domain model.

Generally events are designed as fire and forget data that is sent by devices to the platform in order to convey some sort of information to users. Semantically it contains the information that something has happened on a device. We transport commands or information to devices using operations. Operations are triggered by users (or other components) to trigger an action on the device.

In your case I could imagine a solution that creates an operation from your EPL in addition to or instead of the existing process that you mentioned. Then you can create a SmartREST response template for the created operation and receive the data on the device as it occurs.

Murat_Bayram · July 6, 2022, 8:09am

Adding to Philipps Answer: Can you share a bit more about the use case? What do you want to achieve, what is you problem you are addressing with that? Maybe we can come up with an other solution here.

strasser.manfred · July 6, 2022, 2:32pm

Hello,
thank you for the answers so far.

I hope I can explain our use case so you have a better understanding:

The use case:
We have a machine state EVENT MO. This is sent from the machine and can have various values from 1 - x.
In EPL we combine multiple Events of the communication channel (OPC-UA, MQTT). If the result indicates a communication problem, we set MO=0.
Like this we get

0 = offline
1 = idle
2 = setup
… and so on

Now we want to read back this MO to the machine, to test / check the last segment of the complete communication circuit. In the end, the REST Server needs to receive a machine state information that is != 0. Then communication is OK.
If machine state received = 0, there is a problem in communication northbound.
If there is a timeout reading MO, there is a communication problem southbound.

We like the idea of using operations to transfer MO southbound.

What we need to achieve

Tenant (precisely: EPL)

Trigger the sending of MO from EPL e.g. every 5 minutes.
Trigger causes automatic transfer of operation by activating operation

PLC

expect to receive MO every 5 minutes
handle Timeout in case not (raise alarm)
evaluate MO in case yes ( = 0 → raise alarm)

Can you help me out with information about the Tenant / EPL part?

Is it possible to have a “time-trigger”, e.g. every 5 min do something?
Can we initiate/start an operation (to transfer MO) inside EPL?

If it is 2 x yes, we know how to continue.

Thank you very much.

Manfred

Murat_Bayram · July 8, 2022, 8:03am

Hi Manfred,

some questions:

#1 You mark thin-edge as on tenant side, that’s confusing. thin-edge is running locally right?

#2 Which architecture in terms of communication do you use:

A) Every device within the local network communicates standalone to Cumulocity

B) There is a parent device that handles the communication

For Apama and triggers see their documentation about time triggers: Link

strasser.manfred · July 10, 2022, 5:44pm

Hi Murat,
indeed, i labeled it thin-edge when I ment “thin-edge.io agent”.

Components involved in communication are very few, see sketch:

Thank you for the links to Timer and so on…

Murat_Bayram · July 13, 2022, 8:23am

So basically I see that you use thin-edge.io and the bridged local MQTT broker for communication. In that way I would not see why you want to check north/southbound connectivity for every single child device with the platform since they all run via the same broker.

What I probably would use is the watchdog service of thin-edge.io that checks the child devices and raises alarm if the service is stopped.
For the North/southbound check I would do that only via the parent device (thin-edge.io main). If the communication via the bridged local MQTT Broker works, it does so for every child device. That could be achieved e.g. via an custom operation (e.g. Heartbeat) that is triggered via EPL from platform side and answered by the parent device.

strasser.manfred · July 18, 2022, 11:07am

There still could be a problem on the OPC-UA communication that is not covered by MQTT check. Or does MQTT check if the OPC UA Server is up/ok. That the connection from OPC-UA Server to OPC UA Agent is ok? Thank you.

apes · July 18, 2022, 11:43am

Hello Manfred,

actually the OPC UA Gateway (Agent) is establishing and monitoring the connection to OPC UA Server. Is there something wrong the OPC UA Gatway creates an alarm for the OPC UA Server managed object. I am not 100% understand your comment, why is this related to MQTT?

Best regards, Alex

strasser.manfred · July 18, 2022, 1:57pm

Hi Alexander,

Because I interpret Murat’s answer like this:

Why should one monitor OPC UA communication when OPC UA communication is handled by means of MQTT transport.

My answer was suggesting that when MQTT is OK, it does not mean OPC UA is OK.

At the moment I have 4 OPC UA information that I monitor. Partial, this may be covered then by MQTT monitoring, but not completely.

Murat_Bayram · July 19, 2022, 9:32am

Hi Manfred,

still do not understand the real use case, lets try to split that out:

Monitoring of communication between OPC UA Gateway Agent and OPC Server:
This is already realized via the Gateway Agent directly. If the configured OPC UA Server is not reachable, an alarm will be raised on platform side.
Monitoring that Communication of the OPC UA Gateway Agent to Platform side via thin-edge.io works (northbound):
This can be realized via the mechanism of the required interval on platform side for the OPC UA Gateway Agent.
Monitoring that Communication from Platform to thin-edge.io works (southbound):
This could be realized with a custom operation e.g. heartbeat that needs to be acknowledged once in a while.
Monitoring that other components on local network (e.g. other child device agent components):
This can be realized via the watchdog approach of thin-edge.io.

strasser.manfred · July 19, 2022, 11:19am

Hi Murat

Thanks for the detailed description and analysis.

I think now I know what was missing in the communication before

You write

strasser.manfred · July 19, 2022, 2:12pm

Hi again, I just saw now, that my answer was 'humilitated'. I answered by E-Mail, it seems this is not working so well. So please find my complete answer here....

Hi Murat

Thanks for the detailed description and analysis.

I think now I know what was missing in the communication before

You write

Monitoring of communication between OPC UA Gateway Agent and OPC Server:
This is already realized via the Gateway Agent directly. If the configured OPC UA Server is not reachable, an alarm will be raised on platform side.

I want/need to have the connection status (or the alarm, all possible causes included**) in the system controller (most south point** )

For that I have a logic

This covers all aspects of OPC-UA and (bottom most) I want to include any issue of MQTT (I am still not sure about this, maybe this is not necessary, as MQTT will transport the operations).

The resulting MO (Event) I need to transfer to the PLC. For that I want to install an interval-timer in EPL and execute an operation to transmit this MO to the system controller.

This is important, as by doing this, additionally components (in the gateway (hosts thin-edge.io) and in the system controller) get tested as well.

The endpoint in the system controller only needs to expect every “interval” information about the connection status.

If it is not receiving, there it will raise an alarm because there is a problem south bound or in EPL
If it is receiving, it may show status “OK”
Or it may show any kind of OPC UA problem

(BTW: still need to find – in other words – I am not sure what I can achieve with the thin-edge.io watchdog).

system · October 17, 2022, 2:12pm

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.