RTE interface requirement verification methods, devices, electronic equipment, and storage media

Abstract

This application relates to a method, apparatus, electronic device, and storage medium for verifying RTE interface requirements, comprising: verifying a second functional requirement list imported into the project based on a first functional requirement list from the requester, obtaining a first comparison result; comparing and verifying the second functional requirement list with an onboard bus communication database file and a general configuration file, obtaining a second comparison result; verifying the RTE interface in the general configuration file according to preset verification rules, obtaining a third comparison result; comparing the target RTE interface with the integrated RTE interface in the code project, obtaining a fourth comparison result; and generating a test report based on the comparison results. This method, in the integration testing phase, first automates the comparison and verification of requirements and inputs, ensuring accurate alignment of source input items. It can perform layer-by-layer verification of RTE interfaces according to verification categories, raising issues at each level, and improving the comprehensiveness and efficiency of RTE interface verification.

Description

Technical Field

[0001] This application relates to the field of RTE interface testing technology, specifically to an RTE interface requirement verification method, apparatus, electronic device, and storage medium. Background Technology

[0002] Automotive Open System Architecture (AUTOSAR) is a development framework for automotive electronic systems. It standardizes and encapsulates the underlying software of the Electronic Control Unit (ECU), allowing developers to use a single set of underlying software. Typically, developers only need to modify certain parameters to accommodate different hardware and application-level software. AUTOSAR decouples the Basic Software (BSW) and Application Software (ASW), enabling application software development independent of hardware. To facilitate interaction between the ASW and BSW, the communication interface of the Run-Time Environment (RTE) needs to be configured to ensure correct and reliable data transmission. The RTE interface, defined in the AUTOSAR standard, is primarily used for communication between Software Components (SWCs) and the Microcontroller Abstraction Layer (MCAL). Software integration involves connecting the interfaces of each SWC, generating AUTOSAR code, and compiling the software.

[0003] With the increasingly widespread application of the AUTOSAR software architecture in the automotive field, ECU version integration can now achieve rapid iteration. The Vehicle Interface Unit (VIU) is a controller that integrates body functions, vehicle electric drive functions, air conditioning control functions, and electronic suspension functions. Since the VIU domain controller is the core domain controller of the vehicle, current methods directly test the RTE interfaces within the code. For interfaces that fail to test, the reasons for failure are varied, such as issues with RTEMapping maintenance, signal problems in CAN and LIN messages, application model problems, integration problems, and underlying software issues. Furthermore, debugging must proceed sequentially upwards from the code level, combined with requirements analysis for final location. This reverse operation cannot efficiently discover, locate, and resolve the root cause of the problem. Summary of the Invention

[0004] To solve the above-mentioned technical problems, or at least partially solve them, this application provides an RTE interface requirement verification method, apparatus, electronic device, and storage medium.

[0005] Firstly, this application provides a method for verifying RTE interface requirements, the method comprising:

[0006] The first functional requirement list from the demand side is used to verify the second functional requirement list imported by the project, and the first comparison result is obtained.

[0007] If the first comparison result characterization verification is passed, the second functional requirement list is compared and verified with the vehicle bus communication database file, and the second functional requirement list is compared and verified with the general configuration file to obtain the second comparison result;

[0008] If the comparison verification between the second comparison result representing the second functional requirement list and the general configuration file is successful, the RTE interface in the general configuration file is verified according to the preset verification rules to obtain a third comparison result; wherein, the third comparison result includes the target RTE interface that has been verified.

[0009] The target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, thus obtaining the fourth comparison result;

[0010] A test report is generated based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

[0011] Optionally, the second functional requirement list imported into the project is verified based on the first functional requirement list from the requester to obtain a first comparison result, including:

[0012] Retrieve the first functional requirement list file from the requester in the version control system and store it in the first target address;

[0013] Obtain the second functional requirements list file imported by the project and store it in the second target address;

[0014] By comparing the first functional requirements list file in the first target address with the second functional requirements list file in the second target address, a first comparison result is obtained.

[0015] Optionally, the vehicle bus communication database file includes DBC files and LDF files;

[0016] The second functional requirement list is compared and verified with the vehicle bus communication database file, including:

[0017] Verify whether the data format and data transmission direction in the second functional requirement list conform to the preset rules, and use the signal data that passes the verification as the third functional requirement list.

[0018] Obtain signal data from the DBC file;

