System verification method and device, electronic equipment and storage medium

Abstract

The invention discloses a system verification method and device, electronic equipment and a storage medium. The method comprises the steps that current configuration information and to-be-verified parameters of a vehicle system are acquired; the current configuration information is used for representing a hardware configuration state and a software configuration state of the vehicle system at the current moment; determining service information corresponding to the current configuration information; the service information is used for providing a preset function; establishing an automaton model based on the service information and the to-be-verified parameters; and inputting the automaton model into the formalized verification model, and outputting verification data. According to the method, the corresponding automaton model is established according to the real-time configuration information and the to-be-verified parameters, and the formalized model is input to realize formalized verification, so that the vehicle can perform formalized verification on the system performance under any configuration, and the adaptability and reliability of the system are improved; and meanwhile, each function of the vehicle system is packaged in the service, so that subsequent calling is facilitated, the verification speed of the system is accelerated, and the verification efficiency of the system is improved.

Description

Technical Field

[0001] The present application relates to the field of autonomous driving technology, and in particular to a system verification method, device, electronic device and storage medium. Background Art

[0002] Modern Driver Assistance Systems (DAS) support the driver in many situations, such as lane keeping assistance and automatic emergency braking.

[0003] As the functions and supported driving situations of driver assistance systems increase, the complexity of the systems increases significantly. Different types of vehicles and driving applications require different configurations of assistance systems. For example, a trailer system may disconnect or connect one or more trailers to form various systems during operation. This variability and heterogeneity makes it difficult for a single software architecture to adapt to all needs and changes. At the same time, during the testing process, changes in vehicle configuration, failures in the vehicle's electronic control unit (ECU) or sensor system may result in the need to dynamically reconfigure the system. Therefore, existing verification methods cannot adapt to real-time changes in vehicle driving systems and achieve rapid reconfiguration, which in turn makes the testing and verification of various performance of driver assistance systems complicated and time-consuming. Summary of the invention

[0004] In order to solve the technical problem that the existing system verification method cannot adapt to the real-time changing vehicle driving system, which makes the system verification complicated and time-consuming, the present invention provides a system verification method, device, electronic device and storage medium. According to the real-time configuration information and the parameters to be verified, the corresponding automaton model is established, and the formal model is input, and the verification data is output to realize formal verification, which ensures that the system performance can be formally verified under any configuration of the vehicle, thereby improving the adaptability and reliability of the system; at the same time, the various functions of the vehicle system are encapsulated in the service to facilitate subsequent calls, accelerate the verification speed of the system, and improve the verification efficiency of the system.

[0005] In a first aspect, an embodiment of the present application provides a system verification method, the method comprising:

[0006] Obtain the current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to represent the hardware configuration status and software configuration status of the vehicle system at the current moment;

[0007] Determine the service information corresponding to the current configuration information; the service information is used to provide preset functions;

[0008] Based on the service information and the parameters to be verified, an automaton model is established;

[0009] The automaton model is input into the formal verification model and verification data is output; the verification data is used to characterize the performance of the vehicle system under the current configuration information and parameters to be verified.

[0010] In an optional embodiment, determining the service information corresponding to the current configuration information includes:

[0011] Obtaining a basic service information set corresponding to the original configuration information; the original configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the initial moment; the basic service information set includes multiple basic service information;

[0012] Determine basic service information corresponding to the current configuration information from multiple basic service information;

[0013] Determine new configuration information based on the current configuration information and the original configuration information;

[0014] Determine new service information based on the new configuration information;

[0015] Based on the newly added service information and basic service information corresponding to the current configuration information, the service information corresponding to the current configuration information is determined.

[0016] In an optional embodiment, determining the newly added service information based on the newly added configuration information includes:

[0017] Determine the new activity flow based on the new configuration information;

[0018] Establish new service information based on the new activity process.

[0019] In an optional embodiment, the newly added activity flow includes a plurality of activity step information, sequence flow information between the plurality of activity step information, and data transfer information between the plurality of activity step information;

[0020] Based on the new activity process, establish new service information, including:

[0021] Determine a service module based on multiple activity step information and sequential process information; the service module includes a main service module and a sub-service module;

[0022] Based on the data transmission information, determine the interface connection relationship between the service modules;

[0023] Determine new service information based on the main service module, sub-service module, and interface connection relationship.

[0024] In an optional embodiment, an automaton model is established based on the service information and the parameters to be verified, including:

[0025] Based on the service information and the parameters to be verified, a service contract is formed;

[0026] Based on the interface connection relationship in the service information, an interface automaton model is established;

[0027] Based on the service contract, a contract automaton model is established;

[0028] Based on the interface automaton model and the contract automaton model, the automaton model is determined.

[0029] In an optional embodiment, a service contract is formed based on the service information and the parameters to be verified, including:

[0030] For each group of service modules with interface connection relationship:

[0031] The service module that sends data is regarded as a data supply module, and the service module that receives data is regarded as a data consumption module;

[0032] Defining a service contract between a data supply module and a data consumption module; the service contract includes at least one of a data format, an operation parameter, and a business rule;

[0033] Based on the parameters to be verified and the service contract, a service contract is formed between the data supply module and the data consumption module;

[0034] Based on the service contract between the data provision module and the data consumption module, a service contract for the vehicle system is determined.

[0035] In an optional embodiment, after the automaton model is input into the formal verification model and the verification data is output, the following further comprises:

[0036] Get the preset verification threshold;

[0037] If the verification data is less than or equal to a preset verification threshold, adjusting the parameters to be verified, updating the automaton model to obtain an updated automaton model, inputting the updated automaton model into the formal verification model, and outputting the verification data; or;

[0038] If the verification data is greater than a preset verification threshold, it is determined that the automaton model meets the verification performance.

[0039] In an optional embodiment, the verification data includes at least one of reliability data, reachability data, and security data.

[0040] In a second aspect, an embodiment of the present application provides a system verification device, the device comprising:

