Asset reuse and controlled execution method and system for in-vehicle test case edit execution closed loop

Abstract

The application belongs to the technical field of computer software testing, and particularly relates to an asset reuse and controlled execution method and system for a closed loop of vehicle-mounted test case editing and execution. Standardized test assets are generated through a test editing component, a bus and hardware configuration are packaged into a network container model and bound to storage; a main host loads a configuration model into a running control engine, and an executor dynamically loads DLL to reuse test assets and associate bus resources. The running control engine generates standardized running events from various data sources, a data flow module completes event distribution, SQLite caching and provides a unified data query portal. Operation requests are encapsulated by relying on MMF shared memory IPC and standardized APIs. Bus event-driven assertion verification is adopted, timing is synchronized with a real bus and timing test evidence is retained; hardware and software process faults are monitored in real time, fault protection test assets and execution progress are ensured, breakpoint continuous measurement is supported, and the problems of asset fragmentation, uncontrolled execution, fragmented observation and difficult fault recovery of existing tools are solved.

Description

Technical Field

[0001] This invention belongs to the field of computer software testing technology, and in particular relates to a method and system for asset reuse and controlled execution of closed-loop editing and execution of vehicle-mounted test cases. Background Technology

[0002] In the fields of hardware-in-the-loop (HiL) bench testing of automotive bus and automated testing of electronic control units (ECUs), the editing, execution, and management of test cases are core aspects of ensuring the quality of automotive software. With the increasing complexity of automotive electronic and electrical architectures and the surge in the number of ECUs, the amount of signal interaction carried by the automotive CAN bus is growing exponentially, placing unprecedented demands on the efficiency, reliability, and asset reuse capabilities of testing systems.

[0003] In existing technical solutions, CAN bus testing software primarily adopts an architecture that separates the test editing module from the test execution module. Taking typical commercial CAN testing tools and self-developed single-function test programs as examples, the editing end typically builds test cases based on visual tables and graphical interfaces, and the generated edit files are stored in a proprietary format; while the execution end relies on dedicated script files or compiled binary files for automated testing. This design and implementation approach effectively met basic testing needs in the early stages of technological development. However, with the continuous expansion of testing task scale and the increasing complexity of testing scenarios, its inherent structural defects at the principle level have gradually become apparent, becoming a key bottleneck restricting testing efficiency and system reliability.

[0004] First, the lack of a unified data model linking test assets and underlying configurations leads to significant format conversion losses during asset transfer across different stages. Edited assets and executed assets use different serialization formats, and there is no unified parsing logic between them. Each automated test requires a transfer process of "exporting edited files, converting scripts, and importing the executable program," inevitably causing systemic risks such as parameter loss, broken signal binding relationships, missing custom verification logic, and corrupted business templates. Simultaneously, bus configuration information and test cases use independent storage mechanisms. Bus configuration information for the same vehicle model and the same test bench needs to be repeatedly entered in multiple test projects, reducing configuration consistency and severely restricting the cross-project reusability of test assets.

[0005] Secondly, at the test execution control level, existing technical solutions lack a globally unique operational status arbitration control point, resulting in a lack of effective access constraints for test behaviors. Hardware drivers, bus interfaces, script interpreters, ECU simulation programs, and test case executors each independently maintain operational status identifiers. Each module can autonomously initiate bus message transmission, system variable modification, and hardware start / stop operations, leading to numerous illegal execution scenarios: scripts can still issue hardware message commands when the system is in offline playback mode; test cases continue to modify variables after the hardware connection is disconnected; and automated programs continue to execute test steps after the test bench stops running.

[0006] Secondly, at the process architecture level, most commercial testing software runs the test script interpreter, ECU simulation logic, main program UI, and hardware drivers in the same process, resulting in severely insufficient fault isolation capabilities. Once the test script has abnormal conditions such as infinite loops, memory overflows, or illegal memory accesses, it will directly cause the main program and bus hardware drivers to crash synchronously, resulting in serious consequences such as disconnection of the test bench hardware and loss of all bus data being acquired.

[0007] Furthermore, at the data observation level, existing tools use separate data distribution channels for real-time hardware acquisition, offline file playback, ECU simulation output, and test script actions. The Trace message window, curve display module, log recording module, and test report generation module each subscribe to independent data sources. This parallel existence of multiple sets of data processing, caching, and querying logic results in extremely high code redundancy, and the data caching of each module is independent and incompatible with each other.

[0008] Finally, at the level of collaboration between editing and execution, existing tools lack a standardized inter-process interaction channel between the test editing program and the execution program. During batch automated testing, the editing interface and the execution process block and restrict each other. When failures such as hardware disconnection, script exceptions, or ECU process crashes occur, the test progress and cached data will be directly cleared. After the failure is recovered, all test cases must be reloaded from scratch and the bus environment must be reconfigured. The executed test steps and their intermediate verification results cannot be reused, resulting in a significant increase in the overall time consumption of large-scale vehicle automated testing and a significant decrease in test efficiency and resource utilization.

[0009] Therefore, how to build a unified and standardized test asset modeling and storage mechanism in the vehicle-mounted test platform to achieve lossless loading and cross-scenario reuse of assets; how to establish a globally unique runtime status arbitration control point to implement effective access verification and request routing control for test execution behavior; how to achieve secure isolation between test logic and the main program through process isolation and controlled request encapsulation technology; how to build a unified event-driven data flow channel to achieve alignment between test verification timing and real bus data timing; and how to achieve recoverable reuse of test assets and execution progress in the event of a failure have become key technical challenges and urgent problems to be solved by those skilled in the art. Summary of the Invention

[0010] This invention relates to the fields of vehicle bus hardware-in-the-loop testing and automated testing of electronic control units. Specifically, it discloses a method and system for asset reuse and controlled execution of closed-loop vehicle test case editing and execution, aiming to solve technical problems in the prior art such as fragmented test assets, uncontrollable execution behavior, fragmented observation links, and difficulty in fault recovery.

[0011] To achieve the above-mentioned objectives, the present invention adopts the following technical solution: Firstly, a method for asset reuse and controlled execution within a closed loop of onboard test case editing and execution is provided. This method is executed by an onboard testing platform, which includes a main host program, a runtime control engine, a data flow module, a test case editing component, an executor test executor, an IPC process isolation management module, and a standardized calling interface CanSystemAPI. The method includes the following steps: In step S1, standardized test asset modeling and storage are performed. Specifically, a standardized test asset carrier is constructed using a test case editing component, generating a complete set of test assets including a .tsoproj test project file, a .tt test case table, a parameter configuration file, and an Output DLL custom function library. Simultaneously, project configuration, DBC network matrix, ECU topology, system variables, and hardware measurement configuration are read and encapsulated into a globally unified network container configuration model. The complete set of test assets is then associated and bound to the network container configuration model for storage, forming an integrated test asset pool that can be reused across different scenarios.

