System and method for data integrity verification of vehicle grouping messages

Abstract

The invention provides a system and a method for data integrity verification of vehicle grouping messages. A method includes calculating a first checksum value; transmitting one or more infrastructure grouping messages including a second checksum value based on the first checksum value; receiving one or more vehicle grouping messages; and validating the one or more vehicle grouping messages.

Description

Technical Field

[0001] This disclosure relates to the calculation and verification of data integrity associated with the exchange of one or more messages. Background Technology

[0002] The statements in this section are provided only as background information in relation to this disclosure and may not constitute prior art.

[0003] Before autonomous control of automated vehicles, one or more messages are typically exchanged between the automated vehicle and a central server. If this message exchange is not properly protected, it can be compromised. For example, the data integrity of the messages may be compromised. Additional threats may include a lack of synchronization procedures to check whether the intended recipient has received each bit of data, and a lack of functional methods for calculating and / or verifying the payload associated with the message.

[0004] This disclosure addresses these and other issues related to protecting the data integrity of messages exchanged in a vehicle formation system. Summary of the Invention

[0005] This section provides a general overview of this disclosure and is not a full disclosure of its entire scope or all its features.

[0006] This disclosure provides a method for initiating autonomous control of an automated vehicle, the method comprising: calculating a first checksum value by one or more processors of an infrastructure system based on an infrastructure-side secret key and encoded data associated with an automated vehicle located within a distance-related threshold from the infrastructure system; transmitting to the automated vehicle one or more infrastructure grouping messages including a second checksum value based on the first checksum value; receiving from the automated vehicle one or more vehicle grouping messages including a third checksum value based on a vehicle-side secret key in response to the automated vehicle verifying the one or more infrastructure grouping messages; and verifying the one or more vehicle grouping messages, wherein verifying the one or more vehicle grouping messages includes: decoding the one or more vehicle grouping messages; calculating a fourth checksum value based on the vehicle-side secret key in response to decoding the one or more vehicle grouping messages; and determining whether the fourth checksum value corresponds to the third checksum value; wherein calculating the first checksum value further includes: transforming the infrastructure-side secret key by a transformation constant; and appending the transformed infrastructure-side secret key to the encoded data associated with the automated vehicle; the method further includes: calculating the second checksum value based on the transformation constant; wherein the one or more infrastructure grouping messages further include encoded data associated with the automated vehicle and one or more infrastructure grouping messages. The message includes the length of data associated with the message or a combination thereof; wherein one or more vehicle grouping messages also include encoded data associated with automated vehicles, the length of data associated with one or more vehicle grouping messages, or a combination thereof; wherein decoding one or more vehicle grouping messages further includes: decoding a third checksum value; decoding the length of data associated with one or more vehicle grouping messages; and decoding encoded data associated with automated vehicles; wherein verification of one or more vehicle grouping messages further includes: transforming the decoded third checksum value by a transformation constant; recalculating the vehicle-side secret key based on the vehicle-side public key; and verifying one or more vehicle grouping messages. The method involves re-encoding the group message; and re-transforming the transformed third checksum value using a transformation constant; wherein the calculation of the fourth checksum further includes: appending the recalculated vehicle-side secret key to the re-encoded one or more vehicle group messages; and transforming the re-transformed third checksum value using a transformation constant; wherein the verification of the one or more vehicle group messages further includes: determining whether the data length associated with the re-encoded one or more vehicle group messages corresponds to the data length associated with the decoded data length; and the method further includes: establishing a communication link between the automated vehicle and the infrastructure system based on successfully determining that the fourth checksum value corresponds to the third checksum value.

[0007] This disclosure provides another method for initiating autonomous control of an automated vehicle, the method comprising: receiving, in response to the automated vehicle being within a distance-related threshold from an infrastructure system, one or more infrastructure grouping messages including a first checksum value at a vehicle processing system of the automated vehicle; verifying the one or more infrastructure grouping messages; in response to the verification of the one or more infrastructure grouping messages, calculating a second checksum value by one or more processors of the vehicle processing system based on a vehicle-side secret key and encoded data associated with the infrastructure system; transmitting to the infrastructure system one or more vehicle grouping messages including a third checksum value based on the second checksum value; and wherein the verification of the one or more infrastructure grouping messages includes: decoding the one or more infrastructure grouping messages; in response to the decoding of the one or more infrastructure grouping messages, calculating a fourth checksum value based on the infrastructure-side secret key; and determining whether the fourth checksum value corresponds to the first checksum value; wherein the calculation of the second checksum value further includes: transforming the vehicle-side secret key by a transformation constant; and appending the transformed vehicle-side secret key to the encoded data associated with the infrastructure system; the method further includes: calculating the third checksum value based on the transformation constant; wherein the one or more vehicle grouping messages further include data associated with the automated vehicle. The data includes encoded data, data length associated with one or more vehicle grouping messages, or combinations thereof; wherein one or more infrastructure grouping messages further include encoded data associated with automated vehicles, data length associated with one or more infrastructure grouping messages, or combinations thereof; wherein decoding one or more infrastructure grouping messages further includes: decoding a first checksum value; decoding the data length associated with one or more infrastructure grouping messages; and decoding encoded data associated with an infrastructure system; wherein verification of one or more infrastructure grouping messages further includes: transforming the encoded first checksum value by a transformation constant; recalculating the infrastructure side secret key based on the infrastructure side public key; re-encoding one or more infrastructure grouping messages; and re-transforming the transformed first checksum value by a transformation constant; wherein calculating a fourth checksum value further includes: appending the recalculated infrastructure side secret key to the re-encoded one or more infrastructure grouping messages; and transforming the re-transformed first checksum value by a transformation constant, and wherein verification of one or more infrastructure grouping messages further includes: determining whether the data length associated with the re-encoded one or more infrastructure grouping messages corresponds to the data length associated with the encoded data length.

[0008] This disclosure provides a system for initiating autonomous control of an automated vehicle, the system comprising: one or more processors of an infrastructure system configured to: calculate a first checksum based on an infrastructure-side secret key and encoded data associated with an automated vehicle located within a distance-related threshold from the infrastructure system; transmit one or more infrastructure grouping messages including a second checksum based on the first checksum; receive one or more vehicle grouping messages including a third checksum based on a vehicle-side secret key in response to vehicle verification of the second checksum; verify the one or more vehicle grouping messages; and a vehicle processing system for the automated vehicle configured to: receive one or more infrastructure grouping messages; verify one or more infrastructure grouping messages; calculate a third checksum based on a vehicle-side secret key and encoded data associated with the infrastructure system in response to verification of the one or more infrastructure grouping messages; and transmit the one or more vehicle grouping messages.

[0009] Further applicability will become apparent from the description provided herein. It should be understood that the descriptions and specific examples are intended for illustrative purposes only and are not intended to limit the scope of this disclosure. Attached Figure Description

[0010] To better understand this disclosure, various forms of the disclosure will now be described by way of example with reference to the accompanying drawings, in which: Figure 1 An example system for automated vehicle grouping according to one or more embodiments of the present disclosure is shown; Figure 2 This is a flowchart illustrating an example method for calculating and / or verifying the data integrity associated with the exchange of one or more messages; Figure 3 This is a flowchart illustrating another example method for calculating and / or verifying the data integrity associated with the exchange of one or more messages; Figure 4A and Figure 4C The calculation of data integrity associated with the exchange of one or more messages is shown; Figure 4B and Figure 4D This demonstrates the verification of data integrity associated with the exchange of one or more messages; Figure 5 This is a flowchart illustrating yet another example method for calculating and / or verifying the integrity of data associated with the exchange of one or more messages; Figure 6 This is a flowchart illustrating additional example methods for calculating and / or verifying data integrity associated with the exchange of one or more messages; and Figure 7 This is a block diagram illustrating an example computer system according to one or more embodiments of the present disclosure.

[0011] The accompanying drawings described herein are for illustrative purposes only and are not intended to limit the scope of this disclosure in any way. Detailed Implementation

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

