Communication server device and operation method thereof

Abstract

A communication server device (102) for managing payloads (202, 204) transported by a vehicle (408) and a method of operating the same. The communication server device is configured to determine (206) a value of a first payload attribute parameter indicating a first vehicle capability requirement for a first payload of a first payload class, and to determine (208) a value of a second payload attribute parameter indicating a second vehicle capability requirement for a second payload of a second payload class. The values ​​of the first payload attribute parameter and the second payload attribute parameter are compared (210) with payload capability data associated with the vehicle, and the comparison result is used (212) to determine the capability of the vehicle to transport both the first payload and the second payload.

Description

Technical Field

[0001] The invention relates to a communication server device for managing a payload transported by a vehicle. The invention also relates to a method for managing a payload transported by a vehicle, and to a computer program and a computer program product comprising instructions for implementing the method.

[0002] The invention has particular, but not exclusive, application to the real-time aggregation of payload items and payload orders for delivery vehicles. Background Art

[0003] A variety of methods are known for managing payloads transported by vehicles, including methods in which the payloads are specified in orders for transporting the payloads. For example, methods are known for allocating payloads based on the capacity of the vehicles. In one previously considered method, the capacity of the vehicle is limited based on the complexity of the combined orders. In another previously considered method, payloads are aggregated at a given collection point in a route, and compatibility between legs is considered by determining whether there are overlapping time windows across order legs. In another previously considered method, orders are grouped by similarity. In yet another previously considered method, orders are clustered based on delivery address.

[0004] However, these approaches generally do not consider different types of payloads, which may require different types of capacity in the vehicle. In addition, these approaches do not address the real-time aggregation of payloads or orders. Moreover, these approaches do not consider how to manage orders or payloads that are not aggregated or clustered. Summary of the invention

[0005] Aspects of the invention are defined in the independent claims. Some optional features of the invention are defined in the dependent claims.

[0006] Implementations of the technology disclosed herein can provide important technical advantages. For example, different types of payloads and payload items can be efficiently managed or aggregated in the same transportation system, allowing for more efficient utilization of the shipping capacity. This more efficient utilization of the shipping capacity achieved by managing different types of payloads in the same aggregation arrangement in turn allows, for example, the management system to have greater data processing capacity and lower computational burden because fewer vehicles and vehicle delivery plans are required for the same amount of payload items. In addition, for the same amount of payload orders to the system, the vehicles used in the examples of the transportation arrangements described herein will require less maintenance and will experience less wear and tear because the delivery efficiency is improved.

[0007] Furthermore, vehicles of the system may be managed or pooled while already in use or in transit, thereby utilizing otherwise unused or underutilized capacity. Additionally, orders or payloads that were not pooled or matched in the initial phase may be re-pooled or allocated in further stages of the bundling or pooling process, thereby allowing more orders and / or payloads to be pooled and more underutilized vehicle capacity to be utilized. In at least some embodiments, the techniques disclosed herein allow for determining payload attributes indicative of vehicle capabilities for different classes of payloads, and comparing these to the payload capacity of the vehicle, to address the inability of previously considered approaches to manage different types of payloads that require different types of vehicle capacity. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:

[0009] Figure 1 is a schematic block diagram illustrating a communication system having an exemplary communication server device for managing a payload transported by a vehicle;

[0010] Figure 2 is a flow chart illustrating the steps of an exemplary method for managing a payload transported by a vehicle;

[0011] Figure 3 is a schematic diagram showing a range of examples of payloads and orders;

[0012] Figure 4 is a schematic block diagram illustrating an exemplary communication system for managing payloads transmitted by a vehicle;

[0013] Figure 5a and Figure 5b is a schematic diagram illustrating an example of data logging and processing of data logs for managing a payload transported by a vehicle; and

[0014] Figure 6 is a flow chart illustrating the steps of an exemplary method for managing a payload transported by a vehicle. DETAILED DESCRIPTION

[0015] First reference Figure 1 , a communication system 100 is shown. The communication system 100 includes a communication server device 102, a service provider communication device 104, and a user communication device 106. These devices are connected in a communication network 108 (e.g., the Internet) via corresponding communication links 110, 112, 114. The communication devices 104, 106 can communicate via other communication networks (such as a public switched telephone network (PSTN network), including a mobile cellular communication network), but for the sake of clarity, the communication system 100 is shown in FIG. Figure 1These communication networks are omitted.

