Autonomous Van and Robot Last-Mile Logistics Platform: A Reference Architecture and Proof of Concept Implementation

Abstract

Background: With urban logistics facing challenges such as high delivery volumes and driver shortages, autonomous driving emerges as a promising solution. However, the integration of autonomous vans and robots into existing fulfillment processes and platforms remains largely unexplored. Methods: This paper addresses this gap by developing and piloting a comprehensive blueprint architecture tailored for autonomous mobility in urban last-mile delivery. The proposed framework integrates autonomous vehicle operations, data processing, and stakeholder collaboration. Results: Through initial implementation and piloting, we demonstrate the practical applicability and advantages of this architecture. Conclusions: This study contributes to the understanding of essential data, services, and tools, providing a valuable guideline for Logistics Service Providers aiming to implement autonomous last-mile delivery solutions.

1. Introduction

With the continuous increase in shipment volumes on the Last-Mile (LM) in urban areas, rising customer demands for individual services and the growing shortage of drivers, urban logistics is facing major challenges. This not only affects the efficiency and costs of delivery processes, but also has an impact on urban areas in the form of a lack of public space and traffic disruption [1,2,3].

The last mile describes the transport section starting from a distribution center close to the city to the final recipient. This section is characterized by various different product ranges and particularly for courier express and parcel (CEP) shipments primarily by a one-to-many source-sink relationship. This means that various recipients are supplied from one starting point, resulting in many stops with few deliveries at one stop, creating a very inefficient and therefore expensive process [2,4,5].

Autonomous vehicles (AVs) could provide a solution, as these do not require a driver, can be cost-effectively operated at any time and within a new, networked ecosystem [6,7]. The BeIntelli research project [8] is piloting in two different use cases how autonomous delivery vans and sidewalk autonomous delivery robots (SADR) can be used in the last mile and how they can be integrated into a new type of platform economy.

In one use case, SADRs are used to transport groceries directly from supermarket stores to recipients. This enables omni-channel distribution and uses existing infrastructure in city centers. The second use case involves the delivery of CEP shipments using a Van-and-Robot (VnR), leveraging the advantages of autonomous delivery vans and SADRs. However, a clear research gap exists in integrating these technologies into a cohesive architecture for urban logistics. This study addresses this by proposing a Last-Mile Logistics (LML) reference architecture.

To this end, a blueprint architecture for autonomous mobility has already been developed alongside the project. The objective of this work is to specify this generic architecture for autonomous last-mile deliveries using the two pilot use case applications of BeIntelli. The conceptualized and realized automated test vehicle (van) is depicted in Figure 1. We present the platform, services and tools developed and piloted alongside the project and demonstrate how these apply the proposed reference architecture.

With this objective, the focus of the paper is on the development of an architecture for autonomous LM delivery solutions in urban areas. This refers to a platform that integrates the functions of operating AVs in the LM, thus making these functions accessible to stakeholders such as senders, Logistics Service Providers (LSPs) and recipients. The platform acts as an intermediary between involved actors.

2. Contribution and Outline

We propose an architecture for realizing VnR LM and Hub-to-Hub (H2H) logistics in urban environments. This paper describes existing solutions, concepts, trends and technical requirements. We apply a blueprint architecture to map the requirements to the described components in the architecture, which includes the layers hardware, middleware, autonomous driving system (ADS), platform and applications as well as the actors and their roles on the platforms. Based on the identified elements, we highlight core components and indicate data at the respective granularity levels, tools and services to be considered for scenario implementation.

Section 3.1 provides an overview of application fields, followed by introducing the underlying blueprint architecture in Section 4. Section 5 classifies the transformative nature, LML provides and poses the requirements for autonomous fulfillment with vans and robots. In Section 6, we apply these requirements to the blueprint architecture, resulting in a reference architecture for autonomous VnR LML. This architecture has been partially implemented and tested within the BeIntelli research project in Berlin, Germany (see Section 7). While the blueprint envisions fully autonomous VnR on public roads, testing is currently limited due to regulatory and technical delays, though the architecture anticipates full system integration.

3. State-of-the-Art: Autonomous Logistics

