Due to advances in computing technology, businesses today are able to operate more efficiently when compared to substantially similar businesses only a few years ago. For example, internal networking enables employees of a company to communicate instantaneously by email, quickly transfer data files to disparate employees, manipulate data files, share data relevant to a project to reduce duplications in work product, etc. Furthermore, advancements in technology have enabled factory applications to become partially or completely automated. For instance, operations that once required workers to put themselves proximate to heavy machinery and other various hazardous conditions can now be completed at a safe distance therefrom.
Further, imperfections associated with human action have been minimized through employment of highly precise machines. Many of these factory devices supply data related to manufacturing to databases that are accessible by system/process/project managers on a factory floor. For instance, sensors and associated software can detect a number of instances that a particular machine has completed an operation given a defined amount of time. Further, data from sensors can be delivered to a processing unit relating to system alarms. Thus, a factory automation system can review collected data and automatically and/or semi-automatically schedule maintenance of a device, replacement of a device, and other various procedures that relate to automating a process.
While various advancements have been made with respect to automating an industrial process, utilization and design of controllers have been largely unchanged. In more detail, industrial controllers have been designed to efficiently undertake real-time control. For instance, conventional industrial controllers receive data from sensors and, based upon the received data, control an actuator, drive, or the like. These controllers recognize a source and/or destination of the data by way of a symbol and/or address associated with source and/or destination. More particularly, industrial controllers include communications ports and/or adaptors, and sensors, actuators, drives, and the like are communicatively coupled to such ports/adaptors. Thus, a controller can recognize device identity when data is received and further deliver control data to an appropriate device.
As can be noted from the above, data associated with conventional industrial controllers is created, delivered, and/or stored with a flat physical address space. In other words, all that can be discerned by reviewing data received and/or output by a controller is the memory location where the data for an actuator or sensor and a status resides. This industrial controller architecture operates efficiently for real-time control of a particular device—however, problems can arise when data from industrial controllers is desired for use by a disparate system, user, programmer, device, application, etc. For example, if data from the controller was desired for use by a scheduling application, individual(s) familiar with the controller must determine which data is desirable, cross-reference the data's memory location, export the memory contents, and then extract the necessary data accordingly. The problem is compounded if several applications wish to utilize similar data and/or if the names and/or memory locations associated with the controller data changes.
In particular, data variables, memory locations, names, etc. can be stored off-line in, for example, a project file. In order for other devices, systems, applications, etc. to take advantage of such information, the programmer must export information to a file (e.g., text file) and then extract the desired names from the file (e.g., utilizing a software tool and/or manual extraction). Such task can be daunting, meticulous, and inefficient, yet if the memory locations or names for the data change, the task would need to be repeated to re-associate the system software with the data.
USPTO Backgrounds
USPTO Backgrounds