Patent Description:
Relays and metering are an important part of power generation, power transmission, and power consumption in electric power systems and the power grid. Relays provide monitoring and protection of equipment and personnel. Metering not only provides tracking of generation, consumption and performance, but also provides signals used for control and relaying. Accurate, repeatable and reliable relaying and metering is important. Testing to confirm accuracy, operation, health and functionality of relays, metering and power equipment may be accomplished by simulating different power system conditions. Effective and versatile test equipment is needed to minimize downtime, minimize damage to equipment, and maintain fully accurate and correct operation of power equipment.

The discussion below makes reference to a relay and metering test instrument for testing equipment such as protective relays and metering in power systems. The instrument performs this testing by providing real-time control and adjustment of the parameters that define sample waveforms being generated by the instrument for application to the equipment under test. The parameters, for each waveform output, may be: Amplitude (volts or amperes); Phase angle, relative to a reference; and frequency. For complex waveforms, such as those involving harmonics, multiple sets of amplitude, phase and frequency may be used to generate multiple waveforms, which may be summed by the instrument to produce a combined waveform.

A relay and metering test instrument according to the invention is defined by claim <NUM>.

A method of testing with a relay and metering test instrument according to the invention is defined by claim <NUM>.

A non-transitory computer readable medium according to the invention is defined by claim <NUM>.

Testing with the relay and metering test instrument involves operating the relay test instrument with an application processor circuitry that receives a source code state program and an operational parameter via a user interface as inputs by a user. The instrument may compile, with the application processor circuitry, the source code state program and the operational parameter into a test routine. The test routine may be stored in a memory circuitry with a plurality of other test routines. The instrument may independently execute, with a real time processor circuitry, the plurality of other test routines stored in the memory circuitry, and also independently execute, with the real time processor circuitry, the test routine stored in the memory circuitry to perform a plurality of respective testing stages. In addition, the instrument may generate, with an input/output processor circuitry, a waveform for equipment under test as directed by execution of the test routine.

An interesting feature of the instrument relates to directing, with the input/output processor circuitry, the real time processor circuitry to execute different respective test routines, where the different test routines are identified to the input/output processor circuitry by the application processor circuitry when the source code state program and the operational parameter(s) for a respective test routine are compiled.

Another interesting feature relates to the application processor circuitry, when storing the test routine in the memory circuitry, identifying respective memory locations in the memory circuitry of each of the respective test routines, and generating and storing respective pointers to the respective memory locations in the memory circuitry. The respective pointers may be accessed by the input/output processor circuitry to direct the real time processor circuitry to execute different respective test routines.

A further interesting feature of the instrument is that it provides the capability to dynamically alter the parameters in various ways during a test. For example, smoothly ramping a parameter by generating a sample waveform that "ramps" from a first voltage, such as <NUM> Volts to second voltage, such as 100V smoothly at a constant rate of change, such as 10V per second, until the equipment under test operates. Another interesting feature relates the capability of stepping a parameter. For example, a frequency might be adjusted to <NUM>, <NUM>, <NUM> and so on, with each frequency persisting for <NUM>/<NUM>th of a second. Yet another interesting feature of the instructions relates to the capability to provide pulsing, which is similar to ramping except that the parameter goes to some fixed value (such as zero amplitude) for a defined period of time between values, rather than stepping directly from one value to the next. Still another interesting feature relates to the capability to perform complex operations, such as non-linear ramps and binary searches.

Since the instrument is required to evaluate the timing accuracy of the operation of the equipment under test, such as protective relays, these parameter-adjustment algorithms must be performed by the instrument in a way that results in precisely-timed changes to the generated sample waveforms.

Another interesting feature relates to the instrument having the capability to alter parameters with the following desirable characteristics: Precise timing of the generated waveform adjustments; Accommodation of complex parameter-alteration algorithms; Flexibility to allow a wide variety of algorithms to be employed without changing the firmware loaded on the instrument. Conception, implementation and deployment of a new algorithm may be accomplished without requiring users to update the firmware in the test instrument.

<FIG> is a block diagram of an example of a relay and metering test instrument in communication with a testing computer and one or more pieces of power equipment under test. In <FIG>, the relay and metering test instrument <NUM> is in communication with a testing computer <NUM> executing testing software <NUM> stored in a memory circuitry <NUM>. The testing software <NUM> may be executed by processor circuitry <NUM> on the testing computer <NUM> to provide a test technician with a user interface to the relay and metering test instrument. The testing computer <NUM> may be, for example, a laptop personal computer, a tablet, a mobile phone, or any other device or system having a user interface, such as a keyboard, display screen, and the like, which is configured for bi-direction wireless or wired communication with the relay and metering test instrument <NUM>.

The relay and metering test instrument <NUM> may provide diagnostic testing of equipment under test <NUM>, which may be protective equipment such as relays, transformers, meters and any other equipment within an electric power system used to monitor and safeguard operation. Protective equipment of the type tested with the relay and metering test instrument <NUM> is referred to herein as "protective relaying equipment" or "protective relay(s). " Diagnostic testing with the relay and metering test instrument <NUM>, however, is not limited to digital, mechanical and/or electromechanical protective relays, since other monitoring devices and systems including instrument transformers, such as current/potential transformers, power system disturbance detection and/or analysis devices, and other types of systems/devices may detect and/or take appropriate action when abnormal and/or intolerable power system conditions are present.

The diagnostic testing performed by the relay and metering test instrument <NUM> may include viability/assessment testing such as relay scheme verification, digital logic testing, detection of predetermined conditions, confirmation of operation, accuracy assessment, timing, and functionality testing. The relay and metering test instrument <NUM> may be used by power utilities and others to protect equipment and facilities related to the transmission, distribution and usage of AC or DC electrical power. During operation, protective relaying equipment may monitor current and voltage waveforms being generated, conducted and/or used by the equipment or facilities being protected. In addition, such protective relaying equipment may extract characteristics from the monitored waveforms, such as the amplitude, phase angle and frequency of those waveforms' AC components. Also, such protective relaying equipment may interpret the extracted characteristics to trigger actions such as opening switches or circuit breakers to isolate protected equipment or facilities from electrical power, in order to avoid or minimize damage or undesirable conditions. Those actions may be referred to herein as "operation" of a relay output, such that an action triggered by a protective relay, may be described as a circumstance where the relay has "operated" or "operates.

The relay and metering test instrument <NUM> may test aspects of protective relaying equipment by generation of current and voltage waveforms simulating conditions that could be experienced/observed by the protective relaying equipment in various scenarios. Such scenarios, may include, for example, fault conditions that occur due to short circuits, broken conductors or damaged equipment. Current and voltage waveforms may be emitted by the relay and metering test instrument <NUM> in the form of electrical current and voltage (using voltage amplifiers and current amplifiers), or as digital data such as IEC <NUM> Sampled Values for receipt by the protective relaying equipment under test. The relay and metering test instrument <NUM> may monitor one or more outputs of the protective relaying equipment to, for example, determine whether the equipment under test triggered an event, such as the opening of a breaker in a correct and timely manner. "Outputs" of a protective relay(s) may include physical outputs, such as a contact closure(s) or change in an output voltage or current, or may be a digital output such as setting one or more bits in a data stream, or otherwise digitally communicating to trigger an event.

Generation of current and voltage waveforms by the relay and metering test instrument <NUM> may include real-time control and adjustment of dynamic parameters used to define each of the waveforms being generated. Parameters for each waveform output may include: amplitude (volts or amperes); phase angle, relative to a reference; and frequency. For complex waveforms generated by the relay and metering test instrument <NUM>, such as those involving harmonics, multiple sets of amplitude, phase and frequency can be used by the relay and metering test instrument <NUM> to generate multiple waveforms. The relay and metering test instrument <NUM> may sum the multiple waveforms generated to produce a combined waveform for output to, for example, protective relay(s).

