Formal modeling and verification method of automatic driving simulation model

Abstract

The invention discloses a formalized modeling and verification method of an automatic driving simulation model. The method comprises the steps of building an automatic driving simulation model, preprocessing simulation data, constructing a Mealy machine for describing the simulation model, performing formalized verification, and adopting counter-example optimization design. The method does not need to depend on internal codes of the system, the problem of dependence on white box system information can be solved, operability and engineering applicability of tools can be improved, and a reusable new normal form is provided for formal verification of safety of an automatic driving simulation scene.

Description

Technical Field

[0001] The present invention relates to autonomous driving simulation technology, and in particular to a formal modeling and verification technology for an autonomous driving simulation model based on an active automaton learning algorithm, and specifically to a formal modeling and verification method for an autonomous driving simulation model. Background Art

[0002] The rapid development of autonomous driving technology is reshaping the landscape of modern transportation systems. According to the definition of the Society of Automotive Engineers (SAE), L3 and above autonomous driving systems need to completely take over driving tasks in specific scenarios, which places extremely high demands on the safety and reliability of the system. However, in recent years, many autonomous driving accidents (such as the fatal collision of Uber's autonomous driving test car) have exposed the shortcomings of existing verification methods. Although traditional simulation-based verification methods (such as MATLAB Simulink) can cover some scenarios, their inherent sampling characteristics make it impossible to exhaust all possible combinations of environmental interactions. The National Transportation Safety Board (NTSB) report pointed out that the coverage rate of existing verification methods for corner cases is less than 30%, which has become a key bottleneck restricting the implementation of autonomous driving. Formal verification methods provide completeness proofs through mathematical rigor and are considered to be a breakthrough in solving the above problems. Model checking proposed by Clarke et al. can verify system properties by traversing all possible states, but its application premise is to obtain an accurate formal model. However, autonomous driving systems have high-dimensional continuous state spaces and complex environmental coupling characteristics. Traditional manual modeling methods face two major challenges: (1) low efficiency and error-proneness; (2) dynamic system updates (such as OTA upgrades) lead to a sharp increase in model maintenance and modification costs. Therefore, automated modeling and formal verification of autonomous driving simulation scenarios have become a common demand of industry and academia.

[0003] In recent years, automated modeling technology has become a key direction to break through the bottleneck of manual modeling: Bandera tools can extract finite state machines through static code analysis, but complete white-box system information is required; Buzhinsky et al. use reinforcement learning to derive models from simulation logs, but face the problem of high-dimensional state space explosion. Active automaton learning methods have emerged due to their black-box compatibility. The algorithm proposed by Angluin constructs a minimal deterministic finite automaton (DFA) through member query, but the model it generates only contains state transition logic and lacks explicit expression of input and output event semantics. To this end, Jonsson et al. extended it to an algorithm suitable for Mealy automata, which captures contextual semantics through input and output sequences, constructs a Mealy automaton model with rich contextual information, and achieves remarkable results in communication protocol reverse engineering applications. In recent years, such methods have begun to penetrate into the field of autonomous driving: Kunze et al. combined active learning with fuzzy testing to mine abnormal paths of vehicle control units, and Xia et al. tried to model MATLAB Simulink black-box systems based on algorithms, but their input event abstraction mechanism did not solve the problem of discretization of continuous parameters. Existing related research still has core defects: 1) Event abstraction relies on manual presets and cannot adaptively generate semantic mapping rules; 2) The model's expressive ability is limited to finite state transfers, and the lack of system semantics leads to the model's lack of ability to characterize timing constraints.

[0004] At the same time, the application of formal verification technology in the field of autonomous driving shows a diversified development trend, but there are still some problems: the decision logic verification based on linear temporal logic (LTL) relies on manually constructed state machine models, which is difficult to adapt to the evolution of complex dynamic scenarios; although the neural network abstract method can verify the local robustness of the perception module, it lacks the ability to cover system-level behavior. In terms of tool integration, the Simulink-UPPAAL framework developed by Ivanov et al. requires manual annotation of interface specifications, resulting in limited scalability. Studies have shown that the separation of data pipelines between simulation tools (such as Simulink) and verification tools (such as NuSMV) will cause 20%-40% semantic consistency errors. There are three major shortcomings in the existing verification process: 1) Verification attributes are limited to safety invariants and lack the expression of complex logic such as temporal reachability; 2) The scenario iteration efficiency of counterexample optimization is low; 3) The verification tool lacks an automated interface, and manual intervention reduces the verification efficiency.

[0005] Therefore, the input / output events are abstracted from the autonomous driving simulation scenario and The algorithm constructs the Mealy automaton model, then defines the formal properties covering key safety requirements and designs a scenario reproduction mechanism with counterexample optimization, while achieving seamless integration of the autonomous driving functional module with formal verification tools and ensuring the semantic consistency of the model. This is a complex and challenging task.

[0006] On languages ​​and Mealy automata and The related theories of algorithms and formal verification are:

[0007] 1. Language and Mealy Automata:

[0008] Discrete Event System (DES) is a type of dynamic system with a series of discrete states and discrete events. Its dynamic changes are reflected in the transition of the system state driven by events. The key elements of DES include state set, event set, and transition function. The state set of DES represents the various states that the system may be in, the event set includes all possible events that may occur in the system, and the transition function describes the process of triggering the transition of the system state due to receiving an event. Usually, the input event set of DES is represented as an alphabet ∑, which is a finite set of non-empty characters. The finite sequence of characters in the alphabet is called a string, and the empty string is denoted as ε. The length of a string t can be represented as |t|, and the length of the empty string is |ε|=0.

[0009] Collection∑ * is a Kleene closure defined on ∑, consisting of all strings of finite length and the empty string ε, the set ∑ + The set consisting of strings in ∑ whose length is greater than 0 is called a positive closure;

[0010] For string t = usv, string u∈∑ * and v∈Σ * are called prefix and suffix of t respectively. Suppose the strings s and t are Σ * If there are two elements in , the union of s and t is denoted by s·t, abbreviated as st;

[0011] Assume that a set of events for a given DES is an alphabet ∑, and the language L is a set of strings defined on ∑, that is, Given two languages Then the connection between two languages ​​can be defined as L1·L2={s∈∑ * |s=s1s2,s1∈L1,s2∈L2};

[0012] Assuming a language The prefix closure of If any prefix of any string is also an element of language L, then language L is called prefix closed, expressed as

[0013] Assuming a language The suffix closure of If any suffix of any string is also an element of language L, then language L is called suffix-closed;

[0014] Assume that a Mealy automaton M is defined as a six-tuple M = (Q, ∑, O, δ, λ, q0), where:

[0015] Q is a finite non-empty set of states, q0∈Q is the initial state, is a set of marked states, ∑ is a finite set of input events, O is a finite set of output events, δ: Q×∑→Q is a transition function, λ: Q×∑→O is an output function, where the transition function δ(q, σ)=q′, σ∈∑, means that the Mealy automaton will transfer to state q′ after receiving event i in state q. For a state q∈Q and an event σ∈∑, if there exists a state q′ such that δ(q, σ)=q′, then δ(q, σ) is defined, denoted by δ(q, σ)! At the same time, event σ is defined as a feasible event of state q. The set of all feasible events of state q is called the feasible event set Γ(q) of q, denoted by: Γ(q): Q→2 ∑ For convenience, the state transfer function δ is recursively extended from Q×∑ to Q×∑ in the following way: * : δ (q, ε) = q, δ (q, sσ) = δ (δ (q, s), σ), fors∈∑ * , σ∈∑, where the output function λ(q, σ) = o, for σ∈∑, o∈o, means that when the Mealy automaton is in state q, after receiving the input event σ, a state transition of δ(q, σ) occurs and an output event λ(q, σ) pops up at the same time; similarly, the output function λ is recursively extended from Q×∑ to Q×∑ in the following way * : λ(q,sσ)=λ(q,s)·λ(δ(q,s),σ), fors∈∑ * , σ∈∑, where the domains of the input function and the output function are the same, dom(δ)=dom(λ)=Q×I, and the suffix of the string ω with a length of k is denoted as suff * (ω), if ω=a·b···x·y·z, then suff 3 (ω) = x·y·z;

[0016] Assume that a Mealy automaton M = (Q, ∑, O, δ, λ, q0) is given, and its marked state set Then the generation language of M is: L(M) = {s∈Σ*:δ(q0,s}!}. The generation language L(M) represents all the strings that can be generated by the automaton starting from the initial state and going through a series of state transitions to reach the receiving state.

[0017] 2. algorithm:

[0018] The algorithm is an active automaton learning algorithm for learning Mealy automaton models. It can derive a Mealy automaton model from a given black box system. The derived automaton model can correctly identify the language L that is equivalent to the behavior of the black box system. M ,The algorithm first initializes the observation table, and then performs output queries on the learning object to fill the observation table.,After consistency and closure checks, the algorithm generates a hypothesis automaton model, and then performs equivalence queries.,If it is correct, the hypothesis will be returned, otherwise the algorithm will expand the observation table and re-perform the output query and build a new hypothesis automaton model;

[0019] use The algorithm needs to meet two conditions to learn a Mealy automaton: (1) the input event set of the learning object is known; (2) before each query in the learning process, the model can be reset to the initial state. The algorithm starts with ∑ + The string in the output query is obtained from the learning object, and the corresponding output string is taken + As the input string of the query, the algorithm will return the string λ(q0, ω) after querying it, and record the string returned by each query in the observation table. Before the observation table satisfies the closure and consistency, the query will be repeated; after satisfying the two properties, a hypothetical automaton model can be inferred through the observation table, and then the algorithm performs an equivalent query on the learning object and the hypothetical automaton. If the hypothetical automaton is correct, the algorithm ends and outputs the hypothetical automaton. If the equivalent query is incorrect and returns a counterexample, the algorithm will process the counterexample, expand and fill in the observation table, and continue to infer and improve the hypothetical automaton model.

