DE102022201788A1 - Computer-implemented method and system for providing an automated driving function for a vehicle - Google Patents

Abstract

Measures are proposed that allow a vehicle (1), which is not equipped for autonomous driving according to level 3/4/5, under certain conditions, at least temporarily, with vehicle-external computer support and in compliance with safety specifications automated driving functions can use.For this purpose, a computer-implemented method for providing at least one automated driving function for a vehicle (1) is proposed, in which the actuator equipment of the vehicle (1) is detected, in which the current vehicle position is detected, in which it is determined which odometric information and/or which environmental information is available for the vehicle (1) and in which it is determined which resources are available for the calculation and exercise of automated driving functions. It is then determined which automated driving functions can be implemented at all on the basis of the actuator configuration of the vehicle (1), the available odometric information and/or environmental information and the available resources. Finally, the resources required for the calculation and execution of at least one realizable automated driving function are made available at least for a defined period of time.

Description

State of the art

The invention relates to a computer-implemented method for providing at least one automated driving function for a vehicle and a corresponding computer-implemented system.

The starting point of the present invention is a scenario for vehicle E/E (electrical/electronic) architectures, according to which there will be so-called economy variants with “slim” computers, which alone, i.e. inside the vehicle, can only offer limited functionality. However, vehicles with these economy E/E architectures will then be able to connect to a “digital twin” in the cloud/edge. Based on the vehicle data, more sophisticated calculations can also be carried out with the high computing power available there. The results of these calculations can then be sent back to the vehicle and functionally executed there.

For example, the idea of calculating vehicle functions in whole or in part using a computer external to the vehicle is already out DE 10 2019 213 562 A1 known.

• • Level 2: „Partial Driving Automation“ - Teilautomatisierung
• • Level 3: „Conditional Driving Automation“ - bedingte Automatisierung (Fallback: Fahrer)
• • Level 4: „High Driving Automation“ - Hochautomatisierung (Operational Design Domain ODD beschränkt, Fallback: System)
• • Level 5: „Full Automation“ - Vollautomatisierung

The SAE J3016 standard defines vehicle systems with various levels of automation, in particular

• • Level 2: "Partial Driving Automation" - partial automation
• • Level 3: "Conditional Driving Automation" - conditional automation (fallback: driver)
• • Level 4: "High Driving Automation" - high automation (operational design domain ODD limited, fallback: system)
• • Level 5: "Full Automation" - full automation

The different levels of automation place different demands on the vehicle hardware, such as sensors, control units, computing power, on-board network redundancy, etc., and consequently also on the vehicle software.

object of the invention

• • unter gewissen Bedingungen,
• • zumindest temporär,
• • mit Fahrzeug-externer Rechnerunterstützung, beispielsweise aus der „Edge/Cloud“,
• • unter Einhaltung von Sicherheitsvorgaben

automatisierte Fahrfunktionen nutzen kann.With the invention, a concept is proposed or measures that make it possible for a vehicle that is not equipped for autonomous driving according to level 3/4/5

• • under certain conditions,
• • at least temporarily,
• • with vehicle-external computer support, for example from the "Edge/Cloud",
• • in compliance with security requirements

can use automated driving functions.

essence and advantages of the invention

• • bei dem die Aktuatorausstattung des Fahrzeugs erfasst wird,
• • bei dem die aktuelle Fahrzeugposition erfasst wird,
• • bei dem ermittelt wird, welche odometrischen Informationen und/oder welche Umgebungsinformationen für das Fahrzeug zur Verfügung stehen,
• • bei dem ermittelt wird, welche Ressourcen für die Berechnung und Ausübung von automatisierten Fahrfunktionen zur Verfügung stehen;
• • bei dem dann ermittelt wird, welche automatisierten Fahrfunktionen auf Basis der Aktuatorausstattung des Fahrzeugs, der zur Verfügung stehenden odometrischen Informationen und/oder Umgebungsinformationen und der zur Verfügung stehenden Ressourcen realisierbar sind, und
• • bei dem die Ressourcen, die für die Berechnung und Ausübung mindestens einer realisierbaren automatisierten Fahrfunktion erforderlich sind, zumindest für eine definierte Zeitdauer bereitgestellt werden.

