RTE interface demand verification method and device, electronic equipment and storage medium

Abstract

The invention relates to an RTE interface demand verification method and device, electronic equipment and a storage medium, and the method comprises the steps: verifying a second function demand list imported by a project based on a first function demand list of a demand side, and obtaining a first comparison result; comparing and verifying the second function demand list with the vehicle-mounted bus communication database file and the universal configuration file to obtain a second comparison result; verifying the RTE interface in the general configuration file according to a preset verification rule to obtain a third comparison result; comparing the target RTE interface with an integrated RTE interface in a code project to obtain a fourth comparison result; and generating a test report based on the comparison result. According to the method, automatic comparison verification is firstly carried out on requirements and input in an integration test stage, accurate alignment of source end input items is ensured, layer-by-layer verification can be carried out on the RTE interface according to the verification category, the problem of each layer is led out, and the comprehensiveness and efficiency of RTE interface verification are improved.

Description

Technical Field

[0001] The present application relates to the technical field of RTE interface detection, and in particular to an RTE interface requirement verification method, device, electronic device and storage medium. Background Art

[0002] Automotive Open System Architecture (AUTOSAR) is a development framework for automotive electronic systems. It is a standard package of the software bottom layer of the automotive electronic control unit (ECU) so that developers can share a set of bottom-level software. In most cases, developers only need to modify some of the parameters, that is, they can match different hardware or different application layer software. AUTOSAR can decouple the basic software layer BSW (Basic Software) and the application software layer ASW (Application Software), so that application software can be developed without relying on hardware. In order to realize the interaction between the basic software layer ASW and the basic software layer BSW, the communication interface of the middle layer runtime environment (RTE) needs to be configured to ensure the correctness and reliability of data transmission. The RTE interface is an interface defined in the AUTOSAR standard, which is mainly used for communication between software components (SWC) and microcontroller abstraction layer (MCAL). Software integration is to realize the interface connection of each SWC, AUTOSAR code generation and software compilation.

[0003] With the increasingly widespread application of AUTOSAR software architecture in the automotive field, ECU version integration has been able to achieve rapid iteration. The vehicle interface device VIU (Vehicle Interface Unit) is a type of controller that integrates body functions, vehicle three-electric functions, air conditioning control functions, and electronic suspension functions. Since the VIU domain controller is the core domain controller of the car, the RTE interface in the code is currently tested directly. For test failure interfaces, there are various reasons for failure, such as RTEMapping maintenance issues, signal issues in CAN messages and LIN messages, application model issues, integration issues, and underlying software issues. It is necessary to debug upward from the code level in sequence, and then combine the demand side for final positioning. This reverse operation cannot efficiently discover, locate, and solve the root cause of the problem. Summary of the invention

[0004] In order to solve the above technical problems or at least partially solve the above technical problems, the present application provides an RTE interface requirement verification method, device, electronic device and storage medium.

[0005] In a first aspect, the present application provides a method for verifying RTE interface requirements, the method comprising:

[0006] Verify the second functional requirement list imported by the project based on the first functional requirement list of the demander to obtain a first comparison result;

[0007] If the first comparison result indicates that the verification is passed, performing a comparison and verification between the second function requirement list and the vehicle bus communication database file, and performing a comparison and verification between the second function requirement list and the general configuration file to obtain a second comparison result;

[0008] If the second comparison result indicates that the comparison verification between the second functional requirement list and the general configuration file has passed, verify the RTE interface in the general configuration file according to a preset verification rule to obtain a third comparison result; wherein the third comparison result includes the target RTE interface that has passed the verification;

[0009] Comparing the target RTE interface with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and obtaining a 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 of the demander to obtain a first comparison result, including:

[0012] Pull the first functional requirement list file of the demander from the version management system and store it to the first target address;

[0013] Obtain the second functional requirement list file imported into the project and store it to the second target address;

[0014] The first function requirement list file in the first target address is compared with the second function requirement list file in the second target address to obtain a first comparison result.

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

[0016] Comparing and verifying the second functional requirement list with the vehicle bus communication database file includes:

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

[0018] Get the signal data of the DBC file;

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

[0020] Get signal data from LDF file;

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

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

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

[0024] Parsing the general configuration file through a script to generate a second RTE interface set;

