Methods and apparatuses related to ecu calibration and computer program product

Abstract

A method and apparatus related to ECU calibration and a computer program product are provided. The method can include receiving, with an ECU function, a first set of calibration parameters and corresponding actions, encoding, with the ECU function, the first set of calibration parameters and corresponding actions into an encoded message based on an ECU protocol, and transmitting, with the ECU function, the encoded message to an ECU configured to decode the encoded message to obtain a plurality of batches, each batch of the plurality of batches having a calibration parameter of the first set of calibration parameters and a corresponding action, and calibrate the ECU by executing each batch.

Description

Technical Field

[0001] Exemplary embodiments of this disclosure relate to methods and apparatus, as well as computer program products, related to ECU calibration. Background Technology

[0002] In related technologies, a vehicle's electronic control unit (ECU) may have firmware or parameters internally configured to control the vehicle. For this purpose, an engineer or mechanic may intend to adjust specific values, such as parameters associated with throttle control, by calibrating the ECU. For example, a user might send coded messages to the ECU (e.g., considering payload limits), and the ECU might follow a process to decode the messages for calibration.

[0003] Given the significant diversity of parameters based on their format, structure, and meaning, which requires specific knowledge from the operator for calibration, systems in related technologies may struggle to incorporate multiple types of parameters. Furthermore, there is sometimes a lack of standardization.

[0004] Furthermore, message / payload encoding and decoding may be solely provided / obtained by the user (potentially using a delegation model), thus increasing the likelihood of user-initiated errors. Additionally, the relevant technical systems may struggle with large payload sizes and may become slower. Therefore, more robust and efficient methods are needed for ECU calibration. Summary of the Invention

[0005] An exemplary embodiment matching this disclosure provides a method related to electronic control unit (ECU) calibration. The method may include: receiving a first set of calibration parameters and corresponding actions using ECU functionality; encoding the first set of calibration parameters and corresponding actions into an encoded message based on an ECU protocol using the ECU functionality; and sending the encoded message to an ECU using the ECU functionality, the ECU being configured to: decode the encoded message to obtain multiple batches, each of the multiple batches having calibration parameters and corresponding actions from the first set of calibration parameters; and calibrating the ECU by executing each batch.

[0006] Based on the above, a wider variety of parameters can be implemented. Furthermore, the payload can be larger than usual due to the inclusion of a batch list, thus improving the overall calibration speed by reducing the number of messages between the client device and the target ECU. Additionally, the architecture enables the client device to be based on a user device capable of implementing a graphical user interface, thereby allowing for a more user-friendly and error-free method of data calibration.

[0007] According to an exemplary implementation, the written encoded message may include a header and a payload, wherein the payload includes a first plurality of batches, and the header includes at least one version number of the ECU protocol, the type of action, and the length of the first plurality of batches. The batch header of each batch may include a parameter identifier, the number of actions to be performed, and a list of actions, each action including an offset value relative to a parameter base address, the length of the data, and the data to be written to the ECU.

[0008] According to an exemplary implementation, the method may further include: using an ECU function to receive a response based on whether the calibration was successful. The method may further include: using an ECU function to receive parameters of a second set; using an ECU function, based on an ECU protocol, encoding the calibration parameters of the second set into a read encoded message; using an ECU function to send the read encoded message to an ECU, wherein the ECU is configured to perform the following actions: decoding the read encoded message to obtain a second plurality of batches, wherein each of the second plurality of batches has a plurality of actions corresponding to the parameters of the second set; and based on the plurality of actions, reading from the ECU to obtain request parameter data corresponding to the parameters of the second set; and using an ECU function to receive the request parameter data. Each of the plurality of actions may include an offset value relative to a parameter base address and the length of the request parameter data. The calibration parameters of the first set and the corresponding actions may be obtained from a user equipment.

[0009] Further solutions will be described in part in the description which follows and will become apparent in part from the description, or may be implemented by practicing the embodiments presented in this disclosure. Attached Figure Description

[0010] Hereinafter, with reference to the accompanying drawings, the features, advantages and importance of preferred embodiments of the present disclosure will be described, in which the same reference numerals denote the same elements.

