Autonomous driving vehicle system

Abstract

1. An apparatus comprising: at least one interface that receives a signal identifying a second vehicle in proximity to a first vehicle; and a processing circuit, wherein the processing circuit: obtains a behavior model associated with the second vehicle, the behavior model defining a driving behavior of the second vehicle; predicts a behavior of the second vehicle using the behavior model; and determines a route plan for the first vehicle based on the predicted behavior of the second vehicle.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims the benefit and priority of U.S. Provisional Patent Application No. 62 / 826,955, filed on Mar. 29, 2019, entitled "Autonomous Vehicle System", the entire disclosure of which is incorporated herein by reference.

[0002] This disclosure generally relates to the field of computer systems, and more specifically, to computing systems that enable autonomous vehicles.

Background Art

[0003] Some vehicles are configured to operate in an autonomous mode where the vehicle navigates the environment with little or no input from a driver. Such vehicles typically include one or more sensors configured to sense information about the environment. The vehicle can use the sensed information to navigate the environment. For example, if the sensor senses that the vehicle is approaching an obstacle, the vehicle can navigate around the obstacle.

Brief Description of the Drawings

[0004]

Figure 1

[0005]

Figure 2

[0006]

Figure 3

[0007]

Figure 4

[0008]

Figure 5

[0009]

Figure 6

[0010]

Figure 7

[0011]

Figure 8

[0012]

Figure 9

[0013]

Figure 10

[0014]

Figure 11

[0015]

Figure 12

[0016]

Figure 13

[0017]

Figure 14

[0018]

Figure 15

[0019]

Figure 16

[0020]

Figure 17

[0021]

Figure 18

[0022]

Figure 19

[0023]

Figure 20

[0024]

Figure 21

[0025]

Figure 22

[0026]

Figure 23

[0027]

Figure 24

[0028]

Figure 25

[0029]

Figure 26

[0030]

Figure 27

[0031]

Figure 28A

[0032]

Figure 28B

[0033]

Figure 29

[0034]

Figure 30

[0035]

Figure 31

[0036]

Figure 32

[0037]

Figure 33

[0038]

Figure 34

[0039]

Figure 35

[0040]

Figure 36

Figure 37