[0013] The one or more examples described herein provide a means for calculating and / or verifying the data integrity associated with one or more messages exchanged between an automated vehicle and a central server. In one or more examples, the calculation and verification of the messages protects the data integrity of the messages during transmission between the automated vehicle and the central server. In one or more examples, the calculation and verification of the data integrity associated with the messages provides a synchronization process to check whether all data bits associated with each element in the message are received at the intended recipient and / or whether any data bits are lost, flipped, or associated with any errors during transmission between the automated vehicle and the central server. In one or more examples, the calculation and verification of the data integrity associated with the messages helps define functional protection methods for calculating and / or verifying the payload associated with the messages.

[0014] Figure 1 A schematic block diagram of an Automated Vehicle Grouping (AVM) system 100 is shown. In one or more examples, the AVM system 100 groups one or more vehicles (e.g., vehicle 102) that are traveling at low speeds. However, it should be understood that the AVM system 100 can group one or more vehicles that are traveling at any speed. It should also be understood that the AVM system 100 can group semi-autonomous vehicles and / or fully autonomous vehicles.

[0015] AVM system 100 typically includes vehicle 102, vehicle manufacturing cloud system 104, vehicle delivery manager cloud system 106, vehicle customer web portal account cloud system 108, and infrastructure system 110. Vehicle manufacturing cloud system 104 serves as a central cloud system for managing and / or facilitating any manufacturing processes associated with vehicle 102. Vehicle manufacturing cloud system 104 is configured to communicate wirelessly with vehicle delivery manager cloud system 106 and / or infrastructure system 110. Vehicle manufacturing cloud system 104 is also configured to communicate wirelessly with vehicle 102.

[0016] The vehicle manufacturing cloud system 104 may include an infrastructure-side AVM algorithm 112. The infrastructure-side AVM algorithm 112 processes state information associated with at least one or more vehicles 102. It should be understood that, in one or more embodiments, the infrastructure-side AVM algorithm 112 processes state information associated with each of the one or more vehicles (e.g., vehicle 102). The vehicle manufacturing cloud system 104 is configured to cause the infrastructure system 110 to monitor the progress of the vehicles as one or more vehicles (e.g., vehicle 102) move through a marshalling environment. For example, a marshalling environment may represent a factory marshalling setup, an automatic charging setup, a depot marshalling setup, an underground parking setup, etc. As an example, a factory marshalling setup may include an instance where newly manufactured vehicles move through a production line off-line test at a vehicle assembly plant via overhead visual sensing. As another example, an automatic charging setup may include an instance where vehicles are correctly assigned to an automatic charging mode located outdoors or indoors. As a further example, a depot marshalling setup may include an instance where a fleet of commercial vehicles moves through warehouses and depots for automatic loading and / or handling of goods. As an additional example, underground parking setups may include instances in which vehicles move through underground or covered parking environments with potentially inconsistent communication networks (such as global navigation satellite systems).

[0017] The vehicle manufacturing cloud system 104 is also configured to cause the infrastructure system 110 to communicate with one or more vehicles. For example, the vehicle manufacturing cloud system 104 utilizes the infrastructure-side AVM algorithm 112 to send instructions to the infrastructure system 110 and / or process information received from the infrastructure system 110. The vehicle manufacturing cloud system 104 is also configured to cause the vehicle delivery manager cloud system 106 to facilitate the delivery of one or more vehicles (e.g., vehicle 102) to various locations. For example, the vehicle manufacturing cloud system 104 utilizes the infrastructure-side AVM algorithm 112 to send instructions to the vehicle delivery manager cloud system 106 and / or process information received from the vehicle delivery manager cloud system 106.

[0018] The vehicle manufacturing cloud system 104 is also configured to communicate directly with one or more vehicles to cause the one or more vehicles to start, stop, or pause their progress through the formation environment. The vehicle manufacturing cloud system 104 is also configured to control the formation speed of one or more vehicles as they travel through (e.g., traverse) the formation environment. For example, the vehicle manufacturing cloud system 104 utilizes the infrastructure-side AVM algorithm 112 to send instructions to vehicle 102 and / or process information received from vehicle 102.

[0019] Infrastructure system 110 includes sensor components 114, wireless communication components 116, a multi-access edge computing (MEC) system 118, and one or more traffic lights 120. Typically, and as described herein, infrastructure system 110 is configured to compute and / or verify one or more messages exchanged between infrastructure system 110 and one or more vehicles. For example, infrastructure system 110 is configured to compute and / or verify one or more messages exchanged between infrastructure system 110 and one or more vehicles before grouping of one or more vehicles can begin. However, it should be understood that infrastructure system 110 is configured to compute and / or verify one or more messages exchanged between infrastructure system 110 and one or more vehicles at any time associated with the grouping process. In one or more examples, infrastructure-side AVM algorithm 112 is configured to perform the computation and / or verification of one or more messages exchanged between infrastructure system 110 and one or more vehicles.

[0020] It should be understood that the MEC system 118 is configured to support communication between the wireless communication component 116 and the vehicle 102. However, it should also be understood that the MEC system 118 is also configured to support communication between the wireless communication component 116 and any of the vehicle manufacturing cloud system 104, the vehicle delivery manager cloud system 106, and / or the vehicle customer web portal account cloud system 108. For example, the wireless communication component 116 may utilize GPS, Wi-Fi, satellite, 3G / 4G / 5G, and / or Bluetooth. ® To communicate with one or more vehicles.

[0021] The wireless communication component 116 also communicates with a sensor component 114, which is configured to communicate with and / or manage a set of infrastructure sensors, including one or more cameras, lidar, and / or ultrasonic devices configured to monitor the movement of one or more vehicles through a grouped environment. In one or more examples, the sensor component 114 is also configured to perform one or more positioning functions associated with grouping one or more vehicles, such as, but not limited to, sensing, path planning, detection, control, and / or receiving and analyzing responses from each of the one or more vehicles.

[0022] The wireless communication component 116 also communicates with the traffic light 120. For example, when one or more vehicles are grouped through a grouping environment, the wireless communication component 116 can cause the traffic light 120 to guide the traffic of one or more vehicles. It should be understood that the infrastructure system 110 can forward instructions received from the vehicle manufacturing cloud system 104 to the vehicle 102. However, it should also be understood that the infrastructure system 110 can send instructions directly to the vehicle 102, for example, by utilizing the MEC system 118.

[0023] Vehicle 102 includes a vehicle-side AVM algorithm 122, a wireless transmission module 124, a vehicle central gateway module 126, a vehicle infotainment system 128, one or more vehicle sensors 130, a vehicle battery 132, a vehicle GNSS 134, a vehicle navigation mapping system 136, and a controller area network (CAN) vehicle bus 138. The wireless transmission module 124 may be a transmission control unit (TCU) and / or may be supported by a telematics-enabled subsystem. The wireless transmission module 124 includes one or more sensors configured to collect data and transmit signals to other components of vehicle 102. One or more sensors of the wireless transmission module 124 may include a vehicle speed sensor (not shown) configured to determine the current speed of the vehicle 102; a wheel speed sensor (not shown) configured to determine whether the vehicle 102 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 the vehicle 102 is required in the current state of the vehicle 102; and / or a turbo speed sensor (not shown) configured to transmit data associated with the rotational speed of the torque converter of the vehicle 102.

[0024] The wireless transmission module 124 transmits information collected by one or more sensors to the vehicle-side AVM algorithm 122. In one embodiment, the vehicle-side AVM algorithm 122 may be a component within the wireless transmission module 124. For example, vehicle 102 utilizes the vehicle-side AVM algorithm 122 to process information collected by one or more sensors and transmit the information to infrastructure system 110. As another example, vehicle 102 utilizes the vehicle-side AVM algorithm 122 to process information collected by one or more sensors and transmit the information directly to vehicle manufacturing cloud system 104. The vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to the wireless transmission module 124.

