Software-Defined Manufacturing in Cellular Networks

Abstract

An embodiment of a system includes: at least one access node configured to wirelessly transmit and receive signals to and from industrial devices located within at least two cells of a cellular communication network deployed within a manufacturing facility; and a computer system. The computer system includes an interface connected to transmit and receive signals to and from the access node; and processing circuitry configured to: define a manufacturing process instance (MPI) that identifies manufacturing operations necessary to perform a predetermined manufacturing process; assign one or more of the industrial devices to the MPI, each assigned industrial device being configured to perform at least one of the identified manufacturing operations; and implement a controller configured to control each of the industrial devices assigned to the MPI to cooperatively perform the predetermined manufacturing process.

Description

Technical Field

[0001] The present disclosure relates to industrial automation and, in particular, to software-defined manufacturing (SDM) in cellular networks. Background Art

[0002] Industry 4.0 is a term used to describe the current trends in automation and data exchange in manufacturing technologies. This so-called fourth industrial revolution has the potential to significantly increase productivity, reduce costs, and improve product quality. Essentially, Industry 4.0 aims to achieve fine control of production at every step of the process, thereby improving quality. It also helps to reduce and even eliminate downtime, as data provided by manufacturing equipment such as industrial robots can be used to schedule maintenance or predict failures.

[0003] Although Industry 4.0 encompasses a range of goals and desired outcomes, there is currently no reference architecture that defines how industrial systems can be organized and operated to achieve these goals.

[0004] The International Electrotechnical Commission (IEC) has issued various standards related to automated manufacturing systems. For example, IEC 61131-3 is the third part of the open international standard IEC 61131 for programmable logic controllers (PLCs). The current (third) version was released in February 2013, and it details the basic software architecture and programming languages for control programs within PLCs. It defines the following three graphical and two textual programming language standards:

[0005] Ladder Diagram (LD);

[0006] Function Block Diagram (FBD);

[0007] Structured Text;

[0008] Sequential Function Chart (SFC); and

[0009] Instruction List (IL), which is deprecated.

[0010] IEC 61499 was initially released in 2005, and it addresses the topic of function blocks for industrial process measurement and control systems. The specification defines a general model for distributed control systems and is based on the IEC 61131 standard.

[0011] Although the IEC standards provide function blocks that can be used for automated control of industrial systems, they do not address the system performance requirements needed to implement the concepts of Industry 4.0. Summary of the Invention

[0012] The present invention provides a system that includes: at least one access node configured to wirelessly transmit and receive signals to and from industrial devices located within at least two cells of a cellular communication network deployed within a manufacturing facility; and a computer system that includes an interface connected to transmit and receive signals to and from the access node; and processing circuitry configured to: define a manufacturing process instance (MPI) that identifies manufacturing operations necessary to perform a predetermined manufacturing process; assign one or more of the industrial devices to the MPI, each assigned industrial device being configured to perform at least one of the identified manufacturing operations; and implement a controller configured to control each of the industrial devices assigned to the MPI to cooperatively perform the predetermined manufacturing process.

[0013] Embodiments of a base station, a communication system, and a method performed in a communication system are also disclosed. BRIEF DESCRIPTION OF THE DRAWINGS

[0014] The drawings incorporated in and forming a part of this specification illustrate several aspects of the disclosure and, together with the description, serve to explain the principles of the disclosure.

[0015] Figure 1A and Figure 1B is a block diagram showing a computing device that may be used in an embodiment of the present invention;

[0016] Figure 2 is a block diagram showing virtualization;

[0017] Figure 3 is a block diagram showing a manufacturing framework;

[0018] Figure 4 is a block diagram showing an example cellular communication network according to an embodiment of the present invention;

[0019] Figure 5 is showing in Figure 4 a block diagram of an example controller implemented in a server of the cellular communication network;

[0020] Figure 6 is showing Figure 5 a block diagram of an example packet flow in an implementation of;

[0021] Figure 7 is a block diagram showing an example software-defined manufacturing reference architecture according to an embodiment of the present invention;

[0022] Figure 8 is showing an access network deployed in an industrial facility of Figure 4 a block diagram of;

[0023] Figure 9 is a flowchart depicting an example process according to an embodiment of the present invention;

[0024] Figure 10 is a block diagram showing the creation of a manufacturing process instance in an example process; Figure 9

[0025] Figure 11 is a message flow diagram showing an example process for creating an MPI;

[0026] Figure 12 is a block diagram showing an example operation of a scheduler during a handover;

[0027] Figure 13 is a message flow diagram showing an example process of switching an industrial plant from a first MPI to a second MPI;

[0028] Figure 14 is a block diagram showing an example state of an MPI;

[0029] Figure 15 is a block diagram showing an example SDM functional block and interface;

[0030] Figure 16 is a diagram showing an example assembly line;

[0031] Figure 17 is showing Figure 7 the example functional sub - blocks of a controller;

[0032] Figure 18 is a block diagram showing an example MUTEX use case;

[0033] Figure 19 is showing in Figure 18 an example use case the example process for locking and unlocking a MUTEX;

[0034] Figure 20 is a block diagram showing an example parallel configuration of coarse and fine CLGCs;

[0035] Figure 21 is a block diagram showing an example serial configuration of coarse and fine CLGCs;

[0036] Figure 22 is a diagram showing the route of an autonomous vehicle;

[0037] Figure 23 is a block diagram showing the control of an electric motor of an autonomous vehicle modeled as a streamline;

[0038] Figure 24 is a block diagram showing controlling the steering servo of an autonomous vehicle to follow a path modeled as a streamline;

[0039] Figure 25 is a diagram showing an assembly line;​

[0040] Figure 26 is a block diagram showing the control of the servo in each industrial device arm of an assembly line; Figure 25 for an assembly line;

[0041] Figure 27 is a block diagram showing an example of an SDM operation for increasing the production capacity of an assembly line; Figure 25 for an assembly line;

[0042] Figure 28 is a block diagram showing an example of an SDM operation for replacing an industrial device of an assembly line; Figure 25 for an assembly line;

[0043] Figure 29 is a block diagram showing an example of an SDM operation for redeploying a manufacturing process within a factory; and

[0044] Figure 30 is a block diagram showing an example of two SDMs connected to an IoT cloud according to an embodiment of the present invention. Detailed Description

[0045] The embodiments set forth below represent information that enables those skilled in the art to practice the embodiments and illustrate the best mode of practicing the embodiments. When reading the following description in light of the accompanying drawings, those skilled in the art will understand the concepts of the present disclosure and will recognize applications of these concepts that are not specifically recited herein. It should be understood that these concepts and applications fall within the scope of the present disclosure.

[0046] At least some of the following abbreviations and terms may be used in the present disclosure.

[0047]

[0048]

[0049]

[0050] Radio Node: As used herein, "radio node" is a radio access node or a wireless device.

[0051] Radio Access Node: As used herein, a "radio access node" or "radio network node" is any node operating in a radio access network of a cellular communication network to wirelessly transmit and / or receive signals. Some examples of radio access nodes include, but are not limited to: base stations (e.g., NR base stations (gNB) in a 3rd Generation Partnership Project (3GPP) 5th Generation (5G) New Radio (NR) network or enhanced or evolved Node B (eNB) in a 3GPP Long Term Evolution (LTE) network), high-power or macro base stations, low-power base stations (e.g., micro base stations, pico base stations, home eNBs, etc.), and relay nodes.

[0052] Core Network Node: As used herein, a "core network node" is any type of node in a core network. Some examples of core network nodes include, for example, a Mobility Management Entity (MME), a Packet Data Network Gateway (P-GW), a Service Capability Exposure Function (SCEF), etc.

[0053] Wireless Device: As used herein, a "wireless device" is any type of device that has access to a cellular communication network (i.e., is served by a cellular communication network) by wirelessly transmitting (and / or receiving) signals to (and / or from) a radio access node. Some examples of wireless devices include, but are not limited to, User Equipment devices (UE) and Machine-Type Communication (MTC) devices in a 3GPP network.

[0054] Network Node: As used herein, a "network node" is any node that is part of a core network or a radio access network of a cellular communication network / system.

[0055] Cell: As used herein, a "cell" is a combination of radio resources (such as, for example, antenna port allocations, time, and frequency) that are available for a wireless device to exchange radio signals with a radio access node (which may be referred to as the serving node or host node of the cell). However, it is important to note that beams may be used in place of cells, especially with respect to 5G NR. Thus, it should be recognized that the techniques described herein apply equally to both cells and beams.

[0056] Note that references in this disclosure to various technical standards (e.g., such as 3GPP TS 38.211 V15.1.0 (2018-03) and 3GPP TS 38.214 V15.1.0 (2018-03)) should be understood to refer to the (one or more) specific versions of such standards at the current time of filing this application, and may also refer to applicable copies and successor versions of such versions.

[0057] The description herein focuses on 3GPP cellular communication systems and, accordingly, often uses 3GPP terms or terms similar to 3GPP terms. However, the concepts disclosed herein are not limited to 3GPP systems.

[0058] Figure 1A and Figure 1B is a block diagram schematically showing a communication system 100 including a computing device 102 that can be used in embodiments of the present invention.

[0059] In Figure 1A example, the communication system 100 generally includes a computing device 102 connected to one or more networks 110 and one or more radio units 112. The computing device 102 includes one or more processors 104, a memory 106, and one or more network interfaces 108. The processor 104 can be provided as any suitable combination of, for example, a microprocessor (µP), a central processing unit (CPU), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), etc. Similarly, the memory 106 can be provided as any suitable combination of a random access memory (RAM), a read only memory (ROM), and mass storage technologies such as magnetic disk or optical disk storage devices, etc. The network interface 108 enables signaling between the computing device 102 and a network 110 such as a core network (not shown), a data network (not shown), or a private domain network such as a data center (not shown).

