Block

Mask

Description

The OpC37_118_AsyncSlaveCtrl block allows users to define the asynchronous process parameters that instantiate a C37.118 slave session that can be used to report data to a C37.118 master.

The C37.118 communication protocol has been implemented according to the IEEE Std C37.118.2-2011 standard. However, some features are not actually supported. Please refer to the limitations section for more information.

One OpC37_118_AsyncSlaveCtrl block has to be present for each equipment that needs to report data using the C37.118 protocol. The communication is handled by the asynchronous process that is responsible for the data exchange between the model and the external equipment. This asynchronous process is an independent executable that needs to be transferred to the target and is launched during model initialization.

An example of a synchronous process is provided with the model example and is named 'AsyncC37_118_Slave'. Although this asynchronous process code should cover most of the typical C37.118 applications, it is the user responsibility to adapt it according to its application requirement. This file needs to be transferred to the target during model compilation. A configuration file is also required to configure the block inputs and also needs to be transferred to the target before the model load. The configuration method is explained in the 'Parameters' and 'Configuration File' section.

Three communication protocols are actually supported: TCP only, UDP only or TCP/UDP. It is the user responsibility to select the communication protocol that matches its requirements. More details can be found in Annex F of the IEEE Std C37.118-2-2011 document.

Data exchange between the model and the asynchronous process includes: phasor data, analog data, digital data, frequency deviation from nominal, frequency rate of change and timestamp. These signals will be used to build the C37.118 packets sent to the C37.118 master. If the user requires precise timestamp, it is very important to connect the timestamp input to a reliable time source and to execute the model in XHP mode. See additional details in the 'Inputs' section.

Parameters

General