[0012] In step S2, lossless loading and reuse of assets are performed. When the platform starts, the main host program loads the network container configuration model into the runtime control engine. When a test execution command is triggered, the executor reads the complete set of test assets output in step S1, dynamically loads the Output DLL custom function library through component loader reflection, and directly parses and reuses the test units, test steps, verification logic, and business templates in .tsoproj and .tt files without intermediate format translation. The executor reuses the bus signals, system variables, and hardware channel resources already loaded in the network container to complete the automatic association between the test assets and the underlying vehicle bus configuration.

[0013] In step S3, a unified event backbone for the runtime state is constructed. The runtime control engine, acting as the sole arbitration center for runtime states, maintains a standardized state machine containing five states: Starting, Running, Stopping, Stopped, and Crashed. It converts real-time hardware CAN bus messages, offline ASC playback data, ECU interaction commands, and test actions issued by the actuators into standardized runtime events and pushes them to the data flow module. The data flow module creates multiple data channels based on measurement configurations, distributes all runtime events through these channels, caches and writes them to the SQLite database, and generates a unified DataProvider data query entry point.

[0014] In step S4, IPC process isolation and controlled request encapsulation are performed. The test case editing component, actuator, and ECU business logic are deployed as independent sub-processes, and a bidirectional IPC communication channel is built through MMF shared memory combined with event notifications. All test operations of the actuator are encapsulated into standardized IPC requests through CanSystemAPI. These IPC requests include message sending, system variable modification, panel control, log snapshot, and bus reset operation types. The sub-processes only have the permission to initiate requests and do not have the permission to directly operate hardware or run the underlying resources of the control engine.

[0015] In step S5, admission verification and request routing control are performed. The main process IPC resource management unit receives the IPC request output in step S4, and first calls the operation control engine to read the current global running state machine; if the state machine is in a non-running state, the IPC request is directly intercepted and discarded and the test action is terminated; if the state machine is in a running state, the parameter validity of the IPC request is verified, and after the verification is passed, it is forwarded to the operation control engine to perform underlying hardware, variable, and bus operations.

[0016] In step S6, event-driven controlled test assertion execution is performed. The executor subscribes to standardized runtime events of signal change events and state change events based on the data channel of the data flow module built in step S3. When the data flow module distributes bus signals or system variable change events, the executor's built-in wait, verification, and assertion callback logic is triggered. All assertion results are synchronously pushed to the data flow module and written to the SQLite cache to generate test evidence assets with time-series associations.

[0017] In step S7, fault convergence and asset recovery and reuse are performed. The running control engine hardware link, ECU subprocess, and actuator execution process running status are monitored in real time; if hardware disconnection, ECU process crash, or actuator execution abnormality occurs, the running control engine triggers a cascading safety stop command to intercept all new IPC requests; the complete set of test assets stored in step S1, the SQLite test evidence cached in step S3, and the progress of the currently executed test steps are retained; after the fault is resolved, the actuator directly loads the original test assets and progress breakpoints to continue to complete the remaining test execution.

[0018] According to a preferred embodiment of the present invention, in step S1, the standardized test asset carrier is divided into editable assets and executable assets. Editable assets are generated visually by the test case editing component, while executable assets are compiled OutputDLLs. Editable and executable assets share the same serialization parsing logic, enabling bidirectional asset reuse between editing and execution. Through this bidirectional reuse mechanism, test cases in the editing environment can run directly in the execution environment without format conversion or data migration, effectively avoiding information loss during asset transfer between the editing and execution ends.

[0019] According to a preferred embodiment of the present invention, in step S3, the unified DataProvider data query entry output by the data flow module is simultaneously provided to the Trace timing window, Graphics curve display, log recording, test report generation, and executor assertion reading modules for reuse. Online acquisition and offline playback scenarios share the same set of data distribution and caching logic. This design eliminates code redundancy caused by multiple independent data channels in the original technical solution, ensuring that the raw data acquired by the Trace message window, Graphics curve display, log recording, and test report generation modules have a unified timing benchmark, providing a reliable data foundation for fault location and test evidence tracing.

[0020] According to a preferred embodiment of the present invention, in step S4, the IPC channel distinguishes between notification messages and request messages. Notify is used by the running control engine to push variable changes and bus message reception status to child processes, while Request is used by child processes to initiate controlled operations to the main process. Bidirectional communication uses independent MMF memory partitions to isolate data from different ECUs and test actuators. This design, through a memory partitioning isolation mechanism, ensures that the data of each child process does not interfere with each other in multi-ECU parallel testing scenarios. Simultaneously, through the classified management of notification messages and request messages, it achieves standardized and controllable information interaction between the main process and child processes.

[0021] According to a preferred embodiment of the present invention, in step S5, the operation control engine is the globally unique authority on the operating status. All UI panels, ECU subprocesses, and actuators have no independent authority to determine the operating status. The execution access for all test actions is solely determined by the state machine verification result of the operation control engine. This design fundamentally eliminates the illegal execution scenarios caused by each module's autonomous determination of its operating status in the original technical solution. By establishing a unified operating status arbitration center, the compliance and auditability of test execution behaviors are ensured.

[0022] According to a preferred embodiment of the present invention, in step S6, the test assertion abandons the polling detection mechanism and is fully bound to the real-time event channel of the data flow module. The test verification timing is completely aligned with the actual data timing of the vehicle bus, and all assertion results are bound to the original bus events and stored in the SQLite cache as reproducible test evidence assets. This design completely solves the problem of verification timing distortion caused by the polling detection mechanism in the original technical solution. Through the event-driven assertion execution mode, it ensures the precise correspondence between the test verification actions and the actual bus messages in terms of timing, significantly improving the accuracy and reliability of the test assertions.

[0023] According to a preferred embodiment of the present invention, the fault convergence processing in step S7 includes a three-layer hierarchical control mechanism: the first layer is the configuration layer, which automatically rolls back the network container configuration model when asset loading fails; the second layer is the hardware and ECU anomaly layer, which blocks all test actions and saves the current test progress when hardware disconnection or ECU process anomaly is detected; the third layer is the IPC subprocess crash layer, which retains complete test assets and cached data when an IPC subprocess crashes, supporting breakpoint resumption and reuse of the original test assets. This three-layer hierarchical control mechanism provides differentiated processing strategies for different fault types at different levels, ensuring comprehensive protection and efficient recovery of test assets and execution progress.

