System and method for improving safety of odometer information

Abstract

The present disclosure provides systems and methods for improving security of odometer information. A method, which may be performed by a system installed on a vehicle, may include: acquiring one or more pieces of odometer information from an odometer electronic controller unit (ECU); storing more than one piece of odometer information to an ECU (Electronic Control Unit) of an in-vehicle information entertainment system (IVI); acquiring a usage table; determining whether a boundary condition specified in the use table is satisfied; and storing one or more pieces of odometer information to the electronic fuse based on the usage table based on the determination that the boundary condition is satisfied.

Description

Technical Field

[0001] Exemplary embodiments of the present disclosure relate to a vehicle system, and more particularly, to improving security of odometer information in a vehicle system. Background Art

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

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

[0004] Considering the above situation, the odometer information management in the related art is vulnerable to odometer fraud, and the security of odometer information needs to be improved. Summary of the Invention

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

[0006] According to an exemplary embodiment, a method for improving the security of odometer information is provided. The method can be performed by a system installed in a vehicle and can 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 boundary conditions specified in the usage table are satisfied; and, based on a determination that the boundary conditions are satisfied, storing the one or more odometer information in an electronic fuse based on the usage table.

[0007] According to an embodiment, a system installed in a vehicle to improve the security of odometer information is provided. The system may include: a storage device configured to store computer-executable instructions; and at least one processor communicatively connected to the storage device. 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 boundary conditions specified in the usage table are satisfied; and, based on a determination that the boundary conditions are satisfied, store the one or more odometer information in an electronic fuse based on the usage table.

[0008] Additional aspects are described in part in the description that follows and may be apparent in part from the description, or may be achieved by practice of the embodiments presented in the present disclosure. BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The functions, advantages, and significance of preferred embodiments of the present disclosure will be described below with reference to the accompanying drawings, in which like reference numerals represent like elements.

[0010] Figure 1 A diagram showing exemplary components of a vehicle according to one or more exemplary embodiments.

[0011] Figure 2 An exemplary usage table showing one or more exemplary embodiments.

[0012] Figure 3 A block diagram illustrating exemplary components of a control system according to one or more exemplary embodiments is shown.

[0013] Figure 4 A flowchart illustrating a method for improving the security of odometer information according to one or more exemplary embodiments is provided. DETAILED DESCRIPTION

[0014] The following detailed description of the preferred embodiments refers to the accompanying drawings. The above disclosure provides examples and illustrations, but is not intended to be exhaustive or to limit the implementation scheme to the exact form disclosed. Modifications and variations can be obtained in view of the above disclosure or can be obtained from the implementation scheme. Moreover, one or more functions or components of one embodiment can be embedded in another embodiment (or one or more functions of another embodiment) or can be combined with another embodiment (or one or more functions of another embodiment). Moreover, it will be understood that in the flowcharts and descriptions of the actions provided below, one or more actions can be omitted, one or more actions can be added, one or more actions can be performed (at least partially) simultaneously, and the order of one or more actions can be switched.

[0015] Even if a particular combination of functions is recited in the claims and / or disclosed in this specification, that combination is not intended to limit the disclosure of possible implementations. Indeed, many of the functions may be combined in ways not specifically recited in the claims and / or disclosed in this specification. Each of the dependent claims listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes each dependent claim in combination with all other claims in the claim set.

[0016] As long as it is not particularly clearly stated, the elements, behaviors or instructions used in this specification should not be interpreted as important (critical) or necessary (essential). In addition, when used in this specification, the articles "a" and "an" are intended to include more than one project and can be used in a manner that can be exchanged with "more than one". In the case of referring to only one project, the term "one" or the same term is used. In addition, when used in this specification, the terms "has", "have", "having", "include", "including" or similar terms refer to open terms. Moreover, unless otherwise specifically stated, the phrase "based on..." is intended to mean "at least partially based on...". Moreover, expressions 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 only A, only B or both A and B.

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

