System and method for managing data relay attacks

Abstract

The invention provides a system and a method for managing data relay attacks. A method includes causing a first roadside unit to broadcast one or more messages to one or more vehicles; determining, by an infrastructure-side algorithm, whether the one or more messages received by the second roadside unit match the one or more messages broadcast by the first roadside unit; and causing the one or more vehicles to initiate one or more remedial actions in response to determining that the one or more messages received by the second roadside unit do not match the one or more messages broadcast by the first roadside unit within the predefined time range.

Description

Technical Field

[0001] The present disclosure relates to identification, detection, and communication of data relay attacks. Background Art

[0002] The statements in this section merely provide background information related to the present disclosure and may not constitute prior art.

[0003] A relay attack, or replay attack, is a variation of a man-in-the-middle attack that causes the duplication or delay of valid data transmission between one or more devices. In a vehicle network setting, replay attacks typically target communications between a vehicle's onboard unit and a roadside unit. When this type of replay attack occurs, the originating device associated with the replay attack will be able to authenticate itself at a later time, unbeknownst to the roadside unit or vehicle. Furthermore, mitigating the effects of a replay attack is difficult for any vehicle or roadside unit because they cannot recognize that they are under attack.

[0004] The present disclosure addresses these and other problems related to identification, detection, and communication of relay attacks. Summary of the Invention

[0005] This section provides a general summary of the disclosure and is not a comprehensive disclosure of its full scope or all of its features.

[0006] The present disclosure provides a method comprising: causing a first roadside unit, by an infrastructure controller, to broadcast one or more messages to one or more vehicles; determining, by an algorithm associated with the infrastructure controller, whether one or more messages received by a second roadside unit matches one or more messages broadcast by the first roadside unit; and causing the one or more vehicles, by the infrastructure controller, to initiate one or more remedial actions in response to determining that the one or more messages received by the second roadside unit do not match the one or more messages broadcast by the first roadside unit within a predefined time range; the method further comprising: causing the second roadside unit, by the infrastructure controller, to verify the one or more messages, wherein the second roadside unit is configured to receive the one or more messages based on the location of the first roadside unit, and wherein the verification of the one or more messages is based on matching the one or more messages with one or more decontamination operation scenarios defined by a channel busy rate; wherein the one or more remedial actions include: triggering a global operation pause of all vehicles in one or more vehicles; triggering a subset of one or more vehicles suspending regional operations; identifying one or more target vehicles among one or more vehicles; or triangulating the location of a third party via one or more received signal strength indicator triangulation methods, wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device; the method further includes: causing one or more instructions to be transmitted to one or more roadside units by an algorithm, wherein the one or more roadside units include at least a first roadside unit and a second roadside unit; and the method further includes: causing one or more roadside units to randomly change a data rate associated with each of the one or more roadside units based on the one or more instructions; causing one or more roadside units to isolate and identify replayed data associated with one or more messages broadcast by the first roadside unit based on the one or more instructions; or causing one or more roadside units to isolate and identify the location of a third party, wherein the identification of the location of the third party is based on the signal strength of the one or more roadside units, and wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

[0007] The present disclosure provides another method, the method comprising: predicting, via a probabilistic analysis, that data associated with one or more messages broadcast by one or more roadside units is corrupted, wherein the prediction is implemented by an algorithm associated with a vehicle controller; and initiating, by the vehicle controller, one or more remedial actions in response to predicting that data associated with one or more messages broadcast by one or more roadside units is corrupted; the method further comprising: determining, by the vehicle controller, whether the one or more messages broadcast from the vehicle match a broadcast history associated with the vehicle; the method further comprising: initiating, by the vehicle controller, one or more remedial actions in response to determining that the one or more messages broadcast from the vehicle do not match the broadcast history; wherein the one or more remedial actions comprise: triggering a suspension of operation of the vehicle; transmitting an alarm to A central server, a vehicle manufacturing cloud system, one or more operators, or a combination thereof; or adjusting one or more outgoing data patterns associated with one or more messages broadcast from a vehicle, wherein the one or more outgoing data patterns include data rate, ProSe per-packet priority, modulation and coding scheme, packet size, or a combination thereof; wherein the one or more outgoing data patterns are cross-referenced against one or more messages broadcast from the vehicle; and further comprising: identifying one or more messages broadcast by one or more neighboring vehicles, wherein the one or more messages broadcast by the one or more neighboring vehicles include a change in data rate, a jump in signal strength, or a combination thereof; and transmitting an alert to the central server based on the identification of the one or more messages broadcast by the one or more neighboring vehicles.

[0008] The present disclosure provides a system comprising: an infrastructure controller configured to: cause a first roadside unit to broadcast one or more messages to one or more vehicles; determine, by an algorithm associated with the infrastructure controller, whether one or more messages received by a second roadside unit match the one or more messages broadcast by the first roadside unit; and cause the one or more vehicles to initiate a first set of remedial actions in response to determining that the one or more messages received by the second roadside unit do not match the one or more messages broadcast by the first roadside unit within a predefined time range; and a vehicle controller configured to: predict, via a probabilistic analysis, a match between the one or more messages broadcast by the one or more roadside units and the vehicle; data associated with one or more messages broadcast by one or more roadside units is damaged, wherein the prediction is made by an algorithm associated with the vehicle controller; and a second set of remedial actions is initiated in response to the prediction that data associated with one or more messages broadcast by one or more roadside units is damaged; wherein the infrastructure controller is further configured to: cause a second roadside unit to verify the one or more messages, wherein the second roadside unit is configured to receive the one or more messages based on the location of the first roadside unit, and wherein the verification of the one or more messages is based on the one or more messages matching one or more purge operation scenarios defined by the channel busy rate; wherein the first set of remedial actions includes: triggering a global suspension of operations for all of the one or more vehicles; triggering a sub- the suspension of regional operations of the set; identifying one or more target vehicles among the one or more vehicles; or triangulating the position of a third party via one or more received signal strength indicator triangulation methods, wherein the third party is a roadside unit, an onboard unit associated with the vehicle, or a mobile device; wherein the infrastructure controller is further configured to: cause one or more instructions to be transmitted to the one or more roadside units by an algorithm associated with the infrastructure controller, wherein the one or more roadside units include at least a first roadside unit and a second roadside unit; wherein the infrastructure controller is further configured to: cause the one or more roadside units to randomly change data associated with each of the one or more roadside units based on the one or more instructions; based on a one or more instructions to cause one or more roadside units to isolate and identify relayed data associated with one or more messages broadcast by a first roadside unit; or to cause one or more roadside units to isolate and identify a location of a third party, wherein the identification of the location of the third party is based on signal strength of the one or more roadside units, and wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device; wherein the vehicle controller is further configured to: determine whether the one or more messages broadcast from the vehicle match a broadcast history associated with the vehicle; and initiating one or more remedial actions in response to determining that the one or more messages broadcast from the vehicle do not match the broadcast history; wherein the second set of remedial actions includes: triggering a stoppage of operation of the vehicle;Transmitting an alert to a central server, a vehicle manufacturing cloud system, one or more operators, or a combination thereof; or adjusting one or more outgoing data patterns associated with one or more messages broadcast from the vehicle, wherein the one or more outgoing data patterns include data rate, ProSe per-packet priority, modulation and coding scheme, packet size, or a combination thereof; wherein the one or more outgoing data patterns are cross-referenced against the one or more messages broadcast from the vehicle; and wherein the vehicle controller is configured to: identify one or more messages broadcast by one or more neighboring vehicles, wherein the one or more messages broadcast by the one or more neighboring vehicles include a change in data rate, a jump in signal strength, or a combination thereof; and transmitting the alert to the central server based on the identification of the one or more messages broadcast by the one or more neighboring vehicles.

