Patent Description:
Electrical switchgear generally refers to an assemblage of circuit switching devices, such as circuit breakers, fuses, switches, relays, and the like, that are used to control, protect, and isolate electrical equipment. The circuit switching devices are typically housed together in a metal enclosure commonly referred to as a switchgear. One or more switchgear may then be combined to form a power control system. Such switchgear are usually installed in power distribution stations and substations, as well as medium to large commercial buildings and industrial facilities.

Modern switchgear have highly complex designs with numerous internal and external components and connections that work together. Thus, in most instances, the switchgear needs to undergo a commissioning process before it can be brought online and, indeed, before it leaves the factory floor. The commissioning process thoroughly checks and confirms that the switchgear and the various components therein are working within specified tolerances.

Part of the commissioning process involves performing one or more power control sequences where the switchgear circuit switching devices are turned on and off or off and on, switched, disconnected, toggled, reset, and the like, in a specific order or sequence. A power control sequence can also purposely fail a switching device, such as a circuit breaker, during a sequence in order to verify the switchgear responds properly, for example, by switching to a different power source or backing out of the current sequence. Normally, when a power control sequence is run, commissioning personnel are required to observe the switchgear and manually document step-by-step whether the switchgear has completed the specified power control tasks in the specified order and timing. However, many of these tasks and even entire sequences can pass extremely quickly, such that the commissioning personnel have to run a sequence multiple times before they can be sure the switchgear completed the sequence successfully. Disclosures related to protective relays can be found in <CIT>, <CIT> and <CIT>.

Embodiments of the present disclosure relate to systems and methods for automatically verifying correct completion of a power control sequence in a switchgear. The methods and systems provide a commissioning agent that includes a sequence verification tool. The verification tool can initiate performance of a sequence in the switchgear and immediately compare the sequence actually performed to the sequence intended to be performed, as stored in one or more sequence tables. If the two sequences do not match in order and timing, the verification tool reports the mismatch and identifies the error. In some embodiments, the commissioning agent further includes a log viewer that captures the sequence actually performed in the switchgear and displays the result for viewing. Such an arrangement provides a faster and more reliable way to double-check the system integrity of the switchgear during initial engineering and after factory and/or field modifications.

In general, in one aspect, the present invention relates to a switchgear control module according to claim <NUM>.

In general, in another aspect, the present invention relates to a method according to claim <NUM> of verifying performance of a power control sequence in a switchgear.

In general, in yet another aspect, the present invention relates to a switchgear according to claim <NUM>.

In accordance with any one or more of the foregoing embodiments, the verification is performed after the switchgear controller completes performance of the plurality of sequence steps of the power control sequence, and/or the verification is performed on a step-by-step basis as the switchgear controller completes each sequence step of the plurality of sequence steps.

In accordance with any one or more of the foregoing embodiments, an actual event and an expected event that caused the event mismatch identified by the verification is displayed on the HMI, and/or a position in the event log where the event mismatch occurred for the event mismatch identified by the verification is displayed on the HMI.

In accordance with any one or more of the foregoing embodiments, the at least one sequence table specifies a timing delay for at least one sequence step, and a verification is performed that the timing delay specified by the at least one sequence table was performed by the switchgear controller for the at least one sequence step.

In accordance with any one or more of the foregoing embodiments, the switchgear controller is automatically instructed to perform a plurality of sequence steps for at least one additional power control sequence in the switchgear.

This description and the accompanying drawings illustrate exemplary embodiments of the present disclosure and should not be taken as limiting, with the claims defining the scope of the present disclosure. In some instances, well-known structures and techniques have not been shown or described in detail so as not to obscure the disclosure. Furthermore, elements and their associated aspects that are described in detail with reference to one embodiment may, whenever practical, be included in other embodiments in which they are not specifically shown or described. For example, if an element is described in detail with reference to one embodiment and is not described with reference to a second embodiment, the element may nevertheless be claimed as included in the second embodiment.

Referring now to <FIG>, an exemplary switchgear <NUM> is shown having automatic power control sequence verification capability according to embodiments of the present disclosure. The switchgear <NUM> may be any switchgear known to those skilled in the art used to control, protect, and isolate electrical equipment in power distribution stations as well as medium to large commercial buildings and industrial facilities (not expressly shown). In some embodiments, the switchgear <NUM> may be a medium or low voltage switchgear, such as any of the MV or LV series of switchgear available from Schneider Electric USA, Inc. One or more of such switchgears, including switchgears dedicated to power generation, control, and distribution, may be combined to form a power control system (PCS).