[0018] Furthermore, the functions, advantages, and features described in the present disclosure may be combined in any appropriate manner in one or more exemplary embodiments. In view of the description of this specification, those skilled in the art will recognize that the present disclosure may be implemented without one or more of the specific functions or advantages of a particular embodiment. In other examples, additional functions and advantages may be recognized in a particular embodiment that is sometimes not present in all embodiments of the present disclosure.

[0019] Furthermore, the term "vehicle" as used herein refers to any suitable type of vehicle capable of implementing the exemplary embodiments of the present disclosure. For example, a "vehicle" may refer to a powered vehicle, such as a passenger car, truck, bus, motorcycle, or any other suitable type of automobile powered by an engine, motor, or other mechanical unit. Alternatively or in addition, a "vehicle" as used herein may refer to a bicycle, skateboard, or any other suitable type of unpowered vehicle without departing from the scope of the present disclosure.

[0020] The aforementioned related art systems and methods manage and store odometer information in a single electronic control unit (ECU), such as an odometer ECU. In exemplary embodiments of the present disclosure, odometer information is stored not only in the odometer ECU but also in additional ECUs (e.g., an in-vehicle infotainment (IVI) ECU, a central domain controller (C-DC) ECU, etc.), and is also stored in one or more electronic fuses (e-fuses) based on a usage table. Consequently, odometer information can be stored in multiple vehicle components, particularly in one or more e-fuses, which are one-time programmable read-only memories (ROMs) or write-restricted memories that can be configured to permanently record relatively recent information and are less easily accessed from the outside than ECUs. This reduces the risk of odometer information being leaked and manipulated.

[0021] Figure 1 Figures showing exemplary components of a vehicle 100 according to one or more exemplary embodiments. Figure 1 As shown, the 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 the powertrain ECU 140 , and an electronic fuse 170 associated with the engine ECU 160 .

[0022] Assuming that the components of vehicle 100 are simplified for illustrative purposes, vehicle 100 may include additional components and / or may be composed of different items in actual implementations without departing from the scope of this disclosure. For example, in some implementations, vehicle 100 may also include additional ECUs (e.g., C-DC ECUs, Advanced Driver Assistance System (ADAS) ECUs, etc.), and the ECUs may have multiple electronic fuses associated therewith, and similar situations may exist.

[0023] The control system 110 can be configured to manage one or more odometer information. Specifically, the control system 110 can receive one or more odometer information from the odometer ECU 120, and then appropriately store the odometer information in the IVIECU 130 and the electronic fuse 150 and the electronic fuse 170 (if applicable). The one or more odometer information can include, for example, the total mileage or total distance traveled by the vehicle (e.g., units such as kilometers (km) and miles), travel mileage (i.e., the distance traveled by the vehicle during a specific travel period), the average travel speed of the vehicle during a specific period and / or distance, the fuel efficiency or fuel consumption of the vehicle during a specific period and / or distance (e.g., units such as kilometers per liter (km / L) and miles per gallon (MPG)), and similar information.

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

[0025] According to an exemplary embodiment, the control system 110 may obtain a usage table and then manage one or more odometer information based on the usage table. Figure 2 , Figure 2 An exemplary usage table showing one or more exemplary embodiments is shown. Figure 2As shown, the usage table may include multiple mappings of vehicle travel distances and timings for inputting or storing one or more odometer information into one or more electronic fuses. Figure 2 The usage table in the example is merely an example, and the scope of this disclosure should not be limited thereto. Specifically, depending on the requirements of the implementation, the movement distance may be specified in other appropriate units (e.g., miles, etc.), the time may be specified in other appropriate units (e.g., days, quarters, etc.), and the specific values ​​or parameters in the usage table may be different, and similar situations may exist.

[0026] The table is used to define boundary conditions for starting to input or store odometer information into one or more electronic fuses. The boundary conditions may include a minimum travel distance, with the result that when the control system 110 determines that the vehicle is entering or has entered a specific state, the control system 110 can always determine whether the distance moved by the vehicle meets the minimum travel distance, and then determine whether the odometer information should be input or stored into the electronic fuse. For example, in Figure 2 In the example, the boundary condition is a minimum travel distance of 1000 km. In this case, when control system 110 determines that the vehicle is entering the ignition-off state (e.g., when the vehicle is turned off), control system 110 may determine whether the distance traveled by vehicle 100 is greater than or equal to 1000 km. Therefore, based on the determination that the distance traveled by vehicle 100 is greater than or equal to 1000 km, control system 110 may determine that the boundary condition for storing odometer information in one or more electronic fuses is satisfied, thereby initiating the input or storage of odometer information.

