OTA simulation test method, device and equipment and storage medium

Abstract

The invention discloses an OTA simulation test method, device and equipment and a storage medium, and the method comprises the steps: responding to an input operation, and generating a target test case containing preset message data; executing the target test case, and in the execution process of the target test case, in response to a test task sent by the OTA cloud, configuring upgrade task information, making an upgrade file and uploading the upgrade file to the OTA cloud; in the process that the target controller loads an upgrade file from the OTA cloud through the simulation test bench to carry out OTA upgrade, simulation message data is generated according to the target test case, the power state and / or the communication state of each controller are / is controlled through the program control equipment according to the target test case, each piece of simulation message data is sent to a target participation node through the CANoe equipment, and the target participation node carries out OTA upgrade according to the simulation message data. Actual message data are captured through a CANoe device; and under the condition that execution of the target test case is completed, obtaining an upgrading result based on the actual message data, the simulation message data and the preset message data, and generating a test report according to the upgrading result.

Description

Technical Field

[0001] This application relates to the field of vehicle testing technology, and in particular to an OTA simulation testing method, apparatus, equipment and storage medium. Background Technology

[0002] With the rapid development of the automotive industry, Over-The-Air (OTA) technology has been increasingly widely used in the automotive field. The vehicle OTA upgrade process includes: upgrade package generation, version collection, upgrade package download, upgrade package deployment, and upgrade package installation.

[0003] For the above process, the participants include OTA cloud, in-vehicle intelligent terminal, gateway, controller, etc., and the communication protocols between multiple participants include, but are not limited to, Message Queuing Telemetry Transport (MQTT), Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Controller Area Network (CAN), Local Interconnect Network (LIN), Ethernet (ETH), etc.

[0004] In related technologies, the simulation testing method is usually based on building a simulation environment using the CANoe tool and simulating the OTA upgrade process by defining the communication architecture and task instructions. However, this method has at least one problem: there is a conflict between the data sent by the actual controller and the data sent by the simulation. Summary of the Invention

[0005] One of the purposes of this application is to provide an OTA simulation testing method, apparatus, device, and storage medium to resolve the conflict between the actual controller and the simulation data in the simulation test. The simulation message is calculated by combining a message conversion algorithm with a signal matrix table and a mapping table, and the generation logic is optimized to ensure data co-operation and compatibility to avoid conflicts.

[0006] To achieve the above objectives, the technical solution of this application embodiment is implemented as follows:

[0007] The technical solution of this application embodiment is implemented as follows:

[0008] Firstly, this application provides an OTA simulation testing method, the method comprising:

[0009] In response to input operations, a target test case containing preset message data is generated; wherein, the target test case includes at least any process of the upgrade object loading the upgrade file from the OTA cloud through the simulation test bench to perform OTA upgrade, and the target test case includes preset message data when the participating nodes in the simulation test bench communicate with each other, and the preset message data includes preset actual message data and preset simulation message data;

[0010] Execute the target test cases. During the execution of the target test cases, respond to the test tasks sent by the OTA cloud for the simulation test bench, configure the upgrade task information, and create the upgrade file associated with the upgrade task information and upload it to the OTA cloud. The upgrade task information includes the upgrade object and upgrade version information. The upgrade object includes at least one target controller in the simulation test bench.

[0011] During the OTA upgrade process where each target controller loads the upgrade file from the OTA cloud through the simulation test bench, multiple simulation message data corresponding to different communication protocols are generated according to the target test cases. The simulation message data is the message data sent by the target controller in the disconnected state to other participating nodes in the simulation test bench. The communication protocols used by different target controllers when communicating with other participating nodes may be the same or different.

[0012] Based on the target test cases, the power status and / or communication status of each controller are controlled by the programmable device, and each simulated message data is sent to the target participating node corresponding to the target controller in the disconnected state through the CANoe device for parsing and identification.

[0013] Based on the target test cases, capture the actual message data when communicating with the controller in the connected state using the CANoe device;

[0014] Once the target test cases have been executed, the upgrade results are obtained based on the actual message data, simulated message data, and preset message data, and a test report is generated based on the upgrade results.

[0015] Based on the aforementioned technical means, target test cases containing preset message data are automatically generated in response to input operations. These target test cases, generated based on input operations, can adapt to different upgrade scenarios (such as single controller upgrades and multi-controller concurrent upgrades), reducing manual configuration time. During the execution of the target test cases, the computer equipment automatically configures upgrade task information, creates and uploads upgrade files based on the test tasks sent by the OTA cloud, reducing manual operation time and error rates, making the testing process more efficient. During the OTA upgrade process where the target controller loads upgrade files from the OTA cloud through a simulation test bench, the controller's power / communication is controlled by a programmable device. The system disconnects and uses CANoe to send simulated messages, simulating extreme scenarios such as network interruptions and controller failures in a real vehicle (e.g., momentary network outages during high-speed driving) to verify the anti-interference capability of the upgrade process. It supports mixed transmission of simulated messages from multiple communication protocols, covering heterogeneous in-vehicle network environments and ensuring the integrity of upgrade data during cross-protocol communication. Test reports generated based on actual message data, simulated message data, and preset message data provide detailed data support for subsequent problem analysis and system optimization, helping to quickly locate the cause of problems and take corresponding measures. The automated testing process reduces reliance on expensive testing equipment and lowers labor costs, resulting in an overall reduction in testing costs.

[0016] Secondly, this application provides an OTA simulation testing device, the device comprising:

[0017] The response module is used to respond to input operations;

[0018] The processing module is used to generate target test cases containing preset message data; wherein, the target test cases contain preset message data when communication occurs between participating nodes in the simulation test bench, and the preset message data includes preset actual message data and preset simulation message data;

[0019] The processing module is also used to execute the target test cases;

[0020] The response module is also used to respond to the test task sent by the OTA cloud for the simulation test bench during the execution of the target test case;

[0021] The processing module is also used to configure upgrade task information, and to create an upgrade file associated with the upgrade task information and upload it to the OTA cloud; wherein, the upgrade task information includes upgrade object and upgrade version information, and the upgrade object includes at least one target controller in the simulation test bench;

[0022] The processing module is further configured to generate multiple simulation message data corresponding to different communication protocols according to the target test cases during the OTA upgrade process in which each target controller loads the upgrade file from the OTA cloud through the simulation test bench. The simulation message data is message data sent by the target controller in a disconnected state to other participating nodes in the simulation test bench. The communication protocols used for the message data when different target controllers communicate with the other participating nodes may be the same or different.

[0023] The processing module is further configured to control the power status and / or communication status of each controller through a programmable device according to the target test case, and send each simulation message data to the target participating node corresponding to the target controller in the disconnected state through a CANoe device for parsing and identification.

[0024] The processing module is also used to capture actual message data when communicating with the controller in a connected state through the CANoe device according to the target test case;

[0025] The processing module is further configured to, upon completion of the execution of the target test case, obtain an upgrade result based on the actual message data, the simulated message data, and the preset message data, and generate a test report based on the upgrade result.

[0026] Thirdly, this application provides a computer device, comprising: at least one processor, and a memory communicatively connected to the at least one processor; wherein,

[0027] The memory stores a computer program that can be executed by at least one processor to perform some or all of the steps in the OTA simulation test method as described in any of the first aspects.

[0028] Fourthly, this application provides a computer-readable storage medium storing one or more computer programs, which can be executed by one or more processors to implement some or all of the steps in the OTA simulation test method as described in any of the first aspects.

[0029] Fifthly, this application provides a computer program product, including a computer program or instructions, which, when executed by a processor, implement some or all of the steps in the OTA simulation test method as described in any of the first aspects.

[0030] The beneficial technical effects of the embodiments of this application are as follows:

[0031] 1. OTA full-process dynamic simulation: From configuring upgrade packages and task information in the OTA cloud to the completion of vehicle-side controller upgrade, dynamic simulation can be achieved for the interactive messages in each step of each OTA role. It includes FBL flashing controllers and system self-upgrade controllers (single partition, dual partition). The test objects include the entire OTA channel and controller, with a wider coverage.

[0032] 2. Supports unified scheduling of multiple controllers and simulation protocols: Simultaneously supports CAN / CANFD / LIN / ETH (DOIP, SOMEIP, DDS) protocol simulation and parsing for one or more controllers on the vehicle side. The industrial control computer uniformly calls the programmable BOB to resolve signal conflict and message timing issues during simulation. Meets the requirements of most vehicle models on the market;

[0033] 3. Automated test case writing: The industrial control computer uses AI tools to generate test cases with interactive messages based on the requirements specification, communication protocol document, and message conversion algorithm containing signal mapping relationship, which solves the problem of large and complex message data in the OTA process and greatly improves test coverage.

[0034] 4. The simulation test bench is simple and highly adaptable: Whether simulating all controllers or a single controller, it only needs to be set up once, without any subsequent wiring modifications. For different vehicle models, only modifications are needed based on the differences in network topology; there is no need to rebuild the entire system.

[0035] 5. More diverse fault injection scenarios: The industrial control computer uses a programmable BOB to inject hardware faults during the OTA process, resulting in more complete test scenario coverage;

[0036] 6. Diversified logic for judging test results: Based on message data (raw data and parsed data), vehicle interface, OTA major version information and version information of each controller (obtained through interface display and batch read from diagnostic protocol), the judgment of OTA upgrade results is more accurate;

[0037] 7. Complete data preservation during test case execution: All message data and vehicle-mounted intelligent terminal interface data are automatically saved as attachments to the defect report, reducing the operation process for testers and ensuring more complete defect report information. Attached Figure Description

[0038] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with this application and, together with the specification, serve to explain the technical solutions of this application.

[0039] Figure 1 Hardware system architecture of a test environment for an optional OTA simulation test method provided in this application embodiment;

[0040] Figure 2 A schematic diagram of the functional modules included in an optional computer device provided in an embodiment of this application;

[0041] Figure 3 A flowchart illustrating an optional OTA simulation testing method provided in this application embodiment. Figure 1 ;

[0042] Figure 4 An optional structural block diagram for generating target test cases is provided in an embodiment of this application;

[0043] Figure 5 An optional database diagram provided for an embodiment of this application;

[0044] Figure 6 A structural block diagram of an optional communication control module for a computer device provided in an embodiment of this application;

[0045] Figure 7 A schematic diagram of an optional DOIP protocol message structure provided for an embodiment of this application;

[0046] Figure 8 A schematic diagram of an optional DDS protocol message structure provided for an embodiment of this application;

[0047] Figure 9 A schematic diagram of an optional SOME / IP protocol message structure provided for an embodiment of this application;

[0048] Figure 10 A flowchart illustrating an optional OTA simulation testing method provided in this application embodiment. Figure 2 ;

[0049] Figure 11 A schematic diagram of an optional timing flow for sending simulated messages is provided for an embodiment of this application;

[0050] Figure 12 A schematic diagram of an optional OTA simulation testing device provided in an embodiment of this application;

[0051] Figure 13 This is a schematic diagram of the structure of an optional computer device provided in an embodiment of this application. Detailed Implementation

[0052] To make the objectives, technical solutions, and advantages of this application clearer, the technical solutions of this application are further described in detail below with reference to the accompanying drawings and embodiments. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0053] In the following description, references to "some embodiments" refer to a subset of all possible embodiments. It is understood that "some embodiments" may be the same or different subsets of all possible embodiments and may be combined with each other without conflict. The terms "first / second / third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first / second / third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0054] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this application pertains. The terminology used herein is for descriptive purposes only and is not intended to limit the scope of this application.

[0055] Reference Figure 1 , Figure 1 The hardware system architecture of the test environment for an OTA simulation test method provided in this application embodiment includes an OTA cloud 1, a simulation test bench 2, a computer device 3, a programmable control device 4, a CANoe device 5, an image acquisition module 6, and a robotic arm 7.

