TRAINING A SELF-DRIVING VEHICLE

Abstract

A computer-implemented method, comprising: a detection of the road surface condition of a first roadway by one or more sensors belonging to a vehicle; a detection of an evasive maneuver carried out in response to the detection of the road surface condition by one or more sensors belonging to the vehicle; Determining whether the evasive maneuver successfully avoided the road surface condition, by means of a computer belonging to the vehicle; Saving a recording of the evasive maneuver and the road surface condition in response to the computer's determination of whether the evasive maneuver was a successful attempt to avoid the road surface condition; and as a reaction to a determination that one or more vehicles are exposed to the road surface conditions encountered by the vehicle, training one or more computers belonging to one or more other vehicles to perform the evasive maneuver, the evasive maneuver is designed to cause at least one tire on the vehicle to deflate.

Description

BACKGROUND

[0001] The present invention relates generally to the field of vehicles and in particular to the field of self-driving vehicles (SDVs). More specifically, the present invention further relates to the field of handling self-driving vehicles during collision events.

[0002] Self-driving vehicles (SDVs) are vehicles capable of autonomously navigating private and / or public spaces. Using a system of sensors that detect the SDV's position and / or surroundings, logic integrated into or associated with the SDV controls its speed, propulsion, braking, and steering based on the sensor-detected position and environment.

[0003] In this context, several published documents already exist. Document DE 10 2016 216 199 A1 describes a method for dynamically modifying an active safety system in a motor vehicle. This method detects the traffic situation in which the motor vehicle is operating. The detection of the traffic situation is based on sensor information from the motor vehicle. Furthermore, the probability of a critical driving situation occurring for the motor vehicle is determined based on the detected traffic situation. Document JP 2012 - 194 864 A describes a device and a method for preventing a vehicle collision. The corresponding device is installed on the vehicle and predicts the possibility of a collision risk based on the surrounding moving vehicles.Finally, document DE 10 2014 210 607 A1 also describes a method and a control system for controlling a motor vehicle in the event of a hazardous situation. For this purpose, an evaluation system with a number of detection units identifies a potential accident object and / or accident subjects, and based on this detection, automatic control commands are generated that influence the operation of the vehicle in a way that reduces damage. A number of control units are also used for this purpose.

[0004] Despite the progress already made, there remains a need to further increase the safety of automatically controlled vehicles in order to significantly improve the safety of occupants or other participants in the transaction. SUMMARY

[0005] This task is solved by the subject matter of the independent patent claims. Further details are provided in the dependent patent claims.

[0006] In a computer-implemented method of the present invention, one or more sensors belonging to a vehicle detect a road surface condition of a first lane, and the vehicle performs an evasive maneuver to avoid the detected road surface condition. Upon one or more processors determining that the evasive maneuver was successful, a record of the successful maneuver and the road surface conditions is stored in a database. After the record is stored in the database, one or more computers belonging to one or more vehicles are trained to perform the evasive maneuver in response to a determination that the one or more vehicles are exposed to the road surface condition encountered by the vehicle.

[0007] Other embodiments of the present invention include a computer program product and a computer system. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] The following describes embodiments of the invention with reference to the accompanying drawings, which are to be understood as merely exemplary and in which: Fig. 1 represents an exemplary system according to one or more embodiments of the present invention; Fig. 2 illustrates a driver of a vehicle performing an evasive maneuver according to one or more embodiments of the present invention; Fig. 3 illustrates an exemplary process according to one or more embodiments of the present invention; Fig. 4 an exemplary vehicle performing a maneuver according to one or more embodiments of the present invention; Fig. 5 additional details of one or more in Fig. 4 illustrated vehicles; Fig. 6 illustrates an exemplary arrangement of sensors in an SDV according to one or more embodiments of the present invention; Fig. 7 different crumple zones of an SDV as used according to one or more embodiments of the present invention; Fig. 8 illustrates a further exemplary process according to one or more embodiments of the present invention; Fig. 9 represents a cloud computing environment according to one or more embodiments of the present invention; and Fig. 10 abstraction model layers of a cloud computing environment according to one or more embodiments of the present invention. DETAILED DESCRIPTION

[0009] With regard to the characters and in particular to Fig. Figure 1 shows a block diagram of an exemplary system and network according to one or more embodiments of the present invention. The exemplary system and network shown for and within a computer 101, such as the hardware and / or software shown, can be partially or completely replaced by a Fig. 1 software deployment server shown 149 or other systems 155; and / or one in Fig. 4 monitoring system 401 shown; and / or one in Fig. The 5 SDV on-board computers shown are used.

[0010] With regard to Fig. Figure 1 includes an exemplary computer 101 comprising a processor or processors 103, which is / are operatively connected to a system bus 105. Although a single processor and core are shown, the processor(s) 103 may contain or use multiple processors, one or more of which may have one or more processor cores 123. A video adapter 107, which operates / supports a display 109 (which may be a touch-sensitive screen capable of receiving touch input), is also connected to the system bus 105. The system bus 105 is connected via a bus bridge 111 to an input / output (I / O) bus 113. An I / O interface 115 is connected to the I / O bus 113. The I / O interface 115 enables data transfer with various I / O units, including a keyboard 117, a speaker 119, a data storage slot 121 (for storage units such as e.g.(may include CD-ROM drives, multimedia interfaces, etc.), a transceiver 123 capable of sending and transmitting wireless electronic messages, sensors 153 capable of identifying traffic and road conditions in the vicinity of a vehicle, and one or more external USB ports 125. Although the ports connected to the I / O interface 115 may have any format known to a person skilled in computer architecture, in one or more embodiments some or all of these ports are USB (Universal Serial Bus) ports.

[0011] As shown, a network interface 129 is also connected to the system bus 105. The network interface 129 can be a hardware network interface, such as a network interface card (NIC). The computer 101 is able to exchange data with a software delivery server 149 and / or other systems 155 via the network interface 129 and a network 127. The network 127 can (but is not limited to) include one or more external networks, such as a wide area network (WAN) and / or a network of networks, such as the internet, and / or one or more internal networks, such as an Ethernet network or a virtual private network (VPN). In one or more embodiments, the network 127 includes a wireless network, such as a WLAN network, and a cellular network. An exemplary embodiment in a network cloud environment is described with regard to the Fig. 9 and Fig. 10 explained.

[0012] Looking again at Fig. 1 is also a hard disk drive interface 131 connected to the system bus 105. The hard disk drive interface 131 provides an interface with a hard disk drive 133. In one embodiment, the hard disk drive 133 is non-volatile memory and occupies a system memory 135 (e.g., random access memory, RAM) that is also connected to the system bus 105. The system memory 135 can be considered a lowest level of volatile memory in the computer 101. The system memory 135 can include (not shown) additional, higher levels of volatile memory, such as a cache, registers, and buffers, without being limited to these. Data occupying the system memory 135 includes the computer 101's operating system 137 and application programs 143.

[0013] The operating system 137 includes a shell 139 to provide transparent user access to resources such as application programs 143. The shell 139 is generally a program that provides an interpreter and an interface between the user and the operating system. Specifically, the shell 139 (sometimes also called the command processor) can execute commands entered into a command-line user interface or via a file. In other words, the shell 139 can act as a command interpreter. Although the shell 139 is a line-based, text-based user interface, the present invention equally well supports other types of user input, such as graphical, speech, gestural input, etc. As shown, the shell 139 can be considered the highest level of an operating system software hierarchy.The shell can also provide a prompt, interpret commands entered via keyboard, mouse or other user input media, and send the interpreted command(s) to the appropriate (e.g., deeper) levels of the operating system (e.g., a kernel 141) for processing.

[0014] As shown, the operating system 137 also includes the kernel 141, which contains (hierarchically) lower functional levels for the operating system 137. Some examples of kernel functions (not to be understood as limitations) include: providing basic services required by other parts of the operating system 137 and application programs 143, e.g., memory management, process and task management, disk management, and mouse and keyboard management.

[0015] The application programs 143 include a renderer, which is shown as an example of a browser 145. The browser 145 includes (not shown) program modules and commands that enable a WWW (World Wide Web) client (i.e., the computer 101) to send and receive network messages to and from the network 127 (e.g., the Internet using HTTP (Hypertext Transfer Protocol) messaging), thus enabling data transmission with the software delivery server 149 and other systems.

[0016] In some embodiments, the application programs 143 in the system memory of the computer 101 include a program 147 for training the on-board computers of self-driving vehicles (Program for Training Self Driving Vehicle On-board Computers, PTSDVOC). In some embodiments, the system memory 135 can be shared and / or the application programs 143 can be distributed to one or more software deployment servers 149 or other systems. As shown, the PTSDVOC 147 includes program instructions (software) designed to implement processes and / or functions according to the present invention, such as those relating to the Fig. 2 to 8 described. In some embodiments, the PTSDVOC 147 is downloaded from the software deployment server 149 (on demand or "just-in-time," so that the software in the PTSDVOC 147 is only downloaded when its execution is required). In one embodiment of the present invention, the software deployment server 149 performs all functions pertaining to the present invention (e.g., the execution of the PTSDVOC 147), so that the computer 101 does not need to use its own internal data processing resources to execute the PTSDVOC 147.

[0017] The hardware elements depicted in Computer 101 are not to be understood as an exhaustive list, but rather as representative of essential components required by the present invention. For example, Computer 101 may include alternative memory units such as flash memory, magnetic cartridges, DVDs (Digital Versatile Discs), Bernoulli removable disks, and the like. These and other variations are to be understood as falling within the conceptual essence and scope of the present invention.

[0018] Fig. Figure 2 illustrates a method for determining and evaluating the effectiveness of an evasive maneuver taken by a vehicle. In some embodiments, one or more steps of the method are performed by one or more processors and / or hardware. In some embodiments of the present invention, this (initial) evasive maneuver is performed by a human driver of the human-driven vehicle, and in some embodiments of the present invention, the evasive maneuver is performed by an on-board computer of a self-driving vehicle. As shown and described in Block 204, after a starting block 202, one or more sensors in a vehicle detect an oncoming vehicle during a near-miss event.A camera (mounted either on a fixed unit next to a roadway or in the vehicle taking the evasive action) records the near-miss event. An example of the video recording is shown in Box 216. A "near-miss" event is defined as the avoidance of a collision between two vehicles due to an evasive action taken by one of the vehicles. Although it should be clear that this could also be called a "near-hit event" (since the two vehicles "almost collide"), the term "near hit" is usually used to describe two objects that just barely miss each other, which is why the more common term is used here.

[0019] In block 206, one or more processors extract the trajectory of the oncoming vehicle based on the video shown in field 216 and / or sensor information. As shown, for example, in field 218, such extracted information may include timestamps, viewing angles, the distance between vehicles (e.g., from the camera recording the video), the vehicles shown in the video, and / or other (not shown) sensor data. In some embodiments, one or more processors (e.g., in a surveillance computer such as the one described below) may Fig. 4 described monitoring system 401) detect whether the vehicles collide, and if not, how far apart they missed each other.

