Silent software updates within a vehicle

Abstract

System which includes: a data identification list defining which information is to be included in a query log and at which of a plurality of vehicle control devices this information is located, the data identification list being received as part of a software installation downloaded from a server to the vehicle; and at least one control device of the vehicle which is programmed to to generate the query protocol based on the data identification list, Send query log to the server, Receiving a statement from the server specifying network locations of software updates determined according to the query protocol, Installing update binaries retrieved from network locations to an inactive installation of multiple storage installations and Set the inactive installation as an active installation after a vehicle restart instead of another of the storage installations.

Description

[0001] The illustrative embodiments generally relate to a system, method, and non-transitory computer-readable storage medium for a dedicated wireless module update.

[0002] Vehicle software systems are becoming increasingly complex. Many vehicles now on the road have numerous associated software modules. Powertrain control, information and entertainment, navigation, and a number of other systems are controlled by hardware and software. Given the complex nature of these systems and the number of software and hardware components, there are frequent updates that may be useful to vehicle owners. To address this complexity, a remote operator can be used to assist with software updates. However, these approaches may require the attention of the vehicle owner, which may cause the vehicle owner to postpone performing vehicle software updates.

[0003] The technological background relevant to the present invention is provided by the publications DE 11 2008 003 075 T5, US 2013 / 0 167 134 A1 and DE 10 2012 106 791 A1.

[0004] Against this background, the present invention is based on the object of providing a system, method and non-volatile computer-readable storage medium that is improved compared to the prior art.

[0005] This is achieved by a system according to claim 1, a method according to claim 7 and a non-transitory computer-readable storage medium according to claim 8.

[0006] Thus, the present invention firstly relates to a system comprising: a data identification list defining which information is to be included in a query log and at which of a plurality of vehicle control devices this information is located, wherein the data identification list is received as part of a software installation downloaded from a server to the vehicle; and at least one control device of the vehicle which is programmed to generate the query protocol based on the data identification list, sending the query protocol to the server, Receiving a statement from the server specifying network locations of software updates determined according to the query protocol, Installing update binaries retrieved from network locations to an inactive installation of multiple storage installations and Set the inactive installation as an active installation after a vehicle restart instead of another of the storage installations.

[0007] Furthermore, the invention relates to a method which is carried out at least by a control device of a vehicle, the method comprising: Receiving from a server by a vehicle, a data identification list, which defines which information is to be included in a query log and where the information is located in an active software installation; Generating the query log; Sending the query log to the server; Receiving, in response, a statement specifying network locations of software updates determined according to the query protocol; Installing update binaries retrieved from the network locations to an inactive software installation of multiple storage installations; and setting the inactive software installation as an active software installation after vehicle reboot in place of another storage installation.

[0008] Furthermore, the invention relates to a non-transitory computer-readable storage medium that stores instructions that, when executed by at least one control device of a vehicle, cause the at least one control device to perform the following: receiving from a server by the vehicle, a data identification list that defines which information is to be included in a query log and at which of a plurality of vehicle control devices this information is located; Generating the query log based on the data identification list; sending the query log to the server; Receiving from the server a statement specifying network locations of software updates determined according to the query protocol; Installing update binaries retrieved from network locations to an inactive installation of multiple storage installations; and setting the inactive installation as an active installation after a vehicle restart instead of another storage installation. Fig. 1 shows an example block topology for a vehicle-based computing system for a vehicle, the Fig. 2A - 2D show an illustrative system for silent module software updates, and Fig. Figure 3 shows an example process for updating vehicle software.

[0009] As required, detailed embodiments of the present invention are disclosed herein as appropriate. It is to be understood, however, that the disclosed embodiments are merely exemplary of the invention, and that it may be embodied in various alternative forms. The figures are not necessarily to scale. Some features may have been exaggerated or minimized to show details of particular components. Therefore, specific structural and functional details disclosed herein should not be interpreted as limiting, but merely as a representative basis for teaching those skilled in the art how to variously employ the present invention.

[0010] A system may be designed to perform silent over-the-air updates of software modules. The system may install the updates into a parallel software installation that is separate from an active software installation (such as a partition that is different from the active software partition, or a parallel file and / or directory set that is different from an active file set). When the installation is complete, the system may switch the active software installation to the second parallel software installation. In some cases, the system may provide a notification to the user that the software has been updated. This allows the software to be updated without requiring customer intervention to invoke the update process and without the customer being unable to use the software systems while an update is in progress.

