Robot monitoring node automatic generation method based on structured natural language

Abstract

The invention relates to the technical field of safety verification of robot operating systems, in particular to a robot monitoring node automatic generation method based on a structured natural language. The method comprises the following steps: acquiring a structured natural language monitoring requirement; analyzing and converting the data into a probability sequential logic formula and a variable mapping relation; verifying whether the variable exists in the target data stream framework or not; and automatically generating a monitoring node capable of running in the data stream framework based on the verified formula and the mapping relation. And when the monitoring node runs, monitoring variable update, and only triggering conformity judgment of the correlation formula. The problems that in the prior art, requirement conversion is difficult, monitoring logic and a platform are strongly coupled, and execution time is unpredictable are solved, and requirement unambiguous formalization and monitoring code full-automatic generation are achieved.

Description

Technical Field

[0001] This application relates to the field of robot operating system security verification technology, and in particular to a method for automatically generating robot monitoring nodes based on structured natural language. Background Technology

[0002] In the software development of safety-critical systems such as robots and autonomous driving, runtime verification (RV) technology is widely used to ensure that system behavior always conforms to preset safety specifications. This technology continuously detects whether the system state violates safety requirements at runtime by embedding monitoring code (often manifested as monitoring nodes in the software architecture).

[0003] However, existing runtime verification technologies have significant limitations in practical applications. First, security requirements described in natural language are ambiguous, and the conversion from requirements to formal logic usually relies on manual work, which is error-prone and inefficient, lacking an efficient, automated, and precise conversion mechanism. Second, at the monitor implementation level, solutions such as ROSRV require writing a large amount of code manually, resulting in a heavy development burden; while the monitoring logic generated by automated tools such as HAROS and ROSMonitoring is usually deeply coupled with specific middleware such as the Robot Operating System (ROS), leading to poor portability. Finally, at the performance level, existing monitors are mostly based on non-real-time execution models (such as event callbacks or polling), whose execution time is unpredictable, failing to meet the deterministic requirements of hard real-time systems, and easily introducing significant performance overhead.

[0004] Therefore, existing technologies have long suffered from three major drawbacks: difficulty in formalizing requirements, strong coupling between monitoring implementation and specific platform frameworks, and inability to guarantee real-time performance. This application aims to address these issues. Summary of the Invention

[0005] This application proposes an automatic generation method for robot runtime monitoring nodes to address the technical problems of existing runtime verification technologies, such as difficulties in formalizing requirements, high coupling between monitoring implementation and specific platform frameworks, and difficulty in meeting hard real-time performance requirements with monitoring code.

[0006] This application provides a method for automatically generating robot runtime monitoring nodes, including: Obtain monitoring requirements described in structured natural language; The structured natural language monitoring requirements are parsed according to their grammatical structure and automatically converted into formalized probabilistic temporal logic formulas and the mapping relationships of variables in the formulas; Based on the mapping relationship of the variables, verify whether the variables exist in the target data flow framework; Based on the verified probabilistic temporal logic formula and the mapping relationship of the variables, a monitoring node that can run in the data flow framework is automatically generated. The monitoring node is configured to listen for updates of the corresponding variables according to the mapping relationship of the variables when the data flow framework is running, and trigger a conformity judgment on the probabilistic temporal logic formula associated with any variable only when any variable is updated.

[0007] In some embodiments of this application, the structured natural language is a FRETISH language with a predefined syntax structure, and the statements used to describe monitoring requirements include six fields: scope, condition, component, probability, timing, and response.

[0008] In some embodiments of this application, the formalized probabilistic temporal logic formula is a probabilistic computation tree logic formula; Furthermore, the mapping relationship of the variables is recorded in a separate mapping file.

[0009] In some embodiments of this application, verifying the existence of the variable in the target data flow framework includes: Parse the definition file of the target data flow framework and check whether the variables in the mapping relationship of the variables are declared in the definition file.

[0010] In some embodiments of this application, the step of parsing the structured natural language monitoring requirements according to their grammatical structure and automatically converting them into formal probabilistic temporal logic formulas includes: When the monitoring requirement includes a time constraint, the time constraint is converted into a time sequence operator in the probabilistic time sequence logic formula.

