Charger-based vehicle software update verification

Abstract

The invention provides charger-based vehicle software update verification. An iterative software update using a consumer vehicle includes sending an update request to perform a software update to a vehicle and a charging station in a test loop, wherein the vehicle is included on an update list; receiving a test report from the vehicle and the charging station; in response to the test report indicating success above a minimum success threshold, continuing to launch the software update in an additional test cycle; and otherwise, sending a resume update request to the vehicle and the charging station to roll back the software update.

Description

Technical Field

[0001] The various aspects of this disclosure generally relate to the verification of vehicle software updates based on chargers. Background Technology

[0002] Over-the-air (OTA) software downloads for vehicles can typically be done at home using cellular data or local Wi-Fi. Home charging stations have a secondary opportunity to connect to the home network. Charging stations are usually connected to the vehicle via a wired charging coupler (similar to a computer's local area network (LAN) cable). Charging stations can also connect wirelessly via Bluetooth Low Energy (BLE), Wi-Fi, etc. Summary of the Invention

[0003] In one or more illustrative examples, a method for iterative software updates using a consumer vehicle includes: sending an update request to a vehicle and a charging station in a test cycle to perform a software update, wherein the vehicle is included on an update list; receiving a test report from the vehicle and the charging station; continuing to roll out the software update in an additional test cycle in response to the test report indicating success above a minimum success threshold; and otherwise sending a recovery update request to the vehicle and the charging station to roll back the software update.

[0004] In one or more illustrative examples, a system for iterative software updates using consumer vehicles includes: a storage device that maintains vehicle information including records indicating when a vehicle previously connected to which charging station and parameters regarding the vehicle's configuration and / or characteristics; and a charger monitoring server configured to: identify an update list of vehicles to receive software updates; send update requests to apply software updates to vehicles on the update list; receive test reports from vehicles and charging stations; continue rolling out the software update in an additional test cycle in response to the test reports indicating success above a minimum success threshold; and otherwise send a recovery update request to the vehicles and the charging stations to roll back the software update.

[0005] In one or more illustrative examples, a non-transitory computer-readable medium includes instructions for iterative software updates using a consumer vehicle, the instructions, when executed by a charger monitoring server, causing the charger monitoring server to perform operations including: maintaining vehicle information, including records indicating when a vehicle previously connected to which charging station and parameters regarding the vehicle's configuration and / or characteristics; identifying an update list of vehicles to receive software updates; sending update requests to apply the software updates to vehicles on the update list; receiving test reports from the vehicles and charging stations; continuing to roll out the software updates in an additional test cycle in response to the test reports indicating success above a minimum success threshold; and otherwise sending a recovery update request to the vehicles and the charging stations to roll back the software updates. Attached Figure Description

[0006] Figure 1 An example system for implementing an iterative testing method for updating software in consumer vehicles is shown;

[0007] Figure 2 An example process for performing simultaneous software updates on vehicles and charging stations is shown;

[0008] Figure 3 An example process for a test method of implementing OTA software updates on a charger monitoring server is shown; and

[0009] Figure 4 An example computing device is shown for an iterative testing method for implementing software updates using consumer vehicles. Detailed Implementation

[0010] Detailed embodiments of the invention are disclosed herein as needed; however, it should be understood that the disclosed embodiments are merely examples of the invention that can be embodied in various forms and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of specific components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but only as representative bases for teaching those skilled in the art to employ the invention in various ways.

[0011] New vehicle charging software is validated by testing a fleet of vehicles and chargers. This approach is limited by the availability of chargers and test vehicles (typically fewer than a dozen) and does not cover all market changes that could lead to defects. As software and charging capabilities advance, such as bidirectional power from vehicle batteries to homes, validating proper functioning and sufficient download time becomes more critical. Often, both the vehicle and the charging station may require simultaneous software updates to function correctly.

[0012] An improved method for vehicle software verification and rollout can implement a testing approach where software updates are rolled out to customer vehicles using an iterative method. In this method, the server identifies vehicles to obtain statistically relevant samples from different market groups. These groups take into account climate change, thermal temperatures from previously recorded data, vehicle brand and series, power level, and installation characteristics.

[0013] In a test cycle, the server sends the software update to be installed to the vehicles and charging stations. The software update can then be installed, tested, and a test report, including the installation and testing results, can be sent back to the server. In response to a test report indicating success above a minimum success threshold, the server continues rolling out the software update in additional test cycles. If not, the server sends a revert update request to roll back the software update to the vehicles and charging stations. Further aspects of this disclosure are discussed in detail herein.

[0014] Figure 1 An example system 100 is shown for implementing an iterative testing method for updating software using a consumer vehicle 102. System 100 includes a vehicle 102 with various controllers 104. These controllers 104 include a telematics control unit (TCU) 106 to allow the vehicle 102 to communicate with remote devices via a communication network 108. These controllers 104 may also include a Global Navigation Satellite System (GNSS) controller 112, a Human-Machine Interface (HMI) controller 114, and a charging controller 116 for communicating with various charging stations 118. System 100 also includes a charger monitoring server 126 configured to communicate with the vehicle 102 and the charging stations 118 via the communication network 108. The charger monitoring server 126 can perform a charger service 128 configured to send update requests 124 to the vehicle 102 and the charging stations 118 for installing a software update 130. The charger monitoring server 126 may also be configured to receive test reports 134 from the vehicle 102 and the charging stations 118 based on the software update 130. Using test report 134, charger monitoring server 126 can determine whether software update 130 is causing a problem and can perform various actions, such as reverting software update 130, rolling out software update 130 to additional vehicle 102, etc. It should be noted that system 100 is only one example implementation and more, fewer, and / or different system 100 components can be used.

[0015] Vehicle 102 may include various types of automobiles, crossover multi-purpose vehicles (CUVs), sport multi-purpose vehicles (SUVs), trucks, recreational vehicles (RVs), boats, aircraft, or other mobile machines used for transporting people or goods. In many cases, vehicle 102 may be a battery electric vehicle (BEV) powered by a traction battery and one or more electric motors. As another possibility, vehicle 102 may be a hybrid electric vehicle powered by both an internal combustion engine, a traction battery, and one or more electric motors. Hybrid electric vehicle 102 may take various forms, such as series hybrid electric vehicles, parallel hybrid electric vehicles, or parallel / series hybrid electric vehicles. Because the type and configuration of vehicle 102 can vary, the capabilities of vehicle 102 can vary accordingly. As some possibilities, vehicle 102 may have different capabilities in terms of passenger capacity, towing capacity and volume, and storage capacity. For ownership, inventory, and other purposes, vehicle 102 may be associated with a unique identifier, such as a vehicle identification number (VIN) (e.g., defined by ISO 3779 and ISO 4030, a globally unique identifier (GUID), a customer or fleet account, etc.).

[0016] Vehicle 102 may include a plurality of controllers 104 configured to perform and manage various vehicle 102 functions under the power of the vehicle battery and / or drivetrain. As some non-limiting examples of vehicle controllers 104: a powertrain controller 104 may be configured to provide control over engine operating components (e.g., idle speed control components, fuel delivery components, emission control components, etc.) and to monitor the status of such engine operating components (e.g., the status of engine codes); a body controller 104 may be configured to manage various power control functions such as exterior lighting, interior lighting, keyless entry, remote start, and access point status verification (e.g., the closing status of the hood, doors, and / or trunk of vehicle 102); a radio transceiver controller 104 may be configured to interact with a key fob, moving device 122, or... Communication with other local vehicle 102 devices; the autonomous controller 104 can be configured to provide commands to control the powertrain, steering, or other aspects of the vehicle 102; the climate control management controller 104 can be configured to provide control over heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensors, etc.); the GNSS controller 104 can be configured to provide vehicle 102 location information; and the HMI controller 104 can be configured to receive user input via various buttons or other controls, and to provide the driver with vehicle 102 status information, such as fuel level information, engine operating temperature information, and the current location of the vehicle 102. The vehicle 102 can also be configured to use its battery and / or drivetrain to power other devices external to the vehicle 102.

