SmpSynch, holdover и судьба сложных защит на цифровой подстанции

В данной статье используются принятые в отечественной практике сокращения для устройства, формирующего поток SV:

• ПАС — преобразователь аналоговых сигналов (русскоязычный аналог англоязычного «merging unit»);
• ЦТ — цифровой трансформатор (тока или напряжения) с собственным цифровым выходом по IEC 61869-9.

Дальше для краткости пишем ПАС/ЦТ, подразумевая обобщённое устройство-источник SV-потока.

Под «сложными защитами» в статье понимаются защиты со следующими двумя одновременно выполняющимися признаками:

1. Защита получает несколько независимых SV-потоков от разных ПАС/ЦТ (например, отдельный ПАС для токов и отдельный ЦТ для напряжений; либо токи плеч от разных ПАС);
2. Алгоритм защиты сопоставляет векторы сигналов между этими потоками — то есть результат расчёта зависит от их взаимного временного и углового положения.

К таким защитам относятся, в частности, дистанционные, дифференциальные, направленные и др. Если же все необходимые сигналы (и токи, и напряжения) приходят от одного и того же ПАС/ЦТ, статус его внешней синхронизации на работу указанных защит не влияет — пункт 6.904.6 IEC 61869-9 на этот счёт высказывается прямо:

Оригинал: Regardless of whether the merging unit is synchronized to an external time source or not, all sampled values from the same merging unit shall be synchronized to each other.

Перевод: Независимо от того, синхронизирован ли ПАС/ЦТ с внешним источником времени или нет, все выборки одного и того же ПАС/ЦТ должны быть синхронизированы между собой. (IEC 61869-9, п. 6.904.6)

То есть проблема, которой посвящена эта статья, актуальна именно при «многопотоковой» архитектуре — когда защита собирает картину из выборок, формируемых разными физическими устройствами ПАС/ЦТ.

Постановка проблемы

Часто обсуждаются два связанных вопроса, которые регулярно возникают у проектировщиков и наладчиков РЗА. Перескажем их по существу:

• Сценарий 1. Все потоки SV шли с глобальной меткой синхронизации (SmpSynch=2). В какой-то момент один ПАС/ЦТ продолжает публиковать SmpSynch=2, а второй — переключился на SmpSynch=1. Можно ли в течение какого-то времени считать эти SV всё ещё синхронными между собой?
• Сценарий 2. К терминалу РЗА, реализующему «сложную защиту», приходят два потока SV: токи — с SmpSynch=2 (глобальная), напряжения — с SmpSynch=1 (локальная). Должна ли соответствующая защита блокироваться или какое-то время измерения ещё корректно совмещаются?

Ответ на оба вопроса прямо вытекает из раздела 6.904 стандарта IEC 61869-9 «Synchronization». Ниже разбираем его положения и сопоставляем их с распространёнными заблуждениями, которые встречаются в обсуждениях.

Как стандарт описывает SmpSynch

Атрибут SmpSynch присутствует в каждом ASDU SV-сообщения и сообщает подписчику, к какому источнику времени привязаны выборки. IEC 61869-9, п. 6.904.4 определяет четыре класса значений:

Ключевые предписания п. 6.904.4 в их исходной формулировке и в дословном переводе:

Оригинал: While sampled values are synchronized to a global area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be 2.

Перевод: Пока выборки синхронизированы с глобальными часами в той степени, которая требуется для соблюдения предельной фазовой погрешности класса точности измерений, значение атрибута «SmpSynch» в SV-сообщениях должно быть равно 2. (IEC 61869-9, п. 6.904.4)

Оригинал: All sampled values synchronized to any global area clock are synchronized to each other.

Перевод: Все выборки, синхронизированные с любыми глобальными часами, синхронны между собой. (IEC 61869-9, п. 6.904.4)

Оригинал: While sampled values are synchronized to a local area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be the unique identifier of the specific local area clock if known, or 1 if the identifier is not known.

Перевод: Пока выборки синхронизированы с локальными часами в той степени, которая требуется для соблюдения предельной фазовой погрешности класса точности измерений, значение атрибута «SmpSynch» в SV-сообщениях должно быть равно уникальному идентификатору соответствующих локальных часов, если он известен, либо 1, если идентификатор неизвестен. (IEC 61869-9, п. 6.904.4)

Оригинал: All sampled values synchronized to the same local area clock are synchronized to each other, but may not be synchronized to sampled values synchronized to some other clock.

Перевод: Все выборки, синхронизированные с одними и теми же локальными часами, синхронны между собой, но могут не быть синхронны с выборками, синхронизированными с другими часами. (IEC 61869-9, п. 6.904.4)

Оригинал: While sampled values are not synchronized to a global or local area clock to the degree required to meet the measuring accuracy class phase displacement limit, the value of the "SmpSynch" attribute in the SV messages shall be 0.

Перевод: Пока выборки не синхронизированы ни с глобальными, ни с локальными часами в степени, требуемой для соблюдения предельной фазовой погрешности класса точности измерений, значение атрибута «SmpSynch» в SV-сообщениях должно быть равно 0. (IEC 61869-9, п. 6.904.4)

