[go: up one dir, main page]

WO2023036545A1 - Verfahren und steuerschaltung zum überprüfen, ob ein aktuell aktiver fahrmodus innerhalb seiner odd betrieben wird, sowie system und backend-server - Google Patents

Verfahren und steuerschaltung zum überprüfen, ob ein aktuell aktiver fahrmodus innerhalb seiner odd betrieben wird, sowie system und backend-server Download PDF

Info

Publication number
WO2023036545A1
WO2023036545A1 PCT/EP2022/072444 EP2022072444W WO2023036545A1 WO 2023036545 A1 WO2023036545 A1 WO 2023036545A1 EP 2022072444 W EP2022072444 W EP 2022072444W WO 2023036545 A1 WO2023036545 A1 WO 2023036545A1
Authority
WO
WIPO (PCT)
Prior art keywords
odd
vehicle
driving mode
features
measured
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Ceased
Application number
PCT/EP2022/072444
Other languages
English (en)
French (fr)
Inventor
Mohamed Essayed Bouzouraa
David Alexander Badouin
Endre Aladar Papp
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Cariad SE
Original Assignee
Cariad SE
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Cariad SE filed Critical Cariad SE
Priority to US18/689,049 priority Critical patent/US20240400111A1/en
Publication of WO2023036545A1 publication Critical patent/WO2023036545A1/de
Anticipated expiration legal-status Critical
Ceased legal-status Critical Current

Links

Classifications

    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W60/00—Drive control systems specially adapted for autonomous road vehicles
    • B60W60/005—Handover processes
    • B60W60/0053—Handover processes from vehicle to occupant
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2420/00—Indexing codes relating to the type of sensors based on the principle of their operation
    • B60W2420/40—Photo, light or radio wave sensitive means, e.g. infrared sensors
    • B60W2420/403—Image sensing, e.g. optical camera
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • B60W2556/50—External transmission of data to or from the vehicle of positioning data, e.g. GPS [Global Positioning System] data
    • B—PERFORMING OPERATIONS; TRANSPORTING
    • B60—VEHICLES IN GENERAL
    • B60W—CONJOINT CONTROL OF VEHICLE SUB-UNITS OF DIFFERENT TYPE OR DIFFERENT FUNCTION; CONTROL SYSTEMS SPECIALLY ADAPTED FOR HYBRID VEHICLES; ROAD VEHICLE DRIVE CONTROL SYSTEMS FOR PURPOSES NOT RELATED TO THE CONTROL OF A PARTICULAR SUB-UNIT
    • B60W2556/00—Input parameters relating to data
    • B60W2556/45—External transmission of data to or from the vehicle
    • B60W2556/65—Data transmitted between vehicles

