Привет, Хабр! Представим, что перед нами такой сложный объект для управления, как электроэнергетическая система России. Чтобы рассматривать ее в виде единого целого, нужны высокоточные измерения из различных точек энергосистемы, зачастую географически удаленных друг от друга. Для решения этой задачи был создан стандарт IEEE C37.118. Он описывает так называемые синхрофазоры, или синхронизированные векторные измерения (СВИ).
В этой статье мы обсудим следующие вопросы:
Что такое СВИ и зачем они нужны;
Подробно разберем типы и форматы сообщений;
Рассмотрим, как передаются сообщения внутри стека TCP/IP;
Смоделируем пакеты С37.118 с помощью КПМ РИТМ и PMU Connection Tester.
Что такое СВИ и зачем они нужны
Для решения задач СМПР (система мониторинга переходных режимов), ЦСПА (централизованная система противоаварийной автоматики) и оперативно-диспетчерского управления требуются высокоточные измерения параметров электрического режима в различных точках энергосистемы, синхронизированные по времени с глобальными спутниковыми навигационными системами и передаваемые с высокой частотой 50 и более кадров в секунду.
В самом стандарте IEEE C37.118 говорится, что данные, измеренные в один и тот же момент времени относительно какого-то опорного сигнала, единого для всех точек измерения, называются СВИ. Опорным сигналом в данном случае является косинусоида, привязанная к UTC, на частоте системы 50 Гц.
В энергетике для измерения и передачи СВИ применяют специальные устройства, соединенные в сеть. Устройства измерения располагаются на объектах энергетики, а данные передаются в специальные концентраторы в диспетчерские центры. Простая сеть, основанная на СВИ, представлена на рисунке ниже.
Эти устройства имеют специальные названия УСВИ и КСВД.
УСВИ (PMU) – это устройства синхронизированных векторных измерений (phasor measurement unit), которые осуществляют измерение и передачу СВИ.
КСВД (PDC) – это концентратор синхронизированных векторных данных, (phasor data concentrator) который осуществляет сбор, хранение и передачу СВИ.
Как правило, на отдельно взятом объекте электроэнергетики имеются несколько УСВИ, данные от которых агрегируются в локальном КСВД, который располагается на том же объекте. Уже от него данные отправляются в КСВД вышестоящего уровня и т.д.
Стандарт IEEE C37.118 помимо определения синхронизированного вектора описывает требования к устройствам синхронизированных векторных измерений, формат сообщений СВИ и правила обмена этими сообщениями между устройствами.
Согласно стандарту, УСВИ измеряет синхронизированный вектор, частоту и скорость изменения частоты энергосистемы. Кроме того, устройство должно иметь возможность получать точное время от глобальных спутниковых навигационных систем.
Также они должны поддерживать передачу данных на частоте, кратной номинальной частоте энергосистемы. Конечный выбор частоты передачи определяет пользователь с учетом вышеуказанного условия.
Таблица 1. Требования к частоте передачи данных.
Частота сети | 50 Гц | 60 Гц | |||||||
Частота передачи данных, кадр/c | 10 | 25 | 50 | 10 | 12 | 15 | 20 | 30 | 60 |
Допускаются также частоты выше или ниже указанных в таблице.
Необходимо отметить, что время передачи кадров должно быть равномерно распределено в течение секунды, причем время отправки первого кадра должно совпадать с переходом через секунду по UTC.
Теперь давайте рассмотрим, какие бывают типы и форматы сообщений, а также режимы передачи этих сообщений.
Типы сообщений С37.118
Стандарт C37.118 определяет 4 типа кадров: data, configuration, header, command.
Для начала стоит отметить, что все кадры имеют общую структуру, представленную слева.
Подробнее про поля, характерные для всех типов кадров
SYNC длиной 2 байта состоит из байта синхронизации и байта, определяющего тип кадра и номер версии:
Бит 7: зарезервирован, должен быть 0
Биты 6-4:
000: Кадр данных
001: Кадр заголовка
010: Кадр конфигурации (CFG-1)
011: Кадр конфигурации (CFG-2)
101: Кадр конфигурации (CFG-3)
100: Кадр команды
Биты 3-0:
0001: Версия кадров IEEE Std C37.118-2005
0010: Версия кадров IEEE Std C37.118.2-2011
FRAMESIZE содержит значение количества байт в кадре, включая CHK
IDCODE – это идентификационный номер потока данных. Для кадров типа Command он задает целевой поток данных, а для других типов сообщений определяет исходящий поток данных.
SOC (second-of-century) содержит целое число секунд от начала эпохи UNIX
FRACSEC (fraction-of-second) длиной 4 байта, включает в себя 24-битное целое число доли секунды и 8-битный флаг качества времени
CMD, Header, Data, CFG – байты характерные своему типу кадра
CHK (check word) длиной 2 байта служит для контроля целостности данных.
Стоит немного пояснить про метку времени, передаваемую полями SOC и FRACSEC. Фактически время определяется следующим способом:
В формуле TIME_BASE – это, по сути, число, которое определяет точность метки времени. На сколько долей делится секунда. И в ту или иную часть секунды будет отправляться кадр в зависимости от выбранной частоты отправки кадров данных.
Например, если TIME_BASE = 1 000 000, то одной долей секунды будет являться 1 микросекунда, т.е. значение FRACSEC будет передано с точностью до одной микросекунды. Если TIME_BASE = 1 000, то одной долей секунды является 1 миллисекунда и значение FRACSEC будет передано с точностью до одной миллисекунды. Значение TIME_BASE передается в файле конфигурации.
А теперь рассмотрим каждый из типов кадров отдельно.
Кадры данных
Кадр данных, он же data frame — это измерения, выполненные УСВИ. Он имеет следующий формат:
Подробный разбор полей кадра данных
Для начала, вот как эти поля выглядят в WireShark:
Что означают поля Sync, FRAMESIZE, IDCODE, SOC, FRACSEC и CHK, мы уже рассмотрели.
STAT длиной 2 байта представляет собой набор битовых флагов. Для наглядности снова скриншот из захваченного пакета:
Биты 15-14 – индикатор ошибки данных:
00 – хорошие данные, ошибок нет;
01 – ошибка УСВИ, нет информации о данных;
10 – УСВИ в тестовом режиме или были вставлены отсутствующие теги данных(данные не использовать);
11 – ошибка УСВИ (данные не использовать);
Бит 13 – бит ошибки синхронизации: 0 – если есть синхронизация с источником точного времени, 1 – если нет синхронизации
Бит 12 – бит сортировки данных: 0 по отметке времени, 1 по прибытию;
Бит 11 – бит срабатывания УСВИ: устанавливается для указания на то, что для УСВИ, обладающих возможность срабатывания, обнаружено условие срабатывания. Бит устанавливает в 1 на заданное пользователем время.
Бит 10 – служит для оповещения получателя об изменении конфигурации УСВИ. Бит должен установиться в 1, чтобы указать, что конфигурация УСВИ изменится через 1 минуту, и приёмной стороне следует запросить файл конфигурации через 1 минуту. Бит должен быть сброшен на 0 по истечении минуты, и новая конфигурация должна вступить в силу с первым кадром с битом 10 равным 0.
Бит 9 – индикатор изменения данных: 1 в случае изменения данных постобработкой, 0 в противном случае.
Биты 6-8 – максимальная расчетная ошибка времени УСВИ:
111 – time error > 10 мс или ошибка времени неизвестна;
110 - time error < 10 мс;
101 - time error < 1 мс;
100 - time error < 100 мкс;
011 - time error < 10 мс;
010 - time error < 1 мкс;
001 - time error < 100 нс;
000 – не используется
Биты 5-4 – указывают интервал в секундах с момента потери синхронизации времени:
00 – потери синхронизации нет или она меньше 10 с (наилучшее качество);
01 – 10 с ≤ время потери синхронизации < 100 с;
10 - 100 с ≤ время потери синхронизации ≤ 1000 с;
11 – время потери синхронизации больше 1000 с;
Биты 0-3 – Причина срабатывания:
0111 – цифровой;
0101 – высокая скорость изменения частоты
0011 - разница фазовых углов
0001 – низкая амплитуда
0010 – высокая амплитуда
0100 – высокая или низкая частота
0110 – зарезервировано
PHASORS длиной либо 4 байта в случае использования 16-битного целого числа, либо 8 байт в случае использования 32-битного числа с плавающей точкой несет в себе значение амплитуды и угла передаваемого вектора, либо это действительная и мнимая часть комплексного числа. Формат представления векторных измерений определяется в поле FORMAT кадра конфигурации.
FREQ длиной 2/4 байта по аналогии с PHASORS определяет отклонение частоты от номинальной в мГц.
DFREQ длиной 2/4 байта представляет собой скорость изменения частоты(ROCOF) выраженную в 100*(Гц/c).
ANALOG длиной 2/4 байта может представлять собой какие-либо выборочные данные, определенные пользователем (например, значения температурного датчика).
DIGITAL длиной 2 байта отображает цифровые данные, обычно представляющие 16 цифровых точек состояния (каналов). Если выразиться чуть иначе, то поле содержит одно цифровое слово длиной 16 бит, внутри которого 16 цифровых каналов.
Кадры конфигурации
Следующий на очереди – кадр конфигурации. Он несет в себе информацию о потоке данных СВИ, необходимую приёмнику (например, КСВД) для его обработки.
Стандарт определяет три типа кадров конфигурации (CFG-1, CFG-2 и CFG-3), каждый из которых идентифицируется 4-6 битами SYNC.
CFG-1 и CFG-2 введены версией стандарта 2005 года, а CFG-3 – с версией 2011 года.
CFG-1 и CFG-2 имеют абсолютно идентичные поля, отличаются они назначением. CFG-1 используется для обозначения возможностей УСВИ/КСВД, указывая данные, которые способен передавать УСВИ/КСВД, а в CFG-2 передается информация о текущих измерениях, передаваемых в фрейме данных.
CFG-3 аналогичен CFG-1 и CFG-2 и содержит большую часть тех же данных, но с дополнительной информацией и полями переменной длины, в отличие от кадров конфигурации версии 2005 года, где все поля фиксированной длины. Необходимо заметить, что CFG-3 является опциональным, т.е. устройству не обязательно поддерживать данный формат файла конфигурации для соответствия стандарту.
Формат кадров конфигурации типа CFG-1 и CFG-2 представлен в таблице ниже:
Подробный разбор полей кадров конфигурации CFG-1, CFG-2
Формат CFG-1, CFG-2 кадров
Снова начнем разбор со скриншота из WireShark:
Определение TIME_BASE длиной 4 байта дано выше, а здесь стоит сказать только то, что старшие 8 бит зарезервированы, а биты 23-0 хранят в себе значение, на котором основан расчет FRACSEC.
NUM_PMU длиной 2 байта служит для указания количества УСВИ включенных во фрейм.
STN длиной 16 байт идентифицирует имя станции.
IDCODE длиной 2 байта в кадре конфигурации встречается как минимум два раза, как вы могли заметить. В первом варианте он идентифицирует сам поток данных (STREAM SOURCE ID), а во втором –- исходный источник данных (DATA SOURCE ID), который связан с конкретным УСВИ. В случае, когда источником кадра конфигурации является сам УСВИ, IDCODE будут одинаковыми.
FORMAT длиной 2 байта определяет формат данных в Data Frame:
Биты 15-4: не используются;
Бит 3: определяет тип данных полей FREQ/DFREQ 0 –- INT16, 1 – FLOAT32;
Бит 2: определяет тип данных поля ANALOG 0 –- INT16, 1 – FLOAT32;
Бит 1: определяет тип данных поля PHASORS 0 –- INT16, 1 – FLOAT32
Бит 0: определяет форму представления вектора 0 – алгебраическая(rectangular), 1 – полярная(polar)
PHNMR длиной 2 байта указывает количество векторов, передаваемых в кадре с данными.
ANNMR то же самое, что и PHNMR, только для сигналов в поле ANALOG.
DGNMR длиной 2 байта указывает количество двухбайтовых цифровых слов поля DIGITAL.
CHNAM представляет собой набор имен для каждого элемента полей PHASOR, ANALOG, DIGITAL, количество которых указано в полях выше. Длина каждого имени данных равна 16 байтам. Для поля DIGITAL имя указывается для каждого цифрового канала в цифровом слове.
PHUNIT содержит коэффициент приведения (длиной 4 байта) для каждого вектора поля PHASORS в случае, если используется тип данных INT16. В случае, если значения векторов передаются в формате FLOAT32, это поле просто игнорируется.
Старший байт имеет значение 0 для вектора напряжения, 1 – для вектора тока. Оставшиеся 24 бита представляют собой беззнаковое целое число, умноженное на 10-5.
ANUNIT содержит коэффициент приведения (длиной 4 байта) для каждого сигнала поля ANALOG. Старший байт принимает следующие значения:
0 – мгновенное значение сигнала;
1 – действующее значение;
2 – амплитудное значение;
5-64 – зарезервировано;
65-255 – доступно для определений пользователем.
Оставшиеся 24 бита содержат коэффициент масштабирования, определенный пользователем.
DIGUNIT представляет собой две битовых маски длиной по 2 байта для каждого цифрового слова DIGITAL. Первая битовая маска служит для указания нормального состояния цифровых каналов, вторая – для определения актуальных используемых битов.
FNOM – номинальная частота сети:
Биты 15-1: зарезервированы
Бит 0: 1 – 50 Гц, 0 – 60 Гц
CFGCNT длиной 2 байта показывает количество изменений в конфигурации этого потока данных.
DATA_RATE представляет собой число типа INT16 и определяет частоту отправки кадров данных. Если УСВИ/КСВД отправляет один или больше кадров в секунду, то data_rate > 0, если меньше, то указывается количество секунд на 1 кадр со знаком минус, например data_rate = 15 – это 15 кадров в секунду, а data_rate = −5 – это 1 кадр в 5 секунд.
А теперь взглянем на формат кадра конфигурации CFG-3
Подробный разбор полей кадра конфигурации CFG-3
CONT_IDX длиной 2 байта указывает текущий номер фрагмента сегментированного на уровне приложения кадра в случае, если размер CFG-3 превышает 65535 байт. Значение 0 – сегментирование отсутствует, 1 – сегмент из серии, ждите следующие, 2-65534 – n-й номер сегмента, 65535 – последний сегмент из серии.
STN в CFG-3 имеет переменный размер, следовательно, первый байт имеет формат UINT8 и используется для указания длины имени станции, а последующие байты, соответственно, задают имя станции.
G_PMU_ID – 16-байтный глобальный идентификационный номер УСВИ.
CHNAM в CFG-3 содержит наименования для каждого элемента PHASORS, ANALOG и DIGITAL. Отличие от CFG-1 и CFG-2 аналогично отличию в поле STN, каждое имя имеет переменную длину от 1 до 255 байт, и первый байт используется для указания длины имени, затем следует само имя в ASCII-формате.
PHSCALE длиной 12 байт для каждого вектора поля PHASORS имеет такое же назначение, как и PHSUNIT в CFG-1, CFG-2, но несет в себе немного больше информации и состоит из трех четырехбайтовых слов.
Первые два байта – это битовые флаги, указывающие на тип модификации данных:
Третий байт указывает на тип вектора:
Биты 7-4: зарезервированы;
Бит 3: 0 – напряжение, 1 – ток;
Биты 2-0:
111 – зарезервировано;
110 – фаза С;
101 – фаза B;
100 – фаза А;
011 – зарезервировано;
010 – обратная последовательность;
001 – прямая последовательность;
000 – нулевая последовательность
Четвертый байт доступен для пользовательских определений.
Второе и третье четырехбайтные слова содержат коэффициенты приведения по амплитуде Y или углу θ, применяемые к вектору следующим образом:
Коэффициенты имеют тип данных FLOAT32.
ANSCALE длиной 8 байт содержит в себе коэффициенты М и B к сигналам поля ANALOG, применяемые следующим образом:
передаются в формате FLOAT32.
PMU_LAT, PMU_LON и PMU_ELEV длиной 4 байта каждый несут в себе информацию о географическом местоположении УСВИ (широта, долгота и высота на уровнем моря). Тип данных – FLOAT32.
SVC_CLASS длиной 1 байт содержит один из двух ASCII символов – M или P, описанные в стандарте C37.118.1-2011, которые определяют класс производительности PMU. Данные от УСВИ с классом P (protection) предназначены для приложений, требующих быстрой доставки данных. Класс M (measurement) предназначен для приложений, чувствительных к точности получаемых измерений и не требующих минимальной задержки передачи данных.
WINDOW длиной 4 байта представляет длительность измерений одного вектора, включая все способы обработки сигнала, и измеряется в микросекундах, тип данных – int32.
GRP_DLY – то же, что и WINDOW, только для группы векторов.
Кадры заголовка
Header frame – это кадр с удобочитаемой описательной информацией о УСВИ/КСВД. Формат сообщения представлен слева.
Кадр заголовка идентифицируется 4-6 битами поля SYNC. Поля DATA 1..n длиной 1 байт представляют собой простые ASCII-символы, из которых собираются обычные слова и предложения.
Кадры управления
Устройство передачи данных должно быть готово принимать команды, указанные в command frame, и выполнять соответствующие действия. Так же, как и все остальные кадры, command frame идентифицируется 4-6 битами поля SYNC. Формат сообщения представлен слева.
CMD длиной 2 байта определяет команду, которую требуется выполнить получателю этой команды, т.е. УСВИ/КСВД, в составе которого имеется поток данных с IDCODE, указанным в поле IDCODE данного сообщения.
EXTFRAME – расширенные данные кадра, определяются пользователем.
Использование стека TCP/IP для передачи сообщений C37.118
Итак, очевидно, что С37.118 занимает прикладной уровень модели OSI. В отличие от схемы «Издатель – Подписчик», используемой в протоколах GOOSE и SV, устройства, поддерживающие С37.118 работают по схеме «Клиент – Сервер» (но, если использовать мультикаст IP-адреса, то можно работать и по схеме «Издатель-Подписчик»). Основными режимами работы устройств являются спонтанный и управляемый. В спонтанном режиме данные отправляются по указанному адресу, независимо от состояния Клиента. В управляемом режиме Сервер работает в соответствии с командами, полученными от Клиента.
Стандарт предлагает четыре варианта взаимодействия устройств на транспортном уровне.
TCP-only
В этом режиме все сообщения (команды, заголовки, файлы конфигурации и данные) передаются по протоколу TCP на транспортном уровне. Плюсами этого метода являются надежность и гарантированность доставки всех сообщений. Недостатком становится более высокий объем трафика в сравнении с другими режимами. В случае потери одного пакета механизмы работы протокола TCP могут вызвать временную задержку передачи данных, что для приложений, работающих в реальном времени, значительно хуже, чем потеря одного пакета.
UDP-only
В этом режиме все сообщения передаются по протоколу UDP на транспортном уровне. Плюсами являются сниженные требования к пропускной способности сети, и низкая временная задержка, а минусами – безвозвратная потеря недошедших пакетов.
TCP/UDP
В этом режиме все команды, заголовки и файлы конфигурации передаются по протоколу TCP, а для отправки данных используется UDP. Преимуществами этого метода в сравнении с другими считаются более безопасная передача критически важных сообщений (кадры конфигурации, команды) и меньший объем трафика совместно с низкой временной задержкой при передаче данных.
Spontaneous data transmission
В этом режиме PMU/PDC или другое устройство отправляет данные непрерывно по указанному адресу, независимо от состояния приёмника. Также с каким-либо интервалом времени может высылаться кадр конфигурации.
Моделирование трафика С37.118
Как мы уже выяснили, данные СВИ могут использоваться в различных программах, приложениях, устройствах, работающих в режиме реального времени. В своей основе этим устройствам интересны именно параметры электрического режима, которые передаются по сети согласно стандарту IEEE C37.118. Следовательно, для тестирования таких устройств требуется имитационная модель энергосистемы, на которой можно моделировать различные режимы работы энергосистемы в реальном времени и получать от нее данные в формате сообщений С37.118.
Выглядит как задачка уровня ПАК РВ (программно-аппаратный комплекс реального времени). Одним из ПАК РВ, отвечающим таким условиям, является отечественный КПМ РИТМ. Для тех, кто не знаком с КПМ РИТМ, добро пожаловать на сайт, на котором можно получить всю необходимую информацию о нем.
КПМ РИТМ поддерживает передачу и прием сообщений C37.118 во всех режимах, предусмотренных стандартом (Spontaneous data transmission by UDP, UDP-only, TCP-only, TCP/UDP).
Давайте посмотрим, как выглядит рабочий процесс в таком сценарии использования КПМ РИТМ.
В качестве приёмника пакетов C37.118 будем использовать программу PMU Connection Tester
Соберем небольшую модель энергосистемы и добавим блоки формирования пакетов С37.118. С помощью PMU Connection Tester будем управлять передачей данных из КПМ РИТМ, на котором работает модель физической энергосистемы и УСВИ. PMU Connection Tester в данном случае играет роль приемника трафика С37.118.
Общая схема выглядит следующим образом:
Вот так выглядит наша модель в Simulink.
Смоделируем однофазное замыкание на землю на линии Л2 и начнем передавать на тестируемое устройство 4 тока этой линии и 4 напряжения с шин ПС3 в режиме TCP/UDP. Рассмотрим в WireShark и PMU Connection Tester, как выглядит процесс передачи данных между устройствами, поддерживающими стандарт IEEE C37.118.
В процессе моделирования выполним следующие шаги:
запрос файла конфигурации и команда на включение передачи данных;
включение выключателя Q2;
двухфазное короткое замыкание на землю (BC-N);
возврат к нормальному режиму.
Запустим нашу модель, выполним первый этап моделирования и посмотрим, как это выглядит в WireShark:
Видим, что сначала отправляется команда turn off (в WireShark она отображается как data transmission off), затем запрашивается файл конфигурации, и после его получения отправляется команда на старт передачи данных. Как видно, команды управления и файл конфигурации отправляются по протоколу TCP, а данные уже по UDP.
Теперь рассмотрим, как изменения электрических параметров режима выглядят в PMU Connection Tester.
Модель запущена, выключатель Q2 отключен, КЗ нет. Переток мощности равен нулю. Частота – 50 Гц.
Включаем выключатель и видим изменения значений мощности и углов
Переток мощности в нормальном режиме направлен к шинам ПС 3.
Теперь моделируем короткое замыкание и видим, что мощность изменила свое направление.
После окончания КЗ снова возвращаемся к нормальному режиму.
Итог
Мы обсудили, что такое СВИ и зачем они нужны, рассмотрели в каком формате и каких режимах передаются сообщения С37.118 между устройствами и, используя КПМ РИТМ и PMU Connection Tester, посмотрели, как это выглядит на практике. Если тема моделирования в реальном времени вам интересна, то заходите на наш сайт, где вы найдете всю интересующую вас информацию о нас и КПМ РИТМ, а также в наш телеграм-канал, где мы регулярно рассказываем о проведенных опытах, выкладываем обучающие ролики, анонсируем предстоящие мероприятия и еженедельно выкладываем новости из мира электроэнергетики.
Ждем вопросы и пожелания в комментариях!