[0020] In block 208, one or more processors compare the visual trajectory of the oncoming vehicle, for example, using a global positioning system (GPS) belonging to the camera that recorded the video, with a road network or with one or more of the vehicles in the video ("map matching"). This allows the system to match the recorded near-miss event with a specific map / position, as shown in the example in field 220. In some embodiments, such matching can enable future recommendations, for example, that other vehicles (such as SDVs) should take the same type of evasive action. In block 210, one or more processors can determine (e.g., characterize) the nature of a near-miss event (e.g., whether it occurred at a road intersection or due to a lane change by one or more vehicles, etc.).

[0021] In Block 212, one or more processors assess the effectiveness of the evasive maneuver performed by one of the vehicles shown in the video. For example, while an evasive maneuver may have avoided a collision with another vehicle, the abrupt movement of the maneuver may have resulted in a pedestrian being struck and injured, or it may have damaged the vehicle performing the evasive maneuver (e.g., by striking a solid object, by subjecting a mechanical system or the vehicle's tires to excessive stress, etc.).

[0022] The process ends with termination block 214.

[0023] Fig. Figure 3 represents a further exemplary embodiment of a method according to the present invention.

[0024] As shown, after starting block 301, one or more sensors (e.g., a camera, a microphone, a motion detector, etc.) located in a vehicle and / or on a fixed mount next to a roadway or as part of one or more in Fig. 4 of the roadway sensors shown (408 are mounted) in block 303, a roadway condition of a first roadway. As in Fig. As shown in Figure 4, cameras in a vehicle 402 (which in one or more embodiments of the present invention is a vehicle driven by a person, while in one or more other embodiments it is a self-driving vehicle) detect, for example, lighting, darkness, rain, snow, sleet, ice, etc. on a roadway 404 on which the vehicle 402 is currently driving.

[0025] In block 305, one or more sensors (e.g., a camera, an accelerometer, a microphone, etc.) in the vehicle detect an evasive maneuver initiated by the vehicle (e.g., vehicle 402). Fig. 4) is carried out in response to the detection of a road surface condition that poses a traffic hazard (e.g., a Fig. Vehicle 406 (shown in section 4) can operate on the first lane. With regard to the... Fig. Four examples illustrate this type of traffic hazard: another vehicle with which the vehicle will immediately collide if no evasive action is taken; a pedestrian with whom the vehicle will immediately collide if no evasive action is taken; a fixed object (e.g., a pothole, an obstacle such as an object that has fallen from another vehicle, etc.) with which the vehicle will immediately collide if no evasive action is taken; and so on. However, this example assumes that the vehicle takes an evasive action to avoid the traffic hazard.

[0026] In block 307, one or more processors determine whether the evasive maneuver successfully avoided the road condition (i.e., whether the vehicle avoided a traffic hazard without causing significant damage to another person, object, the vehicle itself, etc.).

[0027] If the evasive maneuver was successful, query blocks 309 and 311 store a record / description of the successful maneuver and the road surface condition (at the time of the evasive maneuver) in a database (which is located, for example, within the... Fig. 4 monitoring system 401 shown is located or belongs to it).

[0028] However, if the evasive maneuver was unsuccessful (e.g., if it resulted in the vehicle hitting the traffic hazard and / or causing damage to a pedestrian, another vehicle, etc.), a record / description of the unsuccessful maneuver, along with the respective road conditions (at the time of the evasive maneuver), is stored in a database in block 313 (which is located, for example, within the... Fig. 4 monitoring system 401 shown is located or belongs to it).

[0029] If the evasive maneuver was unsuccessful, in some embodiments an SDV (which is, for example, currently being trained) may either not be informed about the evasive maneuver or may receive a description of the unsuccessful evasive maneuver along with explicit instructions not to use it if the SDV is confronted with a similar traffic hazard under similar road conditions.

[0030] Following block 313, block 315 prevents the description of this unsuccessful maneuver from ever being transmitted to an onboard processor in an SDV that is currently being trained. In some embodiments, the description of this unsuccessful maneuver is transmitted to the onboard processor in the SDV, but with explicit instructions to the SDV not to use the unsuccessful maneuver.

[0031] After saving the recording of the successful maneuver and the road condition to the database (block 311), the process continues with block 317. In block 317, one or more processors (e.g., within the section discussed below regarding...) determine... Fig. 6 described SDV on-board computer 601), that a self-driving vehicle (SDV) is located on a roadway, encountering the roadway condition of the first roadway, and that the SDV is exposed to the roadway condition (i.e., a traffic hazard) that the vehicle encountered on the first roadway. In a further embodiment, it can be determined that one or more computers belonging to one or more vehicles are exposed to the roadway conditions that the vehicle encountered.