Definitions

  • the invention relates to a method and a control circuit for checking whether a currently active automated and/or assisted driving mode of a vehicle that is driving along a route using the driving mode is within the ODD limit of an operational design domain specified for the driving mode , ODD, the driving mode is operated. If the vehicle leaves the ODD, the driving mode must be deactivated.
  • the invention also includes a backend server and a system.
  • An Operational Design Domain is a specific operational domain or set of operational domains in which an automated driving function or system is intended to function properly, including but not limited to road types, speed range, environmental conditions (e.g. weather, time of day/night) and /or driving situations, in each case, for example, delimited by domain restrictions (ODD limit).
  • ODD limit is given by all those places and/or driving situations where there is an ODD feature that prohibits the use of an automated and/or assisted driving mode. If, for example, the driving mode is not intended for the automated operation of the vehicle at a traffic light, a traffic light represents an ODD feature that marks the ODD limit of the driving mode, i.e.
  • the driving mode should be deactivated , because the ODD limit has been reached.
  • Automated and/or assisted driving modes in particular driving modes of HAF driving systems (HAF - highly automated driving mode, i.e. so-called automation level L3 or higher), must be able to independently recognize their functional limits or challenging situations (in short, the ODD). This can be solved using environmental sensors but also map-based.
  • the disadvantage here is that the detection cannot take place sufficiently early in all cases, particularly in the case of short-term changes in the ODD conditions. It can happen that the remaining distance from detection until the ODD limit is exceeded is not sufficient to a) hand over the driving task to the driver at level L3 and give him the chance of an appropriate reaction or b) at level L4 ensure an appropriate solution to the situation by treating or striving for a qualified safe condition.
  • map data can be generated by means of motor vehicles by measuring the environment in order to make these map data available to other motor vehicles, which can use them to operate their automated driving modes.
  • this requires a corresponding expenditure of time in order to first acquire sufficient map data of an environment before sufficient map data is available stand.
  • a navigation system of a motor vehicle can configure route planning such that the largest possible proportion of a route lies within an ODD of an autonomous driving mode, so that the motor vehicle can drive autonomously.
  • route planning such that the largest possible proportion of a route lies within an ODD of an autonomous driving mode, so that the motor vehicle can drive autonomously.
  • a spontaneous event occurs while driving, such as a traffic jam, the autonomously driving motor vehicle must recognize for itself that an ODD limit may have been reached.
  • the invention is based on the object of an active driving mode for an automated and / or assisted driving approaching an ODD limit of the ODD of the driving mode to recognize in good time or early to have enough time to deactivate the driving mode before the ODD limit is reached to have.
  • the invention includes a method for checking whether a currently active automated and/or assisted driving mode of a vehicle that is driving along a route using this driving mode is within the ODD limit of an operational design domain specified for the driving mode , ODD, the driving mode is operated.
  • a measurement of predetermined ODD features, which mark the ODD limit is carried out in an environment or in an area surrounding the vehicle by means of at least one environment sensor. It is therefore actively sought or sensed whether the ODD limit can be recognized on the basis of ODD features.
  • an ODD monitoring routine is used to check a predetermined limit criterion which indicates whether the vehicle is moving towards an ODD limit and is therefore about to leave the ODD.
  • An ODD limit can also result from the fact that predetermined ODD attributes are missing, ie such attributes that are expected to result within the ODD are no longer present or are not present. So the lack of ODD attributes can also be interpreted as an ODD feature for an ODD limit.
  • An automated driving mode can provide that a longitudinal guidance and/or a lateral guidance of the vehicle is carried out automatically, ie without the intervention of a driver, by a control circuit controlling an actuator of the vehicle for the longitudinal guidance and/or lateral guidance.
  • An assisted driving mode can offer assistance and/or information to a driver when driving the vehicle, for example providing assisted overtaking and/or parking.
  • the limit criterion for the detection of the ODD limit can be set by those skilled in such a way that all those ODD features, such as a traffic light and / or a traffic sign and / or a predetermined arrangement of other vehicles in the area, from the ODD monitoring routine as a ODD limit are detected, which are relevant for the driving mode.
  • the person skilled in the art can define appropriate descriptions for this in the ODD monitoring routine as required.
  • the ODD monitoring routine can be executed by a processor circuit. It can be designed, for example, as software for the processor circuit.
  • the solution according to the invention strives to detect the ODD limit as early as possible and/or at a distance from the host vehicle in order to have enough time for deactivating the driving mode until the ODD limit is reached.
  • the measurement of the ODD features is carried out by means of at least one other vehicle driving ahead of the vehicle on the route and by a backend server, which couples the at least one other vehicle to the vehicle via respective communication links, the measured feature data of the ODD features are collected and/or the ODD monitoring routine is performed.
  • the vehicle uses at least one other vehicle driving ahead to carry out the measurement of ODD features in the environment. This means that the measurement of ODD features is brought forward according to the distance from the other vehicle driving in front.
  • the communication i.e.
  • V2X communication V2X - vehicle-to-X communication, where X stands for a communication device in a vehicle or a stationary infrastructure object of a road network).
  • the method uses sensor inputs or measurement channels from at least one other vehicle driving ahead in order to carry out the measurement of ODD features at an early stage or at a distance from the vehicle.
  • a traffic light can be detected by a vehicle driving ahead as an ODD feature and signaled to the backend server as an ODD feature.
  • the backend server can be implemented, for example, as a computer or a computer network of the Internet.
  • Another vehicle can be a motor vehicle that is different from the vehicle whose driving mode is monitored by the method, that is to say another road user, for example a passenger car or truck.
  • the invention provides the advantage that the vehicle can also recognize such ODD features early or in advance that have arisen or appeared in the area at short notice, such as a damaged traffic sign and/or a traffic light that has failed and/or a traffic jam.
  • At least one third-party vehicle can also be used here, which can itself be driven by a person, ie does not have to have an active driving mode itself. A third-party vehicle therefore only has to meet minor technical requirements.
  • the vehicle and the at least one other vehicle driving ahead form a convoy in that these vehicles are preferably traveling at the same time or are driving on the route.
  • the invention also includes embodiments that result in additional advantages.
  • One embodiment includes signaling at least some of the measured ODD features as a recording of a sensor signal, in particular a video signal, and as metadata, in particular a position indication of a position of the ODD feature and/or an orientation indication of a spatial orientation of the ODD feature become.
  • the other vehicle itself does not have to interpret whether a valid or relevant ODD feature was actually detected.
  • the other vehicle only has to provide the sensor signal that detects or signals a possible ODD feature.
  • the position of this measured ODD feature and/or its orientation for example as an indication of a cardinal point or a direction of travel or an angle specification with respect to a reference angle.
  • the orientation specification defines, for example, the direction in which the ODD feature points, so that, for example, an orientation of a traffic light and/or a traffic sign is signaled.
  • objects of a certain object type e.g. traffic signs of a specified type of sign, e.g. hazard warnings
  • a corresponding trigger or trigger can be set in the third-party vehicle, which upon detection of an object for which the third-party vehicle is responsible Object type is detected, the sensor signal, for example, a camera, are recorded and as a measured ODD feature (including the metadata) are signaled to the backend server.
  • An object and its object type can be recognized in a third-party vehicle in a manner known per se using a machine learning method (eg traffic sign recognition using computer vision).
  • object detection can be operated in the other vehicle in a manner known per se, which is detected, for example, on the basis of a model for machine learning, for example an artificial neural network, using at least one sensor signal.
  • the described video signal and/or a radar signal and/or a LIDAR signal can be used as the sensor signal.
  • a signal section or signal area e.g. image area
  • an object of a known object class e.g.
  • this model can then be followed by a filter, for example, which sends or reports such recognized objects, for example, to the backend server or the vehicle, which are searched for as ODD features.
  • a filter for example, which sends or reports such recognized objects, for example, to the backend server or the vehicle, which are searched for as ODD features.
  • the vehicle transmits ODD parameters, which describe the ODD limits valid for the driving mode and/or the ODD characteristics to be measured, from which the ODD limits can be recognized, to the backend server and/or or sent to at least one other vehicle and the measurement and/or the ODD monitoring routine is configured using the ODD parameters. This limits the measurement and/or the monitoring routine to the ODD limits that apply to the driving mode.
  • the vehicle can thus provide information about the ODD features and/or ODD limits to be measured. If only an ODD limit (instead of the associated ODD features) is signaled by the ODD parameters, a list of associated ODD features can be provided for each ODD limit, for example in the backend server or in the respective third-party vehicle. For example, a list can be provided which assigns associated ODD features to an ODD limit. If, for example, a motorway is specified as the ODD (driving mode may only be operated on the motorway), the ODD limit is exits and parking lots and gas stations.
  • Corresponding ODD features ie, for example, exit signs, exits with a corresponding roadway curvature, traffic signs of a specified color, can then be detected as ODD features that mark this ODD limit.
  • the ODD monitoring routine can, for example, determine which route ahead is planned for the vehicle and then recognize whether the planned route will intersect the ODD limit determined using the ODD features, ie the ODD will probably be left.
  • a handover action to deactivate the driving mode can then be triggered.
  • Route data of the route can be received, for example, from a navigation system of the motor vehicle and/or a navigation function of the backend server that supports the motor vehicle in navigating.
  • the route can also be estimated, for example based on historical route profiles, in that a route that has been traveled repeatedly can be selected as the estimated route.
  • An embodiment includes that in the event that an ODD feature is detected by the other vehicle and the other vehicle is being guided by a person in a manual driving mode, a guidance profile of a person when approaching and/or passing the ODD feature carried out longitudinal guidance and / or transverse guidance is detected as a guidance profile and the guidance profile is specified to the driving mode as a driving mode to be simulated in the vehicle by the driving profile.
  • the driving behavior of a stranger in the foreign vehicle can thus be used to determine control signals for the vehicle that specify suitable behavior of the vehicle at the ODD limit.
  • the driving mode can thus be upgraded or expanded by simulating the guidance profile in such a way that it can also continue to be operated at the ODD limit, i.e. the ODD is dynamically expanded if a suitable guidance profile could or was recorded by a person.
  • the backend server generates a vehicle-specific environment map of the ODD for the driving mode of the vehicle using the collected ODD features and using the limit criterion and is provided to the vehicle for future route planning.
  • Software can be operated in the backend server, for example, which checks the measured ODD features to determine whether they are valid or correct ODD features that actually mark the ODD limit. In this way, false recognitions or false detections can be compensated.
  • the respective position of the collected ODD features can then be used to detect or recognize where the ODD limit runs. This can then be mapped in the environment map, so that in the vehicle the driving mode or the driving function or route planning can take into account the ODD or the course of the ODD limit when planning a route or trajectory.
  • the presumed limit of the ODD determined on the basis of the collected ODD characteristics is thus checked. This can support the early deactivation of the driving mode and/or result in a driving recommendation to change the driving mode to be able to operate on routes that are as long as possible when a specified destination is reached.
  • One embodiment includes the backend server outputting the measured ODD features to an operator via a user interface and receiving user input from the operator and determining whether the ODD feature meets the limit criterion depending on the user input.
  • the interpretation or the recognition or evaluation of a measured ODD feature can thus be carried out by an operator in the backend server.
  • This has the advantage that such ODD features can also be checked for which an automated evaluation fails due to, for example, a signal quality of the sensor signal and/or due to the appearance of the ODD feature, for example dirt on a traffic sign.
  • the ODD feature can be presented to the operator "in the loop" or in real time, so that another vehicle driving ahead signals the measured ODD feature to the backend server, where the measured ODD feature of the operator is displayed (if, for example, a automated evaluation signals an error or a detection confidence is lower than a threshold value) and then upon detection of a permissible ODD feature that meets the limit criterion or indicates the ODD limit, this is signaled to the vehicle.
  • a human plausibility check can thus be integrated into the processing chain for processing measured ODD features for checking the limit criterion.
  • the user input may be a binary indication that the feature is to be ignored or not.
  • One embodiment includes that in the event that the limit criterion is not met by a measured ODD feature, masking data signaling that this ODD feature is to be ignored is generated and sent to the vehicle and an ODD monitoring routine of the vehicle using of the masking data is configured so that when the ODD feature is detected, it is ignored by the vehicle's ODD monitoring routine.
  • the masking data can be used to prevent the vehicle itself from misinterpreting the ODD feature using its own object detection.
  • an ODD feature is signaled by the other vehicle, then at least once an object detection has already erroneously recognized an ODD feature, although the limit criterion then turns out that it does not mark an ODD limit. This can be the case, for example, when a traffic light is shown on an advertising poster and traffic lights are sought as ODD features. If, for example, the operator already described uses the user input to specify that the traffic light on the factory poster is not a valid ODD feature, the masking data can be used to inform the vehicle of this, so that its own object detection for recognizing ODD features is not also deceived or generates false output signals erroneously signaling a valid ODD feature when the vehicle itself approaches or passes the ODD feature.
  • One specific embodiment includes the other vehicle measuring the ODD characteristics when there is no own driving mode or when the own driving mode is deactivated and/or activated. In other words, it is not necessary for the respective third-party vehicle itself to have the driving mode. It is sufficient if the other vehicle detects sensor signals, for example video signals from a camera, and then checks whether a searched ODD feature, for example a traffic sign or a traffic light, is recognized. If the third-party vehicle has the driving mode itself, it does not have to be active. It is thus also possible to use third-party vehicles using the method that did not have to deactivate their driving mode themselves at an ODD limit that was only recognizable for a short time, for example.
  • An embodiment includes that in the vehicle when approaching an ODD limit and imminent leaving the ODD, a predetermined handover measure to deactivate the driving mode and Passing the longitudinal guidance and / or lateral guidance of the vehicle is carried out to a driver.
  • the vehicle can thus deactivate the driving mode by handing over to a driver while driving or by driving the vehicle to a parking space in front of the ODD limit, for example, and interrupting the journey there.
  • a handover measure can generally be used, as is known for automated driving modes in the prior art.
  • the invention includes a control circuit for a vehicle.
  • the control circuit is set up to provide an automated and/or assisted driving mode for the vehicle and ODD parameters which describe ODD limits of an ODD of the driving mode that are valid for the driving mode and/or ODD features to be measured which mark the ODD limits , to a backend server and/or to at least one other vehicle and to receive from the backend server and/or the at least one other vehicle measured ODD features and/or map data of ODD limits of the ODD estimated from measured ODD features and thus restricting operation of the driving mode to the ODD applicable to the driving mode (when an approach to an ODD limit is detected). This can be done using the ODD monitoring routine.
  • the vehicle is preferably designed as a motor vehicle, in particular as a passenger car or truck, or as a passenger bus or motorcycle.
  • the control circuit can be designed, for example, as a control unit or a combination of control units for a vehicle.
  • the control circuit can have a data processing device or a processor device that is set up to carry out the method steps described.
  • the control circuit can have at least one microprocessor and/or at least one microcontroller and/or at least one FPGA (Field Programmable Gate Array) and/or at least one DSP (Digital Signal Processor).
  • the control circuit can have program code which is set up to carry out the method steps when executed by the processor device to perform.
  • the program code can be stored in a data memory of the control circuit.
  • the invention includes a backend server for a vehicle with an automated and/or assisted driving mode.
  • the backend server is set up to receive and receive from the vehicle via a communication link ODD parameters that describe ODD limits of an ODD of the driving mode that are valid for the driving mode and/or ODD features to be measured that mark the ODD limits to control at least one other vehicle driving ahead of the vehicle to measure the ODD features via a respective communication connection and to transmit the measured ODD features and/or map data of ODD limits of the ODD estimated from measured ODD features to the vehicle.
  • the backend server can comprise a computer or a combination of several computers.
  • the backend server can be operated as a server of the Internet.
  • the respective communication connection to another vehicle or the vehicle can be implemented in the manner described as radio-based and/or based on an Internet connection.
  • the ODD parameters can then indicate which ODD features or which ODD boundary (e.g. the edge of a freeway area) is to be searched for.
  • Corresponding detection commands or measurement commands for at least one ODD feature can then be sent to at least one other vehicle, which can then signal ODD features measured as measurement results.
  • Route data and/or a geoposition and direction of travel of the other vehicle can be used to determine whether another vehicle is on a route section ahead of the vehicle, ie whether another vehicle represents a vehicle driving ahead.
  • the invention comprises a system comprising an embodiment of the backend server according to the invention and at least one vehicle with an embodiment of the invention control circuit.
  • the system thus includes the interaction of the backend server and at least one vehicle in order to carry out an embodiment of the method according to the invention.
  • the invention also includes the combinations of features of the described embodiments.
  • the invention also includes implementations that each have a combination of the features of several of the described embodiments, unless the embodiments were described as mutually exclusive.
  • FIG. 1 shows a schematic representation of an embodiment of the system according to the invention, which can carry out an embodiment of the method according to the invention.
  • the figure shows a system 10 with a backend server 11 and a vehicle 12 as a motor vehicle, in particular as a passenger car or truck, can be designed.
  • the vehicle 12 may be operated on a road 13 , which may be a freeway 14 in this example.
  • the vehicle 12 can be operated in an automated driving mode F, for example a HAF or highly automated driving mode, by means of a control circuit 15 .
  • a corresponding driving function can be implemented by an autopilot, for example.
  • Driving mode F can be limited to predetermined driving situations, resulting in an ODD for driving mode F, within which driving mode F may only be active. For example, it can be defined as an ODD that driving mode F is only permitted in the area of freeway 14 as long as predetermined driving conditions exist on freeway 14, for example, there is no construction site.
  • the backend server 11 can be connected to a communication unit 16 of the vehicle 12 via a communication link 17, which can be routed, for example, as a radio link via a mobile radio network 18 and can lead via an Internet connection 19 to the Internet 20, in which the backend server 11 can be operated.
  • a communication unit 16 can be implemented, for example, on the basis of a mobile radio module and/or WIFI module.
  • At least one sensor 21 can be operated in the vehicle 12 in a manner known per se, the detection range 22 of which is aligned in an environment 23 of the vehicle 12 can.
  • the at least one sensor 21 can be used by the control circuit 15 to determine whether an ODD feature 24 is present, which signals that an ODD limit 25 of the ODD has been reached or is present, within which the driving mode F can only be active.
  • exemplary ODD boundaries are a traffic sign 26 signaling that an exit 27 leading off the highway 14 is present.
  • a Another possible ODD feature 24 can be a curve 28 whose curve radius 29 is smaller than a permissible limit value for driving mode F.
  • Another ODD feature 24 may be a construction site 30 that may have been constructed on the freeway 14 and thus in the area of the construction site
  • an ODD feature 24 for the vehicle 12 can only be detected within the maximum range by means of the respective sensor 21
  • At least one other vehicle 32 is used by means of the backend server 11 to detect ODD features 24 that indicate the ODD limit 25 or mark it.
  • the control circuit 15 can send ODD parameters 33 to the backend server via the communication unit 16
  • the backend server 11 can send the ODD parameters 33 or measurement commands or detection commands derived therefrom to the other vehicles 32 .
  • a communication unit 34 , a control device 35 and at least one sensor 36 with a detection area 37 oriented towards the surroundings 23 can be provided or used in each third-party vehicle.
  • the control device 35 in each third-party vehicle 32 can also detect or measure ODD features 24.
  • External vehicles 32 are preferably selected by the backend server 11 whose position and/or route indicates that external vehicles are driving in front of the vehicle 12
  • a position signal 38 can be used, for example, from a global navigation satellite system GNS, for example the GPS (Global Positioning System), which can be used in the vehicle 12 and the respective third-party vehicle 32 to be received by a receiver for the position signal 38 and thus the position of the respective vehicle 12 and the to determine the respective third-party vehicle 32 and, for example, to signal the backend server 11 via the communication links 17, 39.
  • GNS global navigation satellite system
  • GPS Global Positioning System
  • the corresponding sensor 36 Since it is another vehicle 32 driving ahead, the corresponding sensor 36 is also arranged in front of the vehicle 12 in the direction of travel and is therefore beyond the maximum range 31 of the sensor 21 of the vehicle 12 itself. This means a gain in time and/or distance in that there is a lead 40 an ODD feature 24 can already be received by another vehicle 32 even before an ODD feature 24 can be detected by means of the at least one sensor 21 of the vehicle 12 itself. Accordingly, there is time available to deactivate driving mode F when approaching ODD limit 25 marked by ODD feature 24 .
  • an object detection can be operated, by means of which it can be determined on the basis of a sensor signal of the respective sensor signal 41 of the respective sensor 36 which objects in the sensor signal 41 from the environment 23 have been detected or have been detected. If one of these detected objects falls into a recognition scheme or recognition pattern corresponding to the ODD feature sought, as can be specified by the ODD parameters 33, a measured ODD feature 43 can be signaled to the backend server 11 from the respective third-party vehicle 32 , i.e. characteristic data of a measurement result are signaled.
  • an ODD monitoring routine 50 can check in the control circuit 15 whether a planned travel trajectory 51 will cross the ODD limit 25 that lies ahead of the vehicle 12 on the basis of the ODD features 43 . If this is the case, driving mode F can be deactivated and a handover measure can be triggered for this in a manner known per se, for example the driver of vehicle 12 can be requested to carry out the so-called driving task, i.e. longitudinal guidance and/or lateral guidance, which was previously carried out by the activated driving mode F was carried out. Since this is done with the projection 40, there is more time to carry out the handover measure than if the ODD features 24 were only detected by means of the at least one sensor 21 of the vehicle 12 itself. The projection 40 is larger than the maximum range 31 of the at least one sensor 21 .
  • Vehicles driving ahead with properties comparable to those of the HAF system are preferably used in order to carry out a measurement of the ODD in terms of the subsequent HAF system, ie vehicles that also have the driving mode. All vehicles suitable for the measurement are provided with the necessary information about the ODD limits to be measured. This can be done, for example, via a radio link from a central backend.
  • Information about the presumed ODD limit and a recommendation for handling each HAF system can be stored on the server be enriched. Human plausibility checks are also conceivable.
  • a digital map with this information can be used on an HAF system and used there to better deal with (potential) ODD limits (early deactivation or deliberate ignoring).
  • the (bidirectional) exchange of ODD information can be provided.
  • the receiving vehicle sends information about its specific ODD limits to the backend, which creates a vehicle-specific ODD map for the vehicle by appropriately coupling the input data from data-collecting vehicles.
  • the detection range for ODD features is increased, improving the system's response to ODD limits.

