Hierarchical system for controlling automated vehicle

Abstract

The invention relates to a hierarchical structure system for controlling an automated vehicle, having a hardware-based first layer, which receives a first control signal and on which a regulation technology conversion is performed, or other base layer, and a reflection-based second layer, which receives a second control signal and on which a regulation technology conversion is performed, a first processor higher than the hardware layer in the hierarchical structure and receiving a control signal from at least one higher layer and converting the control signal into a first control signal for the hardware layer, further based on a first scene-specific data intervention; and / or a third layer based on motion, which is higher than the reflective layer on the hierarchical structure and receives the base trajectory from the layer above it and converts into a second control signal for the reflective layer, further based on the first scene-specific data intervention; and / or an intent-based fourth layer, which generates a base trajectory for the motion layer on the basis of the first scene-specific data and transmits the base trajectory to the third layer by means of a third control signal; and / or a context-based fifth layer that generates a fourth control signal for the intent layer based on the second scene-specific data.

Description

Technical Field

[0001] The invention relates to a hierarchical system for controlling an automated vehicle. Background Art

[0002] Traditionally, software stacks for automated vehicles are designed according to the Sense-Plan-Act-Prinzip principle: the “Perception” component is responsible for building an environmental model based on acquired sensor data, the “Planning” component derives a plan for the automated vehicle based on the generated model, and the “Act” component converts the plan into control commands for the vehicle. Not only are software stacks that primarily use model-based algorithms designed according to this principle, but so are software stacks that are implemented with the aid of deep learning. Document US2023 202 489A1 discloses an example of such a software stack.

[0003] The challenge of such a stack structure is to design the software stack robustly so that it can reliably handle degradation. A known approach is to implement two parallel signal processing paths - one optimized for performance and the other to ensure safety. However, such a structure may result in the performance path often hitting the limits set by the optimization path for safety and thus causing the entire system to oscillate. As a result, the robustness of such a software stack for automated vehicles is reduced, which may lead to a decrease in the control quality of the vehicle. Summary of the invention

[0004] It is therefore an object of the present invention to provide a solution for improving a software stack for automated vehicles.

[0005] This object is achieved by a hierarchical system for controlling an automated vehicle having the features of the independent claim.

[0006] According to a first aspect, the invention relates to a hierarchical system for controlling an automated vehicle, the hierarchical system having:

[0007] a hardware-based first layer, which is designed to receive the first control signal and to carry out a regulation-technical implementation / conversion of the received first control signal, or another basic layer, and:

[0008] a second reflection-based layer, which is hierarchically higher than the first hardware layer and is designed to receive control signals from at least one further higher layer and to convert the control signals into the first control signals for the hardware-based layer below it, wherein the second reflection-based layer is also designed to intervene based on first scene-specific data; and / or

[0009] a third motion-based layer, which is hierarchically higher than the second reflection-based layer and is configured to receive a basis trajectory from the layer above it and to convert the basis trajectory into a second control signal for the second reflection-based layer, and wherein the third motion-based layer is also configured to intervene based on first scene-specific data; and / or

[0010] - an intent-based fourth layer configured to generate the base trajectory for the motion-based third layer based on the first scene-specific data and to transmit the base trajectory to the third layer via a third control signal (84); and / or

[0011] A fifth context-based layer, which is designed to generate a fourth control signal for the intent-based layer based on second scenario-specific data.

[0012] The basic idea of ​​the invention is to divide a hierarchical system for automated vehicles (which can be constructed as a software stack) into a plurality of layers, wherein each layer contains an "environment modeling" component for detecting the environment of the vehicle in the form of a mathematical model based on environmental data based on sensor information, and a "planning" component for planning tasks for the vehicle, such as trajectory planning. In this case, the individual layers of the hierarchical system usually run at different operating frequencies, wherein more time can be allocated to planning complex tasks (such as handling interactions with other road users) than to executing simple tasks (such as trajectory control). However, it is also conceivable that all layers or at least some layers run at the same operating frequency. The results of the planning of a layer are used as pre-set parameters for the layer directly below it. Conversely, if the results of the planning of a layer conflict with the pre-set parameters of the layer directly above it, the layer can override the pre-set parameters of the layer directly above it.

