Module arbitration and ownership enhancements

CROSS REFERENCE TO RELATED APPLICATIONS

0001This application claims the benefit of U.S. Provisional Patent Application No. 60/862,403, filed on Oct. 20, 2006, entitled MODULE CONTROL AND STATE PROPAGATION. This application also claims the benefit of U.S. Provisional Patent Application No. 60/890,973, filed on Feb. 21, 2007, entitled MODULE CONTROL AND STATE PROPAGATION. The entireties of the aforementioned applications are incorporated herein by reference.

TECHNICAL FIELD

0002The claimed subject matter relates generally to industrial control systems and more particularly to module class components and arbitration of use and ownership of shared industrial resources.

BACKGROUND

0003One type of industrial control process is referred to as a batch process, which involves subjecting raw materials to processing steps using one or more pieces of equipment to produce a “batch” of product. Efforts to automate batch processing have led to the formation of standards committees by members of industries involved in batch processing and suppliers of batch processing equipment, among others. The general purpose of these standards committees has been to define uniform standards for automated batch processing. One such standard has been promulgated by the International Society for Measurement and Control, an international organization concerned with issues of process control. This standard is entitled Batch Control Part 1: Models and Terminology and is often referred to as the ISA S88.01-1995 standard (or “S88” for purposes of this application).

0004The S88.01 standard defines models of equipment and procedures for use in automated batch processes, as well as terminology for use in referring to those models and their elements. The S88.01 standard defines a “batch process” as a process that leads to the production of finite quantities of material by subjecting quantities of input materials to an ordered set of processing activities over a finite period of time using one or more pieces of equipment. A “batch” is defined as the material that is being produced or has been produced by a single execution of a batch process.

0005Batch-processing equipment (i.e., controllable elements such as valves, heaters, mixers, and so forth) is operated according to procedures to produce a batch. Generally, such equipment is referred to synonymously as equipment, equipment modules, processing equipment, or physical elements. The procedures to operate such physical elements are often referred to by the S88.01 standard as the “procedural model.” According to the S88.01 standard, the procedural model is structured as a hierarchical ranking of procedures, with the highest level encompassing each of the lower levels, the next highest level encompassing each of the levels below it, and so on. Typically, the levels of the S88.01 procedural model of a particular application are, in descending order: the “procedure;” the “unit procedure;” the “operation;” and the “phase.”

0006The term “procedural element” generally refers to components that employ any of the levels of the S88.01 procedural model, not just to those of the “procedure” level or any other single level of the procedural model. The highest-level procedural element of interest is referred to as a procedure, which is made up of one or more unit procedures. Each unit procedure is in turn made up of one or more operations, which are each in turn made up of one or more phases. The S88.01 procedural model does not preclude definition and use of other hierarchical levels, nor does it require that each level be present in particular applications. Rather, the standard is intended to provide a broad, standardized model for describing the procedures followed in automated batch-process control.

0007Today, industrial module class components often compete for resources within a plant. For instance, three equipment modules may need to control a common valve that supplies materials to the respective equipment controlled by the modules. This competition for shared resources often required a designer to construct arbitration code for each module in order to have access and control of the valve at a given time. In addition, the arbitration code can often be particular to a module or to a shared resource, requiring additional code to be crafted and tailored to other industrial components. Furthermore, timing/synchronization problems often had to be debugged on site after implementing such arbitration code. A common result of these requirements is an increase in time needed to prepare an industrial process for production, and an increase in overhead costs associated with the industrial process.

SUMMARY

0008The 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.

0009Arbitration functionality is provided within a given module in an industrial setting in order to mitigate custom arbitration coding requirements. A unique identifier is associated with each module, where the identifier is employed for arbitration between the modules. For example, if three equipment modules request a common valve, the first request received could lock out the other two requests until the first was processed. All three modules can be apprised of the competing ID's that are currently accessing a resource. As can be appreciated various arbitration algorithms can be provided.

0010According to additional aspects, arbitration can be located in each control module (or other type module, e.g., arbitration scheme devised for equipment level arbitration) of an industrial process. In addition, an ownership mechanism can be placed in each control module, for example. The ownership mechanism enables higher level objects (e.g., equipment modules) to evaluate a state of arbitration within a control module. If the control module is arbitrated, and is interlocked for use, an equipment module (e.g., able to determine its own identity) can evaluate a current owner of the control module. If an equipment module making the evaluation determines it is the owner of the control module, the equipment module (through its arbitrated control mechanism) can be permitted to command the control module. By leveraging S88 (or other) standard, a hierarchical arbitration scheme can be provided which can be embedded within each module.

0011To 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 that 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.

BRIEF DESCRIPTION OF THE DRAWINGS

0012<figref idref="DRAWINGS">FIG. 1</figref> depicts a block diagram of an example system that provides arbitration for industrial module class components for an industrial automation system.

0013<figref idref="DRAWINGS">FIG. 2</figref> illustrates a block diagram of an example system that provides for arbitration as a function of ownership associated with one or more industrial resources.

0014<figref idref="DRAWINGS">FIG. 3</figref> depicts a block diagram of an example system that can monitor ownership of an industrial resource and notify system components of the ownership.

0015<figref idref="DRAWINGS">FIG. 4</figref> depicts a block diagram of an example system that can process, queue and update control requests for an industrial resource.

0016<figref idref="DRAWINGS">FIG. 5</figref> illustrates an example flowchart of a methodology for arbitrating access to industrial resources in accordance with one or more embodiments.

0017<figref idref="DRAWINGS">FIG. 6</figref> depicts an example flowchart of a methodology for managing control requests for an industrial resource according to particular embodiments.

0018<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example flowchart of a methodology for updating ownership of a resource and arbitrating control to an owning module.

0019<figref idref="DRAWINGS">FIG. 8</figref> illustrates an example flowchart of a methodology for generating a request to control an industrial resource in accordance with one or more embodiments.

0020<figref idref="DRAWINGS">FIG. 9</figref> depicts an example flowchart of a methodology for arbitrating control of an industrial resource according to one or more aspects.

0021<figref idref="DRAWINGS">FIG. 10</figref> is a diagram illustrating module attributes.

0022<figref idref="DRAWINGS">FIG. 11</figref> is a diagram illustrating example resource control modules.

0023<figref idref="DRAWINGS">FIG. 12</figref> is a diagram illustrating a resource module.

0024<figref idref="DRAWINGS">FIG. 13</figref> is a diagram illustrating example resource modules.

0025<figref idref="DRAWINGS">FIG. 14</figref> is a diagram illustrating a resource control model.

DETAILED DESCRIPTION

0026Arbitrating control of shared industrial resources amongst multiple industrial module class components as a function of identity of such component is provided herein. For example, a unique identifier associated with an industrial control module can distinguish the module from other components of the system. Upon receiving a request to control a resource, the identifier of the requesting module can be published to other system components. If the published identifier matches the module identifier, the module can assume control of the resource. Otherwise, the request for control is placed into a request queue for processing by various arbitration algorithms that determine a control order. As described, aspects of the subject innovation can reduce or eliminate a need for custom arbitration coding amongst modules and resources of an industrial system. The result can be greatly reduced overhead costs and pre-production delays associated with such a system.