[0019] The signal data in the third functional requirement list is compared with the signal data in the DBC file to obtain the fifth comparison result;

[0020] Obtain the signal data from the LDF file;

[0021] The signal data in the third functional requirements list is compared with the signal data in the LDF file to obtain the sixth comparison result.

[0022] Optionally, a comparison and verification of the second functional requirements list and the general configuration file is performed, including:

[0023] Determine the first RTE interface set corresponding to the third functional requirement list;

[0024] The general configuration file is parsed using a script to generate a second RTE interface set;

[0025] Identify the RTE interfaces that exist simultaneously in both the first RTE interface set and the second RTE interface set, and generate a seventh comparison result;

[0026] The fifth comparison result, the sixth comparison result, and the seventh comparison result are used as the second comparison result.

[0027] Optionally, the preset verification rules include at least one of the following rules:

[0028] If the read interface and the write interface appear in pairs, and both the read interface and the write interface have mappings, then the verification result is failure;

[0029] If the read interface and the write interface appear in pairs, the read interface has a mapping, the write interface does not have a mapping, and the read interface does not use the RTE variable, then the verification result is failure.

[0030] If the read interface and the write interface appear in pairs, and there is no mapping between the read interface and the write interface, then the verification result is passed;

[0031] If the read interface and the write interface appear in pairs, and the read interface has no mapping while the write interface has a mapping, then the verification result is passed;

[0032] If the read interface does not have a corresponding write interface, but the read interface has a mapping, then the verification result is passed;

[0033] If the read interface does not have a corresponding write interface, and the read interface is not mapped, the verification result will be failure.

[0034] If the write interface does not have a corresponding read interface, but the write interface has a mapping, then the verification result is passed;

[0035] If the write interface does not have a corresponding read interface and the write interface is not mapped, the verification result is that an alarm is required.

[0036] If multiple write interfaces write to the same variable, the verification result will be a failure.

[0037] Optionally, the target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, resulting in a fourth comparison result, including:

[0038] Obtain the integrated RTE interface in the code project;

[0039] Verify that the target RTE interface exists in the integrated RTE interface;

[0040] If it exists, the verification result is "passed".

[0041] If it does not exist, the verification result is failure;

[0042] The verification results of all the target RTE interfaces are used as the fourth comparison result.

[0043] Optionally, a test report is generated based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result, including:

[0044] Obtain a service list and a service list component table; wherein, the service list is used to indicate the included hierarchical services and the interfaces under the hierarchical services; the service list component table is used to mark the component names corresponding to the service list;

[0045] The first comparison result, the second comparison result, the third comparison result, and the fourth comparison result are summarized, and a test report is generated according to the service list and the service list component table.

[0046] Get the API whitelist;

[0047] If the first interface that failed to be characterized in the test report belongs to the interface whitelist, then the first interface will be stored in the list of interfaces whose characterization results have been confirmed.

[0048] Secondly, this application provides an RTE interface requirement verification device, the device comprising:

[0049] The first verification module is used to verify the second functional requirement list imported by the project based on the first functional requirement list from the requester, and obtain the first comparison result.

[0050] The second verification module is used to perform a comparison verification between the second functional requirement list and the vehicle bus communication database file, and a comparison verification between the second functional requirement list and the general configuration file, when the first comparison result characterization verification is passed, to obtain a second comparison result.

[0051] The third verification module is used to verify the RTE interface in the general configuration file according to a preset verification rule when the comparison verification between the second comparison result representing the second functional requirement list and the general configuration file passes, and to obtain a third comparison result; wherein, the third comparison result includes the target RTE interface that has passed the verification.

[0052] The fourth verification module is used to compare the target RTE interface with the integrated RTE interface in the code project, detect whether the target RTE interface is integrated, and obtain the fourth comparison result;

[0053] The generation module is used to generate a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

[0054] Thirdly, this application provides an electronic device, including a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus;

[0055] Memory, used to store computer programs;

[0056] When a processor executes a program stored in memory, it implements the steps of the RTE interface requirement verification method described in any embodiment of the first aspect.

[0057] Fourthly, this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the RTE interface requirement verification method as described in any embodiment of the first aspect.

[0058] The beneficial effects of this application are:

[0059] The method provided in this application verifies a second functional requirement list imported into the project based on a first functional requirement list from the requester, obtaining a first comparison result. If the first comparison result indicates successful verification, the second functional requirement list is compared with the vehicle bus communication database file and with a general configuration file, obtaining a second comparison result. If the second comparison result indicates successful verification of the comparison between the second functional requirement list and the general configuration file, the RTE interface in the general configuration file is verified according to preset verification rules, obtaining a third comparison result. The third comparison result includes the verified target RTE interface. The target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, obtaining a fourth comparison result. A test report is generated based on the first, second, third, and fourth comparison results. This method automates the comparison verification of requirements and inputs during the integration testing phase, ensuring accurate alignment of source input items. It can verify RTE interfaces layer by layer according to verification categories, raising issues at each level and improving the comprehensiveness and efficiency of RTE interface verification. Attached Figure Description

[0060] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0061] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0062] Figure 1 A system architecture diagram of an RTE interface requirement verification method provided in one embodiment of this application;

[0063] Figure 2 A flowchart illustrating an RTE interface requirement verification method provided in one embodiment of this application;

[0064] Figure 3 A flowchart illustrating an RTE interface requirement verification method provided in one embodiment of this application;

[0065] Figure 4 A schematic diagram of an input file list provided for one embodiment of this application;

[0066] Figure 5A flowchart for verifying the correctness of RTEMapping pull is provided as an embodiment of this application;

[0067] Figure 6 A flowchart of RTEMapping and database comparison verification is provided as an embodiment of this application;

[0068] Figure 7 A flowchart illustrating the comparison and verification of RTEMapping and ARXML is provided as an embodiment of this application;

[0069] Figure 8 A flowchart illustrating the RTE interface verification process in an application model ARXML, provided as an embodiment of this application;

[0070] Figure 9 A flowchart of RTE interface integration verification is provided as an embodiment of this application;

[0071] Figure 10 This application provides a schematic diagram illustrating the classification and summarization of test results in one embodiment.

[0072] Figure 11 This is a schematic diagram of the structure of an RTE interface requirement verification device provided in one embodiment of this application;

[0073] Figure 12 This is a schematic diagram of the structure of an electronic device provided in one embodiment of this application. Detailed Implementation

[0074] The embodiments of this application will be described below with reference to the accompanying drawings and preferred embodiments. Those skilled in the art can easily understand other advantages and effects of this application from the content disclosed in this specification. This application can also be implemented or applied through other different specific embodiments, and various details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this application. It should be understood that the preferred embodiments are only for illustrating this application and are not intended to limit the scope of protection of this application.

[0075] The first embodiment of this application provides an RTE interface requirement verification method, which can be applied to, for example... Figure 1 The system architecture shown includes at least a comparison and verification module 101 and a test report generation module 102, which establish a communication connection. Specifically, this system architecture can be a vehicle, and the type of vehicle is not limited, such as a gasoline-powered vehicle, a pure electric vehicle, a hybrid vehicle, or a fuel cell vehicle, etc.

[0076] Next, based on this system architecture, the method for verifying the requirements of the RTE interface will be described in detail, such as... Figure 2 The RTE interface requirement verification method includes:

[0077] Step 201: Verify the second functional requirement list imported by the project based on the first functional requirement list from the demand side to obtain the first comparison result.

[0078] In one specific embodiment, the flowchart of the RTE interface requirement verification method is as follows: Figure 3 This system can be applied to automated testing systems. The automated testing system sequentially performs the following checks: importing and verifying the Functional Requirements List (RTEMapping); verifying whether the RTEMapping pulled from the code project by the integration development team meets the client's expectations; comparing and verifying RTEMapping with the vehicle bus communication database file (also referred to as the database file, including DBC and LDF files); comparing and verifying RTEMapping with the application model's general configuration file ARXML; verifying the RTE interface rules in the application model's general configuration file ARXML; verifying the integration of the RTE interface in the project code; and classifying and summarizing the test results to generate a test report.

[0079] In the AUTOSAR architecture, ECU controllers require multiple access checks before software integration. However, these checks are maintained independently by each party and lack horizontal alignment. For example, there are thousands of CAN and LIN signals, and tens of thousands of RTE interfaces in the application model, making manual comparison impossible. Therefore, this embodiment automates the comparison and verification of all requirements and inputs during the integration testing phase. This ensures accurate alignment of source inputs and effectively prevents functional failures caused by serious issues such as missing CAN and LIN signals. Through multi-level comparison and verification, top-down monitoring is achieved. The comparison results at each level are output and ultimately summarized. Therefore, the resulting test report can efficiently identify problems with the RTE interfaces.

