You are on page 1of 4

This work-in-progress paper was presented as part of the main technical program at IEEE ETFA'2011

Applying PTP-to-SNTP Time-Gateway to IEC61850 systems


Paolo Ferrari, Alessandra Flammini, Stefano Rinaldi
Department of Information Engineering
University of Brescia
Via Branze 38, 25123 Brescia, Italy
stefano.rinaldi@ing.unibs.it
Abstract
The paper describes the application of an improved
Time Gateway for simplifying the integration of old IEC
61850 devices in new IEC 61850 Substation Automation
System with IEEE 1588 PTP. Old devices typically
retrieve time information with the well-known SNTP
protocol which uses very different time representations
and synchronization strategies with respect to PTP.
Hence, the paper uses a transparent, full-software, Time
Gateway for interfacing SNTP devices with a PTP
synchronization domain, demonstrating its applicability
by means of a prototype based on an FPGA.
Experimental results show the Time Gateway improves
the overall performance with respect to an SNTP-only
system. Moreover, the experiments demonstrate that the
synchronization accuracy is limited by the SNTP.

1. Introduction
The IEC 61850 standard [1] for the design of
substation automation systems has been established as
the main communication and system standard within the
substation domain. As such the substation automation
domain is in an easier situation than other parts of
automation where there are numerous communication
technologies competing for market shares. The IEC
61850 standard is used throughout the world and has a
considerable installed based. The first edition was
released in 2003 and the second edition is upcoming.
Electrical substations have strict requirements on time
synchronization in order to ensure that the system
performs according to the specifications so that the
resulting power output meets the desired characteristics.
In the first edition of IEC 61850 standard the time
synchronization requirements were handled via the
SNTP (Simple Network Time Protocol) standard. A
typical requirement could be to synchronize devices in
the systems to within 1 ms. In a relatively small system
this could be achieved with the use of SNTP.
In present substation automation systems the
complexity and size of the systems grow and the
requirements get tougher. Thus, fulfilling the time
synchronization requirements in such systems with the
use of SNTP is getting increasingly difficult. Because of
978-1-4577-0018-7/11/$26.00

2011 IEEE

Gunnar Prytz
ABB Corporate Research
Bergerveien 12
NO-1396 Billingstad, Norway
Gunnar.Prytz@no.abb.com

this the IEEE 1588 Precision Time Protocol (PTP) is


now in the process of becoming the new standard for
time synchronization in substation systems [2].
Going for PTP as the synchronization technology
makes a lot of sense from a technical perspective and
this trend is clear in most automation domain. However,
it brings with it numerous challenges. The obvious
challenge is that there is a need to have PTP support in
the network infrastructure in such systems, i.e. that the
Ethernet switches and network interfaces have to support
PTP in hardware in order to be able to provide accurate
time stamping of the PTP packets which is a prerequisite
for accurate synchronization. New substation devices
requiring accurate synchronization will thus presumably
be designed with proper support for PTP both in
hardware and software. In addition, the network
infrastructure in such systems then needs to be based on
devices such as switches with PTP support in hardware.
The challenge addressed in this paper is a different
one related to the installed base of IEC 61850 devices
without PTP support. It may be possible to add support
for PTP through a software update but this may not be
sufficient for achieving accurate time synchronization.
This would require a new hardware, i.e. a full
replacement of the system. This is not realistic in
practice and the substation domain will thus have to live
with devices without PTP support for quite some time.
The PTP and SNTP protocols can coexist on a
network, indeed coexistence of protocols is one of the
main features of modern industrial Ethernet networks
[2][4] (except those in the so-called Real-time Ethernet
domain where the time-critical requirements make
coexistence not feasible). Thus, PTP can be used by new
devices and SNTP by old ones in the same system.
However, this does not solve everything as systems get
bigger and more complex. A main drawback of SNTP
compared with PTP is the susceptibility to network size
and load. This is mainly since PTP is implemented
differently from SNTP and takes network jitter and
delays into account. The task of SNTP is getting even
more difficult when large substation systems are missed
with process automation systems into one big network.
In such scenarios it would be beneficial to reduce the
usage of SNTP as much as possible. This can be
achieved in several ways; one possible way is to use PTP

until the last link to the SNTP device. Since a sort of


