Patent Description:
Industry <NUM> is a term that has been used to describe current trends of automation and data exchange in manufacturing technologies. This so-called fourth industrial revolution has the potential to significantly boost productivity, reduce costs and improve product quality. Essentially, Industry <NUM> aims to enable fine control of the production at every step of the process, therefore improving quality. It also helps to reduce and even eliminate downtime, because data supplied by manufacturing equipment (such as industrial robots) can be used to schedule maintenance or predict breakdowns.

While Industry <NUM> encompasses a range of goals and desired results, there is currently no reference architecture defining how industrial systems may be organized and operated to achieve these goals.

The International Electrotechnical Commission (IEC) has published various standards related to automated manufacturing systems. For example, IEC <NUM>-<NUM> is the third part of the open international standard IEC <NUM> for programmable logic controllers (PLCs). The current (third) edition was published in February <NUM>, and details the basic software architecture and programming languages of the control program within a PLC. It defines three graphical and two textual programming language standards as follows:.

IEC <NUM>, was initially published in <NUM>, and addresses the topic of function blocks for industrial process measurement and control systems. This specification defines a generic model for distributed control systems and is based on the IEC <NUM> standard.

While the IEC standards provide functional blocks that may be used for automated control of industrial systems, they do not address the system performance requirements needed to implement the concepts of Industry <NUM>.

<CIT> discloses a software-defined technology and system which reference architecture for designing, managing, and providing a highly available, scalable, and flexible automation system.

<CIT> discloses a Fog Computing Facilitated Flexbile Factory for manufacturing a variety of components that share a common trait. The mechanism uses fog computing as edge device controllers as well as edge devices to perform the required control, communications, analytics and data processing at the factory site to achieve the flexible factory.

Aspects of the present invention provide a system according to independent claim <NUM> and a method according to independent claim <NUM>. Further embodiments of the system are provided in dependent claims <NUM>-<NUM>.

The accompanying drawing figures incorporated in and forming a part of this specification illustrate several aspects of the disclosure, and together with the description serve to explain principles of the disclosure.

At least some of the following abbreviations and terms may be used in this disclosure.

Wireless Device: As used herein, a "wireless device" is any type of device that has access to (i.e., is served by) a cellular communications network by wirelessly transmitting (and/or receiving) signals to (and/or from) a radio access node.

Cell: As used herein, a "cell" is a combination of radio resources (such as, for example, antenna port allocation, time and frequency) that a wireless device may use to exchange radio signals with a radio access node, which may be referred to as a host node or a serving node of the cell. However, it is important to note that beams may be used instead of cells, particularly with respect to <NUM> NR. As such, it should be appreciated that the techniques described herein are equally applicable to both cells and beams.

Note that references in this disclosure to various technical standards (such as <NPL>) and <NPL>), for example) should be understood to refer to the specific version(s) of such standard(s) that is(were) current at the time the present application was filed, and may also refer to applicable counterparts and successors of such versions.

The description herein focuses on a 3GPP cellular communications system and, as such, 3GPP terminology or terminology similar to 3GPP terminology is oftentimes used.

<FIG> is a block diagram schematically illustrating a communications system <NUM> including a computing device <NUM> usable in embodiments of the present invention.

In the example of <FIG>, the communications system <NUM> generally includes computing device <NUM> connected to one or more networks <NUM> and one or more radio units <NUM>. The computing device <NUM> includes one or more processors <NUM>, a memory <NUM>, one or more network interfaces <NUM>. The processors <NUM> may be provided as any suitable combination of microprocessors (µPs), Central Processing Units (CPUs), Application Specific Integrated Circuits (ASICs), Field Programmable Gate Arrays (FPGAs), or the like. Similarly, the memory <NUM> may be provided as any suitable combination of Random Access Memory (RAM), Read Only Memory (ROM) and mass storage technologies such as magnetic or optical disc storage or the like. The network interfaces <NUM> enable signaling between the computing device <NUM> and the networks <NUM>, such as a core network (not shown), a data network (not shown), or a private domain network such as a data center (not shown).

Each radio unit <NUM> typically includes at least one transmitter (Tx) <NUM> and at least one receiver (Rx) <NUM> coupled to one or more antennas <NUM>. In the example of <FIG>, the radio unit(s) <NUM> is(are) shown as being external to the computing device <NUM> and connected to the computing device <NUM> via a suitable physical connection (such as a copper cable or an optical cable). In the example of <FIG>, the radio unit(s) <NUM> is(are) shown as being connected to computing device <NUM> via a network <NUM> and a network interface <NUM>. In still other embodiments, the radio unit(s) <NUM> and optionally also the antenna(s) <NUM> may be integrated together with the computing device <NUM>.

The one or more processors <NUM> operate to provide functions of the computing device <NUM>. Typically, these function(s) are implemented as software applications (APPs) <NUM> or modules that are stored in the memory <NUM>, for example, and executed by the one or more processors <NUM>. In some embodiments, one or more software applications or modules <NUM> may execute within a secure run-time environment (RTE) <NUM> maintained by an operating system (not shown) of the computing device <NUM>.

It may be appreciated that specific embodiments may exclude one or more of the elements illustrated in <FIG>. For example, a computing device <NUM> configured to implement a wireless device of a radio access network may incorporate one or more processors <NUM>, a memory <NUM>, and one or more radio units <NUM>, but may exclude a network interface <NUM>. Conversely, a computing device <NUM> configured to implement a server in a core network, for example, may include one or more processors <NUM>, a memory <NUM>, and one or more network interfaces <NUM>, but may exclude radio units <NUM>. A computing device <NUM> configured to implement a base station of a radio access network, on the other hand, will normally include one or more processors <NUM>, a memory <NUM>, and both radio units <NUM> and network interfaces <NUM>.

<FIG> is a block diagram schematically illustrating an example architecture <NUM> for system virtualization usable in embodiments of the present invention. It is contemplated that computing systems may be physically implemented using one or more computing devices (any or all of which may be constructed in accordance with the system <NUM> described above with reference to <FIG>) interconnected together and executing suitable software to perform its intended functions. Those of ordinary skill will recognize that there are many suitable combinations of hardware and software that may be used for this purpose, which are either known in the art or may be developed in the future. For this reason, a figure showing physical hardware components and connections is not included herein.