0027It is noted that as used in this application, terms such as “component,” “module,” “model,” 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, industrial controllers, and/or modules communicating therewith.

0028Referring initially to <figref idref="DRAWINGS">FIG. 1</figref>, a system <b>100</b> is depicted that provides arbitration of a shared industrial resource <b>102</b> for an industrial process <b>104</b>. Specifically, an arbitration component <b>106</b> receives a control request from multiple control modules (<b>108</b>, <b>110</b>) of the industrial process <b>104</b>. The arbitration component <b>106</b> then determines an order in which the modules (<b>108</b>, <b>110</b>) can access the resource <b>102</b>, and facilitate such access according to the determined order. For example, a module given first priority (control module₁<b>108</b>) can access the resource <b>102</b> while remaining modules (up through and including control module_N<b>110</b>) are denied access to the resource <b>102</b>. When control module₁<b>108</b> relinquishes access to the resource <b>102</b>, a module given second priority (e.g., control module_N<b>110</b>) can then access and control the resource <b>102</b>. By utilizing arbitration, system <b>100</b> mitigates conflicting commands delivered to a single resource by different controllers (<b>108</b>, <b>110</b>). In circumstances where multiple control modules attempt to access a resource <b>102</b> concurrently, system <b>100</b> can help to facilitate proper execution of system components instead.

0029For instance, a ‘race condition’ can occur where two control modules (<b>108</b>, <b>110</b>) attempt to access and direct execution of an industrial resource <b>102</b> concurrently. Various problems can result from such condition. For example, if multiple devices (<b>108</b>, <b>110</b>) access and deliver inconsistent or exclusive commands to the resource <b>102</b>, a malfunction can occur and the commands can be executed incorrectly or not executed at all. As another example, the resource <b>102</b> can respond to commands of only one of the control devices (<b>108</b>, <b>110</b>) and be non-responsive to the other(s) (<b>108</b>, <b>110</b>). Consequently, some devices (<b>108</b>, <b>110</b>) can prematurely execute logic because of such non-responsiveness. To address these potential problems, the arbitration component <b>106</b> determines an access/control order for multiple control devices to facilitate efficient utilization of resources. More specifically, arbitration can help to mitigate malfunctioning and/or non-responsive conditions by providing access to the industrial resource <b>102</b> for a single control module (<b>108</b>, <b>110</b>) at a time, and denying access to other control modules (<b>108</b>, <b>110</b>) at such time (or, e.g., to a group of control modules (<b>108</b>, <b>110</b>) designed to work synchronously with the industrial resource).

0030The industrial process <b>104</b> of system <b>100</b> can also include an identifier component <b>112</b> that facilitates arbitration of control of one or more components and/or resources of system <b>100</b>. Arbitration can be between one or more control modules/components (<b>108</b>, <b>110</b>). Particularly, identifier component <b>112</b> can generate a unique ID for one or more control modules (<b>108</b>, <b>110</b>) to assist the arbitration component <b>106</b> in identifying the modules (<b>108</b>, <b>110</b>). For instance, identifier component <b>112</b> can generate a unique ID associated with control module₁<b>108</b> and control module_N<b>110</b>. The unique ID's can be provided to the arbitration component <b>106</b> to assist in determining an access order for the control modules <b>108</b>, <b>110</b>. If access to resource <b>102</b> is granted, the unique ID associated with a control module (<b>108</b>, <b>110</b>) can be further associated with the request and provided to resource <b>102</b>.

0031If resource <b>102</b> is not currently controlled by another industrial component when the arbitration component <b>106</b> receives a control request, access and control of the resource <b>102</b> can pass to a requesting control module (<b>108</b>, <b>110</b>). The association between a unique ID and a request/control of resource <b>102</b> can also be utilized to apprise other industrial components (e.g., controllers, resources, etc.) that the resource <b>102</b> is being controlled by a control module (<b>108</b>, <b>110</b>). Such components could then place a control request (including an additional unique ID generated by identifier component <b>112</b> or an additional identifier component (<b>108</b>) assigned to such device(s)) in a queue, for instance, to facilitate access and control of resource <b>102</b> when it is available.

0032As discussed above, the arbitration component <b>106</b> can also deny access to control modules (<b>108</b>, <b>110</b>) where suitable. For instance, if control module₁<b>108</b> has accessed and is in control of a resource <b>102</b> (and, e.g., its ID is associated with the resource <b>102</b>), the arbitration component <b>106</b> can deny access to the resource <b>102</b> for control module_N<b>110</b>. Denial of access can persist until a time when control module₁<b>108</b> is no longer accessing/controlling resource <b>102</b>.

0033The arbitration component <b>106</b> can utilize various arbitration algorithms to prioritize multiple concurrent (e.g., within a threshold period) requests for control of the resource <b>102</b>. For instance, a first come first serve (FCFS) algorithm can be employed, wherein a module ID and request for control that is first received at arbitration component <b>106</b> (or, e.g., at the resource <b>102</b> itself) can be provided access to the resource <b>102</b>. Other modules (<b>108</b>, <b>110</b>) can be denied access to resource <b>102</b> so long as a first module ID is associated with the resource <b>102</b>. When resource <b>102</b> is available for control (e.g., no module ID is associated there with), a second received ID and request can be executed, and so on. Alternatively, a highest priority first serve (HPFS) algorithm can be employed, wherein a module ID can be associated with a module priority number (e.g., generated by identifier component <b>112</b> or related component). If several module IDs and requests for control are received at the arbitration component <b>106</b> (e.g., within a threshold period of time), a module having the highest priority number can be provided access to the resource <b>102</b>. It is to be understood that various algorithms for arbitrating between one or more control modules (<b>108</b>, <b>110</b>) can be utilized by the arbitration component <b>106</b>, including those articulated above, combinations thereof, and combinations of these and other suitable algorithms.

0034Also of note, the industrial process <b>104</b> can include any suitable combination of industrial controllers (e.g., programmable logic controller (PLC)), control emulators, power supplies, communication bus structures, hardware devices (e.g., motor, pump, refrigerator, conveyor, weight scale, material flow valve, and so on), software modules (e.g., control modules, equipment modules, etc.), logical operators, and so on. In addition, each of the components of the industrial process <b>104</b> can be configured to interact with various other components in order to perform tasks (e.g., open a valve to dispense stored material, move an object across a conveyor, or maintain a predetermined temperature), respond to certain conditions (e.g., fill a container that falls below a threshold weight, activate a conveyor to move a load that rises above a threshold weight, or power a refrigeration module if a temperature rises above a threshold), maintain and/or track a state (e.g., a task number) and provide system feedback (e.g., by way of system alarms).

