Edge computing-based scheduling system

Abstract

The present application relates to an edge computing-based scheduling system. The scheduling system comprises: an edge server, deployed with an edge service deployment package that is used for providing application component mirror images deployed at an edge to collect data information of a production line device; and a cloud center server, connected to the edge server and used for receiving the data information of the production line device and constructing a digital twin model of the production line device on the basis of the data information, wherein the digital twin model is used for indicating transmission of a communication packet in the scheduling system. According to the system, the digital twin model is constructed on the basis of the data information of the production line device, and the communication packet is transmitted in the scheduling system on the basis of the digital twin model, so as to realize a virtual debugging scheme of a specific production line.

Description

Scheduling system based on edge computing Technical Field

[0001] The present application relates to the field of automation technology, and in particular to a scheduling system based on edge computing. Background Art

[0002] With the development of automation technology and the increasing trend of robots replacing human labor, technologies such as scheduling methods based on edge computing have emerged.

[0003] In traditional technologies, scheduling solutions are mainly based on deep learning for pattern recognition, followed by corresponding technical scheduling, and then the expansion of upper-level business based on the edge computing scheduling technology.

[0004] However, in the existing technology, virtual debugging technology is not designed in combination with the six-level BOM (Bill of Material) business model of actual production line equipment, nor does it implement the scalability support and workflow engine support of the edge cloud platform, nor does it combine the construction plan of the wireless self-organizing network to support the robustness of the scheduling system.

[0005] Summary of the Invention

[0006] Based on this, it is necessary to provide an edge computing-based scheduling system that can combine the business model of production line equipment to address the above technical problems.

[0007] This application provides a scheduling system based on edge computing, including:

[0008] Edge servers are deployed with edge service deployment packages, which are used to provide application component images deployed at the edge to collect data information from production line equipment.

[0009] The cloud center server is connected to the edge server and is used to receive data information from production line equipment and build a digital twin model of the production line equipment based on the data information; the digital twin model is used to instruct the transmission of communication messages in the scheduling system.

[0010] In one embodiment, the cloud center server is deployed with:

[0011] A connection component for receiving data information of production line equipment sent by the edge server;

[0012] The stream processing component is used to pre-process and distribute the data information of the production line equipment obtained through the connection component;

[0013] The behavior component is used to receive data distributed by the stream processing component, obtain behavior results, and generate motion information based on the behavior results;

[0014] The motion component is used to receive motion information and drive the corresponding three-dimensional model in the digital twin model based on the motion information.

[0015] In one embodiment, the behavioral component models the behavior of the production line equipment by using a finite state machine, which includes a state set and an instruction set, wherein the state set includes behavioral state information of the production line equipment and the instruction set includes instruction information received by the production line equipment.

[0016] In one embodiment, the edge service deployment package includes an application component, which is used to deploy device applications based on data information of production line devices, and the device applications correspond one-to-one to the devices in the production line;

[0017] Digital twin models are used to indicate the communication between device applications.

[0018] In one embodiment, the scheduling system further includes a file server for storing equipment processing program files of the production line equipment;

[0019] The edge server is deployed with a workflow control component, which communicates with the production line equipment through the edge message bus and communicates with the electronic manufacturing system EMS through the message bus.

[0020] In one embodiment, the digital twin model is a multi-level BOM model constructed based on the digital twin model file of each production line equipment;

[0021] The digital twin model file includes attribute information file and node relationship information file;

[0022] The attribute information file is an AML file, and the node relationship information file is a Neo4j file.

[0023] In one embodiment, the attribute information recorded in the attribute information file includes the main information corresponding to each level of BOM model, the sub-element information corresponding to each level of BOM model, the interface information corresponding to each level of BOM model, the role information corresponding to each level of BOM model, and the parameter information corresponding to each level of BOM model.

[0024] In one embodiment, the levels of the multi-level BOM model are, from bottom to top, parts level, equipment level, production line level, area level, workshop level, and factory level.

[0025] In one embodiment, the communication message carries at least one of BOM information, basic information, time information, and security information;

[0026] Among them, BOM information includes model information, input information, output information and interface information of the target object in the current layer BOM model; basic information includes the sending time and receiving time of the message; time information includes triggering events, and triggering time includes interface group information; security information includes token and decoding form.

[0027] In one embodiment, a digital twin model is used to indicate the communication between BOMs at different levels.

