Workflow generation methods, devices, systems, media, and program products

Abstract

This application discloses a workflow generation method, apparatus, system, medium, and program product. The method includes: receiving a user's behavior tree construction operation on a graphical user interface, the construction operation including adding behavior tree nodes, each behavior tree node including a first iterator node, the first iterator node including an input adapted to receive a first iterative item list and a first work link, the first iterative item list including a plurality of first iterative items and the execution order of each first iterative item; responding to the behavior tree construction operation, generating a behavior tree containing the first iterator node; parsing the behavior tree to generate a workflow; wherein the workflow instructs each first iterative item to execute a first work link based on its respective execution order in the first iterative item list. The iterator node, which implements iteration functionality, facilitates the logical control of the workflow and can also have a nested structure, enriching the control functionality.

Description

Technical Field

[0001] This application relates to the field of industrial technology, and in particular to a workflow generation method, apparatus, system, computer-readable storage medium, and computer program product. Background Technology

[0002] A workflow can be simply defined as a description of a series of operational processes. Workflows are widely used in fields such as automation systems, artificial intelligence, and robotics. For example, the workflow of a product sorting line in an automation system can be simply described as starting, taking pictures, sorting, and moving the products to the target location. In the field of artificial intelligence, the model deployment workflow can be described as data collection, data annotation, model training, and model deployment.

[0003] Currently, these workflows are only described in text. If users want to execute such workflows, they need to follow the text descriptions and may use multiple engineering tools that are almost unrelated to each other, providing completely different user operations. This is not only a challenge for users but also significantly increases costs, reduces efficiency, and limits flexibility due to long development cycles. For example, in the field of artificial intelligence, users need to use a tool for data collection, manually or using other tools for data annotation, write Python scripts for model training, and also need deployment tools for deployment.

[0004] Therefore, those skilled in the art are also working to find other workflow solutions. Summary of the Invention

[0005] This application provides a workflow generation method, system, computer-readable storage medium, and computer program product.

[0006] In a first aspect, embodiments of the present invention propose a workflow generation method. This method includes:

[0007] The system receives a behavior tree construction operation performed by a user on a graphical user interface. The construction operation includes an operation to add behavior tree nodes. The behavior tree nodes include a first iterator node. The first iterator node includes an input adapted to receive a first iteration item list and a first working link. The first iteration item list includes a plurality of first iteration items and the execution order of each first iteration item.

[0008] In response to the behavior tree construction operation, a behavior tree containing the first iterator node is generated;

[0009] The behavior tree is parsed to generate a workflow, wherein the workflow instructs each first iteration project to execute the first workflow based on its respective execution order in the first iteration project list.

[0010] Therefore, the embodiments of the present invention implement an iterative workflow by using iterator nodes with iterative capabilities, thereby enriching the control capabilities.

[0011] In one implementation, the first workflow includes function block nodes, which are used to implement business operations in the workflow.

[0012] As can be seen, by introducing functional block nodes into the work chain contained in the iterator node, iterative processing can be performed on the functional block nodes, thereby speeding up the workflow processing.

[0013] In one implementation, the first working link includes a second iterator node, the second iterator node including an input adapted to receive a second iterative item list and the second working link, the second iterative item list including a plurality of second iterative items and the execution order of each second iterative item;

[0014] The workflow further indicates that during each execution of the first workflow, each second iteration project executes the second workflow based on its respective execution order in the second iteration project list.

[0015] Therefore, by introducing other iterator nodes into the work chain contained in the iterator node, nested iterations can be achieved, enriching the workflow processing logic.

[0016] In one embodiment, the first working link includes a synthesizer node, the synthesizer node including a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple working links arranged between the start block and the end block.

[0017] The workflow also indicates the determination of a target workflow from the multiple workflows based on the type of the synthesizer node.

[0018] Therefore, by introducing synthesizer nodes with multiple capabilities into the work chain contained in the iterator node, complex control logic can be implemented, enriching the workflow processing logic.

[0019] In one implementation, it further includes:

[0020] The workflow is deployed to a runtime of a work unit containing the plurality of first iteration projects, such that the plurality of first iteration projects in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device.

[0021] It is evident that workflow control in the OT domain can be achieved by deploying workflows to the runtime of OT devices.

[0022] In one implementation, it includes:

[0023] The first iterator node is selected based on the user's selection action on the graphical user interface containing the node library.

[0024] Therefore, by selecting the node library, iterator nodes can be selected intuitively.

[0025] In one implementation, the first iterator node includes a first display area adapted to display the type of the first iterator node.

[0026] In one implementation, the first iterator node further includes a second display area adapted to display a label for the first iteration project currently executing the first workflow.

[0027] As can be seen, iterator nodes can also display various types of information, making it easier for users to understand the execution status of the iteration.

[0028] Secondly, embodiments of the present invention provide a workflow generation apparatus. This apparatus includes:

[0029] The receiving module is configured to receive a behavior tree construction operation performed by a user on a graphical user interface, wherein the construction operation includes an operation of adding behavior tree nodes, the behavior tree nodes include a first iterator node, the first iterator node includes an input end adapted to receive a first iteration item list and a first working link, the first iteration item list includes a plurality of first iteration items and the execution order of each first iteration item;

[0030] A behavior tree generation module is configured to generate a behavior tree containing the first iterator node in response to a behavior tree construction operation;

[0031] A workflow generation module is configured to parse the behavior tree to obtain a workflow; wherein the workflow instructs each first iteration item to execute the first workflow based on its respective execution order in the first iteration item list.

[0032] Therefore, the embodiments of the present invention implement an iterative workflow by using iterator nodes with iterative capabilities, thereby enriching the control capabilities.

[0033] In one implementation, the first workflow includes function block nodes, which are used to implement business operations in the workflow.

[0034] As can be seen, by introducing functional block nodes into the work chain contained in the iterator node, iterative processing can be performed on the functional block nodes, thereby speeding up the workflow processing.

[0035] In one implementation, the first working link includes a second iterator node, the second iterator node including an input adapted to receive a second iterative item list and the second working link, the second iterative item list including a plurality of second iterative items and the execution order of each second iterative item;

[0036] The workflow further indicates that during the execution of the first work link, each second iteration project executes the second work link based on its respective execution order in the second iteration project list.

[0037] Therefore, by introducing other iterator nodes into the work chain contained in the iterator node, nested iterations can be achieved, enriching the workflow processing logic.

[0038] In one embodiment, the work link includes a synthesizer node, the synthesizer node including a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple work links arranged between the start block and the end block;

[0039] The workflow also indicates the determination of a target workflow from the multiple workflows based on the type of the synthesizer node.

[0040] Therefore, by introducing synthesizer nodes with multiple capabilities into the work chain contained in the iterator node, complex control logic can be implemented, enriching the workflow processing logic.

[0041] In one implementation, a deployment module is further included, configured to deploy the workflow to a runtime of a work unit containing the plurality of first iteration items, such that the plurality of first iteration items in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device.

[0042] It is evident that workflow control in the OT domain can be achieved by deploying workflows to the runtime of OT devices.

[0043] Thirdly, embodiments of the present invention provide a workflow control system, comprising: at least one memory configured to store computer-readable code; and at least one processor configured to invoke the computer-readable code to execute steps in any of the workflow generation methods described above.

[0044] Fourthly, embodiments of the present invention provide a computer-readable medium, characterized in that the computer-readable medium stores computer-readable instructions, which, when executed by a processor, cause the processor to perform the steps in any of the workflow generation methods described above.

[0045] Fifthly, embodiments of the present invention provide a computer program product tangibly stored on a computer-readable medium and comprising computer-readable instructions that, when executed, cause at least one processor to perform steps in the workflow generation method as described above. Attached Figure Description

[0046] Figure 1A An exemplary flowchart illustrating the workflow creation method provided in various embodiments of this application.

[0047] Figure 1B This is an example diagram of a resource knowledge graph in one of the examples of this application.

[0048] Figure 1C This is an example diagram illustrating how functional block nodes are associated with each resource node in this application.

[0049] Figure 2A This is a schematic diagram of a behavior tree created in one example of this application.

[0050] Figures 2B to 2S These are schematic diagrams of a partial behavior tree created in one example of this application.

[0051] Figure 3 An exemplary structural diagram of a workflow creation system provided in one embodiment of this application.

[0052] Figures 4A-4D A schematic diagram of the workflow creation system provided in various embodiments of this application.

[0053] Figure 4E This is an application scenario diagram of the OT domain low-code development platform 100 in the field of industrial automation.

[0054] Figure 5 A schematic diagram of the hardware implementation of the workflow creation system provided in the embodiments of this application.

[0055] Figure 6 This is an exemplary flowchart of the workflow control method provided in various embodiments of this application.

[0056] Figure 7A This is a first schematic diagram of a low-code example of an FBTD logic synthesizer provided in various embodiments of this application.

