System and method for carrying automated vehicle for autonomous vehicle operation

Abstract

The present disclosure provides a system and method of carrying an automated vehicle for autonomous vehicle operation. A system includes a vehicle system provided with an autonomous vehicle. The vehicle system includes one or more computing devices configured to define a virtual key shared with an infrastructure server using a server public key obtained from the infrastructure server, generating a lamp code pattern using the shared virtual key and code length to identify the autonomous vehicle, transmitting a vehicle public key and a flash characteristic of the lamp code pattern, controlling one or more selected lighting devices of the autonomous vehicle to perform a flash sequence indicative of the lamp code pattern, and in response to identifying the autonomous vehicle based on the flicker sequence, transitioning to a marshalling operating state to cause the autonomous vehicle to be controlled by the infrastructure server.

Description

[0001] Cross-references

[0002] This application claims the benefit of U.S. Provisional Application Serial No. 63 / 632,326, filed April 10, 2024, the disclosure of which is hereby incorporated by reference in its entirety. Technical Field

[0003] The present disclosure relates to systems and / or methods for shunting automated vehicles. Background Art

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

[0005] An automated vehicle (AV) is configured to drive autonomously without a human operator. Typically, a destination is provided to the AV, and using a defined algorithm, the AV autonomously drives to the destination using a travel route. In some applications, the AV can also be controlled by an external system that transmits driving commands to the AV. Summary of the Invention

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

[0007] In some aspects, the present disclosure relates to a system including a vehicle system provided with an autonomous vehicle. The vehicle system includes one or more computing devices configured to: define a virtual key shared with the infrastructure server using a server public key obtained from the infrastructure server, generate a light code pattern using the shared virtual key and a code length to identify the autonomous vehicle, transmit the vehicle public key and flashing characteristics of the light code pattern, control one or more selected lighting devices of the autonomous vehicle to execute a flashing sequence of the light code pattern, and, in response to identifying the autonomous vehicle based on the flashing sequence, transition to a platooning operation state so that the autonomous vehicle is controlled by the infrastructure server.

[0008] In some aspects, the present disclosure relates to a system for autonomously controlling an autonomous vehicle, the system comprising an infrastructure server associated with an installation. The infrastructure server, comprising one or more computing devices, is configured to: generate a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled, transmit the public key and a code length to the autonomous vehicle server, authenticate the identity of the autonomous vehicle using the vehicle public key, transmit a blink command initiating a blink sequence by the autonomous vehicle, and transition to autonomous control of the autonomous vehicle in response to the blink sequence by the autonomous vehicle indicating the predicted light code pattern.

[0009] In some aspects, the present disclosure relates to a method for autonomously controlling an autonomous vehicle. The method includes, by an infrastructure server: generating a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled, transmitting a public key and a code length to the autonomous vehicle server, authenticating an identity of the autonomous vehicle using the vehicle public key, transmitting a flash command to initiate a flash sequence by the autonomous vehicle, and transitioning to autonomous control of the autonomous vehicle in response to the flash sequence by the autonomous vehicle indicating the predicted light code pattern.

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

[0011] So that the disclosure can be well understood, various forms thereof will now be described by way of example with reference to the drawings in which:

[0012] Figure 1 A plurality of automated vehicles and an automated vehicle marshaling central server (AVM CS) for marshaling the automated vehicles according to the present disclosure are shown;

[0013] Figure 2 is a block diagram of an automated vehicle and AVM CS according to the present disclosure;

[0014] Figure 3A is a flowchart of a secure-unique onboarding process for AV marshaling by an AV and AVM CS according to the present disclosure;

[0015] Figure 3B is Figure 3A a continuation view of the flowchart of

[0016] Figure 3C is Figure 3B a continuation view of the flowchart of ; and

[0017] Figure 4 is an example of a light code pattern according to the present disclosure. DETAILED DESCRIPTION

[0018] The following description is merely exemplary in nature and is not intended to limit the present disclosure, application, or uses. The drawings are not necessarily to scale; some features can be exaggerated or minimized for purposes of illustration. The specific structural and functional details disclosed herein are not to be interpreted as limiting but merely as a representative basis for teaching one skilled in the art to variously employ the present application.

[0019] Prior to autonomously controlling the AV, the marshalling system can perform a vehicle identification process to recognize and onboard the corresponding AV. One possible way of performing this vehicle identification process is referred to as a flash challenge, during which the AV flashes one or more light devices according to a selected flashing sequence or in other words a flash pattern. A vision system can be used to detect the flashing sequence performed by the AV to identify the AV.

[0020] These flash challenges can not be unique enough to accurately identify the AV. That is, if the wrong AV is onboarded, the following issues can arise: interference with other AVs due to following an incorrect path generated by the marshalling system for another AV; for manufacturing use cases, this can result in a delay in production cycle time; for commercial yard marshalling use cases, this can result in incorrectly loading / unloading the wrong vehicle; for valet parking marshalling use cases, this can result in incorrectly performing incorrect vehicle control and parking at the wrong location, where the destination location is assigned for another AV; for charging marshalling use cases, this can result in incorrectly moving the wrong AV to a charging slot and occupying space allocated to another AV.

[0021] Other identification methods can also not provide accurate and safe identification. For example, license plate recognition techniques can employ infrastructure-based sensing that is installed too far away, resulting in potential misidentification. This method also requires the AV to be oriented in a certain orientation to detect the license plate. In another example, marker-based identification using, for example, UWB tags, BLE tags, reflective markers requires physical markers to be installed on the AV, which can impact quality and cannot guarantee uniqueness. Ground-based markers require the AV to be in a specific area, which imposes constraints on the marshalling system.