Главный вывод из совокупности этих формулировок: одно лишь значение SmpSynch у отдельного потока не позволяет утверждать, синхронен ли он с каким-то другим потоком. Подписчик-сложная защита должен сравнивать пары значений между всеми потоками, которые подаются на её алгоритм (в частности ID часов при локальной синхронизации).

Holdover и популярное заблуждение

В обсуждениях часто звучит такая интерпретация: «после потери глобальной синхронизации флаг 2 какое-то время сохраняется, а затем переходит в 1». Это неверно. Стандарт описывает поведение иначе. Приведём п. 6.904.5 дословно:

Оригинал: When the external synchronization signal is lost, the merging unit shall go into a holdover mode. For the duration of the holdover mode the merging unit shall continue to send samples maintaining the sample timing required for the measuring accuracy class. During holdover, the "SmpSynch" attribute in the SV messages shall remain unchanged, and the "SmpCnt" attribute in the SV messages shall increment and wrap as if a synchronization signal were present.

Перевод: При потере внешнего сигнала синхронизации ПАС/ЦТ должен перейти в режим holdover. На протяжении режима holdover ПАС/ЦТ должен продолжать передавать выборки, обеспечивая точность их временных меток, требуемую классом точности измерений. На время holdover значение атрибута «SmpSynch» в SV-сообщениях должно оставаться неизменным, а атрибут «SmpCnt» — инкрементироваться и зацикливаться так, как если бы сигнал синхронизации присутствовал. (IEC 61869-9, п. 6.904.5)

Оригинал: The minimum holdover duration shall be 5 seconds under stable temperature conditions.

Перевод: Минимальная длительность режима holdover должна составлять 5 секунд при стабильных температурных условиях. (IEC 61869-9, п. 6.904.5)

То есть в течение holdover значение SmpSynch остаётся равным 2. По истечении holdover ПАС/ЦТ переходит в free-running (п. 6.904.6) и публикует SmpSynch=0, а не 1. Стандарт явно перечисляет причины SmpSynch=0:

• сигнал синхронизации никогда не приходил;
• сигнал синхронизации был прерван и ПАС/ЦТ работает дольше своего паспортного holdover;
• захват сигнала синхронизации не выполнен;
• точность семплирования не соответствует требуемой по классу.

На практике производители заявляют holdover в десятки секунд и часы — в зависимости от класса опорного генератора (TCXO, OCXO, рубидиевые). 5 секунд — это нормативный нижний предел.

Симметрия правила holdover

Формулировка «SmpSynch shall remain unchanged» намеренно сделана общей и не привязана к значению 2. Поэтому правило симметрично для любого исходного значения:

• было 2 (Global) → потеря сигнала → holdover с SmpSynch=2 → истёк holdover → SmpSynch=0;
• было 1 (Local без ID) → потеря сигнала → holdover с SmpSynch=1 → истёк holdover → SmpSynch=0;
• было 5–254 (Local с ID) → потеря сигнала → holdover с тем же ID → истёк holdover → SmpSynch=0.

Логика, которая за этим стоит: SmpSynch отражает, к какому классу источника ПАС/ЦТ был привязан и продолжает удерживать точность класса измерения за счёт собственного опорного генератора. В режиме holdover внутренний осциллятор «помнит» прежнюю привязку и поддерживает её ровно столько, сколько у него хватает стабильности.

Полная карта возможных переходов SmpSynch у одного ПАС/ЦТ:

stateDiagram-v2
    direction LR
    [*] --> S0: запуск без сигнала<br/>SmpSynch=0
    S0: SmpSynch = 0<br/>(не синхронизирован)
    S2: SmpSynch = 2<br/>(Global / traceable)
    S1: SmpSynch = 1 / 5–254<br/>(Local)
    HOLD2: holdover (значение 2 не меняется)<br/>длится T_h ≥ 5 c
    HOLD1: holdover (значение 1 не меняется)<br/>длится T_h ≥ 5 c

    S0 --> S2: появился traceable GM<br/>(timeTraceable=TRUE)
    S0 --> S1: появился non-traceable GM<br/>(timeTraceable=FALSE)

    S2 --> HOLD2: потеря PTP-сигнала
    HOLD2 --> S2: PTP восстановлен до T_h
    HOLD2 --> S0: T_h истёк

    S1 --> HOLD1: потеря PTP-сигнала
    HOLD1 --> S1: PTP восстановлен до T_h
    HOLD1 --> S0: T_h истёк

    S2 --> S1: GM перешёл в clockClass 52<br/>(timeTraceable: TRUE→FALSE)
    S1 --> S2: GM вернулся в clockClass 6/7<br/>(timeTraceable: FALSE→TRUE)

Рис. 1. Состояния и переходы атрибута SmpSynch у одного ПАС/ЦТ. Принципиальное наблюдение: 2 → 1 невозможен «изнутри» при holdover — он возникает только при смене статуса grandmaster-а.

Когда же тогда появляется SmpSynch=1?