[0057] Figure 7BThis is a second schematic diagram of a low-code example of an FBTD logic synthesizer provided in various embodiments of this application.

[0058] Figure 7C This is a schematic diagram of a low-code example of an FBTD logic synthesizer with a folded form, provided in various embodiments of this application.

[0059] Figure 8 An exemplary flowchart of a workflow generation method provided in an embodiment of this application.

[0060] Figure 9 A schematic diagram illustrating a low-code example of an iterator provided in an embodiment of this application.

[0061] Figure 10 This is an exemplary structural diagram of the workflow generation apparatus provided in various embodiments of this application.

[0062] The reference numerals in the attached figures are as follows:

[0063]

[0064] Detailed Implementation

[0065] The subject matter described herein will now be discussed with reference to exemplary embodiments. It should be understood that these embodiments are discussed merely to enable those skilled in the art to better understand and implement the subject matter described herein, and are not intended to limit the scope, applicability, or examples set forth in the claims. The function and arrangement of the elements discussed may be changed without departing from the scope of the embodiments of this application. Various processes or components may be omitted, substituted, or added as needed in the various examples. For example, the described methods may be performed in a different order than described, and steps may be added, omitted, or combined. Furthermore, features described in some examples may be combined in other examples.

[0066] As used herein, the term "comprising" and its variations are open terms meaning "including but not limited to". The term "based on" means "at least partially based on". The terms "one embodiment" and "an embodiment" mean "at least one embodiment". The term "another embodiment" means "at least one other embodiment". The terms "first", "second", etc., may refer to different or the same objects. Other definitions, whether explicit or implicit, may be included below. Unless explicitly indicated by the context, the definition of a term shall remain consistent throughout the specification.

[0067] The embodiments of this application will now be described in detail with reference to the accompanying drawings.

[0068] Figure 1A An exemplary flowchart of a workflow creation method provided in an embodiment of this application is shown. Figure 1A As shown, the method may include the following steps:

[0069] Step S11: Receive the user's behavior tree construction operation based on pre-set behavior tree nodes on the graphical user interface.

[0070] In this embodiment, a behavior tree is used to represent a workflow, which defines the operations to be performed by a work unit. For example, it can represent a distributed process within a work unit. In specific implementations, the workflow can be further subdivided into main workflows and sub-workflows. The main workflow is used to define the start, end, and other flow controls that trigger the entire work unit's process. The main workflow is the entry point for the entire process and links to at least one sub-workflow. Sub-workflows are typically the main workflows, and each sub-workflow corresponds to a sub-process used to implement specific business operations.

[0071] In this context, a workcell can be a combination of resources such as systems or devices capable of implementing a relatively complete and independent control process and operation. In this embodiment, creating workflows based on workcells is more in line with the characteristics of industrial control, improving the integration level of development and reducing its complexity. For example, in the field of industrial technology, workcells can be defined according to actual industrial scenarios. For instance, a workcell can be defined as one process corresponding to one operation, or a workstation within a process can be defined as one workcell, or a workstation within a workstation can be defined as one workcell, etc. Different workcells have different process flows.

[0072] Behavior trees are a formal graphical modeling approach. They are widely used in various types of artificial intelligence decision-making. Since most logic is predefined according to rules, the judgment of behavior resembles a tree with many branches. The behaviors in a behavior tree are the actual behavioral logic to be executed, located at the leaf nodes. Behavior trees allow for the explicit representation of the relevant requirements of software integration systems using clearly defined symbols. The structure of a behavior tree is organized in a tree-like manner, with each node having a corresponding node type and carrying different functions in conjunction with relevant parameters. A component editor can be used to provide users with an intuitive and visual behavior tree editor. Using the behavior tree editor, users can quickly edit behavior trees. For example, after launching the behavior tree editor, users can create a new behavior tree, select behavior tree node types, and edit the attributes of the behavior tree nodes that make up the behavior tree.

[0073] In this embodiment, the behavior tree nodes may include flow control nodes and function block nodes, etc. These will be described in detail below.

[0074] I. Flow Control Node

[0075] Flow control nodes are used to implement logical control within a workflow, and they are typically independent of specific business operations within a work unit. Through flow control nodes, users can create various workflows according to their needs.

[0076] In practical implementation, flow control nodes may include: a master control node, a compositor node (also called an aggregator node or logic control node), and condition nodes. Alternatively, flow control nodes may include one or any combination of a master control node, a compositor node, and condition nodes. These will be briefly explained below.

[0077] 1. Master control node

[0078] The main control node may include some or all of the following: Start node, End node, Goto node, Anchor node, Stop node, and Abort node.

[0079] In this embodiment, the main control nodes are not standard behavior tree elements, but they can be used to control the main flow of the workflow and can be linked to the workflow's state machine. The start node is mandatory, and one of the end or transition nodes can also be mandatory. The main control nodes are primarily used to define the start and end of the workflow. In addition, other element nodes can control the state machine (e.g., abort and stop) or mark critical process steps that can be jumped to (e.g., critical nodes).

[0080] 2. Synthesizer Node

[0081] Synthesizer nodes are used to implement logical control in the workflow. Synthesizer nodes may include some or all of the following: Sequence (Se) nodes, Reactive Sequence (RSe) nodes, Parallel (Pa) nodes, In-Process Quality Control (IPQ) (N-Process QC) nodes, Priority (Fallback) (Pr) nodes, Reactive Priority (Fallback) (RPr) nodes, If-Then-Else (ITE) nodes, and Switch (Sw) nodes.

[0082] Synthesizer nodes define how branches are executed in the behavior tree, used to implement branch logic control in workflows. For example, a typical synthesizer node is briefly described below:

[0083] 1) Sequential node: This node can have one or more child nodes, and will trigger routing to each child node in sequence according to the workflow order.

[0084] 2) Reactive Sequential Nodes function the same as Sequential Nodes, but continuously check the triggering conditions.

[0085] 3) Parallel nodes: These nodes can have one or more child nodes, which are started sequentially from top to bottom and all child nodes are executed simultaneously in multiple processes or threads.

[0086] 4) In-process quality control nodes are where quality engineers conduct quality inspections on a portion of the process steps. If the inspection fails, an exception handling procedure is executed; if it succeeds, the process continues.

[0087] 5) Priority nodes: each sub-branch is executed in sequence according to priority. If the previous execution fails, the next one is executed. If any branch is executed successfully, the process is complete.

[0088] 6) Reactive priority node: Functions the same as priority node, but continuously checks the triggering conditions.

[0089] 7) Is it a conditional node? Check the trigger expression. If it is true, execute the true branch; if it is false, execute the false branch.

[0090] 8) Multi-branch selection node: Check the trigger expression and execute different branches according to different conditions. If none of the conditions are met, execute the default branch.

[0091] Typically, sequential nodes and parallel nodes drive most of the logic in a workflow.

[0092] 3. Condition (C) node

[0093] Condition nodes are typically the basic logical elements in a behavior tree that examine expressions, perform conditional judgments, and return a result. They return success or failure based on whether the condition is true or false. Condition nodes never return a running status.

[0094] In other implementations, condition nodes may also be included within function block nodes. Alternatively, condition nodes may be a separate type of node.

[0095] II. Function Block (FB) Node

[0096] Function block nodes are used to execute commands and implement business operations in the workflow. Normally, if the operation completes correctly, it returns success; if the operation fails, it returns failure. When an operation is in progress, it returns running.

[0097] In this embodiment, the functional block node includes logical nodes, and may also include some specific types of functional block nodes, such as some or all of manual nodes, dynamic nodes, delayed nodes, and empty nodes. Dynamic nodes are used to dynamically inject node instances at runtime. Manual nodes represent manual steps, stopping at the current node before obtaining a confirmation signal and exiting after obtaining the confirmation signal. Delayed nodes represent exiting the current node after a specified delay. Empty nodes represent no operation; they are placeholders and can be replaced by any functional block node. Each logical node may correspond to an operation template, and each operation template predefines at least one type of resource (such as collaborative robot class or PLC class, etc.) that can perform operations. For example, the operations may include actions, methods, or skills.

[0098] In practice, each operation template can consist of an interface and an implementation. The implementation can be an application (e.g., a containerized application) containing functional code and runtime dependencies. This application can run independently and is exposed through a specific network communication interface. The interface can be a logical node presented as a graphical element; that is, like other behavior tree nodes, it can be dragged, dropped, connected, and configured in a graphical user interface. In practice, each logical node can have a parameter panel for configuring its parameters, such as input and output parameters. Of course, these input and output parameters can also be pre-set with default values.

[0099] Each logical node can be configured and executed independently. When executing a logical node in the behavior tree, the input configured by the user for the logical node is read and transmitted to the implementation part of the operation template, i.e., the corresponding application. After completing a specific operation, such as model transformation, the operation result, such as the transformed model, is converted back to the output of the logical node.