[0025] The vehicle central gateway module 126 operates as an interface between various vehicle domain bus systems, such as engine compartment bus (not shown), interior bus (not shown), optical bus for multimedia (not shown), diagnostic bus for maintenance (not shown), or vehicle CAN bus 138. The vehicle central gateway module 126 is configured to distribute data transmitted to it from each of the various domain bus systems to other components of the vehicle 102. The vehicle central gateway module 126 is also configured to distribute information received from the vehicle-side AVM algorithm 122 to the various domain bus systems. The vehicle central gateway module 126 is also configured to send information received from the various domain bus systems to the vehicle-side AVM algorithm 122. For example, the vehicle 102 uses the vehicle-side AVM algorithm 122 to process information received from the vehicle central gateway module 126 and sends the information to the infrastructure system 110. As another example, the vehicle 102 uses the vehicle-side AVM algorithm 122 to process information received from the vehicle central gateway module 126 and sends the information directly to the vehicle manufacturing cloud system 104. The vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from the infrastructure system 110 and / or the vehicle manufacturing cloud system 104 to the vehicle central gateway module 126.

[0026] The vehicle infotainment system 128 delivers a combination of information and entertainment content and / or services to a user 140 of vehicle 102. It should be understood that in some examples, the vehicle infotainment system 128 may only deliver entertainment content to the user 140 of vehicle 102. It should also be understood that in other examples, the vehicle infotainment system 128 may deliver information services to anyone associated with vehicle 102. As an example, the vehicle infotainment system 128 includes a built-in 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 128 transmits information associated with the built-in vehicle computer or processor to a vehicle-side AVM algorithm 122. For example, vehicle 102 utilizes the vehicle-side AVM algorithm 122 to process information received from the vehicle infotainment system 128 and transmits said information to infrastructure system 110. As another example, vehicle 102 utilizes the vehicle-side AVM algorithm 122 to process information received from the vehicle infotainment system 128 and transmits said information directly to vehicle manufacturing cloud system 104. The vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from the infrastructure system 110 and / or the vehicle manufacturing cloud system 104 to the vehicle infotainment system 128.

[0027] One or more vehicle sensors 130 may be one or more of, for example, cameras, lidar, radar, and / or ultrasonic devices. For example, an ultrasonic device serving as one or more vehicle sensors 130 emits high-frequency sound waves that strike a wall or another vehicle and are then reflected back to vehicle 102. Based on the amount of time it takes for the sound waves to return to vehicle 102, vehicle 102 can determine the distance between the one or more vehicle sensors 130 and the wall or other vehicle. As another example, a camera device serving as one or more vehicle sensors 130 provides a visual indication of the space around vehicle 102. As an additional example, a radar device serving as one or more vehicle sensors 130 emits electromagnetic wave signals that strike a wall or other vehicle and are then reflected back to vehicle 102. Based on the amount of time it takes for the electromagnetic waves to return to vehicle 102, vehicle 102 can determine the range, speed, and angle of vehicle 102 relative to the wall or other vehicle.

[0028] One or more vehicle sensors 130 transmit information associated with the position and / or distance of vehicle 102 relative to a wall or other vehicle to vehicle-side AVM algorithm 122. For example, vehicle 102 utilizes vehicle-side AVM algorithm 122 to process information received from one or more vehicle sensors 130 and transmit said information to infrastructure system 110. As another example, vehicle 102 utilizes vehicle-side AVM algorithm 122 to process information received from one or more vehicle sensors 130 and transmit said information directly to vehicle manufacturing cloud system 104. Vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to one or more vehicle sensors 130.

[0029] Vehicle battery 132 is controlled by a battery management system (not shown) that provides instructions to vehicle battery 132. For example, the battery management system provides instructions to vehicle battery 132 based on the temperature of vehicle battery 132. However, it should be understood that the battery management system may provide instructions to vehicle battery 132 based on any metric associated with vehicle battery 132, such as the state of power of vehicle 102, the period of time during which vehicle 102 is in an off state at least during the day, or a combination thereof. The battery management system ensures that the current pattern of vehicle battery 132 is acceptable. For example, an acceptable current pattern prevents overvoltage, overcharge, and / or overheating of vehicle battery 132. As another example, the temperature of vehicle battery 132 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 vehicle battery 132 transmits information related to the temperature of vehicle battery 132 to vehicle-side AVM algorithm 122. For example, vehicle 102 uses vehicle-side AVM algorithm 122 to process the received information about vehicle battery 132 and transmit said information to infrastructure system 110. As another example, vehicle 102 utilizes vehicle-side AVM algorithm 122 to process information about vehicle battery 132 and transmits the information directly to vehicle manufacturing cloud system 104. Vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to vehicle battery 132.

[0030] Vehicle GNSS 134 is configured to communicate with satellites, enabling vehicle 102 to determine its exact location. Vehicle navigation mapping system 136 can display the exact location of vehicle 102 to user 140 via a display screen (not shown). Vehicle GNSS 134 transmits geographic information associated with vehicle 102 to vehicle-side AVM algorithm 122. For example, vehicle 102 uses vehicle-side AVM algorithm 122 to process information received from vehicle GNSS 134 and transmit the information to infrastructure system 110. As another example, vehicle 102 uses vehicle-side AVM algorithm 122 to process information from vehicle GNSS 134 and transmit the information directly to vehicle manufacturing cloud system 104. Vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to vehicle GNSS 134. As another example, vehicle 102 utilizes vehicle-side AVM algorithm 122 to process information associated with vehicle navigation mapping system 136 and transmits said information to infrastructure system 110. As yet another example, vehicle 102 utilizes vehicle-side AVM algorithm 122 to process information from vehicle navigation mapping system 136 and transmits said information directly to vehicle manufacturing cloud system 104. Vehicle-side AVM algorithm 122 is configured to transmit information and / or instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to vehicle navigation mapping system 136.

[0031] Vehicle 102 is configured to transmit any information associated with any component included within vehicle 102 to one or more auxiliary vehicles 142. Vehicle 102 is also configured to transmit (e.g., forward) any instructions received from infrastructure system 110 and / or vehicle manufacturing cloud system 104 to any of the one or more auxiliary vehicles 142. For example, communication between vehicle 102 and one or more auxiliary vehicles 142 may assist infrastructure system 110 and / or vehicle manufacturing cloud system 104 in grouping one or more auxiliary vehicles 142. It should be understood that each of the one or more auxiliary vehicles 142 may include any of the components described as included within vehicle 102, such as vehicle-side AVM algorithm 122, wireless transmission module 124, vehicle central gateway module 126, vehicle infotainment system 128, one or more vehicle sensors 130, vehicle battery 132, vehicle GNSS system 134, vehicle navigation mapping system 136, and / or CAN vehicle bus 138. It should also be understood that any of the one or more auxiliary vehicles 142 is configured to transmit information associated with any component included within vehicle 102. It should also be understood that one or more additional vehicles 142 may also be configured to establish direct wireless communication lines (e.g., via communication links) with the infrastructure system 110 and / or the vehicle manufacturing cloud system 104, thereby enabling direct exchange of information between one or more additional vehicles 142 and the infrastructure system 110 and / or the vehicle manufacturing cloud system 104.

[0032] The vehicle delivery manager cloud system 106 wirelessly communicates (e.g., receives and / or sends instructions and / or information) with one or more of the following: rental agency cloud system 144, valet parking agency cloud system 146, insurance agency cloud system 148, and / or dealer system 150. The vehicle delivery manager cloud system 106 is configured to facilitate the delivery of one or more vehicles to any of the following: a rental agency (not shown) associated with rental agency cloud system 144, a valet parking agency (not shown) associated with valet parking agency cloud system 146, an insurance agency (not shown) associated with insurance agency cloud system 148, and / or dealer system 150. The vehicle delivery manager cloud system 106 also wirelessly communicates with the vehicle customer web portal account cloud system 108. It should be understood that other cloud systems may be included in one or more examples.

