1 Introduction

A study on parking by Cookson and Pishue (2017) shows that motor vehicle drivers in Germany spent an average of 41 h a year trying to find a parking space. The extra time spent looking for a parking space results in additional fuel consumption, which in turn leads to increased emissions and costs. As a result, German drivers lose an average of 896 euros a year. However, focused on big cities the values are higher, e.g. for New York City where the average driver spends 107 h a year searching for a parking lot.

Smart automated parking systems can already completely relieve the driver of the search for a parking space with certain vehicles in selected parking facilities. The problem here is the limited accessibility of this technology because vehicles and parking facilities have to be equipped accordingly. This is because many of the systems known today use sensors within the parking facility in addition to the sensors in the vehicle. Current vehicles already have the necessary sensors. For parking operators, however, this usually results in high costs because the corresponding sensor technology must be integrated into the parking facility, which is why many parking operators ultimately decide against implementing such a system in their parking facilities.

The objective of the paper is to present a lean AVPS system architecture, which builds on the vehicle’s onboard sensors. Such an approach will reduce the necessary investments to the parking facility. Therefore, state-of-the-art Automated Valet Parking Systems (AVPS) are analyzed in the beginning. Based on current implementations, the requirements for an AVPS with minimal extension of the parking facility will be investigated. In this context, the question of how vehicles and parking facilities must be equipped at least to develop such an AVPS will be answered. The main contribution of this research is the presentation of simulation results of a lean AVPS system architecture that uses a minimal set of sensors.

2 Related Work

When implementing an AVPS, there are two ways of obtaining the needed information. On the one hand, data from the vehicle's sensors can be used to move the vehicle safely to the parking space. For example, built-in radars, ultrasonic sensors, LiDAR sensors or cameras can be used for this purpose. On the other hand, infrastructure-based technologies can be used to provide additional information on the environment. Examples of such information are the availability of free parking spaces or a detailed map of the parking facility (Möller & Haas, 2019). Infrastructure-based technologies can be further divided into sensors in or above the roadway (Eiza et al., 2020). By communicating with the parking facility, the vehicle can process the received data in a further step to plan a suitable trajectory and park the vehicle safely (Möller & Haas, 2019).

AVPS require a designated driver to leave the vehicle at defined locations in front of the parking lot, also called drop-off zones, and initiate the parking process (Möller & Haas, 2019). If the user wants to leave the parking area afterwards, he starts the pick-up process, whereupon the vehicle drives to the so-called pick-up zone, where the user can finally get in and drive off.

AVPS bring two decisive advantages. Firstly, the driver is relieved of the stressful search for a parking space. This includes, for example, maneuvering the vehicle through tight curves and ramps in parking houses or the long search for the parked vehicle in large parking areas. On the other hand, the infrastructure can be used much more efficiently by using AVPS. This mainly concerns the parking lot size as well as the number of available parking lots. An efficient use of these parameters has been highly limited by the inhomogeneity of the drivers' abilities to park manually (Isermann, 2018). It would also be conceivable in the future to combine a corresponding charging service for e-vehicles, optimally with wireless charging, or the possibility of a car wash with automated parking, where the car first drives autonomously to a charging station or a car wash before the vehicle subsequently parks autonomously. Another scenario considers that the parking operator can re-park the parked vehicles at will. This makes it much easier e.g. to clean parking houses or to park the vehicles on a high density to fit even more cars into parking facilities.

There are countless examples and designs of AVPS. The final implementation of these systems varies greatly. The parking lot identification alone can already be divided into four categories as shown by Suhr and Jung (2023). The decisive factor here is the question of what sensor data is available to the vehicle for implementing the AVPS. While the industry relies on a combination of data from in-vehicle sensors and infrastructure-based technologies to enable AVPS today in a mixed traffic manner, various research studies provide alternative approaches. Jeong et al. (2016) focus on the parking algorithm with the assumption that a map of the parking facility is provided by the infrastructure. Qin et al. (2020) address the localization of the vehicle in parking facilities without GNSS coverage. Here, the vehicle autonomously creates a map of the parking facility using a SLAM algorithm and detects available parking spaces with an integrated camera system.

