A plant rules management platform

Abstract

A kind of factory rule management platform belongs to industrial internet of things technical field.It includes: process thing model modeling module, process thing model download module, equipment event reporting process module, process database management module, process thing model read-write module, process rule execution module, process database synchronization module.The advantage is that the related tasks and events in process are mapped as method and event of thing model, and factory thing model and original equipment thing model are combined, business event processing is realized by combining rule engine, the processing logic and fast calculation of original business data deployed in cloud can be realized in edge and uploaded to cloud, the communication amount of cloud is reduced, and the use of rule engine can realize customization of process execution on the basis of guaranteeing flexibility of business system, reduce redundant development, and can flexibly meet the change of business demand.

Description

Technical Field

[0001] This invention belongs to the field of industrial Internet of Things (IoT) technology, and in particular provides a factory rule management platform. This rule management platform supports process management, object model management and rule engine. By establishing object model elements such as process object models, process business rule templates and device-business linkage rules, it enhances the business service capabilities of the edge terminal and realizes the adaptation and flexible management of the rule engine to the customized needs of the factory's digital business processes. Background Technology

[0002] RestFul interface

[0003] RESTful is a web service interaction specification. Compared to other web interaction specifications (such as SOAP [Simple Object Protocol], XML-RPC [using HTTP as the transport protocol and XML text as the data]), it is more lightweight and HTTP-oriented. Clients use four verbs—GET, POST, PUT, and DELETE—to manipulate server resources: GET is used to retrieve resources, POST is used to create resources (and can also be used to update resources), PUT is used to update resources, and DELETE is used to delete resources. Resources are manipulated based on their representation; the representation of resources is either XML or HTML. The interaction between the client and server is stateless between requests; each request from the client to the server must contain the information necessary to understand the request.

[0004] Industrial Internet of Things Platform

[0005] An Industrial Internet of Things (IIoT) platform is an integrated platform encompassing device management, secure data communication, and message subscription capabilities. It supports the connection of massive numbers of devices, collecting data from cloud-based systems, and provides cloud APIs. Servers can call these APIs to send commands to devices, enabling remote control and allowing for secure, reliable, and efficient interaction. It possesses device integration, data integration, process integration, and ecosystem service functions. Device integration refers to the IIoT platform's integration of data from sensors, actuators, tags, and beacons, enabling seamless data communication between devices and managing their lifecycles. Data integration refers to the IIoT's ability to capture, integrate, and manage all data running on the platform. Process integration means that as part of a digital ecosystem, IoT solutions need to be embedded into business processes and workflows; therefore, the IIoT platform integrates business processes, workflow engines, and backend business systems onto a unified platform. Ecosystem services refer to the IIoT platform's responsibility for securely establishing, initiating, and managing trusted interactions between people, devices, data, and equipment within the digital ecosystem.

[0006] Process Management

[0007] The core of process management is the process itself. A process is an end-to-end operation, a set of interconnected activities that create value for customers and span across the organization. It is the foundation of business operations and drives the operation of the business.

[0008] As part of the digital ecosystem, the Internet of Things (IoT) can trigger process-related activities and cause changes in enterprise processes. This triggering occurs in the form of events, which in turn trigger the operation of process node activities.

[0009] The execution of process tasks needs to be completed around a series of users, roles, and organizational structures, and the constraints of security access management need to be fully considered.

[0010] Workflow software is a type of automated process management software. It primarily addresses the process of multiple participants transferring various documents, information, and tasks according to predetermined rules to achieve expected business goals. Specialized process models and symbols (such as flowcharts) can describe the connections and logical relationships between various nodes in the process system.

[0011] The interaction between process nodes and process tasks can be achieved through task listeners. In some popular workflow software, a Java class that inherits from the listener interface can be bound to implement the task listener logic.

[0012] Object Model Management

[0013] An object model refers to the digitization of physical entities in an IoT platform. An object model typically includes three parts of information:

[0014] (1) Attributes, the ability to read / set data, are mainly used to describe device status information. Attributes support Get / Set request methods, and application systems can initiate read and set requests for attributes.

[0015] (2) Service: The ability or method of a device that can be invoked externally. Input and output parameters can be set, indicating the ability of the current object model product to be invoked by the cloud. It is mainly used to describe the commands sent to the device and the responses. Compared with attributes, services can implement more complex business logic through a single instruction, such as executing a specific task.

[0016] (3) Events: Events that are actively reported to the cloud when the device is running. Events generally contain notification information that needs to be perceived and processed externally. They can contain multiple output parameters, such as information on the completion of a task, or the temperature when the device malfunctions or alarms. Events can be subscribed to and pushed.

[0017] The object model describes a digital abstraction of how to communicate with a device, describing what the device is, what it can do, and what services it can provide. When manipulating data, the object model's attribute interfaces, service interfaces, and event interfaces can be used to establish a mapping relationship with data in the physical space, and access can be achieved through interface calls.

[0018] Rule Engine

[0019] A rule engine is a crucial module in the Internet of Things (IoT). It's an engine for handling complex logic, evolved from inference engines, and is a component embedded in applications. It separates business decisions from application code, allowing business decisions to be written using predefined semantic modules. It accepts data input, interprets business rules, and makes business decisions based on those rules. It can communicate with the object model, access relevant data from the object model, and decouple the data logic of the object model from the application system.