[0011] Figure 1 This is a block diagram illustrating an exemplary physical system architecture related to ECU calibration, representing one or more exemplary implementations.

[0012] Figure 2 This is a block diagram illustrating an exemplary logical system architecture related to ECU calibration, representing one or more exemplary implementations.

[0013] Figure 3 This is a diagram illustrating exemplary message formats and payloads related to ECU calibration, representing one or more exemplary implementations.

[0014] Figure 4This is a diagram illustrating a call flowchart for sending a message payload to an ECU for calibration in one or more exemplary implementations.

[0015] Figure 5 This is a flowchart illustrating a call process for reading parameters from an ECU in one or more exemplary implementations.

[0016] Figure 6 This is a diagram illustrating an exemplary method related to ECU calibration, representing one or more exemplary implementations.

[0017] Figure 7 This is a diagram illustrating exemplary constituent elements of a system that can be configured to implement more than one exemplary implementation. Detailed Implementation

[0018] The following detailed description of preferred embodiments will be made with reference to the accompanying drawings. The above disclosure provides examples and descriptions, but is not intended to be exhaustive, nor is it intended to limit the implementation to the exact forms disclosed. Modifications and variations can be made based on the above disclosure, or modifications and variations can be obtained according to the implementation of the embodiments. Furthermore, one or more features or constituent elements of one embodiment can be incorporated into another embodiment (or one or more features of another embodiment) or combined with another embodiment (or one or more features of another embodiment). Moreover, in the following flowcharts and descriptions of actions, it will be understood that one or more actions can be omitted, one or more actions can be added, one or more actions can be performed simultaneously (at least partially), and the order of one or more actions can be switched.

[0019] Even if a specific combination of features is listed in the claims and / or disclosed in this specification, such combination is not intended to limit the disclosure of a particular possible implementation. In fact, many of these features can be combined according to methods not specifically listed in the claims and / or not disclosed in this specification. Each dependent claim listed below may be directly dependent on only one claim, but the disclosure of possible implementations includes all dependent claims combined with all other claims in the set of claims.

[0020] Unless otherwise explicitly stated, elements, actions, or instructions used in this specification should not be construed as essential or necessary. Furthermore, when used in this specification, the articles “a” and “an” are intended to include more than one item and may be used interchangeably with “more than one.” Where only one item is intended, the term “one” or similar terms are used. Additionally, when used in this specification, the terms “has,” “have,” “having,” “include,” “including,” or similar terms are intended as open-ended expressions. Moreover, unless otherwise explicitly stated, phrases such as “based on…” are intended to mean “at least partially based on….” Furthermore, 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.

[0021] Regarding expressions such as "at least one processor", when configured to perform the implementation of multiple actions, the execution of multiple instructions, etc., the expression should be understood as each of a single processor performing the implementation of multiple actions, etc., or each of a plurality of processors performing at least a portion (but not necessarily all) of the implementation of multiple actions, etc.

[0022] Throughout this specification, references to "one embodiment," "implementation," "non-limiting preferred embodiment," or the like mean that a particular feature, structure, or characteristic described in connection with the illustrated embodiment is included in at least one embodiment of the solution. Therefore, the phrases "in one embodiment," "in an embodiment," "in a non-limiting preferred embodiment," and the like throughout this specification may all refer to the same embodiment, but not necessarily the same embodiment.

[0023] Furthermore, the features, advantages, and characteristics described in this disclosure can be combined in any suitable manner in more than one exemplary embodiment. Those skilled in the art, based on the description in this specification, should recognize that this disclosure can be implemented in more than one of the specific features or advantages without a particular embodiment. In other instances, further features and advantages may be recognized in specific embodiments, though not always present in all embodiments of this disclosure.

[0024] Furthermore, the term "vehicle" as used in this specification refers to any suitable type of vehicle capable of implementing the exemplary embodiments of this disclosure. For example, "vehicle" can mean 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 component. Alternatively or further, without departing from the scope of this disclosure, "vehicle" as used in this specification can mean a bicycle, skateboard, or any other suitable type of unpowered vehicle.