0035The industrial process <b>104</b> can also include at least one control module (<b>108</b>, <b>110</b>) and various industrial resources (<b>102</b>). The control module(s) (<b>108</b>, <b>110</b>) can be any suitable process, component, device, and/or machine that can access, control, prioritize, or apply the resources <b>102</b> to a particular task. For instance, control module₁<b>108</b> (or, e.g., control module_N<b>110</b>) can be a programmable logic controller (PLC), an equipment module, a logic operation or thread of execution that can conduct an industrial component in accomplishing a task, and so on. Additionally, the control module(s) (<b>108</b>, <b>110</b>) can be a group of industrial components (e.g., equipment modules, control modules, resource control modules, and so on) designed to interact in a synchronized manner with the resource <b>102</b> (e.g., the multiple components can be synchronized to enable multiple successful interactions with the resource <b>102</b> either concurrently or in rapid succession). Resources <b>102</b> can include any suitable industrial resource associated with an industrial process <b>104</b> including modules of the industrial process <b>104</b> (e.g., a control module, an equipment module, a resource control module, etc.) a physical device such as a motor, conveyor, pump, electrical power source, material storage device, material flow shut-off valve, and so on, personnel resources (e.g., input/output information such as verification of a result, or a task performed by a industrial technician, etc.), and like resources of an industrial automation system.

0036As detailed above, system <b>100</b> can help to mitigate damage and confusion resulting from concurrent access to an industrial resource <b>102</b> by multiple control modules (<b>108</b>, <b>110</b>). In addition, system <b>100</b> can reduce overhead costs and time to production delays associated with conventional arbitration. Specifically, by employing an arbitration component <b>106</b> and an identifier component <b>112</b>, a single control module (<b>108</b>, <b>110</b>) (or synchronized modules) can control the resource <b>102</b> at one time, and other components (not depicted) can be notified of the control to redirect attempts at concurrent control. The control and notification can be based on an ID of the control module (<b>108</b>, <b>110</b>) being associated with the resource <b>102</b>, for instance. Specifically, access can be granted only to a module (<b>108</b>, <b>110</b>) whose ID is associated with the resource <b>102</b>, and access by all other modules can be denied. Consequently, repeated instances of arbitration logic, crafted for independent modules of a system, which arbitrate and/or synchronize access for to system resources, can be avoided.

0037As will be described in more detail below, the control modules (<b>108</b>, <b>110</b>), identifier component <b>112</b>, or resource(s) <b>102</b> can be an association of logic with one or more resources. The logic includes program code that can alter the state of a resource for example, ladder code, function chart, script, JAVA, C code, and so forth. The resources are those components or elements that perform an activity in a system including equipment and personnel that perform work in a system. Other examples of types of resources include Equipment, Material, Personnel, Segments and Storage. Personnel and equipment (machines) can perform activities in a system. Resources that can perform work can be classified as active resources (e.g., CNC machine, Injection molding machine), whereas other equipment resources can be considered passive resources (e.g., sensor, material). In general, the modules hide the user from internal interfaces, messages, and logic specific to the resources yet provide standard or generic interfaces to external systems or between components.

0038Modules may include other modules including nested modules where standard module behaviors and attribute patterns can be represented using common data model representations for module classes, module templates and module inheritance. Module classes and templates can be maintained in libraries that facilitate access to desired system functionality and further promote system integration. Resources can have various states associated therewith such as common S88 state classifications including idle, hold, abort, run, reset, stop, restart, and so forth where the module can present logic to represent state machines that manage the state of a resource. During application, resource modules (described below) can take on the name of the resource that is the primary focus of the module. For example, an equipment module is primarily focused on coordination of equipment (e.g., motors, pumps, conveyors, valves, and so on) but may involve personnel in the process. Similarly, a personnel module is focused on coordination of personnel but may involve other resources in the process. A control module (e.g., control module <b>108</b>, <b>110</b>) that manages a material may be referred to as a material control module and so forth.

0039It is noted that components associated with the system <b>100</b> can include various computer or network components such as servers, clients, programmable logic controllers (PLCs), communications modules, mobile computers, wireless components, and/or control components and so forth, which are capable of interacting across a network. Similarly, the term PLC as used herein can include functionality that can be shared across multiple components, systems, and/or networks. For example, one or more PLCs can communicate and cooperate with various network devices across the network. This can include substantially any type of control, communications module, computer, I/O device, sensor, Human Machine Interface (HMI), and the like, that communicates via the network, which includes control, automation, and/or public networks. The PLC can also communicate to and control various other devices such as Input/Output modules including Analog, Digital, Programmed/Intelligent I/O modules, other programmable controllers, communications modules, sensors, output devices, and the like.

0040The network can include public networks such as the Internet, Intranets, and automation networks such as Control and Information Protocol (CIP) networks including DeviceNet and ControlNet. Other networks include Ethernet, DH/DH+, Remote I/O, Fieldbus, Modbus, Profibus, wireless networks, serial protocols, 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 addition to the foregoing, it is noted that components associated with the system <b>100</b> can include presence sensing devices, safety switches, interlock switches, safety relays, emergency stop devices, cable pulls &amp; enabling switches, safety controllers, and so forth, which are capable of interacting to form a safety system.

0041Referring now to <figref idref="DRAWINGS">FIG. 2</figref>, block diagram of an example system <b>200</b> that provides for arbitration as a function of ownership is illustrated. System <b>200</b> includes an identifier component <b>202</b> that generates a unique ID for an industrial control module <b>204</b>. The unique ID can be provided to identifier component <b>202</b> by control module <b>204</b> in conjunction with a request for control of resources <b>206</b>, for instance. Furthermore, if the control module <b>204</b> is granted access to the resources <b>206</b>, the identifier component <b>202</b> associates the unique ID with such resources <b>206</b> to facilitate control thereof and to notify other system components of such control.

0042System <b>200</b> also includes an ownership component <b>208</b> that provides control of a resource <b>206</b> of an industrial process to control module <b>204</b>. Such control can be conditioned on whether an ID of the module (<b>204</b>) generated by identifier component <b>202</b> is associated with the resource <b>206</b>. For instance, identifier component <b>202</b> can write an ID of a control module <b>204</b> into a queue (e.g., a bit, byte, memory counter, or other allocated memory, not depicted) associated with the resource <b>206</b>. Ownership component <b>208</b> can then refer to the queue to determine whether access/control of resource <b>206</b> should be given and to which industrial component (<b>204</b>). Thus, ownership component <b>208</b> provides control and access to the resource <b>206</b> based on the ID written to the ownership queue. Together the ownership component <b>208</b> and ownership queue establish a notion of contemporaneous control, or ownership, of an industrial resource <b>206</b>. System <b>200</b> therefore, can identify (e.g., by arbitration) one or more particular modules (<b>204</b>) to have control of the resource <b>206</b>, associate an ID of the module(s) <b>204</b> with the resource <b>206</b> for duration of the control, and deny access to the resource <b>206</b> for additional modules (<b>204</b>) not affiliated with the ID.