[0032] When the SDV (or the one or more vehicles) is on the lane that encounters the road surface condition of the first lane (i.e., when it is exposed to the traffic hazard that the vehicle encountered on the first lane), an onboard processor (e.g., part of the one in Block 319) is activated. Fig. 6 shown on-board computer 601) in the SDV (e.g. the one in Fig. 4 SDVs shown) trained to perform the successful maneuver that was carried out by the vehicle to avoid the road condition.

[0033] The procedure ends with (termination) block 321.

[0034] With regard to Fig. 4 and Fig. Figure 5 shows an exemplary embodiment of a system according to the present invention. For the sake of clarity and solely for this example, the system described in Figure 5 is described as follows: Fig. 5 described as SDV 412 and what is referred to there, in the vehicle 412 (from Fig. 4) contain or be part of it. It should also be clear that one or more in Fig. The 5 elements shown can also be used by other vehicles, e.g., vehicle 402 in a configuration as an SDV.

[0035] With regard to Fig. 5 The SDV 412 has an on-board computer 501 that can autonomously control one or more operations of the SDV 412. According to instructions from a driving mode unit 507, the SDV 412 can be operated either in a manual or autonomous mode. In some embodiments, the driving mode unit 507 is a dedicated hardware unit that can selectively instruct the SDV on-board computer 501 to operate the SDV 412 in an autonomous mode or in a manual mode.

[0036] In autonomous mode, the SDV 412 can generally be operated without input from a human driver, so that the engine, steering mechanism, braking system, horn, signaling devices, etc., are controlled by the SDV control processor 503, which is controlled by the SDV on-board computer 501. The SDV on-board computer 501 thus processes inputs from the navigation and control sensors 509 and the driving mode unit 507 (indicating that the SDV 412 should be controlled autonomously). In other words, in autonomous mode, input from a human driver to the SDV control processor 503 and / or to physical SDV control mechanisms 505 is not required.

[0037] As mentioned, the SDV on-board computer 501 uses outputs from the navigation and control sensors 509 to control the SDV 412. The navigation and control sensors 509 include hardware sensors that 1) determine the position of the SDV 412; 2) detect other cars and / or obstacles and / or physical structures in the vicinity of the SDV 412; 3) measure the speed and direction of the SDV 412; and 4) provide any other inputs necessary to safely control the movement of the SDV 412.

[0038] With regard to feature 1), determining the position of SDV 412, this can be done using a positioning system such as the one in Fig. The positioning system shown in Figure 1 can achieve this. The positioning system 151 can use a GPS, which utilizes satellites stationed in space that provide positioning signals. These signals are triangulated by a GPS receiver to determine a three-dimensional geophysical position of the SDV 412. The positioning system 151 can also use, either alone or in conjunction with a GPS, physical motion sensors such as accelerometers (which measure the acceleration of a vehicle in any direction), speedometers (which measure the instantaneous speed of a vehicle), airflow meters (which measure the airflow around a vehicle), etc. Such physical motion sensors can include the use of semiconductor strain gauges, electromechanical measuring devices that detect drivetrain rotations, barometric sensors, and the like.

[0039] With regard to feature 2), detecting other cars and / or obstacles and / or physical structures in the vicinity of the SDV 412, the positioning system 151 can use radar or other electromagnetic energy emitted by a transmitter of electromagnetic radiation (e.g., the one in Fig. The signal is emitted by the transceiver 523 shown in section 5, reflected by a physical structure (e.g., another car), and subsequently received by an electromagnetic radiation receiver (e.g., the transceiver 323). An example of a positioning system within SDV 412 is a LIDAR (Light Detection and Ranging) system (e.g., one shown in section 5). Fig. 5 LIDAR 533) or LADAR (Laser Detection and Ranging) system, which measures the time elapsed until the emitted electromagnetic radiation (e.g. light) is received again, and / or assesses a Doppler shift (i.e. a frequency change of the electromagnetic radiation caused by the movement of the SDV 412 relative to objects being scanned with the electromagnetic radiation) of the received electromagnetic radiation compared to the time of transmission, whereby the presence and position of other physical objects can be determined by the SDV on-board computer 501.

[0040] With regard to feature 3), measuring the speed and direction of the SDV 412, this can be achieved by reading an on-board speedometer (not shown) in the SDV 412 and / or detecting movements of the steering mechanism (also not shown) in the SDV 412 and / or the position determination system 151 described above.

[0041] With regard to feature 4), providing any other inputs necessary to safely control the movement of the SDV 412, such inputs include, but are not limited to, control signals to activate a horn, turn signals, hazard warning lights, etc. in the SDV 412.

[0042] In one or more embodiments of the present invention, the SDV 412 includes road surface sensors 511 connected to the SDV 412. The road surface sensors can include sensors capable of detecting the amount of water, snow, ice, etc., on the road surface 404 (e.g., using cameras, heat sensors, humidity sensors, thermometers, etc.). The road surface sensors 511 include sensors capable of detecting uneven road surfaces (e.g., roads with potholes, poorly maintained asphalt, missing asphalt, etc.) using cameras, vibration sensors, etc. The road surface sensors 511 can also include sensors capable of detecting the darkness of the road surface 404 using light sensors.

[0043] Similarly, a dedicated camera 521 can be directed towards the roadway 404 to provide photographic images of conditions on the roadway 404 on which the SDV 412 is currently traveling.

[0044] Similarly, a dedicated object motion detector 519 (e.g. a radar transceiver that can detect Doppler shifts which indicate the speed and direction of movement of other vehicles, animals, persons, etc. on the roadway 404) can be directed towards the roadway 404 on which the SDV 412 is currently traveling.

[0045] In one or more embodiments of the present invention, the SDV 412 also includes SDV equipment sensors 515. The SDV equipment sensors 515 can include cameras directed at the tires on the SDV 412 to detect the remaining tire tread depth. The SDV equipment sensors 515 can include electronic sensors that detect the remaining brake pad material on the brake calipers of disc brakes. The SDV equipment sensors 515 can include powertrain sensors that detect operating conditions within an engine (e.g., power, speed, engine revolutions per minute (rpm), valve timing, cylinder compression, coolant levels, engine temperature, oil pressure, etc.), the transmission (e.g., transmission oil level, clutch condition, gear condition, etc.), and the like. The SDV equipment sensors 515 can include sensors that detect the condition of other components of the SDV 412, such as...from headlights (e.g., using a circuit that detects if a bulb is defective), windshield wipers (e.g., using a circuit that detects a defective wiper blade, a defective wiper motor, etc.), and the like. If the vehicle (e.g., the one in . Fig. 4. Vehicle 402 (shown) performs a corrective / evasive maneuver (e.g., leaves the shoulder 410 of the roadway 404, which is in Fig. 7 shown crumple zone 702a of the SDV 412 collides with an object, etc.), the first SDV 412 in one or more embodiments thus only performs the same evasive maneuver if 1) the traffic / road conditions are similar and 2) this evasive maneuver was successful.

[0046] In one or more embodiments of the present invention, a data transmission transceiver 517 is also located within the SDV 412, which is capable of receiving and sending electronic data transmission signals (e.g. RF messages) to and from other data transmission transceivers that are present in other vehicles, servers, monitoring systems, etc.

[0047] In one or more embodiments of the present invention, a telecommunications unit 525 (e.g. a smartphone, a mobile phone, a laptop computer, etc.) is also located within the SDV 412, which can be connected to the SDV on-board computer 501 (e.g. via a near field communication link (Near Field Communication, NFC)).

[0048] In one or more embodiments of the present invention, the SDV 412 also contains a loudspeaker 537 which is capable of emitting acoustic warning messages (e.g. a buzzer, an alarm or a computer-generated voice) which alert the occupants of the SDV 412 and / or other persons / vehicles to an impending corrective / evasive maneuver which the SDV 412 will perform.

