A method, system and device for full-link consistency check of vehicle signal data and a readable storage medium

Abstract

The application discloses a kind of vehicle signal data's full-link consistency checking method, system, equipment and storage medium, the method includes: based on the first preset quality access control rule to the difference signal between first signal set and second signal set is discriminated, determine whether to generate source code;If not generating source code, then generate pre-check report, after being corrected to the signal to be modified recheck;If generating source code, then according to the second preset quality access control rule to source code is checked for full-link consistency, and generates inspection report.The application realizes early interception and full-link closed-loop management and control by two-stage series quality access control, avoids invalid code generation, ensures code and design consistency, improves software development efficiency and quality reliability.

Description

Technical Field

[0001] This application relates to the field of software development technology, specifically to a method, system, device, and readable storage medium for end-to-end consistency checking of vehicle signal data. Background Technology

[0002] With the continuous development of automotive electronic architecture, AUTOSAR has become the standard architecture for modern automotive software development. In the AUTOSAR development process, runtime environment (RTE) code generation is a critical step, relying on accurate signal mapping configuration. Currently, the industry has increasingly higher demands for software development efficiency and quality control, requiring efforts to reduce rework and resource waste caused by configuration errors while ensuring code correctness.

[0003] In related technologies, checking the consistency of signal mappings typically relies on the built-in verification functions of code generation tools, or on post-generation verification via scripts after code generation. Common practices include performing signal name matching during the generation process, generating empty functions or logging if a match fails, and performing static scanning of the code files after generation.

[0004] However, existing technologies have the following problems: First, the timing of checks is delayed, and mapping configuration errors are often only discovered after the code has been generated, resulting in the generation of invalid RTE code; second, all unmapped signals are treated as errors, leading to a high false alarm rate and interfering with developers' judgment of defects in the absence of actual mappings; third, the consistency verification between the design state and the implementation state is fragmented, lacking full-link closed-loop control. Summary of the Invention

[0005] This application provides a method, system, device, and readable storage medium for end-to-end consistency checking of vehicle signal data, which can solve the technical problem of invalid RTE code generation caused by mapping errors in the prior art.

[0006] In a first aspect, embodiments of this application provide a method for end-to-end consistency checking of vehicle signal data, the method comprising: Based on the first preset quality access control rules, the difference signals between the first signal set and the second signal set are identified to determine whether to generate source code. The first signal set is obtained by extracting the obtained description file according to the first extraction rule, and the second signal set is obtained by extracting the obtained description file according to the second extraction rule. The description file includes a system description file and a CAN database file. If it is determined that the source code is generated, then according to the second preset quality access control rule, a full-link consistency check is performed on the source code, and a check report is generated; If the source code is not generated, a pre-check report is generated, and the signal to be corrected is corrected based on the pre-check report. Then, the end-to-end consistency check is performed again, and a check report is generated.

[0007] In conjunction with the first aspect, in one implementation, the second preset quality access control rule includes a preset whitelist set, and the step of performing a full-link consistency check on the source code according to the second preset quality access control rule and generating a check report includes: The source code is parsed and features are extracted to generate a third set, which includes signals corresponding to "notmapped correctly". Based on the preset whitelist set, a consistency check is performed on the third set, and a check report is generated, which includes a first check report and a second check report.

[0008] In conjunction with the first aspect, in one implementation, the step of performing a consistency check on the third set based on the preset whitelist set and generating a check report includes: Determine whether the signal corresponding to "not mapped correctly" belongs to the preset whitelist set; If the determination is correct, the consistency check is deemed to have passed, and a first check report is generated, which includes a pass identifier. If the determination does not belong to the category, the consistency check is deemed to have failed, and a second check report is generated, which includes the identifier of failure.

[0009] In conjunction with the first aspect, in one implementation, the step of identifying the difference signals between the acquired first signal set and second signal set based on a first preset quality access control rule to determine whether to generate source code includes: Differential signals are identified through naming rules; If the difference signal is a preset target attribute signal, then the source code is determined to be generated; If the difference signal is not a preset target attribute signal, then it is determined that no source code will be generated.

