Data processing method based on traffic rules, electronic equipment and product

Abstract

The embodiment of the invention relates to the field of intelligent traffic, and discloses a traffic rule-based data processing method, electronic equipment and a product, and the data processing method comprises the steps: constructing a monitoring specification of an asynchronous event stream, and carrying out the formalized description of the monitoring specification through employing an extended Bass normal form; the monitoring specification comprises at least one input event stream, at least one output derived stream and at least one trigger; performing static analysis on the monitoring specification to obtain a low-order intermediate representation, the static analysis being used for verifying the monitoring specification; and performing simulation verification on the original data based on the low-order intermediate representation, and outputting an alarm according to a verification result, thereby performing formalized description on various key safety events in an intelligent driving scene through a unified input event stream / output derived stream / trigger model, and further performing formalized description on the key safety events in the intelligent driving scene. A high-readability and high-verifiability specification meeting a complex traffic scene expression requirement is constructed in a short time, and the monitoring efficiency and the automation degree of an intelligent traffic system are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of intelligent transportation, and in particular to a data processing method based on traffic rules, an electronic device and a product. BACKGROUND

[0002] The deep integration of artificial intelligence technology and the Internet of Vehicles promotes the rapid evolution of intelligent driving systems from closed test fields to open roads. The number of intelligent driving vehicles is growing exponentially, reshaping the global transportation landscape. However, current intelligent driving systems still have traffic rule violation behaviors such as running red lights, changing lanes without respecting lines, and not giving way to pedestrians, triggered by decision-making vulnerabilities, extreme working conditions (such as road construction, animal intrusion, etc.), and other issues during testing and actual operation. Such violations not only reduce the safety and social trust of the system, but also pose challenges to its large-scale commercialization in terms of regulatory compliance.

[0003] The current intelligent driving system presents a fragmented feature in terms of traffic rule compliance verification technology, and has not yet formed a complete technical system covering formal modeling, dynamic verification and resource optimization. The mainstream scene simulation test can only verify a limited number of preset scenes and rule libraries, and cannot cope with dynamic changes in complex traffic environments, especially lacking effective means in dealing with the problem of explosive combination of asynchronous event streams. Although the formal verification method provides theoretical completeness, the existing temporal logic language (such as STL) is difficult to represent the dynamic characteristics of multi-agent interaction, resulting in verification results that cannot fully cover actual driving scenarios. In addition, the existing test framework lacks fine-grained monitoring of the decision-making process on the vehicle side, and cannot analyze sensor data in real time, map formal specifications and generate verification evidence chains, failing to achieve dynamic supervision of traffic rule compliance. The traditional verification computation complexity grows exponentially, making it difficult to meet the real-time needs of real-time operation, and failing to support the compliance verification of the entire life cycle of the intelligent driving system.

[0004] Therefore, it is urgent to build a new formal language and efficient verification framework for asynchronous event streams, break through the existing verification bottleneck, achieve comprehensive and systematic test coverage, and ensure the compliance and safety of intelligent driving systems in complex environments. SUMMARY

[0005] An object of the present application is to provide a data processing method based on traffic rules, an electronic device and a product, at least to solve the problem that it is difficult to identify traffic rule violation behaviors in real time during testing and operation in the prior art.

[0006] To achieve the above-mentioned object, some embodiments of the present application provide the following aspects:

[0007] In a first aspect, the present application provides a data processing method based on traffic rules, the data processing method comprising:

[0008] constructing a monitoring specification of an asynchronous event stream, the monitoring specification being formally described using an extended Backus-Naur form;

[0009] the monitoring specification comprising at least one input event stream, at least one output derived stream and at least one trigger;

[0010] the input event stream being used to carry raw data of a vehicle and a road environment;

[0011] the output derived stream being obtained by computation on the input event stream, the output derived stream being used to describe a state of the vehicle in the road environment according to the raw data;

[0012] the trigger being used to output a violation alarm when a traffic rule violation is triggered according to the output derived stream;

[0013] performing static analysis on the monitoring specification to obtain a low-level intermediate representation, the static analysis being used to check the monitoring specification;

[0014] performing simulation verification on the raw data based on the low-level intermediate representation, and outputting an alarm according to a verification result.

[0015] In a second aspect, the present application further provides an electronic device, the electronic device comprising:

[0016] one or more processors; and

[0017] a memory storing computer program instructions which, when executed, cause the processor to perform the steps of any of the above methods.

[0018] In a third aspect, the present application further provides a computer program product comprising computer programs / instructions which, when executed by a processor, implement the steps of any of the above methods.

[0019] Compared with the related art, the scheme provided in the embodiments of the present application takes an asynchronous event stream specification language as the core, and through a unified input event stream / output derived stream / trigger model, formally describes key safety events such as speed overrun, lane deviation, too close following distance and signal light violation in an intelligent driving scenario, can construct a high readability and high verifiability specification meeting the expression needs of a complex traffic scenario in a short time, improves the monitoring efficiency and automation degree of an intelligent transportation system, and reduces the rule modeling and maintenance cost. BRIEF DESCRIPTION OF DRAWINGS

[0020] One or more embodiments are illustrated by way of example in the figures that are part of this disclosure and which are not intended to limit the scope of the embodiments, the same reference notations in different drawings represent the same or similar elements, and the drawings are not to scale unless otherwise specified.

[0021] Figure 1 A flow chart of a data processing method based on traffic rules provided for an exemplary embodiment of the present disclosure;

[0022] Figure 2 A flow chart of monitoring rule construction provided for an exemplary embodiment of the present disclosure;