A utility power source <NUM> is connected to the switchgear <NUM> to provide main power to the switchgear <NUM>. In some embodiments, the utility power source <NUM> provides a medium voltage, such as about <NUM> kilovolts or <NUM> kilovolts at a frequency of about <NUM>. One or more backup power sources <NUM>, labeled here as Source <NUM>, Source <NUM>, Source <NUM>, are also connected to the switchgear <NUM> to provide backup power when the utility power source <NUM> is lost. These backup sources <NUM> may include, for example, one or more backup generators, solar power generators, wind power generators, alternative utility sources, and the like. The generators <NUM> and the utility power source <NUM> provide electrical power to various loads <NUM> connected to the switchgear <NUM>, such as computing equipment, processing equipment, lighting equipment, environmental control equipment, and the like, labeled here as Load A, Load B, Load C. The switchgear <NUM> is also connected to one or more automatic transfer switches (ATS) <NUM>, labeled here as ATS X, ATS Y, ATS Z, that operate to connect the various loads <NUM> to the backup sources <NUM> when the utility power source <NUM> is lost.

A switchgear control module <NUM> is mounted on the switchgear <NUM>, for example, on a front panel thereof. The switchgear control module <NUM> operates to control, protect, and isolate the various loads <NUM>. Among other things, the switchgear control module <NUM> automatically switches one or more of the loads <NUM> from the utility power source <NUM> to the backup generators <NUM> when main power is lost. Users may also enter commands in the switchgear control module <NUM> to manually operate the switchgear <NUM>. For example, users may instruct the switchgear control module <NUM> to initiate one or more power control sequence as part of commissioning the switchgear <NUM>. To this end, the switchgear control module <NUM> is equipped with a commissioning agent that can be run to automatically verify correct completion of a power control sequence in the switchgear <NUM>.

<FIG> shows a more detailed view of the switchgear <NUM> according to embodiments of the present disclosure. As can be seen, the switchgear <NUM> houses a plurality of circuit switching devices, such as one or more circuit breakers <NUM>, switches <NUM>, fuses <NUM>, relays <NUM>, and the like. These circuit switching devices are connected to and controlled by the switchgear control module <NUM> to protect and isolate any electrical equipment connected to the switchgear <NUM>. In particular, a switchgear controller <NUM> in the switchgear control module <NUM> has programming that opens or closes, turns on or off, and/or connects or disconnects one or more of the circuit switching devices. This may be done, for example, when the switchgear control module switches power from one power source to another, adds a load to a power source due to surplus source capacity, or removes a load from a power source due to source over capacity. A human machine interface (HMI) <NUM>, which may be a touchscreen or other type of display, is coupled to the switchgear controller <NUM> to facilitate user control of and interaction with the switchgear controller <NUM>. A communication interface <NUM>, which may be a wired and/or wireless communication interface, is coupled to the switchgear controller <NUM> to facilitate communication with an external system (e.g., remote HMI, control room, SCADA system, etc.).

The switchgear controller <NUM> is also programmed or otherwise stores programming that controls various aspects of the switchgear <NUM>. Any suitable switchgear controller may be used as the switchgear controller <NUM>, such as any of the switchgear controllers available from Schneider Electric USA, provided it has sufficient computing capacity for the purposes herein. Among the programming in the switchgear controller <NUM> are several operational components, including a sequencer <NUM>, one or more sequence tables <NUM>, and an event logger <NUM>. These components operate together in the switchgear controller <NUM> in a known manner to provide power control sequence verification functionality that can be used to perform commissioning of the switchgear <NUM>.

In addition to the above operational components <NUM>, <NUM>, <NUM>, the switchgear controller <NUM> is also programmed or otherwise stores programming for a commissioning agent <NUM>. The commissioning agent <NUM> is designed to leverage the existing power control sequence functionality in the switchgear controller <NUM> to automatically initiate a power control sequence in the switchgear <NUM> and immediately verify whether the sequence was performed correctly. To accomplish this feature, the commissioning agent <NUM> uses several subcomponents, including an event log viewer <NUM>, sequence verification logic <NUM>, and a sequence verification tool <NUM>, among other components.

