|
Форум посвящен вопросам релейной защиты и автоматики (РЗА). Обмену опытом и общению релейщиков. |
Вы не вошли. Пожалуйста, войдите или зарегистрируйтесь.
Коллеги хочу проинформировать новых и напомнить старым участникам форума, что у нас также есть телеграм-канал, присоединяйтесь https://t.me/rzia_sbr
Внимание!!!
1. В связи с наплывом спама в чате включена модерация новых участников.
После подачи заявки на вступление необходимо написать личное сообщение (в телеграмме, ВК или в личных сообщениях на форуме) мне (администратору) с просьбой одобрить заявку с указанием имени (ника) и адреса электронной почты, на которую была регистрация.
2. Для восстановления доступа на форум можно также обращаться по средствам личных сообщений в телеграмме или ВК.
Советы бывалого релейщика → Аварии, дефекты оборудования... → Ложные срабатывания и пуски МТЗ
|
 |
это не свободно программируемая логика, а базовое ПО... и что бы его сменить ...
прикол в том, что ни кто об этом и не узнает даже если они это сделают...
да и вообще кто-то вообще знает, что у них там творится в мозгах...
программные коды дело тёмное ... может у кого-то это даже уже и есть ...
это не свободно программируемая логика, а базовое ПО... и что бы его сменить ...
...
надо познакомиться с коллегами из компании, выпускающей процессоры....
И прикол как раз в том, что на электромеханике, глазами видно и катушку и зазорчики и траекторию какого-нибудь коромысла, с контактами, по которой оно движется, из чего можно вычислить скорости и времена срабатывания. Т.е. обмануть коллегу можно но сложно.
Когда же дело доходит до цифровой техники, то почему то большинство верят уверенно сказанной чуши про какого-нибудь Фурье.
Даже когда, терминал показывает перегрузку линии, а рядом находящийся стрелочный амперметр показывает недогруз до половины номинала.
Когда же дело доходит до цифровой техники, то почему то большинство верят уверенно сказанной чуши про какого-нибудь Фурье.
Даже когда, терминал показывает перегрузку линии, а рядом находящийся стрелочный амперметр показывает недогруз до половины номинала.
Верить никому нельзя. С цифровой техникой можно взять осциллограмму и самому посчитать Фурье или СКЗ. Фурье, СКЗ, мгновенные значения - общедоступные алгоритмы, каждый может проверить.
В РЭ должно быть описание и/или схема, из которых видно - защита работает по основной гармонике и без жестко заданных выдержек времени. Если задал выдержку 0 с - значит, на короткий импульс большой амплитуды защита реагировать будет.
А вот уже всякие скачки и быстродействующие фильтры - исключительно на совести разработчика, и это он должен доказывать, что всё отработало правильно.
Верить никому нельзя. С цифровой техникой можно взять осциллограмму и самому посчитать Фурье или СКЗ. Фурье, СКЗ, мгновенные значения - общедоступные алгоритмы, каждый может проверить.
.
Попробуйте проверить! Первым счастливым человек будете, если получится у какого нибудь производителя - проверить машинные коды от значений вводимых цифр (это когда на клавиатуре нажимаешь единичку, а в памяти машины совсем не единичка запоминается и вступает в работу с другими данными) до формул и циклов. Да и про осциллограмму вы загнули! Наверное с цифрового осциллографа осциллограмму проверять будете не с ЭЛТ же? )))
Попробуйте проверить! Первым счастливым человек будете, если получится у какого нибудь производителя - проверить машинные коды от значений вводимых цифр (это когда на клавиатуре нажимаешь единичку, а в памяти машины совсем не единичка запоминается и вступает в работу с другими данными) до формул и циклов. Да и про осциллограмму вы загнули! Наверное с цифрового осциллографа осциллограмму проверять будете не с ЭЛТ же? )))
Не могу представить, зачем мне проверять машинные коды. Мне важно, что по записанной осциллограмме (что с самого терминала, что с РАС или другого комплекта) я могу оценить, должна ли была работать защита с заданными уставками. Работу осциллографа проверить тоже легко - подаешь от РЕТОМ ток на вход, смотришь осциллограмму.
А уж какие там машинные коды между током и выходным реле - мне совершенно неважно. Если работает неправильно - пускай разработчик разбирается, исправляет и доказывает, что исправил.
| Присоединяйтесь!!! Мы в социальных сетях и на Ютуб. |
А уж какие там машинные коды между током и выходным реле - мне совершенно неважно. .
А мне важно. Товар, в виде труда категории "неважно" даже продавать не хочется.
согласен... МП-реле - это чёрный ящик и собственно нет смысла лесть в его потроха, т.к. должна быть всегда, возможность проверить точность выполняемых им функций...
А мне важно. Товар, в виде труда категории "неважно" даже продавать не хочется.
для этого нужно быть специалистом "широкого профиля"...
но прикол в том, что вероятность найти ошибку практически невозможна ...
можно конечно найти косяки по не оптимальности кода, оставлении отладочных закладок, устаревших блоков, которые остались от старых версий или просто закладок будущих отладок или точек входа в алогритмы...
сложность системы можно оценить числом страниц её описания, а теперь представьте сколько килограммов бумаг нужно, что бы описать МП-терминал как почти белый ящик...
Вопрос о безопасности ПО (в том числе и терминалов) на самом деле актуален... Пока была электромеханика и микроэлектроника (или даже МП-защиты ЦПС 1-й архитектуры) это было непринципиально. Как только началось "объединение" в сети с выходом (входом) "наружу" ПС стали возникать проблемы. Теперь уже, похоже, не надо бомб или ракет. Достаточно знать "уязвимости" и "закладки" в ПО и появляется возможность вывода из строя какого-то района сети (например, потеря управления или защит). Вспомните "вирус" попавший (или уже "заложенный?) в ПО Сименс , выведший из строя центрифуги в Иране. Не зря ведь появилось требование Россетей при аттестации оборудования предоставлять в ФСТЭК "программный" код МП-терминалов и систем АСУ. Не знаю, насколько это требование касается отечественных производителей, но ведь не зря "вражьи" производители стали "возмущаться", мотивируя отказ в предоставлении данных "защитой интеллектуальной собственности". Конечно, навряд ли в ГНИИИ ПТЗИ ФСТЭК России есть специалисты, разбирающиеся в тонкостях алгоритмов защит, но, возможно и существуют методы обнаружения критических "уязвимостей" в ПО? Конечно, может оказаться, что это еще один способ "честного отъема денег" у производителя, но хотелось бы надеяться, что делаются реальные проверки...
согласен... МП-реле - это чёрный ящик и собственно нет смысла лесть в его потроха, т.к. должна быть всегда, возможность проверить точность выполняемых им функций...
Про потроха, уж никто не говорит! Элементарное, когда идете по объекту взять и сравнить показания стрелочных приборов, если они есть и терминалов - это можно сделать. Если есть расхождения, то начать выяснять причины.
Диспетчер, скучающий на смене, не может что ли взять трубку и с объектов свериться, что он видит и что на объекте показывают приборы. Такие операции не требуют высшего образования.
Когда явно видишь, что повреждения на одном элементе, а отключается смежный, то это повод задуматься.
в самих алгоритмах разобраться не сложно ... но вот когда они в ассемблере - пиши пропало ... хуже нет задачи в этом разбираться, легче написать самому...
но по крайней мере специалист должен быть не хуже...
дело же ещё в том, что алгоритм и программы пишутся разными специалистами
алгоритм - это петли и пуговицы, а программа - это швы и обмётка... иногда их число не совпадает, но застегнуть то можно ...
поэтому заведомо релейщику-алгоритмисту не понять программиста...
поэтому заведомо релейщику-алгоритмисту не понять программиста...
Прям уж не понять))) Еще как понять! Только надо начинать с не программы , а обзора рабочего места программиста. Если на нем помойка, то даже минимальной надежды, что написанная им программа, будет стройной - НЕТ. Она будет рваной из разных кусков собранной. Но надо признать, что хуже этого есть режимные программы и режимщики их эксплуатирующие. Вот уж где полный бардак.... Намедни стал разбираться с хваленым системным оператором CIM-порталом! Такая ересь внесена никаких закладок и внешних врагов не надо! Как пример, показал высоковольтным испыталелям завода изготовителя трансформатора, какие данные, системный вносит сам, не имея данных от завода. Так ответ от них был - при таких параметрах наш трансформатор с напряжением 110 кВ и на 330 сможет работать не один десяток лет. Режимщики, что делают - все недостающие данные, которые сами придумали, берут из своих гостов и вносят, а завод изготовитель и гостов таких не видел. Зато все в шоколаде и с премиями! )))
понимаю, если программист перевернёт клавиатуру и хорошенько её встряхнёт, то может питаться этим не меньше недели...
а если серьёзно, то
как пишутся исполнительные машинные коды сейчас
1. Берём симулятор MatLab, PSCad, SimInTech или что другое
2. Моделируем первичную сеть реальную или какую-то вообще и ставим задачу чего хотим получить
3. В FBD этого же симулятора реализуются алгоритмы РЗА на всем понятных элементах - типовые блоки .... алгоритм будет понятен любому релейщику
4. Соединяем первичную модель и вторичную, пытаем и отлаживаем, пока не получим то, что хотим, тут же алгоритмы можно проверить на аварийных сигналах Комтрейд.
5. В этих же ПВК берём из базы аппарат-контроллер-процессор и компилируем под его специфику (сейчас человек не участвует в создании машинных кодов, все процедуры, библиотеки и сценарии уже проработаны).
6. Далее нужен сам аппарат. Заливаем в него исполнительные файлы и, например, опять же используя аварийные файлы и Ретом пытаем уже готовый МП-терминал.
всё ... нет конечно Ваш критический ум опять хоть что-то найдёт ...
Но всё же как видите минимум воздействия бардака и хаоса на производственный процесс...
ПАУтина, браво! Вы великолепно объяснили разницу между ПРОГРАММИРОВАНИЕМ как Искусством, и шаблонным "программированием" по процедуре, описанной Вами выше! В результате что имеем (на примере данной темы): алгоритм в реле "отрабатывает" по "стандартному" Фурье (окно 20мс) на мощную помеху длительностью менее 2мс и все говорят что это "не баг а фича", выражаясь современным языком "псевдорелейщиков" и "псевдопрограммистов". И "обойти" эту "фичу" (особенность алгоритма, в данном случае) надо просто введением задержки в 20мс! То есть "тупо" увеличивая окно с 20мс до 40! И ведь действительно будет "работать"... С появлением мощных процессоров, огромной памяти, увеличением разрядности, частоты обработки "пропали" "истинные программисты" (решение задачи минимумом средств), а остались "ремесленники" и "конвеерщики"... Увы, "вымирают" гении, "выживает" середняк - закон эволюции...
алгоритм в реле "отрабатывает" по "стандартному" Фурье (окно 20мс) на мощную помеху длительностью менее 2мс и все говорят что это "не баг а фича", выражаясь современным языком "псевдорелейщиков" и "псевдопрограммистов".
Я в теме неоднократно писал, что эта "фича" присутствует в любой токовой защите без выдержки времени, в том числе в классических схемах на РТ-40. И эта "фича" всегда решалась введением выдержки времени.
"Настоящие релейщики" же почему-то продолжают считать, что это какая-то особенность неправильного Фурье, а правильная цифровая защита должна телепатически понимать пожелания расчетчика, и не работать в таких режимах и без выдержки времени...
Вера в волшебство неистребима.
Это не "вера в волшебство", а убежденность, что при наличии СОВРЕМЕННЫХ возможностей программирования в МП-реле можно решить проблему отстройки от мощной помехи в 2мс без введения дополнительной "программной" задержки в 20мс ( дополнительное реле времени РВ в "придачу" к реле РТ40 в электромеханике)
Да, еще один аргумент насчет "веры в волшебство": "Программисты-волшебники" из Сименс каким-то образом получили в ДЗШ 7SS52 быстродействие в 2-3мс при КЗ в зоне и отсутствие работы при внешнем КЗ.... А ведь ДЗШ, по большому счету, та же МТЗ?
Это не "вера в волшебство", а убежденность, что при наличии СОВРЕМЕННЫХ возможностей программирования в МП-реле можно решить проблему отстройки от мощной помехи в 2мс без введения дополнительной "программной" задержки в 20мс ( дополнительное реле времени РВ в "придачу" к реле РТ40 в электромеханике)
Эти 20 мс не впридачу к РТ-40. Время срабатывания РТ-40, согласно Алексееву, не более 0,1 с при 1,2 Iср и не более 0,03 с при 3 Iср. Плюс 0,06-0,08 с в промежуточном реле, согласно Федосееву.
Время срабатывания цифрового реле тока при ~1,05 Iср - 20 мс. Плюс ~10 мс на выходных реле. Плюс эти 20 мс выдержки времени.
Современные возможности программирования никак не влияют на принцип действия токовых защит и тем более на процессы в первичных цепях, от которых эти токовые защиты должны быть отстроены.
Выдержка времени 20 мс - гораздо более правильное решение, чем какие-то сложные схемы на приращениях с их встроенными выдержками времени, которые могут нагородить "псевдорелейщики" с "псевдопрограммистами", решая несуществующую задачу ускорения срабатывания обычной токовой защиты.
При работе в РДУ (начальник отдела эксплуатации РЗА) в мои обязанности среди прочих входило рассмотрение уставок. Посчитать-то с трудом могу, а выявить "ляпы" только так. Прошу: Ира или Аня, или кто-то еще. Убери нулевую выдержку времени. Поставь минимально допустимую. Где-то 20, где-то 10 миллисекунд. 5 уже рискованно. Не было возможности отслеживать последствия нулевой выдержки времени. Но береженого Бог бережет.
Да, еще один аргумент насчет "веры в волшебство": "Программисты-волшебники" из Сименс каким-то образом получили в ДЗШ 7SS52 быстродействие в 2-3мс при КЗ в зоне и отсутствие работы при внешнем КЗ.... А ведь ДЗШ, по большому счету, та же МТЗ?
В каком-то смысле ДЗШ - та же МТЗ.
Такая ДЗШ будет срабатывать при внутренних КЗ длительностью 2-3 мс. И даже 0,5-1 мс, скорее всего.
При внешних подобных КЗ дифференциальный ток, скорее всего, будет околонулевой, поэтому срабатывать не будет.
Это достигается дифференциальным принципом действия, который придумали совсем не "программисты-волшебники" из Сименс. Можно это сделать на мгновенных значениях, можно на зарядах, никакие волшебные органы со скачками для этого не нужны.
Кстати было бы любопытно узнать, кто первым предложил дифференциальную защиту.
Советы бывалого релейщика → Аварии, дефекты оборудования... → Ложные срабатывания и пуски МТЗ