[0041] The acquisition module is used to acquire the current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment;

[0042] A determination module is used to determine the service information corresponding to the current configuration information; the service information is used to provide a preset function;

[0043] A modeling module, used to build an automaton model based on service information and parameters to be verified;

[0044] The verification module is used to input the automaton model into the formal verification model and output verification data; the verification data is used to characterize the performance of the vehicle system under the current configuration information and parameters to be verified.

[0045] In a third aspect, an embodiment of the present application provides an electronic device, comprising a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, at least one program, a code set or an instruction set is loaded and executed by the processor to implement the system verification method of the first aspect.

[0046] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which at least one instruction or at least one program is stored, and the at least one instruction or at least one program is loaded and executed by a processor to implement the system verification method of the first aspect.

[0047] In a fifth aspect, an embodiment of the present application provides a computer program product or a computer program, the computer program product or the computer program including computer instructions, the computer instructions being stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, so that the computer device executes the system verification method of the first aspect.

[0048] The system verification method, device, electronic device, and storage medium provided in the embodiments of the present application have the following technical effects:

[0049] Obtain the current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to characterize the hardware configuration status and software configuration status of the vehicle system at the current moment; determine the service information corresponding to the current configuration information; the service information is used to provide preset functions; based on the service information and the parameters to be verified, establish an automaton model; input the automaton model into the formal verification model and output verification data; the verification data is used to characterize the performance of the vehicle system, and according to the real-time configuration information and the parameters to be verified, establish the corresponding automaton model, input the formal model, output verification data, and implement formal verification, which ensures that the vehicle can formally verify the system performance under any configuration, thereby improving the adaptability and reliability of the system; at the same time, encapsulate the various functions of the vehicle system in the service to facilitate subsequent calls, speed up the verification of the system, and improve the verification efficiency of the system. BRIEF DESCRIPTION OF THE DRAWINGS

[0050] In order to more clearly illustrate the technical solutions and advantages in the embodiments of the present application or the prior art, the drawings required for use in the embodiments or the prior art descriptions are briefly introduced below. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0051] Figure 1 is a schematic diagram of an application environment provided by an embodiment of the present application;

[0052] Figure 2 This is a schematic diagram of a system verification method provided in an embodiment of the present application. Figure 1 ;

[0053] Figure 3 This is a schematic diagram of a system verification method provided in an embodiment of the present application. Figure 2 ;

[0054] Figure 4 It is a flowchart of a method for determining service information corresponding to current configuration information provided by an embodiment of the present application;

[0055] Figure 5 It is a flowchart of a method for establishing an automaton model provided in an embodiment of the present application;

[0056] Figure 6 is an activity flow chart of an automatic driving process of a trailer system provided by an embodiment of the present application;

[0057] Figure 7 is a trailer trajectory calculation service interface diagram provided by an embodiment of the present application;

[0058] Figure 8 is a schematic diagram of a service contract provided in an embodiment of the present application;

[0059] Fig. 9 is a schematic diagram of an interface automaton provided in an embodiment of the present application;

[0060] Fig.10 is a schematic diagram of a contract automaton provided in an embodiment of the present application;

[0061] Fig.11 It is a structural diagram of a system verification device provided in an embodiment of the present application;

[0062] Fig.12 It is a hardware structure block diagram of a server of a system verification method provided in an embodiment of the present application. DETAILED DESCRIPTION

[0063] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0064] It should be noted that the terms "first", "second", etc. in the specification and claims of the present application and the above-mentioned drawings are used to distinguish similar objects, and are not necessarily used to describe a specific order or sequence. It should be understood that the data used in this way can be interchangeable where appropriate, so that the embodiments of the present application described herein can be implemented in an order other than those illustrated or described herein. In addition, the terms "including" and "having" and any of their variations are intended to cover non-exclusive inclusions, for example, a process, method, system, product or server that includes a series of steps or units is not necessarily limited to those steps or units clearly listed, but may include other steps or units that are not clearly listed or inherent to these processes, methods, products or devices.

[0065] See also Figure 1 , Figure 1 1 is a schematic diagram of an application environment provided by an embodiment of the present application, including an information detection device 101 and a server 102. The information detection device 101 and the server 102 are connected to each other by a wired link or a wireless link, which is not limited in the present application.

[0066] In a possible embodiment, the information detection device 101 is used to obtain current configuration information of the vehicle system.

[0067] Specifically, the configuration information includes hardware configuration status and software configuration status. A vehicle system is configured with a variety of hardware devices, such as specific sensors, controllers, batteries, power supplies, etc. The above hardware devices are driven or turned on by the corresponding software to perform normal work. By obtaining the hardware configuration status, the vehicle system can obtain the connection status of various hardware devices in real time, such as whether specific sensors, controllers, batteries, power supplies, etc. are configured. By obtaining the software configuration status, the vehicle system can obtain the working status of various hardware devices in real time, such as whether specific sensors, controllers, batteries, power supplies, etc. are enabled. By combining the hardware configuration status and the software configuration status, the vehicle system can grasp the currently available functions and perform subsequent vehicle system modeling.

[0068] In the implementation of this application, the information detection device 101 may include a data sensor interface for reading various sensors (such as temperature sensors, pressure sensors, etc.), and may also include a communication interface for communicating with various hardware devices inside the vehicle to obtain their current working status and configuration information. The information detection device 101 obtains and updates the configuration information of the vehicle system in real time, and sends it to the server 102 for subsequent vehicle system modeling.

[0069] In a possible embodiment, the server 102 is used to receive various information detected by the information detection device 101, and obtain the current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to characterize the hardware configuration status and software configuration status of the vehicle system at the current moment; determine the service information corresponding to the current configuration information; the service information is used to provide preset functions; based on the service information and the parameters to be verified, establish an automaton model; input the automaton model into the formal verification model, and output verification data; the verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified, and according to the real-time configuration information and the parameters to be verified, establish the corresponding automaton model, input the formal model, output the verification data, and implement formal verification, thereby ensuring that the vehicle can formally verify the system performance under any configuration, thereby improving the adaptability and reliability of the system; at the same time, encapsulating the various functions of the vehicle system in the service to facilitate subsequent calls, speed up the verification speed of the system, and improve the verification efficiency of the system.