The sequencer <NUM>, when commanded by the switchgear controller <NUM>, runs one or more specified power control sequences that are intended to test whether the switchgear <NUM> is operating as designed. The one or more power control sequences to be run may be specified by programming residing in the switchgear controller <NUM> or they may be manually entered by the user (via the HMI <NUM>). In a typical implementation, the sequencer <NUM> looks up or obtains these one or more power control sequences from the one or more sequence tables <NUM>. Each sequence table <NUM> has a listing or sequence of steps and, depending on the specific table, a list of event IDs or a list of event timing delays, that defines the power control sequence. The sequencer <NUM> accesses the one or more sequence tables <NUM>, finds the specified sequence, and carries out the steps set forth in the sequence. The event logger <NUM> generally records every event that occurs in the switchgear <NUM>, including the steps of any power control sequence run by the sequencer <NUM>, and stores these events in an event log.

A simplified example of a power control sequence may include the following steps: <NUM>) close the circuit breaker connecting the backup generator, <NUM>) open the switch connecting the UPS, and <NUM>) disconnect the relay connecting the load, in that order. These sequences are usually performed during commissioning of the switchgear <NUM> prior to shipping from the factory and again during initial installation on-site. A sequence may be rerun after initial installation if needed, for example, when modifications are made to the switchgear after initial installation and testing.

For purposes herein, the "events" that are recorded by the event logger <NUM> refer to any transition by one of the circuit switching devices (e.g. circuit breakers <NUM>, switches <NUM>, fuses <NUM>, relays <NUM>, etc.) or other devices in the switchgear <NUM>. Thus, for example, each device transition from OFF to ON, or ON to OFF, or OPEN to CLOSE, or CLOSE to OPEN, and so forth, constitutes an "event" that is recorded by the event logger <NUM> in an event log. These events can also include power sources, such as generators and utility services, turning ON or OFF via the circuit switching devices (e.g., circuit breakers).

In accordance with embodiments of the present disclosure, the commissioning agent <NUM> is configured to initiate (or be used to initiate) a power control sequence in the switchgear controller <NUM>. The commissioning agent <NUM> does this by issuing (or causing issuance of) an appropriate command or instruction to the sequencer <NUM> in a known manner. The commissioning agent <NUM> then reads the event log for the sequence as recorded by the event logger <NUM>, and checks the steps therein against the steps of the corresponding sequence stored in the sequence tables <NUM>. More specifically, the event log viewer <NUM> of the commissioning agent <NUM> accesses a designated memory or storage location where the event logger <NUM> stores the event log and extracts or copies the steps recorded there. The event log viewer <NUM> can then display the extracted sequence steps for user viewing (e.g., on HMI <NUM>, a SCADA system, etc.) and provide the steps to other components in the commissioning agent <NUM>. The extracted sequence steps are thereafter compared by the verification logic <NUM> to the steps of the corresponding sequence in the sequence tables <NUM> to determine whether they match. If there is any mismatch, the verification logic <NUM> identifies the mismatch and reports it to the verification tool <NUM>. The verification tool <NUM> then displays the identified mismatch for user review and can also display any associated annotation that may be available. A user can also use the verification tool <NUM> to select and manually run specific sequences from the sequence tables <NUM> as part of a commissioning procedure.

In some embodiments, the switchgear controller <NUM> is a type of controller that employs a sequence of event recorder to perform the function of the event logger <NUM>. The sequence of event recorder typically has inputs that record each transition of a circuit switching device from OFF to ON or ON to OFF, OPEN to CLOSE or CLOSE to OPEN, and so forth. Each transition is assigned a separate event ID and recorded in a separate row of an internal event table (e.g., "EVENTLOG") that serves as an event log for the controller <NUM>. The timing of that transition is also recorded in the same row of an internal timing table (e.g., "EVENTLOG_TIME"), typically in HH:MM:SS:mm format, where "H" stands for hours, "M" minutes, "S" seconds, and "m" milliseconds. The date of the transition is likewise recorded in the same row of an internal date table (e.g., "EVENTLOG_DATE"), typically in a MM:DD:YYYY format, where "M" stands for month, "D" for day, and Y for year. An internal row pointer (e.g., "EVENTLOG_PTR") points to the current row in the internal event table where a new event ID is to be written. When the last row in the internal event table is reached, the pointer wraps around back to the first row of the table.