[0025] An exemplary embodiment of this disclosure provides a method related to the calibration of an electronic control unit (ECU) in a vehicle. The method may include: receiving a first set of calibration parameters and corresponding actions using ECU functionality; encoding the first set of calibration parameters and corresponding actions into an encoded message based on an ECU protocol using ECU functionality; and sending the encoded message to an ECU using ECU functionality, the ECU being configured to perform the following actions: decoding the encoded message to obtain multiple batches, wherein each of the multiple batches has calibration parameters and corresponding actions from the first set of calibration parameters; and calibrating the ECU by executing each batch.

[0026] Figure 1 A block diagram illustrating an exemplary physical system architecture related to ECU calibration, representing one or more exemplary implementations.

[0027] Cloud data management and storage device 100, professional equipment 110, and user equipment 120 can provide (e.g., data management and storage services such as SPL). The target ECU 134 can be implemented within an IC (Integrated Circuit) interface 130 (e.g., 32AT). The IC interface 130 includes connectivity options such as optical connectivity 131 (e.g., OBD (Optical Branching Device)) and wireless connectivity 132 (e.g., 5G (5th Generation), Wi-Fi, Bluetooth, etc.), and may also include a diagnostic ECU 133 (using protocols such as DCM (Diagnostic Communication Manager)).

[0028] The IC interface 130 and the target ECU 134 can be connected to either the professional device 110 or the user device 120 via optical connection 131 and wireless connection 132. Specifically, the professional device 110 (which could be a desktop / laptop computer or some other computing device) can specify parameters in more detailed configuration, such as in a coded form. This coded form can be a view of data or can be written as a function. Alternatively, the user device 120 can enable a graphical user interface to specify desired parameters for calibration in a more user-friendly format. A single professional device 110 and user device 120 are shown, but it should be understood that a configuration providing only the professional device 110 or only the user device 120 is possible.

[0029] Figure 2 A block diagram illustrating an exemplary logical system architecture related to ECU calibration, representing one or more exemplary implementations.

[0030] Specialized equipment 210 and user equipment 220 can implement ECU function 240. Specifically, ECU function 240 can enable specialized equipment 210 and user equipment 220 to make certain modifications to the target ECU 260. In addition, specialized equipment 210 and user equipment 220 can use ECU central interface 230, protocol interface 250, and diagnostics 270 (e.g., remote diagnostics).

[0031] The cloud data management and storage unit 200 can implement the ECU central interface 230, which performs actions related to calibration and measurement data management.

[0032] To support temporary calibration, the target ECU 260 can implement a protocol interface 250 that can be used to decode received messages. When using wireless communication, it can be assumed that the vehicle provides an interface enabling remote execution of Unified Diagnostic System (UDS) commands. This interface is represented as diagnostics 270 in the above figure. It should be understood that the UDS is used as an exemplary diagnostic system, and other systems can be used.

[0033] Figure 3 Exemplary message formats and payloads related to ECU calibration are shown, illustrating more than one exemplary implementation. In particular, exemplary message formats that can be sent from a professional device / user device implementing ECU functionality to a target ECU are shown.

[0034] The encoded message (exemplified by using UDS messages) can contain an ID and a payload. The payload can contain a message header and a list of batches.

[0035] The message header can include the major / minor version number of the protocol used, the type of action (read or write), the total length of the list of batches, and a list of the batches themselves.

[0036] A batch can have a batch header that specifies the parameter ID (corresponding to the parameter), the number of actions associated with that specific parameter ID, and a list of actions to be performed within that ID.

[0037] The format of each action can be changed depending on the specific type of action (read / write).

[0038] Regarding write operations, an offset, the length of the data, and the data itself can be provided. The offset is a quantity relative to the base address of the parameter associated with a specific ID. For example, for a given throttle parameter, a base address such as 5 can be provided (in decimal form). The data written for some values ​​can each have an exemplary length of 10. Therefore, in this exemplary scenario, with a length of 10, the offsets associated with each operation are 5, 15, 25, ...

