Platformization test method for automobile embedded software

Abstract

The invention relates to the technical field of automobile software testing, in particular to an automobile embedded software platformization testing method, which comprises the following steps of: S1, performing parameter configuration and peripheral equipment calling check on an ECU Test testing system; s2, generating a test case in combination with a predefined writing rule; s3, checking the generated test case; s4, creating an automatic test case used for being executed by the ECU Test test system; s5, the automatic test case is loaded to an ECU Test test system; s6, judging whether an existing item which is executing the automatic test case exists in the ECU Test test system or not; if yes, switching the existing item to a target item to be tested in a mode of modifying an item Mapping file signal mapping path; otherwise, importing the automatic test case into the to-be-tested target item; and S7, executing an automatic test case test of the target project through the HIL platform. According to the invention, the efficiency of the automobile embedded software platform test can be improved.

Description

Technical Field

[0001] This invention relates to the field of automotive software testing technology, and more specifically to a platform-based testing method for automotive embedded software. Background Technology

[0002] Against the backdrop of the deep integration of automotive intelligence and connectivity, the functional complexity of embedded software for automotive controllers has experienced explosive growth. From traditional engine control units (ECUs) and transmission control modules to autonomous driving domain controllers, intelligent cockpit systems, new energy MCU / BMS / VCU electronic control systems, and hybrid HCUs, software functions have deeply covered core areas such as vehicle operation control, human-machine interaction, and information communication.

[0003] The quality of software directly determines a vehicle's safety performance, driving experience, and market competitiveness; therefore, efficient and reliable testing methods are crucial for ensuring software quality. However, current testing processes still rely heavily on manual operation, which is insufficient to meet the rapid iteration needs of modern automotive software development.

[0004] Existing testing methods are mainly divided into two categories: basic manual testing and semi-automated testing. Basic manual testing is based on requirements documents, where testers analyze the functional logic line by line and manually write test cases, then perform manual testing. This process highly relies on the testers' experience and attention to detail, and is prone to logical deviations or incomplete coverage due to subjective judgment. Furthermore, the testing cycle is lengthy and difficult to adapt to the rapid pace of software updates. Semi-automated testing first develops test cases and then builds test sequences in an automated testing system, but its core bottleneck lies in the test case conversion stage. Testers must convert each manually written test case into a format recognizable by the automated system, requiring not only proficiency in multiple testing tools but also a huge workload.

[0005] During project switchover, when the test target changes from one project to another, the signal mapping paths in the test cases (such as the relationships between A2L variables, DBC bus signals, or Simulink model variables) need to be reconfigured according to the structure of the new project. This process relies on manual modification of test case content or related configuration files, which is not only cumbersome but also prone to mapping errors due to oversights, leading to test failures or data deviations. Especially in multi-project parallel development scenarios, frequent project switches trap testers in repetitive work, resulting in extremely low test case reuse rates and a significant amount of time wasted on ineffective configuration adjustments rather than core test verification.

[0006] In summary, existing technologies suffer from significant bottlenecks in both test case generation and project switching, two crucial stages. These issues not only hinder the improvement of testing efficiency but also indirectly affect the development speed and quality assurance capabilities of automotive software. Therefore, there is an urgent need for a solution that can automatically generate test cases and seamlessly switch projects to overcome the efficiency and reliability bottlenecks of the current testing process. Summary of the Invention

[0007] To address the shortcomings of the existing technologies, the technical problem this invention aims to solve is: how to provide a platform-based testing method for automotive embedded software that can automatically generate compliant test cases by combining predefined coding rules with test requirements, and simultaneously enable rapid switching to the project without modifying test cases by modifying the signal mapping paths in the project's Mapping file, thereby improving the efficiency of platform-based testing for automotive embedded software and ensuring the development speed and quality assurance capabilities of automotive software.

[0008] To solve the above-mentioned technical problems, the present invention adopts the following technical solution:

[0009] A platform-based testing method for automotive embedded software includes:

[0010] S1: Configure parameters and check peripheral device calls for the ECUTest test system, and connect it to the HIL platform;

[0011] S2: Obtain the required signals based on the user's testing needs, and generate test cases by combining them with predefined writing rules;

[0012] S3: Inspect the generated test cases;

[0013] S4: Based on the inspected test cases, create automated test cases for execution by the ECUTest test system;

[0014] S5: Load automated test cases into the ECUTest testing system;

