A sensor and ECU simulation system and method based on multi-protocol fusion

Abstract

The application relates to the technical field of vehicles and provides a sensor and ECU simulation system and method based on multi-protocol fusion, wherein the simulation system adopts a full-stack integrated architecture of hierarchical decoupling, and the simulation system integrates a simulation engine architecture, a multi-protocol fusion communication architecture and a distributed and intelligent expansion architecture, and specifically comprises: a hardware resource pool arranged at a hardware interface layer and a core processing unit, a protocol fusion processing module arranged in a field programmable gate array in the core processing unit based on the multi-protocol fusion communication architecture, an integrated simulation engine arranged on a multi-core central processing unit in the core processing unit based on the simulation engine architecture, an integrated diagnosis and flashing module arranged across a user interaction layer and a software function layer, a safety fault injection module embedded in the multi-protocol fusion communication architecture and the simulation engine architecture, and a distributed cooperative unit. The application can realize a full-process integrated simulation verification platform from a signal level to a system level and from simulation to diagnosis.

Description

Technical Field

[0001] This application relates to the field of vehicle technology, and in particular to a sensor and ECU simulation system and method based on multi-protocol fusion. Background Technology

[0002] As automotive electronic and electrical architectures evolve towards domain control and central computing, in-vehicle networks exhibit typical heterogeneous characteristics. Protocols such as SENT (Single Edge Nibble Transmission), PSI5 (Peripheral Sensor Interface, an open standard based on existing sensor interfaces for peripheral airbag sensors), DSI3 (Distributed System Interface), CAN (Controller Area Network) / CANFD (Controller Area Network with Flexible Data Rate), and in-vehicle Ethernet have long coexisted. In the development and testing of ECUs (Electronic Control Units), simulation solutions suffer from bottlenecks related to protocol isolation, model staticization, and toolchain fragmentation. Among these bottlenecks, protocol isolation manifests as the inability of a single protocol simulation device to construct a realistic heterogeneous network environment, leading to difficulties in system cascading and debugging, and the inability to reproduce the timing and logic problems of cross-protocol communication; model staticization bottleneck manifests as traditional models focusing on static input and output characteristics, failing to adequately simulate dynamic characteristics such as sensor nonlinearity, hysteresis, and temperature drift, as well as the evolution of ECU control logic under complex operating conditions, resulting in low simulation confidence; and toolchain fragmentation bottleneck manifests as simulation, diagnostic, and flashing tools operating independently, with inconsistent data and states, leading to lengthy testing processes and low verification efficiency.

[0003] In summary, there is no integrated simulation and verification platform that covers the entire process from signal level to system level, and from simulation to diagnosis. Summary of the Invention

[0004] This application provides a sensor and ECU simulation system and method based on multi-protocol fusion, which can realize an integrated simulation verification platform for the entire process from signal level to system level and from simulation to diagnosis.

[0005] On one hand, this application provides a sensor and ECU simulation system based on multi-protocol fusion. The simulation system adopts a layered and decoupled full-stack integrated architecture, which includes a user interaction layer, a software function layer, a core processing unit, and a hardware interface layer. Each layer interacts with data and transmits instructions through standardized interfaces. Furthermore, the simulation system integrates a simulation engine architecture, a multi-protocol fusion communication architecture, and a distributed and intelligent expansion architecture, specifically including:

[0006] A hardware resource pool is deployed in the hardware interface layer and the core processing unit to provide multi-protocol access, signal conditioning and heterogeneous computing capabilities.

[0007] The protocol fusion processing module, based on the multi-protocol fusion communication architecture, is deployed within the field-programmable gate array of the core processing unit and is used for hardware-level encoding and decoding, time synchronization, and cross-protocol conversion of multi-protocol data.

[0008] An integrated simulation engine, based on the simulation engine architecture, is deployed on the multi-core central processing unit of the core processing unit. It is used to manage the parameterized model library, schedule model simulation tasks, and generate simulation data.

[0009] An integrated diagnostic flashing module is deployed across the user interaction layer and the software function layer. The integrated diagnostic flashing module works in conjunction with the protocol fusion processing module and the integrated simulation engine to execute diagnostic services and program flashing processes in a simulation environment based on an integrated automotive diagnostic service protocol stack.

[0010] A security fault injection module is embedded in the multi-protocol fusion communication architecture and the simulation engine architecture, and is used to inject faults at different levels and ensure test security.

[0011] The distributed collaborative unit is used to realize scalable simulation and collaborative development from single ECU simulation to vehicle-level system verification based on the distributed and intelligent extended architecture.

[0012] On the other hand, this application provides a sensor and ECU simulation method based on multi-protocol fusion. This method is based on the collaborative operation of the aforementioned full-stack integrated architecture, simulation engine architecture, multi-protocol fusion communication architecture, and distributed and intelligent expansion architecture, and specifically includes the following steps:

[0013] The protocol fusion and synchronization steps are as follows: Based on the multi-protocol fusion communication architecture, hardware-level decoding of multi-protocol data is performed in the field-programmable gate array, the multi-protocol data is converted into a unified intermediate frame format, a unified timestamp is written at the decoding time, and standardized data with conversion quality identifier is generated based on the routing table and semantic mapping rules.

[0014] The dynamic simulation and intelligent optimization steps are as follows: Based on the simulation engine architecture, a parameterized model library is loaded on a multi-core central processing unit, sensor and ECU collaborative simulation is executed according to a hybrid scheduling strategy, model parameters are updated without interruption through a dynamic parameter configuration unit, and the simulation results are compared with reference data using an intelligent analysis and optimization unit to automatically identify deviations and optimize model parameters and test scenarios, and high-value test cases are generated through an AI test case generator.

[0015] The integrated diagnostic and flashing process is as follows: by integrating the diagnostic and flashing module, diagnostic or flashing instructions are generated based on the integrated automotive diagnostic service protocol stack, and sent to the simulated ECU or real ECU through the multi-protocol fusion communication architecture. The response data of the simulated ECU or real ECU is received and fed back to the user interaction layer to complete the diagnostic service or program flashing process.

[0016] The fault injection and verification steps are as follows: Based on the safety fault injection module, preset faults are injected at the simulation level, signal level or hardware level. The fault propagation path is traced through a multi-protocol fusion communication architecture. The impact of the fault on the system performance is analyzed using the simulation engine architecture to verify the system's fault tolerance and degradation strategies.

[0017] The distributed collaborative simulation steps are as follows: a cloud-based simulation cluster based on a distributed and intelligent extension architecture decomposes complex simulation tasks and distributes them to multiple computing nodes for parallel execution; edge nodes based on a distributed and intelligent extension architecture perform real-time hardware-in-the-loop testing; and terminal verification clients based on a distributed and intelligent extension architecture perform remote access and collaborative operations, ensuring data consistency and simulation credibility of each node through a state synchronization mechanism.

[0018] The steps for ensuring data quality and confidence are as follows: perform integrity, consistency and confidence checks on the data after protocol conversion, assess the confidence of simulation results, and detect abnormal states during the simulation process and implement recovery strategies.

[0019] The sensor and ECU simulation system and method based on multi-protocol fusion provided in this application employ a layered and decoupled full-stack integrated architecture. This architecture includes a user interaction layer, a software function layer, a core processing unit, and a hardware interface layer. Each layer interacts with data and transmits instructions through standardized interfaces. The simulation system integrates a simulation engine architecture, a multi-protocol fusion communication architecture, and a distributed and intelligent expansion architecture. Specifically, a hardware resource pool deployed in the hardware interface layer and the core processing unit provides multi-protocol access, signal conditioning, and heterogeneous computing capabilities. A protocol fusion processing module deployed within the field-programmable gate array (FPGA) of the core processing unit, based on the multi-protocol fusion communication architecture, performs hardware-level encoding / decoding and time synchronization of multi-protocol data. This system enables cross-protocol conversion; it manages a parametric model library and schedules model simulation tasks to generate simulation data through an integrated simulation engine deployed on a multi-core central processing unit based on a simulation engine architecture; it integrates a diagnostic flashing module deployed across the user interaction layer and software function layer, collaborating with the protocol fusion processing module and the integrated simulation engine to execute diagnostic services and program flashing processes in the simulation environment based on an integrated automotive diagnostic service protocol stack; it injects faults at different levels and ensures test safety through a security fault injection module embedded in a multi-protocol fusion communication architecture and simulation engine architecture; and it achieves scalable simulation and collaborative development from single ECU simulation to vehicle-level system verification through a distributed collaborative unit based on a distributed and intelligent extension architecture. Through architectural innovation, it achieves unified access, parallel processing, and time synchronization of heterogeneous protocols; and based on high-precision dynamic modeling with environmental awareness, the simulation module can adapt to the dynamics and environmental changes of the real world; and it integrates simulation, diagnosis, and optimization into a data-driven test closed loop, thereby realizing a fully integrated simulation verification platform from the signal level to the system level, and from simulation to diagnosis. Attached Figure Description

[0020] Figure 1 This is a schematic diagram of the full-stack integrated architecture used in the simulation system provided in this application embodiment;

[0021] Figure 2 This is a schematic diagram of the simulation engine architecture integrated into the simulation system provided in this application embodiment;

[0022] Figure 3 This is a schematic diagram of the multi-protocol converged communication architecture for simulation system integration provided in this application embodiment;

[0023] Figure 4 This is a schematic diagram of the distributed and intelligent expansion architecture of the simulation system integration provided in the embodiments of this application;

[0024] Figure 5 This is a structural block diagram of a sensor and ECU simulation system based on multi-protocol fusion provided in an embodiment of this application;

[0025] Figure 6 This is a flowchart illustrating the steps of a sensor and ECU simulation method based on multi-protocol fusion provided in an embodiment of this application. Detailed Implementation

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

[0027] The system provided in this application embodiment possesses multi-protocol fusion communication capabilities, high-precision model simulation, and integrated diagnostic and flashing functions. It is suitable for scenarios such as automotive electronic controller development, hardware-in-the-loop testing, fault diagnosis, program flashing, and system integration verification. Specifically, by constructing a resource-virtualized multi-protocol fusion hardware platform, it achieves unified access, parallel processing, and time synchronization of heterogeneous protocols based on architectural innovation; and based on high-precision dynamic modeling with environmental awareness, the simulation module can adapt to the dynamics of the real world and environmental changes; and based on a data-driven test closed loop, it integrates simulation, diagnosis, and optimization to form a self-evolving intelligent verification environment, thereby realizing a fully integrated simulation verification platform from the signal level to the system level and from simulation to diagnosis.

[0028] In this embodiment of the application, a fully integrated collaborative simulation environment, from top-level user interaction to bottom-level hardware execution, can be constructed.

[0029] Specifically, the simulation system can adopt a layered and decoupled full-stack integrated architecture, referring to... Figure 1 The diagram shows a schematic of the full-stack integrated architecture used in the simulation system provided in this embodiment of the application.

[0030] like Figure 1 As shown, the overall system architecture follows the layered design principle of decoupling resource scheduling and hardware execution. The full-stack integrated architecture 1 can include a user interaction layer 11, a software function layer 12, a core processing unit 13, and a hardware interface layer 14 from top to bottom. Each layer can interact with each other and transmit instructions through standardized interfaces, thus forming a complete software and hardware co-simulation system.

[0031] In some embodiments of this application, the user interaction layer 11 serves as the interaction window between the user and the simulation system, and also as the unified interaction entry point for various architectures. This layer can provide a graphical user interface (GUI) and, through the GUI, provide the user with core functional modules such as the model configuration module 111, the bus monitoring module 112, and the diagnostic flashing module 113. Optionally, the unified GUI can receive user commands for simulation configuration, bus monitoring, diagnostic services, and program flashing, convert these commands into scene configurations, diagnostic requests, and flashing tasks, and send them to the simulation engine and protocol fusion processing module for parallel execution, thereby achieving integrated interaction and execution of the simulation system.

[0032] The model configuration module 111 is mainly used to configure the communication parameters of sensor models, ECU behavior models, and various protocol stacks. Specifically, this module provides a visual parameter configuration interface, allowing users to configure sensor models (such as temperature and pressure), ECU behavior models (such as engine controllers and brake controllers), and communication parameters of various protocol stacks through drag-and-drop, form filling, etc., to achieve rapid construction and parameterized management of complex models.

[0033] The bus monitoring module 112 is primarily used to acquire multi-protocol bus data through a multi-protocol fusion communication architecture, providing data filtering, statistical analysis, and signal waveform display functions, and visually displaying the data stream to achieve real-time visual monitoring of the data stream. Specifically, it can capture and visualize data streams on multi-protocol buses such as SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet in real time; and through the integrated data filtering, statistical analysis, and signal waveform display functions, it provides users with comprehensive network status visibility capabilities.

[0034] The diagnostic flashing module 113 serves as the interactive interface for integrating the diagnostic flashing module, primarily supporting diagnostic command issuance, response monitoring, and program flashing operations. Specifically, the diagnostic flashing module deeply integrates with the automotive diagnostic service protocol stack, such as Unified Diagnostic Services (UDS), providing a complete workflow for diagnostic testing, parameter reading and writing, fault code management, and firmware flashing, achieving a unified diagnostic and maintenance entry point for both simulated and real ECUs. Optionally, users can issue diagnostic commands, monitor responses, and execute program flashing within the same interface, thus avoiding switching between multiple tools.

[0035] In some embodiments of this application, the software functional layer 12 defines the core functional logic of the simulation system, which may include logic modules such as protocol stack module 121, simulation engine module 122, and diagnostic service module 123. These logic modules can ultimately be deployed and run on the core processing unit of the next layer.

[0036] The protocol stack module 121 can implement a complete protocol stack for SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet (supporting 100BASE-T1 / 1000BASE-T1). Specifically, this module is responsible for the encapsulation, parsing, error detection, and flow control of data packets for each protocol, and provides a unified API interface for upper-layer applications, shielding the heterogeneity of the underlying protocols and providing a consistent data access method for the upper-layer simulation engine and diagnostic modules.

[0037] The simulation engine module 122 serves as the scheduling center of the simulation system, managing the parametric model library, specifically including the sensor model library and the ECU behavior model library, which respectively execute high-level protocol logic and protocol physical layer / link layer processing. In other words, the simulation engine is responsible for creating, scheduling, and exchanging model examples, thereby generating high-fidelity simulation data.

[0038] The diagnostic service module 123 fully implements the UDS protocol, supporting key services such as diagnostic session control, data reading and writing, routine control, and program flashing. Specifically, this module can work in conjunction with the protocol stack module to send and receive diagnostic messages via CAN or automotive Ethernet, enabling consistent diagnostic behavior between the simulated ECU and the real ECU in the simulation environment, and providing a unified diagnostic entry point for the in-loop ECU.