[0013] The proposed layer-based system architecture transforms from a single Perceive-Plan-Act pipeline to a robotic system consisting of different hierarchical layers with their own Perceive-Check-Plan pipelines in order to handle various tasks at different time scales and complexity levels. In two consecutive layers, the upper layer receives information from its lower layer and in turn provides control signals to its lower layer.

[0014] The advantages of the hierarchical system according to the present invention (or the proposed hierarchical architecture) stem from the fact that the autonomous driving system according to an embodiment of the present invention is divided into closed or independent parts with clear purposes, and interfaces are defined between these parts (or these layers). In particular, the hierarchical system can achieve the following advantages:

[0015] The layered architecture (Schichtenarchitektur) according to the invention defines the interfaces between these layers so that the tasks of implementing these layers can be assigned to different teams. Once each team has reached a meaningful transformation progress or implementation status (Umsetzungsstand) in its simplest form, the entire system can be stacked together (zusammengestapelt) for testing and iterative development.

[0016] The definition of interfaces allows the application of known concepts from software development. Here, it is the application of the so-called SOLID principles that can help maintain an overview of the entire software stack, which is often lost without a clear framework structure.

[0017] Subsystems from one layer downwards, combined with simplified upper layers, can already bring customer value. For example, a lane keeping system for highways with automatic speed control can be implemented with the help of the interaction layer, which provides a driving corridor (Fahrkorridor) based on the detected lanes, while the motion and reflection layers remain unchanged.

[0018] It is often easier to define system KPIs than to find meaningful component KPIs (e.g. for detection or prediction). With a multi-layer architecture, KPIs can be created for each layer or a subset of layers and these KPIs can be optimized individually (or layer-specifically). This avoids the use of system KPIs for complex processes (as they are used in unstructured architectures).

[0019] Another advantage of the hierarchical architecture on a hierarchical structure according to the invention is that each layer can be tested and compared in a simulation, wherein the other layers are simulated. In this way, suitable and application-specific requirements can be set for the simulation. For example, the simulation of the reflection layer will focus on the driving dynamics of the vehicle, but visibility can be ignored, while the interaction layer aims to provide a meaningful model for traffic behavior and vision, but simplifies driving dynamics for the simulation.

[0020] One possible embodiment of the hierarchical system provides that the scenario-specific data are generated from at least one of the following sources: sensor-based environmental perception of the vehicle, map data, aggregated environmental data from a plurality of different data sources. This has the advantage that trajectories for the vehicle are generated efficiently and context-specifically.

[0021] One possible configuration of the hierarchical system provides that, with the exception of the hardware-based first layer, each layer is designed to aggregate and model the environment of the vehicle with the aid of a modeling module, to check control signals received from other layers with the aid of a validation module, and to create a layer-specific trajectory plan for the vehicle with the aid of a planning module, wherein the layer-specific trajectory plan can be used as a predefined parameter for the layer directly below it. This has the advantage that each layer operates independently of the other layers within the hierarchical system, which in particular allows efficient task distribution and task processing at different levels of complexity.

[0022] One possible configuration of the hierarchical system provides that a layer of another directly subordinate layer is designed to override a control signal received from its directly superior layer and used as a pre-set parameter if the received control signal conflicts with a layer-specific trajectory planning. This allows cross-layer (or layer-specific) safeguard mechanisms to be implemented in an efficient manner, which increase the safety of the vehicle to be controlled.

[0023] One possible configuration of the hierarchical system provides that a first hardware-based layer is designed to process sensor-specific data of the vehicle by means of a sensor module and to provide these data to a layer located above the first hardware-based layer, to check sensor signals received from the layer above the first hardware-based layer by means of a checking module, and also to directly access the vehicle control of the vehicle in order to implement the trajectory plan transmitted to the first hardware-based layer by a second reflection-based layer located directly above the first hardware-based layer by means of an implementation module. The advantage achieved thereby is that the vehicle can be efficiently controlled.

[0024] One possible embodiment of the hierarchical system provides that the reflection-based second layer is designed to determine, based on the positioning unit, deviations between the trajectory planning transmitted by the motion-based third layer located directly above the reflection-based second layer and the layer-specific trajectory planning of the reflection-based second layer. This has the advantage that, if errors occur during trajectory planning, these can be identified and corrected before they can affect the vehicle control of the vehicle.