[0020] Equipment linkage

[0021] Device linkage refers to the coordinated response of devices triggered by conditions and based on preset rules, enabling joint actions and intelligent control operations between devices. Device linkage is achieved through conditional forwarding, with trigger points potentially originating from device status data or twin data collected from lower-level devices within the system, or from inputs from upper-level applications. Device linkage enables mutual influence between multiple types of devices, and involves the rule engine sending action commands to the devices.

[0022] Edge computing

[0023] Edge computing, as opposed to traditional centralized general-purpose computing, refers to a method of deploying workloads at the edge. The background for edge computing is the increasing prevalence of 5G, IoT, and other services and scenarios, including the growing number of smart terminal devices. This has led to an explosive growth in the demand for edge-based service deployments. Bringing more computing closer to the edge can effectively reduce network load, lower costs, and improve efficiency. Summary of the Invention

[0024] The purpose of this invention is to provide a factory rule management platform. This platform maps business process model objects in a process system to virtual factory object models, maps related tasks and events in the process to methods and events in the object models, and combines the factory object models with the original equipment object models. It uses a rule engine to process business events, enabling the processing logic of business data originally deployed in the cloud to be implemented at the edge, and synchronizing object model configuration and data with the cloud, reducing cloud communication volume. It supports data linkage between equipment object models and process business models, realizing bidirectional linkage functions of equipment uploading to process equipment linkage and process-driven equipment linkage. Simultaneously, the use of the rule engine allows for customized process execution while maintaining the flexibility of the business system, reducing redundant development and flexibly meeting changes in business needs.

[0025] The object model proposed in this invention corresponds to the information of physical space in the Internet of Things business field. It uses features such as attributes, services, and events to describe the information and operation methods of related physical objects. Common models are generally associated with devices and describe the information and behavior of devices.

[0026] The process model proposed in this invention refers to the Internet of Things (IoT) as part of the digital ecosystem, which is linked to the production process activities of enterprises. The elements of this process activity include a process model and related events. The process model contains process information, activities, sub-processes, etc., and can describe the execution process of related processes using modeling methods such as flowcharts. It is an abstraction of real-world business processes. The information in the process model can be mapped to an object model, where related objects in the process model can be mapped to object model objects, the attributes of objects in the process model can be mapped to attributes of the object model, and the state transitions and event triggers of the process model can be mapped to attributes of the object model; the access interface of the process model can be mapped to the access interface of the object model.

[0027] This invention proposes a rule management platform for industrial object models. It provides a modeling platform, business rule conversion tools, and a rule engine. This platform can convert process models into object models with process business attributes within an industrial IoT platform, establishing a mapping between the process model and the object model. Simultaneously, it converts the corresponding process business methods into rules that the rule engine can read. Because the object model is related to the process business and has established a mapping relationship between business fields and business methods with the process model, we refer to this object model as a process object model. These rules can be executed by calling the object model interface through the rule engine, realizing the execution of existing process tasks and state migration. It provides tools and methods for edge devices to download process object models from the cloud and update them to the edge, enabling rapid changes and applications of corresponding process business rules. It supports the combination of process object models and ordinary equipment object models, as well as the linkage operation between IoT devices and process business. Device event generation and state changes can quickly trigger the execution of business processes. At the same time, changes in process data and the triggering of related business events can also be synchronized to the attributes, events, and service interfaces of the equipment object model, achieving bidirectional linkage between the equipment object model and business process objects.

[0028] This invention includes: 1) a process object modeling module (hereinafter referred to as the modeling module); 2) a process object model downloading module; 3) an equipment event reporting module; 4) a process database management module; 5) a process object model reading and writing module; 6) a process rule execution module; and 7) a process database synchronization module.

[0029] In terms of functional connectivity, the process object modeling module is generally deployed on the administrator's computer as a client, but it can also be deployed in the cloud or at the edge. It connects to the object model database in the cloud via a network communication interface, providing it to the administrator for use in managing information such as cloud object models, service configurations, and event configurations. Other modules of the system, including the process object model download module, the device event reporting process module, the process database management module, the process object model read / write module, the process rule execution module, and the process database synchronization module, are all deployed and run in the container service component on the device side at the edge. They are subject to the lifecycle of the container management software and communicate with each other through the RESTful service interface.

[0030] The process model download module uses standard HTTP. The RESTful interface accesses both the cloud database and edge database simultaneously, downloading the configured object model information from the cloud to the edge database. The process database management module, as a foundational module, connects to the local database on the edge, managing object model information, device information, service information, and event information. The process object model download module connects the cloud database and the edge database system via TCP / IP, synchronizing relevant cloud database configurations to the edge. The process database management module, as a foundational module, manages the edge database tables and the stored data of the process model and related object models. The process object model read / write module connects to the database management module, providing other applications with a data access interface to manipulate object model metadata. The main functions of modules such as the process device reporting module and the process rule execution module are to enable interactive applications between the process and the IoT system. These modules need to interact with the process object model read / write module and the process database management module to access the metadata and stored data of the process object model, read, write, and publish data in the process tables through the process object model interface, realizing the business interaction between the process system and the IoT platform. The process database synchronization module records changes to the local process object model and process data in real time, synchronizing this information to the cloud database promptly.