[0017] TCU 106 is a controller 104 of vehicle 102 that can communicate via communication network 108. In this example, TCU 106 may be configured to provide telematics services to vehicle 102. As some non-limiting possibilities, these services may include navigation, route guidance, vehicle 102 health reporting, local business search, accident reporting, and hands-free calling. TCU 106 may include network hardware configured to facilitate communication between vehicle 102 and other devices of system 100. For example, TCU 106 may include a cellular modem or otherwise access a cellular modem configured to facilitate communication with communication network 108. As some non-limiting examples, communication network 108 may include one or more interconnected communication networks, such as the Internet, cable television distribution networks, satellite link networks, local area networks, and telephone networks.

[0018] The communication network 108 can provide communication services, such as packet switching network services (e.g., Internet access, Voice over Internet Protocol (VoIP) communication services), to devices connected to the communication network 108. For example, the TCU 106 can access the communication network 108 via a connection to one or more cell towers. In another example, the TCU 106 can access the communication network 108 via a Wi-Fi connection.

[0019] The vehicle bus (not shown) may include various communication methods available between controllers 104 and between the TCU 106 and the vehicle controller 104. As some non-limiting examples, the vehicle bus may include one or more of a controller area network (CAN), an Ethernet network, and a media-oriented system transport (MOST) network.

[0020] Sensor 110 may include various hardware of vehicle 102 for collecting information about its surrounding environment and state. As some non-limiting examples, sensor 110 may include one or more of a camera (e.g., an advanced driver assistance system (ADAS) camera), an ultrasonic transceiver, a radio detection and ranging (radar) system, and / or a light detection and ranging (LiDAR) system.

[0021] The GNSS controller 112 can be configured to provide information indicating the current position of the vehicle 102. In this example, the GNSS controller 112 may be responsible for receiving signals from a GNSS constellation. This allows the GNSS controller 112 to receive time information and to determine the precise position of the vehicle 102. The position determined by the GNSS controller 112 can be used for various tasks, such as navigation or other location-based services.

[0022] HMI controller 114 can be configured to provide an interface through which vehicle occupants of vehicle 102 can interact with vehicle 102. The interface may include a touchscreen display, voice commands, and physical controls (such as buttons and knobs). HMI controller 114 can be configured to receive user input via various buttons or other controls, and to provide the driver with status information, such as fuel level information, engine operating temperature information, and the current location of vehicle 102. HMI controller 114 can be configured to provide information to various displays within vehicle 102 (such as a center console touchscreen, instrument cluster screen, etc.). HMI controller 114 may accordingly allow vehicle occupants of vehicle 102 to access and control various systems, such as navigation, entertainment, and climate control.

[0023] The charging controller 116 can be configured to manage battery charging, including monitoring charging status, managing power flow, and communicating with the power grid. The charging controller 116 can communicate with ports on the charging station 118 for connecting to the vehicle 102 using a cable or other means that allow charging from an external power source. The charging station 118 can be configured to direct and manage the energy transfer between the power source and the vehicle 102. The external power source can provide direct current (DC) or alternating current (AC) power to the charging station 118. The charging station 118 can then have a charging connector for insertion into a corresponding charging port on the vehicle 102. The charging port can be any type of port configured to transfer power from the charging station 118 to the vehicle 102. Alternatively, the charging station 118 can be configured to transfer power using other methods, such as wireless inductive coupling. However, the charging station 118 is connected to the charging controller 116 and may include circuitry and controls for directing and managing the energy transfer between the power source and the vehicle 102. The charging controller 116 of vehicle 102 can also be configured to transmit data between vehicle 102 and charging station 118.

[0024] Vehicle information 120 includes records indicating when vehicle 102 connects to charging station 118. This information can be collected from sensor 110, GNSS controller 112, and / or charging controller 116. Charging station 118 may be located at home or in a warehouse. Charging time can typically be overnight or at any time of day. When vehicle 102 is attached to charging station 118, charging station 118 can handle the charging of vehicle 102, which may take from tens of minutes to several hours. This charging time allows sufficient time for the installation and verification of software update 130.