[0027] Alternatively, when odometer information needs to be input or stored in the electronic fuse, the control system 110 retrieves the usage table and selects a map from the multiple maps included in the usage table based on the distance traveled by the vehicle. Therefore, the control system 110 can determine the timing for storing the odometer information in the electronic fuse based on the selected map and then store the odometer information in the electronic fuse according to the timing. For example, based on a determination that the vehicle 100 has traveled 2,500 km, the control system 110 can determine that the odometer information should be stored in the electronic fuse every two months. Therefore, in addition to storing the odometer information in the IVI ECU (or C-DC ECU), the control system 110 can also store the odometer information in the electronic fuse every two months. The control system 110 can store the odometer information as encrypted and hashed information.

[0028] According to an exemplary embodiment, the usage table may be a usage table based on exponential growth. In this case, the plurality of mappings in the usage table may be based on, for example, y=a(1+r) tAn exponential growth algorithm is used, where y represents the future value, a represents the initial value or starting value, r represents the growth rate, and t represents the time elapsed from the start of the growth process. In other words, as the distance traveled during the use of the electronic fuse increases significantly, a large amount of odometer information is input or stored into the electronic fuse early in the vehicle's lifespan. As the vehicle travels longer distances, the input or storage of odometer information into the electronic fuse decreases. Therefore, vehicles traveling longer distances initially write to the electronic fuse at a higher frequency, but write to it at a lower frequency over time to maintain the exponential growth rate. This allows for optimal use of the electronic fuses when storing odometer information, particularly when the number of electronic fuses in a vehicle is limited.

[0029] According to an exemplary embodiment, the usage table may be stored in the odometer ECU and retrieved by the control system 110 when needed. Additionally or alternatively, the usage table may be stored in a storage medium of the control system 110 (an example of a storage medium will be described below). Figure 3 Further described). By default, the usage table can be a table based on exponential growth as described above in this specification. When necessary, the control system 110 can update the usage table in a manner that reflects current usage trends. For example, the control system 110 can determine whether the use of the vehicle exceeds a predetermined period (e.g., 6 months), and then, based on the determination that the use of the vehicle exceeds the predetermined period (e.g., after 6 months), perform a slope line analysis to determine the current usage trend of the vehicle. Therefore, the control system 110 can update the usage table in a manner that reflects the current usage trend.

[0030] According to an exemplary embodiment, the control system 110 can initiate one or more vehicle actions based on the vehicle's state. Specifically, based on a determination that the vehicle is entering or has entered the ignition-on state (e.g., at initial vehicle startup), the control system 110 can check odometer information stored in the IVI ECU (and / or other ECUs such as the C-DC ECU) before entering the driving state, for example, through a password challenge or secure boot confirmation. Similar verification can also be initiated by other vehicle components, such as the ADAS ECU.

[0031] According to an exemplary embodiment, based on a determination that the vehicle is entering or has entered an IG-ON state, the control system 110 may compare odometer information stored in the IVI ECU (and / or another ECU, such as a C-DC ECU) with odometer information stored in the electronic fuse. For example, the control system 110 may obtain odometer information from the IVI ECU and the electronic fuse, 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 fuse, the control system 110 may initiate one or more vehicle actions, such as displaying a message to notify the vehicle's driver (e.g., displaying an error code on a display, activating the vehicle's engine warning light, etc.), instructing the engine immobilizer system to disable one or more actions of the vehicle's engine (e.g., disabling the engine ignition, etc.), and similar actions.

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

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

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