[0023] Figure 3 An exemplary diagram of monitoring rule construction provided for an exemplary embodiment of the present disclosure;

[0024] Figure 4 A flow chart of static analysis provided for an exemplary embodiment of the present disclosure;

[0025] Figure 5 An exemplary structural diagram of the electronic device provided for some embodiments of the present disclosure. DETAILED DESCRIPTION

[0026] To make the objectives, technical solutions and advantages of the embodiments of the present disclosure clearer, the technical solutions in the embodiments of the present disclosure will be described clearly and completely below with reference to the drawings in the embodiments of the present disclosure. Obviously, the described embodiments are some but not all of the embodiments of the present disclosure. Based on the embodiments in the present disclosure, all other embodiments obtained by those of ordinary skill in the art without creative work fall within the scope of the present disclosure.

[0027] Figure 1 A data processing method based on traffic rules provided for an exemplary embodiment of the present disclosure, the data processing method comprises:

[0028] S101, constructing a monitoring specification of an asynchronous event stream, the monitoring specification is formally described using an extended Backus-Naur form.

[0029] Specifically, as Figure 2As shown, firstly, compliance requirements and engineering needs are integrated: on the one hand, the current road traffic management regulations and intelligent driving related policy documents in the vehicle operation region are summarized and arranged; on the other hand, the safety target is refined in combination with the results of the functional safety level division and the scene rationality evaluation report. By putting the "must do" (such as red light stop) at the regulation level and the "should do" (such as reducing speed when the distance to the front vehicle is too close, and avoiding obstacles) at the engineering level in the same list for overall consideration, it is ensured that the subsequent monitoring specification conforms to the regulatory constraints and meets the safety design requirements of the vehicle control system.

[0030] Subsequently, based on the vehicle electronic and electrical architecture list and the sensor topology list, the observable objects and attributes are sorted and confirmed: the object range covers five categories of vehicle main body, adjacent vehicle, road infrastructure, non-motor vehicle and pedestrian; under the existing sensor configuration, the attributes that can be directly obtained include absolute position, heading angle, vehicle speed, acceleration, lane number, turn signal state, brake state and the like.

[0031] The object attributes (such as vehicle speed, position, etc.), object relationships (such as the vehicle and the front vehicle in the same lane) and timing constraints (such as red light -> vehicle must stop within 2s) are abstracted from traffic rules. Based on the three concepts, the language function is designed, and in order to ensure the consistency and parsability of the syntax, the language is formally described by using EBNF (Extended Backus-Naur Form) to generate a set of language syntax rules. The EBNF is used to strictly define the syntax level, which ensures that the language is easy to parse and extend.

[0032] The monitoring specification includes at least one input event stream, at least one output derived stream and at least one trigger. The input event stream is used to carry the original data of the vehicle and the road environment. The output derived stream is obtained by calculating the input event stream, and the output derived stream is used to describe the state of the vehicle in the road environment according to the original data. The trigger is used to output a violation alarm when the traffic rule is violated according to the output derived stream.

[0033] Specifically, after completing the object-attribute framework, the specification can be defined, the dynamic entity is discretized into input event stream entries according to the three-dimensional paradigm of "object identification-attribute value-timestamp", and the perception original data stream is declared at the specification language level with the input keyword; for the associated attribute stream of the same object, the group semantic block can be used for logical aggregation, and the unified clock domain is used for time alignment to ensure the consistent basis of the subsequent window semantics.

[0034] The input event stream (input) and the output derived stream (output) are used as the basic syntax components. The derived expressions such as arithmetic, logic, condition and window are provided for the output derived stream to perform function transformation on one or more event streams. The three types of time semantics binding mechanisms, i.e. relative time, offset time and absolute time, are provided to uniformly express the window size, delay or timeout in the multi-run mode. The aggregation concepts such as sliding window and event window are introduced to calculate the time series indicators such as the maximum value in the last n seconds and the average value of m consecutive events. The object relationship predicate set is extended with the new primitives such as nearby, in_lane and has_priority_over to directly describe the spatial or rule relationship between vehicles.

[0035] After the input event stream is ready, the output derived stream is constructed according to the monitoring indicator list provided in the requirement library by using the arithmetic expression, logic expression, time window aggregation expression and offset expression to derive the time series characteristics such as speed, acceleration, relative distance, lateral offset, lane position and signal phase difference. The 5-second moving average vehicle speed can be calculated using avg(speed sliding(5s,1s)). In addition, the following cycle distance can be accessed using offset(dist,-1) and the number of lane change behaviors within 5 seconds can be counted using count(laneChange within 5s). For the occasion that requires periodic inspection instead of event-driven, the time annotation such as @1Hz can be attached to the stream name to explicitly bind the output derived stream to the fixed beat to ensure that the monitor can still actively evaluate the vehicle health status when the perception data is temporarily silent.

[0036] After the output derived stream is defined, the trigger design stage is entered:

[0037] Firstly, the list of “non-compliance events” in the regulation articles and safety planning documents is browsed, and the scenes such as “overspeed”, “too close following”, “lane deviation”, “disallowed area crossing”, “signal conflict” and “sudden deceleration” are mapped to the judgment formula as shown in the following formula: Figure 3 The interval speed measurement on the highway requires that the uniform speed of the car in a section should not exceed the limit value of its designated limit, which is mapped to the specification as “avgSpeed<=road.limitSpeed”. When the dangerous condition of “avgSpeed>road.limitSpeed” is detected, an alarm is given.

[0038] Secondly, the alarm level, text template and disposal strategy are selected for each event.

[0039] Thirdly, the logic conditions are combined using the primitives such as avg, nearby and in_lane in the predicate library.