[0009] Further areas of applicability will become apparent from the description provided herein.It should be understood that the description and specific examples are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0010] In order that the present disclosure may be better understood, various forms of the present disclosure will now be described by way of example with reference to the accompanying drawings, in which:

[0011] Figure 1 An overall system for vehicle formation according to various embodiments is shown;

[0012] Figure 2A and Figure 2B An example system for marshaling one or more vehicles in the presence of a third party is shown, according to various embodiments;

[0013] Figure 3 shows a process flow associated with the algorithm for detecting the third party shown in FIG. 2 , according to various embodiments;

[0014] Figure 4 is a flow chart illustrating an example method for detecting the third party shown in FIG. 2 , according to various embodiments; and

[0015] Figure 5 is a flow chart illustrating another example method for detecting the third party shown in FIG. 2 , according to various embodiments.

[0016] The drawings described herein are for illustration purposes only and are not intended to limit the scope of the present disclosure in any way. DETAILED DESCRIPTION

[0017] The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses. It should be understood that throughout the drawings, corresponding reference numerals indicate like or corresponding parts and features.

[0018] The present disclosure provides for identification of data replay attacks (e.g., data relay attacks) in situations where one or more autonomous vehicles are being grouped. For example, the disclosed systems and methods provide one or more processes for enhancing one or more responses to replay attacks transmitted from one or more malicious devices. As another example, once a replay attack is detected, the originating device can be isolated and / or identified based at least on a received signal strength indicator (RSSI). As yet another example, the disclosed systems and methods further provide implementable mitigation measures when a replay attack is detected. As another example, the disclosed systems and methods allow for use of device activity history as a basis for distinguishing between unintentionally misconfigured devices and intentional malicious devices to make such distinctions. For example, the disclosed systems and methods also prevent interruptions to operating processes (such as production lines), which prevents unnecessary stops in the manufacturing process. Additionally, one or more disclosed systems and methods enhance the robustness of grouping by promptly mitigating any potential malicious replay attacks.

[0019] Figure 1 A schematic block diagram of an autonomous vehicle marshaling (AVM) system 100 is shown. In one or more examples, the AVM system 100 marshals one or more autonomous vehicles traveling at a low speed. However, it should be understood that the AVM system 100 can marshal one or more vehicles traveling at any speed. It should also be understood that the AVM system 100 can marshal semi-autonomous vehicles and / or fully autonomous vehicles.

[0020] The AVM system 100 generally includes a vehicle manufacturing cloud system 102, a vehicle delivery manager cloud system 104, a vehicle customer website portal account cloud system 106, an infrastructure system 108, and one or more autonomous vehicles 110. The vehicle manufacturing cloud system 102 operates as a central cloud system that manages and / or facilitates any manufacturing processes associated with the autonomous vehicle 110. The vehicle manufacturing cloud system 102 communicates wirelessly with the vehicle delivery manager cloud system 104 and the infrastructure system 108. The vehicle manufacturing cloud system 102 also communicates wirelessly directly with the autonomous vehicle 110. One or more examples provide for enhanced detection of malicious actor devices within a fleet setting utilizing one or more of the described systems. For example, the malicious actor device may be a third party, which may be, but is not limited to, a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

[0021] The vehicle manufacturing cloud system 102 includes an AVM algorithm 112a. The AVM algorithm 112a processes state information associated with at least the autonomous vehicle 110. It should be understood that the AVM algorithm 112a processes state information associated with each of the one or more autonomous vehicles (e.g., autonomous vehicle 110). The vehicle manufacturing cloud system 102 is configured to cause the infrastructure system 108 to monitor the progress of each of the one or more autonomous vehicles as they progress through an environment (e.g., a manufacturing facility or a parking lot). The vehicle manufacturing cloud system 102 is also configured to cause the infrastructure system 108 to communicate with any of the one or more autonomous vehicles. For example, the vehicle manufacturing cloud system 102 utilizes the AVM algorithm 112a to send instructions to the infrastructure system 108 and / or process information received from the infrastructure system 108. The vehicle manufacturing cloud system 102 is configured to cause the vehicle delivery manager cloud system 104 to facilitate the delivery of the one or more autonomous vehicles to various locations. For example, the vehicle manufacturing cloud system 102 utilizes the AVM algorithm 112 a to send instructions to the vehicle delivery manager cloud system 104 and / or process information received from the vehicle delivery manager cloud system 104 .

[0022] Vehicle manufacturing cloud system 102 is also configured to cause one or more autonomous vehicles to start, stop, or pause their progress through, for example, an environment. Vehicle manufacturing cloud system 102 is also configured to control the formation speed of each of the one or more autonomous vehicles as they traverse, for example, an environment. In some examples, vehicle manufacturing cloud system 102 utilizes AVM algorithm 112a to send instructions to autonomous vehicles 110 and / or process information received from autonomous vehicles 110.

[0023] The infrastructure system 108 includes an AVM algorithm 112b, one or more sensors 114, and a sensor component 116. The sensor component 116 provides communication between the one or more infrastructure systems and the one or more autonomous vehicles. For example, the sensor component 116 may utilize GPS, Wi-Fi, satellite, 3G / 4G / 5G, and / or Bluetooth. TMto communicate with one or more autonomous vehicles. The sensor component 116 also communicates with one or more sensors 114 (such as, for example, one or more of a camera, a lidar, a radar, and / or an ultrasonic device). As the autonomous vehicle traverses the environment, the one or more sensors 114 monitor the movement of each of the one or more autonomous vehicles. As an example, the infrastructure system 108 utilizes the AVM algorithm 112b to process information and send the information to the vehicle manufacturing cloud system 102 and / or process information received from the vehicle manufacturing cloud system 102. As another example, the infrastructure system 108 utilizes the AVM algorithm 112b to process information and send the information directly to the autonomous vehicle 110 and / or process information received from the autonomous vehicle 110. It should be understood that the infrastructure system 108 can forward instructions received from the vehicle manufacturing cloud system 102 to the autonomous vehicle 110. However, it should also be understood that the infrastructure system 108 can send instructions directly to the autonomous vehicle 110.

[0024] In addition, the infrastructure system 108 includes an infrastructure controller 118. The infrastructure controller 118 is configured to centrally control the operation of the autonomous vehicle 110. For example, the operation of the autonomous vehicle 110 includes propulsion, braking, and steering of the autonomous vehicle 110. It should be understood that the infrastructure controller 118 can be disposed within the infrastructure system 108 or externally relative to the infrastructure system 108. For example, in a marshaling environment (e.g., the manufacturing environment 200), the infrastructure system 108 wirelessly broadcasts marshaling infrastructure messages to the autonomous vehicles 110. As another example, the marshaling infrastructure messages are broadcast via a vehicle-to-everything (V2X) protocol. However, it should be understood that any communication means (including any communication protocol) can be used to broadcast the marshaling infrastructure messages.