Переход 2 → 1 действительно возможен, но это не следствие потери GPS у самого ПАС/ЦТ, а следствие изменения статуса того grandmaster-а PTP-домена (сервера времени), к которому ПАС/ЦТ подключён.

П. 6.904.2 IEC 61869-9 предписывает интерпретировать сигнал синхронизации, опираясь на флаг timeTraceable Power Profile-а:

Оригинал: A synchronizing signal received with the Power Profile timeTraceable flag TRUE shall be deemed to be sourced by a global area clock. A synchronizing signal received with the Power Profile timeTraceable flag FALSE shall be deemed to be sourced by a local area clock.

Перевод: Сигнал синхронизации, полученный с установленным в TRUE флагом timeTraceable профиля Power Profile, должен считаться поступающим от глобальных часов. Сигнал синхронизации, полученный с установленным в FALSE флагом timeTraceable профиля Power Profile, должен считаться поступающим от локальных часов. (IEC 61869-9, п. 6.904.2)

Соответствие со значением SmpSynch получается такое:

• сигнал с timeTraceable=TRUE → ПАС/ЦТ публикует SmpSynch=2;
• сигнал с timeTraceable=FALSE → ПАС/ЦТ публикует SmpSynch=1 (или 5–254, если в TLV GRANDMASTER_ID передан байт-идентификатор источника).

Когда у grandmaster-а пропадает GPS/ГЛОНАСС и он сам уходит в holdover, по правилам Power Profile через определённое время он начнёт выставлять timeTraceable=FALSE. С этого момента подключённые к нему ПАС/ЦТ перейдут на SmpSynch=1 — при этом физически между собой они продолжают оставаться синхронными, потому что получают время от одного и того же источника.

При наличии резервного grandmaster-а часть ПАС/ЦТ может остаться на «traceable»-grandmaster-е (SmpSynch=2), а часть — переключиться на «non-traceable» (SmpSynch=1). Между такими двумя группами синхронность уже не гарантируется.

Где передаются timeTraceable и clockClass

Оба значения — и timeTraceable, и clockClass — приходят к подписчику внутри одного и того же PTP-сообщения Announce. Это сообщение рассылает каждый grandmaster (Ordinary Clock) и каждый Boundary Clock; по Power Profile оно повторяется с частотой 1 раз в секунду. Помимо собственно метки времени Announce несёт сведения о качестве источника, которые BMCA (Best Master Clock Algorithm) использует для выбора лучшего grandmaster-а в домене, а ПАС/ЦТ — для формирования SmpSynch.

timeTraceable: бит в flagField

Флаг timeTraceable — это не отдельное сообщение, а один из битов поля flagField в заголовке сообщения Announce. Конкретное место — младший байт flagField, бит 4 (по IEEE 1588-2008/2019 обозначается как PTP_TIMETRACEABLE, битовая маска 0x10). В том же flagField рядом расположен флаг frequencyTraceable (маска 0x20) — он сообщает, прослеживается ли частотный эталон; по Power Profile его значение, как правило, совпадает с timeTraceable.

Значение timeTraceable выставляет сам grandmaster в соответствии со своим внутренним состоянием:

• он захвачен за внешним эталоном (например, GNSS) с требуемой Power Profile точностью → timeTraceable=TRUE;
• он находится в собственном holdover, и точность ещё в норме → timeTraceable обычно остаётся TRUE;
• точность вышла за нормативные пределы Power Profile → timeTraceable=FALSE.

clockClass: байт в grandmasterClockQuality

Атрибут clockClass передаётся в теле сообщения Announce, в составе структуры grandmasterClockQuality (по IEEE 1588-2008/2019, п. 13.5). Эта структура занимает 4 байта и содержит три поля:

• clockClass — 1 байт (UInteger8); собственно «класс качества» grandmaster-а, нас интересует именно он;
• clockAccuracy — 1 байт (Enumeration8); грубая оценка фактической точности (значения вроде «лучше 100 нс», «лучше 1 мкс» и т. п.);
• offsetScaledLogVariance — 2 байта (UInteger16); характеристика стабильности генератора.

Power Profile (IEC/IEEE 61850-9-3 и IEEE C37.238) использует только четыре нормативных значения clockClass:

• 6 — часы захвачены за PRC-эталоном (Primary Reference Clock; обычно GNSS), фактическая точность ≤ 250 нс;
• 7 — часы в holdover после ранее достигнутой связи с PRC, точность всё ещё в пределах профиля (≤ 250 нс относительно последней привязки);
• 52 — часы в holdover, точность ушла в диапазон 250 нс — 1 мкс;
• 187 — часы в holdover, точность хуже 1 мкс.

Меньшее значение clockClass соответствует более качественному источнику, и BMCA при прочих равных выбирает grandmaster-а с наименьшим clockClass.

Связь clockClass и timeTraceable

clockClass и timeTraceable — два независимых поля одного и того же сообщения Announce, поэтому теоретически grandmaster может выставлять их в любых сочетаниях. Но Power Profile нормативно связывает их между собой: timeTraceable=TRUE может выставляться только тогда, когда фактическая точность времени соответствует требованиям профиля по прослеживаемости. Отсюда стандартное соответствие, которым руководствуются и сами grandmaster-ы, и подписчики:

