Parking assistant, procedure and vehicle

Abstract

The invention relates to a parking assistant (1) for a vehicle for performing a parking maneuver comprising several sensors and actuators, wherein the parking assistant (1) has a parking assistant architecture (3), wherein the parking assistant architecture (3) has several subsystems which host different modules, wherein the modules access each other.

Description

[0001] The invention relates to a parking assistant for a vehicle for performing a parking maneuver, comprising several sensors and actuators, wherein the parking assistant has a parking assistant architecture comprising various modules. The invention further relates to a method and a vehicle.

[0002] Parking assistants are generally well-known and are often used as part of driver assistance systems in vehicles, especially motor vehicles. Modern parking assistants allow the vehicle to automatically park itself in various types of parking spaces, such as parallel parking spaces or perpendicular parking spaces.

[0003] DE 10 2017 217 528 A1 concerns systems for vehicle-side maneuvering along a predetermined path during parking, in which an imaging device is used to detect the wheel and its surroundings. Image processing determines parameters for the interaction between the wheel and the obstacle in order to calculate a damage indicator, which is used to control the vehicle's movement and prevent rim damage.

[0004] DE 10 2022 204 543 A1 discloses a system for automated parking along a predetermined path, in which the environment of the vehicle is captured and analyzed by means of an imaging device and image processing.

[0005] DE 10 2012 222 197 B4 describes a method for dynamic torque distribution in all-wheel drive vehicles with a parking assistance system, whereby the drive torque is distributed between the primary and secondary axles depending on the situation. In particular, when a parking situation is detected, the torque of the engageable secondary axle is selectively reduced or limited in order to optimize vehicle steering during parking.

[0006] DE 10 2008 060 684 B4 discloses a method and device for automatically parking a motor vehicle in a parking space, wherein the surroundings of the motor vehicle and possible parking spaces are determined by an environmental sensor, comprising the steps of: assigning a parking space situation to each possible parking space, wherein the parking space situation is derived from the surroundings of the parking space and wherein one or more parking space properties are determined from a parking space situation; assigning a parking parameter set to each parking space situation, wherein each parking parameter set has at least three parking parameters and the parking parameter set of a parking space is determined from its parking space properties; and excluding those parking spaces as possible parking spaces where at least one parking parameter of the parking parameter set does not match a selected parking parameter.where the selected parking parameter determines the desired parking behavior of the vehicle.

[0007] One object of the invention is to provide an improved parking assistant as well as a corresponding method and a corresponding vehicle.

[0008] The problem is solved by a parking assistant with the features of claim 1, as well as a method with the features of claim 14 and a vehicle with the features of claim 15. Advantageous further developments and embodiments of the invention are specified in the dependent claims.

[0009] The task is solved by a parking assistant for a vehicle by performing a longitudinal and lateral movement to execute a parking maneuver, wherein the parking assistant has a parking assistant architecture comprising various modules including several sensors and actuators, wherein the parking assistant architecture has: a first subsystem with an input data module for receiving and recognizing driver inputs, wherein the driver inputs include at least one activation as input to an activation input device as an activation request for activation of the parking assistant, wherein the input data module is configured to generate an activation request signal based on the received driver inputs, a third subsystem with a processing module, which is used to receive a sensor signal carrying raw sensor data in a near-field and mid-field detection range in a vehicle environment and to receive a a seventh subsystem with a management module for receiving the activation request signal, an acceleration, a velocity and a yaw rate of the vehicle, each as a signal, and wherein the management module is configured to generate an activation signal based on the signals, which causes at least the activation of various modules in a predefined sequence. an eighth subsystem comprising a restriction module which provides restrictions for driving with regard to the parking maneuver as an in-lane signal, and a restriction module for generating restrictions at least with regard to vehicle acceleration and / or speed and / or position as a restriction signal, a ninth subsystem with a maneuver tool configured to receive an absolute acceleration, an absolute yaw rate and an absolute velocity as well as a future driving scene which includes at least fully characterized detected dynamic objects in the detection horizon, as well as to receive the activation signal as well as the in-lane signal and wherein the maneuver tool is configured to check, based on the received signals, whether the parking maneuver is feasible and, if feasible, to forward the activation signal, a twelfth subsystem with a target trajectory module, which is configured at least to receive the restriction signal as well as a future driving scene, which includes at least fully characterized detected dynamic objects in the detection horizon, and the absolute speed of the vehicle, the absolute yaw rate and the absolute acceleration of the vehicle, and wherein the target trajectory module is further configured to generate a target position, a target speed, a target acceleration and a target steering angle for implementation as a parking maneuver based on the received signals.

[0010] Sensors can include, for example, environmental sensors or chassis sensors such as speed / torque sensors. Actuators can be adjustable by control units. External peripheral sensors include, for example, a rain sensor; that is, all non-driver-related sensors that provide input for functions controlling external parts of the vehicle. Internal peripheral sensors include, for example, a door sensor; that is, all non-driver-related sensors that provide input for functions controlling internal parts of the vehicle.

[0011] The absolute yaw rate / speed, etc., differs from a yaw rate / speed in that it can be more accurate / precise, for example, by using GNSS data, V2X data, or other external sources. If the absolute yaw rate / speed, etc., is not yet available, the conventionally determined yaw rate / speed can be used. Similarly, if reception of GNSS data, for example, is insufficient or nonexistent, a simpler yaw rate / speed / acceleration can be used.

[0012] Modules can be software that performs the corresponding function, or hardware such as a chip, SoC, etc., with a corresponding software component. The modules can, for example, be located within the same computer system.

[0013] The individual subsystems can serve as hosts for the corresponding modules; the subsystems can be executed in ascending order. If no value generated by another subsystem exists, a temporary default value can be used.

[0014] In this process, one signal can be received and others can be requested. According to the invention, the individual subsystems access all other subsystems directly or indirectly and thus process their outputs / inputs or provide input / output signals.

[0015] The management module manages the entire system behavior of the architecture, i.e., which behaviors occur in which sequence and under which conditions and circumstances. The management module is designed to detect the technical status of required sensors and / or actuators, at least with regard to functional safety, reliability, and / or availability. The management module generates the activation signal, which carries this information and is forwarded to the corresponding modules. This ensures that the sequence of signals and the individual modules / functions to be addressed are known. The activation signal can also contain the received signals in processed form.

[0016] The maneuvering tool determines whether a parking maneuver is possible based on the received signals. If it is, the tool can forward the activation signal. If a parking maneuver is not possible, the tool can terminate the maneuver and, if necessary, generate a corresponding message / warning.

