Close loop communication between

RTDS and an external application

TABLE OF CONTENTS..................................................................................................................................... 2
1 Introduction .......................................................................................................................................... 3
2 Socket communication with RTDS ........................................................................................................ 6

-2-
1 Introduction

Many communication protocols have been well established in power system applications. Those

communication protocols include DNP3.0 and IEC 61850 protocol series. The GTNET card is a

communication interface card available in RTDS. The card was developed in order to accommodate

widely utilized communication protocols in power systems during real time simulations. For instance,

GTNET-DNP can allow closed loop communication between RTDS and external SCADA master software

using the DNP 3.0 communication protocol. In such instances, when an external application needs to

depend upon the industry standard protocol, one practical issue arises. This issue is implementation of

the same protocol at the other end of the communication, usually the external application which

intends to talk with RTDS through the protocol. Often, such implementation brings the need to purchase

the necessary protocol stack from a third party software company, mainly because of the complexity of

the protocol stack implementation. Theoretically, writing the necessary protocol stack from scratch

would be possible if enough time and resources are available. However, in most practical circumstances,

the amount of time and effort exceeds what can be afforded. Certain applications come with simpler

requirements, the ability of exchanging data between power system and the applications with no

specific requirement for the type of protocol. In such circumstances, no specific communication protocol

is required, but a simple and easy to use communication interface would be desirable.

GTNET-SKT protocol can address the communication need from the aforementioned circumstance. It is

based on the well-known TCP socket communication program model. Thus, any external application can

connect with RTDS using the protocol as long as the programming environment under the external

application supports the socket programming model. In addition to this simplicity of implementation,

the speed of communication is reasonably fast, which surpass the usual scan rate of SCADA oriented

-3-
protocol such as DNP 3.0. Therefore, the GTNET-SKT can be an attractive candidate for the close loop

communication between RTDS and an external application.

TCP Socket programming model

The TCP socket programming model is regarding the process of communication between two entities,

usually between server and client. The TCP protocol is a connection oriented protocol, whereas UDP

protocol is a connectionless protocol. ‘Connection oriented’ means that once the connection between

the two entities (server and client) is established, the communication channel made out of the

connection can be considered a solid pipe. Consequently, the channel allows a seamless flow or stream

of data from one end to the other. An additional characteristic of the channel is the integrity of the data.

Most of the necessary data integrity checks for the purpose of ensuring the accuracy of the data is

guaranteed in the underlying layer of the communication. Therefore, such checking becomes redundant

at the application level where an external application is to be implemented, unless there are extra

requirements, such as data encryption. In the programming model, the role of the server is distinctively

different from the client. The role of the client, and the necessary handshaking procedure from the

client, is much simpler than the role of the server. From the clients side, the communication can be

initiated by asking for the connection to the server, usually through an API call ‘connect()’. The data can

then be exchanged between the client and server asynchronously. A certain amount of data can be sent

from the client to server. In response to the incoming data from the client, the server would send a

certain amount of data to the client. A notable point here is the asynchronous nature of the data

exchange. The client cannot anticipate the time when the data sent by server will arrive. And the server

cannot pre-determine the moment of data arrival. Therefore, the socket programming necessitates

asynchronous programming model. The traditional way of handling the asynchronous nature of the

communication is using call back functions. The event dispatcher, which is part of TCP protocol stack

implementation, would select the call back function corresponding to the event at the protocol stack.

-4-
Interestingly, the usual name of the dispatcher function is ‘select()’. More and more programming

environments offer threads as an alternative way of handling the events. The role of the server is more

complicated than that of the client. The server usually starts with listening to a certain TCP port.

‘Listening’ means that the server is waiting for the incoming communication request from a client. Once

the client initiates the communication by the ‘connect()’ function, the server accepts the request and

spawn a separate client handler for the connection. In the thread approach, the spawning means

starting a new thread where the data exchange would be handled. One complication coming from this

server action is the ability to serve multiple clients simultaneously, which explains the higher level of

difficulty in server implementation. Handling the multiple clients simultaneously and how to economize

