An automobile ECU flashing method and system based on a domain-specific scripting language

Abstract

The application discloses a kind of based on domain-specific scripting language's automobile ECU flashing method and system, belong to the technical field of automobile electronic software, including: expression and configuration layer, for providing flashing script, project configuration file and algorithm plug-in library, the flashing script is written using domain-specific language, for describing flashing process, control logic and data operation;Core execution engine layer is connected with the expression and configuration layer, for dynamically analyzing and executing the flashing script;Service and resource adaptation layer is connected with the core execution engine layer;Basic service layer is used to provide vehicle diagnostic protocol communication and basic service interface of ECU software file analysis.The application realizes the complete decoupling of flashing business logic and core execution engine, through domain-specific scripting language and layered interpretation execution architecture, the development of flashing process is changed from code modification to script configuration, significantly improves development efficiency, system maintainability and scalability.

Description

Technical Field

[0001] This invention belongs to the field of automotive electronic software technology, and in particular relates to a method and system for flashing automotive ECUs based on a domain-specific scripting language. Background Technology

[0002] Currently, automotive ECU flashing host computer software that follows standards such as ISO 14229 (Unified Diagnostic Services, UDS) generally adopts a method of hard-coding business processes for specific ECU models. Developers need to directly write specific flashing sequences (such as diagnostic session control, secure access, memory erasure, data download and verification) into source code in high-level languages ​​such as C# and C++, and complete the flashing by calling a fixed sequence of diagnostic service functions.

[0003] This model has the following inherent drawbacks: 1) Poor flexibility and maintainability: The flashing logic is deeply coupled with the main software. Any process adjustment or addition of ECU support requires modification, recompilation, and re-release of the entire software, resulting in a long iteration cycle. 2) Low reusability and high maintenance costs: Similar flashing steps between different ECUs cannot be effectively abstracted and reused. Updates to the underlying protocol library will trigger large-scale chain modifications and regression testing. 3) High technical threshold: The formulation and modification of flashing strategies rely entirely on software developers with programming skills and a deep understanding of the UDS protocol. The domain knowledge of field engineers cannot be directly utilized. 4) Limited scalability: Each automaker's proprietary and constantly evolving safety and verification algorithms need to be integrated by repeatedly modifying the core code, resulting in numerous software version branches and chaotic management.

[0004] While existing technologies mention the concept of scripting, such as breaking down a general flashing script into multiple sub-scripts and combining them with parameters to improve flexibility, these solutions do not fundamentally restructure the architecture between the flashing process and the host computer software. The scripts still need to handle low-level protocol details, and there are still shortcomings in terms of abstraction level, decoupling from hardware resources, and handling complex algorithm integration.

[0005] Therefore, this invention proposes a method and system for flashing automotive ECUs based on a domain-specific scripting language. Summary of the Invention

[0006] The purpose of this invention is to provide a method and system for flashing automotive ECUs based on a domain-specific scripting language, in order to solve at least one problem existing in the background art.

[0007] To achieve the above objectives, the present invention adopts the following technical solution: The first aspect of the present invention provides an automotive ECU flashing system based on a domain-specific scripting language, comprising: The expression and configuration layer provides the brushing script, project configuration file and algorithm plugin library. The brushing script is written in a domain-specific language and is used to describe the brushing process, control logic and data operation. The core execution engine layer, connected to the expression and configuration layer, is used to dynamically parse and execute the brushing script. The core execution engine layer includes a script parser, an execution context manager, an instruction executor, and a set of functional modules. The script parser performs lexical and syntactic analysis on the brushing script, generating internal instruction sequences or abstract syntax trees. The execution context manager centrally manages and maintains the dynamic state during script execution. The instruction executor schedules the set of functional modules based on the output of the script parser. The set of functional modules includes multiple functional modules for implementing different brushing operations. The service and resource adaptation layer is connected to the core execution engine layer and is used to provide the core execution engine layer with adaptation interfaces for logical resource management and algorithm plugin services. The basic service layer, connected to the service and resource adaptation layer, provides basic service interfaces for vehicle diagnostic protocol communication and ECU software file parsing.

[0008] Furthermore, the execution context manager maintains implicit response objects to automatically carry and store the response data and execution status of the most recent diagnostic service interaction for subsequent script instructions to reference and process.

