Patent Description:
<CIT> discloses methods for updating industrial controllers after they are deployed, while actively controlling an industrial process and without downtime. The document proposes storing a replacement machine-readable component in an allocated program space, locating and modifying dependent machine-readable components copied in the allocated program space to instead depend on the replacement machine-readable component, re-linking a copy of the control program in the allocated program space, and redirecting execution to the control program in the allocated program space. Replacement machine-readable components could be instructions, libraries or subroutines of the control program. The object of the present invention is to provide a method and a programmable logic controller allowing updating controller at reduced computational overhead. This object is solved by the subject-matter of the independent claims. Embodiments of the present invention are defined by the dependent claims.

As described above, PLCs often have instruction set libraries that are closely coupled to the controller firmware and that are historically the entire instruction set regardless of the PLC's function. This type of architecture leads to inefficiencies, for example when the instruction set is updated, for several reasons. First, the PLC and accompanying machines must be stopped to perform the update of the instruction set and controller firmware leading to downtime for the company. Second, the PLC stores the entire instruction set, so any update that is done on the instruction set must be performed on all PLCs, sometimes even if the PLC does not include programming that uses the updated instructions. Third, because the instruction set architecture is so closely coupled to the firmware of the PLC, updates are not backward compatible and the controller firmware also requires update when the instruction set library is updated and vice versa. Finally, the size of the instruction set and the requirement to transmit/receive/download the entire instruction set library is far larger than necessary, particularly for smaller updates.

These problems are addressed using techniques and systems as described herein. In one aspect, a method for updating an instruction set library in a programmable logic controller is provided. The method is performed by a programmable logic controller that receives an updated instruction set library that includes programming instructions. The programmable logic controller may identifies affected routines, where the affected routines include one or more of the programming instructions, and where the affected routines are executed as part of executable code of the programmable logic controller to provide input signals to and receive output signals from a physical machine in an automation environment. The programmable logic controller binds the updated instruction set library to an application programming interface of the programmable logic controller. The programmable logic controller rebinds the affected routines to the updated instruction set library, where the rebinding is performed between scans of the executable code of the programmable logic controller. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations of this aspect may include additional features. Optionally, the programmable logic controller may delete the original instruction set library from memory after the update. Optionally, the programming instructions are first programming instructions, the instruction set library may include second programming instructions, and at least one of the first programming instructions is included in the second programming instructions. Optionally, the programming instructions are first programming instructions, the instruction set library may include second programming instructions, and the first programming instructions may include additional programming instructions not included in the second programming instructions. The programming instructions are first programming instructions, the instruction set library may include second programming instructions, and a first programming instruction of the first programming instructions is an updated programming instruction of the second programming instructions. Optionally, the instruction set library is a first instruction set library of several instruction set libraries in the programmable logic controller and the programming instructions are a first subset of programming instructions, and each of the instruction set libraries may include a different subset of programming instructions. Binding the updated instruction set library to the application programming interface binds the updated instruction set library to firmware functions of the programmable logic controller. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

In another aspect, a programmable logic controller includes controller firmware, a processor, and a memory. The memory has stored thereon an instruction set library containing programming instructions, a executable code that includes routines and that, when executed, cause the processor to provide input signals to and receive output signals from a physical machine in an automation environment, where each of the routines may include instructions from the programming instructions, and an application programming interface used to bind the instruction set library to the controller firmware. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations of this aspect may include additional features. The instruction set library is divided into partitions, and each partition may include a subset of the programming instructions. Optionally, the instruction set library may include a portion of a complete set of instructions where the programming instructions in the instruction set library are selected from the complete set of instructions based on the routines used in the executable code of the programmable logic controller.

In yet another aspect, a method for supporting programming instructions in a programmable logic controller across versions is provided. The programmable logic controller may access an instruction set library that may include several partitions where each partition may include several programming instructions. The programmable logic controller may download a subset of the partitions based on executable code of the programmable logic controller. The programmable logic controller may bind the downloaded subset of the partitions to an application programming interface of the programmable logic controller. The programmable logic controller may bind a first routine that includes a first instruction to a first partition of the subset of partitions that includes the first instruction. Other embodiments of this aspect include corresponding computer systems, apparatus, and computer programs recorded on one or more computer storage devices, each configured to perform the actions of the methods.

Implementations of this aspect may include additional features. Optionally, the programmable logic controller may receive an updated first partition that includes the first instruction, bind the updated first partition to the application programming interface, and rebind the first routine to the updated first partition between scans of the executable code. Implementations of the described techniques may include hardware, a method or process, or computer software on a computer-accessible medium.

The components in the drawings are not necessarily drawn to scale. While several embodiments are described in connection with these drawings, the disclosure is not limited to the embodiments disclosed herein.

The drawings have not necessarily been drawn to scale. Similarly, some components or operations may not be separated into different blocks or combined into a single block for the purposes of discussion of some of the embodiments of the present technology. Moreover, while the technology is amendable to various modifications and alternative forms, specific embodiments have been shown by way of example in the drawings and are described in detail below. The intention, however, is not to limit the technology to the particular embodiments described.

The figures may include elements that are groupings of similar elements that are notated as such with an element number and appended letter (e.g., machine 120a, 120b, 120n). Where an element number is followed by a letter, reference is made to the specific element. Where an element number is used without a specific letter, reference is made to the entire group or any one of the entire group (e.g., machines <NUM> or any one of machines <NUM>).

The following description and associated figures teach the best mode of the invention. For the purpose of teaching inventive principles, some conventional aspects of the best mode may be simplified or omitted. The following claims specify the scope of the invention. Note that some aspects of the best mode may not fall within the scope of the invention as specified by the claims. Thus, those skilled in the art will appreciate variations from the best mode that fall within the scope of the invention. Those skilled in the art will appreciate that the features described below can be combined in various ways to form multiple variations of the invention.