[0017] The parking assistant according to the invention ensures compliance with the guidelines for model-based systems engineering (MBSE). Furthermore, the parking assistant is guaranteed to be free of warnings and errors. In addition, it can be simulated, which has the advantage of guaranteeing the flawless execution of the logical sequence and the absence of deadlocks (closed loops).

[0018] The parking assistant according to the invention is also characterized by a reduction in costs and risks, as well as a generalization of requirements, standardization of the system description, optimization of development effort, increased product quality, and a shorter time-to-market. It also facilitates the compatibility of products with one another through the standardization of interfaces. Such a parking assistant enables a shared understanding with customers to facilitate agreements and serves as a basis for SoTIF analysis (Safety of Intended Functionality).

[0019] The parking assistant according to the invention, through its inventive architecture, takes into account all necessary inputs and outputs required for the desired longitudinal and lateral dynamics. Furthermore, the parking assistant is logic-controlled with the aid of key decision nodes and control flows.

[0020] In particular, the parking assistant is designed to perform the parking maneuver automatically, taking into account the target position, target speed, target acceleration and target steering angle.

[0021] Further training includes an actuator module which receives at least the target position, target speed, target acceleration and target steering angle from the target trajectory module as well as the vehicle's speed, acceleration and yaw rate and, based on the received signals, determines longitudinal dynamics as longitudinal movement as well as lateral dynamics as lateral movement in order to implement the determined longitudinal dynamics as well as lateral dynamics.

[0022] Furthermore, a separately controllable primary axis and a separately controllable secondary axis may be present. An actuator module may be provided which receives at least the target position, target speed, target acceleration, and target steering angle from the target trajectory module, as well as the vehicle's speed, acceleration, and yaw rate. Based on the received signals, it determines longitudinal dynamics (longitudinal movement), torque distribution, and lateral dynamics (lateral movement), and implements at least the determined longitudinal dynamics and torque distribution using the separately controllable primary axis and the separately controllable secondary axis.

[0023] The parking assistant according to the invention allows a driver to automatically park the vehicle in the desired parking space. For example, the driver only needs to be near the vehicle and control the automatic parking process via a smart device (mobile phone / tablet).

[0024] According to the invention, the parking assistant interacts with the driver via the driver's input and the infrastructure, i.e., the road, in the form of the executed lateral and longitudinal movements. The driver sends and receives information (physical or digital) to and from the parking assistant; the latter provides the requested parking-related information as well as the lateral and longitudinal movements. The driver sends requests to activate and deactivate the parking assistant to the parking assistant, for example, via a mobile device.

[0025] Furthermore, Initiate Pre-Parking actions are preferably started: these provide the vehicle's position as an absolute location as well as its orientation, based on received GNSS (Global Navigation Satellite System) data, for example. They also provide environmental and infrastructure-based requirements. This data is used to initiate automatic parking and generate a CS (connected services)-based signal, which makes available the existing services available to the vehicle, such as FM radio, 4G connectivity, etc., available as connected services.

[0026] Furthermore, the parking assistant can generate the outputs Active, Information and Standby and display them via an output module, so that the driver can read the status and information of the parking assistant.

[0027] Further development includes a thirteenth subsystem with an actuator restriction module, which provides restrictions regarding acceleration, position, speed, and vehicle orientation in relation to the actuators as an actuator restriction signal and transmits this to the actuator module. This allows restrictions regarding the actuators required for longitudinal and lateral dynamics to be perceived, for example, regarding a steering angle.

[0028] Further development includes a recognition module designed to receive the sensor signal and the detection horizon signal. This module is configured to process the raw sensor data, at least with respect to the transmitted detection horizon, based on the sensor signal (which carries raw sensor data in a near-field and mid-field detection range within a vehicle environment) and the detection horizon signal. The processed sensor data may have undergone modifications to the raw data without fundamentally altering the data format.

[0029] Further training includes an Ego position module, which is designed to receive GNSS (Global Navigation Satellite Systems) data and / or map data relating to the absolute position, and furthermore to receive the sensor process signal, and the dynamic entity signal as well as the absolute speed of the vehicle, the absolute yaw rate and the absolute acceleration of the vehicle, and wherein the Ego position module is designed to determine a current absolute position of the vehicle as well as the vehicle orientation based on the received signals.

[0030] A GNSS is a system for determining position and navigation on Earth and in the air by receiving signals from navigation satellites and pseudolites. Absolute data, such as speed, is more precise than speed determined solely by wheel sensors.

[0031] In further development, a scene route restriction module is provided for receiving the acceleration, speed and yaw rate as well as the dynamic and static entity signal as well as an absolute position as well as a vehicle orientation, and a hypothesis signal which carries as a signal the information about at least one hypothetical driving behavior of the vehicle in the longitudinal and / or transverse direction of the planned driving direction, and wherein the scene route restriction module is designed to generate driving scene-related restrictions for the route planning of the vehicle based on the driving scene as a driving scene restriction signal.

[0032] In further development, the eighth subsystem also includes a prediction module which is designed to receive the vehicle's position and orientation as well as the dynamic entity signal, and wherein the prediction module is designed to determine, based on the received signals and in particular received map data relating to the vehicle's location, existing dynamic objects in the vicinity of the vehicle and, based on this, a future driving scene, and to provide them as fully characterized dynamic objects in a signal.

[0033] In further development, the prediction module is designed to transmit the fully characterized dynamic objects as a signal to the target trajectory module. This signal is then used to determine the target position, target speed, target acceleration, and target steering angle. The fully characterized dynamic objects are also transmitted as a signal to the maneuver tool to verify the feasibility of the parking maneuver. This allows for improved determination of the target position, target speed, target acceleration, and target steering angle, as well as enhanced verification.

[0034] In further development, the restriction module is designed to receive acceleration, yaw rate, and velocity from the motion module, as well as the vehicle's absolute position and orientation, and a hypothesis signal. This hypothesis signal carries information about at least one hypothetical driving behavior of the vehicle in both the longitudinal and lateral directions of the planned direction of travel. Furthermore, it is designed to receive both dynamic and static entity signals and, based on these signals, to generate restrictions for the parking maneuver and provide them as an in-lane signal. An entity is a single, uniquely identifiable information object, for example, a vehicle with its type, speed, etc.

[0035] Further development includes a third subsystem with a sensor module. This sensor module is designed to acquire raw sensor data in a near and medium detection range as environmental data of the vehicle and to generate a sensor signal that carries this raw data. Raw sensor data from cameras, lidar sensors, radar sensors, or, for example, ultrasound can be processed.

[0036] Further training includes a motion module which is designed to use suitable sensors to detect the speed, acceleration and yaw rate of the vehicle, as well as an ego motion module for detecting the absolute speed, yaw rate and acceleration of the vehicle.

