A vehicle function verification method and system

Abstract

The application provides a vehicle function verification method and system, which comprises the following steps: defining a vehicle life cycle state and a real-time use state; based on the real behavior constraints of the vehicle in the physical world, constructing all possible combinations in the two dimensions of the vehicle life cycle state and the real-time use state to obtain a combination rule library; obtaining a vehicle function design file to be verified, traversing all logical judgment conditions and state transition conditions in the file, identifying variables and conditions related to the vehicle state, extracting state-dependent relationships implied in the test function, and forming a state combination list; traversing each state combination in the state combination list, checking the validity of each state combination in the combination rule library, and obtaining the validity verification result of the function design file. Through the scheme, design defects can be found in time during the vehicle function development stage, vehicle quality problems and safety hazards caused by mismatch with the real scene can be avoided, and the maintenance cost of the vehicle in the later stage can be reduced.

Description

Technical Field

[0001] This invention belongs to the field of automotive software development technology, and in particular relates to a vehicle function verification method and system. Background Technology

[0002] As the automotive industry evolves towards the "new four modernizations" (electrification, intelligentization, connectivity, and sharing), the electronic and electrical architecture of vehicles is becoming increasingly complex. Vehicle functions, such as advanced driver assistance systems, smart cockpits, and over-the-air (OTA) updates, are no longer independent functions implemented by a single electronic control unit (ECU), but rather complex system functions completed collaboratively by multiple distributed ECUs through network communication. This complexity presents unprecedented challenges to the design, development, and verification of vehicle functions.

[0003] In the traditional V-model development process, detailed functional design and software implementation typically reside on the left side of the V-model, while comprehensive integration testing and verification are on the right side. However, the industry lacks effective verification methods for ensuring the consistency between functional logic and the real-world physical scenarios throughout the vehicle's lifecycle during the functional design phase. Designers may define functional logic based on idealized or even illogical assumptions about vehicle states. For example, a functional designer might unintentionally design functional logic that responds to driving commands (real-time usage state) when the vehicle is in a factory state, but such a factory-state driving scenario is impossible in the physical world. If such fundamental design flaws are not detected early in development, they will be passed down and solidified into software code, ECU remapping files, and even the entire vehicle as the development process progresses. They may only be exposed in extremely subtle ways later, during software-in-the-loop (SIL), hardware-in-the-loop (HIL) testing, or even vehicle road tests, manifesting as unexplained power consumption anomalies, intermittent functional failures, or system logic conflicts. Making corrections at this point would require going back to the design phase, involving collaborative modifications across multiple departments, resulting in huge rework costs, serious project delay risks, and potential quality and safety hazards for the vehicles.

[0004] Currently, some solutions focus on post-production vehicle status management. For example, the patent "Power Management System, Vehicle and Power Management Method" (Publication No. CN115303206B) designs a power management system including a power supply device, a power management controller, a regional power distribution controller, and intelligent / non-intelligent on-board electrical equipment groups. Through components such as communication and electronic fuse switches, it achieves unified management of the vehicle's power supply and electrical equipment, generating control command sets to control the power generation device and equipment status according to the vehicle mode. Such solutions manage the vehicle's energy management or function scheduling by managing the vehicle's operating state (such as normal, sleep, collision, etc.). However, these solutions belong to the management strategies used in the actual operation phase after vehicle manufacturing. Their core purpose is to decide how to allocate resources based on the current state during operation. These are execution-level solutions, making it difficult to detect inconsistencies between functional logic and real-world scenarios during the development phase, potentially leading to quality and safety risks. Summary of the Invention

[0005] In view of this, embodiments of the present invention provide a vehicle function verification method and system to solve the problem that it is difficult to detect functional logic defects in a timely manner during the current vehicle function development stage, which can easily lead to potential quality and safety hazards in the vehicle.

[0006] In a first aspect of the present invention, a vehicle function verification method is provided, comprising: Define the vehicle lifecycle status and real-time usage status; Based on the real-world behavioral constraints of vehicles, we construct all possible combinations of vehicle lifecycle state and real-time usage state to obtain a combination rule base. Obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to vehicle state, extract the implicit state dependencies in the test function, and form a list of state combinations. Iterate through each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the functional design document.

[0007] In a second aspect of the present invention, a vehicle function verification system is provided, comprising: In a third aspect of the present invention, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable by the processor, wherein the processor executes the computer program to implement the steps of the method as described in the first aspect of the present invention.