[0009] Furthermore, the service and resource adaptation layer includes: a logical resource manager, used to map the logical resource identifiers used in the flashing script to the physical storage address of the ECU and the corresponding data block set according to the project configuration file; and a plug-in service manager, used to dynamically load and manage algorithm plug-ins from the algorithm plug-in library, and provide transparent algorithm instance calling services to the algorithm calling modules in the functional module set.

[0010] Furthermore, the domain-specific language supports operational abstractions for diagnostic protocols, built-in response data stream processing, scalable algorithm calls, and structured flow control primitives.

[0011] Based on the same inventive concept, a second aspect of this invention provides a method for flashing an automotive ECU using a domain-specific scripting language, applied to the system described above, comprising: Initialization steps: Load the project configuration file and establish the mapping relationship between logical resource identifiers and physical resources according to the configuration; load the algorithm plugins in the algorithm plugin library; Script parsing steps: The script parser performs lexical and syntactic analysis on the domain-specific writing script to generate an internally executable instruction sequence or abstract syntax tree; Instruction execution steps: The instruction executor traverses and executes the instructions in the instruction sequence or abstract syntax tree. For each instruction, the following sub-steps are performed: Instruction dispatch sub-step: Dispatch the instruction to the corresponding functional module in the functional module set; The parameter parsing and context binding sub-step involves the functional module parsing the instruction parameters and obtaining dynamic parameter values ​​by querying the execution context manager. Service invocation sub-step: The functional module invokes the corresponding service interface of the basic service layer through the service and resource adaptation layer to perform the specific flashing operation; Context update sub-step: Update the state and data in the execution context manager according to the service call result; Flow control steps: Dynamically determine the subsequent execution path based on the status in the execution context manager and the flow control instructions in the script.

[0012] Furthermore, in the service call sub-step, when the data download instruction is executed, the data transmission module parses the logical resource identifier in the instruction into a specific list of data blocks and a target address through the logical resource manager, and cyclically calls the data transmission service interface of the basic service layer to complete the data download.

[0013] Furthermore, in the service invocation sub-step, when the algorithm invocation instruction is executed, the algorithm invocation module locates and invokes the corresponding algorithm plugin instance through the plugin service manager to perform calculations, and stores the calculation results in the execution context manager.

[0014] Furthermore, following the script parsing step, the following steps are also included: Final guarantee block extraction steps: Extract and cache the final guarantee block instructions defined in the flush script; After the instruction execution step and the flow control step, the final guarantee block instruction of the cache is forcibly executed regardless of whether the main flow ends normally or terminates abnormally.

[0015] A third aspect of the present invention provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the method described above.

[0016] A fourth aspect of the present invention provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the method described above.

[0017] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: 1. This invention transforms the development of the flashing process from "modifying and compiling software" to "writing and debugging scripts" by adopting a two-level architecture of "domain-specific language (KTS) describing business" + "general engine scheduling and execution", which greatly shortens the development cycle and significantly improves efficiency.

[0018] 2. The core execution engine of this invention is highly stable and reusable. Business logic changes are isolated in scripts and plugins, avoiding the risk of introducing new defects by modifying the core code, and greatly reducing the complexity of system maintenance and regression testing costs.

[0019] 3. When this invention supports new encryption or verification algorithms, only an independent plugin DLL needs to be provided, without recompiling and republishing the main program, thus achieving "hot expansion" and perfectly dealing with algorithm fragmentation.

[0020] 4. This invention decouples the flashing process description from the ECU's physical memory layout. The same script can be adapted to ECUs with different memory plans by modifying the configuration, making the script highly reusable and portable.

[0021] 5. This invention provides reliable state support for complex process control through a centralized execution context and ensures reliable state cleanup under any execution path, meeting the requirements of high robustness. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of a four-layer system architecture provided for an embodiment of the present invention.

[0023] Figure 2 This is a schematic diagram of the core execution flow of the script engine provided in an embodiment of the present invention.

[0024] Figure 3 This is a schematic diagram of the UDS instruction execution sequence provided in an embodiment of the present invention.

[0025] Figure 4 This is a schematic diagram of the data download process sequence provided in an embodiment of the present invention. Detailed Implementation