[0100] In this embodiment, the interface and implementation parts of each operation template can be stored separately. For example, the node library may only store the interface part, i.e., the logical node, while its implementation part may be stored in a node service module, which can be referred to as the runtime in this embodiment. The node service module may be located on a server or locally.

[0101] Optionally, the aforementioned logical nodes follow an information model for runtime interaction with the main controller. This standardizes communication between the OT domain workflow and the main controllers of various OT devices.

[0102] Furthermore, considering that the business operations corresponding to a functional block node may be executed by different entities, such as a specific physical device, a person, or other virtualized resources, for the sake of convenience, this article refers to these physical devices, personnel, and virtualized resources collectively as resources. These resources usually refer to the resources on-site that can execute workflows as the various operating entities.

[0103] In practical implementation, the resource that serves as the main body of operation execution can be configured as a regular configuration parameter of the functional block node when creating the behavior tree; alternatively, the resource that serves as the main body of operation execution can be configured for the functional block node when it is created, so that resource configuration for the required functional block node is not required when creating the behavior tree. Alternatively, for ease of resource management, these resources can also be represented in the form of resource nodes, and these resource nodes can be stored in the form of a resource knowledge graph. The resource knowledge graph includes: each resource node, and connections representing the relationships between resource nodes. For example, Figure 1B The example diagram shows a resource knowledge graph from one example example. Figure 1B As shown, this resource knowledge graph is a factory resource knowledge graph, describing the actual system configuration of a factory. The factory (F) node has an industrial control computer (IPC) node, which in turn has a cooperative robot (CR) node, a PLC node, and a barcode scanner (BCS) node. Specifically, the cooperative robot (CR) node has a clamping jaw (CJ) node, a torque wrench (TW) node, and a camera (CA) node; the PLC node has a button (B) node and an LED alarm light node. Of course, in some applications, there may be more than one type of device, such as a cooperative robot. These devices can be distinguished by labels or model numbers, which will not be elaborated upon here.

[0104] Each functional block node can be associated with a resource node, allowing the functional block node to be instantiated as an operation of the corresponding resource. For example, a logical node can be instantiated as an operation of the corresponding device by associating it with a device resource node. In practice, a resource header can be set for each functional block node, and the resource associated with the functional block node will be displayed in the resource header.

[0105] The specific association process can be implemented in several different ways. For example, each resource node can be pre-associated with a corresponding functional block node. This way, when creating the behavior tree, the associated functional block node can be directly retrieved without requiring temporary configuration. For example, Figure 1C The example diagram shows how functional block nodes are associated with each resource node. Figure 1C As shown, for Figure 1B The resources shown in the resource knowledge graph are associated with corresponding functional block nodes. Among them, the Industrial Control Computer (IPC) node is associated with the Press Button (PB) node and the Display Dialog Box on Screen (DDB) node; the Cooperative Robot (CR) node is associated with the Linear Move (LM) node and the Shutdown Mobile (SM) node; the PLC node is associated with the Read I / O (RIO) node and the Write I / O (WIO) node; the Bar Code Scanner (BCS) node is associated with the Scan Bar Code (SBC) node; the Clamping Jaw (CJ) node is associated with the Open (O) node and the Grab (Gr) node; the Torque Wrench (TW) node is associated with the Twist (T) node; and the Camera (CA) node is associated with the Register (R) node, the Calibration (Cb) node, and the Take (TP) node. The Photo node and the Object Recognition (OR) node are associated with the Button (B) node and the Press Button (PB) node. The LED Alarm Light node is associated with the Switch On (SO) node and the Switch Off (SF) node.

[0106] Alternatively, instead of pre-associating resource nodes with function block nodes, the corresponding resource nodes can be associated with the required function block nodes when creating the behavior tree.

[0107] Alternatively, functional block nodes that are pre-associated with resource nodes (referred to as dedicated functional block nodes) and functional block nodes that are not associated with resource nodes (referred to as general functional block nodes) can coexist. This is because although general functional block nodes are not associated with on-site resources, they do not affect the simulation of the workflow corresponding to the behavior tree of that functional block node. For example, a collaborative robot may not have been procured yet. To verify its feasibility, the corresponding general functional block node can be used for pre-simulation. Once feasibility is confirmed, procurement can then proceed.

[0108] In addition, this embodiment may further include the following decorator nodes:

[0109] III. Decorator Node

[0110] Decorator nodes are primarily used to decorate function block nodes driven by synthesizer nodes. For example, they can be used to determine whether a branch in the behavior tree or even a single node can be executed. They can include some or all of the following: Repeat (Rp), Retry (Rt), One-Shot (OS), Timeout (TO), Timer (Tm), Inverter (Iv), Force Run (FR), Force OK (FO), Force Failed (FF), and Guard (G). A brief description of some decorator nodes follows:

[0111] 1) Invert a node, which can have one child node, used to invert the child node. Returns success if the child node fails; returns failure if the child node succeeds.

[0112] 2) Forced success node, which can have one child node (such as a function block node), will always return success regardless of whether its child node succeeds or not.

[0113] 3) Force failure node, which can have one child node (such as a function block node), will always return failure regardless of whether its child node succeeds or not.

[0114] 4) Repeating nodes, which can have one child node (such as a function block node) and can repeat their child node a fixed number of times.

[0115] 5) A retry node can have one child node (such as a function block node). It can trigger its child node up to N times. If its child node returns failure, it retryes and decrements the count by one. When the retry count reaches zero, it returns success. If the child node returns success, it interrupts the loop and also returns success. Here, N is a positive integer.

[0116] 6) One-time node, which can have one child node, means that its child node is executed only once in the workflow and will not be executed again before the workflow is restarted.

[0117] 7) Timeout node, which can have one child node, is used to time the execution time of its child nodes (such as function block nodes). When the specified time is exceeded, the execution will stop (even if it has not been completed).

[0118] 8) Timer node, which can have one child node, executes its child node (such as a function block node) after a specified time has elapsed.

[0119] 9) Force the running node, which can have one child node. Regardless of whether its child node (such as a function block node) has finished executing, it will be forced to return to the running state.

[0120] 10) A monitoring node, which can have at least one child node, is used to monitor the status of all its child nodes. An error is reported when any child node encounters a problem. Normalcy is only restored when all child nodes are functioning correctly.

[0121] In other implementations, decorator nodes may also be included within flow control nodes. That is, flow control nodes may include all or some of the main control node, synthesizer node, and decorator node.

[0122] In this embodiment, each behavior tree node can be listed as an icon on the graphical user interface. Users can select or drag icons to add them to the canvas to determine the nodes needed to create a workflow. Furthermore, necessary parameter configurations, such as resource configurations and / or input / output parameter configurations, can be performed on the nodes. If a work unit needs to perform more than one operation (i.e., the operation defined in the required workflow is not limited to one), the behavior tree corresponding to that workflow can include multiple functional block nodes. According to the order and interrelationship of the operations, corresponding flow control nodes can be set. The behavior tree of the corresponding workflow is finally generated by connecting the dragged nodes accordingly. That is, the behavior tree construction operation includes adding and connecting behavior tree nodes. Further, it may also include associating resources with the added functional block nodes. In addition, it may also include configuring the input / output parameters of the behavior tree nodes.

[0123] Step S12: In response to the behavior tree construction operation, a behavior tree corresponding to a workflow is generated, and the logical nodes in the behavior tree are instantiated as operations of the corresponding device.

[0124] In this embodiment, in response to the behavior tree construction operation, each behavior tree node can be instantiated, and connections between the instantiated behavior tree nodes can be established. For example, by performing this step, the added logical nodes can be instantiated as operations of the corresponding devices. Then, based on the connections between the instantiated behavior tree nodes, a behavior tree corresponding to a workflow is generated.

[0125] In practical implementation, the aforementioned behavior tree nodes can be stored in a node library. Furthermore, for similar application scenarios, to avoid wasting manpower and time on repeatedly building behavior trees, behavior trees (or uninstantiated behavior tree frameworks) that users have already built, preferably debugged, or successfully run, corresponding workflows or sub-workflows, should be stored as a workflow node or sub-workflow node. Accordingly, the node library can further include workflow (WF) nodes and sub-workflow (SWF) nodes. When a user needs to build a similar behavior tree or a behavior tree that includes that workflow or sub-workflow, they can select the corresponding workflow node or sub-workflow node and configure it as necessary to obtain the behavior tree used to implement the required workflow.

[0126] Figure 2A The diagram shows a behavior tree for constructing a work unit in a quality inspection production line, as illustrated in an example. Figures 2B to 2S The diagrams show partial behavior trees constructed in an example.

[0127] In addition, in other embodiments, this embodiment may further include the following step S13, as shown by the dashed line portion in FIG1.

[0128] Step S13: Parse the behavior tree and deploy the workflow corresponding to the behavior tree to the runtime of the corresponding work unit so that each resource in the work unit performs operations according to the workflow.