[0025] In another example, vehicle information 120 includes information about the configuration or other characteristics of vehicle 102. For example, vehicle information 120 may indicate the software version of controller 104 installed on vehicle 102. In another example, vehicle information 120 may include the brand, model, and / or features installed on vehicle 102 during manufacturing and / or aftermarket. In yet another example, vehicle information 120 may indicate the VIN or other identifier of vehicle 102, which can be used to access vehicle information 120 regarding the configuration and / or charging history of vehicle 102.

[0026] Mobile device 122 can be any of various types of portable computing devices, such as cellular phones, tablet computers, smartwatches, laptop computers, portable music players, or other devices with processing and communication capabilities. Mobile device 122 may include one or more processors configured to execute computer instructions, and storage media thereon capable of holding computer-executable instructions and / or data. Mobile device 122 may be configured to connect to TCU 106 or other controller 104 of vehicle 102 to provide communication services to vehicle 102.

[0027] Charger monitoring server 126 may be an example of a networked computing device that vehicle 102, charging station 118, and / or other devices can access via communication network 108. Charger monitoring server 126 may be configured to perform charger service 128 to perform the operations of charger monitoring server 126 discussed herein. Vehicle 102 may transmit data from its sensors 110 to charger monitoring server 126 via communication network 108. Vehicle 102 may monitor its charging station 118 usage and may transmit vehicle information 120 to charger monitoring server 126 via communication network 108. In another example of an electric vehicle (EV), charger monitoring server 126 may be configured to receive vehicle information 120 from charging station 118 via communication network 108 (e.g., as part of a billing process for charging station 118 usage or as a separate process).

[0028] Charger monitoring server 126 can maintain information about vehicle 102. For example, charger monitoring server 126 can receive information from communication network 108 indicating the number of vehicles 102 in a geographic area. In another example, charger monitoring server 126 can receive vehicle information 120 from communication network 108 indicating the location of vehicle 102. For example, this information can be based on a raw location database of communication network 108, which maintains information indicating which cells are connected to which vehicles 102's TCU 106. In another example, vehicle 102 can report its location to charger monitoring server 126, for example, by identifying its location using vehicle 102's GNSS controller 104 and having TCU 106 send this information to charger monitoring server 126 via communication network 108.

[0029] Charger monitoring server 126 can define an update list 132 for vehicles 102 intended to receive software update 130. Update list 132 can include a list of vehicles 102 indicated as requiring a specific software update 130. Vehicles 102 can be indicated on update list 132 by any of various vehicle identifiers, such as VIN, Media Access Control (MAC) address, etc. Whether software update 130 is required can be based on factors such as the brand, model, year, location, characteristics, charger type, etc. of vehicle 102. In another example, update list 132 may additionally or alternatively include a list of charging stations 118 that require updates.

[0030] The charger monitoring server 126 can maintain software updates 130 for the vehicle 102 and charging station 118 in its storage device. Software updates 130 may include any of a variety of software updates 130 and / or configuration updates to be applied to the TCU 106 and / or other controllers 104 of the vehicle 102 and / or charging station 118. In some cases, software updates 130 may add additional features to the vehicle 102 and / or charging station 118. In other cases, software updates 130 may include bug fixes or other updates to enhance the operation of existing features of the vehicle 102 and / or charging station 118. In some examples, software updates 130 may be designed for use with a specific brand or model of vehicle 102 and / or charging station 118, and / or for a specific model and / or version of controller 104 (or multiple controllers 104) within the vehicle 102. In some cases, software update 130 may include severity or otherwise be associated with severity, such as whether the update should be installed immediately or whether the update can be installed over time in the background.

[0031] The charger monitoring server 126 can send update requests 124 to vehicles 102 and / or charging stations 118 on the update list 132. The update request 124 can indicate which software update 130 to install, and timing information about when to perform the installation of the software update 130.

[0032] If vehicle 102 is not connected to charging station 118, vehicle 102 can use TCU 106 to download software update 130. In another example, vehicle 102 can use one or more mobile devices 122 communicating with vehicle 102 to download software update 130. Vehicle 102 can connect to each mobile device 122, instruct them to download different segments of software update 130, and then aggregate the data from each device to form software update 130 for installation.

[0033] In many cases, software update 130 includes updates for vehicle 102 and corresponding updates for charging station 118. In this case, both vehicle 102 and charging station 118 need to install their respective parts of software update 130 to complete the software update 130. To facilitate installation when such coordinated interaction between the two is required, charging station 118 can receive and store the software update 130 for both vehicle 102 and charging station 118. In the example, charging station 118 can download the software update 130 for both vehicle 102 and charging station 118 via a local Wi-Fi connection available to charging station 118. This can be useful because charging station 118 can have a relatively more consistent connection with communication network 108 compared to the moving vehicle 102. If the package is corrupted, incomplete, or defective, charging station 118 can retry until the complete package (including several vehicle 102 module packages) for both charging station 118 and vehicle 102 is downloaded and verified.

[0034] Vehicle 102 can connect to charging station 118 at home or in a warehouse location. This connection can be made overnight, but other times are also possible. Because charging takes anywhere from tens of minutes to several hours, this provides ample time to install most software updates 130 and perform the necessary verifications.

[0035] In the example, predictive analytics and / or machine learning can be used to identify reliable parking times and durations to ensure vehicle 102 is plugged in. For example, vehicle 102 may have an 85% confidence interval for plugging in between 1:00 AM and 6:00 AM, but a 95%+ confidence interval between 3:00 AM and 3:30 AM. The duration for performing software update 130 can be determined through testing and compared to regular plugging times. If the predicted time matches the download and verification duration, that time is used as the target. Vehicle 102 can estimate the time required for downloading and installation based on factors such as the connection speed and data transfer rate on communication network 108. This information helps estimate the future update duration for similar vehicles 102. The estimated duration ensures sufficient time for updates before vehicle 102 is needed again. The time at the location can be inferred based on vehicle 102's usage history, state of charge, charging rate, and estimated charging duration.

[0036] In some examples, the planned duration can be configured to account for the time involved in testing and recovery of the software update 130 in case of problems. If the software cannot be reverted to a previous version or causes a defect that prevents further operation, deployment on the unupdated device is halted, and the product recovery process begins. System 100 can alert the operator to any outliers that the system cannot correct.

