требования к наименованию сигналов в файле РАС

Эта часть у меня вызвала массу вопросов на предмет удобства пользования в целом, и порядка следования данных в названии в частности.

Если у вас есть последняя версия стандарта, моя датируется маем 2013, киньте в личку пожалуйста.

Приложение 1
ГОСТ Р МЭК IEC 60255–24 COMTRADE RUSSIAN EXTENSION

Во как!
В последнем варианте никаких русских икстеншенов нет.
Есть просто требования к наименованию сигналов в файле РАС...
Видать желающих ввязаться в это дело на уровне ГОСТ P - не нашлось :0)

Про "русский КОМТРЕЙД" ничего не слышал, а вот стандарт по РАС, действительно ходил по рукам. И да - уже около года тому как.

В Приложении этого СТО как раз и описывался "русский Comtrade"

А Вы не могли бы поделиться какие еще? Было бы любопытно найти им объяснение или решение.

Да, обязательно - чуть попозже.
Сейчас заглядываю сюда на пять минут - мало времени.
Эту тему надо довести до победного конца :0)

а оказалось возможным уйти "в общее ядро")

Именно это я имел в виду говоря про "единый шаблон" - который необходимо прописать в СТО.

Добавлено: 2014-03-26 15:40:17

Про "русский КОМТРЕЙД" ничего не слышал, а вот стандарт по РАС, действительно ходил по рукам. И да - уже около года тому как.

Кстати, вот хорошая бумага по изменениям:

Кончено хотелось бы взглянуть на сам стандарт. Но в документе по указанной ссылке нашел следующее.
1.Ответ на первый мной заданный вопрос по кодировке. Теперь будет

Use of Unicode UTF‐8 characters

Казалсь бы какое отношение это имеет к РЗА? Влияет это на функциональность РАС? Нет. Однако нужно помнить что COMTRADE формат ОБМЕНА информацией. А для ее восприятия и понимания прямое описание записываемых параметров (кстати теперь оно отнесено в разряд критических (обязательных), ранее его можно было опускать) и дополнительные сведения находящиеся в файлах .hdr .inf могут иметь далеко не последнее значение. И если релейщик видит в программе просмотра "кракозябры" вместо текста, то это возможно где-то путаница с кодировкой. Что из этого следует? Да вообщем-то мелочи, которые нужно учесть. Программы просмотра уже сейчас имеют возможность выбора кодировки при просмотре текстовой информации (DOS, Windows). Добавится еще одна - UTF-8. А вот производителям оборудования пишущего в формате COMTRADE и хранящими данные конфигурации на устройстве нужно тщательнее определятся с версией и форматом.

2.Для этого поможет ответ на второй вопрос по году ревизии. В этом же документе в примере ясно указано

SMARTSTATION, IED123, 2013

Из чего я предполагаю, что теперь если
а. даты нет - версия 1991 года
b. дата от 1999 до 2012 (уж так сложилось на практике, причину я указывал) - версия 1999
c. дата 2013 - версия последнй редакции IEC 60255‐24 Ed 2.0/IEEE C37.111‐2013, естественно не последняя и все последующие будут со своей датой.

Перефразируя поэта "О сколько нам открытий чудных готовит..."

Это еще один вопрос который меня интересует. Как-то так складывается, что некоторые межданародные стандарты начинают использоваться, от отечественных производителей требуют соответствия, а стандарт не переведен на руский и не введен в действие. Например 61850 - переведен частично, а на него ссылается всякий, кто выходит на рынок с новым оборудованием. Ибо это не только(или не столько) требование времени, а требование ФСК. Не исключение COMTRADE. На вопрос кто должен переводить по-моему логично предположить - тот кто требует. Изложите свои требования по-русски (переведите стандарт). Хотите внести изменения, дополнения - пожалуйста, но это будет другой стандарт.

А Вы не могли бы поделиться какие еще? Было бы любопытно найти им объяснение или решение.