[0056] The OTA cloud platform is connected to both a computer device and a simulation test bench. Based on user input, the computer device generates target test cases containing preset message data. During the execution of these target test cases, the OTA cloud platform can configure the upgrade task accordingly. Here, the target test cases include at least test cases for any step of the OTA upgrade process where the upgrade target loads the upgrade file from the OTA cloud via the simulation test bench. The target test cases contain preset message data for communication between participating nodes in the simulation test bench, including both preset actual message data and preset simulated message data.

[0057] The simulation test bench 2 includes an in-vehicle intelligent terminal 21, a gateway 22, and multiple controllers 23 supporting OTA upgrades. The simulation test bench is an integrated test environment that connects the in-vehicle intelligent terminal, gateway, and controllers according to the network topology, ensuring normal communication. It should be noted that the connection between the gateway and the controller can be one-to-many. Of course, a gateway can include multiple sub-gateways, and the connection between the sub-gateways and the controller can be one-to-one and / or one-to-many.

[0058] The computer equipment is connected to the programmable controller, CANoe device, image acquisition device, and robotic arm, and can perform normal control. The quantity and placement of these devices (computer, robotic arm, image acquisition device, programmable controller, and CANoe device) can be adjusted according to the network topology of different vehicle models. The controller's power and communication cables are then connected according to the vehicle model's network topology.

[0059] Among them, reference Figure 2 As shown, computer device 3 includes: a communication control module 201, a test case generation module 202, an OTA cloud control module 203, an in-vehicle intelligent terminal control module 204, a power control module 205, and a test result generation module 206.

[0060] Here, the computer equipment can use the OTA cloud control module to automatically configure upgrade task information and create upgrade files associated with the upgrade task information based on the target test cases. The upgrade task information includes the upgrade target and upgrade version. The upgrade task information and upgrade files are sent to the OTA cloud. The OTA cloud then distributes the upgrade task information and upgrade files according to the target test cases. Each controller then loads the OTA upgrade files from the OTA cloud and performs an OTA upgrade via a simulation test bench. It should be noted that the target test cases will contain upgrade task information (such as upgrading a specific controller and its corresponding upgrade package) and include all operations required during the testing process.

[0061] The computer equipment can be an industrial control computer or a host computer. The computer equipment can use a test case generation module to generate test cases containing preset message data by combining software requirements documents, communication protocol documents, and test requirements with artificial intelligence (AI) tools such as TestArchitect and Ranorex, and adjusting them using natural language processing and input instruction templates.

