Procedures for managing the cargo space of a delivery vehicle, cargo space management system and delivery vehicle

Abstract

The disclosure generally relates to a method (54) for managing the cargo space of a delivery vehicle (10), a cargo space management system (12) for a cargo space (14) of a delivery vehicle (10), and a delivery vehicle (10). A route plan (122) of the delivery vehicle (10) is received by a server (38). A respective cargo space position (48) at which a respective object (18) placed or to be placed in the cargo space (14) is to be positioned is determined by an object placement logic (34) before or during the placement of the respective object (18) into a cargo space (14) of the delivery vehicle (10), taking into account at least the route plan (122). A respective cargo space position signal is output by a signaling device (52). The cargo space position signal indicates the respective determined cargo space position (48) for the respective object (18).

Description

[0001] The disclosure generally relates to a method for managing the cargo space of a delivery vehicle, a cargo space management system for a cargo space of a delivery vehicle, and a delivery vehicle.

[0002] Delivery vehicle drivers have various tasks that they typically have to perform multiple times per delivery trip (sometimes more than a hundred times a day). These tasks include, in particular, loading the cargo space with packages based on a "mental map" to ensure that the arrangement of the packages within the cargo space best matches the delivery route. In addition, the tasks include (often) re-sorting the packages several times during the delivery trip and at least locating the package corresponding to a delivery location. These repetitive steps require a significant amount of time.

[0003] To intuitively place the parcels in the cargo space, the delivery driver uses a "mental map" based on the number of parcels for this route, the parcel size, the parcel volume, the available cargo space, the distance to be covered, and often other factors. The goal of the "mental map" is to optimize the loading and unloading of the cargo space in terms of the required time. However, each delivery driver has their own subjective routine, which also depends on the delivery driver's experience. Therefore, taking the "mental map" into account represents a burden for the user of the delivery vehicle on the one hand, and on the other hand, it is generally suboptimal because it is based on the subjective perception of the respective user (delivery driver). This causes inefficiencies in the logistics chain, which therefore limit the operational efficiency of the delivery process.

[0004] US 2022 / 0237557 A1 discloses a system for delivering shipments that optimizes routes for parcel delivery. The system is based on connecting each parcel to a sensor device during the sorting process. However, this requires additional devices and activities. Furthermore, the sensor devices must be removed before delivery, making the system complex.

[0005] US 2016 / 0189087 A1 discloses a system for placing packages in a cargo hold. A logic system determines a cargo hold position for a package, which can be displayed to the user using a light device. The packages can be scanned using a barcode scanner. However, this limits the system's capabilities both in terms of package detection and cargo hold position determination. The cargo space is insufficiently utilized because the characteristics of the cargo hold's shelving system are not taken into account. Furthermore, the delivery route is dynamic, which can affect the stability of the package arrangement within the cargo hold. However, such influences are not taken into account by the system.

[0006] US 2020 / 0074404 A1 discloses a delivery vehicle with movable loading compartments to ensure rapid unloading. However, such delivery vehicles incur high operating costs.

[0007] US 11,377,070 B2 discloses a system for determining the load of a cargo hold. This system takes into account the dimensions of the packages and the characteristics of the cargo hold. However, this neglects many other influences on the optimization of object placement.

[0008] US 2020 / 0023755 A1 discloses a generic system for cloud-based communication.

[0009] The achievable operational efficiency of existing delivery processes is therefore limited. There is therefore a need to eliminate or at least reduce the disadvantages of existing methods and load space management systems. In particular, there is a need to optimize object placement beyond existing approaches in order to optimize delivery processes by leveraging object placement.

[0010] The problem is solved by the subject matter of the independent patent claims. Advantageous embodiments are specified in the dependent patent claims and the following description, each of which, individually or in (sub)combination, may represent aspects of the disclosure. Some features are explained with regard to methods, others with regard to devices. However, the corresponding aspects are to be transferred reciprocally in a corresponding manner.

[0011] According to one aspect, some embodiments of the disclosure relate to a method for managing the cargo space of a delivery vehicle (ZF). The method comprises at least the following steps: A route plan from the ZF is received by a server, in particular by a load space management system (WMS).

[0012] The identities of objects brought or to be brought into a cargo space of the ZF are determined.

[0013] A respective loading space position at which a respective object brought into or to be brought into the loading space is to be placed is determined by an object placement logic before or during the introduction of the respective object into the loading space of the ZF, taking into account at least the route plan.

[0014] A respective cargo space position signal is issued by a signaling device. The cargo space position signal indicates the specific cargo space position for the respective object.

[0015] This provides a method that can optionally independently detect objects placed in the cargo space and, in any case, independently determine the cargo space positions for the objects placed or to be placed, taking into account at least the route plan but optionally also other information, before or during loading of the cargo space of the ZF, so that the delivery process is optimized. The optimization can be optimized equally with regard to both the loading and unloading processes. In addition, the respective cargo space position is indicated to the user of the ZF via a signal device. The user of the ZF is therefore freed from several tasks that were previously performed mentally, such as positioning the objects according to the route plan. This reduces the strain on the user and increases comfort.Additionally, the delivery process is optimized because it is based on objective criteria, thus increasing operational efficiency. For example, the process makes it possible to determine the optimal route for loading objects into the ZF based on object placement logic, allowing for greater flexibility in the allocation of drivers and routes and increasing the efficiency of all drivers in terms of loading time.

[0016] In an alternative, the step of determining the identities of objects loaded into a ZF cargo space can be omitted. In this case, information from at least the route plan and optionally also other information can be used to determine cargo space positions for objects that are to be loaded into the ZF cargo space according to the route plan. In this case, in particular, the cargo space positions of the corresponding objects can be determined using object placement logic before the objects are even loaded into the ZF cargo space.

[0017] According to a further aspect, some embodiments of the disclosure also relate to an LVS for a cargo space of a ZF. The LVS has at least one control device (RV) with a communication device coupled thereto and a signaling device. The RV is coupled at least to the signaling device. The RV is configured, based on the communication device coupled thereto, to receive a route plan of the ZF from a server. The RV has object placement logic, based on which it is configured to determine, taking into account at least the route plan, a respective cargo space position at which a respective object introduced or to be introduced into the cargo space is to be placed. The RV is configured, based on the signaling device, to output a respective cargo space position signal. The cargo space position signal indicates the respective determined cargo space position for the respective object.

[0018] The advantages achieved by the method described herein are also achieved by the LVS in a corresponding manner.

[0019] Preferably, the RV can be configured based on the object placement logic to determine a respective loading space position for an object to be loaded into the loading space, taking into account at least the route plan, before the object is even loaded into the loading space of the ZF. This opens up, in particular, the possibility of determining the loading space positions in advance, independent of the loading process, for example, with the aid of external components, such as a server, to which parts of the object placement logic can be outsourced.

[0020] Optionally, the RV can be configured, based on the sensor to which it is coupled, to determine the identities of objects placed in the cargo area of ​​the vehicle, for example, using the RV's object identification logic. The RV can then also determine the cargo area positions of the objects during or after they have been placed in the cargo area of ​​the vehicle.

[0021] In this case, a cargo space can be understood as any suitable volume of the vehicle, preferably enclosed volumes, which is suitable for receiving and storing objects.

[0022] In this case, loading space positions can be understood as sub-volumes of the loading space where objects can be placed within the loading space. In particular, the objects can be placed at the loading space positions in such a way that they typically do not leave the respective loading space position or only leave it insignificantly during the delivery process of the ZF. Whether they remain permanently in the loading space position during the delivery process of the ZF can also depend on the properties of the objects, for example their weight. Loading space positions can be defined in relation to other structures of the loading space, for example a shelving system arranged within the loading space or compartments thereof. In general, a loading space position is defined according to a Cartesian coordinate system by three relative spatial coordinates within the loading space. In addition, each loading space position also has a certain extent.In this respect, a cuboid-shaped volume can be assigned to each loading space position.

[0023] In this case, objects can be understood to mean, in particular, packages, items of cargo or other items that are to be arranged and transported in the cargo space.

[0024] In this case, the route plan of a ZF can be understood as an information catalog containing delivery locations that correspond to the delivery addresses of objects and that the ZF must travel to so that the objects can be delivered to the respective delivery locations. Obviously, within the route plan, multiple objects can be assigned to individual delivery locations, since they are to be delivered to the same delivery address. However, the route plan can also contain information about the objects, such as their dimensions, photos or representations of the objects, and / or their weight.