[0060] Each radio unit 112 generally includes at least one transmitter (Tx) 114 and at least one receiver (Rx) 116 coupled to one or more antennas 118. In Figure 1A example, the (one or more) radio units 112 are shown to be located outside the computing device 102 and connected to the computing device 102 via a suitable physical connection such as a copper cable or an optical cable. In Figure 1B example, the (one or more) radio units 112 are shown to be connected to the computing device 102 via the network 110 and the network interface 108. Still in other embodiments, the (one or more) radio units 112 and optionally also the (one or more) antennas 118 can be integrated with the computing device 102.

[0061] One or more processors 104 operate to provide the functions of the computing device 102. Generally, these functions are implemented as software applications (APP) 120 or modules stored, for example, in the memory 106 and executed by one or more processors 104. In some embodiments, one or more software applications or modules 120 can be executed in a secure runtime environment (RTE) 122 maintained by an operating system (not shown) of the computing device 102.

[0062] It will be appreciated that certain embodiments may exclude one or more elements shown in Figure 1A and Figure 1B . For example, the computing device 102 configured to implement a wireless device of a radio access network may incorporate one or more processors 104, a memory 106, and one or more radio units 112, but may exclude the network interface 108. Conversely, for example, the computing device 102 configured to implement a server in a core network may include one or more processors 104, a memory 106, and one or more network interfaces 108, but may exclude the radio unit 112. On the other hand, the computing device 102 configured to implement a base station of a radio access network will typically include one or more processors 104, a memory 106, and both the radio unit 112 and the network interface 108.

[0063] Figure 2 FIG. is a block diagram schematically showing an example architecture 200 of system virtualization that may be used in embodiments of the present invention. It is contemplated that a computing system may be physically implemented using one or more computing devices interconnected and executing appropriate software to perform their intended functions (any one or all of which may be constructed according to the system 100 described above with reference to FIG. 1). Those of ordinary skill in the art will recognize that there are many suitable hardware and software combinations that can be used for this purpose, either known in the art or likely to be developed in the future. For this reason, diagrams showing physical hardware components and connections are not included herein.

[0064] As can be seen in Figure 2 , the shown architecture 200 generally includes a hosting infrastructure 202, a virtualization layer 204, and an application platform services layer 206. The hosting infrastructure 202 includes the physical hardware resources provided by the infrastructure on which the architecture 200 is implemented. These physical hardware resources may include any one or all of the processor 104, the memory 106, the network interface 108, and the radio unit 112 described above with reference to FIG. 1, and may also include traffic forwarding and routing hardware 208. The virtualization layer 204 presents an abstraction of the hardware resources 202 to the application platform services layer 206. The specific details of this abstraction will depend on the requirements of the application 120 hosted by the application platform services layer 206. Thus, for example, an abstraction of the hardware resources 202 (e.g., one or more processors 104, a memory 106, and traffic forwarding hardware 208) implementing a simplified traffic forwarding policy may be presented to the APP 120 providing a traffic forwarding function. Similarly, an abstraction of the hardware resources 202 (e.g., one or more processors 104 and a memory 106) facilitating the storage and retrieval of data (e.g., using the Lightweight Directory Access Protocol - LDAP) may be presented for an application providing a data storage function.

[0065] The application platform 206 provides the ability to host applications. In some embodiments, the application platform 206 supports a flexible and efficient multi-tenant runtime and hosting environment for the application 120 by providing an Infrastructure as a Service (IaaS) facility. In operation, the application platform 206 can provide a security and resource "sandbox" for each application 120 hosted by the platform 206. Each "sandbox" can be implemented as a virtual machine (VM) image 210 that can include a suitable operating system and controlled access to the (virtualized) hardware resources 202. Alternatively, each "sandbox" can be implemented as a container 211 that can include suitable virtual memory as well as controlled access to the host operating system and the (virtualized) hardware resources 202. The application platform 206 can also provide a set of middleware application services and infrastructure services to the applications 120 hosted on the application platform 206, as will be described in more detail below.

[0066] Applications 120 from vendors, service providers, and third parties can be deployed and executed in the corresponding virtual machines 210. The communication between the applications 120 and the services of the application platform 206 can be conveniently designed according to the principles of a service-oriented architecture (SOA) known in the art.

[0067] The communication service 212 can allow the applications 120 to communicate with the application platform 206 (e.g., via predefined application programming interfaces (APIs)), and allow the applications 120 to communicate with each other (e.g., via service-specific APIs).

[0068] The service registry 214 can provide visibility of the services available on the server 200. Additionally, the service registry 214 can present service availability (e.g., the status of the service) as well as the associated interfaces and versions. The applications 120 can utilize it to discover and locate the endpoints of the services they need and publish their own service endpoint(s) for use by other applications.

[0069] The Network Information Service (NIS) 216 can provide the applications 120 with low-level network information related to, for example, network service instances or one or more protocol data unit (PDU) sessions.

[0070] The Traffic Offload Function (TOF) service 218 can prioritize traffic and route policy-based data flows to and from the applications 120.

[0071] Figure 3 An example manufacturing framework and the corresponding latency tolerance for each layer of the framework are shown. In this regard, the term "latency" refers to the delay between the time a message is transmitted and the time the message is received. The message can be a command, request, confirmation, or response. As in Figure 3As can be seen, the planning and management functions can operate with a relatively high latency, while the control function requires a significantly lower latency.

[0072] It should be noted that conventional industrial automation standards do not clearly distinguish between coarse control and fine control levels. This reflects the conventional system architecture, in which the industrial plant controller is co-located with the industrial plant itself and directly controls various arms, tools, sensors, and actuators of all industrial plants. In such an architecture, the relevant latency tolerance is related to the industrial plant controller because the latency of various components of the industrial plant is invisible to the rest of the system.

[0073] On the other hand, the present disclosure contemplates that the ultra-reliable low-latency communication (URLLC) capabilities of 5G NR can be used in embodiments of the present invention. In such cases, the distinction between coarse-level control and fine-level control and their associated latency tolerances is useful.

[0074] This document defines coarse control and fine control as follows:

[0075] • Fine control is used to control a specific device (e.g., an actuator such as a servo in an industrial plant arm or an electric motor in an autonomous vehicle). Thus, fine control operates on specific process variables that are typically time-critical. Fine control is generally very fast, which implies that the communication channel (e.g., between the controller and the specific device) is required to have ultra-low latency (e.g., less than or equal to 1 ms).

[0076] • Coarse control can control more than one process variable or some environmental metrics that are important for the manufacturing process but not as time-critical. Coarse control generally requires the communication channel to have a relatively low latency (e.g., less than or equal to 10 ms), but in some cases, depending on the variables or environmental metrics considered in the control plan, it may also require the communication channel to have ultra-low latency.

[0077] Typically, an industrial facility consists of industrial plants (such as industrial robots and other equipment) from different suppliers. The processes of planning, management, and control are considered separate tasks. Each supplier usually provides his own proprietary management solution, which may or may not interact with the management solutions of other suppliers. Technicians usually determine the role of each industrial plant for a given process and then must develop and install appropriate scripts for each device. In some cases, this requires the technician to go to each device to program it. Since industrial operators usually have multiple tools, it is difficult to manage end-to-end operations.

[0078] Some industrial installations in manufacturing rely on an open-source standard called the Robot Operating System (ROS). ROS was first developed at Stanford University and is an open-source framework with an established developer community that has become widespread in the industry. However, ROS does not support the real-time capabilities required by most industrial installations. Therefore, a variant of ROS called ROS-Industrial, which provides real-time support and other required capabilities for industrial installations, is becoming increasingly popular. ROS-Industrial is an open-source solution that includes libraries, tools, and drivers for industrial hardware. It is supported and guided by the ROS-Industrial Consortium.

[0079] Systems and methods for providing an integrated system for controlling and managing industrial installations are disclosed herein. According to an embodiment of the present invention, a system includes: at least one access node configured to wirelessly transmit and receive signals to and from industrial installations located within at least two cells of a cellular communication network deployed within an industrial facility; and a computer system including: an interface connected to transmit and receive signals to and from the access node; and processing circuitry configured to: define a manufacturing process instance (MPI) that identifies industrial operations necessary to perform a predetermined industrial process; assign one or more of the industrial installations to the MPI, each assigned industrial installation being configured to perform at least one of the identified industrial operations; and implement one or more controllers configured to control each of the industrial installations assigned to the MPI to collaboratively perform the predetermined industrial process.

[0080] For the purposes of the present disclosure, an industrial facility is any area (which may consist of one or more buildings and / or sites) used for industrial purposes such as manufacturing, storage, or transportation. Examples of industrial facilities include (but are not limited to) factories, warehouses, operations centers, stockyards, railway yards, port facilities, etc.

[0081] For the purposes of the present disclosure, a manufacturing process refers to a sequence of one or more operations that result in a defined outcome. For example, in a factory, a manufacturing process may include the operations required to convert raw materials (e.g., starting materials) into a finished product. In an assembly plant, a manufacturing process may include the operations of assembling multiple parts in a defined order to produce a final product such as an automobile. An industrial process is a broader concept that includes manufacturing processes but also encompasses other tasks such as storage, forwarding, and transportation. For example, in the context of a railway yard, an industrial process may refer to the sequence of operations required to remove a shipping container from a railway car, temporarily store the shipping container in a stockyard, and then place the shipping container on a transport trailer.

