From Drive-By-Wire to Autonomous Vehicle: Urban Freight Vehicle Perspectives

Freight Urban RoBOTic vehicle (FURBOT) is a complete drive-by-wire vehicle expected to perform autonomously in an urban setting. This upgrading has raised issues that need to be resolved/addressed for the vehicle to achieve a higher level of autonomy. This research addresses two of these main issues. The First is the legal framework/licensing issue necessary to be addressed for the vehicle to be insured and legally drive on public roads. The second is the changes and upgrading the vehicle must go through to become a complete autonomous freight handling vehicle. The outcome of this research led to the decision for correct categorization of the vehicle for resolving its licensing issue and its legal status on the European roads by understanding the limitations of the vehicle, which includes vehicle current state and its structural properties. An additional contribution of this research is identifying the software and hardware changes the vehicle has to go through to be fully autonomous. This includes identification of correct sensors and their placement and quantities. In addition, in-depth study for software identification for the vehicle is provided resulting in favorable choice for an off-the-shelf software. Additionally, foreseeable issues, expectations from the vehicle and requirements (considering its demonstration as an autonomous vehicle) that need to be fulfilled are also highlighted. For demonstration site, use cases and site dynamics are also studied for achieving autonomy. Fulfillment of these requirements is necessary for the vehicle to demonstrate autonomous navigation and freight handling for SHOW (SHared automation Operating models for Worldwide adoption) H2020 project for delivering freight in an urban setting.


