61

Re: статья в журнал

retriever пишет:

Режим 3хф. КЗ в конце линии.

А чего это сразу в конце линии? :0)
Токи на ПС при КЗ на противоположном конце линии - это вполне приемлемые токи для данной ПС. Они конечно "КЗ" - но вполне себе небольшие.
Плюс Х системы справа...
Так что "токи КЗ" - "токам КЗ" - рознь. Да, при АХ токи могут быть равны токам трёхфазного КЗ, но при КЗ в конце очень длинной линии...

62 (2014-03-20 16:13:01 отредактировано retriever)

Re: статья в журнал

Уставкин пишет:

А чего это сразу в конце линии? :0)
Токи на ПС при КЗ на противоположном конце линии - это вполне приемлемые токи для данной ПС. Они конечно "КЗ" - но вполне себе небольшие.

Как можно делать такие выводы о "приемлемости" токов без численных значений? Токи будут "приемлемы", если Zs+ZL >> Zs, тогда ток КЗ в конце линии будет сильно меньше тока КЗ на шинах. А если ZL одного порядка с Zs, то разница может быть, скажем, раза в 2... И что? ТКЗ на шинах 30 кА, а в конце линии - 15 кА, а ТТ стоит 500/1 измерительный с релейными кернами 2000/1 - нормально будет подключать к 500/1 РАС?

Расчет, расчет и только расчет.

63

Re: статья в журнал

retriever пишет:

Расчет, расчет и только расчет.

Безусловно :0)

Я ведь больше спорил о психологии восприятия термина "ток КЗ". Обычно подразумевается именно близкое КЗ. Либо уточняется, чтобы подчеркнуть "малое" значение тока, - "удаленное КЗ".

А про эту злополучную фразу, про 0,5 в документе - есть у нас на форуме люди имеющие возможность задать этот вопрос непосредственно его разработчику.
У меня аргументы кончились :0)

64 (2014-03-21 16:37:53 отредактировано dominator)

Re: статья в журнал

В общем-то, да, при желании можно получить удвоенный ток КЗ.
Включаем генератор в противофазе 3 генераторам - получаем 1.5 Iкз, 100 - 1.98 Iкз. При бесконечном количестве генераторов получим нужную цифру 2.

65

Re: статья в журнал

Уставкин пишет:

Терялись самым таинственным образом

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

Присоединяйтесь!!! Мы в социальных сетях и на Ютуб.

66

Re: статья в журнал

doro пишет:

Не получим информации с одного объекта - получим с другого.

Да, работа в комиссии по расследованию технологических нарушений - это особое искусство :0)
Мало того, что надо полностью разобраться что к чему - но ещё и грамотно "определить виновного".
Зато под "мероприятия" можно выбить что-нибудь действительно полезное :0)

Кстати, для расследования всегда полезно наличие двух независимых источников информации - вот тут и нужен автономный РАС - хозяин которого СО, ну и встроенные в МП-терминалы РАСы вкупе с АСУшными возможностями - от ФСК.

67

Re: статья в журнал

Уставкин пишет:

от тут и нужен автономный РАС - хозяин которого СО

Нет, это хотя и желаемо, но в принципе при нынешней системе взаимодействия субъектов энергетики невыполнимо. Ну представьте, на подстанции стоит какое-то устройство иного собственника (РАС, МП УРЗА, ЭМ УРЗА). Кто будет заниматься его техническим обслуживанием? Подразделениям СО запрещено заниматься подобными вещами. Да и технической возможности никакой нет. Так что надеемся на добросовестность владельцев соответствующего оборудования и аппаратуры. А далее по косвенным данным, полученным с других объектов, проверяем достоверность показаний (пример - на группе страниц http://dororz.ru/os_3.htm).

68

Re: статья в журнал

doro пишет:

Нет, это хотя и желаемо, но в принципе при нынешней системе взаимодействия субъектов энергетики невыполнимо.

Но ведь СМПРы худо-бедно устанавливаются :0)
Оперативный персонал к ним и не подходит.