[0028] The aforementioned edge computing-based scheduling system includes an edge server deployed with an edge service deployment package that provides edge-deployed application component images to collect data from production line equipment; a cloud center server connected to the edge server that receives data from production line equipment and builds digital twin models of these equipment based on this data; and the digital twin models that instruct the transmission of communication messages within the scheduling system. By building digital twin models based on production line equipment data and transmitting communication messages within the scheduling system based on these digital twin models, a virtual commissioning solution for a specific production line can be implemented. BRIEF DESCRIPTION OF THE DRAWINGS

[0029] In order to more clearly illustrate the technical solutions in the embodiments of the present application or related technologies, the following briefly introduces the drawings required for use in the embodiments or related technical descriptions. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0030] FIG1 is a schematic diagram of the architecture of a scheduling system based on edge computing in one embodiment;

[0031] FIG2 is a schematic diagram of the architecture of an edge service deployment package in one embodiment;

[0032] FIG3 is a schematic diagram of components deployed by a cloud center server in one embodiment;

[0033] FIG4 is a schematic diagram of a process for implementing digital twin display in one embodiment;

[0034] FIG5 is a schematic diagram of status information and instruction information of a device in one embodiment;

[0035] FIG6 is a schematic diagram of the composition of an AML file in one embodiment;

[0036] FIG7 is a schematic diagram of the hierarchical structure of a six-level BOM in one embodiment;

[0037] FIG8 is a schematic diagram of the communication process of the edge server in one embodiment;

[0038] FIG9 is a schematic diagram of a communication message structure in one embodiment;

[0039] FIG10 is a schematic diagram of the composition of an AML file in simplified dimensions according to an embodiment;

[0040] FIG11 is a schematic diagram of the composition of a factory-level AML in one embodiment;

[0041] FIG12 is a simplified flow diagram of a factory-level AML composition process according to one embodiment;

[0042] FIG13 is a schematic diagram of the horizontal relationship and collaborative relationship between parts, equipment, and production lines in one embodiment;

[0043] FIG14 is a schematic diagram of a digital twin modeling scheme in one embodiment;

[0044] FIG15 is a schematic diagram of the application process of a grounded digital twin in one embodiment;

[0045] FIG16 is a schematic diagram of the architecture of an edge service deployment package in another embodiment;

[0046] FIG17 is a schematic diagram of cloud native technology support in one embodiment;

[0047] FIG18 is a schematic diagram illustrating the composition of a cloud component library and the deployment and operation of basic AI components and heterogeneous computing components in one embodiment;

[0048] FIG19 is a schematic diagram of components required for component modeling in one embodiment;

[0049] FIG20 is a schematic diagram of the overall process route for a single production in one embodiment;

[0050] FIG21 is a schematic diagram of a production line constructed based on the process route of FIG20 in one embodiment;

[0051] FIG22 is a schematic diagram of the overall process route of a production line constructed in one embodiment;

[0052] FIG23 is a schematic diagram of a Zeebe system in one embodiment. DETAILED DESCRIPTION

[0053] In order to make the purpose, technical solutions and advantages of this application more clear, the following further describes this application in detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are only used to explain this application and are not intended to limit this application.

[0054] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0055] It is understood that terms such as "first" and "second" in this application are only used to distinguish similar objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number of the indicated technical features.

[0056] It can be understood that the “connection” in the following embodiments should be understood as “electrical connection”, “communication connection”, etc. if there is transmission of electrical signals or data between the connected circuits, modules, units, etc.

[0057] It will be understood that "at least one" means one or more, and "a plurality of" means two or more.

[0058] As used herein, the singular forms "a," "an," and "the" may also include the plural forms, unless the context clearly indicates otherwise. It should also be understood that the terms "include," "comprising," "having," and the like specify the presence of stated features, integers, steps, operations, components, parts, or combinations thereof, but do not preclude the presence or addition of one or more other features, integers, steps, operations, components, parts, or combinations thereof. Furthermore, the term "and / or" as used in this specification includes any and all combinations of the relevant listed items.

[0059] In an exemplary embodiment, as shown in FIG1 , a scheduling system based on edge computing is provided, including:

[0060] Edge servers are deployed with edge service deployment packages, which are used to provide application component images deployed at the edge to collect data information from production line equipment.

[0061] The cloud center server is connected to the edge server and is used to receive data information from production line equipment and build a digital twin model of the production line equipment based on the data information; the digital twin model is used to instruct the transmission of communication messages in the scheduling system.

[0062] Specifically, the scheduling system is implemented based on the edge-cloud architecture, in which the components of the edge-cloud architecture are mainly divided into the edge and the cloud. For example, the cloud can be a cloud center server, responsible for building the algorithm library and the digital twin application group, as well as packaging and issuing edge application packages. The edge can be an edge server, responsible for deploying edge applications to support the construction of the digital twin system (digital twin model). Optionally, containerization technology is also used in the edge-cloud architecture to provide support for the deployment of applications through containerization technology.

