Patent Description:
Vehicle driver score algorithms may utilize data produced by driver behavior and events generated by the vehicle to determine a driver score. So called "smart" vehicles, which may include artificial intelligence and/or advanced driving assistance (ADAS) systems, may compute driver scores and use the computed scores for individual vehicles and fleets of vehicles (e.g. monitored by a Fleet Management Systems (FMS)) to provide insights into potential improvements and possible interventions to improve driving quality of the drivers. Conventional driver scoring techniques may utilize data produced by driver behavior and events generated by the vehicle. However, current driver scoring techniques have various drawbacks, including driver scoring being solely event/alert based. <CIT> presents a method of enhancing positioning of a moving vehicle based on visual identification of visual objects, comprising obtaining from a location sensor a global positioning and a movement vector of a moving vehicle, capturing one or more images using one or more imaging devices mounted on the moving vehicle, analyzing the images to identify one or more visual objects having a known geographical position, analyzing the images to calculate a relative positioning of the moving vehicle with respect to the identified visual objects, calculating an enhanced positioning of the moving vehicle, and applying the enhanced positioning to a navigation system of the moving vehicle.

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles and to enable a person skilled in the pertinent art to make and use the techniques discussed herein.

In the following description, reference is made to the following drawings, in which:.

The present invention will be described with reference to the accompanying drawings. The drawing in which an element first appears is typically indicated by the leftmost digit(s) in the corresponding reference number.

The following detailed description refers to the accompanying drawings that show, by way of illustration, exemplary details in which the invention may be practiced. In the following description, numerous specific details are set forth in order to provide a thorough understanding of the present invention. However, it will be apparent to those skilled in the art that the various designs, including structures, systems, and methods, may be practiced without these specific details. The description and representation herein are the common means used by those experienced or skilled in the art to most effectively convey the substance of their work to others skilled in the art. In other instances, well-known methods, procedures, components, and circuitry have not been described in detail to avoid unnecessarily obscuring the invention.

Conventional driver scoring techniques are event/alert-based and may utilize data produced by driver behavior and events/alerts generated by the vehicle. However, these conventional techniques do not consider data reflecting vehicle movements between the generation of events/alerts, such as data from one or more sensors, in driver score computations.

To address the shortcomings of conventional systems, the invention describes driver scoring techniques that consider dynamic movements of the vehicle and the associated data leading up to an event/alert and/or following an event/alert. In contrast to the conventional approaches described above, landmark detection and positional mapping are used to identify driving deviations from a desired (e.g. optimum) driving path, such as an optimum path for an autonomous vehicle, to provide an increased detail and advanced driving characterization to improve upon conventional scoring techniques.

The path deviation processing may also supplement conventional event/alert-based driver scoring techniques. Events may include harsh movements (such as acceleration, breaking and curving). Such harsh movements may also be referred to as harsh driving events, and may include: Harsh Acceleration (HA), Harsh Velocity (HV), Harsh Breaking (HB), Harsh Curving (HC) / directional-change, or other harsh, sudden, or drastic vehicle maneuvers. Events may also be generated from Driver Monitoring Systems (DMS) that detect driver behavioral events, such as distracted-driver events, impaired-driver events, phone usage, smoking, and drowsiness. Additional events may include Collision Avoidance System (CAS) events, such as Forward Collision Warnings (FCW), Pedestrian Collision Warnings (PCW), Headway Monitoring Warnings (HWM) and other CAS alerts/events. The types of events are not limited hereto and may include any events that would be understood by one of ordinary skill in the art.

The vehicle or fleet of vehicles may implement a Safety Driving Model (SDM). The SDM functions to provide a mathematical framework that aims to ensure safety assurance of autonomous vehicles (AVs) and/or any suitable type of vehicle that implements at least some form of an autonomously-executed action or control without human assistance (fully-autonomous control functions, semi-autonomous control functions, etc.). Thus, the SDM is a comprehensive framework that was developed to ensure both longitudinal and lateral safety of vehicles (such as AVs) in various types of scenarios. The SDM (also referred to as a "driving policy model" or simply as a "driving model"), may be implemented as part of a fully or semi-autonomous vehicle control system, such as an advanced driving assistance (ADAS) system and/or a driving assistance and automated driving system.

A SDM may thus be represented as any suitable number of SDM parameters, any suitable subset of which being related as part of a mathematical model formalizing an interpretation of applicable laws, standards, policies, etc., which are applicable to self-driving (such as ground) vehicles and/or other suitable types of vehicles that may implement fully autonomous or semi-autonomous functions and which may utilize tools such as the aforementioned adaptive cruise control, automated braking or steering, etc. For instance, a SDM may be designed to achieve three goals: first, the interpretation of the law should be sound in the sense that it complies with how humans interpret the law; second, the interpretation should lead to a useful driving policy, meaning it will lead to an agile driving policy rather than an overly-defensive driving which inevitably would confuse other human drivers and will block traffic, and in turn limit the scalability of system deployment; and third, the interpretation should be efficiently verifiable in the sense that it can be rigorously proven that the self-driving (autonomous) vehicle correctly implements the interpretation of the law. An implementation in a host vehicle of a SDM, illustratively, may be or include an implementation of a mathematical model for safety assurance that enables identification and performance of proper responses to dangerous situations such that self-perpetrated accidents can be avoided.

A SDM may implement logic that is applied to the SDM parameters to apply driving behavior rules such as the following five rules, for instance:.

It is to be noted that these rules are not limiting and not exclusive, and can be amended in various designs as desired. The rules rather represent a social driving contract that might be different depending on the region, and may also develop over time. While these five rules are currently applicable in most of the countries, they might not be complete and may be amended.

<FIG> shows a vehicle <NUM> including a safety system <NUM> (see also <FIG>) in accordance with the present invention. The vehicle <NUM> and the safety system <NUM> are exemplary in nature, and may thus be simplified for explanatory purposes. Locations of elements and relational distances (as discussed above, the Figures are not to scale) and are provided as non-limiting instances. The safety system <NUM> may include various components depending on the requirements of a particular implementation and/or application.

As shown in <FIG> and <FIG>, the safety system <NUM> may include one or more processors <NUM>, one or more image acquisition devices <NUM> such as one or more cameras, one or more position sensors <NUM> such as a Global Navigation Satellite System (GNSS), a Global Positioning System (GPS), one or more memories <NUM>, one or more map databases <NUM>, one or more user interfaces <NUM> (such as a display, a touch screen, a microphone, a loudspeaker, one or more buttons and/or switches, and the like), and one or more wireless transceivers <NUM>, <NUM>, <NUM>.

