Non-diagnostic updating method of vehicle configuration code, storage medium, device and equipment

Abstract

The invention provides a non-diagnostic updating method and device for a vehicle configuration code. Cooperative operation of multiple ECUs is achieved through a vehicle-mounted communication network. The method comprises the following steps of: responding to a starting signal of an upper computer, judging whether to send a preparation instruction or not by utilizing logic of a state machine, and packaging and broadcasting the preparation or flashing instruction to each ECU through a user-defined communication protocol; and after receiving the instruction, the ECU identifies the type of the instruction and triggers an internal processing flow, automatically completes diagnosis state switching, security access authentication or configuration code writing operation, and finally feeds back an execution result to the upper computer to form closed-loop control. An instruction frame structure is defined based on a specific CAN frame ID and a data domain format, a configuration item ID mapping and data verification mechanism is supported, an ECU end binds an instruction and write logic through a static or dynamic analysis mechanism, and CRC verification and permission verification are introduced to improve safety. The non-diagnostic updating scheme does not need to depend on a traditional diagnostic protocol stack, remote automatic configuration updating is achieved, updating efficiency and system compatibility are improved, the operation process is simplified, and consistency and safety of whole vehicle configuration are enhanced.

Description

Technical Field

[0001] This invention relates to the technical field of vehicle electronic control unit communication and configuration updates, specifically to a non-diagnostic update method, storage medium, apparatus, and device for vehicle configuration codes. Background Technology

[0002] In existing vehicle electronic control systems, configuration code updates typically rely on standard diagnostic protocol stacks, such as the UDS (Unified Diagnostic Services) protocol. This involves establishing a communication connection between the diagnostic tool and the ECU (Electronic Control Unit) and writing configuration parameters within a specific diagnostic session. This approach requires external diagnostic equipment, is complex, and involves interaction across multiple protocol layers, resulting in low configuration update efficiency. Furthermore, it is limited by the communication bandwidth and response latency of the diagnostic protocol, making it difficult to meet the real-time requirements of OEMs for synchronous updates of large batches of ECU configurations in production line or OTA remote update scenarios.

[0003] Furthermore, the implementation of traditional diagnostic protocol stacks relies on the diagnostic protocol stack module on the ECU side. Different manufacturers use different implementations, leading to poor compatibility of configuration update methods in cross-platform applications and increasing system integration and maintenance costs. To write configuration codes, existing technologies typically use instructions based on diagnostic service 0x2E (write to memory) or 0x8D (write parameter identifier), requiring preconditions such as diagnostic session activation and secure access authentication to be met before execution. This process is cumbersome, and each configuration update requires a separate diagnostic connection, making broadcast-style batch updates impossible. Simultaneously, the data format for configuration write operations in diagnostic protocols is usually defined by a unified data identifier (DID) or parameter identifier (PID), limiting scalability and making it difficult to flexibly adapt to the personalized configuration needs of different ECUs. Moreover, the permission verification process relies on interactive operation of external diagnostic equipment, lacking automation mechanisms and limiting the application of configuration updates in unattended scenarios. In summary, existing configuration code update methods based on diagnostic protocol stacks suffer from low update efficiency, poor real-time performance, insufficient compatibility, limited scalability, and low automation, making it difficult to meet the new demands of modern intelligent connected vehicles for flexibility and efficiency in configuration management. Summary of the Invention

[0004] Based on this, in order to solve at least one of the above-mentioned technical problems in the existing vehicle configuration code update process, the present invention proposes a non-diagnostic update method, storage medium, device and equipment for vehicle configuration codes.

[0005] This invention protects a non-diagnostic update method for vehicle configuration codes, enabling coordinated operation of multiple electronic control units (ECUs) through an in-vehicle communication network. The update method includes: responding to a host computer start signal, determining whether the system meets the conditions for sending a configuration code update command through state machine logic; if so, generating a corresponding sending control signal; wherein the configuration code update command includes a preparatory command or a flashing command; according to the sending control signal, the sending module broadcasts the configuration code update command, encapsulated based on a custom communication protocol, to all ECUs in the vehicle through the transmission module; the receiving module receives the command and identifies its type, then triggers the action execution module to execute the corresponding configuration code update process; wherein the configuration code update process includes automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation; after the action execution is completed, each ECU returns the execution result to the host computer through a feedback mechanism to form a closed-loop control.

