Patent Grant
10607466
The subject matter disclosed herein relates generally to industrial control systems, and, more particularly, to configuration of alarms in industrial control systems
The following presents a simplified summary in order to provide a basic understanding of some aspects described herein. This summary is not an extensive overview nor is intended to identify key/critical elements or to delineate the scope of the various aspects described herein. Its sole purpose is to present some concepts in a simplified form as a prelude to the more detailed description that is presented later.
In one or more embodiments, an industrial control device is provided, comprising a program execution component configured to execute an industrial control program; a tag database component configured to maintain controller tags associated with the industrial control program; and an alarm processing component configured to, in response to receipt of alarm configuration data that defines an alarm condition and identifies a controller tag of the controller tags, create an association between the alarm condition and the controller tag, wherein the association causes the alarm condition to be a function of a value of the controller tag, the alarm processing component is further configured to, in response to a determination that the value of the controller tag satisfies the alarm condition, generate an alarm notification based on the association, and the alarm notification is accessible by an external application.
Also, one or more embodiments provide a method for configuring and evaluating industrial alarms, comprising receiving, by an industrial control device comprising a processor, alarm configuration data that defines an alarm condition and identifies a controller tag, of a set of controller tags defined on the industrial control device, to be associated with the alarm condition; in response to the receiving, creating, by the industrial control device, an association between the alarm condition and the controller tag, wherein the creating the association causes the alarm condition to be a function of a value of the controller tag; and in response to determining that the value of the controller tag satisfies the alarm condition, generating, by the industrial control device, an alarm notification in accordance with the association, wherein the alarm notification is accessible to an external application.
Also, according to one or more embodiments, a non-transitory computer-readable medium is provided having stored thereon instructions that, in response to execution, cause a system to perform operations, the operations comprising receiving alarm configuration data that defines an alarm condition and identifies a controller tag, of a set of controller tags defined on the industrial control device, to be associated with the alarm condition; in response to the receiving, creating an association between the alarm condition and the controller tag, wherein the creating the association causes the alarm condition to be a function of a value of the controller tag; and in response to determining that the value of the controller tag satisfies the alarm condition, generating an alarm notification in accordance with the association, wherein the alarm notification is accessible to an external application.
To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings. These aspects are indicative of various ways which can be practiced, all of which are intended to be covered herein. Other advantages and novel features may become apparent from the following detailed description when considered in conjunction with the drawings.
The subject disclosure is now described with reference to the drawings, wherein like reference numerals are used to refer to like elements throughout. In the following description, for purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding thereof. It may be evident, however, that the subject disclosure can be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to facilitate a description thereof.
As used in this application, the terms “component,” “system,” “platform,” “layer,” “controller,” “terminal,” “station,” “node,” “interface” are intended to refer to a computer-related entity or an entity related to, or that is part of, an operational apparatus with one or more specific functionalities, wherein such entities can be either hardware, a combination of hardware and software, software, or software in execution. For example, a component can be, but is not limited to being, a process running on a processor, a processor, a hard disk drive, multiple storage drives (of optical or magnetic storage medium) including affixed (e.g., screwed or bolted) or removable affixed solid-state storage drives; an object; an executable; a thread of execution; a computer-executable program, and/or a computer. By way of illustration, both an application running on a server and the server can be a component. One or more components can reside within a process and/or thread of execution, and a component can be localized on one computer and/or distributed between two or more computers. Also, components as described herein can execute from various computer readable storage media having various data structures stored thereon. The components may communicate via local and/or remote processes such as in accordance with a signal having one or more data packets (e.g., data from one component interacting with another component in a local system, distributed system, and/or across a network such as the Internet with other systems via the signal). As another example, a component can be an apparatus with specific functionality provided by mechanical parts operated by electric or electronic circuitry which is operated by a software or a firmware application executed by a processor, wherein the processor can be internal or external to the apparatus and executes at least a part of the software or firmware application. As yet another example, a component can be an apparatus that provides specific functionality through electronic components without mechanical parts, the electronic components can include a processor therein to execute software or firmware that provides at least in part the functionality of the electronic components. As further yet another example, interface(s) can include input/output (I/O) components as well as associated processor, application, or Application Programming Interface (API) components. While the foregoing examples are directed to aspects of a component, the exemplified aspects or features also apply to a system, platform, interface, layer, controller, terminal, and the like.
As used herein, the terms “to infer” and “inference” refer generally to the process of reasoning about or inferring states of the system, environment, and/or user from a set of observations as captured via events and/or data. Inference can be employed to identify a specific context or action, or can generate a probability distribution over states, for example. The inference can be probabilistic—that is, the computation of a probability distribution over states of interest based on a consideration of data and events. Inference can also refer to techniques employed for composing higher-level events from a set of events and/or data. Such inference results in the construction of new events or actions from a set of observed events and/or stored event data, whether or not the events are correlated in close temporal proximity, and whether the events and data come from one or several event and data sources.
In addition, the term “or” is intended to mean an inclusive “or” rather than an exclusive “or.” That is, unless specified otherwise, or clear from the context, the phrase “X employs A or B” is intended to mean any of the natural inclusive permutations. That is, the phrase “X employs A or B” is satisfied by any of the following instances: X employs A; X employs B; or X employs both A and B. In addition, the articles “a” and “an” as used in this application and the appended claims should generally be construed to mean “one or more” unless specified otherwise or clear from the context to be directed to a singular form.
Furthermore, the term “set” as employed herein excludes the empty set; e.g., the set with no elements therein. Thus, a “set” in the subject disclosure includes one or more elements or entities. As an illustration, a set of controllers includes one or more controllers; a set of data resources includes one or more data resources; etc. Likewise, the term “group” as utilized herein refers to a collection of one or more entities; e.g., a group of nodes refers to one or more nodes.
Various aspects or features will be presented in terms of systems that may include a number of devices, components, modules, and the like. It is to be understood and appreciated that the various systems may include additional devices, components, modules, etc. and/or may not include all of the devices, components, modules etc. discussed in connection with the figures. A combination of these approaches also can be used.
Industrial controllers and their associated I/O devices are central to the operation of modern automation systems. These controllers interact with field devices on the plant floor to control automated processes relating to such objectives as product manufacture, material handling, batch processing, supervisory control, and other such applications. Industrial controllers store and execute user-defined control programs to effect decision-making in connection with the controlled process. Such programs can include, but are not limited to, ladder logic, sequential function charts, function block diagrams, structured text, or other such platforms.
Industrial devices 120 may include both input devices that provide data relating to the controlled industrial systems to the industrial controllers 118, and output devices that respond to control signals generated by the industrial controllers 118 to control aspects of the industrial systems. Example input devices can include telemetry devices (e.g., temperature sensors, flow meters, level sensors, pressure sensors, etc.), manual operator control devices (e.g., push buttons, selector switches, etc.), safety monitoring devices (e.g., safety mats, safety pull cords, light curtains, etc.), and other such devices. Output devices may include motor drives, pneumatic actuators, signaling devices, robot control inputs, valves, and the like.
Industrial controllers 118 may communicatively interface with industrial devices 120 over hardwired or networked connections. For example, industrial controllers 118 can be equipped with native hardwired inputs and outputs that communicate with the industrial devices 120 to effect control of the devices. The native controller I/O can include digital I/O that transmits and receives discrete voltage signals to and from the field devices, or analog I/O that transmits and receives analog voltage or current signals to and from the devices. The controller I/O can communicate with a controller's processor over a backplane such that the digital and analog signals can be read into and controlled by the control programs. Industrial controllers 118 can also communicate with industrial devices 120 over a network using, for example, a communication module or an integrated networking port. Exemplary networks can include the Internet, intranets, Ethernet, DeviceNet, ControlNet, Data Highway and Data Highway Plus (DH/DH+), Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, and the like. The industrial controllers 118 can also store persisted data values that can be referenced by the control program and used for control decisions, including but not limited to measured or calculated values representing operational states of a controlled machine or process (e.g., tank levels, positions, alarms, etc.) or captured time series data that is collected during operation of the automation system (e.g., status information for multiple points in time, diagnostic occurrences, etc.). Similarly, some intelligent devices—including but not limited to motor drives, instruments, or condition monitoring modules—may store data values that are used for control and/or to visualize states of operation. Such devices may also capture time-series data or events on a log for later retrieval and viewing.
Industrial automation systems often include one or more human-machine interfaces (HMIs) 114 that allow plant personnel to view telemetry and status data associated with the automation systems, and to control some aspects of system operation.
HMIs 114 can generate one or more display screens through which the operator interacts with the industrial controllers 118, and thereby with the controlled processes and/or systems. The display screens can visualize present states of industrial systems or their associated devices using graphical objects that display metered or calculated values, employ color or position animations based on state, render alarm notifications, or employ other such techniques for presenting relevant data to the operator. Data presented in this manner is read from industrial controllers 118 by HMIs 114 as controller tag data 206 and presented on one or more of the display screens according to display formats chosen by the HMI developer. HMIs 114 may comprise fixed or mobile devices that execute either user-installed or pre-installed operating systems, and either user-installed or pre-installed graphical application software.
In addition to rendering operational and status information, HMIs are typically configured to generate and display alarm notifications 210 in response to a detected abnormal or fault within the controlled system, machine, or process. These alarms are typically configured within the HMI's project file or on an external server.
Control program 204 can also update values of user-defined controller tags defined in the controller tag database 316, including but not limited to internal program variables or bits, setpoint values, calculated values or calculated status bits, or other such data.
In general, controller tags are data structures that reference a data item or memory location within the controller 118 (e.g., an input value, an output value, or an internal data register). A controller tag can be configured to be an instance of a specified data type, such as binary, floating point, integer, double integer, string, etc. These controller tags are typically defined during configuration and programming of the controller 118.
HMI 114 comprises an HMI terminal device 302 that executes an HMI project file 304. The HMI project file 304 defines the display screens 306 and configuration settings for the HMI (e.g., communication parameters for communicating with controller 118, display preferences, etc.). Each of the display screen 306 hosts static and/or dynamic content that renders, in textual or graphical format, values of selected controller tags representing states of the controlled process 320. One or more of the defined display screens 306 can also include interactive objects that allow an operator to enter a value to be written to a selected one of the controller tags, or to set/reset a bit within the controller 118 (e.g. issue a start or stop command to a device via the control program).
HMI project file 304 also includes an alarm database 308 that defines one or more conditions that will trigger an alarm display on the HMI 114. Alarm database 308 defines each abnormal condition for which an alarm message is to be generated, as well as the industrial controller tag (or combination of tags) that controls the ON and OFF states of each alarm. According to this configuration, evaluation of each alarm's state is performed by the HMI 114 or an external server based on status information read from the controller tag database 316 (e.g., via network 116). Since alarms are viewed and managed via the HMI 114 or external server, it is difficult to suppress alarms from the control application itself.
In other example alarm configurations, alarm instructions can be programmed as part of the control program 204 executing on the industrial controller 118, and alarm detection processing can be performed on the industrial controller 118 rather than on the HMI 114. This technique eliminates the need for the HMI 114 to read controller tag data from the industrial controller 118, and may be more reliable than evaluating alarm conditions in the HMI 114. However, configuring alarms within the control application executing on the industrial controller 118 can detrimentally impact execution of the control program 204 as a result of the additional processing resources required to process the alarms, thereby adversely impacting real-time control latency. Moreover, in order to add or remove alarm conditions using this approach, the user must edit the control program 204, either by modifying the control program offline and downloading the modified program to the industrial controller 118 or by interfacing with the industrial controller 118 using a configuration application and modifying the control program 204 online.
To address these and other issues, various embodiments described herein provide systems and methods that simplify alarm management in industrial control systems. These systems and methods can also improve scalability and capacity of alarms within control systems. In one or more embodiments, a control system device (e.g., an industrial controller 118 or other control device) allows control system alarm conditions to be defined and associated with controller tags or other components of the control system being monitored. Alarm conditions that are associated with controller tags or components can be referenced by external systems (e.g., HMIs, program development applications, or other external systems) as extensions of their associated controller tag or component. This technique can simplify management of alarms during commissioning and operation of the control equipment. For example, this technique allows additional alarms to be added and configured, or alarms that are no longer needed to be deleted, without the need to edit the industrial control program 204 or other control application. Moreover, since the alarm conditions are not programmed as a direct part of the control program 204 executed by the industrial controller 118, alarm conditions are evaluated independently of the control application (e.g., in a separate execution thread relative to the control application) and thus do not impact performance of real-time control.
Industrial control device 402 can include a tag database component 404, a program execution component 406, an alarm processing component 408, one or more processors 416, and memory 418. In various embodiments, one or more of the tag database component 404, program execution component 406, alarm processing component 408, the one or more processors 416, and memory 418 can be electrically and/or communicatively coupled to one another to perform one or more of the functions of the control device 402. In some embodiments, components 404, 406, and 408 can comprise software instructions stored on memory 418 and executed by processor(s) 416. Control device 402 may also interact with other hardware and/or software components not depicted in
Tag database component 404 can be configured to maintain a database of controller tags associated with the control device 402 and used to store or address data items in connection with monitoring and control of an industrial machine, system, or process. The controller tags can include tags corresponding to different data types, including but not limited to analog data tags (e.g., integer, real, or double data tags), digital data tags, string data tags, or other such tags. Some controller tags are configured to store data values corresponding to respective analog or digital inputs or outputs of the control device 402. Other controller tags can be configured to store data values that are generated and used internally by the control program executed by the control device 402. Controller tags can be added to the tag database and configured by a user using a suitable configuration application that interfaces with the control device 402.
Program execution component 406 can be configured to execute a user-defined control program (e.g., control program 204) designed to monitor and control an industrial system, machine, or process via the control device's I/O (e.g., I/O modules or native hardwired inputs and outputs). Alarm processing component 408 can be configured to generate alarm notifications for alarm conditions that are associated with selected controller tags, data types, or other control objects. The one or more processors 416 can perform one or more of the functions described herein with reference to the systems and/or methods disclosed. Memory 418 can be a computer-readable storage medium storing computer-executable instructions and/or information for performing the functions described herein with reference to the systems and/or methods disclosed.
Program development component 504 can be configured to generate a control program for execution on an industrial control device (e.g., industrial control device 402, which may be an industrial controller such as a PLC or another type of industrial control device) based on programming input provided by a user (e.g., a ladder logic program, sequential function chart input, etc.). Alarm configuration component 506 can be configured to generate alarm configuration data to be associated with the control program during development of the control program. Alarm configuration component 506 can generate this alarm configuration data in accordance with user input specifying user-defined alarm conditions, or may generate some or all of this alarm configuration data automatically based on the content of the control program, the controller tags defined for the control device 402, or an organizational hierarchy of the control program. The control device interface component 508 can be configured to establish communication with the control device 402 so that controller configuration data, including the control program and associated tag and alarm conditions, can be downloaded to the control device 402. Communication established by the control device interface component 508 can also allow the user to monitor runtime data generated by the control device within the program development environment.
The one or more processors 516 can perform one or more of the functions described herein with reference to the systems and/or methods disclosed. Memory 518 can be a computer-readable storage medium storing computer-executable instructions and/or information for performing the functions described herein with reference to the systems and/or methods disclosed.
In general, device configuration application 604 generates and downloads controller configuration data 606 to the industrial control device 402 in accordance with user-defined programming and configuration settings. This controller configuration data 606 can include at least a control program 608, tag definitions 610, and alarm configuration data 612. Device configuration application 604 executes a programming environment that allows a developer to generate a control program 608 to be executed on industrial control device 402. As described above, control program 608 can be written as a ladder logic program, one or more sequential function charts, one or more function block diagrams, structured text, or another type of control program.
Device configuration application 604 also includes configuration tools that allow the developer to generate tag definitions 610 defining the controller tags that will be used by the control program 608. These tags can include digital and analog I/O tags as well as tags corresponding to digital, numerical, or string values that are calculated or set by the control program 608 or by the control device's internal diagnostic processing. Each controller tag is an instance of a designated data type (e.g., binary, floating point, integer, double integer, string, etc.). When downloaded to the control device 402 as part of controller configuration data 606, the control device's tag database component 404 configures the device's tag database in accordance with the tag definitions 610.
Alarm configuration data 612 defines alarm conditions to be associated with selected controller tags (that is, selected tags defined by tag definitions 610), data types, or other control objects. Alarm configuration data 612 can also define sets of alarm conditions that are to be grouped together and processed collectively as alarm sets, as will be described in more detail herein. At least some of alarm configuration data 612 can be generated based on user-defined alarm configurations and tag associations. In some embodiments, some or all of alarm configuration data can also be generated automatically during program development.
In addition to the tag database 316, control device 402 maintains alarm configuration data 612 that defines alarm conditions and their associations with one or more of the controller tags defined in the tag database 316. These associations between alarm conditions and selected controller tags can be set by the developer using device configuration application 604, and may be either defined by a user or generated automatically based on the control program (e.g., based on the project structure of the control program, such that the alarm sets reflect the organizational hierarchy of the control program). The alarm configuration component 506 of device configuration application 604 can allow alarm conditions to be indirectly associated with controller tags defined in the tag database. An alarm condition defines the conditions under which an alarm will be generated as a function of its associated controller tag. For example, the alarm condition associated with a given controller tag may define that an alarm notification is to be generated when a value of the controller tag exceeds a defined setpoint specified by the alarm condition, or when another state of the controller tag corresponds to an alarm state specified by the alarm condition.
In the example illustrated in
Control program development system 502 can also support definition of alarm sets comprising multiple alarm conditions that can be acted upon as a group.
In addition, a number of alarm sets 802 have been defined, where each alarm set 802 comprises multiple alarm conditions that have been grouped together for the purposes of collective alarm operations and rollup information (to be described in more detail below). For clarity, only two example alarm sets 802a and 802b are shown in
As will be described in more detail below, alarm processing component 408 can generate rollup information for each defined alarm set 802. This rollup information comprises aggregated statistics regarding the states of the alarm conditions that make up the alarm set. Alarm sets 802 also allow operations—such as alarm acknowledgement operations—to be applied to all alarms in the alarm set 802 in response to a single operator or programmatic action.
Control system developers often wish to use the same alarm conditions on multiple alarms, as in scenarios in which the same type of alarm is applied to different control objects (e.g., different pumps, different brewing vats, etc.). For example, some alarm conditions may be configured to trigger a high temperature alarm when the temperature exceeds a first setpoint, a high-high temperature alarm when the temperature exceeds a second (higher) setpoint, a low temperature alarm when the temperature falls below a third setpoint lower than the high and high-high setpoints, and a low-low temperature alarm when the temperature falls below a fourth setpoint lower than the first, second, and third setpoints. This same alarm condition may be required for several different control objects that make up a control project. In such scenarios, control system designers typically must manually reenter the same configurations and alarms into the development system for different objects (e.g., tags, add-on instructions, function blocks, etc.)
To address this issue, the alarm configuration component 506 can allow an alarm condition to be reused and reapplied to multiple objects, thereby mitigating the need to enter the same alarm configuration multiple times for different objects to be monitored. These reusable alarm conditions can be created offline and downloaded to the control device 402 as part of controller configuration data 606, or may be created online during runtime of the control device 402. Once defined, an alarm condition can be assigned as needed to individual tags or to an alarm set 802. In the example depicted in
In some embodiments, alarm configuration component 506 can allow reusable alarm conditions to be associated with any data type within the control program project, including but not limited to system-defined data types, user-defined data types, and module-defined data types. Reusable alarm conditions can also be associated with add-on instruction definitions. When an alarm condition is created and associated with a selected data type, alarm configuration component 506 can apply the alarm condition to all controller tags within the project that are instances of the selected data type. This can include associating the alarm condition to pre-existing controller tags of the selected data type, as well as automatically assigning the alarm condition to controller tags conforming to the selected data type that are created after the alarm condition has been created. In this way, a developer can define an alarm condition that will be applied to multiple control objects of a selected data type throughout a control project, and the development system 502 will apply this pre-defined alarm condition to controller tags conforming to the data type as appropriate. The ability to reuse defined alarm conditions across multiple controller tags can eliminate the need to define a common alarm condition multiple times across many controller tags.
In some embodiments, alarm configuration component 506 can automatically create and assign an alarm set 802 to a controller tag during program development based on the controller tag's data type (e.g., a user-defined data type or a system-defined data type). In this regard, each controller tag of a given data type can be considered an instance of that data type. An alarm set 802 can be defined and associated with a selected data type, such that the alarm configuration component 506 will automatically assign that alarm set 802 to each controller tag corresponding to the data type. When an alarm set 802 is associated with a data tag, all alarm conditions associated with the tag will be associated with the alarm set 802. In some embodiments, alarm conditions or alarm sets can also be associated with other components of a control system, including but not limited to I/O modules, programs, motion control axes, add-on instructions (AOIs), or a built-in instruction.
After development of control program 608 is complete and the tag definitions 610 and alarm configurations 612 have been defined, the controller configuration data 606—including the compiled program 608 and associated alarm condition and alarm set definitions—is downloaded to the control device 402 (see
During real-time control, alarm processing component 408 evaluates the alarm conditions and alarm sets defined by alarm configuration data 612, and generates alarm notification data 902 in response to determining that one or more of the defined alarm conditions are satisfied. Alarm processing component 408 makes this alarm notification data 902—as well as the alarm condition and alarm set information—accessible to external applications, similar to other control system information. Thus, the alarm notification data 902 can be read by an HMI 114 communicatively connected to the control device 402 (e.g., via a plant network 116 or via a direct hardwired or wireless connection) and rendered on an appropriate alarm display screen generated by the HMI 114. Although the alarm configuration data 612 is stored on the industrial control device 402, some embodiments of alarm processing component 408 can evaluate and process alarm conditions using separate processing resources from those used to execute control program 608, or using a separate execution thread relative to the control program. In this way, alarm conditions are processed without impacting execution of the control program 608 or introducing latency into the control process.
If alarm sets 802 have been configured as part of alarm configuration data 612, alarm processing component 408 will also generate rollup information for each defined alarm set. This rollup information 904 can also be read by and rendered on HMI 114. Rollup information 904 and other alarm set behaviors are discussed in more detail below.
Using this alarm configuration system, alarm conditions and alarm sets are independently creatable and configurable components that reside within the industrial control device 402 but can be configured separately from the control program 608 and other configurable parameters of the control device 402. For example, if a user wishes to add new alarm conditions, edit an alarm set to add or remove alarm conditions, or reassign alarm conditions or alarm sets to different controller tags, such changes can be implemented by modifying alarm configuration data 612 (e.g., using device configuration application 604) without requiring the control program 608 to be edited, interrupted, or re-downloaded. In this way, alarm conditions can be created, configured, or deleted in the control device 402 (e.g., industrial controller, motor drive, etc.) regardless of the current control system state and are not directly connected to the control program or application code.
When an alarm condition or alarm set is associated with a controller tag, the alarm condition or alarm set becomes accessible as an extended member or property of its associated controller tag (or other type of component with which the alarm conditions or alarm sets are associated, such as a control instruction, a data type, an I/O module, a motion control axis, etc.). Members of the alarm conditions and alarm sets are accessible programmatically as controller tag extensions, and are also accessible externally from an HMI 114 or other client-side applications. Programmatic and external access to alarm condition data members and alarm set data members is similar to access to other tags defined in the control device 402.
Since alarm condition and alarm set properties are made available as extended members of controller tags, these properties can be accessed programmatically, allowing changes to be made to the alarm conditions by the control program 608 itself. In an example scenario, operation of an industrial process may require changes to be made to the configuration of one or more alarm conditions based on the state of the process. This may include, for example, disabling or enabling evaluation of the alarm conditions, changing the value of a high limit alarm defined by the alarm condition, or other such changes. While these changes can be made by an operator, some embodiments of the alarm processing system described herein can allow the control application or control program 608 to implement these changes by accessing the appropriate controller tag's alarm extensions or alarm properties.
For example, control program 608 can include code that, when executed by program execution component 406, suppresses selected alarm conditions to prevent these alarm conditions from generating unnecessary or nuisance alarm notifications while a process or machine is in the process of initializing. Suppressing or disabling an alarm condition in this manner prevents evaluation of the alarm condition by the alarm processing component 408. After the process or machine has achieved steady state operation, the program code can re-enable the alarm conditions to allow normal evaluation of the alarm conditions. In another example, the control program 608 can adjust the limit conditions that trigger a given alarm based on the particular process control recipe that is currently being executed by the control device 402. In general, the alarm configuration architecture described herein can allow the programmer to define conditions of the controlled process or machine under which properties of selected alarm conditions are modified (e.g., whether the alarm is enabled or disabled, high or low limits that trigger the alarm, etc.).
Programmatic alarm configuration changes such as those described above can be supported using several techniques. In the following examples, Tank101 is an instance of an add-on instruction that manages inflow and outflow for a material storage tank. In a first technique for programmatically changing an alarm configuration, a member of an alarm condition or an alarm set can be directly programmatically accessed from code outside of the add-on instruction. For example, such outside code can programmatically access or reference the tag extension Tank101.Level@alarms.HiLevel.Limit (or other suitable nomenclature) and modify the high level limit for the alarm for Tank101 by altering a value associated with this extension. The alarm configuration architecture can leverage association information at compile time to resolve the reference to the alarm condition for the high level alarm for Tank101. According to this example nomenclature, the extension @alarms.HiLevel.Limit is an extended member of the controller tag representing a property of the alarm condition associated with the Tank101 (the instance of the add-on instruction). Modifying the value associated with this extension modifies the alarm condition such that the new value is used as the high limit value that triggers the alarm.
Other properties of the alarm condition associated with Tank101 can also be accessed programmatically in this manner, including both read-only properties as well as read-write properties. Other properties of the alarm condition that can be accessed, viewed, and/or modified as extensions of the associated controller tag can include, but are not limited to, a state of the alarm condition (e.g., active, inactive, acknowledged, unacknowledged, etc.), a severity level to be assigned to the alarm condition, an ON delay value associated with the alarm condition (defining an amount of time between satisfaction of the alarm condition and generation of the corresponding alarm notification), an OFF delay value associated with the alarm conditions (defining an amount of time between removal of the condition causing the alarm and removal of the alarm notification), an acknowledge command property, a disable or enable property, a suppress or unsuppressed property, or other such alarm condition properties.
In a second technique for programmatically changing an alarm configuration, a member of the alarm condition or the alarm set for an instance of the Tank101 add-on instruction can be accessed from within the add-on instruction application. For example, a high level alarm conditions created for a present instance of the tank can be accessed by referencing This.Level@alarms.HiLevel.Limit. The system can determine the correct alarm condition to reference for the instance of the add-on instruction that is being executed at runtime. The alarm system can use information within the alarm set object to resolve the reference to the high level alarm condition limit value. Additional alarms can be added to the definition without compromising access to the alarm conditions that were previously referenced.
These alarm-specific tag extensions can also be accessed by external applications, such as HMIs 114, in order to view and/or modify properties of selected alarm conditions or alarm sets. For example, the HMI can be configured to render interactive graphical objects—such as text boxes, graphical push buttons, or the like—that are linked to the controller tag's alarm extensions. As such, an operator can modify or view an alarm condition property via these interactive graphical objects.
The configurable properties of an alarm condition or alarm set can include a property that defines whether the alarm condition is to be enabled or disabled. This property can be set during initial configuration of the alarm condition (e.g., using device configuration application 604), but can also be modified during runtime, either programmatically or in response to a command received from an external application (e.g., an HMI 114). Enabling an alarm condition instructs the alarm processing component 408 to evaluate the alarm condition in the normal manner, and to generate an alarm notification in response to determining that the alarm condition has been satisfied. Disabling the alarm condition prevents evaluation of the alarm condition by the alarm processing component 408, such that no alarm notifications 902 will be generated for the alarm condition even if the condition is satisfied. The enabled/disabled property of an alarm condition can be set programmatically using a suitable control instruction within control program 608 that accesses the appropriate alarm condition setting (e.g., by writing to tag property Tank101.Level@alarms.HiLevel.enable). In an example scenario, the control program 608 may be written to set the alarm condition to be disabled during a transitional start-up period of a machine controlled by control device 402 (in order to prevent nuisance alarm notifications), and to be re-enabled after the machine reaches steady state operation.
Similar techniques for programmatically changing an alarm configuration can also be applied to alarm sets. Moreover, these programmatic operations can be applied to multiple levels of nested add-on instructions, and can also be generalized to support similar access from programs.
As noted above, embodiments of the industrial alarm system described herein allows sets of related alarm conditions to be grouped as alarm sets 802. Once these alarm sets 802 are defined, alarm processing component 408 allows interactive operations to be applied collectively to the related alarm conditions defined within the alarm set 802.
In an example scenario, an HMI 114 can include an interactive control graphic (e.g., a graphical pushbutton or other type of control) that sends a message to the control device 402 to initiate the selected group alarm operation 1102 on a selected alarm set 802. The message may be, for example, a request to acknowledge the active alarm conditions in the alarm set 802. Since the group alarm operation 1102 is directed to the alarm set 802 rather than a single alarm condition, alarm processing component 408 applies the operation 1102 to all alarm conditions within the alarm set 802.
Group alarm operation 1102 directed to selected alarm sets 802 can also originate from the control program 608 itself. In an example embodiment, an alarm set operation instruction 1104 can be included in the control program 608. Parameters of the alarm set operation instruction 1104 can include an identity of the alarm set 802 to which the operation is to be directed as well as the type of group alarm operation to be applied to the selected alarm set 802 (e.g., acknowledge, suppress, disable, etc.). When the instruction 1104 is executed by control program 608 in response to conditions defined by the programmer, the indicated group alarm operation 1102 is iterated over all alarm conditions defined in the alarm set 802. The alarm system allows alarm conditions to be added to or removed from the alarm set 802 (e.g., using device configuration application 604, as described above) without compromising the ability to perform group operations on the alarm conditions associated with the alarm set 802. That is, if a new alarm condition is added to the alarm set 802, subsequent group alarm operations 1102 applied to the alarm set 802 will be applied to the newly added alarm condition as well as the previously included alarm conditions.
By allowing grouped alarm conditions to be acted on collectively as an alarm set 802, alarm operations 1102—such as acknowledgements, alarm suppress operations, alarm disablement, etc.—can be performed on all alarm conditions within the alarm set 802 in response to a single input operation (e.g., a single HMI pushbutton interaction or a single execution of an alarm set operation instruction 608). This single input operation can access the alarm set 802 using a single programmatic reference directed to the alarm set 802, such that the programmatic reference causes the group alarm operation 1102 to be applied to all alarm conditions associated with the referenced alarm set 802.
Alarm processing component 408 can also generate rollup information 904 for each defined alarm set 802.
Rollup information 904 is accessible from external applications, such as HMIs 114. This allows rollup information 904 to be read by an HMI 114 and rendered on a suitable display screen. Since an alarm set 802 will typically comprise alarm conditions that relate to a common area of concern (e.g., a common production area or machine, a common industrial process, etc.), this rollup information 904 can convey useful summary information for a given aspect of a controlled industrial machine or process.
Rollup information 904 can also be accessed programmatically by user application code, including control program 608 as well as application code that is external to control device 402. During runtime, rollup information 904 can be monitored by applications executing on HMI 114 or other client devices communicatively connected to the control device 402.
In various embodiments, alarm configuration component 506 of control program development system can support at least two workflows for applying an alarm condition to a controller tag, which depend on the order in which a tag and an alarm condition is created during development of the control program project (represented by controller configuration data 606).
A configuration area 1308 includes other fields for entering additional configuration information for the alarm condition. For example, configuration area 1308 can include a set of condition fields that allow a user to define a condition that will trigger the alarm in terms of an alarm type (e.g., high alarm, low alarm, etc.), a controller tag against which the alarm will be evaluated, and an expression that defines the trigger condition for the alarm relative to the target tag. In the illustrated example, the TIMER.PRE (timer preset) tag property is set as the target tag, such that the alarm will be triggered when the timer accumulator value (TIMER_ACC) is greater than or equal to the timer preset value associated with the data tag. This condition is only intended to be exemplary, and it is to be appreciated that other conditions for triggering the alarm can be defined using alarm configuration display 1302.
Associated tags area 1312 lists a set of other tags that are captured synchronously when the alarm is activated. The values of these associated tags are sent as part of the alarm notification data 902 for the alarm conditions when the alarm condition is triggered. In the illustrated example, these associated tags include a Timer Preset value (TIMER.PRE) and a Timer Done property (TIMER.DN).
Configuration area 1308 can also include fields for entering delay settings (e.g., an ON delay and an OFF delay) defining a duration of time that the alarm condition must be satisfied before the alarm notification is triggered (the ON delay) and a duration of time that the alarm condition must be false before an active alarm notification will be cleared (the OFF delay). In some embodiments, configuration area 1308 can also include fields that allow the user to define a deadband for the alarm condition and a severity level, where the severity level may determine a manner in which the alarm condition is presented to a user via the HMI 114 (e.g., a frequency of reminders, a color code for the alarm message, etc.). A message field 1314 can allow the user to enter an alarm message to be rendered as part of the alarm notification data 902 when the alarm is active. The alarm configuration information can be saved as a reusable alarm configuration by selecting the OK button 1316.
After the alarm condition has been defined (named TM_ACC_1 in the present example), the alarm configuration component 506 will automatically apply the defined alarm condition to subsequently created data tags having the TIMER data type.
The previous example described a workflow for associating an alarm condition with a controller tag in which the alarm condition was defined first, and was then automatically applied to a new controller tag created subsequently. However, alarm conditions can also be defined and applied to controller tags created prior to definition of the alarm condition. For example, a new tag—MyTimer—may be created first using tag definition display 1322, as shown in
Although the previous examples applied reusable alarm conditions to tags having the TIMER data type, it is to be appreciated that similar techniques can be used to automatically apply user-defined alarm conditions to any other tag data type (e.g., COUNTER, user-defined data types, nested user-defined data types, etc.), as well as to control program function block types (e.g., PID function blocks), add-on instruction types, nested add-on instruction types, etc.
Alarm configuration component 506 also allows the user to modify an alarm condition after the alarm condition has been associated with one or more controller tags. When modifications are made to an existing alarm condition, the alarm modifications will be automatically applied to the controller tags with which the alarm condition was previously associated.
The industrial alarm configuration system described herein allows alarm conditions and alarm sets to be defined and evaluated within an industrial control device independently of the control program executing on the control device. These alarm conditions can be created, assigned to selected control tags, and modified as needed without the need to edit the control program. Once created, the alarm conditions and alarm sets can be assigned as needed to selected controller tags, AOIs, I/O modules, or other control objects, eliminating the need to individually re-enter the same alarm configuration information multiple times for multiple control objects. By allowing these alarm conditions to be grouped into alarm sets, operations or commands can be applied to multiple related alarm conditions using a single user-initiated or program-initiated action. These alarm sets also provide aggregated alarm summary information for the alarm conditions defined within each alarm set.
At 1404, the alarm condition defined at step 1402 is assigned to one or more controller tags defined for the industrial control configuration project. This can be achieved by assigning the alarm condition to an explicitly selected controller tag defined for the control project. Alternatively, the alarm condition can be assigned to system-defined or user-defined data type, which causes the alarm condition to be applied to any defined controller tags that are instances of the data type. Assigning the alarm condition to a controller tag causes the alarm condition to be a function of the state or value of that controller tag. For example, if the alarm condition specifies that an alarm notification is to be generated in response to a measured value exceeding a defined high limit value, assigning the alarm condition to a specified controller tag causes the value of the controller tag to be used as the measured value that determines whether the alarm condition is satisfied, such that the alarm notification will be generated when the value of the assigned controller tag exceeds the high limit defined by the alarm condition.
At 1406, the industrial control configuration project, including the alarm configuration and assignment information entered at step 1402 and 1404, are executed on the industrial control device. During execution, the alarm condition is evaluated relative to the value or state of its assigned controller tag to determine whether the defined alarm condition is satisfied. At 1408, a determination is made as to whether the alarm condition is satisfied. If the alarm condition is satisfied (YES at step 1408), the methodology proceeds to step 1410, where alarm notification data is generated indicating the alarm condition. This alarm notification data is accessible to applications external to the industrial control device (e.g., HMI devices or other types of client devices).
At 1506, a subset of the alarm conditions defined at step 1502 are grouped into an alarm set. The alarm set may include multiple alarm conditions that are deemed by the project developer to be related for the purposes of collective group alarm operations or commands.
At 1508, the industrial control configuration project—including the alarm condition and alarm set definitions—are executed on the industrial control device. At 1510, a determination is made as to whether a group alarm operation directed to the alarm set has been received. The group alarm operation may originate from a control program that executes on the industrial control device, or from an application that is external to the control device, such as an HMI terminal. The group alarm operation may be, for example, an alarm acknowledge command, a command to suppress or unsuppress the alarm conditions within the alarm set, a command to shelf or unshelve the alarm conditions, a command to disable or enable the alarm conditions, a reset command to be applied to the alarm conditions, or other such alarm operations.
If the group alarm operation is received (YES at step 1510), the methodology proceeds to step 1512, where the group alarm operation received at step 1510 is applied to all alarm conditions of the subset of alarm conditions included in the alarm set.
At 1610, rollup information for the subset of the alarm conditions included in the alarm set defined at step 1606 is calculated. This rollup information can include, but is not limited to, a total number of the alarm conditions in the alarm set that are active, a total number of active alarm conditions of the alarm set that are unacknowledged by an operator, an indication of the most severe or urgent alarm condition of all currently active alarm conditions within the alarm set, total counts of other current states of the alarm conditions included in the alarm set, or other such information. This rollup information can be determined by the industrial control device based on the alarm set definition specified at step 1606. At 1612, the rollup information generated at step 1610 is sent to a client device that is communicatively connected to the industrial control device.
At 1704, a controller tag is defined as part of the industrial control configuration project. The controller tag may be one of multiple controller tags to be included in a controller tag database, and which store digital or analog values generated and referenced by the control program or by the control device's I/O during runtime.
At 1706, a determination is made as to whether an alarm condition has been assigned to the controller tag defined at step 1704. The alarm condition is defined as part of the control configuration project, and defines a condition that is to trigger generation of an alarm notification. Assigning the alarm condition to the controller tag makes the alarm condition a function of the value of the controller tag.
If the alarm condition has been assigned to the controller tag (YES at step 1706), the methodology proceeds to step 1708, where properties of the alarm condition are rendered programmatically accessible as extensions of the controller tag. The properties of the alarm condition that can be accessed programmatically as a result of assigning the alarm condition to the controller tag can include, for example, a high limit or low limit setpoint that will trigger the alarm notification, a state of the controller tag that will trigger the alarm notification, a severity level to be assigned to the alarm condition, an ON delay or OFF delay value associated with the alarm condition, an alarm enable setting, an alarm disable setting, an alarm acknowledgement, or other such properties.
At 1710, the industrial control configuration project is executed on the industrial control device. At 1712, a determination is made as to whether a control program instruction included in the control program is executed that references an alarm extension of the controller tag. If a control program instruction that references the alarm extension of the controller tag is executed (YES at step 1712), the methodology proceeds to step 1714, where an operation is performed on the alarm property corresponding to the alarm extension in accordance with the control program instruction. For example, the control program instruction may change a high alarm limit property of the alarm instruction by writing the desired high limit value to a High Limit property extension of the control tag. Other properties of the alarm condition can also be modified in this manner.
Embodiments, systems, and components described herein, as well as industrial control systems and industrial automation environments in which various aspects set forth in the subject specification can be carried out, can include computer or network components such as servers, clients, programmable logic controllers (PLCs), automation controllers, communications modules, mobile computers, wireless components, control components and so forth which are capable of interacting across a network. Computers and servers include one or more processors—electronic integrated circuits that perform logic operations employing electric signals—configured to execute instructions stored in media such as random access memory (RAM), read only memory (ROM), a hard drives, as well as removable memory devices, which can include memory sticks, memory cards, flash drives, external hard drives, and so on.
Similarly, the term PLC or automation controller as used herein can include functionality that can be shared across multiple components, systems, and/or networks. As an example, one or more PLCs or automation controllers can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, Input/Output (I/O) device, sensor, actuator, instrumentation, and human machine interface (HMI) that communicate via the network, which includes control, automation, and/or public networks. The PLC or automation controller can also communicate to and control various other devices such as standard or safety-rated I/O modules including analog, digital, programmed/intelligent I/O modules, other programmable controllers, communications modules, sensors, actuators, output devices, and the like.
The network can include public networks such as the internet, intranets, and automation networks such as control and information protocol (CIP) networks including DeviceNet, ControlNet, and Ethernet/IP. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, CAN, wireless networks, serial protocols, near field communication (NFC), Bluetooth, and so forth. In addition, the network devices can include various possibilities (hardware and/or software components). These include components such as switches with virtual local area network (VLAN) capability, LANs, WANs, proxies, gateways, routers, firewalls, virtual private network (VPN) devices, servers, clients, computers, configuration tools, monitoring tools, and/or other devices.
In order to provide a context for the various aspects of the disclosed subject matter,
With reference to
The system bus 1818 can be any of several types of bus structure(s) including the memory bus or memory controller, a peripheral bus or external bus, and/or a local bus using any variety of available bus architectures including, but not limited to, 8-bit bus, Industrial Standard Architecture (ISA), Micro-Channel Architecture (MSA), Extended ISA (EISA), Intelligent Drive Electronics (IDE), VESA Local Bus (VLB), Peripheral Component Interconnect (PCI), Universal Serial Bus (USB), Advanced Graphics Port (AGP), Personal Computer Memory Card International Association bus (PCMCIA), and Small Computer Systems Interface (SCSI).
The system memory 1816 includes volatile memory 1820 and nonvolatile memory 1822. The basic input/output system (BIOS), containing the basic routines to transfer information between elements within the computer 1812, such as during start-up, is stored in nonvolatile memory 1822. By way of illustration, and not limitation, nonvolatile memory 1822 can include read only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable PROM (EEPROM), or flash memory. Volatile memory 1820 includes random access memory (RAM), which acts as external cache memory. By way of illustration and not limitation, RAM is available in many forms such as synchronous RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), Synchlink DRAM (SLDRAM), and direct Rambus RAM (DRRAM).
Computer 1812 also includes removable/non-removable, volatile/nonvolatile computer storage media.
It is to be appreciated that
A user enters commands or information into the computer 1812 through input device(s) 1836. Input devices 1836 include, but are not limited to, a pointing device such as a mouse, trackball, stylus, touch pad, keyboard, microphone, joystick, game pad, satellite dish, scanner, TV tuner card, digital camera, digital video camera, web camera, and the like. These and other input devices connect to the processing unit 1814 through the system bus 1818 via interface port(s) 1838. Interface port(s) 1838 include, for example, a serial port, a parallel port, a game port, and a universal serial bus (USB). Output device(s) 1840 use some of the same type of ports as input device(s) 1836. Thus, for example, a USB port may be used to provide input to computer 1812, and to output information from computer 1812 to an output device 1840. Output adapters 1842 are provided to illustrate that there are some output devices 1840 like monitors, speakers, and printers, among other output devices 1840, which require special adapters. The output adapters 1842 include, by way of illustration and not limitation, video and sound cards that provide a means of connection between the output device 1840 and the system bus 1818. It should be noted that other devices and/or systems of devices provide both input and output capabilities such as remote computer(s) 1844.
Computer 1812 can operate in a networked environment using logical connections to one or more remote computers, such as remote computer(s) 1844. The remote computer(s) 1844 can be a personal computer, a server, a router, a network PC, a workstation, a microprocessor based appliance, a peer device or other common network node and the like, and typically includes many or all of the elements described relative to computer 1812. For purposes of brevity, only a memory storage device 1846 is illustrated with remote computer(s) 1844. Remote computer(s) 1844 is logically connected to computer 1812 through a network interface 1848 and then physically connected via communication connection 1850. Network interface 1848 encompasses communication networks such as local-area networks (LAN) and wide-area networks (WAN). LAN technologies include Fiber Distributed Data Interface (FDDI), Copper Distributed Data Interface (CDDI), Ethernet/IEEE 802.3, Token Ring/IEEE 802.5 and the like. WAN technologies include, but are not limited to, point-to-point links, circuit switching networks like Integrated Services Digital Networks (ISDN) and variations thereon, packet switching networks, and Digital Subscriber Lines (DSL). Network interface 1848 can also encompass near field communication (NFC) or Bluetooth communication.
Communication connection(s) 1850 refers to the hardware/software employed to connect the network interface 1848 to the system bus 1818. While communication connection 1850 is shown for illustrative clarity inside computer 1812, it can also be external to computer 1812. The hardware/software necessary for connection to the network interface 1848 includes, for exemplary purposes only, internal and external technologies such as, modems including regular telephone grade modems, cable modems and DSL modems, ISDN adapters, and Ethernet cards.
What has been described above includes examples of the subject innovation. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the disclosed subject matter, but one of ordinary skill in the art may recognize that many further combinations and permutations of the subject innovation are possible. Accordingly, the disclosed subject matter is intended to embrace all such alterations, modifications, and variations that fall within the spirit and scope of the appended claims.
In particular and in regard to the various functions performed by the above described components, devices, circuits, systems and the like, the terms (including a reference to a “means”) used to describe such components are intended to correspond, unless otherwise indicated, to any component which performs the specified function of the described component (e.g., a functional equivalent), even though not structurally equivalent to the disclosed structure, which performs the function in the herein illustrated exemplary aspects of the disclosed subject matter. In this regard, it will also be recognized that the disclosed subject matter includes a system as well as a computer-readable medium having computer-executable instructions for performing the acts and/or events of the various methods of the disclosed subject matter.
In addition, while a particular feature of the disclosed subject matter may have been disclosed with respect to only one of several implementations, such feature may be combined with one or more other features of the other implementations as may be desired and advantageous for any given or particular application. Furthermore, to the extent that the terms “includes,” and “including” and variants thereof are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to the term “comprising.”
In this application, the word “exemplary” is used to mean serving as an example, instance, or illustration. Any aspect or design described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other aspects or designs. Rather, use of the word exemplary is intended to present concepts in a concrete fashion.
Various aspects or features described herein may be implemented as a method, apparatus, or article of manufacture using standard programming and/or engineering techniques. The term “article of manufacture” as used herein is intended to encompass a computer program accessible from any computer-readable device, carrier, or media. For example, computer readable media can include but are not limited to magnetic storage devices (e.g., hard disk, floppy disk, magnetic strips . . . ), optical disks [e.g., compact disk (CD), digital versatile disk (DVD) . . . ], smart cards, and flash memory devices (e.g., card, stick, key drive . . . ).
This application is a continuation of, and claims priority to, U.S. patent application Ser. No. 15/983,995, filed on May 18, 2018, and entitled “METHOD TO CONFIGURE CONTROL SYSTEM ALARMS BY ASSOCIATING ALARMS TO TAGS,” which claims priority to U.S. Provisional Application Ser. No. 62/516,872, filed on Jun. 8, 2017. The entireties of these related applications are incorporated herein by reference.
| Number | Name | Date | Kind |
|---|---|---|---|
| 10410493 | Rischar | Sep 2019 | B2 |
| Number | Date | Country | |
|---|---|---|---|
| 20190355228 A1 | Nov 2019 | US |
| Number | Date | Country | |
|---|---|---|---|
| 62516872 | Jun 2017 | US |
| Number | Date | Country | |
|---|---|---|---|
| Parent | 15983995 | May 2018 | US |
| Child | 16530421 | US |
