Критические ошибки проектирования АСУ ТП и программирования ПЛК
В промышленности внедряются автоматизированные системы управления технологическим процессом (АСУ ТП) на промышленных программируемых логических контроллерах (ПЛК) на объектах модернизации. Вновь поставляемое оборудование, уже по умолчанию содержит АСУ на ПЛК. Но качество проектирования АСУ ТП и программирования ПЛК иногда не соответствует логике и требований к надежной защите управляемого объекта. В этой статье я расскажу о типичной ошибке проектирования и программирования обычного промышленного оборудования.
Введение
Рассмотрим типичный объект, содержащий АСУ на ПЛК в промышленности. В горнообрабатывающей отрасли, на обогатительных фабриках (ОФ) на стадии измельчения полезных ископаемых (руды) применяются различного типа мельницы. Они бывают шаровые, стержневые, вертикальные тонкого измельчения и т.д. Основной функцией данных мельниц является измельчения руды до фракции необходимой в дальнейшем для химического извлечения полезного ископаемого. У такого оборудования есть свои слабые места в процессе эксплуатации. Победитовые коренные подшипники, редуктора и т.д. Они требуют к себе постоянного контроля температуры, наличия смазки и т.д. В случае перегрева или сухого хода АСУ должна отключить агрегат, пока состояние узлов не достигло критической точки. Программные реализации данных защит и блокировок типичны и стандартны для такого рода оборудования.
Какие бывают ошибки?
Давайте рассмотрим две основные ошибки при проектировании и программировании АСУ для оборудования такого типа. Первая ошибка — неправильное проектирование релейной части управления главного привода или критичного механизма. Вторая ошибка — недостаток программы в части обработки фатальных ошибок ПЛК.
Ошибки в схемах.
Рассмотрим случай с релейной частью. На рисунке приведен пример такой ошибки. В схеме показана только часть управления отключения главного привода оборудования.
На первый взгляд обычная релейная схема. Но если присмотреться к ней, то можно определить, что рано или поздно наступит такой момент, когда релейная схема не сможет отключить главный привод в случае возникновения аварийной ситуации. Присмотримся к схеме. Отключение главного привода осуществляется ПЛК дискретным выходом. В данной схеме он релейный, но может быть и транзисторным, суть от этого не поменяется. Так вот, если по какой то причине катушка реле К1 сгорит во время работы оборудования, то при возникновении аварии, контроллер даст сигнал на отключение главного привода, но сигнал дальше сгоревшей катушки реле не пойдет. Но ведь по технологии, при отключении главного привода, требуется и отключение вспомогательного оборудования, в данном случае это маслонасос. Так вод при аварии, маслонасос будет благополучно отключен, а главный привод останется молотить на «сухую». Благо система ко всему еще и оповещение включит, так, что противно кричащий звонок и моргающая красная лампа привлекут к себе внимание обслуживающего персонала и «катастрофы» не произойдет. После этого, местные электрики или КИПовцы, найдут причину сего безобразия, поменяют реле и все станет на свои места, быть может, кто нибудь и задумается, как этого избежать в будущем, но врядли.
Так что в этой схеме реле К1 слабое звено. Что можно сделать чтоб такого не случилось. Элементарно. Сигнал отключения ВВ посадить на нормально-закрытый контакт реле К1, а само реле притягивать во время пуска главного привода и в рабочем состоянии удерживать его притянутым. Кстати, кнопку аварийный стоп, тоже так включать не стоит. Либо контакты кнопки должны непосредственно отключать исполнительный механизм, либо, если таких механизмов несколько, разрывать цепь реле, контакты которого уже отключают исполнительные механизмы. Кстати, такое включение промежуточных реле управления критичными исполнительными механизмами рождает и ошибочную отработку при ошибках программирования ПЛК.
Ошибки программирования ПЛК.
При программировании ПЛК, некоторые программисты допускают ошибки, приводящие к аварийным ситуациям на производстве.
Недавно мне пришлось столкнуться с такой ситуацией. Схема релейной части отключения главного привода была такой как представлено выше. Ошибка при программировании привела к тому, что главный привод работал на «сухую» четыре часа, что привело к перегреву редуктора. В результате редуктор полностью вышел из строя, а это в данном оборудовании дорогостоящий элемент. Что же пошло не так?
При выявлении причины аварии, приведшей к большим материальным затратам, было установлено, что ПЛК перешел в режим «СТОП» по причине срабатывания сторожевого таймера. Соответственно, релейная схема отключила всё вспомогательное оборудование, кроме главного привода. Сторожевой таймер сработал по причине наличия тупиковой ветки в алгоритме, не приводящей к зацикливанию главной функции. А как известно, почти у всех фирм производящих ПЛК, переход ПЛК в режим «СТОП», сопровождается установкой дискретных выходов в безопасное состояние. В данном случае в состояние отключено. В данной АСУ программист совершил две ошибки:
- Разветвленный алгоритм имел тупиковую ветку, приведшую к срабатыванию сторожевого таймера.
- Обработка исключений в программе не производилась, тем самым ПЛК перешел в режим «СТОП».
Первую ошибку спишем на сложность программы, в которой трудно найти такого вида ошибку.
Вторую ошибку, списать можно только на отсутствие компетенции программиста.
Как известно, многие ПЛК имеют программные модули для отработки различных фатальных ошибок ПЛК. Рассмотрим такие модули на примере ПЛК от фирмы сименс.
Вот небольшой пример такой ошибки.
Здесь программист производит линеаризацию аналогового входа на основе библиотечной функции FC105. В основном цикле по включению бита М0.1 происходит масштабирование аналогового сигнала. Все бы хорошо, но если в ПЛК не загрузить тот самый FC105, то при выполнении данной строчки, ПЛК вывалится в «СТОП SF» если не задать обработчик программных ошибок, так называемый OB121. Если такой обработчик залит в ПЛК, то при таких ошибках индикация SF появится, но ПЛК в режим «СТОП» не уйдет, и продолжит выполнять пользовательскую программу.
Подведем итоги
Релейную схему необходимо проектировать так, что бы в любой аварийной ситуации, будь то технологическая авария или ошибка ПЛК, отключение исполнительных механизмов проводилось в обязательном порядке не зависимо от рода возникновения аварии. Подходить к программированию ПЛК со всей ответственностью, ведь оборудование, которое призвано защитить АСУ ТП от критичных условий эксплуатации, приводящим к разрушению механизмов, намного дороже самой АСУ.
В данной схеме необходимо было использовать следующее включение компонентов релейной схемы.
А в программном модуле OB121, выполнять какие-нибудь действия по архивированию случившегося отказа в ПЛК.
Видео, показывающее поведения ПЛК при программных ошибках и их обработках представлено ниже.
Вывод
Схемное решение и программные реализации таят в себе не редко глубокие ошибки, которые не всегда выявляются на стадии пусковой наладке. В процессе эксплуатации не всегда специалисты предприятия проводят полный проверочный комплекс надежности системы. К тому же обслуживающему персоналу очень часто не хватает квалификации. Будем надеяться, что таких аварийных ситуаций будет ничтожно мало, и они не будут приводить к травмам на производстве.
P.S.
Оставлять просто пустые программные блоки обработки аппаратных или программных ошибок тоже не стоит. В них необходимо выполнять какие либо действия на детектирование таких ошибок или для сбора статистики отказов ПЛК и возможных причин.