[0037] Furthermore, the problem is solved by a method for implementing a parking assistant for a vehicle by performing a longitudinal and lateral movement to execute a parking maneuver, wherein the parking assistant has a parking assistant architecture comprising various modules including several sensors and actuators, comprising the steps: - Providing a first subsystem with an input data module for receiving and recognizing driver inputs, wherein the driver inputs include at least one activation as input to an activation input device as an activation request for activation of the parking assistant, wherein the input data module is configured to generate an activation request signal based on the received driver inputs, - Providing a third subsystem with a processing module designed to receive a sensor signal carrying raw sensor data in a near-field and mid-field detection range in a vehicle environment, and to receive an absolute position as well as a vehicle orientation and a detection horizon signal carrying information about a detection horizon aligned with the planned route, and designed to detect all dynamic and static entities at least within the detection horizon and to determine them as dynamic and static entity signals. - Providing a seventh subsystem with a management module for receiving the activation request signal, acceleration, velocity and yaw rate of the vehicle, each as a signal, and wherein the management module is configured to generate an activation signal based on the signals, which causes at least the activation of various modules in a predetermined sequence, - Providing an eighth subsystem with a restriction module which provides restrictions regarding the parking maneuver as an in-lane signal and with a restriction module for generating restrictions at least with regard to vehicle acceleration and / or speed and / or position as a restriction signal, - Providing a ninth subsystem with a maneuvering tool configured to receive absolute acceleration, absolute yaw rate, and absolute velocity, as well as a future driving scene that includes at least fully characterized detected dynamic objects in the detection horizon, and to receive the activation signal as well as the in-lane signal, and wherein the maneuvering tool is configured to check, based on the received signals, whether the parking maneuver is feasible and, if feasible, to forward the activation signal. - Providing a twelfth subsystem with a target trajectory module, which is configured at least to receive the restriction signal and the future driving scene, which includes at least fully characterized detected dynamic objects in the detection horizon, and the absolute speed, absolute yaw rate and absolute acceleration of the vehicle, and wherein the target trajectory module is further configured to generate, based on the received signals, a target position, a target speed, a target acceleration and a target steering angle for implementation as a parking maneuver and - Executing the parking maneuver.

[0038] The method is specifically designed to be executed on the parking assistant according to the invention.

[0039] In particular, the advantages of the parking assistant according to the invention can be transferred to the method. Both the method and the parking assistant are suitable for simulation testing.

[0040] Furthermore, the task is solved by a vehicle equipped with a parking assistant and / or a procedure as described above. The vehicle can be a hybrid or fully electric vehicle.

[0041] Further features and advantages of the present invention will become apparent from the following description with reference to the accompanying figures. These show: Fig. 1: a parking assistant for a vehicle in detail, Fig. 2: a pre-parking action (preliminary stage), Fig. 3: a version of the parking assistant.

[0042] Fig. Figure 1 shows a parking assistant 1 for a vehicle to perform longitudinal and lateral movements.

[0043] The vehicle can have a separately controllable primary axle and a separately controllable secondary axle, with the parking assistant 1 having a torque distribution for controlling the primary and secondary axles.

[0044] The primary axle can be a front axle and the secondary axle a rear axle, each with wheels. The parking assistant 1 is thus designed to adjust the torque distribution between the front and rear axles separately using a dedicated control unit. Furthermore, the parking assistant 1 features a parking assistant architecture 3.

[0045] The parking assistant 1 / the parking assistant architecture 3 has a first subsystem C1 with an input data module EM for receiving and recognizing driver inputs FAEI, wherein the driver inputs FAEI have at least one activation as input into an activation input device as an activation request for activation for the parking assistant 1.

[0046] Furthermore, the driver inputs include settings / adjustment options for setting or changing parameters regarding the parking assistant 1. This can, for example, include settings for acoustic / visual warnings or information.

[0047] The input data module EM is configured to generate an activation request signal (Scenario Activation Request) based on the received driver inputs FAEI. Furthermore, the input data module EM is configured to generate a parameter setting signal (Scenario Settings Input) based on the parameters entered by the driver for the parking assistant 1.

[0048] A second subsystem, C2 (energy management system), is also present. This includes an energy module, EngM, which is configured to receive the activation request signal (Scenario Activation Request) and is further configured to provide electrical energy based on the received signal, as well as to generate an electrical energy signal that carries the electrical energy as a high voltage (i.e., voltage above a certain threshold) and as a low voltage.

[0049] Furthermore, a third subsystem, C3, is present, comprising a sensor module SM. This module is configured to receive a low-voltage signal and to acquire raw sensor data within a near-range and mid-range detection area of ​​the vehicle's surroundings using existing sensors. It then generates a sensor signal (Short Range Detection Data, Mid Range Detection Data) that carries this raw data. The sensor module SM thus scans the environment, specifically the predefined near-range and mid-range detection areas, and makes this data available for perception. The near-range and mid-range detection areas can depend on the configuration of the sensors, i.e., their detection range.

[0050] The SM sensor module delivers raw sensor data in the predefined near and medium detection ranges in the vehicle environment using sensors such as cameras, radar, lidar, ultrasonic sensors, etc. The raw sensor data is then processed.

[0051] An eighth subsystem, C8, is also present, featuring a sensing horizon module (EHM). This module receives a planned route signal, which includes information about the planned / desired route from the current location to the destination, taking into account geomap data, traffic data, etc., from a planning route module (PlanroutenM). Furthermore, the sensing horizon module (EHM) receives the vehicle's absolute speed, yaw rate, and acceleration, transmitted by an ego motion module (EnhM). This absolute motion data is generated, for example, with the aid of infrastructure and can therefore be more accurate than data generated solely by the vehicle's internal sensors.

[0052] Based on the received signals, the EHM detection horizon module generates a detection horizon, here the corresponding longitudinal and transverse directions, aligned with the planned route, as a detection horizon signal.

[0053] Furthermore, a fourth subsystem, C4, is present. This subsystem includes a processing module, POV, which is configured to receive the sensor signal (Short Range Detection Data, Mid Range Detection Data) and to receive an absolute position (Vehicle Position) as well as a vehicle orientation, i.e., the vehicle's orientation with respect to yaw, pitch, and roll, and the detection horizon signal as digital signals. It is configured to identify all dynamic entities, such as vehicles, trucks, bicycles, and pedestrians, with object-specific information such as position, speed, and direction, and static entities, such as traffic lights, road signs, etc., with object-specific information such as position and direction, in the vehicle's environment, particularly within the detection horizon.Based on the received signals, the POV processing module generates a dynamic entity signal and a static entity signal. The dynamic entity signal contains information such as position, direction, and speed about dynamic entities like cars, trucks, bicycles, and pedestrians, while the static entity signal contains information such as position and direction about static entities.