[0025] Autonomous vehicle 110 includes one or more systems or components that implement or use AVM algorithm 112c, wireless transmission module 120, vehicle central gateway module 122, vehicle infotainment system 124, one or more vehicle sensors 126, vehicle battery 128, vehicle global navigation satellite system (GNSS) 130, vehicle navigation map 132, and vehicle CAN bus 134. Wireless transmission module 120 may be a transmission control unit. Wireless transmission module 120 includes one or more sensors configured to collect data and send signals to other components of autonomous vehicle 110. The one or more sensors of wireless transmission module 120 may include a vehicle speed sensor (not shown) configured to determine the current speed of autonomous vehicle 110; a wheel speed sensor (not shown) configured to determine whether autonomous vehicle 110 is traveling uphill or downhill; a throttle position sensor (not shown) configured to determine whether a downshift or upshift of one or more gears associated with autonomous vehicle 110 is required given the current state of autonomous vehicle 110; and / or a turbine speed sensor (not shown) configured to transmit data associated with the speed of the torque converter of autonomous vehicle 110. Wireless transmission module 120 transmits information obtained by the one or more sensors to AVM algorithm 112c. For example, autonomous vehicle 110 utilizes AVM algorithm 112c to process the information collected by the one or more sensors and transmits the information to infrastructure system 108. As another example, autonomous vehicle 110 utilizes AVM algorithm 112c to process the information obtained by the one or more sensors and transmits the information directly to vehicle manufacturing cloud system 102. The AVM algorithm 112 c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the wireless transmission module 120 .

[0026] The vehicle central gateway module 122 operates as an interface between various vehicle domain bus systems, such as an underhood bus (not shown), an internal bus (not shown), an optical bus for multimedia (not shown), a diagnostic bus for maintenance (not shown), or the vehicle CAN bus 134. The vehicle central gateway module 122 is configured to distribute data transmitted to the vehicle central gateway module 122 by each of the various domain bus systems to other components of the autonomous vehicle 110. The vehicle central gateway module 122 is also configured to distribute information received from the AVM algorithm 112c to the various domain bus systems. The vehicle central gateway module 122 is also configured to send the information received from the various domain bus systems to the AVM algorithm 112c. For example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process the information received from the vehicle central gateway module 122 and send the information to the infrastructure system 108. As another example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process the information received from the vehicle central gateway module 122 and send the information directly to the vehicle manufacturing cloud system 102. The AVM algorithm 112 c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the vehicle central gateway module 122 .

[0027] The vehicle infotainment system 124 is a system that delivers a combination of information and entertainment content and / or services to the operator 146 of the autonomous vehicle 110. It should be understood that in some examples, the vehicle infotainment system 124 can deliver entertainment content to the operator 146 of the autonomous vehicle 110. It should also be understood that in some examples, the vehicle infotainment system 124 can deliver information services to the operator 146 of the autonomous vehicle 110. In one or more examples, the vehicle infotainment system 124 includes an onboard vehicle computer that combines one or more functions, such as a digital radio, a built-in camera, and / or a television. The vehicle infotainment system 124 transmits information associated with the onboard vehicle computer or processor to the AVM algorithm 112c. For example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process information received from the vehicle infotainment system 124 and transmits the information to the infrastructure system 108. As another example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process information received from the vehicle infotainment system 124 and transmits the information directly to the vehicle manufacturing cloud system 102. The AVM algorithm 112 c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the vehicle infotainment system 124 .

[0028] One or more vehicle sensors 126 may be, for example, one or more of a camera, a lidar, a radar, and / or an ultrasonic device. For example, an ultrasonic device used as one or more vehicle sensors 126 transmits high-frequency sound waves that strike an object (e.g., a wall or another vehicle) and are then reflected back to autonomous vehicle 110. Based on the amount of time it takes for the sound waves to return to autonomous vehicle 110, autonomous vehicle 110 can determine the distance between one or more vehicle sensors 126 and the object. As another example, a camera device used as one or more vehicle sensors 126 provides a visual indication of the space surrounding autonomous vehicle 110. As an additional example, a radar device used as one or more vehicle sensors 126 transmits an electromagnetic wave signal that strikes an object and is then reflected back to autonomous vehicle 110. Based on the amount of time it takes for the electromagnetic wave to return to autonomous vehicle 110, autonomous vehicle 110 can determine the range, speed, and angle of autonomous vehicle 110 relative to the object.

[0029] The one or more vehicle sensors 126 transmit information associated with the position and / or distance of the autonomous vehicle 110 relative to the object to the AVM algorithm 112 c. For example, the autonomous vehicle 110 utilizes the AVM algorithm 112 c to process the information received from the one or more vehicle sensors 126 and transmit the information to the infrastructure system 108. As another example, the autonomous vehicle 110 utilizes the AVM algorithm 112 c to process the information received from the one or more vehicle sensors 126 and transmit the information to the vehicle manufacturing cloud system 102. The AVM algorithm 112 c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the one or more vehicle sensors 126.

[0030] The vehicle battery 128 is controlled by a battery management system (not shown) that provides instructions to the vehicle battery 128. For example, the battery management system provides instructions to the vehicle battery 128 based on the temperature of the vehicle battery 128. The battery management system ensures that the current pattern of the vehicle battery 128 is acceptable. For example, the acceptable current pattern prevents overvoltage, overcharging, and / or overheating of the vehicle battery 128. As another example, the temperature of the vehicle battery 128 indicates to the battery management system whether any of the acceptable current patterns is within an acceptable temperature range. The battery management system associated with the vehicle battery 128 transmits information associated with the temperature of the vehicle battery 128 to the AVM algorithm 112c. For example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process the received information about the vehicle battery 128 and transmits the information to the infrastructure system 108. As another example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process the information about the vehicle battery 128 and transmits the information directly to the vehicle manufacturing cloud system 102. The AVM algorithm 112 c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the vehicle battery 128 .

[0031] Vehicle GNSS 130 is configured to communicate with satellites, allowing autonomous vehicle 110 to determine its specific location. Vehicle navigation map 132 can display the specific location of autonomous vehicle 110 to operator 146 via a display screen (not shown). Vehicle GNSS 130 transmits geographic information associated with autonomous vehicle 110 to AVM algorithm 112c. For example, autonomous vehicle 110 utilizes AVM algorithm 112c to process information received from vehicle GNSS 130 and transmit the information to infrastructure system 108. As another example, autonomous vehicle 110 utilizes AVM algorithm 112c to process information from vehicle GNSS 130 and transmit the information directly to vehicle manufacturing cloud system 102. AVM algorithm 112c is configured to transmit information and / or instructions received from infrastructure system 108 and / or vehicle manufacturing cloud system 102 to vehicle GNSS 130. As another example, autonomous vehicle 110 utilizes AVM algorithm 112c to process information associated with vehicle navigation map 132 and transmit the information to infrastructure system 108. As another example, the autonomous vehicle 110 utilizes the AVM algorithm 112c to process information from the vehicle navigation map 132 and send the information directly to the vehicle manufacturing cloud system 102. The AVM algorithm 112c is configured to transmit information and / or instructions received from the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to the vehicle navigation map 132.

