...
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 fileFile' 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.
...
| 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 responsivity 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 ('). |
...
| 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 localhost Local IP address used must be used ('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. |
...
| 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 fileFile' section. The name should be placed between single quotes ('). |
...
| 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 fileFile' 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 x 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. |
...
Rectangular representation: real and imaginary (real value first), 16-bit signed integer, ranges in ± 32 767±32767
Polar representation: magnitude and angle (magnitude first)
...
Angle -> 16-bit signed integer, in radians x 10^4, ranges in ± 31 416 (± PI x ±31416 (±PI × 10^4)
Floating point
Rectangular representation: real and imaginary (real value first)
...
Angle -> in radians, ranges in ± PI±PI
Here is an example of the content of a configuration file:
...
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 anyissue 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() commands 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 httphttps://pmuconnectiontester.codeplex.comgithub.com/GridProtectionAlliance/PMUConnectionTester.
Characteristics and Limitations
...
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.
...
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 20frames 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).
...