Аварийный останов при отказе САУ: нормативы, стандарты.

[dima154]

Может кто подскажет, каким документом определяется необходимость выполнения аварийного останова при отказе САУ?
Например, имеется САУ компрессорного цеха (КЦ, сжатие газа), при отказе которой (зависании/поломки контроллера) аварийный останов КЦ не производится. И есть САУ газоперекачивающего агрегата (САУ ГПА), при отказе контроллера которой производится аварийный останов ГПА.
Так вот, вопрос в том есть ли какие-то нормативные документы, в которых описаны требования к поведению САУ при ее полном отказе?

[Jackson]

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

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

Вот и стройте систему так, чтобы выполнить Ваши нормативы по ГПА и проектную текстовую часть, и ТЗ.

[Ryzhij]

Только проектировщики техпроцесса могут установить требуемое время диагностики и реакции защит.
Процесс процессу рознь.

[dima154]

А все системы должны быть такими, чтобы любой единичный отказ в любой из систем не оказывал влияния на работу других систем.

Вот это положение хорошо объясняет причину отсутствия АО в нашей САУ КЦ, т.к. отказ ПЛК САУ КЦ не должен повлиять на работу технологического оборудования всей КЦ в целом. В нашем ТЗ есть слова про, то что системы должны работать независимо друг от друга в плане отказоустойчивости. Большое спасибо за консультацию!

[ASUTP_PLC]

Независимо помоему громко сказано. В ТП использовался компрессор системы вентиляции. К нему шел вентилятор.
Вентилятор обдува. Этот вентилятор встал с ошибкой. А компрессор - абсолютно независимо, как работал так и работал.
И в результате - тоже умер. Этот пример помоему хорошо показывает, что взаимные блокировки тоже должны быть.

[Jackson]

т.к. отказ ПЛК САУ КЦ не должен повлиять на работу технологического оборудования всей КЦ в целом

Отказ всего ПЛК сразу - это не единичный отказ, вообще-то.

[Ryzhij]

Отказ всего ПЛК сразу - это не единичный отказ, вообще-то.

Ну, почему же, очень даже может быть. Особенно, когда блок питания нерезервирован.
Тогда только на пассивную безопасность вся надежда...

[Jackson]

Не может. Еди6ичний отказ - это гостированное определение.

Отправлено спустя 29 минут 3 секунды:
Хотя, я признаю, что оперделение это в разных ноомативах звучит по-разному, а нередко и вовсе отсутствует. Но результат отказа ПЛК - это уже не единичный отказ, а отказ всего агрегата.

[Ryzhij]

Отказ одного агрегата в технологической цепочке, даже если на нем, не один, а три контроллера, это всё равно единичный отказ.
Например, таким будет отказ всего агрегата - циркуляционного турбокомпрессора.
Мы же сейчас говорим о системе безопасности - именно там применяется термин единичный отказ (single failure): Отказ, который приводит к потере способности системы или элемента выполнять предписанные им функции безопасности, а также любые последующие отказы, являющиеся результатом этого.
Система безопасности должна быть устойчива к таким единичным отказам.

[Михайло]

Только проектировщики техпроцесса могут установить требуемое время диагностики и реакции защит.
Процесс процессу рознь.

Немного добавлю. В процессе разработки проектировщик исходит из анализа рисков в конкретном технологическом процессе. Так как технологические процессы различны, то и состав рисков различен применяются различные технические решения, в частности различные решения по аварийному останову.
Универсальных решений нет, хотя иногда можно встретить стандарты на некоторые стандартные установки, где всё расписано. Но это редко.

Анализ рисков. Проектировщик обязан провести анализ рисков. Иными словами, он должен понять, а что может произойти такое, что в итоге приведёт:
1. К травмам и смертельным исходам.
2. К нарушениям экологии.
3. К поломкам оборудования.