[0035] The powertrain ECU 140 can be configured to control the operation of the vehicle's powertrain, which typically includes a transmission assembly and a drivetrain. For example, the powertrain ECU 140 can be configured to manage gear shifting and torque distribution within the transmission of the vehicle 100. The electronic fuse 150 can include one or more non-volatile memories (e.g., ROM, write-restricted memory, etc.), which can be configured to interact with the powertrain ECU 140 to store information associated with the powertrain ECU 140 (e.g., version information of the powertrain ECU 140). In some implementations, the electronic fuse 150 can also include a microfuse mounted on a component (e.g., a computer chip) deployed by the powertrain ECU 140. The electronic fuse 150 can receive odometer information from the control system 110 and then store the odometer information internally. According to an exemplary embodiment, the control system 110 can first send the odometer information to the powertrain ECU 140, and then the powertrain ECU 140 can send the odometer information to the electronic fuse 150.

[0036] Engine ECU 160 can be configured to monitor and control the operation of the engine of vehicle 100. For example, engine ECU 160 can monitor the engine and adjust fuel injection, enable or disable engine ignition, manage idle control and engine shutdown / startup routines, and perform similar operations. According to an exemplary embodiment, engine ECU 160 can 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 can include one or more non-volatile memories (e.g., ROM, write-restricted memory, etc.), which can be configured to interact with engine ECU 160 to store information associated with engine ECU 160 (e.g., engine ECU 160 version information, etc.). In some implementations, electronic fuse 170 can also include a microfuse mounted on a component (e.g., a computer chip) deployed with engine ECU 160. Electronic fuse 170 can receive odometer information from control system 110 and then store the odometer information internally. According to an embodiment, first, the control system 110 may transmit the odometer information to the engine ECU 160 , and then, the engine ECU 160 may transmit the odometer information to the electronic fuse 170 .

[0037] Next, refer to Figure 3 , Figure 3 FIG. 1 is a block diagram illustrating exemplary components of a control system 110 according to one or more exemplary embodiments. Figure 3 As shown, 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 .

[0038] Assume that the control system 110 may include Figure 3 More or fewer of the components shown, and / or components associated therewith, may be configured to Figure 3 The components shown may be different without departing from the scope of the present disclosure. For example, in some embodiments, the control system 110 may include multiple storage components 114, the input component 115 and the output component 116 may be implemented as transceiver components, and the memory 113 and the storage component 114 may be implemented as storage devices, and similar situations may exist.

[0039] The bus 111 can be configured to facilitate or enable communication between components of the control system 110. Specifically, the bus 111 can connect the components in a manner that allows them to communicate with each other, providing a means for data movement and flow of control signals between the components. The bus 111 can 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 can be implemented in the control system 110 to enable real-time (or substantially real-time) communication and collaboration between components within the control system 110.

[0040] The processor 112 can be implemented using hardware, firmware, or a combination of hardware and software, and can be configured to handle real-time (or substantially real-time) data processing and control of the control system 110. The processor 112 can include one or more of a central processing unit (CPU), a graphics processing unit (GPU), a tensor processing unit (TPU), an accelerated processing unit (APU), a microprocessor, a microcontroller, a digital signal processor (DSP), a field programmable gate array (FPGA), an application-specific integrated circuit (ASIC), and / or other types of processing or computing components that can be implemented in the control system 110. In some implementations, the processor 112 can be programmed to perform one or more of the actions described herein. Furthermore, the processor 112 can include multiple processing units, each dedicated to performing a specific action (e.g., one processing unit can be assigned to handle communications with an ECU, another processing unit can be assigned to handle communications with an electronic fuse, etc.).

[0041] The memory 113 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers required to control the operation of the control system 110. The memory 113 may include one or more 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 can be implemented in the control system 110 to store information and / or instructions for use by the processor 112.

[0042] The storage component 114 can 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 the control system 110. For example, the storage component 114 can include a hard disk (e.g., a magnetic disk, an optical disk, a magneto-optical disk, and / or a solid-state drive), a compact disc (CD), a digital versatile disc (DVD), a floppy disk, a cassette, a magnetic tape, and / or other types of non-transitory computer-readable media, along with corresponding drives.

