Method, computer program and apparatus for invoking a teleoperated driving session

Abstract

Method, computer program and device for invoking a remotely operated driving session. The present application relates to a method, computer program and device for invoking a remotely operated driving session for a vehicle equipped with an automated driving function. The present application also relates to a vehicle equipped with an automated driving function, which utilizes such a method or device. In a first step, an upcoming situation that may require a remotely operated driving session is identified (10). In addition, a quality of service for communication between the vehicle and a control center for a location where the remotely operated driving session should be performed is predicted (11). The speed of the vehicle is then reduced (12) to the maximum drivable speed for a remotely operated driving session with the predicted quality of service. Once it is confirmed that a remotely operated driving session is required, the remotely operated driving session is started (13).

Description

Technical Field

[0001] The present invention relates to a method, a computer program and an apparatus for invoking a remotely operated driving session for a vehicle equipped with an automated driving function. The present invention also relates to a vehicle equipped with an automated driving function, which utilizes such a method or apparatus. Background Art

[0002] Remote-operated driving is gaining more and more attention. Remote-operated driving in this context means that an external operator remotely controls the vehicle. The external operator is located in a control center. There can be a large distance between the control center and the vehicle. The control center and the vehicle are connected via a radio communication system and its backhaul. Mainly, the radio communication system is part of a public mobile communication system such as LTE (Long Term Evolution) or 5G.

[0003] Remote driving is a safety-related, time-critical application. The main requirements for the exchange of information are low latency, high data rate and high reliability.

[0004] Autonomous driving (also called self-driving, automated driving or piloted driving) is the largely autonomous movement of driverless transport systems, vehicles and mobile robots. There are different degrees of autonomous driving. In Europe, various transport authorities (e.g. the German Federal Institute for Road Systems (Bundesanstalt für Straßenwesen)) have defined the following stages of autonomy:

[0005] Level 0: “Driver only”, the driver drives, steers, accelerates, brakes, etc. by himself.

[0006] Level 1: Certain assistance systems assist in vehicle operation, including cruise control systems such as ACC (Automatic Cruise Control).

[0007] Level 2: Partial automation, in which automatic parking, following functions, general longitudinal guidance, acceleration, deceleration, etc. are taken over by assistance systems, including collision avoidance.

[0008] Level 3: High automation. The driver does not have to continuously monitor the system.

[0009] The vehicle independently performs functions such as triggering of turn signals, lane changes and tracking. The driver can assist with other things, but if requested, the driver must take over control within the warning period.

[0010] Level 4: Full automation. The guidance of the vehicle is permanently performed by the system. If the system is no longer able to handle the task, the driver can be asked to take over control.

[0011] Level 5: No driver required. No human intervention is required other than setting targets and activating the system.

[0012] A slightly different definition of the levels is known from the Society of Automotive Engineers (SAE). In this regard, reference is made to the SAE J3016 standard. Such a definition may also be used instead of the one given above.

[0013] Remote-operated driving may become a key technology in order to solve the problems related to level 4 and level 5 driving vehicles. Autonomous vehicles make their decisions based on the perception of their environment and predetermined traffic rules. However, it may happen that the autonomous vehicle is no longer able to continue its planned route, for example due to incorrect interpretation of the environment, sensor failure, poor road conditions or unclear traffic conditions (such as accidents or construction sites). In such a case, the vehicle requires external instructions from others (such as external operators located in a control center) to resolve the situation. During remote-operated driving, the vehicle will be remotely driven by an external operator until the vehicle is able to resume its autonomous driving operation.

[0014] In this regard, US2017 / 0308082A1 discloses a method for assisting an autonomous vehicle. When the vehicle is operating autonomously, if an event occurs, it can alert a control center, or open a dialog with the control center. The event can include a variety of situations, including a deadlock situation. A deadlock situation may occur when the autonomous vehicle software analysis reaches a threshold uncertainty level or a threshold risk level, or when there is a failure of autonomous control.

[0015] US2019 / 0049948A1 discloses a method for operating a vehicle by switching between an autonomous control system within the vehicle and a remote operator. When operating under full autonomy, the vehicle operating system can check for faulty operating conditions. When such a condition is detected, the vehicle operating system can simultaneously reduce the vehicle speed and send a distress call to the remote operator.

[0016] WO2018 / 141415A1 discloses a method for implementing remote control of a vehicle. The method is performed by a vehicle data provider. When the vehicle data provider detects a need for manual assistance by a remote operator, a vehicle data stream related to a time before the time when remote control is initiated is obtained. The vehicle data is modified by adjusting the duration of playback. Then, the modified vehicle data is provided to the operator for playback.

