Vehicle testing system, method, storage medium and product

Abstract

This application provides a vehicle testing system, method, storage medium, and product. The vehicle testing system includes: an industrial control computer (ICC), a cloud server, and an interface device; the ICC is connected to the interface device and communicates with the cloud server; the cloud server communicates with the vehicle under test (V2T); the interface device is connected to the V2T; the ICC reads preset test cases, parses the test cases to obtain corresponding operation instructions and expected results, and sends editing instructions to the cloud server based on the operation instructions; the cloud server, upon receiving the editing instructions, generates corresponding software packages based on the editing instructions and distributes the software packages to the V2T; the ICC also sends corresponding test signals to the V2T through the interface device based on the operation instructions; the interface device collects the running results of the software packages in the V2T and forwards the running results to the ICC; the ICC also compares the running results with the expected results to obtain the test results.

Description

Technical Field

[0001] This application relates to the field of software testing technology, and in particular to a vehicle testing system, method, storage medium, and product. Background Technology

[0002] With the application of Service-Oriented Architecture (SOA) in the automotive industry, vehicle functions are abstracted into independent, reusable services, and hardware and software are decoupled through standardized interfaces. Simultaneously, cloud application development and vehicle-side function updates are rapidly evolving, forming a new integrated vehicle-cloud software development model. In this model, software must undergo joint testing and verification between the real-vehicle environment and the cloud backend before release to ensure the correctness and reliability of functional logic during interaction between the vehicle and the cloud. However, the testing process relies on manual operation, requiring testers to be proficient in both vehicle-side bus communication and cloud interface calls, which is not only inefficient but also difficult to keep up with the rapid iteration pace of development.

[0003] Currently, mainstream SOA automated testing technologies are mainly applied in the Internet field, focusing on automated testing of cloud or backend interfaces. Their test objects, communication methods, and test processes do not involve vehicle-side domain controllers and automotive-specific protocols, making it impossible to achieve complete verification of cloud operation and vehicle-side response processes, and thus failing to meet the testing requirements of vehicle-cloud integration. Summary of the Invention

[0004] This application provides a vehicle testing system, method, storage medium, and product that can solve the technical problem that the existing technology cannot meet the testing requirements of vehicle-cloud integration.

[0005] In a first aspect, this application provides a vehicle testing system, the vehicle testing system comprising: An industrial control computer, a cloud server, and interface devices; the industrial control computer is connected to the interface devices and communicates with the cloud server; the cloud server communicates with the vehicle under test; the interface devices are connected to the vehicle under test. The industrial control computer is used to read preset test cases, parse the test cases to obtain corresponding operation instructions and expected results, and send editing instructions to the cloud server based on the operation instructions; The cloud server is used to generate a corresponding software package based on the editing instruction upon receiving the editing instruction, and to send the software package to the vehicle under test; The industrial control computer is also used to send corresponding test signals to the vehicle under test through the interface device based on the operation instructions, so as to make the software package in the vehicle under test run. The interface device is used to collect the running results of the software package in the vehicle under test and forward the running results to the industrial control computer; The industrial control computer is also used to compare the running results with the expected results to obtain test results.

[0006] In some possible implementations, the interface device includes a bus interface device and a hardwired signal interface device; the bus interface device is connected to the bus pins of the industrial control computer and the bus pins of the vehicle under test; the hardwired signal interface device is connected to the hardwired pins of the industrial control computer and the hardwired pins of the vehicle under test. The industrial control computer is also used to determine the bus signals and input / output signals that need to be sent based on the operation instructions; The industrial control computer is also used to send the bus signal to the bus interface device and send the input / output signal to the hardwired signal interface device; The bus interface device is used to convert the bus signal into a physical level and then send it to the bus pin of the vehicle under test; The hardwired signal interface device is used to convert the input / output signal into a simulated signal and then output it to the hardwired pin of the vehicle under test.

[0007] In some possible implementations, the bus interface device is also used to acquire a first bus signal emitted by the vehicle under test when the software package is running; and to forward the first bus signal to the industrial control computer; The hardwired signal interface device is also used to collect the first hardwired signal emitted by the vehicle under test when the software package is running; and to forward the first hardwired signal to the industrial control computer.

[0008] In some possible implementations, the bus interface device is also used to listen to communication messages on the bus of the vehicle under test and upload the messages to the industrial control computer; The industrial control computer is also used to determine whether the update is complete based on the communication message; if the update is complete, the industrial control computer sends a corresponding test signal to the vehicle under test through the interface device based on the operation instruction, so as to make the software package in the vehicle under test run.

[0009] In some possible implementations, the industrial control computer is also used to parse the communication message and extract the version information from the communication message; The industrial control computer is also used to determine that the update is complete when the version information meets the update conditions; The industrial control computer is also used to re-acquire version information if the version information does not meet the update conditions.

[0010] In some possible implementations, the industrial control computer is also used to read a preset test specification file, determine the test cases in the test specification file; parse the test cases, extract the corresponding operation instructions and expected results; determine the corresponding editing operation based on the operation instructions; and send the editing instruction to the cloud server according to the editing operation. The cloud server is also used to execute the editing operation according to the editing instructions.

[0011] In some possible implementations, the cloud server is also used to, upon receiving the editing instructions, write and / or configure the software based on the editing instructions to obtain a software package; and distribute the software package to the domain controller corresponding to the vehicle under test.

[0012] Secondly, this application provides a vehicle testing method, which is applied to the vehicle testing system described above, and the method includes: Read the preset test cases, parse the test cases to obtain the corresponding operation instructions and expected results, and obtain the corresponding editing instructions based on the operation instructions; The corresponding software package is generated based on the editing instructions, and the software package is sent to the vehicle under test. Based on the operation instructions, a corresponding test signal is sent to the vehicle under test to enable the software package in the vehicle under test to run. Collect the running results of the software package in the vehicle under test; The test results are obtained by comparing the running results with the expected results.

[0013] Thirdly, this application provides a computer-readable storage medium storing computer program instructions that, when executed by a processor, implement the vehicle testing method described above.

[0014] Fourthly, this application provides a computer program product in which the instructions, when executed by a processor of an electronic device, cause the electronic device to perform the vehicle testing method described above.

[0015] The vehicle testing system, method, storage medium, and product provided in this application embodiment construct a fully automated vehicle-cloud integrated testing system through the collaborative work of an industrial control computer, a cloud server, and interface devices. The industrial control computer, as the core of test control, first automatically parses test cases and sends the included operation instructions to the cloud server and interface devices respectively: it sends editing instructions to the cloud server, enabling it to remotely generate and distribute software packages to the vehicle under test, thus automating the deployment of cloud functions without requiring manual intervention. Simultaneously, the industrial control computer sends test signals to the vehicle under test through the interface devices, simulating real bus communication to trigger the vehicle-side software operation, transforming the originally manually executed vehicle-side stimulus process into automated instructions. Subsequently, the interface devices collect the vehicle's operating results in real time and transmit them back to the industrial control computer, which automatically compares them with the expected results in the test cases, thereby completing the full functional verification from cloud deployment to vehicle-side response. The entire process does not require testers to be familiar with both cloud and vehicle-side operations simultaneously, eliminating the uncertainty of human operation, ensuring consistency and accuracy of results for each test execution, and effectively supporting rapid iterative verification of software functions in a vehicle-cloud integrated scenario, meeting the testing requirements of vehicle-cloud integration. Attached Figure Description

[0016] This application can be better understood from the following description of specific embodiments in conjunction with the accompanying drawings, wherein: Other features, objects, and advantages of this application will become more apparent from the following detailed description of non-limiting embodiments with reference to the accompanying drawings, wherein the same or similar reference numerals denote the same or similar features.

[0017] Figure 1 This is a schematic diagram of a vehicle testing system provided in one embodiment of this application; Figure 2 This is a schematic diagram of a vehicle testing system provided in another embodiment of this application; Figure 3 This is a flowchart of a vehicle testing method provided in one embodiment of this application; Figure 4 This is a schematic diagram of the vehicle testing system provided in the embodiments of this application; Detailed Implementation

[0018] The features and exemplary embodiments of various aspects of this application will be described in detail below. To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and specific embodiments. It should be understood that the specific embodiments described herein are intended only to explain this application and not to limit it. For those skilled in the art, this application can be implemented without some of these specific details. The following description of the embodiments is merely to provide a better understanding of this application by illustrating examples.

[0019] It should be noted that, in this document, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, 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. Without further limitations, an element defined by the phrase "comprising..." does not exclude the presence of additional identical elements in the process, method, article, or apparatus that includes said element.

[0020] SOA (Service-Oriented Architecture) is a software design paradigm that improves system flexibility and reusability by breaking down applications into independent, reusable service units and using standardized interfaces to decouple software. In recent years, the automotive industry has gradually introduced the SOA design paradigm into its software development process to adapt to rapidly changing market demands. Through service-oriented vehicle functions and standardized interfaces, it significantly reduces the coupling between software and hardware, and between different software components, enabling rapid development of vehicle application software. Simultaneously, the widespread adoption of SOA architecture and the extensive application of connected car features have allowed for the rapid deployment of backend applications in user vehicles, greatly satisfying users' evolving needs.

[0021] To ensure proper software functionality, necessary and thorough testing and verification are required before widespread application deployment. However, traditional manual testing methods demand testers with extensive experience in both vehicle-side and cloud platform testing. This approach places high demands on personnel skills and cannot meet the demands of rapid software testing. Therefore, an automated method capable of simultaneously operating on both the vehicle and cloud platforms is needed to achieve integrated vehicle-cloud SOA testing. Currently, the market for SOA testing primarily focuses on either cloud-side or vehicle-side testing, failing to combine the two and meet the current requirements for integrated vehicle-cloud testing. To fill the market gap in automated testing for both vehicle and cloud platforms, an integrated vehicle-cloud SOA automated testing system is proposed to meet the needs of the automotive industry. This system can simulate backend application software developers while simultaneously performing automated testing and verification on the vehicle side, improving the accuracy of software development and significantly increasing the efficiency of testing and verification.

[0022] Vehicle-cloud integrated SOA testing needs to simultaneously test and verify both the vehicle's SOA cloud backend and the vehicle's domain controller. Therefore, the objects of vehicle-cloud integrated SOA testing are completely different from those of existing SOA testing, and existing solutions cannot meet the testing requirements. Vehicle-cloud integrated SOA testing requires protocols that meet the requirements of the automotive industry, and the communication protocols used are more diverse than those in existing SOA testing. Compared with existing SOA testing specifications, the SOA testing specifications of automotive companies are highly correlated with their own SOA architecture. Furthermore, for vehicle-cloud integrated SOA testing, the test specification design must involve both the cloud and the vehicle, verifying not only the correctness of cloud or vehicle-side functions but also the correctness of the functional logic under vehicle-cloud integration. Vehicle-cloud integrated SOA testing needs to achieve closed-loop verification of vehicle-cloud functions. After the cloud operation is completed, closed-loop testing of the software functions on the vehicle is required to achieve vehicle-cloud integrated SOA test verification. Currently, most SOA automated testing is implemented in the internet industry by using specific software, and its application differs significantly from the automated testing requirements of the automotive industry for vehicle-cloud integrated SOA.

[0023] To address the problems of the prior art, embodiments of this application provide a vehicle testing system, method, storage medium, and product. The vehicle testing system provided in this application embodiment will be described first below.

[0024] Figure 1 A schematic diagram of a vehicle testing system provided in one embodiment of this application is shown. Figure 1 As shown, the vehicle test includes an industrial control computer 101, a cloud server 102, and an interface device 103. The industrial control computer 101 is connected to the interface device 103 and has a communication connection with the cloud server 102. The cloud server 102 has a communication connection with the vehicle under test. The interface device 103 is connected to the vehicle under test.

[0025] The industrial control computer 101 is used to read preset test cases, parse the test cases to obtain corresponding operation instructions and expected results, and send editing instructions to the cloud server 102 based on the operation instructions.

[0026] The cloud server 102 is used to generate the corresponding software package based on the editing instructions received, and then send the software package to the vehicle under test.

[0027] The industrial computer 101 is also used to send corresponding test signals to the vehicle under test via the interface device 103 based on operation instructions, so as to make the software package in the vehicle under test run.

[0028] The interface device 103 is used to collect the running results of the software package in the vehicle under test and forward the running results to the industrial control computer 101.

[0029] The industrial computer 101 is also used to compare the running results with the expected results to obtain the test results.

[0030] In practical implementation, the industrial control computer (ICC) retrieves a pre-defined test case file from its local or network storage medium. This file is typically in a structured data format. The ICC uses its built-in parser to perform syntactic analysis on the file, extracting the operation instruction fields corresponding to each test action defined in the file, as well as the expected result fields for that operation. This transforms the abstract test cases into a machine-recognizable set of specific instructions and evaluation criteria. For example, a test case might parse out an operation instruction and expected result of "sending a command to raise the vehicle window, with the expected result being that the window is completely closed." Next, based on the parsed operation instructions, the ICC executes the step of sending editing instructions to the cloud server. The ICC encapsulates the parsed operation instructions that require modification of the vehicle controller (e.g., modifying the parameters of the body control module) into a data packet conforming to the communication protocol with the cloud server, and sends this data packet to the designated cloud server via a TCP / IP network link.

[0031] After continuously listening to and receiving editing instructions from the industrial control computer, the cloud server parses the instructions to identify the specific controllers and parameters that need to be changed. Based on this information, the cloud server retrieves the corresponding firmware or configuration fragments from its database and dynamically generates an incremental software package or a complete flashing package containing only the changes required for this test using compilation or packaging tools. After generating the software package, the cloud server transmits the software package completely and reliably to the vehicle's onboard communication terminal through a remote communication connection established with the vehicle under test, and stores it on the vehicle. Once the software package is ready, the industrial control computer again executes the test signal sending step according to the previously parsed operation instructions. The industrial control computer identifies the parts of the operation instructions that are direct physical excitations and sends the corresponding electrical signals to the interface device through its physical interface. The interface device, acting as an intermediary for signal conversion and adaptation, receives the signal and modulates it to a precise voltage, current, or bus level that the corresponding interface of the vehicle under test can recognize, thereby simulating real physical world input and triggering the software package that has just been downloaded in the vehicle under test to start running.

[0032] The interface device monitors the physical lines or buses connected to the vehicle under test in real time. When the software package in the vehicle runs, it generates a corresponding response through the vehicle's output interface. The interface device captures these raw response signals, performs necessary filtering, analog-to-digital conversion, or protocol parsing, encapsulates them into standard format data, and then transmits them back to the industrial control computer via an internal communication link. The industrial control computer performs automatic comparison and judgment steps for the test results. The industrial control computer compares the actual running result data collected from the interface device with the expected result data parsed from the test cases in the first step. This comparison can be a precise numerical comparison, a logical state judgment, or a verification of complex data frames. The industrial control computer automatically determines whether the two match using a preset algorithm. If they match, the test step is considered passed; if they do not match, it is considered a failure. Finally, all judgment results are summarized to generate a structured test report.

[0033] The vehicle testing system provided in this application embodiment constructs a fully automated vehicle-cloud integrated testing system through the collaborative work of an industrial control computer, a cloud server, and interface devices. The industrial control computer, as the core of test control, first automatically parses test cases and sends the included operation instructions to the cloud server and interface devices respectively: it sends editing instructions to the cloud server, enabling it to remotely generate and distribute software packages to the vehicle under test, thus automating the deployment of cloud functions without requiring manual intervention. Simultaneously, the industrial control computer sends test signals to the vehicle under test through the interface devices, simulating real bus communication to trigger the vehicle-side software operation, transforming the originally manually executed vehicle-side stimulus process into automated instructions. Subsequently, the interface devices collect the vehicle's operating results in real time and transmit them back to the industrial control computer, which automatically compares them with the expected results in the test cases, thereby completing the full functional verification from cloud deployment to vehicle-side response. The entire process does not require testers to be familiar with both cloud and vehicle-side operations simultaneously, eliminating the uncertainty of human operation, ensuring consistency and accuracy of results for each test execution, and effectively supporting rapid iterative verification of software functions in a vehicle-cloud integrated scenario, meeting the testing requirements of vehicle-cloud integration.

[0034] In order to reasonably simulate and transmit signals, in some implementation methods, reference is made to... Figure 2 The interface device 103 includes a bus interface device 1031 and a hardwired signal interface device 1032. The bus interface device 1031 is connected to the bus pins of the industrial control computer 101 and the bus pins of the vehicle under test. The hardwired signal interface device 1032 is connected to the hardwired pins of the industrial control computer 101 and the hardwired pins of the vehicle under test.

[0035] The industrial computer 101 is also used to determine the bus signals and input / output signals that need to be sent based on the operation instructions.

[0036] The industrial computer 101 is also used to send bus signals to the bus interface device 1031 and input / output signals to the hard-wired signal interface device 1032.

[0037] The bus interface device 1031 is used to convert bus signals into physical levels and send them to the bus pins of the vehicle under test.

[0038] The hardwired signal interface device 1032 is used to convert input / output signals into analog signals and output them to the hardwired pins of the vehicle under test.

[0039] In practical implementation, after parsing the operation command, the industrial control computer (ICC) identifies the characteristic fields of the command based on the vehicle control object and its attributes, using its built-in command analysis module to determine whether the command should be transmitted via the bus channel or the hard-wired channel. For example, when the operation command is "send window raising command," the ICC recognizes that this command is usually transmitted via the vehicle's Controller Area Network (CAN) bus, thus classifying it as a bus signal. When the operation command is "simulate door locking / unlocking," the ICC recognizes that this command requires directly driving a hard-wired pin level change, thus classifying it as an input / output signal. The ICC then sends the identified bus-type operation command data, according to the communication protocol agreed upon with the bus interface device, through its internal bus controller and physical layer transceiver, to the bus interface device connected to its bus pin. During transmission, the ICC automatically adds corresponding frame headers, checksums, and other protocol fields according to the requirements of different bus types such as CAN or Ethernet, ensuring that the message format conforms to the vehicle bus specifications.

[0040] The bus interface device continuously listens for and captures bus message data sent by the industrial control computer (ICC) through its receiver, which is connected to the ICC's bus pins. Upon capturing the data, the transceiver chip built into the bus interface device converts the digital signal into differential or single-ended voltage levels conforming to the vehicle bus physical layer specifications. For example, it converts logic "0" and "1" into dominant and recessive levels for the CAN bus. After conversion, the bus interface device injects these physical levels into the vehicle's bus network in real time through its output, which is connected to the bus pins of the vehicle under test. The ICC recognizes the operation commands as input / output types and generates corresponding initial electrical signals through its internal digital input / output controller or analog output channel. For example, if the ICC requires "outputting a 5V high level," it outputs a 5V digital signal through its general-purpose input / output pins, or generates an analog voltage signal in the 0-5V range through a digital-to-analog converter module, and sends these signals to the hardwired signal interface device connected to its hardwired pins. After receiving the input / output signals from the industrial control computer, the hard-wired signal interface device conditions and simulates the signals according to the actual electrical characteristics of the hard-wired interface of the vehicle under test.

[0041] The above-described embodiments of this application use the bus interface device 1031 and the hard-wired signal interface device 103 for input and output, and reasonably simulate and transmit signals.

[0042] To obtain accurate reception results, in some embodiments, the bus interface device 1031 is also used to collect the first bus signal emitted by the vehicle under test when the software package is running, and forward the first bus signal to the industrial control computer 101.

[0043] The hardwired signal interface device 1032 is also used to acquire the first hardwired signal emitted by the vehicle under test when the software package is running. The first hardwired signal is then forwarded to the industrial control computer 101.

[0044] In its implementation, the bus interface device continuously monitors the vehicle's bus network via its receiver, which is connected to the bus pins of the vehicle under test (VUTP). When the software package in the VUTP runs, the vehicle's various electronic control units (ECUs) send response messages via the bus. The bus transceiver of the bus interface device captures these physical level signals in real time and converts them back into digitized bus message data. During the acquisition process, the bus interface device decodes the signals according to a preset bus protocol, filters out noise during bus idle periods, extracts the complete message frame containing valid data, and temporarily stores this message frame in its internal buffer, thus completing the acquisition of the first bus signal. The bus interface device then transmits the first bus signal data temporarily stored in the buffer to the industrial control computer (ICC) in digital form via its transmitter, which is connected to the ICC's bus pins, according to the communication protocol agreed upon between the device and the ICC. During the forwarding process, the bus interface device may perform simple format encapsulation on the data, such as adding a timestamp or data length field, to ensure that the ICC can accurately identify the source and generation time of the signal.

[0045] Hardwire signal interface devices monitor voltage or current changes on the hardwires of a vehicle in real time through their input terminals, which connect to the hardwire pins of the vehicle under test. When the software package changes the output state of a hardwire pin, the built-in analog-to-digital converter and signal conditioning circuitry of the hardwire signal interface device immediately sample the signal. The conditioning circuitry first filters, isolates, and levels the input signal to remove possible high-frequency interference. Then, it converts the analog signal into a digital quantity and quantizes and encodes it with a certain precision, thereby converting the original hardwire physical signal into a digital value that can be recognized by the industrial control computer.

[0046] The hardwired signal interface device transmits the sampled and quantized first hardwired signal data to the industrial control computer via digital communication through its output terminal, which is connected to the hardwired pin of the industrial control computer. Similar to bus interface devices, the hardwired signal interface device may also attach necessary identification information during forwarding, such as the pin number to which the signal belongs and the signal type, so that the industrial control computer can accurately understand the meaning of the signal.

[0047] The above-described embodiments of this application obtain accurate reception results by acquiring the first bus signal emitted by the vehicle under test when the software package is running, and the hard-wired signal interface device acquiring the first hard-wired signal emitted by the vehicle under test when the software package is running.

[0048] In order to start testing at the appropriate time, in some implementations, the bus interface device 1031 is also used to listen to communication messages on the bus of the vehicle under test and upload the messages to the industrial control computer 101.

[0049] The industrial computer 101 is also used to determine whether the update is complete based on the communication message. If the update is complete, the industrial computer 101 sends the corresponding test signal to the vehicle under test through the interface device 103 based on the operation command, so that the software package in the vehicle under test can run.

[0050] In its implementation, the bus interface device keeps its built-in bus transceiver constantly active, continuously monitoring voltage changes on the bus, through its receiver connected to the bus pins of the vehicle under test. When communication activity occurs on the bus, the transceiver converts the physical layer differential or single-ended signals into digital logic levels. The bus protocol controller then decodes and reassembles the data stream according to the corresponding bus protocol to reconstruct a complete message frame. During this process, the bus interface device automatically filters out noise, error frames, and interference signals that do not conform to the protocol format when the bus is idle, temporarily storing only valid communication messages in its internal buffer. The bus interface device then uploads one or more communication messages stored in its internal buffer to the industrial control computer (ICC) in the form of data packets, according to a pre-established data transmission protocol between the device and the ICC, through its transmitter connected to the ICC bus pins. When encapsulating the uploaded data packets, the bus interface device adds precise timestamp information and the bus channel identifier of the message's origin to each message, ensuring that the ICC can reconstruct the complete timing and context of the vehicle bus communication based on this information.

[0051] The industrial control computer (ICC) continuously receives message data streams from the bus interface devices and calls its internal diagnostic protocol parsing module to perform in-depth analysis of each message. This parsing module extracts service identifiers, sub-function parameters, and response data from the messages according to a preset flashing process specification. The ICC determines the progress of the flashing process by monitoring specific types of diagnostic response messages. The ICC marks the software package update as complete in its internal state machine and then retrieves the corresponding operation instructions from the previously parsed and stored test case instruction set. Based on these operation instructions, the ICC generates corresponding bus signals or hardwired signals and sends them to the interface devices via their bus pins or hardwired pins. Upon receiving the signals, the interface devices convert them to physical or simulated levels as described above and inject them into the corresponding pins of the vehicle under test, thereby triggering the newly updated software package in the vehicle under test to start running and verify its functionality.

[0052] The above-described implementation method of this application involves monitoring communication messages on the bus of the vehicle under test (VUTD), uploading these messages to an industrial control computer, and then determining whether an update is complete based on the communication messages. If the update is complete, based on operation instructions, a corresponding test signal is sent to the VUTD via an interface device to run the software package in the VUTD and initiate testing at an appropriate time.

[0053] In order to accurately determine the time when the update is completed, in some implementations, the industrial control computer 101 is also used to parse the communication message and extract the version information in the communication message.

[0054] The industrial computer 101 is also used to determine that the update is complete when the version information meets the update conditions.

[0055] The industrial computer 101 is also used to re-acquire version information when the version information does not meet the update conditions.

[0056] In its implementation, the industrial control computer (ICC) receives raw message data streams from the bus interface device in real time via its communication port connected to the bus interface device. The ICC then invokes its internal pre-set diagnostic protocol stack to parse the received messages byte-by-byte according to the diagnostic services used in the current testing phase. This parsing process includes identifying the protocol header, destination address, source address, and data payload area in the message, and then extracting the software version information field from a specific offset position in the data payload area according to a predefined data format.

[0057] The industrial control computer (ICC) temporarily stores the extracted version information in its memory comparison register and retrieves the preset target version conditions from the locally stored test case configuration file. The ICC uses string comparison functions or numerical comparison logic to determine whether the current version information matches the target version conditions character by character or byte by byte. When the comparison result shows that the current version number is exactly equal to, greater than or equal to, or conforms to the regular expression rules of the target version, the ICC determines that the version information meets the update conditions. It then marks the update status of the controller as "completed" in its internal state machine and records the current time as the update completion time so that subsequent test steps can be initiated accordingly.

[0058] If the above comparison result is a mismatch, i.e., the current version information is lower than the target version, the format is incorrect, or a valid version is not obtained, the industrial control computer (ICC) will not execute the update completion flag. Instead, the ICC will start a retry counter and timer to check whether the current number of retries has exceeded the preset maximum retry threshold. If it has not exceeded the threshold, the ICC will automatically repackage the diagnostic request message for reading the version and send it again to the vehicle under test through the bus interface device, triggering the vehicle to report its software version again. The ICC will then enter a waiting state and repeat the parsing and comparison operations after receiving a new response message until the obtained version information meets the update conditions.

[0059] The above-described implementation method of this application involves using an industrial control computer to parse communication messages, extract version information from the communication messages, and then determine that the update is complete if the version information meets the update conditions. If the version information does not meet the update conditions, the version information is retrieved again to accurately determine the time when the update is complete.

[0060] To issue accurate instructions, in some implementations, the industrial control computer 101 is also used to read a preset test specification file and determine the test cases in the test specification file. The test cases are parsed to extract the corresponding operation instructions and expected results. Based on the operation instructions, the corresponding editing operation is determined. The editing instruction is then sent to the cloud server 102 according to the editing operation.

[0061] Cloud server 102 is also used to perform editing operations based on editing instructions.

[0062] In practical implementation, when the industrial control computer (ICC) initiates the automated testing process, it first retrieves a pre-stored test specification file from the local hard drive, solid-state drive, or network-attached storage via its file access interface. This file is typically in tabular or structured text format. The ICC identifies the file type based on its file extension and calls the corresponding parsing engine to scan and read the file content line by line and column by column. For each test case identified in the previous step, the ICC locates the key columns in that test case that define the test actions and judgment criteria using field mapping rules. The ICC reads the text content from the cells in these columns and uses natural language processing or regular expression matching technology to convert it into machine-executable instruction code and quantifiable result parameters.

[0063] The industrial control computer (ICC) transmits the parsed operation instructions to its internal instruction conversion module. This module maintains a mapping table that associates abstract test operation instructions with specific controller programming operations. The ICC determines, through table lookup, what type of edit request needs to be sent to the cloud server to execute the instruction—for example, whether it's requesting modification of specific parameters on a particular controller or requesting replacement of the entire firmware module. The ICC encapsulates the edit operation metadata determined in the previous step into a standard request message according to a pre-agreed secure communication protocol with the cloud server. This message typically includes an authentication token, a timestamp, the unique identifier of the vehicle under test, and the specific edit operation content. After encapsulation, the ICC sends the instruction message to the designated cloud server via the internet through its network interface. The cloud server continuously listens for connection requests from the ICC through its service interface. Upon receiving the edit instruction message from the ICC, it first decrypts and parses it to verify the ICC's identity and permissions. After successful verification, the cloud server extracts the edit operation content from the message and calls its backend software build and management system.

[0064] The above-described implementation method of this application involves reading a preset test specification file to determine test cases within the file. The test cases are then parsed to extract corresponding operation instructions and expected results. Based on the operation instructions, the corresponding editing operation is determined. An editing instruction is sent to the cloud server according to the editing operation, thereby executing the editing operation and issuing accurate instructions.

[0065] To accurately send the software package to the corresponding location, in some implementations, the cloud server 102 is also used to, upon receiving editing instructions, write and / or configure the software based on the editing instructions to obtain the software package. The software package is then distributed to the domain controller corresponding to the vehicle under test.

[0066] In its implementation, the cloud server continuously listens for and receives Hypertext Transfer Protocol (HTTP) security requests or Message Queuing Telemetry (MQT) messages from industrial control computers (ICCs) via the internet through its cloud-deployed front-end interface service. Upon receiving an edit command, the cloud server first invokes its authentication module to decrypt and verify the digital signature or access token in the message to confirm that the command originates from a legitimate ICC and has not been tampered with. After successful verification, the cloud server extracts the command payload data from the message and decodes the parameter fields in the payload using a pre-defined protocol parser to obtain the unique identifier of the vehicle under test, the type of the target domain controller, the type of edit operation to be performed, and the specific parameter values.

[0067] The cloud server passes the parsed edit operation type and target parameters to the software build module in its backend continuous integration and continuous deployment pipeline. Based on the instruction, this module determines whether to perform an operation at a different depth: software writing or software configuration. When the instruction requires parameter modification, the software build module checks out or copies a base software image or configuration file template corresponding to the target domain controller from the cloud server's code version control repository. Then, the module calls a parameter injection tool to precisely modify the corresponding variables in the configuration file according to the specific parameter values ​​carried in the instruction.

[0068] The cloud server associates the generated software package with its corresponding metadata and stores it in its distribution queue. Simultaneously, the cloud server calls its interface connected to the vehicle-to-everything (V2X) platform to query the test vehicle's current network connection status, online status, and its IP address or communication tunnel identifier. This confirms the vehicle is ready to receive software updates and establishes a communication session for the upcoming distribution task. Through the established long-term secure connection between the V2X platform and the test vehicle, the cloud server divides the prepared software package into multiple data blocks according to a pre-defined transmission protocol, such as using chunked transmission and breakpoint resumption mechanisms, and sends them sequentially to the vehicle's onboard communication terminal. After confirming that all data blocks of the entire software package have been successfully transmitted to the vehicle, the cloud server sends a flash activation command to the vehicle, instructing the onboard communication terminal to forward the received complete software package to the designated target domain controller and triggering the domain controller to enter flash mode in preparation for installation.

[0069] The embodiments described above in this application, upon receiving editing instructions, involve writing and / or configuring software based on those instructions to obtain a software package. The software package is then distributed to the domain controller corresponding to the vehicle under test. This ensures the software package is accurately sent to the appropriate location.

[0070] In some implementations, reference Figure 3 A vehicle testing method is provided, which is applied to a vehicle testing system as described above, and includes the following steps: S301 to S305.

[0071] S301: Read the preset test cases, parse the test cases to obtain the corresponding operation instructions and expected results, and obtain the corresponding editing instructions based on the operation instructions.

[0072] In practical implementation, when the industrial control computer (ICC) initiates the automated testing process, it retrieves a pre-defined test case file from local storage via its file input / output interface. This file is typically stored in tabular or structured text format. The ICC calls the corresponding parsing engine based on the file format, scanning the file content line by line and identifying each line as an independent test case. For each test case, the parsing engine uses predefined field mapping rules to locate the cell storing the test action and the cell storing the judgment criteria, extracting the text-based operation instructions and expected results. For example, the ICC extracts the operation instruction "send window raising command" and the expected result "window glass fully closed" from a test case. Subsequently, the ICC inputs the extracted operation instructions into its internal instruction conversion module. This module, based on a pre-defined mapping relationship, converts the abstract test operation instructions into editable instructions that can be recognized by the cloud server, containing the target controller identifier and specific operation parameters.

[0073] S302: Generate the corresponding software package based on the editing instructions and send the software package to the vehicle under test.

[0074] In its implementation, after receiving editing instructions from the industrial control computer, the cloud server first parses the instructions, extracting key information such as the target controller type, parameters to be modified, and their target values. The cloud server then transmits this parsed information to its backend software building system. This system executes corresponding software writing or configuration operations based on the instructions: when the instructions require parameter modification, the building system retrieves the corresponding controller's basic configuration file from the code repository and modifies the corresponding variables in the configuration file to the target values ​​using a parameter injection tool; when the instructions require software function updates, the building system pulls the latest source code branch, calls the compiler to compile and link, and generates a new executable file. After these operations are completed, the building system packages the generated files into a complete software package with a digital signature and version identifier. Once the software package is generated, the cloud server, through a secure communication link established with the vehicle under test via the vehicle networking platform, uses a chunked transmission and breakpoint resume mechanism to distribute the software package chunk by chunk to the vehicle's onboard communication terminal, and instructs the terminal to forward it to the corresponding domain controller.

[0075] S303: Based on the operation command, send the corresponding test signal to the vehicle under test to make the software package in the vehicle under test run.

[0076] In the specific implementation, after confirming that the software package has been successfully delivered to the vehicle under test, the industrial control computer retrieves the original operation command parsed in step S301. Based on the type of the command, the industrial control computer determines whether to send the test signal via the bus channel or the hardwired channel. If the operation command is a bus-type command, the industrial control computer generates the corresponding digital message through its internal bus controller and sends it to the bus interface device via its bus pins. If the operation command is a hardwired command, the industrial control computer outputs the corresponding level signal through its general purpose input / output pins and sends it to the hardwired signal interface device via its hardwired pins. After receiving the digital message, the bus interface device converts the message into a differential level conforming to the vehicle bus physical layer specification through its built-in transceiver and injects it into the vehicle's bus network. After receiving the level signal, the hardwired signal interface device converts the signal into a simulated voltage or current conforming to the electrical characteristics of the vehicle's hardwired interface through its signal conditioning circuit and outputs it to the vehicle's hardwired pins.

[0077] S304: Collect the running results of the software package in the vehicle under test.

[0078] In the specific implementation, after the test signal is injected, the software package in the vehicle under test begins to run and generates corresponding response outputs. The bus interface device continuously monitors the communication activity on the bus through its receiver connected to the vehicle bus. When it captures the response message generated by the software package, its bus transceiver converts the physical level into a digital message and temporarily stores it in an internal buffer. The hardwired signal interface device monitors the level changes on the hardwire in real time through its input terminal connected to the vehicle hardwire. When it detects the output signal generated by the software package, its signal conditioning circuit samples, filters, and performs analog-to-digital conversion on the signal, quantizing it into a digital value. Subsequently, the bus interface device and the hardwired signal interface device respectively upload the acquired digital message and the quantized digital value to the industrial control computer through their respective signal pins according to the communication protocol agreed upon with the industrial control computer.

[0079] S305: Compare the running results with the expected results to obtain the test results.

[0080] In its implementation, after receiving the actual execution results uploaded from the bus interface device and the hardwired interface device, the industrial control computer (ICC) temporarily stores them in the result register in memory. The ICC then retrieves the expected result obtained from the test case parsing in step S301 and calls its internal result comparison module to compare the actual result with the expected result item by item. The comparison operation varies depending on the result type: for numerical results, the comparison module compares the numerical values ​​to determine if they are within the allowable error range; for status results, the comparison module matches the logical states; for message results, the comparison module verifies each byte of the message. If all comparison items are consistent, the comparison module determines that the test case has passed; if there are inconsistencies, it is determined to have failed. After the determination is completed, the ICC summarizes the execution results of all test cases and generates a structured test report.

[0081] The above-described embodiments of this application, by ensuring the consistency and accuracy of each test execution, can effectively support the rapid iterative verification of software functions in the vehicle-cloud integrated scenario and improve testing efficiency.

[0082] As one implementation method, refer to Figure 4 The vehicle-cloud integrated SOA automated testing system consists of: a test cabinet, an industrial control computer, Python automated testing software, a programmable power supply, CANoe software, VN5650 / VN5620 interface devices, VT boards, and an SOA cloud backend.

[0083] The test cabinet provides power management, current protection, and emergency stop for the entire automated testing system. The industrial PC provides the runtime environment for Python automated testing programs and software such as CANoe. Simultaneously, through the industrial PC's network card, it can connect to the SOA cloud backend, enabling operation and control of the SOA cloud backend. The Python automated testing software uses Pytest to write automated test scripts. These scripts call the Playwright library to operate the SOA cloud backend, write SOA application software, and distribute it to the vehicle-side controller under test. The scripts also call CANoe software to send relevant bus signals, execute parts of the CAPL-written program, and monitor the bus signals and hardwired control signals sent by the vehicle-side controller. The programmable power supply is the input source for the power board in the VT board, providing constant power, constant ground, and wake-up signals to the test sample. VN5650 / VN5620 interface devices connect to the test sample to realize the monitoring and simulation functions of CAN / Ethernet bus data. Monitoring and simulation of SomeIP protocol data based on Ethernet also require this type of device. VT boards can provide power to the device under test (DUT); or simulate different types of switches and sensors to provide necessary I / O inputs to the DUT; or monitor the I / O outputs of the DUT to achieve monitoring of analog or digital I / O outputs. The SOA cloud backend provides a backend environment for SOA application software development, and application software edited during testing can be downloaded to the vehicle-side controller via the network.

[0084] The specific process of SOA automated testing for vehicle-cloud integration involves first connecting the power supply pins, input / output I / O pins, and CAN / Ethernet bus pins of the vehicle-side test component to the automated testing system; secondly, using CANoe software to build the vehicle-side test environment; thirdly, associating the CANoe project with the Python automated testing system, while ensuring the industrial control computer is properly connected to the network and the SOA cloud parameters are configured correctly; finally, running the Python automated testing program, reading the test specifications from an Excel or Word file, operating the SOA cloud backend to write application software according to the specifications, and sending it to the vehicle-side controller under test, while simultaneously sending operation commands to the CANoe software, sending relevant bus signals and I / O hardwire signals, triggering the application to start working, receiving and detecting whether the output of the vehicle-side test component meets the functional requirements of the application software.

[0085] Furthermore, in conjunction with the vehicle testing methods described in the above embodiments, this application embodiment can provide a computer storage medium for implementation. This computer storage medium stores computer program instructions; when these computer program instructions are executed by a processor, they implement any of the vehicle testing methods described in the above embodiments.

[0086] This application also provides a computer program product, including a computer program that, when executed, implements any of the vehicle testing methods described in the above embodiments.

[0087] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0088] The functional blocks shown in the above-described structural diagram can be implemented as hardware, software, firmware, or a combination thereof. When implemented in hardware, they can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. Programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave. "Machine-readable medium" can include any medium capable of storing or transmitting information. Examples of machine-readable media include electronic circuits, semiconductor memory devices, ROM, flash memory, erasable ROM (EROM), floppy disks, CD-ROMs, optical disks, hard disks, fiber optic media, radio frequency (RF) links, etc. Code segments can be downloaded via computer networks such as the Internet, intranets, etc.

[0089] It should also be noted that the exemplary embodiments mentioned in this application describe methods or systems based on a series of steps or apparatus. However, this application is not limited to the order of the above steps; that is, the steps can be performed in the order mentioned in the embodiments, or in a different order, or several steps can be performed simultaneously.

[0090] The aspects of this disclosure have been described above with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this disclosure. It should be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that these instructions, executable via the processor of the computer or other programmable data processing apparatus, enable the implementation of the functions / actions specified in one or more blocks of the flowchart illustrations and / or block diagrams. Such a processor can be, but is not limited to, a general-purpose processor, a special-purpose processor, a special application processor, or a field-programmable logic circuit. It is also understood that each block in the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can also be implemented by an FPGA performing the specified functions or actions, or can be implemented by a combination of an FPGA and computer instructions.

[0091] The above description is merely a specific implementation of this application. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, modules, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here. It should be understood that the protection scope of this application is not limited thereto. Any person skilled in the art can easily conceive of various equivalent modifications or substitutions within the technical scope disclosed in this application, and these modifications or substitutions should all be covered within the protection scope of this application.

Claims

1. A vehicle testing system, characterized in that, The vehicle testing system includes: An industrial control computer, a cloud server, and interface devices; the industrial control computer is connected to the interface devices and communicates with the cloud server; the cloud server communicates with the vehicle under test; the interface devices are connected to the vehicle under test. The industrial control computer is used to read preset test cases, parse the test cases to obtain corresponding operation instructions and expected results, and send editing instructions to the cloud server based on the operation instructions; The cloud server is used to generate a corresponding software package based on the editing instruction upon receiving the editing instruction, and to send the software package to the vehicle under test; The industrial control computer is also used to send corresponding test signals to the vehicle under test through the interface device based on the operation instructions, so as to make the software package in the vehicle under test run. The interface device is used to collect the running results of the software package in the vehicle under test and forward the running results to the industrial control computer; The industrial control computer is also used to compare the running results with the expected results to obtain test results.

2. The vehicle testing system according to claim 1, characterized in that, The interface device includes a bus interface device and a hard-wired signal interface device; the bus interface device is connected to the bus pins of the industrial control computer and the bus pins of the vehicle under test; the hard-wired signal interface device is connected to the hard-wired pins of the industrial control computer and the hard-wired pins of the vehicle under test. The industrial control computer is also used to determine the bus signals and input / output signals that need to be sent based on the operation instructions; The industrial control computer is also used to send the bus signal to the bus interface device and send the input / output signal to the hardwired signal interface device; The bus interface device is used to convert the bus signal into a physical level and then send it to the bus pin of the vehicle under test; The hardwired signal interface device is used to convert the input / output signal into a simulated signal and then output it to the hardwired pin of the vehicle under test.

3. The vehicle testing system according to claim 2, characterized in that, The bus interface device is also used to collect the first bus signal emitted by the vehicle under test when the software package is running; and to forward the first bus signal to the industrial control computer. The hardwired signal interface device is also used to collect the first hardwired signal emitted by the vehicle under test when the software package is running; and to forward the first hardwired signal to the industrial control computer.

4. The vehicle testing system according to claim 2, characterized in that, The bus interface device is also used to listen to communication messages on the bus of the vehicle under test and upload the messages to the industrial control computer. The industrial control computer is also used to determine whether the update is complete based on the communication message; if the update is complete, the industrial control computer sends a corresponding test signal to the vehicle under test through the interface device based on the operation instruction, so as to make the software package in the vehicle under test run.

5. The vehicle testing system according to claim 4, characterized in that, The industrial control computer is also used to parse the communication message and extract the version information in the communication message; The industrial control computer is also used to determine that the update is complete when the version information meets the update conditions; The industrial control computer is also used to re-acquire version information if the version information does not meet the update conditions.

6. The vehicle testing system according to claim 1, characterized in that, The industrial control computer is also used to read a preset test specification file, determine the test cases in the test specification file, parse the test cases, extract the corresponding operation instructions and expected results, and determine the corresponding editing operation based on the operation instructions. The editing command is sent to the cloud server according to the editing operation; The cloud server is also used to execute the editing operation according to the editing instructions.

7. The vehicle testing system according to claim 1, characterized in that, The cloud server is also used to, upon receiving the editing instruction, write and / or configure the software based on the editing instruction to obtain a software package; and to distribute the software package to the domain controller corresponding to the vehicle under test.

8. A vehicle testing method, characterized in that, The method is applied to the vehicle testing system as described in any one of claims 1 to 7, the method comprising: Read the preset test cases, parse the test cases to obtain the corresponding operation instructions and expected results, and obtain the corresponding editing instructions based on the operation instructions; The corresponding software package is generated based on the editing instructions, and the software package is sent to the vehicle under test. Based on the operation instructions, a corresponding test signal is sent to the vehicle under test to enable the software package in the vehicle under test to run. Collect the running results of the software package in the vehicle under test; The test results are obtained by comparing the running results with the expected results.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer program instructions that, when executed by a processor, implement the vehicle testing method as described in claim 8.

10. A computer program product, characterized in that, When the instructions in the computer program product are executed by the processor of the electronic device, the electronic device performs the vehicle testing method as described in claim 8.

Images