СШГЭС и сходные системные проблемы

Цитата: НикВик от 08.10.2009 12:26:32
У меня фильтр на контуженность, а  цитата - для затравки
Попробуйте возразить по фактам - запредельный рост вибраций перед взлётом  и поведение персонала, противоречащее категорическим положениям инструкций.

Могу только сказать, что Латынина, когда читала акт, ничего в нём не поняла. Нет тех. образования, она - филолог.
Вот,  со слов каких то дядей, она и написала свою лабуду.
В акте ничего не написано, что трясло весь маш зал, что запредельная вибрация всеми в зале ощущалась. Это выдумки Латыниной. Наоборот, оператор говорил, что все было в норме.

Цитата: 753 от 08.10.2009 12:55:14
Могу только сказать, что Латынина, когда читала акт, ничего в нём не поняла. Нет тех. образования, она - филолог.
Вот,  со слов каких то дядей, она и написала свою лабуду.
В акте ничего не написано, что трясло весь маш зал, что запредельная вибрация всеми в зале ощущалась. Это выдумки Латыниной. Наоборот, оператор говорил, что все было в норме.

ЦитатаЯ филолог, а не гидроэнергетик, и ГЭС представляю себе очень примитивно: вверху плотина, внизу турбина, между ними водовод. Я правильно понимаю, что если б в 8.05 Мисюкевич и Нефедов перекрыли верхний затвор, то аварии бы не случилось, по той же причине, по которой вы никогда не затопите квартиру соседа, если в доме на центральном стояке перекрыли воду? Как филолог, я не очень поняла: станцию трясет (за семь минут до аварии), вибрация составляет 600 мкм, в четыре раза больше нормы, а «действия Мисюкевич соответствуют инструкции»?

Так правильно или неправильно она поняла?

Латынину изучайте вслух в одиночестве, а не на форуме. Трое суток.
Dobryak

Цитата: НикВик от 08.10.2009 14:00:33
Так правильно или неправильно она поняла?

Нет неправильно.
Масюкевич, судя по её показаниям, ничего не заметила. Все приборы перед аварией работали нормально.
Что она должна была делать?
Латынина нашла виновного,  оператора Масюкевич ! Вы это хотите сказать?

Цитата: 753 от 08.10.2009 16:25:10
Нет неправильно.
Масюкевич, судя по её показаниям, ничего не заметила. Все приборы перед аварией работали нормально.
Что она должна была делать?
Латынина нашла виновного,  оператора Масюкевич ! Вы это хотите сказать?

Не передёргивайте, дело не в Масюкевич.

Как именно должна идти информация о превышении пределов допустимых вибраций и  какой уровень обязан был принять решение дёрнуть стоп-кран - тайна сия велика есть.

Цитата: НикВик от 08.10.2009 16:43:32
Как именно должна идти информация о превышении пределов допустимых вибраций и  какой уровень обязан был принять решение дёрнуть стоп-кран - тайна сия велика есть.

Никакой тайны. Главный инженер станции.
О том и речь - что при управлении станции, имеющей каскад в 250 метров, давление на выходе 25 атмосфер, применялась схема управления, как на Волховской ГЭС. Ну, побренчит, мы послушаем, подумаем...

Эта пакость прослеживается от проекта, от работы Заказчика, до эксплуатантов. То есть - это ОБЩЕПРИНЯТО в гидроэнергетике. И вот это - истинная катастрофа.

Цитата: ursus от 08.10.2009 16:51:10
Никакой тайны. Главный инженер станции.

Посмотрим, что скажет следствие.

Цитата: НикВик от 08.10.2009 16:43:32
Не передёргивайте, дело не в Масюкевич.
Как именно должна идти информация о превышении пределов допустимых вибраций и  какой уровень обязан был принять решение дёрнуть стоп-кран - тайна сия велика есть.

В акте написано, что:
"Система постоянного контроля вибрации, уставленная на гидроагрегате №2, выполняла информационную задачу для эксплуатационного персонала, не имела блока спектрального анализа вибрации и быстродействующей буферной памяти для сохранения параметров вибрации при ненормальных режимах работы."

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

"Инструкцией по эксплуатации гидроагрегатов Саяно-Шушенской ГЭС, утвержденной главным инженером филиала ОАО «РусГидро» - «Саяно-Шушенская ГЭС имени П.С. Непорожнего» от 18.05.2009 требования по контролю вибрации регламентированы п. 2.3.5. «Гидроагрегат должен быть разгружен или остановлен в срок, определяемый главным инженером гидроэлектростанции» при внезапном увеличении вибрации крышки турбины и верхней крестовины агрегата более 0,16 мм, боя вала более 0,5 мм, вал надставки более 0,55 мм»....
По данным анализа архивов АСУ ТП, проведенного в период
с 21.04.2009 до 17.08.2009 наблюдался относительный рост вибрации турбинного подшипника ГА-2  примерно в 4 раза, что отражено графически.
В этой ситуации с целью обеспечения безопасной эксплуатации главный инженер СШГЭС (находившийся на станции с 06.35 17.08.2009 г.) должен был принять решение об остановке ГА-2 и исследовании причин вибрации. Вместо этого ГА-2 оставался приоритетным в ГРАРМ при регулировании мощности."

