SYSTEMS AND METHODS FOR QUEUING AN ACTION IN INDUSTRIAL AUTOMATION SYSTEMS

Abstract

The subject invention relates to a system and methodology facilitating automated manufacturing processes in a regulated industrial controller environment, wherein operator commands are tied to one or more signature requirements before the requested commands take effect in a batch system. In one aspect, a system is provided for signature processing in an industrial control environment. The system includes a queuing component to hold a pending request for an action. A signature component then determines when an electronic signature is completed for the action, wherein a batch processor executes the action from the queuing component after the electronic signature is completed. A policy component can be provided to define one or more conditions for completing the electronic signature.

Description

TECHNICAL FIELD

The subject invention relates generally to industrial control systems, and more particularly to a system and methodology that enables industrial automation equipment to be regulated according to applicable standards via the employment of electronic signatures, wherein operator actions requiring signature verification are queued pending outcome of a completed signature or cancellation thereof.

BACKGROUND OF THE INVENTION

Industrial controllers are special-purpose computers utilized for controlling industrial processes, manufacturing equipment, and other factory automation, such as data collection or networked systems. Controllers often work in concert with other computer systems to form an environment whereby a majority of modern and automated manufacturing operations occur. These operations involve front-end processing of materials such as steel production to more intricate manufacturing processes such as automobile production that involves assembly of previously processed materials. Often such as in the case of automobiles, complex assemblies can be manufactured with high technology robotics assisting the industrial control process.

In many automated processes, including the basic production of commodities such as food, beverages, and pharmaceuticals, complex state logic is often designed and programmed by Systems Engineers or provided in some cases by automated equipment manufacturers. This logic is often programmed with common PLC ladder logic or higher level languages supported by Sequential Function Charts. Sequence logic can be employed for a plurality of tasks such as material movement and conveying operations, packaging operations, or as part of an assembly process itself, wherein various stages of an assembly are sequenced from stage to stage until a final assembly occurs. As can be appreciated, much planning and design is required to implement an automated production process that can involve hundreds of machines, computers, and program logic to facilitate proper operation of the respective sequences.

In modern systems, many layers of regulation are now being imposed on automated industries to ensure compliance to applicable standards. To document that these requirements are being adhered to, often one or more signatures are required which in some systems may be more than merely signing a journal record or document but, in increasing circumstances these procedures have become electronic. For instance, if a customer in an FDA regulated industry desires to use electronic signatures in place of handwritten signatures, they must do so in accordance with 21 CFR Part 11. In some existing systems, electronic signatures are only offered in association with report parameter verification in procedural phases, verification of procedural steps, and confirmation of batch and phase commands. However, these signatures may be lacking several key features required under 21 CFR Part 11. For example, the meanings of the signatures are not presented to the signers nor recorded, and in some electronic event journals it may be difficult or impossible to determine if an electronic signature was properly obtained or not.

Some of the notable aspects of 21 CFR Part 11 include:

(a) Signed electronic records shall contain information associated with the signing that clearly indicates all of the following:

• • (1) The printed name of the signer;
  • (2) The date and time when the signature was executed; and
  • (3) The meaning (such as review, approval, responsibility, or authorship) associated with the signature.

(b) The items identified in paragraphs (a)(1), (a)(2), and (a)(3) of this section shall be subject to the same controls as for electronic records and shall be included as part of any human readable form of the electronic record (such as electronic display or printout).

In addition to the components mentioned above, customer requirements include the ability to specify one or two signers for each signature, to specify security requirements for each signer, and to specify a comment requirement for each signer.

Journaling requirements are further described in the following 21 CFR Part 11 excerpt:

“Electronic signatures and handwritten signatures executed to electronic records shall be linked to their respective electronic records to ensure that the signatures cannot be excised, copied, or otherwise transferred to falsify and electronic record by ordinary means.”

In view of the above, many modern industrial automation systems are not equipped to process, record, and document required signature activities. For instance, in a typical factory setting, process steps and operator actions requiring possible signature authentication are highly distributed throughout various locations in the factories. Attempting to manage such activities from various locations can be a challenge even for the most sophisticated of automation systems. Moreover, current systems that may utilize some form of electronic process validation do not predicate such validation on the actual verification of a signature before continuing further system processing.