[0039] The process associated with a write operation may include: finding the parameter base address associated with the given parameter ID; calculating the valid write address by appending an offset value; copying the data field to that address according to the length field; and repeating the previous steps according to the number of operations. If the total data processed is less than the specified header length, the process is repeated until the total data is equal to the header length.

[0040] Regarding the read action, the format of the action can simply include an offset and a length. Similarly, given a breakage threshold parameter with an exemplary address of 10, and data provided with an exemplary length of 7, in this exemplary scenario, the offset for a uniform length of 7 can be 10, 17, 24, etc.

[0041] The process executed by the ECU for a read operation may include: finding the parameter base address associated with a given parameter ID; calculating the effective read address by appending an offset value; and copying the data from that address to a buffer, starting at a free address, according to the length field. Therefore, the buffer is a contiguous link for consecutive read operations.

[0042] Based on the above, it is understandable that the same message protocol can be used to employ various parameter formats. Specifically, the data does not necessarily need to have a uniform length for each data point; therefore, since encoding / decoding can be delegated to functions, multiple references can be used, thus allowing for a wider range of parameters.

[0043] Figure 4This is a call flowchart illustrating one or more exemplary implementations of sending a message payload to an ECU for calibration. Client 400 can implement the above. Figure 1 and Figure 2 One of the user equipment / professional equipment shown, on the other hand, target 410 refers to target ECU.

[0044] In step 1, a write operation using an ID is performed via client 400 and then sent to target 410. This can be achieved, for example, by using UDS to send the message to target 410, but it should be understood that other protocols can be used.

[0045] In step 2, when the message is successfully verified, target 410 can receive a negative response code (reserved) indicating that the message has been received normally, such as 0x78.

[0046] In step 3, target 410 can process the payload. This is a calibration-related write operation, so step 3 may include: first decoding the message, then executing each batch and its corresponding action to write the data offset to the address of the parameter ID, thereby performing the actions described above. Figure 3 And the process of recording.

[0047] In step 4a, if an affirmative response is received, the positive response indicates that the payload has been processed normally and indicates to the client 400 that another message can be sent.

[0048] If this is not the case, in step 4b, if a negative response is received, indicating that the payload was not processed correctly in step 3, the negative response indicates to the client 400 that some kind of error has occurred. Correspondingly, a rollback of the calibration action or an error message may be displayed to the user of the client 400.

[0049] Figure 5 A call flowchart illustrating reading parameters from an ECU in one or more exemplary implementations.

[0050] Including with Figure 4 Steps 1, 2, 4a, and 4b are the same, therefore their descriptions are omitted. However, instead of executing the payload, in step 3, the parameter values ​​associated with the respective parameter IDs are copied to the output message box.

[0051] In step 5, a read message is sent from client 500 to target 510 to perform the read using an ID. Based on the message, actions from the batch may include: reading from an address in the ECU's memory based on the offset of the associated parameter ID; and providing them as parameter values ​​to a message box to be sent to client 500.

[0052] Step 6 may also include an affirmative response to indicate to the client 500 that the data has been read successfully.

[0053] Figure 6 This is an exemplary method 600 related to ECU calibration, which is one or more exemplary implementations.

[0054] In action S610, it can be done by utilizing ECU functions (for example, referring to the above). Figure 2 (ECU function 240) to receive the first set of calibration parameters and corresponding actions.

[0055] In action S620, the calibration parameters (and their corresponding actions) of the first set can be encoded into a written encoded message based on the ECU protocol.

[0056] In action S630, the encoded message from action S620 may be sent to the ECU. When the encoded message is received, the ECU may be configured to perform the following actions: decode the encoded message to obtain multiple batches, wherein each batch contains calibration parameters and corresponding actions from the first set of calibration parameters; and accordingly, calibrate the ECU by executing each batch.

[0057] The written encoded message may include a header and a payload, wherein the payload contains a first plurality of batches, and the header may contain at least one version number of the ECU protocol, the type of action, and a length field for the first plurality of batches.

[0058] In addition, the batch header of each batch may contain a parameter identifier, the number of actions to be performed, and a list of actions. Each action includes an offset value relative to the parameter base address, the length of the data, and the data to be written to the ECU.