As described above, PLCs often have instruction set libraries that are closely coupled to the controller firmware and that are historically the entire instruction set regardless of the PLC's function. This type of architecture leads to inefficiencies, for example when the instruction set is updated for several reasons. First, the PLC and accompanying machines must be stopped to perform the update of the instruction set and controller firmware leading to downtime for the company. Second, the PLC stores the entire instruction set, so any update that is done on the instruction set must be performed on all PLCs, sometimes even if the PLC does not include programming that uses the updated instructions. Third, because the instruction set architecture is so closely coupled to the firmware of the PLC, updates are not backward compatible and the controller firmware also requires update when the instruction set library is updated and vice versa. Finally, the size of the instruction set and the requirement to transmit/receive/download the entire instruction set library is far larger than necessary, particularly for smaller updates.

To address these and other issues, systems and methods are described herein to decouple the instruction set architecture from programmable logic controller ("PLC") firmware as well as, in some embodiments, partition the instruction set library. By doing so, PLCs may obtain updates to only the instruction set library partitions that impact that particular PLC. Also, the updates can be performed between scans of the PLC's executable code, which avoids downtime for the automation environment. Further, the instruction set libraries can be backward compatible when decoupled from the controller firmware. These improvements are described in more detail with respect to the figures.

Turning now to <FIG>, an exemplary automation environment <NUM> is depicted in a simplified block diagram format. The automation environment <NUM> includes a remote server <NUM>, automation server <NUM>, programmable logic controllers <NUM>, and machines <NUM>, <NUM>, and <NUM>. The automation environment <NUM> may be any automation environment including, for example, an oil refinery, an automotive automation line, and so forth.

The remote server <NUM> may be any one or more suitable computing devices such as, for example, computing device <NUM> as described with respect to <FIG>. The remote server <NUM> may be a computing device from which updates <NUM> to portions of a programmable logic controller ("PLC") <NUM> may be served. The updates <NUM> provided to PLCs <NUM> may include instruction set updates, firmware updates, routine updates, and so forth. The instruction set architecture includes an instruction set library that provides the foundation of the instructions used to program a PLC <NUM> for controlling a machine <NUM>, <NUM>, <NUM>. Such instructions include the functions that can be used for reading and writing input and output values to the machines <NUM>, <NUM>, <NUM>. When updates occur, instructions are added, removed, or updated in the instruction set library or other changes within the instruction set library or a partition of the instruction set library are made. For example, a data type modification may be an update, which may include a modification to the data type or may include a modification of the data type used for an instruction. The update <NUM> is sent from the remote server <NUM> to the automation server <NUM> for proliferating to the PLCs <NUM> to implement the update <NUM>. An update <NUM> may be an update to one or more partitions of the instruction set library or to the entire instruction set library.

The automation server <NUM> may be any one or more suitable computing devices such as, for example, computing device <NUM> as described with respect to <FIG>. The automation server <NUM> may be one or more centralized servers for providing information to and receiving information from PLCs <NUM> within the automation environment <NUM>. For example, the automation server <NUM> may receive the updates <NUM> from the remote server <NUM> and proliferate the updates <NUM> to the PLCs <NUM>. In some embodiments, the automation server <NUM> may make decisions upon receipt of updates <NUM> as to which PLCs <NUM> should receive the updates. In some embodiments, the updates reside in automation server <NUM> and the PLCs <NUM> may access and download appropriate updates <NUM> as needed. For example, automation server <NUM> may send a notification to PLCs <NUM> to notify them of an available update. In some embodiments, automation server <NUM> may notify only impacted PLCs <NUM> of the available update. As described in more detail with respect to <FIG>, an update <NUM> may include an instruction set library partition. As an example, PLC 115a may utilize the updated instruction set partition included in update <NUM> while PLC 115b may not utilize the updated instruction set partition. In such an example, the automation server <NUM> may not provide the update <NUM> to PLC 115b but will provide it to PLC 115a or PLC 115a will download the update <NUM> while PLC 115b will not download the update <NUM>.

Programmable logic controllers ("PLCs") <NUM> are computing devices that are developed and designed to be rugged to withstand the harsh conditions associated with an industrial automation environment and provide extensive input/output to connect to sensors, actuators, and other control devices of the machines <NUM>, <NUM>, <NUM> that are controlled by the PLCs <NUM>. PLCs <NUM> may be any suitable programmable computing devices such as, for example, programmable logic controller <NUM> as described with respect to <FIG>. While three PLCs <NUM> are depicted in <FIG>, the automation environment may include any number of PLCs <NUM> as shown by PLC 115a through PLC 115n. And, each PLC <NUM> is depicted as controlling at least one of machines <NUM>, <NUM>, <NUM>. For example, PLC 115a controls machines 120a, 120b, and 120n, which indicates that PLC 115a may control any number of machines <NUM>. Similarly, PLC 115b controls machines 125a, 125b, and 125n indicating that PLC 115b may control any number of machines <NUM>, and PLC 115n controls machines 130a, 130b, and 130n indicating PLC 115n controls any number of machines <NUM>. Machines <NUM>, <NUM>, <NUM> may be any industrial automation machines having input and output that can be received from and sent to PLCs <NUM>.

In use, a programmer may use the instruction sets available on PLCs <NUM> to develop logic that is utilized in executable code of the PLC <NUM>. The executable code may include programs that may contain routines developed using the programming instructions in the PLC <NUM> and that read and write input and output values to and from the machines <NUM>, <NUM>, <NUM> such that as the executable code of the PLC <NUM> is executed, the machines <NUM>, <NUM>, <NUM> perform operations under the control of the PLC <NUM> based on the execution of the executable code. The remote server <NUM> may provide an update <NUM> of one or more instruction set libraries or library partitions to the automation server <NUM>. The Automation server <NUM> may determine which PLCs <NUM> should be updated with the update <NUM> and provides the update <NUM> to the appropriate PLCs <NUM> or sends a notice of the update <NUM> to PLCs <NUM>, which may then access and download the update <NUM>. The receiving PLCs <NUM> may update the instruction set library or library partitions between scans of the executable code as will be described in more detail with respect to <FIG>.