И не было на пульте у оператора ещё вот этого:
"6.1.5.........обеспечить учет данных вибрационного и теплового контроля гидроагрегатов в системе группового регулирования с реализацией функции предупредительной и аварийной сигнализации, автоматического останова гидроагрегатов. "

http://pics.livejour…c/00002ch3
кто-то выложил по аварии на нурекской гэс в 83 году. слов нет.

Цитата: 753 от 08.10.2009 17:24:18
В акте написано, что:
"Система постоянного контроля вибрации, уставленная на гидроагрегате №2, выполняла информационную задачу для эксплуатационного персонала, не имела блока спектрального анализа вибрации и быстродействующей буферной памяти для сохранения параметров вибрации при ненормальных режимах работы."

skipped

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

Про буферную память... Имеется ввиду, что обычная СУБД (система управления базами данных), например MS SQL Server 2000 физически не может сохранять данные чаще, чем 1 раз в секунду. Для вялотекущих процессов этого вполне достаточно. А вот для быстрых процессов (электрических или механических - таких как вибрация и скорость вращения быстроходных машин) требуется гораздо большее быстродействие. Такие системы конечно существуют, например Industrial SQL от Wonderware Inc. Интересующиеся могут заглянуть сюда - как это выглядит... http://www.asutp.ru/?p=600624
Эта и подобные системы жутко дороги, сложны в эксплуатации, и требуется весьма высококвалифицированный персонал. Предложи любому Главному инженеру и скажи, сколько она стоит - у него "волосы на голове завьются без парикмахера" (С) В моей практике подобные системы поставлялись вместе с АСУ нового блока, тогда их стоимость не бросается в глаза. К тому же, если кто-то шибко грамотный подскажет главному, что в условиях нормальной эксплуатации ценность такой системы практически нулевая, и нужна она только для разбора полёта после аварии (которая то ли случится, то ли нет) - участь такого предложения будет решена в одну секунду.
Да и практика говорит, что даже для разбора полёта быстродействующая СУБД не очень-то помогает. Потому как её способность фиксировать события с временнЫм резрешением 0,001 сек ограничивается относительной тихоходностью управляющих контроллеров, которые отрабатывают один цикл десятки (если не сотни) миллисекунд. И по факту в БД в момент начала аварии сваливаются десяток-полтора сигналов с одной временнОй меткой. Вот и сиди, гадай потом, какой же из них был первым...

Цитата: icethed от 08.10.2009 23:31:48
На мой взгляд этот пункт акта выглядит, как форменное издевательство... На хрена системе иметь блок спектрального анализа, если ГА требуется останавливать всего лишь(!!!) по факту увеличения амплитуды вибрации.

Про буферную память... Имеется ввиду, что обычная СУБД (система управления базами данных), например MS SQL Server 2000 физически не может сохранять данные чаще, чем 1 раз в секунду. Для вялотекущих процессов этого вполне достаточно. А вот для быстрых процессов (электрических или механических - таких как вибрация и скорость вращения быстроходных машин) требуется гораздо большее быстродействие. Такие системы конечно существуют, например Industrial SQL от Wonderware Inc. Интересующиеся могут заглянуть сюда - как это выглядит... http://www.asutp.ru/?p=600624
Эта и подобные системы жутко дороги, сложны в эксплуатации, и требуется весьма высококвалифицированный персонал. Предложи любому Главному инженеру и скажи, сколько она стоит - у него "волосы на голове завьются без парикмахера" (С) В моей практике подобные системы поставлялись вместе с АСУ нового блока, тогда их стоимость не бросается в глаза. К тому же, если кто-то шибко грамотный подскажет главному, что в условиях нормальной эксплуатации ценность такой системы практически нулевая, и нужна она только для разбора полёта после аварии (которая то ли случится, то ли нет) - участь такого предложения будет решена в одну секунду.
Да и практика говорит, что даже для разбора полёта быстродействующая СУБД не очень-то помогает. Потому как её способность фиксировать события с временнЫм резрешением 0,001 сек ограничивается относительной тихоходностью управляющих контроллеров, которые отрабатывают один цикл десятки (если не сотни) миллисекунд. И по факту в БД в момент начала аварии сваливаются десяток-полтора сигналов с одной временнОй меткой. Вот и сиди, гадай потом, какой же из них был первым...