[0017] US2017 / 0192423A1 discloses a method for remote assistance of an autonomous vehicle. Sensor data from an autonomous vehicle is collected and situations requiring assistance are identified. Based on the sensor data, an assistance request is generated, which is transmitted to a remote assistance interface. Then, a response to the assistance request is received and processed.

[0018] It is known that the performance of remote-operated driving is related to the performance of the communication link. This link includes the air interface between the vehicle and the base station and also includes the connection through the operator backbone network (i.e., the core network). It is worth noting that the driving parameters (e.g., maximum speed) used for remote-operated driving must be adapted to the quality of communication with the command center. With this solution for remote-operated driving, when a deadlock occurs, the vehicle needs to stop, contact the control center and start the remote-operated driving session. This causes an interruption in the driving experience. Smooth takeover is still impossible. Summary of the invention

[0019] It is an object of the present invention to provide an improved solution for invoking a teleoperated driving session for a vehicle.

[0020] This object is achieved by a method according to claim 1, by a computer program implementing this method according to claim 9 and by an apparatus according to claim 10. The dependent claims contain advantageous further developments and improvements of the present principle as described below.

[0021] According to a first aspect, a method for invoking a remote operation driving session for a vehicle equipped with an automated driving function comprises the following steps:

[0022] - Identify upcoming situations that may require a teleoperated driving session;

[0023] - predicting the quality of service for communication between the vehicle and the control center for the location where the teleoperation driving session should be performed; and

[0024] - Reducing the speed of the vehicle to a maximum drivable speed for the teleoperated driving session with the predicted quality of service.

[0025] Thus, a computer program comprises instructions which, when executed by at least one processor, cause the at least one processor to perform the following steps for invoking a teleoperation driving session for a vehicle equipped with an automated driving function:

[0026] - Identify upcoming situations that may require a teleoperated driving session;

[0027] - predicting the quality of service for communication between the vehicle and the control center for the location where the teleoperation driving session should be performed; and

[0028] - Reducing the speed of the vehicle to a maximum drivable speed for the teleoperated driving session with the predicted quality of service.

[0029] The term computer must be understood in a broad sense. In particular, it also includes electronic control units, embedded devices and other processor-based data processing devices.

[0030] For example, the computer program code can be made available for electronic retrieval or can be stored on a computer readable storage medium.

[0031] According to another aspect, an apparatus for invoking a teleoperation driving session for a vehicle equipped with an automated driving function includes:

[0032] - an identification module configured to identify an impending situation that may require a teleoperated driving session;

[0033] a prediction module configured to predict a quality of service for communication between the vehicle and the control center for a location where a teleoperation driving session should be performed; and

[0034] - A speed control module configured to reduce the speed of the vehicle to a maximum drivable speed for the teleoperated driving session with a predicted quality of service.

[0035] According to the invention, the automated vehicle not only determines that a teleoperated driving session may be required in the near future, for example due to a deadlock situation, but also predicts the quality of service of the communication link that will be used during this teleoperated driving session. Based on the given situation, in particular the predicted quality of service, a maximum drivable speed is calculated for the teleoperated driving session. Then, if necessary, as a preparatory action, the speed of the automated vehicle is reduced to the maximum drivable speed. The prior reduction of the speed to the maximum drivable speed avoids potential emergency braking of the automated vehicle and thus results in a smoother takeover.

[0036] In order to predict the quality of service for a communication link, there are several options. According to the first option, the quality of service can be estimated by the vehicle itself. For example, in an article by G. Jornod et al. (“Packet Inter-Reception Time Conditional Density Estimation Based on Surrounding Traffic Distribution”, IEEE Open Journal of Intelligent Transportation Systems, 2020, No. 1, pp. 51-62), a prediction model for packet reception time group (platoon) messages in IEEE 802.11p networks is proposed. According to the second option, the quality of service can be provided by the network. In Release 16, the 3GPP standard setting organization introduced a solution that allows cellular 5G communication systems to notify V2X (Vehicle-to-Everything) applications of the expected or estimated quality of service changes before they actually occur. This procedure is called quality of service sustainability analysis in the 3GPP standard and helps V2X applications decide in an active and safe way whether there is a need for application changes. Further details can be found, for example, in 3GPP Technical Specification TS 23.287: “Architecture enhancements for 5G System (5Gs) to support Vehicle-to-Everything (V2X) services (v16.1.0, Release 16)” or 3GPP Technical Specification TS 23.288: “Architecture enhancements for 5G System (5Gs) to support network data analytics services (v16.2.0, Release 16)”.

[0037] In an advantageous embodiment, the teleoperated driving session is started as soon as it is confirmed that a teleoperated driving session is required. As described above, the automated vehicle reduces its speed to the maximum drivable speed in preparation for a situation in which a teleoperated driving session may be required. Of course, it may later turn out that no teleoperated driving session was in fact necessary. However, as soon as it is confirmed that a teleoperated driving session is actually required, the automated vehicle starts this session. In this way, the control center is sufficiently contacted in advance to ensure timely takeover of control by the control center.