Device ID	Specifies the device ID. Each C37.118 block must have its own device ID.
Device name	Specifies the name of the equipment reporting C37.118 data. This name will be included in the configuration sent to the C37.118 master. The device name is limited to 16 characters and should be placed between single quotes (').
Core number	Specifies the core number where the asynchronous process will be executed. Usually, all the asynchronous processes are executed on core 0. If for some reason, the core 0 is very busy, it is possible to execute the asynchronous process on a different core. In this case, it is the user responsibility to make sure that there is no subsystem running in XHP on the selected core.
Executable name	Specifies the name of the executable file of the asynchronous application that handles the low-level communication transactions. Note: at this time, the only precompiled executable available for C37_118 control is 'AsyncC37_118_Slave'. The name should be placed between single quotes (').

Communication

Network interface name	Specifies the network interface name of the Linux target. On most Linux systems, the interface name is 'eth0'. However, it is possible to get the network interface name by running the `ifconfig` command on the target. If the target is equipped with more than one network interfaces, the user can assign different simulated IEDs to different network interfaces and reduce the Ethernet traffic that will have to be handled by each of them. If the C37.118 master used to connect the slave is running on the same target, the loopback interface must be used ('`lo`'). The name should be placed between single quotes (').
Protocol	Specifies the protocol that the C37.118 master will use to communicate with the C37.118 slave. The supported protocols are TCP only, UDP only, and TCP/UDP. In TCP/UDP mode, TCP is used for commands, header and configuration communications whereas UDP is used for sending data. In this mode, the user must specify the UDP port that will be used to send data to the C37.118 master.
Local IP address	Specifies the IP address of the C37.118 slave equipment. During model initialization, the asynchronous process will create an IP alias on the configured network interface so that the IED will be reachable through this address. Each IED will have its own IP alias (i.e. eth0:0, eth0:1, eth0:2, etc.). To validate that the configuration is correct, the user can run the `ifconfig` command on the target once the model initialization is done. Each IP alias should appear in the list: if it is not the case, there is probably a problem with the configuration parameters. If the C37.118 master used to connect the slave is running on the same target, the Local IP address used must be ('127.0.0.1'). The IP address should be placed between single quotes (').
Local port number	Specifies the TCP or UDP port that will be used by the C37.118 master to establish a connection with the C37.118 slave. This number can be the same for different simulated IEDs.

Inputs

Nominal frequency	Specifies the nominal frequency of the equipment reporting C37.118 data. This frequency must be the same than the block connected to the C37.118 slave block.
Data reporting rate	Specifies the rate at which the C37.118 slave block will report the C37.118 data frames to the C37.118 master.
Input configuration file name	Specifies the name of the input configuration file that is used to specify information about the connected inputs (number, format, representation, names, etc.). Additional information about this file will be found in the 'Configuration File' section. The name should be placed between single quotes (').

Inputs

Phasor inputs	As a phasor measurement consists of magnitude and an angle, or a rectangular part and an imaginary part, this input will accept phasor information in pairs. The phasor representation must be specified in the configuration file. If the phasor representation is polar and the block only reports one phasor measurement, two signals have to be connected to the phasor input; the first being the magnitude and the second being the phase. If the block reports two phasor measurements, four signals have to be connected to the phasor input in the following order; magnitude(1), angle(1), magnitude(2), angle(2). They can be either voltage or current phasors. The format, type, name, and unit of the phasor measurements have to be specified in the configuration file. Please see the 'Configuration File' section for details about the input format and units.
Analog inputs	This input will accept a bus of analog values that will be reported within the C37.118 data frames. Typically, it can be a sampled data such as control signal or transducer value. The data format, name, type, and unit of the analog inputs have to be specified in the configuration file.
Digital inputs	This input will accept a bus of digital values that will be reported within the C37.118 data frames. Each input represents a 16-bit channel value that will be reported within the C37.118 data frames. The name and unit of the digital inputs must be specified in the configuration file.
Frequency deviation from nominal	This input will accept a single signal representing the frequency deviation from nominal. It is also reported within each C37.118 data frame. It has to be in mHz (millihertz) unit. The data format (16 bits integer or 32 bits floating point) must be specified in the configuration file.
Frequency rate of change	This input will accept a single signal representing the rate at which the frequency varies, also known as ROCOF. It is also reported within each C37.118 data frame. It has to be in (Hz/sec × 100) unit. The data format (16 bits integer or 32 bits floating point) must be specified in the configuration file and has to be the same as the 'Frequency deviation from nominal' format.
Timestamp	This input will accept a bus of 3 signals with timestamp information. The first signal must be a binary value (0 or 1) that represents the synchronization state of the timestamp. If the timestamp is synchronized with an accurate external source such as a GPS clock, the value applied to this signal should be 1 and otherwise, it should be 0. This value will appear in each 'Time qualify flag' of the data frames to provide information to the C37.118 master about the validity of the timestamp. The second signal should represent the number of seconds elapsed since January 1st, 1970, commonly known as the Unix epoch time. It means that it has to increment at each second. The C37.118 slave uses this signal to timestamp the outgoing packets. The more accurate this epoch time input is, the more accurate is the timestamp of the outgoing packets. It is important to understand that if no increment is detected at this input, no data frame will be sent by the C37.118. Therefore, if no epoch time source is available, a 1 second counter must be connected to this input (see example model). The third signal of this bus should be an incrementing counter representing the current microsecond. The C37.118 slave uses this signal to set the Fracsec field of the outgoing packets. Ideally, the timestamp input should come from an accurate synchronization source. Otherwise, there is no guarantee on the data sampling, reported data rate and fraction of second information. The C37.118 protocol has been validated with a GPS synchronized Spectracom TSync PCIe board. A control block for this board is available in RT-LAB and it provides the signals required by the C37.118 slave block for an accurate timestamp. In this case, the maximum error on each packet timestamp is the step size of the model.

Outputs

Status: This output is a 5-value-wide vector that contains status and error codes that can be updated by the asynchronous process. In normal operation, error codes should be 0.The bus can be de-multiplexed as shown below:

Index	Description
0	Phasor input(s) send error
1	Analog input(s) send error
2	Digital input(s) send error
3	Frequency deviation from nominal send error
4	Frequency rate of change send error

Configuration File

The input configuration file has a custom format that must be respected in order for the asynchronous process to compute it correctly. The file format is validated at the start of the execution. Each C37.118 slave block requires a different input configuration file unless their configuration is the same. This section explains all the input parameters but if additional information on the format, conversion units or representation is required, the user must refer to the IEEE Std C37.118.2-2011 standard.

Note: For phasor, analog inputs and frequencies, the format must be set according to the data format of the signal connected to the C37.118 slave block (16-bit integer or floating point).

Parameter	Description
phasor_nbr	Number of phasors. It must match the number of phasor measurements connected to the C37.118 slave block. Note that one phasor requires two data signals, so if this field is set to 2, four signals must be connected to the phasor input in the following order: magnitude(1), angle(1), magnitude(2), angle(2).
phasor_representation	Must be set to POLAR or RECTANGULAR. This setting is effective for all the phasor measurements reported by this equipment. See (*) below for more details.
phasor_format	Must be set to 16_BIT_INTEGER or FLOATING_POINT. See (*) below for more details.
phasor_names	Specifies the name of each phasor measurement, separated by (;) delimiters. Limited to 16 characters.
phasor_types	Must be set to VOLTAGE or CURRENT for each phasor measurement, separated by (;) delimiters.
phasor_units	Specifies the unit of each phasor measurement, separated by (;) delimiters. If the data format is 16-bit integer, each unit has a conversion factor of 10^-5 V or amperes on the phasor magnitude. For example, if the signal connected to the phasor input has a magnitude of 11 000 and the specified unit for this phasor is 100, the value will be interpreted as (11 000 * 100 * 10^-5) = 11 by the C37.118 master. This scaling feature is defined by the standard. If the data format is floating point, this scaling does not apply.
analog_nbr	Specifies the number of analog values to be reported. It must match the number of analog measurements connected to the C37.118 slave block.
analog_format	Must be set to 16_BIT_INTEGER or FLOATING_POINT.
analog_names	Specifies the name of each analog measurement, separated by (;) delimiters. Limited to 16 characters.
analog_types	Must be set to SINGLE_POINT_ON_WAVE, RMS_OF_ANALOG_INPUT, PEAK_OF_ANALOG_INPUT depending on the reported data type. It must be set for each analog measurement, separated by (;) delimiters.
analog_units	Specifies the unit of each analog measurement, separated by (;) delimiters. It is a user-defined scaling that must be part of the reported data frame in order for the C37.118 master to interpret it.
digital_nbr	Specifies the number of digital values to be reported. It must match with number of digital measurements connected to the C37.118 slave block.
digital_names	Specifies the name of each digital measurement, separated by (;) delimiters. Limited to 16 characters.
digital_units	Specifies each digital mask, separated by (;) delimiters. Two 16-bit words are provided for each digital word. The first word is used to indicate the normal status of the digital input by returning a 0 on a logic (XOR) with the corresponding digital input (also referred to as status word). The second word indicates the current valid inputs to the PMU by setting the bit in the binary position corresponding to the digital input to 1 and all other bits to 0. If the digital status words are used for something different than Boolean status indication, the use of masks is left to the user, such as min or max settings.
freq_format	Must be set to 16_BIT_INTEGER or FLOATING_POINT.

(*) The phasor signals connected to the C37.118 block must match the settings that specify the representation and the format. Conversion in the model might be necessary. Please refer to the information below, coming from the C37.118 standard:

16-bit integer

Rectangular representation: real and imaginary (real value first), 16-bit signed integer, ranges in ±32767

Polar representation: magnitude and angle (magnitude first)

Magnitude -> 16-bit unsigned integer, ranges from 0 to 65535

Angle -> 16-bit signed integer, in radians x 10^4, ranges in ±31416 (±PI × 10^4)

Floating point

Rectangular representation: real and imaginary (real value first)

Polar representation: magnitude and angle (magnitude first)

Magnitude -> no range limit

Angle -> in radians, ranges in ±PI

Here is an example of the content of a configuration file:

File Transfer

As explained in the 'Description' section, the asynchronous process executable file must be transferred to the target and compiled before loading the model. This is also true for the input configuration file. This is done through RT-LAB by setting the correct parameters in the 'File' tab of the model. If you experience any issue with the file transfer, please refer to the example model. Here is an example where the input configuration file is named 'pmu_in_cfg.xml':

Debug

As the asynchronous process executable file is provided to the user, it is possible to add OpalPrint() function calls anywhere into the code if necessary. To receive more information from the C37.118 library, the user can change the C37_118_slv_set_trace_level() parameter in the asynchronous process source code. Also, it can be useful to monitor the network interface using a sniffer tool such as Wireshark. In this case, it is important to decode the port as 'Synchrophasor' so that the TCP and UDP data gets automatically interpreted by the tool.

Finally, to validate the communication, it is possible to download an open-source tool named 'PMU Connection Tester' that acts as a C37.118 master. This tool can be found at https://github.com/GridProtectionAlliance/PMUConnectionTester.

Characteristics and Limitations

The actual version of the block has the following limitations:

Stat word: The statistic word is not supported and will be 0 within all reported packets.

Time quality: The time quality leap second information is not implemented and will be 0 within all reported packets. Also, the time quality indicator can only take 0x0 or 0xF values. The time indicator will be 0x0 when the first input of the timestamp signal is 1 (valid) and 0xF when the first input of the timestamp signal is 0 (invalid). See 'Inputs' section for more details.

Fracsec: The Fracsec value of the data frames is reported in microseconds.

Configuration frames 1 & 2: The configuration reported by the C37.118 slave following a CFG-1 or CFG-2 command is the same.

Configuration frame 3: The configuration frame #3 is not supported.

Timestamp resolution: The timestamp resolution is given by the model step size and is only guaranteed in XHP mode. It means that if the model is running in XHP mode, the fracsec field error is guaranteed to be within the +/- model step size over 2, in microseconds. As an example, if the block is configured to send 20 frames per second, the fracsec field will be a factor of 50 000 microseconds. If the model runs in XHP mode with a step size of 30 microseconds, the fracsec of the first data frame is guaranteed to be between 0 and 30 microseconds. In the second frame, it is guaranteed to be within the 49985 and 50015 microseconds. This field represents the microsecond within the second when the reported data was measured.

Extended frame: When the C37.118 slave block receives an extended frame command, it executes a callback function that needs to be registered by the asynchronous process during the initialization (see C37_118_slv_register_cb() in the asynchronous process example). It is the user responsibility to write this callback function and take action depending on the received packet.

Header frame: When the C37.118 slave block receives a header command, it replies by sending a user-defined string. This string is defined into the asynchronous process (see PMU_HEADER in the asynchronous process example). The user can use this string to provide additional information on the equipment reporting C37.118 data. This header frame can be dynamically modified during the simulation if required (see C37_118_slv_set_hdr_frame() in the asynchronous process example).

Direct Feedthrough	No
Discrete sample time	No
XHP support	Yes, and recommended for accurate timestamp
Work offline	No