Patent Description:
Generally, a control system may facilitate performance of an industrial automation process by controlling operation of one or more automation devices. For example, to facilitate performing an industrial automation process, the control system may determine a control action and instruct an automation device (e.g., a rod-pump) to perform the control action. Additionally, the control system may monitor performance of the process to determine whether the process is operating as desired. When not operating as desired, the control system may also perform diagnostic operations on the process to determine potential causes of the undesired operation.

Model-based optimization and control has received increasingly more attention both in academia and in industry over the past few decades. This is due at least in part to their success in the process industry. However, model-less strategies, such as proportional-integral-derivative (PID) controllers, are still very pervasive in industrial applications. Other model-less control strategies, such as expert systems, fuzzy logic controllers, and so forth, are also used in some industrial applications. The performance of most model-less controllers can be improved by proper adjustments to certain coefficients (or other equivalent parametrizations) of the control algorithm implemented by these model-less controllers. As such, improved systems and methods for dynamically tuning model-less control strategies may enable industrial automation systems to operate more efficiently.

<NPL>, relates to a Bayesian approach to closed-loop system identification. The issue of identifying a closed-loop system from short and/or non-informative data records is addressed. A Bayesian approach is developed within this framework. It is shown that accurate estimates and realistic confidence intervals can be obtained by taking into account prior knowledge on the system.

<NPL>, relates to a comparison of the performance and energy consumption index of model-based controllers. A comparison of the performance of different control algorithms in two types of systems is provided. One exhibits fast dynamics and the other slow dynamics. The first control system regulates the speed of a DC motor, while the second control system regulates the temperature of an electrical heater. This systems' performance comparison pretends to evaluate the energy consumption, as well as the controllers' transient response in order to identify the best control strategy for each system. System models are obtained through the responses to a pseudorandom binary signal (PRBS) and the least squares fit method using an auto-regressive model with an exogenous variable (ARX). The implemented control algorithms used are: pole placement regulator (state-space controller) with integral error processing, auto-tunable proportional-integral-derivative (PID) controller, neural PID controller, unconstrained model predictive control (MPC), fuzzy PID controller, neurofuzzy controller, Bayesian controller and an optimal quadratic regulator (LQR). A detailed analysis of the performance and energy consumption index is performed, that allows the categorization of the control strategies in accordance with their performance.

<CIT> relates to a computer implemented system and method for controlling and monitoring a pump. A pump system is provided comprising a pump, at least one sensor configured for providing an operating state data signal representative of a mechanical, fluidicly, electrical operating state of the pump system and at least one control module controlling the mechanical, fluidicly and/or operating state of the pump in response to a received control signal; a digital twin module comprising a data processing API and an loT database, said digital twin module being configured for retrieving said operating state data signal and storage of the data in the loT database, and being configured to communicate with a chatbot agent, a chatbot agent configured for being in data communication with the API of the digital twin module, a user and the pump system, and configured to providing an actual or historical operating state of the pump by use of the API of the digital twin module extracting from said information from said loT database, and transmitting a control signal, representative of a parameter, to the pump system to set the pump at a requested mechanical and/or electrical operating state.

It is therefore the object of the present invention to improve the performance of model-less controllers.

In one embodiment, a method may include receiving data representative of: one or more commands generated by a model-less controller to control one or more operations of one or more devices within a system and one or more output parameters associated with the one or more devices of the system. The method may also include determining whether the data is indicative of a change in one or more operational characteristics of the system and generating a model representative of the one or more operational characteristics of the system as a function of the data based on a Bayesian optimization algorithm in response to the data being indicative of the change. The method may also involve transmitting an excitation input to the one or more devices in response to the data not being indicative of the change, receiving one or more updated output parameters associated with the one or more devices of the system after the excitation input is transmitted, and generating the model based on the one or more updated output parameters and the excitation input.

As discussed above, embodiments of the present disclosure are directed toward systems and methods for automatically and continuously tuning parameters related to the performance of model-less control strategies, such as proportional-integral-derivative (PID) controllers, to enable improved (e.g., ideally optimized) performance of the controller in response to changes in operating condition of a connected system or system behavior (e.g., aging) and enhance controller robustness when the process experiences disturbances. As described above, model-less control strategies, such as PID controllers, have become ubiquitous in industrial control applications. Such controllers have proven to be fairly robust yet relatively simple in operation. However, due at least in part to the relative simplicity of design, such controllers exhibit certain inherent shortcomings, such as an inability to account for potential future responses of the system being controlled.

In contrast, model-based optimization strategies, such as model predictive control (MPC) techniques, are particularly well-suited for incorporating predictive information of the system being controlled. However, model-based solutions are relatively complex as compared to model-less solutions and are generally more computationally intensive. Moreover, model-based solutions involve expert practitioner input that may include modifying operations of the monitored systems using planned or step tests. That is, practitioners may use a step testing procedure in an open loop control method to cause a response in the process implemented by the system. The response of the system and the related monitored data (e.g., acquired sensor data, system response) may generate a suitable dataset that may be used to model the process. In order for the process to be modeled effectively, the step test may involve purposeful changes in process manipulated variables of the model-less controller and observing the impact of the changes on target variables output or measured from the system.

These changes often move the process implemented by the system away from desired operating conditions for production, thereby reducing the efficiency of the system. Moreover, in complex systems, step tests that adjust one or less than some threshold of variables may not cause any impact or change to the process being implemented by the system. That is, a step test for more complex systems become more onerous for multi-input multi-output (MIMO) systems with coupled dynamics in which the various inputs have dynamic and non-linear affects to the overall system. For such systems, a meaningful or insightful step test may account for interacting process behavior of multiple various, which may complicate the step test procedures.

With this in mind, the presently disclosed embodiments provide improved systems and methods for generating an initial model for dynamically tuning parameters of a model-less controller based on a steady state (e.g., normal) operation of the system controlled by the model-less controller. In other words, the present embodiments include a tuning component that may generate a model related to the operation of the system implementing a process to be a function of data collected from the process as the system operates according to its automated (e.g., control logic) manner. That is, the tuning component may include a self-learning capability that allows it to create a model of the process based on the operating conditions of the system implanting the system, while the system operates. In this way, the present embodiments may avoid implementing a step test that may rely on random changes to process manipulated variables to produce some change to the operation of the system even if the change may cause the system to operate less efficiently.

In brief, the tuning component may implement a two-prong approach to generating the initial model based on normal operation data of the monitored system. Namely, the tuning component may (a) make maximal use of normal operation data of the system by analyzing the information content of the collected data online (e.g., in real time); and may (b) induce minimal excitations to enrich the information content of the data while allowing the system to stay within acceptable bounds operations to minimize efficiency reductions related to production. It should be noted that the tuning component described herein may perform both prongs automatically in real time by using a Bayesian optimization algorithm to determine identify variables that may be used to provide targeted excitation to the system. Additional details with regard to efficiently monitoring audio data to perform diagnostic operations in real time using sensor devices will be described below with reference to <FIG>.

By way of introduction, <FIG> illustrates an example industrial automation system <NUM> employed by a food manufacturer. The present embodiments described herein may be implemented using the various devices illustrated in the industrial automation system <NUM> described below. However, it should be noted that although the example industrial automation system <NUM> of <FIG> is directed at a food manufacturer, the present embodiments described herein may be employed within any suitable industry, such as process, refining, automotive, mining, hydrocarbon production, manufacturing, and the like. The following brief description of the example industrial automation system <NUM> employed by the food manufacturer is provided herein to help facilitate a more comprehensive understanding of how the embodiments described herein may be applied to industrial devices to significantly improve the operations of the respective industrial automation system. As such, the embodiments described herein should not be limited to be applied to the example depicted in <FIG>.

Referring now to <FIG>, the example industrial automation system <NUM> for a food manufacturer may include silos <NUM> and tanks <NUM>. The silos <NUM> and the tanks <NUM> may store different types of raw material, such as grains, salt, yeast, sweeteners, flavoring agents, coloring agents, vitamins, minerals, and preservatives. In some embodiments, sensors <NUM> may be positioned within or around the silos <NUM>, the tanks <NUM>, or other suitable locations within the industrial automation system <NUM> to measure certain properties, such as temperature, mass, volume, pressure, humidity, and the like. In addition, the sensors <NUM> may measure or acquire image data, audio data, and other suitable ambient characteristics surrounding the industrial automation system <NUM>.

The raw materials may be provided to a mixer <NUM>, which may mix the raw materials together according to a specified ratio. The mixer <NUM> and other machines in the industrial automation system <NUM> may employ certain industrial automation devices <NUM> to control the operations of the mixer <NUM> and other machines. The industrial automation devices <NUM> may include controllers, input/output (I/O) modules, motor control centers, motors, human machine interfaces (HMIs), operator interfaces, contactors, starters, sensors <NUM>, actuators, conveyors, drives, relays, protection devices, switchgear, compressors, sensor, actuator, firewall, network switches (e.g., Ethernet switches, modular-managed, fixed-managed, service-router, industrial, unmanaged, etc.) and the like.

The mixer <NUM> may provide a mixed compound to a depositor <NUM>, which may deposit a certain amount of the mixed compound onto conveyor <NUM>. The depositor <NUM> may deposit the mixed compound on the conveyor <NUM> according to a shape and amount that may be specified to a control system for the depositor <NUM>. The conveyor <NUM> may be any suitable conveyor system that transports items to various types of machinery across the industrial automation system <NUM>. For example, the conveyor <NUM> may transport deposited material from the depositor <NUM> to an oven <NUM>, which may bake the deposited material. The baked material may be transported to a cooling tunnel <NUM> to cool the baked material, such that the cooled material may be transported to a tray loader <NUM> via the conveyor <NUM>. The tray loader <NUM> may include machinery that receives a certain amount of the cooled material for packaging. By way of example, the tray loader <NUM> may receive <NUM> ounces of the cooled material, which may correspond to an amount of cereal provided in a cereal box.

A tray wrapper <NUM> may receive a collected amount of cooled material from the tray loader <NUM> into a bag, which may be sealed. The tray wrapper <NUM> may receive the collected amount of cooled material in a bag and seal the bag using appropriate machinery. The conveyor <NUM> may transport the bagged material to case packer <NUM>, which may package the bagged material into a box. The boxes may be transported to a palletizer <NUM>, which may stack a certain number of boxes on a pallet that may be lifted using a forklift or the like. The stacked boxes may then be transported to a shrink wrapper <NUM>, which may wrap the stacked boxes with shrink-wrap to keep the stacked boxes together while on the pallet. The shrink-wrapped boxes may then be transported to storage or the like via a forklift or other suitable transport vehicle.

To perform the operations of each of the devices in the example industrial automation system <NUM>, the industrial automation devices <NUM> may provide power to the machinery used to perform certain tasks, provide protection to the machinery from electrical surges, prevent injuries from occurring with human operators in the industrial automation system <NUM>, monitor the operations of the respective device, communicate data regarding the respective device to a supervisory control system <NUM>, and the like. In some embodiments, each industrial automation device <NUM> or a group of industrial automation devices <NUM> may be controlled using a local control system <NUM>. The local control system <NUM> may include receive data regarding the operation of the respective industrial automation device <NUM>, other industrial automation devices <NUM>, user inputs, and other suitable inputs to control the operations of the respective industrial automation device(s) <NUM>.

With the foregoing in mind, the supervisory control system <NUM>, the local control system <NUM>, and other suitable control systems may employ model-less controllers to coordinate the operation for the industrial automation devices <NUM> (e.g., electromechanical machinery, production lines, conveyer systems). For instance, in certain embodiments, model-less controllers, such as PID controllers, may control operations of single industrial automation device <NUM> (e.g., machine) or a collection of industrial automation devices <NUM> (e.g., line) to cause the industrial automation device(s) <NUM> to modify operations based on detected changes to the operating environment, the industrial automation device(s), process variables associated with the industrial automation system <NUM>, and the like.

By way of example, <FIG> illustrates a diagrammatical representation of an exemplary local control system <NUM> that may be employed in any suitable industrial automation system <NUM>, in accordance with embodiments presented herein. In <FIG>, the local control system <NUM> is illustrated being communicatively coupled to a human machine interface (HMI) <NUM>. The local control system <NUM> may include a control/monitoring device or automation controller adapted to interface with the industrial automation devices <NUM> or other components that may monitor and control various types of the industrial automation devices <NUM>. By way of example, the industrial automation devices <NUM> (industrial automation equipment) may include the mixer <NUM>, the depositor <NUM>, the conveyor <NUM>, the oven <NUM>, other pieces of machinery described in <FIG>, or any other suitable equipment.

It should be noted that the local control system <NUM>, the supervisory control system <NUM>, or any other suitable processing component, in accordance with embodiments of the present techniques, may communicate with other components via certain network strategies. Indeed, any suitable industry standard network or network may be employed, such as DeviceNet, to enable data transfer. Such networks permit the exchange of data in accordance with a predefined protocol and may provide power for operation of networked elements.

In certain embodiments, the local control system <NUM> may include a communication component that enables the industrial automation devices <NUM> to communicate data between each other and other devices. The communication component may include a network interface that may enable the industrial automation equipment <NUM> to communicate via various protocols such as Ethernet/IP®, ControlNet®, DeviceNet®, or any other industrial communication network protocol. Alternatively, the communication component may enable the industrial automation devices <NUM> to communicate via various wired or wireless communication protocols, such as Wi-Fi, mobile telecommunications technology (e.g., <NUM>, <NUM>, <NUM>, LTE, <NUM>), Bluetooth®, near-field communications technology, and the like.

As discussed above, the industrial automation devices <NUM> may take many forms and include devices for accomplishing many different and varied purposes. For example, the industrial automation devices <NUM> may include machinery used to perform various operations in a compressor station, an oil refinery, a batch operation for making food items, a mechanized assembly line, and so forth. Accordingly, the industrial automation devices <NUM> may include a variety of operational components, such as electric motors, valves, actuators, temperature elements, pressure sensors, or a myriad of machinery or devices used for manufacturing, processing, material handling, and other applications.

Additionally, the industrial automation devices <NUM> may include various types of equipment that may be used to perform the various operations that may be part of an industrial application. For instance, the industrial automation devices <NUM> may include electrical equipment, hydraulic equipment, compressed air equipment, steam equipment, mechanical tools, protective equipment, refrigeration equipment, power lines, hydraulic lines, steam lines, and the like. Some example types of equipment may include mixers, machine conveyors, tanks, skids, specialized original equipment manufacturer machines, and the like. In addition to the equipment described above, the industrial automation devices <NUM>, which may include controllers, input/output (I/O) modules, motor control centers, motors, human machine interfaces (HMIs), operator interfaces, contactors, starters, sensors <NUM>, actuators, drives, relays, protection devices, switchgear, compressors, firewall, network switches (e.g., Ethernet switches, modular-managed, fixed-managed, service-router, industrial, unmanaged, etc.), and the like.

In some cases, the industrial automation devices <NUM> may be associated with devices used by other equipment. For instance, scanners, gauges, valves, flow meters, and the like may be disposed on the industrial automation devices <NUM>. Here, the industrial automation devices <NUM> may receive data from the associated devices and use the data to perform their respective operations more efficiently. For example, a controller of a motor drive may receive data regarding a temperature of a connected motor and may adjust operations of the motor drive based on the data.

Input/output (I/O) modules <NUM> may be added or removed from the local control system <NUM> via expansion slots, bays, or other suitable mechanisms. In certain embodiments, the I/O modules <NUM> may be included to add functionality to the local control system <NUM>, or to accommodate additional process features. For instance, the I/O modules <NUM> may communicate with new sensors <NUM> or actuators <NUM> added to local control system <NUM>. It should be noted that the I/O modules <NUM> may communicate directly to sensors <NUM> or actuators <NUM> through hardwired connections or may communicate through wired or wireless sensor networks, such as Hart or IOLink.

Generally, the I/O modules <NUM> serve as an electrical interface to the local control system <NUM> and may be located proximate or remote from a control/monitoring device coupled to the industrial automation device <NUM>, including remote network interfaces to associated systems. In such embodiments, data may be communicated with remote modules over a common communication link, or network, wherein modules on the network communicate via a standard communications protocol. Many industrial controllers can communicate via network technologies such as Ethernet (e.g., IEEE702. <NUM>, TCP/IP, UDP, Ethernet/IP, and so forth), ControlNet, DeviceNet or other network protocols (Foundation Fieldbus (H1 and Fast Ethernet) Modbus TCP, Profibus) and also communicate to higher level computing systems.

In the illustrated embodiment, several of the I/O modules <NUM> may transfer input and output signals between the local control system <NUM> and the industrial automation devices <NUM>. As illustrated, the sensors <NUM> and actuators <NUM> may communicate with the local control system <NUM> via one or more of the I/O modules <NUM>.

In certain embodiments, one or more properties of the industrial automation devices <NUM> may be monitored and controlled by certain equipment for regulating control variables used to operate the industrial automation devices <NUM>. For example, the sensors <NUM> may monitor various properties of the industrial automation devices 20and may provide data to the local control system <NUM>, which may adjust operations of the industrial automation equipment <NUM>, respectively.

The sensors <NUM> may be any number of devices adapted to provide information regarding process conditions. The actuators <NUM> may include any number of devices adapted to perform a mechanical action in response to a signal from a controller (e.g., the local control system <NUM>). The sensors <NUM> and actuators <NUM> may be utilized to operate the industrial automation devices <NUM>. Indeed, they may be utilized within process loops that are monitored and controlled by the local control system <NUM>. Such a process loop may be activated based on process input data (e.g., input from a sensor <NUM>) or direct operator input received through the HMI <NUM>.

In certain embodiments, the industrial automation system <NUM> may make up an industrial automation application that may involve any type of industrial process or system used to manufacture, produce, process, or package various types of items. For example, the industrial applications may include industries such as material handling, packaging industries, manufacturing, processing, batch processing, the example industrial automation system <NUM> of <FIG>, and the like.

In certain embodiments, the local control system <NUM> may be communicatively coupled to a computing device <NUM> and a cloud-based computing system <NUM>. In this network, input and output signals generated from the local control system <NUM> may be communicated between the computing device <NUM> and the cloud-based computing system <NUM>. Although the local control system <NUM> may be capable of communicating with the computing device <NUM> and the cloud-based computing system <NUM>, as mentioned above, in certain embodiments, local control system <NUM> may perform certain operations and analysis without sending data to the computing device <NUM> or the cloud-based computing system <NUM>.

In operation, the industrial automation system <NUM> may receive one or more inputs used to produce one or more outputs. For example, the inputs may include feedstock, electrical energy, fuel, parts, assemblies, sub-assemblies, operational parameters (e.g., sensor measurements), or any combination thereof. Additionally, the outputs may include finished products, semi-finished products, assemblies, manufacturing products, by products, or any combination thereof.

To produce the one or more outputs used to control the industrial automation devices <NUM>, the local control system <NUM> may output control signals to instruct industrial automation devices <NUM> to perform a control action by implementing manipulated variable set points. For example, the local control system <NUM> may instruct a motor (e.g., an automation device <NUM>) to implement a control action by actuating at a particular operating speed (e.g., a manipulated variable set point).

In some embodiments, the local control system <NUM> may determine the manipulated variable set points based at least in part on process data. As described above, the process data may be indicative of operation of the industrial automation device <NUM> and the like. As such, the process data may include operational parameters of the industrial automation device <NUM>. For example, the operational parameters may include any suitable type, such as temperature, flow rate, electrical power, and the like.

Thus, the local control system <NUM> may receive process data from one or more of the industrial automation devices <NUM>, the sensors <NUM>, or the like. In some embodiments, the sensor <NUM> may determine an operational parameter and communicate a measurement signal indicating the operational parameter to the local control system <NUM>. For example, a temperature sensor may measure temperature of a motor (e.g., an automation device <NUM>) and transmit a measurement signal indicating the measured temperature to the local control system <NUM>. The local control system <NUM> may then analyze the process data to monitor performance of the industrial automation application (e.g., determine an expected operational state) and/or perform diagnostics on the industrial automation application.

To facilitate controlling operation and/or performing other functions, the local control system <NUM> may include one or more controllers, such as one or more model predictive control (MPC) controllers, one or more model-less controllers, such as one or more proportional-integral-derivative (PID) controllers, one or more neural network controllers, or one or more fuzzy logic controllers, or both.

In some embodiments, the supervisory control system <NUM> may provide centralized control over operation of the industrial automation application. For example, the supervisory control system <NUM> may enable centralized communication with a user (e.g., operator). To facilitate, the supervisory control system <NUM> may include the display <NUM> to facilitate providing information to the user. For example, the display <NUM> may display visual representations of information, such as process data, selected features, expected operational parameters, and/or relationships there between. Additionally, the supervisory control system <NUM> may include other components as described below.

On the other hand, the local control system <NUM> may provide localized control over a portion of the industrial automation application. For example, in the depicted embodiment of <FIG>, the local control system <NUM> that may be part of the mixer <NUM> may include the local control system <NUM>, which may provide control over operation of a first automation device <NUM> that controls the mixer <NUM>, while a second local control system <NUM> may provide control over operation of a second automation device <NUM> that controls the operation of the depositor <NUM>.

In some embodiments, the local control system <NUM> may control operation of a portion of the industrial automation application based at least in part on the control strategy determined by the supervisory control system <NUM>. Additionally, the supervisory control system <NUM> may determine the control strategy based at least in part on process data determined by the local control system <NUM>. Thus, to implement the control strategy, the supervisory control system <NUM> and the local control systems <NUM> may be communicatively coupled via a network, which may be any suitable type, such as an Ethernet/IP network, a ControlNet network, a DeviceNet network, a Data Highway Plus network, a Remote I/O network, a Foundation Fieldbus network, a Serial, DH-<NUM> network, a SynchLink network, or any combination thereof.

In some embodiments, the sensors <NUM> may include various types of sensors for detecting various types of data. By way of example, the sensors <NUM> described herein may include audio sensors that detect acoustic or sound waves. <FIG> illustrates example components that may be part of the sensor <NUM>. However, it should be noted that the local control system <NUM>, the supervisor control system <NUM>, or any other suitable computing device may include the components described as being part of the sensor <NUM>. Referring to <FIG>, the sensor <NUM> may include a communication component <NUM>, a processor <NUM>, a memory <NUM>, a storage <NUM>, input/output (I/O) ports <NUM>, an audio sensor <NUM> (e.g., a microphone), a location sensor <NUM>, a display <NUM>, additional sensors (e.g., vibration sensors, temperature sensors), and the like. The communication component <NUM> may be a wireless or wired communication component that may facilitate communication between the industrial automation devices <NUM>, the cloud-based computing system <NUM>, and other communication capable devices.

The processor <NUM> may be any type of computer processor or microprocessor capable of executing computer-executable code. The processor <NUM> may also include multiple processors that may perform the operations described below. The memory <NUM> and the storage <NUM> may be any suitable articles of manufacture that can serve as media to store processor-executable code, data, or the like. These articles of manufacture may represent computer-readable media (e.g., any suitable form of memory or storage) that may store the processor-executable code used by the processor <NUM> to perform the presently disclosed techniques. Generally, the processor <NUM> may execute software applications that include programs that enable a user to track and/or monitor operations of the industrial automation devices <NUM> via a local or remote communication link.

The memory <NUM> and the storage <NUM> may also be used to store the data, analysis of the data, the software applications, and the like. The memory <NUM> and the storage <NUM> may represent non-transitory computer-readable media (e.g., any suitable form of memory or storage) that may store the processor-executable code used by the processor <NUM> to perform various techniques described herein. It should be noted that non-transitory merely indicates that the media is tangible and not a signal.

In one embodiment, the memory <NUM> and/or storage <NUM> may include a software application that may be executed by the processor <NUM> and may be used to monitor, control, access, or view one of the industrial automation devices <NUM>. As such, the sensor <NUM> may communicatively couple to the industrial automation devices <NUM> or to a respective computing device via a direct connection between the devices or via the cloud-based computing system <NUM>. The software application may perform various functionalities, such as track statistics of the industrial automation devices <NUM>, determine operating states for the industrial automation devices <NUM>, determine whether industrial automation devices <NUM> are operating in an anomalous state, and so forth.

The I/O ports <NUM> may be interfaces that may couple to other peripheral components such as input devices (e.g., keyboard, mouse), sensors, input/output (I/O) modules, and the like. I/O modules may also enable the sensor <NUM> to interface with the computing device <NUM> or other control/monitoring devices to communicate with the industrial automation devices <NUM> or other devices in the industrial automation system via the I/O modules <NUM>.

The audio sensor <NUM> may include any suitable acoustic acquisition circuitry such as a microphone capable of acquiring sound waves, acoustic signals, or the like. The location sensor <NUM> may include circuitry designed to determine a physical location of the sensor <NUM>. In one embodiment, the location sensor <NUM> may include a global positioning system (GPS) sensor that acquires GPS coordinates for the sensor <NUM>.

The display <NUM> may depict visualizations associated with software or executable code being processed by the processor <NUM>. In one embodiment, the display <NUM> may be a touch display capable of receiving inputs (e.g., parameter data for operating the industrial automation equipment <NUM>) from a user. As such, the display <NUM> may serve as a user interface to communicate with the sensor <NUM>. The display <NUM> may display a graphical user interface (GUI) for operating the sensor <NUM>. The display <NUM> may be any suitable type of display, such as a liquid crystal display (LCD), plasma display, or an organic light emitting diode (OLED) display, for example.

Although the components described above have been discussed with regard to the sensor <NUM> and the local control system <NUM>, it should be noted that similar components may make up other computing devices described herein. Further, it should be noted that the listed components are provided as example components and the embodiments described herein are not to be limited to the components described with reference to <FIG>.

By way of example, the local control system <NUM> may include control systems <NUM> and <NUM> as depicted in <FIG>. That is, <FIG> include schematic diagrams of PID controllers <NUM>, <NUM>, illustrating example operations of such model-less controllers. In particular, <FIG> is a schematic diagram of a position PID controller <NUM>, and <FIG> is a schematic diagram of a velocity PID controller <NUM>, each of which may be augmented with based on analysis of normal operations and minimal excitations input into the control system as will be discussed in greater detail below. As illustrated in <FIG>, an input vector is received by a system <NUM> under control, where the system <NUM> being controlled is defined using the following equations (i.e., model): <MAT> <MAT>
where xk is the state vector, pk is the parameter vector, and yk is the output vector. The output error vector ek between the output vector yk of the system <NUM> and the determined output vector ek (which may include measurements from the system being controlled; µk being measurement noise) is received by the position PID controller <NUM>, which adjusts uPID according to: <MAT>
where KP , KI, and KD are matrix coefficients relating to proportional, integral, and derivative constraints, respectively. The velocity PID controller <NUM> illustrated in <FIG> is similar to the position PID controller <NUM> illustrated in <FIG>. However, the velocity PID controller <NUM> determines Δuk as follows: <MAT> and a control loop <NUM> determines uk based on Δuk using previous values uk-<NUM> as illustrated in <FIG>, and uk is compared to a reference ur to determine the input to the system <NUM>. In conventional systems, there has been no systematic methodology for automatically building reliable models for systematic tuning of coefficients KP, KI , and KD of PID controllers.

It should be noted that the PID controllers <NUM>, <NUM> illustrated in <FIG> are merely exemplary of the types of PID controllers <NUM>, <NUM> that may be used. Any type of arrangement in which a function (linear, polynomial, nonlinear, and so forth) of output error ek , (filtered) derivative of the output error ek , and integral of the output error ek is used to define a control input uk will benefit from the techniques described herein. Any state for which the error signal can be computed may be represented as an output by proper augmentation of the output vector yk.

By way of operation, a set-point may be based on a reference value, and the set-point may be compared to an output of the system <NUM> being controlled to generate an input to the PID controller <NUM>, <NUM>. The PID controller <NUM>, <NUM>, in turn, generates an input for control of the system <NUM>. Furthermore, the output of the system <NUM> is used by the PID controller <NUM>, <NUM> to adjust control commands to cause the system <NUM> to achieve the set-point.

With the foregoing in mind, techniques for combining the features of PID controllers (e.g., speed of operation) with the features of MPC control techniques (e.g., robust predictive capabilities) for the purpose of increasing performance without introducing the drawbacks typically associated with either PID strategies (e.g., lack of predictive capabilities) or MPC strategies (e.g., complexity and relatively low level of responsiveness) are detailed in <CIT> and <CIT>, both of which are incorporated herein. The embodiments presented herein are related to generating the initial model that may be used with MPC control techniques.

<FIG> illustrates a block diagram that illustrates a tuning system <NUM> that may be implemented using embodiments described herein. Before continuing, it should be noted that the tuning system <NUM> is described with a particular model-less controller, certain manipulated variables, certain control variables, certain noise elements, and the like. However, these items are merely provided as example inputs to the tuning system <NUM> and the tuning system <NUM> may receive other suitable inputs that may affect the operations of the tuning system <NUM>.

Referring now to <FIG>, a set point <NUM> may be provided to a PID controller <NUM> similar to the set point or reference described above with reference to <FIG>. The PID controller <NUM> may correspond to the PID controller <NUM> described above. In addition, the PID controller <NUM> may be replaced with any suitable model-less controller.

The PID controller <NUM> may provide commands to a system <NUM> to control process outputs of the system <NUM>. The commands may be provided to one or more industrial automation devices <NUM> or other suitable components. The system <NUM> may correspond to any suitable system, device, or collection of devices that may be controlled by the PID controller <NUM>. As such, the system <NUM> may correspond to the industrial automation system <NUM> described above.

In addition to the commands received from the PID controller <NUM>, the system <NUM> may receive manipulated variable disturbance data <NUM>, which may correspond to actions performed by certain actuators, machines, or components within the system <NUM> or outside the system <NUM>. The manipulated variable disturbance data <NUM> may include any suitable variable that may cause one or more operational characteristics (e.g., speed, efficiency, power usage, heat dissipation, product consistency, error rate) of the system <NUM> to change. As such, the commands provided to the system <NUM> and the manipulated variable disturbance data may both affect the operational characteristics of the system <NUM>. In this way, the commands provided to the system <NUM> by the PID controller <NUM> may not adequately cause the system <NUM> to converge to an operational state that corresponds to the set point <NUM>.

In any case, the system <NUM> may provide system output data <NUM> that may include data acquired from the sensors <NUM>, operational characteristics measured by the industrial automation devices <NUM>, or the like. The system output data <NUM> may represent a current operational state of the system <NUM>. The system output data <NUM> may, however, also include noise or controlled variable disturbance data <NUM>. Noise data may include any suitable sources of noise including electromagnetic interferences, ambient temperature fluctuations, and other noise elements that may cause the system output data <NUM> to change.

In some embodiments, the commands output by the PID controller <NUM>, the manipulated variable disturbance data <NUM>, and the system output data <NUM> may be provided to a tuning component <NUM>. The tuning component <NUM> may be implemented via hardware, software, or both using a controller, a control system, a computing device, or the like. The tuning component <NUM> may generate a model representative of the operational characteristics or the system output data <NUM> of the system <NUM> as a function of the commands output by the PID controller <NUM> and the manipulated variable disturbance data <NUM>. As such, the tuning component may generate the model of the system <NUM> based on normal or continuous operation data of the system <NUM>. Using the generated model, the tuning component may determine PID parameters <NUM> that may enable the PID controller <NUM> to output commands that cause the system <NUM> to converge to the set point <NUM> more efficiently.