[0032] The vehicle delivery manager cloud system 104 wirelessly communicates (e.g., receives and / or sends instructions and / or information) with one or more of the rental organization cloud system 136, the valet parking organization cloud system 138, the insurance organization cloud system 140, and / or the dealership 142. For example, the vehicle delivery manager cloud system 104 can facilitate the delivery of one or more autonomous vehicles to any of the rental organization cloud system 136, the valet parking organization cloud system 138, the insurance organization cloud system 140, and / or the dealership 142. The vehicle delivery manager cloud system 104 also wirelessly communicates with the vehicle customer website portal account cloud system 106. It should be understood that in one or more examples, other cloud systems may be included.

[0033] The vehicle delivery manager cloud system 104 wirelessly communicates with a user device 144, such as a mobile device, display panel, and / or computer. Autonomous vehicle 110 also wirelessly communicates directly with user device 144. Autonomous vehicle 110 is, for example, configured to process information and / or instructions received from user device 144. For example, operator 146 interacts with user device 144 via an application that organizes any information and / or instructions received from vehicle customer website portal account cloud system 106 and / or autonomous vehicle 110. As another example, operator 146 may send one or more instructions to vehicle customer website portal account cloud system 106, such as selecting which vehicle operator 146 would like to receive from any of a rental agency (not shown) associated with rental agency cloud system 136, a valet parking agency (not shown) associated with valet parking agency cloud system 138, an insurance agency (not shown) associated with insurance agency cloud system 140, and / or dealership 142.

[0034] Figure 2AAn example manufacturing environment 200 is shown that facilitates interaction (e.g., communicative coupling) between one or more autonomous vehicles 202a-202d (e.g., autonomous vehicle 110) and one or more infrastructure systems 204a-204e (e.g., infrastructure system 108). For example, manufacturing environment 200 is located within or associated with a manufacturing plant. Typically, an AVM central server edge 206 (e.g., an edge processor) is connected to one or more roadside units (RSUs) 208a-208c and operates in a functionally similar manner to infrastructure controller 118 (e.g., AVM central server edge 206 effectively extends the available coverage area of ​​infrastructure controller 118). For example, AVM central server edge 206 is connected to one or more RSUs 208a-208c via wireless, wired, or a combination thereof. AVM central server edge 206 is also connected to one or more infrastructure systems 204a-204e. For example, AVM central server edge 206 is connected to one or more infrastructure systems 204a-204e via wireless, wired, or a combination thereof. As an example, the AVM central server edge 206 is configured to receive one or more signals from one or more RSUs 208a - 208c and / or from one or more infrastructure systems 204a - 204e while communicating with the vehicle manufacturing cloud system 102 .

[0035] The AVM central server edge 206 is configured to determine the location of any one of the one or more autonomous vehicles 202a-202d using sensor data received from the one or more infrastructure systems 204a-204e. Each of the one or more infrastructure systems 204a-204e includes a set of infrastructure sensors 210 (e.g., one or more sensors 114), such as, for example, a two-dimensional (2D) camera, a three-dimensional (3D) camera, an infrared sensor, a radar scanner, a laser scanner, a light detection and ranging (LiDAR) sensor, an ultrasonic sensor, etc. As the one or more autonomous vehicles 202a-202d move through the environment, the set of infrastructure sensors 210 monitors the movement of each of the one or more autonomous vehicles 202a-202d, also as combined with the vehicle's location. Figure 1 described.

[0036] In one or more examples, sensor data is generated based on the type of monitoring being performed by the set of infrastructure sensors 210 (e.g., the movement of each of the one or more autonomous vehicles 202a-202d or the environment itself). In one form, one or more infrastructure systems 204a-204e provide pose, route, and obstacle data of the environment to the AVM central server edge 206.

[0037] The AVM central server edge 206 is further configured to facilitate communication between the AVM central server edge 206 and any of the one or more autonomous vehicles 202a-202d using one or more RSUs 208a-208c. The one or more RSUs 208a-208c are equipped with a cellular vehicle-to-infrastructure communication system (referred to as a "CV2X system"). As an example, the one or more RSUs 208a-208c are equipped with PC5-based CV2X that employs radio frequency (RF) sidelink communication to achieve low-latency vehicle sensor connectivity.

[0038] Each of the one or more RSUs 208a-208c is configured to receive one or more infrastructure-side data packets from the AVM central server edge 206. Generally, each of the one or more RSUs 208a-208c may include various components for performing the operations described herein, such as, but not limited to, transceivers, processor circuits, memory circuits, routers, and / or input / output interface hardware. For example, the one or more infrastructure-side data packets may include one or more instructions, one or more signals, or a combination thereof. Each of the one or more RSUs 208a-208c is further configured to broadcast the one or more infrastructure-side data packets to any of the one or more autonomous vehicles 202a-202d within range of the one or more RSUs 208a-208c. As another example, the one or more infrastructure-side data packets are generated based on one or more parking control infrastructure messages (PCIMs). As another example, each of the one or more RSUs 208a-208c is configured to broadcast one or more infrastructure-side data packets via one or more wireless communication protocols (such as a CV2X protocol, private and / or public cellular protocols, a Wi-Fi protocol, a long-range (LoRA) signal protocol, a Bluetooth protocol, and / or a UWB protocol).

[0039] Each of the one or more RSUs 208a-208c is further configured to receive one or more vehicle-side data packets including one or more parking control vehicle messages (PCVMs) from any of the one or more autonomous vehicles 202a-202d. Each of the one or more RSUs 208a-208c is further configured to forward the one or more vehicle-side data packets to the AVM central server edge 206.

[0040] Figure 2A2. Further shown in FIG. 2 are multiple workstations 212a-212d. Each of the multiple workstations 212a-212d represents various assembly points in a manufacturing facility. For example, each of the multiple workstations 212a-212d can specifically correspond to (e.g., be associated with) one or more specific infrastructure systems in the one or more infrastructure systems 204a-204e. As an example, infrastructure system 204a corresponds to workstation 212a. As another example, infrastructure system 204b corresponds to workstation 212b. As an additional example, infrastructure systems 204c and 204d correspond to workstation 212c. As yet another example, infrastructure system 204e corresponds to workstation 212d. It should be understood that multiple systems can correspond to one workstation and / or multiple workstations can correspond to one system, as well as other combinations.

[0041] As one or more autonomous vehicles 202a-202d advance through the environment and pass each of a plurality of workstations 212a-212d, each of the one or more autonomous vehicles 202a-202d receives one or more broadcast grouped messages from the AVM central server edge 206 via one or more RSUs 208a-208c. In the event that a third party 214 is present in the manufacturing environment 200, the third party 214 may also receive one or more broadcast grouped messages transmitted from the AVM central server edge 206. In this particular example, the third party 214 is a malicious actor device. While the third party 214 is depicted as an RSU in FIG2 , it should be understood that the third party may be a different device type or component, such as an onboard unit associated with a vehicle, a mobile device, or any other type of device.