[0008] In a fourth aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the method provided in the first aspect of the present invention.

[0009] In this embodiment of the invention, by introducing two independent but related dimensions—vehicle lifecycle state and real-time usage state—a rule base for determining the validity of state combinations is constructed. The rule base is used to automatically scan and test the vehicle's functional logic, thereby timely identifying and warning of dependencies on invalid state combinations before the vehicle's functional model or software code is solidified. This avoids vehicle quality problems and safety hazards caused by the mismatch between functional logic and real-world scenarios, improves the quality of vehicle software design, and reduces the cost of later vehicle modification and maintenance.

[0010] Meanwhile, by significantly advancing the verification process from the later stages of development to the design and modeling phase, functional logic based on invalid scenarios can be identified and eliminated at the source. This approach prioritizes prevention over remediation, avoiding the enormous modification costs and project delays caused by defects propagating to downstream stages. Based on rule bases and automated verification, software development efficiency is greatly improved, along with the coverage and accuracy of verification, avoiding the unreliability and omissions inherent in traditional manual reviews. Attached Figure Description

[0011] To more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0012] Figure 1 This is a flowchart illustrating a vehicle function verification method according to an embodiment of the present invention. Figure 2 This is a schematic diagram of the structure of a vehicle function verification system according to an embodiment of the present invention; Figure 3 This is a schematic diagram of the structure of an electronic device provided in one embodiment of the present invention. Detailed Implementation

[0013] To make the objectives, features, and advantages of this invention more apparent and understandable, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the embodiments described below are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0014] It should be understood that the terms "comprising" and other similar expressions in the specification, claims, and accompanying drawings of this invention are intended to cover a non-exclusive inclusion, such as a process, method, system, or apparatus that includes a series of steps or units and is not limited to the listed steps or units. Furthermore, "first" and "second" are used to distinguish different objects and are not intended to describe a specific order.

[0015] Please see Figure 1 A flowchart illustrating a vehicle function verification method provided in this embodiment of the invention includes: S101. Define the vehicle lifecycle status and real-time usage status; Define multiple lifecycle states of a vehicle, such as factory, transportation, normal, collision, maintenance, and showroom, and define multiple real-time usage states of a vehicle, such as hibernation, standby, comfort, driving, parking, and OTA. These two dimensions together constitute a complete description of vehicle usage scenarios.

[0016] For example, a vehicle lifecycle state definition file (usually in JSON format) is represented as follows: { "lifecycle_states": { "factory": {"id": 1, "desc": "Factory Pattern"}, "transport": {"id": 2, "desc": "transportation mode"}, "normal": {"id": 3, "desc": "Normal mode"}, "showroom": {"id": 4, "desc": "showroom mode"}, "engineering": {"id": 5, "desc": "engineering mode"}, "maintenance": {"id": 6, "desc": "maintenance mode"}, "collision": {"id": 7, "desc": "collision mode"} } } The vehicle real-time usage status definition file is represented as follows: { "realtime_states": { "stationary": {"id": 1, "desc": "stationary state"}, "driving": {"id": 2, "desc": "driving status"}, "charging": {"id": 3, "desc": "charging status"}, "upgrading": {"id": 4, "desc": "Software upgrade status"}, "diagnostic": {"id": 5, "desc": "diagnostic status"}, "emergency": {"id": 6, "desc": "emergency status"} } } S102. Based on the real-world behavioral constraints of vehicles in the physical world, construct all possible combinations of vehicle lifecycle state and real-time usage state to obtain a combination rule base. Real-world behavioral constraints refer to the behavioral constraints of vehicles in real-world scenarios, such as a vehicle being unable to drive while under maintenance. Based on the real-world behavioral constraints of vehicles in the physical world, a set of combination rules can be predefined. This rule base explicitly specifies the validity of all possible combinations between two-dimensional states, that is, which combinations are realistically possible and which combinations are physically impossible or logically invalid.

[0017] Preferably, the combination rules in the combination rule base are stored in the form of a two-dimensional matrix; wherein the vehicle life cycle state and the real-time usage state are respectively used as the rows and columns of the two-dimensional matrix, and the values ​​of the matrix elements represent the validity of the state combination.

[0018] The rule base is implemented in the form of a two-dimensional relation matrix. The rows and columns of the matrix correspond to the lifecycle state and the real-time usage state, respectively, and the value of the matrix element represents the validity of its corresponding state combination.