Autonomous logistics related to transportation are being investigated across various respects, from intra-facility to public road mixed-traffic goods transportation. We classify application fields and introduce existing approaches and solutions.

3.1. Application Fields for Autonomous Vans and Robots

Various AVs are used in logistics in different transport domains and industries. While the standard application has been in-house logistics and closed-off areas, various startups are now venturing into extending these applications to the last mile and middle mile in mixed-traffic environments.

On the middle mile, i.e., in replenishment of hubs in classic hub-to-hub transports or in retail store replenishment, autonomous (small) trucks and autonomous delivery vans can be found in particular. These primarily address transport (CEP) shipments, grocery shipments, or medical products [9,10].

On the last mile, however, various versions of autonomous delivery robots and aerial delivery drones are used in addition to autonomous trucks and autonomous delivery vans. They are primarily used to deliver CEP shipments, groceries and medical products, but also ready-to-eat meals. They differ primarily in terms of range, payload weight, speed and modes of transport [11].

Accordingly, different services are offered by the vehicles, e.g., autonomous delivery robots can have just one or several compartments and drive either on the sidewalk or on the street. In general smaller vehicles like SADRs are used for individual and flexible or on-demand delivery services where there is not enough demand for efficient bundling. For instance, this is often the case with groceries or ready-to-eat meals. Aerial drones, on the other hand, are mainly used for fast deliveries such as medical products. When large quantities are involved, such as in the CEP market, these shipments are often bundled, meaning that larger vehicles such as autonomous delivery vans are commonly used. To leverage the advantages of different vehicle types and mitigate their respective drawbacks, two types of vehicles are also used in combination. Primarily, delivery vans and SADRs are considered, as drones are less commonly used in urban areas due to regulatory hurdles. This approach, known as the VnR approach, combines the range and bundling advantages of delivery vans with the flexibility and low space requirements of SADRs. Based on these potentials, in addition to the application of SADRs, the VnR approach has been examined in the BeIntelli project and in this paper to demonstrate a Proof of Concept (PoC) for the overall technical system [12,13,14].

Nevertheless, it must be emphasized that the majority of AV applications are still in the pilot phase and there is no consensus on the most suitable use cases for the various vehicles. The best matching use cases for different vehicle types depends not only on the product and demand restrictions as described, but also on the stop density, available space, and political restrictions. Thus, this classification represents a current trend rather than a definitive allocation.

3.2. Existing Approaches, Concepts and Solutions

Many companies have developed both SADRs or autonomous delivery vans, some of which are already being used on a pilot basis. WeRide [15], UDELV [16], Einride [17], Loxo [18], Clevon [19], Nuro [20], Meituan [21] and VanAssist [22] are examples addressing solutions and projects for autonomous delivery vans. These vehicles vary in size and are being used for micro mobility solutions as well as in high volume tours. In turn, Starship Technologies [23], Kiwibot [24], Postmates [25] and Ottonomy.io [26] are focusing on SADRs. Depending on the use case, these companies offer proprietary applications or use existing platforms such as Uber Eats or Bolt [10].

Pilots that connect both vehicle types are less common. The most prominent example is Mercedes Vans and Robots [14]. However, this concept does not include an autonomous delivery van and relies on manual handling of shipments in the SADRs. Furthermore, Ford Motor Company has also developed an approach with a humanoid robot [27]. There are also related pilots from research such as LogiSmile or TaBuLa-Log [28,29]. Apart from this distinction, there are comparable methods for delivery vehicles and drones that outline systems for planning and managing the delivery process.

In the literature, the focus of VnR concepts is primarily on the technical design of the vehicles and on route optimization as well as the associated algorithmic approaches [30,31,32]. However, publications on architectures that encompass the necessary entities for designing and implementing these concepts in existing and new industry solutions are scarce.

While the discussed approaches provide valuable insights into autonomous delivery solutions, they are distinct from our proposed solution as they focus primarily on proprietary implementations or isolated technologies rather than an integrated, scalable platform architecture.

4. Blueprint Architecture for Autonomous Mobility and Transportation