[0070] The following describes a specific embodiment of a system verification method of the present application. Figure 2 This is a schematic diagram of a system verification method provided in an embodiment of the present application. Figure 1 , this specification provides method operation steps such as embodiments or flow charts, but may include more or fewer operation steps based on routine or non-creative work. The order of steps listed in the embodiments is only one way of executing the steps among many orders, and does not represent the only order of execution. When the actual system or server product is executed, it can be executed in the order of the method shown in the embodiments or the drawings or in parallel (for example, in a parallel processor or multi-threaded processing environment). Specifically, Figure 2 As shown, the method is applied to the server and may include:

[0071] S201: Acquire current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment.

[0072] S202: Determine service information corresponding to the current configuration information; the service information is used to provide preset functions.

[0073] S203: Establishing an automaton model based on the service information and the parameters to be verified.

[0074] S204: Input the automaton model into the formal verification model and output verification data; the verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified.

[0075] Figure 3 This is a schematic diagram of a system verification method provided in an embodiment of the present application. Figure 2 , the method may include:

[0076] S301: Obtain current configuration information and parameters to be verified of the vehicle system.

[0077] In a possible embodiment, the current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment.

[0078] Optionally, the hardware configuration status represents the status of physical devices such as sensors, actuators, and electronic control units (ECUs) of the vehicle system, specifically whether they are normal, faulty, or disconnected. The software configuration status determines whether the above-mentioned physical devices in the vehicle system are activated and started, correctly configured, or running. Combining the hardware configuration status and software configuration status can help the vehicle system understand the available functions of the current vehicle. For example, the hardware configuration status of the speed sensor represents that the speed sensor is in a normal connection state, and the software configuration status represents that the speed sensor is in a normal activation state. Then, combining the hardware configuration status and software configuration status, the vehicle system can detect the current speed information.

[0079] For example, a trailer system is a vehicle combination system that usually includes a traction unit (also called a tractor or main vehicle) and at least one trailer unit (also called a trailer). Trailer systems are widely used in the transportation industry, especially in scenarios such as cargo transportation and large equipment handling. Among them, the traction unit is the main vehicle in the trailer system, which is responsible for providing power and driving the trailer unit through traction. The trailer unit is the part driven by the traction unit, usually used to load cargo. The trailer unit does not have its own power, but relies on the traction of the traction unit to travel.

[0080] For the trailer system, when a trailer unit is added, the hardware configuration state and software configuration state of the trailer system will change. For example, when a trailer system that already has a trailer unit adds a new trailer unit after the trailer unit, the hardware devices in the new trailer unit (sensors such as rearview camera, wheel speed sensor, brake light sensor, and actuators such as trailer brake system) will be connected to the trailer system. Therefore, the autonomous driving model of the new trailer system will also change accordingly.

[0081] In one possible embodiment, the parameters to be verified represent various constraints on the vehicle system. The parameters to be verified may include time constraints. By setting time limits (such as maximum response time, minimum response time, etc.) for various services, tasks or operations of the vehicle system, it is possible to ensure that the system completes the task within the specified time to the greatest extent possible, avoiding timeouts or excessively long response times.

[0082] In another possible embodiment, the parameters to be verified may also include priority constraints. Setting priorities for different tasks or services can help the vehicle system to reasonably schedule resources and ensure that high-priority tasks are given priority in resource competition, thereby improving the efficiency of completing key tasks.

[0083] By adding constraints such as time and priority to the vehicle system, it is ensured that the vehicle system can operate efficiently, reliably and stably in a complex environment. The system verification of this application also verifies whether the vehicle system meets specific performance under the current configuration state and current constraints.

[0084] S302: Determine the service information corresponding to the current configuration information.

[0085] In the embodiment of the present application, service information is used to provide preset functions and is an independent module for implementing specific functions. By encapsulating different functions into different services, different services can be combined and coordinated to achieve different functional effects, enabling the vehicle system to flexibly and dynamically adapt to changes in hardware and software configurations.

[0086] In a possible embodiment, Figure 4 As shown, determine the service information corresponding to the current configuration information, including:

[0087] S3021: Obtain a basic service information set corresponding to the original configuration information.

[0088] In a possible embodiment, the original configuration information is used to characterize the hardware configuration state and software configuration state of the vehicle system at the initial moment; the basic service information set includes a plurality of basic service information.

[0089] S3022: Determine basic service information corresponding to the current configuration information from multiple basic service information.

[0090] S3023: Determine new configuration information based on the current configuration information and the original configuration information.

[0091] S3024: Determine new service information based on the new configuration information.

[0092] S3025: Determine the service information corresponding to the current configuration information based on the newly added service information and the basic service information corresponding to the current configuration information.

[0093] It should be noted that the newly added configuration information in this application is a new part in a broad sense, which is actually the part that is different from the original configuration and may include added parts and changed parts.

[0094] In a possible embodiment, the current configuration is a vehicle system consisting of five hardware devices A, B, C, D, and E, and the original configuration is a vehicle system consisting of three hardware devices A, B, and C, and the corresponding basic service information are a, b, and c respectively. Then, the newly added configuration is two hardware devices D and E. Subsequently, the functions of the two hardware devices D and E are encapsulated in the two newly added service information d and e. By combining the basic service information a, b, c and the newly added service information d and e, the service information a, b, c, d, e corresponding to the current configuration information can be obtained.

[0095] In another possible embodiment, the current configuration is a vehicle system consisting of three hardware devices A, B, and F, and the original configuration is a vehicle system consisting of three hardware devices A, B, and C, and the corresponding basic service information are a, b, and c respectively. Then, the newly added configuration is a hardware device F, and the function of the hardware device F is subsequently encapsulated in the newly added service information f. By combining the basic service information a, b and the newly added service information f, the service information a, b, and f corresponding to the current configuration information can be obtained.