According to the invention, this is achieved with the aid of a computer-implemented method

• • in which the actuator equipment of the vehicle is recorded,
• • in which the current vehicle position is recorded,
• • in which it is determined which odometric information and/or which environmental information is available for the vehicle,
• • in which it is determined which resources are available for the calculation and execution of automated driving functions;
• • in which it is then determined which automated driving functions can be implemented on the basis of the vehicle's actuator equipment, the available odometric information and/or environmental information and the available resources, and
• • in which the resources required for the calculation and execution of at least one realizable automated driving function are made available at least for a defined period of time.

The concept on which the invention is based no longer regards the vehicle as a functionally self-contained unit that only uses the vehicle's own sensors for perception and the vehicle's own computing power for trajectory planning and control of the actuators in order to manage driving tasks in a given traffic situation. Instead, the vehicle is considered according to the invention as part of a networked overall system. This paradigm shift affects both perception and data processing for trajectory planning and vehicle control. The vehicle's own sensors are not only used for their own purposes. Rather, the recorded odometric information and/or environmental information is also made available to other road users. Accordingly, the vehicle itself can also access information sources from the networked overall system that are external to the vehicle in order to complete its information about the traffic situation gen. The same applies to computing power. If the vehicle's own computing power is not sufficient to handle a specific driving task, the vehicle can also use external resources if they are available when needed.

According to the invention, it has been recognized that the availability of vehicle-external means of perception, outsourced computing capacity and communication channels for the required data transmission within the overall system is heavily dependent on the utilization of the overall system, i.e. on how many road users in a spatial environment contribute perception data and computing power and transmission capacity claim. Furthermore, it has been recognized that, accordingly, the full scope of automated driving functions for all vehicles, regardless of their on-board equipment, cannot generally be implemented everywhere and at all times. The method according to the present invention addresses this problem by determining the information sources and resources available on the vehicle and external to the vehicle and identifying the automated driving functions that can be implemented with them. By reserving corresponding resources, the individual vehicle is then given the opportunity to use one or more of these automated driving functions.

The method according to the invention is preferably carried out by a higher-level entity, which can then make one or more support offers to the vehicle, depending on how many automated driving functions can be implemented in the respective situation. However, the method according to the invention can also be used in parallel by a number of higher-level entities. It would be conceivable, for example, for each of these higher-level entities to manage access to its own set of non-vehicle information sources and resources, and accordingly each of these higher-level entities also to generate individual support offers for the vehicle. The method according to the invention therefore provides the technical prerequisite for marketing automated driving functions by one or more competing providers, which is referred to as "Driving as a Service" (DaaS).

In any case, the method according to the invention ensures that the technical requirements for the implementation of an automated driving function are met and takes into account that a large part of the demanding tasks required for automated driving functions, such as environmental perception and interpretation as well as trajectory planning, can be outsourced. so that the vehicle does not have to be equipped with the full hardware and/or software technology for level 3/4/5 driving. Even emergency maneuvers for assuming a safe state in the event of an error can be outsourced, so that the driver does not have to be available as a fallback protection, as is the case with Level 3. The method according to the invention thus provides the technical prerequisite for vehicles without full Level 3/4/5 technology to be offered temporary “autonomous driving”, e.g. for the “boring” drive home from work in the evening.

A prerequisite for the realization of the concept according to the invention for providing an automated driving function is that the vehicle is integrated into the networked overall system via a bidirectional interface. The vehicle can communicate with a higher-level entity via such an interface. It can request information about the automated driving functions that can currently be implemented and support for their implementation. It proves advantageous if the vehicle also makes vehicle-specific information available to the higher-level entity on this occasion, such as information about the vehicle's own controllable actuators, which can be used to implement automated driving functions, and information about the current vehicle position and navigation information , such as the currently planned route and, if necessary, alternative routes. Furthermore, the sensor data recorded by the vehicle can be fed into the overall system via such a bidirectional interface and thus also made available to other road users.