[0038] In an advantageous embodiment, the probability of requiring a remote-operated driving session is determined, wherein when the probability is above a first threshold, an upcoming situation in which a remote-operated driving session may be required is identified. In real operating conditions, it will usually be difficult to make a clear decision at an early stage as to whether a remote-operated driving session will actually be required. Therefore, relying on probability is desirable. For example, an automated vehicle can continuously determine and evaluate the probability of a deadlock situation. Once this probability is high enough, the necessary actions for handling the deadlock are initiated, i.e., the vehicle collects information about the predicted quality of service and reduces speed accordingly. Of course, information about the predicted quality of service can also be continuously collected regardless of the deadlock situation. The value of the first threshold can be selected so that a compromise is achieved between a smooth reduction in the vehicle speed and the number of unnecessary speed reductions. If the first threshold is set very low, the automated vehicle will reduce its speed in many cases where a remote-operated driving session is not actually required. If the first threshold is set very high, it may happen that the automated vehicle will need to brake quite sharply in order to achieve the maximum drivable speed in time. The determination of an appropriate value for the first threshold is determined by a skilled person.

[0039] In order to determine the probability of requiring a remote-operated driving session, the perception uncertainty of the vehicle sensor can be used. The vehicle sensor (e.g., LIDAR or RADAR sensor) generally provides a confidence level. The higher the perception uncertainty, the higher the probability that a remote-operated driving session will be required. Alternatively or additionally, environmental information can be evaluated. For example, the area in which the vehicle is traveling can be considered. The probability of requiring a remote-operated driving session is higher in urban areas than on highways or in rural areas. Similarly, it can be analyzed whether other vehicles in this area are already in a remote-operated driving session. If this is the case, the probability of requiring a remote-operated driving session is higher. For example, the information required for this analysis can be shared via broadcast. Other environmental information that can be evaluated is weather conditions and traffic information. For severe weather conditions such as snow, hailstones (hell stone), fog, etc., the probability of requiring a remote-operated driving session is higher than the probability for a sunny day. Similarly, in the case of detecting traffic congestion or high vehicle density, the probability is higher than that of low vehicle density. The above analysis can be combined with a statistical, empirical or learning-based approach. Such an approach of considering conditions regarding perception uncertainty and environmental information leads to the frequency of teleoperation driving sessions.

[0040] In an advantageous embodiment, the requirement for a remotely operated driving session is confirmed when the probability is above a second threshold. Confirming the necessity of a remotely operated driving session based on the probability has the advantage that the control center can be contacted fairly early, which increases the time available for the operator to take over control. The value of the second threshold can be chosen so that a compromise between a smooth handover to the control center and the number of remotely operated driving sessions that are unnecessarily called up is achieved. As mentioned above, the determination of a suitable value for the second threshold is at the discretion of the technician. Of course, confirmation of the necessity of a remotely operated driving session can also be obtained by user input (for example, by the driver actuating a button).

[0041] In an advantageous embodiment, the probability is derived from sidelink communications from other vehicles or from data obtained by sensors of the vehicle. For example, a RADAR (Radio Detection and Ranging) sensor, a LIDAR (Light Detection and Ranging) sensor, or a camera for 2D and 3D image acquisition may be used to determine that the road is blocked. Alternatively or additionally, the autonomous vehicle may receive relevant information from other vehicles, such as from a vehicle that is closer to the potential deadlock situation or from a vehicle that has driven through a deadlock situation in a teleoperated driving session.

[0042] In an advantageous embodiment, the quality of service is predicted using previously determined data about the quality of service, data from side link communications originating from other vehicles, or environmental data for the location where the teleoperated driving session should be performed. The previously determined data about the quality of service can be obtained, for example, from previous measurements of the vehicle or from data provided by a service provider. For example, the autonomous vehicle may have collected information about the quality of service of the communication link for a specific location during a previous journey, or it may receive such information from other vehicles. Alternatively, the service provider may provide map data including such information. When environmental data are used to predict the quality of service, these data preferably include information about the location or construction of the communication infrastructure. Based on such data, it can be analyzed whether interference caused by buildings is to be expected for a specific location.

[0043] Advantageously, an autonomous or semi-autonomous vehicle comprises an apparatus according to the invention or is configured to perform a method according to the invention for invoking a teleoperated driving session. In this way, the vehicle exhibits an improved behavior when a teleoperated driving session needs to be invoked. The vehicle may be any type of vehicle, for example a car, a bus, a motorcycle, a commercial vehicle (particularly a truck), an agricultural machine, a construction machine, a rail vehicle, etc. More generally, the invention may be used in land vehicles, rail vehicles, water vehicles and aircraft. This includes robots and drones in the expression. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] Further features of the present invention will become apparent from the following description and appended claims, taken in conjunction with the accompanying drawings.