[0033] The vehicle delivery manager cloud system 106 communicates wirelessly with a user device 152, such as a mobile device, display panel, and / or computer. The vehicle 102 is also configured to communicate wirelessly directly with the user device 152. For example, a user 140 interacts with the user device 152 via an application that organizes any information and / or instructions received from the vehicle customer web portal account cloud system 108 and / or the vehicle 102. As another example, the user 140 may send one or more instructions to the vehicle customer web portal account cloud system 108, such as selecting which vehicle the user 140 wants to receive from any of the following: a rental agency associated with the rental agency cloud system 144, a valet parking agency associated with the valet parking agency cloud system 146, an insurance agency associated with the insurance agency cloud system 148, and / or a dealership system 150.

[0034] Figure 2 This is a flowchart illustrating an example method 200 for calculating and / or verifying the data integrity associated with one or more infrastructure grouping messages (IMMs) and one or more vehicle grouping messages (VMMs) exchanged between an automated vehicle (e.g., vehicle 102) and an infrastructure system (e.g., infrastructure system 110).

[0035] At operation 202, one or more processors of the infrastructure system are configured to compute a first checksum value. In one or more examples, the first checksum value is computed based on an infrastructure-side secret key and / or encoded data associated with an automated vehicle located within a distance-related threshold from the infrastructure system. As another example, the distance-related threshold can be any distance-related range from the infrastructure system in which the automated vehicle can maintain a communication link with the infrastructure system. In one or more embodiments, the computation of the first checksum value includes transforming the infrastructure-side secret key by a transformation constant and / or appending the transformed infrastructure-side secret key to the encoded data associated with the automated vehicle.

[0036] At operation 204, the infrastructure system is configured to transmit one or more IMMs to the automated vehicle. In one or more examples, the one or more IMMs include a second checksum value. As another example, and in one or more embodiments, the second checksum value is calculated based on a first checksum value and / or a transformation constant. As yet another example, the one or more IMMs also include encoded data associated with the automated vehicle, the data length associated with the one or more IMMs, or a combination thereof.

[0037] At operation 206, the infrastructure system is configured to receive one or more VMMs from an automated vehicle. In one or more examples, the one or more VMMs include a third checksum value. As another example, the third checksum value is calculated based on a vehicle-side secret key. As a further example, the third checksum value is calculated in response to the automated vehicle verifying one or more IMMs. As yet another example, the one or more VMMs also include encoded data associated with the automated vehicle, data length associated with one or more VMMs, or a combination thereof.

[0038] At operation 208, the infrastructure system is configured to verify one or more VMMs. In one or more examples, verification of one or more VMMs includes decoding one or more VMMs. As another example, and in one or more embodiments, decoding one or more VMMs includes: decoding a third checksum value; decoding the data length associated with one or more VMMs; and / or decoding encoded data associated with the automated vehicle. As a further example, and in one or more embodiments, verification of one or more VMMs includes: transforming the decoded third checksum value by a transformation constant; recalculating the vehicle-side secret key based on the vehicle-side public key; re-encoding one or more VMMs; and / or re-transforming the transformed third checksum value by a transformation constant.

[0039] Verification of one or more VMMs also includes calculating a fourth checksum value. For example, the calculation of the fourth checksum value is based on a vehicle-side secret key. As another example, the fourth checksum value is calculated in response to decoding one or more VMMs. As yet another example, and in one or more embodiments, the calculation of the fourth checksum includes: appending a recalculated vehicle-side secret key to one or more re-encoded VMMs and / or transforming a re-transformed third checksum value by a transformation constant.

[0040] Validation of one or more VMMs also includes determining whether a fourth checksum value corresponds to a third checksum value. It should be understood that a fourth checksum value may correspond to the third checksum value if the fourth checksum value matches (e.g., is identical) the third checksum value and / or the fourth checksum value is within an acceptable range or variance of the third checksum value. It should be understood that the fourth checksum value may correspond to the third checksum value based on any relational function and may be determined by one or more algorithmic functions associated with one or more processors of the infrastructure system. It should also be understood that the acceptable range may be predefined or determined in real-time by one or more algorithmic functions.

[0041] In one or more embodiments, verification of one or more VMMs may further include determining whether the data length associated with the re-encoded one or more VMMs corresponds to the data length associated with the decoded data length. It should be understood that the data length associated with the re-encoded one or more VMMs may correspond to the data length associated with the decoded data length if the data length associated with the re-encoded one or more VMMs matches (e.g., the same length) and / or the data length associated with the re-encoded one or more VMMs is within an acceptable range or variance of the data length associated with the decoded data length. It should be understood that the data length associated with the re-encoded one or more VMMs may correspond to the data length associated with the decoded data length based on any relational function and may be determined by one or more algorithmic functions associated with one or more processors of the infrastructure system. It should also be understood that the acceptable range may be predefined or determined in real-time by one or more algorithmic functions.

[0042] In one or more embodiments, a communication link is thus established between the automated vehicle and the infrastructure system. In one or more examples, the communication link is established based on successfully determining that a fourth checksum value corresponds to a third checksum value.

[0043] Figure 3 This is another flowchart illustrating an example method 300 for calculating and / or verifying the data integrity associated with one or more infrastructure grouping messages (IMMs) and one or more vehicle grouping messages (VMMs) exchanged between an automated vehicle (e.g., vehicle 102) and an infrastructure system (e.g., infrastructure system 110).

[0044] At operation 302, the vehicle handling system of the automated vehicle is configured to receive one or more IMMs. In one or more examples, the one or more IMMs include a first checksum value. As another example, one or more IMMs are received in response to the automated vehicle being within a distance-related threshold from the infrastructure system. As another example, the distance-related threshold can be any distance-related range from the infrastructure system within which the automated vehicle can maintain a communication link with the infrastructure system. As yet another example, the one or more IMMs also include encoded data associated with the automated vehicle, the data length associated with the one or more IMMs, or a combination thereof.

[0045] At operation 304, one or more processors of the vehicle processing system are configured to verify one or more IMMs. In one or more examples, verification of one or more IMMs includes decoding one or more IMMs. As another example, and in one or more embodiments, decoding one or more IMMs includes: decoding a first checksum value; decoding the data length associated with one or more IMMs; and / or decoding encoded data associated with the infrastructure system. As a further example, and in one or more embodiments, verification of one or more IMMs includes: transforming the decoded first checksum value by a transformation constant; recalculating the infrastructure-side secret key based on the infrastructure-side public key; re-encoding one or more IMMs; and / or re-transforming the transformed first checksum value by a transformation constant.

[0046] Verification of one or more IMMs also includes calculating a fourth checksum. For example, the calculation of the fourth checksum value is based on an infrastructure-side secret key. As another example, the fourth checksum value is calculated in response to decoding one or more IMMs. As yet another example, and in one or more embodiments, the calculation of the fourth checksum includes: appending a recalculated infrastructure-side secret key to one or more re-encoded infrastructure marshalling messages and / or transforming the re-transformed first checksum value by a transformation constant.

[0047] Validation of one or more IMMs also includes determining whether a fourth checksum value corresponds to a first checksum value. It should be understood that a fourth checksum value may correspond to a first checksum value if the fourth checksum value matches (e.g., is identical) the first checksum value and / or is within the acceptable range or variance of the first checksum value. It should be understood that the fourth checksum value may correspond to the first checksum value based on any relational function and may be determined by one or more algorithmic functions associated with one or more processors of the infrastructure system. It should also be understood that the acceptable range may be predefined or determined in real-time by one or more algorithmic functions.

