System and method for remote wake-up of vehicle

Abstract

The invention provides a system and method for remote wakeup of a vehicle. A method for remotely waking up a vehicle includes requesting a vehicle power state of at least one unresponsive vehicle of a plurality of autonomously operated vehicles, verifying a current power state of the at least one unresponsive vehicle by a remote start wakeup automated vehicle grouping algorithm installed within an infrastructure, identifying that the at least one unresponsive vehicle is in an off state, and generating a wake-up command wirelessly transmitted to the at least one unresponsive vehicle over the CV2X-PC5 protocol.

Description

Technical Field

[0001] The present disclosure relates to waking a vehicle remotely. More specifically, the present disclosure relates to waking a vehicle remotely via a secure wireless connection. Background Art

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

[0003] Infrastructure for marshaling vehicles is capable of remotely waking up vehicles via cellular wireless communications. However, by relying on cellular wireless communications, the cost of the manufacturing process is significantly increased. In addition, when using cellular wireless communications, network congestion and packet delays are common. Furthermore, when relying on cellular communications, communications between the infrastructure and the vehicle may be vulnerable to relay attacks. The present disclosure addresses these and other issues associated with remotely waking up vehicles. Summary of the invention

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

[0005] The present disclosure provides a computer-implemented method, comprising: requesting a vehicle power state of at least one non-responsive vehicle from at least one non-responsive vehicle of a plurality of autonomously operated vehicles; waking up an automated vehicle marshaling (AVM) algorithm via a remote start installed in an infrastructure and verifying a current power state of at least one non-responsive vehicle in response to the request; identifying that the at least one non-responsive vehicle is in an off state based on the current power state of the at least one non-responsive vehicle not exceeding a threshold; and generating a remote wake-up command based on identifying that the at least one non-responsive vehicle is in the off state, wherein the remote wake-up command is wirelessly transmitted to the at least one non-responsive vehicle via a CV2X-PC5 protocol; further comprising: broadcasting one or more commands to each of the vehicles of the plurality of autonomously operated vehicles, wherein the one or more commands include the remote wake-up command; receiving a return message from each of the vehicles of the plurality of autonomously operated vehicles and based on the broadcast one or more commands, wherein the return message confirms receipt of the broadcast one or more commands; and determining, by the AVM algorithm, a globally unique identifier (GUI) associated with the infrastructure. D) matches the GUID of the return message; wherein the threshold is defined by the current power state not exceeding the minimum power value, the time period of at least one day during which the at least one unresponsive vehicle is in the shutdown state, or a combination thereof; further comprising: receiving battery data associated with the at least one unresponsive vehicle based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, wherein the battery data includes a discharge state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one unresponsive vehicle; further comprising: receiving battery data associated with the at least one unresponsive vehicle based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, wherein the battery data includes a charge utilization state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one unresponsive vehicle; and wherein generating the remote wake-up command further comprises: switching the power mode state of the at least one unresponsive vehicle from a full power mode to a low power mode based on identifying that the at least one unresponsive vehicle is in the shutdown state; and causing the at least one unresponsive vehicle to enter the shutdown state based on switching from the full power mode to the low power mode.

[0006] The present disclosure provides another method, the method comprising: receiving a remote wake-up command from an infrastructure at an autonomously operated vehicle in a shutdown state, wherein the remote wake-up command is wirelessly transmitted via a CV2X-PC5 protocol; determining, by a remote start wake-up automated vehicle marshaling (AVM) algorithm installed on the autonomously operated vehicle, that a globally unique identifier (GUID) associated with the autonomously operated vehicle matches the GUID of the remote wake-up command; transmitting one or more updates to the infrastructure based on a low power supply battery and a high power supply battery exceeding a power threshold and the GUID of the autonomously operated vehicle matches the GUID of the remote wake-up command, wherein the one or more updates are wirelessly transmitted via the CV2X-PC5 protocol; and initiating communication with the autonomously operated vehicle based on the one or more updates sent to the infrastructure. a shutdown sequence associated with a vehicle of the autonomous operation; further comprising: monitoring the low power supply battery and the high power supply battery when the autonomous operation vehicle is in the shutdown state; wherein initiating the shutdown sequence further comprises: in response to a specified charge associated with the low power supply battery or the high power supply battery dropping below the power threshold, transmitting battery data associated with the autonomous operation vehicle to the infrastructure; stopping the autonomous operation vehicle based on the battery data; and disconnecting the autonomous operation vehicle from the infrastructure based on the battery data and the stopping of the autonomous operation vehicle; and wherein the battery data comprises a discharge state of a low voltage battery state and a high voltage battery state corresponding to the autonomous operation vehicle; and wherein the battery data comprises a charge utilization state of a low voltage battery state and a high voltage battery state corresponding to the autonomous operation vehicle.

[0007] The present disclosure provides a system, comprising: an infrastructure configured to: request a vehicle power state of at least one non-responsive vehicle from at least one non-responsive vehicle of a plurality of autonomously operated vehicles; wake up an automated vehicle marshaling (AVM) algorithm via a remote start installed in the infrastructure and verify a current power state of at least one non-responsive vehicle in response to the request; identify that the at least one non-responsive vehicle is in an off state based on the current power state of the at least one non-responsive vehicle not exceeding a threshold; and generate a remote wake-up command based on identifying that the at least one non-responsive vehicle is in the off state, wherein the remote wake-up command is wirelessly transmitted to the at least one non-responsive vehicle via a CV2X-PC5 protocol. an unresponsive vehicle; and the plurality of autonomously operated vehicles configured to: receive a remote wake-up command from an infrastructure at each of the plurality of autonomously operated vehicles in an off state; determine, by an AVM algorithm installed on each of the plurality of autonomously operated vehicles, that a globally unique identifier (GUID) installed on each of the plurality of autonomously operated vehicles matches the GUID of the remote wake-up command; transmit one or more updates to the infrastructure based on a low power supply battery and a high power supply battery not exceeding a power threshold and the GUID associated with each of the plurality of autonomously operated vehicles matches the GUID of the remote wake-up command, wherein The one or more updates are wirelessly transmitted via the CV2X-PC5 protocol; identifying at least one unresponsive vehicle from the plurality of autonomously operated vehicles based on the one or more updates sent to the infrastructure, and initiating a shutdown sequence associated with the at least one unresponsive vehicle based on the identification of the at least one unresponsive vehicle, wherein the infrastructure is further configured to: broadcast one or more commands to each of the vehicles in the plurality of autonomously operated vehicles, wherein the one or more commands include the remote wake-up command; and receiving a return message from each of the vehicles in the plurality of autonomously operated vehicles and based on the broadcast one or more commands, wherein the return message confirms that the vehicle has been shut down. receiving one or more commands of the broadcast; and determining, by the AVM algorithm installed in the infrastructure, that a GUID associated with the infrastructure matches the GUID of the return message; wherein the threshold is defined by the current power state not exceeding a minimum charge value, a time period of at least one day during which the at least one unresponsive vehicle is in the off state, or a combination thereof; wherein the infrastructure is further configured to: receive battery data associated with the at least one unresponsive vehicle based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, wherein the battery data includes a discharge state of a low voltage battery state and a high voltage battery state corresponding to the at least one unresponsive vehicle;wherein the infrastructure is further configured to: receive battery data associated with the at least one unresponsive vehicle based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, wherein the battery data includes a charging utilization state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one unresponsive vehicle; wherein each of the plurality of autonomously operated vehicles is further configured to: monitor the low-power supply battery and the high-power supply battery when each of the plurality of autonomously operated vehicles is in the off state; wherein each of the plurality of autonomously operated vehicles is further configured to: respond to a charge condition associated with the low-power supply battery transmitting battery data associated with the at least one unresponsive vehicle to the infrastructure when a specified charge level associated with the supply battery or the high power supply battery drops below the power threshold; stopping the at least one unresponsive vehicle based on the battery data; and disconnecting the at least one unresponsive vehicle from the infrastructure based on the battery data and the stopping of the at least one unresponsive vehicle; wherein the battery data includes a discharge state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle; and wherein the battery data includes a charge utilization state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle. ;

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

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