[0129] In a practical implementation, the work unit may have a main controller, and the runtime may reside on the main controller of the work unit. Accordingly, the device resources in the resources can be connected to the main controller, and the main controller controls the connected device resources to perform corresponding operations according to the runtime workflow; the human resources in the resources can directly perform corresponding operations according to the runtime workflow prompts.

[0130] In this embodiment, the behavior tree can be stored in a Markup Language such as XML (Extensible Markup Language) and can be validated by an XML Schema (XSD) prototype to verify that the XML format of the behavior tree is correct. After parsing the behavior tree, a workflow represented in the form of a "node link assembly" can be obtained. Then, the workflow can be compiled and downloaded to the runtime of the main controller of the corresponding work unit.

[0131] Furthermore, according to Gartner's definition, the OT domain typically refers to Operational Technology (OT), which combines hardware and software to detect or trigger changes or events in processes within an enterprise by directly monitoring and / or controlling physical devices (called OT devices). OT utilizes computers to monitor or alter the physical state of systems such as Industrial Control Systems (ICS). ICS are computer-based facilities, systems, and devices used to remotely monitor and / or control critical industrial processes, fulfilling physical functions. The term "OT" is used to distinguish industrial control systems from traditional Information Technology (IT) systems in terms of both technical implementation and functionality.

[0132] Currently, there are numerous IT low-code development tools and platforms on the market. Some of these tools are designed for IoT use cases and are geared towards experienced IT engineers, while OT engineers and junior IT engineers may find their paradigms difficult to understand. Other tools are more suitable for IT domain low-code development and are not well-suited for the OT domain.

[0133] The workflow creation method described in this embodiment can be used in this OT domain as a low-code development method for the OT domain. Specifically, Figure 1A The workflow creation method shown can be implemented in an OT domain, such as an OT domain low-code development platform. Accordingly, the workflow can be an OT domain workflow; the work unit can be a work unit within the OT domain; and the device can be an OT device. Here, OT devices may include, but are not limited to: Internet of Things (IoT) devices, Programmable Logic Controllers (PLCs), robots, manual processes, and Industrial Personal Computers (IPCs).

[0134] Furthermore, in this embodiment of the application, considering that the convergence of IT and OT domains is becoming increasingly important in the process of enterprise digital transformation, a pressing issue in order to integrate IT and OT domains into an ITOT system is how enterprises can collect OT domain data and control OT domain processes in a way that is easy to understand, rather than using IT domain programming.

[0135] The workflow creation method described in this embodiment can be used in this ITOT system as a low-code development method for the OT domain that can be integrated with the IT domain. Similarly, Figure 1A The workflow creation method shown can be implemented in an OT domain, such as an OT domain low-code development platform. Accordingly, the workflow can be an OT domain workflow; the work unit can be a work unit within the OT domain.

[0136] In addition, to achieve convergence of IT and OT domains, it is possible to... Figure 1A Based on the workflow creation method shown, the method further includes: generating a microservice based on the behavior tree, so that an IT device can trigger the runtime of the main controller of the work unit to execute the OT domain workflow by calling the microservice. Specifically, the IT device can directly call the microservice or call it through a knowledge platform.

[0137] When generating a microservice based on the behavior tree, the API of the microservice can be generated based on the behavior tree. The processing procedures in the API include various operations in the OT domain workflow. The input parameters of the API are the parameters obtained from the input port of the OT domain workflow, and the output parameters of the API are the parameters output from the output port of the OT domain workflow.

[0138] For an IT domain to be able to call microservices, it needs to be able to obtain information about the microservices. Specific implementation methods include, but are not limited to, the following two:

[0139] Method 1

[0140] In Method 1, the OT domain code developers can notify the IT domain code developers of the names and IP addresses of the generated microservices. This allows the IT domain code developers to directly incorporate the microservice information into their code during development, enabling IT devices to call the microservices. Method 1 is more suitable for scenarios with a small number of microservices.

[0141] Method 2

[0142] In Method Two, a registration and discovery mechanism can be employed. This involves registering each microservice on the knowledge platform, enabling an IT domain code development tool to allow IT devices to discover the connected microservices through the knowledge platform. Specifically, an IT domain code development tool can be used to develop code that allows IT domain devices to discover connected microservices through the knowledge platform. The device that completes the microservice registration can be an OT domain microservice generator or a third-party device. This third-party device can be considered part of the OT domain low-code development platform or implemented within the knowledge platform. Method Two is more suitable for scenarios with a large number of microservices.

[0143] In this embodiment, IT equipment may include, but is not limited to: Manufacturing Operation Management (MOM) system, Manufacturing Execution System (MES), Enterprise Resource Planning (ERP) system, Enterprise Service Bus (ERP), Product Lifecycle Management (PLM) system, etc.

[0144] In this embodiment, because the IT domain code development tool can programmatically enable IT devices to call microservices through a knowledge platform, triggering the runtime execution of the main controller of the work unit to execute the OT domain workflow, the IT domain code development platform achieves control over the OT domain process, thus realizing the integration of the IT and OT domains. Here, the microservices are automatically generated by the OT domain microservice generator based on the OT domain behavior tree. The IT domain code development tool does not need to understand the details of the OT domain workflow; it only needs to obtain the microservice's identifier (e.g., name) and IP address. IT domain developers do not need to understand OT domain devices and control processes, making it easy to implement and understand.

[0145] The applicable fields of this application include, but are not limited to: industrial automation, logistics, laboratory, marine electrical systems, smart grid, electric vehicle infrastructure, electric vehicles, building automation, smart city, water treatment, garbage recycling, and smart farm.

[0146] The workflow creation method in the embodiments of this application has been described in detail above. The workflow creation system in the embodiments of this application will now be described in detail below. The workflow creation system in the embodiments of this application can be used to implement the workflow creation method in the embodiments of this application. For details not disclosed in detail in the system embodiments of this invention, please refer to the corresponding descriptions in the method embodiments of this invention, which will not be repeated here.

[0147] Figure 3 A schematic diagram of the structure of a workflow creation system according to an embodiment of this application is shown. Figure 3 As shown, the system may include: a node library 110, a graphical interface module 120, and an editing module 130.

[0148] The node library 110 includes behavior tree nodes for constructing behavior trees. These behavior tree nodes may include flow control nodes and function block nodes. A behavior tree represents a workflow, which defines the operations to be performed by a work unit. The flow control nodes implement logical control within the workflow; the function block nodes implement business operations within the workflow. Each function block node may include logic nodes, each corresponding to an operation template. Each operation template predefines at least one type of operation that a resource, such as a device, can perform. These operations include actions, methods, or skills.

[0149] In one implementation, the resources are represented as resource nodes, and all resource nodes are stored in association as a resource knowledge graph; the resource knowledge graph includes: each resource node, and connections representing the relationships between resource nodes. Accordingly, this embodiment may further include: a resource library 150, used to store each resource in the form of a resource knowledge graph, each resource being capable of performing at least one business operation.

[0150] In one implementation, the flow control node may include some or all of the following: a main control node, a logical control node, and a condition node; the main control node may include some or all of the following: a start node, an end node, a go-to node, a critical node, a stop node, and an abort node. The logical control node includes some or all of the following: a sequence node, a reactive sequence node, a parallel node, an in-process quality control node, a priority node, a reactive priority node, a conditional decision node, and a multi-branch selection node.

[0151] In one implementation, the functional block node may further include some or all of the following: manual nodes, dynamic nodes, delayed nodes, and idle nodes.

[0152] In one implementation, the behavior tree node further includes: a decorator node, which may include some or all of the following: repeat node, retry node, one-time node, timeout node, timer node, invert node, force run node, force success node, force failure node, and monitor node.

[0153] In one embodiment, some or all of the functional block nodes in the node library 110 are respectively bound to resources that perform the business operations corresponding to the functional block nodes.

[0154] The graphical interface module 120 is configured to provide a graphical user interface (GUI) for users to construct behavior trees based on behavior tree nodes in the node library.

[0155] Each behavior tree node can be listed as an icon on the graphical user interface (GUI).

[0156] The editing module 130 is configured to generate a behavior tree corresponding to a workflow in response to the behavior tree construction operation. Logical nodes in the behavior tree are instantiated as operations corresponding to resources such as devices. Specifically, the editing module 130 may instantiate each behavior tree node in response to the behavior tree construction operation and establish connections between the instantiated behavior tree nodes; based on these connections, a behavior tree corresponding to a workflow is generated. Some or all of the instantiated functional block nodes are associated with resources that perform the corresponding business operations. For example, through this operation, a logical node is instantiated as an operation corresponding to a resource such as a device.