[0037] Software updates 130 to vehicle 102 and charging station 118 can follow a predetermined sequence. Depending on the software package, the sequence may involve downloading to charging station 118 first, followed by vehicle 102 modules, or vice versa. The sequence may be defined by the type of software. Vehicle 102 can download the software update 130 in segments and perform installation once all segments are obtained, even if vehicle 102 no longer maintains a connection to charging station 118. Charging station 118 can communicate with vehicle 102 to deploy the software update 130.

[0038] After the new software update 130 is installed on vehicle 102, the previous software version can be stored in the non-volatile memory of vehicle 102 for a period of time until the new software is successfully verified on a specific number of vehicles 102 with a certain success rate. The verification level can vary based on update changes and system importance. If the new version performs poorly, vehicle 102 can automatically revert to the previous version. If the update causes operational problems, vehicle 102 can also automatically revert to the previous version. In some cases, if the new software is defective, charging station 118 can download an existing version of the software from the vehicle 102 module for restoration. This transfer can occur via the charging cable between vehicle 102 and charging station 118, but in other examples it can be performed wirelessly. Charging station 118 can verify the installation of software update 130 to vehicle 102, and if verification fails, can retain the previous version of the software for restoration.

[0039] After successful update confirmation, operational verification and reporting can be performed. In the example, once software update 130 is installed, vehicle 102 and charging station 118 undergo a series of operating modes to verify normal functionality. These modes include normal operation (charging, discharging, stopping, starting, derating, etc.) and pre-programmed regression testing. In some examples, vehicle 102 and charging station 118 can report their status via an external sound exciter. In other examples, vehicle 102 and charging station 118 can transmit their status to each other via radio frequency (RF) communication and / or by using a charging cable connection.

[0040] Vehicle 102 can be identified and grouped to obtain statistically relevant samples from different market groups. These groups take into account climate change, thermal temperatures from previously recorded data, brand and series of vehicle 102, power level, and installation characteristics.

[0041] The charger monitoring server 126 can maintain test reports 134 regarding the progress of sending and executing software updates 130 to vehicles 102 on the update list 132. Similarly, the test report 134 from vehicle 102 can include information such as: the result of the software update 130 (e.g., complete delivery, partial delivery, interrupted delivery, checksum error, failure to deliver, etc.), the location of vehicle 102, whether vehicle 102 has been moved, whether vehicle 102 is on or off, the download speed to vehicle 102, and RF signal parameters such as those measured for vehicle 102.

[0042] The charger monitoring server 126 can also maintain test reports 134 regarding the progress of sending and executing software updates 130 to charging stations 118 on the update list 132. These reports can similarly indicate the update status on the charging station 118 side, which also involves the software update 130.

[0043] Each relevant group can run operating mode, diagnostics, and regression tests to report successes, failures, and anomalous operations. Thresholds can be pre-defined to understand whether the group's standard deviation exceeds acceptable limits or whether any defects have occurred. If any normal function fails, the result is reported and flagged. If the reporting is acceptable, the software rollout continues. If any defect exceeds the group's threshold metric, a software recovery process is initiated. This procedure can be performed simultaneously on hundreds to thousands of vehicles 102, accelerating the validation process. Therefore, by using updates to customer or fleet vehicles 102, vehicles 102 can be used as a test fleet.

[0044] Figure 2 An example process 200 for simultaneous installation of software update 130 on vehicle 102 and charging station 118 is shown. In the example, process 200 can be performed by vehicle 102, charging station 118 and charger monitoring server 126 communicating via communication network 108.

[0045] At operation 202, an update request 124 for installing software update 130 is received at charging station 118. This update request 124 may have already been received from charger monitoring server 126, as discussed further in detail with respect to process 300.

[0046] At operation 204, software update 130 is received by vehicle 102 and charging station 118. Installing software update 130 into vehicle 102 and charging station 118 can follow a predetermined sequence. Depending on the software package, the sequence may involve first downloading to charging station 118, then to controller 104 of vehicle 102, or vice versa.

[0047] In this example, charging station 118 can receive software updates 130 from both vehicle 102 and charging station 118 via communication network 108. Charging station 118 can store the software updates 130 in its local storage. When vehicle 102 is present, charging station 118 can transmit the software updates 130 of vehicle 102 via a local network connection with vehicle 102. This connection can be, for example, a wired connection via a data connection included in the charger cable connecting charging station 118 to vehicle 102. In another example, the data connection can be a wireless connection between charging station 118 and vehicle 102, such as a Wi-Fi connection. This approach can take advantage of the fact that charging station 118 is stationary and typically receives a stronger network signal than vehicle 102. Furthermore, this ensures that vehicle 102 and charging station 118 are operating using a corresponding pair of software updates 130.

[0048] In another example, vehicle 102 may use one or more mobile devices 122 to receive software update 130. In this example, vehicle 102 may establish a communication link with each mobile device 122, directing them to download different segments of software update 130, and then aggregating the segments from each mobile device 122 to compile software update 130 for vehicle 102. In this example, vehicle 102 may download software update 130 in segments even when the vehicle is no longer connected to charging station 118.

[0049] Vehicle 102 and / or charging station 118 can verify the signature of software update 130, such as an MD5 hash. If software update 130 is corrupt, incomplete, or defective, charging station 118 and / or vehicle 102 can retry until the complete package for both charging station 118 and vehicle 102 is downloaded and verified.

[0050] At operation 206, vehicle 102 and charging station 118 perform the installation of software update 130. The timing of the installation of software update 130 can be indicated in the update request 124 received at operation 202. For vehicle 102, the installation may include copying the current software of one or more controllers 104 being updated to a backup location, and installing software update 130 onto the one or more controllers 104 being updated. For charging station 118, this may also include copying the current software to a backup location, and installing software update 130 onto charging station 118.

[0051] In the example where charging station 118 provides software update 130 to vehicle 102, charging station 118 can communicate with vehicle 102 to deploy software update 130. If the new software has problems, charging station 118 can use its data connection with vehicle 102 to download the existing software for restoration before updating from vehicle controller 104. This transfer can occur via a charger cable, but can also be performed wirelessly.