As maybe seen in <FIG>, the illustrated architecture <NUM> generally comprises hosting infrastructure <NUM>, a virtualization layer <NUM> and an Application Platform Services layer <NUM>. The hosting infrastructure <NUM> comprises physical hardware resources provided by the infrastructure on which the architecture <NUM> is being implemented. These physical hardware resources may include any or all of the processors <NUM>, memory <NUM>, network interfaces <NUM> and radio units <NUM> described above with reference to <FIG>, and may also include traffic forwarding and routing hardware <NUM>. The virtualization layer <NUM> presents an abstraction of the hardware resources <NUM> to the Application Platform Services layer <NUM>. The specific details of this abstraction will depend on the requirements of the applications <NUM> being hosted by the Application Platform Services layer <NUM>. Thus, for example, an APP <NUM> that provides traffic forwarding functions may be presented with an abstraction of the hardware resources <NUM> (e.g. processor(s) <NUM>, memory <NUM> and traffic forwarding hardware <NUM>) that simplifies the implementation of traffic forwarding policies. Similarly, an application that provides data storage functions may be presented with an abstraction of the hardware resources <NUM> (e.g. processor(s) <NUM> and memory <NUM>) that facilitates the storage and retrieval of data (for example using Lightweight Directory Access Protocol - LDAP).

The application platform <NUM> provides the capabilities for hosting applications. In some embodiments, the application platform <NUM> supports a flexible and efficient multi-tenancy run-time and hosting environment for applications <NUM> by providing Infrastructure as a Service (laaS) facilities. In operation, the application platform <NUM> may provide a security and resource "sandbox" for each application <NUM> being hosted by the platform <NUM>. Each "sandbox" may be implemented as a Virtual Machine (VM) image <NUM> that may include an appropriate operating system and controlled access to (virtualized) hardware resources <NUM>. Alternatively, each "sandbox" may be implemented as a container <NUM> that may include appropriate virtual memory and controlled access to a host operating system and (virtualized) hardware resources <NUM>. The application platform <NUM> may also provide a set of middleware application services and infrastructure services to the applications <NUM> hosted on the application platform <NUM>, as will be described in greater detail below.

Applications <NUM> from vendors, service providers, and third-parties may be deployed and executed within a respective Virtual Machine <NUM>. Communication between applications <NUM> and services of the application platform <NUM> may conveniently be designed according to the principles of Service-Oriented Architecture (SOA) known in the art.

Communication services <NUM> may allow applications <NUM> to communicate with the application platform <NUM> (through pre-defined Application Programming Interfaces (APIs) for example) and with each other (for example through a servicespecific API).

A Service registry <NUM> may provide visibility of the services available on the server <NUM>. In addition, the service registry <NUM> may present service availability (e.g. status of the service) together with the related interfaces and versions. This may be used by applications <NUM> to discover and locate end-points for the services they require, and to publish their own service end-point(s) for other applications to use.

Network Information Services (NIS) <NUM> may provide applications <NUM> with low-level network information pertaining to a network service instance or one or more Protocol Data Unit (PDU) sessions, for example.

A Traffic Off-Load Function (TOF) service <NUM> may prioritize traffic, and route selected, policy-based, data streams to and from applications <NUM>.

<FIG> illustrates an example manufacturing framework, along with a respective latency tolerance for each layer of the framework. In this respect, the term latency refers to the delay between the time that a message is transmitted and the time that the message is received. This message can be a command, a request, an acknowledgement or a response. As may be seen in <FIG>, planning and management functions can operate with a relatively high latency, whereas control functions require significantly lower latency.

It should be noted that conventional industry automation standards do not explicitly distinguish between coarse and fine control levels. This reflects the conventional system architecture, in which the Industrial Device controller is co-located with the Industrial Device itself, and directly controls all of the Industrial Device's various arms, tools, sensors, and actuators. In this architecture, the relevant latency tolerance relates to the Industrial Device controller, because the latency of the various components of the Industrial Device is not visible to the rest of the system.

On the other hand, the present disclosure contemplates that the ultra-reliable low latency communications (URLLC) capability of <NUM> NR can be used in embodiments of the present invention. In such cases, the distinction between coarse and fine levels of control, and their associated latency tolerances, is useful.

This document defines the coarse control and fine control as:.

Typically, an Industrial facility is composed of industrial devices (such as Industrial robots and other equipment) from different vendors. The processes of planning, management and control are treated as separate tasks. Each vendor normally offers its own proprietary management solution, which may or may not interact with management solutions of other vendors. A technician normally decides the role of each industrial device for a given process, and then must develop and install appropriate scripts for each device. In some case, this requires the technician to travel to each device to program it. Since an industrial operator typically has multiple tools, it is difficult to manage the end-to-end operation.

Some Industrial Devices in manufacturing industries rely on an Open Source standard called 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 popular in industry. However, ROS does not support real-time capabilities required by most of the industrial devices. Therefore, a ROS variant called ROS-Industrial, which provides real-time support and other required capabilities for Industrial Device is becoming increasingly popular. ROS-Industrial is an open source solution that contains libraries, tools and drivers for industrial hardware. It is supported and guided by the ROS-Industrial Consortium.

Systems and methods are disclosed herein that provide an integrated system for controlling and managing industrial devices. In accordance with embodiments of the present invention, a system comprises: at least one access node configured to wirelessly transmit and receive signals to and from industrial devices within at least two cells of a cellular communications network deployed within an industrial facility; and a computer system that comprises: 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, identifying industrial operations necessary to perform a predetermined industrial process; allocate one of more of the industrial devices to the MPI, each allocated industrial device configured to perform at least one of the identified industrial operations; and implement one or more Controllers configured to control each of the industrial devices allocated to the MPI to cooperatively perform the predetermined industrial process.

For the purposes of the present disclosure, an industrial facility is any area (which may be composed of one or more buildings and/or yards) used for an industrial purpose such as manufacturing, storage or transport. Examples of industrial facilities include (but are not limited to) factories, warehouses, fulfillment centers, storage yards, rail yards, port facilities and the like.