translation from PTP to SNTP has to be done, a TimeGateway transparent to all other traffic (as in [5]) may be
used. In networking terms this would be a bridging
device according to IEEE 802.1D with PTP and SNTP as
higher layer entities, as applied in this paper.

The most part of the desired features can be found in


the device introduced in [5]. In the following after a brief
description of the existing Time Gateway architecture,
specific improvements for IEC61850 are presented.
GPS Receiver

Time Gateway

End Device

(PTP Master)

(Boundary Clock)

(SNTP Client)

2. Typical application scenarios


A Time Gateway such as the one described in this
paper could be used in numerous scenarios. One typical
scenario would be a modern substation system where
there is a mix of new and old devices, e.g. a system that
has been updated or extended. Even if the time
synchronization requirements have not increased it may
get more difficult to fulfill the requirements for old
devices with the use of SNTP when the network gets
bigger and more complex. Instead of replacing the whole
system the Time Gateway may be used to increase or at
least maintain synchronization accuracy in old devices.
In another scenario there may be installed systems
where the requirements related to time synchronization
have been increased. This can be handled by adding the
Time Gateway functionality to these devices.
The principle of adding a Time Gateway to existing
devices or nodes in general applies not only to substation
automation systems. It is of general interest to have a
way to increase and in some situations just to maintain
the time synchronization accuracy of legacy automation
devices so that they can continue to be used also in
modern industrial Ethernet systems. As such this
represents a cost optimized approach and a step towards
a networked future where there is only advanced devices
with all necessary communication features present.

Eth
10/100

Eth0

Eth1

PTP

SNTP

PTP Aware
network infrastructure

PTP Domain

SNTP Domain

Figure 1. Application of the Time Gateway.


3.1. Short description of the Time Gateway
The block diagram of the Time Gateway is shown in
Figure 2. It is based on FPGA and it has two network
interfaces: one for the PTP domain and the other for the
SNTP domain. The logic architecture of the Time
Gateway is built around a NIOS II fast core, a 32 bit soft
processor (control block) and has special peripherals for
processing the data coming from the networks. For
instance the Timer block is the source of time for the
Time Gateway device. The management of the
synchronization stacks and the routing of network
packets are done by software, so the proposed solution
can be classified as a full software boundary clock.
FPGA

DDR
Contr

NIOS II

3. The applied solution


The Time Gateway must be able to convert PTP time
format into the preferred time format, such as SNTP. In
other word, the gateway must be a boundary clock, being
able to act as a PTP slave on one side of the network,
and as an SNTP server on the other (i.e. a boundary
clock). As shown in Figure 1, the Time Gateway must be
connected directly on the cable, between the SNTP
Client and the PTP-aware infrastructure. The Time
Gateway must be easily configurable, with assort of a
plug and play capability, and transparent to the network
management tools. Never less, additional configuration
interfaces may be required by the user as, for instance,
web interface for configuring the PTP application or the
SNTP Server. From the performance point of view, since
the IEC61850 standard suggests considering 1 ms as the
overall synchronization accuracy on the station bus of
a Substation, the target synchronization accuracy for the
Time Gateway applied to the IEC61850 should be 500s
or less.

Eth
10/100

Clinux (PTPd, SNTP, FTP, HTTP, ..)


Control Logic Block

Flash
Contr

DDR
SDRAM

FLASH

Avalon

PLL

Timer

Eth
MAC0

MDIO
Contr

Bridge

MAC 10/100
SMSC
LAN 91C111
Eth0 10/100 1588

Figure 2. Block diagram of the Time Gateway.


A large external memory (32 Mb DDR SDRAM chip
in the prototype) is required to run the OS. The two
Ethernet ports have been implemented in a different way
in order to allow future improvements. The Ethernet port
attached to the PTP domain is able to support the PTP
protocol with hardware timestamping and could satisfy
strict
synchronization
accuracy
(below
one
microsecond). However, in this paper, this feature has
not been activated and the PTP is timestamped in

software. An Ethernet MAC controller implemented in


