Protection Relay

Implement protection relay with definite minimum time (DMT) trip characteristics

• 

Libraries:
Motor Control Blockset HDL Support / Protection and Diagnostics
Motor Control Blockset / Protection and Diagnostics

Description

The Protection Relay block implements a protection relay for the hardware and the motor with definite minimum time (DMT) trip characteristics using the reference limit, feedback, and reset input signals. In the event of a fault, the block generates a latched fault signal that you can use to protect the hardware and the motor. You can reset the fault latch using an external reset signal.

For more details about the algorithm used by the block, see Algorithms.

Ports

Input

I_max — Upper limit for current

scalar

Upper limit for current (in amperes) in the feedback loop, so as to provide overcurrent protection. The block generates a latched fault signal when the current in the feedback loop (Ifb) exceeds this value.

Dependencies

To enable this port, set Select Protection to Overcurrent.

Data Types: single | double | fixed point

I_fb — Actual current in feedback loop

scalar

Actual current (in amperes) in the feedback loop at a given time.

Dependencies

To enable this port, set Select Protection to Overcurrent.

Data Types: single | double | fixed point

⍵_{m max} — Rotor speed limit for overspeed protection

scalar

Speed limit of the rotor (in RPM). The block generates a latched fault signal when the rotor speed (⍵m fb) exceeds this value.

Dependencies

To enable this port, set Select Protection to Overspeed.

Data Types: single | double | fixed point

⍵_{m fb} — Actual rotor speed

scalar

Actual rotor speed (in RPM) at a given time.

Dependencies

To enable this port, set Select Protection to Overspeed.

Data Types: single | double | fixed point

V_max — Upper voltage limit for overvoltage protection

scalar

Upper limit for voltage (in volts) across the feedback loop. The block generates a latched fault signal when the voltage across the feedback loop (Vfb) exceeds this value.

Dependencies

To enable this port, set Select Protection to Overvoltage.

Data Types: single | double | fixed point

V_min — Lower voltage limit for undervoltage protection

scalar

Lower limit for voltage (in volts) across the feedback loop. The block generates a latched fault signal when the voltage across the feedback loop (Vfb) is less than this value.

Dependencies

To enable this port, set Select Protection to Undervoltage.

Data Types: single | double | fixed point

V_fb — Actual voltage across feedback loop

scalar

Actual voltage (in volts) across the feedback loop at a given time.

Dependencies

To enable this port, set Select Protection to either Overvoltage or Undervoltage.

Data Types: single | double | fixed point

Reset — External reset pulse

scalar

External pulse that resets the fault latch.

Data Types: single | double | fixed point

Output

y — Latched fault signal

scalar

Latched fault signal that the block generates during the overcurrent, overspeed, overvoltage, and undervoltage conditions to protect the hardware and the motor.

Data Types: single | double | fixed point

Parameters

Select Protection — Type of protection relay

Overcurrent (default) | Overspeed | Overvoltage | Undervoltage

Available protection types to configure block behavior during the overcurrent, overspeed, overvoltage, and undervoltage conditions.

Maximum count input type — Input method for maximum count

Specify via dialog (default) | Input port

Use one of these methods to specify the counter limit:

• Specify via dialog — Specify the counter limit using the Maximum count parameter.

• Input port — Specify the counter limit using the input port Cnt_max.

Maximum count — Counter limit

100 (default) | scalar

The maximum count supported by the counter that the block uses for evaluating a threshold violation by the feedback signal.

Samples for debounce filter — Number of debounce samples

3 (default) | scalar

The number of block samples used by the debounce algorithm to test each threshold violation cease. This value determines the debounce period.

Algorithms

The block ensures to detect the faults correctly. It uses a combination of a counter and a debounce algorithm to identify instances of erroneous threshold violations and violation ceases that might happen due to glitches and noise in the feedback signal.

When the block detects a threshold violation, at first it evaluates the signal by starting a counter to track the durability of the violation. If the violation sustains until the count limit of the counter, the block raises a fault. If the violation ceases before the counter reaches the count limit, the block resets the counter and does not raise a fault. The block uses a debounce algorithm to further test each violation cease. It accepts only genuine violation ceases that are not caused by glitches and noise.

When evaluating a threshold violation, whenever a violation cease occurs, the block activates the debounce algorithm, which acts as a second-level test that identifies whether a violation has actually stopped or not. During this test the counter (previously started) continues to run.

• As shown in figure a, if the violation cease continues for a specified number of block samples (debounce period), the block resets the counter and does not raise a fault because the violation ceased successfully.

• As shown in figure b, if the signal jumps back to indicate a threshold violation before the end of debounce period, the block continues to run the counter and continues evaluating the threshold violation because the violation did not cease successfully.

If the counter completes successfully without detecting a successful violation cease, the block generates a latched fault signal.

For example, the following image depicts this behavior for an overspeed condition:

These three common uses cases highlight the block functionality with respect to overspeed condition when a motor tries to follow a reference speed:

1. Counter interrupted before completion — In this use case, the motor speed exceeds the speed threshold, however, it falls back afterward to follow the reference speed. After detecting a successful threshold violation cease, the counter stops before completion and resets. In this case, the block does not trigger a fault.

   

2. Counter completes without activating debounce algorithm — In this use case, the motor speed exceeds the speed threshold and the threshold violation sustains till the counter limit. After the counter completes, the block triggers a latched fault signal.

   

3. Counter completes while activating debounce algorithm — In this use case, the motor speed exceeds the speed threshold, however, it activates debounce algorithm at least once. Because any violation cease does not sustain till the end of debounce period and the counter successfully completes, the block triggers a latched fault signal.

   

The debounce algorithm is not applicable during the latched fault state. The block stops generating the latched fault signal only after receiving a reset input as shown in the following figure.

Significance of debounce algorithm

The debounce algorithm ensures that the counter for evaluating the threshold violation does not stop due to temporary violation ceases resulting from sharp rise or fall of signal caused by glitches and noise. For such a glitch or noise, the debounce logic ensures to keep the counter running, and therefore, generates the latched fault timely to avoid delays.

The following figure shows how a debounce mechanism relays the fault timely and saves critical time.

Extended Capabilities

C/C++ Code Generation
Generate C and C++ code using Simulink® Coder™.

HDL Code Generation

Generate VHDL, Verilog and SystemVerilog code for FPGA and ASIC designs using HDL Coder™.

HDL Coder™ provides additional configuration options that affect HDL implementation and synthesized logic.

HDL Architecture

This block has one default HDL architecture.

HDL Block Properties

ConstrainedOutputPipeline	Number of registers to place at the outputs by moving existing delays within your design. Distributed pipelining does not redistribute these registers. The default is 0. For more details, see ConstrainedOutputPipeline (HDL Coder).
InputPipeline	Number of input pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see InputPipeline (HDL Coder).
OutputPipeline	Number of output pipeline stages to insert in the generated code. Distributed pipelining and constrained output pipelining can move these registers. The default is 0. For more details, see OutputPipeline (HDL Coder).

Fixed-Point Conversion
Design and simulate fixed-point systems using Fixed-Point Designer™.

Version History

Introduced in R2020a