[0019] This process involves reading and parsing the lifecycle state definition file, reading and parsing the real-time usage state definition file, loading the state combination rule configuration file, building an in-memory rule lookup table, verifying the integrity and consistency of the basic data, and ensuring that all state definitions have corresponding entries in the rule table.

[0020] S103. Obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to vehicle state, extract the implicit state dependencies in the test function, and form a state combination list. Open the vehicle function design file (i.e., function model file) through the corresponding API interface, traverse all logical judgments and state transition conditions in the model, identify all variable references and condition judgments related to vehicle state, extract the implicit state dependencies in the functional logic, and obtain a list of state combinations.

[0021] Among them, vehicle function design files are loaded using the API of the modeling tool; Traverse the functional design documents, identify the logical judgment module based on keywords, and extract the logical judgment conditions and state transition conditions; In the extracted logical judgment conditions and state transition conditions, variables and conditions related to the vehicle state are identified by naming rules or a predefined list of state variables. For each functional logic, the identified vehicle state-related variables and conditions are combined. Each combination represents a set of state conditions for a functional logic to be activated or executed. The sets of state conditions are integrated into a list to form a list of state combinations.

[0022] Use the API of a modeling tool (such as Simulink) to load the functional model file. For example, in Matlab, use the load_system function to get the root system of the model and prepare for recursive traversal.

[0023] Traverse the logic judgment modules and state transition conditions to identify the logic judgment modules, such as conditional execution subsystems (e.g., Enabled Subsystem, Triggered Subsystem), which include logic judgment modules such as Switch, MultiportSwitch, and If, as well as state transitions in the Stateflow chart. For each identified module, extract its conditional logic. For example, for Switch modules, extract the control input and judgment threshold; for If modules, extract the conditional expression; and for Stateflow, extract the monitoring conditions and actions for state transitions.

[0024] Identify vehicle state-related variables and conditions. In the extracted conditional expressions, identify variables related to the vehicle state through naming rules or a predefined list of state variables. For example, variable names may contain State, Mode, Status, etc. Record how these variables are used in the conditional expressions, such as comparison operations like equal to, not equal to, and greater than.

[0025] For each functional logic (e.g., a subsystem or state diagram), the identified state variables and conditions are combined, with each combination representing a set of state conditions that activates or executes that functional logic. All these combinations are compiled into a list, with each entry representing: functional logic identifier, required state conditions (possibly a set of values ​​for state variables).

[0026] For example, the structured data of the state combination list is as follows: "function": "Automatic Emergency Braking" / / Function Name: Vehicle Automatic Emergency Braking System "required_states": [ / / List of state conditions that must be met for this function to be activated] {"variable": "VehicleMode" / / State variable: Vehicle operating mode "value": "Normal" / / Required value: Must be in normal mode (not special modes such as transportation or engineering)}, {"variable": "DrivingState" / / State variable: vehicle driving state "value": "Moving" / / Required value: Must be in a moving state (not stationary). {"variable": "CollisionWarning" / / State variable: forward collision warning system status} "value": "Active" / / Required value: Must be active (collision risk detected) ] "function": "Adaptive Cruise Control", / / Function Name: Adaptive Cruise Control System "required_states": [ / / List of state conditions that must be met for this function to be activated] {"variable": "VehicleMode" / / State variable: Vehicle operating mode "value": "Normal" / / Required value: Must be in normal mode }, {"variable": "DrivingState" / / State variable: vehicle driving state "value": "Moving" / / Required value: Must be in a moving state }, {"variable": "CruiseControlStatus" / / Status variable: Cruise control master switch status "value": "Enabled" / / Required value: Must be enabled (the driver has manually activated cruise control). } ] Record the specific location of each state combination in the model (module path, line number, etc.), and output the parsed state dependency list, in the format: [("Factory", "Driving", "Module Path A"), ("Normal", "Parking", "Module Path B"), ...].

[0027] S104. Traverse each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the functional design document.

[0028] Iterate through each state combination in the state dependency list. For each state combination, check its validity in the rule table by executing the query: Validity flag = Rule table [L_i][U_j], where [L_i][U_j] represents the state combination. Record each query result to obtain the validity verification results of the functional design document.

[0029] This involves distinguishing between valid and invalid combinations in the validity verification results, and classifying invalid combinations by severity (e.g., serious error, warning).

