Hi TheChaser,
below I have listed the current implementation what we can say regarding QoS and our system.
Anyway it would be very interesting what exactly you want to do and which part of QoS would be necessary for you.
Current state
The ctrlX data layer is based on client/server architecture (misleadingly: "broker"="server") and does not yet offer any explicit features or setting options in the quality of a service level agreement.
The data layer guarantees a response within adjustable timeouts.
For IPC (interprocesscommunication), most of the QoS settings are unnecessary, as defined for TCP in MQTT, for example.
Especially in the RT area hard realtime is guaranteed.
Statements regarding the performance can be determined via benchmarks. Various measurements are already available on request.
Furthermore, there are currently no additional mechanisms as MQTT or UA has set up here (see below) for pub/sub, etc.
Possible Datalayer QoS quality parameters
With respect to the datalayer (IPC, TCP), the following QoS characteristics (at least) come into question
- Latency: the delay of the end-to-end transmission
- Jitter: the deviation of the latency from its mean value
- Packet loss rate: the probability that individual IP packets are lost during transmission (or - for real-time services - reach their destination too late)
- Throughput: the average amount of data transmitted per unit of time
- Prioritization
- ...
QoS with MQTT (Publish / Subscribe Messaging) architecture
Since MQTT was explicitly designed for insecure networks, an overlay on the underlying TCP layer was defined:
| Qos Level |
Number of send protocols per operation
|
Remark |
| 0 At most once (fire & forget) |
1 |
Same QoS as TCP |
| 1 At least once |
2 |
"Registered": Faulty protocols are forwarded. Client could receive multiple protocols, but this is usually not a problem. |
| 2 Exactly once |
4 |
"Registered mail with return receipt".
Highest reliability but also high communication overhead |
Furthermore there are a lot more quality features, especially with MQTT 5 Essentials (hivemq.com) e.g. Message / Session Expiry etc.
QoS at OPCUA (from Pub/Sub)
Provides here in Spek 1.05 explicit QoS definition for Pub/Sub (not Client/Server) - based on MQTT:
- Broker Transport (Qos): Core Data Types Broker Transport Quality Of Service | OPC UA Online Reference (opcfoundation.org)
- Latency: Core Data Types Receive Qos Latency Data Type | OPC UA Online Reference (opcfoundation.org)
- Receive Qos: Core Data Types Receive Qos Data Type | OPC UA Online Reference (opcfoundation.org)
Sources
Quality of Service - Wikipedia
Quality of Service 0,1 & 2 - MQTT Essentials: Part 6 (hivemq.com)
Overview | OPC UA Online Reference (opcfoundation.org)