[0016] The communication server device 102 may be Figure 1 The single server shown schematically in FIG. 100 may have functionality performed by server device 102 and distributed across multiple server components. Figure 1 In the example of , the communication server device 102 may include a plurality of separate components, including, but not limited to: a microprocessor 116, a memory 118 (e.g., a volatile memory, such as RAM) for loading executable instructions 120, the executable instructions defining the functions performed by the server device 102 under the control of the processor 116. The communication server device 102 also includes an input / output module 122 that allows the server to communicate via the communication network 108. A user interface 124 is provided for user control and may include, for example, conventional peripheral computing devices, such as a display monitor, a computer keyboard, etc. The server device 102 may also include a database 126.

[0017] The service provider communication device 104 may include a number of separate components, including, but not limited to, a microprocessor 128, a memory 130 (e.g., volatile memory, such as RAM) for loading executable instructions 132, which define the functions that the device 104 performs under the control of the processor 128. The device 104 also includes an input / output module 134 that allows the device 104 to communicate via the communication network 108. A user interface 136 is provided for user control. If the service provider communication device 104 is, for example, a smart phone or tablet device (or a user interface installed in a vehicle), the user interface 136 will be in the form of a touch panel display that is prevalent in many smart phones and other handheld devices. Alternatively, if the service provider communication device is, for example, a conventional desktop or laptop computer, the user interface may take the form of, for example, conventional peripheral computing devices, such as a display monitor, a computer keyboard, etc. Otherwise, if the service provider communication device 104 is, for example, a hub or monitoring device, a controller or server, or another system processing device, the user interface may take the form of a touch panel or conventional computing.

[0018] The user communication device 106 may be, for example, a smartphone or tablet device having a hardware architecture that is the same as or similar to that of the tag communication device 104 .

[0019] Additional references Figure 2, an exemplary communication server device 102 is used to manage payloads transported by a vehicle, such as described above, and includes a processor 116 and a memory 118. The device is addressed to a plurality of payloads having respective different payload classes, each payload class being associated with a unique vehicle capability requirement, such as payload class A (202) and payload class B (204). The communication server device is configured to execute instructions 120 in the memory under the control of the processor to: determine 206 a value of a first payload attribute parameter indicating a first vehicle capability requirement for a first payload of a first payload class (class A); determine 208 a value of a second payload attribute parameter indicating a second vehicle capability requirement for a second payload of a second payload class (class B); compare 210 the values ​​of the first payload attribute parameter and the second payload attribute parameter with payload capability data associated with the vehicle; and use 212 the comparison result to determine the capability of the vehicle to transport both the first payload and the second payload.

[0020] As described above, the technology described herein relates to managing or aggregating multiple types of payloads into a vehicle transport framework. Many different types or categories of payloads, contents, or cargo are considered, such as passengers and goods such as packages, food, medicine, flowers, and furniture. Thus, the payloads are varied and not homogeneous as in previously considered systems, which only considered, for example, cargo or passengers.

[0021] For each vehicle, different types of capacities associated with different types of payloads or contents are determined or obtained (if determined previously or elsewhere). The amounts for these different types of capacities are also determined for each vehicle. This allows transport orders containing or listing different types of payloads to be aggregated and the capacity of the vehicles to be used efficiently. The orders themselves may originate from, for example Figure 1 A user device 106 or a service provider device 104 is shown; for example, a user may order a passenger pick-up service, or a service provider may determine to transport a package for delivery to a customer over a network.

[0022] In the exemplary technique, a number of constraints or conditions are introduced to allow for optimized management or aggregation of payloads and payload items per order so that payloads or cargo are efficiently allocated during the aggregation process. For example: the capacity currently occupied by each payload type in a given vehicle; the compatibility of payload types with the vehicle, and between different payload types within the vehicle; and the service level for each payload type and each order, which can all be used as constraints to determine an efficient solution for any given vehicle and order or payload being compared.

[0023] In the example, payload category A is defined as one of: passengers; cargo; or perishables. Categories can of course be combined (e.g., passengers may also carry cargo, such as luggage), but additional categories may be defined for combinations (e.g., an additional category "passengers plus cargo" is defined). Thus, one payload category (or class or type) may cover different payload items (or indeed multiple payload items within a single payload); for example, cargo may come in various sizes and shapes, and passengers may have different requirements for their journeys; and various other factors may also be taken into account in order to efficiently accommodate payload items.