<FIG> shows an example of the one or more sequence tables <NUM> commonly implemented in switchgear controllers like the switchgear controller <NUM> to define a power control sequence. The sequence tables <NUM> are typically stored in or may be downloaded to a designated storage location or memory block in the switchgear controller <NUM>. As alluded to above, the switchgear controller <NUM> is a type of controller that uses at least two sequence tables <NUM>, a sequence table <NUM> and a sequence timing table <NUM>, to store each power control sequence. In this example, the first row in each table <NUM>, <NUM> specifies whether the table is a sequence table (e.g., "SEQUENCE_X") or a timing table (e.g., "SEQUENCE_X_TIME"), while the second row specifies the sequence number (e.g., "<NUM>") that the switchgear <NUM> can use to identify the specific power control sequence defined by the tables <NUM>, <NUM>.

The sequence table <NUM> has two lists, a sequence list <NUM> that specifies the number and order of the steps in the power control sequence, and an event ID list <NUM> that specifies the events to be performed at each step. In the <FIG> example, there are <NUM> steps in the sequence list <NUM>, hence <NUM> event IDs, with the zeroth step (step <NUM>) specifying the total number of steps in the power control sequence (<NUM> steps). The event IDs here use a convention where each circuit switching device is represented by a different number (e.g., <NUM>, <NUM>, <NUM>, <NUM>, <NUM>) and each transition of that device is represented by that number offset by <NUM>. Thus, in step <NUM>, event ID "<NUM>" (first row) indicates a transition by device <NUM> from OFF to ON, whereas event ID "<NUM>" in step <NUM> (sixth row) indicates a reverse transition by device <NUM>, and so forth. As can be seen in this example, the sequence table <NUM> defines a sequence (sequence number "<NUM>") where the devices are turned on in order of <NUM> to <NUM>, but turned off in the reverse order.

The sequence timing table <NUM> also has two lists, a sequence list <NUM> that specifies the same number and order of steps in the sequence as the sequence list <NUM>, and a timing delay list <NUM> that specifies the delay time (e.g., in seconds) between each step. In the current example, no delay times are specified and thus the timing delay list <NUM> is empty or populated with zeroes by default.

Referring now to <FIG>, an exemplary verification tool user interface <NUM> is shown representing one implementation of the verification tool <NUM> of the commissioning agent <NUM> (<FIG>). A user may use this user interface <NUM> to initiate a power control sequence in the switchgear controller <NUM> and immediately verify whether the sequence steps were completed correctly. The exemplary user interface <NUM> includes a Start button <NUM>, Stop button <NUM>, Reset button <NUM>, and Verify button <NUM>. A Sequence Number field <NUM> allows the user to choose a specific power control sequence to initiate by entering the sequence number for that sequence. Doing so automatically populates a Number of Sequences Defined field <NUM> with the number of steps specified in the selected sequence.

Pressing the Start button <NUM> captures (via the event logger <NUM>) the row number in the internal event table ("EVENTLOG") currently being pointed to by the internal row pointer ("EVENTLOG_PTR"). The captured row number is provided to the user interface <NUM> (via the event logger <NUM>), which populates that row number in a Start Position field <NUM>. The Start button <NUM> also launches the selected power control sequence (via the sequencer <NUM>), which runs automatically until all steps in the sequence are completed. The event ID for the first step in the sequence is recorded in the current row, the event ID for the next step is recorded in the next row, and so forth, until the total number of steps in the selected sequence have been completed.

Completion of the sequence steps automatically captures (via the event logger <NUM>) the row number in the internal event table where the last step in the sequence is recorded (e.g., EVENTLOG_PTR - <NUM>). It is of course also possible for the event logger <NUM> to determine the row number where the last step is (or will be) recorded by simply subtracting the total number of steps in the sequence (as defined in sequence table <NUM>) from the row number in the Start Position field <NUM>. In either case, the user interface <NUM> then populates a Stop Position field <NUM> with that last step row number. A Number of Sequence field <NUM> displays the difference between the start position row number and the stop position row number. The power control sequence may also be manually stopped if desired (e.g., to perform only part of the sequence) by manually pressing the Stop button <NUM>.

In the <FIG> example, the starting row number in the internal event table where the power control sequence was recorded is <NUM>, and the ending row number is <NUM>, reflecting a total of <NUM> steps processed, as indicated by the Number of Sequence field <NUM>. This field <NUM> should match the number in the Number of Sequences Defined field <NUM>. A mismatch between these two fields could indicate the sequence steps failed to complete correctly. When a failure is detected, the row number for the event ID in the step that caused the failure populates a Failure Position field <NUM>, the incorrect event ID populates a Failure Event Detected field <NUM>, and the expected or correct event ID populates an Expected Event field <NUM>. In some embodiments, a Test Status indicator <NUM> may be included in the user interface <NUM> to provide a visual indication of the event test status. In a similar manner, if there was a timing delay error in any the sequence steps, the row number for the event ID in the step that caused the timing failure populates a Timing Failure Position field <NUM>, the incorrect timing delay populates an Actual Time Since Last Event field <NUM>, and the expected timing delay populates an Expected Time Since Last Event field <NUM>. Where the sequence includes timing delays, the user may specify a timing tolerance (e.g., in seconds) for the selected sequence in a Timing Tolerance field <NUM>. In some embodiments, a second Test Status indicator <NUM> may be included to provide a visual indication of the timing delay test status.