[0010] In conjunction with the first aspect, in one implementation, the first preset quality access control rule includes a preset whitelist, and after determining not to generate source code if the difference signal is not a preset target attribute signal, the rule further includes: The remaining differential signals are identified using the preset whitelist; If the preset whitelist contains the remaining difference signals, then it is determined that source code will be generated; If the preset whitelist does not contain the remaining difference signals, then it is determined that no source code will be generated; The remaining difference signals include signal identifiers that are not included in the naming rules.

[0011] In conjunction with the first aspect, in one implementation, after determining not to generate source code if the preset whitelist does not contain the remaining difference signals, the method further includes: The remaining difference signals are corrected to generate corrected signals, and then the end-to-end consistency check is performed again to generate a check report.

[0012] In conjunction with the first aspect, in one implementation, the step of identifying the difference signals between the acquired first signal set and second signal set based on a first preset quality access control rule to determine whether to generate source code includes: The obtained description file is extracted according to the first extraction rule to generate the first signal set; The obtained description file is extracted according to the second extraction rule to generate a second signal set; The signals in the first signal set are compared with the signals in the second signal set to obtain the difference signals between the first signal set and the second signal set; The first extraction rule is to parse and extract signal data from the system description file. The signal data includes at least the signal interface, data type, and mapping relationship between the signal and the interface. The second extraction rule is to parse and extract communication message signals from the CAN database file. The communication message signals include at least the network segment name, signal name, and message transmission / reception direction.

[0013] Secondly, embodiments of this application provide a full-link consistency check system for vehicle signal data, the system comprising: The signal discrimination module is used to acquire the difference signal between the first signal set and the second signal set, and to discriminate the difference signal based on the first preset quality access control rule to determine whether to generate source code; The source code generation control module is used to control the source code generation tool to generate the source code based on the discrimination result of the signal discrimination module. The consistency check module is used to perform a full-link consistency check on the source code according to the second preset quality gate rule and generate a check report if it is determined that the source code will be generated; it is also used to generate a pre-check report if the source code is not generated, so that the full-link consistency check can be performed again after the signal to be corrected is corrected and a check report can be generated.

[0014] Thirdly, embodiments of this application provide a vehicle signal data end-to-end consistency check device, the vehicle signal data end-to-end consistency check device includes a processor, a memory, and a vehicle signal data end-to-end consistency check program stored in the memory and executable by the processor, wherein when the vehicle signal data end-to-end consistency check program is executed by the processor, it implements the steps of the vehicle signal data end-to-end consistency check method as described in any of the above claims.

[0015] Fourthly, embodiments of this application provide a computer-readable storage medium storing a full-link consistency check program for vehicle signal data, wherein when the full-link consistency check program for vehicle signal data is executed by a processor, it implements the steps of the full-link consistency check method for vehicle signal data as described in any of the above.

[0016] The beneficial effects of the technical solutions provided in this application include: By using a first preset quality gate rule to identify the differences between the first and second signal sets to determine whether to generate source code, and generating a pre-check report when no source code is generated so that the signals to be corrected can be corrected before a full-link consistency check is performed again, and when it is determined that source code should be generated, a full-link consistency check is performed on the source code according to the second preset quality gate rule and an inspection report is generated, this solves the technical problems in related technologies, such as delayed detection of signal mapping errors leading to invalid code generation and resource waste, the lack of full-link closed-loop control in the consistency verification between design state and implementation state, and the high false alarm rate caused by treating all unmapped signals as errors. This achieves early interception and full-link closed-loop control in the development process, avoids invalid code generation, saves computing resources and time costs, ensures the consistency between the final code and the design, and improves the accuracy and usability of automated checks. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating an embodiment of the end-to-end consistency check method for vehicle signal data according to this application. Figure 2 This is a flowchart illustrating the first stage of the end-to-end consistency check method for vehicle signal data in this application. Figure 3 This is a flowchart illustrating the second stage of the end-to-end consistency check method for vehicle signal data in this application. Figure 4 This is a functional module diagram of an embodiment of the vehicle signal data end-to-end consistency check system of this application. Detailed Implementation