<FIG> illustrates an exemplary PLC <NUM> and an exemplary PLC <NUM>. The PLC <NUM> is operating with a first integrated development environment ("IDE") version. In the case of PLC <NUM>, the IDE version is identified as V1x <NUM>. PLC <NUM> includes memory <NUM>, controller firmware <NUM>, and machine I/O <NUM>. PLC <NUM> may include other components not included here for simplicity. For example, PLC <NUM> may include components of PLC <NUM> as described with respect to <FIG>.

Machine I/O <NUM> is the input and output interfaces in PLC <NUM> that can be coupled to the machines (c. machines <NUM>, <NUM>, <NUM> as described with respect to <FIG>) that PLC <NUM> controls. The machine I/O <NUM> is used to send (i.e., output) and receive (i.e., input) signals to and from the machines being controlled by PLC <NUM>.

Controller firmware <NUM> includes API <NUM>. Controller firmware <NUM> is versioned based on the IDE version, in this case V1x. The IDE defines the development environment such as, for example, the compiler that is used to compile the programmed executables within the PLC <NUM>. Differing versions of the IDE may impact compatibility between PLC programming components. For example, the controller firmware <NUM> is flashed to be compatible with a given IDE version, in this case V1x. The controller firmware <NUM> interfaces with the machine input/output ("I/O") <NUM>. Accordingly, the instruction set library available to the controller firmware <NUM> via the binding of the API <NUM> with the partitions in memory <NUM> should be compatible with the controller firmware <NUM> to provide proper instructions to the machine I/O <NUM> to ensure the machines being controlled by the PLC receive the proper instructions. In the past, an update to the instruction set library, which was closely coupled to the controller firmware would have failed to work properly if the instruction set library was not compiled with the same version of the IDE known to the PLC controller firmware. The described architecture of PLCs <NUM>, <NUM> allows for backward compatibility. As such, for example, PLC <NUM> may be updated with version <NUM>. <NUM> of partition B <NUM>.

The memory <NUM> includes partition A <NUM> and partition B <NUM>. Partition A <NUM> and partition B <NUM> were compiled with IDE version V1x. Partition A <NUM> is version <NUM>. <NUM> (compiled with IDE version V1x) and includes instructions <NUM>, <NUM>, <NUM>. These instructions may be used to develop logic for controlling machines, such as machines <NUM>, <NUM>, and <NUM> as described with respect to <FIG>. The instructions <NUM>, <NUM>, <NUM> are instructions forming an instruction set library within partition A <NUM>. Partition A <NUM> may also be called an instruction set library partition or a subset of instructions. Instructions <NUM>, <NUM>, <NUM> are a subset of instructions from an overall instruction set library. The overall instruction set library is a complete set of instructions that may be used within logic that is executed by the PLC <NUM> to control physical machines in an industrial automation environment such as automation environment <NUM> as described with respect to <FIG>. By partitioning the overall (i.e., complete or entire) instruction set library into partitions such as partition A <NUM> and partition B <NUM>, the overall instruction set library need not be provided to every PLC <NUM>, <NUM>. For example, a customer having an oil and gas environment may not need certain instructions in some partitions that may be used, for example, in an automotive automation line. In some embodiments, partitions may be created for specific industries or machines.

Partition B <NUM> is version <NUM>. <NUM> (compiled with IDE version V1x) and includes instructions <NUM>, <NUM>. These instructions may also be used to develop logic for controlling machines controlled by PLC <NUM>. Partition B <NUM> is similar to partition A <NUM> in that it may also be called an instruction set library partition or a subset of instructions and may include some or all of the instructions in the complete instruction set library.

The instructions <NUM>, <NUM>, <NUM> in partition A <NUM> are bound to the application programming interface ("API") <NUM>. The instructions <NUM>, <NUM> in partition B <NUM> are also bound to API <NUM>. The API <NUM> provides the interface for the partitions to communicate with the controller firmware <NUM>. The controller firmware <NUM> communicates with machine I/O <NUM>. This binding allows the correlation of the instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> within partition A <NUM> and partition B <NUM> to the controller firmware <NUM>, which is used to control machines (e.g., machines <NUM>, <NUM>, <NUM> as described with respect to <FIG>) via the machine I/O <NUM>. The controller firmware <NUM> provides the interface between the machine I/O <NUM> and the software utilizing the instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. The controller firmware <NUM> includes access to controller and embedded functions such as operating system functions, the controller scheduler, timers, input and output of the controller (e.g., machine I/O <NUM>), and the hardware abstraction layer.

PLC <NUM> is operating with a second IDE version. In the case of PLC <NUM>, the IDE version is identified as V2x <NUM>. Version V2x indicates a newer version than the IDE version V1x. PLC <NUM> is configured similarly to PLC <NUM>. PLC <NUM> includes memory <NUM>, controller firmware <NUM>, and machine I/O <NUM>. The controller firmware <NUM> communicates with machine I/O <NUM> to exchange signals (i.e., I/O) with the machines that PLC <NUM> controls. The API <NUM> provides the interface for the instructions within partitions in memory <NUM> that are bound to API <NUM> to communicate with the controller firmware <NUM>. Memory <NUM> includes partition A <NUM> and partition B <NUM>. Partition A <NUM> is a newer version of partition A <NUM>. Where partition A <NUM> was version <NUM>. <NUM>, partition A <NUM> is version <NUM>. Partition A <NUM> was compiled with IDE version V2x. Partition B <NUM> is a newer version of partition B <NUM>. Where partition B <NUM> is version <NUM>. <NUM>, partition B <NUM> is version <NUM>. Partition B <NUM> was compiled with IDE version V2x. Instruction <NUM> is an update of instruction <NUM> in partition A <NUM>. Instruction <NUM> is a new instruction added into partition B <NUM>.