[0059] In action S640, a response can be received from the ECU based on action S630. A positive response indicates successful calibration, while a negative response indicates unsuccessful calibration.

[0060] In action S650, the calibration parameters of the second set can be encoded into a read encoded message based on the ECU protocol (this read encoded message can be received using ECU functions).

[0061] In action S660, the coded message read from action S650 may be sent to the ECU. Specifically, when the coded message is received, the ECU may be configured to perform the following actions: decode the coded message to obtain a second plurality of batches, each batch having multiple actions corresponding to parameters of a second set; based on the multiple actions, read the ECU to obtain request parameter data corresponding to parameters of the second set; and accordingly, receive the request parameter data.

[0062] Each action in action S660 can include an offset value relative to the parameter base address and the length of the request parameter data.

[0063] It should be understood that the calibration parameters and corresponding actions for the first set can be obtained from (refer to the above) Figure 1 and Figure 2 (And the recorded) user equipment or professional equipment is obtained.

[0064] It is understood that, based on the foregoing, the exemplary embodiments of this disclosure can enable the implementation of a more diverse set of parameters. Furthermore, the payload can be larger than usual due to the inclusion of a list of batches, thus improving the overall speed of calibration as the number of messages between the client device and the target ECU is reduced. Moreover, the architecture allows the client device to be based, for example, on a user device capable of implementing a graphical user interface, thus enabling a more user-friendly and error-free method for calibrating data.

[0065] Figure 7 A diagram illustrating exemplary constituent elements of a system with one or more exemplary embodiments. (e.g.) Figure 7 As shown, system 710 may include at least one bus 711, at least one processor 712, at least one memory 713, at least one storage component 714, at least one input component 715, at least one output component 716, and at least one communication interface 717.

[0066] Assuming that, without departing from the scope of this disclosure, system 710 may include more than Figure 7 The contents shown may have more or fewer constituent elements. For example, in one embodiment, system 710 may include multiple storage constituent elements 714, input constituent elements 715 and output constituent elements 716 may be implemented as transceiver constituent elements, and memory 713 and storage constituent elements 714 may be implemented as storage memory, and may have similar contents.

[0067] Bus 711 can be configured to facilitate or enable communication between the components of system 710. Specifically, bus 711 can connect the components in a manner that enables them to communicate with each other, providing components related to the movement and flow of data for control signals between the components. Bus 711 may include one or more of the following buses that can be implemented in system 710 to enable real-time (or near-real-time) communication and cooperation between the components within system 710: internal bus, address bus, data bus, control bus, Controller Area Network (CAN) bus, Ethernet bus, Peripheral Component Interconnect Express (PCIe) bus, and any other suitable type of bus.

[0068] Processor 712 can be implemented through hardware, firmware, or a combination of hardware and software, and can be configured to perform real-time (or near-real-time) data processing and control of system 710. Processor 712 may include one or more of the following: Central Processing Unit (CPU), Graphics Processing Unit (GPU), Neural Processing Unit (NPU), 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 computing component that can be implemented in system 710. In some implementations, processor 712 may be programmed to perform one or more actions described in this specification. Furthermore, processor 712 may include multiple processing units, each dedicated to performing a specific action.

[0069] Memory 713 may include one or more media for storing temporary data, runtime variables, program instructions, and buffers required for the operation of system 710. Memory 713 may include one or more of the following types of memory that can be implemented in system 710 to store information and / or instructions for use by processor 712: flash memory, read-only memory (ROM), random-access memory (RAM), dynamic or static storage devices (e.g., flash memory, magnetic storage, and / or optical storage), or any other suitable type of memory.

[0070] Storage component 714 can be configured to store non-volatile data such as firmware, configuration settings, calibration data, information, and / or software associated with the operation and use of system 710. For example, storage component 714 may include hard disks (e.g., magnetic disks, optical disks, magneto-optical disks, and / or solid-state drives), compact optical disks (CDs), digital versatile optical disks (DVDs), floppy disks, cassette tapes, magnetic tapes, and / or another type of non-transitory computer-readable media, and include corresponding drives.