[0080] In one specific embodiment, before performing import validation for RTEMapping, a list of input files for testing can be prepared first, as illustrated in the diagram below. Figure 4 This may include the RTEMapping form to be verified, database files, ARXML forms, and a service list assigning responsibility for locating failure items, as well as an SOA service component list. A brief explanation of these input files is as follows:

[0081] RTEMapping is a list of functional requirements for converting between onboard CAN / LIN signals and services. For example, RTEMapping may include fields such as FileName, SignalName, MessageName, Classification, Direction, SwcName, PortName, ElementName, and responsible person. It primarily identifies how each CAN / LIN message signal is transmitted and received via the interface "SwcName_PortName_ElementName". Specifically, when implementing a signal-to-service function, if the interface's Direction is set to receive, the RTE service interface is generated as RTE_READ; when implementing a service-to-signal function, if the interface's Direction is set to transmit, the RTE service interface is generated as RTE_WRITE.

[0082] The vehicle bus communication database file includes a DBC (Database Bus CAN) file and an LDF (LIN Description File) file. The DBC is the CAN database file, an XML format file used to define the Controller Area Network (CAN) bus communication protocol. The DBC file contains information such as CAN communication signals, message IDs, data lengths, and cycles. The LDF is the LIN database file, a file format used to describe the LIN bus communication protocol. The LDF file defines the communication parameters, signal definitions, and frame definitions of each node in the LIN network. Signals in the RTEMapping table should be synchronized and maintained in either the DBC or LDF.

[0083] ARXML tables, as a universal configuration file for automotive electronic systems, are considered a system description file in AUTOSAR and play a crucial role in data transmission and storage. An ARXML table is a list of ARXML files generated by parsing all ARXML files. It summarizes the RTE interfaces of all application models and includes fields such as ARXML name, variable, data type, RTE interface (P / R), and the presence / absence signal RTEMapping. The RTE interface (P / R) is the entry point for local and remote end to read and write variables or to send and receive receipts. Variables are the variables read and written to the corresponding RTE interface. The presence / absence signal RTEMapping indicates whether the interface is related to communication; the presence of RTEMapping indicates it is related to communication, while its absence indicates it is not.

[0084] The service list is a list of services designed based on the SOA service-oriented design principle. It includes all the services involved in each module and the interfaces under each service. Each service belongs to a different component.

[0085] The SOA service list component table marks the professional domain to which each component name belongs and the application development manager.

[0086] In one embodiment, the verification of the second functional requirement list imported by the project based on the first functional requirement list of the requester to obtain a first comparison result includes: pulling the first functional requirement list file of the requester from the version management system and storing it in a first target address; obtaining the second functional requirement list file imported by the project and storing it in a second target address; comparing the first functional requirement list file in the first target address with the second functional requirement list file in the second target address to obtain the first comparison result.

[0087] In this embodiment, the flowchart for verifying the correctness of the RTEMapping pull is as follows: Figure 5 Since the requester will provide the requirements to the version control system, the system can automatically pull the latest files under the newly created SVN tag (i.e., the first RTEMapping) from the RTEMapping module and save them to a specified directory, such as input\SVN. It can also pull the latest tag project files from the specified branch of the local Git repository (i.e., the second RTEMapping) and store the RTEMapping files imported into the project to a specified directory, such as input\Import. The system retrieves the RTEMapping files in the SVN directory, parses them to obtain the RTE interface set S0, and retrieves the RTEMapping files in the Import directory, parses them to obtain the RTE interface set S1. Sets S0 and S1 are compared. If the RTE interface only exists in set S0, it means it exists in SVN but is not integrated into the VIU project, and the comparison result is FAIL. If the RTE interface only exists in set S1, it means it has been integrated into the VIU project but is not in SVN, and the comparison result is also FAIL. If it exists in both sets S0 and S1, the comparison result is PASS. The comparison results can be output in an Excel spreadsheet format. It should be understood that the first comparison result includes the FAIL or PASS results of all RTE interfaces contained in the second functional requirements list file. By comparing the two RTEMapping files in the SVN and Import directories, it can be determined whether the integration development team correctly obtained the RTEMapping files provided by the requester. In this embodiment, problems caused by incorrect RTEMapping retrieval can be located.

[0088] Step 202: If the first comparison result characterization verification is passed, perform a comparison verification between the second functional requirement list and the vehicle bus communication database file, and perform a comparison verification between the second functional requirement list and the general configuration file to obtain the second comparison result.