из недавнего (по теме Comtrade):
когда возникла необходимость "вхождения" в comtrade, и понимая, что этот стандарт (МЭК) ничем не лучше других, решили/сделали так:
прошерстили поляну на предмет:
а какие просмотрщики самые популярные/любимые Заказчиком?
какие просмотрщики нравятся нам, и, желательно, современные/бесплатные/легкие?
по-быстрому протестировали 7-12 просмотрщиков;
на хр.. снесли все импортные просмотрщики, как класс (потому, что они импортные и бодаться с ними уже достало, а с нашими - даже "крутыми" - всегда можно договориться);
выбрали тройку (дали им высший рейтинг), остальные расположили по снижению "признания";
создали структуру файлов на 100% совместимую с первой тройкой (хвала им - не пришлось создавать "варианты", а оказалось возможным уйти "в общее ядро"), остальные - как получилось (пусть "стандарт" учат);
провели их (наших файлов и просмотрщиков) "штормовое" (с идиотскими структурами и параметрами) тестирование;
с авторами наиболее понравившегося (и современного) просмотрщика пообщались на предмет внедрения нового для них функционала (проблема удобства использования лежит далеко за пределами стандарта);
покурили, выпили на радости, сообщили о достигнутом заказчикам (два популярных у заказчика и два у нас просмотрщика работают, как часы) и успокоились...

чего и вам желаем :-))

PS
стандарт, это не то, что должно удовлетворять больным фантазиям производителей, а то, что необходимо любому заказчику - минимум/ядро + 2-3 функциональных "красивостью" варианта (таблицы с более 4-5 "вариантами" чего-то - вредительство: пусть изготовители упражняются в надежностях, качествах, дизайнах, эргономиках, стоимостях и т.п.)

В прошлом году вышел IEC 60255‐24 Ed 2.0/IEEE C37.111‐2013, Published on April 30, 2013
Новый стандарт имеет два логотипа IEEE/IEC, т.е. должен трактоваться однозначно. Есть ли в нем более строгое требование к данному полю пока не знаю, может кто из более сведующих подскажет.

Кстати, вот хорошая бумага по изменениям:
http://www.pes-psrc.org/h/H04/IEEE%20PE … _Final.pdf

А вот это - то, что может лечь в основу статьи.

Совершенно согласен.

Когда НАЧИНАЕШЬ ИСПОЛЬЗОВАТЬ станадарт вопросы и появляются.

Спасибо, что не поленились и перешли к конкретике. Очень полезный материал.
Всё именно так, как Вы пишите.
Я именно это, и многое ещё что, и имел в виду, когда написал

В принципе - да. Но не просто правильные примеры, а именно правильные шаблоны, которые бы однозначно толковали коллизии о которых Вы написали (есть и ещё).

Вроде стандарт есть, и вопросов быть не должно.

Когда НАЧИНАЕШЬ ИСПОЛЬЗОВАТЬ станадарт вопросы и появляются.
1.Стандарт международный. В стандарте есть файлы описаний .cfg .hdr .inf в которых содержатся названия дискретных и аналоговых параметров,
дополнительные описания. Стандарт использует для этого ASCII.
А как быть с кириллицей, в какой кодировке должны использоваться строки описаний? Современные операционные системы используют UNICODE (которых тоже не одна).

2. Стандарт разработан институтом IEEE и имеет две ревизии 1991(IEEE Std 111-1991) и 1999 (IEEE Std C37.111-1999)
Они отличаются требованиями к форме заполнения  полей в файле конфигурации и наличием дополнительных полей. Чтобы отличать эти версии введено дополнительное поле года ревизии и в его описании указывалось на
его критичность (обязательность). Отсутствие поля указывало на соответствие версии файла конфигурации 1991 году, наличие – году пересмотра (ввода изменений) стандарта.
В чем проблема?
Программа просмотра ориентирующаяся на оба стандарте IEEE определят его по значению 1999.
Более поздние корректировки должны определяться по другой дате.

В 2001 году появляется стандарт IEC 60255-24 First edition 2001-05 принятый МЭК.
Сам стандарт практически слово в слово копирует документ IEEE Std C37.111-1999.
Однако при описании года ревизии в качестве примера приводится 2000 год, а в разделе приложений указан 1997 год.
Некоторые производители ссылаются на поддержку IEC стандарта COMTRADE и ставят в файле конфигурации год ревизии
2001. Поэтому сторонняя программа просмотра ориентриующаяся на IEEE и вышедшая до 2001г может выдать ошибку, не поняв о какой ревизии идет речь.