[0062] Here, the power and communication lines of the programmable logic device (also known as a programmable BOB) are connected to the power and communication lines of each controller on the simulation test bench. Specifically, the power lines of each controller in the simulation test bench are connected to the power control channel of the programmable logic device, and the communication lines of each controller (including CAN / CANFD / ETH) are connected to the communication control channel of the programmable logic device. For the ETH protocol connection, the CANOE device has a built-in automotive Ethernet converter. During the OTA upgrade process where each target controller loads upgrade files from the OTA cloud via the simulation test bench, the computer equipment can control the connection status (open circuit, short circuit, also known as the controller's power status) of one or more corresponding controllers' power lines through the power control channel of the programmable logic device, based on the target test cases. Similarly, the communication status (open circuit, short circuit, also known as the controller's communication status) of one or more corresponding controllers' communication lines can be controlled through the communication control channel of the programmable logic device. This allows for the injection of various faults into the power and communication lines, such as open circuits and short circuits.

[0063] Here, each CANoe device is connected to the communication network of the simulation test bench. The computer can use the communication control module to send simulated message data to the target participating node corresponding to the controller that is in a disconnected state via the CANoe device. The communication control module also uses the CANoe device to capture actual message data from the simulation test bench's communication network for parsing and saving. It should be noted that when the computer sends simulated message data via the CANoe device, it needs to coordinate with the programmable controller to control the communication status of the communication line of the controller corresponding to the simulated message data to ensure no signal conflict between the actual and simulated message data. Furthermore, the CANoe device can define the network topology and node communication architecture in the simulation test bench, providing a virtual network environment for the development and testing of each node in the simulation test bench. This node communication architecture includes the communication protocols of each participating node (also known as the participating object) in the simulation test bench.

[0064] Here, the robotic arm and image acquisition device are positioned directly above the vehicle-mounted intelligent terminal on the simulation test bench. The image acquisition device is used to capture images of the display interface of the vehicle-mounted intelligent terminal. The computer equipment can control the image acquisition device to capture images of the display interface of the vehicle-mounted intelligent terminal in real time through the vehicle-mounted intelligent terminal control module and perform interface recognition. When a touch operation is detected that the display interface needs to be touched, the interface coordinates of the corresponding operation control are determined. The computer equipment can control the robotic arm to simulate the touch operation based on the interface coordinates through the vehicle-mounted intelligent terminal control module. This is used to execute the OTA process download and installation steps, as well as the OTA upgrade result image judgment. The touch operation includes, but is not limited to, clicking, double-clicking, swiping, long-pressing, and two-finger and multi-finger operations. It should be noted that the image acquisition device can be an industrial camera. Here, the technical approach for the computer equipment to access the industrial camera is Python + device SDK + OpenCV + NumPy. Specifically, the computer equipment uses a Python program to call the Software Development Kit (SDK) to acquire images of the intelligent vehicle terminal captured by the industrial camera. It then uses the OpenCV and NumPy libraries in conjunction with Python to analyze and annotate the intelligent vehicle terminal images. For example, by combining Python with the OpenCV and NumPy libraries to analyze the intelligent vehicle terminal images, it calculates the interface coordinates, thereby completing the recognition of the intelligent vehicle terminal images. Similarly, the technical approach for accessing the robotic arm is Python + device SDK. Specifically, the computer equipment uses a Python program to call the device SDK based on the interface coordinates to control the robotic arm to simulate touch operations.

[0065] Here, the computer equipment can also use the test result generation module to obtain the upgrade result based on the actual message data, simulated message data, and preset message data after the target test cases have been executed, and generate a test report based on the upgrade result.

[0066] The technical solutions in the embodiments of this application will now be clearly and completely described with reference to the accompanying drawings.

[0067] Reference Figure 3 As shown in the embodiment of this application, an optional OTA simulation testing method is provided, applied to... Figure 1 The method may include the following steps:

[0068] Step 301: In response to the input operation, generate target test cases containing preset message data.

[0069] The target test cases include at least any process of the upgrade object loading the upgrade file from the OTA cloud through the simulation test bench to perform an OTA upgrade. The target test cases include preset message data when the participating nodes in the simulation test bench communicate with each other. The preset message data includes preset actual message data and preset simulation message data.

[0070] In this embodiment, the input operation can be an instruction submitted by the tester or the automated system to the computer device, which can be triggered through the computer device's graphical interface (such as a test case editor) or code (script call) to specify preset parameters such as test target, scenario parameters, upgrade object, upgrade file, and upgrade version number.

[0071] In this embodiment of the application, the target test case may be an execution unit containing complete test logic, used to verify the correctness of the function of a specific environment in the OTA upgrade process. For example, the target test case may include at least any process in which the upgrade object loads the upgrade file from the OTA cloud through the simulation test bench to perform an OTA upgrade. The upgrade object may be the target controller in the simulation test bench.

[0072] In this embodiment, the OTA cloud refers to a server cluster deployed with OTA services, responsible for managing upgrade files, upgrade policies, and communication with vehicle-side devices. The OTA cloud not only supports HTTPS for secure transmission of upgrade files but also provides lightweight protocols such as MQTT for real-time communication and status reporting.

[0073] Understandably, computer devices can invoke test case generation modules. Based on AI tools and software requirements documents, communication protocol documents, and message conversion algorithms containing signal mapping relationships, they can automatically generate test cases containing interactive message data (i.e., preset message data). The signal mapping relationship can be between signals in the vehicle and binary signals. For example, a test case involving a CAN bus upgrade might include: the CANID, frame data, Cyclic Redundancy Check (CRC) code, etc., when the upgrade task is issued, as well as the communication timing between the controller and the gateway during the upgrade process.

[0074] In this embodiment, the preset message data includes: preset actual message data and preset simulated message data. The preset actual message data can be messages generated by the actual controller during normal communication, while the preset simulated message data can be simulated messages sent by the CANoe device to simulate the behavior of the target controller in a disconnected state. For example, when testing the upgrade process of a Body Control Module (BCM), i.e., the target controller, if the target controller is disconnected, the computer device can use the CANoe device to simulate its communication behavior according to the preset simulated message data in the target test case, ensuring that other participating nodes communicating with the target controller can still receive the expected message signals.

[0075] In this way, based on the preset parameters input by the user, target test cases containing preset message data are generated, enabling the test system to cover key communication scenarios in the OTA upgrade process, thereby improving the comprehensiveness and accuracy of the test.

[0076] Step 302: Execute the target test case. During the execution of the target test case, respond to the test task sent by the OTA cloud for the simulation test bench, configure the upgrade task information, and create the upgrade file associated with the upgrade task information, and upload it to the OTA cloud.

[0077] The upgrade task information includes the upgrade target and the upgrade version. The upgrade target includes at least one target controller in the simulation test bench.

[0078] In this embodiment, the test task can be a specific test target instruction issued by the OTA cloud for the simulation test bench, including the test scope, process requirements, and expected results. For example, "verify the stability of OTA upgrades of the gateway under network congestion scenarios" or "test the upgrade fault tolerance of the power system controller under low power conditions". Each test task can be broken down into multiple test cases for execution.

[0079] In this embodiment of the application, after the target test case starts to be executed, the computer device obtains the test task from the OTA cloud, thereby ensuring that the test cases used by the test platform are consistent with the real OTA process and providing accurate task basis for subsequent simulation tests.

[0080] In this embodiment, the upgrade task information typically includes the upgrade target and the corresponding upgrade version. The computer device calls the OTA cloud control module to configure the upgrade task information, and then uses automated tools to generate an upgrade file that meets the requirements of the target controller and / or the in-vehicle intelligent terminal. The upgrade file can be a Flash Bootloader (FBL) flash file or a system self-upgrade package; the format depends on the type of target controller and the communication protocol. For example, a target controller on a CAN bus typically uses a CANoe device with a message conversion algorithm to parse upgrade commands, while an Ethernet target controller may use a Diagnostic Over Internet Protocol (DOIP) or a Scalable Service-Oriented Middleware over IP (SOME / IP) protocol to send upgrade data.

[0081] In this embodiment, after the computer device creates the upgrade file, it uploads the upgrade task information and the upgrade file to the OTA cloud via an HTTP / HTTPS interface, simulating the upgrade file distribution process in a real OTA environment. After successful upload, the OTA cloud records the detailed information of the upgrade task and prepares to trigger the upgrade action during subsequent testing.

[0082] In this way, by configuring upgrade task information and creating upgrade files, it is ensured that the upgrade files used in the test environment are consistent with those in the actual production environment, thereby improving the authenticity and effectiveness of the testing process.

[0083] Step 303: During the OTA upgrade process where each target controller loads the upgrade file from the OTA cloud through the simulation test bench, simulation message data corresponding to multiple communication protocols are generated according to the target test cases.

[0084] Among them, the simulation message data is the message data sent by the target controller in the simulated disconnected state to other participating nodes in the simulation test bench. The communication protocols used for the message data when different controllers communicate with other participating nodes may be the same or different.

[0085] In this embodiment, during the OTA upgrade process where each target controller loads upgrade files from the OTA cloud via a simulation test bench, the computer device disconnects the communication line of the target controller via a programmable device, and then uses a CANoe device to generate simulation message data according to the communication protocol set in the target test case. For example, if the target controller originally uses the CAN protocol for communication, the computer device will generate simulation message data according to the preset CAN ID and frame structure, and send it to other participating nodes using the CANoe device to simulate the communication behavior of the target controller while it is still in operation.

[0086] It should be noted that since different target controllers may use different communication protocols (such as CAN, LIN, ETH, DOIP, etc.), the CANoe device will generate corresponding simulation messages according to the communication protocol of each target controller. For example, when testing target controllers using both CAN and ETH protocols simultaneously, CANoe will run two channels at the same time to handle the generation and transmission of simulation messages for these two protocols respectively.

[0087] In this way, by generating simulated message data of multiple communication protocols, the problem of signal conflict in a multi-protocol environment can be effectively solved, and the stability and reliability of the test can be improved.

[0088] Step 304: Based on the target test cases, control the power status and / or communication status of each controller through the programmable control device, and send each simulated message data to the target participating node corresponding to the target controller in the disconnected state through the CANoe device for parsing and identification.

[0089] In this embodiment, the programmable device is used to control the status of the power lines and communication lines of each controller. For example, when testing a power-on / off fault injection scenario of a target controller, the computer device can use the power control module and the programmable device to disconnect the power line of the target controller according to the instructions in the target test case, simulating a power failure. Similarly, for the communication line, the programmable device can disconnect the communication link of the target controller at a specific time to avoid conflicts between the actual controller and the simulation messages.

[0090] In this embodiment of the application, the computer device can generate simulation message data according to the communication protocol and message content set in the target test case through the communication control module, and use the CANoe device to send the simulation message data to the target participating node that is communicating with the target controller in the disconnected state, so as to ensure that the simulation message data can be received and parsed by the target participating node.

[0091] In this way, through the coordinated control of the programmable control equipment and the CANoe equipment, the system achieves accurate simulation of the power supply and communication status of the target controller. The coordinated control method enhances the diversity and realism of the test scenarios.

[0092] Step 305: Based on the target test case, capture the actual message data when communicating with the controller in the connected state using the CANoe device.

[0093] In this embodiment, the CANoe device is used not only to send simulated message data but also to capture actual message data generated by the actual controller under normal communication conditions. For example, when testing the upgrade process of a BCM target controller, the computer device can use the CANoe device to capture the communication messages between it and the gateway in real time and save them as raw data for subsequent analysis. The captured message data includes information such as frame ID, data fields, and timestamps, which can be used to verify whether the target controller has performed the upgrade operation as expected.

[0094] It should be noted that the computer equipment can convert the captured raw message data into structured data through the communication control module. The testing system can then compare the converted structured data with the preset messages in the target test cases.

[0095] In this way, the computer equipment captures the communication message data of the actual controller through the CANoe device, and the system can monitor the communication behavior in real time during the upgrade process, providing a reliable basis for judging the target test results.

[0096] Step 306: After the target test cases have been executed, the upgrade results are obtained based on the actual message data, simulated message data, and preset message data. A test report is then generated based on the upgrade results.

[0097] In this embodiment, the computer device can automatically compare actual message data, simulated message data, and preset message data in the target test case using the test result generation module to determine if there is any deviation. For example, if a target controller does not receive the expected upgrade file confirmation message during the upgrade process, the upgrade is considered to have failed. Simultaneously, the test result generation module can also use an industrial camera to identify the interface display content of the vehicle-mounted intelligent terminal to determine whether the upgrade was successful.

[0098] In this embodiment, the computer device can also compile the test results into a test report. The test report includes preset message data from the target test cases, version information of all controllers and / or in-vehicle intelligent terminals before and after the upgrade, message interaction data, screenshots of the vehicle interface, etc. The version information includes: software part number, software version, BOOT version, hardware part number, hardware version information, and major version information before and after the vehicle upgrade. The test report can also be uploaded to the test cloud for unified viewing and management by the test team.

[0099] In this way, by comprehensively analyzing actual and simulated message data, testers can accurately evaluate the OTA upgrade results and further improve the credibility and traceability of the test results.

[0100] This application provides an OTA simulation testing method that automatically generates target test cases containing preset message data in response to input operations. These target test cases, generated based on input operations, can adapt to different upgrade scenarios (such as single-controller upgrades and multi-controller concurrent upgrades), reducing manual configuration time. During the execution of the target test cases, the computer device automatically configures upgrade task information, creates and uploads upgrade files based on the test tasks sent by the OTA cloud, reducing manual operation time and error rates, making the testing process more efficient. During the OTA upgrade process where the target controller loads the upgrade file from the OTA cloud through the simulation test bench, the process is controlled by a programmable control device. The system simulates extreme scenarios such as network interruption and controller failure in a real vehicle (e.g., momentary network outage during high-speed driving) by sending simulated messages via CANoe after the device power / communication is disconnected, thus verifying the anti-interference capability of the upgrade process. It supports mixed transmission of simulated messages from multiple communication protocols, covering heterogeneous in-vehicle network environments and ensuring the integrity of upgrade data during cross-protocol communication. Test reports generated based on actual message data, simulated message data, and preset message data provide detailed data support for subsequent problem analysis and system optimization, helping to quickly locate the cause of problems and take corresponding measures. The automated testing process reduces reliance on expensive testing equipment and lowers labor costs, resulting in an overall reduction in testing costs.

[0101] In some embodiments, step 301, in response to an input operation, generates a target test case containing preset message data, which can be achieved through the following steps.

[0102] Step 311: In response to the input operation, obtain the software requirements specification of the participating nodes in the simulation test bench and the communication protocol document for communication between different types of participating nodes.

[0103] In this embodiment, the simulation test bench refers to a hardware and software integrated environment used to simulate the interaction behavior of various roles (such as in-vehicle intelligent terminals, gateways, controllers, etc.) during the vehicle OTA upgrade process. Its purpose is to construct a repeatable and controllable test platform without relying on a real vehicle to verify the integrity and stability of the OTA process. In this embodiment, the simulation test bench consists of computer equipment, programmable control equipment, CANoe equipment, a robotic arm, industrial cameras, etc., and can simulate the communication behavior between the OTA cloud and the vehicle, supporting the collaborative operation of multiple protocols (such as CAN, LIN, ETH).

[0104] In this embodiment, the functional modules or devices involved in the communication or control process refer to the various functional modules or devices that actually participate in the communication or control process during the OTA upgrade process, such as in-vehicle intelligent terminals, gateways, and controllers (Electronic Control Units, ECUs). These nodes typically have a clear location in the vehicle network topology and exchange data through different communication protocols.

[0105] In this embodiment, the software requirements specification is a detailed development requirements document written for a specific functional module or device, used to guide software design, development, and testing. The software requirements specification is used to extract key parameters, input / output definitions, boundary conditions, and other information from the test scenario, providing a basis for test case generation. For example, refer to... Figure 4 As shown, the software requirements specification includes Firmware Over-The-Air (FOTA) 401 and Gateway Software Requirements Specification 402.

[0106] In this embodiment of the application, the communication protocol document is a technical document describing the communication rules between two or more functional modules or devices, including message format, signal definition, transmission rate, error handling mechanism, etc. For example, continue to refer to... Figure 4 The communication protocol documents include: communication protocol document 403 for communication between the OTA cloud and the vehicle, communication protocol document 404 for communication between the in-vehicle intelligent terminal and the gateway, and communication protocol stability document 405 for communication between the gateway and the controller. For example, the gateway and controller may include a CAN protocol document, which specifies the frame ID, signal length, checksum, etc.; the Diagnostic Over Internet Protocol (DOIP) document describes the structure of diagnostic requests and responses.

[0107] Step 312: Based on the software requirements specification, communication protocol document, and message conversion algorithm containing signal mapping relationships, combined with test requirements, preset test case templates, and the number of test cases, use an artificial intelligence model to generate initial test cases containing preset message data.

[0108] In this embodiment, the artificial intelligence model is an AI model based on natural language processing and deep learning technologies, possessing powerful text understanding and generation capabilities. In this embodiment, the model is used to parse unstructured or semi-structured data such as software requirements and communication protocols, and automatically generates compliant test cases based on message conversion algorithms containing signal mapping relationships, test requirements, preset test case templates, and the number of test cases. This model can identify key information in documents and transform it into structured test steps and expected results.

[0109] In this embodiment, the preset message data refers to the communication data content pre-set in the test cases, which typically includes fields such as sender, receiver, communication protocol type, message ID, signal value, and timestamp. The preset message data is used to simulate the interaction behavior between various functional modules or devices in the OTA process, ensuring the authenticity and effectiveness of the testing process.

[0110] In this application embodiment, test requirements are the explicit requirements of the user or project team regarding the test scope, objectives, standards, etc., typically including test purpose, test scenario, test conditions, expected results, etc. In this invention, test requirements are used to guide the direction and focus of the AI ​​model in generating test cases.

[0111] In this embodiment, the test case template is a standardized framework of test steps used to unify the structure and format of test cases. Each template typically includes a test name, preconditions, operation steps, expected results, etc.

[0112] In this embodiment of the application, the number of test cases refers to the total number of test cases that need to be generated in this test task. The number of test cases is used to control the test coverage and ensure that test resources are allocated reasonably.

[0113] In one feasible approach, refer to Figure 4 As shown, the computer device, through the test case generation module 202, can generate test cases containing rich communication data by inputting the aforementioned input information into the artificial intelligence model. This significantly improves the efficiency and accuracy of test case generation, ensuring comprehensive coverage of test scenarios and ultimately enhancing overall test quality.

[0114] Step 313: In response to the verification operation of the initial test cases, select target test cases that meet the test case verification conditions from the initial test cases.

[0115] As can be understood, the re-verification operation refers to the process of manually or automatically reviewing test cases after they have been generated. The purpose of this operation is to eliminate invalid, duplicate, or non-compliant test cases, ensuring the quality and usability of the final test case set.

[0116] In this embodiment, the test case verification criteria are used to determine whether a test case can pass verification. These criteria typically include factors such as logical rationality, data consistency, scenario coverage, and executability. The verification criteria can be dynamically adjusted according to testing requirements to adapt to the needs of different testing scenarios.

[0117] In this embodiment, the target test case refers to the test case that meets all the re-verification conditions and is retained after the re-verification operation. These test cases will be used in the subsequent test execution phase as an important basis for evaluating the system's functionality and performance.

[0118] In one feasible approach, continue to refer to Figure 4 After generating initial test cases 407 containing preset message data, the introduction of manual review 408 and test case review conditions (test case review 409) effectively filters out low-quality or invalid test cases from the initial test cases 407, resulting in target test cases containing preset message data. This ensures that the final executed test case set is more accurate and efficient. This avoids test failures or misjudgments caused by test case quality issues, thereby improving test stability and reliability, and ultimately enhancing overall test efficiency and result credibility.

[0119] In some embodiments, generating simulation message data corresponding to multiple communication protocols in step 303 based on the target test case can be achieved through the following steps.

[0120] Step 331: Obtain the test signals corresponding to each target controller in the disconnected state in the simulation test bench of the target test case; wherein, the test signals include temperature signal, vehicle speed signal and gear signal.

[0121] In this embodiment, the test signal refers to the input parameters used to simulate the vehicle's operating state during the simulation test. These parameters typically originate from the expected behavior definition of the vehicle control system in the test cases. The test signal reflects the vehicle's operating state under different conditions, such as engine temperature, speed, and gear shift position. In this embodiment, the test signal serves as the fundamental input to the simulation process, providing a basis for the subsequent generation of simulation message data.

[0122] In practice, when a controller is disconnected, the system extracts the corresponding test signals based on the test cases and uses these signals as input conditions in the simulation environment. For example, when testing CAN bus communication, the system reads the temperature signal value, vehicle speed signal value, and gear position signal status defined in the current test case to ensure that the simulation environment can accurately reproduce the communication requirements in real-world scenarios.

[0123] Step 332: For each test signal, use the signal mapping relationship to map the test signal to a binary signal. The signal mapping relationship includes the mapping relationship between the test signal and the binary signal. The binary signal includes the binary signal value and the binary signal bit position.

[0124] In this embodiment, the signal mapping relationship is a predefined data conversion rule used to convert test signals (typically decimal values ​​or enumeration types) into the binary format used in the communication protocol. This mapping relationship can be established based on a database table to ensure the correct representation of different test signals on the communication bus.

[0125] In this embodiment, the binary signal value refers to the specific numerical value of the test signal in binary form, while the binary signal bit position refers to the bit position occupied by that value in the communication message. For example, a temperature signal may be mapped to an 8-bit binary number with a value range of 0 to 255, corresponding to different temperature ranges. In this way, the system can convert complex test signals into binary data formats supported by the communication protocol, facilitating the subsequent generation of simulation message data that conforms to the protocol specifications.

[0126] In practical applications, the system processes each test signal individually, converting it into a binary signal according to a preset signal mapping relationship. For example, if a test signal is a gear position signal, the system will convert it into the corresponding binary signal code according to the gear position signal definition (such as Parking P / Reverse R / Neutral N / Drive D, etc.) and determine its specific bit width and position in the communication message.

[0127] For example, refer to Figure 5 As shown, the signal mapping relationship can be as follows: Figure 5The database table shown includes a main database (Table 1 on the left) and multiple sub-databases (Table 2 on the right). The main database includes the signal name (Sig_Name), the start bit (Start_Bit), signal length (Sig_Legth), and influence factor (Factor) of each test signal in binary. It should be noted that since some signals contain decimals, such as temperature and vehicle speed, dividing signals with decimals by the influence factor yields the binary signal data. The sub-databases contain the specific value information for each test signal, including: the signal name (Sig_Name), the value name (Value_Name), and the binary signal value (Sig_Value). The binary signal value can be its position within the corresponding signal length. Based on the start bit, signal length, signal value, and influence factor, the actual binary data is obtained using the first formula: Binary Data = Start Bit + Signal Length - (Signal Value / Influence Factor). For example, taking the external input condition as the signal gear and the value name as D gear, we can find the signal value as 1 in Table 2, which is the first binary bit of the actual gear range. Looking up the gear data in Table 1, we find the starting bit as 45, the length as 3, and the influence factor as 1. We know that the binary data of the gear signal D gear occupies the 45th, 46th, and 47th bits. Based on the first formula above, we can get the binary data as 44 + 3 - 1 = 46, which is the 46th bit.

[0128] Step 333: Based on the binary signal value and the binary signal bit position, generate the message bit mask corresponding to the communication protocol to obtain the simulated message data.

[0129] In this embodiment, a message bitmask is a binary structure used to identify valid data bits in a communication message. The message determines which bits will be set to 1 or 0 to form a message format conforming to a specific communication protocol. In this application, the system dynamically generates a message bitmask matching the target communication protocol based on binary signal values ​​and binary signal bit positions, thereby constructing complete simulated message data.

[0130] In summary, in this embodiment, by acquiring the test signal and mapping it to a binary signal, and then generating a message bitmask corresponding to the target communication protocol based on the binary signal, simulated message data conforming to the communication protocol is generated. This allows for accurate simulation of the target controller in a disconnected state, thereby avoiding signal conflicts between the actual controller and the simulated message data, and ultimately improving the accuracy and reliability of OTA communication simulation testing.

[0131] In some embodiments, generating the message bitmask corresponding to the communication protocol based on the binary signal value and the binary signal bit position in step 333 can be achieved through the following steps.

[0132] Step 3331: Based on the binary signal value and the binary signal bit position, obtain the message bit mask of the first binary bit using a mathematical model; wherein, the mathematical model is shown in formula (1) or formula (2) below.

[0133]

[0134] Where M(S) is the binary message bitmask, and S is the set of binary signal bit positions, S = {p1, p2, ..., p...} N-1 ,p N ,},p n For binary signal bit positions, 0≤p n ≤N, where N is 511 or 63.

[0135] In this embodiment, formula (1) can be a core mathematical model, a calculation method based on combinatorial mathematics, used to map multiple specified binary signal bits to a unified binary number expression. The core mathematical model constructs a message bitmask by accumulating powers of 2, ensuring that each selected binary signal bit corresponds to a unique 1 in the final result, and the value at the corresponding position of the unselected binary signal bit is 0. For example, in a 512-bit CAN message, if the binary signal values ​​at the 3rd, 100th, 200th, 300th, and 500th binary positions are to be set to 1, and the binary signal values ​​at the remaining binary positions are to be 0, the corresponding message bitmask can be quickly generated using the core mathematical model.

[0136] In this embodiment, formula (2) can be a polynomial mathematical model, which is a way to extend the calculation of binary signal bits. By representing each binary signal bit position as an exponent and substituting the base e=2, a binary bit mask corresponding to the original signal can be generated. This polynomial mathematical model constructs the mask through a product form, ensuring that signals at different positions do not interfere with each other and enabling independent processing of multiple sets of signals. For example, in the CAN communication protocol, if multiple signals in a frame are located on different binary bits, this polynomial mathematical model can calculate the masks corresponding to these signals separately, which is convenient for subsequent message assembly and verification.

[0137] In this embodiment, both the polynomial mathematical model and the core mathematical model can generate binary masks. The core mathematical model directly generates the binary bitmask, while the polynomial mathematical model serves as an auxiliary verification method, transforming the same signal set through different expressions, thereby improving the robustness and accuracy of the mask generation process. This dual-model approach helps reduce system misjudgments caused by errors in a single model, improving the reliability of communication simulation testing.

[0138] In this embodiment, the binary signal bit position set S is a set of discrete integers representing which bits are activated or need to participate in operations in the message. The element p in the set... n This represents the position index of a specific bit, and each position index must be unique (i.e., p). i ≠p j This set determines which bits in the final message bitmask are set to 1, and the values ​​at the positions corresponding to unselected binary signal bits are 0. For example, for a 512-bit CAN message, S can be {3, 100, 200, 300, 500}, meaning that the binary signal values ​​at these five positions will be processed separately and reflected in the message bitmask.

[0139] In one feasible scenario, the communication control module of a computer device can determine its specific position in a communication message based on the binary signal value and the position of the binary signal bit. For example, in a 512-bit CAN message, the binary signal values ​​of bits 3, 100, 200, 300, and 500 are 1, while the binary signal values ​​of the remaining bits are 0. Next, according to the requirements of the communication protocol, the computer device, based on the binary signal value and the binary signal bit, uses the core data model corresponding to the above formula (1) to obtain the message bitmask for the first binary bit, such as obtaining M=2. 3 +2 100 +2 200 +2 300 +2 500 .

[0140] In another feasible scenario, the communication control module of the computer device can determine its specific position in the communication message based on the binary signal value and binary signal bit. For example, in a 512-bit CAN message, the binary signal values ​​of bits 3, 100, 200, 300, and 500 are 1, while the binary signal values ​​of the remaining bits are 0. Next, according to the requirements of the communication protocol, the computer device, based on the binary signal value and binary signal bit, uses the polynomial mathematical model corresponding to the above formula (2) to obtain the message bitmask for the first binary bit, such as obtaining M = (1 + x 3 (1+x) 100 (1+x)200 (1+x) 300 (1+x) 500 )| x＝2 Furthermore, expanding the polynomial, we get M = 1 + x 3 +x 100 +x 200 +x 300 +x 500 Substituting x = 2 and eliminating positional conflicts, we can obtain the binary message bitmask M = 2. 3 +2 100 +2 200 +2 300 +2 500 .

[0141] Step 3332: Convert the message bitmask of the first binary bit into the message bitmask of the first hexadecimal bit to obtain the message bitmask corresponding to the communication protocol.

[0142] In this embodiment, the hexadecimal message bitmask is a hexadecimal representation of the binary mask compressed into groups of four bits. Since computer systems typically use hexadecimal data for transmission and parsing, converting the binary mask to hexadecimal facilitates compatibility with existing target communication protocols and simplifies subsequent processing.

[0143] In this embodiment of the application, the computer device determines the byte to which each bit in the message bitmask of the first binary bit belongs. It should be noted that a byte is an 8-bit binary number. Let the 8-bit binary number B = b7b6b5b4b3b2b1b0, where b... i ∈{0,1}, each byte is divided into high-order bits (4-7) and low-order bits (0-3). When determining the byte to which each bit belongs in the message bitmask of the first binary bit, for example, for 2 3 For bit 3, 3 / 8 = 0…3, the quotient 0 can be used as the 0th byte. Based on the remainder 3, the 3rd bit of the 8-bit binary number is set to 1, that is, the high bit is 0000, which is used as the low bit 0100. Converting 00000100 to hexadecimal gives 08; for bit 2… 100 For bit 100, 100 / 8 = 12…4, so the quotient 12 can be used as the 12th byte. Based on the remainder 4, the 4th bit of the 8-bit binary number is set to 1, that is, the high bit is 0001 and the low bit is 0000. Converting 00010000 to hexadecimal gives 10; for 2… 200 For bit 200, 200 / 8 = 25…0, so the quotient 25 can be taken as the 25th byte. Based on the remainder 0, the 0th bit of the 8-bit binary number is set to 1, that is, the high bit is 0000 and the low bit is 0001. Converting 00000001 to hexadecimal gives 01; for 2… 300For bit 300, 300 / 8 = 37…4, so the quotient 37 can be taken as the 37th byte. Based on the remainder 4, the 4th bit of the 8-bit binary number is set to 1, that is, the high bit is 0001 and the low bit is 0000. Converting 00010000 to hexadecimal gives 10; for 2… 500 For bit 300, 500 / 8 = 62…4. The quotient 62 can be used as the 62nd byte. Based on the remainder 4, the 4th bit of the 8-bit binary number is set to 1, i.e., the high bit is 0001 and the low bit is 0000. Converting 00010000 to hexadecimal gives 10. Integrating these hexadecimal numbers yields the first hexadecimal message bitmask. This yields the message bitmask corresponding to the communication protocol, where the first hexadecimal message bitmask is shown below. 08 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00 00

[0152] As described above, in this embodiment, by introducing a core mathematical model, a binary bitmask conforming to the communication protocol can be efficiently generated and further converted into hexadecimal format. This reduces the workload of manual configuration, improves the accuracy and consistency of bitmask generation, thereby accelerating the communication simulation process and better supporting the collaborative testing needs of multiple protocols and controllers during vehicle OTA upgrades.

[0153] In some embodiments, after step 3332 converts the message bitmask of the first binary bit into the message bitmask of the first hexadecimal bit, and obtains the message bitmask corresponding to the communication protocol, the following steps may also be performed.

[0154] Step 3333: Treat the message bit mask of the first binary bit as a discrete signal, and transform it using the Discrete Fourier Transform (DFT) model to obtain the first binary frequency domain sequence; wherein, the DFT model is,

[0155]

[0156] Where M[k] is a binary frequency domain sequence, representing the complex amplitude (including amplitude and phase information) of the signal at frequency k / N, M(S) is a binary message bit mask, kn is a time-frequency coupling term, controlling the phase accumulation rate of the complex exponential rotation factor, used to detect the periodic pattern of the mask, k is the discrete frequency index, and p n This refers to the position of a binary signal bit with a value of 1.

[0157] In this embodiment of the application, the message bit mask of the first binary bit is used as a discrete signal and transformed using the Discrete Fourier Transform (DFT) model to obtain the first binary frequency domain sequence. The first binary frequency domain sequence is then used to detect whether the data has errors during transmission.

[0158] In this way, after converting the binary bit mask into a frequency domain complex vector, structural errors that traditional verification cannot identify can be captured by the amplitude distribution of each frequency domain component (such as the degree of energy concentration at a specific frequency). For example, when a CAN bus message has periodic bit flips, the frequency domain energy will have abnormal peaks at the corresponding frequency points, and linear verification such as CRC is difficult to locate such regular errors.

[0159] Step 3334: Determine the first binary frequency domain energy checksum based on the amplitude at each frequency domain position in the first binary frequency domain sequence.

[0160] In this embodiment of the application, the binary frequency domain energy checksum can be determined by the following formula (4).

[0161]

[0162] Where S is the binary frequency domain energy checksum, |X(k)| is the amplitude of the binary frequency domain sequence X(k), and |X(k)| 2 This represents the energy of the frequency component, and b is the set parity bit length.

[0163] In this embodiment of the application, the first binary frequency domain energy checksum is determined based on the amplitude of each frequency domain position in the first binary frequency domain sequence using the above formula (4).

[0164] In practical applications, the message bitmask of the first binary bit is binary data. The relationship between frequency domain energy and binary data can be described as follows: any binary signal value of 1 in the binary data can be considered as an "energy point" in the signal. After the DFT transformation, this energy will be distributed across different frequencies, forming a frequency domain energy distribution. For example, for the binary sequence 1010, after the DFT transformation, there will be energy (amplitude) at certain specific frequencies, while the energy at other frequencies will be 0. If this sequence becomes 0010 during transmission, the number of 1s decreases, and the frequency domain energy distribution will change. Therefore, according to Parseval's theorem, the energy of the time-domain signal is equal to the energy of the frequency-domain signal, i.e., ... Since x(n) in a binary sequence (i.e., binary data) is either 0 or 1, the time-domain energy is the number of 1s in the sequence.

[0165] For example, if the binary data 1010 is subjected to a DFT of N=4 to obtain a binary frequency domain sequence X=[X0,X1,X2,X3], then using the above formula (4), |X0| can be calculated. 2 +∣X1∣ 2 +∣X2∣ 2 +∣X3∣ 2 Then take the modulus 2 of the result. b The binary frequency domain energy checksum S is obtained.

[0166] Step 3335: Determine the first hexadecimal numerical checksum based on the valid values ​​in the first hexadecimal message bitmask.

[0167] In this embodiment, the message bitmask of the first binary bit is converted into a message bitmask of the first hexadecimal value. Then, based on the valid values ​​in the first hexadecimal message bitmask, the first hexadecimal numerical checksum can be obtained by the following formula (5).

[0168]

[0169] Where H is the hexadecimal checksum, h q Let h be any number in h.

[0170] For example, for the binary message bitmask 10101100, convert it to the hexadecimal message bitmask AC, and use the above formula (5) to obtain the hexadecimal checksum H = 10 + 12 = 22.

[0171] Step 3336: Based on the first binary frequency domain energy checksum and the first hexadecimal numerical checksum, perform logical operations and modulo operations to obtain the first checksum of the message bitmask corresponding to the communication protocol. The simulated message data carries the first check parameters, which are used by the target participating nodes to verify the received simulated message data. The first check parameters include: the first checksum, the first binary frequency domain energy checksum, and the first hexadecimal numerical checksum.

[0172] In the embodiments of this application, logical operations include, but are not limited to, one or more of the following: AND operation, OR operation, XOR operation, and NOT operation.

[0173] In this embodiment of the application, the first binary frequency domain energy checksum and the first hexadecimal numerical checksum are logically operated on and then modulo operation is performed, or modulo operation is performed and then logical operation is performed, so as to obtain the first check code.

[0174] In one possible implementation, the first check code is obtained based on the first binary frequency domain energy checksum and the first hexadecimal numerical checksum by the following formula (6).

[0175]

[0176] Where C is the check code, S is the binary frequency domain energy checksum, H is the hexadecimal numerical checksum, and b is the set check bit length.

[0177] Thus, by using binary frequency domain energy checksum, abnormalities in the overall structure of the mask can be detected. By using hexadecimal numerical checksum, the legality of the mask content (such as forced bit values ​​at specific positions) can be verified. By fusing the two checksum results through logical operations and modulo operations, a first checksum is obtained. The first checksum, the first binary frequency domain energy checksum, and the first hexadecimal numerical checksum are used as the first check parameter. The first check parameter is carried in the simulated message data, so that the target participating node can verify the hexadecimal message bitmask in the received simulated message data after receiving it, thereby determining whether errors have occurred in the hexadecimal message bitmask during data conversion and / or transmission. Compared with traditional checksum methods, this method can detect data errors more comprehensively and accurately.

[0178] In some embodiments, after sending each emulation message data to the target participating node corresponding to the controller in a disconnected state via the CANoe device, the method further includes:

[0179] In response to the retransmission command sent by the target participating node, the simulation message data corresponding to the target participating node is retransmitted to the target participating node through the CANoe device based on the retransmission command; wherein, the retransmission command is determined based on the first verification parameter.

[0180] In this embodiment, the computer device monitors the instructions of the target participating node in real time. When it receives a retransmission instruction from the target participating node, it triggers a data retransmission process. It should be noted that the retransmission instruction is not sent randomly. Instead, the target participating node verifies the simulated message data based on the first checksum, binary frequency domain energy checksum, and hexadecimal numerical checksum in the first verification parameters. If the verification fails (e.g., message loss or data tampering), it actively requests retransmission. Thus, the retransmission mechanism based on verification parameters can automatically identify and correct message errors caused by network interference, packet loss, or conversion, ensuring that the data received by the target participating node is completely consistent with the sender, and avoiding functional abnormalities caused by data loss.

[0181] In some embodiments, the process of determining the retransmission instruction includes:

[0182] Step A1: The target participating node receives the simulation message data; wherein, the simulation message data includes a message bitmask in hexadecimal and a first check parameter;

[0183] Step A2: Determine the hexadecimal checksum based on the valid values ​​in the hexadecimal message bitmask;

[0184] Step A3: Convert the hexadecimal message bitmask to obtain the binary message bitmask.

[0185] Step A4: Treat the message bit mask of the second binary bit as a discrete signal, and transform it using the discrete Fourier transform model to obtain the second binary frequency domain sequence.

[0186] Step A5: Determine the second binary frequency domain energy checksum based on the amplitude at each frequency domain position in the second binary frequency domain sequence;

[0187] Step A6: Based on the second binary frequency domain energy checksum and the second hexadecimal numerical checksum, perform logical operations and modulo operations to obtain the second check code of the message bit mask corresponding to the communication protocol.

[0188] In this embodiment, after receiving the simulated message data, the target participating node first obtains the hexadecimal numerical checksum based on the valid values ​​in the hexadecimal message bitmask of the simulated message data using the above formula (5). Then, the hexadecimal message bitmask is converted to obtain the second binary message bitmask, and the second binary message bitmask is used as a discrete signal to obtain the second binary frequency domain sequence using the above formula (3). Further, based on the amplitude of each frequency domain position in the second binary frequency domain sequence, the second binary frequency domain energy checksum is determined using the above formula (4). Finally, based on the second binary frequency domain energy checksum and the hexadecimal numerical checksum, the second check code of the message bitmask corresponding to the communication protocol is obtained using the above formula (6).

[0189] Step A7: If the first check parameter and the second check parameter do not meet the check conditions, generate a retransmission instruction; wherein, the second check parameter includes the second check code, the second binary frequency domain energy checksum, and the second hexadecimal numerical checksum;

[0190] The verification conditions include: the first check code is equal to the second check code, the difference between the first binary frequency domain energy checksum and the second binary frequency domain energy checksum is less than the first difference threshold, and the first hexadecimal numerical checksum is equal to the second hexadecimal numerical checksum.

[0191] In this embodiment of the application, the verification condition can be represented by the following formula (7).

[0192]

[0193] Wherein, C is the first check code, C′ is the second check code, S is the first binary frequency domain energy checksum, S′ is the second binary frequency domain energy checksum, δ is the first difference threshold, H is the first hexadecimal numerical checksum, and H′ is the second hexadecimal numerical checksum.

[0194] In this embodiment, if at least one of the parameters in the first verification parameter and the corresponding parameter in the second verification parameter fails to meet the verification condition, it is determined that an error has occurred in the hexadecimal message bitmask in the simulated message data during conversion or transmission, and a retransmission instruction is generated, thereby triggering the retransmission mechanism. Thus, through the above method, Fourier DFT verifies binary-to-hexadecimal data from both the frequency and time domains, and compared to traditional verification methods, it can detect data errors more comprehensively and accurately.

[0195] The calculated bus data can be transmitted directly via CAN / CANFD / LIN, or encapsulated into data packets according to the following DOIP / DDS message format before transmission.

[0196] In some embodiments, the communication control module of a computer device includes a protocol parsing engine, which can perform reverse parsing and forward assembly of message data based on different communication protocols via CANoe, ensuring data consistency. For example, refer to... Figure 1 , Figure 2 and Figure 6 As shown, the communication control module 201 of computer device 3 is connected to multiple CANoe devices 5. Different CANoe devices are used to receive actual message data of the same or different communication protocols, or to send simulated message data of the same or different communication protocols 601, and save the received actual message data and the sent simulated message data 602. It should be noted that the communication control module can use the message data parsing / assembly module corresponding to different communication protocols. First, the original data 604 in the test case is converted into binary data 605 according to the signal mapping relationship, such as in... Figure 5 The binary bits of the signal are retrieved from Tables 1 and 2. Next, hexadecimal message calculation / verification is performed on the binary data to obtain hexadecimal message 611. Further, based on the message type corresponding to the communication protocol, the message parsing / assembly module 603 assembles the hexadecimal message to obtain simulated message data. Alternatively, the message parsing / assembly module 603 parses the received message and saves the parsed message 612. For example, if the test case contains raw data such as a vehicle speed signal of 30 km / h, it needs to be converted into message data, assembled, and then sent. It should be noted that the message types of different communication protocols include, but are not limited to, CAN / CANFD messages, LIN messages, DOIP messages, SOME / IP messages, and DDS messages. Correspondingly, the message parsing / assembly module 603 includes a CAN / CANFD message data parsing / assembly module 606, a LIN message data parsing / assembly module 607, a DOIP message data parsing / assembly module 608, a SOME / IP message data parsing / assembly module 609, and a Data Distribution Service (DDS) message data parsing / assembly module 610.

[0197] It is understandable that message data for the CAN / CANFD protocol can be parsed and assembled using the CAN / CANFD message data parsing and assembly module 606. Message data for the LIN protocol can be parsed and assembled using the LIN message data parsing and assembly module 607. Message data for the DOIP protocol can be parsed and assembled using the DOIP message data parsing and assembly module 608. Message data for the SOME / IP protocol can be parsed and assembled using the SOME / IP message data parsing and assembly module 609. Message data for the DDS protocol can be parsed and assembled using the DDS message data parsing and assembly module 610.

[0198] For example, the message structures of the DOIP protocol, DDS protocol, and SOME / IP protocol are used as examples for illustration. Figure 7 , 8 As shown in Figure 9, Figure 7 This is a schematic diagram of the message structure of the DOIP protocol. Figure 8 This is a schematic diagram of the message structure of the DDS protocol. Figure 9 This is a schematic diagram of the message structure of the SOME / IP protocol.

[0199] The DOIP protocol's message structure includes a UDP header, a DOIP header, and a DOIP payload. The UDP header occupies 8 bytes and is transmitted based on the UDP protocol. It contains a source port, a destination port, a length, and a checksum, each occupying 2 bytes. The source port can be the sender's port, the destination port can be the receiver's port, the length can be the total length of the UDP message, and the checksum verifies data integrity. The DOIP header also occupies 8 bytes and defines the DOIP protocol itself, including the protocol version, reverse protocol version, payload type, and payload length. The protocol version can be the current protocol version and may occupy 1 byte. The reverse protocol version can be a version adapted for reverse communication and may occupy 1 byte. The payload type identifies the data type of the payload, such as a diagnostic request / response, and may occupy 2 bytes. The payload length indicates the number of bytes in the DOIP payload and may occupy 4 bytes. The DOIP payload carries the actual communication content, such as diagnostic messages from an automotive bus. Its byte length varies depending on data requirements and represents the core business data of the interaction.

[0200] The DDS protocol's message structure is based on the Real-Time Publish-Subscribe (RTPS) protocol, defining a UDP header, DDS header, and submessages. The UDP header in the DDS message structure is similar to that in the DOIP protocol and will not be described further. The DDS header defines the core identifier and metadata of the DDS protocol, including the RTPS identifier, protocol version, vendor identifier, and payload length. The RTPS identifier, associated with the DDS RTPS specification, is used for protocol identification and compatibility and can occupy 4 bytes. The protocol version identifies the DDS protocol version, ensuring version compatibility between communicating parties and can occupy 2 bytes. The vendor identifier distinguishes different vendor implementations, supports customized extensions, and can occupy 2 bytes. The payload length describes the total number of bytes in the "submessage" and can occupy 12 bytes. Here, the sub-message is the actual carrier and interaction unit of DDS data. The sub-message includes sub-message information-transport specific (INFO_TS) and sub-message data (DATA). The sub-message INFO_TS can occupy 12 bytes; the sub-message DATA has a variable byte length and includes a flag, other fields, and sequence number user data. The flag can occupy 2 bytes, divided into two 1-byte fields. The flag is used to define the data type and transmission status (such as whether it is a control message, data priority, etc.). The other fields can occupy 22 bytes and include read / write entity ID, extended flags, etc., used to carry business-related control information. The sequence number user data has a variable byte length and is the core content of the communication.

[0201] The SOME / IP protocol message structure includes message ID, request ID, and payload information. The message ID can occupy 4 bytes, including a service ID, a reserved bit, and a method ID. The service ID can occupy 2 bytes to identify the service involved in the message, distinguishing different services; the reserved bit occupies 1 bit; and the method ID can occupy 15 bits to identify the specific method within the service. The request ID can also occupy 4 bytes, including 1 byte each for the protocol version, interface version, message type, and return code. The protocol version identifies the currently used protocol version number; the interface version identifies the interface version used by the message. The message type specifies the message type, such as a request message, response message, or notification message; the return code indicates the message processing result, such as success, failure, or error code. The payload information has a variable byte length and contains the actual content of the message, such as the requested data or the response result.

[0202] Thus, in this embodiment of the application, the computer device uses Python to call the Vector toolchain API to capture the message data parsed by CANoe in real time and synchronously record the communication line status of the programmable device, forming a linkage between "protocol parsing and hardware control".

[0203] In some embodiments, the communication protocol includes multiple types, including but not limited to CAN / CANFD upgrade packet transmission, FBL protocol, DOIP diagnostic protocol and SOME / IP service protocol, and non-critical LIN bus messages. In step 304, according to the target test case, the power state and / or communication state of each controller is controlled by the programmable device, and each simulation message data is sent to the target participating node corresponding to the target controller in the disconnected state through the CANoe device, including:

[0204] Step 341: Obtain the scheduling priority corresponding to each type of communication protocol.

[0205] In this embodiment, the scheduling priority can be the execution order level set for different communication protocols during multi-protocol concurrent simulation. The scheduling priority is dynamically set by the computer device based on the protocol type, functional importance, and impact on the OTA upgrade process. For example, in an OTA upgrade scenario, the communication protocol with the first scheduling priority is usually given high priority because it is directly responsible for the transmission of upgrade packets, such as the core OTA upgrade protocols, including but not limited to upgrade packet transmission such as CAN / CANFD and the FBL protocol. The communication protocol with the second scheduling priority is used for diagnostic interaction, followed by diagnostic protocol DOIP and service protocol SOME / IP; the communication protocol with the third scheduling priority is used for non-critical signal transmission, and therefore has a lower priority, such as non-critical LIN bus messages (e.g., vehicle light control). It should be noted that the setting of scheduling priorities ensures that there are no conflicts between the protocols and that communication tasks can be completed in a logical order.

[0206] In this embodiment of the application, by setting scheduling priorities, the execution order of various communication protocols can be reasonably arranged, thereby avoiding signal conflicts and timing chaos, and improving system operating efficiency and stability.

[0207] Step 342: According to the target test case, in accordance with the scheduling priority order, the communication state of the first controller corresponding to the communication protocol of the first scheduling priority is switched to the disconnected state through the programmable control device, and the simulation message data of the communication protocol of the first scheduling priority is sent to the first participating node communicating with the first controller through the CANoe device.

[0208] Understandably, a programmable controller (CNC) is a hardware device with automated control capabilities, which can be remotely controlled via a computer to switch the power and communication lines of the controller on and off. A CANoe device is a professional in-vehicle communication analysis tool that supports multiple automotive bus protocols (such as CAN, LIN, ETH, etc.) and can simulate controller behavior and send simulated message data.

[0209] In this embodiment of the application, the communication protocol with the first scheduling priority refers to the protocol with the highest current execution order, for example...

[0210] CAN / CANFD protocol. The first participating node is the node that receives the simulated message of the communication protocol with the highest scheduling priority; it is usually a gateway or other controller.

[0211] In this embodiment, the computer device, through a communication control module, controls the communication state of the first controller corresponding to the communication protocol with the first scheduling priority to be switched to a disconnected state according to the target test case and the scheduling priority order. Further, after a period of time, such as 50 milliseconds (ms), the communication control module uses a CANoe device to send the simulation message data of the communication protocol with the first scheduling priority to the first participating node communicating with the first controller. Thus, through the collaborative work of the programmable device and the CANoe device, simulation messages can be accurately sent even when the communication line of a specific controller is disconnected, effectively isolating interference between the actual controller and the simulation environment, avoiding competition for the bus between actual and simulation messages, and improving test accuracy.

[0212] Step 343: Switch the communication status of the first controller to recovery status through the programmable control equipment.

[0213] In this embodiment, the computer device, through its communication control module and using a CANoe device, sends simulated message data of the communication protocol with the first scheduling priority to the first participating node communicating with the first controller. After a period of time, such as 100ms, the communication line is reconnected via a programmable device, restoring the first controller to normal communication status and preparing for the execution of other protocols in the next step. This restoration of communication status ensures the overall continuity and stability of the system, and also prevents subsequent test steps from failing due to communication interruptions.

[0214] Step 344: According to the scheduling priority order, the communication state of the second controller corresponding to the communication protocol of the second scheduling priority is switched to the disconnected state through the programmable control device, and the simulation message data of the communication protocol of the second scheduling priority is sent to the second participating node communicating with the second controller through the CANoe device; wherein, the first scheduling priority is higher than the second scheduling priority, and the target controller includes the first controller and the second controller.

[0215] In this embodiment, the communication protocol with the second scheduling priority refers to the protocol that ranks second in the current execution sequence, such as the DOIP protocol. The second participating node is the participating node that receives the simulation message of the communication protocol with the second scheduling priority, and may be an in-vehicle intelligent terminal or other controller. This step continues the communication target protocol testing process of the previous scheduling priority, and executes the protocol test of the next priority in sequence.

[0216] In this embodiment, the computer device, through a communication control module, controls the communication state of the second controller corresponding to the communication protocol with the second scheduling priority to be switched to a disconnected state via a programmable control device, according to the scheduling priority order. Further, after a period of time, such as 50ms, the communication control module uses a CANoe device to send the simulation message data of the communication protocol with the second scheduling priority to the second participating node communicating with the second controller. The second participating node may be the same as or different from the first participating node. Thus, by executing communication protocol tests with different scheduling priorities step by step, the simulation and verification of multiple protocols can be completed in an orderly manner, thereby ensuring the integrity and controllability of the testing process.

[0217] Step 345: Switch the communication status with the second controller to the recovery state via the programmable control equipment.

[0218] In this embodiment, the computer device, through the communication control module, uses a CANoe device to send simulated message data of the communication protocol with the second scheduling priority to the second participating node communicating with the second controller. After a period of time, such as 100ms, the communication line is reconnected via a programmable device, restoring the second controller to normal communication status and preparing for the execution of other protocols in the next step. Thus, the restoration of the communication status ensures the overall continuity and stability of the system, and also avoids the failure of subsequent test steps due to communication interruption.

[0219] As can be seen from the above, in this embodiment of the application, by introducing a scheduling priority mechanism and using the programmable device and the CANoe device to coordinate the control of communication status and the sending of simulation messages, the signal conflict problem in the process of multi-protocol concurrent simulation can be effectively solved, thereby ensuring the orderly execution of each protocol and improving the overall efficiency and accuracy of OTA communication simulation testing.

[0220] In some embodiments, the upgrade result obtained in step 306 based on actual message data, simulated message data, and preset message data can be achieved through the following steps.

[0221] Step 361: Obtain the major version information of the vehicle-mounted intelligent terminal in the simulation test bench.

[0222] In this embodiment, the major version information refers to the overall version number of the operating system or software platform currently installed on the vehicle-mounted intelligent terminal, typically consisting of a major version number and a minor version number, such as V1.4.2. This version information is used to identify the operating environment of the entire OTA upgrade system, ensuring compatibility between the upgrade process and the current system. Here, the computer device can view the major version information of the vehicle-mounted intelligent terminal through an image acquisition device (also known as an industrial camera) according to the target test cases.

[0223] Step 362: If the major version information is consistent with the major version information provided by the OTA cloud, the actual message data and the simulated message data are consistent with the corresponding preset message data, and the upgraded version information of each upgraded object is consistent with the corresponding upgraded version information, then the upgrade result is successful.

[0224] In this embodiment of the application, the upgraded version information of each upgrade object can be read by the computer device from each upgrade object through a diagnostic protocol.

[0225] In this embodiment, the computer device determines that the major version information matches the major version information provided by the OTA cloud, the actual message data matches the corresponding preset actual message data, the simulated message data matches the corresponding preset simulated message data, and the upgraded version information of each upgrade object matches the corresponding upgraded version information in the upgrade task information. This results in a successful upgrade. The test report can be stored on the computer device for a period of time and then automatically deleted to reduce memory usage. If at least one of the following is inconsistent: between the major version information and the major version information provided by the OTA cloud, between the actual message data and the corresponding preset actual message data, between the simulated message data and the corresponding preset simulated message data, or between the upgraded version information of each upgrade object and the corresponding upgraded version information in the upgrade task information, an upgrade failure result is obtained. In this case, the test report can be uploaded to the OTA cloud as an attachment to the defect submission. Thus, through the above method, the completeness and accuracy of the OTA upgrade process can be accurately evaluated. This avoids misjudgments caused by version mismatch or communication anomalies, thereby improving the reliability of OTA testing and supporting unified testing requirements for multiple vehicle models, multiple controllers, and multiple protocols.

[0226] Below, in conjunction with Figure 1 , Figure 2 and Figure 10 The implementation process of the embodiments of this application in a feasible application scenario is described below.

[0227] Step 701: Set up the OTA platform and build the hardware environment.

[0228] Among them, the OTA test bench (corresponding to the simulation test bench mentioned above) is connected to the vehicle intelligent terminal, gateway, and various controller ECUs.

[0229] The hardware environment setup (corresponding to the hardware system architecture of the aforementioned test environment) includes: connecting the controller power cord to the programmable BOB to control the controller's power-on and power-off; connecting the communication network in the OTA test bench to the programmable BOB, including CAN / CANFD, ETH, LIN, and other networks, and controlling the closing and opening of the communication lines; placing the robotic arm and industrial camera above the vehicle-mounted intelligent terminal to ensure clear imaging from the industrial camera and that the robotic arm can normally simulate user touch operations on the vehicle-mounted intelligent terminal; and connecting the CANoe, programmable BOB, robotic arm, and industrial camera equipment to the industrial control computer (corresponding to the aforementioned computer equipment) to ensure that the various functional modules of the industrial control computer can normally call upon these hardware devices.

[0230] Step 702: Run the test case generation module.

[0231] Here, the industrial control computer uses the test case generation module to generate test cases with interactive messages (corresponding to the target test cases mentioned above). All steps require specifying the test messages to ensure complete scenario coverage.

[0232] Step 703: Execute the test cases.

[0233] Here, the industrial control computer automatically runs the following modules according to the use case steps: OTA cloud control module, power control module, vehicle intelligent terminal control module, and communication control module. Recording message data and vehicle intelligent terminal interface data begins as soon as the use case execution starts and continues until the use case is completed.

[0234] Among them, the industrial control computer runs the OTA cloud control module 203, completes the OTA upgrade package creation 731 and OTA upgrade task configuration 732, and records the upgrade target and version;

[0235] Among them, the industrial control computer runs the power control module 205, which controls the power control channel of the programmable BOB4 to complete the power-on of the bench, and subsequently controls the controller to power on 733 or power off 734 according to the test case steps.

[0236] Among them, the industrial control computer runs the vehicle-mounted intelligent terminal control module 204, and according to the test case steps, it views the real-time interface of the vehicle-mounted intelligent terminal through the industrial camera 735, takes a screenshot, and performs text recognition; and it initiates the OTA process 736 by clicking the interface of the vehicle-mounted intelligent terminal through the robotic arm, such as triggering version collection, triggering version details viewing, triggering download, triggering installation, and other steps.

[0237] Among them, the industrial control computer runs the communication control module 201, which realizes the reception and storage of messages from all communication networks and the parsing of messages that need to be parsed through the CANoe device 5; and can cooperate with the communication control channel of the programmable BOB4 to simulate messages and send messages (when sending messages through CANoe, the programmable BOB disconnects the ECU communication line of the message sender, and reconnects it after the message is sent to resolve the conflict between the simulated message and the actual message). The simulation process also includes the CRC check part of the CAN communication protocol.

[0238] It should be noted that step 703 is executed according to the test case steps.

[0239] Here, in multi-protocol, multi-controller concurrent simulation, to resolve conflicts between simulated and actual messages, the industrial control computer can coordinate the timing of the programmable BOB and CANoe to achieve closed-loop control of "communication line disconnection - multi-type message transmission - communication line restoration." The specific timing logic is as follows: Figure 11 As shown, the industrial control computer sends a disconnect command 801 to one or more controllers to the programmable logic controller (PLC) BOB. Based on the disconnect command 801, the PLC BOB disconnects the communication lines (such as CAN_H / CAN_L) 802 of one or more controllers through the communication control channel. The industrial control computer sends a multi-protocol simulation message 803 to CANoe, and CANoe sends a simulation message to avoid the actual message and the simulation message competing for the bus. 100ms after the sending is completed, the industrial control computer sends a recovery command 805 to one or more controllers to the PLC BOB. Based on the recovery command 805, the PLC BOB restores the communication of one or more controllers through the communication control channel to ensure bus timing consistency.

[0240] In some embodiments, a timing mapping table is established for the interaction scenarios of ETH (DOIP / SOMEIP) and CAN / CANFD protocols. For example, the time difference between DOIP diagnostic requests and CAN responses is controlled within 200ms, and the ordered interaction of different protocol messages is achieved through the priority scheduling mechanism of the programmable BOB. In this way, through cross-protocol timing mapping, this mechanism reduces the signal collision rate from 32% to 1.5%.

[0241] Step 704: Run the test result generation module.

[0242] Here, the industrial control computer uses an industrial camera to view the major version information of the vehicle-mounted intelligent terminal and analyzes the captured messages in order to compare them with the expected message data in the test cases.

[0243] Step 705: Determine whether the data matches the expected message data in the test case.

[0244] Here, if the captured message data matches the expected message data, proceed to step 706; if the captured message data does not match the expected message data, proceed to step 707.

[0245] Step 706: Save one week's worth of message data and vehicle-mounted intelligent terminal interface data.

[0246] Step 707: Back up the message data and the vehicle-mounted intelligent terminal interface data, and use them as attachments to submit the defect.

[0247] Here, the industrial control computer, based on the test cases, compares the major version information of the in-vehicle intelligent terminal viewed through the industrial camera with the cloud data, and combines the message exchange data with the test case data to determine whether the test case was successful. After all test cases are executed, a test report is generated. The report includes the version information of all controllers before and after the upgrade: software part number, software version, BOOT version, hardware part number, and hardware version information; as well as the major version information of the vehicle before and after the upgrade. The major version information of the vehicle before and after the upgrade is obtained by viewing the in-vehicle intelligent terminal through the industrial camera; the controller version information is read by the industrial control computer from each controller through the diagnostic protocol. The test report is then uploaded to the test cloud, where it organizes and displays all the test reports from the industrial control computers.

[0248] This application provides an OTA simulation testing device, referring to... Figure 12 As shown, Figure 12 This is a schematic diagram of an OTA simulation testing device provided in an embodiment of this application. The OTA simulation testing device 9 includes:

[0249] Response module 901 is used to respond to input operations;

[0250] Processing module 902 is used to generate target test cases containing preset message data; wherein, the target test cases include at least any process of the upgrade object loading the upgrade file from the OTA cloud through the simulation test bench to perform OTA upgrade, and the target test cases include preset message data when the participating nodes in the simulation test bench communicate with each other, and the preset message data includes preset actual message data and preset simulation message data;

[0251] Processing module 902 is also used to execute target test cases;

[0252] The response module 901 is also used to respond to test tasks sent by the OTA cloud for the simulation test bench during the execution of the target test case;

[0253] The processing module 902 is also used to configure upgrade task information, create upgrade files associated with the upgrade task information, and upload them to the OTA cloud; wherein, the upgrade task information includes upgrade object and upgrade version information, and the upgrade object includes at least one target controller in the simulation test bench;

[0254] The processing module 902 is also used to generate multiple simulation message data corresponding to different communication protocols according to the target test cases during the OTA upgrade process when each target controller loads the upgrade file from the OTA cloud through the simulation test bench. The simulation message data is the message data sent by the target controller in the disconnected state to other participating nodes in the simulation test bench. The communication protocols used by different target controllers and other participating nodes when communicating with each other may be the same or different.

[0255] The processing module 902 is also used to control the power status and / or communication status of each controller through the programmable device according to the target test case, and send each simulation message data to the target participating node corresponding to the target controller in the disconnected state through the CANoe device for parsing and identification.

[0256] The processing module 902 is also used to capture the actual message data when communicating with the controller in the connected state through the CANoe device according to the target test case;

[0257] The processing module 902 is also used to obtain the upgrade result based on the actual message data, simulated message data and preset message data after the target test case has been executed, and to generate a test report based on the upgrade result.

[0258] This application provides a computer device, comprising: at least one processor, and a memory communicatively connected to the at least one processor; wherein...

[0259] The memory stores a computer program that can be executed by at least one processor to perform some or all of the steps in the above method.

[0260] This application provides a computer-readable storage medium storing one or more computer programs, which can be executed by one or more processors to implement some or all of the steps in the above-described method. The storage medium can be transient or non-transient.

[0261] This application provides a computer program including computer-readable code, wherein when the computer-readable code is executed in a computer device, a processor in the computer device performs some or all of the steps in the above-described method.

[0262] This application provides a computer program product, which includes a non-transitory computer-readable storage medium storing a computer program. When the computer program is read and executed by a computer, it implements some or all of the steps in the above-described method. This computer program product can be implemented specifically through hardware, software, or a combination thereof. In some embodiments, the computer program product is specifically embodied as a computer storage medium; in other embodiments, the computer program product is specifically embodied as a software product, such as a software development kit (SDK), etc.

[0263] It should be noted that the descriptions of the various embodiments above tend to emphasize the differences between them, while their similarities or commonalities can be referred to interchangeably. The descriptions of the above embodiments of the device, storage medium, computer program, and computer program product are similar to the descriptions of the above method embodiments and have similar beneficial effects. For technical details not disclosed in the embodiments of the device, storage medium, computer program, and computer program product of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0264] This application provides a schematic diagram of the hardware entity of a computer device, which may be a terminal, such as... Figure 13 As shown, the hardware entity of the computer device 3 includes: at least one processor 1001, and a memory 1002 communicatively connected to the at least one processor 1001; wherein,