[0052] In the example where vehicle 102 uses mobile device 122 to perform the download of software update 130, vehicle 102 can download software update 130 in segments, and once all segments are obtained, the installation can be performed, even if vehicle 102 no longer remains connected to charging station 118.

[0053] In any case, after the software update 130 is installed on vehicle 102, charging station 118 can retain the previous software version until the new software is successfully verified on a limited number of vehicles 102 with a limited success rate.

[0054] At operation 208, vehicle 102 and charging station 118 determine whether the software update 130 has been successfully installed. For example, this may include vehicle 102 confirming that software update 130 can be installed on vehicle 102. The charging station 118 may also redundantly verify the software installation on vehicle 102, and if verification fails, may retain the previous software for restoration. This may also include confirming that the charging station 118 has been updated and is able to store backups.

[0055] If software update 130 is installed, control proceeds to operation 210 to test the functionality of the updated software.

[0056] At operation 210, after software update 130 is installed on vehicle 102 and charging station 118, vehicle 102 and charging station 118 perform verification tests on the updated software. Verification may include vehicle 102 and charging station 118 undergoing a series of operating modes to verify normal function. Vehicle 102 and charging station 118 can report their status via charging cable, wirelessly, and / or via an external sound exciter. These modes include normal operation (charging, discharging, stopping, starting, derating, etc.) and pre-programmed regression tests. This verification can be performed simultaneously on hundreds to thousands of vehicles 102, which accelerates the verification process.

[0057] At operation 212, charging station 118 determines whether the verification was successful. For example, if the new version performs poorly in the verification test, vehicle 102 can automatically revert to the previous version. In another example, if the update causes operational problems, vehicle 102 can also automatically revert to the previous version. If verification fails, control proceeds to operation 214 to roll back the update. Similarly, if installation fails at operation 208, control proceeds to operation 214 to roll back the update.

[0058] At operation 214, the installation of software update 130 is rolled back for vehicle 102 and / or charging station 118. In this example, a backup version of the software can be reloaded to controller 104 of vehicle 102 and / or charging station 118.

[0059] At operation 216, following operations 212 or 214, test report 134 is compiled. Test report 134 can indicate the installation result to vehicle 102 and charging station 118. Additionally, if the installation is successful, test report 134 can indicate the verification result. Test report 134 may also include additional information, such as the VIN or other identifiers of vehicle 102 being updated.

[0060] At operation 218, test report 134 is sent to charger monitoring server 126. In one example, charging station 118 may collect test report 134 from vehicle 102 and send it to charger monitoring server 126 via communication network 108. In another example, charging station 118 may additionally send its test report 134 regarding the installation of software update 130 to charging station 118 to charger monitoring server 126. In yet another example, charging station 118 may collect test reports 134 from multiple vehicles 102 and send a collection of test reports 134 to charger monitoring server 126. In other examples, vehicle 102 may send its test report 134 to charger monitoring server 126 individually. After operation 218, process 200 ends.

[0061] Figure 3 An example process 300 of a test method for a charger monitoring server 126 to implement an OTA software update 130 is shown. In this example, as with process 200, process 300 can be performed by a vehicle 102, a charging station 118, and a charger monitoring server 126 communicating via a communication network 108.

[0062] At operation 302, the charger monitoring server 126 maintains vehicle information 120. This vehicle information 120 may include records indicating when the vehicle 102 previously connected to which charging station 118. In another example, vehicle information 120 includes parameters regarding the configuration or other characteristics of the vehicle 102. This information may be received from various sources, such as from the vehicle 102 manufacturer, from the vehicle 102 in response to being charged, or from the charging station 118 that provides its charging history to the charger monitoring server 126.

[0063] At operation 304, charger monitoring server 126 identifies vehicle 102 to receive software update 130. In this example, charger monitoring server 126 may identify an update list 132 for vehicle 102 to receive software update 130. Update list 132 may include a list of vehicles 102 indicated as requiring a specific software update 130. Vehicle 102 may be indicated on update list 132 by any of a variety of vehicle identifiers (such as VIN, MAC address, etc.). Whether a software update 130 is required may be based on factors such as the brand, model, year, location, characteristics, charger type, etc. of vehicle 102. In another example, update list 132 may additionally or alternatively include a list of charging stations 118 that require updates.

[0064] At operation 306, charger monitoring server 126 determines the update timing for each of the vehicles 102 on update list 132 to perform an update, test, and / or recovery cycle of software update 130. In this example, charger monitoring server 126 employs predictive analytics and / or machine learning to identify reliable parking times and durations to ensure vehicle 102 is plugged in. For example, charger monitoring server 126 may have an 85% confidence interval for plugged-in vehicle 102 between 1:00 AM and 6:00 AM, but a 95%+ confidence interval between 3:00 AM and 3:30 AM.

[0065] Charger monitoring server 126 can determine the duration of software update 130 through testing and compare it to regular plug-in time. If the predicted time matches the download and verification duration, charger monitoring server 126 can target that time. Charger monitoring server 126 can estimate the time required for download and installation based on connection speed and data transfer rate. This information helps charger monitoring server 126 estimate the future update duration for similar vehicles 102. The estimated duration ensures sufficient time to download and install (and optionally revert) software update 130 before vehicle 102 is needed again. Charger monitoring server 126 can base the time at said location on factors including vehicle usage history, state of charge, charging rate, and estimated charging duration.

[0066] For example, charger monitoring server 126 can determine that 3:30 AM to 3:30 AM is a better time to perform software update 130 based on the increased likelihood of vehicle 102 being present at that time. In another example, if software update 130 and verification require additional time, charger monitoring server 126 can determine that 1:00 AM to 6:00 AM is a better time to perform software update 130.

[0067] At operation 308, the charger monitoring server 126 invokes the test loop for vehicle 102 on update list 132. To do this, the charger monitoring server 126 may send update request 124 to vehicle 102 and / or charging station 118. This may trigger vehicle 102 and charging station 118 to perform the operations of process 200 discussed in detail above.

[0068] At operation 310, charger monitoring server 126 collects test reports 134. These may include test reports 134 updated according to process 200, sent from vehicle 102 and charging station 118 at operation 218.