[0045] Figure 1 schematically illustrates a method for invoking a teleoperated driving session for a vehicle equipped with an automated driving function;

[0046] Figure 2 Schematically illustrates a first embodiment of an apparatus for invoking a remotely operated driving session for a vehicle equipped with an automated driving function;

[0047] Figure 3 schematically illustrates a second embodiment of an apparatus for invoking a remotely operated driving session for a vehicle equipped with an automated driving function;

[0048] Figure 4 The basic architecture of V2V and V2X communication systems is shown in the figure;

[0049] Figure 5 A block diagram showing an electronic system of a vehicle;

[0050] Figure 6 An exemplary deadlock situation as an application scenario of remote-operated driving is shown;

[0051] Figure 7 showing an estimated probability of a deadlock along a path of a vehicle equipped with an automated driving function;

[0052] Figure 8 showing a predicted quality of service communicated with a control center along a path of a vehicle equipped with the automated driving function; and

[0053] Fig. 9 A comparison between speed profiles with and without the present solution is shown. DETAILED DESCRIPTION

[0054] This description illustrates the principles of the present disclosure. Thus, it will be appreciated that those skilled in the art will be able to devise various arrangements that, although not explicitly described or shown herein, embody the principles of the present disclosure.

[0055] All examples and conditional language recited herein are intended for teaching purposes to help readers understand the principles of the present disclosure and the concepts contributed by the inventors to further understand the art, and should be construed as not being limited to such specifically recited examples and conditions.

[0056] In addition, all statements and specific examples of the principles, aspects and embodiments of the present disclosure are intended to cover their structural and functional equivalents. In addition, such equivalents are intended to include currently known equivalents and equivalents developed in the future, that is, any elements that perform the same function developed, regardless of structure.

[0057] Thus, for example, it will be appreciated by those skilled in the art that the diagrams presented herein represent conceptual views of illustrative circuitry embodying the principles of the disclosure.

[0058] The functions of the various elements shown in the figures can be provided by using dedicated hardware and hardware associated with appropriate software capable of executing software. When provided by a processor, the functions can be provided by a single dedicated processor, by a single shared processor, or by multiple individual processors, some of which can be shared. In addition, the explicit use of the term "processor" or "controller" should not be interpreted as exclusively referring to hardware capable of executing software, and may implicitly include, but is not limited to, digital signal processor (DSP) hardware, read-only memory (ROM), random access memory (RAM), and non-volatile storage devices for storing software.

[0059] Other hardware, conventional and / or custom, may also be included. Similarly, any switches shown in the figures are conceptual only. Their functions may be implemented through the operation of program logic, through dedicated logic, through the interaction of program control and dedicated logic, or even manually, with the particular technique being selected by the implementer as more specifically understood from the context.

[0060] In the claims of the present invention, any element represented as a means for performing a specified function is intended to encompass any means of performing that function, including, for example, a combination of circuit elements that perform that function or any form of software (thus including firmware, microcode, etc.) combined with appropriate circuitry for running that software to perform the function. The disclosure as defined by such claims lies in the fact that the functionality provided by the various recited components is combined and brought together in the manner required by the claims. It is therefore considered that any components that can provide those functionalities are equivalent to those shown herein.

[0061] Figure 1A method for invoking a remotely operated driving session for a vehicle equipped with an automated driving function according to the present invention is schematically illustrated. In a first step, an upcoming situation is identified 10 in which a remotely operated driving session may be required. For this purpose, a probability of requiring a remotely operated driving session may be determined. Then, when the probability is above a first threshold, an upcoming situation is identified 10 in which a remotely operated driving session may be required. The probability may be obtained from sidelink communications from other vehicles or from data obtained by sensors of the vehicle. In addition, a quality of service for communication between the vehicle and a control center is predicted 11 for a location where the remotely operated driving session should be performed. The quality of service may be predicted 11 using previously determined data on the quality of service, data from sidelink communications originating from other vehicles, or environmental data for the location where the remotely operated driving session should be performed. The previously determined data on the quality of service may be obtained, for example, from previous measurements of the vehicle or from data provided by a service provider. The environmental data preferably includes information about the location or construction of the communication infrastructure. Then, the speed of the vehicle is reduced 12a to the maximum drivable speed for a remotely operated driving session with the predicted quality of service. Once it is confirmed that a remotely operated driving session is required, the remotely operated driving session is opened 13. For example, when the probability that the remote-operated driving session is required is higher than the second threshold, it may be confirmed that the remote-operated driving session is required.