[0265] The memory 1002 stores a computer program that can be executed by at least one processor 1001 to perform the following steps:

[0266] In response to the test task sent by the OTA cloud for the simulation test bench, the upgrade task information is configured, and the upgrade file associated with the upgrade task information is created and uploaded to the OTA cloud; wherein, the upgrade task information includes upgrade object and upgrade version information, the test object is at least one participating node in the simulation test bench, and the upgrade object includes at least one target controller and vehicle intelligent terminal in the simulation test bench;

[0267] Based on the test task, target test cases containing preset message data are generated. The target test cases include at least any process of each target controller loading upgrade files from the OTA cloud through the simulation test bench to perform OTA upgrade. The target test cases contain preset message data when communication occurs between participating nodes in the simulation test bench. The preset message data includes preset actual message data and preset simulation message data.

[0268] Execute the target test case. During the execution of the target test case, generate simulation message data corresponding to multiple communication protocols according to the target test case. The simulation message data is the message data sent by the controller in the disconnected state to other participating nodes in the simulation test bench. The communication protocols used by different controllers and other participating nodes are the same or different.

[0269] Based on the target test cases, the power status and / or communication status of each controller are controlled by the programmable device, and each simulated message data is sent to the target participating node corresponding to the controller in the disconnected state through the CANoe device for parsing and identification.