[0006] Preferably, when the configuration code update instruction is a flashing instruction, the step of the sending module broadcasting the configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle via the transmission module, according to the sending control signal, includes: A command frame structure is defined on the host computer, and the command frame structure includes a specific CAN frame ID and data field format. The configuration code writing request is directly encapsulated in the instruction frame structure through the sending module and broadcast to all ECUs in the vehicle through the transmission module; Each of the ECUs is equipped with a protocol parsing mechanism to identify received instructions and extract the configuration code writing content therein; the protocol parsing mechanism includes a static protocol mapping mechanism or a dynamic instruction parsing mechanism to realize the binding of instruction parsing and configuration code writing logic.

[0007] Preferably, the instruction frame structure definition includes a specific CAN frame ID range as a command space identifier, and the data field contains an opcode, a configuration item identifier, a data length, and a payload field; in the instruction with CAN frame ID 0x123, the first byte of the data field indicates the operation type, wherein the first byte is used to indicate the write configuration code operation, the second to fourth bytes represent the configuration item ID, and the remaining bytes are used to write the data content.

[0008] Preferably, the protocol parsing mechanism on the ECU side includes: Determine the validity of the received instructions; If the validity check passes, the configuration item ID in the instruction is mapped to the corresponding configuration item writing function by preloading the configuration table; The identity of the instruction sender is verified by the verification field or permission identifier carried in the instruction. After the identity verification is successful, the configuration item writing function is called to perform the configuration code writing operation.

[0009] Preferably, when the verification field is CRC16, the ECU calculates the CRC value of the received data and compares it with the CRC value carried in the instruction. If they match, the verification is deemed successful.

[0010] Preferably, in the automatic completion of the diagnostic state switching and secure access process, the ECU automatically switches the diagnostic state after receiving the preparatory command; the diagnostic state includes the session state and secure access state in the UDS protocol stack, wherein the session state includes the default session and the extended session, and the secure access state includes the unlocked state.

[0011] Preferably, after the ECU completes the diagnostic status switch, it returns a ready signal to the sending end via a CAN frame or an Ethernet message, wherein the ready signal includes: a status code, an ECU identifier, and current diagnostic status information; The transmitting end determines whether it receives a ready signal feedback from the ECU within a set time. If the sending end does not receive feedback within the set time, it will automatically resend the preparation command. This invention protects a non-diagnostic update device for vehicle configuration codes, applied to a host computer system in an in-vehicle communication network. The device includes: a status judgment module, used to respond to a host computer start signal and determine whether the system meets the conditions for sending a configuration code update instruction through state machine logic; if so, it generates a corresponding sending control signal; wherein the configuration code update instruction includes: a preparatory instruction or a flashing instruction; an instruction sending module, used to broadcast the configuration code update instruction, encapsulated based on a custom communication protocol, to all electronic control units (ECUs) in the vehicle through a transmission module according to the sending control signal; and a feedback receiving module, used to receive the execution results returned by each ECU to form a closed-loop control; wherein, after receiving the instruction, each ECU identifies its type and triggers the execution of the corresponding configuration code update process, the configuration code update process including: automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation.

[0012] This invention protects an electronic device, comprising: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor and the memory communicate via the bus. The machine-readable instructions are executed by the processor to perform the steps of any of the aforementioned non-diagnostic update methods for vehicle configuration codes.

[0013] This invention protects a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of any of the aforementioned non-diagnostic update methods for vehicle configuration codes.

[0014] This invention protects a non-diagnostic update method for vehicle configuration codes. It defines a command frame structure based on a custom communication protocol on the host computer, encapsulates the configuration code write request using a specific CAN frame ID and data field format, and then broadcasts it to all ECUs in the vehicle. At the ECU end, the configuration code update operation is identified and executed through static or dynamic parsing mechanisms, thus achieving an efficient and flexible configuration update method that bypasses the traditional diagnostic protocol stack. This solution overcomes the limitations of traditional configuration modifications that rely on diagnostic services, improving the real-time performance and system compatibility of configuration updates. Furthermore, the command frame structure defined in this method includes a specific range of CAN frame IDs as command space identifiers. CAN frame ID 0x123 indicates the configuration code write operation. The first byte in its data field is the operation code 0x01, the second to fourth bytes represent the configuration item ID, and subsequent bytes carry the write data content. This makes the command structure clear, highly scalable, and facilitates rapid identification and processing of configuration commands by different ECUs, improving overall vehicle communication efficiency and configuration consistency. Furthermore, this method introduces an embedded state machine module within the ECU, which automatically completes the diagnostic state switching in the UDS protocol after receiving the preparatory command, including the switching between the default session and the extended session. It also achieves an automatic authentication process without external intervention through the secure access key verification logic integrated in the virtual diagnostic state machine or the bootloader, effectively simplifying the permission verification process before configuration updates and improving the system's automation level and security. Attached Figure Description