[0040] Finally, the trigger<bool-expr> " <msg>"Syntax format the alarm stream, and optionally append @level=warning or @level=fatal meta-annotation at the end, to facilitate HMI to distinguish the prompt color and alarm sound level. Figure 3 In the case of interval speed measurement, give warning alarm for the case of instantaneous speed exceeding the threshold, and fatal level alarm for the case of uniform speed exceeding the threshold in the interval.

[0041] The monitoring specification is written in the asynchronous event stream specification language, which presents externally in the form of "timestamp + value", and each event can carry a nanosecond-level timestamp to ensure cross-domain synchronization accuracy. The language introduces UTC time zone markers and millisecond, microsecond, and nanosecond-level time literal quantities at the lexical level, and explicitly specifies the production of keywords, operator precedence, window constructors, time bindings, and trigger items at the syntax level through EBNF (Extended Backus-Naur Form). For example, the "trigger avgSpeed>road.limitSpeed" uniform speed too fast "@level=fatal" trigger statement corresponds to "TriggerDecl = "trigger" BoolExpr [StringLiteral] [AttrClause] ;", which clearly describes the basic structure of the trigger and its optional components. With such an EBNF specification, each syntax rule can be accurately parsed into a unique abstract syntax tree (AST), i.e., there is no structural ambiguity in the parsing process, and the same syntax tree structure is always obtained. This ensures that the parser always produces the same, deterministic output when faced with the same input. This is very important for subsequent semantic analysis, code generation, or program verification, because only by ensuring the uniqueness and determinism of the syntax analysis stage, the subsequent processing can be stable and reproducible, avoiding understanding or execution bias.

[0042] Meanwhile, the semantic layer is modeled by referring to the runtime verification scenario, and four types of semantic units, i.e., event stream reference, expression reference, relation predicate reference and trigger reference, are established. The input event stream is referred to as a mapping time->value, where time is the event occurrence time, and value is the object attribute value. The derived expression is referred to as a function transformation of the input event stream in the time domain; the object relation predicate is referred to as a spatial or rule constraint satisfied between the objects at a given time; and the trigger is referred to as a pre-warning condition function that outputs an alarm or record when returning a true value. The event stream is modeled as Stream:Time→Value, the derived expression is modeled as Expr:(Stream…)×Time→Value, the relation predicate is modeled as Rel:(Object…)×Time→Bool, and the trigger is modeled as Trig:Time→{0,1}. It is uniformly agreed that the trigger generates an alarm event only when the returned value jumps, so that the specification can be directly functionally evaluated in the running stage, and ambiguity interpretation or implicit state is avoided.

[0043] Through the above processing, the monitoring rule covers all core expression requirements related to object attributes, object relations and time constraints in the traffic scene. The reference modeling is used in the semantic layer to ensure that the specification can be formally verified and directly connected with the runtime engine, so as to realize efficient, accurate and low-cost expression and automatic monitoring of traffic rules and vehicle behavior.

[0044] S102, performing static analysis on the monitoring specification to obtain a low-order intermediate representation, the static analysis being used for checking the monitoring specification;

[0045] Specifically, the user-defined monitoring specification is parsed and converted into an intermediate representation for use in the subsequent execution stage. The low-order intermediate representation (IR) refers to the user-defined monitoring specification being compiled, optimized and converted into an instructionized and linearized data structure closer to the machine execution semantics. The static analysis is used for further checking of the monitoring specification to remove invalid input event streams and triggers.

[0046] S103, simulating and verifying the original data based on the low-order intermediate representation, and outputting an alarm according to the verification result.

[0047] Specifically, whether the low-order intermediate trigger is triggered correctly is verified by a preset test set.

[0048] In the embodiment, the speed overrun, lane deviation, too close following distance, signal lamp violation and other key safety events in the intelligent driving scene are described by using the asynchronous event stream specification language as the core and through a unified input event stream / output derived stream / trigger model. The high readability and high verifiability specification meeting the expression needs of complex traffic scenes can be constructed in a short time, the monitoring efficiency and automation degree of the intelligent transportation system are improved, and the rule modeling and maintenance cost are reduced.

[0049] In the embodiment, the low-order intermediate representation is generated by static analysis screening monitoring specification, thereby providing an efficient execution basis for subsequent running simulation verification.

[0050] In one embodiment, the static analysis specifically includes:

[0051] Based on the monitoring specification, an abstract syntax tree is generated, and the abstract syntax tree represents the structural hierarchical relationship between nodes in the monitoring specification.

[0052] Specifically, as shown in Figure 4 First, a lexical-syntactic joint parser is called to scan, tokenize and reduce the monitoring specification text, and an complete abstract syntax tree is output. Then, unique symbol numbers are assigned to all input event streams, output derived streams, window entities and trigger entities in the process of traversing the syntax tree, and the identifier-number mapping relationship is written into the symbol table. For example, if the specification includes "input ego.speed:Float, output avgSpeed:Float=..." and "trigger avgSpeed>road.limitSpeed", the ego.speed, avgSpeed, road.limitSpeed and trigger are respectively assigned symbol numbers (such as 1, 2, 3 and 4), and these names and numbers are recorded in the symbol table for subsequent semantic analysis and code generation.

[0053] If the same name conflict, reserved word misuse or illegal character is found, the parser immediately gives an error prompt with line and column numbers, so that the syntax tree entering the subsequent process has a consistent and unambiguous naming system.

[0054] Type deduction and semantic consistency checking are performed according to the syntax tree. The type deduction and semantic consistency checking are used to detect type conflicts, time unit incompatibility and object relationship predicate compatibility errors.