[0018] The technical solutions of the embodiments of this application are described below with reference to the accompanying drawings and related embodiments. In the description of the embodiments of this application, the terminology used in the following embodiments is for the purpose of describing specific embodiments only and is not intended to limit the application. As used in the specification and appended claims of this application, the singular expressions "a," "the," "the," "the," and "this" are intended to also include expressions such as "one or more," unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, "at least one" and "one or more" refer to one or more (including two). The term "and / or" is used to describe the relationship between related objects, indicating that three relationships can exist; for example, A and / or B can represent: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character " / " generally indicates that the preceding and following related objects are in an "or" relationship.

[0019] References to "one embodiment" or "some embodiments" in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized. The term "connection" includes direct connections and indirect connections, unless otherwise stated. "First" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated.

[0020] In the embodiments of this application, the words "exemplarily" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design described as "exemplarily" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of the words "exemplarily" or "for example" is intended to present the relevant concepts in a specific manner.

[0021] The steps involved in the methods provided in this application are merely examples, and not all steps are mandatory, nor are all information or message contents required. They can be added or removed as needed during use. In this application, the same step, or steps or messages with the same function, can be referenced and learned from each other in different embodiments.

[0022] The end-to-end consistency check method for vehicle signal data provided in this application is mainly applied to the software development lifecycle of automotive electronic control units, particularly in the development process based on the AUTOSAR architecture. AUTOSAR is an abbreviation for Automotive Open System Architecture, a standardized automotive software architecture used to standardize the layering and interfaces of electronic control unit software. In this development process, runtime environment code generation is a critical step, relying on accurate signal mapping configuration. Signal mapping refers to the process of associating signals defined by the network layer with software interfaces defined by the design layer. If the mapping configuration is incorrect, the generated code will be invalid, thus affecting the vehicle's communication functions. This method adopts a two-stage quality gate architecture of "design configuration pre-check" and post-code generation check. By comparing the network database with the design documents and reverse-analyzing the feature identifiers in the generated code, it solves the problem of delayed detection of signal mapping errors and the resulting invalid code generation in AUTOSAR development, achieving early interception and end-to-end closed-loop control of the development process.

[0023] The description files in this application embodiment include system description files and CAN database files. The system description file refers to the standardized description file of the AUTOSAR system, which is usually in ARXML format. It records the design configuration information of software components, signals, interfaces, etc., and is the input source for code generation.

[0024] In a specific embodiment, the system description file's filename example can be FlatExtract.arxml. The CAN database file refers to the file that describes the CAN bus communication database, usually in DBC format, which defines network layer information such as messages, signals, and physical values, and is the reference source for signal mapping. The source code refers to the runtime environment code automatically generated by the code generation tool based on the description file, usually in C language.

[0025] In a specific embodiment, the generated source code file name example can be RteCbk.c. Quality gates refer to mandatory control points in the development process. Only when specific inspection conditions are met can the process proceed to the next stage; otherwise, it will be forcibly interrupted.

[0026] The end-to-end consistency check method for vehicle signal data provided in this application runs on a check device with data processing capabilities, which can be a personal computer, server, or embedded development host. The check device includes a processor, a memory, and an end-to-end consistency check program for vehicle signal data stored in the memory and executable by the processor. The processor can be a central processing unit, a digital signal processor, or an application-specific integrated circuit (ASIC). The memory can be a high-speed random access memory (RAM) or a stable non-volatile memory, such as a hard disk or flash memory. The processor executes the steps of the end-to-end consistency check method for vehicle signal data provided in this application by running instructions stored in the memory. This method enables mandatory automated checks in a continuous integration / continuous deployment (CI / CD) pipeline.

