Tips for implementing the VDA 5050 standard interface in your SAP system
Are you wondering what exactly VDA 5050 is? – Many explanations focus on the various actors, processes and data. What is often mentioned only briefly or not at all are technical details such as the method to be used when transmitting messages. In order to be able to adequately implement these comprehensive technical aspects in your company, you should pay attention to a few points, especially when integrating with an SAP ERP system.
In this article, we will go into more detail about the technical requirements and infrastructure necessary to connect AGVs to your SAP ERP via a VDA 5050 compliant interface. First, we look at the technical specifications of VDA 5050 and how SAP supports them. Then, we derive an infrastructure from this, which has already proven itself in practice in many companies over the past weeks and months. The last part of the article summarizes the challenges and recommendations for your new projects when integrating AGVs into SAP.
Technical specifications in the VDA5050
MQTT, broker and data types
The detail that has the most serious impact is communication via the message protocol MQTT (“Message Queuing Telemetry Transport”). This is already standardized and is mainly used for machine-to-machine communication. It is often used, for example, to exchange sensor data from vehicles or machines. In the process, JSON data packets are sent to different channels, so-called “topics” (“publish”). At the same time, any systems, machines or AGVs can listen to these channels in order to receive these messages (“subscribe”).
In order to implement this “publish-subscribe” principle, you need a central instance, the MQTT broker.
The main goal of VDA 5050 is the integration of several different AGVs and control systems. To ensure that each of the actors sends correct MQTT messages and that the recipient can in turn interpret them uniformly, the JSON data packets are also specified.
Not only which data can or must be present in these, but also the respective identifiers and their data types are specified. Nothing may be changed in these, because according to VDA 5050 there is a “claim to correctness with these, on which one can rely as a developer of the interface“. Every AGV and control system, including those in SAP, must therefore support these identifiers and data types exactly.
Support in SAP – integration challenges
Directly with the most important requirement, the support of the MQTT message protocol, considerable restrictions exist. Even the MQTT client, i.e. only the sending and receiving of messages, is only available in ABAP Platform 1809. However, most of our customers and partners still have older systems, which is why this already makes the integration of VDA 5050 into SAP ERP very difficult.
In addition, an MQTT broker must also be operated for new projects, which receives all messages and then distributes them to MQTT clients. This is currently only possible with great difficulty and effort within SAP. For this reason, at least one system, the MQTT broker, must run outside the classic SAP landscape. An external adapter is also necessary for older SAP systems, which converts the MQTT protocol into SOAP or OData, for example.
One last point to mention about the MQTT data packets are the identifiers already mentioned: Some of the SAP interfaces (SOAP) convert them to uppercase letters. “orderUpdateId“, as defined in VDA 5050, is converted to “ORDERUPDATEID” in SAP. This small detail often causes problems with integrations from external systems into SAP ERP and must be solved here as well.
VDA 5050 Infrastructure with SAP ERP
The following image shows an infrastructure that can be flexibly combined with all SAP versions as well as any other VDA 5050-compliant systems. The advantage is the flexibility: Through the Flexus MQTT adapter, this can also be integrated into already existing system landscapes or new systems can simply be added.
The classic VDA 5050 infrastructure consists of the following actors:
- MQTT broker: This central instance receives all messages and forwards them to corresponding MQTT clients
- AGVs: These are MQTT clients that send messages to certain topics at the MQTT broker and in turn receive others
- Control system in SAP: This is also a client that is identical to the AGVs, receives messages from the MQTT broker and sends them back to the broker.
Due to the technical limitations of SAP described above, we have specially developed the Flexus MQTT adapter. This is in turn a normal MQTT client that receives all messages from the broker that may be of interest to the control system in SAP. These messages are converted from the MQTT format and then a SOAP or OData interface of the SAP system is called. In this way, old SAP systems can also be connected. The response of the SOAP or OData call is in turn converted into an MQTT message and sent to the MQTT broker. Individual fields can be modified beforehand, for example, the VDA 5050-compliant identifier “orderUpdateId” can be created again from “ORDERUPDATEID“.
Challenges and recommendations for new projects
Purely from a technical perspective, the biggest challenge is to harmonize MQTT technology with your SAP system. Depending on the SAP version used and your current project status, there are various options. The most flexible and also our recommendation for you is to use an adapter that translates and communicates between MQTT infrastructure and SAP.
Another point that must be clarified early on with all project participants is the MQTT broker: Who provides, supports and operates it? Who provides a test system and where are the boundaries of responsibility? To track problems, it is absolutely necessary to define these responsibility boundaries precisely and then also ensure that these boundaries are monitored and logged. In this way, in the event of messages not arriving or incorrect messages, it can be traced in which system the error occurred.
Of course, a multitude of other challenges exist, such as the handling of faults on AGVs or driving orders, the same understanding of nodes and edges, the interpretation of path blocks, etc. Since these points relate more to the procedural than to the technical area of VDA 5050, they will be described in more detail in another article.
Excursus: SAP Cloud and SAP HANA XSA
As can be seen in the infrastructure picture, other systems are needed apart from AGVs and SAP. This leads to problems in some companies when all processes, policies and user administrations are designed for SAP systems. It is often problematic to use “simple, small systems” outside of SAP, as this does not allow for round-the-clock availability and competent maintenance and support.
However, new possibilities have also developed in the SAP environment: both in the SAP cloud and on SAP 4/HANA on-premise systems, applications can be installed and run encapsulated and independently of the SAP ERP. The advantage of these applications is that they still run in the SAP landscape, are supported by SAP administrators and also enable SAP server administration. At the same time, new technologies can be used and thus also an MQTT broker or the Flexus MQTT adapter can be used in the SAP cloud or a local SAP 4/HANA installation.
A separate article on this topic will also be published shortly. So sign up for our newsletter right now to be notified when more information about VDA 5050 with SAP ERP or the SAP Cloud appears!