Power monitor apparatus and method with object oriented structure5828576Abstract An object oriented architecture is used within individual monitoring units. The monitoring devices include circuitry which receives an electrical signal and generates at least one digital signal representing the electrical signal. Objects within such individual monitoring units include modules which perform a function and registers which contain the inputs, outputs and setup information for the modules. Methods can be invoked on all objects to change or query the operation or configuration of the device. At least one of the modules receives the digital signal as an input and uses the signal to generate measured parameters. Additional modules take measured parameters as input and generate additional parameters therefrom. The module may be linked in an arbitrary manner to form arbitrary functional blocks. Claims We claim: Description MICROFICHE APPENDICES
TABLE A
__________________________________________________________________________
The Types describe the semantics for passing information to and from
modules and registers.
Type Name Type equivalence
Restrictions
Description
__________________________________________________________________________
VoidType fundamental Type Has no semantic
value.
SignedType fundamental Type
Maximum size =
Defines a signed
32 bits. value.
UnsignedType
fundamental Type
Maximum Defines an
size = 32 bits
unsigned value.
CharType fundamental Type
Maximum size =
Defines a
32 bits. character value.
Supports wide
characters as
well as ASCII.
BooleanType
fundamental Type
Size = 1 bit.
Defines a
Boolean value.
Value may be
TRUE or FALSE.
FixedPointType
fundamental Type
Maximum size =
Defines a fixed
64 bits. point value.
FloatType fundamental Type
Size = 32, 64, or
Defines a floating
80 bits. point value.
ComplexType
fundamental Type
Maximum size =
Defines a
TBA. complex value.
DeltaType fundamental Type
Size = 0 bits.
The value
represents a
delta-function
pulse.
RealType define union RealType = Defines a real
SignedType .vertline. value.
UnsignedType .vertline.
CharType .vertline.
BooleanType .vertline.
FloatType .vertline.
FixedPointType.
NumericType
define union Defines a
NumericType = numeric value.
RealType .vertline.
ComplexType.
SignedArrayType
define array Defines an array of
SignedArrayType = signed values.
{SignedType `value.sub.i `}.
UnsignedArrayType
define array Defines an array of
UnsignedArrayType = unsigned values.
{UnsignedType `value.sub.i `}.
CharArrayType
define array CharArrayType =
Defines an array of
{CharType `char.sub.i `} characters.
BooleanArrayType
define array Defines an array of
BooleanArrayType = Boolean values.
{BooleanType `value.sub.i `}.
FixedPointArrayType
define array Defines an array of
FixedPointArrayType = fixed point values.
{FixedPointType `value.sub.i `}.
FloatArrayType
define array FloatArrayType =
Defines an array of
{FloatType `value.sub.i `}.
floating point values.
ComplexArrayType
define array Defines an array of
ComplexArrayType = complex values.
{ComplexType `value.sub.i }.
NumericArrayType
define union Defines an array of
NumericArrayType = numeric values.
SignedArrayType .vertline.
UnsignedArrayType .vertline.
CharArrayType .vertline.
BooleanArrayType .vertline.
FixedPointArrayType .vertline.
FloatPointArrayType .vertline.
ComplexArrayType.
ArrayUnsignedArray
define structure Structure defines an
Type ArrayUnsignedArrayType = array of
{UnsignedArrayType UnsignedArrayTypes.
`us.sub.-- array.sub.i `}.
StringType define StringType =
must be null terminated.
Defines a character
CharArrayType. string (null-terminated).
StringArrayType
define structure Defines an array of
StringArrayType = strings.
{CharArrayType `string.sub.i `}.
SizeType define SizeType = An unsigned integral
UnsignedType. value which is used for
defining a size
parameter (e.g. size of
array, #records).
CounterType
define CounterType = An unsigned integral
UnsignedType. value which can be
incremented (by 1 or
more), decremented (by
1 or more), and cleared
to 0.
IndexType define IndexType = An unsigned integral
UnsignedType. value which is used to
index arrays.
TimeType define TimeType = Universal Time (GMT)
NumericType. in seconds.
ReasonType define ReasonType = The reason for an
CharArrayType. exception.
ExceptionType
define structure ExceptionType =
An exception returns a
UnsignedType code and value. A
exception.sub.-- cause. reason string is
Type optional.
`exception.sub.-- value` The valid codes are:
›ReasonType `reason`!. 0 = underflow
1 = overflow
2 = not.sub.-- valid
3 = not.sub.-- supported
4 = not.sub.-- available
5 = invalid.sub.-- method
6 = loss.sub.-- of.sub.-- precision.
2
7 = internal.sub.-- error
MethodType define The value represents
MethodType = UnsignedType. (numerically) the
particular method of an
Object.
ClassType define ClassType = The value represents
UnsignedType. (numerically) a particular
class (such as Numeric
Register or PowerMeter
Module).
NodeHandleType
define union NodeHandleType =
An address to a remote
StringType .vertline. IED site.
UnsignedType.
ExtendedHandleType
define structure Defines a handle used
ExtendedHandleType = to reference an object
›NodeHandleType`node`! on another IED.
UnsignedType `handle`.
HandleType define union HandleType = The value represents
UnsignedType .vertline. the address of an
ExtendedHandleType. object.
ExtendedHandle
define structure.sub.-- array
The value is an array of
ArrayType ExtendedHandleArrayType = Extended Handles.
(ExtendedHandle `value.sub.i `}.
HandleArrayType
define union HandleArrayType=
The value is an array of
ExtendedHandleArrayType .vertline.
handle values.
UnsignedArrayType.
PriorityType
define Priorities range from
The value represents an
PriorityType = UnsignedType.
0 to 255 priority. Guidelines for
priorities are as follows:
Urgent 192 to 255
High 128 to 191
Medium 64 to 127
Low 0 to 63
RangeType define structure RangeType=
defines a range of
IndexType values that starts at
`range.sub.-- start` index range.sub.-- start and
IndexType ends at index
`range.sub.-- end`. range.sub.-- end. This is
useful in log situations.
EventType define structure EventType =
Defines a structure for
PriorityType `priority` an event.
UnsignedType Values for event.sub.-- state
`event.sub.-- state` are:
HandleType 0 = unary state event.
`cause.sub.-- handle` 1 = Active transition
IONType for bi-state event.
`cause.sub.-- value` 2 = Inactive transition
HandleType for bi-state event.
`effect.sub.-- handle` 3 = Label change
IONType event.
`effect.sub.-- value`.
LogHeaderType
define Structure defines the
LogHeaderType = HandleArrayType.
header for a general
purpose log record.
LogRecordType
define structure LogRecordType =
Structure defines the
IndexType `position` data values in a general
TimeType purpose log record.
`timestamp`
{Type `value.sub.i `}.
LogArrayType
define structure.sub.-- array
Array of log records.
LogArrayType =
(LogRecordType `logrec.sub.i `}.
WaveformType
Table 1 lists a set of methods which presently defined for the base class. All of these base class methods are inherited by the registers and modules.
TABLE 1
__________________________________________________________________________
# Method Return-type
Description
__________________________________________________________________________
1 read.sub.-- class()
ClassType
Causes a manager, module or register to return a
number indicating what type of manager, module or
register it is.
2 read.sub.-- name()
StringType
Causes a manager, module or register to return a
string containing the name of the manager, module
or
register.
3 read.sub.-- label()
StringType
Causes a manager, module or register to return a
string containing the label for the manager,
module or
register. A label differs from a name in that it
can
be programmed by executing a Write Label method
on
the manager, module or register. If no label is
programmed the object name will be returned.
128
write.sub.-- label(StringType)
BooleanType
Write the programmable object label. If a
null-string is
written, the Label is destroyed.
129
read.sub.-- security.sub.-- level
SecurityType
Is executed to determine whether a method can be
(MethodType) executed on a particular manager, module or
register.
Not all methods are available on all devices. The
master device can determine whether it will
receive a
valid result by first executing this method.
Another
method, Read All Security Levels returns a list
which
corresponds to the security levels of all the
methods
that can be executed on a manager or module.
130
read.sub.-- all.sub.-- security.sub.-- levels()
MethodSecurity
Read the security levels for all methods of a
given
ArrayType
object. Only methods valid for the object's class
are
included.
131
read.sub.-- parent.sub.-- handle
HandleType
Returns a handle of the parent of a manager,
module
or register. For instance, executing this method
on an
analog output module will return the handle of
the
analog output manager. Executing this method on
the
analog output manager will return a handle to the
feature manager. Executing this method on an
analog
output's output register returns the analog
output
module.
132
read.sub.-- owners()
HandleArray
Returns a list of handles for all the modules that
own
Type the object this method is executed on. This will
include a list of modules if the method is invoked
on a
register or a manager if it is invoked on a
module.
133
IsA(ClassType)
BooleanType
Returns a value indicating whether or not an
object is
derived from the class given as an argument.
134
check.sub.-- sanity()
BooleanType
Checks to see if the manager, module or register
is
operating correctly. I.e., determines whether the
software that implements the object is operating
correctly. Returns True if object is
__________________________________________________________________________
sane.
If a method invocation is unsuccessful, an ExceptionType will be returned rather than the normal Return-type. In the current implementation a module performs a function using registers. Input registers provide the information a module is operating on. Setup registers permit modification of the operation of the module. Output registers contain the results of the module's operation. The output registers of one module can be used as input registers for another. The module keeps track of which registers are to be used for its input, output and setup. The links to the input registers can be modified, but those to the output and setup registers are fixed. A module is said to "own" all the registers it is linked to. Methods may also be executed on registers once the handle to a register is known. The handle of a register or module is a number which is unique for each register and module on a device. When a method is invoked, a handle is supplied which indicates which module or register the method is to be invoked upon. In most instances, the methods that can be invoked on the different types of registers depend on what type of register is involved. Table 2 lists a set of methods which are presently defined for all registers (all register classes are inherited from the register class).
TABLE 2
______________________________________
Register Class (R) - class = 20
# Method Return-type
Description
______________________________________
20 read.sub.-- time()
TimeType Read the time of last
update.
21 read.sub.-- value()
VoidType Read the value of the object
22 write.sub.-- value(VoidType)
BooleanType
Write the value of the
object
______________________________________
TABLES 3-19 list methods which are supported for the indicated register classes. (In Tables 3-19, "*" indicates that the method is inherited from the parent class and "+" indicates that the method is re-defined from the parent class.)
TABLE 3
______________________________________
BooleanVariableRegister (BVR) - class = 21
This class defines a Boolean variable storage location.
# Method Return-type
Description
______________________________________
20 read.sub.-- time()*
TimeType Read the time
of last update
21 read.sub.-- value()+
BooleanType
Read the value
of the register.
22 write.sub.-- value(BooleanType)+
BooleanType
Write the value
of the register
30 read.sub.-- ON.sub.-- label()
StringType Read the ON
label.
500 write.sub.-- ON.sub.-- label(StringType)
BooleanType
Write the ON
label.
31 read.sub.-- OFF.sub.-- label()
StringType Read the OFF
label.
501 write.sub.-- OFF.sub.-- label(StringType)
BooleanType
Write the OFF
label.
32 read.sub.-- current.sub.-- state.sub.-- label()
StringType Returns the ON
label if register
value = True
and OFF label
if register
value = False.
______________________________________
It is also contemplated that a TableRegisterClass will be defined. The TableRegisterClass represents a database table, rows of data organized into distinct columns. It is presently envisioned that the database tables will not be accessible using methods. These registers may be used permanently as inputs to specialized modules that allow indirect access to the tables. Registers operate only as servers in the architecture. In other words they only respond to method invocations. Some of the most commonly used registers in the preferred embodiment are boolean registers, enumerated registers, numeric registers and numeric bounded registers. A flow chart for the server operation of a boolean register is shown in FIGS. 20A-20C. A flow chart for the server operation of an enumerated register is shown in FIGS. 21A-21B. A flow chart for the server operation of a numeric register is shown in FIGS. 22A-22B. A flow chart for the server operation of a numeric bounded register is shown in FIGS. 23A-23B. It will be recognized by those skilled in the art that the registers' functionality can be embedded within the modules. The modules provide the IED the functionality in the architecture. FIG. 11 schematically illustrates a preferred embodiment of the properties of the modules. The modules can be considered as "black boxes" that read data at the inputs, manipulate the data in some fashion, and write the result to outputs. Input data is read from registers and output data is written to registers. For all types of modules, the links to input registers can be programmed, but the links to output registers are fixed. Most modules have links to registers which contain setup information these links are also fixed, and the module can only read them. FIG. 12 illustrates the data flow for a module. A module 61 is linked to input registers 63a-63n through programmable links 69a-69n. Setup registers 67a-67n are linked to module 61 through links 72a-72n which are not programmable. Output registers 64a-64n are linked to module 61 through links 70a-70n which also are not programmable. In the preferred embodiment, the modules have the following properties An array of handles (input handles) point to the input registers. The module has shared ownership of these registers. The module reads a register using the Read.sub.-- Value method. Module setup data (such as scaling information) is stored in registers. An array of handles (setup handles) point to these Registers. There is one exception: For a manager module these Handles point to other modules rather than registers. The module has shared ownership of these objects. The module uses the input data and setup data to produce output data according to the function of the module which is described by the module behavior. An array of handles (output handles) point to the output registers. The module has shared ownership of these registers. A module writes these registers using the Write.sub.-- Value method. UpdatePeriod contains the period at which the module updates the output registers. ModuleSecurity contains the security level which the module uses when invoking methods on other objects. The module has a class which is unique to that type of module. (e.g. All setpoint modules would have the same class). The module has a name. This name is fixed (read only) and is different in every module. The module has a label which can be programmed. A method security level is defined for every method which can be invoked on a module. Thus, there is a security parameter for every method which can be invoked on the module. The module has owners which are listed in an array of Handles. This array lists all the module(s) that have shared ownership of the module. A module is created by a manager using the Create.sub.-- Module() method. When the module is created all output registers and setup registers are also created. However, input registers are not created when a module is created. Often, a manager will have a fixed number of modules and the Create.sub.-- Module() method will not be supported. The module class (class=500) is derived from the base class. The methods listed below in Table 20 are common to all module classes (all module classes are inherited from this module class).
TABLE 20
__________________________________________________________________________
# Method Return-type
Description
__________________________________________________________________________
1000
read.sub.-- input.sub.-- handles()
Handle Array
Returns a list of the handles to the registers
Type that are connected as inputs to the manager
or module. (In the current embodiment,
managers do not have inputs.)
1001
write.sub.-- input.sub.-- handles
Boolean Type
Accepts a list of handles and attempts to link
(HandleArrayType) a module or manager to these input registers.
(In the current embodiment, managers do not
have inputs.) The handle order is defined in
the module definitions. If one of the handles
is incorrect the method will fail and NO
handles will be written (i.e. all or nothing).
1002
read.sub.-- input.sub.-- classes()
ArrayUnsigned
Reads the allowed register classes for the
ArrayType
write.sub.-- input.sub.-- handles method. The
returned
array has the same number of elements as
the HandleArray used in the
write.sub.-- input.sub.-- handles method. If the
returned
array has an element that contains a Null
rather than a class this indicates that this
input element cannot be programmed.
1003
read.sub.-- output.sub.-- handles()
HandleArray
Returns a list of handles to the output
Type registers of a module or manager. (In the
current embodiment, managers do not have
outputs.) The handle order is defined in the
module definitions.
1004
read.sub.-- setup.sub.-- handles()
HandleArray
Returns a list of handles to the setup register
Type of a module or a list of handles to modules
for a manager. The handle order is defined in
the module definitions.
80 read.sub.-- setup.sub.-- counter()
CounterType
Returns a number indicating how many times
the module or manager has had its
configuration changed. A master device can
keep a local copy of this number. If another
master device changes the setup of the slave
device, the first manager can detect the
change by comparing its count with the
current count.
81 read.sub.-- update.sub.-- counter()
CounterType
Returns a number indicating how many times
the module or manager has successfully
invoked a method to write a new value to its
output registers. A master device can then
determine if it is necessary to read the output
from the module or manager. (In the current
embodiment, managers have no outputs.)
1005
read.sub.-- update.sub.-- period()
StringType
Returns a number indicating the minimum
amount of time there will between the module
or manager updating its output registers. (In
the current embodiment, managers have no
outputs.)
Typical response is one of:
"one cycle"
"one second"
"two cycles"
1006
read.sub.-- module.sub.-- security()
SecurityType
Returns a number indicating the security
access a module has. Other modules or
registers may refuse to execute a method
invoked by a module which does not have a
high enough security level.
__________________________________________________________________________
Table 21 below lists the behavior details for the module parameters.
TABLE 21
______________________________________
Module Parameter
Behavior
______________________________________
update.sub.-- counter
will be incremented every time a write.sub.-- value()
method is successfully invoked on one of the
registers identified by the output handles.
Note: by default the update counter will be
incremented every time an module writes an
event register.
setup.sub.-- counter
will be incremented every time a write.sub.-- value()
method is successfully invoked on one of the
system registers identified by the setup handles
and every time the write.sub.-- input.sub.-- handles() method
is successfully invoked.
______________________________________
Table 22 below provides a list of the modules (including the corresponding input, output and setup registers) presently supported by the presently preferred embodiment.
TABLE 22
__________________________________________________________________________
# Module Name
Input Registers
Output Registers
Setup Registers
Module Description
__________________________________________________________________________
501
Power Meter
V1(NAR)
Vabc*(NVR).sup.1
ode(ENR) Basic 3-phase power met
V2(NAR)
VIIabc*(NVR)
PT Pri Volts(NBR)
met meter.
V3(NAR)
Iabc*(NVR)
PT Sec Volts(NBR)
PhaseOrder:
I1(NAR)
KWabc*(NVR)
CT Pri I(NBR)
"ABC"
I2(NAR)
KVARabc*(NVR)
CT Sec I(NBR)
"ACB"
I3(NAR)
KVAabc*(NVR)
I4 CT Pri I(NBR)
NormFreq:
I4(NAR)
PFSIGNabc*(NVR)
I4 CT Sec I(NBR)
"50"
PFLEADabc*(NVR)
I1 Polarity(ENR)
"60"
PFLAGabc*(NVR)
I2 Polarity(ENR)
"400"
Vunbal(NVR)
I3 Polarity(ENR)
PhaseLabels:
Iunbal(NVR)
PhaseOrder(ENR)
"ABC"
I4(NVR) NormFreq(ENR)
"RST"
Iresidual(NVR)
PhaseLabels
"XY2"
PhaseRev(BVR)
(ENR) "RYB"
LineFreq(NVR)
Event(ER)
__________________________________________________________________________
.sup.1 The method read.sub.-- output.sub.-- handles() will return handle
in the order given here. This also applied to the methods read.sub.--
input.sub.-- handles and read.sub.-- setup.sub.-- handles() for all
modules defined in this document.
In the following description reference is made to "managers". It will be noted that managers are just a specific type of module which have additional functionality. The purpose of the managers is to manage modules. One manager is needed for each practical group of modules, such as setpoint modules and min modules. Table 23 below provides a list of the methods which are added specifically for the manager class. (All class and module class methods are inherited by the manager class but are not shown here for reasons of brevity.)
TABLE 23
__________________________________________________________________________
# Method Return-type
Description
__________________________________________________________________________
100
read.sub.-- module.sub.-- setups.sub.-- counter()
CounterType
Returns a number indicating how many times
the setup registers of the modules below a
manager have been changed. The master
device can keep a local count of this number
in order to determine if another master device
has successfully invoked a method to change
the setup of the device. For instance, if a
master device keeps this count for the feature
manager, it can tell if any setup register on
the device has been changed without going to
each individual module.
101
read.sub.-- module.sub.-- updates.sub.-- counter()
CounterType
Returns a number indicating how many times
the ouput registers of the modules and
managers beneath a certain manager have
been updated. Used in the same fashion as
Read Module Setups Counter, the Read
Module Updates Counter is used to determine
if any of the modules beneath the manager
have successfully invoked a method to update
their output registers. (In the current
embodiment, managers have no outputs.)
1500
create.sub.-- module(ClassType)
HandleType
Creates a module and stores the module
handle in the setup handles array; return
handle to module. The method
read.sub.-- managed.sub.-- class indicates which
class of
module can be created.
1501
destroy.sub.-- module(HandleType)
BooleanType
Destroys a module. Handle must be one of
setup handles or an exception will be returned
and the method will fail. The resources for
that module are then available to perform
other functions on the device.
1502
read.sub.-- managed.sub.-- class()
ClassType
Returns the class of module which can be
created with the create.sub.-- module
__________________________________________________________________________
method.
Every system has a "root" manager module called the feature manager. The feature manager has setup handles to all the other managers. Importantly, the feature manager handle is identical for all systems. The handle for the feature manager is 2. Starting with this handle, it is possible to determine the entire system configuration. As was mentioned previously, modules act as both clients and servers in the object oriented architecture. In the present embodiment, the client and server portion of the modules operate separately. The server portion of the modules respond to method invocations. The server portion follows the same logic for all modules (except the managers) on the device. A flow chart of the logic for the server portion of a module is shown in FIGS. 12a-12c. A description is now given of how the modules described above are used in the system of FIGS. 1-3. In the preferred embodiment the output registers from the data acquisition module 152 (FIG. 4) (which are digital signals representing the samples of the voltage and current) are permanently connected as input registers 120 of a module called the power meter module 126 (FIG. 5). Conceptually, the data acquisition module encompasses signal conditioning circuitry 60, 62, 64, 66A, 66B, 66C, 68A, 68B, 68C, 70, the A/D converters 29, 30 and software in the DSP 28. The interface between the data acquisition module and the power meter module includes the dual port RAM 27. A flow chart for the logic of the client portion of the data acquisition module 152 is shown in FIG. 4A. The power meter module 126 owns setup registers 122 which modify the operation of the power meter module 126 and output registers 124 which contain the results of the calculations that the power meter module does and can be connected to other modules. A flow chart of the logic for the power meter module 126 is shown in FIGS. 5A-5L. The module called the analog input module is an example of a module which connects to a physical signal in a different way. A preferred embodiment of the analog input module 128 is illustrated schematically in FIG. 6. An exemplary embodiment of the logic for the client portion of the analog input module of FIG. 6 is illustrated in flowchart form in FIG. 6A. The analog input module 128 owns a port setup register 130 which defines which of the auxiliary input signals 20 the module is associated with. Analog input modules can also be connected to digital I/O signals 44 (FIG. 2). In this configuration, the Digital I/O transceiver 49 operates in input mode and the analog input module converts the frequency of the digital signal into a number. In this embodiment, an external voltage to frequency converter is connected to the digital input signal line. Analog output modules can also be connected to the Digital I/O Signals 44. In this configuration, an external device is connected to the I/O line which converts the digital signals coming from the analog output module 130 to an analog signal. A preferred embodiment of the analog output module 130 is illustrated schematically in FIG. 7. An exemplary embodiment of the logic for the client portion of the analog output module 130 is illustrated in FIG. 7A in flowchart form. The digital input module 140 transforms a digital I/O signal 44 into a form that can be used as an input to other modules. A preferred embodiment of the digital input module 140 is illustrated schematically in FIG. 8. An exemplary embodiment of the logic for the client portion of the digital input module 140 is illustrated in FIGS. 8A-8B in flowchart form. The digital output module 150 transforms the output from another module into a signal on a digital I/O signal line 44. A preferred embodiment of the digital output module 150 is illustrated schematically in FIG. 9. An exemplary embodiment of the logic for the client portion of the digital output module 150 is illustrated in FIGS. 9A-9H in flowchart form. Additional modules that operate only on the results of other modules are also possible. An example of one of these modules is the AND/OR module 160 illustrated schematically in FIG. 13. The AND/OR module 160 takes a number of boolean variable register inputs and performs a logical AND or OR on them to create a result. The CalcMode setup register 161 determines which AND or OR function is being executed. The EvLogMode setup register 162 determines whether events will be generated in the Event output register 163 when the Result 164 register changes. The logic for a preferred embodiment of the client portion of the AND/OR module 160 is illustrated in FIGS. 13A-13B in flowchart form. The setpoint module 172 is shown schematically in FIG. 14. The logic for a preferred embodiment of the client portion of the setpoint module 172 is shown in FIGS. 14A-14C. These modules do not interface to the outside world. Another module of note is the EventLog module 170. The EventLog module is shown schematically in FIG. 15. A flowchart of a preferred embodiment for the client portion of the EventLog module is shown in FIG. 15A. Nearly all other modules within the device are connected to an event output register. When an unusual state arises within a module, it may send an event message to the event register. The EventLog module 170 takes event registers as an input and invokes a method to write the "event" into its event log output register. The result is that the Event Log register then contains a list of all the significant occurrences that have happened on the device. In this manner, the time as well as the effects which occur in the IED may be recorded. An example of the events that may be generated on the power meter of the present invention can be seen in Table 24.
TABLE 24
______________________________________
Event Cause Cause Effect Effect
# Time Label Value Label Value
______________________________________
1 Dec. 15/94 @
None External
Motor 4
Powered
800 Down
2 Dec. 15/94 @
Motor 4 Powered
Cooler 7
Shutdown
800 Down
3 Dec. 15/94 @
kW Phase A
1000 Over kWa
True
923
4 Dec. 15/94 @
Over kWa True Relay 6
Closed
923
______________________________________
In table 24 a number of events in the system are shown. Event #1 is an event that a digital input module might create if its hardware changed state. In this case, the digital input is connected to the status output of a motor. There is no cause label in this case since the cause is external to the meter. Event #2 shows an event that a digital output module might create. The source input of this digital output module is connected as the state output of the digital input module. Event #3 is an event that a setpoint module might create. The setpoint module has detected that the amount of power being consumed is too great so its status output register is set to true. This status output register is connected as the source input register to another digital output module. In Event #4 the digital output module is shown to close a relay. Therefore, the fact that kW Phase A has exceeded a certain bounds has caused an external relay to close (hopefully rectifying the problem). A significant feature of the disclosed architecture is that the modules can be linked in arbitrary fashions to form arbitrary functional blocks comprised of networked objects. An example application using the architecture of this invention is shown in FIG. 16. In this example, a setpoint module 172 is used to monitor Phase A current from the power meter module 126. The setpoint is enabled using a digital input module 140 which is driven by the manual switch 141. The setpoint setup registers are configured so that the setpoint goes ON when the current exceeds 100 Amps. The setpoint status output controls the digital output module 150, which drives a relay 151 which could control a motor (not shown). Whenever the phase A current exceeds 100 Amps and the manual switch 141 is closed, the relay 151 will be closed causing the motor to turn off. (Note: in this example setup registers and other registers that are not needed for the example are not shown.) It will be appreciated by those skilled in the art that the number and variety of possible additional modules and applications is unlimited. The operation of most of the modules in the IED is governed by the client portion of the module flow controller. A flow chart for the execution of the client portion of the module flow controller is shown in FIG. 17A. The module flow controller causes different modules within the device to execute. The module flow controller only triggers modules to execute that have valid input registers. Therefore, any modules that do not meet this requirement do not use any of the processing power available to the device. The server portion of the module flow controller is executed when a module has the write input handles method invoked on it. A flow chart for the operation of the server portion of the module flow controller is shown in FIG. 17B. The server portion of the module flow controller records whether the input handles being written are valid or not. The client portion then uses this information when it makes its decision on whether to execute the module or not. FIG. 18 schematically illustrates a preferred embodiment of a manager, the analog output manager 300. A flow chart for the logic for the server portion of a manager is shown in FIGS. 18A-18B. In the present embodiment, managers have no client portion. There is one resource manager 300 for each type of module. Each resource manager 300 may have many modules below it. Every manager 300 in an IED resides beneath the feature manager for the device. A preferred embodiment of feature manager 400 is schematically shown in FIG. 19. A flow chart for the logic of the server portion of the feature manager is show in FIGS. 19A-19B. All the managers on the device appear as setup registers 401 to the feature manager 400. The feature manager 400 controls access to the entire device 100. Starting from the feature manager 400, a master device, such as PC 114, can determine all input, output and setup registers for every module on the IED device 100. Each manager is said to own all the modules that appear as its setup registers. The feature manager is said to own the resource managers that appear as setup registers to it. Therefore, a hierarchy of modules exists with the feature manager on top. In order for a master device, such as PC 114, to access the information in a slave device, such as the IED 100, it invokes methods on the managers, modules or registers. In order for a master to execute a method on a slave, it must have a handle. The handle indicates which manager, module or register the method is to be acted on. For example, the handle for the feature manager for any type of slave device is 2 in the current embodiment. This is the only thing that is fixed in the architecture and every type of device has a feature manager with a handle of 2. From this handle, the entire configuration of the device can be determined. With the configuration of the present invention, the slave device, such as the IED's 100 may have the capability to execute many different objects, but only a limited number of objects can be executed at any one time due to processing power constraints. The flow control client controls the operation of modules. Therefore, only the modules that have valid input, output and setup registers connected to them are executed. In order for a master device, such as a PC 114, to determine the configuration of a slave device without the master device having any previous knowledge of the configuration, the master device invokes certain methods on the feature manager. These methods are fixed in the architecture. In other words, every feature manager for every different type of slave device will interpret these methods in the same way. For instance, the master device may invoke the method Read Setup Handles on the feature manager which requests a list of the managers that reside beneath it. From this list, the master device can then go to each individual manager and request the operating modules beneath them by again executing the method Read Setup Handles. Once the master device knows which modules are operating, it can request of each module its currently connected input, output and setup registers using the appropriate methods and thus determine the entire configuration of the device. Thus, without any prior knowledge of the slave device, or its configuration, the master device can determine all characteristics of the device. The master device can then invoke other methods to change the configuration of the device. The slave devices, however can operate autonomously without the involvement of the master devices. Thus, the slave devices, such as power monitors, can be readily configured to exactly match a user's unique requirements and to provide the ability to do so without interrupting the operation of the rest of the functions the device is performing. The slave devices, such as the IEDs, can be networked to one or more computers and the slave devices can be configured or reconfigured via the communications network. Further, with the present invention, it is not necessary to change the software on a master device when a slave device is upgraded. The modules are independent or autonomous. Thus, when a module is modified, there is no need to modify the other modules. As used herein the term "independent modules" means that modifications or changes can be made to one or more modules without a need to modify the remaining modules (i.e. a modification to one module has no effect on the operation or functionality of the other modules. The feature manager keeps a count of how many times the configuration of the device has been changed. A master can invoke a the method Read Module setups counter on the feature manager to request this count. If there are multiple masters changing the configuration of the device, each master need only request this count from the feature manager to determine if the configuration of the device has been changed. The feature manager also contains a count of how many times the modules below it have updated their output registers. Each individual manager has a count of how many times the modules below it have updated their output registers and each individual module has a count as well. Therefore, if a master device executes the method Read Module Updates Counter and finds that none of the modules under a certain manager have updated their output registers since the last time the master read the values in the registers, the master does not need to waste communications bandwidth reading the same values again. Methods and Modules are preferably assigned a security level. This permits the system to be configured such that certain users have access to all of the system functions while other users have access to only selected functions. The Read Security Level, Read All Security Levels and Read Module Security methods can be used to determine what level of authorization is necessary to access the various methods and modules in the system. The foregoing description of the preferred embodiments of the present invention has been presented for purposes of illustration and description. The described embodiments are not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously many modifications and variations are possible in light of the above teachings. The embodiments which were described were chosen in order to best explain the principles of the invention and its practical applications. It is intended that the scope of the invention be defined by the following claims, including all equivalents.
|
Same subclass | ||||||||||