[0025] One possible configuration of the hierarchical system provides that the motion-based third layer is configured to create a trajectory plan for a reflection-based second layer located directly below the motion-based third layer based on an environment model implemented in the reflection-based second layer, wherein the trajectory planning of the third layer is provided for planning alternative trajectories for the vehicle, which alternative trajectories take into account safety-related, vehicle-related and / or environment-related parameters. The advantage achieved thereby is that complex trajectory planning can be carried out efficiently and at the same time the safety of the vehicle can be taken into account accordingly.

[0026] One possible configuration of the hierarchical system provides that the fourth intention-based layer is used for trajectory planning based on the first scenario-specific data, which takes into account the interaction of the vehicle with its environment. The advantage achieved by this is that efficient and more complex trajectory planning can be performed.

[0027] One possible configuration of the hierarchical system provides that the second scenario-specific data of the fifth context-based layer contain data of a driving situation of the vehicle, which extend over a longer planning time frame / planning horizon than the planning horizon used to generate the first scenario-specific data. This has the advantage that more complex trajectory planning is allowed, with the aid of which the vehicle control of the vehicle can be optimally adjusted to the corresponding vehicle environment.

[0028] One possible configuration of the hierarchical system provides that the respective safety requirements of the individual layers decrease as the hierarchy increases. The advantage achieved by this is that safety-related aspects can be implemented in the layers of the hierarchical system according to layer-specific requirements and, if necessary, can be implemented at different levels of maturity, which makes the software-related transformation or implementation of the hierarchical architecture of the hierarchical system more efficient overall.

[0029] According to a second aspect, the invention relates to a computer program product comprising machine-readable instructions which, when executed on one or more computers and / or computer instances, cause the one or more computers and / or computer instances to carry out the method according to the invention.

[0030] According to a third aspect, the invention relates to a machine-readable data carrier and / or a download product having a computer program product.

[0031] According to a fourth aspect, the invention relates to one or more computers and / or computer instances having the computer program product and / or having the machine-readable data carrier and / or download product.

[0032] The following will describe the preferred embodiments of the present invention in more detail in conjunction with the accompanying drawings, together presenting measures for further improving the invention. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] The accompanying drawings show:

[0034] Figure 1 : A schematic diagram of a hierarchical structure system according to an embodiment of the present invention. DETAILED DESCRIPTION

[0035] Figure 1 A schematic diagram of a hierarchical system 100 for a vehicle or object 120 capable of automation (or providing autonomous functions) according to one embodiment of the present invention is shown. Here, the vehicle 120 can also be generally configured as a mobile object, a mobile agent (Agent), a delivery / agricultural robot to list only a few possible application examples here.

[0036] exist Figure 1 In the embodiment of the present invention, corresponding unidirectional and / or bidirectional signal connections 61, 62, 63, 64, 65, 66, 67, 68 between the blocks 90, 92, 96, 97 of the various layers of the system 100 are also shown. These corresponding unidirectional and / or bidirectional signal connections 61, 62, 63, 64, 65, 66, 67, 68 schematically present various possible, but not limited to, signal flows between the various layers of the system 100. For the sake of clarity, the signal connections in the horizontal direction between the blocks 90-92-94 within these layers 30, 40, 50, 60 and / or the signal connections 96-97-98 within the hardware layer 20 are shown in FIG. Figure 1 No additional reference numerals are indicated.

[0037] exist Figure 1In an exemplary embodiment of the invention, the hierarchical system 100 for controlling an automated vehicle 120 has the following layers.

[0038] The hierarchical system 100 has a hardware-based first layer or first hardware layer 20 which is designed to receive a first control signal 80 and to perform a control-related conversion of the received first control signal 80 .

[0039] The hierarchical system 100 has a reflection-based second layer 30, which is hierarchically higher than the first hardware layer 20, and the reflection-based second layer 30 is constructed to receive a control signal 82 (with a base track 14), 84, 86, 88 from at least one other higher layer 40, 50, 60 and convert the control signal into a first control signal 80 for the hardware-based layer 20 below it, wherein the reflection-based second layer 30 is also constructed to intervene based on first scene-specific data 12.