For the purposes of the present disclosure, a manufacturing process refers to a sequence of one or more operations that yields a defined result. For example, in a factory, a manufacturing process may comprise the operations that need to be performed to convert a feed-stock (e.g. raw material) into a finished part. In an assembly plant, a manufacturing process may comprise operations for assembling multiple parts in a defined order to produce a finished 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 transport. For example, in a rail-yard context, an industrial process may refer to the sequence of operations required to remove a shipping container from a rail car, temporarily store the shipping container in a storage yard, and subsequently place the shipping container on a transport trailer.

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

For the purposes of the present disclosure, an industrial device refers to any machine or equipment that is configured to perform one or more industrial operations, and is also capable of communicating with computer systems in accordance with the present disclosure. Examples of industrial devices include (but are not limited to) industrial robots, autonomous vehicles, autonomous guided vehicles (AGVs), sensors, actuators, and controllers (which may be associated with other machines such as milling machines or stamping machines, for example).

<FIG> illustrates one example of a cellular communications network <NUM> in accordance with embodiments of the present disclosure. In the embodiments described herein, the cellular communications network <NUM> may conform to one or more of the LTE, <NUM> and <NUM> NR standards, or their successors. In the illustrated example, the cellular communications network <NUM> includes a Radio Access Network (RAN) <NUM> comprising access nodes 404A and 404B controlling radio communications with industrial devices 406A. <NUM> within corresponding cells 408A and 408B. Each cell <NUM> may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT), modulation scheme and access node identifiers. In some embodiments, a cell <NUM> may be referred to as a manufacturing cell (MC).

Access nodes 404A and 404B can be any type of network access device capable of establishing radio connection(s) with one or more industrial devices <NUM> within a respective coverage area of the access node <NUM>, and further configured to forward signaling traffic between the industrial devices <NUM> and a core network <NUM>.

An important feature of an access node <NUM> is that it is configured with both a radio interface configured to send and receive radio signals to and from industrial devices <NUM>, and a network interface configured to exchange electronic and/or optical signals with the core network <NUM>. Examples of access nodes <NUM> include: Evolved Node B (eNB) and gNB systems (known, for example, in the 3GPP standards): WiFi access points (known, for example from IEEE <NUM> standards) or the like. In some contexts, an access node <NUM> may be referred to as an access point (AP) regardless of the Radio Access Technology (RAT) that it supports.

Industrial devices <NUM> can be any type of industrial equipment or machinery configured with radio and/or wired communications circuitry capable of sending and receiving signals to and from an access node <NUM>. Examples of industrial devices <NUM> include industrial robots, sensors, actuators, machine controllers, mobile computers, Internet of Things (IoT) devices, autonomous vehicle controllers, AGV controllers and the like. In some contexts, an industrial device <NUM> may be referred to as a User Equipment (UE) or a mobile device.

In some embodiments, the cells 408A and 408B may overlap each other. For example, a particular cell 408A may be one among a plurality of cells covering a common geographical region and having a common RAT and modulation scheme, but using respective different frequencies and/or access point (AP) identifiers. In such cases, an industrial device <NUM> located within a region covered by two or more overlapping cells <NUM> may send and receive radio signals to and from each of the corresponding access nodes <NUM>.

In the illustrated example, the RAN <NUM> is connected to a Core Network (CN) <NUM>, which may also be referred to as Evolved Core Network (ECN) or Evolved Packet Core (EPC). The CN <NUM> includes (or, equivalently, is connected to) one or more servers <NUM> configured to provide networking services (such as, for example, Network Functions (NFs) described in 3GPP TS <NUM> V15. <NUM> (<NUM>-<NUM>) "System Architecture for the <NUM> System" and its successors) as control and supervision services for industrial devices <NUM>. The CN <NUM> may also include one or more gateway (GW) nodes <NUM> configured to connect the CN <NUM> to a packet data network (DN) <NUM> such as, for example, the internet. A gateway node <NUM> may be referred to as a packet gateway (PGW) and/or a serving gateway (SGW). The DN <NUM> may provide communications services to support end-to-end communications between servers <NUM> and one or more application servers (ASs) <NUM>. In some contexts, an application server (AS) <NUM> may also be referred to as a host server.

It should be appreciated that the separation between the CN <NUM> and the DN <NUM> can be purely logical, in order to simplify understanding of their respective roles. In particular, the CN <NUM> is primarily focused on providing industrial device access, control and supervision functions and supporting wireless device mobility within a particular industrial facility. On the other hand, the DN <NUM> is primarily focused on providing end-to-end communications and management functions across multiple industrial facilities. However, it will be appreciated that both the CN <NUM> and the DN <NUM> can be implemented on common physical infrastructure, if desired.

In conventional techniques, an industrial process happens in an industrial facility that provides a set of rigidly defined resources, such as Industrial Devices <NUM>, performing pre-defined tasks to achieve a determined goal. For example, in an automobile assembly line, several Industrial Devices <NUM> can collaborate to assemble an automobile. The assembly line is optimized to build a specific model of automobile with high efficiency. Unfortunately, the trade-off is that this process is rigid in that it cannot easily be changed to produce a different type or model automobile. To do the change, several modifications have to be performed such as modifying the Industrial Device <NUM> programming and tools, re-adapting some machinery to new specifications of the new automobile, creating or deleting new tasks, and so on.

In contrast, Industry <NUM> calls for an agile industry that the manufacturing process is modularized and therefore it can be easily adaptable to the changes by demand, easily configurable and customizable and just in time production.

In the present description, the term Software Defined Manufacturing (SDM) generally describes a reference architecture and methods for achieving the goals of Industry <NUM>. Example properties and benefits of Software Defined Manufacturing (SDM) may include:.

In some embodiments, the principles of virtualization described above with reference to <FIG> may be used to implement SDM. For example, process and device control and supervision functions may be implemented as applications <NUM> executing within virtual machines <NUM> or within containers <NUM>, using virtualized hardware resources <NUM>, which in the case of industrial processes may include industrial devices <NUM> and other resources of an industrial facility in addition to computing, data storage and communications resources.

To achieve a successful SDM implementation, an automated Closed-Loop Gain Control with high accuracy is important.