[0063] Specifically, Docker is an open-source application container engine that allows developers to uniformly package their applications and their dependencies into portable containers. These containers can then be deployed to any server with the Docker engine installed (including popular Linux and Windows machines), enabling virtualization. Containers are fully sandboxed, with no interfaces between them and virtually no performance overhead, making them easy to run on machines and in data centers. Most importantly, they are independent of any language, framework, or operating system.

[0064] Optionally, the edge server is based on EdgeX Foundry technology as the basic support for the edge server. In a specific embodiment, as shown in FIG2 , the architecture of the edge service deployment package designed based on EdgeX as the basic architecture includes:

[0065] The system basic service group is used to support the construction of basic modules.

[0066] Deployment configuration group, used to configure deployment parameters.

[0067] Basic configuration group, used for Docker's running installation package and script support.

[0068] Application image groups are used to provide images of all application components deployed on the edge.

[0069] In one embodiment, as shown in FIG3 , the cloud center server is deployed with:

[0070] A connection component for receiving data information of production line equipment sent by the edge server;

[0071] The stream processing component is used to pre-process and distribute the data information of the production line equipment obtained through the connection component;

[0072] The behavior component is used to receive data distributed by the stream processing component, obtain behavior results, and generate motion information based on the behavior results;

[0073] The motion component is used to receive motion information and drive the corresponding three-dimensional model in the digital twin model based on the motion information.

[0074] Specifically, to implement a digital twin display design based on raw data collected by edge servers, the design process shown in Figure 4 can be adopted: For raw data, the digital twin model is obtained through data collection, stream processing, component modeling, and data application. Optionally, after component modeling, a front-end display can also be performed.

[0075] The connection component connects to the connection components in the edge servers and collects raw data from them. Data collected by the connection component is preprocessed and distributed by the streaming component. The behavior component then models the data to form a behavior model at the BOM level. The behavior model data is then modeled by the motion component to implement BOM-level motion modeling. Optionally, the raw data is forwarded via RabbitMQ, stream-processed at the ekuiper level, and forwarded again to the behavior model. Ultimately, the motion model is used to construct and display a digital twin of the data.

[0076] In a specific embodiment, the streaming component can be a streaming processing engine (ekuiper). LF Edge eKuiper is a lightweight IoT edge analytics and streaming processing open source software implemented in Golang that can run on various resource-constrained edge devices. The main goal of eKuiper is to provide a streaming software framework (similar to Apache Flink) at the edge. eKuiper's rule engine allows users to provide SQL-based or graph-based (similar to Node-RED) rules to create IoT edge analytics applications in minutes.

[0077] In one embodiment, the behavioral component models the behavior of the production line equipment by using a finite state machine, which includes a state set and an instruction set, wherein the state set includes behavioral state information of the production line equipment and the instruction set includes instruction information received by the production line equipment.

[0078] Finite state machines (FSMs, or FSAs), also known as state machines or finite state automata, are computational models abstracted for studying computational processes with limited memory and certain language classes. A finite state automaton has a finite number of states, each of which can transition to zero or more states. The input string determines which state transition is executed. A finite state automaton can be represented as a directed graph. Finite state automata are the subject of automata theory.

[0079] For example, a finite state machine is used to model the specific behavior of a device, wherein the behavior of the device is defined as a behavior state group and the instructions of the device are defined as an instruction group. Based on the above definition, the behavior modeling work can be performed.

[0080] Specifically, the state machine includes a state set and an instruction set. The state set includes the behavioral state information of the production line equipment, and the instruction set includes the instruction information received by the production line equipment. In an exemplary device, as shown in Figure 5, the device's behavioral state information may include behavioral states such as preparation, loading, unloading, and completion, while the instruction information may include instructions such as loading instructions, unloading instructions, completion instructions, reloading instructions, and shutdown instructions.

[0081] In one embodiment, the digital twin model is a multi-level BOM model constructed based on the digital twin model file of each production line equipment.

[0082] The digital twin model file includes attribute information file and node relationship information file;

[0083] The attribute information file is an AML file, and the node relationship information file is a Neo4j file.