0043In addition, ownership information can be provided to other components of an industrial system to notify them that a resource <b>206</b> is in use (and not yet accessible). Such notification can be used to route a request for control into a request queue, for instance (see, e.g., <figref idref="DRAWINGS">FIG. 4</figref> for a depiction and discussion of request queue). Consequently, system efficiency is enhanced by mitigating redundant or untimely requests sent to ownership component <b>208</b>.

0044At <b>210</b>, an ownership request component is depicted that receives a request to control a resource <b>206</b> of an industrial automation system if such resource is already controlled by control module <b>204</b>. For instance, if an ID is written to a queue associated with the resource <b>206</b>, then a request for such resource <b>206</b> can be received by and/or routed to ownership request component <b>210</b>. Ownership request component <b>210</b> can then place the request and an ID of a module (<b>204</b>) initiating the request into a request queue (not depicted). The request queue can be any suitable memory (e.g., bit, byte, counter, allocated portion of a data store, etc.) associated with resource <b>206</b> that receives, stores, updates and/or erases requests for control of the resource <b>206</b> and IDs of modules (<b>204</b>) initiating such requests.

0045As an example to provide context for aspects of system <b>200</b>, a material flow shut-off valve can be a particular resource (<b>206</b>) of an industrial automation system. For instance, the shut-off valve (<b>206</b>) can control flow of fuel (e.g., gasoline, natural gas, hydrogen fuel, and so on), coolant (e.g., air, water, liquid nitrogen, or the like), lubricant (e.g., oil), and various other materials suitable for powering or otherwise operating automated industrial machinery. Various control modules (<b>204</b>) associated with industrial machinery can include logic for accessing and controlling the shut-off valve in order to dispense a material used to operate a machine (e.g., to dispense oil for lubricating a moving part, dispense fuel for powering a motor or pump, stopping/starting/changing a flow rate of a dispensed material(s) according to safety requirements, and so on). As a particular example, two control modules (<b>204</b>) associated with different machines can attempt to access the shut-off valve (<b>206</b>) concurrently (e.g., within a threshold period of time). Each module (<b>204</b>) provides a request for control identifying the shut-off valve (<b>206</b>) along with a unique ID associated with the module (<b>204</b>). These requests can be received at an arbitration component (e.g., as depicted at <b>106</b> of <figref idref="DRAWINGS">FIG. 1</figref>, supra) that can arbitrate between the two modules (<b>204</b>) to determine which is provided first access to the shut-off valve (<b>206</b>). Arbitration can be based on a FCFS algorithm, a HPFS algorithm, or combinations of these or like arbitration algorithms. Further, the arbitration can incorporate module importance to provide higher priority access to predetermined modules or class of modules (e.g., safety modules).

0046When control of the shut-off valve is determined, the ‘winning’ module ID can be written to a queue associated with the shut-off valve (<b>206</b>). An ownership component <b>208</b> can then provide access and control of the shut-off valve (<b>206</b>) to the ‘winning’ module. The ID of the ‘losing’ module can be written by an ownership request component (<b>210</b>) to a request queue associated with the shut-off valve (<b>206</b>). The request queue can simply act as a holding position for control requests while the shut-off valve is serving the ‘winning’ (or, e.g., a subsequently served) module (<b>204</b>). When the ‘winning’ module has finished use of the shut-off valve, a control release command can be provided to identifier component <b>202</b> and forwarded to ownership component <b>208</b>. Upon receiving such command, ownership component <b>208</b> can erase the queue associated with the shut-off valve (<b>206</b>), and update it with an ID and request in the request queue (e.g., initiated by the ‘losing’ module).

0047In addition, if an additional request for control is received by the identifier component (<b>202</b>) while the shut-off valve (<b>206</b>) is utilized by the ‘winning’ module (<b>204</b>), such request and a module ID can be forwarded directly to ownership request component <b>210</b> to be placed in a request queue (e.g., because the queue associated with the shut-off valve (<b>206</b>) already has a module ID of the ‘winning’ module written to it). Additional arbitration can be performed (e.g., see <figref idref="DRAWINGS">FIG. 1</figref>, supra) for multiple requests in the request queue. For instance, even though the additional request arrived after the ‘losing’ module (<b>204</b>) request, the additional request can be provided access to the shut-off valve (<b>206</b>) before the ‘losing’ module in certain circumstances (e.g., when an HPFS arbitration algorithm is employed and the additional request has a higher priority than the ‘losing’ request).

0048As described, system <b>200</b> provides for management of multiple requests for a resource <b>206</b> utilizing a general arbitration algorithm or set of algorithms. Such management facilitates a more cost efficient mechanism for implementing arbitration as compared with conventional techniques. In addition, further examples of request management and control arbitration are provided below in order to satisfy other potential conflict or ‘race’ conditions for an industrial automation system.

0049As an additional example, system <b>200</b> can also represent a safety system. Specifically, control module <b>204</b> or resources <b>206</b>, or both, can include components of a safety system, such as safety devices (e.g., presence sensing devices, safety switches, interlock switches, safety relays, emergency stop devices, cable pulls &amp; enabling switches, or the like), which can typically belong to a safety system (<b>200</b>). Additionally, identifier component <b>202</b> can determine and/or provide a unique ID for components of the safety system (<b>200</b>) to distinguish these components within the safety system.

0050According to particular embodiments, a safety controller (<b>204</b>) can have limited resources (<b>206</b>) with which to maintain functional safety requirements of the system (<b>200</b>). For a functional safety system (<b>200</b>), control module <b>204</b> can include additional components, such as a Safety Integrity Level component(s) (SIL) and/or a Performance Level component(s) (PL), or the like, e.g., as defined in industry standards dedicated to safety systems such as IEC61508, IEC61511, IEC 61326-3-1, IEC 61784-3. Further, resources (<b>206</b>) associated with system <b>200</b> can include any suitable material, module, component etc., of an industrial process necessary to maintain an SIL or PL as required by the foregoing and/or like industry standards.

0051If additional safety devices (<b>204</b>) are added to the safety system <b>200</b>, they can each request ownership of safety resources (<b>206</b>) as required. Multiple concurrent requests can be placed in a request queue, as described above. The ownership component <b>208</b> can determine resources required by the requesting device (<b>204</b>), according to identity, and compare the request to the available resources (<b>206</b>). Ownership of resources may then be granted or denied, and the identity of the requesting device (<b>204</b>) removed from the request queue. For example, if a sum of an existing safety component ID and the requesting safety component ID are within resource limits required to maintain an SIL or PL device, access can be granted to a requesting device (<b>204</b>). If, however, the sum of the safety component ID currently associated with the resource <b>206</b> and the requesting safety component ID will exceed a boundary required by the SIL or PIL device, the requesting ID can be placed into the request queue instead.

0052Referring to <figref idref="DRAWINGS">FIG. 3</figref>, a system <b>300</b> is depicted that monitors ownership of an industrial resource and notifies system components of the ownership. Particularly, system <b>300</b> includes a control module <b>302</b> that initiates a request to control a resource <b>304</b> of an industrial automation system. The control request can include a unique ID of the module <b>302</b> and can be received at an ownership component <b>306</b>. Upon receipt of the request, ownership component <b>306</b> references an ownership ID queue <b>308</b> to determine whether another device ID is concurrently in control/ownership of the resource <b>304</b>. If not, ownership component <b>306</b> provides access and control of resource <b>304</b> to control module <b>302</b>.