[0055] Specifically, for arithmetic nodes, the numerical promotion rule is adopted: integers and integers remain integers, and floating points are promoted to floating points. The accuracy of the integer and fixed-point decimal is determined by the fixed-point width. If overflow is found, a warning is inserted. For logical nodes, Booleanization is forced: any non-Boolean operand needs to be compared explicitly before entering logical operation. If an implicit zero-non-zero judgment is detected, the risk of "implicit Booleanization" is prompted in the report. For window aggregation nodes, the compatibility of input domain and aggregation symbol is checked. Numerical aggregation such as avg / sum cannot receive a Boolean stream, and Boolean aggregation such as anyTrue also rejects numerical streams. Once the rule is violated, the compilation is blocked. Then unit algebra deduction is performed to ensure that "speed" is not directly compared with "distance"; if the dimension conflicts, a serious error is recorded. Finally, the object relationship predicate signature is checked. For example, when the vehicle-light combination is found to call nearby, which is limited to vehicle-vehicle predicates, the "object class conflict" is reported. All types unknown, dimension undefined, and semantically contradictory information are written into the diagnosis table; if there are still pending states at the end of iteration, the compilation process is terminated.

[0056] In an embodiment, through the above type derivation and consistency check, it is ensured that only semantically complete, dimensionally correct and type-closed specifications enter the subsequent dependency analysis stage, avoiding runtime hidden risks from the source.

[0057] In an embodiment, the static analysis further includes:

[0058] A flow dependency graph is constructed based on the abstract syntax tree, which is used to describe the data dependency relationship between the input event stream, the output derived stream and the intermediate calculation expression;

[0059] The flow dependency graph is traversed to check the circular reference.

[0060] Specifically, according to the constructed symbol table and the type derivation result, the abstract syntax tree is first scanned for the second time. Each "read-read" relationship is abstracted as a directed edge: if the expression of the output derived stream A references the input event stream B, a directed edge is added from B to A in the flow dependency graph; if the aggregation function of the window W calls the derived stream C again, an edge is also added between C and W. Thus, the incremental construction is performed, and finally all input event streams, output derived streams, window entities and trigger entities are unified as a vertex set, and a complete flow dependency graph is output.

[0061] Then the flow dependency graph is traversed to detect whether there is a loop or a multi-node closed loop in real time; once a loop is found, the shortest path in the loop and the corresponding source code line number are extracted, and a "circular dependency" serious error is recorded, and the compilation is blocked. If the traversal result is a directed acyclic graph, topological sorting is continued, which can not only accurately estimate how much memory and window data are really needed at each step, but also provide a clear and verifiable execution order for the subsequent.

[0062] In the embodiment, when the expression of the first node references the identity of the second node, a directed edge from the second node to the first node is added in the flow dependency graph, and when a loop is detected in the flow dependency graph, a circular dependency error is reported. Thus, the deadlock and logical conflict are reduced, the risk of infinite waiting is eliminated, and the computing power overhead is reduced.

[0063] In one embodiment, the flow dependency graph is constructed based on the abstract syntax tree, specifically including:

[0064] The node reduction and constant folding are performed on the abstract syntax tree to eliminate redundant syntax nodes and simplify the expression structure;

[0065] Based on the set of reduced nodes, the flow declaration nodes, expression nodes and window nodes are extracted, and each node is assigned a unique identity as a vertex set;

[0066] The flow dependency graph is constructed based on the vertex set.

[0067] Specifically, under the premise of ensuring functional equivalence, the flow dependency graph is subjected to optimization such as constant propagation, common sub-expression elimination and window folding: pure constant expressions are directly evaluated at compile time, repeated sub-expressions are merged into a single node, and nested windows that meet the same step and aggregation are folded into larger windows.

[0068] In the embodiment, all entities are renumbered and the dependency relationship is flattened, and a low-level intermediate representation file is output to provide lightweight input for runtime loading and code generation.

[0069] In one embodiment, the static analysis specifically further includes:

[0070] The window nodes in the flow dependency graph are traversed, and the triplets of each window node are recorded;

[0071] The number of events in the window is estimated according to the input event stream history rate or the user set rate, and the memory occupancy is predicted;

[0072] When the predicted memory occupancy exceeds the preset memory threshold, an alarm is output.

[0073] Specifically, the window nodes in the flow dependency graph are traversed one by one, the window length L (for example, the last 10 seconds) written in the syntax tree, the sliding step S (for example, updated once every 100 milliseconds) and the aggregation function F (such as avg, max, count) are read first, and the three are stored in the window resource table as a 〈L, S, F〉 tuple. Subsequently, the real data arrival rate measured in the vehicle calibration stage is referenced to calculate the number of historical samples that the window needs to retain simultaneously in the worst case. If the input event stream bound to the window is a multi-path fusion, the historical sample number is also estimated after adding up the rates of each branch. The system then obtains the peak cache occupancy by multiplying the "number of historical samples x number of bytes per sample", and compares it with the remaining capacity of the target hardware. If the predicted occupancy exceeds 80% of the available upper limit, the window is marked as "high resource risk", and two suggestions are given in the diagnostic report: "appropriately shorten the window length L" or "enlarge the sliding step S", for the developer to trade off accuracy and resources.

[0074] In the present embodiment, through window memory verification, potential memory overflow risks are exposed at the compilation stage, without having to wait until the real vehicle is running to find the problem of insufficient resources.

[0075] In one embodiment, the trigger determines whether the output derived stream triggers a traffic rule violation through a Boolean expression, and the static analysis further includes:

[0076] The system traces the flow dependency graph from bottom to top to calculate the input event stream set of each trigger node;