[0039] In some embodiments of this application, the core processing unit 13 can primarily employ a collaborative heterogeneous computing architecture of a multi-core central processing unit (CPU) 131 and a field-programmable gate array (FPGA) 132, with functional allocation based on task real-time requirements. Specifically, the multi-core CPU 131 can serve as the control plane, running the operating system, high-level protocol logic, and an integrated simulation engine, while the FPGA 132 can serve as the data plane, executing protocol physical layer / link layer processing, protocol conversion, and time synchronization tasks, providing computing power support for the collaboration of various architectures.

[0040] The multi-core CPU 131 is primarily responsible for running various modules of the operating system and software functional layers, handling tasks with high complexity but relatively low real-time requirements, such as model management, simulation scene scheduling, high-level protocol logic, and diagnostic process control. Optionally, the multi-core CPU can utilize multi-threading to manage different simulation tasks, protocol sessions, and diagnostic sessions in parallel.

[0041] The FPGA 132 primarily focuses on handling highly deterministic, low-latency real-time tasks. Specifically, this is manifested in the FPGA's internal hardware pipelined implementation of hardware encoding / decoding logic for multiple protocol physical and data link layers, a protocol conversion and data synchronization engine, and a time-series control unit for precise signal generation and sampling. Optionally, the FPGA 132 can provide a unified time base for subsequent data synchronization between multiple protocols through an internal global clock network. Specifically, the FPGA can inject a unified, high-precision timestamp into each data unit at the very first moment of data acquisition or generation.

[0042] The collaborative mechanism between the multi-core CPU 131 and FPGA 132 involves interconnecting the multi-core CPU and FPGA via a high-speed PCIe bus and exchanging data using a Direct Memory Access (DMA) mechanism based on descriptor linked lists. Optionally, the FPGA can write pre-allocated priority circular buffers on the CPU side via DMA, containing packaged, timestamped intermediate frame data. High real-time tasks (such as braking instructions and safety fault responses) can employ an interrupt notification mechanism to ensure microsecond-level response; ordinary data flow tasks can use a CPU polling mechanism to reduce interrupt overhead. In practical applications, priority management can be implemented on the FPGA side. Data is marked with priority before being written to the buffer, allowing the CPU to process data according to priority order. This mechanism significantly reduces the number of data copies, ensuring low latency and high throughput in hardware-software collaborative processing.

[0043] In some embodiments of this application, the hardware interface layer 14 serves as the physical boundary of the simulation system and can provide all the interface resources required for connecting with real sensors, ECUs and vehicle networks. Specifically, it includes a multi-protocol communication interface 141, a configurable signal conditioning module 142, a storage module 143 and a power management module 144.

[0044] The multi-protocol communication interface 141 supports multiple communication protocols, such as SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet. Each communication protocol can correspond to an independent interface module, and each interface module can integrate the physical layer transceiver chip, electrical isolation, and protection circuitry corresponding to the respective communication protocol. In other words, the multi-protocol communication interface can inherit the physical layer transceiver circuitry of SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet, providing standard-compliant electrical interfaces and signal characteristics for various automotive buses, thereby supporting unified access and flexible configuration of the aforementioned protocols.

[0045] The configurable signal conditioning module 142 incorporates a programmable gain amplifier (PGA) and an anti-aliasing filter. The gain and cutoff frequency of the PGA and configurable filter can be dynamically configured according to the protocol type and signal characteristics. Specifically, the system software can dynamically configure the gain, bandwidth, and impedance matching parameters based on the characteristics of different sensors or bus signals, thereby achieving adaptive conditioning of signals with different electrical characteristics and ensuring signal quality and measurement accuracy.

[0046] Storage module 143 can specifically use high-speed storage media, mainly for storing model libraries, configuration parameters, test scenarios, runtime logs, and test data generated by the distributed architecture. This module supports dynamic loading and updating of models and configurations, thereby ensuring data support capabilities for large-scale simulations and long-term testing.

[0047] The power management module 144 is mainly used to provide multiple isolated power outputs and has overcurrent, overvoltage, and undervoltage monitoring and protection functions. It provides safe power supply for various system architectures and devices under test, ensuring the safe and reliable operation of the system and devices under test under various operating conditions.

[0048] In this embodiment, the simulation system can integrate a simulation engine architecture, a multi-protocol fusion communication architecture, and a distributed and intelligent expansion architecture, thereby forming a complete software and hardware co-simulation system. This embodiment describes this in layers.

[0049] Specifically, refer to Figure 2 The diagram illustrates the architecture of the simulation engine integrated into the simulation system provided in this embodiment. Figure 2 As shown, the simulation engine architecture 2 may include a simulation task scheduler 21, a model library management unit 22, a model executor 23, a dynamic parameter configuration unit 24, an intelligent analysis and optimization unit 25, and an AI test case generator 26.

[0050] In some embodiments of this application, the simulation task scheduler 21 may adopt a hierarchical hybrid scheduling strategy to clarify the execution and preemption rules of tasks at each level and ensure the timing determinism of simulation tasks.

[0051] Optionally, in the hierarchical hybrid scheduling strategy, the highest priority layer consists of safety-critical tasks, such as functional safety-related tasks like braking and steering. This layer can use a fixed priority scheduling method, and tasks cannot be preempted. The specific execution timing can be strictly guaranteed by the FPGA hardware clock. The high priority layer consists of real-time periodic tasks, mainly covering tasks such as control loop simulation and real-time data acquisition. This layer can use a time-driven scheduling method, and it can be preempted by the highest priority task. The medium priority layer and the low priority layer can use an event-driven scheduling method. The medium priority layer consists of important event tasks, such as diagnostic requests and scene switching instructions, which can preempt low priority tasks. The low priority layer consists of background tasks, such as log recording and data backup, which can be preempted by all high-priority tasks.

[0052] In some embodiments of this application, the model library management unit 22 can be mainly used to manage the parameterized model library, and can support on-demand loading and version management of models.

[0053] Optionally, the parametric model library includes a parametric sensor model library and an ECU behavior model library.

[0054] The sensor model library contains layered models of physical, dynamic and environmental layers, which can accurately simulate its physical characteristics (such as nonlinearity, hysteresis, etc.), response characteristics (such as response time, bandwidth, etc.) and environmental characteristics (such as temperature drift, etc.).

[0055] The sensor model can specifically include a basic simulation model and a characteristic model. The basic simulation model is used to simulate the nonlinear relationship between the measured variable and the sensor output; the characteristic model is used to describe the dynamic response, noise characteristics, and the effects of environmental factors (such as temperature and humidity). In practical applications, environmental factors can be derived from preset parameters of the simulation scenario (such as simulating high-temperature conditions) or acquired in real time through real environmental sensors connected to the system hardware interface layer, achieving dynamic coupling between simulation and the real environment; and the sensor model library supports the introduction of digital twin degradation models for predictive simulation.

[0056] The ECU behavioral model library can implement complex control algorithms (such as Proportional-Integral-Derivative (PID) and fuzzy control) and state machine logic to characterize the control process under different operating conditions. Specifically, the ECU behavioral model library can include control algorithm models and functional models. The control algorithm models can implement control strategies such as PID and fuzzy logic; the functional models can simulate the overall behavioral logic of specific ECU units such as engine control and braking control under different operating conditions.

[0057] In some embodiments of this application, the model actuator 23 is primarily responsible for model calculations, supporting single-step, batch, and parallel execution modes. In sensor-ECU co-simulation, its operation can form a closed-loop control loop. Specifically, the closed-loop control loop can be formed through forward data flow, ECU processing, and feedback data flow to realistically simulate the dynamic characteristics of the system.

[0058] The forward data stream can be represented by the sensor model generating measurement values ​​with timing and noise characteristics based on physical input and environmental conditions. These data are then encapsulated and format-converted by the protocol stack and sent to the target ECU model.

[0059] Specifically, the sensor model can receive physical quantities from the environmental model, ECU output, or user-preset parameters and perform characteristic simulations. Static characteristic simulation can be represented by calculating the output based on nonlinear curves (such as polynomials, lookup tables, etc.), dynamic characteristic simulation can be represented by simulating response delay, noise, etc. through transfer functions, and environmental coupling can be represented by dynamically correcting the output based on temperature drift, voltage fluctuations, etc. The simulated sensor signals can then be encapsulated through a protocol stack and sent to the ECU model or the real bus to achieve encapsulated output.

[0060] Optionally, the physical input can be a physical quantity (such as temperature, pressure, rotational speed, etc.) from the controlled object model, and the environmental input can be environmental parameters from an environmental model or real sensors. Then, when simulating the characteristics of the sensor model, a layered computation can be used. The physical layer computation is represented by a nonlinear mapping y=f(x), where x is the aforementioned physical input parameter, and y is the result of the input x after transformation by the nonlinear mapping f, which is the target output of the mapping. The dynamic layer computation is represented by a transfer function processing Y(s)=G(s)·X(s), where s is the frequency domain complex... The operator, X(s), is the input parameter, G(s), is the transfer function, and Y(s) is the frequency domain output of the input X(s) after processing by the transfer function G(s), representing the frequency domain expression of the dynamic response. The environmental layer calculation is represented as temperature drift / humidity compensation y' = y + Δ(T,H,V), where y is the original output parameter, Δ(T,H,V) is the environmental compensation amount, T is temperature, H is humidity, V is supply voltage, and y' is the output parameter of the original output y after correction by the environmental compensation amount Δ(T,H,V), reflecting the final output value of the ECU under real-world conditions. During feature superposition, measurement noise (such as Gaussian white noise, quantization noise), simulated hysteresis characteristics, and applied sampling delays can be added. Finally, the simulated values ​​can be converted to the corresponding protocol format (such as 12-bit data from SENT), timestamps and quality identifiers can be added, and the data can be sent to the protocol stack for frame encapsulation. The encapsulated data is then sent to the target ECU model or the real ECU via the protocol fusion processing module.

[0061] ECU processing can be manifested as the ECU model performing validity checks and filtering on the input data, then executing internal control algorithms and outputting control commands.

[0062] Feedback data flow can be represented as the ECU output acting on the controlled object model or system environment model through the protocol interface, and its state changes are then fed back to the sensor model to complete the simulation of the closed-loop control link.

[0063] In this embodiment, the closed-loop process executed by the model executor 23 can realistically reflect the dynamic characteristics of the actual system, such as computational and communication delays, providing a high-fidelity environment for control strategy verification.

[0064] In some embodiments of this application, the model executor 23 mainly performs corresponding model calculations on the parameterized model library managed by the model library management unit 22 according to the scheduling instructions given by the simulation task scheduler 21. Specifically, after the simulation task scheduler 21 allocates CPU / FPGA resources according to task priority (such as safety-critical tasks > real-time periodic tasks > event tasks > background tasks), the model executor 23 can respond to the scheduling instructions and perform corresponding model calculations, such as generating data from sensor models and executing control algorithms from ECU models, thereby executing the closed-loop control loop composed of the forward data flow, ECU processing, and feedback data flow to realize the dynamic characteristics of the real simulation system.

[0065] In the process of performing model calculations, the model executor 23 involves timing coordination and data exchange. Timing coordination is manifested in that high real-time tasks are scheduled by FPGA hard real-time scheduling, while ordinary tasks are executed by CPU multi-threading, ensuring strict matching between model execution and scheduling timing; data exchange is manifested in that efficient data transfer between the scheduler and the executor is achieved through mechanisms such as DMA and circular buffers.

[0066] In practical applications, during the task registration phase, sensor model instances can be registered as high-priority periodic tasks (e.g., 10ms cycle), ECU control models as high-priority periodic tasks (e.g., 5ms cycle), diagnostic processing as medium-priority event tasks, and log recording as low-priority background tasks. During the scheduling and execution phase, the focus is on the simulation step size. First, the highest-priority queue (e.g., safety-critical tasks) can be checked, and periodic tasks are triggered according to time, such as calling the model executor to run sensor model calculations, calling the model executor to run ECU model calculations, and processing diagnostic requests in the event queue. Background tasks are executed during idle periods. During the model executor's response, after receiving the scheduler's execution instructions, the latest parameters can be read from the global parameter table, and model calculations (single-step / batch / parallel) can be performed. The output is written to the data exchange buffer, and the execution status is fed back to the simulation task scheduler. This application's embodiments do not impose limitations on this.

[0067] The dynamic parameter configuration unit 24 is mainly used to maintain the global parameter table and realize the real-time hot update of model parameters during the simulation through the publish-subscribe mechanism. This unit also manages the parameter association between the sensor model and the ECU model. For example, the same physical quantity affects both the sensor output and participates in the ECU control logic, thereby ensuring the consistency and traceability of the parameters of the entire system.

[0068] Optionally, the dynamic parameter configuration unit 24 can notify relevant model instances when parameters change via a publish-subscribe mechanism. For example, the changed parameters may include user-configured parameters, environmental parameters preset in the simulation scenario (such as temperature curves, power supply voltage fluctuations, etc.), operating condition parameter sets automatically loaded during scenario switching, model parameters automatically adjusted by the intelligent analysis and optimization unit, the optimal parameter set output by the closed-loop optimization algorithm, and related parameters. Among these, user-configured parameters may be model parameters modified through a GUI interface (such as sensor gain, offset, etc.), calibration parameters updated in batches through a script interface, and environmental variable parameters; the environmental parameters preset in the simulation scenario may be real-time environmental data collected by sensors in the actual environment and operating condition switching parameters; the operating condition parameter set automatically loaded during scenario switching may be parameter group switching triggered by state machine transitions and optimization feedback parameters; and related parameters may be related parameters that are automatically updated when a certain physical quantity changes, such as temperature changes simultaneously affecting sensor output and ECU control parameters. This application embodiment does not impose any limitations on this.

[0069] In some embodiments of this application, the intelligent analysis and optimization unit 25 can be mainly used to realize an autonomous closed loop of "test-analysis-optimization" through full lifecycle data management, intelligent deviation analysis, automatic closed-loop optimization and knowledge feedback, thereby constructing a simulation system with "perception-analysis-decision-execution-feedback" capabilities.

[0070] Specifically, full lifecycle data management can be manifested in assigning a unique session ID to each simulation or hardware-in-the-loop (HIL) test, and uniformly associating and storing all bus frames, model internal variables, environment variables, parameter versions, and diagnostic events; data can be indexed using "timestamp + signal ID + session ID" to establish a multi-dimensional index structure, supporting playback, comparison, and multi-session overlay analysis.

[0071] Intelligent deviation analysis can be manifested in supporting the import of real vehicle test or bench data and using it as a target reference curve; after aligning the simulation results with the reference data by time, calculating the residuals and their statistical indices (such as mean, variance, spectral characteristics, etc.); using statistical / machine learning models to identify deviation types (such as sensor gain deviation, time delay deviation, inaccurate noise model, etc.) and locating the set of model parameters that may be affected.

[0072] Automatic closed-loop optimization can be represented by using the deviation analysis output as the objective function of the optimization problem, using algorithms such as genetic algorithms and particle swarm optimization to automatically search the parameter space and obtain a set of candidate parameters; the candidate parameter set is then quickly simulated and verified under typical working conditions, and the set of parameters with the best performance is selected and updated into the database.