[0042] In various applications, for example, third party 214 can perform one or more variations of a man-in-the-middle attack, in which third party 214 causes one or more broadcast group messages received from AVM central server edge 206 to be manipulated (e.g., altered or modified). Third party 214 is able to manipulate the broadcast group message(s) because third party 214 is configured to intercept the broadcast group message(s) before the broadcast group message(s) are received at one or more autonomous vehicles 202a-202d. It should be understood that third party 214 can use different techniques to intercept or capture the broadcast group message(s).

[0043] Manipulation of the broadcasted one or more grouped messages may occur upon receipt of the broadcasted one or more grouped messages at third party 214. Once the broadcasted one or more grouped messages have been manipulated, third party 214 is configured to broadcast the manipulated one or more messages to one or more autonomous vehicles 202a-202d. As an example, third party 214 may manipulate the broadcasted one or more grouped messages by creating a delay in receiving the broadcasted one or more grouped messages at one or more autonomous vehicles 202a-202d. As another example, third party 214 may manipulate the broadcasted one or more grouped messages by sending duplicate messages that may cause confusion (e.g., difficulty processing the messages) at one or more autonomous vehicles 202a-202d. As an additional example, third party 214 may also broadcast completely different messages to one or more autonomous vehicles 202a-202d.

[0044] Figure 2B An example manufacturing environment 200 is shown that includes an additional RSU operating as a data sniffer device 216. The data sniffer device 216 is configured to wirelessly monitor any broadcast messages transmitted to one or more autonomous vehicles 202a-202d via any RSU within range of the data sniffer device 216. As an example, each of the one or more RSUs 208a-208c and the data sniffer device 216 can be wired to the AVM central server edge as an interconnected backend network. The data sniffer device 216 is also configured to transmit any findings (e.g., intercepted messages or data) to the AVM central server edge 206. For example, the findings are associated with the data sniffer device 216 monitoring any broadcast messages transmitted to the one or more autonomous vehicles 202a-202d. In various examples, data sniffer device 216 is any hardware and / or software that allows for “sniffing” or monitoring data traffic and / or capturing data traffic (e.g., capturing data packets or data streams to and / or from one or more autonomous vehicles 202a-202d).

[0045] The AVM central server edge 206 is configured to receive any findings from the data sniffer device 216. For example, the findings may include data indicating the source of the message, whether the message has any malicious content, the message itself, or a combination thereof. However, it should be understood that the data may indicate any information associated with the message. The AVM central server edge 206 is also configured to communicate with the infrastructure system 108 and / or the vehicle manufacturing cloud system 102 to analyze the findings using an infrastructure-side AVM algorithm (e.g., AVM algorithm 112a and / or 112b). However, it should be understood that the AVM central server edge 206 may have an AVM algorithm disposed therein that may also operate as an infrastructure-side AVM algorithm.

[0046] The infrastructure-side AVM algorithm is configured to verify that data received from the data sniffer device 216 matches a broadcast message originally transmitted by the AVM central server edge 206. By way of example, the infrastructure-side AVM algorithm is further configured to verify that data received from the data sniffer device 216 matches a broadcast message originally transmitted by one or more RSUs 208a-208c. For example, the infrastructure-side AVM algorithm is configured to verify that data received from the data sniffer device 216 matches a broadcast message originally transmitted by the AVM central server edge 206 within a defined time range. By way of example, verifying whether data received from the data sniffer device 216 matches a broadcast message originally transmitted by the AVM central server edge 206 may include, in part, verifying whether the data received from the data sniffer device 216 matches the broadcast message originally transmitted by the AVM central server edge 206. By way of another example, the expected time range represents a time period (e.g., a time period threshold) between when the message is sent from the AVM central server edge 206 for broadcast by one or more RSUs 208a-208c and when the broadcast message is expected to be received by the data sniffer device 216.

[0047] In the event that the infrastructure-side AVM algorithm verifies the presence of a malicious actor device (e.g., third party 214), the infrastructure-side AVM algorithm may cause an alert to be transmitted to the AVM central server edge 206, the vehicle manufacturing cloud system 102, and / or any human operator in the vicinity of the manufacturing environment (e.g., operator 146). For example, verification of the presence of a malicious actor device may be a mismatch between a message sent from the AVM central server edge 206 and a message received at the data sniffer device 216, a delay in the message received at the data sniffer device 216, and / or a completely new message received at the data sniffer device 216 relative to the message sent from the AVM central server edge 206, among other verifications.

[0048] In an example embodiment, the AVM central server edge 206 is configured to generate and / or learn (e.g., using machine learning) channel busy rates (CBRs) for one or more sanitization operation scenarios. By way of example, the one or more sanitization operation scenarios are operations that can be considered normal operations and / or known to be non-malicious. For example, the CBR serves as an RF fingerprint, enabling detection of any replays attached by a malicious actor device (e.g., third party 214). As another example, any broadcast message is compared to the CBR. An infrastructure-side algorithm is configured to compare the CBR with the broadcast message to determine whether the broadcast message matches any of the one or more sanitization operation scenarios. If the infrastructure-side algorithm determines that the CBR and the broadcast message do not match, the broadcast message is considered a detected replay attack. The AVM central server edge 206 may also store information related to the total number of active CV2X radios in the manufacturing environment 200. For example, the AVM central server edge 206 may store the total number of active CV2X radios in the manufacturing environment 200 in a database located locally within the AVM central server edge 206 or external to the AVM central server edge 206. As another example, an active CV2X radio may form part of one or more autonomous vehicles 202a-202d and / or one or more RSUs 208a-208c. However, it should be understood that an active CV2X radio may be provided in, for example, any receiving / transmitting device in the manufacturing environment 200. For example, a CV2X radio associated with any message exchanged between any receiving / transmitting device in the manufacturing environment 200 may be a basis on which an infrastructure-side algorithm may detect a replay attack. As another example, a CV2X radio associated with any message exchanged between any receiving / transmitting device in the manufacturing environment 200 may be used as an input parameter by an infrastructure-side algorithm to identify any changes in the CBR (e.g., caused by a malicious actor device) in any specific area within the manufacturing environment 200 and / or in the manufacturing environment 200 as a whole.

[0049] The infrastructure-side AVM algorithm can deploy one or more preventative measures to mitigate any instances of replay attacks in the manufacturing environment 200. For example, the infrastructure-side AVM algorithm can cause the AVM central server edge to direct one or more RSUs 208a-208c to randomly change the data rate associated with each of the one or more RSUs 208a-208c. For example, randomization of the data rate associated with each of the one or more RSUs 208a-208c helps the infrastructure-side AVM algorithm isolate and / or identify replayed data and / or an associated attacker causing or initiating a replay attack. For example, the AVM central server edge 206 can also randomize the ProSe per-packet priority (PPPP) and / or the modulation and coding scheme (MCS) to help identify an associated attacker causing or initiating a replay attack. Additionally, the infrastructure-side AVM algorithm can narrow down the location of the associated attacker based on the received signal strength of messages identified as replay attacks. For example, the infrastructure-side AVM algorithm can use trilateration to pinpoint the source of a signal associated with a replay attack.