[0011] In some embodiments of this application, the step of parsing the structured natural language monitoring requirements according to their grammatical structure and automatically converting them into formal probabilistic temporal logic formulas includes: When the monitoring requirement includes the persisted(n, condition) operator, the persisted(n, condition) operator is converted, wherein the persisted(n, condition) operator is used to indicate that the condition must be true within n consecutive time units.

[0012] In some embodiments of this application, the monitoring node includes a variable receiving module, a monitor detection module, and a violation processing module, wherein: The variable receiving module is used to receive data streams from the data stream framework and parse and record the updates of the variables; The monitoring detection module maintains a variable-formula mapping table to record the mapping relationship between variables and the probability time-series logic formulas, and based on the mapping relationship, it realizes that when a variable is updated, only the conformity judgment of the formula associated with the variable is triggered. The violation handling module is used to execute a predetermined response strategy when the compliance judgment result is non-compliance, wherein the response strategy supports user-defined configuration.

[0013] In some embodiments of this application, the data stream framework is a zero-copy data stream framework.

[0014] In some embodiments of this application, the method further includes: The generated monitoring nodes and their configuration files are packaged, and the packaged monitoring nodes are registered to the definition of the target data flow framework by running the installation script.

[0015] In some embodiments of this application, the installation script is configured to automatically modify the definition file of the target data flow framework to add input / output interface declarations for the monitoring node.

[0016] In summary, the automatic generation method for robot runtime monitoring nodes proposed in the embodiments of this application firstly describes the requirements using structured natural language (such as Fresh) and automatically parses and converts them into formal probabilistic temporal logic (PCTL) formulas according to their syntax, thus constructing an automated and unambiguous conversion path from natural language to a formal model, solving the problem of difficult formal conversion of requirements. Secondly, by verifying the existence of variables in the target data flow framework before generation and generating monitoring nodes that can run in this framework, the monitoring logic is decoupled from specific middleware (such as ROS), making the generated nodes platform-portable and solving the problem of strong coupling between monitoring implementation and specific platform frameworks. Thirdly, by configuring an event-driven evaluation mechanism based on variable mapping for the generated nodes (triggering specific formula judgments only when related variables are updated) and generating nodes for a zero-copy data flow framework, the execution path of the monitor is determined and the execution time is short and controllable, thus solving the problem of difficulty in guaranteeing real-time performance of generated code. The above technical features work together to form a fully automatic generation scheme from unambiguous requirements to portable, high-performance monitoring nodes, achieving significant technical progress. Attached Figure Description

[0017] The features and advantages of this application will become clearer with reference to the accompanying drawings, which are illustrative and should not be construed as limiting the application in any way. In the drawings: Figure 1This is a schematic diagram of the overall process of the automatic generation method for robot runtime monitoring nodes described in this application; Figure 2 This is an example diagram of the AST structure tree formed after parsing the FRETISH requirements described in this application; Figure 3 This is a flowchart illustrating an automatic generation method for robot runtime monitoring nodes according to some embodiments of this application; Figure 4 This is an example diagram of the variable-PCTL expression mapping file format in one embodiment of this application; Figure 5 This is a diagram of the monitoring operator node architecture generated in one embodiment of this application; Figure 6 This is a schematic diagram of a data flow definition file in one embodiment of this application. Detailed Implementation

[0018] In the following detailed description, numerous specific details of this application are illustrated by example to provide a thorough understanding of the relevant disclosure. However, it will be apparent to those skilled in the art that this application can be practiced without these details. It should be understood that the terms “system,” “apparatus,” “unit,” and / or “module” used in this application are one way of distinguishing different parts, elements, sections, or components at different levels in a sequential arrangement. However, these terms may be replaced with other expressions if other expressions can achieve the same purpose.

[0019] It should be understood that when a device, unit, or module is referred to as being "on," "connected to," or "coupled to" another device, unit, or module, it may be directly connected to or coupled to or communicate with other devices, units, or modules, or there may be intermediate devices, units, or modules present, unless the context explicitly indicates otherwise. For example, the term "and / or" as used herein includes any one and all combinations of one or more of the relevant listed items.