[0084] Specifically, BOM (Bill of Material) can be a bill of materials, that is, a file that describes the product structure in a data format. It is a product structure data file that can be recognized by a computer and is also the dominant file of ERP (Enterprise Resource Planning). BOM enables the system to identify the product structure and is also the link for connecting and communicating various business operations of the enterprise. The types of BOM in the ERP system mainly include 5 categories: indented BOM, summarized BOM, reverse-check BOM, cost BOM, and planned BOM. In the embodiment of the present application, BOM can also be used as a general term for hardware equipment at various levels such as materials, equipment, and products.

[0085] The digital twin model file can be a file containing information describing the production line equipment, constructed based on the BOM structure of the actual production line equipment. In the embodiment of the present application, the digital twin model file can include an attribute information file and a node relationship information file. For example, the attribute information file can be an AML file, and the node relationship information file can be a Neo4j file.

[0086] Specifically, AML, or Automation Markup Language, is an XML-based data exchange format for factory engineering data. AML is primarily designed to support data exchange between heterogeneous engineering equipment. Its goal is to interconnect data across diverse fields, such as mechanical engineering design, electrical design, process engineering, process control engineering, HMI (Human-Machine Interface), PLC (Programmable Logic Controller) programming, and robotics programming. It can be applied to all industrial sectors requiring data exchange, such as discrete and process industries. Graph Database (Neo4j): Neo is a network-oriented database—that is, an embedded, disk-based, fully transactional Java persistence engine—but it stores structured data on the network rather than in tables. Networks (or graphs, in mathematical terms) are flexible data structures that enable more agile and rapid development models. They support not only graph-like data representation but also graph-derived features, such as searching clusters of nodes based on relevance.

[0087] For example, the AML file structure is shown in Figure 6, where AML is used to define the attributes and capabilities of each level of BOM. AutomationML is used to describe each level of BOM, and attribute information includes subject information, sub-element information, interface information, role information, and parameter information. Specifically, attribute information corresponds to the following modules of the AutomationML language (see the table below), corresponding to the categories and functions in the table below. Among them, InstanceHierarchy corresponds to subject information; InternalElement corresponds to sub-element information; Interface corresponds to interface information; Role corresponds to role information; and Attribute corresponds to parameter information.

[0088] In one embodiment, the levels of the multi-level BOM model are, from bottom to top, parts level, equipment level, production line level, area level, workshop level, and factory level.

[0089] The bottom layer of the six-level BOM hierarchy defined in the embodiment of the present application is the parts layer, as shown in Figure 7, from bottom to top are the parts layer, equipment layer, production line layer, area layer, workshop layer and factory layer. Among them, multiple parts constitute a device, multiple devices constitute a production line, multiple production lines belong to the same area (constituting an area), multiple areas belong to the same workshop (constituting a workshop), and multiple workshops constitute a factory. The BOMs between the same levels can also include horizontal relationships and connection relationships. For example, there can be an assembly relationship between multiple parts, and there can be a collaborative relationship between multiple devices. In the digital twin model, each BOM corresponds to a node, and the relationship information between nodes can be described using Neo4j.

[0090] In one embodiment, the attribute information recorded in the attribute information file includes the main information corresponding to each level of BOM model, the sub-element information corresponding to each level of BOM model, the interface information corresponding to each level of BOM model, the role information corresponding to each level of BOM model, and the parameter information corresponding to each level of BOM model.

[0091] Taking the six-level BOM hierarchy defined in the embodiments of this application as an example, from bottom to top, they are the parts level, equipment level, production line level, regional level, workshop level, and factory level. Taking the attribute information file as an AML file as an example, the attribute information file records the main information, sub-element information, interface information, role information, and parameter information of each BOM model at the six levels.

[0092] In one embodiment, the edge service deployment package includes an application component, which is used to deploy device applications based on data information of production line devices, and the device applications correspond one-to-one to the devices in the production line;

[0093] Digital twin models are used to indicate the communication between device applications.

[0094] Specifically, the device serves as the carrier point of the basic report in the communication system, that is, the sender and receiver of the message. Therefore, the constructed communication system has specific device applications in the edge deployment package, and the device applications correspond one-to-one to the devices in the production line. Specifically, the embodiment of the present application uses the device level as the component unit to realize the generation of the deployment package of the edge component package. By collecting the raw data of the equipment in the production line in real time, the device application is constructed and the communication between the driving device applications is generated. Specifically, the device component can also be called the BOM component, which exists as an application component and is configured with a corresponding AutomationML file. Optionally, the component package can be designed through the attributes of the BOM at all levels. The digital twin model is constructed based on the sub-element group and attribute group of the AutomationML file of the BOM and the relationship support provided by the graph database Neo4j. In this construction process, the specifications of EdgeX, docker and K8s are integrated. The digital twin model is used to indicate the communication between device applications. For example, the communication between device applications relies on a unified communication message format.