[0024] Thus, each payload class or payload (or payload item) has associated attributes, characteristics, or classifiers / classifications that allow for management of unique or specific requirements for that payload. For example, for a given payload, payload attributes may include in which area of ​​the vehicle the payload may be transported, the size or shape of the payload, the urgency with which the payload must be transported, whether the payload has a maximum or minimum temperature, etc.

[0025] For a given payload class, certain payload attributes may be implicit, others may be defined (e.g. specified during processing of an order, or by retrieving stored details from a database), while still other attributes may not be assigned to that payload class. For payloads of passenger class, this means that the passenger must be transported in the cabin of the vehicle (not in the trunk). It may be defined whether the passenger has other requirements, such as a preferred maximum number of stops, or a minimum / maximum number of other passengers in the vehicle. These may be obtained from the passenger's order or stored preferences. Other attributes may not be assigned (or avoided being assigned) to a passenger, such as how much trunk capacity is to be used.

[0026] For each payload attribute, there will be a payload attribute parameter value that defines the precise vehicle capability requirement for the payload or payload item. For example, a payload attribute for the maximum temperature of a payload will have a payload attribute parameter value for that maximum temperature, such as 4 degrees Celsius. For a payload attribute for the required compartment location, the parameter value may be "trunk" or "passenger cabin" or "refrigerated section". For a payload attribute for size, there may be several attribute parameters, each with a value; for example, width X cm, length Y cm, depth Z cm. For similar or alternative payload attributes for occupied space, for example, in terms of the number of available passenger spaces, the parameter value may be a value from 1 to 4, or in terms of the number of standardized cargo spaces occupied, the parameter value may be a value from 1 to n. For a weight attribute, the parameter value may be an amount of weight, such as 10 kg. For an urgency attribute, the parameter value may be a time for a deadline delivery, such as the time it takes for hot food to become too cold, or the maximum delivery time for biomedical items, or the half-life or other index of a medical radioisotope. For payload category "fragility", attribute parameters may include a maximum number of stops on the route, or a maximum threshold for driving stability, or a maximum threshold for route quality (stability / quality has been rated in order to determine the values ​​of these parameters).

[0027] Accordingly, the payload capacity associated with a vehicle may be represented by vehicle attributes and / or vehicle attribute parameter values. These attributes or values ​​may correspond to the adaptability of the corresponding payload attribute parameters. For example, for the payload attribute of the required cabin position, when the value is "trunk", vehicles having the vehicle attribute of cabin type and the vehicle attribute parameter values ​​of "trunk" and "cabin" will be compatible. For the vehicle attribute of cabin passenger capacity, in the case of a five-passenger vehicle, the parameter value may be "4". These vehicle attributes and parameter values ​​may be recorded in the vehicle capability data component of the data record, such as Figure 5b Those shown.

[0028] Reference again Figure 2 , payload category A will have unique or specific vehicle capability requirements A'; the required transport vehicle capabilities for a passenger payload will be significantly different than for a cargo payload. For example, a delivery vehicle may not have a passenger cabin, and similarly, a car fully loaded with passengers may still have room for cargo in the trunk.

[0029] Nevertheless, while different classes of payloads will have significantly different properties, which will require significantly different vehicle capabilities, there will also be properties that are common to the different classes. For example, both passengers and cargo may need to be delivered or dropped off by a certain time.

[0030] Additionally, comparing the attribute parameter value of a payload to the capabilities associated with the vehicle may include (or be limited to) comparing the attribute parameter value to an attribute parameter value of another payload (e.g., a payload that is already occupying the vehicle (or is scheduled to do so)). For example, a size parameter value of a cargo payload item may be compared to a size parameter value of another cargo payload item to check whether they both fit into the trunk of the vehicle. If both payloads require the use of a food storage area that is limited to one payload item, this will limit the vehicle's ability to transport both simultaneously unless they are transported in different delivery stages.

[0031] Furthermore, comparison(s) may be made not only with one vehicle but with multiple vehicles in order to determine the best vehicle for a given payload or payload category and attribute combination.

[0032] In an example, the payload category for a given payload or order may be a combination, or include multiple categories, for which parameter values ​​should be obtained. For example, a passenger may also have luggage, so both cargo and passenger attributes need to be considered.