[0073] Knowledge feedback and scenario expansion can be manifested in the following ways: optimized model parameters and scenario configurations are written back to the model library and scenario library in the form of new versions, while old versions are retained for retrospection; test scenarios are automatically generated or adjusted for typical working conditions with large deviations, forming new regression test cases, so that the simulation system has the ability to evolve itself.

[0074] In some embodiments of this application, the AI ​​test case generator 26 is the core of intelligent testing, and it can work in conjunction with the intelligent analysis and optimization unit 25 to form a self-evolving closed loop. It mainly models and generates test scenarios based on a multi-dimensional scene space, and triggers the simulation task scheduler to execute tests.

[0075] Specifically, modeling a multi-dimensional scene space can be represented by abstracting the test scene into a multi-dimensional space that includes environmental parameters (such as temperature, humidity, voltage, etc.), operating condition parameters (such as vehicle speed, load, RPM, etc.), protocol parameters (such as baud rate, frame rate, error rate, etc.), and fault parameters (such as fault type, severity, duration, etc.). It should be noted that the scene space can serve as a boundary constraint for sampling, a metric space for coverage calculation, an input / output space definition for AI models, or a means of visualizing test coverage, etc. This application's embodiments do not impose any limitations on this.

[0076] For test scenario generation, AI-driven algorithms such as Generative Adversarial Networks (GANs) or reinforcement learning can be used to automatically generate high-value test scenarios. Optionally, training can be performed based on a historical test database, and the aforementioned algorithms can be used to receive guidance information from the intelligent analysis and optimization unit to automatically generate a sequence of high-value test scenarios that maximizes coverage gain or fault detection rate. It should be noted that in the initial stage of system deployment or when there is no historical data, rule-based test case generation can be used as an auxiliary and supplementary method, and this application embodiment does not limit this approach.

[0077] For example, when training on a historical test database, an AI-driven test case generator can use methods such as Latin hypercube sampling to generate an initial set of test points. GANs generate test scenarios by having a generator produce new scenarios and a discriminator evaluate their value (e.g., coverage, fault detection capability). Reinforcement learning generates test scenarios by having an agent learn to generate high-value scenario sequences through interaction with the environment. Specifically, a generative adversarial network can be trained, where the generator learns to generate test scenarios that are difficult to pass, and the discriminator learns to distinguish between high-value and low-value scenarios. Test case generation can be modeled as a Markov decision process, where the agent learns to generate test sequences that maximize coverage gain or fault detection rate through interaction with a simulation environment. Existing high-value test cases can be mutated and crossovered using a genetic algorithm to generate similar but exploratory new test cases. In the initial stages of the system, rule generation is used as an auxiliary method.

[0078] The generation of guidance information can be based on comparing simulation data and measured data to identify the type of deviation (such as gain deviation, timing deviation, etc.); it can also be generated by using correlation analysis and sensitivity analysis to locate potentially affected model parameters; it can be generated by converting deviations into optimization objective functions (such as minimizing the sum of squared residuals); and it can also be generated by suggesting new test scenarios (such as extreme temperatures, high load conditions, etc.) based on the deviation distribution. This application does not impose any limitations on these aspects.

[0079] For sequence optimization, this involves sorting and pruning the scene sequences based on objectives such as coverage and time cost; spatial mapping represents a point in the scene space corresponding to each generated scene, and the system explores uncovered areas through methods such as spatial interpolation and clustering. This application's embodiments do not impose limitations on this.

[0080] For example, in addition to traditional code coverage, scene coverage determined by scene space sampling density, boundary coverage determined by extreme condition access rate, and fault coverage determined by fault mode activation rate can be introduced; for control algorithms based on neural networks, indicators such as neuron activation coverage and decision boundary coverage can be used; the tested and untested areas in the scene space can be visualized to guide the direction of subsequent test case generation and realize intelligent coverage measurement.

[0081] Furthermore, test set optimization and simplification can be achieved. Specifically, a greedy algorithm or integer programming is used to select the smallest subset from a large set of candidate test cases, minimizing test time while meeting coverage targets; when the model or code is updated, only incremental test cases for the changed parts are generated. This application's embodiments do not impose limitations on this.

[0082] After generating test scenarios, test scheduling can be triggered. Specifically, the generated test scenarios can be converted into scenario configuration instructions executable by the simulation engine and sent as high-priority events to the simulation task scheduler, triggering the system to automatically execute new tests, thereby exploring test blind spots or boundary conditions identified by the intelligent analysis and optimization unit.

[0083] In this embodiment, the simulation engine 2 is the core for achieving high-precision simulation. It can be modularly designed internally and ensures the coordinated operation of the sensor model and the ECU model in terms of time and data through precise scheduling and data management.

[0084] Reference Figure 3 This illustration shows a schematic diagram of the multi-protocol converged communication architecture for simulation system integration provided in an embodiment of this application. Figure 3 As shown, the multi-protocol converged communication architecture 3 may include a protocol interface layer 31, a protocol conversion and data synchronization engine 32, a data routing module 33, and a unified data format unit 34.

[0085] In some embodiments of this application, the protocol interface layer 31 can correspond one-to-one with the multi-protocol communication interface 141 of the hardware interface layer 14, specifically providing a SENT single-wire PWM interface, a PSI5 dual-wire Manchester encoding interface, a DSI3 differential bus interface, a CAN / CANFD interface and an in-vehicle Ethernet interface, thereby providing standardized physical connection channels for different types of sensors and ECUs.

[0086] In some embodiments of this application, the protocol conversion and data synchronization engine 32 deployed within the FPGA 132 is the core of the system for implementing heterogeneous network simulation. It is primarily used for cross-protocol data adaptation and conversion through a three-level hardware pipeline of "decoding – semantic mapping – encoding," and utilizes the FPGA's global high-precision clock to inject a unified timestamp into all data. It also uses a multi-level FIFO (First-In-First-Out) buffer and hardware comparator logic to perform time alignment of data streams with different protocols and sampling rates.

[0087] Optionally, the protocol conversion and data synchronization engine 32 can be implemented through a protocol decoding module 321, a clock injection unit 322, a semantic mapping engine 323, and a protocol encoding module 324.

[0088] In some embodiments of this application, the protocol decoding module 321 and the encoding module 324 are mainly responsible for the bidirectional conversion between protocol data and the unified intermediate format within the system. Specifically, during the decoding process, they perform frame synchronization, data extraction, and error detection; during the encoding process, they perform data encapsulation, verification generation, and frame formatting.

[0089] Specifically, the protocol conversion and data synchronization engine 32 can offload protocol conversion and synchronization from CPU software tasks to FPGA hardware pipeline services.

[0090] Optionally, for this FPGA hardware pipeline service of protocol adaptation and conversion, the system internally operates within the FPGA, using a predefined protocol adaptation rule base and routing table to achieve cross-protocol data and semantic adaptation and conversion. Specifically, the process involves first decoding data frames from different protocols into a unified intermediate format, and then re-encoding them according to the requirements of the target protocol.

[0091] This conversion process can identify and handle inherent differences between protocols, such as the 12-bit precision of the SENT protocol and the 8-byte length difference of the CAN protocol, and achieve accurate data mapping through techniques such as precision trimming, data splicing, or interpolation compensation. Furthermore, to ensure data reliability, the conversion process can introduce a Quality of Service (QoS) identifier to indicate the data's reliability level, such as lossless, lossy compensated, or non-convertible. It should be noted that for critical signals involving functional safety, the simulation system can support a configuration conversion whitelist mechanism to strictly prohibit any unverified protocol conversions; however, this embodiment does not impose such restrictions.

[0092] For example, regarding data mapping, taking specific semantic mapping as an example, when an engine speed signal (with 12-bit precision, unit RPM) transmitted via the SENT protocol needs to be converted, the simulation system will convert it into a standard floating-point value and encapsulate it into a specified CAN ID signal according to the definition of the CAN database. During this process, the simulation system will perform necessary dimensional and offset conversions and explicitly mark the original precision information in the data fields, thereby ensuring the accuracy and consistency of the signal semantics before and after conversion. It should be noted that the embodiments in this application address the adaptation problem of different protocol data representation methods.

[0093] In the example of SENT to CAN data conversion, the SENT protocol data has the characteristics of carrying 12 bits of data (0-4095) in a single SENT frame, and the physical value = original value × resolution + offset. For example, for a speed signal, its resolution is 2 rpm, the offset is 0, and the range is 0-8190 rpm. The CAN protocol data has the characteristics of a maximum of 8 bytes (64 bits) of data per frame, the signal can be defined as any bit width (1-64 bits), and the start bit / length / factor / offset of the signal can be defined through a DBC file.

[0094] During the conversion process, SENT decoding can be performed first. For example, the original value = 2048 (12 bits) and the physical value = 2048 × 2 + 0 = 4096 rpm. Then, semantic mapping can be performed by querying the mapping rule table. For example, the source signal SENT_EngineSpeed ​​is mapped to the target signal CAN_EngineSpeed. Assuming the target CANID is 0x123, the start bit is 0, the length is 16 bits, the target factor is 0.5 rpm, and the target offset is 0, the numerical conversion can be performed to obtain: the target original value = (physical value - offset) / factor = (4096 - 0) / 0.5 = 8192. The 16 bits can represent the range of 0-65535, and 8192 is within the range. Then, CAN frame encapsulation can be performed, represented as CANID: 0x123, Data[0-1]: 8192 (0x2000) - little endian, Data[2-7]: other signals or padding, QoS identifier: Level 0 (lossless).

[0095] For example, the precision processing strategy can be expressed as follows: if the target precision is higher (e.g., a 16-bit target), it indicates a direct mapping situation, and QoS = Level 0; if the target precision is lower (e.g., an 8-bit target), it indicates a rounding situation, and QoS = Level 1. Precision information can be retained in metadata for upper-layer reference, and this application embodiment does not impose any limitations on this.

[0096] Optionally, regarding the labeling strategy for data credibility levels, as one example, if no information is lost during data conversion, the labeled data credibility level is lossless; as another example, if the data has undergone compression, interpolation, or precision pruning, but semantic consistency is maintained through a compensation algorithm, the labeled data credibility level is lossy compensation; as yet another example, if there is semantic mismatch between protocols or security rules prohibit conversion, the labeled data credibility level is non-convertible. It should be noted that the labeling criteria can be based on signal importance, protocol compatibility, security level, etc., and this application embodiment does not impose any limitations on this.

[0097] Optionally, for data synchronization, the FPGA hardware pipeline service utilizes the FPGA's global high-precision clock to assign a unified timestamp to all input data during data decoding. Through multi-level FIFO buffers and hardware comparator logic, data streams with different sampling rates and protocols are aligned on the timeline, thereby ensuring system-level time consistency for cross-protocol data and effectively avoiding timing jitter caused by operating system scheduling in pure software solutions.

[0098] For example, the alignment logic can be manifested as follows: after all data is given a unified timestamp and stored in a multi-level FIFO buffer to achieve timestamp sorting, the management of the buffer is manifested as an independent FIFO for each protocol channel, and a hardware comparator comparing the timestamps at the header of each FIFO and selecting the earliest timestamp data for output; then, for data with different sampling rates, linear interpolation can be performed on the output time grid or the last value can be kept, and synchronization can be triggered based on external events (such as the Pulse Per Second, or PPS) or an internal timer, i.e., periodic alignment can be performed.

[0099] In some embodiments of this application, the data routing module 33 is mainly used to distribute the converted uniform format data to the target protocol communication interface, the integrated simulation engine, or the storage module of the hardware interface layer based on a static or dynamic routing table, and supports unicast, multicast, and broadcast modes, allowing the same data source to serve multiple simulation or monitoring tasks simultaneously. The routing decision can be based on the data frame ID, the source virtual channel ID, or the data content itself; this application does not impose any limitations on this.

[0100] In some embodiments of this application, the unified data format unit 34 can primarily be used to define internal data structures. These internal data structures may include at least timestamp, data source (virtual channel ID), data type, data content, and quality identifier fields. The unified data format can shield against differences in underlying protocols, enabling the upper-layer simulation engine and diagnostic module to process data from different physical buses in a consistent manner. This provides a consistent data access method for the upper-layer architecture and lays the foundation for cross-protocol data fusion and unified analysis.

[0101] In some embodiments of this application, the multi-protocol converged communication architecture 3 can also integrate external networks. Specifically, the simulation system can connect to real sensors / ECUs and simulated sensors / ECUs simultaneously through the protocol interface layer 31. It can support both pure simulation mode and hardware-in-the-loop test mode, and can seamlessly interface with external diagnostic and flashing tools to form a flexible and configurable test environment.

[0102] In this embodiment, the multi-protocol converged communication architecture 3 can ensure seamless interconnection and time synchronization of different vehicle protocols on the same platform, providing basic support for heterogeneous network simulation.

[0103] Reference Figure 4 This illustration shows a schematic diagram of the distributed and intelligent scaling architecture of the simulation system integration provided in this embodiment. The distributed and intelligent scaling architecture design possesses good horizontal and vertical scalability, such as... Figure 4As shown, the distributed and intelligent expansion architecture 4 mainly introduces a three-layer collaborative architecture consisting of a cloud simulation cluster 41, edge nodes 42, and terminal verification clients 43. Optionally, it can also be supplemented with an efficient state synchronization and collaborative development mechanism to achieve scalable simulation and collaborative development from single ECU simulation to vehicle-level system verification.

[0104] In some embodiments of this application, the cloud simulation cluster 41 serves as the computing power and data hub of the simulation system. It focuses on handling computationally intensive and non-real-time tasks, and can be used to implement core functions such as task decomposition and scheduling, large-scale parallel execution, AI model training and centralized management.

[0105] Task decomposition and scheduling can be manifested in the process of breaking down complex vehicle-level or multi-ECU collaborative simulation tasks into multiple parallel sub-tasks based on model coupling relationships and data flow dependencies, such as single ECU functional simulation, sensor simulation, and specific network segment simulation, and constructing a directed acyclic graph (DAG) of task dependencies. Additionally, tasks can be dynamically allocated based on real-time load, specifically by using heuristic algorithms or deep reinforcement learning models to dynamically allocate tasks and balance load based on the real-time load status of cloud computing nodes (such as CPU, memory, GPU, network bandwidth, etc.), aiming to minimize the overall simulation completion time.

[0106] Massive parallel execution can manifest as supporting the simultaneous initiation and management of hundreds to thousands of simulation instances, providing elastic computing power for scenarios such as Monte Carlo simulation (for reliability analysis), parameter scanning (for model calibration and sensitivity analysis), and batch execution of AI-driven test cases. Optionally, the cloud simulation cluster can automatically request or release computing resources from the cloud platform based on the priority of the task queue and the preset deadline, achieving an optimal balance between cost and simulation efficiency.

[0107] AI model training and centralized management can manifest as training and optimizing complex models such as digital twin degradation models and AI test case generators (e.g., GANs, reinforcement learning agents) in the cloud. Optionally, the trained lightweight models can be deployed to edge nodes for execution, forming an efficient collaborative model of cloud training and edge inference. At the same time, the cloud can serve as a central hub for a unified model library, scenario library, and test result library, providing version management and global sharing services.