я насчёт баз данных  :)
во перых никто не заставляет сразу писать в базу
можно делать вставки раз в 5 минут (вобщем-то зависит от объёма оперативной памяти, которая тоже должна быть крайне быстрой), накапливая блоки инфы в оперативке
насчёт временной метки - каждой метке можно присваивать свой порядковый номер, по которому потом сортировать выброку (номер даваться будет на датчике который снимает инфу и передаваться единым целым на сохранение)

в железе реализацию не скажу - не спец, но думаю при желании и умении можно сварганить

Цитата: kostroma от 09.10.2009 04:05:10
я насчёт баз данных  :)
skipped

Industrial SQL так и работает. Первоначально информация поступает в т.н. БД реального времени, а потом периодически и в несколько потоков сбрасывается в обычную СУБД. И не раз в 5 минут, а гораздо чаще.

Цитата: Dobryak
В ядерной физике и физике высоких энергий уже десятилетия работают с  сложными событиями, идущими со скоростью счета в десятки, сотни килогерц, и временные метки ставят с точностью в наносекунды. Не пугайте меня сложностью и немыслимой дороговизной непрерывной записи сигнала с датчика вибрации, може дело просто в психологии каменнного века?

Уважаемый Добряк, ни на йоту не сомневаюсь, что и в ядерной физике и в военных системах существуют системы регистрации событий с очень высокой дискретностью. Я всего лишь попытался показать как обстоит дело с обыкновенными промышленными производствами.
И потом - складывается впечатление, что Вы не поняли основную мысль моего предудущего поста. В вашей области и в военной такие системы - жизненная необходимость. А на обыкновенном предприятии их нужность возникает только в случае форсмажорных обстоятельств. И в глазах любого руководителя выглядят как цацка или ненужная роскошь.
И не говорите мне, что система регистрации с наносекундной дискретностью стоит дёшево...

PS И ещё - вопрос на засыпку... Если вы ходили по ссылке, которую я привёл в предыдущем посте... Там речь идёт о КоАЭС. Внимание, вопрос - отчего же ядерные энергетики всё-таки городят сложные и дорогостоящие системы, если (Ц) "в ядерной физике и физике высоких энергий уже десятилетия работают с  сложными событиями, идущими со скоростью счета в десятки, сотни килогерц, и временные метки ставят с точностью в наносекунды." Области как будто смежные...

Цитата: icethed от 08.10.2009 23:31:48
Про буферную память... Имеется ввиду, что обычная СУБД (система управления базами данных), например MS SQL Server 2000 физически не может сохранять данные чаще, чем 1 раз в секунду. Для вялотекущих процессов этого вполне достаточно. А вот для быстрых процессов (электрических или механических - таких как вибрация и скорость вращения быстроходных машин) требуется гораздо большее быстродействие.

Насчет жутко дорого стоит, это Вы загнули. Жутко за дорого предлагают, но грамотный ЗАКАЗЧИК всегда может привести в чувство и к реальным ценам. (Я нахожусь со стороны тех кто "предлагает".)
При проектировании системы АСУ ТП, на современном оборудовании,  нет особых проблем в получении и хранении логов. Запись истории событий важна всегда, а не только при таких ЧП. По ней происходит разбор полетов и грамотности работы персонала.  
Кстати причем здесь быстродействие СУБД? Вам важно быстродействие контролера, объем памяти для хранения событий, канал связи до сервера хранения событий, и сервер хранения событий вынесеный за пределы зоны опасности, на котором установлена система сбора информации с контролеров. (Так в кратце). Как ее потом будите обрабатывать, и с помощью какой СУБД дело второе.
-----------------------------------------
Приведу пример: Наша предприятие проектировало и внедрило систему в которой как элемент была АСУ-ТП КНС (кустовая насосная станция). Вот было два ЧП связаных с разрушением подшипника двигателя, которое приводило к биению, а затем к его разрушению. Как следствие маховик летал по всей станции и разносил ее к чертям собачьим, благо диспетчерская находилась в другом здании и жертв не было. Заказчик естественно собирал комиссию и начинал задавать вопросы, а почему АСУТП не сработало? Понятно, что для нас это было критично, если виновато АСУТП то все убытки за наш счет. Комисия состояла из представителей Заказчика, Подрядчика и Технадзора.Анализ логов показал что АСУТП не причем. На момент разрушения,  который был зафиксирован КИП (появилось биение, росла температура, нережимное изменение оборотов) система АСУТП дала сигнал на останов двигателя, но случилось следующие. Когда сигнал дошел до управляющих автоматов, срабатывание не произошло - залип геркон (50х годов выпуска ???). Кто-то у Заказчика с экономил на копейках, как результат потерял миллионы. Но АСУТП сработала штатно и претензий к нам не было. (Мощность движка не помню, обычно стоят на 6кВ, мощностью 800, 1250 и 1600 кВт., вот какой-то из них).
-------------------------------------------

