Time synchronization — vulnerability of digital substation?

In papers and presentations you can often meet statements like 'No time synchronization — no digital substation' or 'Loss of time synchronization leads to malfunction of protection and control (PAC) functions in digital substation'. Is it really true? Let's find out.

Sept. 6, 2019, 4:47 p.m. | 3398 Теквел Парк (SSLT)

First of all, it is required to identify which IEDs in digital substation require time synchronization and what are the exact requirements:

  • Time synchronization of non-conventional instrument transformers (NCITs) and stand-alone merging units (SAMUs). Time synchronization of these IEDs provides time coherence of sampled values. NCIT's and SAMUs do not require absolute time reference, it is enough for them to be synchronized to a common, relative time. UCA 61850-9-2LE makes a distinction between the accuracy of the source of synchronization, which is 1 µs, and the accuracy of the actual timestamping of the data, which is 4µs. IEC 61869-6 defines instrument transformer accuracy classes that comprise the whole measurement chain from the instrument transformer to the digital output of the Merging Unit, assuming that the clock synchronization applied to the MU has accuracy better than 1 µs.

  • Time synchronization of other IEDs in substation (excluding NCITs and SAMUs). These IEDs rely on absolute time. This time synchronization provides common time stamps, corresponding to the astronomic time in UTC standard for all signals, captured in digital substation. The required accuracy of the actual timestamping of the data in these IEDs depends on the application. For the general time stamping of the events it is usually 1 ms, phasor measurement units timestamps are synchronized to absolute time within a few microseconds and etc.

The latter absolute time synchronization is present in any modern substation with microprocessor-based IEDs and substation automation system, even if this substation does not involve IEC 61850-based solutions. And it does not in any way influences operation of protection and control (PAC) functions. The first type of time synchronization is specific only for IEC 61850 digital substations with NCITs and SAMUs and it has certain impacts on PAC functions. But those impacts are not as critical and dramatic as often presented in papers and presentations.

An example of the paper with warnings on PAC malfunctions in case of time synchronization failures

Before we dig into details we must outline several preconditions, which are usually met in digital substation:

  • PTP (Precision Time Protocol) time synchronization, operating over Ethernet network, is applied.
  • Time synchronization system includes both main and backup time servers.
  • Ethernet network, which carries time synchronization messages, is redundant.
  • Time synchronization system supports at least one of the global time sources (GPS/GLONASS).
  • Sampled Values messages, published by NCITs and SAMUs, include information on the time source used to assist sample value subscribers in determining whether sampled values are synchronized to each other (SmpSynch attribute).

Time synchronization failure scenarios

In a normal operating mode all NCITs and SAMUs are synchronized against global time source and against each other. In this case SmpSynch==Global. All IEDs, including PAC IEDs, receive synchronized sampled values and are ready to perform their functions.

Let's walk through time synchronization system possible failure scenarios:

  • Main time server failure. In this case backup time server becomes main one, NCITs and SAMUs continue to receive precise time synchronization and publish Sampled Values messages with SmpSynch==Global. PAC functions are fully functional.
  • Main and backup time servers failure. NCITs and SAMUs stop receiving precise time synchronization signals. They go into a holdover mode. For the duration of the holdover mode NCITs and SAMUs continue to send Sampled Values messages with SmpSynch==Global. After holdover timeout they start publishing Sampled Values messages with SmpSynch==None and PAC functions, which are sensitive to the phase angle difference between measurements from different NCITs/SAMUs, are automatically blocked (differential protections, distance protection with currents and voltages coming from different NCITs/SAMUs and etc.). This failure of time synchronization must not lead to PAC malfunction (false or spurious tripping) and this must be guaranteed by the vendor. All other PAC functions receiving Sampled Values from the single NCIT/SAMU must be ready to operate. The described failure must not lead to blocking of all PAC functions. As personnel returns time server (-s) to normal operating mode, previously blocked PAC become active again.
  • GPS/GLONASS connection failure (for both time servers). In this case time servers rely on their local clocks and still send time synchronization messages to all IEDs in the substation. These messages include information on time synchronization quality (including status of global clock connection). The failure to synchronize to GPS/GLONASS is identified by NCITs and SAMUs and they start publishing Sampled Values messages with SmpSynch==Local (or with unique identifier of the local area clock). If NCITs and SAMUs are synchronized against same local area clock, none of the PAC functions are blocked, they all remain active (besides such PAC functions which span over several substations - for example, line differential protection, with line protection IEDs located at different substations).

As it can be seen from the examples above the failure of time synchronization system (including failure of both time servers) does not lead to PAC malfunction. Let's not spread fake news :)

Tekvel Park identifies time synchronization failures

How to identify time synchronization system degradations and failures? In real life Tekvel engineers witnessed both time synchronization system failures and incorrect behaviour of IEDs in these cases. All of them have been identified by Tekvel Park IEC 61850 monitoring and diagnostics system.

Tekvel Park events log, indicating time synchronization system failures

Among these cases:

  • loss of global clock connection (GPS/GLONASS);
  • time server (-s) failure;
  • periodic change of SmpSynch attribute in Sampled Values messages as a result of NCIT/SAMU development drawback;
  • blocking of all PAC functions in NCIT/SAMU local time synchronization mode as a result of IED development drawback;
  • blocking of all PAC functions at loss of global/time synchronization in NCIT/SAMU as a result of IED development drawback;

All these failures are extremely hard to identify without IEC 61850 communications monitoring and diagnostics system. But it is quite important to know that you do not have such problems during FAT/SAT or in the process of operation. So arm yourself now!

Latest blog posts

Transmission of data structures in a GOOSE message
Transmission of data structures in a GOOSE message

GOOSE-messaging has been covered a lot in many technical papers and to add anything valuable to the subject is rather difficult. But we will try. And functional constrained data will help us with that.

Quality Assurance requirements and experiences for GOOSE/SV configuration

The paper describes our experiences in applying quality assurance principles during the off-line SCL engineering phase independent of the engineering tool or Excel files used. These principles include requirements for inspection, visualisation and detailed analysis of the configuration of the GOOSE and SV communication all directly from the SCL files. The results of these processes are presented in regards to optimised data flow, identification of unpublished or unsubscribed GOOSE/SV, restriction of use of generic Logical Nodes and generic signal names ensuring better overall performance and reliability.

Software Based Centralized Protection: commissioning experience
Software Based Centralized Protection: commissioning experience

In 2018 Tekvel signed several contracts to commission centralized protection system based on servers and independent software. In this article we would like to share our experience and discuss some of the problems, that might require special attention from utilities on the way to mass deployment of centralized PAC systems.