[0096] By borrowing the basic services in the original configuration state and combining them into the service information in the current configuration state, the time for determining the service information is effectively saved and the efficiency of system verification is improved.

[0097] S303: Establishing an automaton model based on the service information and the parameters to be verified.

[0098] The automaton model is an abstract, state-based mathematical model used to describe the state of a system and the transition behavior between states. The automaton model includes state, event or input, state transition, initial state, and final state.

[0099] Those skilled in the art are well aware that formal verification is a method of verifying a system using mathematical and logical tools to ensure that the system meets set requirements under set operating conditions (such as configuration information or parameters to be tested). In order to perform formal verification, the system usually needs to be converted into a standardized mathematical model, and the automaton model is one of the common forms of this conversion.

[0100] In the embodiment of the present application, the automaton model is used to describe the various states of the service information and the jump rules between states of the vehicle system under the current configuration information and the parameters to be detected.

[0101] S304: Input the automaton model into the formal verification model and output verification data.

[0102] In a possible embodiment, formal verification is performed through constraint logic programming.

[0103] Constraint Logic Programming (CLP) is a computer programming paradigm. In CLP, various relationships can be defined between variables, and these relationships can be expressed as equations, inequalities, or other logical constraints. CLP is mainly used to solve complex problems, such as class scheduling, task scheduling, resource allocation, etc. CLP usually uses a backtracking algorithm to find a solution that meets the target conditions while satisfying all constraints.

[0104] CLP plays an important role in the formal verification of hybrid automata. Hybrid automata are mathematical models used to describe and analyze systems with both continuous and discrete dynamics. Formal verification is the process of checking whether a system satisfies characteristic properties or requirements. CLP can be used to describe the behavior and properties of hybrid automata, thereby better performing formal verification. For example, constraint logic languages ​​can be used to describe the reachable and unreachable states of hybrid automata, as well as to define properties such as the safety and reliability of the system. In addition, CLP can be used to generate test cases and simulate the behavior of hybrid automata, thereby better understanding the dynamic characteristics and properties of the system.

[0105] In an embodiment of the present application, the current hybrid state machine of the vehicle system, that is, the automaton model established based on the service information and the parameters to be verified, is written and solved using CLP to output verification data.

[0106] In an embodiment of the present application, the verification data is used to characterize specific performance of the vehicle system, such as accessibility, safety or reliability, under the current configuration information and parameters to be verified.

[0107] Specifically, the formal verification model of reachability is a model that analyzes the jump state of the automaton model through CLP, inputs the automaton model of the vehicle system, and outputs the reachability data of the vehicle system. Correspondingly, the formal verification model of safety or reliability is a model that analyzes the jump state of the automaton model through CLP, inputs the automaton model of the vehicle system, and outputs the safety or reliability of the vehicle system.

[0108] Taking the formal verification model of reachability as an example, the automaton model starts from the idle state and successfully jumps to the end state through several subsequent states. The automaton model can be considered to be in a reachable state. The automaton model has multiple paths, each of which represents a possible execution process, which describes the process of the system going from the initial state to several subsequent states until it reaches the end state. In this process, different trigger events and constraints will affect the selection and execution of the path.

[0109] By analyzing different paths through CLP, the probability of success of each path of the automaton model is obtained. If it is within the specified processing time range and can successfully reach the end state, the success probability of this path is 1; if it exceeds the time limit, the path may fail and the success probability is 0. CLP can combine all possible paths to calculate the probability of successfully reaching a reachable state. By analyzing all paths, the reachability is obtained. For example, a path may have a 50% probability of success and another path has 30%, so the overall reachability may be 80%.

[0110] S305: Obtain a preset verification threshold.

[0111] In a possible embodiment, the verifier may input a specific preset verification threshold, where the preset verification threshold is used to represent the requirements for the corresponding performance of the vehicle system.

[0112] S306: Determine whether the verification data is greater than a preset verification threshold, if so, execute S307; if not, execute S308.

[0113] In a possible embodiment, the verification data includes at least one of reliability data, accessibility data, and safety data. Reliability data is used to measure the ability of the vehicle system to operate without failure within a certain period of time, reflecting the stability and failure rate of the system. Accessibility data is used to verify whether the vehicle system can reach the expected target state or provide the required service under different configurations and parameters. Safety data is used to evaluate whether the system meets the predetermined safety standards.

[0114] In the embodiment of the present application, the verification data includes reliability data, which represents the reliability of the vehicle system by a percentage figure, such as 65% or 80%.

[0115] S307: Determine whether the automaton model satisfies verification performance.

[0116] S308: Adjust the parameters to be verified, update the automaton model to obtain an updated automaton model, and execute S304.

[0117] In a possible embodiment, if the preset verification threshold of reliability is 70%, that is, as long as the verification data is greater than the preset verification threshold, it can be considered that the current system meets the verification performance.

[0118] When the reliability data is 80%, which is greater than the preset verification threshold of 70% for reliability, it is considered that the current vehicle system meets the preset verification performance under the current configuration state and current constraints, and the formal verification of the vehicle system is completed; when the reliability data is 65%, which is less than the preset verification threshold of 70% for reliability, it is considered that the current vehicle system does not meet the preset verification performance under the current configuration state and current constraints. Therefore, the parameters to be verified are adjusted, such as increasing or decreasing the time constraint, changing the priority of the task, etc., the automaton model is updated to obtain the updated automaton model, and the formal verification of the vehicle system is re-performed.

[0119] Figure 5 : is a flow chart of a method for establishing an automaton model provided in an embodiment of the present application, and the method may include:

[0120] S401: Determine a new activity process based on the new configuration information.

[0121] In a possible embodiment, the newly added activity flow includes a plurality of activity step information, sequence flow information between the plurality of activity step information, and data transfer information between the plurality of activity step information.

