Установки с блоками III категории взрывоопасности. Проектирование раздельных РСУ и ПАЗ

Установки с блоками III категории взрывоопасности. Проектирование раздельных РСУ и ПАЗ
Количество просмотров - 2574 (ссылка на эту тему)

Pyromaniac 92

Активный участник форумов

Сейчас отсутствует

Сообщение #1 : 11 Мая 2021 года, 14:31
(ссылка на это сообщение)

Добрый день! Прошу поделится опытом и мыслями.
Предусматриваете ли вы отдельные системы РСУ и ПАЗ для установок с блоками 3 категории?
П. 230 ФНиП ОПВ обязывает отдельные системы РСУ и ПАЗ вне зависимости от категории блока:
"Системы ПАЗ функционируют независимо от системы управления технологическим процессом. Нарушение работы системы управления не должно влиять на работу системы ПАЗ. Сети обмена информации между элементами системы ПАЗ должны быть отдельными от сетей обмена информацией между элементами других систем АСУТП."
П. 249 дает какие то вроде послабления, а вроде и ужесточения:
" Технические решения по обеспечению надежности контроля параметров, имеющие критические значения, на объектах с технологическими блоками III категории взрывобезопасности обосновываются разработчиками проектной документации"

Инженер-технолог (?, Россия)

Антониони

Активный участник форумов

Сейчас отсутствует

Сообщение #2 : 12 Мая 2021 года, 09:01
(ссылка на это сообщение)

А можно пример такой установки?
Мы всегда предусматриваем разделение, но я не помню у нас установок 3 категории. В основном у нас 1 категория, иногда 2.
Еще зависит от количества точек контроля. Если взять канализационную насосную (КНС), то там насосы (которые обычно в ПАЗ) и уровень по которому насосы срабатывают. Поэтому если и есть пара сигналов РСУ, то проще их в ПАЗ засунуть и не выполнять две системы.
Или наоборот - куча сигналов РСУ и один ПАЗ. Проще поставить реле, которое напрямую выключало бы что-то и все. И при этом не городить отдельную систему. Хотя таких установок у нас не было ни разу.

Проектировщик КИП (Самара, Россия)

Ixion

Активный участник форумов

Сейчас отсутствует

Сообщение #3 : 12 Мая 2021 года, 22:55
(ссылка на это сообщение)