[0108] In some embodiments of this application, edge node 42 is mainly an edge HIL node, which is the core architecture of the simulation system, specifically manifested as follows: Figure 1The diagram shows the user interaction layer, software function layer, core processing unit, and hardware interface layer. Specifically, the edge HIL node can be deployed in the test site or laboratory for physical deployment. It is a key unit for interacting with real ECU and sensor hardware, ensuring high real-time performance and determinism.

[0109] Among them, the real-time deterministic response of edge HIL nodes can be manifested as the nodes running real-time operating systems (such as RT-Linux, VxWorks, etc.) to ensure the timing determinism of simulation task scheduling, model execution and protocol communication, meet the microsecond-level hard real-time requirements, and provide a reliable foundation for hardware-in-the-loop testing.

[0110] The hardware and software co-processing of edge HIL nodes can be manifested as follows: the edge HIL node acts as a complete carrier of the simulation system's heterogeneous architecture of "multi-core CPU + FPGA," directly connecting to real ECUs, sensor buses, and networks, while maintaining bidirectional communication with the cloud. As the physical deployment carrier of the system's core architecture, the edge HIL node can download optimized and compiled simulation scenarios, model parameters, and protocol configurations from the cloud. While performing real-time HIL tests, it can upload the collected high-fidelity test data and status information to the cloud in real-time or near real-time.

[0111] Edge HIL nodes also support cloud-based training and edge inference. The edge intelligence of edge HIL nodes can be manifested in the nodes receiving and deploying lightweight AI models from the cloud, and having the ability to perform intelligent fault injection, real-time data deviation analysis, and adaptive test sequence adjustment locally. This can reduce the computing and communication pressure on the cloud while ensuring data security and response speed.

[0112] In some embodiments of this application, the terminal verification client 43 can provide developers and testers with a flexible and convenient human-computer interaction interface, mainly used to provide lightweight local verification capabilities, access cloud or edge nodes through Web technology or remote desktop protocols, and support collaborative work for mobile office and multi-user collaborative interaction.

[0113] The terminal verification client 43 can run on engineer terminal devices, such as laptops or mobile devices, and comes pre-installed with commonly used model libraries and basic test scenarios. It supports rapid model debugging and scenario verification in environments without network connectivity, giving the terminal verification client lightweight local verification capabilities. Through secure web technology or remote desktop protocols, the terminal verification client can seamlessly access and operate the simulation environment of cloud simulation clusters or edge HIL nodes. Users can configure simulation parameters, start / stop tests, monitor real-time data, and download analysis reports through a unified web interface, enabling testing and verification anytime, anywhere, and thus achieving remote access and control capabilities for the terminal verification client. Optionally, the terminal verification client 43 also features a collaborative interaction interface, which provides collaborative functions such as task submission, result visualization, and online review, serving as an important window for distributed teams to access the unified simulation service platform.

[0114] In some embodiments of this application, the distributed and intelligent extension architecture 4 adopts a state synchronization and coordination mechanism, which is the core technical support for ensuring data consistency and simulation credibility under the distributed architecture.

[0115] Among them, under the state synchronization and coordination mechanism, distributed clock synchronization can be manifested by using time synchronization protocols, such as the Precision Time Protocol (PTP), between the cloud, edge, and terminal layers to synchronize clocks and control the clock error between nodes to the microsecond level. For scenarios with lower real-time requirements, the Network Time Protocol (NTP) can be used to provide a unified global time reference for all simulation data and events.

[0116] It should be noted that, in order to align data streams with different sampling rates and protocols on the timeline, when the cloud needs to fuse data from multiple edge nodes, there is a need for data fusion. PTP synchronization can ensure that timestamps from different nodes can be directly compared and aligned. In distributed simulation, the causal order of events depends on a global time base. PTP can guarantee the correct timing of events across nodes, realizing causal relationships. When multi-node test data is aggregated and analyzed in the cloud, a unified time base allows cross-node data to be reconstructed in true chronological order, enabling playback analysis. In multi-node collaborative simulation, the simulation step size of each node needs to be synchronized, and PTP can provide a time base for synchronization triggering. This application's embodiments do not impose limitations on this.

[0117] Under the state synchronization and coordination mechanism, state snapshots and breakpoint resume simulation can be represented by the simulation system being able to periodically or automatically save complete state snapshots of all simulation instances at key simulation steps, including model variables, environmental parameters, communication status, etc., to support the rapid recovery of simulation from any historical point in time, greatly facilitating fault reproduction, debugging and analysis, and providing the possibility of breakpoint resume simulation for long-cycle testing.

[0118] Under the state synchronization and coordination mechanism, the fault tolerance and degradation mechanism can be manifested as the simulation system possessing comprehensive anomaly detection and self-recovery capabilities. Specifically, the intelligent offline mode of edge nodes ensures uninterrupted testing during network outages; the distributed state snapshot and consistency recovery mechanism automatically synchronizes the state of each node after network recovery; and based on proactive health monitoring and elastic task migration mechanisms, automatic task reallocation is achieved in the event of node failures, ensuring the high availability and service continuity of the simulation system.

[0119] Under the state synchronization and coordination mechanism, data consistency can be guaranteed by adopting a hybrid consistency model. Specifically, for core data such as simulation model states and global parameters, a strong consistency or sequential consistency model is used to ensure that all nodes see the same data at key decision points. For non-real-time critical data such as logs and historical records, an eventual consistency model is used, allowing for slight differences in data between nodes within a short period of time. Through predefined synchronization cycles and conflict resolution strategies, the system state is ensured to eventually converge and become consistent. When multiple users or nodes simultaneously modify the same shared resource (such as model parameters or scenario configurations), version control (such as Git principles) and a three-way merge strategy are used to automatically resolve conflicts, ensuring the correctness and traceability of data evolution.

[0120] Under the state synchronization and collaboration mechanism, collaborative development support can be manifested in supporting multiple engineers to access the same simulation project environment simultaneously. The system ensures the independence and security of each engineer's testing tasks through resource isolation and session management; it provides standardized interfaces for result storage, querying, and comparative analysis, facilitating the sharing, review, and in-depth analysis of test results among members across teams and regions; it implements role-based access control, strictly managing user permissions to system resources, model libraries, and test data; and it comprehensively records all users' key operation logs.

[0121] In this embodiment, the distributed and intelligent expansion architecture 4 can achieve seamless expansion from single ECU simulation to vehicle-level system verification, and from single-machine testing to geographically distributed team collaboration, upgrading simulation capabilities from a single-point tool to distributed as a service.

[0122] In the embodiments of this application, such as Figure 1The full-stack integrated architecture 1 shown is a complete implementation of the system architecture on a single node. It describes a single-machine system, namely the user interaction layer 11, the software function layer 12, the core processing unit 13, and the hardware interface layer 14.

[0123] like Figure 1 The single-node capability of the full-stack integrated architecture shown is based on, for example... Figure 2 The core functional capabilities of the simulation engine architecture 2 shown.

[0124] Specifically, the core processing unit 13 is the computing power support and hard real-time scheduling layer of the simulation engine architecture 2. It is manifested as the multi-core CPU 131 of the core processing unit 13, which is the core computing power carrier of the simulation task scheduler 21, model executor 23, and intelligent analysis and optimization unit 25 in the simulation engine architecture 2. It is responsible for model calculation and hierarchical task scheduling. The FPGA 132 cooperates to provide hard real-time clock synchronization for the safety-critical tasks of the simulation engine. The software function layer 12 is the complete functional module carrier of the simulation engine architecture 2. It integrates all core modules of the simulation engine architecture, such as the model library management unit 22, dynamic parameter configuration unit 24, and AI test case generator 26. At the same time, it works with the diagnostic writing module and protocol stack module of the multi-protocol fusion communication architecture 3 to realize the functional linkage of simulation data generation, protocol encapsulation, and diagnostic writing. The hardware interface layer 14 is the simulation closed-loop physical interface of the simulation engine architecture 2. It is manifested as the multi-protocol communication interface of the hardware interface layer 14, which is the physical interface for outputting the simulation data generated by the simulation engine architecture 2 to the external real ECU / sensor. The "Tao" layer is also the physical entry point for inputting measured data from external hardware into the simulation engine for deviation analysis and model optimization. Based on this layer, the simulation engine can construct a single-node closed loop of simulation-hardware-feedback optimization. The user interaction layer 11 is the configuration, monitoring, and result display entry point for the simulation engine architecture 2. It is manifested as the model configuration module of the user interaction layer 11, which is linked with the model library management unit 22 and the dynamic parameter configuration unit 24 of the simulation engine. It supports users to visually configure simulation models, adjust simulation parameters, and define test scenarios. The result display module of the user interaction layer 11 receives the intelligent analysis and optimization results and AI test case generation results of the simulation engine, realizing real-time monitoring of the simulation process and visual display of simulation results.

[0125] like Figure 1 The single-node capability of the full-stack integrated architecture shown is based on, for example... Figure 3 The core functional capabilities of the multi-protocol converged communication architecture shown are implemented.

[0126] Specifically, the hardware interface layer 14 is the physical access foundation of the multi-protocol converged communication architecture 3. It manifests as the multi-protocol communication interfaces (SENT / PSI5 / CAN / vehicle Ethernet, etc.) and configurable signal conditioning modules of the hardware interface layer, physically bound to the protocol interface layers of the communication architecture. This provides a physical access channel conforming to the electrical characteristics of each protocol, serving as the physical entry point for heterogeneous protocol data into a single node. The core processing unit 13 is the hardware-based core execution layer of the multi-protocol converged communication architecture 3, manifested as the FPGA of the core processing unit. It carries the protocol encoding / decoding module, protocol conversion and data synchronization engine, and hardware-level data routing of the communication architecture, achieving low-latency (microsecond-level) hardware-based protocol processing, time synchronization, and cross-protocol conversion. The CPU, in conjunction with the software-level data routing and external network integration module carrying the communication architecture, interacts with the CPU via PCIe / DMA, forming the core of the communication architecture. The core of computing power; the software function layer 12 is the software protocol stack and unified API layer of the multi-protocol converged communication architecture 3. It is manifested as the protocol stack module of the software function layer and is the software implementation carrier of the communication architecture. It provides complete high-level protocol logic for each protocol and software parsing interface for unified data format. At the same time, it provides standardized protocol access APIs for other functional modules (such as simulation engine module and diagnostic writing module), shielding the differences of underlying protocols, so that simulation and diagnostic modules do not need to pay attention to protocol details and can directly call data; the user interaction layer 11 is the human-computer interaction and monitoring entry point of the multi-protocol converged communication architecture 3. It is manifested as the bus monitoring module of the user interaction layer and directly interfaces with the data routing module of the communication architecture. It is the visualization window of the communication architecture. That is, users can use this module to monitor the multi-protocol bus data processed by the communication architecture in real time, view the protocol conversion status, locate communication faults, and realize the configuration and status monitoring of the communication architecture.

[0127] like Figure 4 The distributed and intelligent scaling architecture shown has distributed capabilities based on, for example, Figure 1 The single-node capability of the full-stack integrated architecture shown is implemented.

[0128] Specifically, the three-layer collaborative architecture of the distributed and intelligent expansion architecture 4 can be used to achieve distributed expansion of single-node capabilities. This is manifested in replicating the overall architecture 1, which combines the core capabilities of multiple integrated simulation engine architectures 2 and multi-protocol converged communication architectures 3, to multiple nodes (i.e., edge HIL nodes) 42, and combining it with the cloud simulation cluster 41 and the terminal verification client 43 to form a "cloud-edge-device" three-layer collaboration. Essentially, this represents the large-scale replication of single-node capabilities, elastic expansion of computing power, and cross-regional collaboration.

[0129] Reference Figure 5 The diagram shows a structural block diagram of a sensor and ECU simulation system based on multi-protocol fusion provided in an embodiment of this application.

[0130] like Figure 5 As shown, the simulation system 5 provided in this application embodiment may include core modules such as a hardware resource pool 51, a protocol fusion processing module 52, an integrated simulation engine 53, an integrated diagnostic writing module 54, a security fault injection module 55, and a distributed collaborative unit 56. The aforementioned core modules are the physical functional carriers and implementation units of the above-mentioned full-stack integrated architecture 1, simulation engine architecture 2, multi-protocol fusion communication architecture 3, and distributed and intelligent extension architecture 4.

[0131] It should be noted that the above architecture is used to indicate the logical design framework, layering rules, and collaboration basis of the core modules. All core modules can be designed in the following way. Figure 1 The overall system architecture shown (i.e., a single-node four-layer framework) is a unified physical / software container. The hardware resource pool 51, protocol fusion processing module 52, integrated simulation engine 53, integrated diagnostic writing module 54, and security fault injection module 55 are the core functional modules of the single node, capable of supporting the functional implementation of the simulation engine architecture 2 and the multi-protocol fusion communication architecture 3. The distributed collaboration unit 56 is the implementation module of the distributed and intelligent expansion architecture 4, mainly relying on the single-node capabilities of the aforementioned five core modules to complete distributed expansion. This application does not impose any limitations on this embodiment.

[0132] In some embodiments of this application, the hardware resource pool 51 is deployed on the hardware interface layer 14 and the core processing unit 13, and can be mainly used to provide multi-protocol access, signal conditioning and heterogeneous computing capabilities.

[0133] Specifically, the hardware resource pool 51 may include a multi-protocol communication interface, a configurable signal conditioning module, and a heterogeneous processing core.

[0134] A multi-protocol communication interface, deployed at the hardware interface layer, supports multiple communication protocols, such as SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet protocols, and can be connected to the aforementioned communication protocol buses. Optionally, each communication protocol corresponds to an independent interface module, and each interface module can integrate the physical layer transceiver chip, electrical isolation, and protection circuitry corresponding to the respective communication protocol, providing a physical connection foundation for the multi-protocol converged communication architecture.

[0135] The configurable signal conditioning module is located between the multi-protocol communication interface and the analog-to-digital / digital-to-analog converter in the hardware interface layer. It may include a programmable gain amplifier (PGA) and a configurable filter. The gain and cutoff frequency of the programmable gain amplifier and the configurable filter can be dynamically configured by the system software according to the protocol type and signal characteristics to ensure the conditioning accuracy of the multi-protocol signal.

[0136] For example, the configuration strategy of a configurable signal conditioning module may include a three-stage mechanism of protocol identification, feature matching, and adaptive adjustment.

[0137] Optionally, the protocol identification stage can be characterized by the simulation system being able to identify the type of access protocol, such as SENT / PSI5 / DSI3 / CAN / Ethernet, based on user configuration or automatic detection.