The inclusion of the instruction set library in partitions in the memory <NUM> and the decoupling of the instruction set library from the controller firmware allow for multiple advantages. Partitioning the instruction set library limits the updates and downloads needed for PLCs <NUM>, <NUM> to those partitions that are used by the PLC <NUM>, <NUM> respectively. Decoupling the partitions <NUM>, <NUM> from the controller firmware <NUM> and partitions <NUM>, <NUM> from controller firmware <NUM> allows the PLC <NUM>, <NUM> to be updated without stopping the PLC <NUM>, <NUM> to flash the controller firmware <NUM>, <NUM>. This allows updates to the partitions <NUM>, <NUM>, <NUM>, <NUM> to occur between scans of the executable code (e.g., programs <NUM> as described with respect to <FIG>) of the respective PLC <NUM>, <NUM> that utilizes the instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>. Further, the architecture allows for backward compatibility. The controller firmware <NUM> of PLC <NUM> is using IDE version V2x (i.e., a higher version) than the controller firmware <NUM> of PLC <NUM> that is using IDE version V1x. As shown, partition A <NUM> in PLC <NUM> includes three instructions <NUM>, <NUM>, <NUM>. Partition A <NUM> in PLC <NUM> is a higher version <NUM>. <NUM> than partition A <NUM>, and partition A <NUM> in PLC <NUM> includes instructions <NUM>, <NUM>, <NUM>, and an additional instruction <NUM>. Instruction <NUM> is an updated instruction of instruction <NUM>. Yet, partition A <NUM> is backward compatible with partition A <NUM> because the old instruction <NUM> is included in partition A <NUM>. Instruction <NUM> is not bound to API <NUM> because instruction <NUM>, which is updated, is bound. As shown in <FIG> and described further below, a PLC with an older IDE version would bind instruction <NUM> to the API and not bind instruction <NUM>. Partition B <NUM> in PLC <NUM> is version <NUM>. <NUM>, and partition B <NUM> in PLC <NUM> is version <NUM>. <NUM>-a higher version. Partition B <NUM> includes an additional instruction <NUM> than is included in the partition B <NUM> in PLC <NUM>. Since instruction <NUM> is not available or used in older versions, partition B <NUM> can be backward compatible by not binding instruction <NUM> to the API in controller firmware using previous IDE versions than V2x, which is what was used to compile partition B <NUM>. In some embodiments. instructions in partitions may be removed by not binding the instructions to the API in the later versions while still including the instruction and binding it to the API in controllers with older versions of the IDE. Backward compatible partitions are described in more detail with respect to <FIG>.

<FIG> illustrates two PLCs <NUM>, <NUM>. PLC <NUM> and PLC <NUM> arc each operating with the controller firmware <NUM>, <NUM> using IDE version V1x as shown by IDE component <NUM>. PLC <NUM> includes memory <NUM>, controller firmware <NUM>, and machine I/O <NUM>. PLC <NUM> may include other components, such as those described with respect to PLC <NUM> of <FIG>, that are not included here for simplicity. Memory <NUM> includes partition A <NUM> having version <NUM>. <NUM> and partition B <NUM> having version <NUM>. <NUM>, each having been compiled with IDE version V1x. Partition A <NUM> and partition B <NUM> are described further with respect to <FIG>. Partition A <NUM> includes instructions <NUM>, <NUM>, <NUM>. Partition B <NUM> includes instructions <NUM>, <NUM>. The instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in PLC <NUM> are bound to API <NUM>. Controller firmware <NUM> is using IDE version V1x and includes API <NUM>. API <NUM> allows the bound instructions in memory <NUM> to access controller firmware <NUM>. The controller firmware <NUM> communicates with machine I/O <NUM> to send signals to and receive signals from the machines coupled to the machine I/O <NUM>. Accordingly, the instructions within memory <NUM> are used to control the machines coupled to the machine I/O <NUM> via the controller firmware <NUM> and API <NUM>. Each of the instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> are bound to API <NUM> because the partition A <NUM> and partition B <NUM> were compiled with the same IDE version V1x that the controller firmware <NUM> is using.

PLC <NUM> includes memory <NUM>, controller firmware <NUM>, and machine I/O <NUM>. PLC <NUM> may include other components, such as those described with respect to PLC <NUM> of <FIG>, that are not included here for simplicity. Memory <NUM> includes partition A <NUM> having version <NUM>. <NUM> and partition B <NUM> having version <NUM>. <NUM>, each having been compiled with IDE version V2x. Partition A <NUM> and partition B <NUM> are described further with respect to <FIG>. Partition A <NUM> includes instructions <NUM>, <NUM>, <NUM>. Partition B <NUM> includes instructions <NUM>, <NUM>, <NUM>. Instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM> in PLC <NUM> are bound to API <NUM>. Controller firmware <NUM> includes API <NUM>. API <NUM> allows the bound instructions in memory <NUM> to access controller firmware <NUM>. The controller firmware <NUM> communicates with machine I/O <NUM> to send signals to and receive signals from the machines coupled to the machine I/O <NUM>. Accordingly, the instructions within memory <NUM> that are bound to API <NUM> are used to control the machines coupled to the machine I/O <NUM> via the controller firmware <NUM> and API <NUM>.

Instructions <NUM>, <NUM> are not bound to API <NUM> in PLC <NUM> because controller firmware <NUM> is using IDE version V1x (i.e., an older version of the IDE). Partition A <NUM> and partition B <NUM> were each compiled with IDE version V2x, but both are backward compatible. Updated instruction <NUM> that replaces instruction <NUM> in version <NUM>. <NUM> of partition A <NUM> compiled with version V2x of the IDE is not bound to the API in controller firmware using older versions of IDE, and the old instruction <NUM> is still included in partition A <NUM> so it can be bound to the API of controller firmware using older IDE versions. Accordingly, as shown in PLC <NUM> having controller firmware <NUM> using an older version of the IDE (V1x) than was used to compile the partition A <NUM>, the legacy instruction <NUM> is bound to the API <NUM> from partition A <NUM>, and in PLC <NUM> (referring back to <FIG>) having the same version of the IDE (V2x) as was used to compile the partition A <NUM>, the new instruction <NUM> is bound to the API <NUM> from partition A <NUM> and the legacy instruction <NUM> is not bound to the API <NUM>. Similarly, the new instruction <NUM> in partition B <NUM> is not bound to API <NUM> because controller firmware <NUM> does not support the new instruction because it is using the older IDE version (V1x), but the new instruction <NUM> in partition B <NUM> is bound to API <NUM> in PLC <NUM> (referring back to <FIG>) because the controller firmware <NUM> does support the new instruction because it is using the same IDE version (V2x) that was used to compile the partition B <NUM>. Therefore, the decoupled architecture of the instruction set library (e.g., partitions in memory) from the controller firmware allows for backward compatibility of the instruction set library to PLCs using older versions of an IDE than was used to compile the instruction set library.