CLGC is useful in Industrial Device <NUM> automation especially in smart manufacturing as it is a key mechanism to control Industrial Device <NUM> operations in manufacturing processes especially in real-time. In some contexts, the term controller in fact refers to a CLGC controller as it is the most common and used type of control in manufacturing. An example of such type of CLGC controller can be Proportional Integral Derivative (PID) controllers commonly integrated with Programmable Logic Devices (PLCs) used in industrial facilities to control manufacturing processes.

CLGC is based on instantaneous or very low latency feedback signals from a process output with highly predictable timing accuracy. This allows delicate control of Industrial Device <NUM> operations to be performed such as motion operations of Industrial Device <NUM> arms. Isochronous real-time communications enable integration support for real-time closed-loop control with very low latency. These applications are critical for the efficiency and quality assurance of an automated manufacturing process involving Industrial Devices <NUM>, autonomous vehicles, and sensors.

CLGC contains a functional block called a controller. The controller operates to control a manufacturing (or other industrial) process through a variable gain process (VGP) by periodically reading a feedback signal derived from the output of the process and applying corrections when needed. The time between sensing the output to produce the feedback signal and applying the correction to the VGP adjusting the manufacturing process should be as small as possible. A large delay could invalidate the correction calculated from the feedback signal, resulting in, for example, damages to the production line and causing safety issues. The correction intervals also should be the same, avoiding large jitters, to keep the precision and stability of the CLGC algorithm executed in the controller.

Thus, CLGC control in manufacturing processing is an isochronous task requiring real-time execution and tight time-slotted communication between the CLGC controller and meters that measure the signal for the feedback. Typically, a CLGC cycle time could consist of either:.

In the description of these algorithms presented herein, the following definitions are adopted:.

The most common CLGC algorithms used in this disclosure are the On/Off Controller; the Proportional Controller; and the Integral Controller. See, for example: <NUM>) <NPL>; and <NUM>) <NPL>. Each of these controllers is described below.

In the On/Off controller, mv(t) is defined by: <MAT>.

The realization of this controller can use an asynchronous communication based on the notifications sent from the meter to the controller. The notification ON is sent when PV(t) > SP(t) and the notification OFF is sent when PV(t) ≤ SP(t).

In a Proportional controller, mv(t) is defined by: <MAT>.

In the Integral Controller, mv(t) is defined by: <MAT>
where mv(t<NUM>) is defined as either the controller output before integration, the initial condition at time zero, or the condition when the controller is switched into automatic.

In addition, various combination of these controllers may include:.

A Proportional Plus Integral (PI) Controller, in which mv(t) is defined by: <MAT>.

A Proportional Plus Derivative Controller, in which mv(t) is defined by: <MAT>.

A Proportional Integral Derivative (PID) , in which mv(t) is defined by: <MAT>.

<FIG> shows an example embodiment in which a CLGC Controller <NUM> is implemented in a server <NUM> of a <NUM>/<NUM> core network <NUM>. The CLGC controller <NUM> may trigger a periodic message to the industrial device <NUM> to obtain measurement values from a set of meters or assign gain values for VGPs on the industrial device <NUM>. The CLGC controller <NUM> may be expected to receive a response message with feedback data. Since the message exchange is isochronous, the data stream is also isochronous with high predictability.

In alternative embodiments, the controller <NUM> may be co-located with the Access Node <NUM> rather than a server <NUM>.

<FIG> illustrates an example packet flow of the CLGC controller implemented using the TCP/IP stack on a <NUM>/<NUM> network. The dashed lines indicate the flow through the several nodes in the network. The flow originates in the CLGC Controller UE and goes all the way up to the Industrial Device <NUM>. To get to Industrial Device <NUM>, the TCP/IP packet from the controller UE is sent down through its TCP/IP and <NUM>/<NUM> stacks. In the <NUM>/<NUM> PHY the TCP/IP packet is sent via Ethernet to the service gateway (SGW, not shown in <FIG>). The SGW forwards the IP packet (via Ethernet) to the Access node <NUM>. Within the SGW the TCP/IP packet goes all the way down through the TCP/IP and <NUM>/<NUM> stacks and it is sent to the Industrial Device <NUM> through the air interface. The Industrial Device <NUM> receives the packet from its air interface and sends it to the VGP, meter or sensor destination.

The following description is divided into four subsections: A description of Reference Model, A flowchart, A detail explanation of Manufacturing Process Instance and Use case examples.

As described above, the term Software Defined Manufacturing (SDM) has been introduced herein to refer to a reference architecture and methods for realizing the objectives of Industry <NUM>. <FIG> illustrates an example Software Defined Manufacturing Reference Architecture <NUM> in accordance with embodiments of the present invention. Use cases are disclosed below to show how this proposed model can address real industry problems. For ease of understanding, the following description is focused on examples based on a manufacturing context. As such the terminology used relates specifically to manufacturing. However, it will be appreciated that the same techniques can be equally applied to industrial facilities and processes other than manufacturing.

As shown in <FIG>, the reference architecture <NUM> includes a management and planning layer <NUM>, a supervision and control layer <NUM> and a field layer <NUM> composed of physical resources of the industrial facility such as industrial devices <NUM>, loading docks, storage areas and working areas. The planning, supervision and control layers <NUM> and <NUM> may be implemented as one or more computer systems as described above with reference to <FIG>, and may form part or all of the core network <NUM> described above. In the illustrated example, the planning layer <NUM> includes an Internet of Things (loT) cloud <NUM>, a planner <NUM> and a database <NUM>, while the supervision and control layer <NUM> includes a scheduler <NUM>, a supervisor <NUM>, a controller <NUM>, a mutual exclusion (MUTEX) server <NUM>, a PTP server <NUM> and a Position server <NUM>.

In some embodiments, the field layer <NUM> may comprise physical resources and a virtualization layer that operates to present virtualized resources to upper layers, in a manner directly analogous to that described above with reference to <FIG>. For example, the functions and services of the management and planning layer <NUM> and supervision and control layer <NUM> may be implemented as applications <NUM> executing in virtual machines <NUM> or containers <NUM> hosted by an application platform <NUM>, and using virtualized resources of the industrial facility presented to the application platform <NUM> by the virtualization layer <NUM>.