0053System <b>300</b> also includes an update component <b>310</b> that writes an ID of control module <b>302</b> into ownership ID queue <b>308</b> (e.g., associated with resource <b>304</b>). For instance, update component <b>310</b> can write the ID of control module <b>302</b> into the ownership ID queue <b>308</b> if the module <b>302</b> is determined to be a concurrent owner of an industrial resource <b>304</b> (e.g., if no module ID is written into the ownership ID queue <b>308</b> when a request from control module <b>302</b> is received at ownership component <b>306</b>). Ownership component <b>306</b> also references the ownership ID queue <b>308</b> in determining whether to provide access and control of resource <b>304</b> to control module <b>302</b>. If an ID of control module <b>302</b> is in the ownership ID queue <b>308</b>, access is given. Otherwise, access is denied.

0054At <b>312</b> is depicted a control monitoring component that audits the ownership ID queue <b>308</b> and determine whether a control module (<b>302</b>) is a concurrent owner of resource <b>304</b>. Specifically, whether a module ID is written to the ownership ID queue <b>308</b> is determined. If such is the case, control monitoring component <b>312</b> also publishes the contents of the ownership ID queue (<b>314</b>) throughout an industrial network (and/or, e.g., make ownership information available upon request by network devices). Publication can be utilized in order to notify additional modules that the resource <b>304</b> is in use and to identify the module(s) (<b>302</b>) that has ownership of the resource <b>304</b>, for instance. Consequently, such additional devices can place a control request into a request queue, for instance, to await arbitration and/or access to the resource <b>304</b>.

0055Referring to <figref idref="DRAWINGS">FIG. 4</figref>, a block diagram of an example system <b>400</b> that processes, queues and updates control requests for an industrial resource <b>402</b> is depicted. The industrial resource <b>402</b> can include any suitable controller, material, machine, program module, logical process, or personnel resource pertaining to an industrial automated system (as described herein). The resource <b>402</b> is affiliated with an ownership ID queue <b>404</b> that contains an ID of a control module <b>406</b> currently having access to and ownership of the resource <b>402</b>. Ownership of resource <b>402</b> enables control module <b>406</b> to direct, appropriate, instruct, provide/receive information from, etc., the resource <b>402</b>. For instance, control of a shut-off valve resource can enable control module <b>406</b> to dispense material stored within a container associated with the shut-off valve (e.g., see <figref idref="DRAWINGS">FIG. 2</figref>, supra). If no device (<b>406</b>) has control of resource <b>402</b>, the ownership ID queue <b>404</b> is empty.

0056System <b>400</b> also includes a request queue <b>408</b>. Request queue <b>408</b> serves as a place to store a control request from module <b>406</b> if an ID of another device (not depicted) is written in the ownership ID queue <b>404</b> (and, e.g., already in control of the resource <b>402</b>). Request queue <b>408</b> can store multiple requests for ownership of resource <b>402</b> from multiple control modules (<b>406</b>). Multiple requests are prioritized by an arbitration algorithm (e.g., FCFS, HPFS) establishing a priority of access to resource <b>302</b>.

0057At <b>410</b> a reset component is depicted that erases the contents of ownership ID queue <b>404</b>. For instance, if a control module <b>406</b> having ownership of resource <b>402</b> sends an ownership termination command indicating that the module (<b>406</b>) no longer requires ownership of the resource <b>402</b>, reset component <b>410</b> can erase ownership ID queue <b>404</b>. As a result, another request (if present) stored in request queue <b>408</b> is loaded into ownership ID queue <b>404</b>, and a module (<b>406</b>) initiating such request takes ownership and control of resource <b>402</b>. As described above, if multiple requests are stored in request queue <b>408</b>, a priority order can be established by an arbitration algorithm.

0058System <b>400</b> provides a substantial improvement over conventional arbitration mechanisms. Specifically, system <b>400</b> provides a general purpose resource request management system that employs one or more arbitration algorithms based on an ID of a requesting module (and/or, e.g., a priority factor associated with the ID). Specific synchronization and arbitration code tailored to each individual control module, or groups of control modules, can be avoided. Because drafting repeated instances of arbitration/synchronization code is time consuming and expensive, system <b>400</b> can provide substantial cost-reduction and time to production benefits over these conventional techniques.

0059In view of the exemplary systems described supra, methodologies that may be implemented in accordance with the disclosed subject matter will be better appreciated with reference to the flow charts of <figref idref="DRAWINGS">FIGS. 5-9</figref>. While for purposes of simplicity of explanation, the methodologies are shown and described as a series of blocks, it is to be understood that the claimed subject matter is not limited by the order of the blocks. For example, some blocks may occur in different orders and/or concurrently with other blocks from what is depicted and described herein. Moreover, not all illustrated blocks may be used to implement the disclosed methodologies. Additionally, the methodologies disclosed throughout this specification are capable of being stored on an article of manufacture to facilitate transporting and transferring such methodologies to computers.

0060Referring now to <figref idref="DRAWINGS">FIG. 5</figref>, a flowchart of a sample method <b>500</b> for arbitrating access to industrial resources is depicted. At <b>502</b>, method <b>500</b> receives a request to control an industrial resource. The industrial resource can include any suitable component (e.g., communication bus, power source), machine (e.g., motor, pump, conveyor, compressor, lift, mixer, valve, storage container, and so on), module (e.g., control module, equipment module, resource control module), material (e.g., fuel, lubricant, coolant, cleanser), and/or personnel (e.g., technician, department manager) affiliated with an industrial automation process. Control can include direct control, wherein commands are performed by the industrial resource, or a request for information (e.g., database request, reference to a logical program condition, input/feedback from a technician). In addition, such request can be provided by way of any suitable interface, including a communication bus or an HMI.

0061At <b>504</b>, method <b>500</b> arbitrates control of the industrial resource based on a component ID. The component ID is a unique identifier distinguishing a component from other components (or, e.g., a group of synchronized components). In addition, the component can be any suitable entity capable of communicating with and/or controlling a resource (described above). For instance, the component can be a control module, an equipment module, or a resource control module. Further, the component can be a human (e.g., plant technician) having a component ID (e.g., an ID badge). Arbitration of control can be a decision to provide access to the resource for one component, and deny access for another, based at least on the component ID of one or more components.

0062For instance, if two control modules request control of a compressor machine within a threshold period of time, the compressor can malfunction due to inconsistent or contrary commands issued by the control modules. Arbitrating control, so that only a single module issues commands to the compressor machine at a time, can help to mitigate such problems. Arbitration can also determine a control priority amongst the two control modules. Specifically, priority can determine which control module can access the resource first. Such priority can be determined based on a first received request, or on importance of a requesting component, or combinations of these and other criteria.