[0025] Preferably, the route plan can be received from the server via a wireless communication connection, for example, a cellular connection or a Wi-Fi connection. In particular, the communication connection can be established via the Internet.

[0026] Optionally, the server can be a cloud server configured to transmit route plans for different ZFs. The server can also have at least one data processing device for creating the different route plans. The server can further be coupled to a database containing information enabling the server to create or determine the different route plans.

[0027] The sensor of the LVS is preferably an image acquisition sensor, for example a camera. The camera can be configured to capture image data in the visible spectrum. Of course, multiple sensors can also be provided, for example multiple cameras. The sensors can together form a sensor system, for example a camera system. The cameras of the camera system can preferably have different properties. For example, a first camera can be configured to capture RGB data, CMYK data, or data from other color tables, i.e., image data based on different contrasts, colors, or brightness differences. On the other hand, at least one camera can be configured to capture depth information. This means that the camera is configured to display a distance of an object from the camera in the output image data or corresponding data.The captured image data is transmitted from the cameras of the camera system to the RV of the LVS. The RV can be configured based on the received sensor data to identify various objects, such as packages or people.

[0028] In some embodiments, the identity of an object is determined based on object identification logic of the RV of the WMS. The identity of an object can be determined, for example, based on the object's external dimensions. Alternatively, the identity can also be identified, for example, based on a barcode or similar serial identifier, such as a company logo or other imprint, located on the object's external surface. Other properties that can be used to identify an object are the shape, color, or other geometric characteristics that characterize the object.

[0029] In some embodiments, the object identification logic of the RV comprises a machine learning algorithm. Based on the algorithm, objects can be identified. The algorithm is capable of distinguishing various properties of objects from the sensor data of a sensor, for example, a camera. The algorithm can be trained accordingly to distinguish and identify objects based on these properties. The algorithm can also be trained during ongoing operation. This means that training can take place not only during individual loading and / or unloading operations, but also over extended periods of several days or weeks and a high number of loading and / or unloading operations in order to learn the various properties and continuously optimize the object identification logic.A neural network can be used as the basis for the algorithm within the object identification logic of the RV.

[0030] Preferably, the object identification logic of the RV is configured to be at least partially executable as a cloud server mechanism. The RV is connectable to the cloud server. In particular, the underlying algorithm of the object identification logic can be executed on the cloud server. The RV then transmits the corresponding sensor data from the sensor, for example, the camera, to the cloud server, where it is evaluated to identify specific objects within the cargo space. This creates the possibility of supplying the object identification logic with data from different RVs that were recorded in relation to different WMS. Since the amount of data made available to the object identification logic is thereby significantly increased, the decision-making processes underlying the object identification logic are refined.In particular, the algorithm can be further trained using machine learning during operation, thereby increasing the confidence of the individual identification of an object.

[0031] The RV of the WMS has at least one data processing device. Using the data processing device, the RV can perform various calculation processes, for example, object identification logic for detecting and identifying objects located in the cargo space, as well as object placement logic for determining cargo space positions for the objects within the ZF's cargo space. Parts of the determination or calculation processes can be outsourced to the cloud server. In this case, the RV simply transmits corresponding data records to the cloud server so that it can perform the corresponding determination processes. The RV then receives data from the cloud server reflecting the results of the respective processes.

[0032] Optionally, a quantity notification is issued within the process via a human-machine interface (HMI). The quantity notification indicates, with regard to the route plan, whether the identities of all or only a subset (number), and in particular which subset, of the objects underlying the route plan have been determined. This provides the WMS user with immediate feedback on the quantity of objects brought into the cargo space that the WMS was able to automatically identify. The user then only needs to check whether the number of identified objects matches the quantity brought in, and thus knows whether additional measures are necessary.For example, the user can manually record and identify individual objects and provide the corresponding information to the WMS so that the WMS can then determine a corresponding loading space position for an object not automatically identified by the WMS. For this purpose, the WMS can have a manually operable sensor device or identification device, for example a scanner. The identification of an object can also be semi-automatic. For example, a user can record data about an object, for example using the scanner, and transmit it to the WMS. The WMS can compare the received data with the route plan to identify the object. For example, the identification of the object can be guaranteed after a barcode of the object has been recorded, since the corresponding data can be stored in the route plan.

[0033] The MMS can be a multimedia device of the ZF. The MMS can have at least one image output device and a loudspeaker. Information output via the MMS can be provided via acoustic (beep, voice, etc.), visual (image on a display, LED strip, spotlight, pointer, etc.), or tactile (smart clothing with corresponding vibration, etc.) cues.

[0034] Optionally, the MMS can also be external to the ZF. For example, the MMS can be part of a mobile device that is at least indirectly linked to the WMS, e.g., wirelessly. The connection can optionally be established via a cloud server. The MMS enables a variety of display options for the cargo space and the display of cargo space positions, as well as the transmission of information such as quantity notifications. These can be customized in a variety of ways to increase user convenience.

[0035] The loading space position signal is preferably multi-level. In particular, the signaling device can be multi-component. This means that the loading space position signal can initially have a coarse signal that simply indicates that a specific loading space position is located within a higher-level section of the loading space. In addition, the loading space position signal can have a fine signal that indicates a specific section within the section defined by the coarse signal. The section can then correspond to an individual loading space position. Optionally, further gradations between the coarse signal and the fine signal are possible. To output the various signals, the signaling device can be multi-component. For example, a first light source, such as a headlight, can be used to output the coarse signal.Additionally, a second light signal, such as a laser or an LED strip, can be used to emit the fine signal. Alternatively, a single signaling device configured to emit different signal types sequentially and / or simultaneously can be used. For example, an emitted laser beam can be split to provide different signal types. The multi-stage design of the cargo space position signal makes identifying a specific cargo space position particularly intuitive. This can increase the operational efficiency of loading or unloading processes.

[0036] In some embodiments, the object placement logic additionally determines the cargo space position based on at least one of the following: - ZF vehicle information; - Object properties of the objects underlying the route plan; - Stability criteria of the objects in the cargo space, which indicate the reliability of the position of the objects arranged in the cargo space during movement of the ZF; - a removal distance to be provided between at least some objects; - an estimated time required to load the cargo space; - an estimated time required to unload the cargo space; - Loading space positions of objects brought into the loading space; - a current traffic situation regarding the route plan; - an expected traffic situation with regard to the route plan at the time of a delivery process corresponding to the route plan; and - Route preferences and / or loading preferences of a driver or operator of the ZF.

[0037] The vehicle information from the ZF can, in particular, include the size of the cargo space, in particular the width, height, and length, optionally including local obstacles in the cargo space, such as wheel arches. The vehicle information can also include the arrangement and dimensions of compartments of a shelving system in the cargo space, in particular their width, height, and length, as well as the loading limits of the shelving system or its loading compartments. Additionally, the vehicle information can include a total loading limit of the delivery vehicle and / or a number of loading compartments.

[0038] The object properties may include, for example, the dimensions of the objects, their weight, their type, such as roll, box, bag or envelope, their delivery address and / or their resistance.

[0039] The stability criteria of the objects in the cargo space indicate the positional reliability of the objects arranged in the cargo space during a movement of the ZF. This means that the stability criteria indicate the positional accuracy of the objects in their respective cargo space positions. Positional accuracy can be influenced, for example, by neighboring objects or by the packing density. In addition, the stability criteria can also indicate the extent to which a specific object can ensure positional accuracy for neighboring objects. For example, a lightweight envelope cannot usually guarantee positional accuracy for neighboring objects. In contrast, a cuboid box with a minimum weight can usually very well ensure the positional accuracy of a neighboring, parallel-arranged object of smaller mass.The stability criteria can also include the orientation of the objects at the loading space positions. A cuboid-shaped object typically has one side with a smallest surface area, a second side arranged orthogonally to it with a largest surface area, and an additional side with a central surface area. The positional accuracy of the object then depends, among other things, on which side the object is placed at the loading space position. Thus, the stability criteria encompass a variety of aspects, such as how reliable the respective distribution of objects at different loading space positions is with regard to the overall delivery process.

[0040] The removal distance can be understood as a distance that must be provided between at least some objects so that the objects can be removed by a user from the loading space positions. For example, the removal distance can be such that a user can grasp an object.

[0041] The estimated time required for loading and unloading the cargo space is the time required for loading or unloading the cargo space with all objects corresponding to the route plan.

