VDA5050 is a standardized interface for the communication between AMRs/ AGVs and fleet management software. While it does make logistics automation much easier, its implementation can be challenging. With that in mind, one of arculus software specialists created a free toolchain to help other developers run the standard. Here is what you should know:

What is VDA5050?

VDA5050 is an open protocol created by the German Association of the Automotive Industry (VDA) and the VDMA Materials handling and Intralogistics Association. The goal was to standardise the communication between autonomous robots and fleet management software.

In layman’s terms: if every single AMR and AGV on the market could only communicate with their own master control, the implementation of solutions from two or more suppliers could result in interoperability issues. And with the growth in Industry 4.0 bringing increasingly more automation options to the market, customers want to make sure they can count on multiple suppliers for a large and diverse fleet of AMRs and AGVs.

“So basically, VDA5050 is supposed to be a common language between robots and fleet managers, so that customers can interchange robots and fleet software from different providers without any compatibility issues. This not only offers greater interoperability, but also protects them from vendor lock-in”, explains Alexandr, arculus Software Developer supporting with VDA5050 topics.

Needles in a haystack

According to Alexandr, implementing the standard is rather simple: “you read the open document, then you implement it”, but it does come with a few challenges. For instance, the complexity of troubleshooting. To understand that, let’s have a look at how VDA5050 uses Message Queuing Telemetry Transport (MQTT) to transmit JavaScript Object Notation (JSON) data:

The blue screen contains the message that the fleet manager sends to the robot. In a real-life situation, with dozens of robots running at the same time, a high volume of similar messages is sent every second. Now, if a human has to manually inspect this information, finding an error would be like “finding a needle in a haystack”, as Alexandr describes it.

An example of this would be a fleet manager sending an order to the AMR expecting it to stop at a certain position, but the robot stopped sooner than it should. A series of hypotheses could explain the failure, but to test them, the developer would need to analyse every single position coordinate in the log.

“In practice, I would usually need to scroll to the right point in the log and copy/paste the payload to a text editor that ‘prettifies’ it, so that the indented structure is more readable. This is not only time consuming, but also extremely error-prone”, explains Alexandr.

A bright solution for all

When confronted with this “boring, monotonous task”, as Alexandr himself describes it, he decided to look into ways of simplifying it. And as any good software developer would do, his solution was to create a digital tool: the arculus VDA 5050 Visualizer. What the mechanism does, is illustrate the data exchange between the AMR or AGV and the fleet manager in the form of a chat. It allows the user to scroll through the history of messages, while the alignment of “bubbles” indicates who sent each message.

Just like a car display, the tool also comes with a set of symbols that the AGV sends with each message to indicate different aspects of its work, e.g.: Is it driving? Is it charging? Is it carrying loads? And so on:

Further benefits of the visualiser also include compatibility with the latest version of the standard (VDA 5050 v1.1), easy operation via desktop or mobile browser, seamless integration, and no interference by design – meaning that the visualizer is a passive listener, it cannot break or otherwise affect the communication between the AGV and the fleet manager. Developers can also count on privacy assurance: arculus has no access to any information uploaded into the tool.

“This payload visualizer is a tool I wish I had at hand when I was implementing VDA 5050, as it would have saved me a lot of time and mental effort. It transforms boring and error-prone problems into purely visual issues that can be solved much easier”, concludes Alexandr.

Successfully navigating an obstacle course

Once the communication stream between robot and fleet manager is debugged using the visualiser, it is time to prove the implementation of VDA5050 with the performance of real-life tasks. For that, the arculus software team came up with a series of challenges to test the AMR. In the beginning, every single task had to be observed by a human, who would then be able to tell if the robot passed or failed the test.

After manually taking notes on countless trials, Alexandr decided to also come up with a way to automate this part of the VDA5050 implementation. And this is how the second instrument in the arculus toolkit was born: the VDA 5050 compliance test suite. 

The tool consists of scenarios that are described in notation that reads like plain English. This makes it easy for every stakeholder to get on board and follow the logic of the test, even if they don’t have a technical background. Here is an example of a test produced for Audi:

AGV must drive to n90 without actions
   [Documentation]     Ensure that the AGV is capable of
   ...                 executing an order, by sending it a
   ...                 predefined one to drive from n82 to n90
   ...                 without any actions

   Send VDA5050        go n82->n90
   Wait until AGV starts moving

   ${data}             Get one state message
   The flag must be set in data                driving  ${data}
   Wait for AGV to report reaching node        90
   Wait until AGV stops moving

   Wait until AGV reports it is not moving
   ${data}             Get one state message
   The flag must NOT be set in data            driving  ${data}

Tests such as the one above are then arranged in a sequence, forming an “obstacle course” that the AGV should go through. As the tests are executed, the live results can be observed in the console, providing a one-line summary for each test. Once the robot completes the whole course, users can also view the test results in a graphical form:

Each entry can also be inspected to get even more detailed information, down to the level of “what was the value of this particular attribute at that time?”. Here is what that looks like:

Of course, the next logical step is to understand how each task failed. For that, users can use the tool to get information about what request was sent to the AGV, how it replied, and which part of that reply was different from the expected result. Such feedback enables the team of software engineers who develop the software running on the AMR or AGV, to iterate rapidly because the exact error is pointed out.

With this automation tool, developers can rely on a facilitated ‘inclusion of compliance test’ in a continuous integration (CI) infrastructure. The mechanism also allows for total replicability, which ensures that tests are run in exactly the same way, no matter how many times or on how many devices.

“What I find interesting is that it only took me a couple of weeks to come up with the tests and get the tool running. But now that it’s ready, myself and other users can run it as many times as necessary, with little to no effort required. That for me, sums up my job: solving problems using software”, concludes Alexandr.

---