[0020] The terminology used in this application is for the purpose of describing specific embodiments only and is not intended to limit the scope of this application. As shown in the specification and claims of this application, unless the context clearly indicates otherwise, words such as "a," "an," "an," and / or "the" do not specifically refer to the singular and may also include the plural. Generally speaking, the terms "comprising" and "including" only indicate that explicitly identified features, integrals, steps, operations, elements, and / or components are included, and such expressions do not constitute an exclusive list, and other features, integrals, steps, operations, elements, and / or components may also be included.

[0021] Referring to the following description and accompanying drawings, these and other features and characteristics, operating methods, functions of related structural elements, combinations of parts, and economics of manufacture of this application can be better understood, wherein the description and drawings form part of the specification. However, it is clearly understood that the drawings are for illustrative and descriptive purposes only and are not intended to limit the scope of protection of this application. It is understood that the drawings are not drawn to scale.

[0022] Various structural diagrams are used in this application to illustrate various variations of the embodiments according to this application. It should be understood that the preceding or following structures are not intended to limit this application. The scope of protection of this application is determined by the claims.

[0023] In the development of safety-critical systems such as robots and autonomous driving, ensuring that the system's runtime behavior consistently conforms to preset safety specifications is crucial. Runtime Verification (RV) technology, which continuously monitors the operational status by deploying monitoring nodes (i.e., software units that execute monitoring logic) within the system, is a core means of ensuring functional safety. However, in actual deployments, existing RV technologies suffer from a break in the complete implementation chain from vague requirements to reliable monitoring code. The root cause lies in three interrelated systemic defects: First, there is a formalization gap on the requirements side. Safety engineers often describe requirements using ambiguous natural language, while machine-executable formal logic (such as Probabilistic Computation TreeLogic (PCTL), also known as probabilistic temporal logic formulas) is relatively obscure. Existing solutions (such as ROSMonitoring, a runtime verification tool for the Robot Operating System (ROS)) largely rely on manual conversion of requirements into formal logic, which is inefficient and prone to misunderstandings, leading to subsequent runtime verification failures. Second, on the implementation side, there are issues of strong platform coupling and inefficient development. Even after formalizing requirements, the cost of converting them into a runnable monitor remains high. For example, ROSRV requires manually writing a large amount of boilerplate code to implement logic such as topic subscription and message processing, which is tedious and error-prone; while the requirements specifications of automation tools such as HAROS embed platform-specific information such as themes of the Robot Operating System (ROS), resulting in a deep binding between the monitor and the ROS framework, making it difficult to port to other dataflow frameworks such as DORA. Finally, on the performance side, there is a bottleneck where hard real-time performance cannot be guaranteed. Safety-critical scenarios require monitors to have microsecond-level deterministic response capabilities, but existing solutions (such as monitors based on ROS event callbacks) have unpredictable execution paths and time consumption, which cannot meet hard real-time constraints.

[0024] To systematically address the aforementioned problems, this application proposes a fully automated method for generating robot monitoring nodes based on structured natural language.

[0025] like Figure 1 As shown, the proposed solution constructs an end-to-end automated generation framework, whose core process includes the following three stages: The first stage (requirements elicitation and formalization) involves transforming unambiguous FRETISH into structured natural language requirements (whose grammatical structure can be parsed as follows). Figure 2 The AST tree shown is automatically parsed and converted into precise probabilistic temporal logic (PCTL) formulas and variable mapping relationships by FRET (Formal Requirements Elicitation Tool, a structured natural language requirements editing and analysis tool developed by NASA).

[0026] The second phase (system check) uses the DORAApp generation module, combined with the target system's data flow framework definition file (dataflow.yml), to verify the existence of variables in the requirements, thereby decoupling the monitoring logic from the underlying platform.

[0027] The third stage (monitor node generation) automatically synthesizes monitor operators that can run independently within the dataflow framework, based on the validated formal requirements. Internally, these operators employ an efficient event-driven architecture (such as...). Figure 5 (As shown).

[0028] Through the closed-loop process implemented by this framework, this application effectively solves the aforementioned three major defects: First, it eliminates the formal gap of requirements by using structured natural language and automatic formal parsing; second, it decouples the monitor from the platform by verifying the existence of variables and generating a general data flow framework; and third, it ensures the hard real-time performance of the monitoring logic by using lightweight event-driven monitoring nodes.