[0033] It can also be noted that the various constraints of the system (represented in this example by the categories, attributes and their parameter values) that are compared to the capabilities of the vehicle will also affect each other. For example, if a cargo payload is arranged to occupy the passenger cabin area, the passengers will no longer be able to sit in the passenger cabin, even though the vehicle originally had that capability. If several payload items have time constraint attributes, then in the event that there are so many payloads that they cannot all arrive at the destination in time, a solution where the payloads completely occupy the vehicle will not be a solution that meets all time constraint constraints. Therefore, the comparison between the payload attributes and the vehicle capabilities will take into account all attributes and parameters in order to find one or more optimal solutions for efficiently managing multiple payloads together.

[0034] Once the payload attribute parameter values ​​have been compared 210 with the capability data associated with the vehicle, the results of the comparison can be used to determine whether the vehicle is actually capable of transporting the payload. In this way, the characteristics or attributes of the payload can be used as constraints on possible solutions for filling or occupying the available vehicle(s). Therefore, these techniques can be used as a method for optimizing the allocation or distribution of a set of payloads among a set of available vehicles. Similarly, these techniques can of course be used for the reverse optimization, that is, optimizing the allocation of a set of available vehicles to a given set of payloads.

[0035] Of course, once a system is established to constrain payload attributes according to vehicle capabilities, it can be used to bundle or aggregate orders. These orders may contain details of the payloads and their categories and or attributes, and may specify pickup locations and drop-off locations for (multiple) payloads. Orders such as those described above may, for example, come from a user, such as ordering passenger transport between locations, or may come from a service provider, which may have compiled the cargo and pickup and drop-off locations into an order.

[0036] Figure 3 is a diagram illustrating an example of a series of payloads and orders. A given vehicle has an initial location 1. A first package 2 has a sender location, while a second package 3 has a different sender location. The vehicle leaves the initial location and travels to pick up 2 and 3. The vehicle then travels to pick up the first food payload at the first food order restaurant location 4, and the second food payload at the second food order restaurant location 5. The vehicle then picks up the first passenger at location 6, and the second passenger at location 7. The vehicle then travels to the respective drop-off locations for these respective payloads. The first passenger is dropped off at location 8, and the second passenger is dropped off at location 9. The first food order is dropped off at 10, and the second food order is dropped off at 11. Finally, the first package is dropped off at location 12, and the second package is dropped off at 13.

[0037] These payloads may of course come from multiple orders from a user or service provider. For example, the first passenger and the second passenger at different locations are likely to be the result of separate orders from two different users. Two packages at different locations may come from different orders from the same or different users or service providers. Two food orders may be ordered for the same user from different locations, or for different users.

[0038] In this case, these payloads can all be accommodated in the same vehicle and this may have been determined, for example, by the process described above, by constraining the attributes of the payload, determining values ​​for the attribute parameters and comparing these to the capabilities of the vehicle and the planned footprint of the other payloads in the order set (referred to herein as an order bundle).

[0039] Additionally, pickup locations and drop-off locations may be managed when collecting, aggregating, or bundling orders to produce order bundles or sets that are efficient not only from a capacity usage perspective but also from a vehicle distance traveled perspective.

[0040] For example, given an initial set of orders including payloads and locations, any payloads or orders whose locations are outside a given threshold distance (e.g., from the initial order) may be initially rejected. A comparison of orders may thus be performed, initially grouping orders based on similarity of location(s) and subsequently optimizing through efficient vehicle usage as described above, or vice versa. A third mode may optimize both aspects in parallel.

[0041] In an exemplary technique, comparison of order locations is performed by analyzing the order locations as a graph problem. The pick-up locations and drop-off locations of all orders are represented as nodes in the graph. The links between any two nodes are represented as arcs in the graph. In addition, the current vehicle location can be included in the graph analysis.

[0042] In one example, two groups of orders are compared, each containing a payload and a location. The matching scores for the two groups of orders are calculated based on modeling a solution to the Traveling Salesman Problem (TSP), a modeling paradigm known in the art. Essentially, this type of modeling determines the shortest path that visits all nodes in a graph. Therefore, the two groups of orders can be compared by determining how far they need to be traveled to complete. Therefore, different comparisons of multiple groups of orders can be evaluated by comparing their increase in travel time. A threshold combined direct travel time can be set to reject any order or group of orders that excessively increases the travel time. In the example, the order batching efficiency score is calculated as follows:

[0043] Order batch processing efficiency = total order direct travel time / driver travel time after batch processing.

[0044] Among them, the total order direct travel time is the time required to complete each group of orders in a separate trip, and the driver travel time after batching is the time required to complete all orders in the combined trip.

[0045] While orders may be collected or bundled in this manner, the above constraints may also be applied. Thus, during the matching process of the exemplary technique, orders may be compared to find a sufficiently efficient bundle, but orders may be rejected if the payloads in the order are not compatible with the vehicle, or with each other, or with the service level requirements of the order / payload / travel time, or if the vehicle is already fully loaded with a particular payload.

[0046] Additionally, an order or payload may be compared to the vehicle compatibility data while the vehicle itself is in transit. For example, a payload or order may be compared to a vehicle that is already en route between a pickup location and a drop-off location for other payloads (or scheduled for such payloads) and that may already have payloads assigned or loaded on the vehicle. Thus, a real-time comparison is made between the payload or order and the vehicle payload or assigned order. Figure 6 Similar exemplary techniques are described in more detail.

[0047] Figure 4 is a schematic block diagram illustrating an exemplary communication system for managing payloads transported by vehicles. The service provider's server 402 (which may be similar to Figure 1 Device 104 in ) and user device 404 (which may be similar to Figure 1 The device 102 in ( ) is the device that creates the order. The order is then sent to a communication server 406, which processes the order and payload according to the techniques described herein to efficiently manage and / or aggregate the order and payload. The communication server 406 also communicates with one or more vehicles 408 and a server or database 410. The server 410 may provide a backup data supply for the vehicles of the transportation network, or may store details of trips that the vehicle has made or is making, or details of regular or recurring trips that the vehicle may make.

[0048] The communication server 406 uses information from the vehicle 408 and the server or database 410 to make comparisons between payloads and / or orders to determine the capabilities of the vehicle for those payloads and / or orders as described herein. Communications between the servers 402 and 410, the user device 404, and the vehicle 408 and the communication server 406 can of course be via a network, such as Figure 1 The network 108 shown in FIG.

[0049] Of course, it can be noted that vehicle 408 can be an autonomous vehicle. In this case, the programming of the vehicle can include a route determined by comparison of payload and order according to the techniques described herein.

[0050] For devices 402 and 404, the software application may include features and functionality in an interface or GUI, including, but not limited to, one or more of the following: a portion for entering a starting or origin location for a requested service; a portion for entering a destination location for a requested service; a portion for selecting a type of service (e.g., taxi, private car, ride-sharing or car-pool, shuttle, bus, delivery, etc.); a map that may include an indication of the current location of the user's computing device, an indication of the starting or origin location of the requested service, an indication of the end or destination location of the requested service, or an indication of the locations of one or more available service providers; commonly used starting locations and destination locations; and links to other features and functionality.

[0051] Some processes for managing payloads can be similar to known techniques for managing transportation-related services (e.g., taxis, private car services, shuttles, ride-sharing, e-hailing services, delivery services, etc.), including receiving orders, searching for suitable and available service providers or vehicles near the user's location (or a starting or origin location provided by the user), and matching suitable and available service providers with service requests.

[0052] Figure 5a and Figure 5b 5 is a schematic diagram showing an example of data records 550 for managing payloads transported by vehicles and processing of these data records. In an example of use of the system described herein, when a user wishes to place an order, the user's communication device (e.g., a mobile phone) generates data for the order using an application running on the user's device. The service requester's application typically outputs messages in the form of packets with a header indicating an ID and addressing information for the packet. Figure 5a and 5b As shown, the content of the packet (payload, field) consists of the user's order information. Figure 5a In this example of this includes: payload attribute data component 504 and location data component 506. A similar data record (from another source, perhaps another user) similarly has a header 503, a payload attribute data component 505 and a location data component 507.

[0053] The techniques described herein, for example, as implemented in the exemplary communication server apparatus described herein, can use data fields in data record 550 to determine comparisons between data records, as described herein. For example, location data components 506 and 507 in these data records can be processed to generate a comparison. In this case, the data records are combined into an order bundle data record having a header 522, a bundle attribute data component 524 (generated by processing the order payload attribute data component of data record 550), and a similar bundle location data component 526 (generated by comparing the location component).