Проектировщик должен доработать свою установку системами безопасности и аварийного останова для предотвращения пунктов 1, 2, 3. Риски должны быть устранены на всём жизненном цикле установки: в процессе ПНР, в процессе эксплуатации и в процессе утилизации.

То есть вместо универсального стандарта предлагается подумать головой самому.

ПРИ ЭТОМ! Забудьте об отказоустойчивости, так как это может противоречить требованиям безопасности. В первую очередь, вы должны обеспечить безопасность, а удобства функционирования - это уже вторично.

[Ryzhij]

Забудьте об отказоустойчивости, так как это может противоречить требованиям безопасности. В первую очередь, вы должны обеспечить безопасность, а удобства функционирования - это уже вторично.

Опять упираемся в терминологию.
Об отказоустойчивости в отношении ЧЕГО нам предлагается забыть?
Отказоустойчивость - способность системы выполнять свои функции при отказах.
Если речь про отказоустойчивость системы ПАЗ, это одно, если речь про обеспечение непрерывности техпроцесса, это несколько иное.

Фёдоров справедливо замечает, что останов крупнотоннажного производства на ОПО уже сама по себе опасная ситуация, и, возможно поэтому, в новых федеральных правилах появилось требование рассчёта вероятности ложного срабатывания СПАЗ, т.е. вероятности т.н. "безопасного" отказа.

[Михайло]

Согласно требованиям безопасности нужно обеспечивать отказобезопасность, а может и не нужно. Чтобы определиться надо или не надо, нужно проводить анализ рисков.

С терминологией достаточно просто: отказобезопасность = отказоустойчивость ПАЗ.

Нужно ли обеспечивать отказоустойчивость основного техпроцесса - это вопрос к разработчику. Если он видит в этом риск... Всё в конечном итоге упирается в риск, риск должен быть снижен до приемлемого уровня в процессе итеративной разработки. Совершенно непонятно, на кой хрен при этом требовать рассчитывать ложные срабатывания. Ложные срабатывания - это не то, над чем следует париться. При ложных и неложных срабатываниях система должна оставаться в безопасном состоянии, а не как у Фёдорова - речь про какие-то непокрытые риски.
НО! Всё же я считаю, что вероятность ложных срабатываний нужно понижать, так как в любой АСУ это порождает риск намеренного отключения ПАЗ. Хочу обратить внимание, что данный риск относится к социально-экономическим, а не к техническим как у Фёдорова.

[Ryzhij]

Если помните, Фёдоров приводил пример с ложным срабатыванием ПАЗ критикуя понятие "безопасного отказа" в семействе стандартов, посвящённых полноте функциональной безопасности.

[Михайло]

Я не помню и не знаю.

[Ryzhij]

Ложные срабатывания - это не то, над чем следует париться.

Закон суров, но это Закон, - говаривали ещё в Риме.
Федеральные Правила писаны для того, чтобы их обязательно исполняли, причем исполняли даже непонимая.
Наше мнение в этой ситуации никого не интересует.

[Jackson]

Согласно требованиям безопасности нужно обеспечивать отказобезопасность, а может и не нужно.

Странно как-то. Так нужно или не нужно?

Мне кажется, сказанное настолько очевидно, что тут и мусолить нечего.
Установка не должна нести вред ни окр.среде ни людям ни экономике. Любая установка строится так, чтобы риск такого вреда был минимален. Это достигается частично за счет выполнения соответствующей НТД, оставшаяся часть - за счёт головы разработчиков (ибо инженерами они названы не для галочки а чтобы думали).

И о чём тут говорить-то? Неужели кто-то хочет с этим поспорить?

Нет такого термина или определения - "отказобезопасность". Нет за не надобностью, как нет в уголовном кодексе нигде определения "смерть".

Если помните, Фёдоров приводил пример с ложным срабатыванием ПАЗ критикуя понятие "безопасного отказа" в семействе стандартов, посвящённых полноте функциональной безопасности.

Есть "понятие" а есть "пример". Это разные вещи.