Matthias Blankenburg

Xavier Bush

The impact of AGVs in the Industry 4.0 (Industrie 4.0) is supposed to be outstanding. Based on the experience that we have at R3 Communications, the industry envisions shop floors where machines, AGVs and humans interact seamlessly with each other. An excellent example of this interaction is illustrated by the following use case: cooperative transport of assets using AGVs platooning. In a platoon of AGVs, several AGVs work together, mirroring each other to perform a task.

As it might have already crossed your mind, the platoons of AGVs need to perform their task efficiently while meeting the safety requirements of the industry. Rather than focusing on the control of the AGVs, this blog entry focuses on how EchoRing contributes to the safety requirements of this AGVs application. First, we show how EchoRing provides an ultra-available link that prevents the AGVs from going to the emergency state, making the process more efficient. Second, we show how EchoRing enables a new concept of Emergency Stop (E-Stop) button.

Nowadays, it is ubiquitous to find cranes moving large or heavy assets in what is called the heavy industry, and it is, in fact, a desire that AGVs substitute those cranes. To show the impact of the safety functionalities in such a scenario, in this blog entry we focus on one particular highly demanded use case (?!):  you want to take an elephant out of the room using four AGVs.


An operator monitors the AGVs while they take the elephant (asset) out of the room



It is widely known that human safety is a crucial topic within the industry. Therefore, machine builders take that into account when designing and manufacturing their machines. Without getting into too many details, there are some essential concepts that help us to understand how a machine can operate safely. Essentially, a machine needs to be compliant with the functional safety requirements, often using industrial safety protocols, which, when triggered by certain events, bring the machine into the emergency [stop] state. Some of these events are self-driven decisions by the machines while other events are human-driven.

Typical machine-driven decision examples are a communication loss among the machines, and a machine stopping because some sensor data indicates that there is some dangerous situation in the surroundings, e.g. a person opens a door that should be closed during a manufacturing process.

As per human-driven events, the most common one is the activation of an E-Stop button to enable a human operator to stop the machine whenever there is a critical situation. It is important to remark that in the manufacturing and automation industries, it is infrequent to see any type of machine without an E-Stop button attached to it.



In a typical industrial bus structure, there are several machines in a wired network that exchange control and safety information with very short time frames. Standard deadlines for safety protocols are in the vicinity of 10 ms. Understandably, safety protocols do not adapt the deadlines depending on the communications technology (wired or unwired), but they rely on the safety requirements of each application. In this way, if a machine does not receive the safety information before the deadline, it goes directly to the emergency state. Anytime that any machine goes into the emergency, the machine stops working, and usually, an operator needs to restart the machine personally to restore the motive power, i.e. bring the machine back to work. As you might have already thought, this process is time-consuming and, the longer the machine stays in the emergency state, the longer the machine is not producing, leading to an efficiency decrease. Also, as we all know… Time is money.

Going back to our AGVs platooning example: if the technology used to synchronise the machines is WiFi, the needed availability of the wireless link will not be guaranteed, especially if there are two or more participants in the network. As WiFi is an unsynchronised technology, the on average achieved latency will be around 50 ms (5 times the typical 10 ms deadline mentioned before) or even higher. In other words, as the latency in a WiFi network will never be guaranteed (check other blog posts), relevant safety packets in such a network will be delivered even much later than 50 ms. In this scenario, there is a high likelihood that the machines go into the safe state very often, decreasing too much the productivity and efficiency of the application.


Let’s assume now that while the AGVs take the elephant out of the room, an operator crosses the platoon’s path. In that case, one of the AGVs might detect the operator and go into the safe state, completely stopping its course. At this point, to guarantee that the operator (human) is not hurt and the elephant (asset) is not damaged, the other three AGVs should stop. If they don’t, the outcome might be catastrophic.

Another worker crosses the AGVs’ path; one AGV detects him and stops; the other AGVs don’t stop; the operator pushes the E-Stop but the signal does not propagate

As mentioned before, WiFi does not meet current safety deadlines for the propagation of safety signals in such a scenario. Therefore, other solutions/technologies should be screened, potentially adding more complexity and cost in the development of the AGVs.




With EchoRing, the two challenges presented in the previous section can be tackled at the same time.

First, the low-latency performance of EchoRing guarantees a single-digit latency, meeting the 10 ms deadline for safety applications. With the correct propagation of the safety packets among all the network participants, the likelihood that the AGV goes into the emergency state decreases. With the emergency state happening less often, the productivity and efficiency of the application increase, which solves the efficiency challenge explained in the previous section.

Second, with a distributed and cooperative network like EchoRing, the propagation of a safety signal is guaranteed, which ensures the safety of both the operator that crosses the AGVs path and the asset carried by the AGVs: once the front AGV detects the operator, it goes to the emergency state and instantly propagates that information to the other AGVs.

Another worker crosses the AGVs’ path; one AGV detects him and stops; the signal is propagated to the other AGVs and all stop safely



There might be a need that an operator actively stops the whole platoon by her/his own choice. As mentioned before, each machine has its own E-Stop button. However, when dealing with moving machinery, and with short reaction time, pressing the button physically attached to an AGV might be, at least, challenging. With EchoRing, an entirely new concept of E-Stop button that would stop all the AGVs remotely becomes possible.

With one single remote E-Stop, an operator could stop all AGVs remotely, ensuring its safety, and that of the asset. The safety signal would be broadcasted in a deterministic manner to all stations and automatically propagated in case of need.

In the same way as the machines can be stopped remotely, EchoRing would also provide the needed communications interface for a remote restart of the machines. With this feature, the operator wouldn’t need to personally restart the machine, making the whole process even safer.

The operator realises that the door closes, pushes the E-Stop and it remotely stops all the AGVs



EchoRing can integrate into an AGV in different ways, always depending on the size and type of vehicle.

The most straight forward and common integration would be with an EchoRing Wireless Bridge via an Ethernet interface. Relatively big AGVs incorporate a “switching” cabinet making possible the allocation of a radio module and allowing for the needed connecting interfaces. As we can see, the integration in this sense is close to plug-and-play.

Another integration possibility for smaller AGVs would be a deeper integration of the EchoRing Radio Board into the own vehicle’s logic. This solution is slightly more complicated yet more compact (see the previous blog entry). Along the same lines of integration goes the new concept of E-Stop button mentioned above. However, the E-Stop button would likely be a part of a module with more functionalities like a teaching panel, which is a topic that we will cover in this very blog soon.

Finally, please, if you have any feedback or comment about this blog entry, write us to or comment directly on our LinkedIn or Twitter posts.

Back to news