The parameters may be altered by the relay and metering test instrument <NUM> in various ways during a test. For example, the relay and metering test instrument <NUM> may generate a test waveform having a smoothly ramping parameter, such as a voltage. For example, a waveform may be generated during testing that "ramps" from <NUM> Volts to <NUM> Volts smoothly, where smoothly, in this example is a constant and linear rise in voltage at a rate of 10V per second until the protective relay operates. In another example, the relay and metering test instrument <NUM> may generate a waveform having a stepping a parameter. For example, a parameter such as frequency might be adjusted to <NUM>, <NUM>, <NUM>, and so on, with each frequency persisting for defined time, such as <NUM>/<NUM>th of a second. In yet another example, the relay and metering test instrument <NUM> may generate a waveform having a pulsing parameter. In the example of a pulsing parameter, the pulsing may be similar to ramping except that the parameter goes to some fixed predetermined value (such as zero amplitude) for a defined period of time between values, rather than stepping directly from one value to the next. In still another example, the relay and metering test instrument <NUM> may vary parameters using complex algorithms, such as non-linear ramps and binary searches to generate the test waveforms. The relay and metering test instrument <NUM> may evaluate the timing accuracy of the protective relay's operation during such testing. Accordingly, the relay and metering test instrument <NUM> performs parameter-adjustment in a way that results in precisely-timed changes to the generated waveforms.

The example relay and metering test instrument <NUM> in <FIG> includes application processor circuitry <NUM>, real-time processor circuitry <NUM>, memory circuitry <NUM>, and input/output processor circuitry <NUM>. The application processor circuitry <NUM> may manage and control the functional operation of the relay and metering test instrument <NUM>. For example, the application processor circuitry <NUM> may include executable firmware that provides a communication interface with the testing computer <NUM>. In addition, the executable firmware may provide an interface with the memory circuitry <NUM>. The memory circuitry <NUM> may be a shared or arbitrated memory that is accessible by the real-time processor circuitry <NUM> and the input/output processor circuitry <NUM>. The real-time processor circuitry <NUM> may be in communication with the input/output processor circuitry <NUM> via one or more communication busses <NUM>. In an example, the application processor circuitry <NUM>, real-time processor circuitry <NUM>, and input/output processor circuitry <NUM> may be separate, distinct, and independently operational processor circuitry. For example, in a system on a chip (SOC) configuration, the application processor circuitry <NUM> may be a quad core ARM, the real-time processor circuitry <NUM> may be a dual core ARM, the memory circuitry <NUM> may be a DRAM, and input/output processor circuitry <NUM> may include an FPGA.

The real-time processor circuitry <NUM> administers the diagnostic tests performed by the relay and metering test instrument <NUM> by, among other things, coordinating with the input/output processor circuitry <NUM> over the communication bus <NUM> to generate test waveforms during a test state. Operation of the real-time processor circuitry <NUM> to perform a test routine <NUM> in a test state may be based on execution of any of a number of different and independent test routines <NUM> stored in the memory circuitry <NUM>. Each of the test routines <NUM> may include one or more different testing stages <NUM> that together represent at least part of a respective test state. For example, an overcurrent protective relay may be cycled through the test states of pre-fault condition where balanced current conditions are simulated, a fault condition where a three-phase or single-phase fault current conditions are simulated, and a post-fault condition where balanced current conditions are again simulated after an event, such as opening a circuit breaker to eliminate the fault. During a test state, one or more test routines <NUM> may be executed.

The relay and metering test instrument <NUM> may include any number of test routines. Accordingly, any number of test routines <NUM> may be stored in the memory circuitry <NUM>, with each of the test routines <NUM> having any number of respective testing stages <NUM>. Pointers <NUM> may be stored in the memory circuitry <NUM>. The pointers <NUM> may identify a location of a respective test routine <NUM>. The test routines <NUM> may be generated and stored in the memory circuitry <NUM> in an overlay database <NUM> by the application processor circuitry <NUM>. The application processor circuitry <NUM> may also generate and store the pointers <NUM> in the memory circuitry <NUM> in a pointer database <NUM>. The memory circuitry <NUM> may be a shared memory, such as a random-access memory (RAM) that is accessible by the application processor circuitry <NUM>, the real-time processor circuitry <NUM> and the input output processor circuitry <NUM>. Execution, by the real-time processor circuitry <NUM>, of testing stages <NUM> in a respective overlay <NUM> may be coordinated with operation of the input output processor <NUM>.

The application processor circuitry <NUM> may receive, from the testing computer <NUM>, a source code state program selected by a user, and operational parameters received as inputs from the user. The application processor circuitry <NUM> may compile the source code state program and the operational parameters into a test routine <NUM>. The test routine <NUM> may be stored in the overlay database <NUM> in the memory circuitry <NUM> with a number of other test routines <NUM>, which are accessible by the real-time processor circuitry <NUM>. In addition, the application processor circuitry <NUM> may generate pointers <NUM> identifying locations of respective test routines <NUM>. The pointers <NUM> may be stored in the pointers database <NUM> in the memory <NUM> to be accessible by the input/output processor circuitry <NUM>. The real time processor circuitry <NUM> may selectively execute test routines <NUM> according to pointers <NUM> provided by the input/output processor circuitry <NUM>. The pointers <NUM> may be provided by the input/output processor circuitry <NUM> at the time input/output processor circuitry <NUM> instructs the real time processor circuitry <NUM> to transition to another test routine <NUM>.

The input/output processor circuitry <NUM> may generate waveforms for output to the equipment under test <NUM>. The waveforms may be sinusoidal waveforms generated by the input/output processor circuitry <NUM> from waveform generation parameters calculated by the real-time processor circuitry <NUM>. In addition, the input/output processor circuitry <NUM> may receive and process input triggers received from the equipment under test <NUM>. The input triggers may be used by the input/output processor circuitry <NUM> to control the respective test routines <NUM>. The equipment under test may be, for example, one or more protective relays that sense voltage and/or current and output an output signal. For example, an overvoltage or overcurrent relay may output an over voltage/overcurrent indication, such as a digital output, a contact closure, or an analog output.

<FIG> is an example of an operational flow diagram for a relay and metering test instrument <NUM>. With reference to <FIG> and <FIG>, the operation starts with the application processor circuitry <NUM> controlling functional operation of the relay and metering test instrument <NUM> (<NUM>) to perform a test routine in a test state. Control of functional operation may be performed with firmware executed by the application processor circuitry <NUM> to, for example, manage communication, control the user interface, compile source code and operational parameters(s), manage operational parameters, manage database(s), manage data storage in the memory circuitry <NUM>, and the like.

The application processor circuitry <NUM> may receive a source code state program selected by a user, and operational parameters received as inputs from the user as part of a complete state sequence (<NUM>). The complete state sequence may include state definitions for each state or test state. The test states may be a series of states in the state sequence of a complete test. Each of the states may include transitions between states. The source code state program may be one of a number of different source code files, such as a C-language source code files, representative of a portion of a respective state definition in a state. The state definitions of the respective states in a state sequence may also include, for example, waveform generation parameters such as amplitude, phase angle, frequency, for test state functionality, which is not part of the test routines being controlled by the real-time processor <NUM>. Other example test functionality that may be included in the state definitions includes maximum duration for the state; index(s) providing transition to another state if a maximum duration is reached; other state index values that may become active under pre-specified conditions; an "inherit" Boolean value, which if true causes any value not defined for a given state to remain as it was in the previous state rather than changing to a default value; definition(s) of outputs such as binary/logic/contact outputs that may be set to a particular state during the particular state; sets of waveform sample data that may be played back, for cases where, for example, simple sinusoidal waveforms aren't appropriate; trigger definitions, indicating which inputs and other events will be processed into numbered trigger events; definition(s) of state transitions that may occur if a certain trigger event occurs, without any interaction with the real-time processor <NUM>; and the like.