[0025] Determine the RTE interfaces that exist 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 rule includes 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 are mapped, the verification result is failure;

[0029] If the read interface and the write interface appear in pairs, the read interface is mapped, the write interface is not mapped, and the read interface does not use the RTE variable, the verification result is failed;

[0030] If the read interface and the write interface appear in pairs, and neither the read interface nor the write interface is mapped, the verification result is passed;

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

[0032] If the read interface does not have a corresponding write interface, and the read interface has a mapping, 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 is failed;

[0034] If the write interface does not have a corresponding read interface, and the write interface has a mapping, 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 is failure.

[0037] Optionally, comparing the target RTE interface with an integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and obtaining a fourth comparison result includes:

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

[0039] Verify whether 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 failed;

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

[0043] Optionally, generating a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result includes:

[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] 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;

[0046] Get the interface whitelist;

[0047] If the first interface that fails the characterization in the test report belongs to the interface whitelist, the first interface is stored in a list of confirmed characterization results.

[0048] In a second aspect, the present application provides an RTE interface requirement verification device, the device comprising:

[0049] A first verification module is used to verify the second functional requirement list imported by the project based on the first functional requirement list of the demander to obtain a first comparison result;

[0050] A second verification module is used to compare and verify the second function requirement list with the vehicle bus communication database file, and to compare and verify the second function requirement list with the general configuration file, to obtain a second comparison result, if the first comparison result indicates that the verification is passed;

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

[0052] A fourth verification module, used for comparing the target RTE interface with the integrated RTE interface in the code engineering, detecting whether the target RTE interface is integrated, and obtaining a fourth comparison result;

[0053] A generating 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] In a third aspect, the present 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 via the communication bus;

[0055] Memory, used to store computer programs;

[0056] The processor is used to implement the steps of the RTE interface requirement verification method described in any one of the embodiments of the first aspect when executing the program stored in the memory.

[0057] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon, and when the computer program is executed by a processor, the steps of the RTE interface requirement verification method as described in any embodiment of the first aspect are implemented.

[0058] Beneficial effects of this application:

[0059] The method provided in the embodiment of the present application is to verify the second functional requirement list list imported into the project based on the first functional requirement list list of the demander to obtain a first comparison result; when the first comparison result indicates that the verification is passed, the second functional requirement list list is compared and verified with the vehicle bus communication database file, and the second functional requirement list list is compared and verified with the general configuration file to obtain a second comparison result; when the second comparison result indicates that the comparison and verification of the second functional requirement list list and the general configuration file is passed, 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 passed the verification; the target RTE interface is compared with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated to obtain a fourth comparison result; and a test report is generated based on the first comparison result, the second comparison result, the third comparison result and the fourth comparison result. In this method, the requirements and inputs are first automatically compared and verified in the integration test phase to ensure that the source input items are accurately aligned, and the RTE interface can be verified layer by layer according to the verification category, leading to problems at each level, and improving the comprehensiveness and efficiency of RTE interface verification. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0061] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

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

[0063] Figure 2 A flowchart of an RTE interface requirement verification method provided for an embodiment of the present application;

[0064] Figure 3 A flowchart of an RTE interface requirement verification method provided by an embodiment of the present application;

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

[0066] Figure 5A RTEMapping pull correctness verification flow chart provided for an embodiment of the present application;

[0067] Figure 6 A flow chart of RTEMapping and database comparison verification provided for one embodiment of the present application;

[0068] Figure 7 A flow chart of RTEMapping and ARXML comparison and verification provided for an embodiment of the present application;

[0069] Figure 8 A flowchart of RTE interface verification in an application model ARXML provided in one embodiment of the present application;

[0070] Fig. 9 An RTE interface integration verification flow chart provided for one embodiment of the present application;

[0071] Fig.10 A schematic diagram of a test result classification summary provided for an embodiment of the present application;

[0072] Fig.11 A schematic diagram of the structure of an RTE interface requirement verification device provided by an embodiment of the present application;

[0073] Fig.12 A schematic diagram of the structure of an electronic device provided in accordance with an embodiment of the present application. DETAILED DESCRIPTION

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