[0031] Functionally, the process object modeling module can scan the input of the flowchart, establish process object model information, process task rule templates, object model access permission information, and equipment linkage rule template information, and store this information in a cloud database. The process object model download module is responsible for downloading object model configuration data with process attributes, process task templates, object model permission information, and equipment linkage rule template information from the cloud database, and assigning trigger events to the execution of the corresponding process tasks, preparing for subsequent process rule execution. The process equipment reporting module directly triggers the execution of process tasks through the event interface of the equipment object model. The event contains equipment information, trigger parameters, and rule type information, which are then... The input rule engine combines information from the process object model to make judgments. The process database read / write module manages the underlying data access of the process object model. It configures a relational database at the edge, containing process configurations downloaded from the cloud and historical process data information of the current device. The corresponding process object model can be mapped to tables in the relational database, and the attribute data of the process object model is mapped to fields in the database entity tables. The process object model read / write module connects with the process database read / write module, providing external data interfaces to support service access. The process rule execution module connects with the device event reporting process module and the process object model read / write module, dynamically managing the execution of interaction rules and events between the device object model and the process object model triggered by process business. If the event is initiated by the process system, based on the event's input parameters, it reads the attributes and methods of the process object model, executes the process task, modifies the data of the process object model, and triggers the calculation of corresponding device linkage rules and statistical rules. If the event is reported by the device, based on the device parameters, device object model attribute information, and the mapping relationship between the device object model and the process object model, it converts the reported data into operations on the process data tables and generates corresponding process statistics. The process database synchronization module (hereinafter referred to as the synchronization module) dynamically detects data changes in the process object model and reports the process data and statistical data recorded at the edge to the cloud.

[0032] In this invention, the process object model is built using a process object modeling module. The main modeling content includes configuring process object model information, process object model attribute mapping information, equipment linkage rule template information, process task rule templates, organizational structure and permission information, etc. This information is stored in the cloud, and edge clients can download this information from the cloud database to the edge object model database. In addition to this information, the cloud database also contains process data tables and statistical data tables, which can be synchronized from the edge device database. Users can use this data for further analysis.

[0033] The process object model is an extension of the original object model. It uses process information as its core and expands the related database structure. In the original process system modeling, multiple process objects and multiple associated business objects are included. In the object model system, after adding the original business objects to the object model collection, business object model tagging information (Entity, Database, TableName, Primary-Key, TS-Field) can be added to all object models, and business association field tags can be added to the corresponding object model attributes.

[0034] (Property,

[0035] ContraintMap-Entity,MapField,

[0036] [DataType,NotNull,Comment,AutoIncrement,DefaultValue],

[0037] [Join-Type, Join-Condition],

[0038] [Match-Condition,Match-Function])

[0039] These two tuples are referred to as the object model information tuple and the attribute information tuple, respectively.

[0040] The tuple information (Entity, Database, TableName, Primary-Key, TS-Field) can be defined as process item model tuple information.

[0041] In the object model tuple, Entity represents the business entity object in the process, Database represents the database name of the corresponding real-time database / business database, TableName represents the data table stored in the process, Primary-Key represents the primary key field of the current business entity, and TS-Field represents the timestamp field in the process entity. CRUD and query access interfaces for process business objects can be implemented based on the primary key field and timestamp field, providing a process data access interface for the execution of the rule engine.

[0042] In the attribute information tuple, Property represents the attribute of the current object model, MapEntity is the mapped object model object, MapField is the mapped attribute, and Constraint represents the constraint condition of the current process field, which is used to determine the value constraint information of the current object model. The constraint type may be a foreign key constraint or an expression constraint.

[0043] Multiple business identifiers corresponding to the relationship model can be added to the attributes, including:

[0044] DataType: The business type of the attribute data.

[0045] NotNull: Whether the current field is not null.

[0046] Comment: Attribute annotation information, users can add custom descriptions to the attributes of the object model.

[0047] AutoIncrement: Whether the current property is an auto-incrementing field.

[0048] DefaultValue: The default value of the current attribute when the data is empty. This information can be a common constant value or a calculation formula, which can be used to calculate the default value of the current data based on other fields of the current object model.

[0049] The system supports two methods for data matching relationships between object model attributes: foreign key joins and data search condition relationships. The [Join-Type, Join-Condition] fields represent the mapping relationship between two object model attributes matched through a primary-foreign key relationship, while (Match-Condition, Match-Function) represent the method of searching attribute information and completing attribute data matching through matching conditions and matching functions. These two data mapping relationships are mutually exclusive; only one can be used at a time during configuration—either a foreign key join or a search condition relationship.

[0050] Join-Type represents the object connection type, which, referring to the database object connection type, is divided into four types:

[0051] (1) Left Outer Join: The execution rule of the left join is to return all rows of the corresponding process table of the left object model. If there is no matching row in the right table, the column of the result in the right table will return null values.

[0052] (2) Right outer join is the opposite of left join. It returns all rows in the table corresponding to the right object model. If there are no matching rows in the table corresponding to the right object model, the corresponding column in the table corresponding to the left object model will be null.

[0053] (3) Inner Join

[0054] An inner join returns only the records matched between two object model table objects based on the join condition.

[0055] (4) Fully Connected Full Outer Join

[0056] The execution rule for a full join is to return all rows that are related between the left and right object models. If either the left or right table has no related rows in the other object model's table, then the corresponding join field will be null.