The source code state program may be waveform parameter-alteration algorithms, such as smooth ramp, stepped ramp, pulsed ramp, binary search and multiple-parameter ramp source code used to generate waveform parameters. Operational parameters received as inputs from the user with the source code state program may be static operational parameters corresponding to the selected source code state program. The static operational parameters may include, for example, start and end parameters such as thresholds, setpoints, time periods and other variables that configure aspects of the respective test routine. The static operational parameters may also include "trigger" selections, which, as further described elsewhere, are related to the way events are communicated between the input/output processor circuitry <NUM> and the real-time processor circuitry <NUM> over the communication bus <NUM>. Any of the number of different source code state program files may be available and selectable by a user via the user interface provided on the testing computer <NUM>. In addition, one or more of the static operational parameters for a selected source code state program may be input via the user interface in the testing computer <NUM>.

The application processor circuitry <NUM> may compile the source code state program and the static operational parameters into a test routine <NUM> (<NUM>). The test routine <NUM> may be, for example an object file having a header that includes the static operational parameters. In other examples, other types of file structures may be used. Each time an operational parameter is updated by receipt of a user input, for example, the source code state program and the static operational parameters may be compiled into the test routine <NUM>.

The test routine <NUM> may be created by the application processor circuitry <NUM> firmware in response to commands from the user's testing software executed on the test computer <NUM>. The testing software executed on the test computer <NUM> may provide a message containing operational parameter names and values. The application processor circuitry <NUM> may package the parameter names and values in a predetermined format. For each operational parameter, the application processor circuitry <NUM> may generate an "undef" macro, to undefine a default value that's defined in the test routine <NUM>. In this way, any static parameters the user's test software and the test computer <NUM> provides may be used, and any parameters not provided may have default values. The application processor <NUM> may then "re-define" each parameter to set the value of the static parameter according to the value provided in the test routine <NUM>. Values may be presented in the test routine <NUM> as static parameters in an appropriate form to initialize a variable of the appropriate type for the particular parameter (integer, double value, boolean, etc.). Conversion functions may be defined in a header to scale values according to a type of the parameter. That way parameter initializers such as amps(<NUM>) or Hz(<NUM>) result in values that may be typed and scaled correctly.

For example, if the test routines may expect voltages to be in fixed-point integer format with <NUM> fractional bits, the conversion function may multiply the given voltage value by <NUM> and retain only the integer portion of the result. If the user's test software sends an incorrect parameter name, that parameter may still get generated as undef/define static parameter, but those parameters may be ignored by the test routine processor circuitry <NUM>. With specific static operational parameters, such as in the example shown below: arrays in the test routines code may be sized to allow simultaneous ramping of up to four separate parameters. In the below example, input trigger <NUM> may be used to sense the operation of an equipment under test, such as a relay being tested.

The application processor circuitry <NUM> may compile the source code and static parameters to generate an object file. The object file may then be stored the test routine <NUM> in the memory circuitry <NUM> (<NUM>). The test routine <NUM> may be stored with any number of other test routines <NUM> in the memory circuitry <NUM>. A memory location in the memory circuitry <NUM> of the test routine may be accessible by the real-time processor circuitry <NUM>. The real-time processor circuitry <NUM> may selectively and independently execute the test routine <NUM> or one of the other test routines <NUM> to perform a plurality of respective testing stages <NUM> when directed by the input/output processor circuitry <NUM>. Writing of the test routine <NUM> to the memory circuitry <NUM> (after compilation to generate the object file) may be executed by the application processor circuitry <NUM> while the real-time processor circuitry <NUM> is executing one of the other test routines <NUM>. The just compiled object file may be loaded as the test routine <NUM> into a RAM area in the memory circuitry <NUM> that's always accessible to the application processor circuitry <NUM> and the real-time processor circuitry <NUM>. The specific RAM area where the just compiled object file is stored as the test routine <NUM> may only get modified while the real-time processor circuitry <NUM> is not accessing that specific RAM area (between tests, or while generating another test routine other than the one that's being updated with the just compiled object file). The real-time application processor <NUM> may update its function pointer when a new pointer <NUM> is provided by a state sequencer included in the input/output processor circuitry <NUM>. The state sequencer may obtain the pointers <NUM> for all the test routines from another shared RAM area of the memory circuitry <NUM>.

The application processor circuitry <NUM> may generate a pointer <NUM> to the memory location in the memory circuitry <NUM> where the test routine is stored (<NUM>). The pointer <NUM> may be stored in the memory circuitry <NUM> by the application processor circuitry <NUM>. Different pointers <NUM> may also be stored in the memory circuitry <NUM> for each of the other test routines stored in different memory locations in the memory circuitry <NUM>.

The test routine <NUM> may be executed by the real-time processor circuitry <NUM> when test state that includes the test routine <NUM> is initiated (<NUM>). During execution of the test routine <NUM> by the real-time processor circuitry <NUM>, the input/output processor circuitry <NUM> may cooperatively operate with the real-time processor circuitry <NUM> to output test signals to the equipment under test <NUM>. In addition, the input/output processor circuitry <NUM> may monitor for receipt of input test signals, such as triggers, from the equipment under test <NUM> or from the real-time processor circuitry <NUM> (<NUM>). If a predetermined input signal is not received, the test routine <NUM> may continue to execute. If a predetermined input signal is received, the input/output processor circuitry <NUM> may direct transition, by the real time processor circuitry <NUM>, between execution of the respective test routines <NUM>.

The input/output processor circuitry <NUM> and/or the real-time processor circuitry <NUM> may dictate whether the test state being performed by execution of the test routine <NUM> is complete (<NUM>). Completion of the test state may be based on, for example, a predetermined input signal received by the input/output circuitry <NUM>, an elapsed period of time determined by the real-time processor circuitry <NUM>, or some other criteria. If the test state is not complete, execution of the test routine <NUM> in one or more testing stages <NUM> may continue. If the test state is determined to be completed, the transition between test routines <NUM> may be directed by the input/output processor circuitry <NUM> by providing commands to the real-time processor circuitry <NUM> that include a pointer <NUM> to the next test routine <NUM> (<NUM>). The input/output processor circuitry <NUM> may retrieve the pointer <NUM> from the memory circuitry <NUM>, and direct the real time processor circuitry <NUM> to execute a test routine <NUM> identified with the pointer <NUM> and the operation ends. In some examples, directing of the transitions between test routines <NUM> by the input/output processor circuitry <NUM> may be initiated by other than the input test signals.

<FIG> is a block diagram of an example relay and metering test instrument <NUM> in communication with a test computer <NUM> and an equipment under test <NUM>. In this example, the relay and metering test instrument <NUM> includes the application processor circuitry <NUM>, the real-time processor circuitry <NUM>, the memory circuitry <NUM>, and input/output processor circuitry <NUM> similar to the relay and metering test instrument <NUM> discussed with reference to <FIG> and <FIG>. Unless otherwise indicated, the features and functionality of the relay and metering test instrument <NUM> (<FIG> & <FIG>) are similar. Accordingly, for purposes of brevity the details of these features and functionality will not be repeated, however, it should be understood that such features and functionality are fully interchangeable, combinable, and/or useable in either the relay and metering test instrument <NUM> or the relay and metering test instrument <NUM>, unless otherwise indicated.

In <FIG>, the application processor circuitry <NUM> includes a compiler <NUM> for compiling the source code state programs and operational parameters received as selections included in a state sequence <NUM> from the test computer <NUM>. The state sequence <NUM> may be prepared by a user of the relay and metering test instrument <NUM> using the test computer <NUM> and provided to the relay and metering test instrument <NUM>. The user may create a test sequence <NUM> that includes a series of states as one or more test states 303A having state definitions 303B. Each of the state definitions 303B, may include, among other things, one or more source code state programs 303C. The source code state programs 303C may be compiled as object code, which is stored as a test routine <NUM> executable within a test state 303A of a state sequence <NUM>. The compiled object code of a test routine <NUM> may be stored in the test routine database <NUM> as illustrated by the compiled code line <NUM>.

The application processor circuitry <NUM> also includes a communication interface circuitry <NUM>, a user interface circuitry <NUM> and a memory manager circuitry <NUM>. The communication interface <NUM> may include functionality providing wired or wireless communication with the test computer <NUM>. In addition, communication with the real-time processor circuitry <NUM> and the input/output processor circuitry <NUM> may be handled via the communication interface <NUM>. The user interface <NUM> may provide functionality to drive visual indicators, such as lights, readouts, and/or displays and the like, and receive user input signals such as button press signals, touch screen signals, images, and the like which may be initiated by a user from hardware such as buttons, switches, a touch screen, a camera, a sensor or any other mechanical user interface included on the relay and metering test instrument <NUM>. The memory manager circuitry <NUM> may manage arbitration of the shared memory circuitry <NUM>, and may include database management capability, multi-level secure access management for authorized users and the like.

Referring to <FIG>, the real-time processor circuitry <NUM> may include executive code <NUM> to manage execution of the test routines <NUM>. In addition, the real-time processor circuitry <NUM> includes a waveform generation parameters buffer <NUM> for waveform generation parameters generated and altered by a test routine being executed during a test state 303A. Waveform generation parameters may be dynamically calculated by a respective test routine <NUM> in one or more testing stages <NUM> of the test routine <NUM>. In an example, the waveform generation parameters are phasor values (amplitude, phase angle, frequency, and the like). The waveform generation parameters may be dynamically changed or adjusted by the real-time processor circuitry <NUM> during a test state 303A, during a testing stage <NUM>, when transitioning between testing stages <NUM> or when transitioning between test routines <NUM>. The waveform generation parameters <NUM> may be dynamically changed as the relay and metering system proceeds through the test routine <NUM> based on predetermined times, logic conditions and/or events occurring during the test routine <NUM> and/or during the test state 303A. In addition, the waveform generation parameters <NUM> may be dynamically changed by receipt of dynamic operational parameters that are input by a user, such as in the test computer <NUM>.

The executive code <NUM> may be a firmware program executable with the real-time processor circuitry <NUM> to manage activation, deactivation control and execution of the test routines <NUM>. Each test routine <NUM> may reside an overlay, which becomes active when appropriate based on the sequencing of test states 303A in a respective test sequence <NUM> during a test. Sequencing of the test states 303A in a test sequence <NUM> may be controlled by the input/output processor circuitry <NUM> based on, for example, triggers and timers to transition between the test states 303A and/or between the test routines <NUM> within a test sequence <NUM> using pointers <NUM> stored in the memory circuitry <NUM>.

The memory circuitry <NUM> may include a test routines database <NUM>, a pointers database <NUM> and a report queue <NUM>. The test routines database <NUM> may store the test routines <NUM> in association with one or more memory locations <NUM>. The source code state programs, which are selectable by a user as part of one or more test states 303A in a state sequence <NUM>, and compiled to generate the test routines <NUM> may also be stored in the test routine database <NUM>. The stored source code state programs may be provided to the test computer <NUM> for selection by a user when creating a state sequence <NUM>. The source code state programs may be stored in the test routine database <NUM> at the time the firmware executable with the application processor circuitry <NUM> was developed, tested and released. Alternatively, or in addition, at least some of the source code state programs may be stored in the test computer <NUM> or accessed with the test computer <NUM> for selection for inclusion in a test state 303A of a state sequence <NUM>.

The pointers database <NUM> may include the pointers <NUM> providing a memory location <NUM> of each of the test routines <NUM> in the test routine database <NUM>. The input/output processor circuitry <NUM> may access the pointers database <NUM> according to a respective test state 303A to extract corresponding pointers and direct the real-time processor circuitry <NUM> to execute different test routines <NUM> as dictated by operation of the test sequence <NUM> when running through a series of test states 303A during a test. For example, to transition between first and second test states, the input/output processor circuitry <NUM> may retrieve and provide, to the real-time processor circuitry <NUM>, a respective pointer to a memory location <NUM> of a test routine <NUM> in order to direct execution by the real-time processor circuitry <NUM>.

The report queue <NUM> may store real-time test result values as each test routine <NUM> is executing testing stages <NUM> in a particular test state 303A for equipment under test. For example, in a test routine <NUM> for a double ramp, in which a waveform ramps down until a protective relay drops out and then ramps back up again until the protective relay picks up, the parameter values of the waveform at the time the relay dropped out may be stored and the parameter values of the waveform at the time the relay picks up may be stored as testing stage result values of the respective testing stages <NUM>. The testing stage result values may be calculated, reported, interpreted and stored by the real-time processor circuitry <NUM>. Calculation, reporting and interpretation of the testing stage result values may include analysis of differences in expected operation of the equipment under test vs. actual operation of the equipment under test. Accordingly, the real-time processor circuitry <NUM> may capture, calculate, report, interpret and store time-based situational aspects in the report queue <NUM> as a test state 303A unfolds, as illustrated in <FIG> by a test report values line <NUM>. The time-based situational aspects may be captured, calculated and stored while testing stages <NUM> of a particular test routine <NUM> is executed and input(s) and output(s) of the input/output processor circuitry <NUM> are occurring.

In addition to the static operational parameters compiled in a header file with a selected source code state program 303C, dynamic operational parameters may also be conveyed by the application processor <NUM> and stored in memory circuitry <NUM>, such as in registers in the test routine database <NUM>. The registers containing dynamic operational parameters may be updated based on new operation parameters input by a user during a test in which a test routine <NUM> is executing. For example, the user interface of the testing computer <NUM> may allow a user to manually adjust a ramp rate of a waveform during ramping of the waveform by a ramping test routine <NUM> by changing dynamic operational parameters using push buttons. Thus, the application processor circuitry <NUM> may update the storage location of the dynamic operational parameters of the ramping test routine <NUM> with a new operational parameter input by the user during execution of the ramping test routine <NUM> as illustrated with the dynamic line <NUM>. The real-time processor circuitry <NUM> may retrieve the newly stored operational parameter from the memory circuitry <NUM> during execution of a testing stage <NUM> included in the ramping test routine <NUM>. In an example, the dynamic operational parameter may be retrieved from one or more register(s) <NUM> in the memory circuitry <NUM>, by the real time processor circuitry <NUM> while executing one or more testing stages <NUM> of the ramping testing routine <NUM>. The registers <NUM> may be one or more predetermined blocks of memory storage location(s) that are writeable by the application processor circuitry <NUM> and readable by the real-time processor circuitry <NUM> during execution of the ramping test routine <NUM> by the real-time processor circuitry <NUM>.