The implementation of connected, cooperative and automated mobility (CCAM) and transportation solutions is a complex task. It involves various stakeholders (actors), assets, and multiple layers of both proprietary and publicly accessible systems, connected to process data at different granularity levels to achieve autonomy. The three core layers Vehicle, Edge and Cloud form the foundation for this architecture and address the so-called Distributed Artificial Intelligence (DAI) approach to autonomous driving (AD) [33,34]. Platforms play a central role in handling transaction of any kind (e.g., data and goods) to interconnect between actors and systems.

We adopt the blueprint architecture introduced in [33], providing a model for building autonomous mobility solutions within the platform economy, see Figure 2. The architecture proposes main components and core layers that constitute the functions for realizing AD, see [33,35]. Each component comprises interconnected sub-components built on platforms, serving applications deployed within the broader ecosystem of actors [33].

The architecture was developed alongside the BeIntelli research project on autonomous mobility and acts as an initial blueprint to be further tested and validated at specific use cases. BeIntelli aims to develop an AD software-stack (AI-Mobility-OS), digitize various autonomous test vehicles, establish a platform and showcase AI advancements in mobility to the society [33,34].

The project designs and tests various use cases including LML and establishes a ‘real-laboratory’ environment for developing, implementing, testing and validating solutions. This includes the digitalization of a van and delivery robots, see Figure 1. The blueprint architecture is subject to continuous improvement, incorporating learnings from use case applications [33].

In this paper we apply the blueprint to (1) propose a LML reference architecture for autonomous VnR LML, and (2) evaluate the blueprint architecture. Further implementation will be conducted within the BeIntelli project framework.

5. Transformation of the Last Mile Logistics Service Providers

In the domain of supply chain management, LML plays a critical role by encapsulating the final phase in the delivery process, where goods are transported (often by a LSP) from the order penetration point to the recipient. This segment is not only pivotal for ensuring customer satisfaction but also has a significant impact on the cost and efficiency of the delivery process. Characterized by the planning, implementation, and management of both the transportation and storage of goods, LML strives to achieve a seamless and cost-effective delivery process [36].

Following this foundational understanding of LML, it is evident that the digitalization of logistics facilities and the development of connected and automated vehicles (CAVs) are fundamentally transforming the field of transportation. Technological innovations such as the Internet of Things (IoT), cloud computing, data analytics and digital platforms have revolutionized LML, transitioning it into an interconnected ecosystem of various stakeholders and objects. This transformation is leading to the development of new services and operational improvements, such as facilitating intelligent route planning, real-time tracking, and predictive analytics. These advancements enhance efficiency, reliability, and customer satisfaction, showcasing the role of digitalization and technological innovation in redefining logistics and supply chain management [37].

LML and H2H logistics are major use cases that have been conceptualized, developed, and tested in both research and industry settings, further illustrating the practical application and benefits of these technological advancements.

6. Towards an Autonomous Logistics Architecture—The Case BeIntelli

Emerging application fields for VnR and corresponding approaches, concepts and solutions for implementation, are introduced in Section 3. When combined with the transformative nature of autonomous LML, these elements necessitate a comprehensive understanding of how to orchestrate actors, components, data, tools and services for realization and operation.

6.1. Autonomous Fulfillment with Vans and Robots—Scenario and Requirements

The central logistics pilot use case in the BeIntelli project is based on the VnR concept for LML (Figure 3). Accordingly, the process of the concept starts at a distribution center close to the city and assumes that upstream fulfillment tasks, such as ensuring the availability of goods, have already been completed. In this concept autonomous delivery vans transport SADRs along with the shipments, dropping them off as close as possible to the recipients on the sidewalk.

This approach leverages the advantages of both vehicle types: bundling shipments in the van to increase tour efficiency and allowing for parallel, individual deliveries by the SADRs. Moreover, the SADR’s flexibility enables the delivery van to avoid stops directly at delivery addresses, mitigating second-row parking issues and optimizing the use of limited urban space [30,31,32]. The vehicle concept and SADR drop-off is shown in Figure 1 and Figure 3.