[0054] exist Figure 5b In the process, the vehicle capability data component 554 from one data record is compared with the payload attribute data component 504 from another data record to produce a data component field 564 of another data record (header 562), which is populated by the comparison result between the vehicle capability data component 554 and the attribute data component 504.

[0055] In an exemplary technique for bundling and aggregating payloads and orders, a number of steps are performed:

[0056] 1. Bundle transport orders together, e.g., by location. If a given bundle exceeds a determined efficiency threshold, or if orders within the bundle are late (too late to be matched in (2)), assign the bundle to a new / unoccupied vehicle. Orders are bundled together if their pickup and drop-off locations are close to each other. Order bundling reduces the size of the problem and encourages fast real-time aggregation resolution times. The advantage of bundling or aggregation of new orders is the effect of scale - new order aggregations are generally of better quality with a larger candidate set compared to in-transit aggregations; most aggregated bundles start from similar pickup locations.

[0057] 2. For bundles below this efficiency threshold, determine the match score between the bundle and the delivery plan currently being executed by occupied / in-transit vehicles. Compare each bundle with each in-transit vehicle delivery plan. For match scores above the threshold, add the order bundle for vehicles with matching delivery plans. Once the in-transit pooling is completed, the driver plans of the in-transit vehicles are updated immediately. In the in-transit pooling, a search is performed on all in-transit vehicles. Vehicles that are far away from any order pickup location are excluded from the candidate set. This approach reduces pre-processing time and solution time. The advantage of in-transit pooling is that the capacity of in-transit vehicles is fully utilized and vehicles are allowed to serve more orders before the end of the current trip.

[0058] 3. Any remaining order bundles are (a) pooled together and assigned to new / unoccupied vehicles, or if the pooling is not efficient enough, (b) the order bundles are broken back into individual orders and returned to (1) for re-bundling.

[0059] In other exemplary techniques, the above or referenced Figure 6 The features of the described techniques may be used alone (or in separate combinations); for example, in the case of Figure 6 In a simpler approach to the described method, comparison of orders may be used as a preliminary stage in order to provide an order bundle. In other techniques, during an order fulfillment trip of a vehicle, an order (or order bundle) may be compared with orders assigned to that vehicle. Optionally, multiple orders may be clustered to improve the efficiency of comparing orders or payloads.

[0060] Figure 6 600 is a flowchart illustrating the steps of an exemplary method for managing payloads transported by vehicles. In step 1 (602), order bundles are created from individual orders, as described above. These order bundles can be created from brand new orders or from recycled orders (see below) or from a combination of the two.

[0061] The bundling step 602 may include TSP modeling as described above. However, this step may also take into account constraints as described above, so that the order bundles have been populated with payloads that are compatible with each other's attributes.

[0062] If the order bundle is efficient, the bundle is passed to be assigned 620 to an empty vehicle. To determine if the efficiency of the bundle is sufficient, a threshold may be applied, as described above. In the example, the efficiency would be calculated as:

[0063] (a) Order batching efficiency = total order direct travel time / driver travel time after batching.

[0064] (b) Driver trip load = Number of orders

[0065] Both (a) and (b) are criteria used to determine whether the bundle (from 602 ) should be assigned to the empty vehicle 620 .

[0066] If the order bundle contains late orders at step 1, the order bundle will be passed to be assigned to a new vehicle even if the order bundle does not meet these two criteria (or even if the efficiency does not exceed the threshold). This is because the late orders will need to be completed urgently, so in order to do this, some efficiency in the order aggregation process must be sacrificed.

[0067] If the order bundle is underutilized (and there are no late orders) at step 1, it is passed to step 2.1 (604), where a match score is calculated for the pairing of the (or each) order bundle with each driver plan in transit. The matching score comparison process can be as described above: TSP modeling can be used to determine the similarity of the location of the order bundle and each driver plan, and in addition (or alternatively) constraints can be used as described above to compare the payload with the capacity of the in-transit vehicle.

[0068] At step 2.2 (606), the scores of some of the comparisons will be high enough that a given order bundle can be assigned 630 to an in-transit driver plan that yields a high comparison score or matching score. In certain techniques, an assignment algorithm or a combinatorial optimization algorithm (such as the known Kuhn-Munkres algorithm) is used to optimize the comparison scores so that the overall efficiency in matching bundles to in-transit driver plans is maximized.