SUMMARY OF THE INVENTION

The following presents a simplified summary of the invention in order to provide a basic understanding of some aspects of the invention. This summary is not an extensive overview of the invention. It is intended to neither identify key or critical elements of the invention nor delineate the scope of the invention. Its sole purpose is to present some concepts of the invention in a simplified form as a prelude to the more detailed description that is presented later.

The subject invention relates to a system and methodology to automatically manage and control electronic signature activities in accordance with a distributed industrial control system. In one aspect, various operator actions such as commands to change operations within a batch processing system are conditioned upon electronic signature events (e.g., receiving and validating signature data from a user). Various conditions can be prescribed by a policy component that tag differing operator actions as requiring a completed electronic signature before the requested action takes place. A queuing component holds pending action requests from the batch processing system until the signature is completed or cancelled by an operator. Multi-operator conditions can also be specified, wherein signature data is supplied by two or more operators before a pending action held in the queuing component can be further processed or executed by the batch processing system.

In one example, if a user issues a command (e.g., START, STOP or HOLD) to a batch and that command has been configured to require a signature, the batch processing system queues the command and generates a signature (e.g., dialog interface to retrieve signature data from the user). The signature can then be completed or cancelled. If the signature is completed such as receiving a valid username and password form the user, the batch processing system executes the command, and if the signature is cancelled, the batch processing system removes the command from the queue and performs other processing. In addition to techniques such as password data being supplied to complete signature requirements, the subject invention can also employ various biometric technologies to complete the signatures and enable subsequent execution of requested actions.

The following description and the annexed drawings set forth in detail certain illustrative aspects of the invention. These aspects are indicative, however, of but a few of the various ways in which the principles of the invention may be employed and the present invention is intended to include all such aspects and their equivalents. Other advantages and novel features of the invention will become apparent from the following detailed description of the invention when considered in conjunction with the drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a schematic block diagram that illustrates a queuing architecture for signature processing in accordance with an aspect of the subject invention.

FIG. 2 illustrates a batch system for signature processing in accordance with an aspect of the subject invention.

FIG. 3 illustrates a policy component for signature in accordance with an aspect of the subject invention.

FIGS. 4 and 5 illustrate example signature processes in accordance with an aspect of the subject invention.

FIGS. 6 and 7 illustrate example user interfaces for signature processing in accordance with an aspect of the subject invention.

FIG. 8 illustrates biometric applications for generating signature data in accordance with an aspect of the subject invention.

DETAILED DESCRIPTION OF THE INVENTION

The subject invention relates to a system and methodology facilitating automated manufacturing processes in a regulated industrial controller environment, wherein operator commands are tied to one or more signature requirements before the requested commands take effect in a batch system. In one aspect, a system is provided for signature processing in an industrial control environment. The system includes a queuing component to hold a pending request for an action. A signature component then determines when an electronic signature is completed for the action, wherein a batch processor executes the action from the queuing component after the electronic signature is completed. A policy component can be provided to define one or more conditions for completing the electronic signature. Signature completion can include receiving data from distributed interfaces including typed or spoken names and security information such as passwords. Other forms of signature data can be communicated from one or more biometric devices that generate such data based on unique characteristics of users.

It is noted that as used in this application, terms such as “component,” “queue,” “object, ” “class,” and the like are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software in execution as applied to an automation system for industrial control. For example, a component may be, but is not limited to being, a process running on a processor, a processor, an object, an executable, a thread of execution, a program and a computer. By way of illustration, both an application running on a server and the server can be components. One or more components may reside within a process and/or thread of execution and a component may be localized on one computer and/or distributed between two or more computers (e.g., via data packets and signals between the computers), industrial controllers, and/or modules communicating therewith.