[0089] If the first comparison result characterization verification is successful, the comparison between RTEMapping and DBC files, RTEMapping and LDF files, and RTEMapping and ARXML can be performed to obtain the second comparison result.

[0090] In one embodiment, the comparison and verification of the second functional requirement list and the vehicle bus communication database file includes: verifying whether the data format and data transmission direction in the second functional requirement list conform to preset rules, and using the verified signal data as the third functional requirement list; obtaining the signal data of the DBC file; comparing the signal data in the third functional requirement list with the signal data of the DBC file to obtain a fifth comparison result; obtaining the signal data of the LDF file; and comparing the signal data in the third functional requirement list with the signal data of the LDF file to obtain a sixth comparison result.

[0091] In this embodiment, the flowchart for RTEMapping and database comparison verification is as follows: Figure 6 The preset rules include, for example, Rule 1 and Rule 2. Rule 1 requires that the relevant fields "SwcName", "PortName", and "ElementName" of the RTE interface are not empty. Meeting Rule 1 ensures that the CAN and LIN signals have been configured with corresponding service interfaces and that signal-to-service conversion has been performed. Rule 2 limits the sending direction to "SEND" or "RECEIVE". Meeting Rule 2 ensures the directionality of the service interface; SEND fulfills the service-to-signal conversion requirement, and RECEIVE fulfills the signal-to-service conversion requirement. The verified signal data is used as the third RTEMapping table for subsequent verification processes. Signal data that fails verification is output as a failure result to an Excel spreadsheet. Obtaining signal data from the DBC file involves acquiring messages and signals from the DBC. Specifically, the DBC file is imported and parsed, and the parsed data is grouped and stored according to the dimension fields CAN and message ID. The signal data in the RTEMapping table is compared with the signal data in the DBC. Redundant messages and signals in the DBC are not considered, based on the RTEMapping table. The comparison scenarios are shown in Table 1 below.

[0092] Table 1

[0093] Condition Message in DBC Signal in DBC result Reasons for failure 1 Does not exist Does not exist FAIL The message is not in DBC 2 exist Does not exist FAIL The signal is not in DBC 3 exist exist PASS

[0094] Next, the signal data of the LDF file is obtained, such as the messages and signals in the LDF. The signal data in the RTEMapping table is compared with the signal data in the LDF. Based on RTEMapping, redundant messages and signals in the LDF are not required. In this embodiment, problems in the comparison process with the database can be located. The comparison scenarios are shown in Table 2 below:

[0095] Table 2

[0096] Condition Message in LDF Signal in LDF result Reasons for failure 1 Does not exist Does not exist FAIL The message is not in the LDF. 2 exist Does not exist FAIL The signal is not in the LDF 3 exist exist PASS

[0097] In one embodiment, the comparison and verification of the second functional requirement list and the general configuration file includes: determining the first RTE interface set corresponding to the third functional requirement list; generating the second RTE interface set by parsing the general configuration file through a script; determining the RTE interfaces that exist simultaneously in the first RTE interface set and the second RTE interface set, and generating a seventh comparison result; and using the fifth comparison result, the sixth comparison result, and the seventh comparison result as the second comparison result.

[0098] In this embodiment, signal data whose data format and data transmission direction conform to preset rules from the second functional requirement list are used as RTEMapping for comparison and verification with the general configuration file. The flowchart of RTEMapping and ARXML comparison and verification is as follows. Figure 7 The application model ARXML file in the project is parsed using a script to generate an ARXML RTE interface summary list set S2. Set S2 contains the ARXML name, variables, data type, RTE interface (P / R), and whether the signal RTEMapping exists. The presence of the signal RTEMapping indicates whether the interface is related to communication. The RTE interface set S1 in the RTEMapping table is compared with the ARXML list set S2. Based on the data in the RTEMapping table, the value of the field "whether the signal RTEMapping exists" in the ARXML list is retrieved as TRUE or FALSE. TRUE means that the signal exists in RTEMapping, and FALSE means that the signal does not exist in RTEMapping. In this embodiment, problems in the comparison and verification with ARXML can be located, as shown in Table 3 below:

[0099] Table 3

[0100] Condition Set S1 Vs Set S2 result Reasons for failure 1 Only exists in S1 FAIL The interfaces in the mapping table are not present in ARXML. 2 Simultaneously exists in S1 and S2 PASS Note: The model is implemented according to requirements.