In the BeIntelli project, the PoC setup allows an autonomous delivery van to carry up to four SADRs and 10 shipments. This capacity is expected to increase in future early-market applications. A specially developed Material Flow System (MFS) facilitates the loading of SADRs with shipments directly inside the van, enabling both loading for delivery and automatic unloading for returns or undelivered items. Thus, the van serves as a mobile micro-hub, beginning its tour at a depot or distribution center pre-loaded with sorted shipments suitable for the SADR’s capacity in terms of size and volume. This operation necessitates advanced route planning that accounts for both the van’s and the robots’ paths, requiring a two-stage planning process. An optimization model mathematically assigns recipients specific SADRs, as well as the optimal stopping points for dropping off and picking up. Figure 4 illustrates the relationship between sender (provider) and recipient (consumer), highlighting the core actors, services, the flow of goods (material) and data between the entities, with dashed lines representing data flows and solid lines indicating material flows.

Given that SADRs currently cannot climb stairs or open doors, the recipient must meet the SADR at a predetermined meeting point, such as the front door. Accordingly, the delivery status and the Estimated Time of Arrival (ETA) are continuously updated and displayed to the recipient in an application. Recipients are also informed via push messages as soon as the SADR is close enough to the delivery address. This ensures that the recipient can reach the meeting point on time, avoiding unnecessary waits. This application enables users to open and close the SADR, confirm receipt of the shipment and communicate with customer support in case of issues. Eventually, it is anticipated that SADRs will be able to interface with facility management systems, allowing them to automatically open doors and summon elevators.

Accordingly, the physical LML process, which begins at a distribution center near the city, requires an information technology solution. This solution will facilitate the communication and processing of information crucial for planning and controlling the operation. Data, services and components are made available by actors within the ecosystem and through transactions on both proprietary and open platforms. Embedding the described scenario within the given blueprint architecture enables the proposal of a reference architecture for autonomous VnR LML. This architecture is depicted in Figure 5.

6.2. Embedding in the Platform Economy for Autonomous Mobility

Drawing upon the established architecture for autonomous mobility solutions (illustrated in Figure 2) and the specified requirements pertinent to the VnR concept, we present a refined reference architecture, see Figure 5. The core elements of this architecture are building upon a platform encapsulating baseline components. The platform interfaces between the respective entities, including: 1. sender (supplier/provider), 2. recipient (consumer), 3. vehicle assets (provider), 4. operations (provider), 5. analytics, and 6. various connected service provider.

We adopt the three layers vehicle, edge and cloud for building as the underlying structure for the major components:

1.

Hardware: constitutes the vehicles truck, van, delivery robots, and infrastructure components such as the extended road-side-units (computing, communication, sensors)

2.

Middleware: intermediates between the different hardware entities (vehicles/infrastructure) and ADS layer (e.g., HD map, V2X communication)

3.

ADAS or ADS: provides the basic and advanced for autonomous driving

4.

Platform: entails data acquisition, processing, and provision at demanded granularity levels as well as basic and advanced services that are provided to the involved stakeholder

5.

Applications: comprises applications needed for interaction between the actors as well as to execute, manage and monitor vehicle operations

These major components form the core block of the developed reference architecture. Each respective component entails specific requirements for the autonomous VnRs. For instance, the middleware should provide access to gates, doors or elevators, which in turn allows the vehicle to execute its order efficiently. Moreover, the ADS should communicate fuel/battery levels and manage access to vehicle doors or compartments for deliveries.

Upon receiving an order, the sender forwards the order data to the platform’s services, transport management system (TMS) and analytics for operation. Thereby, attention must be paid to data access and ownership. The data is therefore classified into proprietary data and third-party data.

The operation of the vehicles and the final fulfillment of a customer’s order requires fleet management for planning and controlling vehicles and tours as well as teleoperation for technical supervision of the vehicles.

Fleet management involves evaluating vehicle data to perform tasks such as predicting future maintenance, utilizing vehicle capacity, securing regulatory compliance or optimizing the fleet’s energy consumption. The TMS’s basic tasks include filtering shipments for weight and volume suitability, creating and exchanging digital shipment documents and generating tours. This involves considering storage management in vehicles and planning, optimizing and assigning vehicle routes in line with the VnR concept.