[0020] Assumptions After learning the system, the algorithm obtains the Mealy automaton model with the smallest number of states, which is M = (Q, ∑, O, δ, λ, q0), and the input and output events of M are observable. At any time, All are preserved from ∑ + The input string and the + The collection of output strings is summarized and organized into an observation table Obs (Observation Table), using {S, E, TM} indicates that the observation table requires that S and E are non-empty finite sets of strings of finite length on ∑, where S is prefix closed and always contains the empty string ε; and E is suffix closed ( Except), define T M is a finite function: T M :(S∪S·∑)×E→O + , if s∈S∪S·∑ and e∈E, then T N (s, e) contains all the output strings from λ(q0, s·e). The rows in the observation table consist of elements of S∪S·∑, and the columns consist of elements of E. Initialize the observation table and set S = {ε}, E = {ε}. That is, each input string constitutes a column of the observation table, taking rows s∈S∪S·∑ and columns e∈E, whose return values ​​in the observation table are T M (s, e), the equivalence of different rows in the observation table is distinguished by the strings in E. Suppose s, t∈S∪S·∑ are two rows in the observation table, then for all e∈E, if and only if T M (s, e) = T M (t, e), s and t are said to be equivalent, expressed as Denote all row equivalence classes containing s as [s];

[0021] The algorithm will gradually build a hypothetical automaton model based on the observation table. The strings or prefixes in S are the potential states of the hypothetical automaton, while the strings or suffixes in E can distinguish the potential states.

[0022] If we want to construct a valid hypothetical Mealy automaton model from the observation table, then the observation table must satisfy two properties: First, the observation table must satisfy the closure property, that is, for each t∈S·∑, there exists an s∈S such that If the observation table does not satisfy the closure property, then a potential state observed in the table will be missing in the constructed hypothetical automaton model; secondly, the observation table must satisfy consistency, that is, for For all s, t∈S, given all σ∈∑, If the observation table does not satisfy consistency, then two seemingly equivalent states in the hypothetical automaton may go to different states after receiving the same input;

[0023] Assume that we take a closed and consistent observation table {S, E, T M}, define the hypothetical automaton model as M = (Q, ∑, o, δ, λ, q0), where: the state set Q M={[s]|s∈S}, initial state q0=[ε], transfer function is: The output function is: In order to ensure that M is fully defined, the following points must be noted: S is a non-empty set that is prefix-closed and contains at least one row ε, so that Q and q0 are fully defined in the hypothetical automaton for all such that For s, t∈S, there must be [s]=[t], because the observation table is consistent, so for all σ∈∑, [s·σ]=[t·σ] holds, because the observation table is closed, there must be u∈S such that [u]=[s·σ]=[t·σ] holds, so the transfer function δ is fully defined, because E is a suffix closed set on ∑ (except ε), then if there exists s, t∈S such that Then for all σ∈∑, T M (s, σ) = T M (t, σ) all hold, thus the output function λ is fully defined;

[0024] Below The algorithm is described in detail, where the symbols and descriptions used in Algorithm 5 are as follows:

[0025] ∑ is the input event set, O is the output event set, output_query is the output query, M is the Mealy machine M = (Q, ∑, O, δ, λ, q0), Q is the state set, δ is the state transition function δ: Q×∑→Q, λ is the output function λ: Q×∑→O, q0 is the initial state, Obs is the observation table, and S, E, T M Composition, S is a finite set of strings whose prefixes are closed on ∑, E is a finite set of strings whose suffixes are closed on ∑, T M is the output mapping table, which stores the output value corresponding to (s, e) in the observation table, ε is the empty string, [s] is the equivalence class of state s, · is the string concatenation operator, ⊥ is the invalid output marker, row(s) is the row vector corresponding to s in the observation table, prefixes(p) is the prefix set of path p, (∑×Q) * is the prefix set of path p, M(p) is the output of the hypothetical automaton M on path p, T(p) is the output of the target system on path p, is an equivalence relationship.

[0026] Algorithm 5: algorithm:

[0027] Input: input event set ∑, output event O, output query output_query: (S∪S·∑)×E→O + ;

[0028] Output: M = (Q, ∑, O, δ, λ, q0), including:

[0029]

[0030]

[0031] 3. Theoretical basis of formal verification:

[0032] 1) LTL is used to describe the timing properties of a system on a time linear path. Its syntax is based on atomic propositions and timing operators, including: Indicates that the system eventually satisfies the property Indicates that the system always satisfies the property Indicates that the system satisfies the property at the next moment Represents the properties of the system The property ψ holds true until it holds. Typical application scenarios of LTL include security and liveness. Common security requirements can be described as properties. It means that the system will never reach an error state during operation. The common liveness requirement can be described as the attribute Fsuccess, which means that the system will eventually achieve the goal at some point in the future.

[0033] 2) CTL describes the combination of path quantifiers and timing operators on the computation tree structure: Indicates that all paths in the system eventually satisfy the property Indicates that there is a path in the system that eventually satisfies the property Indicates that all paths in the system always satisfy the property Indicates that there is a path in the system that always satisfies the property CTL is suitable for expressing state reachability and global constraints. For example, the attribute AG (req→AF ack) indicates that on all possible execution paths of the system, the global requirement "if a request (req) occurs, then the request (ack) will eventually be confirmed" is satisfied. That is, no matter what state the system is in, as long as a request is issued, the system will eventually confirm the request. Summary of the invention

[0034] The purpose of the present invention is to provide a formal modeling and verification method for autonomous driving simulation models in view of the shortcomings of the prior art. This method does not need to rely on the internal code of the system, can solve the problem of dependence on white box system information, can improve the operability and engineering applicability of the tool, and provides a reusable new paradigm for the formal verification of the safety of autonomous driving simulation scenarios.

[0035] The technical solution for achieving the purpose of the present invention is:

[0036] A formal modeling and verification method for an autonomous driving simulation model includes the following steps:

[0037] 1. Construction of autonomous driving simulation model: The autonomous driving simulation model includes an environmental model and a vehicle model. The environmental model includes a basic road network and related facilities. The basic road network and related facilities include lane lines, traffic lights, basic signposts, etc. The traffic light facilities are required to operate normally according to the preset regulations. The vehicle model should meet the basic dynamics standards and be equipped with autonomous driving modules with different functions, namely, traffic light response function modules, vehicle collision detection modules, etc. At the same time, it is equipped with basic sensor hardware. When the vehicle model runs according to the preset trajectory in the simulation scene, it uses sensors to collect environmental data and adjust the vehicle action according to the autonomous driving function module;

[0038] 2. Simulation data preprocessing: Run the autonomous driving simulation model and record the environmental data and vehicle data during the process. The environmental data includes traffic light status data, relative distance data between vehicles, etc. The vehicle data includes speed data, throttle data, brake data, etc. The simulation data is preprocessed, including data discretization and state transfer construction:

[0039] II-1) Data discretization: Since the simulation generates continuous data, it is assumed that the collected speed data is a uniform growth process data from 0km / h to 30km / h within 0s-30s. The automaton model requires that the input and output are discrete symbol sequences. The continuous data is converted into discrete symbol representation by sampling and quantization. The actual sampling interval and quantization level are selected according to the modeling accuracy requirements:

[0040] Assume that the sampled time series data set is in:

[0041] x(t)=[x1(t),...,x m (t)] T represents m environmental data vectors. Assuming that one environmental variable is a traffic light status data vector, then m = 1; y(t) = [y1(t), ..., y n (t)] T Represents n vehicle data vectors. Assuming there are three vehicle data vectors, namely speed data vector, throttle data vector and brake data vector, then n=3, N is the number of sampling points, which is determined by the actual simulation scenario running time and sampling interval. The discretization rule consists of two mapping function vectors:

[0042] f: R m →F m, used for discretization of environmental data,

[0043] g:R n →G n , used for vehicle data discretization,

[0044] in:

[0045] f(x(t))=[f1(x1(t)),...,f m (x m (t))] T ,

[0046] g(y(t))=[g1(y1(t)),...,g n (y n (t))] T ,

[0047] R m represents the m-dimensional real number space, that is, the vector space composed of m real numbers; R n represents the n-dimensional real number space, that is, the vector space composed of n real numbers, which represents the value space of continuous data, F m represents the m-dimensional discrete symbol space, that is, the vector space composed of m discrete symbols; G n represents the n-dimensional discrete symbol space, that is, the vector space composed of n discrete symbols, which represent the discretized symbol space, f: R m →F m Indicates mapping m-dimensional continuous environmental data to m-dimensional discrete symbol space, g: R n →G n It means mapping the n-dimensional continuous vehicle data to the n-dimensional discrete symbol space. The data set D is processed based on the discretization rule, and the discretized data set is obtained as in:

[0048] σ(t)=f(x(t)), represents the discretized input event,

[0049] o(t)=g(y(t)), represents the discretized output event;

[0050] 2-2) State transition construction: The method of constructing the state transition set is shown in Algorithm 1. The symbols and descriptions used in Algorithm 1 are as follows:

[0051] D′ is the discretized data set, σ(t) is the input event of the environmental data at time t, o(t) is the output event representing the vehicle data at time t, T is the state transition set of the algorithm output, Q is the state set, ∑ is the input event set, O is the output event set, Map is the state mapping table, B is the behavior pattern set, T rawis the original transition set constructed for discretized data, c is the state counter, b is q is the behavior pattern of state q, b p is the behavior pattern of state p, s c is the identifier of the cth state, ≡ is the behavior pattern equivalence relation;