[0010] Figure 1 An overall system for autonomous vehicle teaming according to various implementations is shown;

[0011] Figure 2 Implementations of a system for automated vehicle marshaling according to various implementations are shown;

[0012] Figure 3 According to various implementations, Figure 1 and Figure 2 The system distribution vehicle shown in;

[0013] Figure 4 A method for remote wakeup according to various implementations is shown. Figure 3 the systems of the vehicle shown;

[0014] Figure 5 is a diagram showing a method for remote wake-up according to various implementations. Figure 3A flow chart of an example method for a vehicle is shown;

[0015] Figure 6 is a diagram showing a method for remote wake-up according to various implementations. Figure 3 A flowchart of another example method of a vehicle is shown;

[0016] Figure 7 is a diagram showing a method for remote wake-up according to various implementations. Figure 3 A flowchart of another example method of a vehicle is shown; and

[0017] Figure 8 is a diagram showing a method for remote wake-up according to various implementations. Figure 3 A flow chart of another example method for a vehicle is shown.

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

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

[0020] One or more examples described herein provide a means for remotely waking a vehicle using the CV2X-PC5 secure wireless communication protocol. By using the CV2X-PC5 secure wireless communication protocol, various inefficiencies are mitigated due to the use of alternative communication methods rather than cellular means. Additionally, network congestion and / or packet delays are reduced by using the CV2X-PC5 secure wireless communication protocol and one or more examples described herein. Additionally, delay attacks may be reduced by using the CV2X-PC5 secure wireless communication protocol and one or more examples described herein.

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

[0022] The AVM system 100 generally includes a vehicle manufacturing cloud 102, a vehicle delivery manager cloud 104, a vehicle customer portal account 106, an infrastructure 108, and a vehicle 110. The vehicle manufacturing cloud 102 operates as a central cloud system that manages and / or facilitates any manufacturing processes associated with the vehicle 110. The vehicle manufacturing cloud 102 communicates wirelessly with the vehicle delivery manager cloud 104 and the infrastructure 108. The vehicle manufacturing cloud 102 also communicates wirelessly with the vehicle 110.

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

[0024] For example, the vehicle manufacturing cloud 102 is also configured to communicate directly with one or more vehicles to start, stop, or pause the progress of one or more vehicles through a factory floor or a parking lot. For example, the vehicle manufacturing cloud 102 is also configured to control the speed of one or more vehicles as the one or more vehicles travel through, for example, a factory floor or a parking lot. For example, the vehicle 110 utilizes the AVM algorithm 112 to send instructions to the vehicle 110 and / or process information received from the vehicle 110.

[0025] The infrastructure 108 includes a remote start wake-up infrastructure (IX) algorithm 113a, one or more sensors 114, and a sensor component 116. It should be understood that the sensor component 116 can be, for example, a sensor controller. The sensor component 116 provides communication between one or more infrastructures (e.g., infrastructure 108) and one or more vehicles. For example, the sensor component 116 can utilize GPS, Wi-Fi, satellite, 3G / 4G / 5G and / or Bluetooth. TMTo communicate with one or more vehicles. The sensor component 116 also communicates with one or more sensors 114 (e.g., such as one or more of a camera, a lidar, a radar, and / or an ultrasonic device). When one or more vehicles move through, for example, a factory floor or a parking lot, one or more sensors 114 monitor the movement of the vehicles. As an example, the infrastructure 108 utilizes a remote start wake-up IX algorithm 113a to process information and send the information to the vehicle manufacturing cloud 102 and / or process information received from the vehicle manufacturing cloud 102. As another example, the infrastructure 108 utilizes a remote start wake-up IX algorithm 113a to process information and send the information directly to the vehicle 110 and / or process information received from the vehicle 110. It should be understood that the infrastructure 108 can forward instructions received from the vehicle manufacturing cloud 102 to the vehicle 110. However, it should also be understood that the infrastructure 108 can send instructions directly to the vehicle 110.

[0026] The vehicle 110 includes a remote start wake-up algorithm 113b, a wireless transmission module 118, a vehicle central gateway module 120, a vehicle infotainment system 122, one or more vehicle sensors 124, a vehicle battery 126, a vehicle global navigation satellite system 128, a vehicle navigation map 130, vehicle exterior lights 132, and a controller area network (CAN) vehicle bus 133. The wireless transmission module 118 may be a transmission control unit (TCU). The wireless transmission module 118 includes one or more sensors configured to collect data and send signals to other components of the vehicle 110. The one or more sensors of the wireless transmission module 118 may include a vehicle speed sensor (not shown) configured to determine the current speed of the vehicle 110; a wheel speed sensor (not shown) configured to determine whether the vehicle 110 is traveling uphill or downhill; a throttle position sensor (not shown) that determines whether a downshift or upshift of one or more gears associated with the vehicle 110 is required in the current state of the vehicle 110; and / or a turbine speed sensor (not shown) configured to transmit data associated with the speed of the torque converter of the vehicle 110. The wireless transmission module 118 transmits the information collected by the one or more sensors to the remote start wake-up algorithm 113b. In one embodiment, the remote start wake-up algorithm 113b may be provided as a component within the wireless transmission module 118. For example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process the information collected by the one or more sensors and transmit the information to the infrastructure 108. As another example, the vehicle 110 utilizes a remote start wake-up algorithm 113b to process information collected by one or more sensors and send the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113b is configured to transmit information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the wireless transmission module 118.