[0075] The first embodiment of the present application provides a method for verifying RTE interface requirements. The method can be applied to Figure 1 The system architecture shown in the figure includes at least a comparison and verification module 101 and a test report generation module 102, and the comparison and verification module 101 establishes a communication connection with the test report generation module 102. Specifically, the system architecture can be a vehicle, and the type of vehicle is not limited, for example, it can be a fuel vehicle, a pure electric vehicle, a hybrid vehicle or a fuel cell vehicle, etc.

[0076] Next, based on the system architecture, the RTE interface requirement verification method is described in detail, such as Figure 2 , the RTE interface requirement verification method includes:

[0077] Step 201 , based on the first functional requirement list of the demander, the second functional requirement list imported into the project is verified to obtain a first comparison result.

[0078] In a specific embodiment, the flowchart of the RTE interface requirement verification method is as follows: Figure 3 , which can be applied to the automated testing system, which sequentially implements the import verification of the functional requirement list (hereinafter referred to as RTEMapping), that is, verifies whether the RTEMapping pulled from the code engineering by the integrated development meets the expectations of the demander; compares and verifies RTEMapping with the vehicle bus communication database file (also referred to as the database file, including DBC files and LDF files), and compares and verifies RTEMapping with the general configuration file ARXML of the application model; verifies the RTE interface rules in the general configuration file ARXML of the application model; verifies the integration of the RTE interface in the engineering code; and generates a test report by classifying and summarizing the test results.

[0079] The ECU controller under the Autosar architecture requires multiple accesses before software integration, and the accesses of each party are maintained by themselves and are not aligned horizontally. For example, there are thousands of CAN and LIN signal quantities, and tens of thousands of application model RTE interfaces, which cannot be manually compared one by one. Therefore, in this embodiment, various requirements and inputs are first automatically compared and verified during the integration test phase to ensure that the source input items are accurately aligned, which can effectively intercept functional failures caused by serious problems such as missing CAN and LIN signals. Through multi-level comparison and verification, monitoring from top to bottom according to the level is finally achieved, and the comparison results of each level can be output and finally summarized. Therefore, the problems existing in the RTE interface can be efficiently found in the obtained test report.

[0080] In a specific embodiment, before performing the RTEMapping import verification, a list of input files for the test input may be prepared first. The schematic diagram of the input file list is as follows: Figure 4 , which can include the RTEMapping table to be verified, database files, ARXML tables, service lists divided by responsible persons for failed items, and SOA service list component tables. A brief description of these input files is as follows:

[0081] RTEMapping is a list of functional requirements for the conversion of vehicle-mounted CAN / LIN signals and services. For example, RTEMapping can contain fields such as file name FileName, signal name SignalName, message name MessageName, classification Classification, direction Direction, software component name SwcName, serial port name PortName, element name ElementName, and person in charge. It mainly identifies that the message signal on each CAN and LIN is sent and received through the interface "SwcName_PortName_ElementName". Specifically, when the function of signal-to-service conversion is to be implemented, the Direction of the interface design is reception, and the RTE service interface is generated as RTE_READ type; when the function of service-to-signal conversion is to be implemented, the Direction of the interface design is transmission, and the RTE service interface is generated as RTE_WRITE type.

[0082] The vehicle bus communication database file includes DBC (Database Bus CAN) file and LDF (LIN Description File) file. DBC is a CAN database file, which is 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. LDF is a LIN database file, which is used to describe the file format of the LIN bus communication protocol. The LDF file defines the communication parameters, signal definitions, frame definitions, and other information of each node in the LIN network. The signals in the RTEMapping table should be synchronously maintained in DBC or LDF.

[0083] As a general configuration file for automotive electronic systems, the ARXML table is regarded as a system description file in AUTOSAR and plays a key role in data transmission and storage. The ARXML table is an ARXML list generated by parsing all ARXML files. It summarizes the RTE interfaces of all application models and contains the fields ARXML name, variables, data types, RTE interface (P / R), and whether the signal RTEMapping exists. The RTE interface (P / R) is the entry for the local and peer ends to read and write variables or to send and receive receipts, and the variable is the variable for the corresponding RTE interface to perform read and write operations. The existence of the signal RTEMapping indicates whether the interface is related to communication. The existence of the signal RTEMapping indicates that it is related to communication, and the absence of the signal RTEMapping indicates that it is not related to communication.

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