[0071] According to an embodiment, the storage component 714 can be configured to store computer-readable or computer-executable instructions that implement one or more actions of the system 710. The storage component 714 can provide the stored information to the memory 713 for execution by the processor 712.

[0072] Input element 715 may include one or more input elements (e.g., touchscreen display, keyboard, keypad, mouse, button, switch, and / or microphone) that allow the system 710 to receive information via user input. Output element 716 may include one or more output elements (e.g., display, speaker, navigation device, one or more light-emitting diodes (LEDs)). Depending on the implementation, input element 715 and / or output element 716 may be arbitrarily selected and may be removed from the system 710.

[0073] At least one communication interface 717 may include a transceiver (e.g., a transceiver and / or separate receiver and transmitter) that enables system 710 to communicate with other components (e.g., ECU, user equipment, etc.) via wired connection, wireless connection, or a combination of wired and wireless connection. For example, communication interface 717 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.

[0074] According to one or more embodiments, the communication interface 717 may include at least one input / output (I / O) interface, at least one network interface, at least one storage interface, or a similar interface that enables components 712 to 716 to communicate with other components. Furthermore, the communication interface 717 may include at least one application programming interface (API) that enables the system 710 (or one or more components included therein) to communicate with one or more software applications (e.g., software applications deployed in the ECU).

[0075] Computer-executable instructions (e.g., software instructions, etc.) may be read into memory 713 and / or storage component 714 via communication interface 717 from another computer-readable medium or from another device (e.g., a remote server, external storage, etc.). When executed, the computer-executable instructions stored in memory 713 and / or storage component 714 may cause processor 712 to execute one or more processes described in this specification. Further or alternatively, hard-wired circuitry may be used instead of software instructions, or in combination with software instructions, to execute one or more processes described in this specification. Therefore, the implementation schemes described in this specification are not limited to any specific combination of hardware circuitry and software.

[0076] It can be assumed that the features, advantages, and importance of the exemplary embodiments described above in this specification are only a part of this disclosure and are not intended to be exhaustive or to limit the scope of this disclosure. The following provides further explanation of the features, constituent elements, configuration, operation, and implementation of exemplary embodiments of this disclosure, as well as the associated technical advantages and importance.

[0077] It is understood that the specific order or hierarchy of function blocks in the process / flowcharts disclosed in this specification are examples of exemplary methods. It is understood that the specific order or hierarchy of function blocks in the process / flowcharts can be reconfigured based on design preferences. Furthermore, some function blocks can be combined or omitted. The appended method claims present the elements of various function blocks in a sample order and are not intended to limit the user to the specific order or hierarchy presented.

[0078] Some implementations may involve systems, methods, and / or computer-readable media at any level of conceivable technical detail. Furthermore, as described above, one or more of the aforementioned 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 media (multiple)) having computer-readable program instructions to cause a processor (or processor (multiple)) to perform actions.

[0079] A computer-readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium can 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 of the above, but is not limited thereto. A non-exhaustive list of more specific examples related to computer-readable storage media includes portable computer floppy disks, 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 disc read-only memory (CD-ROM), digital versatile optical disc (DVD), memory sticks, floppy disks, punched cards containing instructions, or other mechanically encoded devices such as raised structures in a slot, and any suitable combination of the above. The computer-readable storage medium used in this specification should not be construed as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through an optical fiber), or an electrical signal transmitted through a wire.

[0080] The computer-readable program instructions described in this specification can be downloaded from a computer-readable storage medium to various computing / processing devices, or downloaded via a network such as the Internet, local area network, wide area network, and / or wireless network to an external computer or external storage device. The network may include copper cables, optical fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. Network adapter cards or network interfaces within each computing / processing device receive the computer-readable program instructions from the network and transmit them to the computer-readable storage medium within the respective computing / processing device.

[0081] Computer-readable program code / instructions that perform actions can be any of the following: assembly instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, status setting data, configuration data for integrated circuits, or source code or object code written in any combination of one or more programming languages. These programming languages ​​include object-oriented programming languages ​​such as Smalltalk, C++, or similar languages, as well as procedural programming languages ​​such as "C" or similar languages. Computer-readable program instructions can 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 can 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 can connect to an external computer (e.g., via the internet using an internet service provider). In some implementations, for example, to perform a scheme or action, electronic circuits including programmable logic circuits, field-programmable gate arrays (FPGAs) or programmable logic arrays (PLAs) can use state information of computer-readable program instructions to personalize the electronic circuits, thereby executing computer-readable program instructions.