[0041] FIG. 1 is a simplified diagram 100 showing an exemplary autonomous driving environment. Vehicles (e.g., 105, 110, 115, etc.) may be equipped with different levels of autonomous driving capabilities facilitated through an in-vehicle computing system having logic implemented in hardware, firmware, and / or software to enable each respective autonomous driving stack. Such an autonomous driving stack may enable a vehicle to perform self-control or provide driver assistance in order to detect roads, navigate from one location to another, detect other vehicles and entities on the road (e.g., pedestrians (e.g., 135), cyclists, etc.), detect obstacles and hazards (e.g., 120), and road conditions (e.g., traffic, road conditions, weather conditions, etc.), and appropriately adjust vehicle control and guidance. In the present disclosure, a “vehicle” may be a manned vehicle (e.g., a car, truck, van, bus, motorcycle, train, air transport vehicle, ambulance, etc.) designed to carry one or more human passengers, an unmanned vehicle (e.g., a cargo vehicle (e.g., a truck, a rail-based vehicle, etc.), a vehicle for transporting non-human passengers (e.g., livestock transport, etc.), and / or a drone (e.g., a ground-based or aerial drone or a robot that moves within an operating environment (e.g., to collect information regarding the operating environment, provide assistance for the automation of other vehicles, perform road maintenance tasks, provide industrial tasks, provide public safety and emergency response tasks, etc.)) that operates with or without a human passenger. In some implementations, a vehicle may alternatively be a system configured to operate in multiple different modes (e.g., a passenger vehicle, an unmanned vehicle, or a drone vehicle), among other examples. A vehicle may “drive” within an environment to move the vehicle along the ground (e.g., a paved or unpaved road, path, or landscape), through water, or through the air. In this sense, a “road” or “path” may embody an outdoor or outdoor ground path, a waterway, or a defined air boundary, depending on the implementation. Thus, it should be understood that the following disclosure and related embodiments may be equally applicable to various contexts and vehicle implementations.

[0042] In some implementations, an in-vehicle computing system includes a communication module for supporting wireless communication using one or more technologies (e.g., IEEE 802.11 communication (e.g., WiFi), cellular data networks (e.g., 3rd Generation Partnership Project (3GPP) networks, Global System for Mobile Communications (GSM®), General Packet Radio Service, Code Division Multiple Access (CDMA), etc.), 4G, 5G, 6G, Bluetooth®, millimeter wave (mmWave), ZigBee®, Z-Wave, etc.), and the in-vehicle computing system is capable of connecting to and communicating with other computing systems such as in-vehicle computing systems of other vehicles, roadside units, cloud-based computing systems, or other support infrastructures, such that vehicles (e.g., 105, 110, 115) within the environment can be “connected.” For example, in some implementations, a vehicle (e.g., 105, 110, 115) can communicate with a computing system that provides sensors, data, and services in support of the vehicle's autonomous driving capabilities. For example, as shown in the example for the description of FIG. 1, among other examples, a support drone 180 (e.g., ground and / or aerial), a roadside computing device (e.g., 140), various external (external to the vehicle, or “extraneous”) sensor devices (e.g., 160, 165, 170, 175, etc.), and other devices may be provided as an autonomous driving infrastructure separate from the computing systems, sensors, and logic implemented in a vehicle (e.g., 105, 110, 115) to support and improve the results of autonomous driving provided through the vehicle. The vehicle can also communicate with other connected vehicles via a wireless communication channel to share data and coordinate movement within the autonomous driving environment, among other exemplary communications.

[0043] As shown in the example of FIG. 1, the autonomous driving infrastructure can be incorporated into a variety of different systems. Such systems can vary depending on location, and more developed roads (e.g., roads managed by a particular local government or toll authority, urban roads, sections of roads known to be problematic for autonomous vehicles, etc.) may have a greater number and more advanced support infrastructure devices than other sections of the road, etc. For example, auxiliary sensor devices (e.g., 160, 165, 170, 175) may be provided, which include sensors for observing vehicles moving within the road portion and environment and generating corresponding data for explaining or embodying the observation results of the sensors. By way of example, the sensor devices may be embedded, among other examples, in the road itself (e.g., sensor 160), roadside or overhead signs (e.g., sensor 165 on sign 125), roadside electronic devices or equipment (e.g., traffic lights (e.g., 130), electronic road signs, electronic billboards, etc.), sensors (e.g., 170, 175) attached to dedicated roadside units (e.g., 140). The sensor devices may also include communication capabilities to communicate the sensor data they collect directly to nearby connected vehicles or to fog-based or cloud-based computing systems (e.g., 140, 150). The vehicle can obtain data embodying the observation results or recommendations generated by other systems (e.g., 140, 150) based on the sensor data collected by external sensor devices (e.g., 160, 165, 170, 175, 180) or the sensor data from these sensor devices (e.g., 160, 165, 170, 175, 180) and use this data in sensor fusion, inference, path planning, and other tasks performed by the in-vehicle autonomous driving system. In some cases, such external sensors and sensor data may actually be within the vehicle, for example, in the form of commercially available sensors attached to the vehicle, personal computing devices (e.g., smartphones, wearables, etc.) carried or worn by the vehicle's passengers.Other road agents, including pedestrians, bicycles, drones, unmanned aerial vehicles, robots, electric scooters, etc., among other examples, may be equipped with, or carried by, sensors that generate sensor data that describes an autonomous driving environment and that may be used and consumed by autonomous vehicles, cloud or fog-based support systems (e.g., 140, 150), other sensor devices (e.g., 160, 165, 170, 175, 180).

[0044] Since the self-driving vehicle system can possess various levels of functionality and sophistication, a support infrastructure may be required not only to supplement the sensing capabilities of some vehicles but also to supplement the computers and machine learning functions that enable the self-driving functions of some vehicles. For example, the computer resources and self-driving logic used to facilitate machine learning model training and the use of such machine learning models can be provided entirely on the in-vehicle computing system or partially on both the in-vehicle system and some external systems (e.g., 140, 150). For example, a connected vehicle can communicate with a roadside unit, an edge system, or a cloud-based device (e.g., 140) within a specific segment of a road, and such a device (e.g., 140) can perform calculations (as a service) on data provided by the vehicle (e.g., sensor data aggregated from local sensors (e.g., 160, 165, 170, 175, 180) or data reported from sensors of other vehicles), supplement the vehicle's unique capabilities, and / or push information to vehicles passing by or approaching (e.g., at device 140 or based on sensor data collected from nearby sensor devices, etc.). A connected vehicle (e.g., 105, 110, 115) can also or instead communicate with a cloud-based computing system (e.g., 150) that can provide similar memory, sensing, and computing resources to enhance what is available in the vehicle. For example, among other exemplary implementations, a cloud-based system (e.g., 150) can collect sensor data from various devices at one or more locations and use this data to build and / or train a machine learning model that can be used in the cloud-based system (to provide results to various vehicles (e.g., 105, 110, 115) communicating with the cloud-based system 150 or to push to the vehicles for use by their in-vehicle systems).Access points such as cell phone towers, roadside units, network access points mounted on various road infrastructures, access points provided by neighboring vehicles or buildings, and other access points (e.g., 145) may be provided in the environment and used to facilitate communication between a cloud-based system (e.g., 150) and various vehicles (e.g., 105, 110, 115) via one or more local or wide area networks (e.g., 155). Through such infrastructure and computing systems, it should be understood that the examples, features, and solutions described herein can be fully implemented by one or more of such in-vehicle computing systems, fog-based or edge computing devices, or cloud-based computing systems, or combinations of the foregoing, through communication and coordination between systems.

[0045] Generally, the "server", "client", "computing device", "network element", "host", "platform", "sensor device", "edge device", "autonomous driving system", "autonomous vehicle", "fog-based system", "cloud-based system", and "system" described in this specification can generally include an electronic computing device operable to receive, transmit, process, store, or manage data and information associated with an autonomous driving environment. As used in this document, the terms "computer", "processor", "processor device", or "processing device" include, among other examples, a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a tensor processor, and other matrix operation processors, and are intended to encompass any suitable processing device. For example, an element shown as a single device within an environment may be implemented using multiple computing devices and processors, such as a server pool that includes multiple server computers. Further, any, all, or some of the computing devices may be adapted to execute any operating system, including Linux®, UNIX®, Microsoft® Windows®, Apple OS, Apple iOS®, Google Android®, Windows® Server, etc., and may also be a virtual machine adapted to virtualize the execution of a particular operating system, including a customized proprietary operating system.

[0046] Any flow, method, process (or part thereof), or function of any of the various components described below or shown in the figures may be performed by any suitable computing logic, such as one or more modules, engines, blocks, units, models, systems, or other suitable computing logic. References herein to "module", "engine", "block", "unit", "model", "system", or "logic" may refer to hardware, firmware, software, and / or any combination thereof for performing one or more functions. By way of example, a module, engine, block, unit, model, system, or logic may include one or more hardware components associated with a non-transitory medium storing code adapted to be executed by a microcontroller or processor, e.g., a microcontroller or processor. Thus, references to a module, engine, block, unit, model, system, or logic may, in one embodiment, refer to hardware specifically configured to recognize and / or execute code held on a non-transitory medium. Further, in another embodiment, the use of a module, engine, block, unit, model, system, or logic may refer to a non-transitory medium including code specifically adapted to be executed by a microcontroller or processor to perform a given operation. And, as may be inferred, in yet another embodiment, a module, engine, block, unit, model, system, or logic may refer to a combination of hardware and a non-transitory medium.In various embodiments, a module, engine, block, unit, model, system, or logic may include a microprocessor or other processing element operable to execute software instructions, discrete logic such as an application specific integrated circuit (ASIC), a programmable logic device such as a field programmable gate array (FPGA), a memory device containing instructions, a combination of logic devices (such as may be found on a printed circuit board), or other suitable hardware and / or software. A module, engine, block, unit, model, system, or logic may include one or more gates or other circuit components, which may be implemented, for example, by transistors. In some embodiments, a module, engine, block, unit, model, system, or logic may be implemented entirely as software. The software may be embodied as a software package, code, instructions, instruction sets, and / or data recorded on a non-transitory computer-readable storage medium. Firmware may be embodied as code, instructions, or instruction sets and / or data hard-coded (e.g., non-volatile) in a memory device. Further, the logic boundaries shown as separate generally vary and potentially overlap. For example, first and second modules (or engines, blocks, units, models, systems, or logic) may share hardware, software, firmware, or combinations thereof, while potentially retaining some independent hardware, software, or firmware.

[0047] The flows, methods, and processes described below and in the accompanying figures merely represent functions that can be performed in specific embodiments. In other embodiments, additional functions may be performed in the flows, methods, and processes. The various embodiments of the present disclosure envision any suitable signaling mechanism for performing the functions described herein. Some of the functions shown herein may be repeated, combined, modified, or deleted within the flows, methods, and processes, where applicable. Further, the functions may be performed in any suitable order within the flows, methods, and processes without departing from the scope of the specific embodiments.

[0048] Next, referring to FIG. 2, a simplified block diagram 200 is shown that illustrates an exemplary implementation of a vehicle (and corresponding in-vehicle computing system) 105 equipped with an autonomous driving function. In one example, the vehicle 105 may be equipped with one or more processors 202 such as, among other examples, a central processing unit (CPU), a graphics processing unit (GPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a digital signal processor (DSP), a tensor processor, and other matrix operation processors. Such a processor 202 may be coupled to, or integrated with, a hardware accelerator device (e.g., 204), which may be provided with hardware to speed up certain processing and memory access functions such as, among other examples, functions related to machine learning inference or training (including either of the machine learning inference or training described below), processing of specific sensor data (e.g., camera image data, LIDAR point cloud, etc.), and execution of specific arithmetic functions related to autonomous driving (e.g., matrix operations, convolution operations, etc.). One or more memory elements (e.g., 206) may be provided to store machine-executable instructions that implement all or any one part of the modules or sub-modules of the autonomous driving stack implemented in the vehicle, and to store a machine learning model (e.g., 256), sensor data (e.g., 258), and other data received, generated, or used (or used in connection with the examples and solutions described herein) in connection with the autonomous driving functions executed by the vehicle. Also, various communication modules (e.g., 212) may be implemented and provided in hardware circuitry and / or software to implement the communication capabilities used by the vehicle's system to communicate with other external computing systems via one or more network channels using one or more network communication technologies.These various processors 202, accelerators 204, memory devices 206, and network communication modules 212 can be interconnected on the vehicle system through one or more interconnect fabrics or links (e.g., 208), such as a fabric that utilizes technologies such as Peripheral Component Interconnect Express (PCIe), Ethernet (R), OpenCAPI (TM), Gen-Z (TM), UPI, Universal Serial Bus (USB), Cache Coherent Interconnect for Accelerators (CCIX (TM)), Advanced Micro Device (TM) (AMD (TM))'s Infinity (TM), Common Communication Interface (CCI), or Qualcomm (TM)'s Centriq (TM) interconnect, among others.

[0049] Continuing with the example of FIG. 2, an exemplary vehicle (and corresponding in-vehicle computing system) 105 may include, among other exemplary modular implementation functions of an autonomous vehicle in hardware and / or software, an in-vehicle processing system 210, a driving control unit (e.g., 220), sensors (e.g., 225), and a user / passenger interface (e.g., 230). For example, in some implementations, the in-vehicle processing system 210 may implement all or a portion of an autonomous driving stack and processing flow (e.g., as shown and described in the example of FIG. 5). The autonomous driving stack may be implemented in hardware, firmware, or software. A machine learning engine 232 may be provided to utilize various machine learning models (e.g., 256) provided to the vehicle 105 in connection with one or more autonomous functions and features provided to or implemented for the vehicle, as described in the examples herein. Such machine learning models 256 may include artificial neural network models, convolutional neural networks, decision tree-based models, support vector machines (SVMs), Bayesian models, deep learning models, and other exemplary models. In some implementations, the exemplary machine learning engine 232 may include one or more model training engines 252 for participating in the training (e.g., initial training, continuous training, etc.) of one or more of the machine learning models 256. Also, one or more inference engines 254 may be provided to derive various inferences, predictions, classifications, and other results using the trained machine learning models 256. In some embodiments, the training or inference of the machine learning models described herein may be performed outside of the vehicle, e.g., by computing systems 140 or 150.

[0050] The machine learning engine 232 provided in the vehicle can be utilized to support and provide results for use by other logical components and modules of the in-vehicle processing system 210 that implement the autonomous driving stack and other features related to autonomous driving. For example, the data collection module 234 can be provided with logic for determining a source from which data (e.g., for input in the training or use of various machine learning models 256 used by the vehicle) is collected. For example, a particular source (e.g., an internal sensor (e.g., 225) or an external source (e.g., 115, 140, 150, 180, 215, etc.)) can be selected, as well as the frequency and fidelity at which data can be sampled. In some cases, such selection and configuration can be performed autonomously by the data collection module 234, at least in part, using one or more corresponding machine learning models (e.g., assuming a particular detected scenario, and where applicable, for collecting data).

[0051] The sensor fusion module 236 can also be used to manage the use and processing of various sensor inputs utilized by the machine learning engine 232 and other modules (e.g., 238, 240, 242, 244, 246, etc.) of the in-vehicle processing system. One or more sensor fusion modules (e.g., 236) that can derive outputs from multiple sensor data sources (e.g., on or external to the vehicle) may be provided. The sources can be of the same or different types (e.g., multiple inputs from multiple instances of a common type of sensor, or from instances of multiple different types of sensors). The exemplary sensor fusion module 236 can apply direct fusion, indirect fusion, among other exemplary sensor fusion techniques. The output of the sensor fusion can, in some cases, be supplied as an input (along with potential additional inputs) to another module of the in-vehicle processing system and / or one or more machine learning models, in relation to providing an autonomous driving function or other functions, as described in the exemplary solutions described herein.

[0052] In some examples, a perception engine 238 may be provided, which in some examples may take various sensor data (e.g., 258) including data from external sources and / or the sensor fusion module 236 as input to perform object recognition and / or tracking of detected objects, among other exemplary functions corresponding to the autonomous perception of the environment that the vehicle 105 encounters (or will encounter). The perception engine 238 may use deep learning to perform object recognition from the sensor data input, for example, through one or more convolutional neural networks and other machine learning models 256. Object tracking may also be performed to autonomously estimate from the sensor data input whether an object is moving and, if so, along what trajectory it is moving. For example, after a given object is recognized, the perception engine 238 may detect how that given object moves with respect to the vehicle. Such functions may be used, for example, among other exemplary uses, to detect objects that may affect the path of a vehicle on a road, such as other vehicles moving within the environment, pedestrians, wildlife, bicyclists, etc.

[0053] In some implementations, a localization engine 240 may also be included within the vehicle processing system 210. In some cases, the localization engine 240 may be implemented as a sub-component of the perception engine 238. The localization engine 240 may also utilize one or more machine learning models 256 and sensor fusion (e.g., that of LIDAR and GPS data, etc.) to determine the highly reliable position of the vehicle and the space it occupies within a given physical space (or “environment”).

[0054] Vehicle 105 may further include a path planner 242 that can utilize the results of various other modules such as, among other things, data collection 234, sensor fusion 236, perception engine 238, and localization engine (e.g., 240) to determine a path plan and / or an operation plan of the vehicle for use by an operation control unit (e.g., 220) to control the operation of vehicle 105 in the environment. For example, the path planner 242 can utilize these inputs and one or more machine learning models to determine the probabilities of various events in the driving environment to determine an effective real-time plan for operating in the environment.

[0055] In some implementations, vehicle 105 may include one or more recommendation engines 244 to generate various recommendations from sensor data generated by sensors of vehicle 105 itself (e.g., 225) and sensor data from external sensors (e.g., on sensor devices 115, 180, 215, etc.). Some of the recommendations may be determined by the recommendation engine 244, and these recommendations may be provided as inputs to other components of the vehicle's autonomous driving stack and may affect the decisions made by these components. For example, when considered by the path planner 242, recommendations may be determined that cause the path planner 242 to deviate from a decision or plan that would otherwise be determined differently. Recommendations may also be generated by the recommendation engine (e.g., 244) based on considerations of passenger comfort and experience. In some cases, based on these recommendations (determined from sensor data (e.g., 258) captured by vehicle sensors and / or external sensors, etc.), the interior features within the vehicle may be operated predictively and autonomously.

[0056] As introduced above, some vehicle implementations may include a user / passenger experience engine (e.g., 246), which can utilize sensor data (e.g., 258) and the outputs of other modules within the vehicle's autonomous driving stack to control the vehicle's control unit, based on observations captured by the sensor data, to vary the driving maneuvers and bring about changes in the cabin environment to enhance the experience of passengers within the vehicle. In some examples, aspects of the user interface (e.g., 230) provided in the vehicle to enable the user to interact with the vehicle and its autonomous driving system may be improved. In some cases, among other exemplary uses, information presentation (e.g., audio, visual, and / or tactile presentation) may be generated and provided through the user display to help affect and improve the passenger experience within the vehicle (e.g., 105).

[0057] In some cases, a system manager 250 may also be provided to monitor information collected by various sensors on the vehicle to detect problems related to the performance of the vehicle's autonomous driving system. For example, computational errors, sensor power outages and problems, the availability and quality of communication channels (e.g., provided through the communication module 212), vehicle system checks (e.g., problems related to the motor, transmission, battery, cooling system, electrical system, tires, etc.), or other operating events may be detected by the system manager 250. Such problems may be identified in the system report data generated by the system manager 250, which, in some cases, can be used as inputs to the machine learning model 256 and related autonomous driving modules (e.g., 232, 234, 236, 238, 240, 242, 244, 246, etc.) to enable consideration of the normality and problems of the vehicle system, along with other information collected in the sensor data 258 in the autonomous driving function of the vehicle 105.

[0058] In some implementations, among other examples, the autonomous driving stack of vehicle 105 may be coupled to driving control 220 to affect how the vehicle is driven, including, for example, steering control (e.g., 260), accelerator / throttle control (e.g., 262), brake control (e.g., 264), signaling control (e.g., 266). In some cases, the vehicle may also be controlled fully or partially based on user input. For example, the user interface (e.g., 230) may include driving controls (e.g., physical or virtual steering wheel, accelerator, brake, clutch, etc.) to enable a human driver to take over control from the autonomous driving system (e.g., in a handover, or after a driver assistance operation). Other sensors such as voice detection 292, gesture detection camera 294, and other examples may be utilized to receive user / passenger input. The user interface (e.g., 230) may capture the wishes and intentions of the passenger / user, and the autonomous driving stack of vehicle 105 may consider these as additional inputs in the control of the vehicle's driving (e.g., driving control 220). In some implementations, the driving control may be managed by an external computing system, among other exemplary implementations, when a passenger utilizes an external device (e.g., smartphone or tablet) to provide the route or control of the driving, or in the case of a remote valet service where an external driver or system controls the vehicle (e.g., based on an emergency).

[0059] As described above, the autonomous driving stack of the vehicle can utilize various sensor data (e.g., 258) generated by various sensors provided in or outside the vehicle. As an example, vehicle 105 can possess an array of sensors 225 to collect various information related to the exterior and surrounding environment of the vehicle, the state of the vehicle system, the situation inside the vehicle, and other information usable by the modules of the vehicle's processing system 210. For example, such sensors 225 can include, among other exemplary sensors, a global positioning system (GPS) sensor 268, a light detection and ranging (LIDAR) sensor 270, a two-dimensional (2D) camera 272, a three-dimensional (3D) or stereo camera 274, an acoustic sensor 276, an inertial measurement unit (IMU) sensor 278, a temperature sensor 280, an ultrasonic sensor 282, a biometric sensor 284 (e.g., face recognition, voice recognition, heart rate sensor, body temperature sensor, emotion detection sensor, etc.), a radar sensor 286, and a weather sensor (not shown). Such sensors can be used in combination, among other examples, to determine the attributes and conditions of the environment in which the vehicle operates (e.g., weather, obstacles, traffic, road conditions, etc.), the passengers inside the vehicle (e.g., the awareness or attention of the passengers or driver, the comfort or mood of the passengers, the health or physiological state of the passengers, etc.), other contents of the vehicle (e.g., packages, livestock, cargo, luggage, etc.), and the subsystems of the vehicle. Sensor data 258 can also (or alternatively) be generated by sensors that are not integrally coupled to the vehicle, including sensors on other vehicles (e.g., 115) that can communicate with vehicle 105 through vehicle-to-vehicle communication or other technologies, sensors on ground-based or aerial drones 180, sensors of user devices 215 (e.g., smartphones or wearables) carried by human users inside or outside vehicle 105, and sensors mounted or provided on other roadside elements, such as roadside units (e.g., 140), road signs, traffic lights, street furniture, etc. Sensor data from such external sensor devices can, among other exemplary implementations, be provided directly from the sensor device to the vehicle, or provided as a result generated based on these sensors through a data aggregation device or by other computing systems (e.g., 140, 150).

[0060] In some implementations, the autonomous vehicle system 105 may interface with and utilize information and services provided by other computing systems to enhance, enable, or otherwise support the autonomous driving functionality of the device 105. In some examples, some autonomous driving features (including some of the exemplary solutions described herein) may be enabled through services, computing logic, machine learning models, data, or other resources of a computing system external to the vehicle. If the vehicle cannot utilize such an external system, these features may be at least temporarily disabled. For example, external computing systems may be provided and utilized, and these may be hosted on roadside units or fog-based edge devices (e.g., 140), other (e.g., higher-level) vehicles (e.g., 115), and cloud-based systems 150 (e.g., accessible through network access points (e.g., 145)). The roadside unit 140 or the cloud-based system 150 (or other collaborative systems with which the vehicle (e.g., 105) interacts using it) may potentially include all or part of the logic shown as belonging to an exemplary in-vehicle processing system (e.g., 210), along with additional functionality and logic. For example, a cloud-based computing system, the roadside unit 140, or other computing systems may include a machine learning engine that supports either or both of model training and inference engine logic. For example, such external systems may possess more high-end computing resources and more developed or up-to-date machine learning models, thereby enabling these services to provide superior results compared to what could originally be generated in the vehicle's processing system 210. For example, the in-vehicle processing system 210 may rely on machine learning training, machine learning inference, and / or machine learning models provided through cloud-based services for the processing of specific tasks and specific scenarios.In fact, one or more of the modules described and shown as belonging to vehicle 105 may, in some implementations, alternatively or redundantly, be provided within a cloud-based, fog-based, or other computing system that supports an autonomous driving environment.

[0061] Various embodiments herein may utilize one or more machine learning models to perform the functions of an autonomous driving vehicle stack (or other functions described herein). The machine learning models may be executed by a computing system to gradually improve the performance of a particular task. In some embodiments, the parameters of the machine learning model may be adjusted during a training phase based on training data. The trained machine learning model may then be used during an inference phase to make predictions or judgments based on input data.

[0062] The machine learning models described herein may take any suitable form or utilize any suitable technology. For example, any of the machine learning models may utilize supervised learning, semi-supervised learning, unsupervised learning, or reinforcement learning techniques.

[0063] In supervised learning, the model may be constructed using a training set of data that includes both inputs and corresponding desired outputs. Each training instance may include one or more inputs and a desired output. Training may include iterating through the training instances and teaching the model to predict the output for new inputs using an objective function. In semi-supervised learning, some of the inputs in the training set may lack desired outputs.

[0064] In unsupervised learning, a model can be constructed from a set of data that includes only the input and not the desired output. An unsupervised model can be used to find the structure in the data (e.g., grouping or clustering of data points) by discovering patterns in the data. Techniques that can be implemented with unsupervised learning models include, for example, self-organizing maps, nearest neighbor mapping, k-means clustering, and singular value decomposition.

[0065] In reinforcement learning models, positive or negative feedback can be given to improve accuracy. A reinforcement learning model can attempt to maximize one or more objectives / rewards. Techniques that can be implemented with reinforcement learning models can include, for example, Q-learning, temporal difference (TD), and deep adversarial networks.

[0066] The various embodiments described herein can utilize one or more classification models. In a classification model, the output can be restricted to a limited set of values. A classification model can output the class of an input set of one or more input values. References to classification models herein can be assumed to be, for example, models that implement any one or more of the following techniques, linear classifiers (e.g., logistic regression or naive Bayes classifiers), support vector machines, decision trees, boosting trees, random forests, neural networks, or nearest neighbor methods.

[0067] The various embodiments described herein can utilize one or more regression models. A regression model can output a numerical value from a continuous range based on an input set of one or more values. References to regression models herein can be assumed to be, for example, models that implement any one or more of the following techniques (or other suitable techniques), linear regression, decision trees, random forests, or neural networks.

[0068] In various embodiments, any of the machine learning models described herein may utilize one or more neural networks. A neural network may include a group of neural units that roughly model the structure of a biological brain, including a large class of neurons connected by synapses. In a neural network, neural units are connected to other neural units via links whose effects on the active states of the connected neural units can be excitatory or inhibitory. A neural unit may perform a function of updating the membrane potential of the neural unit using the values of its inputs. A neural unit may propagate a spike signal to a connected neural unit when a threshold associated with the neural unit is exceeded. A neural network may be trained or otherwise adapted to perform various data processing tasks (including tasks performed by an autonomous vehicle stack), such as computer vision tasks, speech recognition tasks, or other suitable computing tasks.

[0069] Figure 3 shows an exemplary portion of a neural network 300 according to a particular embodiment. Neural network 300 includes neural units X1 - X9. Neural units X1 - X4 are input neural units that each receive primary inputs I1 - I4 (which may be held constant while the neural network 300 processes an output). Any suitable primary input may be used. As an example, when neural network 300 performs image processing, the primary input values may be pixel values from an image (and the values of the primary inputs may be held constant while the image is being processed). As another example, when neural network 300 performs speech processing, the primary input values applied to a particular input neural unit may change over time based on changes in the input speech.

[0070] While a specific topology and connection scheme are shown in FIG. 3, the teachings of the present disclosure can be used in neural networks having any suitable topology and / or connection. For example, the neural network can be a feedforward neural network, a recurrent network, or any other neural network having any suitable connection between neural units. As another example, while the neural network is illustrated as having an input layer, a hidden layer, and an output layer, the neural network can have any suitable layers arranged in any suitable manner. In the illustrated embodiment, each link between two neural units has a synaptic weight that indicates the strength of the relationship between the two neural units. The synaptic weight is illustrated as WXY, where X indicates the pre-synaptic neural unit and Y indicates the post-synaptic neural unit. The links between neural units can have excitatory or inhibitory effects on the activation states of the connected neural units. For example, spikes propagating from X1 to X5 can increase or decrease the membrane potential of X5 depending on the value of W15. In various embodiments, the connections can be either directed or undirected.

[0071] In various embodiments, during each time step of the neural network, a neural unit can receive any suitable input, such as a bias value or one or more input spikes, from one or more of the neural units connected to the neural unit via their respective synapses (this set of neural units is referred to as the fan-in neural units of the neural unit). The bias value applied to a neural unit can be a function of the primary input applied to the input neural unit and / or any other value applied to the neural unit (e.g., a constant value that can be adjusted during training or other operations of the neural network). In various embodiments, each neural unit can be associated with its own bias value, or the bias value can be applied to a plurality of neural units.

[0072] A neural unit can execute a function using its input and the value of its current membrane potential. For example, to generate an updated membrane potential, an input can be added to the current membrane potential of the neural unit. As another example, a non-linear function such as a sigmoid transfer function can be applied to the input and the current membrane potential. Any other suitable function can be used. The neural unit then updates its membrane potential based on the output of the function.

[0073] Next, referring to FIG. 4, a simplified block diagram 400 is shown that illustrates exemplary levels of autonomous driving that can be supported in various vehicles (e.g., by their corresponding in-vehicle computing systems). For example, a range of levels may be defined (e.g., L0 - L5 (405 - 435)), where level 5 (L5) corresponds to a vehicle having the highest level of autonomous driving functionality (e.g., full automation), and level 0 (L0) corresponds to the lowest level of autonomous driving functionality (e.g., not automated). For example, an L5 vehicle (e.g., 435) may possess a fully autonomous computing system capable of providing autonomous driving performance equal to or better than what would be provided by a human driver in all driving scenarios, including extreme road conditions and weather. An L4 vehicle (e.g., 430) can also be considered fully autonomous, autonomously performing safety-critical driving functions and efficiently monitoring road conditions throughout the journey from the starting location to the destination. An L4 vehicle may differ from an L5 vehicle in that the L4 autonomous capabilities are defined within the limits of the vehicle's "operational design domain," which may not include all driving scenarios. An L3 vehicle (e.g., 420) provides an autonomous driving function that fully shifts safety-critical functions to the vehicle in a specific set of traffic and environmental conditions, but in all other scenarios, the human driver is involved in handling the driving and is still assumed to be available. Thus, an L3 vehicle may provide a handover protocol for organizing the transfer of control from the human driver to the autonomous driving stack and vice versa. An L2 vehicle (e.g., 415) provides driver assistance functions that allow the driver to sometimes disengage from physically operating the vehicle, such that both the driver's hands and feet can be periodically removed from physical control of the vehicle. An L1 vehicle (e.g., 410) provides driver assistance for one or more specific functions (e.g., steering, braking, etc.), but still requires a driver's constant control for most vehicle functions.The L0 vehicle may be considered non-autonomous, with a human driver controlling all of the vehicle's driving functions (however, such a vehicle can still passively participate in the autonomous driving environment, for example, by providing sensor data to a higher-level vehicle, or by using sensor data to enhance GPS and in-vehicle infotainment services). In some implementations, a single vehicle may support operation at multiple levels of autonomy. For example, a driver may control and select which level of autonomy support to use during a given trip (e.g., levels below L4). In other cases, the vehicle may autonomously toggle levels, for example, based on conditions that affect the autonomous driving system of the road or vehicle. For example, among other examples, in response to the detection that one or more sensors are impaired, an L5 or L4 vehicle may shift to a lower mode (e.g., below L2) so that a human passenger is involved in view of the sensor problem.

[0074] FIG. 5 is a simplified block diagram 500 showing an exemplary autonomous driving flow that may be implemented in some autonomous driving systems. For example, an autonomous driving flow implemented in an autonomous (or semi-autonomous) vehicle may include a sensing and perception stage 505, a planning and decision-making stage 510, and a control and operation stage 515. During the sensing and perception stage 505, data is generated by various sensors and collected for use by the autonomous driving system. Data collection may, in some examples, include data filtering and receiving sensor data from external sources. This stage may also include sensor fusion operations and object recognition, as well as other perception tasks performed using one or more machine learning models, such as localization. The planning and decision-making stage 510 may utilize the sensor data and the results of various perception operations to make a probabilistic prediction of the road ahead and determine a real-time route plan based on these predictions. Further, the planning and decision-making stage 510 may make decisions related to the route plan in response to the detection of obstacles and other events and determine whether and what actions should be taken to safely navigate the determined route in view of these events. Based on the route plan and decisions of the planning and decision-making stage 510, the control and operation stage 515 may convert these decisions into actions through actuators that operate driving controls including steering, acceleration, and braking, as well as secondary controls such as turn indicators, sensor cleaners, wipers, headlights, etc.

[0075] In some implementations, the autonomous driving stack may utilize a "perception, planning, actuation" model. For example, FIG. 6 shows an exemplary "perception, planning, actuation" model 600 for controlling an autonomous vehicle according to at least one embodiment. Model 600 may also be referred to in some instances as an autonomous vehicle control pipeline. In the example shown, the perception / sensing system 602 enables a digital construction of the environment (through sensor fusion) that includes moving and non-moving entities and their current positions relative to the sensing elements, and may include either a single type of sensor or a multimodal combination of sensors (e.g., LIDAR, radar, camera, HD map, or other types of sensors as shown). This allows the autonomous vehicle to build an internal representation of its surroundings and place itself within that representation (which may be referred to as an environmental model). The environmental model may, in some cases, include three types of components: static information about the environment (which may correlate with an HD map), dynamic information about the environment (e.g., objects moving on the road that may be represented by current position information and velocity vectors), and ego-position estimation information that represents the location within the model where the autonomous vehicle fits.

[0076] The environmental model may then be provided to the planning system 604 of the in-vehicle autonomous driving system, which receives the actively updated environmental information and constructs a plan for the operation (e.g., may include route information, behavior information, prediction information, and trajectory information) in response to the predicted behavior of these environmental conditions. The plan is then provided to the actuation system 606, which can operate the vehicle according to the plan (e.g., by operating the gas, brake, and steering systems of the autonomous vehicle).

[0077] In one or more embodiments, the social norm modeling system 608 exists between the perception and planning systems and functions as a parallel input to the planning system. The proposed social norm modeling system may function to provide an understanding of the adaptive semantic behavior of the vehicle's environment for the purpose of conforming the vehicle's behavior to social norms observed at a particular location. For example, in the example shown, the social norm modeling system 608 receives the environmental model generated by the perception system 602 along with the behavior model used by the planning system 604, and uses such information as input to determine a social norm model that can be provided back to the planning system 604 for consideration.

[0078] The social norm modeling system 608 may be able to obtain sensory information from the vehicle's sensing components and create a location-based behavior model of social driving norms. This information may be useful in dealing with the behavior of a timid self-driving vehicle, as this information can be used to quantify and interpret the behavior of a human driver in a way that does not make the self-driving vehicle more risk-averse than what a human driver would consider normal negotiation on the road. For example, current models may take a calculated approach, and thus measure the risk of collision when performing a particular action. However, this approach alone may disable a self-driving vehicle when entering a highway in an environment where aggressive driving is a social norm.

[0079] FIG. 7 shows a simplified social norm understanding model 700 according to at least one embodiment. The social norm understanding model may be implemented by a social norm modeling system of the self-driving vehicle control pipeline, e.g., the social norm modeling system 608 of the self-driving vehicle control pipeline 600.

[0080] In the example shown, at 702, the social norm modeling system first loads an environmental model and a behavior model of the autonomous vehicle. The environmental model can be the environmental model sent from the perception system of the autonomous vehicle control pipeline to the social norm modeling system (e.g., as shown in FIG. 6). The behavior policy can be received from the planning phase of the autonomous vehicle control pipeline (e.g., as shown in FIG. 6). In some cases, a default behavior policy used by the planning phase can be sent. In other cases, the behavior policy can be based on the environmental model sent from the perception system to the planning system.

[0081] At 704, the social norm modeling system determines whether the scenario illustrated by the environmental model is mapped to an existing social norm profile. If it is mapped, the existing social norm profile is loaded for reference. If it is not mapped, a new social norm profile is created. The newly created social norm profile can include default constraints and other information explaining the social norms. Each social norm profile can be associated with a specific scenario / environment (e.g., the number of vehicles around the autonomous vehicle, time, speed of surrounding vehicles, weather conditions, etc.), constraints (described further below), and other information explaining the social norms for the behavior policy. Each social norm profile can also be associated with a specific geographical location. For example, the same scenario can be presented at different geographical locations, but each scenario can have a different corresponding social norm profile, because the observed behavior can vary greatly at different locations.

[0082] Next, at 710, the social norm modeling system observes the dynamic information in the environmental model. The dynamic information may include behavior information about dynamic obstacles (e.g., other vehicles or humans on the road). The social norm modeling system then, in parallel, (1) determines or estimates a change in the observed behavior indicated by the dynamic obstacle at 712, and (2) determines or estimates a deviation from the observed behavior indicated by the dynamic obstacle from the behavior of the autonomous vehicle itself at 714. For example, the model may determine at 712 whether the observed behavior of other vehicles is within the current parameters of the behavior model loaded at 702, and at 714, may determine whether a deviation in the vehicle's behavior is within the current parameters of the behavior model.

[0083] Based on the determined changes and deviations, the social norm understanding model may determine at 716 whether the observed social norm has changed from the social norm profile. If it has changed, new information (e.g., constraints described below) may be stored in the social norm profile. If it has not changed, the model may determine at 720 whether the scenario has changed. If it has not changed, the model continues to observe the dynamic information and makes determinations about the changes and deviations in the observed behavior as described above. If the scenario has not changed, the model starts from 702 and executes the process from the beginning.

[0084] In some embodiments, the social norm understanding model 700 may be responsible for generating social norms as constraints based on the observations for the ego-vehicle behavior policy. The generation of these constraints may be derived from the temporal tracking behavior in the scenario of surrounding vehicles. In particular, two processes may be executed in parallel: · In the estimation of the change in behavior, analyze the Euclidean (or other distance metric, e.g., Mahalanobis) distance from the observations of all surrounding vehicles to the current behavior policy / model, and · In the estimation of the deviation, analyze the reaction of the surrounding vehicles to the observed driving policy to determine a negative feedback (violation) that functions as a limit of behavior.

[0085] The results of these two parallel processes can be used to determine the boundary limits of behavior that form social norms. This social norm (e.g., boundary limit) can then be returned to the planning module to function as a constraint for a particular driving scenario. Depending on the changes and deviations in behavior observed in the parallel processes, the resulting social norm can apply more stringent or more lenient constraints to the behavior planner to enable more natural driving behavior. In some cases, the construction of social norms can depend on characteristics of the scenario such as road shape and signaling, as well as the surrounding vehicles observed. Different social norms can emerge from combinations of the road environment and the number of passengers in the vehicles interacting with the host vehicle. In some examples, the model can allow for changes in social norms that occur over time.

[0086] In one exemplary implementation, the scenario can be configured in a road map shape that designates vehicles placed within these lanes having a state characterized by

Number

Number

Number

[0087] Δu i is the observed difference in vehicle control with respect to the behavior model. By applying the cost function to a defined observation result window N, the trajectory tryi is generated. Constraints on this trajectory plan are i,k y min < y i,k < y i,k max as static obstacles, dynamic obstacles (safety constraints) (x i,k ) ∈ S i (x, y), or the feasibility of a particular output u i,k can be obtained from. The interaction between each vehicle is

Number

[0088] When the understanding of driving culture / social norms is known (e.g., in the case of aggressive driving), the planning system can be adapted to change those negotiation means to be more or less aggressive and to change to accept risk because knowledge of the risks expected by other agents on the road results in a reduction in risk. Further, by monitoring social norms, problems related to the fact that the autonomous driving system is designed for a particular geographical context can be solved, because the behavior model can be designed for multiple geographical locations and can be improved over time. This approach also sets the basis for the creation and distribution of social driving norms. As autonomous vehicles come to make up a majority of the population on the road, this adaptive semantic behavior understanding system can allow for a common behavior model that dictates the negotiation of all agents on the road.

[0089] The operations in the exemplary processes shown in FIGS. 6 and 7 can be performed by various aspects or components of an in-vehicle computing system of an exemplary autonomous vehicle. The exemplary processes may include additional or different operations, and the operations may be performed in the order shown, or in a different order. In some cases, one or more of the operations shown in FIGS. 6 and 7 are implemented as a process that includes multiple operations, sub-processes, or other types of routines. In some cases, the operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated or performed in a different manner.

[0090] To achieve risk reduction, vehicle-to-vehicle communication (V2V) can be utilized by autonomous vehicles. For example, such communication can be used to inform events such as collisions, the location of obstacles on the road, etc. In other uses, remote sensing can be utilized for cooperative tasks such as mapping or maneuvering cooperation. In the second type of cooperative task, most concepts are limited to very specific traffic situations or applications such as cooperative adaptive cruise control (C-ACC) used to regulate platooning. C-ACC, for example, uses longitudinal adjustment to maintain a minimum time interval with the vehicle in front, obtaining improvements in traffic flow and fuel efficiency. In some systems, other regulated maneuvers such as lane changes and merges can be supported through a combination of longitudinal and lateral adjustments to establish a safe distance in the vehicle's path and adjacent lanes. However, control adjusted longitudinally and laterally may not be sufficient at intersections where the adjustment of multiple vehicles and the application of right-of-way rules are required to achieve coordination. Existing solutions are useful in specific driving scenarios but lack an interoperability mechanism. Furthermore, most of such solutions assume that each vehicle is connected and automated and that they are controlled by the same strategy at the same time. In this sense, the machine learning models used in some autonomous driving systems assume general vehicle behavior and make autonomous driving decisions based on these processes. The standard approach to autonomous driving systems can also apply models that assume ideals (e.g., other vehicles being autonomous, human drivers complying with the law, etc.). However, such solutions cannot be applied to mixed traffic scenarios where human drivers and their behavior cannot be controlled and where the rules or objectives of traffic cooperation may or may not be accepted.

[0091] In some implementations, the in-vehicle autonomous driving system of a particular vehicle may be configured to utilize a common behavior model communicated via a functional V2X communication technology (including vehicle-to-vehicle (V2V) or infrastructure-to-vehicle (I2V), etc.) to perform maneuver adjustments in fully automated or mixed traffic scenarios and support the autonomous driving decision-making and route planning of the particular vehicle. For example, as shown in FIG. 8, diagrams 800a-c showing the modes of adjustment between vehicles in an environment where at least some of the vehicles are semi-autonomous or fully autonomous are shown. For example, the behavior model can be constructed using driving rules in the case of automated vehicles or through a data learning process that derives prior driving behaviors. For example, as described above, a behavior model can be provided that enables continuous development and improvement through adaptation based on observations from the environment, which serves as a basis for modifying the learned constraints defined in the model. In the case of a vehicle driven by a human, there may be no model, and an approximate behavior model can be constructed over time using an artificial neural network. Such a neural network model can continuously learn and be improved based on the input provided to the model. For example, exemplary input parameters to such a model can include, among other examples, road environment information (e.g., mapping data), the position and velocity vectors of surrounding vehicles, the initial position and velocity vector of the host vehicle, and driver identification information (e.g., the demographics of a human driver). Thus, when a vehicle shares its behavior model with other vehicles, the version of the behavior model can be improved and further fine-tuned based on observations and further learning by the vehicles operating on the road.

[0092] As shown in FIG. 8, diagram 800a shows two vehicles A and B in an operating environment. V2V communication that enables one or both of the vehicles to share observation results and sensor data with the other can be enabled. For example, vehicle A may detect an obstacle (e.g., 805) affecting a section of the road and may further detect the presence of another vehicle (e.g., vehicle B) within or entering the same section of the road. In response, vehicle A may communicate information about the obstacle 805 (e.g., its coordinates, the type of obstacle or hazard factor (e.g., an object, an accident, a weather event, a power outage of a sign or traffic signal, etc.)), a computer vision-based classification determined for the obstacle (e.g., the obstacle being a bicycle). Further, as introduced above, vehicles A and B may also share behavior models with other vehicles using V2V or V2X communication. These models can be used by the receiving vehicle to determine the probability that a neighboring vehicle will take a particular action in a particular situation. These determined probabilities can then be used as inputs to the vehicle's own machine learning or other (e.g., logic-based such as rule-based) models, and autonomous driving logic, to influence decisions and route planning in the presence of these neighboring vehicles.

[0093] Figure 8 shows the flow for exchanging and using behavior models within an autonomous driving environment. For example, as shown in diagram 800a, two vehicles can identify each other's presence within a road segment and transmit information identifying the current position, pose, and speed of the transmitting vehicle to the other vehicle. One or more behavior models can be exchanged between vehicles or between a vehicle and an infrastructure mediator within the range where the behavior model has not yet been shared or obtained from other vehicles. As shown in diagram 800c, the behavior model uses as inputs mapping and other geographical data (e.g., identifying which potential routes can be driven), obstacles detected within these routes, and the state of the vehicle (e.g., its position, orientation, speed, acceleration, brakes, etc.). The output generated by the behavior model can indicate the probability that the corresponding vehicle will take a particular action (e.g., steering, braking, accelerating, etc.). The behavior model can be general or scenario-specific (e.g., lane keeping, lane changing, ramp merging, or intersection models, etc.). For example, the behavior model can be a "universal" model in the sense that for any particular driving scenario, it classifies the probability of the corresponding vehicle's actions in that scenario. In other cases, multiple scenario-specific or location-specific behavior models can be developed for a single vehicle (or vehicle type / model), and a collection of models can be exchanged (e.g., all at once as a package, scene by scene based on the location or scenario where the vehicle encounters other vehicles, etc.). In such an example, among other exemplary implementations, the vehicle first detects the planned scenario (e.g., based on decisions made in its own route planning phase), uses the result to identify a particular one of the shared models of other vehicles, identifies the behavior model that best "fits" the current scenario, and can use this behavior model.

[0094] Continuing with the example of FIG. 8, upon receiving the behavior model of vehicle A, vehicle B can detect that vehicle A is in its perception and further detect the current inputs of the behavior model from, for example, its own sensor array of vehicle B, an external data source (e.g., a roadside unit), or data shared by vehicle A via V2V (e.g., through a beacon signal) that explain the environment, obstacles, the speed of vehicle A, etc. These inputs (e.g., 810) can be provided as inputs to a common behavior model (e.g., 815) to derive a probability value P (e.g., 820). This probability value 820 can indicate the probability that vehicle A will perform a specific action, e.g., steering in a specific direction, accelerating, braking, maintaining speed, etc. (assuming the current environment of vehicle A and the observed state of the vehicle). This probability value 820 can then be utilized by the autonomous driving stack of vehicle B (e.g., 825) when planning its own path and making decisions related to the presence of vehicle A. Thus, among other exemplary implementations, through the use of a common behavior model, vehicle B can change the manner in which it determines the actions to take in the driving environment from the default approach or programming used by the autonomous driving stack 825 when driving in the presence of vehicles that do not have access to the behavior model.

[0095] Thus, in some implementations, in order for a vehicle to anticipate and plan for the actions and maneuvers of other vehicles, particularly vehicles having different levels of driving autonomy, the vehicle can obtain or otherwise access behavioral models of these other vehicles (using its own machine learning capabilities). Based on these models of neighboring vehicles, a vehicle sharing the road with these vehicles can predict how these vehicles will react based on conditions observed in the environment that affect each of the vehicles. By providing behavioral models of surrounding vehicles to a vehicle, the vehicle may be able to infer future scenarios through projection of environmental conditions. Thus, vehicles equipped with these additional behavioral models can plan risk-optimized decisions based on current observations and model-based predictions that present lower uncertainty. Such a solution not only increases safety in an autonomous driving environment, but may also be computationally more efficient, as vehicles using these other models do not need to compute individual behavioral models based on probabilistic projections of surrounding vehicles, but simply check whether the projections are certain and modify their behavior accordingly.

[0096] Referring now to FIG. 9, a block diagram 900 is shown that illustrates an exemplary information exchange between two vehicles 105, 110. In one example, connected vehicles may have multiple different modes of information exchange, including beacon exchange and model exchange. In one example, beacon exchange includes signaling a beacon 908 along with a state vector representing the identity of the corresponding vehicle (e.g., a connected autonomous vehicle identifier (CAVid)), the position, orientation, and direction of travel of the same vehicle. Model exchange may include signaling the behavioral model of the vehicle doing the signaling to other vehicles (and roadside systems).

[0097] Assume that a behavior model can be actuated by another vehicle in order to predict future vehicle behavior and take corresponding actions. In some cases, the behavior model may only be allowed to be used when received from a reliable vehicle. Therefore, the exchange of models between vehicles may include a trust protocol to enable the device and establish the initial reliability of the behavior model received from that vehicle. In some implementations, this reliability value may change over time if the output behavior is significantly different from the observed vehicle behavior. If the reliability value falls below a certain threshold, the model may be considered unsuitable. As shown in FIG. 9, in some implementations, when two vehicles 105, 110 encounter each other in an environment, the two vehicles (e.g., 105, 110) use beacon exchange to identify each other through their respective CAVid announcements. A vehicle (e.g., 105) can determine from the CAVid (e.g., at 910) whether the other vehicle (e.g., 110) is a known vehicle (or whether its behavior model is a known model). As a result, vehicle 105 can identify and access the corresponding behavior model (e.g., stored in a local cache or in a reliable (e.g., cloud or fog-based) database (e.g., 915)). Therefore, in some implementations, when encountering another vehicle, a lookup can be performed to determine whether the necessary behavior model corresponding to the indicated CAVid included in the beacon signal is in database 915. When it is determined that vehicle 105 does not possess the identified behavior model of vehicle 110, the vehicle may initiate model exchange by establishing a session through token exchange (at 920). In one example, each token (e.g., 925) may include a CAVid, a public key, and a secret value, as well as a session ID. Each vehicle (e.g., 105, 110) can receive the other's token and perform token verification 930 to confirm that the token is valid. Once the token signature is verified, approval can be shared with the other vehicle, indicating that the vehicle trusts the other and wishes to proceed with model exchange.In some implementations, model exchange may include communication (e.g., 935) of a behavior model that is split into multiple packets and communicated until the model exchange 940 of the last packet is complete (e.g., this may be indicated by approval). The session ID of the session may be used to enable data restoration if the connection between the two vehicles is lost, if necessary. V2V or V2X communication may be utilized in the communication between two vehicles. In some examples, the communication channel may be a high-throughput, low-latency 5G wireless channel or the like.

[0098] Upon receiving a behavior model of another vehicle, the vehicle may perform model verification 945 of the model. Model verification 945 may include checking the model for compliance and compatibility with the autonomous driving stack or machine learning engine of the receiving vehicle. In some examples, past inputs and the recorded outputs of the behavior model of the receiving vehicle are cached at the receiving vehicle, and the receiving vehicle may apply these cached inputs to the received behavior model and compare the outputs with the cached outputs to verify the validity of the received behavior model (e.g., validating the received behavior model if the outputs are equivalent). In other implementations, verification of the behavior model 945 may be performed by observing the performance of the corresponding vehicle (e.g., 110) and determining whether the observed performance corresponds to the expected performance determined through the behavior model (e.g., by providing inputs corresponding to the current environment to the model and identifying whether the outputs conform to the observed behavior of the vehicle). In the example of FIG. 9, when the received behavior model is verified, approval (e.g., 950) may be sent to the source vehicle and the session may be closed. Thereafter, the vehicles may continue to exchange beacons (at 955) to continuously identify their proximity and to share other information (e.g., sensor data, outputs of their models, etc.).

[0099] The example of FIG. 9 shows an example where an unknown vehicle is encountered and a new behavior model is shared. However, if two vehicles (e.g., 105, 110) have already shared behavior models with each other in the past, a lookup in the cache or behavior model database 915 will result in a positive outcome, and a model verification approval message can be shared between the two vehicles. In some cases, among other examples, the behavior model can be updated or invalidated. In that case, the vehicle can identify an update to another known vehicle (or vehicle model), and a model update exchange (e.g., in a manner similar to a full model exchange in a new session) can be executed. In some cases, a vehicle (e.g., 105) detects that the observed behavior of a particular vehicle does not conform to the predicted behavior determined when applying a previously stored version of the behavior model. Based on this (when encountering the particular vehicle subsequently), the vehicle can unilaterally determine that the already stored behavior model of a particular other vehicle (e.g., 110) is old, inaccurate, or incomplete. Such a determination can cause the vehicle (e.g., 105) to request an updated version of the behavior model (e.g., and trigger a model exchange similar to that shown in FIG. 9).

[0100] Through the exchange and collection of verified, accurate, and reliable behavior models, vehicles can in the future use beacon exchange to identify vehicles that use accurate and reliable behavior models in environmental navigation, thereby generating future predictions of the behavior of surrounding vehicles in an efficient manner. In some examples, a behavior model and CAVid can be provided for each vehicle. In other examples, each example of a particular self-driving vehicle model (e.g., vehicle make, model, and year) uses the same behavior model. Therefore, it can be assumed that when a vehicle encounters any example of this vehicle's model, among other examples, it can use the verification of a single behavior model associated with this vehicle's model.

[0101] The behavior model can be based on a machine learning model used to enable autonomous driving in the corresponding vehicle. In some cases, the behavior model can instead be based on a rule engine or heuristic (and thus can be rule-based). In some cases, the behavior model that is shared and exchanged with other vehicles can be different from the machine learning model actually used by the vehicle. For example, as described above, the behavior model can be a smaller, simpler "chunk" of the overall model and can correspond to a particular environment, scenario, road segment, etc. As an example, a scenario-specific behavior model can be a neural network model that indicates the probabilities of various operations of the corresponding vehicle in the context of a particular scenario (e.g., operations at intersections, operations at roundabouts, handling of lane change or drifting events, driving on highways, driving in adverse weather, driving in various degrees of altitude change, lane changes, etc.). Thus, multiple behavior models can be provided for a single vehicle and stored in the memory of the particular vehicle that uses these models. Further, among other exemplary implementations, by using these multiple models individually, compared to the use of a universal behavior model that models all potential behaviors of a particular vehicle, faster and more efficient (and accurate) predictions can be made by the particular vehicle.

[0102] In some examples, the exchange and collection of behavior models can be extended to cover vehicles driven by humans, including lower-level autonomous vehicles. In some examples, behavior models can be generated for individual drivers, groups of drivers (such as drivers in a particular region or location, drivers of a particular demographic), hybrid models (depending on whether the vehicle is operating in autonomous mode or human driver mode), and other examples. For example, a vehicle can include monitors (as OEM components or off-the-shelf components) for observing the behavior of a human driver and constructing a behavior model for this driver or group of drivers (e.g., by sharing monitoring data with a cloud-based aggregator application). In other examples, data from roadside sensors and / or cloud-sourced sensors that explain the observed driving of an individual human driver or group of drivers can be utilized, and a behavior model can be constructed based on this information. A behavior model for a human driver can be stored in an associated vehicle and shared with other vehicles according to other exchanges of behavior models as described in the above examples. In other examples, such as when a human-driven vehicle is not connected or does not support model exchange, other systems, such as roadside units, peer-to-peer (e.g., V2V) distribution by other vehicles, can be utilized to share and spread the behavior model for a human driver among other examples.

[0103] As more road agents become self-driving and urban infrastructure is modernized, collisions can occur between the various autonomous driving stacks and machine learning-based behavior models that these agents rely on. In fact, because different vehicle and autonomous system providers compete with individual solutions, it may be desirable to facilitate coordination and consensus building between the various models used by these many vehicles and other agents. Government legislation and regulation, as well as industry standardization, may develop to assist in promoting safety and compatibility between different technologies. However, if multiple key players are taking their own solutions, the question of overall safety improvement on the road remains unanswered. Since there is no clear way for politicians and the public to verify the decisions made by these vehicles, safety standards are still in their development phase. Additionally, in order to improve their models and corresponding decisions, older models and solutions (e.g., those included in vehicles during the early days of autonomous driving) can increase the risk on the road for self-driving vehicles. This creates the problem of behavior consensus, as road agents with old or malfunctioning self-driving vehicles may use conflicting models and not benefit from the improved capabilities offered through newer, evolved models.

[0104] Since the autonomous driving vehicle industry is young and developing, and 5G networks and infrastructure are in their infancy, V2X communications and solutions are similarly limited. For example, current V2X solutions provided today are mainly in the localization and mapping domain. As autonomous driving vehicles and the supporting infrastructure become more mainstream, opportunities arise to expand and develop new solutions that utilize the coordination and mutual communication between connected vehicles and their environments. For example, in some implementations, a vehicle's machine learning model can continuously evolve to adopt the safest, most efficient, and passenger-friendly innovations and "knowledge", and for example, a consensus and supporting protocol can be implemented that enables the construction of a consensus behavior model that can be shared and utilized to spread the "best" models across vehicles. For example, high-speed wireless network technologies (e.g., 5G networks) and improved road infrastructure can be utilized to assist such a consensus system.

[0105] In one example, to implement a fault-tolerant consensus, a Byzantine consensus algorithm may be defined and implemented among agents in an autonomous driving system. Such a consensus may depend on most providers (e.g., providers of a common behavior model) providing accurate information to the consensus system. The total amount of agents on the road at a given intersection at a given time may potentially be low, and thus the probability of a bad consensus increases (e.g., through model sharing among few agents), so the accuracy of the provision may be a problem in the context of autonomous vehicles. In some implementations, computing nodes may be provided, among other exemplary locations, for example, within a roadside unit (e.g., 140), mounted on streetlights, nearby buildings, traffic signals, etc., to coincide with road segments and road interchanges (e.g., intersections, roundabouts, etc.). In some cases, the computing nodes may be integrated with or connected to an auxiliary sensor device that may be capable of observing the traffic situation corresponding to the road segment. Such roadside computing devices (collectively referred to herein for convenience as "roadside units" or "RSUs") may be designated and configured to operate as a central point for collecting model provisions, distributing models among vehicles, verifying models across incoming connected autonomous vehicles, and determining a consensus from these models (if enabled, based on the observations of the RSU's sensors) at the corresponding road segment location.

[0106] In some implementations, a roadside unit implementing a consensus node for a particular section of a road receives model-based behavior information from the perception and awareness stack of each vehicle and can improve over time what the ideal behavior model for that road segment is. In doing so, this central point can verify the accuracy of the model by comparing the peers that are on the road at that time, as well as peers that previously negotiated in that same section of the road in the past. Thus, the consensus node can consider the model in a history-based fashion. This central node can then function as a leader in Byzantine consensus communication to standardize safety on the road between different parties, regardless of the different amounts and distribution of accurate consensus providers.

[0107] Next, referring to FIG. 10, a simplified block diagram 1000 is shown that illustrates an exemplary road intersection 1005. One or more roadside units (e.g., 140) may be provided that function as consensus nodes for the road segment 1005. In this example, the consensus node device (e.g., 140) may include one or more sensors, such as camera 1010. In some implementations, among other exemplary implementations, the consensus node may be implemented as two or more separate co-located computing devices that communicate and interact as a single device when executing a consensus service for the corresponding road segment 1005. The reliability of the roadside unit (e.g., 140) implementing the consensus node may be fundamental, and the RSU 140 may be partnered with a trusted entity such as a government agency. In some implementations, among other exemplary features, the RSU 140 may be configured with hardware, firmware, and / or software to perform attestation processing to attest its identity and reliability to other computing systems associated with other nearby road entities (e.g., vehicles 105, 110, 115, etc.). An exemplary RSU may wirelessly communicate with systems of other road entities, observe and capture vehicle-to-vehicle behavior model exchanges (as described above in the examples of FIGS. 8 and 9), directly receive behavior models from other road entities, determine a consensus model (from the model inputs it receives) (e.g., based on a Byzantine consensus scheme or algorithm), and distribute the consensus model to road entities (e.g., 105, 110, 115) for use in updating (or exchanging) their internal models to optimize the navigation of road entities on the corresponding road segment (e.g., 1005), and may include computing and memory resources with hardware and / or software-based logic for this purpose.

[0108] It should be understood that the RSU implementing the consensus node can do so without an auxiliary sensor device. However, in some implementations, the RSE sensor system (e.g., 1010) can provide useful inputs that can be utilized by the RSE in constructing the consensus behavior model. For example, the RSU may utilize one or more sensors (e.g., 1010) to observe entities (e.g., autonomous vehicles, electric scooters, and other small electric transportation means, bicycle riders, pedestrians, animals, etc.) on the road of non-autonomous vehicles and create a localized model (e.g., for a road segment (e.g., 1005)), and these observations can be included in the consensus model. For example, it can be assumed that an autonomous vehicle may not be able to communicate with the behavior model, and the sensor system of the RSU can construct a behavior model for autonomous vehicles, human drivers, and other entities on the road based on the observations of its sensors (e.g., 1010). For example, the sensor system and logic of an exemplary RSU (e.g., 140) can enable the recognition of a specific autonomous vehicle or even a specific human driver, and a corresponding behavior model can be developed based on the presence in the road environment (and the frequency of the presence of these entities). When such non-autonomous entities are detected by an autonomous driving vehicle (e.g., 105) applying the consensus model, a consensus model can be constructed for this road segment 1005 to incorporate knowledge of how to best plan routes and make decisions. In yet another example, the autonomous vehicle may still record the operations of the vehicle or its driver and record the environmental conditions corresponding to these recorded operations (e.g., to enable the detection of the driving response to these conditions), and communicate this information to the roadside unit to assist in providing data that can be used and integrated within the consensus model generated by each of these RSUs for their respective locations or road segments.OEM and commercially available systems may also be provided to enable some autonomous driving features in non-autonomous vehicles and / or to provide driver assistance, and such systems may be equipped with the ability to communicate with an RSU and obtain a consensus model for use in increasing the services and information provided through such driver assistance systems, among other exemplary implementations.

[0109] The consensus provider can be either an autonomous vehicle or a non-autonomous vehicle on the road. For example, when vehicles (e.g., 105, 110, 115) are within the range of each other and of the roadside unit 140 that manages the road segment (e.g., 1005), the vehicles can communicate with each other, share their respective behavior models, and participate in consensus negotiation. The RSU 140 can interfere in the negotiation and identify old, maliciously inaccurate, or incomplete models based on the consensus model developed by the RSU 140 over time. The consensus model is similar to a work description that prevents a small number of agents in the negotiation from dramatically degrading the quality of the accumulated knowledge embodied in the consensus model and invalidating them. Referring now to FIG. 11, diagrams 1105, 1110 are shown that illustrate that a locally localized behavior model consensus for a given road segment can be collected and determined over time (t) in view of the involvement of the corresponding RSU (e.g., 140) in each consensus negotiation for the road segment. This historical consensus approach allows for improved safety on the road because autonomous vehicles of different vehicle types and manufacturers with various autonomous driving systems can benefit from each other both currently and in the past. Such a consensus-based system applies a holistic and time-tested approach to road safety through the sharing of behavior models. Each agent on the road (e.g., 105, 110, 115), whether an autonomous vehicle or a non-autonomous vehicle, is expected to observe the environment and make a determination of how they should operate independently. All consensus providers (e.g., 105, 110, 115, 140, etc.) also attempt to predict the behavior of other agents on the road through their respective sensing systems. As can be seen from the illustration of diagrams 1105, 1110, autonomous vehicles (e.g., 105, 110, 115) then share their behavior models with the RSU (e.g., 140) and with each other.

[0110] Through the coordinated sharing of models in a consensus building scheme (e.g., based on the Byzantine consensus model), autonomous vehicles can then utilize their own perception of the environment through a consensus behavior model to determine the precise actions of other road agents, thereby enabling them and their peers to confirm whether their initial predictions about each other were accurate. This information and confirmation may also be visible to the RSU that is also involved in this consensus negotiation. Using knowledge of higher-risk behavior models that would result in a collision, voting can be initiated, where a distribution of behavior models that do not result in a collision or misunderstanding of the environment, including other road agents, is provided. To simplify the comparison and avoid re-execution of local behavior model predictions during the process, a hash or seed based on the selected model can be used. In some implementations, as a consensus node, the RSU's contribution to the consensus can be weighted based on previous successful consensus negotiations it has been involved in, which should be considered by other road agents. The confirmation of the consensus can then be checked based on the actions of the road agents.

[0111] Autonomous vehicles are expected to continue to share the road with human-driven vehicles (HV) that may exhibit irregular behavior not conforming to recorded driving habits. Human drivers may exhibit aggressive behavior (e.g., tailgating or driving through traffic jams) or timid behavior (e.g., driving at a speed significantly slower than the posted speed limit, which can also cause accidents). Irregular human driving patterns can also, in some cases, arise from driving habits in a particular region. For example, a maneuvering method sometimes referred to as "Pittsburgh left" observed in eastern Pennsylvania violates the standard rules of vehicle right-of-way at intersections by giving precedence to the first left-turning vehicle over vehicles going straight through the intersection (e.g., after both-way stop signs turn green). As another example, drivers in a particular region of a country may also drive more aggressively or less aggressively than drivers in other regions of that country.

[0112] An autonomous driving stack implemented through an in-vehicle computing system of an exemplary autonomous vehicle can learn and detect erratic behaviors presented by HVs and can be improved to respond to them safely. In some aspects, for example, an autonomous vehicle system can observe and track the frequency of erratic behaviors (e.g., those shown in the table below) to learn that an individual HV is likely to exhibit erratic behavior in the near future, or that a particular type of erratic behavior is more likely to occur in a given region of a country. [Table 1]

[0113] In some embodiments, an irregular driving pattern can be modeled as a series of driving actions that deviate from the normal behavior expected by an autonomous vehicle. FIGS. 12 and 13 show two examples of irregular driving patterns and how an autonomous vehicle can learn to adapt to such behavior in response to observing it.

[0114] FIG. 12 shows the above exemplary "Pittsburgh left" scenario. In the example shown, when traffic signal 1208 turns green, both HV 1202 and autonomous vehicle 1204 are stopped at intersection 1206. In a typical scenario, the autonomous vehicle has the right of way to pass through the intersection in front of the HV. However, in the Pittsburgh left scenario shown, the HV turns left first instead of yielding the right of way to the autonomous vehicle going straight through the intersection. By observing this behavior multiple times in a geographic area, the autonomous vehicle can learn to expect such behavior (assuming priority for the first left-turning vehicle) and thus enter intersections more cautiously when within that geographic area.

[0115] Figure 13 shows an exemplary "taunting driving" scenario by an HV. In the example shown, the driver of HV 1302 may be angry with the autonomous vehicle and thus may cut in front of the autonomous vehicle 1304 and may suddenly decelerate. In response, the autonomous vehicle may decelerate and change lanes to avoid the HV. The HV may then accelerate further and cut in front of the autonomous vehicle again and then suddenly decelerate again. Since the autonomous vehicle has seen this maneuver by the HV multiple times, the autonomous vehicle may detect that the HV is an angry driver who repeatedly cuts in front of the autonomous vehicle. The autonomous vehicle may then take corrective measures accordingly, such as, for example, handing control over to that human driver the next time a particular HV is encountered.

[0116] Figure 14 is a simplified block diagram showing an irregular / anomalous behavior tracking model 1400 of an autonomous vehicle according to at least one embodiment. In the example shown, the sensing phase 1410 of the autonomous vehicle software stack receives sensor data from the sensors 1402 of the autonomous vehicle and uses the sensor data to detect / identify anomalous behavior by a particular observed HV (e.g., in the anomalous behavior detection software module 1404 as shown). In response to the detection of anomalous behavior, or in parallel with that detection, an anonymous identity of the HV is created (e.g., in the anonymous identity creation software module 1406 as shown). The observed behavior of the HV and the associated identity are then used to track the frequency of the observed behavior by that HV and other HVs around the autonomous vehicle (e.g., in the dangerous behavior tracking software module 1408 as shown). In some cases, the tracked behavior may be used by the planning phase 1420 of the autonomous vehicle software stack to trigger a dynamic behavior policy for the autonomous vehicle in response to seeing a pattern of anomalous behavior in the HV. Aspects of the model 1400 are described further below.

[0117] In some embodiments, an autonomous vehicle can detect abnormal or irregular behavior by a given HV by tracking a series of driving operations, such as a driver who disrupts the safety model of the autonomous vehicle (e.g., a driver who does not maintain a safe lateral distance according to a set of rules of a responsibility-aware safety theory), a driver whose driving behavior is significantly different from that of other nearby drivers (e.g., a driver who drives significantly slower or faster than other drivers, or a driver who maneuvers through traffic jams and whose speed is significantly different from the surrounding traffic, and studies have shown that such a driver can increase the likelihood of an accident), or a driver whose actions cause other drivers to react unfavorably (e.g., a driver who is avoided by multiple drivers, or a driver who is honked at by multiple drivers).

[0118] In addition to tracking a series of driving operations, in some embodiments, an autonomous vehicle can also use audio and visual context information to classify types of drivers (e.g., distracted drivers vs. safe drivers who maintain a safe distance from other vehicles), driver attributes (e.g., paying attention to the road vs. looking down at a phone), or vehicle attributes (e.g., missing mirrors, cracked windshields, or other characteristics that make the vehicle unsuitable for road use) that are likely to lead to dangerous behavior in the near future. For example, video from an outward-facing camera on an autonomous vehicle can be used to train a computer vision model to detect vehicle attributes or driver attributes that increase the risk of an accident, such as a human driver using a mobile phone or limited visibility due to a snow-covered window. In certain examples, the computer vision model can be augmented with an acoustic model that can recognize aggressive behavior such as an aggressive honk, a scream, or dangerous situations such as a sharp brake on. The following table lists specific examples of audio and visual context information that can indicate a high likelihood of future dangerous behavior. [Table 2]

[0119] In some embodiments, the autonomous vehicle can track the frequency of observed erratic behavior by a particular vehicle (e.g., an HV) to determine whether it is a single driver exhibiting the same behavior within a given time frame (which may indicate a dangerous driver), or whether there are multiple drivers exhibiting the same behavior at a given location (which may indicate the social norms of that location).

[0120] To protect the privacy of human drivers, the autonomous vehicle can create an anonymous identity for a dangerous HV and tag dangerous behavior to this identity to track recurrence of tracking by the HV or other HVs. The anonymous identity can be created without relying on license plate recognition, which may not always be available or reliable. In some embodiments, an anonymous signature can be created by extracting representative features from a deep learning model used to recognize the vehicle. For example, a particular layer of the autonomous vehicle's deep learning network can capture features about the vehicle, such as its shape and color. These features can also be extended with additional attributes identifying the vehicle, such as its make, model, or unusual features such as dents, scratches, a cracked windshield, or the absence of a side mirror. Next, an encrypted hash can be applied to the combined features, and this hash can be used as an identifier for the HV during the autonomous vehicle's current trip. In some cases, this signature may not be completely unique to the vehicle (e.g., if there are similar-looking vehicles around the autonomous vehicle). However, it may be sufficient for the autonomous vehicle to identify dangerous vehicles during a trip. License plate recognition can be used in certain cases, such as when the autonomous vehicle needs to alert the authorities about a dangerous vehicle.

[0121] An autonomous vehicle can determine that a dangerous behavior is escalating by, for example, monitoring whether the period between dangerous events is decreasing or whether the severity of a dangerous operation is increasing. This information can then be fed into the planning phase of the AD pipeline to trigger dynamic policies such as avoiding a dangerous vehicle if the autonomous vehicle encounters it again or warning the authorities if the dangerous behavior poses a risk to other motorists on the road. The autonomous vehicle can also define a suppression policy for tracking the dangerous behavior of a given vehicle. For example, the suppression policy may require the autonomous vehicle to retain information about a dangerous driver only for a set number of trips or for a set period of time during the course of a trip.

[0122] In some embodiments, the autonomous vehicle can send data about detected abnormal behavior to the cloud for each vehicle. This data can be used to learn patterns of irregular behavior due to human driving and to determine whether such behavior is likely to occur in a given context. For example, it can be learned that drivers in a given city are likely to cut into traffic when the lateral distance between vehicles is greater than a certain distance, that drivers at a particular intersection are often slow without stopping, or that drivers using a mobile phone are likely to deviate from their lane. The data transmitted from the autonomous vehicle to the cloud can include, for example, · the dangerous vehicle, the vehicles adjacent to it, and the trajectory of the autonomous vehicle, · the driver of the dangerous vehicle and vehicle attributes, such as a driver using a mobile phone, poor visibility due to a snow-covered window, · geographical location, weather conditions, traffic signs, and traffic signal data, · the type of dangerous operation, which can be tagged as either a known operation, such as a hard stop that interfered with the safety model of the autonomous vehicle, or an unknown abnormal behavior flagged by the system.

[0123] In some embodiments, learning context-based patterns of human driving irregularities may include clustering the time series of driving actions associated with dangerous behaviors using techniques such as the longest common subsequence (LCS). Clustering can reduce the dimensionality of the vehicle trajectory data and identify representative orders of driving actions for each dangerous behavior. The following table provides examples of specific time series that can be clustered.

Table 3

[0124] Furthermore, in some embodiments, driving patterns that are likely to occur in a given context can be learned. For example, based on the order followed, it can be learned whether a particular irregular driving pattern is more common in a given city when it is snowing, or whether a particular driving action is likely to occur by an angry driver. This information can be used to model the conditional probability distribution of driving patterns in a given context. These context-based models enable an autonomous vehicle to anticipate the order in which dangerous vehicles are likely to act in a given scenario. For example, a context graph that tracks the frequency of occurrence of a certain driving pattern in a given context is shown in FIG. 15. As shown, the context graph tracks a specified order (the "driving pattern" node in FIG. 15) along with context information (the "context" node in FIG. 15) and the associated frequency of observations of the order and context (the weights of the edges in FIG. 15) to identify whether there are particular behavior patterns (e.g., patterns that predominantly occur in a particular geographic context, time context, etc.) that occur more frequently than other contexts in a particular context. The identified patterns can also be used to train a reinforcement learning model that identifies the actions an autonomous vehicle should take to avoid dangerous behavior. For example, the learned context behavior patterns can be used to dynamically modify the behavior model of the autonomous vehicle, such as when the autonomous vehicle enters or observes a particular context associated with the context behavior pattern.

[0125] FIG. 16 is a flowchart of an exemplary process 1600 for tracking erratic behavior observed by a vehicle according to at least one embodiment. Operations in the exemplary process 1600 may be performed by one or more components of an autonomous vehicle or a cloud-based learning module. The exemplary process 1600 may include additional or different operations, and the operations may be performed in the order shown, or in a different order. In some cases, one or more of the operations shown in FIG. 16 are implemented as a process that includes multiple operations, sub-processes, or other types of routines. In some cases, the operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated or performed in a different manner.

[0126] At 1602, sensor data is received from a plurality of sensors coupled to an autonomous vehicle, including a camera, LIDAR, or other sensors used by the autonomous vehicle to identify the vehicle and its surroundings.

[0127] In 1604, irregular or abnormal behavior is detected as being executed by one or more vehicles. In some cases, the detection can be made by comparing the observed behavior executed by a particular vehicle with the safety model of the autonomous vehicle, and based on the comparison, determining that the observed behavior interferes with the safety model of the autonomous vehicle. In some cases, the detection can be made by comparing the observed behavior executed by a particular vehicle with the observed behavior executed by other vehicles, and based on the comparison, determining that the observed behavior executed by the particular vehicle deviates from the observed behavior executed by the other vehicles. In some cases, the detection can be made by comparing the observed behavior executed by a particular vehicle with the observed behavior executed by other vehicles, and based on the comparison, determining that the observed behavior executed by the particular vehicle deviates from the observed behavior executed by the other vehicles. The detection may be made in another manner. The detection may be based on audio and visual context information in the sensor data.

[0128] In 1606, an identifier is generated for each vehicle for which irregular behavior has been observed. The identifier can be generated by obtaining the values of the respective features of a particular vehicle and applying an encryption to the combination of values to obtain the identifier. The values can be obtained by extracting representative features from a deep learning model used by the autonomous vehicle to recognize other vehicles. The identifier may be generated in another manner.

[0129] In 1608, the irregular behavior detected in 1604 is associated with the identifier generated in 1606 for the vehicle that executed each irregular behavior.

[0130] In 1610, for the identified vehicles, the frequency of occurrence of the irregular behavior is tracked.

[0131] At 1612, it is determined whether it is observed that the observed irregular behavior is executed by a specific vehicle more times than a threshold number. If so, at 1614, a dynamic behavior policy is initiated (e.g., to further avoid the vehicle). If not, the autonomous vehicle continues to operate under the default behavior policy.

[0132] FIG. 17 is a flowchart of an exemplary process 1700 for identifying a context behavior pattern according to at least one embodiment. The operations in the exemplary process 1700 may be performed by a learning module of an autonomous vehicle or a cloud-based learning module. The exemplary process 1700 may include additional or different operations, and the operations may be performed in the order shown, or in a different order. In some cases, one or more of the operations shown in FIG. 17 are implemented as a process that includes multiple operations, sub-processes, or other types of routines. In some cases, the operations may be combined, performed in a different order, performed in parallel, repeated, or otherwise repeated or performed in a different manner.

[0133] At 1702, tracking data of irregular behavior is received from multiple autonomous vehicles. The tracking data of irregular behavior may include entries that include a vehicle identifier, associated irregular behavior observed to be executed by the vehicle associated with the vehicle identifier, and context data indicating the context in which the irregular behavior was detected by the autonomous vehicle. In some cases, the context data may include one or more of trajectory information of the vehicle executing the irregular behavior, vehicle attributes of the vehicle executing the irregular behavior, driver attributes of the vehicle executing the irregular behavior, geographical location of the vehicle executing the irregular behavior, weather conditions around the vehicle executing the irregular behavior, and traffic information indicating the traffic conditions around the vehicle executing the irregular behavior.

[0134] In 1704, one or more sequences of erratic behavior are identified. This can be done, for example, by clustering the behavior using the longest common subsequence (LCS) technique.

[0135] In 1706, a context graph is generated based on the sequences identified in 1704 and the data received in 1702. The context graph can include a first set of nodes indicating the identified sequences and a second set of nodes indicating context data, and the edges of the context graph indicate the frequency of associations between the nodes.

[0136] In 1708, context behavior patterns are identified using the context graph, and in 1710, the behavior policy for one or more autonomous vehicles is modified based on the identified context behavior patterns. For example, the behavior policy can be modified for one or more autonomous vehicles based on the detection that the one or more autonomous vehicles are in a particular context associated with the identified context behavior pattern.

[0137] As described herein, the principles and features of modern computer vision (CV) and artificial intelligence (AI) can be utilized in an in-vehicle computing system to implement an exemplary autonomous driving stack for highly automated autonomous vehicles. However, CV and AI models and logic can be prone to misclassification and maloperation. A typical intrusion detection system (IDS) is slow and complex and can generate a significant amount of noise and false positives. A single-bit flip in a deep neural network (DNN) algorithm can cause misclassification of a complete image. Therefore, an improved autonomous driving system can be implemented to more accurately identify faults and attacks on highly automated autonomous vehicles.

[0138] The following disclosure provides various possible embodiments or examples for implementing a fault and intrusion detection system 1800 for a highly automated autonomous vehicle shown in FIG. 18. In one or more embodiments, vehicle motion prediction events and control commands, both of which are at a higher level of abstraction, are monitored. Based on the current state of vehicle motion parameters and road parameters, the vehicle remains within a certain motion envelope. A temporal normal behavior model 1841 is constructed to maintain adherence to the motion envelope. In at least one embodiment, at least two algorithms are used to construct the temporal normal behavior model. The algorithms include a vehicle behavior model 1842 (e.g., based on a Hidden Markov Model (HMM)) that learns normal vehicle behavior and a regression model 1844 to find deviations from the vehicle behavior model. In particular, the regression model is used to determine whether the vehicle behavior model accurately detects a fault, where the fault can be a vehicle system error or a malicious attack on the vehicle system.

[0139] For the purpose of showing some embodiments of a fault and intrusion detection system for a highly automated autonomous vehicle, it is important to first understand the possible activities associated with a highly automated autonomous vehicle. Thus, the following basic information can be referred to as a basis from which the present disclosure can be appropriately explained.

[0140] Modern computer vision (CV) and artificial intelligence (AI) used in self-driving vehicles are prone to misclassification and manipulation. For example, an attacker can generate stickers that can convince the vehicle that a sign actually means something else. Figure 19 shows such an operation, as seen in the "LOVE / HATE" graphics 1900 where "LOVE" is printed above the "STOP" of a stop sign and "HATE" is printed below the "STOP" of the stop sign. The sign marked with graffiti is clearly a stop sign to an English-speaking driver, but this graffiti can cause at least some computer vision algorithms to be convinced that the stop sign is actually a speed limit or a yield notice. Additionally, a single-bit flip error in a deep neural network (DNN) algorithm that classifies images can cause misclassification of the image. For example, instead of a large truck, a single-bit flip can cause the classifier to see a small animal or a bird.

[0141] Current (rule-based) intrusion detection systems (IDSs) are unsuitable for covering the full range of abnormal behaviors because they generate excessive noise and excessive false positives due to the nondeterministic nature of automotive networks. Error correction code (ECC) algorithms have limitations and are generally not useful for artificial intelligence. Adversarial generative networks (GANs) are valuable but highly dependent on the selection of adversarial data in the training set. Current machine learning-based intrusion detection systems are not suitable for use in automotive systems due to their high complexity and the large number of internal networks and external connections being monitored.

[0142] As shown in FIG. 18, a fault and intrusion detection system 1800 solves many (and more) of the aforementioned problems. The system 1800 includes a temporal normal behavior model 1841 having two algorithms, namely, a vehicle behavior model 1842 for learning the normal behavior of the vehicle and a regression model 1844 for predicting the likelihood of a certain behavior of the vehicle at a time interval t. The vehicle behavior model can be a probabilistic model for normal vehicle behavior. The vehicle behavior model learns a baseline low-rank static model and then models the deviation of the temporal model from the static model. Since this set of events is generally static over time, previous and new, vetted training samples retained through the fault and intrusion detection system are provided, and the vehicle behavior model can be updated through periodic reweighting of the parameters. The regression algorithm compares the likelihood of a change in movement based on a newly received control event calculated from the vehicle behavior model with a model (e.g., a motion envelope) predicted by the regression algorithm.

[0143] The fault and intrusion detection system 1800 provides several potential advantages. For example, the system 1800 monitors vehicle motion prediction events and control commands, which are at a higher level of abstraction than what is monitored by typical intrusion detection systems. Embodiments herein enable detection at a higher level where malicious attacks and intentions can be detected, rather than low-level changes that may not be captured by typical intrusion detection systems. Thus, the system 1800 enables detection of sophisticated and complex attacks and system malfunctions.

[0144] Next, referring to FIG. 18, the fault and intrusion detection system 1800 includes a cloud processing system 1810, a vehicle 1850, other edge devices 1830, and one or more networks (e.g., network 1805) that facilitate communication between the vehicle 1850 and the cloud processing system 1810 and between the vehicle 1850 and the other edge devices 1830. The cloud processing system 1810 includes a cloud vehicle data system 1820. The vehicle 1850 includes a CCU 1840 and a number of sensors, such as sensors 1855A - 1855E. The elements of FIG. 18 also include appropriate hardware components, including but not necessarily limited to processors (e.g., 1817, 1857) and memories (e.g., 1819, 1859), which can be implemented in a number of different embodiments.

[0145] In the vehicle 1850, the CCU 1840 can receive a nearly continuous data feed from the sensors 1855A - 1855E. The sensors can include any type of sensor described herein, including steering, throttle, and brake sensors. A number of other types of sensors (e.g., image capture devices, tire pressure sensors, road condition sensors, etc.) can also provide data to the CCU 1840. The CCU 1840 includes a temporal normal behavior model 1841 that includes a vehicle behavior model 1842, a regression model 1844, and a comparator 1846.

[0146] The vehicle behavior model 1842 can be trained with raw sensor data, such as steering sensor data, throttle sensor data, and brake sensor data, to learn vehicle behavior at a low level. Since events occurring in the vehicle are generally static over time, the vehicle behavior model can be given previous and new, vetted training samples retained through the fault and intrusion detection system, and the vehicle behavior model can be updated through periodic re - weighting of parameters.

[0147] In at least one example, the vehicle behavior model 1842 is a probabilistic model. A probabilistic model is a statistical model used to define relationships between variables. In at least some embodiments, these variables include steering sensor data, throttle sensor data, and brake sensor data. In a probabilistic model, there can be an error in predicting one variable from another. Other factors can explain the variations in the data, and the probabilistic model includes one or more probability distributions for explaining these other factors. In at least one embodiment, the probabilistic model can be a Hidden Markov Model (HMM). In an HMM, the system being modeled is assumed to be a Markov process of unobserved (e.g., hidden) states.

[0148] In at least one embodiment, the vehicle behavior model is in a pipeline to physical vehicle actuation. Actuation events (also referred to herein as "control events") can be marked as actuation events by a previous software layer. A vector structure can be used for different types of input data by the vehicle behavior model 1842 (e.g., a weather vector, a speed vector, a direction vector, etc.). For each parameter in the vector structure, the vehicle behavior model 1842 assigns a probability. The vehicle behavior model 1842 can be continuously executed on data going to the vehicle's actuators. Thus, each command (e.g., for changing the movement of the vehicle) can pass through the vehicle behavior model and maintain the behavior state of what the vehicle is doing.

[0149] Typically, a control event is initiated by a driver command (e.g., turning the steering wheel, applying the brakes, applying the throttle) or from sensors of an autonomous vehicle indicating the next movement of the vehicle. A control event can also result from a feedback loop from the sensors and actuators themselves. Generally, a control event indicates a change in movement by the vehicle. The vehicle behavior model 1842 can determine whether the change in movement is potentially abnormal or is an expected behavior. In particular, the output of the vehicle behavior model can be a classification of the change in movement. In one example, the classification can indicate the likelihood that the change in movement is a fault (e.g., a malicious attack or a defect in the vehicle's computer system).

[0150] The regression model 1844 predicts the likelihood of a change in the movement of the vehicle occurring at a given time interval t indicated by the control event. A regression algorithm is a statistical method for examining the relationship between two or more variables. Generally, a regression algorithm examines the effect of one or more independent variables on a dependent variable.

[0151] The input to regression model 1844 can include inputs from motion sensors other than those associated with a higher-level event, such as a control event. For example, if the control event is associated with a brake sensor, the input to the regression model can also include inputs from a throttle sensor and a steering sensor. The input can be received from other relevant vehicle sensors, such as a gyroscope indicating the inertia of the vehicle. Regression model 1844 can also receive inputs from other models within the vehicle, such as an image classifier that can classify images captured by an imaging device (e.g., a camera) associated with the vehicle. Additionally, regression model 1944 can include inputs from remote sources including, but not limited to, other edge devices such as cell sites, toll booths, infrastructure devices, satellites, other vehicles, radio stations (e.g., for weather forecasts, traffic conditions, etc.). Inputs from other edge devices can include environmental data providing additional information (e.g., environmental conditions, weather forecasts, road conditions, time, vehicle location, traffic conditions, etc.), which can be considered by the regression model to determine how the additional information affects the control event.

[0152] In at least one embodiment, the regression model 1844 is executed in the background and creates a memory of what the vehicle has done based on considering inputs from sensors, other models, remote sources such as other edge devices, etc., and predicts what the vehicle should do in a normal (fault - free) state. To apply limits to the vehicle behavior model, a motion envelope can be created. The motion envelope is a calculated prediction based on the vehicle's path and the input of the vehicle's destination during a given time interval t, assuming no problems occur. The regression model 1844 can determine whether a control event indicates a change in the vehicle's movement outside the motion envelope. For example, if the control event is a hard - brake event, the vehicle behavior model can determine that the brake event is outside the normal threshold range of the brakes and indicates a high probability of a fault in the vehicle system. However, the regression model can consider inputs from roadside infrastructure devices indicating traffic congestion (e.g., due to an accident). Thus, the regression model can determine that a hard - brake event is likely to occur within the predicted motion envelope, calculated at least in part based on the specific traffic situation during the time interval t.

[0153] The fault and intrusion detection system 1800 is agnostic to the type of regression algorithm used. For example, the Expectation - Maximization (EM) algorithm, which is an iterative method for finding the maximum likelihood of parameters in a statistical model such as an HMM that depends on hidden variables, can be used. In at least one embodiment, the regression algorithm (e.g., linear or lasso) can be selected to increase or decrease the degree of deviation allowed according to the desired motion envelope size. For example, one motion envelope can be restricted (or small) for vehicles used by the general public, while another motion envelope can be more relaxed for vehicles for military use.

[0154] To apply a limitation to the vehicle behavior model 1842, a comparator 1846 may be used. The comparator may compare the output classification of the vehicle behavior model 1842 with the prediction output by the regression model 1844, and determine whether the change in movement indicated by the control event is a failure or an acceptable change in movement that can occur within the predicted motion envelope. The output classification of the vehicle behavior model may indicate the likelihood that the change in movement indicated by the control event is a failure (e.g., a malicious attack or a defect in the vehicle's computer system). The prediction output by the regression model 1844 may be the likelihood that a change in movement can occur at a given time interval t based on input data from sensors, edge devices, other models within the vehicle, etc. The comparator may use the regression model to apply a limitation to the output classification of the control event by the vehicle behavior model.

[0155] In one example of the comparator function, the vehicle behavior model indicates that the braking event is potentially abnormal, while the regression model indicates that for the specific environmental conditions received as input (e.g., high speed from a sensor, a stop sign ahead on the road map, rain from a weather forecast), the expected braking event is within an acceptable threshold (e.g., within the motion envelope). Since the braking event is within the acceptable threshold based on the motion envelope, the comparator may determine that the evaluation of the vehicle behavior model indicating that the braking event is potentially abnormal can be invalidated, and a control signal may be sent to allow the braking operation to continue. In another example for illustration, the regression model 1844 recognizes that the vehicle is traveling at 35 mph on a city road and expects a stop sign at the intersection since it can access the map. The regression model also recognizes that the weather forecast is very cold. In contrast, the vehicle behavior model 1842 has an acceleration control event (e.g., receives a command to the actuator) because its image classifier wrongly determines that the stop sign ahead means a higher speed, or a hacker manipulates the control data and sends a wrong command to the accelerator. In this scenario, the classification output from the vehicle behavior model does not indicate that the control event is potentially abnormal, but the comparator may generate an error or a control signal based on the prediction output by the regression model that, assuming a motion envelope, the probability of the control event occurring during a given time interval t is low, which indicates that the vehicle should brake as it approaches the stop sign.

[0156] To implement the likelihood comparison feature of the temporal normal behavior model 1841, any one of a plurality of suitable comparators may be used. In at least one embodiment, the comparator may be selected based on the specific vehicle behavior model and regression model used.

[0157] Comparator 1846 can be triggered to send feedback to vehicle behavior model 1842 to modify the model. Feedback to the vehicle behavior model enables retraining. In one example, the system generates a memory of the errors committed based on the feedback and is retrained to identify similar scenarios, for example, based on location and time. Other variables can also be used for retraining.

[0158] Cloud vehicle data system 1820 can train and update a regression model (e.g., 1844) for a plurality of vehicles. In one example, cloud vehicle data system 1820 can receive feedback 1825 from a regression model (e.g., 1844) in a runner vehicle (e.g., 1850). Feedback 1825 can be sent to cloud vehicle data system 1820 for aggregation and recalculation to update the regression models of the plurality of vehicles to optimize behavior. In at least some examples, one or more edge devices 1830 can perform aggregation and, possibly, some training / updating operations. In these examples, feedback 1835 can be received from the regression model (e.g., 1844) to enable these aggregation, training, and / or updating operations.

[0159] Next, referring to FIG. 20, a block diagram of a simplified centralized vehicle control architecture 2000 for a vehicle, according to at least one embodiment, is shown. In the vehicle control architecture, a bus 2020 (e.g., a Controller Area Network (CAN), a FlexRay bus, etc.) connects tires 2010A, 2010B, 2010C, and 2010D, and their respective actuators 2012A, 2012B, 2012C, and 2012D to various engine control units (ECUs) including a steering ECU 2056A, a throttle ECU 2056B, and a brake ECU 2056C. The bus also connects a connection control unit (CCU) 2040 to the ECUs. The CCU 2040 is communicatively connected to sensors such as a steering sensor 2055A, a throttle sensor 2055B, and a brake sensor 2055C. The CCU 2040 can receive commands from an autonomous ECU or a driver in addition to feedback from one or more of the steering, throttle, and brake sensors, and / or actuators, and send commands to the appropriate ECUs. Vehicle behavior learning to generate a vehicle behavior model often uses raw data generated as described above. For example, a particular type of angle is currently made to the wheel, the brake pressure is a particular percentage, the acceleration, etc.

[0160] FIG. 21 is a simplified block diagram of an autonomous perception and control pipeline 2100. The control of the vehicle is passed to an engine control unit (ECU) responsible for operation. FIG. 21 shows an autonomous processing pipeline from sensors, through sensor fusion and planning ECU, and through vehicle control ECU. FIG. 21 shows various sensor inputs including out-of-sight, in-sight, vehicle state, and position. In particular, such inputs can be provided by V2X 2154A, radar 2154B, camera 2154C, LIDAR 2154D, ultrasonic device 2154E, movement of vehicle 2154F, speed of vehicle 2154G, GPS, inertia, telemetry 2154H, and / or high-definition (HD) map 2154I. These inputs are supplied to a central unit (e.g., a central processing unit) via a sensor model 2155. The sensor model 2155 provides inputs for performing probabilistic sensor fusion and motion planning 2110. Generally, sensor fusion includes evaluating all input data to understand the vehicle state, movement, and environment. A continuous loop can be used to predict the next movement of the vehicle, display relevant information in the vehicle's instrument cluster 2120, and send appropriate signals to vehicle control actuators 2130.

[0161] FIG. 22 is a simplified block diagram showing an exemplary x-by-wire architecture 2200 of a highly automated or autonomous vehicle. The CCU 2240 can receive inputs (e.g., control signals) from the vehicle's steering wheel 2202 and pedals 2204. However, in an autonomous vehicle, there may be no steering wheel and / or pedals. Instead, an autonomous driving (AD) ECU can take the place of these mechanisms and make all driving decisions.

[0162] A wired network (e.g., CAN, FlexRay) connects the CCU 2240 to the steering ECU 2256A and its steering actuator 2258A, to the brake ECU 2256B and its brake actuator 2258B, and to the throttle ECU 2256C and its throttle actuator 2258C. The wired network is specified by steer-by-wire 2210, brake-by-wire 2220, and throttle-by-wire 2230. In autonomous or highly autonomous vehicles, a CCU such as the CCU 2240 is a closed system with secure boot, attestation, and software components required for digital signatures. However, an attacker may be able to control the input to the sensors (e.g., images, radar, spoofing, etc.), manipulate the network traffic to the CCU, and / or compromise other ECUs (other than the CCU) within the vehicle. The network between the CCU 2240 and the actuators 2258A - 2258C cannot be compromised by additional hardware checks on the allowed traffic and connections. In particular, ECUs other than the CCU 2240 are not allowed on the wired network. The implementation may be cryptographic by binding these devices and / or by using other physical implementation methods using traffic transceivers and receivers (Tx / Rx).

[0163] FIG. 23 is a simplified block diagram showing an exemplary safety reset architecture 2300 for a highly automated or autonomous vehicle according to at least one embodiment. Architecture 2300 includes a CCU 2340 and a hardware / software monitor 2360 connected to a bus 2320 (e.g., CAN, FlexRay). The HW / SW monitor 2360 monitors the CCU 2340 for errors and resets the CCU when it is determined that a change in movement indicated by a control event is outside the range of a motion envelope calculated by a regression model. In at least one embodiment, the HW / SW monitor 2360 may receive an input from a comparator that makes a decision whether to send an error signal. In at least some embodiments, if an error signal is sent and the vehicle behavior is not efficiently corrected such that a self-reset of the CCU is within the predicted motion envelope, the CCU 2340 may safely stop the vehicle.

[0164] FIG. 24 is a simplified block diagram showing an example of a general safety architecture 2400 for a highly automated or autonomous vehicle according to at least one embodiment. The safety architecture 2400 includes a CCU 2440 connected via a bus 2420 (e.g., CAN, FlexRay) to a steering ECU 2456A and its steering actuator 2458A, a throttle ECU 2456B and its throttle actuator 2458B, and a brake ECU 2456C and its brake actuator 2458C. The CCU 2440 is also communicatively connected to a steering sensor 2455A, a throttle sensor 2455B, and a brake sensor 2455C. The CCU 2440 may also be communicatively connected to other entities for receiving environmental metadata 2415. Such other entities may include, but are not necessarily limited to, other sensors, edge devices, other vehicles, etc.

[0165] Several communications related to safety may occur. First, in the CCU, throttle, steering, and brake commands, as well as sensory feedback, are received from the actuators and / or sensors. Additionally, environmental metadata 2415 may be transmitted from the autonomous driver assistance system (ADAS) or the autonomous driver ECU (AD ECU). This metadata may include, for example, the type of road and road, weather conditions, and traffic information. This can be used to create a restricted motion envelope and predict movement for the next few minutes. For example, when the vehicle is moving on a suburban road, the speed limit may be restricted to 25 or 35 miles per hour. If a command conflicting with the speed limit is received from the AD ECU, the CCU may identify it as a failure (e.g., a malicious attack or an error without malice).

[0166] Other redundant schemes may also be used to see if the system is recoverable. Temporal redundancy 2402 may be used to read the command multiple times and use median voting. Information redundancy 2404 may be used to process the value multiple times and store several copies in memory. Additionally, majority voting 2406 may be used to schedule the control commands of the ECU. If the redundant scheme does not allow the system to recover from the error, the CCU may safely stop the vehicle. For example, in 2408, other safety controls may include constructing a hypothesis of the vehicle motion vector, restricting movement within the hypothesis envelope, and stopping the vehicle if the control value goes outside the envelope range.

[0167] FIG. 25 is a simplified block diagram showing an exemplary operational flow 2500 of a fault and intrusion detection system for a highly automated autonomous vehicle according to at least one embodiment. In FIG. 25, several operations are shown within CCU 2540. CCU 2540 represents an example of CCU 1840 and shows possible operations and activities that can occur in CCU 1840. The operations correspond to the algorithms of a temporal normal behavior model (e.g., 1841). HMM evaluation 2542 corresponds to a vehicle behavior model (e.g., 1842), regression evaluation 2544 corresponds to a regression model (e.g., 1844), and likelihood comparison 2546 corresponds to a comparator (e.g., 1846).

[0168] Control event 2502 is received by CCU 2540 and can be used for both HMM evaluation 2542 and regression evaluation 2544. The control event can result from a driver command, from sensors of the autonomous vehicle indicating the next movement of the vehicle, or from a feedback loop from sensors or actuators. The HMM evaluation can determine the likelihood that a change in movement indicated by the control event is a fault. HMM evaluation 2542 can also receive sensor data 2555 (e.g., throttle sensor data, steering sensor data, tire pressure sensor data, etc.) to help determine whether a change in movement is normal behavior or indicates a fault. The vehicle behavior model can receive feedback 2504 from a comparator (e.g., 1846), and for example, the feedback can recognize previously made mistakes and modify the vehicle behavior model to identify similar situations (e.g., based on position and / or time). Thus, HMM evaluation 2542 can be executed differently based on the feedback from the comparator.

[0169] Regression evaluation 2544 predicts the likelihood of a change in movement that occurs at a given time interval t under normal conditions, as indicated by a control event. The input to the regression evaluation can include sensor data 2555 and input data from remote data sources 2530 (e.g., other edge devices 1830). Additionally, the regression model that performs the regression evaluation 2544 can be updated by feedback 2504 from the cloud (e.g., from the cloud vehicle data system 1820), and the regression model is updated to optimize vehicle behavior and enjoy the benefits of learning in other vehicles.

[0170] In one example, regression evaluation 2544 creates a motion envelope defined by one or more limits or thresholds of normal vehicle behavior based on consideration of inputs from sensors, other models, other edge devices, etc. The regression evaluation 2544 can then determine whether a change in movement indicated by a control event is outside one or more of the limits or thresholds of the motion envelope.

[0171] The likelihood comparison 2546 can be performed based on the classification of the movement changes output from the HMM evaluation 2542 and the prediction output from the regression evaluation 2544. The classification output from the HMM evaluation can indicate the likelihood that the movement change is a failure (e.g., a malicious attack or a malfunction of the vehicle computer system). The prediction output from the regression evaluation 2544 can be the likelihood that a movement change can occur within a given time interval t, based on input data from sensors, edge devices, other models within the vehicle, etc. If the prediction output from the regression evaluation indicates that the likelihood of a movement change occurring during a given time interval t is low, and the classification output from the HMM evaluation indicates that the likelihood of the movement change being a failure is high, the prediction can be outside the limits or range of the motion envelope, and the output classification can be outside the normal threshold range as shown at 2547, and an error signal 2506 can be sent to the appropriate ECU to take corrective measures and / or to the appropriate device display. If the prediction output from the regression evaluation indicates that the likelihood of a movement change occurring during a given time interval t is high, and the classification output by the HMM evaluation indicates that the likelihood of the movement change being a failure is not high (e.g., it is likely to be normal), the prediction can be within the limits or range of the motion envelope, and the output classification can be within the normal threshold range as shown at 2548, and an operation 2508 that causes the movement change indicated by the control event is allowed to occur. In at least some implementations, a signal can be sent to allow the operation to occur. In other implementations, the operation can occur even without an error signal.

[0172] In other scenarios, the predictions output by the regression evaluation 2544 and the classifications output by the HMM evaluation 2542 may be inconsistent. For example, if the prediction output by the regression evaluation indicates that there is a low likelihood of a change in movement during a given time interval t, and the classification output by the HMM evaluation indicates that the change in movement is unlikely to be a failure (e.g., it is likely to be normal behavior), an error signal 2506 may be sent to the appropriate ECU for controlling vehicle behavior and / or to an appropriate device display. This may be due to the regression evaluation considering additional conditions and factors (such as other sensor data, environmental data, etc.) that constrain the movement envelope such that the change in movement is outside one or more of the limits or thresholds of the movement envelope and is less likely to occur under specific conditions and factors. As a result, even when the classification output by the HMM evaluation indicates that the change in movement is normal, the regression evaluation may cause an error signal to be sent.

[0173] In another example, if the prediction output by the regression evaluation indicates that there is a high likelihood of a change in movement indicated by a control event during a given time interval t, and the classification output by the HMM evaluation indicates that the change in movement is likely to be a failure, a threshold can be evaluated to determine whether the classification output from the HMM evaluation indicates a likelihood of failure exceeding a desired threshold. For example, if the HMM output classification indicates that the probability that the change in movement is abnormal behavior is 95%, but the regression evaluation output prediction indicates that there is a high likelihood of a change in movement because it is within the limit or threshold of its predicted motion envelope, the HMM output classification can be evaluated to determine whether the probability of abnormal behavior exceeds the desired threshold. If so, an error signal 2506 can be sent to the appropriate ECU to control or otherwise affect the vehicle behavior and / or to an appropriate device display. However, if it does not exceed the desired threshold, the action causing the change in movement may be allowed due to the regression evaluation considering additional conditions and factors (such as other sensor data, environmental data, etc.) that relax the motion envelope such that the change in movement is within the limit or threshold of the motion envelope and represents behavior expected under specific conditions and factors.

[0174] Furthermore, a sample hold 2549 of the results of a likelihood comparison 2546 of specific control events (or all control events) can be stored and used to retrain the vehicle behavior model and / or the regression model and / or can be stored and used for multiple evaluations.

[0175] FIG. 26 is a simplified flowchart showing a high-level possible flow 2600 of operations associated with a fault and intrusion detection system such as system 1800. In at least one embodiment, a set of operations corresponds to the activities of FIG. 26. A CCU within the vehicle, e.g., CCU 1840 within vehicle 1850, may utilize at least a portion of this set of operations. Vehicle 1850 may include one or more data processors (e.g., 1857) for performing the operations. In at least one embodiment, vehicle behavior model 1842 performs one or more of the operations.

[0176] At 2602, a control event is received by vehicle behavior model 1842. At 2604, sensor data of the vehicle is obtained by the vehicle behavior model. At 2606, the vehicle behavior model is used to classify a change in movement (e.g., braking, accelerating, steering) indicated as a fault or not by the control event. In at least one embodiment, the classification may indicate the likelihood (e.g., probability) that the change in movement is a fault. At 2608, the output classification of the change in movement is provided to a comparator.

[0177] FIG. 27 is a simplified flowchart showing a high-level possible flow 2700 of operations associated with a fault and intrusion detection system such as system 1800. In at least one embodiment, a set of operations corresponds to the activities of FIG. 27. A CCU within the vehicle, e.g., CCU 1840 within vehicle 1850, may utilize at least a portion of this set of operations. Vehicle 1850 may include one or more data processors (e.g., 1857) for performing the operations. In at least one embodiment, regression model 1844 performs one or more of the operations.

[0178] At 2702, a control event is received by the regression model 1844. The control event indicates a change in movement such as braking, steering, or acceleration. At 2704, vehicle sensor data is obtained by the regression model. At 2706, related data from other sources (e.g., remote sources such as edge device 1830, local sources downloaded and updated within the vehicle, etc.) is obtained by the regression model.

[0179] At 2708, the regression model is used to predict the likelihood that a change in movement indicated by the control event will occur during a given time interval t. The prediction is based at least in part on the sensor data and data from other sources. At 2710, the outputted prediction of the likelihood that a change in movement will occur during time interval t is provided to a comparator.

[0180] Figure 28A is a simplified flowchart showing a high-level possible flow 2800 of operations associated with a fault and intrusion detection system such as system 1800. In at least one embodiment, the set of operations corresponds to the activities of FIG. 27. A CCU within the vehicle, e.g., CCU 1840 within vehicle 1850, may utilize at least a portion of this set of operations. Vehicle 1850 may include one or more data processors (e.g., 1857) for executing the operations. In at least one embodiment, comparator 1846 executes one or more of the operations.

[0181] At 2802, a classification of a change in the movement of the vehicle is received from a vehicle behavior model. The outputted classification provided to the comparator at 2608 of FIG. 26 corresponds to receiving the classification from the vehicle behavior model at 2802 of FIG. 28A.

[0182] At 2804, a prediction of the likelihood that a change in movement will occur during time interval t is received from the regression model. The outputted prediction provided to the comparator at 2710 of FIG. 27 corresponds to receiving the prediction at 2804 of FIG. 28A.

[0183] At 2806, the comparator compares the classification of the movement change with the prediction of the likelihood of a movement change occurring during the time interval t. At 2808, a determination is made as to whether the movement change classified by the vehicle behavior model is within the range of the threshold (or limit) of the expected vehicle behavior predicted by the regression model. Generally, when the movement change classified by the vehicle behavior model is within the range of the threshold of the expected vehicle behavior predicted by the regression model, at 2810, a signal allowing the movement change to proceed may be transmitted (or the movement change may proceed due to the absence of an error signal). Generally, when the movement change classified by the vehicle behavior model is not within the range of the threshold (or limit) of the vehicle behavior predicted by the regression model, at 2812, an error signal may be transmitted to warn the driver to take corrective measures or to warn the autonomous driving system to take corrective measures. A more detailed description of the possible comparator operations is provided in FIG. 28B.

[0184] FIG. 28B is a simplified flowchart showing a high-level possible flow 2850 of additional operations associated with comparator operation, as shown more specifically at 2808 in FIG. 28A.

[0185] At 2852, a determination is made as to whether the following conditions, namely, that the classification output from the vehicle behavior model (e.g., HMM) indicates a fault and that the prediction output by the regression model indicates a fault based on the same control event, are true. If both conditions are true, at 2854, an error signal (or control signal) may be transmitted to warn the driver to take corrective measures or to warn the autonomous driving system to take corrective measures.

[0186] If at least one of the conditions in 2852 is false, then in 2856, a determination is made as to whether the following two conditions are true, namely, that the classification output from the vehicle behavior model indicates a fault and that the prediction output by the regression model does not indicate a fault based on the same control event. If both conditions are true, then in 2858, another determination is made as to whether the classification output from the vehicle behavior model exceeds a desired threshold that could invalidate the output of the regression model. If so, then in 2854, an error signal (or control signal) can be sent to warn the driver to take corrective action or to warn the autonomous driving system to take corrective action. If not, then in 2860, a signal can be sent to allow the vehicle behavior indicated by the control event to proceed (or the movement can proceed due to the absence of an error signal).

[0187] If at least one of the conditions in 2856 is false, then in 2862, a determination is made as to whether the following conditions are true, namely, that the classification output from the vehicle behavior model does not indicate a fault and that the prediction output by the regression model indicates a fault based on the same control event. If both conditions are true, then in 2864, an error signal (or control signal) can be sent to warn the driver to take corrective action or to warn the autonomous driving system to take corrective action.

[0188] If at least one of the conditions in 2862 is false, then in 2866, the following conditions, namely, that the classification output from the vehicle behavior model does not indicate a fault and that the prediction output by the regression model does not indicate a fault based on the same control event, should be true. If both conditions are true, then in 2868, a signal can be sent to allow the vehicle behavior indicated by the control event to proceed (or the movement can proceed due to the absence of an error signal).

[0189] The level of autonomy of a self-driving vehicle depends greatly on the number and type of sensors equipped in the self-driving vehicle. In addition, many different functions of a self-driving vehicle, such as autonomous driving on a highway, for example, are realized by a specific set of sensors that function well to provide the self-driving vehicle with appropriate information processed by the algorithms of the vehicle's control system.

[0190] Since sensors play such an important role in the operation of a self-driving vehicle, it is important to know the normality of various sensors. In addition to safety concerns about the normality of sensors (if there is a sensor failure, the vehicle may not be able to continue driving autonomously), there are other benefits to knowing the normality of the vehicle's sensors. This may include, for example, enhancing driver / passenger trust and improving the efficiency of the self-driving vehicle.

[0191] As the technology of self-driving vehicles improves, the number of sensors in self-driving vehicles is increasing. For example, to reach automation level 3, some vehicle manufacturers have equipped their vehicles with more than 14 sensors. Figure 29 shows an example of a sensor array commonly found in self-driving vehicles. Sensors can include, for example, radar, LIDAR, cameras, and ultrasonic sensors. Having more sensors can account for increased redundancy and functionality, but in the event of a sensor failure, the self-driving vehicle can be configured to self-recognize and determine the vehicle's capabilities after the failure.

[0192] FIG. 30 shows an example of a Dynamic Autonomous Level Detection (“DALD”) system 3000 that is compatible with autonomous vehicle functions based on sensing and processing capabilities available to a vehicle. In some embodiments, system 3000 may consider the driver's desired experience (e.g., the level of autonomy the driver desires) and the current progress of the vehicle's operation. This DALD system may utilize different inputs, such as one or more of weather conditions, sensor performance, vehicle customization, and driver plans, for example, to dynamically determine the necessary maximum level of autonomy for which the vehicle should function for a defined route. In this way, the vehicle may adapt its function based on the health of existing sensors, vehicle customization (e.g., a vehicle with a trailer that obscures rear sensors), weather conditions, and the like.

[0193] Continuing to refer to FIG. 30, system 3000 includes a score module 3005 and a safety module 3010. Score module 3005 may also be regarded as an “L” score calculation module. The score module estimates the level of autonomy (“L”) that the vehicle may implement based on different inputs received by system 3000. Examples of inputs received by DALD system 3000 may include sensor state (or health) information 3030, desired user experience 3040, weather conditions 3050, computing resources 3020, and vehicle customization state 3060. Note that the list of inputs herein is merely illustrative, and it should be noted that more or fewer inputs than those listed may be considered inputs to system 3000.

[0194] As an example, the “L” score may be defined as follows. [Number]

[0195] Here, the input i is one of N different inputs to DALD system 3000 illustrated in FIG. 30, and W i is for each input iThey are different weights associated therewith. The weights can change dynamically as the capabilities of the autonomous vehicle change over time and depend, for example, on the architecture of the autonomous vehicle such as the vehicle's sensors and algorithms. W i being 0 means that the input i has been disabled. The autonomous vehicle then adapts its L スコア to a number corresponding to different levels of automation available for the vehicle, which can be an integer from 0 to 5 when the maximum level of automation available for the vehicle is level 5.

[0196] Note that in at least some embodiments, the weights also need to satisfy the following conditions in order to consistently generate L スコア when the number of contributing inputs changes.

Number

[0197] Thus, in one embodiment, when one or more inputs have a weight of zero, the remaining non - zero weights are adjusted so as to sum to 1 at all times.

[0198] The above example of L スコア shows a linear relationship, but it is possible for L スコア to be defined by a higher - order polynomial that utilizes more complex calculations and calibrations. Thus, the above linear relationship is provided as an example representing a relatively simple way to calculate L スコア .

[0199] Continuing to refer to FIG. 30, the "L" score calculation module 3005 is vehicle-dependent and is intended to indicate the capabilities of the vehicle based on its current state. Examples of inputs that can affect the "L" score can include the vehicle's computing power 3020, the vehicle's sensors 3030, the user experience 3040, the weather 3050, and the vehicle's customization 3060. This list does not cover all factors that can be used to calculate the "L" score, and not all of the listed factors need to be used in the "L" score calculation.

[0200] As described above, the sensors 3030 assist in the autonomous level of the autonomous vehicle. In this way, the sensors 3030 can greatly affect the "L" score. If a sensor or multiple sensors are damaged, the DALD system 3000 can disable the sensors or set a lower input weight for the affected / damaged sensors. Therefore, the indicated confidence level decreases, and the "L" score is likely to decrease. In addition to damaged sensors, the following are examples of reasons why the weighted score of sensor inputs can be reduced in the "L" score calculation: sensors with poor performance, sensors that function abnormally (e.g., sensors that start to operate abnormally due to gradual degradation), sensor drift, and the intentional disabling of sensors that can conserve computing power and battery power when not required for the current driving performance.

[0201] The weather 3050, which can include other environmental conditions, can also have an impact on the autonomous level of the vehicle. As an example, an autonomous vehicle can reduce its autonomous level when it detects a dangerous weather condition, such as snow, along a route for which it is not properly prepared. Such environmental conditions can negatively affect the sensing capabilities of the autonomous vehicle or can significantly reduce the tire traction, which can prompt a regression of the autonomous level.

[0202] Vehicle customization 3060 can also affect the vehicle's autonomy level. When a human adds elements to the vehicle after calibrating the sensors, some sensors may be blocked. In some cases, it may be necessary to disable the sensors when modifying the vehicle. In such situations, the sensors may need to be weighted less for temporary or permanent modifications. Examples of vehicle modifications can include, for example, a trailer / other object attached to the rear of the vehicle, an attached roof rack, or even additional payload (e.g., suitcases, furniture, etc.). It should be noted that any change to the vehicle that can affect the handling of the sensors or the vehicle can be included in vehicle customization 3060.

[0203] The driver / passenger of the vehicle may want to prioritize certain aspects of driving / route. This user experience 3040 can also affect the vehicle's autonomy level. As an example, the driver may want to prioritize travel time even when an autonomous vehicle may request frequent lane changes (when driving in the city), or the driver may want to prioritize a scenic location that will take longer. The driver may further prioritize routes that do not require a higher level of autonomy, such as highway driving (which can be achieved with a minimal set of sensors). In some situations, the level of autonomy may be completely irrelevant, for example, when the driver is simply enjoying driving the car or enjoying the scenery.

[0204] Another factor in the "L" score is the available computing power 3020. For example, if the vehicle's battery is not fully charged or if it is malfunctioning, there may not be enough power for the extra computing required to reach a higher level of automation in an autonomous vehicle. As another example, if a component related to the autonomous driving capabilities of the autonomous vehicle, such as a hard drive, is malfunctioning or has limited capacity to hold data, the autonomous vehicle should adapt its level of autonomy based on the computing power it has.

[0205] After receiving the above input, the DALD system 3000 may determine which functions to activate along the route. In so doing, the system 3000 provides advanced contextual attention to the autonomous vehicle before the journey. For example, if there is a sensor malfunctioning abnormally, the vehicle may disable the sensor and determine how the sensor was contributing to the current autonomous level and whether the degree algorithm was relying on the sensor information. Thanks to sensor redundancy, if the vehicle can function by disabling the sensor, the "L" score may remain the same. However, if the sensor is critical in the performance of the autonomous vehicle, such as a 360-degree LIDAR sensor used for localization at level 4, the autonomous vehicle should reduce its level of autonomy to a level where it can maximize the automated functions without that sensor. This may mean reducing the autonomous level to, for example, L3 or L2, depending on the vehicle design. In another example, it may also be necessary to reduce the autonomous level if a trailer is attached to the vehicle and any rear sensors are blocked. As yet another example, the autonomous level may be reduced if a roof rack carrying a snowboard interferes with the vehicle's GPS signal.

[0206] Continuing to refer to FIG. 30, the autonomy level indicator 3070 can display the current "L" score for better visualization, thereby enhancing the user's attention and the reliability of the autonomous vehicle. The indicator 3070 enables the user to see how the autonomy level changes after an event that can affect the vehicle's capabilities. As a result, if the user is more interested in safety and automation capabilities along the route, the user can recognize how changes to the vehicle (e.g., sensor damage, customization, etc.) affect the vehicle's autonomy level and can consider other alternatives such as not towing a trailer. As another example, it can even affect the level of confidence in the user's ability to handle situations along the route, or prompt the driver / owner to take the vehicle in for inspection when the vehicle performs an operation that is always or sometimes below capacity / expectations.

[0207] The DALD system 3000 also includes a safety check module 3080 that is responsible for determining which parameters of the autonomous vehicle are important in the route planning algorithm. Examples of such parameters can include the coefficient of friction in a particular area of the route that can change due to different weather conditions, the maximum acceleration of the autonomous vehicle that can change due to vehicle customization, and the weight of the autonomous vehicle that affects the maximum and minimum brakes. The ability to modify parameters specific to each route and route planning algorithm plays an important role in the safety of autonomous vehicles. The safety module relies on the accuracy of these parameters to estimate the best control parameters for the user.

[0208] In addition to the obvious safety benefits, an additional benefit of System 3000 is that by enabling a self-driving vehicle to self-recognize and dynamically adapt its functions, the vehicle's power consumption and the maintenance costs of the self-driving vehicle can be reduced in the long term. Therefore, user input can be important to System 3000. For example, depending on the user's desire to travel the fastest route or a scenic route, an L5 self-driving vehicle can choose to maintain L3 mode along a route (or part of a route) after checking the sensor status and the predicted weather conditions, thereby avoiding consuming expensive sensors and computing resources.

[0209] As self-driving vehicles become ubiquitous, they can become a common part of the family, replacing ordinary passenger cars. As they become more universal, they are expected to perform the functions of conventional human-driven vehicles, not only for daily commuting or school trips but also for more mundane purposes. This means that people will expect self-driving vehicles to be versatile, for example, facilitating activities such as camping trips, weekend trips to the beach or a lake, or tailgate parties at sports events. Therefore, self-driving vehicles are expected to be able to tow equipment temporarily. Examples of such equipment can include camping gear, bicycles, boats, jet skis, coolers, grills, etc. Therefore, self-driving vehicles can include the ability to connect trailers, hooks, platforms, extensions, etc.

[0210] However, such attachments to an autonomous vehicle can block sensors and can result in changes to the vehicle behavior model with respect to the vehicle dimensions. This is particularly true in the case of pre-existing parameters that are an essential part of maintaining a safe distance, which the vehicle will need to compensate for in the future when operating along a road. As an example, referring to FIG. 31, if an autonomous vehicle believes there is enough space to cut in front of another vehicle, but instead the autonomous vehicle itself is much longer than its control system realizes, this can prevent the following vehicle from having enough space to stop and, even worse, can cause the autonomous vehicle to hit the vehicle it is trying to pass.

[0211] As another example, similar considerations may be required when a vehicle owner begins to customize the vehicle, such as lowering the vehicle's ride height or incorporating oversize tires (which can protrude outside the wheel well), spoilers, or other add-ons. These customizations can change the modeling and calibration of the vehicle parameters.

[0212] In that way, it may be important to obtain the new vehicle dimensions to the extent that the vehicle dimensions are extended by the modification. This enables the autonomous vehicle to change the safety distance clearance model to determine how much guard band is needed to compensate for the extension. This distance is important in navigation, which enables the autonomous vehicle to avoid accidents and is applicable to systems such as adaptive cruise control when backing out of a parking spot and when performing similar autonomous operations.

[0213] For example, while there are models for driving safety such as a safe driving distance, the safety of an autonomous vehicle can be enhanced by the autonomous vehicle recognizing that the dimensions of the vehicle have changed. Further, the robot driver of an autonomous vehicle relies on sensors and precise calibration for proper execution. As part of the vehicle's sensor calibration, a coordinate system is used where, according to this, except for altitude, the reference points of the vehicle are very unlikely to move / change. An example shown in FIG. 32, namely, the Ackermann model includes the center point of the rear axle of the vehicle between two wheels. Any changes to this model can be considered and referenced with respect to such coordinates. As an example, if an expansion of the vehicle dimensions is the result of a hitch attached to the vehicle, the coordinates shift to account for the hitch point.

[0214] In addition to the confusion to the vehicle modeling system, customizations such as attaching a trailer hitch can disrupt both the vehicle's sensors and the vehicle's operability. These disruptions are likely to affect the level of autonomy of the vehicle. FIG. 33 shows an example of a vehicle 3300 having an attachment 3310 (e.g., in this example, a boat towed by the vehicle). As shown in this example, the customization creates an obstructed area 3320.

[0215] One possible solution to address the new dimensions of a vehicle is to equip the corresponding sensors on the trailer or hitch. However, this would increase the complexity of the system and can be time-consuming and expensive. For example, the user has to worry about the compatibility of the new sensor system with the existing vehicle system, it is expensive and time-consuming to complete the precise steps of calibration, there can be exposure to elements (e.g., when the extension is a boat, jet ski, canoe, etc., the sensor may get submerged in water), there can be poles or other hardware that extend beyond the trailer (e.g., a boat may be much larger than its trailer). Additionally, since the use of such a trailer (e.g., a boat) can be temporary (a weekend outing), this solution is impractical and less likely to be implemented / observed.

[0216] Another possible alternative is to implement an array of ultrasonic sensors capable of 3D modeling that can capture, with some approximation, the customized width and depth that block the sensors along the same coordinate system as the vehicle model.

[0217] As yet another example, as a simple and low-cost solution, there is a method of capturing and tracing the new exterior vehicle dimensions as a result of customization (e.g., attached trailer / hitch). The autonomous vehicle can then temporarily compensate as needed (while the trailer / hitch is attached).

[0218] Figure 34 shows an example of the use of a simple method for tracing the new dimensions of a vehicle incorporating dimensions added by an extension coupled to the vehicle. As a comparison, 3410 shows a 3D ultrasonic map of the vehicle and the extension, which can be sensed by an ultrasonic sensor that may or may not be attached to the vehicle. In some examples, the example of 3410 can be automated. In such examples, when the vehicle detects an occlusion or that a trailer is attached, an automated ultrasonic scan can be initiated to create a rendering of the 3D model. Another example is shown at 3430. In the example of 3430, the new dimensions of the vehicle are captured using LIDAR, for example, by the use of a LIDAR-based base station. 3420 shows an example where a user performs a manual walkthrough to facilitate tracing the new dimensions of the vehicle. After the walkthrough, a new model 3440 of the vehicle's dimensions is created. To perform the walkthrough, the vehicle owner can walk along the path of the vehicle and the extension with a given length (e.g., arm length) while carrying a sensor. In some examples, this sensor can be paired (e.g., communicatively coupled) with a smartphone. In other examples, the sensor can be paired with the vehicle. In various embodiments, as shown by 3420, instead of physically walking around the vehicle, the dimensions of the vehicle can be traced using a drone and a camera. The tracing results can then be delivered to an autonomous vehicle, and a polygon model representation 3440 can be approximated. This model can be incorporated into the driving algorithm of the autonomous vehicle.

[0219] The system for incorporating the above options may include one or more of the following elements: a vehicle having an integrated hitch with a sensor that aligns when the hitch is attached to or removed from an extension; an alarm that warns the driver that a "safety walkthrough" is required in response to the detection of a hitch attachment; a sensing element / device that creates a trace; an unobstructed sensor that performs a check / reference while the trace is being made; and a vehicle warning system that warns the driver of a change in its autonomy level as a result of the trace and the remaining functional sensors. In one embodiment, the sensing element / trace device may include a smartphone app that calculates the dimensions of a new autonomous vehicle based on one or more images captured by a smartphone camera. To scan the new dimensions, the user may simply walk around the vehicle, or a drone may be used. In another example, the scanning device may include an integrated removable vehicle camera that performs a similar function as the above. After scanning, if there are gaps in the trace, or if the result is not exactly a straight trace (or does not exactly stop at the origin), the trace can still be converted into a closed polygon / loop around the vehicle based on the capture points of the trace. The vehicle may consider the original dimensions to compensate for the effect of the "pivot" point on the curve, and the new model of the dimensions may include an offset that ensures that the model is outside the limits of the vehicle, which may serve as an additional safety buffer. In other embodiments, other methods for determining the new dimensions may be used, such as ultrasonic and LIDAR sensors, which may or may not be attached to the vehicle.

[0220] Figure 35 shows an example of a vehicle model occlusion compensation flow according to an embodiment of the present disclosure. The example of Figure 35 may also be regarded as a method for updating the vehicle dimensions of an autonomous vehicle.

[0221] The example of FIG. 35 includes an operation to determine whether the hitch switch is engaged. In some embodiments, the hitch may include an automatic sensor (e.g., a switch) that indicates whether the hitch is engaged. In various embodiments, the autonomous vehicle may further or alternatively include a manual switch that indicates that the hitch is engaged.

[0222] If the hitch switch is engaged, before the vehicle moves in the added dimension, the vehicle may perform a check to determine whether all necessary safety operations have been performed. If they have been performed, the flow ends. If they have not been performed, the vehicle may determine whether a safety walkthrough to capture the new vehicle dimension has been completed. If it has not been completed, the driver may be warned that a walkthrough is required, and the walkthrough may begin.

[0223] To perform the walkthrough, the vehicle first activates and / or pairs with a sensing device. This may be a sensing device or similar device integrated within or paired with a smartphone, or a separate device that connects directly to the vehicle. After the device is paired / activated, the owner performs a walkthrough around the vehicle.

[0224] Next, the sensing device transfers the data acquired during the walkthrough to the autonomous vehicle. The autonomous vehicle may then convert the data acquired by the sensing device into a polygon model. The autonomous vehicle may then use the new dimension in its autonomous vehicle algorithm, including, for example, a safe distance algorithm. Finally, the autonomous vehicle may perform a self-test to determine whether the new dimension affects the autonomous level at which the vehicle is operating. If the level has changed, this new level may be displayed (or otherwise communicated) to the driver (alternatively, an indication that the level has not changed may be displayed or otherwise communicated to the driver).

[0225] FIG. 36 and FIG. 37 are block diagrams of exemplary computer architectures that may be used by the embodiments disclosed herein. Other computer architecture designs known in the art for processors and computing systems may also be used. In general, a suitable computer architecture for the embodiments disclosed herein may include, but is not limited to, the configurations shown in FIGS. 36 and 37.

[0226] FIG. 36 is an exemplary diagram of a processor according to one embodiment. Processor 3600 is an example of a type of hardware device that may be used in connection with the above-described implementations. Processor 3600 can be any type of processor, such as a microprocessor, an embedded processor, a digital signal processor (DSP), a network processor, a multi-core processor, a single-core processor, or other device that executes code. Although only one processor 3600 is shown in FIG. 36, the processing elements may alternatively include two or more of the processors 3600 shown in FIG. 36. Processor 3600 can be a single-threaded core, or, in at least one embodiment, processor 3600 can be multi-threaded in that it can include two or more hardware thread contexts (or "logical processors") per core.

[0227] FIG. 36 also shows a memory 3602 coupled to the processor 3600 according to one embodiment. Memory 3602 can be any of a variety of memories known or available to those skilled in the art (including various layers of the memory hierarchy). Such memory elements can include, but are not limited to, random access memory (RAM), read only memory (ROM), logic blocks of a field programmable gate array (FPGA), erasable programmable read only memory (EPROM), and electrically erasable programmable ROM (EEPROM).

[0228] Processor 3600 may execute any type of instructions associated with the algorithms, processes, or operations detailed herein. Generally, processor 3600 may convert an element or an object (e.g., data) from one state or thing to another state or thing.

[0229] Code 3604, which may be one or more instructions executed by processor 3600, may be stored in memory 3602, or may be stored in software, hardware, firmware, or any suitable combination thereof, or in any other internal or external component, device, element, or object based on specific needs as required. In one example, processor 3600 may follow a program sequence of instructions indicated by code 3604. Each instruction enters front - end logic 3606 and is processed by one or more decoders 3608. The decoder may generate micro - operations such as fixed - width micro - operations in a predefined format as its output, or may generate other instructions, micro - instructions, or control signals that reflect the original code instruction. Front - end logic 3606 also includes register - naming logic 3610 and scheduling logic 3612, which generally allocate resources and queue the operations corresponding to the instructions for execution.

[0230] Processor 3600 may also include execution logic 3614 having a set of execution units 3616a, 3616b, 3616n, etc. Some embodiments may include several execution units dedicated to a particular function or a particular set of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. Execution logic 3614 executes the operations specified by the code instructions.

[0231] After the execution of the operation specified by the code instruction is completed, the backend logic 3618 may retire the instruction of the code 3604. In one embodiment, the processor 3600 permits out-of-order execution but requires in-order retirement of instructions. The retirement logic 3620 may take various known forms (e.g., reorder buffers, etc.). In this way, the processor 3600 is transformed during the execution of the code 3604 with respect to at least the decoder, hardware registers, and tables utilized by the register renaming logic 3610, and the outputs generated by any registers (not shown) modified by the execution logic 3614.

[0232] Although not shown in FIG. 36, the processing element may include other elements on the chip having the processor 3600. For example, the processing element may include memory control logic together with the processor 3600. The processing element may include I / O control logic and / or may include I / O control logic integrated with the memory control logic. The processing element may also include one or more caches. In some embodiments, non-volatile memory (e.g., flash memory or fuses) may also be included on the chip having the processor 3600.

[0233] FIG. 37 shows a computing system 3700 arranged in a point-to-point (PtP) configuration according to one embodiment. In particular, FIG. 37 shows a system in which processors, memories, and input / output devices are interconnected by several point-to-point interfaces. In general, one or more of the computing systems described herein may be configured in the same or similar manner as the computing system 3600.

[0234] Processors 3770 and 3780 may also each include integrated memory controller logic (MC) 3772 and 3782 to communicate with memory elements 3732 and 3734. In alternative embodiments, memory controller logic 3772 and 3782 may be separate logic separate from processors 3770 and 3780. Memory elements 3732 and / or 3734 may store various data used by processors 3770 and 3780 in realizing the operations and functions outlined herein.

[0235] Processors 3770 and 3780 can be any type of processor, such as those described in relation to other figures herein. Processors 3770 and 3780 can each exchange data via point-to-point (PtP) interface 3750 using point-to-point interface circuits 3778 and 3788. Processors 3770 and 3780 can each exchange data with chipset 3790 via individual point-to-point interfaces 3752 and 3754 using point-to-point interface circuits 3776, 3786, 3794, and 3798. Chipset 3790 can also exchange data with coprocessor 3738, such as a high-performance graphics circuit, a machine learning accelerator, or other coprocessor 3738, via interface 3739, which can be a PtP interface circuit. In alternative embodiments, any or all of the PtP links shown in FIG. 37 can be implemented as a multi-drop bus instead of a PtP link.

[0236] The chipset 3790 can communicate with the bus 3720 via the interface circuit 3796. The bus 3720 can have one or more devices communicating therewith, such as the bus bridge 3718 and the I / O device 3716. Via the bus 3710, the bus bridge 3718 can communicate with other devices such as the user interface 3712 (e.g., keyboard, mouse, touch screen, or other input device), the communication device 3726 (e.g., modem, network interface device, or other type of communication device that can communicate through the computer network 3760), the audio I / O device 3714, and / or the data storage device 3728. The data storage device 3728 can store the code 3730 that can be executed by the processors 3770 and / or 3780. In an alternative embodiment, any part of the bus architecture can implement one or more PtP links.

[0237] The computer system illustrated in FIG. 37 is a schematic diagram of one embodiment of a computing system that can be utilized to implement the various embodiments described herein. It will be understood that the various components of the system shown in FIG. 37 can be combined into a system-on-chip (SoC) architecture or any other suitable configuration that can implement the functions and features of the examples and implementations provided herein.

[0238] Some of the systems and solutions described and shown herein are described as including or being associated with a plurality of elements, but in each alternative implementation of the present disclosure, not all of the elements explicitly shown or described may be utilized. Further, one or more of the elements described herein may be located outside of the system, and in other instances, a particular element may be included within or as part of one or more of the other described elements, as well as other elements not described in the shown implementations. Further, a particular element may be combined with other components and used for alternative or additional purposes in addition to the purposes described herein.

[0239] Furthermore, the examples presented above are non-limiting examples provided for the purpose of merely illustrating certain principles and features, and it should be understood that they do not necessarily limit or restrict potential implementations of the concepts described herein. For example, various different implementations may be realized using various combinations of the features and components described herein, including combinations realized through various implementations of the components described herein. Other implementations, features, and details should be understood from the content of this specification.

[0240] The present disclosure has been described in terms of particular implementations and generally related methods, but modifications and permutations of these implementations and methods will be apparent to those skilled in the art. For example, the operations described herein may be performed in an order different from that described and still achieve desirable results. As an example, the processes illustrated in the accompanying figures do not necessarily require the particular order or sequential order shown to achieve the desired results. In certain implementations, multitasking and parallel processing may be advantageous. Further, other user interface layouts and functions may be supported. Other variations are within the scope of the following claims.

[0241] This specification includes details of numerous specific implementations, which should not be construed as limiting the scope of any invention or what can be claimed, but rather as describing features specific to particular embodiments of a particular invention. The specific features described herein in the context of separate multiple embodiments can also be implemented in combination in a single embodiment. Conversely, the various features described in the context of a single embodiment can also be implemented separately in multiple embodiments or in any suitable sub-combination. Furthermore, a feature may be described and even initially claimed as operating in a particular combination, but one or more features of the claimed combination can in some cases be deleted from the combination, and the claimed combination may be directed to a sub-combination or a variant of a sub-combination.

[0242] Similarly, although multiple operations are shown in the drawings in a particular order, it should not be understood that such operations need to be performed in the particular order shown, or sequentially, or that all of the operations shown need to be performed, in order to achieve a desired result. Multitasking and parallel processing may be advantageous in certain circumstances. Further, the separation of the various system components in the above embodiments should not be understood as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0243] One or more computing systems can be provided, including an in-vehicle computing system (e.g., implementing at least a part of an autonomous driving stack and used to enable the autonomous driving function of a vehicle), a roadside computing system (e.g., one separated from the vehicle, implemented in a dedicated roadside cabinet, on a traffic sign, on a traffic signal or a street lamp, etc.), one or more computing systems implementing a cloud-based or fog-based system supporting an autonomous driving environment, or a computing system remote from the autonomous driving environment. These computing systems can include logic implemented using one or a combination of one or more data processing devices (e.g., a central processing unit, a graphics processing unit, a tensor processing unit, an ASIC, an FPGA, etc.), an accelerator, hardware, other hardware circuits, firmware, and / or software to execute or implement one or a combination of the following examples (or a part thereof). For example, in various embodiments, the operations of the following exemplary methods can be executed using any suitable logic such as a computing system of a vehicle (e.g., 105) or its components (e.g., processor 202, accelerator 204, communication module 212, user display 288, memory 206, IX fabric 208, driving control 220, sensor 225, user interface 230, in-vehicle processing system 210, machine learning model 256, other components, or any sub-components thereof), a roadside computing device 140, a fog-based or cloud-based computing system 150, a drone 180, and an access point 145, a sensor (e.g., 165), memory 3602, processor core 3600, system 3700, any other suitable computing system or device, any sub-components thereof, or any other suitable logic. In various embodiments, one or more specific operations of the following exemplary methods can be executed by a specific component or system, while one or more other operations of the exemplary methods can be executed by another component or system.In other embodiments, the operations of the exemplary methods can each be performed by the same component or system.

[0244] Example 1 includes an apparatus comprising at least one interface that receives a signal for identifying a second vehicle proximate to a first vehicle, and a processing circuit, the processing circuit obtaining a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, predicting the operation of the second vehicle using the behavior model, and determining a route plan for the first vehicle based on the predicted operation of the second vehicle.

[0245] Example 2 includes the apparatus according to Example 1, wherein the processing circuit determines the reliability of the behavior model associated with the second vehicle before predicting the operation of the second vehicle using the behavior model.

[0246] Example 3 includes the apparatus according to Example 2, wherein determining the reliability of the behavior model includes verifying the format of the behavior model.

[0247] Example 4 includes the apparatus according to any one of Examples 1 to 3, wherein determining the reliability of the behavior model includes verifying the accuracy of the behavior model.

[0248] Example 5 includes the apparatus according to Example 4, wherein verifying the accuracy of the behavior model includes storing an input provided to at least one machine learning model and a corresponding output of the at least one machine learning model, providing the input to the behavior model, and comparing the output of the behavior model with the output of the at least one machine learning model.

[0249] Example 6 includes the apparatus according to Example 4, which includes determining the expected behavior of the second vehicle according to the behavior model based on the input corresponding to the observed state, observing the behavior of the second vehicle corresponding to the observed state, and comparing the observed behavior with the expected behavior.

[0250] Example 7 includes the apparatus according to any one of Examples 1 to 6, wherein the behavior model corresponds to at least one machine learning model used by the second vehicle to determine the autonomous driving behavior of the second vehicle.

[0251] Example 8 includes the apparatus according to any one of Examples 1 to 7, wherein the processing circuit communicates with the second vehicle to obtain the behavior model, and the communication with the second vehicle includes establishing a secure communication session between the first vehicle and the second vehicle, and receiving the behavior model via communication within the secure communication session.

[0252] Example 9 includes the apparatus according to Example 8, wherein establishing the secure communication session includes exchanging tokens between the first and second vehicles, and each token includes the respective identifier of the corresponding vehicle, the respective public key, and a shared secret value.

[0253] Example 10 includes the apparatus according to any one of Examples 1 to 9, wherein the signal includes a beacon for indicating the identity and position of the second vehicle.

[0254] Example 11 includes the apparatus according to any one of Examples 1 to 10, further comprising a transmitter for notifying other vehicles in the vicinity of the first vehicle to identify the first vehicle to the other vehicles.

[0255] Example 12 includes the apparatus according to any one of Examples 1 to 11, wherein the processing circuit starts communication of a second behavior model to the second vehicle in the replacement of the behavior model including the behavior model, and the second behavior model defines the driving behavior of the first vehicle.

[0256] Example 13 includes the apparatus according to any one of Examples 1 to 12, wherein the one or more processors determine whether the behavior model associated with the second vehicle is in the model database of the first vehicle, and the behavior model associated with the second vehicle is acquired based on the determination that the behavior model associated with the second vehicle is not yet in the model database.

[0257] Example 14 includes the apparatus according to any one of Examples 1 to 13, wherein the second vehicle is operable in a human driving mode, and the behavior model associated with the second vehicle models at least one characteristic of at least one human driver of the second vehicle during operation of the second vehicle in the human driving mode.

[0258] Example 15 includes the apparatus according to any one of Examples 1 to 14, wherein the behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models.

[0259] Example 16 includes the apparatus according to Example 15, wherein the one or more processors determine a specific scenario based at least in part on sensor data generated by the first vehicle, determine that a specific behavior model in the set of behavior models corresponds to the specific scenario, and predict the operation of the second vehicle using the specific behavior model based on the determination that the specific behavior model corresponds to the specific scenario.

[0260] Example 17 is a vehicle, including a plurality of sensors that generate sensor data, a control system that physically controls the movement of the vehicle, at least one interface that receives a signal for identifying a second vehicle proximate to the vehicle, obtaining a behavior model associated with the second vehicle, where the behavior model defines the driving behavior of the second vehicle, predicting the operation of the second vehicle using the behavior model, determining a route plan of the vehicle based on the predicted operation of the second vehicle and the sensor data, and communicating with the control system to move the vehicle according to the route plan, and a processing circuit for performing the above operations.

[0261] Example 18 includes the vehicle according to Example 17, where the processing circuit determines the reliability of the behavior model associated with the second vehicle before predicting the operation of the second vehicle using the behavior model.

[0262] Example 19 includes the vehicle according to Example 18, where determining the reliability of the behavior model includes verifying the format of the behavior model.

[0263] Example 20 includes the vehicle according to any one of Examples 17 to 19, where determining the reliability of the behavior model includes verifying the accuracy of the model.

[0264] Example 21 includes the vehicle according to Example 20, where verifying the accuracy of the behavior model includes storing the input provided to at least one machine learning model and the corresponding output of the at least one machine learning model, providing the input to the behavior model, and comparing the output of the behavior model with the output of the at least one machine learning model.

[0265] Example 22 includes a vehicle as described in Example 20, which includes verifying the accuracy of the above behavior model by providing an input corresponding to the observed state to the above behavior model, determining the expected behavior of the second vehicle from the above behavior model based on the above input, observing the behavior of the second vehicle corresponding to the observed state, and comparing the observed behavior with the expected behavior.

[0266] Example 23 includes a vehicle as described in any one of Examples 17 to 22, wherein the above behavior model corresponds to at least one machine learning model used by the second vehicle to determine the autonomous driving behavior of the second vehicle.

[0267] Example 24 includes a vehicle as described in any one of Examples 17 to 23, wherein the above processing circuit communicates with the second vehicle to obtain the above behavior model, and the communication with the second vehicle includes establishing a secure communication session between the vehicle and the second vehicle, and receiving the above behavior model via communication within the secure communication session.

[0268] Example 25 includes a vehicle as described in Example 24, wherein establishing the above secure communication session includes exchanging tokens between the first and second vehicles, and each token includes the respective identifier of the corresponding vehicle, the respective public key, and a shared secret value.

[0269] Example 26 includes a vehicle as described in any one of Examples 17 to 25, wherein the above signal includes a beacon for indicating the identity and position of the second vehicle.

[0270] Example 27 includes a vehicle as described in any one of Examples 17 to 26, further comprising a transmitter for notifying other vehicles in the vicinity of the first vehicle to identify the first vehicle to the other vehicles.

[0271] Example 28 includes a vehicle according to any one of Examples 17 to 27, in which the processing circuit causes the second vehicle to communicate with a second behavior model including the behavior model, and the second behavior model defines the driving behavior of the vehicle.

[0272] Example 29 includes a vehicle according to any one of Examples 17 to 28, in which the processing circuit determines whether the behavior model associated with the second vehicle is in the vehicle's model database, and the behavior model associated with the second vehicle is obtained based on a determination that the behavior model associated with the second vehicle is not yet in the model database.

[0273] Example 30 includes a vehicle according to any one of Examples 17 to 29, in which the second vehicle is operable in a human driving mode, and the behavior model associated with the second vehicle models the characteristics of at least one human driver in the second vehicle during operation of the second vehicle in the human driving mode.

[0274] Example 31 includes a vehicle according to any one of Examples 17 to 30, in which the behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models.

[0275] Example 32 includes a vehicle according to Example 31, in which the processing circuit determines a specific scenario based at least in part on sensor data generated by the vehicle, determines that a specific behavior model in the set of behavior models corresponds to the specific scenario, and predicts the operation of the second vehicle using the specific behavior model based on the determination that the specific behavior model corresponds to the specific scenario.

[0276] Embodiment 33 includes a system comprising means for receiving a signal for identifying a second vehicle close to a first vehicle, means for obtaining a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, means for predicting the behavior of the second vehicle using the behavior model, and means for determining a route plan for the first vehicle based on the predicted behavior of the second vehicle.

[0277] Embodiment 34 includes the system according to Embodiment 33, further comprising means for determining the reliability of the behavior model associated with the second vehicle before predicting the behavior of the second vehicle using the behavior model.

[0278] Embodiment 35 includes the system according to Embodiment 33, wherein determining the reliability of the behavior model includes verifying the accuracy of the model.

[0279] Embodiment 36 includes a computer-readable medium storing instructions that, when executed by a machine, cause the machine to receive a signal for identifying a second vehicle close to a first vehicle, obtain a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, predict the behavior of the second vehicle using the behavior model, and determine a route plan for the first vehicle based on the predicted behavior of the second vehicle.

[0280] Embodiment 37 includes a memory and a processing circuit coupled to the memory, and includes an apparatus for executing one or more of Embodiments 17 to 32.

[0281] Embodiment 38 includes a system comprising means for executing one or more of Embodiments 17 to 32.

[0282] Example 39 includes a product comprising one or more tangible computer-readable non-transitory storage media including computer-executable instructions that, when executed by at least one computer processor, enable the at least one computer processor to implement the operations described in Examples 17-32.

[0283] Example 40 includes a method comprising receiving an environmental model generated based on sensor data from a plurality of sensors coupled to an autonomous vehicle, determining, based on information within the environmental model, a change in one or more behaviors of a vehicle other than the autonomous vehicle, determining, based on information within the environmental model, a deviation between one or more behaviors of a vehicle other than the autonomous vehicle and the same one or more behaviors to be executed by the autonomous vehicle, determining, based on the determined change and deviation, one or more constraints on a behavior model of the autonomous vehicle, and applying the one or more constraints to the behavior model to control the operation of the autonomous vehicle.

[0284] Example 41 includes the method of Example 40, further comprising constructing a scenario based on the environmental model and geographical location information of the autonomous vehicle, and associating the constraints with the scenario in a social norm profile of the behavior model of the autonomous vehicle.

[0285] Example 42 includes the method of Example 41, wherein the scenario is based on one or more of the number of vehicles near the autonomous vehicle, the speed of each of one or more vehicles near the autonomous vehicle, time, and weather conditions.

[0286] Example 43 includes the method according to any one of Examples 40-42, wherein determining the change includes determining whether the observed behavior is within current parameters of the behavior model of the autonomous vehicle.

[0287] Example 44 includes the method described in Example 43, where the above change is based on the Euclidean distance from the observation results of surrounding vehicles to the current behavior model.

[0288] Example 45 includes the method according to any one of Examples 40 to 42, where determining the above deviation includes determining whether the above deviation in behavior is within the current parameters of the above behavior model of the above autonomous vehicle.

[0289] Example 46 includes the method described in Example 45, where the above deviation is based on a negative feedback violation that functions as the above limit of behavior.

[0290] Example 47 includes the method according to any one of Examples 40 to 46, where the above change and deviation are based on information in the above environmental model associated with dynamic obstacles.

[0291] Example 48 includes an apparatus comprising a memory and a processing circuit coupled to the memory, and executing one or more of Examples 40 to 47.

[0292] Example 49 includes a system comprising means for executing one or more of Examples 40 to 47.

[0293] Example 50 includes one or more tangible computer-readable non-transitory storage media comprising computer-executable instructions that, when executed by at least one computer processor, enable the at least one computer processor to implement the operations described in Examples 40 to 47.

[0294] Example 51 involves participating in a first consensus negotiation with a first plurality of vehicles, wherein at least some of the behavior models or their parameters of the first plurality of vehicles are exchanged in the first consensus negotiation. Participating in the first consensus negotiation includes receiving each of the exchanged behavior models and determining the validity of each of the behavior models within the first consensus negotiation. It also involves participating in a second consensus negotiation with a second plurality of vehicles, wherein at least some of the behavior models of the second plurality of vehicles are exchanged in the second consensus negotiation. Participating in the second consensus negotiation includes receiving each of the exchanged behavior models and determining the validity of each of the behavior models within the second consensus negotiation. The method further includes generating a consensus behavior model from the first and second consensus negotiations.

[0295] Example 52 includes the method according to Example 51, further comprising distributing the consensus behavior model to a third plurality of vehicles.

[0296] Example 53 includes the method according to Example 52, wherein the consensus behavior model is distributed in a third consensus negotiation.

[0297] Example 54 includes the method according to any one of Examples 51 to 53, wherein the first and second consensus negotiations are based on a Byzantine fault-tolerant consensus algorithm.

[0298] Example 55 includes the method according to any one of Examples 51 to 54, wherein the behavior model includes a neural network-based model.

[0299] Example 56 includes the method according to any one of Examples 51 to 55, wherein at least one of the above-described first or second plurality of vehicles includes a non-autonomous vehicle having a human driver.

[0300] Example 57 includes the method according to Example 56, further comprising determining a behavior model corresponding to the non-autonomous vehicle.

[0301] Example 58 further includes generating sensor data in one or more local sensors to observe behaviors of one or more non-autonomous vehicles, wherein the behavior model corresponding to the non-autonomous vehicle is based on the sensor data, and includes the method according to Example 57.

[0302] Example 59 includes the method according to Example 58, wherein the behavior model corresponding to the non-autonomous vehicle is further based on the consensus behavior model.

[0303] Example 60 includes the method according to any one of Examples 51 to 59, wherein the method is executed using a static computing node corresponding to a specific road segment, and the static computing node is positioned in proximity to the specific road segment.

[0304] Example 61 includes the method according to Example 60, wherein the consensus behavior model attempts to explain ideal driving behavior in the specific road segment.

[0305] Example 62 includes a system comprising means for executing the method according to any one of Examples 51 to 61.

[0306] Example 63 includes the system according to Example 62, wherein the means includes a computer-readable medium for storing instructions, and when the instructions are executed by a machine, the machine is caused to execute at least a part of the method according to any one of Examples 51 to 61.

[0307] Example 64 includes receiving sensor data from a plurality of sensors coupled to an autonomous vehicle, detecting irregular behavior performed by a specific vehicle other than the autonomous vehicle based on the sensor data, generating an identifier for the specific vehicle, and starting a dynamic behavior policy of the autonomous vehicle in response to detecting that the irregular behavior has been performed by the specific vehicle more times than a threshold number.

[0308] Example 65 includes the method according to Example 64, wherein the step of detecting the irregular behavior performed by the specific vehicle includes comparing the observed behavior performed by the specific vehicle with a safety model of the autonomous vehicle and determining, based on the comparison, that the observed behavior violates the safety model of the autonomous vehicle.

[0309] Example 66 includes the method according to Example 64, wherein the step of detecting the irregular behavior performed by the specific vehicle includes comparing the observed behavior performed by the specific vehicle with the observed behavior performed by other vehicles and determining, based on the comparison, that the observed behavior performed by the specific vehicle deviates from the observed behavior performed by the other vehicles.

[0310] Example 67 includes the method according to Example 64, wherein the step of detecting the irregular behavior performed by the specific vehicle includes comparing the observed behavior performed by the specific vehicle with the observed behavior performed by other vehicles and determining, based on the comparison, that the observed behavior performed by the other vehicles is performed in response to the observed behavior performed by the specific vehicle.

[0311] Example 68 includes the method according to any one of Examples 64 to 67, wherein the detection of the irregular behavior is based on audio and visual context information in the sensor data.

[0312] Example 69 includes the method according to any one of Examples 64 to 68, wherein the step of generating an identifier for the specific vehicle includes obtaining values of respective features of the specific vehicle and applying an encrypted hash to the combination of the values to obtain the identifier.

[0313] In Example 69, the values are obtained by extracting representative features from a deep learning model used by an autonomous vehicle to recognize other vehicles. The method according to Example 68 is included.

[0314] Example 70 includes the method according to any one of Examples 64 to 69, further comprising the step of tracking the frequency of detection of the irregular behavior by other vehicles.

[0315] Example 71 includes an apparatus comprising a memory and a processing circuit coupled to the memory, and executing one or more of the methods according to Examples 64 to 70.

[0316] Example 72 includes a system comprising means for executing one or more of the methods according to Examples 64 to 70.

[0317] Example 73 includes a product comprising one or more tangible computer-readable non-transitory storage media including computer-executable instructions that, when executed by at least one computer processor, enable the at least one computer processor to implement the operations of the methods according to any one or more of Examples 64 to 70.

[0318] Example 74 includes a step of receiving tracking data of irregular behavior from a plurality of autonomous vehicles, where the tracking data of the irregular behavior includes an entry containing a vehicle identifier, an associated irregular behavior observed as being executed by a vehicle associated with the vehicle identifier, and context data indicating a context in which the irregular behavior was detected by the autonomous vehicle; a step of identifying one or more orders of the irregular behavior executed by one or more vehicles; a step of identifying a context behavior pattern based on the identified order and the tracking data of the irregular behavior; and a step of modifying a behavior policy for one or more autonomous vehicles based on the identified context behavior pattern.

[0319] Example 75 includes the method according to Example 74, where the step of identifying a context behavior pattern includes generating a context graph including a first set of nodes indicating the identified order and a second set of nodes indicating the context data, and the ends of the context graph indicate the frequency of the association between the nodes; and using the context graph to identify the context behavior pattern.

[0320] Example 76 includes the method according to Example 74, where the step of modifying a behavior policy for one or more autonomous vehicles is based on detecting that one or more autonomous vehicles are in a specific context associated with the identified context behavior pattern.

[0321] Example 77 includes the method according to any one of Examples 74 to 76, where the context data includes one or more of trajectory information of the vehicle executing the irregular behavior, vehicle attributes of the vehicle executing the irregular behavior, driver attributes of the vehicle executing the irregular behavior, geographical location of the vehicle executing the irregular behavior, weather conditions around the vehicle executing the irregular behavior, and traffic information indicating traffic conditions around the vehicle executing the irregular behavior.

[0322] Example 78 includes the method according to any one of Examples 74 to 77, wherein one or more orders of irregular behavior are identified based on the longest common subsequence (LCS).

[0323] Example 79 includes an apparatus comprising a memory and a processing circuit coupled to the memory, and executing one or more of the methods described in Examples 74 to 78.

[0324] Example 80 includes a system comprising means for executing one or more of the methods described in Examples 74 to 78.

[0325] Example 81 includes a product comprising one or more tangible computer-readable non-transitory storage media including computer-executable instructions that, when executed by at least one computer processor, enable the at least one computer processor to implement one or more operations of the methods described in Examples 74 to 78.

[0326] Example 82 includes receiving, from a vehicle behavior model, a classification of a first change in the movement of a vehicle; receiving, from a regression model, a prediction of the likelihood that the first change in the movement of the vehicle occurs during a given time interval; comparing the classification from the vehicle behavior model with the prediction from the regression model; determining, based at least in part on the comparison, that the first change in the movement of the vehicle is a failure; and transmitting, based on the determination that the first change in the movement of the vehicle is a failure, a first control signal that affects the first change in the movement of the vehicle.

[0327] Example 83 includes receiving, in the vehicle behavior model, a first control event indicating the first change in the movement of the vehicle; and generating the classification of the first change in the movement based at least in part on the first control event and data from one or more sensors in the vehicle, the method according to Example 82.

[0328] Example 84 includes the method described in Example 82, further comprising receiving a first control event in the regression model, obtaining one or more variables indicating the current state, and generating the prediction based at least in part on the first control event and the one or more variables indicating the current state.

[0329] Example 85 includes the method described in Example 84, wherein the current state includes at least one environmental condition.

[0330] Example 86 includes the method described in any one of Examples 84 to 85, wherein the current state includes at least one vehicle state.

[0331] Example 87 includes the method described in any one of Examples 84 to 86, wherein at least one of the one or more variables is obtained from one or more remote sources.

[0332] Example 88 includes the method described in any one of Examples 83 to 87, wherein the first control event is associated with a brake actuator, a steering actuator, or a throttle actuator.

[0333] Example 89 includes the method described in any one of Examples 82 to 88, wherein the vehicle behavior model is a Hidden Markov Model (HMM) algorithm.

[0334] Example 90 includes the method described in any one of Examples 82 to 89, wherein the regression model is an Expectation-Maximization (EM) algorithm.

[0335] Example 91 includes the method described in any one of Examples 82 to 90, wherein the failure is one of a malicious attack on the vehicle's computing system or a defect in the vehicle's computing system.

[0336] Example 92 includes a memory and a processing circuit coupled to the memory, and includes an apparatus that executes one or more of the methods described in any one of Examples 82 to 91.

[0337] Example 93 includes a system comprising means for executing one or more of the methods described in Examples 82 to 91.

[0338] Example 94 includes at least one machine-readable medium containing instructions that, when executed, cause an apparatus to be realized or implement the method described in any one of Examples 82 to 93.

[0339] Example 95 includes a system comprising a memory, a processor coupled to the memory, a safety module, and a score module that determines an autonomous level score of the vehicle based at least in part on the normality of sensors of the vehicle.

[0340] Example 96 includes the system described in Example 95, further comprising an autonomous level indicator for displaying the autonomous level score.

[0341] Example 97 includes the system described in any one or more of Examples 95 to 96, wherein the at least one input includes data related to one or more sensors.

[0342] Example 98 includes the system described in any one or more of Examples 95 to 97, wherein the at least one input includes data related to weather conditions.

[0343] Example 99 includes the system described in any one or more of Examples 95 to 98, wherein the at least one input includes data related to the available computing power of the vehicle.

[0344] Example 100 includes the system described in any one or more of Examples 95 to 99, wherein the at least one input includes data related to the customization of the vehicle.

[0345] Example 101 includes the system described in any one or more of Examples 95 to 100, where at least one of the inputs includes data related to the user experience.

[0346] Example 102 includes a method comprising receiving a plurality of inputs related to a vehicle, weighting the plurality of inputs, combining the plurality of weighted inputs, and determining an autonomous driving level score of the vehicle using the combined and weighted inputs.

[0347] Example 103 includes the method described in Example 102, further comprising displaying the autonomous driving level score on an autonomous level indicator.

[0348] Example 104 includes the method described in any one or more of Examples 95 to 102, further comprising updating information regarding the characteristics of the driver.

[0349] Example 105 includes a system comprising means for executing any one or more of the methods described in Examples 102 to 104.

[0350] Example 106 includes the system described in Example 105, where the means includes at least one machine-readable medium containing instructions that, when executed, implement any one of the methods described in Examples 102 to 104.

[0351] Example 107 includes a method comprising determining whether the dimensions of a vehicle have been modified, obtaining new vehicle dimensions, generating a new vehicle model based on the new vehicle dimensions, and adjusting one or more algorithms of an autonomous driving vehicle stack based on the new vehicle model.

[0352] Example 108 includes the method described in Example 107, where the step of determining whether the dimensions of the vehicle have been modified includes using a sensor to determine that the hitch is engaged.

[0353] Example 109 includes the method described in any one or more of Examples 107 to 108, where the step of obtaining new vehicle dimensions includes performing an ultrasonic scan.

[0354] Example 110 includes the method described in any one or more of Examples 107 to 108, where the step of obtaining new vehicle dimensions includes scanning the vehicle during a walkthrough.

[0355] Example 111 includes the method described in Example 110, where the scan during the walkthrough includes using a smartphone.

[0356] Example 112 includes the method described in any one or more of Examples 107 to 111, further comprising the step of prompting the driver about the new vehicle dimensions when the vehicle dimensions have been changed.

[0357] Example 113 includes the method described in any one or more of Examples 107 to 112, further comprising the step of determining the autonomous level of the vehicle after the dimensions of the vehicle have been modified.

[0358] Example 114 includes the method described in any one or more of Examples 107 to 113, further comprising the step of using a sensor to verify the new vehicle dimensions.

[0359] Example 115 includes a system comprising means for executing any one or more of Examples 107 to 114.

[0360] Example 116 includes the system described in Example 115, where the means includes at least one machine-readable medium containing instructions, and when the instructions are executed, they implement any one or more of the methods described in any of Examples 107 to 114.

[0361] Thus, particular embodiments of the subject matter have been described. Other embodiments are within the scope of the following claims. In some cases, the multiple actions recited in the claims may be executed in different orders and still achieve desirable results. Further, the processes illustrated in the accompanying figures do not necessarily require the particular order or sequence shown to achieve desirable results.

Claims

1. At least one interface that receives a signal for identifying the second vehicle notified from the second vehicle close to the first vehicle; A processing circuit, Establishing a wireless communication session between the first vehicle and the second vehicle, and obtaining a behavior model associated with the second vehicle through the wireless communication session, wherein the behavior model defines the driving behavior of the second vehicle; obtaining; Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted operation of the second vehicle A processing circuit that performs the above; An apparatus comprising.

2. The apparatus according to claim 1, wherein the processing circuit determines the reliability of the behavior model associated with the second vehicle before predicting the operation of the second vehicle using the behavior model.

3. The apparatus according to claim 2, wherein the processing circuit determines the reliability of the behavior model associated with the second vehicle based on a further signal received from the second vehicle.

4. At least one interface that receives a signal for identifying the second vehicle close to the first vehicle; A processing circuit, Obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle; obtaining; Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted operation of the second vehicle A processing circuit that performs the above; Comprising, The apparatus, wherein the processing circuit determines the reliability of the behavior model associated with the second vehicle based on the signal before predicting the operation of the second vehicle using the behavior model.

5. The apparatus according to any one of claims 2 to 4, wherein determining the reliability of the behavior model includes verifying the format of the behavior model.

6. At least one interface that receives a signal for identifying the second vehicle close to the first vehicle; A processing circuit, Obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle; obtaining; Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted behavior of the second vehicle A processing circuit for performing Comprising Before the processing circuit predicts the behavior of the second vehicle using the behavior model, it determines the reliability of the behavior model associated with the second vehicle, The apparatus for determining the reliability of the behavior model includes verifying the format of the behavior model. **Claim 7** The apparatus according to any one of claims 2 to 6, wherein determining the reliability of the behavior model includes verifying the accuracy of the behavior model. **Claim 8** Verifying the accuracy of the behavior model includes Storing inputs provided to at least one machine learning model and corresponding outputs of the at least one machine learning model, Providing the inputs to the behavior model and comparing the output of the behavior model with the corresponding output of the at least one machine learning model The apparatus according to claim 7, comprising **Claim 9** At least one interface for receiving a signal for identifying a second vehicle proximate to the first vehicle, A processing circuit, Obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle, Predicting the behavior of the second vehicle using the behavior model, Determining a route plan for the first vehicle based on the predicted behavior of the second vehicle Comprising a processing circuit for performing, Verifying the accuracy of the behavior model includes Storing inputs provided to at least one machine learning model and corresponding outputs of the at least one machine learning model, Providing the inputs to the behavior model and comparing the output of the behavior model with the corresponding output of the at least one machine learning model The apparatus, comprising **Claim 10** Verifying the accuracy of the behavior model includes Determining the expected behavior of the second vehicle according to the behavior model based on inputs corresponding to the observed state, Observing the behavior of the second vehicle corresponding to the observed state, Comparing the observed behavior with the expected behavior The apparatus according to claim 7, comprising **Claim 11** The apparatus according to any one of claims 1 to 10, wherein the behavior model associated with the second vehicle corresponds to at least one machine learning model used by the second vehicle to determine an autonomous driving behavior of the second vehicle.

12. The apparatus according to any one of claims 1 to 11, wherein the processing circuit communicates with the second vehicle to obtain the behavior model, and the communication with the second vehicle includes establishing a secure communication session between the first vehicle and the second vehicle and receiving the behavior model via communication within the secure communication session.

13. The apparatus according to claim 12, wherein establishing the secure communication session includes exchanging tokens between the first vehicle and the second vehicle, and each token includes an identifier of the corresponding vehicle, a respective public key, and a shared secret value.

14. The apparatus according to any one of claims 1 to 13, wherein the signal includes a beacon for indicating an identity and a position of the second vehicle.

15. At least one interface that receives a signal for identifying a second vehicle proximate to a first vehicle, A processing circuit, Obtaining a behavior model associated with the second vehicle, the behavior model defining a driving behavior of the second vehicle, Predicting an operation of the second vehicle using the behavior model, Determining a route plan of the first vehicle based on the predicted operation of the second vehicle A processing circuit that performs Comprising, The apparatus, wherein the signal includes a beacon for indicating an identity and a position of the second vehicle.

16. The apparatus according to any one of claims 1 to 15, further comprising a transmitter that notifies other vehicles proximate to the first vehicle of a signal for identifying the first vehicle to the other vehicles.

17. The apparatus according to any one of claims 1 to 16, wherein the processing circuit initiates communication of a second behavior model to the second vehicle in an exchange of behavior models including the behavior model, and the second behavior model defines a driving behavior of the first vehicle.

18. At least one interface that receives a signal for identifying a second vehicle proximate to a first vehicle, A processing circuit, Obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle; Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted operation of the second vehicle; A processing circuit that performs the above; Comprising; In the exchange of the behavior model including the behavior model, the processing circuit, based on a second signal for identifying the second vehicle transmitted by the first vehicle to the second vehicle, when the second behavior model associated with the first vehicle by the second vehicle is trusted, starts communicating the second behavior model to the second vehicle, and the second behavior model defines the driving behavior of the first vehicle.

19. The processing circuit determines whether the behavior model associated with the second vehicle is in the behavior model database of the first vehicle, and the behavior model associated with the second vehicle is obtained based on the determination that the behavior model associated with the second vehicle is not yet in the behavior model database. The apparatus according to any one of claims 1 to 18.

20. At least one interface that receives a signal for identifying a second vehicle close to the first vehicle; A processing circuit, Obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle; Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted operation of the second vehicle; A processing circuit that performs the above; Comprising; The processing circuit determines whether the behavior model associated with the second vehicle is in the behavior model database of the first vehicle, and the behavior model associated with the second vehicle is obtained based on the determination that the behavior model associated with the second vehicle is not yet in the behavior model database. An apparatus.

21. The second vehicle is operable in a human driving mode, and the behavior model associated with the second vehicle models at least one human driver characteristic of the second vehicle during operation of the second vehicle in the human driving mode. The apparatus according to any one of claims 1 to 20.

22. The behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models. The apparatus according to any one of claims 1 to 21.

23. At least one interface that receives a signal for identifying a second vehicle proximate to a first vehicle, A processing circuit, Establishing a wireless communication session between the first vehicle and the second vehicle, and obtaining, through the wireless communication session, a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle. Obtaining, Predicting the operation of the second vehicle using the behavior model; Determining a route plan for the first vehicle based on the predicted operation of the second vehicle A processing circuit that performs Comprising The behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models. An apparatus.

24. The processing circuit, Determining a specific scenario based at least in part on sensor data generated by the first vehicle, Determining that a specific behavior model within the set of behavior models corresponds to the specific scenario, Predicting the operation of the second vehicle using the specific behavior model based on the determination that the specific behavior model corresponds to the specific scenario. The apparatus according to claim 22 or 23.

25. A first vehicle, A plurality of sensors that generate sensor data, A control system that physically controls the movement of the first vehicle, The apparatus according to any one of claims 1 to 24 Comprising a first vehicle.

26. A vehicle, A plurality of sensors that generate sensor data, A control system that physically controls the movement of the vehicle, At least one interface that receives a signal for identifying the second vehicle notified from a second vehicle proximate to the vehicle A processing circuit, establishing a wireless communication session between the vehicle and the second vehicle, and obtaining a behavior model associated with the second vehicle through the wireless communication session, wherein the behavior model defines the driving behavior of the second vehicle; obtaining; predicting the behavior of the second vehicle using the behavior model; determining a route plan for the vehicle based on the predicted behavior of the second vehicle and the sensor data; communicating with a control system to move the vehicle according to the route plan A processing circuit that performs A vehicle comprising

27. A vehicle, a plurality of sensors that generate sensor data; a control system that physically controls the movement of the vehicle; at least one interface that receives a signal for identifying a second vehicle proximate to the vehicle, the signal including a beacon for indicating the identity and location of the second vehicle; at least one interface; a processing circuit, obtaining a behavior model associated with the second vehicle, wherein the behavior model defines the driving behavior of the second vehicle; obtaining; predicting the behavior of the second vehicle using the behavior model; determining a route plan for the vehicle based on the predicted behavior of the second vehicle and the sensor data; communicating with a control system to move the vehicle according to the route plan A processing circuit that performs A vehicle comprising

28. The vehicle according to claim 26 or 27, wherein the processing circuit determines the reliability of the behavior model associated with the second vehicle before predicting the behavior of the second vehicle using the behavior model.

29. The vehicle according to claim 28, wherein determining the reliability of the behavior model includes verifying the accuracy of the behavior model.

30. The vehicle according to any one of claims 26 to 29, wherein the behavior model corresponds to at least one machine learning model used by the second vehicle to determine autonomous driving behavior of the second vehicle.

31. The vehicle according to any one of claims 26 to 30, wherein the behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models.

32. A vehicle, a plurality of sensors that generate sensor data, a control system that physically controls the movement of the vehicle, at least one interface that receives a signal for identifying a second vehicle proximate to the vehicle, a processing circuit, establishing a wireless communication session between the vehicle and the second vehicle, and obtaining, through the wireless communication session, a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, obtaining, using the behavior model to predict the behavior of the second vehicle, determining a route plan for the vehicle based on the predicted behavior of the second vehicle and the sensor data, communicating with the control system to move the vehicle according to the route plan and a processing circuit that performs and comprising The vehicle, wherein the behavior model associated with the second vehicle includes one of a set of behavior models of the second vehicle, and the set of behavior models includes a plurality of scenario-specific behavior models.

33. means for receiving a signal for identifying the second vehicle notified from the second vehicle proximate to the first vehicle, means for establishing a wireless communication session between the first vehicle and the second vehicle, and obtaining, through the wireless communication session, a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, obtaining means, means for predicting the behavior of the second vehicle using the behavior model, means for determining a route plan for the first vehicle based on the predicted behavior of the second vehicle and a system comprising.

34. means for receiving a signal for identifying a second vehicle proximate to the first vehicle, the signal including a beacon for indicating the identity and position of the second vehicle, receiving means, means for obtaining a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, obtaining means, means for predicting the operation of the second vehicle using the behavior model; means for determining a route plan for the first vehicle based on the predicted operation of the second vehicle A system comprising:

35. The system according to claim 33 or 34, further comprising means for determining the reliability of the behavior model associated with the second vehicle before predicting the operation of the second vehicle using the behavior model.

36. The system according to claim 35, wherein determining the reliability of the behavior model includes verifying the accuracy of the behavior model.

37. In a machine, a procedure for receiving a signal for identifying the second vehicle notified from the second vehicle close to the first vehicle; a procedure for establishing a wireless communication session between the first vehicle and the second vehicle and acquiring, through the wireless communication session, a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, the procedure for acquiring; a procedure for predicting the operation of the second vehicle using the behavior model; a procedure for determining a route plan for the first vehicle based on the predicted operation of the second vehicle A program for causing the execution.

38. In a machine, a procedure for receiving a signal for identifying a second vehicle close to the first vehicle, the signal including a beacon for indicating the identity and position of the second vehicle, the procedure for receiving; a procedure for acquiring a behavior model associated with the second vehicle, the behavior model defining the driving behavior of the second vehicle, the procedure for acquiring; a procedure for predicting the operation of the second vehicle using the behavior model; a procedure for determining a route plan for the first vehicle based on the predicted operation of the second vehicle A program for causing the execution.

39. A computer-readable medium storing the program according to claim 37 or 38.

Images