[0095] In one embodiment, a digital twin model is used to indicate the communication between BOMs at different levels.

[0096] Specifically, AutomationML modeling of equipment enables cross-level communication, such as between the component level and the production line level. For example, a common scenario involves triggering a production line stop in the event of a core component failure.

[0097] In one embodiment, the scheduling system further includes a file server for storing equipment processing program files of the production line equipment;

[0098] The edge server is deployed with a workflow control component, which communicates with the production line equipment through the edge message bus and communicates with the electronic manufacturing system EMS through the message bus.

[0099] Specifically, as shown in Figure 8, the edge server (i.e., edge system) is deployed with a workflow control component that communicates with production line equipment via the edge message bus (Rabbit MQ). Optionally, the workflow control component communicates with the device component in the edge server, and the device component corresponds one-to-one with the equipment in the actual production line and communicates with them.

[0100] Furthermore, the workflow control component communicates with the electronic manufacturing system (EMS) via a message bus (Rabbit MQ), receiving process flow information from the EMS and subscribing to real-time process parameters and quality data. The EMS is also known as an intelligent flexible production system. Optionally, the EMS communicates with the workflow control component via a publish-subscribe SDK (Software Development Kit).

[0101] In one embodiment, the communication message carries at least one of BOM information, basic information, time information, and security information;

[0102] Among them, BOM information includes model information, input information, output information and interface information of the target object in the current layer BOM model; basic information includes the sending time and receiving time of the message; time information includes triggering events, and triggering time includes interface group information; security information includes token and decoding form.

[0103] In message communication, the sender organizes the information to be transmitted into a specific format and encapsulates it within a message. Specifically, the structure of the communication message can be expanded based on the aforementioned digital twin model. As shown in Figure 9, a communication message can carry BOM information, basic information, time information, and security information. Specifically, the dashed lines in the figure represent inclusion relationships. For example, basic information includes input information, output information, and interface information. For example, for a motor's interface information, its core interface is a switch. The input is the on / off information of the switch button, and the output is the motor's rotation information. The relationship between trigger events and interface groups is as follows: for example, if you click "Off" in the interface group, the motor turns off, and motor shutdown is an event. A model instance refers to a device. After modeling through the digital twin, it becomes a specific device model information. For example, if the device is a motor, the relevant information such as the manufacturer, model, production date, and batch number will be included, as well as its threshold and status information. For example, if the actual operating hours are 10,000, but the actual operating hours are 7,000, this instance refers to its actual information.

[0104] In order to further illustrate the solution of the embodiment of the present application, a specific example is given below to illustrate that a data twin model of the factory is constructed based on the six-level BOM system as shown in Figure 7, and then a virtual debugging solution is implemented based on discrete event simulation technology, normalized BOM model, process engine technology and discrete event simulation technology, thereby realizing its derived business flow.

[0105] The main process is as follows:

[0106] (1) Define the attributes and capabilities of each level of BOM using AML. Specifically, use AML to describe parts, equipment, production lines, regions, workshops, and factories in sequence. Based on the above definition of the AML description of each level of BOM, the second step is to simplify the description of the AML language and simplify the AML description of each level of BOM into attributes and sub-element groups, so that a single AML can describe the entire factory.

[0107] As shown in Figure 10, the simplified AML file structure is actually divided into attribute groups and sub-element groups. Therefore, the description of each level of BOM using AML and the final factory-level AML structure are shown in Figures 11 and 12.

[0108] (2) Component relationships described based on the graph database Neo4j. Specifically, the AutomationML language can only describe the hierarchical relationships and attribute relationships of a six-level BOM, but it is difficult to provide an intuitive description of the horizontal relationships. Therefore, this round introduces the graph database Neo4j. The BOM structure composed of the graph database Neo4j can not only reflect the combination relationship of the previous layer to the next layer, but also reflect the assembly relationship between components.

[0109] As shown in Figure 13, multiple parts within a device actually have assembly relationships between them, such as between Part 1, Part 2, and Part 3. Furthermore, for devices, there are collaboration relationships between Device 1, Device 2, and Device 3. These horizontal relationships can be represented using Neo4j graphs.