[0026] The technical solutions in the embodiments of the present invention will be clearly and completely described below. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0027] like Figures 1-4As shown, this invention constructs an automotive ECU flashing system based on a domain-specific scripting language. Its core innovation lies in introducing a script interpretation and execution engine as the system's central hub, decoupling the variable flashing business logic from the stable underlying communication infrastructure services through a layered architecture.

[0028] The overall architecture of this system follows a clear hierarchical and modular design principle, as shown in the attached diagram. Figure 1 As shown, it can be divided into four logical levels from top to bottom: (I) System Overall Architecture 1. Expression and Configuration Layer This layer is the user-facing interface layer, which includes: KTS script files: written in a domain-specific language defined in this invention, used to describe the complete brushing process, control logic and data operations in a declarative syntax.

[0029] Project configuration file: Defines logical resource mapping relationships using structured data (such as JSON). For example, it associates the logical identifier "FLASH_A" in the script with a specific physical address, data length, and the corresponding set of parsed binary data blocks.

[0030] Algorithm plugin library: Various security algorithms and verification algorithm entities are encapsulated in the form of dynamic link libraries (DLLs). These plugins strictly follow the unified functional interface defined by the system.

[0031] 2. Core Execution Engine Layer This layer is the central system of this invention, responsible for driving and coordinating the entire flashing process. It employs a modular design and mainly includes: Script parser: Includes a lexical analyzer and a syntax analyzer, responsible for scanning and parsing the input KTS script line by line, converting it into a series of internally recognizable and executable instruction objects or abstract syntax tree (AST) structures.

[0032] Execution Context Manager: As a global singleton state container, it is responsible for centrally managing and maintaining all dynamic states throughout the entire lifecycle of script execution. This includes user-defined variables, raw response data from the last diagnostic request, lookup tables from logical identifiers to physical resources, system-level control flags (such as exception flags and exit commands), and progress information.

[0033] Instruction executor: As the command scheduling center, it locates and invokes the corresponding dedicated function execution module based on the instruction object type output by the script parser. Its core responsibilities are instruction decoding, parameter verification, locating dependent resources, and timing coordination between execution modules, rather than implementing specific communication or algorithm logic.

[0034] Functional module set: A group of highly cohesive and loosely coupled processor modules, such as: UDS instruction execution module, data block transfer module, arithmetic and logic operation module, flow control module, algorithm call module, etc. Each module encapsulates the specific business logic required to implement a certain type of KTS instruction.

[0035] 3. Service and Resource Adaptation Layer This layer acts as an abstraction layer and adapter between the core engine and the underlying infrastructure, responsible for "translating" high-level instructions from the engine into operations on specific resources. Logical Resource Manager: Manages logical entities such as FlashBlocks. It maintains a logical resource pool. When the engine needs to operate on "FLASH_A", the manager is responsible for resolving it into a specific starting memory address, data length, and a list of multiple binary blocks, thereby achieving complete decoupling between the flashing process description and the ECU's physical storage layout.

[0036] Plugin Service Manager: Responsible for the full lifecycle management of algorithm plugins, including dynamically loading DLLs from specified paths, instantiating algorithm classes that implement specific interfaces, and maintaining a cache pool of algorithm instances. It provides transparent algorithm invocation services to the upper-layer engine.

[0037] 4. Basic Service Layer This layer consists of existing, proven hardware and software components, forming the foundation of stability upon which this system relies, including: Diagnostic Protocol Stack: Fully implements standard vehicle diagnostic protocols such as UDS / OSI, and provides a stable set of service-oriented APIs (e.g., requesting entry into a programming session, transmitting data, executing routines, etc.).

[0038] Bus communication driver: Responsible for low-level frame-level data transmission and reception with vehicle networks (such as CAN FD, Ethernet).

[0039] File parser: Used to parse and load ECU executable files in formats such as HEX and S19, and convert them into memory data models.

[0040] (ii) Design paradigm of domain-specific scripting languages ​​(KTS) The design of the KTS language is fundamentally different from general-purpose scripting languages ​​(such as Python and Lua) or configuration languages ​​(such as XML and JSON). Its core is to create a semantic environment and operational abstraction that closely fits the specific field of "automotive ECU flashing".