[0015] S6: Determine if the ECUTest testing system has an existing project executing the automated test case: If yes, switch the existing project to the target project to be tested by modifying the signal mapping path in the project Mapping file; otherwise, import the automated test case into the target project to be tested.

[0016] S7: Execute automated test cases for the target project through the HIL platform.

[0017] Preferably, in step S1, configuring the parameters of the ECUTest test system includes: loading hardware configuration information, loading dbc files, FIU files, A2L files and / or HEX files, and configuring the test project.

[0018] Preferably, in step S1, the peripheral device call check of the ECUTest test system includes: checking whether the calls of peripheral hardware devices used in conjunction with the HIL platform are normal.

[0019] Preferably, in step S2, the predefined writing rules include writing format, keyword information, signal settings, signal reading, logical judgment and / or data processing;

[0020] The generated test cases include test case ID, test case description, initial conditions before test case execution, test steps, action description, waiting time, expected result, time expression and / or time parameter.

[0021] Preferably, in step S2, the signal types of the test cases include A2L software variables, dbc bus signals, and Simulink model variables;

[0022] The steps for determining the signal type of a test case include:

[0023] S201: Determine if the signal has the A2L keyword: if yes, determine if the signal is a software variable; otherwise, proceed to step S202.

[0024] S202: Determine if the signal exists in the IO.txt file. If it does, determine if the signal is a model variable; otherwise, proceed to step S203.

[0025] S203: The signal is determined to be a DBC bus signal.

[0026] Preferably, in step S3, checking the generated test cases includes:

[0027] Analyze the content of the test cases to determine whether the format, rules, and syntax of the test cases are correct.

[0028] Preferably, in step S3, checking the generated test cases includes:

[0029] Determine whether the signals involved in the test cases are system-defined signals.

[0030] Preferably, in step S6, the process of switching the existing project to the target project to be tested by modifying the signal mapping path in the project Mapping file includes:

[0031] S601: Determine the change signal from an existing project to a target project through database file relocation;

[0032] S602: Use an .exls table to mark the target items, record the names of the changing signals, and the corresponding signal path relationships;

[0033] S603: Load the target project's Mapping file and modify the signal names of the automated test cases in the Mapping file to the names in the .exls table;

[0034] S604: Adjust the mapping relationship of the Mapping file in the project configuration of the ECUTest test system, switch from the existing project to the target project, and load the automated test cases.

[0035] Preferably, in step S7, before executing the automated test cases of the target project through the HIL platform, the automated test cases of the target project are first subjected to syntax checks.

[0036] Preferably, in step S7, after executing the automated test cases of the target project through the HIL platform, a corresponding test report is generated based on the test execution results and real-time data.

[0037] Compared with existing technologies, the automotive embedded software platform testing method of this invention has the following advantages:

[0038] This invention parses user test requirements through predefined writing rules, automatically acquires and processes the required signal types (including A2L software variables, DBC bus signals, and Simulink model variables), and generates compliant test cases. This reduces the manual writing workload in traditional test case development and improves development efficiency. Furthermore, the test cases generated based on predefined rules are highly standardized and consistent, avoiding formatting errors and logical inconsistencies caused by human factors, ensuring the quality and reliability of the test cases. Moreover, it supports the identification and processing of multiple signal types, enhancing the applicability and flexibility of the test cases, laying a high-quality foundation for subsequent automated test execution, and effectively shortening the test preparation cycle.

[0039] This invention utilizes a systematic test case inspection mechanism to automatically verify whether the format, rules, and syntax of test cases conform to preset standards, ensuring the standardization and correctness of test cases. It can proactively identify and correct potential problems, avoiding test failures or misjudgments caused by test case defects, thereby improving the quality and reliability of test cases. Simultaneously, the created automated test cases can be directly executed in the ECUTest testing system, reducing manual conversion and debugging steps and improving the efficiency and accuracy of test execution.

[0040] This invention achieves rapid switching to the target project without modifying test cases by modifying the signal mapping path in the project's mapping file, significantly improving the efficiency of test environment switching. Traditional testing methods often require rewriting or modifying test cases when projects change. This method, however, automatically handles changes in signal mapping relationships through database file relocation and Excel spreadsheet marking of changed signals, avoiding repetitive test case modifications, reducing maintenance costs, improving test case reusability and efficiency, and allowing the same set of test cases to be applied to multiple different projects, reducing redundant investment in testing resources. Furthermore, the fast and reliable switching process ensures test continuity and consistency, providing efficient support for multi-project parallel testing of automotive embedded software, and enhancing the overall flexibility and efficiency of the testing process. Attached Figure Description