[0011] To determine which modules need to be updated, a vehicle module may be configured to generate a query log containing version information of at least one software module installed on the vehicle and send the query log to a cloud server. The vehicle module may determine that the query log needs to be generated based on criteria, which may include determining that a predetermined number of power-on cycles have been performed by the vehicle, determining that a specified period of time has elapsed since a query log was generated, or a combination of both.The query log may include information compiled according to a data identification list that defines what information is to be included in the query log and where that information is located in the active software installation. The vehicle may be configured to receive a declaration from the cloud server based on information contained in the provided query log, thereby specifying network locations of at least one software update to be installed by the vehicle. Based on the declaration, the vehicle may be configured to install updated binary elements retrieved from specified network locations into an inactive installation. The vehicle may be configured to set the inactive installation, once updated, as the active installation (e.g., a boot partition) instead of the previously active installation.Accordingly, after restarting the vehicle, the software of the updated installation can be used.

[0012] Fig. 1 shows an example block topology for a vehicle-based computing system 1 (VCS) for a vehicle 31. An example of such a vehicle-based computing system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle equipped with a vehicle-based computing system may include a visual front-end interface 4 located in the vehicle 31. The user may also be able to interact with the interface, if provided, for example, with a touch-sensitive screen. According to another illustrative embodiment, the interaction occurs through keystrokes, a voice dialog system with automatic speech recognition, and speech synthesis.

[0013] According to the Fig. In the illustrative embodiment 1 shown in FIG. 1, a processor 3 or central processing unit (CPU) 3 controls at least part of the operation of the vehicle-based computing system. The processor 3, provided within the vehicle 31, enables on-board processing of instructions and routines. Further, the processor 3 is connected to both a non-persistent memory 5 and a non-persistent memory 7. According to this illustrative embodiment, the non-persistent memory 5 is random access memory (RAM), and the non-persistent memory 7 is a hard disk drive (HDD) or flash memory. In general, the non-persistent (non-volatile) memory 7 may include any form of memory that maintains data when a computer or other device is shut down.These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, SSDs, portable USB drives, and any other suitable form of permanent storage 7.

[0014] The processor 3 is also provided with a number of different inputs that allow the user to communicate with the processor 3. According to this illustrative embodiment, a microphone 29, an auxiliary input 25 (for an input 33), a USB input 23, a global positioning system (GPS) input 24, a screen 4, which may be a touchscreen display, and a BLUETOOTH™ input 15 are all provided. An input selector 51 is also provided to allow a user to switch between different inputs. Input to both the microphone and the auxiliary connector is converted from analog to digital by a converter 27 before being passed to the processor 3.Although not shown, many of the vehicle components and auxiliary components that communicate with the VCS 1 may utilize a vehicle network (such as, but not limited to, a vehicle area network (CAN) bus) to communicate data to or from the VCS 1 (or components thereof).

[0015] Outputs of the VCS system 1 may include, but are not limited to, a visual display 4 and a speaker 13 or a stereo output. The speaker 13 is connected to an amplifier 11 and receives its signal from the processor 3 via a digital-to-analog converter 9. Output may also be made to a remote BLUETOOTH™ device, such as a personal navigation device (PND) 54, or a USB device, such as a vehicle navigation device 60, along the bidirectional data streams illustrated at 19 and 21, respectively.

[0016] According to an illustrative embodiment, the system 1 uses the BLUETOOTH™ transceiver 15 to communicate 17 with a nomadic device (ND) 53 (e.g., a cellular phone, a smartphone, a PDA, or other device with wireless wide-area network connectivity). The nomadic device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31, for example, by communicating 55 with a cellular tower 57. According to some embodiments, the tower 57 may be a WiFi access point.

[0017] An exemplary communication between the nomadic device 53 and the BLUETOOTH™ transceiver is illustrated by communication 14.

[0018] Pairing of a nomadic device 53 and the BLUETOOTH™ transceiver 15 may be initiated by a button 52 or similar input. Accordingly, the CPU is alerted that the onboard BLUETOOTH™ transceiver 15 is being paired with a BLUETOOTH™ transceiver in a nomadic device 53.

[0019] Data may be communicated between the CPU 3 and the network 61, for example, using a data plan, voice data transmission, or dual-tone multifrequency (DTMF) tones in conjunction with the nomadic device 53. Alternatively, it may be desirable to include an onboard modem 63 with an antenna 18 to communicate 16 data over the voice band between the CPU 3 and the network 61. The nomadic device 53 may then be used to communicate 59 with a network 61 external to the vehicle 31, for example, by communicating 55 with a cellular tower 57. According to some embodiments, the modem 63 may establish a connection 20 with the tower 57 to communicate with the network 61. In one non-limiting example, the modem 63 may be a USB cellular modem 63, and the communication 20 may be a cellular communication.