<FIG> shows an exemplary event log <NUM> as extracted by the event log viewer <NUM> (<FIG>) from the internal event table mentioned above. The event log <NUM> in this example includes two lists, an event ID list <NUM> containing the event IDs that were recorded for each step of the selected sequence, and a row number list <NUM> containing the row numbers where the event IDs were recorded in the internal event table. In some embodiments, the event log viewer <NUM> may wait until all the sequence steps are completed, then obtain the entire event ID list <NUM> and row number list <NUM> for the selected sequence in one reading or one extraction (from the internal event table). In other embodiments, the event log viewer <NUM> may obtain the event ID list <NUM> and row number list <NUM> on a step-by-step basis in real time as each step is completed. In either case, event IDs in the event log <NUM> should match the event IDs in the sequence table <NUM> (<FIG>) for the selected sequence if the switchgear is operating as intended.

<FIG> shows the verification tool user interface <NUM> after the Verify button <NUM> was pressed. Pressing this button <NUM> causes the verification logic <NUM> to begin comparing the event IDs in the sequence table <NUM> and the event IDs in the event log <NUM> extracted from the internal event table. Depending on the implementation, the verification logic <NUM> may perform the verification on all the event IDs at once or on a step-by-step basis in real time as each step is completed. Regardless, if there is any mismatch between the event IDs in the sequence table <NUM> and the event log <NUM>, then the user interface <NUM> populates the failure event ID fields <NUM>, <NUM>, <NUM> accordingly. There are no mismatches in the present example, so those fields are populated with zeros by default, and the event Test Status indicator <NUM> is green-lit or otherwise visually highlighted to reflect successful completion of the sequence steps.

<FIG> show the same verification tool user interface <NUM> and event log <NUM> from <FIG>, but for illustrative purposes, the verification here was made to fail or not pass by inserting an incorrect event ID for the selected sequence. As the event log <NUM> shows, the sequence turned off devices <NUM> to <NUM> in the same order they were turned on instead of in the reverse order, as specified in the sequence table <NUM>. This order reversal caused a mismatch starting at the sixth row, or row number <NUM>, from where the sequence steps began to be recorded in the internal event table. The user interface <NUM> accordingly populates the Failure Position field <NUM> with the number "<NUM>" in <FIG>. The event ID that caused the failure is "<NUM>," so the user interface <NUM> populates the Failure Event Detected field <NUM> with the number "<NUM>. " The event ID that was expected is "<NUM>," so the user interface <NUM> populates the Expected Event field <NUM> with the number "<NUM>. " In some embodiments, the event Test Status indicator <NUM> is red-lit or otherwise highlighted to indicate the unsuccessful completion of the sequence steps.

<FIG> shows the sequence timing table <NUM> from <FIG> again, but for illustrative purposes, a time delay of <NUM> seconds was specified at the second step. <FIG> shows the verification tool user interface <NUM> from <FIG> again, but with a failed or non-passing verification due to an incorrect timing delay at the second step. As can be seen, a timing delay discrepancy occurred at the second row from where the sequence steps began to be recorded in the internal event table. The user interface <NUM> accordingly populates the Failure Position field <NUM> with the number "<NUM>. " The event at that second step was performed only <NUM> seconds after the previous event (instead of <NUM> seconds), so the user interface <NUM> populates the Actual Time field <NUM> with the number "<NUM>. " The event was expected to occur <NUM> seconds after the previous event, so the user interface <NUM> populates the Expected Time field <NUM> with the number "<NUM>. " In some embodiments, the delay Test Status indicator <NUM> is red-lit or otherwise highlighted to indicate the unsuccessful completion of the sequence steps.