[0041] To make the objectives, technical solutions, and advantages of the invention clearer, the invention will now be described in further detail with reference to the accompanying drawings, wherein:

[0042] Figure 1 and Figure 2 The logical block diagram and test flowchart are for the platform-based testing method of automotive embedded software.

[0043] Figure 3 Create a logical block diagram of the system for platform-based test cases.

[0044] Figure 4 A logic diagram for project switching.

[0045] Figure 5 A logical flowchart for Jenkins continuous integration testing. Detailed Implementation

[0046] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. The components of the embodiments of the present invention described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present invention provided in the accompanying drawings is not intended to limit the scope of the claimed invention, but only to illustrate selected embodiments of the invention. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention without inventive effort are within the scope of protection of the present invention.

[0047] It should be noted that similar reference numerals and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In the description of this invention, it should be noted that the terms "center," "upper," "lower," "left," "right," "vertical," "horizontal," "inner," and "outer," etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the figures, or the orientation or positional relationship commonly used when the product is in use. They are only for the convenience of describing the invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on the invention. Furthermore, the terms "first," "second," and "third," etc., are only used to distinguish descriptions and should not be construed as indicating or implying relative importance. In addition, the terms "horizontal," "vertical," etc., do not mean that the component is required to be absolutely horizontal or suspended, but can be slightly tilted. For example, "horizontal" only means that its direction is more horizontal than "vertical," and does not mean that the structure must be completely horizontal, but can be slightly tilted. In the description of this invention, it should also be noted that, unless otherwise explicitly specified and limited, the terms "set," "install," "connect," and "link" should be interpreted broadly. For example, they can refer to a fixed connection, a detachable connection, or an integral connection; they can refer to a mechanical connection or an electrical connection; they can refer to a direct connection or an indirect connection through an intermediate medium; and they can refer to the internal connection of two components. Those skilled in the art can understand the specific meaning of the above terms in this invention based on the specific circumstances.

[0048] The following detailed explanation illustrates the specific implementation methods:

[0049] Example:

[0050] This embodiment discloses a platform-based testing method for automotive embedded software.

[0051] like Figure 1 and Figure 2 As shown, a platform-based testing method for automotive embedded software includes:

[0052] S1: Configure parameters and check peripheral device calls for the ECUTest test system, and connect it to the HIL platform;

[0053] S2: The platform-based test case creation system obtains the required signals based on the user's test needs and generates test cases in combination with predefined writing rules;

[0054] S3: The platform-based test case creation system checks the generated test cases;

[0055] S4: Based on the inspected test cases, create automated test cases for execution by the ECUTest test system;

[0056] In this embodiment, after the loaded test cases are checked for syntax and formatting errors, the system will automatically create test cases. The process no longer requires manual intervention, which can avoid system errors caused by human error.

[0057] S5: Load automated test cases into the ECUTest testing system;

[0058] S6: Determine if the ECUTest testing system has an existing project executing the automated test case: If yes, switch the existing project to the target project to be tested by modifying the signal mapping path in the project Mapping file; otherwise, import the automated test case into the target project to be tested.

[0059] S7: Execute automated test cases for the target project through the HIL platform.

[0060] This invention parses user test requirements through predefined writing rules, automatically acquires and processes the required signal types (including A2L software variables, DBC bus signals, and Simulink model variables), and generates compliant test cases. This reduces the manual writing workload in traditional test case development and improves development efficiency. Furthermore, the test cases generated based on predefined rules are highly standardized and consistent, avoiding formatting errors and logical inconsistencies caused by human factors, ensuring the quality and reliability of the test cases. Moreover, it supports the identification and processing of multiple signal types, enhancing the applicability and flexibility of the test cases, laying a high-quality foundation for subsequent automated test execution, and effectively shortening the test preparation cycle.

[0061] This invention utilizes a systematic test case inspection mechanism to automatically verify whether the format, rules, and syntax of test cases conform to preset standards, ensuring the standardization and correctness of test cases. It can proactively identify and correct potential problems, avoiding test failures or misjudgments caused by test case defects, thereby improving the quality and reliability of test cases. Simultaneously, the created automated test cases can be directly executed in the ECUTest testing system, reducing manual conversion and debugging steps and improving the efficiency and accuracy of test execution.

