Handling high definition map data messages

Abstract

Various embodiments of methods and systems for handling high definition (HD) map data messages by a processing system of a vehicle include receiving a plurality of HD map data messages each including sequence information in a first memory queue of the processing system via a user datagram protocol (UDP); storing a selected one of the HD map data messages in a second memory queue in response to determining that sequence information for the selected one of the HD map data messages is greater than an expected sequence number; and processing the HD map data message stored in the second memory queue in response to the sequence information of the HD map data message stored in the second memory queue matching the expected sequence number.

Description

Background Art

[0001] High-definition maps (HD maps) are highly accurate maps widely used in autonomous driving systems (ADS) and advanced driver assistance systems (ADAS). Vehicles can request HD map data from network computing devices, such as electronic horizon providers (EHPs). EHPs can send HD map data in a sequence of multiple HD map messages. However, due to network congestion, network routing, or other factors, the requesting vehicle may receive the HD map data messages out of sequence. Summary of the Invention

[0002] Various aspects include a method executable by a vehicle processing system of a vehicle for handling HD map data messages. The various aspects include: receiving a plurality of HD map data messages, each including sequence information, in a first memory queue of the processing system via a user datagram protocol (UDP); storing a selected HD map data message in a second memory queue in response to determining that the sequence information of a selected HD map data message among the HD map data messages is greater than expected sequence information; and processing the HD map data message stored in the second memory queue in response to the sequence information of the HD map data message stored in the second memory queue matching the expected sequence information.

[0003] Some aspects may include determining whether the second memory queue stores an HD map data message, and in response to determining that the second memory queue stores an HD map data message, determining whether the HD map data message stored in the second memory queue matches the expected sequence information. Some aspects may include processing the HD map data message stored in the first memory queue in response to determining that the second memory queue does not store an HD map data message or determining that the sequence information of the HD map data message stored in the second memory queue does not match the expected sequence information. Some aspects may include discarding selected ones of the HD map data messages in response to determining that the sequence information of the selected HD map data message is less than the expected sequence information.

[0004] In some aspects, receiving the plurality of HD map data messages, each including sequence information, in the first memory queue of the processing system via UDP may include: sending a request for HD map data to an electronic horizon provider; and receiving the plurality of HD map data messages in response to the request for the HD map data. Some aspects may include: starting a first timer after sending the request for the HD map data to a network computing device configured to provide HD map data; and sending a second request for HD map data to the network computing device in response to the first timer expiring before receiving the HD map data message.

[0005] Some aspects may include: starting a second timer after receiving the plurality of HD map data messages in the first memory queue of the processing system; and determining that an HD map data message has been lost in response to the second timer expiring before the sequence information of the HD map data messages stored in either the first memory queue or the second memory queue matches the expected sequence information. In some aspects, the second memory queue may include a priority queue, and the sequence information of each of the HD map data messages stored in the second memory queue is processed as priority information for each of the HD map data messages stored in the second memory queue.

[0006] Further aspects include a processing system for a vehicle, the processing system comprising a memory and a processor configured to perform the operations of any of the methods outlined above. Further aspects may include a processing system for a vehicle having various components for performing functions corresponding to any of the methods outlined above. Further aspects may include a non-transitory processor-readable storage medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause the processing system of the vehicle to perform various operations corresponding to any of the methods outlined above. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate exemplary embodiments of the claims and, together with the general description and detailed description given, serve to explain the features herein.

[0008] Figure 1A is a system block diagram illustrating an example communication system suitable for implementing various embodiments.

[0009] Figure 1B is a system block diagram illustrating an example decomposed base station suitable for implementing various embodiments.

[0010] Figure 2A is a component diagram of an example vehicle processing system suitable for implementing various embodiments.

[0011] Figure 2B is a component block diagram illustrating components of an example vehicle processing system suitable for implementing various embodiments.

[0012] Figure 3 is a block diagram illustrating components of a system-on-chip suitable for use in a vehicle processing system, according to various embodiments.

[0013] Figure 4A is a message flow diagram illustrating a method for handling HD map data messages according to various embodiments.

[0014] Figure 4B is a block diagram illustrating a method for handling HD map data messages according to various embodiments.

[0015] Figure 4C is a block diagram illustrating a first memory queue and a second memory queue configured to handle HD map data messages according to various embodiments.

[0016] 5A to 5I is a block diagram illustrating operations that may be performed by a processor of a vehicle processing system for handling HD map data messages, according to various embodiments.

[0017] Figure 6A is a process flow diagram of an example method executed by a processor of a vehicle processing system in a vehicle for handling HD map data messages, according to various embodiments.

[0018] Figure 6B is a process flow diagram of an example method executed by a processor of a vehicle processing system in a vehicle for handling HD map data messages, according to various embodiments.

[0019] Figure 6C is a process flow diagram of example operations that may be performed by a processor of a vehicle processing system in a vehicle as part of a method for handling HD map data messages, according to various embodiments.

[0020] Figure 6D is a process flow diagram of example operations that may be performed by a processor of a vehicle processing system in a vehicle as part of methods and operations for handling HD map data messages, according to various embodiments. DETAILED DESCRIPTION

[0021] Various embodiments will be described in detail with reference to the accompanying drawings. Wherever possible, the same reference numerals will be used throughout the drawings to refer to the same or similar parts. Reference to specific examples and specific implementations is for illustrative purposes and is not intended to limit the scope of the claims.

[0022] Various embodiments include methods and vehicle processing systems configured to perform methods for handling high-definition (HD) map data messages. In various embodiments, the vehicle processing system may include one or more processors and / or other components configured to perform various operations for handling HD map data messages. In various embodiments, the vehicle processing system may receive HD map messages, each HD map message including sequence information indicating a sequence of the HD map messages. These systems and methods enable the vehicle's processing system to receive HD map messages using two memory queues of the processing system and process the HD map messages in the sequence indicated therein even when the HD map messages are received out of sequence. In this way, the vehicle processing system may reduce or avoid the need to transmit a request to reestablish a communication link with a service provider computing device that sent the HD map data messages.

[0023] As used herein, the term "vehicle" generally refers to any of a car, motorcycle, truck, bus, boat, and any other type of vehicle that may be configured with a processing system for managing driver engagement.

[0024] The term "system on a chip" (SOC) is used herein to refer to a single integrated circuit (IC) chip that contains multiple resources and / or processors integrated on a single substrate. A single SOC may contain circuitry for digital, analog, mixed-signal, and radio frequency functions. A single SOC may also include any number of general-purpose and / or specialized processors (digital signal processors, modem processors, video processors, etc.), memory blocks (e.g., ROM, RAM, flash memory, etc.), and resources (e.g., timers, voltage regulators, oscillators, etc.). The SOC may also include software for controlling the integrated resources and processors, as well as for controlling peripheral devices.

[0025] The term "system-in-package" (SIP) may be used herein to refer to a single module or package that contains multiple resources, computing units, cores and / or processors on two or more IC chips, substrates, or SOCs. For example, a SIP may include a single substrate on which multiple IC chips or semiconductor dies are stacked in a vertical configuration. Similarly, a SIP may include one or more multi-chip modules (MCMs) on which multiple ICs or semiconductor dies are packaged into a unified substrate. A SIP may also include multiple independent SOCs that are coupled together via high-speed communication circuits and packaged in close proximity, such as on a single motherboard or in a single wireless device. The proximity of the SOCs facilitates high-speed communication and the sharing of memory and resources.

[0026] A high-definition map (HD map) is a data structure that includes highly accurate map data, including information about road geometry, lanes, traffic signs, and signals, as well as other appropriate map data. HD map data is also referred to as electronic horizon data. Autonomous driving systems (ADS) or advanced driver assistance systems (ADAS) can use HD map data to perform various planning and maneuvering operations. HD map data can be generated by a network computing device, such as an electronic horizon provider (EHP), and provided to the vehicle processing system in a number of HD map data messages.

[0027] The vehicle processing system may be configured to perform operations to receive an HD map data message from a network computing device and assemble an HD map based on the information in the HD map data message. In some embodiments, a function or module of the vehicle processing system, such as a vehicle-side electronic horizon reconstructor (EHR), may receive the HD map data message and reconstruct the HD map from the HD map data message. The vehicle processing system may also be configured to perform operations to transform the information or HD map in the HD map data message into a format usable by an ADS or ADAS system. For example, the vehicle processing system may perform operations to format the information or HD map in the HD map data message according to the data structure, format, syntax, etc. required by a particular ADS or ADAS system.

[0028] In some embodiments, network computing devices (e.g., of an HD map provider) and vehicle processing systems may communicate HD map data messages using the Uniform Datagram Protocol (UDP). UDP is a connectionless protocol in which the sending and receiving computing devices (e.g., the HD map data provider computing device and the vehicle computing system) do not establish a communication link before sending data. Instead, a computing device (e.g., a vehicle processing system) sends a request for data (e.g., HD map data) to a provider computing device (e.g., an EHP network computing device), and the provider computing device responds by sending the requested data, for example, to a designated port of the requesting computing device. However, computing devices using UDP do not implement error checking or flow control operations, nor does UDP include procedures for resending lost or damaged packets. For at least these reasons, UDP enables the rapid transmission of HD map data messages without the network signaling and processing overhead incurred by, and without the reliability of transmission provided by, communication link establishment (connection establishment), error checking, flow control, and resending procedures.

[0029] Because UDP is a relatively unreliable protocol, HD map data messages may arrive at the vehicle processing system out of order (e.g., out of sequence), may be delivered more than once, or may not be received (e.g., lost or garbled). In conventional systems, upon detecting (identifying, determining) an out-of-order packet, the receiving computing device may transmit another connection request to the network computing device that provided the HD map data message, and in response, the network computing device may retransmit the HD map data message. In some embodiments, the network computing device may retransmit the HD map data message for the geographic area surrounding the vehicle, resulting in a large and unnecessary transmission of the HD map data message (unnecessary because the HD map data message was received despite being out of order).