Landscapes

  • Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Human Computer Interaction (AREA)
  • Transportation (AREA)
  • Mechanical Engineering (AREA)
  • Traffic Control Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Multimedia (AREA)
  • Theoretical Computer Science (AREA)

Abstract

Die Erfindung betrifft ein Verfahren zum Überprüfen, ob ein aktuell aktiver automatisierter und/oder assistierter Fahrmodus eines Fahrzeugs (12), das mittels des Fahrmodus eine Fahrt entlang einer Fahrtroute durchführt, innerhalb der für den Fahrmodus vorgegebenen ODD-Grenze (25) einer Operational-Design-Domäne, ODD, des Fahrmodus betrieben wird, wobei mittels zumindest eines Umfeldsensors (36) in einer Umgebung (23) des Fahrzeugs (12) eine Messung von vorbestimmten ODD-Merkmalen (24), welche die ODD-Grenze (25) markieren, durchgeführt wird. Die Erfindung sieht vor, dass die Messung mittels zumindest eines auf der Fahrroute dem Fahrzeug (12) vorausfahrendes Fremdfahrzeug (32) durchgeführt wird und durch einen Backend-Server (11), der das zumindest eine Fremdfahrzeug (32) mit dem Fahrzeug (12) über jeweilige Kommunikationsverbindungen (17, 39) koppelt, die gemessenen ODD-Merkmale (24) gesammelt werden und/oder die ODD-Überwachungsroutine (50) durchgeführt wird.

Description