[0043] According to an embodiment, the storage component 114 can be configured to store computer-readable instructions or computer-executable instructions that implement one or more actions of the control system 110, one or more usage tables, information related to one or more predetermined timings for storing odometer information to the IVIECU (or any other appropriate ECU), information that implements one or more exponential growth algorithms, information that implements one or more grade line analyses, information that implements one or more vehicle actions, and similar information. The storage component 114 can provide the stored information to the memory 113 for execution by the processor 112.

[0044] The input component 115 may include one or more input components (e.g., a touch screen display, a keyboard, a keypad, a mouse, buttons, switches, and / or a microphone) that allow the control system 110 to receive information through user input, etc. The output component 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 the system 110. Depending on the embodiment, the input component 115 and / or the output component 116 may be optional and may be excluded from the control system 110.

[0045] The at least one communication interface 117 may include a component such as a transceiver (e.g., a transceiver and / or a separate receiver and transmitter) that enables the control system 110 to communicate with other vehicle components (e.g., an ECU, an electronic fuse, etc.) via a wired connection, a wireless connection, or a combination of a wired connection and a wireless connection. For example, the 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 a similar interface.

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

[0047] Computer-executable instructions (e.g., software instructions, etc.) can be read into the memory 113 and / or storage component 114 from other computer-readable media or from other devices (e.g., remote servers, external storage, etc.) via the communication interface 117. When executed, the computer-executable instructions stored in the memory 113 and / or storage component 114 can cause the processor 112 to perform one or more processes described in this specification. Additionally or alternatively, hardwired circuitry can be used in place of or in combination with software instructions to perform one or more processes described in this specification. Therefore, the implementation scheme described in this specification is not limited to any specific combination of hardware circuitry and software.

[0048] Figure 4 A flow chart illustrating a method 400 for improving the security of odometer information according to one or more exemplary embodiments. The method can be performed by at least one processor (e.g., processor 112) of a system in a vehicle (e.g., control system 110) when executing computer-readable instructions stored in one or more storage devices (e.g., memory 113, storage component 114, etc.). The method 400 can be triggered regularly or periodically.

[0049] like Figure 4As shown, in action S410, 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, the total mileage or total distance traveled by the vehicle (e.g., units such as km or miles), travel mileage (i.e., the distance traveled by the vehicle during a specific travel period), the average travel speed of the vehicle during the specific period and / or distance, the fuel efficiency or fuel consumption of the vehicle during the specific period and / or distance (e.g., units such as kilometers per liter (km / L) or miles per gallon (MPG)), and similar information.

[0050] In action S420, the at least one processor may be configured to store one or more odometer information items to 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 one or more odometer information items to the IVI ECU according to a predetermined period (e.g., at the beginning of each month).

[0051] In action S430, at least one processor may be configured to obtain a usage table. For example, the usage table may be stored in a storage memory of the control system (e.g., memory 113, storage component 114, etc.), and at least one processor may obtain the usage table from the storage memory. As another example, the usage table may be stored or implemented in an odometer ECU. In this case, at least one processor may communicate with the odometer ECU to obtain the usage table. The usage table may include: an exponential growth-based usage table including a plurality of mappings based on an exponential growth rate, each of the mappings may include a distance moved by the vehicle and a timing for storing one or more odometer information to one or more electronic fuses, associated with the distance. An example of a usage table is shown in FIG. Figure 2 Explained above.

[0052] In action S440, at least one processor may be configured to determine whether a boundary condition specified in a usage table is satisfied. For example, the usage table may include a minimum movement distance. In this case, the at least one processor may determine whether the boundary condition is satisfied by performing the following actions: determining whether the vehicle is entering or has entered an ignition-off (IG-OFF) state; based on the determination that the vehicle is entering or has entered the IG-OFF state, determining whether the distance moved by the vehicle satisfies the minimum movement distance; determining that the boundary condition is satisfied based on a determination that the distance moved by the vehicle is greater than or equal to the minimum movement distance; and determining that the boundary condition is not satisfied based on a determination that the distance moved by the vehicle is less than the minimum movement distance.