[0027] The following describes in detail the end-to-end consistency check method for vehicle signal data provided in this application embodiment, using a specific application scenario. This method aims to solve the technical problems of delayed signal mapping checks, high false alarm rates, and lack of end-to-end closed-loop control in existing technologies. By setting dual quality gates in the design and code generation phases, end-to-end consistency assurance is achieved.

[0028] As shown in Figure 1, the end-to-end consistency check method for vehicle signal data provided in this application includes the following steps: Step S10: Based on the first preset quality access control rules, the difference signals between the acquired first signal set and the second signal set are identified to determine whether to generate source code.

[0029] Specifically, firstly, the system acquires key description files from the development process, including system description files and Controller Area Network (CAN) database files. The system then parses the acquired system description files according to a first extraction rule and extracts signal data to generate a first signal set. The signal data includes at least the signal interface, data type, and the mapping relationship between signals and interfaces. Next, the system parses the acquired CAN database files according to a second extraction rule and extracts communication message signals to generate a second signal set. The communication message signals include at least the network segment name, signal name, and message transmission / reception direction. The first signal set represents the desired signal configuration at the design level, and the second signal set represents the signal sources defined at the network level. Next, the system compares the signals in the first signal set with the signals in the second signal set to obtain the difference signals between the first signal set and the second signal set. The difference signals include signals that exist in the CAN database file but are not mapped to the system description file, or signals that exist in the system description file but are missing from the CAN database file. Subsequently, the system identifies these differential signals based on the first preset quality access control rule, which aims to distinguish between genuine configuration errors and legitimate non-mapping signals.

[0030] The specific identification logic includes: identifying the difference signals through naming rules. The system maintains a naming rule library. For example, it checks whether the signal name contains a specific prefix. If the difference signal is a preset target attribute signal, such as a diagnostic signal or a network management signal, which usually does not require regular runtime environment mapping, then it determines to generate source code.

[0031] In a specific embodiment, the naming rules also include identifying signal prefixes. For example, signals with the prefix "Diag" are considered diagnostic signals, and signals with the prefix "Nm" are considered network management signals. If a differential signal is not a preset target attribute signal, the remaining differential signals are identified through a preset whitelist. The preset whitelist stores a list of special signals that have been manually confirmed not to require mapping. The remaining differential signals include signal identifiers that are not included in the naming rules. If the preset whitelist contains the remaining differential signals, it is determined that source code will be generated. If the preset whitelist does not contain the remaining differential signals, it is determined that there is a configuration error, and it is determined that source code will not be generated.

[0032] Step S20: If it is determined that the source code has been generated, then according to the second preset quality access control rule, perform a full-link consistency check on the source code and generate a check report.

[0033] Specifically, as shown in Figure 3, if the first preset quality access rule in step S10 is passed, the code generation tool is triggered to generate source code. The system calls the automated code generation tool to generate runtime environment source code according to the mapping relationship between the first signal set and the second signal set. After generation, the system verifies the generated source code according to the second preset quality access rule, which includes a preset whitelist set. The system parses and extracts features from the source code to generate a third set. Since the code generation tool usually inserts specific identifiers into the generated code when it encounters signals that cannot be mapped, the system will not be able to do so.

[0034] In a specific embodiment, the system does not rely on complex compilation or abstract syntax tree analysis. Instead, it directly extracts the mapping state by parsing specific comment strings in the generated code, reducing the inspection overhead. For example, the feature identifier can be the comment string "not mapped correctly". The system extracts these signals containing specific identifiers and generates a third set. The third set includes the signals corresponding to "not mapped correctly". The "not mapped correctly" string is implanted by the source code generation tool in the form of code comments to identify signal mapping abnormalities, rather than participating in program logic execution.

[0035] The system loads a preset whitelist set, iterates through each signal in the third set, and determines whether the signal corresponding to "not mapped correctly" belongs to the preset whitelist set. If it does, the consistency check is considered passed, and a first check report is generated, which includes the passed flag. If it does not belong, the consistency check is considered failed, and a second check report is generated, which includes the failed flag. The check report can include both the first and second check reports. If the check passes, the process ends or enters the compilation and integration stage. If the check fails, a second quality gate is triggered, interrupting the compilation or integration process. This step solves the problem of disconnect between design-state and implementation-state consistency verification. Even if the design configuration is correct, if a defect in the code generation tool version causes mapping loss, it can be detected in a timely manner.

