Everything you need to know about VDA 5050 bundled on one page
VDA 5050 as an AGV interface in practice
Together with the Assosciation of the Automotive Industry (VDA), the Assosiaction of Conveyor Technology and Intralogistics (VDMA) has defined an interface that describes the communication between driverless transport systems, also called Automated Guided Vehicle systems, and a transport guidance system. The current version (1.1) can be downloaded free of charge here.
The goal of unified communication is interoperability between different AGV systems systems and simplified integration into transport guidance systems. This not only avoids “lock-in” effects, both with regard to the manufacturers of AGV systems and the developers of the transport guidance systems, but also reduces complexity, special in-house developments and integration effort to a minimum.
Even though VDA 5050 is specifically oriented towards the requirements of the automotive industry, these are still so diverse that the defined AGV interface must give room for many different scenarios and special situations. Because of this, it is unfortunately not sufficient for new projects to assume that an AGV system can communicate with the transport guidance system cockpit without any problems if both support VDA 5050. The standard offers a wide range of possibilities, where in practice it must be individually checked which aspects should actually be used in communication.
Additionally, in practice, the complexity of different systems also comes into play. The exchange of data between the transport guidance system and an ERP/Warehouse Management system goes without saying. Many manufacturers of AGV systems, however, now also offer fleet managers. These fleet managers have different functionalities, ranging from battery management to simple transport guidance systems. The first thing to clarify here is whether fleet managers need to be used, and if so, which ones, and then which aspects of VDA 5050 apply to the communication in each case. One example for this would be battery management: The standard provides the possibility to communicate the current state of the battery state to the transport guidance system and also the instruction to the AGV system to drive back to a charging station. In practical application, this is already supported by all fleet managers. Here, it must be decided whether the responsibility should remain as it is or whether it should move upwards to the transport guidance system.
The most important aspects of VDA 5050 are described below and directly commented based on practical experience on how to implement each of these. The focus is on how a quick proof-of-concept can be drafted that complies with the defined interface but does not yet have to support all features.
Which actors are there and who communicates with whom?
In addition to the ERP or Warehouse Management system, a so-called transport guidance system is planned. It knows the topology and possible routes as well as the individual transport tasks. In the following figure, all automated guided transport systems and fleet managers have been drawn as one actor. The reality is more complex. Multiple AGV systems are (mostly) attached to a fleet manager, which in turn is optional in some cases.
The focus, though, is on illustrating that an additional, new system called the Message Broker (MQTT Broker) is also required. One can imagine this as a system with several queues (these are called “topics“).
Actors can send messages to a topicor read messages from a topic. This decouples the transport guidance system from the various AGV systems or fleet managers and makes it possible to connect another transport guidance system or additional hardware at any time.
Challenges of the AGV interface in practice
One challenge we have faced in practice is, for example, the change from the push to the pull principle. Some systems “wait” for an action that they are supposed to process, execute or forward. This concept changes when switching to a VDA 5050 compatible system: Each actor has to establish a connection to the Message Broker and wait there for new messages on a topicthat is relevant for the actor.
Aside from the decoupling between the AGV system and the transport guidance system, the big advantage lies in the fact that each system can decide for itself what kind of messages it wants to receive. One example for this is the topic“visualization“, which is defined in VDA 5050. It enables resources to report their current position with a high frequency. These updates are of no relevance to the transport guidance system, so it does not need to receive them. A dashboard or a 2D map of the warehouse, on the other hand, is solely interested in this information and will therefore only receive it and nothing else.
Need for clarification at the beginning of the project
At the start of a project, it is therefore important to coordinate which systems are in use, who is the central Message Broker provider and whether all systems can communicate with it. After that, the responsibilities, functions and roles of the different systems have to be worked out. Based on this, the topicscan be defined and the actors who send messages to and receive messages from them.
Communication of the current status of an AGV to the control station
One of the most important messages is the current status of an AGV system, which has to be sent to the transport guidance station cockpit. Without it, it is neither known which resources are available, nor can transport tasks be allocated intelligently. In the VDA 5050 AGV interface, the topic“state“ was defined for this purpose. Messages of this type should be sent at regular intervals (30 seconds are mentioned) or after special events have occurred. Examples of this include errors, the arrival at a node or even the confirmation upon receiving a task. The transport guidance system cockpit can, in turn, read them and is always aware of the current situation of the AGV systems.
Date of „state“
A complex data object with many required but also optional elements has been defined for the status. For this reason, only the important data types are explained below, the ones that one should know in order to be able to assess the potential and the possibilities.
- orderId: ID of the current or previous task
- lastNodeId: D of the current or last traversed node
- safetyState: Information important for safety, e.g. whether “E-Stop” is activated.
- informations: Any information that can be sent by the AGV system. The content is undefined and should not trigger any logic in the transport guidance system
- errors: A list of current error messages
- batteryState: The current battery state of the AGV system
- actionStates: List of actions, which the AGV system will handle in the future
- edgeStates: List of all paths that the AGV system must traverse until the current task is completed
- nodeStates: List of all nodes that the AGV system must traverse until the current task is completed
We will not go into any more detail on the various data in this article. For more information, please look up VDA 5050 directly.
Need for clarification in practice
As mentioned earlier, it is important to consider at the beginning of a project which data is actually sent and which systems react to it in which way. The example of battery management was mentioned at the beginning. The standard provides the possibility to communicate the battery state. It must now be examined now whether each AGV system or each fleet manager can actually send this information and whether the transport guidance system can or should react to it.
Another example is the position of the vehicle: There are multiple ways to communicate or calculate where the AGV system is currently located. Via the lastNodeId, edgeStates and nodeStates, it can be determined within the topology (at least roughly) where the vehicle is currently moving to. However, there is another (optional) field in the state, the agvPosition. Exact X and Y coordinates can be passed here. Together it must be coordinated right at the start which of this information is available, which should be used by the transport guidance system for the assignment of transport tasks and how to proceed in case of contradictory data.
Communication of transport orders / routes to an AGV
The main point and purpose of the entire system is to assign transport tasks to different resources. For this purpose, the VDA 5050 defines the topic“order“. The principle of an orderis quickly explained: it includes a path from node X to node Y and actions that need to be performed. The actions will be looked into in the following chapter. Here we will first elaborate on the route, meaning from where to where and on which path an AGV system should navigate.
Topology in the control room
The starting point is a complete topology of the warehouse or production in the transport guidance system cockpit. It consists of nodes and edges. The following example is very simplified. In reality, there are still one-way streets, vehicle type restrictions that define which type can traverse on which edge, elevators, gates and other obstacles.
Transferred route to the AGV
As soon as the transport guidance system receives or creates a transport task, it must communicate the route to the AGV system. Ideally, there are no restrictions and no other vehicles that can get in the way. In this case, the complete route can be communicated.
The AGV system, which is currently positioned at node 3, now knows that it should travel via nodes 6 and 7 to node 8. The standard, however, dictates that all nodes and edges of this communicated route are reserved for this vehicle, which means that it can travel the entire route without disturbance.
Since it would be very inefficient in practical application to directly block all edges to be traversed for other vehicles, VDA 5050 provides a concept with “base” and “horizon“.
Transferred route to the AGV with “BASE” and “HORIZON”
The idea behind it is that at the beginning it is not necessary to block the whole route. In other words, it is divided into a “base” section, which is already reserved, and a “horizon” section.
This means that the AGV system can already start moving from node 3 to node 6, although part of the route (from node 7 to 8) has not yet been released. Once it has reached node 6, it stops and waits for the further section of the route to be released. In the following example, it is updated that the route to node 7 and the node itself are released and reserved for this vehicle. It can therefore continue its run.
Simplified concept for first proof of concept
As mentioned above, the standard offers many possibilities for optimization and for communicating detailed information at the right time. Once again, at the start, the question must be asked which information actually needs to be used and communicated. Many fleet managers already support the function of moving from point X to point Y on the other side of the warehouse. They do this based on magnetic stripes, RFID tags, or visual features. If a fleet manager that already supports this functionality needs to be connected to a transport guidance system via a VDA 5050 AGV interface, it may not be necessary to communicate the exact route.
The positive and at the same time challenging aspect of the standard is the fact that many things are possible but mostly not necessary in practical application. All sides should know the possibilities of VDA 5050 and decide together at the start of the project which aspects are necessary. Opting for a standard does not mean that communication and coordination are no longer necessary.
Communication of actions to an AGV
In the previous section, it was explained how the information is communicated that an AGV system is to move from node 3 to node 8. But the VDA 5050 standard additionally offers the possibility to communicate concrete actions that should be performed by the vehicle.
Predefined and own actions
Since some actions are universally valid these have been included in the standard. These include for example:
- startPause/stopPause: Activate/Deactivate the pause mode
- startCharging/stopCharging: Activate/Deactivate the charging
- pick/drop: Request the AGV system to pick up/drop off something
- cancelOrder: Cancel the current order
Additionally, designated fields are provided where each AGV system manufacturer can implement its own set of actions. In this case, it is necessary to develop support for it in the transport guidance system cockpit as well. As already mentioned a number of times, it is also necessary to check for the actions which ones are relevant for the current project and which ones have to be triggered and received by which system.
Times of the actions
There are two ways to communicate actions to the AGV system.
First, there is the topic“instantAction“. This topic can be used to send actions directly and at any time. This can be necessary to avoid collisions or “deadlocks” at intersections, to change tasks on the fly or to react to errors of other vehicles.
Second, it is possible to send a task directly with actions that should be executed on certain nodes or edges.
In the following example, the AGV system must move from node 3 to node 8. While moving, it must turn on the warning signal at node 6 and activate both the warning signal and the signal lamp on the path between 7 and 8. On arrival at node 8, the “pick” action must be executed.
Questions from practice
When changing to a communication standardized by VDA 5050 or a new project, simply telling the manufacturers of the AGV system and the transport guidance system that the standard must be supported is not enough. There are too many ways to interpret the standard. The following questions provide a first orientation on the points that should be addressed directly at the very beginning.
- Technical coordination: Who provides the Message Broker?
- Which topics are relevant for this project?
- Will visualization be required?
- Will connection be required?
- Will additional, self-defined topics be required?
- Which information can be sent by the AGV system or fleet manager?
- Is the current position available?
- Can the battery state be sent?
- Is there any specific information that needs to be communicated? (For example, the load weight, position of a gripper arm or conveyor belt).
- Can all vehicles and fleet managers send the same information?
- Which system must react to which information?
- Which information will be used for the actual current position?
- Which error codes will be relevant for the transport guidance system cockpit? When is it necessary to make changes to the plan?
- What are the responsibilities of each system?
- Will the AGV system/fleet manager take care of route finding autonomously?
- Will the AGV system/fleet manager take care of battery management autonomously? Will vehicles move to the charging station and log off at the transport guidance system cockpit autonomously?
In conclusion
We hope that we have been able to show you in this article what VDA 5050 actually involves and what it means to switch to this standard. It first of all offers the convincing advantage that crucial aspects of communication are standardized, which otherwise would lead to a lot of communication and integration effort. Another advantage is that it is possible to start “small”. As shown in the example of the route, the entire concept with “base” and “horizon” does not have to be implemented on day one; it is sufficient to send a start and destination node at first.
It is this flexibility that is the key advantage. Once the infrastructure, in other words the Message Broker and the individual topics, have been defined, it is very easy to connect additional actors. An additional AGV system manufacturer can be easily integrated, a new tool for the visualization of the vehicles in real time can be connected and even the transport guidance system can be replaced with significantly less effort.
So if you only have a transport guidance system and a fleet manager or an AGV system and do not plan to extend it, you will not get any benefits from this standard (which exceed the implementation effort). For a more complex system landscape, a new project starting from scratch, or if this flexibility is necessary because future plans are not set in stone, we can only recommend you to at least consider this standard.
Further information
Do you have questions regarding the new VDA 5050 guideline? Our staff will gladly answer your questions and help you out. Please simply fill out our contact form. In the meantime, you can also find out how the Flexus Transport Guidance System integrates AGV systems.