[0015] The accompanying drawings are provided to further illustrate the invention and form part of the specification. They are used in conjunction with embodiments of the invention to explain the invention and do not constitute a limitation thereof. In the drawings: Figure 1 This is a flowchart illustrating the steps of a non-diagnostic update method for a vehicle configuration code provided in an embodiment of this application. Figure 2 This is a structural block diagram of a non-diagnostic update device for a vehicle configuration code provided in an embodiment of this application. Detailed Implementation

[0016] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. Based on the embodiments of this application, every other embodiment obtained by those skilled in the art without inventive effort falls within the scope of protection of this application.

[0017] Research has revealed that current technologies for updating vehicle configuration codes typically rely on traditional diagnostic protocols (such as UDS), requiring complex diagnostic commands to write the configuration codes. This approach is not only cumbersome, involving multiple diagnostic state switching and security access verification steps, but also inefficient, severely limiting the speed of vehicle production and the flexibility of configuration updates. Furthermore, traditional methods often depend on dedicated diagnostic tools and individual ECU communication, making it difficult to achieve parallel processing across all vehicle ECUs, further impacting overall flashing efficiency. Therefore, there is an urgent need for a technical solution based on non-diagnostic commands that can efficiently coordinate multiple ECUs to complete configuration code updates.

[0018] Based on this, please refer to Figure 1 This application provides a non-diagnostic update method for vehicle configuration codes, which enables the coordinated operation of multiple electronic control units (ECUs) through an in-vehicle communication network. The non-diagnostic update method includes the following steps: Step S101: In response to a host computer start signal, the system uses state machine logic to determine whether the conditions for sending a configuration code update instruction are met. If met, a corresponding sending control signal is generated. The configuration code update instruction includes either a preparatory instruction or a flashing instruction. Step S102: Based on the sending control signal, the sending module broadcasts the configuration code update instruction, encapsulated based on a custom communication protocol, to all ECUs in the vehicle via the transmission module. Step S103: After receiving the configuration code update instruction and identifying its type, the receiving module triggers the action execution module to execute the corresponding configuration code update process. The configuration code update process includes automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation. Step S104: After the action execution is completed, each ECU returns the execution result to the host computer through a feedback mechanism to form a closed-loop control.

[0019] This application provides a non-diagnostic update method for vehicle configuration codes. By employing a custom communication protocol to replace traditional diagnostic commands, it achieves synchronous control and configuration updates for multiple ECUs. This method can automatically complete diagnostic state switching and secure access processes without complex diagnostic service jumps and secure access authentication, thereby significantly improving the efficiency and reliability of configuration code updates. Simultaneously, by broadcasting commands to all ECUs in the vehicle, it supports parallel processing by multiple ECUs, effectively shortening the overall flashing time. It is particularly suitable for rapid off-line configuration setup scenarios on vehicle manufacturing production lines, demonstrating promising application prospects and widespread application value.

[0020] In one optional embodiment, in response to the host computer start signal, the state machine logic determines whether the system meets the conditions for sending the configuration code update instruction. If it does, the corresponding send control signal is generated. When the host computer receives the start signal triggered by the user, the signal processing module starts running the state machine logic to evaluate the current system operation state in order to determine whether the preconditions for sending the configuration code update instruction are met.

[0021] The prerequisites for the configuration code update command include: normal vehicle power supply, all ECUs being in a communicable state, no serious communication failures in the vehicle network, and no other abnormal events that may affect the configuration code update. The state machine logic judges each of the above conditions one by one and, in conjunction with preset state transition rules, determines the current state node of the system.