the allocated resource for such handling is another substantial topic, which is not delved into here.

The following diagram, Figure 1, presents the programming concept of the socket programming model

figuratively:

-5-
 Figure 1 TCP socket programming model

2 Socket communication with RTDS

This demonstration is composed of three steps. The first step starts with a simple RTDS simulation case,

where the GTNET-SKT model representing the GTNET-SKT communication interface card is utilized. The

same RTDS simulation case will be utilized through the three steps explained in this chapter. In the

simulation case, a specific number of data points (20 in this demonstration) are generated and sent to

an external application. In this demonstration, the GTNET-SKT takes the role of socket server, while the

external application plays the role of the socket client. The communication initiates from the client side

first. Once the socket is established (the state of the connection can be detected from an output

-6-
variable of the socket model), the GTNET-SKT starts to send the data points to the external client at a

given update frequency. The transmission frequency can change while the simulation case runs, using a

slider in this simulation case. The external application receives the incoming data packets from the

GTNET-SKT and extracts those data points (20 floating point numbers). It then tries to manipulate the

data, adding a small number in this demonstration, in order to make the outgoing data from the client

different from the incoming data from the server. Once the manipulation is complete, the client sends

back those data points to the server, which is the GTNET-SKT. Finally, those data points appear as output

points from the GTNET-SKT model in the simulation case. The value of the data points can be verified in

Runtime.

In the first step, the external client is implemented using MATLAB M script. The necessary socket

communication related commands were introduced in MATLAB version 2014b. The MATLAB M file

explained in this demonstration should run in the proper MATLAB version (after version 2014b). The

second step is to replicate the same function of the MATLAB M script using MATLAB/Simulink. A user

defined Simulink model was written using Simulink L2 user defined modeling capability. In this step,

dynamic interaction between the two different simulation environments, namely MATLAB/Simulink and

RTDS can be observed. The last step incorporates a standalone client application written in C# language,

therefore, no additional programming environment such as MATLAB is necessary.

RTDS simulation Draft

This demonstration offers the TCP socket communication capability between the RTDs and the external

application. The following figure, Figure 2, presents the RTDS simulation Draft used for the

demonstration:

-7-
 Figure 2 RTDS Draft for the GTNET-SKT demonstration

The simulation case can be divided into 4 different sections, as shown Figure 2. The GTNET-SKT

simulation model is in section 1. This model represents the GTNET-SKT card installed in the RTDS rack.

Section 2 in the simulation case generates the first data points from the simulation. One of the output

signals from the GTNET-SKT model, ‘ready1’ signal, indicates whether or not a socket channel is

established between the RTDS and the external application. The first transition from 0 to 1 of the

variable indicates that the communication channel is ready for transmitting data. In order to generate

the data from RTDS simulation case, a simple controller was implemented. The control in the case

-8-
generates 20 points of floating number data with a certain update frequency. The update frequency can

be adjusted while the simulation case is running by a slider. By applying different update frequency, the

performance of the external application can be measured. A counter generates a signal named ‘TSTEPx’

in the case. The variable increases every time step. The AND gate next to the counter logic begins to

produce a series of pulses to the counter model next. Note that the pulse comes from the AND gate

every two time step, because the logic gate works only on LSB(Least Significant Bit) of the input. The

pulse train goes into the synchronous counter model, and the counter produces the output variable

named ‘TSTEP’. The variable is compared with a slider input. Once the value becomes equal to or larger

than the slider input, a reset signal named ‘RST’ is generated. The signal resets the counter which

produces the ‘TSTEP’ variable. In effect, the ‘RST’ variable represents a slower rate pulse train. For

instance, if the size of time step is 50µS and the given value to the slider is 10, then the ‘RST’ pulse

occurs every 1ms (1000µs = 50*2*10), and the ‘RST’ pulse goes into another synchronous counter which

produces the first data point labeled as ‘MYSTATUS0’. The value of this data point increases with the

same period as the ‘RST’ pulse. Section 3 generates the rest of the data points, 19 in total, from the first