[0048] In one or more embodiments, verification of one or more IMMs may further include determining whether the data length associated with the re-encoded one or more infrastructure marshalling messages corresponds to the data length associated with the decoded data length. It should be understood that the data length associated with the re-encoded one or more IMMs may correspond to the data length associated with the decoded data length if the data length associated with the re-encoded one or more IMMs matches (e.g., the same length) and / or the data length associated with the re-encoded one or more IMMs is within an acceptable range or variance of the data length associated with the decoded data length. It should be understood that the data length associated with the re-encoded one or more IMMs may correspond to the data length associated with the decoded data length based on any relational function and may be determined by one or more algorithmic functions associated with one or more processors of the infrastructure system. It should also be understood that the acceptable range may be predefined or determined in real-time by one or more algorithmic functions.

[0049] At operation 306, one or more processors of the vehicle processing system are configured to compute a second checksum value. In one or more examples, the second checksum value is computed based on a vehicle-side secret key and / or encoded data associated with the infrastructure system. As another example, the second checksum value is computed in response to verification of one or more IMMs. As a further example, and in one or more embodiments, the computation of the second checksum value includes transforming the vehicle-side secret key by a transformation constant and / or appending the transformed vehicle-side secret key to the encoded data associated with the infrastructure system.

[0050] At operation 308, the vehicle system is configured to transmit one or more VMMs to the infrastructure vehicle. In one or more examples, the one or more VMMs include a third checksum value. As another example, and in one or more embodiments, the third checksum value is calculated based on a second checksum value and / or a transformation constant. As yet another example, the one or more VMMs also include encoded data associated with the automated vehicle, data lengths associated with one or more vehicle grouping messages, or combinations thereof.

[0051] It should be understood that, in one or more embodiments, the description herein is consistent with... Figure 2 and Figure 3 The operation-related methods discussed in the article are respectively reflected in Figures 4A to 4D The example process described in [the document]. Specifically, Figure 4AAn example procedure 400 for calculating an IMM-related checksum is shown, executed by the infrastructure-side AVM algorithm 112 of the infrastructure system 110. In one or more examples, the infrastructure-side AVM algorithm 112 is configured to calculate the SharedvIDCSSecretKey at step 402.

[0052] The infrastructure-side AVM algorithm 112 is also configured to compute the Unaligned Packaging Encoding Rule (UPER) at step 404 and encode the vehicle x-container data (e.g., encoded data associated with an automated vehicle), and compute the TransformedSharedvIDCSSecretKey (e.g., an infrastructure-side secret key). In one or more examples, the TransformedSharedvIDCSSecretKey is computed based on appending a transformation constant to the computed SharedvIDCSSecretKey. As another example, the vehicle x-container data can be populated with raw data or any type of data format. It should be understood that the transformation constant can be a standard constant applicable to any process for computed IMM-related checksums. However, it should also be understood that the transformation constant can be a unique constant corresponding to different vehicles associated with the computation of IMM-related checksums.

[0053] The infrastructure-side AVM algorithm 112 is also configured to compute a checksum at step 406. In one or more examples, the checksum computed at step 406 represents the checksum about... Figure 2 The first checksum value described. In one or more examples, the checksum is calculated based on appending UPER-encoded container data to the TransformedSharedvIDCSSecretKey. It should be understood that, although... Figure 4A The diagram shows the checksum calculation in 32-bit format, but any format can be used in checksum calculation.

[0054] The infrastructure-side AVM algorithm 112 is further configured to compute a checksum of the new transformation at step 408. In one or more examples, the checksum of the new transformation computed at step 408 represents the change in... Figure 2 The description of the second checksum value and about Figure 3 The first checksum value is described. In one or more examples, the checksum of the new transformation is calculated based on the checksum calculated at step 406 appended to the additional transformation constant. It should be understood that the additional transformation constant may be the same as the transformation constant appended to SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant may be different from the transformation constant appended to SharedvIDCSSecretKey at step 404.

[0055] Furthermore, the infrastructure-side AVM algorithm 112 is configured to generate (e.g., create) a vehicle x-container binary large object (blob) at step 410. In one or more examples, the vehicle x-container blob includes a checksum of the newly transformed vehicle x-container data, an IMM UPER length, and the vehicle x-container data. It should be understood that each of the checksum of the newly transformed vehicle x-container data, the IMM UPER length, and the vehicle x-container data can correspond to the original data associated with the vehicle x-container data discussed with respect to step 404. However, it should be understood that each of the checksum of the newly transformed vehicle x-container data, the IMM UPER length, and the vehicle x-container data can also correspond to any type of data format. An IMM payload is also generated at step 410. In one or more examples, the IMM payload corresponds to a UPER-encoded representation of each of the newly transformed vehicle x-container data, the IMM UPER length, and the vehicle x-container data. In one or more examples, the infrastructure system 110 is also configured to transmit the IMM payload to the vehicle 102.

[0056] Figure 4B An example procedure 500 for verifying IMM-related checksums is illustrated, executed by the vehicle-side AVM algorithm 122 of vehicle 102. In one or more examples, procedure 500 is initiated when the vehicle-side AVM algorithm 122 determines that the identity management associated with the received IMM payload matches the vehicle 102 receiving the IMM payload. In one or more examples, procedure 500 is also initiated when the vehicle-side AVM algorithm 122 determines that the IMM payload received at vehicle 102 is recent (e.g., newly generated and / or received at vehicle 102). It should be understood that procedure 500 can be initiated based on the vehicle-side AVM algorithm 122 determining that the identity management associated with the received IMM payload matches vehicle 102 and / or determining that the IMM payload received at vehicle 102 is recent.

[0057] In one or more examples, the vehicle-side AVM algorithm 122 is configured to perform UPER decoding on the IMM payload received at vehicle 102 at step 502. Specifically, while performing UPER decoding on the IMM payload, and also at step 502, the vehicle-side AVM algorithm 122 decodes each of the checksum of the new transformation of the vehicle x-container data, the IMM UPER length, and the vehicle x-container data (e.g., the vehicle x-container blob). In one or more examples, vehicle 102 is configured to store the decoded vehicle x-container blob in a database (not shown) associated with vehicle 102. It should be understood that the database may be located externally and / or internally relative to vehicle 102.

[0058] The vehicle-side AVM algorithm 122 is also configured to compute a checksum of the decoded original reception at step 504. In one or more examples, the checksum of the decoded original reception is computed based on the checksum of the new transformation of the decoded vehicle x container data by appending an additional transformation constant. It should be understood that the additional transformation constant may be the same as the transformation constant appended to the SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant may be different from the transformation constant appended to the SharedvIDCSSecretKey at step 404. The vehicle-side AVM algorithm 122 is also configured to recompute the SharedvIDCSSecretKey at step 504. In one or more examples, the SharedvIDCSSecretKey is recomputed based on the VIDCSPublicKey associated with the infrastructure system 110 (e.g., an infrastructure-side public key).

[0059] The vehicle-side AVM algorithm 122 is also configured to perform UPER re-encoding on the vehicle x-container data and compute the Re-TransformedSharedvIDCSSecretKey at step 506. In one or more examples, the Re-TransformedSharedvIDCSSecretKey is computed by appending the recomputed SharedvIDCSSecretKey to the transformation constant. It should be understood that the transformation constant can be the same as the transformation constant appended to the SharedvIDCSSecretKey at step 404. However, it should also be understood that the transformation constant can be different from the transformation constant appended to the SharedvIDCSSecretKey at step 404.

[0060] The vehicle-side AVM algorithm 122 is further configured to recalculate the checksum at step 508 (e.g., the checksum described with respect to step 406). In one or more examples, the checksum is recalculated by appending the re-encoded vehicle x container data to the Re-TransformedSharedvIDCSSecretKey. The vehicle-side AVM algorithm 122 is also configured to recalculate the checksum of the new transformation at step 508 (e.g., the checksum of the new transformation described in step 408). In one or more examples, the checksum of the new transformation recalculated at step 508 represents the checksum of the new transformation described in step 408. Figure 3 The fourth checksum value is described. In one or more examples, the checksum of the new transformation is recalculated by appending the recalculated checksum to the additional transformation constant. It should be understood that the additional transformation constant may be the same as the transformation constant appended to SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant may be different from the transformation constant appended to SharedvIDCSSecretKey at step 404.