[0029] The following, in conjunction with the accompanying drawings, provides a detailed description of the fully automated generation method for robot monitoring nodes based on structured natural language proposed in this application.

[0030] Figure 3 This is a flowchart illustrating a method for automatically generating robot runtime monitoring nodes according to some embodiments of this application. For example... Figure 3 As shown, the method includes: S310, obtain monitoring requirements described in structured natural language.

[0031] This method begins by reading a monitoring requirement file written in structured natural language. This file can contain multiple monitoring requirements. The structured natural language is Fresh. Fresh is a restricted natural language that eliminates ambiguity through six predefined fields: scope, condition, component, probability, timing, and response. In Fresh statements, the condition field supports the persisted(n, condition) operator to indicate that the condition remains true for n time units; the timing field supports time constraints such as within n seconds. This structured expression allows complex timing requirements to be formalized unambiguously.

[0032] S320, the structured natural language monitoring requirements are parsed according to their grammatical structure and automatically converted into formalized probabilistic temporal logic formulas and the mapping relationship of variables in the formulas.

[0033] This step corresponds to the requirements elicitation and formalization phase. Specifically, the read FRETish monitoring requirements are handed over to the running FRET tool, which transforms them one by one into an Abstract Syntax Tree (AST). Then, the AST structure tree is parsed to obtain the Probability Computation Tree Logic (PCTL) formula corresponding to each monitoring requirement, as well as a description of the variable mapping relationships in the formula.

[0034] The transformation process can be illustrated with a concrete example. For instance, for the FRETISH statement: "ONLY INmode1, AND UPON trigger, The system SHALL with probability>=0.9, within 5 seconds, satisfy photo_check(x,y)", the FRET tool generates the following AST structure after parsing it: Figure 2 As shown, this AST tree clearly demonstrates the logical structure after the requirements are decomposed, with each node containing six fields describing the requirements.

[0035] Ultimately, this phase yielded two key results: Formalized probabilistic temporal logic formulas, i.e. PCTL formulas obtained from AST analysis.

[0036] The mapping relationship between variables is recorded in a separate mapping file. In some embodiments of this application, the following is used: Figure 4The JSON-formatted mapping file shown establishes the association between variables and PCTL expressions. This file contains fields such as PCTL formula group, variable type, and the variable corresponding to the formula. The purpose of this mapping is to ensure that during system runtime, when a variable changes, the system can accurately locate and trigger only the monitoring logic associated with that variable for evaluation.

[0037] S330, Based on the mapping relationship of the variables, verify whether the variables exist in the target data flow framework.

[0038] This step corresponds to the system check phase. The specific process is executed by the DORAApp monitoring operator generation module, which reads the PCTL formula file and variable mapping relationship file generated by the FRET tool in the previous stage, and then substitutes them into the definition file (e.g., dataflow.yml) of the target dataflow framework (such as DORA, a middleware system based on a dataflow framework) to check whether the sources of all variables and functions in the PCTL formula have been defined.

[0039] This verification mechanism automatically substitutes the variable mapping relationships output by FRET into the data flow definition file for inspection to confirm the existence of the specific definitions of variables and processing functions in the monitoring requirements. If the inspection finds a missing source of a variable, the system will display the missing information and skip the monitoring requirements related to the missing variable, thereby identifying and avoiding integration errors in advance before generation.

[0040] This step is crucial for achieving the invention's effect. Through this platform-independent variable existence check, monitoring requirements described in Fresh and without any data flow framework-specific information can be adapted to specific data flow frameworks. This decouples monitoring requirements from platform usage and is the core technological foundation ensuring the monitor's "plug-and-play" capability across different data flow frameworks.

[0041] S340, Based on the verified probabilistic temporal logic formula and the mapping relationship of the variables, a monitoring node capable of running in the data flow framework is automatically generated. The monitoring node is configured to, when the data flow framework is running, listen for updates of the corresponding variables according to the mapping relationship of the variables, and when any variable is updated, only trigger a conformity judgment on the probabilistic temporal logic formula associated with that variable.

[0042] This step corresponds to the monitoring operator node generation phase and covers subsequent deployment and integration. Specifically, it includes: automatically generating monitoring operator nodes that run within the data flow framework based on the verified variable mapping relationship description, and generating complex number monitors by reading each PCTL formula. Monitoring nodes are then automatically added to the data flow definition file according to the required variables.