In Table 1, three different approaches are examined in more detail. The focus is primarily on the general functionality of the systems and the sensor technology used for this purpose, to be able to evaluate the respective benefits of different on- and offboard sensors. First, the extensively developed AVPS with smart infrastructure of the Robert Bosch GmbH in cooperation with the Mercedes-Benz Group AG on two locations (Bosch, 2019, 2020) is considered to present an example of the first commercial use of future autonomous parking. Next, the Autonomous Valet Parking project by Parkopedia, the University of Surrey and Connected Places Catapult (avp-project, 2020) are examined in more detail. This implementation uses artificial visual landmarks for localization within the parking facility, thus requires some adaptions of the parking facility. In contrast, an AVPS describing a minimal system architecture is examined next (Chirca et al., 2015). Here, the approach is limited to the use of low-cost in-vehicle sensors and using them as efficiently as possible. Finally, the table shows the advantages and disadvantages of each approach (see Table 1).

Table 1 Used sensors including pros and cons of previously mentioned approaches for implementing an AVPS
Full size table

3 System Design

Based on the information gained by examining various approaches of developing an AVPS, the requirements analysis for the system must first be considered. The requirements are used in the next step to map them to functionalities of the system, which are represented using comprehensive state diagrams. The subsequent technical system design ultimately describes the realization of the system using a comprehensive figure for the system architecture as an example. This is followed by a hazard analysis to identify and evaluate potential risks to derive risk reduction measures.

3.1 Requirements Engineering

Common process models for software development show that the development of a system starts with the definition of its requirements. The requirements analysis considers the quality criteria and the specifications from ISO/IEC/IEEE 29148:2018 (ISO, 2018a) and is based on the defined requirements of the AVPS of Parkopedia by Hassanaly (2019a). In addition, requirements are derived from the ISO 20900 standard (ISO, 2019), which defines minimum requirements for the functionality of partially automated parking systems. Moreover, the system is designed to meet the requirements for AVPS defined by the German Federal Motor Transport Authority (ger. Kraftfahrt-Bundesamt, KBA) (KBA, 2022). This is necessary if one wants to develop a system with the goal of approval in German parking facilities. For this purpose, a requirements description is first defined. This is followed by the stakeholder analysis to investigate which interest groups can place requirements on the system. The subdivision of the overall system into subsystems and modules completes the examination of the requirements. Finally, the requirements are defined using the information obtained from this overall analysis. Relevant stakeholders for the system were determined to be developers, car manufacturers, users and parking operators. For a comprehensive analysis of the requirements, the overall AVPS is divided into two subsystems (vehicle and parking facility) and in total five modules as indicated in Fig. 1.

Fig. 1
figure 1

Breakdown of the overall AVPS

Full size image

The first subsystem is the vehicle. For the vehicle to be operated in an automated manner, it must be equipped with a so-called autonomous driving stack (AD stack). More specifically, the vehicle must be able to always locate itself, sense its surroundings, plan a trajectory, and follow it accordingly by controlling the vehicle’s motion.

Therefore, the vehicle subsystem consists of four modules as follows:

(i) Localization which estimates the actual position of the vehicle using different algorithms based on e.g. maps, or GNSS approaches, (ii) perception which observes the car’s surrounding with corresponding sensor technologies for short and long distances to the vehicle, (iii) planning which uses information from localization and perception to define a suitable trajectory according to the used algorithm e.g. A*, (iv) control which calculates the output values (e.g. steering angle) for the actuators to keep the vehicle on the planned trajectory using the information from all the previously mentioned modules.

The parking facility subsystem contains the module (v) map which includes valuable information about the parking facility e.g. a coordinate system to calculate distances or cost information to assess the best trajectory among a variety of paths. Additionally, the map needs to contain so-called semantic information about the infrastructure (e.g. lane width, lane direction, traffic signs) so the car knows about lane sizes, lane orientations as well as traffic rules.