The wireless transceivers <NUM>, <NUM>, <NUM> may be configured to operate in accordance with any suitable number and/or type of desired radio communication protocols or standards. A wireless transceiver (a first wireless transceiver <NUM>) may be configured in accordance with a Short Range mobile radio communication standard such as Bluetooth, Zigbee, and the like. A wireless transceiver (a second wireless transceiver <NUM>) may be configured in accordance with a Medium or Wide Range mobile radio communication standard such as a <NUM> (Universal Mobile Telecommunications System - UMTS), a <NUM> (Long Term Evolution - LTE), or a <NUM> mobile radio communication standard in accordance with corresponding 3GPP (3rd Generation Partnership Project) standards.

A wireless transceiver (a third wireless transceiver <NUM>) may be configured in accordance with a Wireless Local Area Network communication protocol or standard such as in accordance with IEEE <NUM> Working Group Standards, the most recent version at the time of this writing being IEEE Std <NUM>™ -<NUM>, published February <NUM>, <NUM> (such as <NUM>, <NUM>. 11a, <NUM>. 11b, <NUM>, <NUM>. 11n, <NUM>. 11p, <NUM>-<NUM>, <NUM>. 11ac, <NUM>. 11ad, <NUM> ah, <NUM>. 11ax, <NUM> ay, and the like). The one or more wireless transceivers <NUM>, <NUM>, <NUM> may be configured to transmit signals via an antenna system (not shown) using an air interface. One or more of the transceivers <NUM>, <NUM>, <NUM> may be configured to implement one or more vehicle to everything (V2X) communication protocols, which may include vehicle to vehicle (V2V), vehicle to infrastructure (V2I), vehicle to network (V2N), vehicle to pedestrian (V2P), vehicle to device (V2D), vehicle to grid (V2G), and any other suitable communication protocols.

The one or more processors <NUM> may implement any suitable type of processing circuitry and architecture, and may be configured as a controller implemented by the vehicle <NUM> to perform various vehicle control functions. The one or more processors <NUM> may be configured to function as a controller for the vehicle <NUM> to analyze sensor data and received communications, to calculate specific actions for the vehicle <NUM> to execute, and to cause the corresponding action to be executed, which may be in accordance with an AV or ADAS system, for instance.

The one or more processors <NUM> may include one or more application processors 214A, 214B, an image processor <NUM>, a communication processor <NUM>, and additionally or alternatively may include any other suitable processing device not shown in the Figures. Similarly, image acquisition devices <NUM> may include any suitable number of image acquisition devices and components depending on the requirements of a particular application. Image acquisition devices <NUM> may include one or more image capture devices (such as cameras, charge coupling devices (CCDs), or any other type of image sensor). The safety system <NUM> may also include a data interface communicatively connecting the one or more processors <NUM> to the one or more image acquisition devices <NUM>. A first data interface may include any wired and/or wireless first link <NUM>, or first links <NUM> for transmitting image data acquired by the one or more image acquisition devices <NUM> to the one or more processors <NUM>, such as to the image processor <NUM>.

The wireless transceivers <NUM>, <NUM>, <NUM> may be coupled to the one or more processors <NUM>, such as to the communication processor <NUM> via a second data interface. The second data interface may include any wired and/or wireless second link <NUM> or second links <NUM> for transmitting radio transmitted data acquired by wireless transceivers <NUM>, <NUM>, <NUM> to the one or more processors <NUM>, such as to the communication processor <NUM>. Such transmissions may also include communications (one-way or two-way) between the vehicle <NUM> and one or more other (target) vehicles in an environment of the vehicle <NUM> (such as to facilitate coordination of navigation of the vehicle <NUM> in view of or together with other (target) vehicles in the environment of the vehicle <NUM>), or even a broadcast transmission to unspecified recipients in a vicinity of the transmitting vehicle <NUM>. These communications may include messages and/or control messages that are transmitted between the vehicles while traveling together.

The memories <NUM> as well as the one or more user interfaces <NUM> may be coupled to each of the one or more processors <NUM>, via a third data interface. The third data interface may include any wired and/or wireless third link <NUM> or third links <NUM>. Furthermore, the position sensor <NUM> may be coupled to each of the one or more processors <NUM>, via the third data interface.

Each processor 214A, 214B, <NUM>, <NUM> of the one or more processors <NUM> may be implemented as any suitable number and/or type of hardware-based processing devices (processing circuitry), and may collectively, i.e. with the one or more processors <NUM>, form one or more type of controllers as discussed herein. The architecture shown in <FIG> is provided for ease of explanation, and the vehicle <NUM> may include any suitable number of the one or more processors <NUM>, each of which may be similarly configured to utilize data received via the various interfaces and perform a specific task.

The one or more processors <NUM> may form a driver scoring controller that is configured to determine one or more driver scores and/or characterizations of a vehicle's movements or behaviors as discussed further herein, such as the determination of a driver score based on determined deviations from an optimum path, one or more alerts/events, traffic data, sensor data, map data, map metadata, map markers, and/or other data as would be understood by one of ordinary skill in the art. Landmark detection and positional mapping to identify the deviations. These determinations provide an increased detail and advanced driving characterization to improve upon conventional scoring techniques. The functions performed by the driver scoring controller may be implements in a single processor <NUM> or distributed across multiple of the processors <NUM>. Additionally or alternatively, these determinations may be used to characterize and improve the operation of the processors <NUM> or other driving control systems, including evaluating the ADAS, the operation of the controller <NUM> and/or controller <NUM>, and/or other driving management systems that calculate specific actions for the vehicle <NUM> to execute and to cause the corresponding action to be executed. This advantageously provides a system that is configured to improve the determination of an optimum driving path for the vehicle <NUM>.

The driver scoring controller may receive data from respectively coupled components as shown in <FIG> via respective interfaces (<NUM>, <NUM>, <NUM>, <NUM>, etc.), with the wireless transceivers <NUM>, <NUM>, and/or <NUM> providing data to the respective controller via the second links <NUM>, which function as communication interfaces between the respective wireless transceivers <NUM>, <NUM>, and/or <NUM> and each respective controller.