[0041] 1. Operational abstraction for diagnostic protocols: The KTS language encapsulates complex UDS service calls into intuitive instructions. For example, the instruction `uds.phy.tx 10 02` does not directly manipulate bytes, but instead declares the business intent of "sending a request to the target ECU (physical addressing) to switch to the programming session (service $10, subfunction $02)". The engine is responsible for translating this into the correct request message, handling the addressing mode, and invoking the underlying protocol stack.

[0042] The data download command `download.transfer "APP"` represents a higher-level transaction abstraction. It isolates the cumbersome details such as data chunking, cyclically sending the `TransferData` service ($36), managing the block sequence counter, and handling flow control. The script writer only needs to focus on the goal of "writing the application image named 'APP' to the ECU".

[0043] 2. Built-in response data stream processing mechanism: The KTS language defines an implicit `&response` object to hold the result of the most recent UDS interaction. This establishes an automated data flow: after any UDS command is executed, its success / failure status and the raw response byte stream are automatically loaded into this context object.

[0044] Subsequent commands can directly consume this data stream. For example, `set seed = response.get.bytes 3 8` means extracting 8 bytes as the seed, starting from the 3rd byte of the previous response. This design allows the secure "request seed - calculate key - send key" handshake process to be expressed concisely and linearly, without requiring scripts to handle intermediate state storage.

[0045] 3. Extensible algorithm calling interface: The commands `calc.crc ALGO_CRC32 "APP"` and `calc.key ALGO_AES_CMAC &seed` provide a calling method independent of specific algorithm implementations. `ALGO_CRC32` and `ALGO_AES_CMAC` serve as algorithm identifiers, which are resolved and bound to the corresponding plugin instance by the plugin service manager at runtime. This allows scripts to invoke various currently known or future-added algorithms in a unified manner.

[0046] 4. Structured process control primitives: The language natively supports control structures such as if / else / endif, while / endwhile, and for / endfor, and allows direct referencing of variables and the &response property in conditional expressions. This enables scripts to dynamically determine the execution path based on the actual response status of the ECU, implementing robust business logic such as "retry three times" or "abort if check fails".

[0047] (III) Working Mechanism of the Core Execution Engine The engine works as a finely controlled, state-driven interpretation and execution loop, the core of which is to gradually transform the declarative description of the KTS script into a series of ordered calls to the underlying services.

[0048] 1. Initialization and Loading Phase: After the engine starts, it first loads the project configuration file. The logical resource manager initializes all FlashBlock objects according to the configuration and establishes a mapping from logical IDs to data models.

[0049] The plugin service manager scans and loads the specified algorithm plugin DLLs, creates algorithm instances, and registers them to the algorithm list.

[0050] 2. Script parsing and instruction pipeline construction: Lexical analysis: ScriptLexer decomposes the character stream of script source code into a series of lexical units (tokens) with distinct types, such as command identifiers, string literals, variable names, numbers, operators, etc.

[0051] Syntax Analysis: ScriptParser receives a stream of tokens, checks their structural validity according to the syntax rules of the KTS language, and constructs an Abstract Syntax Tree (AST) or a linear sequence of instructions that reflects the script's logical hierarchy. For example, it will identify the conditional expression body, the true branch, and the false branch of an if statement.

[0052] 3. Instruction execution and status management loop: The engine begins traversing and executing the AST or instruction sequence. For each instruction: Command dispatch: CommandExecutor dispatches commands to the corresponding functional modules based on their initial keywords (such as display, uds.phy.tx, set).

[0053] Parameter parsing and context binding: The execution module extracts the parameter list from the instructions. For variable references (such as &seedBytes), its current value is immediately queried from the ScriptContext; for string or numeric literals, they are directly converted to their internal representation. For parameters involving logical resources (such as "APP"), they are parsed into specific data objects through the logical resource manager.

[0054] Service Invocation and Adaptation: The execution module forwards the parameterized request to the underlying basic service layer through a predefined adapter interface. The key point is that the execution module itself does not generate any diagnostic messages or directly interact with the bus; it only organizes the invocation parameters and triggers existing, stable service functions. For example, the UDS instruction module will call methods such as RequestDiagnosticSession() or TransferData() provided by the diagnostic protocol stack.

[0055] Context Update: After the underlying service call returns, its execution result (boolean value) and returned data (response message) are synchronously updated to the &response object in the ScriptContext and other related variables. Simultaneously, any user variable assignments (set operations) also take effect at this time.