[0030] Various embodiments may include a method and a vehicle processing system (vehicle processing system) configured to implement the method for handling HD map data messages. In some embodiments, the vehicle processing system may send a request for HD map data to a network computing device (e.g., of an electronic horizon provider). In response to the request for HD map data, the vehicle processing system may receive a plurality of HD map data messages in a first memory queue of the processing system via UDP.

[0031] In some embodiments, the network computing device may configure (e.g., include or append) sequence information to each HD map data message, such as a sequence number on each message that indicates the position of each message in the sequence of HD map data messages. As a non-limiting example, the first HD map data message may be configured with or include a sequence number (e.g., "0"), the second HD map data message may be configured with or include a subsequent sequence number (e.g., "1"), and so on.

[0032] In some embodiments, the vehicle processing system may include a first memory queue configured to receive HD map data messages and store the messages in the order in which they were received from the network computing device. In some embodiments, the vehicle processing system may be configured to process or dispose of the HD map data messages in the first memory queue in a first-in, first-out (FIFO) manner. The vehicle processing system may also include a second memory queue, such as a priority queue.

[0033] In some embodiments, the vehicle processing system may be configured to process (handle, use) sequence information in each HD map data message as an indication of a priority for storing the HD map data message in the second memory queue. In some embodiments, the vehicle processing system may be configured to store the HD map data messages in a priority order, such as from the highest priority message (e.g., the message with the lowest sequence number) stored in the first memory location to the lowest priority message (e.g., the message with the highest sequence number) stored in the last memory location within the second memory queue. In some embodiments, the vehicle processing system may be configured to process or handle the HD map data messages stored in the second memory queue in a priority order, i.e., from highest priority (or lowest sequence number) to lowest priority (or highest sequence number).

[0034] In some embodiments, a vehicle processing system may receive a plurality of HD map data messages via UDP and store such messages in a first memory queue of the processing system. Each of the HD map data messages may include sequence information. The vehicle processing system selects one of the plurality of received HD map data messages and determines whether the sequence information of the selected HD map data message is greater than expected sequence information (e.g., an expected sequence number). The vehicle processing system may store the selected HD map data message in a second memory queue in response to determining that the sequence information of the selected HD map data message is greater than the expected sequence information (e.g., the expected sequence number). The vehicle processing system may process the HD map data message stored in the second memory queue in response to the sequence information of the HD map data message stored in the second memory queue matching the expected sequence information. In some embodiments, the vehicle processing system may determine whether the second memory queue holds the HD map data message and, in response to determining that the second memory queue holds the HD map data message, determine whether the HD map data message stored in the second memory queue matches the expected sequence information.

[0035] In some embodiments, the vehicle processing system may process the HD map data messages stored in the first memory queue in response to determining that the second memory queue does not hold any HD map data messages. In some embodiments, the vehicle processing system may process the HD map data messages stored in the first memory queue in response to determining that sequence information of the HD map data messages stored in the second memory queue does not match expected sequence information. In some embodiments, the vehicle processing system may discard selected ones of the HD map data messages in response to determining that sequence information of the selected HD map data messages is less than expected sequence information.

[0036] In some embodiments, the vehicle processing system may start a first timer after sending a request for HD map data to a network computing device configured to provide HD map data, such as an Electronic Horizon Provider (EHP). The vehicle processing system may send a second request for HD map data to the network computing device in response to the first timer expiring before receiving the HD map data message.

[0037] In some embodiments, the vehicle processing system may start a second timer after receiving a plurality of HD map data messages in a first memory queue of the processing system. The vehicle processing system may determine that the HD map data messages have been lost in response to the second timer expiring before sequence information of the HD map data messages stored in either the first memory queue or the second memory queue matches expected sequence information.

[0038] Various embodiments improve the operational efficiency and speed of a vehicle by enabling a vehicle processing system to handle HD map data messages received out of sequence without requiring a second (or subsequent) transmission of some HD map data messages from the network computing device providing the HD map data messages. Various embodiments improve the operational safety of a vehicle by enabling the vehicle processing system to more quickly assemble HD map data from HD map data messages, thereby more quickly providing information in the HD map data to the vehicle processing system. Various embodiments improve the operational efficiency of a communication network that handles HD map data by reducing the amount of redundant HD map data messages transmitted by the network.

[0039] Figure 1A is a system block diagram illustrating an example communication system 100 suitable for implementing various embodiments. Communication system 100 includes a 5G New Radio (NR) network, an Intelligent Transportation System (ITS) V2X wireless network, and / or any other suitable network, such as a Long Term Evolution (LTE) network. References to 5G networks and 5G network elements in the following description are for illustrative purposes and are not intended to be limiting.

[0040] The communication system 100 may include a heterogeneous network architecture that includes a core network 140, a plurality of base stations 110, and various mobile devices, including a vehicle 102 equipped with a vehicle processing system 104 including wireless communication capabilities. The base stations 110 may communicate with the core network 140 over a wired communication link 126. The communication system 100 may also include a roadside unit 112 that supports V2X communication with the vehicle 102 via the V2X wireless communication link 124.

[0041] The base station 110 is a network element that communicates with wireless devices (e.g., the vehicle processing system 104 of the vehicle 102) via a wireless communication link 122 and may be referred to as a Node B, an LTE evolved Node B (eNodeB or eNB), an access point (AP), a radio head, a transmit receive point (TRP), a new radio base station (NR BS), a 5G Node B (NB), a next generation Node B (gNodeB or gNB), etc. Each base station 110 may provide communication coverage for a particular geographic area or "cell". In 3GPP, the term "cell" may refer to the coverage area of ​​a base station, or a base station subsystem serving the coverage area, or a combination thereof, depending on the context in which the term is used. The core network 140 may be any type of core network, such as an LTE core network (e.g., an evolved packet core (EPC) network), a 5G core network, a reference Figure 1B The decomposed network described above, etc.

[0042] The roadside unit 112 may communicate with the core network 140 via a wired or wireless communication link 128. The roadside unit 112 may communicate with a vehicle 102 equipped with a vehicle processing system via a V2X wireless communication link 124 for downloading information useful for the vehicle processing system's autonomous and semi-autonomous driving functions, and for receiving information such as abnormal behavior reports from the vehicle processing system 104.

[0043] The network computing device 132 may communicate with the core network 140 via a wired or wireless communication link 127. The network computing device 132 may receive a request for HD map data from the vehicle processing system 104. The network computing device 132 may send an HD map data message in response to the request from the vehicle processing system 104.

[0044] The wireless communication link 122 may include multiple carrier signals, frequencies, or frequency bands, each of which may include multiple logical channels. The wireless communication links 122 and 124 may utilize one or more radio access technologies (RATs). Examples of RATs that may be used in the wireless communication links include 3GPP LTE, 3G, 4G, 5G (e.g., NR), GSM, Code Division Multiple Access (CDMA), Wideband Code Division Multiple Access (WCDMA), Worldwide Interoperability for Microwave Access (WiMAX), Time Division Multiple Access (TDMA), and other mobile phone communication technology cellular RATs. Other examples of RATs that may be used in one or more of the various wireless communication links within the communication system 100 include medium-range protocols (such as Wi-Fi, LTE-U, LTE-Direct, LAA, MuLTEfire) and relatively short-range RATs (such as ZigBee, Bluetooth, and Bluetooth Low Energy (LE)).

[0045] Figure 1Bis a system block diagram illustrating an example decomposed base station 160 architecture that may be part of a V2X and / or 5G network suitable for communicating map data and updated object / feature location data to vehicles, according to any of various embodiments. Figure 1A and Figure 1B The disaggregated base station 160 architecture may include one or more central units (CUs) 162, which may communicate directly with the core network 180 via a backhaul link, or indirectly with the core network 180 through one or more disaggregated base station units, such as a near real-time (near-RT) RAN intelligent controller (RIC) 164 via an E2 link, or a non-real-time (non-RT) RIC 168 associated with a service management and orchestration (SMO) framework 166, or both. The CUs 162 may communicate with one or more distributed units (DUs) 170 via corresponding midhaul links, such as the F1 interface. The DUs 170 may communicate with one or more radio units (RUs) 172 via corresponding fronthaul links. The RUs 172 may communicate with corresponding UEs 120 via one or more radio frequency (RF) access links. In some implementations, a user equipment (UE), such as the vehicle processing system 104, may be served simultaneously by multiple RUs 172.

[0046] Each of the units (i.e., CU 162, DU 170, RU 172), as well as near-RT RIC 164, non-RT RIC 168, and SMO framework 166, may include one or more interfaces, or be coupled to one or more interfaces configured to receive or transmit signals, data, or information (collectively, signals) via a wired or wireless transmission medium. Each of the units, or an associated processor or controller that provides instructions to the communication interface of these units, may be configured to communicate with one or more of the other units via the transmission medium. For example, these units may include a wired interface configured to receive signals or transmit signals to one or more of the other units via the wired transmission medium. Additionally, these units may include a wireless interface, which may include a receiver, transmitter, or transceiver (such as a radio frequency (RF) transceiver) configured to receive signals or transmit signals to one or more of the other units via the wireless transmission medium, or both.

[0047] In some aspects, the CU 162 may host one or more higher-layer control functions. Such control functions may include radio resource control (RRC), packet data convergence protocol (PDCP), service data adaptation protocol (SDAP), etc. Each control function may be implemented using an interface configured to communicate signals with other control functions hosted by the CU 162. The CU 162 may be configured to handle user plane functionality (i.e., central unit-user plane (CU-UP)), control plane functionality (i.e., central unit-control plane (CU-CP)), or a combination thereof. In some specific implementations, the CU 162 may be logically split into one or more CU-UP units and one or more CU-CP units. When implemented in an O-RAN configuration, the CU-UP units may communicate bidirectionally with the CU-CP units via an interface (such as an E1 interface). As needed, the CU 162 may be implemented to communicate with the DU 170 for network control and signaling.