[0024] Secondly, a closed-loop asset reuse and controlled execution system for in-vehicle test case editing and execution is provided to implement the methods described in any of the above embodiments. This system includes: a main host program module for loading project configuration, managing window layout, and triggering project loading and test execution instructions; a runtime control engine, serving as the sole arbitration center for the global runtime state, with a built-in hardware manager, ECUManager_IPC process coordinator, message decoder, and variable processor, maintaining a standardized runtime state machine, and uniformly processing bus messages and system variable changes; a data flow module, which interfaces with the runtime control engine to build a unified event backbone, divides multiple data channels, configures WriterManager cache to write to an SQLite database, and outputs a unified DataProvider data query interface; and a test case editing component for visually building standardized .tsoproj and .tt test assets and compiling to generate Output. A DLL custom function library; an executor test executor, deployed as an independent subprocess, used to load and parse complete sets of test assets, and encapsulate test operations to generate IPC requests through CanSystemAPI; an IPC process isolation management module, including an IPC resource management unit, an ECU process management unit, and a hidden IPC client agent, to build an MMF shared memory IPC communication channel, enabling subprocess request reception, status monitoring, and exception capture; and a standardized calling interface CanSystemAPI, which encapsulates a unified test operation facade, converting executor and ECU business logic operation instructions into compliant IPC requests.

[0025] The main host program module serves as the top-level entry point for the entire vehicle-mounted testing platform, managing the lifecycle of the test project. Upon startup, this module first loads the project configuration file, parses key information such as the test case set, parameter configuration, and output path defined in the .tsoproj project file, and initializes the main window's interface layout. The main host program maintains the communication link with the runtime control engine. When a user triggers a test execution command, it forwards the command to the runtime control engine for state transition scheduling. Furthermore, the main host program manages the startup and termination of the test case editing component and executor processes, ensuring that each child process is correctly managed throughout the main process's lifecycle.

[0026] The runtime control engine is the core control hub of the entire platform, undertaking three core functions: global runtime status arbitration, hardware resource management, and bus message processing. Its built-in hardware manager manages the allocation and release of CAN bus hardware channels, maintains hardware connection status, and triggers alarms and executes a safety stop procedure when a hardware disconnection occurs. The ECUManager_IPC process coordinator manages the creation, monitoring, and termination of ECU simulation subprocesses, synchronizing status and exchanging instructions with each subprocess through standardized IPC channels. The message decoder parses raw CAN bus messages, converting raw data frames into physically meaningful signal values ​​based on the DBC network matrix. The variable processor maintains the definition, assignment, and query of system variables, supporting variable expression operations and conditional triggering. These four components work collaboratively under the unified scheduling of the runtime control engine, jointly supporting the state transition logic of the standardized state machine.

[0027] The data flow module constructs a unified event backbone connecting the operation control engine and various data consumption modules. This module receives all types of operational events from the operation control engine, including real-time hardware CAN bus messages, offline ASCII playback data streams, ECU simulation output data, system variable change events, and test action execution events, dividing them into multiple independent data channels according to event type. The WriterManager component is responsible for caching the event data from each channel and writing it to an SQLite database, generating persistent records with time-series identifiers. The unified DataProvider data query interface provides standardized data query APIs to upper-layer modules, supporting flexible retrieval based on time range, signal name, event type, and other conditions. The design of the data flow module solves the code redundancy and data fragmentation problems caused by the coexistence of multiple independent data channels in the original technical solution.

[0028] The test case editing component provides a visual test case building environment. This component allows users to create test projects, define test cases, configure test parameters, and write custom test functions through a graphical interface. Test cases are serialized and stored in .tsoproj project files and .tt test case tables. User-defined test functions are compiled into Output DLL files for dynamic loading and invocation during execution. The test case editing component runs integrated with the main host program within the same process, achieving persistent storage and version management of test assets through a standardized asset serialization manager.

[0029] The executor test executor is deployed as an independent subprocess, responsible for loading and executing test assets. Upon startup, the executor receives the test project path and execution parameters from the main host program. It dynamically loads the test project files and Output DLL files through the component loader component, and parses and extracts execution elements such as test units, test steps, verification logic, and business templates. The executor's built-in test scheduler calls the test steps sequentially according to a preset execution order, encapsulating test actions into IPC requests and sending them to the main process through the standardized CanSystemAPI call interface. All assertion results during test execution are written to the SQLite cache through the event channel of the data flow module, forming a time-series-correlated test evidence record.

[0030] The IPC process isolation management module is a key component for achieving secure process isolation and controlled communication. This module comprises three core sub-components: the IPC resource management unit, responsible for receiving and managing IPC requests from each child process, performing admission checks based on the current running state machine state, and forwarding requests that pass the checks to the runtime control engine for low-level operations; the ECU process management unit, responsible for monitoring the running status of ECU simulation child processes, triggering a fault convergence process when an abnormal exit of a child process is detected; and the hidden IPC client agent, running inside the child process, responsible for converting operation requests initiated by the child process into a compliant IPC request format. Through MMF shared memory technology, the IPC process isolation management module establishes an efficient and reliable communication channel between the main process and each child process, while ensuring data security in multi-ECU parallel testing scenarios through a memory partitioning isolation mechanism.

[0031] The standardized CanSystemAPI interface serves as a unified operation facade for actuator and ECU business logic. This interface encapsulates all IPC request construction methods corresponding to test operations, including message sending, variable modification, panel control, log snapshot, and bus reset interfaces. By calling CanSystemAPI, the business logic layer can perform controlled operations on hardware resources, bus channels, and system variables without needing to concern itself with the implementation details of the underlying IPC communication. The design of CanSystemAPI decouples business logic from underlying communication, improving the platform's modularity and maintainability.

[0032] By implementing the above-described technical solution, the present invention can achieve the following technical effects: First, by coordinating standardized test asset modeling and storage steps with lossless asset loading and reuse steps, integrated management of asset editing and execution is achieved. The .tsoproj project files and .tt test case tables generated during the editing phase can be directly loaded and executed by the executor without any format conversion. The Output DLL custom function library is loaded and called at runtime through dynamic reflection. The entire process eliminates intermediate format translation steps, thus resolving issues such as parameter loss, broken signal binding relationships, and missing custom verification logic caused by asset format conversion in the original technical solution.