[0057] Join-Condition represents the current join condition. By default, this join condition is usually an equation, which typically consists of the name of the current object model attribute and the primary key attribute field of the corresponding mapped object model. Custom expressions for matching field information can also be added to this join condition.

[0058] Match-Condition: Represents the condition for data matching. This condition is usually a formula that includes the name of the current attribute and the name of the matching attribute. If the matching condition returns True, the row will be matched.

[0059] Match-Function: Represents a data matching function. This function is an aggregate function that will perform aggregate calculations on all mapping fields that match the condition as true. Commonly used aggregate functions include Max, Min, Sum, Avg, First, and Last.

[0060] Device linkage rule templates are a common method for customizing the operation methods and services of IoT devices by triggering process tasks through templates. They are frequently seen in IoT platforms. However, in this invention, the device linkage rule template is configured with device linkage scripts and operation parameters, and the task listener of the process system is configured to associate with the device linkage method / service. When the process task is triggered, the rule template information, process task information and calling parameters are sent to the associated rule engine execution module for execution.

[0061] Process task rule templates are a method for customizing process tasks through templates. Specifically, they provide customized processing logic scripts for process object models, combined with process business identifiers from business object models, to enable customized data tasks for business object models, facilitating interaction between device object models and process object models. Depending on actual business needs, the system can incorporate various types of process rule processing templates to meet the requirements of customized process processing.

[0062] Organizational permissions are a crucial module in the workflow engine. All task nodes in the workflow are associated with relevant organizational organizations, and the execution of tasks at these nodes requires checking the permissions of the associated organizational organization. In this invention, there is no function to store organizational permission information. Instead, organizational permissions are obtained by checking the permission information of task nodes in the original workflow model through the association between the workflow object model and the workflow model. Access to attributes and data in the workflow object model also requires checking whether the corresponding workflow model has the relevant organizational organization's operational permission information. Historical data also includes corresponding information on operators and organizational organizations.

[0063] The method for adding process object models by scanning the flowchart is as follows: First, read the flowchart and data dictionary in the process system. First, identify the business information in the process object, including possible business entities, fields in each entity, and relationships between entities. Create object model objects, generating object model information tuples and attribute information tuples corresponding to the process model. Then, provide an interactive input screen to allow users to refine and supplement the business object model and related attribute information based on their business experience. Next, read the business activity swimlane information from the process. Each swimlane may belong to a specific user role or organizational structure. Then, based on this information, add user, role, organizational structure, and access permission information to the current object model object and attributes. Finally, for task nodes in the process, according to the process... The object model object adds an interactive input screen and allows selection of process rule templates for the current task. The corresponding rule engine template can be fine-tuned according to the specific needs of the process. The fine-tuned part appears in the form of a modified rule script. When applying the rule, the rule engine first reads the original rule part, then uses the rule logic of the modified part to change the original part and recompiles it. For the handling of the event listening part in the original process, the device linkage rule semantics of the object model are used for processing. The method is as follows: during the system initialization phase, the device linkage rule template is associated according to the type of the process listening class, ready to receive linkage signals at any time. When the linkage signal is triggered, the operation is also based on the device linkage type and parameter interface. The rule engine automatically calls the predefined device event interface to implement the linkage operation.

[0064] The process object model download module downloads process object models, process task templates, and device linkage rules from the cloud database to the edge device. This module updates the object model data of the current edge device system. Considering that processes may be continuously modified and changed during system use, version information needs to be added to the corresponding process object models, process task templates, and device linkage templates when configuring the process object models. When the process object models are downloaded to the edge device, the process version information is also downloaded to the edge device. The rule execution template on the edge device needs to retrieve the object model configuration, process task template, and device linkage template information that match the process version from the edge device database, and download them to the edge device via the TCP / IP network port to meet the requirements for rule triggering.

[0065] The device event reporting module is responsible for reporting changes in device object model data to the process object model, generating device events. When a device reports an event, it reads the association configuration between the device object model and the process object model based on the definitions of the device object model and the device event, combined with the triggering conditions of the process node. It then maps the device event data to the process object model and related data tables, and hands it over to the rule engine for execution.

[0066] In this module, the association between device events and process models can be achieved by establishing connection relationships between device object model attributes and process object attributes. The attributes of the device object model will establish connection relationships or data search relationships with the attributes of the process object model. Taking the connection relationship as an example, the connection relationship includes matching conditions for relevant attributes and timestamps. Based on these connection conditions, the mapping relationship between the process object model and relevant data tables, and the process rule template information, the corresponding object model attribute data can be injected into the rule template, dynamically generating SQL statements, script code, or other executable programs to execute the process. In short, this module can scan the input of device events one by one, call the rule engine to dynamically execute SQL scripts and corresponding rule templates, and the processed results are fed back to the device end through the device object model's attributes, services, and event interfaces.

[0067] The function of the process object model read / write module is to provide a general object model read / write interface for accessing the object model. At the lower level, it needs to call the process database management module to complete the read operation of the process database.

[0068] When writing the execution process object model, it is necessary to consider the batch execution data function and the transaction operation requirements when writing business data.