[0062] This invention achieves rapid switching to the target project without modifying test cases by modifying the signal mapping path in the project's mapping file, significantly improving the efficiency of test environment switching. Traditional testing methods often require rewriting or modifying test cases when projects change. This method, however, automatically handles changes in signal mapping relationships through database file relocation and Excel spreadsheet marking of changed signals, avoiding repetitive test case modifications, reducing maintenance costs, improving test case reusability and efficiency, and allowing the same set of test cases to be applied to multiple different projects, reducing redundant investment in testing resources. Furthermore, the fast and reliable switching process ensures test continuity and consistency, providing efficient support for multi-project parallel testing of automotive embedded software, and enhancing the overall flexibility and efficiency of the testing process.

[0063] To better illustrate the technical solution of the present invention, this embodiment will be described in more detail through the following parts.

[0064] I. Parameter Configuration

[0065] In the specific implementation process, the parameter configuration of the ECUTest test system includes: loading hardware configuration information such as ControlDesk, INCA, PCAN, and TOSUN; loading dbc files, FIU files, A2L files, and HEX files; and configuring the test project (target test platform calls such as dSPACE, VT, LabCar, NI, etc.).

[0066] The goal of this invention for configuring parameters in the ECUTest testing system is to load test files into the ECUTest testing system, enabling the system to connect with the target HIL platform. The purpose of parameter configuration is to ensure the correct loading of various projects involved in the testing process before testing, such as host computer control software (ControlDesk, CANoe, VerStand, LabcarOperator, etc.), dbc database files, fault injection configuration files, etc.

[0067] II. Peripheral Device Call

[0068] In the specific implementation process, the peripheral device call check of the ECUTest test system includes checking whether the calls of peripheral hardware devices used in conjunction with the HIL platform are normal. Peripheral hardware devices include CANape, Pcan, INCA, IXXAT, TOSUN, SOFTING, J2534, etc. These devices are used to work with the HIL platform to perform tasks such as UDS diagnostics, ECU calibration, bus signal setting and reading.

[0069] The ECUTest test system requires auxiliary test equipment because the HIL platform itself interacts with the controller under test (DUT) via various I / O boards, such as digital boards, analog boards, resistor boards, and CAN / LIN / Ethernet bus boards. By running a Simulink controlled object model on an RTPC real-time machine to control these boards, a closed-loop control system can be formed with the DUT. However, the testing process may also involve UDS communication and calibration, requiring the use of other peripheral hardware devices in conjunction with the HIL test bench. These peripheral devices typically include INCA, PCAN, TOSUN, Vector, and CANApe.

[0070] Based on project requirements, a controlled object model was built using Matlab / Simulink. The model includes all the basic functions of the simulated ECU that interact with the controller under test, such as the MCU motor model, BMS battery management system model, VCU / HCU vehicle control model, engine model, reducer model, and vehicle dynamics model. After compilation, the model is downloaded to the target processor RTPC real-time machine. Electrical signals are transmitted through the processor module and various I / O boards, enabling Simulink to control these supporting I / O boards. The channels of the I / O boards are then connected to the pins of the controller under test, thus achieving closed-loop control of the controller.

[0071] The ECUTest testing software loads the target file and test project compiled by Simulink, and synchronously calls auxiliary peripheral hardware devices to set and read bus signals, hard-wired signals, and internal software variables, as well as perform logical judgments.

[0072] III. Platform-based Test Case Creation System

[0073] In the specific implementation process, the predefined writing rules include writing format, keyword information, signal settings, signal reading, logical judgment and / or data processing;

[0074] Specifically, the test cases generated by the platform-based test case creation system include test case ID, test case description, initial conditions before test case execution, test steps, action description, waiting time, expected result, time expression and / or time parameter.

[0075] The test cases are shown in the table below:

[0076]

[0077] Test Case ID refers to the name of each test case after its creation. Test Case Description is a basic description based on the functional requirements, providing an overview of the test case. Initial Conditions Before Execution refers to the initial environment required for each test case to ensure its execution. Test Steps indicates the current step of the test case and the total number of steps. Action Description describes the actions to be performed at each step. Waiting Time refers to the waiting time (in seconds) after each action is completed. Expected Result refers to the expected test result after each action; if the result matches the expected result, the test passes; otherwise, it fails. The time-based expression has two parameters: 'still' represents the minimum expected duration of the result, and 'untill' represents the expected result within a certain timeframe.

[0078] This invention generates test cases by intelligently identifying all information related to test cases, such as the user's testing purpose, testing actions, logical judgments, and initial conditions.

[0079] The signal types for test cases include A2L software variables (variables that INCA can manipulate), dbc bus signals (all variables in the dbc file), and Simulink model variables (constant values ​​in Simulink).

