В русскоязычной части интернета отсутствуют исчерпывающие статьи про формат COMTRADE. Автором данной статьи предпринята попытка структурировать разрозненную информацию про данный формат и собрать её воедино. В данной статье представлена история развития формата COMTRADE, показано содержание актуальной версии стандарта, а также приведён пример использования данных файлов для тестирования релейной защиты с помощью среды вычислений и моделирования Engee. Данный материал может быть полезен как студентам, только начинающим изучать работу со стандартом COMTRADE, так и опытным инженерам для освежения знаний.
Введение
COMTRADE (Common Format for Transient Data Exchange for Power Systems — «Единый формат для обмена переходными процессами в энергосистемах») — международный формат, созданный для унификации хранения и обмена данными о возмущениях в электроэнергетике. Его главная цель — обеспечить совместимость оборудования разных производителей и упростить анализ аварийных событий за счёт использования единого формата записи.
Формат COMTRADE развивался в четыре этапа:
Первая публикация формата комитетом IEEE в 1991 году под обозначением IEEE C37.111-1991;
Пересмотр стандарта в 1999 году - IEEE C37.111-1999;
Последствия блэкаута на северо‑востоке США в 2003 году;
Пересмотр стандарта в 2013 году - IEEE C37.111-2013 (IEC 60255-24:2013).
Эволюция формата COMTRADE
Стандарт 1991 года
Необходимость в стандарте возникла в 1980-е годы, когда цифровые регистраторы аварийных событий и микропроцессорные устройства релейной защиты и автоматики (РЗА) стали активно внедряться в энергосистемах. До этого периода использовалась РЗА на основе электромеханических реле, которые не позволяли вести детальную запись осциллограмм и хранить большие массивы данных. Их работа фиксировалась в основном по механическим указателям, лампочкам или элементарным печатающим устройствам, что было недостаточно для глубокого анализа сложных аварийных процессов. Появление цифровых устройств дало возможность записывать и анализировать осциллограммы переходных процессов, однако каждый производитель РЗА использовал собственный формат записи аварийных событий, что затрудняло обмен информацией между устройствами и усложняло расследование аварий. Кроме того, отсутствовал единый подход к хранению параметров измерений: каналов, коэффициентов пересчёта, частоты дискретизации и временных меток. Для решения этой проблемы комитет по релейной защите института IEEE (некоммерческая ассоциация, которая разрабатывает стандарты в области электроники и электротехники) разработал единый формат COMTRADE, первая версия которого вышла в 1991 году как стандарт IEEE C37.111-1991.
Редакция 1991 года определяла три типа (расширения) файлов:
.CFG — для описания каналов и параметров измерений,
.DAT — для записи аналоговых и дискретных данных,
.HDR — для текстовой информации о событии.
Так выглядит набор файлов на компьютере:
Все три файла рассматривались как обязательные элементы комплекта записи переходного процесса. Под словосочетанием “запись переходного процесса” понимается запись мгновенных значений токов и напряжений в какой-то точке энергосистемы, например на линии электропередачи на подстанции. Данные в .DAT записывались в формате ASCII, что делало их легко читаемыми, но объёмными и не всегда удобными для обработки. Первая версия стандарта была быстро принята ведущими производителями РЗА и энергетическими компаниями, которые увидели ценность в обмене и использовании данных множества устройств, географически распределённых, включая моделирующие и испытательные лаборатории и объекты в поле. К середине 1990-х стандарт получил широкое международное распространение.
Стандарт 1999 года
В 1990‑е годы было внедрено много микропроцессорных устройств РЗА, способных записывать переходные процессы и появилось значительное количество новых эксплуатационных нюансов. Комитет по релейной защите отслеживал эти изменения и подготовил пересмотренный стандарт IEEE COMTRADE в 1999 году.
В этой редакции файл .HDR стал необязательным, сохранив функцию хранения свободных текстовых комментариев. Для структурированной дополнительной информации был введён новый файл — .INF, куда помещались сведения о регистраторе, условиях записи и характеристиках каналов в формате, понятном для компьютера. Существенным новшеством стало появление в файле конфигурации (.CFG) новых полей для описания первичных и вторичных величин каналов, что позволяло явно указывать, какое значение представляет измерение: вторичное с выхода измерительного трансформатора или пересчитанное в первичные параметры сети. Также был добавлен бинарный формат хранения данных в файле данных (.DAT), который позволял существенно уменьшать объём файлов и ускорял их обработку.
Блэкаут в США в 2003 году
14 августа 2003 года значительная часть северо‑востока США и часть Канады пережили блэкаут, который затронул более 50 миллионов человек. На полное восстановление системы потребовалось несколько дней. Североамериканская корпорация по надежности (NERC) инициировала расследование первопричин с целью дать рекомендации по предотвращению подобных событий. NERC собрала тысячи файлов переходных процессов от многих задействованных энергокомпаний. Сбор показал две ключевые проблемы, серьезно повлиявшие на ход расследования:
Собранные файлы имели множество форматов, многие — проприетарные. Команда по расследованию аварии вынуждена была использовать разные программы отображения и анализа, что замедляло работу и мешало синхронизировать файлы и проводить сквозные исследования;
Отсутствие общего соглашения об именовании файлов: было сложно понять, какие файлы относятся к какому участнику и какому устройству. Не было единой практики именования стало серьёзным препятствием.
К счастью, у команды были инструменты для конвертации файлов в COMTRADE и переименования их по единому формату. Использование COMTRADE и единого формата наименований файлов помогло решить многие проблемы управления и анализа больших массивов записей переходных процессов. Эти практики были признаны NERC чрезвычайно ценными в ходе расследования. Сегодня их использование закреплено в стандарте NERC PRC‑002‑2 (Требования к мониторингу нарушений и отчётности). Однако расследование также выявило ряд слабых мест формата COMTRADE версии 1999 года:
Отсутствие структурированного поля для указания, основаны ли временные метки на местном времени или на UTC (всемирное координированное время);
Отсутствие общих структурированных полей для указания качества синхронизации временных меток;
Отсутствие комбинированного формата файла, что усложняло работу с четырьмя отдельными файлами на одну запись COMTRADE.
Стандарт 2013 года
С 2002 года две рабочие группы Комитета по релейной защите накапливали опыт, разрабатывали решения и тщательно перерабатывали текст стандартов 1991 и 1999 годов, что привело к созданию стандарта IEC 60255-24:2013 / IEEE C37.111-2013. Стандарт содержит ряд полезных дополнений и изменений, включая:
Новые поля и типы данных для поддержки расширяющегося применения стандарта;
Новую структуру единого файла для упрощения управления и отслеживания больших объёмов записей COMTRADE;
Пересмотр текста с удалением устаревших ограничений (например, ограничение длины имени файла 8 символами);
Поддержка нескольких частот дискретизации в одном наборе файлов;
Расширение разрешения временной метки до микросекунд для соответствия GPS-синхронизации;
Перевод некоторых некритичных полей конфигурации в разряд критичных для лучшего понимания и использования данных файла COMTRADE.
Эти изменения сделали COMTRADE более удобным для интеграции в автоматизированные системы анализа и мониторинга, а также повысили совместимость с устройствами синхронизированных векторных измерений (про них более подробно можно прочитать в одной из наших прошлых статей.
Сегодня COMTRADE является де-факто мировым стандартом для обмена записями аварийных событий. Его поддерживают практически все современные устройства РЗА, регистраторы аварийных событий и аналитические программные комплексы. Он применяется в расследовании аварий, наладке устройств РЗА, тестировании и моделировании энергосистем. Последняя версия стандарта, описывающего формат COMTRADE, выпущена в 2013 году и по сей день остается общепринятым во всем мире. Формат COMTRADE активно используется и в России, поэтому был разработан так называемый “COMTRADE Russian Edition” в виде стандарта ГОСТ Р 58601— 2019, где более подробно описаны требования к содержанию файлов. Раздел ниже подробно описывает структуру формата и предназначен для технических специалистов (непосвященный читатель может смело его пропустить).
Скрытый текст
Формат COMTRADE 2013 года
Теперь подробно рассмотрим содержание актуальной версии формата COMTRADE. Стандарт IEEE C37.111-2013 определяет набор файлов, в которых хранится информация о зафиксированных переходных процессах в энергосистеме в формате COMTRADE. Основные файлы — .CFG и .DAT; дополнительно могут присутствовать .HDR и .INF.
1 Файл заголовка (.HDR)
Файл заголовка представляет собой текстовый файл ASCII, предназначенный для хранения дополнительной описательной информации, предоставляемой пользователю для лучшего понимания условий записи переходных процессов. Файл заголовка не предназначен для обработки прикладными программами.
Примеры информации, которая может быть включена в файл заголовка:
Описание энергосистемы до возникновения нарушения;
Название станции или подстанции;
Наименование линии, трансформатора, реактора, БСК или автоматического выключателя, где произошла авария;
Длина линии с неисправностью;
Активное сопротивление, реактивное сопротивление прямой и нулевой последовательности;
Описание способа получения данных: были ли они получены на подстанции энергокомпании или путем моделирования в компьютерной программе;
Описание использованных фильтров в АЦП;
2 Файл конфигурации (.CFG)
Файл конфигурации представляет собой текстовый файл ASCII в стандартизированном формате. Он должен быть включен в каждый набор файлов для определения формата файла данных.
2.1 Первая строка файла конфигурации должна содержать название станции, идентификатор записывающего устройства и год выпуска стандарта:
station_name,rec_dev_id,rev_year<CR/LF>
где
station_name — название подстанции.
rec_dev_id — идентификационный номер записывающего устройства.
rev_year — год пересмотра стандарта, например 2013.
2.2 Строка содержит количество и тип каналов, как они встречаются в каждой записи данных в файле данных:
TT, ##A, ##D <CR/LF>
где
TT — общее количество каналов. TT должно равняться сумме ##A и ##D ниже.
##A — количество аналоговых каналов.
##D — количество дискретных каналов.
2.3 Информация об аналоговых каналах. Для каждого аналогового канала имеется одна строка, общее количество строк аналоговых каналов должно равняться ##A. Если количество аналоговых каналов = 0, то строк с информацией об аналоговых каналах нет. Используется следующий формат:
An,ch_id,ph,ccbm,uu,a,b,skew,min,max,primary,secondary,PS<CR/LF>
где
An — индекс аналогового канала.
ch_id — идентификатор канала.
ph — идентификация фазы канала.
ccbm — контролируемый компонент цепи.
uu — единицы измерения канала (kV, V, kA, A, A RMS, A Peak).
a — множитель канала.
b — смещение канала. Коэффициент преобразования канала равен a·x+b, где x — сохраненное в файле данных значение.
skew — сдвиг времени (в мкс) в канале с начала отсчета.
min — минимальное значение данных диапазона.
max — максимальное значение данных. Примечание: max ≥ min всегда.
primary — первичный коэффициент трансформатора напряжения или тока канала.
secondary — вторичный коэффициент трансформатора напряжения или тока канала.
P или S — идентификатор масштабирования первичных или вторичных данных.
2.4 Информация о дискретных каналах. Для каждого канала имеется одна строка. Общее количество строк канала состояния должно равняться ##D. Если количество каналов состояния = 0, то строк информации о канале состояния нет. Используется следующий формат:
Dn,ch_id,ph,ccbm,y<CR/LF>
где
Dn — индексный номер канала состояния.
ch_id — это название канала.
ph — это идентификатор фазы канала.
ccbm — контролируемый компонент цепи.
y — нормальное состояние дискретного канала.
2.5 Частота сети:
If<CR/LF>
где
If — номинальная частота сети в Гц.
2.6 Информация о частотах дискретизации и количестве выборок данных при данной частоте.
Для файлов с одной или несколькими заранее определенными частотами дискретизации информация состоит из одной строки с общим количеством частот дискретизации, за которой следует строка для каждой частоты дискретизации, включая номер последней выборки при этой частоте дискретизации. Для каждой частоты дискретизации в файле данных должна быть одна строка с информацией о частоте дискретизации и номере конечной выборки. Для файлов с непрерывно изменяющимися периодами дискретизации информация о частоте дискретизации состоит из двух строк: одна строка с нулем, означающим, что нет фиксированных периодов дискретизации или частот, и вторая строка, включающая ноль, означающий, что период дискретизации не фиксирован, и номер последней выборки в файле данных.
nrates<CR/LF>
samp,endsamp<CR/LF>
где
nrates — количество частот дискретизации в файле данных.
samp — частота дискретизации в герцах.
endsamp — номер последней выборки при этой (samp) частоте дискретизации.
Если nrates и samp равны нулю, временная метка в файле данных становится критической, и endsamp должно быть установлено на номер последней выборки в файле. Когда доступна как информация переменных nrates и samp, так и информация временной метки, для точного времени предпочтительно использовать переменные nrates и samp.
2.7 Метки даты/времени. Первая — для времени первого значения данных в файле данных. Вторая — время срабатывания триггера. Они должны отображаться в следующем формате:
dd/mm/yyyy,hh:mm:ss.ssssss<CR/LF>
dd/mm/yyyy,hh:mm:ss.ssssss<CR/LF>
где
dd — день месяца
mm — месяц.
yyyy — год.
hh — час.
mm — минуты.
ss.ssssss — секунды, разрешение = до 1 нс.
Все значения даты и времени должны быть дополнены нулями по мере необходимости. Если какие-либо данные для отметки времени и даты отсутствуют, разделители полей запятые/<CR/LF> могут следовать друг за другом без промежуточных символов, или правильно отформатированное поле может быть заполнено числовыми значениями, замененными нулями.
2.8 Тип файла данных должен быть задан как файл ASCII, binary, binary32 или float32 с помощью идентификатора типа файла в следующем формате:
ft<CR/LF>
где
ft — тип файла.
2.9 Коэффициент умножения временной метки. Это поле должно использоваться в качестве коэффициента умножения для поля временной метки (timestamp) в файле(ах) данных, чтобы обеспечить возможность хранения записей длительной продолжительности в формате COMTRADE. Время, прошедшее с момента первой выборки данных в файле данных до выборки, отмеченной любым полем временной метки в этом файле данных, является произведением временной метки для этой выборки данных и множителя времени в файле конфигурации (timestamp*timemult).
timemult<CR/LF>
где
timemult — коэффициент умножения для поля разницы во времени (timestamp) в файле данных.
2.10 Эта строка содержит информацию о часовом поясе для отметок даты/времени и местоположении регистратора.
time_code, local_code<CR/LF>
где
time_code соответствует временному коду (+10h30, -7h15).
local_code — разница во времени между местным часовым поясом места записи и UTC.
2.11 Качество времени выборок должно быть обозначено идентификатором качества времени в следующем формате:
tmq_code,leapsec<CR/LF>
где
tmq_code — код индикатора качества времени часов записывающего устройства.
leapsec — индикатор високосной секунды.
Допустимые значения:
3 = источник времени не имеет возможности обрабатывать високосную секунду,
2 = високосная секунда вычтена из записи,
1 = в записи добавлена високосная секунда,
0 = в записи нет високосной секунды.
Полная структура файла конфигурации:
station_name,rec_dev_id,rev_year<CR/LF>
TT,##A,##D<CR/LF>
An,ch_id,ph,ccbm,uu,a,b,skew,min,max,primary,secondary,PS<CR/LF>
An,ch_id,ph,ccbm,uu,a,b,skew,min,max,primary,secondary,PS<CR/LF>
An,ch_id,ph,ccbm,uu,a,b,skew,min,max,primary,secondary,PS<CR/LF>
An,ch_id,ph,ccbm,uu,a,b,skew,min,max,primary,secondary,PS<CR/LF>
Dn,ch_id,ph,ccbm,y<CR/LF>
Dn,ch_id,ph,ccbm,y<CR/LF>
lf<CR/LF>
nrates<CR/LF>
samp,endsamp<CR/LF>
samp,endsamp<CR/LF>
dd/mm/yyyy,hh:mm:ss.ssssss<CR/LF>
dd/mm/yyyy,hh:mm:ss.ssssss<CR/LF>
ft<CR/LF>
timemult<CR/LF>
time_code, local_code<CR/LF>
tmq_code, leapsec<CR/LF>
Пример файла конфигурации:
Condie,518,2013<CR/LF>
12,6A,6D <CR/LF>
1,Popular Va-g,,,kV, 0.14462,0.0000000000,0,–2048,2047,2000,1,P <CR/LF>
2,Popular Vc-g,,,kV, 0.14462,0.0000000000,0,–2048,2047,2000,1,P <CR/LF>
3,Popular Vb-g,,,KV, 0.14462,0.0000000000,0,–2048,2047,2000,1,P <CR/LF>
4,Popular Ia,,,A,11.5093049423,0.0000000000,0,–2048,2047,1200,5,P <CR/LF>
5,Popular Ib,,,A,11.5093049423,0.0000000000,0,–2048,2047,1200,5,P <CR/LF>
6,Popular Ic,,,A,11.5093049423,0.0000000000,0,–2048,2047,1200,5,P <CR/LF>
1,Va over,,,0 <CR/LF>
2,Vb over,,,0 <CR/LF>
3,Vc over,,,0 <CR/LF>
4,Ia over,,,0 <CR/LF>
5,Ib over,,,0 <CR/LF>
6,Ic over,,,0 <CR/LF>
60 <CR/LF>
1 <CR/LF>
6000.000,885 <CR/LF>
11/01/2011,17:38:26.663700 <CR/LF>
11/01/2011,17:38:26.687500 <CR/LF>
ASCII <CR/LF>
1<CR/LF>
0, -5h30<CR/LF>
B,3
3 Файл данных (.DAT)
Файл данных содержит номер выборки данных, временную метку и значения данных каждого канала для каждой выборки в файле. В файлах данных ASCII данные для каждого канала в пределах выборки отделены от данных следующего канала запятой. Это обычно называется «форматом с разделителями запятой». Последовательные выборки разделены символом <CR/LF> между последним значением данных канала в выборке и номером следующей выборки. В файлах binary, binary32 или float32 нет разделителей между данными для каждого канала в выборке или между последовательными периодами выборки. Файл данных не содержит никакой другой информации.
3.1 Формат файла данных ASCII
Каждая запись выборки данных должна состоять из целых чисел, расположенных в следующем порядке:
n, timestamp, A1, A2, .....Ak, D1, D2, .....Dm
где
n — номер выборки.
timestamp — временная метка. Некритическая, если переменные nrates и samp в файле .CFG отличны от нуля, критическая, если переменные nrates и samp в файле .CFG равны нулю.
A1 ….Ak — значения данных аналогового канала, разделенные запятыми.
D1 …. Dm — значения данных дискретного канала, разделенные запятыми.
Пример:
5, 667, –760, 1274, 72, 61, –140, –502,0,0,0,0,1,1 <CR/LF>
3.2 Бинарный формат файла данных
Файлы двоичных данных, binary32 и float32 используют ту же базовую структуру, что и файлы данных ASCII, за исключением того, что данные канала состояния сжимаются. Формат представляет собой номер выборки данных, временную метку, значение данных для каждого аналогового канала и сгруппированные данные цифровых каналов для каждой выборки данных в файле. Разделители данных не используются; данные в двоичной записи выборки не разделяются запятыми, а конец записи выборки не отмечается символами возврата каретки/перевода строки. Файл данных представляет собой непрерывный поток данных. Перевод данных определяется последовательным положением в файле. Если какой-либо элемент данных отсутствует или поврежден, последовательность переменных будет утрачена, и файл может стать непригодным для использования. В таком случае восстановление данных невозможно.
Пример (данные соответствуют примеру в формате ASCII):
05 00 00 00 9B 02 00 00 08 FD FA 04 48 00 3D 00 74 FF 0A FE 30 00
4 Файл информации (.INF)
Файл информации представляет собой текстовый файл ASCII, который имеет определенный формат, читаемый компьютером. Файл содержит как информацию, доступную для чтения обычным пользователям, так и информацию, предназначенную для определенной категории пользователей, которая может быть недоступна для чтения обычным пользователям. Данные, хранящиеся в файле информации, должны храниться в общедоступном разделе, если такой раздел определен. Если подходящий заранее определенный общедоступный раздел отсутствует, может быть использован частный раздел. Записи должны точно соответствовать заданному формату, чтобы данные могли быть прочитаны компьютерной программой.
5 Единый формат файлов COMTRADE (с расширением .CFF)
Стандарт 2013 года также предусматривает единый формат файлов для COMTRADE. Единый формат файлов имеет множество преимуществ, в том числе:
Простота управления большими объемами записей COMTRADE,
Только один файл для обмена,
COMTRADE становится стандартным файлом для записей переходных процессов (а не только для обмена).
Файл .CFF состоит из четырёх разделов в следующем порядке с однострочным разделителем между разделами:
--- file type: CFG ---
Содержимое файла конфигурации (.CFG)
--- file type: INF ---
Содержимое файла информации (.INF)
--- file type: HDR ---
Содержимое файла заголовка (.HDR)
--- file type: DAT ASCII ---
ИЛИ
--- file type: DAT BINARY:702 ---
Содержимое файла данных (.DAT)
Число «702» после слова «BINARY» — это количество байтов в двоичных данных.
Пример:
--- file type: CFG ---
SMARTSTATION,IED123,2013
8,4A,4D
1,IA ,,Line123, A,0.1138916015625,0.05694580078125,0,-32768,32767,933,1,s
2,IB ,,Line123, A,0.1138916015625,0.05694580078125,0,-32768,32767,933,1,s
3,IC ,,Line123, A,0.1138916015625,0.05694580078125,0,-32768,32767,933,1,s
4,3I0,,Line123, A,0.1138916015625,0.05694580078125,0,-32768,32767,933,1,s
1,51A,,Line123,0
2,51B,,Line123,0
3,51C,,Line123,0
4,51N,,Line123,0
50
1
1200,40
12/01/2011,05:55:30.75011
12/01/2011,05:55:30.78261
ASCII
1
-5h30,-5h30
B,3
--- file type: INF ---
--- file type: HDR ---
--- file type: DAT ASCII ---
1,72500,-83,68,7,-8,0,0,0,0
2,73333,-15,5,4,-6,0,0,0,0
3,74167,55,-53,0,2,0,0,0,0
4,75000,122,-96,-2,24,0,0,0,0
5,75833,182,-119,-7,56,0,0,0,0
6,76667,228,-121,-11,95,0,0,0,0
7,77500,260,-104,-14,142,0,0,0,0
8,78333,271,-68,-17,186,0,0,0,0
9,79167,260,-19,-18,223,0,0,0,0
10,80000,228,39,-19,248,0,0,0,0
11,80833,178,100,-19,260,0,0,0,1
12,81667,113,158,-16,255,0,0,0,1
13,82500,43,206,-12,236,0,0,0,1
14,83333,-30,236,-5,202,1,1,0,1
15,84167,-95,249,2,156,1,1,0,1
16,85000,-150,243,6,98,1,1,0,1
17,85833,-187,218,11,42,1,1,0,1
18,86667,-202,176,16,-10,1,1,0,1
19,87500,-195,123,18,-54,1,1,0,1
20,88333,-165,61,19,-85,1,1,0,1
21,89167,-118,-2,17,-103,1,1,0,1
22,90000,-57,-61,13,-106,1,1,0,1
23,90833,10,-110,9,-91,1,1,0,1
24,91667,78,-144,4,-62,1,1,0,1
25,92500,138,-159,-2,-23,1,1,0,1
26,93333,187,-159,-7,21,1,1,0,1
27,94167,219,-139,-11,69,1,1,0,1
28,95000,230,-105,-14,111,1,1,0,1
29,95833,221,-56,-16,149,1,1,0,1
30,96667,191,2,-17,176,1,1,0,1
31,97500,143,61,-15,189,1,1,0,1
32,98333,83,118,-13,188,1,1,0,1
33,99167,17,165,-9,172,1,1,0,1
34,100000,-50,197,-4,144,1,1,0,1
35,100833,-111,212,2,103,1,1,0,1
36,101667,-161,209,6,53,1,1,0,1
37,102500,-195,187,11,4,1,1,0,1
38,103333,-208,149,15,-44,1,1,0,1
39,104167,-199,99,17,-83,1,1,0,1
40,105000,-169,41,18,-110,1,1,0,1
Зачем еще используют COMTRADE
Если вы дочитали до этого раздела, то поняли, что COMTRADE - это по сути контейнер с записанной аварией в энергосистеме. Энергетики люди находчивые и логично стали применять эти записи не только для разбора аварий, но и для того, чтобы проверить защитное оборудование еще до введения в эксплуатацию. Одним из наиболее распространённых испытательных комплексов, который может этот файл превратить в реальные токи и напряжения, является РЕТОМ. К нему подключается устройство РЗА на которое подаются токи и напряжения с испытательного комплекса. В результате устройство РЗА “думает”, что находится на реальном объекте.
Но сценарии тестирования устройств РЗА должны быть крайне разнообразными и экзотическими. Реальных аварий с такими осциллограммами не напасёшься. И тут энергетикам пришла гениальная мысль "А давайте мы будем имитировать эти аварии в специальном ПО и сделаем столько записей COMTRADE, сколько захотим".
Такой подход используется для проверки правильности уставок, анализа временных характеристик и селективности защит, оценки устойчивости алгоритмов к переходным процессам. С помощью одного и того же COMTRADE файла могут быть проверены различные терминалы, что позволяет сравнивать работу устройств, контролировать согласованность их функционирования и проводить регрессионное тестирование при обновлении прошивок. Кроме того, воспроизведение через испытательный комплекс обеспечивает возможность безопасной отработки редких или опасных для сети режимов, а также используется для обучения эксплуатационного персонала.
Генерация COMTRADE файлов в Engee
А теперь, после разбора всей теории, перейдём к практике. Представьте себя на пару минут на месте релейщика, которого на работе попросили проверить терминал РЗА для ЛЭП 220 кВ, но у Вас нет никаких записей аварий. Данную проблему можно решить, сгенерировав записи различных аварий с помощью математической модели энергосистемы.
Российская среда динамического моделирования Engee позволяет моделировать электроэнергетические системы, а также имеет встроенный инструмент для генерации COMTRADE файлов. Это делается с помощью специального блока «To COMTRADE» предназначенного для записи сигналов в модели в COMTRADE файлы. В него необходимо подать измеренные токи и напряжения в модели энергосистемы и блок сам сгенерирует файлы.
В библиотеке примеров Engee есть наглядный демо-пример по генерации COMTRADE файлов. В примере для генерации сигналов используется модель, содержащая две энергосистемы 220 кВ, соединенные двухцепной воздушной линией. В момент времени 1 с работы модели на ВЛ происходит однофазное короткое замыкание, которое отключается через 0,1 с. В модель также добавлены трансформаторы тока и напряжения, сигналы от них подаются в блок «To COMTRADE». Для упрощения примера выключатели и трансформатор тока добавлены только на повреждённой цепи.
График напряжения на шинах ПС А фазы А:
Трансформатор тока моделируется с учётом насыщения, его графики первичного и приведенного вторичного тока фазы А приведены ниже:
Для проверки записанных COMTRADE файлов они были открыты в специальной программе для просмотра. В данном примере была выбрана программа Waves от компании ООО НПП «ЭКРА». Скриншот записанных осциллограмм из программы:
Далее записанные COMTRADE файлы можно загрузить на испытательный комплекс и провести тестирование терминала РЗА. В Engee можно моделировать и более сложные аварийные ситуации. Например, в библиотеке примеров Engee есть специальная модель для проведения функциональных испытаний блокировки при нарушениях в цепях напряжения для сетей 6-35 кВ по стандарту ФСК ЕЭС «СТО 56947007-29.120.70.241-2017. В данной модели реализован полный набор из 29 опытов, описанных в стандарте, состоящих из различных обрывов проводов и коротких замыканий с первичной и вторичной стороны с записью измерений в COMTRADE файлы.
Заключение
Формат COMTRADE за несколько десятилетий превратился из простого формата записи данных в полноценный международный стандарт, поддерживающий сложные сценарии анализа и тестирования. Его развитие стало ответом на реальные вызовы энергетики — от необходимости унифицировать хранение аварийных осциллограмм до анализа крупнейших блэкаутов. Сегодня формат COMTRADE является универсальным инструментом, без которого невозможно представить работу современных систем релейной защиты и автоматики. Он обеспечивает инженерам и исследователям надёжную основу для диагностики, моделирования и повышения устойчивости энергосистем. Современные среды моделирования, такие как Engee, расширяют практическое применение формата COMTRADE. Платформа сочетает моделирование энергосистем, быстрые вычисления и генерацию COMTRADE-файлов, что позволяет инженерам анализировать переходные процессы и проверять работу РЗА.
Mnemone
Вроде стандарт поддерживает, что бы в одном файле были осциллограммы с разной частотой дискретизации, но ни один из известных мне просмотровщиков отображать такие файлы не умеет.