0063In addition, arbitrating control based on a component ID can circumvent a need for redundant arbitration code in an industrial setting. For instance, conventional arbitration mechanisms typically require one or more arbitration and/or synchronization programs to be coded for each control component. Redundant coding is typically costly and time consuming, as it has to be developed, tested, and debugged. Arbitration based on component ID, on the other hand, can provide a general arbitration mechanism applicable to various industrial control components. Each requesting component can provide an ID along with a request for control, and the ID can be associated with a resource when a component is in control of it. Therefore, competing components can suspend control requests until the ID is cleared. Alternatively, requests can be placed in a queue where the general purpose arbitration algorithm (e.g., a FCFS or HPFS algorithm) can prioritize the requests, and provide access to the resource based on such priority. As described, method <b>500</b> can therefore increase efficiency and lower overhead costs associated with an industrial process.

0064Referring to <figref idref="DRAWINGS">FIG. 6</figref>, a flowchart of a sample method <b>600</b> is depicted for managing control requests for an industrial resource. Method <b>600</b>, at <b>602</b>, receives a request to control an industrial resource, as described herein. At <b>604</b>, a determination is made as to whether an ownership queue associated with the industrial resource is empty. If the ownership queue is empty, method <b>600</b> proceeds to reference number <b>608</b>, if not method <b>600</b> proceeds to reference number <b>606</b>.

0065At <b>606</b>, if the ownership queue is empty, control of the industrial resource is surrendered to a requesting entity. Subsequently, at <b>608</b>, an ID of the requesting entity is written to the ID queue. As a result, ownership of the resource is established for the requesting entity. At <b>610</b>, the contents of the ID queue are published. For example, the contents can be included in a file and provided to control components of an industrial network, or access to the ID queue can be provided to pertinent entities for reference. Publication in this manner can therefore apprise networked entities of the ownership of the resource. As a result, subsequent requests for control can be sent directly to a request queue (see below) thereby enhancing system efficiency.

0066At <b>612</b>, method <b>600</b> makes another determination, if the ownership queue is not empty, as to whether an ID contained therein is the ID of a component requesting control of a resource. If so, method <b>600</b> proceeds to <b>606</b> where control is surrendered to the requesting component. If not, method <b>600</b> proceeds to <b>614</b>, where a request queue is updated. The request queue can, for instance, store control requests and associated component IDs when the resource is currently owned by a different device (e.g., having a different component ID). In addition, an arbitration algorithm, as described herein, can be utilized to establish a priority for control requests in the request queue. Such priority establishes an order in which multiple requests are given access to an industrial resource when the resource becomes available. As described, method <b>600</b> organizes and manages multiple requests to control a resource, thereby promoting efficient and consistent utilization of the resource. In addition, a general purpose arbitration scheme is employed to prioritize the requests, based on an ID associated with a requesting component.

0067Referring now to <figref idref="DRAWINGS">FIG. 7</figref>, a flowchart of an example methodology <b>700</b> is depicted for updating ownership of a resource and arbitrating control to an owning module. Method <b>700</b>, at <b>702</b>, receives a request to control an industrial resource, as described herein. At <b>704</b>, a determination is made as to whether an ownership queue is full and, if so, whether an owner ID contained therein is the ID of the requesting device. If the ownership queue is not full, or if the owner ID is the ID of the requesting device, method <b>700</b> proceeds to <b>706</b> where control of the resource is surrendered to the requesting device, for example.

0068If, at <b>704</b>, the ownership queue is full (and the owner ID is not the ID of the requesting device), method <b>700</b> proceeds to reference number <b>708</b>. At <b>708</b>, an additional determination is made as to whether a prior process is complete. For instance, a control module having ownership of a resource can send an ownership termination command when ownership is no longer needed. The ownership termination command can result in clearing the ownership queue, for example. If the ownership queue is cleared, a component ID of another device (if available) is loaded into the ownership queue. Consequently, if the determination at <b>708</b> is that a prior process is complete, method <b>700</b> proceeds to <b>714</b> where the owner queue is updated with a component ID from a request queue.

0069If, at <b>708</b>, the prior process is not complete, method <b>700</b> proceeds to reference number <b>710</b>. At <b>710</b>, a request queue is updated to include the request received at reference number <b>702</b>. In addition, at <b>712</b>, the request is provided a priority if such priority is not already specified. For instance, an arbitration algorithm as disclosed in the subject specification, or known in the art, can provide priority based on a component ID associated with the request. Particularly, priority can be based on an order in which the component ID was received relative to other owner IDs, an importance of the owner ID relative to other owner IDs, and so on. Upon generating priority at reference number <b>712</b>, method <b>700</b> again determines whether a prior process is complete at reference number <b>708</b>.

0070Upon updating the owner queue with an owner ID from the request queue at <b>714</b>, method <b>700</b> proceeds to <b>716</b>. At <b>716</b>, a determination is made as to whether the owner ID updated into the owner queue is equal to the component ID associated with the request received at reference number <b>702</b>. If so, method <b>700</b> proceeds to <b>718</b> where control of the resource is surrendered to a requesting entity initiating such request. If the owner ID does not equal the component ID associated with such request, method <b>700</b> proceeds to reference number <b>710</b>, where the request queue is updated again.

0071Referring to <figref idref="DRAWINGS">FIG. 8</figref>, a flowchart of an example methodology <b>800</b> is illustrated for securing access to an industrial resource. More specifically, method <b>800</b> can be utilized by a control device to initiate a control request for accessing the industrial resource. At <b>802</b>, a determination is made as to whether ownership of an industrial resource is desired. If not, method <b>800</b> proceeds to <b>804</b> where no action is taken and where method <b>800</b> can terminate. If ownership is desired, method <b>800</b> proceeds from reference number <b>802</b> to reference number <b>806</b>. At <b>806</b>, a determination is made as to whether the industrial resource is currently owned. For instance, an ownership queue can be referenced to determine whether ownership of the resource has been established. If the resource is not owned, method <b>800</b> proceeds to reference number <b>810</b>. If the resource is owned method <b>800</b> proceeds to reference number <b>808</b>.

0072At <b>808</b>, another determination is made as to whether an owner ID associated with the resource is equal to an ID of a requesting device. If so, method <b>800</b> proceeds to <b>810</b>. If the owner ID is not equal to the ID of the requesting device, method <b>800</b> returns to reference number <b>802</b>, for instance, to repeat the methodology until the resource is no longer owned or until an owner ID is equal to the ID of the requesting device. At <b>810</b>, the requesting device writes its ID to an ownership queue of the resource. As a result, control of the resource can pass to the requesting device (e.g., upon initialization of the resource).

0073Referring now to <figref idref="DRAWINGS">FIG. 9</figref>, a flowchart of an additional example methodology <b>900</b> is illustrated for arbitrating control of an industrial resource. For instance, method <b>900</b> can be implemented by an industrial automation system in addition to, or in lieu of, methodologies <b>500</b>-<b>800</b>. At <b>902</b>, method <b>900</b> begins. At <b>904</b>, method <b>900</b> determines whether a request queue associated with an industrial resource is empty. If the request queue is not empty, an incoming request is placed in queue and prioritized by an arbitration algorithm, as described herein.