[0110] As shown in Figure 14, through the above approach, AutomationML combines with the six-level BOM and the graph database technology Neo4j to implement a digital twin modeling solution. For any BOM, a presentation method is provided. The first is the AML (AutomationML) file, and the second is the nodes and relationships in Neo4j. Taking equipment as an example, the final application process for implementing a digital twin is shown in Figure 15. AutomationML is the foundation of industrial modeling languages, but it is not a commonly used industrial modeling system because the existing IIoT system is imperfect and has not yet been widely used as a foundation for industrial modeling. Graph databases, as the foundation of graphical display, demonstrate their advanced capabilities by intuitively displaying node hierarchical relationships and subsequent linked nodes. This seamlessly integrates with the BOM concept of existing industrial systems. This integration of these concepts forms the overall foundation of the digital twin system and forms the key core system.

[0111] (3) The architectural composition of the edge cloud. Specifically, for a digital twin model built based on the six-level BOM system, a complete edge cloud architecture needs to be built. The composition of the edge cloud architecture is mainly divided into the edge and the cloud. For example, the cloud can be a cloud center server, which is responsible for building the algorithm library and the digital twin application group, as well as packaging and issuing edge application packages. The edge can be an edge server, which is responsible for deploying edge applications to support the construction of the digital twin system (digital twin model). Optionally, containerization technology is also used in the edge cloud architecture to provide support for the deployment of applications through containerization technology.

[0112] Specifically, Docker is an open-source application container engine that allows developers to uniformly package their applications and their dependencies into portable containers. These containers can then be deployed to any server with the Docker engine installed (including popular Linux and Windows machines), enabling virtualization. Containers are fully sandboxed, with no interfaces between them and virtually no performance overhead, making them easy to run on machines and in data centers. Most importantly, they are independent of any language, framework, or operating system.

[0113] Because edge servers require EdgeX Foundry technology as their foundational support, in one embodiment, the architecture of an edge service deployment package designed based on EdgeX is shown in Figure 16. The system foundation service group supports the construction of basic modules. The deployment configuration group configures deployment parameters. The basic configuration group provides support for Docker installation packages and scripts. The application image group provides images for all application components deployed on the edge.

[0114] Furthermore, as shown in Figure 17, the cloud center server is equipped with cloud-native technology support. Cloud-native technology provides stability and scalability, and Harbor technology supports the composition of component libraries based on the six-level BOM, as well as providing other support. Among them, stability technology, cluster management and monitoring performed by Kubernetes ensure the stability of individual applications. Scalability technology, Kubernetes supports dynamic application expansion. Component library technology, Harbor provides support for component library construction. Other technologies include container management and monitoring.

[0115] (4) Component library composition and component design scheme of six-level BOM. Specifically, the embodiment of the present application uses the device level as the component unit to realize the deployment package generation of the edge component package. Based on the specification support of EdgeX, Docker and K8s, and the digital twin modeling solution based on AutomationML combined with the six-level BOM and the graph database technology Neo4j, the digital twin application (device application) corresponding to the device is realized in the edge server. The design scheme of the component package is carried out through the attributes of the BOM at each level. The digital twin application is constructed based on the sub-element group and attribute group of the AutomationML file of the BOM and the relationship support provided by the graph database Neo4j. In this construction process, the specifications of EdgeX, docker and K8s are integrated.

[0116] Furthermore, an AI integrated component design solution is used. This AI component design solution demonstrates the AI ​​support capabilities within the edge system. Heterogeneous computing components (GPU computing components) are used for heterogeneous support. Figure 18 shows the composition of a cloud component library and the deployment and operation of basic AI components and heterogeneous computing components. This solution demonstrates the integrated edge-cloud heterogeneous computing capabilities by performing training in the cloud, running predictions on the edge, and distributing model and configuration files to the edge-cloud.

[0117] After AI components are deployed at the edge, they provide prediction capabilities. Based on the aforementioned model, multiple edge components can be AI-enabled, enabling cloud-based training and edge-based prediction. Because the cloud has more resources, it can store data, while the edge loads data models. This simple loading and prediction process at the edge reduces resource usage. The edge's data collection and upload provides in-depth support for data retraining in the cloud, enabling model refinement. This collaborative effort between the cloud and edge enables more accurate AI predictions and self-improvement capabilities.

