Когда речь заходит про умные заводы, «тёмные производства», цифровых двойников, промышленный интернет вещей и в целом будущее, многие настолько воодушевляются, что упускают важные вещи. А именно — общую логику построения систем автоматизации заводов. Об этом, и не только, рассказывает руководитель направления «Цифровая промышленность» в СберМобайле Олег Плотников.
Основы, описанные в ISA-95 или ГОСТ Р МЭК 62264-1-2014, всегда звучат в рассказах, презентациях или описаниях. Авторы используют такие термины, как SCADA, PLC, IIoT‑платформа или MES. Но правила работы и уровни промышленной автоматизации часто трактуют неверно. И очень зря.
Уровни автоматизации при неудачном смешивании могут вызват�� немало проблем. Поэтому всегда нужно держать в голове пирамиду АСУ ТП/АСУП, о которой мы сегодня и поговорим. Добро пожаловать в основы цифрового завода.
Два слова про автора
Меня зовут Олег Плотников, последний год я занимаю должность продакта направления «Цифровая промышленность» в СберМобайле. До этого был IIoT-архитектором. Занимался умной частью строящейся штаб-квартиры Яндекса. А в прошлой, еще до-московской жизни активно внедрял современные технологии на Уральских заводах. Кстати, сам я родом из Челябинска, города-предприятия.
Уровни АСУ ТП/АСУП
Для начала немного терминов. АСУ ТП — это автоматизированная система управления технологическими процессами, то есть та самая промышленная автоматизация. АСУП — автоматизированная система управления предприятием. Идеологически то же самое, что АСУ ТП, только масштабом больше и задачами амбициознее.
Деление на уровни вы можете увидеть на картинке ниже. Международный стандарт ISA-95 с таким разделением не согласится и схлопнет уровень MES со SCADA в один (Level 3 — Manufacturing operations management), а также добавит нулевой про физические процессы. На самом деле, точное разделение не принципиально, если вы понимаете смысл. Чем же важна эта пирамида и что может случиться, если её как-то неправильно истолковать? Давайте посмотрим.
Уровень 1. Исполнительные механизмы и датчики
В самом низу у нас находится то, что непосредственно выполняет задачи или следит за процессом.
Что такое исполнительный механизм? Электродвигатель, автоматическая защёлка, лебёдка — всё, что делает какое-то действие при подаче управляющего сигнала.
Датчик — это ровно наоборот. Он следит за каким‑либо параметром и отдаёт его значение: температуру, давление, скорость конвейера, вибрацию дробилки. Благодаря датчикам системы автоматизации «видят», что происходит на производстве.
Не воспринимайте датчик как простую железку. Он может быть очень сложным и со своей логикой работы. Например, камера с машинным зрением, которая считает количество деталей на конвейере. Несмотря на продвинутость, камера даже видеопоток не выдаёт, она отдаёт лишь количество распознанных изделий. И в нашей архитектуре это будет датчик.
Уровень 2. ПЛК
ПЛК — это программируемые логические контроллеры. Сердце и мозг современного производства. Именно внутри них находится вся логика производства, и они отдают управляющие команды.
На российских заводах с огромным отрывом лидируют контроллеры Siemens серии S7. Хотя встречаются Omron, Beckhoff, а также российские ОВЕН и ТЭКОН и ряд других.
Давайте рассмотрим ПЛК поближе. ПЛК — это специализированный контроллер в промышленном корпусе с необходимым уровнем защиты и нужными интерфейсами подключения. ПЛК могут работать в очень агрессивных условиях, потому их схемотехника и оболочка должны быть рассчитаны на тяжёлое существование. Но это не самое важное. Важнее другое: ПЛК прямо заточен под управление производством в тех условиях, в которых это производство происходит. Это его главная цель. Например, он может работать в системе жёсткого времени.
Жёсткое и мягкое время
В системах жёсткого реального времени есть минимальный порог, в течение которого система должна принять решение и выполнить какие-то действия. Если система не успевает это сделать, то техпроцесс ломается катастрофически. Например: нож режет заготовку, роборука её забирает. Случилась нештатная ситуация, а система не успела сообщить ножу, что надо притормозить? Роборуку отрезало.
В системах мягкого реального времени пропуск события не сломает техпроцесс, но снизит его качество. Пропустили, что крышечка для газировки застряла в аппарате — пошёл брак. Не смертельно, но неприятно и накладно.
На практике вокруг жёсткого времени выстраивают дополнительные уровни защиты, и просто так руку отрезать не должно. Но для иллюстрации идеи годится.
Контроллер и его окружение проектируются под предсказуемое выполнение цикла и отказоустойчивость: watchdog, диагностика, промышленная элементная база, понятная логика действий. Поэтому в нормальной архитектуре у вас есть уверенность в таймингах и в том, что логика линии не сломается от случайных задержек.
Это важная мысль. Мир промышленной автоматики — это мир, который работает в непривычной многим логике. Отличный пример такого подхода — протокол EtherCAT. На первый взгляд этот протокол работает максимально странно. Кадр выходит из мастер‑контролера, оббегает по очереди все устройства в сегменте, и последний узел/топология возвращает его мастеру обратно. Каждое устройство забирает из кадра информацию, предназначенную для него, или пишет туда что‑то, что необходимо сообщить контроллеру.
Зачем такая странная конструкция? Чем вам не угодил старый добрый Ethernet? Всё просто: обычный Ethernet не даёт гарантии по времени доставки кадра. Особенно при конкуренции трафика, очередях, неправильной архитектуре. Несмотря на гигабитные скорости, в Ethernet может сложиться ситуация, когда кадр запоздает и придёт не в регламентное время. Часто такое бывает? Зависит от многих факторов, но нам важно, что в системе жёсткого времени хватит одного раза.
EtherCAT лишён такой проблемы. Он устроен так, чтобы задержки были предсказуемыми. Мастер задаёт расписание обмена. Устройства читают и пишут в кадр на лету. Джиттер и задержки в этой архитектуре не исчезают вовсе, но становятся контролируемыми и рассчитываемыми. И вокруг них уже можно проектировать тайминги линии.
Итак, на уровне ПЛК живет вся оперативная логика управления оборудованием и техпроцессом: что включить, когда открыть, какие блокировки держать, как отрабатывать аварии в реальном времени. Всё, что критично по таймингам и безопасности процесса, должно пережить отсутствие SCADA/сети/серверов. Единственное, что может прилететь не с ПЛК в рабочем режиме – различные аварийные команды от частотников, систем управления, релейной защиты и прочего. Остальное либо с контроллера, либо у вас режим отладки и линия не в работе.
И вот здесь мы подбираемся к первой проблеме, которую обожают создавать многие автоматизаторы. Звучит проблема так: «А давайте делегируем часть решений SCADA»!
Уровень 3. SCADA
SCADA (Supervisory Control and Data Acquisition) – это система диспетчерского контроля и сбора данных. Когда автор хочет сопроводить статью про цифровой завод красивой и технологичной картинкой, он в 80 процентах случаев выберет пульт со SCADA. Еще 20 процентов остаются на 3D-модель в режиме Wireframe, которой иллюстрируют цифрового двойника. Я тоже не остался в стороне и вынес пульт SCADA в обложку этой статьи.
Самые известные SCADA на рынке – это WinCC от Siemens, Master SCADA, Simple SCADA (для несложных задач), SCADA на платформе Tibbo и ряд других.
Что делает SCADA? Показывает диспетчеру что сейчас происходит на производстве, в цехе, на переделе. И очень хорошо это визуализирует. Так сложилось, что в системах SCADA используют интуитивно понятный язык мнемосхем. Это когда мы видим наше производство в упрощенном графическом виде и сразу ясно, куда чего идет. Видно и аварии. Они вынесены как в отдельный журнал, так и отображаются на мнемосхемах. Наглядно понимаем, где чего застряло или закипело. Выглядит, кстати, красиво.
Архив тоже имеется. Разными графиками и таблицами можно прикинуть, что было вчера или месяц назад. Еще SCADA умеет управлять. Диспетчер с ее помощью может вмешаться в техпроцесс. Это нештатная, но допустимая ситуация. Например, диспетчер видит, что роборуке на конце конвейера плохо и заготовки в печь никто не переложит. Логично же остановить конвейер? Логично.
А еще диспетчер может изменить какой-то техпроцесс или сменить режим работы. Например, выбрать другой рецепт (последовательность действий на линии), т.к. пошла другая номенклатура деталей из других материалов. А еще бывает, что диспетчер может подрегулировать какой-то параметр в техпроцессе. Греется у нас чан с сыром, потому что потеплело на улице и в цеху теплее. Сменим установки на летние. Но вот здесь очень тонкая грань между «разово сменим установки в ПЛК» и «будем динамически регулировать часть параметров в ПЛК через SCADA». Первое допустимо. Второе — фатальная ошибка.
Дело в том, что когда SCADA упадёт (не если, а когда) техпроцесс не должен пострадать. SCADA — это инструмент контроля и корректировки, но не полноценного управления. Если хоть какая‑то логика на линии заложена в SCADA и никак не прописана на уровне ПЛК, жди беды.
Чтобы проиллюстрировать эту грань, я обычно пользуюсь примером не из промки, а из умного ЖКХ. Есть такая штука как АСУНО (автоматическая система управления наружным освещением). И на её логике работы проблема максимально понятна и показательна. Как правильно строится система включения и выключения уличных фонарей? На подстанции или даже в каждом фонаре есть контроллер, который включает и выключает фонари. Расписание залито в сам контроллер, и он автономен. Есть система управления всеми фонарями. Она находится далеко, в диспетчерской, и связана с контроллерами через какой-то канал связи. Если проводить аналогии, то система управления — это SCADA.
Система может зайти в контроллер и подкорректировать ему расписание. Она может разово принудительно включить фонари днём. Но она не должна каждое утро и вечер отправлять команду на включение и выключение. Если мы так поступим, то при любой проблеме канала связи/системы управления у нас город погрузится в темноту.
Отказоустойчивость - это одно из важнейших правил АСУ ТП. Хорошо, когда есть SCADA, но без SCADA работа не должна останавливаться.
HMI
Где-то между ПЛК и SCADA находятся HMI-панели. Расшифровывается как Human-Machine Interface, то есть человеко-машинный интерфейс. Обычно это небольшой сенсорный экран, встроенный в шкаф управления или линию. Через панель можно получить доступ к основным функциям или настройкам ПЛК. Линии на некоторых не вполне цифровизированных производствах работают без SCADA и управляются исключительно через HMI. Но это, конечно, не слишком удобно.
Иногда возникает путаница, когда HMI-панель оказывается подключена не к ПЛК, а к серверу со SCADA, и отображается на ней SCADA. По сути, HMI тут выполняет функцию консоли. Потому я не отношу её однозначно к одному уровню, а выделяю слегка обособленно, но не рассказать про неё нельзя.
Помимо уже понятного вам желания завязать часть логики на SCADA бывает еще одна опасная навязчивая идея. «А давайте навесим в SCADA аналитики!». Что ж разберемся, что за бочка с порохом кроется в этом желании.
Уровень 4. MES
После уровня SCADA АСУ ТП заканчивается и начинается следующий большой блок: АСУП, или автоматизированная система управления предприятием.
Четвёртым уровнем идёт система MES (Manufacturing Execution System) — система управления производственными процессами. Здесь находятся аналитика, планирование производства, управление документацией, контроль качества, планирование и распределение ресурсов, мониторинг оборудования и процессов, а также сбор и обработка информации с уровня АСУ ТП.
Кажется, что MES частично дублирует функциональность SCADA? Вам не кажется, так и есть. Бывает непросто провести грань между теми аналитиками, что должны быть в SCADA, и теми, что уже должны жить в MES. Аналогичная история с диспетчеризацией.
Если очень широкими мазками, то главных отличий два. MES — это уровень не технологической линии, а целого цеха или даже завода. И это система, заточенная под контроль производства в целом, а не отдельных технологических процессов.
В общем случае MES не контролирует конкретные параметры отдельного конвейера. Этому уровню хватит понимания, что конвейер в порядке или выведен из работы, и в зависимости от этого система будет планировать производство, опираясь на имеющиеся возможности.
Из примеров MES можно вспомнить Siemens Opcenter, SAP ME, решения от ИндаСофта и Цифры, а также 1C:MES, РеMESло и ряд других. Платформа SberMobile AIoT тоже обладает некоторой функциональностью MES, но с ней классификация чуть сложнее. Тут вступают в силу современные реалии.
MES на наших заводах встречается реже SCADA, и понимания по нему традиционно было меньше. Но в общих чертах зоны ответственности были понятны. Однако классическая пирамида АСУ ТП/АСУП складывалась в 90-е годы и начале нулевых, и тогда такая логика работала идеально.
С тех пор у нас случилась революция интернета вещей и появилась такая штука, как IIoT-платформа. Мы ещё подробно поговорим о ней во второй части, когда будем разбирать цифровые тени и двойники. Пока лишь отмечу, что IIoT-платформа впитала в себя часть функциональности SCADA, взяла немного от MES и стала некой параллельной частью, которая расположилась где-то между третьим и четвёртым уровнями промышленной автоматизации.
Наряду с граничными контроллерами (о них тоже поговорим) IIoT‑платформы сломали всю эту стройную логику и внесли путаницу. Сейчас нередко их могут принять за MES, а MES — за IIoT‑платформы. И границу правда провести непросто. Именно поэтому я с осторожностью отношусь к классификации SberMobile AIoT и отмечаю, что это скорее IIoT‑платформа, которая при определённых условиях может выполнять часть функциональности MES.
Наверное, будет правильным такое определение — там, где идёт сбор информации с большого количества датчиков и анализ этой информации самыми изощрёнными способами — это IIoT. Там, где больше думают про производственный процесс, сырьевую модель и оптимизацию — это MES.
Вернёмся к вопросу из третьего уровня: «что не так с аналитикой и почему её опасно размещать в SCADA?» Давайте уточним — речь не про любую аналитику, а только про тяжёлые отчёты с многочисленными метриками. Проблема в том, что цифровой завод может генерировать колоссальное количество данных. Один условный серьёзный станок вполне отдаст нам по 50 метрик каждую секунду. Если это складывать в БД, а потом попробовать дёрнуть статистику за квартал, то процессор сервера SCADA просто уйдёт в полку, потому что без инструментов работы с Big Data в такую аналитику идти бессмысленно. Если данные не прорежены, не усреднены, то их обработка становится слишком тяжёлой.
Подобные инструменты могут быть на борту MES, и они точно будут у IIoT-платформ. Но не у SCADA. В чём же сложность поместить их туда? В том, что SCADA — это система операторского контроля и управления. При проектировании в неё просто не закладывают такие серверные мощности. Вам нужна тяжелая аналитика? Выносите её отдельно. Не уследите за нагрузкой — диспетчер лишится контроля и управления производством.
Сервер SCADA в полке из‑за запуска тяжёлого отчета, увы, повторяющаяся ситуация. Хотя такого быть не должно.
Уровень 5. ERP
Если MES — это как производство выполняет свою работу, то ERP (Enterprise Resource Planning — планирование ресурсов предприятия) — это как завод живёт с точки зрения бизнеса. Деньги, закупки, склады, договоры, планирование потребностей, себестоимость, отгрузки, закрытие периодов — это всё ERP.
Главная идея тут в том, что ERP — это не система реального времени. Она умеет отлично считать деньги и запасы, но ей не надо (и нельзя) участвовать в управлении процессом «здесь и сейчас».
Нормальная связка выглядит так:
ERP отдаёт заказы, планы, спецификации, ограничения (что делать, сколько, к какому сроку, из чего).
MES превращает это в конкретные производственные задания, маршруты, операции, партии, серии и правила качества, и фиксирует факт выполнения.
SCADA помогает диспетчеру контролировать процесс и вмешиваться в него, если что-то идёт не так. Кроме того, она же подсвечивает аварии и показывает несложную аналитику.
ПЛК обеспечивает реальное управление оборудованием и реакцию на первичные нештатные события.
Глобальная архитектурная ошибка — попробовать проскочить уровень MES и связать SCADA напрямую с ERP. Так делают, и это даже работает. Но ERP не оперативна, и попытка завязать на неё часть процессов создаёт бутылочное горлышко: пока ходим за данными, процесс провисает.
Ещё один страшный враг ERP — хаос. Дело в том, что в ERP может скопиться большая номенклатура продукции или сырья. И если нет чётких правил его именования и разграничения, то всё это станет большим трудночитаемым списком.
Но чаще всего ERP живёт в зоне ответственности 1С и с промышленной автоматизацией связана слабо. Потому там свой мир, не всегда понятный с завода. Именно поэтому популярнейшей ERP в российской промке остаётся 1С:ERP. Все остальные конкуренты довольно нишевые, хотя можно вспомнить ещё Галактику и решения от SAP.
Уровень 6. BI
BI (Business Intelligence) — это не система управления и не система учёта. BI — это витрина и калькулятор поверх уже собранных данных, чтобы руководители, технологи, экономисты и начальники производств видели картину в числах: выпуск, OEE, простои, качество, себестоимость, выполнение плана, узкие места.
Ключевой момент: BI не должен ходить «с запросами» в боевые SCADA, MES и ERP, потому что тяжелые отчёты и дашборды рано или поздно превращаются в «почему всё тормозит». Правильная схема — отдельное хранилище, витрина, озеро, куда данные приходят из ERP, MES и историка, очищаются и нормализуются, и уже оттуда BI спокойно строит отчёты хоть каждые 10 секунд, не рискуя положить ни операторский контур, ни учёт.
Рынок BI на данный момент представлен такими монстрами как Microsoft Power BI, Tableau, Qlik, Yandex DataLens и наш Сберовский BI‑навигатор.
Ключевая проблематика
Но ключевая проблема большинства современных заводов всё же выглядит следующим образом. У нас есть SCADA. Даже не одна, а три‑четыре. Есть линия, где всё только на ПЛК и HMI‑панелях. Есть какой‑то специализированный софт, вроде АСТУЭ/АСКУЭ. ППР и поверки вообще ведутся только в бумажных журналах, а в цифру если и переезжают, то в виде сканов.
И эти вещи никак между собой не связаны. Казалось бы, получая те же параметры электропитания, мы могли бы коррелировать их с производственным процессом и возможными авариями, простои из‑за ППР наложить на эффективность производства, а сами ППР привязать к недавним авариям и посмотреть, хорошо ли у нас обслуживают оборудование.
Но ничего этого нет. Почему? Потому что предприятие редко строится с нуля и целиком. Цеха вводят в строй постепенно. Оснащают тем, что есть на рынке и что выигрывает по соотношению цена/качество. Как итог — хаос: этот цех конца 90-х, этот вчера сдали, этот, кажется, в 2010-м, а там вообще советское наследие, но пока живое. Разные производители, поколения и протоколы.
Здесь у меня есть любимая аналогия. Представьте себе железную дорогу большой страны, которая разделена на несколько несвязанных частей. Где‑то на поезде можно доехать из одного города в другой, где‑то — только покружить по городу на электричке. Если связать эту дорогу воедино, то мы получим потрясающую транспортную систему. И построить эти связи не так уж дорого: между «железками» не хватает буквально небольших участков. Но их нет. Поэтому проехать на поезде через всю страну невозможно.
Заключение
Мы прошлись по всей пирамиде АСУ ТП/АСУП и теперь хорошо понимаем все уровни. И не просто знаем расшифровку терминов, мы понимаем суть и логику разнесения этих уровней. А также понимаем проблемы, с которыми наши цифровые заводы живут.
Теперь, когда этот этап пройден, перейдём на следующий уровень цифровизации. В следующей статье ждут IIoT, цифровые двойники и граничные вычисления.