[0027] The vehicle central gateway module 120 operates as an interface between various vehicle domain bus systems, such as an engine compartment bus (not shown), an internal bus (not shown), an optical bus for multimedia (not shown), a diagnostic bus for maintenance (not shown), or a vehicle CAN bus 133. The vehicle central gateway module 120 is configured to distribute data transmitted to the vehicle central gateway module 120 by each of the various domain bus systems to other components of the vehicle 110. The vehicle central gateway module 120 is also configured to distribute information received from the remote start wake-up algorithm 113b to various domain bus systems. The vehicle central gateway module 120 is also configured to send information received from various domain bus systems to the remote start wake-up algorithm 113b. For example, the vehicle 110 uses the remote start wake-up algorithm 113b to process the information received from the vehicle central gateway module 120 and send the information to the infrastructure 108. As another example, the vehicle 110 uses the remote start wake-up algorithm 113b to process the information received from the vehicle central gateway module 120 and send the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113 b is configured to communicate information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the vehicle central gateway module 120 .

[0028] The vehicle infotainment system 122 is a system that delivers a combination of information and entertainment content and / or services to the user 144 of the vehicle 110. It should be understood that in some examples, the vehicle infotainment system 122 can deliver only entertainment content to the user 144 of the vehicle 110. It should also be understood that in other examples, the vehicle infotainment system 122 can deliver information services to anyone associated with the vehicle 110. As an example, the vehicle infotainment system 122 includes a built-in car computer that combines one or more functions, such as a digital radio, a built-in camera, and / or a television. The vehicle infotainment system 122 transmits information associated with the built-in car computer or processor to the remote start wake-up algorithm 113b. For example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process information received from the vehicle infotainment system 122 and sends the information to the infrastructure 108. As another example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process information received from the vehicle infotainment system 122 and sends the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113 b is configured to communicate information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the vehicle infotainment system 122 .

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

[0030] The one or more vehicle sensors 124 transmit information associated with the location and / or distance of the vehicle 110 relative to the object to the remote start wake-up algorithm 113b. For example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process the information received from the one or more vehicle sensors 124 and transmit the information to the infrastructure 108. As another example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process the information received from the one or more vehicle sensors 124 and transmit the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113b is configured to transmit the information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the one or more vehicle sensors 124.

[0031] The vehicle battery 126 is controlled by a battery management system (not shown) that provides instructions to the vehicle battery 126. For example, the battery management system provides instructions to the vehicle battery 126 based on the temperature of the vehicle battery 126. However, it should be understood that the battery management system can provide instructions to the vehicle battery 126 based on any metric associated with the vehicle battery 126, such as the power state of the vehicle 110, the time period during which the vehicle 110 is in an off state for at least one day, or a combination thereof. The battery management system ensures that the current mode of the vehicle battery 126 is acceptable. For example, the acceptable current mode prevents overvoltage, overcharging, and / or overheating of the vehicle battery 126. As another example, the temperature of the vehicle battery 126 indicates to the battery management system whether any of the acceptable current modes is within an acceptable temperature range. The battery management system associated with the vehicle battery 126 transmits information associated with the temperature of the vehicle battery 126 to the remote start wake-up algorithm 113b. For example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process the received information about the vehicle battery 126 and send the information to the infrastructure 108. As another example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process information about the vehicle battery 126 and send the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113b is configured to transmit information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the vehicle battery 126.

[0032] The vehicle GNSS 128 is configured to communicate with satellites so that the vehicle 110 can determine the specific location of the vehicle 110. The vehicle navigation map 132 can display the specific location of the vehicle 110 to the user 144 via a display screen (not shown). The vehicle GNSS 128 transmits geographic information associated with the vehicle 110 to the remote start wake-up algorithm 113b. For example, the vehicle 110 uses the remote start wake-up algorithm 113b to process information received from the vehicle GNSS 128 and send the information to the infrastructure 108. As another example, the vehicle 110 uses the remote start wake-up algorithm 113b to process information from the vehicle GNSS 128 and send the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113b is configured to transmit information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the vehicle GNSS 128. As another example, the vehicle 110 uses the remote start wake-up algorithm 113b to process information associated with the vehicle navigation map 130 and send the information to the infrastructure 108. As another example, the vehicle 110 utilizes the remote start wake-up algorithm 113b to process information from the vehicle navigation map 132 and send the information directly to the vehicle manufacturing cloud 102. The remote start wake-up algorithm 113b is configured to transmit information and / or instructions received from the infrastructure 108 and / or the vehicle manufacturing cloud 102 to the vehicle navigation map 130.

[0033] The vehicle exterior lights 132 may include one or more lights embedded around the perimeter of the vehicle 110. For example, the vehicle exterior lights 132 include, but are not limited to, low beam headlights, high beam headlights, parking lights, daytime running lights, fog lights, signal lights, side marker lights, cab lights, tail lights, brake lights, center mounted brake lights, and / or reverse lights. The vehicle exterior lights 132 are configured to automatically turn on and off based on external weather conditions. The vehicle exterior lights 132 are also configured to automatically turn on and off based on the brightness of light adjacent to the vehicle 110 (such as sunlight, artificial light, and / or the absence of light and / or the reduction of light). The vehicle exterior lights 132 are also configured to be manually turned on and off by a user 144. In addition, the vehicle exterior lights 132 are configured to turn on and off in a certain pattern to provide visual notifications or information, such as indications of one or more faults. For example, one or more failures may be an unplanned disconnection between the infrastructure 108 and the vehicle 110, which may be associated with, but not limited to, onboarding, offboarding, and / or re-onboarding of the vehicle 110 from the infrastructure 108. The vehicle 110 transmits one or more instructions to the vehicle exterior lights 132 based on the remote start wake-up algorithm 113b. For example, the vehicle 110 transmits one or more instructions received from the infrastructure 108 to the vehicle exterior lights 132. As another example, the vehicle 110 transmits one or more instructions received from the vehicle manufacturing cloud 102 directly to the vehicle exterior lights 132.

[0034] The vehicle delivery manager cloud 104 wirelessly communicates (e.g., receives and / or sends instructions and / or information) with one or more of a rental agency cloud 134, a valet parking agency cloud 136, an insurance agency cloud 138, and / or a dealer 140. The vehicle delivery manager cloud 104 is configured to facilitate the delivery of one or more vehicles to any of a rental agency (not shown) associated with the rental agency cloud 134, a valet parking agency (not shown) associated with the valet parking agency cloud 136, an insurance agency (not shown) associated with the insurance agency cloud 138, and / or a dealer 140. The vehicle delivery manager cloud 104 also wirelessly communicates with the vehicle customer portal account 106. It should be understood that in one or more examples, other cloud systems may be included.