[0040] The hierarchical system 100 has a third motion-based layer 40, which is hierarchically higher than the second reflection-based layer 30, and which is designed to receive a base trajectory 14 from the layer 50 above it and to convert the base trajectory 14 into a corresponding second control signal 82 for the second reflection-based layer 30, and wherein the third motion-based layer 40 is also designed to intervene based on the first scene-specific data 12. In this case, a base trajectory 14 can be understood as a first trajectory or a basic trajectory, which forms the starting point or basis for a trajectory to be further developed and represents a basic structure or basic shape for a trajectory to be further formed or further developed.

[0041] The hierarchical system 100 has an intention-based fourth layer 50 which is designed to generate a base trajectory 14 for a motion-based third layer 40 based on first scene-specific data 12 and to transmit the base trajectory 14 to the third layer 40 via a corresponding third control signal 84 .

[0042] Hierarchical system 100 has a fifth context-based layer 60 which is designed to generate a corresponding fourth control signal 86 for intention-based layer 50 based on second scenario-specific data 13 .

[0043] Figure 1 The hierarchical system or hierarchical architecture 100 in the illustrated embodiment includes the above-mentioned individual layers 20 , 30 , 40 , 50 , 60 , which are interconnected by means of signaling.

[0044] However, alternatively or optionally, the hierarchical architecture 100 can also consist of fewer than these five individual layers, or alternatively have more than these five layers. In this way, it is conceivable, for example, that the hierarchical system 100 only has a so-called base layer (Basis-Schicht), such as a hardware-based layer 20, and that a reflection-based layer 30 is additionally added thereto. The reflection-based layer 30 can also optionally be regarded as one of the base layers of the system 100. Alternatively, in addition to the hardware-based layer 20, the hierarchical architecture 100 can have at least one of the other layers 40, 50, 60. In this way, the hierarchical system 100 can be flexibly configured and can have various combinations of layers 30, 40, 50, 60 added to the hardware-based layer 20 depending on the application.

[0045] In each pair of connected layers, the upper layer receives information from the layer below it and in turn provides control signals to the lower layer.

[0046] Optionally, the first scenario-specific data 12 and the second scenario-specific data 13 may be generated by at least one of the following sources: sensor-based environmental perception of the vehicle 120 , map data, aggregated environmental data from a plurality of different data sources, which may be implemented inside or outside the vehicle.

[0047] Optionally, in addition to the hardware-based first layer 20, each individual layer 30, 40, 50, 60 is designed to: aggregate and model the environment of the vehicle 120 with the help of a modeling module 90 (= perception), check the control signals received from other layers with the help of a verification module 92 (= check), and create a layer-specific trajectory plan for the vehicle 120 with the help of a planning module 94 (= planning), which can be used as a pre-set parameter for the layer directly below this layer. In this way, a perception (Perceive)-check (Check)-plan (Plan) pipeline is formed for each layer in the hierarchical system 100. It should be mentioned here that even according to Figure 1 Each layer 30 , 40 , 50 , 60 has a module 90 , 92 , 94 of the same name, but it is clear to a person skilled in the art that the functionality behind each of these modules 90 , 92 , 94 is designed in a layer-specific manner.

[0048] The first hardware layer 20 is a special case in this framework, since it does not perform planning for the layers below it, but directly accesses the vehicle control via the so-called implementation module 98. However, the hardware layer 20 is still a component of the proposed hierarchical architecture 100, since the sensor part of this hardware layer 20 is accessible to all other layers of the hierarchical system 100. For example, sensor and actuator drivers, hardware status checks, synchronization of sensors and actuators operating at the same frequency, sensor calibration, and low-level controllers are provided in the hardware layer.

[0049] Here, according to Figure 1 The first hardware layer 20 differs from the layers above it as follows and comprises the following modules: a sensor module 96 , a checking module 97 and an implementation or conversion module 98 .

[0050] The sensor module 96 processes sensor-specific data of the vehicle 120 and provides the data to the various layers 30, 40, 50, 60 located above the first hardware layer 20 when necessary. In addition, the sensor module 96 can also detect the environment of the vehicle 120.