[0069] At operation 312, the charger monitoring server 126 determines whether the test cycle was successful. In this example, the charger monitoring server 126 may compare the results of test report 134 with a threshold pass rate to ensure that at least a minimum number of vehicles 102 and / or charging stations 118 successfully applied software update 130. If so, control proceeds to operation 314.

[0070] At operation 314, charger monitoring server 126 determines whether the test is complete. For example, charger monitoring server 126 can be configured to run a set of test loops for software update 130 with different parameters, such as the brand, model, configuration, location, and / or characteristics installed on vehicle 102. These loops can be run iteratively to ensure that one or more loops are successful before running additional loops. For example, a small loop for vehicles 102 with a given set of parameters can receive and test software update 130 (e.g., to build confidence), and then apply software update 130 to a larger set of vehicles 102 with those parameters. In another example, loops can be constructed that first build confidence with a first set of parameters and then attempt to update software update 130 on vehicles 102 with a different set of parameters. If the pass rate of the update is higher than a termination threshold, charger monitoring server 126 can continue updating with additional loops. If not, charger monitoring server 126 can choose to stop the test. If the test passes but is not complete, process 300 returns to operation 304 to continue updating with additional update list 132. If the test is completed or the pass rate of the update is lower than the abort threshold, control proceeds to operation 316.

[0071] At operation 316, the charger monitoring server 126 determines whether to maintain the software update 130 on vehicle 102 and / or charging station 118. For example, if the update pass rate is higher than the abort threshold and the software update 130 is intended for production use, the software update 130 can be allowed to remain installed and process 300 ends.

[0072] However, if the pass rate is low, the charger monitoring server 126 may choose not to maintain the installation of software update 130 and may instruct vehicle 102 and / or charging station 118 to restore to backup software. If so, control is transferred to operation 318 so that the charger monitoring server 126 instructs vehicle 102 and / or charging station 118 to restore to backup software. In another example, even if software update 130 passes, if software update 130 was installed experimentally (e.g., to test new features but not to be retained), the charger monitoring server 126 may still transfer to operation 318 to restore the software.

[0073] At operation 318, the charger monitoring server 126 sends an update request 124 to vehicle 102 and / or charging station 118 to restore to backup software. In some examples, update request 124 is sent to vehicle 102 and also to charging station 118. In another example, update request 124 is sent to charging station 118, which then instructs vehicle 102 to restore software update 130 when connected to charging station 118. For example, this restoration can be performed using backup software stored at charging station 118 during the application of software update 130 to vehicle 102. After operation 318, process 300 ends.

[0074] Figure 4 An example computing device 402 is shown for an iterative testing method of implementing software update 130 using a consumer vehicle 102. (Reference) Figure 4 And refer to Figure 1 Vehicle 102, controller 104, TCU 106, communication network 108, controller 110, GNSS controller 112, HMI controller 114, charging controller 116, charging station 118, mobile device 122, and charger monitoring server 126 are examples of such computing devices 402. Computing devices 402 typically include computer-executable instructions, such as those for charger service 128 and software update 130, which may be executable by one or more computing devices 402. Computer-executable instructions can be compiled or interpreted from computer programs created using various programming languages ​​and / or technologies, individually or in combination, including but not limited to Java™, C, C++, C#, Visual Basic, JavaScript, Python, Perl, etc. Generally, a processor (e.g., a microprocessor) receives instructions, for example, from memory, a computer-readable medium, etc., and executes these instructions to perform one or more processes, including one or more of the processes described herein. Such instructions and other data (such as vehicle information 120) can be stored and transmitted using a variety of computer-readable media.

[0075] As shown in the figure, computing device 402 may include processor 404, which is operatively connected to storage device 406, network device 408, output device 410, and input device 412. It should be noted that this is merely an example, and computing device 402 with more, fewer, or different components may be used.

[0076] Processor 404 may include one or more integrated circuits that implement the functionality of a central processing unit (CPU) and / or a graphics processing unit (GPU). In some examples, processor 404 is a system-on-a-chip (SoC) that integrates the functionality of a CPU and a GPU. The SoC may optionally include other components, such as storage device 406 and networking device 408, into a single integrated device. In other examples, the CPU and GPU are connected to each other via peripheral connectivity devices, such as Peripheral Component Interconnect (PCI) or another suitable peripheral data connection. In one example, the CPU is a commercially available central processing unit that implements an instruction set, such as x86, ARM, Power, or a non-interlocked pipelined microprocessor (MIPS) instruction set family.

[0077] Regardless of the details, during operation, processor 404 executes stored program instructions retrieved from storage device 406. The stored program instructions accordingly include software that controls the operation of processor 404 to perform the operations described herein. Storage device 406 may include both non-volatile memory and volatile memory devices. Non-volatile memory includes solid-state memory, such as NAND flash memory, magnetic and optical storage media, or any other suitable data storage device that retains data when the system is disabled or loses power. Volatile memory includes static and dynamic random access memory (RAM) that stores program instructions and data during operation of system 100.

[0078] The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics to the output device 410. The output device 410 may include a graphics or visual display device, such as an electronic display screen, a display unit, a printer, or any other suitable device for reproducing a graphical display. As another example, the output device 410 may include an audio device, such as a speaker or headphones. As yet another example, the output device 410 may include a tactile device, such as a mechanically elevable device, which in this example may be configured to display Braille or another physical output that can be touched to provide information to a user.

[0079] Input device 412 may include any of a variety of devices that enable computing device 402 to receive control input from a user. Examples of suitable input devices 412 for receiving human-machine interface input may include a keyboard, mouse, trackball, touchscreen, microphone, graphics tablet, etc.

[0080] Network device 408 may each include any of a variety of means that enable the described components to send and / or receive data from external devices via a network. Examples of suitable network devices 408 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a Bluetooth or BLE transceiver, or other network adapters or peripheral interconnects that may be useful for receiving large amounts of data in an efficient manner.

