Automobile ECU cross-domain interaction verification method and system, electronic device and storage medium

Abstract

The application provides a kind of automobile ECU cross-domain interaction verification method, system, electronic equipment and storage medium, in the method, by introducing automobile ECU cross-domain interaction verification system between business layer and bottom bus tool, unified general operation instruction is converted into the private interface call instruction of each tool using mapping relationship, so as to shield the difference of bottom hardware interface, the decoupling of test logic and hardware tool is realized, the complexity and maintenance cost of cross-tool, cross-platform test are significantly reduced.Not only greatly reduces the complexity and maintenance cost of software and hardware engineering construction, but also makes it only need to update mapping configuration when switching vehicle type or upgrading tool without modifying business code, significantly improves the flexibility and scalability of test system.

Description

Technical Field

[0001] This invention relates to the technical field of automotive electronic testing, and in particular to a cross-domain interactive verification method, system, electronic device, and storage medium for automotive ECUs. Background Technology

[0002] With the increasing complexity of automotive electronic and electrical architectures and the dramatic increase in the number of onboard ECUs, cross-domain interaction verification between ECUs has become a critical aspect of the R&D process. In the R&D and verification of intelligent vehicles, especially in the early stages when no physical vehicle or test bench is available for automated software function verification of each ECU, it is necessary to use bus tools to simulate the vehicle network environment and perform cross-domain interaction verification of automotive ECUs from different functional domains. Currently, in the development and verification of automotive ECUs, bus tools (such as Vector CANoe, Tongxing Intelligent TSMaster, and Zhiyuan Electronics ZXDoc) are typically used to simulate the vehicle network environment, send messages, or perform diagnostic operations. These bus tools support various automotive bus protocols (such as CAN, LIN, FlexRay, and automotive Ethernet) to achieve cross-domain interaction verification between ECUs from different functional domains.

[0003] However, in existing technologies, different brands of bus tools often provide their own proprietary and incompatible application programming interfaces (APIs). When writing automated test scripts, test engineers must learn and call the proprietary API functions of specific bus tools. When testing requirements involve the collaborative operation of multiple hardware tools from different brands, or when hardware tools need to be changed during project transitions, test scripts often require large-scale refactoring or even rewriting. This tightly coupled architecture leads to complex software and hardware engineering setup, high maintenance costs, and a large workload for tool switching and adaptation, severely restricting the improvement of testing efficiency and the promotion of test automation.

[0004] Therefore, how to shield the differences in underlying hardware tools and decouple the test logic from the hardware tools is a technical problem that urgently needs to be solved. Summary of the Invention

[0005] In view of this, the purpose of the present invention is to provide a method, system, electronic device and storage medium for cross-domain interactive verification of automotive ECUs, so as to alleviate the technical problem that traditional technologies cannot achieve decoupling of test logic and hardware tools.

[0006] In a first aspect, the present invention provides a method for cross-domain interaction verification of automotive ECUs, applied to an automotive ECU cross-domain interaction verification system, the method comprising: Business operation requests from the business layer are converted into general operation instructions, which are used to perform cross-domain interactive verification of automotive ECUs in multiple different functional domains. Based on a preset mapping relationship, the general operation instructions are converted into private interface call instructions corresponding to the target bus tool; The private interface call instruction is sent to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

[0007] Furthermore, the automotive ECU cross-domain interactive verification system is pre-set with a standardized universal operation instruction set, which includes at least one of initialization instructions, connection instructions, signal read / write instructions, and diagnostic control instructions; The mapping relationship is configured to map each general operation instruction in the general operation instruction set to a private application interface function of a different brand bus tool.

[0008] Furthermore, the signal read / write instructions include signal write instructions and signal read instructions; The signal write instruction is mapped to call the signal send function of the target bus tool, and the signal read instruction is mapped to call the signal listen function of the target bus tool; The diagnostic control commands are mapped to diagnostic service request functions that invoke the target bus tool.

[0009] Furthermore, the method also includes: Obtain a test task, which contains multiple bus operations to be executed; The test task is parsed to generate a sequence of scheduling instructions; Each scheduling instruction in the sequence of scheduling instructions is converted into a corresponding private interface call instruction. The execution of private interface call instructions is controlled according to a preset timing sequence to ensure the timing consistency of cross-domain interactions.

[0010] Furthermore, the execution of the scheduling instruction sequence includes: Monitor the running status of each bus tool; According to the requirements of the test task, allocate corresponding hardware channels for each bus operation; Simultaneously execute bus operations on multiple hardware channels, as well as non-bus device control instructions associated with the bus operations.

[0011] Furthermore, the method also includes: Load pre-configured test cases, which contain business operation requests; Identify the business operation request and convert the business operation request into the general operation instruction; Execute the general operation instructions and obtain the execution results; A test report is generated based on the comparison between the execution results and the expected results.

[0012] Furthermore, the service operation request includes at least one of signal emulation request, message monitoring request, and diagnostic service request.

[0013] Secondly, the present invention also provides a cross-domain interaction verification system for automotive ECUs, comprising: The use case parsing module is configured to convert business operation requests from the business layer into general operation instructions pre-set by the adaptation layer module. These general operation instructions are used to perform cross-domain interaction verification of automotive ECUs in multiple different functional domains. The mapping configuration module is configured to store preset mapping relationships and convert the general operation instructions into private interface call instructions corresponding to the target bus tool based on the mapping relationships. The scheduling and execution module is configured to send the private interface call instruction to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

[0014] Thirdly, the present invention also provides an electronic device, including a memory and a processor, wherein the memory stores a computer program that can run on the processor, and the processor executes the computer program to implement the method described in the first aspect.

[0015] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the method described in the first aspect.

