Это обзорная статья по теме «автоматизированные системы управления технологическим процессом» (АСУ ТП). Сюда в понятной и доступной форме (надеюсь) будет сводиться теоретическая и практическая информация, которую можно использовать как для самообразования, так и для того, чтобы освежить знания перед их практическим использованием. Ссылки на уже написанные статьи активны, на ненаписанные, соответственно, будут активны когда-то позже — они ожидают появления музы у автора. Перечень статей раздела приводится ближе к концу материала и постоянно обновляется.
Если чего-то упустил, забыл и нагло проигнорировал, то пишете в комментариях.
АСУ в общем
На самом деле, если говорить про АСУ в общем, то это куда более глобальная тема. Ведь управлять можно не только оборудованием и процессами, но и людьми в рамках организации. Не зря наш старенький преподаватель по Теории автоматического управления (ТАУ) предупреждал, что даваемые им знания обязательно пригодятся нам в самых неожиданных ситуациях. Правда, не уточнял в каких именно.
Так или иначе, но конкретно здесь мы будем больше говорить про бездушные промышленные железяки, которые, однако, требуют нежной автоматизации особо внимательного подхода к управлению собой. В том плане, что иногда хрен знает, почему ничего не работает. И что хуже: совершенно непонятно, почему другое рядом работает и главное — как. Впрочем, у специалистов с опытом появляются некоторые волшебные заклинания и ритуальные предметы, которые в некоторых случаях являются чудодейственными средствами, способными запустить любой объект с пол тычка, ну если повезет. И ряд отмазок, почему ничего не получилось, тоже имеется, не без этого. «КИПовская земля» (а также фаза луны, солнечная активность) сегодня есть, а завтра нет — она такая непредсказуемая.
Концептуально в АСУ нет ничего сложного. Мы имеем некий технический объект, который должен выполнять определенную функцию, но ему постоянно что-то мешает. Пусть это будет бак с водой, используемый для смыва единовременного предоставления всего объема жидкости для нужд смежной системы. Так как вода (целевой продукт) нужна в любой момент, то подача последней в бак организуется непрерывно, а задача управления будет состоять в том, чтобы не давать ей выливаться при заполнении емкости. То есть мы должны контролировать технологический параметр состояния объекта — уровень, и в зависимости от его значения открывать или закрывать задвижку на подающем трубопроводе.
Одним словом, мы кое-что измеряем, а по результатам что-то делаем. Желательно автоматически. Хотя в реальности АСУ ТП состоит из двух функциональных подсистем, которые могут работать как по отдельности, так и совместно. Система автоматического контроля (САК) — обеспечивает только автоматическое (с нужной периодичностью) измерение технологических параметров, характеризующих процесс и далее их регистрацию. Управление остается на совести человека. Классический пример — системы диспетчеризации и учета. На один монитор сводится вся ключевая информация о потребляемых ресурсах, и диспетчер сразу видит, какой чудак, уходя с работы не выключил свет. Судьба этого чудака будет вестимо незавидна. Система автоматического регулирования (САР) обеспечивает изменение регулируемой величины (уровня, давления, температуры и т. д.) по какому-либо закону (правилу, программе, алгоритму) исходя из команды или в зависимости от измеряемых параметров. Все вместе такое называется контуром регулирования (величины). И естественно, что настоящая САР может включать их в себя немеряно.
Цели создания АСУ ТП
За автоматизацией будущее, но светлым оно будет не для всех. Любая система АСУ ТП в идеале заменяет минимум нескольких сотрудников. И если вы когда-либо видели технико-экономическое обоснование на разработку такой системы, то сокращение рабочих мест — один из экономических факторов, который обеспечивает окупаемость внедрения. Там, правда, еще про повышение производительности в общем пишут. Но тут штука какая: во-первых, брать на себя ответственность всегда страшновато, а во-вторых, совершенно нет гарантии, что повышенная производительность одного участка будет востребована всеми остальными. И по итогу не получится, как в советское время, когда зарубежная линия, бывало, включалась только раз в неделю на пару часов и полностью закрывала потребности предприятия в полуфабрикатах на следующий период.
Автоматика, если она работает правильно, исключает человеческий фактор, то есть, более безопасна. Отдельный класс систем — противоаварийная защита (ПАЗ), которая используется в составе опасных производственных объектов. Сразу оговорюсь, это дорого, а потому применяется не всегда, не везде. К таким системам особые требования: как к железу, так и к программному обеспечению. Рассказ о ПАЗ запланирован.
Это я так кратко прошелся по целям создания АСУ ТП, которая, строго говоря, может являться компонентом распределенной системы управления (РСУ). Когда много-много локальных систем управления (ЛСУ) хитрым образом объединяются в одну для управления крупным производством непрерывного цикла. Отличительная черта такой системы, она же цель создания — всеми способами не дать незапланированно прервать процесс изготовления продукта. Ибо такое прерывание стоит ну очень-очень-очень дорого.
Распространение и внедрение АСУ ТП
Сейчас к АСУ ТП привыкли и трудно себе представить, чтобы какое-то сложное технологическое оборудование шло без обвязки. Так было не всегда и что характерно, для нашей необъятной родины — есть места, где к таким системам продолжают относиться крайне настороженно.
Беда зарыта в том, что для больших начальников старой формации АСУ ТП — это всегда темный лес, чудо-юдо дорогое, эффект, от которого вот прямо неочевидный. Вроде бы экономия есть, лампочки красиво моргают, но следить за новым хозяйством дорого. Обслуживающего специалиста в провинции фиг найдешь и платить ему надо по местным меркам много. Опять же работяги ругаются и ломают все втихаря.
Хорошо помню, как местный персонал боролся с моей системой автоматизированного контроля процесса — обрывал датчики, тыкал электродами в сенсорный экран. И сколько раз я по гарантии на предприятие катался впустую. Очень уж система мешала вводить начальство в заблуждение о фактической производительности и качестве продукта. А ведь она еще даже не регулировала процесс.
Еще есть вопрос надежности. Опять же, если система управления идет комплектно с серийным оборудованием — это один уровень надежности, но куда чаще такая система разрабатывается отдельно, еще и многими отдельными компаниями (каждая свой кусок) на разной элементной базе, да под чутким руководством заказчика. Подружить ежа с голым задом получается не всегда, да и не у всех.
Существуют сотни причин, почему АСУТП может быть крайне ненадежной штукой изначально или вести себя таковой в процессе эксплуатации. Конечно, каждый конкретный случай требуется анализировать индивидуально. Про то мы также будем говорить в статьях раздела. Благо, если все навернется практически везде система управления предполагает наличие ручного режима управления в противовес автоматическому. «Не доверяю я этой автоматике», — любил говорить наш многоопытный начальник АСУТП, запустивший сотни систем в эксплуатацию, в свое время. Сейчас тоже любит, но реже. Возраст не тот. Все-таки элементная база изменилась. Правда беда пришла откуда не ждали, случилось импортозамещение.
Очень многое зависит от технологического процесса, который надо знать хорошо до того, как начать его автоматизировать. На берегу, так сказать, чтобы потом не получилось, что продукт равномерно не поступает в рабочую зону потому, что это физически невозможно, но вы под такое уже подписались. Договариваться с физикой, знаете ли, такая себе затея.
Благо, к разным процессам предъявляются разные требования по надежности, безопасности, отказоустойчивости и т. д. А если точнее — разные процессы удобны для автоматизации по-разному. Одно дело повесить где-то в пространстве датчик температуры и завести его на терморегулятор радиатора. Совсем другое — засунуть оптический датчик куда-то под конвейер с продуктом, причем последний линзу постоянно засерает загрязняет, а пневмоочистка срабатывает через раз. Или вот ставишь первичный блок дорогущего импортного расходомера в трубопровод, по науке: расчеты, расстояния и все дела. А прибор врет и ничего с этим сделать не удается. Приезжает представитель производителя (что довольно редко случается), нервно курит пару минут, потом дает указание переставить блок на пару метров дальше по трубе. Опять же — звезды совпали, что монтажники еще тут ошиваются и им интересно. Закончили работы, все начинает показывать правильно. Как так? «Да, хрен знает… если бы сейчас не заработало, то надо было бы еще пару мест установки попробовать. Обычно, чтобы все стало хорошо, требуются моя интуиция и не более трех итераций», — то ли шутит, то ли всерьез заявляет на ломанном русском сервисный инженер крупной европейской компании.
Жизненный цикл АСУ ТП
Теперь про жизненный цикл. Он стандартный в общем-то. Сначала идея и экономика, потом инжиниринг, проектирование и программирование, изготовление оборудования, комплектация изделиями и материалами, монтаж по месту, напряженная пусконаладка (ПНР), счастливая эксплуатация, а после предсказуемый финал — или модернизация, или же помойка утилизация. С точки зрения разработчика системы, конечно, этапы называются по-другому.
Подходы к разработке АСУ ТП
Дело в том, что АСУТП может быть разработана в рамках нескольких подходов, даже в рамках разных систем ГОСТов. Я как-то рассказывал печальную историю, когда заказчик заказал рабочую документацию по ГОСТ 21.408, но думал получить ее по ГОСТ 34.ХХХ (осторожно, 34-е ГОСТы теперь с огромной скоростью отменяются и заменяются). А это очень разные комплекты документов по составу и стоимости работ.
Вы можете спросить меня: зачем так? И я вам отвечу: чтобы было!
На самом деле, все зависит от ситуации. Предположим, что вы разрабатываете и изготавливаете технический комплекс, пусть это будет орбитальный модуль «ВсемП». Результат у Вас — космический корабль, который обязательно будет запущен в околоземное пространство и станет приветственно подмигивать иностранным партнерам. Вот к нему вы готовите конструкторскую документацию для себя, заводов смежников, для запуска и эксплуатации заказчиком. Одной из многочисленных подсистем, реализуемых и документируемых будет в ней система автоматики.
А вот у вас есть некоторое оборудование металлообрабатывающего центра, доставшееся за копейки из советского прошлого, которое, например, уже существует и работает. Кто-то умный подсчитал, что если его автоматизировать, то можно озолотиться увеличить эффективность. Тогда АСУТП будет совершенно отдельным продуктом, разрабатывать который надо по серии ГОСТ 34.ХХХ и их замененными аналогами (см. литературу в приложении к статье). Причем, чем сложнее объект автоматизации, тем строго в соответствии, ни в коем случае, не пропуская этапы и не забивая на документы. Даже не потому, что это очень надо (положа руку на сердце, часть документов для большинства АСУТП не нужна ни для реализации, ни для эксплуатации). Просто, если технологический комплекс не заработает, то без бумажек разработчику будет значительно хуже, чем с бумажками. Показательный пример мне рассказали тут на днях. Один олигарх купил ГОК, да решил с ним покорить рынок. И да, для этого ему нужно было модернизировать старье оборудование и прежде всего избавиться от кучи людишек автоматику. Местные тыкали в имеющуюся документацию, где научные светила и профильные институты указывали на нюансы месторождения, особенность руды, которую надо обрабатывать по особенной технологии, специальным оборудованием. Но их заставили замолчать. А чтобы вообще исключить вредительский отечественный фактор, на реализацию наняли буржуев. Те мудрить не стали: взяли свое типовое решение и прописали его в контракт. Потом, и это логично, что прописали, то и сделали. А когда уже на ПНР стало понятно, что никакого покорения рынка не случится, так ушли в глубокую несознанку. Господин Заказчик ведь знал, что заказывал, разве нет? Ну олигарх, не дурак, как понял к чему идет, так продал «не актив, а персик» конкурентам даже без дисконта, просто не посвящая в детали. Стратегия изменилась, бывает. Тут может у читателя сложиться мнение, что во всем виноваты буржуи. То, безусловно факт. Но в данном случае, у отечественных компаний шансов справиться также не имелось. Если барышня хочет, то нет силы, что способна это изменить. Есть разница в долгосрочных отношениях заказчика и подрядчика. Почему-то отношение к иностранцам у нас уважительное и лояльное, а вот местных можно любит нетрадиционно, да на договорные обязательства по отношению к ним забивать. Хотя вроде бы должно быть наоборот, ну согласно заветам партии и правительства.
Иная ситуация, когда строится завод, автоматика идет комплектно с оборудованием, но не в полном объеме. Она относительно детально проработана поставщиком, однако в связи с тем, что поставщик не знает, как и что по месту будет построено, то оставляет обвязку данной системы заказчику, то есть разработчику архитектурно-строительного проекта.
Или вот оборудование крайне простое, вообще действующее, где система автоматики модернизируется или просто технически перевооружается. В работе объекта автоматизации и в алгоритмах управления все понятно — тысячу раз так делали. Чего тут мудрить?
Еще вариант. Для стройки нужен, конечно, раздел рабочей документации марки «АТХ», а вот разрабатывать его пока не из чего. Что будет за технологическое оборудование в финале, как оно должно работать, то еще никто доподлинно не знает. Тогда заказчик говорит своему общестроительному проектировщику: ну вы придумайте что-нибудь, а я потом найму специалистов, они все сделают правильно.
Ситуаций может быть много. И задача ответственного руководителя выработать оптимальные порядок действий и количество документов, чтобы реализовать АСУТП без лишнего геморроя с наименьшими затратами. Но у нас любят гвозди забивать микроскопом, а вирусы разглядывать в лупу. И чтобы кто-то сделал все быстро, качественно и за копейки.
Состав типовой АСУТП
Типовая система автоматизации сейчас состоит в общем из аппаратных и программных средств:
- многообразия контрольно-измерительных приборов (КИП) для контроля и регулирования параметров технологического процесса (датчики (а меня учили, что это первичные преобразователи)), сигнализаторы, сенсоры и т.д.),
- программируемого логического контроллера (ПЛК) в составе шкафа управления (ШУ) с прикладным программным обеспечением среднего уровня,
- исполнительных устройств (клапаны, приводы, частотно-регулируемые преобразователи, пуско-регулирующая аппаратура),
- человеко-машинного интерфейса (ЧМИ): пульты (ПУ) и панели оператора (ПО), автоматизированные рабочие места (АРМ) на базе персонального компьютера (ПК) с прикладным программным обеспечением верхнего уровня.
Типовая структура АСУ ТП
Группируют указанные компоненты обычно в три уровня построения АСУТП. При этом в литературе могут писать про два, четыре и более уровней, но это фигня на любителя. Плясать следует от реализуемых на каждом уровне функций. Функции нижнего (полевого) уровня — сбор и первичная обработка данных, формирование физического управляющего воздействия. Это уровень КИПа и исполнительных механизмов, на котором может осуществляться, впрочем, ручное управление. Средний уровень обеспечивает дальнейшую обработку и анализ данных, а также формирование логических сигналов управления (с помощью автоматических регуляторов или ПЛК). Это уровень шкафов управления, что размещаются рядом с оборудованием или в щитовых. Здесь реализуется локальное регулирование по заданной программе, как правило, без участия или с минимальным участием человека. Наконец, верхний (интеграционный) уровень предназначен для комплексной обработки данных и общего управления промышленной установкой (линией) в реальном времени. Уровень объединяет, как правило, несколько локальных систем управления (но не обязательно) среднего уровня. Он включает в себя сервера, автоматизированные рабочие станции на основе персональных компьютеров, а также основные программные средства человеко-машинного интерфейса (например, SCADA-система). Физически оборудование размещают в комфортных операторских, предназначенных для длительного нахождения персонала.
Информация с верхнего уровня может уходить еще куда-то. Но надсистемами уровня «все производство» (например, MES) занимаются специализированные организации и крайне редко те, кто лазает в говнах реализует типовые АСУ ТП.
Уровень оснащения объекта автоматизации
Еще об уровнях автоматизации говорят в части объекта, что ей в особо циничной форме подвергается.
Нулевой уровень автоматизации говорит нам, что АСУ ТП отсутствует как класс. Если автоматизируются отдельные операции на станке (линии), но роль оператора все равно высока и без него ничего работать не будет — это частичная автоматизация. Комплексная автоматизация намекает, что линия (участок, цех) может работать автономно, оператор требуется для контроля и, возможно, выбора режимов работы оборудования. Ну а полная автоматизация подразумевает, что весь цикл производства выполняется без человеческого участия.
Если подумать, то можно даже выявить соответствия между уровнями типовой структура АСУ ТП и уровнями оснащения средствами АСУ объектов.
Боль и страдания рядового АСУТПиста
Особенность современной АСУ ТП сейчас в том, что она ни рыба, ни мясо. Говоря высоким штилем — программно-технический комплекс (ПТК), причем с наворотами из смежных областей знаний. А инженер АСУТП немного технолог, схемотехник, связист, проектировщик, конструктор, много программист, строитель и даже преподаватель технический писатель. То отдельная боль любого АСУшника. Ибо не могут они понять несправедливость мира по отношению к ним-любимым. Часто знают и умеют больше, чем распиаренные IT-шники. Добра миру причиняют аки былинные богатыри. А вот денег получают меньше. Дома времени почти не проводят, вечно тусуясь в каких-то эбенях дальних далях. Что не проект, то геморрой.
И ведь не сказать ничего в части поддержки, типа что все будет хорошо. Каждый сам выбирает свою судьбу.
Ну а мы поговорим по всем вопросам более подробно, но в отдельных статьях.
Cодержание раздела
Общие вопросы
| Основные понятия АСУТП (эта статья) | Технологический процесс производства продукции | Системы контроля и регулирования технологическими процессами | Синтез и расчет автоматических систем регулирования | Противоаварийная автоматика (ПАЗ): часть №1 , часть №2 |
Инжиниринг и проектирование
| Предпроектная подготовка | Исходные данные и материалы | Задание на проектирование | Стадии проектирования и состав проектной документации | Разработать схему автоматизации | Разработать схему принципиальную | Как правильно подобрать частотный преобразователь? |
Вопросы создания АСУТП
| Про ПЛК, резервирование и бывших партнеров | Производство шкафов управления | Электроника — наука о контактах |
Монтаж и ПНР
| Производственная среда | Требования к выполнению систем во взрыво- и пожароопасных зонах | Монтажные работы | Шефмонтаж и пусконаладка | Нежданные танцы с бубном в стиле АСДУЭ |
Эксплуатация
| Ввод в эксплуатацию | Почему АСУТП постоянно выходит из строя |
Дополнительно рекомендую ознакомиться со статьями цикла по системе автоматизированного проектирования EPLAN: Точка входа.
Источники, дополнительная информация
1. ГОСТ Р 59793–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Стадии создания» (взамен: ГОСТ 34.601–90 «Автоматизированные системы. Стадии создания»)
2. ГОСТ 34.201–2020 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Виды, комплектность и обозначение документов»
3. ГОСТ 34.602–2020 «Техническое задание на создание автоматизированной системы» (взамен: ГОСТ 34.602–89 «Техническое задание на создание автоматизированной системы»)
4. ГОСТ Р 59792–2021 «Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» (взамен: ГОСТ 34.201–89 «Виды, комплектность и обозначение документов при создании автоматизированных систем»)
5. ГОСТ Р 59795–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Требования к содержанию документов» (взамен: РД 50–34.698–90 «Автоматизированные системы. Требования к содержанию документов»)
6. ГОСТ Р 59853–2021 «Комплекс стандартов на автоматизированные системы. Автоматизированные системы. Термины и определения» (взамен: ГОСТ 34.003–90 «Автоматизированные системы. Термины и определения»)
7. ГОСТ Р 597922021 «Информационные технологии. Комплекс стандартов на автоматизированные системы. Виды испытаний автоматизированных систем» (взамен ГОСТ 34.603-92 «Виды испытаний автоматизированных систем»)
8. ГОСТ 34.32096 «Информационные технологии. Система стандартов по базам данных. Концепции и терминология для концептуальной схемы и информационной базы»
9. ГОСТ 34.32196 «Информационные технологии. Система стандартов по базам данных. Эталонная модель управления данными»
10. ГОСТ 21.1012020 «Система проектной документации для строительства. Основные требования к проектной и рабочей документации»
11. ГОСТ 21.40485 «Система проектной документации для строительства. Автоматизация технологических процессов. Обозначения условные приборов и средств автоматизации в схемах»
12. ГОСТ 21.4082013 «Система проектной документации для строительства. Правила выполнения рабочей документации автоматизации технологических процессов»
13. ГОСТ 21.114-2013 «Система проектной документации для строительства. Правила выполнения эскизных чертежей общих видов нетиповых изделий»
14. ГОСТ 2.102–2013 «Единая система конструкторской документации. Виды и комплектность конструкторских документов»
15. ГОСТ Р 2.105–2019 «Единая система конструкторской документации. Общие требования к текстовым документам»
16. ГОСТ Р 2.106–2019 «Единая система конструкторской документации. Текстовые документы»
17. ГОСТ 2.113–75 «Единая система конструкторской документации. Групповые и базовые конструкторские документы»
18. ГОСТ 19.101–77 «Единая система программной документации. Виды программ и программных документов» (ЕСПД)
19. ГОСТ 19.30179 «Единая система программной документации. Программа и методика испытаний. Требования к содержанию и оформлению»
20. ГОСТ Р ИСО/МЭК 15910-2002 «Информационная технология. Процесс создания документации пользователя программного средства»
21. ГОСТ 19.50278 «Единая система программной документации. Описание применения. Требования к содержанию и оформлению»
22. ГОСТ 19.50379 «Единая система программной документации. Руководство системного программиста. Требования к содержанию и оформлению»
23. ГОСТ 19.50479 «Единая система программной документации. Руководство программиста. Требования к содержанию и оформлению»
24. ГОСТ 19.50579 «Единая система программной документации. Руководство оператора. Требования к содержанию и оформлению»
25. ГОСТ Р 51583–2014 «Защита информации. Порядок создания автоматизированных систем в защищенном исполнении. Общие положения»
26. Нестеров А. Л. Проектирование АСУТП. Методическое пособие. — СПб, Издательство ДЕАН, 2006 (в двух книгах)
Ознакомиться с содержанием журнала.
Уважаемые коллеги, желаю хорошего дня. Подписывайтесь, чтобы иметь возможность обсудить со мной вашу задачу в комментариях. Буду рад лайку, альтернативному мнению или истории по теме статьи.
ПРЕДУПРЕЖДЕНИЕ №1: Оценки, суждения и предложения по рассматриваемым вопросам являются личным мнением автора.
ПРЕДУПРЕЖДЕНИЕ №2: Техническая информация, представленная на сайте, не является официальной и предоставлена только в целях ознакомления. Владелец сайта не несет никакой ответственности за риски, связанные с использованием информации, полученной из данного источника.
Все изображения, если не указано иное, либо выполнены автором, либо взяты из открытых источников.