Действительно, хотелось бы пример.
У нас блоков 3-ей категории встречается достаточно много -- да чуть ли не половина из всех проектируемых объектов. Но именно блоков -- как составных частей более крупных объектов: установок, рез. парков, ж/д эстакад, пунктов автоналива и пр. И в составе этих объектов есть, как правило, блоки 1-ой и/или 2-ой категории. Так как системы ПАЗ и РСУ общие на всю установку, то "правила игры" определяет блок 1-ой или 2-ой категории. Так, чтобы был обособленный объект с собственной независимой АСУ, да при этом 3-ей категории -- так и не припомню, встречался ли в практике. Но могу сказать, что проектировали бы отдельные РСУ и ПАЗ, причины следующие:
1. Какая АСУ (на ПЛК, только ПАЗ или независимо ПАЗ+РСУ) нужно определяться почти сразу, а технолог энергетические потенциалы может посчитать и через месяц, и через два... И не факт, что когда технолог посчитает наконец-таки, то будет 3-я категория. И еще есть вероятность, что в ходе проектирования поступят какие-то уточненные данные и по уточненным расчетам 3-я категория превратится во 2-ю (например, площадь каре рез. парка увеличилась). Эти расчеты достаточно мутные, можно по разному насчитать. Не редки случаи, когда результат расчета зависит от пола, возраста, опыта, настроения (нужное подчеркнуть) расчетчика... А еще есть вероятность последующей реконструкции/техперевооружения, и тот проектировщик вспомнит недобрым словом разработчика оригинального проекта, решившего "сэкономить" таким сомнительным способом.
2. П. 249 ФНиПа не отменяет п. 230. "Первое. Клиент всегда прав. Второе. Если клиент не прав, то смотри пункт один" -- так и здесь. Где в п. 249 написано, что можно объединять РСУ и ПАЗ? Инспектор Ростехнадзора, эксперт экспертизы, любой проверяющий -- он по умолчанию тупой, ему чужда логика, здравый смысл. Я утрирую, но представим это так. Он понимает только одно: то, что написано в его Библии (т.е. в ФНиПе, СП, ФЗ и пр..). При этом он может понимать нормативное требование в самой извращенной форме. И раз такое толкование нормативного требования возникло, как минимум, в одной голове, т.е. его, то оно может возникнуть и в другой и третьей, т.е. имеет право на жизнь. Пытаться как-то с вашей стороны иначе перевести смысл требования, его растолковать, воззвать к здравым рассуждениям, понимаю появления этого требования -- все может быть тщетно. Рассмотрим п. 230 ФНиПа, написано "Системы ПАЗ функционируют независимо от системы управления технологическим процессом. Нарушение работы системы управления не должно влиять на работу системы ПАЗ". В этом пункте постулируется наличие системы ПАЗ и некой "системы управления технологическим процессом". И если одной из этих систем не будет -- это уже может расцениваться как нарушение ФНиПа. Даже если вы управление единственного насоса реализовали через ПАЗ, чтобы для этого не городить отдельную систему под названием РСУ. С другой стороны, система ПАЗ уже так глубокого в головах инспекторов, экспертов, да и проектировщиков ассоциируется с автоматикой, то уже многие не могут понять и принять такой факт, что к системе ПАЗ могут относиться "неАСУшные" компоненты, например, предохранительные клапаны, разрывные мембраны -- т.е. исключительно механические средства. Мало того, может быть система ПАЗ полностью неавтоматизированная, ну на пример, только состоящая из блока СППК. Попробуй докажи, что вот она: мая система ПАЗ!
3. В нашей практике было, что предшествующие проектировщики использовали датчики ПАЗ для работы РСУ, часто вешали действия дискретного дистанционного управления (например, включить/отключить насос, открыть/закрыть задвижку) на СПАЗ, либо передавали сигнал из СПАЗ в РСУ (но не наоборот). И вроде бы ФНиПы (тогда еще ПБ старые) не нарушали: СПАЗ имела приоритет над АСУТП, нарушение работы АСУТП не вело к снижению функциональности ПАЗ. Связь СПАЗ и РСУ была, но односторонняя: передача сигнала была из ПАЗ в РСУ, а не наоборот. Но требования менялись, игра "на тоненького" в конце концов проиграна, так как появилась фраза "Сети обмена информации между элементами системы ПАЗ должны быть отдельными от сетей обмена информацией между элементами других систем АСУТП". Если бы тот проектировщик 10-летней давности не играл в игру компромиссов и полумер, а поступал бы топорно, то сейчас проще было бы реконструкции проводить и не боятся, что опять какая-нибудь хрень "всплывет".
4. П. 249 ФНиПа: "Технические решения по обеспечению надежности контроля параметров, имеющие критические значения, на объектах с технологическими блоками III категории взрывобезопасности обосновываются разработчиками проектной документации". А скажите, господа, что не обосновывается проектной документацией? Технические решения по обеспечению надежности контроля параметров на объектах с технологическими блоками I или II категории взрывобезопасности? Нет же, тоже обосновываются. Да все технические решения должны обосновываться проектной документацией! Прямо: т.е. по тексту или на графике в составе проектной документации, либо косвенно: в виде ответа на замечание эксперта. То, что написано в п. 249 -- это фраза-заглушка. Раньше здесь было дельное требование. Но потом по какой-либо причине оно стало чему-то или кому-то мешающим. Но у авторов ФНиПа не хватила ума, чтобы ее переделать, не хватило смелости, чтобы удалить вовсе. А хватило их лишь на то, чтобы перевесить ответственность за решение на проектировщика, иными словами: уйти от ответственности за данное нормативное требование. Но спасибо и на этом: это, вероятно, все же лучше, чем то, что было написано в прежней редакции ФНиПа.

Антониони

Активный участник форумов

Сейчас отсутствует

Сообщение #4 : 12 Мая 2021 года, 23:55
(ссылка на это сообщение)