[0101] Step 203: If the comparison verification between the second comparison result and the second functional requirement list and the general configuration file is successful, the RTE interface in the general configuration file is verified according to the preset verification rules to obtain the third comparison result; wherein, the third comparison result includes the target RTE interface that has been verified.

[0102] In this embodiment, the verified target RTE interface can also be called the requirement RTE interface. The RTE interface verification flowchart in the application model ARXML is as follows: Figure 8 First, the application model ARXML file in the project is parsed by a script to generate an ARXMLRTE interface summary list set S2. The RTE interfaces in the application model ARXML are then verified on the list set S2. The preset verification rules are shown in Table 4 below.

[0103] Table 4

[0104]

[0105] Similarly, the failure result can be output in tabular form. In this embodiment, the problem in the RTE interface verification can be located.

[0106] Step 204: Compare the target RTE interface with the integrated RTE interface in the code project to check whether the target RTE interface is integrated, and obtain the fourth comparison result.

[0107] In one embodiment, the target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and a fourth comparison result is obtained. This includes: obtaining the integrated RTE interface in the code project; verifying whether the target RTE interface exists in the integrated RTE interface; if it exists, the verification result is passed; if it does not exist, the verification result is failed; and using the verification results of all target RTE interfaces as the fourth comparison result.

[0108] In this embodiment, the RTE interface integration verification flowchart is as follows: Figure 9 The target RTE interfaces aligned through the aforementioned steps include two types: communication (COM) related interfaces and communication (COM) unrelated interfaces. COM-related interfaces have already undergone database comparison and ARXML comparison in the previous steps, and have passed ARXML rule validation; non-COM-related interfaces have passed ARXML validation. Whether the target RTE interface has been integrated can be determined based on the integrated RTE interfaces in the code project. For example, using the target RTE interface as a benchmark, the existence of integrated RTE interfaces in the source code can be verified. If they exist, the verification result is passed; if they do not exist, the verification result is failed. In this embodiment, problems in RTE interface integration can be located.

[0109] Step 205: Generate a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

[0110] This method first automates the comparison and verification of requirements and inputs during the integration testing phase to ensure accurate alignment of source input items. It can then perform layer-by-layer verification of the RTE interface according to the verification category, raising questions at each level and improving the comprehensiveness and efficiency of RTE interface verification.

[0111] In one embodiment, generating a test report based on a first comparison result, a second comparison result, a third comparison result, and a fourth comparison result includes: obtaining a service list and a service list component table; wherein the service list is used to indicate the included hierarchical services and the interfaces under the hierarchical services; the service list component table is used to mark the component names corresponding to the service list; summarizing the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result, and generating a test report according to the service list and the service list component table; obtaining an interface whitelist; if the first interface that failed to be represented in the test report belongs to the interface whitelist, then the first interface is stored in the list of confirmed representation results.

[0112] In this embodiment, test results are categorized and summarized to facilitate the identification of failed test results into the corresponding teams and responsible persons. This allows requirement personnel, application developers, and integration developers at each stage to pinpoint their specific issues and implement corrective actions immediately. A diagram illustrating the categorization and summarization of test results is shown below. Figure 10 After summarizing all test results and generating test results for each module according to the service list and component list, separate test reports are generated for both failed and successful tests. An interface whitelist can be used to store failed interfaces that appear on the whitelist in the development confirmed results list. Finally, the final failed test results are submitted and tracked by team members and responsible persons to achieve a closed loop.

[0113] In any of the above embodiments, RTE interface requirement verification can be performed before RTE interface testing. RTE interface testing verifies whether the interface can normally read and write variables (non-communication RTE interface) and send and receive signals (communication RTE interface). The test result is either failure or success. Simply testing a large number of RTE interfaces (such as the current tens of thousands of interfaces) is quite time-consuming. If root cause analysis is added, the required input will increase, and the time consumption will multiply. Currently, RTE interface generation is generally done automatically using toolchains, and problems rarely occur at the generation end. Most interfaces that fail during RTE interface testing are found to have requirement alignment issues. Therefore, through the hierarchical requirement verification in this embodiment, failed RTE interfaces will not enter subsequent RTE interface verification. Only interfaces that pass the RTE requirement verification will ultimately enter RTE interface testing. RTE interface requirement verification can locate and filter problems arising upstream. The automated requirement verification system is highly efficient, typically producing results in just a few minutes, which is significantly more efficient than the several hours required for conventional RTE interface testing. Furthermore, RTE interfaces that have undergone RTE requirement verification generally do not exhibit problems during RTE interface testing, reducing the frequency of RTE interface testing during development and thus greatly improving development efficiency.