By way of example, it should be noted that processes performed by the system <NUM> are often impacted due to changes related to multiple variables, as opposed to a single variable. As such, in some embodiments, the tuning component <NUM> may analyze the changes in the system output data <NUM> using a Bayesian optimization algorithm. That is, the tuning component <NUM> may analyze the changes in the system output data <NUM> using the Bayesian optimization algorithm to identify process changes, upsets, disturbances, and other features that may relate to certain correlations between one or more variables and the system output data <NUM>. That is, since the objective function related to the correlation of the input variables and the system output data <NUM> is unknown, the tuning component <NUM> may treat the behavior of the system <NUM> as a random function and place a prior probability distribution of an uncertain quantity related to the behavior of the system <NUM>.

By using the Bayesian optimization algorithm, the tuning component <NUM> may identify a portion of the collected data that has the lowest (e.g., less than some threshold) uncertainty quantity related to the relationship between the one or more variables and the system output data <NUM>. As such, the tuning component <NUM> may perform a "smart data selection" operation to identify the data that contains information with correlations that may be used to generate a model of the system <NUM>. For instance, in a water treatment facility, the Bayesian optimization algorithm may identify a certain period of time (e.g., operational schedule) in which wastewater is provided during the day, while the remaining period of time the water treatment facility operates using water harvested from rain. The wastewater time period may correspond to a number of manipulated variable changes that cause the associated system <NUM> to react in various ways. These reactions may provide more insight into the behavior of the system <NUM> as opposed to the time period in which the water treatment facility receives rainwater.

If the tuning component <NUM> does not identify a time period in which correlations between input variables and output variables can be identified within some threshold of confidence (e.g., standard deviation threshold of uncertainty), the tuning component <NUM> may send some excitation <NUM> to the system <NUM>. The excitation may include modifying one or more of the manipulated variables, such that the system <NUM> may induce some response or reaction that may be used to identify a correlation, which may be used to generate the model. That is, the excitation may create a time period that the tuning component may characterize as data rich because it includes some detectable correlation between input parameters and the system output data <NUM>.

In some embodiments, after identifying the information rich time period, the tuning component <NUM> may generate a model that represents the performance of the system <NUM> in view of the manipulated variable disturbance data <NUM>, the commands issued by the PID controller <NUM>, and the like. The model may be any suitable model that characterizes the expected system output data <NUM> given the various inputs received by the system <NUM>.

By way of example, the tuning component <NUM> may consider two factors in defining the information-rich time period. The first factor may include whether a variable of interest (e.g., a manipulated variable such as the speed of mixer in a mixing process) is changing more than a threshold amount to offer the possibility of meaningful information extraction (e.g., measurable changes in system output data <NUM>). This property is referred to as "persistent excitation. " Some mathematical definitions for this property may be based on the calculation of different autocorrelations for the signal with its shifted (e.g., delayed) version and identifying if a symmetric matrix formed by these autocorrelations is of full rank or not. The tuning component <NUM> may include an automated calculation of this metric as part of an Al engine function.

The second factor that may be part of determining whether the data is information-rich may include determining whether the variable that is determined to have persistent excitation does in fact impact the target variable of interest (e.g., system output data <NUM>). In one example, a mixer's speed should have more than a threshold amount of variation to be able to introduce information into the operation data (i.e., be persistently exciting). However, if the mixer's speed excitation does not impact the variable of interest (e.g., the viscosity of the mix) in a discernable way (e.g., more than some threshold), then the tuning component <NUM> may determine that the data is not informative. In mathematical terms, this impact may be measured in many ways, such as "mutual information.

With this in mind, the tuning component <NUM> may also determine whether the data is informative or not based on a determination that the mutual information is "authentic. " Referring again to the example above, if the tuning component <NUM> detects another variable that is changing while the mixer speed was changing, this additional variable may corrupt the calculation of mutual information between mixer speed and the viscosity of the mix. As such, the tuning component <NUM> may use a combination of "excitation overlap" and "prior process knowledge" to authenticate this discovery.

Based on the identified model and the current operating state of the system <NUM>, the tuning component <NUM> may generate the PID parameters <NUM> that adjust the operations or function of the PID controller <NUM>. The PID parameters <NUM> may correspond to coefficients used by the PID controller <NUM> to implement the PID algorithm as described above with respect to <FIG>. The PID parameters <NUM> may tune the PID controller <NUM> to react to changes in the system <NUM> more quickly and cause the system <NUM> to achieve a desired state related to the set point <NUM> more efficiently. In other words, the tuned PID controller <NUM> may cause the system <NUM> to converge to a desired state more efficiently and thus increase productivity of the system <NUM>. Additional details with regard to the operations of the tuning component <NUM> is described below with respect to <FIG>.

<FIG> illustrates a flow chart of a method <NUM> for generating parameters of the model-less controller or the PID controller <NUM> of <FIG>, in accordance with embodiments described herein. Although the following description of the method <NUM> is detailed as being performed by the tuning component <NUM>, it should be noted that the method <NUM> may be performed by any suitable controller, control system, or computing device. In addition, although the method <NUM> is described in a particular order, it should be understood that the method <NUM> may be implemented in any suitable order.

Referring now to <FIG>, at block <NUM>, the tuning component <NUM> may receive output data from the PID controller <NUM>. As discussed above, the PID controller output data may include commands designated for one or more industrial automation devices <NUM> of the system <NUM>. The commands are designed to cause the system <NUM> to converge or move to a desired state that corresponds to the set point <NUM>.

At block <NUM>, the tuning component <NUM> may receive system output data <NUM>, which may include responses, sensed data, measured data, operational states, or any other suitable property associated with an output of the system <NUM>. Based on the PID controller output data and the system output data, the tuning component <NUM> may analyze the operational data associated with the system <NUM> in real time. As such, in some embodiments, the tuning component <NUM> may determine an operational mode (e.g., continuous, heavy load, light load) being executed by the system <NUM>.