[0062] Figure 2A block diagram of a first embodiment of an apparatus 20 according to the present invention is schematically illustrated, the apparatus 20 being used to call a remotely operated driving session for a vehicle equipped with an automated driving function. The apparatus 20 has an input 21 for receiving data, for example, from sensors 150, 151, 182, 186 of the vehicle, from other vehicles 41 or from a base station 210. An identification module 22 is configured to identify an upcoming situation that may require a remotely operated driving session based on the received data. For this purpose, the identification module 22 may be configured to determine a probability that a remotely operated driving session is required. Then, when the probability is above a first threshold, an upcoming situation that may require a remotely operated driving session is identified. Similarly, it may be confirmed that a remotely operated driving session is required when the probability is above a second threshold. The probability may be obtained from sidelink communications from other vehicles or from data obtained by sensors of the vehicle. The identification module 22 may also be configured to start the remotely operated driving session once it is confirmed that a remotely operated driving session is required. The prediction module 23 predicts a quality of service PQoS for communication between the vehicle and the control center for a location where the remotely operated driving session should be performed. For example, the prediction module 23 may be configured to predict the quality of service PQoS using previously determined data on the quality of service, data from sidelink communications originating from other vehicles, or environmental data for the location where the teleoperated driving session should be performed. The previously determined data on the quality of service may be obtained, for example, from previous measurements of the vehicle or from data provided by a service provider. The environmental data preferably includes information on the location or construction of the communication infrastructure. The speed control module 24 then reduces the speed of the vehicle to a maximum drivable speed v for a teleoperated driving session with the predicted quality of service PQoS. max The control signals generated by the control module 24 or the identification module 22 may be further provided to the autonomous driving control unit 184 via the output 27. A local storage unit 26 is provided, for example for storing data during processing. The output 27 may also be combined with the input 21 into a single bidirectional interface.

[0063] The recognition module 22, the prediction module 23, and the speed control module 24 may be controlled by a controller 25. A user interface 28 may be provided to enable a user to modify the settings of the recognition module 22, the prediction module 23, the speed control module 24, or the controller 25. The recognition module 22, the prediction module 23, the speed control module 24, and the controller 25 may be embodied as dedicated hardware units. Of course, they may also be fully or partially combined into a single unit, or implemented as software running on a processor (e.g., a CPU or a GPU).

[0064] exist Figure 3, a block diagram of a second embodiment of an apparatus 30 according to the present invention is illustrated, the apparatus 30 being used to invoke a remotely operated driving session for a vehicle equipped with an automated driving function. The apparatus 30 comprises a processing device 31 and a memory device 32. For example, the apparatus 30 may be a computer, an electronic control unit or an embedded system. The memory device 32 has stored instructions which, when executed by the processing device 31, cause the apparatus 30 to perform steps according to one of the methods described. Thus, the instructions stored in the memory device 32 tangibly embody an instruction program executable by the processing device 31 to perform program steps as described herein according to the present principles. The apparatus 30 has an input 33 for receiving data. Data generated by the processing device 31 is made available via an output 34. In addition, such data may be stored in the memory device 32. The input 33 and the output 34 may be combined into a single bidirectional interface.

[0065] As used herein, the processing device 31 may include one or more processing units, such as a microprocessor, a digital signal processor, or a combination thereof.

[0066] The local storage unit 26 and the memory devices 32 may include volatile and / or non-volatile storage areas and storage devices, such as hard disk drives, optical drives, and / or solid-state memory.

[0067] In the following, reference will be made to Figures 4 to 9 Preferred embodiments of the present invention are explained in more detail.

[0068] Figure 4 The basic architecture of a V2V (vehicle to vehicle) and V2X (vehicle to everything) communication system is shown. Reference numeral 40 denotes a vehicle, which in this example is a car, in particular a passenger car. The vehicle 40 is equipped with an on-board connectivity module 160 including a corresponding antenna, so that the vehicle 40 can participate in any form of mobile communication services. Figure 4 As shown in FIG. 1 , the vehicle 40 may transmit and receive signals to and from a base station 210 of a mobile communication service provider using a V2N (Vehicle to Network) communication link Uu.

[0069] Such a base station 210 can be an eNodeB (evolved Node B) base station of an LTE mobile communication service provider or a gNB (next generation Node B) base station of a 5G mobile communication provider. The base station 210 and corresponding equipment are part of a mobile communication network having multiple network cells, each of which is served by a base station 210.

[0070] Figure 4The base station 210 in is positioned close to the main road on which the vehicle 40 travels. Of course, other vehicles 41 can also travel on said road. In the terminology of LTE, a mobile terminal corresponds to a user equipment, which allows a user to access network services, connect to the UTRAN (UMTS (Universal Mobile Telecommunications System) Terrestrial Radio Access Network) or Evolved UTRAN via a radio interface. Typically, such a user equipment corresponds to a smartphone. Of course, mobile terminals are also used in the vehicles 40, 41 in the form of the onboard connectivity modules 160. These onboard connectivity modules 160 are LTE, 5G or any other communication modules, which enable the vehicles 40, 41 to receive mobile data in the downlink direction and to send such data in the uplink direction or in the direct device-to-device direction.