[0061] The vehicle-side AVM algorithm 122 is also configured at step 510 to determine (e.g., verify) whether the recalculated checksum matches (e.g., is the same) the decoded original received checksum. The vehicle-side AVM algorithm 122 is also configured at step 510 to determine (e.g., verify) whether the checksum of the recalculated new transform matches (e.g., is the same) the decoded vehicle x container data new transform checksum. The vehicle-side AVM algorithm 122 is further configured at step 510 to determine (e.g., verify) whether the length of the re-encoded IMM UPER data matches (e.g., is the same) the length of the decoded IMM UPER data.

[0062] Figure 4C An example procedure 600 for calculating VMM-related checksums is shown, performed by the vehicle-side AVM algorithm 122 of vehicle 102. In one or more examples, the vehicle-side AVM algorithm 122 is configured to calculate the SharedvIDAVSecretKey at step 602.

[0063] The vehicle-side AVM algorithm 122 is also configured to perform UPER encoding on the VMM data associated with vehicle 102 and compute a TransformedSharedvIDAVSecretKey (e.g., a vehicle-side secret key) at step 604. In one or more examples, the TransformedSharedvIDAVSecretKey is computed based on appending a transformation constant to the computed SharedvIDAVSecretKey. As another example, the UPER-encoded data of the VMM can be provided in the form of raw data or in any type of data format. It should be understood that the transformation constant can be the same as the transformation constant appended to the SharedvIDCSSecretKey at step 404. However, it should also be understood that the transformation constant can be different from the transformation constant appended to the SharedvIDCSSecretKey at step 404.

[0064] The vehicle-side AVM algorithm 122 is also configured to calculate a checksum at step 606. In one or more examples, the checksum calculated at step 606 represents the information about... Figure 3 The second checksum value is described. In one or more examples, the checksum is calculated based on appending the UPER-encoded data of the VMM to the TransformedSharedvIDAVSecretKey. It should be understood that, although... Figure 4C The diagram shows the checksum calculation in 32-bit format, but any format can be used in checksum calculation.

[0065] The vehicle-side AVM algorithm 122 is further configured to compute a checksum of the new transformation at step 608. In one or more examples, the checksum computed at step 608 represents the change in the new transformation. Figure 2 and Figure 3 Both describe a third checksum value. In one or more examples, the checksum of the new transformation is calculated based on appending the checksum calculated at step 606 to an additional transformation constant. It should be understood that the additional transformation constant can be the same as the transformation constant appended to SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant can be different from the transformation constant appended to SharedvIDCSSecretKey at step 404.

[0066] Furthermore, the vehicle-side AVM algorithm 122 is configured to generate (e.g., create) raw data associated with the VMM at step 610. In one or more examples, the raw data associated with the VMM includes VMM-associated data regarding the checksum of the new transformation, the VMM UPER length, and VMM-associated data regarding the VMM data. It should be understood that each of the VMM-associated data regarding the checksum of the new transformation, the VMM UPER length, and the VMM-associated data regarding the VMM data can correspond to the raw data associated with the VMM data at step 604. However, it should be understood that each of the VMM-associated data regarding the checksum of the new transformation, the VMM UPER length, and the VMM-associated data regarding the VMM data can also correspond to any type of data format. A VMM payload is also generated at step 610. In one or more examples, the VMM payload corresponds to a UPER-encoded representation of each of the VMM-associated data regarding the checksum of the new transformation, the VMM UPER length, and the VMM-associated data regarding the VMM data. In one or more examples, vehicle 102 is also configured to transmit VMM payloads to infrastructure system 110.

[0067] Figure 4D An example procedure 700 for verifying VMM-related checksums is illustrated, executed by the infrastructure-side AVM algorithm 112 of the infrastructure system 110. In one or more examples, procedure 700 is initiated when the infrastructure-side AVM algorithm 112 determines that the identityManagement associated with the received VMM payload matches the rollingCounterOfIMMReceived with respect to the transmitted VMM payload.

[0068] In one or more examples, the infrastructure-side AVM algorithm 112 is configured to perform UPER decoding on the VMM payload received at the infrastructure system 110 at step 702. Specifically, while performing UPER decoding on the VMM payload, and also at step 702, the infrastructure-side AVM algorithm 112 performs UPER decoding on each of the VMM with respect to the checksum of the new transformation, the VMM UPER length, and the data associated with the VMM regarding the VMM data (e.g., automated vehicle VMM data). In one or more examples, the infrastructure system 110 is configured to store the decoded automated vehicle VMM data in a database (not shown) associated with the infrastructure system 110. It should be understood that the database may be located externally and / or internally relative to the infrastructure system 110.

[0069] The infrastructure-side AVM algorithm 112 is also configured to compute the checksum of the decoded raw reception at step 704. In one or more examples, the checksum of the decoded raw reception is computed based on the decoded VMM with an additional transformation constant appended to the checksum with respect to the new transformation. It should be understood that the additional transformation constant may be the same as the transformation constant appended to the SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant may be different from the transformation constant appended to the SharedvIDCSSecretKey at step 404. The infrastructure-side AVM algorithm 112 is also configured to recompute the SharedvIDAVSecretKey at step 704. In one or more examples, the SharedvIDAVSecretKey is recomputed based on the VIDAVpublicKey associated with the vehicle 102 (e.g., the vehicle-side public key).

[0070] The infrastructure-side AVM algorithm 112 is also configured at step 706 to perform UPER re-encoding on the VMM-related data concerning the VMM data and to compute the Re-TransformedSharedvIDAVSecretKey. In one or more examples, the re-transformed SharedvIDAVSecretKey is computed by appending the re-computed SharedvIDAVSecretKey to the transformation constant. It should be understood that the transformation constant can be the same as the transformation constant appended to the SharedvIDCSSecretKey at step 404. However, it should also be understood that the transformation constant can be different from the transformation constant appended to the SharedvIDCSSecretKey at step 404.

[0071] The infrastructure-side AVM algorithm 112 is further configured to recalculate the checksum at step 708 (e.g., the checksum described with respect to step 606). In one or more examples, the checksum is recalculated by appending the re-encoded data associated with the VMM regarding the VMM data to the Re-TransformedSharedvIDAVSecretKey. The infrastructure-side AVM algorithm 112 is also configured to recalculate the checksum of the new transformation at step 708 (e.g., the checksum of the new transformation described in step 608). In one or more examples, the checksum of the new transformation recalculated at step 708 represents the checksum of the new transformation described in step 608. Figure 2The fourth checksum value is described. In one or more examples, the checksum of the new transformation is recalculated by appending the recalculated checksum to the additional transformation constant. It should be understood that the additional transformation constant may be the same as the transformation constant appended to SharedvIDCSSecretKey at step 404. However, it should also be understood that the additional transformation constant may be different from the transformation constant appended to SharedvIDCSSecretKey at step 404.

[0072] The infrastructure-side AVM algorithm 112 is also configured at step 710 to determine (e.g., verify) whether the recalculated checksum matches (e.g., is the same) the decoded original received checksum. The infrastructure-side AVM algorithm 112 is also configured at step 710 to determine (e.g., verify) whether the recalculated checksum of the new transform matches (e.g., is the same) the decoded VMM with respect to the checksum of the new transform. The infrastructure-side AVM algorithm 112 is further configured at step 710 to determine (e.g., verify) whether the length of the re-encoded VMM UPER data matches (e.g., is the same) the length of the decoded VMM UPER data.

[0073] Figure 5 This is a flowchart illustrating an additional example method 800 for calculating and / or verifying the data integrity associated with one or more infrastructure grouping messages (IMMs) and one or more vehicle grouping messages (VMMs) exchanged between an automated vehicle (e.g., vehicle 102) and an infrastructure system (e.g., infrastructure system 110).