<FIG> shows an exemplary ignore events table <NUM> that may be used to inform the commissioning agent <NUM> that certain events may be ignored in the power control sequence. The ignore events table <NUM> has two lists, an index list <NUM> that serves simply to enumerate events that are to be ignored in the sequence, and an events to be ignored list <NUM> that specifies the event IDs that may be ignored or skipped if found. These events may be events that can occur somewhat randomly in a working switchgear and are not necessarily failures, but events that may occur in any order in the switchgear. For example, the timing of a specific generator starting or coming online cannot always be predicted with precision. Such an event is still recorded (via the sequence of events recorder of the switchgear controller <NUM>), but it may get recorded out of sequence. The ignore events table <NUM> allows the commissioning agent <NUM> to ignore any such "random" events if they get recorded by the sequence of events recorder. In the example shown, there are <NUM> events that may be ignored if either is found, event ID "<NUM>" and event ID "<NUM>.

<FIG> show the same verification tool user interface <NUM> and event log <NUM> from <FIG>, but this time the definition of the power control sequence includes the ignore events table <NUM> from <FIG> in addition to the sequence table <NUM> from <FIG>. As can be seen in the event log <NUM>, event ID "<NUM>" and event ID "<NUM>" occurred unexpectedly during the running of the sequence. These event IDs were recorded at the third row and fifth row, respectively, in the internal event table (via the sequence of events recorder), which caused the event log <NUM> to have a total of <NUM> event IDs instead of the expected <NUM> (per sequence table <NUM>). The number of event IDs ("<NUM>") is populated in the Number of Sequences Captured field <NUM> in the user interface <NUM> and would normally cause a mismatch (via the verification logic <NUM>). However, because event ID "<NUM>" and event ID "<NUM>" are included in the ignore events table <NUM>, these events are skipped and verification is performed only on the remaining event IDs. The user interface <NUM> can accordingly indicate successful completion of the sequence steps.

<FIG> shows an example of a sequence table <NUM> in which annotations have been provided for the event IDs listed in the table. The sequence table <NUM> is similar to the sequence table <NUM> from <FIG> insofar as there is a sequence list <NUM> that specifies the number and order of the steps in the sequence, and an event ID list <NUM> that specifies the events to be performed at each step. In addition, a list of annotations <NUM> is included for the event IDs that provide users with a shorthand description or context for the events. Thus, for example, event ID "<NUM>" in the first row indicates a transition of device <NUM> from OFF to ON. The annotation for this first row explains that event ID "<NUM>" is intended to remove utility power ("Utility <NUM>") from the switchgear when there is a main power outage. Similarly, event ID "<NUM>" in the second row indicates a transition of device <NUM> from OFF to ON. The annotation for the second row explains that event ID "<NUM>" is intended to bring a backup generator ("52U1") online in case of a main power outage, and so forth.

<FIG> are an alternative event log <NUM> and alternative verification tool user interface <NUM> for the commissioning agent <NUM> that use the annotations from the sequence table <NUM> in <FIG>. The event log <NUM> is similar to the event log <NUM> from <FIG> in that there is an event ID list <NUM> containing the event IDs that were recorded (by the sequence of events recorder), and a row number list <NUM> containing the row numbers where the event IDs were recorded (in the internal event table). Additionally, an annotations list <NUM> provides users with annotations that briefly explain the event IDs in the event ID list <NUM>. In the current example, the annotations in the annotations list <NUM> are taken or otherwise extracted from the sequence table <NUM> of <FIG>. It is also possible in some embodiments for the annotations in the annotations list <NUM> to be entered manually by the user as needed. Other features of the event log <NUM> may include a date column <NUM> containing the date stamps for when the event IDs were performed, and a time column <NUM> containing the time stamps for when the event IDs took place. A Newest Row field <NUM> may be added in some cases to indicate which row is the newest row in the log, to let the user know whether the log is in forward or reverse order.

The verification tool user interface <NUM> is also similar to the verification tool user interface <NUM> from <FIG>, except that annotations are used in the user interface <NUM>. Also included in the user interface <NUM> is an option for the user to automatically run multiple sequence automatically, one after another. As can be seen, there is a Start button <NUM> and a Stop button <NUM> that capture the start and stop positions for each sequence (as recorded in the internal event table). A Steps Captured So Far button <NUM> shows the current number of steps captured for each sequence. A Sequence Number field <NUM> allows the user to choose a specific sequence to run by entering the sequence number for that sequence. Pressing a Start Sequence Test button <NUM> causes the user interface <NUM> to automatically run the selected sequence. Selecting a Keep Going to Next option <NUM> causes the user interface <NUM> to automatically run the next sequence after the current sequence has completed and any additional sequences that may be available in the switchgear controller.

