Encryption-based platooning mechanism for autonomous driving fleet management

Abstract

Techniques for managing a queue of autonomous vehicles are disclosed. In one embodiment, a method is disclosed, comprising: establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a queue; receiving a request from a first autonomous vehicle to deviate from the queue, the request comprising a digitally signed message from the first autonomous vehicle; assigning the first autonomous vehicle as a second master autonomous vehicle; permanently recording the assignment in a blockchain data structure; instantiating a new queue path using the first autonomous vehicle as a head of the new queue path; and upon determining that the new queue path is stable, disconnecting one or more autonomous vehicles associated with the new queue path, the disconnection causing the second master autonomous vehicle to manage the one or more autonomous vehicles using a second blockchain stored on the second master autonomous vehicle.

Description

[0001] Related Applications

[0002] This application claims the benefit of an application filed on March 25, 2019 and entitled “CRYPTOGRAPHY-BASED PLATOONING MECHANISM FOR AUTONOMOUS VEHICLEFLEET MANAGEMENT,” the entire disclosure of which is hereby incorporated by reference herein.

[0003] Copyright Notice

[0004] This application contains material which is subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and Trademark Office files or records, but otherwise reserves all copyright rights whatsoever. Background Art

[0005] The disclosed embodiments relate to autonomous vehicles, and in particular, to systems and methods for managing a fleet of autonomous vehicles.

[0006] With the advent of autonomous vehicles, a variety of new technical problems and their solutions have emerged. Since autonomous vehicles are programmatically controlled, one of these new solutions is the concept of "platooning" autonomous vehicles. During platooning, autonomous vehicles are closely positioned in motion with other autonomous vehicles. Typically, all movements of autonomous vehicles are synchronized with each other to maintain this tight formation throughout the route.

[0007] Platooning has numerous advantages over manually driven vehicles. In general, platooning increases the capacity of a road. When driven by a human, vehicles are advised (or required) to maintain a safe following distance (e.g., three car lengths). This distance is used only to compensate for delayed human reaction to sudden stops or other hazards. Therefore, large portions of the road are "unused," i.e., used primarily to buffer vehicles. Platooning eliminates this buffer space and allows the entire road to be used by lining up vehicles close to each other.

[0008] Additionally, platooning reduces fuel consumption and improves the fuel efficiency of the platoon due to reduced air resistance, and reduces the likelihood of accidents due to, for example, the elimination of vehicles overtaking each other.

[0009] Currently, one type of solution for implementing platooning typically relies on centralized servers and the use of GPS measurements. For example, a central station can receive the position of a vehicle and calculate the positions of other vehicles in the platoon. These calculated positions are then transmitted to control the position of each vehicle based on the first vehicle. However, such solutions suffer from significant delays in transmitting data from autonomous vehicles to the network operations center (NOC), which can have a negative and, in some cases, fatal impact on the platoon.

[0010] Another class of solutions utilizes vehicle-to-vehicle (V2V) communication links to coordinate platoons. In general, these solutions rely on protocols that are at least partially based on the Dedicated Short Range Communication (DSRC) protocol. Although the use of DSRC-based protocols removes the strong reliance on the NOC, the protocol is (by default) insecure and can be manipulated. In addition, the protocol itself is ephemeral and does not provide data storage that can be shared among the platoon.

[0011] Therefore, there is a need in the current state of the art for a secure, decentralized system and method for managing a queue of vehicles. Summary of the invention

[0012] Disclosed herein are methods, computer-readable media, and devices for managing a fleet of autonomous vehicles using an encryption and blockchain data storage layer.

[0013] In one embodiment, a method is disclosed, comprising: establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a queue; receiving a request from a first autonomous vehicle to deviate from the queue, the request comprising a digitally signed message from the first autonomous vehicle; assigning the first autonomous vehicle as a second master autonomous vehicle; permanently recording the assignment in a blockchain data structure; instantiating a new queue path using the first autonomous vehicle as a leader of the new queue path; and upon determining that the new queue path is stable, disconnecting one or more autonomous vehicles associated with the new queue path, the disconnection causing the second master autonomous vehicle to manage the one or more autonomous vehicles using a second blockchain stored on the second master autonomous vehicle.

[0014] In another embodiment, an apparatus is disclosed that includes: a processor; and a storage medium for tangibly storing program logic thereon for execution by the processor, the stored program logic including: logic executed by the processor for establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a queue; logic executed by the processor for receiving a request from a first autonomous vehicle to deviate from the queue, the request comprising a digitally signed message from the first autonomous vehicle; logic executed by the processor for assigning the first autonomous vehicle as a second master autonomous vehicle; logic executed by the processor for permanently recording the assignment in a blockchain data structure; logic executed by the processor for instantiating a new queue path using the first autonomous vehicle as a leader of the new queue path; and logic executed by the processor for disconnecting one or more autonomous vehicles associated with the new queue path when it is determined that the new queue path is stable, the disconnection causing the second master autonomous vehicle to manage the one or more autonomous vehicles using a second blockchain stored on the second master autonomous vehicle.