Referring initially to FIG. 1, a system 100 illustrates a queuing architecture for electronic signature processing in accordance with an aspect of the subject invention. A queuing component 110 receives one or more actions 120 from remote system interfaces interacting with a batch processor 130 (or from process steps associated with the batch processor). The actions 120 include commands for change within the batch processor 130 such as start, stop, hold, abort, pause, and so forth which are described in more detail below. Other actions 120 include requests for process changes such as a change to a variable. A policy component 140 maps respective actions to a signature requirement. Thus, if an action 120 such as an abort command is tagged as requiring a signature by the policy component 140, the queuing component 110 will hold the requested action 120 or command until a signature component 150 receives a valid signature (or signatures) from the interfaces that issued the action. Signature requests can be generated via the signature component 150 by operator commands, automated phase logic uploading values outside of defined ranges, operators entering values outside of defined ranges, or with respect to other automated requirements of an automated process. After signatures are generated, they are managed centrally via the signature components 150, with distributed client applications interacting with the signature components as described below with respect to FIG. 2.

In general, the signature component 150 determines when a signature event or requirement is to be executed and then proceeds to automatically verify whether or not the requirement for signature has been met. Thus, the policy component 140 determines what type of actions 120 require signatures and the signature component executes a signature verification procedure for the actions tagged as requiring such signatures. Other features of the policy component 140 include the ability to link multiple signature requirements to an action 120. For instance, a command such as “Stop” could be configured to require three signatures by the policy component 140. Thus, when the “Stop” command is initiated by an operator, the command would be queued by the queuing component 110 until all three signatures were executed. As will be described in more detail below with respect to FIG. 3, various logical expressions can be formed for multiple signature conditions determine whether or not all or a subset of the multiple signatures are required before the action 120 can be executed.

A signature and its component parts can be configurable for any operator interaction with a running batch, however, signatures initiated by a process-connected device can not be canceled, whereas signatures initiated by an operator interaction can be canceled. In one aspect, signatures can be considered transactions—note that until the transactions are completed the actions they correlate to are not performed. Thus, signatures can be held active until they are completed, or, in some cases, canceled. Interactions with signatures, successful or not, are journaled (i.e., written to the batch record). Also, if a signature requires multiple signoffs, each signoff can be completed on different workstations. Before proceeding with a discussion of FIG. 2, the following definitions may be employed:

Electronic Signature

An electronic representation of a signature, including associated data. Can include one or more signoffs. Associated data includes meanings for the signoffs, comments, security requirements, and timestamps.

Signoff

A component of an electronic signature in which a user enters his username and password and optionally a comment. An electronic signature can require one or two signoffs or more.

Signoff Meaning

A short phrase describing the meaning attached to a given signoff. For example, “Done By” or “Checked By”.

Signature List

A list of pending signatures and their related commands, report parameters, etc. maintained on a Batch Server or processor.

Signature List UI

User interface for accessing signatures.

Signature Template

A collection of data to define a signature—number of signoffs, signoff meanings, signoff security requirements, and signoff comment requirements. Signature templates can be defined centrally, and can be referred to when defining signature requirements.

Cancel a Signature

When a user cancels a signature, this signals the batch system that the signature will not be completed. The Batch system will then let the originator of the signature know that it has been canceled so that it may take appropriate actions. Likely reasons for canceling a signature include incorrect data associated with the signature and the user desiring to prevent a command associated with a signature to complete.

Referring now to FIG. 2, a system 200 illustrates signature processing via a batch server in accordance with an aspect of the subject invention. The system 200 includes a batch server 210 for processing recipes or programs that are employed to manufacture a plurality of differing products in an automated industrial environment. The server 210 generally operates with one or more control systems 220 via network connections 230 (wireless and/or wired) to the server 210. Such network connections can include local factory networks such as ControlNet, DeviceNet or Ethernet and can include communications to remote systems such as over the Internet, for example. The control systems 220 can include programmable logic controllers, I/O modules, communications modules and so forth. In order to facilitate signature processing, one or more distributable signature components 240 are migrated to various locations across the factory. These components can include signature templates, Application Programming Interfaces (APIs), Schemas, and so forth that drive respective user interface components 250 to interact with various users or operators associated with the control systems 220 and/or batch server 210. The user interface 250 interacts with operators to control a process and mange signatures in accordance with the subject invention.