[0069] The method for reading the process object model is as follows: At the upper level, based on the input process object model attribute list and object model list, the data view of each process object model needs to be dynamically read. Then, based on the associated fields of the process business object model, a query plan is generated. The query plan refers to the execution plan of the SQL statement and follows the SQL92 language specification. Based on the mapping and association relationships between business entities, plus the data filtering and sorting conditions, a custom query view is generated, which can output the custom process object model data.

[0070] The process database management module (hereinafter referred to as the database module) is responsible for managing data access to the data tables corresponding to the process object models. It configures process data storage based on relational databases at the edge. The corresponding process object models can be mapped to tables in the relational database. Data access to the process object models will be mapped to data access to the database entity tables. Reading and writing data to the process object models is converted into SQL statements that operate the database for execution.

[0071] The process rule engine execution module is the core of the entire system, triggering processes and devices through the rule engine. The rule engine is triggered via events. It obtains customized processing logic scripts for process models by reading trigger parameters, business object model identifiers, device linkage rule templates, and process rule template identifiers from event records. These scripts are then executed, and execution records are saved in a local database. If new event records are generated during rule execution, the process rule engine will continue to execute the rules.

[0072] As mentioned in previous chapters, the generation of events for process rules can be accomplished through event listeners in the process system tasks. When the corresponding task in the process system is executed, the code of the corresponding Java event listener is triggered according to the device event type. The logic of this code is as follows: read the corresponding process node information and process object information of the process task, record the business object model identifier, process rule type, and process object association information through the object model management module and the process data management module, construct data query SQL and process rule information in the event, and dynamically generate process object model processing rule scripts through customized processing logic script templates for use by the process engine.

[0073] The process database synchronization module is responsible for dynamically detecting data changes in the process object model and reporting the process data and related statistics recorded at the edge to the cloud.

[0074] The innovative aspects of this invention:

[0075] This invention maps business process model objects in a process system to virtual factory object models, maps related tasks and events in the process to object model methods and events, and combines the factory object model with the original equipment object model. Combined with a rule engine, it realizes business event processing, enabling the processing logic of business data originally deployed in the cloud to be realized at the edge and quickly calculated and uploaded to the cloud, reducing the amount of communication in the cloud. At the same time, the use of the rule engine can realize the customization of process execution while ensuring the flexibility of the business system, reducing redundant development and flexibly meeting changes in business needs.

[0076] This invention provides a modeling platform and rule conversion tool that can convert process object models into object models with business attributes in the industrial field, referred to as process object models. It also converts corresponding business methods into rules that a rule engine can read, establishes mapping rules between process models and object models, and executes these rules through the rule engine to achieve process task execution and state transition. Furthermore, it provides tools and methods for edge devices to download and apply business object models for process applications from the cloud, enabling rapid changes and applications of business rules. The invention supports the combination of process business models and ordinary equipment object models, and supports the linkage operation between equipment object models and business object models. Equipment event generation and state changes can quickly trigger the execution of business processes. Attached Figure Description

[0077] Figure 1 Deploy a structure diagram for the process object model.

[0078] Figure 2 This is a flowchart for supporting quality assessment operations.

[0079] Figure 3 This is a structural diagram of the object model used for quality determination. Detailed Implementation

[0080] Figures 2-3 This is one specific embodiment of the present invention.

[0081] like Figure 1The diagram shows the deployment structure of the process object model. The system is deployed in three layers. The first layer is the client, deployed on the administrator's computer, which contains the process object modeling module. This module's main function is to model the process object model, and the corresponding model information and business rule mapping information are stored in a cloud database. The next layer is the cloud, which supports internet access. A database system is deployed in the cloud, providing the edge device with the ability to download model resources related to the process object model. It can also receive process business data and related statistical data calculated by the rule engine from the edge device. Related process application systems or web servers can be deployed in the cloud for process calculation and display. The final layer is the edge device, whose main function is to integrate the specific device object model and cloud object model data, and process events and rules. This includes object model download, device-reported processes, process rule execution, process database management, and object model read / write modules.

[0082] The characteristics of process object modeling are as follows: the functionality of process object modeling includes not only the process object model itself, but also configuration information such as equipment linkage rule templates, process task rule templates, organizational permission information, and equipment linkage rules. The process object model is the foundation of the current system, and the corresponding object model is oriented towards process business. During system implementation, it is based on a mature equipment object model platform currently on the market, and then the process business-oriented object model feature extensions of this invention are deployed on top of it, including information such as model tuples and attribute tuples. During the modeling process, the model, data dictionary, and heuristic business model settings already built by the process software are imported. This is because process modeling in process software is mostly process-oriented, and the data dictionary and business modeling process surrounding the process are often not very complete. Some business logic may need to be defined in the process screen and cannot be directly obtained, requiring the supplementation of relevant business field information, model association information, and constraint information.

[0083] In this invention, the processing of the business model is implemented at the edge. The system downloads the required object model, organizational structure and permission information, process task rule template information, and device linkage rule template information from the cloud to the edge. It fully considers the needs of flowchart version changes and dynamically records the configuration data of the required version at the edge for different process versions and business object model versions, which can agilely adapt to rapid changes in business and rules. The device reporting process module realizes the linkage between the device object model and the business object model. When the data of the device object model changes, an event is generated. At the same time, corresponding event listeners can be attached to the process task nodes, which can realize bidirectional linkage between device data and business data by combining the definition of the business object model.

