CN108268264B - Pre-shutdown exchange verification - Google Patents
Pre-shutdown exchange verification Download PDFInfo
- Publication number
- CN108268264B CN108268264B CN201711475936.XA CN201711475936A CN108268264B CN 108268264 B CN108268264 B CN 108268264B CN 201711475936 A CN201711475936 A CN 201711475936A CN 108268264 B CN108268264 B CN 108268264B
- Authority
- CN
- China
- Prior art keywords
- vehicle
- electronic control
- control unit
- storage area
- vehicle electronic
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
- 238000012795 verification Methods 0.000 title abstract description 9
- 230000004044 response Effects 0.000 claims abstract description 18
- 238000000034 method Methods 0.000 claims description 34
- 238000004891 communication Methods 0.000 claims description 15
- 230000010365 information processing Effects 0.000 claims description 3
- 230000004913 activation Effects 0.000 claims 2
- 239000000725 suspension Substances 0.000 claims 1
- 230000008569 process Effects 0.000 description 21
- 238000009434 installation Methods 0.000 description 13
- 230000006870 function Effects 0.000 description 10
- 238000004590 computer program Methods 0.000 description 5
- 230000005055 memory storage Effects 0.000 description 5
- 238000013459 approach Methods 0.000 description 2
- 230000005540 biological transmission Effects 0.000 description 2
- 238000002485 combustion reaction Methods 0.000 description 2
- 230000003993 interaction Effects 0.000 description 2
- 238000007726 management method Methods 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 230000000737 periodic effect Effects 0.000 description 2
- 238000012360 testing method Methods 0.000 description 2
- 240000005020 Acaciella glauca Species 0.000 description 1
- RYGMFSIKBFXOCR-UHFFFAOYSA-N Copper Chemical compound [Cu] RYGMFSIKBFXOCR-UHFFFAOYSA-N 0.000 description 1
- 238000004422 calculation algorithm Methods 0.000 description 1
- 230000001413 cellular effect Effects 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 238000012790 confirmation Methods 0.000 description 1
- 238000010276 construction Methods 0.000 description 1
- 238000001816 cooling Methods 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 238000011161 development Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 239000000835 fiber Substances 0.000 description 1
- 239000000446 fuel Substances 0.000 description 1
- 238000010438 heat treatment Methods 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012986 modification Methods 0.000 description 1
- 230000004048 modification Effects 0.000 description 1
- 238000005192 partition Methods 0.000 description 1
- 230000002085 persistent effect Effects 0.000 description 1
- 235000003499 redwood Nutrition 0.000 description 1
- 238000011160 research Methods 0.000 description 1
- 238000012546 transfer Methods 0.000 description 1
- 230000001960 triggered effect Effects 0.000 description 1
- 230000000007 visual effect Effects 0.000 description 1
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/65—Updates
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/60—Software deployment
- G06F8/61—Installation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
- G06F21/57—Certifying or maintaining trusted computer platforms, e.g. secure boots or power-downs, version controls, system software checks, secure updates or assessing vulnerabilities
- G06F21/575—Secure boot
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/70—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer
- G06F21/78—Protecting specific internal or peripheral components, in which the protection of a component leads to protection of the entire computer to assure secure storage of data
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/70—Software maintenance or management
- G06F8/71—Version control; Configuration management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/4401—Bootstrapping
- G06F9/4406—Loading of operating system
- G06F9/4408—Boot device selection
-
- B—PERFORMING OPERATIONS; TRANSPORTING
- B60—VEHICLES IN GENERAL
- B60R—VEHICLES, VEHICLE FITTINGS, OR VEHICLE PARTS, NOT OTHERWISE PROVIDED FOR
- B60R16/00—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for
- B60R16/02—Electric or fluid circuits specially adapted for vehicles and not otherwise provided for; Arrangement of elements of electric or fluid circuits specially adapted for vehicles and not otherwise provided for electric constitutive elements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/03—Indexing scheme relating to G06F21/50, monitoring users, programs or devices to maintain the integrity of platforms
- G06F2221/033—Test or assess software
Abstract
The invention relates to pre-shutdown exchange verification. A system comprising: a first storage area, a second storage area, and a vehicle Electronic Control Unit (ECU). The vehicle electronic control unit is configured to: downloading a software update received from a server to the first storage area; before the vehicle is turned off, when the ignition switch is turned off, attempting restarting of the vehicle electronic control unit; in response to successful boot-up of the vehicle electronic control unit to the first storage area, the first storage area is validated as active for boot-up instead of the second storage area.
Description
Technical Field
Aspects of the present disclosure relate to vehicle software exchange verification performed prior to completion of a vehicle shutdown.
Background
The vehicle may be driven to a dealer and maintained by a technician to update the software of the vehicle components. The technician may utilize a system that tracks the respective software levels of the components within the vehicle and the available software updates. The technician may manually apply the software updates indicated by the system and record any changes back into the system. The software update may be performed when the vehicle is not operating and is located at a dealer.
Disclosure of Invention
In a first exemplary embodiment, a system includes: a first storage area; a second storage area; a vehicle electronic control unit configured to: downloading a software update received from a server to the first storage area; before the vehicle is turned off, when the ignition switch is turned off, attempting restarting of the vehicle electronic control unit; in response to successful boot-up of the vehicle electronic control unit to the first storage area, the first storage area is validated as active for boot-up instead of the second storage area.
In a second exemplary embodiment, a system includes: a remote information processing control unit; a plurality of vehicle electronic control units in communication with the telematics control unit over a vehicle bus, one of the plurality of vehicle electronic control units configured to: restarting the vehicle electronic control unit to the first storage area using a software update received from the telematics control unit when the ignition switch is turned off; in response to a successful reboot using the first storage area, the first storage area is validated as active for booting instead of the second storage area.
In a third exemplary embodiment, a method for over-the-air software updating includes: upon turning off of the ignition switch prior to turning off of the vehicle, the first storage area, but not the second storage area, is identified as active for starting in response to successful reboot of the vehicle electronic control unit to the first storage area, the first storage area including the downloaded software update received from the remote server.
Drawings
FIG. 1 illustrates an example system for providing software updates to a vehicle;
FIGS. 2A and 2B show examples of programmable memory for installation of software updates for a vehicle ECU;
FIGS. 2C and 2D show alternative examples of programmable memory for installation of software updates for a vehicle ECU;
FIG. 3 illustrates an example data flow for installing a software update to an inactive memory area of one of the vehicle ECUs;
fig. 4 illustrates an example process for performing exchange verification before a vehicle shutdown is completed.
Detailed Description
As 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 exaggerated or minimized to show details of particular 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.
Software and firmware (collectively referred to herein as software) play an increasingly important role in modern vehicles. The increasingly important roles of software have led to potential increases in efficiency problems, functional changes and security drawbacks that would be addressed in a non-operating (out in the field) vehicle. In many modern vehicle systems, a vehicle Electronic Control Unit (ECU) is configured with the ability to undergo a firmware update after deployment. Updating firmware may be one solution to improve the security of software installed to an ECU of a vehicle. However, an incorrect firmware update may cause an unauthorized or malicious software update to be installed to the vehicle ECU. Such improper updating may result in failure of the vehicle ECU or unauthorized vehicle operation.
The improved software update process may take two phases: a first stage in which a software update is downloaded from an update server and provided to a vehicle ECU for installation to an inactive store; a second stage in which swapping is performed to allow the vehicle ECU to swap to install the software update to the inactive memory area. By using such a two-stage process, software updates can be performed on the inactive memory area over time without affecting the function of the ECU operation using the active memory area.
The swap function may be performed during an ECU reset event in response to new software being loaded into the inactive memory area and verified as ready for swap. The reset event may require a small amount of down time (downtime) for the vehicle. As one possibility, the update of the inactive memory area swap to a new active memory area may be written to the ECU during the ignition switch off. However, if there is a problem with the exchanged or new software, the problem may not be detected until the next ignition switch on cycle when the customer is ready to drive.
An improved switching method may be employed to avoid the potential complexity of detecting an error at the next ignition switch turn-on. When the ignition switch is turned off before the completion of turning off the vehicle, the ECU may restart with new software to ensure that the ECU is operating as intended. Then, if the ECU is properly restarted, the exchange may be confirmed to continue the normal shut down sequence before shutting down the ECU again. On the other hand, if a problem is identified with the updated software, the ECU may automatically switch back to the previous software and/or notify the telematics control unit of any errors to report back to the update server for error handling. Thus, by testing the new software when the ignition switch is turned off, potential software problems can be detected before the next ignition switch turn-on cycle. Further aspects of the two-stage update process are described in detail below.
FIG. 1 illustrates an example system 100 for providing software updates 116 to a vehicle 102. The system 100 may include a telematics control unit 108, with the telematics control unit 108 communicating with an update server 120 over a network 110 (e.g., via an onboard modem, or via a data channel provided by a mobile device of a vehicle occupant). The update server 120 may be in communication with a data store 118, the data store 118 configured to store software updates 116 for download and vehicle configuration information 114 about the vehicle 102. The telematics control unit 108 may include a software update manager 112, with the software update manager 112 configured to download software updates 116 with the telematics control unit 108 for installation to the telematics control unit 108 or other ECUs 104 of the vehicle 102. Although the example system 100 is illustrated in fig. 1, the example components illustrated are not intended to be limiting. In practice, system 100 may have more or fewer components and additional or alternative components and/or implementations may be used. As some alternative examples, the functionality of the software update manager 112 may be implemented by another ECU other than the telematics control unit 108, such as an onboard communication ECU (e.g., ford SYNC Accessory Protocol Interface Module (APIM), gateway module between the vehicle buses 106, etc.).
The vehicle 102 may include various types of automobiles, hybrid utility vehicles (CUVs), sport Utility Vehicles (SUVs), trucks, recreational Vehicles (RVs), boats, airplanes, or other mobile machines for transporting people or cargo. In many cases, the vehicle 102 may be driven by an internal combustion engine. As another possibility, the vehicle 102 may be a Hybrid Electric Vehicle (HEV) driven by both an internal combustion engine and one or more electric motors, such as a Series Hybrid Electric Vehicle (SHEV), a Parallel Hybrid Electric Vehicle (PHEV), or a parallel/series hybrid electric vehicle (PSHEV). Since the type and configuration of the vehicle 102 may vary, the performance of the vehicle 102 may vary accordingly. As some other possible approach, the vehicle 102 may have different capabilities with respect to passenger capacity, traction capability and performance, and storage capacity.
The vehicle 102 may include a plurality of Electronic Control Units (ECUs) 104, the plurality of ECUs 104 being configured to perform and manage various functions of the vehicle 102 under power from a vehicle battery and/or powertrain. As depicted, the example vehicle ECU 104 is represented as discrete ECUs 104-a through 104-H. However, the vehicle ECU 104 may share physical hardware, firmware, and/or software such that functions from multiple ECUs 104 may be integrated into a single ECU 104. Alternatively, the functionality of a plurality of such ECUs 104 may be distributed among a plurality of ECUs 104. The vehicle ECU 104 may include various components of the vehicle 102 configured to receive updates of associated software, firmware, or configuration settings.
As some non-limiting examples of the vehicle ECU 104: the engine control ECU 104-a may be configured to provide control of engine operating components; the transmission control ECU 104-B may be configured to utilize the sensor data and data from the engine control ECU 104-a to calculate how and when to change gears in the vehicle 102 for optimal performance, fuel economy, and shift quality; the body control ECU104-C may be configured to manage various power control functions such as external lighting, internal lighting, keyless entry, remote start, and access point status verification; the radio transceiver ECU 104-D may be configured to communicate with a key fob, a mobile device, or other local device of the vehicle 102; the entertainment control unit 104-E may be configured to support voice command interactions and Bluetooth interactions with the driver and the driver's portable device; the climate control management ECU 104-F may be configured to provide control of heating and cooling system components (e.g., compressor clutches, blower fans, temperature sensors, etc.); the Global Positioning System (GPS) ECU 104-G may be configured to provide vehicle location information; a human-machine interface (HMI) ECU 104-H may be configured to receive user input and provide vehicle status information to a driver via various buttons or other controls.
The vehicle bus 106 may include various communication methods available between the vehicle ECUs 104. The vehicle bus 106 may also support communication between the telematics control unit 108 and the vehicle ECU 104. As some non-limiting examples, the vehicle bus 106 may include one or more of a vehicle Controller Area Network (CAN), ethernet, and a media-oriented system transfer (MOST) network. It should be noted that the bus topology shown is merely an example, and that other numbers and arrangements of vehicle buses 106 may be used.
The telematics control unit 108 (or TCU 108) may include network hardware configured to facilitate communications between the vehicle ECUs 104 and with other devices of the system 100. For example, telematics control unit 108 may include or utilize an onboard cellular modem to facilitate communications over communications network 110. The network 110 may include one or more interconnected communication networks, such as the Internet, a cable distribution network, a satellite link network, a local area network, a wide area network, and a telephone network, as some non-limiting examples. As another example, the telematics control unit 108 may utilize one or more of bluetooth, wi-Fi, and wired USB network connections to facilitate communication with the communication network 110 via the user's smartphone or other mobile device.
The software update manager 112 may be configured to: the vehicle bus 106 is accessed for communication with the vehicle ECU 104 using the telematics control unit 108. When the vehicle 102 is assembled, the vehicle 102 may include various hardware components and software components. At or after assembly, the software update manager 112 may be configured to query the vehicle ECU 104 of the vehicle 102 for presence and version information of at least a portion of the hardware components and software components.
The software update manager 112 may also be configured to communicate with the update server 120 over the network 110 using the telematics control unit 108. Using the queried information and additional information identifying the particular vehicle 102, the software update manager 112 may communicate via the network 110 to establish an account with the update server 120. As some non-limiting examples, additional information identifying the vehicle 102 may include: VIN information published on the CAN bus, or Subscriber Identity Module (SIM) information (such as international mobile station equipment identity (IMEI)) of a modem of the telematics control unit 108. The update server 120 may receive these communications from the vehicle 102 and may maintain a software data store 118 of the vehicle configuration information 114 relating to the hardware configuration and software (e.g., firmware, etc.) version of the received identifier linked to the vehicle 102.
The software data storage area 118 may also be configured to store software updates 116 that may be provided to the vehicle 102. The software update 116 may include changes to the software or settings of the vehicle 102 to address issues with or provide improved functionality to the current software. For example, the software update 116 may include updated configuration settings for one or more vehicle ECUs 104 and/or updated versions of software or firmware to be installed on one or more vehicle ECUs 104. In some cases, the software update 116 may include a single portion, while in other cases, the software update 116 may be organized into multiple sub-portions, partitions, or blocks, wherein all sub-portions may be downloaded to complete the entire software update 116 to be installed. In some examples, the software update 116 may be initiated by a vendor (e.g., a vendor of the vehicle ECU 104) or by a vehicle manufacturer. In some cases, the software update 116 may be encrypted, while in other cases, the software update 116 may not be encrypted.
The software data storage area 118 may also be configured to store additional information regarding the software update 116. For example, the software data store 118 may be configured to hold optional/required flags regarding software updates 116 that allow the vehicle 102 to determine which software updates 116 are required and which software updates 116 are optional. As another example, the software data store 118 may be configured to hold an indication of which vehicle ECUs 104 are associated with which software updates 116. The software data storage area 118 may also store information indicating the compatibility of the software update 116 with a vehicle model or configuration. For example, a stored entry for the software update 116 may indicate that the software update 116 is compatible with a particular make and model of vehicle 102, or that the software update 116 is dependent on a version of another vehicle ECU 104 (the version being a particular software version or versions).
The update server 120 may include one or more devices configured to provide the software updates 116 stored by the data store 118 to the vehicle 102. For example, the update server 120 may be configured to receive an update request for available software updates 116 from the vehicle 102. The update request may include vehicle information to allow the update server 120 to query the data store 118 for software updates 116 applicable to the currently configured vehicle 102. The update server 120 may provide an indication of the software update 116 (or the software update 116 itself) that may be downloaded and installed in response to the update request to update the requesting vehicle 102. The update server 120 may also be configured to provide the software update 116 to a device requesting to download the software update 116 according to the provided indication.
The software update manager 112 may also be configured to manage the installation of software updates 116. For example, the vehicle 102 may receive a command from a user requesting the inspection software update 116. As another possibility, the vehicle 102 may trigger a periodic check for new software updates 116. When the periodic check is triggered, the vehicle 102 may be configured to send an update request to the update server 120 to query whether the software update 116 for the vehicle 102 is available. For example, the vehicle 102 may query the update server 120 using the vehicle information (or, if the data store 118 holds current vehicle information, using an identifier of the vehicle 102), and may receive a response from the update server 120 indicating whether new software updates 116 for the vehicle 102 are available (e.g., a link or other identifier for the downloaded software updates 116 for the vehicle 102). For example, the determination of whether a new update is available may be based on configuration information 114 saved for the requesting vehicle 102. If the response to the vehicle 102 indicates that the software update 116 is available to the vehicle 102, the vehicle 102 may also be configured to download the indicated software update 116 using the telematics control unit 108, or otherwise queue the software update 116 to be downloaded.
The software update manager 112 may also be configured to provide a user interface to the user for managing the software updates 116. For example, the software update manager 112 may be configured to provide a prompt to the user (e.g., via a display or speaker of the user interface module 104-H) for informing the user that the software update 116 is available and requesting permission to install the software update 116. As another possibility, the software update manager 112 may be configured to: when the software update 116 is available (e.g., downloaded), an indication of the available update is provided within the instrument cluster of the vehicle 102.
To enhance the security of the downloading of the software updates 116 to the vehicle 102, the system 100 may utilize an asymmetric encryption algorithm for verifying the received information. For example, the data store 118 may store a private key 122 for signing messages sent from the update server 120 to the vehicle 102, and the vehicle ECU 104 may store a public key 124 corresponding to the private key 122 that may be used to ensure that messages sent from the update server 120 are indeed signed. The public keys 124 of the engine control ECU 104-a are shown as an example in fig. 1, but it should be noted that other ECUs 104 of the vehicle 102 also maintain their respective public keys 124. In particular, the telematics control unit 108 may also have its own separate public key 124 for updating the telematics control unit 108 as another vehicle ECU, although the public key 124 for the telematics control unit 108 may be suitable for updating the telematics control unit 108 and not for updating other ECUs 104. Variations are possible in which a symmetric key may be used instead of the private key 122/public key 124 pair.
Once the user confirms that the software update 116 should be installed and/or upon other triggers of the vehicle, such as ignition on or ignition off, the software update manager 112 may be configured to initiate various functions useful to support software updates of the vehicle ECU 104. For example, the software update manager 112 may be configured to: the software update mode is invoked by providing a message from the software update manager 112 to the vehicle module ECU 104 via the vehicle bus 106. The software update manager 112 may also be configured to: the software update 116 is provided to the vehicle ECU 104 identified by the software update 116 as the recipient of the software update 116 for verification and installation. The receiving vehicle ECU 104 may accordingly receive the software update 116 for compatibility testing and installation.
In some systems of the vehicle 102, the installation of the software update 116 may require that the vehicle 102 not be operational because the storage device (e.g., flash memory) used by the vehicle ECU 104 to store the executed software cannot be simultaneously operated and refreshed with the software update 116. However, in some cases, the vehicle ECU 104 may include multiple storage areas such that the software update 116 may be installed to one storage area of the vehicle ECU 104, while the current version of software may be executed from another storage area of the vehicle ECU 104.
Fig. 2A shows an example of a programmable memory circuit for the vehicle ECU 104 having a plurality of memory areas 202. As shown, the programmable memory circuit may include an active memory area 202-A, an inactive memory area 202-B, an active processor 204-A, an update processor 204-B, and a switch 206. The active storage area 202-A may include a software installation 208-A located at a software version 210-A and the inactive storage area 202-B may include a software installation 208-B located at a software version 210-B. The programmable memory circuit may also include or otherwise have access to a public key 124 of the vehicle ECU 104, the public key 124 may be used to help verify the received software update 116. In a first state of the switch 206 (shown in FIG. 2A), the active processor 204-A may be coupled to the active storage area 202-A and the update processor 204-B may be coupled to the inactive storage area 202-B. In the second state of the switch 206 (as shown in FIG. 2B), the switch 206 may swap which memory area 202 is the active memory area 202-A and which memory area 202 is the inactive memory area 202-B. Accordingly, in the second state of the switch 206, the active processor 204-A may be connected to a memory area that was previously an inactive memory area 202-B of the new active memory area 202-A, and the update processor 204-B may be connected to a memory area that was previously an active memory area 202-A of the new inactive memory area 202-B. Thus, by toggling the switch 206, the programmable memory circuit can toggle which of the software installations 208-A or 208-B is to be executed by the active processor 204-A.
For example, the vehicle ECU 104 may execute a software installation 208-A installed to the active storage area 202-A for operation of the vehicle 102 using the active processor 204-A while installing the software update 116 as a software installation 208-B of the inactive storage area 202-B using the update processor 204-B. In such an example, while the software update 116 is being installed, the vehicle ECU 104 may continue to utilize the active processor 204-a connected to the memory area 202-a without interruption to continue executing the software installation 208-a.
When the vehicle ECU 104 that has installed the software update 116 to the inactive memory area 202-B receives an acknowledgement for exchanging the installed software update 116, the vehicle ECU 104 may be configured to toggle the switch 206 so that the inactive memory area 202-B becomes the new active memory area 202-a and the current active memory area 202-a becomes the new inactive memory area 202-B. This switching of the switch 206 may be performed at the next initialization event of the vehicle 102. As some non-limiting examples, the initialization event may include a vehicle ignition switch on, a vehicle ignition switch off, and/or a vehicle ECU 104 re-initialization event.
As another example, fig. 2C and 2D illustrate a programmable memory circuit including an active memory area 202-a, an inactive memory area 202-B, and a processor 204. In contrast to the processors 204-A and 204-B of FIGS. 2A and 2B, the processor 204 may perform the execution of the software installation 208-A of the active storage area 202-A and the update of the software installation 208-B using the inactive storage area 202-B. The programmable memory circuit may also include or otherwise access a public key 124 of the vehicle ECU 104, the public key 124 may be used to help verify the received software update 116. Similar to fig. 2A and 2B, the processor 204 in fig. 2C may switch which memory area 202 is the active memory area 202-a and which memory area 202 is the inactive memory area 202-B based on the updated application.
Alternatively, as another example (not shown), the storage area 202-A may store the software installation 208 and the storage area 202-B may store the software update 116. In such an example, the software update 116 may include differences in updates to be applied to the software installation 208 to update the software installation 208 from the software version 210-A to the software version 210-B. This differential approach to the software update 116 may allow for easier downloading of the software update 116. When the vehicle ECU104, having received the software update 116 to the inactive memory area 202-B, receives confirmation for exchanging the software update 116, the vehicle ECU104 may be configured to install the software update 116 to the memory area 202-a.
Fig. 3 illustrates an example process 300 for validating the software update 116 and installing the software update 116 to the vehicle ECU 104. In an example, process 300 may be performed by vehicle ECU104 communicating with telematics control unit 108 over vehicle bus 106.
At operation 302, the vehicle ECU104 receives the software update 116. In an example, the vehicle ECU104 receives an update message from the telematics control unit 108 in response to the update server 120 determining that the vehicle 102 should receive a software update 116 for the vehicle ECU 104.
At operation 304, the vehicle ECU 104 verifies the signature and version of the software update 116. In an example, the vehicle ECU 104 may utilize the public key 124 maintained by the vehicle ECU 104 to ensure that the received software update 116 is provided by the update server 120 using the private key 122 maintained by the data storage area 118. In another example, the vehicle ECU 104 may confirm that the version of the software update 116 has a higher version number than the software version 210-a of the software installation 208-a for the active storage area 202-a of the vehicle ECU 104.
At operation 306, the vehicle ECU 104 determines whether the software update 116 is permitted to be installed. In an example, if the verification at operation 304 is successful, the software update 116 may be licensed for installation. Additionally or alternatively, the software update manager 112 may be configured to prompt the user for permission to install the software update 116, and may indicate permission from the user to install the software update 116 to the vehicle ECU 104. If the software update 116 is licensed for installation, control passes to operation 308. Otherwise, vehicle ECU 104 discards software update 116 and process 300 ends.
In operation 308, the vehicle ECU 104 installs the software update 116 to the inactive memory area 202-B of the vehicle ECU 104. In an example, the vehicle ECU 104 may install the software update 116 to the inactive memory area 202-B of the vehicle ECU 104. The vehicle ECU 104 may use the update processor 204-B to perform the installation, allowing the active processor 204-a to continue to use the active memory area 202-a to perform the operation of the vehicle ECU 104. After operation 308, process 300 ends.
Fig. 4 illustrates an example process 400 for performing exchange verification before shutdown of the vehicle 102 is complete. As with process 300, process 400 may be performed by vehicle ECU 104 communicating with telematics control unit 108 over vehicle bus 106.
In operation 402, the vehicle ECU 104 determines whether the attempted swap is ready. In an example, the vehicle ECU 104 may determine that the vehicle 102 has initiated an ignition off cycle with the software update 116 installed to the inactive memory area 202-B of the ECU 104. Initiation of ignition off may be detected by the vehicle ECU 104 in response to receipt of a signal or bus message by the vehicle ECU 104 over the vehicle bus 106 indicating the status of the ignition off. In other examples, the update process at the time of ignition switch off may be controlled by the telematics control unit 108 (or other ECU performing the function of the software update manager 112), and the telematics control unit 108 (or the other ECU) may identify an ignition switch off condition via the vehicle bus 106, or may receive a message from the vehicle ECU 104 over the vehicle bus 106 indicating that the vehicle ECU 104 sending the message is ready to attempt an exchange. If the vehicle ECU 104 is ready to perform the swap, control passes to operation 404. Otherwise control passes to operation 414.
At operation 404, the vehicle ECU 104 performs an exchange of the software update 116. In an example, the vehicle ECU 104 may mark the following in the memory area 202 in the vehicle ECU 104: the updated memory storage area 202-B will be temporarily restarted as an active memory storage area 202-a. The vehicle ECU 104 may also send a signal or message to other vehicle ECUs 104 over the vehicle bus 106 requesting that the vehicle 102 shutdown sequence be aborted to allow the vehicle ECU 104 to attempt a restart. In other examples, the update process when the ignition switch is turned off may be controlled by the telematics control unit 108 (or other ECU performing the function of the software update manager 112), and a signal requesting to abort the vehicle 102 shut-down sequence to allow the vehicle ECU 104 to attempt to restart may be sent by the telematics control unit 108 (or the other ECU) to the vehicle ECU 104.
At operation 406, the vehicle ECU 104 initiates a restart of the vehicle ECU 104.
At operation 408, the vehicle ECU 104 determines whether the restart was successful. In an example, the vehicle ECU 104 may determine whether the newly activated software installation 208-B successfully started to the vehicle ECU 104 without error. If the newly activated software installation 208-B successfully starts to the vehicle ECU 104 without error, control passes to operation 410. Otherwise, control passes to operation 412. After a restart of the vehicle ECU 104, the vehicle ECU 104 may also send a signal or message over the vehicle bus 106 to other vehicle ECUs 104 indicating that the vehicle 102 shut down sequence may continue. In other examples, the update process when the ignition switch is turned off may be controlled by the telematics control unit 108 (or other ECU performing the function of the software update manager 112), and a signal indicating that the vehicle 102 shut-down sequence may continue may be sent by the telematics control unit 108 (or the other ECU) to the vehicle ECU 104.
At operation 410, the vehicle ECU 104 determines the updated version of the software installation 208-B including the software update 116 as the new active software installation 208-a. Accordingly, the vehicle ECU 104 may set the new installation as the active memory storage area 202-a and may set the previous active storage area back to the inactive state. After operation 410, control continues with operation 414.
At operation 412, the vehicle ECU 104 reverts to the previous active software installation 208-a. Accordingly, the vehicle ECU 104 may discard or undo the installation of the new software. Thus, the vehicle ECU 104 may restart back to the last known good installed memory storage area. In some examples, the vehicle ECU 104 may additionally or alternatively notify the telematics control unit 108 of any errors to report back to the update server 120 for error handling. After operation 412, control continues with operation 414.
In operation 414, the vehicle ECU 104 ends the vehicle ignition off. In an example, the vehicle ECU may terminate the power-up operation and/or reduce their respective ignition-off loads to the load at which the ignition switch is off. When the next ignition-on cycle, the vehicle ECU 104 may again power up to their active state using software installed to the active memory storage area 202-a. After operation 414, process 400 ends.
Thus, by validating the software update 116 when the ignition switch is off rather than on, the exchange may be validated before the ECU 104 is turned off again as part of a normal turn-off event. Thus, an improved switching method may be employed to avoid potential complications regarding the detection of software compatibility or other errors at the next ignition switch turn-on.
In general, computing systems and/or devices such as vehicle ECU 104, telematics control unit 108, and update server 120 may utilize any one of a variety of computer operating systems including, but in no way limited to: microsoft (R)Operating System, unix operating System (e.g. issued by oracle corporation of Redwood Shores, california)>Operating system) An AIX UNIX operating system published by International Business machines corporation of Armonk (Armonk) N.Y., a Linux operating system, mac OS X and iOS operating systems published by apple Inc. of Coptino (Cupertino) of California, a blackberry OS or QNX operating system published by dynamic research corporation of Toku (Waterloo) Canada, and multiple versions and/or categories of android operating systems developed by the open cell phone alliance.
Computing devices such as the vehicle ECU 104, the telematics control unit 108, and the update server 120 typically include computer-executable instructions that are executable by the processor of one or more computing devices. Computer-executable instructions may be compiled or interpreted by a computer program created using a variety of programming languages and/or techniques, including, but not limited to: java (Java) TM C, C ++, visual Basic, java Script, perl, etc., or combinations thereof. Generally, a processor or microprocessor receives instructions from, for example, a memory, a computer-readable medium, etc., and executes the instructions, thereby performing one or more processes, including one or more of the processes described herein. Various computer readable media may be used to store and transmit such instructions, as well as other data.
Computer-readable media (also referred to as processor-readable media) includes any non-transitory (e.g., tangible) media that participates in providing data (e.g., instructions) that may be read by a computer (e.g., by a processor of a computing device). Such a medium may take many forms, including but not limited to, non-volatile media and volatile media. For example, non-volatile media may include optical or magnetic disks, and other persistent memory. For example, volatile media may include Dynamic Random Access Memory (DRAM), which typically constitutes a main memory. Such instructions may be transmitted over one or more transmission media, including coaxial cables, copper wire and fiber optics, including the wires that comprise a system bus coupled to a processor of a computer. Common forms of computer-readable media include, for example: a floppy disk, a flexible disk, hard disk, magnetic tape, any other magnetic medium, a CD-ROM, DVD, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, PROM, EPROM, FLASH-EEPROM, any other memory chip or cartridge, or any other medium from which a computer can read.
A database, data store, or other data store (such as data store 118 described herein) may include various mechanisms for storing, accessing, and retrieving various data, including: hierarchical databases, a set of files in a file system, application databases in a proprietary format, relational database management systems (RDBMS), etc. Each such data store is typically included in a computing device that uses a computer operating system (such as one of the computer operating systems mentioned above), and is accessed via a network in any one or more of a variety of ways. The file system may be accessed through a computer operating system and may include files stored in various formats. In addition to utilizing a language for creating, storing, editing, and executing stored programs, RDBMS typically uses a Structured Query Language (SQL) (such as the PL/SQL language mentioned above).
In some examples, system elements may be implemented as computer-readable instructions (e.g., software) on one or more computing devices (e.g., servers, personal computers, etc.) stored on a computer-readable medium (e.g., disk, memory, etc.) associated with the computing devices. The computer program product may include such instructions stored on a computer-readable medium for performing the functions described herein. Some or all of the operations disclosed herein as being performed by the vehicle ECU 104, the telematics control unit 108, the software update manager 112, and the update server 120 may be computer program products. In some examples, these computer program products may be provided as software that, when executed by one or more processors, provides the operations described herein. Alternatively, the computer program product may be provided as hardware or firmware or a combination of software, hardware and/or firmware.
For the processes, systems, methods, teachings, etc. described herein, it should be understood that while the steps of such processes, etc. have been described as occurring according to a particular ordered sequence, such processes may be practiced with the described steps performed in an order other than the order described herein. It should also be understood that certain steps may be performed concurrently, other steps may be added, or certain steps described herein may be omitted. In other words, the description of the processes herein is provided for the purpose of illustrating particular embodiments and should not be construed as limiting the claims in any way.
Accordingly, it is to be understood that the above description is intended to be illustrative, and not restrictive. Many embodiments and applications other than the examples provided will be apparent upon reading the above description. The scope should be determined not with reference to the above 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 contemplated and intended that future developments will occur in the arts described herein, and that the disclosed systems and methods will be incorporated into such future embodiments. In summary, it should be understood that the application is capable of modification and variation.
All terms used in the claims are intended to be given their broadest reasonable constructions and their ordinary meanings as understood by those skilled in the art in view of the description herein unless an explicit indication to the contrary is made herein. In particular, the use of singular articles such as "a," "an," "the," and the like are to be construed to describe one or more of the indicated elements unless the claims recite 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. The abstract is subject to this understanding: the abstract is submitted with the understanding that it will not be used to interpret or limit the scope or meaning of the claims. Furthermore, in the foregoing detailed description, it can be seen that various features are grouped together in various embodiments for the purpose of streamlining the disclosure. The methods of the present disclosure are not to be construed as reflecting such intent: the claimed embodiments require more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive subject matter lies in less than all features of a single disclosed embodiment. Thus, the claims are hereby incorporated into the detailed description, with each claim standing on its own as a separate claim topic.
While exemplary embodiments are described above, these embodiments are not intended to describe all possible forms of the invention. Rather, the words 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 invention. Furthermore, features of the various implemented embodiments may be combined to form further embodiments of the invention.
Claims (17)
1. A system for vehicle software updating, comprising:
a first storage area;
a second storage area;
a vehicle electronic control unit configured to:
downloading a software update received from a server to the first storage area;
before the vehicle is turned off, when the ignition switch is turned off, attempting restarting of the vehicle electronic control unit;
in response to successful activation of the vehicle electronic control unit to the first storage area, the first storage area is validated as active for activation instead of the second storage area,
wherein the vehicle electronic control unit is further configured to: receiving a first signal over the vehicle bus from a telematics control unit or other vehicle electronic control unit requesting an abort of the vehicle shutdown to allow the vehicle electronic control unit to attempt a restart; a second signal is received over the vehicle bus from the telematics control unit or other vehicle electronic control unit requesting continued vehicle shutdown after a restart.
2. The system of claim 1, wherein the vehicle electronic control unit is further configured to: in response to an unsuccessful boot of the vehicle electronic control unit to the first storage area, the second storage area is reserved as active for booting.
3. The system of claim 1, wherein the vehicle electronic control unit is further configured to: when the vehicle electronic control unit performs software installation for the second storage area of the vehicle electronic control unit, a software update is applied to the first storage area.
4. The system of claim 1, wherein the vehicle electronic control unit is further configured to: and continues to turn off to the ignition off mode after restarting.
5. The system of claim 1, wherein the vehicle electronic control unit is further configured to: a signal is sent over the vehicle bus to the other vehicle electronic control units requesting that the vehicle shutdown be aborted to allow the vehicle electronic control units to attempt a restart.
6. The system of claim 1, wherein the vehicle electronic control unit is further configured to: a signal is sent via the vehicle bus to the other vehicle electronic control units requesting that vehicle shutdown be continued after a restart.
7. The system of claim 1, wherein the first storage area and the second storage area are part of a vehicle electronic control unit.
8. A system for vehicle software updating, comprising:
a remote information processing control unit;
a plurality of vehicle electronic control units in communication with the telematics control unit over a vehicle bus, one of the plurality of vehicle electronic control units configured to:
restarting said one of said plurality of vehicle electronic control units to a first storage area using a software update received from a telematics control unit when an ignition switch is turned off;
in response to a successful reboot using the first storage area, the first storage area is validated as active for booting instead of the second storage area,
wherein the one of the plurality of vehicle electronic control units is further configured to:
transmitting a first signal requesting to suspend a vehicle shutdown to other vehicle electronic control units of the plurality of vehicle electronic control units via a vehicle bus to allow the one of the plurality of vehicle electronic control units to attempt a restart;
A second signal is sent over the vehicle bus to other vehicle electronic control units of the plurality of vehicle electronic control units requesting continued vehicle shutdown after restart.
9. The system of claim 8, wherein the telematics control unit is further configured to:
downloading a software update from a server;
the software update is sent to the one of the plurality of vehicle electronic control units via the vehicle bus.
10. The system of claim 8, wherein the one of the plurality of vehicle electronic control units is further configured to: in response to the one of the plurality of vehicle electronic control units not being successfully booted to the first storage area, the second storage area is left active for booting.
11. The system of claim 10, wherein the telematics control unit is configured to: the software update is received from a remote server, and the one of the plurality of vehicle electronic control units is further configured to: in response to the one of the plurality of vehicle electronic control units not being successfully started using the software update, a message is sent to the telematics control unit to cause the telematics control unit to report the unsuccessful start to the remote server.
12. The system of claim 8, wherein the one of the plurality of vehicle electronic control units is further configured to:
applying a software update to the first storage area when the one of the plurality of vehicle electronic control units performs a software installation on the second storage area of the one of the plurality of vehicle electronic control units;
and continues to turn off to the ignition off mode after restarting.
13. A system for vehicle software updating, comprising:
a remote information processing control unit;
a plurality of vehicle electronic control units in communication with the telematics control unit over a vehicle bus, one of the plurality of vehicle electronic control units configured to:
restarting said one of said plurality of vehicle electronic control units to a first storage area using a software update received from a telematics control unit when an ignition switch is turned off;
in response to a successful reboot using the first storage area, the first storage area is validated as active for booting instead of the second storage area,
Wherein the telematics control unit is configured to:
transmitting a first signal to the plurality of vehicle electronic control units requesting suspension of vehicle shutdown to allow the one of the plurality of vehicle electronic control units to attempt a restart via a vehicle bus;
a second signal is sent over the vehicle bus to the plurality of vehicle electronic control units requesting continued vehicle shutdown after restart.
14. A method for over-the-air software updating, comprising:
upon turning off of the ignition switch prior to turning off of the vehicle, responsive to successful reboot of the vehicle electronic control unit to the first storage area, the first storage area is identified as active for booting instead of the second storage area, the first storage area includes the downloaded software update received from the remote server,
wherein the method further comprises: transmitting a first signal to the other vehicle electronic control unit via the vehicle bus requesting an abort of the vehicle shutdown to allow the vehicle electronic control unit to attempt a restart; a second signal is sent over the vehicle bus to the other vehicle electronic control unit requesting continued vehicle shutdown after a restart.
15. The method of claim 14, further comprising: the software update is sent to the vehicle electronic control unit over the vehicle bus in response to the software update being downloaded from the server by the telematics control unit.
16. The method of claim 14, further comprising: in response to an unsuccessful boot of the vehicle electronic control unit to the first storage area, the second storage area is reserved as active for booting.
17. The method of claim 14, further comprising:
applying a software update to the first storage area when the vehicle electronic control unit performs a software installation on the second storage area of the vehicle electronic control unit;
and continues to turn off to the ignition off mode after restarting.
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US15/396,955 | 2017-01-03 | ||
| US15/396,955 US10782955B2 (en) | 2017-01-03 | 2017-01-03 | Pre-shutdown swap verification |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN108268264A CN108268264A (en) | 2018-07-10 |
| CN108268264B true CN108268264B (en) | 2023-11-28 |
Family
ID=62568261
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201711475936.XA Active CN108268264B (en) | 2017-01-03 | 2017-12-29 | Pre-shutdown exchange verification |
Country Status (3)
| Country | Link |
|---|---|
| US (1) | US10782955B2 (en) |
| CN (1) | CN108268264B (en) |
| DE (1) | DE102018100015A1 (en) |
Families Citing this family (22)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US10416985B2 (en) * | 2017-02-16 | 2019-09-17 | Ford Global Technologies, Llc | Method and apparatus for multi cycle vehicle software update compliance handling |
| US10237131B2 (en) * | 2017-06-14 | 2019-03-19 | Noritz Corporation | Communication adapter and program update method for communication adapter |
| US10402192B2 (en) * | 2017-07-25 | 2019-09-03 | Aurora Labs Ltd. | Constructing software delta updates for vehicle ECU software and abnormality detection based on toolchain |
| DE102017217668A1 (en) * | 2017-10-05 | 2019-04-11 | Bayerische Motoren Werke Aktiengesellschaft | Method and central data processing device for updating software in a plurality of vehicles |
| US10776096B2 (en) * | 2018-01-12 | 2020-09-15 | Blackberry Limited | Method and system for controlling software updates on a network connected device |
| JP7010049B2 (en) * | 2018-02-16 | 2022-01-26 | トヨタ自動車株式会社 | Vehicle control device, program update confirmation method and update confirmation program |
| JP2019153043A (en) * | 2018-03-02 | 2019-09-12 | トヨタ自動車株式会社 | Software management system and software management method |
| CN108958774A (en) * | 2018-07-13 | 2018-12-07 | 深圳市道通智能航空技术有限公司 | Module updating method and module to be upgraded in UAV system |
| US20200035358A1 (en) * | 2018-07-27 | 2020-01-30 | Hill-Rom Services, Inc. | Apparatus and method for updating software in a patient support apparatus using a memory toggle |
| US20200097275A1 (en) * | 2018-09-20 | 2020-03-26 | International Business Machines Corporation | Automated compatibility verification for software purchases prior to purchase |
| JP6698778B2 (en) * | 2018-10-04 | 2020-05-27 | 三菱電機株式会社 | Control system |
| JP7216559B2 (en) | 2019-02-05 | 2023-02-01 | 日立Astemo株式会社 | How to use electronic controllers and non-volatile memory |
| DE102019202232A1 (en) * | 2019-02-19 | 2020-08-20 | Robert Bosch Gmbh | Method and device for communicating between a first control device and a second control device |
| DE102019205368A1 (en) * | 2019-04-12 | 2020-10-15 | Volkswagen Aktiengesellschaft | Motor vehicle |
| JP7008661B2 (en) * | 2019-05-31 | 2022-01-25 | 本田技研工業株式会社 | Authentication system |
| JP7331931B2 (en) * | 2019-08-28 | 2023-08-23 | 株式会社デンソー | Vehicle electronic control system |
| JP7298427B2 (en) * | 2019-10-07 | 2023-06-27 | トヨタ自動車株式会社 | Program update system and program update method |
| JP7033116B2 (en) * | 2019-12-27 | 2022-03-09 | 本田技研工業株式会社 | Vehicle and software update method |
| JP7415726B2 (en) * | 2020-03-26 | 2024-01-17 | 株式会社オートネットワーク技術研究所 | In-vehicle information processing device, information processing method, and server program |
| JP2022037805A (en) * | 2020-08-25 | 2022-03-09 | トヨタ自動車株式会社 | On-vehicle system |
| JP2022121300A (en) * | 2021-02-08 | 2022-08-19 | トヨタ自動車株式会社 | Vehicular control device |
| US11271971B1 (en) * | 2021-03-19 | 2022-03-08 | King Saud University | Device for facilitating managing cyber security health of a connected and autonomous vehicle (CAV) |
Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801671B1 (en) * | 2006-09-05 | 2010-09-21 | Pederson Neal R | Methods and apparatus for detecting misfires |
| CN103568997A (en) * | 2013-11-07 | 2014-02-12 | 镇江长江汽车配件有限公司 | Power source module of electronic parking brake system |
| CN104866336A (en) * | 2014-02-25 | 2015-08-26 | 福特全球技术公司 | Silent in-vehicle software updates |
| WO2015185173A1 (en) * | 2014-06-07 | 2015-12-10 | Audi Ag | Motor-vehicle control unit having a current-saving mode for a parking phase |
| CN105487883A (en) * | 2014-10-07 | 2016-04-13 | 福特全球技术公司 | Methods and systems to update a vehicle computing system |
| CN105691330A (en) * | 2014-12-11 | 2016-06-22 | 福特全球技术公司 | telematics update software compatibility |
| CN105791387A (en) * | 2015-01-13 | 2016-07-20 | 福特全球技术公司 | Vehicle control update method and system |
Family Cites Families (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20090119657A1 (en) * | 2007-10-24 | 2009-05-07 | Link Ii Charles M | Methods and systems for software upgrades |
| US9032194B2 (en) * | 2010-12-06 | 2015-05-12 | Microsoft Technology Licensing, Llc | Fast computer startup |
| US9557981B2 (en) | 2011-07-26 | 2017-01-31 | Ford Global Technologies, Llc | Method and apparatus for automatic module upgrade |
| US8813061B2 (en) | 2012-10-17 | 2014-08-19 | Movimento Group | Module updating device |
| US9128798B2 (en) | 2012-10-17 | 2015-09-08 | Movimento Group | Module updating device |
| US9436456B2 (en) * | 2014-04-17 | 2016-09-06 | Myine Electronics, Inc. | System and method for management of software updates at a vehicle computing system |
| EP3101535B1 (en) * | 2015-06-01 | 2022-04-13 | OpenSynergy GmbH | Method for updating a control unit for an automotive vehicle, control unit for an automotive vehicle, and computer program product |
-
2017
- 2017-01-03 US US15/396,955 patent/US10782955B2/en active Active
- 2017-12-29 CN CN201711475936.XA patent/CN108268264B/en active Active
-
2018
- 2018-01-02 DE DE102018100015.4A patent/DE102018100015A1/en active Pending
Patent Citations (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US7801671B1 (en) * | 2006-09-05 | 2010-09-21 | Pederson Neal R | Methods and apparatus for detecting misfires |
| CN103568997A (en) * | 2013-11-07 | 2014-02-12 | 镇江长江汽车配件有限公司 | Power source module of electronic parking brake system |
| CN104866336A (en) * | 2014-02-25 | 2015-08-26 | 福特全球技术公司 | Silent in-vehicle software updates |
| WO2015185173A1 (en) * | 2014-06-07 | 2015-12-10 | Audi Ag | Motor-vehicle control unit having a current-saving mode for a parking phase |
| CN105487883A (en) * | 2014-10-07 | 2016-04-13 | 福特全球技术公司 | Methods and systems to update a vehicle computing system |
| CN105691330A (en) * | 2014-12-11 | 2016-06-22 | 福特全球技术公司 | telematics update software compatibility |
| CN105791387A (en) * | 2015-01-13 | 2016-07-20 | 福特全球技术公司 | Vehicle control update method and system |
Non-Patent Citations (2)
| Title |
|---|
| Experimental Security Analysis of a Modern Automobile;Karl Koscher等;《2010 IEEE Symposium on Security and Privacy》;447-462 * |
| 工程车显示监视控制一体机的设计与实现;朱静静;《《中国优秀硕士学位论文全文数据库 (信息科技辑)》》;I140-420 * |
Also Published As
| Publication number | Publication date |
|---|---|
| DE102018100015A1 (en) | 2018-07-05 |
| CN108268264A (en) | 2018-07-10 |
| US20180189049A1 (en) | 2018-07-05 |
| US10782955B2 (en) | 2020-09-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN108268264B (en) | Pre-shutdown exchange verification | |
| CN106484457B (en) | Multi-stage safe vehicle software update method and system | |
| CN105691330B (en) | Telematics update software compatibility | |
| CN106487778B (en) | Telematics system and method for vehicle-mounted network server | |
| CN108279917B (en) | Software update management | |
| CN105791387B (en) | Vehicle control updating method and system | |
| US10162625B2 (en) | Vehicle control storage methods and systems | |
| CN104866336B (en) | Silent in-vehicle software update | |
| JP6332580B1 (en) | Control device, program update method, and computer program | |
| US9557981B2 (en) | Method and apparatus for automatic module upgrade | |
| US20170242678A1 (en) | Method and apparatus for vehicle software update installation | |
| US10416985B2 (en) | Method and apparatus for multi cycle vehicle software update compliance handling | |
| US20140282467A1 (en) | Method and Apparatus for Multiple Vehicle Software Module Reflash | |
| JPWO2012056773A1 (en) | Program rewriting system for vehicles | |
| US20230004381A1 (en) | Software version rollback method, apparatus, and system | |
| WO2018189975A1 (en) | Relay apparatus, transfer method, and computer program | |
| CN112860299A (en) | Vehicle wireless update apparatus and method | |
| CN107102849B (en) | Method and apparatus for file replacement with periodic ignition switch off | |
| US20220391192A1 (en) | Ota master, center, system, method, non-transitory storage medium, and vehicle | |
| KR102109125B1 (en) | Method for managing state of ECU in vehicle based on automotive open system architecture | |
| US11853742B2 (en) | Server, software update system, distribution method, and non-transitory storage medium | |
| WO2022205443A1 (en) | Software upgrade method and apparatus | |
| US11670117B2 (en) | Vehicle and software update method | |
| JP7405033B2 (en) | Server, update management method, update management program, software update device, system including server and software update device, center, OTA master, system including center and OTA master | |
| CN115454462A (en) | OTA manager, system, method, non-transitory storage medium, and vehicle |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |