Patent Description:
Industrial automation systems may be used to provide automated control of one or more actuators. Specifically, a controller may receive power from a power source and output a conditioned power signal to an actuator to control movement of the actuator. Typically, controllers for industrial automation systems are available for sale (either individually, as a component within an industrial automation system, or as a subcomponent within an industrial automation component) from manufacturers or sellers with a limited number of combinations of features and/or capabilities. As such, a customer may be unable to find a controller having a specific combination of features he or she seeks. The customer may end up paying a higher price to purchase a controller having one or more extra features and/or capabilities that he or she does not plan on utilizing. Similarly, the customer may end up purchasing a controller that lacks one or more of the particular features he or she sought and adapting an application for operating the controller to accommodate the purchased controller. Further, once a customer purchases a controller, the customer may be locked into the features of the controller at the time of purchase, without the ability to add or remove features. Accordingly, it may be desirable to give customers the ability to customize the features of the controller before purchase and add or remove features after the controller has been purchased.

<CIT> discloses a device that obtains proof of its authority to use a first set of selectively activated features (first proof). An authorization server signs the first proof with its private key. The device sends a request to use a network service to a network node. The device sends the first proof to the network node. The network node validates the first proof using a public key of the authorization server. The network node grants the request to use the network service. The device sends a request for proof of authority for the network node to provide the network service (second proof). The device obtains the second proof, signed by another authorization server, and validates the second proof before using the network service. The first proof and the second proof each include a list of selectively activated features, where the selectively activated features are needed to use or provide the network service.

<CIT> relates to a licensing system that provides enhanced flexibility for licensing applications in a network. The licensing system includes a license certificate database which stores all license information. The license certificate database is accessed by providing a request to a license service provider associated with a server. The license service provider generates an executable entity based on the request parameters, which searches the database and, if the appropriate units are available, assembles a license. The license and the application are then transmitted to the requesting client. All aspects of the transaction are also stored in a database organized according to a transaction's relation to a particular license.

It is the object of the present invention to provide an improved method and system for customizing the features of a controller.

In one embodiment, a tangible, non-transitory, computer-readable medium comprising program instructions that, when executed by a processor, cause the processor to access a project code that defines one or more operations of a controller, analyze the project code to identify one or more capabilities the controller that are utilized by the one or more operations, generate a file indicative of the one or more capabilities of the controller, transmit the file to a server that generates a certificate for authorizing the controller to execute the project code, receive the certificate from the server that identifies the file and an authorization for the controller to execute the project code to perform the one or more operations, and transmit the project code, the file, and the certificate to the controller for execution.

In another embodiment, a method includes receiving, one or more inputs defining a project, analyzing the project to identify one or more capabilities of a controller that are utilized by the project, generating a file comprising the one or more capabilities of the controller that are utilized by the project, transmitting the file to a server, receiving a certificate from the server, wherein the certificate identifies the manifest and an authorization for the controller to execute the project associated with the file, transmitting the project, the file, and the certificate to the controller for execution.

In yet another embodiment, a system includes a computing device and a controller disposed behind a firewall. The computing device is configured to analyze a project code to identify one or more capabilities of a controller that are utilized by the project code, generate a manifest comprising the one or more capabilities of the controller that are utilized by the project, transmit the manifest to a server, wherein the server is configured to generate a certificate for authorizing the controller to execute the project code, receive a certificate from the server identifying the manifest and an authorization for the controller to execute the project code to perform the one or more operations, and transmit the project code, the manifest, and the certificate to the controller. The controller is configured to receive, from the computing device, the project code, the manifest, and the certificate, decrypting the certificate, verify that the certificate matches the manifest and the project code, and execute the project code.

These and other features, aspects, and advantages of the present embodiments will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:.

An industrial automation system may utilize a controller, to receive power from a power source and output a conditioned power signal to an actuator to control movement of the actuator. The controller may be a stand-alone control unit that controls multiple industrial automation components (e.g., a motor control center or MCC), a controller that controls the operation of a single automation component, or a subcomponent within a larger industrial automation system. Controllers are typically available from manufacturers or sellers having a limited number of combinations of features. Accordingly, a customer looking for a controller with a particular combination of features that does not match a model available from a manufacturer or seller may settle for a model of controller that is closest to the particular combination of features they seek. As such, the customer may pay a higher price to purchase a controller having all of the particular features they seek, but also one or more features and/or capabilities that they do not plan on utilizing. Alternatively, the customer may purchase a controller that lacks one or more of the particular features for which they were looking and adapting other aspects of the industrial automation system to accommodate the purchased controller. Further, once a controller has been purchased, the customer may be limited to the features of the controller at the time of purchase without the ability to add or remove features.

The disclosed techniques enable a customer to customize the features/capabilities of a controller to his or her specific industrial automation project (e.g., a file or portion of programmatic code that define operations and/or provide operations guidelines for the controller in controlling an industrial automation system or component during performance of one or more tasks or processes) and then add or remove (e.g., meter) features/capabilities of the controller on a project-by-project basis, for a specified amount of time, a specified number of project cycles, or as otherwise needed. Specifically, a computing system operated by the customer analyzes an industrial automation project to identify which controller features/capabilities are utilized by the industrial automation project and generates a manifest for the industrial automation project identifying the controller features/capabilities utilized by the industrial automation project. The manifest may identify, for example, a number of axes of motion that are used, a number of Ethernet nodes that are used, an identity of languages used, what, if any, premium instructions are being used (e.g., PID control loop, other control loop, features developed by the seller, etc.), a number of connections that are used, whether machine learning and/or artificial intelligence is used, whether analytics are being used, and the like. The manifest is sent to a remote/cloud server associated with a manufacturer/seller of the controller or other service provider. The remote/cloud server determines which controller features/capabilities utilized by the industrial automation project and identified in the manifest are not available to the customer. For example, the remote/cloud server may review past purchases by the customer and/or existing licensing agreements to identify which features/capabilities are not free and have not been purchased. The customer may then purchase access to the unavailable features/capabilities. Once the customer has access to the controller features/capabilities utilized by the industrial automation project and identified in the manifest, the remote/cloud server generates an encrypted certificate that is sent back to the computing device. The computing device sends the industrial automation project, the manifest, and the certificate to the controller. The controller decrypts the certificate, validates the certificate (e.g., confirms that the industrial automation project, the manifest, and the certificate all match one another). Upon validation of the certificate, the controller runs or executes the industrial automation project. In some embodiments, the controller may collect data during execution of the industrial automation project that is transmitted back to the computing device following the execution of the industrial automation project.

By way of introduction, <FIG> is a schematic view of an industrial automation system <NUM>. As shown, the industrial automation system <NUM> includes a controller <NUM> and an actuator <NUM> (e.g., a motor). The industrial automation system <NUM> may also include, or be coupled to, a power source <NUM>. The power source <NUM> may include a generator or an external power grid. The controller <NUM> may be a stand-alone control unit that controls multiple industrial automation components (e.g., a plurality of motors <NUM>), part of a motor control center (MCC), a controller <NUM> that controls the operation of a single automation component (e.g., motor <NUM>), or a subcomponent within a larger industrial automation system <NUM>. In the instant embodiment, the controller <NUM> includes a user interface <NUM>, such as a human machine interface (HMI), and a control system <NUM>, which may include a memory <NUM> and a processor <NUM>. The controller <NUM> may include a cabinet or some other enclosure for housing various components of the industrial automation system <NUM>, such as a motor starter, a disconnect switch, etc..

The control system <NUM> may be programmed (e.g., via computer readable code or instructions stored on the memory <NUM> and configured to be executed by the processor <NUM>) to provide signals for driving the motor <NUM>. In certain embodiments, the control system <NUM> may be programmed according to a specific configuration desired for a particular application. For example, the control system <NUM> may be programmed to respond to external inputs, such as reference signals, alarms, command/status signals, etc. The external inputs may originate from one or more relays or other electronic devices. The programming of the control system <NUM> may be accomplished through software configuration or firmware code that may be loaded onto the internal memory <NUM> of the control system <NUM> (e.g., via a computing device <NUM>) or programmed via the user interface <NUM> of the controller <NUM>. The firmware of the control system <NUM> may respond to a defined set of operating parameters. The settings of the various operating parameters determine the operating characteristics of the controller <NUM>. For example, various operating parameters may determine the speed or torque of the motor <NUM> or may determine how the controller <NUM> responds to the various external inputs. As such, the operating parameters may be used to map control variables within the controller <NUM> or to control other devices communicatively coupled to the controller <NUM>. These variables may include, for example, speed presets, feedback types and values, computational gains and variables, algorithm adjustments, status and feedback variables, programmable logic controller (PLC) like control programming, and the like.

In some embodiments, the controller <NUM> may be communicatively coupled to one or more sensors <NUM> for detecting operating temperatures, voltages, currents, pressures, flow rates, etc. within the industrial automation system <NUM>. With feedback data from the sensors, the control system <NUM> may keep detailed track of the various conditions under which the industrial automation system <NUM> may be operating. For example, the feedback data may include conditions such as actual motor speed, voltage, frequency, power quality, alarm conditions, etc. In some embodiments, the feedback data may be communicated back to the computing device <NUM> for additional analysis.

The computing device <NUM> may be communicatively coupled to the controller <NUM> via a wired or wireless connection. The computing device <NUM> may receive inputs from a user defining an industrial automation project using a native application running on the computing device <NUM>, or using website accessible via a browser. The user may define the industrial automation project by writing code, interacting with a visual programming interface, inputting or selecting values via a graphical user interface, providing some other inputs, or some combination thereof. The computing device <NUM> may send a project to the controller <NUM> for execution. Execution of the industrial automation project causes the controller <NUM> to control the industrial automation system through performance of one or more tasks and/or processes. In some applications, the controller <NUM> may be disposed behind a firewall, such that the controller does not have internet access and is not in communication with any devices outside the firewall, other than the computing device. As previously discussed, the controller may collect feedback data during execution of the project, which may be provided back to the computing device <NUM> for analysis. Feedback data may include, for example, one or more execution times, one or more alerts, one or more error messages, one or more alarm conditions, one or more temperatures, one or more pressures, one or more flow rates, one or more motor speeds, one or more voltages, one or more frequencies, and so forth. The project may be updated via the computing device <NUM> based on the analysis of the feedback data.

The computing device <NUM> may be in communication with a cloud server <NUM> or remote server via the internet, or some other network. In the instant embodiment, the cloud server <NUM> is operated by the manufacturer of the controller <NUM>. However, in other embodiments, the cloud server may be operated by a seller of the controller, a service provider, etc. The cloud server <NUM> may be used to help customers create and/or modify projects, to help troubleshoot any problems that may arise with the controller <NUM>, or to provide other services (e.g., project analysis, enabling, restricting capabilities of the controller <NUM>, data analysis, controller firmware updates, etc.). The remote/cloud server <NUM> may be one or more servers operated by the manufacturer, seller, or service provider of the controller <NUM>. The remote/cloud server <NUM> may be disposed at a facility owned and/or operated by the manufacturer, seller, or service provider of the controller <NUM>. In other embodiments, the remote/cloud server <NUM> may be disposed in a datacenter in which the manufacturer, seller, or service provider of the controller <NUM> owns or rents server space. In further embodiments, the remote/cloud server <NUM> may include multiple servers operating in one or more data center to provide a cloud computing environment.

<FIG> illustrates a block diagram of example components of a computing device <NUM> that could be used as the computing device <NUM> and/or the cloud/remote server <NUM> shown in <FIG>. As used herein, a computing device <NUM> may be implemented as one or more computing systems including laptop, notebook, desktop, tablet, HMI, or workstation computers, as well as server type devices or portable, communication type devices, such a cellular telephones, and/or other suitable computing devices.

As illustrated, the computing device <NUM> may include various hardware components, such as one or more processors <NUM>, one or more busses <NUM>, memory <NUM>, input structures <NUM>, a power source <NUM>, a network interface <NUM>, a user interface <NUM>, and/or other computer components useful in performing the functions described herein.

The one or more processors <NUM> are, in certain implementations, microprocessors configured to execute instructions stored in the memory <NUM> or other accessible locations. Alternatively, the one or more processors <NUM> may be implemented as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), and/or other devices designed to perform functions discussed herein in a dedicated manner. As will be appreciated, multiple processors <NUM> or processing components may be used to perform functions discussed herein in a distributed or parallel manner.

The memory <NUM> may encompass any tangible, non-transitory medium for storing data or executable routines, including volatile memory, non-volatile memory, or any combination thereof. Although shown for convenience as a single block in <FIG>, the memory <NUM> may encompass various discrete media in the same or different physical locations. The one or more processors <NUM> may access data in the memory <NUM> via one or more busses <NUM>.

The input structures <NUM> are used to allow a user to input data and/or commands to the device <NUM> and may include mouses, touchpads, touchscreens, keyboards, controllers, and so forth. The power source <NUM> can be any suitable source for providing power to the various components of the computing device <NUM>, including line and battery power. In the depicted example, the device <NUM> includes a network interface <NUM>. Such a network interface <NUM> may allow communication with other devices on a network using one or more communication protocols. In the depicted example, the device <NUM> includes a user interface <NUM>, such as a display configured to display images or data provided by the one or more processors <NUM>. The user interface <NUM> may include, for example, a monitor, a display, and so forth. As will be appreciated, in a real-world context a processor-based system, such as the computing device <NUM> of <FIG>, may be employed to implement some or all of the present approach, such as performing the functions of the computing device <NUM> and/or the cloud/remote server <NUM> shown in <FIG>.

Returning to <FIG>, typically, a seller of controllers <NUM> may only offer a limited number of models of controllers <NUM> having pre-determined combinations of features/capabilities. For example, if a customer wishes to purchase a controller <NUM> having a specific combination of features and/or capabilities, but the seller does not sell a controller <NUM> having the specific combination of features and/or capabilities, the customer may end up paying a higher price for a controller <NUM> having all of the features and/or capabilities sought, as well as one or more additional features and/or capabilities that the customer does not plan on using. Alternatively, the customer may end up purchasing a controller <NUM> that lacks one or more particular features and/or capabilities that the customer sought, and determining how to make the purchased controller <NUM> work in their application. Additionally, when a customer purchases a controller <NUM>, typically, particular features and/or capabilities of the controller <NUM> cannot be turned on or off. Accordingly, a customer may end up paying to use particular features and/or capabilities of the controller <NUM> for the entire life of the controller <NUM>, even though one or more of the particular features and/or capabilities of the controller <NUM> may not be used regularly, or even used at all during the life of the controller <NUM>. Further, after the controller <NUM> has been purchased, the customer may not have the option to add particular features and/or capabilities to the controller <NUM>. Accordingly, the disclosed techniques include using certificates generated by the cloud server <NUM> and verified by the controller <NUM> to enable customers to customize features and/or capabilities of the controller <NUM>, and to add and/or remove features and/or capabilities to the controller <NUM>, such that the customer only pays for features and/or capabilities of the controller <NUM> that are being used. Accordingly, customizing controller <NUM> features/capabilities, adding controller <NUM> features/capabilities, and/or removing controller <NUM> features/capabilities may is referred to herein as metering controller functionality. Particular controller <NUM> features/capabilities may be available to particular projects, particular customer, for a set period of time (a specific duration, before some date/time, after some date/time, and so forth), for a set number of cycles, and the like.

<FIG> is a schematic of a system for metering controller <NUM> functionality. As previously described, the computing device <NUM> is used to generate a project <NUM> using a native software application running on the computing device <NUM> or using a webpage accessed via a browser. The project <NUM> may be created and/or edited by writing code, interacting with a visual programming interface, inputting or selecting values via a graphical user interface, providing some other inputs, or some combination thereof. The project <NUM> is a portion of code defining how the controller <NUM> and one or more industrial automation components within an industrial automation system <NUM> are to operate during performance of one or more industrial automation tasks. After the project <NUM> has been finalized, the computing device <NUM> performs an analysis of the project <NUM> to determine which features and/or capabilities of the controller <NUM> are utilized by the project <NUM>. This may include, for example, the number of axes of motion used, number of Ethernet nodes used, languages used, what, if any, premium instructions are being used (e.g., PID control loop, other control loop, features developed by the seller, etc.), number of connections used, whether machine learning and/or artificial intelligence is used, whether analytics are being used, central processing unit (CPU) performance, amount of memory available, safety level (e.g., safety integrity level <NUM>, safety integrity level <NUM>, and so forth), redundancy capability, and the like. The computing device <NUM> generates a manifest <NUM> that indicates which features and/or capabilities are being utilized and transmits the manifest <NUM> to the cloud server <NUM>. The manifest <NUM> may include, for example, a data file listing the features and/or capabilities utilized by the project <NUM>, a data file having fields that correspond a set list of features and/or capabilities and indicating in each field whether the respective feature/capability is used, and for certain fields, how much of that feature/capability is used, what level of the feature/capability is used, and/or how many times that feature/capability is used. In some embodiments, the manifest <NUM> may include a unique identity of a controller <NUM> on which the project <NUM> is authorized to run. Accordingly, a customer may choose to purchase a certificate <NUM> to run on a specific controller <NUM> or controllers, or to run on a limited number of controllers <NUM>. It should be understood, however, that other formats of the manifest are also envisaged. In the illustrated embodiment, the project <NUM> itself is not sent to the cloud server <NUM>. Some customers may wish to keep various aspects of the project <NUM> private and thus, may not wish to send the project <NUM> to the cloud server <NUM>. Accordingly, in the instant embodiment, the manifest <NUM> may merely indicate which features and/or capabilities are being used by the project <NUM> and not the specific ways in which those features and/or capabilities are being used by the project <NUM>. However, embodiments are envisaged in which the project <NUM> may be sent to the cloud server <NUM> with the manifest <NUM> (e.g., for project analysis, troubleshooting, help developing the project, etc.). Further, embodiments are envisaged in which the project <NUM> is sent to the cloud server <NUM> and the manifest <NUM> is generated by the cloud server <NUM>.

The cloud server <NUM> cross checks past purchases, licensing agreements, etc. and determines what, if any, features and/or capabilities used by the project <NUM> are not free and have not been paid for. If there are features and/or capabilities that are not free and have not been paid for, the cloud server <NUM> generates a statement identifying the features and/or capabilities used by the project <NUM> that are not free and have not been paid for, the options for gaining access to those features and/or capabilities, and the costs associated with each option. The customer responds by selecting one or more of the options and providing payment, or promising to provide payment, for the selected option(s). In response to receiving the selection of the one or more of the options and the payment (e.g., lump sum, monthly payment, quarterly payment, annual payment, etc.), or in response to determining that all features and/or capabilities used by the project <NUM> are covered by past purchases and/or existing license agreements, the cloud server <NUM> generates and transmits a certificate <NUM> for the manifest <NUM> to the computing device <NUM>. The certificate may be valid for a particular project, a particular duration of time, until an expiration date, after a start date, for a certain number of cycles, and so forth.

In the instant embodiment, the certificate <NUM> is an encrypted X. <NUM> certificate that includes a private key corresponding to a public key stored on the controller. Generally, a certificate <NUM> may include a public key or a private key and an identity (e.g., a host name, an entity, or an individual). The certificate <NUM> is signed by a trusted certificate authority. The certificate <NUM> may include, for example, a version number, a serial number, a signature algorithm ID, an issuer name, a validity period, a start date, and end date, subject name, subject public key info, subject public key, subject private key info, subject private key, issuer unique identifier, subject unique identifier, extensions, certificate signature algorithm, certificate signature, or some combination thereof. After the certificate <NUM> is signed, the public key may be used to validate documents signed using the corresponding private key. The certificate <NUM> is rejected if an unrecognized extension is encountered. In some embodiments, the signing authority may use a certificate revocation list to communicate that a certificate has been deemed invalid by the signing authority. Further, in embodiments having multiple certificate authorities, a certification path validation algorithm may be used to allow certificates <NUM> to be signed by intermediate certificates or signing authorities. However, it should be understood that the certificate <NUM> may utilize other known encryption and/or security standards and techniques for securing the certificate <NUM>.

In some embodiments, the controller <NUM> may be purchased from a first entity, such as an original equipment manufacturer (OEM), by a second entity. The second entity may incorporate the controller <NUM> into a product (e.g., a turn-key industrial automation system <NUM> for a particular application), and then sell the product to a third entity (e.g., an end customer). In such an embodiment, there may be multiple certificates <NUM>. For example, the first entity may sell the controller <NUM> to the second entity having a first set of capabilities. The second entity then packages the controller <NUM> into the product such that only a subset of the first set of capabilities are available for use and sells the product to the third entity. Thus, a certificate <NUM> may be created for each transaction along the chain of entities that specifies the capabilities of the controller <NUM> as governed by the terms of the transaction. For example, a first certificate <NUM> may identify the first set of capabilities as being available for use by the second entity based on the terms of the transaction between the first and second entities. A second certificate <NUM> may identify the subset of the first set of capabilities as being available for use by the third entity based on the terms of the transaction between the second and third entities. It should be understood that this certificate chain may propagate through additional levels of transactions between entities. Accordingly, embodiments are envisaged in which there may be three, four, five, or more certificates <NUM>. In such an embodiment, the controller <NUM> may verify multiple certificates <NUM> before executing the project <NUM>. For example, the controller <NUM> may verify that the issuer of each certificate <NUM>, except for the last issuer, matches the subject of the next certificate <NUM> in the chain. Each certificate <NUM>, except for the last certificate <NUM> in the chain, is signed by a key corresponding to the next certificate <NUM> in the chain, such that the signature of one certificate <NUM> can be verified using the key contained in the subsequent certificate <NUM>. The last certificate <NUM> in the chain is called the trust anchor because the certificate <NUM> was delivered from a trustworthy source or through some trustworthy procedure.

In the embodiment described above with two certificates <NUM> and three entities, the third entity, the end customer, may decide that they would like to use a controller <NUM> functionality beyond the first subset of capabilities of the first set of capabilities. Accordingly, the third entity may pay the second entity for access to the additional capabilities if those capabilities are within the first set of capabilities. If the additional capabilities are outside of the first set of capabilities, then the second and/or third entity may pay the first entity for access for the additional capabilities, resulting in new certificates.

The computing device <NUM> transmits the project <NUM>, the manifest <NUM>, and the certificate <NUM> to the controller <NUM>. The controller <NUM> uses a copy of the corresponding public key stored in its memory to decrypt the certificate <NUM> and confirm that the certificate <NUM> matches the manifest <NUM>. In some embodiments, the controller <NUM> may be preprogrammed with the public key stored in its memory by the manufacturer, the seller, or some other entity. In other embodiments, the public key may have been received via a firmware update or some other network communication.

In addition to providing or updating public keys, firmware updates may be used to "retrofit" legacy controllers <NUM> in the field to add functionality and increase capabilities. For example, a firmware update may provide an installed controller <NUM> with new analytics capabilities, new algorithms for use, new control loops to implement, and the like.

If the certificate <NUM> matches the manifest <NUM>, the controller <NUM> runs or executes the project. The controller <NUM> does not evaluate which features have been paid for, which features are included with past purchases, or which features have been licensed. As long as a valid certificate <NUM> has been provided that matches the manifest <NUM>, the controller <NUM> runs the project <NUM>.

<FIG> is a flow chart of a process <NUM> for metering controller <NUM> functionality. As previously described, the project is created or edited on the computing device <NUM>. The computing device <NUM> analyzes the project to generate a manifest identifying various controller features and/or capabilities used by the project. At <NUM>, the manifest is transmitted to the cloud server <NUM>. The cloud server <NUM> analyzes the manifest and compares the controller features and/or capabilities identified by the manifest to past purchases, licensing agreements, etc. and determines which, if any, controller features and/or capabilities identified by the manifest are not free and have not been purchased. If there are features and/or capabilities that are purchased, the cloud server <NUM> generates a statement identifying the features and/or capabilities used by the project <NUM> that have not been purchased, the options for gaining access to those features and/or capabilities, and the costs associated with each option. At <NUM>, the statement is transmitted to the computing device <NUM>. At <NUM>, the computing device <NUM> sends an identification of one or more options and/or payment for the features and/or capabilities that have not been purchased. The cloud server <NUM> generates a certificate (e.g., an encrypted X. <NUM> certificate) for the manifest, which includes a private key and transmits the certificate to the computing device at <NUM>. At <NUM>, the computing device <NUM> transmits the project, the manifest, and the certificate to the controller <NUM>. The controller <NUM> uses a copy of the corresponding public key stored in its memory to decrypt the certificate <NUM> and confirm that the certificate matches the manifest <NUM>. If the certificate <NUM> matches the manifest <NUM>, the controller <NUM> runs the project. In some embodiments, at <NUM>, the controller may transmit data collected during the running of the project to the computing device <NUM>. The data may include, for example, one or more execution times, one or more alerts, one or more error messages, one or more alarm conditions, one or more temperatures, one or more pressures, one or more flow rates, one or more motor speeds, one or more voltages, one or more frequencies, and so forth.

<FIG> is a flow chart of a process <NUM> for metering a controller functionality from the perspective of the computing device <NUM>. At block <NUM>, inputs are received that define an industrial automation project. The inputs may include programmatic code, inputs to a visual programming environment, and/or inputs to a graphical user interface (GUI) setting thresholds, displacements, speeds, temperatures, voltages, currents, or controlling other aspects of the industrial automation system to perform one or more industrial automation tasks or processes.

At block <NUM>, the project is analyzed and a manifest is generated. The analysis involves determining controller features and/or capabilities that are utilized by the project. For example, the analysis may determine a number of axes of motion that are used, a number of Ethernet nodes that are used, an identity of languages used, what, if any, premium instructions are being used (e.g., PID control loop, other control loop, features developed by the seller, etc.), a number of connections that are used, whether machine learning and/or artificial intelligence is used, whether analytics are being used, and the like. The results of the analysis are included in the manifest. That is, the manifest identifies the controller features and/or capabilities that are utilized by the project. The analysis and/or generation of the manifest may be performed during, or in response to, executing one or more scripts. For example, the script may cause the processor to parse the program code that defines the project and apply one or more rules, or otherwise look for features of the code that indicate that specific controller features and/or capabilities are being used by the project. Because the manifest may not include specific information about exactly how the project uses the enumerated features and/or capabilities, a customer that may be reluctant to hesitant to transmit sensitive data (e.g., trade secrets, specific recipes, details about manufacturing processes, etc.) to a third party may feel comfortable transmitting the manifest to an external destination. At block <NUM>, the manifest is transmitted to the remote/cloud server. In some embodiments, the manifest may be encrypted (e.g., using a public/private key scheme, or some other encryption techniques). In other embodiments, the manifest may be transmitted in an unencrypted form.

As previously discussed, in some embodiments, the analysis may be performed by the cloud server <NUM> rather than by the computing device <NUM>. In such embodiments, the customer may transmit the project to the cloud server <NUM> to perform the analysis and generate a manifest, which is returned to the computing device <NUM>, either with or separate from the certificate.

Upon receipt of the manifest, the cloud server <NUM> may cross-check past purchases and existing license agreements with the customer and identifies which controller features and/or capabilities in the manifest are not free and have not already been paid for. That is, the cloud server <NUM> generates and transmits for receipt by the computing device <NUM> (block <NUM>), a statement of controller features and/or capabilities in the manifest that need to be paid for. In some embodiments, the statement may include options for acquiring the controller features and/or capabilities (e.g., lump sum, regular payment, package with other features/capabilities, etc.). At block <NUM>, an order selecting one of the options from the statement and/or payment for the features and/or capabilities is transmitted to the remote server. In some embodiments, a promise to pay may be sent in lieu of payment. Further, in some embodiments, payment may be through a third-party payment service. Once all controller features and/or capabilities in the manifest that need to be paid for have been paid for, the cloud server <NUM> generates and sends a certificate for receipt by the computing device (block <NUM>). In the instant embodiment, the certificate is an encrypted X. <NUM> certificate that includes a private key that corresponds to a public key stored on the controller <NUM>. However, it should be understood that the certificate may utilize other known encryption and/or security standards and techniques for securing the certificate <NUM>. As previously discussed, in some embodiments, the cloud server <NUM> may send multiple certificates.

At block <NUM>, the computing device <NUM> transmits the project, the manifest, and the certificate to the controller <NUM>. The controller <NUM> verifies the certificate and the manifest and then runs the project. In some embodiments, the controller <NUM> may transmit data collected from running the project for receipt by the computing device (block <NUM>).

<FIG> is a flow chart of a process <NUM> for metering controller functionality from the perspective of the cloud/remote server <NUM>. At block <NUM> the manifest is received from the customer. As previously discussed, in some embodiments, the cloud server <NUM> may receive the project from the customer and analyze the project to generate the manifest. The manifest identifies the controller features and/or capabilities are utilized by the project. For example, the manifest may identify how many axes of motion are used, how many Ethernet nodes are used, which languages used, what, if any, premium instructions are being used (e.g., PID control loop, other control loop, features developed by the seller, etc.), how many connections are used, whether machine learning and/or artificial intelligence is used, whether analytics are being used, etc..

At block <NUM>, the features being used that are not purchased are identified. For example, previous purchases and existing licenses may be reviewed to identify the controller features and/or capabilities from the manifest that are not purchased. Options for accessing the controller features and/or capabilities are then identified and a cost associated with each option is calculated. At block <NUM>, a statement is generated that identifies the various options for accessing the controller features and/or capabilities to which the customer does not already have access, as well as a cost associated with each option. The statement may identify, for example, individual controller features and/or capabilities, packages of controller features and/or capabilities, or available services (e.g., analytics) that include access to controller features and/or capabilities. Further, the statement may include options for a lump sum payment for use of a particular controller feature and/or capability by the customer for the instant project or any project in perpetuity, a monthly payment, a quarterly payment, an annual payment, and so forth.

At block <NUM>, an order and/or payment is received from the customer. The order specifies one or more of the options set forth in the statement, as well as payment for the one or more selected options. In some embodiments, a promise to pay may be sent in lieu of payment. Further, in some embodiments, payment may be through a third-party payment service.

