Method and apparatus for processing industrial behavior description file, and computer device

Abstract

Disclosed in the present application is a method for processing an industrial behavior description file, the method comprising: receiving a behavior description file on the basis of a definition of an industrial behavior model; splitting the behavior description file into a plurality of logic types, and respectively distributing same to a plurality of logic models; and executing the logic types in the plurality of logic models, so as to control the operation of an industrial object. By means of the method in the present application, a behavior description file can be converted, within the same system, into different logic types, and by means of different logic models included in the system, an industrial object is driven to operate. Therefore, the method is relatively convenient and unified.

Description

Industrial behavior description file processing method, device, and computer equipment Technical Field

[0001] The present application relates to the industrial field, and in particular, to a method, apparatus, computer equipment, and storage medium for industrial behavior description files. Background Art

[0002] Typical industrial scenarios are often very complex and are typically described by standard operating procedures (SOPs) or bills of process (BOPs), which can be converted into behaviors and workflows through system logic. However, system logic consists of multiple hierarchies, each described by a different language, information model, or algorithm. The most commonly used logic models include finite state machines (FSMs), hierarchical finite state machines (HFSMs), behavior trees, and rule engines, which are typically executed by different controllers or software.

[0003] Summary of the Invention

[0004] This summary is provided to introduce some selected concepts in a simplified form, which will be further described in the detailed description below. This summary is not intended to identify any key features or essential features of the claimed subject matter, nor is it intended to be used to help determine the scope of the claimed subject matter.

[0005] Based on this, the present application discloses a method for processing industrial behavior description files, which includes: receiving a behavior description file according to the definition of an industrial behavior model; splitting the behavior description file into multiple logical types and distributing them to multiple logical models respectively; executing the logical types in the multiple logical models to control the operation of industrial objects.

[0006] Through the above method, the corresponding behaviors or workflows in the behavior description file can be converted into corresponding logical types, and then distributed to control the execution or operation of different industrial objects, saving compilation costs and improving the uniformity of industrial task processing.

[0007] Furthermore, the method further includes: receiving a logic description file according to the definition of the industrial behavior model.

[0008] Through the above method, the behavior description file can be further described and modified, so as to facilitate the subsequent logic decomposition into the corresponding execution logic.

[0009] Furthermore, the behavior description file is split into multiple logic types and distributed to multiple logic models respectively, including: converting the logic in the behavior description file into common logic, relative logic and complex logic respectively;

[0010] Distribute the above common logic, relative logic, and complex logic to the behavior tree model, finite state machine model, and rule engine model respectively.

[0011] Through the above method, the text description file can be broken down into different logical types and distributed to different logical models, which further facilitates subsequent related distribution and execution.

[0012] Furthermore, it also includes: receiving a state mapping standard input of a state mapper.

[0013] Through the above method, the logic in the behavior logic file can be mapped according to the industry mapping standard, thereby facilitating the subsequent execution of different industrial objects.

[0014] The present application also discloses a device for processing an industrial behavior description file, which includes:

[0015] A description file receiving module is used to receive a behavior description file according to the definition of the industrial behavior model;

[0016] An industrial logic scheduling module splits the behavior description file into multiple logic types and distributes them to multiple logic models respectively;

[0017] Industrial logic coordination module, used to execute the logic types in the multiple logic models to control the operation of industrial objects

[0018] The present application also provides a computer device, comprising a memory and a processor, wherein the memory stores a computer program, and wherein the processor implements the above method when executing the computer program.

[0019] The present application also provides a computer-readable storage medium having a computer program stored thereon, and the computer program implements the above method when executed by a processor.

[0020] The present application also provides a computer program product, which is tangibly stored on a computer-readable medium and includes computer-executable instructions. When the computer-executable instructions are executed, the computer-executable instructions cause at least one processor to perform the method described above. BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Implementations of the present disclosure are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate the same or similar parts.

[0022] FIG1 is a schematic diagram of a process of a method for processing an industrial behavior description file according to an embodiment of the present application.

[0023] FIG2 is a schematic diagram of a device for processing industrial behavior description files according to an embodiment of the present application.

[0024] FIG3 is a schematic diagram of a computer device for processing an industrial behavior description file according to an embodiment of the present application.

[0025] FIG4 is a schematic diagram of an industrial logic scheduling module according to an embodiment of the present application.

[0026] FIG5 is a schematic diagram of a device for processing industrial behavior description files according to an embodiment of the present application.

[0027] FIG6 is a schematic diagram of an industrial logic transmitter according to an embodiment of the present application.