[0035] The delivery manager cloud 104 communicates wirelessly with a user device 142, such as a mobile device, a display panel, and / or a computer. The vehicle 110 is also configured to communicate wirelessly directly with the user device 142. For example, the user 144 engages with the user device 142 via an application that organizes any information and / or instructions received from the vehicle customer portal account 106 and / or the vehicle 110. As another example, the user 144 may send one or more instructions to the vehicle customer portal account 106, such as selecting which vehicle the user 144 wants to receive from any of a rental agency associated with the rental agency cloud 134, a valet parking agency associated with the valet parking agency cloud 136, an insurance agency associated with the insurance agency cloud 138, and / or a dealer 140.

[0036] Figure 2 The engagement of the vehicle 110 with the infrastructure 108 is shown in a case where the vehicle 110 communicates wirelessly with the infrastructure 108. For example, there may be situations where the vehicle 110 will not be able to communicate with the infrastructure 108, as will be described. In other words, there may be situations where the infrastructure 108 may not be able to detect the vehicle 110, as will be described. Typically, in this particular example, the manufacturing plant information technology (IT) system 202 communicates wirelessly with the vehicle manufacturing cloud 102. The manufacturing plant information technology system 202 is also connected to the AVM central server edge 204. It should be understood that the manufacturing plant information technology system 202 can be wirelessly connected to the AVM central server edge 204, where the manufacturing plant information technology system 202 is configured to communicate with the AVM central server edge 204. It should also be understood that the manufacturing plant information technology system 202 can be hardwired to the AVM central server edge 204. The AVM central server edge 204 receives one or more signals from a roadside unit (RSU) 206. It should be understood that the AVM central server edge 204 can be wirelessly connected to one or more infrastructures (e.g., infrastructure 108) and configured to communicate with one or more infrastructures (e.g., infrastructure 108). It should also be understood that the AVM central server edge 204 can be hardwired to one or more infrastructures. The vehicle 110 is wirelessly connected to each of the vehicle manufacturing cloud 102 and / or the RSU 206, wherein the vehicle 110 is configured to communicate with each of the vehicle manufacturing cloud 102 and / or the RSU 206.

[0037] One or more infrastructures utilize the remote start wake-up algorithm 113b to enable one or more vehicles to perform various tasks associated with the formation of one or more vehicles. Specifically, the various tasks may include exchanging wake-up messages between one or more infrastructures and one or more vehicles to facilitate detection of one or more vehicles and initiation of remote wake-up processes / actions of one or more vehicles.

[0038] Further references Figure 3 , in various forms, one or more vehicles (e.g., vehicle 110) may be powered in various ways, such as with an electric motor. It should be understood that one or more vehicles may also be powered by an internal combustion engine. For example, one or more vehicles may be any type of electric vehicle, such as a car, truck, robot, airplane, and / or boat. The one or more vehicles include a controller 300, one or more actuators 302, a plurality of onboard sensors 304, and a human-machine interface (HMI) 306. The one or more vehicles have a reference point 308, i.e., a designated point within the space defined by the vehicle body, such as a geometric center point where the respective longitudinal and transverse center axes of each of the one or more vehicles intersect. The reference point 308 identifies the location of the one or more vehicles, such as a point at which the one or more vehicles are located when the one or more vehicles are navigating toward a waypoint.

[0039] The controller 300 operates one or more vehicles in an autonomous or semi-autonomous mode. In each of the autonomous mode and / or the semi-autonomous mode, each of the propulsion, braking and steering of the one or more vehicles is controlled by the controller 300.

[0040] In some examples, the controller 300 is configured or programmed to control the operation of one or more of vehicle braking, propulsion (e.g., controlling the acceleration of the vehicle by controlling one or more of an internal combustion engine, an electric motor, a hybrid engine, etc.), steering, climate control, interior and / or exterior lights, etc., and to determine whether and when the controller 300 (rather than a human operator) controls such operations. Additionally, the controller 300 is programmed to determine whether and when a human operator controls such operations.

[0041] The controller 300 includes or may be communicatively coupled (e.g., via a vehicle communication bus) to one or more processors, such as controllers included in one or more vehicles for monitoring and / or controlling various vehicle controllers, such as a powertrain controller, a brake controller, a steering controller, etc. The controller 300 is typically arranged to communicate over a vehicle communication network, which may include a bus in each of the one or more vehicles, such as a vehicle CAN bus 133, etc., and / or other wired and / or wireless mechanisms.

[0042] The controller 300 transmits and / or receives messages to and / or from various devices in each of the one or more vehicles, such as one or more actuators 302, HMI 306, etc., via the vehicle network. Alternatively or additionally, where the controller 300 includes multiple devices, the vehicle communication network is used for communication between the devices represented in this disclosure as the controller 300. In addition, as discussed below, various other controllers and / or sensors provide data to the controller 300 via the vehicle communication network.

[0043] In addition, the controller 300 is configured to communicate with other traffic objects (e.g., vehicles, infrastructure, pedestrians, etc.), such as via a vehicle-to-vehicle communication network through a wireless vehicle communication interface. The controller 200 is also configured to communicate through the vehicle-to-infrastructure communication network, such as communicating with the sensor components 116 of the infrastructure 108. The vehicle communication network represents one or more mechanisms by which the controller 300 of each of the one or more vehicles can communicate with other traffic objects, and can be one or more of the wireless communication mechanisms, including any desired combination of wireless (e.g., cellular, wireless, satellite, microwave, and radio frequency) communication mechanisms and any desired network topology (or multiple topologies when multiple communication mechanisms are used). Examples of vehicle communication networks include cellular, IEEE 802.11, Dedicated Short Range Communications (DSRC) and / or Wide Area Network (WAN) (including the Internet), etc.

[0044] The vehicle actuator 302 is implemented via a circuit, chip, or other electronic and / or mechanical component that can actuate various vehicle subsystems according to appropriate control signals. The actuator 302 can be used to control the braking, acceleration, and / or steering of one or more vehicles. The controller 300 can be programmed to actuate the vehicle actuator 302 (including the propulsion actuator, the steering actuator, and / or the brake actuator) based on the planned acceleration or deceleration of one or more vehicles.

[0045] The HMI 306 is configured to receive information from a user (such as a human operator) during operation of one or more vehicles. In addition, the HMI 306 is configured to present information to a user (such as an occupant of one or more of the vehicles 110). In some variations, the controller 300 is programmed to receive destination data, such as location coordinates, from the HMI 306.