[0081] Regarding the processes, systems, methods, heuristics, etc., described herein, it should be understood that although the steps of such processes, etc., are described as occurring in a certain ordered order, such processes can be practiced by performing the described steps in a different order than that described herein. It should also be understood that some steps may be performed simultaneously, other steps may be added, or some steps described herein may be omitted. In other words, the description of processes herein is provided for the purpose of illustrating specific embodiments and should in no way be construed as limiting the claims.

[0082] Therefore, it should be understood that the above description is intended to be illustrative rather than restrictive. Many embodiments and applications beyond the examples provided will become apparent upon reading the above description. The scope should not be determined by reference to the above description, but rather by reference to the appended claims and the full scope of their equivalents. It is anticipated and expected that the techniques discussed herein will evolve in the future, and the disclosed systems and methods will be incorporated into such future embodiments. In conclusion, it should be understood that modifications and variations are possible with this application.

[0083] All terms used in the claims are intended to give their broadest reasonable structure and their general meaning as would be understood by one of skill in the art described herein, unless explicitly indicated otherwise herein. Specifically, unless the claims explicitly limit the recitation to the contrary, the use of singular articles such as “a,” “the,” or “the” should be interpreted as referring to one or more of the elements indicated by the recitation.

[0084] An abstract of this disclosure is provided to allow the reader to quickly determine the nature of this technical disclosure. It should be understood that the abstract is not intended to interpret or limit the scope or meaning of the claims. Furthermore, as can be seen in the foregoing detailed description, various features are grouped together in various embodiments for the purpose of making the disclosure fluent. This approach of the disclosure should not be construed as reflecting an intention to require more features than expressly stated in each claim. Rather, as reflected in the appended claims, the inventive subject matter lies in fewer than all features of a single disclosed embodiment. Therefore, the appended claims are hereby incorporated into the detailed description, wherein each claim is itself a separately claimed subject matter.

[0085] Although exemplary embodiments have been described above, these embodiments are not intended to describe all possible forms of this disclosure. Rather, the terminology used herein is descriptive rather than restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. Furthermore, features of various embodiments may be combined to form other embodiments of this disclosure.

[0086] According to the present invention, a method for iterative software updates using a consumer vehicle includes: sending an update request to install a software update to a vehicle and a charging station in a test cycle, wherein the vehicle is included on an update list; receiving a test report from the vehicle and the charging station; continuing to roll out the software update in an additional test cycle in response to the test report indicating success above a minimum success threshold; and otherwise sending a recovery update request to the vehicle and the charging station to roll back the software update.

[0087] In one aspect of the invention, the method includes: sending a vehicle software update and a corresponding charging station software update to one of the charging stations, the vehicle software update to be installed in one of the vehicles, and the corresponding charging station software update to be installed in one of the charging stations; receiving from the one of the charging stations a vehicle test report indicating the result of installing the vehicle software update in the one of the vehicles, and a charging station test report indicating the result of installing the charging station software update in the one of the charging stations.

[0088] In one aspect of the invention, the result of the installation includes an indication of whether the installation of the software update was successful, and if the installation is successful, it includes an indication of whether the verification of the functionality of the software update was successful.

[0089] In one aspect of the invention, the method includes storing a backup of the vehicle software of the vehicle before applying the software update to the storage device of the vehicle in the charging station.

[0090] In one aspect of the invention, the method includes rolling back the software update by sending a backup of the vehicle software from a storage device of one of the charging stations to one of the vehicles for reinstallation in the other vehicle.

[0091] In one aspect of the invention, the software update is tested but not retained, and also includes restoring to the backup of the vehicle software regardless of the test report.

[0092] In one aspect of the invention, the method includes: identifying the parking time and duration during which the vehicle may be connected to the charging station; and indicating a timing for installing the software update in the update request.

[0093] In one aspect of the invention, the method includes: including a first group of vehicles having a given set of parameters on the update list to test the software update before applying it to a larger group of vehicles having the given set of parameters; and including the larger group of vehicles having the given set of parameters on a second update list for the additional test cycle.

[0094] In one aspect of the invention, the method includes: including a first group of vehicles having a given set of parameters on the update list to test the software update before applying it to vehicles having a different set of parameters; and including a second group of vehicles having the different set of parameters on a second update list for the additional test cycle.

[0095] According to the present invention, a system for iterative software updates using consumer vehicles is provided, comprising: a storage device maintaining vehicle information including records indicating when the vehicle previously connected to which charging station and parameters regarding the vehicle's configuration and / or characteristics; and a charger monitoring server configured to: identify an update list of vehicles to receive software updates; send update requests to apply software updates to vehicles on the update list; receive test reports from the vehicles and the charging stations; continue rolling out the software update in an additional test cycle in response to the test reports indicating success above a minimum success threshold; and otherwise send a recovery update request to the vehicles and the charging stations to roll back the software update.

[0096] According to an embodiment, the charger monitoring server is further configured to: send a vehicle software update and a corresponding charging station software update to one of the charging stations, wherein the vehicle software update is to be installed in one of the vehicles and the corresponding charging station software update is to be installed in one of the charging stations; and receive from the charging station a vehicle test report indicating the result of installing the vehicle software update in the vehicle, and a charging station test report indicating the result of installing the charging station software update in the charging station.

[0097] According to an embodiment, the result of the installation includes an indication of whether the software update was installed successfully, and if the installation is successful, it includes an indication of whether the functionality verification of the software update was successful.

[0098] According to an embodiment, the charger monitoring server is also configured to store a backup of the vehicle software of the vehicle before applying the software update to the storage device of the vehicle in the charging station.

[0099] According to an embodiment, the charger monitoring server is also configured to roll back the software update by sending the backup of the vehicle software from the storage device of one of the charging stations to the one of the vehicles for reinstallation in the one of the vehicles.

[0100] According to an embodiment, the software update will be tested but not retained, and the charger monitoring server is also configured to restore to the backup of the vehicle software regardless of the test report.

[0101] According to an embodiment, the charger monitoring server is further configured to: identify the parking time and duration during which the vehicle may connect to the charging station; and indicate the timing for installing the software update in the update request.

[0102] According to an embodiment, the charger monitoring server is further configured to: include a first group of vehicles with a given set of parameters on the update list to test the software update before applying it to a larger group of vehicles with the given set of parameters; and include the larger group of vehicles with the given set of parameters on a second update list for the additional test cycle.