[0028] The reference numerals are as follows: S101-S103 Step 200: Apparatus 201: Module 202: Module 203: Module 204: Module 206: Module 207: Module 208: Module 300: Computer device 302: Processor 304: Memory DETAILED DESCRIPTION

[0029] In the following description, for the purpose of explanation, a large number of specific details are set forth. However, it is understood that the present invention can be implemented without these specific details. In other examples, well-known circuits, structures, and technologies are not shown in detail so as not to affect the understanding of the description.

[0030] References throughout this specification to "an implementation," "an implementation," "an exemplary implementation," "some implementations," "various implementations," etc., indicate that the implementations of the invention being described may include particular features, structures, or characteristics. However, it does not imply that every implementation must include those particular features, structures, or characteristics. Furthermore, some implementations may have some, all, or none of the features described for other implementations.

[0031] It should be understood that although the various steps in the flowchart of FIG1 are shown in sequence as indicated by the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be executed in other orders. Moreover, at least a portion of the steps in FIG1 may include multiple steps or multiple stages, and these steps or stages are not necessarily executed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily to be carried out in sequence, but can be executed in turn or alternately with other steps or at least a portion of steps or stages in other steps.

[0032] According to current practice, there are many unresolved issues: for example,

[0033] Problem A: Systems described using FSM, HFSM, behavior trees, and rule engines are difficult to integrate. They lack a systematic method to describe the logical models in a standardized way.

[0034] Problem B: Certain logic methods, such as behavior trees, require extensible definitions to support complex logic.

[0035] Problem C: The complex logic of FSM and HFSM is difficult to understand and implement in code. Changing the current state or adding a new state is also difficult.

[0036] Problem D: The execution engines of different logic models are very different and incompatible with each other.

[0037] Among existing technologies, open automation groups, such as OPC (OLE for Process Control) and IEC61499, still lack a good method for describing complex logic in industrial scenarios. The IEC61499 and IEC61131-3 communities have some promising approaches for handling complex logic using FSMs or variant FSM systems. However, these systems are often difficult for junior engineers to understand and are incompatible with other systems. The Behavior Tree community has conducted various studies on describing complex logic using methods such as relative composites, but their implementation methods increase system complexity. Rule engines, on the other hand, are generally not integrated with other logic models.

[0038] The implementation scenario and focus of this application are: creating an Industrial Logic Emitter, which is a core component of the system that integrates FSM, behavior tree and rule engine. It can accept behavior description files, convert them into corresponding logic, distribute them to different logic models, and give different state mappings according to industry standards, so as to ultimately control the operation of different software and hardware entities through the coordinator. In this way, the innovative method of describing industrial complex logic in a unified format using the Industrial Logic Emitter can be used to provide a solution for general industrial control scenarios. It can be implemented by different engineering and operation software, thereby subsequently controlling the execution or operation of industrial objects, saving compilation costs and reducing complexity.

[0039] Based on this, the present application discloses a method for processing an industrial behavior description file, which includes:

[0040] S101, receiving a behavior description file according to the definition of the industrial behavior model.

[0041] Specifically, the behavior description file includes a file used to represent the logic of industrial execution, or a description of industrial steps. The behavior description file can be generated based on the industrial behavior model. The behavior description provided in natural language or document form is the source input of the industrial workflow and can be described by the industrial behavior model.

[0042] The Industrial Behavior Model (IBM) is a common information model (CIM) that focuses on industrial interoperability behavior definitions and can work in conjunction with existing and future information models such as OLE for Process Control Unified Architecture (OPC UA), Asset Administration Shell (AAS), and the National Association of Automation for Process Industries (NAMUR MTP). The IBM provides common definitions for instructions and skills for common industrial work steps, including "BOP / SOP work steps," "machine skills," "controller instructions," and "human actions" (manual industrial work steps).

[0043] S102: Split the behavior description file into multiple logical types and distribute them to multiple logical models respectively.

[0044] Specifically, the above behavior description file is split into different parts and then distributed to different logic models (Logic Model).

[0045] Specifically, these behavioral descriptions are input into the core component, the industrial logic transmitter, which integrates logic models such as behavior trees, FSMs, and rule engines. In some embodiments, behavior trees, FSMs, and rule engines are three different logic models that can handle logic types such as trees, graphs, and expressions or scripts, respectively.