[0080] In this invention, the purpose of obtaining the required signals and their corresponding types based on the user's testing needs is to automatically distinguish the interface call methods of the signals according to their types, ensuring that the generated test cases can be executed correctly, while also achieving test case generalization and cross-project adaptability. During HIL testing, three types of signals are involved: DBC bus signals, Simulink model signals, and A2L software variables. Once the type of the current signal is identified, the background automatically calls the corresponding interface to perform signal injection or reading operations. For example, if the current signal is identified as an A2L software variable, the variable is directly found in the A2L file and the desired operation is performed.

[0081] Specifically, the processing steps for determining the signal type of a test case include:

[0082] S201: Determine if the signal has the A2L keyword: if yes, determine if the signal is a software variable; otherwise, proceed to step S202.

[0083] S202: Determine if the signal exists in the IO.txt file. If it does, determine if the signal is a model variable; otherwise, proceed to step S203.

[0084] S203: The signal is determined to be a DBC bus signal.

[0085] This invention automatically identifies and classifies signal types (including A2L software variables, DBC bus signals, and Simulink model variables) in test cases through predefined rules, effectively avoiding the subjectivity and error risk of manual judgment, improving the efficiency of test case development, reducing repetitive verification work in the signal type processing stage, and ensuring the standardization and consistency of signal processing in test cases.

[0086] IV. Check the test cases

[0087] In practice, the platform-based test case creation system was independently developed using Python, with the aim of automating test case creation. For example... Figure 3 As shown, this platform-based test case creation system can intelligently identify potential errors or syntax errors in test case design. If an anomaly is detected, a prompt message will appear to quickly locate the cause of the problem and facilitate test case modification; otherwise, it will automatically create executable automated test cases.

[0088] Specifically, checking the generated test cases includes:

[0089] The system parses the test cases to determine if their format, rules, and syntax are correct. For example, it checks for Chinese characters, correct signal settings, and whether the expected results are correct. If an exception occurs, the system prints error messages, indicating the location of the exception and a basic description of the cause, helping testers quickly pinpoint the problem and escalate the test cases.

[0090] Determine whether the signals involved in the test cases are system-defined signals. Signals are divided into three categories: model variables (constant values ​​in Simulink), software variables (variables that can be manipulated by INCA), and bus signals (all variables in the DBC file). If the signal in the test case does not belong to any of these three categories, the system will exit and print an exception message to the user to help locate the cause of the problem and upgrade and maintain the test case; otherwise, continue with the following actions.

[0091] V. Project Switching

[0092] In practice, the automated testing platform can quickly switch between test cases for different projects. Often, when switching from project A to project C, only the signal names are changed, while the internal software logic remains the same. In such cases, the automated testing platform can intelligently identify which signals have been modified, thus enabling rapid replacement of signal names and path mappings.

[0093] Different platform-based projects can be quickly switched without requiring testers to adjust test cases, thus shortening the project's test and development cycle. In this invention, when the dbc file or Simulink controlled object model is updated, as long as the controller's software logic remains unchanged, the project can be directly migrated and automated testing can be carried out by modifying the signal mapping path in the Mapping file through a rapid test signal mapping method.

[0094] Combination Figure 4 As shown, the steps to switch an existing project to the target project to be tested by modifying the signal mapping path in the project's Mapping file include:

[0095] S601: Determine the change signal from an existing project to a target project through database file relocation;

[0096] S602: Use an .exls table to mark the target items, record the names of the changing signals, and the corresponding signal path relationships;

[0097] S603: Load the target project's Mapping file and modify the signal names of the automated test cases in the Mapping file to the names in the .exls table;

[0098] S604: Adjust the mapping relationship of the Mapping file in the project configuration of the ECUTest test system, switch from the existing project to the target project, and load the automated test cases.

[0099] This invention enables rapid switching of the test environment without adjusting test case content by modifying the signal mapping paths in the project's Mapping file. This reduces test maintenance costs during project changes, improves test case reusability, and allows the same set of test cases to be flexibly applied to different target projects, reducing redundant development and debugging workload. Simultaneously, automation simplifies the test environment switching operation, improving the efficiency and flexibility of test execution.

[0100] VI. Automated Testing

[0101] In practice, before executing automated test cases for the target project through the HIL platform, a syntax check is performed on the automated test cases for the target project. If an exception is found, the test system exits and prints an error message to help locate the cause of the problem and upgrade / maintain the test cases; otherwise, the following actions continue.