[0122] In the embodiment of the present application, the activity flow is expressed in the form of an activity flow chart. For example, Figure 6 is an activity flow chart of an automatic driving process of a trailer system provided by an embodiment of the present application, such as Figure 6 As shown, the activities and processes such as reading the steering angle (Read Steering Angle) and reading the bending angle (Read Bending Angle) in the automatic driving process of the trailer system are drawn in the form of an activity flow chart, and the activity flow chart of the process simulation is extracted.

[0123] Specifically, Figure 6 As shown, the multiple active steps of the trailer system autonomous driving process include:

[0124] (1) Read Steering Angle.

[0125] (2) Calculate Trajectory Tractive Unit based on the steering angle;

[0126] (3) Read Bending Angle;

[0127] (4) Calculate Trajectory Trailer and Combination based on the tractor unit trajectory and the bending angle;

[0128] (5) Read Rear View;

[0129] (6) Overlay Trajectory and Rear View;

[0130] (7) Output on Monitor.

[0131] The traction and trailer combination model in the above steps is the trailer system mentioned above. The above seven steps are the various steps of the automatic driving activities of the trailer system. By reading the steering angle and calculating the trajectory of the traction unit based on the steering angle, and then reading the bending angle, the trajectory of the trailer system is calculated based on the trajectory of the traction unit and the bending angle, and then reading the rear view (the view behind the car seen by the driver through the rearview mirror or the on-board camera), and superimposing the trailer system trajectory on the rear view, finally displaying the trajectory of the trailer system on the rear view on the display, providing the driver with reference and assistance for driving, and avoiding traffic accidents caused by blind spots to a certain extent. The working conditions of the automatic driving of the trailer system are modeled, and the above seven activities in the hybrid system composed of the traction unit and the trailer unit are arranged in sequence, and the above activity flow chart is drawn.

[0132] The above-mentioned activity flow includes a plurality of activity step information, a sequence flow information between the plurality of activity step information, and a data transmission information between the plurality of activity step information. For example, step (1) reading the steering angle is a separate activity, and step (1) reading the steering angle must be performed before step (2) calculating the trajectory of the traction unit based on the steering angle, and step (1) transmits the steering angle information to step (2).

[0133] S402: Determine a service module based on multiple activity step information and sequential process information; the service module includes a main service module and a sub-service module.

[0134] In the embodiment of the present application, each of the above-mentioned active steps with independent functions is determined as an independent service module. For example, step (1) reading the steering angle can be used as a service module with the function of reading the steering angle.

[0135] The service module encapsulated based on the above-mentioned activity steps includes a main service module and a sub-service module. The main service module is the core function module, and the sub-service module is other service modules that are dependent on in order to complete this function. For example, the function encapsulated in step (1) of reading the steering angle is the service module for reading the steering angle, which is the sub-service module. Since it needs to rely on the data of the service module for reading the steering angle, the traction unit trajectory calculation module encapsulated in step (2) is the main service module.

[0136] S403: Determine the interface connection relationship between the service modules based on the data transfer information.

[0137] S404: Determine new service information based on the main service module, the sub-service module, and the interface connection relationship.

[0138] Specifically, service information is presented in the form of a service interface diagram, which can show the interaction, data flow, and dependency between different service modules. For example, Figure 7 is a trailer trajectory calculation service interface diagram provided by an embodiment of the present application, such as Figure 7 As shown, the trailer trajectory calculation service (CalcTrajTractiveService) in the figure is the trailer trajectory calculation activity encapsulated in step (2) as an independent service module.

[0139] The connection relationship between the trailer trajectory calculation service and other services is represented by the interface connection relationship, which is the expose and use in the figure.

[0140] The trailer trajectory calculation service (CalcTrajTractiveService) uses the trailer trajectory calculation function CalcTrajTractiveUnit() of the trailer trajectory calculation interface (《Interface》CalcTrajTractiveUnit).

[0141] The trailer trajectory calculation service (CalcTrajTractiveService) uses the steering angle reading function GetSteerAngle() of the steering angle reading interface (《Interface》GetSteerAngleRequest).

[0142] The trailer trajectory calculation service (CalcTrajTractiveService) exposes a trailer trajectory calculation capability ("ServiceInterface") through a service interface ("ServiceInterface"), which is specifically implemented through the trailer trajectory calculation function CalcTrajTractiveUnit().

[0143] Similarly, the track overlay service (OverlayService) is the service encapsulated by overlaying the track on the rear view image in step (6). It exposes a track overlay capability through the service interface and depends on the rear view reading interface (GetRearViewRequest), the track acquisition interface (GetTrajTrailCombRequest) and the track overlay interface (CalcOverlay).

[0144] In the embodiment of the present application, the method of converting other steps into services is the same as the above steps and will not be described in detail here. After completing the autonomous driving activity flow chart of the trailer system, each activity is converted into a service, and the sub-service and interface connection relationship is identified, and the continuous activities in the activity flow chart are converted into independent services, so that the complex autonomous driving system is divided into independent service modules, each of which is responsible for specific functions, such as reading information, path planning, decision-making and control, etc.

[0145] Through the above settings, each service module communicates with each other through interfaces, so that each module can be independently developed, maintained and combined, reducing the mutual dependence and strong coupling between modules and reducing the complexity of the system. Furthermore, when new functions need to be added or existing functions need to be optimized, new services can be added or individual modules can be expanded without affecting existing services. Convert certain functions in the autonomous driving activity process into independent service modules so that these functions can be reused in other scenarios or systems. For example, service modules such as path planning and obstacle detection can be reused in the modeling of other autonomous driving systems or related applications, reducing development costs and time.

[0146] S405: Determine the service information corresponding to the current configuration information based on the newly added service information and the basic service information corresponding to the current configuration information.

[0147] S406: Form a service contract based on the service information and the parameters to be verified.

[0148] In a possible embodiment, a service level agreement (SLA) is a formal agreement or document between a service provider and a service consumer, which specifies the quality, performance, responsibilities, obligations, and expectations and guarantees of both parties.