[0033] Secondly, a unified data flow channel was established through the design of the unified event backbone construction steps and the event-driven controlled test assertion execution steps. The data flow module converts real-time hardware CAN bus messages, offline ASCII playback data, ECU interaction commands, and test action events into standardized runtime events, which are then distributed and processed through multiple data channels. All event data is synchronously written to the SQLite database and a unified DataProvider data query entry is generated. Test assertions are fully bound to the real-time event channel of the data flow module, abandoning the traditional polling detection mechanism. The test verification timing is fully aligned with the actual data timing of the vehicle bus, solving the problem of misjudgment and missed judgment caused by verification timing distortion in the original technical solution.

[0034] Furthermore, by coordinating IPC process isolation and controlled request encapsulation steps with execution admission verification and request routing control steps, secure isolation between the test logic and the main program is achieved. The test case editing component, executor, and ECU business logic are each deployed as independent sub-processes. All test operations are encapsulated into standardized IPC requests through the CanSystemAPI. The sub-processes only have the permission to initiate requests and do not have the permission to directly operate hardware resources.

[0035] Finally, a three-tiered hierarchical control mechanism, encompassing fault convergence and asset recoverability and reuse steps, achieves comprehensive protection of test assets and execution progress. When faults such as hardware disconnection, ECU process crashes, or actuator execution anomalies occur, the runtime control engine triggers a cascading safety stop command, intercepting all new IPC requests while preserving the stored complete set of test assets, SQLite test evidence, and the progress of currently executed test steps. After the fault is resolved, the actuator can directly load the original test assets and progress breakpoints to continue executing the remaining tests without reloading all test cases from scratch, significantly improving the execution efficiency of batch automated vehicle testing. Attached Figure Description

[0036] Figure 1 This is a schematic diagram of the overall structure of the asset reuse and controlled execution system for the closed-loop editing and execution of vehicle-mounted test cases according to the present invention. Figure 2 This is a schematic diagram of the asset reuse and controlled execution method for the closed-loop editing and execution of vehicle-mounted test cases according to the present invention. Figure 3 This is a schematic diagram of the IPC process isolation and communication mechanism of the present invention. Detailed Implementation

[0037] The following is in conjunction with the appendix Figures 1-3 The present invention will be further described in detail below: The present invention relates to an asset reuse and controlled execution method and system for closed-loop editing and execution of vehicle-mounted test cases, which has been fully and thoroughly implemented in an automotive testing platform. The technical solution of the present invention will be described in detail below through several specific embodiments. In the description, the specific implementation methods, key parameter configurations, and data flow relationships of each functional module will be elaborated one by one, strictly following the technical architecture constructed by the present invention.

[0038] See Figure 1 In the overall architecture of the vehicle-mounted testing platform, the main host program serves as the top-level entry point for the entire system, responsible for managing the lifecycle of the test project, maintaining the window layout, and triggering project loading and test execution commands. The main host program runs on a Windows operating system using the .NET Framework architecture and implements the collaborative work of various functional modules using the C# language. Upon startup, the main host program first loads the project configuration file, parses key information such as the test case set, parameter configuration, and output path defined in the .tsoproj project file, and initializes the interface layout of the main window. The main host program maintains its communication link with the core engine through named pipes for inter-process communication with the runtime control engine. When a user triggers a test execution command, the main host program forwards the execution command to the runtime control engine for state transition scheduling of the runtime state machine. Furthermore, the main host program is also responsible for managing the startup and termination of the test case editing component and executor processes, ensuring that each child process is correctly managed within the lifecycle of the main process.

[0039] The runtime control engine is the core control hub of the entire platform, undertaking three core functions: global runtime status arbitration, hardware resource management, and bus message processing. The runtime control engine resides in an independent service process, communicating bidirectionally with the main host program via named pipes. It has four core components: the hardware manager manages the allocation and release of CAN bus hardware channels, maintains hardware connection status, and triggers alarms and executes a safety stop procedure when a hardware disconnection occurs; the ECUManager_IPC process coordinator manages the creation, monitoring, and termination of ECU simulation subprocesses, synchronizing status and exchanging instructions with each subprocess through standardized IPC channels; the message decoder parses raw CAN bus messages, converting raw data frames into physically meaningful signal values ​​based on the DBC network matrix; and the variable processor maintains the definition, assignment, and querying of system variables, supporting variable expression operations and conditional triggering. These four components work collaboratively under the unified scheduling of the runtime control engine, jointly supporting the state transition logic of the standardized state machine.

[0040] See Figure 2 During the standardized test asset modeling and storage process in step S1, the test case editing component provides a complete visual test case building environment. This component supports tree-structured management of test projects and multi-level folder organization of test cases; it provides a test case template library management, supporting user-defined test step templates; it provides a visual editing interface for parameter configuration, supporting DBC signal binding and variable expression configuration; and it provides a custom test function development environment, supporting the writing of test logic in C# and compilation into an Output DLL. Test asset serialization uses a binary format. The .tsoproj file contains complete information such as project metadata, test case references, and configuration parameters, while the .tt file contains execution elements such as the test step sequence, verification logic definition, and wait condition settings.

[0041] In the specific implementation of step S1, the standardized test asset carriers are divided into two main categories: editable assets and execution assets. Editable assets are generated visually by the test case editing component and include .tsoproj project files and .tt test case table files. Execution assets are compiled Output DLL custom function libraries, containing the compiled binary code of user-written custom test functions. Editable and execution assets share the same serialization and parsing logic, enabling bidirectional asset reuse between the editing and execution ends. Through this bidirectional reuse mechanism, test cases in the editing environment can run directly in the execution environment without format conversion or data migration, effectively avoiding information loss during asset transfer between the editing and execution ends.

[0042] Simultaneously, step S1 also performs the task of synchronously reading project configuration, DBC network matrix, ECU topology, system variables, and hardware measurement configuration. When the platform starts, the main host program first instantiates and runs the control engine process, completing the loading of the network container configuration model. The network container internally maintains four core data structures: a DBC network matrix parser, an ECU topology diagram, a system variable dictionary, and a hardware channel mapping table. It reads various types of configuration files through a unified configuration loader and parses them into memory objects. The network container encapsulates the read configuration information into a globally unified configuration model. This configuration model is associated and bound to the complete set of test assets generated in step S1, forming an integrated test asset pool that can be reused across scenarios. This association and binding mechanism ensures a persistent association between test cases and the underlying vehicle bus configuration, enabling test assets to maintain configuration consistency and availability in different test scenarios and hardware environments.

