Logtunnel scenarios

Summary

This page is intended as inspiration for Logtunnel setups and contains a variety of examples to be adapted for more specific use-cases.

This is not an exhaustive list of the possible LogTunnel setups, and if you have a specific scenario that is not covered here it may simply be one we have not thought to include. In such a situation we recommend contacting your point of purchase to advise you on the feasibility of your proposed setup. Please include a detailed description of the network setup and the desired outcome.

For more information on how to set up LogTunnels, please refer to the following documents:

Simple Pull scenario setup

Deployment Guide

LogTunnel with serial ports

Scenarios

Scenario 1 depicts a simple one-to-one LogTunnel setup, but even this simple setup has a few variations;

• One-way Pull: In which there is a Pull Master in SiteManager1 and a Logtunnel Client in SiteManager2, where the Pull Master initiates the connection.
• One-way Push: In which there is a LogTunnel Client in SiteManager1 and a Push Master in SiteManager2, where the Client initiates the connection.
• 2-way Push/Pull: In which each SiteManager will have both a Master of the appropriate type and a LogTunnel Client, where either party can initiate the connection.

Scenario 2 depicts a one-to-many LogTunnel setup, in which data is retrieved from multiple devices behind one or multiple SiteManagers to a Pull Master. In this scenario, each device has a LogTunnel Client, but there is only a single Pull Master.

Scenario 3 depicts a one-to-many LogTunnel setup, in which data is retrieved from multiple devices behind one or multiple SiteManagers to a Pull Master. In this scenario, each device has a LogTunnel Client, but there is only a single Pull Master. This setup is identical to Scenario 2, but in this case, there is a larger variety in the devices, as it depicts a more generalized monitoring setup.

Scenario 4 depicts a double one-to-many LogTunnel setup, in which data is retrieved from multiple devices behind one or multiple SiteManagers to a Pull Master. In this scenario, each device has a LogTunnel Client, but there is only a Pull Master on SiteManager1 and SiteManager4. In this setup, there are two destinations for data, the PLC behind SiteManager1 and the log server behind SiteManager4, with each of the PLCs having a LogTunnel Client as well.

Scenario 5 depicts a one-to-many LogTunnel setup, in which data is retrieved from multiple devices behind one or multiple SiteManagers to a Pull Master. In this scenario, each device has a LogTunnel Client, but there is only a single Pull Master at the log server. Similar to previous scenarios in its construction, this setup also shows how SiteManager Embedded can be utilized on the client-side, in both the Basic and Extended varieties. In the case of the SiteManager Embedded Basic, it is only able to connect to the device on which it is installed, whereas the SiteManager Embedded Extended, is able to connect create connections to devices behind it. A SiteManager Embedded Extended license is also required to create a LogTunnel Master on a SiteManager Embedded.

Scenario 6 depicts a one-to-many LogTunnel setup, in which data is retrieved from multiple devices behind one or multiple SiteManagers to a Pull Master. In this scenario, each device has a LogTunnel Client, but there is only a single Pull Master at the log server. The difference between this and Scenario 5, is that this scenario utilises a SiteManager Embedded by the log server, which in this case functions identically to the SiteManager Hardware solution, but could conceivably be deployed in a cloud, which the hardware version would not be able to unless one has control of the hardware used in the cloud solution.

Scenario 7 depicts a many-to-many Logtunnel setup, in which data is transferred between multiple devices on both ends of the connection. In situations such as these, the setup can become complex and non-trivial to maintain, therefore we generally recommend a traditional VPN if possible as this tends to stray from the intended use-cases. We do understand that in some cases a setup such as this will develop out of necessity, for example, if there is no possibility of using a VPN or if this is simply a result of multiple overlapping Logtunnel setups.

In this kind of setup, any device which should be able to initiate the connection will require a Pull Master or will need to be a client attached to a Push Master, and any device which should be connected to will need to be a client or a Push Master. In a many-to-many setup, many devices will be both Masters and Clients.