[0054] The dynamic entity signal contains processed raw sensor data from dynamic entities, and the static entity signal contains processed raw sensor data from static entities in the short range and mid range, particularly in the detection horizon.

[0055] Furthermore, a data availability module (DatM) is present. This allows the perception capability to be estimated. This can be expressed, for example, simply by a detection horizon along with an estimated latency between detections within this horizon. The capability itself can be derived, for example, from the capabilities of the individual sensors under different light, weather, and environmental conditions. To determine the perception capability, the data availability module (DatM) receives the detection horizon signal as well as the velocity, acceleration, and yaw rate from a motion module (EgoM). This module generates the motion data using internal sensors.

[0056] The data availability module DatM has interfaces for receiving map data and Vx2 data. This data can also be processed within the data availability module DatM. Based on the received signals, the data availability model DatM generates a data availability signal (perception capability).

[0057] Furthermore, subsystem C4 includes a recognition module ErkM, which is configured to receive the sensor signal and the detection horizon signal. Based on these signals, it processes the raw sensor data, particularly with regard to the transmitted detection horizon. The output data can be in the same format as the raw input data, but it has undergone additional processing or transformation. The processed sensor data may have undergone modifications to the raw data without fundamentally altering the data format. An example of processed environmental data would be an image, which can be modified but remains an image, unlike converting a pixel-based image into a list of objects. The recognition module ErkM generates a sensor process signal that carries the processed sensor data.

[0058] A fifth subsystem is also present, featuring an extended Ego Position Module (Ego-PosM). This module is designed to determine the vehicle's current absolute position relative to global coordinates, as well as its orientation (yaw, pitch, and roll), each as a signal. Ego Position Module Ego-PosM can receive data such as GNSS and map data, including information about the current route (i.e., relative to the current location), and potentially V2X data. GNSS data consists of position and time data transmitted from a global navigation satellite system (GNSS) to a GNSS receiver. This data can be used for location determination.

[0059] Furthermore, the Ego Position Module (Ego-PosM) receives the dynamic entity signal from the Processing Module (POV) as well as the sensor process signal from the Recognition Module (ErkM). The Ego Position Module (Ego-PosM) also receives the vehicle's absolute speed, yaw rate, and acceleration, which are transmitted by the Ego Motion Module (EnhM). Absolute motion data is generated, for example, with the aid of an infrastructure and can therefore be more accurate than data generated solely by the vehicle's internal sensors.