[0051] The sensor signals received from the layers 30, 40, 50, 60 above the first hardware layer 20, which may also represent environment model data, are checked by means of a checking module 97 before they are passed on to the vehicle control of the vehicle 120 by means of an implementation module 98. In this way, the trajectory plan passed on to the hardware layer 20 by the second reflection layer 30 directly above the first hardware layer 20 is implemented, or corresponding control signals are generated for implementing the passed on trajectory plan. In this case, the corresponding control signals may be control commands (e.g., direction changes and accelerations).

[0052] Furthermore, the system 100 has the capability that a layer 30, 40, 50 directly below another layer 40, 50, 60 is designed to override a control signal received from the layer directly above it and used as a predefined parameter if the received control signal conflicts with a layer-specific trajectory planning. It should be added that in the system 100, not every layer generates a trajectory.

[0053] Other general aspects of the hierarchical system 100 and other specific aspects of the respective layers of the hierarchical system 100 are listed below to deepen the understanding of the layer-based system.

[0054] According to Figure 1The motivation for the layer-based system architecture comes from the idea of ​​how an automated vehicle or object should be built. This first involves implementing a hardware-layer-platform that is able to control the received trajectory and, if necessary, interrupt the trajectory to prevent a collision. Then, a layer is implemented that builds a drivable path for the vehicle based on the superordinate ego plan (Ego-Plan) calculated by the higher layers. Finally, a layer is added that takes over tasks for the automated vehicle, such as defining routes or pick-up locations. In this way, a layer reduces the action space of the layers below it. In this way, these layers are made more versatile.

[0055] Here, the multi-layer system architecture allows the developed software components to be assigned to one of these layers. Here, this helps to specify the requirements and restrictions for the respective software components. In general, the proposed system architecture represents a design approach rather than an implementation concept. The hierarchical view helps to group these modules based on their tasks, their abstraction level and their system properties. This also increases the possibility of higher operating frequencies in lower layers and slower, more complex calculations in higher layers. In addition, this view of the entire system directly indicates which modules should be evaluated together and in what hierarchical structure the software stack itself can be iteratively evaluated. For example, it is conceivable that each lower layer runs at ten times the frequency of its upper layer, starting from 100 Hz in the reflection layer.

[0056] Optionally, the individual layers are designed in such a way that the respective safety requirements of the individual layers 20 , 30 , 40 , 50 , 60 decrease as the hierarchy goes up.

[0057] An important aspect of the proposed hierarchical system 100 is also to link security in each layer with responsibilities that are consistent with the focus of the corresponding layer. In this way, the requirements for security components in each layer are different, with stronger arguments and requirements for security assurance in lower layers.

[0058] In the hierarchical architecture of the proposed system 100, safety-related aspects of automated driving are addressed by a sense-check-plan structure and increasing complexity in each layer, in accordance with the requirements of ISO 21448. The lower the layer, the lower the complexity. Thus, in the hierarchical architecture of the proposed system 100, the lower layers bear the safety burden, while the safety burden steadily decreases from the hardware layer 20 to the context layer 60. In contrast, the performance steadily increases from the hardware layer 20 to the context layer 60.

[0059] In order to shoulder the burden of safety, it is important to have a checking component that checks that the input to its upper layer is valid. Since finding a solution is usually much more difficult than checking the correctness of that solution, the checking mechanism can be integrated into the lower layers.

[0060] For example, planning a comfortable and fuel-efficient trajectory in an area filled with pedestrians and cars is much more difficult than checking whether the provided input trajectory is safe. Moreover, the safety of such a checking mechanism can be more easily verified than generating the corresponding trajectory.

[0061] If the lower layer recognizes an invalid input, it discards the input and computes a fallback solution. ). By default, the fallback solution has to be calculated in a less complex way and therefore performance is traded for robustness in this limiting case. However, safety is maintained in all cases. For the above example, if a collision with an occupied grid on the input trajectory from the motion layer 40 is identified in the monitoring module of the reflection layer 30, the vehicle will fall back to the braking maneuver This security strategy is called top-down security (Top-Down-Sicherheit).

[0062] Specific aspects regarding each of the layers 30 , 40 , 50 , and 60 of the hierarchical system 100 are listed next.

[0063] 1) Reflective layer