[0157] In this embodiment, each behavior tree node can be listed as an icon on the graphical user interface. Users can select or drag icons onto the canvas to determine the nodes needed to create a workflow. Furthermore, necessary parameters can be configured for the nodes, such as resource configuration and / or input / output parameter configuration. If a work unit needs to perform more than one operation (i.e., the operation defined in the required workflow is not limited to one), the behavior tree corresponding to that workflow can include multiple logical nodes. According to the order and interrelationships of the operations, corresponding flow control nodes can be set. By connecting the dragged nodes accordingly, the behavior tree of the corresponding workflow is finally generated.

[0158] In one implementation, the build operation may include: adding a function block node and associating resources with the added function block node.

[0159] and Figure 1A Corresponding to the method shown, the workflow creation system in this embodiment may further include: a parsing deployment module 140, which is configured to parse the behavior tree and deploy the workflow corresponding to the behavior tree to the runtime of the main controller of the corresponding work unit, so that each resource in the work unit connected to the main controller performs operations according to the workflow.

[0160] Figure 4A This application illustrates an OT domain low-code development platform 100 provided in an embodiment. This platform 100 can be used to implement... Figure 3 The workflow creation system shown.

[0161] As mentioned earlier, there is currently no low-code development tool or platform suitable for the OT domain. Figure 4A In the platform 100 shown, because operation templates for various OT devices to perform operations are predefined (which can be regarded as providing OT domain capabilities), and corresponding logical nodes are constructed based on the operation templates, and other behavior tree nodes for building OT domain workflows are set, the behavior trees for corresponding OT domain workflows can be created conveniently and quickly, realizing low-code development suitable for OT domains. Development engineers do not need to have an in-depth understanding of various OT devices to achieve OT domain development.

[0162] Specifically, such as Figure 4A As shown, the OT domain low-code development platform 100 may include:

[0163] An OT domain low-code development tool 10, which can be configured to implement Figure 3 The graphical interface module 120 and editing module 130 in the workflow creation system shown can further realize... Figure 3 The workflow creation system shown includes the parsing and deployment module 140. Figure 3 The node library 110 in the workflow creation system shown can be stored on a memory.

[0164] Furthermore, such as Figure 4B As shown, the OT domain low-code development platform 100 may further include the runtime 30 of the main controller of the aforementioned work unit. The OT domain low-code development tool 10 can deploy the OT domain workflow corresponding to the generated behavior tree to the runtime 30 of the main controller of the work unit, so that each OT device in the work unit connected to the main controller performs operations according to the OT domain workflow.

[0165] Figure 4A and Figure 4B The OT domain low-code development platform 100 shown only involves the OT domain. However, the integration of IT and OT domains has become increasingly important for enterprise digital transformation. The challenge is to enable enterprises to control OT domain processes in an easy-to-understand, non-IT programming manner. Figure 4C The OT domain low-code development platform 100 shown addresses how to control OT domain processes through the IT domain code development platform 300. For example... Figure 4C As shown, the OT domain low-code development platform 100 in Figure 4B Based on the structure shown, an OT domain microservice generator 20 can be further included, which can generate microservices 40 based on the OT domain behavior tree. In this way, the IT domain code development tool 301 can programmatically implement the execution of the OT domain workflow by having IT devices call microservices 40 through a knowledge platform 200, thereby triggering the runtime 30 of the main controller of the work unit to execute the OT domain workflow. This achieves the control of the OT domain process by the IT domain code development platform 300, that is, the integration of the IT domain and OT domain. Here, microservices 40 are automatically generated by the OT domain microservice generator 20 based on the OT domain behavior tree. The IT domain code development tool 301 does not need to understand the details of the OT domain workflow; it only needs to obtain the identifier (e.g., name) and IP address of the microservices 40. IT domain developers do not need to understand OT domain devices and control processes, making it easy to implement and understand.

[0166] For the IT domain to be able to call microservice 40, the IT domain needs to be able to obtain information about microservice 40. Figure 1A Corresponding to the method shown, it can be implemented in, but is not limited to, the following two ways:

[0167] Method 1

[0168] In Method 1, the code developers in the OT domain can notify the code developers in the IT domain of the names and IP addresses of each generated microservice 40. This allows the IT domain code developers to directly incorporate the information of each microservice 40 into their code during development, enabling IT devices to call the microservices 40. Method 1 is more suitable for scenarios with a small number of microservices.

[0169] Method 2

[0170] In Method Two, a registration and discovery mechanism can be employed. Each microservice 40 can be registered on the Knowledge Platform 200, allowing the IT domain code development tool 301 to enable IT domain devices to discover the connected microservices 40 via the Knowledge Platform 200 through code development. The device that completes the registration of the microservices 40 can be the OT domain microservice generator 20 or... Figure 4D A third-party device 50 is shown. This third-party device 50 can be considered as part of the OT domain low-code development platform 100, or implemented in the knowledge platform 200. Method two is more suitable for scenarios with a large number of microservices. By registering microservices on the knowledge platform, the invocation of microservices by IT devices is realized more effectively, strengthening the integration of the OT and IT domains.

[0171] Optionally, the OT domain microservice generator 20 can generate the API of the microservice 40 based on the OT domain behavior tree. The processing in the API can include the operation of each functional block in the OT domain workflow. The input parameters of the API are the parameters obtained by the input port of the OT domain workflow, and the output parameters of the API are the parameters output by the output port of the OT domain workflow.

[0172] An application scenario of the OT domain low-code development platform 100 provided in this application embodiment in the field of industrial automation is as follows: Figure 4E As shown. The low-code development tool 10 generates a behavior tree for the corresponding OT domain workflow under user input. This OT domain workflow defines... Figure 4E The right side shows the operations to be performed by a production line as a work unit. Based on this behavior tree, a corresponding workflow is generated and published to runtime 30, so that runtime 30 can control the production line operation of the work unit. Simultaneously, based on this behavior tree, microservice generator 20 can generate corresponding microservices and register them to knowledge platform 200, so that the IT domain's code development tool 301 can call the corresponding microservices through knowledge platform 200. Users can... Figure 4EThe GUI in the lower left corner shows how to edit the OT domain behavior tree by dragging and dropping various nodes, including function block nodes. For example, the knowledge platform 200 first retrieves the required data (e.g., workpiece processing parameters) from the database and server to control the operation of the entire work unit. Here, the work unit is a production line, which includes machines, conveyor belts, robotic arms, workers, PLCs, AGBs, etc. In practice, the IT domain code development tool 301 can also be located on the same hardware device as the low-code development tool 10, such as the same computer.

[0173] Figure 5 A schematic diagram of the structure of another workflow creation system provided in an embodiment of this application is shown. For example... Figure 5 As shown, this system can be used for implementation Figure 1A The method or implementation shown Figure 3 The workflow creation system shown, or implementation Figures 4A to 4D The workflow creation system described in any one of these descriptions is the OT domain low-code development platform 100. The aforementioned OT domain low-code development tool 10, OT domain microservice generator 20, runtime 30, and third-party device 60 can all be implemented as separate hardware devices, such as servers, workstations, microcontrollers, or processing chips. Alternatively, these devices can be implemented on the same hardware device, stored as software programs in at least one memory, and implemented through calls from at least one processor to perform the aforementioned OT domain low-code development method. The node library 110 and the generated microservices 40 can be stored in at least one memory.

[0174] like Figure 5 As shown, the system may include at least one memory 51, at least one processor 52, and at least one display 53. Additionally, it may include other components such as a communication port. Figure 5 (not shown in the image). These components communicate via bus 54.

[0175] At least one memory 51 is used to store computer programs. The at least one memory 51 may include a computer-readable medium, such as random access memory (RAM). Furthermore, the at least one memory 51 may also store an operating system, etc. Operating systems include, but are not limited to, Android, Symbian, Windows, Linux, etc. The computer program stored may include the following program modules: node library 110, graphical interface module 120, editing and processing module 130, and parsing and deployment module 140. Optionally, it may also include an OT domain microservice generator 20, a runtime 30, and a third-party device 50.

[0176] At least one processor 52 is used to invoke a computer program stored in at least one memory 51 to execute the workflow creation method described in the embodiments of this application. The at least one processor 52 can be a microprocessor, application-specific integrated circuit (ASIC), digital signal processor (DSP), central processing unit (CPU), graphics processing unit (GPU), state machine, etc. It can receive and send data through the communication port.

[0177] At least one display 53 is used to display an image user interface.

[0178] Specifically, at least one processor 52 is used to invoke a computer program stored in at least one memory 51 to cause the system to perform operations in the workflow creation method of any of the above embodiments. Furthermore, a communication interface is used to enable communication with other devices, such as with the knowledge platform 200.

[0179] In this embodiment, the OT domain low-code development tool 10, used to implement the graphical interface module 120, the editing and processing module 130, and the parsing and deployment module 140, can be a lightweight web-based application. It can be implemented in industrial settings (such as edge devices or local servers) or in the cloud (such as public clouds like AWS or private clouds like OpenStack). Its visual engineering paradigm is derived from the Function Block Type Diagram (FBTD). The OT domain microservice generator 20 can use modern translational programming languages ​​to generate standard APIs such as RESTful or RPC. The runtime 30 can easily implement OT domain workflows and provides openness based on the ecosystem of open-source communities (such as Python). The runtime 30 can be deployed on embedded IoT devices such as single-board computers (SBCs).