The only module of the parking facility is a map which is to be sent to the vehicle via wireless communication. It contains information for the localization of the vehicle and planning of the trajectory. Thereby the vehicle gets everything it needs to navigate autonomously through the parking facility. In this case, the technology used for the communication between the vehicle and the infrastructure can be freely selected, provided it meets the safety requirements of the previous mentioned technical catalogue of requirements for AVPS (KBA, 2022) regarding the implemented cyber security management system. Furthermore, wireless communication can be used to coordinate the requests of multiple vehicles to ensure that no parking lot is approached by more than one car. The prioritization of the vehicles can be done according to the “first come first serve” principle in combination with other criteria such as the distance to the target vehicle. In the context of this work, the data transmission is not being considered. Therefore, it is assumed that the vehicle has already received the map. In that way, a proof of concept of the proposed architecture can be shown. Further work will investigate which technology can be used to transfer the map of the parking facility.

3.2 Functionality and System Architecture

In the following, diagrams are presented to obtain a holistic understanding of the structure and functionality of the defined AVPS. State diagrams are used to illustrate the functionality. Here, the diagrams of the processes of entering and leaving a parking facility are defined and explained. Next, a system architecture is derived, which contains the required hardware and software modules including their interconnections.

3.2.1 State Diagrams

Basically, the overall process can be divided into two subprocesses. These subprocesses will henceforth be referred to as AVPS drop-off and AVPS pick-up. In the following, both subprocesses are represented by a state diagram and explained in detail. Figure 2 shows the state diagram of AVPS drop-off.

Fig. 2
figure 2

State diagram of subprocess AVPS drop-off

Full size image

Its states are explained in detail as follows:

System initialized: When the user wants to start the parking process, the system first of all checks whether all conditions for a correct activation of the parking process are met and prepares itself accordingly. To do this, it first checks whether the system is operational. If the availability of the internal sensors and actuators has been confirmed, the next step is to establish the network connection to the parking facility. If the connection could be established within a certain number of attempts, the final step is to verify the position of the vehicle, assuming that the vehicle has received an appropriate map of the parking facility. As the vehicle is at the drop-off zone, its position is verified. If the connection to the infrastructure could not be established or the vehicle has not received the corresponding map, the AVPS can’t be used, and the driver must park the car manually.

Planned route guidance to the parking lot: Once the system has been successfully initialized, the next step is to plan the route guidance to a given parking lot. To do this, a free parking space is first selected. If the parking facility is not fully occupied, the selected parking space is then reserved. For this, the vehicle must receive a confirmation of the reservation from the parking facility to plan the route. As the last step of this state, the user must confirm that the automated route guidance can now be initiated. This makes sure that the driver and passengers have left the car accordingly.

Started route guidance to the parking lot: If the route guidance was started successfully, the actual driving to the parking lot begins. If the system detects an object on the route, it searches for an alternative route. If an alternative route is available, it will be calculated, and the route guidance will go on according to the new route. Before going into the next state, the reserved parking space must also be verified. This includes checking the size of the parking space on the one hand and checking for objects in the parking space on the other. If the parking space has been successfully verified, the next state called parking started can be carried out. Otherwise, the system must plan a new route to another suitable parking lot.

Parking started: When this state is started, the parking route is first calculated. If the route can be planned, the next step of this state is to guide the vehicle into the free parking lot.

System abort started: This state is only to clarify that possible errors are to be considered and caught. However, this is not to be further investigated in the following.

The process AVPS pick-up shown in Fig. 3 is very similar to the previous state diagram and its states can generally be described as follows:

Fig. 3
figure 3

State diagram of process AVPS pick-up

Full size image

System initialized: Again, the system must first be initialized. The initialization is basically exactly the same as in the previous process with two key differences. First of all, the vehicle must be started. Next, the vehicle position is verified by comparing it with the position of the parking space.

Planned route guidance to the pick-up zone: At first the system must make a request to enter the pick-up zone. If the pick-up zone is occupied, the system is set into a waiting state where it is placed at the end of an appropriate queue. If the system receives permission to enter the pick-up zone, the pick-up zone is reserved and the route to it can be planned.

Started route guidance to the pick-up zone: This diagram corresponds exactly to the route guidance to the parking lot in the previous state diagram.

System abort started: Again, this state is only mentioned due to reasons of completeness and should not be examined further.

3.2.2 System Architecture