Verfahren und Steuerschaltung zum Überprüfen, ob ein aktuell aktiver Fahrmodus innerhalb seiner ODD betrieben wird, sowie System und Backend-Server
BESCHREIBUNG:
Die Erfindung betrifft ein Verfahren und eine Steuerschaltung zum Überprüfen, ob ein aktuell aktiver automatisierter und/oder assistierter Fahrmodus eines Fahrzeugs, das mittels des Fahrmodus eine Fahrt entlang einer Fahrtroute durchführt, innerhalb der für den Fahrmodus vorgegebenen ODD-Grenze einer Operational-Design-Domäne, ODD, des Fahrmodus betrieben wird. Verlässt das Fahrzeug die ODD, muss der Fahrmodus deaktiviert werden. Zu der Erfindung gehören auch ein Backend-Server und ein System.
Eine Operational Design Domain (ODD) ist eine spezifische Betriebsdomäne oder eine Gruppe von Betriebsdomänen, in der eine automatisierte Fahrfunktion oder ein automatisiertes System ordnungsgemäß funktionieren soll, einschließlich, aber nicht beschränkt auf Straßentypen, Geschwindigkeitsbereich, Umgebungsbedingungen (z.B. Wetter, Tages- ZNachtzeit) und/oder Fahrsituationen, jeweils z.B. abgegrenzt durch Domäneneinschränkungen (ODD-Grenze). Die ODD-Grenze ist durch all diejenigen Orte und/oder Fahrsituationen gegeben, an denen sich ein ODD- Merkmal befindet, das den Einsatz eines automatisierten und/oder assistierten Fahrmodus verbietet. Ist der Fahrmodus z.B. nicht für den automatisierten Betrieb des Fahrzeugs an einer Ampel vorgesehen, so stellt entsprechend eine Ampel ein ODD-Merkmal dar, das die ODD-Grenze des Fahrmodus markiert, d.h. bei Erreichen oder Passieren eines ODD-Merkmals sollte der Fahrmodus deaktiviert sein, weil die ODD-Grenze erreicht ist. Automatisierte und/oder assistierte Fahrmodi, insbesondere Fahrmodi von HAF-Fahrsystemen (HAF - hoch-automatisierter Fahrmodus, d.h. sogenannter Automatisierungs-Level L3 oder höher), müssen ihre Funktionsgrenzen oder herausfordernde Situationen (zusammengefasst die ODD) selbstständig erkennen können. Dies wird kann umfeldsensorisch aber auch kartenbasiert gelöst werden.
Nachteilig dabei ist, dass die Erkennung insbesondere bei kurzfristiger Änderung der ODD-Bedingungen nicht in allen Fällen ausreichend früh erfolgen kann. Dabei kann es dazu kommen, dass der verbleibende Weg ab Erkennung bis zur Überschreitung der ODD-Grenze nicht ausreicht, um a) im Level L3 dem Fahrer die Fahraufgabe zu übergeben und ihm die Chance auf eine angemessene Reaktion zu geben oder b) im Level L4 eine geeignete Lösung für die Situation durch Behandlung oder Anstreben eines qualifizierten sicheren Zustands sicherzustellen.
Aus der DE 10 2013 210 395 B4 ist bekannt, dass Fahrzeuge mit automatisierten Fahrmodi das Erreichen einer ODD-Grenze sensorbasiert erkennen und daraufhin den Fahrmodus deaktivieren können. Durch einen zentralen Backend-Server können all diejenigen Orte abgefragt werden, an denen eine solche Deaktivierung des Fahrmodus aufgrund einer Detektion einer ODD-Grenze erfolgte. Daraus kann eine digitale Straßenkarte erstellt werden, in welcher die ODD-Grenzen verzeichnet sind. Nachteilig bei dieser Lösung ist, dass die abgefragten Fahrzeuge zunächst selbst an die noch unbekannte ODD-Grenze heranfahren müssen und dadurch diese Fahrzeuge in die oben beschriebene Situation geraten können, dass nur wenig Zeit für das Deaktivieren des Fahrmodus verbleibt.
Aus der EP 3 745 376 A1 ist bekannt, dass mittels Kraftfahrzeugen Kartendaten durch Vermessen der Umgebung erzeugt werden können, um diese Kartendaten anderen Kraftfahrzeugen bereitzustellen, die damit ihre automatisierten Fahrmodi betreiben können. Dies erfordert aber einen entsprechenden zeitlichen Aufwand, um zunächst genügend Kartendaten einer Umgebung zu erfassen, bevor ausreichend Kartendaten zur Verfügung stehen. Zudem kann auf Grundlage solcher Kartendaten nicht auf akute Sonderfälle, wie beispielsweise einen entstandenen Stau, reagiert werden.
Aus der US 2020/0241564 A1 ist bekannt, dass ein Navigationssystem eines Kraftfahrzeugs eine Routenplanung dahingehend konfigurieren kann, dass ein möglichst großer Anteil einer Fahrroute innerhalb einer ODD eines autonomen Fahrmodus liegt, sodass die Fahrt durch das Kraftfahrzeug autonom durchgeführt werden kann. Ereignet sich während der Fahrt allerdings ein spontanes Ereignis, wie beispielsweise ein Verkehrsstau, so muss das autonom fahrende Kraftfahrzeug selbst erkennen, dass eventuell eine ODD-Grenze erreicht wird.
Aus der DE 10 2021 001 096 A1 ist bekannt, in einer digitalen Straßenkarte solche Straßenobjekte zu kartographieren, die durch Sensoren nicht identifiziert werden können. Solche nicht-identifizierbaren Straßenobjekte werden als ODD-Grenze zum Deaktivieren eines Fahrmodus interpretiert. Auch hier besteht das Problem, dass die ersten Fahrzeuge, die an diesen nicht-identifizierbaren Straßenobjekten vorbeifahren, selbst nicht vorgewarnt werden können.
Aus der US 2019/0184997 A1 ist bekannt, wie ein Kraftfahrzeug einen automatisierten Fahrmodus abschalten kann, falls eine ODD-Grenze erreicht wird oder sich das Fahrzeug der ODD-Grenze nähert.
Der Erfindung liegt die Aufgabe zugrunde, bei einem aktiven Fahrmodus für eine automatisierte und/oder assistierte Fahrt das Annähern an eine ODD- Grenze der ODD des Fahrmodus rechtzeitig oder frühzeitig zu erkennen, um genügend Zeit für das Deaktivieren des Fahrmodus vor Erreichen der ODD- Grenze zu haben.
Die Aufgabe wird durch die Gegenstände der unabhängigen Patentansprüche gelöst. Vorteilhafte Ausführungsformen der Erfindung sind durch die abhängigen Patentansprüche, die folgende Beschreibung sowie die Figur beschrieben. Als eine Lösung umfasst die Erfindung ein Verfahren zum Überprüfen, ob ein aktuell aktiver automatisierter und/oder assistierter Fahrmodus eines Fahrzeugs, das mittels dieses Fahrmodus eine Fahrt entlang einer Fahrtroute durchführt, innerhalb der für den Fahrmodus vorgegebenen ODD- Grenze einer Operational-Design-Domäne, ODD, des Fahrmodus betrieben wird. Mittels zumindest eines Umfeldsensors wird in einer Umgebung oder in einem Umfeld des Fahrzeugs eine Messung von vorbestimmten ODD- Merkmalen, welche die ODD-Grenze markieren, durchgeführt. Es wird also aktiv gesucht oder sensiert, ob die ODD-Grenze anhand von ODD- Merkmalen erkannt werden kann. Anhand der gemessenen ODD-Merkmale wird mittels einer ODD-Überwachungsroutine ein vorbestimmtes Grenzkriteriums überprüft, das angibt, ob sich das Fahrzeug auf eine ODD- Grenze zubewegt und damit ein Verlassen der ODD bevorsteht. Eine ODD- Grenze kann sich auch dadurch ergeben, dass vorbestimmte ODD-Attribute fehlen, das heißt solche Attribute nicht mehr oder nicht vorhanden sind, die sich innerhalb der ODD erwartungsgemäß ergeben müssen. Also das Fehlen von ODD-Attri buten kann ebenfalls als ein ODD-Merkmal für eine ODD- Grenze interpretiert werden.
Ein automatisierter Fahrmodus kann vorsehen, dass eine Längsführung und/oder eine Querführung des Fahrzeugs automatisiert, das heißt ohne das Zutun eines Fahrers, durchgeführt wird, indem eine Steuerschaltung einen Aktuator des Fahrzeugs für die Längsführung und/oder Querführung steuert. Ein assistierter Fahrmodus kann dagegen einem Fahrer beim Führen des Fahrzeugs Hilfestellung und/oder Informationen bieten, beispielsweise ein assistiertes Überholen und/oder Einparken vorsehen. Das Grenzkriterium für die Erkennung der ODD-Grenze kann vom Fachmann derart festgelegt werden, dass all diejenigen ODD-Merkmale, beispielsweise eine Ampel und/oder ein Verkehrsschild und/oder eine vorbestimmte Anordnung von Fremdfahrzeugen in der Umgebung, von der ODD-Überwachungsroutine als eine ODD-Grenze erkannt werden, die für den Fahrmodus relevant sind. Der Fachmann kann hierzu in der ODD-Überwachungsroutine entsprechende Beschreibungen nach Bedarf festlegen. Die ODD-Überwachungsroutine kann durch eine Prozessorschaltung ausgeführt werden. Sie kann beispielsweise als eine Software für die Prozessorschaltung ausgestaltet sein.
Die erfindungsgemäße Lösung strebt an, die ODD-Grenze möglichst frühzeitig und/oder in einem Abstand zum eigenen Fahrzeug zu erkennen, um genügend Zeit für das Deaktivieren des Fahrmodus zu erhalten, bis die ODD-Grenze erreicht ist.
Hierzu ist vorgesehen, dass die Messung der ODD-Merkmale mittels zumindest eines auf der Fahrroute dem Fahrzeug vorausfahrendes Fremdfahrzeugs durchgeführt wird und durch einen Backend-Server, der das zumindest eine Fremdfahrzeug mit dem Fahrzeug über jeweilige Kommunikationsverbindungen koppelt, die gemessenen Merkmalsdaten der ODD-Merkmale gesammelt werden und/oder die ODD-Überwachungsroutine durchgeführt wird. Mit anderen Worten nutzt das Fahrzeug zumindest ein vorausfahrendes Fremdfahrzeug, um die Messung von ODD-Merkmalen in der Umgebung durchzuführen. Hierdurch wird also die Messung von ODD- Merkmalen entsprechend dem Abstand zu dem vorausfahrenden Fremdfahrzeug vorverlagert. Um das zumindest eine Fremdfahrzeug mit dem Fahrzeug zuverlässig zu koppeln, erfolgt die Kommunikation, also insbesondere die Übertragung von Merkmalsdaten der gemessenen ODD- Merkmale, über einen Backend-Server, der entsprechende Kommunikationsverbindungen unterhält, die beispielsweise auf zumindest einer Funkverbindung und/oder zumindest einer Internetverbindung bereitgestellt werden können. Beispielsweise kann auf eine Mobilfunk- Kommunikationstechnologie und/oder WIFI-Technologie zurückgegriffen werden. Allgemein ist eine solche Kommunikation als V2X-Kommunikation bekannt (V2X - Fahrzeug-zu-X-Kommunikation, wobei X für ein Kommunikationsgerät in einem Fahrzeug oder einem stationären Infrastrukturobjekt eines Straßennetzes steht). Mit anderen Worten nutzt das Verfahren Sensoreingänge oder Messkanäle aus zumindest einem vorausfahrenden Fremdfahrzeug, um frühzeitig oder mit einem Abstand zum Fahrzeug die Messung von ODD-Merkmalen durchzuführen. So kann beispielsweise als ODD-Merkmal eine Ampel durch ein vorausfahrendes Fremdfahrzeug erfasst werden und als ODD-Merkmal an den Backend- Server signalisiert werden. Der Backend-Server kann beispielsweise als ein Computer oder ein Computerverbund des Internets implementiert sein. Ein Fremdfahrzeug kann ein von dem Fahrzeug, dessen Fahrmodus durch das Verfahren überwacht wird, verschiedenes Kraftfahrzeug, also ein anderer Verkehrsteilnehmer sein, z.B. ein Personenkraftwagen oder Lastkraftwagen.
Durch die Erfindung ergibt sich der Vorteil, dass auch solche ODD-Merkmale für das Fahrzeug frühzeitig oder vorausschauend erkennbar sind, die kurzfristig in der Umgebung entstanden oder aufgetaucht sind, wie beispielsweise ein beschädigtes Verkehrsschild und/oder eine ausgefallene Verkehrsampel und/oder ein Verkehrsstau. Hierbei kann auch auf zumindest ein Fremdfahrzeug zurückgegriffen werden, das selbst von einer Person geführt sein kann, also selbst keinen aktiven Fahrmodus aufweisen muss. Ein Fremdfahrzeug muss somit nur geringe technische Anforderungen erfüllen. Das Fahrzeug und das zumindest eine vorausfahrende Fremdfahrzeug bilden dahingehend eine Kolonne, als dass diese Fahrzeug bevorzugt gleichzeitig unterwegs sind oder auf der Fahrroute fahren.
Die Erfindung umfasst auch Ausführungsformen, durch die sich zusätzliche Vorteile ergeben.
Eine Ausführungsform umfasst, dass zumindest einige der gemessenen ODD-Merkmale jeweils als ein Mitschnitt eines Sensorsignals, insbesondere eines Videosignals, und als Metadaten, insbesondere eine Positionsangabe einer Position des ODD-Merkmals und/oder eine Ausrichtungsangabe einer räumlichen Ausrichtung des ODD-Merkmals, signalisiert werden. Mit anderen Worten muss durch das Fremdfahrzeug selbst nicht interpretiert werden, ob tatsächlich ein gültiges oder relevantes ODD-Merkmal erfasst wurde. Das Fremdfahrzeug muss lediglich das Sensorsignal bereitstellen, das ein möglichen ODD-Merkmal erfasst oder signalisiert. Zudem kann die Position dieses gemessenen ODD-Merkmals und/oder seine Ausrichtung, beispielsweise als Angabe einer Himmelsrichtung oder eine Fahrtrichtung oder einer Winkelangabe bezüglich eines Referenzwinkels, signalisiert werden. Die Ausrichtungsangabe legt zum Beispiel fest, in welche Fahrtrichtung das ODD-Merkmal weist, sodass beispielsweise eine Ausrichtung einer Ampel und/oder eines Verkehrsschilds signalisiert ist. Wenn als ODD-Merkmale Objekte eines bestimmten Objekttyps (beispielsweise Verkehrsschilder eines vorgegebenen Schildertyps, beispielsweise Gefahrenhinweise) durch ein Fremdfahrzeug erfasst werden sollen, so kann in dem Fremdfahrzeug ein entsprechender Trigger oder Auslöser gesetzt werden, der bei Erkennen eines Objekts, für das im Fremdfahrzeug der Objekttyp detektiert wird, das Sensorsignal beispielsweise einer Kamera, mitgeschnitten werden und als gemessenes ODD-Merkmal (inklusive der Metadaten) an den Backend-Server signalisiert werden.
Eine Erkennung eines Objekts und seines Objekttyps kann in einem Fremdfahrzeug in an sich bekannter Weise mittels einer Methode des maschinellen Lernen erfolgen (z.B. Verkehrsschilderkennung mittels Computer-Vision). In dem Fremdfahrzeug kann hierdurch in an sich bekannter Weise eine Objektdetektion betrieben werden, die beispielsweise auf der Grundlage eines Modells für maschinelles Lernen, beispielsweise ein künstliches neuronales Netzwerk, anhand von zumindest einem Sensorsignal detektiert werden. Beispielsweise kann als Sensorsignal das beschriebene Videosignal und/oder ein Radarsignal und/oder ein LIDAR- Signal genutzt werden. Mittels der Objektdetektion oder Objekterkennung kann in einem Sensorsignal ein solcher Signalabschnitt oder Signalbereich (zum Beispiel Bildbereich) identifiziert werden, der ein Objekt einer bekannten Objektklasse, beispielsweise Verkehrsschild, Ampel, Fahrbahnmarkierung, Verkehrsteilnehmer, um nur Beispiele zu nennen, vermutlich oder mit einer vorgegebenen Mindestwahrscheinlichkeit oder Mindestkonfidenz, enthält. Für das Erzeugen von gemessenen ODD- Merkmalen kann diesem Modell dann beispielsweise ein Filter nachgeschaltet sein, der solche erkannten Objekte beispielsweise an den Backend-Server oder das Fahrzeug sendet oder meldet, die als ODD- Merkmal gesucht werden. Eine Ausführungsform umfasst, dass durch das Fahrzeug ODD-Parameter, welche die für den Fahrmodus gültigen ODD-Grenzen beschreiben und/oder die zu messenden ODD-Merkmale, an denen man die ODD-Grenzen erkennt, festlegen, an den Backend-Server und/oder an das zumindest eine Fremdfahrzeug ausgesendet werden und die Messung und/oder die ODD- Überwachungsroutine mittels der ODD-Parameter konfiguriert wird. Hierdurch wird die Messung und/oder die Überwachungsroutine auf die für den Fahrmodus gültigen ODD-Grenzen beschränkt. Das Fahrzeug kann somit Informationen über die zu messenden ODD-Merkmale und/oder ODD- Grenzen bereitstellen. Wird durch die ODD-Parameter lediglich eine ODD- Grenze (anstelle der zugehörigen ODD-Merkmale) signalisiert, so kann zu jeder ODD-Grenze eine Liste zugehöriger ODD-Merkmale beispielsweise in dem Backend-Server oder in dem jeweiligen Fremdfahrzeug bereitgestellt sein. So kann beispielsweise eine Liste vorgesehen sein, welche einer ODD- Grenze zugehörige ODD-Merkmale zuordnen. Ist als ODD beispielsweise eine Autobahn angegeben (Fahrmodus darf nur auf Autobahn betrieben werden), so ergeben sich als ODD-Grenze Ausfahrten und Parkplätze und Tankstellen. Entsprechende ODD-Merkmale, also beispielsweise Ausfahrtsschilder, Ausfahrten mit entsprechender Fahrbahnkrümmung, Verkehrsschilder einer vorgegebenen Farbe, können dann als ODD- Merkmale erfasst werden, welche diese ODD-Grenze markieren. Die ODD- Überwachungsroutine kann beispielsweise ermitteln, welche vorausliegende Fahrtroute für das Fahrzeug geplant ist und dann erkennen, ob die geplante Fahrtroute die anhand der ODD-Merkmale ermittelte ODD-Grenze schneiden wird, also die ODD voraussichtlich verlassen werden wird. Dann kann eine Übergabemaßnahme zum Deaktivieren des Fahrmodus ausgelöst werden. Routendaten der Fahrtroute können z.B. aus einem Navigationssystem des Kraftfahrzeugs und/oder einer Navigationsfunktionsfunktion des Backend- Server, der das Kraftfahrzeug bei einer Navigation unterstützt, empfangen werden. Die Fahrtroute kann auch geschätzt werden, beispielsweise anhand von historischen Fahrtroutenverläufen, indem eine wiederholt befahrene Strecke als geschätzte Fahrtroute ausgewählt werden kann. Eine Ausführungsform umfasst, dass in dem Fall, dass durch das Fremdfahrzeug ein ODD-Merkmal erkannt wird und das Fremdfahrzeug durch eine Person in einem manuellen Fahrmodus geführt wird, ein Führungsprofil einer von der Person beim Annähern an und/oder beim Passieren des ODD-Merkmals durchgeführten Längsführung und/oder Querführung als eine Führungsprofil erfasst wird und das Führungsprofil dem Fahrmodus als ein in dem Fahrzeug durch den Fahrmodus nachzubildendes Führungsprofil vorgegeben wird. Somit kann das Fahrverhalten einer fremden Person in dem Fremdfahrzeug dazu genutzt werden, Steuersignale für das Fahrzeug zu ermitteln, die ein geeignetes Verhalten des Fahrzeugs an der ODD-Grenze vorgeben. So kann also der Fahrmodus durch Nachbilden des Führungsprofils dahingehend ertüchtig oder erweitert werden, dass er auch an der ODD-Grenze weiter betrieben werden kann, also die ODD dynamisch erweitert wird, falls ein geeignetes Führungsprofil von einer Person erfasst werden konnte oder wurde.
Eine Ausführungsform umfasst, dass durch den Backend-Server anhand der gesammelten ODD-Merkmale und anhand des Grenzkriteriums eine fahrzeugindividuelle Umfeldkarte der ODD für den Fahrmodus des Fahrzeugs erzeugt und dem Fahrzeug für eine zukünftige Routenplanung bereitgestellt wird. In dem Backend-Server kann beispielsweise eine Software betrieben werden, welche die gemessenen ODD-Merkmale daraufhin überprüft, ob es valide oder korrekte ODD-Merkmale sind, die tatsächlich die ODD-Grenze markieren. Hierdurch können Fehl-Erkennungen oder Fehldetektionen kompensiert werden. Sodann kann durch die jeweilige Position der gesammelten ODD-Merkmale erfasst oder erkannt werden, wo die ODD-Grenze verläuft. Dies kann dann in der Umfeldkarte kartographiert werden, sodass in dem Fahrzeug der Fahrmodus oder die Fahrfunktion oder ein Routenplanung die ODD oder den Verlauf der ODD-Grenze beim Planen einer Route oder Trajektorie berücksichtigen kann. Somit wird also die anhand der gesammelten ODD-Merkmale ermittelte mutmaßliche Grenze der ODD geprüft. Dies kann das frühzeitige Deaktivieren des Fahrmodus unterstützen und/oder eine Fahrempfehlung ergeben, um den Fahrmodus beim Erreichen eines vorgegebenen Fahrziels auf möglichst langen Fahrstrecken betreiben zu können.
Eine Ausführungsform umfasst, dass durch den Backend-Server über eine Bedienschnittstelle die gemessenen ODD-Merkmale an eine Bedienperson ausgegeben werden und eine Nutzereingabe der Bedienperson empfangen wird und in Abhängigkeit von der Nutzereingabe festgelegt wird, ob das ODD-Merkmal das Grenzkriterium erfüllt. Im Backend-Server kann somit die Interpretation oder die Erkennung oder Auswertung eines gemessenen ODD-Merkmals durch eine Bedienperson erfolgen. Dies hat den Vorteil, dass auch solche ODD-Merkmale überprüft werden können, an denen aufgrund beispielsweise einer Signalqualität des Sensorsignals und/oder aufgrund des Erscheinungsbilds des ODD-Merkmals, beispielsweise eine Verdreckung eines Verkehrsschilds, eine automatisierte Auswertung scheitert. Das Präsentieren des ODD-Merkmals an die Bedienperson kann „in the loop“ oder in Echtzeit erfolgen, sodass ein vorausfahrendes Fremdfahrzeug das gemessene ODD-Merkmal an den Backend-Server signalisiert, dort das gemessene ODD-Merkmal der Bedienperson dargestellt wird (falls beispielsweise eine automatisierte Auswertung einen Fehler signalisiert oder eine Erkennungskonfidenz geringer als ein Schwellenwert ist) und dann bei Erkennen eines zulässigen ODD-Merkmals, welches das Grenzkriterium erfüllt oder auf die ODD-Grenze hinweist, dies dem Fahrzeug signalisiert wird. Somit kann eine menschliche Plausibilisierung in die Verarbeitungskette zum Verarbeiten gemessener ODD-Merkmale zum Überprüfen des Grenzkriteriums integriert werden. Die Nutzereingabe kann z.B. eine binäre Angabe sein, dass das Merkmal zu ignorieren ist oder nicht.
Eine Ausführungsform umfasst, dass für den Fall, dass durch ein gemessenes ODD-Merkmal das Grenzkriterium unerfüllt ist, Maskierdaten, die signalisieren, dass dieses ODD-Merkmal zu ignorieren ist, erzeugt und an das Fahrzeug ausgesendet werden und eine ODD-Überwachungsroutine des Fahrzeugs mittels der Maskierdaten konfiguriert wird, sodass bei Detektieren des ODD-Merkmals dieses durch die ODD- Überwachungsroutine des Fahrzeugs ignoriert wird. Wird zu einem gemessenen ODD-Merkmal erkannt oder detektiert, dass es das Grenzkriterium nicht erfüllt, also keine Markierung der ODD-Grenze darstellt, so kann durch die Maskierdaten verhindert werden, dass das Fahrzeug selbst mittels seiner eigenen Objektdetektion das ODD-Merkmal fehlinterpretiert. Denn wird ein ODD-Merkmal durch das Fremdfahrzeug signalisiert, so hat zumindest schon einmal eine Objektdetektion bereits fehlerhafterweise ein ODD-Merkmal erkannt, obwohl sich dann anhand des Grenzkriteriums herausstellt, dass es keine ODD-Grenze markiert. Dies kann beispielsweise sein, wenn auf einem Werbeplakat eine Ampel dargestellt ist und als ODD-Merkmale Ampeln gesucht werden. Wird dann beispielsweise durch die bereits beschriebene Bedienperson anhand der Nutzereingabe vorgegeben, dass die Ampel auf dem Werkeplakat kein gültiges ODD- Merkmal ist, so kann dies durch die Maskierdaten dem Fahrzeug mitgeteilt werden, sodass dessen eigene Objektdetektion zum Erkennen von ODD- Markmalen nicht ebenfalls getäuscht oder falsche Ausgabesignale erzeugt, die irrtümlicherweise ein gültiges ODD-Merkmal signalisieren, wenn das Fahrzeug selbst das ODD-Merkmal erreicht oder passiert.
Eine Ausführungsform umfasst, dass das Fremdfahrzeug die Messung der ODD-Merkmale bei fehlendem eigenem Fahrmodus oder bei deaktiviertem und/oder aktiviertem eigenem Fahrmodus durchführt. Mit anderen Worten ist nicht notwendig, dass auch das jeweilige Fremdfahrzeug selbst den Fahrmodus aufweist. Es reicht, wenn das Fremdfahrzeug Sensorsignale, beispielsweise Videosignale einer Kamera, erfasst und daraufhin überprüft, ob ein gesuchtes ODD-Merkmal, beispielsweise ein Verkehrsschild oder eine Ampel, erkannt wird. Falls das Fremdfahrzeug den Fahrmodus selbst aufweist, muss dieser nicht aktiv sein. Somit können auch solche Fremdfahrzeuge mittels des Verfahrens genutzt werden, die nicht selbst an einer beispielsweise nur kurzfristig erkennbaren ODD-Grenze ihren Fahrmodus deaktivieren mussten.
Eine Ausführungsform umfasst, dass in dem Fahrzeug bei Annäherung an eine ODD-Grenze und bevorstehendem Verlassen der ODD eine vorbestimmte Übergabemaßnahme zum Deaktivieren des Fahrmodus und Übergeben der Längsführung und/oder Querführung des Fahrzeugs an einen Fahrer durchgeführt wird. Das Fahrzeug kann somit den Fahrmodus dadurch deaktivieren, dass während der Fahrt eine Übergabe an einen Fahrer erfolgt oder das Fahrzeug beispielsweise auf einen vor der ODD-Grenze liegenden Parkplatz fährt und dort die Fahrt unterbricht. Es kann allgemein auf eine Übergabemaßnahme zurückgegriffen werden, wie sie für automatisierte Fahrmodi im Stand der Technik bekannt sind.
Als eine weitere Lösung umfasst die Erfindung eine Steuerschaltung für ein Fahrzeug. Die Steuerschaltung ist dazu eingerichtet, einen automatisierten und/oder assistierten Fahrmodus für das Fahrzeug bereitzustellen und ODD- Parameter, welche für den Fahrmodus gültige ODD-Grenzen einer ODD des Fahrmodus beschreiben und/oder zu messende ODD-Merkmale, welche die ODD-Grenzen markieren, an einen Backend-Server und/oder an zumindest ein Fremdfahrzeug auszusenden und aus dem Backend-Server und/oder dem zumindest einem Fremdfahrzeug gemessene ODD-Merkmale und/oder Kartendaten von aus gemessenen ODD-Merkmalen geschätzten ODD- Grenzen der ODD zu empfangen und damit einen Betrieb des Fahrmodus auf die für den Fahrmodus gültigen ODD (bei Erkennen einer Annäherung an eine ODD-Grenze) zu beschränken. Dies kann mittels der ODD- Überwachungsroutine erfolgen. Das Fahrzeug ist bevorzugt als Kraftwagen, insbesondere als Personenkraftwagen oder Lastkraftwagen, oder als Personenbus oder Motorrad ausgestaltet. Die Steuerschaltung kann beispielsweise als ein Steuergerät oder ein Verbund aus Steuergeräten für ein Fahrzeug ausgestaltet sein.
Die Steuerschaltung kann eine Datenverarbeitungsvorrichtung oder eine Prozessoreinrichtung aufweisen, die dazu eingerichtet ist, beschriebenen Verfahrensschritte durchzuführen. Die Steuerschaltung kann zumindest einen Mikroprozessor und/oder zumindest einen Mikrocontroller und/oder zumindest einen FPGA (Field Programmable Gate Array) und/oder zumindest einen DSP (Digital Signal Processor) aufweisen. Des Weiteren kann die Steuerschaltung Programmcode aufweisen, der dazu eingerichtet ist, bei Ausführen durch die Prozessoreinrichtung die Verfahrensschritte durchzuführen. Der Programmcode kann in einem Datenspeicher der Steuerschaltung gespeichert sein.
Als eine weitere Lösung umfasst die Erfindung einen Backend-Server für ein Fahrzeug mit einem automatisierten und/oder assistierten Fahrmodus. Der Backend-Server ist dazu eingerichtet, aus dem Fahrzeug über eine Kommunikationsverbindung ODD-Parameter, welche für den Fahrmodus gültige ODD-Grenzen einer ODD des Fahrmodus beschreiben und/oder zu messende ODD-Merkmale, welche die ODD-Grenzen markieren, zu empfangen und zumindest ein dem Fahrzeug vorausfahrendes Fremdfahrzeug zum Messen der ODD-Merkmale über eine jeweilige Kommunikationsverbindung anzusteuern und die gemessenen ODD- Merkmale und/oder Kartendaten von aus gemessenen ODD-Merkmalen geschätzten ODD-Grenzen der ODD an das Fahrzeug auszusenden. Der Backend-Server kann in der beschriebenen Weise einen Computer oder einen Verbund aus mehreren Computern umfassen. Der Backend-Server kann als ein Server des Internets betrieben werden. Die jeweilige Kommunikationsverbindung zu einem Fremdfahrzeug oder dem Fahrzeug kann in der beschriebenen Weise funkbasiert und/oder auf Grundlage einer Internetverbindung realisiert sein. Die ODD-Parameter können dann angeben, nach welchen ODD-Merkmalen oder nach welcher ODD-Grenze (beispielsweise der Rand eines Autobahnbereichs) gesucht werden soll. Entsprechende Erfassungsbefehle oder Messbefehle für zumindest ein ODD-Merkmal können dann an zumindest ein Fremdfahrzeug ausgesendet werden, das dann als Messergebnisse gemessene ODD-Merkmale signalisieren kann. Ob sich ein Fremdfahrzeug auf einem dem Fahrzeug vorausliegenden Streckenabschnitt befinden, ob also ein Fremdfahrzeug ein vorausfahrendes Fahrzeug darstellt, kann anhand von Routendaten und/oder einer Geoposition und einer Fahrtrichtung des Fremdfahrzeugs ermittelt werden.
Als eine weitere Lösung umfasst die Erfindung ein System umfassend eine Ausführungsform des erfindungsgemäßen Backend-Server und zumindest ein Fahrzeug mit einer Ausführungsform der erfindungsgemäßen Steuerschaltung. Das System umfasst also das Zusammenspiel aus Backend-Server und zumindest einem Fahrzeug, um eine Ausführungsform des erfindungsgemäßen Verfahrens durchzuführen.
Die Erfindung umfasst auch die Kombinationen der Merkmale der beschriebenen Ausführungsformen. Die Erfindung umfasst also auch Realisierungen, die jeweils eine Kombination der Merkmale mehrerer der beschriebenen Ausführungsformen aufweisen, sofern die Ausführungsformen nicht als sich gegenseitig ausschließend beschrieben wurden.
Im Folgenden sind Ausführungsbeispiele der Erfindung beschrieben. Hierzu zeigt die einzige Figur:
Fig. eine schematische Darstellung einer Ausführungsform des erfindungsgemäßen Systems, das eine Ausführungsform des erfindungsgemäßen Verfahrens durchführen kann.
Bei den im Folgenden erläuterten Ausführungsbeispielen handelt es sich um bevorzugte Ausführungsformen der Erfindung. Bei den Ausführungsbeispielen stellen die beschriebenen Komponenten der Ausführungsformen jeweils einzelne, unabhängig voneinander zu betrachtende Merkmale der Erfindung dar, welche die Erfindung jeweils auch unabhängig voneinander weiterbilden. Daher soll die Offenbarung auch andere als die dargestellten Kombinationen der Merkmale der Ausführungsformen umfassen. Des Weiteren sind die beschriebenen Ausführungsformen auch durch weitere der bereits beschriebenen Merkmale der Erfindung ergänzbar.
In der Figur bezeichnen gleiche Bezugszeichen jeweils funktionsgleiche Elemente.
Die Figur zeigt ein System 10 mit einem Backend-Server 11 und einem Fahrzeug 12, das als Kraftfahrzeug, insbesondere als Personenkraftwagen oder Lastkraftwagen, ausgestaltet sein kann. Das Fahrzeug 12 kann auf einer Straße 13 betrieben werden, bei der es sich in dem vorliegenden Beispiel um eine Autobahn 14 handeln kann. Das Fahrzeug 12 kann mittels einer Steuerschaltung 15 in einem automatisierten Fahrmodus F betrieben werden, beispielsweise einem HAF oder hochautomatisierten Fahrmodus. Eine entsprechende Fahrfunktion kann beispielsweise durch einen Autopiloten realisiert sein. Der Fahrmodus F kann auf vorbestimmte Fahrsituationen begrenzt sein, wodurch sich eine ODD für den Fahrmodus F ergibt, innerhalb welcher der Fahrmodus F nur aktiv sein darf. Beispielsweise kann als ODD festgelegt sein, dass der Fahrmodus F nur im Bereich der Autobahn 14 zulässig ist, solange sich auf der Autobahn 14 vorbestimmte Fahrverhältnisse ergeben, beispielsweise keine Baustelle vorliegt.
Der Backend-Server 11 kann mit einer Kommunikationseinheit 16 des Fahrzeugs 12 über eine Kommunikationsverbindung 17 verbunden sein, die beispielsweise als Funkverbindung über ein Mobilfunknetz 18 geführt sein kann und über eine Internetverbindung 19 in das Internet 20 führen kann, in welchem der Backend-Server 11 betrieben sein kann. Hierzu können von dem Backend-Server 11 aus entsprechende Kommunikationsverbindungen 39 zu dem jeweiligen Fremdfahrzeug 32 über dessen Kommunikationseinheit 34 betrieben werden. Eine Kommunikationseinheit 16 kann beispielsweise auf der Grundlage eines Mobilfunkmoduls und/oder WIFI-Moduls realisiert sein.
Um sicherzustellen, dass der Fahrmodus F, während er in Betrieb ist, auch innerhalb der ODD betrieben wird, kann in an sich bekannter Weise zumindest ein Sensor 21 in dem Fahrzeug 12 betrieben werden, dessen Erfassungsbereich 22 in eine Umgebung 23 des Fahrzeugs 12 ausgerichtet sein kann. Mittels des zumindest einen Sensors 21 kann durch die Steuerschaltung 15 ermittelt werden, ob ein ODD-Merkmal 24 vorliegt, welches signalisiert, dass eine ODD-Grenze 25 der ODD erreicht ist oder vorliegt, innerhalb welcher der Fahrmodus F nur aktiv sein kann. In der Figur sind beispielhafte ODD-Grenzen ein Verkehrsschild 26, welches signalisiert, dass eine Ausfahrt 27 vorhanden ist, die von der Autobahn 14 wegführt. Ein weiteres mögliches ODD-Merkmal 24 kann eine Kurve 28 sein, deren Kurvenradius 29 kleiner als ein für den Fahrmodus F zulässiger Grenzwert ist. Ein weiteres ODD-Merkmal 24 kann eine Baustelle 30 sein, die auf der Autobahn 14 errichtet worden sein kann und somit im Bereich der Baustelle
30 den Betrieb oder die Aktivität des Fahrmodus F verbietet.
Da der jeweilige Sensor 21 einen auf eine Maximalreichweite 31 begrenzten Erfassungsbereich 22 aufweist, kann mittels des jeweiligen Sensors 21 für das Fahrzeug 12 ein ODD-Merkmal 24 nur innerhalb der Maximalreichweite
31 erfasst werden, was unter Umständen zu einer kurzfristigen Beendigung oder Deaktivierung des Fahrmodus F führen kann. Dies ist bei dem Fahrzeug 12 durch das System 10 vermieden. Hierzu wird bei dem System
10 mittels des Backend-Servers 11 zumindest ein Fremdfahrzeug 32 dazu genutzt, ODD-Merkmale 24 zu detektieren, die auf die ODD-Grenze 25 hinweisen oder diese markieren. Durch die Steuerschaltung 15 können über die Kommunikationseinheit 16 ODD-Parameter 33 an den Backend-Server
11 übermittelt werden. Der Backend-Server 11 kann die ODD-Parameter 33 oder daraus abgeleitete Messbefehle oder Detektionsbefehle an die Fremdfahrzeuge 32 aussenden. In jedem Fremdfahrzeug kann eine Kommunikationseinheit 34, ein Steuergerät 35 und zumindest ein Sensor 36 mit einem in die Umgebung 23 ausgerichteten Erfassungsbereich 37 vorgesehen oder bereitgestellt oder genutzt werden. Anhand der ODD- Parameter 33 kann durch das Steuergerät 35 in jedem Fremdfahrzeug 32 ebenfalls eine Erfassung oder Messung von ODD-Merkmalen 24 durchgeführt werden. Es werden bevorzugt solche Fremdfahrzeuge 32 durch den Backend-Server 11 ausgewählt, deren Position und/oder Fahrtroute indiziert, dass es sich um dem Fahrzeug 12 vorausfahrende Fremdfahrzeuge
32 handelt. Hierzu kann beispielsweise von einem globalen Navigationssatellitensystem GNS, beispielsweise dem GPS (Global Positioning System) ein Positionssignal 38 genutzt werden, das in dem Fahrzeug 12 und dem jeweiligen Fremdfahrzeug 32 dazu genutzt werden kann, mittels eines Empfängers für das Positionssignal 38 empfangen zu werden und somit die Position des jeweiligen Fahrzeugs 12 und des jeweiligen Fremdfahrzeug 32 zu ermitteln und beispielsweise dem Backend- Server 11 zu signalisieren über die Kommunikationsverbindungen 17, 39.
Indem es sich um vorausfahrende Fremdfahrzeuge 32 handelt, ist auch der entsprechende Sensor 36 vor dem Fahrzeug 12 in Fahrtrichtung angeordnet und damit jenseits der Maximalreichweite 31 des Sensors 21 des Fahrzeugs 12 selbst. Dies bedeutet einen Zeitgewinn und/oder Streckengewinn dahingehend, dass in einem Vorsprung 40 bereits durch ein Fremdfahrzeug 32 ein ODD-Merkmal 24 empfangen werden kann, noch bevor ein ODD- Merkmal 24 mittels des zumindest einen Sensors 21 des Fahrzeugs 12 selbst erkannt werden kann. Entsprechend ist Zeit zur Verfügung, bei Annäherung an die durch das ODD-Merkmal 24 markierte ODD-Grenze 25 den Fahrmodus F zu deaktivieren. In dem jeweiligen Steuergerät 35 kann beispielsweise eine Objektdetektion betrieben werden, durch welche anhand eines Sensorsignals des jeweiligen Sensorsignals 41 des jeweiligen Sensors 36 ermittelt werden kann, welche Objekte im Sensorsignal 41 aus der Umgebung 23 erkannt worden oder erfasst worden sind. Fällt eines dieser erfassten Objekte in ein Erkennungsschema oder Erkennungsmuster entsprechend dem gesuchten ODD-Merkmal, wie es durch die ODD- Parameter 33 vorgegeben sein kann, so kann an den Backend-Server 11 aus dem jeweiligen Fremdfahrzeug 32 ein gemessenes ODD-Merkmal 43 signalisiert werden, also Merkmalsdaten eines Messergebnisses signalisiert werden. In dem Backend-Server 11 kann vorgesehen sein, gemessene ODD-Daten der gemessenen ODD-Merkmale 43 einer Bedienperson 44 über eine Benutzerschnittstelle 45, beispielsweise einen Bildschirm, anzuzeigen und eine Nutzereingabe 46 von der Bedienperson 44 zu empfangen, die beispielsweise bestätigen kann, dass es sich um ein gültiges oder valides ODD-Merkmal für die ODD-Grenze 25 handelt oder es können anders herum bei Ablehnung des ODD-Merkmals Maskierdaten 47 generiert werden, welche angeben, dass eine Objektdetektion zwar ein potentielles oder mögliches ODD-Merkmal 24 erkennen mag, dies aber eine Täuschung oder Fehldetektion ist, weil es sich beispielsweise lediglich um eine Abbildung eines ODD-Merkmals beispielsweise auf einem Werbeplakat handeln kann. Entsprechend können die bestätigten ODD-Merkmale 43 und/oder die Maskierdaten 47 an das Fahrzeug 12 über die Kommunikationsverbindung 17 ausgesendet werden. In der Steuerschaltung 15 kann beispielsweise eine ODD-Überwachungsroutine 50 überprüfen, ob eine geplante Fahrtrajektorie 51 die ODD-Grenze 25 kreuzen wird, die anhand der ODD-Merkmale 43 dem Fahrzeug 12 vorausliegt. Ist dies der Fall, so kann der Fahrmodus F deaktiviert werden und hierzu in an sich bekannter Weise eine Übergabemaßnahme ausgelöst werden, beispielsweise der Fahrer des Fahrzeugs 12 aufgefordert werden, die sogenannte Fahraufgabe, das heißt die Längsführung und/oder Querführung, die bisher durch den aktivierten Fahrmodus F durchgeführt wurde, zu übernehmen. Da dies mit dem Vorsprung 40 erfolgt, bleibt mehr Zeit für die Durchführung der Übergabemaßnahme als für den Fall, dass lediglich mittels des zumindest einen Sensors 21 des Fahrzeugs 12 selbst die ODD-Merkmale 24 detektiert worden wären. Der Vorsprung 40 ist größer als die Maximalreichweite 31 des zumindest einen Sensors 21 .
Bevorzugt werden vorausfahrende Fahrzeuge mit vergleichbaren Eigenschaften wie das HAF-System verwendet, um eine Messung der ODD im Sinne des nachfolgenden HAF-Systems durchzuführen, also Fahrzeuge, die ebenfalls den Fahrmodus aufweisen. Alle zur Messung geeigneten Fahrzeuge mit den notwendigen Informationen über die zu messenden ODD- Grenzen versorgt. Die kann z.B. über eine Funkverbindung von einem zentralen Backend geschehen.
Während der Fahrt werden die Sensoreingänge auf relevante ODD- Merkmale geprüft. Angenommen Ampeln stellen eine ODD-Grenze dar, so würde ein Fahrzeug, welches eine Ampel erfasst einen Videomitschnitt der Grenze mit Metadaten wie Position etc. aufzeichnen und ans Backendübertragen. Die Information kann im Falle einer manuellen Fahrt noch mit Informationen zum Umgang des menschlichen Fahrers angereichert werden (z.B. Anhalten vor Ampel).
Auf dem Server kann die Information über die mutmaßliche ODD Grenze abgelegt werden und um eine Empfehlung zum Umgang je HAF-System angereichert werden. Auch menschliche Plausibilisierungen sind dann denkbar.
Eine digitale Karte mit diesen Informationen kann an ein HAF-System genutzt werden und dort zum besseren Umgang mit (potentiellen) ODD- Grenzen angewendet werden (frühzeitige Deaktivierung oder bewusstes Ignorieren).
Der (bidirektionale) Austausch von ODD-Informationen kann vorgesehen sein. Das empfangende Fahrzeug sendet Informationen über seine spezifische ODD-Grenzen an das Backend, welches durch geeignete Kopplung der Eingangsdaten von datensammelnden Fahrzeugen eine fahrzeugspezifische ODD-Karte für das Fahrzeug erstellt.
Der Erkennungsbereich für ODD-Merkmale wird vergrößert und damit die Systemreaktion auf ODD-Grenzen verbessert.
Insgesamt zeigen die Beispiele, wie eine Vorausschauende Erkennung von ODD-Grenzen (ODD - operational design domain) bereitgestellt werden kann.