Turning now to <FIG>, an explanation of the updating of the instruction set libraries is described. <FIG> illustrates a PLC <NUM>. PLC <NUM> may be any suitable programmable logic controller in an industrial automation environment such as automation environment <NUM> as described with respect to <FIG>. PLC <NUM> may include additional components than are described here for clarity. The additional components may include components such as those described with respect to PLC <NUM> as described with respect to <FIG>. PLC <NUM> includes memory <NUM> and controller firmware <NUM>. Memory <NUM> includes API <NUM>, programs <NUM>, and instruction set architecture library partitions <NUM>.

Programs <NUM> may include any number of programs <NUM>. <NUM>, <NUM>. Programs <NUM> includes three programs, program A <NUM>, program B <NUM>, and program C <NUM>, but may include more or fewer programs depending on the machines, such as machines <NUM>, <NUM>, <NUM> described in <FIG>, that PLC <NUM> is controlling. Each of these programs may be executed by a processor (not shown) sequentially. For example, program A <NUM> may be the first in the sequence, so program A <NUM> is executed first, then the next program is executed, for example program B <NUM>, and then the next, for example program C <NUM>, until there are no further programs to be executed. Completion of the sequence is a scan, and once a scan is complete, the sequence starts over with the first program to perform another scan. Within each program are routines that are also executed sequentially. For example, program A <NUM> includes routines <NUM>, <NUM>, <NUM> that are executed sequentially. The programs (e.g., program A <NUM>, program B <NUM>, and program C <NUM>) within programs <NUM> are the executable code of PLC <NUM>. Program A <NUM> includes routines <NUM>, <NUM>, <NUM>. Each routine, such as routine <NUM> for example, is built using the instructions from the instruction set library. A technician may program the PLC <NUM> using, for example, ladder logic programming that uses the instructions from the instruction set library, to build the routines, such as routine <NUM>, that are executed on PLC <NUM> by a processor. Ladder logic resembles ladders with two vertical rails and a series of horizontal rungs between them. The rungs each include instructions from the instruction set library. When executing, the rungs are executed sequentially to sequentially execute the routines and programs for a complete scan of the executable code. In some embodiments, the scans occur many times per second.

Program B <NUM> may include, for example, routines <NUM>, <NUM>. Program C <NUM> may include routines <NUM>, <NUM>, <NUM>, <NUM>, for example. Each program within programs <NUM> may include any number of routines.

Within memory <NUM> are instruction set architecture library partitions <NUM>. These partitions include subsets of instructions that are from the overall instruction set library supported by the PLC <NUM>. As described with respect to <FIG>, the partitions may include any number of instructions. Instruction set library partitions <NUM> includes core <NUM> partition <NUM>, motion <NUM> partition <NUM>, and process <NUM> partition <NUM>. The core <NUM> partition <NUM> may include core instructions for PLC <NUM>, and the version of the partition may be version <NUM>. The motion <NUM> partition <NUM> may include instructions from the instruction set library used for motion controls of one or more machines controlled by PLC <NUM>. The motion <NUM> partition <NUM> may be version <NUM>. The process <NUM> partition <NUM> may include instructions from the instruction set library for completing a process with one or more machines controlled by PLC <NUM>. Process <NUM> partition <NUM> may be version <NUM>. As shown, core <NUM> partition <NUM> is bound to API <NUM>, motion <NUM> partition <NUM> is bound to API <NUM>, and process <NUM> partition <NUM> is bound to API <NUM>, as described with respect to <FIG>. API <NUM> provides the interface to controller firmware <NUM> as described with respect to <FIG>. Accordingly, the instructions within each partition <NUM>, <NUM>, <NUM> are bound to controller firmware <NUM> via API <NUM>.

PLC <NUM> may receive updated process <NUM> partition <NUM>. Process <NUM> partition <NUM> may be version <NUM> of the process instruction set library partition, and is intended to replace process <NUM> partition <NUM>. Upon receipt of the process <NUM> partition <NUM>, the PLC <NUM> determines which routines within the programs <NUM> are impacted by the update. For example, if a routine includes an instruction within the process <NUM> partition <NUM>, the routine will be deemed impacted. In some embodiments, the IDE (not shown) within PLC <NUM> may determine which routines are impacted. In some embodiments, the controller may determine which routines are impacted. In the example shown in <FIG>, at least one instruction within routine <NUM> and routine <NUM> are impacted by the update. Between scans of the executable code, so that the PLC <NUM> and associated machines need not be shut down, the PLC <NUM> binds the instructions within process <NUM> partition <NUM> to the API <NUM> and breaks the binding between the instructions within process <NUM> partition <NUM> and API <NUM>. Additionally, the PLC <NUM> rebinds the instructions within process <NUM> partition <NUM> with the impacted routines <NUM>, <NUM> and breaks the binding between the instructions within process <NUM> partition <NUM> and impacted routines <NUM>, <NUM>. By completing this breaking of bindings and new binding to the API and rebinding of the instructions with the updated partition <NUM>, the process <NUM> partition <NUM> is updated. Process <NUM> partition <NUM> may be deleted from memory <NUM>, in some embodiments. On the next scan of the executable code, the instructions from the updated process <NUM> partition <NUM> are used for execution.