[0042] The object placement logic can also consider existing cargo space positions of objects. For example, a user can place a specific object in a preferred cargo space position independent of the WMS, e.g., because the corresponding object is of higher importance. The object placement logic can then distribute the remaining objects to other cargo space positions and exclude the blocked cargo space position from the assignment of further objects. Alternatively, a number of cargo space positions may be blocked by other means. The WMS considers such blocked cargo space positions and distributes the remaining objects to the remaining available cargo space positions.

[0043] The current or expected traffic situation can influence the duration of the entire delivery process, for example, the corresponding unloading procedure. Furthermore, the traffic situation can influence the movement of the ZF, which in turn can affect the positioning accuracy of objects in the loading space. Thus, the traffic situation can interact with the stability criteria of the objects in the loading space.

[0044] Route preferences and / or user preferences may indicate that certain delivery routes should be considered. For example, it is known to adapt delivery routes in such a way that (in right-hand driving environments, e.g., Germany) left turns are avoided as much as possible. User preferences may, for example, indicate that particularly heavy objects should be placed in a cargo space position close to a cargo space exit, even though this does not seem sensible in terms of the route planning itself. The route preferences and / or user preferences may, in particular, be based on empirical values ​​that can be taken into account by the object placement logic of the WMS's RV.

[0045] As a result, the object placement logic is configured to determine the respective loading space positions for the identified objects. The overarching goal of the object placement logic is to optimize the delivery process as a whole. As shown in the example, optimization can be influenced by many factors. By taking the various factors into account from a multifaceted perspective, the RV's object placement logic is configured to determine loading space positions for the objects within the loading space more effectively than before, thus increasing the efficiency of the overall delivery process compared to existing approaches. Furthermore, user convenience is enhanced because, for example, user preferences can also be taken into account.

[0046] In some embodiments, the RV's object placement logic comprises a machine learning algorithm. Based on the algorithm, loading space positions for the objects can be determined. The algorithm is capable of considering various influencing factors when determining the respective loading space position. The algorithm can also be trained accordingly to determine the optimized loading space position of an object. The algorithm can also be trained during ongoing operation. This means that training can take place not only during individual loading and / or unloading processes, but also over extended periods of several days or weeks and a high number of loading and / or unloading processes in order to learn the various properties and continuously optimize the object placement logic.A neural network can be used as the basis for the algorithm within the object placement logic of the RV.

[0047] Preferably, the object placement logic of the RV is configured to be at least partially executable as a cloud server mechanism. The RV can be coupled to the cloud server. In particular, the underlying algorithm of the object placement logic can be executable on the cloud server. The RV then transmits the corresponding data of identified objects and optionally also further information, such as the route route or the aforementioned influencing factors, to the cloud server. In some embodiments, the data of the identified objects or at least some influencing factors can already be present on the cloud server, for example, if the cloud server also at least partially executes the object identification logic. This creates the possibility of supplying the object placement logic with data from different RVs that were recorded with reference to different LVS.Since the amount of data available to the object placement logic is significantly increased, the decision-making processes underlying the object placement logic are refined. In particular, the algorithm can be further trained using machine learning during operation, thereby increasing the confidence in the individual determination of an object's cargo space position.

[0048] In some embodiments, the loading space positions of objects placed in the loading space can be detected using at least one sensor. The sensor is coupled to the RV of the WMS. The sensor can be the same sensor that is used to detect objects placed in the loading space. This means that the sensor can also be used to check whether objects are actually located at certain loading space positions. For example, during the delivery process (e.g. while driving), it can be checked whether an object is still located in its original loading space position. If this is not the case, the RV can update an entry for the object in a corresponding database with regard to its loading space position. This makes it possible to output an updated loading space position signal when the object is unloaded, allowing the user to remove the actually applicable object.This further increases the efficiency of the delivery process. Furthermore, it may happen that new objects are brought into the cargo space during the delivery process according to the route plan, for example, because the ZF user is accepting a return shipment. Because the sensor can detect cargo space positions, it is possible to determine which cargo space positions are currently available and how the newly introduced object should be optimally positioned within the cargo space at a specific cargo space position.

[0049] The object placement logic is preferably configured to determine a respective loading space position in real time, either adaptably or repeatedly. The loading process of the ZF can comprise several individual loading steps, each of which involves placing several objects into the loading space. This can be due to the fact that the user cannot place the entire quantity of objects into the loading space in a single step. Between these steps, the WMS can repeatedly determine the respective loading space positions using the object placement logic. This makes it possible to take into account that certain loading space positions are no longer available because they are already occupied by objects. Alternatively, for example, an update of the route plan can result in a different distribution of the objects being more advantageous, in line with changed loading space positions.The repeated determination of the loading space positions by the object placement logic therefore enables a gain in efficiency.

[0050] Optionally, a respective unloading position signal is issued by a signaling device at a delivery location underlying the route plan. The unloading position signal indicates the respective loading space position for the respective object that is to be unloaded from the loading space at the delivery location. The signaling device can be the same signaling device that can also issue the loading space position signal. This enables rapid location of the respective object to be unloaded, thereby increasing the operational efficiency of the delivery process.

[0051] Preferably, the unloading position signal can be multi-stage in a manner corresponding to the loading space position signal.

[0052] In some embodiments, the cargo space position also indicates an orientation of an object to be placed in the cargo space. The respective cargo space position signal additionally indicates the orientation of the respective object. Orientation here refers, for example, to the placement of an object according to a specified orientation, such as placing the object on the side with the smallest surface area. This can influence, in particular increase, the packing density. In addition, the stability criteria can be influenced, for example, if an object is to be arranged on the side with the largest surface area.

[0053] The cargo space position signal can also be multi-stage to additionally indicate the orientation of the object to be placed in the cargo space. For example, the cargo space position signal can have a specific signal sequence that can encode a specific orientation of the object.

[0054] Preferably, the loading space position also indicates a stacking of multiple objects to be placed in the loading space, depending on the available loading area and the objects to be placed in the loading space based on the route plan. The respective loading space position signal additionally indicates the stacking of multiple objects to be placed in the loading space. This allows the packing density within the loading space to be further increased. For example, stacking objects is advantageous if several objects have the same delivery address and therefore need to be unloaded at the same delivery location. This creates the possibility of removing the objects from the loading space together.

[0055] The WMS preferably has at least one sensor that is configured to detect which respective object is removed from a specific loading space position by a user (delivery person) during an unloading process from the loading space of the ZF. A control device coupled to the sensor can then determine, depending at least on the information from a route plan (but optionally also further information, such as a user input) and the data received from the sensor, whether the user is removing an object that corresponds to the route plan from the loading space from the specific loading space position. For example, information stored in a storage device coupled to the control device that indicates the specific loading space position at which the object was positioned when it was loaded into the loading space of the ZF.In other words, it can be determined whether the correct object is removed by a user.

[0056] In some embodiments, depending on whether the applicable or a non-applicable object is removed by the user from a cargo space location, a notification can be triggered by the control device, for example, via the MMS. The notification can, in particular, indicate whether the applicable or a non-applicable (incorrect) object is / has been removed by the user.

[0057] Optionally, the method is at least partially computer-implemented. This means that the essential control mechanisms can be executed with the aid of one or more data processing devices.

[0058] According to a further aspect, the disclosure also relates to a computer program product comprising instructions that, when executed by a computer, cause the computer to perform the method as described herein. The advantages achieved by the method described herein are also achieved correspondingly by the computer program product.

[0059] According to an additional aspect, the disclosure also relates to a computer-readable storage medium comprising instructions that, when executed by a computer, cause the computer to perform the method as described herein. The advantages achieved by the method described herein are also achieved correspondingly by the computer-readable storage medium.

[0060] In some embodiments, the LVS is configured to perform the method as described herein.

[0061] According to a further aspect, some embodiments of the disclosure also relate to a delivery vehicle with a cargo space and a WMS as described herein. For the purposes of the disclosure, delivery vehicles may include, in particular, land vehicles, namely, but not limited to, off-road and road vehicles such as passenger cars, buses, trucks, and other commercial vehicles. Delivery vehicles may be manned or unmanned.

[0062] All features explained with regard to the various aspects can be combined individually or in (sub-)combination with other aspects.