69

Re: статья в журнал

Да не имеет принципиального значения - подходит или не подходит оперативный персонал. Любое устройство, пусть даже и супернадежное, за счет самотестирования не требующее никакого технического обслуживания, имеет привычку иногда выходить из строя. Пусть даже СО найдет для решения проблем сервисную организацию. А система допуска как в это вписывается? Диспетчер РДУ или ОДУ будет выдавать распоряжения или наряды на работу? Черт ногу сломит. Нет, все же лучше по-дружески. Я тебя уважаю, ты меня уважаешь, я тебя не подставляю - ты меня не подставляешь. Оба мы уважаемые и неподставляемые люди.

70 (2014-03-24 11:03:00 отредактировано Уставкин)

Re: статья в журнал

doro пишет:

Да не имеет принципиального значения - подходит или не подходит оперативный персонал.

Это да. Разумеется независимый РАС должен быть на балансе у ФСК, но относиться они к этой аппаратуре должны как  к, например, счетчикам коммерческого учета - т.е. лишний раз вообще руками не трогать.

71

Re: статья в журнал

Кстати, по теме ветки.

Мне кажется, что нужна хорошая статья по формату COMTRADE. С целью определения общего подхода к формированию файлов cfg и dat и их однозначной интерпретации всеми программами отображения и анализа.
На форуме часто обсуждались эти вопросы, здесь например
http://rzia.ru/topic3195-rasshifrovka-c … trade.html

Ситуация странная:
Вроде стандарт есть, и вопросов быть не должно. Но мы все видим, что эти вопросы возникают.
У каждой программы есть свои особенности интерпретации данных из комтрейд-файла, и особенности их создания (и всё это, конечно же "строго" в рамках стандарта) :0)
Возможно в стандарте организации на РАС (который. как я знаю рождается)  необходимо выделить отдельный раздел - в котором бы давались однозначные рекомендации производителям ПО - как формировать и считывать файлы cfg и dat (т.е.  однозначно трактовались требования стандарта с конкретными примерами).

72 (2014-03-24 16:11:24 отредактировано doro)

Re: статья в журнал

А чем статья http://dororz.ru/pt2_16_1.htm Вас не устраивает? Собственно, тема и была затеяна в ее продолжение. До завершения приема предложений по продолжению статьи осталась одна неделя.

73 (2014-03-24 16:48:30 отредактировано Уставкин)

Re: статья в журнал

doro пишет:

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

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

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

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

74 (2014-03-24 19:20:04 отредактировано doro)

Re: статья в журнал

Э-э-э, так ведь Вы покушаетесь не на российский - на международный уровень!
Впрочем, под лежачий камень (или инженера) вода (коньяк) не течет. Изложите свои мысли в формате статьи на страничку (1000 - 1500 знаков), и постараюсь продвинуть публикацию.

Уставкин пишет:

Программисту ведь не сложно сделать, чтобы "открывалось": взял файл данных и как-то там более или менее достоверно отобразил на на экране.

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

Уставкин пишет:

собрать один рекомендуемый шаблон, и декларировать его в стандарте организации.

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

75

Re: статья в журнал

Уставкин пишет:

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

Когда НАЧИНАЕШЬ ИСПОЛЬЗОВАТЬ станадарт вопросы и появляются.
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 - собрать один рекомендуемый шаблон

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

76

Re: статья в журнал

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

77

Re: статья в журнал

mixi пишет:

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

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

Уставкин пишет:

Вроде стандарт есть, и вопросов быть не должно. Но мы все видим, что эти вопросы возникают.

mixi пишет:

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

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

78

Re: статья в журнал

doro пишет:

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

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

79

Re: статья в журнал

mixi пишет:

В прошлом году вышел 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

80

Re: статья в журнал

СО ЕЭС не первый год уже пишет СТО на "русский COMTRADE", ожидают в этом году закончить.