[0270] Based on the target test cases, capture the actual message data when communicating with the controller in the connected state using the CANoe device;

[0271] Once the target test cases have been executed, the upgrade results are obtained based on the actual message data, simulated message data, and preset message data, and a test report is generated based on the upgrade results.

[0272] The processor 1001 and the memory 1002 are provided, wherein the memory 1002 stores a computer program that can run on the processor 1001, and the processor 1001 executes some or all of the steps in the OTA simulation test method described above.

[0273] The memory 1002 stores computer programs that can run on the processor. The memory 1002 is configured to store instructions and applications that can be executed by the processor 1001. It can also cache data to be processed or already processed by the processor 1001 and various modules in the computer device 10 (e.g., image data, audio data, voice communication data and video communication data). It can be implemented by flash memory or random access memory (RAM).

[0274] The processor 1001 executes the program to implement any of the steps of the OTA simulation test method described above. The processor 1001 typically controls the overall operation of the computer device 10.

[0275] Continue to refer to Figure 13 The computer device 10 may also include a communication bus 1003 and a communication interface 1004.

[0276] The communication bus 1003 can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into an address bus, a data bus, a control bus, etc. The bus is configured to enable communication between the memory 1002 and at least one processor 1001.

[0277] The communication interface 1004 is used for communication between the aforementioned computer device and other devices, including a network interface and a user interface. Optionally, the network interface may include a wired interface and / or a wireless interface (such as a Wi-Fi interface, Bluetooth interface, etc.), typically used to establish communication connections between the computer device and other computer devices. The user interface may be a display, an input unit (such as a keyboard), and optionally, the user interface may also be a standard wired interface or a wireless interface. Optionally, in some embodiments, the display may be an LED display, a liquid crystal display, a touch-screen liquid crystal display, or an OLED display.