[0046] In some embodiments, the Industrial Logic Emitter will use a Logic Dispatcher to fuse Behavior Tree Tasks & Composites with FSM & HDSM driven actions. The relative composites of the Behavior Tree will also be replaced by FSM logic, as FSM logic is easier to understand and describe. The complex logic will be implemented and executed by the Rule Engine, which can also be converted to an FSM or HFSM.

[0047] In some embodiments, the data structure tree of the Behavior Tree and the graph of FSM can be interpreted by the same industrial logic orchestrator.

[0048] S103: Execute the logic types in the multiple logic models to control the operation of the industrial objects.

[0049] Specifically, the Industrial Logic Orchestration (ILO) will execute and coordinate logic from different logic models to control various OT (Operational Technology) hardware devices or resources.

[0050] Specifically, the industrial logic orchestrator is the execution engine for logic and functionality. It is typically an executable binary file or container that can be deployed to edge devices or cloud services. All different logic in various paradigms will be executed in the same orchestration engine. At the same time, the orchestration engine will communicate with the execution target, such as software or hardware devices, and support the selected language, that is, it supports the execution of different programming languages ​​​​and domain-driven languages ​​​​. In short, all software, hardware, and code will be coordinated by logic.

[0051] In this way, the overall system architecture flow of the industrial logic transmitter-based solution was built, which can integrate different logic models including FSM, behavior tree and rule engine.

[0052] In some embodiments, the industrial logic transmitter may include a behavior description and a logic description described by an industrial behavior model, as well as a logic dispatcher for logic classification, and a mutated state for mapping to other state machine standards.

[0053] This approach leverages the innovative method of describing industrial complex logic in a unified format using industrial logic transmitters, providing a solution for general industrial control scenarios. This solution can be implemented by different engineering and operational software, thereby subsequently controlling the execution or operation of industrial objects, saving compilation costs and reducing complexity.

[0054] Furthermore, it also includes: receiving a logic description file according to the definition of the industrial behavior model.

[0055] The Logic Description file is a markup language description of the industrial behavior model for general logic, such as sequence, parallel, condition, loop, selector, timer, and other logic. The Logic Description file will become part of the input of the Logic Dispatcher or the industrial logic dispatch module 202. As shown in Figure 6, the industrial behavior model can obtain a behavior description file and a logic description file. Both the behavior description file and the logic description file can be input into the Logic Dispatcher for logic classification. After classification, normal logic (or short for logic), relative logic (Relative Logic), and complex logic (Complex Logic) are obtained.

[0056] Through the above method, the behavior description file can be further described and modified, so as to facilitate the subsequent logic splitting and decomposition into corresponding logic types to be input into the logic model.

[0057] Furthermore, the behavior description file is split into multiple logical types and distributed to multiple logical models respectively, including:

[0058] Converting the logic in the behavior description file into common logic, relative logic and complex logic respectively;

[0059] Distribute the above common logic, relative logic, and complex logic to the behavior tree model, finite state machine model, and rule engine model respectively.

[0060] As shown in Figure 6, the Logic Dispatcher is the core of the Industrial Logic Transmitter. This component first collects behavior and logic descriptions in the Industrial Behavior Model format using an Industrial Behavior Model template. Using this as a source, it categorizes the raw logic into three types: normal logic, relative logic, and complex logic. Relative logic can be understood as requiring feedback and state updates every tick. Complex logic, on the other hand, requires expressions or scripts to describe it. In short, different logic types are assigned to different logic models.

[0061] As mentioned above, behavior trees, FSMs, and rule engines are three different logic models, each capable of handling tree, graph, and expression or script logic types. As shown in the figure, normal logic corresponds to trees, relative logic to graphs, and complex logic to expressions or scripts.

[0062] Through the above method, the behavior description file can be disassembled into different logical types and distributed to different logical models, thereby completing the driving and execution of the corresponding industrial software and hardware.

[0063] Furthermore, it also includes: receiving a state mapping standard input of a state mapper.

[0064] Among them, the state mapper (State Mapping System) is used to generate state mapping (State Mapping) or mutated state (Mutated State). Specifically, the actual state machines of logic models follow many existing standards from multiple domains and are not compatible with each other. For example, PackML state machines, ISA88 Batch state machines, and IEC61499 state machines cannot be directly integrated. Therefore, a method for integrating them through state mapping (State Mapping) is needed. In some embodiments, the state mapper can also be referred to as a mutated state. Therefore, the mutated state component provides the interface for state mapping to states from other standard or non-standard state machines. It can also be expanded to support other states. As shown in Figure 6, the mutated state will serve as an input for the logic dispatcher to dispatch different types of logics.