[0064] To describe this layer in detail, it is assumed for simplicity that this layer acquires the trajectory from the layer directly above the reflective layer and drives the trajectory until this layer receives a new trajectory. Without loss of generality, it can be assumed that this layer operates at a frequency greater than or equal to its input layer, which provides the trajectory for control.

[0065] In order to bridge the gap before the new track is taken over, the reflective layer requires a so-called positioning unit, by means of which the reflective layer can track possible errors between the movement of the reflective layer and the movement required by the track.

[0066] For this purpose, for example, a simple frame-to-frame odometry may be sufficient even without being registered to the environment. This error relates to the input of the so-called trajectory tracking control, which calculates control commands for the vehicle (such as acceleration and steering angle).

[0067] In this sense, the reflection-based second layer 30 is designed to determine, based on the localization unit, deviations between the trajectory planning transmitted by the motion-based third layer 40 located directly above it and its layer-specific trajectory planning.

[0068] In addition to trajectory drives, safety concepts can also be implemented in this layer that are state-driven, i.e. a function of the current state rather than a prediction. The state-controlled aspect or reflection gives this layer its name. Safety concepts for the reflection layer only provide for braking maneuvers at objects or occupancy grids, or initiate braking maneuvers if no new trajectories have been received after a certain number of trajectory transmission cycles.

[0069] More sophisticated safety functions are implemented by higher layers.Due to the high frequencies within this reflection layer 30, a simple model with a short planning horizon (e.g., for constant acceleration) may be sufficient for object tracking, providing the perceptual information required for planning at the operating frequency.

[0070] This differs from the more sophisticated behavioral priors that can be used for object recognition and tracking in the upper layers and reduces the verification effort in the reflection layer. Safety mechanisms in this layer can include, for example, automatic emergency braking. From the perspective of the automotive industry, achieving so-called ASIL-D certification for this layer is a desired goal, as this layer has direct access to the vehicle control interface.

[0071] 2) Motion-based layers

[0072] The third layer 40 is responsible for generating trajectories for the reflective layer 30, which receives control commands from the third layer 40 above it. Trajectory generation is limited to small-scale planning (e.g., within a driving corridor) in this third layer 40. Optionally, the upper layers can provide the intentions of the autonomous vehicle and other agents, which form the basis for planning in this third layer 40. These intentions can be encoded as rough trajectories, for example.

[0073] Since the motion layer 40 works with rough predictions for the agent, it is also called predictive control. The goal of this third layer 40 is to solve a convex programming problem in which decisions about homotopy classes (=behavior patterns, such as merging in front of or behind another vehicle) are made by the upper layers.

[0074] For this purpose, the sensor detection is combined with a priori information in the form of more sophisticated motion models, for example single-track models, which have a longer planning horizon than the model in the reflection layer 30 .

[0075] Furthermore, the sensing and positioning of the kinematic layer 40 acquires the sensing and positioning information from the reflective layer 30 in order to learn the environmental model of the reflective layer 30 and to be able to adjust the trajectory commands in such a way that the reflective layer 30 does not have to compensate for the drift between the two positioning systems. This is an important prerequisite, because in this way the reflective layer 30 does not have to take into account the positioning of the kinematic layer 40, which operates at a much slower frequency.

[0076] Furthermore, it should be mentioned that the motion layer 40 has its own safety components, which are more capable than those in the reflection layer 30, because the safety components of the motion layer 40 allow planning of alternative trajectories within the driving corridor, where they can perform collision checks with the help of occupancy grids and traffic forecasts (depending on the traffic intentions received from the upper layer). In this way, not only can the brakes be applied to obstacles, but steering can also be applied and the route adjusted.

[0077] More generally, the motion-based third layer 40 is designed to create a trajectory plan for the reflection-based second layer 30 located directly below the motion-based third layer 40 based on the environment model implemented in the reflection-based second layer 30. In this case, the trajectory plan of the third layer 40 can be provided for planning a plurality of alternative trajectories for the vehicle 120, which alternative trajectories take into account safety-related, vehicle-related and / or environment-related parameters.

[0078] With this capability, the motion layer 40 can, for example, guide the vehicle 120 to the boundary of the driving path and can even achieve a crash orientation that reduces the severity of an unavoidable collision, for example by striking the front of the vehicle instead of the passenger compartment.