Claims

PATENTANSPRÜCHE: Verfahren zum Überprüfen, ob ein aktuell aktiver automatisierter und/oder assistierter Fahrmodus eines Fahrzeugs (12), das mittels des Fahrmodus eine Fahrt entlang einer Fahrtroute durchführt, innerhalb der für den Fahrmodus vorgegebenen ODD-Grenze (25) einer Operational-Design-Domäne, ODD, des Fahrmodus betrieben wird, wobei mittels zumindest eines Umfeldsensors (36) in einer Umgebung (23) des Fahrzeugs (12) eine Messung von vorbestimmten ODD- Merkmalen (24), welche die ODD-Grenze (25) markieren, durchgeführt wird und anhand der gemessenen ODD-Merkmale (24) mittels einer ODD-Überwachungsroutine (50) ein vorbestimmtes Grenzkriterium überprüft wird, das angibt, ob sich das Fahrzeug (12) auf eine ODD- Grenze (25) zubewegt und damit ein Verlassen der ODD bevorsteht, dadurch gekennzeichnet, dass die Messung mittels zumindest eines auf der Fahrroute dem Fahrzeug (12) vorausfahrendes Fremdfahrzeug (32) durchgeführt wird und durch einen Backend-Server (11), der das zumindest eine Fremdfahrzeug (32) mit dem Fahrzeug (12) über jeweilige Kommunikationsverbindungen (17, 39) koppelt, die gemessenen ODD- Merkmale (24) gesammelt werden und/oder die ODD- Überwachungsroutine (50) durchgeführt wird. Verfahren nach Anspruch 1 , wobei zumindest einige der gemessenen ODD-Merkmale (24) jeweils als ein Mitschnitt eines Sensorsignals (41 ), insbesondere eines Videosignals, und als Metadaten, insbesondere eine Positionsangabe einer Position des ODD-Merkmals (24) und/oder eine Ausrichtungsangabe einer räumlichen Ausrichtung des ODD- Merkmals (24), signalisiert werden. Verfahren nach einem der vorhergehenden Ansprüche, wobei durch das Fahrzeug (12) ODD-Parameter (33), welche die für den Fahrmodus gültigen ODD-Grenzen (25) beschreiben und/oder die zu messenden ODD-Merkmale (24) festlegen, an denen man die ODD-Grenzen (25) erkennt, an den Backend-Server (11 ) und/oder an das zumindest eine Fremdfahrzeug (32) ausgesendet werden und die Messung und/oder die ODD-Überwachungsroutine (50) mittels der ODD-Parameter (33) konfiguriert wird und hierdurch auf die für den Fahrmodus gültigen ODD-Grenzen (25) beschränkt wird. Verfahren nach einem der vorhergehenden Ansprüche, wobei in dem Fall, dass durch das Fremdfahrzeug (32) ein ODD-Merkmal (24) erkannt wird und das Fremdfahrzeug (32) durch eine Person in einem manuellen Fahrmodus geführt wird, eine von der Person beim Annähern an und/oder beim Passieren des ODD-Merkmals (24) durchgeführten Längsführung und/oder Querführung als ein Führungsprofil erfasst wird und das Führungsprofil dem Fahrmodus als ein in dem Fahrzeug (12) durch den Fahrmodus nachzubildendes Führungsprofil vorgegeben wird. Verfahren nach einem der vorhergehenden Ansprüche, wobei durch den Backend-Server (11) anhand der gesammelten ODD-Merkmale (24) und anhand des Grenzkriteriums eine fahrzeugindividuelle Umfeldkarte der ODD des Fahrmodus des Fahrzeugs (12) erzeugt und dem Fahrzeug (12) für eine zukünftige Routenplanung bereitgestellt wird. Verfahren nach einem der vorhergehenden Ansprüche, wobei durch den Backend-Server (11 ) über eine Bedienschnittstelle die ODD- Merkmale (24) an eine Bedienperson (44) ausgegeben werden und eine Nutzereingabe (46) der Bedienperson (44) empfangen wird und in Abhängigkeit von der Nutzereingabe (46) festgelegt wird, ob das ODD- Merkmal (24) das Grenzkriterium erfüllt. Verfahren nach einem der vorhergehenden Ansprüche, wobei für den Fall, dass durch ein gemessenes ODD-Merkmal (24) das Grenzkriterium unerfüllt ist, Maskierdaten (47), die signalisieren, dass dieses ODD-Merkmal (24) zu ignorieren ist, erzeugt und an das Fahrzeug (12) ausgesendet werden und eine ODD- Überwachungsroutine (50) des Fahrzeugs (12) mittels der Maskierdaten (47) konfiguriert wird, sodass bei Detektieren des ODD- Merkmals (24) dieses durch die ODD-Überwachungsroutine (50) des Fahrzeugs (12) ignoriert wird. Verfahren nach einem der vorhergehenden Ansprüche, wobei das Fremdfahrzeug (32) die Messung der ODD-Merkmale (24) bei fehlendem eigenem Fahrmodus oder bei deaktiviertem und/oder aktiviertem eigenem Fahrmodus durchführt. Verfahren nach einem der vorhergehenden Ansprüche, wobei in dem Fahrzeug (12) bei Annäherung an eine ODD-Grenze (25) und bevorstehendem Verlassen der ODD eine vorbestimmte Übergabemaßnahme zum Deaktivieren des Fahrmodus und Übergeben der Längsführung und/oder Querführung des Fahrzeugs (12) an einen Fahrer durchgeführt wird. Steuerschaltung (15) für ein Fahrzeug (12), wobei die Steuerschaltung (15) dazu eingerichtet ist, einen automatisierten und/oder assistierten Fahrmodus für das Fahrzeug (12) bereitzustellen und ODD-Parameter (33), welche für den Fahrmodus gültige ODD-Grenzen (25) einer ODD des Fahrmodus beschreiben und/oder zu messende ODD-Merkmale (24), welche die ODD-Grenzen (25) markieren, an einen Backend- Server (11 ) und/oder an zumindest ein Fremdfahrzeug (32) auszusenden und aus dem Backend-Server (11 ) und/oder dem zumindest einem Fremdfahrzeug (32) gemessene ODD-Merkmale (24) und/oder Kartendaten von aus gemessenen ODD-Merkmalen (24) geschätzten ODD-Grenzen (25) der ODD zu empfangen und damit einen Betrieb des Fahrmodus auf die für den Fahrmodus gültigen ODD durch Auslösen einer Übergabemaßnahme bei Erkennen einer Annäherung an eine ODD-Grenze (25) zu beschränken. Backend-Server (11) für ein Fahrzeug (12) mit einem automatisierten und/oder assistierten Fahrmodus, wobei der Backend-Server (11 ) dazu eingerichtet ist, aus dem Fahrzeug (12) über eine Kommunikationsverbindung (17) ODD-Parameter (33), welche für den Fahrmodus gültige ODD-Grenzen (25) einer ODD des Fahrmodus beschreiben und/oder zu messende ODD-Merkmale (24), welche die ODD-Grenzen (25) markieren, zu empfangen und zumindest ein dem Fahrzeug (12) vorausfahrendes Fremdfahrzeug (32) zum Messen der ODD-Merkmale (24) über eine jeweilige Kommunikationsverbindung (39) anzusteuern und die gemessenen ODD-Merkmale (24) und/oder
Kartendaten von aus gemessenen ODD-Merkmalen (24) geschätzten ODD-Grenzen (25) der ODD an das Fahrzeug (12) auszusenden. System (10) umfassend einen Backend-Server (11 ) nach Anspruch 11 und zumindest ein Fahrzeug (12) mit einer Steuerschaltung (15) nach
Anspruch 10.
PCT/EP2022/072444 2021-09-08 2022-08-10 Verfahren und steuerschaltung zum überprüfen, ob ein aktuell aktiver fahrmodus innerhalb seiner odd betrieben wird, sowie system und backend-server Ceased WO2023036545A1 (de)