[0071] In the case of an LTE mobile communication system, the evolved UTRAN is composed of a plurality of eNodeBs, which provide E-UTRA user plane protocol terminals (i.e., PDCP (Packet Data Convergence Protocol), RLC (Radio Link Control), MAC (Media Access Control) and PHY (Physical Layer)) and control plane protocol terminals (i.e., RRC (Radio Resource Control)) toward user equipment. The eNodeBs are interconnected via the so-called X2 interface. The eNodeBs are also connected to the EPC (Evolved Packet Core) 200 via the so-called S1 interface, more specifically, to the MME (Mobility Management Entity) via the S1-MME interface, and to the serving gateway via the S1-U interface.

[0072] Regarding this general architecture, Figure 4 The eNodeB is shown connected to the EPC 200 via an S1 interface, and the EPC 200 is connected to the Internet 300. A control center computer 320, to which the vehicles 40, 41 send messages and from which the vehicles 40, 41 receive messages, is also connected to the Internet 300. In the field of cooperative and autonomous driving, the control center computer 320 is usually located in a traffic control center where operators for the teleoperated driving sessions requested by the vehicles 40, 41 are working. Finally, an infrastructure network component is also shown, in this case a roadside unit 310. For ease of implementation, it is assumed that all components have been assigned Internet addresses (usually in the form of IPv6 addresses) so that packets transmitting messages between components can be routed accordingly.

[0073] Various interfaces of the LTE network architecture are standardized. In this regard, reference is made to the various LTE specifications, which are publicly available for the purpose of fully disclosing further implementation details.

[0074] The vehicles 40, 41 may also be equipped with components for observing their surroundings. Depending on the application, their sensor systems for capturing environmental objects are based on different measurement methods. Among others, widespread technologies are RADAR, LIDAR, cameras for 2D and 3D image acquisition, and ultrasonic sensors.

[0075] Since autonomous driving is on the rise, more data needs to be exchanged between the vehicles 40, 41, for example using the V2V communication link PC5, and more data also needs to be exchanged between the vehicles 40, 41 and the network. The communication systems for V2V and V2X communications need to be adapted accordingly. The 3GPP standard setting organization has and is publishing features for the new generation of 5G cellular mobile communication systems, including V2X features. From infotainment to collaborative driving, a large number of vehicle use cases have been designed. Depending on the application, the requirements for the access link Uu in the V2N communication range change dramatically. When it comes to safety-related, time-critical applications (such as remote-operated driving) in which the command center takes over certain driving functions of the vehicle, the requirements are for the exchange of information with low latency, high data rate and high reliability.

[0076] Figure 5 A block diagram of an onboard electronic system of a vehicle is schematically shown. A part of the onboard electronic system is an infotainment system, which comprises a touch-sensitive display unit 50, a computing device 60, an input unit 70 and a memory device 80. The display unit 50 is connected to the computing device 60 via a data line 55 and comprises a display area for displaying variable graphic information and an operator interface (touch-sensitive layer) arranged above the display area for inputting commands by a user. The input unit 70 is connected to the computing device 60 via a data line 75. Reference numeral 71 denotes a button which allows the driver to manually request a remotely operated driving session if the vehicle is blocked and the driver wants the support of a remotely operated driving operator to find a way out of the blocked situation. If other manual control techniques are used, the dedicated button 71 is not needed. This includes selecting an option in a user menu displayed on the display unit 50, detecting a command by means of voice recognition or using gesture control components.

[0077] The memory device 80 is connected to the computing device 60 via a data line 85. In the memory device 80, a pictogram catalog and / or a symbol catalog is stored together with the pictograms and / or symbols for possible overlay of additional information.

[0078] Other parts of the infotainment system, such as a camera 150, a radio 140, a navigation device 130, a phone 120, and an instrument cluster 110, are connected to the computing device 60 via a data bus 100. As a data bus 100, a high-speed variant of a CAN (controller area network) bus according to ISO standard 11898-2 can be used. Alternatively, an Ethernet-based bus system such as IEEE 802.03cg can be used. Bus systems that implement data transmission via optical fiber are also available. Examples are the MOST bus (Media Oriented System Transport) or the D2B bus (Home Digital Bus). For inbound and outbound wireless communications, the vehicle is equipped with an onboard connectivity module 160. It can be used for mobile communications, such as mobile communications according to the 5G standard.