[0063] The disclosure as well as further advantageous embodiments and developments thereof are described and explained in more detail below with reference to the examples shown in the drawings. They show: - Fig. 1 a simplified schematic representation of a delivery vehicle with a cargo space management system according to an embodiment of the disclosure, - Fig. 2 a simplified schematic representation of a method for managing the cargo space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 3 a simplified schematic representation of a method for object identification of objects as part of a method for cargo space management of a delivery vehicle according to an embodiment of the disclosure, - Fig. 4 a simplified schematic representation of a method for loading a delivery vehicle as part of a method for managing the load space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 5 is a simplified schematic representation of a method for unloading a delivery vehicle at a delivery location as part of a method for managing the load space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 6 a simplified schematic representation of the exemplary communication structure of a cargo space management system in the context of a method for cargo space management of a delivery vehicle according to an embodiment of the disclosure, - Fig. 7 shows a simplified schematic representation of the system components of the cargo space management system arranged in the delivery vehicle as part of a method for managing the cargo space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 8 and Fig. 9 shows a common simplified schematic representation of a method for loading a delivery vehicle as part of a method for managing the load space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 10 is a simplified schematic representation of a method for unloading a delivery vehicle at a delivery location as part of a method for managing the load space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 11 is a simplified schematic representation of a method for determining the loading space position for objects as part of a method for managing the loading space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 12 shows a simplified schematic representation of a method for determining the loading space position for objects as part of a method for managing the loading space of a delivery vehicle according to an embodiment of the disclosure, - Fig. 13 a simplified schematic representation of a method for determining the loading space position for objects as part of a method for managing the loading space of a delivery vehicle according to an embodiment of the disclosure, and - Fig. 14A and Fig. 14B simplified schematic representations of object distributions of objects in a loading space of a delivery vehicle as a result of various methods for determining the loading space position for objects.

[0064] The following detailed description, taken in conjunction with the accompanying drawings, in which like numerals refer to like elements, is intended to describe various embodiments of the disclosed subject matter and is not intended to be the only embodiments. Each embodiment described in this disclosure is merely an example or illustration and should not be construed as preferred or advantageous over other embodiments. The illustrative examples contained herein are not exhaustive or limit the claimed subject matter to the precise forms disclosed. Various modifications of the described embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments and applications without departing from the spirit and scope of the described embodiments.Therefore, the described embodiments are not limited to the embodiments shown, but have the widest possible scope of application consistent with the principles and features disclosed herein.

[0065] All features disclosed below with respect to the embodiments and / or the accompanying figures may be combined alone or in any sub-combination with features of the aspects of the disclosure, including features of preferred embodiments, provided that the resulting combination of features is meaningful to a person skilled in the art.

[0066] For the purposes of the disclosure, the phrase "at least one of A, B, and C" means, for example, (A), (B), (C), (A and B), (A and C), (B and C), or (A, B, and C), including all other possible combinations when more than three elements are listed. In other words, the phrase "at least one of A and B" generally means "A and / or B," namely "A" alone, "B" alone, or "A and B."

[0067] Fig. 1 shows a simplified schematic representation of a delivery vehicle (ZF) 10 with a load space management system (LVS) 12 according to an embodiment of the disclosure.

[0068] The LVS 12 is arranged at least partially within the ZF 10. The ZF has a loading space 14. A Cartesian coordinate system 16 indicates the orientation of the loading space 14 and the objects 18 arranged therein.

[0069] A camera system 20 comprises a plurality of cameras 24 configured as sensors 22, all of which are movably positionable. For this purpose, the cameras 24 have mounting devices by means of which they can be moved along various rail devices 26.

[0070] The LVS 12 also includes a control device (RV) 28, which has at least one data processing device 30. According to this embodiment, the RV 28 also includes the object identification logic 32 and the object placement logic 34.

[0071] The RV 28 is coupled to the cameras 24.

[0072] The RV 28 further comprises a communication device 36. The RV 28 is coupled to a (cloud) server 38 via the communication device 36. The server 38 can therefore be a cloud server. At least parts of the object identification logic 32 and the object placement logic 34, for example, a respective machine learning algorithm or underlying neural networks, can also be stored remotely from the RV 28, for example, within the server 38.

[0073] Additionally, the RV 28 is coupled with a human-machine interface (MMS) 40. The connection between the RV 28 and the MMS 40 can be wireless. Using the MMS 40, the RV 28 can issue notifications or receive user inputs.

[0074] In addition, the RV 28 is also coupled to a manually operable sensor device 42, which can be used to manually capture object data, such as a barcode. For example, the sensor device 42 can comprise a scanner. Optionally, the sensor device 42 can also be formed integrally with the MMS40, for example, as part of a mobile device such as a smartphone.

[0075] According to this embodiment, the cargo space 14 comprises a shelving system 44 by means of which different objects 18 are positioned within the cargo space 14. The objects 18 typically have different sides 46A, 46B, 46C of different dimensions, in particular different surface sizes. For example, 46A can denote the smallest side.

[0076] The loading space 14 has different loading space positions 48A, 48B,..., which are assigned to different parts of the shelving system 44. In other words, virtual positions are determined (in particular by the RV 28) that depend on characteristics of a respective object 18, such as the size of the object. These virtual positions are assigned to a coordinate system in the ZF 10. The loading space positions 48 can vary in their dimensions. The loading space positions 48 can also have multiple abstraction levels. This means that a first abstraction level can, for example, designate the left side of the shelving system 44 within the loading space 14.

[0077] A further level of abstraction may concern a rough division of the relevant part of the shelving system 44. An additional level of abstraction may concern the precise arrangement of the loading space position within the rough division, i.e., a fine division.

[0078] Objects 18 can also be arranged as a stack 50 within the loading space 14. All objects 18 of a stack 50 typically have the same loading space position 48. This means that the loading space position 48 essentially refers to an available area in the xz-plane of the coordinate system 16. The x-direction corresponds to the longitudinal direction of the ZF 10, the z-direction to the width of the ZF 10, and the y-direction to the height of the ZF 10. As a result, the stack 50 has a certain height along the y-direction.

[0079] The cameras 24 are configured to detect objects 18 placed in the cargo space 14. The cameras 24 can also be configured to detect the cargo space positions 48, and, for example, to detect whether objects 18 are located at the respective cargo space positions 48. The detection of the cargo space position 48 can, for example, also be performed with regard to their respective dimensions. This means that the dimensions of the respective available volumes at the respective cargo space positions 48 can be determined using the respectively detected sensor data.

[0080] The cameras 24 can be positioned, in particular using the rail devices 26, such that they can capture the entire cargo space 14. For this purpose, several rail devices 26 are arranged orthogonally to one another.

[0081] Optionally, a camera 24 of the camera system 16 is configured to capture depth information within the cargo space 14, i.e., a distance of an object 18 from the camera 24.

[0082] The image data captured by the cameras 24 are transmitted to the RV 28. Within the RV 28, or with the aid of external devices such as the (cloud) server 38, the RV 28 is configured to execute the object identification logic 32 and the object placement logic 34.

[0083] The LVS 12 also includes at least one signaling device 52. The signaling device 52 can also be displaceable using the rail devices 26. The signaling device 52 is coupled to the RV 28. The signaling device 52 is configured to output a cargo space position signal, in this case a visual cargo space position signal. The cargo space position signal can be multi-stage and indicate a specific cargo space position 48, for example, at which a specific object 18 is to be arranged. In addition, the cargo space position signal can also indicate a specific orientation of the object 18 so that the object 18 is arranged on a specific side at a specific cargo space position 48. Furthermore, the cargo space position signal can indicate that specific objects 18 are to be arranged at a cargo space position 48 according to a stack 50.

[0084] The signaling device 52 can also be configured to output an unloading position signal. The unloading position signal can indicate a specific object 18 or a specific loading space position 48 at which an object 18 is located that is to be unloaded, i.e., removed, from the loading space 14 at this time.

[0085] Fig. Figure 2 shows a simplified schematic representation of a method 54 for cargo space management of a ZF 10 according to one embodiment of the disclosure. The embodiment of the method 54 represents a high-level embodiment with a low level of detail. The method 54 may have additional optional steps and configurations according to the embodiments illustrated in the other figures.

[0086] The method 54 initially comprises step 56, in which at least one route plan of the ZF 10 is received from a server, in particular a (cloud) server 38. The route plan can be received, in particular, by the RV 28 using the communication device 36.

[0087] In the subsequent optional step 58, the identities of objects 18 placed in the cargo space 14 of the ZF 10 are determined. For this purpose, for example, sensor data captured by a sensor 22, in particular a camera 24, can be used. The sensor data can be used to determine the dimensions of the objects 18 or their identification features, such as barcodes.

[0088] These can then be compared, for example, with the route plan, which may contain information about the dimensions or identification features of the objects 18 to be delivered. This enables the identification of the objects 18 by the RV 28, for example, based on the object identification logic 32. Optionally, step 58 of the method 54 can be executed at least partially on the (cloud) server 38.

