Дискретность и разная логика

Проблема двустороннего обмена данными между автоматизированными системами управления производством (АСУ П, в международной терминологии — MES) и системами планирования ресурсов предприятия (ERP) стоит действительно остро. На состоявшейся 17 сентября итоговой стратегической сессии Межотраслевого комитета по MES эта тема стала одной из ключевых.

Источник проблемы в самой логике процесса цифровизации предприятия. Компании начинают его с вершины айсберга — с решения экономических задач: сведения бухгалтерского баланса, оптимизации себестоимости, ведения базы заказчиков и реестра договоров. Для этого внедряют ERP. После того, как работа с данными и аналитика в «экономической» сфере налажены, появляется задача повышения эффективности производства. Тут встает вопрос о внедрении АСУ П.

Но у каждой системы свои временные рамки, своя дискретность. В стандарте ISA-95 это выглядит так: верхний (четвёртый) уровень автоматизации оперирует месяцами и сутками, третий уровень (АСУ П) — сменами и минутами, второй и первый (SCADA, PLC) — секундами и миллисекундами.

Все эти системы используют разные данные. ERP, ориентированная на финансовые задачи, работает с крупными массивами, состоящими из разных групп данных — например, при расчете себестоимости производства нескольких номенклатурных рядов продукции. АСУ П взаимодействует с производственным аспектом тех же процессов, и тут появляется множество «мелких» деталей, которые «не важны для ERP»: внутренняя логистика, контроль качества, технологические параметры на каждом этапе выпуска продукции. Здесь возникает первая проблема взаимодействия ERP и АСУ П: последняя должна учесть и сгруппировать на своем «нижнем» уровне данные так, чтобы их сумел прочитать верхний уровень.

Уровень цифровой зрелости российских промышленных предприятий очень разный. Где-то учет данных ведется вручную, а кто-то уже построил цифровой двойник. Большинство же, около 70%, застряли где-то посередине: ERP у них уже есть, но АСУ П находится в полуразобранном виде, общего цифрового контура и, соответственно, моделей интеграции разных уровней нет. Отдельный вопрос — качество данных. При сквозном потоке данных ошибка на одном из уровней влияет, в конечном итоге, на работу всей системы, соответственно, в процессе интеграции всех уровней важно проработать механизмы и логику корректировки данных.

Единая модель

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

В концепции Индустрии 4.0 общая информационная модель — это сквозное дерево, где полевые данные привязываются к конкретному объекту, сначала к датчику, затем к агрегату, к узлу, к оборудованию, к цеху, к предприятию. Тогда сбор этих данных, агрегация, контроль качества и BI-аналитика будут легко формировать нужную отчетность с пониманием того, как данные уложены в эту структуру.

Наиболее логичной видится архитектура модели, состоящая из нескольких слоев. «Источник правды для всей компании» в ней — слой Мастер-НСИ (главная система нормативно справочной информации), в котором консолидируются мастер-данные из всех подразделений и информационных систем. Это единый источник справочников для номенклатуры, материалов, оборудования. В Слейв-НСИ — ведомой системе — эти данные детализируются под производственные задачи. На этот слой «надстраиваются» функциональные модули для каждого подразделения, или домена — планирование, контроль качества, учет ресурсов, диспетчеризация.

Потоки данных в единой модели разнонаправлены. Вниз от ERP идут справочники, спецификации, планы, потребность в материалах и в персонале, нормы потребления ресурсов, заказы на производство, стандарты качества. Вверх от АСУ П — фактические объемы производства, расход материалов, энергозатраты, данные по качеству продукции, информация о простоях оборудования, заявки на материалы. Периодичность обмена зависит от зрелости систем и может быть установлена как по факту производства, так и раз в смену или даже раз в месяц.

Данные агрегируются по уровням: номенклатура товара, выпущенная партия, производственное задание, заказ на производство. В рамках единой модели все эти данные передаются без ручного маппинга.

Преимущества общей информационной модели хорошо видны на примере процесса планирования. Например, ERP сформировала этапы производства исходя из данных финансового учета и расчета себестоимости, MRP II выдала потребность в материалах, план загрузки оборудования, график отгрузки. Дальше возможны варианты. Если на предприятии есть APS, то она формирует сменные задания с очередностью выполнения позиций, оптимизирует и детализирует график поставок и отгрузок. Если APS нет, с графиками работают вручную. АСУ П в такой модели выступает в роли отдельного диспетчера: контролирует выполнение сменного задания, осуществляет интеграцию с АСУ ТП и оборудованием, контролирует комплектацию и сверяет план с фактом. Систем много, много стыков между ними — и на каждом возможны ошибки.

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

Автор инструкции

Важный вопрос: кто должен строить архитектуру единой информационной модели в конкретной компании. Задача сложная и ответственная: как правило, интеграция «съедает» до 40% всего бюджета автоматизации. При стыковке ERP и АСУ П появляется большой интеграционный слой и для того, чтобы их соединить, нужно изучить обе модели и настроить их взаимодействие, но на открытом рынке специалистов с такими компетенциями мало. Также очевидно, что пользователи из бизнес-подразделений не должны вникать в вопросы и устройство интеграции.

Осуществить интеграцию может лишь опытный еnterprise-архитектор, который понимает, какие объекты на что влияют «сверху донизу», и способен выстроить структуру потока данных. На практике требования к интеграции должен задавать вендор ERP-системы: стандарт B2MML в данном случае неэффективен.

Лидер на рынке

Технологически российская промышленность готова к переходу на полностью автоматическое управление производством. Но для этого необходимо повышать качество данных и разрабатывать подходы к интеграции различных систем. До 2022 года у нас уровень ERP закрывался такими продуктами, как SAP со своими моделями данных, идеологией, архитектурой. В какой-то момент SAP стал двигаться в сторону АСУ П, в нем появлялись модули, которые частично закрывали ее функции. Архитекторы были заточены под готовый продукт и не изучали, как он устроен внутри: зачем разбираться в сути, если есть готовые стандарты интеграции. И когда после 2022 года выяснилось, что продукт нужно замещать, оказалось, что делать это некому — многие специалисты уехали вслед за продуктом.

Сейчас формируется новое поколение архитекторов, которые, изучая разные решения, разные рекомендации вендоров, пытаются создать стандарт интеграции. Понимая суть того, что нужно, они могут предложить концептуальные решения, а на их базе уже реально будет создать новые продукты. Это долгий путь, но у него есть преимущество: отечественные разработчики учитывают предыдущий опыт и имеют все шансы не наступить на те же грабли. Поэтому отечественный «условный SAP» может появиться относительно быстро, срок в 3–5 лет вполне имеет место быть. Кто его сделает, пока непонятно: рынок промышленного ПО выбирает «лидера». Пробуют многие, но того, кто бы встал и сказал: «Должно быть так», — пока нет. Это действительно сложная задача, и ускорить ее решение может только консолидация профессионального сообщества.

Источник: IT Channel News.

Больше новостей читайте в сообществе SAPLAND в ВК и телеграм-канале SAPLAND: Новости экосистемы.