[0052] The algorithm 1 is a state transfer construction algorithm based on discretized data:

[0053] Input: discretized data set Where σ(t) represents the input event of the discretized environmental data, and o(t) represents the output event of the discretized vehicle data;

[0054] Output: state transition set Q is the state set, ∑ is the input event set, and O is the output event set, including:

[0055]

[0056]

[0057] Among them, step 1-1) is the initialization work, initializing the state mapping table Map to The behavior pattern set B is initialized as The transfer relation set T is initialized as Original transfer set T raw Initialize to At the same time, the state counter c is initialized to 0;

[0058] Steps 1-2) to 1-7) construct the original transition set, traverse the discretized data set D′ from t=1 to t=N-1, construct the current state with the output data o(t) at time t, construct the successor state with the output data o(t+1) at time t+1, and mark the input data σ(t+1) as the input event that triggers the transition, construct an original transition and add it to the original transition set, recorded as: T raw (current_state, input) ← next_state;

[0059] Steps 1-8) and 1-9) are performed on the original transfer set T raw Traverse each state in and construct their behavior patterns Behavior Pattern b q Contains all input events σ of state q and the next state T corresponding to σ raw (q, σ);

[0060] Step 1-10) first sets the behavior pattern judgment flag found_match to false, and then in step 1-11) sets the currently constructed behavior pattern b q Compare with all the behavior patterns in B. In step 1-12), if the behavior pattern b of the current state q is found q and the behavior pattern b of a state p in B p The same means that states p and q have the same output for the same input event σ, so in step 1-13), the current state q is mapped to state p, that is, the two can be represented by one state, and in step 1-14), the judgment flag found_match is set to true;

[0061] In steps 1-16) to 1-21), if no behavior pattern matching the current state q is found, a new state q is created. new , using the identifier s c Record and increase the state counter c by 1, and then map the current state q to the new state q in step 1-19) new That is, state s c , and in step 1-20) add the new behavior pattern and state to set B;

[0062] Step 1-23) to step 1-27) for the original transfer set T raw Traverse and construct the final transfer set T. For T raw For each state current_state and event σ in the current state, the actual transition constructed is: mapped Map[current_state,σ], the successor state q next For Map[T raw (current state ,σ)], the output event output is T raw (current state ,σ), and then transfer the entire mppsd ,σ,output,q next ) is added to the state transition set T;

[0063] Step 1-29) Return the constructed complete state transition set T;

[0064] 3. Yes The algorithm is modified and Algorithm 2 is used to construct the Mealy machine that describes the simulation model:

[0065] right The algorithm is adaptively modified, and the modified algorithm 2 is used to learn the state transition set T, and the Mealy machine describing the simulation model is constructed. The algorithm, Algorithm 2, is shown below. The symbols and descriptions used in Algorithm 2 are as follows:

[0066] ∑ is the input event set, O is the output event set, Q is the state set, and T is the state transition set M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), δ is the state transfer function δ: Q×∑→Q, λ is the output function λ: Q×∑→O, q0 is the initial state, Obs is the observation table, and S, E, T M Composition, S is a finite set of strings whose prefixes are closed on ∑, E is a finite set of strings whose suffixes are closed on ∑, T M is the output query, ε is the empty string, [s] is the equivalence class of state s, · is the string concatenation operator, ⊥ is the invalid output marker, row(s) is the row vector corresponding to s in the observation table, T p The state transition set obtained by running the simulation model built for counterexample p, prefixes(p) is the prefix set of path p;

[0067] The algorithm 2 is a modified Mealy machine learning algorithm:

[0068] Input: input event set Σ, output event set O, state transition set

[0069] Output: Mealy machine M = (Q, ∑, O, δ, λ, q0), including:

[0070]

[0071]

[0072] Among them, step 2-1) initializes the observation table, sets S and E are set to empty string sets {ε}, and outputs query T M Set to

[0073] Steps 2-2) to 2-13) are to construct and update the observation table. Step 2-2) enters the While loop to determine if the observation table does not meet the closure and consistency requirements, and then it is iteratively updated. Steps 2-3) and 2-4) traverse each prefix s in S∪S·∑ and each suffix e in E to construct a complete input sequence (q0, s, σ, e). Step 2-5) determines each input sequence (q0, s, σ, e). If the transfer sequence exists in the set T, then in step 2-6) the output o corresponding to the input sequence is obtained from T, and in step 2-7) the output query T is used.M (s, e) is recorded as o, and a judgment is made in step 2-9. If the transfer sequence does not exist in the set T, the query T is output in step 2-10). M (s, e) is recorded as ⊥, indicating that there is no valid output;

[0074] In step 2-14), the observation table is checked for closure. If there exists t∈S·∑, such that the row vector row(t) of t is different from all the row vectors row(s) in S, then in step 2-15), {t} is added to S; in step 2-17), the observation table is checked for consistency. If there exist s1, s2∈S and σ∈∑, such that row(s1) and row(s2) are equivalent, but they produce different outputs after receiving the same input σ, then in step 2-18), {σ·e} is added to E;

[0075] After step 2-20) jumps out of the While loop, it means that the observation table has satisfied the closure and consistency. Execute step 2-21) and construct a hypothetical automaton M = (Q, ∑, O, δ, λ, q0) according to the observation table Obs, where the state set Q is composed of the equivalence class [s] of the elements in S, the initial state q0 is the empty string ε, and the transition function δ(s, σ) is defined as [s·σ] to ensure that the output is the equivalence class of the state, and the output function λ(s, σ) = T M (s, σ) query T according to the output in the observation table M Return the corresponding output;

[0076] Steps 2-22) to 2-29) are to perform equivalence check on the hypothesized automaton M and process counterexamples; in step 2-22), traverse (∑×Q) * In step 2-23), check whether the output of the hypothetical automaton M on the path p is consistent with the transition set T. If the two are inconsistent, add all prefixes of p to S in step 2-24. Then, in step 2-25), construct a simulation model with input sequence p based on the counterexample p and run it. Use Algorithm 1 to process the data of the simulation run to obtain the state transition set T based on the counterexample p. p , step 2-26) T p Merge into T, and then in step 2-27) return to step 2-2) to continue iterating;

[0077] If there is no counterexample, it means that the behavior of the hypothesized automaton M is always consistent with that of the transfer set T, then in step 2-30), the Mealy machine M learned by the algorithm is returned;

[0078] 4. Formal Verification: Formal verification of the Mealy automaton model M obtained by modeling includes attribute specification definition, model conversion, model verification and counterexample optimization design, specifically:

[0079] IV-1) Attribute specification definition: Based on the Mealy automaton model M obtained by modeling, the verification attribute specification set Specs = Spec_LTL ∪ Spec_CTL ∪ Spec_custom is defined, where Spec_LTL is the LTL attribute specification, Spec_CTL is the CTL attribute specification, and Spec_custom is the custom attribute specification. The existing laws, regulations or relevant standards are abstracted according to the logical specifications of LTL and CTL to obtain the corresponding attribute specifications;

[0080] IV-2) Model conversion: Use the Nusmv tool to verify the constructed Mealy machine model, convert the model into a form that can be read by Nusmv, and use Algorithm 3 to convert the model. The symbols used in Algorithm 3 are defined as follows:

[0081] M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), Q is a state set, Σ is an input event set, O is an output event set, δ is a state transition function δ: Q×∑→Q, λ is an output function λ: Q×∑→O, q0 is the initial state, L is a state label mapping function, s i is the state label numbered i, CASE is the conditional statement keyword in Nusmv, VAR is the variable declaration keyword in Nusmv, and FAIRNESS is the fairness constraint keyword in Nusmv;

[0082] The algorithm 3 is a model conversion algorithm:

[0083] Input: Mealy automaton M = (Q∑, O, δ, λ, q0), state label mapping table L: Q → {s0, s1, ...};

[0084] Output: Nusmv file Mealy.smv, including:

[0085]

[0086]

[0087] Among them, step 3-1) generates state variable declarations, VAR state: {L(q)|q∈Q} indicates that the value range of the state variable state is all state labels in the state label mapping table L, and q is an element in the state set Q; VAR input: ∑ declares the input variable input, and the value range is the input event set ∑; VAR output: O declares the output variable output, and the value range is the output event set O; maps the initial state to q0;

[0088] Steps 3-2) to 3-12) construct state transition rules. Steps 3-3) and 3-4) traverse each input event σ of each state q in the state set Q. In step 3-5), the successor state q after state q receives input σ is calculated according to the transition function δ. next Then, in step 3-6), according to the output function λ, the output o after the state q receives the input σ is calculated. From step 3-7), a CASE statement is generated to describe the logic of state transition. Step 3-8) indicates that in the CASE statement, the condition part is state=L(q)&input=σ, that is, the current state variable state is equal to the state label L(q), and the input variable input is equal to the input event σ. Step 3-9) indicates that if the condition is met, the state variable state is updated to the label L(q) of the next state. next ), and at the same time in step 3-10) the output variable is updated to the calculated output o;

[0089] Execute step 3-13) define observation predicates for describing the state of the system, DEFINEis_stationary:=state in{L(q)|q∈Q_stationary} means that the meaning of defining the observation predicate is_stationary is that the vehicle is stationary, DEFINEis_throttling:=output=THROTTLE_ON means that the meaning of defining the observation predicate is_throttling is that the vehicle throttle is enabled;

[0090] In step 3-14) and step 3-15), fairness constraints are added to ensure that the input variable input is not equal to UNDEFINED, which means that the system must have a clear input signal when running to avoid undefined states; finally, in step 3-16), the generated Mealy.smv is output for verification;