[0050] Regardless of how a replay attack is detected, the infrastructure-side AVM algorithm can cause one or more post-detection measures to be initiated in the event a replay attack is detected. For example, the infrastructure-side AVM algorithm can cause the AVM central server edge 206 to trigger a global operational pause or a regional operational pause of one or more autonomous vehicles 202a-202d. The AVM central server edge 206 can also identify a target vehicle from the one or more autonomous vehicles 202a-202d. In addition, the AVM central server edge 206 can triangulate the location of the associated attacker. For example, the AVM central server edge 206 can utilize interference from the data sniffer device 216, a particular RSU from one or more RSUs 208a-208c that is being attacked, and / or an onboard unit of a vehicle associated with the offending broadcast message to triangulate the location of the associated attacker. As another example, the AVM central server edge 206 can use an RSSI method to triangulate the location of the associated attacker.

[0051] In another example embodiment, each of the one or more autonomous vehicles 202a-202d is further configured to detect any relay attacks. For purposes of explanation and to illustrate an example, the vehicle-side AVM algorithm (e.g., AVM algorithm 112c) of a single autonomous vehicle in the one or more autonomous vehicles 202a-202d is configured to perform a statistical probabilistic analysis of whether any message transmitted and / or received in the manufacturing environment 200 may have been replayed and / or delayed. As another example, the vehicle-side AVM algorithm is configured to monitor PCIM data patterns associated with each of the one or more RSUs 208a-208c. As an additional example, the vehicle-side AVM algorithm's monitoring of PCIM data patterns enables the performance of a probabilistic analysis. However, it should be understood that in some examples, all autonomous vehicles in the one or more autonomous vehicles 202a-202d are configured to utilize corresponding vehicle-side AVM algorithms to perform the probabilistic analysis.

[0052] Each of one or more autonomous vehicles 202a-202d utilizes a corresponding onboard unit (not shown) to detect any malicious messages. For example, the corresponding onboard unit may compare each message transmitted and / or received by any of the one or more autonomous vehicles 202a-202d with a corresponding broadcast history associated with each of the one or more autonomous vehicles 202a-202d. As an example, the broadcast history corresponds to historical messages transmitted and / or received from / to each of the one or more autonomous vehicles 202a-202d.

[0053] Thus, the vehicle-side AVM algorithm can cause one or more post-detection measures to be initiated upon detection of a replayed message. For example, the vehicle-side AVM algorithm can alert the AVM central server edge 206, the vehicle manufacturing cloud system 102, and / or any human operator (e.g., operator 146) of the detected replay attack. As another example, the vehicle-side AVM algorithm can also change the outgoing data rate of any number of messages broadcast by any of one or more autonomous vehicles 202a-202d. As an additional example, the vehicle-side AVM algorithm can also enable triggering a pause in operation of an affected vehicle (e.g., an autonomous vehicle that has received the replayed message). As yet another example, the vehicle-side AVM algorithm can cause the vehicle's corresponding broadcast data pattern (e.g., data rate, PPPP, MCS, and / or packet size) to be transmitted to the AVM central server edge 206, so that the AVM central server edge 206 can cross-reference the received vehicle data pattern against the received PCVM message. For example, the vehicle-side AVM algorithm is configured to identify any statistical anomalies within any message transmitted / received by any nearby (e.g., adjacently located) vehicle.

[0054] As another example, the vehicle-side AVM algorithm is configured to identify statistical anomalies present within messages based on the vehicle-side AVM algorithm monitoring messages transmitted / received by nearby vehicles. As yet another example, the statistical anomaly may include a changed data rate associated with the message, a sudden jump in signal strength associated with the message, or a combination thereof. However, it should be understood that the statistical anomaly may be, for example, any metric associated with the message. As an additional example, the vehicle-side AVM algorithm may provide an audiovisual alert, such as flashing lights of a vehicle, honking a horn of a vehicle, rolling up and / or down windows of a vehicle, or a combination thereof, in the event that a replayed message is detected. However, it should be understood that the vehicle-side AVM algorithm may alert the AVM central server edge 206 of the detected replayed message in any other manner.

[0055] Figure 3 An example communication flow is depicted between the vehicle manufacturing cloud system 102, the AVM central server edge 206, one or more RSUs 208a-208c, a third party 214, a data sniffer device 216, and each of the autonomous vehicle 110. As an example, each of the one or more RSUs 208a-208c, the third party 214, the data sniffer device 216, and the autonomous vehicle 110 has a corresponding AVM algorithm component and a V2X wireless communication component disposed therein that supports communication between each of the third party 214, the data sniffer device 216, and the autonomous vehicle 110.

[0056] The infrastructure-side AVM algorithm supports data integrity for the overall infrastructure associated with manufacturing environment 200 by validating one or more PCIM-related data elements against the original data source derived from AVM central server edge 206. For example, the one or more PCIM-related data elements may be compared to data associated with any message transmitted from AVM central server edge 206 to one or more autonomous vehicles 202a-202d via one or more RSUs 208a-208c. As another example, the one or more PCIM-related data elements may include a vehicle identifier, a message generation time, a rolling counter, a driving permission, a driving command, a control interface, or a combination thereof. As an additional example, the vehicle identifier may be unique to each of the corresponding one or more autonomous vehicles 202a-202d. As yet another example, if the message generation time meets a predefined threshold (e.g., falls below a predefined threshold), the message generation time may indicate the absence of replayed messages. As another example, the rolling counter may reflect a history of random resets in the absence of any replayed messages. As yet another example, in the absence of any replayed messages, the data elements associated with the driving permission may be consistent with past, current, and / or future messages. As yet another example, in the absence of any replayed messages, data elements associated with driving commands will be consistent with past, current, and / or future messages. As an additional example, in the absence of any replayed messages, data elements associated with driving permissions (particularly relating to route segments, direct control of the vehicle, and / or trajectory control of the vehicle) will be consistent with past, current, and / or future messages.

[0057] The vehicle-side AVM algorithm supports data integrity for the overall infrastructure associated with manufacturing environment 200 by validating one or more PCIM-related data elements against the original data source derived from AVM central server edge 206. For example, the one or more PCIM-related data elements may be compared with data associated with any message transmitted from AVM central server edge 206 to one or more autonomous vehicles 202a-202d via one or more RSUs 208a-208c. As another example, the one or more PCIM-related data elements may include a vehicle identifier, a message generation time, a rolling counter, a vehicle state, driving parameters, vehicle parameters, or a combination thereof. As an additional example, the vehicle identifier may be unique to each of the corresponding one or more autonomous vehicles 202a-202d. As yet another example, if the message generation time meets a predefined threshold, the message generation time may indicate the absence of replayed messages. As another example, the rolling counter may reflect a history of random resets in the absence of any replayed messages. As yet another example, in the absence of any replayed messages, data elements associated with the vehicle state may be consistent with past, current, and / or future messages. As an additional example, in the absence of any replayed messages, data elements associated with driving permission (particularly related to speed, curvature, and / or odometer relative to the vehicle) will be consistent with past, current, and / or future messages. As another example, in the absence of any replayed messages, data elements associated with driving permission (particularly related to vehicle feedback, vehicle errors, vehicle debugging, and / or vehicle identification data relative to the vehicle) will be consistent with past, current, and / or future messages.