[0065] Through the above method, mapping is performed according to the industrial mapping standard, thereby facilitating the subsequent execution of different industrial objects.

[0066] In summary, compared to traditional logic actuators, this system brings many advantages to traditional or new system solutions in typical industrial scenarios, including:

[0067] -Describe different industrial logics in a unified format instead of incompatible formats.

[0068] -Execute different logic models in the same software system instead of multiple systems.

[0069] -Be compatible with different standardized state machines.

[0070] - Provide better developer experiences for future engineering and runtime than current ones.

[0071] As shown in Figure 5, the overall system architecture flow of a solution based on an industrial logic transmitter is disclosed. This solution can integrate different logic models, including FSM, behavior trees, and rule engines. Behavior descriptions are provided in natural language or document form and serve as the source input for industrial workflows, described and defined by the Industrial Behavior Model. As shown in Figure 5, the components of a behavior description file can include: BOP / SOP work steps, machine skills, controller instructions, and human actions.

[0072] As shown above, these behavioral descriptions are fed into the core component, the Industrial Logic Emitter, which integrates behavior trees, FSMs, and rule engine logic. Finally, the Industrial Logic Orchestrator executes and coordinates the logic from the different logic models to control various OT (Operational Technology) hardware devices or resources.

[0073] The Industrial Logic Emitter is an innovative method that describes industrial composite logics in a unified format. It provides a solution for common industrial control scenarios and can be implemented by different engineering and runtime software.

[0074] In some embodiments, the Behavior Tree model includes elements such as actions, composites, conditionals, and decorators, which can help understand the Behavior Tree in Figure 5 . Some common concepts in the prior art can help understand Figure 5 .

[0075] Furthermore, industrial logic transmitters can bring benefits and value to different businesses:

[0076] For example, 1. IEC61131-3-based programmable logic controllers (PLCs) and distributed control system (DCS) software and controllers can use this system to describe and execute complex logic, providing a better developer experience based on "Logic of Choice." For example, 2. Behavior tree-based software or control systems can use this approach to replace scalable logic in a more elegant and intuitive manner. For example, 3. IEC61499 systems can use this system to describe understandable complex logic. For example, 4. General industrial business or control workflows can be described using this approach.

[0077] FIG2 provides a device 200 for processing an industrial behavior description file, which includes:

[0078] The description file receiving module 201 is used to receive the behavior description file according to the definition of the industrial behavior model;

[0079] Industrial logic scheduling module 202 is used to split the behavior description file into multiple logic types and distribute them to multiple logic models respectively.

[0080] The industrial logic coordination module 203 is used to execute the logic types in the multiple logic models to control the operation of industrial objects.

[0081] Furthermore, it also includes: a logic description receiving module 204, which is used to receive a logic description file according to the definition of the industrial behavior model.

[0082] Furthermore, the industrial logic scheduling module 202 includes:

[0083] a logic scheduler conversion module 206 for converting the logic in the behavior description file into ordinary logic, relative logic and complex logic;

[0084] The logic scheduler distribution module 207 is used to distribute the above-mentioned common logic, relative logic and complex logic to the different logic models respectively.

[0085] Furthermore, the industrial logic scheduling module 202 further includes:

[0086] The logical scheduler mapping module 208 is configured to receive a state mapping standard input from the state mapper.

[0087] It should be noted that the apparatus may include more or fewer modules to implement the described functionality. For example, at least one module in FIG. 2 may be further divided into a plurality of different submodules, each of which is configured to perform at least a portion of the operations described herein in conjunction with the corresponding module. Furthermore, in some examples, apparatus 200 may include additional modules for performing other operations already described in the specification. Furthermore, those skilled in the art will appreciate that exemplary apparatus 200 may be implemented using software, hardware, firmware, or any combination thereof.

[0088] Figure 3 provides a computer device. According to one embodiment, the computer device 300 may include a processor 302, which executes a computer program stored in a memory 304. When the computer program is executed by the processor, the above method is implemented.

[0089] Those skilled in the art will understand that the structure shown in Figure 3 is merely a block diagram of a portion of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0090] Those skilled in the art will appreciate that all or part of the processes in the methods for implementing the above-mentioned embodiments can be accomplished by instructing the relevant hardware through a computer program, and the computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include processes for the implementation of the above-mentioned methods. Among them, any reference to memory, storage, database or other media used in the various embodiments provided in this application may include at least one of non-volatile and volatile memory. Non-volatile memory may include read-only memory (ROM), magnetic tape, floppy disk, flash memory or optical memory, etc. Volatile memory may include random access memory (RAM) or external cache memory. As an illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM).