This reference architecture <NUM> is an abstract layered structure, that defines three abstraction layers:.

The example reference model of <FIG> has white boxes which indicate functions having counterparts in conventional systems (e.g. in ROS industrial and/or IEC standards). However, the present description invention describes enhancements to their conventional functionality, and complements legacy functional blocks with new functional blocks and new interactions to fulfill requirements of Industry <NUM>, ROS Industrial and IEC simultaneously.

<FIG> illustrates an industrial facility <NUM> such as a manufacturing floor in which a radio access network <NUM> comprising a set of four adjacent cells <NUM> is deployed. As noted above, each cell <NUM> may be defined by any suitable combination of geography, frequency, Radio Access Technology (RAT), modulation scheme and access node identifiers. If desired, conventional hand-over techniques (based on signal strength or radio signal coverage, for example) may be used for handling mobile devices (such as autonomous vehicles and AGVs) that move from one cell <NUM> to another. Alternatively, fixed "geographical" boundaries between adjacent cells <NUM> may be defined within the industrial facility <NUM>, and hand-over of a mobile device from one cell to another triggered by the location (and/or speed and direction) of the mobile device within the industrial facility <NUM>.

<FIG> also illustrates a set of Manufacturing Process Instances (MPIs) <NUM> within the industrial facility <NUM>. As will be described in greater detail below, an MPI is a logical construct which identifies industrial operations necessary to perform a predetermined industrial process, and one or more industrial devices or Manufacturing Processes (MPs) that are configured to perform those industrial operations. In some embodiments, all of the industrial devices allocated to a given MPI <NUM> are located within a common cell <NUM>. For example, <FIG> illustrates an embodiment in which MPI 408A encompasses all of the industrial devices <NUM> within cell 408A, and another embodiment in which the industrial devices <NUM> within cell 408B are allocated to two different MPIs 802B and 802C. These arrangements are beneficial in that in each case, all of the industrial devices <NUM> of a given MPI 802A. 802C are connected to a single access node <NUM>, which helps satisfy the latency requirements of fine control functions (See <FIG>).

<FIG> also illustrates an alternative embodiment, in which MPI 802D encompasses industrial devices <NUM> located in two difference cells 408C and 408D. In such embodiments, the required inter-cell packet flows may make it more difficult to meet low latency demands of fine control functions. However, where higher latency can be either tolerated, or inter-cell packet flows managed to minimize impacts on latency, an MPI <NUM> may span two or more cells <NUM>.

Referring back to <FIG>: The Planner <NUM> is responsible for taking manufacturing orders and breaking it down into fine steps. Each step in a manufacturing process (MP), and the MP as a whole, is a logical set that is specified by a collection of resources and one or more plans, such as, for example, a motion plan, a mobility plan, a task plan, a control plan, a supervision plan and a calibration plan. An MP is defined by a Planner and takes places in one or more MPls, that means, the MP is instantiated in one or more MPls to process an order.

The loT Cloud <NUM> is responsible for collecting alarms and equipment status so that the consolidated information can be displayed on-demand.

The database <NUM> may be subdivided as follows:.

The scheduler <NUM> is responsible for triggering the execution of manufacturing process definitions through one or more processing plans received from the planner <NUM> by:.

The PTP server <NUM> is responsible to provide a constant time reference across all nodes in the SDM reference model. It ensures all entities are time synchronized so that the tasks described in the collection of plans can be executed correctly. The PTP server can be substituted by any high accuracy time synchronization server.

The Position server <NUM> is responsible to monitor and track the location of industrial devices <NUM> (and especially mobile devices) within the industrial facility.

The manufacturing processing instance (MPI) may include a controller <NUM>, supervisor <NUM> and multiple industrial devices <NUM>, at least some of which may be mobile devices.

The supervisor <NUM> is the entity that handles or reacts to synchronous and asynchronous events originating inside the framework, for example as alarms from controllers of manufacturing processes or alarms resulting from monitoring determined properties of the manufacturing processes.

The Controller <NUM> controls the execution of the plans to each of the Industrial Devices <NUM> under its control.

<FIG> is a flowchart describing an example process in accordance with embodiments of the present invention. Some steps in the flowchart will be explained further in the following subsections
Step <NUM>: Scheduler creates a Manufacturing Process Instance (MPI).

Reception of an order may trigger the Planner <NUM> to create an MP which can originate one or more MPI(s). This is illustrated in <FIG>. An MPI is created by the scheduler <NUM> in response to a request from the planner <NUM> which sends a Manufacturing Process specification to the scheduler to create one or more corresponding MPls. <FIG> illustrates an example sequence of messages to create an MPI. Before creating the MPI, the scheduler <NUM> may verify that there are sufficient physical resources in the SDM resource pool to meet the requirements specified in the MP. If enough resources are available, the MPI is created and resources are allocated to it.

Step <NUM>: Scheduler allocates resources. Allocation of resources involves allocating Industrial Devices and allocating communication channels.

Step <NUM>: Scheduler <NUM> handles Mobile Industrial Device <NUM> Handover to a new MPI. Mobile Industrial Device <NUM> handover is done when the Industrial Device <NUM> moves between different MPls. As shown in <FIG>, the Handover Engine, operating as part of the Scheduler, receives a Handover Event. The MPI allocation and destruction of the entity representation of the Industrial Device <NUM> that is to be handed over happens over the <NUM>/<NUM> channel and the relevant Processing Cell Database is updated to reflect the changes. <FIG> illustrates an example message sequence of an industrial device handover process. An event is generated and sent to the Scheduler which handles the event. The Scheduler deletes the device from the Controller and Supervisor of the corresponding <NUM>st MPI to which the device is allocated. Then the Scheduler adds the device to the Controller and the Supervisor of the <NUM>nd (target) MPI that is to receive the device.

As <FIG> illustrates, the handover takes place by deleting the Industrial Device <NUM> from the first MPI and adding it to the second MPI. Deleting and adding Industrial Device <NUM> to a new MPI as illustrated by <FIG> implies no-disruption of the industrial process implemented by the <NUM>st MPI. Otherwise the handover might not be successful, or one or more additional actions may be taken such as a shutdown of the 1st MPI by the Supervisor.