Conversely, the vehicle can be controlled externally via the bidirectional interface if an automated driving function is to be implemented that goes beyond the functional scope of the vehicle. For this purpose, the bidirectional interface should be adaptive and enable different types of intervention, such as control by a central or local human tele-operator or by a so-called “AD kit” or Highly Automated Driving (HAD) system in the edge or cloud , e.g. based on a digital twin of the vehicle.

• - Abdeckung der Fahrstrecke mit fahrzeugfremden Perzeptionsmitteln zur Umfeldwahrnehmung - die Umfeldwahrnehmung sollte auf der gesamten Fahrstrecke möglichst mehrfach redundant sein;
• - Verfügbarkeit einer Kommunikationsverbindung in die Edge/Cloud entlang der gesamten Fahrstrecke zur Sicherstellung der erforderlichen Datenübertragung;
• - Fahrzeugkonfiguration im Hinblick auf ansteuerbare Aktorik, fahrzeugeigene Sensorik, Hardware- und Softwarekonfiguration für Planungszwecke, z.B. mittels Fahrzeug-Identifizierungsnummer (VIN);
• - Und ggf. auch zusätzliche Sicherheitsaspekte, wie

• ◯ Wetterbedingungen und deren Einfluss auf die Perzeption über den voraussichtlichen Zeitraum der Steuerung,
• ◯ astronomischen Daten, z.B. Sonnenstand, über den voraussichtlichen Zeitraum der Steuerung,
• ◯ Berücksichtigung von möglichen Sensor- bzw. Informationsausfällen und verfügbaren Mitigationsmaßnahmen.

As already mentioned, the feasibility of automated driving functions for a vehicle not only depends on its individual hardware and software equipment, but also on the current position of the vehicle and its planned route. An automated driving function and thus an external control is only released if the safety of an external control is guaranteed along the route is, ie if it can be carried out safely and without driver intervention. For this purpose, a compatibility check of route and vehicle is carried out under the current conditions, which includes the following aspects:

• - Coverage of the route with non-vehicle means of perception for the perception of the environment - the perception of the environment should be redundant as many times as possible over the entire route;
• - Availability of a communication connection to the edge/cloud along the entire route to ensure the required data transmission;
• - Vehicle configuration with regard to controllable actuators, on-board sensors, hardware and software configuration for planning purposes, eg using vehicle identification number (VIN);
• - And possibly also additional security aspects, such as

• ◯ weather conditions and their influence on perception over the expected period of control,
• ◯ astronomical data, e.g. position of the sun, over the probable control period,
• ◯ Consideration of possible sensor or information failures and available mitigation measures.

As an alternative or in addition to the compatibility test outlined above, individual routes could also be certified for specific vehicle configurations, for example after validation with a corresponding test vehicle.

• - Fahrzeugeigene Sensorik,
• - Sensorik weiterer Verkehrsteilnehmer,
• - Stationäre Infrastruktursensorik, insbesondere Video-Kameras, IR-Kameras, Radarsensoren, Lidar-Sensoren, Ultraschallsensoren Fahrbahnbelegungssensoren,
• - Mobile Infrastruktursensorik, insbesondere Drohnen zur Verkehrsüberwachung,
• - Unterhaltungselektronikgeräte in der Fahrzeugumgebung, insbesondere Mobiltelefone, Datenbrillen, Security-Kameras.

As part of the compatibility check, it is therefore checked which odometric information and/or which environmental information is available for the vehicle at the current vehicle position and in the area of the planned route. The following sources of information are advantageously taken into account:

• - vehicle sensors,
• - sensors of other road users,
• - Stationary infrastructure sensors, in particular video cameras, IR cameras, radar sensors, lidar sensors, ultrasonic sensors, lane occupancy sensors,
• - Mobile infrastructure sensors, especially drones for traffic monitoring,
• - Consumer electronics devices in the vehicle environment, in particular mobile phones, data glasses, security cameras.

• - Sicherheitsintegrität der Daten (z.B. ISO 26262, IEC 61508)
• - Konfidenz der Information
• - Zeitstempel, z.B. globale Zeit
• - Vertrauenswürdigkeit der Information
• - Bedingungen, unter denen diese Informationen ermittelt wurden und die u.U. einen Einfluss auf die Konfidenz/Qualität haben, wie z.B. Wetter, Ressourcenknappheit.

The basis for external control is the existence of a sufficiently secure environment model, which is used either by a tele-operator or by HAD control in the edge/cloud. In the event that the vehicle has sufficient sensors, such as cameras, but the complex environment modeling and planning cannot be carried out in the vehicle due to a lack of resources, these tasks could be carried out purely on the basis of the vehicle sensor data by a human tele-operator or a " Edge/Cloud”. For this, however, sufficient bandwidth from the vehicle and low latency of the wireless communication would have to be guaranteed. If the vehicle sensors do not provide sufficient odometric and/or environment information, the environment model can be aggregated in real time from a wide variety of information sources inside and outside the vehicle. The basis for this could be a so-called "spatial web" in which all environment-related parameters are collected, processed, checked for plausibility, provided with security guarantees regarding security integrity, correctness, timing, accuracy, trustworthiness, etc. and then published together with map information if necessary. This is also referred to as "knowledge-based distributed perception". In order to calculate the security guarantees, these information sources may have to provide metadata, e.g

• - Security integrity of the data (e.g. ISO 26262, IEC 61508)
• - Confidence of information
• - Time stamp, eg global time
• - Reliability of the information
• - Conditions under which this information was obtained and which may have an impact on the confidence/quality, such as weather, scarcity of resources.

The merging of the information and the determination of the security guarantees must then be done taking into account these metadata and constraints. With this central fusion, far more information than just sensor data can be taken into account, namely also deeper knowledge, such as more detailed and up-to-date movement models. In addition, higher computing capacities, e.g. for computationally intensive algorithms such as deep learning or particle filters, can be used, so that overall a high quality of the environment model for perception and prediction is achieved.

The environment model generated by "knowledge-based distributed perception" can be used by a human tele-operator as well as by an Edge/Cloud HAD controller as a basis for planning.

The environment model could be visualized for a tele-operator, in the simplest case via monitors. Alternatively, one could also use "augmented reality" glasses, ideally with a 360° view and visualization of additional information, such as movement vectors of other vehicles, marking of dangerous objects, etc.. For planning or control, the tele-operator could then be a human Machine Interface (HMI), such as a combination of steering wheel and pedals or a touch screen.

• - Eingriffe in die Perzeption bzw. das interne Umfeldmodells des Fahrzeugs und/oder
• - Eingriffe in die interne Verhaltens- und Bewegungsplanung des Fahrzeugs und/oder
• - Direkte Eingriffe in die Aktuatorik des Fahrzeugs, z.B. über eine Schnittstelle zum Fahrzeugführungsrechner.

If the planning is done automatically with the help of an edge/cloud HAD control, the environment model supplies the input data for the planner in the form of a multidimensional data structure, an "array"/"struct". All required calculations are performed by the Edge/Cloud HAD control outside of the vehicle. Depending on the vehicle configuration or current latencies, external control can be carried out via:

• - Interventions in the perception or the internal environment model of the vehicle and/or
• - interventions in the internal behavior and movement planning of the vehicle and/or
• - Direct intervention in the vehicle's actuators, eg via an interface to the vehicle control computer.

The availability, reliability, safety and security of the control interventions must be guaranteed and a safe emergency reaction must be available in the event of a fault, e.g. a safe stop or a safe emergency trajectory.