[0015] In another embodiment, a non-transitory computer-readable storage medium is disclosed for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the following steps: establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a queue; receiving a request from a first autonomous vehicle to deviate from the queue, the request comprising a digitally signed message from the first autonomous vehicle; assigning the first autonomous vehicle as a second master autonomous vehicle; permanently recording the assignment in a blockchain data structure; instantiating a new queue path using the first autonomous vehicle as a leader of the new queue path; and upon determining that the new queue path is stable, disconnecting one or more autonomous vehicles associated with the new queue path, the disconnection causing the second master autonomous vehicle to manage the one or more autonomous vehicles using a second blockchain stored on the second master autonomous vehicle. BRIEF DESCRIPTION OF THE DRAWINGS

[0016] The foregoing and other objects, features and advantages of the present disclosure will be apparent from the following description of the embodiments illustrated in the accompanying drawings, wherein reference characters refer to the same parts throughout the various views. The drawings are not necessarily drawn to scale, emphasis instead being placed upon illustrating the principles of the present disclosure.

[0017] Figure 1 is a diagram illustrating an autonomous vehicle platoon according to some embodiments of the present disclosure.

[0018] Figures 2A to 2C Autonomous vehicle platoon changes according to some embodiments of the present disclosure are described.

[0019] Figure 3A is a flow chart illustrating a method for processing a queue change request message according to some embodiments of the present disclosure.

[0020] Figure 3B is a flow chart illustrating a method for changing a queue according to some embodiments of the present disclosure.

[0021] Figure 4 is a diagram of an autonomous vehicle blockchain and block layout according to some embodiments of the present disclosure.

[0022] Figure 5 is a block diagram of an autonomous vehicle according to some embodiments of the present disclosure. DETAILED DESCRIPTION

[0023] Figure 1 is a diagram illustrating an autonomous vehicle platoon according to some embodiments of the present disclosure.

[0024] Figure 1 Each of the autonomous vehicles (102a to 102n) is equipped with an encryption subsystem and a messaging subsystem, such as Figure 4 As described in . The autonomous vehicles (102a to 102n) are configured to establish a vehicle self-organizing network (VANET) between each of the autonomous vehicles (102a to 102n). In one embodiment, a dedicated short-range communication (DSRC) or 5G LTE communication channel can be used to create a VANET. Alternatively, or in combination with the foregoing, the autonomous vehicles (102a to 102n) can be connected to a centralized network via a cellular, satellite, mesh network, or other network connection. In general, the disclosed embodiments are not intended to be limited to the specific type of network employed, as long as each of the autonomous vehicles (102a to 102n) can transmit messages to one or more autonomous vehicles (102a to 102n). Although the following description provides examples of autonomous vehicles, other types of vehicles should be considered to fall within the scope of the present disclosure, such as ships, aircraft, drones, etc.

[0025] In order for autonomous vehicles (102a-102n) to communicate with each other, a mechanism is needed to ensure the authenticity of messages. Without this mechanism, autonomous vehicles (102a-102n) will be affected by malicious or false messages, causing them to deviate from the queue. For example, an attacker can spoof messages to cause some or all autonomous vehicles (102a-102n) to divert to a location selected by the attacker. In addition, in a platooning setting, a single vehicle controls the queue (i.e., the leading vehicle), and therefore the entire queue of vehicles is subject to a single point of failure. Therefore, the integrity of the communication between vehicles is critical.

[0026] Each autonomous vehicle (102a to 102n) is equipped with an encryption subsystem. Figure 1 1, each autonomous vehicle (102a-102n) is illustrated as being equipped with a Device Identifier Composite Engine (DICE) and Robust Internet of Things (RIoT) (collectively referred to as "DICE-RIoT") subsystem. Only one such subsystem (104) is illustrated, but each autonomous vehicle (102a-102n) may be equipped with such a subsystem. In other embodiments, various other types of systems may be used, such as a Trusted Platform Module (TPM) system. However, due to the lower hardware requirements of the system, a DICE-RIoT system may be utilized.

[0027] This article provides a brief overview of the DICE-RIoT architecture. Each DICE-RIoT subsystem (104) contains a device secret (106). The DICE functionality in the DICE-RIoT subsystem (104) creates a secret value called a composite device identity (CDI) and passes it to the L in read-only memory (ROM). 0 (Layer 0) RIoT Core (108). The CDI is typically a 32-byte value generated using the SHA256 hash function based on a hash of the per-device secret and the RIoT Core (108). Alternative implementations may utilize other cryptographic one-way functions and generate other values ​​of different lengths. The RIoT Core (108) uses the CDI to derive additional keys and secrets, and then deletes the CDI from RAM and registers. In some embodiments, the RIoT Core (108) never changes, so the CDI remains unchanged for the life of the device. In another embodiment, the RIoT Core (108) can be securely updated, generating a new, unique CDI.

[0028] The RIoT core (108) additionally creates an asymmetric DeviceID key pair using a deterministic key generation function embedded in the CDI. In addition, the RIoT core (108) generates an encrypted device identifier and certificate. The device identifier, certificate, and public DeviceID key are exported to a layer 1 (L2) executed, for example, in an operating system (OS) of the autonomous vehicle (102a). 1 ) software (110). In addition, the RIoT core (108) creates a certificate containing the DeviceID public key. The certificate allows other devices to confirm that the DeviceID public key is consistent with the L 0 and L 1 Layer associated. In one embodiment, the RIoT Core (108) signs the certificate using the DeviceID private key. In another embodiment, the RIoT Core (108) creates a certificate signing request ("CSR") structure (e.g., a PKCS10 request) for the DeviceID public key, signed by the DeviceID private key.