[0180] It should be mentioned that embodiments of this application may include those having different characteristics from those of other applications. Figure 5 The apparatus with the architecture shown is merely exemplary and is used to explain the workflow construction method provided in the embodiments of this application.

[0181] Furthermore, embodiments of this application also provide an IT domain-OT domain converged system, i.e., an ITOT system, which may include IT equipment and a workflow creation system as described in any embodiment of this application. Additionally, it may further include: Figure 4C and Figure 4D The code development platform 300 for the IT domain is shown.

[0182] The embodiments of the present invention also propose a technical solution for controlling the workflow by using a synthesizer node with a low-code paradigm (FBTD, Function Block Typed Diagram) logic. Figure 6 This is an exemplary flowchart of the workflow control method provided in various embodiments of this application.

[0183] like Figure 6 As shown, the method 600 includes:

[0184] Step 601: Based on the user's operation on the graphical user interface, determine the type of synthesizer node, which includes a start block adapted to start executing the synthesizer node, an end block adapted to end executing the synthesizer node, and a plurality of working links arranged between the start block and the end block.

[0185] Step 602: Based on the type of synthesizer node, determine the target working link from the multiple working links.

[0186] Step 603: Based on the target workflow, control the workflow logic, where the workflow is generated based on a behavior tree containing synthesizer nodes.

[0187] Synthesizer nodes always appear in pairs with start and end blocks. The start block has an optional input port to provide a synthesizer expression, allowing the selection of a target work link based on that expression. For example, the target work link can be selected based on the value of the synthesizer expression, or based on a work link selection rule defined by the synthesizer expression. The end block has an optional input port called the end logic value, which is used by parallel-type synthesizer nodes to determine whether it is a logical AND or logical OR operation. A pair of synthesizer blocks can contain two or more work links (i.e., branches). Optionally, a data value block (DVB) is appended to each work link in the synthesizer pair, representing the trigger value of the synthesizer expression for the corresponding work link. In one implementation, the data value block can be the value generated based on the synthesizer expression for the corresponding work link, used to select that work link. In another implementation, the data value block can also be a condition for selecting the corresponding work link, where the condition is related to a value generated based on the synthesizer expression.

[0188] In one implementation, at least one of the plurality of work links includes a function block node, which is used to implement business operations in the workflow.

[0189] In one implementation, determining the type of a synthesizer node based on user actions on a graphical user interface includes: determining the type of a synthesizer node based on user selection actions on the graphical user interface containing a node library, wherein the node library contains: synthesizer nodes whose types are identified semantically or whose types are identified by presentation styles.

[0190] In compositor nodes that are semantically identified by type, the type of the compositor node is directly identified by text in the visual icon of the compositor node.

[0191] In compositor nodes that use presentation styles to identify their type, different presentation styles are used to identify the type of the compositor node. For example, in the icon of a compositor node, different line types (such as solid lines, dashed lines, and spaced lines) are used to identify the type of the compositor node.

[0192] In one embodiment, the method further includes: receiving a user's behavior tree construction operation performed on the graphical user interface; wherein the construction operation includes adding and connecting behavior tree nodes, the behavior tree nodes including the synthesizer node and the function block node; the behavior tree is used to characterize the workflow, the workflow is used to define the operation to be performed by a work unit; the function block node includes: a logic node, each logic node corresponding to an operation template, each operation template predefines at least one type of operation that can be performed by a device, the operation including: action, method or skill; in response to the behavior tree construction operation, generating the behavior tree corresponding to the workflow, wherein the logic nodes in the behavior tree are instantiated as operations of the corresponding device; parsing the behavior tree to obtain the workflow; deploying the workflow to the runtime of the corresponding work unit so that each device in the work unit performs the operation according to the workflow; wherein the workflow is an OT domain workflow; the device is an OT device.

[0193] In one implementation, the method further includes: generating microservices based on the behavior tree, such that an IT device triggers the runtime of the main controller of the work unit to execute the OT domain workflow by invoking the microservices.

[0194] The following provides an illustrative example of how to achieve flexible control of the workflow using different types of synthesizer nodes.

[0195] Figure 7A This is a first schematic diagram illustrating a low-code example of an FBTD logic synthesizer provided in various embodiments of this application. Figure 7AIn this synthesizer node 70, there is a start block 71, an end block 72, and three working links arranged between the start block 71 and the end block 72. The first working link includes an execution function block node 73, the second working link includes an execution function block node 74, and the third working link includes an execution function block node 75. The start block 71 may contain inputs for providing the synthesized expression 76; the end block 72 may contain inputs for providing the ending logical value 77. Each function block node 73, function block node 74, and function block node 75 has its own data value block. The data value blocks 78, 79, and 80 of function block nodes 73 and 74 may be arranged before their respective function block nodes.

[0196] Depending on the type of synthesizer node 70, different ways of determining the target work link from multiple work links can be achieved, thus enabling flexible control over the workflow.

[0197] In one implementation, the synthesizer node 70 is of type Parallel (Pa); determining the target working link from the plurality of working links includes: identifying each working link in the plurality of working links as the target working link and starting execution of the target working link; the method further includes: receiving an end logic value via the input of an end block; wherein when the end logic value is logical AND, the execution of the synthesizer node is terminated via the end block when all the plurality of working links have been executed; when the end logic value is logical OR, the execution of the synthesizer node is terminated via the end block when at least one working link in the plurality of working links has been executed.

[0198] Specifically, in Figure 7A In the context of synthesizer node 70 being of type parallel selection, there is no need to provide synthesization expression 76 for synthesizer node 70, and correspondingly, there is no need to generate synthesized data value blocks 78-80. Furthermore, an end logic value 77 needs to be provided for synthesizer node 70. At this time, the first, second, and third working links are all determined as the destination working links. Moreover, the first, second, and third working links are executed separately (i.e., function block nodes 73, 74, and 75 are executed synchronously), where the value of the end logic value 77 determines when to stop executing synthesizer node 70. Specifically: when the provided end logic value 77 is a logical AND, synthesizer node 70 is terminated via end block 72 when the first, second, and third working links have all been executed; when the end logic value 77 is a logical OR, synthesizer node 70 is terminated via end block 72 when at least one of the first, second, and third working links has been executed.

[0199] In one implementation, the synthesizer node is of type multi-branch selection (SW, Switch), and the method further includes: receiving a pre-defined synthesis expression via the input of the start block; determining the target working link from the plurality of working links includes: determining the data value block when each working link is selected; and selecting the target working link that matches the corresponding data value block from the plurality of working links based on the calculation result of the synthesis expression.

[0200] Specifically, in Figure 7A In the synthesizer node 70, when the type is multi-branch selection, a synthesis expression 76 needs to be provided. Correspondingly, synthesis data value blocks 78-80 need to be generated based on the synthesis expression 76 or provided manually, but the ending logic value 77 does not need to be provided. For example, assuming the data value blocks are conditions for selecting the corresponding working link, where data value block 78 is: "temperature greater than 30 degrees and less than 50 degrees"; data value block 79 is: "temperature greater than 50 degrees"; and data value block 80 is: "temperature less than 30 degrees". Then, based on the specific temperature generated by the synthesis expression, the specific branch corresponding to the value block can be selected. For example, when the generated temperature is 20 degrees, the third working link corresponding to data value block 80 is selected.

[0201] In one implementation, the synthesizer node is of type If-Then-Else (ITE), and the method further includes: receiving a pre-defined synthesis expression via the input of the start block, wherein the result of the synthesis expression includes a logical true value or a logical false value; determining the destination working link from the plurality of working links includes: determining the corresponding destination working link from the plurality of working links based on whether the result of the synthesis expression is a logical true value or a logical false value.

[0202] Here, based on the logical value generated by the synthetic expression being true or false, a pre-defined working link corresponding to the logical value is selected.