The vehicle is advantageously equipped with an HMI, via which the driver is provided with information about the feasibility of at least one automated driving function for at least one planned and/or alternative route. After the compatibility check has been carried out, routes or zones of the current availability of automated driving functions, for example, can be displayed to the driver on a map, together with so-called entry points. This designates zones in which the transfer to the external control is enabled.

The driver can then simply select one of these offers via a corresponding request signal. The required resources are then made available and the execution of the selected automated driving function is triggered.

The handover between manual driving and automated driving at an entry point must meet certain safety requirements. For this purpose, it can be provided, for example, that the driver repeatedly confirms his request signal, ie the transfer of control of the vehicle to an external control entity, through further actions. Only then is control handed over, either directly or after a synchronization phase, for which a separate controller is required.

The above-mentioned HMI is advantageously also used to display the current driving status, ie whether an automated driving function is active and, if so, which automated driving function it is.

Basically, there are different criteria for when the execution of an automated driving function should be terminated and also how driving control should then be handed over to the driver. The driver could initiate the handover, for example, with a stop signal that is transmitted to the external control authority. However, the execution of an automated driving function can also be terminated automatically as soon as the available odometric information and/or the available environmental information and/or the available resources are no longer sufficient to execute this automated driving function. In this case, the vehicle could be automatically switched to manual driving mode or to another automatic driving function, for which the available odometric information and/or the available environmental information and/or the available resources are sufficient.

Advantageously, the vehicle control is handed over to the driver after going through an abort procedure and/or at a so-called exit point. These are zones in which an external vehicle control must be terminated due to the compatibility check. As part of this termination procedure, a driver monitoring system can be used, for example, to check whether the driver is already sufficiently alert to take over control of the vehicle. The abort procedure could also provide that the vehicle must first be brought to a safe stop before the driver can take control of the vehicle again.

As already mentioned, the availability of a Communication connection to the edge/cloud checked along the entire route to ensure the required data transmission. This check includes, for example, the identification of geographical areas of reduced availability and the determination of redundancies resulting from the vehicle equipment in combination with the infrastructure. In addition to the availability of the communication link, the security of the wireless connection should always be guaranteed.

To simplify the method according to the invention, the compatibility check and thus also the offer of automated driving functions could be limited to previously defined driving situations, or more complicated driving situations could be excluded from the outset. For example, the release could be limited to "simple" ODDs, such as routes without pedestrians or cyclists, routes without oncoming traffic with physically separated lanes, routes without poorly visible areas, etc..

Furthermore, the vehicle functionality could be limited in automated driving, for example by limiting the vehicle maneuvers, such as excluding overtaking maneuvers, and/or "conservative" driving behavior, etc..

The vehicle's external controls could also be monitored, namely centrally in the cloud, locally in the edge and/or internally in the vehicle. Error reactions could then also be initiated here, such as minimum risk maneuvers. In addition, continuous calculations of emergency maneuvers, such as braking to a standstill, stopping in the lane, driving on the hard shoulder, could also be carried out here. If necessary, they are implemented using the vehicle's actuators. This can be controlled by the tele-operator, e.g. after being shown on a display, or centrally by the cloud or locally by the edge or by the vehicle's internal vehicle management computer.

character list

• 1 veranschaulicht die Funktionsweise eines erfindungsgemäßen Computer-implementierten Systems zum Bereitstellen mindestens einer automatisierten Fahrfunktion für ein Fahrzeug 1.
• 2 zeigt ein Flussdiagramm einer Ausführungsform des erfindungsgemäßen Computer-implementierten Verfahrens zum Bereitstellen mindestens einer automatisierten Fahrfunktion für ein Fahrzeug 1.

Advantageous embodiments and developments of the invention are explained below with reference to the figures.

• 1 illustrates the functioning of a computer-implemented system according to the invention for providing at least one automated driving function for a vehicle 1.
• 2 shows a flowchart of an embodiment of the computer-implemented method according to the invention for providing at least one automated driving function for a vehicle 1.