[0074] At operation 802, one or more processors of the infrastructure system are configured to compute a first checksum value. In one or more examples, the first checksum value is computed based on an infrastructure-side secret key and / or encoded data associated with an automated vehicle located within a distance-related threshold from the infrastructure system. As another example, the distance-related threshold can be any distance-related range from the infrastructure system within which the automated vehicle can maintain a communication link with the infrastructure system.

[0075] At operation 804, the infrastructure system is configured to transmit one or more IMMs to the automated vehicle. In one or more examples, the one or more IMMs include a second checksum value. As another example, and in one or more embodiments, the second checksum value is calculated based on a first checksum value and / or a transformation constant.

[0076] At operation 806, the infrastructure system is configured to receive one or more VMMs from an automated vehicle. In one or more examples, the one or more VMMs include a third checksum value. As another example, the third checksum value is calculated based on a vehicle-side secret key. As a further example, the third checksum value is calculated in response to the automated vehicle verifying one or more IMMs.

[0077] At operation 808, the infrastructure system is also configured to determine whether one or more VMMs have been verified. In one or more examples, verification of one or more VMMs includes at least decoding one or more VMMs. Verification of one or more VMMs also includes at least calculating a fourth checksum value. Verification of one or more VMMs also includes at least determining whether the fourth checksum value corresponds to a third checksum value.

[0078] In one or more examples, and where a determination is made that one or more VMMs have not been verified, the transmission of one or more IMMs is repeated (e.g., at operation 804). It should be understood that because operation 804 is repeated, the infrastructure system does not utilize the original transmission of one or more VMMs and can generate a report that may include any data-related information associated with one or more explanations as to why one or more VMMs were not verified. However, in other examples, and where a determination is made that one or more VMMs have been verified at operation 808, a communication link is established between the automated vehicle and the infrastructure system at operation 810.

[0079] Figure 6 This is another flowchart illustrating a further example method 900 for calculating and / or verifying the data integrity associated with one or more infrastructure grouping messages (IMMs) and one or more vehicle grouping messages (VMMs) exchanged between an automated vehicle (e.g., vehicle 102) and an infrastructure system (e.g., infrastructure system 110).

[0080] At operation 902, the vehicle handling system of the automated vehicle is configured to receive one or more IMMs. In one or more examples, in response to the automated vehicle being within a distance-related threshold from the infrastructure system, the one or more IMMs include a first checksum value based on an infrastructure-side secret key and / or encoded data associated with the automated vehicle. As another example, the distance-related threshold can be any distance-related range from the infrastructure system within which the automated vehicle can maintain a communication link with the infrastructure system.

[0081] At operation 904, one or more processors of the vehicle processing system are configured to verify one or more IMMs. At operation 906, the one or more processors of the vehicle processing system are further configured to determine whether the one or more IMMs have been verified. In one or more examples, verification of the one or more IMMs includes at least decoding the one or more IMMs. Verification of the one or more IMMs also includes at least calculating a fourth checksum. Verification of the one or more IMMs also includes at least determining whether the fourth checksum value corresponds to a first checksum value.

[0082] In one or more examples, and where a determination is made that one or more VMMs have been verified, one or more processors of the vehicle processing system are configured to compute a second checksum value at operation 908. In one or more examples, the second checksum value is computed based on a vehicle-side secret key and / or encoded data associated with the infrastructure system. As another example, the second checksum value is computed in response to verification of one or more IMMs.

[0083] At operation 910, the vehicle system is configured to transmit one or more VMMs to the infrastructure system. In one or more examples, the one or more VMMs include a third checksum value. As another example, and in one or more embodiments, the third checksum value is calculated based on a second checksum value and / or a transformation constant.

[0084] However, in other examples, and where a determination is made that one or more VMMs are not verified (e.g., at operation 906), the vehicle system is configured to transfer one or more VMMs to the infrastructure system (e.g., at operation 910) without calculating a second checksum value (e.g., at operation 908).

[0085] Figure 7An operating environment, such as a computer system, is shown that facilitates the execution of one or more systems and methods described herein. More specifically, the systems and methods described herein can be implemented using computing device 1002. For example, computing device 1002 can be a personal computer, desktop computer, laptop computer, tablet computer, handheld computer, server, workstation, mainframe, wearable computer, supercomputer, or a combination thereof. However, it should be understood that the foregoing examples of computing device 1002 are not exhaustive, and computing device 1002 can be any type of processing or computing device. Computing device 1002 typically includes a processor 1004, a display adapter 1006, one or more input / output ports 1008, one or more input / output components 1010, a network adapter 1012, a power supply 1014, and memory 1016. However, it should be understood that the computing device 1002 may include any additional components, and need not include any of the listed components (e.g., processor 1004, display adapter 1006, one or more input / output ports 1008, one or more input / output components 1010, network adapter 1012, power supply 1014, and memory 1016).

[0086] Processor 1004 is configured to provide instructions to computing device 1002, enabling computing device 1002 to process one or more tasks, including implementing software programs to perform one or more operations as described in more detail herein. It should also be understood that computing device 1002 may include any number of processors 1004. Display adapter 1006 may be a graphics card or video board that provides computing device 1002 with the ability to display content on display device 1018. For example, display device 1018 may be any screen, monitor, and / or light-emitting component associated with any of a personal computer, desktop computer, laptop computer, tablet computer, handheld computer, server, workstation, mainframe, wearable computer, supercomputer, or combinations thereof. However, it should be understood that the foregoing examples of display device 1018 are not exhaustive, and display device 1018 may be any type of device capable of providing visual display.

[0087] Input / output port 1008 provides multiple interfaces (e.g., jacks) for one or more cables to connect to computing device 1002. It should be understood that any number of input / output ports 1008 may be present on computing device 1002. For example, input / output port 1008 provides computing device 1002 with a means to receive signals and / or data from external devices connected to computing device 1002 via one or more cables. As another example, input / output port 1008 provides computing device 1002 with a means to transmit signals and / or data to external devices connected to computing device 1002 via one or more cables. Input / output component 1010 may include one or more components supporting input / output port 1008, such as, but not limited to, switches, buttons, pressure pads, float switches, keyboards, radio receivers, or combinations thereof.

[0088] Network adapter 1012 can be any type of network interface controller configured to provide means for communicating with another computing device (such as remote computing device 1022) via network 1020. For example, remote computing device 1022 can be a user device such as a cellular phone, smartphone, tablet computer, laptop computer, or a combination thereof. Power supply 1014 is configured to convert high-voltage alternating current (e.g., AC) into direct current (e.g., DC) to provide power to other components of computing device 1002 (e.g., processor 1004, display adapter 1006, one or more input / output ports 1008, one or more input / output components 1010, network adapter 1012, and memory 1016).

[0089] Additionally, memory 1016 may be a mass storage device and / or system memory, such as a hard disk drive, memory card, solid-state drive, random access memory (RAM), or a combination thereof. Memory 1016 is configured to provide storage for instructions and data associated with the operation of computing device 1002. Memory 1016 may typically include operating system 1024, computing / verification software 1026, and computing / verification data 1028. For example, operating system 1024 is configured to manage and / or process any of the data and / or instructions associated with computing / verification software 1026 and / or computing / verification data 1028, as described in more detail herein.

[0090] Furthermore, a system bus 1030 is also included within the computing device 1002, configured to couple each of the various components of the computing device 1002 (e.g., processor 1004, display adapter 1006, one or more input / output ports 1008, one or more input / output components 1010, network adapter 1012, power supply 1014, and memory 1016). It should also be understood that the functions associated with each component of the computing device 1002 and each component of the computing device 1002 can be implemented within a remote computing device 1022. Although Figure 7 The operating environment shown herein depicts a specific configuration associated with at least computing device 1002, network 1020, and remote computing device 1022; however, it should be understood that the operating environment can be configured in any manner.

[0091] Therefore, one or more examples of this disclosure provide a means for calculating and / or verifying one or more messages exchanged between an automated vehicle and a central server, thereby providing a secure means for exchanging one or more messages by utilizing a checksum process as described herein.

