Patent Application
20180107473
The present invention relates to installing vehicle system updates in a vehicle, and more particularly, to installing updates in vehicle system modules and/or electronic control units in the vehicle.
Vehicle computer modules often utilize software (e.g., or firmware or the like) to carry out various vehicle functions. A vehicle manufacturer may install the software initially in a vehicle module; however, from time to time, the manufacturer may develop updates or new software which improves the performance or increases the capabilities of the module. These updates may be provided to the vehicle by wire at a vehicle service center or wirelessly via so-called ‘over-the-air’ (OTA) communications. When these updates are provided at the vehicle service center, they are typically installed by service technicians who are trained to render the vehicle stationary before installing the update. However, when the updates are received via the OTA method, a vehicle end user may participate in the installation process, and the vehicle user may not follow the same procedures. For example, the user may attempt to install the updates while the vehicle is moving—and if the vehicle is moving or being operated during the installation of the updates, the vehicle may not operate properly—e.g., since the targeted vehicle module could be de-activated or at least partially disabled temporarily during the installation process. Thus, installation, in at least some instances, may endanger the user as certain vehicle systems may be inoperative.
Thus, there is a general need to inhibit vehicle functionality during the installation process. And for example, there is a more specific need to determine at a vehicle computer whether the vehicle is stationary prior to permitting the installation of the update in a vehicle module. Furthermore, since the installation process may be performed by computer(s), there is a need to determine that the vehicle is stationary with a high level of confidence.
According to an embodiment of the invention, there is provided a method of determining whether to install a software update at an electronic control unit (ECU) in a vehicle. The method includes: receiving at the ECU a first signal from a first vehicle system module (VSM) in the vehicle; receiving at the ECU a second signal from a second VSM in the vehicle, wherein the first and second signals each provide an indication that the vehicle is in a stationary state; based on the first and second signals, assessing at the ECU that the vehicle is in the stationary state, wherein the assessment is in accordance with a first predetermined confidence level; and in response to the assessment, authorizing at the ECU an installation of the software update on ECU memory.
According to another embodiment of the invention, there is provided a software update system for a vehicle. The system includes: a vehicle system module (VSM) configured to determine a first assessment of whether the vehicle is in a stationary state using a first set of parameters; a gateway module configured to determine a second assessment of whether the vehicle is in the stationary state using a second set of parameters, wherein at least some of the parameters of the second set differ from the parameters of the first set; and a target electronic control unit (ECU) having a processor coupled to memory, wherein the memory stores a plurality of instructions executable by the processor, including: instructions to receive data associated with the first and second assessments from the VSM and the gateway module, respectively; instructions to assess whether the vehicle is in the stationary state in response to receiving the first assessment data and the second assessment data; and instructions to authorize an installation of a software update when the processor determines that the vehicle is in the stationary state.
According to another embodiment of the invention, there is provided a computer program product that includes a non-transitory computer readable medium for an electronic control unit (ECU) in a vehicle that includes computer program instructions that enable a processor of the ECU to install a software update in memory of the ECU when the vehicle is in a stationary state. The computer program instructions include: instructions to receive a first signal from a vehicle system module (VSM) in the vehicle, wherein the first signal is associated with an assessment by the VSM that the vehicle is in the stationary state; instructions to receive a second signal from a gateway module in the vehicle, wherein the second signal is associated with an assessment by the gateway module that the vehicle is in the stationary state; instructions to determine whether the vehicle is in the stationary state in response to receiving the first and second signals, wherein the determination is in accordance with a predetermined confidence level; instructions to authorize an installation of the software update when the processor determines that the vehicle is in the stationary state; based on the authorization, instructions to receive the software update from one of a plurality of VSMs in the vehicle; and based on receiving the instructional update, instructions to reflash the memory device with the software update.
One or more embodiments of the invention will hereinafter be described in conjunction with the appended drawings, wherein like designations denote like elements, and wherein:
A software update system for a vehicle is described below which is adapted to control an installation of a vehicle system update in a vehicle system module (e.g., in an electronic control unit (ECU) thereof). The software system update may be adapted to update software, firmware, instructional code, or any other suitable instructions for a configurable or programmable electronic device. Prior to conducting the installation in the ECU, the software update system determines with a high level of confidence that the vehicle is in a stationary state. According to one example, before initiating the update of an ECU, the software update system determines whether the vehicle is moving and inhibits the update of the ECU until the vehicle is determined to be stationary. Further, the update system may account for one or more vehicle systems providing false readings or data to the software update system—e.g., due to a malfunction of a vehicle hardware, due to a programming bug in vehicle software, or due to malicious activity by vehicle hackers, just to name a few examples. The update system, as well as its implementation, will be discussed in greater detail below.
With reference to
Wireless carrier system 12 is preferably a cellular telephone system that includes a plurality of cell towers (only is one shown), one or more mobile switching centers (MSCs) (not shown), as well as any other networking components required to connect wireless carrier system 12 with land network 14. Each cell tower includes sending and receiving antennas and a base station, with the base stations from different cell towers being connected to the MSC either directly or via intermediary equipment such as a base station controller. Cellular system 12 can implement any suitable communications technology, including for example, analog technologies such as AMPS, or the newer digital technologies such as LTE, CDMA (e.g., CDMA2000), or GSM/GPRS. As will be appreciated by those skilled in the art, various cell tower/base station/MSC arrangements are possible and could be used with wireless system 12. For instance, the base station and cell tower could be co-located at the same site or they could be remotely located from one another, each base station could be responsible for a single cell tower or a single base station could service various cell towers, and various base stations could be coupled to a single MSC, to name but a few of the possible arrangements.
Land network 14 may be a conventional land-based telecommunications network that is connected to one or more landline telephones and connects wireless carrier system 12 to backend system 16. For example, land network 14 may include a public switched telephone network (PSTN) such as that used to provide hardwired telephony, packet-switched data communications, and the Internet infrastructure. One or more segments of land network 14 could be implemented through the use of a standard wired network, a fiber or other optical network, a cable network, power lines, other wireless networks such as wireless local area networks (WLANs), or networks providing broadband wireless access (BWA), or any combination thereof. Furthermore, data service center 20 need not be connected via land network 14, but could include wireless telephony equipment so that it can communicate directly with a wireless network, such as wireless carrier system 12.
Remote server 18 can be one of a number of computers accessible via a private or public network such as the Internet. Each such server 18 can be used for one or more purposes, such as a web server accessible via land network 14 and/or wireless carrier 12. Other such accessible servers 18 can be, for example: a service center computer where diagnostic information and other vehicle data can be uploaded from the vehicle 24; a client computer used by the vehicle owner or other subscriber for such purposes as accessing or receiving vehicle data or to setting up or configuring subscriber preferences or controlling vehicle functions; or a third party repository to or from which vehicle data or other information is provided, whether by communicating with the vehicle 24 or data service center 20, or both. Remote server 18 can also be used for providing Internet connectivity such as DNS services or as a network address server that uses DHCP or other suitable protocol to assign an IP address to the vehicle 24.
Data service center 20 is designed to provide the vehicle 24 with a number of different system back-end functions and generally includes one or more switches, servers, databases, live advisors, as well as an automated voice response system (VRS), all of which are known in the art. These various data service center components are preferably coupled to one another via a wired or wireless local area network. Switch, which can be a private branch exchange (PBX) switch, routes incoming signals so that voice transmissions are usually sent to either the live adviser by regular phone or to the automated voice response system using VoIP. The live advisor phone can also use VoIP; VoIP and other data communication through the switch may be implemented via a modem connected between the switch and network. Data transmissions are passed via the modem to server and/or database. Database can store account information such as subscriber authentication information, vehicle identifiers, profile records, behavioral patterns, and other pertinent subscriber information. Data transmissions may also be conducted by wireless systems, such as 802.11x, GPRS, and the like. Although one embodiment has been described as it would be used in conjunction with a manned data service center 20 using a live advisor, it will be appreciated that the data service center can instead utilize VRS as an automated advisor or, a combination of VRS and a live advisor can be used.
As shown in
In general, VSMs 32 can include any suitable hardware modules in the vehicle 24, each of which may be configured to perform one or more different vehicle functions or tasks. Non-limiting examples of VSMs 32 include an engine control module (ECM) that controls various aspects of engine operation such as fuel ignition and ignition timing and a powertrain control module (PCM) that regulates operation of one or more components of the vehicle powertrain. According to one embodiment, the ECM is equipped with on-board diagnostic (OBD) features that provide myriad real-time data, such as that received from various sensors including vehicle emissions sensors, and provide a standardized series of diagnostic trouble codes (DTCs) that allow a technician to rapidly identify and remedy malfunctions within the vehicle. Other VSM implementations will be apparent to skilled artisans.
Turning to
The illustrated BCM 44 includes a processor 52 coupled to memory 54. Processor 52 can be any type of device capable of processing and/or executing instructions, including microprocessors, microcontrollers, host processors, controllers, vehicle communication processors, and application specific integrated circuits (ASICs). It may be a dedicated processor (used only for module 44), or it can be shared with other vehicle systems. For example, in at least one embodiment, the processor 52 may perform or execute a number of instructions stored on memory 54, including one or more of the following: (1) receiving electrical inputs or parameters from various vehicle system modules, circuits, sensors, switches, etc. (e.g., which may be indicia that the vehicle is in a stationary state); (2) assessing or determining whether the vehicle 24 appears to be in the stationary state based on the received electrical parameters, wherein the assessment has a certain confidence level; and (3) in response to receiving the parameters and making an assessment that the vehicle 24 appears to be in the stationary state (wherein the assessment meets or exceeds a predetermined threshold confidence level), then providing a first trigger or other suitable signal as an output (e.g., see T1). Thus, the processor 52 may carry out at least a portion of the method described herein, as will be discussed in greater detail below.
In
The non-stationary state may include instances where the vehicle 24 is moving or the vehicle 24 is static or still but the transmission is in DRIVE, REVERSE, or is similarly capable of being operated by a vehicle user. A stationary state includes a condition wherein the vehicle 24 is not moving whether the engine is on or off and the vehicle is in PARK. In at least one embodiment, the vehicle mechanical (or so-called emergency) brake is actuated or applied as well. These are merely examples of a stationary state; of course, other implementations exist. As will be explained more below, various mechanical, electrical, and/or software controls may assist update system 30 in determining whether the vehicle 24 is in the stationary state—e.g., the update system 30 may use mechanical hardware or systems within the vehicle 24, electrical circuits or control systems within the vehicle, programming instructions within the vehicle 24, etc.
Memory 54 of BCM 44 may be used to store parameter data (e.g., A-C data) and other data associated with the operation of the BCM. Memory 54 includes any non-transitory computer usable or readable medium, which includes one or more storage devices or articles. Exemplary non-transitory computer usable storage devices include conventional computer system RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. In at least one implementation, the memory 54 includes non-volatile memory (e.g., ROM, EPROM, EEPROM, etc.). These of course are merely examples; other implementations are contemplated herein.
The gateway module 46 may be configured to provide a variety of communication services. For example, the module 46 may include one or more wireless chipsets (not shown) enabling the gateway module to communicate via cellular communication over the wireless carrier system 12 (e.g., LTE, CDMA, GSM, etc.), as well as via short range wireless communication (SRWC) with other local wireless devices, other vehicle devices, and the like. For example, SRWC includes but is not limited to technologies such as Bluetooth, BLE, Wi-Fi, Wi-Fi Direct, etc. In at least some embodiments, the gateway module 46 is located in a center stack or instrument panel of vehicle 24 and includes a user interface device (e.g., buttons, knobs, touch-screen, etc.) (not shown). For example, the module 46 may provide vehicle user(s) with entertainment and infotainment services via an internet connection, via AM/FM/Satellite radio, via one or more of a CD, DVD, or MP3 player, etc. As will be explained more below, the gateway module 46 may act as a receiving device for OTA or instructional updates from the backend system 16—e.g., these updates may be provided to the gateway module from time-to-time and consequently, the gateway module 46 may be configured to provide them to the respective VSMs 32 within the vehicle 24, as appropriate.
The illustrated gateway module 46 includes a processor 62, memory 64, and an auxiliary or back-up power supply or power source 66. Processor 62 may be any type of device capable of processing and/or executing instructions, including microprocessors, microcontrollers, host processors, controllers, vehicle communication processors, and application specific integrated circuits (ASICs). It may be a dedicated processor (used only for module 46), or it can be shared with other vehicle systems. For example, in at least one embodiment, the processor 62 may perform or execute a number of instructions stored on memory 64, including one or more of the following: (1) receiving electrical inputs or parameters D, E, F, G, H from various vehicle system modules, circuits, sensors, switches, etc. (including receiving electrical parameters from BCM 44, as shown) (e.g., which may be indicia that the vehicle is in the stationary state); (2) assessing or determining whether the vehicle 24 appears to be in the stationary state based on the received electrical parameters, wherein this assessment has a certain confidence level; and (3) in response to receiving the parameters and making the assessment that the vehicle 24 appears to be in the stationary state (wherein this assessment meets or exceeds a predetermined threshold confidence level), then providing a second trigger or other suitable signal as an output (e.g., see T2). Thus, the processor 62 may carry out at least a portion of the method described herein, as will be discussed in greater detail below.
In
Memory 64 of gateway module 46 may be coupled to the processor 62 and may be used to store parameter data (e.g., D-H data) and other data associated with the operation of the gateway module. Memory 64 includes any non-transitory computer usable or readable medium, which includes one or more storage devices or articles. Exemplary non-transitory computer usable storage devices include conventional computer system RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. In at least one implementation, the memory 64 includes non-volatile memory (e.g., ROM, EPROM, EEPROM, etc.). These of course are merely examples; other implementations are contemplated herein.
Auxiliary power source 66 of gateway module 46 includes any suitable power storing device coupled to a circuit that includes the processor 62 and memory 64. The power supply 66 can be adapted to provide sufficient power to carry out at least a portion of the method described herein when the vehicle ignition system 36 is powered OFF. Non-limiting examples include a battery (e.g., a rechargeable battery), one or more capacitive devices, and the like. In other implementations, the power source 66 is not contained within the gateway module 46; e.g., the power source 66 may represent a portion of a vehicle power budget—e.g., a percentage of Amp-hours allotted to the gateway module 46 from the primary vehicle battery (not shown).
Turning now to VSM 48, target VSM may be any VSM (32) located in the vehicle 24 for which a software update is available. For example, the target VSM 48 may be identified by the gateway module 46, e.g., when the gateway module 46 receives a notification or an update from the backend system 16 that is directed to the particular VSM. Thus, the VSM 48 may be the ECM, the PCM, a brake control module, a transmission control module, or any one of a number of other VSMs not listed here. In one embodiment, the target VSM 48 could be the body control module 44 or the gateway module 46 as well. Thus, target module 48 can represent any system module or ECU coupled to the network connection 34.
The illustrated VSM 48 includes an electronic control unit (ECU) 70 that controls a number of operations and functions of the respective VSM, and the ECU 70 comprises a processor 72 and memory 74. Processor 72 can be any type of device capable of processing and/or executing instructions, including microprocessors, microcontrollers, host processors, controllers, vehicle communication processors, and application specific integrated circuits (ASICs). It could be a dedicated processor (used only for module 48), or it could be shared with other vehicle systems. Further, memory 74 includes any non-transitory computer usable or readable medium, which includes one or more storage devices or articles. Exemplary non-transitory computer usable storage devices include conventional computer system RAM (random access memory), ROM (read only memory), EPROM (erasable, programmable ROM), EEPROM (electrically erasable, programmable ROM), and magnetic or optical disks or tapes. In at least one implementation, the memory 74 includes non-volatile memory (e.g., ROM, EPROM, EEPROM, etc.). These of course are merely examples; other implementations are contemplated herein.
As will be described more below, the processor 72 may perform or execute a number of instructions stored on memory 74. For example, processor 72 may be configured to perform one or more of the following: (1) receive one or more trigger or enable signals (e.g., such as the first and second trigger signals T1, T2 described above) (e.g., these trigger signals may be considered parameters or indicia to the processor 72 that the vehicle 24 is in the stationary state); (2) in response to receiving the first and second trigger signals, determine whether the vehicle 24 is in the stationary state, wherein the determination has a certain confidence level; (3) when it is determined that the vehicle 24 is in the stationary state and the determination meets or exceeds a predetermined threshold confidence level (e.g., that is higher the confidence levels associated with the first and second triggers), then authorize the installation of a software update at the ECU 70; (4) receive the software update from the gateway module 46 (or other system module 32) in response to the authorization; and (5) reflash the memory 74 using the software update in response to the authorization and in response to receiving the software update (e.g., perform a reflashing procedure). These instructions of course are merely examples; in a preferred embodiment, the processor 72 executes other instructions stored on memory 74 as well (e.g., such as instructions associated with the particular vehicle function and/or operations carried out by the particular VSM 48).
As will be appreciated by skilled artisans, reflashing a device or performing a reflashing procedure is a process that applies a software update to a targeted memory device so that the associated processor can carry out new, different, or modified instructions. Thus, as used herein, reflashing a device includes adding, overwriting, modifying, appending, pre-pending, and/or deleting instructions stored within a non-transitory computer readable medium (e.g., within memory 74). Thus, the reflashed device may include entirely new instructions, some new instructions and some instructions which existed prior to the reflash procedure, etc.
As shown in
Below, one or more methods of using the communications system 10 will be described. More particularly, at least one embodiment of a method of using the software update system 30 in the vehicle 24 will be described.
As shown in the flow diagram of
Step 305 may include other steps as well. For example, in step 305, the gateway module 46 may send a message to the target VSM 48 (e.g., or more particularly to the target ECU 70); the message may notify the ECU 70 that a software update is available requiring a reflash procedure. In response to receiving this message, the ECU 70, in some instances, may be configured to stay awake or active when the vehicle ignition system 36 powers down. In other implementations, the ECU 70 may be woken up (e.g., by the gateway module 46) after the vehicle ignition system 36 has powered down.
In step 310 which follows step 305, the vehicle ignition system 36 may power OFF. This may occur in any suitable manner, as described above—e.g., after detecting actuation of a power OFF button by a vehicle user, detecting de-actuation of a vehicle key in an ignition switch, receiving and detecting a cellular or SRWC wireless signal indicating an authorized vehicle user desires to stop the engine, etc., just to cite a few examples.
In step 315, vehicle ignition system 36 may transmit parameter data (e.g., B, H) indicating that the ignition system 36 is about to power OFF or that it has powered OFF—e.g., parameter B may be sent to the BCM 44, and parameter H may be sent to the gateway module 46. Steps 310 and 315 may occur in any suitable order or at least partially concurrently. In one embodiment, step 315 occurs just before the ignition system 36 has powered down—e.g., the ignition system 36 sends a message over the bus 34 that a power down sequence is in process. According to this embodiment, the auxiliary power source 66 of the gateway module 46 may be triggered to be operative in lieu of vehicle battery power.
In another embodiment of step 315, the parameter data B, H behaves as a low-voltage enable signal. For example, when the ignition system 36 is powered ON, the parameter data B, H may be a high or 5V signal (e.g., a digital ‘1’) and when the ignition system 36 is powered OFF, the parameter data B, H may be low or drop to a 0V signal (e.g., a digital ‘0’). These embodiments are merely examples; other implementations are also possible.
Steps 320 and 325 follow; these steps may occur in any suitable order or at least partially concurrently. In at least one embodiment, step 325 occurs in response to step 320. For example, in step 320, the BCM 44 provides a trigger signal T1 to the processor 72 of ECU 70 based on assessing or determining that the vehicle 24 appears to be in the stationary state. This assessment may be based on receiving and analyzing a set of parameters or indicia (A, B, C, . . . ), and the assessment may be associated with a certain confidence level. For example, BCM 44 may receive parameter data A from the mechanical parking brake sensor P (e.g., a mechanical brake may or may not be applied). Parameter data B may be received the vehicle ignition system 36 and may or may not indicate that the system 36 is powered OFF (per step 315). And parameter data C may be received from one or more electrical circuits, sensors, modules, etc. in the vehicle 24 and may provide any other suitable indication that the vehicle might be in the stationary state (e.g., electronic brake sensor data (e.g., applied or not), seat sensor data (e.g., driver present or not), door sensor data (e.g., door opened and closed recently or not), etc.). Thus, when the assessment by the processor 52 is that the vehicle 24 appears to be in the stationary state and when the confidence level meets or exceeds a predetermined threshold confidence level, then BCM 44 transmits the trigger signal T1.
It should be appreciated that the term ‘set’ (e.g., ‘set of parameters’) as used herein, includes one or more elements (e.g., parameters, inputs, indicia, etc.). Further, the system module (e.g., the BCM 44) need not evaluate or analyze each or every parameter in a given set. For example, the BCM 44 may receive three parameters (A, B, C); however, in making its assessment, the BCM may analyze a set of only one (e.g., parameter B), a set of only two (e.g., parameters A and B), etc.
In at least one embodiment, the trigger signal T1 indicates a vehicle power mode of the vehicle ignition system 36, which was assessed by the BCM 44. For example, the vehicle ignition system 36 may have two or more states or modes, as discussed above. Regardless, in at least one implementation, the trigger signal T1 indicates at least one of an ignition system power OFF mode or an ignition system power ON mode.
Furthermore, in at least one embodiment, step 320 includes transmitting the trigger signal T1 to the gateway module 46, as well as ECU 70. For example,
As discussed above, each assessment may have an associated confidence level. According to one embodiment, confidence levels may utilize probabilities, other statistical data, or the like. The associated confidence level may take into account that the reliability of the assessment made by processor 52 may only be as good as the reliability and/or accuracy of the received electrical parameters (e.g., A, B, C, etc.). For example, it is contemplated that in at least some instances, the parameters A-C received by processor 52 could include inadvertent errors or be altered maliciously (e.g., by a hacker who has gained access to the software update system 30). Thus, processor 52 has the capability to assess a probability that the assessment is accurate.
Probabilities are merely an example; other implementations also exist. For example, in at least one embodiment, the confidence level is based upon an industry standard such as an Automotive Safety Integrity Level (or ASIL), as defined in ISO 26262-1 (published Nov. 15, 2011), the entirety of which is hereby incorporated by reference. Thus, in this embodiment, when the processor 52 assesses that the vehicle 24 appears to be in the stationary state, the processor may base this assessment on an ASIL value. It will be appreciated that ASIL values can account for a number of criteria (e.g., probabilities plus more). Thus, for example, processor 52 may provide trigger signal T1 according to an ASIL-B confidence level. It should be appreciated that this is merely one example (e.g., the trigger signal could be according to an ASIL-A or ASIL-C confidence level instead—e.g., in other embodiments). Further, it should be appreciated that the ASIL value may be determined by the processor 52, or the parameters provided to the BCM 44 may define the ASIL value. Further, it should be appreciated that some vehicle modules (e.g., such as the BCM 44, gateway module 46, etc.) may be so-called ASIL-B modules; similarly, the electronic control units (ECUs) therein (e.g., including processor 52, processor 62, etc.) could be so-called ASIL-B ECUs.
In step 325 (
Similar to the step 320, step 325 may determine a confidence level using probabilities, ISO 26262, or the like. And in at least one embodiment, the processor 62 provides trigger signal T2 according to an ASIL-B confidence level. This is merely one example however; other ASIL implementations (and other confidence level implementations) are also possible. Further, it should be appreciated that the ASIL value may be determined by the processor 62, or the parameters provided to the gateway module 46 may define the ASIL value.
In step 330, the trigger signals T1 and T2 are received by the processor 72 (in the target ECU 70). For example, as shown in
Steps 335 and 340 follow step 330. In step 335, the target ECU 70 determines whether the vehicle 24 is in the stationary state based on receiving the trigger signals T1, T2, wherein this determination has a certain confidence level as well (which is assessed in step 340 below). For example, in one embodiment of step 335, when the processor 72 receives trigger signals T1 and T2 at least partially concurrently, the processor 72 determines that the vehicle is in the stationary state. For example, merely receiving both triggers signals T1, T2 concurrently may be sufficient to determine the stationary state. When this occurs, the method 300 proceeds to step 340, and when this does not occur, the processor 72 may determine that the non-stationary state exists—and consequently may loop back or return to step 315 (e.g., and wait for the next time the vehicle ignition system 36 provides parameter data to the BCM 44 and the gateway module 46). Of course, this is merely one example, and in other embodiments, the method could loop back to a different step instead.
In other embodiments of step 335, the target ECU 70 may evaluate additional trigger or enable signals from other system modules, vehicle sensors, etc. For example, three or more signals may be required to determine the stationary state.
In step 340, the target ECU 70 determines whether the determination in step 335 meets or exceeds a predetermined confidence threshold level. For example, trigger signals T1, T2 may include data indicating their respective confidence levels. For example, probability data may be included with the trigger signals and processor 72 may determine a confidence level based on the data received from the BCM 44 and gateway module 46. If the calculated confidence level meets or exceeds the threshold confidence level of the ECU 70, then the method 300 may proceed to step 345; if it does not, then the method may loop back to step 315 (or any other suitable step).
In another implementation of step 340, the processor 72 may evaluate two ASIL values. For example, the processor 72 may determine that an ASIL-B value (of trigger signal T1) and an ASIL-B value (of trigger signal T2) may correlate to an ASIL-D value—which, as will be appreciated by skilled artisans, is the highest ASIL value (e.g., a highest threshold ASIL value). Skilled artisans will appreciate that ASIL values (A, B, C, and D) correspond with both qualitative and quantitative metrics. For example, qualitatively, an ASIL-D includes high coverage with respect to “single point fault requirement,” high coverage with respect to “plausible dual point fault/latent fault requirements,” and requires dependent failure evaluation. And as appreciated by skilled artisans for example, quantitatively, an ASIL-D value corresponds to a “failure rate/operation hour” of less than 10−8 occurrences. Thus, in at least one embodiment, the processor 72 may have the highest confidence level that the vehicle 24 is in the stationary state prior to reflashing the ECU 70. This of course is merely one example; other embodiments exist. For example, the processor 72 may receive two or more trigger or enable signals—each having ASIL values of ASIL-A, ASIL-B, or ASIL-C—and correlate these combined ASIL values to an ASIL-D value.
In step 345, the memory 74 of ECU 70 is reflashed using the software update. For example, the gateway module 46 may store the update in memory 64 during steps 305-340 and, as part of step 345, the gateway module 46 may provide the update to the ECU 70. In at least one embodiment, the ECU 70 may refuse to receive (e.g., ignore) any software updates transmitted to it without the ECU 70 first completing steps 335 and 340. For example, in this manner, the ECU 70 may inhibit a reflash event in instances when a hardware or software error has occurred or when a malicious entity has infiltrated the vehicle network or bus 34.
According to one embodiment of step 345, the gateway module 46 performs the reflash of ECU 70, and according to another embodiment, the ECU 70 reflashes itself upon receipt of the software update (e.g., when method 300 proceeds from step 340 to 345). Reflashing may or may not include rebooting (e.g., powering down and then powering up again the ECU 70). Other aspects of reflashing memory 74 will not be discussed herein, as reflashing memory is generally known in the art.
In general, it should be appreciated that the ECU 70 determines whether to reflash using the software update. In this manner, network security is improved as each respective VSM ECU has the opportunity to determine—based on trigger signals whether the vehicle is in the stationary state prior to reflash, and each VSM ECU has the opportunity to calculate or determine a confidence level—based on the confidence levels of the associated trigger signals.
Following step 345, the method may end. It should be appreciated that the method 300 may repeated for other VSMs 32. In some instances, method 300 may be performed with respect to two or more target VSMs concurrently.
Other embodiments also exist. For example, the BCM 44 may transmit the first trigger signal T1 to the target ECU 70 (e.g., over the bus 34) prior to the vehicle ignition being OFF, and the gateway module 46 may transmit the second trigger signal T2 to the target ECU 70 (e.g., over bus 34) after the vehicle ignition is OFF. Further, the ECU 70 may be configured to store and execute additional instructions which include: storing data associated with the first trigger signal at the target ECU, and using that data to determine whether the vehicle is in the stationary state until an updated trigger signal T1 is received from the BCM 44. For example, receipt of the trigger signal T1 may serve a latching function—e.g., so that the ECU 70 may repeatedly evaluate only the trigger signal T2 of the gateway module 46 (e.g., waiting for gateway module 46 to assess that the vehicle 24 appears to be in the stationary state with some level of confidence).
In another example, the method above describes receiving OTA updates. However, in at least one embodiment, the update could be performed at a vehicle service center or other location. For example, the update system 30 could be used as an additional safeguard against service technician error—e.g., a safeguard against not placing the vehicle 24 entirely in the stationary state prior to update installation attempts.
Thus, there has been described a method of determining whether to install a software update in a vehicle. More particularly, there has been described a method that determines whether the vehicle is a stationary state and that also inhibits the installation of the software update until the vehicle is in the stationary state according to a predetermined level of confidence.
It is to be understood that the foregoing is a description of one or more embodiments of the invention. The invention is not limited to the particular embodiment(s) disclosed herein, but rather is defined solely by the claims below. Furthermore, the statements contained in the foregoing description relate to particular embodiments and are not to be construed as limitations on the scope of the invention or on the definition of terms used in the claims, except where a term or phrase is expressly defined above. Various other embodiments and various changes and modifications to the disclosed embodiment(s) will become apparent to those skilled in the art. All such other embodiments, changes, and modifications are intended to come within the scope of the appended claims.
As used in this specification and claims, the terms “e.g.,” “for example,” “for instance,” “such as,” and “like,” and the verbs “comprising,” “having,” “including,” and their other verb forms, when used in conjunction with a listing of one or more components or other items, are each to be construed as open-ended, meaning that the listing is not to be considered as excluding other, additional components or items. Other terms are to be construed using their broadest reasonable meaning unless they are used in a context that requires a different interpretation.