Priority Applications (1)

Application Number Priority Date Filing Date Title
US18/689,049 US20240400111A1 (en) 2021-09-08 2022-08-10 Method and control circuit for checking, if a current active driving mode is operated within its odd, and system and backend server

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
DE102021123270.8 2021-09-08
DE102021123270.8A DE102021123270B3 (de) 2021-09-08 2021-09-08 Verfahren und Steuerschaltung zum Überprüfen, ob ein aktuell aktiver Fahrmodus innerhalb seiner ODD betrieben wird, sowie System und Backend-Server

Publications (1)

Publication Number Publication Date
WO2023036545A1 true WO2023036545A1 (de) 2023-03-16

Family

ID=83151764

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/EP2022/072444 Ceased WO2023036545A1 (de) 2021-09-08 2022-08-10 Verfahren und steuerschaltung zum überprüfen, ob ein aktuell aktiver fahrmodus innerhalb seiner odd betrieben wird, sowie system und backend-server

Country Status (3)

Country Link
US (1) US20240400111A1 (de)
DE (1) DE102021123270B3 (de)
WO (1) WO2023036545A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230166761A1 (en) * 2021-11-30 2023-06-01 Zenseact Ab Method and system for estimation of an operational design domain boundary

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102022212701A1 (de) 2022-11-28 2024-05-29 Robert Bosch Gesellschaft mit beschränkter Haftung Verfahren zum Erzeugen von Infrastrukturassistenzdaten
DE102023203101A1 (de) * 2023-04-04 2024-10-10 Zf Friedrichshafen Ag Computerimplementiertes Verfahren, Computerprogramm und System zur Überprüfung der Einhaltung von Betriebsrahmenbedingungen im operativen Einsatz eines automatisierten Fahrsystems

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102018107924A1 (de) * 2017-04-05 2018-10-11 Hyundai Motor Company Autonomes-Fahren-Steuerungssystem und Steuerungsverfahren unter Verwendung des gleichen
US20190184997A1 (en) 2017-12-19 2019-06-20 PlusAI Corp Method and system for risk based driving mode switching in hybrid driving
US20190243361A1 (en) * 2017-03-14 2019-08-08 Omron Corporation Drive switching determination apparatus, drive switching determination method, and program for drive switching determination
US20200241564A1 (en) 2019-01-25 2020-07-30 Uatc, Llc Proactive generation of tuning data for autonomous vehicle dispatch
EP3745376A1 (de) 2019-05-29 2020-12-02 Zenuity AB Verfahren und system zur bestimmung von fahrunterstützenden daten
DE102019209619A1 (de) * 2019-07-01 2021-01-07 Hyundai Motor Company Verfahren zum autonomen betreiben eines fahrzeugs, steuerungsvorrichtung für ein fahrzeug und fahrzeug
DE102021001096A1 (de) 2021-03-02 2021-05-20 Daimler Ag Verfahren zum Betrieb eines Fahrzeuges
DE102013210395B4 (de) 2013-06-05 2021-06-02 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Datenkommunikation zwischen Kraftfahrzeugen einerseits und einem zentralen Informationspool andererseits