[0048] The DU 170 may correspond to a logical unit that includes one or more base station functions for controlling the operation of one or more RUs 172. In some aspects, the DU 170 may host one or more of a radio link control (RLC) layer, a medium access control (MAC) layer, and one or more higher physical (PHY) layers (such as modules for forward error correction (FEC) encoding and decoding, scrambling, modulation, and demodulation), depending at least in part on a functional split, such as that defined by the Third Generation Partnership Project (3GPP). In some aspects, the DU 170 may further host one or more lower PHY layers. Each layer (or module) may be implemented using an interface configured to communicate signals with other layers (and modules) hosted by the DU 170 or with control functions hosted by the CU 162.

[0049] Lower layer functionality may be implemented by one or more RUs 172. In some deployments, a RU 172 controlled by a DU 170 may correspond to a logical node that hosts RF processing functionality or low-PHY layer functionality (such as performing fast Fourier transforms (FFTs), inverse FFTs (iFFTs), digital beamforming, physical random access channel (PRACH) extraction and filtering), or both, based at least in part on a functional split (such as a lower layer functional split). In such an architecture, a RU 172 may be implemented to handle over-the-air (OTA) communications with one or more UEs 120. In some specific implementations, both real-time and non-real-time aspects of control and user plane communications with the RU 172 may be controlled by the corresponding DU 170. In some scenarios, this configuration may enable the DU 170 and CU 162 to be implemented in a cloud-based radio access network (RAN) architecture, such as a vRAN architecture.

[0050] The SMO framework 166 can be configured to support RAN deployment and provisioning of both non-virtualized and virtualized network elements. For non-virtualized network elements, the SMO framework 166 can be configured to support the deployment of dedicated physical resources for RAN coverage requirements, which can be managed via an operations and maintenance interface (such as the O1 interface). For virtualized network elements, the SMO framework 166 can be configured to interact with a cloud computing platform (such as Open Cloud (O-Cloud) 176) to perform network element lifecycle management (such as instantiating virtualized network elements) via a cloud computing platform interface (such as the O2 interface). Such virtualized network elements may include, but are not limited to, the CU 162, DU 170, RU 172, and near-RT RIC 164. In some implementations, the SMO framework 166 can communicate with 4G RAN hardware (such as Open eNB (O-eNB) 174) via the O1 interface. Additionally, in some implementations, the SMO framework 166 can communicate directly with one or more RUs 172 via the O1 interface. The SMO framework 166 may also include a non-RT RIC 168 configured to support the functionality of the SMO framework 166 .

[0051] The non-RT RIC 168 can be configured to include logic that enables non-real-time control and optimization of RAN elements and resources, artificial intelligence / machine learning (AI / ML) workflows including model training and updating, or policy-based guidance of applications / features in the near-RT RIC 164. The non-RT RIC 168 can be coupled to or in communication with the near-RT RIC 164 (e.g., via an A1 interface). The near-RT RIC 164 can be configured to include logic that enables near-real-time control and optimization of RAN elements and resources through data collection and actions over an interface (e.g., via an E2 interface) that connects one or more CUs 162, one or more DUs 170, or both, and the O-eNB with the near-RT RIC 164.

[0052] In some implementations, to generate AI / ML models to be deployed in the near-RT RIC 164, the non-RT RIC 168 may receive parameters or external enrichment information from an external server. Such information may be utilized by the near-RT RIC 164 and may be received from non-network data sources or from network functions at the SMO framework 166 or the non-RT RIC 168. In some examples, the non-RT RIC 168 or the near-RT RIC 164 may be configured to tune RAN behavior or performance. For example, the non-RT RIC 168 may monitor long-term trends and patterns in performance and employ AI / ML models to execute corrective actions through the SMO framework 166 (such as via reconfiguration of O1) or via the creation of RAN management policies (such as A1 policies).

[0053] Figure 2A is a component diagram of an example vehicle processing system 200 suitable for implementing various embodiments. Figures 1A to 2A , processing system 200 may include vehicle 102, which includes vehicle processing system 104. Vehicle processing system 104 may communicate with various systems and devices, such as an in-vehicle network 210, an infotainment system 212, various sensors 214, various actuators 216, and a radio module 218 coupled to an antenna 219. Vehicle processing system 104 may also communicate with roadside units 112, cellular communication network base stations 110, and other external devices.

[0054] The vehicle processing system 104 may include a processor 205, a memory 206, an input module 207, an output module 208, and a radio module 218. The processor 205 may be coupled to the memory 206 (i.e., a non-transitory storage medium) and may be configured with processor-executable instructions stored in the memory 206 to perform operations according to the various embodiments described herein. In addition, the processor 205 may be coupled to the output module 208 (which may control an onboard display) and to the input module 207 to receive information from vehicle sensors and driver input.

[0055] The vehicle processing system 104 may include a V2X antenna 219 coupled to a radio module 218, which is configured to communicate with one or more ITS participants (e.g., stations), the roadside unit 112, and the base station 110 or another suitable network access point. The V2X antenna 219 and the radio module 218 may be configured to receive dynamic traffic flow characteristic information via vehicle-to-everything (V2X) communications. In various embodiments, the vehicle processing system may receive information from multiple sources, such as the in-vehicle network 210, the infotainment system 212, various sensors 214, various actuators 216, and the radio module 218. The vehicle processing system may be configured to use map data in addition to sensor data to perform autonomous or semi-autonomous driving functions, as further described below.

[0056] Examples of in-vehicle networks 210 include controller area networks (CAN), local interconnect networks (LIN), networks using the FlexRay protocol, media-oriented systems transport (MOST) networks, and automotive Ethernet networks. Examples of vehicle sensors 214 include location-determining systems (such as global navigation satellite systems (GNSS) systems), cameras, and other suitable sensor devices and systems. Examples of vehicle actuators 216 include various physical control systems, such as those for steering, brakes, engine operation, lights, turn signals, and the like.

