PTP and Process Bus - A "time" to fail?

The Precision Time Protocol (PTP) is a method used to synchronize clocks through a network. The protocol was initially defined by the IEEE-1588 2002, and the latest active version is the IEEE-1588 2008. The hierarchical master-slave PTP architecture is design to calculate the path delay through different nodes of the network and dynamic compensate the time distribution information. That feature allows PTP to achieve sub-microsecond accuracy what becomes attractive for power system applications like Synchrophasors (IEEE C37-118) and Sampled Values (IEC 61850-9-2). When PTP is applied together with Sampled Values technologies, some corner-cases and situations needs to be predictive and tested to avoid misoperations and failures in the system. This article talks about those cases and shows some results from the Brazilian 2019 Process Bus Interoperability workshop.

To avoid different implementations, PTP profiles are defined. IEEE C37.238-2011 "Power Profile" and the new IEC 61850-9-3 are chosen for power system applications. That standard profiles define some characteristic of the PTP message, like the delay measurement mechanism, the communication layer, transmission mechanism, and among other things. For example, the PTP "Power Profile" defines a Peer-to-Peer delay measurement, and layer 2 encapsulation using a multicast transmission. The PTP profiles customize the classes values for each clock state, and there are four relevant classes useful for the power system application, as defined in IEC 61850-9-3.

• Clock Class 6 - Clock is locked to a reference signal and accuracy < 250 ns.
• Clock Class 7 - Clock is in holdover mode and accuracy < 250 ns to a previous time reference.
• Clock Class 52 - Clock is in holdover mode and 250 ns < accuracy < 1 us to a previous time reference.
• Clock Class 187 - Clock is in holdover mode and accuracy > 1 us.

The clock class is mapped to the Samped Values protocol through the SmpSynch field information. When the device (publisher or subscriber) is synchronized to a high accuracy global source, the SmpSynch = 2. When the device is not synchronized to an external reference (local time) the SmpSynch = 1 or the GMID (Grandmaster Clock ID) value, and that depends on the PTP profile in use. If the device is running in a freewheeling mode (no synchronization) the SmpSynch = 0. However, there is no clear rule that defines how the relay or the merging unit (MU) should drive this information based on the clock class information and accuracy. That could lead to awkward situations when different IED manufacturers are used in the Process Bus application. Take the example shown in the figure below.

The MU-A is gathering voltage information from the bus bar and publishing the data through sampled values to the Relay. The MU-B is gathering current and contact information from the breaker and sending over Sampled Values and GOOSE messages. The MU-B and the relay are from the same manufacturer, and the MU-A is from another vendor. When the PTP clock is connected to an external GNSS source, the Clock Class = 6, and the MU-A, MU-B, and the relay reported a SmpSynch = 2, and the relay subscribe both streams without any issue. However, when the antenna is lost the PTP clock switch for his local mode and starts to send local time. The MU-A begins to send SV stream with SmpSynch = 1, the MU-B begins to send SV stream with SmpSynch = GMID = 50, and the relay declares a SmpSynch mismatch for the SV-A and starts to drop the voltage signal and blocks the breaker protection. The picture below shows a result from the Brazilian 2019 Process Bus Interoperability workshop. The results clearly show that for the lost of the antenna situation, clock class = 187 and disconnected, each manufacturer reacts differently and could be an issue when applied different vendors for the process bus application.

The PTP is an excellent fit for time synchronization in digital substations, PTP has a sub-microsecond time accuracy, and it is path delay safe. When applied in conjunction with sampled values, they can share the same network infrastructure to synchronize the relays and merging units, and publishing the sampled value data. However, some cases needed to be tested before deploying this solution into the fields. This article shows an excellent example of how a bad time synchronization situation can injure a critical protection application.

I hope that you enjoyed the reading, and of course, let me know what do you think about it.