At block <NUM>, the tuning component <NUM> may also analyzed data to determine whether information present in the data received at blocks <NUM> and <NUM> are sufficient for generating a model for the system <NUM>. The tuning component <NUM> may evaluate the received data to determine whether a threshold number of correlations may be gleaned or tracked between the input data and the output data. That is, if the input data and the output data does not change during a period of time, the tuning component <NUM> may not be able to identify any relationships between the input data and the output data. In the same manner, if the one or more input variables (e.g., manipulated variables) change over a period of time and the output data does not change, the tuning component <NUM> may again be unable to identify any relationship between the input data and the output data. Conversely, if the input data changes and is associated with changes in the output data, the tuning component <NUM> may identify certain correlations that may be used to generate a model of the system <NUM>.

As discussed above, the determination of the information-rich period may be conducted in a number of ways. In some embodiments, the techniques described above may be integrated with an artificial intelligence (AI) engine with the tuning component <NUM> to inform and guide the process of discovering "information-rich data. " For example, controller programs (e.g., Ladder Logic in Rockwell Automation's ControlLogix) may include accurate information on any actions that impact the process of interest. Through connection to related programmable logic control (PLC) code, the tuning component may provide the AI engine with the accurate and real-time context for the data that is measured. This context may assist in the determination of the "information-worthiness" of the data. For example, if the controller program indicates that a certain variable should remain constant, but the actual measurement reflects variation in that variable then the data can be flagged for further input from the operation to ensure that, for example, a sensor failure is not the source of recorded variations.

If the information is not sufficient to generate a model of the system <NUM>, the tuning component <NUM> may proceed to block <NUM> and determine whether a digital twin or simulation of the system <NUM> is available. In some embodiments, the tuning component <NUM> may be communicatively coupled to a storage component (e.g., memory, hard drive, database), a computing device, or some other component that may host a digital twin of the system <NUM>. The digital twin of the system <NUM> may be a digital simulation or representation of the system <NUM>. As such, the digital twin may be composed of individual components that collectively interact with each other in the same manner as the system <NUM>.

When tuning coupled multi-loop PID controllers, closed loop data alone is not sufficient to uniquely determine individual loop models. As such, simulation models, such as the digital twin, may be used to separate the impact of the inputs in closed loop multiple-input multiple-output (MIMO) data. The digital twin may then receive live input data and may produce an output that may be used for either monitoring, anomaly detection, or for modification of the simulation model. In some embodiments, the digital twin or simulation model may be executed by a separate computing device or cloud system that may be accessible to the tuning component <NUM>. In this architecture, the flow of the data from the tuning component <NUM> to server/cloud and the return of information to the tuning component <NUM> may involve encryption/authentication for security reasons.

If the digital twin of the system <NUM> is available, the tuning component <NUM> may proceed to block <NUM> and augment data within the digital twin to enrich the content. The tuning component <NUM> may augment the digital twin by changing a condition or input parameter that the digital twin is currently simulating. The tuning component <NUM> may then proceed to block <NUM> and determine whether the augmented data generated a response from the digital twin of the system <NUM> that may enable the tuning component <NUM> to generate a model for controlling the system <NUM>. As such, the tuning component <NUM> may evaluate the response of the system <NUM> with respect to the modified manipulated variables that correspond to the augmented data. The analysis performed by the tuning component <NUM> at block <NUM> may correspond to the analysis performed at block <NUM>.

If the information at block <NUM> is not sufficient to generate a model of the behavior of the system <NUM> in response to the changes in input data, the tuning component <NUM> may proceed to block <NUM>. At block <NUM>, the tuning component <NUM> may generate an excitation input that may be provided to the system <NUM>. The excitation input may correspond to induce one or more minimal excitations input signals that may be provided to the system <NUM> to enrich the information content of the data while ensuring that the system <NUM> stays within acceptable bounds for production. The excitation input signals may include any change to any suitable manipulated variable or other variable that the system <NUM> may receive as an input. By way of example, the tuning component <NUM> may use excitation input signals such as Pseudo Random Binary Sequence (PRBS) and provide carefully crafted step changes. That is, the tuning component <NUM> may use step changes in processes with long settling time to avoid undue disturbance to the system <NUM>. With the forgoing in mind, the use of Bayesian optimization by the tuning component may ensure that the tuning component <NUM> identify a minimum number of variables to be excited to generate reliable models.

In some embodiments, the tuning component <NUM> may generate an optimal excitation to enrich data to more accurately generate or identify the model of the system <NUM>. The optimal excitation may include an excitation input that produces a detectable change in the system output data <NUM> while allowing the system <NUM> to continue operating within certain operating bounds (e.g., speed, operational efficiency, power consumption). To identify the optimal excitation, the tuning component <NUM> may employ a constrained Bayesian optimization algorithm to determine an excitation signal to provide the system <NUM> to cause the system <NUM> to generate maximal new information. As such, the tuning component <NUM> may use statistical information in the data and the confidence in the model to identify variables that can be excited and a magnitude or level in which the variables should be excited. The tuning component <NUM> may constrain the application of the Bayesian optimization algorithms based on physical constraints of the system <NUM> with respect to certain excitation signals. It is possible that the necessary excitation level for creating informative data would push the process out of an acceptable operation zone of the system <NUM>. In such a case, the constrained Bayesian optimization algorithm may cause the tuning component <NUM> to generate a flag to indicate that manual intervention may be recommended or that the tuning component is unable to generate a meaningful excitation. As a result, the tuning component <NUM> may ensure that the induced excitation does not lead to unacceptable operation regime by the system <NUM>.

In the absence of the systematic Bayesian optimization described herein, excitation signals may be based on heuristic or domain expertise. These excitations are time consuming and may result in measurable waste (e.g., energy, additional control action to compensate for the induced excitation, etc.). As such, optimizing the excitation strategy as described in the embodiments herein may result in significant operational savings, especially if the time/cost to execute these excitations is high.

After generating the excitation input signals, at block <NUM>, the tuning component <NUM> may send the excitation input signal to the system <NUM>. The tuning component <NUM> may then return to block <NUM> and receive the system output data <NUM>. The tuning component <NUM> may then resume the method <NUM>.

Referring briefly back to block <NUM>, if the tuning component <NUM> does not determine that a digital twin of the system <NUM> is available, the tuning component <NUM> may proceed to block <NUM>. As such, in the absence of a digital twin, the tuning component <NUM> may generate an excitation input signal as described above.

Referring now back to blocks <NUM> and <NUM>, after the tuning component <NUM> determines that the information is sufficient for generating a model for the system <NUM>, the tuning component <NUM> may proceed to block <NUM>. At block <NUM>, the tuning component <NUM> may generate a model of the system <NUM> based on the reaction of the system <NUM> in view of the PID controller output data, the system output data <NUM>, or other input data changes. In some embodiments, the tuning component <NUM> may identify a suitable model that represents the response of the system <NUM> in view of the excitation signal.

Model generation, referred to as "System Identification," may be part of an AI-driven tuning of the PID controller <NUM>. In some embodiments, the tuning component <NUM> may use a closed-loop system identification algorithm. As referred herein, a closed loop may refer to a controller (e.g., the PID controller) that remains in place and therefore there is an inherent correlation due to controller action that the identification algorithm should overcome. The tuning component may thus include an integrated closed-loop system ID with an AI engine so that the identification in closed loop is possible for multi-input multi output (MIMO) systems, thereby providing reliable results.

In some embodiments, the tuning component <NUM> may monitor the consistency of the models built against various upset conditions. That is, the tuning component <NUM> may use cross-validation operations to ensure the robustness of the model. In some embodiments, the tuning component <NUM> may utilize an inherent randomness in how disturbances impact the process implemented by the system <NUM> as an opportunity to cross validate the model across different times and process variations. The tuning component <NUM> may then select a model that is most consistent against variations.

After generating the model of the system <NUM>, the tuning component <NUM> may proceed to block <NUM> and generate PID parameters <NUM> to improve the performance of the PID controller <NUM>. In some embodiments, the tuning component may use a robust multi-objective optimization strategy to determine the PID parameters <NUM> associated with the coupled MIMO PID loops through systematic optimization. For example, the tuning component <NUM> may consider three terms considered in an objective function for determining the PID parameters <NUM>. The terms may include (a) a transfer function between an input set point <NUM> to error (e.g., set point - process variable or system output data <NUM>) and may be concerned with the ability to track the set point <NUM>; (b) a transfer function between reference input set point <NUM> and a control variable or the PID controller output data that may be concerned with a cost/size of the control action; and (c) a transfer function between process disturbances to the process output (e.g., noise/ control variable disturbance <NUM>) that may be concerned with disturbance rejection. Simultaneous consideration of these three terms may enable the tuning component <NUM> to provide a robust tuning strategy that eliminates the need for trial and error. That is, by employing the techniques described herein, the tuning component <NUM> may provide automated online tuning of the PID controllers by selecting the tuning parameters as a result of the analysis of the operation data to properly set the parameters as it pertains to current operating condition of the system <NUM>.

The tuning component <NUM> may employ a variety of methodologies to determine the PID parameters <NUM>. For example, the tuning component <NUM> may employ tuning algorithms that rely on heuristic processes and may involve some degree of trial and error. With this in mind, the tuning component <NUM> may use an optimization-based approach to the tuning of the PID coefficients. In particular, the tuning component <NUM> may use the connectivity to the PID controller <NUM> to determine whether the output of the optimization is reliably robust to be deployed online. As such, the tuning component <NUM> may perform parallel simulations against various process models to examine whether the identified tuning is robust across various operation regions. Also, the tuning component <NUM> may use the AI engine to properly schedule transition from current tuning of the system <NUM> to the newly determined optimal tuning.

It should be noted that the tuning component <NUM> may avoid creating disturbances in the system <NUM> due to changes in PID parameters <NUM> or coefficients. If done without proper provisions, changing PID coefficients could trigger transient responses in the system <NUM> that may result in interruptions in operation (e.g., tripping protective relays because of current excursions). As such, at block <NUM>, the tuning component <NUM> may determine a time to apply the PID parameters <NUM> to the PID controller <NUM>. That is, the tuning component <NUM> may use automated analysis of the data to determine a time period in which a change in the PID parameters <NUM> (e.g., coefficients) may result in minimum transient response (e.g., changing the proportional gain when the tracking error is near zero which makes contributions of the change in P coefficient insignificant).

After determining the suitable time period, the tuning component <NUM> may, at block <NUM>, send the PID parameters <NUM> to the PID controller <NUM> at the suitable time. That is, the tuning component <NUM> may modify the PID parameters <NUM> of the PID controller <NUM> during a time period in which the system <NUM> may be minimally affected due to the current operational state of the system <NUM>. However, after the PID parameters <NUM> are updated in the PID controller <NUM>, the PID controller <NUM> may control the system <NUM> more effectively by converging to a desired state that corresponds to the set point <NUM> more efficiently, as compared to using the previous PID parameters. Moreover, the PID controller <NUM> may be better suited to adapt to changes in the system output data <NUM> due to changes int eh manipulated variable disturbance data <NUM>, the noise or controlled variable disturbance data <NUM>, or the like.

It should be noted that that the different components of the block diagram shown in <FIG> may be deployed in different environments. For example, while the tuning component <NUM> may be hosted on an edge device (e.g., Rockwell Automation's VersaView <NUM>), the digital twin may be hosted by a server or in a cloud under proper communication security protocols. Moreover, as mentioned above, the PID controller <NUM> may be embedded in a programmable logic controller (PLC) (e.g., Rockwell Automation's ControlLogix), on an edge device, and the like. Moreover, it is also possible to run different portions of the method <NUM> in different cores of a single multi-core processor.

Claim 1:
A non-transitory computer-readable medium comprising computer-executable instructions that, when executed, are configured to cause a processor to perform operations comprising:
receiving (<NUM>, <NUM>) data representative of:
one or more commands (<NUM>) generated by a model-less controller to control one or more operations of one or more devices within a system (<NUM>; <NUM>);
manipulated variable disturbance data (<NUM>) associated with one or more operational characteristics of the system; and
one or more output parameters (<NUM>) associated with the one or more devices of the system;
determining (<NUM>) whether the data is indicative of a change in the one or more operational characteristics of the system;
generating a model representative of the one or more operational characteristics of the system as a function of the data based on a Bayesian optimization algorithm in response to the data being indicative of the change;
generating (<NUM>) an excitation input, wherein the excitation input includes a change to one or more manipulated variables that the system receives, wherein the excitation input is determined using a constrained Bayesian optimization algorithm, and wherein the excitation input is adapted to produce a detectable change in the system output data while allowing the system to continue operating within operating bounds, and transmitting the excitation input to the one or more devices in response to the data not being indicative of the change;
receiving one or more updated output parameters associated with the one or more devices of the system after the excitation input is transmitted; and
generating the model based on the one or more updated output parameters and the excitation input.