[0077] In response to the input event stream set being empty or the Boolean expression being always false, the trigger is deleted.

[0078] Specifically, the trigger uses a Boolean expression, and the trigger Boolean expression is referred to as a warning condition function, which outputs an alarm or record when it returns a true value. It is uniformly agreed that the trigger stream only generates an alarm event when the return value jumps from 0 to 1, so that the specification can directly perform function evaluation during the running stage, avoiding ambiguous interpretation or implicit states.

[0079] The system traces the dependency chain from bottom to top to calculate the input event stream set reachable by each trigger node; if the set is empty or the Boolean expression is always false, it is determined that the trigger will not be activated in any running scenario, and it is marked as a dead trigger and a deletion or reconstruction suggestion is output in the diagnostic report.

[0080] In the present embodiment, invalid decision logic can be reduced, and the running period overhead can be reduced.

[0081] In one embodiment, the final summary of type errors, circular dependencies, resource alarms, dead latches, and optimization summaries are outputted in JSON format; if no blocking errors are detected, the "analysisStatus: pass" is marked in the report. The report can be used for integrated development environment highlighting and can be read by the continuous integration pipeline to automatically intercept non-compliant submissions.

[0082] In the above embodiment, by completing the syntax correctness, semantic consistency, and resource feasibility checks before the monitoring specification enters the running phase, and outputting the optimized intermediate representation while ensuring functional equivalence, a safe, reliable, and predictable foundation is laid for subsequent efficient execution.

[0083] In one embodiment, the original data is simulated and verified based on the low-level intermediate representation, and the simulation and verification specifically includes:

[0084] Online simulation, which is used to evaluate the clock-driven event stream when the original data comes from a real-time simulator or a digital twin platform;

[0085] In one embodiment, the simulation and verification further includes:

[0086] Offline simulation, which is used to replay in timestamp order when the original data comes from historical logs or synthetic test sets.

[0087] Specifically, the low-level intermediate representation generated in the static analysis stage is loaded into the runtime memory, and the deployment environment is determined to enter the online verification mode or the offline verification mode, laying a running benchmark for subsequent event injection, derived flow calculation evaluation, and alarm output.

[0088] The verifier first loads the low-level intermediate representation file from the local disk, maps the stream entities, window entities, and trigger entities in it to data structures within the process; then, according to the user-specified simulation scheme, it determines whether to enter the online verification mode or the offline verification mode. If the event-driven data directly comes from a real-time simulator, a digital twin platform, or a hardware-in-the-loop (HIL) interface, the online-simulation mode is enabled to evaluate the flow driven by the host operating system high-precision clock; if the event data source is a historical driving log or a synthetic test set, the offline-replay mode is enabled to replay the data in the order of event timestamps and allows setting a speedup parameter to speed up testing. After the simulation mode is confirmed, the verifier allocates a ring queue buffer for each input event stream, applies a dynamic array for each window, and initializes the trigger state bit to complete the data face preparation.

[0089] In one embodiment, the verifier creates a multi-level priority task queue according to the dependency relationship to ensure the order of dependency; in a typical desktop simulation scenario, a "main thread + worker thread pool" model is used: the main thread pushes periodic tasks and event-driven tasks into a lock-free MPSC queue according to the layer sequence table, and if the queue is congested due to too fast playback speed, the speed is adaptively reduced; the worker thread pulls tasks from the queue and calls the evaluator to calculate the derived flow, thereby maximizing the parallelism of multi-core CPUs, so that the pressure test of the order of magnitude of millions of events can be covered in a PC environment.

[0090] In online verification (simulation) mode, the verifier receives input events pushed by the simulator through shared memory or a local Socket interface; whenever a new sample is written to an input event stream, the system marks the downstream derived flow according to the dependency relationship and pushes the evaluation task into the queue.

[0091] In offline verification (replay) mode, the replay thread reads the log file records sequentially and injects them into the same pipeline; the incremental evaluator updates the aggregate function according to the current pointer of the window register and writes the calculation results back to the flow cache, and then wakes up the downstream nodes in turn to avoid full recalculation.

[0092] When the last input of a trigger is ready, the verifier calculates the Boolean result using the reverse Polish evaluator on the stack; if its logical value changes from false to true, a violation JSON record is immediately generated, including the simulation time, trigger ID, scene ID, severity level, and text description, and written to the result file, which can also be pushed to a visualization dashboard in real time to observe the rule hit frequency.

[0093] In one embodiment, verification logs are recorded and offline replay is supported.

[0094] During operation, the verifier stores all input events, derived flow snapshots, and output alerts on the disk in a ring block; the file is organized in segments, each with a CRC and a time index for quick positioning afterwards. The test team can load the log file in a bench environment and use the offline mode of the verifier to replay the historical data for the second time to reproduce the on-site violation cause or evaluate new rules, forming a closed-loop iteration.

[0095] In this embodiment, with the help of incremental evaluation and hierarchical scheduling mechanism, the system can achieve millisecond-level detection delay in a PC simulation environment; in the FPGA (Field Programmable Gate Array) deployment form, microsecond-level alarm output is achieved, thereby providing high-throughput, low-power, and verifiable real-time monitoring capability at the vehicle end. Through the log replay interface and automatic code generation link, the scheme supports rapid iteration of rules, offline regression testing, and one-key solidification of software and hardware, significantly reducing development and maintenance costs, and providing strong protection for the safe and compliant operation of intelligent driving systems in complex traffic environments.