[0057] Figure 2B is a component block diagram illustrating components of an example vehicle processing system 220 suitable for implementing various embodiments. Figures 1A to 2B , a vehicle processing system 220, which may include an autonomous or semi-autonomous driving system, may be coupled to the vehicle processing system 104. The vehicle processing system 220 may include various subsystems, communication elements, computing elements, computing devices, or units that may be utilized within the vehicle 102. The various computing elements, computing devices, or units within the vehicle processing system 220 may be implemented within a system (i.e., a subsystem) of computing devices that communicate data and commands to each other via the vehicle network 210 (e.g., by Figure 2B In some implementations, the various computing elements, computing devices, or units within the vehicle processing system 220 may be implemented within a single computing device, such as separate threads, processes, algorithms, or computing elements. Figure 2BEach subsystem / computing element illustrated in FIG220 is also generally referred to herein as a "layer" within the computing "stack" that makes up vehicle processing system 220. However, the use of the terms layer and stack when describing various embodiments is not intended to imply or require that the corresponding functionality be implemented within a single vehicle computing device, although this is a potential specific implementation. Rather, the use of the term "layer" is intended to include subsystems with independent processors, computing elements (e.g., threads, algorithms, subroutines, etc.) running in one or more computing devices, and combinations of subsystems and computing elements.

[0058] The vehicle processing system 220 may include a sensor perception layer 222, a camera perception layer 224, a positioning engine layer 226, a map database 228, a map fusion and arbitration layer 230, a route planning layer 232, an operating mode evaluation layer 234, a sensor fusion and road world model (RWM) management layer 236, a motion planning and control layer 238, and a behavior planning and prediction layer 240. Layers 222 to 240 are merely examples of some of the layers in one example configuration of the vehicle processing system 220. In other configurations, other layers may be included, such as additional layers for other perception sensors (e.g., a lidar perception layer, etc.), additional layers for planning and / or control, additional layers for modeling, etc., and / or some of the layers 222 to 240 may be excluded from the vehicle processing system 220. Figure 2B As illustrated by the arrows in , each of the layers 222 to 240 can exchange data, calculation results, and commands.

[0059] In addition, the vehicle processing system 220 can receive and process data from sensors (e.g., cameras, inertial measurement units (IMUs), etc.), navigation information sources (e.g., global positioning system (GPS) receivers, IMUs, etc.), vehicle networks (e.g., controller area network (CAN) buses), and databases in memory (e.g., digital maps or HD map data).

[0060] The vehicle processing system 220 may output vehicle control commands or signals to an autonomous driving system (ADS) vehicle control unit 242 , which is a system, subsystem, or computing device that interfaces directly with the vehicle's steering, throttle, and brake controls. Figure 2A The configuration of the vehicle processing system 220 and the ADS vehicle control unit 242 illustrated in FIG. 1 is merely an example configuration, and other configurations of the vehicle management system and other vehicle components may be used. As an example, Figure 2B The configuration of the vehicle processing system 220 and the ADS vehicle control unit 242 illustrated in FIG. 2 may be used in a vehicle configured for autonomous or semi-autonomous operation, while a different configuration may be used in a non-autonomous vehicle.

[0061] The sensor perception layer 222 may receive data from one or more detection and ranging sensors and process the data to identify and determine the location of other vehicles and objects in the vicinity of the vehicle 102. The sensor perception layer 222 may include the use of neural network processing and artificial intelligence methods to identify objects and vehicles and pass such information to the sensor fusion and RWM management layer 236.

[0062] The camera perception layer 224 may receive data from one or more cameras, such as cameras, and process the data to identify and determine the location of other vehicles and objects in the vicinity of the vehicle 102. The camera perception layer 224 may include the use of neural network processing and artificial intelligence methods to identify objects and vehicles and pass such information to the sensor fusion and RWM management layer 236.

[0063] The positioning engine layer 226 may receive data from the sensor sensing layer 222, the camera sensing layer 224, and various navigation information sources, and process the data and information to determine the location of the vehicle 102. The various navigation information sources may include, but are not limited to, a GPS receiver, an IMU, and / or other sources and sensors connected via a CAN bus. The positioning engine layer 226 may also utilize input from one or more cameras (such as cameras and / or any other available sensors capable of identifying and determining the direction and distance to objects in the vicinity of the vehicle).

[0064] According to various embodiments, the vehicle processing system 220 may include or be coupled to the vehicle processing system 104. One or more of the layers 222 through 240 may provide information to or receive information from the vehicle processing system 104. The vehicle processing system 104 may be configured to communicate with a highway communication system, such as via a V2X communication link (e.g., 124) and / or with a remote information source (e.g., computing device 132) via a cellular wireless communication link (e.g., 122), such as via a 5G cellular network.

[0065] The map fusion and arbitration layer 230 may access the map database 228 to obtain location information about nearby objects and features, and receive positioning / navigation information output from the positioning engine layer 226 , and process the data to further determine the location of the vehicle 102 in the map, such as the location within a lane, the location within a street map, etc. The sensor data may be stored in a memory (e.g., memory 312 ).

[0066] Similar to the location information of some map objects and features, as well as sensor accuracy and precision, GPS positioning includes some errors. Therefore, the map fusion and arbitration layer 230 can be used to determine a best-guess position of the vehicle within the road based on arbitration between GPS coordinates, sensor data, and map data regarding objects and features in and near the road. For example, while GPS coordinates may place the vehicle near the middle of a two-lane road in the sensor data, the map fusion and arbitration layer 230 may determine that the vehicle is most likely aligned with a lane of travel consistent with the direction of travel based on the direction of travel. The map fusion and arbitration layer 230 may pass the arbitrated map position information to the sensor fusion and RWM management layer 236.

[0067] The route planning layer 232 can utilize sensor data and input from an operator or dispatcher to plan a route to be followed by the vehicle 102 to a specific destination. The route planning layer 232 can pass map-based location information to the sensor fusion and RWM management layer 236. However, other layers (such as the sensor fusion and RWM management layer 236) are not required to use a priori maps. For example, other stacks can operate and / or control the vehicle based solely on sensory data without a provided map, building concepts such as lanes, boundaries, and local maps as the sensory data is received.

[0068] In embodiments including an operating mode evaluation layer 234, the processing layer may use safety and / or confidence information about nearby objects and features to select an appropriate ADS driving mode. In some embodiments, the operating mode evaluation layer 234 may determine whether the current autonomous or semi-autonomous driving mode is consistent or appropriate with respect to nearby objects and features in the driving environment in view of the safety and / or confidence information about nearby objects and features in the driving environment.

[0069] The sensor fusion and RWM management layer 236 may receive data and outputs generated by the sensor perception layer 222, the camera perception layer 224, the map fusion and arbitration layer 230, the route planning layer 232, and the operating mode evaluation layer 234, and use some or all of such inputs to estimate or refine the position and state of the vehicle 102 relative to the road, other vehicles on the road, and other objects in the vicinity of the vehicle 102. For example, the sensor fusion and RWM management layer 236 may combine image data from the camera perception layer 224 with arbitration map position information from the map fusion and arbitration layer 230 to refine the determined position of the vehicle within the traffic lane. As another example, the sensor fusion and RWM management layer 236 may combine object recognition and image data from the camera perception layer 224 with object detection and ranging data from the sensor perception layer 222 to determine and refine the relative position of other vehicles and objects in the vicinity of the vehicle. As another example, the sensor fusion and RWM management layer 236 can receive information about the location and direction of travel of other vehicles from V2X communications (such as via a CAN bus) and combine this information with information from the sensor perception layer 222 and the camera perception layer 224 to refine the location and motion of the other vehicles. The sensor fusion and RWM management layer 236 can output the refined location and state information of the vehicle 102 and the refined location and state information of other vehicles and objects in the vicinity of the vehicle to the motion planning and control layer 238 and / or the behavior planning and prediction layer 240.

[0070] As a further example, the sensor fusion and RWM management layer 236 can use dynamic traffic control instructions to direct the vehicle 102 to change speed, lane, direction of travel, or other navigation elements, and combine this information with other received information to determine refined position and state information. The sensor fusion and RWM management layer 236 can output the refined position and state information of the vehicle 102 and the refined position and state information of other vehicles and objects in the vicinity of the vehicle 102 via wireless communication (such as through a C-V2X connection, other wireless connections, etc.) to the motion planning and control layer 238, the behavior planning and prediction layer 240, and / or devices remote from the vehicle 102, such as data servers, other vehicles, etc.

[0071] As yet another example, the sensor fusion and RWM management layer 236 can monitor perception data from various sensors (such as perception data from the sensor perception layer 222, the camera perception layer 224, other perception layers, etc.) and / or data from one or more sensors themselves to analyze conditions in the vehicle sensor data. The sensor fusion and RWM management layer 236 can be configured to detect conditions in the sensor data, such as sensor measurements being at, above, or below thresholds, the occurrence of certain types of sensor measurements, etc., and can output the sensor data as part of refined position and state information of the vehicle 102 that is provided to the behavior planning and prediction layer 240 and / or devices remote from the vehicle 102 (such as data servers, other vehicles, etc.) via wireless communication (such as through a C-V2X connection, other wireless connections, etc.).

[0072] The behavior planning and prediction layer 240 of the autonomous vehicle processing system 220 can use the refined position and state information of the vehicle 102, as well as the position and state information of other vehicles and objects output from the sensor fusion and RWM management layer 236, to predict the future behavior of other vehicles and / or objects. For example, the behavior planning and prediction layer 240 can use this information to predict the future relative positions of other vehicles based on the host vehicle's position and velocity, as well as the positions and velocities of other vehicles in its vicinity. Such predictions can take into account information from map data and route planning to anticipate changes in the relative vehicle positioning of the host vehicle and other vehicles along the road. The behavior planning and prediction layer 240 can output the other vehicle and object behavior and position predictions to the motion planning and control layer 238.

[0073] Additionally, the behavior planning and prediction layer 240 can use object behavior in conjunction with position predictions to plan and generate control signals for controlling the motion of the vehicle 102. For example, based on route planning information, detailed positions in road information, and the relative positions and motions of other vehicles, the behavior planning and prediction layer 240 can determine that the vehicle 102 needs to change lanes and accelerate, such as to maintain or achieve a minimum spacing with other vehicles and / or to prepare for a turn or exit. As a result, the behavior planning and prediction layer 240 can calculate or otherwise determine the steering angle of the wheels and the change to the throttle setting, which will be commanded to the motion planning and control layer 238 and the ADS vehicle control unit 242, along with various such parameters necessary to implement such lane changes and accelerations. One such parameter can be the calculated steering wheel command angle.

[0074] The motion planning and control layer 238 may receive data and information output from the sensor fusion and RWM management layer 236, map data from the map database 232, and other vehicle and object behavior and position predictions from the behavior planning and prediction layer 240, and use this information to plan and generate control signals for controlling the motion of the vehicle 102, and verify that such control signals meet the safety requirements of the vehicle 102. For example, based on the route planning information, the refined position in the road information, and the relative position and motion of other vehicles, the motion planning and control layer 238 may verify and pass various control commands or instructions to the ADS vehicle control unit 242.

[0075] The ADS vehicle control unit 242 may receive commands or instructions from the motion planning and control layer 238 and convert such information into mechanical control signals for controlling the wheel angles, brakes, and throttle of the vehicle 102. For example, the ADS vehicle control unit 242 may respond to a calculated steering wheel command angle by transmitting a corresponding control signal to a steering wheel controller.

[0076] In various embodiments, the vehicle processing system 104 can communicate with other vehicle processing system participants (e.g., other vehicles, roadside units, etc.) via wireless communication links to transmit sensor data, positioning data, vehicle data, and data collected by onboard sensors about the environment surrounding the vehicle. Other vehicle processing system participants can use this information to update stored sensor data for relay to other vehicle processing system participants.

[0077] In various embodiments, the vehicle processing system 220 may include functionality for performing safety checks or oversight of various commands, plans, or other decisions at various levels that may affect vehicle and occupant safety. Such safety checks or oversight functionality may be implemented within a dedicated layer or distributed across various layers and included as part of the functionality. In some embodiments, various safety parameters may be stored in memory, and the safety checks or oversight functionality may compare determined values ​​(e.g., relative spacing from nearby vehicles, distance from the road centerline, etc.) to corresponding safety parameters and issue warnings or commands if a safety parameter is or will be violated. For example, a safety or oversight function in the behavior planning and prediction layer 240 (or in a separate layer) may determine the current or future separation distance between the vehicle and another vehicle (as defined by the sensor fusion and RWM management layer 236) (e.g., based on a world model refined by the sensor fusion and RWM management layer 236), compare the separation distance to a safe separation distance parameter stored in memory, and issue a command to the motion planning and control layer 238 to accelerate, decelerate, or turn if the current or predicted separation distance violates the safe separation distance parameter. As another example, safety or supervisory functionality in the motion planning and control layer 238 (or in a separate layer) may compare a determined or commanded steering wheel command angle to a safe wheel angle limit or parameter and issue an override command and / or alert in response to the commanded angle exceeding the safe wheel angle limit.

[0078] Some safety parameters stored in memory may be static (i.e., do not change over time), such as maximum vehicle speed. Other safety parameters stored in memory may be dynamic, in that they are continuously or periodically determined or updated based on vehicle status information and / or environmental conditions. Non-limiting examples of safety parameters include: maximum safe speed, maximum brake pressure, maximum acceleration, and safe wheel angle limits, all of which may vary with road and weather conditions.

[0079] Figure 3 is a block diagram illustrating example components of a system on a chip (SOC) 300 suitable for use in a vehicle processing system according to various embodiments. Figures 1A to 3 The processing device SOC 300 may include several heterogeneous processors, such as a digital signal processor (DSP) 303, a modem processor 304, an image and object recognition processor 306, a mobile display processor 307, an application processor 308, and a resource and power management (RPM) processor 317. The processing device SOC 300 may also include one or more coprocessors 310 (e.g., vector coprocessors) connected to one or more of the heterogeneous processors 303, 304, 306, 307, 308, 317.

[0080] Each of these processors may include one or more cores and an independent / internal clock. Each processor / core may perform operations independently of the other processors / cores. For example, the processing device SOC 300 may include a processor that executes a first type of operating system (e.g., FreeBSD, LINUX, OS X, etc.) and a processor that executes a second type of operating system (e.g., Microsoft Windows). In some embodiments, the application processor 308 may be the main processor of the SOC 300, a central processing unit (CPU), a microprocessor unit (MPU), an arithmetic logic unit (ALU), etc. The graphics processor 306 may be a graphics processing unit (GPU).

[0081] The processing device SOC 300 may include analog and custom circuits 314 for managing sensor data, analog-to-digital conversion, wireless data transmission, and for performing other specialized operations, such as processing encoded audio and video signals for rendering in a web browser. The processing device SOC 300 may also include system components and resources 316, such as voltage regulators, oscillators, phase-locked loops, peripheral bridges, data controllers, memory controllers, system controllers, access ports, timers, and other similar components for supporting the processor and software clients (e.g., web browsers) running on the computing device.

[0082] The processing device SOC 300 may also include dedicated circuitry for camera actuation and management (CAM) 305, which includes, provides, controls, and / or manages the operation of one or more cameras (e.g., a main camera, a web camera, a 3D camera, etc.), video display data from camera firmware, image processing, video pre-processing, a video front end (VFE), embedded JPEG, a high-definition video codec, etc. The CAM 305 may be an independent processing unit and / or include an independent or internal clock.

[0083] In some embodiments, the image and object recognition processor 306 may be configured with processor-executable instructions and / or specialized hardware configured to perform the image processing and object recognition analysis described in various embodiments. For example, the image and object recognition processor 306 may be configured to process images received from a camera via the CAM 305 to recognize and / or identify other vehicles, as well as otherwise perform the functions of the camera perception layer 224 as described. In some embodiments, the processor 306 may be configured to process external sensor data and perform the functions of the sensor perception layer 222 as described.

[0084] System components and resources 316, analog and custom circuits 314, and / or CAM 305 may include circuitry for interfacing with peripheral devices such as cameras, external sensors, electronic displays, wireless communication devices, external memory chips, and the like. Processors 303, 304, 306, 307, 308 may be interconnected to one or more memory elements 312, system components and resources 316, analog and custom circuits 314, CAM 305, and RPM processor 317 via an interconnect / bus module 324, which may include a reconfigurable logic gate array and / or implement a bus architecture (e.g., CoreConnect, AMBA, etc.). Communication may be provided by an advanced interconnect, such as a high-performance network-on-chip (NoC).

[0085] The processing device SOC 300 may further include an input / output module (not shown) for communicating with resources external to the SOC, such as a clock 318 and a voltage regulator 320. Resources external to the SOC (e.g., clock 318, voltage regulator 320) may be shared by two or more internal SOC processors / cores (e.g., DSP 303, modem processor 304, graphics processor 306, application processor 308, etc.).

[0086] In some embodiments, the processing device SOC 300 may be included in a control unit (e.g., 140) for use in a vehicle (e.g., 100). The control unit may include communication links for communicating with a telephone network (e.g., 180), the Internet, and / or a network server (e.g., 184), as described.

[0087] The processing device SOC 300 may also include additional hardware and / or software components suitable for collecting sensor data from sensors, including motion sensors (e.g., accelerometers and gyroscopes of an IMU), user interface elements (e.g., input buttons, touch screen displays, etc.), microphone arrays, sensors for monitoring physical conditions (e.g., position, direction, motion, orientation, vibration, pressure, etc.), cameras, compasses, GPS receivers, communication circuits (e.g., Bluetooth ® , WLAN, WiFi, etc.) and other well-known components of modern electronic devices.

[0088] Figure 4A is a message flow diagram illustrating a method 400a for handling HD map data messages according to various embodiments. Figures 1A to 4AThe various operations of method 400a may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of vehicle processing system 402 or network computing device 404. The various operations of method 400a may be implemented in a software processing module executed in the vehicle computing device, in a dedicated hardware module within the vehicle, or in a combination of software processing modules and dedicated hardware modules that constitute vehicle processing system 402 or network computing device 404.

[0089] Vehicle processing system 402 may send a request for HD map data to network computing device 404 via communication network 406. In some embodiments, the HD map data request may include or be included in a connection request (e.g., a UDP connection request). In some embodiments, vehicle processing system 402 may start a timer after sending the HD map data request. In response to determining that the timer expired before receiving the HD map data message, vehicle processing system 402 may send a second request for HD map data to network computing device 404.

[0090] The network computing device 404 may receive the HD map data request and, in response, may send one or more HD map data messages in a sequence (e.g., n, n+1, n+2, etc.) via the communication network 406. Due to various conditions in the communication network 406, including routing and network paths traveled by the HD map data messages, network congestion, etc., the vehicle processing system 402 may receive the HD map data messages in a different order than the sequence in which they were sent (i.e., out of sequence). For example, the vehicle processing system 402 may receive the HD map data messages in the order n+2, n, n+1, etc.

[0091] Figure 4B is a block diagram illustrating a method 400b for handling HD map data messages according to various embodiments. Figures 1A to 4B The various operations of method 400b may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of vehicle processing system 420 or network computing device 404. Vehicle processing system 420 may include a communication module 422, a decoding module 424, and a reconstruction module 426. Communication module 422, decoding module 424, and reconstruction module 426 may be configured to perform the various operations of method 400b and may be implemented in a software processing module executed in the vehicle computing device, in a dedicated hardware module within the vehicle, or in a combination of software processing modules and dedicated hardware modules comprising vehicle processing system 420. In some embodiments, vehicle processing system 420 may include an electronic horizon reconstructor (EHR).

[0092] In various embodiments, an HD map data message 440 may be received by the communication module 422 within the vehicle processing system 420. The communication module 422 may store the HD map data message 440 and the first memory queue 430 and / or the second memory queue 432, as further described herein. The decoding module 424 may perform operations to obtain the HD map data message 440 stored in the first memory queue 430 and / or the second memory queue 432. The decoding module 424 may perform operations to decode the information in the HD map data message and may send the decoded map information 444 to the reconstruction module 426. The reconstruction module 426 may use the decoded map information to perform operations to reconstruct a data structure, such as an HD map 446. The reconstruction module may send the reconstructed HD map 446 as output to one or more vehicle systems (e.g., an ADS, ADAS, or other suitable systems), which may use the HD map 446 to perform vehicle operations, such as planning, maneuvering, or another suitable vehicle operation.

[0093] Figure 4C is a block diagram illustrating a first memory queue 450 and a second memory queue 452 configured to handle HD map data messages according to various embodiments. Figures 1A to 4C The various operations of method 400b may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of vehicle processing system 420 or network computing device 404. First memory queue 450 and second memory queue 452 may be implemented in a software processing module executed in a vehicle computing device in the vehicle processing system (e.g., 104, 200, 402, 420), in a dedicated hardware module within the vehicle, or in a combination of software processing modules and dedicated hardware modules comprising the vehicle processing system.

[0094] In some embodiments, the vehicle processing system may receive an HD map data message configured (e.g., by a network computing device) with sequence information, such as a sequence number indicating the sequence of the HD map data message. The first memory queue 450 may be configured to receive and store the HD map data messages in the order in which they were received, which may not be the order in which the messages were sent, e.g., with sequence information n, n+3, n+2, n+1, etc. Furthermore, the first memory queue 450 may receive and store copies of the HD map data messages (e.g., two HD map data messages with sequence information n+1). In some embodiments, the first memory queue 450 may be configured to process the HD map data messages in a first-in, first-out (FIFO) manner.

[0095] In some embodiments, the second memory queue 452 may be configured as a priority queue that processes (handles, uses) sequence information in each HD map data message as an indication of the priority for storing the HD map data message in the second memory queue 452. In some embodiments, the second memory queue 452 may be configured to store the HD map data messages in a priority order of highest priority first (e.g., lowest sequence number first) to lowest priority last (e.g., highest sequence number last). For example, the second memory queue 452 may store received HD map data messages in the priority order n, n+1, n+2, n+3, and so on. In some embodiments, the vehicle processing system may be configured to process or handle the HD map data messages in the second memory queue 452 in a priority order from highest priority to lowest priority.

[0096] 5A to 5I is a block diagram illustrating memory operations 500a-500i that may be performed by a processor of a vehicle processing system for handling HD map data messages in a message queue, according to some embodiments. Figures 1A to 5I Memory operations 500a-500i may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of a vehicle processing system (e.g., 104, 200, 402, 420) that implements a first memory queue (e.g., 450) and a second memory queue (e.g., 452). The first memory queue 450 and the second memory queue 452 may be implemented in a software processing module executed in a vehicle computing device within the vehicle processing system, in a dedicated hardware module within the vehicle, or in a combination of software processing modules and dedicated hardware modules that constitute the vehicle processing system.

[0097] In operation 500a, the vehicle processing system may receive a plurality of HD map data messages, each including sequence information (e.g., 0, 3, 2, 1, 1), in first memory queue 450. In some embodiments, the vehicle processing system may first determine whether second priority queue 452 stores any HD map data messages. In response to determining that second priority queue 452 does not store any HD map data messages, the vehicle processing system may determine whether first memory queue 450 stores any messages. In some embodiments, the vehicle processing system may repeat the determination of whether second priority queue 452 and / or first priority queue 450 store any HD map data messages.

[0098] In operation 500b, the vehicle processing system may handle (obtain, process) the first HD map data message stored in the first memory queue 450. In some embodiments, the vehicle processing system may determine sequence information for the first HD map data message. In some embodiments, the vehicle processing system may set expected sequence information (e.g., an expected sequence number) in a data structure or in memory. In some embodiments, the expected sequence information may be represented as expected_seq_no or another suitable tag, string, information element, etc. In some embodiments, the expected sequence information may represent the sequence information that the vehicle processing system expects in the next HD map data message after the first HD map data message. For example, if the sequence information in the first HD map data message is "0", the vehicle processing system may determine the expected sequence information to be n+1, which in this case is "1".

[0099] In operation 500c, the vehicle processing system may process (obtain, process) the next HD map data message from the first memory queue 450. In some embodiments, in response to determining that no HD map data message is stored in the second memory queue 452, the vehicle processing system may process the next HD map data message from the first memory queue 450. The vehicle processing system may determine sequence information (e.g., "3") in the next HD map data message. In some embodiments, the vehicle processing system may compare the determined sequence information of the next HD map data message with expected sequence information. In response to determining that the expected sequence information is less than the determined sequence information of the next HD map data message (e.g., 1 < 3), the vehicle processing system may store the next HD map data message in the second memory queue 452.

[0100] In operation 500d, the vehicle processing system may process (obtain, process) the next HD map data message from the first memory queue 450. In some embodiments, in response to determining that the second memory queue 452 does not store an HD map data message that matches the expected sequence information, the vehicle processing system may process the next HD map data message from the first memory queue 450. The vehicle processing system may determine sequence information (e.g., "2") in the next HD map data message. In some embodiments, the vehicle processing system may compare the determined sequence information of the next HD map data message with the expected sequence information. In response to determining that the expected sequence information is less than the determined sequence information of the next HD map data message (e.g., 1 < 2), the vehicle processing system may store the next HD map data message in the second memory queue 452. The second memory queue 452 now stores two HD map data messages, one with sequence information "3" and one with sequence information "2." The second memory queue 452 is configured to store the HD map data message with sequence information "2," even though it was processed after the HD map data message with sequence information "3." In this way, the second memory queue 452 stores the HD map data messages according to their corresponding sequence information. In some embodiments, the second memory queue 452 may be configured to treat the HD map data message sequence information as priority information for the HD map data messages.

[0101] In operation 500e, the vehicle processing system may process (obtain, process) the next HD map data message from the first memory queue 450. In some embodiments, in response to determining that the second memory queue 452 does not store an HD map data message that matches the expected sequence information, the vehicle processing system may process the next HD map data message from the first memory queue 450. The vehicle processing system may determine sequence information (e.g., "1") in the next HD map data message. The vehicle processing system may compare the determined sequence information of the next HD map data message with the expected sequence information. In response to determining that the sequence information of the next HD map data message matches the expected sequence information (e.g., 1=1), the vehicle processing system may process the next HD map data message from the first memory queue 450. The vehicle processing system may increment or update the expected sequence information (e.g., to "2").

[0102] In operation 500f, in response to determining that the second memory queue 452 is storing an HD map data message that matches the expected sequence information (e.g., 2=2), the vehicle processing system may handle (obtain, process) the next HD map data message from the second memory queue 452. The vehicle processing system may increment or update the expected sequence information (e.g., to "3").

[0103] In operation 500g, in response to determining that the second memory queue 452 is storing an HD map data message that matches the expected sequence information (e.g., 3=3), the vehicle processing system may handle (obtain, process) the next HD map data message from the second memory queue 452. The vehicle processing system may increment or update the expected sequence information (e.g., to "4").

[0104] In operation 500h, the vehicle processing system may process (obtain, process) the next HD map data message from the first memory queue 450. In some embodiments, in response to determining that the second memory queue 452 does not store an HD map data message that matches the expected sequence information, the vehicle processing system may process the next HD map data message from the first memory queue 450. The vehicle processing system may determine sequence information (e.g., "1") in the next HD map data message. In some embodiments, the vehicle processing system may compare the determined sequence information of the next HD map data message with the expected sequence information. In response to determining that the sequence information is less than the expected sequence information (e.g., 1 < 4), the vehicle processing system may discard (delete, ignore, refrain from processing) the next HD map data message.

[0105] In operation 500i, in some embodiments, the vehicle processing system may be configured to perform operations to address scenarios where neither the sequence information in the HD map data messages stored in the first memory queue 450 nor the sequence information in the second memory queue 452 matches the expected sequence information. For example, the HD map data message may be lost in transmission from the network computing device to the vehicle processing system. In some embodiments, the vehicle processing system may start a timer after receiving one or more HD map data messages in the first memory queue 450. In such embodiments, the vehicle processing system may reset the timer each time the vehicle processing system determines that the sequence information of the HD map data messages stored in the second memory queue 452 or the first memory queue 450 matches the expected sequence information.

[0106] If an HD map data message has been lost in transmission, the vehicle processing system may be unable to find an HD map data message in first memory queue 450 or second memory queue 452 with sequence information that matches the expected sequence information. For example, the expected sequence information may be "4," but second memory queue 452 stores HD map data messages with sequence information "5," "6," "7," "8," ..., "99," and first memory queue 450 stores HD map data messages with sequence information "100," "101," "102," and so on. The HD map data message with sequence information "4" has been lost in transmission. To avoid the scenario where the vehicle processing system waits indefinitely for lost packets, the vehicle processing system may start a timer after receiving one or more HD map data messages in first memory queue 450. In response to determining that the sequence information of an HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information before the timer expires, the vehicle processing system may select (obtain and process) an HD map data message with sequence information that matches the expected sequence information and reset the timer.

[0107] In response to the second timer expiring before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information, the vehicle processing system may determine that the HD map data message with sequence information "4" has been lost. The vehicle processing system may increment or increase the expected sequence information to the next sequence information after the lost HD map data message (e.g., increment or increase to "5"). The vehicle processing system may then determine whether the second memory queue 452 stores an HD map data message with sequence information that matches the expected sequence information, as further described above. For example, the vehicle processing system may determine that an HD map data message with sequence information "5" that matches the expected sequence information (e.g., 5=5) is stored in the second memory queue 452, and the vehicle processing system may handle (obtain, process) the next HD map data message from the second memory queue 452 as described.

[0108] Figure 6A is a process flow diagram of an example method 600a that may be executed by a processor of a vehicle processing system in a vehicle for handling HD map data messages, according to various embodiments. Figures 1A to 6A , the operations of method 600a may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of a vehicle processing system (e.g., 104, 200, 402, 420), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements and is generally referred to as a "processor."

[0109] In block 602 , a processor may receive a plurality of HD map data messages each including sequence information as described in a first memory queue of a processing system via a User Datagram Protocol (UDP).

[0110] In block 604, the processor may determine whether the sequence information of one of the HD map data messages is greater than the expected sequence information, and in response to determining that the sequence information of the selected HD map data message is greater than the expected sequence information, store the selected HD map data message in the second memory queue. In some embodiments, the processor may track the sequence numbers of received HD map data messages (e.g., by buffering each sequence number or incrementing a sequence number counter), verify the sequence information of each received HD map data message, and store any messages whose sequence information is out of sequence in the second memory queue. For example, an HD map data message may be identified as out of sequence when the preceding message in the sequence has not yet been received.

[0111] Also as part of the operations in block 604, the HD map data messages may be stored in a second memory queue in a priority order determined based on a sequence number of each message. In some embodiments, messages with the lowest sequence numbers may be stored in a queue with the highest priority, and messages with higher sequence numbers may be stored in queues with decreasing priorities consistent with increasing sequence numbers.

[0112] In block 606, the processor may process the HD map data message stored in the second memory queue in response to the sequence information of the HD map data message stored in the second memory queue matching the expected sequence information. For example, when the sequence number of the HD map data message stored in the second memory queue matches a sequence number being tracked by the processor, the processor, which is tracking message sequence numbers, may access and use the message, indicating that it is the next message in the sequence.

[0113] Figure 6B is a process flow diagram of an example method 600b executed by a processor of a vehicle processing system in a vehicle for handling HD map data messages, according to various embodiments. Figures 1A to 6B , the operations of method 600b may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of a vehicle processing system (e.g., 104, 200, 402, 420), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements and is generally referred to as a "processor."

[0114] In determination block 610 , the processor may determine whether the second memory queue holds (stores) HD map data messages. For example, the processor may determine whether any messages are stored in the queue, such as by checking the contents of the queue or the memory location of a queue memory pointer.

[0115] In response to determining that the second memory queue stores HD map data messages (i.e., determination block 610 = "Yes"), the processor may obtain (i.e., determine, access) sequence information for the highest priority HD map data message from the second memory queue in block 612. For example, if multiple messages are stored in the second memory queue, the processor may identify the sequence information for the HD map data message with the highest priority (i.e., lowest sequence number) and access that message (e.g., pop the message from the queue memory stack).

[0116] In determination block 614, the processor may determine whether the obtained sequence information for the highest priority message in the second memory queue matches the expected sequence information.

[0117] In response to determining that the obtained sequence information for the highest priority message in the second memory queue matches the expected sequence information (i.e., determination block 614 = "Yes"), in block 616, the processor may process the HD map data message stored in the second memory queue (i.e., the highest priority HD map data message in the second memory queue).

[0118] At block 618, the processor may increment the expected sequence information. For example, the processor may increase the value of the expected sequence number of the HD map data message or other suitable information. For example, after having received the highest priority (lowest sequence number) HD map data message for processing, the processor may update the expected sequence number in a counter that tracks messages processed in sequence to reflect (indicate) that the selected HD map data message has been processed. In some embodiments, the expected sequence information may be set to one greater than the sequence number of the selected HD map data message to indicate that the processor should receive the next message in the sequence.

[0119] In response to determining that the second memory queue does not store an HD map data message (i.e., determination block 610 = "No"), or in response to determining that the sequence information of the highest priority message and the second memory queue does not match the expected sequence information (i.e., determination block 614 = "No"), in determination block 620, the processor may determine whether the first memory queue stores an HD map data message.

[0120] In response to determining that the first memory queue holds HD map data messages (ie, determination block 620 = "No"), the processor may determine whether the second memory queue holds (stores) HD map data messages in determination block 610 as described.

[0121] In response to determining that the first memory queue stores the HD map data message (ie, determination block 620 = "Yes"), in block 622 the processor may obtain (ie, select and access) the HD map data message from the front or top (ie, first-out) of the first memory queue.

[0122] In determination block 624 , the processor may determine whether the sequence information of the HD map data message from the front of the first memory queue matches the expected sequence information.

[0123] In response to determining that the sequence information of the HD map data message from the front of the first memory queue matches the expected sequence information (ie, determination block 624 = "Yes"), in block 626 the processor may process the HD map data message from the front of the first memory queue.

[0124] In block 628, the processor may increment the expected sequence information. For example, the processor may increase the value of the expected sequence number of the HD map data message or other suitable information. For example, after processing the HD map data message from the front of the first memory queue, the processor may update the expected sequence number in a counter that tracks messages processed in sequence order to reflect (indicate) that the selected HD map data message has been processed. In some embodiments, the expected sequence information may be set to one greater than the sequence number of the selected HD map data message to indicate that the processor should receive the next message in the sequence.

[0125] In response to determining that the sequence information of the HD map data message from the front of the first memory queue does not match the expected sequence information (i.e., determination block 624 = "No"), in determination block 630, the processor may determine whether the sequence information of the HD map data message from the front of the first memory queue is greater than the expected sequence information.

[0126] In response to determining that the sequence information of the HD map data message from the front of the first memory queue is greater than the expected sequence information (ie, determination block 630 = “Yes”), in block 632 the processor may store the HD map data message in the second memory queue.

[0127] In response to determining that the sequence information of the HD map data message from the front of the first memory queue is not greater than the expected sequence information (ie, determination block 630 = "No"), in block 634 the processor may discard (ignore, avoid processing) the HD map data message.

[0128] In response to determining that the first memory queue does not store the HD map data message (i.e., determination block 620 = "No"), or after completing the operations in blocks 618, 628, 632, or 634, the processor may repeat the operations of determination block 610 and repeat the operations of method 600b as described.

[0129] Figure 6C is a process flow diagram of example operations 600c that may be performed by a processor of a vehicle processing system in a vehicle as part of the method 600a or 600b for handling HD map data messages, according to various embodiments. Figures 1A to 6C , operation 600c may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of a vehicle processing system (e.g., 104, 200, 402, 420), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements and is generally referred to as a "processor."

[0130] In block 640 , the processor may send a request for HD map data to a network computing device (eg, network computing device 404 ) that is configured to provide HD map data.

[0131] In block 642, the processor may start a timer.

[0132] In determination block 644 , the processor may determine whether the timer expired before the processor received the HD map data message.

[0133] In response to determining that the timer did not expire before the processor received the HD map data message (i.e., determination block 644 = "No"), in block 646 the processor may store the received HD map data message(s) in the first memory queue and then perform the operations of block 624 of method 600b as described.

[0134] In response to the timer expiring before the processor receives the HD map data message (ie, determination block 644 =“Yes”), in block 648 , the processor may send a second request for HD map data to the network computing device.

[0135] In block 650 , the processor may increment a maximum request counter.

[0136] In determination block 652 , the processor may determine whether a maximum request counter has reached a limit, such as a maximum number of requests.

[0137] In response to determining that the maximum request counter has not reached the limit (ie, determination block 652 = "No"), the processor may send another request for HD map data to the network computing device in block 640 as described.

[0138] In response to determining that the maximum request counter has reached a limit (ie, determination block 652 = "Yes"), in block 654 the processor may determine that connection establishment with the network computing device has failed, thereby enabling the processor to perform operations for reestablishing a connection to the network.

[0139] Figure 6D is a process flow diagram of example operations 600d that may be performed by a processor of a vehicle processing system in a vehicle as part of methods and operations 600a, 600b, and / or 600c for handling HD map data messages, according to some embodiments. Figures 1A to 6D , operation 600d may be performed by a processor (e.g., 207, 303, 304, 306, 307, 308, 310) of a vehicle processing system (e.g., 104, 200, 402, 420), which may be implemented in hardware elements, software elements, or a combination of hardware and software elements and is generally referred to as a "processor."

[0140] In some embodiments, the vehicle processing system may be configured to perform operations to address a scenario in which neither the sequence information in the HD map data message stored in the first memory queue (e.g., 450) nor the sequence information in the second memory queue (e.g., 452) matches the expected sequence information. This may occur, for example, when the HD map data message is lost or irrecoverably corrupted in transmission from the network computing device to the vehicle processing system.

[0141] In block 646 , the processor may store the received HD map data message in a first memory queue in a manner similar to the operations in block 604 of method 600 a as described.

[0142] In block 660 , the processor may start a timer (in some implementations, a second timer).

[0143] In determination block 662 , the processor may determine whether the timer expires before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information.

[0144] In response to determining that the timer has not expired when the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information (i.e., determination box 662 = "No"), the processor may continue to monitor the timer and perform the operations of determination box 662 as described.

[0145] In response to the timer expiring before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information (i.e., determination block 662 = "Yes"), the processor may determine that the HD map data message has been lost in block 664. In some embodiments, the processor may determine that the HD map data message having sequence information that matches the expected sequence information has been lost.

[0146] In block 666, the processor may increment or otherwise increase the expected sequence information. For example, the processor may increment or update the expected sequence number so that the processor expects to receive the next message in the sequence, thereby skipping the lost message.

[0147] The processor may restart another timer in block 660 and perform the operations in determination blocks 662 , 664 , and 666 until an HD map data message with the expected sequence information is received, thereby skipping lost messages until in-sequence order message reception is reestablished.

[0148] Specific implementations are described in the following paragraphs. While some of the following specific implementations are described in terms of example methods, further example implementations may include: the example methods discussed in the following paragraphs implemented by a vehicle processing system, which may be an onboard unit, a mobile device unit, or a mobile computing unit or a network computing device, the vehicle processing system including a processor configured with processor-executable instructions to perform the operations of the methods of the following specific implementations; the example methods discussed in the following paragraphs implemented by a vehicle processing system including components for performing the functions of the methods of the following specific implementations; and the example methods discussed in the following paragraphs may be implemented on a non-transitory processor-readable storage medium having stored thereon processor-executable instructions configured to cause a processor of the vehicle processing system to perform the operations of the methods of the following specific implementations.

[0149] Embodiment 1. A method for handling high-definition (HD) map data messages by a processing system of a vehicle, the method comprising: receiving a plurality of HD map data messages, each including sequence information, in a first memory queue of the processing system via a user datagram protocol (UDP); storing the selected HD map data messages in a second memory queue in response to determining that the sequence information of a selected HD map data message among the HD map data messages is greater than expected sequence information; and processing the HD map data messages stored in the second memory queue in response to the sequence information of the HD map data messages stored in the second memory queue matching the expected sequence information.

[0150] Example 2. According to the method described in Example 1, the method also includes: determining whether the second memory queue stores HD map data messages; and in response to determining that the second memory queue stores HD map data messages, determining whether the HD map data messages stored in the second memory queue match the expected sequence information.

[0151] Example 3. According to the method described in Example 2, the method also includes: processing the HD map data message stored in the first memory queue in response to determining that the second memory queue does not store the HD map data message or determining that the sequence information of the HD map data message stored in the second memory queue does not match the expected sequence information.

[0152] Example 4. According to the method described in any one of Examples 1 to 3, the method further includes: discarding the selected HD map data message in response to determining that the sequence information of the selected HD map data message in the HD map data message is less than the expected sequence information.

[0153] Example 5. A method according to any one of Examples 1 to 4, wherein receiving the multiple HD map data messages each including sequence information in the first memory queue of the processing system via UDP includes: sending a request for HD map data to an electronic horizon provider; and receiving the multiple HD map data messages in response to the request for the HD map data.

[0154] Example 6. According to the method described in any one of Examples 1 to 5, the method further includes: starting a first timer after sending a request for the HD map data to a network computing device configured to provide HD map data; and sending a second request for HD map data to the network computing device in response to the first timer expiring before receiving the HD map data message.

[0155] Example 7. A method according to any one of Examples 1 to 6, the method further comprising: starting a second timer after receiving the multiple HD map data messages in the first memory queue of the processing system; and determining that the HD map data message has been lost in response to the second timer expiring before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information.

[0156] Example 8. A method according to any one of Examples 1 to 7, wherein the second memory queue includes a priority queue, and the sequence information of each HD map data message in the HD map data message stored in the second memory queue is processed as priority information of each HD map data message in the HD map data message stored in the second memory queue.

[0157] The various embodiments illustrated and described are provided merely as examples illustrating various features of the claims. However, the features shown and described with respect to any given embodiment are not necessarily limited to that associated embodiment and may be used or combined with other embodiments shown and described. Furthermore, the claims are not intended to be limited to any one exemplary embodiment. For example, one or more operations of a method may be substituted for or combined with one or more operations of a method.

[0158] The foregoing method descriptions and process flow diagrams are provided as illustrative examples only and are not intended to require or imply that the operations of the various embodiments must be performed in the order given. As will be appreciated by those skilled in the art, the order of operations in the foregoing embodiments may be performed in any order. Words such as "thereafter," "then," "next," etc. are not intended to limit the order of operations; these words are merely used to guide the reader through the description of the method. In addition, any reference to a claim element in the singular (e.g., a reference using the articles "a," "an," or "the") should not be construed as limiting the element to the singular.

[0159] The various illustrative logical blocks, modules, circuits, and algorithmic operations described in conjunction with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or a combination of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and operations have been generally described above in terms of their functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the overall system. Although a skilled person may implement the described functionality in different ways for each specific application, such specific implementation decisions should not be interpreted as causing a departure from the scope of the claims.

[0160] The hardware for implementing the various illustrative logics, logic blocks, modules, and circuits described in conjunction with the embodiments disclosed herein may be implemented or executed using a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field programmable gate array (FPGA), or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. Although a general-purpose processor may be a microprocessor, in an alternative embodiment, the processor may be any conventional processor, controller, microcontroller, or state machine. The processor may also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, one or more microprocessors combined with a DSP core, or any other such configuration. Alternatively, some operations or methods may be performed by circuits specific to a given function.

[0161] In one or more embodiments, the described functions may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, these functions may be stored as one or more instructions or code on a non-transitory computer-readable medium or a non-transitory processor-readable medium. The operations of the methods or algorithms disclosed herein may be embodied in a processor-executable software module, which may reside on a non-transitory computer-readable or processor-readable storage medium. A non-transitory computer-readable or processor-readable storage medium may be any storage medium that can be accessed by a computer or processor. By way of example, and not limitation, such non-transitory computer-readable or processor-readable media may include RAM, ROM, EEPROM, flash memory, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to store desired program code in the form of instructions or data structures and that can be accessed by a computer. As used herein, disk and optical disk include compact disc (CD), laser disc, optical disc, digital versatile disc (DVD), floppy disk, and Blu-ray disc, where disks typically reproduce data magnetically, while optical discs reproduce data optically with lasers. Combinations of the above are also included within the scope of non-transitory computer-readable and processor-readable media. Additionally, the operations of a method or algorithm may reside as one or any combination or set of codes and / or instructions on a non-transitory processor-readable medium and / or computer-readable medium, which may be incorporated into a computer program product.

[0162] The above description of the disclosed embodiments is provided to enable any person skilled in the art to make or use the claims. Various modifications to these embodiments will be apparent to those skilled in the art, and the general principles defined herein may be applied to other embodiments without departing from the scope of the claims. Thus, the present disclosure is not intended to be limited to the embodiments shown herein, but should be accorded the broadest scope consistent with the following claims and the principles and novel features disclosed herein.

Claims

1. A method for processing a high-definition (HD) map data message by a processing system of a vehicle, the method comprising: receiving a plurality of HD map data messages each including sequence information in a first memory queue of the processing system via a user datagram protocol (UDP); storing the selected ones of the HD map data messages in a second memory queue in response to determining that the sequence information of the selected ones of the HD map data messages is greater than expected sequence information; as well as The HD map data messages stored in the second memory queue are processed in response to the sequence information of the HD map data messages stored in the second memory queue matching the expected sequence information.

2. The method according to claim 1, further comprising: determining whether the second memory queue stores an HD map data message; as well as In response to determining that the second memory queue holds HD map data messages, it is determined whether the HD map data messages stored in the second memory queue match the expected sequence information.

3. The method according to claim 2, further comprising: The HD map data messages stored in the first memory queue are processed in response to determining that the second memory queue does not hold an HD map data message or determining that the sequence information of the HD map data messages stored in the second memory queue does not match the expected sequence information.

4. The method according to claim 1, further comprising: The selected HD map data message is discarded in response to determining that the sequence information of the selected one of the HD map data messages is less than the expected sequence information.

5. The method of claim 1 , wherein receiving the plurality of HD map data messages, each including sequence information, in the first memory queue of the processing system via UDP comprises: Sending a request for HD map data to the electronic horizon provider; as well as The plurality of HD map data messages are received in response to the request for the HD map data.

6. The method according to claim 1, further comprising: starting a first timer after sending a request for the HD map data to a network computing device configured to provide the HD map data; as well as A second request for HD map data is sent to the network computing device in response to the first timer expiring before receiving the HD map data message.

7. The method according to claim 1, further comprising: starting a second timer after receiving the plurality of HD map data messages in the first memory queue of the processing system; as well as An HD map data message is determined to have been lost in response to the second timer expiring before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information.

8. The method according to claim 1, wherein the second memory queue includes a priority queue, and the sequence information of each HD map data message in the HD map data messages stored in the second memory queue is processed as the priority information of each HD map data message in the HD map data messages stored in the second memory queue.

9. A vehicle processing system, comprising: A processor configured with processor-executable instructions to: receiving a plurality of HD map data messages each including sequence information in a first memory queue of the processing system via a user datagram protocol (UDP); storing the selected ones of the HD map data messages in a second memory queue in response to determining that the sequence information of the selected ones of the HD map data messages is greater than expected sequence information; as well as The HD map data messages stored in the second memory queue are processed in response to the sequence information of the HD map data messages stored in the second memory queue matching the expected sequence information.

10. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions to: determining whether the second memory queue stores HD map data messages; and In response to determining that the second memory queue holds HD map data messages, it is determined whether the HD map data messages stored in the second memory queue match the expected sequence information.

11. The vehicle processing system of claim 10 , wherein the processor is further configured with processor-executable instructions to process the HD map data message stored in the first memory queue in response to determining that the second memory queue does not hold an HD map data message or determining that the sequence information of the HD map data message stored in the second memory queue does not match the expected sequence information.

12. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions to discard the selected one of the HD map data messages in response to determining that the sequence information of the selected one of the HD map data messages is less than the expected sequence information.

13. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions to: Sending a request for HD map data to an electronic horizon provider; and The plurality of HD map data messages are received in response to the request for the HD map data.

14. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions to: starting a first timer after sending a request for the HD map data to a network computing device configured to provide the HD map data; and A second request for HD map data is sent to the network computing device in response to the first timer expiring before receiving the HD map data message.

15. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions to: starting a second timer after receiving the plurality of HD map data messages in the first memory queue of the processing system; and An HD map data message is determined to have been lost in response to the second timer expiring before the sequence information of the HD map data message stored in either the first memory queue or the second memory queue matches the expected sequence information.

16. The vehicle processing system of claim 9, wherein the processor is further configured with processor-executable instructions such that the second memory queue includes a priority queue, and the sequence information of each of the HD map data messages stored in the second memory queue is processed as priority information of each of the HD map data messages stored in the second memory queue.

17. A vehicle processing system, comprising: means for receiving, via a user datagram protocol (UDP), in a first memory queue of the processing system, a plurality of HD map data messages each including sequence information; means for storing a selected one of the HD map data messages in a second memory queue in response to determining that the sequence information of the selected one of the HD map data messages is greater than expected sequence information; and Means for processing the HD map data messages stored in the second memory queue in response to the sequence information of the HD map data messages stored in the second memory queue matching the expected sequence information.

18. The vehicle processing system of claim 17, further comprising: means for determining whether the second memory queue stores an HD map data message; and Means for determining whether the HD map data message stored in the second memory queue matches the expected sequence information in response to determining that the second memory queue holds HD map data messages.

19. The vehicle processing system of claim 18, further comprising a component for processing the HD map data message stored in the first memory queue in response to determining that the second memory queue does not store an HD map data message or determining that the sequence information of the HD map data message stored in the second memory queue does not match the expected sequence information.

20. The vehicle processing system of claim 17, further comprising means for discarding the selected one of the HD map data messages in response to determining that the sequence information of the selected one of the HD map data messages is less than the expected sequence information.

21. The vehicle processing system of claim 17, wherein the means for receiving the plurality of HD map data messages each including sequence information in the first memory queue of the processing system via UDP comprises: means for sending a request for HD map data to an electronic horizon provider; and Means for receiving the plurality of HD map data messages in response to the request for the HD map data.

22. The vehicle processing system of claim 17, further comprising: means for starting a first timer after sending a request for the HD map data to a network computing device configured to provide the HD map data; and Means for sending a second request for HD map data to the network computing device in response to the first timer expiring before receiving an HD map data message.

23. The vehicle processing system of claim 17, further comprising: means for starting a second timer after receiving the plurality of HD map data messages in the first memory queue of the processing system; and Means for determining that an HD map data message has been lost in response to the second timer expiring before the sequence information of the HD map data messages stored in either the first memory queue or the second memory queue matches the expected sequence information.

24. The vehicle processing system according to claim 17, wherein the second memory queue includes a priority queue, and the sequence information of each of the HD map data messages stored in the second memory queue is processed as the priority information of each of the HD map data messages stored in the second memory queue.

25. A non-transitory processor-readable medium having processor-executable instructions stored thereon, the processor-executable instructions configured to cause a processing device in a vehicle processing system to perform operations comprising: receiving a plurality of HD map data messages each including sequence information in a first memory queue of the processing system via a user datagram protocol (UDP); storing the selected ones of the HD map data messages in a second memory queue in response to determining that the sequence information of the selected ones of the HD map data messages is greater than expected sequence information; as well as The HD map data messages stored in the second memory queue are processed in response to the sequence information of the HD map data messages stored in the second memory queue matching the expected sequence information.

26. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processing device in the vehicle processing system to perform operations further comprising: determining whether the second memory queue stores an HD map data message; as well as In response to determining that the second memory queue holds HD map data messages, it is determined whether the HD map data messages stored in the second memory queue match the expected sequence information.

27. The non-transitory processor-readable medium of claim 26, wherein the stored processor-executable instructions are further configured to cause the processing device in the vehicle processing system to perform operations further comprising: The HD map data messages stored in the first memory queue are processed in response to determining that the second memory queue does not hold an HD map data message or determining that the sequence information of the HD map data messages stored in the second memory queue does not match the expected sequence information.

28. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processing device in the vehicle processing system to perform operations further comprising: The selected HD map data message is discarded in response to determining that the sequence information of the selected one of the HD map data messages is less than the expected sequence information.

29. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processing device in the vehicle processing system to perform operations such that receiving the plurality of HD map data messages, each including sequence information, in the first memory queue of the processing system via UDP comprises: Sending a request for HD map data to the electronic horizon provider; as well as The plurality of HD map data messages are received in response to the request for the HD map data.

30. The non-transitory processor-readable medium of claim 25, wherein the stored processor-executable instructions are further configured to cause the processing device in the vehicle processing system to perform operations further comprising: starting a first timer after sending a request for the HD map data to a network computing device configured to provide the HD map data; as well as A second request for HD map data is sent to the network computing device in response to the first timer expiring before receiving the HD map data message.

Images