[0091] IV-3) Model verification: The Mealy.smv file output by Algorithm 3 and the set attribute specifications are input into Nusmv for verification. If the verification passes, it means that the model meets the attribute specifications; if the verification fails, the counterexample driven optimization step is entered, and Algorithm 4 is used to verify Mealy.smv and the attribute specification set Specs. The symbols used in Algorithm 4 are defined as:

[0092] Mealy.smv is the Nusmv model file, Specs is the attribute specification set, spec is a single verification specification, Result is the verification result, read_model is the Nusmv model reading command, flatten_hierarchy is the Nusmv hierarchy flattening command, encode_variables is the Nusmv variable encoding command, and build_model is the Nusmv variable encoding command;

[0093] The algorithm 4 is the Mealy machine model verification algorithm:

[0094] Input: NuSMV model file Mealy.smv, attribute specification set Specs;

[0095] Output: Verification result, including:

[0096]

[0097] Step 4-1) Select the attribute spec to be verified in the attribute specification set Specs, and in step 4-2) add the spec to the Nusmv model file Mealy.smv to be verified;

[0098] Step 4-3) Generate a sequence of Nusmv verification commands in the following order: read_model command reads the model file, flatten_hierarchy command flattens the model hierarchy, encode_variables command encodes the variables in the model, build_model command builds a complete verification model, check_spec command performs specification verification, step 4-4) executes Nusmv command to verify the model and attribute specifications, and collects the verification output results;

[0099] From step 4-5) to step 4-7), if the output result of executing the Nusmv command is True, it means that the model meets the verified attribute specifications, and a PASSED result is returned. From step 4-8) to step 4-11), if the output result of executing the Nusmv command is False, it means that the model does not meet the verified attribute specifications, and a FAILED result is returned, and a counterexample counterexample is generated. The counterexample information includes the specific state sequence and variable values ​​that cause the attribute violation.

[0100] Step 4-12) will return the complete verification result Result, including: verification status (pass or fail), corresponding attribute specifications, and specific counterexample information in the case of failure;

[0101] 5. Use counterexamples to optimize the design: If, during the modeling process, it is assumed that the state transition sets of the automaton model and the simulation model have some behaviors that are not equivalent, that is, Algorithm 2, or the model fails to pass the verification, it means that the model does not meet the corresponding attribute specifications. There may be an error in the process of constructing the model, or there may be a problem in the design of the autonomous driving simulation module. Then the modified Mealy machine learning algorithm or verification tool will generate a counterexample v = σ1…σ k , at this time, the counter-example optimization design is adopted;

[0102] The core content of counterexample optimization design is to convert the counterexample v=σ1…σ provided by Algorithm 2 or model verification software into k Reconvert it into the input signal of the scenario, rerun the scenario and repeat the modeling and verification process.

[0103] The sequence of input events v = σ1…σ k Converted into an input signal available to MATLAB Simulink, the inverse discretization rule is defined as follows:

[0104] Assume the inverse discretization mapping function is:

[0105] f -1 ; F k →R k ×T,

[0106] Among them, F k represents the sequence space consisting of k discrete input events, R k represents the sequence space composed of k continuous control signal values, T represents the time parameter space, the signal duration is Δt,

[0107] Then for the counterexample v=σ1…σ k , the input signal sequence obtained after inverse discretization is:

[0108]

[0109] Where s(t) = f -1 (σ t ), represents the input signal value corresponding to the t-th input event, Δt∈T represents the duration of each signal, and f -1 ; Green→1, f -1 ; Red→0;

[0110] The counterexample optimization design process is as follows: First, the counterexample v is inversely discretized and converted into a simulation input signal sequence S v , execute S in the simulation v , repeat the process of formal modeling and verification, determine the source of the problem based on the verification results and make corresponding corrections. If the updated model passes the verification, it means that there are deviations in the original modeling process, and only the Mealy machine model needs to be updated. If the model verification still fails, it means that there are defects in the design of the simulation model and the model design needs to be modified.

[0111] This technical solution adopts a modeling framework of active automaton learning algorithm for autonomous driving simulation scenarios. Through semantically driven input and output event abstraction (such as mapping continuous speed to Moving / Stationary) and the active query mechanism of the algorithm, a Mealy machine model with rich contextual information is generated. This technical solution does not need to rely on the internal code of the system, which solves the problem of existing methods' dependence on white box system information. In terms of tool chain integration, this technical solution implements an end-to-end automated process, covering closed-loop management from autonomous driving simulation scenario construction and data collection (Simcenter Prescan & MATLAB Simulink) to formal verification of the model (NuSMV). It supports user-defined attribute verification and counterexample reproduction through a graphical interface, which significantly improves the tool's operability and engineering applicability.

[0112] This method does not need to rely on the system's internal code, can solve the problem of dependence on white-box system information, can improve the tool's operability and engineering applicability, and provides a reusable new paradigm for formal verification of the safety of autonomous driving simulation scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0113] Figure 1 Schematic diagram of the process of the embodiment method;

[0114] Figure 2 The basic scenario built in Simcenter Prescan for the implementation example;

[0115] Figure 3To build a basic scenario for the demonstration of the input sequence Green / NoLight·Red / Yellow·Green / NoLight·Red / Yellow in Simcenter Prescan in the implementation example;

[0116] Figure 4 In the embodiment, the modified The algorithm actively learns the scene and obtains the hypothesized automaton model M′, in which both input events and output events are expressed in the form of acronyms. DETAILED DESCRIPTION

[0117] The contents of the present invention are further described below in conjunction with the accompanying drawings and implementation examples, but the present invention is not limited thereto.

[0118] Example:

[0119] Reference Figure 1 , a formal modeling and verification method for an autonomous driving simulation model, comprising the following steps:

[0120] 1. Construction of autonomous driving simulation model: The autonomous driving simulation model includes an environmental model and a vehicle model. The environmental model includes the basic road network and related facilities, including lane lines, traffic lights, basic signposts, etc. The traffic light facilities are required to operate normally according to the preset regulations. The vehicle model should meet the basic dynamics standards and be equipped with autonomous driving modules with different functions, i.e., traffic light response function modules, vehicle collision detection modules, etc. At the same time, it is equipped with basic sensor hardware. When the vehicle model runs according to the preset trajectory in the simulation scene, it uses sensors to collect environmental data and adjust the vehicle action according to the autonomous driving function module.

[0121] In this example, if Figure 2 As shown in the figure, the road grid provided by Simcenter Prescan is used to construct a straight road, and several intersections are placed on the straight road. At each intersection, a traffic light model is placed according to the vehicle driving direction and in reference to the real scene. The cycle time of the traffic light is freely set through functions in the MATLAB Simulink model to construct input event sequences under different conditions. After the road grid is built in Simcenter Prescan, a vehicle model (fixed as Audi_A3) is selected and placed in the scene to run the simulation. A 2D dynamic model and a straight driving trajectory that conforms to the road network design are added to it. The maximum speed and initial speed of the vehicle are set to 10m / s. The rest are configured according to the default parameters of the vehicle in Simcenter Prescan.

[0122] 2. Simulation data preprocessing: Run the autonomous driving simulation model and record the environmental data and vehicle data during the process. The environmental data includes traffic light status data, relative distance data between vehicles, etc. The vehicle data includes speed data, throttle data, brake data, etc. The simulation data is preprocessed, including data discretization and state transfer construction;

[0123] In this example, the simulation model is run in MATLAB Simulink, and the traffic light signal data and vehicle motion data (including throttle, brake, and speed) are obtained through the simout module to obtain a time series data set.

[0124] II-1) Data discretization: The time series data set obtained by running the simulation is in:

[0125] Assume that the sampled time series data set is in:

[0126] x(t)=[x1(t),...,x m (t)] T Represents 1 environmental data vector - traffic light status

[0127] y(t)=[v(t),α(t),p(t)] T Represents three vehicle data vectors - speed status, throttle status, and brake status;

[0128] N is the number of sampling points;

[0129] The discretization rule consists of two mapping function vectors:

[0130] f: R m →F m , used for discretization of environmental data,

[0131] g:R n →G n , used for vehicle data discretization,

[0132] in:

[0133] f(x(t))=[f1(x1(t)),…,f m (x m (t))] T ,

[0134] g(y(t))=[g1(y1(t)),…,g n (y n (t))] T ,

[0135] R mrepresents the m-dimensional real number space, that is, the vector space composed of m real numbers; R n represents the n-dimensional real number space, that is, the vector space composed of n real numbers, which represents the value space of continuous data, F m represents the m-dimensional discrete symbol space, that is, the vector space composed of m discrete symbols; G n Represents an n-dimensional discrete symbol space, that is, a vector space composed of n discrete symbols. They represent the discretized symbol space. In this example, the following is set:

[0136] R m ={0,1}

[0137] F mm ={Red / Yellow, Green / Nolight}

[0138] R n = {v t ∈R,α t ∈{0,1},β t ∈{0, 1}}

[0139] G n ={(Moving, Stationary), (Throttle_0, Throttle-1), (Brake_0, Brake_1)}

[0140] The data set D is processed based on the discretization rule, and the discretized data set is obtained as follows:

[0141] 2-2) State transition construction: After obtaining the discretized data, it is necessary to construct the basic state transition based on the data. The method of constructing the state transition set is shown in Algorithm 1. The symbols and descriptions used in Algorithm 1 are as follows:

[0142] D′ is the discretized data set, σ(t) is the input event of the environmental data at time t, o(t) is the output event representing the vehicle data at time t, T is the state transition set of the algorithm output, Q is the state set, ∑ is the input event set, O is the output event set, Map is the state mapping table, B is the behavior pattern set, T raw is the original transition set constructed for discretized data, c is the state counter, b is q is the behavior pattern of state q, b p is the behavior pattern of state p, s c is the identifier of the cth state, ≡ is the behavior pattern equivalence relation;