[0022] In one implementation, the state machine logic is built based on a finite state machine (FSM) model, containing multiple state nodes such as "idle," "ready," and "send preparatory instruction." The transitions between states are driven by both external input signals and internal judgment results. For example, in the "idle" state, if a host computer start signal is detected and all preconditions are met, the state machine transitions to the "ready" state and generates a send control signal to instruct the sending module to prepare to send a configuration code update instruction; if any condition is not met, the system remains in the "idle" state and feeds back system readiness information to the host computer.

[0023] Furthermore, the transmission control signal is a Boolean control signal, with a high level indicating that the transmission of the configuration code update command is allowed, and a low level indicating that transmission is prohibited. This signal is transmitted to the transmission module as an enable signal for subsequent broadcasting of the configuration code update command. Simultaneously, the state machine logic also has a timeout detection mechanism. If the state transition is not completed or a valid feedback signal is not received within the set time, the system automatically enters the error handling process and records relevant state logs for subsequent analysis.

[0024] In summary, by using state machine logic to judge and control the system state in real time, it is ensured that configuration code update instructions are only allowed to be sent when the system is in a safe and stable condition, thereby improving the security and reliability of the entire configuration code update process.

[0025] In step S102, according to the sending control signal, the sending module broadcasts the configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle through the transmission module. Specifically, after the state machine logic determines that the conditions for sending the configuration code update instruction are met, a corresponding sending control signal is generated and transmitted to the sending module to trigger the sending module to execute the corresponding instruction broadcast operation.

[0026] The configuration code update instructions include: preparatory instructions or flashing instructions; In an optional embodiment, the step of broadcasting a configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle via a transmission module, according to a transmission control signal, specifically includes: S1: defining an instruction frame structure on the host computer, wherein the instruction frame structure includes a specific CAN frame ID and data field format; S2: encapsulating the configuration code write request directly in the instruction frame structure via the transmission module and broadcasting it to all ECUs in the vehicle via the transmission module; wherein each ECU is equipped with a protocol parsing mechanism to identify the received instruction and extract the configuration code write content therein; the protocol parsing mechanism includes a static protocol mapping mechanism or a dynamic instruction parsing mechanism to achieve the binding of instruction parsing and configuration code write logic.

[0027] A command frame structure is defined on the host computer. This structure includes a specific CAN frame ID range as a command space identifier, and the data field contains the opcode, configuration item identifier, data length, and payload fields. For example, in the command with CAN frame ID 0x123, the first byte of the data field indicates the operation type, where 0x01 indicates a write configuration code operation. The second to fourth bytes represent the configuration item ID, and the remaining bytes are used to write the data content. This frame structure design gives the commands clear operational semantics and supports flexible expansion of various configuration items.

[0028] When S2 executes, the sending module directly encapsulates the configuration code writing request into the instruction frame structure and broadcasts it to all ECUs in the vehicle. Upon receiving the transmission control signal from the signal processing module, the sending module calls the message constructor in the CAPL script to encapsulate the configuration code data according to a preset frame structure and broadcasts it to all target ECU nodes via the CAN bus. This process does not rely on the UDS diagnostic service, avoiding the complex session switching and secure access interactions of traditional processes, thus improving overall flashing efficiency.

[0029] A protocol parsing mechanism is set up at the ECU end to identify the received instruction frames and extract the configuration code to write the content. Specifically, an independent non-diagnostic instruction parser module is integrated in the Bootloader stage. This non-diagnostic instruction parser module has lightweight status control capabilities to determine the legality of the received instructions and trigger the corresponding operation. If the legality judgment is successful, the configuration item ID in the instruction is mapped to the corresponding configuration item writing function by preloading the configuration table. The configuration table uses a structure array to store the mapping relationship between the configuration item ID and the Flash address, and accelerates the matching process through hashing or lookup tables, thereby improving parsing efficiency and execution response speed.

[0030] The identity of the command sender is verified by the verification field or authorization identifier carried in the command frame. After the identity verification is successful, the configuration item writing function is called to perform the configuration code writing operation. If the command frame contains a CRC16 check field, the ECU calculates the CRC value of the received data and compares it with the CRC value carried in the command. If they match, the verification is considered successful; otherwise, the command is discarded and an error message is sent to the host computer. If the command frame contains an authorization identifier (such as a token), the ECU implements a key verification mechanism. The configuration update operation is only allowed when the token carried in the command is valid, thereby preventing illegal writing and improving the security and reliability of the system.