Now that the functionality of the AVPS has been defined, the next step is to investigate which hardware and software components could be used to implement the described functions in concrete terms. For this purpose, a system architecture was developed which, in addition to the sensors and actuators to be used, also describes necessary software modules and the interrelationships between all components of the architecture (see Fig. 4).

Fig. 4
figure 4

System architecture of the AVPS

Full size image

The system architecture is presented as a simple IPO (input-process-output) model to clearly show the chain of effects between the modules.

Input: The input can be divided into offboard and onboard components. The only necessary offboard module is the map of the parking area. This decreases necessary adaptions in the parking facility. Together with the onboard sensors, the entire input modules provide the required data for further processing in the next step. For long-range environment detection and object recognition, cameras and LiDAR sensors can be used. For short-range environment sensing and obstacle detection ultrasonic sensors around the vehicle are used. This ensures a safe parking process and effectively scans the environment for objects within a very short distance of the vehicle similarly to the production vehicles. To localize the vehicle one can use GNSS (when the satellite signal is available) and/or LiDAR or camera. In parking houses and similar facilities where the GNSS satellite signal is not available, the vehicle’s exact location is calculated based on LiDAR using 3D point cloud maps as implemented e.g. in Autoware (Kato et al., 2018), or cameras using natural landmarks. The project described in avp-project (2020) is using cameras based on artificial landmarks in the form of QR-Codes. These artificial landmarks can also be seen on the walls of the parking house at the Technische Hochschule Ingolstadt (see Fig. 5).

Fig. 5
figure 5

Parking house used for testing automated parking systems at the Technische Hochschule Ingolstadt

Full size image

Processing: To process the available data accordingly the used AD stack needs to provide at least four modules to ensure safe vehicle guidance. The data from the input is first processed in the environment detection to observe surrounding objects and recognize hazards at an early stage. By combining the results from the sensors and the localization of the vehicle, the route can be planned next and finally the vehicle can be controlled on the planned route.

Output: The most important component within the output is the drive-by-wire system, which is needed for the longitudinal and lateral guidance of the vehicle. The driveline serves as an output module, since it must be deactivated or activated at the end of the parking process and when the pick-up process is started.

3.3 Hazard Analysis and Risk Assessment

The ADAS Code of Practice (CoP) (Knapp et al., 2009) supports the specification and evaluation of driver assistance systems throughout the development process. The focus is primarily on risk identification and assessment as well as the analysis of the controllability by the driver. From this, it can be derived in the next step which measures are necessary to minimize the risk to an acceptable level. The product safety disciplines to be considered in the course of this investigation are the functional safety and the safety of the intended functionality. In the following, the hazard analysis and risk assessment will be performed according to the ADAS CoP. This is done by taking the ISO 26262–3 (ISO, 2018a, 2018b) and the ISO 21448 (ISO, 2022) into account. In this process, the results are determined and recorded using a failure mode and effects analysis (FMEA). The FMEA is performed according to the analysis techniques and procedures described in IEC (2018) and is based on the results of the FMEA of the AVPS from Parkopedia (Hassanaly, 2019a, 2019b).

Failure modes can be the triggers of other failure modes at a higher level, which can result in a chain of failures and ultimately a system shutdown. For this reason, it is important to minimize the risk to all known failure modes. To this end, failure effects and causes of all failure modes were examined to determine a measure of the severity and frequency of failure modes. Based on these assessments, detection methods and failure compensation measures can be defined in the next step, which helps to minimize the risk of a failure mode. For the purpose of minimizing the risk and thus increasing the safety of the entire AVPS, the following measures were defined for the development and testing of the AVPS:

Use of a safety driver: To be able to guarantee the safety of the AVPS in physical assessment, a safety driver should be present in the vehicle at all times. In dangerous situations, where collisions with surrounding objects are imminent, the safety driver can override the automated driving function by manual intervention. However, this point is not relevant to the presented development, since the AVPS is only applied in the simulation in the context of this work. Nevertheless, this measure has been mentioned for the sake of completeness.

Reduced maximum speed: A reduced maximum speed initially reduces the extent of potential collisions. In addition, it makes it easier for the safety driver to intervene in real traffic, since the ratio between the human reaction time and the time to react before a critical situation occurs is significantly reduced. The maximum permissible speed for the automated operation is therefore 5 km/h. This was also previously specified in the requirements analysis.