[0020] According to one illustrative embodiment, the processor 3 is provided with an operating system having an API for communicating with modem application software. The modem application software can access an embedded module or firmware on the BLUETOOTH™ transceiver to perform wireless communication with a remote BLUETOOTH™ transceiver (such as that found in a nomadic device). Bluetooth is a subset of the Institute of Electrical and Electronics Engineers (IEEE) 802 Personal Area Network (PAN) protocols. IEEE 802 Local Area Network (LAN) protocols include Wi-Fi protocols and have significant cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle 31.For example, BLUETOOTH™ and Wi-Fi can be used as transport to provide communication between the processor 3 and mobile applications executed by a nomadic device 53 that support technologies such as SYNC APPLINK provided by THE FORD MOTOR COMPANY. Another means of communication that can be used in this area is through free-space optical communication (such as Infrared Data Association (IrDA)) and non-standard consumer infrared (IR) protocols.

[0021] According to another embodiment, the nomadic device 53 includes a modem for voiceband or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the nomadic device 53 can speak through the device while data is transmitted. At other times, when the owner is not using the device, data transmission may utilize the entire bandwidth (in one example, from 290 Hz to 3.4 kHz). Although frequency division multiplexing may be and is still used for analog mobile communications between the vehicle 31 and the Internet, it has been largely replaced by hybrids of code-domain multiple access (CDMA), time-domain multiple access (TDMA), and space-domain multiple access (SDMA) for digital mobile communications.These are all ITU-IMT-2000 (3G) compliant standards and offer data rates of up to 2 mbs for stationary or walking users and up to 385 kbps for users in a moving vehicle 31. 3G standards are now being replaced by IMT-Advanced (4G), which offers 200 mbs for users in a vehicle 31 and 1 gbs for stationary users. If the user has a data plan associated with the nomadic device 53, it is possible that the data plan allows for broadband transmission and the system could use a much larger bandwidth (which would speed up data transmission). According to a further embodiment, the nomadic device 53 is replaced by a mobile communication device (not shown) installed in the vehicle 31. According to a further embodiment, the ND 53 may be a wireless LAN device operating, for example (and without limitation), over an 802.11g network (i.e.WiFi) or a WiMax™ network.

[0022] According to one embodiment, incoming data may be transmitted via a data-over-voice or data plan through the nomadic device 53, through the onboard BLUETOOTH™ transceiver, and into the processor 3 of the vehicle 31. In the case of certain temporary data, the data may be stored, for example, on the HDD or other storage medium 7 until the data is no longer required.

[0023] Additional sources that may connect to the vehicle 31 include a PND 54, such as with a USB connection 56 and / or an antenna 58, a vehicle navigation device 60 with a USB connection 62 or other connection, an on-board GPS device 24, or a remote navigation system (not shown) with connectivity to the network 61. USB is a class of serial network protocols. IEEE 1394 (FireWire™ (Apple), i.LINK™ (Sony), and Lynx™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1298 (Centronics connector), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Implementers Forum) form the basis of serial device-to-device standards. Most of the protocols can be implemented for either electrical or optical communication.

[0024] Furthermore, the CPU 3 may be in communication with a variety of other auxiliary devices 65. These devices 65 may be connected via a wireless connection 67 or a wired connection 69. The auxiliary device 65 may include, for example, but is not limited to, personal media players, wireless health devices, portable computers, and the like.

[0025] Also, or alternatively, the CPU 3 could be connected to a vehicle-based wireless router 73, for example, using a WiFi (IEEE 803.11) transceiver 71. This could enable the CPU 3 to be connected to remote networks within range of the local router 73.

[0026] In addition to example processes being performed by a vehicle computing system located within the vehicle 31, the example processes may be performed at least in part by one or more computing systems external to and in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (for example, and without limitation, a cellular phone) or a remote computing system (for example, and without limitation, a server) connected by the wireless device. These systems may collectively be referred to as vehicle-associated computing systems (VACS). According to certain embodiments, certain VACS components may perform certain portions of a process, depending on the particular implementation of the system.For example, and without limitation, if a process includes a step of sending or receiving information with a paired wireless device, it is likely that the wireless device will not perform the process because the wireless device would not "send and receive" information with itself. Those of ordinary skill in the art will understand when it is inappropriate to apply a specific VACS to a given solution. For all solutions, it is contemplated that at least the VCS 1 located within the vehicle 31 itself is capable of performing the example processes.