[0085] The SOA service inventory component table marks the corresponding professional domain and application development person in charge of each component name.

[0086] In one embodiment, the second function requirement list list imported into the project is verified based on the first function requirement list list of the demander to obtain a first comparison result, including: pulling the first function requirement list list file of the demander from the version management system and storing it to the first target address; obtaining the second function requirement list list file imported into the project and storing it to the second target address; comparing the first function requirement list file in the first target address with the second function requirement list file in the second target address to obtain the first comparison result.

[0087] In this embodiment, the RTEMapping pull correctness verification flow chart is as follows Figure 5 , since the demander will provide the demand to the version management system, the file under the latest created SVN Tag under the RTEMapping module (i.e., the first RTEMapping) can be automatically pulled from the version management system and saved to the specified directory, such as input\SVN, and the latest Tag project file under the specified branch of the GIT repository can be pulled from the local (i.e., the second RTEMapping), and the RTEMapping file imported by the project can be obtained and stored in the specified directory, such as input\Import. Get the RTEMapping file under the SVN directory, parse it to obtain the RTE interface set S0, get the RTEMapping file under the Import directory, parse it to obtain the RTE interface set S1. Compare set S0 with set S1. If the RTE interface only exists in set S0, it means that it exists on SVN but has not been integrated into the VIU project, and the comparison result is FAIL; if the RTE interface only exists in set S1, it means that it has been integrated into the VIU project but not on 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 the form of an excel table. It should be understood that the first comparison result includes the FAIL or PASS results of all RTE interfaces included in the second functional requirements list file. By comparing the two RTE mapping files in the SVN and Import directories, it can be determined whether the integrated development correctly obtains the RTE mapping files provided by the demander. In this embodiment, the problem caused by incorrect RTE mapping pull can be located.

[0088] Step 202 , when the first comparison result indicates that the verification is passed, a comparison and verification is performed between the second function requirement list and the vehicle bus communication database file, and a comparison and verification is performed between the second function requirement list and the general configuration file to obtain a second comparison result.

[0089] When the first comparison result indicates that the verification is passed, a comparison between RTEMapping and the DBC file, a comparison between RTEMapping and the LDF file, and a comparison between RTEMapping and ARXML may be performed to obtain a second comparison result.

[0090] In one embodiment, a comparison and verification is performed between the second function requirement list and the vehicle bus communication database file, including: verifying whether the data format and data sending direction in the second function requirement list comply with preset rules, and using the signal data that passes the verification as the third function requirement list; obtaining the signal data of the DBC file; comparing the signal data in the third function requirement list with the signal data of the DBC file to obtain a fifth comparison result; obtaining the signal data of the LDF file; comparing the signal data in the third function requirement list with the signal data of the LDF file to obtain a sixth comparison result.

[0091] In this embodiment, the RTEMapping and database comparison verification flow chart is as follows Figure 6 , the preset rules include, for example, Rule 1 and Rule 2. Rule 1 can be that the relevant fields "SwcName", "PortName", and "ElementName" involved in the RTE interface are not empty. Compliance with Rule 1 can ensure that the corresponding service interface has been set for the CAN signal and the LIN signal, and the signal and service have been converted. Rule 2 can limit the sending direction to "SEND" or "RECEIVE". Compliance with Rule 2 can ensure the directionality of the service interface. SEND realizes the service-to-signal requirement, and RECEIVE realizes the signal-to-service requirement. The signal data that passes the verification enters the subsequent verification process as the third RTEMapping, and the signal data that fails the verification is output to the Excel table in the form of a failure result. Obtaining the signal data of the DBC file can be obtaining the message and signal in the DBC. Specifically, the DBC file is imported for DBC parsing, 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. Based on RTEMapping, no requirements are made for redundant messages and signals in the DBC. The comparison scenario is shown in Table 1 below:

[0092] Table 1

[0093] Condition Message in DBC Signals in DBC result Cause of failure 1 Does not exist Does not exist FAIL The message is not in the DBC 2 exist Does not exist FAIL Signal not in DBC 3 exist exist PASS