[0030] The validity check result list may include: valid state combinations and their locations; invalid state combinations and their locations and severity; and statistical information on the number of valid and invalid combinations.

[0031] For example, a valid combination of states may include: normal mode, driving state -> autonomous driving module; factory mode, stationary state -> software flashing station; location: emergency call function.

[0032] Invalid state combinations may include: collision mode, driving state -> high risk; location: factory inspection program; reason: factory mode prohibits activation of autonomous driving.

[0033] In this embodiment, by significantly advancing the verification process from the later stages of development to the design and modeling phase, functional logic based on invalid scenarios can be identified and eliminated at the source. This approach prioritizes prevention over remediation, avoiding the enormous modification costs and project delays caused by defects propagating to downstream stages. The rule base and verification engine automate the checking of scenario authenticity, replacing the unreliable, inefficient, and easily overlooked traditional methods relying on manual review by designers. This greatly improves the coverage, efficiency, and accuracy of verification, thereby enhancing development efficiency and automation.

[0034] Meanwhile, to address the verification blind spots at the design layer, a verification method is proposed to ensure the consistency between the vehicle's design intent and physical reality, which can complement existing technologies. By forcibly excluding illogical functional scenarios, it can effectively prevent unexpected functional activation or failure of the vehicle under specific conditions, thereby improving the functional safety and behavioral reliability of the vehicle's electronic and electrical systems from the design source. Based on the concept of state decoupling and the rule-based verification mechanism, it does not depend on specific vehicle platforms or hardware architectures and can be seamlessly integrated into mainstream model-based development processes and toolchains, possessing good versatility and scalability.

[0035] In one embodiment, building the combined rule base in step S102 further includes: The combined rule base is integrated into the design and / or verification phases of vehicle functions. In the design phase, the combined rule base is integrated into the design environment of the functional model, and in the verification phase, the functional model is integrated into a software-in-the-loop or hardware-in-the-loop test platform.

[0036] Optionally, during the design phase, the vehicle functional design documents can be scanned through static analysis or simulation testing; during the verification phase, the vehicle functional design documents can be automatically scanned using test scripts.

[0037] During the design phase, integrating the rule base into the model-based design environment allows for the scanning of the functional model through static analysis or simulation testing to identify whether there are any state combinations that are deemed invalid by the rule base. During the verification phase, the rule base is integrated into the software-in-the-loop or hardware-in-the-loop test platform. The test script automatically or semi-automatically traverses the state combinations in the functional model and judges whether the state combination response of the tested function meets expectations based on the rule base.

[0038] In one embodiment, step S103, which extracts the implicit state dependencies in the test function and forms a list of state combinations, further includes: Obtain the state dependencies from the list of state combinations, evaluate the confidence of the inclusion dependencies and mutual exclusion dependencies in the state dependencies, and add the confidence evaluation results to the state dependencies; For dependencies, the confidence level is calculated according to the formula: Conf = E i / E j ; In the formula, Conf represents the confidence level of including dependencies, and E i E j Different state variables; For mutually exclusive dependencies, the confidence level is represented as 1.0.

[0039] Calculate the confidence level for both containment dependencies and mutual exclusion dependencies. Calculate the containment dependency Conf = E. i / E j The smaller the ratio (closer to 0), the higher the confidence level. For mutually exclusive dependencies, the confidence level is always high (1.0). Thus, a list of dependencies with confidence levels can be obtained.

[0040] In one embodiment, step S103 further includes: When an abnormal vehicle state variable or condition is detected, based on predefined vehicle function permissions, the state dependencies and parameter constraints under the functional scenario are obtained by extracting the function state mapping and logical relationship deduction. If any anomalies or warnings (such as undefined state variables) are found during the functional model parsing and detection process, the state dependencies and parameter constraints in the scenario are obtained through logical deduction based on the predefined vehicle function permission matrix (XML format).

[0041] In some embodiments, the analysis of dependencies between functions (such as function A requiring function B to be activated first) includes: If the set of allowed states of function A is a proper subset of function B, then the operating environment of A is more stringent and may depend on B as a basic or prerequisite function. Input an XML-formatted function permission matrix, and iterate through each one. <function>Nodes, extract function names,<allowed_states> and<prohibited_states> content; Expand the state description with wildcards into specific state combinations, calculate the valid allowed set E_i = A_i->P_i for each function F_i, and output: function-state set mapping table; Based on the function-state set mapping table, calculate the set relationship for each pair of functions (F_i, F_j), and determine mutual exclusion: E_i ∩ E_j = Inclusion check: E_i E_j or E_j Intersection calculation: I_ij = E_i ∩ E_j. For inclusion relations, determine whether it is a proper subset E_i. E_j. Output the set relation matrix between function pairs; Applying inference rules to handle mutually exclusive dependency rules based on set relations: If E_i ∩ E_j = Then F_i and F_j are mutually exclusive; dependency rule: if E_i If E_j, then F_i → F_j (F_i may depend on F_j).