[0082] For the purposes of the present disclosure, an industrial operation is a discrete operation in an industrial process. In many cases, an industrial operation will be performed by a specific machine or device and at a specific time. Thus, in some embodiments, different industrial operations in an industrial process are performed by corresponding different machines and / or at different times.

[0083] For the purposes of the present disclosure, an industrial device is any machine or equipment configured to perform one or more industrial operations and also capable of communicating with a computer system according to the present disclosure. Examples of industrial devices include (but are not limited to) industrial robots, autonomous vehicles, automated guided vehicles (AGVs), sensors, actuators, and controllers (e.g., which may be associated with other machines such as milling machines or stamping machines).

[0084] Figure 4 An example of a cellular communication network 400 according to an embodiment of the present disclosure is shown. In the embodiments described herein, the cellular communication network 400 may conform to one or more of the LTE, 4G, and 5G NR standards or subsequent versions thereof. In the example shown, the cellular communication network 400 includes a radio access network (RAN) 402, and the RAN 402 includes access nodes 404A and 404B that control radio communication with industrial devices 406A...406H within corresponding cells 408A and 408B. Each cell 408 may be defined by any suitable combination of geographical environment, frequency, radio access technology (RAT), modulation scheme, and access node identifier. In some embodiments, the cell 408 may be referred to as a manufacturing cell (MC).

[0085] The access nodes 404A and 404B can be any type of network access device capable of establishing one or more radio connections with one or more industrial devices 406 within the respective coverage areas of the access nodes 404 and further configured to forward signaling traffic between the industrial devices 406 and the core network 410.

[0086] An important feature of the access node 404 is that it is configured with both a radio interface configured to transmit and receive radio signals to and from the industrial device 406 and a network interface configured to exchange electrical and / or optical signals with the core network 410. Examples of the access node 404 include: evolved Node B (eNB) and gNB systems (known, for example, in 3GPP standards); WiFi access points (known from, for example, IEEE 802.11 standards), etc. In some contexts, the access node 404 may be referred to as an access point (AP), regardless of the radio access technology (RAT) it supports.

[0087] Industrial device 406 can be any type of industrial equipment or machinery configured with radio and / or wired communication circuitry capable of transmitting and receiving signals to and from access node 404. Examples of industrial device 406 include industrial robots, sensors, actuators, machine controllers, mobile computers, Internet of Things (IoT) devices, autonomous vehicle controllers, AGV controllers, etc. In some contexts, industrial device 406 may be referred to as a user equipment (UE) or mobile device.

[0088] In some embodiments, cells 408A and 408B may overlap with each other. For example, a particular cell 408A may be one of multiple cells that cover a common geographical area and have a common RAT and modulation scheme but use respective different frequencies and / or access point (AP) identifiers. In such cases, an industrial device 406 located within an area covered by two or more overlapping cells 408 may transmit and receive radio signals to and from each corresponding access node 404.

[0089] In the example shown, RAN 402 is connected to a core network (CN) 410, which may also be referred to as an evolved core network (ECN) or evolved packet core (EPC). CN 410 includes (or is equivalently connected to) one or more servers 412 configured to provide networking services (such as network functions (NFs) described, for example, in 3GPP TS 23.501 V15.2.0 (2018-06) "System Architecture for the 5G System" and its successor versions) as control and supervision services for industrial device 406. CN 410 may also include one or more gateway (GW) nodes 414 configured to connect CN 410 to a packet data network (DN) 416 (such as the Internet, for example). The gateway node 414 may be referred to as a packet gateway (PGW) and / or serving gateway (SGW). DN 416 may provide communication services to support end-to-end communication between server 412 and one or more application servers (AS) 418. In some contexts, application server (AS) 418 may also be referred to as a host server.

[0090] It should be appreciated that the separation between CN 410 and DN 416 may be purely logical to simplify the understanding of their respective roles. In particular, CN 410 is mainly focused on providing industrial device access, control, and supervision functions and supporting the mobility of wireless devices within a particular industrial facility. On the other hand, DN 416 is mainly focused on providing end-to-end communication and management functions across multiple industrial facilities. However, it will be appreciated that if desired, both CN 410 and DN 416 may be implemented on a common physical infrastructure.

[0091] In conventional technologies, industrial processes are carried out in industrial facilities that provide a strictly defined set of resources, such as industrial plant 406, in order to perform predefined tasks and thus achieve a defined goal. For example, in an automobile assembly line, several industrial plants 406 can cooperate to assemble an automobile. The assembly line is optimized to efficiently build a specific model of the automobile. Unfortunately, the trade-off is that the process is rigid because it cannot be easily changed to produce different types or models of automobiles. To make changes, some modifications must be made, such as modifying the programming and tools of the industrial plant 406, readjusting some machinery to fit the new specifications of the new automobile, creating or deleting new tasks, etc.

[0092] In contrast, Industry 4.0 requires an agile industry that modularizes the manufacturing process, and thus, it can easily adapt to changes according to demand, is easy to configure and customize, and produces in a timely manner.

[0093] In this description, the term "Software-Defined Manufacturing (SDM)" generally describes the reference architecture and methods for achieving the goals of Industry 4.0. Example features and benefits of Software-Defined Manufacturing (SDM) can include:

[0094] • Agile planning: An industrial facility can have more than one industrial process and can easily add new processes or modify existing processes.

[0095] • Control with minimal human intervention: The control and supervision of industrial processes should be automated. Human intervention focuses on planning and supervision review.

[0096] • Control focuses on efficiency and quality assurance (QA). Closed-loop gain control (CLGC) (sometimes also called closed-loop control (CLC)) is widely used as a process to ensure that efficiency and QA match.

[0097] • Supervision includes self-healing capabilities, which require maintenance through the industrial plant 406. The focus is also based on preventive maintenance.

[0098] • Machinery is general-purpose and dynamically allocated to manufacturing processes: Reduces the use of statically allocated machinery for processes. For example, if required by demand, the arm of the industrial plant 406 can be reallocated to a different manufacturing process.

[0099] • Online manufacturing: The manufacturing of parts preferably starts when an order occurs.

[0100] • The manufacturing process is defined by software, which means that a process definition is created in a computer that includes specifications of the resources used in the process, what the desired output is, quality assurance (QA) parameters, control definitions, etc. This manufacturing process can be further instantiated using the resources of the facility (e.g., industrial device 406) and the tasks in the plan in order to produce the desired output via the intelligent manufacturing framework.

[0101] In some embodiments, the principles of virtualization described above with reference to Figure 2 can be used to implement SDM. For example, process and device control and supervision functions can be implemented using virtualized hardware resources 202 as applications 120 executing within virtual machines 210 or containers 211. In the case of industrial processes, in addition to computing, data storage, and communication resources, the virtualized hardware resources 202 can also include industrial devices 406 and other resources of the industrial facility.

[0102] For a successful SDM implementation, an automated closed-loop gain control with high precision is important.

[0103] CLGC is useful in the automation of industrial device 406, especially in intelligent manufacturing, because it is a key mechanism for controlling the operation of industrial device 406 during the manufacturing process (especially in real time). In some contexts, the term "controller" actually refers to the CLGC controller because it is the most common and frequently used type of control in manufacturing. An example of this type of CLGC controller can be a proportional-integral-derivative (PID) controller, which is typically integrated with programmable logic devices (PLCs) used in industrial facilities to control the manufacturing process.

[0104] CLGC is based on instantaneous or very low-latency feedback signals from the process output with a highly predictable time accuracy. This allows for precise control of the operation of industrial device 406, such as the motion operation of the arm of industrial device 406. Isochronous real-time communication enables integration with very low latency to support real-time closed-loop control. These applications are crucial for the efficiency and quality assurance of automated manufacturing processes involving industrial device 406, autonomous vehicles, and sensors.

[0105] CLGC includes a functional block called a controller. This controller operates to control the manufacturing (or other industrial) process through a variable gain process (VGP) by periodically reading feedback signals derived from the output of the process and applying corrections when needed. The time between sensing the output to generate the feedback signal and applying the correction to the VGP to adjust the manufacturing process should be as small as possible. A large delay can invalidate the correction calculated from the feedback signal, resulting in, for example, damage to the production line and causing safety issues. The correction intervals should also be the same to avoid large jitters, thus maintaining the accuracy and stability of the CLGC algorithm executed in the controller.

[0106] Therefore, the CLGC control in the manufacturing process is an isochronous task, which requires real-time execution and tight-slot communication between the CLGC controller and the instrumentation of the measurement feedback signals. Generally, the CLGC cycle time can consist of any of the following parts:

[0107] • Periodic downlink transactions from the CLGC controller to a set of instruments, followed by an uplink response with measurement values to the CLGC controller; or

[0108] • Periodic downlink transactions from the CLGC controller to a set of VGPs, followed by an uplink response from the VGPs to the CLGC controller.

[0109] In the description of these algorithms presented herein, the following definitions are adopted:

[0110] • is the manipulated variable at time t

[0111] • is the controller gain at time t

[0112] • is the process variable at time t

[0113] • is the controlled variable at time t

[0114] • is the setpoint at time t

[0115] • is the integral time constant,

[0116] • is the derivative time constant,

[0117] • is the error at time t and

[0118] • is defined as the output of the controller when the error is zero, i.e., it is the compensation due to the environmental sensor.