[0089] In step 60, a respective cargo space position 48 is determined by the object placement logic 34 of the RV 28, taking into account at least the route plan, before or during the introduction of an object 18 into the cargo space 14 of the ZF 10. Identification of objects 18 actually introduced into the cargo space 14 is not required for step 60. Rather, the cargo space positions 48 can also be determined by the object placement logic 34 independently of the actual introduction, based exclusively at least on information from the route plan (and optionally further information). At the cargo space position 48 thus determined, a respective object 18 introduced or to be introduced into the cargo space 14 is to be placed. The totality of the cargo space positions 48 thus determined forms an object distribution. Data recorded by a sensor 22, for example a camera 24, can also be taken into account.The collected data can be used, for example, to determine the arrangement and dimensions of the loading space positions 48 within the shelving system 44. Optionally, step 60 of the method 54 can be executed at least partially on the (cloud) server 38.

[0090] The method 54 also includes step 62, in which a respective loading space position signal is output by a signaling device 52. The loading space position signal indicates the respective specific loading space position 48 for the respective object 18. This assists the user in loading the loading space 14 with the objects 18, as the user no longer has to locate the loading space positions 48 themselves. As a result, the loading process of the loading space 14 with the objects 18 can take place in shorter periods of time. Thus, the operational efficiency of the delivery process based on the method 54 can be increased.

[0091] The method 54 can be executed, in particular, by the LVS 12. The following figures illustrate further, more detailed embodiments of the method 54 that can be used by the LVS 12 to provide additional functionality. However, the aspects explained with reference to different figures can also be combined with one another.

[0092] Fig. 3 shows a simplified schematic representation of a method 64 for object identification of objects 18 as part of a method 54 for cargo space management of a ZF 10 according to an embodiment of the disclosure. The method 64 exemplifies the functionality of the object identification logic 32 of the RV 28 of the LVS 12.

[0093] In step 66 of the method 64, a user places a number X of objects 18 into the loading space 14 of a ZF 10.

[0094] In step 68, the LVS 12 identifies a number Y of objects 18. For this purpose, sensor data acquired by at least one sensor 22 can be used.

[0095] In step 70, the LVS 12 informs the user that a number Y of the objects 18 have been identified.

[0096] In step 72, the user checks whether the number Y of objects 18 identified by the LVS 12 matches the number X of objects 18 that the user has placed in the loading space 14.

[0097] The object identification logic 32 then depends on the condition 74, namely whether the number X is equal to the number Y.

[0098] If this is not the case, the method 64 includes the subsequent step 76, in which the user checks which of the objects 18 have been identified by the WMS 12. The WMS 12 can also initiate a corresponding information output to the user. If a complete identification of the objects 18 is not possible, the WMS 12 can also inform the user of the necessary follow-up measures to ensure completeness for the subsequent delivery steps. The corresponding notification can then be issued, for example, via the MMS40.

[0099] Subsequently, in step 78, the user scans the objects 18 not identified by the LVS 12. For this purpose, the user can, for example, use the manually operable sensor device 42. The data acquired by the sensor device 42 is transmitted to the RV 28 of the LVS 12, and in particular to the object identification logic 32.

[0100] After the user has manually recorded all objects 18 that were not automatically identified by the WMS 12, the object identification is completed in step 80 according to the object identification logic 32. If the number X matches the number Y in condition 74, step 80 follows immediately, and the object identification according to method 64 is completed.

[0101] Fig. 4 shows a simplified schematic representation of a method 82 for loading a ZF 10 as part of a method 54 for managing the cargo space of a ZF 10 according to an embodiment of the disclosure.

[0102] In step 84, the WMS 12 has identified objects 18 placed in the cargo space 14. For this purpose, the method 64 of the object identification logic 32 can be used, for example.

[0103] In step 86, the WMS 12 optimizes the order of storage of the objects 18 according to the loading space positions 48 determined with regard to the objects 18. The corresponding loading space positions 48 can be determined, for example, according to step 60 of the method 54.

[0104] In the subsequent step 88, the LVS 12 outputs loading space position signals for all objects 18 simultaneously or sequentially, preferably sequentially, in order to indicate to the user the loading space positions 48 at which the objects 18 are to be arranged within the loading space 14. The loading space position signals are assigned to individual objects 18. For example, the loading space position signal can also be configured to provide the user with information about the object 18 to be placed at a loading space position 48, for example by projecting its outline or an identifier. For example, the signaling device 52 can be used for this purpose. The loading space position signals can be output, for example, in accordance with step 62 of the method 54.

[0105] Within the scope of condition 90, the LVS 12 checks whether the objects 18 have been correctly placed within the loading space 14 by the user, ie according to their determined loading space positions 48. For this purpose, the LVS 12 can, for example, use sensor data that was recorded using the sensors 22.

[0106] If not all objects 18 have been arranged by the user at their respective assigned loading space positions 48, the WMS 12 outputs feedback to the user in the subsequent step 92 of the method 82 that at least some, and in particular which, of the objects 18 need to be repositioned so that the objects 18 are arranged at their respective designated loading space positions 48. The feedback to the user in step 92 can be provided, for example, using the MMS40.

[0107] In the subsequent step 94 of the method 82, the user repositions the objects 18 according to the previously determined loading space positions 48. Optionally, step 94 may also include the output of corresponding loading space position signals so that the user is assisted in arranging the objects 18 according to the respectively assigned loading space positions 48.

[0108] Subsequently, the loading process is completed in step 98 of method 82. If, during the check of condition 90, it is determined that the objects 18 were correctly placed by the user, i.e., according to the respectively assigned loading space positions 48, method 82 continues immediately with the subsequent step 98, which indicates the end of the loading process.

[0109] Fig. 5 shows a simplified schematic representation of a method 100 for unloading a ZF 10 at a delivery location as part of a method 54 for managing the load space of a ZF 10 according to an embodiment of the disclosure.

[0110] In step 102, the ZF 10 arrives at a delivery location. The delivery location may, in particular, coincide with a delivery location that is part of a route plan.

[0111] In the subsequent step 104, according to this embodiment of the method 100, the user selects objects 18 to be delivered to this delivery location.

[0112] The user then enters the cargo space 14 in step 106 of the method 100.

[0113] In the subsequent step 108, the WMS 12 specifies the loading space positions of the objects 18 to be removed from the loading space 14 at this delivery location. For this purpose, the signaling device 52 can be used, in particular, to output corresponding loading space position signals. This means that the loading space position signals can indicate not only loading space positions 48, but also objects 18 in the area of ​​corresponding loading space positions 48, to indicate that the objects 18 are either to be placed at the loading space positions 48 or that the objects 18 are to be removed from the loading space positions 48. This assists the user in unloading the ZF 10.

[0114] In the subsequent step 110, the user removes the objects 18 to be delivered from the loading space 14.

[0115] Subsequently, the WMS 12 confirms in step 112 of the method 100 that the delivery process for this delivery location is completed. In particular, the WMS 12 can check in step 112 whether all objects 18 selected by the user in step 104 have been removed from the loading space 14 (not shown here, but exemplarily in the Fig. 8 and Fig. 9). If this is not the case, the LVS 12 can send a notification to the user, for example using the MMS40 (not shown here, but exemplarily in the Fig. 8 and Fig. 9 shown).

[0116] The process 100 is repeated for each delivery location.

[0117] Fig. 6 shows a simplified schematic representation of the exemplary communication structure 114 of an LVS 12 in the context of a method 54 for cargo space management of a ZF 10 according to an embodiment of the disclosure.

[0118] The figure shows the LVS 12 and how the various components are interconnected. The ZF 10 is thus linked to a cloud server 116 of a delivery company (operator of the ZF 10) and to a cloud server 118 of the vehicle manufacturer, for example, the Ford Pro Cloud.

[0119] The cloud 116 of the delivery company includes all information about the objects 18 within an object database 120, for example their dimensions and delivery addresses, as well as the route and updates of the route, i.e. the route plan 122.

[0120] According to this embodiment, the vehicle manufacturer's cloud server 118 includes the object placement logic 34, which uses artificial intelligence to determine the optimal loading space position 48 in the loading space 14 for each object 18. This takes into account the complete list of objects 18 from the object database 120, the route plan 122, and optionally also the user's information regarding their route preferences or similar, as well as previous experiences. For example, traffic information can also be considered within the scope of the object placement logic 34.

[0121] According to this embodiment, the object identification logic 32 of the LVS 12 is arranged within the ZF 10. In this case, the ZF 10 also includes a position sensor 124, which can be used to track the position of the ZF 10. For example, the LVS 12 can detect the arrival of the ZF 10 at a delivery location.