[0069] If this step still does not find a match for the order bundle, then the underutilized unmatched order bundles are then clustered at step 3.1 (608). This could be done simply by fetching each batch of order bundles as they come in, but in this example, clustering is performed using an agglomerative clustering method with constrained cluster size. This clustering method does not require the number of clusters to be defined in advance. It is based on the nearest neighbor chain algorithm with the addition of a cluster size constraint and a maximum distance constraint.

[0070] Once the order bundles have been clustered, at step 3.2 (610), the number of order bundles in each cluster is reduced (compared to the number of available unmatched bundles in step 3.1) and a further aggregation step is performed. This can use TSP modeling or comparison of applied constraints, or both. This can provide a trip plan from these aggregated order bundles. Other techniques can be used for this aggregation stage. For example, a known capacity constrained vehicle routing problem (CVRP) algorithm (such as the capacity constrained vehicle routing problem with extracted delivery and time window constraints (CVRPPDTW)) can be used to provide an aggregated trip plan for these bundles.

[0071] If this final stage produces an order bundle trip plan that exceeds an efficiency threshold (similar to that defined for step 1), the resulting driver plan is assigned to an empty vehicle.

[0072] If there are still inefficient order bundles after step 3.2, they are broken down into their constituent orders and used as recycled orders to help create the initial order bundle at step 1.

[0073] It should be understood that the present invention has been described by way of example only. Various modifications may be made to the techniques described herein without departing from the spirit and scope of the appended claims. The disclosed techniques include techniques that may be provided in an independent manner or in combination with one another. Therefore, features described with respect to one technique may also be presented in combination with another technique.

Claims

1. A communication server device for managing a payload transported by a vehicle, comprising a processor and a memory, the communication server device being configured to execute instructions in the memory under the control of the processor to: Multiple payloads for corresponding different payload categories, each payload category being associated with unique vehicle capability requirements, determining, for a first payload of a first payload category, a value of a first payload attribute parameter indicative of a first vehicle capability requirement; determining, for a second payload of a second payload category, a value of a second payload attribute parameter indicative of a second vehicle capability requirement; comparing the value of the first payload attribute parameter and the value of the second payload attribute parameter to payload capacity data associated with the vehicle; as well as using the comparison to determine the capability of the vehicle to transport both the first payload and the second payload, wherein the payload capacity data associated with the vehicle includes one or more payload attribute parameters of a payload associated with the vehicle; comparing the value of the first payload attribute parameter with the value of the second payload attribute parameter; Compatibility between the first payload category and the second payload category is determined using a comparison result of the value of the first payload attribute parameter and the value of the second payload attribute parameter, wherein the first payload category and the second payload category are different.

2. The communication server device according to claim 1, wherein: The apparatus is configured to: initially compare the value of the first payload attribute parameter with the payload capacity data; and later compare the value of the second payload attribute parameter with the payload capacity data.

3. A communication server device as claimed in any preceding claim, wherein: The first payload category includes one of: passengers; cargo; and perishables.

4. The communication server device according to claim 3, wherein: The first payload category includes cargo, and wherein the first payload attribute parameter is one or more of: size; shape; weight; designated loading area; urgency; required temperature; and fragility.

5. The communication server device according to claim 3, wherein: The first payload category includes passengers, and wherein the first payload attribute parameter is one or more of: urgency; and a required level of service.

6. The communication server device according to claim 3, wherein: The first payload category includes perishable items, and wherein the first payload attribute parameter is one or more of: size; shape; weight; perishability; designated loading area; urgency; required temperature; and fragility.

7. The communication server device according to claim 1, wherein: The payload capability data associated with the vehicle includes one or more vehicle attribute parameter values ​​corresponding to suitability of corresponding payload attribute parameters.

8. The communication server device according to claim 1, wherein: The apparatus is configured to use the payload attribute parameter values ​​and the vehicle payload capacity data to assign constraints to the calculation of a solution for transporting the respective payload.

9. The communication server device according to claim 1, wherein: The apparatus is configured to compare the values ​​of the first payload attribute parameter and the second payload attribute parameter with payload capacity data associated with the vehicle during a trip of the vehicle.

10. The communication server device according to claim 1, wherein: The apparatus is configured to obtain orders for transport payloads, wherein a first order includes at least the first payload and at least one first order location; and a second order includes at least the second payload and at least one second order location.

11. The communication server device according to claim 10, wherein: At least the first order is obtained via a communication link to a communication device.