[0149] In a possible embodiment, a service contract is formed based on the service information and the parameters to be verified, including:

[0150] For each group of service modules with interface connection relationship:

[0151] S4061: The service module that sends data is used as a data supply module, and the service module that receives data is used as a data consumption module.

[0152] S4062: Define the service contract between the data supply module and the data consumption module.

[0153] In one possible embodiment, a service contract is a clearly defined agreement between services that specifies how services interact, respond, and transfer data. The service contract mainly defines the inputs that the data supply module needs to provide and the outputs returned by the data consumption module, describes the specific operations performed by the service when receiving a request, how the service handles and responds in abnormal situations, and performance indicators such as response time, throughput, and reliability.

[0154] In the embodiment of the present application, the service contract includes at least one of a data format, an operation parameter, and a business rule.

[0155] S4063: Based on the time constraint parameters and the service contract, a service contract is formed between the data supply module and the data consumption module.

[0156] Based on the service contract between the data provision module and the data consumption module, a service contract for the vehicle system is determined.

[0157] After the service interface diagram is modeled, the service contract is defined, and time constraints are added to form service performance (Quality of Service, QoS) items to form a service contract.

[0158] Figure 8 is a schematic diagram of a service contract provided in an embodiment of the present application, such as Figure 8 As shown, the QoS parameter configuration shows the sequence diagram of the Overlay Service contract and the added constraints. In the embodiment of the present application, a time constraint parameter is added, and the format of the added time constraint parameter is [minimum time, average time, maximum time], and all times are in milliseconds.

[0159] Among them, the minimum time refers to the shortest time required for the service to process a request, that is, under the most ideal circumstances, the fastest time required for the service to complete the task. The minimum time indicates the response speed of the service under the best performance conditions, which is the performance ceiling that the system can achieve under the optimal state.

[0160] The average time refers to the average time it takes for a service to process a request. It is a statistical average of all response times and reflects the typical performance of the service in most cases. The average time represents the average performance of the service in daily operation and can help evaluate the stability and efficiency of the service under normal load.

[0161] The maximum time refers to the longest time allowed for a service to process a request, that is, the slowest time required for a service to complete a task under the most extreme circumstances. The maximum time is used to specify the upper limit of the response time that a service must guarantee under the worst performance conditions.

[0162] For example Figure 8 As shown, the time constraint when the trajectory overlay interface sends data to the trajectory overlay service is [1, 2, 4], the time constraint when the trajectory overlay service returns data to the trajectory overlay interface is [1, 2, 4], and the time constraint when the trajectory overlay service processes the data is [7, 4, 22].

[0163] S407: Establishing an interface automaton model based on the interface connection relationship in the service information.

[0164] In a possible embodiment, the service interface is converted into a service interface state machine, that is, an interface automaton model.

[0165] Fig. 9 is a schematic diagram of an interface automaton provided in an embodiment of the present application, such as Fig. 9 As shown in Figure 1, the interface automaton model is used to simulate the workflow of the service and the interaction of the external interface. By default, the service is in an idle state until it is activated by an event.

[0166] When there is no external request, the interface automaton is in idle state by default. When the synchronization tag actp activates the service, the service starts to execute. The actp synchronization tag may come from the interface caller, service consumer or external system to issue a request and is responsible for switching the service from idle state to processing state.

[0167] After the processing state (Process), the service starts waiting for the input data reqX it needs. The reqX input data is usually the data submitted by the service caller when calling the service. After the service collects the input, it enters the waiting state (Waiting) and waits for the generation of the processing result repX. This step simulates the process of the service processing data. Finally, it enters the end state (Finish) and sends the end signal finp, indicating that the data processing has been completed. The finp end signal is equivalent to telling the vehicle system that the service has processed the data and entered the result output stage. When the service processing is completed and the signal is sent, it returns to the initial idle state (Idle) to prepare for the next request.

[0168] S407: Based on the service contract, establish a contract automaton model.

[0169] In a possible embodiment, the service contract is converted into a service contract state machine, that is, a contract automaton model.

[0170] Fig.10 is a schematic diagram of a contract automaton provided in an embodiment of the present application, such as Fig.10 As shown, the contract automaton is in an idle state (Idle) before the service receives the request signal reqc. When the service is called, the contract automaton receives the request signal reqc, and the reqc request starts the execution process of the entire service contract. The contract automaton enters the sending state (Send), which simulates the time required for the service to send data after receiving the request, ensuring that the service can send data or perform other operations within the specified time. When the contract automaton receives the synchronization tag actp, the contract automaton enters the waiting state (Waiting), starts to collect input and waits for the collection to be completed. When the input data is collected, the contract automaton sends a finp signal, indicating that the task in the waiting state is completed, and enters the next processing state (Process). After the processing is completed, the contract automaton simulates the generation of output data and sends the result to the requester within the specified time. After the sending is completed, the repc signal is sent, indicating that the entire service interaction process is over, and returns to the idle state (Idle), indicating that the contract automaton can continue.

[0171] S408: Determine the automaton model based on the interface automaton model and the contract automaton model.

[0172] In the embodiment of the present application, the automaton model for formal verification includes an interface automaton model and a contract automaton model. By establishing the interface automaton model and the contract automaton model, the various states of the service interface and the service contract are described respectively. Since the automaton model clearly defines the state jump rules, these states can help verify whether the operation of the system meets expectations. Furthermore, the automaton model converts the service operation logic and contract constraints into a mathematical model, and then uses formal verification tools to verify whether the vehicle system meets the requirements of reliability, safety, and accessibility.

[0173] The present application also provides a system verification device. Fig.11 is a schematic diagram of the structure of a system verification device provided in an embodiment of the present application, such as Fig.11 As shown, the device 500 includes:

[0174] The acquisition module 501 is used to acquire the current configuration information and the parameters to be verified of the vehicle system; the current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment;