[0096] In one embodiment, the data processing method further comprises: in response to the verification result being satisfied after the original data is simulated and verified based on the monitoring specification in the simulation environment, converting the low-level intermediate representation into software source code, compiling and linking the software source code to generate an executable file, deploying the executable file to the vehicle, and performing real-time monitoring.

[0097] Specifically, when the preset test set passes in the PC environment in the online verification or offline verification mode and no new semantic error is triggered, the system calls the C code generator to translate the intermediate representation into pure C99 source code, and directly compiles and links the source code to generate a Linux executable file for subsequent rapid interface verification with the vehicle ECU or software and hardware in-the-loop joint debugging.

[0098] In one embodiment, the data processing method further comprises: in response to the verification result being satisfied after the original data is simulated and verified based on the monitoring specification in the simulation environment, converting the low-level intermediate representation into hardware description language code, and generating a bitstream file from the hardware description language code, and burning the bitstream file to an FPGA for real-time monitoring.

[0099] Specifically, when the PC simulation verification passes and there is a higher requirement for real-time performance, the system calls the VHDL generator to convert the same intermediate representation into synthesizable hardware description, and then completes high-level synthesis and timing analysis in the local FPGA development environment to generate a bitstream for delivery to the hardware team for burning and testing. If the subsequent hardware-in-the-loop regression test still maintains the same result as the PC simulation, it is declared that the rule solidification phase is completed.

[0100] The runtime verifier of the embodiments of the present disclosure can complete online simulation and offline playback double testing of the rules on the PC side, not only verifying semantic correctness, but also verifying performance bottlenecks under large-scale data conditions. Only when the PC simulation passes and the real-time performance requirement is met, the system will automatically enter the C code and FPGA code generation process, avoiding the rework cost caused by premature solidification, and ensuring that each traffic rule is subjected to sufficient offline deduction and stress testing before entering the vehicle deployment phase.

[0101] In one embodiment, the data processing method further comprises:

[0102] The output alarm includes alarm text, alarm level, vehicle identification, and timestamp, and is output through a network interface or local storage.

[0103] In the present embodiment, when the trigger is triggered, the output alarm includes alarm text, alarm level, vehicle identification, and timestamp, and is output through a network interface or local storage. Thus, the alarm function is realized and displayed to the user.

[0104] Corresponding to the implementation manners of the above data processing method, the embodiments of the present disclosure further provide a data processing system for executing the data processing method of any of the preceding embodiments. The data processing system comprises:

[0105] A monitoring specification construction module is configured to construct a monitoring specification of the asynchronous event stream and to use an extended Backus-Naur form to formally describe the monitoring specification; the monitoring specification comprises at least one input event stream, at least one output derived stream, and at least one trigger.

[0106] An emulation verification module is configured to perform emulation verification based on the monitoring specification and to output an alarm according to a verification result.

[0107] In one embodiment, the apparatus further comprises:

[0108] A static analysis module is configured to perform static analysis based on the monitoring specification and to generate a low-order intermediate representation.

[0109] An intermediate representation loading module is configured to load the low-order intermediate representation file from a storage medium when the verification environment is started and to map the stream entity, the window entity, and the trigger entity in the low-order intermediate representation file into a memory data structure.

[0110] In one embodiment, the apparatus further comprises:

[0111] A scheduling engine module is configured to construct a multi-level task queue according to a scheduling layer sequence table generated in the static analysis stage and to maintain the ordered scheduling of event-driven tasks and periodic-driven tasks during the running period.

[0112] In one embodiment, the apparatus further comprises:

[0113] A running mode selection module is configured to automatically determine whether to enter an online-emulation mode or an offline-replay mode according to a user configuration or a data source and to initialize an input channel, a time reference, and a speedup parameter according to the determination.

[0114] In one embodiment, the apparatus further comprises:

[0115] An event injection module is configured to receive event data pushed by a real-time emulator or a digital twin platform in the online-emulation mode, to replay log events in a timestamp order in the offline-replay mode, and to write the events into a unified task queue.

[0116] In one embodiment, the apparatus further comprises:

[0117] An incremental evaluation module is configured to perform incremental calculation on a derived stream, a window aggregation function, and an offset expression according to a dependency relationship and to write the calculation result back to a stream cache until all tasks of a current layer are completed.

[0118] In one embodiment, the apparatus further comprises:

[0119] a trigger decision module for resolving the reverse polish notation expression of the trigger upon all dependent inputs being ready, and generating a violation result and pushing it to the output buffer immediately if the logic value changes from false to true.

[0120] In one embodiment, the apparatus further comprises:

[0121] an alert output module for serializing the violation result into JSON lines or Protobuf batch format, and writing it to a log file, a network interface, or a visual dashboard.

[0122] In one embodiment, the apparatus further comprises:

[0123] a software verifier generation module for expanding the intermediate representation into C99 source code and compiling it natively upon passing both online-simulation and offline-replay tests, and generating a deployable executable file;

[0124] a hardware verifier generation module for converting the intermediate representation into a VHDL description file and automatically invoking a high-level synthesis tool to generate a burnable bitstream for deployment on FPGA in scenarios with high real-time requirements.

[0125] In one embodiment, the apparatus further comprises:

[0126] a log archiving and replay module for writing the input events, derived flow snapshots, and alert records into external storage as time-sliced segments with CRC during the verification process, and reproducing the test process through offline-replay mode when needed to support rule iteration and comparative analysis.

[0127] In addition, some embodiments of the present application also provide an electronic device. The electronic device can be various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and the like. The electronic device can also be various forms of mobile devices, such as personal digital assistants, cellular phones, smart phones, wearable devices, and other similar computing devices.