[0027] The Fig. 2A-2D show an illustrative system 200 for silent module software updates. Fig. 2A shows a vehicle module portion 202 of the illustrative system 200, Fig. 2B shows a cloud server section 204 of the system 200, Fig. 2C shows a gateway section 206 of the system 200 and Fig. 2D shows a data backend portion 208 of system 200. Vehicle module 202 of vehicle 31 may be configured to utilize the services of system 200 to perform updates to the software of vehicle 31. Cloud server 204 may be configured to handle requests for software updates from vehicle module 202 and provide software update downloads to vehicle module 202. Gateway 206 may be configured to provide controlled access to data backend 208 from other elements of system 200. Data backend 208 may be configured to provide data storage of software binaries and information of vehicle 31 secured behind gateway 206.

[0028] In particular, as with reference to Fig. 2A, a user or vehicle 31 may elect to have silent software updates performed by vehicle 31. To facilitate the selection process, in some examples, vehicle module 202 may provide a prompt to the user via visual display 4 and / or system speaker 13 requesting user authorization. Vehicle module 202 may be an information and entertainment module or other in-vehicle module for which silent software updates may be desirable. An example prompt may ask the user to consent to performing over-the-air updates via WiFi. Consent may be requested once but used across multiple update cycles.As another possibility, the user may select over-the-air updates using a nomadic device 53 paired with or otherwise associated with the vehicle 31 (e.g., by providing consent via a mobile application executed by the nomadic device 53, by sending a short message service (SMS) message from the nomadic device 53 to a specific number, by using an authorization web page accessible from the nomadic device 53, etc.). The vehicle module 202 may be configured, once authorization is given (e.g., by receiving keystrokes or spoken dialogue from the user), to generate a software update request 210 to prompt the vehicle module 202 to request software updates from modules of the vehicle 31.This request may be executed silently and without requiring user input. The request may also be executed upon the fulfillment of one or more conditions, for example, after a predetermined number of power-on events of the vehicle 31. If a connection (for example, a connection of the vehicle 31 to a Wi-Fi network) is unavailable at the power-on event, the vehicle module 202 may wait to execute the query specified by the software update request 210 at the next available connection.

[0029] The vehicle module 202 may be configured to collect information 212 related to the modules of the vehicle 31. The process of collecting data may be referred to as a query, and the collected data may be referred to as a query log 214. The information to be queried may include, in some non-limiting examples, the module name, module serial number, VIN, hardware part number, MAC address, part numbers of software applications, languages, and service packages installed on the module, available memory space on the module, and status information related to the installation of previous updates.The vehicle module 202 may be further configured to determine what information to collect using an optimized data identification list (ODL) file 216 that defines the specific information to be retrieved and where that information may be located. Specifically, the information to be collected may include data items from other engine control units or other controllers of the vehicle 31 and may be retrieved via the controller area network (CAN) or other communication architecture of the vehicle 31 that supports data transfer between controllers. The information may also include diagnostic trouble codes and other vehicle condition information that may be collected while the vehicle is being serviced by a dealer.The information may also include analytical data, including usage and log data, that provides insight into the use of various vehicle features. In some cases, the ODL file 216 may be installed as part of a software installation on the vehicle module 202, while in other cases, the ODL file 216 may have been previously received according to previously performed updates (described in further detail below). As another example, the vehicle module 202 may be configured to send the VIN of the vehicle 31 or other identifying information to the cloud server 204 and receive an ODL file 216 that defines what information to query for the particular VIN.

[0030] As an additional level of security, the system 200 may use message identifiers 218 to validate messages sent from the vehicle module 202 to the cloud server 204. In particular, the vehicle module 202 may send a request to the cloud server 204 to receive message identifiers 218 for use in sending verifiable messages to the cloud server 204. With reference to Fig. 2B, it should be noted that the cloud server 204 may receive 220 the request and generate or otherwise look up the message identifiers 218 to be used for the vehicle module 202. The cloud server 204 may encrypt 222 the message identifiers 218 and return the encrypted message identifiers 224 to the vehicle module 202. The message identifiers 218 may be used, for example, in situations where the cloud server 204 identifies a possible replay attack by a party attempting to repeat an intercepted message sent by a vehicle module 202. Accordingly, the cloud server 204 may validate messages received from the vehicle module 202 to ensure that they use message identifiers 218 that are valid for the system 200 and / or for the vehicle module 202 or the vehicle 31 (e.g., have not been previously used). To Fig. 2A, it should be noted that the vehicle module 202 may be further configured to receive the encrypted message identifiers 224, decrypt 226 the message identifiers 224 into message identifiers 218, and record the new message identifiers 228 for use by the vehicle module 202.