а) ПАЗ может быть и без РСУ как в нашем примере с насосом. И не прикопается эксперт, потому что системы ПАЗ более надежные (дублирование оборудования) - мы лишь усилили защиту. Но тут дело в другом - нет таких объектов. Есть мелкие типа КНС, но если КНС выйдет из строя, то авария будет заключаться в .. в чем? Вот именно, ничего страшного не случится. Если эе насос будет качать бензин - тут уже возможны варианты. Но я ни разу не встречал одинокий бензиновый насос. Так что замена ПАЗом сразу и ПАЗ и РСУ это дико частный случай.
б) все что нарушает ФНиП может быть легко описано в обосновании безопасности. Если в этом документе приведете все данные по возможным авариям, расчеты вероятности и последствий, укажете имеющиеся средства защиты и обоснуете их достаточность, то этого вполне будет достаточно эксперту. Вот именно это и есть п.249 ФНиП. Эксперт даже согласится с курением у резервуара с пропаном если все расчеты и мероприятия на предприятии сделают это курение безопасным. Я пару раз видел подобные обоснования - это жесть! Например обоснование отсутствия ПАЗ вообще наличием отсекающих устройств с безопасным положением. То есть при аварии все клапаны закрываются и все - никакой аварии и контроллер ПАЗ не нужен вообще. Не знаю прошли ли экспертизу с таким "ноу хау", но как говорится " а на хау нам это ноу?"

Проектировщик КИП (Самара, Россия)

Ixion

Активный участник форумов

Сейчас отсутствует

Сообщение #5 : 13 Мая 2021 года, 01:20
(ссылка на это сообщение)

Цитата: Антониони от 12 Мая 2021 года, 23:55

ПАЗ может быть и без РСУ как в нашем примере с насосом. И не прикопается эксперт, потому что системы ПАЗ более надежные

Я бы не был так уверен. Во ФНиПе говорится о "системе управления технологическим процессом". Где она? Аа... нету! Чем не замечание? Но стоит отметить, что многое зависит от эксперта: вдруг адекватный попадется... или не не испорченный еще стажем работы.

Цитата: Антониони от 12 Мая 2021 года, 23:55

все что нарушает ФНиП может быть легко описано в обосновании безопасности... Я пару раз видел подобные обоснования - это жесть!

"Легко" в кавычки нужно. Да, это действительно жесть. И самое главное, что никто (ни вы как разработчик, не эксперт) не знает меру достаточности аргументов и мероприятий по обоснованию этой безопасности. Опять же конечная задача: переложить ответственность за решение с ваших плеч проектировщика и с плеч эксперта или нормотворца на плечи того парня, который этот томик обоснования безопасности разработал.

Foxson

Активный участник форумов

Сейчас отсутствует

Сообщение #6 : 13 Мая 2021 года, 05:51
(ссылка на это сообщение)

Если не вдаваться в специфику отрасли и аббревиатуры, то речь идёт о системе управления (регулирования) тех процессом и системе защиты. Эти системы всегда выполняются раздельно, независимо от отрасли и категории блока. Неисправность или временное отключение любого элемента системы управления не должна ни как влиять на работоспособность системы защиты (начиная с уровня энергоснабжения систем).
Другое дело, что не каждый тех процесс требует одновременно обе системы или вообще какой либо из систем.
П. 249 вообще ни каких "послаблений" о возможности объединения систем не даёт - речь идёт там только об обеспечении надёжности входных сигналов. На уровне контроля входных сигналов системы управления и защиты не объединяют.

Монтажник (Челябинск, Россия)

Pyromaniac 92

Активный участник форумов

Сейчас отсутствует

Сообщение #7 : 14 Мая 2021 года, 15:20
(ссылка на это сообщение)

Пример простой - есть небольшая установка получения водорода электролизом воды. Все блоки входящие в состав установки имеют 3 категорию. Раньше, когда во ФНиП не указывалось, что категории блоков и вытекающее из этого не требуются для складов нефти и нефтепродуктов систему РСУ и ПАЗ мы реализовывали на общем контроллере. От экспертизы вопросов не было.

Инженер-технолог (?, Россия)

В-и-к-т-о-р

Участник форумов

Сейчас отсутствует

Сообщение #8 : 21 Мая 2021 года, 16:24
(ссылка на это сообщение)

Добрый день.
Для если на установки только блоки 3 категории деление на РСУ и ПАЗ излишне.
Приказ Ростехнадзора от 15.12.2020 № 533
35. Производства, имеющие в своем составе технологические блоки III категории взрывоопасности, оснащаются системами автоматического (с применением вычислительной техники или без нее) регулирования, средствами контроля параметров, значения которых определяют взрывоопасность процесса, эффективными быстродействующими системами, обеспечивающими приведение технологических параметров к регламентированным значениям или остановке процесса.

Технолог (Казань, Россия)

Pyromaniac 92

Активный участник форумов

Сейчас отсутствует

Сообщение #9 : 24 Мая 2021 года, 11:51
(ссылка на это сообщение)

