One mission of arculus is to bring the best technology to the world of intralogistics through continuous innovation and development. The new arculus Fleet Management Software is just another example of this dedication. This blog post explores the key features of the latest generation of our Fleet Manager and how it makes the user journey easier, as discussed by Georg Held, Senior Product Manager, Andy Brinkmeyer, Software Engineer, and Axel Jäger, Teamlead Frontend Development at arculus.

The Basics of the arculus Fleet Manager

Let’s discuss the basics. Can you provide an overview of the features in the new software?

Georg: Yeah. So, the arculus fleet manager consists mainly of three feature domains: the layouter, the simulator, and the operator. We provide the user with a layout editor and a layout manager so that they can create their project in the software. The simulator helps to set up a transport matrix and to simulate on the created layout, making it easier to understand the performance of a certain project. The operator is where the fleet manager handles all the arculees (our AMRs) and controls traffic.

What fundamental changes did you apply in creating the new generation of arculus fleet management software?

Georg: The user journey of the product was very important to us. We had a fleet manager already in the market in some projects. Considering our experience from those previous installations and from the customers who were using the software, we conceptually created a new fleet manager. The idea was to have one tool for the whole user journey from presales to operation by a coherent user interface. Perhaps Axel can provide more detailed insights here.

Axel: Yeah, an issue we had with our previous product was that when the user made some change, like creating an additional drive, and then checked the actual impact on the system, it seemed to take a long time to actualise. Now, for the new generation of the product, our goal was to make this as fast as possible. For example, you can immediately see the effect if you change something now. So you can run many iteration cycles in a shorter amount of time and find the best-performing layout.

Georg: And just to add on to that—actually, I’m among those user groups that greatly benefit from the new fleet manager because, in our test area, I am now able, to set up a test project within 30 to 45 minutes. I no longer need support from the development teams, which makes my work easier and allows the experts to invest their energies in other tasks without worrying about software usage.

arculus Fleet Manager: The Technical Aspects

Moving to the technical topics, how does the user interface of the fleet manager facilitate ease of use, especially for the various user groups and complex operations?

Axel: The first step a user typically takes is to create a representation of the shop floor. You can either do it by importing data from a CAD system, especially for a new factory building, or by using a robot to scan the existing environment. Once you have the shop floor layout, the next step is to place various objects onto it, such as driveways, stations, and other necessary features. For the user, the primary goal is to define the essential components of the factory or warehouse.

We aim to simplify this process as much as possible, ensuring the user’s intentions are easily captured. Then, for our internal representation inside the fleet manager, we convert the user input to a data structure that the robot can use.

Andy: Also, a key part of our system is ensuring that once a layout is validated, it works seamlessly without requiring further adjustments. When the user creates a layout, we run all necessary checks. If there are any issues, we inform the user about what they need to correct or modify. However, once the layout passes validation, it should function perfectly right away. The user shouldn’t need to make additional tweaks, for example, to prevent collisions or vehicle blockages.

Georg: In addition, one of our main goals, especially during this initial development phase, is to test the product with end-users. This means we develop the features Axel described, test them with users, see what works well and what doesn’t, and then make improvements accordingly.

How did you decide on the technology stack and architecture for the new fleet manager?

Andy: Perhaps let’s talk about the backend first – this is the part where we do all the complex algorithms, logic, and communication with vehicles and other connected systems. So, here we focused on what’s most important to our customers – reliability and robustness. No one wants to be woken up in the middle of the night because of a crash or have an entire shift blocked at some logistics centre due to any unexpected software issue.

In addition to robustness and safety, we prioritised performance since we are also targeting large fleets, potentially over 100 vehicles. We’ve successfully tested this in simulation, and it works like a charm! To achieve this, we built our backend on Rust, an emerging language that mainly focuses on safety and performance.

Axel: So, we have a web-based system for the front end. It is good because:

• We can then utilise the richness of a web-based frontend ecosystem
• It allows us to deploy the software on one server and access it with every client

Talking of the more specific technology stack, we went for a combination of angular, which is a Single Page Application (SPA) framework provided by Google. On top of that, we installed a 3D engine which has the potential to show a realistic digital twin of a facility.

Georg: The tech stack the team selected can run on standard business computers, such as mine, allowing me to test and verify our system. This also assures me that it will work on standard customer computers, which is crucial given the strict IT regulations our customers usually have. Therefore, our technology choice was influenced not only by detailed engineering decisions but also by market standards.

Were there any particular tools or frameworks that proved to be pivotal?

Andy: Coming from the world of systems programming, where languages like C++ and C are common, I know there is often a lot of overhead with tooling to get everything built and running. So, for me, choosing Rust as our main backend language was the best decision for our tool stack because it provides comprehensive solutions, eliminating the need for additional tooling for building and dependency management. It’s part of a robust and growing ecosystem, simplifying our development process and integrating well with our systems.

