All dialogs underwent a comprehensive redesign, resulting in an intuitive and consistent user interface across all views. This serves as a robust foundation for all future enhancements.
The implementation of the 2D map in the dialog “Drive driving order” enables the display of the current driving route with a single click. This allows the driver to orient himself intuitively.
The fields for entering information in the quick action dialogs were expanded in line with “Create orders”, allowing more diverse information to be provided for the driving order.
The new dialog “Drive tour” allows the selection of a configured route for a logged-in tugger train. Drivers can use this dialog to drive their tour and drop off and pick up load carriers.
To increase transparency, it is now possible to generate a PDF document for automatic download after manually creating a driving order. This allows handling units of manually created driving orders to be labelled quickly and correctly.
After a driving order has been set to error status due to an incorrect load carrier type, a follow-up action “Change load carrier type” can now be selected. After selecting the correct load carrier type, the driving order can be processed normally.
Multiple driving orders can now be validated simultaneously. For example, if several handling units are placed at a to-station, it can be configured so that the end user only has to scan the to-station once and can then place each handling unit one after the other. This reduces the number of scans required by the end user and consequently improves the efficiency of the process.
With two-step validation enabled, the repositioning location now only needs to be scanned once; after that, it is sufficient to scan the individual HUs, so that the repositioning location does not have to be recorded again for each HU.
For the tugger train module, a dialog combination consisting of “Select route,” “Assign tour,” and “Execute tour” is available for the end user. The tour optimized via the tugger train algorithm is processed using this new dialog combination.
Order Management
If a successor is to be assigned to an open order that has already been canceled or completed, the user is asked whether the predecessor should be acknowledged.
When the first order in a disrupted order chain is set back to “Ready,” the subsequent orders automatically change from ‘Disrupted’ to “Inactive.” Manual adjustment is then no longer necessary.
The weight of a driving order is now also considered in driving order assignment. The priority value is assigned in individually configurable steps, similar to the configuration of the age priority. For resource types, a maximum weight can be maintained to assign driving orders that exceed this limit to alternative resources.
A validation mechanism for source and destination location states was added to the capacity priority to prevent incorrect entries.
Using the priority settings, it can now be individually configured whether driving orders with a negative overall priority should still be assigned to a resource or not.
Status messages are only processed if the AMR reports the status “AUTOMATIC.” This ensures correct communication and prevents orders from being assigned to unavailable vehicles.
When creating driving orders, it is possible to enter a group as free text. These groups are considered separately from each other during route planning, i.e., one group is driven per tour. This allows driving orders for a tour to be categorized by theme.
Robots can now also be detected during an active parking request. In this case, the parking request is canceled and a new driving request is assigned immediately without having to reach the parking station.
The allocation logic with the options None, FIFO, and LIFO has been added to the nodes. When assigning transport orders, the system now checks whether the FIFO or LIFO flag is set and assigns priority to the oldest or newest order in the “Ready” status accordingly.
With the route train, you have the option of setting the route planning algorithm to “Basic.” The route starts and ends at the first node, with pickups and drop-offs occurring at the intermediate nodes. Alternatively, you can select the “Continuous” setting. The route starts and ends at the first node, with pickups and drop-offs occurring at the intermediate nodes.
A function called “Order Assignment” has been added. This allows the assignment of new driving orders (including battery and idle management) to be deactivated, while the targeted sending of robots to nodes remains possible.
SAP
For Flexus resources, the corresponding FlexGuide4 user is now also displayed in the order confirmation in EWM. In addition, synchronization between FlexGuide4 and EWM with regard to to-station changes has been improved.
The EWM area was extended by a table for packaging materials that are available for entering information during the creation of a handling unit.
Product Settings
The search options in the global search of FlexGuide4 were expanded so that the search bar returns more results, leading to a more intuitive search experience. For example, an entered term can now be recognized as part of various FlexGuide4 terms, which are then suggested.
Simulation
A central button above the tabs of the virtual bots allows for all bots to be started or stopped simultaneously.
Traffic Management
The logic has been adjusted so that necessary nodes are now also taken into account, even if they are not part of the route. This ensures more stable path checking and correct blocking of relevant nodes, which in turn optimizes the driving logic.
AMRs no longer detour to activated no-hold nodes to prevent vehicles from stopping in prohibited areas. If no other detour node is available, an alternative detour path is automatically calculated and integrated into the route.
An additional check has been implemented: If a blocked node that is not reserved is detected, further release is stopped. The added value lies in the correct consideration of reservations and the reduced risk of conflicts between vehicles.
The logic for selecting alternative nodes has been corrected: Nodes within the blocking radius are no longer selected, and only positions from which there is a valid path back to the destination are considered. In addition, the search for suitable alternative nodes has been supplemented with meaningful termination criteria and distance information.
Alternative nodes have been newly introduced and are now taken into account when assigning orders; if a destination point is occupied, a free alternative location is automatically searched for.
There is a new status for nodes called “Reserved” to clearly distinguish between blockages and crossing rules and to improve route planning.
Three new zone types have been introduced: “Exclusive Traffic Zone,” “Locked Traffic Zone,” and “Reporting Zone” are used to trigger signals or block areas.
Ressource Management
To make orientation easier, vehicles can now be displayed with appropriate images or symbols for each resource type. For this purpose, a central image selection for models and vehicle types has been integrated.
VDA5050
The MQTT broker is connected via an MQTT bridge and the SAP Cloud Connector to a local MQTT broker, to which the AMRs connect.
Bug Fixes
Dialogs
Various display and functional issues in the dialogs were fixed, for example the functionality of the side buttons in the minimized window view.
Order Management
Status errors within the predecessor–successor relationships of chained driving orders were improved. The interaction of chained driving orders is now globally predefined: If the predecessor order is canceled, all successor orders are also canceled. If the predecessor order is set to “Done”, the direct successor is set to “Ready”. In the event of an “Error” state, it can be decided separately for each order error whether the successor order inherits the error or not.
A bug in the transfer of the load carrier type within transport chains was fixed.
SAP
A validation mechanism ensures that the validation of a handling unit for an EWM driving order is only successful if the handling unit exists in EWM. Previously, handling units with non-existent identifiers could be overwritten.
The confirmation of product warehouse movements on EWM resources previously led to various errors due to issues in EWM synchronization. These issues have been resolved, and confirmation now works reliably.
A problem has been fixed whereby, in some cases, the “Due date” field in the data records was not filled in, even though the corresponding value was available in EWM. The data transfer has been corrected so that due date data is now reliably transferred.
Traffic Management
The sequence and logic of the check have been corrected so that nodes are now handled correctly even if path determination has not yet been completed. This ensures greater operational reliability and reliable reservation of travel areas.
Vendor Connector
The “Cancel Order” function has been corrected and now uses the appropriate POST request.
Ressource Management
When adding additional robots, the labeling of the map has been corrected: The map, which was previously labeled as “Label,” is now correctly displayed as “Road network.”
The backend crash caused by accessing the resource property “maxWeight” via the type without first loading the required type and weight data has been fixed. Missing data is now loaded or intercepted correctly, so that the system no longer crashes unexpectedly.
Product Settings
FG4 has been updated to patch levels that address a known denial-of-service vulnerability. This improves the stability and security of the application against such attacks.