[0094] Next, obtain the signal data of the LDF file, such as obtaining the messages and signals in the LDF, and compare the signal data in the RTEMapping table with the signal data in the LDF, using RTEMapping as the basis, and not requiring the redundant messages and signals in the LDF. In this embodiment, the problems existing in the comparison process with the database can be located, and the comparison scenario is shown in Table 2 below:

[0095] Table 2

[0096] Condition Message in LDF Signal in LDF result Cause of failure 1 Does not exist Does not exist FAIL The message is not in LDF 2 exist Does not exist FAIL Signal not in LDF 3 exist exist PASS

[0097] In one embodiment, a comparison and verification is performed between the second functional requirement list and the general configuration file, including: determining the first RTE interface set corresponding to the third functional requirement list; generating a second RTE interface set by script parsing the general configuration file; determining the RTE interface that exists in both 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, the signal data whose data format and data transmission direction in the second functional requirement list conform to the preset rules is used as RTEMapping for comparison and verification with the general configuration file. The RTEMapping and ARXML comparison and verification flow chart is as follows: Figure 7 , the application model ARXML file in the project is parsed through a script to generate an ARXML RTE interface summary list set S2, which contains the ARXML name, variables, data types, RTE interface (P / R), and whether there is a signal RTEMapping. Whether there is a signal RTEMapping indicates whether the interface is related to communication. Compare the RTE interface set S1 in the RTEMapping table with the ARXML list set S2, and use the RTEMapping table data as a basis to retrieve the value of the field "Whether there is a signal RTEMapping" in the ARXML list to be 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 existing in the comparison and verification with ARXML can be located, and the scenario is as shown in Table 3:

[0099] Table 3

[0100] Condition Set S1 Vs Set S2 result Cause of failure 1 Only exists in S1 FAIL The interface in the mapping table does not exist in ARXML 2 Exists in both S1 and S2 PASS Note: The model is implemented according to the requirements

[0101] Step 203, when the second comparison result indicates that the comparison verification between the second functional requirement list and the general configuration file has passed, 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 verified target RTE interface.

[0102] In this embodiment, the target RTE interface that passes the verification can also be called the required RTE interface. The RTE interface verification flow chart in the application model ARXML is as follows: Figure 8 First, the application model ARXML file in the project is parsed through a script to generate an ARXMLRTE interface summary list set S2, and the RTE interface in the application model ARXML is verified for the list set S2. The preset verification rules are as shown in Table 4 below.

[0103] Table 4

[0104]

[0105] Likewise, the determination failure result may be output in a table format. In this embodiment, the problem existing in the RTE interface verification may be located.

[0106] Step 204 , compare the target RTE interface with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and obtain a 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, including: 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 the verification results of all target RTE interfaces are used as the fourth comparison result.

[0108] In this embodiment, the RTE interface integration verification flow chart is as follows: Fig. 9 , the target RTE interfaces that have been aligned through the above steps include two types, one is the interface related to communication (COM), and the other is the interface unrelated to communication (COM). The interface related to COM has passed the database comparison and ARXML comparison in the above steps, and has passed the ARXML rule verification; the interface not related to COM has passed the ARXML verification. It is possible to determine whether the target RTE interface has been integrated based on the integrated RTE interface in the code project. For example, using the target RTE interface as a benchmark, verify whether the integrated RTE interface in the source code exists. If it exists, the verification result is passed; if it does not exist, the verification result is failed. In this embodiment, the problem of whether the RTE interface is integrated can be located.

[0109] Step 205 : generating 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 automatically compares and verifies requirements and inputs during the integration test phase to ensure accurate alignment of source input items. It can verify the RTE interface layer by layer according to the verification category, identify problems at each level, and improve the comprehensiveness and efficiency of RTE interface verification.

[0111] In one embodiment, a test report is generated based on a first comparison result, a second comparison result, a third comparison result, and a fourth comparison result, including: 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 fails to be characterized in the test report belongs to the interface whitelist, the first interface is stored in a list of confirmed characterization results.

[0112] In this embodiment, the test results are classified and summarized to facilitate the location of failed test results to the corresponding team and responsible person, so that the demand personnel, application developers, and integration developers in each link can immediately identify the problems in their own part and carry out rectification. Fig.10 , after summarizing all test results and generating test results for each module according to the service list and its component list, the test reports for failed and passed test results are output separately. The RTE interface that failed but appeared in the whitelist can be stored in the development confirmed result list in combination with the interface whitelist. Finally, the final failed test results are sorted and tracked by team and responsible person, and finally a closed loop is achieved.