[0031] Protocol parsing mechanisms include either static protocol mapping or dynamic instruction parsing mechanisms to bind instruction parsing with configuration code writing logic. Static protocol mapping refers to pre-setting a fixed correspondence between instruction frames and configuration item addresses in the ECU software, such as directly mapping CAN frame IDs and data field offsets to the Flash address space. This is suitable for scenarios with few and fixed configuration items. Dynamic instruction parsing, on the other hand, involves matching the receiving end's runtime parsing and writing logic based on field identifiers (such as operation type and configuration item ID) in the instruction. This is suitable for application scenarios with many configuration items and requiring flexible expansion.

[0032] In one optional embodiment, a verification field or authorization identifier is also introduced into the instruction frame, and the ECU performs the write operation only after the verification is successful. Furthermore, this mechanism can be combined with security policy enhancement schemes. For example, in dynamic parsing mode, a verification field (such as CRC16) or authorization identifier can be introduced into the instruction, and the ECU must perform the write operation only after the verification is successful. More advanced applications can implement a key verification mechanism within the ECU, so that only instruction frames with a valid token can trigger the configuration update operation. This scheme does not require external diagnostic tools to participate in the authentication process and is completed entirely within the ECU, thereby improving system security and automation.

[0033] In summary, through the above-mentioned multi-level technical implementation, the sending module can efficiently and accurately broadcast the preparatory instructions or flashing instructions encapsulated based on the custom communication protocol to all ECUs in the vehicle according to the sending control signal, ensuring reliable transmission and correct parsing of instructions in the vehicle network, while taking into account both security and flexibility, thereby constructing a complete vehicle configuration code update mechanism in a non-diagnostic mode.

[0034] In step S103, after the receiving module receives the configuration code update instruction and identifies its type, it triggers the action execution module to execute the corresponding configuration code update process. The configuration code update process includes automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation. Specifically, after the sending module broadcasts the preparatory instruction or flashing instruction to all ECUs in the vehicle through the transmission module, the receiving module of each ECU begins to listen to the instruction frames on the vehicle network and identifies and classifies the instructions according to the preset protocol parsing logic.

[0035] In an optional embodiment, after the receiving module receives the configuration code update instruction and identifies its type, the step of triggering the action execution module to execute the corresponding configuration code update process specifically includes the following sub-steps: In the process of automatically completing the diagnostic state switching and secure access, the ECU automatically switches the diagnostic state after receiving the preparatory command. Specifically, the diagnostic state can be automatically switched internally through an embedded state machine module. This state machine module is used to simulate the standard diagnostic behavior in the UDS protocol stack, including the session state (default session / extended session) and the secure access state (locked / unlocked), so that the key steps in the traditional diagnostic process can be completed without the intervention of external diagnostic tools.

[0036] The embedded state machine module employs a finite state machine (FSM) model, defining multiple diagnostic state nodes, including "Default Session," "Extended Session," "Security Lock," and "Security Unlock." State transitions are triggered by internal events, such as receiving a preparatory command, successful security verification, and timeout retry failure, ensuring logical consistency and predictability during state switching. For example, when the ECU is in the "Default Session" state and receives a preparatory command, the state machine transitions to the "Extended Session," then enters the "Security Lock" state, completes challenge response authentication based on a preset key, and finally enters the "Security Unlock" state to prepare for configuration code updates. An event priority mechanism is introduced during state transitions, where security access failure events take precedence over session switching events to prevent subsequent operations from continuing due to security verification failure, thus improving system security and stability. When integrating secure access key verification logic, the key is stored in an encrypted storage area, and an automatic authentication process is completed through a challenge-response algorithm. For example, a set of keys and corresponding verification algorithms are pre-configured in the Bootloader stage. Upon receiving a preparatory command, the ECU automatically generates a random seed and calculates the response value, comparing it with the response value carried in the command. If they match, authentication is successful; otherwise, subsequent operations are rejected, and an error message is sent to the host computer. After the ECU completes the state switch, it returns a "ready" signal to the sending end. The feedback is implemented via CAN frames or Ethernet messages, including the status code, ECU ID, and current diagnostic status information. The sending end determines whether all target ECUs have entered the ready state based on the feedback result. If not all are ready, the preparatory command is automatically resent or an error handling process is entered, ensuring that the system has good fault tolerance and a retry mechanism.