data point, ‘MYSTATUS0’. The data point ‘MYSTATUS1’ is made by adding a small value, 0.01, to the

‘MYSTATUS0’. The next data point ‘MYSTATUS2’ is made by adding a small value, 0.02, to the

‘MYSTATUS0’. In this way, all of the data points will have distinctive values while they increase at the

same rate as the first data point. Section 4, measures the time elapsed between each update of an

incoming data point, ‘MYCONTR0’. The data send command is issued by an input signal to a port named

‘SendDataFlag’ in the GTNET-SKT model. The signal is stimulated with the every logic transition from 0 to

1 in ‘RST’ signal. The signal labelled as ‘startx’ represents this logic transition, and the command is issued

with the same period as the data update period of the input data points. The GTNET-SKT model also

provides the output values which represent the incoming values from the client. The model has 20

-9-
output points, the first one labelled as ‘MYCNTR0’ and the last one as ‘MYCNTR19’. These output points

make the verification of the incoming data possible when the simulation case runs.

RTDS simulation Runtime

The close loop communication can be verified at the Runtime screen as presented in the following

figure, Figure 3:

Figure 3 RTDS Runtime for the GTNET-SKT demonstration

The input data point update period can be adjusted by the slider at the left side. The ‘tupdate’ meter

shows the current update period in seconds. The two meters at the bottom of the slider presents the

number of errors which have occurred during the communication. The upper meter indicates the

-10-
number of invalid packets received and the lower meter indicates the number of socket overflow

occurrences. The case is equipped with an external plot update model, which updates the two groups of

plots in the Runtime when the Runtime is armed by engaging the ‘Arm External Plot Update’ button

marked within a red box in the above figure, Figure 3.

MATLAB client

As mentioned, a native API set for socket programming was introduced from MATLAB version 2014b.

The first step for constructing the client for the close loop communication testing is based on the newly

introduced API set in MATLAB M script. The following figure, Figure 4, presents a simple

implementation. The name of M file is ‘Socket_20pts.m’.

Figure 4 A TCP client written in MATLAB M script

At line 1 and 2, the server IP address and port number are assigned. The IP address and port number

must match with the GTNET-SKT IP address and the port number given to the GTNET-SKT model in the

-11-
RTDS simulation case. The following lines, from 5 to 8, declare and initialize the variables in order to

minimize the necessary execution time. At line 11, the client socket is declared. At the same time, a

connection request is sent to the server at the execution of this line. From line 15 to line 30, an infinite

loop handles the actual communication. At line 17, data is read from the established socket channel, 80

bytes in total. As mentioned earlier, the total number of points coming from the server is 20. Each point

is in single precision floating point number format. Thus, the incoming amount of data at each data

update at the server is 80 bytes. At line 18, the data order is modified from the network byte order (big

endian) to the PC byte order (little endian). The ‘For’ loop between line 20 and 22 adds a tiny number to

each incoming data points. The results make the outgoing data points, which would be sent to the

server. At line 24, the buffer data type is cast back to the single precision. At line 26, the byte order of

the buffer is changed back to the network byte order and the type is cast to unsigned integer 8 bit type

(unsigned char type). Finally, the content of the buffer is transmitted towards the server at line 28.

Figure 5 presents the screen capture of the plot update:

-12-
 Figure 5 Loop back communication

The value next to the plot labelled ‘Subsystem #1|GTNET SKT|GTNETSKT1’ presents that the incoming

data point ‘MYCONTR0’ reflects the tiny number (0.005 in this case) added onto the incoming data point

by the MATLAB M script. In this experiment, the update period at the server (or RTDS) side was set as

5ms, as noted from the meter value next to the slider in the above Runtime screen capture, Figure 5.

Another interesting point we can observe from the plot is the irregular update period of the incoming

data points from the MATLAB software, as evident in the following plot zoom capture image, Figure 6:

-13-
 Figure 6 Irregular update period from MATLAB M script client

This irregularity indicates that the execution of the application inside MATLAB wouldn’t be light enough

to follow the outgoing data update period which is determined at the server (RTDS) side, which is 5ms in