[0043] During the lossless loading and reuse of assets in step S2, when the platform starts, the main host program loads the network container configuration model into the runtime control engine. The configuration loader maintained internally by the runtime control engine parses the DBC network matrix file, extracting key information such as the identifier, data length, signal name, signal start bit, signal length, signal byte order, and signal physical value range of the CAN bus messages, and constructs a signal parsing lookup table. Simultaneously, the runtime control engine parses the ECU topology diagram, establishing a mapping relationship between ECU nodes and bus channels and message signals. The parsing process of the system variable dictionary extracts attributes such as the name, data type, initial value, and variable expression of system variables, constructing a variable management table. The parsing process of the hardware channel mapping table establishes the correspondence between logical channels and physical channels, supporting channel multiplexing and channel switching.

[0044] When the test execution instruction is triggered, the executor reads the complete set of test assets output in step S1. The executor dynamically loads components via reflection using a component loader to achieve runtime loading of the Output DLL custom function library. The component loader uses the .NET Assembly.LoadFrom method to load all Output DLL files referenced in the test project file, and uses reflection to traverse the loaded assemblies, extracting method information for user-defined test functions and constructing a test function call lookup table. The executor directly parses and reuses the test units, test steps, verification logic, and business templates in the .tsoproj project file and .tt test case table without any intermediate format translation. The test project file parser reads the binary content of the .tsoproj file, determines the file version and structure based on the format identifier in the file header, and then parses detailed information such as project metadata, test case reference paths, and configuration parameters line by line. The test case table parser reads the content of the .tt file, parses execution elements such as the test step sequence, verification logic definition, and wait condition settings, and constructs a sequence of test step objects.

[0045] The executor reuses the bus signals, system variables, and hardware channel resources already loaded in the network container to automatically associate the test asset with the underlying vehicle bus configuration. The test step executor calls the test steps sequentially according to a preset execution order. During each test step, it automatically obtains the bus signal identifier and system variable name associated with that step, and retrieves the current signal or variable value through the signal query interface provided by the runtime control engine, eliminating the need for testers to manually configure signal binding relationships. This automatic association mechanism greatly simplifies the test case execution preparation work while ensuring the accuracy of signal binding and avoiding errors that may occur during manual configuration.

[0046] During the construction of the unified event backbone in step S3, the runtime control engine, acting as the sole arbitration center for runtime states, maintains a standardized state machine comprising five states: Starting, Running, Stopping, Stopped, and Crashed. The Starting state indicates that the system is in the process of initializing resources, during which it completes preparatory work such as hardware channel allocation, DBC loading, and variable initialization. The Running state indicates that the system is in normal operation and can execute test actions. The Stopping state indicates that the system is in the process of stopping, during which it completes cleanup work such as test action interception, resource release, and state saving. The Stopped state indicates that the system has completely stopped and all resources have been released. The Crashed state indicates that the system has entered a fault state due to an abnormal situation, during which the system locks all test operations and awaits fault investigation and recovery.

[0047] The state machine only allows state transitions from Starting to Running, Running to Stopping, Stopping to Stopped, and any state to Crashed; it does not allow jump transitions or rollback transitions. For example, the system cannot directly transition from the Starting state to the Stopped state; it must go through the intermediate states of Running and Stopping. Similarly, it cannot directly transition back from the Stopped state to the Running state; it must re-enter the Starting state to initialize resources. This strict state transition rule ensures the standardization of system resource management and the predictability of test execution behavior.

[0048] In the specific implementation of step S3, the operation control engine converts real-time hardware CAN bus messages, offline ASCII playback data, ECU interaction commands, and test actions issued by actuators into standardized operation events, which are then pushed to the data flow module. These standardized operation events employ a unified event data structure, containing four core fields: event timestamp, event type identifier, event source address, and event payload data. The event timestamp is accurate to the microsecond level, obtained based on the system's high-performance timer, ensuring precise timing alignment of multi-source events. The event type identifier uses enumerated values ​​to distinguish different types of events, including bus message events, variable change events, test action events, and ECU interaction events. The event source address identifies the module from which the event originated, supporting parallel event tracing across multiple hardware channels, multiple ECU nodes, and multiple test actuators. The event payload data uses structured binary encoding, employing different data structures and encoding rules according to the event type.

[0049] The data flow module creates multiple data channels based on the MeasurementConfig measurement configuration. The measurement configuration defines parameters such as the number, type, caching strategy, and write target of data channels. The data flow module creates independent data channels for each type of event, including bus message channels, variable change channels, test action channels, and ECU interaction channels. Each channel uses an asynchronous queue to buffer event data; the queue length is configurable, with a default of 1024 event records. The WriterManager component of the data flow module is responsible for writing the event data from each channel to the SQLite database, generating persistent records with time-series identifiers. The write process uses a batch write mode, triggering a batch write operation every 100 events or every 500 milliseconds to reduce database I / O operations and improve write performance.

[0050] The unified DataProvider data query interface output by the data flow module provides a standardized data query API to upper-layer modules. The DataProvider supports various search criteria, including querying by time range, signal name, event type, and event source, and supports combined and fuzzy queries. The DataProvider is also reused by modules for Trace timing windows, Graphics curve display, log recording, test report generation, and executor assertion reading. Online acquisition and offline playback scenarios share the same data distribution and caching logic, ensuring that the raw data acquired by different data consumption modules has a unified timing benchmark, providing a reliable data foundation for fault location and test evidence tracing.

[0051] See Figure 3 In step S4, during the IPC process isolation and controlled request encapsulation process, the test case editing component, executor, and ECU business logic are deployed as independent sub-processes. A bidirectional IPC communication channel is established between the sub-processes and the main process via MMF shared memory combined with event notifications. The IPC process isolation management module uses memory-mapped file technology to achieve cross-process communication. Each sub-process corresponds to an independent MMF memory partition, and the main process maintains read / write permission control for each partition.

[0052] The IPC channel distinguishes between two types of messages: notification messages and request messages. Notification messages are distributed in a broadcast mode and are used by the control engine to push event notifications such as variable changes and bus message reception status to child processes. Child processes obtain real-time status changes during operation by subscribing to the Notify channel, eliminating the need for active polling and reducing communication overhead. Request messages are forwarded in a point-to-point mode and are used by child processes to initiate controlled operation requests to the main process. Child processes only have the permission to initiate requests and do not have direct access to hardware or the underlying resources of the control engine. All test operations are encapsulated into standardized IPC requests through the CanSystemAPI. These IPC requests include message sending, system variable modification, panel control, log snapshots, and bus reset operation types. The construction process of a request includes three steps: operation type encoding, operation parameter serialization, and call stack identifier injection, ensuring the integrity and traceability of the request.