[0278] (Organic Light-Emitting Diode) touchscreens, etc. A display, also appropriately called a screen or display unit, is used to display information processed in computer devices and to display visual user interfaces.

[0279] It should be noted that the descriptions of the storage medium and device embodiments above are similar to the descriptions of the method embodiments above, and have similar beneficial effects. For technical details not disclosed in the storage medium and device embodiments of this application, please refer to the descriptions of the method embodiments of this application for understanding.

[0280] The aforementioned processor can be at least one of the following: Application-Specific Integrated Circuit (ASIC), Digital Signal Processor (DSP), Digital Signal Processing Device (DSPD), Programmable Logic Device (PLD), Field Programmable Gate Array (FPGA), Central Processing Unit (CPU), Controller, Microcontroller, and Microprocessor. It is understood that other electronic devices can also implement the functions of the aforementioned processor, and this application does not specifically limit the specific implementation.

[0281] The aforementioned computer storage media / memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), magnetic random access memory (FRAM), flash memory, magnetic surface memory, optical disc, or compact disc read-only memory (CD-ROM), etc.; or it can be various terminals that include one or any combination of the above-mentioned memories, such as mobile phones, computers, tablet devices, personal digital assistants, etc.

[0282] It should be understood that the phrase "one embodiment" or "an embodiment" throughout the specification means that a specific feature, structure, or characteristic related to the embodiment is included in at least one embodiment of this application. Therefore, "in one embodiment" or "in an embodiment" appearing throughout the specification do not necessarily refer to the same embodiment. Furthermore, these specific features, structures, or characteristics can be combined in any suitable manner in one or more embodiments. It should be understood that in the various embodiments of this application, the sequence numbers of the above steps / processes do not imply a sequential order of execution; the execution order of each step / process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application. The sequence numbers of the above embodiments of this application are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0283] It should be noted that, in this document, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes that element.

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

[0285] The units described above as separate components may or may not be physically separate. The components shown as units may or may not be physical units. They may be located in one place or distributed across multiple convolutional network units. Some or all of the units may be selected to achieve the purpose of this embodiment according to actual needs.

[0286] In addition, each functional unit in the various embodiments of this application can be integrated into one processing unit, or each unit can be a separate unit, or two or more units can be integrated into one unit; the integrated unit can be implemented in hardware or in the form of hardware plus software functional units.

[0287] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as mobile storage devices, read-only memory (ROM), magnetic disks, or optical disks.

[0288] Alternatively, if the integrated units described above are implemented as software functional modules and sold or used as independent products, they can also 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 related technologies, 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 in-vehicle terminal (which may be a personal computer, server, or network device, etc.) to execute all or part of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as mobile storage devices, ROM, magnetic disks, or optical disks.

[0289] The above description is merely an embodiment of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application.

Claims

1. An over-the-air (OTA) download simulation test method, characterized in that, Applied to a computer device, the method includes: In response to an input operation, a target test case containing preset message data is generated; wherein, the target test case includes at least any process of the upgrade object loading an upgrade file from the OTA cloud through a simulation test bench to perform an OTA upgrade, and the target test case contains preset message data when communication occurs between participating nodes in the simulation test bench, the preset message data including preset actual message data and preset simulation message data; The target test case is executed. During the execution of the target test case, in response to the test task sent by the OTA cloud for the simulation test bench, upgrade task information is configured, and an upgrade file associated with the upgrade task information is created and uploaded to the OTA cloud. The upgrade task information includes the upgrade object and upgrade version information, and the upgrade object includes at least one target controller in the simulation test bench. During the OTA upgrade process where each target controller loads the upgrade file from the OTA cloud via the simulation test bench... Based on the target test cases, multiple simulation message data corresponding to different communication protocols are generated. The simulation message data is message data sent by the target controller in a disconnected state to other participating nodes in the simulation test bench. The different target controllers may use the same or different communication protocols when communicating with the other participating nodes. According to the target test case, the power status and / or communication status of each controller are controlled by the programmable device, and the simulation message data of each controller is sent to the target participating node corresponding to the target controller in the disconnected state through the CANoe device for parsing and identification. According to the target test case, the CANoe device captures the actual message data when communicating with the controller in the connected state; Once the target test case is completed, the upgrade result is obtained based on the actual message data, the simulated message data, and the preset message data, and a test report is generated based on the upgrade result.