[0042] Intersection analysis: If I_ij ≠ Furthermore, since there is no inclusion relationship, calculate the ratio of |E_i| / |E_j|. If the ratio is small, then F_i may be weakly dependent on F_j.

[0043] The final result is a set of state dependencies.

[0044] In one embodiment, the step of verifying the validity of each state combination in the combination rule base and outputting the validity verification result of the functional design document further includes: Based on the degree of impact of conflicting combinations in the validity verification results, the validity verification results are prioritized and sorted, and the conflicting state combinations, conflicting design locations, consequences analysis, and remediation suggestions are identified in the validity verification results. Integrate the validity verification results into the software development environment to visually display the location of conflicting designs.

[0045] By analyzing the conflict combinations in the validity verification results, and based on the preset severity threshold, combined with functional safety standards (such as ISO 26262 ASIL level), the impact of conflicts involving vehicle safety, core functions, user experience, etc., can be prioritized.

[0046] The validity verification results may trigger a chain reaction of critical conflict combinations, such as: collision mode + driving status: safety system misjudgment may lead to incorrect airbag activation or power interruption, causing a secondary accident. Charging status + high-speed driving: battery management and power system logic conflict may lead to high-voltage power failure or drive failure.

[0047] The conflict analysis outputs a priority list of design conflicts, with each conflict combination including: the state combination of the conflict, its specific location in the model, possible consequences analysis, and remediation recommendations.

[0048] Integrate conflict detection results into the development environment, visually mark problem locations in design tools, and generate standardized validation reports. Output visual error / warning markers integrated into the IDE, such as standardized HTML / PDF format validation reports or machine-readable validation result files (JSON / XML format), and can output validation summary statistics (total number of checks, number of problems, pass rate, etc.).

[0049] For example, the automatic door locking function can be activated in any lifecycle state. The system automatically iterates through the validity checks and finds that "Factory" and "Driving" are marked as "invalid" in the rule table. The system determines this to be a "critical" design conflict because driving scenarios are unlikely to occur in a real factory environment. A red warning is marked at the automatic door locking logic block in the functional model (functional design document), and a detailed report is generated indicating the problem. The developers modify the logic, adding the condition "and the lifecycle state is 'normal'", and after re-validation, the warning is removed.

[0050] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.

[0051] Figure 2 This is a schematic diagram of a vehicle function verification system provided in an embodiment of the present invention. The system includes: The state definition module 210 is used to define the vehicle lifecycle state and real-time usage state; The rule base construction module 220 is used to construct all possible combinations of vehicle lifecycle state and real-time usage state based on the real behavioral constraints of the vehicle in the physical world, and obtain a combined rule base. Optionally, the combination rules in the combination rule base are stored in the form of a two-dimensional matrix; wherein the vehicle life cycle state and the real-time usage state are respectively used as the rows and columns of the two-dimensional matrix, and the values ​​of the matrix elements represent the validity of the state combination.

[0052] The state extraction module 230 is used to obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to the vehicle state, extract the implicit state dependencies in the test function, and form a state combination list. Among them, vehicle function design files are loaded using the API of the modeling tool; Traverse the functional design documents, identify the logical judgment module based on keywords, and extract the logical judgment conditions and state transition conditions; In the extracted logical judgment conditions and state transition conditions, variables and conditions related to the vehicle state are identified through naming rules or a predefined list of state variables. For each functional logic, the identified vehicle state-related variables and conditions are combined. Each combination represents a set of state conditions for a functional logic to be activated or executed. The sets of state conditions are integrated into a list to form a list of state combinations.

[0053] The function verification module 240 is used to traverse each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the function design document.

[0054] Optionally, the function verification module 240 includes: The sorting unit is used to prioritize the validity verification results based on the degree of influence of conflicting combinations in the validity verification results, and to identify conflicting state combinations, conflicting design locations, consequence analysis, and remediation suggestions in the validity verification results; An integrated display unit is used to integrate validity verification results into the software development environment and visually display the location of conflicting designs.