[0022] The present disclosure relates to a system or method for onboarding an AV using a secure and unique flash pattern. In one form, the AV is configured to define a shared virtual key (e.g., shared key) between the AV and a central server (CS) using a CS public key obtained from the CS. The AV then generates a unique light code pattern for identifying the AV using the shared virtual key and a code length specified by the CS. The AV transmits a message providing an AV public key and sometimes flash characteristics of the light code pattern to the CS and also controls one or more selected lighting devices to perform a flashing sequence indicative of the light code pattern. In response to identifying the AV based on the light code pattern, the AV transitions to a marshalling operation state to be controlled by the CS. The onboarding process of the present disclosure provides a secure and unique technique for identifying and onboarding the AV to the marshalling process.

[0023] Reference Figure 1 and Figure 2In a non-limiting example, autonomous vehicles 100A, 100B, 100C, 100D (collectively, “autonomous vehicles 100”) are provided in a facility 102 where vehicles 100 are undergoing various system processes, such as calibration, software configuration, and / or testing. In one form, autonomous vehicles 100 are driven to various stations 104A, 104B, 104C, 104D, and 104E (collectively, “stations 104”) under the control of an automated vehicle marshaling central server (AVM CS) 106. That is, autonomous vehicles 100, being automated vehicles (AVs), are driven in the facility based on driving commands from AVM CS 106, which utilizes a vision system 110 (which may be part of AVM CS 106). Figure 2 ) tracks the position and orientation of vehicle 100.

[0024] Hereinafter, the autonomous vehicle 100 is referred to as an automated vehicle (AV) 100. Although the AV 100 is shown as a four-wheeled passenger vehicle, the present disclosure may be applicable to other types of AVs 100, such as, but not limited to, automated guided vehicles, vehicles with one or more wheels, vehicles with tracks that move via wheels / rollers, and other vehicles that can be autonomously controlled.

[0025] In one form, the vision system 110 includes a plurality of vision sensors 112 (e.g., cameras) that capture images of various areas of the facility 102, where the images are then processed by a vision module 113 to identify, for example, the AV 100 and sometimes specific areas of the AV 100, such as one or more light devices 114.

[0026] In addition to the vision system 110 , the AVM CS 106 includes a communication system 120 and an AVM controller 122 having an AV onboard module 124 of the present disclosure.