[0122] Fig. 7 shows a simplified schematic representation of the system components 126 of the LVS 12 arranged in the ZF 10 as part of a method 54 for cargo space management of a ZF 10 according to an embodiment of the disclosure.

[0123] The object database 120 of the supplier's external cloud server 116 provides an object list 128 for the respective ZF 10. According to this embodiment, at least part of the object placement logic 34 is arranged as part of the LVS 12 within the ZF 10.

[0124] The camera system 20, at least the signaling device 52, the MMS 40, and a feedback module 130 are arranged in the cargo space 14. Using the feedback module 130, the user can provide appropriate inputs for the LVS 12. In some embodiments, the feedback module 130 can also be integral with the MMS 40.

[0125] At least one object selection module 134 is arranged in a cabin area 132 of the ZF 10. Using the object selection module 134, the user can select corresponding objects 18 to be unloaded at a delivery location. Optionally, the object selection module 134 can also be integrated with the MMS40. Preferably, the MMS40 can also be configured as part of a mobile device.

[0126] The Fig. 8 and Fig. 9 together show a simplified schematic representation of a method 136 for loading a ZF 10 as part of a method 54 for managing the cargo space of a ZF 10 according to an embodiment of the disclosure. Compared to method 82, method 136 has a higher level of detail.

[0127] In step 138, the loading process starts according to method 136.

[0128] In the following step 140, the user enters the loading space 14.

[0129] The following condition 142 depends on whether the LVS 12 detects the person entering the cargo space 14. If this is not the case, the method 136 results in an error according to step 144, since the person entering the cargo space 14 was not detected. Optionally, the method 136 can provide a user input for this case indicating that the user has entered the cargo space 14. For example, the user input can be made using the MMS40.

[0130] If, when checking condition 142, it is determined that the person entering the loading space 14 has been detected by the LVS 12, the subsequent condition 146 checks whether the user is bringing objects 18 into the loading space 14.

[0131] If the person actually brings objects 18 into the cargo space, but these are not detected by the LVS 12, the method 136 according to this embodiment results in an error corresponding to step 148.

[0132] If it is determined within the scope of condition 146 that the person does not bring any objects 18 into the loading space 14 in accordance with step 150, the method 136 is returned to step 140 and the next time a person enters the loading space 14 is awaited.

[0133] If it is determined within the scope of condition 146 that the person actually brings objects 18 into the loading space 14, the WMS 12 initiates the object identification in the subsequent step 152, for example based on the object identification logic 32 of the WMS 12.

[0134] In the subsequent step 154, the LVS 12 compares detected objects 18, in particular object information thereof, with information from the route plan 122. The object information, such as the dimensions of an object 18, can be detected, for example, by a sensor 22.

[0135] In the subsequent step 156, objects 18 can be identified by comparison using the LVS 12, for example, because the dimensions of a specific object 18 match an entry for an object 18 in the route plan 122. Additional identification mechanisms are based, for example, on the recognition of a barcode.

[0136] The method 136 continues with step 158, in which the LVS 12 informs the user about the number Y of identified objects 18. For this purpose, the MMS40 can be used, for example.

[0137] If the number Y of identified objects 18 does not match the number X of objects 18 actually placed in the cargo space 14, the method 136 proceeds to step 160, which indicates that the number Y is incorrect.

[0138] In the subsequent step 162, the user indicates that the number Y is incorrect. For example, the user can use the MMS40 or the feedback module 130 for this purpose.

[0139] As a result, the LVS 12 indicates in the subsequent step 146 which objects 18 have been identified.

[0140] The user can now scan objects 18 not previously identified by the LVS 12 according to the subsequent step 166. For example, the user can use the manual sensor device 42 for this purpose. Once the user has scanned the objects 18 not identified by the LVS 12, the method 136 returns to step 156.

[0141] If the number Y of objects 18 identified by the LVS 12 matches the number X of objects 18 actually introduced, the method 136 continues from step 158 through step 168. In step 168, the user confirms the number X of objects 18 introduced.

[0142] As a result, the LVS 12 indicates the loading space positions for the identified objects 18 in the subsequent step 170. For this purpose, the signaling device 52 can be used, in particular, to output corresponding loading space position signals.

[0143] Starting from step 164, the LVS 12 can modify the method 136 to subsequently execute step 170, i.e., to output the loading space positions of the identified objects 18 to the user.

[0144] After step 170, the method 136 comprises the subsequent step 172 in which the user places the objects 18 according to the loading space positions specified by the WMS 12.

[0145] Starting from step 172, the method 136 continues with the checking of condition 174, in which the LVS 12 determines whether the objects 18 introduced into the cargo space 14 are positioned according to the cargo space positions 48 output by the LVS 12. For this purpose, the LVS 12 can, for example, again use sensor data acquired using a sensor 22.

[0146] If the condition 174 is not met, the method 136 continues with step 176, which indicates that at least some objects 18 are not arranged at the predetermined loading space positions 48.

[0147] As a result, in step 178, the LVS 12 notifies the user about deviating loading space positions 48 of objects 18.

[0148] Now, in the following condition 180, it is checked whether the user corrects the loading space positions 48 of the relevant objects 18.

[0149] If condition 180 is not met, the LVS 12 stores different loading space positions of the objects 18 according to the subsequent step 182. For this purpose, the RV 28 can be coupled, for example, to a storage device.

[0150] If the condition 174 is fulfilled, i.e. that the objects 18 are placed at the assigned loading space positions 48, the LVS 12 checks in the following condition 184 whether all objects of the route plan have been placed in the loading space 14.

[0151] As a result, the LVS 12 checks in condition 186 whether the charging process has finished.

[0152] If condition 180 is met, i.e., if the user has corrected the loading space positions 48 of the relevant objects 18, the method 136 also continues with condition 186. Starting from step 182, in which the deviating loading space positions of the objects 18 are stored by the WMS 12, the method 136 also continues with condition 186.

[0153] If condition 186 is met, i.e. the loading process is finished, the LVS 12 confirms the end of the loading process according to step 188.

[0154] If condition 186 is not met, method 136 includes a return to step 140 starting from condition 186. LVS 12 therefore waits for the user to enter loading space 14 again.

[0155] Fig. 10 shows a simplified schematic representation of a method 190 for unloading a ZF 10 at a delivery location as part of a method 54 for managing the load space of a ZF 10 according to an embodiment of the disclosure. Compared to method 100, method 190 has a higher level of detail.

[0156] In step 192, the ZF 10 arrives at a delivery location. For example, this can be detected by the LVS 12 using the position sensor 124.

[0157] In the subsequent step 194, the WMS 12 specifies the objects 18 to be unloaded for this delivery location. Alternatively, the user can also select the objects 18 to be unloaded for this delivery location. This can be done, for example, using the object selection module 134.

[0158] In the following step 196, the person enters the cargo space 14.

[0159] The procedure 91 continues with condition 198, which depends on the LVS 12 detecting the person entering the cargo space 14.

[0160] If the condition 198 is not fulfilled, the method 91 results in an error according to step 200, since the person entering the cargo space 14 is not detected by the LVS 12.

[0161] If the condition 198 is fulfilled, the method 190 continues with the subsequent step 202, in which the LVS 12 detects the objects 18 located in the cargo space 14.

[0162] Subsequently, the condition 204 is evaluated, namely whether the objects 18 to be unloaded at this delivery location have been identified by the WMS 12.

[0163] If the condition 204 is not met, the method 190 proceeds to step 206 corresponding to an error in which the LVS 12 notifies the user that the objects 18 to be unloaded have not been identified.

[0164] As a result, the user manually identifies the objects 18 to be invited in the subsequent step 208.

[0165] If condition 204 is met, the WMS 12 indicates the loading space positions of the objects 18 to be unloaded in the subsequent step 210. For this purpose, the signaling device 52 can be used, for example.

[0166] Subsequently, in the following step 212, the user removes the objects 18 to be unloaded from the loading space 14.

[0167] The method 190 may now proceed to step 214 if the user removes an incorrect object 18 from the cargo space 14, which corresponds to an error.

[0168] In this case, the method 190 proceeds to the subsequent step 216, in which the LVS 12 informs the user about the incorrect, unloaded object 18. For example, this can be done using the MMS40.

[0169] The subsequent condition 218 depends on whether the user corrects the unloading process and removes the correct object 18 to be unloaded from the loading space 14. If this is not the case, the method 190 returns to step 216 starting from condition 218.