Family Cites Families (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013210923A1 (de) 2013-06-12 2014-12-18 Robert Bosch Gmbh Vorausschauende Steuerung eines Kraftfahrzeugs
US9547989B2 (en) * 2014-03-04 2017-01-17 Google Inc. Reporting road event data and sharing with other vehicles
US11040725B2 (en) * 2015-09-04 2021-06-22 Inrix Inc. Manual vehicle control notification
DE102017219301A1 (de) 2017-10-27 2019-05-02 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Erhöhung der Sicherheit bei Gefahrensituationen betreffend den Straßenverkehr
JP7078660B2 (ja) * 2020-03-16 2022-05-31 本田技研工業株式会社 走行制御装置、車両、走行制御方法及びプログラム
CN112654549A (zh) * 2020-07-23 2021-04-13 华为技术有限公司 控制车辆驾驶模式切换的方法和装置

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013210395B4 (de) 2013-06-05 2021-06-02 Bayerische Motoren Werke Aktiengesellschaft Verfahren zur Datenkommunikation zwischen Kraftfahrzeugen einerseits und einem zentralen Informationspool andererseits
US20190243361A1 (en) * 2017-03-14 2019-08-08 Omron Corporation Drive switching determination apparatus, drive switching determination method, and program for drive switching determination
DE102018107924A1 (de) * 2017-04-05 2018-10-11 Hyundai Motor Company Autonomes-Fahren-Steuerungssystem und Steuerungsverfahren unter Verwendung des gleichen
US20190184997A1 (en) 2017-12-19 2019-06-20 PlusAI Corp Method and system for risk based driving mode switching in hybrid driving
US20200241564A1 (en) 2019-01-25 2020-07-30 Uatc, Llc Proactive generation of tuning data for autonomous vehicle dispatch
EP3745376A1 (de) 2019-05-29 2020-12-02 Zenuity AB Verfahren und system zur bestimmung von fahrunterstützenden daten
DE102019209619A1 (de) * 2019-07-01 2021-01-07 Hyundai Motor Company Verfahren zum autonomen betreiben eines fahrzeugs, steuerungsvorrichtung für ein fahrzeug und fahrzeug
DE102021001096A1 (de) 2021-03-02 2021-05-20 Daimler Ag Verfahren zum Betrieb eines Fahrzeuges

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230166761A1 (en) * 2021-11-30 2023-06-01 Zenseact Ab Method and system for estimation of an operational design domain boundary

Also Published As

Publication number Publication date
DE102021123270B3 (de) 2022-12-29
US20240400111A1 (en) 2024-12-05

Similar Documents

Publication Publication Date Title
EP3572293B1 (de) Verfahren zum unterstützen eines führens wenigstens eines kraftfahrzeugs und assistenzsystem
DE102014008578B4 (de) Verfahren zur Ermittlung von Positionsdaten zur Nutzung beim Betrieb eines Fahrzeugsystems eines Kraftfahrzeugs und Positionsdatenermittlungs- und-verteilssystem
EP3181422B1 (de) Verfahren und system zur automatischen steuerung eines folgefahrzeugs mit einem scout-fahrzeug
DE102017203654B4 (de) Verfahren zum Betreiben eines Fahrerassistenzsystems für ein Fahrzeug auf einer Straße und Fahrerassistenzsystem
DE102013212255A1 (de) Verfahren zum Austausch von Informationen zwischen mindestens zwei Fahrzeugen
EP4128187A1 (de) VERFAHREN UND EINE VORRICHTUNG ZUR IDENTIFIZIERUNG POTENTIELLER GEFAHRENSTELLEN IM STRAßENVERKEHR
DE102013012324A1 (de) Verfahren und Vorrichtung zur Fahrwegfindung
DE102016002230B4 (de) Verfahren zum Betrieb eines Kraftfahrzeugs und Kraftfahrzeug
DE102021123270B3 (de) Verfahren und Steuerschaltung zum Überprüfen, ob ein aktuell aktiver Fahrmodus innerhalb seiner ODD betrieben wird, sowie System und Backend-Server
DE102020117340A1 (de) Verfahren zur Umgebungserfassung mit wenigstens zwei unabhängigen bildgebenden Umgebungserfassungssensoren, Vorrichtung zur Durchführung des Verfahrens, Fahrzeug sowie entsprechend ausgelegtes Computerprogramm
DE10311241B4 (de) Verfahren und Einrichtung für die Spurführung eines Fahrzeugs
WO2019233777A1 (de) Fahrassistenzsystem
DE102015004605B4 (de) Verfahren zum Betrieb eines Steuersystems einer Mobileinheit und Mobileinheit
DE102021209315A1 (de) Verfahren zum Betreiben eines Infrastruktursystems zur Fahrunterstützung von zumindest teilautomatisiert geführten Kraftfahrzeugen
DE102014214505B4 (de) Verfahren zur Erstellung eines Umfeldmodells eines Fahrzeugs
DE102017208244A1 (de) System und verfahren
DE102014214507A1 (de) Verfahren zur Erstellung eines Umfeldmodells eines Fahrzeugs
DE102011083777A1 (de) Fahrerassistenzsystem und Verfahren zum Betreiben eines Fahrerassistenzsystems
EP2254104A2 (de) Verfahren zum automatischen Erkennen einer Situationsänderung
DE102016212786A1 (de) Fahrerassistenzsystem für ein Ego-Fahrzeug auf einem Weg eines Wegenetzes und Verfahren zum Betreiben des Fahrerassistenzsystems
DE102021208806B4 (de) Verfahren zum Warnen eines ersten Fahrzeugs bei einem Fehlverhalten des ersten Fahrzeugs mittels eines Warnsystems, Computerprogrammprodukt sowie Warnsystem
DE102022206348A1 (de) Verfahren und System zum Ermitteln von Sensor- und/oder Lokalisierungsfehlern
DE102020004192B4 (de) Verfahren zur Kommunikation eines zumindest teilweise autonom fahrenden Kraftfahrzeugs und einem Fußgänger mittels eines Systems, sowie System
DE102018207719A1 (de) Vorrichtung und Verfahren zum Betreiben eines automatisierten Fahrzeugs
DE102022210507A1 (de) Alarmsystem zur Warnung vulnerabler Verkehrsteilnehmer in einem vorgegebenen Straßenabschnitt

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 22762075

Country of ref document: EP

Kind code of ref document: A1

122 Ep: pct application non-entry in european phase

Ref document number: 22762075

Country of ref document: EP

Kind code of ref document: A1