At 260, one or more operator actions can be input that may affect operations of the system 200. For instance, an operator may request to change a parameter or system variable. This request is fed back to the server 210, wherein a signature and verification component 270 determines whether or not the changed parameter requires signature verification for such request. These determinations are described can include policy or rule determinations and/or limit testing on the changed value. If the parameter change requires a signature, the batch server 210 initiates a signature verification procedure, wherein the operator (or operators) is required perform one or more signature requirements 280 at the user interface 250. These requirements 280 can include such procedures as entering a user name and password, for example. After entering the signature data, the data is transferred to the server where the data is verified by the signature and verification component 270. When the data has been verified, automated processes occur such updating a regulation record with the operator's electronic signature. After verification, the actual parameter change can be initiated on the batch server 210 and/or control system 220. At 290, one or more automated signature events (non-operator initiated) can occur such as an event that is detected during a recipe phase or step that requires signature verification and validation before proceeding with other phases or steps. Upon triggering of the automated event 290, the user can be directed to complete a signature requirement at 280 via the user interface 250.

Referring to FIG. 3, a policy component 300 for signature processing is illustrated in accordance with an aspect of the subject invention. The policy component 300 links signature requirements to respective commands such as start, stop, hold, abort, and so forth. Also, signature requirements can be linked to process variables or parameters such that if an operator attempts to change the parameter a request for signature can be generated. Other non-operator actions can also be configured such as process phases or steps that trigger a signature requirement. A selection component 310 (e.g., user interface) is employed to enable users to set which conditions an actions will trigger a signature to be generated. For instance, a start command may be selected to cause a signature to be generated whenever an operator issues a start command. A pause command in contrast and depending on the application may have no such requirement for signature and is thus not configured to generate a signature by the selection component 310.

Other conditions 320 that can be mapped relate to the requirement for an action or command to have multiple signatures before the signature can be completed. Thus, in a multiple signature configuration, a command such as hold could be configured to require two signoffs before the command can be removed from an associated queue and executed by a batch server. After the conditions and actions 320 have been identified as requiring a signature, one or more action/condition tags 330 are set representing the type of actions and respective joint signature requirements. Upon execution of any of these actions having a corresponding tag, the action will be queued, a signature requirement generated, and subsequently executed if the signature requirements are met. It is to be appreciated that the conditional requirements for multiple signatures can be set according to various logical expressions. For instance, a command having a multiple signature requirement can be configured in a logical AND arrangement to only be executed unless all parties to the signature requirement complete the signature. Another arrangement can be set in a logical OR arrangement whereby if any one of the parties configured for the signature signoff, the associated command or parameter change can then be executed. As can be appreciated, other logical expressions are also possible. Furthermore, hierarchical groupings 340 of expressions are possible. This could include complex expressions such as “Command 1 only requires a signature if Command 1 proceeds Command X.”

FIGS. 4 and 5 illustrate example processes 400 and 500 for signature processing in accordance with an aspect of the subject invention. While, for purposes of simplicity of explanation, the methodology is shown and described as a series of acts, it is to be understood and appreciated that the present invention is not limited by the order of acts, as some acts may, in accordance with the present invention, occur in different orders and/or concurrently with other acts from that shown and described herein. For example, those skilled in the art will understand and appreciate that a methodology could alternatively be represented as a series of interrelated states or events, such as in a state diagram. Moreover, not all illustrated acts may be required to implement a methodology in accordance with the invention.

Referring to FIG. 4, a process 400 illustrates generalized signal and condition processing in accordance with an aspect of the subject invention. Proceeding to 410, one or more actions are defined that may need signature verification. These can include specific parameters or variables, various system commands, and/or system processes such as a phase triggered events that can lead to a request for signature being directed to the operator. At 420, one or more signature conditions are defined. This can include policies that are configured to tag a particular command or variable as needing a signature. Also, conditions can be set whereby more than one signature is required for a given command or parameter. At 430, system processes are monitored for respective commands (e.g., execute batch operations). At 440, a determination is made as to whether or not any signatures have completed from pending signature requests stored in the queue. If not, the process adds any new pending actions to the queue and proceeds back to 430. If a signature has completed or canceled at 440, the signature request relating to the pending action in the queue is cleared from the queue at 460 and executed if not previously canceled. The process then proceeds back to 430.

Turning to FIG. 5, a process 500 illustrates signature generation and verification in response to a command or parameter change in accordance with an aspect of the present invention. The process 500 describes signatures and related processing that result from an operator entering a command such as stop start or hold that has been previously been configured to require signature verification. Also, the process 500 applies if the operator attempts to change a system parameter or variable that has been tagged as requiring signature verification. Proceeding to 512, a user attempts a batch command or changes a recipe parameter value. At 514, if the command or parameter change does not require signatures, the process proceeds to 516 to execute the command or implement the parameter change. If a command or parameter change requires a signature at 514, the process proceeds to 518, where the command or parameter change is queued and a signature verification procedure is initiated. At 524, a user enters sign-off data for the verification. At 528, a determination is made as to whether or not a user desires to cancel the verification. If so, the process proceeds to 532 where the signature cancellation is logged, an error is returned, and the command or parameter change request is removed from the queue.

Proceeding back to the determination at 528, and if the user does not cancel the previously queued command or parameter request, the process proceeds to verify a sign-off for a first user at 538. At 542, a determination is made as to whether or not the verification succeeded. If not, the process logs a verification failure at 544 and proceeds back to receive new sign-off data. If the verification is a success at 542, the process proceeds to 548 to log that a successful sign-off has occurred. At 550, a determination is made as to whether one or more sign-offs is required. If not, the process proceeds to 552 and clears the request for the signature. If another sign-off is required, the process proceeds to the acts represented at 554 to request signature verification from a subsequent user. These acts are similar to the acts represented at 524, 528, 538, 542, 548, and 548. As can be appreciated, sign-offs for a given signature requirement can occur with more than two users or other logical groupings of signatures as described above. After execution of the clear signature request at 552 the process ends at 516.

Before proceeding with a discussion of FIGS. 6 and 7, it is noted that example user interfaces are shown that can include various display and input capabilities. Thus, the user interface can be implemented as a Graphical User Interface (GUI) or interface application to interact with the systems previously described. This can include substantially any type of application that sends, retrieves, processes, and/or manipulates the various signature data and processes described herein. For example, such user interfaces can also be associated with an engine, controller, batch processor, web service, web site, and web browser although other type applications can be utilized. For example, depending on the detected recipe phase, the user interface may be converted from a normal operating interface to a guided sequence of instructions. This may be especially beneficial when all or portions of the recipe have changed and/or new procedures are to be installed. It is also noted that the user interface can be adapted to direct the operator to remote locations for respective information. For example, the interfaces can include hyperlinks for directing the operator to a remote web site, wherein further instructions are provided (e.g., mouse click at user interface automatically brings up web site).

The user interface can also include a display having one or more display objects including such aspects as configurable icons, buttons, sliders, input boxes, selection options, menus, tabs and so forth having multiple configurable dimensions, shapes, colors, text, data and sounds to facilitate operations with the systems and processes described herein. In addition, the user interface can also include a plurality of other inputs or controls for adjusting and configuring one or more aspects of the subject invention. This can include receiving user commands from a mouse, keyboard, speech input, web site, remote web service and/or other device such as a camera or video input, biometric device to affect or modify operations of the user interface.

Turning to FIG. 6, an interface 600 illustrates an example policy configuration in accordance with an aspect of the subject invention. Batch and phase command verification policies can be configured as part of an area model that describes class objects that relate to actual equipment for executing a batch. For each command, the user selects whether or not a signature is required for that particular command, and if so, which signature template is required. In this aspect, the interface 600 enables users to select commands that tag (e.g., select check-box) whether or not a particular command requires a signature. If a command is selected, when the respective command is executed by the batch server, the command will be queued by the batch server and a signature verification using the selected signature template will be performed with the user. After the verification is completed or the command canceled, the command will be removed from the queue with the batch server then executing the command if not previously canceled. As noted above, signature policies can also include associating a signature requirement with parameter changes, variable changes, program changes, process changes and so forth that affect how the system performs. Other actions or commands depicted on the interface 600 include commands such as start, hold, restart, abort, stop, reset, manual, pause, resume, acknowledge, and disconnect, for example. Still yet other commands include auto, download, semi-auto, add batch, remove batch, step change, clear failures, acquire, release, and bind, for example.