[0037] A virtual diagnostic state machine is implemented at the ECU application layer to simulate the switching logic of diagnostic states. This state machine is deployed within the application layer task scheduling framework and, combined with the timer and event notification mechanisms provided by the operating system, enables dynamic response and asynchronous processing of diagnostic states. This solution is suitable for scenarios where flexible control of the diagnostic process is required during the main program's execution. It also supports logging and debugging interfaces, facilitating later maintenance and problem tracking.

[0038] Alternatively, a pre-built secure access key verification logic can be integrated into the bootloader to complete the automatic authentication process without external input. This solution is suitable for the rapid preparation stage before flashing, requiring the bootloader to have basic CAN communication capabilities and status judgment logic, and to have a concise code size and high execution efficiency. In this mode, the state machine logic starts immediately after the ECU is powered on, automatically completing the diagnostic state switching and secure access process, greatly shortening the preparation time and improving production line efficiency.

[0039] When the receiving module recognizes that it has received a flash command rather than a preparatory command, it triggers the action execution module to perform a configuration code data writing operation. Specifically, the action execution module calls the underlying Flash driver interface, matches the configuration item ID extracted from the command frame with the write data to the corresponding Flash address space, and performs erase and write operations. After the writing is completed, the ECU generates a feedback signal and transmits it back to the host computer through the vehicle network, forming a closed-loop control.

[0040] In summary, through the synergistic effect of the aforementioned multi-level technical features, the receiving module can accurately identify the instruction type and trigger the corresponding action execution process, enabling the ECU to autonomously complete the diagnostic state switching and secure access process in a non-diagnostic environment, or efficiently execute the configuration code writing operation, thereby constructing a complete, reliable, and efficient non-diagnostic update mechanism for vehicle configuration codes.

[0041] In step S104, after executing the configuration code update instruction, each ECU returns the execution result to the host computer through the feedback mechanism to form a closed-loop control. When the action execution module of each ECU completes the diagnostic state switching, safe access process or configuration code data writing operation, it generates a feedback message containing the execution status, error code, ECU identifier and current diagnostic status, and sends the message to the host computer through the vehicle communication network (such as CAN bus).

[0042] The feedback mechanism employs an event-driven communication strategy, returning a "ready" or "write successful" signal upon successful execution and a corresponding error code and exception description upon failure. The host computer receives and parses the feedback messages from each ECU, performs summary analysis and status judgment. If all ECUs return a successful status, the subsequent flashing steps continue or the update process ends. If some or all ECUs return a failed status, the system determines whether to retry, pause, or terminate the entire update process based on the error type.

[0043] Furthermore, to enhance the reliability and real-time performance of the feedback mechanism, the system supports timeout detection and automatic retransmission. If the host computer does not receive a feedback signal from a certain ECU within a preset time, it determines that the ECU's communication is abnormal and records relevant log information. At the same time, it can selectively resend the command or trigger an alarm prompt to ensure that the entire configuration code update process has good controllability and observability.

[0044] In summary, this feedback mechanism enables a complete closed-loop control process from issuing commands from the host computer and executing them through the ECU to transmitting the execution results back, effectively improving the stability, security, and automation level of the vehicle configuration code non-diagnostic update system.

[0045] Figure 2This is a schematic diagram of a non-diagnostic update device for a vehicle configuration code provided in an embodiment of this application. It is applied to a host computer system in an in-vehicle communication network; such as... Figure 2 As shown, the device includes the following functional modules: The status judgment module 210 is used to respond to the host computer start signal and determine whether the system meets the conditions for sending the configuration code update instruction through the state machine logic. If it meets the conditions, the corresponding sending control signal is generated. The configuration code update instruction includes a preparatory instruction or a flashing instruction. The instruction sending module 220 is used to broadcast the configuration code update instruction encapsulated based on a custom communication protocol to all electronic control units (ECUs) of the vehicle through the transmission module according to the sent control signal. The feedback receiving module 230 is used to receive the execution results returned by each ECU to form a closed-loop control. Upon receiving an instruction, each ECU identifies its type and triggers the execution of the corresponding configuration code update process. The configuration code update process includes: automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation.