As shown in <FIG>, the instruction set architecture library partitions <NUM> include various partitions <NUM>, <NUM>, <NUM>, <NUM> including core instructions, motion instructions, and process instructions. The complete instruction set library that is supported by PLC <NUM> may include many more programming instructions that are not included in the subsets of programming instructions that are within in partitions <NUM>, <NUM>, <NUM>. The routines used to control the machines that PLC <NUM> controls may not include all the instructions from the complete instruction set library, and therefore including every instruction within the instruction set architecture library partitions is not necessary. Further, various industries have differing needs, and therefore there may be instruction set partitions that include appropriate instructions needed for a given industry or machine and exclude other instructions. The instruction set partitions created for various industries or machines may overlap (i.e., contain some of the instructions but not others) those instruction set partitions created for other industries or machines. For example, a given Machine A may have a motion partition including instructions that are different from or in some cases overlap the motion partition for a different Machine B. In some embodiments, a single partition may be used and may include a subset or all of the instructions in the instruction set library. Even if partitions are not used to limit the number of instructions in the PLC <NUM>, the decoupling of the instruction set library from the controller firmware provides benefits such as "hot" updates that do not require downtime of the PLC or machines.

<FIG> depicts the components of a PLC <NUM> involved in the updating process. <FIG> may be used to describe the initial setup of PLC <NUM> as well. PLC <NUM> may access an instruction set library that is stored, for example, in automation server <NUM> as described with respect to <FIG>. The instruction set library may include instruction set library partitions, and the PLC <NUM> may download the instruction set library partitions that are appropriate for the PLC <NUM> based on the machines that PLC <NUM> controls. In the example shown, PLC <NUM> downloads core <NUM> partition <NUM>, motion <NUM> partition <NUM>, and process <NUM> partition <NUM>. After downloading, PLC <NUM> binds the instructions within each partition <NUM>, <NUM>, <NUM> to API <NUM>. The instructions within routines of programs in programs <NUM> are bound to the appropriate partitions <NUM>, <NUM>, <NUM> as the programs and routines are developed. Further, in some embodiments, the entire instruction set library used for PLC <NUM> may be in a single partition. In some embodiments, the complete instruction set library available for use on PLC <NUM> may be in a single partition. As such, the benefits of decoupling the instructions from the controller firmware are still realized.

<FIG> illustrates a method <NUM> for updating an instruction set library. The method <NUM> may be performed by, for example PLC <NUM>, PLC <NUM>, PLC <NUM>, and/or PLC <NUM>. The PLC may receive an updated instruction set library comprising a plurality of instructions at step <NUM>. For example, as shown in <FIG>, PLC <NUM> received updated process <NUM> partition <NUM>. In some embodiments, only a single partition or instruction set library is used in the PLC. In some embodiments, the update may include multiple partitions that are updated.

At step <NUM>, the PLC identifies affected routines, where the affected routines include one or more of the instructions. For example, as shown in <FIG>, routine <NUM> and routine <NUM> each included one or more instructions within process <NUM> partition <NUM> and therefore those routines <NUM>, <NUM> were affected. In some embodiments, the PLC IDE may determine which routines are affected, and in other embodiments, the PLC may determine which routines are affected (i.e., impacted). The PLC IDE may determine which routines are affected in a compile-time analysis. For example, the IDE is aware of which routines utilize which instructions based on compiling the routines, and the IDE can identify which routines are affected based on the instructions that are within the update. The IDE may provide the affected routine information with the update such that the PLC can implement the update based on the routines identified by the IDE with the update. As another example, the PLC may determine which routines are affected based on a link-time analysis. The PLC knows which routines were bound to a given instruction, so if the instruction is included in the update, the PLC can identify the affected routines based on the previous bindings.

At step <NUM>, the PLC binds the updated instruction set library to an application programming interface of the programmable logic controller. For example, as described with respect to <FIG>, the PLC <NUM> binds the process <NUM> partition <NUM> to API <NUM>. In some embodiments, upon binding the updated instruction set library to the API, the PLC unbinds the old instruction set library that is being replaced from the API.

At step <NUM>, the PLC rebinds the affected routines to the updated instruction set library, where rebinding is performed between scans of the executable code. For example, the PLC <NUM> rebinds the instructions within process <NUM> partition <NUM> to routines <NUM>, <NUM>. In some embodiments, rebinding the instructions in the updated instruction set library to the affected routines unbinds the instruction in the old instruction set library from the routines. Upon completing the rebinding of step <NUM>, in some embodiments, the old instruction set library is deleted from the PLC memory by the PLC. Upon completion of the rebinding, the instructions used in the affected routines are bound via the API to the controller firmware such that the new instructions and routines will effectively control the machines controlled by the PLC.

In some embodiments, the updated instruction set library may include instructions from the old instruction set library. For example, as shown in <FIG>. <NUM> version of partition A <NUM> includes instructions <NUM>, <NUM>, <NUM>, and the <NUM>. <NUM> version of partition A <NUM> also includes instructions <NUM>, <NUM>, <NUM>. Additionally, in some embodiments, the updated instruction set library may include an updated instruction over the old instruction in the old instruction set library. For example, as shown in <FIG>, the <NUM>. <NUM> version of partition A <NUM> includes instruction <NUM>, and the <NUM>. <NUM> version of partition A <NUM> includes updated instruction <NUM> to replace old instruction <NUM>. To replace the instruction in the newer versions of the partition and the IDE, the new instruction is bound to the API rather than the old instruction. In older versions of the IDE, the old instruction is bound to the API rather than the new instruction if the new instruction is not supported in the older version of the IDE. Further, in some embodiments, new instructions may be added in the updated instruction set library. For example, as shown in <FIG>, the <NUM>. <NUM> version of partition B <NUM> includes instructions <NUM>, <NUM>, and the <NUM>. <NUM> version of partition B <NUM> includes a new instruction <NUM> in addition to instructions <NUM>, <NUM>.