[0016] This invention provides a cross-domain interactive verification method for automotive ECUs, comprising: applying an automotive ECU cross-domain interactive verification system; the method comprising: converting business operation requests from the business layer into general operation instructions, which are used to perform cross-domain interactive verification on automotive ECUs of multiple different functional domains; based on a preset mapping relationship, converting the general operation instructions into private interface call instructions corresponding to a target bus tool, which is determined by loading a pre-configured test project file; and sending the private interface call instructions to the target bus tool to control the target bus tool to perform bus operations on the automotive ECU through the corresponding hardware channel. As can be seen from the above description, the automotive ECU cross-domain interactive verification method of this invention introduces an automotive ECU cross-domain interactive verification system between the business layer and the underlying bus tool, and uses a mapping relationship to convert unified general operation instructions into private interface call instructions for each tool, thereby shielding the differences in the underlying hardware interfaces, decoupling the test logic from the hardware tools, and significantly reducing the complexity and maintenance cost of cross-tool and cross-platform testing. This not only greatly reduces the complexity of building and maintaining software and hardware projects, but also allows for updating only the mapping configuration without modifying the business code when switching vehicle models or upgrading tools. This significantly improves the flexibility and scalability of the testing system and effectively solves the technical problems of difficult collaboration and high switching costs of heterogeneous tools in existing technologies. Attached Figure Description

[0017] To more clearly illustrate the specific embodiments of the present invention or the technical solutions in the prior art, the drawings used in the description of the specific embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0018] Figure 1 A flowchart illustrating a cross-domain interactive verification method for automotive ECUs provided in this embodiment of the invention; Figure 2 The hardware and software architecture design diagram of the test system provided in the embodiments of the present invention; Figure 3 A schematic diagram of a cross-domain interactive verification system for automotive ECUs provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

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

[0020] To facilitate understanding of this embodiment, a detailed description of a cross-domain interactive verification method for automotive ECUs disclosed in this embodiment of the invention will be provided first.

[0021] Example 1: According to an embodiment of the present invention, an embodiment of a cross-domain interactive verification method for an automotive ECU is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Furthermore, although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0022] Figure 1 This is a flowchart of a cross-domain interaction verification method for automotive ECUs according to an embodiment of the present invention, as shown below. Figure 1 As shown, the method includes the following steps: Step S100: Convert the business operation request from the business layer into a general operation instruction. The general operation instruction is used to perform cross-domain interaction verification of automotive ECUs in multiple different functional domains.

[0023] The core concept of this method lies in building a standardized middleware architecture, namely, setting up a cross-domain interaction verification system for automotive ECUs between business logic and underlying hardware tools. This system enables unified scheduling and control of heterogeneous bus tools, facilitating cross-domain interaction verification of automotive ECUs from multiple functional domains. The system comprises: a test case parsing module, an adaptation layer module, a mapping configuration module, a scheduling execution module, and a hardware interface management module. The functions of each module will be described below in conjunction with the method's execution process.