No pedestrian allowed in the parking area: To reduce the probability of collisions with pedestrians in the automated operation, pedestrians must not enter the area in which the vehicle is being operated autonomously. This area should therefore be closed in some way to indicate to pedestrians that their presence in this area is not permitted. However, crosswalks should be provided in the area where the vehicle is being operated manually to allow pedestrians to cross the street. Conceivable areas for this are before the drop-off zone or after the pick-up zone. In the event that VRUs disregard the rule and still enter the prohibited area, the AVPS uses the common modules of automated driving. Accordingly, the vehicle's surroundings are always monitored, which is why the vehicle is always able to detect surrounding objects. In the case of e.g. a pedestrian in the AVP area, the system gets information from those vehicle sensors about the pedestrian and reacts accordingly based on the given situation, e.g. by an evasion maneuver or stopping until the obstacle disappears. Furthermore, for safety reasons, the vehicle speed is reduced to 5 km/h as mentioned above, which results in very small stopping distances in such unexceptional cases. For the application of the AVPS, the vehicle has a defined safety area with a radius of 3 m around the vehicle. If the car detects a pedestrian entering this safety area the vehicle will stop and wait until the pedestrian leaves the safety area again. However, if the pedestrian is not in this safety area the vehicle operates as planned.

4 Proof of Concept

This Section is used to illustrate the operation and functionality of the AVPS system architecture defined previously. For this purpose, it is first shown which components were necessary to safeguard the described system in the simulation. Next, the scenario to be used for the demonstration of the results is defined before the results are finally presented.

4.1 Description of the Experimental Setup

The following gives an overview of the used experimental setup. It starts with the description of the vehicle model of the used car including the presentation of the corresponding AD stack. Furthermore, it includes the definition and illustration of the environment model of a suitable parking facility.

4.1.1 Vehicle Model of ANTON

Figure 6 presents the research vehicle ANTON which is used for the assessment.

Fig. 6
figure 6

Explorative development platform ANTON

Full size image

ANTON uses a passively cooled, Linux-based In-Car-PC CQ70G series with additional NVIDIA GeForce GTX 1060 GPUs and 2 CAN interfaces. The CAN interfaces are used to connect all installed devices and sensors to the PC and the PC to the drive-by-wire control unit. The older generation GPU was selected because of the passive cooling concept. To gather information about its surrounding the vehicle is equipped with a 360° LiDAR sensor mounted on the roof, eight cameras around the car, one radar at the front, two GNSS-RTK antennas, one GNSS-IMU and a V2X communication unit. To enable the automated driving function, modules from the open-source software stack called Autoware.AI are used.

Autoware.AI runs with Ubuntu 18.04, is ROS 1 based and has already all the needed modules for localization and control of the car as well as perception, prediction and planning (Kato et al., 2018). Figure 7 shows an overview of Autoware.AI’s modules and components.

Fig. 7
figure 7

Overview of Autoware.AI (Kato et al., 2018)

Full size image

Autoware.AI uses LiDAR sensors for the localization of the vehicle in HD maps. The other sensors that are integrated into the vehicle complement the information sources.

For initial testing, the assessment will be taken out in the simulation environment CARLA. In de Borba et al., (2021) the process of developing and adding the ANTON vehicle model to the simulation tool (see Fig. 8) is described.

Fig. 8
figure 8

Vehicle model of ANTON in CARLA (de Borba et al., 2021)

Full size image

To control the car in the simulation environment via ROS messages the ROS bridge of CARLA has to be installed additionally.

For localization and object detection the research vehicle uses a 360° LiDAR mounted on the roof of the vehicle. Trajectory planning is done with Autoware’s Open Planner, which implements dynamic programming to find the most convenient path for a given start and goal position (Darweesh et al., 2021).

The used map for localization and trajectory planning contains a point cloud map for the localization. The used semantic map for path planning is compatible with the high-definition map framework Lanelet2 (Poggenhans et al, 2018). To follow the planned trajectory, a pure pursuit algorithm is used. Finally, the motion planning and control is carried out by Autoware’s decision maker which controls the vehicle status by implementing various state machines (Decision_maker, 2019). The Autoware.AI standard functions are extended with a vector intersection detection algorithm for the verification of the parking space based on the LiDAR sensor data.