[0046] Sensors 304 include various devices to provide data to controller 300. For example, sensors 304 may include object detection sensors, such as lidar sensors disposed on or in each of the one or more vehicles, which provide the relative position, size, and shape of one or more targets (e.g., additional vehicles, bicycles, pedestrians, robots, drones, etc.) traveling beside, in front of, and / or behind any of the one or more vehicles around the one or more vehicles. As another example, one or more of the sensors may be radar sensors fixed to one or more bumpers of the one or more vehicles, which may provide the position of the target relative to the position of each of the one or more vehicles.

[0047] The object detection sensor may include a camera sensor, for example to provide a front view, a side view, a rear view, etc., which provides images from the area surrounding the one or more vehicles. For example, the controller 300 may be programmed to receive image data from the camera sensor and implement image processing techniques to detect roads, infrastructure elements, etc. The controller 300 may also be programmed to determine the current vehicle position based on position coordinates (e.g., GPS coordinates) received from the one or more vehicles and indicating the position of the one or more vehicles from a GPS sensor. Thus, each of the one or more vehicles may be autonomously guided toward a waypoint using a combination of sensors 114 and vehicle sensors (e.g., onboard sensors 304).

[0048] In another embodiment, Figure 4 A system 400 is shown that is configured to facilitate communication and remote wake-up functionality between an infrastructure 108 and one or more vehicles (e.g., vehicle 110). Typically, the infrastructure 108 communicates with the vehicle 110 using one of two means via a cellular protocol or a secure wireless protocol. However, it should be understood that the infrastructure 108 can communicate with the vehicle 110 by any other means. It should also be understood that the secure wireless protocol can include a CV2X-PC5 protocol and / or be sent via a CV2X-PC5 protocol. However, it should be understood that any secure communication protocol can be used. More specifically, a remote start wake-up algorithm 113b installed on the vehicle 110 is used to optimize the management of remote wake-up and shutdown of the vehicle 110 to provide rapid control capabilities to the infrastructure 108 using CV2X-PC5 wireless communication.

[0049] like Figure 4As shown, the infrastructure 108 generally includes a manufacturing plant IT system 202, an AVM cloud local (on-prem) multi-access edge computing (MEC) component 402, an AVM sensor infrastructure 404, and an AVM central server edge 204. The AVM central server edge 204 operates as a central server of the infrastructure 108, which utilizes an AVM application 406 to process communications ultimately received from each of the remote start wake-up IX algorithm 113a installed in the infrastructure 108 and the remote start wake-up algorithm 113b installed in the vehicle 110. The AVM application 406 is configured to communicate directly with the vehicle 110 using the wireless CV2X-PC5 protocol to initiate and / or maintain a marshaling process associated with the vehicle 110 going online, going offline, and / or going back online with the infrastructure 108. The AVM application 406 is also configured to communicate with the manufacturing plant IT system 202 and the marshaling process associated with the vehicle 110 going online, going offline, and / or going back online with the infrastructure 108. It should be appreciated that the AVM application 406 may be wirelessly connected to the fab IT system component 202. It should also be appreciated that the AVM application 406 may be hardwired to the fab IT system component 202.

[0050] The manufacturing plant IT system 202 is configured to communicate with the AVM cloud on-prem MEC 402. The AVM cloud on-prem MEC 402 includes a remote start wake-up IX algorithm 113a. For example, the AVM cloud on-prem MEC 402 may transmit a command based on one or more decisions made by the remote start wake-up IX algorithm 113a. The decisions made by the remote start wake-up IX algorithm 113a are based on critical information stored in the AVM cloud on-prem MEC 402. The decisions made by the remote start wake-up IX algorithm 113a are alternatively based on non-critical information stored by the vehicle manufacturing cloud 104. For example, the critical information may include, but is not limited to, the state of charge of the vehicle battery (e.g., low voltage, high voltage, or a combination thereof), the range of the vehicle, the gear status of the vehicle (e.g., park / reverse / neutral / drive / low gear), the power mode status of the vehicle, the wireless communication status of the vehicle, the location of the vehicle, the emergency stop status of the infrastructure associated with one or more vehicles, and / or the station status of the infrastructure associated with one or more vehicles. As another example, non-critical information may include, but is not limited to, feature activation status of the vehicle, feature deactivation status of the vehicle, power mode status of the vehicle during activation, power mode status of the vehicle during deactivation, and deregistering critical functions of the corresponding vehicle in the event that one or more critical functions become non-critical associated with the vehicle manufacturing cloud 104. In addition, the AVM on-prem MEC 402 is configured to communicate with the vehicle manufacturing cloud 104 and the marshaling process associated with the on-line, off-line, and / or re-online of the vehicle 110 with the infrastructure 108. As another example, the manufacturing plant IT system 202 is configured to communicate with the AVM cloud on-prem MEC 113a and the marshaling process associated with the on-line, off-line, and / or re-online of the vehicle 110 with the infrastructure 108. It should be understood that the AVM cloud on-prem MEC 402 can be wirelessly connected to the manufacturing plant IT system 202. It should also be understood that the AVM cloud on-prem MEC 402 can be hardwired to the manufacturing plant IT system 202. It should also be understood that the AVM cloud on-prem MEC 402 is wirelessly connected to the vehicle manufacturing cloud 104. Figure 4 The use of a MEC (e.g., AVM cloud on-prem MEC 402) locally disposed relative to the infrastructure 108 is shown, but it should be understood that a remote MEC may also be used. It should be understood that in the case where a remote MEC is used, the remote MEC may be implemented at least within the system 400 in the same manner as the AVM cloud on-prem MEC 402.

[0051] The AVM application is also configured to communicate with the AVM sensor infrastructure 404. The AVM sensor infrastructure 404 is configured to process sensor inputs and / or outputs associated with one or more sensors 114. For example, the vehicle 110 can transmit various states associated with going online, going offline, and / or going back online to the one or more sensors 114 via the AVM application 406. The AVM application 406 includes a data translation service 408, which initially receives various states transmitted from the vehicle 110 and translates the various states before sending the various states to the AVM sensor infrastructure 404. The AVM sensor is configured to receive the translated various states from the AVM application 406 and process the various states. It should be understood that the AVM application 406 can be wirelessly connected to the AVM sensor infrastructure 404. It should also be understood that the AVM application 406 can be hardwired to the AVM sensor infrastructure 404.

[0052] A switch 410 is utilized within the infrastructure 108, thereby allowing the AVM application 406 to communicate with one or more RSUs (e.g., 206a-206c) and the central on-prem MEC 412. The AVM application 406 is additionally configured to process commands from the AVM cloud on-prem MEC 402 and instruct the central on-prem MEC 412 and / or one or more RSUs to take actions. For example, the central on-prem MEC 412 communicates directly with the vehicle manufacturing cloud 104 and / or the manufacturing plant IT system 202. As another example, one or more RSUs communicate directly with the vehicle 110. It should be understood that the switch 410 can wirelessly connect the AVM application 406, the central on-prem MEC 412, and each of the one or more RSUs. It should also be understood that the switch 410 can be hardwired to each of the AVM application 406, the central on-prem MEC 412, and the one or more RSUs.