Step <NUM>: Scheduler updates MPI states. <FIG> shows example states of a manufacturing process instance (MPI). If an MPI is uncalibrated, a manufacturing process may not be executed to process an order. In some embodiments, the MPI must be calibrated before running a manufacturing process.

To achieve the flow chart illustrated in <FIG>, it is important to illustrate the type of information being exchanged. <FIG> shows example SDM functional blocks and interfaces between these functional blocks. As shown in <FIG>, an MPI has the following main blocks:.

Shared functional blocks are blocks whose instances are shared or communicates with different MPls. These are:.

An SDM framework may contain two types of communication interfaces as follows:.

<FIG> also shows example interfaces of the SDM framework which may include:.

The following paragraphs with describe Manufacturing Process Instances in greater detail.

The SDM executes a manufacturing process (MP) in an MPI. An MPI couples a processing cell (PC) to an MP. A unique MP can run in multiple MPls. Each MPI is associated with different PCs and producing a copy of the specified output for the order in the MP specification.

<FIG> shows an auto assembly line as an example realization of an MPI. An MPI can have several Industrial Devices <NUM> collaborating to satisfy an order.

Each MPI is made up of functional blocks including Controller, Supervisor and industrial devices, with instruction from the Planner and Scheduler.

The Planner is responsible for taking manufacturing orders and generate manufacturing processes which are specified with plans. The planning of a manufacturing process may involve any one or more of the following types of planning:.

In order to achieve goals of a manufacturing step like drilling holes in a part, moving a part from the conveyor belt to an autonomous vehicle, Industrial Devices <NUM> such as Industrial Device <NUM> arms need to be able to carry out high-level task planning in conjunction with low-level motion planning. Task planning is needed to determine long-term strategies such as whether to stop the conveyor belt to grab the part to put in the autonomous vehicle. The motion planning is required for computing the actual movements that the Industrial Device <NUM> should carry out.

The Industrial Device <NUM> field has traditionally treated task planning and motion planning in isolation. However, this separation can be problematic. Instead, Task-Motion Planning (TMP) is being proposed for use to tightly couple task planning and motion planning, to thereby produce a sequence of steps that can actually be executed by a real Industrial Device <NUM> to bring it from an initial to a final state.

Embodiments of SDM may support either on or both approaches:.

A mobility plan describes how a mobile Industrial Device <NUM> travels inside an MPI and/or outside to cross to another MPI. The path followed by a mobile Industrial Device <NUM> can include the Industrial Device <NUM> being added and removed to different processing cells such as MC or MPI during its running. Therefore, a mobility plan may include either one or both of:.

A control plan contains the configuration of each fine control and the coarse control plan of the streamline.

A supervision plan contains specifications for at least one of:.

A Calibration Plan involves performing the initial calibration of the various sensors in the Industrial Devices <NUM> in the manufacturing plant in order to aid in obtaining accurate sensor and meter values for the coarse and fine controllers.

The Scheduler <NUM> may be responsible for one or more of:.

The Controller <NUM> controls the execution of the plans which might include motion, calibration, and control plans.

Example functional subblocks of the Controller are illustrated in <FIG>, and are described below:.

As described above, the Supervisor <NUM> handles or reacts to synchronous and asynchronous events originated inside the framework as alarms from controllers of manufacturing processes or alarms resulting from monitoring determined properties of the manufacturing processes.

Every supervision plan sent to the supervisor <NUM> by the planner <NUM> triggers a new action that might include starting agents for monitoring QA parameters, adding event filters, adding event forwarders, creating scripts to execute actions to handle events.

The foregoing description discussed high-level architecture, functional blocks and interfaces for implementing SDM in accordance with embodiments of the present invention. The following description provides a context of how these can be used to solve Industry <NUM> challenges. The SDM may support the following use cases of changes in manufacturing cells and manufacturing processes which are not supported by current solutions.

Use Case of Industrial Device <NUM> Collaboration: The collaboration between Industrial Devices <NUM> as defined herein deals with several characteristics of Industrial Device <NUM> collaboration especially due to a combination of Industrial Devices <NUM> following motion plans and Industrial Devices <NUM> following path plans.

Streamline: A streamline models the flow of activities performed by Industrial Devices <NUM> to achieve a given goal such as:.

Tasks: A task is a set of computation procedures performed, periodically or not. Examples of tasks are Linux threads and Linux processes. Real-time tasks are guaranteed to be started before a due-time in a concurrent operating system. A streamline may contain any one or more of the following real-time tasks:.

MUTEXes: Sometimes Industrial Devices <NUM> need exclusive access to shared resources such as a manufactured part for Industrial Device <NUM> arms or access corridor in a floor for an autonomous vehicle. These types of accesses need to be coordinated so that the Industrial Devices <NUM> do not interfere with each other or generate collisions. This exclusive access can be implicitly programmed in the TMP or mobility plans. However, these plans are very hard to be done within the complex manufacturing process, some are probabilistically guaranteed to be found by an algorithm and some are prototyped using off-line programming [<NUM>].

For the cases that a plan is not found or to provide extra protection against collisions, SDM provides mutual exclusive objects, or MUTEXes. When using a resource protected by a MUTEX, the Industrial Devices <NUM> need to own the MUTEX before accessing that resource. This guarantees that only one Controller <NUM> or one Industrial Device <NUM> can access the resource at any given time, and so helps to prevent collisions. Industrial Devices <NUM> that want to access the resource while it is being accessed by another Industrial Device <NUM> will wait in a MUTEX queue. Once an Industrial Device <NUM> finishes its access, it frees the MUTEX and the next Industrial Device <NUM> in the MUTEX queue can have access.

Control tasks defined in SDM are typically real-time. Therefore, the isochronous real-time communication with low latency, low jitter and high reliability must be used to implement network MUTEXes. These requirements are typical of Time Sensitive Networks (TSN).

MUTEXes have a MUTEX ID and owner associated to them:.

Each manufacturing process instance (MPI) has an interface to MUTEX server <NUM> or a MUTEX area where MUTEXes can be created, maintained and destroyed. Streamline tasks can access a MUTEX in this area through the naming services.