[0128] The above runtime verification system of the present disclosure and the runtime verification method of the embodiments of the present disclosure are based on the same inventive concept, and have the same beneficial effects as the method employed, run, or implemented.

[0129] The electronic device includes one or more processors and a memory storing computer program instructions that, when executed, cause the processor to perform the steps of the method provided by any one or more of the above embodiments. Figure 5 An exemplary structural diagram of the electronic device is disclosed. The electronic device includes one or more processors 1101, memory 1102, and an interface for connecting the components, including a high-speed interface and a low-speed interface. The components are interconnected through different buses, and can be mounted on a common main board or otherwise installed as needed. The processor can process instructions executed within the electronic device, including instructions stored in the memory or on the memory to display a GUI on an external input / output device such as a display device coupled to the interface. In some other embodiments, a plurality of processors and / or buses can be used with a plurality of memories and a plurality of memory, if necessary. Also, a plurality of electronic devices can be connected, each device providing part of the necessary operations. Among them, the components shown herein, their connections and relationships, and their functions are merely examples, and are not intended to limit the implementation of the present application described and / or claimed herein.

[0130] The electronic device can further include an input device 1103 and an output device 1104. The processor 1101, the memory 1102, the input device 1103, and the output device 1104 can be connected through a bus or otherwise, and are connected through a bus in the figure.

[0131] The input device 1103 can receive input digital or character information, and generate key signal input related to user settings and function control of the electronic device, such as a touch screen, a keypad, a mouse, a trackpad, a touchpad, a pointing stick, one or more mouse buttons, a trackball, a joystick, etc. The output device 1104 can include a display device, an auxiliary lighting device (e.g., an LED), and a tactile feedback device (e.g., a vibration motor), etc. The display device can include, but is not limited to, a liquid crystal display, a light emitting diode display, and a plasma display. In some embodiments, the display device can be a touch screen.

[0132] To provide interaction with the user, the electronic device can be a computer. The computer has a display device (e.g., a cathode ray tube or an LCD monitor) for displaying information to the user, and a keyboard and a pointing device (e.g., a mouse) through which the user can provide input to the computer. Other kinds of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback); and input from the user can be received in any form (e.g., voice input or tactile input).

[0133] In the embodiments of the present application, the computer program / instruction stored on the computer readable medium is executed by the processor to implement the steps of the method provided by any one or more of the embodiments described above. The computer readable medium can be included in the electronic device described in the embodiments above, or can exist separately and not be assembled into the device. The computer readable medium carries one or more computer readable instructions.

[0134] The memory 1102 can be used to store non-transitory software programs, non-transitory computer executable programs and modules. The processor 1101 executes various functions and data processing of the server by running the non-transitory software programs, instructions and modules stored in the memory 1102, so as to implement the program instructions / modules corresponding to the method provided by any one or more of the embodiments described above in the embodiments of the present application.

[0135] The memory 1102 can include a program storage area and a data storage area. The program storage area can store an operating system and at least one application required by a function. The data storage area can store data created according to the use of the electronic device. In addition, the memory 1102 can include a high-speed random access memory, and can also include a non-transitory memory, such as at least one magnetic disk storage device, a flash memory device, or other non-transitory solid-state memory device. In some embodiments, the memory 1102 can optionally include a memory disposed remotely with respect to the processor 1101, and these remote memories can be connected to the electronic device through a network. Examples of the network include but are not limited to the Internet, an intranet, a local area network, a mobile communication network, and a combination thereof.

[0136] It should be noted that the computer readable medium described in the present application can be a computer readable signal medium or a computer readable storage medium or any combination of the two. The computer readable medium may, for example, but is not limited to, an electrical, magnetic, optical, electromagnetic, infrared or semiconductor system, device or instrument, or any combination of the above. More specific examples of computer readable storage media can include, but are not limited to, an electrical connection with one or more conductive wires, a portable computer disk, a hard disk, a random access memory, a read-only memory, an erasable programmable read-only memory, an optical fiber, a portable compact disk read-only memory, an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present application, the computer readable medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, device or instrument.

[0137] Computer-readable media includes permanent and non-permanent, movable and non-movable media that can be implemented by any method or technology for information storage. Information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase-change memory, static random access memory, dynamic random access memory, other types of random access memory, read-only memory, electrically erasable programmable read-only memory, flash memory or other memory technologies, read-only optical discs, digital versatile discs or other optical storage, magnetic cassette tapes, magnetic tape discs storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible to a computing device.

[0138] Computer program code for carrying out operations of the present application can be written in one or more programming languages or combinations of languages including object-oriented, such as Java, Smalltalk, C++, conventional procedural programming languages, such as the C programming language or similar programming languages. Program code can be executed entirely on a user computer, partially on a user computer, as a standalone software package, partially on a user computer and partially on a remote computer, or entirely on a remote computer or server. In the case of a remote computer, the remote computer can be connected to the user computer through any kind of network, including a local area network or a wide area network, or can be connected to an external computer (for example, using an Internet service provider to connect through the Internet).

[0139] In the above embodiments, all or part can be implemented by software, hardware, firmware or any combination thereof. For example, a dedicated integrated circuit, a general-purpose computer or any other similar hardware device can be used. In some embodiments, the software program of the present application can be executed by a processor to implement the above steps or functions. Similarly, the software program of the present application (including related data structures) can be stored in a computer-readable recording medium, such as RAM memory, magnetic or optical drive or soft disc and similar devices. In addition, some steps or functions of the present application can be implemented by hardware, for example, as a circuit cooperating with the processor to perform each step or function.