Introduction
FURBOT (Freight Urban RoBOTic vehicle) is an urban freight delivering vehicle designed for last-mile delivery in an urban environment. The vehicle was part of European Green Vehicles Initiative (EGVI) funded under the umbrella of FP7-Transport European project ending in December 2015 [1,2]. It was completed as a complete drive-by-wire vehicle and conceptually designed to be converted to an autonomous vehicle. Recently, FURBOT has taken part in SHOW (SHared automation Operating models for Worldwide adoption) project where 69 partners from all across the EU will take part in the adaptation of autonomous vehicles in 20 cities across Europe where autonomous vehicles will demonstrate their autonomy for 24 months (https://show-project.eu/). For a full demonstration, the vehicle needs to be adapted in an autonomous environment with full legislative support. For homologation of the vehicle, two separate unique hurdles are being faced. The first one is the vehicle approval under EU regulations for the vehicle to operate on public roads for delivering goods. The second is the upgrading of the vehicle to turn it from a drive-by-wire vehicle into a completely autonomous vehicle. The homologation of FURBOT is thus only possible if we resolve both issues. Thus, the need for our work is generated.
Several freight delivery options are available within urban setting for last mile delivery, which include advance delivery locations (reception boxes (parcel boxes), delivery boxes, controlled axes points, collection points and locker banks) and advanced delivery vehicles (electric delivery vehicles, electric cargo bicycles and autonomous driving vehicles) [3]. However, any single solution is not enough for smart last mile delivery, as every option has its own advantages and disadvantages [3]. However, road-based transportation using AVs can significantly reduce accidents and operational time of vehicles [4]. Parcel lockers do not seem to provide less congestion for last mile delivery if their utilization is less than 93% [5]. Among advance delivery locations, reception boxes have the greatest usefulness, flexibility, punctuality, security, privacy, reliability and lack of liability issues [6]. In our case, FURBOT provides the unique solution of integrating AVs with delivery boxes. This unique solution eliminates disadvantage of customer unavailability on reception with smart delivery locations, which is close to customer [7].
Bringing autonomous vehicles on the road is still an enormous challenge for companies. In March 2018, Tesla's vehicle had an accident killing its passenger while on autopilot [8]. Autonomous vehicles are extremely expensive and yet not completely reliable [9], thus a good start for autonomous vehicles would be to introduce them in last mile delivery option where risk is minimum [9]. For first stage deployment of autonomous vehicles, slow speed last mile freight delivery is an excellent opportunity [9]. With over 1.7 billion parcels delivered per annum [10], optimization in this business sector is a very fruitful idea [11]. In addition, inaccessible curb space, improper off-loading facilities for the vehicles and lack of elevators waste a lot of energy in last mile delivery [12]. In such scenario, delivery boxes through vehicles best suits the need for the customer and operators alike [13]. To justify such need, FURBOT is an in-line vehicle to solve the last mile delivery problem in urban setting.
Bringing autonomous vehicles on the road is not a new concept now; in fact, exactly a decade ago Google announced that they had built a car capable of driving itself [14]. Since then, autonomous vehicles have come a long way from driving themselves [15] to delivering freight [16]. Recently, JD.com (https://www.chinamoneynetwork. com/2017/06/19/jd-com-launches-robot-delivery-services-in-chinese-universities) (http: //www.ecns.cn/news/sci-tech/2018-06-20/detail-ifyvmiee7350792.shtml) used robot delivery services in Beijing and universities of China [17,18] for delivery of personal packages. Similarly, Starship technologies (https://www.theverge.com/2019/8/20/20812184 /starship-delivery-robot-expansion-college-campus) is also going to deploy its six-wheeled delivery robots in the universities of the US for delivery services within university campuses [19]. It is now clearly envisioned that delivery systems are specially targeted for autonomous vehicles [17][18][19]. However, thus far, heavy freight delivery is not completely possible in an urban setting through autonomous vehicles. FURBOT will attempt to achieve this milestone for autonomous freight delivery within an urban environment. The concept of using heavy autonomous vehicles is still under study [20], but these concepts are still in the conceptual phase and use mini autonomous vehicles for personal package delivery within urban environments. The idea is to use large vehicles (LV) to deliver and deploy small autonomous vehicles (SAV) for personalized deliveries of freight [20,21]. The novelty of FURBOT is that it is not only a freight delivering autonomous vehicle, but it is also equipped with fully functional forklifts, capable of loading and unloading freight autonomously.
Requirement formalization for autonomous vehicles is a very crucial need. Whether it is for bringing the vehicle on the roads [22] or to formalize the requirements for localization [23], addressing the requirements is a must for advancing the vehicle upgrading process. For this purpose, requirement formulation for conversion from drive-by-wire vehicle to a completely autonomous vehicle driven on roads is necessary. This need thus essentially created the necessity of our work.
There is a lack of research published for policy and regulations formation for autonomous trucks-large vehicles [24]-because of the belief that it will be a long time until they are formally allowed on roads [25]. This natural belief creates increased confusion regarding the policies governing freight vehicles and legalizing them for the roads. Thus, the need for requirement assessments for policy and regulations for bringing the vehicle on the roads for individual cases as FURBOT arises. For autonomous vehicles to reach their full potential, the policies should be ready for the interests of manufacturers and potential plaintiffs alike [26]. The current system, however, does not provide such an environment [26].
In addition, sensor identification for autonomous vehicles is also an important topic. As the identification of sensors for autonomous vehicles is an important issue, there is research available for identification of sensors [27], their fusion within the system [28] and their use in autonomous vehicles [29]. As FURBOT is upgrading itself from a drive-by-wire vehicle to a fully autonomous vehicle within a short period, it is essential for its upgrading that identification, fusion and use of the new sensors which will enable it to navigate and handle freight autonomously be carefully selected. It is also necessary to identify an open platform as in [30] which can help in bonding the new sensor hardware with the mission computer of the vehicle.
This research is thus an attempt to address two main core issues for FURBOT for it to be upgraded from its current state to an autonomous vehicle. The first issue revolves around the correct categorization of the vehicle so it can earn legal status on the road. Second, the vehicle must also be upgraded with hardware and software for it to be a fully autonomous vehicle. For that, we should identify the required sensors and the complete platform where the hardware can be easily incorporated in the software.

Research Methodology
The two main core issues this paper addresses (mentioned above) arose for the vehicle's amalgamation in the SHOW project. The methodology developed to address these issues is discussed in this section. Two key questions are answered: (1) How were the data collected/generated? (2) How the situation to come up with the solutions analyzed?
One focus for this study is to develop a strategy to secure licensing for the vehicle to be insured properly. To resolve this issue, first, the current state of vehicle is distinguished, highlighting its feature. Second, a study of the European type approval is carried out, identifying the vehicle categories [31] approved by European commission. Comparing the vehicle design with the approved vehicle categories by European commission, best suited vehicle categories are identified. Afterwards, requirements in context with the current state of the vehicle are analyzed, keeping in view selected vehicle categories. Hurdles to categorize our vehicle in the shortlisted categories are highlighted and analyzed. Thus, we were finally able to resolve the vehicle categorization issue for licensing and insurance purposes.
The second focus of this research is to identify hardware and software changes the vehicle requires in order to upgrade itself from a drive by wire to an autonomous vehicle. The methodology opted for resolution of this issue involved a literature search in the type of sensors required by the vehicle to be upgraded to autonomous vehicle. Similar autonomous vehicles are studied to identify sensor requirements. Study participants involved vehicles with similar shape as FURBOT. Several study participants are chosen to identify software required for the upgrade of the vehicle. The inclusion criterion for software is ease of changing/development of autonomous navigation modules, whereas the exclusion criterion is the rigidity of change in software, i.e., being a black box. Further inclusion criteria for software are for it to be open sourced, accessible and have a proven track record in autonomous industry. Vision check for 3D LiDAR is performed through CAD software and the results are analyzed to identify the right sensors and their quantity.
Regarding the demo site, in-depth site study is performed collecting data from the site. Afterwards, use cases are developed considering the environmental constraints.
Step-bystep freight collection for the vehicle is envisaged. The autonomy level required is analyzed and completed through project constraints. Environmental problems and advantages are studied and highlighted. Complete demonstration is studied and analyzed, helping in clearly constraining the performance requirements.
The paper is further organized into five additional sections. In Section 2, the current state of the vehicle, its mass distribution and current features of FURBOT are discussed. In Section 3, we discuss the work progress in terms of current achievements and future goals. In Section 4, the technical classifications of how the vehicle can be correctly categorized is debated. The licensing issues are additionally highlighted. In Section 5, we discuss the foreseeable issues about the demonstration in the actual site. Finally, the vehicle upgrading requirements and expectations are highlighted in Section 6 before the conclusion.

State of the Vehicle
The vehicle is expected to transport two types of freights i.e., pallets and small parcels, as a feeder service from retail urban distribution service in late nights or early mornings. It is expected that the vehicle will collect freight from the loading bay, navigate to the designated store and deliver the freight. The expected workload per day for the vehicle during the full demo is around 5 h or 5-6 autonomous deliveries in full use case demo of the vehicle.
The vehicle at its current state is a complete drive-by-wire vehicle. Loading and unloading functionality for the cargo pallet is in working condition for the vehicle. The vehicle has two primary modes, i.e., fork mode and drive mode. While in drive mode, the vehicle cannot operate a forklift for loading/unloading of freight, and, while in fork mode, it cannot drive.
The vehicle is also equipped with multiple stereo cameras (side cameras, front and back) for the driver to see around the vehicle (with screens in front of the driver). A pair of single-plane LiDARs (front and back) are also mounted for emergency braking. The vehicle is also equipped with driving assistance, including emergency braking and adaptive speed control. However, in its current state, it lacks the sensors for complete autonomous driving. At the current stage of the project, it can be categorized as a fully functional drive-by-wire vehicle with loading/unloading capability of freight. The current state of the vehicle is shown in Figure 1.

Vehicle Components Breakdown
The overall mass breakdown considering its different components is mentioned in Table 1. The vehicle dimensions are given in Table 2. The passenger and cargo of the vehicle do not make up the weight of the vehicle for classification; thus, the mass of these components is ignored. The tires of the vehicle take up approximately 25 kg of weight.  Apart from these three components, other components of the vehicle are discussed and detailed below. Additionally, a full CAD drawing of FURBOT is shown in Figure 2. The vehicle is comprised of eight major components which are discussed below. These components are: Vehicle cover 4. Batteries 5.
Installed sensors and additional hardware 6. Cargo 7. Passenger 8. Tires The chassis, as shown in Figure 3, is made of steel and is the heaviest part of the vehicle, weighing 500 kg. Because of this steel frame, it is very difficult to trim down the weight of the vehicle. The structural mass of the steel frame is unavoidable unless redesigning of the vehicle is carried out.

Forklifts
Two separate forklifts are part of the total mass of the vehicle. The mass of each forklift is roughly 90 kg. Thus, these two forklifts combined make up about 180 kg of FURBOT's mass. The forklift design is shown in Figure 4. It is also discussed that the mass of forklifts could be part of the payload/cargo of the vehicle and can be excluded from the total mass of the vehicle.

Vehicle cover
FURBOT body cover comprises the orange cover which fits on the chassis of the vehicle and gives it the overall shape of the vehicle. The cover of FURBOT is roughly 300 kg and includes almost all the vehicle's outer body. The CAD model for the body cover is given in Figure 5.

Batteries
The mass of the batteries is not included for L7E category vehicles, but it is included for N1 category vehicles (vehicle categorization is further discussed in Section 4), thus this mass is highlighted. The batteries have custom made power management with distributed drivers. The battery power pack is shown in Figure 6. The battery management cabinet on the battery frame and the complete power unit can be easily assembled or removed from the back of the vehicle.

Installed Sensors and Additional Hardware
At present, FURBOT is installed with minimal sensors. However, after the upgrading of the vehicle takes place for autonomous driving, the increase in mass is expected to be roughly 200 kg or less.
At this moment, the mass of auxiliary components and computational hardware cannot be calculated, thus no exact figure can be given for these components which are already installed in FURBOT.
The auxiliary components whose mass is not included in the overall breakdown of the mass of FURBOT are as under: • Hydraulic services • Suspensions • Active braking • Control hardware • Seating and wiring It is estimated that the overall mass of these components makes up about 110 kg of the vehicle's mass.

Current Features of FURBOT
The vehicle is currently a full drive-by-wire vehicle. The highlighted features of FURBOT are discussed below: • Adaptive speed control • Emergency braking (pure electrical): The hydraulic braking available is on front wheels only with a single line circuit. The pump is automotive standard but using only one piston line: no crossed braking circuit. Electrical braking on rear wheels is through the traction motors. The presence of the gearboxes makes maximum braking torque above the minimum requirement for the overall N1 vehicle category, but with control or electrical fail this reduces to a viscous braking torque lower than the requirement and not controllable. • Joystick for steering, i.e., no steering wheel attached: the by-wire steering system works for a prototype, but it does not have the features of an automotive standard bywire setup. It has no hardware redundancy and the software and method of operation are not certified for by-wire driving in road condition. Doing this certification is not workable without a major restructuring of the HW and SW. For certification, the joystick needs to be replaced with the steering wheel. • Hydraulic-based controls of suspension and forklift: They are not involved in vehicle homologation and classification. • Driver assistance: It is not involved in vehicle homologation and classification.
• Pedal and joystick-based braking: The pedal is the hardware on the braking pump, with the limitations exposed above concerning homologation; the stick is by-wire operating on the electric motors, again with the limitations explained above.

Work Progress for Automation
Continuous efforts are placed for the upgrading of FURBOT so it can perform all tasks autonomously for successful contribution and complete all UCs (Use Cases) associated with it. A brief description of how proceedings are moving forward with FURBOT per requirements is provided below.

Current Achievements
Considerable developments were done in the first six months of the upgrading project for FURBOT. The tasks carried out are detailed below.

•
In the technical domain, mathematical modeling for FURBOT is carried out devising obstacle avoidance techniques/strategies [32,33]. Further explanation of this work is given in Section 3.1. The multi-body model is also created for performance evaluation to analyze extreme cases [34]. • Identification of shortcomings in terms of sensors required and upgrading needed is carried out. • Identification of issues concerning freight approach and autonomous drive within an urban environment are highlighted. Strategies on how to tackle the respective issues are formalized. Furthermore, the hardware of forklifts is also upgraded [35]. • Development of a plan for upgrading is carried out where hardware and software requirements for the vehicle are completed.

Mathematical Modeling and Obstacle Avoidance
Mathematical model of the vehicle was developed as part of development of its digital twin for critical analysis [32]. The longitudinal equation of motion used and developed is given in Equation (1).v Newton-Euler equations of motions used for vehicle lateral model are further given in Equations (2) and (3). The development, expansion and annotations of these equations are presented in [32].
To control the vehicle, three different PID controllers are developed for traction power control, braking power control and steering control [33]. The values of the respective controllers are given in Table 3. Using the mathematical model, obstacle avoidance techniques are developed using mainly velocity control [33]. Using velocity control, the velocity of the vehicle is adjusted whenever interacting with obstacles. A reference of how velocity of the vehicle is adjusted when facing an obstacle is shown in Figure 7. The complete workflow can be found in [33].

Future Goals
The future/upcoming goals for FURBOT are list below.
• Initialize the upgrading process, including software upgrading of the vehicle • Incorporate relevant sensors for autonomous driving and autonomous handling of freight, including relevant sensors for identification of freight • Strategies for freight approach and cargo loading are being visualized and simulations are to be developed for the collection of freight, navigation to the drop-off location and drop-off of freight The way forward towards these goals are further discussed in Section 6.

Technical Classification for Vehicle
Currently, there are no existing legal basis for the autonomous freight vehicle operation in a real traffic environment in Europe. The best way to legalize the freight vehicle is to categorize it into one of the already approved categories of EU vehicle definitions. Among the many approved vehicle categories available, FURBOT can be considered in two categories according to its size, weight and type. These two categories of EU vehicle definitions and the issues governing in opting for them are further discussed below 1.
L7E-CU: L7E vehicle is a vehicle with four wheels, whose unladen mass is not over 400 kg (550 kg for vehicles intended for carrying goods), not including the mass of batteries with electric vehicles and whose maximum continuous rated power does not exceed 15 kW. Category L7E-CU is a sub-category that is a heavy Quadri-mobile for utility (utility vehicle only designed for the carriage of goods).
2. N1-1: N1 vehicle is designed for the carriage of goods and having a maximum mass not exceeding 3.5 t. N1 vehicles are further classified into three sub-classes, which are discussed in their respective subsections.

L7E-CU
L7E-CU is defined as a Heavy Quadri-mobile for utility purposes. Further details for this classification of the vehicle are taken from [36] and are given in Table 4. An equivalent loading bed area as defined above designed to install machines and/or equipment and 3.
Designed with a loading bed area which is separated by a rigid partition from the area reserved for the vehicle occupants 4.
The loading bed area shall be able to carry a minimum volume represented by a 600 mm cube Maximum two non-straddle seats, including the seating position for the driver.
Some other technical aspects of L7E-CU as taken from [37] are given in Table 5. According to the classification of L7E-CU, FURBOT falls well within this category except for its overall weight, i.e., 1300 kg excluding batteries, cargo and passenger, which is 700 kg more than the designed limit of 600 kg. The excess weight reduces to 500 kg if considering the forks as part of the cargo; further reduction could be achieved with the redesign of structural parts of the vehicle, but it would be better to rebuild the entire vehicle if weight limitation criteria have to be met. Apart from weight issues, the vehicle falls well within the limits of the L7E-CU category.
Another consideration in terms of safety is that, as FURBOT is a prototype vehicle, it cannot take part in impact testing, which is usually necessary for vehicles for granting minimum road safety. However, L7E category vehicles were exempted from impact test criteria [37], thus FURBOT might qualify for safety in impact testing.

N1-1
As mentioned above, N1 category vehicles are those which are designed for carrying goods and have a maximum mass of 3.5 t. There are three sub-classes of N1 type vehicle which are given in Table 6 and are taken from [38]. The classes are based on reference mass, which is defined as the mass of the vehicle in running order, less the mass of the driver. Further details on N1 type vehicles can be found in [39]. Apart from impact testing requirements, which cannot be managed for FURBOT as it is a prototype vehicle, there are no other requirements that FURBOT does not fall in.

Possible Licensing Issues
The major hurdle which is foreseen for licensing for the vehicle in the category of L7E-CU is: • Overweight issue of the vehicle For licensing the vehicle under the N1 category, hurdles are: • Absence of steering wheel • No impact testing possible as it is a prototype vehicle

Foreseeable Issues
As FURBOT is expected to operate at late night or early morning, some concerns regarding the demo area are highlighted.

1.
Illegally parked cars: Vehicles that will be parked illegally in the demo area might become an obstacle for FURBOT, which can require additional help during the drive.

2.
Expected U-turn: The vehicle should have enough room to make a U-turn maneuver efficiently for a return route at a designated area. The demo area should thus be equipped with such a spot. It is preferable if the vehicle is not required to cross busy roads for U-turn rather stays within the dedicated lane.

3.
Freight placement for designated shops: While placing the freight at the designated stores/clients, vehicle needs to be sure that the area where the freight is being placed is clear from any obstacles or human interference. As the freight needs to be laterally extruded from the vehicle, it must not hit any obstacle. A supervised drop-off of the freight might solve this issue, otherwise appropriate sensors need to be placed which can take an automated decision on freight placement.

4.
Empty pallet collection: A strategy for the collection of empty pallets by the vehicle also needs to be planned. Empty freight collection has almost the same concerns as the freight placement as the forklift has to be laterally displaced from the vehicle to collect the empty pallets from the collection points.

Upgrading of Vehicle (Requirements and Expectations)
Work on the upgrading of FURBOT has already started in terms of automation requirements. For this purpose, necessary sensors are being identified and shortlisted for purchase. The guideline for the required sensors is taken from the Apollo Auto hardware installation guide [40] and further modified keeping in view the vehicle. The initial identification of sensors has placed the requirements of the following sensors for the vehicle: 1.
3D LiDAR at the top (for 360 • view of the surrounding) 2.
Three Leopard Cameras with respective lens and trigger cables [41] (for traffic light detection and freight handling) 3.
Two single plane LiDARs (front and rear) 4.
To RADARs (front and rear)

5.
Industrial computer (for processing of sensor data) 6.
LTE/5G modem (for data communication between vehicle and remote user) 7.
Medium-range RFID readers (for freight recognition) It is expected to upgrade the vehicle software and hardware architecture for its complete autonomy.

Resolution of 3D LiDAR Purchase/Placement/Quantity Issues
3D LiDAR is one of the most expensive sensors that is being purchased for the vehicle. As the vehicle is unconventional compared to typical Apollo Auto vehicle [40], typical Apollo Auto conventions cannot be followed. For considerations, three 3D LiDARs have been shortlisted keeping in mind the cost, availability and compatibility with Apollo software [42][43][44]. The specifications which are affecting the decision of the LiDAR are mentioned in Table 7. As shown in the figures in Section 2 and Table 2, FURBOT has a box shape figure and thus looking down from the mid-top of the vehicle through 3D LiDAR is very difficult. In that respect, the most crucial aspect for consideration is the negative values of the vertical field of view for each LiDAR. Since Velodyne PUCK is not better than HESAI PANDARXT in price or vertical FOV, it is not further considered. The primary advantage of choosing Ultra PUCK over PANDARXT is the better vertical FOV values. While placing Hesai PANDARXT on top middle of the vehicle and trying to yield the maximum field of view, the LiDAR has to be placed almost 0.5 m above the vehicle, as shown in Figure 8. This shows that, although Ultra PUCK is better than PANDARXT, we cannot use the additional vertical field of view as 0.5 m above the vehicle is already out of bounds for placing 3D LiDAR stably. The above insight into placement and type of LiDAR puts Hesai PANDARXT as an optimum option under given constraints. However, even choosing PANDARXT does not solve the problem of 7 m undetectable shadow in front of and behind the vehicle (Figure 8). To solve this issue, inspiration is taken from a similar structure autonomous vehicle Olli [45]. Because of the type of structure Olli and FURBOT has, it is better to place two LiDARs, as shown in Figure 9. Having the above configuration for FURBOT gives sturdier placement for LiDARs and decreases the blind spots for LiDAR detection. This configuration does however come with a drawback that it increases the cost of installation as the need is increased from one 3D LiDAR to two. However, selection of economical LiDAR gives us advantage to go ahead with this configuration. The remaining blind spots are further removed by placing single plane LiDARs and RADARs at the front and back of the vehicle (same configuration as Olli [45]).

Requirements
The vehicle is expected to navigate in an urban environment at low speed, i.e., 15 km h −1 , in a dedicated lane for the autonomous vehicles. Although the lane for autonomous vehicles is dedicated, it is also a lane for cyclists, and people are expected to cross the lane. Figure 10 shows the expected lane in the demonstration area where the vehicle is expected to navigate with autonomy, addressing few hurdles within its path. Figure 11 presents the clear setting of the demonstration area and the environment. Currently, the vehicle operates with Level 3 automation. However; it is expected that the vehicle needs to be upgraded to Level 4 automation (according to SAE J3016 standards [47]) during pre-demo and full demo. The vehicle is expected to demonstrate TRL (technology readiness level) 6 for pre-demo and 7 for a full demonstration. Table 8 further summarizes the automation/performance level required for real life demonstration.  In terms of connectivity, two service areas are proposed. The first service area will be covered by 5G/4G, whereas the second service area will be covered by a proprietary fiber-optic network. The infrastructure availability for FURBOT is still uncertain and will depend on the service area where autonomy demonstration is required.The proprietary fiber-optic network availability and its use is only considered if a major client is in an area which is not covered by 5G/4G network.

Use Cases for Demonstration Site
The vehicle is expected to cover five use cases. For successfully demonstrating the autonomy of the vehicle, these use cases have to be performed. The use cases are further enumerated below:

1.
Autonomous cargo vehicle operation in real urban pedestrian city-center environment 2.
Autonomous cargo vehicle operation and parking in real urban pedestrian city-center environment 3.
Autonomous cargo vehicle operation, smooth braking and immobilization in real urban pedestrian city-center environment 4. This is combined with Use Case 2, as part of the routes will be performed in mixed lanes with other vehicles 5.
Autonomous cargo vehicle remote monitoring and emergency braking for immobilization mechanism via the connection with the remote control center The flow of Use Case 3 combined with Use Case 5 is enumerated below to understand the demonstration requirement better: 1.
The FURBOT vehicle load is packaged in freights boxes with the help of the operator.

2.
The safety driver on board monitors the vehicle's route.

3.
The FURBOT follows its pre-defined route and stops at the fixed location in order to unload part of its cargo.

4.
The vehicle parks safely autonomously.

5.
The local business stakeholder picks up the load via the robotized freight boxes. 6.
The vehicle continues its route, but a pedestrian is crossing the road. 7.
The vehicle detects the pedestrian, adjusts its speed and stops smoothly.

8.
The safety person on board also activates the emergency brake. 9.
After the pedestrian moves and the road is unblocked, the vehicle continues its route towards every delivery location until all the goods are delivered. 10. The vehicle parks at the depot area.

Software Requirements
Many software architectures are available for autonomous vehicles to interface the hardware with the software. Some software architectures available for engineers are given in [48]. Under the current software architecture developments, autonomous vehicle software architectures are under constant scrutiny from a security perspective [49] and few security concerns are repeatedly highlighted [50,51]. Choosing the right software architecture can be an arduous task for an autonomous vehicle designer. The considerations for our team before selecting the software architecture for FURBOT were that the software should be: Have a proven track record in the industry Considering the above requirements, Apollo Auto fulfills our requirements, and it is considered as the "Android for autonomous vehicles" [52]. It has intelligent components such as perception, simulation, planning and intelligent control [52]. These features help in developing the interface with vehicle's hardware and thus achieving autonomous navigation. Since FURBOT is a freight vehicle and the autonomous freight handling part has to be developed, it is imperative that the selection of our software architecture is programmable and open sourced so that changes in the software could be easily implementable.
Considering factors highlighted above, it is thus decided to interface the entire vehicle through Apollo Auto for autonomous and remote controlling for the vehicle. Moreover, the vehicle needs to have a remote control for the vehicle besides on-board autonomous control.
The latest launch of Apollo is Apollo 5.0. Apollo 5.0 ushers in a brand-new data pipeline service with per-vehicle calibration options, along with spruced-up prediction evaluators and map data verification tools [53]. The highlights are Open Space Planner and improved support for parking and intersections, including stop signs and traffic lights and those without signage. Finally, Dreamland, Apollo's web-based simulation platform for model validation and testing, has been updated with a more robust scenario editor and control-in-the-loop simulation [53].
Already many auto companies are on board with Apollo Auto to integrate it with their autonomous vehicles. Toyota Motor already signed on to the Apollo self-driving platform led by Baidu. Toyota will be the second Japanese automaker to take part, following Honda Motor [54].
Not content to let Toyota be the only tech giant to get their hands on Apollo, Geelythe company that owns both Volvo and Lotus-will also work with Baidu, but it will be less focused on self-driving hardware and more focused on artificial intelligence [55]. Presently, Apollo has dozens of partner companies, including plenty of Chinese domestic companies as well as global companies such as Honda, BMW, Daimler, Volkswagen, Intel and Nvidia. The project was started in 2017 and is already in its fifth iteration with plans to reach full autonomy by 2021 [55].
Interfacing of the entire vehicle simultaneously with Apollo Auto is also essential in the development of the autonomous vehicle. All sensors should be able to interface with Apollo Auto for seamless automation of the vehicle. Integration and interfacing with Apollo Auto are also essential for off-line testing of the vehicle.

Hardware Identification and Installation
Hardware installation is required for the overall upgrading of FURBOT for autonomous navigation and freight handling in an urban environment. Among the major hardware changes which are requested are the integration of new sensors, connecting and interfacing the installed sensors with MC and establishing the connection with Apollo Auto.
Apart from new sensor requirements, their integration with MC is also essential. The cable/connectors requirements also need to be identified. In short, the transmission of sensor output data to MC whether wired or wireless needs to be identified.

Operative Modes of the Vehicle
There are mainly two operative modes for the vehicle: "fork mode" for freight handling and normal mode for vehicle navigation. When "fork mode" is activated, the vehicle cannot drive. Thus, the exact identification of freight must be performed before fork mode is started. The two operative modes, i.e., autonomous urban navigation and autonomous freight handling, are further discussed in their respective sections below.

1.
Autonomous urban navigation: Within this mode, the vehicle is supposed to navigate within the urban environment with the help of newly installed sensors in all weather and light conditions, i.e., in daylight and nighttime. It is also supposed to identify obstacles within its path and avoid them during its urban navigation.

2.
Autonomous freight handling: For autonomous freight handling, the vehicle is expected to autonomously load the pallet (freight) at the loading bay and then deliver it to the expected shop in an urban setting through autonomous urban navigation. Afterward, it should deliver the pallet, collect the empty pallet and then return to the loading bay. For the vehicle to perform this task seamlessly, the vehicle is expected to: • Approach the pallet using GNSS, RFID and LiDARs autonomously in the loading bay • Collect the pallet by parking right next to the pallet and initiating fork mode for collection • Deliver the freight at designated undocking location, mainly with the GNSS location of the designated shop • Collect the empty pallet at the designated shop using GNSS, RFID and LiDARs same way as in the loading bay • Unload the empty pallet at the designated location in the loading bay The process is further explained in Figure 12.

Expectations
The automation of FURBOT needs to fulfill additional expectations than just the automation requirements set forth. Among the expectations, the expectations at pre-demo and full demo are important besides the performance expectations and the timelines associated with them.

Demonstration expectations
The demonstration requirements are summarized in Table 8. The next is for full functionality for full demo for six months to two years, servicing the transport of goods within an urban environment continuously within the next four years. The expectations for the pre-demo are listed below: The journey for FURBOT is expected in the following way: Freight loading at loading bay → Delivery of freight at designated shop → Collection of empty pallets from shops → Return journey planning and Return to the loading bay.

Recommendations
Future goals for amalgamation of the vehicle are mentioned in Section 3.2. However, few recommendations are highlighted on licensing and hardware/software upgrading for further research.

•
As the driver-less era is approaching, it is crucial that proper regulations (in this case, EU regulations) should be developed for the driver-less vehicles to operate on road for them to qualify for medical/comprehensive insurance from insurance providers. • Targeted designing of the vehicle in a pre-existing vehicle category can lead to much ease when bringing the autonomous vehicle on the road. Addressing the legal requirements for autonomous vehicles is much easier if the vehicle is pre-tailored, keeping in mind a specific category of the vehicle. • Hardware and software identification for the vehicle autonomy is crucial and thus the highlight of our research. However, there is no single solution or a specific path to take in order to make the vehicle completely autonomous. There is no specific guideline available to resolve this issue, thus the need for our work. However, further contributions such as these can help set a standard procedure for vehicle autonomy upgrading. • Hardware/software upgrading for autonomy can be very expensive, especially due to the need of expensive sensors and expensive off-the-shelf software. Thus, sensor identification and budgeting should be a prime consideration during autonomy upgrading.

Conclusions
We highlight and address several issues for FURBOT to complete its transition from a drive-by-wire electric vehicle to a fully autonomous one. The research focus is to address the issues concerning licensing and autonomy of the vehicle.
For licensing, the weight difference is enormous for the vehicle to qualify for the category of L7E-CU. The vehicle is overweight for this category, and shedding some weight will not solve the issue. However, qualifying the vehicle for the N1 category seems very promising. The only hurdle which needs to be addressed is the incorporation of a steering wheel instead of joystick, which is viable. Second, for crash testing, as the vehicle is a prototype and very expensive, it is not possible to do crash testing. However, to resolve this issue, it is possible to do simulated crash testing in structural analysis software. Structural analysis in software for crash testing is now becoming increasingly common [56]. Thus, after considering all the factors, it is decided for FURBOT to gain the license in compliance with the N1 category by installing a steering wheel and doing structural analysis for crash testing.
Further conclusive results of our study showed the relevant hardware changes FUR-BOT must go through to change from a drive-by-wire vehicle to an autonomous one. For that, incorporating new sensors is of high importance. The identification of the right 3D LiDAR with the presence of single plane LiDARs and Radars will be sufficient for the vehicle to perform autonomous navigation. The identification and finalization of software architecture are also of prime importance, and Apollo architecture serves as an ideal platform.
We identify and highlight foreseeable issues that will help us in our path forward. Additionally, we critically analyze how we need to show autonomy, highlighting our strategy and constraints.
Few issues which are envisioned during the implementation phase of the whole hardware/software upgrade are that we stripped the top 3D LiDAR from 128 L (as recommended by Apollo [40]) to 32 L. This means lower resolution with fewer data points for the perception module to detect shapes on the road. However, this was countered with front and back single plane LiDAR/radar for better perception. According to the manual of Apollo Auto, the backward motion is not developed for autonomous vehicles, which is a very crucial problem for parking for freight vehicle in the constrained urban environment. To resolve this issue, a new module has to be designed and incorporated into the system, which is cumbersome to do for off-the-shelf software. Resolution of these additional issues will have a direct impact on the budgeting of the project, as the manpower requirement for the project will considerably increase.
Changing the environment for the vehicle operations (i.e., city/country) can increase the number of requirements for the vehicle to be operational. Currently, the vehicle is envisaged to operate in a dedicated lane where authorization of other vehicles to operate is restricted (only autonomous vehicles are allowed). Thus, the vehicle is only expected to encounter person or cycles. Putting the vehicle in a lane which also occupies other (manual) vehicles will require additional work on modules built for autonomous navigation. Changing countries for vehicle operations can also bring in additional legislative requirements that vary from country to country. This can lead to delays in vehicle freight delivery application.

Conflicts of Interest:
The authors declare no conflict of interest. The funders had no role in the design of the study; in the collection, analyses, or interpretation of data; in the writing of the manuscript, or in the decision to publish the results.