FIG. 7 is an example interface 700 illustrating a signature completion dialog in accordance with an aspect of the subject invention. When a batch or phase command is attempted that requires a signature, that command can be put into a pending state via the queue described above, and a signature will be placed on a signature list. In addition, a dialog will such as shown in the interface 700 will be presented to the operator to complete the signature. The interface 700 shows a batch for which a Hold has been requested. In this case, a Hold command has been configured to require a single signature, wherein the dialog includes inputs to enter a user ID, a password and comment, if desired at 710 to complete the signature request issued from the batch server in response to the aforementioned Hold command.

FIG. 8 illustrates example biometric applications 800 for completing signatures in accordance with an aspect of the subject invention. Biometric authentication devices and applications 800 can be employed to collect signature data in order to validate users' identities based on unique biological characteristics such as voice, fingerprint, or facial characteristics, for example. In one aspect, a fingerprint recognition system 810 can be utilized to gather signature data to be subsequently used for validation purposes at the batch system. These systems can include Integrated Circuit IC-based devices to measure skin capacitance in order to develop an image of a fingerprint's various characteristics. For instance, some fingerprint sensors utilize solid-state capacitance sensing to collect fingerprint data. When a user places a finger on the IC sensor, the finger acts as one of the plates of a capacitor. The other plate, on the surface of the sensor, is a silicon chip that includes a plurality of capacitor plates. The capacitor sensing plates create an image of the finger's ridges and valleys. This information is then converted to a video signal, which is fed to an algorithm that creates a template of the image. The template-not the image of the print itself-verifies the user on subsequent logins. In some systems, IC-based fingerprint readers include a rectangular fingerprint-detection surface called the sensor matrix. This is an active antennae array of more than sixteen thousand elements that are protected by a scratch- and impact-resistant transparent coating. The sensor matrix is surrounded by an annular drive ring, which transmits a small signal that the individual antennae elements can detect.

Software can be provided, which operates in conjunction with associated hardware devices, analyzes below the outer layer of the skin (the epidermis) to the living layer below where the unique ridge and valley patterns of the fingerprint originate. When a user places a finger on the chip's detection surface, the drive ring couples a small signal onto the finger's living sub-dermal layer. This signal creates a digital pattern that reflects the fingerprint's unique underlying structure. Using “under-pixel” amplifiers and other signal conditioners, these systems can manage and combine the output of thousands of individual sensor elements to form an accurate, undistorted image of the fingerprint. The image is then rendered into a template, which is used for future verification.

In some cases, biometric applications 800 can be combined with smart cards and card keys. For example, some systems have integrated a fingerprint reader onto an ID badge. The half-inch-thick badge communicates via infrared signals with a badge reader, similar to access-control cards used in many organizations to open doors. Users may be required to first enroll their fingerprint in the system, creating a template of their print that's stored on the card. In other systems, the template of the user's fingerprint is stored in memory on the card during the enrollment process, which matches the template to the user's private encryption key. Then, when the user puts the smart card into the reader and touches a finger to its sensor, the key authenticates the user.

At 820, hand recognition systems can be employed. Hand-geometric scanners are ideal for highly secure, high-traffic environments, including server rooms. These systems are accurate, with low False Rejection Rates (FRRs)—that is, incidences of turning away valid users. Low FRRs are important for several reasons, most notably to reduce user frustration and discomfort with the biometric device. Hand-geometry readers take a three-dimensional picture of the hand, measuring characteristics such as finger length, thickness, and hand surface area. In all, some systems take more than 90 measurements, which are then converted into a data template for later comparison. The template can be stored locally, on individual hand scanners, or in a central database.

At 830, face recognition applications can be employed to gather signature data. Face-scanning technology is well suited for a number of applications in which other biometric technologies are unusable. This technology uses distinctive features or characteristics of the human face—such as eyes, nose, and lips—to verify an individual's identity. Many of these systems employ mathematical algorithms to help identify users.

One advantage of facial scanning is that it can be used in conjunction with the types of cameras shipped standard with personal computer (PCs).