<FIG> illustrates a flowchart <NUM> for supporting instructions in an instruction set library across versions of a PLC IDE is provided. The method of flowchart <NUM> may be performed by, for example PLC <NUM>, PLC <NUM>, PLC <NUM>, and/or PLC <NUM>. The PLC may access an instruction set library comprising a plurality of partitions each comprising a plurality of programming instructions at step <NUM>. For example, PLC <NUM> may access the instruction set library partitions stored in automation server <NUM>. The partitions may include all partitions used by PLCs <NUM> within automation environment <NUM>. Each partition includes multiple programming instructions. For example, as shown in <FIG>, each partition <NUM>, <NUM>, <NUM>, <NUM> include some subset of instructions <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>.

At step <NUM>, the PLC downloads a subset of the plurality of partitions based on executable code of the programmable logic controller. For example, the executable code of the programmable logic controller may include one or more programs. For example, as shown with respect to <FIG>, program A <NUM>, program B <NUM>, and program C <NUM> are all part of the executable code, which is run sequentially in scans. Accordingly, any instructions used within the routines included in any of the programs in programs <NUM> may be used to determine which instruction set partitions should be downloaded based on the instructions used in the routines.

At step <NUM>, the PLC binds the subset of the plurality of partitions to an application programming interface of the programmable logic controller. For example, the PLC may bind the instructions within each of the partitions to the API. For example, as shown in <FIG>, each instruction <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM>, <NUM> is bound to APIs <NUM>, <NUM> as appropriate. In some embodiments, the partitions themselves rather than individual instructions may be bound to the API.

At step <NUM>, the PLC binds a first routine comprising a first instruction to a first partition of the subset of the plurality of partitions comprising the first instruction. For example, as shown in <FIG>, routine <NUM> includes an instruction within process <NUM> partition <NUM>. Accordingly, the PLC binds routine <NUM>, which includes the instruction, to process <NUM> partition <NUM>. Later, as also shown in <FIG>, when the process partition is updated to version <NUM>, the PLC rebinds routine <NUM> to process <NUM> partition <NUM>. In some embodiments, the binding between the routines and the partitions occurs as the ladder logic routines are developed.

<FIG> illustrates a block diagram of an example of a PLC <NUM>. PLC <NUM> can be any of the described PLCs herein including, for example, PLCs <NUM>, PLCs <NUM>, <NUM>, and/or PLC <NUM>. PLC <NUM> is a ruggedized computing device designed to withstand the harsh environment of industrial automation environments. As described further below, PLC <NUM> includes extensive input/output to connect to sensors, actuators, and other control devices of the machines that are controlled by the PLC.

PLC <NUM> can include a processor <NUM> interfaced with other hardware via a bus <NUM>. A memory <NUM>, which can include any suitable tangible (and non-transitory) computer readable medium, such as RAM, ROM, EEPROM, or the like, can embody program components (e.g., instruction set libraries <NUM> and programs <NUM>, which includes the executable code) that configure operation of the PLC <NUM>. Memory <NUM> can store the program code <NUM>, program data <NUM>, or both. In some embodiments, PLC <NUM> includes additional storage (not shown). Although <FIG> depicts a PLC <NUM> with a processor <NUM>, the system can include any number of processors <NUM>. For example, dual core or distributed processors may be used.

The PLC <NUM> executes program code <NUM> that configures the processor <NUM> to perform one or more of the operations described herein. Examples of the program code <NUM> include, in various embodiments, the ladder logic programs, such as programs <NUM> that include routines used to control the machines via the machine I/O <NUM>. The program code <NUM> may be resident in the memory <NUM> or any suitable computer-readable medium and may be executed by the processor <NUM> or any other suitable processor.

The PLC <NUM> may generate or receive program data <NUM> by virtue of executing the program code <NUM>. For example, sensor data from the machines and other data described herein are examples of program data <NUM> that may be used by the PLC <NUM> during execution of the program code <NUM>.

The PLC <NUM> can include network components <NUM>. Network components <NUM> can represent one or more of any components that facilitate a network connection. In some examples, the network components <NUM> can facilitate a wireless connection and include wireless interfaces such as IEEE <NUM>, BLUETOOTH™, or radio interfaces for accessing cellular telephone networks (e.g., a transceiver/antenna for accessing CDMA, GSM, UMTS, or other mobile communications network). In other examples, the network components <NUM> can be wired and can include interfaces such as Ethernet, USB, or IEEE <NUM>. For example, PLCs <NUM> may communicate with each other or with automation server <NUM> using network components <NUM>.

PLC <NUM> includes machine I/O <NUM> that is coupled to the I/O interfaces of the machines that PLC <NUM> controls. Typically, there is extensive machine I/O <NUM> in PLC <NUM> so that many inputs and outputs can be read and transmitted between PLC <NUM> and the machines. The machine I/O communicates via the controller firmware <NUM> with the memory <NUM>, which uses the API <NUM> to allow routines to utilize the machine I/O <NUM> signals. The controller firmware <NUM> provides access to many hardware and embedded functions of the PLC <NUM> including operating system functions, the PLC scheduler, PLC timers, and the hardware abstraction layer. The API <NUM> within controller firmware <NUM> allows access to these hardware and embedded functions by providing an interface for the program code <NUM> to interact with the controller firmware <NUM>.

PLC <NUM> includes programming I/O <NUM> that provides an interface for a technician to review, modify, and create programs (e.g., programs <NUM> that may be ladder logic programs) to execute for controlling the machines via the machine I/O <NUM>. The programming I/O <NUM> may provide an interface for a technician to plug a device into the PLC <NUM> for visualizing the programs.

PLC <NUM> includes power supply <NUM>. Power supply <NUM> is an industrial power supply for use in industrial automation environments. In some embodiments, power supply <NUM> is redundant to avoid environment failure or downtime.

<FIG> illustrates a block diagram of an example of a computing device <NUM>. Computing device <NUM> can be any of the described computers herein including, for example, remote server <NUM> or automation server <NUM>. The computing device <NUM> can be or include, for example, an integrated computer, a laptop computer, desktop computer, tablet, server, or other electronic device.