4.1.2 Environment Model

For the development and validation of the AVPS in the simulation, an appropriately equipped parking facility is required. Accordingly, a conventional parking facility has to be extended by separate entrances and exits including corresponding drop-off and pick-up zones. During the development, it was discovered that the vehicle is not able to automatically change the driving direction. Because of that reason, the parking spaces must be arranged in such a way that it is not necessary to reverse in any situation.

The geometric map represents the physical environment in which the vehicle should be able to move in the simulation. For its development, first of all, the drivable area of the parking facility had to be created. The recommended software for creating an environmental model for use in CARLA is RoadRunner from MathWorks. Considering the requirements of the parking facility, a suitable road plan was designed. This plan has one entrance and exit each and a total of 55 parking spaces. All parking spaces have been deliberately left open from both sides. This ensures that the vehicle can enter and exit each parking space in a forward direction. Using Unreal Engine, a suitable environment was added to the street, thus finalizing the geometric map (see Fig. 9).

Fig. 9
figure 9

Geometric map of the used parking facility

Full size image

The experimental infrastructure in Fig. 9 has one drop-off zone (green X in Fig. 9) and one pick-up zone (red X in Fig. 9).

4.2 Simulation Results

The presentation of the simulation results shows the functionality of the final AVPS. For this purpose, different scenarios were tested. Middle and outer parking spaces, as well as the first and last parking spaces were used as target parking spaces. Streets were blocked, vehicles were parked at an angle, thus parking spaces communicated as free were occupied.

In the following, the simulation results of a specific scenario are presented. For this purpose, the scenario considered is first described before the results of the simulation are presented. The demonstration of the results includes the description of the parking and pick-up process, as well as challenges encountered during the simulation.

4.2.1 Scenario Definition

Before the results can be presented, the initial situation must first be clearly defined. Figure 10 shows the example scenario to be considered.

Fig. 10
figure 10

Example scenario for assessing the AVPS

Full size image

To obtain a uniform and clear description of the parking lots, they will be numbered. The number of the parking lots increases from left to right. The 1st parking lot is marked with a green arrow and the 55th parking lot with a red arrow in Fig. 10. In the presented scenario, 46 parking lots are occupied and 9 are free. The following parking lots are considered to be free: 17, 25, 36, 38, 39, 43, 47, 53 and 55. To affect the accessibility to parking lot 17, vehicles have been parked incorrectly in parking lots 16 and 18. As a result, parking lot 17 is no longer wide enough for the vehicle to park (see blue arrow in Fig. 10). The vehicle which is currently placed right at the entrance of the parking facility (see red rectangle in Fig. 10) is from now on referred to as the ego vehicle. In the following scenario, the ego vehicle will be the one equipped with the AVPS functionality. The presented scenario will be used to test both, the drop-off subprocess and the pick-up subprocess. Following results are expected:

Drop-off: The ego vehicle plans and starts the route guidance from the drop-off zone to parking lot number 17. As the desired parking lot is partially occupied, the ego vehicle requests a new parking lot and finishes the parking process at parking lot number 25.

Pick-up: The ego vehicle plans and starts the route guidance from parking lot number 25 to the pick-up zone. The process is finished when the ego vehicle reaches the pick-up zone.

4.2.2 Results of a Defined Scenario

The parking process starts with the ego vehicle in the drop-off zone (see Fig. 11).

Fig. 11
figure 11

Start of the parking process. Top: Simulation environment. Bottom: Planned trajectory and objects detected by the ego vehicle

Full size image

The ego vehicle starts the parking process as soon as the infrastructure sends the location of the next known free parking lot including a corresponding map. In the presented scenario it is parking lot number 17. The path to the parking lot is planned and the decision maker checks the planned mission to initiate the driving. The blue line in Fig. 11 shows the planned trajectory of the ego vehicle to reach the desired parking position.