[0058] Figure 4 4 is a flow chart illustrating an example method 400 for detecting a third party (e.g., third party 214) in a marshaling setting. However, it should be understood that the process described by method 400 can be implemented to detect a third party in any setting. At operation 402, a first roadside unit (e.g., first roadside unit 208a) is caused to broadcast one or more messages. For example, the first roadside unit is caused to broadcast one or more messages to one or more vehicles (e.g., autonomous vehicle 110). As another example, an infrastructure controller (e.g., infrastructure controller 118) causes the first roadside unit to broadcast one or more messages to one or more vehicles.

[0059] At operation 404, a determination is made as to whether one or more messages received by the second roadside unit (e.g., the data sniffer device 216) match one or more messages broadcast by the first roadside unit. For example, the determination of whether one or more messages received by the second roadside unit match one or more messages broadcast by the first roadside unit is made by an algorithm associated with the infrastructure controller (e.g., the AVM algorithm 112b).

[0060] At operation 406, one or more vehicles are caused to initiate one or more remedial actions. For example, in response to determining that one or more messages received by a second roadside unit do not match one or more messages broadcast by a first roadside unit within a predefined time range, the one or more vehicles are caused to initiate one or more remedial actions. It should be understood that in response to determining that one or more messages received by a second roadside unit do not match one or more messages broadcast by a first roadside unit, for example based on any metric and also outside of a time range, the one or more vehicles are caused to initiate one or more remedial actions. As another example, the one or more remedial actions may include: triggering a global pause in operation of all vehicles in the one or more vehicles; triggering a regional pause in operation of a subset of one or more vehicles; identifying one or more target vehicles in the one or more vehicles; triangulating the location of a third party; or a combination thereof. For example, triangulation of the third party is performed via one or more received signal strength indicator triangulation methods. As another example, the third party is a malicious actor device, which may be, but is not limited to, a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

[0061] In an example embodiment, a second roadside unit is caused to verify the one or more messages. For example, the infrastructure controller causes the second roadside unit to verify the one or more messages. As another example, the second roadside unit is configured to receive the one or more messages based on the location of the first roadside unit. In another example embodiment, one or more instructions are caused to be transmitted to one or more roadside units. For example, the one or more roadside units include at least a first roadside unit and a second roadside unit. As another example, verification of the one or more messages is based on matching the one or more messages to one or more decontamination operation scenarios defined by a channel busy rate.

[0062] In yet another example embodiment, one or more roadside units are caused to randomly change data rates. For example, a data rate is associated with each of the one or more roadside units. As another example, the data rate is based on one or more instructions. As yet another example, one or more roadside units are caused to isolate and / or identify the replayed data. As another example, the replayed data is associated with one or more messages broadcast by a first roadside unit based on one or more instructions. As an additional example, one or more roadside units are caused to isolate and / or identify the location of a third party. For example, identification of the third party is based on signal strength of the one or more roadside units.

[0063] Figure 5 is another flow chart illustrating an example method 500 for detecting a third party (e.g., third party 214) in a marshaling setting. However, it should be understood that the process described by method 500 can be implemented to detect a third party in any setting. At operation 502, it is predicted that data associated with one or more messages will be damaged. As an example, it can be determined that the data associated with one or more messages may be damaged. For example, a probabilistic analysis is used to predict the data. As another example, the data is broadcast by one or more roadside units (e.g., one or more roadside units 208a-208c). As an additional example, the prediction is achieved by an algorithm associated with a vehicle controller (e.g., algorithm 112c).

[0064] At operation 504, one or more remedial actions are initiated in response to predicting that data associated with one or more messages broadcast by one or more roadside units is corrupted. For example, the one or more remedial actions are initiated by a vehicle controller. As another example, the one or more remedial actions may include: triggering a pause in operation of the vehicle; transmitting an alert; adjusting one or more outgoing data patterns associated with one or more messages broadcast from the vehicle; or a combination thereof. As an additional example, the alert may be transmitted to a central server (e.g., AVM central server edge 206), a vehicle manufacturing cloud system (e.g., vehicle manufacturing cloud system 102), one or more operators (e.g., 146), or a combination thereof. As another example, the one or more outgoing data patterns may include data rate, PPPP, MCS, packet size, or a combination thereof. As yet another example, the one or more outgoing data patterns are cross-referenced against one or more messages broadcast from the vehicle.

[0065] In an example embodiment, a determination is made as to whether one or more messages broadcast from a vehicle match a broadcast history associated with the vehicle. For example, the determination of whether one or more messages broadcast from a vehicle match the broadcast history associated with the vehicle is made by a vehicle controller. In another example embodiment, one or more remedial actions are initiated in response to a determination that one or more messages broadcast from a vehicle do not match the broadcast history. For example, the initiation of the one or more remedial actions is made by a vehicle controller.

[0066] In yet another example embodiment, one or more messages broadcast by one or more neighboring vehicles are identified. For example, the one or more messages broadcast by one or more neighboring vehicles may include a change in data rate, a jump in signal strength, or a combination thereof. As another example, an alert is transmitted to a central server. As an additional example, an alert is transmitted to a central server based on the identification of one or more messages broadcast by one or more neighboring vehicles.

[0067] Thus, one or more examples of the present disclosure provide a means for identifying, detecting, and / or communicating malicious actor devices via the use of systems and methods implemented by infrastructure-side algorithms and / or vehicle-side algorithms. For example, real-time detection of malicious actor devices allows for rapid isolation of any replayed messages, rapid identification of the source of any replayed messages, and / or efficient mitigation associated with addressing any compromised vehicles.

[0068] Unless otherwise expressly indicated herein, all numerical values ​​indicating mechanical / thermal properties, composition percentages, dimensions and / or tolerances or other characteristics when describing the scope of the present disclosure should be understood as modified by the word "about" or "approximately." Such modification is desirable for various reasons, including: industrial practice; material, manufacturing and assembly tolerances; and testing capabilities.

[0069] As used herein, the phrase at least one of A, B, and C should be construed to mean a logical (A or B or C), using a non-exclusive logical "OR", and should not be construed to mean "at least one of A, at least one of B, and at least one of C."

[0070] In this application, the terms "controller" and / or "module" may refer to, be part of, or include: an application-specific integrated circuit (ASIC); a digital, analog, or mixed analog / digital discrete circuit; a digital, analog, or mixed analog / digital integrated circuit; a combinatorial logic circuit; a field-programmable gate array (FPGA); a processor circuit (shared, dedicated, or group) that executes code; a memory circuit (shared, dedicated, or group) that stores code executed by the processor circuit; other suitable hardware components that provide the described functionality; or a combination of some or all of the above, such as in a system on a chip.

[0071] The term memory is a subset of the term computer-readable medium. The term computer-readable medium, as used herein, does not encompass transient electrical or electromagnetic signals propagated through a medium (such as on a carrier wave); thus, the term computer-readable medium may be considered to be both tangible and non-transitory. Non-limiting examples of non-transitory tangible computer-readable media are non-volatile memory circuits (such as flash memory circuits, erasable programmable read-only memory circuits, or mask read-only circuits), volatile memory circuits (such as static random access memory circuits or dynamic random access memory circuits), magnetic storage media (such as analog or digital magnetic tape or hard drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0072] The apparatus and methods described in this application may be implemented partially or completely by a special-purpose computer created by configuring a general-purpose computer to perform one or more specific functions embodied in a computer program. The functional blocks, flow chart components, and other elements described above serve as software specifications that can be translated into a computer program through routine work by a technician or programmer.