Табл. 1. Соответствие clockClass grandmaster-а, флага timeTraceable в Announce и значения SmpSynch у подписчика-ПАС/ЦТ по Power Profile (IEC/IEEE 61850-9-3 и IEEE C37.238).

Именно поэтому переход потока с SmpSynch=2 на SmpSynch=1 — это, по существу, индикатор перехода grandmaster-а в Announce из clockClass 6/7 в clockClass 52: timeTraceable падает в FALSE, и ПАС/ЦТ обязан соответственно поменять SmpSynch.

Что ещё передаётся в Announce и где это видно

Кроме timeTraceable и clockClass подписчик получает в Announce ещё одно важное для нас поле:

• GMID (Grandmaster ID) — передаётся как Power Profile TLV в сообщении Announce. Именно его младший байт по 6.904.2 IEC 61869-9 копируется в SmpSynch при значениях 5–254 — то есть локальный clock-ID, который видит сложная защита, физически приходит из этого TLV.

Подписчик-ПАС/ЦТ (а также любая защита, имеющая собственный PTP-стек) не пересылает эти поля наружу — он использует их внутренне для формирования SmpSynch. Поэтому при наладке цифровой подстанции цепочку «Announce → SmpSynch» удобно проверять стандартными PTP-анализаторами, способными разбирать содержимое Announce-сообщений побайтно (например, используя РС ВАПС ПТК «Теквел Парк»).

Итоговая причинно-следственная цепочка получается такая: «состояние grandmaster-а → его clockClass и timeTraceable в Announce → их интерпретация в PTP-стеке ПАС/ЦТ → SmpSynch в SV-сообщении → решение сложной защиты».

flowchart TB
    GM["Grandmaster<br/><i>состояние внутреннего осциллятора</i>"]
    ANN["Announce-сообщение PTP<br/>(1 раз/сек по Power Profile)"]
    FF["flagField · бит timeTraceable<br/>TRUE / FALSE"]
    CC["grandmasterClockQuality.clockClass<br/>6 · 7 · 52 · 187"]
    GMID["TLV GRANDMASTER_ID<br/>(IEEE C37.238)"]
    PTP["PTP-стек ПАС/ЦТ<br/>интерпретация Announce"]
    SV["SV-сообщение<br/>атрибут SmpSynch"]
    DEF["Сложная защита<br/>сравнение пар SmpSynch<br/>между всеми потоками"]
    DEC{"Все потоки<br/>взаимно синхронны?"}
    OK["Полная точность<br/>функция работает"]
    BLK["Блокировка / переход<br/>на резервный алгоритм"]

    GM --> ANN
    ANN --> FF
    ANN --> CC
    ANN --> GMID
    FF --> PTP
    CC --> PTP
    GMID --> PTP
    PTP --> SV
    SV --> DEF
    DEF --> DEC
    DEC -->|да| OK
    DEC -->|нет| BLK

    style GM fill:#e8f4fd,stroke:#4a90d9
    style ANN fill:#fff8e1,stroke:#e6a23c
    style PTP fill:#f3e5f5,stroke:#9c27b0
    style SV fill:#e8f5e9,stroke:#67c23a
    style DEF fill:#fde8e8,stroke:#f56c6c
    style OK fill:#e8f5e9,stroke:#67c23a
    style BLK fill:#fde8e8,stroke:#f56c6c

Рис. 2. Причинно-следственная цепочка от состояния grandmaster-а до решения сложной защиты. Каждое звено — отдельная точка отказа и отдельный объект тестирования.

Возврат к сценариям из обсуждения

Сценарий 1: один ПАС/ЦТ остался на 2, другой ушёл в 1

Формальный ответ стандарта: считать такие потоки взаимно синхронными нельзя. Подписчик не имеет средств узнать, действительно ли локальный источник второго ПАС/ЦТ физически совпадает с глобальным источником первого.

Физически такая ситуация чаще всего означает одно из двух:

• Оба ПАС/ЦТ «висят» на одном и том же grandmaster-е, который потерял GPS и теперь выставляет timeTraceable=FALSE. Тогда по факту оба потока остаются синхронны (общий источник), но и второй ПАС/ЦТ должен был тоже перейти в SmpSynch=1 — если этого не произошло, есть неисправность одного из устройств.
• ПАС/ЦТ подключены к разным grandmaster-ам, один из которых ещё имеет GPS, а другой — уже нет. Тогда между потоками появляется фазовый дрейф локального генератора, и точность их совмещения деградирует.

Поскольку подписчик не может различить эти два случая по контенту SV, безопаснее считать пару «2 + 1» несинхронной и выполнять блокировку сложной защиты.

Сценарий 2: токи SmpSynch=2, напряжения SmpSynch=1

Это типовая ситуация, при которой токи и напряжения формируются разными ПАС/ЦТ — то есть имеет место именно «многопотоковая» архитектура, для которой смысл вопроса о синхронизации актуален. Сложная защита (например, дистанционная) считает свои величины через векторное сопоставление тока и напряжения, и любая фазовая ошибка между ними напрямую попадает в результат.