Description of exemplary embodiments

1 shows a vehicle 1 whose vehicle equipment enables automated driving functions according to level 2 of the SAE J3016 standard. For this purpose, the vehicle 1 is equipped with a corresponding sensor system for perception, with a data processing and control device for planning and controlling Level 2 driving maneuvers, and with a controllable actuator system for executing these driving maneuvers.

A prerequisite for implementing the concept according to the invention for providing automated driving functions that go beyond the actual scope of functions of the vehicle 1 is a higher-level entity in a cloud 3, which is also referred to below as a “Driving as a Service” (DaaS) manager . The vehicle 1 can communicate with the cloud 3 or the DaaS manager via a bidirectional interface 2 . Thus, the vehicle 1 can request information and support from the DaaS manager. Conversely, the vehicle 1 can also provide information or deliver it to the cloud 3 . Of particular interest for the DaaS manager is information about the vehicle equipment, such as the scope of the vehicle's own sensors, computing power and actuators, but also information about the current vehicle position and navigation information, such as the currently planned route and, if necessary, alternative routes. Furthermore, the sensor data recorded by the vehicle 1 can be fed into the cloud 3 via the bidirectional interface 2 and thus also made available to other road users not shown here. The bidirectional interface 2 is advantageously standardized so that the cloud-based infrastructure described here can be used by a wide variety of vehicle models. In addition, the interface 2 should be adaptive in order to allow different implementations of the DaaS manager to control the vehicle 1 .

The cloud 3 collects perception data from a wide variety of spatially distributed information sources 4 and makes the collected perception data available to a number of spatially distributed users, such as the vehicle 1 , which is indicated by the double arrows 5 and arrow 22 . The information sources 4 can be, for example, the sensors of other road users or stationary infrastructure sensors such as video cameras, IR cameras, radar sensors, lidar sensors, ultrasonic sensors and lane occupancy sensors. Information sources in the form of mobile infrastructure are also conceivable Door sensors, such as drones for traffic surveillance, and in the form of consumer electronics devices in the vehicle environment, such as mobile phones, data glasses and security cameras. These information sources 4 can then either place their sensor data directly in the cloud 3 or collect it in a local edge 41 which makes the locally collected perception data available to the cloud 3 . In 1 the perception and edge infrastructures along three different route options for the vehicle 1 are shown as examples.

In addition to storage capacity, the Cloud 3 also has computing capacity for processing the perception data, in particular for creating a reliable environment model and for calculating possible vehicle trajectories. This computing capacity can be made available to the vehicle 1 as needed or on request in order to be able to use automated driving functions that go beyond its own range of functions.

First, the DaaS manager checks which automated driving functions can be implemented at all for the vehicle 1 in a given situation. For this purpose, the DaaS manager determines on the basis of the current vehicle position and possibly a route plan which odometric information and/or which environmental information is available for the vehicle 1 along the planned route. Both the vehicle's own sensors and the vehicle-external information sources 4 are taken into account, as well as their confidence, integrity and data security. In addition, the DaaS manager determines which on-board and off-board resources are available for the calculation and execution of automated driving functions, taking into account not only the computing capacity but also the availability of transmission channels and latency effects along the planned route. Finally, the DaaS manager must also consider the actuator equipment of vehicle 1 in order to determine which automated driving functions can be offered to vehicle 1 in the current situation. According to the invention, the DaaS manager then provides the resources required for the calculation and execution of at least one realizable automated driving function, at least for a defined period of time.

In order to ensure safe navigation along a certain route, the external infrastructure, together with the vehicle's hardware and software, must provide a sufficient amount of sufficiently reliable environment and status data as well as resources that are sufficient to calculate a digital twin, an environment model and trajectory planning . The task of the DaaS manager is to determine what data and what resources are needed to offer automated driving functions, depending on the forecast conditions along the driving route, and to reserve these resources in advance to ensure that they are available when the vehicle has reached a certain point. If the availability of sufficient and sufficiently reliable data and computing resources for a specific automated driving function cannot be guaranteed, this cannot be offered by the DaaS Manager, but an automated driving function with a lower degree of automation may be offered. For example, a "level 3 service" in which the driver has to be ready to take over within a few seconds could still be feasible, while a "level 4 service" in which an external controller navigates the vehicle without driver intervention is not possible with the available resources is realizable.