[0092] Unless otherwise expressly indicated herein, all numerical values ​​indicating mechanical / thermal properties, percentage of composition, dimensions and / or tolerances or other characteristics should be understood as being modified by the words “about” or “approximately” when describing the scope of this disclosure. Such modification is desired for various reasons, including: industrial practice; material, manufacturing and assembly tolerances; and testing capabilities.

[0093] As used herein, the phrases A, B, and C at least one should be interpreted as representing logic (A or B or C) using the non-exclusive logic "or", and should not be interpreted as representing "at least one of A, at least one of B, and at least one of C".

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

[0095] The term memory is a subset of the term computer-readable medium. As used herein, the term computer-readable medium does not cover transient electrical or electromagnetic signals propagated through a medium (such as on a carrier wave); therefore, the term computer-readable medium can be considered tangible and non-transient. Non-limiting examples of non-transient tangible computer-readable media include 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 magnetic tape or digital magnetic tape or hard disk drives), and optical storage media (such as CDs, DVDs, or Blu-ray discs).

[0096] The apparatus and methods described in this application can be implemented, in part or in whole, by a dedicated computer created by configuring a general-purpose computer to perform one or more specific functions embodied in a computer program. Function blocks, flowchart components, and other elements described above serve as software specifications that can be translated into computer programs through the routine work of a technician or programmer.

[0097] The description in this disclosure is merely exemplary in nature, and therefore, variations without departing from the spirit and scope of this disclosure are intended to be made within its scope. Such variations should not be considered as departing from the spirit and scope of this disclosure.

[0098] According to the present invention, a method for initiating autonomous control of an automated vehicle includes: receiving one or more infrastructure grouping messages including a first checksum value at a vehicle processing system of the automated vehicle in response to the automated vehicle being within a distance-related threshold of an infrastructure system; verifying the one or more infrastructure grouping messages; calculating a second checksum value based on a vehicle-side secret key and encoded data associated with the infrastructure system by one or more processors of the vehicle processing system; transmitting one or more vehicle grouping messages including a third checksum value based on the second checksum value to the infrastructure system; and wherein verifying the one or more infrastructure grouping messages includes: decoding the one or more infrastructure grouping messages; calculating a fourth checksum value based on the infrastructure-side secret key in response to decoding the one or more basic message grouping messages; and determining whether the fourth checksum value corresponds to the first checksum value.

[0099] In one aspect of the invention, the calculation of the second checksum value further includes: transforming the vehicle-side secret key by a transformation constant; and appending the transformed vehicle-side secret key to encoded data associated with the infrastructure system.

[0100] In one aspect of the invention, the method includes: calculating a third checksum value based on a transformation constant.

[0101] In one aspect of the invention, one or more vehicle grouping messages may further include encoded data associated with automated vehicles, data length associated with one or more vehicle grouping messages, or a combination thereof.

[0102] In one aspect of the invention, one or more infrastructure grouping messages may further include encoded data associated with the automated vehicle, data length associated with one or more infrastructure grouping messages, or a combination thereof.

[0103] In one aspect of the invention, decoding one or more infrastructure marshalling messages further includes: decoding a first checksum value; decoding the data length associated with one or more infrastructure marshalling messages; and decoding encoded data associated with an infrastructure system.

[0104] In one aspect of the invention, verification of one or more infrastructure marshalling messages further includes: transforming the decoded first checksum value by a transformation constant; recalculating the infrastructure-side secret key based on the infrastructure-side public key; re-encoding one or more infrastructure marshalling messages; and / or re-transforming the transformed first checksum value by a transformation constant.

[0105] In one aspect of the invention, the calculation of the fourth checksum further includes: appending the recalculated infrastructure-side secret key to one or more re-encoded infrastructure marshalling messages; and transforming the re-transformed first checksum value by a transformation constant.

[0106] In one aspect of the invention, verification of one or more infrastructure marshalling messages further includes determining whether the data length associated with the re-encoded one or more infrastructure marshalling messages corresponds to the data length associated with the decoded data length.

Claims

1. A method for initiating autonomous control of an automated vehicle, the method comprising: A first checksum value is calculated by one or more processors of the infrastructure system based on an infrastructure-side secret key and encoded data associated with the automated vehicle located within a distance-related threshold from the infrastructure system; Transmit one or more infrastructure marshalling messages to the automated vehicle, including a second checksum value based on the first checksum value; In response to the automated vehicle verifying the one or more infrastructure grouping messages, one or more vehicle grouping messages including a third checksum value based on a vehicle-side secret key are received from the automated vehicle; as well as Verify the one or more vehicle grouping messages, wherein the verification of the one or more vehicle grouping messages includes: Decode the one or more vehicle grouping messages. In response to decoding the one or more vehicle grouping messages, a fourth checksum value is calculated based on the vehicle-side secret key, and Determine whether the fourth checksum value corresponds to the third checksum value.

2. The method of claim 1, wherein the calculation of the first checksum value further comprises: The infrastructure-side secret key is transformed by transforming constants; as well as The transformed infrastructure-side secret key is attached to the encoded data associated with the automated vehicle.

3. The method of claim 1, further comprising: The second checksum value is calculated based on the transformation constant.

4. The method of claim 1, wherein the one or more infrastructure grouping messages further include the encoded data associated with the automated vehicle, the data length associated with the one or more infrastructure grouping messages, or a combination thereof.

5. The method of claim 1, wherein the one or more vehicle grouping messages further include the encoded data associated with the automated vehicle, the data length associated with the one or more vehicle grouping messages, or a combination thereof.

6. The method of claim 1, wherein decoding the one or more vehicle grouping messages further comprises: Decode the third checksum value; Decode the data length associated with the one or more vehicle grouping messages; as well as The encoded data associated with the automated vehicle is decoded.

7. The method of claim 6, wherein the verification of the one or more vehicle grouping messages further comprises: The decoded third checksum value is transformed by transforming a constant; The vehicle-side secret key is recalculated based on the vehicle-side public key; The one or more vehicle grouping messages are re-encoded; as well as The transformed third checksum value is then re-transformed using the transformation constant.

8. The method of claim 7, wherein the calculation of the fourth checksum value further comprises: The recalculated vehicle-side secret key is appended to one or more re-encoded vehicle grouping messages; as well as The transformed third checksum value is transformed using the transformation constant.

9. The method of claim 7, wherein the verification of the one or more vehicle grouping messages further comprises: Determine whether the data length associated with the re-encoded one or more vehicle grouping messages corresponds to the data length associated with the decoded data length.

10. The method of claim 1, further comprising: A communication link between the automated vehicle and the infrastructure system is established based on successfully determining that the fourth checksum value corresponds to the third checksum value.

11. A system for initiating autonomous control of an automated vehicle, the system comprising: One or more processors in an infrastructure system, said one or more processors being configured to: A first checksum value is calculated based on the infrastructure-side secret key and encoded data associated with the automated vehicle located within a distance-related threshold from the infrastructure system. The transmission includes one or more infrastructure marshalling messages based on a second checksum value based on the first checksum value. In response to the vehicle verifying the second checksum value, one or more vehicle grouping messages are received, including a third checksum value based on the vehicle-side secret key. Verify the one or more vehicle grouping messages; and The vehicle processing system of the automated vehicle is configured to: Receive one or more infrastructure grouping messages, Verify the one or more infrastructure marshalling messages. In response to the verification of the one or more infrastructure grouping messages, the third checksum value is calculated based on the vehicle-side secret key and encoded data associated with the infrastructure system. Transmit the one or more vehicle grouping messages.

12. The system of claim 11, wherein the one or more infrastructure grouping messages further include the encoded data associated with the automated vehicle, the data length associated with the one or more infrastructure grouping messages, or a combination thereof.

13. The system of claim 11, wherein the one or more vehicle grouping messages further include the encoded data associated with the automated vehicle, the data length associated with the one or more vehicle grouping messages, or a combination thereof.

Images