Source: http://patents.com/us-9864364.html
Timestamp: 2018-01-19 06:01:52
Document Index: 167060013

Matched Legal Cases: ['Application No. 62', 'art 800', 'art 800', 'art 800', 'art 800', 'art 800']

US Patent # 9,864,364. Method and apparatus for retrieving time-based event data into unified activity hierarchy across process clusters - Patents.com
United States Patent 9,864,364
Rybarczyk , et al. January 9, 2018
Method and apparatus for retrieving time-based event data into unified activity hierarchy across process clusters
A method includes receiving notifications associated with batch execution instances executed by multiple devices. The notifications identify events occurring in an industrial process control and automation system. The method also includes creating a unique namespace for association with the notifications. The method further includes storing records identifying the notifications in a unified activity hierarchy based on the unique namespace. Creating the unique namespace could include creating an initial namespace using one or more fields associated with a parent process being executed. The parent process can activate a child process, and a namespace for the child process can contain the initial namespace and use one or more fields associated with the child process. The child process can activate a grand-child process, and a namespace for the grand-child process can contain the initial namespace and the namespace for the child process and use one or more fields associated with the grand-child process.
Rybarczyk; David F. (Phoenix, AZ), SunderKumar; Ashwath Kakde (Karnataka, IN)
Family ID: 1000003051470
14/577,657
US 20160132043 A1 May 12, 2016
62076841 Nov 7, 2014
Current CPC Class: G05B 19/418 (20130101); G06F 9/542 (20130101); G06F 11/0775 (20130101); G06F 11/0769 (20130101); G05B 2219/31288 (20130101)
Current International Class: G05B 19/418 (20060101); G06F 9/54 (20060101); G06F 11/07 (20060101)
Field of Search: ;700/11
7653721 January 2010 Romanov
9367579 June 2016 Kumar
2006/0074714 April 2006 Aziz
2006/0271341 November 2006 Brown
2008/0010641 January 2008 Zhao
2011/0257767 October 2011 Worek
2014/0137086 May 2014 Chamieh
European Search Report issued for EP 15193054.2 dated Mar. 29, 2016, 10 pgs. cited by applicant .
Wikipedia, "SCADA", URL: https://en.wikipedia.org/w.index.php?title=SCADA&oldid=632691050, XP002755067, dated Nov. 6, 2014, 10 pgs. cited by applicant .
Wikipedia, "Unique Key", URL: https://en.wikipedia.org/w.index.php?title=Unique.sub.--Key&oldid=6316417- 85, XP002755068, dated Oct. 29, 2014, 6 pgs. cited by applicant .
Wikipedia, "Namespace", URL: https://en.wikipedia.org/w.index.php?title=Namespace&oldid=629888686, XP002755050, dated Oct. 16, 2014, 10 pgs. cited by applicant.
This application claims priority under 35 U.S.C. .sctn.119(e) to U.S. Provisional Patent Application No. 62/076,841 filed on Nov. 7, 2014, which is hereby incorporated by reference in its entirety.
1. A method comprising: receiving, by an interface, notifications associated with batch execution instances executed by multiple devices, the notifications identifying events occurring in an industrial process control and automation system; creating, by a processor, an initial namespace using one or more fields associated with a parent process being executed; receiving, by the interface, a start event notification in response to the parent process activating a child process; creating, by the processor, a unique namespace for the child process containing the initial namespace and one or more fields associated with the child process; storing, by the processor, records identifying the notifications in a unified activity hierarchy based on the unique namespace; and providing a unified batch view of the notifications for events of procedure execution instances that span the multiple devices.
2. The method of claim 1, further comprising: receiving a second start event notification in response to the child process activating a grand-child process; wherein creating the unique namespace further comprises creating a namespace for the grand-child process containing the initial namespace and the namespace for the child process and using one or more fields associated with the grand-child process.
3. The method of claim 2, further comprising: using event type definitions to map the start event notifications from the devices to different event records to be recorded in the unified activity hierarchy.
4. The method of claim 1, further comprising: caching one or more event notifications associated with the child process received before the start event notification is received from the parent process; wherein the unique namespace for the child process is created after the start event notification is received from the parent process.
5. The method of claim 1, wherein the unified activity hierarchy represents a single table.
6. The method of claim 1, wherein the multiple devices comprise multiple notification servers.
7. The method of claim 1, wherein the parent process and child process are executed on different servers of the multiple devices.
8. The method of claim 1, wherein the one or more fields associated with the child process includes at least one of a phase block name, an issuing block identifier, or a loop count.
9. The method of claim 1, wherein one or more event notifications associated with the child process are received out-of-order and cached until the start event notification is received.
10. The method of claim 1, wherein the one or more fields associated with the child process include a description field that contains a unique issuing block identifier of the parent process.
11. The method of claim 1, wherein receiving the notifications comprises receiving an event notification associated with the child process of a first device of the multiple devices prior to the start event notification, and further comprising: storing the event notification in a cache, wherein the start event notification, related to the event notification, is received from a second device of the multiple devices, and wherein creating the unique namespace comprises creating the unique namespace for the event notification of the first device as a child of the start event notification.
12. An apparatus comprising: at least one interface configured to: receive notifications associated with batch execution instances executed by multiple devices, the notifications identifying events occurring in an industrial process control and automation system; and receive a start event notification in response to a parent process activating a child process; and at least one processing device configured to: create an initial namespace using one or more fields associated with the parent process being executed; create a unique namespace for the child process containing the initial namespace and one or more fields associated with the child process; store records identifying the notifications in a unified activity hierarchy based on the unique namespace; and provide a unified batch view of the notifications for events of procedure execution instances that span the multiple devices.
13. The apparatus of claim 12, wherein: the at least one processing device is further configured to receive a second start event notification in response to the child process activating a grand-child process; and the at least one processing device is configured to create the unique namespace further by creating a namespace for the grand-child process containing the initial namespace and the namespace for the child process and using one or more fields associated with the grand-child process.
14. The apparatus of claim 12, further comprising: a cache configured to temporarily store one or more event notifications associated with the child process that are received before the start event notification is received from the parent process; wherein the at least one processing device is configured to create the unique namespace for the child process after the start event notification is received from the parent process.
15. The apparatus of claim 12, wherein the at least one processing device is further configured to use event type definitions to map the start event notifications from the devices to different event records to be recorded in the unified activity hierarchy.
16. The apparatus of claim 12, wherein the unified activity hierarchy represents a single table.
17. A non-transitory computer readable medium embodying a computer program, the computer program comprising computer readable program code that when executed causes at least one processing device to: receive notifications associated with batch execution instances executed by multiple devices, the notifications identifying events occurring in an industrial process control and automation system; create an initial namespace using one or more fields associated with a parent process being executed; receive a start event notification in response to the parent process activating a child process; create a unique namespace for the child process containing the initial namespace and one or more fields associated with the child process; store records identifying the notifications in a unified activity hierarchy based on the unique namespace; and provide a unified batch view of the notifications for events of procedure execution instances that span the multiple devices.
18. The non-transitory computer readable medium of claim 17, wherein: the computer program further comprises computer readable program code that when executed causes the at least one processing device to receive a second start event notification in response to the child process activating a grand-child process; and the computer readable program code that when executed causes the at least one processing device to create the unique namespace further comprises computer readable program code that when executed causes the at least one processing device to create a namespace for the grand-child process containing the initial namespace and the unique namespace for the child process and using one or more fields associated with the grand-child process.
19. The non-transitory computer readable medium of claim 17, wherein: the computer program further comprises computer readable program code that when executed causes the at least one processing device to cache one or more event notifications associated with the child process received before the start event notification is received from the parent process; and the computer readable program code that when executed causes the at least one processing device to create the unique namespace for the child process comprises computer readable program code that when executed causes the at least one processing device to create the unique namespace for the child process after the start event notification is received from the parent process.
20. The non-transitory computer readable medium of claim 17, wherein the computer program further comprises computer readable program code that when executed causes the at least one processing device to: use event type definitions to map the start event notifications from the devices to different event records to be recorded in the unified activity hierarchy.
This disclosure relates generally to industrial process control and automation systems. More specifically, this disclosure relates to a method and apparatus for retrieving time-based event data into a unified activity hierarchy across process clusters.
A batch automation process denotes one type of process that takes place over a period of time in a control and automation system. Notifications generated during a batch execution can be used to regenerate batch activity information, which generally involves reconstructing what occurred during a prior batch execution. The regenerated batch activity information could be used to support reporting and analysis functions. Current products can typically regenerate batch activity information based on information from a single notification server.
This disclosure provides a method and apparatus for retrieving time-based event data into a unified activity hierarchy across process clusters.
In a first embodiment, a method includes receiving notifications associated with batch execution instances executed by multiple devices, where the notifications identify events occurring in an industrial process control and automation system. The method also includes creating a unique namespace for association with the notifications. The method further includes storing records identifying the notifications in a unified activity hierarchy based on the unique namespace.
In a second embodiment, an apparatus includes at least one interface configured to receive notifications associated with batch execution instances executed by multiple devices. The notifications identify events occurring in an industrial process control and automation system. The apparatus also includes at least one processing device configured to create a unique namespace for association with the notifications and store records identifying the notifications in a unified activity hierarchy based on the unique namespace.
In a third embodiment, a non-transitory computer readable medium embodies a computer program. The computer program includes computer readable program code for receiving notifications associated with batch execution instances executed by multiple devices, where the notifications identify events occurring in an industrial process control and automation system. The computer program also includes computer readable program code for creating a unique namespace for association with the notifications. The computer program further includes computer readable program code for storing records identifying the notifications in a unified activity hierarchy based on the unique namespace.
FIG. 2 illustrates an example device for retrieving time-based event data into a unified activity hierarchy across process clusters according to this disclosure;
FIG. 3 illustrates an example functional overview of a unified activity tool for retrieving time-based event data into a unified activity hierarchy across process clusters according to this disclosure;
FIG. 4 illustrates example operations of the unified activity tool to retrieve time-based event data into a unified activity hierarchy across process clusters according to this disclosure;
FIG. 5 illustrates an example graphical user interface for configuring functionality associated with the unified activity tool according to this disclosure;
FIG. 6 illustrates an example process for building a procedure event table according to this disclosure;
FIG. 7 illustrates an example mapping of events to event types in a procedure event table according to this disclosure;
FIGS. 8A and 8B illustrate an example chart containing definitions for various types of batch events generated by a process cluster that can be mapped into a procedure event table according to this disclosure;
FIGS. 9A through 9E illustrate examples of how a procedure event table namespace can be constructed from batch events generated by a process cluster using methods described in this disclosure;
FIG. 10 illustrates an example use of an event cache to facilitate out-of-order event processing by the unified activity tool according to this disclosure; and
FIGS. 11 through 17 illustrate example details of a specific software implementation of the unified activity tool according to this disclosure.
In the Purdue model, "Level 1" may include one or more controllers 106, which are coupled to the network 104. Among other things, each controller 106 may use the measurements from one or more sensors 102a to control the operation of one or more actuators 102b. For example, a controller 106 could receive measurement data from one or more sensors 102a and use the measurement data to generate control signals for one or more actuators 102b. Each controller 106 includes any suitable structure for interacting with one or more sensors 102a and controlling one or more actuators 102b. Each controller 106 could, for example, represent a multivariable controller, such as a Robust Multivariable Predictive Control Technology (RMPCT) controller or other type of controller implementing model predictive control (MPC) or other advanced predictive control (APC). As a particular example, each controller 106 could represent a computing device running a real-time operating system.
As described above, conventional industrial process control and automation systems can include products that use notifications generated by a single notification server to regenerate batch activity information associated with a batch automation process. Unfortunately, these products require a batch instance to be executed on a single notification server, and a unified namespace can only be created based on the event sequencing for that single notification server. Many industrial process control and automation systems actually include multiple servers that can function as notification servers (such as any of the controllers shown in FIG. 1 that are implemented as servers), and these servers can be grouped into multiple process clusters.
In accordance with this disclosure, one or more components of the system 100 support the use of a unified activity tool 154 for creating and managing a unique namespace across multiple process servers to create a unified activity hierarchy for batch execution instances. The unified activity tool 154 can collect information (such as notifications) from the multiple servers and associate the information with the appropriate devices within a unique namespace that spans across the multiple servers. For example, a batch activity hierarchy can be maintained by creating and maintaining a unique namespace for a single batch execution instance, and this strategy can be applied to all batch execution instances. Among other things, this approach does not require a single batch instance to be executed on a single notification server or a unified namespace to be created based on the event sequencing of a single notification server. Rather, this approach can build a unified namespace even if batch instances are executed across multiple notification servers in any server order.
In this way, the unified activity tool 154 supports techniques for creating and managing a unique namespace across process servers to produce a unified activity hierarchy for any batch execution instance. This can, for example, allow the regeneration of batch activities from multiple notification servers using the unified hierarchy when notifications are dispersed across the multiple notification servers.
The unified activity tool 154 includes any suitable structure supporting the creation or use of a unified activity hierarchy to associate time-based notifications with devices in an industrial process control and automation system. The unified activity tool 154 could, for example, represent a computing device having at least one processor, at least one memory, and at least one network interface. The unified activity tool 154 could represent a stand-alone component (such as a computing device designated solely for this purpose) or be integrated into another component (such as a computing device implementing control functionality on some level of the system 100). The logic of the unified activity tool 154 could be implemented using hardware components only or using hardware components and software/firmware instructions.
Additional details regarding specific implementations of the unified activity tool 154 are provided below. In some embodiments, the unified activity tool 154 can be realized as a set of software components collected into a service called a Process Event Processor (PEP). Also, in some embodiments, the PEP can connect to multiple HONEYWELL EXPERION clusters or other notification servers and process notifications from the clusters into regenerated batch activities that are stored as a single structure in a relational database (such as in the historian 141). One example way this can be practiced is by a Manufacturing Execution System (MES), which can extract information from a single table (called a procedure event table or "PET") for purposes of advanced analysis or regulatory compliance. Another way this can be practiced is by providing post-execution plant operational information for reports and queries.
In particular embodiments, the industrial process control and automation system 100 can support the use of unit control modules (UCMs), class based recipes (CBRs), recipe control modules (RCMs), sequential control modules (SCMs), control modules (CMs), and phase control modules (PCMs). Various notifications generated by these components could be stored in a PET and managed as described here. Additional details regarding these types of modules are provided in U.S. Pat. Nos. 7,630,777 and 8,429,654 (both of which are hereby incorporated by reference in their entirety).
Although FIG. 1 illustrates one example of an industrial process control and automation system 100, various changes may be made to FIG. 1. For example, a control system could include any number of sensors, actuators, controllers, servers, operator stations, networks, and unified activity tools. Also, the makeup and arrangement of the system 100 in FIG. 1 is for illustration only. Components could be added, omitted, combined, or placed in any other suitable configuration according to particular needs. Further, particular functions have been described as being performed by particular components of the system 100. This is for illustration only. In general, process control systems are highly configurable and can be configured in any suitable manner according to particular needs. In addition, FIG. 1 illustrates an example environment in which time-based event data can be placed into a unified activity hierarchy. This functionality can be used in any other suitable device or system.
FIG. 2 illustrates an example device 200 for retrieving time-based event data into a unified activity hierarchy across process clusters according to this disclosure. The device 200 could, for example, represent any suitable device in the system 100 of FIG. 1 providing the unified activity tool 154.
Although FIG. 2 illustrates one example of a device 200 for retrieving time-based event data into a unified activity hierarchy across process clusters, various changes may be made to FIG. 2. For example, various components in FIG. 2 could be combined, further subdivided, or omitted and additional components could be added according to particular needs. Also, computing devices can come in a wide variety of configurations, and FIG. 2 does not limit this disclosure to any particular configuration of computing device.
FIG. 3 illustrates an example functional overview 300 of the unified activity tool 154 for retrieving time-based event data into a unified activity hierarchy across process clusters according to this disclosure. As shown in FIG. 3, notifications 302 associated with various events are received at a process event processor (PEP) 304, which processes and stores the event notifications 302 in a procedure event table (PET) 306. One purpose of the PET 306 is to provide a unified batch view of the event notifications 302, and the PEP 304 leverages its namespace generation capabilities to create a unified batch instance collection in the PET 306. The PET 306 is therefore a single table representation of the batch events for procedure execution instances, even if the events from a single execution instance span multiple process servers.
The PET 306 here represents a single table containing a batch events list in a unified namespace. The PET 306 provides a flattened view of a database of batch events. The PET 306 can be used to support various functions. For example, an MES could monitor the single table forming the PET 306 and trigger various actions in response to events in the PET 306. As another example, various regulated industries may be required to monitor and store batch events to support functions like advanced analysis or regulatory compliance.
The PEP 304 includes any suitable structure for creating and managing a unique namespace to create a unified activity hierarchy for batch execution instances. The PEP 304 could, for example, include various software routines or other algorithms executed by one or more processors. The PET 306 includes any suitable structure for storing batch events. The PET 306 could, for instance, denote one or more memories.
Although FIG. 3 illustrates one example of a functional overview 300 of a unified activity tool 154 for retrieving time-based event data into a unified activity hierarchy across process clusters, various changes may be made to FIG. 3. For example, event notifications 302 could be received from any number of sources.
FIG. 4 illustrates example operations of the unified activity tool 154 to retrieve time-based event data into a unified activity hierarchy across process clusters according to this disclosure. As shown in FIG. 4, there are multiple event notification server sources 402a-402c of event notifications. Each event notification here includes an event time associated with an event and an event identifier (Event ID) associated with the event. Each event notification also includes an execution identifier (Execution ID), which can identify a thread of execution for a procedure execution instance. The Execution ID can be common to all procedure levels of a single procedure execution instance. Each event notification further includes a condition name, a subcondition name, a source, a description, and a value of the event. These fields are commonly associated with events in an industrial process control and automation system. Each source 402a-402c generally denotes any suitable structure for generating events, such as a notification server.
The PEP 304 operates here to receive the event notifications. The PEP 304 implements parsing, processing, sequencing, and consolidation operations for batch process events spread across multiple sources into a single unified flat table (the PET 306). The PET 306 shown here includes fields for event times, execution identifiers, batch identifiers, and activity full names of the events. Additional details regarding the data fields in the PET 306 are provided below.
Any suitable types of batch event notifications can be supported in the PET 306. Table 1 illustrates example types of event notifications that can be supported in the PET 306.
TABLE-US-00001 TABLE 1 Event Type Event Header Events Recipe Header - Scale Recipe Header - Version Recipe Header - Version Date Framing Events Procedure Started Unit Procedure Started Operation Started Unit Procedure Complete Operation Complete Procedure Complete Command/State Change Events State Command State Change Step Activated Step Deactivated Mode Changed Mode Command Attribute Change Active Step Change Commencing Creation Bind Recipe Events Recipe Value Parameter Download Verified Report Batch Create Events Batch Delete Beginning of Batch End of Batch
Although FIG. 4 illustrates one example of operations of the unified activity tool 154 to retrieve time-based event data into a unified activity hierarchy across process clusters, various changes may be made to FIG. 4. For example, the PEP 304 could receive event notifications from any suitable number(s) and type(s) of sources.
FIG. 5 illustrates an example graphical user interface 500 for configuring functionality associated with the unified activity tool 154 according to this disclosure. As shown in FIG. 5, the graphical user interface 500 includes a checkbox 502 that allows a user to enable or disable the use of a PET 306. The graphical user interface 500 also includes various connection entries 504 that (when PET usage is enabled) allows the user to define connections to different servers or other devices that provide event notifications.
The number of connection entries 504 shown in the graphical user interface 500 can vary depending on the implementation. For example, a "number of servers" setting in a configuration table for the PEP 304 or PET 306 can control the number of connection entries 504 shown in the graphical user interface 500. The connection entries 504 here include text boxes for manual entry of data, although any other suitable mechanism could be used to identify connections to event sources. Each PET table is configured by its server connections, which allows the PET table(s) to support servers in any combination. For example, three notification server connections could use the same PET table, or each could have its own PET table.
Although FIG. 5 illustrates one example of a graphical user interface 500 for configuring the functionality associated with the unified activity tool 154, various changes may be made to FIG. 5. For example, any other suitable input mechanism(s) could be used to enable or disable the PET 306 and identify connections.
FIG. 6 illustrates an example process 600 for building a procedure event table 306 according to this disclosure. The process 600 could be used, for example, to construct the PET 306 based on information provided via the graphical user interface 500.
As shown in FIG. 6, the process 600 includes building at least one PET 306 (which can initially be empty) at step 602. The process 600 also includes, at step 604, building a PET type table 605, which includes event type definitions for the events to be received by the PEP 304 and recorded in the PET 306. In this example, the type table 605 identifies an event type identifier, an event type name, one to three event type definition names, and an inactive flag for each event type. The inactive flag can be used to prevent the PEP 304 from generating PET records for inactive types of events. The event type identifier can be based on the event identifiers contained in an event definition table. As can be seen in FIG. 6, various event identifiers end in common numbers (such as "416" for start and "418" for end) since start and end events can occur for multiple types of events. Different suffixes (such as "1," "2," "3," and so on) can be used to distinguish between the starts and ends of different events to support the correct event mappings. In the PET type table 605, values within brackets ([Value]) denote values mapped to a Value field as shown in the chart 800 described below.
The event type definition names (EventTypeDefName1, EventTypeDefName2, and EventTypeDefName3) in the PET type table 605 are either literal values or mapped to fields in the chart 800 described below. Mapped fields are denoted by brackets [ ] in PET 605. For example, EventName, EventType fields in the PET 306 can be mapped to literal fields (EventTypeDefName1, EventTypeDefName2) in the PET 605. An EventValue field in the PET 306 can be mapped to a (EventTypeDefName3) Value mapping field in the chart 800.
In some embodiments, common fields in the PET 306 can include the fields shown in Table 2.
TABLE-US-00002 TABLE 2 EventTime Event creation time ExecutionID Execution instance unique identifier ActivityFullName Unique procedure instance identifier BatchID Batch name EventName Event name EventType Event type name EventValue Event value ProcCell Process Area Name Unit Equipment Unit Name
After the PET 306 is ready for use, the manner of PEP usage is identified from a PEP configuration page at step 606. This could include, for example, identifying the user entries in the graphical user interface 500. The PEP 304 is placed into operation at step 608 and reads the event type definitions from the PET type table 605 at step 608. At this point, the PEP 304 knows how to process incoming event notifications 302, and the PEP 304 processes the incoming event notifications 302 to generate records in the PET 306 at step 612.
Although FIG. 6 illustrates one example of a process 600 for building a PET 306, various changes may be made to FIG. 6. For example, while shown as a numbered series of steps, various steps in FIG. 6 could overlap, occur in parallel, occur in a different order, or occur any number of times.
FIG. 7 illustrates an example mapping 700 of events to event types in a procedure event table 306 according to this disclosure. As shown in FIG. 7, there is a listing 702 of events that may occur in a given system and be provided to the PEP 304. Mappings 704 associate the various events in the listing 702 with the event types identified the PET type table 605.
As can be seen here, different events in the listing 702 can be associated with the same event type in the PET type table 605. This includes the start ("416") and end ("418") events. As noted above, a numerical or other suffix can be added to distinguish between the starts and ends of different events.
This mapping 700 shows graphically the mapping of batch event notifications to PET event types. One uniqueness of this disclosure is that a batch activity hierarchy can be maintained in a single structure by creating and maintaining a unique namespace for every batch execution instance, even those that span across multiple notification servers. This disclosure is different from current products in one way because current products require a batch instance to be executed on a single notification server and a unified namespace can only be created based on event sequencing on a single notification server. This disclosure can build a unified namespace even if a batch instance is executed across multiple notification servers in any server order.
FIGS. 8A and 8B illustrate an example chart 800 containing definitions for various types of batch events generated by a process cluster that can be mapped into a procedure event table according to this disclosure. These events are for illustration only and do not limit the scope of this disclosure to the specific events shown here. The PET 306 could be used to map any other or additional events.
Each procedural level execution instance of a procedure execution instance can be associated with a unique issuing block identifier and phase block name generated by an event notification server source 402a-402c. In some embodiments, the issuing block identifier can be composed of a unique Activity ID and a phase block ID (termed $Actid-DOC). The issuing block identifier and phase block name of an initiating procedure (parent) can be contained in a SubConditionName field of a Start of Control event and passed to a subordinate procedure (child) through a Description field in FIGS. 8A and 8B. In addition, a loop count contained in a Value field of the Start of Control event can be associated with the procedure level execution instance. All procedure level execution instance events for the issuing block identifier may contain the same the phase block name. For example, these events could include Formula and Report events for a phase block associated with the issuing phase block. All subordinate procedure (child) events for the same procedure level execution instance may contain the same Description field. The subordinate (child) procedure execution instance may execute in the same event notification server source or in a different event notification server from the initiating (parent) procedure execution instance. For instance, the Description field can be used by the PEP 304 to generate the unique PET namespace levels in the PET 306 and could include Command, State, and Activation of child procedure level instances using Start of Control events.
Although FIG. 7 illustrates one example of a mapping 700 of events to event types in a PET 306 and FIGS. 8A and 8B illustrate one example of a chart 800 containing definitions for various types of batch events generated by a process cluster that can be mapped into a PET 306, various changes may be made to FIGS. 7 through 8B. For example, these mappings and definitions are for illustration only.
FIGS. 9A through 9E illustrate examples of how a procedure event table namespace can be constructed from batch events generated by a process cluster using methods described in this disclosure. In particular, FIGS. 9A through 9E illustrate examples of how the PEP 304 can construct a unified namespace that uniquely identifies events regardless of source for the PET 306.
As shown in FIG. 9A, when a new batch instance is created, a Batch Creation event can be generated by a batch manager, which is used to establish an initial namespace hierarchy. The initial namespace contains a creation time (EventTime), an execution identifier (ExecutionID), and a name of the top level procedure (Source). This initial namespace represents the prefix to be used for all child namespaces. Note, however, that any suitable field or fields could be used to create the initial namespace.
There is a parent-child relationship between batch events generated by a parent batch procedure level execution instance and events generated by a child batch procedure level execution instance. The batch events for the parent and child may or may not be executed in different process clusters. When the parent procedure level execution instance activates a child procedure level execution instance, a Start of Control event can be issued by an event notification server. The procedure level execution instance initiating event may contain a unique issuing block identifier (SubConditionName), a phase block name (Description), and a loop counter (Value). As shown in FIG. 9B, the PEP 304 creates a unique procedure level execution instance namespace for the child procedure instance that includes the initial namespace of the parent procedure and uses the Start of Control fields SubConditionName, Description, and Value issued by the notification event server. This represents a unique namespace for the procedure level execution instance, which can then be used as a namespace identifier for the procedure instance level as well as a prefix namespace for lower-level procedure level execution instances.
As an example, the phase block name, the issuing block identifier, and the loop count can be concatenated to form a unique name identifier "phaseblockname@issuingBlockID:loopcount". This unique identifier name, combined with the parent identifier namespace, forms a fully qualified namespace for the procedure level execution instance. This namespace can be maintained in an internal cache by the PEP 304 and used in the creation of the namespace of all PET 306 records for a procedure level execution instance. The phase block name can be used for parent procedure level execution events, and the issuing block identifier can be used for children events. Note, however, that any other suitable field or fields could be used to create the namespace for the child process.
As shown in FIG. 9C, when a child procedure level execution instance executes (in the same process cluster or in a different process cluster), its batch events may contain the unique issuing block identifier of the parent procedure level execution instance in the Description field. The Description field may be common to all child procedure level execution instance events of the procedure level. This allows for a single unified namespace across process clusters. Since events from clusters can be processed in any order, a cache can be used (as described below with respect to FIG. 10) to support child events processed before a parent Start of Control event.
As shown in FIG. 9D, when a grand-child procedure level execution instance executes, a Start of Control event is created that contains its own issuing block identifier (SubConditionName), phase block name (Description), and loop counter (Value), which can be passed to the grand-child. As shown in FIG. 9E, when the grand-child procedure level execution instance executes, its events contain the issuing block identifier, phase block name, and loop count information of the parent and child procedure level execution instances. Thus, the namespace of the grand-child procedure level execution instance includes the initial namespace generated for the parent procedure level execution instance and the namespace generated for the child procedure level execution instance as a prefix, along with the namespace associated with the grand-child procedure level execution instance to form a fully qualified procedure level execution instance namespace.
Although FIGS. 9A through 9E illustrate examples of how a procedure event table namespace can be constructed from batch events generated by a process cluster, various changes may be made to FIGS. 9A through 9E. For example, the specific values shown here are for illustration only and are meant to help illustrate one example process in which a unified namespace can be created. Other processes for creating a unified namespace could also be used.
FIG. 10 illustrates an example use of an event cache 1002 to facilitate out-of-order event processing by the unified activity tool 154 according to this disclosure. The cache 1002 here denotes at least one memory that can be used to temporarily store events that are being processed by the PEP 304 for storage in the PET 306. For example, the cache 1002 could denote external memory accessible by the PEP 304 or internal memory within the PEP 304.
The cache 1002 is maintained by the PEP 304 to support batch event processing across process clusters, including the handling of out-of-sequence batch events. Out-of-sequence batch events may include, for example, child batch events that do not have a parent activity because their parent Start of Control batch events have not yet been processed by the PEP 304 to create the PET namespace. The out-of-sequence batch events are managed in the cache 1002 and processed when the parent events are eventually processed.
Consider the following example defined in FIG. 10. In a first step (1), the PEP 304 receives and processes events associated with a child process from Server 3 (source 402c). However, since a Start of Control event for the child process' parent process from Server 2 (source 402b) has not yet been processed, a namespace for the child procedure instance cannot be created. In this case, the Server 3 events are cached by the PEP 304 in the cache 1002 in step (2). In Step (3), the PEP 304 processes events from Server 1 (source 402a). In step (4), events for the top-level procedure are created by the PEP 304 from the Server 1 events and recorded in the PET 306. In step (5), the Server 3 events in the cache 1002 are examined by the PEP 304, but those cached events cannot be processed yet because the parent's events from Server 2 have not yet been processed to define the child's namespace. In step (6), the PEP 304 creates a namespace and processes events from Server 2 and records the Server 2 events in the PET 306 as children of the events from Server 1. In step (7), since the parent namespace from Server 2 has been created, the PEP 304 processes the Server 3 events in the cache 1002 and records the Server 3 events as children of the Server 2 events in the PET 306.
In this manner, the PEP 304 can help to ensure that out-of-order events for child processes are not lost and are temporarily stored in the cache 1002 until the needed events for parent processes are received and processed. This allows the PEP 304 to create the unified namespace for the events even when out-of-order events are received, since the processing order of events from the sources 402a-402c cannot be predetermine.
Although FIG. 10 illustrates one example use of an event cache 1002 to facilitate out-of-order event processing by the unified activity tool 154, various changes may be made to FIG. 10. For example, the PEP 304 could use one or more caches 1002 to store events associated with any number of event sources. Also, the example process flow shown in FIG. 10 and described above is provided merely as a non-limiting way in which out-of-order events could be received and processed.
FIGS. 11 through 17 illustrate example details of a specific software implementation of the unified activity tool 154 according to this disclosure. For ease of explanation, this implementation of the unified activity tool 154 is described with respect to the control and automation system 100 of FIG. 1. However, this implementation of the unified activity tool 154 could be used in any other suitable system.
FIG. 11 illustrates an example use case 1100 for installing and configuring a PET 306. As shown in FIG. 11, a user has access to a PEP configuration tool 1102, a DOS or other command shell 1104, and a text editor 1106. The PEP configuration tool 1102 can be used to interact with a registry 1108 in order to configure a PEP service 1114. The command shell 1104 can be used to interact with an SQL or other database server service 1110, which provides access to a process automation (PA) database 1116. The text editor 1106 can be used to create database scripts 1112, which could be executed by the database server service 1110.
FIG. 12 illustrates an example sequence diagram 1200 in which components are used to install and configure a PET 306. As shown in FIG. 12, a user uses the text editor 1106 to open one or more database scripts 1112 for one or more procedure event tables during operation 1202. During operation 1204, the user uses the text editor 1106 to add PET definitions for EXPERION servers or other sources of event notifications. The user uses the text editor 1106 to save the one or more database scripts 1112 during operation 1206. During operation 1208, the user uses the command shell 1104 to select the one or more database scripts 1112. The user uses the command shell 1104 to cause the database server service 1110 to execute the one or more database scripts 1112 during operation 1210. In response, the database server service 1110 builds one or more procedure event tables in the database 1116 during operation 1212. During operation 1214, the user uses the configuration tool 1102 to select a server's tab, enter the server's procedure event table name, and accept the information. As part of operation 1214, the name(s) of the procedure event table(s) can be stored in the registry 1108.
FIG. 13 illustrates an example use case 1300 for converting events into records of a PET 306. As shown in FIG. 13, the PEP service 1114 interacts with an EXPERION or other notification database 1302. FIG. 14 illustrates an example sequence diagram 1400 in which components are used to convert events into records of a PET 306. As shown in FIG. 14, the PEP service 1114 reads one or more names of one or more PETs from the registry 1108 during operation 1402. For each process cluster, the PEP service 1114 accesses a notification database 1302 during an operation 1404. For each event from that notification database 1302, the PEP service 1114 reads an event from the notification database 1302 during an operation 1406. If the PET feature is enabled, the PEP service 1114 converts the event into a PET record during an operation 1408 and inserts the PET record into the database 1116 during an operation 1410.
FIG. 15 illustrates an example use case 1500 of the design elements for the PET 306. More specifically, FIG. 15 shows the implementation subsystem components for creating events to be recorded in the PET 306. FIG. 16 illustrates an example sequence diagram 1600 in which components are used to install and configure a PET 306. As shown in FIG. 16, the text editor 1106 is used by a user to open one or more database scripts 1112, edit PET definitions in the script(s), and save the script(s) during operation 1602. The user uses the configuration tool 1102 to read PET data from the registry 1108, enable the use of one or more PETs, enter one or more names for the PET(s), and write the data to the registry 1108 during operation 1604. The user uses the command shell 1104 to cause the database server service 1110 to execute the definition script(s) and build one or more PETs during operation 1606.
FIG. 17 illustrates an example sequence diagram 1700 in which these components, along with a PEP parser function 1702 and a PEP data access function 1704, are used to convert events into records of a PET 306. As shown in FIG. 17, the PEP service 1114 and functions 1702-1704 query the database 1116 to obtain event definitions, which are then cached, during operation 1706. During operation 1708, the PEP service 1114 queries the database 1116 for the PEP state. If enabled, the PEP service 1114 and functions 1702-1704 are used to query the notification database 1302 for any events during operation 1710. For each identified event, an event record is created and inserted into the database 1116 during operation 1712.
Although FIGS. 11 through 17 illustrate example details of a specific software implementation of the unified activity tool 154, various changes may be made to FIGS. 11 through 17. For example, the various functions shown in FIGS. 11 through 17 could be implemented using any suitable component(s). Also, the signaling shown in various figures may not completely identify all operations and signaling that occur between various components.
Previous Patent US 9,864,363 | Next Patent US 9,864,365