[0046] Optionally, when the configuration code update instruction is a flashing instruction, the instruction sending module, according to the sending control signal, broadcasts the configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle via the transmission module. Specifically, this is done by: defining an instruction frame structure on the host computer, the instruction frame structure including a specific CAN frame ID and data field format; directly encapsulating the configuration code write request in the instruction frame structure through the instruction sending module, and broadcasting it to all ECUs in the vehicle via the transmission module; wherein each ECU is equipped with a protocol parsing mechanism to identify the received instruction and extract the configuration code write content; the protocol parsing mechanism includes a static protocol mapping mechanism or a dynamic instruction parsing mechanism to achieve the binding of instruction parsing and configuration code write logic.

[0047] Optionally, the instruction frame structure definition includes a specific CAN frame ID range as a command space identifier, and the data field includes an opcode, configuration item identifier, data length, and payload field; In the instruction with CAN frame ID 0x123, the first byte of the data field indicates the operation type. The first byte is used to indicate the operation of writing configuration codes, the second to fourth bytes represent the configuration item ID, and the remaining bytes are used to write the data content.

[0048] Optionally, the protocol parsing mechanism on the ECU side includes: determining the legality of the received command; if the legality determination is successful, mapping the configuration item ID in the command to the corresponding configuration item writing function by preloading the configuration table; verifying the identity of the command sender by the verification field or permission identifier carried in the command; and after the identity verification is successful, calling the configuration item writing function to perform the configuration code writing operation.

[0049] Optionally, if the verification field is CRC16, the ECU calculates the CRC value of the received data and compares it with the CRC value carried in the instruction. If they match, the verification is deemed successful.

[0050] Optionally, in the automatic completion of the diagnostic state switching and secure access process, the ECU automatically switches the diagnostic state after receiving the preparatory command; the diagnostic state includes the session state and secure access state in the UDS protocol stack, wherein the session state includes the default session and the extended session, and the secure access state includes the unlocked state.

[0051] Optionally, after the ECU completes the diagnostic state switch, it returns a ready signal to the sending end via a CAN frame or Ethernet message. The ready signal includes a status code, an ECU identifier, and current diagnostic status information. The sending end determines whether it receives the ready signal feedback from the ECU within a set time. If the sending end does not receive feedback within the set time, it automatically retransmits the preparation command.

[0052] The non-diagnostic update device for vehicle configuration codes provided in this application embodiment enables the coordinated operation of multiple electronic control units (ECUs) through an in-vehicle communication network. In response to a host computer start signal, the device uses state machine logic to determine whether the system meets the conditions for sending a preparatory instruction and generates a corresponding sending control signal. Based on the sending control signal, the sending module broadcasts the preparatory instruction or flashing instruction, encapsulated based on a custom communication protocol, to all ECUs in the vehicle via the transmission module. The receiving module receives the instruction, identifies its type, and triggers the action execution module to execute the corresponding internal processing flow. This internal processing flow includes automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation. After the action execution is completed, each ECU returns the execution result to the host computer through a feedback mechanism to form a closed-loop control. In this way, efficient and secure updates of vehicle configuration codes can be achieved without relying on traditional diagnostic tools, improving the efficiency of vehicle software maintenance and reducing debugging costs.

[0053] This application provides a schematic diagram of the structure of an electronic device. The electronic device includes a processor, a memory, and a bus.

[0054] The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via a bus. When the machine-readable instructions are executed by the processor, the steps of the non-diagnostic update method for the vehicle configuration code as described in the above method embodiment can be performed. For specific implementation details, please refer to the method embodiment, which will not be repeated here.

[0055] This application also provides a computer-readable storage medium storing a computer program. When the computer program is run by a processor, it can execute the steps of the non-diagnostic update method for vehicle configuration codes as described in the above method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0056] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

[0057] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. The apparatus embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the shown or discussed mutual couplings, direct couplings, or communication connections may be through some communication interfaces; indirect couplings or communication connections between devices or units may be electrical, mechanical, or other forms.