Furthermore, analytics functions of operation aim to identify profitable shipments by analyzing tour length, process times, shipment feasibility and tour utilization across different application areas. Beyond fleet management, technical supervision for vehicle operation is essential and required by German law using a teleoperation system. This monitors several vehicles simultaneously, approves driving maneuvers and controls vehicles (access to compartments, vehicle status, etc.).

Finally, the recipient accepts their shipment. With transparent availability of all necessary shipment information, the recipient can meet the vehicle at a designated location where they can open and close the vehicle’s compartment. The user interface should allow the recipient to access support options.

Thus, the individual components of the platform are interconnected, allowing them to facilitate transactions among themselves. However, the allocation of functions and ownership of platform components remains flexible to accommodate evolving business models.

The reference architecture addresses producer/supplier, consumer and platform mechanisms, known from the platform economy concept. In the described VnR scenario, we identified three supplier roles: (1) sender (online/offline), (2) operator (vehicle fleet) and (3) components (involves middleware, ADS, platform and applications). Each role could be fulfilled by various actors. While suppliers may utilize/consume deliverables or output from other actors in the ecosystem, thereby accessing data from other suppliers, the opposite end of the spectrum is represented by the end consumer receiving the sender’s delivery.

Assuming a high demand of goods delivered via autonomous vans and robots, the increase in supplied goods and vehicle deliveries enhances service attractiveness to consumers, potentially on a more convenient scale. This example simplifies positive indirect network effect. Moreover, the platform facilitates positive direct network effects among senders, as the accumulation of a larger volume of input data enables the platform to offer improved optimizations and services. As each sender contributes more data, the platform becomes increasingly capable of identifying the most efficient logistics solutions, thereby benefiting all participants. However, this aspect falls outside our current scope and merits further research.

7. Application and Test Pilot of the LML-Architecture in the BeIntelli Project

This section maps the proposed reference architecture to the developments in the BeIntelli research project, thus showcasing its application and pilot in the real-world.

We show the advantages and limitations of this architecture, as well as resulting future work for improvement.

7.1. The Role of the BeIntelli Real-Laboratory for Developing, Testing and Validating the Van-and-Robot Scenario

Within the BeIntelli research project, vehicles (van, delivery robots), a software-stack for AD (ADS), a platform and applications are developed to pilot the LML scenario described in Section 6.1. The project’s platform baseline elements allow for conceptualizing, testing, and validating the scenario. These elements are:

• Data acquisition, processing, storage and provision at different granularity levels; e.g., vehicle data
• Provision of development tools (APIs, SDKs) and a runtime for the development, test and validation of solutions
• Provision of services that function as modular components for solutions

While the BeIntelli setup constitutes all elements for testing the scenario, the framework also enables third parties to integrate their own vehicles and solutions. This allows for the testing and validation of specific functions, such as the ADS component. The modular architecture of the real-laboratory ensures scalability by enabling the seamless integration of additional autonomous VnRs. The infrastructure’s flexibility allows third-party solutions to be validated without major reconfiguration.

7.2. Application of the Reference Architecture Towards the BeIntelli LML Architecture

The emerging LML architecture addresses four identified core elements: (1) Supplier (Sender), (2) Consumer (Recipient), (3) Operations and (4) Technical Layers. Figure 6 provides insights about BeIntelli’s order journey, representing the flow of actions in the LML scenario. In turn, Figure 7 shows the embedded automated vehicles in the TMS.

The technical layer acts as an intermediary between the Sender and Receiver, and the operations. Figure 8 displays the emerging BeIntelli LML architecture to implement and pilot the VnR scenario. The architecture follows the blueprint architecture for autonomous mobility presented in [33] and is based on the proposed reference architecture in Section 6. It constitutes of the six layers, ranging from Hardware (devices/computing), Middleware, ADS, Platform and Cloud towards Applications, Operations, Supplier and Consumer.

While the reference architecture provides a comprehensive overview of potential components, the evolving BeIntelli LML showcases the practical implementation of selected elements. However, some components are only partially realized. The current implementation allows to create, process and complete orders as well as managing orders of several delivery robots. The testing of the VnR interplay on the actual road is subject to further research.