[0119] ​​​​​The most common CLGC algorithms used in this disclosure are the On / Off (open / closed) controller, the proportional controller, and the integral controller. See, for example: 1) W. Svrcek, D. Mahoney, and B. Young, “A Real-Time Approach to Process Control,” John Wiley & Sons, p.93-113, ISBN: 9781119993872, 2014., Chapters 3 and 4; and 2) S. Mitsi, K. D. Bouzakis, G. Mansour, and D. Sagris, "Off-line programming of an industrial Device 406 for manufacturing," International Journal of Advanced Manufacturing Technology, no. 26, p. 262-267, 2005. Each of these controllers will be described below.

[0120] In the On / Off controller, it is defined by the following formula :

[0121]

[0122] The implementation of this controller can use asynchronous communication based on notifications sent from the instrument to the controller. When , the notification ON (open) is sent, and when , the notification OFF (closed) is sent.

[0123] In the proportional controller, it is defined by the following formula :

[0124]

[0125] In the integral controller, it is defined by the following formula :

[0126]

[0127] where is defined as the controller output before integration, the initial condition at time zero, or the condition when the controller switches to automatic.

[0128] In addition, various combinations of these controllers can include:

[0129] The proportional plus integral (PI) controller, where it is defined by the following formula :

[0130]

[0131] A proportional plus derivative controller, which is defined by the following formula :

[0132]

[0133] Proportional integral derivative (PID), which is defined by the following formula :

[0134]

[0135] Figure 5 An example embodiment of implementing the CLGC controller 500 in the server 412 of the 4G / 5G core network 410 is shown. The CLGC controller 500 can trigger periodic messages to the industrial device 406 to obtain measurement values from a set of meters or assign gain values to the VGP on the industrial device 406. It is expected that the CLGC controller 500 receives response messages with feedback data. Since the message exchange is isochronous, the data stream is also isochronous with high predictability.

[0136] In an alternative embodiment, the controller 500 can be collocated with the access node 404 instead of the server 412.

[0137] Figure 6 An example packet flow of the CLGC controller implemented using the TCP / IP stack over the 4G / 5G network is shown. The dashed line indicates that the flow passes through several nodes in the network. The flow originates from the CLGC controller UE and goes up to the industrial device 406. To reach the industrial device 406, TCP / IP packets from the controller UE are sent down through its TCP / IP and 4G / 5G stacks. In the 4G / 5G PHY, the TCP / IP packets are sent via Ethernet to the serving gateway (SGW, not shown in Figure 5 ). The SGW forwards the IP packets (via Ethernet) to the access node 404. Inside the SGW, the TCP / IP packets go down through the TCP / IP and 4G / 5G stacks all the way and send it to the industrial device 406 via the air interface. The industrial device 406 receives the packets from its air interface and sends it to the VGP, meter or sensor destination.

[0138] The following description is divided into four subsections: description of the reference model, flowchart, detailed explanation of the manufacturing process example, and use case examples.

[0139] As described above, the term "software-defined manufacturing (SDM)" is introduced herein to refer to the reference architecture and method for achieving the goals of Industry 4.0.Figure 7 FIG. 700 shows an example software-defined manufacturing reference architecture according to an embodiment of the present invention. Use cases will be disclosed below to show how this proposed model can solve practical industrial problems. For ease of understanding, the following description will focus on examples based on manufacturing contexts. Thus, the terms used are specifically related to manufacturing. However, it will be recognized that the same techniques can equally be applied to industrial facilities and processes other than manufacturing.

[0140] As Figure 7 shown, the reference architecture 700 includes a management and planning layer 702, a supervision and control layer 704, and a field layer 706. The field layer 706 consists of physical resources of an industrial facility, such as industrial devices 406, loading docks, storage areas, and work areas. The planning, supervision, and control layers 702 and 704 can be implemented as one or more computer systems as described above with reference to Figure 1A and Figure 1B and can form part or all of the core network 410 described above. In the example shown, the planning layer 702 includes an Internet of Things (IoT) cloud 708, a planner 710, and a database 712, while the supervision and control layer 704 includes a scheduler 714, a supervisor 716, a controller 718, a mutual exclusion (MUTEX) server 720, a PTP server 722, and a location server 724.

[0141] In some embodiments, the field layer 706 can include a physical resource and a virtualization layer. The virtualization layer operates to present virtualized resources to the upper layers in a manner directly similar to that described above with reference to Figure 2 For example, the functions and services of the management and planning layer 702 and the supervision and control layer 704 can be implemented as an application 120 that executes in a virtual machine 210 or a container 211 hosted by the application platform 206 and utilizes the virtualized resources of the industrial facility presented to the application platform 206 by the virtualization layer 204.

[0142] The reference architecture 700 is an abstract layered structure that defines three abstract layers:

[0143] • Management and planning: This layer is the planning and management application of SDM.

[0144] • Supervision and control: This layer is responsible for supervision and control in each manufacturing process instance (MPI).

[0145] • Field: This is the communication between the MPI and the industrial device 406 of the industrial device 406 control layer itself.

[0146] Figure 7The example reference model has white boxes that indicate functions that have counterparts in conventional systems (e.g., ROS Industrial and / or IEC standards). However, this described invention describes enhancements to its conventional functionality and supplements traditional functional blocks with new functional blocks and new interactions to meet the requirements of Industry 4.0, ROS Industrial, and IEC simultaneously.

[0147] Figure 8 An industrial facility 800 such as a manufacturing plant is shown, in which a radio access network 402 including a set of four adjacent cells 408 is deployed. As described above, each cell 408 can be defined by any suitable combination of geographical environment, frequency, radio access technology (RAT), modulation scheme, and access node identifier. If needed, conventional handover techniques (e.g., based on signal strength or radio signal coverage) can be used to handle mobile devices (such as autonomous vehicles and AGVs) moving from one cell 408 to another. Alternatively, fixed "geographical" boundaries between adjacent cells 408 can be defined within the industrial facility 800, and the position (and / or speed and direction) of mobile devices within the industrial facility 800 can trigger the handover of mobile devices from one cell to another.

[0148] Figure 8 A set of manufacturing process instances (MPI) 802 within the industrial facility 800 is also shown. As will be described in more detail below, an MPI is a logical construct that identifies the industrial operations necessary to perform a predetermined industrial process and one or more industrial devices or manufacturing processes (MP) configured to perform those industrial operations. In some embodiments, all industrial devices assigned to a given MPI 802 are located within a common cell 408. For example, Figure 8 An embodiment is shown in which MPI 408A encompasses all industrial devices 406 within cell 408A and another embodiment in which industrial devices 406 within cell 408B are assigned to two different MPIs 802B and 802C. These arrangements are beneficial because in each case, all industrial devices 406 of a given MPI 802A…802C are connected to a single access node 404, which helps to meet the latency requirements of fine control functions (see Figure 3 ).

[0149] Figure 8 An alternative embodiment is also shown in which MPI 802D encompasses industrial devices 406 located in two different cells 408C and 408D. In such embodiments, the required inter-cell packet flow can make it more difficult to meet the low latency requirements of fine control functions. However, in cases where higher latency can be tolerated or the inter-cell packet flow manages to minimize the impact on latency, an MPI 802 can span two or more cells 408.

[0150] Return referenceFigure 7 : The planner 710 is responsible for receiving manufacturing orders and decomposing them into fine-grained steps. Each step in the manufacturing process (MP) and the MP as a whole are logical collections defined by a set of resources and one or more plans (such as, for example, motion plans, movement plans, task plans, control plans, supervision plans, and calibration plans). The MP is defined by the planner and carried out in one or more MPIs, which means that the MP is instantiated in one or more MPIs to process the order.

[0151] The IoT cloud 708 is responsible for collecting alerts and device status so that the integrated information can be displayed on demand.

[0152] The database 712 can be subdivided as follows:

[0153] • The processing cell (or manufacturing cell) database may contain processing cell definitions. The cell definition specifies the resources allocated to the cell, such as industrial devices 406 and computing resources.

[0154] • The manufacturing process database may store the (one or more) MPs created to process manufacturing orders and their plans (such as control plans, supervision plans, motion plans, and movement plans).

[0155] • The calibration database may contain calibration tables for industrial devices and manufacturing processes.

[0156] The scheduler 714 is responsible for triggering the execution of the manufacturing process definition through the following steps by means of one or more processing plans received from the planner 710:

[0157] • Create, start, and stop manufacturing process instances.

[0158] • Allocate resources to manufacturing process instances.

[0159] • Switch mobile devices between MPIs.

[0160] The PTP server 722 is responsible for providing a constant time reference across all nodes in the SDM reference model. It ensures that all entities are time-synchronized so that the tasks described in the set of plans can be executed correctly. The PTP server can be replaced by any high-precision time synchronization server.

[0161] The location server 724 is responsible for monitoring and tracking the location of industrial devices 406 (and especially mobile devices) within the industrial facility.

[0162] The manufacturing process instance (MPI) may include a controller 718, a supervisor 716, and multiple industrial devices 406, at least some of which may be mobile devices.

[0163] The supervisor 716 is an entity that disposes of or reacts to synchronous and asynchronous events originating within the framework (e.g., an alert from a controller of a manufacturing process, or an alert caused by monitoring a certain property of the manufacturing process).

[0164] The controller 718 controls the execution of the plan for each industrial device 406 under its control.

[0165] Figure 9 is a flowchart depicting an example process according to an embodiment of the present invention. Some of the steps in the flowchart will be further explained in the following subsections.

[0166] Step 906: The scheduler creates a manufacturing process instance (MPI).