In some embodiments, for a given sequence, the comparison of the steps that were actually performed against the expected steps in a corresponding sequence table may be done in real time (via the verification logic <NUM>), on a step-by-step basis as each step in the sequence is performed. In such embodiments, a Test Results field <NUM> displays any annotations associated with each step in the sequence (from sequence table <NUM>) as the step is performed. A Sequence Step Clock <NUM> shows the elapsed time (in seconds) for the current step since the previous step, and a Number of Steps in Current Sequence field <NUM> shows the total number of steps in the current sequence. A Delay Between Test field <NUM> allows the user to set a time delay (in seconds) between consecutive sequences.

The above multi-PCS, real-time verification embodiment is also implemented via the event log <NUM> of <FIG>. Here, rather than display the steps for one sequence at a time, the log maintains a rolling window of, for example, <NUM> to <NUM> steps that can span two or more sequences. When the commissioning agent starts a new sequence, the event log <NUM> green-lights or otherwise highlights each step for that sequence one at a time to indicate performance of that step. When a sequence is completed, the event log <NUM> removes the highlighting from the steps for that sequence, and begins green-lighting each step of the next sequence, and so forth. This can be seen in <FIG> where the green-lighting or highlighting on rows <NUM>, <NUM>, and <NUM> indicate that the first three steps of a new sequence were performed (successfully) at these rows, while highlighting was removed from the proceeding rows.

Referring to <FIG> again, when a wrong event ID is detected in the steps of a sequence, the user interface <NUM> reports the position of that error in a Failure Position Test Sequence Step field <NUM>. The failed event ID is reported in a Failure Event Detected field <NUM> and any annotation associated with that event ID is displayed in an associated annotations field <NUM>. The expected event ID is reported in an Expected Event field <NUM> and any annotations associated with that event ID is displayed in an associated annotations field <NUM>. An error message <NUM> is displayed that summarizes the event ID failure for the user.

Similarly, when a wrong delay time is detected in the steps of a sequence, the user interface <NUM> reports the position of that failure in a Failure Position field <NUM>. The actual delay time is reported in an Actual Time Since Last Event field <NUM>, and the expected delay time is reported in an Expected Time Since Last Event field <NUM>. Timing tolerance may be set (e.g., in seconds) by the user in a Tolerance field <NUM>, and an error message <NUM> is displayed that summarizes the timing delay failure.

<FIG> illustrate the same alternative event log <NUM> and verification tool user interface <NUM>, but where an event ID failure has been assumed for illustrative purposes. In this example, the wrong event ID was detected in the third step of the current sequence at row <NUM>. The event log <NUM> accordingly red-lights or otherwise flags the incorrect event ID and continues with the next step. The user interface <NUM> similarly reports the position of the event ID failure (i.e., step <NUM>) in the Failure Position Test Sequence Step field <NUM>. The detected event ID is reported in the Failure Event Detected field <NUM> and any associated annotation is displayed in an associated annotation field <NUM>. The expected event ID is reported in the Expected Event field <NUM> and any associated annotations is displayed in an associated annotation field <NUM>. The user interface <NUM> also displays a summary error message at <NUM>.

Thus far, specific embodiments of the present disclosure have been described. Following now is a general method that may be used with embodiments of the present disclosure.

Referring to <FIG>, a flow diagram of an exemplary method <NUM> is shown that may be used with various embodiments of the commissioning agent disclosed herein. The method generally begins at <NUM> where a power control sequence to be performed in a switchgear is selected. The selection of the power control sequence may be made automatically by programming residing in a switchgear controller, or it may be made manually by user-entry of a sequence number for the sequence using the commissioning agent. At <NUM>, the commissioning agent instructs the switchgear controller to perform the sequence steps in the selected sequence. This may be done, for example, by the commissioning agent issuing, or causing to be issued, an appropriate command to the switchgear controller. The switchgear controller then looks up the selected sequence in one or more sequence tables, typically stored at a designated storage location or memory block in the switchgear controller, and obtains the steps to be performed for the selected sequence.

At <NUM>, the commissioning agent reads or otherwise accesses an event log in the switchgear controller were the results of performing the steps of the selected sequence are recorded. This event log may be in the form of an internal event table residing at a designated storage location or memory block in the switchgear controller. At <NUM>, the commissioning agent determines the starting and ending positions in the event log for events corresponding to the steps in the selected sequence. This may be done either by capturing the starting and ending row numbers in the internal event table for events resulting from or corresponding to the steps in the selected sequence, or by capturing the starting row number and calculating the ending row number from the total number of steps in the sequence as set out in the sequence tables.