In the exemplary embodiment described here, the automated driving functions that can be implemented are offered to the driver of the vehicle 1 via the interface 2 and a corresponding HMI. The driver can then select an automated driving function and hand over the vehicle control for this driving function to the DaaS manager, so that the vehicle 1 is controlled externally in a row. In-vehicle HMIs can be used as the HMI, such as an infotainment system, or a smartphone with a corresponding app.

The higher the degree of automation of the requested automated driving function, the more extensive is the use of resources external to the vehicle, both in terms of perception and computing power. Accordingly, the automated driving functions offered can also be priced differently. The price could depend on the degree of automation of the driving function offered, ie the service level, but also on the equipment of the requesting vehicle, ie how much the requesting vehicle contributes to the required perception and computing effort with its own hardware and software. In addition, the current demand for automated driving functions in a specific environment could be taken into account in the pricing, since it may not always be possible to satisfy all requests with the resources available in the cloud 3 . Thus, higher prices could be charged the more vehicles request the service offered by the DaaS manager. In addition, the pricing could depend on the level of difficulty of the route, as there is usually an increased level on more difficult routes Perception and computing effort must be driven. In the exemplary embodiment described here, the driver is offered options for automated driving functions with different prices for all three routes. The driver can therefore include the pricing here both in the choice of the route and in the decision as to whether and which automated driving function he would like to request. Conversely, the use of an automated driving function can also be terminated for cost reasons, or the driver switches to a cheaper automated driving function for cost reasons. In this context, it should also be mentioned that there could also be several competing providers for the service described above. With multiple providers, the DaaS manager could negotiate the price for provisioning and reservation. In order to achieve a lower total price, the DaaS manager can also suggest an alternative route to the customer.

The DaaS business model could also provide for a central "negotiation" of free/smooth/uninterrupted travel, e.g. by paying other road users to give way to an L3+ vehicle with limited ability to act.

Using the flowchart of 2 the inventive computer-implemented method for providing at least one automated driving function for a vehicle is explained in the context of the business model outlined above.

The driver of a vehicle whose vehicle equipment only enables automated driving functions according to level 2 of the SAE J3016 standard would like to use automated driving functions with a higher degree of automation according to level 3/4/5. To do this, the driver issues a service call in step 21 and thus requests external support from a cloud service, with which he communicates via a bidirectional interface and a DaaS manager.

In step 22, the DaaS manager then determines the equipment of the vehicle, namely with regard to the actuators for implementing automated driving functions, with regard to the sensors for determining odometric information and environmental information and with regard to the available computing power for determining an environment model and for trajectory planning.

In addition, in step 23 the DaaS manager determines the current vehicle position, the destination and several route alternatives.

Based on this, the DaaS manager determines in step 24 for each route alternative which external resources are additionally required in order to be able to implement automated driving functions according to level 3, 4 or 5 while ensuring all safety requirements.

Then, in step 25, the DaaS manager determines for each route alternative which external resources are available for the calculation and execution of the respective automated driving functions and which automated driving functions can be implemented at all based on the equipment of the vehicle and the available resources.

In step 26, the DaaS manager then determines the costs for the required external resources and corresponding service prices for each service offer—route alternative with realizable automated driving function—and provides the external resources required in each case at least for a defined period of time.

In step 27, the DaaS manager transmits these service offers together with the service prices to the vehicle, where they are displayed to the driver in step 28.

In step 29 the driver can then select a service offer in order to reserve or bindingly book the external resources required for this in step 30 .