[0167] The receipt of an order may trigger the planner 710 to create an MP, and the MP may cause one or more MPIs. This is as Figure 10 shown. In response to a request from the planner 710 to send a manufacturing process specification to the scheduler to create one or more corresponding MPIs, the scheduler 714 creates an MPI. Figure 11 shows an example message sequence for creating an MPI. Before creating an MPI, the scheduler 714 may verify that there are sufficient physical resources in the SDM resource pool to meet the requirements specified in the MP. If sufficient resources are available, an MPI is created and resources are allocated to it.

[0168] Step 908: The scheduler allocates resources. The allocation of resources involves allocating industrial devices and allocating communication channels.

[0169] Step 918: The scheduler 714 disposes of the mobile industrial device 406 switching to a new MPI. When the industrial device 406 moves between different MPIs, the mobile industrial device 406 switching occurs. As Figure 12 shown, the switching engine operating as part of the scheduler receives the switching event. The destruction of the entity representation of the industrial device 406 about to switch and the MPI allocation are performed over the 4G / 5G channel, and the relevant processing cell database is updated to reflect the changes. Figure 13 shows an example message sequence of the industrial device switching process. An event is generated and sent to the scheduler that disposes of the event. The scheduler deletes the device from the controller and supervisor of the corresponding first MPI to which the device is allocated. Then, the scheduler adds the device to the controller and supervisor of the second (target) MPI that is about to receive the device.

[0170] As Figure 13 shown, the switching is performed by deleting the industrial device 406 from the first MPI and adding it to the second MPI. As shown by Figure 13The deletion of the industrial device 406 as shown and its addition to the new MPI imply that the industrial process implemented by the first MPI is not interrupted. Otherwise, the switch may not be successful, or one or more additional actions may be taken, such as shutting down the first MPI by the supervisor.

[0171] Step 914: The scheduler updates the MPI status. Figure 14 An example status of a manufacturing process instance (MPI) is shown. If the MPI is not calibrated, the manufacturing process may not be executable to process an order. In some embodiments, the MPI must be calibrated before running the manufacturing process.

[0172] To implement Figure 9 For the flowchart shown, it is important to illustrate the types of information exchanged. Figure 15 An example SDM functional block and the interfaces between these functional blocks are shown. As Figure 15 shown, the MPI has the following main blocks:

[0173] • Supervisor 716: Receives supervision control events from the controller via interface e1. Thus, it can request a repair action from the controller 718 via interface e1, and / or publish an event log to the IoT cloud via interface w1. The repair actions and events are described in the supervision plan. Optionally, as described in the supervision plan, the supervisor can monitor the quality assurance (QA) metrics of the output of an order.

[0174] • Controller 718: As described in the control plan, it performs the coarse control and fine control of the industrial device 406 assigned to the MPI. It uses interface c1 for the coarse control of the device and interface f1 for the fine control of the device. It also obtains the motion plan from the planner and executes it via the interface m1 to the device.

[0175] • Industrial device 406: It obtains motion or movement commands from the controller 718 via interface m1 and executes the commands when being controlled by the controller 718 via interfaces c1 and f1. Additionally, when the industrial device 406 is started and connected to the controller, it sends its capabilities to the controller via interface d1 and further forwards its capabilities to the planner through the controller.

[0176] Shared functional blocks are a type of block whose instances are shared with or communicate with different MPIs. They are:

[0177] • IoT cloud: It stores the database of event logs collected from the supervisor via interface w1 and generates an intelligent manufacturing health report.

[0178] • Planner with a database: Generates control, calibration, movement, and motion plans, and sends the plans to the scheduler via interface p1. It also generates a supervision plan and sends it to supervision via interface e1. However, to generate these plans, the planner must know in advance the resource availability from the scheduler (via interface p1), and whenever a new industrial plant 406 (connected to the controller) is discovered, the resource availability is sent via interface d1 with the help of the controller.

[0179] • PTP server: It saves the time synchronization between the controller and the industrial plant 406 via interface t1.

[0180] • Location server: It saves the mapping and location references and implements location services for mobile industrial plants 406 such as autonomous vehicles and AGVs.

[0181] • MUTEX area: It is a system area that maintains the cooperation of all MUTEXes among streamline tasks.

[0182] • Scheduler: It creates new MPI instances by coordinately creating MPI function blocks (scheduler, controller, and supervisor). It also switches the procedures of the mobile industrial plant 406. Figure 12 The function blocks of the scheduler are shown.

[0183] • MPI allocator: It is responsible for MPI creation and destruction.

[0184] • Resource allocator: It is responsible for allocating resources to each MPI.

[0185] • Switching engine: It is responsible for switching management.

[0186] The SDM framework may include the following two types of communication interfaces:

[0187] • Best-effort (or non-real-time) interface: An interface that does not require isochronous real-time transmission (such as negotiating the capabilities of industrial plant 406 (via TCP) and SDM management of MPI). The best-effort interface may include any one or more of the l1, d1, s1, and p1 interfaces.

[0188] • Isochronous real-time: An interface for isochronous real-time transmission such as motion control, path control, and CLGC control. The isochronous real-time interface may include any one or more of the c1, f1, m1, t1, a1, and e1 interfaces.

[0189] Figure 15 An example interface of the SDM framework is also shown, which may include:

[0190] • Control Interface (c1, f1): f1 is an optional interface because highly specialized industrial device 406 can achieve fine control instead of using the control provided by the controller. The protocol used in these interfaces is the Coarse and Fine Control Protocol (CFCP).

[0191] • Discovery Interface (d1): The controller uses these interfaces to discover the capabilities of industrial device 406. The d1 interface is also used to forward the capabilities of industrial device 406 from the controller 718 to the planner 710.

[0192] • Motion / Path Command Interface (m1): The controller uses the m1 interface to send motion or path commands to industrial device 406.

[0193] • Planning Interface (p1): The planner sends the plan file to other functional blocks through interface p1. The plan file can be, for example, a control plan, a motion plan, or a task plan.

[0194] • w1: It is an interface for communicating with the IoT cloud, generally an interface running a protocol based on the TCP / IP interface (such as the MQTT protocol or REST).

[0195] • Time Reference Interface (t1): Through the t1 interface, the SDM functional blocks can synchronize their clocks and perform IRT communication.

[0196] • Supervision Event (e1): The planner, the controller, and the PTP server use these interfaces to send events to the supervisor.

[0197] • Network MUTEX Interface (a1): The a1 interface is used to create, destroy, lock, and unlock the network MUTEX used by the control tasks.

[0198] • Location Interface (l1): These interfaces are used to transmit location information, such as the spatial coordinates of the moving industrial device 406.

[0199] • Scheduler Interface (s1): The scheduler uses the s1 interface to create functional blocks for MPI.

[0200] The following paragraphs will describe the manufacturing process instance in more detail.

[0201] SDM executes the manufacturing process (MP) in MPI. MPI couples the processing cell (PC) to the MP. The only MP can run in multiple MPIs. Each MPI is associated with a different PC and generates a copy of the specified output for the order in the MP specification.

[0202] Figure 16 An automotive assembly line is shown as an example implementation of MPI. MPI can have several industrial devices 406 that collaborate to fulfill the order.

[0203] Each MPI consists of functional blocks including a controller, a supervisor, and industrial devices, and its instructions come from a planner and a scheduler.

[0204] The planner is responsible for receiving manufacturing orders and generating a manufacturing process specified by the plan. The planning of the manufacturing process may involve one or more of the following types of planning:

[0205] • TMP plan: including task plan, motion plan, and path plan

[0206] • Movement plan

[0207] • Control plan

[0208] • Supervision plan

[0209] • Calibration plan

[0210] To achieve the goals of manufacturing steps such as drilling holes in parts and moving parts from a conveyor belt to an autonomous vehicle, industrial devices 406 such as the arm of industrial device 406 need to be able to perform high-level task planning in combination with low-level motion planning. Task planning is required to determine long-term strategies, such as whether to stop the conveyor belt to pick up a part and place it into an autonomous vehicle. Motion planning is required to calculate the actual movements that industrial device 406 should perform.

[0211] Traditionally, task planning and motion planning have been treated separately in the field of industrial device 406. However, this separation may be problematic. Instead, task-motion planning (TMP) is proposed for tightly coupling task planning and motion planning, thereby generating a sequence of steps that can be actually executed by a real industrial device 406 to bring it from an initial state to a final state.

[0212] Embodiments of SDM may support any one or both of the following methods:

[0213] • Separate task and motion plans.

[0214] • TMP plan including tightly coupled task and motion planning.

[0215] The movement plan describes how the mobile industrial device 406 travels within and / or outside the MPI to cross to another MPI. The path followed by the mobile industrial device 406 may include adding and removing the industrial device 406 to different processing cells (such as MC or MPI) during its operation. Therefore, the movement plan may include any one or both of the following:

[0216] • Cellular plan: including security and configuration parameters for the connection of industrial device 406 to a cellular cell and cellular handover parameters.

[0217] • Route description: It describes the route that the industrial device 406 will follow. It may include obtaining a map of the area of interest / manufacturing center, planning the optimal route for the industrial device 406, and parameters for optimizing the route when new obstacles are encountered.

[0218] The control plan contains the configuration of each fine control and coarse control plan for the flow line.

[0219] The supervision plan contains the specifications of at least one of the following:

[0220] • Event handling: The controller can generate events such as alarms. These alarms are handled by the MPI supervisor, which may include event filtering, forwarding the event to the IoT cloud, or requesting the controller to perform actions such as shutting down the entire MPI.