[0084] The internal design of the rules engine establishes an adaptation between the device object model and the business object model, reducing the hard-coding steps in the system. The triggering of process tasks is accomplished through process rule templates and rule patches. The process rule templates are downloaded from the cloud, and rule patches are added at the edge to adapt them, avoiding frequent updates to the rule templates in the cloud and enabling the execution of business rules at the edge quickly. For rule changes at the edge, they can be uploaded to the cloud periodically through database synchronization, which can realize the synchronization of rule configurations between the cloud and the edge.

[0085] Additionally, edge devices can report business and statistical data to the cloud, using a combination of periodic and manual reporting methods. During uploads, a batch upload method is employed. For a certain amount of data, batch identifiers and data verification are added to the data packets before compression and transmission. Before uploading, a batch data packet identifier list is first sent, followed by sequential transmission according to the timestamp order of the data packets. If a data packet transmission fails, the upload is considered failed, and the system sets a failure attempt count or a delayed upload strategy to retransmit the data.

[0086] Cloud-based systems can develop data business data monitoring programs and visualize reports to display process data and statistical information from edge computing.

[0087] In addition, the processing of process task rules in this system is accomplished by creating task templates oriented towards the process object model. One approach is to port the task processing-related code from the original process system to the current system, appearing as related scripts and patches. This approach requires more development work, but the system has high execution efficiency and speed. Another approach is to create a process API access interface and encapsulate the service interface of the original process software. For example, most popular workflow software nowadays provides microservice access interfaces, and the interface adaptation module can be created in the rule engine according to the object model and the type of process task to meet the requirements.

[0088] like Figure 2 This is an implementation scheme for factory material model management applied to quality management. The corresponding business rules are: each time real-time measurement is performed, it is necessary to determine whether the workpiece is qualified. If it is unqualified, the workpiece is recycled to the scrap warehouse; if it is qualified, it is put into the finished goods warehouse. It is assumed that the real-time detection data is stored in the real-time database Real, and other business configuration and process configuration data are stored in the business database BI. The material models and attribute objects included in this scheme are:

[0089] (1) Workpiece Inspection Standard Model (TestStandard): This is a business configuration model containing the following attributes: Standard Number (Standard_Code), Weight Constraint (Weight_Contraint), Size Constraint (Size_Contraint), Rule (SpecCode), and Judgment Result (Result, with values ​​limited to the enumeration type OK / Failed). The information tuples defined on this model are:

[0090] (Entity:TestStandard,TableName:TestStandard,PrimaryKey:Standard_Code,TS-Field:null)

[0091] (2) TestModel, which includes the following property information: real-time measured workpiece number (Piece_No), weight (Weight), specifications (SpecCode), size (Size), and inspection time (TS). The information tuple corresponding to this equipment testmodel is:

[0092] (Entity:TestModel,Database:Real,TableName:TestModel,Primary-Key:ts,TS-Field:ts)

[0093] (3) Detection and Judgment (Judge), which is a process model that includes the following information: Test ID, PieceNo (sample number), SpecCode (sample specification), Standard_Code (inspection standard), Judge_Result (judgment result), TS: judgment time.

[0094] The information tuple corresponding to the equipment physical model is as follows:

[0095] (Entity:Judge,Database:BI,TableName:Judge,PrimaryKey:ID,TS-Field:ts

[0096] The attribute information tuple is:

[0097] [{Property:PieceNo,MapEntity:TestModel,MapField:PieceNo,JoinType:Left,JoinCondition:”Judge.PieceNo=TestModel.PieceNo”},

[0098] {Property:StandardCode:MapEntity:TestStandard,MapField:StandardCode,Match-Condition:”Judge.SpecCode=TestModel.SpecCode”,MatchFunction:”First”},{Property:Judge_Result:MapEntity:TestStandard,MapField:Result,

[0099] Match-Condition:”Judge.SpecCode=TestModel.SpecCodeand

[0100] match(TestModel.Size,TestStandard.SizeContraint)and match(TestModel.Weight,TestStandard.WeightConstraint)”,MatchFunction:”First”}]

[0101] In the matching criteria, `match` is a user-configured matching function used to perform a custom match based on the measured dimensions and weight information of the current test model, setting dimensional and weight constraints for the standard. The current solution's judgment criterion is that the test sample's specifications, dimensional matching, and weight matching all meet the requirements, resulting in the first judgment result that satisfies the judgment criteria.

[0102] (4) Waste Inbound

[0103] This is a process material model, containing the following material model fields: ID: Inbound ID, auto-incrementing type; PieceNo: Scrapped workpiece code; TS: Inbound time; SpecCode: Rule model; Weight: Weight information.

[0104] The object model information tuple is:

[0105] (Entity:WasteIn,Database:BI,TableName:WasteIn,PrimaryKey:ID,TS-Field:ts)

[0106] The attribute information tuple is:

[0107] [{Property:ID,AutoIncrement,true,NotNull,true},{Property:PieceNo,MapEntity:TestModel,MapField:PieceNo,JoinType:Left,JoinCondition:”WasteIn.PieceNo=TestModel.PieceNo”},

[0108] {Property:SpecCode:MapEntity:TestModel,MapField:SpecCode,Match-Condition:”WasteIn.SpecCode=TestModel.SpecCode”,MatchFunction:”First ”},{Property:Weight:MapEntity:TestModel,MapField:Weight,Match-Condition:”WasteIn.PieceNo=TestModel.PieceNo”,MatchFunction:”First”}]

[0109] (5) Finished Goods Inventory Model (ProductIn)

[0110] This is a process material model. The material model fields include: ID: Inbound ID (auto-incrementing type), PieceNo: Scrapped workpiece code, TS: Inbound time, SpecCode: Rule / model number, and Weight: Weight information.

[0111] The object model information tuple is:

[0112] (Entity:ProductIn,Database:BI,TableName:WasteIn,PrimaryKey:ID,TS-Field:ts)

[0113] The attribute information tuple is:

[0114] [{Property:ID,AutoIncrement,true,NotNull,true},{Property:PieceNo,MapEntity:TestModel,MapField:PieceNo,JoinType:Left,

[0115] JoinCondition:”ProductIn.PieceNo=TestModel.PieceNo”},

[0116] {Property:SpecCode:MapEntity:TestModel,MapField:SpecCode,Match-Condition:”WasteIn.SpecCode=TestModel.SpecCode”,MatchFunction:”First ”},{Property:Weight:MapEntity:TestModel,MapField:Weight,Match-Condition:”WasteIn.PieceNo=TestModel.PieceNo”,MatchFunction:”First”}]

[0117] The relationships between multiple object models can be achieved through... Figure 3 It is represented by a connection diagram.

[0118] The equipment process steps in this solution correspond to Figure 2 In the process flow's pass / fail judgment stage, for each input of inspection data, a script task needs to be introduced into the process system. This script task reads the process task rule information, the tuple definitions of the equipment object model and the process object model, the equipment definition, and the object model attribute definitions. Based on the judgment conditions and rules, it calculates the connection relationships between the object model and its attributes and executes the judgment result calculation. This judgment logic can be pre-configured as a process task rule template and executed immediately after each new workpiece inspection record is input. During execution, the system connects to the real-time database and relational database to read and write the corresponding model attribute data, triggering modifications to the corresponding process data, thus implementing the logic of the equipment reporting process.

Claims

1. A factory rule management platform, characterized in that, include: Process object modeling module, process object model download module, equipment event reporting module, process database management module, process object model read / write module, process rule execution module, and process database synchronization module; The process object modeling module is deployed as a client on the administrator's computer, or in the cloud and at the edge. It connects to the object model database in the cloud via a network communication interface, providing it to the administrator for use in managing information such as cloud object models, service configurations, and event configurations. The process object model download module, device event reporting module, process database management module, process object model read / write module, process rule execution module, and process database synchronization module are all deployed and run in the container service component on the device side at the edge. They are subject to lifecycle management by the container management software and communicate with each other through the RESTful service interface. The process object model download module accesses both the cloud database and the edge database simultaneously via a standard HTTP RESTful interface, downloading the configured object model information from the cloud to the edge database. The process database management module, as a foundational module, connects to the local database on the edge, managing object model information, device information, service information, and event information within the edge database. The process object model download module connects to the cloud database and the edge database system via TCP / IP, responsible for synchronizing relevant cloud database configurations to the edge. The process database management module, as a foundational module, is responsible for managing the edge database tables and the stored data of the process model and related object models. The process object model read / write module connects to the database management module, providing other applications with a data access interface for manipulating object model metadata. The device event reporting module and process rule execution module enable interactive applications between the process and the IoT system. These modules need to interact with the process object model read / write module and the process database management module to access the object model's metadata and stored data, read and write data through the mapping relationship between the process object model interface and process model data, and publish data in the process tables, thus realizing the business interaction process between the process system and the IoT platform. The process database synchronization module records changes to the local process object model and process data in real time and synchronizes this information to the cloud database promptly. The process object model modeling module scans the flowchart input, establishes process object model information, process task rule templates, object model access permission information, and device linkage rule template information, and stores this information in the cloud database. Within the database, the process object model download module is responsible for downloading object model configuration data with process attributes, process task templates, object model permission information, and device linkage rule template information from the cloud database, and assigning trigger events to the corresponding process tasks to prepare for subsequent process rule execution; the device event reporting process module directly triggers the execution of process tasks through the event interface of the device object model. The event contains device information, trigger parameters, and rule type information. This information is then input into the rule engine, which combines the information of the process object model to make a judgment; the database read and write module is responsible for managing the underlying data access of the process object model. It configures a relational database on the edge side, which contains process configurations downloaded from the cloud and historical process data information of the current device. The corresponding process object model can be mapped to tables in the relational database, and the attribute data of the process object model is mapped to the fields of the database entity table; The process object model read / write module and the database read / write module are connected, and a data interface that provides support service access is provided to the outside world. The process rule execution module is connected to the device event reporting process module and the process object model read / write module, and the dynamic management process business triggers the execution of interaction rules and events between the device object model and the process object model; If the event is initiated by the process system, the attributes and methods of the process object model are read according to the input parameters of the event, the process task is executed, the data of the process object model is changed, and the calculation of equipment linkage rules and statistical rules is triggered accordingly. If it is a device reporting process, the device reported data is converted into operations on the process data table based on the device parameters, device object model attribute information, and the mapping relationship between the device object model and the process object model, and the corresponding process statistics are generated. The process database synchronization module dynamically detects data changes in the process object model and reports the process data and statistics recorded at the edge to the cloud.

2. The factory rule management platform according to claim 1, characterized in that, Process task rule templates are a method for customizing process tasks through templates. Specifically, they provide customized processing logic scripts for process object models, combined with process business identifiers of business object models, to enable customized data tasks for business object models and facilitate interaction between device object models and process object models. Based on actual business needs, the system has built-in various types of process rule processing templates to meet the needs of customized process processing. The method of adding process object models by scanning the flowchart is as follows: First, read the flowchart and data dictionary in the process system. First, confirm the business information in the process object, what possible business entities there are, what fields each business entity has, and how the business entities are related. Then, provide an interactive input screen so that users can improve and supplement the business object model and related attribute information based on their business experience. Then, read the swimlane information of business activities from the process. Each swimlane may belong to a specific user role or organization information. Then, add user, role, organization and access permission information to the current object model management platform based on this information. Then, for task nodes in the process, based on the process object model object, add interactive input screens and select rule templates for the current process task. The corresponding rule engine template can be fine-tuned according to the special needs of the process. The fine-tuned part appears in the form of a modified rule script. When the rule engine applies the rule, it first reads the original rule part, then uses the rule logic of the modified part to change the original part and recompiles it. For the handling of the event listening part in the original process, the rule semantics of device linkage in the object model are used for processing. The method is as follows: during the system initialization phase, a corresponding device linkage processing template is created for backup based on the type of the process listening class. The corresponding template is implemented in the program as an event listener class similar to the original process software. This class accepts relevant linkage parameters and executes device linkage operations. The linkage operation is also implemented by the rule engine automatically calling the defined device event interface according to the device linkage type and parameter interface.

3. The factory rule management platform according to claim 1, characterized in that, The function of the process object model download module is to download the process object model, process task template and device linkage rules from the cloud database to the edge. This module will update the object model data of the current edge system. During system use, processes may be continuously modified. When configuring the process object model, version information needs to be added to the corresponding process object model, process task template, and device linkage rule template. When the process object model is downloaded to the edge device, the process version information is also downloaded to the edge device. The rule execution template on the edge device needs to retrieve the object model configuration, process task template, and device linkage rule template information that match the process version from the database on the edge device according to the different process versions, and download them to the edge device through the TCP / IP network port to meet the requirements of rule triggering.

4. The factory rule management platform according to claim 1, characterized in that, The device event reporting module is responsible for reporting changes in device object model data to the process object model, generating device events. When a device is reported, it reads the association configuration of the device object model and the process object model based on the definition of the device object model and the device event, combined with the triggering conditions of the process node, maps the device event data to the process object model and related data tables, and hands it over to the rule engine for execution. In the equipment event reporting module, the association between equipment events and process models is achieved by establishing connection relationships between equipment object model attributes and process object attributes. The attributes of the equipment object model establish connection relationships or data search relationships with the attributes of the process object model. These connection relationships include matching conditions for relevant attributes and timestamps. Based on these connection conditions, the mapping relationship between the process object model and relevant data tables, SQL statements or corresponding operation rules are dynamically generated. The rule engine can execute the corresponding SQL statements to execute the rules, or load predefined rule templates and inject the corresponding object model attribute data into the rule templates for dynamic processing. This module scans each device event input, calls the rule engine to dynamically execute SQL scripts and corresponding rule templates, and feeds back the processed results to the device through the device object model's attributes, services, and event interfaces.

5. The factory rule management platform according to claim 1, characterized in that, The function of the process object model read / write module is to provide a general object model read / write interface for accessing the object model. At the lower level, it needs to call the process database management module to complete the read operation of the process database. When writing the execution process object model, it is necessary to consider the batch execution data function, as well as the transaction operation requirements when writing business data. The method for reading the process object model is as follows: At the upper level, based on the input process object model attribute list and object model list, the data view of each process object model needs to be dynamically read. Then, based on the associated fields of the process business object model, a query plan is generated. The query plan refers to the execution plan of the SQL statement and follows the SQL92 language specification. Based on the mapping and association relationships between business entities, plus the data filtering and sorting conditions, a custom query view is generated, which can output the custom process object model data.

6. The factory rule management platform according to claim 1, characterized in that, The process database management module is responsible for managing data access to the data tables corresponding to the process object models. It configures process data storage based on relational databases at the edge. The corresponding process object models can be mapped to tables in the relational database. Data access to the process object models will be mapped to data access to the database entity tables. Reading and writing data to the process object models is converted into SQL statements that operate the database for execution.

7. The factory rule management platform according to claim 1, characterized in that, The process rule execution module is the core of the entire system. It triggers the execution of business logic through the rule engine. The rule engine is triggered by events. The rule engine obtains the customized process logic script of the process object model by reading the trigger parameters, business object model identifier, and process rule template identifier in the event record. It executes the script and saves the script execution record in the local database. If an event record is generated during the rule execution process, the process rule engine will continue to execute the rule. The generation of events for process rules is accomplished through event listeners in the process system tasks. When the corresponding task in the process system is executed, the code of the corresponding Java event listener is triggered. The logic of this code is as follows: read the corresponding process node information and process object information of the process task, record the business object model identifier, process rule type, and process object association information through the object model management module and process data management module, construct data query SQL and process rule information in the event, and dynamically generate process object model processing rule scripts through customized processing logic script templates for use by the process engine.

Images