[0043] Figure 5 This is a diagram of the monitoring operator node architecture generated in one embodiment of this application. For example... Figure 5 As shown, The monitoring node (i.e., the monitoring operator node) comprises three modules: Variable receiving module: The data flow definition file has configured the input ports of the monitoring nodes. This module is used to parse the variables corresponding to the inputs and record them in historical data. When the received variables are updated, the monitor detection module is called in a timely manner.

[0044] Monitor detection module: When this module is called by the variable receiving module, it selects the associated monitor to perform condition judgment based on the changed variable; if the condition is not met, it calls the violation handling module. This module utilizes variables generated by S320. The PCTL mapping mechanism enables precise triggering of monitoring logic.

[0045] Violation handling module: When this module is called by the monitoring detection module, it invokes the user-defined violation handling strategy based on the monitoring device that triggered the violation. Since the violation handling module and the monitoring detection module only have a calling relationship, they can be designed separately and independently, making it convenient for users to develop custom violation handling logic.

[0046] During system operation, monitoring nodes constantly listen for the latest values ​​of variables and re-evaluate all monitors associated with the variable when new data arrives. As shown in the following running example, when a variable changes, the monitors established for this monitoring requirement are triggered, thus achieving the re-evaluation of all monitors associated with the variable when new data arrives.

[0047] After generating the nodes, the deployment steps are also included: The generated monitoring nodes and their configuration files are packaged, and an installation script is run to register the packaged monitoring nodes into the definition of the target data flow framework. In practice, the integration process requires only three steps: First, copy the entire monitoring node generation package to any directory of the data flow framework; second, run the installation script (e.g., . / monitor.sh followed by the path to the data flow definition file) to create the monitoring nodes; finally, start the original system. This installation script will automatically modify the data flow framework's definition file to complete the integration.

[0048] Running Example The implementation and operation of this method are further illustrated below through a specific embodiment.

[0049] Suppose there is a security monitoring requirement described in natural language as follows: "When mode1 is triggered, the system needs to satisfy the result of the photo_check(x, y) function within 1 second when the trigger is triggered, and the total success rate of the condition judgment should be above 90%." First, the requirement is expressed as the following Fresh structured natural language statement: ONLY IN mode1, AND UPON trigger, The system SHALL with probability>=0.9, within 1 seconds, satisfy photo_check(x, y) The method then automatically performs the aforementioned steps: Requirements Acquisition and Formalization (S310, S320): The above FRETISH statements are acquired and automatically parsed and converted by the FRET tool into the corresponding PCTL probabilistic time-series logic formulas and variable mapping relationships.

[0050] Run system checks (S330): The system checks whether the variables mode1, trigger, x, y, and the function photo_check have been declared in the definition file (dataflow.yml) of the target dataflow framework (such as DORA).

[0051] Monitoring operator node generation and integration (S340): After verification, the corresponding monitoring operator node is automatically generated, and the data flow definition file is modified so that the node can obtain the four variables mode1, trigger, x, and y as its input.

[0052] During system operation, the generated monitoring nodes continuously monitor the four input variables based on the variable mapping relationship. When the value of any variable (such as trigger) changes (i.e., it differs from the previous sampled value), the monitor generated by this specific monitoring requirement will be triggered immediately and perform a compliance check on the associated PCTL formula. Once the monitor detects that the condition check result is not true, it will pass this violation event to the corresponding violation handling function and execute the user-defined response strategy.

[0053] This example fully demonstrates the entire process of starting from a specific natural language security requirement, automatically generating a deployable monitoring node using the method described in this application, and efficiently and accurately triggering monitoring logic based on variable changes at runtime.

[0054] The following two specific application scenarios illustrate the detailed implementation process of this method.

[0055] Example 1: Monitoring the range of motion commands during the execution of robotic arm movements Application scenario: When the control module sends motion commands to the robotic arm, it is necessary to detect in real time whether the commands exceed the preset range or are at a singular point while the robotic arm is powered on and enabled.