this experiment. In other words, it frequently takes more than 5ms by the MATLAB client execution to

send the data points back to the server in this experiment, though the actual manipulation of the data at

the client is trivial (adding 0.005 to each point).

Simulink client

In this step, a Simulink environment was utilized to construct the communication client. The client code

written in the previous demonstration can be migrated into the MATLAB/Simulink environment by

writing a user defined Simulink model. In order to utilize the existing MATLAB code as much as possible,

the S-function L2 user defined modeling technique was used when the user defined model was written.

The model was composed of many call back functions written in MATLAB M script format. Therefore,

writing the necessary code for the model became much easier, mainly because the MATLAB M code in

the previous example was already verified. Here is the Simulink case screen capture:

-14-
 Figure 7 A Simulink client

The tiny number added onto the incoming data points from the server became the input to the socket

communication model. As before, the MATLAB version should be the same or newer than version 2014b

in order to utilize the native socket API support. The simulation end time is given as ‘inf’ (infinity) in the

left top corner in order to run the close loop communication experiment as long as necessary. There is a

timeout parameter given to the underlying socket, therefore, the simulation in Simulink will stop once

the timeout of the communication channel is detected. The following figure, Figure 8, shows the

parameter dialog box of the socket communication Simulink model:

-15-
 Figure 8 Simulink model parameters

The necessary IP address and port number for the socket communication are given as parameters, as

seen in the above figure. Again, the IP address must match the GTNET-SKT IP address and the port

number must match the port number assigned to the GTNET-SKT model in the RTDS simulation case.

The following figure, Figure 9, presents the plot update, triggered by the starting of the socket

communication between the Simulink client and the RTDS server:

-16-
 Figure 9 Plot update with Simulink client loop back communication

The long period of pause in the middle of the plot indicates the obvious data exchange stall which

occurred on the Simulink client side. The pause and the resulting irregularity of the data update from

the client side clearly indicate the heavier burden of execution at the Simulink and MATLAB. There may

be different ways to expedite the execution speed of the Simulink model, which were not explored in

this experiment. The update period set at the server side was the same as the previous experiment,

which was 5ms. The communication testing was terminated by the exception occurred at the client side,

-17-
another obvious indication that such high speed of updating is beyond the execution capability of the

MATLAB and Simulink environment. The testing will probably become smoother once the length of the

update period lengthens at the server side, but such experiments were left for as the users’ own trial.

Standalone client written in C#

A simple TCP standalone client application was written in a general programming language environment

(C#/Visual Studio) in order to check the ability of a usual PC in keeping up with the data update rate

determined from RTDS/Server side. The following screen capture, Figure 10, shows the appearance of

the application:

Figure 10 A standalone client application

The order of execution in the code is almost identical to the MATLAB M script in previous steps. The

actual communication client, however, was made as an independent thread from the main execution

-18-
thread for the following reasons: 1) in order to separate the main window event handling loop from the

loop back communication, allowing the main window to be responsive and to be able to update while

the close loop communication is running, and 2) in order to expedite the execution time of the

communication loop itself.

The following plot screen capture, Figure 11, presents the result from the experiment.

Figure 11 Plot update with standalone client

-19-
When this plot is compared with the previous two experiments, it becomes clear that the data point

update interval is almost the same as the given period at the RTDS/server side, indicating that the

standalone application is much lighter in execution and able to handle a much tighter loop with the

RTDS/server. In order to verify the superior execution characteristic, the data point update period at the

server side was brought down to 1ms. The following screen capture presents the result from this

experiment:

Figure 12 Standalone client with 1ms data update period

The close loop communication was successfully maintained with the new update period of 1ms. With

such a short update period, the previous two experiments, the first on MATLAB and the second on

Simulink, failed because the execution of the code could not catch up with the volume of incoming data,

which was generated by the fast update speed. We can also note that the delay measured at the

RTDS/server side fluctuates, sometimes approaching 5ms, but as mentioned, the standalone application

was able to manage the fast incoming data stream while sending back the manipulated data stream to

the server in a timely manner.

-20-