[0079] Since the reflective layer 30 and its much shorter foresight could intercept the plan of the moving layer 40 and thus impair the collision orientation, a so-called covering mechanism between these layers is further proposed. The overriding mechanism is provided such that the reflective layer 30 can overwrite the control signal from the motion layer 40 as long as the reflective layer 30 confirms that it conflicts with its own planning.

[0080] 3) Intent-based layer

[0081] Intent-based fourth layer 50 is designed for trajectory planning based on first scenario-specific data 12 , which takes into account the interaction of vehicle 120 with the environment of vehicle 120 . The interaction with the environment may involve other agents.

[0082] In other words, this layer 50 generates driving paths and intentions for the automated vehicle 120 and the traffic participants, for example in the form of a rough target trajectory for the automated vehicle 120 and in the form of rough predictions for the other traffic participants. The task of the intention layer 50 is to handle the interaction with the traffic and to handle visibility, i.e., the intention layer 50 must evaluate how the ego behavior of the vehicle 120 affects the perception of the traffic and the automated driving environment.

[0083] This layer 50 is therefore interactively controlled. To this end, the intention layer 50 must analyze the possible outcomes of the development of the current driving scenario and reduce this multimodality to a single, goal-oriented future (selection of homology classes) for the motion layer 40, whereby the intention layer 50 can perform its small-scale planning.

[0084] The intention layer 50 operates at a slower or equal frequency than the motion layer 40. The intention layer 50 receives control commands from the context layer 60 directly above it. These control commands may be provided, for example, in the form of routes and tactical search spaces encoded in the target and semantic prior knowledge (e.g., a child is more likely to accidentally run into the street).

[0085] To be able to handle interactions, this fourth intent layer 50 requires finer perception and localization than the motion layer 40. For this purpose, a finer tracking model than the motion layer 40 is used, and it is even possible to implement intent classification, which affects not only the motion prediction but also the tracking model.

[0086] Since the fourth intention layer 50 is responsible for handling interactions, the planning horizon of the fourth intention layer 50 is within the range of ten seconds. Therefore, the environment model must remain sufficiently consistent within this time period. For this purpose, semantics and priorities need to be used.

[0087] In addition, the perception and positioning of the intention layer 50 receives the perception and positioning information from the motion layer 40, so that the intention layer 50 obtains the environmental model of the lower layer and can adjust the driving channel and intention commands.

[0088] Therefore, the safety argument for the third intention layer 50 is also based on these components and is therefore significantly less demanding than the safety argument in the motion layer 40. While a safe maneuver in the motion layer 40 will involve planning within a corridor, the intention layer 50 may plan within a search space, for example allowing the vehicle to continue through a red light to give way to an emergency vehicle.

[0089] 4) Context-based layers

[0090] The second scenario-specific data 13 of the fifth context-based layer 60 optionally include data of a driving situation of the vehicle 120 , which relate to a planning horizon that is longer than the planning horizon used to generate the first scenario-specific data 12 .

[0091] While maintaining the established structure, the context layer 60 provides control commands to the intent layer 50. The control commands contain a search space for the intent layer 50, which is derived from the route and mission of the vehicle 120, such as driving to a destination, finding a parking space, protecting a person lying on the road from a collision with a rear vehicle, and parameters for interactive processing (e.g., different driver models for traffic in different parts of the world) or identifying anomalies in traffic behavior, such as drunk drivers or fights on the sidewalk, in which case people may run into the street.

[0092] The last two points require observation of driving conditions for a much longer period of time than the period observed by the fourth intention layer 50 to make its decisions. In addition, the context layer 60 is responsible for accumulating repeated events in order to establish semantic knowledge priorities, such as the higher frequency of pedestrians accidentally running into the street next to the school at a specific time. Therefore, the fifth context layer 60 is called the knowledge-driven layer.

Claims