[0036] Step S30: If no source code is generated, a pre-check report is generated, and the signal to be corrected is corrected based on the pre-check report. Then, the full-link consistency check is performed again, and a check report is generated.

[0037] As shown in Figure 2, specifically, if it is determined in step S10 that source code should not be generated, a pre-inspection report is generated. The pre-inspection report details the difference signals that failed the first preset quality gate rule. Based on the pre-inspection report, the signals to be corrected are corrected, for example, by modifying the system description file configuration or updating the CAN database file. After the correction is completed, the system re-triggers the end-to-end consistency check process, that is, it returns to step S10 to re-perform the screening based on the first preset quality gate rule. After correction, the end-to-end check process is re-triggered until the first gate is passed and the second gate step is entered. This step avoids an invalid code generation process, saving computing resources and time costs. After the correction passes the check and the source code is generated, step S20 is executed to generate the final inspection report.

[0038] In the embodiments of this application, the specific implementation of the end-to-end consistency check may vary depending on the application scenario. For example, in a continuous integration environment, the method can run as an independent node in an automated pipeline. When a developer submits code or makes configuration changes, the end-to-end consistency check is automatically triggered. If the check fails, the pipeline is automatically stopped and a notification is sent to the relevant personnel. In a local development environment, the method can run as a plugin for an integrated development environment. When a developer saves a configuration file or triggers a generation command, the check is automatically executed and the check results are directly displayed on the interface.

[0039] Regarding the naming rules in the first preset quality access control rules, the system supports regular expression matching. For example, the rule base defines signals starting with Diag as diagnostic signals and signals starting with Nm as network management signals. When the comparison finds that there is a signal NmVehicleSpeed ​​in the CAN database file but no corresponding mapping in the system description file, the system matches the prefix and determines that it is a preset target attribute signal. This does not block the code generation process, but it can be marked as ignored in the report.

[0040] Regarding the preset whitelist, the whitelist can be a separate configuration file, such as JSON (Data Exchange Format) or TXT text format, which lists the signal names or partial matching patterns. For example, some pseudo signals used for testing may only exist in the CAN database file for simulation and do not need to generate runtime environment code. After adding them to the whitelist, even if the naming rules are not met, the instruction not to generate source code will not be triggered.

[0041] Regarding feature extraction in the second preset quality access control rules, the source code is usually a C language file. The system traverses the generated source code file and scans the text content line by line. The system has preset feature string templates. When a line containing a specific string is scanned, the system extracts the signal name that follows it through regular expressions and adds it to the third set.

[0042] The consistency check logic is as follows: The system loads a preset whitelist set. This whitelist can be the same as the whitelist in the first preset quality access control rule, or it can be configured independently to specifically address exceptions during the code generation phase. It iterates through each signal in the third set and checks whether the signal exists in the preset whitelist set. If it exists, it means that the unmapped state is expected; if it does not exist, it means that the signal should have been mapped but the generation failed.

[0043] like Figure 4 As shown in the figure, this application embodiment also provides a vehicle signal data end-to-end consistency check system, which includes a signal identification module, a source code generation control module and a consistency check module; The signal discrimination module is used to obtain the difference signals between the first signal set and the second signal set, and to discriminate the difference signals based on the first preset quality access control rules to determine whether to generate source code. This module integrates a file parsing submodule, a set comparison submodule, and a rule filtering submodule. The file parsing submodule is used to parse the system description file and the CAN database file, the set comparison submodule is used to calculate the difference set, and the rule filtering submodule is used to execute naming rules and whitelist matching.

[0044] The source code generation control module is used to control the source code generation tool to generate source code based on the discrimination result of the signal discrimination module. If the discrimination result is no generation, the module sends a lock command to the source code generation tool; if the discrimination result is generation, the module sends a trigger command.