[0053] The one or more RSUs are configured to send a remote start wake-up message to the vehicle 110. It should be understood that the remote start wake-up message is sent via the CV2X-PC5 protocol. Each of the one or more RSUs includes a content management system (CMS) RSU application 414 that is utilized by the one or more RSUs to process a wake-up message response status received from the vehicle 110.

[0054] The vehicle 110 typically includes a TCU 118, a vehicle central gateway module, and a vehicle advanced driver assistance system (ADAS) module 416. The TCU 118 is configured to process information collected by one or more sensors using a remote start wake-up algorithm 113b that is provided as a component within the TCU 118, as described above. The vehicle central gateway module 120 operates as an interface (such as, for example, a vehicle CAN bus 133) between at least the TCU 118 and the vehicle ADAS module 416. It should be understood that the vehicle central gateway module 120 can be wirelessly connected to each of the TCU 118 and the vehicle ADAS module 416. It should also be understood that the vehicle central gateway module 120 can be hardwired to each of the TCU 118 and the vehicle ADAS module 416.

[0055] The vehicle 110 is also configured to communicate with the vehicle manufacturing cloud 104 via cellular means. In addition, the vehicle can communicate marshaling processes associated with the on-line, off-line, and / or re-online of the vehicle 110 with the vehicle manufacturing cloud via a wireless connection. Although the infrastructure 108 is depicted as communicating with the vehicle 110 so that the vehicle 110 can be remotely awakened, it should be understood that a user device (e.g., a phone, a computer, etc.) can be used as a key, where in an embodiment, the user device will replace the functionality of the infrastructure 108. It should be understood that any operating device that has the functionality of the infrastructure 108 as described above can replace the infrastructure 108 in its communication with the vehicle 108.

[0056] Figure 5 is a flow chart illustrating an example method 500 for remotely waking up a vehicle (e.g., vehicle 110). At operation 502, a vehicle power state of at least one unresponsive vehicle among a plurality of autonomously operated vehicles is requested. At operation 504, a current power state of at least one unresponsive vehicle is verified. For example, verification of the current power state of at least one unresponsive vehicle is enabled via a remote start wake-up automated vehicle marshaling (AVM) algorithm. As another example, the remote start wake-up AVM algorithm is installed within an infrastructure (e.g., infrastructure 108). As yet another example, verification of the current power state of at least one unresponsive vehicle is enabled in response to a request for the vehicle power state of at least one unresponsive vehicle. Additionally, verification of the current power state of at least one unresponsive vehicle is enabled via a remote start wake-up AVM algorithm and in response to a request for the vehicle power state of at least one unresponsive vehicle.

[0057] At operation 506, at least one unresponsive vehicle is identified as being in an off state. For example, the at least one unresponsive vehicle is identified as being in an off state based on the current power state of the at least one unresponsive vehicle not exceeding a threshold. It should be understood that the threshold is defined by the current power state not exceeding a minimum charge value, a time period of at least one day during which the at least one unresponsive vehicle is in an off state, or a combination thereof.

[0058] At operation 508, a remote wake-up command is generated. For example, the remote wake-up command is generated based on identifying that at least one unresponsive vehicle is in an off state. As another example, the remote wake-up command is wirelessly transmitted to the at least one unresponsive vehicle via the CV2X-PC5 protocol. As yet another example, the power mode state of the at least one unresponsive vehicle is switched from a full power mode to a low power mode. For example, switching the power mode state of the at least one unresponsive vehicle from a full power mode to a low power mode is based on identifying that at least one unresponsive vehicle is in an off state. As another example, at least one unresponsive vehicle is caused to enter an off state. At least one unresponsive vehicle is caused to enter an off state based on switching from a full power mode to a low power mode.

[0059] In an embodiment, one or more commands are broadcast. For example, one or more commands are broadcast to each of a plurality of autonomously operated vehicles. For example, the one or more commands include a remote wake-up command. In another embodiment, a return message is received. For example, a return message is received from each of a plurality of autonomously operated vehicles. As another example, a return message is received based on the broadcast one or more commands. As yet another example, the return message confirms receipt of the broadcast one or more commands. In yet another embodiment, a globally unique identifier (GUID) associated with the infrastructure is determined to match the GUID of the return message. For example, an AVM algorithm is used to determine whether the GUID associated with the infrastructure matches the GUID of the return message.

[0060] In an embodiment, battery data associated with at least one unresponsive vehicle is received. For example, battery data associated with at least one unresponsive vehicle is received based on the current power state of the at least one unresponsive vehicle not exceeding a threshold. As another example, the battery data may include a discharge state of a low voltage battery state and a high voltage battery state corresponding to the at least one unresponsive vehicle. However, in another example, the battery data may include a charge utilization state of a low voltage battery state and a high voltage battery state corresponding to the at least one unresponsive vehicle.

[0061] Figure 66 is a flow chart illustrating an example method 600 for remotely waking up a vehicle (e.g., vehicle 110). At operation 602, a vehicle power state of at least one unresponsive vehicle among a plurality of autonomously operated vehicles is requested. At operation 604, a current power state of at least one unresponsive vehicle is verified. For example, verification of the current power state of at least one unresponsive vehicle is enabled via a remote start wake-up automated vehicle marshaling (AVM) algorithm. As another example, the remote start wake-up AVM algorithm is installed within an infrastructure (e.g., infrastructure 108). As yet another example, verification of the current power state of at least one unresponsive vehicle is enabled in response to a request for the vehicle power state of at least one unresponsive vehicle. Additionally, verification of the current power state of at least one unresponsive vehicle is enabled via a remote start wake-up AVM algorithm and in response to a request for the vehicle power state of at least one unresponsive vehicle.

[0062] At operation 606, a determination is made as to whether a response message has been received from the autonomously operated vehicle. In the event that a response message has been received from the autonomously operated vehicle, the algorithm state stream is updated in operation 608. In operation 610, an AVM central server edge (e.g., AVM central server edge 204) is alerted that a response message has been received from the autonomously operated vehicle and / or the algorithm state stream has been updated. However, in the event that a response message has not been received from the autonomously operated vehicle, a fault associated with the autonomously operated vehicle is transmitted to a manufacturing operator at step 612.