[0053] Based on a determination that the boundary condition is not met, method 400 may end or terminate, and the one or more odometer information is not stored or input into any electronic fuse. Conversely, based on a determination that the boundary condition is met, the at least one processor may be configured to store the one or more odometer information into the one or more electronic fuses based on a usage table. For example, the at least one processor may store the one or more odometer information by: selecting a mapping from a plurality of mappings based on the distance traveled by the vehicle; determining a timing for storing the one or more odometer information into the one or more electronic fuses based on the selected mapping; and storing the one or more odometer information into 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.

[0054] assumed Figure 4 The flowchart in FIG. 4 only illustrates possible implementations, and the scope of the present disclosure should not be limited thereto. Specifically, in some implementations, the method 400 may include: Figure 4 More / less action shown.

[0055] For example, according to an exemplary embodiment, method 400 may further include an action of updating the usage table. In this case, the at least one processor may be configured to update the usage table by: determining whether the vehicle has been used for a period exceeding a predetermined period; performing a grade line analysis to determine a current usage trend of the vehicle based on a determination that the vehicle has been used for a period exceeding the predetermined period; and updating the usage table based on the current usage trend.

[0056] Furthermore, method 400 may further include initiating one or more vehicle actions, such as displaying a message to notify the driver of the vehicle, instructing an engine immobilizer system to disable 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 is entering or has entered an ignition-on (IG-ON) state; based on a determination that the vehicle is entering or has entered the IG-ON state, comparing one or more odometer information stored in the IVI ECU with one or more odometer information stored in the electronic fuse; and based on a determination that the one or more odometer information stored in the IVI ECU is different from the one or more odometer information stored in the electronic fuse, initiating the one or more vehicle actions.

[0057] In the above reference Figure 1and Figure 2 Further descriptions of specific actions are provided in association with the actions of method 400. Therefore, redundant descriptions associated therewith may be omitted below for simplicity.

[0058] To this end, exemplary embodiments of the present disclosure provide improved security for odometer information. Specifically, compared to the related art practice of storing and managing 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. Input or storage of odometer information into or into the electronic fuses is initiated based on a usage table (regularly updated based on the vehicle's recent usage trends). Thus, the timing of inputting or storing odometer information into or into the electronic fuses optimizes the utilization of the vehicle's electronic fuses and is determined based on the driver's behavior. Furthermore, 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 based on this information, one or more actions (e.g., engine immobilization) can be performed, effectively reducing the risk of odometer fraud.

[0059] It is assumed that the functions, advantages, and significance of the exemplary embodiments described above in this specification are only part of the present disclosure and are not intended to be exhaustive or limit the scope of the present disclosure. Further description of the functions, components, configurations, actions, and implementation schemes of the exemplary embodiments of the present disclosure and the advantages and significance of the associated technologies will be provided below.

[0060] It is understood that the specific order or hierarchy of the functional blocks in the process / flowchart disclosed in this specification is an example of an exemplary method. It is understood that the specific order or hierarchy of the functional blocks in the process / flowchart can be reconfigured based on design preferences. Moreover, some functional blocks can be combined or some functional blocks can be omitted. The attached method claims present the elements of various functional blocks in an exemplary order, which does not mean that the elements of various functional blocks are limited to the specific order or hierarchy presented.

[0061] Some embodiments may involve systems, methods, and / or computer-readable media at any possible level of technical detail of the integration. Moreover, as described above in this specification, one or more of the above-mentioned components may be implemented as instructions stored in 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 (or multiple media) having computer-readable program instructions therein to cause the processor to perform actions.

[0062] 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, 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, but is not limited thereto. A non-exhaustive list of more specific examples of computer-readable storage media includes the following, namely, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a punch card with instructions recorded on it, or a mechanically encoded device such as a raised structure in a slot, and any suitable combination thereof. The computer-readable storage medium used in this specification should not be interpreted as a temporary signal itself, such as an electric wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (for example, a light pulse passing through an optical cable), or an electrical signal transmitted through a wire.

[0063] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to each computing / processing device, or can be downloaded to an external computer or external storage device via a network, such as the Internet, a local area network, a wide area network, and / or a wireless network. The network can include copper transmission cables, optical transmission fibers, wireless transmission, 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 transmits the computer-readable program instructions to a computer-readable storage medium within the computing / processing device for storage.

[0064] The computer readable program code / instructions for performing the actions may be any of assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state setting data, configuration data for an integrated circuit, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, or similar programming languages, 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 stand-alone 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 case, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, for example, an electronic circuit including a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA) can utilize state information of computer-readable program instructions to personalize the electronic circuit, thereby executing the computer-readable program instructions to perform a scheme or action.

