System and method for improving security of odometer information

Abstract

To provide the improvement of security of odometer information related to a vehicle.SOLUTION: According to this embodiment, a method for improving the security of odometer information is provided. The method that can be performed by a system mounted on a vehicle can include acquiring one or more pieces of odometer information from an odometer electronic controller unit (ECU), storing the one or more pieces of odometer information in an on-vehicle infotainment (IVI) ECU, acquiring a use table, determining whether a boundary condition determined in the use table is satisfied, and storing the one or more pieces of odometer information in an electronic fuse on the basis of the use table, on the basis of determination that the boundary information is satisfied.SELECTED DRAWING: Figure 1

Description

[Technical Field]

[0001] FIELD OF THE DISCLOSURE Exemplary embodiments of the present disclosure relate to vehicle systems, and more particularly to improving the security of odometer information in vehicle systems. [Background technology]

[0002] An odometer is a device or system utilized in a vehicle to measure and display information related to the distance traveled by the vehicle. The odometer provides information regarding the vehicle's usage, maintenance schedule, and potential resale value.

[0003] In modern vehicles, odometer information is typically managed by and stored in a single electronic control unit (ECU), such as an odometer ECU. This practice is vulnerable in terms of the security of the odometer information because a person can easily access the odometer ECU and control it (e.g., by replacing the ECU, modifying the ECU, etc.) to manipulate the odometer information. For example, the recorded distance traveled may be reset to zero or some other arbitrary number for malicious purposes (e.g., to resell the vehicle at a higher price to a trusting customer).

[0004] In view of the above, odometer information management in the related art is vulnerable to odometer fraud, and there is a need to improve the security of odometer information. Summary of the Invention

[0005] Exemplary embodiments consistent with the present disclosure effectively and efficiently provide increased security for odometer information.

[0006] According to an exemplary embodiment, a method for improving security of odometer information is provided. The method may be performed by a system implemented in a vehicle and may include obtaining one or more odometer information from an odometer ECU, storing the one or more odometer information in an in-vehicle infotainment (IVI) ECU, obtaining a usage table, determining whether a boundary condition defined in the usage table is satisfied, and storing the one or more odometer information in an electronic fuse based on the usage table based on a determination that the boundary condition is satisfied.

[0007] According to an embodiment, a system implemented in a vehicle for improving security of odometer information is provided. The system may include a memory storage configured to store computer-executable instructions and at least one processor communicatively coupled to the memory storage. The at least one processor may be configured to obtain one or more odometer information from an odometer ECU, store the one or more odometer information in an IVI ECU, obtain a usage table, determine whether a boundary condition defined in the usage table is satisfied, and, based on a determination that the boundary condition is satisfied, store the one or more odometer information in an electronic fuse based on the usage table.

[0008] Additional aspects will be set forth in part in the description that follows, and in part will be apparent from the description, or may be learned by practice of presented embodiments of the present disclosure. [Brief explanation of the drawings]

[0009] The features, advantages, and importance of preferred embodiments of the present disclosure will now be described with reference to the accompanying drawings, in which like reference numerals refer to like elements.

[0010] [Figure 1] FIG. 1 illustrates a diagram of exemplary components of a vehicle, in accordance with one or more exemplary embodiments. [Figure 2]FIG. 10 illustrates an exemplary usage table according to one or more exemplary embodiments. [Figure 3] FIG. 2 illustrates a block diagram of exemplary components in a control system according to one or more exemplary embodiments. [Figure 4] FIG. 1 illustrates a flow diagram of a method for improving security of odometer information according to one or more exemplary embodiments. DETAILED DESCRIPTION OF THE INVENTION

[0011] The following detailed description of preferred embodiments refers to the accompanying drawings. The foregoing disclosure provides illustration and description, but is not intended to be exhaustive or to limit implementations to the precise form disclosed. Modifications and variations are possible in light of the above disclosure or may be acquired from practice of implementations. Furthermore, one or more features or components of one embodiment may be incorporated into or combined with another embodiment (or one or more features of another embodiment). Furthermore, in the flowcharts and descriptions of operations provided below, it is understood that one or more operations may be omitted, one or more operations may be added, one or more operations may occur (at least partially) concurrently, and the order of one or more operations may be swapped.

[0012] Although a particular combination of features is recited in a claim and / or disclosed herein, such combination is not intended to limit the disclosure of possible implementations. Indeed, many of the features may be combined in ways not specifically recited in the claims and / or disclosed herein. Although each dependent claim listed below may depend directly on only one claim, the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0013] No element, act, or instruction used herein should be construed as critical or required unless expressly stated otherwise. Also, as used herein, the articles "a" and "an" are intended to include one or more items and may be used interchangeably with "one or more." Where only one item is intended, the term "a" or similar terms are used. Also, as used herein, the terms "has," "have," "having," "include," "including," or the like are intended to be open-ended terms. Furthermore, the phrase "based on" is intended to mean "based at least in part on," unless expressly stated otherwise. Furthermore, phrases such as "[A] and / or [B]," "at least one of [A] and [B]," or "at least one of [A] or [B]" should be understood to include A only, B only, or both A and B.