[0102] After executing automated test cases for the target project through the HIL platform, corresponding test reports are generated based on the test execution results and real-time data. Test report generation and data post-processing involve automatically creating reports according to customized templates after test case execution, and performing data post-processing on the collected data during the test process based on the test case settings. This primarily involves comparing the trend of signal changes with the expected results; if the trends match, the test report is considered successful; otherwise, it fails.

[0103] Specifically, test execution can be triggered through Jenkins, and the entire process can be fully automated. Jenkins calls test projects and test cases such as A / B / C, enabling 24 / 7 unattended testing, improving work efficiency, reducing the testing burden on personnel, shortening project development time, and accelerating project development progress.

[0104] like Figure 5 As shown, the Jenkins continuous integration testing platform automatically loads test projects based on the project under test and automatically connects auxiliary equipment needed during the testing process, forming continuous integration and testing capabilities. The purpose of introducing Jenkins is to accelerate continuous iterative testing of software. Test cases and project files are packaged and uploaded to the SVN system. Jenkins acts as the scheduling center, downloading the test project from SVN, calling the ECUTest testing software via ComAPI, connecting to auxiliary testing hardware, executing tests, generating reports, and finally automatically uploading the test reports to SVN.

[0105] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit the technical solutions. Those skilled in the art should understand that any modifications or equivalent substitutions to the technical solutions of the present invention without departing from the spirit and scope of the present invention should be covered within the scope of the claims of the present invention.

Claims

1. A platform-based testing method for automotive embedded software, characterized in that, include: S1: Configure parameters and check peripheral device calls for the ECUTest test system, and connect it to the HIL platform; S2: Obtain the required signals based on the user's testing needs, and generate test cases by combining them with predefined writing rules; S3: Inspect the generated test cases; S4: Based on the inspected test cases, create automated test cases for execution by the ECUTest test system; S5: Load automated test cases into the ECUTest testing system; S6: Determine if the ECUTest testing system has an existing project executing the automated test case: If yes, switch the existing project to the target project to be tested by modifying the signal mapping path in the project Mapping file; otherwise, import the automated test case into the target project to be tested. S7: Execute automated test cases for the target project through the HIL platform.

2. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S1, configuring the parameters of the ECUTest test system includes: loading hardware configuration information, loading dbc files, FIU files, A2L files and / or HEX files, and configuring the test project.

3. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S1, the peripheral device call check of the ECUTest test system includes checking whether the calls of peripheral hardware devices used in conjunction with the HIL platform are normal.

4. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S2, the predefined writing rules include writing format, keyword information, signal settings, signal reading, logical judgment and / or data processing; The generated test cases include test case ID, test case description, initial conditions before test case execution, test steps, action description, waiting time, expected result, time expression and / or time parameter.

5. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S2, the signal types of the test cases include A2L software variables, dbc bus signals, and Simulink model variables; The steps for determining the signal type of a test case include: S201: Determine if the signal has the A2L keyword: if yes, determine if the signal is a software variable; otherwise, proceed to step S202. S202: Determine if the signal exists in the IO.txt file. If it does, determine if the signal is a model variable; otherwise, proceed to step S203. S203: The signal is determined to be a DBC bus signal.

6. The automotive embedded software platform testing method as described in claim 1, characterized in that: Step S3 involves checking the generated test cases, including: Analyze the content of the test cases to determine whether the format, rules, and syntax of the test cases are correct.

7. The automotive embedded software platform testing method as described in claim 1, characterized in that: Step S3 involves checking the generated test cases, including: Determine whether the signals involved in the test cases are system-defined signals.

8. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S6, the process of switching the existing project to the target project to be tested by modifying the signal mapping path in the project Mapping file includes: S601: Determine the change signal from an existing project to a target project through database file relocation; S602: Use a table to mark the target items, record the names of the changing signals, and the corresponding signal path relationships; S603: Load the target project's Mapping file and modify the signal names of the automated test cases in the Mapping file to the names in the table; S604: Adjust the mapping relationship of the Mapping file in the project configuration of the ECUTest test system, switch from the existing project to the target project, and load the automated test cases.

9. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S7, before executing the automated test cases of the target project through the HIL platform, the automated test cases of the target project are first checked for syntax.

10. The automotive embedded software platform testing method as described in claim 1, characterized in that: In step S7, after executing the automated test cases of the target project through the HIL platform, a corresponding test report is generated based on the test execution results and real-time data.

Images