[0060] Based on the received signals, the Ego-PosM position module determines the current absolute position of the vehicle as both its global coordinate positioning (i.e., the vehicle's origin position) and its vehicle orientation (i.e., its orientation with respect to, for example, yaw, pitch, and roll). If an absolute current position cannot yet be determined, the Ego-PosM position module can provide a preliminary position.

[0061] Furthermore, a sixth subsystem C6 contains an Ego motion module EnhM for recording the absolute vehicle speed, absolute yaw rate, and absolute acceleration of the vehicle.

[0062] The Ego Motion Module EnhM is designed to receive current GNSS data as well as a corresponding low-voltage signal. Furthermore, the Ego Motion Module EnhM receives the sensor process signal from the Recognition Module ErkM, which carries the processed sensor data. The Ego Motion Module EnhM also receives the dynamic entity signal as well as the static entity signal from the Processing Module POV. The Ego Motion Module EnhM thus combines data from perception and infrastructure to intelligently determine a more accurate and complex estimate of the vehicle's motion data.

[0063] Based on this, the Ego motion module EnhM provides the motion data: absolute vehicle speed, absolute yaw rate, and absolute acceleration. The absolute vehicle speed / acceleration / yaw rate is more accurate than the speed / acceleration / yaw rate measured by an EgoM motion module.

[0064] Furthermore, the sixth subsystem, C6, contains the motion module EgoM, which is designed to detect the vehicle's speed, acceleration, and yaw rate using suitable sensors. Wheel sensors or other sensors can be used for this purpose. The EgoM motion module is interconnected with the EngM power module to provide the necessary low-voltage supply.

[0065] The EgoM motion module provides vehicle motion data such as speed, acceleration, and yaw rate using sensors like the IMU and / or chassis sensors and / or compass. The accuracy of this data may differ from the absolute speed, acceleration, and yaw rate measured by the Ego motion module EnhM.

[0066] Furthermore, a seventh subsystem C7 with a management module VM is present. This receives the activation request signal from the input data module EM as well as the acceleration, velocity, and yaw rate, which are generated by the motion module EgoM.

[0067] Based on the signals, an activation signal (Scenario Activation Command) is generated, which triggers the activation of various modules in a predefined sequence. The Management Module (VM) manages the overall system behavior of the architecture, i.e., which behaviors occur in which sequence and under which conditions and circumstances. The Management Module (VM) is designed to detect the technical status of required sensors and / or actuators, at least with regard to functional safety, reliability, and / or availability. The Management Module (VM) generates the activation signal, which carries this information and is forwarded to the corresponding modules.

[0068] This allows the sequence of signals and individual modules / functions to be addressed to be known. Likewise, the activation signal can contain the received signals in processed form.

[0069] The seventh subsystem, C7, also includes a route restriction module, RoutebeM. This module receives map data relating to the current location as well as the data availability signal (Perception Capability) from the data availability model, DatM.

[0070] The RoutebeM route restriction module forms route restrictions based on received signals to ensure that infrastructure boundaries are not exceeded. RoutebeM thus recognizes driving-scene-based route restrictions, i.e., restrictions on specific routes that must be considered to define which behavioral functions can be activated and when. Based on these recognized driving-scene-based route restrictions, RoutebeM generates a route restriction signal (VSM-Based Route Constraints).

[0071] Furthermore, the eighth subsystem C8 is present. This includes a scene route constraint module SzenroutebeM. This receives the absolute acceleration, absolute velocity, and absolute yaw rate generated by the Ego motion module EnhM, as well as the dynamic entity signal and the static entity signal from the POV processing module.

[0072] Furthermore, the scene route restriction module SzenroutebeM receives the absolute position as well as the vehicle orientation, i.e., an orientation of the vehicle in terms of yaw, pitch and roll, from the Ego position module Ego-PosM.

[0073] Likewise, the scene route restriction module SzenroutebeM receives a hypothesis signal (longitudinal hypothesis, lateral hypothesis) which carries information about at least one hypothetical driving behavior of the vehicle in the longitudinal direction of the planned direction of travel as well as in the transverse direction (lateral direction) of the planned direction of travel as a signal from a hypothesis module HM.

[0074] Similarly, the scene route restriction module (SzenroutebeM) can be configured to receive map data, data on the current traffic route (i.e., in relation to the current location), and potentially V2X data. Based on the received signals, the scene route restriction module (SzenroutebeM) generates restrictions, such as limitations on permissible routes, for the vehicle's route planning based on a detected driving scene. It then generates a driving scene restriction signal (infrastructure-based constraints) containing the detected driving scene-related restrictions.

[0075] Furthermore, the eighth subsystem C8 (perception subsystem) includes a prediction module VorM, which is configured to receive the vehicle's position and orientation as digital signals. The prediction module VorM is also configured to receive the dynamic entity signal. Additionally, the prediction module VorM receives map data related to the vehicle's location / route.

[0076] Similarly, the VorM prediction module is designed to determine all dynamic objects, such as a ball, animal, etc., in the vicinity of the vehicle and their future driving scenario, based on the received signals, and to provide them as fully characterized dynamic objects.

[0077] The identified, fully characterized dynamic objects are provided as processed environmental data, in this case a signal, as fully characterized dynamic objects. A full characterization of the dynamic objects includes, for example, detailed object data, various states, and / or a future trajectory.

[0078] Furthermore, the eighth subsystem C8 includes a restriction module BMP, which provides restrictions for driving in the lane. To this end, the restriction module BMP receives the acceleration, yaw rate, and velocity from the motion module EgoM, as well as the vehicle's absolute position and orientation, and the hypothesis signal, i.e., information about the at least hypothetical driving behavior of the vehicle in the longitudinal direction of the planned direction of travel, as well as in the transverse (lateral) direction of travel. The restriction module BMP also receives the dynamic entity signal and the static entity signal. Based on these signals, the restriction module EschM determines restrictions for planned parking maneuvers of the vehicle based on the driving scene conditions recognized by the received signals, such as a possible...Emergency braking and safe stopping within the lane. The BMP restriction module generates an in-lane driving constraint signal, which conveys the restrictions regarding the parking maneuver.

[0079] Furthermore, the eighth subsystem C8 includes a constraint module EschM, which receives the acceleration, yaw rate, and velocity from the motion module EgoM, the vehicle's absolute position and orientation, and the hypothesis signal, i.e., information about the hypothetical driving behavior of the vehicle in the longitudinal direction of the planned direction of travel as well as in the transverse (lateral) direction of travel. The constraint module EschM also receives the dynamic entity signal as well as the static entity signal.

[0080] Based on the received signals, the EschM restriction module generates restrictions at least with regard to the acceleration of the vehicle, for example with regard to longitudinal, lateral and angular acceleration restrictions and speed restrictions.

[0081] The EschM restriction module also generates position constraints, such as longitudinal position constraints or transverse position constraints, as a restriction signal.

[0082] Furthermore, a ninth subsystem, C9, includes a motion planning module, MovM, which is configured to receive acceleration, yaw rate, and velocity from the motion module, EgoM, as well as the activation signal from the management module, VM. Additionally, the MovM motion planning module receives a connectivity signal (Smart Devices Request), which provides information on the connectivity of smart devices such as Bluetooth, Wi-Fi hotspot, USB connection, AUX cable connection, etc., required for various applications. The MovM motion planning module is configured to configure and schedule various motion controllers to control different movements based on the received signals.The MovM motion planning module processes requirements and limit values ​​as planned braking data or planned acceleration data (longitudinal motion data) and / or planned steering data (lateral motion data), which specifies steering information. These signals are then used to plan the motion. Thus, for non-autonomous scenarios, the MovM motion planning module provides the planned longitudinal and lateral motion data, including limit values ​​for motion control, torque, braking force, etc., as well as the corresponding force required.

[0083] Furthermore, the EHM (Emergency Height Management) module is located in the ninth subsystem, C9. This module receives a planned route signal, which includes information about the planned / desired route from the current location to the destination, taking into account geomap data, traffic data, etc., from a PlanroutenM (Planned Routes) module. The EHM also receives the vehicle's absolute speed, yaw rate, and acceleration, which are transmitted by an EnhM (Ego Motion) module. Absolute motion data is generated, for example, with the aid of infrastructure and can therefore be more accurate than data generated solely by the vehicle's internal sensors.

[0084] Based on the received signals, the EHM detection horizon module generates a detection horizon, here the corresponding longitudinal and transverse directions, aligned with the planned route, as a detection horizon signal.

[0085] Furthermore, a hypothesis module HM is present in the ninth subsystem C9, which is configured to receive acceleration, yaw rate, and velocity from the motion module EgoM. Additionally, the hypothesis module HM receives the planned route signal, which contains information about the planned / desired route from the current location to the destination, taking into account geomap data, traffic data, etc., from the planned route module PlanroutenM.

[0086] The hypothesis module HM generates at least one hypothetical maneuver for the vehicle, based on the received signals. This maneuver provides information about the vehicle's hypothetical driving behavior both longitudinally and laterally (in the planned direction of travel). This maneuver can trigger reactions from other road users that must be anticipated. For example, a lane change might force another road user approaching in that lane to brake suddenly and dangerously. The hypothesis module HM can generate multiple maneuver hypotheses before a decision is made.

[0087] Based on the hypothetical driving behavior of the vehicle in the longitudinal direction of the planned direction of travel as well as in the transverse direction (lateral direction) of the planned direction of travel, a hypothesis signal (longitudinal hypothesis, lateral hypothesis) is generated that carries the information about the hypothetical driving behavior.

[0088] Furthermore, the ninth subsystem C9 contains a maneuvering tool MT.

[0089] The maneuvering tool MT is designed to receive the in-lane signal from the constraint module BMP, as well as the fully characterized dynamic objects as an (environmental) signal from the prediction module VorM, the activation signal (Scenario Activation Command) from the management module VM, and the vehicle's absolute speed, yaw rate, and acceleration from the ego motion module EnhM. Based on these signals, the maneuvering tool MT is configured to verify whether all necessary data for a parking maneuver is available and whether such a maneuver is feasible. If the parking maneuver is possible, the activation signal is forwarded by the management module MV.

[0090] Furthermore, a tenth subsystem, C10, is present, containing a connection service module (VerSM) that is configured to receive a CS (connected services)-based signal (CS-Based Information) with information from available services provided to the vehicle, such as FM radio, 4G connectivity, etc. For this purpose, the VerSM receives a low-voltage signal. Based on this, the VerSM generates an infrastructure-based signal (Infrastructure Based Information) that carries the information about the available services. This infrastructure-based signal (Infrastructure Based Information) thus contains infrastructure-based information provided by available services, which can be output to an output module (AusM).

[0091] Similarly, a subsystem C11 is present, which includes the route planning module PlanroutenM. This module plans the required route from the current location to the destination, taking into account geomaps, traffic data, and other relevant information. To do this, PlanroutenM receives V2X data as well as map data regarding the current location, the vehicle's absolute position and orientation, the scenario settings input generated from the received driver inputs (FAEI), and the infrastructure-based constraints signal from the RoutebeM route restriction module. Furthermore, PlanroutenM receives the scene-based route constraints signal with infrastructure-related restrictions, such as limitations on permissible routes, from the SceneroutebeM route restriction module.

[0092] Based on the received signals, the route planning module PlanroutenM generates the planned route signal, which includes information about the planned / desired route from the current location to the destination, taking into account geomap, traffic data, etc.

[0093] Likewise, a twelfth subsystem, C12, is present, comprising a target trajectory module, ZM. ZM is configured to receive the activation signal (Scenario Activation Command) transmitted by the maneuver tool, MT. Furthermore, ZM is configured to receive the constraint signal from the constraint module, EschM, regarding the vehicle's acceleration, speed, and position constraints. ZM also receives fully characterized dynamic objects as a signal from the prediction module, VorM. Additionally, ZM receives the vehicle's absolute speed, yaw rate, and acceleration, transmitted by the ego motion module, EnhM.

[0094] Furthermore, the target trajectory module ZM receives an actuator constraint signal regarding acceleration, speed, position and vehicle orientation (Position Constraints, Speed ​​Constraints, Acceleration Constraints Orientation Constraints), which carries the restrictions for certain maneuvers with respect to the actuators as information and which are generated by an actuator constraint module ABeschM.

[0095] Based on the received signals, the target trajectory module ZM generates a target position, a target speed, a target acceleration, and a target steering angle.

[0096] Furthermore, a thirteenth subsystem C13 with the actuator constraint module ABeschM is available for generating the actuator constraint signal (Position Constraints, Speed ​​Constraints, Acceleration Constraints Orientation Constraints), which specifies the restrictions for certain maneuvers with regard to the actuators, for example with regard to the actuator settings / change rate, etc.

[0097] Thus, the actuator constraint module ABeschM restricts the vehicle's movement with respect to acceleration, position, speed, and orientation based on actuator conditions, such as actuator limits, actuator limit status, etc. To this end, the actuator constraint module ABeschM receives a feedback signal (Actuator Generated Effort), which represents the effort expended by the vehicle's actuators based on the target position, target speed, target acceleration, and target steering angle generated by the target trajectory module ZM. Furthermore, the actuator constraint module ABeschM receives a status signal containing information about the status of the required actuators.

[0098] Furthermore, the thirteenth subsystem C13 additionally includes an actuator module AktM, which receives the target position, target speed, target acceleration and target steering angle from the target trajectory module ZM, as well as the vehicle speed, acceleration and yaw rate from the motion module EgoM, and also the planned braking data or planned acceleration data as planned longitudinal motion data and / or planned steering data as planned lateral motion data as a signal from the motion planning module MovM.

[0099] Based on the received signals, the actuator module AktM is designed to calculate longitudinal dynamics (desired effort, longitudinal dynamics) as longitudinal movement and lateral dynamics (desired effort, lateral dynamics) as transverse movement. The longitudinal dynamics signal contains information about various longitudinal physical quantities, including at least the longitudinal velocity and longitudinal acceleration, which are to be generated by the actuators responsible for the longitudinal dynamics. Furthermore, the actuator module AktM can also generate a signal indicating a desired operating state for the required actuators. In doing so, the actuator module AktM can determine the torque distribution between the primary and secondary axes.

[0100] The actuator module AktM sends the calculated longitudinal dynamics and torque distribution as well as the lateral dynamics to a conversion module UmsetzungM as well as the signal with a desired operating state in order to effect the desired conversion.

[0101] Thus, the actuator module AktM is responsible for the requirements of drive changes related to the movement of the vehicle.

[0102] Furthermore, a fourteenth subsystem C14 is provided, which has the conversion module ImplementationM, for converting the received longitudinal dynamics and torque distribution as well as the received lateral dynamics on the basis of a received high voltage voltage using required actuators / control devices.

[0103] The desired calculated longitudinal and lateral dynamics are sent by the actuator module AktM to an actuator management module VAM, which is located in the thirteenth subsystem C13. This module manages the status of the required actuators / drives, i.e., whether they are active, on standby, malfunctioning, or have a fault. Based on the determined status for each required actuator, an information message can be generated as a status signal (Active, Error). If a fault is detected, this message contains a fault warning; otherwise, it contains a fault-free or active information.

[0104] Likewise, a feedback module FeedM is available to generate a feedback signal (Actuator Generated Effort) for transmission to the actuator module AktM regarding the desired longitudinal and lateral dynamics actually achieved by the actuators, whereby the actuator module AktM is designed to take the feedback into account when recalculating the desired longitudinal and lateral dynamics.

[0105] Likewise, an output module AusM is present in the first subsystem C1 for outputting the status signal (Active, Error) or a standby mode as information.

[0106] Fig. Figure 2 shows a pre-parking action (preliminary stage) for executing the parking assistant 1. This action features input devices such as a display / touchscreen for entering driver inputs (FAEI), where the driver inputs (FAEI) include at least the activation request as input to an activation input device for activating the parking assistant 1. The input data module (EM) is configured to generate the activation request signal (Scenario Activation Request) based on the received activation request.

[0107] This is transmitted to the energy module EngM, which provides electrical energy based on the received signal and generates an electrical energy signal that carries the electrical energy as high voltage (i.e., voltage above a certain threshold) and as low voltage.

[0108] Furthermore, the activation request signal (Scenario Activation Request) is sent to a connection request module VerbiM. This module also receives the connectivity signal (Smart Devices Request), which provides information on the connectivity of smart devices such as Bluetooth, Wi-Fi hotspot, USB connection, AUX cable connection, etc., required for various applications.

[0109] The VerbiM connection request module queries / requests various connected services required by the parking assistant 1, such as FM radio, 4G connection, etc., and generates a CS-based request signal that defines the requirements for these services. Furthermore, an interface for transmitting GNSS data is provided for generating the absolute position and vehicle orientation via the Ego-PosM position module.

[0110] Fig.Figure 3 shows a version of the parking assistant 1.

[0111] This system features input devices such as a display / touchscreen for entering driver inputs (FAEI). These FAEI inputs can be entered into various elements and forwarded to the input data module (EM). FAEI inputs include activation input to an activation input device to generate the activation request signal (Scenario Activation Request) and parameter settings input to generate the parameter setting signal (Scenario Settings Input). Furthermore, a deactivation input can also be used to deactivate the parking assistant 1, which is converted into a deactivation signal (Scenario Deactivation Request). This signal can be received by a deactivation module (DeM).The deactivation module DeM is designed to generate a deactivation output signal (Inactive, Feedback to Occupant) which carries the information about the deactivation of the parking assistant 1 and also to activate the parking assistant 1.

[0112] Likewise, a deactivation function may be present, which is located, for example, in the management module VM, for receiving the deactivation signal (Deactivation Request scenario), which is also designed to deactivate the parking assistant 1 as well as to generate the deactivation output signal (Inactive, Feedback to Occupant).

[0113] The system also includes a connectivity signal (Smart Devices Request), which provides information on the connectivity of smart devices such as Bluetooth, Wi-Fi hotspot, USB connection, AUX cable connection, etc., and is forwarded to the pre-parking action (preliminary stage). This action also receives GNSS data. The absolute position (vehicle position) and the vehicle orientation are determined using this GNSS data.

[0114] Furthermore, based on the connectivity signal (Smart Devices Request), environment-based and infrastructure-based requests are generated by the pre-parking action (preliminary stage). These requests are forwarded to an infrastructure module (InfraM) to determine the available environment-based and infrastructure-based services. Information on the available services, such as FM radio, 4G connection, etc., as connected services, as well as environmental information, is forwarded to the parking assistant 1 as a service provision signal (Infrastructure-Based Information, Environment-Based Information).

[0115] Furthermore, the parking assistant 1 has interfaces for receiving V2X data and map data.

[0116] The parking assistant 1 is designed to execute longitudinal dynamics as longitudinal movement and lateral dynamics as lateral movement based on the received signals, wherein the longitudinal dynamics signal contains information about various longitudinal dynamic physical quantities including at least the longitudinal velocity and longitudinal acceleration, which are to be generated by the actuators causing the longitudinal dynamics.

[0117] Furthermore, the parking assistant 1 generates a torque distribution to distribute the torque between the primary and secondary axles. This allows the vehicle to perform a parking maneuver on the road surface using longitudinal dynamics and lateral dynamics.

[0118] Similarly, the parking assistant 1 displays corresponding signals / information on an output module AusM, such as active, inactive, etc. Reference symbol list 1 Parking assistant 3 Parking Assistance Architecture From output module InfraM infrastructure module DeM deactivation signal FAEI rider inputs VerbiM connection request module Ego-PosM Ego Position Module EngM Energy Module FeedM feedback module Implementation Module VAM Actuator Management Module AktM Actuator Module ABeschM Actuator Restriction Module ZM Target Trajectory Module EnhM Ego Movement Module Pre-M prediction module EschM Restriction Module MT Maneuver Tool RoutebeM route restriction module Planned routes M Planned route module Scene routebeM scene route restriction module VerSM Connection Service Module VM Management Module HM Hypothesis Module EHM Acquisition Horizon Module MovM Movement Planning Module BMP Restriction Module EgoM movement module ErkM Recognition Module DatM Data Availability Module Street surface POV Processing Module SM Sensor Module EM Input Data Module C1-C14 Subsystems

Claims

[1] Parking assistant (1) for a vehicle by performing a longitudinal and lateral movement to carry out a parking maneuver, wherein the parking assistant (1) has a parking assistant architecture (3) comprising various modules including several sensors and actuators characterized by , that the parking assistance architecture (3) features: a first subsystem (C1) with an input data module (EM) for receiving and recognizing driver inputs (FAEI), wherein the driver inputs (FAEI) include at least one activation as input to an activation input device as an activation request for activation of the parking assistant (1), wherein the input data module (EM) is configured to generate an activation request signal based on the received driver inputs (FAEI), a third subsystem (C3) with a processing module (POV) which is designed to receive a sensor signal carrying raw sensor data in a near-range and mid-range detection area in a vehicle environment, and which is designed to receive an absolute position as well as a vehicle orientation and a detection horizon signal which carries information about a detection horizon adapted to the planned route, and which is further designed to detect all dynamic and static entities at least in the detection horizon and to determine them as dynamic and static entity signals. a seventh subsystem (C7) with a management module (VM) for receiving the activation request signal, acceleration, speed and a yaw rate of the vehicle each as a signal and wherein the management module (VM) is configured to generate an activation signal based on the signals, which causes at least the activation of various modules in a predetermined sequence, an eighth subsystem (C8) with a restriction module (BMP) which provides restrictions for driving with regard to the parking maneuver as an in-lane signal and with a restriction module (EschM) for generating restrictions as a restriction signal at least with regard to vehicle acceleration and / or speed and / or position; a ninth subsystem (C9) with a maneuver tool (MT) which is configured to receive an absolute acceleration, an absolute yaw rate and an absolute speed as well as a future driving scene which includes at least fully characterized detected dynamic objects in the detection horizon, as well as to receive the activation signal as well as the in-lane signal and wherein the maneuvering tool (MT) is trained to check, based on the received signals, whether the parking maneuver is feasible and, if feasible, to forward the activation signal, a twelfth subsystem (C12) with a target trajectory module (ZM) which is designed at least to receive the restriction signal and the future driving scene, which includes at least fully characterized detected dynamic objects in the detection horizon, and the absolute speed of the vehicle, the absolute yaw rate and the absolute acceleration of the vehicle and wherein the target trajectory module (TM) is further configured to generate a target position, target speed, target acceleration and target steering angle for implementation as a parking maneuver, based on the received signals. [2] Parking assistant (1) according to claim 1, characterized by, that the parking assistant (1) is designed to carry out the parking maneuver automatically, taking into account the target position, target speed, target acceleration and target steering angle. [3] Parking assistant (1) according to one of the preceding claims, characterized bythat a separately controllable primary axis and a separately controllable secondary axis are present, and an actuator module (ActM) is provided which receives at least the target position, target speed, target acceleration and target steering angle from the target trajectory module (ZM) as well as the vehicle speed, acceleration and yaw rate, and determines longitudinal dynamics as longitudinal movement and torque distribution as well as lateral dynamics as lateral movement based on the received signals, and implements at least the determined longitudinal dynamics and torque distribution by means of the separately controllable primary axis and the separately controllable secondary axis. [4] Parking assistant (1) according to one of the preceding claims 1 and 2, characterized by, that an actuator module (ActM) is provided which receives at least the target position, target speed, target acceleration and target steering angle from the target trajectory module (ZM) as well as the vehicle speed, acceleration and yaw rate and, based on the received signals, determines a longitudinal dynamic as longitudinal movement as well as a lateral dynamic as lateral movement for the implementation of the determined longitudinal dynamic as well as lateral dynamic. [5] Parking assistant according to claim 3 or 4, characterized by , that a thirteenth subsystem (C13) with an actuator restriction module (ABeschM) is present, which provides restrictions regarding acceleration, position, speed and vehicle orientation in relation to the actuators as an actuator restriction signal, and transmits this to the actuator module (AktM). [6] Parking assistant (1) according to any of the preceding claims, characterized by, that a detection module (DML) is present which is designed to receive the sensor signal and the detection horizon signal, and which is designed to process the raw sensor data based on the sensor signal and the detection horizon signal, at least with respect to the transmitted detection horizon, and to make it available as a sensor process signal. [7] Parking assistant (1) according to claim 6, characterized by, that an Ego Position Module (Ego-PosM) is present, which is configured to receive GNSS data and / or map data with respect to the absolute position, and furthermore to receive the sensor process signal, and the dynamic entity signal as well as the absolute speed of the vehicle, the absolute yaw rate and the absolute acceleration of the vehicle, and wherein the Ego Position Module (Ego-PosM) is configured to determine an absolute position of the vehicle as well as the vehicle orientation based on the received signals. [8] Parking assistant (1) according to one of the preceding claims, characterized by, that a scene route restriction module (scene routebeM) is present for receiving the acceleration, velocity and yaw rate as well as the dynamic entity signal and static entity signal as well as the absolute position as well as the vehicle orientation, and a hypothesis signal which carries as a signal the information about at least one hypothetical driving behavior of the vehicle in the longitudinal and / or transverse direction of the planned driving direction, and wherein the scene route restriction module (scene routebeM) is configured as a driving scene restriction signal for generating driving scene-related restrictions for the route planning of the vehicle based on the driving scene. [9] Parking assistant (1) according to any of the preceding claims, characterized by, that the eighth subsystem (C8) further comprises a prediction module (VorM) which is configured to receive the position of the vehicle as well as the vehicle orientation and to receive the dynamic entity signal and wherein the prediction module (VorM) is configured to determine, based on the received signals and received map data relating to the location of the vehicle, existing dynamic objects in the vicinity of the vehicle and, on the basis of this, to determine a future driving scene and to provide it as fully characterized dynamic objects in a signal. [10] Parking assistant (1) according to claim 9, characterized by, that the prediction module (VorM) is designed to transmit the fully characterized dynamic objects as a signal to the target trajectory module (ZM) for consideration of the signal in determining the target position, target speed, target acceleration and target steering angle, as well as to transmit the fully characterized dynamic objects as a signal to the maneuver tool (MT) for consideration in checking whether the parking maneuver is feasible. [11] Parking assistant (1) according to any of the preceding claims, characterized by, that the constraint module (BMP) is designed to receive the acceleration, yaw rate and speed from the motion module EgoM as well as the absolute position and vehicle orientation of the vehicle and a hypothesis signal which carries information about at least one hypothetical driving behavior of the vehicle in the longitudinal direction as well as in the lateral direction of the planned driving direction as a signal and is further designed to receive the dynamic entity signal as well as the static entity signal and is further designed to generate constraints for the parking maneuver based on the signals and to provide them as an in-lane signal. [12] Parking assistant according to one of the preceding claims, characterized by, that a third subsystem (C3) with a sensor module (SM) is present, wherein the sensor module (SM) is designed to acquire raw sensor data in a near detection range and medium detection range as environmental data of the vehicle and to generate a sensor signal which carries the raw sensor data. [13] Parking assistant (1) according to one of the preceding claims, characterized by , that a motion module (EgoM) is present which is designed to detect the speed, acceleration and yaw rate of the vehicle using suitable sensors, and that an Ego motion module (EnhM) is present for detecting the absolute speed of the vehicle and the absolute yaw rate and the absolute acceleration of the vehicle. [14] Method for performing a parking assistant (1) for a vehicle by performing a longitudinal and lateral movement to perform a parking maneuver, wherein the parking assistant (1) has a parking assistant architecture (3) comprising various modules, comprising several sensors and actuators, comprising the steps: - Providing a first subsystem (C1) with an input data module (EM) for receiving and recognizing driver inputs (FAEI), wherein the driver inputs (FAEI) include at least one activation as input to an activation input device as an activation request for activation of the parking assistant (1), wherein the input data module (EM) is configured to generate an activation request signal based on the received driver inputs (FAEI), - Providing a third subsystem (C3) with a processing module (POV) designed to receive a sensor signal carrying raw sensor data in a near-field and mid-field detection range in a vehicle environment, and to receive an absolute position as well as a vehicle orientation and a detection horizon signal carrying information about a detection horizon aligned with the planned route, and designed to detect all dynamic and static entities at least within the detection horizon and to determine them as dynamic and static entity signals. - Providing a seventh subsystem (C7) with a management module (VM) for receiving the activation request signal, acceleration, velocity and yaw rate of the vehicle, each as a signal, and wherein the management module (VM) is configured to generate an activation signal based on the signals, which causes at least the activation of various modules in a predetermined sequence, - Providing an eighth subsystem (C8) with a restriction module (BMP) which provides restrictions regarding the parking maneuver as an in-lane signal, and with a restriction module (EschM) for generating restrictions as a restriction signal at least with regard to acceleration and / or speed and / or position of the vehicle, - Providing a ninth subsystem (C9) with a maneuver tool (MT) configured to receive absolute acceleration, absolute yaw rate, and absolute velocity, as well as a future driving scene which includes at least fully characterized detected dynamic objects in the detection horizon, and to receive the activation signal as well as the in-lane signal, and wherein the maneuver tool (MT) is configured to check, based on the received signals, whether the parking maneuver is feasible and, if feasible, to forward the activation signal. - Providing a twelfth subsystem (C12) with a target trajectory module (ZM) configured at least to receive the restriction signal and the future driving scene, which includes at least fully characterized detected dynamic objects in the detection horizon, and the vehicle's absolute speed, absolute yaw rate, and absolute acceleration, and wherein the target trajectory module (ZM) is further configured to generate, based on the received signals, a target position, a target speed, a target acceleration, and a target steering angle for implementation as a parking maneuver and - Executing the parking maneuver. [15] Vehicle with a parking assistant (1) according to any of the preceding claims 1 to 13 or a parking assistant (1) on which the method according to claim 14 is carried out.

Images