[0056] 4. Process control and exception handling mechanisms: The flow control module (handling if, while, etc.) evaluates conditional expressions by querying the values ​​of variables in the ScriptContext and the status of &response in real time, thereby dynamically changing the jump direction of the instruction execution pointer to achieve branching and looping.

[0057] The engine has global exception handling and status flags. When any instruction fails to execute or a runtime error occurs, the error flag in the ScriptContext is set. The engine can then decide, based on its strategy, whether to terminate immediately or jump to a specific error handling or cleanup section.

[0058] 5. Resource Security and Clearance Phase: The KTS language supports finally block definitions. During the script parsing phase, all instructions within the finally block are pre-fetched and cached.

[0059] Regardless of whether the main script logic completes normally or terminates prematurely due to an error or an exit command, the cached finally block instructions will be forcibly executed before the engine exits. This ensures that critical cleanup and state reset operations such as "restoring to the default session" and "closing communication" will be performed, meeting the stringent reliability requirements of automotive flashing tools.

[0060] The universal ECU flashing system for automobiles proposed in this invention, based on a domain-specific scripting language, achieves significant breakthroughs over existing technologies in several key dimensions through its innovative architecture design.

[0061] I. Fundamental Advantages Brought by the Core Architecture Structural features: It adopts a two-tier architecture of "domain-specific language (KTS) to describe business" + "general engine scheduling and execution".

[0062] Beneficial effects: The development of the flashing process is transformed from "modifying and compiling software" to "writing and debugging scripts", which greatly shortens the development cycle and significantly improves efficiency.

[0063] II. Engineering Advantages of Modular and Decoupled Design Structural features: A clear four-layer modular architecture (script / configuration layer, core engine layer, adaptation layer, basic service layer), with highly modular internal engine functions.

[0064] Beneficial effects: The core execution engine is highly stable and reusable. Business logic changes are isolated within scripts and plugins, avoiding the risk of introducing new defects by modifying the core code, and greatly reducing the complexity of system maintenance and regression testing costs.

[0065] III. Innovative Design Advantages of Key Subsystems Pluggable Algorithm Framework Structural features: The algorithm is dynamically integrated through a unified interface (such as ICrcAlgorithm) and a plugin manager.

[0066] Beneficial effects: When supporting new encryption or verification algorithms, only an independent plugin DLL needs to be provided, without recompiling and republishing the main program, achieving "hot expansion" and perfectly dealing with algorithm fragmentation.

[0067] Logical block virtualization management Structural features: The storage space is abstracted through the FlashBlock model, and the script uses logical IDs to manipulate the data.

[0068] Beneficial effects: It decouples the flashing process description from the ECU's physical memory layout. The same script can be adapted to ECUs with different memory plans by modifying the configuration, making the script highly reusable and portable.

[0069] Centralized execution context Structural features: ScriptContext manages all states uniformly, supports implicit data streams in the &response block and finally block guarantees.

[0070] Beneficial effects: It provides reliable state support for complex process control and ensures reliable state cleanup under any execution path, meeting the requirements of high robustness.

[0071] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any equivalent substitutions or modifications made by those skilled in the art within the scope of the technology disclosed in the present invention, based on the technical solution and inventive concept of the present invention, should be covered within the scope of protection of the present invention.

Claims

1. A vehicle ECU flashing system based on a domain-specific scripting language, characterized in that, include: The expression and configuration layer provides the brushing script, project configuration file and algorithm plugin library. The brushing script is written in a domain-specific language and is used to describe the brushing process, control logic and data operation. The core execution engine layer, connected to the expression and configuration layer, is used to dynamically parse and execute the brushing script. The core execution engine layer includes a script parser, an execution context manager, an instruction executor, and a set of functional modules. The script parser is used to perform lexical and syntactic analysis on the brushing script to generate internal instruction sequences or abstract syntax trees. The execution context manager is used to centrally manage and maintain the dynamic state during script execution. The instruction executor is used to schedule the set of functional modules according to the output of the script parser; the set of functional modules includes multiple functional modules for implementing different write operations. The service and resource adaptation layer is connected to the core execution engine layer and is used to provide the core execution engine layer with adaptation interfaces for logical resource management and algorithm plugin services. The basic service layer, connected to the service and resource adaptation layer, provides basic service interfaces for vehicle diagnostic protocol communication and ECU software file parsing.