[0045] The consistency check module is used to perform a full-link consistency check on the source code according to the second preset quality gate rule, and generate a check report, if it is determined that source code will be generated. It is also used to generate a pre-check report if source code is not generated, so that a full-link consistency check can be performed again after the signals to be corrected, and a check report can be generated. This module includes a code static scanning submodule and a report generation submodule. This system can run as a standalone software tool or be integrated as a plugin into an existing AUTOSAR configuration toolchain or continuous integration server.

[0046] This application also provides a vehicle signal data end-to-end consistency check device. The device includes a processor, a memory, and a vehicle signal data end-to-end consistency check program stored in the memory and executable by the processor. When executed by the processor, the vehicle signal data end-to-end consistency check program implements the steps of the vehicle signal data end-to-end consistency check method as described in any of the above embodiments. Specifically, the processor reads the CAN database file and system description file from the memory, executes a parsing algorithm to construct a signal set, runs comparison logic, and controls an external interface to call a code generator based on the results. Throughout the process, the processor interacts with the memory via a bus and outputs a check report via a network interface or input / output interface.

[0047] This application also provides a computer-readable storage medium storing a vehicle signal data end-to-end consistency check program. The storage medium can be a USB flash drive, external hard drive, read-only memory, random access memory, magnetic disk, or optical disk, or any other medium capable of storing program code. When the vehicle signal data end-to-end consistency check program is executed by a processor, it implements the steps of the vehicle signal data end-to-end consistency check method as described in any of the above embodiments.

[0048] In summary, the technical solution provided in this application effectively filters signals that do not require mapping and reduces the false alarm rate by introducing a first quality gate based on naming rules and whitelists during the design phase. It also intercepts configuration errors before code generation, avoiding waste of computational resources and time. By introducing a second quality gate based on feature extraction after code generation, the authenticity of the generated code is verified, preventing potential problems caused by toolchain errors. The two phases, linked together, form a closed-loop system, significantly improving the efficiency and reliability of automotive software development.

[0049] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the system can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments 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. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. In the above embodiments, the descriptions of each embodiment have different focuses; parts not described in detail or recorded in a certain embodiment can be referred to the relevant descriptions of other embodiments.

[0050] 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.

[0051] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units 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 indirect coupling or communication connection through some interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0052] 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. Furthermore, the functional units in the various embodiments of this 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. The integrated units described above can be implemented in hardware or as software functional units.

[0053] It should be noted that the sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0054] In some processes described in the embodiments of this application, multiple operations or steps are included in a specific order. However, it should be understood that these operations or steps may not be executed in the order they appear in the embodiments of this application, or they may be executed in parallel. The sequence number of the operation is only used to distinguish different operations, and the sequence number itself does not represent any execution order. In addition, these processes may include more or fewer operations, and these operations or steps may be executed sequentially or in parallel, and these operations or steps may be combined.

[0055] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device to execute the methods described in the various embodiments of this application.

[0056] The above are merely preferred embodiments of this application and do not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A method for end-to-end consistency checking of vehicle signal data, characterized in that, The end-to-end consistency check method for vehicle signal data includes: Based on the first preset quality access control rules, the difference signals between the first signal set and the second signal set are identified to determine whether to generate source code. The first signal set is obtained by extracting the obtained description file according to the first extraction rule, and the second signal set is obtained by extracting the obtained description file according to the second extraction rule. The description file includes a system description file and a CAN database file. If it is determined that the source code is generated, then according to the second preset quality access control rule, a full-link consistency check is performed on the source code, and a check report is generated; If the source code is not generated, a pre-check report is generated, and the signal to be corrected is corrected based on the pre-check report. Then, the end-to-end consistency check is performed again, and a check report is generated.