The application processors 214A, 214B may individually represent respective controllers that work in conjunction with the one or more processors <NUM> to perform specific controller-related tasks. For instance, the application processor 214A may be implemented as a driver scoring controller, whereas the application processor 214B may be implemented as a different type of controller that is configured to perform other types of tasks as discussed further herein. The one or more processors <NUM> may receive data from respectively coupled components as shown in <FIG> via the various interfaces <NUM>, <NUM>, <NUM>, <NUM>, etc., and the communication processor <NUM> may provide communication data received from other vehicles (or to be transmitted to other vehicles) to each controller via the respectively coupled links 240A, 240B, which function as communication interfaces between the respective application processors 214A, 214B and the communication processors <NUM>.

The one or more processors <NUM> may additionally be implemented to communicate with any other suitable components of the vehicle <NUM> to determine a state of the vehicle while driving or at any other suitable time. For instance, the vehicle <NUM> may include one or more vehicle computers, sensors, ECUs, interfaces, etc., which may collectively be referred to as vehicle components <NUM> as shown in <FIG>. The one or more processors <NUM> are configured to communicate with the vehicle components <NUM> via an additional data interface <NUM>, which may represent any suitable type of links and operate in accordance with any suitable communication protocol (such as CAN bus communications). Using the data received via the data interface <NUM>, the one or more processors <NUM> may determine any suitable type of vehicle status information (vehicle data) such as the current drive gear, current engine speed, acceleration capabilities of the vehicle <NUM>, etc..

In any event, the one or more processors may include any suitable number of other processors 214A, 214B, <NUM>, <NUM>, each of which may comprise a sub-processor and/or include a microprocessor, pre-processors (such as an image pre-processor), graphics processors, a central processing unit (CPU), support circuits, digital signal processors, integrated circuits, memory, or any other types of devices suitable for running applications and for data processing (image processing, audio processing, etc.) and analysis and/or to enable vehicle control to be functionally realized. Each processor 214A, 214B, <NUM>, <NUM> may include any suitable type of single or multi-core processor, mobile device microcontroller, central processing unit, etc. These processor types may each include multiple processing units with local memory and instruction sets. Such processors may include video inputs for receiving image data from multiple image sensors, and may also include video out capabilities.

Any of the processors 214A, 214B, <NUM>, <NUM> disclosed herein may be configured to perform certain functions in accordance with program instructions, which may be stored in a memory of the one or more memories <NUM>. In other words, a memory of the one or more memories <NUM> may store software that, when executed by a processor (by the one or more processors <NUM>, one or more of the processors 214A, 214B, <NUM>, <NUM>, etc.), controls the operation of the safety system <NUM>. A memory of the one or more memories <NUM> may store one or more databases and image processing software, as well as a trained system, such as a neural network, or a deep neural network. The one or more memories <NUM> may include any number of random access memories, read only memories, flash memories, disk drives, optical storage, tape storage, removable storage, or any other suitable types of storage.

The safety system <NUM> may further include components such as a speed sensor <NUM> (such as a speedometer) for measuring a speed of the vehicle <NUM>. The safety system may also include one or more accelerometers (either single axis or multiaxis) (not shown) for measuring accelerations of the vehicle <NUM> along one or more axes. The safety system <NUM> may further include additional sensors or different sensor types such as an ultrasonic sensor, a thermal sensor, one or more radar sensors <NUM>, one or more LIDAR sensors <NUM> (which may be integrated in the head lamps of the vehicle <NUM>), digital compasses, and the like. The radar sensors <NUM> and/or the LIDAR sensors <NUM> may be configured to provide pre-processed sensor data, such as radar target lists or LIDAR target lists. The third data interface (one or more links <NUM>) may couple the speed sensor <NUM>, the one or more radar sensors <NUM>, and the one or more LIDAR sensors <NUM> to at least one of the one or more processors <NUM>.

The one or more memories <NUM> may store data in a database or in any different format, which may indicate a location of known landmarks. The one or more processors <NUM> may process sensory information (such as images, radar signals, depth information from LIDAR or stereo processing of two or more images) of the environment of the vehicle <NUM> together with position information, such as a GPS coordinate, a vehicle's ego-motion, etc., to determine a current location and/or orientation of the vehicle <NUM> relative to the known landmarks and refine the determination of the vehicle's location. Certain designs of this technology may be included in a localization technology such as a mapping and routing model.

The map database <NUM> may include any suitable type of database storing (digital) map data for the vehicle <NUM>, for the safety system <NUM>. The map database <NUM> may include data relating to the position, in a reference coordinate system, of various items, including roads, water features, geographic features, businesses, points of interest, restaurants, gas stations, etc., as well as parameters of such items, such as road width, grade, slope, elevation, or the like. The map database <NUM> may store not only the locations of such items, but also descriptors relating to those items, including names associated with any of the stored features. A processor of the one or more processors <NUM> may access information from the map database <NUM> using a wired or wireless data connection, and/or may download information from an external map database <NUM> (<FIG>) over a wired or wireless data connection (such as over a cellular network and/or the Internet, etc.). The map database <NUM> may also include stored representations of various recognized landmarks that may be provided to determine or update a known position of the vehicle <NUM> with respect to a target trajectory. The landmark representations may include data fields such as landmark type, landmark location, among other potential identifiers. Landmarks may include road features such as lane markings, road edge markings, crosswalk markings, road arrow markings, stop line markings, or other road markers as would be understood by one of ordinary skill in the art. The road features may additionally or alternatively include traffic signs, traffic lights, or other traffic control elements, and/or utility or other poles (e.g. road light poles) or structures as would be understood by one of ordinary skill in the art.