[0065] The computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device to generate a machine. As a result, the instructions executed by the processor of the computer or other programmable data processing device generate a unit that implements the functions / behaviors specified in the functional block or multiple functional blocks in the flowchart and / or block diagram. The computer-readable program instructions can also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing device, and / or other device to perform functions in a specific method. As a result, the computer-readable storage medium having the instructions stored therein has a product including instructions for implementing the functional block or multiple functional blocks specified in the flowchart and / or block diagram.

[0066] Computer-readable program instructions can also be loaded into a computer, other programmable data processing apparatus or other device to cause a series of action steps to be performed on the computer, other programmable apparatus or other device, thereby generating a computer-implemented process, as a result of which the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the functional box or multiple functional boxes in the flowchart and / or block diagram.

[0067] The flowcharts and block diagrams in the accompanying drawings represent the architecture, functions and actions of possible implementation schemes of the systems, methods and computer-readable media of various embodiments. In this regard, each functional block in the flowchart or block diagram can represent a module, a program segment or a portion of an instruction, which has one or more executable instructions that implement the specified logical function. The method, computer system and computer-readable medium can include additional functional blocks, fewer functional blocks, different functional blocks or functional blocks of different configurations compared to the functional blocks depicted in the accompanying drawings. In a partially replaced implementation scheme, the functions recorded in the functional blocks can occur independently of the order recorded in the accompanying drawings. For example, two functional blocks shown in succession can actually be executed simultaneously or substantially simultaneously, or the functional blocks can sometimes be executed in reverse order according to the related functions. It should also be noted that each functional block of the block diagram and / or flowchart and the combination of functional blocks of the block diagram and / or flowchart can be implemented by a system based on dedicated hardware, which performs the specified functions or behaviors, or executes a combination of dedicated hardware and computer instructions.

[0068] It is apparent that the systems and / or methods described in this specification can be implemented in various forms of hardware, firmware, or a combination of hardware and software. The actual dedicated control hardware or software code used to implement the system and / or method does not limit the implementation scheme. Therefore, it is understood that the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and software and hardware can be designed to implement the system and / or method based on the description of this specification.

Claims

1. A method for improving the security of odometer information, the method being performed by at least one processor of a system installed in a vehicle, wherein: The method comprises: 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 system ECU, i.e., an IVI ECU; Get usage table; determining whether boundary conditions specified in the usage table are met; and Based on a determination that the boundary condition is satisfied, the one or more odometer information is stored in an electronic fuse based on the usage table.

2. The method according to claim 1, wherein The storing of the one or more odometer information in the IVI ECU includes: The one or more odometer information are periodically stored in the IVI ECU at a predetermined period.

3. The method according to claim 1 or 2, wherein: The boundary condition has a minimum movement distance, and the determination related to whether the boundary condition is met includes: determining whether the vehicle has entered an ignition-off (IG-OFF) state; determining, based on the determination that the vehicle has entered the IG-OFF state, whether a distance moved by the vehicle satisfies the minimum movement distance; determining that the boundary condition is satisfied based on a determination that the distance moved by the vehicle is greater than or equal to the minimum movement distance; and Based on a determination that the distance moved by the vehicle is shorter than the minimum movement distance, it is determined that the boundary condition is not satisfied.

4. The method according to any one of claims 1 to 3, wherein The usage table is an exponentially increasing usage table including a plurality of maps based on exponential growth rates, and each of the maps includes a distance traveled by the vehicle and a timing at which the one or more odometer information items are stored in the electronic fuse and associated with the distance.