[0082] To generate a machine, the computer-readable program instructions can be provided to a processor of a SoC, a general-purpose computer, a special-purpose computer, or other programmable data processing device, resulting in the instructions, which, when executed by the processor of the computer or other programmable data processing device, create components that implement the functions / behaviors specified in the function blocks or function blocks(multiple) of 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 function in a particular manner, resulting in a computer-readable storage medium internally storing the instructions comprising an article of manufacture that includes instructions for implementing the functions / behaviors specified in the function blocks or function blocks(multiple) of the flowchart and / or block diagram.

[0083] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus or another device and perform a series of action steps on the computer, other programmable apparatus or other device to generate a computer-implemented process, the result of which is that the instructions executed on the computer, other programmable apparatus or other device implement the functions / behaviors specified in the function blocks or function blocks(multiple) of the flowchart and / or block diagram.

[0084] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and action of conceivable implementations of systems, methods, and computer-readable media in various embodiments. Accordingly, each functional block in a flowchart or block diagram may represent a module, segment, or portion of instructions having one or more executable instructions that implement the specified logical function. Compared to what is depicted in the figures, methods, computer systems, and computer-readable media may include further functional blocks, fewer functional blocks, different functional blocks, or functional blocks with different configurations. In some alternative implementations, the functions described in the functional blocks may be generated regardless of the order in which they are described in the figures. For example, two functional blocks shown consecutively may actually be executed simultaneously or substantially simultaneously, or functional blocks may sometimes be executed in reverse order according to their related functions. It is also worth noting that the functional blocks of the block diagrams and / or flowcharts, and combinations of functional blocks of the block diagrams and / or flowcharts, can be implemented by a system based on dedicated hardware, wherein the dedicated hardware-based system performs the specified function or behavior or executes a combination of dedicated hardware and computer instructions.

[0085] It is evident that the systems and / or methods described in this specification can be implemented in various forms, including 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 is not a limitation of the implementation. Therefore, the actions and behaviors of the system and / or method are described in this specification without reference to specific software code, and it is understood that software and hardware can be designed to implement the system and / or method based on the description in this specification.

[0086] Computer program products including the computer programs described above can also be stored on storage media or distributed via communication lines.

Claims

1. A method related to the calibration of an electronic control unit (ECU), the method comprising: The ECU function is used to receive the calibration parameters and corresponding actions of the first set. Using the ECU function, based on the ECU protocol, the calibration parameters and corresponding actions of the first set are encoded into coded messages; as well as The ECU function is used to send the encoded message to the ECU. The ECU is configured as follows: The encoded message is decoded to obtain multiple batches, each of the multiple batches having calibration parameters and corresponding actions from the calibration parameters of the first set; as well as The ECU is calibrated by performing various batches.

2. The method according to claim 1, wherein, The written encoded message has a header and a payload, wherein the payload contains a first plurality of batches. The head has at least one version number of the ECU protocol, the type of action, and the length of the first plurality of batches.

3. The method according to claim 2, wherein, Each batch header contains a parameter identifier, the number of actions to be performed, and a list of actions. Each action contains an offset value relative to the parameter base address, the length of the data, and the data to be written to the ECU.

4. The method according to any one of claims 1 to 3, wherein, The method further includes: using the ECU function to receive a response based on whether the calibration was successful.

5. The method according to any one of claims 1 to 4, wherein, The method further includes: The ECU function is used to receive parameters from the second set. Using the ECU function and based on the ECU protocol, the calibration parameters of the second set are encoded into a read encoded message; The ECU function is used to send the read encoded message to the ECU, wherein the ECU is configured to decode the read encoded message to obtain a second plurality of batches, each of the second plurality of batches having multiple actions corresponding to parameters of a second set, and the ECU is configured to read the data based on the multiple actions to obtain request parameter data corresponding to parameters of the second set; and The ECU function is used to receive the requested parameter data.