[0049] In one or more embodiments of the present invention, the SDV 412 also contains a video display 539 which is capable of outputting visual warning messages (e.g. a flashing light, a text message, etc.) which alert the occupants of the SDV 412 and / or other persons / vehicles to an impending corrective / evasive maneuver which the SDV 412 will perform.

[0050] In one or more embodiments of the present invention, a proximity sensor 541 is also located within the SDV 412, which uses motion detectors, radar (using Doppler displacement logic), etc., which can detect an object (e.g., a vehicle on an adjacent lane) in the vicinity of the SDV 412.

[0051] In one or more embodiments of the present invention, the SDV 412 also contains a tire deflation system 543, which is capable of releasing air from one or more tires on the SDV 412. The tire deflation system 543 can, for example, be an explosive unit (e.g., a compressed air cylinder) which, when activated by the SDV's on-board computer 501, causes a tire to deflate, so that the SDV 412 slows down abruptly to avoid a collision.

[0052] Although SDVs (due to short reaction times of the computers controlling them) are very good at recognizing and reacting to traffic scenarios, collisions between SDVs cannot be avoided under some circumstances.

[0053] If an SDV has no occupants, according to one or more embodiments of the present invention, the SDV may take certain actions that could result in its own irreparable damage in order to avoid damage to an object that is about to collide (e.g., another vehicle with passengers, a pedestrian, etc.). Therefore, if the SDV "knows" that there are no human passengers on board, and the SDV is about to collide with another vehicle that may have human passengers, the SDV would rather sacrifice its own integrity (e.g., by driving over a cliff and falling) than collide with the other vehicle.

[0054] Thus, one embodiment of the present invention, as described herein, utilizes a self-driving vehicle (SDV), a means of determining with confidence C1 that a collision is imminent, a means of determining with confidence C2 whether the SDV has a passenger of type P, and a means of determining aspects of the object with which a collision is imminent with confidence C3. Based on C1, C2, C3, and P, the system plans a real-time remedial action that can avoid a collision or simply mitigate the damage caused by an unavoidable collision. For example, if an SDV has no occupant, it may take certain actions that, in the event of a collision, could cause more damage to itself (such as breaking apart more quickly) than would be the case if it had an occupant.

[0055] Determining a collision with a confidence level of C1 can be based on an analysis of sensor data (e.g., from a captured visual image of an object in a lane, from LiDAR data on the distance between the SDV 412 and another vehicle / object, etc.). The determination that the SDV 412 is about to collide with another vehicle thus has a confidence level of C1. C1 could, for example, be "a 90 percent probability that the SDV 412 will collide with an object if no corrective action is taken to avoid the object."

[0056] A passenger of type P can be a person, a pet, a package (e.g., for delivery), or no passenger at all. Confidence C2 is the confidence level (e.g., the probability) with which the system has precisely identified what type of occupant (animate or inanimate) is currently inside the SDV 412.

[0057] Confidence C1 is the confidence level (e.g., the probability) with which the system has accurately identified what type of object is about to collide with the SDV 412 (i.e., is the object a manually driven vehicle, an SDV, a pedestrian, an animal, etc.), and / or what type and number of occupants are in the other vehicle (if the object about to collide with the SDV 412 is another vehicle).

[0058] As described here, the object that is about to collide with the SDV 412 can be any of the following: another SDV (with or without a passenger), another vehicle that is not an SDV, a person, an animal, a tree, a rock, a guardrail, a deer, a school bus, a bridge, etc.

[0059] Additionally, the object may be located behind the SDV 412. For example, if an SDV detects that it is about to be involved in an incident on a road with fast traffic closely following it, and if a shoulder is narrow or non-existent, the SDV, without passengers, may determine that driving over an embankment poses a lower risk to human drivers behind it.

[0060] In various embodiments of the present invention, the evasive action can be one or more of the following: allowing the SDV 412 to swerve (to reduce the impact on the object with which a collision occurs); performing a certain type of very aggressive braking or steering maneuver; allowing the SDV 412 to self-destruct (e.g., against a tree at the side of the road); abruptly releasing air from the tires of the SDV (to bring the SDV 412 to a rapid stop); not deploying the airbags inside the SDV 412 (if there is no occupant in the vehicle); allowing the passenger compartment of the SDV 412 to deform if there is no occupant, etc.

[0061] In one or more embodiments of the present invention, the SDV 412 has an arrangement of sensors used to detect an imminent collision. The exemplary SDV 412, described in [reference to SDV 412], serves as an example. Fig. 6 is shown.

