Linking your Industrial System to a Cloud Based Dashboard
A common Remote Access Engineering problem that I come across frequently usually comes in as a call from John Doe with say 3 remote sites in the middle of nowhere and needs data from these sites sent to a central location where it can be monitored and manipulated. And every now and then it comes with a twist like – John also wants to make sure data is stored or some form of control is required. First thing would be to break this problem down. You have remote sites you want to poll data to a cloud for display and control with logging capabilities. This presents aspects of a remote connectivity problem, a remote access problem, a cloud computing problem and a data logging problem all rolled into one.
Analysis of a Remote Access Engineering Problem
For remote connectivity and remote access, we would recommend John gets a 4G/5G mobile router with fall back to 3G – remember we are in the middle of nowhere here - which should also be capable of interconnecting the remote sites together. The solution must also provide secure access and firewalling capabilities to protect the remote site in the cyber space.
ProSoft Technology’s ICX35 Industrial Wireless Modem is perfectly suited for this type of application. It comes with features like SMS capability, DDNS, OpenVPN and IPSEC support, imbedded firewall and serial encapsulation and also support ProSoft Technology’s Cloud Connectivity Service – ProSoft Connect. ProSoft Connect will allow the individual remote site to communicate with each other in a Persistent Data Network or PDN which emulates a somewhat unmanaged switch connecting the remote sites together. You can also connect the Cloud machine to the PDN as a standard remote access device and it would have the ability to communicate with all the remote sites – sending data back and forth from site to site.
With regard to data storage, the solution would need to be able to independently log data from the Remote Site PLCs or PACs so as not to increase the load on these machines. The solution must also be able to allow the user to monitor the data being logged in real time so that the user can verify this data. Finally, because you can have multiple protocols on different sites, the solution must be able to support multiple communication protocols. ProSoft Technology’s PLX51-DataLogger+ is perfectly suited for these requirements and comes with a numerous features including, but not limited to, a high record capacity, high logging frequency, multi-PLC support, multi-protocol support and is JSON compliant with support for REST API.
The last part of this solution is a Cloud based machine interface. The solution will need to be secure and yet accessible. It would need to be hardware redundant and it would need to be highly scalable. This part is dealer’s choice, one can choose from a number of solution packages like chariot or one can decide to build an in-house platform to meet these requirements. In the technical video of this solution, we will demonstrate a platform built from scratch running over Google Cloud Platform which is secure, with an asterisk, accessible from anywhere in the world and utilizes powerful Kubernetes to support Hardware redundancy, load balancing and scalability.
Kubernetes or K8S allows you to run you applications in a containerized manner using containers know as pods. Pod will have everything that is required to run your application and can be imaged and mirrored for easy deployments – that is running the applications, updates and rollbacks. These pods can run across multiple individual machines referred to as nodes that are stateful and interconnected. Stateful meaning the pods share the same resource. This provides that needed redundancy with every node capable of compensating for the absence of another. Each will still be able to handle so much work but K8S allow you to scale the number of available pods in each node dynamically. So you can create and delete pods automatically depending on load. K8S Uses services to connect the outside user to the Nodes running the pods running the applications. This gives the user a unique opportunity to dictate how the outside world interacts with the cluster, the set of connected nodes. In our scenario, the service can be a load-balancer, distributing the external requests across all the all the available nodes. If one of the nodes were to go offline, the service would adjust the distribution of request to the remaining available nodes.
The last part of the implementation of this solution is connecting the cloud platform to the PDN Network. There are 2 ways of doing this. The first is to have the cloud as a Standard Remote Access device connecting to the PDN using ProSoft Connect. This makes the cloud platform part of the PDN network. It can communicate with all the other devices on the PDN.
Another option is to use a connector device that will be part of the PDN network connected on one of the remote sites. The connector would segregate the cloud from the reset of the PDN, serving data to or receiving data from the cloud using a secure IoT protocol like MQTT. For our demonstration setup, I chose to implement both of these 2 options. We have the cloud as part of the PDN network but we also have a connector device interacting with the cloud via JSON over HTTPS or HTTP Secure, which allows for secure, easy integration.