По СШГЭС
Вот почему логи не собирали мне непонятно? А если собирали, но хранили в помещении машзала непонятней еще, ведь были аварии с затопленим. Хотя для этой аварии-катастрофы особой роли не играет.

Цитата: AndreyK от 09.10.2009 10:58:37

skipped
-------------------------------------------

Имею, что сказать по Вашему посту, да боюсь, что забанят модераторы, ибо оффтоп... Если Добряк сочтёт нужным высказать своё мнение относительно продолжения данной темы, буду исходить из его мнения.

Цитата: icethed от 09.10.2009 09:56:16
. А на обыкновенном предприятии их нужность возникает только в случае форсмажорных обстоятельств. И в глазах любого руководителя выглядят как цацка или ненужная роскошь.

СШГЭС - обыкновенное предприятие. (!?)
Согласно нормам ПТБ  и ПТЭ, СШГЭС - предприятие опасного производства  стратегического значения.

Цитата: 753 от 09.10.2009 12:18:12
СШГЭС - обыкновенное предприятие. (!?)
Согласно нормам ПТБ  и ПТЭ, СШГЭС - предприятие опасного производства  стратегического значения.

Об этом и была речь, что рыжий снял с ГЭС статус опасных объектов...

Цитата: finereader от 09.10.2009 12:22:26
Об этом и была речь, что рыжий снял с ГЭС статус опасных объектов...

Привидите нам этот документ.
Зато у нас есть акт комиссии (тоже документ), где черным по белому сказано, что СШГЭС - опасное предприятие, федерального значения (а значит стратегического).
И там же в акте сказано, что РАО ЕЭС штамповала ненормативные документы.

Цитата: Dobryak
Давайте по частям:

я говорил о системах регистрации в режиме реального времени. Для анналов истории и для прокурора. Для этого на один ГА СШ АЭС было бы достаточно одной корзины (крэйта) на допотопном САМАС и одной персоналки, даже Fastbus следующего поколения был бы избыточен.  Ничтоже сумнящеся, я даже 15 килодолларов  (с дублированием) на один ГА не вижу: о стоимости собственно датчиков молчу. Современное поколение студентов в ядерной физике уже не узнает никогда ничего о вымерших динозаврах по кличке САМАС и Fastbus. Ваши слова я воспринимаю исключительно как свидетельское показание: в энргетике все в каменном веке, на мечущейся по экрану стрелке осциллографа по Латыниной.

А вот АСУ ТП на АЭС совсем другая песня, так как в ней ключевое слово не регистрация ,  [/b] а управление.   [/b]

Ненене! Тут все не так просто. На контроллере управления (который ПТК ЭГР и ПТК АУГ) как раз весь кратковременный архив лежит с миллисекундной точностью, как это и указано в ТЗ и в нормативных документах. Но тут какое дело - структура АСУ ТП подразумевает иерархичность: ПТК (нижнего/технологического уровня)-сервер энергоблока (2 гидроагрегата+1 трансформатор)-сервер АСУ ТП. И сервер энергоблока понятное дело на энергоблоке и обитает. Так вот все данные с миллисекундной точностью хранятся на контроллерах ПТК. Далее транслируются на сервер энергоблока (с какой-то там периодичностью), допустим раз в секунду, и уже оттуда еще реже транслируются на сервера АСУ ТП. При аварии смыло как контроллер, так и сервер энергоблока, поэтому часть данных вообще не попала в уцелевший сервер. И скажу больше, в приведенной вами системе было бы точно также.

Цитата: грейпфрут от 09.10.2009 13:07:56
При аварии смыло как контроллер, так и сервер энергоблока, поэтому часть данных вообще не попала в уцелевший сервер. И скажу больше, в приведенной вами системе было бы точно также.

Даже, если это будет черный ящик или блок  системы  IP  ?  ???

Цитата: 753 от 09.10.2009 13:15:56
Даже, если это будет черный ящик или блок  системы  IP  ?  ???

Шутку я оценил, но сами понимаете - сейчас таких требований нет. Чисто принципиально - да в таком случае данные остались бы на контроллере и были бы найдены и интерпретированы. Будут требования - будем делать так и никак иначе.
Более того - на ГЭС (в частности на Загорской, думаю что и на Саянах) есть специальная система регистрации аварийных событий, так называемая РАС. Это все придумано было еще в Советском Союзе, и всилу этого в нее заводятся лишь дискретные сигналы, в том числе по превышению нормативных параметров, то есть без всяких там анализов спектров и других гармонических изысков. Скажут - сделаем, будьте уверены.