Что вообще такое — АСУТП на заводе

Все же знают, что такое АСУТП? Обычно бывает так: все что-то слышали, но никто точно не знает, как вся эта история работает. Мы в целом тоже не до конца знаем, но можем рассказать о практике.

Платы старого и нового контроллера

Начнём с того, что во всём виноват пар. Первые заводы были незамысловатыми: вода или ветер вращали колёса, они передавали движение на кузнечные меха, пилу, молот, жернова или пресс для масла. Если ветра или воды не было, то часто можно было запустить тот же процесс с ослика. А вот с появлением паровых машин появились изобретатели, которые стали пытаться прикручивать какую-то базовую автоматизацию. Жидкостные компьютеры мы сейчас пропустим и сразу перейдём к электричеству. Электричество в районе 60-х дало возможность делать логические схемы: сначала — на лампах, а потом куда более массово в районе 70-х — на транзисторах.

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

Всё, конечно, чуть сложнее, но теперь вы уже разбираетесь в АСУТП.

Сейчас поговорим про такие детали, как операционные системы реального времени, которые нужны, чтобы всё это работало правильно.

Классическая схема автоматизации

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

Индуктивный датчик

• Логика: обычно это контроллер. Старый контроллер похож на микросхему площадью до одного квадратного метра, новый — на шкаф с какой-нибудь промышленной материнской платой и процессором в корпусе без дырок (чтобы не засасывало пыль), но большим количеством меди (чтобы отводить тепло). Контроллер смотрит на показания датчиков и управляющие телеграммы, отдавая команды на актуаторы.

Контроллер в шкафу

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

Всё это не может работать на обычных операционных системах, потому что нужны очень быстрая скорость реакции (около 1 мс) и гарантированный ответ от вычислительных компонентов в течение определённого срока. У нас — WindRiver VxWorks. Её архитектура предполагает ответ нескольких «спящих» обработчиков в гарантированный срок, то есть она вся заточена под гарантированный ответ на непредсказуемую ситуацию в предсказуемое время. Относительно классических систем у неё полностью переписано выделение ресурсов. Такая же ОС использовалась на марсоходе «Куриосити», если что.

ОС реального времени есть не везде: где-то контроллер может работать на более привычной, хоть и очень кастомной nix-сборке.

Первый уровень — уровень контроллера — обеспечивает выполнение достаточно простых программ, но без остановок. Архитектурно это одна запущенная задача, которая состоит из бесконечного цикла и кучи IF’ок в теле. Дальше в зависимости от состояния датчиков и телеграммы выбирается один из IF’ов, исполняется, после завершения исполнения — добро пожаловать в начало цикла! Если датчики сваливаются в ошибку или если текущей задачи нет — контроллер останавливает работу станка.

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

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

Некоторые датчики передают не прямую информацию о техпроцессе, а косвенную. Например, пирометр позволяет догадаться, когда под ним проезжает горячая заготовка, но греется он заранее, когда она только на подходе. И если не знать скорости вращения валков или рольганга, то можно и не понять, где она, поэтому используются разные коррекции и расчёты.

Большая часть сложных задач вынесена на второй уровень автоматизации. Обычно это уже полноценный компьютер, управляющий контроллером. Он говорит ему, что делать, и контроллер делает. Он собирает с контроллера (и часто с соседних контроллеров) данные, делает сложные расчёты, у него есть логика, триггеры, большая база данных, большой объём памяти (на контроллере — редко больше 16 Мб), например, там может быть софт, который отслеживает совокупности параметров, чтобы понять, что устройство отклонилось от стандартных режимов. Там же может копиться информация для ремонта. Он же может отдавать данные в разные системы вроде шины АСУТП или вообще складывать «сырые» данные нашим сатанистам в их хранилки.

Второй уровень способен принять задачу условно на сутки: «Точите 8 деталей так, потом 5 деталей — так, потом 11 деталей — так, потом, пока не сработает вот этот датчик, — вот так». Эта задача ставится из MES-системы (третьего уровня автоматизации), где формируются суточные задания.

То есть:

• MES говорит, что делать на горизонте от минут до часов.
• Второй уровень расписывает это на задачи для контроллера и отправляет на него телеграммы.
• Контроллер получает телеграммы вроде: «Подними штангу на 12 сантиметров», и просто делает, что ему говорят.
• Контроллер собирает данные с датчиков, обрабатывает сам, отдаёт их на второй уровень.
• На втором уровне корректируется план действий дальше или подаётся следующая телеграмма контроллеру.
• Второй уровень докладывает в MES что-то вроде: «Заготовка такая-то готова с такими-то параметрами», а также сваливает данные телеметрии в системы ремонта и т. п.

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

Это, кстати, значит, что на станки с буквами Н — «Непрерывно» — ставят по два контроллера, чтобы если один вылетел, то второй подхватил бы работу.

Сеть между устройствами — обычно на базе Ethernet. Если что-то находится в зоне сильных помех, то это ошиблись при проектировании цеха, потому что источники помех обычно или экранируются, или же разносятся с коммутацией и нашими узлами. Наш кабель нельзя тащить в том же лотке, что и силовой. Но если выхода нет, то у нас есть всякие экранированные штуки, которые дороже обычных раз в 10. Если что-то движется, и движется часто, к тому же оно так же часто перетирает кабель, то можно поставить промышленную систему беспроводной связи. Это не Wi-Fi и не LORA — это хардкорные решения вроде троллея, представляющего собой щелевую антенну, и антенны на тележке в 15–40 сантиметрах, которая едет мимо этого излучающего кабеля. В АСУТП мы вообще ни разу не доверяем беспроводным соединениям больше полуметра в условиях завода. А ещё можно проводить сеть по железнодорожным рельсам, потому что толщина рельса гарантирует скорость и надёжность соединения. На самом деле этот стандарт достался нам от железных дорог: там сигнализация передаётся током прямо на рельс, а поезд считывает сигнал индукционной катушкой спереди.