Georg: Well, I have one anecdote to share about this. So, Rust as a development language was also quite new to the team, and when we initially introduced it, one team member said that they would never learn it due to its conceptual differences from what they were used to. However, just two or three weeks later, those concerns vanished. It turned out to be surprisingly easy to onboard the team to Rust.

What is the role of VDA5050 in the new software? What benefits does it bring to users?

Andy: VDA5050 is a crucial part of our system because it’s a specification that outlines how a fleet management system should communicate with a robot. A lot of big companies have developed it together to specify how this should look. We at arculus also contribute to the development of the specifications, and it helps us in multiple ways.

• Defining Communication Standards

Firstly, it streamlines the process by defining communication standards, eliminating the need to devise our own protocols. With the adoption of the new fleet management system, we’ve phased out our legacy communication protocol in favour of VDA5050.

• Interoperability

Additionally, VDA5050 enhances interoperability. As an industry standard supported by various developers of fleet management systems and robots, it allows our system to interface with a wide array of different robots. This flexibility benefits our customers, who have the option to use our fleet management system with diverse robot models. Conversely, our robots also support VDA5050, ensuring compatibility with alternative fleet management systems if a customer chooses to switch.

Axel: Usually, when we supply such an automation system, it’s not a greenfield project. Instead it is an integration into existing setups and processes. So we contribute some parts of it and establish interfaces with other parts of the factory floor. Sometimes, we even encounter mixed traffic. And, of course, if we have our fleet manager with our robots, we can nicely visualise them on a canvas. However, there are instances where one of our vehicles cannot operate due to the presence of vehicles from different vendors or systems serving different purposes.

To ensure transparency for users and explain why a specific vehicle is not moving, we must visualise all vehicles. This also includes the ones that are not under our direct control. VDA5050, being a standard communication protocol, enables us to access information from all vehicles across the factory floor. Moreover, it facilitates better decision-making and system management.

Performance Optimisation of the New arculus Fleet Manager

Let’s talk performance. What strategies were employed to optimise the performance of the new fleet manager, particularly in handling large fleets in complex environments?

Andy: One of our primary goals in developing the fleet management system was to ensure it could support large fleets exceeding 100 vehicles. So, we decided to employ modern algorithms right out of the academic world. These work on a detailed level by subdividing space into smaller regions. Unlike our competitors, our system doesn’t just check where we are driving; it also considers possible future scenarios of vehicle locking and congestion.

This approach sets us apart in the industry, as we’re among the few working with this foresight. Of course, we had to adapt these algorithms from academia to suit real-world complexities. Fortunately, initial simulations have yielded promising results as we’ve successfully controlled a fleet of 150 vehicles on potential layouts.

How does the Fleet Manager’s backend handle real-time data processing and decision-making?

Andy: That’s a great question! For a fleet of robots driving around, you don’t have much time to tell them what to do. If they don’t get another command, they will just keep standing there. The robots will not process any order, and will not deliver any material. So we need to react fast.
From the operational side, we do that with:

• Our modern tech stack, which, combined with our algorithms, allows super-fast processing and decision-making
• VDA5050 communication protocol that helps us directly communicate with the robot and send updates as quickly as possible

However, the robots also generate a lot of data while driving around and operating. This data can then be used to further evaluate, monitor, and determine what to do next in real-time.

Georg: When you deal with real-time data, you have to think about what this really means. What do you think, Andy?

Andy: Yes, it depends on the type of data you’re looking at. For instance, in terms of visualisation, which is Axel’s department, the robot sends updates multiple times per second. However, other parts of the communication are more event-driven. For example, if a robot gets clearance to drive to a specific location, it passes certain waypoints along the way. It updates us when it reaches a certain waypoint, saying, “Hey, I reached it.” This allows us to run additional logic, potentially change something, or simply command it to continue driving.

Georg: That’s great input, and this is exactly what I meant earlier. You need to create several abstraction layers to effectively handle and expose the relevant data to users. I mean, the data acts as a digital twin of the site—whether it’s a warehouse, factory, or another facility. It shows what’s happening in real time. You can iterate how crucial it is to process and then present the data to the user if we want to display the state of a robot, its battery level, its current location and its route.

Axel, perhaps you can expand on this since, as you already mentioned, the layout canvas and how it works.

Axel: Yeah, this is definitely important from the user’s perspective. When you give a manual command to the robot, such as: ‘drive to a location’ or ‘head to a charging station’, you would want to see immediate feedback. However, the robot has to perform several actions before it can start moving, such as switching sensors and releasing brakes. If you’re near the robot, you can hear these actions and know there is a response. However, if you’re at your computer, every fraction of a second of delay matters.

Now, feedback within several hundred milliseconds would be acceptable. However, if it takes several seconds, the user will perceive the system as sluggish or broken. While it’s nice to have an animated UI, it’s crucial the system provides immediate and clear responses to initiated actions. This ensures the user’s trust in the system.

This is all about the arculus Fleet Management Software. Watch the entire video here.