[0063] Figure 77 is a flow chart illustrating an example method 700 for remotely waking up a vehicle (e.g., vehicle 110). At operation 702, a remote wake-up command is received. For example, a remote wake-up command is received at an autonomously operated vehicle in an off state. As an additional example, a remote wake-up command is received from an infrastructure (e.g., infrastructure 108). As another example, a remote wake-up command is transmitted wirelessly via a CV2X-PC5 protocol. Once a remote start wake-up automated vehicle marshaling (AVM) algorithm installed on an autonomously operated vehicle activates a wake-up process, the vehicle may receive a remote wake-up command. The wake-up process provides a trigger for the AVM algorithm to activate a full power mode on a transmission control unit (e.g., wireless transmission module 118) of the vehicle. The full power mode is transmitted to a corresponding vehicle module and / or a remote start wake-up AVM algorithm installed in an infrastructure. Alternatively, an AVM installed on an autonomously operated vehicle may deactivate the wake-up process. Deactivation of the wake-up process provides a trigger for the AVM algorithm to activate a low power mode on a transmission control unit of the vehicle to deactivate the wake-up process. The low power mode is communicated to the corresponding vehicle module and / or remote start wake-up AVM algorithm installed within the infrastructure. However, it should be understood that the remote wake-up command may be received at any time, including before initiating activation of the wake-up command.

[0064] At operation 704, a determination is made that a globally unique identifier (GUID) associated with the autonomously operated vehicle matches the GUID of the remote wake-up command. For example, a determination is made by a remote start wake-up AVM algorithm whether the GUID associated with the autonomously operated vehicle matches the GUID of the remote wake-up command. In the event that it is determined that the GUID associated with the autonomously operated vehicle matches the GUID of the remote wake-up command, software onboard the vehicle is activated. Upon activating the onboard software, the AVM provides the vehicle with the ability to receive messages transmitted from the infrastructure 108, as further described.

[0065] At operation 706, one or more updates are transmitted to the infrastructure. For example, one or more updates are transmitted to the infrastructure based on the low power supply battery and / or the high power supply battery exceeding a power threshold. As another example, one or more updates are transmitted to the infrastructure based on the GUID of the autonomously operated vehicle matching the GUID of the remote wake-up command. As yet another example, one or more updates are transmitted to the infrastructure based on the low power supply battery and / or the high power supply battery exceeding a power threshold and based on the GUID of the autonomously operated vehicle matching the GUID of the remote wake-up command.

[0066] At operation 708, a shutdown sequence associated with the autonomously operated vehicle is initiated. For example, a shutdown sequence associated with the autonomously operated vehicle is initiated based on one or more updates sent to the infrastructure. As an example, battery data associated with the autonomously operated vehicle is transmitted. For example, battery data associated with the autonomously operated vehicle is transmitted to the infrastructure. As an additional example, in response to a specified charge associated with the low power supply battery and / or the high power supply battery dropping below a power threshold, battery data associated with the autonomously operated vehicle is transmitted. For example, the autonomously operated vehicle stops. For example, the autonomously operated vehicle stops based on the battery data. As another example, the autonomously operated vehicle is disconnected from the infrastructure. For example, the autonomously operated vehicle is disconnected from the infrastructure based on the battery data. For example, the autonomously operated vehicle is disconnected from the infrastructure based on the autonomously operated vehicle stopping. As another example, the autonomously operated vehicle is disconnected from the infrastructure based on the autonomously operated vehicle stopping and the battery data.

[0067] For example, the battery data includes a discharge state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle. However, in another example, the battery data may include a charge utilization state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle. In an embodiment, the low power supply battery and the high power supply battery are monitored when the autonomously operated vehicle is in an off state.

[0068] Figure 8 8 is a flow chart illustrating an example method 800 for remotely waking a vehicle (e.g., vehicle 110). At operation 802, a remote wake-up command is received. For example, the remote wake-up command is received at an autonomously operated vehicle that is in an off state. As an additional example, the remote wake-up command is received from an infrastructure (e.g., infrastructure 108). As another example, the remote wake-up command is wirelessly transmitted via a CV2X-PC5 protocol. At operation 804, a determination is made as to whether a globally unique identifier (GUID) associated with the autonomously operated vehicle matches the GUID of the remote wake-up command. For example, a determination is made as to whether a GUID associated with the autonomously operated vehicle matches the GUID of the remote wake-up command by a remote start wake-up automated vehicle marshaling (AVM) algorithm installed on the autonomously operated vehicle.

[0069] At operation 806, it is determined whether the low power supply battery and / or the high power supply battery meets the power threshold. In the case where the low power supply battery and / or the high power supply battery meets the power threshold, at step 808, the vehicle range reduction, the readiness of the vehicle power mode state, or a combination thereof is transmitted to the infrastructure.

[0070] In the case where the low power supply battery and / or the high power supply battery do not meet the power threshold, the low power supply battery and the high power supply battery are monitored at operation 810. For example, the low power supply battery and the high power supply battery are monitored based on not receiving one or more updates from the infrastructure. At operation 812, an alarm is transmitted to the infrastructure. For example, the transmission of the alarm is based on the low power supply battery and / or the high power supply battery not meeting the power threshold. For example, the alarm is associated with a fault.

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

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

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

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

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

[0076] 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 should not be regarded as a departure from the spirit and scope of the present disclosure.

[0077] According to the present invention, a computer-implemented method includes: requesting the vehicle power state of at least one unresponsive vehicle among a plurality of autonomously operated vehicles from the at least one unresponsive vehicle; waking up an automated vehicle marshaling (AVM) algorithm via a remote start installed in an infrastructure and verifying the current power state of the at least one unresponsive vehicle in response to the request; identifying that the at least one unresponsive vehicle is in an off state based on the current power state of the at least one unresponsive vehicle not exceeding a threshold; and generating a remote wake-up command based on identifying that the at least one unresponsive vehicle is in the off state, wherein the remote wake-up command is wirelessly transmitted to the at least one unresponsive vehicle via a CV2X-PC5 protocol.

[0078] In one aspect of the present invention, the method includes: broadcasting one or more commands to each of the vehicles in the plurality of autonomously operating vehicles, wherein the one or more commands include the remote wake-up command; receiving a return message from each of the vehicles in the plurality of autonomously operating vehicles based on the broadcast one or more commands, wherein the return message confirms receipt of the broadcast one or more commands; and determining through the AVM algorithm that a globally unique identifier (GUID) associated with the infrastructure matches the GUID of the return message.

[0079] In one aspect of the invention, the threshold is defined by the current power state not exceeding a minimum charge value, a period of at least one day in which at least one non-responsive vehicle is in an off state, or a combination thereof.

[0080] In one aspect of the present invention, the method includes: based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, receiving battery data associated with the at least one unresponsive vehicle, wherein the battery data includes a discharge state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one unresponsive vehicle.

[0081] In one aspect of the present invention, the method includes: based on the current power state of the at least one unresponsive vehicle not exceeding the threshold, receiving battery data associated with the at least one unresponsive vehicle, wherein the battery data includes a charging utilization status of a low-voltage battery state and a high-voltage battery state corresponding to the at least one unresponsive vehicle.