Стандарт IEC 61869-9 не описывает поведение РЗА — он лишь даёт подписчику средство (атрибут SmpSynch) для принятия решения. Само же решение задаётся требованиями к функции защиты и логикой устройства РЗА. На практике принято следующее:

• если оба потока SmpSynch=2 — функция работает;
• если оба потока SmpSynch=N (одинаковый локальный ID 5–254) — функция работает;
• если один поток =2, другой =1, или ID локальных часов различаются, или хотя бы один =0 — сложные защиты блокируются.

Когда вопрос «совмещать или не совмещать» вообще не возникает

Если же сложная защита работает с потоком от единственного ПАС/ЦТ (то есть и токи, и напряжения формируются одним и тем же устройством), вопрос внешней синхронизации не стоит — по уже процитированному выше п. 6.904.6, выборки одного устройства всегда синхронны между собой, независимо от состояния его внешней синхронизации. Внешняя синхронизация в этом случае нужна только для «глобального» совмещения данных с другими подсистемами (например, синхрофазорами), но не влияет на работу самой функции защиты.

Что обязан делать ПАС/ЦТ при потере источника

Сводка требований 6.904.5–6.904.6 и тестов 7.2.902 IEC 61869-9:

• при потере внешней синхронизации ПАС/ЦТ обязан войти в holdover и продолжать выдавать SV с прежним SmpSynch и инкрементируемым SmpCnt, как если бы сигнал не пропадал;
• длительность holdover указывается в паспорте устройства (атрибут hold в PhyNam.d, см. п. 6.903.5); минимум — 5 с;
• по истечении holdover ПАС/ЦТ переходит в free-running, выставляет SmpSynch=0 и удерживает частоту дискретизации в пределах ±100 ppm от номинала;
• при возобновлении сигнала до истечения holdover поток продолжается «бесшовно»; при возобновлении после — стандарт допускает скачок SmpCnt и/или изменение SmpSynch в соседних ASDU, и подписчик должен это обнаруживать (NOTE 912 в п. 6.904.7).

Графически это выглядит так:

{
  "title": {
    "text": "Поведение ПАС/ЦТ при потере PTP-сигнала",
    "subtext": "SmpSynch и накопленная ошибка |Δt| · IEC 61869-9 пп. 6.904.5 / 7.2.902",
    "left": "center",
    "top": 8,
    "textStyle": { "fontSize": 14, "fontWeight": "bold" },
    "subtextStyle": { "fontSize": 11, "color": "#888" }
  },
  "tooltip": { "trigger": "axis" },
  "legend": {
    "bottom": 8,
    "itemGap": 24,
    "data": ["SmpSynch", "|Δt| / предел класса"]
  },
  "grid": { "left": 70, "right": 70, "top": 75, "bottom": 70 },
  "xAxis": {
    "type": "value",
    "name": "Время (в долях паспортного T_h)",
    "nameLocation": "middle",
    "nameGap": 32,
    "min": -0.4,
    "max": 1.6,
    "axisLabel": { "formatter": "{value}·T_h" },
    "splitLine": { "show": false }
  },
  "yAxis": [
    {
      "type": "value",
      "name": "SmpSynch",
      "nameLocation": "middle",
      "nameGap": 38,
      "nameRotate": 90,
      "nameTextStyle": { "color": "#409EFF", "fontWeight": "bold" },
      "min": -0.3,
      "max": 2.6,
      "interval": 1,
      "position": "left",
      "axisLabel": { "color": "#409EFF" },
      "splitLine": { "show": false }
    },
    {
      "type": "value",
      "name": "|Δt| / предел",
      "nameLocation": "middle",
      "nameGap": 40,
      "nameRotate": -90,
      "nameTextStyle": { "color": "#E6A23C", "fontWeight": "bold" },
      "min": 0,
      "max": 1.6,
      "position": "right",
      "axisLabel": { "color": "#E6A23C" },
      "splitLine": { "show": false }
    }
  ],
  "series": [
    {
      "name": "SmpSynch",
      "type": "line",
      "step": "end",
      "yAxisIndex": 0,
      "data": [[-0.4, 2], [0, 2], [0.95, 2], [0.95, 0], [1.6, 0]],
      "lineStyle": { "width": 4, "color": "#409EFF" },
      "symbol": "circle",
      "symbolSize": 8,
      "z": 10,
      "markLine": {
        "silent": true,
        "symbol": ["none", "none"],
        "label": { "show": false },
        "data": [
          {
            "xAxis": 0,
            "lineStyle": { "color": "#F56C6C", "type": "dashed", "width": 2 }
          },
          {
            "xAxis": 0.95,
            "lineStyle": { "color": "#F56C6C", "type": "dashed", "width": 2 }
          }
        ]
      },
      "markArea": {
        "silent": true,
        "label": {
          "fontSize": 12,
          "fontWeight": "bold",
          "color": "#555",
          "position": "insideTop",
          "distance": 6
        },
        "data": [
          [
            { "name": "Норма", "xAxis": -0.4, "itemStyle": { "color": "rgba(103,194,58,0.12)" } },
            { "xAxis": 0 }
          ],
          [
            { "name": "Holdover", "xAxis": 0, "itemStyle": { "color": "rgba(230,162,60,0.18)" } },
            { "xAxis": 0.95 }
          ],
          [
            { "name": "Free-running", "xAxis": 0.95, "itemStyle": { "color": "rgba(245,108,108,0.18)" } },
            { "xAxis": 1.6 }
          ]
        ]
      }
    },
    {
      "name": "|Δt| / предел класса",
      "type": "line",
      "smooth": true,
      "yAxisIndex": 1,
      "data": [
        [-0.4, 0.04], [0, 0.04], [0.15, 0.10], [0.30, 0.22],
        [0.50, 0.40], [0.70, 0.62], [0.85, 0.85], [0.95, 0.98],
        [1.10, 1.18], [1.30, 1.32], [1.6, 1.45]
      ],
      "lineStyle": { "width": 2, "color": "#E6A23C" },
      "areaStyle": { "color": "rgba(230,162,60,0.18)" },
      "showSymbol": false,
      "markLine": {
        "silent": true,
        "symbol": ["none", "none"],
        "data": [
          {
            "yAxis": 1,
            "lineStyle": { "color": "#909399", "type": "dotted", "width": 1.5 },
            "label": {
              "formatter": "предел класса точности",
              "position": "middle",
              "fontSize": 11,
              "fontWeight": "bold",
              "color": "#555",
              "backgroundColor": "rgba(255,255,255,0.9)",
              "borderColor": "#909399",
              "borderWidth": 1,
              "borderRadius": 3,
              "padding": [3, 8]
            }
          }
        ]
      }
    }
  ]
}