VHDL is connected to such Ethernet PHY. On the SNTP
side, a traditional 10/100 Mbps Ethernet PHY+MAC
chip (LAN91C111); such a solution is acceptable
because the SNTP protocol does not support hardware
timestamping and future improvements are unlikely.
The NIOS II embedded system uses the Clinux OS
(kernel 2.6.30), a Linux kernel for MMUless processors
with at least 32 bit addressing. The Clinux OS occupies
less than 300 Kbyte of memory, but the OS supports
almost all of the Linux API and most of the traditional
Linux system calls are available for programming.
Clinux provides a built-in IP connectivity, a full
multitasking environment, and a pre-emptive kernel. The
Figure 3 shows the software stack of the Time Gateway.
On the top, PTPd [7] daemon, a software only
implementation of the PTP protocol which supports PTP
V1 and V2, with messages mapped to layer 2 or layer 3.
As any software implantation, the sync messages are
timestamped at kernel level and the received time is used
to estimate the offset of the local clock from the Master
Clock. A standard SNTP server (MSNTP Server) is used
to forward the time information to the attached SNTP
device (client). Last, an FTP server, a web server (Boa
server) and telnet have been added to the system in order
to configure the device with a user friendly interface.
3.2. Improvements for IEC61850 applications
There are two main aspects to be considered for
application of the Time Gateway to the IEC61850
domain: transparency to other protocols used by the
attached device; and synchronization accuracy of the
software only implementation.
An IEC61850 substation has quite complex network
architecture with several protocols for managing and
healing the network fault. For such a reason the Time
Gateway introduced in [5] must be improved in
transparency. Any Ethernet packet received on interface
Eth0 which is addressed to a device connected on Eth1
has to be forwarded from Eth0 to Eth1. Similarly, any
Ethernet packet received on interface Eth1 which is
addressed to a device connected on Eth0 has to be
forwarded from Eth1 to Eth0. For this reason, Clinux
has been compiled to support the 802.1d Ethernet
Bridging and the bridge-utils package has been added. In
this way, it is possible to create a Linux bridge device
with two physical ports (Eth0 and Eth1) and the Time
Gateway thus also works as a software bridge (layer 2
device). In [5] the bridging was at layer 3, resulting in
very poor performance. However, the solution proposed,
although extremely flexible, is still not performing as a
dedicated hardware solution since the forwarding of the
packets is managed by the kernel in software. The device
may not be able to manage full bandwidth traffic,

although. This is not important in a proof-of-concept


demonstration.
In [5] was demonstrated that OS scheduling adds an
irregular and uncorrelated noise to the timestamp of the
received Sync messages leading to great synchronization
errors at the PTP side and, consequently, to the SNTP
side. For such a reason, a new filter applied to the
timestamp has been added in order to reduce this noise
and to improve the synchronization performance of the
system. The filtering stage of the standard PTPd has
been improved by introducing a median filter (10
samples) that operates on the received timestamps. The
effect of the proposed non-liner filtering is a great
improvement of the performance as sown in the
experimental section.
User Space

MSNTP
MSNTP
Client
Server

PTPd

System Calls Interface


adjTime

Clinux Kernel
TS

TS

System Time
802.1d Ethernet Bridge

Eth0

Device Drivers

Eth
PHY0
PTP

Eth1
Eth
PHY1

Other Messages

SNTP

Figure 3. Time Gateway firmware:


forwarding and timestamping mechanism.

4. Experimental validation and conclusions


The Time Gateway prototype is based on a NIOS II
development kit with an EP2S60F672C3 Stratix II
FPGA (60k LE). An external evaluation board
(DP83640T-EVK) carries the PTP-aware 10/100 Mbps
Ethernet PHY (DP83640 from National Semiconductor)
The complete prototype is shown in Figure 4. The Time
Gateway has limited hardware resources requests and
can be ported the system on low cost devices (such as
the Cyclone series of FPGAs). The synchronization
performance of the PTP-side of the Time Gateway has
been evaluated using the experimental set-up shown in
Figure 4b. The Master Clock is a Class B LXI device
(TriggerBox E5818A from Agilent) and it sends a sync
message every 2 s. The PTPd daemon on the Time
Gateway periodically corrects the local system time and
registers its time offset and its drift from the PTP Master
clock in a log file (PTPLog). In the experiment no
additional traffic was present in the network. The

synchronization has been monitored for 2 hours (3600


offset samples).
Time Gateway
(PTP -> SNTP)

(PTP Master)

Eth
10/100

Eth0

Offset (s)