[0058] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0059] In addition, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0060] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0061] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The scope of protection of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be covered within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A non-diagnostic update method for a vehicle configuration code, characterized in that, The update method enables coordinated operation of multiple electronic control units (ECUs) through an in-vehicle communication network; the update method includes: In response to the host computer's startup signal, the system uses state machine logic to determine whether the conditions for sending a configuration code update instruction are met; the configuration code update instruction includes either a preparatory instruction or a write instruction. If the conditions are met, the corresponding transmission control signal is generated; According to the control signal, the sending module broadcasts the configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle through the transmission module; After receiving the configuration code update instruction and identifying its type, the receiving module triggers the action execution module to execute the corresponding configuration code update process; wherein, the configuration code update process includes: automatically completing the diagnostic state switching and security access process, or performing a configuration code data writing operation; After executing the configuration code update command, each ECU returns the execution result to the host computer through a feedback mechanism.

2. The non-diagnostic update method for vehicle configuration codes according to claim 1, characterized in that, When the configuration code update instruction is a flashing instruction, the step of the sending module broadcasting the configuration code update instruction encapsulated based on a custom communication protocol to all ECUs in the vehicle via the transmission module according to the sending control signal includes: A command frame structure is defined on the host computer, and the command frame structure includes a specific CAN frame ID and data field format. The configuration code writing request is directly encapsulated in the instruction frame structure through the sending module and broadcast to all ECUs in the vehicle through the transmission module; Each of the ECUs is equipped with a protocol parsing mechanism to identify received instructions and extract the configuration code writing content therein; the protocol parsing mechanism includes a static protocol mapping mechanism or a dynamic instruction parsing mechanism to realize the binding of instruction parsing and configuration code writing logic.

3. The non-diagnostic update method for vehicle configuration codes according to claim 2, characterized in that, The instruction frame structure definition includes a specific CAN frame ID range as a command space identifier, and the data field contains the opcode, configuration item identifier, data length, and payload fields; In the instruction with CAN frame ID 0x123, the first byte of the data field indicates the operation type. The first byte is used to indicate the operation of writing configuration codes, the second to fourth bytes represent the configuration item ID, and the remaining bytes are used to write the data content.

4. The non-diagnostic update method for vehicle configuration codes according to claim 2, characterized in that, The protocol parsing mechanism on the ECU side includes: Determine the validity of the received instructions; If the validity check passes, the configuration item ID in the instruction is mapped to the corresponding configuration item writing function by preloading the configuration table; The identity of the instruction sender is verified by the verification field or permission identifier carried in the instruction. After the identity verification is successful, the configuration item writing function is called to perform the configuration code writing operation.

5. The non-diagnostic update method for vehicle configuration codes according to claim 4, characterized in that, When the verification field is CRC16, the ECU calculates the CRC value of the received data and compares it with the CRC value carried in the instruction. If they match, the verification is deemed successful.

6. The non-diagnostic update method for vehicle configuration codes according to claim 1, characterized in that, In the automatic completion of the diagnostic state switching and secure access process, the ECU automatically switches the diagnostic state after receiving the preparatory command; The diagnostic status includes the session status and secure access status in the UDS protocol stack, wherein the session status includes the default session and the extended session, and the secure access status includes the unlocked status.

7. The non-diagnostic update method for vehicle configuration codes according to claim 6, characterized in that, After the ECU completes the diagnostic status switch, it returns a ready signal to the sending end via CAN frame or Ethernet message. The ready signal includes: status code, ECU identifier and current diagnostic status information. The transmitting end determines whether it receives a ready signal feedback from the ECU within a set time. If the sending end does not receive feedback within the set time, it will automatically resend the preparation command.

8. A non-diagnostic update device for a vehicle configuration code, characterized in that, A host computer system applied in a vehicle-mounted communication network, the device comprising: The status judgment module is used to respond to the host computer's start signal and determine whether the system meets the conditions for sending the configuration code update instruction through state machine logic. If it does, the corresponding sending control signal is generated. The configuration code update instruction includes either a preparatory instruction or a flashing instruction. The instruction sending module is used to broadcast the configuration code update instruction encapsulated based on a custom communication protocol to all electronic control units (ECUs) in the vehicle through the transmission module, according to the sent control signal. The feedback receiving module is used to receive the execution results returned by each ECU to form a closed-loop control. Upon receiving an instruction, each ECU identifies its type and triggers the execution of the corresponding configuration code update process. The configuration code update process includes: automatically completing the diagnostic state switching and secure access process, or performing a configuration code data writing operation.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. The machine-readable instructions are executed by the processor to perform the steps of the non-diagnostic update method for the vehicle configuration code as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the non-diagnostic update method for the vehicle configuration code as described in any one of claims 1 to 7.

Images