Как это выглядит на практике

Стоит станок. Обычно внутри него — только датчики и выводы от них. Вся эта паутина подходит к шкафу, который стоит рядом, там — контроллер, привода, распределённая периферия. Иногда там же — пульт или тач-панель в какой-нибудь защищённой оболочке.

Дальше стоит помещение со шкафами — контроллерная. Там — контроллеры без периферии.

Ещё дальше — серверная со своим воздухом вдали от производства, в ней стоят уже полноценные серверы, которые считают 2-й уровень АСУТП — тот, где сменное задание превращается в команды для контроллеров.

Есть диспетчерская, где видно телеметрию и откуда можно поуправлять станком. Есть рабочие места — у нас это станции человеко-машинного интерфейса. От пульта до терминала с компьютером с привычным экраном — либо защищённый, либо офисный.

Если вы думаете, что это всё возможное управление, то нет. Ещё можно влезть прямо в низкий уровень с перемычкой. Джамперы есть только у ремонтников, потому что для всех остальных это строжайшее табу с мгновенным увольнением: нужны допуски и очень глубокое понимание, что именно вы замыкаете. Для штатных ситуаций перемычки у нас закончились в 70-х, а вот в случае аварий очень редко, но бывает.

Одна из самых сложных ситуаций — либо когда приходит новое оборудование, либо когда строится новый цех. Предположим, мы купили новое оборудование, которое меняет техпроцесс. Оно поставляется сразу с системой управления и автоматизацией. Чтобы оно отдавало телеметрию в шину, надо подключить пару портов, сделать next-next-done и почти всё. А вот чтобы оно работало — это задача огромного масштаба, потому что надо присовокупить к существующей линии. Хорошо, если оно ставится в конце производственного процесса, сбоку или в начале. Сложно, когда надо вклинить в разрез производственной линии.

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

Где-то доработки идут на стенде, к которому можно прикрутить моторы или что-то ещё, и такой же контроллер. Где-то есть виртуальная среда и возможность играть с контроллером в симуляторе. Где-то нужно прямо «на живую» — если есть что-то, что невозможно повторить даже на стенде.

Доработка прошла — начинаются холодные испытания, потом — горячие. Ждём какого-нибудь планового ремонта, пока участок стоит — вклиниваемся и начинаем смотреть. Сначала подключаем питание на контроллер и смотрим, не упадёт ли всё, как озимые. Если ушёл в ошибку, то начинаем проверять сигналы с датчиков, с приводов и так далее. Если проверка прошла успешно, то начинаем робкие попытки управления агрегатом в ручном режиме: пошевелить рольгангом, подвигать штангой и так далее. Все исполнительные механизмы проверяем. Потом смотрим, везде ли правильные задержки, разгоны и торможения для приводов, чтобы обеспечить параметры производительности. После нескольких итераций отлаживания и понимания, что и ПО по кускам работает в нормальном режиме, уже включаем в производство и пробуем делать продукцию. Иногда получается, но чаще симулятор и реальный мир отличаются друг от друга, и надо ещё дорабатывать. Потом уже испытания в разных режимах производства, краевые случаи — и можно запускать в линию, но внимательно за ним присматривать ещё некоторое время.

Кто у нас работает

У нас два основных крыла — ремонт и развитие. Ремонт — это фактически поддержка, развитие — фактически разработка.

Сначала — про ремонтный персонал.

Самая частая профессия — рабочие: электромонтёры и слесари. На них — обслуживание датчиков и исполнительных механизмов, трасс, клеммных коробок. Они могут делать простые ремонтные операции на системах управления. Логику они почти не трогают.

Дальше идёт инженер по автоматизации — он умеет делать всё то, что делает рабочий, но занимается небольшими доработками, может менять логику, но много не разрабатывает, то есть, по сути, управляет конфигами. Они опытные пользователи, то есть понимают логику системы и смысл всех действий. Они же привлекаются к разборам ситуаций, они же выступают неким аналогом второй линии поддержки по софту АСУТП.

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

Руководитель — начальник участка или отдела. Административный и функциональный руководитель. Оборудование не трогает, работает с людьми, ищет ресурсы, деньги, заботится о том, чтобы всё всегда было в нужном количестве, убеждает других людей, что вот так делать правильно, умеет подводить обоснования под: «Если это не это, то оно всё того, верняк!»

Теперь — развитие.

Тут уже нет рабочих: все они — инженеры или главные специалисты либо, в крайнем случае, менеджеры. Их функция — не какая-то единица оборудования или цех. Они в целом отвечают за внедрение и распространение по всем участкам оперативно-ремонтных правил, проектов, нововведений, стандартов ИБ и так далее. Есть команда специалистов, которая делает новый софт для запуска новых производств и глубокой модернизации существующих.

То есть оперативно-ремонтная часть команды поддерживает общую работоспособность оборудования, делает небольшие изменения софта и трогает конфиги, а развитие может написать новый софт или переписать заново что-то для целой группы агрегатов. Они же взаимодействуют с подрядчиками, пишут стандарты и ТЗ, принимают в эксплуатацию (приёмка в эксплуатацию идёт вместе с ремонтным персоналом).

Примерно вот так у нас выглядит АСУТП. Приходите, будет тяжело!