[0029] In the illustrated embodiment, the RIoT Core (108) exports the DeviceID public key, certificate, and vehicle identifier to the L 1 Software (110). As described herein, L 0 and L 1 Layer refers to the software or firmware executed on the guided vehicle (102a), and L 2 refers to the layer on the second vehicle (102b), L 3 refers to the layer on the third vehicle (102c), and so on. This triple is usually represented as {ID Lk Public, ID Lk Certificate, K Lk In the illustrated embodiment, L 1 The software (110) may include system-level or user-level code. There is no limitation on the specific nature of the code. However, as will be described, L 1 One of the main functionalities of the software (110) is to coordinate the queue information of the queue. 0 Firmware (108) and L 1 The software (110) resides on the "lead" vehicle of the queue. 2 The code (112) and higher level code (114, 116, 118) reside on other vehicles. How the autonomous vehicle (102a) becomes the leader is described in more detail below, but in one embodiment, the leader may be statically assigned at the beginning of a route (e.g., if a "convoy" of autonomous vehicles leaves from a safe location). 1The software (110) may include a flash image of the platoon code that handles the transmission of platoon data to one or more other autonomous vehicles (102b to 102n). In one embodiment, this data includes data such as the lead vehicle's speed, road conditions, braking information, and any other information relevant to the platoon.

[0030] In one embodiment, as described above, the lead autonomous vehicle (102a) transmits the message via a VANET or another network. Alternatively, or in combination with the foregoing, the lead autonomous vehicle (102a) transmits the message via broadcasting the message to a blockchain. In some embodiments, the blockchain comprises a public, private, or consortium blockchain. The blockchain may be built based on the Ethereum blockchain or any other suitable blockchain technology. When used in conjunction with a VANET, the autonomous vehicles (102a to 102n) may simultaneously transmit the message via the VANET and also publish the message to the blockchain (for record keeping purposes).

[0031] Regardless of the transmission, in the illustrated embodiment, each message is digitally signed using the sender's private key generated as described above. Additionally, in some embodiments, the message itself is encrypted using the recipient's public key. In one embodiment, each autonomous vehicle (102a-102n) broadcasts a message with its public key and certificate to the blockchain, allowing each vehicle to access any vehicle public key. Since the blockchain is verified by each peer, the inherent security in the blockchain paradigm ensures that public keys, certificates, and identifiers are valid. Alternatively, a trusted central repository can be utilized to record known public keys, vehicle identities, and certificates.

[0032] In the illustrated embodiment, the queue of autonomous vehicles (102a-102n) transmits messages sequentially. That is, the lead autonomous vehicle (102a) transmits operating instructions to the second autonomous vehicle (102b), which in turn transmits instructions to the third autonomous vehicle (102c), and so on. However, as will be discussed below, there is no limitation on the manner in which messages are delivered (particularly when queue changes occur). Figure 1 The DICE-RIoT protocol is used to protect messages exchanged between autonomous vehicles (102a to 102n). At each layer (e.g., autonomous vehicle) (110, 112, 114, 116, 118), the transmitted messages are digitally signed using a key generated by the autonomous vehicle (102a to 102n). Specifically, at each layer, a one-way function is used to generate a value K L1 ,…K Ln Specifically, using the formula K L1 =KDF(DS,Hash(L 1 Calculate K L1, where DS is the device secret (108), and the hash (L 1 ) is a cryptographic hash of the code operated at layer 1. The function KDF may include a one-way hash function, such as an HMAC function. As the message progresses through the layers, a similar formula K Ln =KDF(K Ln-1 ,Hash(L n )) Calculate each key. Therefore, the derived key K L1 Depends on device confidentiality and L 1 Since the device secret uniquely identifies the device hardware, the program L 1 K can be used in the proof of possession protocol 1 to prove to the manufacturer the identity of the platform and the cryptographic identity of the code it is running. 1 Can be used for both device and software authentication. Layer-derived keys can also be used to protect private data. 1 Can use K 1 Encrypt and protect the integrity of locally stored data—a security primitive called sealing. KDF-based key derivation schemes provide excellent protection against malware that attempts to obtain the decryption key and decrypt the data. For example, if an attacker can replace L 1 To receive or extract K 1 , then the attacker will obtain a different key and will not be able to decrypt previously stored data. This is because the derived key is based on the identity of the component that received the key.

[0033] In one embodiment, the hash (L n ) value includes the firmware ID (FWID) of the layer n software. Alternatively, or in combination with the foregoing, the hash (L n ) value includes a hardware identifier and / or a vehicle identification number and / or any other identifier associated with the vehicle. In some embodiments, each autonomous vehicle FWID may be recorded in a blockchain that allows authentication by other autonomous vehicles. As described above, one layer provides a key based on a hash of the layer's code to the next layer. Therefore, the layer that generates the key must retrieve the hash from the vehicle or a secure storage mechanism (e.g., blockchain). By utilizing a distributed storage mechanism such as a blockchain, the various layers of the DICE-RIoT architecture (which are typically executed on the same device) can be distributed.

[0034] Consider K performed by layer 1 L2 The code executed in layer 1 will execute K L2 =KDF(K L1 ,Hash(L 2 )) operation. In one embodiment, hash (L 2 ) including L2 The FWID (software on the external vehicle) is broadcast on the blockchain and retrieved by the code of layer 1. Since the blockchain storage has been previously authenticated, layer 1 can determine that this FWID is accurate and can therefore use the FWID and its own key to generate the next key K L2 In one embodiment, the FWID is generated using the standard DICE-RIoT mechanism (ie, Firmware Security Descriptor), the details of which are not included herein.

[0035] Figures 2A to 2C Autonomous vehicle platoon changes according to some embodiments of the present disclosure are described.

[0036] exist Figure 2A , there exists a first path (202) between autonomous vehicles (102a-102n). As described above, this path (202) represents an ordered communication flow of platoon data (e.g., speed, direction, etc.). In the illustrated embodiment, commands are issued by the lead autonomous vehicle (102a) and passed along the path (202) until reaching the last vehicle (102n).

[0037] exist Figure 2B , autonomous vehicle (102b) issues a request to become the lead autonomous vehicle of the second platoon. For example, autonomous vehicles (102b, 102d) may be changing routes at an intersection and will therefore deviate from the platoon represented by autonomous vehicles (102a, 102c, 102n). Although autonomous vehicles (102b, 102d) are no longer illustrated in a platoon formation, this is only to illustrate the logical distinction between platoons.

[0038] During this transition phase, two new paths (204, 206) are formed representing the new queue. These new paths (204, 206) are maintained along with the original path (202). During this phase, the lead vehicle (102a) may continue to control the operation of all vehicles (102b to 102n) until the handover to the second lead vehicle (102b) is completed.

[0039] exist Figure 2C The transition to two queues is now complete. Now, the original path (202) has been destroyed and the new paths (204, 206) have been confirmed. In this state, the leading autonomous vehicles (102a, 102b) control their respective queues, such as Figure 2A Like in.

[0040] Figure 3A is a flow chart illustrating a method for processing a queue change request message according to some embodiments of the present disclosure.

[0041] In step 302 , the method operates a platoon of autonomous vehicles.

[0042] In one embodiment, a queue includes a lead or master autonomous vehicle and one or more other autonomous vehicles. These autonomous vehicles are arranged in a chain or path of autonomous vehicles. The lead autonomous vehicle is responsible for managing and planning the route. It transmits control messages to the second autonomous vehicles in the path of the autonomous vehicles. These control messages provide, for example, the speed of the lead autonomous vehicle, routing information for the lead autonomous vehicle, and any other relevant information.

[0043] In step 304, the method receives a request from one or more autonomous vehicles to deviate from the queue.

[0044] In one embodiment, this request is received by the lead autonomous vehicle, but in other embodiments it may be initially received from a centralized system. In one embodiment, the request received in step 304 is a digitally signed request, where the request is signed by the private key of the autonomous vehicle that is allegedly issuing the request. As described above, this private key may be generated using the DICE-RIoT architecture, and may therefore be guaranteed to be secure.

[0045] In step 306, the method authenticates the request.

[0046] In one embodiment, step 306 is performed by the current leading autonomous vehicle of the queue. In one embodiment, the leading autonomous vehicle maintains a blockchain that stores all details about the autonomous vehicles in the queue. For example, these details may include the public keys and certificates of all autonomous vehicles in the queue. In step 306, the leading autonomous vehicle receives a deviation request signed using the private key of one of the autonomous vehicles in the queue. The request may additionally include a vehicle identifier (ID) or another identifier. The leading autonomous vehicle retrieves the public key associated with the vehicle ID and attempts to verify the signature, thereby verifying that the request is indeed from the autonomous vehicle claiming to make the request. In some embodiments, the request may further include a list of autonomous vehicles that will follow the autonomous vehicle making the request. In other embodiments, the current leading vehicle may broadcast a notification that a change is to be made and request any autonomous vehicle joining the new queue to identify itself. The leading autonomous vehicle can then verify the new queue autonomous vehicle by performing a similar verification using the digital signature of the autonomous vehicle.

[0047] If the lead autonomous vehicle cannot verify the request (i.e., the digital signature is fraudulent), then the method rejects the request (step 310). In some embodiments, the method may further log the unauthorized request and any details associated with the request (e.g., Internet Protocol (IP) address). In one embodiment, these details are recorded to a blockchain data structure to ensure that the data has not been tampered with.

[0048] If the lead autonomous vehicle determines that the request is valid (i.e., the digital signature is valid), the method continues by assigning the requesting autonomous vehicle as the new master vehicle in step 312. At this stage, the original platoon is still intact, and the second master autonomous vehicle cannot control the new platoon autonomous vehicle.

[0049] In step 314, the lead autonomous vehicle records the change to the queue in the blockchain data structure. Figure 4 is a diagram of an autonomous vehicle blockchain and block layout according to some embodiments of the present disclosure.

[0050] exist Figure 4 In the blockchain illustrated in , a plurality of blocks (401-405) and a genesis block (400) are illustrated. As is known in the art, a blockchain represents an immutable and cryptographically verified record of changes in transactions or data states. In real-time applications, each time a change to a queue is made, the change is recorded to the blockchain. In one embodiment, only selected autonomous vehicles access the blockchain. For example, only the current lead autonomous vehicle can participate in the consensus algorithm employed by the blockchain. In this way, all changes to the queue data are verified and recorded for future retrieval when needed. In addition, the inherent verification of the blockchain ensures that rogue entities do not maliciously attempt to publish queue changes. This is guaranteed by the use of DICE-RIoT keys as blockchain addresses, as the DICE-RIoT keys cannot be compromised or tampered with.

[0051] Figure 4The contents of the blocks (403) in the chain are additionally described. As described, each block includes a primary ledger block header (403A), which includes a hash of the current block and a hash of the previous block. As used herein, this header (403A) corresponds to a master blockchain stored by an organization that manages multiple queues. In this context, the master ledger refers to a ledger that stores all queue changes. In contrast, the ledger of the master autonomous vehicle block header (403B) stores a local blockchain for a given queue. As described above, in one embodiment, a given lead autonomous vehicle manages the queues and associated blockchains. Therefore, when a queue change is added to the local blockchain, the lead autonomous vehicle generates its own block header. As described, the master block header (403B) includes the vehicle identification number (VIN) of the master autonomous vehicle, the current and previous block hashes, and the block signature (signed using the master autonomous vehicle private key).

[0052] In the body of the block (403), a triplet is stored comprising a vehicle identifier (403C), a certificate (403D) and a public key (403E). This triplet represents the destination autonomous vehicle of the message or transaction stored in the block. The block additionally comprises a timestamp (403F) associated with the timing of the message contained in the block.

[0053] Additionally included in the block is service information (403G) representing the contents of a message sent to the vehicle identified by the triples (403C to 403E). In the illustrated embodiment, the service information includes the current path the vehicle is on. The service information may also include a disconnection point, such as specific geographic coordinates at which the vehicle should disconnect from the queue. The service information may also include the current active master of the queue (i.e., the lead autonomous vehicle represented by a vehicle identifier, certificate, or public key). The service information may also include an identifier (i.e., triple) of the next lead or master autonomous vehicle after disconnecting from the main queue.

[0054] Finally, each block is signed by the sender (e.g., the lead autonomous vehicle), and the signature is packaged and included in the block as a packaged digital signature (403H). In the illustrated embodiment, the signature (403H) is signed using the sender private key and verified by the receiver using the receiver public key.

[0055] Back to Figure 3A ,As part of recording the replacement queue information, the blockchain is inherently transmitted to all queue members.

[0056] Therefore, in step 316, the method transmits a replacement queue notification to all queue vehicles managed by the lead autonomous vehicle. In one embodiment, this notification may include the service information discussed above. In some embodiments, the autonomous vehicle may receive this information via a DSRC or 5G LTE network. However, the autonomous vehicle may alternatively receive the information via a block added to the blockchain. However, if the blockchain is used to distribute the service information, the method may use a faster consensus algorithm compared to the traditional proof of work (PoW) method. For example, the method may use event proof together with dynamic alliance consensus to quickly confirm new blocks. During consensus, DICE-RIoT, which ensures the authenticity of the message, may also be used to bypass stricter security checks.

[0057] Figure 3B is a flow chart illustrating a method for changing a queue according to some embodiments of the present disclosure.

[0058] In step 318, the method initializes a replacement queue connection. In one embodiment, this is performed by the current queue leader autonomous vehicle. In one embodiment, the replacement queue connection includes a list of autonomous vehicles in the new queue and an identifier of the new master autonomous vehicle.

[0059] In step 320, the method distributes the alternative queue connection to all other vehicles in the queue. Notably, this step distributes the alternative queue plan to all other vehicles, not just the vehicles involved in the new queue. In this way, each autonomous vehicle has a record of the queue change. In some embodiments, each vehicle may be involved in confirming the validity of the queue change via a blockchain consensus algorithm.

[0060] In step 322, the method continues with the existing platoon. In this step, all vehicles maintain the platoon formation. In one embodiment, the existing lead autonomous vehicle may continue to broadcast platoon control commands while the handover occurs.

[0061] In step 324, the method determines whether the queue change is stable. In one embodiment, determining whether the queue change is stable includes ensuring that the queue change has been verified by peers on the blockchain. In some embodiments, the method requires only a single block verification. In other embodiments, the method may require double or multiple block verifications before executing the queue change. In this way, the method ensures that rogue blocks are not added to the chain and invalid queue changes are made. As illustrated, the method continues with the existing queue until the new queue is stabilized.

[0062] Once the new queue is verified and recorded in the blockchain, the method disconnects the new queue from the original queue (step 326). In one embodiment, this may be performed by the original master autonomous vehicle, or may be performed by the new master. In one embodiment, the disconnection is pre-established as part of the service information. For example, the service information may be included in the block, and this service information includes the specific point where the new queue should be disconnected from the master queue.

[0063] In step 328, the method transfers mastership to the new queue leader.

[0064] In one embodiment, as part of the handover, the new master assumes the role of managing the local blockchain of the new queue. Thus, the new queue leader autonomous vehicle can perform all previous operations using the newly established blockchain.

[0065] In step 330, the new queue and the original queue proceed according to the route information associated with each queue (as previously discussed).

[0066] Figure 5 is a block diagram of an autonomous vehicle according to some embodiments of the present disclosure.

[0067] Figure 5 The system described in may be fully installed in a vehicle. In some embodiments, some components (eg, components and subsystems other than subsystem (504)) may include existing autonomous subsystems.

[0068] The system includes an autonomous subsystem (502). In the illustrated embodiment, the autonomous subsystem (502) includes a map database (502A), a radar device (502B), a laser radar device (502C), a digital camera (502D), a sonar device (502E), a GPS receiver (502F), and an inertial measurement unit (502G). Each of the components of the autonomous subsystem (502) includes standard components provided in most current autonomous vehicles. In one embodiment, the map database (502A) stores multiple high-definition three-dimensional maps for routing and navigation. The radar device (502B), the laser radar device (502C), the digital camera (502D), the sonar device (502E), the GPS receiver (502F), and the inertial measurement unit (502G) may include various corresponding devices installed at different locations throughout the autonomous vehicle as known in the art. For example, these devices may be installed along the perimeter of the autonomous vehicle to provide location awareness, collision avoidance, and other standard autonomous vehicle functionality.

[0069] Vehicle subsystems (506) are additionally included in the system. Vehicle subsystems (506) include various anti-lock braking systems (506A), an engine control unit (506B), and a transmission control unit (506C). These components can be used to control the operation of the autonomous vehicle in response to streaming data generated by the autonomous subsystem (502). Standard autonomous vehicle interactions between the autonomous subsystem (502) and the vehicle subsystem (506) are well known in the art and are not described in detail herein.

[0070] The processing side of the system includes one or more processors (510), short-term memory (512), an RF system (514), a graphics processing unit (GPU) (516), long-term storage (518), and one or more interfaces (520).

[0071] The one or more processors (510) may include a central processing unit, an FPGA, or any range of processing devices required to support the operation of the autonomous vehicle. The memory (512) includes DRAM or other suitable volatile RAM for temporarily storing data required by the processor (510). The RF system (514) may include a cellular transceiver and / or a satellite transceiver. The long-term storage device (518) may include one or more high-capacity solid-state drives (SSDs). In general, the long-term storage device (518) can be used to store, for example, high-definition maps, routing data, and any other data that requires permanent or semi-permanent storage. The GPU (516) may include one or more high-throughput GPU devices for processing data received from the autonomous subsystem (502). Finally, the interface (520) may include various display units (e.g., screens on the dashboard) located within the autonomous vehicle.

[0072] The system additionally includes a queue subsystem (504) that performs all queue operations required for the methods described in the previous figures. The queue subsystem (504) includes a blockchain storage device (504) that is connected to a bus (508) and processes and stores blockchain data transmitted on the bus (508).

[0073] The queue subsystem (504) additionally includes a key generator (504B). In one embodiment, the key generator (504B) is configured with ROM-based components and software-based components to generate keys (including keys for multiple levels of the DICE-RIoT-based system).

[0074] The platooning subsystem (504) additionally includes a message processor (504C). In one embodiment, the message processor (504C) is configured to broadcast, unicast, or multicast a message to one or more autonomous vehicles.

[0075] Each of the devices is connected via a bus (508). In one embodiment, the bus (508) may include a controller area network (CAN) bus. In some embodiments, other bus types may be used (e.g., FlexRay or MOST buses). Additionally, each subsystem may include one or more additional buses to handle inter-subsystem communications (e.g., a LIN bus for lower bandwidth communications).

[0076] However, the subject matter disclosed above may be embodied in a variety of different forms, and thus the covered or claimed subject matter is intended to be construed as not limited to any example embodiments set forth herein; the example embodiments are provided merely to be illustrative. Likewise, a reasonably broad scope of the claimed or covered subject matter is contemplated. For example, the subject matter may be embodied as a method, device, component, or system, among other things. Thus, embodiments may, for example, take the form of hardware, software, firmware, or any combination thereof (except software itself). Thus, the following detailed description is not intended to be construed in a limiting sense.

[0077] Throughout the specification and claims, terms may have nuanced meanings that are suggested or implied by the context beyond what is explicitly stated. Likewise, the phrase "in one embodiment" as used herein does not necessarily refer to the same embodiment and the phrase "in another embodiment" as used herein does not necessarily refer to a different embodiment. For example, it is intended that claimed subject matter includes, in whole or in part, a combination of example embodiments.

[0078] In general, terms may be understood at least in part based on the context in which they are used. For example, terms such as "and", "or" or "and / or" as used herein may include multiple meanings, which may depend at least in part on the context in which such terms are used. Typically, "or", if used in an associated list, such as A, B or C, is intended to indicate that A, B and C are used in an inclusive sense here, and also indicates that A, B or C are used in an exclusive sense here. In addition, the term "one or more" used herein may be used to describe any feature, structure or characteristic in a singular sense or may be used to describe a combination of features, structures or characteristics in a plural sense, depending at least in part on the context. Similarly, terms such as "a / an" or "the" may also be understood to express singular use or plural use, depending at least in part on the context. In addition, the term "based on" may be understood to not necessarily wish to express a set of exclusive factors, and may alternatively allow for the presence of additional factors that are not necessarily explicitly described, which also depends at least in part on the context.

[0079] The present disclosure is described with reference to the block diagram and operation description of method and device.It should be understood that the combination of each frame of block diagram or operation description and the frame in block diagram or operation description can be implemented by analog or digital hardware and computer program instructions.These computer program instructions can be provided to the processor of general-purpose computer to change its function as described in detail herein, be provided to special-purpose computer, ASIC or other programmable data processing equipment, so that the instruction execution of the processor of computer or other programmable data processing equipment implements the function / action specified in the block diagram or operation frame.In some alternative embodiments, the function / action marked in the frame may not appear in the order marked in the operation description.For example, two frames of continuous display can actually be performed substantially simultaneously, or frames can sometimes be performed in reverse order, depending on the functionality / action involved.

[0080] These computer program instructions may be provided to a processor of: a general-purpose computer to change its functionality to a special purpose; a special-purpose computer; an ASIC; or other programmable digital data processing device, so that the instructions executed by the processor of the computer or other programmable data processing device implement the functions / actions specified in the block diagram or operation block, thereby converting its functionality according to the embodiments of the present invention.

[0081] For the purposes of this disclosure, a computer-readable medium (or computer-readable storage medium) stores computer data in a machine-readable form, which data may include computer program code (or computer-executable instructions) that can be executed by a computer. By way of example but not limitation, a computer-readable medium may include a computer-readable storage medium for tangible or fixed storage of data, or a communication medium for transient interpretation of a signal containing code. As used herein, a computer-readable storage medium refers to physical or tangible storage (as opposed to a signal), and includes (without limitation) volatile and non-volatile, removable and non-removable media for tangible storage of information (e.g., computer-readable instructions, data structures, program modules, or other data) implemented in any method or technology. Computer-readable storage media include (but are not limited to) RAM, ROM, EPROM, EEPROM, flash memory or other solid-state memory technology, CD-ROM, DVD or other optical storage, cassettes, magnetic tape, disk storage devices or other magnetic storage devices, or any other physical or material media that can be used to tangibly store the desired information or data or instructions and can be accessed by a computer or processor.

[0082] For purposes of this disclosure, a module is a software, hardware or firmware (or combination thereof) system, process or functionality or component thereof that performs or facilitates the processes, features and / or functions described herein (with or without human-computer interaction or enhancement). A module may include submodules. The software components of a module may be stored on a computer-readable medium for execution by a processor. A module may be integrated into one or more servers, or may be loaded and executed by one or more servers. One or more modules may be grouped into an engine or application.

[0083] Those skilled in the art will recognize that the methods and systems of the present disclosure may be implemented in many ways and are thus not limited by the foregoing exemplary embodiments and examples. In other words, the functional elements performed by single or multiple components in various combinations of hardware and software or firmware may be distributed among software applications at the client level or the server level or both. In this regard, any number of features of the different embodiments described herein may be combined into a single or multiple embodiments, and alternative embodiments having fewer or more features than all of the features described herein are possible.

[0084] Functionality may also be distributed in whole or in part among multiple components in ways now known or to be known in the future. Thus, countless software / hardware / firmware combinations are possible in implementing the functions, features, interfaces, and preferences described herein. Moreover, the scope of the present disclosure encompasses conventionally known ways to implement the described features and functions and interfaces, as well as those changes and modifications that may be made to the hardware or software or firmware components described herein that will now and later be understood by those skilled in the art.

[0085] In addition, the embodiments of the methods presented and described as flow charts in the present disclosure are provided by way of example to provide a more complete understanding of the technology. The disclosed methods are not limited to the operations and logic flows presented herein. Alternative embodiments are contemplated in which the order of the various operations is changed and sub-operations described as parts of larger operations are performed independently.

[0086] Although various embodiments have been described for the purposes of this disclosure, these embodiments should not be considered to limit the teachings of this disclosure to the embodiments described. Various changes and modifications may be made to the elements and operations described above to obtain results that are still within the scope of the systems and processes described in this disclosure.

Claims

1. A method for autonomous driving fleet management, the method comprising: establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a platoon; receiving a request from a first autonomous vehicle to deviate from the formation, the request comprising a digitally signed message from the first autonomous vehicle; designating the first autonomous vehicle as a second master autonomous vehicle; permanently recording the assignment in a blockchain data structure; instantiating a new platoon path using the first autonomous vehicle as a leader of the new platoon path, the new platoon path comprising an ordered subset of the plurality of autonomous vehicles; and Upon determining that the new queue path is stable, disconnecting the ordered subset of the plurality of autonomous vehicles from the new queue path, the disconnecting causing the second master autonomous vehicle to manage the ordered subset of the plurality of autonomous vehicles using a second blockchain data structure stored on the second master autonomous vehicle, the second blockchain data structure being accessed only by the ordered subset of the plurality of autonomous vehicles in the new queue path. 2 . The method of claim 1 , wherein establishing the network connection comprises establishing a vehicle ad hoc network (VANET) between the plurality of autonomous vehicles.

3. The method of claim 1, wherein the request is secured using the DICE-RIoT protocol. The method of claim 3 , further comprising authenticating the request using a public key of the first autonomous vehicle. The method of claim 4 , further comprising denying the request if the authentication is unsuccessful.

6. The method of claim 1 , wherein the permanently recording the assignment in the blockchain data structure comprises reaching a consensus among a plurality of lead autonomous vehicles to record the assignment in the blockchain data structure, each of the lead autonomous vehicles managing a respective fleet of autonomous vehicles.

7. The method of claim 1 , wherein permanently recording the assignment in the blockchain data structure comprises recording a block to the blockchain data structure, the block comprising an identifier identifying the recipient autonomous vehicle, a certificate and a public key, a timestamp, and service information related to the assignment.

8. A non-transitory computer readable storage medium for tangibly storing computer program instructions executable by a computer processor, the computer program instructions defining the following steps: establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a platoon; receiving a request from a first autonomous vehicle to deviate from the formation, the request comprising a digitally signed message from the first autonomous vehicle; designating the first autonomous vehicle as a second master autonomous vehicle; permanently recording the assignment in a blockchain data structure; instantiating a new platoon path using the first autonomous vehicle as a leader of the new platoon path, the new platoon path comprising an ordered subset of the plurality of autonomous vehicles; and Upon determining that the new queue path is stable, disconnecting the ordered subset of the plurality of autonomous vehicles from the new queue path, the disconnecting causing the second master autonomous vehicle to manage the ordered subset of the plurality of autonomous vehicles using a second blockchain data structure stored on the second master autonomous vehicle, the second blockchain data structure being accessed only by the ordered subset of the plurality of autonomous vehicles in the new queue path.

9. The non-transitory computer-readable storage medium of claim 8, said establishing the network connection comprises establishing a vehicle ad hoc network (VANET) between the plurality of autonomous vehicles.

10. The non-transitory computer-readable storage medium of claim 8, wherein the request is secured using a DICE-RIoT protocol.

11. The non-transitory computer-readable storage medium of claim 10, wherein the computer program instructions further define the step of authenticating the request using a public key of the first autonomous vehicle.

12. The non-transitory computer-readable storage medium of claim 11, the computer program instructions further defining the step of denying the request if the authentication is unsuccessful.

13. The non-transitory computer-readable storage medium of claim 8, wherein the permanently recording the assignment in the blockchain data structure comprises reaching a consensus among a plurality of lead autonomous vehicles to record the assignment in the blockchain data structure, each of the lead autonomous vehicles managing a respective fleet of autonomous vehicles.

14. The non-transitory computer-readable storage medium of claim 8, wherein permanently recording the assignment in the blockchain data structure comprises recording a block to the blockchain data structure, the block comprising an identifier identifying a recipient autonomous vehicle, a certificate and a public key, a timestamp, and service information related to the assignment.

15. A device for autonomous driving fleet management, the device comprising: processor; and A storage medium for tangibly storing program instructions thereon for execution by the processor, the stored program instructions comprising: program instructions executed by the processor for establishing a network connection between a plurality of autonomous vehicles, the plurality of autonomous vehicles operating as a platoon; program instructions executed by the processor for receiving a request from a first autonomous vehicle to deviate from the queue, the request comprising a digitally signed message from the first autonomous vehicle; program instructions executed by the processor for designating the first autonomous vehicle as a second master autonomous vehicle; program instructions executable by the processor for permanently recording the assignment in a blockchain data structure; program instructions executed by the processor for instantiating a new queue path using the first autonomous vehicle as a leader of the new queue path, the new queue path comprising an ordered subset of the plurality of autonomous vehicles; and Program instructions executed by the processor for disconnecting the ordered subset of the plurality of autonomous vehicles from the new queue path when it is determined that the new queue path is stable, the disconnection causing the second master autonomous vehicle to manage the ordered subset of the plurality of autonomous vehicles using a second blockchain data structure stored on the second master autonomous vehicle, the second blockchain data structure being accessed only by the ordered subset of the plurality of autonomous vehicles in the new queue path.

16. The apparatus of claim 15, wherein the program instructions for establishing the network connection include program instructions executed by the processor for establishing a vehicle ad hoc network (VANET) between the plurality of autonomous vehicles.

17. The apparatus of claim 15, wherein the request is secured using a DICE-RIoT protocol.

18. The apparatus of claim 17, wherein the program instructions for receiving the request to deviate from a queue further comprise program instructions executed by the processor for authenticating the request using a public key of the first autonomous vehicle.

19. The apparatus of claim 15, wherein the program instructions for permanently recording the assignment in the blockchain data structure include program instructions executed by the processor for reaching a consensus among a plurality of lead autonomous vehicles to record the assignment in the blockchain data structure, each of the lead autonomous vehicles managing a respective fleet of autonomous vehicles.

20. The apparatus of claim 15, wherein the program instructions for permanently recording the assignment in the blockchain data structure include program instructions executed by the processor to record a block to the blockchain data structure, the block including an identifier identifying a recipient autonomous vehicle, a certificate and a public key, a timestamp, and service information related to the assignment.

Images