[0027] In one form, the communication system 120 is configured to support wireless and / or wired communications with, for example, the vision sensor 112, the AV 100, and other devices and / or controllers in the facility 102. In one form, the communication system 120 is configured to communicate using any suitable wireless communication protocol (e.g., Wireless communications may be established using a variety of wireless communication protocols (e.g., Wi-Fi, Wi-Fi, NFC, and UWB). The communication system 120 may include various hardware (e.g., routers, antennas, wires, input-output interfaces, and / or processors) and computer software for implementing various wireless communication protocols.

[0028] The AVM controller 122 is configured to control the AV 100 through the facility 102 using various driving commands. Prior to marshalling the AV 100 to various stations 104, each AV 100 is boarded by an AV boarding module 124. As detailed herein, the AV boarding module 124 is configured to perform a secure-unique handshake protocol in which the AV 100 is requested to identify itself using a unique flash pattern performed by one or more lighting devices on the AV 100. The vision system 110 captures the flash pattern and the AV boarding module 124 decodes the pattern to determine whether the AV 100 is the correct vehicle to communicate with the AVM controller 122.

[0029] In one form, the AV 100 is configured to include a communication system 130 having a telematics control unit (TCU) 132, lighting devices 114, and an autonomous driving controller (ADC) 134. While the lighting devices 114 are shown as headlamps, the lighting devices 114 can also include other devices such as, but not limited to: rear brake lights; front / rear fog lights, side mirror lights, and parking lights.

[0030] The communication system 130 is configured to support wired and wireless communication with external devices or systems using various suitable technologies and / or wireless protocols (e.g., Bluetooth® type protocols, cellular protocols, wireless fidelity (WiFi) type protocols, near field communication (NFC) protocols, ultra-wideband (UWB) protocols, etc.). In one form, the TCU 132 is employed to support vehicle-to- everything (V2X) communication.

[0031] The ADC 134 is configured to autonomously drive the AV 100 by controlling a drive system (not shown) of the AV 100. The ADC 134 controls the AV 100 to a desired destination using, for example, a driving control algorithm stored and executed by the ADC 134 and / or using driving commands from the AVM CS 106. In one form, the ADC 134 includes an AV tuple (AVM) module 136 configured to board the AV 100 with the AVM CS 106 so that the AVM CS 106 can control the AV 100 through the facility 102.

[0032] In one form, the AVM controller 122 is configured to communicate with the AV 100 using an infrastructure marshalling message (IMM) that is wirelessly transmitted using the communication system 120. The ADC 134 of the AV 100 is configured to communicate with the AVM CS 105 using a vehicle marshalling message (VMM) that is wirelessly transmitted using the communication system 130.

[0033] ​Prior to being controlled by the AVM CS 106 during the marshaling process, the new AV 100 undergoes a boarding process during which the AVM CS 106 recognizes and identifies the new AV 100A to confirm that the AVM CS 106 is communicating with the correct new AV 100A. For the boarding process, the AV boarding module 124 and the AVM module 136 communicate using a secure messaging technique that not only mitigates interference by third parties, but also helps generate a unique strobe sequence that the new AV 100A employs during a strobe challenge to visually identify the new AV 100A in the facility 102. Specifically, the AVM CS 106 communicates with the new AV 100A using IMM. However, for various reasons, including but not limited to interference by third parties and / or the visual system 110 can not be able to identify the AV 100 in the facility 102, the IMM can not be sufficient to recognize and identify the AV 100A within the facility 102. Accordingly, the AV boarding module 124 and the AVM module 136 define a unique strobe challenge for the AV 100A that is visually captured by the visual system 110 and processed by the AV boarding module 124 to confirm that the correct AV 100 is being boarded.

[0034] In one form, the AV boarding module 124 of the AVM CS 106 and the AVM module 136 of the AV 100 employ a private-public key encryption technique as the secure messaging technique. The AVM module 136 is configured to define a shared virtual key (e.g., a shared secret) based on a central server (CS) public key provided by the AV boarding module 124. The AVM module 136 also uses the shared virtual key and a code length variable from the AV boarding module 124 to generate a light code pattern for the strobe challenge.

[0035] In some instances, the AV boarding module 124 provides strobe characteristics for the strobe challenge, including a strobe light rate code bit and a synchronization bit. The strobe characteristics can be determined based on the imaging capabilities of the visual system 110 such that the on-off cycle of the lighting device 114 is not too fast for the visual system 100 to capture the strobe sequence. In addition to or in lieu of the strobe characteristics from the AV boarding module 124, the AVM module 136 provides strobe characteristics for the strobe challenge to the AV boarding module 124, but different from the strobe characteristics that can be captured by the visual system 110.

[0036] The AVM module 136 transmits the AV public key to the AV boarding module 124, which determines the shared virtual key to authenticate the AV 100 and then decodes a predicted light code pattern to use for the strobe challenge using the shared virtual key, the code length, and / or the strobe characteristics.

[0037] The AVM module 136 executes a flashing sequence or flash pattern using one or more selected lighting devices of the AV 100, and the AV onboarding module 124 determines whether the flashing sequence matches a light code pattern based on information from the vision system 110. If the flashing sequence does not match, the AV 100 is unknown or unidentified. If the flashing sequence does match, the AV 100 is recognized and identified in the facility 102 as an AV to be marshaled.

[0038] Using public-private key encryption technology as a variable to define a unique light code pattern, the AV onboarding module 124 is able to distinguish a selected AV 100 from other AVs 100 that can be captured by the vision system 110. Additionally, using public-private key encryption technology during the onboarding process provides a degree of security to prevent third parties from attempting to interfere with the marshaling control of the AV 100.

[0039] Details regarding the onboarding process of the present disclosure are described below, including example messages exchanged between the AVM CS 106 and the AV 100. In the following description, the operation of the various steps is described in terms of the AVM CS 106 and the AV 100 attempting to be onboarded (e.g., AV 100A).

[0040] The IMM and VMM exchanged between the AVM CS 106 and the AV 100 include different fields for communicating specific information to the recipient. In a non-limiting example, Table 1 provides a list of specific fields provided in the IMM and / or VMM.

[0041] Table 1: Message Fields

[0042] Field Abbreviation Identity Management IdMgt State Flow Identification Command StateFlowIdCmd IMM Data Management IMMDataMgt Vehicle Identification Command VehIdCmd Drive Command DrvCmd State Flow Identification Command Response StateFlowIdCmdResp VMM Data Management VMMDataMgt Vehicle Identification Command Response VehIdCmdResp Vehicle State VehState

[0043] Identity management provides details of one or more identifiers of the AV 100. In a non-limiting example, identity management includes four data elements, such as a vehicle ID, a session ID, a task ID, and a facility ID. Since several sessions can in principle be related to the same vehicle over time, the vehicle ID data element uniquely identifies the AV 100. The format of the vehicle ID can be similar to a vehicle identification number (VIN). In some forms, the OEM can in principle decide to use a real VIN or a pseudo VIN, as long as the identifier is uniquely defined and provided to the AVM CS 106 (e.g., the AVM CS 106 receives the VIN from the OEM cloud-based server).

[0044] The session ID data element is a unique identifier for a given AV 100's series of interactions between a destination origin and a destination destination. It identifies a set of multiple tasks or task IDs (e.g., a series of driving maneuvers between a destination origin and a destination destination). It is pre-negotiated and agreed upon by both the AVM CS 106 and the AV 100 participants.

[0045] The task ID data element identifies and describes a task negotiated and agreed upon by the AVM CS 106 and the AV 100 (e.g., driving from a parking location (origin) to a destination for a specific purpose such as charging, washing, or parking). The task is associated with a unique identifier used as the task ID data element, where the unique identifier is referred to as the AVM CS 106 and the AV 100.

[0046] The facility ID data element provides an option for identifying infrastructure (e.g., a parking lot or logistics yard, a specific factory).

[0047] The status flow ID command or status flow ID command response (collectively referred to as "status flow ID") is employed by both the AVM CS 106 and the AV 100 to identify which operational state the AV 100 is in with respect to the AV marshaling process. In a non-limiting example, Table 2 provides a list of states for the status flow ID. The status flow ID command / response can also be referred to as a feature flow command / response.

[0048] Table 2: Status flow ID command / response

[0049]

[0050]

[0051] The IMM data management includes control information for the two-way wireless communication between the AVM CS 106 and the AV 100 of the AVM CS 106. In a non-limiting example, Table 3 provides the types of information that can be provided with the IMM data management.

[0052] Table 3: IMM data management

[0053]

[0054] The drive command contains the motion and drive control operations for the AV 100, and the drive command action is the primary drive state request for automated vehicle operation. The AVM CS 106 can employ system states as defined in ISO-23374 to operate the AV 100. In a non-limiting example, Table 4 provides some drive commands employed by the AVM CS 106.

[0055] Table 4: Drive command

[0056]

[0057]

[0058]

[0059] As with IMM data management, VMM data management includes control information for bidirectional wireless communication between the AVM CS 106 and the AV 100. In a non-limiting example, Table 5 provides example control information for VMM data management.

[0060] Table 5: VMM Data Management

[0061]

[0062] The flash sequence carries the signal that transmits the code to the AV 100 to generate a flash pattern. The AVM CS 106 uses the flash pattern transmitted by the AV 100 to identify the respective AV 100 at a specified location (e.g., station 104A). A vehicle identification command from the AVM CS 106 can be used to initiate a pick-up identification process. The command provides a code length, which is a value indicating how many bits from the CS public key (e.g., vIDCSPublicKey) should be used to generate a flash pattern (e.g., a light code pattern). The code length is dynamic, with 2 code length possible combinations.

[0063] The vehicle identification command also indicates a flash command, which includes the current identification request status of a flash challenge with the AV 100 from the perspective of the AVM CS 106 system. In a non-limiting example, Table 6 provides example states of the flash command.

[0064] Table 6: Flash Command States

[0065]

[0066] The vehicle identification command response provided by the AV 100 provides a response to the flash command indicating the current status of the AV 100 for the vehicle identification process, and can be referred to as a flash command response (BLR). In one form, the vehicle identification command response includes a flash command response, a flash light rate code bit, and a flash light rate. In a non-limiting example, Table 7 provides a list of potential flash command responses. The flash light rate code bit (BLR-CB) indicates the data rate at which the vehicle blinks the respective vehicle light code bit, and the flash light rate sync bit (BLR-SB) indicates the data rate at which the vehicle turns off the vehicle turn signal.

[0067] Table 7: AV Flash Command Response

[0068]

[0069]

[0070] The vehicle operation mode indicates the current operation mode or state of the AV 100. In a non-limiting example, Table 8 provides some example vehicle operation modes for the AV 100.

[0071] Table 8: AV Operation (Oper) Modes

[0072]

[0073] The flash characteristics of the light code pattern provide information about the on / off state of one or more of the lighting devices 114 of the AV 100. For example, the code sync flash bit indicates can be provided as: “unknown” when the AV 100 does not know the lighting device 114 state; “sync bit” indicates that the AV 100 is not flashing the code bit sequence (e.g., the lighting device 114 is in the “off” duration); and “code bit” indicates that the AV 100 is flashing the code bit sequence (e.g., the lighting device 114 is in the “on” duration).

[0074] Referring to Figure 3A , Figure 3B and Figure 3C , an example onboarding or identification process performed by the AVM CS 106 and the AV 100 of the present disclosure is described.

[0075] In the case where the AV 100 and the AVM CS 106 communicate using a wireless communication link, the AVM CS 106 transmits a message 201 to the AV 100 indicating that the AV CS 106 is in an activation state / process to onboard the AV 100 and is active driving command AVM CS 106 (e.g., StateFlowldCmd→activation and DrvCmdAction=active).

[0076] Additionally, the AV 100 transmits a message 202 to the AVM CS 106 to enter the onboarding process or activation process. The system operator at the area where the AV 100 is entering confirms the onboarding process of the AV 100. In a non-limiting example, referring to Figure 1, the operator can use the computing device 140 to transmit a message to the AVM CS 106 confirming that the AV 100A is present at the station 104A. The message 202 includes information identifying the AV 100 (e.g., IdMgt = Vehicle ID), identifying the operating state of the AV 100 in the marshaling process as pre-boarding (e.g., StateFlowIdCmdResp = Pre-Boarding), and indicating that the operating mode of the AV 100 is not yet defined but is in an active state (e.g., VehState -> Ope1Mode = Active).

[0077] In some implementations, the system operator confirms to the AVM CS 106 that the AV 100 is available for boarding. In other implementations, confirmation from the system operator can not be required. In either scenario, the AVM CS 106 and the AV 100 enter an initialization process in which the AVM CS 106 transmits a message 204 to indicate a vehicle identification command using a flash sequence or, in other words, a flash challenge. The AVM CS 106 provides a flash command to generate a new code and a CS public key that the AV 100 employs to authenticate the sender. In a non-limiting example, the message 204: includes information identifying the AV 100 (e.g., IdMgt = Vehicle ID); defines the operating state of the AV 100 in the marshaling process as boarding, which can also be referred to as an identification state (e.g., StateFlowIdCmd = Boarding); provides the CS public key (e.g., IMMDataMgt -> vIdCSPublicKey); defines a flash command (BC) to generate a new code (e.g., VehIdCmd -> Flash = {BC = GNC}; and indicates that the AVM CS 106 is preparing for secure vehicle identification and is not in a system management state for the AV 100 (e.g., DrvCmd -> DrvCmdAction = Initialization).

[0078] AV 100 is configured to transmit message 205 indicating whether AV 100 is going to perform the flash challenge requested by AVM CS 106 in message 204. In some aspects, AV 100 updates the operation state of the marshaling process to “onboard” (e.g., StateFlowIdCmdResp→onboard) and begins decoding or validating the CS public key. AV 100 can transmit message 206 including a vehicle identification command response indicating that code identification is in progress to decode or validate the CV public key with the AV public key (e.g., VehIdCmdResp={vIdAVPublicKey, BCR=IdIP}). Message 206 continues to be transmitted until decoding is successful or not completed, at which time the vehicle identification command response is updated to indicate identification complete or identification failed, respectively (e.g., VehIdCmdResp={vIdAVPublicKey, BCR=IdC} or VehIdCmdResp={VIdAVPublicKey, BCR=IdF}).

[0079] If code identification is not completed, AV CS 106 can retransmit message 204, or the system coordinator can perform diagnostic checks.

[0080] If code identification is completed, AV CS 106 determines the predicted light code pattern and provides AV 100 with additional information defining the light code pattern. Specifically, AV CS 106 is configured to provide the code length, and in some instances, the flash characteristics of the light code pattern, such as the requested code bit interval rate and the sync bit interval rate, as part of the flash command (e.g., VehIdCmd→Flash={code length, BCR=GNC, CodeBitIntrReq, SyncBitIntlReq}). In some implementations, AV CS 106 determines the predicted light code pattern in a similar manner as AV 100, as detailed below.

[0081] With the additional information from AV CS 106 (e.g., code length and flash characteristics), AV 100 defines the light code pattern for performing the flash challenge. AV 100 also provides message 207 including a vehicle identification command response indicating that identification of the light code pattern is in progress, and provides a response to the flash characteristics request by identifying the code bit interval rate and the sync bit interval rate. For example, vehicle identification command response VehIdCmdResp={BCR=CPIdIP, CodeBitIntrResp, SyncBitIntResp}. In some implementations, message 207 can include the AV public key (e.g., the vehicle identification command response can include “vIdAVPublicKey”).

[0082] Once the light code pattern is determined, message 207 provides an updated status via the flash command response when the vehicle code pattern identification is complete (e.g., BCR = CPIdC). Alternatively, if the light code pattern cannot be determined, message 207 provides an updated status of the vehicle code pattern identification as unsuccessful (e.g., BCR = CPIdUS). In non-limiting examples, the determined light code pattern can be unsuccessful if the AV 100 does not receive message 206 after a selected period of time, or the AV 100 is unable to generate a shared virtual key using the CS public key, as detailed below.

[0083] Using information from messages 204 and 206, the AV 100 is configured to determine a shared virtual key using the CS public key, and determine a light code pattern using the shared virtual key and the code length. More specifically, the AVM CS 106 and the AV 100 employ public key cryptography to securely transmit messages. In one form, the AVM CS 106 and the AV 100 employ a Diffie-Hellman key exchange technique in which the AVM CS 106 and the AV 100 each generate a public / private key pair and distribute the public key of the public / private key pair. After obtaining a true copy of the other's public key, the AVM CS 106 and the AV 100 compute a shared virtual key. For this technique, the AVM CS 106 and the AV 100 employ previously agreed upon values of a prime number (P) and a generator (G). While a particular public key cryptography technique is provided, other suitable encryption techniques can be used.

[0084] In non-limiting examples, the AV 100 is configured to generate an AV private key (e.g., VehicleIDPrivateKey) that is less than the prime number (P) (e.g., an unsigned 64-bit or 32-bit value). Using the received CS public key and the AV private key, the AV 100 is configured to compute a shared virtual key (e.g., SharedvIDSecrKey) using Equation 1A.

[0085] Equation 1A..... SharedvIDSecrKey = vIDCSPublicKey VehicleIDPrivateKey mod (P)

[0086] AV 100 is also configured to determine the light code pattern using the shared virtual key and the code length. In a non-limiting example, Equation 2 is used to calculate the light code pattern (e.g., IndicatorLightCodePattem), where the indicator constant is predefined and agreed upon. In a non-limiting example, the indicator light code pattern can define a code bit value of “0” to indicate the left turn signal is on and the right turn signal is off, and define a code bit value of “1” to indicate the left turn signal is off and the right turn signal is on.

[0087] Equation 2... IndicatorLightCodePattem = truncate(SharedvIDSecrKey XOR

[0088] IndicatorConstant, CodeLength)

[0089] In a non-limiting example, AV CS 106 and AV 100 agree to make P = 2 32 -17 = 4294967278) and GENERATOR (G = 7). AV 100 generates VehicleIDPrivateKey as VehicleIDPrivateKey is unsigned 32-bit, VehicleIDPrivateKey < P, such as 1185390551 = 43425267 < P. AV CS 106 and AV 100 also agree on an indicator constant, which is set to a default configuration of 0x14FAFAD5 as an example.

[0090] Continuing the example, SharedvIDSecrKey = 3560272037, and AV CS 106 provides the following information: vIdCSPublicKey = 3323458733; codeLength = 8; CodeBitlntrReq = 20, which represents 200 msec, and SyncBitlntrReq = 25, which represents 250 msec. AV 00 and AV CS 106 determine the light code pattern and the predicted light code pattern, respectively, using Equation 2 at the same or different times. For example, for the values provided herein, IndicatorLightCodePattem = truncate(3560272037 XOR 0x14FAFAD5, 8) = 01110000, which can be interpreted in the light code pattern table 400 of FIG. 4. The values provided herein are for explanatory purposes only, and other values can also be employed. Figure 4

[0091] ​The AV 100 is also configured to compute an AV public key (e.g., VehicleIDPublicKey). In a non-limiting example, the AV public key is determined using Equation 3.

[0092] Equation 3... vIDAVPublicKey = G VehicleIDPrivateKey mod(P)

[0093] If the AV 100 is able to begin generating the flash pattern, the AV 100 and the AVM CS 106 enter a flash cycle process to perform the flash challenge. Specifically, the AVM CS 106 prepares to detect the blink sequence of the AV 100 and transmits a message 208 indicating such preparation as part of the flash command (e.g., VehIdCmd -> Flash = {codelength, BC = PFF, CodeBitlntrReq, SyncBitlntrReq}).

[0094] In response to the message 208, the AV 100 transmits a message 210 indicating that the AV 100 is ready to perform the flash challenge (e.g., VehIdCmdResp -> {BCR = VR, CodeBitlntrResp, SyncBitlntrResp}) and can also provide the AV public key (e.g., VMMDataMgt -> vIdAVPublicKey).

[0095] Upon receiving the message 210, the AVM CS 106 is configured to verify the identity of the AV 100 using the AV public key and, if ready, instruct the AV 100 to perform the blink sequence via a message 212. In one form, to verify the AV 100, the AVM CS 106 uses the AV public key and, more specifically, computes a shared virtual secret key (e.g., SharedvIDSecrKey) using Equation 4 below where "AVMCSIDPrivateKey" is the CS private key.

[0096] Equation 4... SharedvIDSecrKey = vIDAVPublicKey AVMCSIDPrivateKey mod(P)

[0097] The message 212 provides the CS public key (e.g., IMMDataMgt -> vIdCSPublicKey) and indicates that the visual system 110 is ready to capture the blink sequence by the AV 100 (e.g., VehIdCmd -> Flash = {codelength, BC = FLASH, CodeBitlntrReq, SyncBitlntrReq}).

[0098] In response to receiving message 212, AV 100 transmits message 214 indicating that AV 100 is performing the flash challenge or in other words is flashing the code (e.g., VehIdCmdResp = {BCR = LFIP, CodeBitlntrResp, SyncBitlntrResp}).

[0099] As detailed above, the light code pattern is generated from the "SharedvIDSecrKey" decoded from the public keys (vIDCSPublicKey, vIDAVPublicKey) exchanged through the IMM and VMM messages. In a non-limiting example, AV 100 flashes a message indicating the AV public key using the headlamps and side mirror projection lights; flashes the decoded complete unique flash code pattern on each of the external lights; and flashes the unique flash code pattern using one or more combinations of selected light devices 114 to prevent man-in-the-middle attacks and multiple AVs flashing at the same time. Example light device combinations include, but are not limited to: headlamps and rear brake lights; front fog lights and rear brake lights; front fog lights and rear fog lights; left side mirror lights and right side mirror lights; and front fog lights and rear park lights.

[0100] Once complete, AV 100 transmits message 216A indicating that the flashing sequence was successfully completed using the identified lights (e.g., VehIdCmdResp = {BLR = LFC, CodeBitlntrResp, SyncBitlntrResp}); or transmits message 216B indicating that the flashing sequence was not completed or failed due to a vehicle error (e.g., VehIdCmdResp = {BCR = LFIP, CodeBitlntrResp, SyncBitlntrResp}). In a non-limiting example, a vehicle error can occur when the light module controlling the identified light device 114 has an error or is resolving another issue, in which case the light module can reject the flashing request from AVM module 136.

[0101] AVM CS 106 analyzes the images from vision system 110 to determine if the correct flash code was provided. Specifically, using Equation 2 above, AVM CS 106 is able to obtain the light code pattern that will be flashed by AV 100 and compare the decoded light code pattern to the obtained images.

[0102] If the correct flashing sequence pattern is executed, the AV 100 is successfully recognized and identified, and the AVM CS 106 transmits a message 218A indicating success (e.g., VehIdCmd -> Flash = {codelength, BC = Succ}). Additionally, the AVM CS 106 indicates that the AV 100 is ready for platooning (e.g., DrvCmd -> DrvCmdAction = Ready).

[0103] In response to the message 218A, the AV 100 is configured to transmit a message 220 indicating that the identification was successful and that the AV 100 is switching its state flow identification command response and operational mode in the subsequent VMM (e.g., VehIdCmdResp = {BCR = Vehicle Authorized, CLR = CB, BLR = SB}; and VehState -> OperMode = Ready).

[0104] Alternatively, if the flashing sequence pattern is incorrect, the AV 100 cannot be identified, and thus, the AVM CS 106 transmits a message 218B indicating that a new code is generated (e.g., VehIdCmd -> Flash = {codelength, BC = GNC}).

[0105] In the case of successful identification, the AVM CS 106 and the AV 100 enter an output next state transition, in which the AVM CS 106 provides the next operational state as autonomous platooning to control the AV 100 to perform certain actions. In a non-limiting example, the AVM CS 106 transmits a message 222 indicating a platooning operational state (e.g., StateFlowIdCmd -> Platooning), and causes the AV 100 to standby and wait for further driving commands (e.g., the AVM CS 106 indicates to the AV 100 to standby - wait) until further driving commands (e.g., DrvCmd -> DrvCmdAction = Standby - Wait).

[0106] In response to the message 222, the AV 100 is configured to transmit a message 224 to confirm the new operational state (e.g., StateFlowIdCmdResp -> Platooning) and that it is in an automated mode and waiting for further instructions (e.g., VehState -> OperMode = Ready or Ready).

[0107] If AV 100 is not successfully identified after the first flash challenge or after one or more subsequent flash challenges, AV 100 and AVM CS 106 enter an output error state transition. Here, AVM CS 106 returns to pre-cab and indicates that there is an error (critical or non-critical) in AV 100 that needs to be checked by an operator. For example, AVM CS 106 transmits message 226 with an operational state of pre-cab (e.g., StateFlowldCmd -> Pre-Cab) and a drive command indicating an error (e.g., DrvCmd -> DrvCmdAction = Temp Error / Suspended). Similarly, AV 100 transmits message 228 indicating pre-cab (StateFlowldCmdResp -> Pre-Cab) and an error (e.g., VehState -> OperMode = Temp Error / Suspended) or active.

[0108] The pre-cabbing process of the present disclosure provides a safe and unique technique for pre-cabbing AV 100 to inhibit inadvertent control of an error AV. In addition, the pre-cabbing process causes AV 100 to use different combinations of light devices to flash a unique flash code pattern to prevent third party interference and multiple AVs from flashing at the same time. The AV can also be a flasher with any frequency supported by its hardware and provide the flash frequency depending on the infrastructure.

[0109] The particular messaging format is merely one way of defining the communication between AVM CS 106 and AV 100, and other suitable formats can be employed. For example, the public keys exchanged between AVM CS 106 and AV 100 can be provided as part of the flash command or vehicle identification command response.

[0110] While a particular naming convention is used, other suitable naming conventions can be employed for the commands, handles, or other fields.

[0111] Unless specifically stated otherwise as apparent from the foregoing disclosure, all measurements, values, ratings, positions, magnitudes, sizes, and other specifications that are not otherwise qualitatively described herein are deemed to be approximations. Unless otherwise indicated, the contents of the specification are intended to be illustrative only and are not limiting of the scope of the disclosure. As such, although the disclosure has been described in connection with specific embodiments thereof, it will be understood that it is capable of further modifications and that this application is intended to cover any variations which fall within the scope of the following claims, functions, and / or arrangements.

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

[0113] The term "memory" is a subset of the term "computer-readable medium." The term computer-readable medium, as used herein, does not encompass transitory propagating signals or electromagnetic waves through a medium, such as on a carrier or the Internet. Thus, the term computer-readable medium can be considered tangible and non-transitory. Non-limiting examples of non-transitory computer-readable media are nonvolatile memory circuits (such as flash memory circuits, erasable programmable read only memory (EPROM) circuits, or electrically erasable programmable read only memory (EEPROM) circuits), volatile memory circuits (such as static random access memory (SRAM) circuits or dynamic random access memory (DRAM) circuits), magnetic storage media (such as analog magnetic tapes or digital magnetic tapes or hard disk drives), and optical storage media (such as optical discs like CDs, DVDs, or Blu-ray discs).

[0114] The apparatus and methods described in this application can be partially or fully implemented by special purpose computers configured to perform one or more specific functions by virtue of having software, firmware, hardware, or a combination thereof installed structure them. The various elements of the functional blocks, flow diagrams, and other elements described above can be used as software specifications to create computer programs that can be interpreted by a technician or programmer to create the computer programs.

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

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

[0117] According to the invention, there is provided a system having: a vehicle system provided with an autonomous vehicle and comprising one or more computing devices configured to: define a virtual key shared with an infrastructure server using a server public key obtained from the infrastructure server; generate a light code pattern using the shared virtual key and a code length to identify the autonomous vehicle; transmit a vehicle public key and a flash characteristic of the light code pattern; control one or more selected lighting devices of the autonomous vehicle to perform a flashing sequence indicative of the light code pattern; and in response to identifying the autonomous vehicle based on the flashing sequence, transition to a marshalling operational state to have the autonomous vehicle controlled by the infrastructure server.

[0118] According to an embodiment, the light code pattern is a binary digit string, wherein zeros and ones are associated with on or off states of at least one of the selected lighting devices.

[0119] According to an embodiment, the flash characteristic comprises a flash rate bit characteristic indicative of a switching rate for the flashing sequence.

[0120] According to an embodiment, the invention further features an infrastructure server associated with a facility and comprising one or more computing devices configured to: transmit a server public key and a code length to a vehicle system; authenticate an identity of the vehicle system using the vehicle public key; in response to the identity of the vehicle system being authenticated, generate a predicted light code pattern of the autonomous vehicle using the vehicle public key; and in response to a flashing sequence by one or more selected lighting devices being indicative of the predicted light code pattern, initiate autonomous marshalling control of the autonomous vehicle.

[0121] According to an embodiment, the infrastructure server is configured to use an image of the flashing sequence by the autonomous vehicle to determine whether the flashing sequence by the one or more selected lighting devices is indicative of the predicted light code pattern.

[0122] According to an embodiment, the infrastructure server is configured to request the vehicle system to generate a new light code pattern in response to the flashing sequence by the one or more selected lighting devices not being indicative of the predicted light code pattern.

[0123] According to an embodiment, the invention further features a vision system comprising a plurality of imaging devices arranged in the facility to capture the image of the flashing sequence.

[0124] According to an embodiment, the infrastructure server is configured to use the vehicle public key to determine the shared virtual key to verify the identity of the vehicle system.

[0125] According to the invention, there is provided a system for autonomously controlling an autonomous vehicle, having: an infrastructure server associated with a facility and comprising one or more computing devices configured to: generate a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled; transmit a public key and a code length to the autonomous vehicle server; authenticate an identity of the autonomous vehicle using the vehicle public key; transmit a flash command to initiate a flashing sequence by the autonomous vehicle; and transition to autonomous control of the autonomous vehicle in response to the flashing sequence by the autonomous vehicle indicating the predicted light code pattern.

[0126] According to an embodiment, the one or more computing devices of the infrastructure server transmit a flash rate bit characteristic to the autonomous vehicle, the flash rate bit characteristic for the flashing sequence, the flash rate bit characteristic indicating an on-off rate for the flashing sequence.

[0127] According to an embodiment, the one or more computing devices of the infrastructure server are configured to use an image of the flashing sequence by the autonomous vehicle to determine whether the flashing sequence by the autonomous vehicle indicates the predicted light code pattern.

[0128] According to an embodiment, the infrastructure server is configured to request the autonomous vehicle to generate a new light code pattern in response to the flashing sequence by the autonomous vehicle not indicating the predicted light code pattern.

[0129] According to an embodiment, the invention further features a vision system comprising a plurality of imaging devices arranged in the facility to capture the image of the flashing sequence.

[0130] According to an embodiment, the invention further features a vehicle system provided with the autonomous vehicle and comprising one or more computing devices configured to: generate a light code pattern using a shared virtual key and a code length to identify the autonomous vehicle; transmit a vehicle public key to the infrastructure server; control one or more selected lighting devices of the autonomous vehicle to perform a flashing sequence indicative of the light code pattern in response to the flash command; and transition to a marshalling operating state to have the autonomous vehicle controlled by the infrastructure server in response to the infrastructure server transitioning to autonomous control of the autonomous vehicle.

[0131] According to an embodiment, the light code pattern is a binary digit string, wherein zeros and ones are associated with an on or off state of at least one of the selected lighting devices.

[0132] According to an embodiment, the one or more computing devices of the vehicle system and the one or more computing devices of the infrastructure server employ the same prime number and generator value to authenticate each other’s identity.

[0133] According to the present invention, a method for autonomously controlling an autonomous vehicle includes generating, by an infrastructure server, a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled; transmitting, by the infrastructure server, a server public key and a code length to the autonomous vehicle; authenticating, by the infrastructure server, an identity of the autonomous vehicle using the vehicle public key; transmitting, by the infrastructure server, a flash command initiating a flash sequence by the autonomous vehicle; and transitioning, by the infrastructure server, to autonomous control of the autonomous vehicle in response to the flash sequence by the autonomous vehicle indicating the predicted light code pattern.

[0134] In one aspect of the present invention, the method includes generating, by a vehicle system, a light code pattern using the shared virtual key and the code length to identify the autonomous vehicle; transmitting, by the vehicle system, a vehicle public key to the infrastructure server; controlling, by the vehicle system, one or more selected lighting devices of the autonomous vehicle to perform the flash sequence indicative of the light code pattern in response to the flash command; and transitioning, by the vehicle system, to a marshaling operational state to enable the autonomous vehicle to be controlled by the infrastructure server in response to the infrastructure server transitioning to autonomous control of the autonomous vehicle.

[0135] In one aspect of the present invention, the predicted light code pattern and the light code pattern are binary digit strings in which zeros and ones are associated with on or off states of at least one of the selected lighting devices.

[0136] In one aspect of the present invention, the method includes transmitting, by the infrastructure server, a flash rate bit characteristic to the autonomous vehicle, the flash rate bit characteristic being for the flash sequence and indicative of an on-off rate for the flash sequence; capturing, by a vision system, an image of the flash sequence by the autonomous vehicle, wherein the flash rate bit characteristic is based on operational characteristics of the vision system; and determining, by the infrastructure server, whether the flash sequence by the autonomous vehicle indicates the predicted light code pattern using the image of the flash sequence.

Claims

1. A system comprising: A vehicle system provided with an autonomous vehicle and comprising one or more computing devices configured to: defining a virtual key shared with the infrastructure server using a server public key obtained from the infrastructure server; generating a light code pattern using the shared virtual key and a code length to identify the autonomous vehicle; transmitting a vehicle public key and flash characteristics of the light code pattern; controlling one or more selected lighting devices of the autonomous vehicle to perform a flashing sequence indicative of the light code pattern; and In response to identifying the autonomous vehicle based on the blink sequence, a transition is made to a platoon operating state such that the autonomous vehicle is controlled by the infrastructure server. 2 . The system of claim 1 , wherein the light code pattern is a binary digit string in which zeros and ones are associated with an on or off state of at least one of the selected lighting devices.

3. The system of claim 1 wherein the flash characteristics include a flash lamp rate bit characteristic indicating an on / off rate for the blinking sequence.

4. The system of claim 1 , further comprising: An infrastructure server associated with the facility and comprising one or more computing devices configured to: transmitting the server public key and the code length to the vehicle system; authenticating the identity of the vehicle system using the vehicle public key; generating a predicted light code pattern for the autonomous vehicle using the vehicle public key in response to the identity of the vehicle system being authenticated; and In response to the blinking sequence by the one or more selected lighting devices indicating the predicted light code pattern, autonomous formation control of the autonomous vehicles is initiated.

5. The system of claim 4, wherein the infrastructure server is configured to use an image of the blinking sequence performed by the autonomous vehicle to determine whether the blinking sequence performed by the one or more selected lighting fixtures is indicative of the predicted light code pattern. 6 . The system of claim 5 , wherein the infrastructure server is configured to request the vehicle system to generate a new light code pattern in response to the blinking sequence by the one or more selected lighting devices not indicating the predicted light code pattern.

7. The system of claim 5, further comprising a vision system comprising a plurality of imaging devices arranged in the facility to capture the images of the flashing sequence. 8 . The system of claim 4 , wherein the infrastructure server is configured to use the vehicle public key to determine the shared virtual key to verify the identity of the vehicle system.

9. A system for autonomously controlling an autonomous vehicle, comprising: An infrastructure server associated with the facility and comprising one or more computing devices configured to: generating a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled; transmitting a server public key and a code length to the autonomous vehicle; authenticating the identity of the autonomous vehicle using the vehicle public key; transmitting a blink command to initiate a blink sequence by the autonomous vehicle; as well as Transitioning to autonomous control of the autonomous vehicle is responsive to the blinking sequence by the autonomous vehicle indicating the predicted light code pattern.

10. The system of claim 9, wherein the one or more computing devices of the infrastructure server transmit a flash light rate bit characteristic to the autonomous vehicle, the flash light rate bit characteristic for the flash sequence, the flash light rate bit characteristic indicating an on / off rate for the flash sequence.

11. The system of claim 9, wherein the one or more computing devices of the infrastructure server are configured to use an image of the blinking sequence performed by the autonomous vehicle to determine whether the blinking sequence performed by the autonomous vehicle indicates the predicted light code pattern.

12. The system of claim 11, wherein the infrastructure server is configured to request the autonomous vehicle to generate a new light code pattern in response to the blinking sequence performed by the autonomous vehicle not indicating the predicted light code pattern.

13. The system of claim 9, further comprising: A vehicle system provided with the autonomous vehicle and comprising one or more computing devices configured to: generating a light code pattern using a shared virtual key and the code length to identify the autonomous vehicle, the light code pattern being a string of binary digits in which zeros and ones are associated with an on or off state of at least one of the selected lighting devices; transmitting a vehicle public key to the infrastructure server; controlling one or more selected lighting devices of the autonomous vehicle to perform the blinking sequence indicative of the light code pattern in response to the blink command; and In response to the infrastructure server transitioning to autonomous control of the autonomous vehicle, transitioning to a platoon operating state such that the autonomous vehicle is controlled by the infrastructure server.

14. A method for autonomously controlling an autonomous vehicle, comprising: generating, by an infrastructure server, a predicted light code pattern using a vehicle public key of the autonomous vehicle to be controlled; transmitting, via the infrastructure server, a server public key and a code length to the autonomous vehicle; authenticating, by the infrastructure server, the identity of the autonomous vehicle using the vehicle public key; transmitting, by the infrastructure server, a blinking command to initiate a blinking sequence by the autonomous vehicle; as well as Transitioning to autonomous control of the autonomous vehicle by the infrastructure server in response to the blinking sequence by the autonomous vehicle indicating the predicted light code pattern.

15. The method of claim 14, further comprising: generating, by a vehicle system, a light code pattern using the shared virtual key and the code length to identify the autonomous vehicle; transmitting a vehicle public key to the infrastructure server via the vehicle system; controlling, by the vehicle system in response to the blink command, one or more selected lighting devices of the autonomous vehicle to perform the blink sequence indicative of the light code pattern; as well as In response to the infrastructure server transitioning to autonomous control of the autonomous vehicle, the vehicle system transitions to a platoon operating state such that the autonomous vehicle is controlled by the infrastructure server.

Images