В прошлом году вышел IEC 60255‐24 Ed 2.0/IEEE C37.111‐2013, Published on April 30, 2013
Новый стандарт имеет два логотипа IEEE/IEC, т.е. должен трактоваться однозначно. Есть ли в нем более строгое требование к данному полю пока не знаю, может кто из более сведующих подскажет.

COMTRADE имеет две стороны - сторона записывающая в этом формате и сторона читающая.
Если это дело рук одного производителя, то вопросов, как правило, не возникает.
Если РАС (регистратор аварийных событий) или (функция РАС) записывает файл конфигурации с отклонениями от стандарта, то должна ли читающая программа распознавать это и производить корректировки
или просто сообщать об ошибке? 
С точки зрения стандарта - второе, ибо стандарт предписывает в случае ошибки в критически важном поле считать файлы не соответствующими стандарту и читающая программа не обязана ее исправлять ибо не знает причину (источник) ошибки.
С точки зрения использования программы, а если она коммерческая и привлекательности - первое.
Проблема только в том, что читающая программа не знает заранее какие ошибки могут появиться  от того или иного производителя. Поэтому если устройство эксплуатируется и производитель не собирается
менять его "прошивки" (хотя бы потому что прибор уже устарел) ищите (пишите) программу читающую данный формат, что и сделал Евгений Георгиевич (doro).
Для людей занимающихся написанием программ чтения полезно иметь подборку РЕАЛЬНО записанных файлов с различными "проблемами". Поэтому просьба к doro разместить где-нибудь - на своем сайте или на форуме -
тестовый архивчик с такими файлами - программистам он будет подспорьем. А может и форумчане добавят свое.

По моему каждая версия COMTRADE и есть рекомендованный шаблон. Может быть речь идет о том, чтобы собрать правильные примеры для всех вариантов стандарта.

Тем не менее, далеко не всем программистам это удалось. Отсюда и рейтинг - от лидеров до аутсайдеров.

А какой организации? На сегодня есть две таковые: ФСК и СО ЕЭС. Так вот под заказ первой и при некотором административном нажиме на производителей РАС НПП Бреслер и удалось создать наиболее универсальное средство просмотра осциллограмм. ЭКРА и без этого (пусть и под моим нажимом) удалось разобраться в проблеме и распознать все представленные типы осциллограмм. Так для чего в СТП вносить дополнительные требования, когда главные поставщики соответствующего ПО для ФСК и так справились с проблемой? А кто не справился до конца - пусть работают, проблема ведь решаемая.

А чем статья http://dororz.ru/pt2_16_1.htm Вас не устраивает?

Так Вы же там сами пишите:
"Формат COMTRADE не является абсолютно универсальным. Качество просмотра зависит как от разработчика исходных файлов, так и от качества программ – просмотрщиков.
Нет абсолютно универсального средства для просмотра всех модификаций файлов COMTRADE. Программы разных разработчиков в большей или меньшей степени к этому приближаются, и нет гарантии, что даже очевидные лидеры этого этапа тестирования (функциональность 60 из 63 возможных) так же успешно справится и с другими осциллограммами от аппаратуры для более низкого класса напряжения".

Я и предлагаю исправить эту ситуацию
Здесь ведь если файл "открывается" - это не значит, что всё в порядке.
Вот ведь чудо какое - открывается!
Программисту ведь не сложно сделать, чтобы "открывалось": взял файл данных и как-то там более или менее достоверно отобразил на на экране.
Чтобы всё было верно, необходимо чтобы все параметры указанные в CFG файле были адекватно считаны, имеющиеся данные были  правильно интерпретированы, правильно пересчитаны и отображены.
Т.е. чтобы каждая точка из имеющегося массива данных заняла положенное ей место на плоскости - как по времени так и по амплитуде.
Ну и, разумеется, не перепутались каналы :0)

А для этого надо из всех возможных вариантов (версий) COMTRADE - собрать один рекомендуемый шаблон, и декларировать его в стандарте организации. Собранный по такому шаблону файл будет читаться всеми программами. У нас появиться уверенность - у программистов - однозначность.