[0138] The characteristic matching stage involves automatically loading preset parameter templates according to the protocol type. For example, for the SENT protocol, the gain can be set to be adjustable from 1 to 10 times, the bandwidth can be set to 1 to 100kHz, and the input impedance can be matched to the high impedance mode. For the PSI5 protocol, the gain can be set to the differential amplification mode, and the bandwidth can be set to the filtering characteristics corresponding to 189kbps. For the CAN / CANFD protocol, the gain can be fixed, the bandwidth can be adjusted according to the baud rate (125kbps-8Mbps), and the anti-aliasing filter cutoff frequency can be automatically adjusted. For the automotive Ethernet protocol, the impedance can be matched to 100Ω differential, and the bandwidth can be matched to 100BASE-T1 or 1000BASE-T1. This application embodiment does not impose any limitations on these aspects.

[0139] The adaptive adjustment phase involves dynamically fine-tuning the gain and filtering parameters based on signal quality metrics (such as signal-to-noise ratio and bit error rate) during runtime. It should be noted that the specific dynamic fine-tuning strategy is not limited in the embodiments of this application.

[0140] The heterogeneous processing core, as the core of the core processing unit, can include a multi-core CPU and an FPGA interconnected via a high-speed PCIe bus, to execute high-level protocol logic and physical / link layer processing, respectively. The multi-core CPU can serve as the control plane, running the operating system, high-level protocol logic, and an integrated simulation engine, while the FPGA can serve as the data plane, executing physical / link layer processing, protocol conversion, and time synchronization tasks, providing computing power support for the collaboration of the four architectures.

[0141] In some embodiments of this application, a hardware resource virtualization architecture concept can be established. By using modular physical interfaces and heterogeneous cores of CPU+FPGA, the physical layer resources of heterogeneous protocols such as SENT, PSI5, and DSI3 are abstracted into a unified, dynamically schedulable virtual resource pool. This solves the industry problem of unified access, parallel processing, and deterministic synchronization of multiple protocols from a physical foundation, surpassing traditional solutions such as multi-device stacking or software protocol conversion.

[0142] In practical implementation, the modularization of physical interfaces can be manifested in designing independent interface modules (such as boards or sub-modules) for different protocols such as SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet, taking into account their electrical characteristics. Each module integrates physical layer transceiver chips for the corresponding protocol (such as automotive Ethernet PHY, CAN / CANFD transceivers, PSI5 / DSI3 interface chips) and isolation / protection circuits, and is equipped with a programmable gain amplifier (PGA) and configurable filters at the front end to achieve level conversion, anti-aliasing filtering, electrical isolation, and EMC optimization. The modules are connected to the main control board through a unified backplane or connecting bus, enabling the simulation system to add or remove interface types and the number of channels as needed.

[0143] For a CPU+FPGA heterogeneous computing core, the FPGA side can function as follows: It implements independent hardware encoding / decoding state machines and processing pipelines for each protocol, performing high real-time tasks such as bit-level synchronization, frame boundary detection, and CRC / checksum checks. It converts the decoded raw frame data into a unified intermediate frame format and writes a timestamp count value driven by a global high-precision clock (e.g., a 64-bit counter with configurable resolution of 100ns or 1μs) at the decoding moment, achieving a unified microsecond-level timescale. It maintains a virtual channel table, assigning a virtual channel ID to each physical interface. Upper-layer software accesses lower-level resources only through virtual channels, employing a unified structure that includes at least timestamp, data source (virtual channel ID), data type, data content, and quality identifier fields. The CPU side can function as follows: It runs the operating system and a complete protocol stack, performing complex logic such as high-level protocol state machines, error recovery strategies, and diagnostic session control. It runs the simulation engine and diagnostic writing module, mapping intermediate frame data from the FPGA to model input or encapsulating it into diagnostic messages.

[0144] For an efficient collaborative mechanism, the FPGA and CPU can be interconnected via a high-speed PCIe bus and use DMA for large data transfer, minimizing CPU involvement in frame-by-frame data transfer. A circular buffer or descriptor queue is used to organize DMA transfers, and the FPGA only reports batch data availability events to the CPU via interrupts or polling, reducing interrupt frequency and improving throughput. The CPU only exposes an abstract interface of "virtual bus / virtual channel" to the upper layer. Changes in the underlying physical interface (replacing boards, expanding channels) only require updating the mapping table, without affecting the upper-layer simulation scenario and test scripts.

[0145] In some embodiments of this application, the protocol fusion processing module 52 is deployed in the FPGA of the core processing unit based on a multi-protocol fusion communication architecture. It can be mainly used for hardware-level encoding and decoding, time synchronization and cross-protocol conversion of multi-protocol data.

[0146] Optionally, the protocol fusion processing module 52 can perform the protocol fusion and synchronization steps in S601 below.

[0147] Specifically, a hardware-pipeline-based protocol adaptation and time synchronization mechanism can be implemented. This means that protocol conversion and data synchronization are moved from CPU software thread scheduling tasks to hardware pipeline services with fixed internal structures within the FPGA. Through a three-stage pipeline of decoding, semantic mapping, and encoding, and a global hardware timestamp mechanism, low-latency, jitter-free protocol adaptation and conversion are achieved. It also provides a unified spatiotemporal reference across protocol domains, which is fundamental to ensuring the causal relationships and timing consistency of heterogeneous network data, solving the problem of uncontrollable timing in traditional software solutions.

[0148] In practical implementation, for an FPGA hardware pipeline structure, the decoding stage can be represented by designing a separate decoding state machine for each protocol to recover the frame structure and payload from the physical layer bitstream. The decoding state machine is used to convert the physical layer bitstream before decoding into structured frame data after decoding. Optionally, it can process the original bitstream, complete bit synchronization, frame delimitation, and CRC check, and output structured data (such as ID, data field, timestamp) after decoding for use by subsequent modules. The mapping stage can be represented by encapsulating the decoded data into a unified intermediate format, looking up the target channel / target protocol based on the routing table, and generating the signal values ​​required by the target protocol according to semantic mapping rules (such as ID mapping, unit conversion, offset / scaling, etc.), and attaching a conversion quality identifier. The encoding stage can be represented by re-encoding the intermediate data into data frames of the target protocol according to the target protocol frame format and sending them to the specified physical interface for transmission.

[0149] For unified timestamps and data synchronization, this can be achieved by maintaining a high-precision global counter internally within the FPGA (e.g., an external high-stability crystal oscillator). All successfully decoded data frames are written to this counter value as a timestamp at the decoding time. The data synchronization engine uses a FIFO to buffer multiple protocol data streams, sorting and aligning them with the timestamp as the key, ensuring that when output to the simulation engine or monitoring module, each protocol data is presented according to the real time sequence. For buses with different sampling rates (such as high-speed CANFD and low-speed SENT), data is resampled to a common time grid through interpolation or decimation algorithms, facilitating unified time-domain analysis by the upper layer.

[0150] In some embodiments of this application, the integrated simulation engine 53 can be deployed on the multi-core CPU of the core processing unit based on the simulation engine architecture. It can be mainly used to manage the parameterized model library, schedule model simulation tasks through the simulation task scheduler, generate high-fidelity simulation data, and encapsulate the simulation data into intermediate frames or diagnostic frames and output them to the protocol fusion processing module, supporting dynamic hot updates of model parameters during the simulation process.

[0151] Optionally, the integrated simulation engine 53 can perform the dynamic simulation and intelligent optimization steps of S602 below.

[0152] Specifically, a parameterized dynamic modeling method based on environmental perception can be introduced to overcome the limitations of traditional modeling in failing to consider the time-varying nature of environmental parameters. Environmental factors such as temperature drift, humidity changes, and power supply fluctuations can be treated as independent compensation dimensions and coupled with the nonlinearity and dynamic response characteristics of sensors and ECU control logic for modeling. Combined with a dynamic parameter hot update mechanism, the simulation model can have online adaptive capabilities, achieving an upgrade from static fitting to dynamic evolution with the environment, thereby significantly improving the simulation confidence under multiple operating conditions and environments.

[0153] In practical implementation, within the layered sensor model, the physical layer primarily calculates basic outputs (such as voltage values) based on input physical quantities, specifically describing the fundamental nonlinear relationship between the input physical quantities and the sensor output (such as piezoresistive effects and capacitance changes). It uses polynomial fitting, look-up tables (LUTs), or lightweight neural network structures to fit calibration data. The dynamic layer primarily applies dynamic responses to the basic outputs (such as low-pass filtering to simulate inertia), specifically using transfer functions or state-space models to describe the sensor's dynamic response (such as rise time, bandwidth, and phase delay), with parameters obtained through experimental data identification. The environmental layer primarily corrects the parameters of the first two layers based on real-time environmental parameters (such as temperature and humidity). Specifically, it establishes mapping models from environmental variables such as temperature drift, humidity, and power supply voltage to physical / dynamic layer parameters, such as through first- or second-order temperature compensation and multi-dimensional interpolation tables, to achieve automatic correction of characteristic curves and dynamic parameters under different environments. Optionally, the final sensor signal generated after the three layers are superimposed can be injected into the protocol stack to achieve output synthesis.