[0062] As in Fig. As shown in Figure 6, the SDV 412 includes a LIDAR 633 (analogous to the one in Fig. Figure 5 (LIDAR 533) illustrates this, using a rotating, roof-mounted unit that may be a laser rangefinder. The LIDAR incorporates an array of multiple (e.g., 64 or more) laser beams from which the unit can generate 3D images of objects (thus acting as a camera), helping the car to "see" (e.g., detect and register) objects (and hazards) along its route. For example, a LIDAR unit can calculate the distance of an object from the moving vehicle based on the time it takes its laser to hit the object and return. Some (high-intensity) lasers can calculate distances and generate images for objects within a range of 200 meters.

[0063] Distance sensors 619 (analogous to the object motion sensor 519 from Fig. 5) are mounted on the front and rear bumpers of the SDV 412 to enable the SDV 412 to detect the distance to vehicles in front of and behind it. In some embodiments, the distance sensors 619 can be implemented by radar transceivers. As those skilled in electronics know, radar is an object detection system that uses radio waves to determine the distance, angle, and / or speed of objects.

[0064] As in Fig. As shown in section 6, a video camera 621 (analogous to the one in Fig. The camera 521 (shown in Figure 5) is mounted on the windshield of the SDV 412. Using the image processing and artificial intelligence integrated into the SDV's on-board computer 501, this camera interprets general road behavior and signals from other road users. For example, if a cyclist indicates that they intend to turn, the autonomous vehicle correctly interprets this and brakes to allow the cyclist to make the turn. Predefined shape and motion descriptors are programmed into the system to assist the SDV 412 in making intelligent decisions.

[0065] A position estimator 641 (analogous to the one in Fig. The proximity sensor 541 (shown in Figure 5) can be configured as an ultrasonic sensor that uses sound propagation to detect objects. The position estimator 641 can also be used as a geophysical positioning unit when mounted on one of the rear wheels of the SDV 412, enabling the position estimator 641 to calculate the number of wheel rotations to determine the exact position of the SDV 412.

[0066] With regard to Fig. Section 7 of SDV 412 includes crumple zones 702a and 702b, which, for example, through controlled deformation, can absorb and / or dissipate energy from the impact during a traffic accident. In some embodiments, SDV 412 is designed such that the crumple zones 702a and 702b absorb and / or dissipate the energy of a collision, thereby protecting the passengers in the passenger compartment 704. The exemplary crumple zones 702a and 702b can use aluminum, a honeycomb structure of composite material and carbon fiber, energy-absorbing foam, or any other material that sufficiently absorbs, mitigates, and / or dissipates impact energy. Thus, in some embodiments, the SDV on-board computer 501 within the SDV 412 "knows" the energy-absorbing capabilities of the crumple zones 702a and 702b and also knows (e.g.(based on sensors embedded in the seats) that there are passengers inside the passenger compartment 704, whereupon the SDV on-board computer 501 within the SDV 412 maneuvers the SDV 412 shortly before a collision so that a large portion of the collision energy can be absorbed by the crumple zone 702a and / or the crumple zone 702b, thereby protecting the passengers inside the passenger compartment 704. In some embodiments, if the SDV 412 determines that there are no passengers, the SDV 412 may not take into account whiplash or crumple zones when taking action and may disregard acceleration forces that occur during very aggressive braking, evasive maneuvers, etc., which would otherwise be excessively high.

[0067] A characterization (of the object with which a collision is imminent) may include an assessment of the object's weight (since the results of a collision may depend on the relative weights of the SDV 412 and the object just hit).

[0068] The present invention is preferably capable of handling many collision scenarios. For example, the SDV 412 should "know" (e.g., based on sensor data from sensors in the SDV 412) that it is about to collide head-on with another vehicle or a solid object (e.g., a large object that has just fallen from the loading platform of a truck in front of the SDV 412). If the SDV 412 has a human passenger, it can swerve to avoid the collision, colliding with another vehicle traveling in the same direction, and rely on the known crumple zones of both vehicles to protect their passengers (including passengers inside the SDV 412). However, if the SDV 412 has no passenger, it can choose to effectively sacrifice itself by breaking apart, crashing into a concrete wall, driving over a cliff, etc., thereby protecting passengers in other vehicles from potential harm.In another example, chain-reaction collisions on highways, sometimes involving more than 100 vehicles, can pose a very serious danger to drivers. If an SDV such as the SDV 412 is involved in a chain-reaction collision and is not carrying passengers, the present invention enables the SDV 402 to change vehicle parameters to absorb a larger portion of the chain-reaction collision as it increases in length, even if this means that the SDV 412 itself is destroyed in the process (in order to provide an additional barrier / impact absorption for other vehicles).

[0069] According to one or more embodiments of the present invention, an electronic system (e.g., the SDV on-board computer 501) in the SDV 412 includes impact prediction modules and sensor systems, each configured to detect or predict an imminent impact involving the SDV 412. An occupant detection system can detect the presence of an occupant. The impact prediction system(s) and the occupant detection system(s) can be connected to a bus and supplied with power and data transmission via the bus. Each occupant unit and impact prediction unit can be triggered in the event of a predicted impact in which the vehicle is involved, as detected by a sensor system. The SDV's impact prediction and avoidance system can include an environmental imaging system.

[0070] In one or more embodiments of the present invention, the impact prediction is achieved by the user of a neural network (e.g. as part of the SDV on-board computer 501) which has been previously trained with training data to predict the possibility of an impact, wherein the training data represents constantly changing views that were previously recorded by an image capture device while vehicles were driving.

[0071] The SDV 412 can include a vehicle traffic management system that monitors the position of vehicles in a lane as well as other objects in the vicinity of the SDV 412. Based on this information, the SDV's onboard computer then generates a corrective action if it determines that the SDV 412 is about to be involved in a collision.

[0072] Fig. Figure 8 represents a further exemplary process according to one or more embodiments of the present invention.

[0073] As shown, after a start block 802, one or more processors (e.g., within the one in Fig. The SDV on-board computer 501 shown in block 804 has a confidence level of C1 that an imminent collision by a self-driving vehicle (SDV) is imminent. For example, the SDV on-board computer 501 within the SDV 412 can determine that the SDV 412 is about to collide with another vehicle, a fixed object, a pedestrian, etc., unless corrective action is taken to change the trajectory of the SDV 412. This determination has a confidence level of C1, which is the probability (e.g., 95%) that the SDV on-board computer 501 made the prediction correctly. This confidence level C1 can be based on past experience with other SDV on-board computers 501 programmed in a similar manner (and / or on similar road conditions, traffic conditions, SDV configurations, etc.).If other SDV onboard computers 501 have correctly predicted 95% of the time that the SDVs they are in will be involved in an imminent collision, then the confidence level C1 is 95%.

[0074] In block 806, one or more processors determine with a confidence level of C2 whether the SDV contains an occupant of occupant type P. This confidence level C2 can be based on past experience with other SDV onboard computers 501 programmed in a similar manner and / or on the use of similar sensors within the passenger compartment of the SDV 412 (e.g., the camera 521 directed at the interior of the passenger compartment of the SDV 412). If other SDV onboard computers 501 have correctly identified occupant type P (i.e., where P = human) 99% of the time, then the confidence level C2 is 99%.

[0075] In block 808, one or more processors identify with a confidence level of C3 an object with which a collision by the SDV is imminent. For example, the processors can identify the object in Fig. The four vehicles shown, vehicle 406, can be identified in front of the SDV 402 with a confidence level of 90%. This confidence level C3 can be based on past experience with the SDV on-board computer 501 within the SDV / vehicle 402 and / or other SDV on-board computers 501 in other SDVs that were programmed in a similar way (and / or on similar road conditions, traffic conditions, SDV configurations, etc.). If these SDV on-board computers 501 have correctly identified objects that are about to collide with the SDV in which they are located 90% of the time, then the confidence level C3 is 90%.

[0076] In this way, confidence level C1 reflects how certain the system is that it has correctly predicted / detected an imminent collision. Confidence level C2 reflects how certain the system is that it has correctly determined what type of occupants (if any) are currently in the SDV. Confidence level C3 reflects how certain the system is that it has correctly identified the object that is about to collide with the SDV. Confidence level C3 is based on 1) how certain the system is that it has detected the object that is about to collide with the SDV, and / or 2) how certain the system is that it has identified the type of object (person, vehicle, animal, etc.) with which it is about to collide.

[0077] In block 810, one or more processors then generate and implement a real-time mitigation measure based on C1, C2, C3, and P to mitigate the imminent collision between the SDV and the object. Once values ​​for C1, C2, C3, and P are entered into the SDV onboard computer 501, the SDV onboard computer 501 is thus able to inform the SDV 412 which mitigation steps (braking, accelerating, swerving, colliding with another object, etc.) the SDV / vehicle 402 should take.

[0078] Block 812 checks whether the corrective / evasive action taken by vehicle 402 was successful (e.g., whether vehicle 402 avoided a collision). If not, block 816 stores the unsuccessful corrective / evasive action in a training database as a prohibited future corrective action that should never be taken by another SDV (block 816). However, if the evasive action was successful, block 814 sends a description and instructions on how to perform this evasive action to the SDV onboard computer 501 in SDV 412.If, in Block 818, it is determined that SDV 412 might encounter a similar traffic situation / hazard under similar environmental / weather / lighting conditions, SDV 412 will perform the evasive maneuver in Block 820 that has proven successful when performed in the past by SDV / Vehicle 402 under similar circumstances.

[0079] The process ends with (termination) block 822.

[0080] In a further embodiment of the present invention, one or more processors determine a confidence level (C1) based on an analysis of sensor data received (e.g., in real time) from one or more sensors in the SDV. The SDV on-board computer 501 can thus determine, based on camera values ​​(e.g., from the vehicle camera 621), the LIDAR 633, a microphone 531 (which detects the sound of the object about to collide with the SDV 412), etc., how certain it is that it has correctly identified the object and / or the type of object.

[0081] In one embodiment of the present invention, the occupant type P describes live passengers in the SDV. The system thus provides sensor data pertaining to live passengers (e.g., using a biometric sensor 535 and / or the camera 521 and / or the microphone 531 directed at the passengers in the SDV 412). Such sensors can, for example, detect human sounds in the passenger compartment of the SDV 412, indicating the presence of a human passenger within the SDV 412. The SDV on-board computer 501 then adjusts the real-time corrective action accordingly.

[0082] In one embodiment of the present invention, the occupant type describes inanimate passengers in the SDV. For example, if the biometric sensor 535 and / or the camera 521 and / or the microphone 531, which are directed towards a passenger compartment of the SDV 412, do not detect any living forms, the SDV on-board computer 501 assumes that the SDV 412 is merely transporting cargo and adjusts the real-time corrective action accordingly. If no human lives are at risk, the corrective action is thus much more likely to result in sharp braking, a collision with a wall, etc., unless this would damage the cargo.

[0083] In one embodiment of the present invention, the occupant type describes the absence of any occupants in the SDV. For example, if the camera 521 directed at a passenger compartment of the SDV 412 detects no life forms, no cargo, etc., the SDV onboard computer 501 assumes that the SDV 412 is empty and adjusts the real-time corrective action accordingly. Thus, if there is no risk to either human passengers or cargo, the real-time corrective action is much more likely to lead to drastic measures, including serious damage to the SDV 412, in order to avoid the risk of damage / injury to other entities.

[0084] In one embodiment of the present invention, the object that is about to collide with the SDV is another SDV carrying a human passenger. In this case, the SDV on-board computer 501 in the SDV / vehicle 402 generates a real-time corrective action that poses the lowest risk to both passengers in the SDVs 402 / 412 (if any) and passengers in the other vehicle (e.g., the one in the Fig. 4 shown vehicle 406), which is about to collide.

[0085] In one embodiment of the present invention, the object that is about to collide with the SDV is another SDV that has no passengers. In this case, the SDV on-board computer 501 in the SDV / vehicle 402 generates a real-time corrective action that poses the lowest risk to passengers in the SDVs 402 / 412 without causing any material damage to the unoccupied vehicle (e.g., the one in Fig. to take into account vehicle 406 shown in section 4, which is about to collide.

[0086] In one embodiment of the present invention, the object immediately on the verge of a collision with the SDV is a pedestrian. In this case, the SDV's on-board computer generates a real-time corrective action that poses the least risk to the pedestrian, even if this entails an increased risk of injury to passengers in the SDVs 402 / 412 and damage to the SDVs 402 / 412, since a collision with the pedestrian would most likely result in serious injury to the pedestrian.

[0087] In one embodiment of the present invention, the object immediately on the verge of a collision with the SDV is an animal. In this case, the SDV's on-board computer generates a real-time corrective action that does not pose an unreasonable risk to passengers in the SDVs 402 / 412, nearby pedestrians, and nearby vehicles when it avoids the animal (e.g., a deer).

[0088] In one embodiment of the present invention, the object immediately on the verge of a collision with the SDV is a vehicle that is not an SDV. It is assumed that the SDV / vehicle 402 is about to collide with the object in the SDV. Fig. The fourth vehicle, 406, is shown to collide. Furthermore, it is assumed that all (or at least most) SDVs transmit a signal indicating that they are 1) in autonomous mode and 2) capable of coordinating movements with other SDVs. If vehicle 406 is another SDV, SDV 402 and vehicle 406 can thus coordinate their movements to avoid a collision. However, if vehicle 406 is not an SDV, the SDV onboard computer 501 in SDV 402 assumes that vehicle 406's trajectory will not change quickly enough to prevent the collision, and that SDV 402 may therefore have to take any necessary corrective action to minimize (or prevent) the impact of the collision.

[0089] In one embodiment of the present invention, the object immediately facing a collision with the SDV is an inanimate object located in a fixed position (e.g., a branch in the middle of the road). In this case, the SDV on-board computer 501 determines that the object will not move and generates a corrective action that takes this into account (including, if necessary and the safest alternative, simply allowing the SDV 402 to collide with the stationary object).

[0090] In one embodiment of the present invention, the remedy consists in striking the object in such a way that energy-absorbing areas on the SDV absorb the impact of the SDV striking the object. For example, if the SDV 402 detects that it cannot prevent a collision with an object, it at least positions itself in such a way that the crumple zone 702a bears the main load of the collision, thereby protecting the passengers within the Fig. The passenger compartment 704 of the SDV 412 shown in section 7 is protected.

[0091] In one embodiment of the present invention, the remedy is intended to cause the air to be released from at least one tire on the SDV. The SDV 402 is intended to be, for example, unoccupied. Furthermore, the SDV 402 is intended to be equipped with a tire puncture repair system 543 (e.g., the one described in [reference missing]). Fig. The SDV 402 must be equipped with the tire bursting system shown in Figure 5. When the SDV on-board computer 501 instructs the tire bursting system 543 to deflate one or more tires on the SDV 402 (to burst the tires), this causes the SDV 402 to slow down abruptly (due to the grinding and resistance of the burst tires).

[0092] In one embodiment of the present invention, the SDV is assumed to be unoccupied. In this case, the remedy in this embodiment consists of preventing any airbags within the SDV from being deployed in response to a collision between the SDV and an object. That is, the deployment of airbags could damage cargo within the SDV or simply provide no benefit, since there are no passengers (while still incurring costs for replacing the deployed airbags). Therefore, the airbags are deactivated. It should be noted that even in this case, a pressure sensor may be present in the seats of the SDV. However, the camera recognizes that this pressure originates from cargo and not from passengers and accordingly deactivates the airbags.

[0093] In one embodiment of the present invention, one or more processors determine a weight ratio between the SDV and the object and then adjust the remedial action accordingly. For example, the SDV 402 is a sedan (with passengers inside) that is about to collide with a fast-moving train (e.g., a train traveling at more than 95 kilometers per hour). In this case, the SDV 402 takes every appropriate step, including colliding with another vehicle, crashing into a wall, etc., to avoid colliding with the fast-moving train, which would certainly have fatal consequences for the occupants of the SDV 402.

[0094] In one embodiment of the present invention, one or more processors adapt the corrective action based on the road conditions of a roadway on which the SDV is currently traveling. For example, if chemical sensors 527 from Fig. 5 the presence of flammable liquids on the in Fig. If the SDV on-board computer 501 detects lane 404 as shown in diagram 4, it can develop a corrective action to prevent driving through the flammable liquids. If the SDV on-board computer has been warned of bad weather on lane 404 and / or knows (e.g., based on a loaded digital map within the SDV on-board computer 501) that lane 404 has a sharp curve within the next 30 meters, the SDV on-board computer 501 adjusts the corrective action accordingly to take these conditions into account.

[0095] In one embodiment of the present invention, the vehicle 402 is a first SDV. One or more processors receive executable instructions for implementing a corrective action taken by a group of other SDVs that have been confronted with an imminent collision similar to the imminent collision faced by the first SDV, and then execute the executable instructions for implementing the corrective action taken by the group of other SDVs. The SDV 402 can thus utilize corrective actions taken by other SDVs. Such corrective actions can be stored within the SDV on-board computer 501 within the SDV 402.

[0096] In one or more embodiments of the present invention, the SDV 402 can also learn in advance from other SDVs in the same geographical location and context (e.g., road conditions / weather) what decisions they have made and what the results of those decisions were, and apply such knowledge when similar situations arise. The SDV on-board computer 501 in the SDV 402 can thus use a probability function to determine the best possible option based on the other SDVs and human input.

[0097] In one or more embodiments of the present invention, a human driver or passenger may be permitted to override the decision of SDV 402 / 412, provided that this is possible in terms of time.

[0098] In one embodiment of the present invention, where the SDV 402 is unoccupied, a full-size interior airbag can be deployed when the SDV detects that it is about to crash, in order to minimize damage to the interior. Alternatively, the interior can be filled with a rapidly expanding foam (to protect the interior of the SDV 402) and / or with fire-retardant materials and foams to prevent explosions and fires. Such measures are not taken if there are people inside the SDV 402.

[0099] As described here, an SDV (e.g., the one in Fig. 4 SDV 412 shown) from the experiences of another vehicle, such as vehicle 402, which may be driven by a person or also be an SDV. This other vehicle performs an evasive action that 1) was successful or not and 2) was appropriate / necessary or not.

