Description

This component implements a Phasor Measurement Unit (PMU) inspired from the IEEE Standard for Synchrophasor Measurements for Power Systems [1]. It computes the three-phase and positive sequence phasors, the frequency and the rate of change of frequency (ROCOF) from the input three-phase instantaneous signals (voltage or current). The time reference which is used by the model could be the simulation time or an external timing reference.

This Phasor Measurement Unit (PMU) component is based on the Discrete Fourier Transform (DFT) algorithm, which is a phasor-tracking method documented in [1], and modified according to the amendment [2] published in 2014. The input is a bundle including the instantaneous three-phase voltages or currents. The PMU outputs three phase phasors, positive sequence phasor, frequency and rate of change of frequency (ROCOF) calculated from the positive sequence component. The following figure shows the internal structure of the PMU model.

The phasors can be configured to be output in the format of magnitude-angle or real-imaginary parts. According to [1], a sinusoidal waveform  x(t) = X_m cos (ωt + Φ) in ac power system analysis is commonly represented as the phasor shown below:

X=(X_m / √2)*e^jΦ=Xr + j*X_i

Where the magnitude is the root-mean-square (rms) value, (Xm / √2) . In this model, angle Φ is the instantaneous phase angle relative to a cosine function at the nominal system frequency synchronized to the simulation time.  X_r and X_i are the real and imaginary parts of the phasor in rectangular components.

The PMU can work in two different performance classes: P class and M class. P class for protection applications features smaller response time while M class for measurement applications features higher accuracy.

Depending on the user selection of performance class and reporting rate, the internal filter coefficients are adapted accordingly. The P class phasor estimation algorithm uses fixed length two-cycle triangular weighted FIR filter that is not changed for different reporting rates [1]. The M class phasor estimation algorithm attenuates signals above the Nyquist frequency for the given reporting rate by at least 20 dB.

The filter coefficients are obtained based on “sinc” function (sin(x)/x) multiplied with a Hamming window [1]. More details regarding the filters can be found in Annex C (informative) Reference signal processing models in [1] and [2].

The sampling frequency of this PMU model is modified from [1] to 1000 Hz for all classes and reporting rates in order to adapt to a typical EMT real-time simulation time step such as 50 us. As a result, the measurement accuracy of the PMU model can be limited in some cases. The following table summarizes the cases in which the PMU measurement accuracy is non-compliant to the standard:

PMU performance compliance table with a sampling rate of 1000 Hz

The time source used by the PMU model for synchronization could either be the simulation time (internal digital clock) or an external source like the Global Positioning System (GPS) and the user can choose between the two. If the external clock is chosen, then the input “Clock” is activated and needs the appropriate signals. The signals should come from another library component representing the external clock.

The outputs of the PMU model also have a refreshing rate of 1000 Hz. A rate transition component can be added to the outputs to match the selected reporting rate if the reporting interval is an integer multiple of the simulation time step. If using this PMU model with the C37.118 slave communication protocol, the driver will fetch data at the selected reporting rate, so no rate transition component is required. 

The 1000 Hz output frequency also introduces some oscillations in three-phase phasor outputs for the 50 Hz M class and 60 Hz P and M class models, but there is no oscillation in the positive sequence phasor data. In this model, the reporting latency of the PMU with different configurations is fixed as shown in the following table:

PMU reporting latency

Mask and Parameters

PMU

Inputs, Outputs and Signals Available for Monitoring

Inputs

Outputs

Sensors

How to use the PMU Component with C37.118 Driver

A way that the PMU component can be used with synchrophasor streams according to the IEEE C37.118 standard in HYPERSIM is shown in the picture below.

The picture also shows how the external clock of the PMU is being used for synchronization. So, the following sections will show how to configure the external clock as well as how to configure C37.118 slaves in HYPERSIM I/O Interface Configuration. 

Setup to use the External Clock

To use the External Clock option of the PMU, firstly a simulator with a syn1588 PCIe Oregano card for synchronization is required. 

Secondly, the following configurations need to be done to the I/O Interface Configuration and single line diagram in HYPERSIM.

• A new Synchronization interface should be added which specifies the synchronization options like the picture below. The parameters are configured as such when the simulator serves as the master clock. When an external master clock is present on the network, the PTP profile and Priority should be modified accordingly to Power Slave and a lower priority.

• A continuously increasing time signal has to be connected to the “Clock” input of the PMU.  An "Add" component from the HYPERSIM library is being used to add up seconds and nanoseconds as the external clock. The following figures show the gain values which are used for the addition and mapping of Synchronization data points to the clock.

NOTE: While working with External clock and the PMU component, using the Timestamp of the PMU might cause issues. Check this section for more information. 

C37.118 Mapping

Whether the PMU is using an internal or external clock as the timing reference, the following setup is the same:

• A C37.118 Slave interface is added in the I/O Interface Configuration. The following pictures show the configuration.

• In the I/O Interface Configuration, the option “Use External Clock” should be chosen for C37.118 Slave. Do not check "Auto-connect to external synchronization if present", so that the timestamp output of the PMU can be used to drive the sending of C37.118 packets.

• The sensors from the PMU are mapped to appropriate C37.118 Slave signals as shown in the picture below.