2. The end-to-end consistency check method for vehicle signal data as described in claim 1, characterized in that, The second preset quality access control rule includes a preset whitelist set. The step of performing a full-link consistency check on the source code according to the second preset quality access control rule and generating an inspection report includes: The source code is parsed and features are extracted to generate a third set, which includes signals corresponding to "not mapped correctly". Based on the preset whitelist set, a consistency check is performed on the third set, and a check report is generated, which includes a first check report and a second check report.

3. The end-to-end consistency check method for vehicle signal data as described in claim 2, characterized in that, The process of performing a consistency check on the third set based on the preset whitelist set and generating a check report includes: Determine whether the signal corresponding to "not mapped correctly" belongs to the preset whitelist set; If the determination is correct, the consistency check is deemed to have passed, and a first check report is generated, which includes a pass identifier. If the determination does not belong to the category, the consistency check is deemed to have failed, and a second check report is generated, which includes the identifier of failure.

4. The end-to-end consistency check method for vehicle signal data as described in claim 1, characterized in that, The step of identifying the difference signals between the acquired first signal set and second signal set based on the first preset quality access control rules to determine whether to generate source code includes: Differential signals are identified through naming rules; If the difference signal is a preset target attribute signal, then the source code is determined to be generated; If the difference signal is not a preset target attribute signal, then it is determined that no source code will be generated.

5. The end-to-end consistency check method for vehicle signal data as described in claim 4, characterized in that, The first preset quality access control rule includes a preset whitelist. After determining not to generate source code if the difference signal is not a preset target attribute signal, the rule further includes: The remaining differential signals are identified using the preset whitelist; If the preset whitelist contains the remaining difference signals, then it is determined that source code will be generated; If the preset whitelist does not contain the remaining difference signals, then it is determined that no source code will be generated; The remaining difference signals include signal identifiers that are not included in the naming rules.

6. The end-to-end consistency check method for vehicle signal data as described in claim 5, characterized in that, If the preset whitelist does not contain the remaining difference signals, then after determining not to generate source code, the method further includes: The remaining difference signals are corrected to generate corrected signals, and then the end-to-end consistency check is performed again to generate a check report.

7. The end-to-end consistency check method for vehicle signal data as described in claim 1, characterized in that, The step of identifying the difference signals between the acquired first signal set and second signal set based on the first preset quality access control rules to determine whether to generate source code includes: The obtained description file is extracted according to the first extraction rule to generate the first signal set; The obtained description file is extracted according to the second extraction rule to generate a second signal set; The signals in the first signal set are compared with the signals in the second signal set to obtain the difference signals between the first signal set and the second signal set; The first extraction rule is to parse and extract signal data from the system description file. The signal data includes at least the signal interface, data type, and mapping relationship between the signal and the interface. The second extraction rule is to parse and extract communication message signals from the CAN database file. The communication message signals include at least the network segment name, signal name, and message transmission / reception direction.

8. A system for checking the consistency of vehicle signal data across the entire chain, characterized in that, The system includes: The signal discrimination module is used to acquire the difference signal between the first signal set and the second signal set, and to discriminate the difference signal based on the first preset quality access control rule to determine whether to generate source code; The source code generation control module is used to control the source code generation tool to generate the source code based on the discrimination result of the signal discrimination module. The consistency check module is used to perform a full-link consistency check on the source code according to the second preset quality gate rule and generate a check report if it is determined that the source code will be generated; it is also used to generate a pre-check report if the source code is not generated, so that the full-link consistency check can be performed again after the signal to be corrected is corrected and a check report can be generated.

9. A device for checking the end-to-end consistency of vehicle signal data, characterized in that, The end-to-end consistency check device for vehicle signal data includes a processor, a memory, and an end-to-end consistency check program for vehicle signal data stored in the memory and executable by the processor. When the end-to-end consistency check program for vehicle signal data is executed by the processor, it implements the steps of the end-to-end consistency check method for vehicle signal data as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a full-link consistency check program for vehicle signal data, wherein when the full-link consistency check program for vehicle signal data is executed by a processor, it implements the steps of the full-link consistency check method for vehicle signal data as described in any one of claims 1 to 7.

Images