[0140] The computer program product provided by the embodiments of the present application includes one or more computer programs / instructions, which, when executed by a processor, generate all or part of the processes or functions described in the embodiments of the present application. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium, for example, the computer instructions can be transmitted from one website, computer, server or data center to another website, computer, server or data center through wired (such as coaxial cable, optical fiber, digital subscriber line) or wireless (such as infrared, wireless, microwave, etc.) mode. The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server, data center, etc. integrated with one or more available media. The available media can be magnetic media (such as floppy disk, hard disk, magnetic tape), optical media (such as DVD), or semiconductor media (such as solid state disk), etc.

[0141] The flowcharts or block diagrams in the drawings illustrate the architecture, functionality, and operation of possible implementations of devices, methods, and computer program products according to various embodiments of the present application. In this regard, each block in the flowcharts or block diagrams can represent a module, a segment, or a portion of code, which comprises one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions noted in the blocks can occur in a different order than that shown in the figures. For example, two blocks noted in succession can actually be executed substantially concurrently, or they can sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented by dedicated hardware-based systems that perform the specified functions or operations, or can be implemented by a combination of dedicated hardware and computer instructions.

[0142] The scope of the present application is defined by the appended claims rather than the description set forth above, and therefore the intent of the application is to be encompassed within the meaning and range of equivalents of the claims. Any reference signs in the claims should not be construed as limiting the claims to the figures in which the reference signs are used. Furthermore, the words "comprise" and "contain" do not exclude other elements or steps, and the singular "a" or "an" does not exclude the plural. Multiple units or apparatuses stated in the apparatus claims can also be implemented by one unit or apparatus, either by software or hardware. The words "first", "second" and the like do not imply any particular order, but they are used to identify different components. They also do not indicate or imply any relative importance of the referenced elements.

[0143] The above merely provides specific examples of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical scope disclosed by the present application, which should be covered by the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims, and the above examples should be regarded as exemplary and non-limiting.< / msg> < / bool-expr>

Claims

1. A data processing method based on traffic rules, characterized by, The data processing method comprises: constructing a monitoring specification of an asynchronous event stream, the monitoring specification being described in a formalized manner using an extended Backus-Naur form; the monitoring specification comprising at least one input event stream, at least one output derived stream, and at least one trigger; the input event stream being used to carry original data of a vehicle and a road environment; the output derived stream being obtained by calculation on the input event stream, and being used to describe a state of the vehicle in the road environment according to the original data; the trigger being used to output a violation alarm when a traffic rule violation is triggered according to the output derived stream; performing static analysis on the monitoring specification to obtain a low-level intermediate representation, the static analysis being used to check the monitoring specification; based on the low-level intermediate representation, performing simulation verification on the original data, and outputting an alarm according to a verification result.

2. The data processing method of claim 1, wherein, The static analysis specifically comprises: based on the monitoring specification, generating an abstract syntax tree, the abstract syntax tree representing a structural hierarchical relationship between nodes in the monitoring specification; performing type deduction and semantic consistency checking according to the syntax tree.

3. The data processing method of claim 2, wherein, The static analysis specifically further comprises: based on the abstract syntax tree, constructing a flow dependency graph, the flow dependency graph being used to describe a data dependency relationship between the input event stream, the output derived stream, and an intermediate calculation expression; traversing the flow dependency graph to perform a circular reference check.

4. The data processing method of claim 3, wherein, The flow dependency graph is constructed based on the abstract syntax tree, specifically comprising: performing node reduction and constant folding on the abstract syntax tree to eliminate redundant syntax nodes and simplify expression structures; based on a set of reduced nodes, extracting flow declaration nodes, expression nodes, and window nodes, and assigning a unique identifier to each node as a vertex set; based on the vertex set, constructing the flow dependency graph.

5. The data processing method of claim 4, wherein, The static analysis specifically further comprises: traversing window nodes in the flow dependency graph to record a triple of each window node; estimating a number of events in a window according to an input event stream historical rate or a user-set rate, and predicting memory occupancy; when the predicted memory occupancy exceeds a preset memory threshold, outputting an alarm.

6. The data processing method of claim 5, wherein, The trigger judges whether the output derived stream triggers a traffic rule violation through a Boolean expression, and the static analysis further comprises: backtracking the flow dependency graph from bottom to top to calculate a set of input event streams of each trigger node; in response to the set of input event streams being empty or the Boolean expression being always false, deleting the trigger.

7. The data processing method of claim 1, wherein, The simulation verification on the original data based on the low-level intermediate representation specifically comprises: online simulation, which is used to evaluate a clock-driven event stream when the original data comes from a real-time simulator or a digital twin platform; and / or; offline simulation, which is used to replay according to a timestamp sequence when the original data comes from historical logs or a synthetic test set. The data processing method further comprises:

8. The data processing method of claim 1, wherein, in response to the verification result being satisfied after the simulation verification on the original data based on the monitoring specification in a simulation environment, converting the low-level intermediate representation into software source code, compiling and linking the software source code to generate an executable file, and deploying the executable file on a vehicle to perform real-time monitoring. ​ and / or; In response to the simulation verification of the original data based on the monitoring specification in the simulation environment satisfying a verification result, the low-order intermediate representation is converted into hardware description language code, and the hardware description language code is generated into a bit stream file, the bit stream file is burned to an FPGA, and real-time monitoring is performed.

9. An electronic device, comprising: The electronic device comprises: one or more processors; and a memory storing computer program instructions which, when executed, cause the processor to perform the steps of the method of any one of claims 1 to 8.

10. A computer program product comprising computer programs / instructions, characterized in that, The computer program / instructions, when executed by the processor, implement the steps of the method of any one of claims 1 to 8.

Images