The computing device <NUM> can include a processor <NUM> interfaced with other hardware via a bus <NUM>. A memory <NUM>, which can include any suitable tangible (and non-transitory) computer readable medium, such as RAM, ROM, EEPROM, or the like, can embody program components (e.g., program code <NUM>) that configure operation of the computing device <NUM>. Memory <NUM> can store the program code <NUM>, program data <NUM>, or both. In some examples, the computing device <NUM> can include input/output ("I/O") interface components <NUM> (e.g., for interfacing with a display, keyboard, mouse, and the like) and additional storage <NUM>.

The computing device <NUM> executes program code <NUM> that configures the processor <NUM> to perform one or more of the operations described herein. Examples of the program code <NUM> include, in various embodiments logic as described with respect to <FIG> in which the remote server <NUM> transmits the updates <NUM> to automation server <NUM> and the logic within automation server <NUM> to determine and send updates <NUM> to the appropriate PLCs <NUM>. The program code <NUM> may be resident in the memory <NUM> or any suitable computer-readable medium and may be executed by the processor <NUM> or any other suitable processor.

The computing device <NUM> may generate or receive program data <NUM> by virtue of executing the program code <NUM>. For example, updates <NUM> and other data described herein are examples of program data <NUM> that may be used by the computing device <NUM> during execution of the program code <NUM>.

The computing device <NUM> can include network components <NUM>. Network components <NUM> can represent one or more of any components that facilitate a network connection. In some examples, the network components <NUM> can facilitate a wireless connection and include wireless interfaces such as IEEE <NUM>, BLUETOOTH™, or radio interfaces for accessing cellular telephone networks (e.g., a transceiver/antenna for accessing CDMA, GSM, UMTS, or other mobile communications network). In other examples, the network components <NUM> can be wired and can include interfaces such as Ethernet, USB, or IEEE <NUM>. Although <FIG> depicts a computing device <NUM> with a processor <NUM>, the system can include any number of computing devices <NUM> and any number of processors <NUM>. For example, multiple computing devices <NUM> or multiple processor <NUM> can be distributed over a wired or wireless network (e.g., a Wide Area Network, Local Area Network, or the Internet). In some embodiments, multiple computing devices <NUM> are grouped to perform as a single computing device <NUM> by performing load sharing, load shedding, distributed computing, and the like. The multiple computing devices <NUM> or multiple processor <NUM> can perform any of the steps of the present disclosure individually or in coordination with one another.

While some examples provided herein are described in the context of an embedded analytic engine, it should be understood the condition monitoring systems and methods described herein are not limited to such embodiments and may apply to a variety of other condition monitoring environments and their associated systems. As will be appreciated by one skilled in the art, aspects of the present invention may be embodied as a system, method, computer program product, and other configurable systems.

Unless the context clearly requires otherwise, throughout the description and the claims, the words "comprise," "comprising," and the like are to be construed in an inclusive sense, as opposed to an exclusive or exhaustive sense; that is to say, in the sense of "including, but not limited to. " As used herein, the terms "connected," "coupled," or any variant thereof means any connection or coupling, either direct or indirect, between two or more elements; the coupling or connection between the elements can be physical, logical, or a combination thereof. Additionally, the words "herein," "above," "below," and words of similar import, when used in this application, refer to this application as a whole and not to any particular portions of this application. Where the context permits, words in the above Detailed Description using the singular or plural number may also include the plural or singular number respectively. The word "or," in reference to a list of two or more items, covers all of the following interpretations of the word: any of the items in the list, all of the items in the list, and any combination of the items in the list.

The phrases "in some embodiments," "according to some embodiments," "in the embodiments shown," "in other embodiments," and the like generally mean the particular feature, structure, or characteristic following the phrase is included in at least one implementation of the present technology, and may be included in more than one implementation. In addition, such phrases do not necessarily refer to the same embodiments or different embodiments.

The above Detailed Description of examples of the technology is not intended to be exhaustive or to limit the technology to the precise form disclosed above. While specific examples for the technology are described above for illustrative purposes, various equivalent modifications are possible within the scope of the technology, as those skilled in the relevant art will recognize. For example, while processes or blocks are presented in a given order, alternative implementations may perform routines having steps, or employ systems having blocks, in a different order, and some processes or blocks may be deleted, moved, added, subdivided, combined, and/or modified to provide alternative or subcombinations. Each of these processes or blocks may be implemented in a variety of different ways. Also, while processes or blocks are at times shown as being performed in series, these processes or blocks may instead be performed or implemented in parallel or may be performed at different times. Further any specific numbers noted herein are only examples: alternative implementations may employ differing values or ranges.

The teachings of the technology provided herein can be applied to other systems, not necessarily the system described above. The elements and acts of the various examples described above can be combined to provide further implementations of the technology. Some alternative implementations of the technology may include not only additional elements to those implementations noted above, but also may include fewer elements.

Claim 1:
A method for updating an instruction set library in a programmable logic controller, the method comprising:
receiving (<NUM>), by the programmable logic controller, an updated library comprising a plurality of programming instructions;
identifying (<NUM>), by the programmable logic controller, affected routines, wherein the affected routines comprise one or more of the plurality of programming instructions, and wherein the affected routines are executed as part of the executable code of the programmable logic controller to provide input signals to and receive output signals from a physical machine in an automation environment;
binding (<NUM>), by the programmable logic controller, the updated library to an application programming interface of the programmable logic controller; and
rebinding (<NUM>), by the programmable logic controller, the affected routines to the updated library, wherein the rebinding is performed between scans of the executable code of the programmable logic controller,
characterized in that:
the updated library is an updated instruction set library partition and comprises at least an original programming instruction (<NUM>) and an updated programming instruction (<NUM>) of the original programming instruction (<NUM>),
the updated instruction set library partition is selected from a plurality of instruction set library partitions based on instructions included in the executable code utilized at the programmable logic controller,
each instruction set library partition is created for specific industries or machines, and binding the updated instruction set library partition to the application programming interface binds the updated instruction set library partition to a firmware (<NUM>) of the programmable logic controller, wherein, based on a version of an IDE used by the firmware (<NUM>) of the programmable logic controller, the updated programming instruction (<NUM>) or the original programming instruction (<NUM>) is bound to the firmware.