[0154] Taking a layered sensor model as an example of a pressure sensor, assuming the application scenario is a simulated engine intake manifold pressure (Manifold Absolute Pressure Sensor, or MAP) sensor, in this example, we assume the input is the actual intake manifold pressure P. actual =85kPa, environmental parameters are temperature T=80℃, supply voltage V=4.8V. The first physical layer calculation can describe the basic conversion relationship from pressure to voltage. Specifically, the model can be used: V out =f(P)=a0+a1•P+a2•P 2 +a3•P 3 The calculation is performed using a third-order polynomial fitting, with coefficients derived from sensor calibration data. Assuming system values ​​of a0 = 0.2V, a1 = 0.045V / kPa, a2 = 0.00001, and a3 ≈ 0, the actual intake manifold pressure P can be substituted into the values. actualFor output parameter V out Calculations are performed to obtain the output physical voltage value V. physical =0.2 + 0.045 × 85 + 0.00001 × 85 2 =0.2+3.825+0.072=4.097V; The second-layer dynamic layer calculation can simulate the dynamic response characteristics of the sensor. Specifically, the model can be: G(s)=1 / (τs+1) the first-order transfer function, where G(s) is the transfer function, s is the frequency domain complex operator, and the time constant τ=5ms (used to represent the response time), according to the acquisition period T s Discretizing by 1ms yields: V dynamic [k]=α•V physical [k]+(1-α)•V dynamic [k-1], where α=T s / (τ+T s V = 1 / (5+1) = 0.167 dynamic [k] represents the final discrete output value of the sensor's dynamic layer at time k (i.e., the current sampling time), assuming the dynamic layer output value V at time k-1 (i.e., the previous sampling time) is... dynamic [k-1]=4.05V, then V dynamic [k] = 0.167 × 4.097 + 0.833 × 4.05 = 0.684 + 3.374 = 4.058V; The third-layer environmental calculation can compensate for the influence of environmental factors such as temperature and voltage. Specifically, a temperature drift model can be used: ΔV temp =k t ×(TT ref ), where ΔV temp This refers to the voltage compensation amount caused by temperature deviation, i.e., the voltage value that the sensor output needs to be corrected due to temperature deviation from the reference value. T is the actual temperature of the sensor's current operating environment, and we assume the sensor's temperature drift coefficient k. t = -0.002V / ℃, the reference temperature T calibrated by the sensor ref =25℃, then ΔV temp =-0.002×(80-25)=-0.11V, after environmental compensation, V env =V dynamic +ΔV temp +ΔV supply Assume V dynamic =4.058V, ΔV supply =-0.004V, V env =4.058 + (-0.11) + (-0.004) = 3.944V, where V env The final output voltage after environmental layer compensation is the final result of sensor simulation, V. dynamicThe output voltage after dynamic layer discretization and iteration is an ideal dynamic output without environmental bias, V supply This refers to the voltage compensation amount caused by the supply voltage deviation, i.e., the voltage value that the sensor output needs to be corrected due to the supply voltage deviating from the reference value; and characteristic superposition can be performed. For example, Gaussian noise superposition is represented by using Gaussian noise: N(0,σ²), where the standard deviation of Gaussian noise σ=0.005V. Then, the noise value collected for superposition, i.e., the actual Gaussian noise value n of a single acquisition, can be a sample value randomly drawn from the distribution N(0,0.005²), such as 0.003V. Quantization superposition is represented by resolution = ADC (Analog-to-Digital Converter) full-scale voltage / quantization level. Assuming the ADC full-scale output voltage is 5V and the ADC quantization level is 4096, the calculated resolution is 5V / 4096=1.22mV, i.e., the actual quantization resolution is 1.22mV, which is the quantization parameter directly used in engineering. Then, the final analog voltage output is V. final =round(V noise / resolution)×resolution=round((3.944+0.003) / 0.00122)×0.00122=3.947V, where, according to the 12-bit ADC, the quantized value obtained by quantization in the range of 0~5 is: round((3.944+0.003) / 0.00122)=3236, that is, the final digital output (SENT protocol) is Raw value =3236 (12 bits). This application does not limit this.

[0155] In some embodiments of this application, the ECU behavior model can describe the switching conditions of the ECU between different working modes such as normal, fault, and diagnosis through a finite state machine; the control algorithm module implements control laws such as PID and fuzzy control, and can call different parameter sets or control law versions according to the working conditions; the model explicitly introduces timing parameters such as sampling period, calculation delay, and execution delay to approximate the timing behavior of the real ECU during operation.

[0156] For example, the finite state machine of the ECU behavior model includes a normal mode, a fault mode (when the input exceeds the limit), and a diagnostic mode (when a diagnostic request is received); the ECU behavior model can calculate the delay through PID control, assuming that the sampling period T is during the execution of the timing behavior. s =10ms (100Hz task), calculate latency T c =2ms (i.e., algorithm execution time), output delay T o =1ms (i.e., PWM (Pulse Width Modulation) update delay), then the total delay =T s / 2+T c +T o ≈8ms.

[0157] The dynamic parameter adjustment mechanism can be represented by storing key parameters of all sensors and ECU models in a globally shared parameter table, which can be read and written through GUI or script interface; the parameter update adopts the "atomic update + version number" mechanism, and the simulation engine only loads the latest version of the parameter set at a specific synchronization point (such as the end of each simulation step), avoiding the state of partial update; it supports online adjustment of environmental variables (such as temperature curves, power supply fluctuations, etc.) during simulation, and the environmental layer model automatically updates the physical layer / dynamic layer parameters, and the output characteristics change in real time.

[0158] Specifically, an intelligent simulation system can achieve a self-governing closed loop of testing, analysis, and optimization. By constructing an intelligent simulation system with "perception-analysis-decision-execution-feedback" capabilities, the system can not only generate simulation data and compare it with measured data, but also automatically identify model deficiencies and insufficient operating condition coverage based on differences. It can then achieve self-correction through parameter optimization and scenario adjustment, transforming the simulation platform from a static verification tool into a dynamic and adaptive development assistant. In the specific implementation, the full lifecycle data management, intelligent deviation analysis, automatic closed-loop optimization, and knowledge feedback process implemented by the intelligent analysis and optimization unit 25 can be referenced; however, the specific details in this application's embodiment will not be elaborated upon here.

[0159] Furthermore, it can also generate adaptive test cases and optimize coverage based on AI.

[0160] Specifically, test case generation can be shifted from being driven by human experience to being driven by AI autonomous learning. By constructing an intelligent closed loop of scenario space exploration, coverage assessment, and test case optimization, the system can automatically discover testing blind spots, generate high-value test scenarios, and continuously optimize the test set to achieve maximum coverage with the minimum number of test cases, realizing a paradigm shift from exhaustive testing to intelligent testing. In the specific implementation, the collaborative working process of the AI ​​test case generator 26 and the intelligent analysis and optimization unit 25 can be referred to, which will not be elaborated here in the embodiments of this application.

[0161] In some embodiments of this application, the integrated diagnostic flashing module 54 can be deployed across the user interaction layer and the software function layer. Specifically, it works in conjunction with the protocol fusion processing module and the integrated simulation engine to perform diagnostic services and program flashing processes in the simulation environment based on the deeply integrated UDS protocol, thereby achieving unified diagnosis and program flashing for both the simulated ECU and the real ECU.

[0162] The diagnostic service and program flashing process can be manifested as providing a unified diagnostic flashing interface at the user interaction layer; implementing diagnostic session control, data reading and writing, routine control, fault code management, and firmware flashing functions at the software function layer; and communicating with the real ECU or simulated ECU through a multi-protocol fusion communication architecture protocol interface, thereby achieving unified diagnosis and flashing of simulated and real ECUs without switching between multiple tools. Optionally, the integrated diagnostic flashing module 54 can perform the integrated diagnostic and flashing steps of S603 below, which is not limited in this embodiment.

[0163] In some embodiments of this application, the security fault injection module 55 can be embedded in a multi-protocol converged communication architecture and a simulation engine architecture, mainly used to inject faults at different levels and ensure test security.

[0164] Optionally, the security fault injection module 55 can perform the fault injection and verification steps in S604 below.

[0165] Specifically, the security fault injection module 55 can adopt a layered injection mechanism (simulation level, signal level, hardware level) and hardware protection circuits. The layered injection mechanism can include simulation-level injection embedded in a simulation engine architecture, signal-level injection embedded in an FPGA signal link with a multi-protocol fusion communication architecture, and hardware-level injection implemented through hardware protection circuits. Fault coverage includes the physical layer (e.g., signal short circuit, open circuit), protocol layer (e.g., frame loss, CRC error), and application layer (e.g., data out of bounds, logic error). It integrates fault whitelist control, pre-injection security checks, real-time monitoring, and emergency stop functions to ensure secure and controllable fault injection, while also supporting automatic exploration of key fault combinations based on AI algorithms.

[0166] In practical applications, predictive simulation and safety fault injection mechanisms based on digital twins can overcome the limitations of passive response in traditional simulations, enabling the construction of a digital twin-driven predictive simulation system with prediction, verification, and evolution capabilities. By integrating basic simulation models, degradation models, and real-time data calibration, it achieves a leap from single-condition simulation to full lifecycle degradation prediction. Combined with a layered safety fault injection engine, it enables proactive exploration of extreme conditions, boundary conditions, and potential failure modes while ensuring test safety, significantly improving the system's robustness verification capabilities.

[0167] In its implementation, it involves a digital twin model layer, a layered security fault injection engine, and a twin synchronization mechanism.

[0168] The digital twin model layer integrates the basic simulation model and the degradation model. The degradation model simulates sensor aging (such as MEMS structural fatigue and circuit drift) and ECU performance degradation (such as memory wear and decreased computing power), and simulates the characteristic changes after long-term use through accelerated aging algorithms. Health status assessment: a State of Health (SOH) is introduced to quantify the health of the current model. Based on historical simulation data and measured data, the SOH is updated in real time using Kalman filtering or particle filtering. Based on the SOH trend and degradation rate, the Remaining Useful Life (RUL) of the sensor / ECU is predicted, and the corresponding failure modes are triggered in advance in the simulation.

[0169] The layered security fault injection engine can construct a three-dimensional fault space covering the physical layer, protocol layer, and application layer. Physical layer faults include signal short circuits, open circuits, and noise interference; protocol layer faults cover frame loss, CRC errors, and timing violations; and application layer faults involve data out-of-bounds errors and logical errors.

[0170] Optionally, the engine employs a layered injection mechanism to ensure safety and comprehensiveness. Simulation-level injection occurs at the model level, posing no hardware risk; signal-level injection operates on the signal links within the FPGA, implemented through hardware isolation; hardware-level injection requires dedicated protection circuitry (such as current limiting, voltage clamping, and isolating switches) to ensure the safety of the hardware itself. In terms of safety control, the engine can integrate multiple safeguards, including whitelist control (allowing only predefined combinations of safe faults), pre-injection safety checks, and real-time monitoring and emergency stop functions. Furthermore, the engine can automatically explore and discover fault combinations and injection sequences most likely to trigger system failure based on genetic algorithms or reinforcement learning techniques, thereby achieving intelligent exploration and verification of the system's "worst-case" scenario.

[0171] The digital twin synchronization mechanism supports real-time data transmission from the actual vehicle. The digital twin dynamically calibrates model parameters and SOH status based on measured data. It operates in a parallel verification mode (i.e., shadow mode): the digital twin runs in parallel with the actual vehicle or high-fidelity model, continuously comparing the predicted output with the actual output. When the deviation exceeds a threshold, it triggers a model update or an anomaly alarm. Fault propagation tracing logic is implemented within the FPGA to record how a single-point fault propagates to other parts of the system through protocol conversion and model coupling, generating a fault tree and impact chain diagram.

[0172] In some embodiments of this application, the distributed collaborative unit 56 can be mainly used to realize scalable simulation and collaborative development from single ECU simulation to whole vehicle-level system verification based on a distributed and intelligent extended architecture.

[0173] Specifically, the distributed collaborative simulation and cloud-edge-device integrated architecture mainly manifests in breaking through the bottlenecks of single-machine simulation computing power and scale, and constructing a three-layer collaborative architecture of cloud-based large-scale parallel simulation + edge real-time HIL + terminal lightweight verification. Through task decomposition, load balancing, and state synchronization mechanisms, it achieves scalable simulation from a single ECU to a vehicle-level system, and supports collaborative development and testing by geographically distributed teams, upgrading simulation capabilities from a single-point tool to a distributed service. Optionally, the distributed collaborative unit 56 can execute the distributed collaborative simulation steps of S605 below, which will not be elaborated upon in this embodiment.

[0174] In a simulation system, system data flow can form a complete closed loop from configuration to execution based on the four major architectures mentioned above. System data flow mainly includes user configuration flow, simulation execution flow, bus monitoring flow, diagnostic service flow, and distributed data flow.

[0175] The user configuration flow can be represented by configuring parameters through the user interaction layer. These parameters are then parsed by the software functional layer and stored in the storage module. The integrated simulation engine then reads the configuration from the storage module and loads the corresponding model and protocol stack instances. Specifically, users can select models, configure parameters, define scenarios, and set protocols through the GUI. The configuration data is parsed by the software functional layer and stored in a configuration database, allowing the simulation engine to read the configuration and load the corresponding model and protocol stack instances.

[0176] The simulation execution flow is used to drive the operation of sensor models and ECU behavior models. Specifically, it can be manifested as the integrated simulation engine driving the model to run and generate simulation data according to the scheduling strategy. The simulation data can be encapsulated by a multi-protocol fusion communication architecture and sent down to the hardware interface layer by the core processing unit. Then, it can be output to external devices or fed back to the internal monitoring module through the multi-protocol interface of the hardware interface layer.

[0177] It should be noted that simulation data output to external devices can be used to implement bus monitoring streams. Simulation data fed back to the internal monitoring module can be used for closed-loop verification, debugging support, data logging, anomaly detection, and synchronous verification. Closed-loop verification involves comparing the data generated by the simulation engine with the expected output in real time to verify the correctness of the simulation model. Debugging support allows developers to observe the simulation data stream in real time through the GUI interface, facilitating model debugging and parameter tuning. Data logging means the internal monitoring module also performs data logging, storing simulation data for subsequent analysis and playback. Anomaly detection allows the monitoring module to detect whether simulation data exceeds reasonable limits, promptly identifying model anomalies or configuration errors. Synchronous verification involves comparing internal simulation data with external real data during HIL testing to assess simulation confidence.

[0178] The bus monitoring stream is used for real-time visualization of the status and data flow of a multi-protocol bus. Specifically, external data is collected through the hardware interface layer, parsed by the core processing unit of the multi-protocol converged communication architecture, and then sent to the bus monitoring module in the user interaction layer for real-time visualization.

[0179] The diagnostic service flow can be represented as follows: diagnostic requests are received and parsed by the protocol stack module of the multi-protocol converged communication architecture, and then processed by the integrated diagnostic flushing module. The diagnostic requests can be sent by external diagnostic tools or internal scripts; the processing results can be returned through the multi-protocol converged communication architecture using the corresponding protocol, thereby realizing the closed-loop execution of diagnostic commands.

[0180] Distributed data flow can be manifested as data interaction between edge nodes and the cloud through state synchronization and collaboration mechanisms; terminal verification clients access simulation resources and test data from the cloud or edge nodes via the network. The state synchronization and collaboration mechanism uses the PTP protocol to achieve three-layer clock synchronization between the cloud, edge, and terminal, and supports breakpoint resumption through state snapshots. It employs a hybrid consistency model to ensure data consistency and features fault tolerance and degradation mechanisms as well as collaborative development support.

[0181] In this embodiment, the simulation system integrates multiple communication protocols such as SENT, PSI5, DSI3, CANFD, and automotive Ethernet to achieve multi-protocol collaborative simulation testing. This embodiment leverages the simulation system's capabilities for multi-protocol parallel access, integrated modeling of full-scenario parameters, simultaneous execution of multi-dimensional tasks, unified data acquisition across the entire link, and automated analysis and verification. It integrates all verification elements, including multi-protocol adaptation, full-scenario operating conditions, fault injection, diagnostic flashing, and performance verification, into a single test session. Through deep collaboration among modules within the system, it achieves one-time configuration, one-time execution, and full verification, eliminating the need for multiple tests per protocol and scenario. Compared to traditional single-protocol testing equipment, the simulation system provided in this embodiment significantly improves the testing efficiency for sensors and ECUs. A single test can complete full-scenario verification under a multi-protocol environment, effectively avoiding time waste and configuration errors caused by changing test equipment.

[0182] Reference Figure 6 This document illustrates a flowchart of a sensor and ECU simulation method based on multi-protocol fusion, as provided in an embodiment of this application. Figure 1 The full-stack integrated architecture shown, such as Figure 2 The simulation engine architecture shown is as follows: Figure 3 The multi-protocol converged communication architecture shown, and as Figure 4 The distributed and intelligent scaling architecture shown works in concert, which may include the following steps:

[0183] Step S601, Protocol fusion and synchronization steps.

[0184] In some embodiments of this application, a multi-protocol converged communication architecture can be used to perform hardware-level decoding of heterogeneous protocol data from SENT, PSI5, DSI3, CAN / CANFD, and automotive Ethernet within an FPGA. This converts the multi-protocol data into a unified intermediate frame format and writes a unified high-precision timestamp at the decoding time, resulting in intermediate frame format data with a unified timestamp. In other words, cross-protocol data adaptation, conversion, and time alignment are achieved through a hardware pipeline. Furthermore, standardized data with conversion quality identifiers are generated based on routing tables and semantic mapping rules, which means that multi-protocol data is cached, time aligned, and has conversion quality identifiers.

[0185] Specifically, the decoding stage can be characterized by the protocol decoding module of the multi-protocol converged communication architecture performing frame synchronization, data extraction and error detection on the bit streams received from each protocol interface, and restoring the frame structure and payload.

[0186] The format conversion stage can be characterized by encapsulating the decoded data into a unified intermediate format, performing cross-protocol data adaptation based on preset semantic mapping rules, handling precision and data format differences between different protocols, and marking conversion quality with QoS identifiers. A conversion whitelist mechanism is also used for functional safety-critical signals. The semantic mapping rules can include signal identifier mapping, unit conversion, and precision alignment.

[0187] The time synchronization phase can be characterized by using the FPGA's global high-precision clock (based on an external high-stability crystal oscillator) to write a timestamp to each data frame during data decoding. Through multi-level FIFO buffers and hardware comparator logic, data streams with different sampling rates are sorted and aggregated. Data is then resampled to a common time grid using interpolation or decimation algorithms to ensure time consistency of cross-protocol data.

[0188] The encoding and distribution phase can be characterized by the protocol encoding module re-encoding the converted intermediate data into target protocol data frames, and the data routing module distributing the data to the target protocol interface, simulation engine, or data storage module according to the routing table.

[0189] The unified intermediate frame format can include at least the timestamp, data source (virtual channel ID), data type, data content, conversion quality identifier (QoS), and protocol type fields. The timestamp resolution should be no less than 1μs to ensure the traceability and synchronization accuracy of multi-protocol data.

[0190] Step S602, Dynamic simulation and intelligent optimization step.

[0191] In some embodiments of this application, a parameterized model library can be loaded onto a multi-core CPU based on a simulation engine architecture. Sensor and ECU co-simulation can be executed according to a hybrid scheduling strategy. A dynamic parameter configuration unit enables uninterrupted updating of model parameters. An intelligent analysis and optimization unit compares simulation results with reference data, automatically identifies deviations, and optimizes model parameters and test scenarios. Furthermore, an AI test case generator generates high-value test cases. Specifically, a sensor and ECU co-simulation model can be run on a multi-core CPU based on a parameterized model library and a global parameter table. Simulation tasks are executed according to a hybrid scheduling strategy that is time-driven as the foundation, supplemented by event-driven scheduling, and guaranteed by fixed priorities. During simulation execution, model parameters and environmental variables are updated uninterruptedly through the dynamic parameter configuration unit.

[0192] Specifically, model parameter updates can be implemented by managing key parameters of sensor and ECU models through a globally shared parameter table. An atomic update + version number mechanism is used, with the simulation engine loading the latest version of the parameter set at the end of each simulation step. Online adjustment of environmental variables is supported, and the environmental layer model automatically corrects physical / dynamic layer parameters. These environmental variables can include parameters such as temperature, humidity, and power supply voltage collected from simulation presets or real sensors.

[0193] Intelligent deviation analysis can be manifested by importing real vehicle test or bench data as the target reference curve, aligning the simulation results with the reference data over time, calculating residuals and statistical indicators (such as mean, variance, spectral characteristics, etc.), and using statistical / machine learning models to identify the type of deviation and locate the affected model parameters.

[0194] Automatic closed-loop optimization can be manifested as using the deviation analysis results as the objective function, employing algorithms such as genetic algorithms and particle swarm optimization to search for the optimal parameter set, updating the model library after simulation verification, and automatically generating or adjusting test scenarios for working conditions with large deviations to form new regression test cases.

[0195] AI test case generation can be manifested as abstracting the test scenario into a multi-dimensional space such as environment, operating conditions, protocol, and fault, training an AI model based on historical test data, automatically generating a sequence of test scenarios that can maximize coverage gain or fault detection rate, and triggering the simulation task scheduler to execute the test.

[0196] Specifically, the hybrid scheduling strategy can be as follows: safety-critical tasks (such as braking and steering-related tasks) can be scheduled with fixed priority and cannot be preempted, and their execution timing is strictly guaranteed by the FPGA hardware clock; real-time periodic tasks (such as control loop simulation and data acquisition) can be scheduled with time-driven scheduling and can be preempted by safety-critical tasks; important event tasks (such as diagnostic requests and scene switching) and background tasks (such as log recording and data backup) can be scheduled with event-driven scheduling, and important event tasks can preempt background tasks. This application does not impose any limitations on this approach.

[0197] Step S603, Integrated diagnostic and flashing process.

[0198] In some embodiments of this application, an integrated diagnostic flashing module can be used to generate diagnostic or flashing instructions based on an integrated automotive diagnostic service protocol stack, and send them to the simulated ECU or the real ECU via a multi-protocol fusion communication architecture. It can also receive response data from the simulated ECU or the real ECU and feed the response data back to the user interaction layer to complete the diagnostic service or program flashing process.

[0199] Specifically, in the integrated diagnostic and flashing process, secure access can be achieved through a challenge-response interaction with the target ECU via a secure access service based on the UDS protocol, completing authentication and access control. Diagnostic testing can be implemented by issuing diagnostic commands to the target ECU (such as reading fault codes, reading / writing data, executing routines, etc.), receiving response data through a multi-protocol converged communication architecture, and displaying diagnostic results at the user interaction layer. Flashing can be implemented by dividing the program to be flashed into multiple data blocks, using a sliding window protocol for parallel transmission and batch confirmation, recording the writing progress and verification results of each data block, supporting breakpoint resumption, and automatically rolling back to a stable program version when flashing fails or verification fails. Communication adaptation can be achieved through the protocol conversion function of the multi-protocol converged communication architecture, adapting diagnostic / flashing commands to the communication protocols supported by the target ECU, ensuring accurate command transmission and normal response reception.

[0200] Step S604, Fault Injection and Verification Steps.

[0201] In some embodiments of this application, a preset fault can be injected at the simulation level, signal level, or hardware level based on a security fault injection module. The fault propagation path can be tracked through a multi-protocol fusion communication architecture, and the impact of the fault on system performance can be analyzed using a simulation engine architecture to verify the system's fault tolerance and degradation strategies.

[0202] Specifically, in the fault injection and verification steps, fault configuration can be manifested by configuring parameters such as fault type, injection level, severity, and duration through the user interaction layer, and selecting safe fault combinations based on a fault whitelist; fault injection can be manifested by injecting faults at the simulation level (model level), signal level (FPGA signal link level), or hardware level (hardware interface level) according to the configuration, and monitoring the system status in real time during the injection process; fault propagation tracing can be manifested by recording the path and timing of the fault propagation from the injection point to other parts of the system through the fault propagation tracing logic in the FPGA, generating a fault tree and an impact link diagram; fault tolerance verification can be manifested by analyzing the system's response behavior after fault injection, verifying the system's fault tolerance capability and the effectiveness of the degradation strategy, evaluating the system's robustness, and feeding the verification results back to the intelligent analysis and optimization unit for scenario optimization.

[0203] Step S605, Distributed Collaborative Simulation Step.

[0204] In some embodiments of this application, complex simulation tasks can be decomposed and distributed to multiple computing nodes for parallel execution based on a cloud simulation cluster with a distributed and intelligent extension architecture; real-time hardware-in-the-loop testing can be performed on edge HIL nodes with a distributed and intelligent extension architecture; and remote access and collaborative operation can be performed on terminal verification clients with a distributed and intelligent extension architecture, with data consistency and simulation credibility of each node ensured through a state synchronization mechanism.

[0205] Specifically, in the distributed collaborative simulation process, task decomposition and scheduling can be manifested in the cloud-based simulation cluster breaking down complex simulation tasks, such as vehicle-level or multi-ECU collaborative simulation tasks, into multiple parallel-executable subtasks, such as single ECU simulation, sensor simulation, and network simulation. Then, a directed acyclic graph (DAG) of task dependencies is constructed based on the data dependencies between subtasks. Based on the real-time load of cloud computing nodes (such as CPU, memory, and network bandwidth), heuristic algorithms or deep reinforcement learning are used to dynamically allocate subtasks, minimizing the overall simulation time and achieving load balancing. Large-scale parallel execution can be manifested in the cloud supporting the simultaneous running of hundreds to thousands of simulation instances for scenarios such as Monte Carlo simulation, parameter scanning, and batch execution of AI test cases. Cloud resources are automatically requested or released based on task priority and deadlines, achieving a balance between cost and performance. Edge real-time testing can be manifested in edge HIL deployed at test sites or laboratories. The nodes directly connect to real ECUs and sensor hardware, running real-time operating systems (such as RT-Linux, VxWorks, etc.) to perform real-time hardware-in-the-loop testing. Edge HIL nodes can also upload test data and status information to the cloud in real time, obtaining optimized model parameters and simulation scenarios from the cloud. Terminal interaction and collaboration can be manifested in the terminal verification client configuring simulation parameters, starting / stopping tests, monitoring real-time data, and downloading analysis reports through a unified web interface. It supports multiple users accessing the same simulation environment simultaneously, enabling cross-team and cross-regional collaborative development and test result sharing. Specifically, for the implementation of collaborative development support, it can support multiple engineers to access the same simulation environment simultaneously, each running independent tests. The system automatically isolates resources and data and provides a unified result storage and query interface. It supports cross-team and cross-regional test result comparison and analysis, and can implement role-based access control (RBAC) to record all operation logs, meeting functional safety and information security requirements.

[0206] It should be noted that it can guarantee microsecond-level deterministic response to the operation of real-time operating systems through edge HIL nodes; it can support cloud training and edge inference by using complex models to train and optimize in the cloud, and then deploying them to edge nodes for execution after lightweighting; it can provide lightweight simulation and rapid verification capabilities through terminal verification clients running on engineers' laptops or mobile devices; it can perform basic verification in offline environments by preloading common models and scenarios; and it can enable testing anytime, anywhere by accessing the simulation environment in the cloud or on edge nodes through a web interface.

[0207] Optionally, state synchronization can be ensured through multiple mechanisms.

[0208] State synchronization and coordination mechanisms can include clock synchronization, state snapshots, and fault tolerance and degradation.

[0209] Clock synchronization can be manifested as distributed clock synchronization on a time base, using the PTP protocol to achieve three-layer clock synchronization of cloud, edge, and device, with clock error controlled at the microsecond level (e.g., the clock synchronization error of the three-layer cloud, edge, and device is no more than 10 microseconds). In non-real-time scenarios, the NTP protocol is used as a supplement.

[0210] State snapshots can be represented by the system periodically or automatically saving a complete state snapshot of all simulation instances (including model variables, environmental parameters, communication status, etc.) at key simulation steps. This supports restoring simulations from any historical point in time, enabling breakpoint continuation of simulations, and thus enhancing fault tolerance.

[0211] Fault tolerance and degradation mechanisms ensure the service continuity and data integrity of the distributed simulation system under abnormal operating conditions. Their design follows the principles of edge autonomy, state traceability, and flexible scheduling. Edge autonomy manifests as edge HIL nodes automatically switching to offline mode when the network is interrupted, continuing real-time testing based on local caching, such as a local cache model and the latest state snapshot, with data persistently stored locally. State synchronization and recovery involve the system periodically generating distributed state snapshots with version tags, storing them at the edge and in the cloud. After network recovery, the state can be automatically synchronized, specifically through automatic comparison and incremental synchronization to ensure eventual consistency. Health monitoring and task migration are demonstrated by real-time monitoring of node status via heartbeats and resource detection. When a faulty node is marked as inactive, its tasks can be automatically migrated from the simulation task scheduler to healthy nodes, ensuring simulation continuity.

[0212] Step S606, Data Quality and Confidence Assurance Steps.

[0213] In some embodiments of this application, the integrity, consistency and credibility of the data after protocol conversion can be checked, the confidence level of the simulation results can be evaluated, and abnormal states in the simulation process can be detected and recovery strategies can be executed to ensure that the simulation process is stable and reliable.

[0214] Specifically, in the data quality and confidence assurance steps, data quality verification can be manifested in checking the integrity (whether it meets protocol requirements), consistency (whether it conforms to semantic mapping rules), and credibility (whether it reaches the preset QoS level) of the data after protocol conversion, and marking, excluding, or compensating for untrustworthy data; simulation confidence assessment can be manifested in calculating indicators such as residuals, mean error, and variance between simulation results and reference data to evaluate the credibility of the simulation model, and triggering the model optimization process when the confidence level is lower than the threshold; anomaly detection and recovery can be manifested in real-time monitoring of the model's running status, data... Based on the transmission status and hardware operating status, anomalies such as parameter out-of-bounds errors, transmission timeouts, protocol decoding errors, and hardware failures are identified, and recovery strategies such as parameter reset, scenario rollback, fault isolation, and breakpoint resumption are executed. For data consistency assurance, multiple mechanisms can be used to ensure consistency, which is manifested in the use of a hybrid strategy in the consistency model. Optionally, a strong consistency model can be used for the core simulation state data, while an eventual consistency model can be used for non-real-time data such as test logs and historical data. When multiple nodes modify shared resources at the same time, such as shared models or parameters, and conflicts arise, version control and a three-way merging strategy can be used to resolve the conflicts.

[0215] In some embodiments of this application, based on such Figures 1 to 4 The architecture shown, such as Figure 5 The simulation system structure shown, and as Figure 6 As shown in steps S601 to S606, this embodiment of the application can implement a hardware-accelerated multi-protocol data synchronization method, which specifically includes implementing a unified time stamp step and a data alignment step within an FPGA. The unified time stamp step involves generating a unified timestamp at the hardware moment of successful multi-protocol data decoding using the FPGA's global clock, and appending this timestamp to the corresponding intermediate frame. The data alignment step involves sorting and aggregating data streams from different protocols and sampling rates based on the unified timestamp using the FPGA's internal multi-channel FIFO and comparator logic, forming a time-aligned synchronized data set, which is then output to the upper-layer simulation engine or monitoring module.

[0216] In some embodiments of this application, a dynamic configuration and binding method for simulation models can be implemented, specifically including a scenario definition step and an environment reconstruction step. The scenario definition step involves generating a test scenario configuration file through a graphical interface or scripting language, defining a sequence of operating conditions in the configuration file, and binding each operating condition step with a specific sensor model instance, ECU model instance, and communication protocol channel configuration. The environment reconstruction step involves, during simulation operation, when operating condition steps change, the scenario management module automatically loads or unloads the corresponding model instance according to the configuration file, adjusts the model parameters and bound protocol channels, and notifies the protocol stack module to update synchronously with the simulation engine, enabling seamless reconstruction of the test environment without interrupting the simulation.

[0217] In some embodiments of this application, an ECU program flashing method supporting breakpoint resumption and parallel transmission can be implemented. Specifically, it may include a secure access step, an optimized transmission step, a breakpoint resumption step, and a secure rollback step. The secure access step involves a challenge-response interaction with the target ECU based on a secure access service using the UDS protocol, completing authentication and access control before flashing. The optimized transmission step involves dividing the program to be flashed into multiple data blocks during the program download phase and using a sliding window protocol for parallel data block sending and batch confirmation to reduce handshake attempts and improve transmission efficiency. The breakpoint resumption step involves recording the current writing progress and verification result after each data block is successfully written. If the flashing process is interrupted, the remaining data blocks are resumed from the last successfully written data block position after the connection is restored, and the integrity of the written portion is verified before resuming transmission. The full rollback step involves automatically rolling back to the previous stable program version retained in the ECU when flashing fails or verification fails.

[0218] In some embodiments of this application, a predictive simulation method for sensors and ECUs based on digital twins can be implemented. Specifically, it may include a twin model construction step, a secure fault injection step, a fault propagation tracing step, a predictive maintenance step, and a parallel verification mode (shadow mode) operation step. The twin model construction step involves establishing a digital twin model integrating a basic simulation model and degradation characteristics for the sensor and ECU. The model includes a health state vector (SOH) and degradation rate parameters to describe the performance evolution of the devices during long-term use. The secure fault injection step involves injecting single-point or combined faults at the simulation level, signal level, and hardware level based on a multi-level fault library and a layered secure injection mechanism. An adaptive injection strategy is used to search for the fault mode most likely to trigger system failure. The injection process is controlled by hardware protection circuits and a software whitelist. The fault propagation tracing step involves implementing fault propagation tracing logic within the FPGA. The system records the path and timing of fault propagation from the injection point to other parts of the system through protocol conversion and model coupling in real time, generating fault trees and impact chain diagrams. Predictive maintenance steps are manifested in predicting the remaining service life (RUL) of sensors / ECUs based on SOH trends and degradation rates, and triggering corresponding fault modes in advance in simulations to verify the system's fault tolerance and degradation strategies. Parallel verification mode (shadow mode) operation steps are manifested in the parallel operation of the digital twin with the real system or high-fidelity simulation model, continuously comparing its predicted output with the actual output. When the deviation exceeds a preset threshold, it triggers automatic calibration of the twin model parameters or issues a warning to the user.

[0219] In some embodiments of this application, an adaptive test case generation method based on artificial intelligence can be implemented, specifically including a scenario space modeling step, an AI-driven generation step, a multi-dimensional coverage evaluation step, and a test set optimization step. The scenario space modeling step involves abstracting the test scenario into a multi-dimensional space containing environmental parameters, operating condition parameters, protocol parameters, and fault parameters, and generating an initial test point set using an adaptive sampling method. The AI-driven generation step involves training a Generative Adversarial Network (GAN) or reinforcement learning algorithm based on a historical test database to automatically generate a sequence of test scenarios that maximizes coverage gain or fault detection rate; optionally, a rule-based generation method is used initially to assist the system. The multi-dimensional coverage evaluation step involves calculating multi-dimensional indicators such as scenario coverage, boundary coverage, fault coverage, and neural network coverage, and generating a coverage heatmap in the scenario space to guide subsequent test case generation. The test set optimization step involves using a greedy algorithm or integer programming to select the smallest subset from a large set of candidate test cases, minimizing test time while meeting the coverage target.

[0220] In some embodiments of this application, the embodiments of this application can realize a distributed collaborative simulation system and method, which may specifically include: a cloud simulation cluster, used to decompose complex simulation tasks into multiple sub-tasks and distribute them to multiple computing nodes for parallel execution through a dynamic load balancing algorithm, supporting large-scale Monte Carlo simulation and parameter scanning; edge HIL nodes, deployed at the test site, running a real-time operating system, directly connected to real ECU and sensor hardware, maintaining bidirectional communication with the cloud, and realizing a collaborative mode of "cloud training and edge inference"; a state synchronization mechanism, using the Precise Time Protocol (PTP) to ensure three-layer clock synchronization of cloud-edge-device, and ensuring data consistency in the distributed environment through state snapshots, version control, and conflict resolution strategies. The data consistency strategy adopts a hybrid model for different data types, strong consistency for the core simulation state, and eventual consistency for test logs and historical data; a fault tolerance and degradation mechanism, supporting offline independent operation of edge nodes, state caching and recovery, and heartbeat detection and task reassignment; and a collaborative development interface, supporting multi-user concurrent simulation, result sharing and comparison, and providing role-based access control and operation auditing functions.

[0221] In this embodiment, the simulation system adopts a layered and decoupled full-stack integrated architecture. This architecture includes a user interaction layer, a software function layer, a core processing unit, and a hardware interface layer. Each layer interacts with data and transmits instructions through standardized interfaces. The simulation system integrates a simulation engine architecture, a multi-protocol fusion communication architecture, and a distributed and intelligent expansion architecture. Specifically, a hardware resource pool deployed in the hardware interface layer and the core processing unit provides multi-protocol access, signal conditioning, and heterogeneous computing capabilities. A protocol fusion processing module deployed within the field-programmable gate array (FPGA) of the core processing unit, based on the multi-protocol fusion communication architecture, performs hardware-level encoding / decoding, time synchronization, and cross-protocol conversion of multi-protocol data. An integrated simulation engine, deployed on a multi-core central processing unit within the core processing unit, manages a parametric model library, schedules model simulation tasks, and generates simulation data. Through an integrated diagnostic flashing module deployed across the user interaction layer and software function layer, it collaborates with the protocol fusion processing module and the integrated simulation engine to execute diagnostic services and program flashing processes within the simulation environment based on an integrated automotive diagnostic service protocol stack. A security fault injection module, embedded within a multi-protocol fusion communication architecture and the simulation engine architecture, injects faults at different levels and ensures test safety. A distributed collaborative unit, based on a distributed and intelligent extension architecture, enables scalable simulation and collaborative development from single ECU simulation to vehicle-level system verification. Architectural innovation achieves unified access, parallel processing, and time synchronization of heterogeneous protocols; high-precision dynamic modeling based on environmental awareness allows the simulation module to adapt to real-world dynamics and environmental changes; and a data-driven test closed loop integrates simulation, diagnosis, and optimization, thereby realizing a fully integrated simulation verification platform from signal level to system level, and from simulation to diagnosis.

[0222] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0223] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other.