[0053] Bidirectional communication employs independent MMF memory partitions to isolate data from different ECUs and test actuators. The main process allocates an independent MMF memory partition for each child process; the partition size is configurable, with a default of 64KB. Each partition is divided into three areas: a request queue, a response queue, and a shared data area. The request queue uses a circular buffer, supporting sequential writing and reading of requests. The response queue also uses a circular buffer, supporting asynchronous reception of responses. The shared data area stores configuration information and status data shared between the child and main processes. This partitioning and isolation mechanism ensures that data from each child process does not interfere with each other in multi-ECU parallel testing scenarios. Furthermore, the categorized management of notification and request messages standardizes and controls information exchange between the main and child processes.

[0054] During the admission verification and request routing control process in step S5, the main process IPC resource management unit receives the IPC request output in step S4. The IPC resource management unit first calls the status query interface of the runtime control engine to obtain the current status value of the running state machine. The status query interface returns the current status enumeration value, and the IPC resource management unit executes the admission judgment logic based on the status value.

[0055] If the state machine is in a non-running state, i.e., in one of the four states: Starting, Stopping, Stopped, or Crashed, the IPC resource management unit directly intercepts and discards the IPC request and terminates the test. The IPC resource management unit constructs a rejection response message, including the rejection reason code, current system status, request identifier, etc., and returns it to the request initiating child process through the Notify channel, while simultaneously recording a rejection log. The rejection log contains detailed information such as the request initiation time, request type, request parameters, rejection reason, and current system status, providing a basis for post-event auditing and troubleshooting.

[0056] If the state machine is running, the IPC resource management unit performs parameter validity checks on IPC requests. Parameter validity checks include three levels: parameter type check, parameter range check, and resource permission check. Parameter type check verifies whether each parameter in the request conforms to the expected data type for that operation type. For example, the message identifier for a message sending request should be an integer value, and the variable value for a variable modification request should be matched and validated as a string or number according to the variable type. Parameter range check verifies whether the parameter values ​​are within a valid range. For example, the message identifier should be between 0x00000000 and 0x7FFFFFFF, and the data length should be between 0 and 8 bytes. Resource permission check verifies whether the requesting child process has the permission to operate on the target resource, such as access permissions for specific hardware channels or permissions to modify sensitive system variables.

[0057] After successful verification, the IPC resource management unit forwards the IPC request to the operation control engine to perform underlying hardware, variable, and bus operations. The operation control engine calls the corresponding built-in components to perform specific operations based on the request type: message transmission requests are processed by the message decoder, which encodes the signal value into a CAN data frame and sends it to the bus via the hardware manager; variable modification requests are processed by the variable processor, which updates the current value of system variables and triggers variable change events; panel control requests are executed by the main host program's processing module, which updates the UI display status; and log snapshot requests are processed by the data stream module, which generates a data snapshot of the current moment and saves it to the database.

[0058] The operation control engine is the sole global authority on operational status. No UI panel, ECU subprocess, or actuator has independent authority to determine operational status. The execution access for all test actions is solely determined by the state machine verification result of the operation control engine. This design fundamentally eliminates illegal execution scenarios caused by modules autonomously determining their operational status in the original technical solution. By establishing a unified operational status arbitration center, it ensures the compliance and auditability of test execution behaviors.

[0059] During the execution of the event-driven controlled test assertion in step S6, the executor subscribes to two types of standardized runtime events—signal change events and state change events—based on the data channel of the data flow module constructed in step S3. At startup, the executor registers the subscription relationship for these two types of events with the data flow module, specifying the entry address of the event handling callback function. The data flow module maintains an event subscription table, recording the callback function address and subscription conditions of each subscriber.

[0060] When the data flow module distributes bus signals or system variable change events, the executor's built-in wait, verification, and assertion callback logic is triggered. The wait logic uses an event-triggered mechanism instead of a traditional polling mechanism; subsequent test steps are executed when the wait condition is met. The wait condition configuration includes parameters such as wait timeout, expected signal value, expected variable value, and trigger condition type. When an event arrives, the callback function first checks if the event meets the wait condition. If it does, a wait completion flag is set, and subsequent steps are triggered; otherwise, the wait continues until a timeout occurs or the condition is met.

[0061] The verification logic executes test assertions, including assertion types such as signal value equals assertion, signal value does not equal assertion, signal value is greater than assertion, signal value is less than assertion, signal value is within range assertion, variable value equals assertion, and variable value does not equal assertion. All assertion results are synchronously pushed to the data stream module and written to the SQLite cache, generating test evidence assets with time-series associations. Test evidence records include fields such as a unique assertion identifier, associated test step identifier, original event timestamp triggering the assertion, assertion type, expected value, actual value, and assertion result. This time-series associated test evidence storage method simplifies and reliably enables backtracking and analysis of test results.

[0062] The test assertion abandons the polling detection mechanism and is fully bound to the real-time event channel of the data flow module, ensuring that the test verification timing is perfectly aligned with the actual data timing of the vehicle bus. This design completely solves the timing distortion problem caused by the polling detection mechanism in the original technical solution. In the traditional polling mode, the test program queries the signal value at a fixed period. Due to the time difference between the query time and the actual change time of the signal, misjudgment or omission may occur. However, through the event-driven mode, the test verification action is executed immediately when the signal value change event arrives, precisely corresponding to the timing of the real bus message, significantly improving the accuracy and reliability of the test assertion.

[0063] During the fault convergence and asset recoverability and reuse process in step S7, the running status of the control engine hardware link, ECU subprocesses, and actuator execution processes is monitored in real time. The fault monitoring module detects the running status at three levels in real time: the hardware layer monitors the connection status of the CAN bus interface, the hardware manager maintains the hardware connection status table and performs connection checks periodically, and triggers a safety stop process when a hardware disconnection is detected; the ECU process layer monitors the running status of each ECU simulation subprocess, the ECUManager_IPC maintains the subprocess status monitoring queue, and triggers a process restart and test recovery process when an abnormal exit of a subprocess is detected; the actuator execution layer monitors the running status of the test execution subprocesses, the main process maintains the actuator process status monitoring thread, and triggers a test progress saving and breakpoint resume process when an execution abnormality is detected.