2. The method according to claim 1, characterized in that, The step of generating simulation message data corresponding to multiple communication protocols based on the target test case includes: Obtain the test signal corresponding to each target controller in the disconnected state in the simulation test bench in the target test case, wherein the test signal includes temperature signal, vehicle speed signal and gear signal; For each test signal, a signal mapping relationship is used to map the test signal to a binary signal, wherein the signal mapping relationship includes the mapping relationship between the test signal and the binary signal, and the binary signal includes the binary signal value and the binary signal bit position; Based on the binary signal value and the position of the binary signal bit, a message bitmask corresponding to the communication protocol is generated, thereby obtaining the simulated message data.

3. The method according to claim 2, characterized in that, The step of generating the message bitmask corresponding to the communication protocol based on the binary signal value and the binary signal bit position includes: Based on the binary signal value and the position of the binary signal bit, a message bitmask for the first binary bit is obtained using a mathematical model; wherein, the mathematical model is, or, Where M(S) is the binary message bitmask, S is the set of binary signal bit positions, and p n For binary signal bit positions, 0≤p n ≤N, where N is 511 or 63; The message bitmask of the first binary bit is converted into a message bitmask of the first hexadecimal number to obtain the message bitmask corresponding to the communication protocol.

4. The method according to claim 3, characterized in that, The method further includes: The message bitmask of the first binary bit is treated as a discrete signal and transformed using a discrete Fourier transform model to obtain a first binary frequency domain sequence; wherein, the frequency domain sequence represents the amplitude and phase of the message bitmask at different frequency components, and the discrete Fourier transform model is... Where M[k] is a binary frequency domain sequence, M(S) is a binary message bit mask, and kn is a time-frequency coupling term; The first binary frequency domain energy checksum is determined based on the amplitude at each frequency domain position in the first binary frequency domain sequence. Based on the valid values ​​in the first hexadecimal message bitmask, determine the first hexadecimal numerical checksum; Based on the first binary frequency domain energy checksum and the first hexadecimal numerical checksum, logical operations and modulo operations are performed to obtain the first checksum of the message bitmask corresponding to the communication protocol. The simulated message data carries a first check parameter, which is used by the target participating node to verify the received simulated message data. The first check parameter includes: the first checksum, the first binary frequency domain energy checksum, and the first hexadecimal numerical checksum.

5. The method according to claim 4, characterized in that, After sending each simulation message data to the target participating node corresponding to the controller in the disconnected state via the CANoe device, the method further includes: In response to a retransmission command sent by the target participating node, the CANoe device retransmits the simulation message data corresponding to the target participating node to the target participating node based on the retransmission command; wherein the retransmission command is determined based on the first verification parameter.

6. The method according to claim 5, characterized in that, The process of determining the retransmission instruction includes: The target participating node receives the simulated message data; wherein, the simulated message data includes a 26-bit message bitmask and the first verification parameter; Determine the hexadecimal checksum based on the valid values ​​in the hexadecimal message bitmask. The second hexadecimal message bitmask is converted to obtain the second binary message bitmask; The message bit mask of the second binary bit is used as a discrete signal, and the discrete Fourier transform model is used to transform it to obtain the second binary frequency domain sequence. The second binary frequency domain energy checksum is determined based on the amplitude at each frequency domain position in the second binary frequency domain sequence. Based on the second binary frequency domain energy checksum and the second hexadecimal numerical checksum, logical operations and modulo operations are performed to obtain the second checksum of the message bitmask corresponding to the communication protocol. If the first verification parameter and the second verification parameter do not meet the verification conditions, the retransmission instruction is generated; wherein, the second verification parameter includes the second check code, the second binary frequency domain energy checksum, and the second hexadecimal numerical checksum; The verification conditions include: the first check code is equal to the second check code, the difference between the first binary frequency domain energy checksum and the second binary frequency domain energy checksum is less than a first difference threshold, and the first hexadecimal numerical checksum is equal to the second hexadecimal numerical checksum.

7. The method according to any one of claims 1 to 6, characterized in that, The communication protocol includes multiple types. According to the target test case, the power state and / or communication state of each controller is controlled by a programmable device, and each simulation message data is sent to the target participating node corresponding to the target controller in the disconnected state via a CANoe device, including: Obtain the scheduling priority corresponding to each type of communication protocol; According to the target test case, and in accordance with the scheduling priority order, the communication state of the first controller corresponding to the communication protocol of the first scheduling priority is switched to the disconnected state by the programmable device, and the simulation message data of the communication protocol of the first scheduling priority is sent to the first participating node communicating with the first controller by the CANoe device. The communication state of the first controller is switched to recovery state by the programmable device. According to the scheduling priority order, the communication state of the second controller corresponding to the communication protocol of the second scheduling priority is switched to the disconnected state by the programmable device, and the simulated message data of the communication protocol of the second scheduling priority is sent to the second participating node communicating with the second controller by the CANoe device; wherein, the first scheduling priority is higher than the second scheduling priority, and the target controller includes the first controller and the second controller; The communication state between the programmable device and the second controller is switched to a recovery state.

8. The method according to any one of claims 1 to 6, characterized in that, The step of generating target test cases containing preset message data according to the test task includes: Obtain the software requirements specification and communication protocol document for communication between different types of participating nodes in the simulation test bench; Based on the software requirements specification, the communication protocol document, and the message conversion algorithm containing signal mapping relationships, combined with the test requirements, the preset test case templates, and the number of test cases, an artificial intelligence model is used to generate initial test cases containing the preset message data. In response to the verification operation of the initial test cases, the target test cases that meet the test case verification conditions are selected from the initial test cases.

9. The method according to any one of claims 1 to 6, characterized in that, The upgrade result obtained based on the actual message data, the simulated message data, and the preset message data includes: Obtain the major version information of the vehicle-mounted intelligent terminal in the simulation test bench; If the major version information is consistent with the major version information provided by the OTA cloud, the actual message data and the simulated message data are consistent with the corresponding preset message data, and the upgraded version information of each upgraded object is consistent with the corresponding upgraded version information, then the upgrade result is successful.

10. An OTA simulation testing device, characterized in that, The device includes: The response module is used to respond to input operations; The processing module is used to generate target test cases containing preset message data; wherein, the target test cases include at least any process of the upgrade object loading upgrade files from the OTA cloud through the simulation test bench to perform OTA upgrade, and the target test cases contain preset message data when the participating nodes in the simulation test bench communicate with each other, and the preset message data includes preset actual message data and preset simulation message data; The processing module is also used to execute the target test cases; The response module is also used to respond to the test task sent by the OTA cloud for the simulation test bench during the execution of the target test case; The processing module is also used to configure upgrade task information, and to create an upgrade file associated with the upgrade task information and upload it to the OTA cloud; wherein, the upgrade task information includes the upgrade object and upgrade version information, and the upgrade object includes at least one target controller in the simulation test bench; The processing module is further configured to generate multiple simulation message data corresponding to different communication protocols according to the target test cases during the OTA upgrade process in which each target controller loads the upgrade file from the OTA cloud through the simulation test bench. The simulation message data is message data sent by the target controller in a disconnected state to other participating nodes in the simulation test bench. The communication protocols used for the message data when different target controllers communicate with the other participating nodes may be the same or different. The processing module is further configured to control the power status and / or communication status of each controller through a programmable device according to the target test case, and send each simulation message data to the target participating node corresponding to the target controller in the disconnected state through a CANoe device for parsing and identification. The processing module is also used to capture actual message data when communicating with the controller in a connected state through the CANoe device according to the target test case; The processing module is further configured to, upon completion of the execution of the target test case, obtain an upgrade result based on the actual message data, the simulated message data, and the preset message data, and generate a test report based on the upgrade result.

11. A computer device, characterized in that, The computer device includes: at least one processor, and a memory communicatively connected to the at least one processor; wherein... The memory stores a computer program that can be executed by the at least one processor to implement the OTA simulation test method as described in any one of claims 1 to 9.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores one or more computer programs, which can be executed by one or more processors to implement the OTA simulation test method as described in any one of claims 1 to 9.

Images