[0224] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments described herein can be implemented in an order other than that illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or device that includes a series of steps or modules is not necessarily limited to those steps or modules explicitly listed, but may include other steps or modules not explicitly listed or inherent to these processes, methods, products, or devices. The division of modules in the embodiments of this application is merely a logical division; in actual applications, there may be other division methods. For example, multiple modules may be combined into or integrated into another system, or some features may be ignored or not performed. Additionally, the shown or discussed mutual coupling or direct coupling or communication connection may be through some interface, and the indirect coupling or communication connection between modules may be electrical or other similar forms, none of which are limited in the embodiments of this application. Furthermore, the modules or sub-modules described as separate components may or may not be physically separated, may or may not be physical modules, or may be distributed among multiple circuit modules. Some or all of the modules may be selected according to actual needs to achieve the purpose of the embodiments of this application.

[0225] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions in other embodiments.

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

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

[0228] Furthermore, the functional modules in the various embodiments of this application can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium.

[0229] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0230] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0231] The technical solutions provided in the embodiments of this application have been described in detail above. Specific examples have been used in the embodiments of this application to illustrate the principles and implementation methods of the embodiments of this application. The description of the above embodiments is only for the purpose of helping to understand the methods and core ideas of the embodiments of this application. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of the embodiments of this application. Therefore, the content of this specification should not be construed as a limitation on the embodiments of this application.