Рис. 3. Поведение SmpSynch и накопленной ошибки временной метки Δt при потере PTP-сигнала. Зелёная зона — нормальная работа, оранжевая — holdover (SmpSynch=2 неизменен, точность ещё в пределах класса), красная — free-running (SmpSynch=0). Принципиальный момент: SmpSynch переключается в 0 раньше, чем |Δt| фактически превысит предел класса точности (требование 7.2.902).

Как проверяют декларируемое значение holdover

Сама процедура подтверждения паспортной длительности holdover у ПАС/ЦТ описана в IEC 61869-9, п. 7.2.902 «Loss of synchronization tests» — это одно из обязательных типовых испытаний (type tests). Стандарт формулирует её предельно лаконично, поэтому имеет смысл привести её дословно:

Оригинал: Verify under worst-case conditions that on loss of synchronizing signal, the merging unit continues to send samples maintaining the sample timing required for the measuring accuracy class for the published duration of the holdover period. Verify that over this period, the SmpSynch attribute in the SV messages remains unchanged, and the SmpCnt attribute in the SV messages increments and wraps as if synchronization signal were present. Verify that before the sample timing fails to meet that required for the measuring accuracy class, the SmpSynch attribute changes to zero.

Перевод: Подтвердить в наихудших условиях, что при потере сигнала синхронизации ПАС/ЦТ продолжает передавать выборки, обеспечивая точность их временных меток, требуемую классом точности измерений, в течение декларируемой длительности holdover. Подтвердить, что в течение этого периода атрибут «SmpSynch» в SV-сообщениях остаётся неизменным, а атрибут «SmpCnt» инкрементируется и зацикливается так, как если бы сигнал синхронизации присутствовал. Подтвердить, что до того как точность временных меток перестанет соответствовать требуемой классом точности измерений, атрибут «SmpSynch» меняется в ноль. (IEC 61869-9, п. 7.2.902)

Из этой формулировки разворачиваются четыре утверждения, которые проверка должна подтвердить количественно: (1) точность временных меток выборок остаётся в пределах класса всё заявленное время holdover T_h; (2) на этом интервале SmpSynch не меняется; (3) SmpCnt инкрементируется без скачков и пропусков; (4) когда временна́я ошибка приближается к пределу класса, SmpSynch переключается ровно в 0 — раньше, чем точность реально вышла за норму.

Стенд для проверки

Идея стенда такая: подать на проверяемое устройство одновременно стабильный аналоговый сигнал и управляемый PTP, в момент t = 0 разорвать PTP, а SV-поток на выходе записать с привязкой ко внешнему эталону времени. Затем по записи провести post-processing — для каждого ASDU посчитать ошибку временной метки, сравнить с пределом класса точности и проверить значения SmpSynch и SmpCnt.

Рис. 4. Структура стенда для типового испытания holdover (IEC 61869-9, п. 7.2.902).

Из ключевых элементов:

• Эталон времени — Cs/Rb-источник или GNSS-disciplined oscillator со стабильностью на 1–2 порядка лучше, чем у проверяемого ПАС/ЦТ. Он остаётся источником истины и в момент, когда у DUT отнимают синхронизацию.
• Управляемый PTP-grandmaster, синхронизированный от того же эталона. Подаёт PTP Power Profile (IEC/IEEE 61850-9-3) на проверяемое устройство.
• Точка отключения PTP — коммутатор с ACL, программируемый фильтр или физический разрыв линии PTP. Важно: разрыв должен затрагивать только PTP, а не сам SV-канал DUT (иначе приём SV-потока тоже прервётся).
• Аналоговый источник — поверенный источник тока/напряжения.
• DUT — собственно ПАС/ЦТ с заявленным паспортным holdover T_h.
• SV-анализатор с аппаратным тайм-стемпингом, привязанный к эталону по PPS/10 МГц. Записывает каждый ASDU с метками времени приёма. Например, РС ВАПС ПТК «Теквел Парк» или сетевая карта с поддержкой PHC + Wireshark с диссектором PTPv2/SV (точность последнего варианта обычно ~50–100 нс).
• Post-processing — расчёт временной ошибки Δt = t_capture − (t_SmpCnt + t_d) для каждого ASDU и сравнение с пределом класса. Здесь t_d — паспортная задержка ПАС/ЦТ (атрибут «delay» в PhyNam.d, см. п. 6.903.5).

Сценарий проверки

Базовый сценарий по 7.2.902 укладывается в четыре шага:

• Шаг 1. Стабилизация. На DUT подаются синхронизация и аналоговый сигнал. Дождаться захвата (Lock), убедиться, что SV-поток имеет правильное значение SmpSynch (как правило, 2 для проверки сценария «Global») и Δt укладывается в норму класса точности.
• Шаг 2. Обрыв PTP. В момент t = 0 на «точке отключения» разрываем PTP. Аналоговый сигнал и сам SV-канал не трогаем. Фиксируем точное время обрыва по эталону.
• Шаг 3. Запись потока. Захватываем SV-поток в течение времени ≥ T_h + запас (обычно T_h × 1,5). Параллельно лог-эталон сохраняет PPS-метки, чтобы каждой записи можно было приписать абсолютное время приёма.
• Шаг 4. Анализ. По записи проверяются четыре критерия из 7.2.902: |Δt(t)| ≤ предел класса для всех t ≤ T_h; SmpSynch неизменен на [0, T_h]; SmpCnt без скачков; SmpSynch переключается в 0 раньше, чем |Δt| превысит предел класса.

Дополнительно бывает полезно проверить, как ведёт себя устройство при возобновлении сигнала: до истечения holdover поток должен продолжаться «бесшовно», после — допускается скачок SmpCnt и/или изменение SmpSynch в соседних ASDU (NOTE 912 п. 6.904.7), и тогда подписчик обязан это обнаруживать.

Что считается «наихудшими условиями»

Пункт 7.2.902 обязывает проводить проверку при наихудших условиях. На практике под этим понимается совокупность факторов, ускоряющих дрейф внутреннего генератора:

• работа на границах рабочего температурного диапазона DUT (обычно проверяется в термокамере на нижней и верхней границах);
• предварительный «прогон» устройства при пограничной температуре, чтобы исключить начальный самопрогрев;
• при необходимости — проверка с воздействием по ЭМС (см. соответствующие пункты IEC 61869-9 в части ЭМС-тестов).

Если паспортный T_h объявлен только для «стабильной температуры» (формулировка, прямо разрешённая п. 6.904.5), термокамера не обязательна, но условия её отсутствия должны быть зафиксированы в протоколе.

Что обычно происходит на практике

Полный цикл проверки holdover — это длительное испытание (для T_h в десятки минут или часы реальное время теста сопоставимо), и в полной мере его проводят в аккредитованных лабораториях (KEMA/DNV, VDE, KERI и т. п.) при сертификации устройства; результат фиксируется в соответствующих сертификатах типа. На приёмо-сдаточных и наладочных проверках цифровой подстанции, как правило, ограничиваются «короткой» версией: PTP отключают на 5–10 секунд и убеждаются, что в это время SV-поток продолжается, SmpSynch не меняется, SmpCnt идёт без скачков. Это подтверждает работоспособность механизма holdover, но не его длительность.

Длительная проверка (на полное T_h) имеет смысл закладывать в техническое задание для опытных образцов, при выходе нового поколения устройств, а также при экспертизе после инцидентов, когда есть подозрение в реальном поведении holdover. Заметим также, что у самого PTP-grandmaster-а есть свой собственный holdover, и его подтверждают аналогичной методикой, описанной в IEC/IEEE 61850-9-3.

Что говорит IEC 61850-9-3 и PTP Power Profile

IEC 61869-9 описывает поведение ПАС/ЦТ и значения SmpSynch, но за качеством самой сети синхронизации стоит другая пара стандартов: IEC/IEEE 61850-9-3 (Power Profile для PTP) и IEEE C37.238. Связку между ними важно держать в голове, иначе атрибут SmpSynch воспринимается как «вещь в себе».

Power Profile задаёт у grandmaster-а атрибут clockClass (передаётся в Announce, см. предыдущий раздел) и его типовые значения для энергетики:

• clockClass = 6 — часы захвачены за внешним эталоном (как правило, GNSS), точность ≤ 250 нс. Подписчики получают сигнал с timeTraceable=TRUE → ПАС/ЦТ публикует SmpSynch=2.
• clockClass = 7 — часы в holdover после ранее захваченного эталона, точность по-прежнему ≤ 250 нс. timeTraceable обычно остаётся TRUE; SmpSynch у ПАС/ЦТ остаётся 2.
• clockClass = 52 — holdover, точность ухудшилась до диапазона 250 нс — 1 мкс. timeTraceable=FALSE; ПАС/ЦТ перейдёт на SmpSynch=1 (или 5–254, если в TLV передан GRANDMASTER_ID).
• clockClass = 187 — holdover, точность хуже 1 мкс. SV-поток с такой синхронизацией уже не соответствует классу измерительного канала и должен публиковаться с SmpSynch=0.

Иными словами, переход SmpSynch 2 → 1 (а не 2 → 0) у потока — это не «ПАС/ЦТ потерял сигнал», а «grandmaster перешёл из clockClass 7 в clockClass 52». Если grandmaster теряет внутренний осциллятор настолько, что попадает в clockClass 187, у ПАС/ЦТ включается уже собственный holdover, и SmpSynch=0 появляется по логике, описанной в разделе про обязанности ПАС/ЦТ.

Отсюда — типовые рекомендации, которые можно сформулировать:

• Дублирование grandmaster с собственными приёмниками GNSS и согласованной BMCA (Best Master Clock Algorithm). Отказ одного приёмника или одного устройства не должен переводить домен в clockClass 52.
• Boundary clocks в каждом здании ОПУ/КРУЭ. При нарушении связи между зданиями привязка времени локально сохраняется, и у ПАС/ЦТ не происходит переключений SmpSynch.
• Однородная конфигурация PTP-профиля: номера доменов, механизм задержки (E2E/P2P), частоты Sync/Announce, приоритеты BMCA, поведение в holdover должны быть согласованы у grandmaster-ов, коммутаторов с поддержкой PTP, ПАС/ЦТ и устройств защиты.
• Закладывать запас по holdover: устройства с термостатированными OCXO держат clockClass 7 десятки минут, устройства с Rb — часы. Это критично для энергообъектов с возможной потерей GNSS целиком на стороне подстанции.
• Тестировать переходы — не только потери сигнала у ПАС/ЦТ (тест 7.2.902 IEC 61869-9), но и переходы grandmaster-а 6 → 7 → 52 → 187 — на стороне подписчика проверяется логика реакции на 2 → 1 → 0 и на скачки SmpCnt.

Практические рекомендации для проектирования и наладки

• Сравнивать пары SmpSynch, а не отдельные значения. Подписчик-сложная защита должен проверять: совпали ли источники у всех потоков, участвующих в её алгоритме.
• Закладывать запас по holdover. Минимальные 5 с по стандарту — это паспортный нижний предел. Для обеспечения устойчивости защит при кратковременных сбоях PTP/1PPS целесообразно выбирать ПАС/ЦТ и grandmaster с holdover на десятки минут.
• Резервировать источник времени. Дублировать grandmaster с собственными приёмниками GPS/ГЛОНАСС.
• Стремиться к одному источнику для каждой защиты. Там, где это возможно по топологии, токи и напряжения, участвующие в одной сложной защите, выгодно собирать с одного ПАС/ЦТ — тогда вопрос совмещения SmpSynch вообще не стоит.
• Однородная конфигурация PTP-профиля: номера доменов, механизм задержки (E2E/P2P), частоты Sync/Announce, приоритеты BMCA, поведение в holdover должны быть согласованы у grandmaster-ов, коммутаторов с поддержкой PTP, ПАС/ЦТ и устройств защиты.
• Boundary clocks в каждом здании ОПУ/КРУЭ. При нарушении связи между зданиями привязка времени локально сохраняется, и у ПАС/ЦТ не происходит переключений SmpSynch.
• Тестировать переходы. Тест 7.2.902 IEC 61869-9 — это требование к ПАС/ЦТ; на стороне подписчика нужно проверять собственную логику реакции на 2→0, 2→1, изменения SmpCnt-разрыва, а на сети — переходы grandmaster-а 6 → 7 → 52 → 187.

Заключение

Картина «2 → 1 → 0», которая иногда формулируется в обсуждениях, упрощает реальное поведение ПАС/ЦТ и приводит к неверным выводам. Стандарт IEC 61869-9 описывает другой переход: «2 → (holdover, SmpSynch остаётся 2) → 0», а значение 1 появляется в другом сценарии — когда меняется статус самого grandmaster-а, что физически передаётся флагом timeTraceable в Announce-сообщениях PTP-домена.

Для подписчика-сложной защиты это означает простое правило: пара «SmpSynch=2 и SmpSynch=1» в общем случае не считается синхронной, и при такой комбинации защиты, использующие межпотоковое сопоставление, должны блокироваться.

И, наконец, важная архитектурная мысль: вопрос «считать ли ещё синхронными» вообще не возникает там, где сложная защита получает сигналы от единственного ПАС/ЦТ. Поэтому при проектировании цифровой подстанции имеет смысл смотреть не только на саму систему синхронизации, но и на распределение функций между ПАС/ЦТ — чем меньше зависимостей в одной защите, тем меньше у неё точек отказа, связанных с состоянием SmpSynch.