[0118] (5) Digital twin display scheme based on component modeling. Specifically, in order to realize the design of digital twin display, it is necessary to adopt the most simplified design process shown in Figure 4. As shown in Figure 5, component modeling requires the use of three components: behavior modeling, stream processing engine (ekuiper), and motion modeling. Among them, the stream processing engine (ekuiper) performs data preprocessing and realizes data forwarding, secondary forwarding and other functions. Motion modeling uses the motion model to display the motion mechanism data of the component to support the display of the front-end page and support the upper-level applications based on the motion model, such as interference detection. Behavior modeling uses the behavior model to display the behavior mechanism data of the component to support the upper-level applications based on the behavior model, such as virtual debugging based on work steps. The data flow process of the simplest digital twin scheme based on motion model and behavior model is shown in Figure 3. The data is collected through the connection component, preprocessed and distributed by the stream processing component, and then modeled by the behavior component to form a behavior model at the BOM level. The behavior model data is modeled through the motion component to realize the motion modeling at the BOM level. Optionally, the original data is forwarded through RabbitMQ, the data is stream processed at the Ekuiper level, and the data is forwarded to the behavior model again, and the digital twin of the data is finally constructed and displayed with the motion model.

[0119] The specific behavior of the device is modeled using a finite state machine (FSM), where the device's behavior is defined as a behavior state group and the device's instructions are defined as an instruction group. Based on the above definitions, the behavior modeling work can be carried out.

[0120] The purpose of motion modeling is to make the motion state of the BOM visible. Through this visibility, the motion function construction of the component is provided for visualization, and the three-dimensional spatial construction of the motion twin is realized, ultimately achieving the three-dimensional spatial construction of the production line to support derivative businesses. The goal of motion modeling is to ultimately provide the construction of motion models. Based on industrial mechanisms, motion models can be divided into four main types:

[0121] Linear motion: forward and backward movement in a straight line, but not pure uniform motion;

[0122] Curvilinear motion: Curvilinear motion that follows a linear motion trajectory;

[0123] Axis motion: a motion pattern based on a fixed rotation axis;

[0124] Cylinder motion: motion based on a cylinder, such as piston motion;

[0125] Other sports: Sports other than the above sports modes.

[0126] At this point, the above solution can be used to construct and implement the digital twin (digital twin model) of the six-level BOM.

[0127] (6) Digital twin and scheduling system modeling. For example, as shown in Figure 20, the overall process route for producing a car at a time is: floor section, body section, assembly section, and door cover section. The corresponding process route construction production line is shown in Figure 21. Furthermore, the overall process route of the constructed production line is shown in Figure 22.

[0128] (7) Message design for the digital twin system. Specifically, the structure of the communication message can be expanded based on the above-mentioned digital twin model. As shown in Figure 9, the communication message can carry BOM information, basic information, time information and security information. Specifically, the dotted line in the figure refers to the inclusion relationship. For example, the basic information includes input information, output information and interface information. For example, the interface information of the motor, its core interface is a switch. The input is the start / stop information of a switch button, and the output is the rotation information of the motor. The relationship between the trigger event and the interface group is that, for example, if you click on the off button in the interface group, the motor will be turned off. The motor turning off is an event. The model instance refers to: a device, after being modeled by the digital twin, is a specific device model information. For example, if this device is a motor, the relevant manufacturer, model, production date, batch, etc. of the motor will be added, and it will have its threshold and status information. For example, its actual quota is 10,000 working hours, and it has actually worked for 7,000 hours. This instance refers to its real information.

[0129] (8) Scheduling system. The scheduling system is a transmission carrier for messages and a solution for implementing services. For example, the present embodiment uses Zeebe to design a system scheduling solution. The Zeebe system solution is shown in Figure 23. The message system is combined with the scheduling system to form an overall communication system.

[0130] For example, using an automobile body-in-white production line as an example, the overall scheduling solution flow is shown in Figure 8. The edge server (i.e., edge system) is deployed with a workflow control component, which communicates with production line equipment via the edge message bus (Rabbit MQ). Optionally, the workflow control component communicates with the device component in the edge server, which corresponds one-to-one with the equipment on the actual production line and communicates with them.

[0131] Furthermore, the workflow control component communicates with the electronic manufacturing system (EMS) via a message bus (Rabbit MQ), receiving process flow information from the EMS and subscribing to real-time process parameters and quality data. The EMS is also known as an intelligent flexible production system. Optionally, the EMS communicates with the workflow control component via a publish-subscribe SDK (Software Development Kit).

[0132] The above technologies ultimately form an overall scheduling solution system based on the six-level BOM model, supporting existing intelligent technology solutions. The scheduling system provided in the embodiment of this application combines the six-level BOM model and the BOM normalization communication system implemented based on AutomationML, as well as the use of process engine technology. The scalability of the overall system and the business scope that the scheduling solution can support have been greatly improved. Thereby supporting more scalable businesses (flexible intelligent production line construction system based on the scheduling solution, adaptive beat system based on the scheduling solution, etc.).