6. The method according to claim 5, wherein, Each of the plurality of actions has an offset value relative to the parameter base address and the length of the request parameter data.

7. The method according to any one of claims 1 to 6, wherein, The calibration parameters and corresponding actions for the first set are obtained from the user equipment.

8. An apparatus related to electronic control unit (ECU) calibration, the apparatus being configured to: Receive the calibration parameters and corresponding actions for the first set; Based on the ECU protocol, the calibration parameters and corresponding actions of the first set are encoded into encoded messages; as well as The encoded message is sent to the ECU. The ECU is configured as follows: The encoded message is decoded to obtain multiple batches, each of the multiple batches having calibration parameters and corresponding actions in the calibration parameters of the first set; as well as The ECU is calibrated by performing various batches.

9. The apparatus according to claim 8, wherein, The written encoded message has a header and a payload, wherein the payload contains a first plurality of batches. The head has at least one version number of the ECU protocol, the type of action, and the length of the first plurality of batches.

10. The apparatus according to claim 9, wherein, Each batch header contains a parameter identifier, the number of actions to be performed, and a list of actions. Each action contains an offset value relative to the parameter base address, the length of the data, and the data to be written to the ECU.

11. The apparatus according to any one of claims 8 to 10, wherein, The device is also configured to receive a response based on whether the calibration was successful.

12. The apparatus according to any one of claims 8 to 11, wherein, The device is also configured to: Receives parameters from the second set; Based on the ECU protocol, the calibration parameters of the second set are encoded into the read encoded message; The read encoded message is sent to the ECU, wherein the ECU is configured to decode the read encoded message to obtain a second plurality of batches, each of the second plurality of batches having a plurality of actions corresponding to the parameters of the second set, and the ECU is configured to read the ECU based on the plurality of actions to obtain request parameter data corresponding to the parameters of the second set; as well as Receive the requested parameter data.

13. The apparatus according to claim 12, wherein, Each of the plurality of actions has an offset value relative to the parameter base address and the length of the request parameter data.

14. The apparatus according to any one of claims 8 to 13, wherein, The calibration parameters and corresponding actions for the first set are obtained from the user equipment.

15. A computer program product comprising a computer program including instructions for performing a method related to the calibration of an electronic control unit (ECU), the method comprising: The ECU function is used to receive the calibration parameters and corresponding actions of the first set. Using the ECU function, based on the ECU protocol, the calibration parameters and corresponding actions of the first set are encoded into coded messages; as well as The ECU function is used to send the encoded message to the ECU. The ECU is configured as follows: The encoded message is decoded to obtain multiple batches, each of the multiple batches having calibration parameters and corresponding actions in the calibration parameters of the first set; as well as The ECU is calibrated by performing various batches.

16. The computer program product according to claim 15, wherein, The written encoded message has a header and a payload, wherein the payload contains a first plurality of batches. The head has at least one version number of the ECU protocol, the type of action, and the length of the first plurality of batches.

17. The computer program product according to claim 16, wherein, Each batch header contains a parameter identifier, the number of actions to be performed, and a list of actions. Each action contains an offset value relative to the parameter base address, the length of the data, and the data to be written to the ECU.

18. The computer program product according to any one of claims 15 to 17, wherein, The method further includes: using the ECU function to receive a response based on whether the calibration was successful.

19. The computer program product according to any one of claims 15 to 18, wherein, The method further includes: The ECU function is used to receive parameters from the second set. Using the ECU function and based on the ECU protocol, the calibration parameters of the second set are encoded into a read encoded message; The ECU function is used to send the read encoded message to the ECU, wherein the ECU is configured to decode the read encoded message to obtain a second plurality of batches, each of the second plurality of batches having multiple actions corresponding to parameters of a second set, and the ECU is configured to read the data based on the multiple actions to obtain request parameter data corresponding to parameters of the second set; and The ECU function is used to receive the requested parameter data.

20. The computer program product according to claim 19, wherein, Each of the plurality of actions has an offset value relative to the parameter base address and the length of the request parameter data.

Images