[0056] Implementation steps: Input requirements: In the requirements file named test.txt, enter the following FRETISH structured monitoring requirements: ONLY IN power, AND UPON enable, The system SHALL with probability>=1, satisfy move_instruction_check(linear_move, joint_move, end_move).

[0057] This requirement states that the system must satisfy the move_instruction_check function's check result for the three motion instruction variables with 100% probability, only if power is true and the enable condition is met.

[0058] Execution generation and integration: Execute the command `. / monitor.sh dataflow.yml` in the script directory, where `dataflow.yml` is the original data flow framework definition file for the target system. This script automatically executes the aforementioned S310-S340 full process.

[0059] Result generated: After the process is executed, the target data flow definition file is automatically modified. For example... Figure 6 As shown, in the modified dataflow.yml file, a monitoring operator node named "monitor" is automatically added, and its inputs are explicitly defined as the variables power, enable, linear_move, joint_move, and end_move from the specified topic. This confirms the method's ability to automatically modify the dataflow definition file to add a monitoring node interface.

[0060] Start the system: Start the original robotic arm control system and execute the command `dora run dataflow.yml`. The generated monitoring node has been automatically integrated and is running as part of the data flow graph.

[0061] Test and verification: Input test data: power=True, enable equals False for the first 5 cycles and True for the last 6 cycles. A total of 11 sampling cycles are used. No violation detection is triggered in the 5th cycle before the monitoring node. After the power and enable conditions are met in the next 6 cycles, the three inputs linear_move, joint_move, and end_move are fed into the move_instruction_check function for inspection.

[0062] The log output is as follows: Variable 'linear_move' changed =========================================================== PCTL check time: 2026-03-14 07:31:50.535 =========================================================== Check for changes in the variables: {'power', 'enable', 'linear_move'} Current variable values: {'power': True, 'enable': True, 'linear_move':{"cmdName":"joint_move","relFlag":0,"jointPosition":[0,90.5,90.5,0,90.5,0],"speed":20.5,"accel":20.5,"tol":0, "executing_line_id":0}} Expression [0] is triggered by a change in the dependent variable: depends on {'power', 'enable', 'linear_move'}, changes to {'power', 'enable', 'linear_move'}. Check 1 relevant expression: If the expression is true, the following will be displayed: The expression [0] is satisfied; if it is not satisfied, the following will be displayed: PCTL violation - expression [0].

[0063] Formula: P>=1.0 [ G ((power&enable) ->(move_instruction_check( linear_move, joint_move, end_move))) ] Prerequisite: None = True Conclusion: move_instruction_check(linear_move, joint_move, end_move) PCTL Summary: 1 / 1 of the expressions satisfy - Index [0] Example 2: Calibration plate presence detection during camera vision calibration process Application scenario: When performing visual calibration, the end effector camera of a robotic arm is required to detect the presence of a calibration plate in the captured image while the camera is taking a picture.

[0064] Input requirements: Enter the following FRETISH requirements in test.txt: ONLY IN calibration, The system SHALL with probability>= 1, satisfy photo_check(image).

[0065] Execute the script to start the original system. The `dora run camera.yml` function, specifically the `photo_check` function, calls the camera's OpenCV library to detect the presence of a calibration board in the image.

[0066] In summary, the automatic generation method for robot runtime monitoring nodes proposed in the embodiments of this application firstly describes the requirements using structured natural language (such as Fresh) and automatically parses and converts them into formal probabilistic temporal logic (PCTL) formulas according to their syntax, thus constructing an automated and unambiguous conversion path from natural language to a formal model, solving the problem of difficult formal conversion of requirements. Secondly, by verifying the existence of variables in the target data flow framework before generation and generating monitoring nodes that can run in this framework, the monitoring logic is decoupled from specific middleware (such as ROS), making the generated nodes platform-portable and solving the problem of strong coupling between monitoring implementation and specific platform frameworks. Thirdly, by configuring an event-driven evaluation mechanism based on variable mapping for the generated nodes (triggering specific formula judgments only when related variables are updated) and generating nodes for a zero-copy data flow framework, the execution path of the monitor is determined and the execution time is short and controllable, thus solving the problem of difficulty in guaranteeing real-time performance of generated code. The above technical features work together to form a fully automatic generation scheme from unambiguous requirements to portable, high-performance monitoring nodes, achieving significant technical progress.

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