[0079] Reference numeral 172 denotes an engine control unit. Reference numeral 174 denotes an ESC (Electronic Stability Control) unit, and reference numeral 176 denotes a transmission control unit. The networking of such control units, all of which are assigned to the category of the powertrain, usually takes place with the CAN bus 104. Since various sensors are installed in a motor vehicle and these sensors are no longer connected only to individual control units, such sensor data are also distributed to individual control devices via the bus system 104.

[0080] Modern vehicles can include additional components, such as additional sensors for scanning the surroundings, for example, LIDAR sensors 186 or RADAR sensors 182 and additional cameras 151, for example, front cameras, rear cameras or side cameras. Such sensors are increasingly used in vehicles for observing the environment. Additional control devices such as ADC (autopilot control) units 184 can be provided in vehicles. RADAR sensors 182 and LIDAR sensors 186 can have a scanning range of up to 250 meters, while cameras 150, 151 can cover a range from 30 meters to 120 meters. Components 182 to 186 are connected to another communication bus 102, for example, an Ethernet bus, due to the higher bandwidth of another communication bus 102 for data transmission. An Ethernet bus suitable for the special needs of automotive communication is standardized in the IEEE 802.1Q specification. In addition, a large amount of information about the environment can be received from other vehicles via V2V communication. Especially for those vehicles that are not in the sight of the observing vehicle, it is very advantageous to receive information about their position and movement via V2V communication.

[0081] Reference numeral 190 denotes an on-board diagnostic interface connected to the other communication bus 106 .

[0082] For the purpose of transmitting the vehicle-related sensor data to another vehicle or to a control center computer via the onboard connectivity module 160, a gateway 90 is provided. This gateway 90 is connected to the different bus systems 100, 102, 104 and 106. The gateway 90 is suitable for converting the data it receives via one bus into the transmission format of another bus, so that it can be distributed using the packets specified for the respective other bus. In order to forward this data to the outside, i.e. to another vehicle or to a control center computer, the onboard connectivity module 160 is equipped with a communication interface to receive these data packets and convert them in turn into the transmission format of the appropriate mobile radio standard.

[0083] Figure 6 An exemplary deadlock situation is shown as an application scenario of teleoperation driving. A truck 42 blocks a one-way road. The following vehicle 40 is an autonomous vehicle with level 4 or level 5 autonomous driving capabilities that needs to bypass this obstacle. The autonomous driving functionality needs to comply with all traffic regulations, including traffic signs and traffic lights, etc. Since the autonomous driving function cannot choose to drive on the sidewalk 330 to bypass the truck 42, the vehicle 40 will remain behind the truck 42 and wait until the truck 42 moves forward. However, this may take several hours, for example, if the truck 42 stops unintentionally due to a breakdown or road accident. In order to overcome this deadlock situation, the vehicle 40 needs to drive on the sidewalk 330 to continue its planned route. To do this, it is necessary to call a teleoperation driving session at the control center computer 320 using a connection via the roadside unit 310 and the Internet 300. According to the present solution for teleoperation driving, considering the situation and information of the quality of service communicated during the teleoperation driving session, the vehicle 40 will stop, contact the control center, and then reach the maximum drivable speed. As can be seen, the building 340 constitutes an obstacle for communication with the roadside unit 310 , ie the quality of service will be negatively affected by this building 340 .

[0084] In contrast, according to the present solution, when the autonomous vehicle 40 approaches a deadlock situation, it first identifies an impending situation that may require a teleoperated driving session. To this end, the autonomous vehicle 40 may continuously determine and assess the probability of a deadlock occurring along its path. Figure 7 The figure schematically shows the Figure 6As can be seen, the probability increases along the path. When the probability of deadlock exceeds the first threshold th1, the automatic vehicle 40 further collects information about the predicted quality of service PQoS for the communication between the vehicle 40 and the control center. Of course, the predicted quality of service PQoS can also be determined continuously regardless of any probability of deadlock. Figure 6 The predicted service quality PQoS for the case Figure 8 As can be seen, there is a drop in the predicted quality of service PQoS due to the presence of the building 340. When the drop in the predicted quality of service PQoS coincides with an increase in the deadlock probability, the autonomous vehicle 40 changes its driving settings to set the maximum drivable speed v to 1 in the teleoperated driving session in this environment. max In addition, once it is confirmed that a deadlock will occur (for example, because the probability of deadlock is higher than the second threshold value th2), the automated vehicle 40 prepares for a remote-operated driving session. The speed is reduced to the maximum drivable speed v for the remote-operated driving session. max And start the remote driving session in advance to avoid emergency braking and waiting time that would occur without this solution. Fig. 9 A comparison between the speed curve with the present solution (solid line) and the speed curve without the present solution (dashed line) is shown in . The initial speed of the vehicle when approaching the deadlock situation is V0.

[0085] Reference Numbers