[0100] Although the solution described so far aims to train an SDV to avoid a collision based on the evasive maneuvers taken by other vehicles, one or more embodiments of the present invention determine whether such an evasive maneuver was actually successful. The driver (human or computer) of vehicle 402 can thus perform a specific maneuver involving sharp braking, rapid acceleration, rapid changes of direction, etc. To determine whether such measures were actually necessary to avoid a collision or merely represented poor driving style / poor vehicle control, the road and traffic conditions (as described above) are assessed.For example, if a video provides no indication that the vehicle is about to collide with another vehicle, and the vehicle nevertheless performs a sudden evasive maneuver, etc., the system will discard this action as an unjustified evasive action. Furthermore, a pattern of such driving behavior will prompt the system to investigate future "evasive actions" occurring in the presence of other vehicles more closely to ensure that such actions were indeed necessary and should therefore be shared to train other SDVs.

[0101] The present invention can be implemented in one or more embodiments using cloud computing. However, it should be clarified from the outset that the implementation of the teachings presented herein is not limited to a cloud computing environment, although this disclosure contains a detailed description of cloud computing. Instead, embodiments of the present invention can be implemented together with any type of data processing environment, now known or subsequently invented.

[0102] Cloud computing is a service delivery model that enables seamless, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing power, main memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management overhead or interaction with a service provider. This cloud model can include at least five properties, at least three service models, and at least four implementation models.