[0143] The algorithm 1 is a state transfer construction algorithm based on discretized data:

[0144] Input: discretized data set Where σ(t) represents the input event of the discretized environmental data, and o(t) represents the output event of the discretized vehicle data;

[0145] Output: state transition set Q is the state set, ∑ is the input event set, and O is the output event set, including:

[0146]

[0147]

[0148]

[0149] Among them, step 1-1) is the initialization work, initializing the state mapping table Map to The behavior pattern set B is initialized as The transfer relation set T is initialized as Original transfer set T raw Initialize to At the same time, the state counter c is initialized to 0;

[0150] Steps 1-2) to 1-7) construct the original transition set, traverse the discretized data set D′ from t=1 to t=N-1, construct the current state with the output data o(t) at time t, construct the successor state with the output data o(t+1) at time t+1, and mark the input data σ(t+1) as the input event that triggers the transition, construct an original transition and add it to the original transition set, recorded as: T raw (current_state, input) ← next_state;

[0151] Steps 1-8) and 1-9) are performed on the original transfer set T raw Traverse each state in and construct their behavior patterns Behavior Pattern b q Contains all input events σ of state q and the next state T corresponding to σ raw (q, σ);

[0152] Step 1-10) first sets the behavior pattern judgment flag founnd_match to false, and then in step 1-11) sets the currently constructed behavior pattern b q Compare with all the behavior patterns in B. In step 1-12), if the behavior pattern b of the current state q is found q and the behavior pattern b of a state p in B pThe same means that states p and q have the same output for the same input event σ, so in step 1-13), the current state q is mapped to state p, that is, the two can be represented by one state, and in step 1-14), the judgment flag found_match is set to true;

[0153] In steps 1-16) to 1-21), if no behavior pattern matching the current state q is found, a new state q is created. new , using the identifier s c Record and increase the state counter c by 1, and then map the current state q to the new state q in step 1-19) new That is, state s c , and in step 1-20) add the new behavior pattern and state to set B;

[0154] Step 1-23) to step 1-27) for the original transfer set T raw Traverse and construct the final transfer set T. For T raw For each state current_state and event σ in the current state, the actual transition constructed is: mapped Map[current_state,σ], the successor state q next For Map[T raw (current state ,σ)], the output event output is T raw (current state ,σ), and then transfer the entire mappsd ,σ,output,q next ) is added to the state transition set T;

[0155] Step 1-29) Return the constructed complete state transition set T;

[0156] 3. Yes The algorithm is modified and Algorithm 2 is used to construct the Mealy machine that describes the simulation model:

[0157] right The algorithm is adaptively modified, and the modified algorithm 2 is used to learn the state transition set T, and the Mealy machine describing the simulation model is constructed. The algorithm, Algorithm 2, is shown below. The symbols and descriptions used in Algorithm 2 are as follows:

[0158] ∑ is the input event set, O is the output event set, Q is the state set, and T is the state transition set M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), δ is the state transfer function δ: Q×∑→Q, λ is the output function λ: Q×∑→O, q0 is the initial state, Obs is the observation table, and S, E, T M Composition, S is a finite set of strings whose prefixes are closed on ∑, E is a finite set of strings whose suffixes are closed on ∑, T M is the output query, ε is the empty string, [s] is the equivalence class of state s, · is the string concatenation operator, ⊥ is the invalid output marker, row(s) is the row vector corresponding to s in the observation table, T p The state transition set obtained by running the simulation model built for counterexample p, prefixes(p) is the prefix set of path p;

[0159] The algorithm 2 is a modified Mealy machine learning algorithm:

[0160] Input: input event set ∑, output event set O, state transition set

[0161] Output: Mealy machine M = (Q, ∑, O, δ, λ, q0), including:

[0162]

[0163]

[0164] Among them, step 2-1) initializes the observation table, sets S and E are set to empty string sets {ε}, and outputs query T M Set to

[0165] Steps 2-2) to 2-13) are to construct and update the observation table. Step 2-2) enters the While loop to determine if the observation table does not meet the closure and consistency requirements, and then it is iteratively updated. Steps 2-3) and 2-4) traverse each prefix s in S∪S·∑ and each suffix e in E to construct a complete input sequence (q0, s, σ, e). Step 2-5) determines each input sequence (q0, s, σ, e). If the transfer sequence exists in the set T, then in step 2-6) the output o corresponding to the input sequence is obtained from T, and in step 2-7) the output query T is used. M (s, e) is recorded as o, and a judgment is made in step 2-9. If the transfer sequence does not exist in the set T, the query T is output in step 2-10). M (s, e) is recorded as ⊥, indicating that there is no valid output;

[0166] In step 2-14), the observation table is checked for closure. If there exists t∈S·∑, such that the row vector row(t) of t is different from all the row vectors row(s) in S, then in step 2-15), {t} is added to S; in step 2-17), the observation table is checked for consistency. If there exist s1, s2∈S and σ∈∑, such that row(s1) and row(s2) are equivalent, but they produce different outputs after receiving the same input σ, then in step 2-18), {σ·e} is added to E;

[0167] After step 2-20) jumps out of the While loop, it means that the observation table has satisfied the closure and consistency. Execute step 2-21) and construct a hypothetical automaton M = (Q, ∑, O, δ, λ, q0) according to the observation table Obs, where the state set Q is composed of the equivalence class [s] of the elements in S, the initial state q0 is the empty string ε, and the transition function δ(s, σ) is defined as [s·σ] to ensure that the output is the equivalence class of the state, and the output function λ(s, σ) = T M (s, σ) query T according to the output in the observation table M Return the corresponding output;

[0168] Steps 2-22) to 2-29) are to perform equivalence check on the hypothesized automaton M and process counterexamples; in step 2-22), traverse (∑×Q) * In step 2-23), check whether the output of the hypothetical automaton M on the path p is consistent with the transition set T. If the two are inconsistent, add all prefixes of p to S in step 2-24. Then, in step 2-25), construct a simulation model with input sequence p based on the counterexample p and run it. Use Algorithm 1 to process the data of the simulation run to obtain the state transition set T based on the counterexample p. p , step 2-26) T p Merge into T, and then in step 2-27) return to step 2-2) to continue iterating;

[0169] If there is no counterexample, it means that the behavior of the hypothesized automaton M is always consistent with that of the transfer set T, then in step 2-30), the Mealy machine M learned by the algorithm is returned;

[0170] In this example, the modified Algorithm for state transition set To learn, the specific steps are as follows:

[0171] First, initialize the observation table OT1 according to the formal definition:

[0172] Observation Table OT1

[0173]

[0174] For the output content at ☆ in the observation table OT1, run the scenario with the input event Green, use the transfer construction algorithm (Algorithm 2) to process the obtained time series data set to obtain the state transfer set T1, and then use the modified After learning T1, the algorithm (Algorithm 3) obtains that when the input event of the scene is Green, the output is (Moving, Throttle_1, Brake_0), which is filled in the observation table.

[0175] Then, the input events of the scene are modified to Red / Yellow, Green / NoLight·Green / NoLight, Red / Yellow·Green / NoLight, Green / NoLight·Red / Yellow and Red / Yellow·Red / Yellow, and the corresponding outputs are obtained through algorithm learning and the observation table OT1 is filled in.

[0176] Note that, in the observation table OT1, m Both rows of σ are consistent with S m The rows are not equivalent, so add them all to S m In the output, construct a new observation table OT2 and perform an output query, abbreviating Moving as M, Stationary as S, Throttle as T, and Brake as B:

[0177] Observation Table OT2

[0178]

[0179] Use the same method to modify the scene input sequence to S m and S m · The sequence in σ is run, and after obtaining the data, the transfer is constructed and the observation table is filled in to obtain OT2. The S in the observation table OT2 m ·σ has two rows and S m All rows of are not equivalent, so add them all to S m In the output, construct a new observation table OT3 and perform an output query, abbreviating Moving as M, Stationary as S, Throttle as T, and Brake as B:

[0180] Observation Table OT3

[0181]

[0182] As can be seen from the above, the length of the input event sequence in OT3 has reached 4. Using the input sequence Green / NoLight·Red / Yellow·Green / NoLight·Red / Yellow for demonstration, we can construct the following in Simcenter Prescan: Figure 2 The scenario shown:

[0183] In the running scenario, the vehicle will receive traffic light signal inputs of Green / NoLight·Red / Yellow·Green / NoLight·Red / Yellow in a continuous manner, such as Figure 3 As shown, the simulation data is collected, and the output sequence is (Moving, Throttle_0, Brake_1) after algorithm processing and learning. Fill in the observation table OT3. Observe OT3 and find that it is closed and consistent. Construct Figure 4 The hypothetical automaton model M shown;

[0184] 4. Formal Verification: Formal verification of the Mealy automaton model M obtained by modeling includes attribute specification definition, model conversion, model verification and counterexample optimization design, specifically:

[0185] IV-1) Attribute specification definition: Based on the Mealy automaton model M obtained by modeling, the verification attribute specification set Specs = Spec_LTL ∪ Spec_CTL ∪ Spec_custom is defined, where Spec_LTL is the LTL attribute specification, Spec_CTL is the CTL attribute specification, and Spec_custom is the custom attribute specification. The existing laws, regulations or relevant standards are abstracted according to the logical specifications of LTL and CTL to obtain the corresponding attribute specifications;

[0186] In this example, Spec_LTL (LTL attribute specification):

[0187] 1. Red Light Response Specifications (Eventually Stop at Red)