[0024] In this embodiment, the business layer typically refers to the automated test scripts or test case management platform written by testers. Its focus is on specific test business logic, such as "simulating vehicle speed signals" or "sending diagnostic commands," without concern for the underlying bus tools used by a particular manufacturer. General operation commands are standardized commands predefined by the automotive ECU cross-domain interaction verification system, independent of specific hardware brands. Specifically, the automotive ECU cross-domain interaction verification system exposes a unified application programming interface (API), which the business layer calls to issue business operation requests. For example, the business layer only needs to send a connection request, without needing to know whether the underlying connection function is called from the Vector tool or the Tongxing tool. The automotive ECU cross-domain interaction verification system (i.e. Figure 2 The bus tool software in the middleware, located logically below the business layer (i.e., the use case layer) and above the bus tool driver, serves to isolate changes. It should be understood that the automotive ECU cross-domain interaction verification system can be an independent dynamic link library file, an independently running proxy service process, or even encapsulated as a containerized service. Its specific form depends on the system's deployment requirements, as long as it can achieve the function of instruction relay and processing.

[0025] In practice, the use case parsing module converts the above business operation requests into general operation instructions that are the same as those preset by the adaptation layer module, so that the subsequent mapping configuration module can recognize the above general operation instructions.

[0026] Step S200: Based on the preset mapping relationship, the general operation instructions are converted into private interface call instructions corresponding to the target bus tool. The target bus tool supports multiple vehicle bus protocols and is determined by loading a pre-configured test project file.

[0027] This is the core processing logic of the automotive ECU cross-domain interactive verification system. Because the API function names, parameter definitions, and calling methods provided by different brands of bus tools (such as Vector CANoe, Tongxing TSMaster, Zhiyuan ZXDoc, etc.) vary, direct calls would result in extremely high code coupling. This embodiment solves this problem through a pre-defined mapping relationship. Specifically, the automotive ECU cross-domain interactive verification system (specifically the mapping configuration module) maintains a mapping configuration table or configuration file, which records the correspondence between general operation commands and the private API functions of each brand's tools. When the mapping configuration module receives a general operation command, it parses the command type and parameters, and based on the target bus tool type configured in the current system, searches the mapping table to find the corresponding private interface call command. For example, if the general operation command is "write signal," and the target bus tool configured in the current system is Vector, the mapping configuration module will convert it into the Vector-specific "XL_WriteSignal" function call command; if the target bus tool is Tongxing, it will convert it into the Tongxing-specific "TSMaster_WriteSignal" function call command. This process achieves the "translation" of instruction semantics, transforming standardized abstract semantics into specific hardware execution semantics.

[0028] Step S300: Send the private interface call instruction to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

[0029] The aforementioned automotive ECU cross-domain interaction verification system is used to shield the interface differences between bus tools from different brands and achieve unified scheduling of heterogeneous bus tools.

[0030] After instruction translation is completed, the automotive ECU cross-domain interaction verification system (specifically the scheduling and execution module) acts as the driver invoker. Specifically, the scheduling and execution module loads the driver program for the target bus tool or sends the translated private interface call instructions to the target bus tool via inter-process communication. Upon receiving the instructions, the target bus tool parses the instruction parameters and drives the underlying hardware interface card (such as a CAN card or LIN card) to perform the corresponding physical operations, such as sending a message to the CAN bus, listening to LIN bus signals, or sending a diagnostic request via Ethernet. At this point, the intent of the business layer is truly executed at the physical level. Through these steps, the business layer and the underlying tool are completely decoupled. When the project needs to change the bus tool, the business layer code does not need to be modified; only the mapping relationship needs to be updated in the mapping configuration module, greatly reducing maintenance costs.

[0031] The specific structure of the general operation instruction set in the adaptation layer module and the configuration details of the mapping relationship are further explained in detail.

[0032] In this embodiment, the adaptation layer module has a pre-configured standardized universal operation instruction set, which includes at least one of initialization instructions, connection instructions, signal read / write instructions, and diagnostic control instructions. The use case parsing module is configured to convert business operation requests into universal operation instructions conforming to the universal operation instruction set format.

[0033] Specifically, initialization commands are used to configure the hardware parameters of the bus tool, such as sampling rate and sampling point location, which is a prerequisite for the bus tool to work; connection commands are used to establish the physical link and data communication session between the test host and the bus interface card; signal read / write commands are the most frequently used commands during the test, used to send signal data to or retrieve signal data from the bus; and diagnostic control commands are used to implement various diagnostic interactions under the UDS (Unified Diagnostic Services) protocol, such as reading fault codes and clearing fault codes. By abstracting these high-frequency and common operations into a standardized command set, developers at the business layer can operate the underlying hardware as if it were a local function, without having to consult complex hardware API documentation.

[0034] Furthermore, the mapping relationship is configured to map each general operation instruction in the general operation instruction set to a private application interface function of a different brand bus tool.

[0035] This mapping mechanism essentially establishes a "one-to-many" translation dictionary. It should be understood that although different brands of bus tools may have drastically different function names, parameter types, and call orders when implementing the same functionality, their physical behavior at the bus level is consistent. This invention utilizes this consistency of physical behavior to shield the differences in function calls within the mapping configuration module.

[0036] As a specific implementation of this embodiment, the signal read / write instructions include signal write instructions and signal read instructions.

[0037] Specifically, signal write instructions are mapped to call the signal send function of the target bus tool, signal read instructions are mapped to call the signal listen function of the target bus tool, and diagnostic control instructions are mapped to call the diagnostic service request function of the target bus tool.

[0038] To illustrate this mapping process more clearly, the following description uses the "signal write command" as an example: Suppose the business layer issues a business operation request "simulate vehicle speed signal of 80km / h". The use case parsing module converts this into a general "signal write command", which includes the signal name "Engine_Speed" and the target value "2000rpm". After receiving this command, the mapping configuration module will look up the mapping configuration table according to the target bus tool type registered in the current system. If the target bus tool is the Vector brand CANoe tool, the mapping configuration module will convert the general command into a Vector tool-specific API function, such as "XL_WriteSignal(Engine_Speed, 2000)", and handle its unique handle parameters and data type conversions. If the target bus tool is the TSMaster tool from the same brand, the mapping configuration module will convert it into a private API function of the same tool, such as "TSMaster_WriteSignal(Engine_Speed, 2000)", and pass parameters according to the calling convention required by the tool.

[0039] Through the mapping mechanism described above, regardless of the brand of hardware tools connected at the underlying level, the business layer only needs to maintain a unified set of code logic. When project requirements change and hardware tools are replaced, only the mapping configuration module needs to be updated, without modifying the test scripts in the business layer. This greatly improves the compatibility and maintainability of the testing system and solves the technical problem of tight coupling between test scripts and hardware tools in existing technologies.

[0040] This section provides a more detailed explanation of the dynamic scheduling and hardware resource coordination mechanism used by the system when handling complex test tasks. In real-world automotive electronics testing scenarios, multiple bus operations often execute concurrently, such as simultaneously monitoring CAN bus messages and simulating LIN bus signals. This places high demands on the system's multitasking capabilities.

[0041] The method provided in this embodiment also includes: the scheduling and execution module of the automotive ECU cross-domain interaction verification system obtains a test task, which includes multiple bus operations to be executed.

[0042] Specifically, test tasks are typically defined by testers using test scripts or test case files issued from the business layer. This task is not a single instruction, but rather a logical set of multiple operational steps. For example, a cross-domain interaction test task might include "Step 1: Send vehicle speed signal via CAN channel; Step 2: Control window movement via LIN channel; Step 3: Monitor diagnostic responses via Ethernet channel." After receiving the test task, the system first parses it, identifying all the atomic operations it contains and their interdependencies.

[0043] After the scheduling and execution module parses the test task, it generates a sequence of scheduling instructions.

[0044] This process transforms the business logic-level test steps into a sequence of scheduling instructions that the system can recognize and that possesses timing attributes. Each instruction in the scheduling instruction sequence clearly defines the operation type, target object, and execution parameters. More importantly, the system calculates the absolute trigger timestamp of each scheduling instruction based on the logical dependencies between operations (e.g., "Step 2 must be executed 500ms after Step 1 is completed"), thus forming a rigorous execution schedule.

[0045] Subsequently, the mapping configuration module converts each scheduling instruction in the scheduling instruction sequence into a corresponding private interface call instruction.

[0046] This conversion process utilizes the aforementioned mapping relationship to translate abstract scheduling instructions into specific hardware driver instructions. For example, the scheduling instruction "send vehicle speed signal" is converted into an API call to the Vector tool, and the scheduling instruction "control window movement" is converted into an API call to the Tongxing tool. The converted instructions are then sent to the execution queue to await issuance.

[0047] Finally, the scheduling and execution module controls the execution of each private interface call instruction according to a preset timing sequence.

[0048] At this point, the system kernel's scheduling engine begins to operate, maintaining a high-precision timer that strictly follows the timestamps set in the scheduling instruction sequence to trigger instruction issuance. This timing control mechanism ensures the repeatability and accuracy of the testing process, avoiding timing disruptions caused by system scheduling delays or CPU resource contention, thereby guaranteeing the authenticity and validity of the test results.

[0049] Furthermore, the execution of the scheduling instruction sequence specifically includes the following steps: First, the hardware interface management module of the automotive ECU cross-domain interaction verification system monitors the operating status of each bus tool.

[0050] In a multi-tool collaborative environment, the availability of hardware resources is dynamic. The system monitors the status of each bus interface card in real time through the hardware interface management module or by using an interrupt mechanism, including "idle," "busy," "faulty," or "offline." For example, if a CAN card of a certain brand is detected to be in a "busy" state (possibly occupied by other processes), the system will temporarily suspend sending new commands to that tool to prevent command execution failures or hardware deadlocks due to resource conflicts.

[0051] Secondly, the hardware interface management module allocates corresponding hardware channels for each bus operation according to the requirements of the test task.

[0052] Since testing tasks may involve networks with different protocols (such as CAN, LIN, and FlexRay), the system needs to route the commands to the correct physical channels based on their protocol type. For example, commands related to body control are assigned to channel 1 connected to the LIN bus, while commands related to the powertrain are assigned to channel 2 connected to the CAN bus. This dynamic allocation mechanism allows the system to flexibly adapt to different bench topologies, maximizing the utilization of hardware resources.

[0053] Finally, the scheduling and execution module synchronously executes bus operations on multiple hardware channels, as well as non-bus device control instructions associated with the bus operations.

[0054] This is a crucial step in achieving "cross-domain collaboration." The system utilizes multi-threading or asynchronous I / O technology to drive different hardware channels to execute their respective tasks in parallel. For example, within the same time slice, while system control channel 1 sends LIN messages, control channel 2 listens for CAN messages. This parallel processing capability significantly shortens the testing cycle, especially for complex scenarios requiring verification of real-time interaction logic between different domain controllers. It can realistically simulate the concurrent communication conditions of multiple domains in a real vehicle environment, significantly improving test coverage and efficiency.

[0055] The following section provides a more detailed explanation of how the system connects to business layer requirements and automates the entire testing process. In actual automotive electronics development and verification, test engineers typically focus more on the test logic itself, such as "verifying whether the doors lock after the vehicle speed exceeds a threshold," rather than getting bogged down in writing low-level hardware instructions. This embodiment addresses this pain point through a decoupled design of the cross-domain interaction verification system between the business layer and the automotive ECU.

[0056] The method provided in this embodiment also includes: the test case parsing module loading pre-configured test cases, which contain business operation requests.

[0057] Specifically, test cases are the carriers of test logic, and their form can be structured table files, script files, or database records. Test cases record test steps, expected results, and business operation requests. Business operation requests are highly abstract descriptions of the test's functionalities, such as "simulating a vehicle speed signal of 80 km / h" or "monitoring door status messages." When the system starts a test task, it first reads these pre-configured files, loads them into memory, and prepares them for subsequent parsing and execution. This pre-configuration approach separates the test logic from the execution engine, facilitating the reuse and management of test cases.

[0058] Subsequently, the use case parsing module identifies business operation requests and converts them into general operation instructions.

[0059] This is a crucial step in achieving decoupling of the business layer. The system has a built-in test case parsing module that can identify various business operation requests defined in test cases. The identification process is typically based on keyword matching or semantic analysis techniques. Once a specific business request is identified, the system translates it into a general operation instruction that the adaptation layer module can recognize. For example, for the business request "simulate vehicle speed signal of 80km / h", the system will parse it into "signal write instruction" and extract the signal name "Vehicle_Speed" and the value "80" as instruction parameters. This conversion process transforms the natural or semi-natural language description of the business layer into standardized machine instructions, laying the foundation for subsequent cross-tool adaptation.

[0060] In this embodiment, the service operation request includes at least one of the following: signal emulation request, message monitoring request, and diagnostic service request.

[0061] Among them, signal simulation requests correspond to the operation of injecting signals into the bus to simulate the behavior of vehicle sensors or actuators; message monitoring requests correspond to the operation of listening to bus communication data to verify the correctness of network communication; and diagnostic service requests correspond to the operation of executing the UDS diagnostic protocol to read or clear the internal state of the ECU. It should be understood that as testing requirements expand, the types of service operation requests can also include fault injection requests, network management requests, etc., and this embodiment does not exhaustively limit their scope. By defining a rich set of service request types, the system can cover the vast majority of testing scenarios.

[0062] Next, the general operation instructions are executed through the adaptation layer module, mapping configuration module, and scheduling execution module, and the execution result is obtained.

[0063] The adaptation layer module receives the general operation command and sends it to the mapping configuration module. The mapping configuration module, based on the type of the currently connected bus tool, converts the general operation command into the corresponding private interface call command. Then, the scheduling execution module calls the corresponding private interface to drive the hardware to perform the physical operation. For example, if the currently connected tool is Vector, the scheduling execution module will call Vector's API to send vehicle speed messages to the CAN bus; if the connected tool is a satellite-based tool, it will call the satellite-based API to perform the same operation. After the hardware execution is complete, it will feed back the operation result (such as successful transmission confirmation, received message data, diagnostic response codes, etc.) to the scheduling execution module. The scheduling execution module then encapsulates this low-level hardware feedback into a unified execution result and returns it to the use case parsing module.

[0064] Finally, the test case parsing module generates a test report based on the comparison between the execution results and the expected results.

[0065] After obtaining the execution result, the test case parsing module automatically compares it with the predefined expected result in the test case. For example, if the expected result is "receive the door lock signal within 500ms," the test case parsing module will check whether the timestamp and value of the actually received signal match this expectation. The comparison logic can include various modes such as equality judgment, range judgment, and timing judgment. Based on the comparison result, the test case parsing module automatically determines whether the test step is "passed" or "failed" and records detailed log information. After all test steps are executed, the test case parsing module summarizes all judgment results and generates a structured test report. The report typically includes a test summary, detailed step results, failure cause analysis, and raw data records. This complete closed-loop process allows test engineers to automatically obtain detailed test conclusions by only writing high-level business test cases, greatly improving testing efficiency and accuracy.

[0066] Specifically, the automotive ECU cross-domain interaction verification system provided in this embodiment includes an adaptation layer module, a mapping configuration module, a scheduling execution module, a test case parsing module, and a hardware interface management module. These modules work collaboratively to achieve unified adaptation and control of heterogeneous bus tools, building a stable and reliable test execution platform.

[0067] The following example uses the automated verification of cross-domain interaction functions of automotive ECUs as a specific application scenario to demonstrate the complete application process of the technical solution of this invention in a real-world testing environment. This embodiment will describe in detail the complete process from hardware environment setup to test execution, and will focus on demonstrating how the automotive ECU cross-domain interaction verification system achieves decoupling between the business layer and hardware tools, as well as the specific application of the general operation instruction set and mapping mechanism in actual testing.

[0068] I. Hardware Connection and Test Environment Setup The implementation of this invention first relies on a stable and reliable hardware testing environment that can realistically simulate the network architecture and electrical conditions of a vehicle and provide a hardware foundation for automated testing.

[0069] 1.1 Core Hardware Components Test Host: As the brain of the entire testing system, it is an industrial computer equipped with a general-purpose operating system, a bus testing software platform, and an automated script execution environment. It is responsible for executing test logic, processing test data, and generating test reports. In the architecture of this invention, the business-layer test scripts running on the test host interact with the underlying hardware tools through the automotive ECU cross-domain interactive verification system, achieving decoupling between business logic and hardware control.

[0070] Bus interface card: Serving as a bridge connecting the test host and the vehicle network, it is a general-purpose hardware device that supports multiple channels and various vehicle bus protocols (such as CAN, LIN, FlexRay, automotive Ethernet, etc.). It exchanges commands and data with the test host through a high-speed interface (such as Ethernet or USB), and simultaneously accesses different bus networks of the vehicle through its physical channels. In actual testing scenarios, test benches may be configured with bus interface cards from different brands. For example, Vector's VN1630A is used for CAN bus communication, while Tongxing's TC1016 is used for LIN bus communication. This heterogeneous hardware environment is precisely the technical pain point that this invention aims to address—the APIs of different brands of tools differ significantly, and direct calls lead to extremely high code coupling. This invention establishes a mapping relationship between general operation commands and the private APIs of various brands of tools through a mapping configuration module, thus shielding this difference.

[0071] The ECU system under test refers to multiple automotive electronic control units from different functional domains that are to be verified. These ECUs are interconnected through the vehicle bus network to achieve cross-domain functional interaction. The specific types and number of ECUs can be flexibly configured according to testing requirements, and may include, for example, body control modules, motor controllers, battery management systems, and driver assistance system controllers.

[0072] Power supply system: Composed of a programmable DC power supply, used to accurately simulate the vehicle's power environment, including battery voltage, ignition switch signals (such as IGN_ON, ACC), etc., and can simulate extreme conditions such as voltage fluctuations, undervoltage, and overvoltage.

[0073] Wiring harnesses and connectors: Customized, high-reliability test wiring harnesses are used to ensure that the power, ground, bus signals, and necessary discrete input / output signals of all ECUs can be correctly and reliably connected to the bus interface card and power system to form a complete electrical loop.

[0074] 1.2 Physical Connection Steps Control Connection: Connect the control port of the bus interface card to the corresponding network interface of the test host using a standard high-speed communication cable (e.g., Ethernet cable). After connection, configure the network on the test host to ensure it can establish a stable communication link with the bus interface card. This step corresponds to the connection command and is a prerequisite for the bus tool to work. In existing technologies, test engineers need to call the connection functions of the Vector tool and the Tongxing tool separately, resulting in significant code differences. In this invention, the business layer only needs to issue one connection request. The test case parsing module converts it into a general operation command, and the mapping configuration module automatically converts the general operation command into the corresponding private connection function call according to the brand of the currently connected tool, achieving the effect of "write once, run everywhere".

[0075] Bus Connection: Based on the network topology of the system under test, different physical channels of the bus interface card are connected to different vehicle bus networks. For example, channel 1 can be connected to a high-speed bus network primarily for the powertrain, and channel 2 can be connected to a low-speed bus network primarily for the vehicle comfort system. This connection method ensures that the test system can simultaneously monitor and intervene in communication between multiple network domains. All connections are completed through standardized bus connectors to ensure signal impedance matching and communication quality. This multi-channel connection scenario is the hardware foundation for the synchronous execution of bus operations on multiple hardware channels. This invention uses a hardware interface management module to monitor the operating status of each bus interface card in real time and dynamically allocate hardware channels according to the needs of the test task, ensuring that no resource conflicts occur when multiple tasks are executed concurrently.

[0076] Power connection: Connect the positive output of the programmable DC power supply in parallel to the constant power (BAT+) input pin of all the ECUs under test through the wiring harness; connect the other controlled output of the programmable DC power supply to the ignition signal (IGN_ON) input pin of all the ECUs; connect the ground (GND) pin of all the ECUs to the negative terminal of the power supply to form a complete common ground system to avoid communication errors introduced by potential difference.

[0077] Preliminary verification: After completing all physical connections, the test bench was powered on and self-tested to confirm that each ECU was powered normally, the bus interface card could be correctly recognized by the test host, and there were no continuous error frames on each bus network, laying the foundation for subsequent software engineering. This step corresponds to the initialization command, which is used to configure the hardware parameters of the bus tools.

[0078] II. Bus tool project construction and application of adaptation layer architecture The bus test software platform of the test host needs to be built with software engineering capabilities that can simulate vehicle network behavior, define test interfaces, and support automated control. This section will focus on demonstrating how the automotive ECU cross-domain interaction verification system plays a role in this process.

[0079] 2.1 Project Initialization and Hardware Mapping A new test project is created in the software platform. In the project's hardware configuration interface, physically connected bus interface cards are added, and each physical channel is bound to a virtual network defined in the software. Simultaneously, the communication parameters of each network, such as baud rate and sampling points, are configured according to the actual vehicle specifications. In existing technologies, the project initialization processes and configuration interfaces of different brands of bus tools (such as Vector CANoe and Tongxing TSMaster) vary, requiring test engineers to learn two separate operating methods. In this invention, the automotive ECU cross-domain interactive verification system exposes a unified project initialization interface. The business layer only needs to call the interface to send an initialization request. The test case parsing module converts this into a general initialization command, and the mapping configuration module automatically converts the general initialization command into the corresponding tool's private initialization function call, thus shielding the operational differences between different tools.

[0080] 2.2 Importing and Parsing Communication Databases Import the database file describing the vehicle's communication matrix. This file defines all bus messages, signals, and their attributes in an industry-standard format. The software platform will parse this file and establish a signal database within the project, enabling test scripts to access and manipulate bus data by signal name (rather than raw hexadecimal data). This database provides the mapping between signal names and physical values ​​for signal read / write commands, allowing the business layer to directly manipulate bus data by signal name without needing to know the underlying message ID and data byte position.

[0081] 2.3 Virtual Nodes and Network Simulation Several "virtual ECU" nodes are created in the project. These nodes are used to simulate the behavior of other ECUs that are missing in real-world testing or that require interaction with. The network behavior of each virtual node is configured. For example, one virtual node can be configured to periodically send simulated vehicle speed messages, while another node sends an acknowledgment message upon receiving a specific light control signal. This constructs a controlled and repeatable network environment. The creation and configuration process of virtual nodes essentially defines the specific content of signal simulation requests. The business layer can drive the virtual nodes to send signals through "signal write requests," thus realizing network simulation functionality.

[0082] 2.4 Creation of Test Functional Modules and Definition of General Instruction Set A dedicated "test function module" is created within the project. This module serves as the core interface connecting external automation scripts with the internal bus communication. Within this module, a series of functions are defined using a scripting language supported by the software platform, allowing external calls. For example, the `Set_Vehicle_Speed(speed)` function can be defined, whose internal logic converts the input speed value into a signal physical value conforming to the database definition, and then drives the corresponding virtual node or directly sends a message containing that signal to the bus. Similarly, the `Check_Brake_Light_Status()` function can be defined, whose internal logic continuously monitors the brake light signal status on the bus and returns the result to the external caller.

[0083] The definition process of these functions is precisely the concrete implementation of the general operation instruction set. This invention abstracts high-frequency and common bus operations (such as signal writing, signal reading, and diagnostic control) into a standardized instruction set, enabling developers at the business layer to operate the underlying hardware as if it were a local function, without needing to consult complex hardware API documentation. For example, the `Set_Vehicle_Speed` function corresponds to a signal writing instruction, and the `Check_Brake_Light_Status` function corresponds to a signal reading instruction. These general instructions are converted into private API function calls for different brand tools through a mapping configuration module, achieving unified scheduling across tools.

[0084] III. Implementation and Command Conversion Process of Automated Test Control Interface This invention drives the entire testing process through a self-developed automated control program running on the test host. This program interacts with the bus test software platform via an application programming interface (API). This section will detail the complete data flow path of general operation commands, from receiving and converting to sending.

[0085] 3.1 Software Platform Connection and Session Management The automated control program first establishes a connection with the bus test software platform via API and gains control of its object model. The program then opens and loads the test project file configured in the previous stage. The program locates and obtains references to the test function modules via API, thereby gaining the ability to call predefined functions within them. This process corresponds to the business layer (automated control program) sending a connection request to the automotive ECU cross-domain interactive verification system, which receives the request and prepares to perform the conversion processing.

[0086] 3.2 Bus Communication and Control: The Specific Process of Converting General-Purpose Instructions to Private Instructions Signal writing: The automation program writes target values ​​to specified bus channels, messages, and signals by calling the API. The API layer translates this operation into specific bus communication commands, which are sent to the network through the bus interface card, thereby simulating the behavior of a certain ECU. For example, the program can call Set_Vehicle_Speed(80) to simulate a vehicle reaching a speed of 80 km / h.

[0087] Signal Reading and Monitoring: The automation program can read the latest value of any signal on the bus synchronously or asynchronously via the API. Simultaneously, asynchronous event listeners can be set to immediately notify the automation program when the value of a signal changes or certain conditions are met, achieving real-time response.

[0088] Measurement Control: The automated program controls the start and stop of measurements on the software platform via API. Upon starting the measurement, bus communication begins recording and simulation; stopping the measurement ends the current recording cycle.

[0089] 3.3 Test Sequence Execution: Implementation of Multi-Task Cooperative Scheduling The automated program can call APIs to initiate predefined test sequences within the project. These test sequences can contain complex combinations of bus operations with timing requirements. The program can monitor the execution status of the test sequences and obtain the final pass / fail results as well as detailed execution logs. This process demonstrates a multi-task scheduling mechanism.

[0090] IV. Test Case Design and Automated Execution: A Complete Demonstration of Business Layer Decoupling Based on the aforementioned hardware and software infrastructure, the specific cross-domain interaction function verification is accomplished by writing structured test cases and having them executed by an automated system. This section will fully demonstrate how the business layer decouples itself from hardware tools through the automotive ECU cross-domain interaction verification system, enabling the autonomous writing of test logic.

[0091] 4.1 Structured Test Case Design: Definition of Business Operation Requests Each test case follows the following structure: Use case identification and description: Clearly describe the target function of the test, such as "to verify that the automatic door locking function is triggered when the vehicle speed exceeds the set threshold".

[0092] Prerequisites: Describe the state that the system must reach before the test begins, such as "the vehicle power status is IGN_ON, all doors are closed, and the gear is in P".

[0093] Test steps: Simulate the initial state (e.g., set the vehicle speed to 0) through the automation control interface; trigger test conditions (e.g., gradually increase the simulated vehicle speed to the target threshold); periodically or event-triggeredly check the response behavior of the target ECU through the automation control interface (e.g., listen for door lock command messages).

[0094] Expected results: Clearly define the correct behavior that each checkpoint should have, such as "within 500ms after the vehicle speed signal first exceeds XX km / h, a 'door lock' command message should be received from the body domain controller, and the signal value should be 'locked'".

[0095] Result determination criteria: Define how to give a final determination of "pass", "fail" or "blocked" based on the comparison between the actual response and the expected result.

[0096] 4.2 Test Execution and Scheduling: The Complete Process of Converting Business Requests into General Instructions The automated control program loads and executes test cases one by one according to the predetermined test plan.

[0097] First, the test case parsing module loads pre-configured test cases and identifies the business operation requests within them. For example, after identifying the business request "simulating a vehicle speed signal of 20 km / h," the test case parsing module converts it into a generic "signal write command," with parameters including the signal name "Vehicle_Speed" and the value "20." Similarly, after identifying the business request "monitoring the door lock signal," it converts it into a generic "signal read command," with parameters including the signal name "Door_Lock_Status." This process effectively identifies business operation requests and converts them into generic operation commands.

[0098] Then, the adaptation layer module receives these general operation instructions and converts them into private interface call instructions through the mapping configuration module. For example, if the currently connected tool is Vector (used for CAN bus communication), the adaptation layer will convert the "signal write instruction" into the Vector tool's "XL_WriteSignal" function call; if the connected tool is a satellite-based tool (used for LIN bus communication), the adaptation layer will convert the "signal read instruction" into the satellite-based tool's "TSMaster_ReadSignal" function call. This process achieves "converting general operation instructions into private interface call instructions corresponding to the target bus tool based on a preset mapping relationship."

[0099] Next, the scheduling and execution module sends the converted private instructions to the target bus tool, controlling it to execute bus operations. The Vector tool sends vehicle speed messages to the CAN bus, and the Tongxing tool starts listening to the LIN bus. Because the system has timing control capabilities, the two operations are executed synchronously within millisecond-level time errors, realistically simulating the real-time correlation between vehicle speed changes and door lock actions in a real vehicle. This process achieves "sending private interface call instructions to the target bus tool to control the target bus tool to execute corresponding bus operations."

[0100] Finally, the system acquires the execution results in real time (such as the door locking signal detected by the Xingxing tool) and compares them with the expected results. If the comparison is consistent, the test case is marked as "Pass" in the test report.

[0101] For each test case, the program automatically sets preset conditions and then executes the test steps sequentially. During execution, the test case parsing module continuously compares the actual behavior on the bus with the expected results defined in the test case. After all test steps are completed, the test case parsing module automatically generates the test result for that test case according to the decision criteria and records a detailed execution log, including the change curves of all key signals, event timestamps, etc. After the test execution is complete, the test case parsing module automatically summarizes the execution status of all test cases and generates a structured test report, which includes the overall pass rate, detailed error information of failed test cases, and related bus data log files, greatly facilitating problem localization and analysis.

[0102] V. Summary of Technical Effects: The specific manifestations of how this invention addresses the pain points of existing technologies. Through the above specific implementation methods, this invention achieves efficient, comprehensive, and reproducible automated verification of cross-domain interaction functions of automotive ECUs, significantly improving test coverage and reliability. More importantly, this invention effectively solves the following technical pain points of traditional technologies: Pain Point 1: "The hardware and software setup for test benches is complex and maintenance costs are high." This invention, through its automotive ECU cross-domain interactive verification system, decouples the business layer from the hardware tools. Test engineers only need to write one set of business logic code, eliminating the need to learn the APIs of different brands of tools, greatly reducing development difficulty and maintenance costs.

[0103] Pain Point Two: "When switching vehicle models, the software and hardware engineering almost needs to be rebuilt, resulting in a significant workload." This invention achieves the effect of "write once, run everywhere" through a universal operation instruction set and mapping configuration module. When the test bench hardware is changed from the "Vector + Tongxing" combination to the "Vector + Zhiyuan" combination, the test case code requires no modification; only the mapping configuration needs to be updated at the adaptation layer, greatly reducing the engineering adaptation workload when switching vehicle models.

[0104] Pain Point 3: "Mainstream manufacturers like Vector / DSPACE have extremely high prices, and other manufacturers' software has poor usability." This invention, through a cross-domain interactive verification system for automotive ECUs, shields the API differences between different brands of tools, allowing the testing system to flexibly choose more cost-effective tools from other manufacturers (such as Xingxing and Zhiyuan) without worrying about software usability issues, effectively reducing the procurement costs of the hardware and software tools required for testing.

[0105] Through the achievement of the above-mentioned technical effects, this invention fully demonstrates its significant effectiveness in solving the technical problems of difficult collaboration of heterogeneous tools, high switching costs, and large maintenance costs, and provides an efficient, flexible, and low-cost solution for the automated verification of cross-domain interaction functions of automotive ECUs.

[0106] Example 2: This invention also provides a cross-domain interaction verification system for automotive ECUs. This system is mainly used to execute the cross-domain interaction verification method for automotive ECUs provided in Embodiment 1 of this invention. The following is a detailed description of the cross-domain interaction verification system for automotive ECUs provided in this invention.

[0107] Figure 3 This is a schematic diagram of a cross-domain interaction verification system for automotive ECUs according to an embodiment of the present invention, as shown below. Figure 3 As shown, the device mainly includes: a use case parsing module 10, a mapping configuration module 20, and a scheduling execution module 30, wherein: The use case parsing module 10 is configured to convert business operation requests from the business layer into general operation instructions pre-set by the adaptation layer module. The general operation instructions are used to perform cross-domain interaction verification of automotive ECUs in multiple different functional domains. The mapping configuration module 20 is configured to store preset mapping relationships and convert general operation instructions into private interface call instructions corresponding to the target bus tool based on the mapping relationships; The scheduling and execution module 30 is configured to send private interface call instructions to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

[0108] This invention introduces a cross-domain interactive verification system for automotive ECUs between the business layer and the underlying bus tools. By utilizing mapping relationships, it transforms unified, general operation commands into private interface call commands for each tool, thereby shielding the differences in underlying hardware interfaces and decoupling the test logic from the hardware tools. This significantly reduces the complexity and maintenance costs of cross-tool and cross-platform testing. It not only greatly reduces the complexity and maintenance costs of software and hardware engineering but also allows for updates to the mapping configuration without modifying the business code during vehicle model switching or tool upgrades. This significantly improves the flexibility and scalability of the testing system and effectively solves the technical problems of difficult heterogeneous tool collaboration and high switching costs in existing technologies.

[0109] Optionally, the automotive ECU cross-domain interaction verification system is pre-configured with a standardized set of general operation instructions, which includes at least one of initialization instructions, connection instructions, signal read / write instructions, and diagnostic control instructions. The mapping relationship is configured to map each general operation instruction in the set of general operation instructions to a private application interface function of a different brand bus tool.

[0110] Optionally, the signal read / write instructions include signal write instructions and signal read instructions; the signal write instructions are mapped to calling the signal sending function of the target bus tool, and the signal read instructions are mapped to calling the signal listening function of the target bus tool; the diagnostic control instructions are mapped to calling the diagnostic service request function of the target bus tool.

[0111] Optionally, the device is also used to: acquire a test task, which includes multiple bus operations to be executed; parse the test task to generate a scheduling instruction sequence; convert each scheduling instruction in the scheduling instruction sequence into a corresponding private interface call instruction; and control the execution of each private interface call instruction according to a preset timing sequence to ensure the timing consistency of cross-domain interaction.

[0112] Optionally, the device is also used to: monitor the operating status of each bus tool; allocate corresponding hardware channels for each bus operation according to the requirements of the test task; and synchronously execute bus operations on multiple hardware channels, as well as non-bus device control commands associated with the bus operations.

[0113] Optionally, the device is also used to: load pre-configured test cases, which contain business operation requests; identify the business operation requests and convert them into general operation instructions; execute the general operation instructions and obtain the execution results; and generate a test report based on a comparison between the execution results and the expected results.

[0114] Optionally, the service operation request includes at least one of the following: signal emulation request, message monitoring request, and diagnostic service request.

[0115] The system provided in this embodiment of the invention has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment.

[0116] like Figure 4 As shown in the embodiment of this application, an electronic device 600 includes a processor 601, a memory 602, and a bus. The memory 602 stores machine-readable instructions that can be executed by the processor 601. When the electronic device is running, the processor 601 communicates with the memory 602 via the bus, and the processor 601 executes the machine-readable instructions to perform the steps of the above-described cross-domain interactive verification method for automotive ECUs.

[0117] Specifically, the memory 602 and processor 601 mentioned above can be general-purpose memory and processor, without any specific limitations. When the processor 601 runs the computer program stored in the memory 602, it can execute the above-mentioned cross-domain interactive verification method for automotive ECUs.

[0118] The processor 601 may be an integrated circuit chip with signal processing capabilities. In implementation, each step of the above method can be completed by the integrated logic circuitry in the hardware of the processor 601 or by instructions in software form. The processor 601 may be a general-purpose processor, including a Central Processing Unit (CPU), a Network Processor (NP), etc.; it may also be a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor may be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly manifested as execution by a hardware decoding processor, or execution by a combination of hardware and software modules in the decoding processor. The software module can reside in a mature storage medium in the art, such as random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, or registers. This storage medium is located in memory 602, and processor 601 reads the information from memory 602 and, in conjunction with its hardware, completes the steps of the above method.

[0119] Corresponding to the above-described cross-domain interaction verification method for automotive ECUs, this application embodiment also provides a computer-readable storage medium storing machine-executable instructions. When the machine-executable instructions are invoked and executed by a processor, the machine-executable instructions cause the processor to perform the steps of the above-described cross-domain interaction verification method for automotive ECUs.

[0120] The automotive ECU cross-domain interaction verification system provided in this application embodiment can be specific hardware on the device or software or firmware installed on the device. The system provided in this application embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, units, and processes described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

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

[0122] For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

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

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

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

[0126] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

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

Claims

1. A method for cross-domain interactive verification of automotive ECUs, characterized in that, The method, applied to a cross-domain interaction verification system for automotive ECUs, includes: Business operation requests from the business layer are converted into general operation instructions, which are used to perform cross-domain interactive verification of automotive ECUs in multiple different functional domains. Based on a preset mapping relationship, the general operation instructions are converted into private interface call instructions corresponding to the target bus tool; The private interface call instruction is sent to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

2. The method according to claim 1, characterized in that, The automotive ECU cross-domain interactive verification system is pre-set with a standardized set of general operation instructions, which includes at least one of initialization instructions, connection instructions, signal read / write instructions, and diagnostic control instructions. The mapping relationship is configured to map each general operation instruction in the general operation instruction set to a private application interface function of a different brand bus tool.

3. The method according to claim 2, characterized in that, The signal read / write instructions include signal write instructions and signal read instructions; The signal write instruction is mapped to call the signal send function of the target bus tool, and the signal read instruction is mapped to call the signal listen function of the target bus tool; The diagnostic control commands are mapped to diagnostic service request functions that invoke the target bus tool.

4. The method according to claim 1, characterized in that, The method further includes: Obtain a test task, which contains multiple bus operations to be executed; The test task is parsed to generate a sequence of scheduling instructions; Each scheduling instruction in the sequence of scheduling instructions is converted into a corresponding private interface call instruction. The execution of private interface call instructions is controlled according to a preset timing sequence to ensure the timing consistency of cross-domain interactions.

5. The method according to claim 4, characterized in that, The execution of the scheduling instruction sequence includes: Monitor the running status of each bus tool; According to the requirements of the test task, allocate corresponding hardware channels for each bus operation; Simultaneously execute bus operations on multiple hardware channels, as well as non-bus device control instructions associated with the bus operations.

6. The method according to claim 1, characterized in that, The method further includes: Load pre-configured test cases, which contain business operation requests; Identify the business operation request and convert the business operation request into the general operation instruction; Execute the general operation instructions and obtain the execution results; A test report is generated based on the comparison between the execution results and the expected results.

7. The method according to claim 6, characterized in that, The service operation request includes at least one of signal simulation request, message monitoring request, and diagnostic service request.

8. A cross-domain interactive verification system for automotive ECUs, characterized in that, include: The use case parsing module is configured to convert business operation requests from the business layer into general operation instructions pre-set by the adaptation layer module. These general operation instructions are used to perform cross-domain interaction verification of automotive ECUs in multiple different functional domains. The mapping configuration module is configured to store preset mapping relationships and convert the general operation instructions into private interface call instructions corresponding to the target bus tool based on the mapping relationships. The scheduling and execution module is configured to send the private interface call instruction to the target bus tool to control the target bus tool to perform bus operations on the vehicle ECU through the corresponding hardware channel.

9. An electronic device comprising a memory and a processor, wherein the memory stores a computer program executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 7.

10. A computer-readable storage medium storing a computer program thereon, characterized in that, The computer program is executed by the processor to perform the method of any one of claims 1 to 7.

Images