[0133] It should be understood that, although the various steps in the flowcharts involved in the various embodiments described above are displayed in sequence according to the instructions of the arrows, these steps are not necessarily executed in sequence 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 the flowcharts involved in the various embodiments described above can include multiple steps or multiple stages, and these steps or stages are not necessarily executed and completed at the same time, but can be executed at different times, and 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.

[0134] Those skilled in the art will appreciate that all or part of the processes in the above-mentioned embodiment methods can be implemented 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 the processes of the embodiments of the above-mentioned methods. Among them, any reference to memory, database or other media used in the 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, optical memory, high-density embedded non-volatile memory, resistive random access memory (ReRAM), magnetic random access memory (MRAM), ferroelectric random access memory (FRAM), phase change memory (PCM), graphene memory, etc. Volatile memory may include random access memory (RAM) or external cache memory, etc. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM). The database involved in the various embodiments provided herein may include at least one of a relational database and a non-relational database. Non-relational databases may include, but are not limited to, distributed databases based on blockchains. The processor involved in the various embodiments provided herein may be, but are not limited to, a general-purpose processor, a central processing unit, a graphics processing unit, a digital signal processor, a programmable logic unit, a data processing logic unit based on quantum computing, and the like.

[0135] The technical features of the above embodiments can be combined arbitrarily. To make the description concise, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0136] The above-described embodiments merely represent several implementation methods of the present application. While the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the present application. It should be noted that a person of ordinary skill in the art may make various modifications and improvements without departing from the spirit of the present application, and these modifications and improvements fall within the scope of protection of the present application. Therefore, the scope of protection of the present application shall be determined by the appended claims.

Claims

1. A scheduling system based on edge computing, characterized in that: include: An edge server, wherein the edge server is deployed with an edge service deployment package, wherein the edge service deployment package is used to provide an application component image deployed at the edge to collect data information of production line equipment; The cloud center server is connected to the edge server, and is used to receive data information of the production line equipment, and construct a digital twin model of the production line equipment based on the data information; the digital twin model is used to indicate the transmission of communication messages in the scheduling system.

2. The dispatching system according to claim 1, characterized in that: The cloud center server is deployed with: A connection component, used for receiving data information of the production line equipment sent by the edge server; A stream processing component, used for performing data preprocessing and data distribution on the data information of the production line equipment acquired via the connection component; A behavior component, configured to receive data distributed by the stream processing component, obtain behavior results, and generate motion information based on the behavior results; A motion component is used to receive the motion information and drive the corresponding three-dimensional model in the digital twin model based on the motion information.

3. The dispatching system according to claim 2, characterized in that: The behavior component performs behavior modeling on the production line equipment by using a finite state machine, wherein the finite state machine includes a state set and an instruction set, wherein the state set includes behavior state information of the production line equipment, and the instruction set includes instruction information received by the production line equipment.

4. The dispatching system according to claim 1, characterized in that: The edge service deployment package includes an application component, and the application component is used to deploy device applications based on the data information of the production line equipment, and the device applications correspond to the equipment in the production line one by one; The digital twin model is used to indicate the communication between the device applications.

5. The dispatching system according to claim 1, characterized in that: The scheduling system also includes a file server for storing equipment processing program files of the production line equipment; The edge server is deployed with a workflow control component, and the workflow control component communicates with the production line equipment through an edge message bus, and communicates with an electronic manufacturing system EMS through a message bus.

6. The dispatching system according to any one of claims 1 to 5, characterized in that: The digital twin model is a multi-level BOM model constructed based on the digital twin model file of each production line equipment; The digital twin model file includes an attribute information file and a node relationship information file; The attribute information file is an AML file, and the node relationship information file is a Neo4j file.

7. The dispatching system according to claim 6, characterized in that: The attribute information recorded in the attribute information file includes main information corresponding to each level of BOM model, sub-element information corresponding to each level of BOM model, interface information corresponding to each level of BOM model, role information corresponding to each level of BOM model, and parameter information corresponding to each level of BOM model.

8. The dispatching system according to claim 6, characterized in that: The levels of the multi-level BOM model are, from bottom to top, parts level, equipment level, production line level, area level, workshop level and factory level.

9. The dispatching system according to claim 8, characterized in that: The communication message carries at least one of BOM information, basic information, time information and security information; Among them, the BOM information includes model information, input information, output information and interface information of the target object in the current layer BOM model; the basic information includes the sending time and receiving time of the message; the time information includes the trigger event, and the trigger time includes the interface group information; the security information includes the token and the decoding form.

10. The dispatching system according to claim 9, characterized in that: The digital twin model is used to indicate the communication between BOMs at different levels.

Images