[0103] According to an embodiment, the charger monitoring server is further configured to: include a first group of vehicles with a given set of parameters on the update list to test the software update before applying it to vehicles with a different set of parameters; and include a second group of vehicles with the different set of parameters on a second update list for the additional test cycle.

[0104] According to the present invention, a non-transitory computer-readable medium is provided having instructions for iterative software updates using a consumer vehicle, the instructions, when executed by a charger monitoring server, causing the charger monitoring server to perform operations including: maintaining vehicle information, the vehicle information including records indicating when the vehicle previously connected to which charging station and parameters regarding the vehicle's configuration and / or characteristics; identifying a list of vehicles for receiving software updates; sending an update request to apply the software update to the vehicles on the update list; receiving test reports from the vehicles and the charging stations; continuing to roll out the software update in an additional test cycle in response to the test report indicating success above a minimum success threshold; and otherwise sending a recovery update request to the vehicles and the charging stations to roll back the software update.

[0105] According to an embodiment, the present invention is further characterized by instructions, which, when executed by the charger monitoring server, cause the charger monitoring server to perform operations, including: sending a vehicle software update and a corresponding charging station software update to one of the charging stations, wherein the vehicle software update is to be installed in one of the vehicles, and the corresponding charging station software update...

[0106] The update is to be installed in one of the charging stations; and from the charging station...

[0107] One of them receives an instruction to install the vehicle software update on the other of the vehicles.

[0108] The resulting vehicle test report, and instructions to install the [unclear] in one of the charging stations.

[0109] A charging station test report showing the results of the charging station software update.

Claims

1. A method for iterative software updates using consumer vehicles, comprising: sending an update request to install a software update to vehicles and charging stations in a test cycle, wherein the vehicles are included on an update list; receiving test reports from the vehicles and the charging stations; in response to the test reports indicating success above a minimum success threshold, continuing rollout of the software update in additional test cycles; and otherwise sending a restore update request to the vehicles and the charging stations to roll back the software update.

2. The method of claim 1, further comprising: sending a vehicle software update to be installed into one of the vehicles and a corresponding charging station software update to be installed into one of the charging stations to the one of the charging stations; receiving a vehicle test report from the one of the charging stations indicating results of installing the vehicle software update into the one of the vehicles, and a charging station test report indicating results of installing the charging station software update into the one of the charging stations.

3. The method of claim 2, wherein the results of the installation include an indication of whether installation of the software update was successful, and if the installation was successful, an indication of whether verification of functionality of the software update was successful.

4. The method of claim 2, further comprising storing a backup of vehicle software of the one of the vehicles before applying the software update to a storage device of the one of the charging stations.

5. The method of claim 4, further comprising rolling back the software update by sending the backup of the vehicle software from the storage device of the one of the charging stations to the one of the vehicles for reinstallation into the one of the vehicles.

6. The method of claim 4, wherein the software update is to be tested but not retained, and further comprising reverting to the backup of the vehicle software regardless of the test reports.

7. The method of claim 1, further comprising: identifying a parking time and duration that the vehicles are likely to be connected to the charging stations; and indicating a timing of installing the software update in the update request.

8. The method of claim 1, further comprising: including a first set of vehicles having a given set of parameters on the update list to test the software update before applying the software update to a larger set of vehicles having the given set of parameters; and including the larger set of vehicles having the given set of parameters on a second update list for the additional test cycles.

9. The method of claim 1, further comprising: including a first set of vehicles having a given set of parameters on the update list to test the software update before applying the software update to vehicles having a different set of parameters; and including a second set of vehicles having the different set of parameters on a second update list for the additional test cycles. ​ 10. A system for iterative software updates using consumer vehicles, comprising: a storage device maintaining vehicle information including records indicating when a vehicle connected to which charging station in the past and parameters about the configuration and / or characteristics of the vehicle; and a charger monitoring server configured to: identify a list of vehicles for an update to receive a software update, send an update request to apply the software update to the vehicles on the list of updates, receive test reports from the vehicles and the charging stations, in response to the test reports indicating success above a minimum success threshold, continue rollout of the software update in additional test cycles, and otherwise send a recovery update request to the vehicles and the charging stations to roll back the software update.

11. The system of claim 10, wherein the charger monitoring server is further configured to: send, to one of the charging stations, a vehicle software update to be installed into one of the vehicles and a corresponding charging station software update to be installed into the one of the charging stations; and receive, from the one of the charging stations, a vehicle test report indicating results of installing the vehicle software update into the one of the vehicles and a charging station test report indicating results of installing the charging station software update into the one of the charging stations.

12. The system of claim 11, wherein the results of the installation include an indication of whether installation of the software update was successful and, if the installation was successful, an indication of whether verification of functionality of the software update was successful.

13. The system of claim 11, wherein the charger monitoring server is further configured to one or more of: store a backup of vehicle software of the one of the vehicles prior to applying the software update to a storage device of the one of the charging stations; roll back the software update by sending the backup of the vehicle software from the storage device of the one of the charging stations to the one of the vehicles to reinstall into the one of the vehicles; and where the software update is to be tested but not retained, revert to the backup of the vehicle software regardless of the test reports.

14. The system of claim 10, wherein the charger monitoring server is further configured to: identify a time and duration of parking that the vehicles are likely to connect to the charging stations; and indicate a timing of installing the software update in the update request.

15. The system of claim 10, wherein the charger monitoring server is further configured to one or more of: include a first set of vehicles with a given set of parameters on the list of updates to test the software update before applying the software update to a larger set of vehicles with the given set of parameters, and include the larger set of vehicles with the given set of parameters on a second list of updates for the additional test cycles; or include a first set of vehicles with a given set of parameters on the list of updates to test the software update before applying the software update to a larger set of vehicles with the given set of parameters, and include the larger set of vehicles with the given set of parameters on a second list of updates for the additional test cycles; or including a first set of vehicles having a given set of parameters on the update list to test the software update before applying the software update to vehicles having a different set of parameters, and including a second set of vehicles having the different set of parameters on a second update list for an additional test cycle.

Images