In addition to the AGVs and the MQTT broker, which distributes messages, the control system is the third important actor in any VDA 5050-compliant system. Data required by all AGVs is stored and maintained centrally in this system. This includes the following information, among others:
- Topology of the warehouse or production: which places and nodes exist at which coordinates? Which edges connect these places and nodes?
- Reference system: What are reference points for the coordinate system used?
- Error reasons: Which error messages are possible? How can the respective error messages be reacted to?
Furthermore, order management takes place in the control system. Driving orders for AGVs are created from any source and distributed to the AGVs with or without optimization according to certain logics. A special feature of a control system integrated in SAP is the direct coupling with SAP modules such as SAP EWM, SAP WM or SAP PP. A large part of the transport orders for AGVs originates in these modules and must first be read out and optimized by the control system.
Then the SAP-specific orders, for example a warehouse task or a transport order, must be converted into VDA 5050-compliant messages and sent to the AGVs via the MQTT broker. Since the associated SAP postings must also be acknowledged or canceled in order to start subsequent processes, the responses of the AGVs must be understood by the control system and converted back into SAP structures.
In an earlier article, the technical background was explained how VDA 5050 messages can be sent and received by an SAP system. Now two more questions arise:
- How do I interpret the content of VDA 5050 messages?
- How do I integrate VDA 5050 processes into SAP EWM and SAP WM?
In order to answer these two questions, three aspects are considered below:
- organizational information
- from transport orders via actions to bookings
- exceptions, disturbances and errors
Organizational information: Assignment of warehouse structures
Most warehouses and productions are divided into different halls, areas or other units. In SAP, this is mapped by hierarchical structures that, for example, describe individual locations or bins in ever greater detail, from warehouse numbers to storage areas to storage bins. This basic information must also be available in a VDA 5050-compliant communication.
For example, to know for which storage areas an AGV can accept orders, this assignment must either be maintained in the control system or sent along by the AGV within the VDA 5050 message. Both options are possible, depending on the flexibility it has to be decided how often and in which system changes can be re-maintained.
All AGVs must communicate their current status to the control system at regular intervals. These are the so-called status messages. In these, the field “zoneSetId” is present, in which, for example, the storage area where the AGV can drive is sent along.
In addition to the higher-level warehouse structures, concrete places where goods have to be picked up and set down are the most relevant. The challenge here is that both each AGV and the control system have a common understanding of what which place is and where it is located. Especially when there are multiple AGV manufacturers, this can become very complex. To solve this problem and to specify a uniform network of places and routes, Flexus offers the RouteOptimizer. With this, the layout can be drawn graphically and places can be linked to concrete SAP objects such as storage bins. This can then serve as a reference system for any number of AGVs, each of which can map their internal topology to it.
From transport orders to actions to bookings
Collecting and optimizing transport orders
Basically, it is defined that AGVs communicate their status to the control system at regular intervals or when certain actions are performed. Part of this status are all orders currently to be processed. At the beginning, there should be no orders, which means that such a status message can be understood by the control system as a request for a new order.
Parallel to this, objects can be created in various SAP modules that result in a goods movement. In SAP WM, for example, these are transfer orders or in SAP EWM warehouse tasks. These must now be read out by the control system, possibly optimized and distributed to AGVs via a VDA 5050-compliant interface. With Flexus, this is done by the transport control system. This contains interfaces to all relevant SAP modules: WM, EWM, PP, EAM and WM.
Furthermore, additional orders for which there are no SAP objects, such as waste and scrap drives, can be added to the common transport order pool. The transport control system not only takes care of the readout of all SAP orders, but also of a holistic, cross-module optimization.
Sending actions to AGVs
If an AGV now sends a new status message and the control system recognizes that it can assign a transport order to it, one of the orders from the pool is assigned to this AGV. This must now also be converted into a VDA 5050 compliant message. This means that all types of goods movements, whether they originate from SAP EWM or from a manual waste disposal system, must be converted into the same structure so that they can be interpreted in the same way by all AGVs.
Apart from organizational information such as the order number, there are two important data in the VDA 5050 message:
- Nodes and edges to be moved and their release or blocking.
- Actions (pick up and set down)
The concept of locking logic has already been written about in the first article of this series. Relatively simple in comparison, the actions are passed. This is just a list, at which node which action should be executed.
Triggering bookings in SAP
While the order is being processed, the AGV constantly sends its status messages to the control system. It becomes relevant for the SAP system as soon as the control system recognizes that the order has been completed. On the one hand, a new order must be assigned to this AGV and on the other hand, it must be checked whether a booking is to be made.
In the case of transport orders that have been created by a transfer order or a storage task, these underlying objects must also be confirmed. Since there are many special cases here, depending on the SAP module, such as partial withdrawals or partial confirmations, this abstraction is again mapped by the standard of the Flexus transport control system. No matter if the transport order has been created by SAP MM, SAP WM, SAP EWM etc., the appropriate booking is executed after successful confirmation of the AGV.
Exceptions, faults and errors
Data that cannot be interpreted
Firmly defined messages for standardized communication, one of the great advantages of VDA 5050, can lead to problems in practice to the same extent. This can be due to the fact that developers rely on receiving certain information in a specific form from the AGV or the control system. Since these are also defined in this way in VDA 5050, this assumption is justified. However, companies often set other priorities when developing their VDA 5050 interface:
- An AGV manufacturer has its own battery management system and therefore sends no or a fixed value as state of charge to the control system
- The control system sends an action to all AGVs, for example the emergency stop, but this action is not supported by all AGV types
- In systems or interfaces, defined fixed values are slightly changed, for example from “drop” to “DROP“, which can still be interpreted by some systems, but not by others
These examples show that despite clear specification, unpredictable situations still occur in practice where data cannot be interpreted by a system. To get a grip on these problems, three measures are necessary:
- Direct communication about used and supported VDA 5050 features between all project participants, especially AGV manufacturers with control system developers.
- Feature customizing in the control system and AGVs, for example to be able to set that no battery management takes place in the control system for AGVs of type X or that AGVs of type Y cannot perform certain actions.
- Robust fault management and active notification in case of such problems, because especially during go-live and hypercare phase those situations will occur. It is important that the errors are reported directly in order to subsequently find a solution for them together.
Faults on AGVs
Unfortunately, in practice there are still situations in which the AGV has a malfunction that results in no further transport orders being processed. In the best case, this is also communicated to the control system so that it can plan with a reduced fleet, report the disruption and/or display it in a dashboard.
The VDA 5050 interface of Flexus recognizes such a disruption by the fact that an error object with the level “fatal” has been received. This level is defined in such a way that the AGV can no longer continue to drive independently and a human must intervene. However, the associated SAP bookings are not cancelled by the error at the AGV alone, since the transport orders can possibly be processed by other AGVs or by the same AGV after the error has been eliminated.
This is an example of the points that need to be discussed between the AGV manufacturer and the control system developer at an early stage. Flexus does not perform SAP bookings in case of malfunctions of AGVs, but it does in case of malfunctions of transport orders.
Driving job error
There are different possibilities within the VDA 5050 status message to communicate errors in transport orders to the control system. In Flexus, this has been solved as follows:
The actionStatus “FAILED” must be sent for the respective action (pick up or set down). This triggers the cancellation of the bookings in SAP. Additionally, error objects can be sent, which are considered optional by Flexus. If an error object exists in the same message, which matches either the actionID (pickup/dropoff) or the orderID (transport order number), this additional information will be stored for later analysis.
In this situation, however, it is assumed that the error exists only in the transport order and not in the AGV itself. This means that the order is cancelled, but the AGV is assigned a new transport order again.
Conclusion
In this article, some examples were used to show concretely how VDA 5050 messages can be interpreted in order to subsequently trigger postings in SAP WM or SAP EWM. VDA 5050 provides a very good basis for implementing technology, processes and data in a uniform manner. However, there is still coordination effort between AGV manufacturers and the control system as well as implementation effort when connecting SAP modules.
With the Flexus transport control system, at least the effort for the connection of various SAP modules can be reduced, although a direct exchange with AGV manufacturers is necessary for each project in order to coordinate special cases and the support of features.