12. The communication server device according to claim 10 or 11, wherein: The device is configured to compare the first order location and the second order location with location data associated with the vehicle.

13. The communication server device according to claim 12, wherein: The device is configured to, during an order fulfillment trip of the vehicle: compare the value of the first payload attribute parameter and the value of the second payload attribute parameter with payload capacity data associated with the vehicle; and compare the first order location and the second order location with location data associated with the vehicle.

14. The communication server device according to claim 10 or claim 11, wherein: The apparatus is configured to, in a preliminary stage prior to comparing the values ​​of the first payload attribute parameter and the second payload attribute parameter with payload capacity data associated with the vehicle: Preliminarily comparing the first order and the second order; as well as Based on the results of the preliminary comparison, the values ​​of the first payload attribute parameter and the second payload attribute parameter are subsequently compared with payload capacity data associated with the vehicle.

15. The communication server device according to claim 14, wherein: The device is configured to compare the first order and the second order with orders assigned to the vehicle during an order completion trip of the vehicle after the initial comparison of the first order with the second order.

16. The communication server device according to claim 15, wherein: The device is configured to: After comparing the first order and the second order with the orders assigned to the vehicle, clustering a plurality of orders including the first order and the second order; as well as The first order is compared to a third order determined to have a minimum cluster distance from the first order.

17. The communication server device according to claim 1, wherein: The apparatus is configured to use the determined capabilities to generate a completion instruction to be transmitted to the vehicle.

18. A communication system for managing a payload transported by a vehicle, comprising a communication server apparatus, at least one user communication device, and a communication network device operable to allow the communication server apparatus and the at least one user communication device to establish communication therewith, wherein: The at least one communication device includes a first processor and a first memory, and the at least one communication device is configured to execute a first instruction in the first memory under the control of the first processor to: generating an order for the transport of at least the first payload, And among them: The communication server device includes a second processor and a second memory, and the communication server device is configured to execute a second instruction in the second memory under the control of the second processor so as to: Multiple payloads for corresponding different payload categories, each payload category being associated with unique vehicle capability requirements, determining, for the first payload belonging to the first payload category, a value of a first payload attribute parameter indicative of a first vehicle capability requirement; determining, for a second payload of a second payload category, a value of a second payload attribute parameter indicative of a second vehicle capability requirement; comparing the value of the first payload attribute parameter and the value of the second payload attribute parameter to payload capacity data associated with the vehicle; and using the comparison to determine the capability of the vehicle to transport both the first payload and the second payload, wherein the payload capacity data associated with the vehicle includes one or more payload attribute parameters of a payload associated with the vehicle, comparing the value of the first payload attribute parameter with the value of the second payload attribute parameter; Compatibility between the first payload category and the second payload category is determined using a comparison result of the value of the first payload attribute parameter and the value of the second payload attribute parameter, wherein the first payload category and the second payload category are different.

19. A method performed in a communication server device for managing a payload transported by a vehicle, the method comprising, under the control of a processor of the communication server device: Multiple payloads for corresponding different payload categories, each payload category being associated with unique vehicle capability requirements, determining, for a first payload of a first payload category, a value of a first payload attribute parameter indicative of a first vehicle capability requirement; determining, for a second payload of a second payload category, a value of a second payload attribute parameter indicative of a second vehicle capability requirement; comparing the value of the first payload attribute parameter and the value of the second payload attribute parameter to payload capacity data associated with the vehicle; as well as using the comparison to determine the capability of the vehicle to transport both the first payload and the second payload, wherein the payload capacity data associated with the vehicle includes one or more payload attribute parameters of a payload associated with the vehicle, comparing the value of the first payload attribute parameter with the value of the second payload attribute parameter; Compatibility between the first payload category and the second payload category is determined using a comparison result of the value of the first payload attribute parameter and the value of the second payload attribute parameter, wherein the first payload category and the second payload category are different.

20. The method according to claim 19, comprising: comparing the value of the first payload attribute parameter and the value of the second payload attribute parameter to payload capacity data associated with one or more other vehicles; using the comparison to determine capabilities of the other vehicles to transport both the first payload and the second payload; as well as One of the vehicles is assigned using the determined capabilities for transporting the first payload and the second payload.

21. A computer program product comprising instructions for implementing the method of claim 19.

22. A computer program comprising instructions for implementing the method of claim 19.

Images