[0203] Specifically, in Figure 7AIn the process, when the synthesizer node 70 is of type conditional judgment, a synthesis expression 76 that can generate a logical value of True or False needs to be provided. Assuming the first working link corresponds to True and the second working link corresponds to False, then when the value of the synthesis expression 76 is True, the first working link is selected and executed as the destination working link; when the value of the synthesis expression 76 is False, the second working link is selected and executed as the destination working link. In one embodiment, the synthesizer node is of type Priority (Pr, Priority(Fallback)), and the method further includes: receiving a pre-set synthesis expression via the input of the start block; determining the destination working link from the plurality of working links includes: calculating a data value block for each working link based on the synthesis expression; determining the priority order of the plurality of working links based on the sorting result of the data value blocks of each working link; and determining the destination working link from the plurality of working links based on the priority order. The data value block can be a value generated by the corresponding working link based on the synthesizer expression for selecting the corresponding working link. That is, data value blocks 78, 79, and 80 generated based on the synthesizer expression may not be the same (e.g., differences in parameters between execution links). In this case, the priority order of the plurality of working links is determined based on the sorting result of the data value blocks of each working link; based on the priority order, the target working link is determined from the plurality of working links. The sorting result of the data value blocks can be, based on a pre-set configuration, from largest to smallest or from smallest to largest, etc. For example, in... Figure 7A In the process, when the type of synthesizer node 70 is priority, a synthesis expression 76 needs to be provided. Assume the first link generates a data value block of 15 based on this synthesis expression 76; assume the first link generates a data value block 78 of 18 based on this synthesis expression 76, the second link generates a data value block 79 of 20 based on this synthesis expression 76, and the third link generates a data value block 80 of 25 based on this synthesis expression 76. The priority order of the working links is determined according to the size of the data value blocks. It is evident that the third link has the highest priority (because data value block 80 of the third link is the largest among the data value blocks), thus determining the third link as the destination working link, and executing the third link as the destination working link.

[0204] In one implementation, the synthesizer node is of type ReactivePriority (RPr, ReactivePriority(Fallback)), and the method further includes: receiving a first synthesis expression and a second synthesis expression via the input of the start block; determining the destination work link from the plurality of work links includes: calculating a first data value block for each work link based on the first synthesis expression; calculating a second data value block for each work link based on the second synthesis expression; determining a priority order of the plurality of work links based on the sorting result of the first data value blocks of the plurality of work links; and determining the destination work link from the plurality of work links based on the priority order and the second data value blocks of each work link.

[0205] exist Figure 7A In the synthesizer node, the type of synthesizer node can be directly identified by text in the visually effective icon (for example, the type is identified by text in the boxes of start block 71 and end block 72). Figure 7B This is a second schematic diagram illustrating a low-code example of an FBTD logic synthesizer provided in various embodiments of this application. Figure 7B In this design, start block 71 and end block 72 are simply identified using spacers with specific shapes, which not only visually identifies the type of synthesizer node but also saves canvas display resources.

[0206] The synthesizer nodes described above are easy to understand, but only apply to a limited number of branches. Therefore, this invention also introduces a new synthesizer node paradigm that can support a large number of branches. The folded synthesizer has similar functionality to a regular synthesizer, but supports folding.

[0207] In one embodiment, the synthesizer node is displayed in a collapsed frame on the graphical user interface, wherein the collapsed frame includes a first display area adapted to display the currently displayed workflow of the synthesizer node and hide workflows other than the currently displayed workflow. In one embodiment, the collapsed frame further includes a second display area, a third display area, and a toggle control; wherein the second display area is adapted to display the data value block of the currently displayed workflow; the third display area is adapted to display the label of the currently displayed workflow; and the toggle control is adapted to switch the currently displayed workflow among the plurality of workflows.

[0208] Figure 7C This is a schematic diagram illustrating a low-code example of a synthesizer with folded FBTD logic provided in various embodiments of this application.

[0209] exist Figure 7CIn the folded frame 90, there are a first display area 88, a second display area 83, and a third display area 81. The first display area 88 displays the currently displayed work link, which includes function block nodes 85 and 86. The second display area 83 displays the data value block of the currently displayed work link. The third display area 81 displays the label of the currently displayed work link. The folded frame 90 also includes a toggle control 84 (e.g., an arrow shape) for switching between the current displayed work links. The first display area 88 is preferably stretchable and can be stretched based on the length of the currently displayed work link contained therein. Thus, the folded synthesizer is another type of low-code example of an FBTD synthesizer. The data value block of the synthesizer expression result can be displayed in a new column of the header row. Furthermore, there are left and right arrow buttons to switch between different branches. The data value block of the current branch will be displayed in the data value block column. Simultaneously, the current label of the current branch of the synthesizer will be displayed in the work instruction label index block. The size of the folded synthesizer can be stretched for different numbers of function blocks, and this paradigm provides a convenient way to display complex logic in a limited area of ​​a low-code canvas.

[0210] The present invention also proposes an iterator node with iterative function, and a workflow generation method based on the iterator node.

[0211] Figure 8 An exemplary flowchart of a workflow generation method provided in an embodiment of this application. The method 700 includes:

[0212] Step 701: Receive the behavior tree construction operation performed by the user on the graphical user interface; wherein the construction operation includes the addition operation of behavior tree nodes, the behavior tree nodes include a first iterator node, the first iterator node includes an input end adapted to receive a first iteration item list and a first working link, the first iteration item list includes a plurality of first iteration items and the execution order of each first iteration item.

[0213] Step 702: In response to the behavior tree construction operation, generate a behavior tree containing the first iterator node.

[0214] Step 703: Parse the behavior tree to generate a workflow; wherein the workflow instructs each first iteration item to execute the first work link based on its respective execution order in the first iteration item list.

[0215] As can be seen, by providing the first iterator node with a list of iterator items containing the iterator items and the execution order of the iterator items, each iterator item can execute the first working link in the first iterator node in its own order, thereby realizing a fast processing logic for batch execution of working links.

[0216] In one implementation, the first workflow includes function block nodes, which are used to implement business operations in the workflow.

[0217] In one implementation, the first workflow includes a second iterator node, the second iterator node including an input adapted to receive a second iterative item list and a second workflow, the second iterative item list including a plurality of second iterative items and an execution order of each second iterative item; wherein the workflow further indicates that during the execution of the first workflow, each second iterative item executes the second workflow based on its respective execution order in the second iterative item list.

[0218] Therefore, by further setting other second iterator nodes in the first working link, a nested iterative processing method can be realized, thereby enriching the control logic.

[0219] In one embodiment, the first workflow includes a synthesizer node, which includes a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple workflows arranged between the start block and the end block; wherein the workflow also indicates that a destination workflow is determined from the multiple workflows based on the type of the synthesizer node. It is evident that by further configuring a synthesizer node in the first workflow, the control logic can be enriched.

[0220] In one embodiment, the method further includes deploying the workflow to a runtime of a work unit containing the plurality of first iteration items, such that the plurality of first iteration items in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device. Therefore, embodiments of the present invention can achieve workflow control in the OT domain.

[0221] In one implementation, the first iterator node is selected based on a user's selection operation on the graphical user interface containing the node library. Therefore, the iterator node can be conveniently provided to the user through the selection operation of the node library.

[0222] The first iterator node includes a first display area adapted to display the type of the first iterator node. The first iterator node also includes a second display area adapted to display the label of the first iteration item currently executing the first workflow. Therefore, by setting a display area in the iterator node, the type of the iterator node can be identified, and the label of the currently executing iteration item can be visualized.

[0223] Figure 9 A schematic diagram illustrating a low-code example of an iterator provided in an embodiment of this application.

[0224] exist Figure 9 In the process, iterator node 60 includes an input adapted to receive an iterable item list 61. Iterator node 60 also includes a first display area 62, a second display area 63, and a workflow. The workflow includes function block nodes 64 and 65 connected sequentially. The iterable item list 61 contains multiple iterable items and the execution order of each iterable item. Iterator 60 also includes a pin 66 adapted to connect to the previous node in the workflow and a pin 67 adapted to connect to the next node in the workflow. The previous node can be a synthesizer node, decorator node, function block node, or other iterator, etc. The next node can be a synthesizer node, decorator node, function block node, or other iterator, etc. Moreover, based on specific control requirements, function block nodes 64 and 65 can be replaced by synthesizer nodes, decorator nodes, function block nodes, or other iterators, respectively.

[0225] For example, the iterative project list 61 includes 100 robots and their respective execution sequences. Specifically, it includes: Execution Sequence 1: Robot 1; Execution Sequence 2: Robot 2; Execution Sequence 3: Robot 3; Execution Sequence 4: Robot 4; and so on, up to Execution Sequence 100: Robot 100. Functional block node 64 in the workflow is a camera node, and functional block node 65 is an object recognition node. The generated workflow indicates: In the first iteration, Robot 1 executes the camera node function to perform camera capture, and then Robot 1 executes the object recognition function to perform object recognition on the captured image. After the first iteration is completed, the second iteration is executed. In the second iteration: Robot 2 executes the camera node function to perform camera capture, and then Robot 2 executes the object recognition function to perform object recognition on the captured image. After the second iteration is completed, the third iteration is executed. In the third iteration, Robot 3 executes the camera node function to perform camera capture, and then Robot 3 executes the object recognition function to perform object recognition on the captured image. This process continues until the 99th iteration is completed, at which point the 100th iteration is executed. In the 100th iteration, robot 100 executes the camera node's function to capture images, and then robot 100 executes the object recognition function to perform object recognition on the captured images, thus completing the control logic of iterator node 60.