[0014] References throughout this specification to "one embodiment," "an embodiment," "a non-limiting preferred embodiment," or similar terms mean that the particular features, structures, or characteristics described in connection with the illustrated embodiment are included in at least one embodiment of the solution. Thus, the phrases "in one embodiment," "in an embodiment," "a non-limiting preferred embodiment," and similar terms throughout this specification may, but do not necessarily, all refer to the same embodiment.

[0015] Furthermore, the described features, advantages, and characteristics of the present disclosure may be combined in any suitable manner in one or more exemplary embodiments. Those skilled in the art will recognize, in light of the description herein, that the present disclosure may be practiced without one or more of the specific features or advantages of a particular embodiment. In other instances, additional features and advantages may be recognized in certain embodiments that may not be present in all embodiments of the present disclosure.

[0016] Furthermore, the term "vehicle" as used herein refers to any suitable type of vehicle in which exemplary embodiments of the present disclosure may be implemented. For example, a "vehicle" may refer to a motorized vehicle, such as a car, truck, bus, motorcycle, or any other suitable type of motor vehicle powered by an engine, motor, or other mechanical means. Alternatively, or in addition, a "vehicle" as used herein may refer to a bicycle, skateboard, and any other suitable type of non-motorized vehicle without departing from the scope of the present disclosure.

[0017] The systems and methods of the related art described above manage and store odometer information in a single electronic control unit (ECU), such as an odometer ECU. In addition to storing odometer information in the odometer ECU, exemplary embodiments of the present disclosure also store odometer information in an additional ECU (e.g., an in-vehicle infotainment (IVI) ECU, a central domain controller (C-DC) ECU, etc.) and store the odometer information in one or more electronic fuses based on a usage table. Therefore, the risk of odometer information being compromised and manipulated can be reduced because the odometer information can be stored in multiple vehicle components, particularly one or more electronic fuses that are one-time programmable read-only memory (ROM) or write-limited memory that can be configured to permanently record more recent information and are less accessible from the outside compared to the ECU.

[0018] 1 illustrates a diagram of exemplary components of a vehicle 100, according to one or more exemplary embodiments. As shown in FIG. 1, vehicle 100 may include a control system 110, an odometer ECU 120, an IVI ECU 130, a powertrain ECU 140, an engine ECU 160, an electronic fuse 150 associated with powertrain ECU 140, and an electronic fuse 170 associated with engine ECU 160.

[0019] The components of vehicle 100 have been simplified for purposes of explanation, and it is contemplated that vehicle 100 may include additional components and / or be configured differently in an actual implementation without departing from the scope of the present disclosure. For example, in some implementations, vehicle 100 may further include additional ECUs (e.g., a C-DC ECU, an advanced driver assistance system (ADAS) ECU, etc.), which may have multiple electronic fuses associated therewith, and the like.

[0020] Control system 110 may be configured to manage one or more pieces of odometer information. Specifically, control system 110 may receive one or more pieces of odometer information from odometer ECU 120 and then appropriately store the odometer information in IVI ECU 130 and electronic fuses 160 and 170 (if applicable). The one or more pieces of odometer information may include, for example, a total number of miles or distance traveled by the vehicle (e.g., in units of kilometers (km), miles, etc.), a number of miles traveled (i.e., a distance traveled by the vehicle during a particular trip), an average travel speed of the vehicle over a particular period and / or distance, a fuel efficiency or fuel consumption of the vehicle (e.g., in units of kilometers per liter (km / L), miles per gallon (MPG), etc.) over a particular period and / or distance, and the like.

[0021] According to an exemplary embodiment, control system 110 may periodically store odometer information in IVI ECU 130 according to a predetermined cycle. For example, control system 110 may obtain odometer information from odometer ECU 120 and then store the odometer information in IVI ECU 130 at the beginning of each month. Control system 110 may perform this operation repeatedly for at least a certain period of time (e.g., six consecutive months). Furthermore, control system 110 may store the odometer information as encrypted and hashed information. Similarly, control system 110 may also store the odometer information in another ECU (e.g., a C-DC ECU) in addition to or instead of IVI ECU 130.