[0082] In one aspect of the present invention, generating the remote wake-up command also includes: based on identifying that the at least one unresponsive vehicle is in the shutdown state, switching the power mode state of the at least one unresponsive vehicle from a full power mode to a low power mode; and based on switching from the full power mode to the low power mode, causing the at least one unresponsive vehicle to enter the shutdown state.

[0083] According to the present invention, a method includes: receiving a remote wake-up command from an infrastructure at an autonomously operated vehicle in a shutdown state, wherein the remote wake-up command is wirelessly transmitted via the CV2X-PC5 protocol; determining, through a remote start wake-up automated vehicle marshaling (AVM) algorithm installed on the autonomously operated vehicle, that a globally unique identifier (GUID) associated with the autonomously operated vehicle matches the GUID of the remote wake-up command; transmitting one or more updates to the infrastructure based on a low power supply battery and a high power supply battery exceeding a power threshold and the GUID of the autonomously operated vehicle matches the GUID of the remote wake-up command, wherein the one or more updates are wirelessly transmitted via the CV2X-PC5 protocol; and initiating a shutdown sequence associated with the autonomously operated vehicle based on the one or more updates sent to the infrastructure.

[0084] In one aspect of the invention, the method includes monitoring a low power supply battery and a high power supply battery when the autonomously operating vehicle is in a shut-off state.

[0085] In one aspect of the present invention, initiating the shutdown sequence also includes: in response to a specified charge associated with the low-power supply battery or the high-power supply battery dropping below the power threshold, transmitting battery data associated with the autonomously operated vehicle to the infrastructure; stopping the autonomously operated vehicle based on the battery data; and disconnecting the autonomously operated vehicle from the infrastructure based on the battery data and the stopping of the autonomously operated vehicle.

[0086] In one aspect of the invention, the battery data includes a discharge state of a low voltage battery state and a high voltage battery state corresponding to an autonomously operated vehicle.

[0087] In one aspect of the invention, the battery data includes a charge utilization status of a low voltage battery state and a high voltage battery state corresponding to an autonomously operated vehicle.

Claims

1. A system comprising: An infrastructure, the infrastructure being configured to: requesting, from at least one non-responsive vehicle of the plurality of autonomously operating vehicles, a vehicle power state of the at least one non-responsive vehicle, waking up an automated vehicle marshaling (AVM) algorithm via a remote start installed within the infrastructure and verifying the current power state of the at least one non-responsive vehicle in response to the request, identifying that the at least one non-responsive vehicle is in a shut-off state based on the current power state of the at least one non-responsive vehicle not exceeding a threshold, and A remote wake-up command is generated based on identifying that the at least one non-responsive vehicle is in the off state, wherein the remote wake-up command is wirelessly transmitted to the at least one non-responsive vehicle via a CV2X-PC5 protocol.

2. The system of claim 1, wherein the infrastructure is further configured to: One or more commands are broadcast to each of the vehicles in the plurality of autonomously operating vehicles, wherein the one or more commands include the remote wake-up command.

3. The system of claim 2, wherein the infrastructure is further configured to: A return message is received from each of the vehicles in the plurality of autonomously operating vehicles and based on the broadcast one or more commands, wherein the return message confirms receipt of the broadcast one or more commands.

4. The system of claim 3, wherein the infrastructure is further configured to: A globally unique identifier (GUID) associated with the infrastructure is determined by the AVM algorithm installed within the infrastructure to match the GUID of the return message.

5. The system of claim 1, wherein the threshold is defined by the current power state not exceeding a minimum charge value, a period of at least one day during which the at least one non-responsive vehicle is in the off state, or a combination thereof.

6. The system of claim 1, wherein the infrastructure is further configured to: Based on the current power state of the at least one non-responsive vehicle not exceeding the threshold, battery data associated with the at least one non-responsive vehicle is received, wherein the battery data includes a discharge state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one non-responsive vehicle.

7. The system of claim 1, wherein the infrastructure is further configured to: Based on the current power state of the at least one non-responsive vehicle not exceeding the threshold, battery data associated with the at least one non-responsive vehicle is received, wherein the battery data includes a charge utilization state of a low-voltage battery state and a high-voltage battery state corresponding to the at least one non-responsive vehicle.

8. The system of claim 1 , wherein the infrastructure configured to generate the remote wake-up command is further configured to: switching a power mode state of the at least one non-responsive vehicle from a full power mode to a low power mode based on identifying that the at least one non-responsive vehicle is in the off state; and The at least one unresponsive vehicle is caused to enter the shut-off state based on switching from the full power mode to the low power mode.

9. The system of claim 1, wherein the plurality of autonomously operated vehicles are configured to: receiving, at each vehicle of the plurality of autonomously operating vehicles in the shut-off state, the remote wake-up command from the infrastructure; and A globally unique identifier (GUID) installed on each of the plurality of autonomously operating vehicles is determined by an AVM algorithm installed on each of the vehicles in the plurality of autonomously operating vehicles to match the GUID of the remote wake-up command.

10. The system of claim 9, wherein each of the vehicles in the plurality of autonomously operated vehicles is further configured to: transmitting one or more updates to the infrastructure based on a low power supply battery and a high power supply battery not exceeding a power threshold and the GUID associated with each of the plurality of autonomously operated vehicles matching the GUID of the remote wake-up command, wherein the one or more updates are wirelessly transmitted via the CV2X-PC5 protocol; identifying the at least one non-responsive vehicle from among the plurality of autonomously operating vehicles based on the one or more updates sent to the infrastructure, and A shutdown sequence associated with the at least one non-responsive vehicle is initiated based on the identification of the at least one non-responsive vehicle.

11. The system of claim 10, wherein each of the vehicles in the plurality of autonomously operated vehicles is further configured to: The low power supply battery and the high power supply battery are monitored when each of the plurality of autonomously operating vehicles is in the shut-off state.

12. The system of claim 10, wherein each of the plurality of autonomously operated vehicles is further configured to: In response to a specified charge associated with the low power supply battery or the high power supply battery dropping below the power threshold, battery data associated with the at least one non-responsive vehicle is transmitted to the infrastructure.

13. The system of claim 12, wherein each of the plurality of autonomously operated vehicles is further configured to: stopping the at least one unresponsive vehicle based on the battery data; and Based on the battery data and the at least one unresponsive vehicle being stopped, the at least one unresponsive vehicle is disconnected from the infrastructure.

14. The system of claim 12, wherein the battery data includes a discharge state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle.

15. The system of claim 12, wherein the battery data includes a charge utilization state of a low voltage battery state and a high voltage battery state corresponding to the autonomously operated vehicle.

Images