Patent Publication Number: US-2021173385-A1

Title: Automation system with edge computing

Description:
RELATED APPLICATION 
     The present application is a continuation of U.S. patent application Ser. No. 16/707,918 filed Dec. 9, 2019, the contents of which are hereby incorporated by reference. 
    
    
     SUMMARY 
     Various embodiments provide edge computing in an automation system with an automated device connected to a local computing circuitry and a network computing device on a single site. The local computing circuitry is configured to generate a unique automation network address from unique factory information collected from the automated device independent of the network computing device. 
     An automation system, in other embodiments, can operate by connecting local computing circuitry to an automated device and a network computing device with each of the local computing circuitry, automated device, and network computing device positioned on a single site. At least one piece of unique factory information from the first automated device is collected with the local computing circuitry in order to generate a unique automation system network address with the local computing circuitry independent of the network computing device. The unique automation system network address is employed to conduct at least one automation task with the automated device. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  is a block representation of an example automation system in which assorted embodiments can be practiced. 
         FIG. 2  depicts an example timeline of actions that can be carried out by the automation system of  FIG. 1 . 
         FIG. 3  depicts a block representation of portions of an example automation system configured in accordance with various embodiments. 
         FIG. 4  depicts an example timeline of actions that can be carried out by the automation system of  FIG. 3 . 
         FIG. 5  depicts an example unique address within a given namespace that may be generated by local device computing circuitry in some embodiments. 
         FIG. 6  depicts a block representation of portions of an example automation system configured and operated in accordance with assorted embodiments. 
         FIG. 7  is a flowchart of an example edge computing routine that can be executed by the various embodiments of  FIGS. 1-6 . 
         FIG. 8  depicts portions of an example edge computing automation system arranged in accordance with some embodiments. 
         FIG. 9  depicts portions of an example edge computing automation system utilized in accordance with assorted embodiments. 
     
    
    
     DETAILED DESCRIPTION 
     Assorted embodiments of the present disclosure are generally directed to an automation system employing multiple automated devices with local circuitry that generates unique addresses to allow direct device-to-device two-way communication, which optimizes the efficiency and modularity of the automation system. 
     As computing hardware and software have become more sophisticated, automation systems have evolved into complex mixtures of software languages and communication protocols. Such complexity often corresponds with time-consuming and precise system administration, particularly upon device installation, upgrade, or reassignment. The trend of utilizing greater numbers and types of automated devices in a system increases the likelihood of device replacement, service, and/or reassignment, which requires further system administration at the cost of man power and system down-time. Hence, there is an opportunity to optimize automation systems employing multiple automated devices. 
     Accordingly, various embodiments are directed to providing computing circuitry to an automation system to allow for at least the generation and utilization of two-way unique device addresses at the device level instead of a network server/controller/node level. The ability to deploy hardware and software locally at the device level allows for device-to-device communication, data transmission, and operational optimizations without requiring network controller computation, implementation, or transfer of system signals. The implementation of hardware circuitry as an attachment to an automation device allows for simple, efficient, and straightforward deployment of system upgrades without having extensive system downtime, reprogramming, or added complexity. 
       FIG. 1  depicts a block representation of portions of an example automation system  100  in which assorted embodiments may be practiced. The system  100  can consist of any number of separate automated devices  102  positioned within a single site  104 , or distributed across a number of separate sites and interconnected via one or more wired, or wireless, networks  106 . An automated device  102  can be any type, size, function, and construction that can perform autonomously. For instance, a first automated device  102  may be a sensor while a second automated device  102  is a robotic assembly and a third automated device is a solenoid. 
     It is contemplated that the respective automated devices  102  can operate independently and/or concurrently, as programmed, to carry out one or more tasks, such as the assembly of a machine, transformation of a material, collection of hydrocarbons, or processing of a substance. While programmed operation can be carried out cyclically by the respective automated devices  102 , data analysis, system optimization, and inter-device communications can be executed exclusively by downstream computing devices  108 , such as a controller, microprocessor, or other programmable circuitry. 
     The use of one or more centralized computing devices  108  to carry direct operation of the automation system  100  and the respective devices  102  allows the devices  102  to be cheaper and simpler than incorporating computing hardware into every device  102 . As such, various embodiments arrange the respective automated devices as “dummy” devices that can execute programmed instructions, but cannot transform signals, software, or data in a manner that allows inter-device communication, data analysis, device repurposing, or device instruction alterations, which is reserved for downstream computing devices  108 . 
     As a result of utilizing dummy devices  102 , the complexity of a system  100  can be somewhat mitigated by consolidating computing activity in a central device  108  and/or a remote host  110 . However, such consolidation of computing activity can limit the efficiency and accuracy of the system  100 , particularly when fast device  102  operations are needed or when the number of devices  102  on a single site  104 , or connected remotely via the network  106 , cause channel and/or processing latency in the central device  108 . Thus, there is a continued need for a balance of computing activity in an automation system  100  that allows for optimized performance and reduced reliance on centralized computing devices  108  without degrading system operation via increased complexity. 
       FIG. 2  depicts an example timeline  120  of events associated with utilizing automated devices  102  in the automation system  100  of  FIG. 1  in accordance with some embodiments. The timeline  120  is contemplated with an established automation system that has at least one operational automated device capable of performing one or more tasks, such as material movement, assembly, processing, or packaging, without user involvement, such as manual manipulation, activation, or data input to the automated device. However, the events of the timeline may also be applicable for newly established automation systems where no automated devices have yet become operational. 
     With event  122 , an automated device change is introduced to the automation system. Such a change is not limited, but may be the introduction of a new device, repurposing of an existing device, or alteration to the programmed automated activity of an existing device. For instance, a new automation device can be physically installed into a position on a site and connected to a local computing device  108  via one or more network connections. Due to the automated device not having local computing capabilities and instead having circuitry capable of storing programmed code, executing automation instructions, and returning data to a downstream network computing device, a user brings the automation system offline in event  124  while programming automation instructions for the device in event  126 . 
     The programming of automation instructions by a user in event  126  may involve one or more software actions that enable the device to activate, function, return data, and deactivate as desired by the user to complete at least one task. As a non-limiting example, device software actions in event  126  can generate and store static programming code in the device&#39;s native execution language. Another example of a software action can be translating the device&#39;s native output into a communication protocol, such as Open Platform Communications Unified Architecture (OPC-UA), and/or setting operational parameters in the native software stored in the device during manufacturing. Hence, the software action(s) of event  126  convert a non-operational device into an operational device that will at least activate to perform a task and, perhaps, return data to a downstream network device pertaining to operation of the device. 
     The programming of all newly added, or modified, automated devices in event  126  allows the automation system to be brought online in event  128  and subsequent device operation completes at least one task in event  130  in accordance with the programmed instructions. As a result, the programmed devices of the system can operate cyclically executing the instructions programmed during event  126 . While the device programming may be useful over time to complete tasks, it is contemplated that system conditions change over time and cause the programming of at least one device to be sub-optimal. For example, device operation may degrade over time complete a designated task, but with more time to completion, less precision, more danger, or greater amount of waste. Accordingly, embodiments are directed to providing computing capabilities locally in an automated device to allow communication between devices without network device involvement, which allows device modification and optimization over time without bringing the entire automation system offline. 
     The block representation in  FIG. 3  depicts portions of an example automation system  140  configured in accordance with various embodiments to provide edge computing and optimal automated task operation over time. While not required or limiting, the automation system  140  can have multiple separate automation devices  142  that are each connected to a local computing device  108  positioned on-site  104 . It is contemplated that the local computing device  108  can be connected to one or more off-site, remote hosts  110  that can provide data storage, processing, and maintenance to supplement the computing capabilities of the local device  108 . 
     Although the local computing device  108  may have robust capabilities to facilitate communication between devices  142  and execute predetermined device programming to perform one or more autonomous and automated tasks, the performance of the device  108  may be stressed and/or degraded in response to managing large numbers of devices  142 , different tasks being performed, and modifications to device  142  operation over time. Hence, each automated device  142  is equipped with a local computing circuitry  144  that enables device-to-device two-way communication, as illustrated by arrows  146 , and modification of device  142  programming without involving the computing device  108 . 
     The ability to generate unique device  142  addresses with the device-level computing circuitry  144  allows the devices  142  to transfer operational data and other information that can be used to alter existing thresholds, programming, and/or operation to adapt to changing environmental and device  142  conditions. For instance, the two-way communication between automated devices  142  can recognize a change to a task, such as greater waste, increased temperature, or slower delivery, which triggers the computing circuitry  144  to alter the programming of at least one automated device  142  to accommodate the task change and provide optimal automated activity individually and collectively amongst the devices  142 . 
     The generation of a unique address with the device-level computing circuitry  144  further allows for two-way communication between the computing device  108  and each automated device  142 . The local computing circuitry  144  may be hardware, such as a printed circuit board, employing programmable circuitry that can monitor device  142  operation and generate communication addresses and pathways between devices  142  independent of the computing device  108  or connected remote host  110 . It is contemplated that the computing circuitry  144  physically attached to a single automated device  142  can evaluate other connected devices  142  of the system  140  in order to generate unique network addresses without involving the downstream computing device  108 , which allows for two-way communications between automated devices  142  without signals and data flowing through the computing device  108 . 
       FIG. 4  depicts an example timeline  160  of the utilization of the example automation system  140  of  FIG. 3 . An automation system can be initially setup to allow event  162  to conduct at least one automated task, such as material movement, processing, evaluation, or transition. The automation system during event  162  is contemplated as having a plurality of automated devices that can be different types of devices that perform different automated actions. For instance, a first device may be a sensor that collects data while a second device is a solenoid that activates in response to a detected condition and a third device is a robotic assembly that articulates to physically alter the condition of a material. 
     Some embodiments of the automation system have one or more connected network computing devices that direct overall automation activity by communicating with the respective automated devices and any connected remote hosts. While not required or limiting, one or more automated devices of the automation system can have local computing circuitry that provides hardware and software capabilities that supplement the capabilities of the automated device. The local computing circuitry can be incorporated into the automated device from the device manufacturer, such as within the device&#39;s housing, or externally attached to the device, such as in-line external to the device&#39;s housing. 
     The presence of the local computing circuitry with at least one automated device allows event  164  to collect and store data associated with the automated task(s) of event  162 . As a non-limiting example, local computing circuitry, such as a data source gateway historian, can evaluate and/or process data collected by the automated device in order to determine device performance metrics, such as latency, accuracy, time-to-completion, and if the automated task has properly occurred. It is contemplated that the local computing circuitry can conduct assorted data collection and processing activities without direction or involvement of a connected network computing device. The independent automation capabilities provided by the local computing circuitry may extend to communicating signals, information, commands, and data between automated devices without involvement of any network computing devices, which may correspond with the network computing device becoming a passthrough and/or switching mechanism without processing the constituent data, generating metadata, or generating destination addresses for the signals, information, commands, and data. 
     At some time after event  164 , at least one automated device is newly installed into the automation system in event  166 , which triggers the local computing circuitry of that new device to generate and assign a unique network address for the device in event  168 . It is contemplated that the connection of a new automated device into the system triggers the local computing device of a different device of the network to generate and assign an address to the new device. The ability to utilize the local computing circuitry of other automated devices allows for the seamless integration of an automated device without local computing circuitry. 
       FIG. 5  depicts an example unique network address  180  that may be generated by local device computing circuitry in accordance with some embodiments. The unique network address  180  can have a hierarchical structure corresponding with the logical, and possibly physical, configuration of the device within an automation system along with the unique device ID and INFO data stored in the device from the factory. 
     The non-limiting address  180  has a first level identifier  182 , second level identifier  184 , third level identifier  186 , fourth level identifier  188 , and a fifth level identifier  190  that respectively distinguish the device from other actual, or potential, addresses of an automation system. The first level identifier  182  may correspond to a site location of the automated device while the second level identifier  184  corresponds with the network computing device that directs operation of the automated device within the assigned site. The third level identifier  186  may correspond with an object in which the automated device is interacting, such as a tank, pipe, mechanism, or tool. A particular device may be identified by the fourth level identifier  188  of the address and a device tag may be the fifth level identifier  190 . 
     In some embodiments, an address module can input various address information from different sources. For instance, site, controller, and object information can be designated automatically from a host or server while device and tag information is designated from ID and INFO data sourced from the particular device. The host, or server, may be polled by the local computing circuitry during device deployment to verify the accuracy of the automatically generated network address identifiers for an automated device. That is, the address module may automatically generate address information for a device that is incorrect until a host, or server, provides correct address information during device deployment, which will alter the automatically generated address. 
     By automatically generating a network address and conducting minor address adjustments, as necessary, automated devices can efficiently be incorporated into sophisticated, and perhaps complex, automated systems, without degrading system capabilities or real-time performance. Returning to the timeline  160  of  FIG. 4 , the generation of a unique network address for an automated device allows for device-to-device direct communications in event  168 . While such device-to-device communications can be used for a plethora of different purposes, various embodiments utilize the direct device communications to integrate the device into the automation system, establish the device&#39;s operation for a task, and/or optimize the function of the device with respect to other system automated devices. 
     The unique network address for an automated device may further be used for two-way communication with one or more network computing devices. Such two-way communications contrasts the conventionally one-way communication pathway from the network computing device instructing the respective automated devices when and how to operate. The two-way communication with the network computing device enables the automated device to provide feedback data, information, and signals to the network computing device, which can be utilized to understand the real-time operating conditions and performance of the automation system. 
     With all newly installed automated devices having unique network addresses that facilitates incorporation into the automation system, at least one automation task can be executed in event  168  with the newly installed automated devices from event  166 . It is noted that portions of the timeline  160  may be conducted repeatedly as equipment, conditions, and tasks change over time. In a non-limiting example, the direct device-to-device communications without involvement of the network computing device of event  168  can be conducted repeatedly between one or more pair of automated devices in the alteration of the devices&#39; respective automation instructions in response to a task being changed. 
     The automation and adaptation capabilities provided by one or more automated devices having local computing circuitry allows an automation system to be efficiently operated despite environmental, task, and device performance changes over time. The incorporation of local computing circuitry into an automated device ensures the compatibility of the device with an automation system due to the circuitry&#39;s ability to generate and utilize a network address to communicate to other devices in their native code, language, and protocol, regardless of the type of automation system, task, or network computing device being utilized. 
     However, some automated device may not be manufactured with local computing circuitry and instead are “dummy” devices capable of only performing instructions inputted from a remote source, such as a network computing device.  FIG. 6  depicts a block representation of portions of an example automation system  200  that employs physically isolated local computing circuitry  202  to optimize the execution of automation tasks. A physically isolated local computing circuitry can have one or more computing components positioned in a housing with means for connecting to an automated device. It is contemplated, but not required, that various computing components are mounted to a printed circuit board along with a physical port connector, such as a serial bus. 
     As shown, multiple separate local computing circuitry  202  are respectively connected to automated devices  102  that are configured to provide different automated capabilities and activity. For instance, a sensor  204  can detect one or more dynamic or static conditions while a valve  206  is positioned to influence the movement of material and a robotic assembly  208  articulates material to perform at least parts of a task. It is contemplated that a local computing circuitry  202  is physically connected in-line between the automated device  102  and the network computing device  108  via a wired connection, such as Ethernet, universal serial bus (USB), serial AT attachment (SATA). Other embodiments employ a wireless data pathway, such as with Bluetooth or secure local area network connections, between the local computing circuitry and the automated device and/or network computing device. 
     The connectivity and installation capabilities of a local computing circuitry  202  external to an automated device  102  allows for retrofit applications for automated devices that do not have local computing circuitry. It is contemplated that an external local computing circuitry  202  can be connected to an automated device that has internal local computing circuitry to provide redundant and/or supplemental device operation, programming, and communication capabilities. Through the use of an external circuitry  202 , internal device computing circuitry, or a combination of the two, multiple concurrent, or sequential, data pathways can be established and maintained. Such data pathways can be employed to communicate redundant or different data to one or more destinations with different languages, code, and protocols, which allows automated devices to efficiently communicate in their native code, language, and protocol. 
     In some embodiments, an externally connected local computing circuitry  202  provides additional automation capabilities, such as optical, acoustic, or mechanical detectors, which can be utilized independently and collectively with the capabilities of the automated device  102 . It is contemplated that the external local computing circuitry  202  may provide automation capabilities, such as material handling, processing, or translation, that are redundant or different than the connected automated device  102 . The ability to provide redundant and/or additional sensing and automation capabilities allows for automation system upgrades simply by physically connecting the circuitry  202  in-line with the automation device  102 . 
       FIG. 7  is a flowchart of an edge computing automation routine  220  that can be carried out by the assorted embodiments of  FIGS. 1-6 . The routine  220  may begin with multiple automated devices being positioned on a site in step  222  and connected with a network computing device, such as a server, controller, or node. It is noted that step  222  may be skipped in the event a new automation site is being setup with routine  220 . The various automated devices can be programmed from the factory with software, code, and protocols that facilitate at least one automated activity. Such programming may be augmented, replaced, or supplemented by commands and/or code provided by the connected network computing device as part of the automation system. For example, a sensor can be manufactured to optically detect at a first resolution and the connected network computing device alters the detection to a second resolution. 
     The automation activities executed by the assorted automated devices, as directed by the connected network computing device, can perform any number of tasks cyclically for any period of time before step  224  introduces at least one new automation device to the system. The automated device may or may not have internal computing circuitry. Hence, decision  226  evaluates if an external computing circuitry (dongle) is to be connected to the automated device. It is noted that an external computing circuitry may be chosen in decision  226  to complement internal computing circuitry of an automated device. 
     If an external computing circuitry is to be used, step  228  physically connects the external computing circuitry into the automation system. Such physical connection may be with data and or power cabling engaging one or more ports of the automation device and/or the on-site network computing device. Alternatively, the physical connection may involve placing the circuitry on-site and wirelessly connecting the circuitry to the automated device and/or the on-site network computing device. 
     The connection of the local computing circuitry in step  228 , or in the event no external circuitry is utilized in decision  226 , prompts step  230  to generate a unique network address for the new device with the local computing circuitry. The local computing circuitry may poll one or more unique factory parameters of the automated device, such as serial number, operating latency, or manufacture date, to generate the unique network address for the automated device. The polling of the device, in some embodiments, involves the local computing circuitry conducting one or more test operations or commands that convey unique hardware, software, and/or operational characteristics manufactured into the automated device, which corresponds to a truly unique address. 
     Once the unique network address is generated by the local computing circuitry, direct automated device to automated device and two-way network computing device communication can occur via one or more pathways. That is, the unique network address of an automated device can be employed to establish one or more data and/or signal pathways, which may be concurrent or sequentially employed to communicate between automated devices while bypassing the network computing device or back and forth between with the network computing device. The communication pathways are then employed in step  232  to collect information directly from other automated devices, which keeps the network computing device free to efficiently conduct high-level system operations, such as remote host access security or data transfers. 
     The collection of information in step  232  may involve the polling of any type and volume of data from other automated devices of the automation system. For instance, information pertaining to the automation activities, tasks, timing, programming, and collected data can be collected in step  232 . With the direct automated device communication pathways, the native programming and communication protocol of the automated devices can be used regardless of the type, manufacturer, age, or function of the automated device, which contrasts the inefficiency of having to translate communication protocols and/or programming languages when communicating through the network computing device. 
     Collecting automated device information allows the local circuitry to generate an optimization strategy in step  234 . The optimization strategy at least incorporates the capabilities of the newly installed automated device with the other automated devices of the system. As a non-limiting example, an optimization strategy can accomplish a previously conducted automation task by changing the timing, scope, type, or duration of one or more automation activities executed by the various automated devices of the system. As a result of utilizing the local computing circuitry of an automated device, the optimization strategy can increase the efficiency, safety, and productivity of the automation system by intelligently incorporating the newly installed automated device without degrading the efficiency of the network computing device. 
     The optimization strategy generated in step  234  may involve the reprogramming, repurposing, or otherwise altering the operation of one or more automated devices. Decision  236  determines if such an alteration is needed. If so, step  238  effectuates the optimization strategy with the local computing circuitry of at least one automated device by altering at least the programming code of at least one automated device. In the event no other automated device is to be altered to accomplish the optimization strategy, or at the conclusion of step  234 , the local computing circuitry of an automated device programs the newly installed automated device in step  240  to be conducive to the automation tasks and the other automated devices of the system. 
     It is contemplated that the optimization strategy and programming of steps  238  and  240  may involve the enabling of device capabilities that were previously dormant or unavailable, such as sensing or automation activity provided by the connected local computing circuitry. The various alterations and capabilities of the respective automated devices can be conveyed to the network computing device at any time so that the network computing device can properly evaluate system performance and report accurate measurements and calculations to remote hosts. 
     With the newly installed automated device programmed in accordance with the optimization strategy, step  242  employs the programming of the respective automated devices of the automation system to carry out one or more automation tasks. By moving automated device incorporation and optimization to the edge of the automation system with local computing circuitry connected to an automated device, the network computing device is bypassed, which allows for more efficient channel, data storage, and processing utilization. Employing the local computing circuitry, instead of the network computing device, to evaluate real-time automated device operation further allows for efficient network computing device utilization while decreasing the computing requirements of the network computing device. 
       FIG. 8  depicts portions of an example edge computing automation system  250  arranged in accordance with some embodiments. The system has a central OPC-UA Server that is connected to multiple different data source gateways and respectively employ via two-way communications. One or more databases can be employed by the Server to aid in the issuance of at least one device command that is relayed to an automation device, or remote data input/output (I/O) once receiving a device identification (ID) from the XML data of the local data source gateway. 
     One or more automation devices can be used to collect/detect conditions and operating parameters of the system  250 . Such readings can be used to determine the operation of other automation devices. For instance, a measurement from a device, or I/O, can prompt a different automation device to activate or deactivate depending on the static configuration programmed into the system  250  by the logic. As shown, but in no way required or limiting, the remote I/O can handle multiple different device activities while a programmable logic controller (PLC) may alternatively be placed in-line between one or more automation devices and a data source gateway. 
     It is noted that the Server can communicate with the respective local data source gateways, but the gateways cannot communicate amongst themselves, independent of the Server. Hence, all collected measurements and readings must flow through the Server in order to prompt action by other automation devices, which can degrade performance when numerous gateways are connected and place an undue security risk with the integrity of the Server. 
     The example edge computing automation system  270  of  FIG. 9  illustrates how various embodiments can configure data source gateways with hardware that allows two-way communications independent of the Server. The ability for gateway-to-gateway two-way communications allows for more sophisticated automation of device activities as the channel, bandwidth, and processing of the Server is not the limiting factor, as it is in the system  250  of  FIG. 8 . For instance, the gateways, and Server, can utilize local gateway logic data (Logic XML) to respond to measured/detected conditions not with a static action (activate/deactivate), as with system  250 , but instead with a trigger setpoint that provides a range of readings for a particular automation activity/function. 
     It is noted that utilizing the data source gateways for computing and automation activity, instead of the central Server, distributes the computing requirements of the system  270  and reduces performance bottlenecks associated with centralized Server management. The ability for gateways to communicate directly further allows for efficient introduction of new automation devices as the gateways, instead of the Server, can generate and utilize a new unique network address from a new automation device, which contrasts having to wait for the Server to identify, poll, and integrate a newly connected device into the system  270 . 
     Through the assorted embodiments of an automation system employing a local computing circuitry connected to an automation device, the automation system can continuously operate in an optimized configuration due to the real-time monitoring of operating conditions and subsequent alteration of automated device programming. The ability to incorporate a new automated device or alter the programming of an existing automated device automatically with local computing circuitry without bringing the entire automation system offline while a user manually writes software, code, and/or commands provides long-term automation system viability and performance. 
     The local computing circuitry&#39;s ability to automatically gather system information and effectuate automated device code allows any type of device from any manufacturer that communicates with any protocol and executes any programming language to be automatically incorporated and optimized into an automation system without manual user involvement or processing with the network computing device. By configuring local computing circuitry as hardware that can be externally attached and connected to an automated device, legacy devices that otherwise would not have sophisticated capabilities can be upgraded and optimized simply by connecting the local computing circuitry. 
     It is to be understood that even though numerous characteristics of various embodiments of the present disclosure have been set forth in the foregoing description, together with details of the structure and function of various embodiments, this detailed description is illustrative only, and changes may be made in detail, especially in matters of structure and arrangements of parts within the principles of the present technology to the full extent indicated by the broad general meaning of the terms in which the appended claims are expressed. For example, the particular elements may vary depending on the particular application without departing from the spirit and scope of the present disclosure.