[0022] According to an exemplary embodiment, control system 110 may obtain a usage table and then manage one or more odometer readings based on the usage table. Referring to FIG. 2, FIG. 2 illustrates an exemplary usage table, according to one or more exemplary embodiments. As shown in FIG. 2, the usage table may include multiple mappings of vehicle distance traveled and timings for inputting or storing one or more odometer readings into one or more electronic fuses. It is contemplated that the usage table in FIG. 2 is merely an example, and the scope of the present disclosure should not be limited thereto. Specifically, according to implementation requirements, distance traveled may be defined in other suitable units (e.g., miles, etc.), time may be defined in other suitable units (e.g., days, quarters, etc.), and specific values ​​or parameters in the usage table may vary and be similar.

[0023] The usage table defines boundary conditions that trigger the entry or storage of odometer information in one or more electronic fuses. The boundary conditions may include a minimum distance traveled, such that whenever control system 110 determines that the vehicle is entering or has entered a particular state, control system 110 may determine whether the distance traveled by the vehicle meets the minimum distance traveled and then determine whether the odometer information should be entered or stored in the electronic fuses. For example, in the example of FIG. 2 , the boundary condition is a minimum distance traveled of 1000 km. In this case, when control system 110 determines that the vehicle is entering an ignition-off (IG-OFF) state (e.g., when the vehicle is shut down), control system 110 may determine whether the distance traveled by vehicle 100 is greater than or equal to 1000 km. Thus, based on a determination that the distance traveled by vehicle 100 is greater than or equal to 1000 km, control system 110 may determine that the boundary conditions for storing odometer information in one or more electronic fuses are met, thereby triggering the entry or storage of odometer information.

[0024] When odometer information needs to be entered or stored in the electronic fuses, control system 110 may retrieve a usage table and select a mapping from among multiple mappings included in the usage table based on the distance traveled by the vehicle. Therefore, control system 110 may determine when to store the odometer information in the electronic fuses based on the selected mapping, and then store the odometer information in the electronic fuses accordingly. For example, based on a determination that vehicle 110 has traveled 2500 km, control system 110 may determine that the odometer information should be stored in the electronic fuses every two months. Therefore, control system 110 may store the odometer information in the electronic fuses every two months in addition to storing the odometer information in the IVI ECU (or C-DC ECU). Control system 110 may store the odometer information as encrypted and hashed information.

[0025] According to an exemplary embodiment, the usage table may be an exponentially increasing based usage table, where the mappings in the usage table are, for example, y=a(1+r) t where y represents a future value, a represents an initial or starting value, r represents the rate of increase, and t represents the time elapsed since the beginning of the increase process. In other words, when the distance traveled between uses of the electronic fuse increases, the entry or storage of odometer information into the electronic fuse occurs more frequently early in the vehicle's life and less frequently as the vehicle travels greater distances. Thus, a vehicle traveling greater distances will write to the electronic fuse more frequently at a faster rate initially, but less frequently over time, to maintain the exponential rate of increase. This allows for optimal use of the electronic fuses in storing odometer information, especially when the number of electronic fuses in a vehicle is limited.

[0026] According to an exemplary embodiment, the usage table may be stored in the odometer ECU and retrieved by control system 110 when needed. Additionally or alternatively, the usage table may be stored in a storage medium of control system 110 (an example storage medium is further described below with reference to FIG. 3). By default, the usage table may be an exponentially increasing table, as described above in this specification. When needed, control system 110 may update the usage table to reflect current usage trends. For example, control system 110 may determine whether vehicle usage has exceeded a predetermined period (e.g., six months), and then, based on the determination that vehicle usage has exceeded the predetermined period (e.g., after six months), perform a slope analysis to determine the vehicle's current usage trend. Thus, control system 110 may update the usage table to reflect the current usage trend.

[0027] According to an exemplary embodiment, control system 110 may initiate one or more vehicle actions according to the state of the vehicle. Specifically, based on a determination that the vehicle is or has entered an ignition-on (IG-ON) state (e.g., when the vehicle is initially started), before entering a driving state, control system 110 may check odometer information stored in the IVI ECU (and / or another ECU, such as the C-DC ECU), for example, via a cryptographic challenge or secure boot verification. Similar verifications may also be initiated by other vehicle components, such as, for example, an ADAS ECU.