[0170] Starting from step 212, the method 190 can also be continued by the subsequent condition 220, in which the WMS 12 checks whether all objects 18 to be unloaded for this delivery location have been removed from the loading space 14.

[0171] If condition 218 is met, i.e. the user corrects the unloading process, the method 190 continues from condition 218 with condition 220.

[0172] If condition 220 is met, i.e., all objects 18 to be unloaded for this delivery location have been removed from the loading space 14, the WMS 12 confirms the end of the unloading process in the subsequent step 222. The method 190 then returns to step 192, i.e., it waits for the ZF 10 to reach a new delivery location.

[0173] If condition 220 is not met, the WMS 12 informs the user in the subsequent step 224 about a forgotten object 18 that is to be unloaded for this delivery location. The method 190 then returns from step 224 to step 212.

[0174] Fig. 11 shows a simplified schematic representation of a method 226 for determining the cargo space position for objects 18 as part of a method 54 for managing the cargo space of a ZF 10 according to an embodiment of the disclosure. In particular, the method 226 can exemplify the functionality of the object placement logic 34.

[0175] In step 228 of method 226, the LVS 12 receives object data of the objects 18 of the route plan 122. For this purpose, the RV 28 of the LVS 12 can, for example, use the communication device 36 to receive the corresponding object data from a server 38.

[0176] In the following step 230, the LVS 12 determines the dimensions of all objects 18.

[0177] In the subsequent step 232, the LVS 12, in particular its object placement logic 34, determines a size category for each object 18. The size category can be determined according to a predefined distribution, for example, small, medium, and large. Additional or finer adjustments between the size categories are also possible.

[0178] In the subsequent step 234, the objects 18 are imaged according to their minimum dimensions and the unloading sequence. The minimum dimensions refer in particular to a side with the smallest dimensions. For example, a cuboid-shaped object 18 typically has a side 46A that has the smallest surface area compared to the other side surfaces of the object 18.

[0179] The method 226 continues with step 236 in which removal distances between the objects 18 are taken into account.

[0180] As a result, in the subsequent step 238, an object distribution of the objects 18 is determined according to their unloading sequence across loading space positions 48. The object distribution comprises the totality of all loading space positions 48 to which corresponding objects 18 are assigned. In other words, the object distribution represents an occupancy plan of the loading space 14 with the totality of the objects 18.

[0181] In addition, according to the method 226, the LVS 12 receives vehicle information from the ZF 10 according to step 240, for example from a (cloud) server 38.

[0182] In the subsequent step 242, based on the received vehicle information, the WMS 12 determines an available shelf length of the cargo space 14 along the X direction of a Cartesian coordinate system 16, i.e., along the vehicle's longitudinal extension direction. In addition, the WMS 12 also determines an available shelf height along the Y direction and an available shelf depth along the Z direction for each compartment of the shelving system 44. From this, the dimensions of the respective cargo space positions 48 can be determined. This information is taken into account starting from step 242 within step 238.

[0183] Following step 238, the method 226 continues with step 244, in which the WMS 12 determines a required shelf length of the intended object distribution.

[0184] According to the following condition 246, the WMS 12 checks whether the required shelf length from step 244 is less than or at least equal to the available shelf length determined according to step 242.

[0185] If condition 246 is met, the determined object distribution of the 18 objects is output to the user on the MMS40 according to step 248. The object distribution can include a sequential output of individual entries of the object distribution. Alternatively, the object distribution can also be output in its entirety via the MMS40.

[0186] If condition 246 is not met, method 226 continues with step 250. In step 250, stacked objects 18 are assigned to individual loading space positions 48 of the object distribution based on individual stacks 50. This means that multiple objects 18 are to be arranged at a single loading space position 48 by forming a stack 50. Starting from step 250, method 226 then includes a return to step 238.

[0187] Fig. 12 shows a simplified schematic representation of a method 252 for determining the loading space position for objects 18 as part of a method 54 for managing the loading space of a ZF 10 according to an embodiment of the disclosure. In particular, the method 252 can exemplify the functionality of the object placement logic 34. The method 252 is repeatedly performed with respect to individual delivery locations. For each delivery location, the totality of the objects 18 to be unloaded at the delivery location is generally taken into account.

[0188] Method 252 begins with step 254, in which the WMS 12 determines a stacking metric for each object 18 of a route plan 122. The stacking metric specifies how a corresponding object 18 is to be oriented at a specific loading space position 48. For example, the stacking metric can specify whether an object 18 is to be placed on the side with the smallest surface area (small stacking metric). On the other hand, the stacking metric can specify whether an object 18 is to be placed on the side with the largest surface area (large stacking metric). This influences, for example, the positioning accuracy of the object 18 during the delivery process.

[0189] The method 252 then continues with condition 256, in which the WMS 12 checks whether several objects 18 are to be unloaded for a delivery location.

[0190] If this is not the case, in the following step 258, the stack metric for the object 18 under consideration at this delivery location is set to 0. This means that the object 18 in question does not have a stack metric, so stack formation is currently excluded.

[0191] If condition 256 is met, method 252 proceeds to step 260, in which the WMS 12 determines an order of the objects 18 of this delivery location according to the smallest dimensions of the objects 18 of this delivery location. The smallest dimensions generally refer to the sides with the smallest side surfaces.

[0192] In the subsequent condition 262, the WMS 12 checks whether a stack 50 containing the second to last object 18 of this delivery location according to the sequence determined in step 260 corresponds to the available space of the intended loading space position 48. In other words, a single loading space position 48 is assigned to this delivery location, and a check is made to determine whether a stack 50 containing the second to last object of the determined sequence corresponds to an available volume of the loading space position 48.

[0193] If condition 262 is not met, the stack metric is set to 0 according to step 264. This means that the object 18 in question has no stack metric, thus stack formation has been ruled out so far. Subsequently, method 252 is returned to condition 262, but condition 262 is now repeatedly executed, albeit only with regard to the second to penultimate object 18 in the sequence determined in step 260. The loop between condition 262 and step 264 can be repeated, with the check being reduced by one object 18 in the sequence determined in step 260, starting with the last object 18 in the sequence.

[0194] If condition 262 is met, the LVS 12 checks in the subsequent condition 266 whether the objects 18 arranged adjacent to the intended loading space position 48 ensure sufficient lateral stability for the stack 50.

[0195] If condition 266 is not met, method 252 continues with step 268, in which the stack metric for the object 18 under consideration at this delivery location is set to 0. This means that the object 18 in question has no stack metric, i.e., stack formation has so far been ruled out. Method 252 then comprises a return from step 268 to condition 262, wherein the condition 262 is likewise checked for a reduced number of objects 18, as already explained with regard to the loop between condition 262 and step 264. This means that the loop between condition 262, condition 266, and step 268 is repeated, wherein the check is reduced in each case by one object 18 of the sequence determined in step 260, starting from the last object 18 in the sequence.

[0196] If condition 266 is met, method 252 proceeds to step 270 by setting the stacking metric for object 18 of this delivery location as the smallest dimension of object 18. The smallest dimension of object 18 is again generally understood to be the side with the smallest surface area.

[0197] In the subsequent step 272, the LVS 12 determines the object distribution according to the largest stack metric, provided a stack metric has been determined for each object 18 at this time. The object distribution thus determined can then be output, for example, using the MMS40. Selecting the largest stack metric ensures that the objects 18 are preferentially placed on their largest sides. This increases stability during the delivery process, for example, positional accuracy during a movement of the ZF 10.

[0198] Fig. 13 shows a simplified schematic representation of a method 274 for determining the loading space position for objects 18 as part of a method 54 for managing the loading space of a ZF 10 according to an embodiment of the disclosure. In particular, the method 274 can exemplify the functionality of the object placement logic 34. The method 274 is executed jointly for all objects 18 of a single delivery location.

[0199] The method 274 begins with step 276, in which the LVS 12 determines an available space at a loading space position 48 taking into account a variable width along the X direction, i.e. the longitudinal extension direction of the ZF 10.

[0200] In the subsequent step 278, the WMS 12 determines a total number of stacks 50 of objects 18 for this delivery location, which correspond to the available space at this loading space position 48 determined in step 276, taking the stack metric into account. In other words, the possible combinations of objects 18 corresponding to different stacks 50 are determined, for which the available volume of the corresponding loading space position 48 is sufficient.

[0201] In the subsequent step 280, the LVS 12 selects the stack 50 with the smallest width. The width of the stack 50 refers here to the X direction of the coordinate system 16, i.e., the longitudinal direction of the ZF 10.