The depicted architecture demonstrates data exchange between vehicles and middleware, and towards the platform (cloud), which distributes data a different granularity levels (pre-processed) towards the respective applications, such as order management, TMS, or the control center, to name just a few examples. The architecture’s design supports scalability by allowing dynamic configuration and integration of additional vehicles, stakeholders, and services. The middleware and cloud provide a distributed system capable of handling increasing data loads and operational demands.

7.3. Evaluation of the Implemented Architecture

The implemented architecture has been tested alongside the BeIntelli project and within its real-laboratory on public roads. For the initial tests, in total, 78.06 km have been driven by a SADR with 21 orders and a share of 22% required remote operation mode. The robot’s average velocity in automated driving mode achieved was 2.67 km/h. It was affected by obstacles both moving and parked as well as limits due to the early stage of development.

The interplay between the robots and van has not been tested on the public road yet, due to delays in setting up the vehicle, deploying the developed ADS on the vehicle, and regulatory approval. Nonetheless, within the given project’s time, the envisioned scenario and evolving van concept was implemented including a lift, in-vehicle conveyor belt as well as the required components to achieve automated driving functions. Testing the interplay between VnR is subject to further research. In addition, future research should adopt the developed approach of infrastructure supported AD, aiming to optimize routes for e.g., the delivery time. Further details and explanations regarding the pilot applications, as well as how the data was collected, are described in greater detail in the article by [38].

8. Discussion and Future Research

Corporations are developing and deploying delivery robots of various sizes for road and sidewalk use, often within pilot projects aimed at package delivery and grocery sectors. However, there lacks a uniform reference architecture for defining roles and a framework for testing and validation.

Besides the architecture, operation models must be tested to determine the effects of operating SADRs in the public transport sector. This includes assessing delivery strategies, route planning, and the practical coordination between vans and robots, including drop-off and pick-up dynamics.

Furthermore, defining the platform, ownership of assets, data, and services across stakeholders is essential, given that business transactions depend on the value added by each actor within the ecosystem. For instance, a vehicle fleet operator may prefer to retain its route optimization strategies in-house, while a goods supplier might wish to maintain control over delivery sequencing decisions to preserve service sovereignty. The provision and consumption of respective services leads to network effects further to be investigated.

The proposed reference architecture provides a classification of necessary components but requires real-world validation, which will be pursued in the BeIntelli research project. Additionally, the further examination of network effects within the proposed architecture and corresponding actors remains unexplored. While the platform outlines the necessary functions and interrelations, further research is needed to clarify stakeholder roles or the emergence of new specialized entities.

9. Conclusions

The transformation of LML to an interconnected ecosystem through innovative technologies such as CAVs necessitates the development of a new reference architecture. This architecture incorporates the required elements such as assets, data at different granularity levels, components and their interplay for operational improvements. Presenting the specification and extension of the blueprint architecture for autonomous mobility, this paper leverages on the approach to DAI for AD, CCAM and the platform economy to enhance the LML process, and proposes a LML reference architecture. The architecture structures components within a platform, outlining their interrelations. Consequently, the operations block has been introduced, encompassing systems, services and tools essential for implementing LML according to logistical specifications.

The proposed architecture facilitates task division and the development of scalable, specialized services, thereby enabling new business models based on asset and data ownership. For instance, the platform could be owned by the LSP for the integration of operational processes, the vehicle manufacturer to integrate the vehicles into existing operational processes, or a new independent platform operator acting as a new stakeholder.

New approaches of collaborations between stakeholders are enabled for integrating physical and informational processes with AV operations. Additionally, a single provider could serve as a system integrator to implement integrated LML solutions. The individual functions on the platform may provide scaling effects, for instance:

• Remote/Tele-Operation can be provided for different vehicles and operators (Teleoperation as a Service)
• Operation can be offered as a LSP for various senders (Autonomous Delivery as a Service)
• A platform can be owned by the vehicle manufacturer to integrate the vehicles into existing operational processes; or multiple platforms can take different responsibilities and tasks for realizing LML
• The ADS could function as a digital driver for different operators (Autonomous Driving as a Service)

This flexibility in ownership and operational models underscores the architecture’s potential to advance last-mile logistics by enabling scalable, specialized solutions and fostering innovative collaborations among stakeholders in the field.