[0221] • Quality Assurance (QA): The order can describe the desired QA parameters that the planner can include in the supervision plan. The supervisor can monitor these parameters, which may generate events showing differences during the manufacturing order through the MPI.

[0222] The calibration plan involves performing an initial calibration of various sensors in the industrial device 406 of the manufacturing plant to help obtain accurate sensor and instrument values for the coarse and fine controllers.

[0223] The scheduler 714 may be responsible for one or more of the following:

[0224] • Creating, starting, and stopping manufacturing process instances

[0225] • Allocating resources to manufacturing process instances

[0226] • Enabling the mobile industrial device 406 to perform an Intra-Handover between manufacturing cells (MCs) assigned to the same manufacturing process instance (MPI)

[0227] • Enabling the mobile industrial device 406 to perform an Inter-Handover between manufacturing cells (MCs) assigned to different manufacturing process instances (MPI)

[0228] The controller 718 controls the execution of the plan, which may include motion, calibration, and control plans.

[0229] Example functional sub-blocks of the controller are as Figure 17 shown and are described as follows:

[0230] • Control Engine: For each tick of the time reference, it receives measurements and calculates new gain values to compensate for the errors detected in the measurements. The new gain values are calculated according to an algorithm that implements a closed-loop gain control type for the industrial plant 406 (coarse control) or for the actuators in the industrial plant 406 (fine control) as described previously.

[0231] • Interpolator: Calibration data is generally defined in a table. In this case, the measured values rarely have corresponding rows in the calibration table. Therefore, the calibration table and the measurement data are sent to the interpolator. The interpolator performs a predefined interpolation function to calculate the compensation value for the control engine.

[0232] • CFCP Interface: It fetches CFCP messages from the network and makes the content available to the control engine and vice versa.

[0233] • Local Time Unit (LTU): The LTU signals the synchronization time tick to the CFCP interface and the control engine that initiate a new control interaction.

[0234] • PTP Client: The Precision Time Protocol (PTP) client provides a synchronized time reference for the LTU.

[0235] • Calibration Database: It contains calibration data for looking up calibration values corresponding to the measured values to be used by the interpolator. The comparison between the calibration values and the measured values generates an error, and the control engine uses the error to generate gain values to correct the actuators.

[0236] • Control Plan Cache: It contains the control plans for each closed-loop gain control sent by the planner to the control engine.

[0237] As described above, the supervisor 716 disposes of or reacts to synchronous and asynchronous events originating within the framework as alerts from the controller of the manufacturing process or alerts caused by monitoring certain attributes of the manufacturing process.

[0238] Each supervision plan sent by the planner 710 to the supervisor 716 triggers new actions, which may include starting agents for monitoring QA parameters, adding event filters, adding event forwarders, creating scripts to execute actions to dispose of events.

[0239] The above description discusses the high-level architecture, functional blocks, and interfaces for implementing SDM according to embodiments of the present invention. The following description provides the context of how they can be used to address Industry 4.0 challenges. SDM can support the following use cases of changes in manufacturing cells and manufacturing processes that current solutions do not support.

[0240] Use case for the cooperation of industrial device 406: The cooperation between industrial devices 406 as defined herein addresses several characteristics of the cooperation of industrial devices 406, especially those caused by the combination of an industrial device 406 following a motion plan and an industrial device 406 following a path plan.

[0241] Flow line: The flow line models the flow of activities that an industrial device 406 performs to achieve a given goal, such as:

[0242] • The arm of the industrial device 406 executes steps of a motion plan to manufacture a part. This flow line is called a motion control flow line.

[0243] • Move the mobile industrial device 406 from the starting position to the ending position in the path plan. This flow line is called a path control flow line.

[0244] Task: A task is a set of computational procedures that are executed periodically or aperiodically. Examples of tasks are Linux threads and Linux processes. In a concurrent operating system, real-time tasks are guaranteed to start before their due times. A flow line can contain any one or more of the following real-time tasks:

[0245] • Fine CLGC task: A task that performs the loop of the CLGC algorithm on a fine controller. Each iteration of the CLGC algorithm or loop has a due time to be completed. Therefore, the fine CLGC task must be implemented as a real-time task in a real-time operating system.

[0246] • Coarse CLGC task: A task that performs the loop of the CLGC algorithm implementation on a coarse controller responsible for coarse control. Each iteration of the CLGC algorithm or loop has a due time to be completed. Therefore, the coarse CLGC task must be implemented as a real-time task in a real-time operating system.

[0247] • Motion control: A task that executes one or more steps of a motion plan. Each movement of the motion can have a due time to be completed. Therefore, the motion control task can be implemented as a real-time task in a real-time operating system. Each movement of the motion can have a due time to be completed. Therefore, the motion control task can be implemented as a real-time task in a real-time operating system.

[0248] • Path control: A task that executes one or more steps of a path plan. Each movement of the path can have a due time to be completed. Therefore, the path control task can be implemented as a real-time task in a real-time operating system. Each movement of the path can have a due time to be completed. Therefore, the path control task can be implemented as a real-time task in a real-time operating system.

[0249] • Task ID: The unique task ID can be associated with the task when it is created. The MUTEX server or MUTEX client can use this task ID to identify the current owner of the MUTEX.

[0250] MUTEX: Sometimes, industrial device 406 needs exclusive access to shared resources, such as manufacturing parts of the arm of industrial device 406 or the entrance corridor of the workshop of an autonomous vehicle. These types of access need to be coordinated so that industrial devices 406 do not interfere with or conflict with each other. This exclusive access can be implicitly programmed in the TMP or movement plan. However, it is difficult to complete these plans in complex manufacturing processes, some are probabilistically guaranteed to be discovered by algorithms, and some are prototyped using offline programming [4].

[0251] For cases where no plan is found or additional protection is provided against conflicts, the SDM provides mutex objects or MUTEX. When using a resource protected by a MUTEX, industrial device 406 needs to own the MUTEX before accessing the resource. This ensures that only one controller 718 or one industrial device 406 can access the resource at any given time, and thus helps prevent conflicts. An industrial device 406 that wants to access the resource while another industrial device 406 is accessing it will wait in the MUTEX queue. Once industrial device 406 finishes its access, it releases the MUTEX, and the next industrial device 406 in the MUTEX queue can access it.

[0252] The control tasks defined in the SDM are usually real-time. Therefore, isochronous real-time communication with low latency, low jitter, and high reliability must be used to implement network MUTEX. These requirements are typical requirements of time-sensitive networking (TSN).

[0253] MUTEX has MUTEX IDs and owners associated with them:

[0254] • MUTEX ID: The MUTEX ID is used to identify the MUTEX in every MUTEX operation except MUTEX creation.

[0255] • Owner: The MUTEX has an active owner associated with the MUTEX, which is the ID of the task that exclusively accesses the resource protected by the task.

[0256] Each manufacturing process instance (MPI) has an interface to the MUTEX server 720 or the MUTEX region where MUTEX can be created, maintained, and destroyed. Stream tasks can access the MUTEX in this region through a naming service.

[0257] Since tasks in a streamline can run in different network devices, MUTEX can be created, accessed, and destroyed through network protocols. The network protocol can have the following synchronization messages:

[0258] • Create: It creates a MUTEX and returns its MUTEX ID. The MUTEX ID can be used to search through the naming service of the SDM.

[0259] • Lock: A task can use it to request an exclusive MUTEX. After the message is confirmed, the task owns the MUTEX. Exclusive access to the MUTEX is only available to the owner task of the MUTEX.

[0260] • Unlock: A task can use it to release the exclusive MUTEX. After the message is confirmed, the task no longer owns the MUTEX. The MUTEX is released so that any other task can obtain exclusive access.

[0261] • Destroy: A task can use it to request the destruction of the MUTEX. After the message is confirmed, the MUTEX is no longer available.

[0262] The MUTEX protocol preferably should use a real-time isochronous protocol with very low latency and reliability for communication.

[0263] Figure 18 An example is shown of using two MUTEXes to protect access to manufacturing parts in MPI and access to an autonomous vehicle. In this example, the TMP plan of streamline 1 defines two motion control tasks. The first motion control task controls the arm 1 of industrial device 406 that performs some manufacturing tasks on the part. The second motion control task controls the second industrial device 406 arm that grabs the part and places it inside the autonomous vehicle. Once the part is inside the autonomous vehicle, the autonomous vehicle transports it to the destination, which is carried out by a path control task defined in the path plan. Figure 19 An example sequence of lock and unlock operations performed by all three tasks to coordinate the entire manufacturing process from starting to manufacture the part to transporting it to the destination is shown.

[0264] Use case of adaptive adjustment through industrial device 406 control

[0265] Control type. The control plan can define fine control or coarse control (see the definitions in the background art section).

[0266] Control Plan Specification and Generation. If needed, any language in the IEC 61131-3 programming language can be used to write the control plan. The process of generating the control plan can be accomplished through an automated process that obtains the order and resource specifications from the cell processing database and uses, for example, structured text to generate the control plan. The control plan can be developed as part of the manufacturing process defined by the planner.

[0267] Control Function Blocks. Fine control and coarse control are implementations of closed-loop control. They are integrated in such a way that they work with different time granularities of measurement and gain to adjust one or more variables as described above. Figure 20 A parallel configuration of the coarse / fine CLGC is shown. In this configuration, the fine CLGCs are independent of each other. The behavior of one loop does not affect the behavior of other loops. Figure 21 An example serial configuration of the coarse / fine CLGC is shown. In the serial configuration, the CLGC loops are cascaded. Therefore, the behavior of any CLGC loop affects the behavior of other CLGC loops.

