Is VPN the right tool for robotics?

2023-02-16

Understand the challenges faced with inter-network connectivity when deploying AMRs in a warehouse and how Staex provides a solution through its overlay network with global addressing, end-to-end encryption, and efficient management capabilities.

Robot maker's perspective

Suppose you run a robot maker company. You designed a slim, nice-looking, and powerful robot that carries pallets. You perfected the software and the hardware. You found your first customer — a retail store that wants to automate their warehouse. You deployed your first small fleet of robots to the warehouse. Since this is your first deployment you expect things to go wrong and you want to fix the issues as fast as possible. To do that you need remote access to your robots. Thankfully a retail store is eager to help and provides you the access to the fleet manager over a VPN. Your robots get stuck multiple times and you decide to tune navigation parameters for them. You upload the new version of the software package first to your fleet manager, then to each robot. You replace the old version with the new one and restart relevant system services.

Everything seems fine but you want to ensure that the next time you update the software you don't have to go through all these hoops. Your robotics engineers don't have much experience with DevOps but have enough expertise to follow current best practices. They learn that writing and maintaining shell scripts to automate software deployment is not a sustainable solution. They look for other IT automation technologies but none of them seem to work in this use case.

The problem of IT automation across networks and possible solutions

Why does this problem exist? IT automation software (e.g. Ansible) was designed to work within a single network, but here we have two networks: the fleet manager is part of the VPN network and robots are part of the retail store's local network. It is not possible to establish direct connections from your servers to the robots, and it is not possible for the robot maker to change network configuration because both networks are operated by the retail store. The robot maker runs the robots in a retail store's warehouse and connects to the robots using the retail store's networks. The problem may sound superficial until you have many clients and they all have their own network configurations.

What can we do about it? Robot maker can deploy a router that will handle connectivity between the warehouse and the robot maker's office. After that each robot can be part of the VPN, and both the VPN and the local network are operated by the robot maker. This may incur additional costs as the retail store may not allow the robot maker to use their network for internet connectivity and the robot maker has to equip its router with a SIM card and hope that a mobile network is available near the warehouse.

Another option is for the robot maker to use yet another VPN on top of the retail store's VPN. Then each robot becomes a part of this new VPN and everything works fine. This setup may have problems with network performance. Scaling this approach to a large number of clients may not be possible because each client has its own network configuration. Finally, configuring VPN is non-trivial and may consume a lot of engineering time that could otherwise be used for improving the robots — the company's main product.

The overarching cause of problems with inter-network connectivity is the fact that there is no global addressing in the Internet: most of the computers and devices are connected to the Internet via gateways and do not have addresses in the global address space. IPv6 was meant to fix this problem, but the protocol failed to include encryption into the specification, and without encryption there is no way to protect the computers and the devices from Internet threats. Hence the use of good old VPN for IoT with all its peculiarities as a workaround.

The modern solution to this problem is zero-trust network access — a notion of a network in which there is no connectivity by default and connectivity between certain nodes is enabled using policies (this is in contrast to nowadays networks in which there is all-to-all connectivity by default). From this perspective VPN is really an old well-established technology that is used only due to a lack of a modern alternative.

Revolutionizing Remote Access: How Staex is Solving the Connectivity Problem

As you may imagine there is no ready-made solution to the overarching problem, but at least Staex can solve the problem for the robot maker. Staex provides an overlay network with global addressing that bridges all the networks where its robots reside. With the global view of the fleet the robot maker can efficiently manage, maintain and monitor its robots and auxiliary systems. Besides that Staex provides the following features.

• Staex enforces end-to-end encryption for every connection, thus ensuring that even devices that use legacy insecure communication protocols do not pose security threat for the infrastructure.
• Staex is easy to configure and easy to use for a network engineer, and provides service orchestration capabilities on top of network infrastructure.
• Staex is optimized for networks with packet loss which is not uncommon in a global network.
• Staex is fully distributed and decentralized.

In an ideal world the retail store would also use Staex to give the robot maker access to certain network nodes using policies. We are not there yet, but we are working on the features that would enable such a use case.

Now, are you tired of jumping through hoops every time you need to update your software? Don't let network limitations slow you down — contact us to find out how we can help you solve this problem and streamline your IT automation for good!

Staex is a secure public network for IoT devices that can not run a VPN such as smart meters, IP cameras, and EV chargers. Staex encrypts legacy protocols, reduces mobile data usage, and simplifies building networks with complex topologies through its unique multi-hop architecture. Staex is fully zero-trust meaning that no traffic is allowed unless specified by the device owner which makes it more secure than even some private networks. With this, Staex creates an additional separation layer to provide more security for IoT devices on the Internet, also protecting other Internet services from DDoS attacks that are usually executed on millions of IoT machines.

To stay up to date subscribe to our newsletter, follow us on LinkedIn and Twitter for updates and subscribe to our YouTube channel.