0074If, at reference number <b>904</b>, the request queue is empty, method <b>900</b> proceeds to reference number <b>908</b>. At <b>908</b>, a requesting component ID can be loaded into the request queue. At <b>910</b>, the component ID is then loaded into an owner queue. Upon loading the component ID into the owner queue from the request queue, method <b>900</b> also clears the request queue at <b>912</b>, and proceeds to reference number <b>914</b>.

0075At <b>914</b>, a determination is made as to whether the owner queue is non-empty (e.g., a bit representing the queue is non-zero). If the owner queue is not empty, method <b>900</b> proceeds to reference number <b>916</b> where a ‘resource acquired’ bit is set. The resource acquired bit can indicate, for instance, that the resource is concurrently owned by a component of an industrial system. If the owner queue is empty, method <b>900</b> proceeds to <b>918</b> where the resource acquired bit is reset. Following reference numbers <b>916</b> or <b>918</b>, method <b>900</b> proceeds to <b>920</b> where the methodology terminates.

0076It is noted that method <b>900</b> can be implemented in conjunction with method <b>800</b>. For instance, method <b>900</b> can provide logic for queuing requests for an arbitrated industrial resource, and method <b>800</b> can provide logic for acquiring access of the industrial resource by an industrial controller, for instance. More specifically, writing an ID of a requesting device to a request queue of the industrial resource, at reference number <b>810</b> of method <b>800</b>, can trigger initiation of method <b>900</b> at <b>902</b>. Consequently, methodologies <b>800</b> and <b>900</b> can be utilized together or separately in order to implement one or more aspects of the subject disclosure.

0077Referring now to <figref idref="DRAWINGS">FIG. 10</figref>, module attributes <b>1000</b> are illustrated. The attributes <b>1000</b> depicted in <figref idref="DRAWINGS">FIG. 10</figref> include a common (or exemplary) representation that can be modules from modules. Generally, a set of standard attributes can be determined that are common to all modules. Similarly, for other types of modules described below, additional standard attributes can be defined. An example of a property <b>1010</b> available on modules includes attributes such as Fault and Status at <b>1014</b>. Active resource modules (e.g., equipment and personnel) can support additional properties <b>1010</b> such as available/unavailable.

0078Attributes presented below are represented associations from the module to objects that may be internal in a common data model or elsewhere (e.g., CAD Files). At <b>1020</b>, standard public interfaces can be provided. These interfaces <b>1020</b> publish verbs <b>1024</b> that are available to external systems and are documented activities that hide the complexity of the underlying code used to implement the interface. Interfaces <b>1020</b> can be considered into at least two common usage scenarios. For example, interfaces <b>1020</b> can be used as access points that can be used to hook in real time diagnostics, security and so forth.

0079Public verbs <b>1024</b> initiate an action within the module. The activity is described to clients of the interface <b>1020</b>. The implementation is considered private and is not presented to clients—for example, Open, Stop, Abort, Shut, and so forth. A data value property <b>1010</b> provides public access to information that is used by the module during its operation and can be provided by request values and/or internal values (or an equivalent). The association of logic to transfer request values to internal values and vice versa are referred to as get and set logic for the value. It is noted that in a controller, if there is not a set routine to transfer request values to internal values, the internal value can overwrite the request value on the next scan providing read only capability.

0080In general, the properties <b>1010</b> can be considered in at least two classifications. States have special significance for production systems and can have a specific set of values that can be represented by range or enumeration. A state can represent the current status of the primary resource being encapsulated by the module e.g., Percent open, Mode, Service (in, out), and so forth. Information that is used by the module during its operation includes access to data that is provided by interfaces <b>1020</b>. e.g., Conversion Map, Name, Description, expiry date, personnel contact information. Some properties <b>1010</b> can be common to all instances of resource modules (e.g., scanned copy of resource specification documents), whereas other properties <b>1010</b> are specific to each module instance (e.g., Status, percent open).

0081At <b>1030</b>, internal resource interfaces include interfaces from logic <b>1040</b> in the module to the resource being managed at <b>1050</b>, where the logic includes code and/or configuration that processes a command and/or updates state and data properties. In some cases, this can be hardware such as I/O interfaces, or in other cases it is to subordinate resource control modules that have direct interfaces. Some examples include I/O mapping, material management logic routines, and so forth. These interfaces <b>1030</b> are internal to the module enabling the module's public interfaces <b>1020</b> and properties <b>1010</b> to be the boundary to other system components. Modules that wrap different resources but support the same public properties/interfaces can be exchanged without disrupting interfaces to other components. Generally, I/O mapping and system messaging interfaces are exposed during deployment bind processes. When bound, external interfaces <b>1020</b> to runtime systems may then consider these interfaces as internal.

0082At <b>1060</b>, alarm and event messages can be provided which include messages exposed as runtime messages that are visible to external systems during the execution of the module. This includes alarms and events explicitly coded by the developer and system messages promoted to be visible by external systems. At <b>1070</b>, one or more artifacts include information that document the operation and structure of the resource such as for example, wiring diagrams, warranties, payroll, parts supplier information, and so forth. Visualization aspects include associated graphics that present the resource state and properties to applications interacting with the resource. Some examples include: faceplates, icons, edit dialogs, help files, and state overlays. At <b>1080</b>, system messages allow modules to identify, extract/receive and publish data model messages to external components. Inbound messages are typically used to manage modules (configure, initialize, propagate properties, and so forth) and publish messages on module activity (resource state, data model messages, and so forth).

0083Turning to <figref idref="DRAWINGS">FIG. 11</figref>, example resource control modules <b>1100</b> are illustrated. In general, resource control modules <b>1100</b> provide simple control of one or more resources. The resource control module (RCM) <b>1100</b> represents the logic to manage the state or data of the resource and may contain other resource control modules to achieve its respective functionality. The RCM <b>1100</b> provides public interfaces via actions and properties. In some cases, an action may be a simple bit value or a request value that is interfaced to internal values in the module and in other cases more complex logic can be provided. The RCM <b>1100</b> can include other resource control modules and may promote a command to be represented as a segment resource control interface. At <b>1110</b>, an Equipment Control Module (Common name=“Control Module”) CM is depicted. The CM can be the simplest form of basic regulatory control of equipment for an industrial environment. Further, the CM can encapsulate the equipment and its control such as control of values, drives, and so forth. At <b>1120</b>, a Material Control Module (MCM) can be provided. Management of Material resource instances which are represented as sub-lots including change in location, quality status, availability, order status, logic that can be performed on material sub-lots, generation of material events such as consumed, produced and moved events, sub-lot combination, expiry dates, and so forth.