[0064] In the event of a hardware disconnection, ECU process crash, or actuator execution anomaly, the operation control engine triggers a cascading safety stop command to intercept all new IPC requests. The safety stop command first sets the state machine to the Stopping state, preventing new test actions from entering the execution queue; then it broadcasts a stop notification to all child processes, instructing them to execute the stop process; next, it waits for all currently executing test steps to complete or time out; finally, it releases hardware channels and memory resources and saves the current system state. During fault handling, the complete set of test assets stored in step S1, the SQLite test evidence cached in step S3, and the progress of currently executed test steps are retained. The test step progress is saved in the form of execution sequence numbers, recording the number of completed test steps and the identifier of the last completed step.

[0065] After the fault is resolved, the actuator directly loads the original test assets and progress breakpoints, and continues to complete the remaining test execution. The breakpoint resume process includes the following steps: First, load the test project file and execution parameters, and establish a communication connection with the runtime control engine; then, read the saved test step progress to determine the starting execution position; next, execute the remaining test steps sequentially from the starting position; finally, generate a complete test report after all test steps have been executed. This breakpoint resume mechanism avoids the time-consuming operation of reloading all test cases from scratch, significantly improving the execution efficiency of batch vehicle automated testing.

[0066] Step S7's fault convergence handling also includes a three-layer hierarchical control mechanism: The first layer is the configuration layer, which automatically rolls back the network container configuration model when asset loading fails. The configuration loader maintains a configuration version stack; when an anomaly is detected in the current configuration loading, it pops up the latest configuration version and attempts to reload. After three consecutive loading failures, loading stops and an alarm is triggered. The second layer is the hardware and ECU anomaly layer, which blocks all test actions and saves the current test progress when a hardware disconnection or ECU process anomaly is detected. The hardware manager immediately stops sending bus messages when a hardware disconnection is detected, and ECUManager_IPC attempts to restart the child process and synchronizes its status with the test execution module when a child process anomaly is detected. The third layer is the IPC child process crash layer, which preserves complete test assets and cached data when an IPC child process crashes, supporting breakpoint resumption and reuse of existing test assets. Child process crash capture is implemented through a process monitoring thread; when an abnormal child process exit code is detected, the test progress saving process is triggered. This three-layer hierarchical control mechanism provides differentiated handling strategies for different fault types at different levels, ensuring comprehensive protection and efficient recovery of test assets and execution progress.

[0067] The following specific embodiment illustrates the application of the method of the present invention in a real-world testing scenario. Assume that automated functional testing of an in-vehicle multimedia domain controller is required, with test scenarios including multimedia playback function testing, navigation function testing, and telephone communication function testing. In step S1, the test engineer uses the test case editing component to create a test project file TestProject.tsoproj, and adds three test case table files PlayMedia.tt, Navigation.tt, and PhoneCall.tt to the project, corresponding to the test cases for the three functional modules, respectively. The test step sequence is defined in PlayMedia.tt: first, a multimedia playback control message is sent to start playback; then, the system variable MediaPlayStatus changes to the Playing state; next, the value of the bus signal MediaCurrentTrack is verified to meet expectations; finally, a stop playback control message is sent and the MediaPlayStatus changes to the Stopped state. Simultaneously, the test engineer uses C# to write a custom test function library PlayMediaFunctions.dll to implement auxiliary functions for playback progress calculation.

[0068] In step S2, when the platform starts, the main host program loads the network container configuration model, parses the DBC file to obtain the bus signal definitions of the multimedia domain controller, parses the ECU topology diagram to establish the mapping relationship between multimedia domain controller nodes and bus channels, and loads the system variable dictionary to obtain the definitions of system variables such as MediaPlayStatus. When the user triggers the test execution command, the executor subprocess starts, the component loader loads the PlayMediaFunctions.dll dynamic library, parses the TestProject.tsoproj and PlayMedia.tt files to extract the test step sequence, and the test executor begins to execute the test steps after it is ready.

[0069] In step S3, the state machine maintained by the running control engine is in a running state. All bus messages, variable changes, and test actions are uniformly distributed and cached through the data flow module. The Trace timing window and Graphics curve display module obtain real-time data through the DataProvider interface, and multiple data consumption modules share a unified data source.

[0070] In step S4, the executor subprocess encapsulates the message into an IPC request through the CanSystemAPI and writes it into the request queue of the MMF memory partition through a hidden IPC client agent. The main process's IPC resource management unit receives the request and performs subsequent processing.

[0071] In step S5, the IPC resource management unit queries the state machine to confirm that it is in the running state, verifies the request parameters, and forwards them to the operation control engine to execute the underlying bus operation after successful verification. The operation control engine calls the message decoder to encode the signal value into a CAN data frame, which is then sent to the bus hardware through the hardware manager.

[0072] In step S6, when a response message arrives from the multimedia controller on the bus, the runtime control engine parses the message into a signal value change event and pushes it to the data stream module. The data stream module then distributes the event to the actuator's subscription callback. The callback function checks whether the MediaPlayStatus variable has reached the expected Playing state. If it has, it waits for the condition to be met before executing subsequent verification steps. After the verification logic is completed, the result is written to the SQLite database as test evidence.

[0073] In step S7, if a CAN hardware disconnection fault occurs during test execution, the operation control engine triggers a safety stop command and saves the progress of the currently executed test steps. After the fault is recovered, the actuator continues to execute the remaining test steps from the breakpoint to complete the entire test process.

Claims