[0068] Although the subject matter described herein is provided in the general context of execution on a computer system in conjunction with an operating system and applications, those skilled in the art will recognize that other implementations can also be executed in conjunction with other types of program modules. Generally, program modules include routines, programs, components, data structures, and other types of structures that perform specific tasks or implement specific abstract data types. Those skilled in the art will understand that the subject matter described herein can be practiced using other computer system configurations, including handheld devices, multiprocessor systems, microprocessor-based or programmable consumer electronics, minicomputers, mainframes, etc., and can also be used in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In a distributed computing environment, program modules may reside on both local and remote memory storage devices.

[0069] Those skilled in the art will recognize that the units and method steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0070] It should be understood that the specific embodiments described above are merely illustrative or explanatory of the principles of this application and do not constitute a limitation thereof. Therefore, any modifications, equivalent substitutions, improvements, etc., made without departing from the spirit and scope of this application should be included within the protection scope of this application. Furthermore, the appended claims are intended to cover all variations and modifications falling within the scope and boundaries of the appended claims, or equivalent forms of such scope and boundaries.

Claims

1. A method for automatically generating monitoring nodes during robot operation, characterized in that, include: Obtain monitoring requirements described in structured natural language; The structured natural language monitoring requirements are parsed according to their grammatical structure and automatically converted into formalized probabilistic temporal logic formulas and the mapping relationships of variables in the formulas; Based on the mapping relationship of the variables, verify whether the variables exist in the target data flow framework; Based on the verified probabilistic temporal logic formula and the mapping relationship of the variables, a monitoring node that can run in the data flow framework is automatically generated. The monitoring node is configured to listen for updates of the corresponding variables according to the mapping relationship of the variables when the data flow framework is running, and trigger a conformity judgment on the probabilistic temporal logic formula associated with any variable only when any variable is updated.

2. The method according to claim 1, characterized in that: The structured natural language is the FRETISH language with a predefined syntax structure. The statements used to describe monitoring requirements include six fields: scope, condition, component, probability, timing, and response.

3. The method according to claim 1, characterized in that: The formalized probabilistic temporal logic formula is a probabilistic computation tree logic formula; Furthermore, the mapping relationship of the variables is recorded in a separate mapping file.

4. The method according to claim 1, characterized in that, The verification of whether the variable exists in the target data flow framework includes: Parse the definition file of the target data flow framework and check whether the variables in the mapping relationship of the variables are declared in the definition file.

5. The method according to claim 1, characterized in that, The process of parsing the structured natural language monitoring requirements according to their grammatical structure and automatically converting them into formalized probabilistic temporal logic formulas includes: When the monitoring requirement includes a time constraint, the time constraint is converted into a time sequence operator in the probabilistic time sequence logic formula.

6. The method according to claim 5, characterized in that, The process of parsing the structured natural language monitoring requirements according to their grammatical structure and automatically converting them into formalized probabilistic temporal logic formulas includes: When the monitoring requirement includes the persisted(n, condition) operator, the persisted(n, condition) operator is converted, wherein the persisted(n, condition) operator is used to indicate that the condition must be true within n consecutive time units.

7. The method according to claim 1, characterized in that, The monitoring node includes a variable receiving module, a monitor detection module, and a violation handling module, wherein: The variable receiving module is used to receive data streams from the data stream framework and parse and record the updates of the variables; The monitoring detection module maintains a variable-formula mapping table to record the mapping relationship between variables and the probability time-series logic formulas, and based on the mapping relationship, it realizes that when a variable is updated, only the conformity judgment of the formula associated with the variable is triggered. The violation handling module is used to execute a predetermined response strategy when the compliance judgment result is non-compliance, wherein the response strategy supports user-defined configuration.

8. The method according to claim 1, characterized in that: The data flow framework is a zero-copy data flow framework.

9. The method according to claim 1, characterized in that, The method further includes: The generated monitoring nodes and their configuration files are packaged, and the packaged monitoring nodes are registered to the definition of the target data flow framework by running the installation script.

10. The method according to claim 9, characterized in that: The installation script is configured to automatically modify the definition file of the target data flow framework to add input / output interface declarations for the monitoring node.

Images