Спасибо за ответы!

Инженер-технолог (?, Россия)

УЦ РЕСУРС

Активный участник форумов

Сейчас отсутствует

Сообщение #10 : 03 Июля 2022 года, 05:10
(ссылка на это сообщение)

Цитата: Pyromaniac 92 от 24 Мая 2021 года, 11:51

Спасибо за ответы!

Делаем выводы из дискуссии:
1. Обоснование безопасности это часто просто трюк. чтобы пройти экспертизу ПД.
2. критерий должен быть один и это анализ расков с демонстрацией отсутствия неприемлемых рисков
3. экспертиза должна убедиться что пд. все техн устройства соответствуют нтД РФ плюс что анализ рисков сделан и риски неприемлемых уровней отсутствуют
3,1 к сожалению. часто эксперты не владеют методиками анализа рисков, как и то кто обосновывает ПБ. что приводит к формальному подходу экспертизы и если авария произойдет все таки. чтобы был виновник. В данной ситуации это будет тот кто обосновывал ПБ.

Инженер (Уфа, Россия)

УЦ РЕСУРС

Активный участник форумов

Сейчас отсутствует

Сообщение #11 : 04 Марта 2023 года, 12:19
(ссылка на это сообщение)

Это все рассуждения ловкачей пытающихся уменьшить объем работ.
Чем обоснованы эти рассуждения?
1.Невнятностью формулировок наших норм.
2. Отсутствием четких требований к установкам различных категорий.
3. Начисто отсутствие риск ориентированного ПИР, где единственным критерием является отсутствие неприемлемых рисков.
4. Деление на приемлемые и неприемлемые риски делается на основе матицы рисков или таблицы целевых рисков в зависимости от тяжести последствий сценария или сценариев с одними и теме же последствиями.
4.1. Матицы рисков или таблицы целевых рисков должны создать сами компании. Здесь есть трудности, так как на гос уровне отсутствуют критерии допустимых рисков в зависимости от категории объекта.
4.2 А чего тут сложного, если каждому блоку в зависимости от категории дать целевой риск в виде вероятности приемлемости для здоровья, ОС, активов....и все стало бы на свои места.
5. Т.е. Анализ и управление рисками не делается часто вообще, особенно в малых предприятиях, потому как система управление ПИР не имеет такого руководства как анализ рисков.
6. Отсутствует система управления ПИР, как у иностранцев, где расписано по азам когда делается грубый ХАЗОП, когда детальный, когда определяются риски и СИЛ ПАЗ и все это в обязательном порядке.
6.1 на этапе ТЭО делается грубый ХАЗОП и даются рекомендации и по ПАЗ и по АСУ и по сигнализации и по ПИР и т.д. с целью учитывающих будущий анализ рисков, с тем чтобы не допустить неприемлемых рисков и не перепроектировать, если риски будут неприемлемые. Будучи ГИПом хорошая практика на грубом ХАЗОПе сразу дать рекомендации, чтобы ПАЗ и АСУ и сигнализация и ПИР были НСЗ и даже уже определить уровень СИЛ ПАЗ. Это реально. Т.е. на этапе ТЭО или фазы проект можно определить конфигурацию ПСБ .

Инженер (Уфа, Россия)

Dinosaur

Активный участник форумов

Сейчас отсутствует

Сообщение #12 : 04 Марта 2023 года, 13:20
(ссылка на это сообщение)

Если честно, то мне трудно уловить Вашу мысль. Последний пост построен так, как будто это возражение на чье-то утверждение. Но предпоследний пост тоже Ваш. С кем Вы спорите?

? (Уфа, Россия)

УЦ РЕСУРС

Активный участник форумов

Сейчас отсутствует

Сообщение #13 : 04 Марта 2023 года, 14:14
(ссылка на это сообщение)

Цитата: Dinosaur от 04 Марта 2023 года, 13:20

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

Инженер (Уфа, Россия)

Страниц: [1] Вверх

ВЕРСИЯ ДЛЯ ПЕЧАТИ

www.proektant.org > ТЕХНОЛОГИЧЕСКИЙ ФОРУМ > Химия, нефтехимия и топливная промышленность (Куратор: Artchem) >

Контактные данные\| Партнёрская программа \| Подробная статистика
Настройка форумов © «Проектант» \| Конфиденциальность данных Powered by SMF 1.1.23 \| SMF © 2017, Simple Machines