Since tasks in a streamline can run in different network devices, MUTEXes may be created, accessed and destroyed through a network protocol. The network protocol may have the following synchronous messages:.

The MUTEX protocol should preferably use a real-time isochronous protocol with very low latency and reliability communications.

<FIG> illustrates an example in which two MUTEXes are used to protect access to a manufactured part in an MPI, and access to an autonomous vehicle. In this example, The TMP plan for streamline <NUM> defines two motion control tasks. The first motion control task controls the Industrial Device <NUM> arm <NUM> which does some manufacturing task on the part. The second motion control task controls the second Industrial Device <NUM> arm which grabs the part and put it inside the autonomous vehicle. Once the part is inside the autonomous vehicle, the autonomous vehicle will delivery to the destination which is done by the path control task defined in the path plan. <FIG> shows an example sequence of lock and unlock operations done by all three tasks to coordinate the whole manufacturing process from starting to manufacture the part to transporting it to the destination.

Control Type. Control plans can define a fine control or a coarse control (see the definition in the background section).

Control Plan Specification and Generation. Control plans may be written using any of the IEC <NUM>-<NUM> Programming Languages, if desired. The process of generating a control plan may be done through an automated process that takes orders and resources specifications from the Cell Processing database and generates the control plan using Structured Text, for example. The control plan may be made part of the Manufacturing Process which is defined by the planner.

Control Functional Blocks. The fine control and coarse control are the implementation of closed-loop controls. They are integrated in such a way that they work together with different time granularity of measurement and gain, to adjust one or more variables as described above. <FIG> illustrates the parallel configuration of the coarse/fine CLGC. In this configuration, the fine CLGC are independent of each other. The behavior of one loop does not affect the behavior of the other loops. <FIG> illustrates an example serial configuration of the coarse/fine CLGC. In a serial configuration, CLGC loops are cascaded. Thus, the behavior of any CLGC loop influences the behavior of the other CLGC loop.

In both configurations, the functional blocks are:.

Functional blocks exchange the following signals:.

For the Closed-loop Gain Control shown in <FIG>, the following relations are valid: <MAT> <MAT> where j is the number of sensors connected to Ci and <NUM> ≤ i ≤ n. <MAT> <MAT> where Zis the number of sensors connected to G.

Fine control happens in the fine controller ( Ci ). Each controller Ci is independent of the others and generates the control signal di given by di(t) = Ci(ei(t), pi(t), si,<NUM>(t),. ,si,m(t)) , where m is the number of sensors connected to Ci.

Ci is typically an Industrial Device specific function, but the Industrial Device controller can supply a fine controller based on any control function such as one of the previously defined types of controller. For example, a Proportional Plus Integral (PI) controller is defined by making the following mapping: <MAT> <MAT> where:
ϕi is a function that compensates for environmental parameters sensed by the sensors.

For example, a VGP Ai can control the rear wheel speed of an autonomous car to keep it constant. The corresponding meter Mi can sense the speed has deviated and the car will have to accelerate. The corresponding ei can give an initial correction di in terms of acceleration increase. However, the floor can be slippery which is sensed by a traction sensor installed in the wheels. A corresponding function ϕi can negatively feedback Ci to avoid the full speed increase giving by di. Other examples of θi can model control for temperature, frequency, and humidity.

Fine Controller Implemented in the Industrial Device <NUM>. When the fine controller is implemented in an Industrial Device <NUM> controlled by the Industrial Device Controller through CFCP protocol, closed-loop gain control capability request messages are sent by the Industrial Device Controller to the fine controller which replies with the confirmation of the capability, that is, the capability is allocated by the fine controller in the Industrial Device <NUM> controlled by the Industrial Device Controller.

Fine Controller Implemented in the Industrial Device Controller. The fine controller can be implemented in the Industrial Device Controller to control a VGP implemented at the Industrial Device <NUM> having feedback signal from meters close to the Industrial Device <NUM> and environmental sensors. The fine controller at Industrial Device Controller can discover the capabilities of VGP, meter, and sensor characteristics through the CFCP capability negotiation messages for VPG, meters and sensors respectively.