[0103] The properties are as follows: On-Demand Self-Service: A cloud user can unilaterally and automatically provide data processing functions such as server time and network storage as needed, without requiring human interaction with the service provider. Broad Network Access: Functions are available over a network, accessed through standard mechanisms that support use by heterogeneous thin or thick client platforms (e.g., mobile phones, laptops, and PDAs). Resource pooling: The provider's data processing resources are pooled to serve multiple users using a multi-tenant model, with various physical and virtual resources being dynamically allocated and reassigned as needed. There is a perceived location independence, as the user generally has no control over or knowledge of the exact location of the provided resources, but may be able to define a location at a higher level of abstraction (e.g., country, state, or data center). Rapid Elasticity: Features can be deployed quickly and elastically for rapid horizontal scaling (scale-out), in some cases automatically, and released quickly for rapid scale-in. To the user, the available features often appear unlimited and can be purchased in any quantity at any time. Measured Service: Cloud systems automatically control and optimize resource usage by employing a measurement function at a certain level of abstraction appropriate for the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource consumption can be monitored, controlled, and reported, creating transparency for both the provider and the user of the service. Software as a Service (SaaS): The functionality provided to the user consists of using the provider's applications running in a cloud infrastructure. These applications are accessible from various client devices via a thin-client interface, such as a web browser (e.g., web-based email). The user does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functions, with the possible exception of limited user-specific application configuration settings. Platform as a Service (PaaS): The function provided to the user is to deploy applications created or obtained by the user, using programming languages ​​and tools supported by the provider, within the cloud infrastructure. The user does not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but has control over the deployed applications and potentially over configurations of the application hosting environment. Infrastructure as a Service (IaaS): The functionality provided to the user consists of supplying processing, storage, networking, and other basic data processing resources, enabling the user to deploy and run any software, including operating systems and applications. The user does not manage or control the underlying cloud infrastructure but has control over operating systems, storage, deployed applications, and potentially limited control over selected network components (e.g., host firewalls).

[0104] The following are the deployment models: Private Cloud: The cloud infrastructure is operated solely for one organization. It can be managed by the organization or a third party and can be located on the organization's own premises or on external premises. Community Cloud: This cloud infrastructure is shared by multiple organizations and supports a specific user community with shared concerns (e.g., mission, security requirements, policies, and regulatory compliance considerations). It can be managed by the organizations themselves or a third party and can be located on-premises or externally. Public Cloud: The cloud infrastructure is made available to the general public or a large industry group and is owned by an organization that sells cloud services. Hybrid Cloud: The cloud infrastructure is a composition of two or more clouds (private, community or public) that remain separate entities but are connected by a standardized or proprietary technology that enables data and application portability (e.g. cloud audience distribution for load balancing between clouds).

[0105] A cloud computing environment is service-oriented, focusing on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing lies an infrastructure that comprises a network of interconnected nodes.

[0106] With reference to Fig. Figure 9 illustrates a cloud computing environment 50. As shown, the cloud computing environment 50 has one or more cloud computing nodes 10 with which local data processing units used by cloud users, such as the electronic assistant (PDA, Personal Digital Assistant) or mobile phone 54A, the desktop computer 54B, the laptop computer 54C, and / or the automotive computer system 54N, can exchange data. The nodes 10 can exchange data with each other. They can be grouped physically or virtually into one or more networks, such as private, community, public, or hybrid clouds (not shown), as described above, or into a combination thereof. This enables the cloud computing environment 50 to offer infrastructure, platforms, and / or software as a service, for which a cloud user does not need to maintain resources on a local data processing unit.It should be noted that the types of in . Fig. The data processing units 54A to N shown are for illustrative purposes only, and the data processing nodes 10 and the cloud computing environment 50 can exchange data with any type of computer unit via any type of network and / or any type of network-accessible connection (e.g., using a web browser).

[0107] With reference to Fig. 10 shows a set of functional abstraction layers that are used by the cloud computing environment 50 ( Fig. 9) will be provided. It should be clear from the outset that the in Fig. The components, layers, and functions shown in Figure 10 are intended for illustrative purposes only, and embodiments of the invention are not limited to them. As shown, the following layers and corresponding functions are provided:

[0108] A hardware and software layer 60 contains hardware and software components. Examples of hardware components include: mainframe computers 61; servers based on the RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage units 65; and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0109] A virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks 73, including virtual private networks, virtual applications and operating systems 74; and virtual clients 75.

[0110] In one example, an administration layer 80 can provide the functions described below. Resource provisioning 81 provides the dynamic procurement of data processing resources and other resources used to perform tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking for the use of resources within the cloud computing environment and billing for the consumption of these resources. In one example, these resources might include application software licenses. Security provides identity verification for cloud users and tasks, as well as protection for data and other resources. A user portal 83 provides users and system administrators with access to the cloud computing environment.Service scope management (84) provides the allocation and management of cloud computing resources so that the required service objectives are met. Service level agreement (SLA) planning and fulfillment (85) provides the advance planning and procurement of cloud computing resources for which a future requirement is anticipated, in accordance with an SLA.

[0111] A workload layer 90 provides examples of the functionality for which the cloud computing environment can be used. Examples of workloads and functions that can be provided by this layer include: mapping and navigation 91; software development and lifecycle management 92; delivery of training in virtual classrooms 93; data analytics processing 94; transaction processing 95; and SDV training processing 96, which performs one or more workloads and functions according to the present invention.

[0112] The terminology used here serves only to describe certain embodiments and is not intended to limit the present invention. In the sense used here, the singular forms "a / an" and "the" are also to include the plural forms, unless the context clearly indicates otherwise. Furthermore, it should be noted that the terms "indicates" and / or "indicate" in this description indicate the presence of the aforementioned features, integers, steps, operations, elements, and / or components, without, however, excluding the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof.

[0113] The structures, materials, actions, and equivalents of all means or steps, in addition to the functional elements in the following claims, shall include all structures, materials, or actions by which the function can be performed in conjunction with other claimed elements, as expressly claimed herein. The description of various embodiments of the present invention has been provided for illustrative and explanatory purposes and is not to be understood as exhaustive or limiting with regard to the present invention as described herein. Those skilled in the art are aware that numerous modifications and adaptations are possible without altering the scope and conceptual essence of the invention.The embodiment was selected and described to best explain the principles of the present invention and its practical application, and to enable other skilled persons to understand the present invention with regard to various embodiments with different modifications suitable for the respective intended use.

[0114] Some embodiments of the present invention can be implemented using a VHDL (Hardware Description Language) program in conjunction with one or more compatible electronic units (sometimes also referred to as a VHDL chip). VHDL is an example input language for electronic units such as field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), and other units. Furthermore, and only as an example, a computer-implemented (software-based) method can be emulated by a hardware-based VHDL program, which is then applied to a VHDL chip such as an FPGA.

[0115] The present invention may be a system, a method, and / or a computer program product with any possible degree of technical integration. The computer program product may include a computer-readable storage medium (or media) on which computer-readable program instructions are stored to induce a processor to execute aspects of the present invention.