5. The method according to claim 4, wherein The storing of the one or more odometer information in the electronic fuse includes: selecting a map from the plurality of maps based on the distance the vehicle travels; determining timings for storing the one or more odometer information in the electronic fuse based on the provided selected mapping; and The one or more odometer information are stored in the electronic fuse according to the determined timing.

6. The method according to any one of claims 1 to 5, further comprising: Determining whether the vehicle has been used for a period exceeding the established period; Based on the determination that the usage of the vehicle exceeds the predetermined period, performing a slope line analysis to determine a current usage trend of the vehicle; as well as The usage table is updated based on the current usage trend.

7. The method according to any one of claims 1 to 6, further comprising: 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; as well as One or more vehicle actions are initiated based on a determination that the one or more pieces of odometer information stored in the IVI ECU are different from the one or more pieces of odometer information stored in the electronic fuse.

8. The method according to claim 7, wherein: The one or more vehicle actions include: A message is displayed to inform the driver of the vehicle.

9. The method according to claim 7, wherein: The one or more vehicle actions include: One or more actions instructing an engine immobilizer system to disable the engine of the vehicle.

10. The method according to any one of claims 1 to 9, wherein The electronic fuse includes at least one of an electronic fuse associated with a powertrain ECU and an electronic fuse associated with an engine ECU.

11. A system for improving the security of odometer information, the system being installed in a vehicle, the system comprising: a storage memory storing computer-executable instructions; and at least one processor communicatively connected to the storage device; The at least one processor is configured to execute 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 system ECU, i.e., an IVI ECU; Get usage table; determining whether boundary conditions specified in the usage table are met; as well as Based on a determination that the boundary condition is satisfied, the one or more odometer information is stored in an electronic fuse based on the usage table.

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

13. The system according to claim 11 or 12, wherein: The boundary condition has a minimum movement distance, and the at least one processor is configured to determine whether the boundary condition is satisfied by: determining whether the vehicle is entering an ignition-off (IG-OFF) state; determining, based on a determination that the vehicle is entering the IG-OFF state, whether a distance moved by the vehicle satisfies the minimum movement distance; determining that the boundary condition is satisfied based on a determination that the distance moved by the vehicle is greater than or equal to the minimum movement distance; as well as Based on a determination that the distance moved by the vehicle is shorter than the minimum movement distance, it is determined that the boundary condition is not satisfied.

14. The system according to any one of claims 11 to 13, wherein: The usage table is an exponentially increasing usage table including a plurality of maps based on exponential growth rates, and each of the maps includes a distance traveled by the vehicle and a timing at which the one or more odometer information items are stored in the electronic fuse and associated with the distance.

15. The system according to claim 14, wherein: The at least one processor is configured to store the one or more odometer information in the electronic fuse by: selecting a map from the plurality of maps based on the distance the vehicle travels; determining timings for storing the one or more odometer information in the electronic fuse based on the selected mapping; as well as The one or more odometer information are stored in the electronic fuse according to the determined timing.

16. The system according to any one of claims 11 to 15, wherein: The at least one processor is further configured to: Determining whether the vehicle has been used for a period exceeding the established period; Based on the determination that the usage of the vehicle exceeds the predetermined period, performing a slope line analysis to determine a current usage trend of the vehicle; as well as The usage table is updated based on the current usage trend.

17. The system according to any one of claims 11 to 16, wherein: The at least one processor is further configured to: determining whether the vehicle is entering an ignition-on (IG-ON) state; based on a determination that the vehicle is entering 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; as well as One or more vehicle actions are initiated based on a determination that the one or more pieces of odometer information stored in the IVI ECU are different from the one or more pieces of odometer information stored in the electronic fuse.

18. The system according to claim 17, wherein: The one or more vehicle actions include: A message is displayed to inform the driver of the vehicle.

19. The system of claim 17, wherein: The one or more vehicle actions include: One or more actions instructing an engine immobilizer system to disable the engine of the vehicle.

20. The system according to any one of claims 11 to 19, wherein The electronic fuse includes at least one of an electronic fuse associated with a powertrain ECU and an electronic fuse associated with an engine ECU.

Images