[0031] The vehicle module 202 may be further configured to include the query protocol 214 in a message 230 to be sent to the cloud server 204. In some cases, if no connection is available when the query protocol 214 is ready, the message 230 comprising the query protocol 214 may be passed to the cloud server 204 during the next available connection to the vehicle 31. The vehicle module 202 may be further configured to sign 232 the message 230 using a module key associated with the vehicle module 202. The vehicle module 202 may be further configured to perform secure encoding of the message 230, for example, by encrypting the message 230 according to a private key used in a protocol for transmitting messages to and from the vehicle 31.In general, messages sent from the vehicle module 202 to the cloud server 204 may be signed, encrypted, and encoded by the vehicle module 202, and messages received by the vehicle module 202 from the cloud server 204 may be authenticated, decrypted, and decoded by the vehicle module 202.

[0032] As one possible pass-through technique, the vehicle module 202 may be configured to send the message 230 to a nomadic device 53 (connected to the vehicle 31, for example, via BLUETOOTH™ or via Wi-Fi) to forward the message 230 to the cloud server 204. If the vehicle 31 is connected to the nomadic device 53, for example, via a Wi-Fi network, the vehicle module 202 may choose to send the message 230 to the nomadic device 53 via Wi-Fi. On the other hand, if the vehicle 31 is connected to the nomadic device 53 via BLUETOOTH™, the vehicle module 202 may provide the message 230 to the cloud server 204 via BLUETOOTH™ through the nomadic device 53. It should be noted that the transmission of other messages sent between the vehicle module 202 and the cloud server 204 may be similar.

[0033] With reference to Fig. 2B, it should be noted that the cloud server 204 may be configured to receive 234 the message 230 containing the query log 214 from the vehicle 31 either via the cellular phone or via WiFi. Regardless of which approach is used to receive the message 230, the cloud server 204 may be configured to validate the query log 214 and, if the log 214 is validated, request new updates 236 for the vehicle 31. The validations of the log 214 may include, for example, ensuring that the log 214 is in the appropriate format, that the log 214 has an appropriate length, and that the log 214 does not contain any invalid characters.

[0034] As an example of requesting updates 236, with reference to the Fig. 2C and Fig. 2D notes that the cloud server 204 may forward 238 the signed log 230 via the gateway 206 to the data backend 208 to enable the data backend 208 to record 240 the query log 230, to track the current installation status of the vehicle 31, such as the version 242 and configuration of the vehicle module 202 and other modules of the vehicle 31, and to obtain a copy of the query log 230 itself.

[0035] On Fig. Referring back to Figure 2B, according to another aspect of requesting updates 236, cloud server 204 may check for new updates 244 to the software of vehicle 31 that may be required. Cloud server 204 may be configured to review the current module configuration and the current version of vehicle module 202 indicated by query log 230 and determine whether software updates should be installed on vehicle 31. Based on the determination, cloud server 204 may identify binaries that should be installed on vehicle 31 to effect the identified updates. These binaries may be identified in a declaration 246. Furthermore, declaration 246 may specify network locations where each of the specified update binaries may be retrieved.For example, the declaration 246 may specify the network locations as URLs served by the cloud server 204. In some cases, the binary items may include new versions of files to be installed, while in other cases, the binary items may include incremental updates to be applied to currently installed binary items to upgrade the currently installed binary items from one version to a next version.

[0036] To identify the software updates, the cloud server 204 may be configured to compare the current module versions indicated in the query log 230 with the latest version of the modules compatible with the vehicle module 202. The cloud server 204 may further be configured to identify, for any components that should be updated, any additional dependencies that these updated versions may require. These additional dependencies may be further added to the declaration 246.

[0037] The cloud server 204 may provide a message to the vehicle 31 in response to the identification of the software updates. The message may include the declaration 246 and additional information, such as one or more private keys 248 that may be used by the vehicle 31 to decrypt software updates to be downloaded according to the declaration 246, and may include a response indicating the current or latest version information 250. The current or latest version information 250 may, for example, include the updated ODL 250, which includes new definitions for what information to query the next time an update is performed.

[0038] The cloud server 204 may, as a further part of the request for new updates 236, perform encryption 252 of the response returned to the vehicle module 202. For example, the cloud server 204 may perform encoding / encryption 252 of requests according to signature keys 254 received from the data backend 208 and stored 256 by the cloud server 204. With reference to the Fig. 2C and Fig. 2D, it should be noted that the data backend 208 may in turn be configured to handle key signature requests 260 and provide the signature key 254 to the cloud server 204, which are forwarded 258 via the data gateway 206. On Fig. Referring back to Figure 2B, the cloud server 204 may accordingly, using the signature keys 254, return 262 the signed, coded, and encrypted response to the requesting vehicle module 202 in response to the vehicle module 202's original request for updates sent at 232, as shown in Fig. 2A. Although it is returned in response thereto at 262, it should be noted that the vehicle module 202 does not need to synchronously wait or stand by until the declaration 246 is received in response to the original request. As discussed in detail below, beginning with element 284, the vehicle module 202 may use the information contained in the response to perform the software update.