The exemplary embodiments described above make it clear that the computer-implemented method according to the invention and the system according to the invention for providing at least one automated driving function for a vehicle form the technical basis for a DaaS business model.

QUOTES INCLUDED IN DESCRIPTION

This list of documents cited by the applicant was generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Patent Literature Cited

• DE 102019213562 A1 [0003]

Claims (14)

Computer-implemented method for providing at least one automated driving function for a vehicle (1), • in which the actuator equipment of the vehicle (1) is recorded, • in which the current vehicle position is recorded, • in which it is determined which odometric information and/or which environmental information is available for the vehicle (1), • in which it is determined which resources are available for the calculation and execution of automated driving functions; • in which it is then determined which automated driving functions can be implemented on the basis of the actuator equipment of the vehicle (1), the available odometric information and/or environmental information and the available resources, and • in which the resources required for the calculation and execution of at least one realizable automated driving function are made available at least for a defined period of time. procedure after claim 1 , characterized in that at least individual functions of the automation levels defined according to the SAE J3016 standard • Level 2: "Partial Driving Automation" - partial automation, • Level 3: "Conditional Driving Automation" - conditional automation (fallback: driver), • Level 4: " High Driving Automation" - high automation (operational design domain ODD limited, fallback: system) and/or • Level 5: "Full Automation" - full automation are offered as automated driving functions. Procedure according to one of Claims 1 or 2 , characterized in that the actuator equipment is detected by the vehicle (1) provides information about the vehicle's own controllable actuators. Procedure according to one of Claims 1 until 3 , characterized in that the vehicle (1) provides navigation information, in particular information about at least one currently planned route and / or information about at least one alternative route. Procedure according to one of Claims 1 until 4 , characterized in that the following information sources are taken into account when determining the odometric information and/or the environmental information: a. On-board sensors, b. sensors of other road users, c. Stationary infrastructure sensors, in particular video cameras, IR cameras, radar sensors, lidar sensors, ultrasonic sensors, lane occupancy sensors, d. Mobile infrastructure sensors, especially drones for traffic monitoring, e. Consumer electronics devices in the vehicle environment, in particular mobile phones, data glasses, security cameras. procedure after claim 5 , characterized in that the confidence and/or the integrity and/or the data security of at least one information source of odometric information and/or environmental information is evaluated and that this evaluation is taken into account when determining which automated driving functions can be implemented. Procedure according to one of Claims 1 until 6 , characterized in that when determining which resources are available for the calculation and execution of automated driving functions, the vehicle's own resources and/or vehicle-external resources and/or capacities of transmission channels are taken into account, which are connected to the vehicle via at least one communication interface (2). (1) are connected. Procedure according to one of Claims 1 until 7 , characterized in that when determining which automated driving functions can be implemented, latency aspects are taken into account in the calculation and execution of automated driving functions, which can be attributed to the use of the respective available resources. Procedure according to one of Claims 4 until 8th , characterized in that the navigation information is taken into account when determining which odometric information and/or environmental information is available, and/or when determining which resources are available for the calculation and execution of automated driving functions. Procedure according to one of Claims 4 until 9 , characterized in that information about the feasibility of at least one automated driving function is made available to the vehicle (1) for at least one planned and/or alternative route. Procedure according to one of Claims 1 until 10 , characterized in that providing and / or running an automated Driving function is triggered by at least one request signal of the vehicle (1). Procedure according to one of Claims 1 until 11 , characterized in that the execution of an automated driving function is terminated, a. by at least one stop signal from the vehicle (1) or b. as soon as the available odometric information and/or the available environmental information and/or the available resources are no longer sufficient to carry out the automated driving function. procedure after claim 12 , characterized in that the vehicle (1) is then automatically transferred to a manual driving mode or to another automatic driving function, for the realization of which the available odometric information and/or the available environmental information and/or the available resources enough. Computer-implemented system for providing at least one automated driving function for a vehicle (1) according to a method according to one of Claims 1 until 13 .

Images