At block <NUM>, a certificate is generated for the manifest. The certificate may be an encrypted certificate (e.g., a X. <NUM> certificate) that includes a private key corresponding to a public key stored on the controller. At block <NUM>, the certificate is transmitted to the computing device of the customer.

<FIG> is a flow chart of a process <NUM> for metering controller functionality from the perspective of the controller <NUM>. At block <NUM> the project, manifest, and certificate (e.g., encrypted X. <NUM> certificate) are received from the computing device. At block <NUM>, the certificate is decrypted. As previously described, the certificate includes a private key and the public key is stored in memory in the controller <NUM>. The controller <NUM> may be preprogrammed with the public key by a manufacturer or seller. Alternatively, the public key may have been obtained via a firmware update to the controller <NUM> or some other communication method.

At block <NUM>, the certificate is verified. That is, confirmation is made that the project matches the manifest and the manifest matches the certificate. The certificate, which was generated after the project was finalized and the manifest was generated, identifies the manifest. This may include a manifest number, some other alphanumeric character string associated with the manifest, or some other data that corresponds to the manifest. In some embodiments, the certificate may also identify the project. The certificate being encrypted and only enabling a project associated with a specific manifest to run prevents a customer from using a falsified certificate to run a project. As previously discussed, in some embodiments, there may be multiple certificates to verify.

At block <NUM>, the project is executed. In some embodiments, data may be collected while the project is being executed (block <NUM>). The data may include, for example, one or more execution times, one or more alerts, one or more error messages, one or more alarm conditions, one or more temperatures, one or more pressures, one or more flow rates, one or more motor speeds, one or more voltages, one or more frequencies, and so forth. In such an embodiment, the data may be stored within the controller <NUM> and data analysis performed within the controller <NUM>. In other embodiments, some or all of the data may be transmitted back to the computing device (block <NUM>). Analysis may be performed on the computing device <NUM>, or transmitted to the cloud server <NUM>, or another third party, for analysis.

It should be understood that though <FIG> are from the perspective of the computing device, the remote server, and the controller, respectively, embodiments are envisaged in which actions shown and described as performed by one component in <FIG> may be performed by other components in the system. For example, actions described as performed by the computing device may be performed by the remote server or the controller, actions described as performed by the remote server may be performed by the computing device or the controller, and actions described as performed by the controller may be performed by the computing device or the remote server. Further, though the industrial automation component that is described as validating the certificate, the manifest, and the project, and then executing the project is the controller, it should be understood that a different industrial automation components, any other industrial equipment, or a collection of components operated by a control system may perform these tasks.

The disclosed techniques enable a customer to customize the features/capabilities of an industrial automation controller to his or her specific project and then add or remove features/capabilities of the controller on a project-by-project basis. Specifically, a computing system operated by the customer analyzes an industrial automation project to identify which controller features/capabilities are utilized by the project and generates a manifest for the project identifying the controller features/capabilities utilized by the project. The manifest is sent to a remote/cloud server associated with the manufacturer/seller of the controller or other service provider. The remote/cloud server determines which controller features/capabilities utilized by the project and identified in the manifest are not accessible to the customer. For example, the remote/cloud server may review past purchases by the customer and/or existing licensing agreements to identify which features/capabilities are not free and have not yet been paid for. The customer may then purchase access to the features/capabilities. Once the customer has access to the controller features/capabilities utilized by the project and identified in the manifest, the remote/cloud server generates an encrypted certificate that is sent back to the computing device. The computing device send the project, the manifest, and the certificate to the controller. The controller decrypts the certificate, validates the certificate (e.g., confirms that the project, the manifest, and the certificate all match). Upon validation of the certificate, the controller runs the project. In some embodiments, the controller may collect data during execution of the project that is transmitted back to the computing device following execution of the project.

Claim 1:
A tangible, non-transitory, computer-readable medium comprising program instructions that, when executed by a processor, cause the processor to perform operations comprising:
accessing a project code (<NUM>) stored in memory (<NUM>), wherein the project code is configured to define one or more operations of an industrial automation controller (<NUM>);
analyzing the project code to identify one or more capabilities of the industrial automation controller that are utilized by the one or more operations;
generating a file (<NUM>) comprising the one or more capabilities of the industrial automation controller;
transmitting the file to a server;
receiving a certificate (<NUM>) from the server, wherein the certificate identifies the file and an authorization for the industrial automation controller to execute the project code to perform the one or more operations; and
transmitting the project code, the file, and the certificate to the industrial automation controller for execution.