[0039] For processing the data backend 208 in Fig. Returning to Figure 2D, the data backend 208 may upload 264 updated binary elements to the cloud server 204 to be downloaded from the vehicle module 202. As one capability, the data backend 208 may be configured to periodically (e.g., daily, weekly, monthly) upload 264 binary elements to the cloud server 204. As another capability, the data backend 208 may be configured to provide updates to the cloud server 204 based on an identified need (e.g., to correct a software bug, problem, or emergency, in response to a request for software updates for the vehicle 31, etc.).

[0040] With reference to the Fig. 2B and Fig. 2D, it should be noted that to provide security for the binary elements during network transport to the cloud server 204, the binary elements may be transmitted as transport-encrypted binary elements 266 in a transport encryption format. The cloud server 204 may accordingly load 268 the binary elements 266 in a decrypted format decoded according to the transport protocol. Because the binary elements are not in an encrypted format once received via transport, the cloud server 204 may be configured to encrypt 270 the binary elements for storage as generic encrypted binary elements 272, where the generic binary elements are encoded using private keys 274 that are not associated with a key for a particular vehicle 31 or VIN.Accordingly, the encrypted binary elements 272 may be decrypted using private keys 274 provided to the vehicle modules 202. The encrypted binary elements 272 may accordingly be made available at generic binary network locations 276, which may be specified by the declaration 246 provided to the vehicle 31. In some cases, the binary elements being requested are signed in a manner to be associated with a private key 274 of a particular requestor or downloader (e.g., the vehicle 31). These requests may be referred to as electronic serial number (ESN)-signed subrequests 280 and may be executed upon generation and storage of the signed binary element 282.For example, cloud server 204 may determine dynamic signed binary URLs 276 for dynamic signed binary items 272 and generic signed binary URLs 276 for generic signed binary items 272. As part of the signing and encryption processing 270 and / or the signed binary item generation and storage processing 282, the binary URL 276 information may be forwarded 278 via gateway 206 to data backend 208 to enable data backend 208 to be informed of the locations of the loaded binary items.

[0041] With reference to Fig. 2A, in response to element 282, the vehicle module 202 may receive the response comprising a signed declaration 246, private keys 248, and the updated ODL 250, and may authenticate, decode, and decrypt 284 the response. Accordingly, the vehicle module 202 may extract the included declaration 246, the included private keys 248, and the included ODL 250. The vehicle module 202 may further store 286 the declaration 246, the private keys 248, and the ODL 250. The vehicle module 202 may be configured to download 288 the specified binary elements 272 based on the declaration 246. For example, the vehicle module 202 may be configured to download binary elements 272 from the cloud server 204 by accessing network locations specified by the declaration 246.The vehicle module 202 may be configured to decrypt 290 the binary elements 272 into decrypted binary elements 292 for installation using the private keys 248.

[0042] In some cases, the vehicle module 202 may request a binary element from the cloud server 204 that the cloud server 204 does not host. With reference to Fig. 2B, it should be noted that the cloud server 204 may detect the memory fetch error 294, for example, after receiving a request directed to a URL or other network location for which the cloud server 204 does not host a file. In response to the detection, the cloud server 204 may retrieve 296 the missing binary item. As one option, the cloud server 204 may provide the ESN and / or the partial number 298 of the missing binary item to the gateway 206, which in turn may forward 300 the requested number 298 to the data backend 208. The data backend 208 may accordingly perform a fetch 302 of the missing binary item, similar to loading 264 binary items to the cloud server 204 based on a check for new updates 244.

[0043] To Fig. Returning to Figure 2A, the vehicle module 202 may also maintain a download status 304 indicating the progress of the vehicle module 202 in retrieving the software updates specified by the declaration 246. To enable the data backend 208 to be automatically notified of the download status, the vehicle module 202 may provide a download status 304 to the cloud server 204. Accordingly, the vehicle module 202 may sign, encrypt, and encode 306 the status 304 similarly to that discussed above with respect to providing the signed query logs 230 in element 232. The signed status 308 may be provided to the cloud server 204, which may receive the request 310, as in Fig. 2B. The cloud server 204 may retrieve 312 the decrypted status and store 314 the decrypted status 316 to enable the system 200 to track the progress of the vehicle module 202. Accordingly, the vehicle module 202 may provide the cloud server 204 with error information for binary items that could not be downloaded or that could be downloaded but could not be decrypted using the private keys 248. The cloud server 204 may, in some cases, forward updates to the status 304 to the data backend 208 (not shown) to enable the data backend 208 to remain updated with the download status 304 of the vehicle module 202.