• Frequency deviation can be calculated by subtracting the frequency output of the PMU component from the nominal frequency (50 ,60 Hz). This is shown in the following picture. The "Hz_to_mHz" component has a gain value of 1000 and outputs the frequency deviation in mHz.

So, it can be mapped to the frequency deviation signal from the C37.118 Slave driver.

Timestamping C37.118 Slave signals

The PMU timestamp output should not be used to map to the C37.118 Slave signals. The reason is the sampling rate of the PMU timestamp is 1000 Hz so it updates the data every 1 ms. When external clock is selected for communication, if the Timestamp of the PMU is mapped to the C37.118 Slave I/O interface data points (epoch, nanoseconds), because of this refresh rate, the packets are timestamped with 15 ms, 16 ms instead of 16.667 ms. This will cause an issue on how the C37.118 Slave driver is scheduling the data out and might send packets out later and might end up not sending them at all. On Wireshark or PMU Connection Tester, it can be seen that the packets are not being transmitted correctly and this could cause complications if the model is communicating with a phasor data concentrator (PDC).

• The data points for the C37.118 Slave I/O interface related to the timestamp (epoch, nanosecond) can be connected to the data points from the Oregano card Synchronization I/O interface (second, nanosecond) and Sync from C37.118 can be mapped to a constant block with the value of 1. This way, the C37.118 Slave driver is timestamping the C37.118 packets with the timestamp from the Oregano card. A delay of 1 cycle has to be configured between the two sets of data to make sure the C37.118 Slave data points get delayed for one cycle. The delay is important if the PMU model is connected to an external controller or connected to a PDC.

HYPERSIM version older than 2023.1

The picture below shows how the connection can be made using I/O Interface blocks in HYPERSIM versions that are older than 2023.1. Please note that the second and nanosecond signals from the Oregano card in Synchronization are still connected to the clock which is connected to the PMU. There is a fixed delay of 0.016 seconds between the data from the Oregano card and data from C37.118 slave. The delay is only meant for the C37.118 data and should not be used for the Oregano data to the clock that is connected to the PMU as shown in the picture below.

HYPERSIM version from 2023.1 and newer

In HYPERSIM versions from 2023.1 to the most recent ones, the delay can be specified in the Synchronization I/O interface for the Oregano card itself.

In this case, there is no need to create a fixed delay component. Moreoever, in Synchronization I/O interface, two additional data points are created which show the shifted time. 

So, the model could like the picture below. Please note that the shifted time is only used for C37.118 Slave time data points and not for the Clock which is connected to the PMU.

The I/O connection for C37.118 Slave driver signals look like the picture below.

Use of Auto Connect option for C37.118 Slave

The option "Auto-connect to external synchronization if present" means the C37.118 Slave time signals will automatically connect to the time signals from the Synchronization I/O and therefore, the user cannot manually connect them or use them. 

In HYPERSIM versions from 2023.1, if there is shifted time for Synchronization I/O, then the C37.118 Slave will use that to timestamp the C37 packets. If there is no shifted time, it will use the original time. 

Important Note about using simulators with PCIe Oregano card

To achieve the highest accuracy with this PMU and prevent clock drifting, the simulation time step must be synchronized on the syn1588 PCIe Oregano card. For this to happen, an OPAL-RT board I/O interface must be added to the project, the “Clock mode” must be set to "HW" and the "Use external synchronization source" option must be checked. An SMA cable has to be connected between the x7 port of the Oregano card and the clock adapter board for the FPGA. If it is an OP4510, the clock adapter should also be connected to the FPGA RX located on the front panel. Also, at least one signal in the model should be mapped to an analog or digital I/O.

An example of the OPAL-RT Board Interface is shown below. More details on how to use OPAL-RT Board can be found here: OPAL-RT Board.

PMU Time Step

It should be noted that to achieve better measurement accuracy, the PMU sampling frequency should be the same as proposed in the standard [1]: 900 Hz for 60 Hz P class, 750 Hz for 50 Hz P class, 960 Hz for 60 Hz/50 Hz M class. However, using these sampling frequencies will require the simulation time step to be a factor of 1/900 s, 1/750 s or 1/960 s respectively. If the user wants to use the PMU model at such sampling frequencies in HYPERSIM, the code needs to be re-generated with the correct time step in Simulink. Please refer to the confluence document “How to import a Simulink model”. The default time step for the PMU component available with the software is 50 us. 

To generate the code for a different time step, open the Simulink model, in Model Properties - Callbacks - InitFcn, modify the variable iFsamp to a value close to 960. 1/iFsamp has to be an integer multiple of the time step. By default, the iFsamp value is 1000.

References

[1] IEEE Standard for Synchrophasor Measurements for Power Systems," in IEEE Std C37.118.1-2011 (Revision of IEEE Std C37.118-2005), vol., no., pp.1-61, Dec. 28 2011

[2] IEEE Standard for Synchrophasor Measurements for Power Systems -- Amendment 1: Modification of Selected Performance Requirements," in IEEE Std C37.118.1a-2014 (Amendment to IEEE Std C37.118.1-2011) , vol., no., pp.1-25, 30 April 2014