Claims

1. A sensor and ECU simulation system based on multi-protocol fusion, characterized in that, The simulation system adopts a layered and decoupled full-stack integrated architecture, which includes a user interaction layer, a software function layer, a core processing unit, and a hardware interface layer. Each layer interacts with data and transmits instructions through standardized interfaces. Furthermore, the simulation system integrates a simulation engine architecture, a multi-protocol fusion communication architecture, and a distributed and intelligent expansion architecture, specifically including: A hardware resource pool is deployed in the hardware interface layer and the core processing unit to provide multi-protocol access, signal conditioning and heterogeneous computing capabilities. The protocol fusion processing module, based on the multi-protocol fusion communication architecture, is deployed within the field-programmable gate array of the core processing unit and is used for hardware-level encoding and decoding, time synchronization, and cross-protocol conversion of multi-protocol data. An integrated simulation engine, based on the simulation engine architecture, is deployed on the multi-core central processing unit of the core processing unit. It is used to manage the parameterized model library, schedule model simulation tasks, and generate simulation data. An integrated diagnostic flashing module is deployed across the user interaction layer and the software function layer. The integrated diagnostic flashing module works in conjunction with the protocol fusion processing module and the integrated simulation engine to execute diagnostic services and program flashing processes in a simulation environment based on an integrated automotive diagnostic service protocol stack. A security fault injection module is embedded in the multi-protocol fusion communication architecture and the simulation engine architecture, and is used to inject faults at different levels and ensure test security. A distributed collaborative unit is used to realize scalable simulation and collaborative development from single ECU simulation to vehicle-level system verification based on the distributed and intelligent extended architecture. The multi-protocol converged communication architecture includes: The protocol interface layer corresponds to the multi-protocol communication interface of the hardware interface layer. The protocol decoding / encoding module is responsible for the bidirectional conversion between protocol data and the system's unified intermediate format. The decoding process includes frame synchronization, data extraction, and error detection, while the encoding process includes data encapsulation, verification generation, and frame formatting. The protocol conversion and data synchronization engine is deployed within the field-programmable gate array (FPGA) and is used to perform cross-protocol data adaptation and conversion through a three-level hardware pipeline. It also uses the global clock of the FPGA to inject a unified timestamp into all data and performs time alignment of data streams with different protocols and sampling rates through multi-level buffers and hardware comparator logic. The data routing module is used to distribute the converted unified format data to the target protocol communication interface, the integrated simulation engine, or the storage module of the hardware interface layer according to a static or dynamic routing table. A unified data format unit is used to define an internal data structure; wherein the internal data structure includes at least a timestamp, data source, data type, data content, and quality identifier field.

2. The system according to claim 1, characterized in that, The hardware resource pool includes: A multi-protocol communication interface is deployed on the hardware interface layer and supports multiple communication protocols. Each communication protocol corresponds to an independent interface module, and each interface module integrates the physical layer transceiver chip, electrical isolation and protection circuit corresponding to the communication protocol. A configurable signal conditioning module is located between the multi-protocol communication interface and the analog-to-digital / digital-to-analog converter unit in the hardware interface layer. It includes a programmable gain amplifier and a configurable filter. The gain and cutoff frequency of the programmable gain amplifier and the configurable filter are dynamically configured according to the protocol type and signal characteristics. The heterogeneous processing core includes a multi-core central processing unit and a field-programmable gate array interconnected via a high-speed bus; wherein, the multi-core central processing unit serves as the control plane, running the operating system, protocol high-level logic, and the integrated simulation engine, and the field-programmable gate array serves as the data plane, performing protocol physical layer / link layer processing, protocol conversion, and time synchronization tasks.

3. The system according to claim 1, characterized in that, The simulation engine architecture includes: The simulated task scheduler adopts a hierarchical hybrid scheduling strategy; wherein, in the hierarchical hybrid scheduling strategy, the highest priority layer adopts fixed priority scheduling and is non-preemptive, the high priority layer adopts time-driven scheduling, and the medium priority layer and low priority layer adopt event-driven scheduling. The model library management unit is used to manage the parameterized model library; the parameterized model library includes a parameterized sensor model library and an ECU behavior model library, wherein the sensor model library contains layered models of physical layer, dynamic layer and environmental layer, and the ECU behavior model library contains control algorithm model and functional model; The model actuator is responsible for model calculations to form a closed-loop control loop through positive data flow, ECU processing, and feedback data flow, so as to realistically simulate the dynamic characteristics of the system. The dynamic parameter configuration unit is used to maintain the global parameter table and realizes real-time hot updates of model parameters during simulation through a publish-subscribe mechanism; The intelligent analysis and optimization unit is used to build an autonomous closed loop through full lifecycle data management, intelligent deviation analysis, automatic closed-loop optimization, and knowledge feedback; The AI ​​test case generator is used to model and generate test scenarios based on a multi-dimensional scene space, and to trigger the simulation task scheduler to execute tests.

4. The system according to claim 1, characterized in that, The distributed and intelligent scaling architecture includes: The cloud-based simulation cluster is used to decompose complex simulation tasks into multiple sub-tasks and construct a directed acyclic graph, dynamically allocating tasks based on real-time load. Edge nodes, deployed at the test site, are used to run a real-time operating system, directly connect to real ECUs and sensor hardware, and maintain bidirectional communication with the cloud; The terminal verification client runs on the engineer's terminal device and is used to access cloud or edge nodes via web technology or remote desktop protocols, supporting multi-user collaborative interaction.

5. The system according to claim 1, characterized in that, The diagnostic service and program flashing process provides a unified diagnostic flashing interface at the user interaction layer; implements diagnostic session control, data reading and writing, routine control, fault code management, and firmware flashing functions at the software function layer; and communicates with the real ECU or simulated ECU through the protocol interface of the multi-protocol fusion communication architecture.

6. The system according to claim 1, characterized in that, The security fault injection module adopts a layered injection mechanism and hardware protection circuit. The layered injection mechanism includes simulation-level injection embedded in the simulation engine architecture, signal-level injection embedded in the field-programmable gate array signal link of the multi-protocol fusion communication architecture, and hardware-level injection implemented through hardware protection circuits; the fault coverage is physical layer, protocol layer and application layer, and integrates fault whitelist control, pre-injection security check and real-time monitoring and emergency stop functions.

7. The system according to claim 1, characterized in that, The user interaction layer includes: The model configuration module is used to configure the sensor model, ECU behavior model, and communication parameters of each protocol stack. The bus monitoring module is used to acquire multi-protocol bus data through the multi-protocol fusion communication architecture, provide data filtering, statistical analysis and signal waveform display functions, and visualize the data stream; The diagnostic flashing module, serving as the interactive interface for integrating the diagnostic flashing module, is used to support the issuance of diagnostic commands, response monitoring, and program flashing operations.

8. The system according to any one of claims 1 to 7, characterized in that, The hardware interface layer also includes a storage module and a power management module; The storage module is deployed on the hardware interface layer and uses high-speed storage media to store model libraries, configuration parameters, test scenarios, operation logs and test data generated by the distributed architecture, and supports dynamic loading and updating. The power management module is used to provide multiple isolated power outputs and has overcurrent, overvoltage, and undervoltage monitoring and protection functions to provide safe power supply for the system architecture and the device under test.

9. The system according to claim 8, characterized in that, In the simulation system, the system data flow includes user configuration flow, simulation execution flow, bus monitoring flow, diagnostic service flow, and distributed data flow; Specifically, the user configuration flow involves configuring parameters through the user interaction layer, parsing the configured parameters through the software function layer, and storing them in the storage module; then, the integrated simulation engine reads the configuration from the storage module and loads the model and protocol stack instance. The simulation execution flow is as follows: the integrated simulation engine drives the model to run and generate simulation data; the simulation data is encapsulated by the multi-protocol converged communication architecture and then output to external devices or fed back to the internal monitoring module through the hardware interface layer. The bus monitoring flow specifically refers to: external data being collected through the hardware interface layer, and the external data being parsed by the multi-protocol converged communication architecture and then sent to the bus monitoring module of the user interaction layer; The diagnostic service flow is as follows: after the diagnostic request is received and parsed by the multi-protocol converged communication architecture, it is processed by the integrated diagnostic writing module; the processing result is returned through the multi-protocol converged communication architecture. The distributed data flow specifically refers to: data interaction between edge nodes and the cloud through a state synchronization and collaboration mechanism; terminal verification clients access simulation resources and test data of the cloud or edge nodes through the network; the state synchronization and collaboration mechanism uses a time synchronization protocol to achieve clock synchronization, supports breakpoint resume simulation through state snapshots, uses a hybrid consistency model to ensure data consistency, and has fault tolerance and degradation mechanisms and collaborative development support functions.

10. A sensor and ECU simulation method based on multi-protocol fusion, characterized in that, The method is based on the collaborative operation of the full-stack integrated architecture, simulation engine architecture, multi-protocol converged communication architecture, and distributed and intelligent expansion architecture as described in any one of claims 1 to 9, and specifically includes the following steps: The protocol fusion and synchronization steps are as follows: Based on the multi-protocol fusion communication architecture, hardware-level decoding of multi-protocol data is performed in the field-programmable gate array, the multi-protocol data is converted into a unified intermediate frame format, a unified timestamp is written at the decoding time, and standardized data with conversion quality identifier is generated based on the routing table and semantic mapping rules. The dynamic simulation and intelligent optimization steps are as follows: Based on the simulation engine architecture, a parameterized model library is loaded on a multi-core central processing unit, sensor and ECU collaborative simulation is executed according to a hybrid scheduling strategy, model parameters are updated without interruption through a dynamic parameter configuration unit, and the simulation results are compared with reference data using an intelligent analysis and optimization unit to automatically identify deviations and optimize model parameters and test scenarios, and high-value test cases are generated through an AI test case generator. The integrated diagnostic and flashing process is as follows: the integrated diagnostic and flashing module generates diagnostic or flashing instructions based on the integrated automotive diagnostic service protocol stack, and sends them to the simulated ECU or the real ECU through the multi-protocol fusion communication architecture. It also receives the response data from the simulated ECU or the real ECU and feeds the response data back to the user interaction layer to complete the diagnostic service or program flashing process. The fault injection and verification steps are as follows: Based on the security fault injection module, a preset fault is injected at the simulation level, signal level or hardware level. The fault propagation path is tracked through the multi-protocol fusion communication architecture. The impact of the fault on the system performance is analyzed using the simulation engine architecture to verify the system's fault tolerance and degradation strategy. The distributed collaborative simulation steps are as follows: the cloud simulation cluster based on the distributed and intelligent extended architecture decomposes complex simulation tasks and distributes them to multiple computing nodes for parallel execution; the edge nodes based on the distributed and intelligent extended architecture perform real-time hardware-in-the-loop testing; the terminal verification client based on the distributed and intelligent extended architecture performs remote access and collaborative operation, and the consistency of data and the credibility of simulation are ensured by the state synchronization mechanism. The steps for ensuring data quality and confidence are as follows: perform integrity, consistency and confidence checks on the data after protocol conversion, assess the confidence of simulation results, and detect abnormal states during the simulation process and implement recovery strategies.

Images