[0044] With reference to Fig. 2A, it should be noted that the vehicle module 202 may be configured to install 318 the downloaded and decrypted binaries 292. To avoid disrupting the current version of the software installed in the vehicle module 202, the vehicle module 202 may be configured to perform the installation for a second installation of the vehicle module 202 that is different from the currently active installation from which the vehicle module 202 was booted. The installation of the modules for the second installation may occur silently, without requiring any input from the user. Similar to downloading the binaries, as modules are installed in the vehicle module 202, the vehicle module 202 may be configured to provide installation status updates 320 to the cloud server 204.The cloud server 204 may forward the status updates to the data backend 208 to enable the data backend 208 to remain updated with the status 320 of the installed module versions of the vehicle module 202.

[0045] The vehicle module 202 may be configured, after completing the installation of the modules specified by the declaration, to perform an additional query of the modules of the vehicle 31 to generate a query log 322. Similar to what was described above with respect to element 294, the vehicle module 202 may generate the query log 322, but this time using the received ODL 250, thereby providing an updated definition of what information to query for the currently executing software update. Also, similar to what was discussed above, the vehicle module 202 may be configured to sign, encode, and provide the query log 326 to the cloud server 204, which may, in turn, provide the query log 326 to the data backend 208 (similar to query log 230).Accordingly, the data backend 208 can be automatically updated with respect to the installation status of the vehicle 31 without requiring user HMI interaction.

[0046] The vehicle module 202 may also be configured to reconfigure the vehicle module 202 after the software installation is complete to indicate that the second installation is the new active installation (e.g., a partition to be booted). Accordingly, the software updates may be made available for use by the vehicle 31 the next time the vehicle module 202 is started, e.g., the next time it is powered on. In some cases, the user may be notified that the software installation is complete. Furthermore, after the vehicle 31 successfully boots into the second installation, the first installation may be updated to the new software version. Accordingly, the first installation may then be available for silent installation of future software updates for the vehicle 31.

[0047] With reference to Fig. 2B, an operator 328 of system 200 may use system 200 to generate reports 330 relating to the current module versions of the software installed on vehicle 31(s) 31, which reports may be viewed 332 by operator 328. In one example, reports 330 may include information relating to the status of vehicle updates for a vehicle 31 (e.g., queried according to VIN or other vehicle-specific identifier), which may indicate whether vehicle 31 has finished downloading software updates, finished installing software updates, or encountered problems when attempting to perform software updates using system 200. In another example, reports 330 may include statistics relating to which vehicles 31 are at which installed version levels for various modules.

[0048] Fig. 3 shows an example process 400 for updating vehicle software. The example process 400 may be executed, for example, by a vehicle 31 communicating with a cloud server 204.

[0049] At block 402, the vehicle 31 determines that the vehicle 31 should check for software updates. For example, after determining that a predetermined number of power-on cycles have been completed by the vehicle 31 and / or a period of time has elapsed, and further that a network connection is available for communication with a cloud server 204 (e.g., via a connected nomadic device 53), the vehicle module 202 of the vehicle 31 may determine that the vehicle 31 should check for software updates.

[0050] In block 404, the vehicle 31 generates a query log 214. The query log 214 may include version information of at least one software module installed on the vehicle 31. The information to be queried may include, in some non-limiting examples, the module name, module serial number, VIN, hardware part number, MAC address, part numbers of software applications, languages, and service packages installed on the module, available memory space on the module, and status information regarding the installation of previous updates. The vehicle module 202 may be configured to generate the query log 214 according to an ODL 216 that defines what information to query and where that information may be located. The information to be queried may include, for example, requested identifiers from the vehicle module 202 and other ECUs within the vehicle.The information may be collected via the CAN or another vehicle network and included in the query log 214. In some cases, the ODL 216 may be received as part of a software installation on the vehicle module 202, while in other cases, the ODL 216 may have been previously received according to previously performed updates, for example, as ODL 250.

[0051] In block 406, the vehicle 31 provides the challenge log 214 to the cloud server 204. For example, the vehicle module 202 may encrypt the challenge log 214 and send a signed challenge log message 230 to the cloud server 204.