Next, the ego vehicle follows the planned trajectory. When the car reaches the red rectangle shown in Fig. 11 the system verifies whether the desired parking lot is free using the onboard LiDAR. In case the parking lot is empty the vehicle continues to follow the planned trajectory and parks the car accordingly. However, if the system identifies an obstacle in the desired parking lot, the vehicle shares this information with the infrastructure and waits for a new destination. As described earlier parking lot number 17 (blue arrow in Fig. 10) is partially occupied by the adjacent vehicles. Therefore, the ego vehicle stops near the red square (see Fig. 11) and requests to get the next free parking lot. Then, the new trajectory is planned, and the vehicle follows it accordingly (see Fig. 12).

Fig. 12
figure 12

Ego vehicle scanning the currently desired parking lot. Top: Simulation environment. Bottom: Planned trajectory and objects detected by the ego vehicle

Full size image

The ego vehicle follows the planned trajectory until it reaches its goal. Eventually, the parking process is finished when the ego vehicle has parked correctly at the desired parking lot (see Fig. 13).

Fig. 13
figure 13

Final parking position

Full size image

The pick-up subprocess is comparatively uncomplicated due to the fact that the ego vehicle just needs to reach the pick-up zone. Figure 13 shows the starting position for the pick-up subprocess. From there the ego vehicle plans the trajectory to the pick-up zone (see Fig. 14).

Fig. 14
figure 14

Trajectory planning to the pick-up zone

Full size image

The ego vehicle follows the panned trajectory until it reaches the pick-up zone where the driver can get in and take over the driving of the car (see Fig. 15).

Fig. 15
figure 15

Final pick-up position

Full size image

4.2.3 Assessment of Results

Various tests have shown that this concept of an AVPS system architecture works really well. By receiving the maps of the parking facility via wireless communication the vehicle has every information needed to navigate safely through the parking facility with the onboard sensors. A final summary of the proposed AVPS system architecture shows the used sensors and emphasizes the advantages of the proposed system architecture which can be used to compare it to the already existing approaches (see Table 2).

Table 2 Summary of proposed AVPS system architecture
Full size table

5 Future Work

By and large, the planned AVPS was successfully implemented. However, there are some open points that must be addressed in future research.

In the present approach, only the LiDAR sensor was used for environmental monitoring. However, this is not optimally suited for short distances, which play a particularly important role in the parking process. To be able to use the parking area more efficiently in the next step, ultrasonic sensors are to be integrated and used in future work.

The LiDAR sensor is also currently used for localization. However, compared to other sensors, this one is relatively expensive. One could consider using cheaper and in the current vehicles already implemented sensors such as cameras for localization to further increase the accessibility to this technology. Conceivable would be the localization via artificial landmarks within the infrastructure or the use of odometry sensors. It has to be assessed how this can be implemented for future use.

Finally, it remains to mention the current problem of backward planning. The parking process is unnecessarily prolonged by the fact that the vehicle has to drive around the parking space to park appropriately after verifying that the parking space is free. In subsequent work, the open planner can either be extended, or a custom planner can be developed to implement reverse planning.

After improving and extending the proof of concept, real-world test scenarios can be carried out to assess the performance of the proposed AVPS. This will help in comparing the developed system architecture to other implementations in a more technical manner and stressing its advantages.

6 Conclusion

This paper presents a lean AVPS system architecture that mainly relies on onboard sensors. This approach reduces the necessary investments to the parking infrastructure. Within the scope of this research, a functioning AVPS was elaborated and developed. In this context, requirements for the system were determined and the system was designed functionally as well as technically. A hazard analysis helped to identify risks and to reduce them accordingly. Based on a simulated scenario, the implemented AVPS was finally demonstrated. It could be shown that an extension of the parking system with a communication unit is already sufficient to develop a correspondingly safe and functioning AVPS even though this research used only a LiDAR sensor to observe the environment. This work has laid the foundation for an AVPS with minimal additional requirements for the extension of the parking facility.

Future work will address the challenges presented. First, this relates to include an ultrasonic sensor system to get a more precise picture of surrounding objects within a short distance. Furthermore, it will be investigated how the localization can be done without the need for a LiDAR due to its high price. However, further developments should first focus on extending the AD stack to enable reverse driving. This would allow the AVPS to be tested in real research vehicle to evaluate the quality of the implemented AVPS under realistic environmental conditions.