In some cases, the map database <NUM> may store a sparse data model including polynomial representations of certain road features (such as road markings) or target trajectories for the vehicle <NUM>. The map database <NUM> can also include non-semantic features including point clouds of certain objects or features in the environment, and feature point and descriptors. The map database <NUM> may also include road/infrastructure condition and/or quality data, such as identified or potential hazardous instances (e.g. potholes; impaired, stopped, or crashed vehicles; debris in the roadway; construction events; weather impairments (flooding, mudslide, washed-out road), or other obstructions or hazards as would be understood by one of ordinary skill in the art. The map database <NUM> may be dynamically updated (e.g. by the database provider, vehicle manufacture, or the like) to include changes to the map data. Additionally or alternatively, the map database <NUM> (and/or map database <NUM>) may be dynamically updated in response to data driver submissions of new map data and/or driver submitted revisions to existing map data. As discussed in more detail below with reference to <FIG>, the map database <NUM> may additionally or alternatively be dynamically updated based on data provided from one or more vehicles <NUM>, where updated map data may then be provided to the vehicle(s) <NUM>.

Furthermore, the safety system <NUM> may implement the aforementioned SDM as part of any suitable type of control system, which may form part of an advanced driving assistance system (ADAS) or a driving assistance and automated driving system. The safety system <NUM> may include a computer implementation of a formal model such as the SDM. As described above, the vehicle <NUM> may include the safety system <NUM> as also described with reference to <FIG>. The vehicle <NUM> may include the one or more processors <NUM>, which may be integrated with or separate from an engine control unit (ECU) of the vehicle <NUM>. The safety system <NUM> may generate data to control or assist to control the ECU and/or other components of the vehicle <NUM> to directly or indirectly control the driving of the vehicle <NUM>.

A driver scoring controller <NUM> of a vehicle is provided. With reference to <FIG>, the controller <NUM> may include processing circuitry <NUM>. The controller <NUM> may optionally include a communication interface <NUM> and/or memory <NUM>. The controller <NUM> may be implemented as one or more processor <NUM> of the vehicle <NUM>.

The controller <NUM> (e.g. via communication interface <NUM>) is configured to receive map data from map database <NUM> (<FIG>) and/or from one or more external sources outside the vehicle using one or more communication protocols (e.g. <NUM>, vehicle-to-everything (V2X) communication protocol), such as map data from controller <NUM> (<FIG>). The controller <NUM> may receive data from one or more sensors, such as image sensors <NUM>, data from one or more mobile device sensors, and/or other sensor(s).

The memory <NUM> may store map data, road condition data, event data, driver score data, sensor data, and/or other data as would be understood by one of ordinary skill in the art. The memory <NUM> may additionally or alternatively store instructions that when executed by the processing circuity <NUM>, cause the processing circuitry <NUM> to perform one or more functions of the controller <NUM>.

The processing circuitry <NUM> is configured to process data (e.g. map data and/or sensor data) received by the controller <NUM> and/or accessed from memory <NUM> to determine a driver score. The processing circuitry <NUM> may additionally or alternatively process the data (e.g. sensor data) to determine one or more event instances represented as event data. The processing of the data (e.g. map and/or sensor data) provides an increased detail and advanced driving characterization to improve upon conventional scoring techniques.

The processing circuitry <NUM> is configured to determine a driver score based on positional deviations between the map data and sensor data, such as positional deviations from a reference point and one or more landmarks, road markings, traffic signs, or other road features. Additionally or alternatively, the driving system (e.g. safety system <NUM> and/or road management system <NUM>) may be evaluated and adapted based on the driver scoring metrics determined using deviations between the optimum path (e.g. deviations between the map data and sensor data). The driving systems may be adaptively improved (e.g. using machine learning) based on determinations of deviations used in the driving scoring according to the invention.

As illustrated in <FIG>, landmarks may include road features such as lane markings <NUM>, road edge markings <NUM>, road arrow markings <NUM>, stop line markings <NUM>, crosswalk markings, or other road markers as would be understood by one of ordinary skill in the art. The road features may additionally or alternatively include signage, such as traffic lights <NUM>, traffic signs <NUM>, <NUM>, <NUM>, or other traffic control elements, and/or utility or other poles (e.g. road light poles) or structures as would be understood by one of ordinary skill in the art.

As described in more detail with reference to <FIG>, the positions of the various landmarks with respect to a reference point is used to determine deviations from the optimum driving path <NUM>. Advantageously, by using the deviations between the map data that includes an optimum drivable path <NUM> and the current position/path of the vehicle determined from sensor data, the processing circuitry <NUM> is configured to determine dynamic movements of the vehicle and the associated data leading up to an event and/or following an event. For example, using one or more landmarks, the processing circuitry <NUM> is configured to detect driving deviations from a desired (e.g. optimum) driving path <NUM>, such as an optimum path for an autonomous vehicle. The processing circuitry <NUM> may process deviations between the map data that includes an optimum drivable path <NUM> and the current position/path of the vehicle determined from sensor data alert/event data, vector data, vector differences, landmark data, and/or other data using one or more machine learning models.

The processing circuitry <NUM> of the controller <NUM> may include an image processor <NUM> and a driver scoring processor <NUM>. According to the invention, the image processor <NUM> is configured to process image data, such as one or more images, videos, and/or video frames, to determine deviations between image data generated by one or more vehicle sensors (e.g. from image sensor(s) <NUM>) and the map data, where the map data includes one or more road features or landmarks identified in the image data.

With reference to <FIG>, the processing circuitry <NUM> (e.g. image processor <NUM>) may be configured to process image data generated by one or more sensors of the vehicle (e.g. image sensor <NUM>) at the vehicle's current position to determine one or more vectors (a') between a reference point <NUM> and one or more landmarks <NUM>. The vector (a') is a position vector defining a position of the landmark <NUM> with respect the reference point <NUM> at the vehicles current position. The processing circuitry <NUM> may also be configured to determine one or more reference vectors (a) between the reference point <NUM> and the corresponding landmark(s) <NUM> when the vehicle is traversing an optimum path (e.g. the path used to direct an autonomous vehicle). The reference vector (a) is also a position vector defining a position of the landmark <NUM> with respect the reference point <NUM>, but with respect to an optimum path. The reference vector (a) may be determined based on map data, such as map data from map database <NUM> and/or map database <NUM>. The processing circuitry <NUM> may then determine a difference between the position vectors a and a' (e.g. a-a'), and compare the difference with a vector threshold Tv. The reference point <NUM> may be a center of view, such as a center of view of an image sensor such that the reference point <NUM> is the center of the captured image. In this example, the position of the reference point <NUM> with respect to the landmarks <NUM> changes as the vehicle is moving.

The processing circuitry <NUM> may be configured to determine a running windowed average (averaged over a sequence of video frames) of vector differences (greater than vector thresholds) for one or more landmarks over the path of the vehicle as illustrated in <FIG>, which illustrate the averaged vector magnitude differences and the averaged vector angular differences, respectively. Instances of a high deviation count and the extent of deviation or curve analysis of this windowed deviation can be used for driving characterization.

<FIG> illustrate the identification of one or more landmarks and the determination of position vectors between the identified landmarks and a reference point, center of view <NUM>. Although examples include the center of view <NUM> as the reference point, the reference point is not limited thereto.

The controller <NUM> may be configured to process image data generated by one or more sensors of the vehicle (e.g. image sensor <NUM>) at the vehicle's current position to identify one or more landmarks, such as lane markings <NUM>, road edge markings <NUM>, road arrow markings <NUM>, stop line markings <NUM>, crosswalk markings, traffic lights <NUM>, traffic signs <NUM>, <NUM>, <NUM>, or other markings or objects as would be understood by one of ordinary skill in the art. The controller <NUM> may then determine one or more position vectors (a') between the reference point <NUM> (as the center of view) and the identified landmarks. In the example illustrated in <FIG>, position vectors and vector differences are determine between traffic lights <NUM> and <NUM>. For example, position vector a' is determined between the reference point <NUM> and traffic light <NUM> and position vector b' is determined between the reference point <NUM> and traffic light <NUM>.

The controller <NUM> may then determine vector differences for the landmarks (traffic lights <NUM> and <NUM>) based on the determined position vectors and position vectors for these landmarks during the traversal of an optimum path <NUM>. <FIG> illustrates the position vectors between the landmarks, including position vector a between the reference point <NUM> and traffic light <NUM> and position vector b between the reference point <NUM> and traffic light <NUM>. These optimum path position vectors may be provided to the vehicle (e.g. from a road management system <NUM> as shown in <FIG>) in the form of, for example, map data, map metadata, and/or other data, and/or determined by the controller <NUM> of the vehicle <NUM> based on data provided to the vehicle (e.g. from a road management system <NUM>). In configurations where the controller <NUM> determines the optimum path vectors, the controller <NUM> can be provided the optimum path <NUM> and then determines the position vectors for the landmarks with respect to the reference point <NUM> when adjusted to the optimum path <NUM>.

The controller <NUM> may then determine vector difference a-a' for traffic light <NUM> and vector difference b-b' for traffic light <NUM>. The controller <NUM> may then determine a driver score or driving characterization based on one or more of the vector differences and corresponding vector threshold values. The vector difference for a particular landmark may be determined continuously (e.g. while the landmark is within a viewing range of the image sensor <NUM>) and two or more of the calculated vector differences for the particular landmark may be used in the driver scoring and/or characterization. For example, an average or a rolling average of the vector differences may be determined and compared to the threshold value.

For configurations when vector differences for two or more landmarks are determined, the controller <NUM> may use one or more vector differences from one or more of the landmarks in the driver scoring and/or characterization. The number of vector differences and/or the number of associated landmarks may be dynamically adjusted, such as to adjust the degree of accuracy of the driver scoring and/or characterization calculations. The adjustments may be based on the number of events/alerts determined by the vehicle <NUM> within a particular driving segment or time window, a previous driver score determined by the controller <NUM>, available processing capabilities of the controller <NUM> or vehicle <NUM>, and/or one or more other factors or parameters as would be understood by one of ordinary skill in the art.

<FIG> illustrate the identification of one or more landmarks and the determination of position vectors between the identified landmarks and a reference point, center of view <NUM>, similar to the identification and determinations as discussed with reference to <FIG>. In <FIG>, the determination of the position vectors and vector differences utilizes only landmarks in the form of various lane markings, such as lane markings <NUM>, road edge markings <NUM>, and road arrow markings <NUM>. For example, position vectors are determined between the center of view <NUM> as the reference point and road arrow <NUM>, road arrow <NUM>, and road edge <NUM>, as position vectors k, m, and n, respectively.

The controller <NUM> may be configured to determine one or more driver scores and/or characterizations of a vehicle's movements or behaviors based on determined deviations from an optimum path (based on landmark vector differences), one or more alerts/events, traffic data, sensor data, map data, map metadata, map markers, and/or other data as would be understood by one of ordinary skill in the art. As shown in <FIG>, the processing circuitry <NUM> of the controller <NUM> may generate the driver score based on the path deviations, alert data (corresponding to one or more events/alerts), and/or traffic data and other external influences. The driver score may be alternatively or additional determined based on one or more other data parameters as would be understood by one of ordinary skill in the arts.

Additionally or alternatively, the controller <NUM> may be configured to determine and analyze deviation at a regular sampling frequency with respect to distance, time and/or significant location points (intersections, grey spots, etc.). Based on the comparison of the deviations with the threshold value, the deviations may contribute the driver score calculation or disregarded. Additionally or alternatively, the controller <NUM> may adjust the sampling of the sensor data and/or map data (or other data) based on the degree and/or prevalence of the deviations and/or in response to a generated event/alert. For example, if a Headway Monitoring Warning (HMW) event is generated (which may implying tailgating), the frequency of sampling of optimum path deviations may be increased. As a further example, if a lane departure warning is generated, the optimum path deviation information may be ignored as the deviation may be intended by the driver. Additionally or alternatively, the nature of the road and/or traffic may also impact the use of the path deviations as a deviation may be the result of the driver attempting to avoid traffic.

As discussed above, the determination of driver scores may be computed externally, such as by the system <NUM>, and/or by the vehicle's internal system (e.g. controller <NUM>). For example, non-autonomous vehicles may upload the data to the external system <NUM> where driver scores can be computed. In configuration where the computations are performed by the vehicle <NUM>, the vehicle <NUM> can download the map from the system <NUM>, determine path deviations, and generate the driver score based on the deviations.

As illustrated in <FIG>, optimum path deviations for driving characterization can be used to generate the driver score based on the vector magnitude and angular deviations. Accumulated, distance normalized, magnitude and/or angular data sampled at location points over the course of a trip can be used to derive a score using, for example, the histogram-CDF (cumulative distribution function) or other distribution functions as would be understood by one of ordinary skill in the art.

Maps for vehicle positioning may be created by crowd sourcing data associated with the various landmarks. <FIG> shows system <NUM> having controller <NUM> that is configured to communicate with one or more vehicles <NUM> via one or more communication technologies (e.g. <NUM>). The controller <NUM> may include a transceiver <NUM>, processing circuitry <NUM>, and memory <NUM> having a map database <NUM>.

The transceiver <NUM> may be configured to operate in accordance with any suitable number and/or type of desired radio communication protocols or standards, such as one or more Short Range mobile radio communication standards (e.g. Bluetooth, Zigbee, and the like); one or more Medium or Wide Range mobile radio communication standard (e.g. <NUM> (Universal Mobile Telecommunications System - UMTS), a <NUM> (Long Term Evolution - LTE), or a <NUM> mobile radio communication standard in accordance with corresponding 3GPP (3rd Generation Partnership Project) standards, the most recent version at the time of this writing being the 3GPP Release <NUM> (<NUM>); one or more a Wireless Local Area Network communication protocols or standards (e.g. one or more technologies in accordance with IEEE <NUM> Working Group Standards) and/or one or more vehicle to everything (V2X) communication protocols).

The processing circuitry <NUM> may be configured to analyze and/or process data, such as data received from one or more vehicles, to generate and/or modify one or more maps. The generated and/or updated maps may be stored in map database <NUM> and/or provided to one or more vehicles via the transceiver <NUM>. Additionally or alternatively, the processing circuitry <NUM> may be configured to determine one or more driver scores based on map data and/or other data (e.g. vector data, vector differences) from one or more vehicles <NUM>. The determination of vector differences may be determined by the controller <NUM> alone or in cooperation with the controller <NUM> of one or more vehicles <NUM>. That is, the controller <NUM> of the vehicle and/or the controller <NUM> may determine a driver score based on deviations between the map data and sensor data, such as positional deviations from a reference point and one or more landmarks, road markings, traffic signs, or other road features. For example, the.

Additionally or alternatively, the processing circuitry <NUM> may be configured to generate control data to control one or more vehicles <NUM> to perform one or more actions; analyze and/or process alert/event data corresponding to one or more vehicle-generated alerts/events; generate one or more alerts based on sensor data; imaging, video, and/or audio processing; object detection processing; and/or other processing as would be understood by one of ordinary skill in the art. The operations performed by the processing circuitry <NUM> may be in collaboration with operations performed by the vehicle(s) <NUM>, such as to cooperatively perform one or more of the methods of the invention. The alert/event data, vector data, vector differences, and/or other data may be combined with low confidence map data (e.g. map metadata) to generate one or more higher-confidence maps. The improved/updated maps may then be provided to the vehicle(s) <NUM> via the transceiver <NUM>. The processing circuitry <NUM> may process alert/event data, vector data, vector differences, and/or other data using one or more machine learning models.

<FIG> illustrates a flowchart of a driver scoring method <NUM> according to the invention. The flowchart <NUM> is described with continued reference to <FIG>. The operations of the method are not limited to the order described below, and the various operations may be performed in a different order. Further, two or more operations of the methods may be performed simultaneously with each other.

The flowchart <NUM> begins with operations <NUM>, where one or more landmarks are identified. For example, the controller <NUM> may process image data generated by one or more sensors of the vehicle (e.g. image sensor <NUM>) to identify one or more landmarks (e.g. as illustrated in <FIG>, such as lane markings <NUM>, road edge markings <NUM>, road arrow markings <NUM>, stop line markings <NUM>, crosswalk markings, traffic lights <NUM>, traffic signs <NUM>, <NUM>, <NUM>, or other markings or objects as would be understood by one of ordinary skill in the art).

After operation <NUM>, the flowchart <NUM> transitions to operation <NUM>, where one or more position vectors (v') from the reference point to the identified marker(s) are determined based on sensor or other data. For example, the controller <NUM> may be configured to determine one or more position vectors (v') between the reference point (e.g. center of view <NUM>) and the identified landmarks based on the vehicle's current position and image data including the landmark(s).

After operation <NUM>, the flowchart <NUM> transitions to operation <NUM>, where one or more position vectors (v) from the reference point to the identified marker(s) are determined based on map data. In this example, the position vectors (v) corresponding to position vectors between the reference point and the landmarks during a traversal of an optimum path (e.g. path <NUM>) by a vehicle. This optimum path is a path that is traversed by an autonomous vehicle when under an autonomous or semi-autonomous operation, such as the path determined by an advanced driving assistance system (ADAS) or a driving assistance and automated driving system. The vehicle may be provided the information defining the optimum path by its ADAS or other driving system, and/or by one or more external systems in the form of, for example, map data (e.g. map data provided by controller <NUM>). For example, the optimum path position vectors may be provided to the vehicle from a road management system <NUM> as shown in <FIG>.

After operation <NUM>, the flowchart <NUM> transitions to operation <NUM>, where one or more vector differences are determined and the vector differences are compared to a threshold value. For example, the controller <NUM> may determine vector differences for the landmarks based on the determined position vectors (v') and position vectors (v) for these landmarks during the traversal of an optimum path. The controller <NUM> may then compare the vector difference to a threshold value to determine if the deviation from the optimum path as reflected by the vector difference should be used for driving characterization and/or be used in the driver scoring determination.

The determination of the position vectors and/or vector differences may be determined locally by the vehicle (e.g. by controller <NUM>), by one or more external systems (e.g. by controller <NUM>), and by a combination of local and external processing. In configurations where an external system performs at least some determinations of the position vectors and/or vector differences, the vehicle can provide data identifying the landmarks at the vehicles current position to the external system.

In configurations where the controller <NUM> determines the optimum path position vectors, the controller <NUM> can be provided the optimum path <NUM> and then determines the position vectors for the landmarks with respect to the reference point <NUM> when adjusted to the optimum path <NUM>.

If the comparison of the vector difference is greater than or equal to the threshold (YES at operation <NUM>), the flowchart <NUM> transitions to operation <NUM> where the vector differences are used for driving characterization and/or as a factor in driver score determinations. Otherwise (NO at operation <NUM>), the flowchart <NUM> returns to operation <NUM>. For example, the controller <NUM> may determine the driver score based on the vector difference. Additionally or alternatively, the external controller <NUM> may determine the driver score based on the vector difference. The vector difference for a particular landmark may be determined continuously (e.g. while the landmark is within a viewing range of the image sensor <NUM>) and two or more of the calculated vector differences for the particular landmark may be used in the driver scoring and/or characterization. For example, an average or a rolling average of the vector differences may be determined and compared to the threshold value.

With continued reference to <FIG>, the flowchart <NUM> may be a computer-implemented method executed by and/or otherwise associated with one or more processors (processing circuitry) and/or storage devices. These processors and/or storage devices may be, for instance, associated with one or more components of a vehicle <NUM> as discussed herein with reference to <FIG>, including the controller <NUM> of <FIG> and/or controller <NUM> of <FIG>. For instance, the processors and/or storage devices may be identified with the one or more processors <NUM> and/or one or more of the application processors 214A, 214B, image processor <NUM>, communication processor <NUM>, etc., executing computer-readable instructions stored in the memory <NUM>, as shown and described herein with reference to <FIG>. The one or more processors <NUM> and/or one or more of the application processors 214A, 214B, image processor <NUM>, communication processor <NUM>, etc. may additionally or alternatively work exclusively as hardware components (processing circuitry or other suitable circuitry), execute instructions stored on other computer-readable storage mediums not shown in the Figures (which may be locally-stored instructions as part of the processing circuitries themselves), and any combination thereof. The various vehicle components used to perform the method <NUM> may also include other components such as one or more of the wireless transceivers <NUM>, <NUM>, <NUM>, and their accompanying communication interface(s), as discussed herein with reference to <FIG>. The flowchart <NUM> may include alternate or additional steps that are not shown in <FIG>, for purposes of brevity, and may be performed in a different order than the steps shown.

The aforementioned description will so fully reveal the general nature of the implementation of the invention that others can, by applying knowledge within the skill of the art, readily modify and/or adapt for various applications such specific implementations without undue experimentation and without departing from the general concept of the present invention. Therefore, such adaptations and modifications are intended to be within the meaning and range of equivalents of the disclosed implementations, based on the teaching and guidance presented herein. It is to be understood that the phraseology or terminology herein is for the purpose of description and not of limitation, such that the terminology or phraseology of the present specification is to be interpreted by the skilled artisan in light of the teachings and guidance.

Each implementation described may include a particular feature, structure, or characteristic, but every implementation may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same implementation. Further, when a particular feature, structure, or characteristic is described in connection with an implementation, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other implementations whether or not explicitly described.

The exemplary implementations described herein are provided for illustrative purposes, and are not limiting. Other implementations are possible, and modifications may be made to the exemplary implementations. Therefore, the specification is not meant to limit the invention. Rather, the scope of the invention is defined only in accordance with the following claims and their equivalents.

The designs of the invention may be implemented in hardware (e.g., circuits), firmware, software, or any combination thereof. Designs may also be implemented as instructions stored on a machine-readable medium, which may be read and executed by one or more processors. A machine-readable medium may include any mechanism for storing or transmitting information in a form readable by a machine (e.g., a computing device). A machine-readable medium may include read only memory (ROM); random access memory (RAM); magnetic disk storage media; optical storage media; flash memory devices; electrical, optical, acoustical or other forms of propagated signals (e.g., carrier waves, infrared signals, digital signals, etc.), and others. Further, firmware, software, routines, instructions may be described herein as performing certain actions. However, it should be appreciated that such descriptions are merely for convenience and that such actions in fact results from computing devices, processors, controllers, or other devices executing the firmware, software, routines, instructions, etc. Further, any of the implementation variations may be carried out by a general purpose computer.

The terms "at least one" and "one or more" may be understood to include a numerical quantity greater than or equal to one (e.g., one, two, three, four, [. The term "a plurality" may be understood to include a numerical quantity greater than or equal to two (e.g., two, three, four, five, [.

The words "plural" and "multiple" in the description and in the claims expressly refer to a quantity greater than one. Accordingly, any phrases explicitly invoking the aforementioned words (e.g., "plural [elements]", "multiple [elements]") referring to a quantity of elements expressly refers to more than one of the said elements. The terms "group (of)", "set (of)", "collection (of)", "series (of)", "sequence (of)", "grouping (of)", etc., and the like in the description and in the claims, if any, refer to a quantity equal to or greater than one, i.e., one or more. The terms "proper subset", "reduced subset", and "lesser subset" refer to a subset of a set that is not equal to the set, illustratively, referring to a subset of a set that contains less elements than the set.

The phrase "at least one of" with regard to a group of elements may be used herein to mean at least one element from the group consisting of the elements. The phrase "at least one of" with regard to a group of elements may be used herein to mean a selection of: one of the listed elements, a plurality of one of the listed elements, a plurality of individual listed elements, or a plurality of a multiple of individual listed elements.

The term "data" as used herein may be understood to include information in any suitable analog or digital form, e.g., provided as a file, a portion of a file, a set of files, a signal or stream, a portion of a signal or stream, a set of signals or streams, and the like. Further, the term "data" may also be used to mean a reference to information, e.g., in form of a pointer. The term "data", however, is not limited to the aforementioned data types and may take various forms and represent any information as understood in the art.

The terms "processor" or "controller" as used herein may be understood as any kind of technological entity that allows handling of data. The data may be handled according to one or more specific functions executed by the processor or controller. Further, a processor or controller as used herein may be understood as any kind of circuit, e.g., any kind of analog or digital circuit. A processor or a controller may thus be or include an analog circuit, digital circuit, mixed-signal circuit, logic circuit, processor, microprocessor, Central Processing Unit (CPU), Graphics Processing Unit (GPU), Digital Signal Processor (DSP), Field Programmable Gate Array (FPGA), integrated circuit, Application Specific Integrated Circuit (ASIC), etc., or any combination thereof. Any other kind of implementation of the respective functions, which will be described below in further detail, may also be understood as a processor, controller, or logic circuit. It is understood that any two (or more) of the processors, controllers, or logic circuits detailed herein may be realized as a single entity with equivalent functionality or the like, and conversely that any single processor, controller, or logic circuit detailed herein may be realized as two (or more) separate entities with equivalent functionality or the like.

As used herein, "memory" is understood as a computer-readable medium in which data or information can be stored for retrieval. References to "memory" included herein may thus be understood as referring to volatile or non-volatile memory, including random access memory (RAM), read-only memory (ROM), flash memory, solid-state storage, magnetic tape, hard disk drive, optical drive, among others, or any combination thereof. Registers, shift registers, processor registers, data buffers, among others, are also embraced herein by the term memory. The term "software" refers to any type of executable instruction, including firmware.

In one or more of the implementations described herein, processing circuitry can include memory that stores data and/or instructions. The memory can be any well-known volatile and/or non-volatile memory, including read-only memory (ROM), random access memory (RAM), flash memory, a magnetic storage media, an optical disc, erasable programmable read only memory (EPROM), and programmable read only memory (PROM). The memory can be non-removable, removable, or a combination of both.

Unless explicitly specified, the term "transmit" encompasses both direct (point-to-point) and indirect transmission (via one or more intermediary points). Similarly, the term "receive" encompasses both direct and indirect reception. Furthermore, the terms "transmit," "receive," "communicate," and other similar terms encompass both physical transmission (e.g., the transmission of radio signals) and logical transmission (e.g., the transmission of digital data over a logical software-level connection). A processor or controller may transmit or receive data over a software-level connection with another processor or controller in the form of radio signals, where the physical transmission and reception is handled by radio-layer components such as RF transceivers and antennas, and the logical transmission and reception over the software-level connection is performed by the processors or controllers. The term "communicate" encompasses one or both of transmitting and receiving, i.e., unidirectional or bidirectional communication in one or both of the incoming and outgoing directions. The term "calculate" encompasses both 'direct' calculations via a mathematical expression/formula/relationship and 'indirect' calculations via lookup or hash tables and other array indexing or searching operations.

A "vehicle" may be understood to include any type of driven object. A vehicle may be a driven object with a combustion engine, a reaction engine, an electrically driven object, a hybrid driven object, or a combination thereof. A vehicle may be or may include an automobile, a bus, a mini bus, a van, a truck, a mobile home, a vehicle trailer, a motorcycle, a bicycle, a tricycle, a train locomotive, a train wagon, a moving robot, a personal transporter, a boat, a ship, a submersible, a submarine, a drone, an aircraft, a rocket, and the like.

The term "autonomous vehicle" may describe a vehicle that implements all or substantially all navigational changes, at least during some (significant) part (spatial or temporal, e.g., in certain areas, or when ambient conditions are fair, or on highways, or above or below a certain speed) of some drives. Sometimes an "autonomous vehicle" is distinguished from a "partially autonomous vehicle" or a "semi-autonomous vehicle" to indicate that the vehicle is capable of implementing some (but not all) navigational changes, possibly at certain times, under certain conditions, or in certain areas. A navigational change may describe or include a change in one or more of steering, braking, or acceleration/deceleration of the vehicle. A vehicle may be described as autonomous even in case the vehicle is not fully automatic (fully operational with driver or without driver input). Autonomous vehicles may include those vehicles that can operate under driver control during certain time periods and without driver control during other time periods. Autonomous vehicles may also include vehicles that control only some implementations of vehicle navigation, such as steering (e.g., to maintain a vehicle course between vehicle lane constraints) or some steering operations under certain circumstances (but not under all circumstances), but may leave other implementations of vehicle navigation to the driver (e.g., braking or braking under certain circumstances). Autonomous vehicles may also include vehicles that share the control of one or more implementations of vehicle navigation under certain circumstances (e.g., hands-on, such as responsive to a driver input) and vehicles that control one or more implementations of vehicle navigation under certain circumstances (e.g., hands-off, such as independent of driver input). Autonomous vehicles may also include vehicles that control one or more implementations of vehicle navigation under certain circumstances, such as under certain environmental conditions (e.g., spatial areas, roadway conditions). In some implementations, autonomous vehicles may handle some or all implementations of braking, speed control, velocity control, and/or steering of the vehicle. An autonomous vehicle may include those vehicles that can operate without a driver. The level of autonomy of a vehicle may be described or determined by the Society of Automotive Engineers (SAE) level of the vehicle (as defined by the SAE in SAE J3016 <NUM>: Taxonomy and definitions for terms related to driving automation systems for on road motor vehicles) or by other relevant professional organizations. The SAE level may have a value ranging from a minimum level, e.g. level <NUM> (illustratively, substantially no driving automation), to a maximum level, e.g. level <NUM> (illustratively, full driving automation).

The systems and methods of the invention may utilize one or more machine learning models to perform corresponding functions of the vehicle (or other functions described herein). The term "model" as, for example, used herein may be understood as any kind of algorithm, which provides output data from input data (e.g., any kind of algorithm generating or calculating output data from input data). A machine learning model may be executed by a computing system to progressively improve performance of a specific task. In some aspects, parameters of a machine learning model may be adjusted during a training phase based on training data. A trained machine learning model may then be used during an inference phase to make predictions or decisions based on input data.

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

In supervised learning, the model may be built using a training set of data that contains both the inputs and corresponding desired outputs. Each training instance may include one or more inputs and a desired output. Training may include iterating through training instances and using an objective function to teach the model to predict the output for new inputs. In semi-supervised learning, a portion of the inputs in the training set may be missing the desired outputs.

In unsupervised learning, the model may be built from a set of data which contains only inputs and no desired outputs. The unsupervised model may be used to find structure in the data (e.g., grouping or clustering of data points) by discovering patterns in the data. Techniques that may be implemented in an unsupervised learning model include, e.g., self-organizing maps, nearest-neighbor mapping, k-means clustering, and singular value decomposition.

Reinforcement learning models may be given positive or negative feedback to improve accuracy. A reinforcement learning model may attempt to maximize one or more objectives/rewards. Techniques that may be implemented in a reinforcement learning model may include, e.g., Q-learning, temporal difference (TD), and deep adversarial networks.

The systems and methods of the invention may utilize one or more classification models. In a classification model, the outputs may be restricted to a limited set of values (e.g., one or more classes). The classification model may output a class for an input set of one or more input values. An input set may include road condition data, event data, sensor data, such as image data, radar data, LIDAR data and the like, and/or other data as would be understood by one of ordinary skill in the art. A classification model as described herein may, for example, classify certain driving conditions and/or environmental conditions, such as weather conditions, road conditions, and the like. References herein to classification models may contemplate a model that implements, e.g., any one or more of the following techniques: linear classifiers (e.g., logistic regression or naive Bayes classifier), support vector machines, decision trees, boosted trees, random forest, neural networks, or nearest neighbor.

One or more regression models may be used. A regression model may output a numerical value from a continuous range based on an input set of one or more values. References herein to regression models may contemplate a model that implements, e.g., any one or more of the following techniques (or other suitable techniques): linear regression, decision trees, random forest, or neural networks.

A machine learning model described herein may be or may include a neural network. The neural network may be any kind of neural network, such as a convolutional neural network, an autoencoder network, a variational autoencoder network, a sparse autoencoder network, a recurrent neural network, a deconvolutional network, a generative adversarial network, a forward-thinking neural network, a sum-product neural network, and the like. The neural network may include any number of layers. The training of the neural network (e.g., adapting the layers of the neural network) may use or may be based on any kind of training principle, such as backpropagation (e.g., using the backpropagation algorithm).

Claim 1:
A controller (<NUM>) of a vehicle (<NUM>), comprising:
interface means (<NUM>) for receiving map data and sensor data; and
processing means (<NUM>) for:
determining a positional deviation (a-a') between one or more landmarks (<NUM>) included in the map data and the one or more landmarks (<NUM>) included in the sensor data; and
determining a driver score based on the determined positional deviation (a-a').