The input/output processor circuitry <NUM> may include a state sequencer <NUM>, a waveform sample generator <NUM>, and a sample timing generator <NUM>. The state sequencer <NUM> may control progression through a series of the test states 303A in a state sequence <NUM>. In addition, to determining the current test state 303A that a particular test sequence <NUM> should be in, the state sequencer <NUM> may also identify the respective pointer <NUM> in the pointers database <NUM> for a respective test routine <NUM> included in the test state 303A that should be executed as part of the test. The state sequencer <NUM> may extract and pass the pointer <NUM> to the real-time processor circuitry <NUM>. In the example of <FIG>, the pointer <NUM> for the test routine <NUM> in the current test state 303A is passed to the real-time processor circuitry <NUM> via a function pointer line <NUM>, and a test state number of the current test state 303A is passed to the real-time processor circuitry <NUM> via the state transition line <NUM>. Thus, when the state sequencer <NUM> elects to transition from a first test state 303A to a second test state 303A in a respective test sequence <NUM>, the function pointer line <NUM> carries the pointer for a test routine <NUM> in the second test state 303A, and the state transition line changes from the first test state 303A to the second test state 303B, such as from #<NUM> to #<NUM>.

The state sequencer <NUM> also includes a trigger manager <NUM> to manage incoming and outgoing triggers <NUM> as illustrated by arrows in <FIG>. Outgoing triggers <NUM> from the state sequencer <NUM> may be provided to a respective test routine <NUM> to, for example, initiate some action or change in the testing stages <NUM> of a test routine <NUM>. For example, in the case of a double ramp test routine <NUM>, a waveform may be ramping in a first direction through one or more testing stages <NUM> until the test routine <NUM> receives an output trigger from the state sequencer <NUM> to execute one or more testing stages <NUM> to reverse the direction of the ramp to a second direction. Incoming triggers to the trigger manager <NUM> may be provided from input devices <NUM> upon receiving events <NUM> from equipment under test <NUM>. Input devices <NUM> may be opto-isolators, A/D converters, dry contacts, wet contacts and/or any other signal conversion or conditioning device or system receiving signals from an equipment under test <NUM>.

Events <NUM> may be a predefined condition, such as, for example, a contact closure in a protective relay, or a voltage reaching a predetermined threshold, or the like. Example events include an overcurrent protective relay closing a contact when an overcurrent condition is reached, or a frequency protective relay sensing a frequency and providing a representative signal outside a predetermined acceptable range. Incoming triggers <NUM> may also be provided to the state sequencer <NUM> by testing stages <NUM> in the test routines <NUM>. For example, a test routine <NUM> executing in a testing stage <NUM> may generate one or more incoming triggers <NUM> related to the progress of the testing stage <NUM>. For example, one or more incoming triggers <NUM> may be generated when a protective relay fails to sense an event when a generated waveform reaches a predetermined condition.

Each of the incoming triggers <NUM> may be identified by a unique identifier known to the state sequencer <NUM>. In addition, each of the outgoing triggers provided to the real-time processor circuitry <NUM> may be identified by a unique identifier so that the respective test routines <NUM> may receive, process and react appropriately to outgoing triggers received from the state sequencer <NUM>. Alternatively, or in addition, triggers <NUM> to and from the test routines <NUM> may be stored in the registers <NUM> or other predetermined storage locations in the memory circuitry <NUM> that are accessible by both the real-time processor <NUM> and the input/output processor <NUM>. Accordingly, as a test routine <NUM> is revised by revisions to the corresponding source code state program 303C, the interface between the trigger manager <NUM> and the test routine <NUM> may remain intact and fully operational. In addition, if the triggers <NUM> passing between the test routine <NUM> and the trigger manager <NUM> are changed as part of the revisions to the test routine <NUM>, pre-determined indexing and predetermined assigned storage locations indexed to the triggers may be used such that changes to the functionality of the state sequencer <NUM> and/or the trigger manager <NUM> may be avoided. Accordingly, more extensive updates to the firmware supporting the state sequencer <NUM> and the trigger manager <NUM> as well as the other functionality outside the test routines <NUM> may be avoided when one or more of the test routines <NUM> are updated.

Determination by the state sequencer <NUM> of a beginning and an end of respective testing stages <NUM> and/or respective test routines <NUM> and or test state 303A may be rules-based determination using predetermined rules that align with the triggers <NUM> and trigger conditions. The trigger conditions may be a current status of incoming triggers <NUM> received by the state sequencer <NUM> and outgoing triggers <NUM> generated by the state sequencer <NUM>. The state sequencer <NUM> may receive triggers <NUM> from any number of input devices <NUM> and testing routines <NUM>. In addition, each of the input devices <NUM> may generate one or more separate and distinct incoming triggers <NUM> according to event(s) <NUM>.

The waveform sample generator <NUM> may receive waveform generation parameters <NUM> from a particular testing routine <NUM> and generate waveforms therefrom. For example, the waveform sample generator <NUM> may receive phasor values for one or more waveforms, which may be summed to generate more complex waveforms, such as waveforms with superimposed harmonics, or other complex features. The waveform generation parameters <NUM> may be dynamically changed by the testing stages <NUM> of the test routine <NUM> during a test as part of the test state. In addition, the waveform generation parameters <NUM> may be dynamically changed during testing stages <NUM> by receipt of dynamic operational parameters that are input by a user and stored in the registers <NUM>. Thus, during a particular test that includes execution of a test routine <NUM>, the waveform generators may be receiving changing phasor values, such as amplitudes, phase angles, frequency and the like that coincide with the particular testing stage <NUM> of the test routine <NUM>. Since the real-time processor circuitry <NUM> is also receiving triggers, pointers, and state transitions, time synchronization of waveform changes may be precisely controlled. Parallel processing of the generation of waveform generation parameters and processing of triggers, pointers, and state transitions in the testing stages <NUM> avoids sequential processing and related lag time and delays, and allows for precise timing of dynamic adjustments of the generated waveform samples.

The waveform sample generators <NUM> may output waveform sample values <NUM> to any number of different amplifiers <NUM> included in the input/output processor circuitry <NUM> as illustrated by arrows. The amplifiers <NUM> may be current amplifiers, voltage amplifiers or both. The waveform sample values <NUM> may be used to drive the amplifiers <NUM> to output desired current and voltage sine waves <NUM> to simulate desired test conditions for equipment under test <NUM>. In addition, or alternatively, the waveform sample values <NUM> may be provided to a digital data generator <NUM>. The digital data generator <NUM> may convert the waveform sample values <NUM> to digital information. The digital information representing the waveform sample values <NUM> may be organized in data packets <NUM> for transmission over a network to the equipment under test <NUM>. Amplifiers <NUM> and digital data generator <NUM> and transmission via a network are representative ways of conveying the waveform sample values. Other conveyance platforms may be used to provide the equipment under test <NUM> with simulation of different waveforms for purposes of testing.

The sample timing generator <NUM> may be a time source to coordinate operation of the real-time processor circuitry <NUM> and the input/output processor circuitry <NUM>. Thus, the operation of the test routines <NUM>, including stepping through a number of different testing stages <NUM>, may be based on receipt of the interrupts. For example, the test routine <NUM> may enter a different testing stage <NUM> each time an interrupt is received. Alternatively, or in addition, the test routine <NUM> may, for example, remain in a testing stage <NUM> for a predetermined number of interrupts, until either a trigger is received or a determined number of interrupts are received, or any other timing/logic to provide the desired test situation/scenario for a test state 303A. Desired test situation/scenarios may include, for example, the correct waveform generation parameters <NUM>, generation of trigger(s) <NUM> in synchronism with the other processor circuitry, and the like. Thus, not only do the interrupts cause the test routine <NUM> to execute test stages <NUM>, or take no action, the interrupts also provide synchronization with operations related to the application processor circuitry <NUM> and the input/output processor <NUM>. For example, execution of a respective different testing stages <NUM> of a test routine <NUM> to generate waveform generator parameters may be synchronized with the waveform sample generators <NUM> using the interrupts.

In <FIG>, sample pulses may be output as a pulse train on a sample pulses interrupt line <NUM> to operate as an interrupt for the test routine <NUM>. The interrupts received by the real-time processor <NUM> may cause a presently executing test routine <NUM> to transition to another testing stage <NUM>, poll registers <NUM>, check for triggers <NUM> from the state sequencer <NUM>, pause and take no action, and the like. In addition, the interrupts may cause the real-time processor <NUM> to initiate execution of the test routine <NUM> to dynamically generate waveform sample values with the waveform sample generator <NUM>. In an example, the sample timing generator <NUM> may generate a <NUM> pulse train. Also, the sample timing generator <NUM> may be synchronized or disciplined to a time source.

During example execution, a test routine <NUM> may respond to an interrupt that occurs at the waveform sample generation rate (for example <NUM>), by performing calculations based on a count of the interrupts received from the sample timing generator on the sample pulses line <NUM>. In addition, the real-time processor circuitry <NUM> may execute the test routine <NUM> to dynamically calculate waveform generator parameters, such as amplitude, phase angle and frequency parameters, according to the testing stage <NUM> and/or the phase of a test state being executed and/or dynamic operational parameters received as inputs from a user. The waveform generator parameters may be written into the waveform generation parameter buffer <NUM> and stored in, for example, registers in the input/output processor circuitry <NUM>. The input/output processor circuitry <NUM> may include sample generation logic in the waveform sample generator <NUM>, which may use the parameters to generate waveforms as waveform sample values <NUM>.

The test routines <NUM> may respond to changes in the states of outgoing triggers or incoming triggers. Triggers <NUM> may, for example, be in the form of trigger bits, which may be a single bit that toggles to indicate a change, or more than one bit that provides a trigger message indicative of the change. The outgoing triggers may be provided by the state sequencer <NUM> of the input/output processor circuitry <NUM>. The outgoing triggers may be bits that responsively change state during a test state 303A, such as, for example, in response to a relay operation. Each test routine <NUM> may use the outgoing triggers in any desired fashion. For example, a binary-search test routine <NUM> may decide whether a given waveform pulse or waveform stop threshold should be higher or lower than the previous one, based on whether the equipment under test <NUM> operated during the previous pulse or step, and what was the nature of the operation.

The real-time processor circuitry <NUM> may also produce triggers, such as "trigger" bits, by writing triggers <NUM> to registers accessible to state sequencer <NUM> in the input/output processor circuitry <NUM>. Such input triggers from the real-time processor circuitry <NUM> may indicate, for example "relay operated at the correct time", "relay operated at an inappropriate time", or "relay did not operate within the allowed time limit". The state sequencer <NUM> may, for example, use the incoming triggers from the real-time processor circuitry <NUM> to decide whether to direct the real-time processor circuitry <NUM> to make a transition from one test state 303A to another test state 303A during a state sequence <NUM> or change testing stages <NUM> within the test routine <NUM> of the present test state 303A.

The real-time processor circuitry <NUM> may also write report values to the report queue buffer <NUM>, which is accessible to application processor circuitry <NUM>. The application processor circuitry <NUM> may provide the report values to the test computer <NUM> as result data. For example, if a phase angle of a simulated waveform is ramped from <NUM> to <NUM> degrees, and a phase angle protective relay operates at a test stage <NUM> when the phase angle is <NUM> degrees, the test routine <NUM> may write <NUM> degrees as a result value in the report queue buffer <NUM> to that test stage <NUM> and/or for the test routine <NUM>.

<FIG> is an operational block diagram of an example of execution of a test routine. With reference to <FIG> and <FIG>, in this example, the test routine <NUM> is a ramped test routine executed by the real-time processor circuitry <NUM> to provide a ramped waveform via the waveform sample generator <NUM>. In summary, the ramped test routine <NUM> sets a waveform amplitude to a start value, then enters one or more different test stages <NUM> and ramps the amplitude of the waveform up at a defined rate until either the connected equipment under test, such as a relay, operates or the ramp reaches a defined end value.

The example operation begins when the ramped test routine is executed by the executive code <NUM> operating as firmware in the real-time processor circuitry <NUM>. The real-time processor circuitry <NUM> is directed to transition to a test state 303A that includes the ramped test routine <NUM> by the input/output processor circuitry <NUM> providing a current state on the current state line <NUM> and a state transition number on the state transition line <NUM> (<NUM>). Once in the test state, the controlled waveform generation parameter values are set equal to the static operational parameter values (start_ value) included in the header of the object file when the source code state program 303C representing the ramp test routine <NUM> was compiled by the application processor circuitry <NUM> (<NUM>). The start ramp value may be a waveform amplitude, such as <NUM> Vac having a ramp of, for example, <NUM> volt/second, to an end ramp value, such as <NUM> Vac. The real-time processor circuitry <NUM> determines if the ramp value is greater than a value (end _value) at which the equipment under test is expected to operate (<NUM>). If yes, the real-time processor circuitry <NUM> executes the ramp test routine <NUM> to assert that the equipment under test did not operate (no_operation_trigger) (<NUM>), sends a trigger output from the real-time processor circuitry <NUM> for receipt as a trigger input to the state sequencer <NUM> (<NUM>), and ends execution of the ramp test routine <NUM>.

If the ramp value is not greater than the value at which the equipment under test is supposed to operate (<NUM>), the real-time processor <NUM> may generate waveform generator parameter(s) (<NUM>), and provide to the input/output processor circuitry <NUM> via the waveform generation parameters buffer <NUM> (<NUM>). The input/output processor circuitry <NUM> may, for example, extract the waveform generation parameters from a memory location, and provide the parameters to the waveform sample generator <NUM>, which provides waveforms or waveform samples to the equipment under test (<NUM>). The real-time processor circuitry <NUM> may then wait for the next sample-interval interrupt from the sample timing generator <NUM> (<NUM>).

The real-time processor circuitry <NUM> may determine if the event has occurred upon receipt of the sample interrupt by checking if an output trigger from the state sequencer <NUM> has been provided as an input trigger to the real-time processor (<NUM>). If yes, the real-time processor circuitry <NUM> executes the ramp test routine <NUM> to assert that the equipment under test did operate (operation_trigger) (<NUM>), and sends a trigger output from the real-time processor circuitry <NUM> for receipt as a trigger input to the state sequencer <NUM> (<NUM>). In addition, the real-time processor circuitry <NUM> calculates and records test result values including the as-ramped waveform value and the amplitude value at which the equipment under test, such as a protective relay operated (<NUM>). The test result values, including the as-ramped value may be provided to the report queue <NUM> (<NUM>). The testing computer <NUM> may read test results from the report queue <NUM> (<NUM>). Alternatively, or in addition, the test results may be pushed to the testing computer <NUM>. Execution of the ramp test routine <NUM> may cease (<NUM>).

If the output trigger from the state sequencer <NUM> has been provided as an input trigger to the real-time processor <NUM> (<NUM>), the real-time processor <NUM> may increment the amplitude value of the waveform by the ramp rate (<NUM>) by providing waveform generation parameters to the waveform sample generator <NUM>. In addition, the real-time processor <NUM> may determine if the increment caused the amplitude value to exceed the expected amplitude that should cause the equipment under test to actuate and the operation may proceed to repeat some of the previously discussed steps.

<FIG> is a block diagram of another example operation of a test routine for a piece of equipment under test. In this example, the equipment under test is described as a relay, however, in other examples, other equipment may be tested. Referring to <FIG> and <FIG>, when executed by the real-time processor circuitry <NUM>, the test routine <NUM> of this example is a multi-ramp test routine that may execute in parallel a number of waveforms, such as simple ramps, smoothly increasing or decreasing a value for each ramp. The multiple ramp waveforms may be executed in parallel until either the equipment under test, such as a relay being tested, operates, or the user's testing software on the testing computer <NUM> requests a transition out of the current state. Each time the relay operates, test result value(s) may be enqueued in the report queue <NUM> for each ramp, namely the as-ramped value at the time when the relay operated is enqueued in the report queue <NUM>. If the relay does not operate, no result values are enqueued. Each ramp optionally includes a trigger index, which may be asserted when the relay operates. In this way the test state may be structured so that a state transition occurs at the time the relay operates for any one of the ramps.

In this example, the source code state program, which is compiled into the test routine <NUM> may include one or more header files that are parameter definition files generated by the application processor circuitry <NUM>. The header files included in the test routine <NUM> may include conversion functions, such as a voltage conversion function, and the like. The test routine <NUM> may also include standardized library headers, to make use of standardized library functions and classes. In addition, the headers of the test routine <NUM> may define one or more special trigger index values, such as a special trigger index value to monitor for relay operation. In addition, the header file(s) may define default values for some or all static operational parameters. These default values may be used for any static operational parameter that is not defined in the header file.

Each ramp may also operate with a set of dynamic parameters, which may be dynamically adjusted by a user during a test while the test routine is executing. Static operational parameters, on the other hand, are set to fixed values from the header file(s) before the test routine is executed. For example, each of the ramps may include as dynamic operational parameters a start value, an end value and a ramp rate for a value, such as amplitude, being ramped. The ramp rate may be positive or negative, for upward or downward ramps. The respective ramp may stop when it hits either the start value or the end value such that the value of the respective ramp no longer changes. During a test, if the start value dynamically changes due to a user input of a change start value, the ramp may be re-started at that new start value.

Referring to <FIG> and <FIG>, example operation begins when the multi-ramp test routine is executed by the executive code <NUM> operating as firmware in the real-time processor circuitry <NUM>. The real-time processor circuitry <NUM> is directed to transition to a test state of the multi-ramp test routine <NUM> by the input/output processor circuitry <NUM> by providing a current state on the current state line <NUM> and a state transition number on the state transition line <NUM> (<NUM>). Once in the test state, the real-time processor circuitry <NUM> sets a flag indicative of operation of the equipment under test, such as a relay, to false (<NUM>). The real-time processor circuitry <NUM> may then identify the number of ramps (N) from static operational parameters included in the header file, and initialize a ramp state of the N ramp states using initial dynamic parameters (<NUM>).

The initial dynamic operational parameters may be extracted from registers <NUM> in the test routine database <NUM>. In other examples, the dynamic operational parameters may be stored in other ways in memory circuitry <NUM>. In this example, the dynamic operational parameters for each ramp N are upper limit, lower limit, and ramp value, where the ramp value may initially be equal to the lower limit. The real-time processor circuitry <NUM> may determine if all N of the ramps identified by the static operational parameter are initialized (<NUM>), and if not, initialize the remaining ramp states for the N ramps (<NUM>). The state information of each N ramp may be retained in a structure, such as an array, that is updated and monitored by the multi-ramp test routine <NUM>. The array ramp state may be initialized as state information for each of the "N" ramps.

In an example there may be maximum_ramp_count structures, each containing: An "outputValue" which may be a parameter value written to a waveform generation parameter. The "outputValue" may be calculated according to the ramp parameters "mostRecentLowerLimit," and "mostRecentUpperLimit," where copies of lowerLimit and upperLimit dynamic parameters may be used to detect when those parameters change. In this example, the dynamic parameters used may be a Dynamic Parameter RAM block, which is an array with one structure per simultaneous ramp (maximum_ramp_count elements). Values may be dynamically changed by the application processor circuitry <NUM> while this test routine is executing. Each structure may include: waveformIndex (identifies the waveform for which a generation parameter is to be ramped), destination (which parameter to ramp: amplitude, frequency or phase), lowerLimit, upperLimit, rampRate (ramping limits and rate).

Once the N ramps are initialized, the real-time processor circuitry <NUM> may set a flag indicating whether the relay operated in the previous sample interval (in order to later determine whether the input state changed) (<NUM>). The real-time processor <NUM> may then generate waveform generator parameters (<NUM>) for each of the respective N ramps using a ramp index and destination. The ramp index may be an identifier of a respective ramp N, and the destination may be a waveform generator <NUM>, which will output the respective waveform sample values <NUM> (<FIG>). The waveform generator parameters may be provided to the input/output processor circuitry <NUM> (according to the index and destination) via the waveform generation parameters buffer <NUM> (<NUM>). The waveform generator parameters, such as amplitude, phase or frequency, for each index may be retained in the buffer <NUM> between sample intervals, so the real-time processor circuitry <NUM> may detect when these parameters are changed by a user by changing the dynamic operational parameters for one of the N ramps. The input/output processor circuitry <NUM> may, for example, extract the waveform generation parameters from a memory location for a respective ramp N, and provide the parameters to the waveform sample generator <NUM>, which provides waveforms or waveform samples to the equipment under test (<NUM>).

<FIG> is a second part of the block diagram of <FIG>. Referring to <FIG> and <FIG>, the real-time processor circuitry <NUM> may confirm that waveform generation parameters have been written for all N of the ramps (<NUM>) and if not, complete the remaining N ramps (<NUM>) (<FIG>). Once all the N ramped waveform generation parameters have been written, the real-time processor circuitry <NUM> may await a next interrupt from the sample timing <NUM>. Upon receipt of an interrupt, the real-time processor circuitry <NUM> may check to see if any of the dynamic operational parameters stored in the registers <NUM> have been updated. The application processor circuitry <NUM> may update the storage location of the dynamic operational parameters with a new dynamic operational parameter <NUM> received as an input by the user for a respective ramp N during a test.

For each of the N ramps with updated dynamic operational parameters, the real-time processor circuitry <NUM> may calculate new respective waveform generation parameters, for provision with the corresponding index and destination to the input/output processor circuitry <NUM> for the next sample interval (<NUM>). The real-time processor circuitry <NUM> may then determine if the generation parameters have been calculated for all the respective N ramps (<NUM>). If not, the real-time processor circuitry <NUM> may calculate waveform generation parameters for the next one of the N ramps.

(<NUM>) according to any updates to the dynamic operational parameters <NUM>. The real-time processor circuitry <NUM> may wait for the next sample interval interrupt from the sample timing <NUM> (<NUM>). The real-time processor circuitry <NUM> may also enforce limits, such as the high and low limits when, for example, the value parameter, such as an amplitude, is updated. In the case where a new user entered dynamic value parameter <NUM> is outside the limits, the real-time processor circuitry <NUM> may force the output value into range. In addition, for those ramps N where no updated dynamic operational parameters were detected, the real-time processor circuitry <NUM> may continuing ramping for the next sample interval according to the existing dynamic operational parameters.

At the next sample-interval interrupt, the real-time processor circuitry <NUM> may determine if the relay operated (<NUM>) by reading a trigger value indexed by input_trigger, and may place the trigger value in a variable, such as a Boolean variable. A trigger state <NUM> may indicate a source of the trigger bit which caused the relay to operate. The real-time processor circuitry <NUM> may determine if the relay operated in the current sample interval due to one of the N ramps (<NUM>). If yes, the trigger for the respective ramp N may be asserted (<NUM>), and a trigger output from the real-time processor circuitry <NUM> may be provided as a trigger input to the state sequencer <NUM> (<NUM>). In response to the trigger, the real-time processor circuitry <NUM> may calculate and record test result values, including the as-ramped value, and the other dynamic operational values, for each of the N ramps. The test result values may be provided to the report queue <NUM>.