[0268] In both configurations, the function blocks are:

[0269] • Variable Gain Processor (VGP) ( ): The variable gain processor is the block that models the actuator for the manufacturing process and the control process output. The VGP block accepts two signals, namely, the input signal of the first VGP or that of another VGP and the correction signal ( ) of the application function. The result is the output signal .

[0270] • Fine Controller ( ): It is the function block that calculates the correction ( ) to be applied to the VGP .

[0271] • Summing Device ( ): The summing device is the device that compares the output of the instrument with a predefined expected value . The difference is called the error signal.

[0272] • Instrument ( ): The instrument is the device that measures the output signal for a given measurement signal .

[0273] • Coarse Controller ( ): It is the controller for coarse control. It receives the error from the summing device .

[0274] • Sensor ( ): The sensor is connected to the controller .

[0275] The function block exchanges the following signals:

[0276] • Input signal ( ): The input signal, which is applied to the VGP in the industrial device 406, causing the property to change.

[0277] • Output signal ( ): It is the value generated from the action of the VGP.

[0278] • Measured output signal ( ): It is the measured value of the output signal .

[0279] • Target value ( ) and ( ): It is the expected value or set point. The coarse controller has the corresponding target value .

[0280] • Error signal ( ): It is the difference .

[0281] • Fine control correction signal ( ): It is the input generated from the controller . • Sensor signal (

[0282] ): It is the signal measured from the environmental sensor . • Coarse control correction signal (

[0283] ): It is the input generated from the coarse controller . • For the closed-loop gain control as shown in , the following relationship is valid:

[0284] For Figure 21 shown closed-loop gain control, the following relationship is valid:

[0285] , for and

[0286]

[0287] wherein is the number of sensors connected to , and .

[0288] , for

[0289]

[0290] wherein is the number of sensors connected to .

[0291] Fine control is performed in a fine controller ( ). Each controller is independent of other controllers and generates a control signal given by , wherein is the number of sensors connected to .

[0292] is typically an industrial plant specific function, but the industrial plant controller can supply the fine controller based on any control function, such as one of the controller types defined previously. For example, a proportional-integral (PI) controller is defined by making the following mapping:

[0293]

[0294] where:

[0295] is a function that compensates for the environmental parameters sensed by the sensors.

[0296] For example, VGP can control the rear wheel speed of an autonomous vehicle to keep it constant. The corresponding gauge can sense that the speed has deviated and that the vehicle will have to accelerate. The corresponding can give an initial correction in terms of increasing the acceleration . However, a traction sensor mounted on the wheel can sense the smoothness of the ground. The corresponding function can provide negative feedback to avoid a full speed increase given by . Other examples of

[0297] ​Fine controller implemented in industrial device 406. When a fine controller is implemented in industrial device 406 controlled by an industrial device controller via the CFCP protocol, the industrial device controller sends a closed-loop gain control capability request message to the fine controller, and the fine controller responds with an acknowledgement of the capability, i.e., the fine controller implemented in industrial device 406 under the control of the industrial device controller allocates the capability.

[0298] Fine controller implemented in industrial device controller. A fine controller can be implemented in the industrial device controller to control the VGP implemented at industrial device 406, which has feedback signals from meters near industrial device 406 and environmental sensors. The fine controller at the industrial device controller can discover the capabilities of the VGP, meters, and sensor characteristics through the CFCP capability negotiation messages of the VPG, meters, and sensors respectively.

[0299] Coarse control. Coarse control is performed in the coarse controller ( ). The general control function combines all errors m from sensors and data to generate a control vector . Each element in this vector is a control value that is applied to the fine controller along with . Therefore, is composed of closed control gain loop controllers, and each controller generates a signal . Such individual controllers can be from one of the controller types defined above. For example, global control can be composed of a series of n integral controllers using the following mapping:

[0300]

[0301] where:

[0302] : This is the coarse error threshold the difference between and the error. is a function to compensate for the environmental parameters sensed by the sensors in the global controller block.

[0303] Coarse and fine control protocol (CFCP). The coarse and fine control protocol (CFCP) can be a peer-to-peer client / server protocol. It can be used as an application layer transport protocol specifically designed to transfer packet data from a device controlled by a CLGC controller to the CLGC controller / to transfer packet data from the CLGC controller to a device controlled by the CLGC controller:

[0304] • VGP: Variable Gain Processor: A device that receives commands from the CLGC controller and modifies some attributes of the manufacturing process to adjust its output.

[0305] • Meter: A specialized sensor that is responsible for collecting samples of the manufacturing process output for feedback to the CLGC controller.

[0306] • Sensor: A specialized sensor that samples some attributes of the manufacturing process (not the output) or the environment around it and feeds back to the CLGC controller.

[0307] The requirements of CFCP may include any one or more of the following:

[0308] • Small packets for real-time transmission: The CFCP packets for synchronizing real-time and isochronous real-time transmissions should be very small to fit into a few 4G / 5G resource blocks without being generated over several 4G / 5G time slots (see the resource block allocation mechanism).

[0309] • Option to duplicate packets: Since the reliability requirements for IRT transmissions are very high, duplicating packets is a technique that can be used to improve the reliability of the network. This can be done automatically by the CFCP layer or activated by the CLGC controller.

[0310] • Support for capability negotiation between the device and the controller.

[0311] • Agnostic to the supported network.

[0312] For real-time transmission, CFCP packets should preferably use an average of two 4G resource blocks.

[0313] CFCP packets for non-real-time transmission: These packets are used for capability negotiation and association negotiation. There is no limit on the size of CFCP packets.

[0314] CFCP packets for synchronous real-time transmission: These packets are used for synchronous real-time transmission. These packets should preferably fit into an average of two LTE resource blocks.

[0315] CFCP packets for isochronous real-time transmission: These packets are used for isochronous real-time transmission. These packets should preferably fit into an average of two LTE resource blocks.

[0316] Examples of fine control and coarse control

[0317] Example 1: Figure 22 A production line showing autonomous vehicles 406 for transporting parts manufactured in the manufacturing process. The autonomous vehicles 406 are one after another. Although the distance difference between the autonomous vehicles is kept as small as possible, they are spaced by a variable distance (d).

[0318] Each autonomous vehicle 406 has two electric motors. Figure 23 The control of these motors of the autonomous vehicle 406 modeled as streamline is shown. The two motors are controlled by thin CLGC controllers (C1 and C2) that command each motor to rotate. The feedback signals of these two controllers come from tachometers or encoders (M1 and M2). The distance between autonomous vehicles is controlled by a thick CLGC controller (G). The feedback signal of G comes from one of the proximity sensors (S) in each autonomous vehicle.

[0319] Assume that i indicates the motor (for the first motor i = 1, and for the second motor i = 2), Figure 23 the tags in have the following definitions:

[0320] • : The actuator (PWM controller) of motor i.

[0321] • : The tachometer of motor i.

[0322] • : The thin CLGC controller of motor i.

[0323] • : The proximity sensor between this autonomous vehicle and the next autonomous vehicle.

[0324] • : The current of motor i.

[0325] • : The target speed of motor i.

[0326] • : The error difference between the measured speed (derived from mi) and the target speed (ti) of motor i.

[0327] • : The rotation of motor i.

[0328] • : The rotation value of motor i.

[0329] • : The increase of the PWM pulse of motor i.

[0330] • : The compensation caused by the proximity sensor.

[0331] • : Speed alarm.

[0332] • : The proximity value from sensor S.

[0333] • : Coarse CLGC controller.

[0334] • : Supervisor

[0335] In the case where the error cannot be corrected, the supervisor (H) receives an event (speed alert) from the coarse controller.

[0336] Streamline 1:

[0337] CLGC plan:

[0338]

[0339] The controller C1 is a PID controller defined by the following formula:

[0340]

[0341] The two front wheels can be rotated by means of their wheel servos. They are controlled by a path controller following a path plan. Figure 24 This path control modeled as a streamline is shown. Two fine controllers (C1 and C2) control the angles of the wheels, and the coarse control (G) controls the angle of the autonomous vehicle. These controllers receive feedback signals from the gauges (M1 and M2), which measure this angle using a fixed reference (such as the middle boundary of the lane (the yellow line of the road) or the roadside line of the road).

[0342] Assume that i indicates the wheel (i = 1 for the first wheel and i = 2 for the second wheel), Figure 24 the labels in have the following definitions:

[0343] • : Actuator of wheel servo i (PWM controller).

[0344] • : Angle reader of wheel i.

[0345] • : Fine CLGC controller of wheel i.

[0346] • : Sensor of the angle between this autonomous vehicle and the reference line.

[0347] • : Current of wheel servo i.

[0348] • : Target angle of wheel i.

[0349] • : Angle of wheel i.

[0350] • : Angle of wheel i.

[0351] • : Increase in PWM pulse of wheel servo i.

[0352] • : Compensation due to angle sensor (S) of autonomous vehicle.

[0353] • : Angle alarm.

[0354] • : Angle of autonomous vehicle.

[0355] • : Coarse CLGC controller.

[0356] • : Supervisor.

[0357] Supervision plan:

[0358]

[0359] Example 2

[0360] This example shows the case of cascading streamlines in sequence. The output of a streamline is the input of the next streamline, unless it is the last streamline in the sequence. The output of the last streamline is the output of the streamline sequence.