[0175] Determination module 502, used to determine the service information corresponding to the current configuration information; the service information is used to provide a preset function;

[0176] A modeling module 503, for establishing an automaton model based on service information and parameters to be verified;

[0177] The verification module 504 is used to input the automaton model into the formal verification model and output verification data; the verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified.

[0178] In an optional implementation, it also includes:

[0179] A first acquisition module, used to acquire a preset verification threshold;

[0180] A first verification module is used to adjust the parameters to be verified if the verification data is less than or equal to a preset verification threshold, update the automaton model to obtain an updated automaton model, input the updated automaton model into a formal verification model, and output the verification data; or;

[0181] The determination module is used to determine whether the automaton model meets the verification performance if the verification data is greater than a preset verification threshold.

[0182] In an optional implementation, the verification data includes at least one of reliability data, reachability data, and security data.

[0183] In an optional implementation, it also includes:

[0184] The second acquisition module is used to acquire a basic service information set corresponding to the original configuration information; the original configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the initial moment; the basic service information set includes a plurality of basic service information;

[0185] A first determining module, used to determine basic service information corresponding to the current configuration information from multiple basic service information;

[0186] A second determination module, configured to determine newly added configuration information based on the current configuration information and the original configuration information;

[0187] A third determination module, configured to determine the newly added service information based on the newly added configuration information;

[0188] The fourth determining module is used to determine the service information corresponding to the current configuration information based on the newly added service information and the basic service information corresponding to the current configuration information.

[0189] In an optional implementation, it also includes:

[0190] A fifth determination module, used to determine a newly added activity flow based on the newly added configuration information;

[0191] The first creation module is used to establish new service information based on the new activity process.

[0192] In an optional implementation manner, the newly added activity flow includes multiple activity step information, sequential flow information between the multiple activity step information, and data transfer information between the multiple activity step information; and also includes:

[0193] a sixth determination module, configured to determine a service module and a sub-service module based on a plurality of activity step information and sequence process information;

[0194] A seventh determination module, used to determine the interface connection relationship between the service modules based on the data transmission information;

[0195] The eighth determination module is used to determine the newly added service information based on the service module, the sub-service module, and the interface connection relationship.

[0196] In an optional implementation manner, the service information includes an interface connection relationship; and further includes:

[0197] A first forming module, for forming a service contract based on the service information and the parameters to be verified;

[0198] The second creation module is used to establish an interface automaton model based on the interface connection relationship in the service information;

[0199] The third creation module is used to establish a contract automaton model based on the service contract;

[0200] The eighth determination module is used to determine the automaton model based on the interface automaton model and the contract automaton model.

[0201] In an optional implementation manner, the parameter to be verified includes a time constraint parameter; the service information also includes a service module; and further includes:

[0202] For each group of service modules with interface connection relationship:

[0203] A ninth determination module, configured to use the service module that sends data as a data supply module and the service module that receives data as a data consumption module;

[0204] A definition module, used to define a service contract between a data supply module and a data consumption module; the service contract includes at least one of a data format, an operation parameter, and a business rule;

[0205] A second forming module, for forming a service contract between the data supply module and the data consumption module based on the time constraint parameter and the service contract;

[0206] The tenth determining module is used to determine the service contract of the vehicle system based on the service contract between the data supply module and the data consumption module.

[0207] The device and method embodiments in the embodiments of this application are based on the same application concept.

[0208] The method embodiments provided in the embodiments of the present application can be executed in a computer terminal, a server or a similar computing device. Taking running on a server as an example, Fig.12 1 is a hardware structure block diagram of a server of a system verification method provided in an embodiment of the present application. Fig.12 As shown, the server 600 may have relatively large differences due to different configurations or performances, and may include one or more central processing units (CPU) 610 (the processor 610 may include but is not limited to a processing device such as a microprocessor MCU or a programmable logic device FPGA), a memory 630 for storing data, and one or more storage media 620 (such as one or more mass storage devices) for storing application programs 623 or data 622. Among them, the memory 630 and the storage medium 620 can be short-term storage or permanent storage. The program stored in the storage medium 620 may include one or more modules, each of which may include a series of instruction operations on the server. Furthermore, the central processing unit 610 can be configured to communicate with the storage medium 620 and execute a series of instruction operations in the storage medium 620 on the server 600. The server 600 may also include one or more power supplies 660, one or more wired or wireless network interfaces 650, one or more input and output interfaces 640, and / or one or more operating systems 621, such as Windows Server™, Mac OS X™, Unix™, Linux™, FreeBSD™, etc.

[0209] The input / output interface 640 may be used to receive or send data via a network. The specific example of the network may include a wireless network provided by a communication provider of the server 600. In one example, the input / output interface 640 includes a network adapter (Network Interface Controller, NIC), which may be connected to other network devices via a base station so as to communicate with the Internet. In one example, the input / output interface 640 may be a radio frequency (RF) module, which is used to communicate with the Internet wirelessly.

[0210] It can be understood by those skilled in the art that Fig.12 The structure shown is for illustration only and does not limit the structure of the above electronic device. Fig.12 More or fewer components as shown, or with Fig.12 Different configurations shown.

[0211] An embodiment of the present application provides an electronic device, which includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, at least one program, a code set or an instruction set is loaded and executed by the processor to implement the above-mentioned system verification method.

[0212] An embodiment of the present application also provides a computer-readable storage medium, which can be set in a server to store at least one instruction, at least one program, a code set or an instruction set related to a system verification method in an implementation method embodiment. The at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the above-mentioned system verification method.