[0114] Based on the same technical concept, the second embodiment of this application provides an RTE interface requirement verification device, such as... Figure 11 The device includes:

[0115] The first verification module 1101 is used to verify the second functional requirement list imported by the project based on the first functional requirement list of the demand side, and obtain the first comparison result.

[0116] The second verification module 1102 is used to perform a comparison verification between the second functional requirement list and the vehicle bus communication database file, and a comparison verification between the second functional requirement list and the general configuration file, when the first comparison result characterization verification is passed, to obtain a second comparison result.

[0117] The third verification module 1103 is used to verify the RTE interface in the general configuration file according to a preset verification rule when the comparison verification between the second comparison result representing the second functional requirement list and the general configuration file is passed, and to obtain a third comparison result; wherein, the third comparison result includes the target RTE interface that has been verified.

[0118] The fourth verification module 1104 is used to compare the target RTE interface with the integrated RTE interface in the code project, detect whether the target RTE interface is integrated, and obtain the fourth comparison result;

[0119] The generation module 1105 is used to generate a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

[0120] This device first performs automated comparison and verification of requirements and inputs during the integration testing phase to ensure accurate alignment of source input items. It can perform layer-by-layer verification of RTE interfaces according to the verification category, raising issues at each level and improving the comprehensiveness and efficiency of RTE interface verification.

[0121] like Figure 12 As shown, the third embodiment of this application provides an electronic device, including a processor 111, a communication interface 112, a memory 113, and a communication bus 114, wherein the processor 111, the communication interface 112, and the memory 113 communicate with each other through the communication bus 114.

[0122] Memory 113 is used to store computer programs;

[0123] In one embodiment, when the processor 111 executes the program stored in the memory 113, it implements the RTE interface requirement verification method provided in any of the foregoing method embodiments.

[0124] The memory and processor in the aforementioned electronic devices communicate with each other via a communication bus and communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus, etc. This communication bus can be divided into address bus, data bus, control bus, etc.

[0125] The memory may include random access memory (RAM) or non-volatile memory, such as at least one disk storage device. Optionally, the memory may also be at least one storage device located remotely from the aforementioned processor.

[0126] The processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0127] The fourth embodiment of this application provides a computer-readable medium having processor-executable non-volatile program code.

[0128] Optionally, in embodiments of this application, the computer-readable medium is configured to store program code for a processor to execute the above-described methods.

[0129] Optionally, specific examples in this embodiment can refer to the examples described in the above embodiments, and will not be repeated here.

[0130] In specific implementation, the embodiments of this application can be referred to the above embodiments and have corresponding technical effects.

[0131] It is understood that the embodiments described herein can be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), general-purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of this application, or combinations thereof.

[0132] For software implementation, the techniques described herein can be implemented through units that perform the functions described herein. The software code can be stored in memory and executed by a processor. The memory can be implemented within the processor or external to the processor.

[0133] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0134] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

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

[0138] If a function is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solutions of the embodiments of this application, essentially, or the parts that contribute to the prior art, or parts of the technical solutions, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, ROM, RAM, magnetic disks, or optical disks.

[0139] 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. Unless otherwise specified, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes the element.

[0140] The above embodiments are merely preferred embodiments provided to fully illustrate this application, and the scope of protection of this application is not limited thereto. Equivalent substitutions or modifications made by those skilled in the art based on this application are all within the scope of protection of this application.

Claims

1. A method for verifying RTE interface requirements, characterized in that, The method includes: The first functional requirement list from the demand side is used to verify the second functional requirement list imported by the project, and the first comparison result is obtained. If the first comparison result characterization verification is passed, the second functional requirement list is compared and verified with the vehicle bus communication database file, and the second functional requirement list is compared and verified with the general configuration file to obtain the second comparison result; If the comparison verification between the second comparison result representing the second functional requirement list and the general configuration file is successful, the RTE interface in the general configuration file is verified according to the preset verification rules to obtain a third comparison result; wherein, the third comparison result includes the target RTE interface that has been verified. The target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, thus obtaining the fourth comparison result; A test report is generated based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