1. A hierarchical system (100) for controlling an automated vehicle (120), the hierarchical system comprising: a hardware-based first layer (20) which is designed to receive a first control signal (80) and to perform a control-related conversion on the received first control signal (80), or another basic layer, and: a second reflection-based layer (30) hierarchically higher than the first hardware layer (20) and configured to receive a control signal (82, 84, 86, 88) from at least one further higher layer (40, 50, 60) and convert the control signal into the first control signal (80) for the hardware-based layer (20) below it, wherein The second reflection-based layer (30) is further configured to intervene based on the first scene-specific data (12); and / or a third motion-based layer (40) hierarchically higher than the second reflection-based layer (30), and configured to receive a base trajectory (14) from a layer (50) above it and to convert the base trajectory into a second control signal (82) for the second reflection-based layer (30), and wherein the third motion-based layer (40) is further configured to intervene based on the first scene-specific data (12); and / or - an intent-based fourth layer (50), the intent-based fourth layer being configured to generate the base trajectory (14) for the motion-based third layer (40) based on the first scene-specific data (12) and to communicate the base trajectory to the third layer (40) via a third control signal (84); and / or A fifth context-based layer (60) is configured to generate a fourth control signal (86) for the intent-based layer (50) based on the second scenario-specific data (13).

2. The hierarchical structure system (100) according to claim 1, wherein: The scenario-specific data (12, 13) is generated from at least one of the following sources: sensor-based environmental perception of the vehicle (120), map data, aggregated environmental data from a plurality of different data sources.

3. The hierarchical system (100) according to one of the preceding claims, wherein: Each of the layers (30, 40, 50, 60), except for the hardware-based first layer (20), is configured to aggregate and model the environment of the vehicle (120) with the aid of a modeling module (90), to check control signals received from other layers with the aid of a verification module (92), and to create a layer-specific trajectory plan for the vehicle (120) with the aid of a planning module (94), wherein the layer-specific trajectory plan can be used as a predefined parameter for a layer directly below the layer.

4. The hierarchical system (100) according to one of the preceding claims, wherein: A layer (30, 40, 50) directly below another layer (40, 50, 60) is designed to overwrite control signals received from a layer directly above it and used as predefined parameters if the received control signals conflict with a layer-specific trajectory plan.

5. The hierarchical system (100) according to one of the preceding claims, wherein: The hardware-based first layer (20) is designed to: process sensor-specific data of the vehicle (120) with the help of a sensor module (96) and provide the sensor-specific data to a layer (30, 40, 50, 60) located above the hardware-based first layer, check sensor signals received from the layer (20, 30, 40, 50) above the hardware-based first layer with the help of a check module (97), and also directly access the vehicle control of the vehicle (120) in order to implement a trajectory planning transmitted by the reflection-based second layer (30) located directly above the hardware-based first layer with the help of an implementation module (98).

6. The hierarchical system (100) according to one of the preceding claims, wherein: The reflection-based second layer (30) is designed to determine, based on a localization unit, a deviation between a trajectory plan transmitted by the motion-based third layer (40) located directly above the reflection-based second layer and a layer-specific trajectory plan of the reflection-based second layer.

7. The hierarchical system (100) according to one of the preceding claims, wherein: The motion-based third layer (40) is configured to create a trajectory plan for the reflection-based second layer (30) located directly below the motion-based third layer based on an environment model implemented in the reflection-based second layer (30), wherein the trajectory planning of the third layer (40) is configured to plan an alternative trajectory for the vehicle (120), the alternative trajectory taking into account safety-related, vehicle-related and / or environment-related parameters.

8. The hierarchical system (100) according to one of the preceding claims, wherein: The fourth intent-based layer (50) is configured to perform trajectory planning based on the first scenario-specific data (12), the trajectory planning taking into account the interaction of the vehicle (120) with its environment.

9. The hierarchical system (100) according to one of the preceding claims, wherein: The second scenario-specific data (13) of the fifth context-based layer (60) contain data of a driving condition of the vehicle (120), which extend over a longer planning horizon than the planning horizon used to generate the first scenario-specific data (12).

10. The hierarchical system (100) according to one of the preceding claims, wherein: The respective security requirements of the various layers (20, 30, 40, 50, 60) decrease as one goes up the hierarchy.

11. A computer program product comprising machine-readable instructions which, when executed on one or more computers and / or computer instances, cause the one or more computers and / or computer instances to implement the method according to any one of claims 1 to 10.

12. A machine-readable data carrier and / or a download product having a computer program product according to claim 11.

13. One or more computers and / or computer instances having a computer program product according to claim 11 and / or having a machine-readable data carrier and / or a download product according to claim 12.

Images