[0202] In the subsequent condition 282, the LVS 12 checks whether the adjacent objects 18 of the corresponding loading space positions 48 ensure sufficient lateral stability for the stack 50 selected in step 280.

[0203] If condition 282 is not met, method 274 includes a return to step 280, but the stack 50 previously selected in step 280 is removed from the total number of available stacks 50 for these loading space positions 48. Thus, only the remaining stacks 50 of the total number of stacks 50 are checked.

[0204] If the condition 282 is met, the method 274 continues with step 284 in which the LVS 12 determines the object distribution according to the stacks 50 selected from the total set.

[0205] The object distribution can then be output in a known manner, for example via an MMS40.

[0206] The methods 226, 252, 274 can, in particular, be part of the method 54 for cargo space management of a ZF 10 according to one embodiment of the disclosure. The methods 226, 252, 274 can, in particular, be taken into account in step 60 of the method 54 by the object placement logic 34.

[0207] In connection with proceedings 252, 274 of the Fig. 12 and Fig. Show 13 Fig. 14A and Fig. 14B simplified schematic representations of object distributions of objects 18 in a loading space 14 of a ZF 10 as a result of various methods for determining the loading space position for objects 18.

[0208] In the Fig. 14A, stacking of objects 18 is excluded. All objects 18 are arranged next to each other along the X direction of the coordinate system 16, i.e., along the longitudinal direction of the ZF 10. This results in the objects 18 occupying a common loading space length 286A.

[0209] In the Fig. 14B, in particular, the possibility of stacking objects 18 is taken into account, for example, using methods 252, 274. In this case, care is taken to ensure that objects 18 arranged adjacent to stacks 50 ensure sufficient lateral stability for the respective stack 50. As a result, the object distribution, i.e. the totality of the objects 18 arranged in the loading space 14, only requires a reduced loading space length 286B, which is in particular smaller than the loading space length 286A of the object distribution from Fig. 14A. This allows the packing density within the cargo space 14 to be increased.

[0210] Specific embodiments disclosed herein, in particular the control device, use circuits (e.g., one or more circuits) to implement standards, protocols, methods, or technologies disclosed herein, operatively couple two or more components, generate information, process information, analyze information, generate signals, encode / decode signals, convert signals, transmit and / or receive signals, control other devices, etc. Circuits of any type may be used.

[0211] In one embodiment, a circuit such as the control device includes, among other things, one or more data processing devices such as a processor (e.g., a microprocessor), a central processing unit (CPU), a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), a system on a chip (SoC), or the like, or any combination thereof, and may include discrete digital or analog circuit elements or electronics, or combinations thereof. In one embodiment, the circuit includes hardware circuit implementations (e.g., implementations in analog circuits, implementations in digital circuits, and the like, and combinations thereof).

[0212] In one embodiment, circuitry includes combinations of circuitry and computer program products with software or firmware instructions stored on one or more computer-readable memories that cooperate to cause a device to execute one or more of the protocols, methods, or technologies described herein. In one embodiment, the circuitry includes circuitry, such as microprocessors or portions of microprocessors, that require software, firmware, and the like to operate. In one embodiment, the circuitry includes one or more processors or portions thereof and the associated software, firmware, hardware, and the like.

[0213] In this disclosure, reference may be made to quantities and numbers. Unless expressly stated, such quantities and numbers are not to be considered limiting, but rather as examples of the possible quantities or numbers in connection with the disclosure. In this context, the term "plurality" may also be used in the disclosure to refer to a quantity or number. In this context, the term "plurality" means any number greater than one, e.g., two, three, four, five, etc. The terms "about," "approximately," "near," etc., mean plus or minus 5% of the stated value.

[0214] Although the disclosure has been shown and described with respect to one or more embodiments, those skilled in the art will be able to make equivalent changes and modifications after reading and understanding this description and the accompanying drawings. QUOTES CONTAINED IN THE DESCRIPTION

[0000] This list of documents submitted by the applicant was generated automatically and is included solely for the convenience of the reader. This list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions. Cited patent literature

[0000] US 2022 / 0237557 A1

[0004] US 2016 / 0189087 A1

[0005] US 2020 / 0074404 A1

[0006] US 11,377,070 B2

[0007] US 2020 / 0023755 A1

[0008]

Claims

[1] Method (54) for managing the loading space of a delivery vehicle (10), the method (54) comprising at least the following steps: - receiving a route plan (122) of the delivery vehicle (10) from a server (38), - Determining a respective loading space position (48) at which a respective object (18) introduced or to be introduced into the loading space (14) is to be placed, taking into account at least the route plan (122) by an object placement logic (34) before or during introduction of the respective object (18) into a loading space (14) of the delivery vehicle (10), and - Outputting a respective loading space position signal by a signaling device (52), wherein the loading space position signal indicates the respective determined loading space position (48) for the respective object (18). [2] Method according to claim 1, characterized by that the method further comprises the step: - Determining identities of objects (18) placed in a loading space (14) of the delivery vehicle (10). [3] Method (54) according to claim 2, characterized by that a quantity notification is issued by means of a human-machine interface (40), wherein the quantity notification indicates with respect to the route plan (122) whether the identities of all or only those of a subset of the objects (18) underlying the route plan (122) have been determined. [4] Method (54) according to one of the preceding claims characterized by that the cargo space position signal is multi-stage. [5] Method (54) according to one of the preceding claims, characterized by that the object placement logic (34) additionally determines the cargo space position (48) based at least on one of the following: - Vehicle information of the delivery vehicle (10), - object properties of the objects (18) underlying the route plan (122), - stability criteria of the objects (18) in the loading space (14), which indicate a loading space position reliability of the objects (18) arranged in the loading space (14) during a movement of the delivery vehicle (10), - a removal distance to be provided between at least some objects (18), - an estimated time required to load the cargo space (14), - an estimated time required to unload the cargo space (14), - loading space positions (48) of objects (18) placed in the loading space (14), - a current traffic situation regarding the route plan (122), - an expected traffic situation with respect to the route plan (122) at the time of a delivery process corresponding to the route plan (122), and - route preferences and / or loading preferences of a driver or operator of the delivery vehicle (10). [6] Method (54) according to one of the preceding claims, characterized bythat loading space positions (48) of objects (18) introduced into the loading space (14) can be detected by means of at least one sensor (22). [7] Method (54) according to one of the preceding claims, characterized by that the object placement logic (34) determines a respective cargo space position (48) in real time in an adaptable or repetitive manner. [8] Method (54) according to one of the preceding claims, characterized by that a respective unloading position signal is output by a signaling device (52) at a delivery location underlying the route plan (122), wherein the unloading position signal indicates the respective loading space position (48) for the respective object (18) which is to be unloaded from the loading space (14) at the delivery location. [9] Method (54) according to one of the preceding claims, characterized bythat the loading space position (48) also indicates an orientation of an object (18) to be placed in the loading space (14), and wherein the respective loading space position signal additionally indicates the orientation of the respective object (18). [10] Method (54) according to one of the preceding claims, characterized by that the loading space position (48) also indicates a stacking of several objects (18) to be placed in the loading space (14) depending on an available loading area and the objects (18) to be placed in the loading space (14) on which the route plan (122) is based, and wherein the respective loading space position signal additionally indicates the stacking of several objects (18) to be placed in the loading space (14). [11] Method (54) according to one of the preceding claims, characterized by that the method (54) is at least partially computer-implemented. [12] A loading space management system (12) for a loading space (14) of a delivery vehicle (10), wherein the loading space management system (12) comprises at least one control device (28) with a communication device (36) coupled thereto, and a signaling device (52), wherein the control device (28) is coupled to at least the signaling device (52), wherein the control device (28) is configured, based on the communication device (36) coupled thereto, to receive a route plan (122) of the delivery vehicle (10) from a server (38), wherein the control device (28) has an object placement logic (34) by means of which it is configured to determine a respective loading space position (48) before or during the introduction of the respective object (18) into a loading space (14) of the delivery vehicle (10), taking into account at least the route plan (122),at which a respective object (18) introduced or to be introduced into the loading space (14) is to be placed, and wherein the control device (28) is configured by means of the signaling device (52) to output a respective loading space position signal, wherein the loading space position signal indicates the respective specific loading space position (48) for the respective object (18). [13] Cargo space management system (12) according to claim 12, which is arranged to carry out the method (54) according to one of claims 1 to 11. [14] Delivery vehicle (10) with a cargo space management system (12) according to one of claims 12 or 13.

Images