Architecture
The ADS router in each device brokers the ADS commands between the local and also remote "ADS devices".
This router can be configured so that ADS communication can also take place over a broker.
The broker brokers the incoming ADS commands on the basis of the stored configuration.
Virtual AMS network
Different "virtual AMS networks" with different devices can be defined in the broker. To do this, each TwinCAT router opens an MQTT connection to the broker that is set in its configuration.
The broker configuration specifies which devices are permitted to access which other devices.
Overall, virtual AMS networks can be mapped via a broker.
Local realization
The realization of the ADS-over-MQTT connection takes place via the TwinCAT router as an additional transport channel. As a result, the extension is transparent with regard to the ADS client as well as the ADS servers on the respective devices.
Technical realization
At MQTT protocol level each ADS router is mapped as a "user", although this need not represent an exclusive relationship.
Two different topics categories are used by each communication device:
- Discovery: <NetworkName>/<AmsNetId>/info
A connecting router sends a RETAIN message to this topic whilst at the same time subscribing to <NetworkName>/+/info (QoS2) so that it is informed about other connected routers. - Communication: <NetworkName>/<AmsNetId>/ams/#
A router subscribes to <NetworkName>/<AmsNetId>/ams/# (QoS2).
The ADS commands are sent to this router at <NetworkName>/<AmsNetId>/ams and the responses via <NetworkName>/<AmsNetId>/ams/res.
The result of this is that the broker has to implement RETAIN topics as well as QoS, as described in the introduction. One example of this is the Eclipse Mosquitto broker.