[0055] In one embodiment, the rule base construction module 220 further includes: The rule integration unit is used to integrate the combined rule base into the design and / or verification phases of vehicle functions. In the design phase, the combined rule base is integrated into the design environment of the functional model. In the verification phase, the functional model is integrated into a software-in-the-loop or hardware-in-the-loop test platform.

[0056] Optionally, during the design phase, the vehicle functional design documents can be scanned through static analysis or simulation testing; during the verification phase, the vehicle functional design documents can be automatically scanned using test scripts.

[0057] In one embodiment, the state extraction module 230 further includes: The confidence assessment unit is used to obtain the state dependencies in the state combination list, assess the confidence of the inclusion dependencies and mutual exclusion dependencies in the state dependencies, and add the confidence assessment results to the state dependencies. For dependencies, the confidence level is calculated according to the formula: Conf = E i / E j ; In the formula, Conf represents the confidence level of including dependencies, and E i E j Different state variables; For mutually exclusive dependencies, the confidence level is represented as 1.0.

[0058] In one embodiment, the function verification module 240 further includes: The anomaly extraction unit is used to obtain the state dependencies and parameter constraints in a functional scenario by extracting functional state mappings and logical relationship deductions based on predefined vehicle function permissions when an anomaly in vehicle state variables or conditions is detected.

[0059] Those skilled in the art will understand that, for the sake of convenience and brevity, the specific working process of the system and modules described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0060] Figure 3 This is a schematic diagram of an electronic device according to an embodiment of the present invention. The electronic device is used for vehicle function verification. Figure 3 As shown, the electronic device 30 of this embodiment includes: a memory 310, a processor 320, and a system bus 330. The memory 310 includes an executable program 3101 stored thereon. As those skilled in the art will understand, Figure 3 The electronic device structure shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0061] The following is combined with Figure 3 A detailed description of each component of the electronic device 30 is provided below: The memory 310 can be used to store software programs and modules. The processor 320 executes various functional applications and data processing of the electronic device by running the software programs and modules stored in the memory 310. The memory 310 may mainly include a program storage area and a data storage area. The program storage area may store the operating system, application programs required for at least one function (such as sound playback function, image playback function, etc.), etc.; the data storage area may store data created according to the use of the electronic device (such as cached data), etc. In addition, the memory 310 may include high-speed random access memory, and may also include non-volatile memory, such as at least one disk storage device, flash memory device, or other volatile solid-state storage device.

[0062] The memory 310 contains an executable program 3101 for vehicle function verification. This executable program 3101 can be divided into one or more modules / units, which are stored in the memory 310 and executed by the processor 320 to perform vehicle function scenario authenticity verification, etc. Each module / unit can be a series of computer program instruction segments capable of performing a specific function, describing the execution process of the executable program 3101 in the electronic device 30. For example, the executable program 3101 can be divided into functional modules such as a state definition module, a rule base construction module, a state extraction module, and a function verification module.

[0063] The processor 320 is the control center of the electronic device. It connects various parts of the electronic device via various interfaces and lines. By running or executing software programs and / or modules stored in the memory 310, and by calling data stored in the memory 310, it performs various functions and processes data, thereby monitoring the overall status of the electronic device. Optionally, the processor 320 may include one or more processing units; preferably, the processor 320 may integrate an application processor and a modem processor, wherein the application processor mainly handles the operating system, application programs, etc., and the modem processor mainly handles wireless communication. It is understood that the modem processor may also not be integrated into the processor 320.

[0064] The system bus 330 is used to connect various functional components within the computer, transmitting data, address, and control information. Its type can be, for example, a PCI bus, an ISA bus, or a CAN bus. Instructions from the processor 320 are transmitted to the memory 310 via the bus, and the memory 310 sends data back to the processor 320. The system bus 330 is responsible for data and instruction exchange between the processor 320 and the memory 310. Of course, the system bus 330 can also connect to other devices, such as network interfaces and display devices.

[0065] In this embodiment of the invention, the executable program executed by the processor 320 included in the electronic device includes: Define the vehicle lifecycle status and real-time usage status; Based on the real-world behavioral constraints of vehicles, we construct all possible combinations of vehicle lifecycle state and real-time usage state to obtain a combination rule base. Obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to vehicle state, extract the implicit state dependencies in the test function, and form a list of state combinations. Iterate through each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the functional design document.

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