[0073] The description of the present disclosure is merely exemplary in nature and, thus, variations that do not depart from the essence of the disclosure are intended to be within the scope of the present disclosure. Such variations are not to be regarded as a departure from the spirit and scope of the present disclosure.

[0074] According to the present invention, a method includes: causing a first roadside unit, by an infrastructure controller, to broadcast one or more messages to one or more vehicles; determining, by an algorithm associated with the infrastructure controller, whether one or more messages received by a second roadside unit match one or more messages broadcast by the first roadside unit; and causing one or more vehicles, by the infrastructure controller, to initiate one or more remedial actions in response to determining that the one or more messages received by the second roadside unit do not match the one or more messages broadcast by the first roadside unit within a predefined time range.

[0075] In one aspect of the present invention, the method includes: causing a second roadside unit, by an infrastructure controller, to verify one or more messages, wherein the second roadside unit is configured to receive the one or more messages based on a location of the first roadside unit, and wherein the verification of the one or more messages is based on matching the one or more messages with one or more decontamination operation scenarios defined by a channel busy rate.

[0076] In one aspect of the invention, the one or more remedial actions include: triggering a global suspension of operations for all vehicles in one or more vehicles; triggering a regional suspension of operations for a subset of one or more vehicles; identifying one or more target vehicles in one or more vehicles; or triangulating the location of a third party via one or more received signal strength indicator triangulation methods, where the third party is a roadside unit, an onboard unit associated with the vehicle, or a mobile device.

[0077] In one aspect of the present invention, the method includes: causing, by an algorithm, one or more instructions to be transmitted to one or more roadside units, wherein the one or more roadside units include at least a first roadside unit and a second roadside unit.

[0078] In one aspect of the present invention, the method includes: causing one or more roadside units to randomly change a data rate associated with each of the one or more roadside units based on one or more instructions; causing one or more roadside units to isolate and identify replayed data associated with one or more messages broadcast by a first roadside unit based on one or more instructions; or causing one or more roadside units to isolate and identify the location of a third party, wherein the identification of the location of the third party is based on the signal strength of the one or more roadside units, and wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

Claims

1. A method comprising: predicting, via a probabilistic analysis, that data associated with one or more messages broadcast by one or more roadside units is corrupted, wherein the prediction is implemented by an algorithm associated with a vehicle controller; and One or more remedial actions are initiated by the vehicle controller in response to predicting that the data associated with the one or more messages broadcast by the one or more roadside units is corrupted.

2. The method of claim 1, further comprising: A determination is made by the vehicle controller whether one or more messages broadcast from the vehicle match a broadcast history associated with the vehicle.

3. The method of claim 2, further comprising: The one or more remedial actions are initiated by the vehicle controller in response to a determination that the one or more messages broadcast from the vehicle do not match the broadcast history.

4. The method of claim 3, wherein the one or more remedial actions include: triggering a suspension of operation of said vehicle; transmitting the alert to a central server, a vehicle manufacturing cloud system, one or more operators, or a combination thereof; or One or more outgoing data modes associated with one or more messages broadcast from the vehicle are adjusted, wherein the one or more outgoing data modes include data rate, ProSe per-packet priority, modulation and coding scheme, packet size, or a combination thereof. 5 . The method of claim 4 , wherein the one or more outgoing data patterns are cross-referenced against the one or more messages broadcast from the vehicle.

6. The method of claim 1, further comprising: identifying one or more messages broadcast by one or more neighboring vehicles, wherein the one or more messages broadcast by the one or more neighboring vehicles may include a change in data rate, a jump in signal strength, or a combination thereof; and An alert is transmitted to a central server based on the identification of the one or more messages broadcast by the one or more neighboring vehicles.

7. A system comprising: An infrastructure controller, the infrastructure controller being configured to: causing a first roadside unit to broadcast one or more messages to one or more vehicles, determining, by an algorithm associated with the infrastructure controller, whether one or more messages received by a second roadside unit match the one or more messages broadcast by the first roadside unit, and causing the one or more vehicles to initiate a first set of remedial actions in response to determining that the one or more messages received by the second roadside unit do not match the one or more messages broadcast by the first roadside unit within a predefined time range; and A vehicle controller configured to: predicting, via a probabilistic analysis, that data associated with one or more messages broadcast by one or more roadside units is corrupted, wherein the prediction is implemented by an algorithm associated with the vehicle controller; and In response to predicting that the data associated with the one or more messages broadcast by the one or more roadside units is corrupted, a second set of remedial actions is initiated.

8. The system of claim 7, wherein the infrastructure controller is further configured to: causing the second roadside unit to verify the one or more messages, wherein the second roadside unit is configured to receive the one or more messages based on a location of the first roadside unit, and wherein the verification of the one or more messages is based on the one or more messages matching one or more decontamination operation scenarios defined by a channel busy rate.

9. The system of claim 7, wherein the first set of remedial actions comprises: triggering a global pause in operation of all vehicles of the one or more vehicles; triggering a suspension of regional operations for a subset of the one or more vehicles; identifying one or more target vehicles among the one or more vehicles; or The location of a third party is triangulated via one or more received signal strength indicator triangulation methods, wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

10. The system of claim 7, wherein the infrastructure controller is further configured to: One or more instructions are caused by the algorithm associated with the infrastructure controller to be transmitted to one or more roadside units, wherein the one or more roadside units include at least the first roadside unit and the second roadside unit.

11. The system of claim 10, wherein the infrastructure controller is further configured to: causing the one or more roadside units to randomly change a data rate associated with each of the one or more roadside units based on the one or more instructions; causing the one or more roadside units to isolate and identify replayed data associated with the one or more messages broadcast by the first roadside unit based on the one or more instructions; or Causing the one or more roadside units to isolate and identify the location of a third party, wherein the identification of the location of the third party is based on the signal strength of the one or more roadside units, and wherein the third party is a roadside unit, an onboard unit associated with a vehicle, or a mobile device.

12. The system of claim 7, wherein the vehicle controller is further configured to: determining whether one or more messages broadcast from the vehicle match a broadcast history associated with the vehicle; and The one or more remedial actions are initiated in response to a determination that the one or more messages broadcast from the vehicle do not match the broadcast history.

13. The system of claim 12, wherein the second set of remedial actions comprises: triggering a suspension of operation of said vehicle; transmitting the alert to a central server, a vehicle manufacturing cloud system, one or more operators, or a combination thereof; or One or more outgoing data modes associated with one or more messages broadcast from the vehicle are adjusted, wherein the one or more outgoing data modes include data rate, ProSe per-packet priority, modulation and coding scheme, packet size, or a combination thereof.

14. The system of claim 13, wherein the one or more outgoing data patterns are cross-referenced against the one or more messages broadcast from the vehicle.

15. The system of claim 7, wherein the vehicle controller is configured to: identifying one or more messages broadcast by one or more neighboring vehicles, wherein the one or more messages broadcast by the one or more neighboring vehicles include a change in data rate, a jump in signal strength, or a combination thereof; and An alert is transmitted to a central server based on the identification of the one or more messages broadcast by the one or more neighboring vehicles.

Images