[0361] Figure 25 An example of an assembly line is shown. The assembly line contains four industrial device 406 arms. The industrial device 406 arms are placed along the line to perform some manufacturing tasks on the parts passing through the industrial device 406. Each industrial device 406 has a defined task due time. After the due time, the next industrial device 406 can start its task on the manufactured part in production. To maintain the most efficient time alignment between industrial devices 406, Figure 26 The streamlines shown model the control of the servos in each industrial device 406 arm. The streamline contains: four cascaded fine control loops, each of which controls the speed of the servo; and a coarse control loop that coarsely controls these speeds after a certain speed threshold.

[0362] Assume i indicates the servo (for the first wheel i = 1, and for the second wheel i = 2), Figure 26 the labels in have the following definitions:

[0363] • : Actuator (PWM controller) of servo i.

[0364] • : Tachometer of servo i.

[0365] • : The fine CLGC controller of servo i.

[0366] • : The current of servo i.

[0367] • : The rotation target of servo i.

[0368] • : The output rotation of servo i.

[0369] • : The measured rotation of servo i.

[0370] • : The adjustment of the PWM pulse for servo i.

[0371] • : The compensation for servo i due to coarse control.

[0372] • : The alarm for time calibration of the industrial device 406 control.

[0373] • : The coarse CLGC controller.

[0374] • : The supervisor.

[0375] Use case with self - repair and quality assurance for industrial device supervision

[0376] Supervision is control with a maximum response time. Supervisory control allows a longer time interval than CLGC to take actions to correct problems detected during fine and coarse CLGC that cannot be corrected by changing the gain from VGP.

[0377] Self - repair: Supervision is characterized by the self - repair property, which is a supervisory property that corrects a certain defect or problem in the MPI following abnormal manufacturing conditions. The supervision function block monitors the control functions of the fine and coarse CLGC. Additionally, supervision can also monitor the properties of the environmental sensors in the MPI, and if the predetermined conditions are not met, it may raise an alarm to the IoT cloud 708 or perform a self - repair operation.

[0378] Control stability: It indicates how frequently the output deviates from the target value.

[0379] Control convergence: It is the average time for the PV to converge to the PS (or very close to the PS).

[0380] In the case where some of these attributes deviate from the acceptable intervals, the supervisor triggers self - repair actions, which will apply some predefined corrections outside the control function block, such as:

[0381] Recalibration: Stop the streamline and apply a recalibration sequence specific to the industrial device 406 or remap the factory floor of the autonomous vehicle.

[0382] Switching: A defective industrial device 406 in the streamline can be replaced with another industrial device 406 in good working condition. Perform a task switch from the defective industrial device 406 to the new industrial device 406 in the streamline.

[0383] Route re - selection: Determine (force) a new route for the autonomous vehicle.

[0384] Maintenance service: The industrial device 406 can be maintained periodically or on - demand, such as replacing the tool in the robotic arm industrial device 406 or replacing the sensor or the industrial device 406 battery with a new battery.

[0385] Monitoring for quality assurance:

[0386] The manufacturing process can specify quality - assurance control parameters that trigger the instantiation of the supervisory monitors for these parameters. Depending on the supervision plan, these monitors can trigger events if these parameters are not met.

[0387] Quality assurance through timely calibration. Before executing the manufacturing process, the MPI verifies the status of the processing cell to determine if any calibration is required. If the PC requires calibration, the MPI moves to the uncalibrated state and can initiate the calibration procedure of the processing cell during the maintenance window. It is costly to find any defective products being manufactured, and it is also very costly to suspend any ongoing manufacturing process because any unplanned interruption will have an economic impact. In other words, the value of the products that could be manufactured during the downtime cannot be realized.

[0388] Calibration plan

[0389] The calibration plan can include any one or more of the following:

[0390] • The recommended calibration periodicity for each industrial device 406.

[0391] • Thresholds of process variables and environmental variables that trigger calibration through fine and coarse control tasks.

[0392] • The expected calibration time.

[0393] • Optionally, a calibration script for performing automatic calibration when supported by the industrial device 406. Otherwise, manual calibration can be performed.

[0394] • Calibrated calibration references, such as:

[0395] • A reference part for calibrating a certain process and environmental variables such as time alignment, position alignment.

[0396] • A label for a position reference used to calibrate a position sensor.

[0397] • Remapping an industrial facility by mapping an automated industrial device 406.

[0398] Use cases for production scaling

[0399] Production scaling: It is to increase or decrease order production through a software interface during the manufacturing process. Figure 27 An example of an order to increase production capacity is shown. This action on the SDM can be triggered by the SDM planner or by a human operator through the SDM software interface.

[0400] Use cases for fault recovery of replacing an industrial device 406

[0401] Replacement of industrial device 406: It is a maintenance action to replace a defective industrial device 406 as Figure 28 shown. This action can be automatically triggered by SDM supervision or by a human operator through the SDM software interface.

[0402] Use cases for order adaptation of repositioning an industrial device 406

[0403] Production repositioning: It is to physically reposition the manufacturing process to a new area in the factory. Figure 29 The use case is shown in. This action can be automatically triggered by SDM supervision, triggered by the SDM planner, or triggered by a human operator through the SDM software interface.

[0404] Figure 30 An example of a cloud-based deployment of software-defined manufacturing is shown. The IoT cloud represents an information network implemented using cloud technology. The IoT cloud implements several services such as manufacturing order dispatching, SDM health reports, SDM management. The planner is responsible for generating the manufacturing process definition, and each streamline includes the manufacturing process of the streamline and its associated plans (control plan, supervision plan, motion plan, transportation plan). The planner also maintains a centralized database with physical resource definitions. The scheduler can be located in the cloud, and it dispatches instructions to the controller and supervisor.

[0405] If real-time response and closed-loop control are not required in the deployment, the controller and supervisor can also reside in the cloud. For the purposes of this discussion, we assume that they are edge computing and reside on the premises. The scheduler is responsible for instantiating cells to generate orders using streamline definitions and a centralized resource database. The scheduler allocates industrial plant 406 and any other physical resources in the processing cell. It also operates the processing (start, pause, stop).

[0406] Although the processes in the figures may show a particular order of operations performed by certain embodiments of the present disclosure, it should be understood that such order is representative and alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.

[0407] Those skilled in the art will recognize improvements and modifications to the embodiments of the present disclosure. All such improvements and modifications are considered to be within the scope of the concepts disclosed herein.

Claims

1. A software-defined manufacturing system in a cellular network, comprising: At least one access node configured to wirelessly transmit and receive signals to and from industrial devices located within at least two cells of a cellular communication network deployed within a manufacturing facility, wherein the cellular communication network complies with the 5G NR standard and has ultra-reliable low-latency communication (URLLC) capabilities; A computer system, comprising: An interface connected to transmit and receive signals to and from the access node using URLLC; and Processing circuitry configured to: Define a manufacturing process instance (MPI) that identifies the manufacturing operations necessary to perform a predetermined manufacturing process; Assign one or more of the industrial devices to the MPI, each assigned industrial device being configured to perform at least one of the identified manufacturing operations; and Implement a controller configured to control each of the industrial devices assigned to the MPI by performing the following steps in each cycle of an iterative process: Transmit a command signal to a selected one of the industrial devices assigned to the MPI using URLLC; and Receive a response signal from the selected one of the industrial devices using URLLC.

2. The system according to claim 1, wherein The industrial devices include any one or more of the following: Industrial robots; Sensors; Actuators; and Machine controllers.

3. The system according to claim 1, wherein The cellular communication network is isolated from a public land mobile network (PLMN) by any one or more of the following: Either or both of an encryption protocol and at least one encryption key; Spatial separation; And Radio frequency shielding.

4. The system according to claim 1, wherein All of the industrial devices assigned to the MPI are located within a common cell of the cells of the cellular communication network.

5. The system according to claim 1, wherein, At least one of the industrial devices assigned to the MPI is located within one cell of the cellular communication network, and another of the industrial devices assigned to the MPI is located within a different cell of the cellular communication network.

6. The system according to claim 1, wherein, The processing circuitry is further configured to implement a supervisor configured to monitor the operation of each of the industrial devices assigned to the MPI.

7. The system according to claim 1, wherein, The processing circuitry is further configured to implement a MUTEX server configured to control access by the industrial devices assigned to the MPI to resources of the manufacturing facility shared with industrial devices assigned to different MPIs.

8. The system according to claim 1, wherein The processing circuitry is further configured to implement a location server configured to record the current location within the manufacturing facility of each of the industrial devices assigned to the MPI.

9. The system according to claim 1, wherein, The response signal includes closed-loop gain control (CLGC) data.

10. The system according to claim 1, wherein, The command signal is at least partially based on: a particular manufacturing operation associated with the selected one of the industrial devices; and the response signal received from the selected one of the industrial devices in a previous cycle of the iterative process.

11. A computer-implemented software-defined manufacturing method in a cellular network, comprising: Wirelessly transmit and receive signals to and from industrial devices located within at least two cells of a cellular communication network deployed within a manufacturing facility, wherein the cellular communication network complies with the 5G NR standard and has ultra-reliable low-latency communication (URLLC) capabilities; Define a manufacturing process instance (MPI) that identifies the manufacturing operations necessary to perform a predetermined manufacturing process; Assign one or more industrial devices to the MPI, each assigned industrial device being configured to perform at least one of the identified manufacturing operations; And Implement a controller configured to control each of the industrial devices of the MPI by performing the following steps in each cycle of an iterative process: Transmit a command signal to a selected one of the industrial devices assigned to the MPI using URLLC; and Receive an acknowledgment signal from the selected one of the industrial devices using URLLC.

Images