CHARGER-BASED VALIDATION OF VEHICLE SOFTWARE UPDATES

Abstract

Iterative software update using consumer vehicles involves sending update requests to perform software updates on vehicles and charging stations in a test cycle, with the vehicles included in an update list; receiving test reports from the vehicles and charging stations; in response to the test reports indicating success above a minimum success threshold, continuing the rollout of the software update in an additional test cycle; and otherwise sending reset update requests to reset the software update to the vehicles and charging stations.

Description

FIELD OF TECHNOLOGYAspects of the disclosure generally relate to charger-based validation of vehicle software update.GENERAL STATE OF THE ARTFor vehicle software downloads over the air (OTA), cellular data or local Wi-Fi may be used, typically at home. Charging stations at home have the repeated possibility of connecting to home networks. Charging stations are typically connected to vehicles via a wired charging coupler, similar to local area network (LAN) lines for computers. Charging stations may also connect wirelessly via Bluetooth Low Energy (BLE), Wi-Fi, etc.SUMMARYIn one or more illustrative examples, a method for iterative software update using consumer vehicles includes sending update requests to perform software updates to vehicles and charging stations in a test cycle, the vehicles included in an update list; receiving test reports from the vehicles and charging stations; in response to the test reports indicating success above a minimum success threshold, continuing to introduce the software update in an additional test cycle; and otherwise sending reset update requests to reset the software update to the vehicles and charging stations.In one or more illustrative examples, an iterative software update system using consumer vehicles includes a memory that maintains vehicle information, the vehicle information including records indicating to which of the charging stations vehicles are currently connected and parameters related to configuration and / or characteristics of the vehicles; A charger monitoring server configured to identify an update list of vehicles to receive a software update, send update requests to apply the software update to the vehicles of the update list, receive test reports from the vehicles and the charging stations, responsive to the test reports indicating success above a minimum success threshold, continue introduction of the software update in an additional test cycle, and otherwise send a reset update request to reset the software update to the vehicles and the charging stations.In one or more illustrative examples, a non-transitory computer readable medium includes instructions for iterative software update using consumer vehicles that, when executed by a charger monitoring server, cause the charger monitoring server to perform operations that include vehicle information, the vehicle information including records indicating to which charging stations vehicles are currently connected and parameters related to configuration and / or features of the vehicles; identifying an update list of vehicles to receive a software update, sending update requests to apply the software update to the vehicles of the update list, receiving test reports from the vehicles and charging stations, responsive to the test reports indicating success above a minimum success threshold, continuing to introduce the software update in an additional test cycle, and otherwise sending a reset update request to reset the software update at the vehicles and charging stations.BRIEF DESCRIPTION OF THE DRAWINGSFIG. 1 illustrates an example system implementing an iterative test approach for updating software using consumer vehicles; FIG. 2 illustrates an example process for performing a simultaneous installation of a software update to the vehicle and the charging station; FIG. 3 illustrates an example process for the charger monitoring server implementing a test approach for OTA software updates; and FIG. 4 illustrates an example computing device for implementing an iterative test approach for software updates using consumer vehicles.DETAILED DESCRIPTIONAs required, detailed embodiments of the present invention are disclosed herein; however, it is to be understood that the disclosed embodiments are merely exemplary of the invention that may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be greatly exaggerated or minimized to show details of specific components. Therefore, specific structural and functional details disclosed herein are not to be interpreted as limiting, but merely as a representative basis for teaching one skilled in the art to variously employ the present invention.New vehicle charging software is validated by tests on a test fleet of vehicles and charging devices. This approach is limited by the available chargers and test vehicles, typically less than a dozen, and does not cover all variations on the market that may lead to defects. As software and charging capabilities progress, such as bi-directional power from the vehicle battery to the house, verifying proper function and an appropriate download time becomes more dependent. Often, both the vehicle and the charging station require simultaneous software update for proper operation.An improved approach to vehicle software validation and introduction may implement a test approach in which software updates are introduced in an iterative approach to customer vehicles. In the approach, a server identified vehicles to obtain statistically relevant samples from different market populations. These groups take into account variations in climate, thermal temperatures from previous recordings, brands and series of vehicles, power levels and installation properties.The server sends the software updates to be installed on the vehicles and the charging stations in one cycle of testing. Then, the software updates may be installed and tested, and test reports including results of the installation and tests may be logged back to the server. In response to the test reports indicating success above a minimum success threshold, the server continues to introduce the software update in an additional test cycle. If not, the server sends reset update requests to reset the software update to the vehicles and the charging stations. Other aspects of the disclosure are discussed in detail herein.FIG. 1 illustrates an example system 100 implementing an iterative test approach for updating software using consumer vehicles 102. The system 100 includes a vehicle 102 having various controllers 104. These controllers 104 include a telematics control unit (TCU) 106 to enable the vehicle 102 to communicate with remote devices over 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 communication with various charging stations 118. The system 100 also includes a charger monitoring server 126 configured to communicate with the vehicles 102 and the charging stations 118 via the communication network 108. The charger monitoring server 126 may execute a charger service 128 configured to send update requests 124 to the vehicles 102 and the charging stations 118 for installation of software updates 130. The charger monitoring server 126 may also be configured to receive test reports 134 from the vehicles 102 and the charging stations 118 based on the software updates 130. Using the test reports 134, the charger monitor server 126 may determine whether the software updates 130 cause problems and may perform various actions, such as resetting the software updates 130, introducing the software updates 130 for additional vehicles 102, etc. Note that the system 100 is only an example implementation and more, fewer, and / or other elements of the system 100 may be used.The vehicle 102 may include various types of automobiles, crossover utility vehicle (CUV), sport utility vehicle (SUV), trucks, recreational vehicles (RV), boats, airplanes, or other mobile machines for transporting people or goods. In many cases, the vehicle 102 may be a battery electric vehicle (BEV) powered by a traction battery and one or more electric motors. As another possibility, the 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 vehicles 102 may take various forms, such as a series hybrid electric vehicle, a parallel hybrid electric vehicle, or a parallel / series hybrid electric vehicle. Accordingly, as the type and configuration of the vehicle 102 may vary, the capabilities of the vehicle 102 may also vary. As some other possibilities, the vehicles 102 may have different capabilities with respect to occupant capacity, towability and capacity, and stowage. For registration purposes, inventory purposes, and other purposes, vehicles 102 may be associated with unique identifiers, such as vehicle identification numbers (VIN), e.g., as defined by International Organization for Standardization (ISO) 3779 and ISO 4030, globally unique identifiers (GUIDs), customers, or fleet accounts, etc.The vehicle 102 may include a plurality of controllers 104 configured to perform and manage various functions of the vehicle 102 using the power of the vehicle's battery and / or powertrain. As some non-limiting examples of vehicle controllers 104: a powertrain controller 104 may be configured to provide control of engine operating components (e.g., idle control components, fuel delivery components, emission control components, etc.) and for monitoring the status of such engine operating components (e.g., 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 verification of the status of access points (e.g., closure status of the hood, doors, and / or trunk of the vehicle 102); a radio transceiver controller 104 may be configured to communicate with radio keys, mobile devices 122, or other local devices of the vehicle 102; An autonomous controller 104 may be configured to provide commands for controlling the powertrain, steering, or other aspects of the vehicle 102; a climate control management controller 104 may be configured to provide control for heating and cooling system components (e.g., compressor clutch, blower fan, temperature sensors, etc.); a global navigation satellite system GNSS controller 104 may be configured to provide location information of the vehicle 102; and an HMI controller 104 may be configured to receive user inputs via various buttons or other controllers as well as provide status information of the vehicle 102 to a driver, such as fuel level information, engine operating temperature information, and the current location of the vehicle 102. The vehicle 102 may also be configured to power other devices external to the vehicle 102 using the vehicle 102 battery and / or powertrain.The TCU 106 is a controller 104 of the vehicle 102 that may be used for communication over the communication network 108. In an example, the TCU 106 may be configured to provide telematics services to the vehicle 102. These services may include, as some non-limiting possibilities, navigation, turn-by-turn directions, vehicle 102 status messages, local enterprise search, accident reporting, and hands-free calling. The TCU 106 may include network hardware configured to facilitate communication between the vehicle 102 and other devices of the system 100. For example, the TCU 106 may include or otherwise access a cellular modem configured to enable communication with the communication network 108. The communication network 108 may include one or more interconnected communication networks, such as, by way of some non-limiting examples, the Internet, a cable television distribution network, a satellite connection network, a local area network, and a telephone network.The communication network 108 may provide communication services to devices connected to the communication network 108, such as packet switched network services (e.g., Internet access, voice over Internet Protocol (VoIP) communication services). For example, the TCU 106 may access the communication network 108 via a connection to one or more cell towers. In another example, the TCU 106 may access the communication network 108 via a Wi-Fi connection.A vehicle bus (not shown) may include various communication methods available between the controllers 104, as well as between the TCU 106 and the vehicle controllers 104. As some non-limiting examples, a vehicle bus may include one or more of a controller area network (CAN), an Ethernet network, or a media-oriented system transfer (MOST) network.The sensors 110 may include various hardware of the vehicle 102 used to collect information about its environment and status. In some non-limiting examples, the sensors 110 may include one or more of cameras (e.g., advanced driver-assistance system (ADAS) cameras), ultrasonic transceivers, radio detection and ranging (RADAR) systems, and / or light detection and ranging (LIDAR) systems.The GNSS controller 112 may be configured to provide information indicating the current location of the vehicle 102. In one example, the GNSS controller 112 may be responsible for receiving signals from a GNSS constellation of satellites. This may allow the GNSS controller 112 to receive time information as well as determine an accurate location of the vehicle 102. The location determined by the GNSS controller 112 may be used for various tasks, such as navigation or other location-based services.The HMI controller 114 may be configured to provide an interface through which occupants of the vehicle 102 may interact with the vehicle 102. The interface may include a touch screen display, voice commands, and physical controls such as buttons and buttons. The HMI controller 114 may be configured to receive user input via various buttons or other controls, as well as provide status information to a driver, such as fuel level information, engine operating temperature information, and a current location of the vehicle 102. The HMI controller 114 may be configured to provide information to various displays within the vehicle 102, such as a center console touch screen, a cluster screen, etc. The HMI controller 114 may accordingly enable the occupants of the vehicle 102 to access and control various systems such as navigation, entertainment, and climate control.The charge controller 116 may be configured to manage charging of the battery, including monitoring the state of charge, managing the flow of electricity, and communicating with the power grid. The charging controller 116 may be in communication with a port for connection to a charging station 118 using a cable or other device that enables the vehicle 102 to be charged from an external power source. The charging stations 118 may be configured to direct and manage the transfer of energy between a power source and the vehicle 102. An external power source may provide direct current (DC) or alternating current (AC) electrical power to the charging stations 118. The charging stations 118 may in turn have a charging plug for insertion into a respective charging connection of the vehicle 102. The charging port may be any type of port configured to transmit power from the charging stations 118 to the vehicle 102. Alternatively, the charging stations 118 may be configured to transmit power using other approaches, such as wireless inductive coupling. Whatever the charging stations 118 are connected to the charging controller 116, the charging stations 118 may include circuitry and controllers to direct and manage the transfer of energy between the power source and the vehicle 102. The charge controller 116 of the vehicle 102 may also be configured to communicate data between the vehicle 102 and the charging station 118.The vehicle information 120 includes records indicating when the vehicle 102 is connected to the charging station 118. This information may be retrieved from the sensors 110, the GNSS controller 112, and / or the charge controller 116. The charging station 118 may be home or depot locations. The time of charging may typically be overnight, but may be at any time of day. The charging station 118 may handle charging of the vehicle 102 when the vehicle 102 is mounted to the charging station 118, which takes dozen minutes to hours. This load time may provide sufficient time for the software updates 130 to be installed and the software updates 130 to be validated.In another example, the vehicle information 120 includes information related to the configuration or other features of the vehicle 102. For example, the vehicle information 120 may indicate the software versions installed on the controllers 104 of the vehicle 102. In another example, the vehicle information 120 may include the make, model, and / or features installed on the vehicle 102 during manufacture and / or mining. In yet another example, the vehicle information 120 may indicate a VIN or other identifier of the vehicle 102, which may be used to access the vehicle information 120 related to the configuration and / or charging history of the vehicle 102.The mobile devices 122 may be any of various types of portable computing device, such as cellular phones, tablet computers, smart watches, laptop computers, portable music players, or other devices having processing and communication capabilities. The mobile device 122 may include one or more processors configured to execute computer instructions and a storage medium on which the computer-executable instructions and / or data may be stored. The mobile devices 122 may be configured to connect to the TCU 106 or other controllers 104 of the vehicle 102 to provide communication services to the vehicle 102.The charger monitoring server 126 may be an example of a networked computing device that may be accessed by the vehicles 102, the charging stations 118, and / or other devices via the communication network 108. The charger monitor server 126 may be configured to execute the charger service 128 to perform the charger monitor server 126 operations discussed herein. The vehicle 102 may send data from its sensors 110 to the charger monitoring server 126 via the communication network 108. The vehicle 102 may monitor its use of the charging station 118 and may send its vehicle information 120 to the charger monitoring server 126 via the communication network 108. In another example of an electric vehicle (EV), the charger monitor server 126 may be configured to receive vehicle information 120 from the charging stations 118 via the communication network 108 (e.g., as part of a charging process for using the charging station 118 or as a separate process).The charger monitoring server 126 may maintain information about the vehicles 102. For example, the charger monitoring server 126 may receive information from the communication network 108 indicative of the amount of vehicles 102 in a geographic area. In another example, the charger monitoring server 126 may receive, from the communication network 108, vehicle information 120 indicative of the locations of the vehicles 102. This information may be based on, for example, a home location database of the communication network 108 that retains information indicative of which cells are connected to the TCUs 106 of which vehicles 102. In another example, the vehicles 102 may report their locations to the charger monitoring server 126, e.g., by using a GNSS controller 104 of the vehicle 102 to identify the vehicle location and sending this information by the TCU 106 to the charger monitoring server 126 via the communication network 108.The charger monitoring server 126 may define an update list 132 of the vehicles 102 that are directed to receiving a software update 130. The update list 132 may include a listing of the vehicles 102 as indicated to require a particular software update 130. The vehicles 102 may be specified on the update list 132 by any of various vehicle identifiers, such as VIN, Media Access Control (MAC) address, etc. Whether a software update 130 is required may be based on factors such as make, model, year, location, features, charging device type, etc. of the vehicle 102. In another example, the update list 132 may additionally or alternatively include a listing of the charging stations 118 that need to be updated.The charger monitor server 126 may maintain the software update 130 for the vehicles 102 and the charging stations 118 in a memory of the charger monitor server 126. The software updates 130 may include any of various 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 stations 118. In some cases, the software update 130 may add additional features to the vehicle 102 and / or the charging stations 118. In other cases, the software update 130 may include debugging or other updates to improve the operation of existing features of the vehicle 102 and / or the charging stations 118. In some examples, the software update 130 may be configured for use with a specific make or model of the vehicle 102 and / or the charging stations 118, and / or for a specific model and / or version of the controller 104 (or controllers 104) within the vehicle 102. In some cases, the software update 130 may include or otherwise be associated with a severity level, e.g., whether the update should be installed immediately or whether the update may be installed in the background over time.The charger monitoring server 126 may send update requests 124 to the vehicles 102 and / or the charging stations 118 on the update list 132. The update requests 124 may indicate which software update 130 is to be installed, as well as time information regarding when to perform the installation of the software update 130.If the vehicle 102 is not connected to the charging station 118, the vehicle 102 may use the TCU 106 to download the software update 130. In another example, the vehicle 102 may utilize one or more mobile devices 122 in communication with the vehicle 102 to download the software update 130. The vehicle 102 may connect to each mobile device 122, instruct it to download different segments of the software update 130, and then aggregate the data from each device to form the software update 130 for installation.In many cases, a software update 130 includes an update of the vehicle 102 and also a corresponding update of the charging station 118. In such a case, both the vehicle 102 and the charging station 118 must install their portions of the software update 130 in order for the software update 130 to be completed. To facilitate installation, when such coordinated interaction between the two is required, the charging station 118 may receive and store software updates 130 for both the vehicle 102 and the charging station 118. In an example, the charging station 118 may download software updates 130 for both the vehicle 102 and the charging station 118 via a local Wi-Fi connection available to the charging station 118. This may be useful because the charging station 118 may have a relatively more consistent connection with the communication network 108 than a moving vehicle 102. If the software package is damaged, incomplete, or defective, the charging station 118 may again attempt to download and confirm a complete package for both the charging station 118 and the vehicle 102, including multiple module software packages for the vehicle 102.The vehicle 102 may be connected to the charging station 118 at home or at a depot location. This connection can be made overnight, but other times are possible. Since the load takes dozens of minutes to hours, this provides sufficient time to install most software updates 130 and perform validation.In one example, predictive analysis and / or machine learning may be used to identify reliable parking times and durations while ensuring that the vehicle 102 is connected. For example, a vehicle 102 may have a confidence interval of 85% when inserted between 1 AM and 6 AM, but a confidence interval of 95%+ between 3 AM and 3:30 AM. The duration for performing the software update 130 may be determined from tests and compared to routine plug-in times. If the predicted time matches the download and validation durations, that time is targeted. The vehicle 102 may estimate the time required for download and installation based on factors such as link speed and data transfer rates over the communication network 108. This information helps estimate future update durations for similar vehicles 102. The estimated duration ensures that there is sufficient time for the update before the vehicle 102 is required again. The time at the location may be derived based on the usage history, the state of charge, the charging rate, and the estimated charging duration of the vehicle 102.In some examples, the scheduled amount of time may be configured to take into account the time involved in testing and resetting the software update 130 when a problem occurs. If the software cannot be reset to the previous version or causes errors that prevent further operation, the provision is halted on devices that still need to be updated and the reset process begins with products in process. The system 100 may notify the operator to manage any outliers that the system cannot correct.Software updates 130 for the vehicle 102 and the charging station 118 may follow a predetermined sequence. Depending on the software package, the sequence may first include downloading to the charging station 118, followed by modules of the vehicle 102, or vice versa. The sequence may be defined by the type of software. The vehicle 102 may download the software update 130 in segments and perform the installation once all segments have been obtained, even if the vehicle 102 no longer remains connected to the charging station 118. The charging station 118 may communicate with the vehicle 102 to provide the software update 130.After a new software update 130 is installed on the vehicle 102, the previous software version may be stored in non-volatile memory of the vehicle 102 for a period of time until the new software on a particular number of vehicles 102 has been successfully validated at a particular success rate. The validation level may vary based on the update changes and the system importance. If the new version is performing poorly, the vehicle 102 may be automatically reset to the previous version. Additionally, if the update causes operational issues, the vehicle 102 may be automatically reset to the previous version. In some cases, the charging station 118 may download existing software versions from the modules of the vehicle 102 for resetting if the new software has errors. This transmission may be through a charging cable between the vehicle 102 and the charging station 118, but in other examples may be performed wirelessly. The charging station 118 may confirm installation of the software update 130 in the vehicle 102 and may retain the previous version of the software for reset if validation fails.After a successful update has been confirmed, validation of the procedure and reporting can be done. In one example, once installation of the software update 130 is completed, the vehicle 102 and charging station 118 are subjected to a sequence of modes of operation to verify proper operation. These modes include normal operations (charge, discharge, stop, start, throttle, etc.) and preprogrammed regression tests. In some examples, the vehicle 102 and the charging station 118 may report their status via external sound exciters. In other examples, the vehicle 102 and the charging station 118 may communicate their status to each other via radio frequency (RF) wireless communication and / or using the charging cord connection.Vehicles 102 may be identified and grouped to obtain statistically relevant samples from different market populations. These groups account for variations in climate, thermal temperatures from previous recordings, brands and series of vehicles 102, power levels, and installation characteristics.The charger monitoring server 126 may maintain test reports 134 regarding the progress in sending and performing the software update 130 to the vehicles 102 on the update list 132. Likewise, test reports 134 from the vehicles 102 may include information such as a result of the software update 130 (e.g., completed transmission, incomplete transmission, interrupted transmission, checksum errors, transmission not possible, etc.), a location of the vehicle 102, whether the vehicle 102 has moved, whether the vehicle 102 is ON or OFF, download speed to the vehicle 102, RF signal parameters as measured for the vehicle 102, etc.The charger monitoring server 126 may also maintain test reports 134 regarding the progress in sending and performing the software update 130 to the charging stations 118 on the update list 132. These reports may likewise indicate the update state of the charging station 118 side of software updates 130, which also include the charging station 118.Each relevant population may perform operational modes, diagnostics, and regression tests reporting success, failure, and abnormal events. Thresholds may be predetermined to understand whether the standard deviation exceeds acceptable limits for the population or whether defects occur. The results are reported and marked if a proper function fails. If the message is acceptable, the software is further introduced. If any defects exceed population threshold metrics, the software reset process is initiated. This procedure may be performed on hundreds to thousands of vehicles 102 simultaneously, accelerating the verification process. Thus, by using the updates of customer or fleet vehicles 102, the vehicles 102 may be used as a test fleet.FIG. 2 illustrates an example process 200 for performing a simultaneous installation of a software update 130 to the vehicle 102 and to the charging station 118. In an example, the process 200 may be performed by the vehicle 102, the charging station 118, and the charger monitoring server 126 in communication via the communication network 108.At operation 202, an update request 124 for installing a software update 130 at the charging station 118 is received. This update request 124 may have been received from the charger monitoring server 126, as discussed in more detail with respect to the process 300.At operation 204, a software update 130 is received at the vehicle 102 and at the charging station 118. The installation of the software update 130 in the vehicle 102 and in the charging station 118 may follow a predetermined sequence. Depending on the software package, the sequence may first include downloading to the charging station 118, followed by the controllers 104 of the vehicle 102, or vice versa.In an example, the charging station 118 may receive the software update 130 for both the vehicle 102 and the charging station 118 via the communication network 108. The charging station 118 may store the software updates 130 in its local memory. When the vehicle 102 is present, the charging station 118 may send the software update 130 for the vehicle 102 to the vehicle 102 via a local network connection. This connection may be, for example, a wired connection via a data connection included in the charging cable connecting the charging station 118 to the vehicle 102. In another example, the data connection may be a wireless connection between the charging station 118 and the vehicle 102, such as a Wi-Fi connection. This approach may take advantage of the fact that the charging station 118 is stationary and typically receives a stronger network signal than the vehicle 102. Moreover, this may also ensure that the vehicle 102 and the charging station 118 are operated using a corresponding pair of software updates 130.In another example, the vehicle 102 may use one or more mobile devices 122 to receive the software update 130. In an example, the vehicle 102 may establish communication links with each mobile device 122, instruct it to download different segments of the software update 130, and then aggregate the segments from each mobile device 122 to compile the software update 130 for the vehicle 102. In such an example, the vehicle 102 may download the software update 130 in segments even if the vehicle no longer remains connected to the charging station 118.The vehicle 102 and / or the charging station 118 may verify a signature of the software update 130, e.g., an MD5 hash or the like. If the software update 130 is corrupted, incomplete, or defective, the charging station 118 and / or the vehicle 102 may retry until a complete package has been downloaded and acknowledged for both the charging station 118 and the vehicle 102.At operation 206, the vehicle 102 and the charging station 118 perform installation of the software update 130. The time of installation of the software update 130 may be indicated in the update request 124 received at operation 202. For the vehicle 102, the installation may include copying the current software of the one or more controllers 104 being updated to a backup location, as well as installing the software update 130 on the one or more controllers 104 being updated. For the charging station 118, this may also include copying the current software to a backup location as well as installing the software update 130 at the charging station 118.In an example where the charging station 118 provides the software update 130 to the vehicle 102, the charging station 118 may communicate with the vehicle 102 to provide the software update 130. The charging station 118 may use its data connection to the vehicle 102 to download the existing software from the vehicle controllers 104 for reset prior to update if the new software has problems. This transmission can be effected via the charging cable, but can also be carried out wirelessly.In an example where the vehicle 102 performs the download of the software update 130 using the mobile devices 122, the vehicle 102 may download the software update 130 in segments and may perform the installation once all segments have been obtained, even if the vehicle 102 no longer remains connected to the charging station 118.Regardless, after the software update 130 is installed on the vehicle 102, the previous software version may be maintained by the charging station 118 until the new software on a defined number of vehicles 102 has been successfully validated at a defined success rate.At operation 208, the vehicle 102 and the charging station 118 determine whether the installation of the software update 130 is successful. This may include, for example, the vehicle 102 determining that the software update 130 could be installed in the vehicle 102. This charging station 118 may also redundantly confirm the software installation in the vehicle 102 and may retain the previous software for resetting if the validation fails. This may also include confirming that the charging station 118 has been updated and that the fuses could be stored.Once the software update 130 has been installed, control passes to operation 210 to test the functionality of the updated software.At operation 210, the vehicle 102 and the charging station 118 perform update software validation tests after installation of the software updates 130 in the vehicle 102 and at the charging station 118. The validation may include subjecting the vehicle 102 and the charging station 118 to a sequence of modes of operation to verify proper functioning. The vehicle 102 and the charging station 118 may report status via the charging cable, wirelessly, and external sound exciters. These modes include normal operations (charge, discharge, stop, start, throttle, etc.) and preprogrammed regression tests. This validation may be performed on hundreds to thousands of vehicles 102 simultaneously, accelerating the verification process.At operation 212, the charging station 118 determines whether the validation was successful. For example, if the new version provides poor performance with respect to validation tests, the vehicle 102 may be automatically reset to the previous version. In another example, if the update causes operational issues, the vehicle 102 may also be automatically reset to the previous version. If validation is not successful, control passes to operation 214 to reset the update. Similarly, if validation is not successful at operation 208, control passes to operation 214 to reset the update.At operation 214, the vehicle 102 and / or the charging station 118 resets installation of the software update 130. In one example, the backup version of the software may be recharged to the controllers 104 of the vehicle 102 and / or to the charging station 118.At operation 216, a test report 134 is compiled following operations 212 or 214. The test report 134 may indicate the results of the installation to the vehicle 102 and the charging station 118. Additionally, the test report 134 may indicate the results of the validation if the installation was successful. The test report 134 may also include additional information, such as the VIN or other identifier of the vehicle 102 being updated.At operation 218, the test report 134 is sent to the charger monitoring server 126. In an example, the charging station 118 may collect the test report 134 from the vehicle 102 and may send the test report 134 to the charger monitoring server 126 via the communication network 108. In another example, the charging station 118 may additionally send its test report 134 regarding the installation of the software update 130 at the charging station 118 to the charger monitoring server 126. In yet another example, the charging station 118 may collect test reports 134 from a plurality of vehicles 102 and may send the collection of test reports 134 to the charger monitoring server 126. In another example, the vehicle 102 may send its test report 134 separately to the charger monitoring server 126. After operation 218, the process 200 ends.FIG. 3 illustrates an example process 300 for the charger monitoring server 126 implementing an OTA software update test approach 130. In one example, as with process 200, process 300 may be performed by vehicle 102, charging station 118, and charger monitoring server 126 in communication via communication network 108.At operation 302, the charger monitor server 126 maintains the vehicle information 120. This vehicle information 102 includes records that indicate when the vehicle 102 is currently connected to which of the charging station 118. In another example, the vehicle information 120 includes parameters related to the configuration or other features of the vehicle 102. This information may be received from various sources, such as from the manufacturer of the vehicle 102, the vehicles 102 responsive to the charging, the charging stations 118 providing the charger monitoring server 126 with their charging history, etc.At operation 304, the charger monitoring server 126 identifies vehicles 102 to receive a software update 130. In an example, the charger monitoring server 126 identifies an update list 132 of the vehicles 102 to receive the software update 130. The update list 132 may include a listing of the vehicles 102 as indicated to require a particular software update 130. The vehicles 102 may be specified on the update list 132 by any of various vehicle identifiers, such as VIN, MAC address, etc. Whether a software update 130 is required may be based on factors such as make, model, year of construction, location, features, charging device type, etc. of the vehicle 102. In another example, the update list 132 may additionally or alternatively include a listing of the charging stations 118 that need to be updated.At operation 306, the charger monitor server 126 determines, for each of the vehicles 102 on the update list 132, the update time to perform the update, test, and / or reset cycles for the software update 130. In one example, the charger monitoring server 126 provides predictive analysis and machine learning to identify reliable parking times and durations while ensuring that the vehicle 102 is connected. For example, the charger monitor server 126 may have a vehicle 102 confidence interval of 85% when inserted between 1 AM and 6 AM, but a 95%+ confidence interval between 3 AM and 3:30 AM.The charger monitoring server 126 may determine the duration of the software update 130 from tests and compares it to routine plug-in times. If the predicted time matches the download and validation durations, the LAde device monitoring server 126 may target that time. The charger monitoring server 126 may estimate the time required for download and installation based on the connection speed and data transfer rates. This information helps the charger monitoring server 126 estimate future update durations for similar vehicles 102. The estimated duration ensures that there is sufficient time for the software update 130 to be downloaded and installed (and optionally reset) before the vehicle 102 is needed again. The charger monitoring server 126 may support the time at the location based on factors including vehicle usage history, state of charge, charging rate, and estimated charging duration.For example, based on the increased likelihood that the vehicle 102 is present at that time, the charger monitor server 126 may determine that 3-3:30 a.m. is the better time to perform the software update 130. In another example, if additional time is required for software update 130 and validation, charger monitor server 126 may determine that 1-6 am is a better time to perform software update 130.At operation 308, the charger monitor server 126 invokes a test cycle for the vehicles 102 on the update list 132. To do so, the charger monitoring server 126 may send update requests 124 to the vehicles 102 and / or the charging stations 118. This may trigger the vehicles 102 and charging stations 118 to perform the operations of the process 200 discussed in detail above.At operation 310, the charger monitoring server 126 collects test reports 134. These may include the test reports 134 sent from the vehicles 102 and charging stations 118 at operation 218 being updated according to the process 200.At operation 312, the charger monitor server 126 determines whether the test cycle is successful. In an example, the charger monitoring server 126 may compare the results of the test reports 134 to a threshold success rate to ensure that at least a minimum of the vehicles 102 and / or charging stations 118 successfully applied the software updates 130. If so, control passes to operation 314.At operation 314, the charger monitor server 126 determines whether the tests are complete. For example, the charger monitoring server 126 may be configured to execute a set of test cycles for software update 130 of various parameters, such as trademarks, models, configurations, locations, and / or features installed in the vehicle 102. These cycles may be iteratively performed to ensure that one or more cycles are successful before additional cycles are performed. For example, a small cycle of vehicles 102 with a given set of parameters may receive and test the software update 130 (e.g., to establish confidence) before applying the software update 130 to a larger set of vehicles 102 with these parameters. In another example, cycles may be constructed that first establish confidence with a first set of parameters and then attempt software update 130 for vehicles 102 with a different set of parameters. If the success rate of the update is above a cancellation threshold, the charger monitor server 126 may continue updating with the additional cycles. If not, the charger monitor server 126 may choose to interrupt testing. If testing is passed and not completed, the process 300 returns to operation 304 to continue updating with an additional update list 132. If testing is complete or the update success rate is below the abort threshold, control passes to operation 316.At operation 316, the charger monitoring server 126 determines whether to maintain the software update 130 at the vehicles 102 and / or the charging stations 118. For example, if the success rate of the update is above a break threshold and the software update 130 is intended for production, the software update 130 may be permitted to remain installed and the process 300 ends.However, if the success rate is low, the charger monitor server 126 may decide not to leave the software update 130 installed and may instruct the vehicles 102 and / or charging stations 118 to return to the backup software. If so, control passes to operation 318 to cause the charger monitoring server 126 to instruct the vehicles 102 and / or charging stations 118 to return to the backup software. In another example, even if the software update 130 is passed, if the software update 130 was provisionally installed (e.g., to test a new feature, but not maintain), the charger monitor server 126 may still proceed to operation 318 to reset the software.At operation 318, the charger monitoring server 126 sends an update request 124 to the vehicles 102 and / or charging stations 118 to reset to the backup software. In some examples, the update request 124 is sent to the vehicles 102 and also to the charging stations 118. In another example, the update request 124 is sent to the charging stations 118, which when connected to the charging stations 118 instruct the vehicles 102 to reset the software update 130. This reset may be performed, for example, using the backup software stored on the charging stations 118 during application of the software update 130 to the vehicles 102. After operation 318, the process 300 ends.FIG. 4 illustrates an example computing device 402 for implementing an iterative software update test approach 130 using consumer vehicles 102. Referring to FIG. 4 and with reference to FIGS. 1-6B, the vehicles 102, controllers 104, TCU 106, communication network 108, sensors 110, GNSS controller 112, HMI controller 114, charging controller 116, charging stations 118, mobile devices 122, charger monitoring server 126 are examples of such computing devices 402. Computing devices 402 generally include computer-executable instructions, such as those of charger service 128 and software updates 130, where the instructions may be executable by one or more computing devices 402. Computer-executable instructions may be compiled or interpreted from computer programs created using a variety of programming languages and / or technologies, including, without limitation, and either alone or in combination, Java™ C, C++, C#, Visual Basic, JavaScript, Python, JavaScript, Perl, etc. In general, a processor (e.g., a microprocessor) receives instructions, e.g., from a memory, a computer-readable medium, etc., and executes these instructions, thereby performing one or more processes including one or more of the processes described herein. Such instructions and other data, such as vehicle information 120, may be stored and transmitted using a variety of computer readable media.As shown, computing device 402 may include a processor 404 operatively connected to a data store 406, a network device 408, an output device 410, and an input device 412. It should be noted that this is merely an example and computing devices 402 with more, fewer, or different components may be used.The processor 404 may include one or more integrated circuits that implement central processing unit (CPU) and / or graphics processing unit (GPU) functionality. In some examples, the processors 404 are a system on a chip (SoC) in which the functionality of the CPU and the GPU are integrated. The SoC may optionally include other components, such as the data store 406 and the network device 408, in a single integrated device. In further examples, the CPU and the GPU are interconnected via a peripheral interconnect device, such as a peripheral component interconnect (PCI) express or other suitable peripheral data connection. In one example, the CPU is a commercially available central processing device that implements an instruction set, such as one of the x86, ARM, or power instruction set family or a microprocessor without interconnected pipeline stages (MIPS) instruction set family.Regardless of the details, during operation, processor 404 executes stored program instructions that are retrieved from data store 406. The stored program instructions accordingly include software that controls the operation of the processors 404 to perform the operations described herein. The data store 406 may include both non-volatile and volatile storage devices. The non-volatile memory includes solid state memory, such as Not-AND (NAND) memory, magnetic and optical storage media, or any other suitable data storage device that maintains data when the system is deactivated or power is interrupted. The volatile memory includes static and dynamic random access memory (RAM) that stores program instructions and data during operation of the system 100.The GPU may include hardware and software for displaying at least two-dimensional (2D) and optionally three-dimensional (3D) graphics on an output device 410. The output device 410 may include a graphical or visual display device, such as an electronic display screen, a projector, a printer, or any other suitable device that reproduces a graphical display. As another example, the output device 410 may include an audio device such as a speaker or a headphone. As yet another example, the output device 410 may include a tactile device, such as a mechanically elevatable device, which in one example may be configured to display blind text or other physical output that may be touched to provide information to a user.The input device 412 may include any of various devices that enable the computing device 402 to receive control inputs from users. Examples of suitable input devices 412 that receive input via an interface with humans may include keyboards, mice, trackballs, touch screens, microphones, graphics tablets, and the like.The network devices 408 may each include any of various devices that enable the described components to send and / or receive data from external devices over networks. Examples of suitable network devices 408 include an Ethernet interface, a Wi-Fi transceiver, a cellular transceiver, or a BLUETOOTH or BLE transceiver, or another network adapter or peripheral connection device that receives data from another computer or external data storage device, which may be efficiently useful for receiving large sets of data.With respect to the processes, systems, methods, heuristics, etc. described herein, it should be understood that although the steps of such processes, etc. have been described as occurring according to a particular ordered sequence, such processes could be practiced with the described steps performed in an order that varies from the order described herein. Further, it should be understood that certain steps could be performed simultaneously, other steps added, or certain steps described herein could be omitted. In other words, the descriptions of processes herein are for the purpose of illustrating certain embodiments and should not be construed as limiting the claims.Accordingly, it is to be understood that the foregoing description is intended to be illustrative and not restrictive. From reading the foregoing description, many embodiments and applications other than the examples provided will be apparent. The scope should be determined, not with reference to the foregoing description, but should instead be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled. It is anticipated and intended that future developments will occur in the technologies discussed herein, and that the disclosed systems and methods will be incorporated into such future embodiments. Overall, it is understood that the application may be modified and varied.All terms used in the claims are intended to be accorded the broadest comprehensible constructions and their general meaning as are known to those skilled in the art using the techniques described herein, unless expressly stated to the contrary herein. In particular, the use of the singular articles such as "a", "an", "the", "the", etc. is to be understood to mean one or more of the stated elements unless a claim gives an explicit limitation to the contrary.The Abstract of the Disclosure is provided to enable the reader to quickly ascertain the nature of the technical disclosure. It is submitted with the proviso that it is not used to interpret or limit the scope or meaning of the claims. In addition, it will be apparent from the foregoing detailed description that various features have been incorporated in various embodiments for the purpose of simplifying the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, the subject matter of the invention lies in less than all features of a single disclosed embodiment. Thus, the following claims are hereby incorporated into the Detailed Description, each claim standing on its own as a separately claimed subject matter.While exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the disclosure. The terms used in the specification are words of description rather than limitation, and it is understood that various changes may be made without departing from the spirit and scope of the disclosure. Additionally, the features of various implementing embodiments may be combined to form further embodiments of the disclosure.According to the present invention, a method for iterative software updating using consumer vehicles includes sending update requests to perform software updates to vehicles and charging stations in a test cycle, the vehicles included in an update list; receiving test reports from the vehicles and charging stations; in response to the test reports indicating success above a minimum success threshold, continuing to introduce the software update in an additional test cycle; and otherwise sending reset update requests to reset the software update to the vehicles and charging stations.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, the corresponding charging station software update to be installed in the one of the charging stations; receiving a vehicle test report indicating a result of the installation of the vehicle software update to the one of the vehicles, from the one of the charging stations, and further a charging station test report indicating a result of the installation of the charging station software update to one of the charging stations.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 so, an indication of whether the validation of the functionality of the software update was successful.In one aspect of the invention, the method includes storing a backup of the vehicle software of the one of the vehicles in a memory of the one of the charging stations prior to application of the software update.In one aspect of the invention, the method includes resetting the software update by sending the backup of the vehicle software from the memory of the one of the charging stations to the one of the vehicles for reinstallation in one of the vehicles.In one aspect of the invention, the software update is to be tested but not preserved, and further comprising resetting to backup the vehicle software independent of the test reports.In one aspect of the invention, the method includes: identifying parking times and durations during which the vehicles are likely connected to the charging stations; and indicating a time to install the software update in the update requests.In one aspect of the invention, the method includes: including a first set of vehicles having a given set of parameters in 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 in a second update list for the additional test cycle.In one aspect of the invention, the method includes: including a first set of vehicles having a given set of parameters in the update list to test the software update before the software update is applied to vehicles having a different set of parameters; and including a second set of vehicles having the different set of parameters in a second update list for the additional test cycle.According to the present invention, there is provided an iterative software update system using consumer vehicles, comprising: a memory that maintains vehicle information, the vehicle information including records indicating to which charging stations vehicles are currently connected and parameters related to configuration and / or characteristics of the vehicles; A charger monitoring server configured to identify an update list of vehicles to receive a software update, send update requests to apply the software update to the vehicles of the update list, receive test reports from the vehicles and the charging stations, responsive to the test reports indicating success above a minimum success threshold, continue introduction of the software update in an additional test cycle, and otherwise send a reset update request to reset the software update to the vehicles and the charging stations.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, the vehicle software update to be installed in one of the vehicles, the corresponding charging station software update to be installed in the one of the charging stations; and receive a vehicle test report indicating a result of the installation of the vehicle software update to the one of the vehicles, from the one of the charging stations, and also a charging station test report indicating a result of the installation of the charging station software update to one of the charging stations.According to one embodiment, the result of the installation includes an indication of whether the installation of the software update was successful and, if so, an indication of whether the validation of the functionality of the software update was successful.According to an embodiment, the charger monitoring server is further configured to store a backup of the vehicle software of the one of the vehicles in a memory of the one of the charging stations prior to the application of the software update.According to an embodiment, the charger monitoring server is further configured to reset the software update by sending the backup of the vehicle software from the memory of the one of the charging stations to the one of the vehicles for reinstallation in one of the vehicles.According to one embodiment, the software update is to be tested but not preserved, and wherein the charger monitor server is further configured to reset to backup the vehicle software independent of the test reports.According to an embodiment, the charger monitoring server is further configured to identify parking times and durations during which the vehicles are likely connected to the charging stations; and indicate a time to install the software update in the update requests.According to an embodiment, the charger monitoring server is further configured to: include a first set of vehicles with a given set of parameters in the update list to test the software update before the software update is applied 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 in a second update list for the additional test cycle.According to one embodiment, the charger monitoring server is further configured to: include a first set of vehicles having a given set of parameters in the update list to test the software update before the software update is applied to vehicles having a different set of parameters; and include a second set of vehicles having the different set of parameters in a second update list for the additional test cycle.According to the present invention, there is provided a non-transitory computer readable medium comprising instructions for iterative software update using consumer vehicles that, when executed by a charger monitor server, cause the charger monitor server to perform operations including: maintaining vehicle information, the vehicle information including records indicating to which charging stations vehicles are currently connected and parameters related to configuration and / or features of the vehicles; identifying an update list of vehicles to receive a software update, sending update requests to apply the software update to the vehicles of the update list, receiving test reports from the vehicles and charging stations, responsive to the test reports indicating success above a minimum success threshold, continuing to introduce the software update in an additional test cycle, and otherwise sending a reset update request to reset the software update at the vehicles and charging stations.According to an embodiment, the discovery is further characterized by instructions that, 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, the vehicle software update to be installed in one of the vehicles, the corresponding charging station software update to be installed at the one of the charging stations; and receiving a vehicle test report indicating a result of the installation of the vehicle software update to the one of the vehicles from the one of the charging stations, and also a charging station test report indicating a result of the installation of the charging station software update to one of the charging stations.References included in the specificationThis list of documents cited by the applicant has been produced in an automated manner and is only included for the better information of the reader. The list is not part of the German patent application or utility model application. The DPMA does not take any adhesion for any faults or omissions.Cited Non-Patent LiteratureISO) 3779