[0052] In block 408, the vehicle 31 receives a declaration 246 from the cloud server 204. For example, in response to the message 230, the vehicle module 202 of the vehicle 31 may receive a signed declaration 246 specifying one or more binaries to be downloaded and installed by the vehicle 31, as well as other information to be used when performing the update, such as the updated ODL 250 and private keys 248 for decrypting the binaries to be downloaded and installed.

[0053] In block 410, the vehicle 31 downloads the binary elements specified by declaration 246. For example, the vehicle module 202 of the vehicle 31 may download encrypted binary elements 272 from the cloud server 204 at network locations specified by declaration 246 and decrypt the binary elements 272 into decrypted binary elements 292 according to the received private keys 248.

[0054] In block 412, the vehicle 31 installs the downloaded binary elements into an inactive installation. For example, the vehicle module 202 may use software executing in the active installation to install the decrypted binary elements 272 into an inactive installation, which is also the active installation in the current software version. This may allow the installation to occur without impacting the functionality of the vehicle module 202.

[0055] At block 414, the vehicle 31 sets the inactive installation to the new active installation. If the installation is successful, the vehicle module 202 may, for example, change the boot information for the vehicle module 202 to designate the inactive installation as the new active installation at the next boot. In some cases, the vehicle module 202 may force a reboot of the vehicle module 202, while in other cases, the vehicle module 202 may allow the reboot to be delayed until the next time the vehicle module 202 is booted (for example, at the next power cycle of the vehicle 31). After the next boot, if the software update is successful, the vehicle module 202 may update the previous active installation to also match the new version of the software.However, if the reboot fails, the vehicle module 202 may be able to gracefully fall back to the previously active installation (and, in some cases, also revert the failed changes to the inactive installation). After block 414, the process 400 ends.

[0056] While exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the words used in the description are for the purpose of explanation and not limitation, and it is understood that various changes may be made without departing from the spirit and scope of the invention. In addition, the features of various implementing embodiments may be combined to form further embodiments of the invention.

Claims

[1] System which includes: a data identification list defining which information is to be included in a query log and at which of a plurality of vehicle control devices this information is located, the data identification list being received as part of a software installation downloaded from a server to the vehicle; and at least one control device of the vehicle which is programmed to to generate the query protocol based on the data identification list, Send query log to the server, Receiving a statement from the server specifying network locations of software updates determined according to the query protocol, Installing update binaries retrieved from network locations to an inactive installation of multiple storage installations and Set the inactive installation as an active installation after a vehicle restart instead of another of the storage installations. [2] The system of claim 1, wherein the installation comprises either a storage partition or a collection of files within a partition. [3] The system of claim 1, wherein the at least one controller is further configured to perform the following: Generating the query log to include at least one of the following: (i) current status information of at least one software module installed on the vehicle and (ii) diagnostic problem codes of at least one software module installed on the vehicle and Send the query log to the server. [4] The system of claim 3, wherein the at least one controller is further configured to generate the query log after determining at least one of the following: (i) a predetermined number of power-on cycles has been completed by the vehicle; and (ii) a predetermined period of time has elapsed since the query log was generated. [5] The system of claim 1, wherein the at least one controller is further configured to perform at least one of the following steps: (i) Providing a message in a vehicle user interface that the software will be updated upon reboot, (ii) receiving an indication of a selection from the vehicle user interface before allowing a silent software update to be performed, and (iii) receiving an indication of a selection from a user interface of a nomadic device in communication with the vehicle before allowing a silent software update to be performed. [6] The system of claim 1, wherein the at least one controller is further configured to update another of the storage installations in accordance with the software updates performed on the activated installation. [7] Method which is carried out by at least one control device of a vehicle, the method comprising: Receiving from a server by a vehicle, a data identification list, which defines which information is to be included in a query log and where the information is located in an active software installation; Generating the query log; Sending the query log to the server; Receive, in response, a statement whereby network locations of Software updates are specified, which are determined according to the query protocol; Installing update binaries retrieved from the network locations to an inactive software installation of multiple storage installations; and setting the inactive software installation as an active software installation after vehicle reboot in place of another storage installation. [8] A non-transitory computer-readable storage medium storing instructions which, when executed by at least one control device of a vehicle, cause the at least one control device to perform the following: Receiving from a server by the vehicle, a data identification list, which defines which information is to be included in a query log and which of several vehicle control devices this information is located on; Generating the query protocol based on the data identification list; Sending the query log to the server; Receiving from the server a statement specifying network locations of software updates determined according to the query protocol; Installing update binaries retrieved from network locations to an inactive installation of multiple storage installations; and setting the inactive installation as an active installation after a vehicle restart instead of another storage installation.

Images