[0213] Optionally, in this embodiment, the storage medium may be located in at least one of the multiple network servers of the computer network. Optionally, in this embodiment, the storage medium may include, but is not limited to, various media that can store program codes, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0214] It can be seen from the embodiments of the system verification method, device, electronic device or storage medium provided by the present application that in the present application, the current configuration information and parameters to be verified of the vehicle system are obtained; the current configuration information is used to characterize the hardware configuration status and software configuration status of the vehicle system at the current moment; the service information corresponding to the current configuration information is determined; the service information is used to provide preset functions; based on the service information and the parameters to be verified, an automaton model is established; the automaton model is input into the formal verification model, and verification data is output; the verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified, and the corresponding automaton model is established according to the real-time configuration information and the parameters to be verified, and the formal model is input, and the verification data is output to implement formal verification, thereby ensuring that the vehicle can formally verify the system performance under any configuration, thereby improving the adaptability and reliability of the system; at the same time, the various functions of the vehicle system are encapsulated in the service to facilitate subsequent calls, speed up the verification speed of the system, and improve the verification efficiency of the system.

[0215] It should be noted that the above-mentioned sequence of the embodiments of the present application is for description only and does not represent the advantages and disadvantages of the embodiments. The above-mentioned specific embodiments of this specification are described. Other embodiments are within the scope of the attached claims. In some cases, the actions or steps recorded in the claims can be performed in an order different from that in the embodiments and still achieve the desired results. In addition, the processes depicted in the drawings do not necessarily require the specific order or continuous order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.

[0216] Each embodiment in this specification is described in a progressive manner, and the same or similar parts between the embodiments can be referred to each other, and each embodiment focuses on the differences from other embodiments. In particular, for the device embodiment, since it is basically similar to the method embodiment, the description is relatively simple, and the relevant parts can be referred to the partial description of the method embodiment.

[0217] A person skilled in the art will understand that all or part of the steps to implement the above embodiments may be accomplished by hardware or by instructing related hardware through a program, and the program may be stored in a computer-readable storage medium, and the above-mentioned storage medium may be a read-only memory, a disk or an optical disk, etc.

[0218] The above description is only a preferred embodiment of the present application and is not intended to limit the present application. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and principles of the present application should be included in the protection scope of the present application.

Claims

1. A system verification method, characterized in that: include: Obtain the current configuration information and parameters to be verified of the vehicle system; The current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment; Determine the service information corresponding to the current configuration information; The service information is used to provide preset functions; Establishing an automaton model based on the service information and the parameters to be verified; Inputting the automaton model into a formal verification model and outputting verification data; The verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified.

2. A system verification method according to claim 1, characterized in that: The determining the service information corresponding to the current configuration information includes: Acquire a basic service information set corresponding to the original configuration information; the original configuration information is used to characterize the hardware configuration state and software configuration state of the vehicle system at the initial moment; the basic service information set includes a plurality of the basic service information; Determining basic service information corresponding to the current configuration information from a plurality of basic service information; Determining new configuration information based on the current configuration information and the original configuration information; Determining new service information based on the new configuration information; Based on the newly added service information and basic service information corresponding to the current configuration information, the service information corresponding to the current configuration information is determined.

3. A system verification method according to claim 2, characterized in that: The determining, based on the newly added configuration information, the newly added service information includes: Determine a new activity flow based on the new configuration information; Based on the newly added activity process, the newly added service information is established.

4. A system verification method according to claim 3, characterized in that: The newly added activity flow includes a plurality of activity step information, sequence flow information between the plurality of activity step information, and data transfer information between the plurality of activity step information; The establishing of the newly added service information based on the newly added activity process includes: Determine a service module based on the plurality of activity step information and the sequence process information; the service module includes a main service module and a sub-service module; Based on the data transmission information, determining the interface connection relationship between the service modules; The newly added service information is determined based on the main service module, the sub-service module, and the interface connection relationship.

5. A system verification method according to claim 2, characterized in that: The step of establishing an automaton model based on the service information and the parameters to be verified includes: Based on the service information and the parameters to be verified, forming a service contract; Establishing an interface automaton model based on the interface connection relationship in the service information; Based on the service contract, a contract automaton model is established; The automaton model is determined based on the interface automaton model and the contract automaton model.

6. A system verification method according to claim 5, characterized in that: The forming of a service contract based on the service information and the parameter to be verified includes: For each group of the service modules having the interface connection relationship: The service module sending data is used as a data supply module, and the service module receiving data is used as a data consumption module; Defining a service contract between the data supply module and the data consumption module; the service contract includes at least one of a data format, an operation parameter, and a business rule; Based on the parameters to be verified and the service contract, forming a service contract between the data supply module and the data consumption module; Based on the service contract between the data provision module and the data consumption module, a service contract for the vehicle system is determined.

7. A system verification method according to claim 1, characterized in that: After inputting the automaton model into a formal verification model and outputting verification data, the method further includes: Get the preset verification threshold; If the verification data is less than or equal to the preset verification threshold, adjusting the parameter to be verified, updating the automaton model to obtain an updated automaton model, inputting the updated automaton model into the formal verification model, and outputting the verification data; or; If the verification data is greater than the preset verification threshold, it is determined that the automaton model meets the verification performance.

8. A system verification method according to claim 7, characterized in that: The verification data includes at least one of reliability data, reachability data, and security data.

9. A system verification device, characterized in that: The device comprises: An acquisition module, used to acquire current configuration information and parameters to be verified of the vehicle system; the current configuration information is used to represent the hardware configuration state and software configuration state of the vehicle system at the current moment; A determination module, used to determine service information corresponding to the current configuration information; the service information is used to provide a preset function; A modeling module, used for establishing an automaton model based on the service information and the parameters to be verified; The verification module is used to input the automaton model into a formal verification model and output verification data; the verification data is used to characterize the performance of the vehicle system under the current configuration information and the parameters to be verified.

10. An electronic device, characterized in that: The electronic device includes a processor and a memory, wherein the memory stores at least one instruction, at least one program, a code set or an instruction set, and the at least one instruction, the at least one program, the code set or the instruction set is loaded and executed by the processor to implement the system verification method as described in any one of claims 1-8.

11. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores at least one instruction or at least one program, and the at least one instruction or the at least one program is loaded and executed by a processor to implement the system verification method according to any one of claims 1 to 8.

Images