[0113] In any of the above embodiments, the RTE interface requirement verification can be performed before the RTE interface test. The RTE interface test is to test whether the interface can normally read and write variables (non-communication RTE interface) and send and receive signals (communication RTE interface). The test results are only failure and success. It is also relatively time-consuming to simply test a large number of RTE interfaces (such as the current tens of thousands of interfaces). If the cause analysis is also added, the required input will increase and the time consumption will double. At present, RTE interface generation is generally automatically generated using a tool chain, and there will be basically no problems at the generation end. When testing the RTE interface, it is found that most of the interfaces that fail to be determined are alignment problems on the demand side. Therefore, by performing the requirement verification in a hierarchical manner in the embodiments of the present application, the RTE interface that fails to be detected will not enter the subsequent RTE interface verification, and only the interface that passes the RTE requirement verification will eventually enter the RTE interface test. Through RTE interface requirement verification, problems generated upstream can be located and screened, and the requirement verification automation system has high execution efficiency and can generally produce results in a few minutes. Compared with the conventional RTE interface test that takes several hours, the efficiency is significantly improved. In addition, the RTE interface that has passed the RTE interface requirement verification generally will not have problems in the RTE interface test, which can reduce the frequency of RTE interface testing during development, thereby greatly improving development efficiency.

[0114] Based on the same technical concept, the second embodiment of the present application provides an RTE interface requirement verification device, such as Fig.11 , the device comprises:

[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 demander to obtain a first comparison result;

[0116] The second verification module 1102 is used to compare and verify the second function requirement list with the vehicle bus communication database file, and compare and verify the second function requirement list with the general configuration file, to obtain a second comparison result when the first comparison result indicates that the verification is passed;

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

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

[0119] The generating module 1105 is configured 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 automatically compares and verifies requirements and inputs during the integration test phase to ensure accurate alignment of source input items. It can verify the RTE interface layer by layer according to the verification category, identify problems at each level, and improve the comprehensiveness and efficiency of RTE interface verification.

[0121] like Fig.12 As shown, the third embodiment of the present 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] A memory 113, for storing computer programs;

[0123] In one embodiment, the processor 111 is configured to implement the RTE interface requirement verification method provided by any one of the aforementioned method embodiments when executing a program stored in the memory 113 .

[0124] The memory and processor in the above electronic device communicate through the communication bus and the communication interface. The communication bus can be a Peripheral Component Interconnect (PCI) bus or an Extended Industry Standard Architecture (EISA) bus. The communication bus can be divided into an address bus, a data bus, a control bus, etc.

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

[0126] The above-mentioned processor can be a general-purpose processor, including a central processing unit (CPU), a network processor (NP), etc.; it can also be a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components.

[0127] A fourth embodiment of the present application provides a computer-readable medium having a non-volatile program code executable by a processor.

[0128] Optionally, in an embodiment of the present application, a computer-readable medium is configured to store program code for a processor to execute the above method.

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

[0130] When the embodiments of the present application are specifically implemented, reference may be made to the above-mentioned embodiments, which have corresponding technical effects.

[0131] It is understood that the embodiments described herein may be implemented in hardware, software, firmware, middleware, microcode, or a combination thereof. For hardware implementation, the processing unit may be implemented in one or more application specific integrated circuits (ASIC), digital signal processors (DSP), digital signal processing devices (DSPD), programmable logic devices (PLD), field programmable gate arrays (FPGA), general purpose processors, controllers, microcontrollers, microprocessors, other electronic units for performing the functions of the present application, or a combination thereof.

[0132] For software implementation, the technology of this article can be implemented by a unit that performs the functions of this article. The software code can be stored in a memory and executed by a processor. The memory can be implemented in the processor or outside the processor.

[0133] Those of ordinary skill in the art will appreciate that the units and algorithm steps of each example 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 performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application.

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

[0135] In the embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic. For example, the division of modules is only a logical function division. There may be other division methods in actual implementation, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or units, which can be electrical, mechanical or other forms.

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