At <NUM>, the commissioning agent compares the IDs of the events between the starting and ending row numbers in the event log with the event IDs specified in the sequence tables. As mentioned earlier, this may be done on a step-by-step basis in real time as each sequence step is performed, or may be done on all event IDs together after the sequence has completed. At <NUM>, the commissioning agent outputs or otherwise presents the results of the comparison to an HMI or other type of display. This may involve presenting, for example, some or all of the sequence information in the exemplary user interface and/or event logs depicted herein. At <NUM>, the commissioning agent visually highlights any mismatches resulting from the comparison in <NUM>. This may be done, for example, by red-lighting an appropriate status indicator.

At <NUM>, the commissioning agent determines whether it should run another sequence, for example, by checking a user selected option to keep running sequences automatically. If the determination is yes, then the commissioning agent automatically selects the next power control sequence at <NUM> and returns to <NUM> to begin performing the next sequence. If the determination is no, then the commissioning agent returns to <NUM> and waits for the next power control sequence to be selected and repeats the method described above.

In the preceding, reference is made to various embodiments. However, the scope of the present disclosure is not limited to the specific described embodiments. Furthermore, although embodiments may achieve advantages over other possible solutions or over the prior art, whether or not a particular advantage is achieved by a given embodiment is not limiting of the scope of the present disclosure. Thus, the preceding aspects, features, embodiments and advantages are merely illustrative and are not considered elements or limitations of the appended claims except where explicitly recited in a claim(s).

The various embodiments disclosed herein may be implemented as a system, method or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a "circuit," "module" or "system. " Furthermore, aspects may take the form of a computer program product embodied in one or more computer-readable medium(s) having computer-readable program code embodied thereon.

Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a non-transitory computer-readable medium. A non-transitory computer-readable medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination of the foregoing. More specific examples (a non-exhaustive list) of the non-transitory computer-readable medium can include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. Program code embodied on a computer-readable medium may be transmitted using any appropriate medium, including but not limited to wireless, wireline, optical fiber cable, RF, etc., or any suitable combination of the foregoing.

Computer program code for carrying out operations for aspects of the present disclosure may be written in any combination of one or more programming languages. Moreover, such computer program code can execute using a single computer system or by multiple computer systems communicating with one another (e.g., using a local area network (LAN), wide area network (WAN), the Internet, etc.). While various features in the preceding are described with reference to flowchart illustrations and/or block diagrams, a person of ordinary skill in the art will understand that each block of the flowchart illustrations and/or block diagrams, as well as combinations of blocks in the flowchart illustrations and/or block diagrams, can be implemented by computer logic (e.g., computer program instructions, hardware logic, a combination of the two, etc.). Generally, computer program instructions may be provided to a processor(s) of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus. Moreover, the execution of such computer program instructions using the processor(s) produces a machine that can carry out a function(s) or act(s) specified in the flowchart and/or block diagram block or blocks.

The flowchart and block diagrams in the figures illustrate the architecture, functionality and/or operation of possible implementations of various embodiments of the present disclosure. In this regard, each block in the flowchart or block diagrams may represent a module, segment or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s).

Claim 1:
A switchgear control module (<NUM>) configured for connection to a switchgear (<NUM>), the switchgear control module (<NUM>) comprising:
a human machine interface HMI (<NUM>); and
a switchgear controller (<NUM>) coupled to the HMI (<NUM>), the switchgear controller (<NUM>) having a commissioning agent (<NUM>) residing therein, the commissioning agent (<NUM>) operable to:
select a power control sequence to be performed in the switchgear (<NUM>), the power control sequence being composed of a plurality of sequence steps, the sequence steps being defined in at least one sequence table (<NUM>) and include sequential transitions of at least two circuit switching devices in the switchgear (<NUM>);
instruct the switchgear controller (<NUM>) to perform the plurality of sequence steps in the switchgear (<NUM>), the switchgear controller (<NUM>) recording events resulting from the plurality of sequence steps in an event log;
determine a starting position and an ending position in the event log where the events resulting from the plurality of sequence steps were recorded;
perform a verification of the events recorded between the starting position and the ending position in the event log against events in the at least one sequence table (<NUM>) corresponding the plurality of sequence steps; and
visually highlight any event mismatch identified by the verification on the HMI (<NUM>).