2. The method according to claim 1, characterized in that, The first functional requirement list from the client was used to verify the second functional requirement list imported from the project, resulting in the first comparison result, which includes: Retrieve the first functional requirement list file from the requester in the version control system and store it in the first target address; Obtain the second functional requirements list file imported by the project and store it in the second target address; By comparing the first functional requirements list file in the first target address with the second functional requirements list file in the second target address, a first comparison result is obtained.

3. The method according to claim 1, characterized in that, The vehicle bus communication database files include DBC files and LDF files; The second functional requirement list is compared and verified with the vehicle bus communication database file, including: Verify whether the data format and data transmission direction in the second functional requirement list conform to the preset rules, and use the signal data that passes the verification as the third functional requirement list. Obtain signal data from the DBC file; The signal data in the third functional requirement list is compared with the signal data in the DBC file to obtain the fifth comparison result; Obtain the signal data from the LDF file; The signal data in the third functional requirements list is compared with the signal data in the LDF file to obtain the sixth comparison result.

4. The method according to claim 3, characterized in that, Compare and verify the second functional requirement list with the general configuration file, including: Determine the first RTE interface set corresponding to the third functional requirement list; The general configuration file is parsed using a script to generate a second RTE interface set; Identify the RTE interfaces that exist simultaneously in both the first RTE interface set and the second RTE interface set, and generate a seventh comparison result; The fifth comparison result, the sixth comparison result, and the seventh comparison result are used as the second comparison result.

5. The method according to claim 1, characterized in that, The preset verification rules include at least one of the following rules: If the read interface and the write interface appear in pairs, and both the read interface and the write interface have mappings, then the verification result is failure; If the read interface and the write interface appear in pairs, the read interface has a mapping, the write interface does not have a mapping, and the read interface does not use the RTE variable, then the verification result is failure. If the read interface and the write interface appear in pairs, and there is no mapping between the read interface and the write interface, then the verification result is passed; If the read interface and the write interface appear in pairs, and the read interface has no mapping while the write interface has a mapping, then the verification result is passed; If the read interface does not have a corresponding write interface, but the read interface has a mapping, then the verification result is passed; If the read interface does not have a corresponding write interface, and the read interface is not mapped, the verification result will be failure. If the write interface does not have a corresponding read interface, but the write interface has a mapping, then the verification result is passed; If the write interface does not have a corresponding read interface and the write interface is not mapped, the verification result is that an alarm is required. If multiple write interfaces write to the same variable, the verification result will be a failure.

6. The method according to claim 1, characterized in that, The target RTE interface is compared with the integrated RTE interface in the code project to check whether the target RTE interface is integrated, resulting in a fourth comparison result, including: Obtain the integrated RTE interface in the code project; Verify that the target RTE interface exists in the integrated RTE interface; If it exists, the verification result is "passed". If it does not exist, the verification result is failure; The verification results of all the target RTE interfaces are used as the fourth comparison result.

7. The method according to claim 1, characterized in that, A test report is generated based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result, including: Obtain a service list and a service list component table; wherein, the service list is used to indicate the included hierarchical services and the interfaces under the hierarchical services; the service list component table is used to mark the component names corresponding to the service list; The first comparison result, the second comparison result, the third comparison result, and the fourth comparison result are summarized, and a test report is generated according to the service list and the service list component table. Get the API whitelist; If the first interface that failed to be characterized in the test report belongs to the interface whitelist, then the first interface will be stored in the list of interfaces whose characterization results have been confirmed.

8. An RTE interface requirement verification device, characterized in that, The device includes: The first verification module is used to verify the second functional requirement list imported by the project based on the first functional requirement list from the requester, and obtain the first comparison result. The second verification module is used to perform a comparison verification between the second functional requirement list and the vehicle bus communication database file, and a comparison verification between the second functional requirement list and the general configuration file, when the first comparison result characterization verification is passed, to obtain a second comparison result. The third verification module is used to verify the RTE interface in the general configuration file according to a preset verification rule when the comparison verification between the second comparison result representing the second functional requirement list and the general configuration file passes, and to obtain a third comparison result; wherein, the third comparison result includes the target RTE interface that has passed the verification. The fourth verification module is used to compare the target RTE interface with the integrated RTE interface in the code project, detect whether the target RTE interface is integrated, and obtain the fourth comparison result; The generation module is used to generate a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result.

9. An electronic device, characterized in that, It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; A processor, when executing a program stored in memory, implements the method described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method described in any one of claims 1-7.

Images