2. The automotive ECU flashing system based on a domain-specific scripting language as described in claim 1, characterized in that, The execution context manager maintains implicit response objects, which automatically carry and store the response data and execution status of the most recent diagnostic service interaction for subsequent script instructions to reference and process.

3. The automotive ECU flashing system based on a domain-specific scripting language as described in claim 1, characterized in that, The service and resource adaptation layer includes: The logical resource manager is used to map the logical resource identifiers used in the flashing script to the physical storage address and corresponding data block set of the ECU, based on the project configuration file. The plugin service manager is used to dynamically load and manage algorithm plugins from the algorithm plugin library, and to provide transparent algorithm instance invocation services to the algorithm invocation modules in the functional module set.

4. The automotive ECU flashing system based on a domain-specific scripting language as described in claim 1, characterized in that, The domain-specific language supports operation abstractions for diagnostic protocols, built-in response data stream processing, extensible algorithm calls, and structured flow control primitives. Operation abstractions for diagnostic protocols encapsulate Unified Diagnostic Service (UDS) calls as declarative instructions. Built-in response data stream processing automatically transmits the response data from the previous service call through implicit objects. Extensible algorithm calls invoke various algorithms implemented by plugins through a unified instruction interface. Structured flow control primitives include conditional branching and loop control instructions.

5. The automotive ECU flashing system based on a domain-specific scripting language as described in claim 1, characterized in that, The functional module set includes at least: a diagnostic instruction execution module, a data transmission module, a flow control module, and an algorithm invocation module; the diagnostic instruction execution module is used to process instructions related to the UDS protocol; the data transmission module is used to process data download and transmission instructions; the flow control module is used to process condition judgment and loop control instructions; and the algorithm invocation module is used to invoke specific algorithm plugins through the service and resource adaptation layer.

6. A method for flashing an automotive ECU based on a domain-specific scripting language, applied to an automotive ECU flashing system based on a domain-specific scripting language as described in any one of claims 1 to 5, characterized in that, include: Initialization steps: Load the project configuration file and establish the mapping relationship between logical resource identifiers and physical resources according to the configuration; Load algorithm plugins from the algorithm plugin library; Script parsing steps: The script parser performs lexical and syntactic analysis on the domain-specific writing script to generate an internally executable instruction sequence or abstract syntax tree; Instruction execution steps: The instruction executor traverses and executes the instructions in the instruction sequence or abstract syntax tree. For each instruction, the following sub-steps are performed: Instruction dispatch sub-step: Dispatch the instruction to the corresponding functional module in the functional module set; The parameter parsing and context binding sub-step involves the functional module parsing the instruction parameters and obtaining dynamic parameter values ​​by querying the execution context manager. Service invocation sub-step: The functional module invokes the corresponding service interface of the basic service layer through the service and resource adaptation layer to perform the specific flashing operation; Context update sub-step: Update the state and data in the execution context manager according to the service call result; Flow control steps: Dynamically determine the subsequent execution path based on the status in the execution context manager and the flow control instructions in the script.

7. The automotive ECU flashing method based on a domain-specific scripting language as described in claim 6, characterized in that, In the service call sub-step, when the data download instruction is executed, the data transmission module parses the logical resource identifier in the instruction into a specific list of data blocks and a target address through the logical resource manager, and cyclically calls the data transmission service interface of the basic service layer to complete the data download.

8. The automotive ECU flashing method based on a domain-specific scripting language as described in claim 6, characterized in that, In the service invocation sub-step, when the algorithm invocation instruction is executed, the algorithm invocation module locates and invokes the corresponding algorithm plugin instance through the plugin service manager to perform calculations, and stores the calculation results in the execution context manager.

9. The automotive ECU flashing method based on a domain-specific scripting language as described in claim 6, characterized in that, Following the script parsing step, the following is also included: Final guarantee block extraction steps: Extract and cache the final guarantee block instructions defined in the flush script; After the instruction execution step and the flow control step, the final guarantee block instruction of the cache is forcibly executed regardless of whether the main flow ends normally or terminates abnormally.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the program, it implements the method as described in any one of claims 6 to 9.

Images