According to an aspect of the invention, the method of testing with a relay and metering test instrument (<NUM>, <NUM>) comprises generating, with the input/output processor circuitry (<NUM>), the sample waveform for the equipment under test as directed by execution of the test routine (<NUM>), said method further comprising calculating an amplitude, phase angle and frequency parameters of the sample waveform with the real time processor circuitry (<NUM>) in the respective test state; storing the amplitude, phase angle and frequency parameters of the sample waveform in registers in the memory circuitry (<NUM>); and executing the input/output processor circuitry (<NUM>) to extract the amplitude, the phase angle and the frequency parameters from the registers and generate the sample waveform.

According to an aspect of the invention, the non-transitory computer readable medium stores the instructions executable with the processor circuitry (<NUM>), said instructions executable with the processor circuitry (<NUM>) to selectively execute the test routine (<NUM>) further comprises instructions executable with the processor circuitry (<NUM>) during a plurality of testing stages (<NUM>) of the test routine (<NUM>) to generate waveform generation parameters according to the operational parameters during the respective test state, the waveform generation parameters comprising phasor values used by a waveform sample generator to generate different sample waveforms during the plurality of testing stages (<NUM>).

According to an aspect of the invention, said instructions executable with the processor circuitry (<NUM>) during the plurality of testing stages (<NUM>) of the test routine (<NUM>) to generate the waveform generation parameters according to the operational parameters further comprises instructions executable with the processor circuitry (<NUM>) to receive dynamic operational parameters input by the user during the respective test state while the sample waveforms are being generated and instructions executable with the processor circuitry (<NUM>) to update the waveform generation parameters based on the dynamic operational parameters to generate dynamically adjusted sample waveforms during the respective test state.

According to an aspect of the invention, the computer readable medium further comprises instructions executable with the processor circuitry (<NUM>) to select the test routine or one or more of the plurality of test routines (<NUM>) for execution using a respective one of the pointers.

According to an aspect of the invention, the computer readable medium further comprises instructions executable with the processor circuitry (<NUM>) to store the test routine as an update of one of the plurality of test routines (<NUM>) stored in the memory circuitry (<NUM>).

The methods, devices, processing, circuitry, and logic described above may be implemented in many different ways and in many different combinations of hardware and software. For example, as discussed, all or parts of the implementations may be circuitry that includes an instruction processor, such as a Central Processing Unit (CPU), microcontroller, or a microprocessor; or as an Application Specific Integrated Circuit (ASIC), Programmable Logic Device (PLD), or Field Programmable Gate Array (FPGA); or as circuitry that includes discrete logic or other circuit components, including analog circuit components, digital circuit components or both; or any combination thereof. The circuitry may include discrete interconnected hardware components or may be combined on a single integrated circuit die, distributed among multiple integrated circuit dies, or implemented in a Multiple Chip Module (MCM) of multiple integrated circuit dies in a common package, as examples.

Accordingly, the circuitry may store or access instructions for execution, or may implement its functionality in hardware alone. The instructions may be stored in a tangible storage medium that is other than a transitory signal, such as a flash memory, a Random Access Memory (RAM), a Read Only Memory (ROM), an Erasable Programmable Read Only Memory (EPROM); or on a magnetic or optical disc, such as a Compact Disc Read Only Memory (CDROM), Hard Disk Drive (HDD), or other magnetic or optical disk; or in or on another machine-readable medium. A product, such as a computer program product, may include a storage medium and instructions stored in or on the medium, and the instructions when executed by the circuitry in a device may cause the device to implement any of the processing described above or illustrated in the drawings.

The implementations may be distributed. For instance, the circuitry may include multiple distinct system components, such as multiple processors and memories, and may span multiple distributed processing systems. Parameters, databases, and other data structures may be separately stored and managed, may be incorporated into a single memory or database, may be logically and physically organized in many different ways, and may be implemented in many different ways. Example implementations include linked lists, program variables, hash tables, arrays, records (e.g., database records), objects, and implicit storage mechanisms. Instructions may form parts (e.g., subroutines or other code sections) of a single program, may form multiple separate programs, may be distributed across multiple memories and processors, and may be implemented in many different ways. Example implementations include stand-alone programs, and as part of a library, such as a shared library like a Dynamic Link Library (DLL). The library, for example, may contain shared data and one or more shared programs that include instructions that perform any of the processing described above or illustrated in the drawings, when executed by the circuitry.

In some examples, each unit, subunit, and/or module of the system may include a logical component. Each logical component may be hardware or a combination of hardware and software. For example, each logical component may include an application specific integrated circuit (ASIC), a Field Programmable Gate Array (FPGA), a digital logic circuit, an analog circuit, a combination of discrete circuits, gates, or any other type of hardware or combination thereof. Alternatively or in addition, each logical component may include memory hardware, such as a portion of the memory, for example, that comprises instructions executable with the processor or other processors to implement one or more of the features of the logical components. When any one of the logical components includes the portion of the memory that comprises instructions executable with the processor, the logical component may or may not include the processor. In some examples, each logical components may just be the portion of the memory or other physical memory that comprises instructions executable with the processor or other processor to implement the features of the corresponding logical component without the logical component including any other hardware. Because each logical component includes at least some hardware even when the included hardware comprises software, each logical component may be interchangeably referred to as a hardware logical component.

A second action may be said to be "in response to" a first action independent of whether the second action results directly or indirectly from the first action. The second action may occur at a substantially later time than the first action and still be in response to the first action. Similarly, the second action may be said to be in response to the first action even if intervening actions take place between the first action and the second action, and even if one or more of the intervening actions directly cause the second action to be performed. For example, a second action may be in response to a first action if the first action sets a flag and a third action later initiates the second action whenever the flag is set.

To clarify the use of and to hereby provide notice to the public, the phrases "at least one of <A>, <B>,. and <N>" or "at least one of <A>, <B>,. <N>, or combinations thereof" or "<A>, <B>,. and/or <N>" are defined by the Applicant in the broadest sense, superseding any other implied definitions hereinbefore or hereinafter unless expressly asserted by the Applicant to the contrary, to mean one or more elements selected from the group comprising A, B,. In other words, the phrases mean any combination of one or more of the elements A, B,. or N including any one element alone or the one element in combination with one or more of the other elements which may also include, in combination, additional elements not listed.

Claim 1:
A relay and metering test instrument (<NUM>, <NUM>) comprising:
an application processor circuitry (<NUM>) configured to control functional operation of the relay and metering test instrument, the application processor circuitry (<NUM>) further configured to receive a source code state program selected by a user, and operational parameters received as inputs from the user, the application processor circuitry configured to compile the source code state program and the operational parameters into a test routine (<NUM>;
a memory circuitry (<NUM>) in communication with the application processor circuitry, the application processor circuitry (<NUM>) configured to store a plurality of other test routines (<NUM>) and the test routine (<NUM>) in the memory circuitry (<NUM>);
a real time processor circuitry (<NUM>) in communication with the memory circuitry (<NUM>), the real time processor circuitry (<NUM>) configured to selectively and independently execute the test routine (<NUM>) or one of the plurality of other test routines (<NUM>) to perform a plurality of respective test states; and
an input/output processor circuitry (<NUM>) in communication with the real time processor circuitry (<NUM>) and the memory circuitry (<NUM>), the input/output processor circuitry (<NUM>) cooperatively operable with the real time processor circuitry (<NUM>) to output test signals and monitor for receipt of input test signals according to execution of the test routine;
characterized in that
the relay and metering test instrument (<NUM>, <NUM>) is configured to deploy a parameters-altering algorithm without requiring an update to the firmware in the relay and metering test instrument; and
that the real time processor circuitry is operable for execution of the parameters-altering algorithm during the execution of the test routine,
and
that the application processor circuitry is operable for executing the firmware in the relay and metering test instrument to control functional operation of the relay and metering test instrument.