Agilent LXI
Trigger Box

100

Eth1

a)

50
0
-50
2000

2500

PTPLog

In conclusion, the obtained results are acceptable for


many typical IEC 61850 applications and, in practice,
represent a significant improvement in synchronization
accuracy compared to a synchronization strategy based
on SNTP alone. Future investigations are aimed at
improving the synchronization performance by means of
a full-hardware timestamping unit in the Time Gateway.

3500

Offset (s)

10

Figure 4.
Time Gateway prototype and
experimental setup.
The time offset, i.e. the time difference between the
Master and Slave local Time, logged during the first
experiment with standard PTPd, is reported in Figure
5.a. In this case, the synchronization capabilities of the
Time Gateway are severely affected by the timestamping
uncertainty introduced by the OS. Again, it should be
noticed that the incoming sync messages in this
implementation are timestamped at kernel level. In
figure 5.b, the synchronization results obtained using the
improved PTPd are reported. Note that the adoption of
the median filtering stage improves the synchronization
accuracy approximately of one order of magnitude. The
synchronization jitter obtained using the improved PTPd
is 11 s, in accordance with other results reported in
literature for a software only PTP implementation [7][6],
but clearly inferior to results available using hardware
assisted implementations [8][9]. Last, a simple test case
in which the proposed Time Gateway propagates the
time information using the SNTP protocol, has been
realized. In this experimental setup, the SNTP Client
(SNTP version 4) is a PC that every 2 s asks for the time
and logs the time offset from the Time Gateway (SNTP
Server). During the experiment, the System Time of the
Time Gateway is synchronized to the PTP Master (the
LXI device described in the previous experiment), using
the PTPd daemon. Once again, the proposed
improvement in the PTPd increases the overall
performance: with standard PTPd, the SNTP client jitter
is approximately 1500 s, whereas with optimized PTPd
it is approximately 400 s, near to the SNTP Server
limit. As a matter of fact, the SNTP protocol does not
provide for a Follow_up message (as in the PTP case)
and it is prone to OS scheduling jitter.

3000

4000

Time (s)

To SNTP
Domain

b)

5
0
-5
-10
2000

2500

3000

Time (s)

3500

4000

Figure 5.
The time offset obtained using
normal (a) and improved (b) PTPd.
References
[1]
[2]
[3]

[4]

[5]

[6]

[7]

[8]

[9]

IEC Standard for Communication network and systems


in substations, IEC 61850, 2003.
IEEE PC37.238 D5.0; Draft Standard Profile for Use of
IEEE 1588 PTP in Power System Applications, 2010.
Thrybom, L.; Prytz, G.; , "QoS in switched Industrial
Ethernet," ETFA 2009. IEEE Conference on , vol., no.,
pp.1-8, 22-25 Sept. 2009.
P. Ferrari, A. Flammini, S. Rinaldi, E. Sisinni, "On the
Seamless Interconnection of IEEE 1588-Based Devices
Using a PROFINET IO Infrastructure", IEEE Trans. Ind.
Informatics, August, 2010, Vol. 6, N. 3, pp. 1551-3203.
P. Ferrari, A. Flammini, S. Rinaldi, G. Prytz, P.C. Juel,
Architecture of an Embedded Time Gateway between
PTP and SNTP, IEEE SIES 2011, 15-17 June 2011
P. Ferrari, A. Flammini, D. Marioli, A. Taroni, "IEEE
1588-Based Synchronization System for a Displacement
Sensor Network", IEEE Trans. Instr. and Meas., 2008,
Vol. 57, N. 2, pp. 254-260.
K. Correll, N. Barendt, and M. Branicky, "Design
considerations for software only implementations of the
IEEE 1588 precision time protocol", Proceedings of
Conference on IEEE 1588, Zurich, CH, Oct. 10-12, 2005.
Moreira, P.; Serrano, et al., "White rabbit: Subnanosecond timing distribution over ethernet,". ISPCS
2009. vol., no., pp.1-5, 12-16 Oct. 2009.
P. Ferrari, A. Flammini, D. Marioli, A. Taroni, "A
Distributed Instrument for Performance Analysis of RealTime Ethernet Networks", IEEE Trans. Ind. Informatics,
February, 2008, Vol. 4, N. 1, pp. 16-25.

You might also like