Abstract
Automated Valet Parking Systems (AVPS) relieve the driver of the entire parking process. Many of the systems known today rely on a combination of automotive sensors with sensors of the infrastructure. For this purpose, parking facilities are equipped with comprehensive sensor technology to support the vehicles in environment sensing and route planning. This approach is comparatively expensive which is why many parking operators don’t provide that technology to their customers. This paper proposes a lean AVPS system architecture that requires minimal effort to adapt the infrastructure. At the same time, state-of-the-art vehicle technology is used to make AVPS more profitable overall. At the beginning, an overview will be given describing the state of the art of AVPS. Subsequently, requirements for the AVPS will be elaborated, whereby the system can be designed and implemented in the following. Finally, the presentation of simulation results shows that one doesn’t have to extend the infrastructure with sensors to develop a safe and reliable AVPS.
Similar content being viewed by others
Explore related subjects
Discover the latest articles, news and stories from top researchers in related subjects.Avoid common mistakes on your manuscript.
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).
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.
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.
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:
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).
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).
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.
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.
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.
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).
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.
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).
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).
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).
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).
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).
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).
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.
Data availability
The developments and findings of this research are available from the corresponding author upon reasonable request.
References
avp-project. (2020). Autonomous valet parking. https://avp-project.uk/category/uncategorized. Accessed 12 May 2023
Bosch. (2019). World first: Bosch and Daimler obtain approval for driverless parking without human supervision. https://www.bosch-presse.de/pressportal/de/en/world-first-bosch-and-daimler-obtain-approval-for-driverless-parking-without-human-supervision-194624.html. Accessed 12 May 2023
Bosch. (2020). Stuttgart airport set to welcome fully automated and driverless parking. https://www.bosch-presse.de/pressportal/de/en/press-release-219648.html. Accessed 12 May 2023
Chirca, M., Chapuis, R., & Lenain, R. (2015). Autonomous Valet Parking System Architecture. In: 2015 IEEE 18th International Conference on intelligent transportation systems 18, 2619–2624.
Cookson, G., & Pishue, B., The Impact of Parking Pain in the US, UK and Germany, INRIX Research, Report, July 2017.
Darweesh, H., Takeuchi, E., & Takeda, K. (2021). OpenPlanner 2.0: The portable open source planner for autonomous driving applications. In: 2021 IEEE Intelligent Vehicles Symposium Workshops (IV Workshops). Nagoya. 11–17 July.
de Borba, T., Patel, P. H. and Vaculín, O. (2021). Concept of a Vehicle Platform for Development and Testing of Low-Speed Automated Driving Functions. FISITA World Congress 2021. Prague. 13–17 September.
Decision_maker. (2019). Decision Maker. https://gitlab.com/autowarefoundation/autoware.ai/core_planning/blob/master/decision_maker/README.md. Accessed 12 May 2023
Eiza, M. H., Cao, Y., & Xu, L. (2020). Towards sustainable and economic smart mobility (1st ed.). World Scientific Publishing Europe Ltd.
Hassanaly, M. (2019a). Requirements Capture. Connected Places Catapult. Internal Report.
Hassanaly, M. (2019b). Failure Mode and Effect Analysis for Testing in a Controlled Car Park. Connected Places Catapult. Internal Report.
IEC. (2018). Failure modes and effects analysis (FMEA and FMECA). IEC, 60812, 2018.
Isermann, R. (2018). Fahrerassistenzsysteme 2016 (1st ed.). Springer Vieweg Wiesbaden.
ISO. (2018a). Road vehicles—Functional safety—Part 3: Concept phase. In: ISO, 26262–3, 2018.
ISO. (2018b). Systems and software engineering—Life cycle processes—Requirements engineering. In: ISO/IEC/IEEE, 29148, 2018.
ISO. (2019). Intelligent transport systems—Partially automated parking systems (PAPS)—Performance requirements and test procedures. In: ISO, 20900, 2019.
ISO. (2022). Road vehicles—Safety of the intended functionality. ISO, 21448, 2022.
Jeong, Y., Kim, S., Yi, K., Lee, S., & Jo B. (2016). Design and implementation of parking control algorithm for autonomous valet parking. SAE Technical Paper. 2016–01–0146.
Kato, S., Tokunaga, S., Maruyama, Y., Maeda, S., & Hirabayashi, M. (2018). Autoware on board: Enabling autonomous vehicles with embedded systems. ACM/IEEE International Conference on Cyber-Physical Systems, 9, 287–296.
KBA. (2022). Technical catalogue of requirements for the fully automated driving function „Automated Valet Parking (AVP)”. Technical Catalogue of Requirements.
Knapp, A., Neumann, M., Brockmann, M., Walz, R., & Winkle, T. (2009). ADAS Code of Practice. Code of Practice for the Design and Evaluation of ADAS. ACEA. Technical Report.
Möller, D. P. F., & Haas, R. E. (2019). Guide to automotive connectivity and cybersecurity (1st ed.). Springer Cham.
Poggenhans, F., Pauls, J. H., Janosovits, J., Orf, S., Naumann, M., Kuhnt, F., & Mayr, M. (2018). Lanelet2: A high-definition map framework for the future of automated driving. In: 2018 21st International Conference on intelligent transportation systems 21, 1672–1679, Maui, Hawaii, USA. 4–7 November.
Qin, T., Chen, T., Chen, Y., & Su, Q. (2020). AVP-SLAM: Semantic visual mapping and localization for autonomous vehicles in the parking lot. In: 2020 IEEE/RSJ International Conference on intelligent robots and systems (IROS).
Suhr, J. K., & Jung, H. G. (2023). Survey of target parking position designation for automatic parking systems. International Journal of Automotive Technology, 24(5), 287–303.
Acknowledgements
This research was conducted in the course of project ANTON (13FH7E03IA) which is part of the research partnership SAFIR funded by the German Federal Ministry of Education and Research.
Funding
Open Access funding enabled and organized by Projekt DEAL.
Author information
Authors and Affiliations
Corresponding author
Additional information
Publisher's Note
Springer Nature remains neutral with regard to jurisdictional claims in published maps and institutional affiliations.
Rights and permissions
Open Access This article is licensed under a Creative Commons Attribution 4.0 International License, which permits use, sharing, adaptation, distribution and reproduction in any medium or format, as long as you give appropriate credit to the original author(s) and the source, provide a link to the Creative Commons licence, and indicate if changes were made. The images or other third party material in this article are included in the article's Creative Commons licence, unless indicated otherwise in a credit line to the material. If material is not included in the article's Creative Commons licence and your intended use is not permitted by statutory regulation or exceeds the permitted use, you will need to obtain permission directly from the copyright holder. To view a copy of this licence, visit http://creativecommons.org/licenses/by/4.0/.
About this article
Cite this article
Dönmez, Ö., Vaculín, O. & de Borba, T. A Cost Effective Solution to an Automated Valet Parking System. Int.J Automot. Technol. 25, 369–380 (2024). https://doi.org/10.1007/s12239-024-00031-9
Received:
Revised:
Accepted:
Published:
Issue Date:
DOI: https://doi.org/10.1007/s12239-024-00031-9