[0067] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0068] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.< / function>

Claims

1. A method for verifying vehicle functions, characterized in that, include: Define the vehicle lifecycle status and real-time usage status; Based on the real-world behavioral constraints of vehicles, we construct all possible combinations of vehicle lifecycle state and real-time usage state to obtain a combination rule base. Obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to vehicle state, extract the implicit state dependencies in the test function, and form a list of state combinations. Iterate through each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the functional design document.

2. The method according to claim 1, characterized in that, The combined rules in the combined rule base are stored in the form of a two-dimensional matrix; In this model, the vehicle lifecycle state and real-time usage state are represented as rows and columns of a two-dimensional matrix, respectively, and the values ​​of the matrix elements indicate the validity of the state combination.

3. The method according to claim 1, characterized in that, The construction of all possible combinations across the two dimensions of vehicle lifecycle state and real-time usage state, resulting in a combination rule base, also includes: The combined rule base is integrated into the design and / or verification phases of vehicle functions. In the design phase, the combined rule base is integrated into the design environment of the functional model. In the verification phase, the functional model is integrated into a software-in-the-loop or hardware-in-the-loop test platform.

4. The method according to claim 3, characterized in that, The integration of the combined rule base into the design and / or verification phases of vehicle functions also includes: During the design phase, the vehicle functional design documents are scanned through static analysis or simulation testing. During the verification phase, test scripts are used to automatically scan the vehicle's functional design documents.

5. The method according to claim 1, characterized in that, The process involves obtaining the vehicle function design file to be verified, traversing all logical judgment conditions and state transition conditions in the file, identifying variables and conditions related to the vehicle state, extracting the implicit state dependencies in the test function, and forming a state combination list, including: Load vehicle function design files using the API of the modeling tool; Traverse the functional design documents, identify the logical judgment module based on keywords, and extract the logical judgment conditions and state transition conditions; In the extracted logical judgment conditions and state transition conditions, variables and conditions related to the vehicle state are identified by naming rules or a predefined list of state variables. For each functional logic, the identified vehicle state-related variables and conditions are combined. Each combination represents a set of state conditions for a functional logic to be activated or executed. The sets of state conditions are integrated into a list to form a list of state combinations.

6. The method according to claim 1, characterized in that, The extraction of implicit state dependencies in the testing function to form a state combination list also includes: Obtain the state dependencies from the state combination list, evaluate the confidence of the inclusion dependencies and mutual exclusion dependencies in the state dependencies, and add the confidence evaluation results to the state dependencies; For dependencies, the confidence level is calculated according to the formula: Conf = E i / AND j ; In the formula, Conf represents the confidence level of including dependencies, and E i E j Different state variables; For mutually exclusive dependencies, the confidence level is represented as 1.

0.

7. The method according to claim 1, characterized in that, The process of identifying variables and conditions related to vehicle state, extracting implicit state dependencies from the test function, and forming a state combination list also includes: When an abnormal vehicle state variable or condition is detected, the state dependency and parameter constraints under the functional scenario are obtained by extracting the functional state mapping and logical relationship deduction based on the predefined vehicle function permissions.

8. The method according to claim 1, characterized in that, The process of verifying the validity of each state combination in the rule base and outputting the validity verification results of the functional design document includes: Based on the degree of impact of conflicting combinations in the validity verification results, the validity verification results are prioritized and sorted, and the conflicting state combinations, conflicting design locations, consequences analysis, and remediation suggestions are identified in the validity verification results. Integrate the validity verification results into the software development environment to visually display the location of conflicting designs.

9. A vehicle function verification system, characterized in that, include: The state definition module is used to define the vehicle's lifecycle state and real-time usage state; The rule base construction module is used to construct all possible combinations of vehicle lifecycle state and real-time usage state based on the real behavioral constraints of vehicles in the physical world, thus obtaining a combined rule base. The state extraction module is used to obtain the vehicle function design file to be verified, traverse all logical judgment conditions and state transition conditions in the file, identify variables and conditions related to the vehicle state, extract the implicit state dependencies in the test function, and form a state combination list. The functional verification module is used to traverse each state combination in the state combination list, check the validity of each state combination in the combination rule base, and output the validity verification result of the functional design document.

10. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of a vehicle function verification method as described in any one of claims 1 to 8.

Images