[0226] Figure 10 This is an exemplary structural diagram of a workflow generation apparatus provided in various embodiments of this application. The workflow generation apparatus 800 includes: a receiving module 801 configured to receive a behavior tree construction operation performed by a user on a graphical user interface; wherein the construction operation includes an addition operation of behavior tree nodes, the behavior tree nodes including first iterator nodes, the first iterator nodes including an input adapted to receive a first iterative item list and a first workflow, the first iterative item list including a plurality of first iterative items and an execution order of each first iterative item; a behavior tree generation module 802 configured to generate a behavior tree including the first iterator nodes in response to the behavior tree construction operation; and a workflow generation module 803 configured to parse the behavior tree to obtain a workflow; wherein the workflow indicates that each first iterative item executes the first workflow based on its respective execution order in the first iterative item list.

[0227] In one implementation, the first workflow includes function block nodes, which are used to implement business operations in the workflow.

[0228] In one implementation, the first workflow includes a second iterator node, the second iterator node including an input adapted to receive a second iterative item list and the second workflow, the second iterative item list including a plurality of second iterative items and an execution order of each second iterative item; wherein the workflow further indicates that during the execution of the first workflow, each second iterative item executes the second workflow based on its respective execution order in the second iterative item list.

[0229] In one implementation, a workflow includes a synthesizer node, the synthesizer node including a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple workflows arranged between the start block and the end block; wherein the workflow also indicates that a destination workflow is determined from the multiple workflows based on the type of the synthesizer node.

[0230] In one embodiment, a deployment module 804 is further included for deploying the workflow to a runtime of a work unit containing the plurality of first iteration items, such that the plurality of first iteration items in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device.

[0231] Furthermore, embodiments of this application also provide a computer-readable storage medium storing computer-readable code, which, when executed by a processor, causes the processor to perform the aforementioned workflow generation method. Additionally, embodiments of this application also provide a computer program product tangibly stored on a computer-readable medium and including computer-readable instructions, which, when executed, cause at least one processor to perform the steps of the workflow generation method in the embodiments of this application. Embodiments of this application also propose a workflow generation system with similar... Figure 5 The system architecture described herein may include at least one memory 51, at least one processor 52, and at least one display 53. The at least one processor 52 is used to invoke a computer program stored in the at least one memory 51 to execute the workflow generation method described in this embodiment.

[0232] Specifically, a system or apparatus equipped with a storage medium storing computer-readable code that implements the functions of any of the embodiments described above can be provided. The computer (or CPU or MPU) of the system or apparatus can read and execute the computer-readable code stored in the storage medium. Furthermore, an operating system or similar device operating on the computer can perform some or all of the actual operations based on instructions from the computer-readable code. The computer-readable code read from the storage medium can also be written to a memory located in an expansion board inserted into the computer or to a memory located in an expansion unit connected to the computer. Subsequently, instructions from the computer-readable code can be used to execute some or all of the actual operations by a CPU or similar device installed on the expansion board or expansion unit, thereby implementing the functions of any of the embodiments described above. In this embodiment, embodiments of the computer-readable medium include, but are not limited to, floppy disks, CD-ROMs, magnetic disks, optical disks (such as CD-ROM, CD-R, CD-RW, DVD-ROM, DVD-RAM, DVD-RW, DVD+RW), memory chips, ROMs, RAMs, ASICs, configured processors, all-optical media, all magnetic tapes or other magnetic media, or any other medium from which a computer processor can read instructions. In addition, various other forms of computer-readable media can send or carry instructions to a computer, including routers, private or public networks, or other wired and wireless transmission devices or channels, such as downloading computer-readable instructions from a server computer or the cloud via a communication network. Instructions can include code in any computer programming language, including C, C++, C++, Visual Basic, Java, and JavaScript.

[0233] It should be noted that not all steps and modules in the above processes and system structure diagrams are mandatory; some steps or modules can be omitted as needed. The execution order of each step is not fixed and can be adjusted as required. The system structure described in the above embodiments can be a physical structure or a logical structure. That is, some modules may be implemented by the same physical entity, or some modules may be implemented by multiple physical entities, or they may be jointly implemented by certain components in multiple independent devices.

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

Claims

1. A workflow generation method (700), characterized in that, include: The system receives a behavior tree construction operation performed by a user on a graphical user interface. The construction operation includes adding behavior tree nodes. Each behavior tree node includes a first iterator node. The first iterator node includes an input adapted to receive a first iteration item list and a first workflow. The first iteration item list includes a plurality of first iteration items and the execution order of each first iteration item (701). The first iterator node includes a first display area in the graphical user interface. The first display area is adapted to display the type of the first iterator node. In response to the behavior tree construction operation, a behavior tree containing the first iterator node is generated (702). The behavior tree is parsed to generate a workflow, wherein the workflow instructs each first iteration item to execute the first work link based on its respective execution order in the first iteration item list; wherein, in the workflow, for each first iteration item in the first iteration item list, the first work link is executed by that first iteration item (703); further comprising: The workflow is deployed to a runtime of a work unit containing the plurality of first iteration projects, such that the plurality of first iteration projects in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device.

2. The workflow generation method (700) according to claim 1, characterized in that, The first workflow includes function block nodes, which are used to implement business operations in the workflow.

3. The workflow generation method (700) according to claim 1, characterized in that, The first working link includes a second iterator node, the second iterator node includes an input adapted to receive a second iterative item list and a second working link, the second iterative item list includes a plurality of second iterative items and the execution order of each second iterative item; The workflow further indicates that during each execution of the first workflow, each second iteration project executes the second workflow based on its respective execution order in the second iteration project list.

4. The workflow generation method (700) according to claim 1, characterized in that, The first working link includes a synthesizer node, which includes a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple working links arranged between the start block and the end block. The workflow also indicates the determination of a target workflow from the multiple workflows based on the type of the synthesizer node.

5. The workflow generation method (700) according to any one of claims 1-4, characterized in that, include: The first iterator node is selected based on the user's selection action on the graphical user interface containing the node library.

6. The workflow generation method (700) according to claim 5, characterized in that, The first iterator node includes a first display area, which is adapted to the type of displaying the first iterator node.

7. The workflow generation method (700) according to claim 6, characterized in that, The first iterator node also includes a second display area, which is adapted to display the label of the first iteration project currently executing the first workflow.

8. A workflow generation device (800), characterized in that, include: The receiving module (801) is configured to receive a behavior tree construction operation performed by a user on a graphical user interface, wherein the construction operation includes an operation of adding behavior tree nodes, the behavior tree nodes include a first iterator node, the first iterator node includes an input adapted to receive a first iteration item list and a first working link, the first iteration item list includes a plurality of first iteration items and the execution order of each first iteration item; wherein the first iterator node includes a first display area in the graphical user interface, the first display area being adapted to display the type of the first iterator node; The behavior tree generation module (802) is configured to generate a behavior tree containing the first iterator node in response to the behavior tree construction operation; Workflow generation module (803) is configured to parse the behavior tree to obtain a workflow; wherein the workflow instructs each first iteration item to execute the first work link based on its respective execution order in the first iteration item list; wherein, in the workflow, for each first iteration item in the first iteration item list, the first work link is executed by that first iteration item; further comprising: The deployment module (804) is configured to deploy the workflow to a runtime of a work unit containing the plurality of first iteration items, such that the plurality of first iteration items in the work unit perform operations according to the workflow, wherein the workflow is an OT domain workflow; and the work unit is an OT device.

9. The workflow generation apparatus (800) according to claim 8, characterized in that, The first workflow includes function block nodes, which are used to implement business operations in the workflow.

10. The workflow generation apparatus (800) according to claim 8, characterized in that, The first working link includes a second iterator node, the second iterator node includes an input adapted to receive a second iterative item list and a second working link, the second iterative item list includes a plurality of second iterative items and the execution order of each second iterative item; The workflow further indicates that during the execution of the first work link, each second iteration project executes the second work link based on its respective execution order in the second iteration project list.

11. The workflow generation apparatus (800) according to claim 8, characterized in that, The work link includes a synthesizer node, which includes a start block adapted to begin execution of the synthesizer node, an end block adapted to end execution of the synthesizer node, and multiple work links arranged between the start block and the end block. The workflow also indicates the determination of a target workflow from the multiple workflows based on the type of the synthesizer node.

12. A workflow control system, characterized in that, include: At least one memory (51) is configured to store computer-readable code; At least one processor (52) is configured to invoke the computer-readable code to perform the steps of the workflow generation method (700) as claimed in any one of claims 1 to 7.

13. A computer-readable medium, characterized in that, The computer-readable medium stores computer-readable instructions, which, when executed by a processor, cause the processor to perform the steps of the workflow generation method (700) as described in any one of claims 1 to 7.

14. A computer program product, characterized in that, The computer program product is tangibly stored on a computer-readable medium and includes computer-readable instructions that, when executed, cause at least one processor to perform the steps of the workflow generation method (700) according to any one of claims 1 to 7.

Images