[0188] (1) Source of specification setting:

[0189] ① Article 5.3.2 of the Chinese National Standard GB 5768-2017 "Road Traffic Signal Light Setting and Installation Specifications" clearly states: "When the red light is on, vehicles must not cross the stop line, and vehicles that have crossed the stop line should stop safely"

[0190] ② Industry practice | SAE J3016 Autonomous Driving Level 3 Definition | Regulation: "The system must ensure compliance with traffic signal responses within the ODD"

[0191] (2) Formal Definition

[0192] G(input_signal=RED→F(is_stationary|is_braking))

[0193] G: Globally, meaning it is valid at all times

[0194] Implies

[0195] F: Finally / Eventually, meaning it will be true at some point in the future

[0196] |: logical or (or)

[0197] (3) Safety significance: Whenever a red light is encountered, the vehicle will eventually either stop or apply the brakes, thus ensuring that the system vehicle will take appropriate safety measures at the red light.

[0198] 2. State transition smoothness specification (No Sudden Brake)

[0199] (1) Source of specification setting:

[0200] ① Vehicle dynamics | ISO 8855:2011 "Road vehicles - Vehicle dynamics and directional stability terminology" Article 4.2.3 | stipulates: "The braking process should ensure a smooth transition of deceleration"

[0201] ② Industry practice | SAE J2944 "Automatic Driving System Test Method" Article 6.2.4 | Requirement: "The state transition process should ensure that the acceleration is continuous and divisible"

[0202] (2) Formal Definition

[0203] G((is_moving&X is_stationary)→is_braking)

[0204] G:Globally

[0205] &: logical AND

[0206] X:Next

[0207] Implies

[0208] (3) Popular explanation: At any time, the vehicle cannot jump directly from the running state to the stationary state. The brake must be activated in the middle to ensure the smoothness of the state transition.

[0209] 3. Green light response specification (Progress)

[0210] (1) Source of specification setting:

[0211] ① Traffic efficiency | Article 4.2.1 of GB 14886-2016 "Road Traffic Signal Light Setting and Installation Specifications" stipulates: "During the green light period, vehicles should effectively use the right of way and avoid unnecessary detention"

[0212] ②Automated driving | ISO 22737-2021 "Performance requirements for low-speed automated driving systems" Article 6.3 | Requirement: "The system should ensure that the vehicle starts in a timely manner when obtaining the right of way"

[0213] (2) Formal Definition

[0214]

[0215] G:Globally

[0216] F:Finally / Eventually

[0217] Implies

[0218] GF: Indicates infinite occurrence

[0219] (3) Safety significance: If the vehicle in the system continues to receive green light signals, the vehicle will eventually reach the moving state.

[0220] (ii) Spec_CTL (CTL attribute specification):

[0221] 1. Safe States Reachable

[0222] (1) Source of specification setting:

[0223] ① Article 5.2.1 of China's national standard GB 21670-2008 "Technical requirements and test methods for brake systems of passenger cars" stipulates: "The brake system should ensure that the vehicle can stop safely within the specified distance at any initial speed."

[0224] ②Automated driving safety|ISO 21448 (SOTIF) Article 8.3.2|Specifies: "In the event of a perception system failure, the vehicle should be able to enter a state of minimal risk"

[0225] (2) Formal Definition

[0226] AG(EF is_stationary)

[0227] AG: Always Globally

[0228] EF: Exists Finally

[0229] is_stationary: is stationary

[0230] (3) Safety significance: There is a path for the system to reach a stationary state from any state, which means that the vehicle can safely stop by making several transitions under any circumstances.

[0231] 2. System non-blocking specification (Liveness)

[0232] (1) Source of specification setting:

[0233] ① Functional safety | ISO 26262-6:2018 Article 5.4.8 (System health monitoring) | states: "The system shall continuously monitor the operating status to ensure that at least one valid transfer path exists"

[0234] ②Automated driving | ISO 21448 (SOTIF) Article 9.2.1 | Requirement: "In unknown scenarios, the system should maintain minimum operability"

[0235] (2) Formal Definition

[0236] AG(EX TRUE)

[0237] Formal meaning:

[0238] AG: In all reachable states

[0239] EX: Exists Next

[0240] TRUE: True value

[0241] (3) Safety significance: The system has at least one successor state in any state, and deadlock will not occur and cause blocking

[0242] 3. Red Light Response

[0243] (1) Source of specification setting:

[0244] The source of the specification setting of the red light response attribute is the same as the red light response attribute in LTL attributes.

[0245] (2) Formal Definition

[0246]

[0247] AG: In all reachable states

[0248] Implied Relationship

[0249] AF: Always Finally

[0250] |: logical or (or)

[0251] (3) Safety significance: When encountering a red light, the vehicle will eventually come to a standstill or apply the brakes to ensure that it responds to the red light.

[0252] IV-2) Model conversion: Use the Nusmv tool to verify the constructed Mealy machine model, convert the model into a form that can be read by Nusmv, and use Algorithm 3 to convert the model. The symbols used in Algorithm 3 are defined as follows:

[0253] M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), Q is a state set, ∑ is an input event set, O is an output event set, δ is a state transition function δ: Q×∑→Q, λ is an output function λ: Q×∑→O, q0 is the initial state, L is a state label mapping function, s i is the state label numbered i, CASE is the conditional statement keyword in Nusmv, VAR is the variable declaration keyword in Nusmv, and FAIRNESS is the fairness constraint keyword in Nusmv.

[0254] The algorithm 3 is a model conversion algorithm:

[0255] Input: Mealy automaton M = (Q, ∑, O, δ, λ, q0), state label mapping table L:

[0256] Output: Nusmv file Mealy.smv, including:

[0257]

[0258] Among them, step 3-1) generates state variable declarations, VAR state: {L(q)|q∈Q} indicates that the value range of the state variable state is all state labels in the state label mapping table L, and q is an element in the state set Q; VAR input: ∑ declares the input variable input, and the value range is the input event set ∑; VAR output: O declares the output variable output, and the value range is the output event set O; maps the initial state to q0;

[0259] Steps 3-2) to 3-12) construct state transition rules. Steps 3-3) and 3-4) traverse each input event σ of each state q in the state set Q. In step 3-5), the successor state q after state q receives input σ is calculated according to the transition function δ. next Then, in step 3-6), according to the output function λ, the output o after the state q receives the input σ is calculated. From step 3-7), a CASE statement is generated to describe the logic of state transition. Step 3-8) indicates that in the CASE statement, the condition part is state=L(q)&input=σ, that is, the current state variable state is equal to the state label L(q), and the input variable input is equal to the input event σ. Step 3-9) indicates that if the condition is met, the state variable state is updated to the label L(q) of the next state. next ), and at the same time in step 3-10) the output variable is updated to the calculated output o;

[0260] Execute step 3-13) define observation predicates for describing the state of the system, DEFINEis_stationary:=state in{L(q)|q∈Q_stationary} means that the meaning of defining the observation predicate is_stationary is that the vehicle is stationary, DEFINEis_throttling:=output=THROTTLE_ON means that the meaning of defining the observation predicate is_throttling is that the vehicle throttle is enabled;

[0261] In step 3-14) and step 3-15), fairness constraints are added to ensure that the input variable input is not equal to UNDEFINED, which means that the system must have a clear input signal when running to avoid undefined states; finally, in step 3-16), the generated Mealy.smv is output for verification;

[0262] IV-3) Model verification: The Mealy.smv file output by Algorithm 3 and the set attribute specifications are input into Nusmv for verification. If the verification passes, it means that the model meets the attribute specifications; if the verification fails, the counterexample driven optimization step is entered, and Algorithm 4 is used to verify Mealy.smv and the attribute specification set Specs. The symbols used in Algorithm 4 are defined as:

[0263] Mealy.smv is the Nusmv model file, Specs is the attribute specification set, spec is a single verification specification, Result is the verification result, read_model is the Nusmv model reading command, flatten_hierarchy is the Nusmv hierarchy flattening command, encode_variables is the Nusmv variable encoding command, and build_model is the Nusmv variable encoding command;

[0264] The algorithm 4 is the Mealy machine model verification algorithm:

[0265] Input: NuSMV model file Mealy.smv, attribute specification set Specs;

[0266] Output: Verification result, including:

[0267]

[0268]

[0269] Step 4-1) Select the attribute spec to be verified in the attribute specification set Specs, and in step 4-2) add the spec to the Nusmv model file Mealy.smv to be verified;

[0270] Step 4-3) Generate a sequence of Nusmv verification commands in the following order: read_model command reads the model file, flatten_hierarchy command flattens the model hierarchy, encode_variables command encodes the variables in the model, build_model command builds a complete verification model, check_spec command performs specification verification, step 4-4) executes Nusmv command to verify the model and attribute specifications, and collects the verification output results;

[0271] From step 4-5) to step 4-7), if the output result of executing the Nusmv command is True, it means that the model meets the verified attribute specifications, and a PASSED result is returned. From step 4-8) to step 4-11), if the output result of executing the Nusmv command is False, it means that the model does not meet the verified attribute specifications, and a FAILED result is returned, and a counterexample counterexample is generated. The counterexample information includes the specific state sequence and variable values ​​that cause the attribute violation.

[0272] Step 4-12) will return the complete verification result Rexult, including: verification status, i.e., pass or fail, corresponding attribute specifications, and specific counterexample information in the case of failure;

[0273] In this example, the specific verification results are as follows:

[0274] 1.LTL attribute specification verification

[0275] (1) Red Light Response Specifications (Eventually Stop at Red)

[0276]

[0277] Verification successful;

[0278] (2) State transition smoothness specification (No Sudden Brake)