1. A method for asset reuse and controlled execution with a closed-loop system for editing and executing vehicle-mounted test cases, characterized in that: Includes the following steps: S1: Construct a standardized test asset carrier through the test case editing component, generating a complete set of test assets including .tsoproj test project files, .tt test case tables, parameter configuration files, and Output DLL custom function libraries; synchronously read project configuration, DBC network matrix, ECU topology, system variables, and hardware measurement configuration and encapsulate them into a globally unified network container configuration model; associate and bind the complete set of test assets with the network container configuration model for storage, forming an integrated test asset pool that can be reused across scenarios; S2: When the platform starts, the main host program loads the network container configuration model into the runtime control engine; when the test execution command is triggered, the executor reads the complete set of test assets output in step S1, dynamically loads the Output DLL custom function library through component loader reflection, and directly parses and reuses the test units, test steps, verification logic, and business templates in .tsoproj and .tt files without intermediate format translation; the executor reuses the bus signals, system variables, and hardware channel resources already loaded in the network container to complete the automatic association between the test assets and the underlying vehicle bus configuration; S3: The runtime control engine acts as the sole arbitration center for runtime states, maintaining a standardized state machine. The hardware CAN bus real-time messages, offline ASC playback data, ECU interaction commands, and test actions issued by the actuator are uniformly converted into standardized running events and pushed to the data stream module. The data flow module creates multiple types of data channels based on measurement configuration, distributes all runtime events in a channelized manner, caches and writes them to the SQLite database, and generates a unified DataProvider data query entry point. S4: The test case editing component, actuator, and ECU business logic are deployed as independent sub-processes. A bidirectional IPC communication channel is built through MMF shared memory and event notification. All test operations of the actuator are encapsulated into standardized IPC requests through CanSystemAPI. These IPC requests include message sending, system variable modification, panel control, log snapshot, and bus reset operation types. The sub-processes only have the permission to initiate requests and do not have the permission to directly operate the hardware or run the underlying resources of the control engine. S5: The main process IPC resource management unit receives the IPC request output in step S4, first calls the runtime control engine to read the current global runtime state machine; if the state machine is in a non-running state, it directly intercepts and discards the IPC request and terminates the test action; If the state machine is in the running state, it performs parameter validity verification on the IPC request. If the verification passes, it forwards the request to the running control engine to perform underlying hardware, variable, and bus operations. S6: The actuator subscribes to standardized runtime events, including signal change events and state change events, based on the data channel of the data flow module built in step S3; when the data flow module distributes bus signals or system variable change events, it triggers the actuator's built-in wait, verification, and assertion callback logic. All assertion results are synchronously pushed to the data stream module and written to the SQLite cache to generate test evidence assets with time-series correlations; S7: Real-time monitoring of the running status of the hardware link of the operation control engine, ECU sub-processes, and actuator execution processes; If a hardware disconnection, ECU process crash, or actuator execution error occurs, the operation control engine triggers a cascading safety stop command to intercept all new IPC requests; it retains the complete set of test assets stored in step S1, the SQLite test evidence cached in step S3, and the progress of the currently executed test steps; after the fault is resolved, the actuator directly loads the original test assets and progress breakpoints to continue the remaining test execution.

2. The asset reuse and controlled execution method for closed-loop editing and execution of vehicle-mounted test cases according to claim 1, characterized in that, In step S1, the standardized test asset carrier is divided into editable assets and execution assets. Editable assets are generated by visual editing of the test case editing component, while execution assets are the compiled output DLL. Editable assets and execution assets share the same set of serialization parsing logic, realizing bidirectional asset reuse between the editing end and the execution end.

3. The asset reuse and controlled execution method for closed-loop editing and execution of vehicle-mounted test cases according to claim 1, characterized in that, In step S3, the unified DataProvider data query entry output by the data flow module is simultaneously reused by the Trace timing window, Graphics curve display, log recording, test report generation, and executor assertion reading modules. The same set of data distribution and caching logic is shared for online acquisition and offline playback scenarios.

4. The method for asset reuse and controlled execution with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 1, characterized in that, In step S4, the IPC channel distinguishes between notification messages and request messages. Notify is used by the running control engine to push variable changes and bus message reception status to the child process, while Request is used by the child process to initiate controlled operations to the main process. Bidirectional communication uses independent MMF memory partitions to isolate data from different ECUs and test actuators.

5. The method for asset reuse and controlled execution with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 1, characterized in that, In step S5, the operation control engine is the only global authority on the operation status. No UI panel, ECU subprocess, or actuator has independent operation status judgment authority. The execution access of all test actions is solely based on the state machine verification result of the operation control engine.

6. The method for asset reuse and controlled execution with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 1, characterized in that, In step S6, the test assertion abandons the polling detection mechanism and is fully bound to the real-time event channel of the data flow module. The test verification timing is fully aligned with the actual data timing of the vehicle bus. All assertion results are bound to the original bus events and stored in the SQLite cache as reproducible test evidence assets.

7. The method for asset reuse and controlled execution with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 1, characterized in that, Step S7's fault convergence handling includes a three-tiered hierarchical control mechanism: The first layer is the configuration layer, which automatically rolls back the network container configuration model when asset loading fails. The second layer is the hardware and ECU anomaly layer. When a hardware disconnection or ECU process anomaly is detected, all test actions are blocked and the current test progress is saved. The third layer is the IPC subprocess crash layer. When the IPC subprocess crashes, it preserves the complete test assets and cached data, and supports breakpoint resume and reuse of the original test assets.

8. An asset reuse and controlled execution system with a closed-loop system for editing and executing vehicle-mounted test cases, characterized in that: The method for implementing any one of claims 1 to 7 is characterized by comprising: The main host program module is used to load project configuration, manage window layout, and trigger project loading and test execution commands. The runtime control engine, as the sole arbitration center for the global runtime status, has a built-in hardware manager, ECUManager_IPC process coordinator, message decoder, and variable processor. It maintains a standardized runtime state machine and uniformly handles bus messages and system variable changes. The data flow module interfaces with the runtime control engine to build a unified event backbone, divides multiple types of data channels, configures WriterManager to cache and write to the SQLite database, and outputs a unified DataProvider data query interface. The test case editing component is used to visually build standardized test assets (.tsoproj and .tt) and compile them to generate the OutputDLL custom function library. The executor test executor is deployed as an independent subprocess and is used to load and parse complete sets of test assets, and encapsulate test operations to generate IPC requests through the CanSystemAPI; The IPC process isolation management module includes an IPC resource management unit, an ECU process management unit, a hidden IPC client agent, and establishes an MMF shared memory IPC communication channel to realize child process request reception, status monitoring, and exception capture. The standardized calling interface CanSystemAPI encapsulates a unified test operation facade, converting the operation instructions of actuator and ECU business logic into compliant IPC requests.

9. The asset reuse and controlled execution system with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 8, characterized in that, The hardware manager in the operation control engine is responsible for managing the allocation and release of CAN bus hardware channels, maintaining hardware connection status, triggering alarms and executing a safety stop procedure when a hardware disconnection exception occurs; the ECUManager_IPC process coordinator is responsible for managing the creation, monitoring and termination of ECU simulation subprocesses. The message decoder is responsible for parsing the raw CAN bus messages and converting the raw data frames into signal values ​​with physical meaning based on the DBC network matrix; the variable processor is responsible for maintaining the definition, assignment, and query of system variables.

10. The asset reuse and controlled execution system with a closed-loop system for editing and executing vehicle-mounted test cases according to claim 8, characterized in that, The IPC process isolation management module uses memory-mapped file technology to achieve cross-process communication. Each child process corresponds to an independent MMF memory partition, which is divided into three areas: request queue, response queue, and shared data area. The IPC resource management unit is responsible for receiving and managing IPC requests from each child process and performing access verification according to the current running state machine state. The hidden IPC client agent, as a hidden IPC client agent, runs inside the child process and is responsible for converting the operation requests initiated by the child process into a compliant IPC request format.

Images