At 840, voice recognition can be employed to generate signature data. Voice-systems benefit from economic factors similar to those of face-recognition systems. These systems can be used with equipment (microphones, for example) that is standard with many PCs, so they benefit from a low cost of ownership. Voice-authentication systems are more apt to be integrated into telephony applications than used for network logons. Voice-authentication systems typically work together with voice-recognition. That is, the authentication system first recognized the context of the words spoken, then authenticate the individual. During enrollment and a subsequent identification process, voice-authentication systems make use of “features of the voice that are unique to each individual,” such as pitch, tone, and frequency.

At 850, retinal recognition can also be employed as a biometric application of the subject invention. The human retina generally offers the “most unique biometric pattern. Not even identical twins have the same blood vessel pattern at the back of the eye.

Some systems employ retina-scanning technology that reflects an infrared beam of light on the blood vessels on the retina, collecting views from several different angles. As with other biometric devices, the information collected is parsed with various algorithms to produce a data template that uniquely identifies the respective person.

What have been described above are preferred aspects of the subject invention. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing the present invention, but one of ordinary skill in the art will recognize that many further combinations and permutations of the present invention are possible. Accordingly, the present invention is intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims.

Claims

1. A system that facilitates regulation of an automated manufacturing process, comprising: a batch server configured to process a program, comprising a command, to facilitate execution of the automated manufacturing process;a signature component configured to identify that the command is associated with a request for an electronic signature; anda queuing component configured to prohibit execution of the command until the electronic signature is received.

2. The system of claim 1, wherein the request includes reception of at least one of a username, a password, or a comment via a user interface.

3. The system of claim 1, wherein the batch server is further configured to send the request for the electronic signature via a user interface.

4. The system of claim 1, further comprising, a verification component configured to authenticate the electronic signature received via a user interface, wherein the batch server is configured to facilitate execution of the command in response to a successful authentication of the electronic signature.

5. The system of claim 4, wherein the batch server is further configured to operate with one or more control systems and execute the command via the one or more control systems, in response to the successful authentication of the electronic signature.

6. The system of claim 1, wherein the signature component is further configured to identify that the command is associated with the request based on a predefined rule.

7. The system of claim 1, wherein the signature component is further configured to identify that the command is associated with the request based on a limit test of a parameter value, which is changed by execution of the command.

8. The system of claim 1, wherein the request includes reception of at least two electronic signatures from disparate users.

9. The system of claim 1, further comprising, one or more distributable signature components, residing at different locations and coupled to the batch server, that are configured to at least one of define, manage, modify, or delete the electronic signature by utilization of at least one of a signature template, an application programming interface (API), or a schema.

10. The system of claim 1, wherein the command is initiated by at least one of a user or an automated event.

11. The system of claim 1, wherein the queuing component comprises a queue that is configured to store the command until the electronic signature is received and verified.

12. A method to facilitate regulation of an automated manufacturing process, comprising: displaying, via a graphical user interface, a list of one or more actions relating to the automated manufacturing process;receiving a first input, via the graphical user interface, for selecting a set of the one or more actions for which an electronic signature is to be requested before processing;receiving a second input, via the graphical user interface, for specifying data associated with the electronic signature associated with one of the set of the one or more actions; andqueuing a request for the one of the set of the one or more actions at run-time, pending receipt and verification of the data.

13. The method of claim 12, further comprising, defining one or more conditions that trigger a query for the data in response to receiving the one of the set of the one or more actions at a batch processor.

14. The method of claim 13, further comprising, receiving the data in response to the query.

15. The method of claim 14, further comprising: verifying the data; andexecuting the one of the set of the one or more actions in response to the verifying being successful.

16. The method of claim 15, further comprising logging a result of the verifying.

17. The method of claim 14, wherein the receiving includes receiving at least one of a phrase indicative of a meaning of an electronic signature.

18. A computer readable storage medium comprising computer-executable instructions that, in response to execution by an industrial automation system, cause the industrial automation system to perform operations, comprising: identifying, within a program being processed by a batch processor, an action that requests verification of an electronic signature associated with the action, prior to execution;retrieving and verifying data, associated with the electronic signature, that is predefined by a user; andprohibiting execution of the action until the verifying is determined to be successful.

19. The computer readable storage medium of claim 18, the operations further comprising, displaying a signature completion dialog window that enables input of the data.

20. The computer readable storage medium of claim 19, wherein the verifying includes performing biometric authentication.