[0279]

[0280] Verification successful;

[0281] (3) Green light response specification (Progress)

[0282]

[0283] Verification successful;

[0284] 2. CTL attribute specification verification

[0285] (1) Safe States Reachable

[0286] AG(EF is_stationary)

[0287] Verification successful;

[0288] (2) System non-blocking specification (Liveness)

[0289] AG(EX TRUE)

[0290] Verification successful;

[0291] (3) Red Light Response

[0292] AG(input_signal=RED->AF(is_stationary|Brake=1))

[0293] Verification successful;

[0294] 3. User-defined attribute verification example

[0295] Considering that the automaton models learned in different scenarios need to be verified using different attribute logics, a user-defined attribute verification function is added to the program.

[0296] For example, after reading the model, if you want to verify the global reachability of states s0 and s1, you can add the logic specification SPEC EF (state = s0) & EF (state = s1) in the program to verify it. The verification is successful.

[0297] If there is a syntax error in the specification added by the user, the program will report an error message. If the user wants to delete the redundant custom validation specification, right-click and select the specification to delete;

[0298] VI. V. Using counterexamples to optimize design: If, during the modeling process, it is assumed that the state transition sets of the automaton model and the simulation model have some behaviors that are not equivalent, that is, Algorithm 2, or the model fails to pass the verification, it means that the model does not meet the corresponding attribute specifications. There may be an error in the process of constructing the model, or there may be a problem in the design of the autonomous driving simulation module. Then the modified Mealy machine learning algorithm or verification tool will generate a counterexample v = σ1…σ k , at this time, the counter-example optimization design is adopted;

[0299] The core content of counterexample optimization design is to convert the counterexample v=σ1…σ provided by Algorithm 2 or model verification software into k Reconvert it into the input signal of the scenario, rerun the scenario and repeat the modeling and verification process.

[0300] The sequence of input events v = σ1…σ k Converted into an input signal available to MATLAB Simulink, the inverse discretization rule is defined as follows:

[0301] Assume the inverse discretization mapping function is:

[0302] f -1 ; F k →R k ×T,

[0303] Among them, F k represents the sequence space consisting of k discrete input events, R k represents the sequence space composed of k continuous control signal values, T represents the time parameter space, the signal duration is Δt,

[0304] Then for the counterexample v=σ1…σ k , the input signal sequence obtained after inverse discretization is:

[0305]

[0306] Where s(t) = f -1 (σ t), represents the input signal value corresponding to the t-th input event, Δt∈T represents the duration of each signal, and f -1 ;Greern→1,f -1 ; Red→0;

[0307] The counterexample optimization design process is as follows: First, the counterexample v is inversely discretized and converted into a simulation input signal sequence S v , execute S in the simulation v , repeat the process of formal modeling and verification, determine the source of the problem based on the verification results and make corresponding corrections. If the updated model passes the verification, it means that there are deviations in the original modeling process, and only the Mealy machine model needs to be updated. If the model verification still fails, it means that there are defects in the design of the simulation model and the model design needs to be modified.

[0308] Since the attribute specification verification of the Mealy machine model did not fail in this example, there was no counterexample, so there was no need to perform counterexample optimization design operations, which verified the safety of the constructed autonomous driving simulation scenario.

[0309] In terms of practical application, this technical solution uses Simcenter Prescan & MATLAB Simulink simulation case studies to verify the effectiveness of this method in typical traffic scenarios (traffic signal response). By defining multiple temporal logic properties (such as red light stop mutual exclusivity and state reachability) and combining the mechanism of counterexample optimization design, it provides a reusable new paradigm for formal verification of the safety of autonomous driving simulation scenarios.

Claims

1. A formal modeling and verification method for an autonomous driving simulation model, characterized in that: The steps include:

1. Construction of autonomous driving simulation model: The autonomous driving simulation model includes an environmental model and a vehicle model. The environmental model includes a basic road network and related facilities. The basic road network and related facilities include lane lines, traffic lights, and basic signposts. The traffic light facilities are required to operate normally according to the preset regulations. The vehicle model meets the basic dynamics standards and is equipped with autonomous driving modules with different functions, namely, traffic light response function modules and vehicle collision detection modules. At the same time, it is equipped with basic sensor hardware. When the vehicle model runs according to the preset trajectory in the simulation scene, it uses sensors to collect environmental data and adjusts the vehicle action according to the autonomous driving function module.