[0116] A computer-readable storage medium can be a physical unit capable of retaining and storing instructions for use by an instruction execution unit. For example, a computer-readable storage medium can be an electronic storage unit, a magnetic storage unit, an optical storage unit, an electromagnetic storage unit, a semiconductor storage unit, or any suitable combination thereof, without limitation. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), and erasable programmable read-only memory (EPROM).Flash memory), static random-access memory (SRAM), portable read-only compact disc (CD-ROM), DVD (Digital Versatile Disc), USB flash drive, floppy disk, a mechanically coded unit such as punched cards or raised structures in a groove on which instructions are stored, and any suitable combination thereof. A computer-readable storage medium shall not, in its use herein, be understood as volatile signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses guided by an optical fiber cable), or electrical signals transmitted by a wire.

[0117] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to individual data processing units or, via a network such as the internet, a local area network, a wide area network, and / or a wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission lines, wireless transmission, routing computers, firewalls, switching units, gateway computers, and / or edge servers. A network adapter card or network interface in each data processing unit receives computer-readable program instructions from the network and forwards them for storage on a computer-readable storage medium within the respective data processing unit.

[0118] Computer-readable program instructions for executing work steps of the present invention may be assembly instructions, ISA (Instruction Set Architecture) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state-setting data, or both source code and object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java, Smalltalk, C++, etc., as well as conventional procedural programming languages ​​such as the programming language "C" or similar programming languages.The computer-readable program instructions can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on the remote computer or server. In the latter case, the remote computer can be connected to the user's computer via any type of network, including a LAN or WAN, or the connection can be established with an external computer (for example, via the internet using an internet service provider).In some embodiments, electronic circuits, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs) or programmable logic arrays (PLAs), can execute computer-readable program instructions by using state information from the computer-readable program instructions to personalize the electronic circuits to implement aspects of the present invention.

[0119] Aspects of the present invention are described herein with reference to flowcharts and / or block diagrams or diagrams of methods, devices (systems), and computer program products according to embodiments of the invention. It is pointed out that each block of the flowcharts and / or block diagrams or diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams or diagrams, can be executed by computer-readable program instructions.

[0120] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a specialized computer, or another programmable data processing device to create a machine, such that the instructions executed via the processor of the computer or other programmable data processing device generate a means of implementing the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.These computer-readable program instructions may also be stored on a computer-readable storage medium capable of controlling a computer, programmable data processing device, and / or other units to function in a particular manner, such that the computer-readable storage medium on which instructions are stored has a manufactured product, including instructions that implement aspects of the function / step specified in the block(s) of the flowchart and / or block diagrams or charts.

[0121] The computer-readable program instructions can also be loaded onto a computer, other programmable data processing device or other unit to cause the execution of a series of process steps on the computer or other programmable device or other unit in order to produce a computer-implemented process, such that the instructions executed on the computer, other programmable device or other unit implement the functions / steps specified in the block(s) of the flowcharts and / or block diagrams or charts.

[0122] The flowcharts and block diagrams or charts in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this context, each block in the flowcharts or block diagrams or charts can represent a module, segment, or part of instructions that includes one or more executable instructions for performing the specific logical function(s). In some alternative embodiments, the functions specified in the block may occur in a different order than shown in the figures. For example, two blocks shown consecutively may in reality be executed essentially simultaneously, or the blocks may sometimes be executed in reverse order depending on the corresponding functionality.It should also be noted that each block of the block diagrams or charts and / or flowcharts, as well as combinations of blocks in the block diagrams or charts and / or flowcharts, can be implemented by special hardware-based systems that perform the specified functions or steps, or execute combinations of special hardware and computer instructions.

[0123] After embodiments of the present invention of the present patent application have been described in detail and with reference to their illustrative embodiments, it should be obvious that changes and modifications are possible without deviating from the scope of the present invention as defined in the attached claims.

Claims

[1] A computer-implemented method comprising: a detection of the road surface condition of a first roadway by one or more sensors belonging to a vehicle; a detection of an evasive maneuver carried out in response to the detection of the road surface condition by one or more sensors belonging to the vehicle; Determining whether the evasive maneuver successfully avoided the road surface condition, by means of a computer belonging to the vehicle; Saving a recording of the evasive maneuver and the road surface condition in response to the computer's determination of whether the evasive maneuver was a successful attempt to avoid the road surface condition; and as a reaction to a determination that one or more vehicles are exposed to the road surface conditions encountered by the vehicle, training one or more computers belonging to one or more other vehicles to perform the evasive maneuver, the evasive maneuver is designed to cause at least one tire on the vehicle to deflate. [2] A computer-implemented method according to claim 1, further comprising: in response to a determination that the evasive maneuver was unsuccessful, a prevention of the transmission of the unsuccessful maneuver to the one or more vehicles. [3] A computer-implemented method according to claim 1, wherein the road surface condition is a traffic hazard from a group, comprising: a second vehicle that is in close proximity to the vehicle at the time of the evasive maneuver; and a fixed obstacle on the first carriageway; and whereby The evasive maneuver is performed to avoid the road surface condition. [4] A computer-implemented method according to claim 1, wherein the road surface condition is determined to indicate a hazard to a pedestrian who is in close proximity to the vehicle at the time of the evasive maneuver, and wherein the evasive maneuver is carried out to avoid hitting the pedestrian. [5] A computer-implemented method according to claim 1, wherein the vehicle is a self-driving vehicle (SDV) and wherein the method further comprises: a detection with a confidence level of C1 that an imminent collision by the SDV is imminent, by one or more processors; Determining with a confidence level of C2 whether the SDV contains one or more occupants, by one or more processors; Identifying an object with which an immediate collision by the SDV is imminent, with a confidence level of C3, by one or more processors; a generation of a remedy for the SDV based on C1, C2, C3 by one or more processors; and an instruction to the onboard processor belonging to the SDV to execute the corrective action. [6] A computer-implemented method according to claim 5, further comprising: Determining a confidence level C1 based on an analysis of sensor data received in real time from one or more sensors in the SDV by one or more processors. [7] A computer-implemented method according to claim 5, wherein the one or more occupants are selected from a group comprising living passengers and non-living passengers. [8] A computer-implemented method according to claim 5, wherein the SDV has one or more crumple zones, further comprising: an instruction to the onboard processor belonging to the SDV to impact the object in a manner that causes one or more crumple zones of the SDV to maximally absorb the collision with the object. [9] A computer-implemented method according to claim 5, wherein the remedy prevents one or more airbags from being triggered within the SDV in response to a collision of the SDV with the object. [10] A computer-implemented method according to claim 5, further comprising: a computer determines the weight ratio between the SDV and the object; and an adjustment of the corrective action by the computer according to the weight ratio between the SDV and the object. [11] A computer-implemented method according to claim 1, further comprising: Receiving computer-executable commands from the vehicle to implement an evasive maneuver similar to the evasive maneuver performed by the vehicle, by the one or more computers belonging to the one or more vehicles; and In response to a detection of road conditions, an instruction of one or more vehicles to execute the computer-executable commands to implement the evasive action, by at least one of the one or more computers. [12] A computer-implemented method according to claim 1, wherein the computer-implemented method is implemented as a cloud-based service. [13] Computer program product for training one or more computers belonging to one or more vehicles to perform an evasive maneuver, wherein the computer program product comprises a computer-readable storage medium containing program instructions, wherein the program instructions are executable by a processor to cause the processor to execute the method according to any one of claims 1 to 12. [14] System, having: one or more processors; one or more computer-readable memory units that are operatively connected to the one or more processors; one or more computer-readable storage media that are operatively connected to the one or more computer-readable memory units; and Program instructions stored on at least one of the one or more computer-readable storage media for execution by at least one of the one or more processors, wherein the program instructions include instructions for the processor to execute the method according to any one of claims 1 to 12. [15] Computer program comprising a program code means designed to perform the method according to any one of claims 1 to 12 when the program is executed on a computer.

Images