[0028] According to an exemplary embodiment, based on a determination that the vehicle is entering or has entered the IG-ON state, control system 110 may compare odometer information stored in the IVI ECU (and / or another ECU, such as the C-DC ECU) with odometer information stored in the electronic fuses. For example, control system 110 may obtain odometer information from the IVI ECU and the electronic fuses, and then compare the obtained odometer information (e.g., via hashing). Based on a determination that the odometer information stored in the IVI ECU differs from the odometer information stored in the electronic fuses, control system 110 may initiate one or more vehicle actions, such as displaying a message to notify the vehicle driver (e.g., transmitting an error code on a display, activating the vehicle's engine warning light, etc.), commanding an engine immobilizer to disable one or more operations of the vehicle's engine (e.g., disabling the engine's ignition, etc.), and the like.

[0029] According to an example embodiment, control system 110 (or one or more operations associated therewith) may be implemented in one or more ECUs. For example, control system 110 (or one or more operations associated therewith) may be implemented in odometer ECU 120, IVI ECU 130, powertrain ECU 140, engine ECU 150, and / or any other suitable ECU, such as a C-DC ECU and an ADAS ECU.

[0030] 1 , odometer ECU 120 may be configured to measure, track, and record one or more odometer information associated with vehicle 100. For example, odometer ECU 120 may receive input from sensors (e.g., sensors that monitor the vehicle's movement, etc.) and then process the sensor input to calculate the distance traveled by the vehicle. Upon determining the odometer information, odometer ECU 120 may store the odometer information in its own memory storage and provide the odometer information to control system 110 for further processing.

[0031] The IVI ECU 130 may be configured to manage the vehicle's information and entertainment systems, including audio playback, video display, and navigation. Additionally, the IVI ECU 130 may also provide an interface to external devices, such as a smartphone or navigation device, and provide a user interface for accessing and controlling various infotainment functions. Furthermore, the IVI ECU 130 may also receive odometer information (from the control system 110) and then store the odometer information in its memory storage. In this regard, the IVI ECU 130 may function as an additional ECU that stores odometer information, thereby providing redundancy or backup of the odometer information. Furthermore, the IVI ECU 130 may also be configured to present the odometer information to the driver via one or more displays (e.g., an IVI display, a navigation display, etc.) in the vehicle 100.

[0032] Powertrain ECU 140 may be configured to control the operation of a vehicle's powertrain, which typically includes transmission components and a drivetrain. For example, powertrain ECU 140 may be configured to manage transmission shifting and torque distribution in vehicle 100. Electronic fuse 150 may include one or more non-volatile memories (e.g., ROM, limited write memory, etc.) configured to interact with powertrain ECU 140 and store associated information (e.g., version information for powertrain ECU 140, etc.). In some implementations, electronic fuse 150 may further include micro fuses implemented in a component (e.g., a computer chip, etc.) in which powertrain ECU 140 is deployed. Electronic fuse 150 may receive odometer information from control system 110 and then store the odometer information internally. According to an exemplary embodiment, control system 110 may first send odometer information to powertrain ECU 140 , which may then send the odometer information to electronic fuse 150 .

[0033] Engine ECU 160 may be configured to monitor and control the operation of the engine of vehicle 100. For example, engine ECU 160 may monitor and adjust fuel injection, enable or disable engine ignition, manage idle speed control and engine shutdown / startup procedures, and the like. According to an exemplary embodiment, engine ECU 160 may be configured to provide information about the vehicle's ignition status (e.g., IG-ON, IG-OFF, etc.) to control system 110. Similar to electronic fuse 150, electronic fuse 170 may include one or more non-volatile memories (e.g., ROM, limited write memory, etc.) configured to interact with engine ECU 160 and store associated information (e.g., version information for engine ECU 160, etc.). In some implementations, electronic fuse 170 may further include micro fuses implemented in a component (e.g., a computer chip, etc.) in which engine ECU 160 is deployed. Electronic fuse 170 may receive odometer information from control system 110 and then store the odometer information internally. According to an embodiment, control system 110 may first transmit the odometer information to engine ECU 160, and then engine ECU 160 may transmit the odometer information to electronic fuse 170.

[0034] 3, which illustrates a block diagram of exemplary components in a control system 110, in accordance with one or more exemplary embodiments. As shown in FIG. 3, the control system 110 may include at least one bus 111, at least one processor 112, at least one memory 113, at least one storage component 114, at least one input component 115, at least one output component 116, and at least one communication interface 117.

[0035] It is contemplated that control system 110 may include more or fewer components than those shown in Figure 3 and / or its associated components may be arranged differently than those shown in Figure 3 without departing from the scope of the present disclosure. For example, in some embodiments, control system 110 may include multiple storage components 114, input components 115 and output components 116 may be implemented as transceiver components, memory 113 and storage components 114 may be implemented as memory storage, and the like.

[0036] Bus 111 may be configured to facilitate or enable communication between components of control system 110. In particular, bus 111 may communicatively couple the components to one another and provide a means for data movement and flow of control signals between the components. Bus 111 may include one or more of an internal bus, an address bus, a data bus, a control bus, a Controller Area Network (CAN) bus, an Ethernet bus, a Peripheral Component Interconnect Express (PCIe) bus, and any other suitable type of bus that may be implemented in control system 110 to enable real-time (or near real-time) communication and coordination between components within control system 110.

[0037] Processor 112 may be implemented in hardware, firmware, or a combination of hardware and software and may be configured to handle real-time (or near-real-time) data processing and control of control system 110. Processor 112 may include one or more of a central processing unit (CPU), graphics processing unit (GPU), tensor processing unit (TPU), accelerated processing unit (APU), microprocessor, microcontroller, digital signal processor (DSP), field programmable gate array (FPGA), application specific integrated circuit (ASIC), and / or another type of processing or computational component that may be implemented in control system 110. In some implementations, processor 112 may be programmable to perform one or more operations described herein. Furthermore, processor 112 may include multiple processing units, each dedicated to performing a particular operation (e.g., one processing unit may be assigned to handle communications with an ECU, one processing unit may be assigned to handle communications with electronic fuses, etc.).

[0038] Memory 113 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers necessary for operation of control system 110. Memory 113 may include one or more of flash memory, read-only memory (ROM), random access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic memory, and / or optical memory), or any other suitable type of memory that may be implemented in control system 110 to store information and / or instructions for use by processor 112.

[0039] Storage component 114 may be configured to store non-volatile data, such as firmware, configuration settings, calibration data, information, and / or software related to the operation and use of control system 110. For example, storage component 114 may include a hard disk (e.g., a magnetic disk, optical disk, magneto-optical disk, and / or solid-state disk), a compact disk (CD), a digital versatile disk (DVD), a floppy disk, a cartridge, a magnetic tape, and / or another type of non-transitory computer-readable medium along with a corresponding drive.

[0040] According to an embodiment, storage component 114 may be configured to store computer-readable or computer-executable instructions implementing one or more operations of control system 110, one or more usage tables, information regarding one or more predetermined timings for storing odometer information in the IVI ECU (or any other suitable ECU), information implementing one or more exponential growth algorithms, information implementing one or more slope analyses, information implementing one or more vehicle operations, and the like. Storage component 114 may provide the stored information to memory 113 for execution by processor 112.

[0041] Input components 115 may include one or more input components (e.g., a touchscreen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that allow control system 110 to receive information, such as via user input. Output components 116 may include one or more output components (e.g., a display, a speaker, a navigation device, one or more light-emitting diodes (LEDs), etc.) that provide output information from system 110. According to an embodiment, input components 115 and / or output components 116 may be optional and / or may be excluded from control system 110.

[0042] At least one communication interface 117 may include transceiver-like components (e.g., a transceiver and / or separate receivers and transmitters) that enable control system 110 to communicate with other vehicle components (e.g., ECUs, electronic fuses, etc.) via wired connections, wireless connections, or a combination of wired and wireless connections, etc. For example, communication interface 117 may include a controller area network (CAN) bus interface, an Ethernet interface, an optical interface, a coaxial interface, an infrared interface, a radio frequency (RF) interface, a universal serial bus (USB) interface, a Wi-Fi interface, a cellular network interface, or the like.

[0043] According to one or more embodiments, communication interface 117 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or the like, that enables components 112-116 to communicate with other vehicle components. Additionally, communication interface 117 may include one or more application programming interfaces (APIs) that enable control system 110 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed in ECUs, etc.).

[0044] Computer-executable instructions (e.g., software instructions, etc.) may be loaded into memory 113 and / or storage component 114 from another computer-readable medium or from another device (e.g., a remote server, external storage, etc.) via communications interface 117. When executed, the computer-executable instructions stored in memory 113 and / or storage component 114 may cause processor 112 to perform one or more processes described herein. Additionally or alternatively, hardwired circuitry may be used in place of or in combination with software instructions to perform one or more processes described herein. Thus, implementations described herein are not limited to any specific combination of hardware circuitry and software.

[0045] 4 illustrates a flow diagram of a method 400 for improving the security of odometer information, according to one or more exemplary embodiments. The method may be performed by at least one processor (e.g., processor 112) of a system (e.g., control system 110) in a vehicle by executing computer-readable instructions stored in one or more memory storages (e.g., memory 113, storage component 114, etc.). Method 400 may be triggered regularly or periodically.

[0046] 4, in operation S410, the at least one processor may be configured to obtain one or more odometer information from an odometer ECU (e.g., ECU 120). The one or more odometer information may include, for example, a total number of miles or distance traveled by the vehicle (e.g., in units of km, miles, etc.), a number of miles traveled (i.e., a distance traveled by the vehicle during a particular trip), an average travel speed of the vehicle over a particular period and / or distance, a fuel efficiency or fuel consumption of the vehicle (e.g., in units of km per liter (km / L), miles per gallon (MPG), etc.) over a particular period and / or distance, and the like.

[0047] At operation S420, the at least one processor may be configured to store the one or more odometer information in the IVI ECU (or any other suitable ECU, such as a C-DC ECU). According to an exemplary embodiment, the at least one processor may periodically store the one or more odometer information in the IVI ECU according to a predetermined cycle (e.g., at the beginning of each month).

[0048] At operation S430, the at least one processor may be configured to retrieve a usage table. For example, the usage table may be stored in a storage (e.g., memory 113, storage component 114, etc.) of the control system, and the at least one processor may retrieve the usage table from the storage. As another example, the usage table may be stored or implemented in an odometer ECU. In this case, the at least one processor may communicate with the odometer ECU to retrieve the usage table. The usage table may include an exponential increase-based usage table including multiple mappings based on an exponential increase rate, each of which may include a distance traveled by the vehicle and an associated timing for storing the one or more pieces of odometer information in one or more electronic fuses. Examples of usage tables are described above with reference to FIG. 2.

[0049] At operation S440, the at least one processor may be configured to determine whether a boundary condition defined in a usage table is satisfied. For example, the usage table may include a minimum distance traveled. In this case, the at least one processor may determine whether the boundary condition is satisfied by determining whether the vehicle is entering or has entered an ignition-off (IG-OFF) state, determining whether a distance traveled by the vehicle meets the minimum distance traveled based on a determination that the vehicle is entering or has entered the IG-OFF state, determining that the boundary condition is satisfied based on a determination that the distance traveled by the vehicle is greater than or equal to the minimum distance traveled, and determining that the boundary condition is not satisfied based on a determination that the distance traveled by the vehicle is less than the minimum distance traveled.

[0050] Based on a determination that the boundary condition is not satisfied, method 400 may terminate or end, and the one or more pieces of odometer information are not stored or entered into any electronic fuses. Conversely, based on a determination that the boundary condition is satisfied, the at least one processor may be configured to store the one or more pieces of odometer information in one or more electronic fuses based on the usage table. For example, the at least one processor may store the one or more pieces of odometer information by selecting a mapping from among a plurality of mappings based on a distance traveled by the vehicle, determining a timing for storing the one or more pieces of odometer information in the one or more electronic fuses based on the selected mapping, and storing the one or more pieces of odometer information in the one or more electronic fuses according to the determined timing. According to an exemplary embodiment, a portion of the odometer information may be stored in a first electronic fuse, and another portion of the odometer information may be stored in a second electronic fuse. The one or more electronic fuses may include an electronic fuse associated with a powertrain ECU and / or an electronic fuse associated with an engine ECU.

[0051] It is contemplated that the flow diagram in Figure 4 merely illustrates one possible embodiment, and that the scope of the present disclosure should not be limited thereto. Specifically, in some implementations, method 400 may include more or fewer operations than those shown in Figure 4.

[0052] For example, according to an example embodiment, method 400 may further include an operation of updating a usage table, where the at least one processor may be configured to update the usage table by determining whether usage of the vehicle has exceeded a predetermined period of time, and based on a determination that usage of the vehicle has exceeded the predetermined period of time, performing a slope analysis to determine a current usage trend for the vehicle, and updating the usage table based on the current usage trend.

[0053] Additionally, method 400 may further include initiating one or more vehicle actions, such as displaying a message to notify a vehicle driver, instructing an engine immobilizer to disable one or more operations of the vehicle's engine, and the like. In this case, the at least one processor may be configured to initiate the one or more vehicle actions by: determining whether the vehicle has entered or has reached an ignition-on (IG-ON) state; comparing one or more odometer information stored in the IVI ECU with one or more odometer information stored in electronic fuses based on a determination that the vehicle has entered or has reached the IG-ON state; and initiating the one or more vehicle actions based on a determination that the one or more odometer information stored in the IVI ECU differs from the one or more odometer information stored in the electronic fuses.

[0054] Further description of the specific operations associated with the operation of method 400 is provided above with reference to Figures 1 and 2. Accordingly, redundant description associated therewith may be omitted below for the sake of brevity.

[0055] To this end, exemplary embodiments of the present disclosure provide improved security for odometer information. Specifically, compared with the related art, which stores and manages odometer information in a single odometer ECU, exemplary embodiments of the present disclosure store odometer information in at least one additional ECU (e.g., an IVI ECU, a C-DC ECU, etc.) and one or more electronic fuses. Inputting or storing odometer information in the electronic fuses is initiated and performed according to a usage table (which is regularly updated according to the vehicle's latest usage trends). In this way, the timing of inputting or storing odometer information in the electronic fuses is determined according to the driver's behavior, optimizing the use of the electronic fuses in the vehicle. Furthermore, the odometer information stored in various vehicle components (e.g., ECUs, electronic fuses, etc.) can be used to verify the accuracy and integrity of the odometer information, and one or more actions (e.g., engine immobilization, etc.) can be taken based thereon, effectively reducing the risk of odometer fraud.

[0056] It is assumed that the features, advantages, and significance of the exemplary embodiments described herein above are merely part of the present disclosure and are not intended to be exhaustive or to limit the scope of the present disclosure. A further description of the features, components, configuration, operation, and implementation aspects of the exemplary embodiments of the present disclosure, as well as associated technical advantages and significance, is provided below.

[0057] It is understood that the specific order or hierarchy of blocks in the processes / flowcharts disclosed herein is an example of an exemplary approach. Based on design preferences, it is understood that the specific order or hierarchy of blocks in the processes / flowcharts may be rearranged. Furthermore, some blocks may be combined or omitted. The accompanying method claims present elements of the various blocks in a sample order and are not meant to be limited to the specific order or hierarchy presented.

[0058] Some embodiments may relate to systems, methods, and / or computer-readable media at any possible level of technical detail of integration. Additionally, as described herein above, one or more of the above components described above may be implemented as instructions stored on a computer-readable medium and executable by at least one processor (and / or may include at least one processor). The computer-readable medium may include a computer-readable non-transitory storage medium(s) having computer-readable program instructions thereon for causing a processor to perform operations.

[0059] A computer-readable storage medium may be a tangible device that can hold and store instructions for use by an instruction-execution device. A computer-readable storage medium may be, for example, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable compact disk read-only memory (CD-ROM), digital versatile disk (DVD), memory sticks, floppy disks, mechanically encoded devices such as punch cards or ridge-in-groove structures with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be construed as being transitory signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0060] The computer-readable program instructions described herein may be downloaded from a computer-readable storage medium into each computing / processing device, or may be downloaded to an external computer or external storage device over a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0061] The computer-readable program code / instructions for performing operations may be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or the like, and procedural programming languages ​​such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection to the external computer may be made (e.g., through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to personalize the electronic circuitry to perform an aspect or operation.

[0062] The computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to create a machine, such that the instructions, executed by the processor of the computer or other programmable data processing apparatus, create means for implementing the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium that can direct a computer, programmable data processing apparatus, and / or other device to function in a particular manner, such that the computer-readable storage medium having instructions stored therein comprises an article of manufacture containing instructions that implement aspects of the function(s) / act(s) specified in the block(s) of the flowcharts and / or block diagrams.

[0063] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or another device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to create a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the function / act specified in the block or blocks of the flowcharts and / or block diagrams.

[0064] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer-readable media according to various embodiments. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions comprising one or more executable instructions that implement a specified logical function. The methods, computer systems, and computer-readable media may include additional, fewer, different, or differently arranged blocks compared to those depicted in the figures. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be executed concurrently or substantially concurrently, or the blocks may even be executed in the reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowchart diagrams, and combinations of blocks in the block diagrams and / or flowchart diagrams, may be implemented by a dedicated hardware-based system that performs the specified functions or acts or executes a combination of dedicated hardware and computer instructions.

[0065] It will be apparent that the systems and / or methods described herein may be implemented in various forms of hardware, firmware, or combinations of hardware and software. The actual dedicated control hardware or software code used to implement the systems and / or methods is not a limitation of the implementation. Thus, the operation and behavior of the systems and / or methods are described herein without reference to specific software code, and it will be understood that software and hardware can be designed to implement the systems and / or methods based on the description herein.

Claims

1. 1. A method performed by at least one processor of a system implemented in a vehicle for improving security of odometer information, comprising: obtaining one or more odometer information from an odometer electronic controller unit (ECU); storing the one or more odometer information in an In-Vehicle Infotainment (IVI) ECU; Obtaining the usage table; determining whether boundary conditions defined in the usage table are satisfied; storing the one or more odometer information in an electronic fuse based on the usage table based on a determination that the boundary condition is met; A method comprising:

2. The storing of the one or more odometer information in the IVI ECU comprises: periodically storing the one or more odometer readings in the IVI ECU according to a predetermined cycle; The method of claim 1 , comprising:

3. The boundary condition comprises a minimum travel distance, and the determination as to whether the boundary condition is satisfied is made by: determining whether the vehicle has entered an ignition-off (IG-OFF) state; determining whether a distance traveled by the vehicle has satisfied the minimum travel distance based on a determination that the vehicle has entered the IG-OFF state; determining that the boundary condition is satisfied based on a determination that the distance traveled by the vehicle is greater than or equal to the minimum distance traveled; determining that the boundary condition is not satisfied based on a determination that the distance traveled by the vehicle is less than the minimum distance traveled; 3. The method of claim 1 or 2, comprising:

4. 3. The method of claim 1, wherein the usage table is an exponential growth based usage table comprising a plurality of mappings based on an exponential growth rate, each mapping comprising a distance traveled by the vehicle and an associated timing for storing the one or more odometer readings in the electronic fuse.

5. The storing of the one or more pieces of odometer information in the electronic fuse comprises: selecting a mapping from among the plurality of mappings based on the distance traveled by the vehicle; determining when to store the one or more pieces of odometer information in the electronic fuse based on the selected mapping provided; storing the one or more odometer information in the electronic fuse according to the determined timing; The method of claim 4, comprising:

6. determining whether use of the vehicle has exceeded a predetermined period of time; based on a determination that the use of the vehicle has exceeded the predetermined period, performing a slope analysis to determine a current usage trend of the vehicle; updating the usage table based on the current usage trends; The method of claim 1 or 2, further comprising:

7. determining whether the vehicle has entered an ignition-on (IG-ON) state; based on a determination that the vehicle has entered the IG-ON state, comparing the one or more odometer information stored in the IVI ECU with the one or more odometer information stored in the electronic fuse; Initiating one or more vehicle actions based on a determination that the one or more odometer information stored in the IVI ECU differs from the one or more odometer information stored in the electronic fuse; and The method of claim 1 or 2, further comprising:

8. The one or more vehicle actions include:

8. The method of claim 7, including displaying a message to notify the operator of the vehicle.

9. The one or more vehicle actions include:

8. The method of claim 7, comprising instructing an engine immobilizer to disable operation of one or more of the engines of the vehicle.

10. The method of claim 1 or 2, wherein the electronic fuses comprise one or more of an electronic fuse associated with a powertrain ECU and an electronic fuse associated with an engine ECU.

11. 1. A system implemented in a vehicle for improving security of odometer information, the system comprising: memory storage for storing computer-executable instructions; at least one processor communicatively connected to the memory storage; wherein the at least one processor executes the instructions to obtaining one or more odometer information from an odometer electronic controller unit (ECU); storing the one or more odometer information in an In-Vehicle Infotainment (IVI) ECU; Get the table used, determining whether boundary conditions defined in the usage table are satisfied; and upon determining that the boundary condition is met, the system is configured to store the one or more odometer information in an electronic fuse based on the usage table.

12. The at least one processor 12. The system of claim 11, configured to store the one or more odometer information in the IVI ECU by periodically storing the one or more odometer information in the IVI ECU according to a predetermined cycle.

13. The boundary condition comprises a minimum travel distance, and the at least one processor: determining whether the vehicle is in an ignition-off (IG-OFF) state; determining whether a distance traveled by the vehicle has satisfied the minimum travel distance based on a determination that the vehicle has entered the IG-OFF state; determining that the boundary condition is satisfied based on a determination that the distance traveled by the vehicle is greater than or equal to the minimum distance traveled; determining that the boundary condition is not satisfied based on a determination that the distance traveled by the vehicle is less than the minimum distance traveled; 13. The system of claim 11 or 12, configured to determine whether the boundary condition is satisfied by:

14. 13. The system of claim 11 or 12, wherein the usage table is an exponential growth based usage table comprising a plurality of mappings based on an exponential growth rate, each mapping comprising a distance traveled by the vehicle and an associated timing for storing the one or more odometer readings in the electronic fuse.

15. The at least one processor selecting a mapping from among the plurality of mappings based on the distance traveled by the vehicle; determining a timing for storing the one or more pieces of odometer information in the electronic fuse based on the selected mapping; storing the one or more odometer information in the electronic fuse according to the determined timing; 15. The system of claim 14, wherein the system is configured to store the one or more pieces of odometer information in the electronic fuse by:

16. The at least one processor further comprises: determining whether the use of the vehicle has exceeded a predetermined period of time; based on a determination that the use of the vehicle has exceeded the predetermined period, performing a slope analysis to determine a current usage trend of the vehicle; 13. The system of claim 11 or 12, configured to update the usage table based on the current usage trends.

17. The at least one processor further comprises: determining whether the vehicle is in an ignition-on (IG-ON) state; based on a determination that the vehicle has entered the IG-ON state, comparing the one or more odometer information stored in the IVI ECU with the one or more odometer information stored in the electronic fuse; 13. The system of claim 11 or 12, configured to initiate one or more vehicle actions based on a determination that the one or more odometer information stored in the IVI ECU differs from the one or more odometer information stored in the electronic fuse.

18. The one or more vehicle actions include:

20. The system of claim 17, including displaying a message to notify an operator of the vehicle.

19. The one or more vehicle actions include:

20. The system of claim 17, including commanding an engine immobilizer to disable operation of one or more of the engines of the vehicle.

20. 13. The system of claim 11 or 12, wherein the electronic fuses comprise one or more of an electronic fuse associated with a powertrain ECU and an electronic fuse associated with an engine ECU.

Images