[0091] The present application also provides a computer-readable storage medium having a computer program stored thereon, which implements the above steps when the computer program is executed by a processor.

[0092] The present application also provides a computer program product, which is tangibly stored on a computer-readable medium and includes computer-executable instructions. When the computer-executable instructions are executed, the computer-executable instructions cause at least one processor to perform the above method.

[0093] Furthermore, the computer program can be stored and run in the cloud to perform the method. Furthermore, the components of the program can be deployed on multiple devices and the cloud. For example, the corresponding steps can be deployed and run on a local or local computer, or run on different cloud devices, and transmit signals through a communication connection, or can also be deployed and run on a local or local computer. This application does not limit the manner or method, and the corresponding technology can be flexibly deployed to make full use of equipment and technologies such as the cloud, big data, and supercomputing capabilities to execute and complete the method.

[0094] Some implementations of the present disclosure may include articles of manufacture. Articles of manufacture may include storage media for storing logic. Examples of storage media may include one or more types of computer-readable storage media capable of storing electronic data, including volatile or non-volatile memory, removable or non-removable memory, erasable or non-erasable memory, writable or rewritable memory, and the like. Examples of logic may include various software units, such as software components, programs, applications, computer programs, application programs, system programs, machine programs, operating system software, middleware, firmware, software modules, routines, subroutines, functions, methods, processes, software interfaces, application program interfaces (APIs), instruction sets, computing codes, computer codes, code segments, computer code segments, words, values, symbols, or any combination thereof. In some implementations, for example, articles of manufacture may store executable computer program instructions that, when executed by a processor, cause the processor to perform the methods and / or operations described herein. Executable computer program instructions may include any suitable type of code, such as source code, compiled code, interpreted code, executable code, static code, dynamic code, and the like. Executable computer program instructions can be implemented according to a predefined computer language, method or syntax for commanding a computer to perform a specific function. The instructions can be implemented using any appropriate high-level, low-level, object-oriented, visual, compiled and / or interpreted programming language.

[0095] What has been described above includes examples of the disclosed architecture. It is, of course, not possible to describe every conceivable combination of components and / or methodologies, but those skilled in the art will appreciate that many other combinations and permutations are possible. Therefore, the novel architecture is intended to embrace all such alternatives, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A method for processing an industrial behavior description file, wherein: include: Receive behavior description files according to the definition of industrial behavior model; Splitting the behavior description file into multiple logic types and distributing them to multiple logic models respectively; Logic types in the plurality of logic models are executed to control the operation of the industrial object.

2. The method according to claim 1, wherein: Also includes: According to the definition of the industrial behavior model, a logic description file is received.

3. The method according to claim 1, wherein: The behavior description file is split into multiple logic types and distributed to multiple logic models respectively, including: Converting the logic in the behavior description file into common logic, relative logic and complex logic respectively; Distribute the above common logic, relative logic and complex logic to the behavior tree model, finite state machine model and rule engine model respectively.

4. The method according to claim 3, further comprising: Receives the state map standard input from the state mapper.

5. A device (200) for processing an industrial behavior description file, wherein: include: A description file receiving module (201), used for receiving a behavior description file according to the definition of the industrial behavior model; An industrial logic scheduling module (202) splits the behavior description file into multiple logic types and distributes them to multiple logic models respectively; The industrial logic coordination module (203) is used to execute the logic types in the multiple logic models to control the operation of the industrial objects.

6. The device (200) according to claim 5, wherein: Also includes: The logic description receiving module (204) is used to receive a logic description file according to the definition of the industrial behavior model.

7. The device (200) according to claim 5, wherein: The industrial logic scheduling module (202) comprises: A logic scheduler conversion module (206), used to convert the logic in the behavior description file into common logic, relative logic and complex logic respectively; The logic scheduler distribution module (207) is used to distribute the above-mentioned common logic, relative logic and complex logic to the different logic models respectively.

8. The device (200) according to claim 7, wherein: The industrial logic scheduling module (202) further includes: The logical scheduler mapping module (208) is used to receive the state mapping standard input of the state mapper.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program, wherein: When the processor executes the computer program, the steps of the method according to any one of claims 1 to 4 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, wherein: When the computer program is executed by a processor, the steps of the method according to any one of claims 1 to 4 are implemented.

11. A computer program product tangibly stored on a computer readable medium and comprising computer executable instructions which, when executed, cause at least one processor to perform the method according to any one of claims 1 to 4.

Images