[0137] In addition, each functional unit in each embodiment of the present application may be integrated into one processing unit, or each unit may exist physically separately, or two or more units may be integrated into one unit.

[0138] If the function is implemented in the form of 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 solution of the embodiment of the present application can be essentially or partly embodied in the form of a software product that contributes to the prior art. The computer software product is stored in a storage medium and includes several instructions for a computer device (which can be a personal computer, server, or network device, etc.) to perform all or part of the steps of the methods of each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as USB flash drives, mobile hard drives, ROM, RAM, magnetic disks, or optical disks.

[0139] It should be noted that, in this article, relational terms such as "first" and "second" are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the existence of other identical elements in the process, method, article or device including the elements.

[0140] The above embodiments are only preferred embodiments for fully illustrating the present application, and the protection scope of the present application is not limited thereto. Any equivalent substitution or change made by a person skilled in the art based on the present application is within the protection scope of the present application.

Claims

1. A RTE interface requirement verification method, characterized in that: The method comprises: Verify the second functional requirement list imported by the project based on the first functional requirement list of the demander to obtain a first comparison result; If the first comparison result indicates that the verification is passed, performing a comparison and verification between the second function requirement list and the vehicle bus communication database file, and performing a comparison and verification between the second function requirement list and the general configuration file to obtain a second comparison result; If the second comparison result indicates that the comparison verification between the second functional requirement list and the general configuration file has passed, verify the RTE interface in the general configuration file according to a preset verification rule to obtain a third comparison result; wherein the third comparison result includes the target RTE interface that has passed the verification; Comparing the target RTE interface with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and obtaining a 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 second functional requirement list imported by the project is verified based on the first functional requirement list of the demander to obtain a first comparison result, including: Pull the first functional requirement list file of the demander from the version management system and store it to the first target address; Obtain the second functional requirement list file imported into the project and store it to the second target address; The first function requirement list file in the first target address is compared with the second function requirement list file in the second target address to obtain a first comparison result.

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

4. The method according to claim 3, characterized in that Compare and verify the second functional requirements list with the general configuration file, including: Determine a first RTE interface set corresponding to the third functional requirement list; Parsing the general configuration file through a script to generate a second RTE interface set; Determine the RTE interfaces that exist 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 are mapped, the verification result is failure; If the read interface and the write interface appear in pairs, the read interface is mapped, the write interface is not mapped, and the read interface does not use the RTE variable, the verification result is failed; If the read interface and the write interface appear in pairs, and neither the read interface nor the write interface is mapped, the verification result is passed; If the read interface and the write interface appear in pairs, the read interface has no mapping, and the write interface has a mapping, the verification result is passed; If the read interface does not have a corresponding write interface, and the read interface has a mapping, 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 is failed; If the write interface does not have a corresponding read interface, and the write interface has a mapping, 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 is failure.

6. The method according to claim 1, characterized in that Comparing the target RTE interface with the integrated RTE interface in the code project to detect whether the target RTE interface is integrated, and obtaining a fourth comparison result, including: Get the integrated RTE interface in the code project; Verify 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; 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 Generating a test report based on the first comparison result, the second comparison result, the third comparison result, and the fourth comparison result includes: 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; 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; Get the interface whitelist; If the first interface that fails the characterization in the test report belongs to the interface whitelist, the first interface is stored in a list of confirmed characterization results.

8. An RTE interface requirement verification device, characterized in that: The device comprises: A first verification module is used to verify the second functional requirement list imported by the project based on the first functional requirement list of the demander to obtain a first comparison result; A second verification module is used to compare and verify the second function requirement list with the vehicle bus communication database file, and to compare and verify the second function requirement list with the general configuration file, to obtain a second comparison result, if the first comparison result indicates that the verification is passed; A third verification module is used to verify the RTE interface in the general configuration file according to a preset verification rule to obtain a third comparison result when the second comparison result indicates that the comparison verification between the second functional requirement list and the general configuration file has passed; wherein the third comparison result includes a target RTE interface that has passed the verification; A fourth verification module, used for comparing the target RTE interface with the integrated RTE interface in the code engineering, detecting whether the target RTE interface is integrated, and obtaining a fourth comparison result; A generating 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, for implementing the method according to any one of claims 1 to 7 when executing a program stored in a memory.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Images