[0011] ISO 4030

[0011]

Claims

A method for iterative software updating using consumer vehicles, comprising: sending update requests to install a software update to vehicles and charging stations in a test cycle, the vehicles being included in 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 to introduce the software update in an additional test cycle; and otherwise sending reset update requests to reset the software update to the vehicles and the charging stations.The method of claim 1, further comprising: 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 at one of the vehicles, the corresponding charging station software update to be installed at the one of the charging stations; receiving a vehicle test report indicating a result of the installation of the vehicle software update to the one of the vehicles from the one of the charging stations and also a charging station test report indicating a result of the installation of the charging station software update at one of the charging stations.The method of claim 2, wherein the result of the installation includes an indication of whether the installation of the software update was successful and, if so, an indication of whether the validation of the functionality of the software update was successful.The method of claim 2, further comprising storing a backup of the vehicle software of the one of the vehicles in a memory of the one of the charging stations prior to the application of the software update.The method of claim 4, further comprising resetting the software update by sending the backup of the vehicle software from the memory of the one of the charging stations to the one of the vehicles for reinstallation in one of the vehicles.The method of claim 4, wherein the software update is to be tested but not to be maintained, and further comprising resetting to backup the vehicle software independent of the test reports.The method of claim 1, further comprising: identifying parking times and durations during which the vehicles are likely to be connected to the charging stations; and indicating a time to install the software update in the update requests.The method of claim 1, further comprising: including a first set of vehicles having a given set of parameters in 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, in a second update list for the additional test cycle, the larger set of vehicles having the given set of parameters.The method of claim 1, further comprising: including a first set of vehicles having a given set of parameters in the update list to test the software update before applying the software update to vehicles having the one different set of parameters; and including, in a second update list for the additional test cycle, a second set of vehicles having the different set of parameters.An iterative software update system using consumer vehicles, comprising: a data store that maintains vehicle information, wherein the vehicle information includes records that indicate when vehicles are currently connected to which charging stations and that indicate parameters related to configuration and / or characteristics of the vehicles; A charger monitoring server configured to: identify an update list of vehicles to receive a software update; send update requests to apply the software update to the vehicles on the update list; receive test reports from the vehicles and the charging stations, in response to the test reports indicating success above a minimum success threshold; continue to introduce the software update in an additional test cycle; and otherwise send reset update requests to reset the software update to the vehicles and the charging stations.The system of claim 10, wherein 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, the vehicle software update to be installed on one of the vehicles, the corresponding charging station software update to be installed on the one of the charging stations; and receive a vehicle test report indicating a result of the installation of the vehicle software update to the one of the vehicles from the one of the charging stations and also a charging station test report indicating a result of the installation of the charging station software update on one of the charging stations.The system of claim 11, wherein the result of the installation includes an indication of whether the installation of the software update was successful and, if so, an indication of whether the validation of the functionality of the software update was successful.The system of claim 11, wherein the charging facility location server is further configured to one or more of: store a backup of the vehicle software of the one of the vehicles in a memory of the one of the charging stations prior to application of the software update; reset the software update by sending the backup of the vehicle software from the memory of the one of the charging stations to the one of the vehicles for reinstallation in one of the vehicles; and wherein the software update is to be tested but not to be maintained, and reset to the backup of the vehicle software independent of the test reports.The system of claim 10, wherein the charger monitoring server is further configured to: identify parking times and durations during which the vehicles are likely connected to the charging stations; and indicate a time to install the software update in the update requests.The system of claim 10, wherein the loader location server is further configured to one or more of: include a first set of vehicles having a given set of parameters in the update list to test the software update before the software update is applied to a larger set of vehicles having the given set of parameters and include the larger set of vehicles having the given set of parameters in a second update list for the additional test cycle; or include a first set of vehicles having a given set of parameters in the update list to test the software update before the software update is applied to vehicles having a different set of parameters and include a second set of vehicles having the different set of parameters in a second update list for the additional test cycle.

Images