2. Simulation data preprocessing: Run the autonomous driving simulation model and record the environmental data and vehicle data during the process. The environmental data includes traffic light status data and relative distance data between vehicles. The vehicle data includes speed data, throttle data, brake data, etc. The simulation data is preprocessed including data discretization and state transfer construction: II-1) Data discretization: Running the simulation generates continuous data. Assume that the collected speed data is a uniform growth process data from 0km / h to 30km / h within 0s-30s. The automaton model requires that the input and output are discrete symbol sequences. The continuous data is converted into discrete symbol representation by sampling and quantization. The actual sampling interval and quantization level are selected according to the modeling accuracy requirements: Assume that the sampled time series data set is in: x(t)=[x1(t),...,x m (t)] T represents m environmental data vectors. Assuming that one environmental variable is a traffic light status data vector, then m = 1; y(t) = [y1(t), …, y n (t)] T Represents n vehicle data vectors. Assuming there are three vehicle data vectors, namely speed data vector, throttle data vector and brake data vector, then n=3, N is the number of sampling points, which is determined by the actual simulation scenario running time and sampling interval. The discretization rule consists of two mapping function vectors: f: R m →F m , used for discretization of environmental data, g:R n →G n , used for vehicle data discretization, in: f(x(t))=[f1(x1(t)),...,f m (x m (t))] T , g(y(t))=[g1(y1(t)),...,g n (y n (t))] T , R m represents the m-dimensional real number space, that is, the vector space composed of m real numbers; R n represents the n-dimensional real number space, that is, the vector space composed of n real numbers, which represents the value space of continuous data, F m represents the m-dimensional discrete symbol space, that is, the vector space composed of m discrete symbols; G n represents the n-dimensional discrete symbol space, that is, the vector space composed of n discrete symbols, which represent the discretized symbol space, f: R m →F m Indicates mapping m-dimensional continuous environmental data to m-dimensional discrete symbol space, g: R n →G n It means mapping the n-dimensional continuous vehicle data to the n-dimensional discrete symbol space. The data set D is processed based on the discretization rule, and the discretized data set is obtained as in: σ(t)=f(x(t)), represents the discretized input event, o(t)=g(y(t)), represents the discretized output event; 2-2) State transition construction: The method of constructing the state transition set is shown in Algorithm 1. The symbols and descriptions used in Algorithm 1 are as follows: D′ is the discretized data set, σ(t) is the input event of the environmental data at time t, o(t) is the output event representing the vehicle data at time t, T is the state transition set of the algorithm output, Q is the state set, ∑ is the input event set, O is the output event set, Map is the state mapping table, B is the behavior pattern set, T raw is the original transition set constructed for discretized data, c is the state counter, b is q is the behavior pattern of state q, b p is the behavior pattern of state p, s c is the identifier of the cth state, ≡ is the behavior pattern equivalence relation; The algorithm 1 is a state transfer construction algorithm based on discretized data: Among them, step 1-1) is the initialization work, initializing the state mapping table Map to The behavior pattern set B is initialized as The transfer relation set T is initialized as The original transfer set T raw Initialize to At the same time, the state counter c is initialized to 0; Steps 1-2) to 1-7) construct the original transition set, traverse the discretized data set D′ from t=1 to t=N-1, construct the current state with the output data o(t) at time t, construct the successor state with the output data o(t+1) at time t+1, and mark the input data σ(t+1) as the input event that triggers the transition, construct an original transition and add it to the original transition set, recorded as: T raw (current_state, input) ← next_state; Steps 1-8) and 1-9) are performed on the original transfer set T raw Traverse each state in and construct their behavior patterns The behavior pattern bq contains all input events σ of state q and the next state T corresponding to σ. raw (q, σ); Step 1-10) first sets the behavior pattern judgment flag found_match to false, and then in step 1-11) sets the currently constructed behavior pattern b q Compare with all the behavior patterns in B. In step 1-12), if the behavior pattern b of the current state q is found q and the behavior pattern b of a state p in B p The same means that states p and q have the same output for the same input event σ, so in step 1-13), the current state q is mapped to state p, that is, the two can be represented by one state, and in step 1-14), the judgment flag found_match is set to true; In step 1-16) to step 1-21), if no behavior pattern matching the current state q is found, a new state q is created. new , using the identifier s c Record and increase the state counter c by 1, and then map the current state q to the new state q in step 1-19) new That is, state s c , and in step 1-20) add the new behavior pattern and state to set B; Step 1-23) to step 1-27) for the original transfer set T raw Traverse and construct the final transfer set T. For T raw For each state current_state and event σ in the current state, the actual transition constructed is: mapped Map[current_state,σ], the successor state q next For Map[T raw (current state， σ)], the output event output is T raw (current state ,σ), and then transfer the entire mapped ,σ,output,q next ) is added to the state transition set T; Step 1-29) Return the constructed complete state transition set T; 3. Yes The algorithm is modified and Algorithm 2 is used to construct the Mealy machine that describes the simulation model: right The algorithm is adaptively modified, and the modified algorithm 2 is used to learn the state transition set T, and the Mealy machine describing the simulation model is constructed. The algorithm, Algorithm 2, is shown below. The symbols and descriptions used in Algorithm 2 are as follows: ∑ is the input event set, O is the output event set, Q is the state set, and T is the state transition set M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), δ is the state transfer function δ: Q×∑→Q, λ is the output function λ: Q×∑→O, q0 is the initial state, Obs is the observation table, and S, E, T M Composition, S is a finite set of strings whose prefixes are closed on ∑, E is a finite set of strings whose suffixes are closed on ∑, T M is the output query, ε is the empty string, [s] is the equivalence class of state s, · is the string concatenation operator, ⊥ is the invalid output marker, row(s) is the row vector corresponding to s in the observation table, T p The state transition set obtained by running the simulation model built for counterexample p, prefixes(p) is the prefix set of path p; The algorithm 2 is a modified Mealy machine learning algorithm: Among them, step 2-1) initializes the observation table, sets S and E are set to the empty string set {ε}, and outputs the query T M Set to Step 2-2) to step 2-13) are to construct and update the observation table. Step 2-2) enters the While loop to determine if the observation table does not meet the closure and consistency requirements, and then it is iteratively updated. Steps 2-3) and 2-4) traverse each prefix s in S∪S·∑ and each suffix e in E to construct a complete input sequence (q0, s, σ, e). Step 2-5) judges each input sequence (q0, s, σ, e). If the transfer sequence exists in the set T, then in step 2-6) the output o corresponding to the input sequence is obtained from T, and in step 2-7) the output query TM(s, e) is recorded as o. In step 2-9), if the transfer sequence does not exist in the set T, then in step 2-10) the output query T is recorded as o. M (s, e) is recorded as ⊥, indicating that there is no valid output; In step 2-14), the observation table is checked for closure. If there exists t∈S·∑, such that the row vector row(t) of t is different from all the row vectors row(s) in S, then in step 2-15), {t} is added to S; in step 2-17), the observation table is checked for consistency. If there exist s1, s2∈S and σ∈∑, such that row(s1) and row(s2) are equivalent, but they produce different outputs after receiving the same input σ, then in step 2-18), {σ·e} is added to E; After step 2-20) jumps out of the While loop, it means that the observation table has satisfied the closure and consistency. Execute step 2-21) and construct a hypothetical automaton M = (Q, ∑, O, δ, λ, q0) according to the observation table Obs, where the state set Q is composed of the equivalence class [s] of the elements in S, the initial state q0 is the empty string ε, and the transition function δ(s, σ) is defined as [s·σ] to ensure that the output is the equivalence class of the state, and the output function λ(s, σ) = T M (s, σ) query T according to the output in the observation table M Return the corresponding output; Steps 2-22) to 2-29) are to perform equivalence check on the hypothesized automaton M and process counterexamples; in step 2-22), traverse (∑×Q) * In step 2-23), check whether the output of the hypothetical automaton M on the path p is consistent with the transition set T. If the two are inconsistent, add all prefixes of p to S in step 2-24. Then, in step 2-25), construct a simulation model with input sequence p based on the counterexample p and run it. Use Algorithm 1 to process the data of the simulation run to obtain the state transition set T based on the counterexample p. p , step 2-26) T p Merge into T, and then in step 2-27) return to step 2-2) to continue iterating; If there is no counterexample, it means that the behavior of the hypothesized automaton M is always consistent with that of the transfer set T, then in step 2-30), the Mealy machine M learned by the algorithm is returned; 4. Formal Verification: Formal verification of the Mealy automaton model M obtained by modeling includes attribute specification definition, model conversion, model verification and counterexample optimization design, specifically: IV-1) Attribute specification definition: Based on the Mealy automaton model M obtained by modeling, the verification attribute specification set Specs = Spec_LTL ∪ Spec_CTL ∪ Spec_custom is defined, where Spec_LTL is the LTL attribute specification, Spec_CTL is the CTL attribute specification, and Spec_custom is the custom attribute specification. The existing laws, regulations or relevant standards are abstracted according to the logical specifications of LTL and CTL to obtain the corresponding attribute specifications; IV-2) Model conversion: Use the Nusmv tool to verify the constructed Mealy machine model, convert the model into a form that can be read by Nusmv, and use Algorithm 3 to convert the model. The symbols used in Algorithm 3 are defined as follows: M is a Mealy machine M = (Q, ∑, O, δ, λ, q0), Q is a state set, ∑ is an input event set, O is an output event set, δ is a state transition function δ: Q×∑→Q, λ is an output function λ: Q×∑→O, q0 is the initial state, L is a state label mapping function, s i is the state label numbered i, CASE is the conditional statement keyword in Nusmv, VAR is the variable declaration keyword in Nusmv, and FAIRNESS is the fairness constraint keyword in Nusmv; The algorithm 3 is a model conversion algorithm: Among them, step 3-1) generates state variable declarations, VAR state: {L(q)|q∈Q} indicates that the value range of the state variable state is all state labels in the state label mapping table L, and q is an element in the state set Q; VAR input: ∑ declares the input variable input, and the value range is the input event set ∑; VAR output: O declares the output variable output, and the value range is the output event set O; maps the initial state to q0; Steps 3-2) to 3-12) construct state transition rules. Steps 3-3) and 3-4) traverse each input event σ of each state q in the state set Q. In step 3-5), the successor state q after state q receives input σ is calculated according to the transition function δ. next Then, in step 3-6), according to the output function λ, the output o after the state q receives the input σ is calculated. From step 3-7), a CASE statement is generated to describe the logic of state transition. Step 3-8) indicates that in the CASE statement, the condition part is state=L(q)&input=σ, that is, the current state variable state is equal to the state label L(q), and the input variable input is equal to the input event σ. Step 3-9) indicates that if the condition is met, the state variable state is updated to the label L(q) of the next state. next ), and at the same time in step 3-10) the output variable is updated to the calculated output o; Execute step 3-13) define observation predicates for describing the state of the system, DEFINE is_stationary:=statein{L(q)|q∈Q_stationary} means that the meaning of defining the observation predicate is_stationary is that the vehicle is stationary, DEFINE is_thrattling:=output=THROTTLE_ON means that the meaning of defining the observation predicate is_throttling is that the vehicle throttle is enabled; In step 3-14) and step 3-15), fairness constraints are added to ensure that the input variable input is not equal to UNDEFINED, which means that the system must have a clear input signal when running to avoid undefined states; finally, in step 3-16), the generated Mealy.smv is output for verification; IV-3) Model verification: The Mealy.smv file output by Algorithm 3 and the set attribute specifications are input into Nusmv for verification. If the verification passes, it means that the model meets the attribute specifications; if the verification fails, the counterexample driven optimization step is entered, and Algorithm 4 is used to verify Mealy.smv and the attribute specification set Specs. The symbols used in Algorithm 4 are defined as: Mealy.smv is the Nusmv model file, Specs is a set of attribute specifications, spec is a single verification specification, Result is the verification result, read_model is the Nusmv model reading command, flatten_hierarchy is the Nusmv hierarchy flattening command, encode_variables is the Nusmv variable encoding command, and build_model is the Nusmv variable encoding command. The algorithm 4 is the Mealy machine model verification algorithm: Step 4-1) Select the attribute spec to be verified in the attribute specification set Specs, and in step 4-2) add the spec to the Nusmv model file Mealy.smv to be verified; Step 4-3) Generate a sequence of Nusmv verification commands in the following order: read_model command reads the model file, flatten_hierarchy command flattens the model hierarchy, encode_variables command encodes the variables in the model, build_model command builds a complete verification model, check_spec command performs specification verification, step 4-4) executes Nusmv command to verify the model and attribute specifications, and collects the verification output results; From step 4-5) to step 4-7), if the output result of executing the Nusmv command is True, it means that the model meets the verified attribute specifications, and a PASSED result is returned. From step 4-8) to step 4-11), if the output result of executing the Nusmv command is False, it means that the model does not meet the verified attribute specifications, and a FAILED result is returned, and a counterexample counterexample is generated. The counterexample information includes the specific state sequence and variable values ​​that cause the attribute violation. Step 4-12) will return the complete verification result Result, including: verification status (pass or fail), corresponding attribute specifications, and specific counterexample information in the case of failure; 5. Use counterexamples to optimize the design: If the state transition sets of the automaton model and the simulation model are assumed to have some behaviors that are not equivalent in the modeling process, that is, Algorithm 2, or the model fails to pass the verification, it means that the model does not meet the corresponding attribute specifications. There may be an error in the process of constructing the model, or there may be a problem in the design of the autonomous driving simulation module. The modified Mealy machine learning algorithm or verification tool generates a counterexample v = c1…σ k , at this time, the counter-example optimization design is adopted; Counterexample optimization design is to convert the counterexample v=σ1…σ provided by Algorithm 2 or model verification software into k Reconvert to the input signal of the scenario, rerun the scenario and repeat the modeling and verification process: The sequence of input events v = σ1…σ k Converted into an input signal available to MATLAB Simulink, the inverse discretization rule is defined as follows: Assume the inverse discretization mapping function is: f -1 ;F k →R k ×T, Among them, F k represents the sequence space consisting of k discrete input events, R k represents the sequence space composed of k continuous control signal values, T represents the time parameter space, the signal duration is Δt, For the counterexample v=σ1…σ k , the input signal sequence obtained after inverse discretization is: Where s(t) = f -1 (σ t ), represents the input signal value corresponding to the t-th input event, Δt∈T represents the duration of each signal, and f -1 ; Green→1, f -1 ; Red→0; The counterexample optimization design process is as follows: First, the counterexample v is inversely discretized and converted into a simulation input signal sequence S v , execute S in the simulation v , repeat the process of formal modeling and verification, determine the source of the problem based on the verification results and make corresponding corrections. If the updated model passes the verification, it means that there are deviations in the original modeling process, and only the Mealy machine model needs to be updated. If the model verification still fails, it means that there are defects in the design of the simulation model and the model design needs to be modified.

Images