0000At <b>1130</b>, a Personnel Control Module (PCM) is provided. This includes management of individual people such as Active, Idle, Break states directly or via shift schedules. This also includes data associated with people such as shift time patterns, for example. Other attributes that may be managed by PCM <b>1130</b> are a person's location in a plant (e.g., by way of GPS), qualification checks, or current assignment, for example. At <b>1140</b>, a Segment Control Module (SCM) includes manipulation of simple segment tasks such as piping paths, AGV paths, device state machines, robotic sequences and so forth. The SCM <b>1140</b> typically performs an action on one segment such as next step to execute after the current step. At <b>1150</b>, a Storage Control Module (STGCM) includes Manipulation of simple storage logic such as buffer capacity and ordering into and out of a queue for the respective storage unit or requirement.

0084<figref idref="DRAWINGS">FIG. 12</figref> illustrates a resource module <b>1200</b> for an industrial control system. Resource modules <b>1200</b> extend resource control modules described above to enable coordination of resources (equipment, people, modules and so forth) and achieve synchronized application of such resources. As shown, the resource control module <b>1200</b> includes a module <b>1210</b> and a resource control interface <b>1220</b>. Resource modules <b>1200</b> are also able to represent more complex activities than resource control modules. For example, resource modules may include other resource control modules at <b>1210</b> and/or other resource modules. For example, an equipment module may leverage a subordinate material control module to represent material handling aspects or a segment module to solicit an electronic signature.

0085Before proceeding it is noted that other types of modules are possible than shown. For instance, a configuration module may include management definitions and configuration of resources—personnel, segments, equipment, segments, storage, and so forth. Another type of module includes nested modules where a module references other modules. These modules may be children of a parent module or shared from one module to another. Resource modules may include resource control modules; however resource control modules should not include resource modules. Modules can include modules focused on other resource types, for example an equipment module may include equipment modules and material modules.

0086It is also noted that while a resource module <b>1200</b> can be a resource of an industrial system, controlled and applied for a particular purpose as described herein, not all resource modules <b>1200</b> need be available as an industrial resource. For instance, the material control module subordinated by the equipment module described above can be an example of a module used as a resource. As an additional example, a configuration module can be autonomous and inaccessible for control by other modules; such a module may be available only as a reference source, for instance. Similar variations to these examples can be extrapolated and extended to other example modules described herein or known in the art.

0087<figref idref="DRAWINGS">FIG. 13</figref> illustrates example resource modules <b>1300</b> for an industrial control system. At <b>1310</b>, an Equipment Module provides coordination of equipment modules and equipment control modules to perform a process-orientated task independent of specific material e.g., In-feed, AGV controller, Conveyor, and so forth. At <b>1320</b>, a Material Module provides coordination of material modules and material control modules to perform material focused tasks e.g., Material reservation, provision, material mass balance calculation, Bill of Material management, Work order management, and so forth. At <b>1330</b>, a Personnel Module provides coordination of personnel modules and personnel control modules to perform personnel focused tasks e.g., Electronic signature collection, Security validation, certification validation, Manual control interactions, and so forth.

0088At <b>1340</b>, a Segment Module provides coordination of segment modules and segment control modules and to execute sequences of tasks represented by segments. Segments define resource requirements and ordering that can represent most production and process activities. This module provides access to more complex tasks that require specific sequences to be followed e.g., Process Analytics Technology (PAT) integration, electronic signatures collection, defect, process deviation and fault recovery processing. The segment module <b>1340</b> may also construct a sequence to be followed that can be applied as manual, automatic or semi automatic sequences (e.g., Route, recipe execution). At <b>1350</b>, a Storage Module provides coordination of storage related activities, allocation of storage to requestors, modeling of inventory calculations and so forth. This also includes interaction with higher-level systems that manage storage and inventory information.

0089<figref idref="DRAWINGS">FIG. 14</figref> illustrates an example resource control model <b>1400</b> for an industrial control system. Resource Control Interfaces are the interfaces exposed to production management systems for resource binding and arbitration purposes. The interfaces are elements of the resource control model <b>1400</b> including procedures, operations or phases. These interfaces are made available by exposure via one or more capabilities <b>1410</b> described below. Procedures, operations and phases depicted in this model <b>1400</b> are commonly referred to in association with their module resource type such as Equipment Phase, Personnel Phase, Segment Phase, or as a generic Resource Phase where no specific resource module is desired. Production management including Product Production Rules (production route or control recipe) physically bind to (reference) resource control phases to perform work. The availability of other resources <b>1420</b> such as material, equipment, personnel are considered during the binding process of product production rules to work centers (production lines, process cells, and so forth). These selection processes evaluate resource capabilities to locate the appropriate resource for the task.

0090Resource capabilities <b>1410</b> include the resource <b>1420</b> required to perform work in a production system. Consequently, resources <b>1420</b> are at the centre of efficiency, capacity, scheduling and arbitration considerations. A resource's ability to work or be available to allow work to commence is represented as resource capability at <b>1430</b>. The existence of capability <b>1430</b> associated with a resource <b>1420</b> does not make the resource available for production; the resource's capability <b>1430</b> is associated with organizational units <b>1440</b> that can support the respective resource capability. For example, an operator (personnel resource) may have qualifications for a Mixer in line <b>1</b>, where this qualification capability is only in effect with that specific mixer unless explicitly directed. Resource arbitration algorithms (e.g., first request, priority first, as described herein and like algorithms) can search for resource capabilities <b>1430</b> in the scope of organizational units <b>1440</b> they are to be executed within.

0091Resources <b>1420</b> publish capabilities to organizational units <b>1440</b> for use by system processes in a given scope. Modules are a type of resource and can be accessed directly by published capabilities <b>1410</b>. However, a more common interface to Resource Modules is via verbs that are supported by the Resource Module noted above. These verbs are Resource Control elements (phases, operations, procedures . . . ) which are segments. A published capability of a resource module is typically one of the phases supported by the module. Resource control interfaces are published (made available) to the outside world as capabilities <b>1410</b>. Resource modules provide the ability to promote a command to become a resource control interface.

0092Some process control systems are built using only Resource control modules (especially control modules). Examples of this are continuous processes such as petrochemical and heavy chemical plants. In order to initiate, the process takes a plant up to its running state or makes a change to the state of a series of commands that are initiated and coordinated to achieve the new state. It is also possible to promote commands from resource control modules to appear as capabilities that can be accessed as “tuning knobs” for tweaking the system between system states. As shown in the model <b>1400</b>, the resource <b>1420</b> and capability can be associated with a higher-level class or abstraction <b>1450</b>.

0093What has been described above includes various exemplary aspects. It is, of course, not possible to describe every conceivable combination of components or methodologies for purposes of describing these aspects, but one of ordinary skill in the art may recognize that many further combinations and permutations are possible. Accordingly, the aspects described herein are intended to embrace all such alterations, modifications and variations that fall within the spirit and scope of the appended claims. Furthermore, to the extent that the term “includes” is used in either the detailed description or the claims, such term is intended to be inclusive in a manner similar to the term “comprising” as “comprising” is interpreted when employed as a transitional word in a claim.