[0086] 10 Identify situations where telepiloting may be required

[0087] 11 Predicting Service Quality

[0088] 12 Reduce speed to maximum drivable speed

[0089] 13 Start a remote driving session

[0090] 20 Installation

[0091] 21 Input

[0092] 22 Identification Module

[0093] 23 Prediction Module

[0094] 24 Speed ​​Control Module

[0095] 25 Controller

[0096] 26 Local storage unit

[0097] 27 Output

[0098] 28 User Interface

[0099] 30 Devices

[0100] 31 Processing equipment

[0101] 32 Memory devices

[0102] 33 Input

[0103] 34 Output

[0104] 40 Transportation

[0105] 41 Other means of transportation

[0106] 42 Truck

[0107] 50 Display Units

[0108] 55 Data line to display unit

[0109] 60 Computing devices

[0110] 70 Input Units

[0111] 71 Button

[0112] 75 Data line to input unit

[0113] 80 memory cells

[0114] 85 Data lines to memory cells

[0115] 90 Gateway

[0116] 100 First data bus

[0117] 102 Second data bus

[0118] 104 Third data bus

[0119] 106 Fourth data bus

[0120] 110 Instrument cluster

[0121] 120 Phone

[0122] 130 Navigation equipment

[0123] 140 Radio

[0124] 150 Camera

[0125] 151 Other Cameras

[0126] 160 Onboard Connectivity Module

[0127] 172 Engine Control Unit

[0128] 174 Electronic stability control unit

[0129] 176 Transmission Control Unit

[0130] 182 RADAR sensor

[0131] 184 Automatic driving control unit

[0132] 186 LIDAR Sensor

[0133] 190 On-board diagnostic interface

[0134] 200 Evolved Packet Core

[0135] 210 Base Station

[0136] 300 Internet

[0137] 310 Roadside Unit

[0138] 320 Control Center Computer

[0139] 330 Sidewalk

[0140] 340 Buildings

[0141] PC5 V2V communication link

[0142] PQOS Predicted Quality of Service

[0143] S1 S1 interface

[0144] Uu V2N communication link.

Claims

1. A method for invoking a teleoperation driving session for a vehicle (40) equipped with an automated driving function, the method comprising: - identifying (10) an impending deadlock situation that may require a teleoperated driving session; - predicting (11) a quality of service (PQoS) for communication between the vehicle (40) and a control center for a location where a teleoperated driving session should be performed; as well as - reducing (12) the speed of the vehicle (40) to a maximum drivable speed for a teleoperated driving session with a predicted quality of service (PQoS) to avoid potential emergency braking of the vehicle (40).

2. The method according to claim 1, further comprising: Once it is confirmed that the remote-operated driving session is desired, the remote-operated driving session is initiated (13).

3. The method according to claim 1, further comprising: A probability of requiring a teleoperated driving session is determined (10), wherein when the probability is above a first threshold, an impending deadlock situation that may require a teleoperated driving session is identified (10).

4. The method according to claim 3, wherein: When the probability is above a second threshold, the teleoperation driving session is confirmed to be required.

5. The method according to claim 3 or 4, wherein: The probability is derived from sidelink communications from other vehicles (41) or from data obtained by sensors (150, 151, 182, 186) of the vehicle (40).

6. The method according to any one of the preceding claims 1 to 4, wherein: The quality of service (PQoS) is predicted using previously determined data on the quality of service, data from sidelink communications originating from other vehicles (41), or environmental data for the location where the teleoperated driving session should be performed.

7. The method according to claim 6, wherein: The previously determined data on the quality of service are obtained from previous measurements of the vehicle (40) or from data provided by a service provider.

8. The method according to claim 6, wherein: The environmental data comprises information about the location or construction of the communication infrastructure.

9. A computer program product storing a computer program including instructions which, when executed by a computer, cause the computer to perform a method according to any one of claims 1 to 8 for invoking a remotely operated driving session for a vehicle (40) equipped with an automated driving function.

10. A device (20) for invoking a teleoperation driving session for a vehicle (40) equipped with an automated driving function, the device (20) comprising: - an identification module (22) configured to identify (10) an impending deadlock situation that may require a teleoperated driving session; a prediction module (23) configured to predict (11) a quality of service (PQoS) for communication between the vehicle (40) and a control center for a location where the teleoperation driving session should be performed; as well as - A speed control module (24) configured to reduce (12) the speed of the vehicle (40) to a maximum drivable speed for a teleoperated driving session with a predicted quality of service (PQoS) to avoid potential emergency braking of the vehicle (40).

11. A vehicle (40) equipped with an automatic driving function, characterized in that: The vehicle (40) comprises the apparatus (20) according to claim 10, or is configured to perform the method according to any one of claims 1 to 8 for invoking a teleoperated driving session.

Images