Coarse Control. Coarse control happens in the coarse controller ( G ). The general control function G combines all the errors ei and data from m sensors si to generate a control vector [p<NUM>,p<NUM>,. Each element in this vector is a control value pi which is applied together with di to the fine controller Ci. Therefore, G is a composition of closed control gain loop controllers, each controller generating a signal pi. Such an individual controller 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: <MAT> <MAT>
where:
εi = Hi - ei: this is the difference between the coarse error threshold Hi and the error ei. ϕi is a function that compensates for environmental parameters sensed by the sensors in the global controller block.

Coarse and Fine Control Protocol (CFCP). The Coarse and Fine Control Protocol (CFCP) may be a peer-to-peer client/server protocol. It may be provided as an application layer transport protocol designed specifically to transport packet data from/to devices controlled by the CLGC controller to/from the CLGC controller:.

Requirements of the CFCP may include any one or more of the following:.

For Real-time Transmission, CFCP packets should preferably use an average of two <NUM> resource blocks.

CFCP packets for non-real-time transmission: These packets are used for capability negotiation and association negotiation. There is no restriction to the size of the CFCP packet.

CFCP packet for synchronous real-time transmission: These packets are used for synchronous real-time transmissions. These packets should preferably fit in two LTE resource blocks on average.

CFCP packet for isochronous real-time transmission: These packets are used for isochronous real-time transmissions. These packets should preferably fit in two LTE resource blocks on average.

Example <NUM>: <FIG> illustrates a line of autonomous vehicles <NUM> used to transport manufactured parts from a manufacturing process. The autonomous vehicles <NUM> follow one after another. They are separated by a variable distance (d), although the differences in the distances between autonomous vehicles are kept as minimal as possible.

Each autonomous vehicle <NUM> has two electrical motors. <FIG> illustrates the control of these motors of an autonomous vehicle <NUM> modelled as a streamline. The two motors are controlled by fine CLGC controllers (C<NUM> and C<NUM>) that commands the rotation of each motor. The feedback signals for these two controllers come from the tachometers or encoders (M<NUM> and M<NUM>). The distance between the autonomous vehicles is controlled by a coarse CLGC controller (G). The feedback signal for G comes from one of the proximity sensors (S) in each autonomous vehicle.

Assuming i indicates the motor (i=<NUM> for the first motor and i=<NUM> for the second motor), the labels in <FIG> have the following definitions:.

A supervisor (H) receives events (speed alarms) from the coarse controllers in case it is not able to correct the errors.

The controller C1 is a PID controller defined by: <MAT>.

The two front wheels can turn by means of their wheel servos. They are controlled by the path controller that follows a path plan. <FIG> shows this path control modelled as a streamline. The two fine controllers (C<NUM> and C<NUM>) control the angles of the wheels and the coarse control (G) controls the angle of the autonomous vehicle. These controllers receive the feedback signal from the meters (M, and M<NUM>) that measures that angle with a fixed reference such as the middle border of the lane (yellow line of the road) or the curb line of the road.

Assuming i indicates the wheel (i=<NUM> for the first wheel and i=<NUM> for the second wheel), the labels in <FIG> have the following definitions:.

This example illustrates a case where the streamlines are cascaded in a 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.

<FIG> illustrates an example of an assembly line. The assembly line contains four Industrial Device <NUM> arms. The Industrial Device <NUM> arms are placed along a line performing some manufacturing task in a part passing through the Industrial Devices <NUM>. Each Industrial Device <NUM> has a determined time to due time the task. After the due time, the next Industrial Device <NUM> can start its task on the manufactured part being produced. To maintain the most efficient time alignment between the Industrial Devices <NUM>, the streamline illustrated in <FIG> models the control for the servos in each Industrial Device <NUM> arm. The streamline contains four fine control loops in cascade, each controlling the speed of the servos and one coarse control loop with a coarse control of these speeds after some speed threshold.

Assuming i indicates the servo (i=<NUM> for the first wheel and i=<NUM> for the second wheel), the labels in <FIG> have the following definitions:.

Supervision is the control with the largest response time. Supervision control permits a longer time interval than CLGC, taking actions to correct problems detected during the fine and coarse CLGC and cannot be corrected by varying the gain from VGPs.

Self-healing: The supervision is characterized by the self-healing property which is the supervision property to correct some defect or problem in the MPI following an abnormal manufacturing condition. The Supervision functional block monitors the control functions of the fine and coarse CLGC. Additionally, the supervision can monitor properties of environmental sensors in the MPI and it might raise alarms to loT Cloud <NUM> or performing self-healing operations if pre-determined conditions are not met.

Control stability: It tells how often the output deviates from the target value.

Control convergence: it is the time in average for the PV to converge to PS (or very close to it).

On the event of some of these properties deviates from acceptable intervals, the supervisor triggers a self-healing action which will apply some predefined correction external to the control functional block such as:.

The manufacturing process may specify quality assurance control parameters which triggers the instantiation of supervision monitors for these parameters. Depending on the supervision plan these monitors can trigger events if the parameters are not met.

Quality Assurance by timely calibration. Before executing a manufacturing process, the MPI verifies the state of the processing cell to determine whether or not any calibration is required. If the PC needs calibration, the MPI moves to uncalibrated state and may start a calibration procedure for the processing cell during a maintenance window. It is costly to discover any defective product being manufactured and it is extremely costly to pause any ongoing manufacturing process because any unplanned interruption has monetary impact. In other words, the product value that can be manufactured during the stoppage is not able to realize.

A calibration plan may contain any one or more of:.

Production scaling: It is the increase or decrease by the software interface of the production of orders in a manufacturing process. <FIG> illustrates an example of an order to increase the production capacity. This action on SDM can be triggered by the SDM Planner or by a human operator through the SDM software interface.

Industrial Device <NUM> replacement: It is the maintenance action of replacement a defected Industrial Device <NUM> as shown in <FIG>. This action can be triggered automatically through the SDM supervision or by a human operator through the software interface of the SDM.

Production Relocation: it is the physical relocation of a manufacturing process to a new area in a factory. This use case is illustrated in <FIG>. This action can be triggered automatically through the SDM supervision, by the SDM Planner or by a human operator through the software interface of the SDM.

<FIG> illustrates an example cloud-based deployment of Software Defined Manufacturing. The loT cloud represents an information network implemented using cloud technologies. The loT cloud implements several services such as manufacturing order dispatching, SDM health reporting, SDM management. The Planner is responsible for generating the manufacturing process definition, each streamline comprising a manufacturing process and its correlated plans (control plan, supervision plan, motion plan, transport plan) of the streamline. The planner also keeps the centralized database with physical resource definitions. The scheduler can be situated in the cloud and it dispatches instruction to the controller and supervisor.

The controller and supervisor can reside in the cloud as well if the real-time responses and closed-loop controls are not needed in the deployment. For this discussion, we assume they are edge computing and residing on the premise. The scheduler is responsible for instantiating the cells to produce the orders using the streamline definitions and the centralized resource database. The scheduler allocates Industrial Devices <NUM> and any other physical resources in a processing cell. It also operates the processing (start, pause, stop).

Claim 1:
A system comprising
at least one access node (<NUM>) configured to wirelessly transmit and receive signals to and from industrial devices (<NUM>) within at least two cells (<NUM>) of a cellular communications network (<NUM>) deployed within a manufacturing facility, wherein the cellular communications network conforms to <NUM> NR standards and has ultra-reliable low latency communications, URLLC, capabilities;
a computer system comprising:
an interface (<NUM>) connected to transmit and receive signals to and from the access node using URLLC; and
processing circuitry (<NUM>) configured to:
define a manufacturing process instance, MPI, identifying manufacturing operations necessary to perform a predetermined manufacturing process;
allocate one or more of the industrial devices to the MPI, each allocated industrial device configured to perform at least one of the identified manufacturing operations; and
implement a controller (<NUM>) configured to control each of the industrial devices allocated to the MPI by, in each cycle of an iterative process:
transmitting, using URLLC, a command signal to a selected one of the industrial devices allocated to the MPI; and
receiving, using URLLC, a reply signal from the selected one of the industrial devices.