Источник: «Инфосистемы Джет»
Информационные системы и оборудование современных промышленных предприятий генерируют огромные объемы данных, которые могут быть использованы для повышения эффективности производства и принятия лучших управленческих решений. Директор центра корпоративных решений «Инфосистемы Джет» Дмитрий Кулагин рассказывает о различных вариантах сбора и управления технологическими данными на производстве на примере реальных кейсов.
Роль данных в цифровой трансформации предприятий
Промышленные предприятия идут по тому же пути цифровой трансформации, который в свое время прошли банки и телеком, при только теперь они должны опираться на импортозамещенные технологии. Безусловно, данные являются ключевым компонентом цифровых предприятий, позволяя повышать безопасность, экологичность, эффективность и управляемость производства, сокращать внеплановые простои оборудования. Эти возможно, в частности, благодаря созданию платформ управления технологическими данными.
Влияние данных на деятельность промышленного предприятия.
Источник: «Инфосистемы Джет»
Согласно опросу руководителей 700 крупных производственных компаний из 23 стран, проведенному аналитиками PwC, две трети из них пока находятся на начальном этапе трансформационных программ, инвестируя в этот процесс в среднем 1,8% выручки ежегодно. Сами же консультанты называют оптимальным показатель в 3%. Из наиболее популярных направлений, в которых уже внедрены цифровые решения, – ТОиР (Техническое обслуживание и ремонт), качество и операционная эффективность, цифровые двойники.
При этом, если раньше первоочередным эффектом от реализации трансформационных программ руководители чаще всего называли оптимизацию себестоимости производства за счет повышения эффективности использования активов и снижения простоев, то сегодня на первое место выходит эффект увеличения гибкости и адаптивности предприятий. Вероятно, причиной этому является необходимость реагировать на непредсказуемые изменения мирового рынка, либо многие компании уже прошли первоначальный этап внедрения цифровых решений, на котором происходит оптимизация себестоимости.
Актуальные направления цифровизации предприятий.
Источник: «Инфосистемы Джет»
Важно также отметить, что цифровая трансформация – длительный и сложный процесс. Согласно опросу, более 60 российских производственных предприятий, компании, которые занимаются цифровой трансформацией менее двух лет, чаще всего не достигают от нее существенного эффекта – он появляется только спустя 3-5 лет.
Каждое предприятие собирает и использует данные по-своему, в зависимости от сферы деятельности, бюджета, технологического ландшафта, желаемых результатов и прочих факторов. Но в любой компании программы цифровизации основываются на принципах доступности и достоверности данных. Статистика показывает, что отраслевые лидеры стремятся работать с данными наиболее глубоко и быстро: многие предприятия используют хранилища данных, считают показатели эффективности вплоть до KPI каждого оператора несколько раз в день или в реальном времени.
Этапы аналитики данных в промышленности и барьеры на пути
Чтобы достичь хороших результатов, необходимо пройти определенный путь. Мы выделяем на нем три этапа, которые могут проходить последовательно или частично накладываться друг на друга. На первом этапе собираются и обрабатываются в основном исторические данные – например, регламентные отчеты за длинные временные периоды. В ретроспективе фиксируются произошедшие отклонения от нормы и анализируются их причины. Уже на этом этапе компании требуется заложить фундамент для будущего развития: внедрить технологии и процессы сбора, хранения и обработки данных. Этот этап мы наблюдаем на многих российских предприятиях, и уже сейчас они фиксируют первые положительные результаты. К примеру, руководители получают актуальную информацию, позволяющую принимать объективные решения по управлению процессами и персоналом.
Уровни цифровой зрелости и этапы цифровизации предприятий.
Источник: «Инфосистемы Джет»
На втором этапе полученные данные начинают использоваться не только людьми, но и алгоритмами, благодаря чему становится возможным как ретроспективная оценка, так и предсказание будущих результатов. Когда на предприятии сформированы базы данных, эти данные очищены и доступны для использования программами, можно внедрять предиктивную аналитику – например, по ремонтам оборудования, или прогнозированию объемов производства. Важно уточнить: на этом этапе в компании должны произойти еще и организационные изменения – переход к гибким методологиям. Это связано с тем, что многие гипотезы, связанные с предиктивной аналитикой (например, с цифровыми советчиками) необходимо тестировать достаточно быстро.
На третьем этапе аналитика данных выходит за пределы одного предприятия или одной доменной области (например, только производства) и встраивается в процессы взаимодействия систем, работающих на разных предприятиях. Это может быть, например, взаимодействие поставщиков оборудования и их заказчиков для получения оптимальных цепочек поставок, взаимодействие систем производства и вспомогательных систем (вентиляции, метеоданных и т. п.). Этого уровня на данный момент удалось достичь совсем немногим компаниям как в России, так и в мире. Опрос Ernst&Young 2022 года показал, что барьерами на пути цифровизации промышленных предприятий становятся проблемы технической инфраструктуры, информационной безопасности, недостаток инвестиций, нехватка квалифицированного персонала и компетенций в ИТ.
Барьеры на пути цифровой трансформации на основе данных.
Источник: «Инфосистемы Джет»
Чтобы преодолеть эти барьеры, зачастую необходимы большие вложения. Производственный сектор генерирует огромные объемы данных: например, одна нефтедобывающая платформа может выдавать до 1 терабайта данных в сутки. И даже если речь идет об 1 тыс тегов (метаданных, помогающих описать информацию для ее последующего поиска и классификации) с дискретностью в 50 миллисекунд, то за год это до 30 ТБ информации. А на обычном предприятии таких тегов обычно тысячи и десятки тысяч. Поэтому для хранения всей этой информации предприятию нужны хранилища, вычислительные ресурсы, резервирование каналов связи, средства информационной безопасности. Важен рациональный подход: понимание того, какие именно данные собирать и подвергать анализу.
Зато, когда этот процесс выстроен, компании могут решить целый ряд актуальных задач. Вот с какими запросами за последние два года заказчики обращались в Центр Корпоративных Решений компании «Инфосистемы Джет»: организация операционного и архивного хранилища технологических данных, автоматизация отчетности и планирования, построение цифровых советчиков, контроль режимов простоев для повышения производительности, расчет технологических балансов, аналитика по оборудованию и техпроцессу, построение специализированных АРМ, предиктивная аналитика, оценка качества.
Отметим, что уровень цифровизации компании не всегда зависит от ее масштаба. Так, некоторые наши заказчики имеют внушительные центры компетенций и нуждаются в помощи по решению точечных вопросов. Но есть и достаточно крупные компании, которые вообще не имеют в своих дивизионах культуры работы с данными и первоначально приходят с запросом на базовую функциональность – такую, как автоматизации отчетности. Исходя из запросов, мы видим, что во многих случаях данные у них собираются фрагментированно, лишь в тех объемах, которые нужны соответствующим службам. На многих предприятиях они хранятся в бумажном виде или в таблицах Excel. Могут иметься локальные СУБД, но без централизованного хранения.
Задачи платформ управления данными.
Источник: «Инфосистемы Джет»
Все эти вызовы мы так же помогаем преодолеть. Ниже я расскажу о двух реальных проектах в компаниях наших заказчиков, которые обратились к нам с разными задачами, и способы сбора, хранения и аналитики данных тоже оказались разными. В первом случае использовалось коробочное решение для сбора и обработки данных на локальных мощностях, а во втором – Open Source компоненты и облачные Managed Services.
Кейс 1: Сквозной функционал MES
Первый заказчик пришел в «Инфосистемы Джет» с запросом на централизованное накопление и систематизацию разрозненной технологической и производственной информации с АСУ ТП и смежных систем, налаживание контроля технологических параметров и производственных показателей, а также автоматизацию и унификацию отчетности. По сути, это именно тот базовый уровень цифровизации, с которого начинается дальнейший путь. Перспективной целью проекта было построение на предприятии MES-системы.
В качестве решения была предложена промышленная платформа Zyfra Industrial IoT Platform (ZIIoT). Это коробочный продукт от вендора «Цифра», входящий в реестр отечественного ПО. Он представляет собой набор из более чем ста микросервисов, которые оркестрируются Kubernetes, и может развертываться локально или в облаке. Уточним, что это решение реализует базовые функции MES, а его преимуществом является то, что разработка ведется в единой среде, в которой пользователи работают с уже имеющимися сервисами, а сервисы используют единый оркестратор, общие методы доступа к данным, сквозные авторизацию и логирование.
Для обеспечения сбора, хранения и обработки данных была подготовлена локальная инфраструктура на базе имеющихся у заказчика вычислительных мощностей от Kepware. Непосредственно с АСУ ТП данные поступают на OPC-сервера в качестве централизованной точки сбора. Для взаимодействия этих серверов со всеми опрашиваемыми системами и контроллерами необходимы драйвера к применяемым проприетарным промышленным протоколам – в основном это PROFINET и Modbus. Для опроса на ту же машину, где находится OPC-сервер (либо на другую), установлены специальные службы – zif interface agent и MiNiFi. Общая архитектура решения для организации сбора данных представлена на изображении:
Архитектура решения для сбора данных.
Источник: «Инфосистемы Джет»
Для обеспечения информационной безопасности по требованию заказчика в сетевой инфраструктуре выделялся отдельный сегмент в демилитаризованной зоне (DMZ). Передача данных из службы сбора в корпоративный сегмент идет уже не по OPC, UA или проприетарным протоколам, а по защищенному каналу HTTPS. Решение имеет две шлюзовые станции, основную и резервную: в случае поломки OPC-сервера взаимодействие будет происходить напрямую с АСУ ТП.
Собранные данные конвертируются в необходимый формат – например, JSON или AVRO, и передаются в Kafka, там они учитываются соответствующими сервисами: сервис временных рядов, сервис событий и т. д. Интерфейс платформы с определенной периодичностью спрашивает у своих менеджеров и агентов, с какой частотой ему нужно собирать данные, получает сверху настройки расписания и конфигурации. Он так же имеет резервирование: создается группа интерфейсов, основной и резервный. Разработчиком предусмотрены три вида резервирования: горячее, теплое и холодное. В нашем случае используется горячее – когда оба интерфейса собирают данные одновременно, но резервный не передает их наверх.
В качестве инструментов для сбора данных используются Interface Agent (служба, которая устанавливается на шлюз, сканирует систему в поисках доступных интерфейсов, собирает данные по ним и передает на интерфейсы задания) и Interface Manager (компонент платформы, который формирует задание для интерфейса, принимает данные от агентов и передает им конфигурации и задания). У Interface Manager существует удобное фронтэнд-приложение, в котором администратор системы может создавать и удалять интерфейсы, редактировать их без непосредственного доступа к машине, на которой они находятся.
Организация хранения данных.
Источник: «Инфосистемы Джет»
На платформе используются три типа хранилища: Cassandra – для хранения временных рядов, Postgres – для хранения метаданных платформы и витрин и MiniO – S3 хранилище для файлов и документов (например, сюда можно выкладывать фотографии операторов или контролеров качества после замеров, из этих данных формировать справочники и другую НСИ).
Также в решении используется сервис ручного ввода, необходимый в тех случаях, когда автоматизированный сбор данных с АСУ ТП и смежных информационных систем невозможен. Этот инструмент позволяет вводить данные по расписанию или по требованию, здесь можно редактировать значения, удалять их, фильтровать, контролировать границы данных. В проекте мы создали набор листов операторского ввода, которые сгруппированы в так называемые операторные. Каждый оператор или группа операторов имеет доступ к своей операторной, есть разграничение прав доступа. Настраиваются маски для ввода данных и проверки по допустимому или предупредительному диапазону (то есть оператор либо не сможет ввести данные, которые не попадают в нужный диапазон, либо при вводе таких данных система выдаст ему предупреждение). Введенные данные попадают в сервис хранения временных рядов, сохраняются в тегах: можно поднять историю действий.
Моделирование данных в данном случае выстроено таким образом, чтобы пользователи работали не с тегами, а с неким слоем абстракции, который отображает понятную им предметную область. Например, модель оборудования визуально представляет собой иерархический организационно-технический справочник, в котором все объекты распределены по уровням – холдинга, производства, цеха, фабрики, участка и т. д. Каждый из объектов имеет свои свойства: например, у оборудования это могут быть температура, скорость, давление, состояние, сроки ввода в эксплуатацию, дата последнего ремонта, текущая наработка. Для каждого типа объектов первоначально реализуется прототип, который наделяется типовыми свойствами и тиражируется. Наряду с моделью оборудования существуют также модели материалов и операций. На основе модели материалов впоследствии строятся спецификации контроля качества, разрабатываются образцы проб, налаживаются графики аналитического контроля.
Кейс 2: Обеспечение доступа к технологическим данным и цифровой советчик
Целью второго заказчика было обеспечение персонала удобными инструментами для доступа к технологическим данным и внедрение цифрового советчика (виртуального ассистента), который помогал бы оператору при работе с устройством контроля температуры. В отличие от первого кейса, здесь уже имелся технологический процесс, который генерировал данные с дискретностью от 1 до 50 миллисекунд.
В этом проекте мы применили смешанный подход Lake House, сочетающий технологии корпоративного хранилища (DWH) и озера данных (Data Lake). Это новая открытая архитектура, которая взяла самое лучшее от своих «истоков»: DWH и Data Lake. В ней используется структура данных и методы управления ими, аналогичные хранилищам данных, но при этом поддерживаются все форматы данных и обеспечивается сквозной непрерывный доступ к ним в режиме реального времени как в озерах данных. Кроме того, Lake House совместим с инструментами бизнес-аналитики и различными библиотеками.
Различия между подходами Data Warehouse и Data Lake.
Источник: «Инфосистемы Джет»
Первой нашей задачей в рамках этого проекта был организован сбор различных данных, их интеграция в единое информационное пространство и предоставление их пользователям – технологам и всем другим заинтересованным лицам. Источниками данных были АСУ ТП, MES-системы, отдельные файлы и множество временных рядов. Этот сценарий был реализован как на открытых компонентах (Apache Airflow, Kafka и др.) в инфраструктуре заказчика, так и по большей части в облачной среде. Связано это было с необходимостью оптимизации стоимости хранения данных и с потребностями по этапного масштабировать решение.
Итак, источники данных передают данные на OPC-сервер, где установлены решения ibaPDA и ibaDat Coordinator. Последний делает постобработку: собирает данные с ibaPDA, агрегирует первоначальную информацию по единицам продукции и превращает ее в parquet-файлы. Они используются для обеспечения эффективного хранения и передачи информации, так как занимают существенно меньше места, чем JSON или CSV. Помимо АСУ ТП опрашиваются базы данных нескольких информационных систем, отображающие результаты деятельности определенных систем. Эти данные собираются в фоновом режиме, обновление витрин и реплик происходит с периодичностью в один час. В инфраструктуре заказчика установлен Airflow, который выполняет инкрементальное получение данных из источников и их проверку, после чего перемещает parquet-файлы в облачное хранилище S3. Метаданные, которые используются в Airflow, хранятся локально в Postgres.
Так как облачное файловое хранилище стоит существенно дешевле, чем облачные Managed Services, мы и создали гибридное решение. В облаке используется база данных Greenplum, обладающая рядом существенных для нас преимуществ: имеет полную SQL-совместимость, поддерживает разные языки программирования, имеет библиотеки для работы с ML и геоданными, хорошо горизонтально масштабируется и предоставляет возможность быстрой параллельной загрузки данных. Используется фреймворк PXF – возможность использовать внешние таблицы в Greenplum. Таким образом мы эксплуатируем не огромную дорогостоящую базу Postgres как Managed Service, а объемное хранилище S3 – то есть придерживаемся подхода Data Lake. В файловых пакетах хранится вся собранная информация, к которой можно обращаться в целях аналитики и исследований.
Создание реплик данных также относится к концепции озер данных. Собственный фреймворк, разработанный специалистами «Инфосистемы Джет», позволяет загружать эти данные и создавать их реплики, просто указав на них в метаданных. Таким образом моделирование реплик данных и наполнение платформы происходит автоматически на основании метаданных в источниках.
Моделирование данных на основе фреймфорка Jet D Framework.
Источник: «Инфосистемы Джет»
Для моделирования определенных витрин данных на основе информации из хранилища мы используем классический инструмент Power Designer и уже подход, свойственный DWH. Чтобы сформировать витрину, необходим архитектор данных, который хорошо знает процессы и может выстроить четкую структуру данных.
Реализация потокового сценария.
Источник: «Инфосистемы Джет»
Вторая наша задача в рамках этого проекта – создание советчика, который работает с данными оборудования в режиме реального времени, с дискретностью 50 миллисекунд. Эта задача реализована исключительно на открытых компонентах, основная часть которой работает локально у заказчика.
Аналитика информации с оборудования необходима операторам для контроля работы этих устройств, своевременного выявления неполадок. Источником здесь является OPC-сервер, компоненты Kafka с использованием библиотеки PLC4X формируют образы, передают их через адаптеры в приложение, которое запрашивает обработку этих данных моделью машинного обучения. Расположенная в облаке модель обрабатывает данные и через веб-приложение выдает оператору заключение и рекомендации. Всё это работает в режиме реального времени.
Как вы видите на примере этих двух кейсов, для организации работы с данными могут применятся разные подходы, в зависимости от специфики процессов организации и ее целей, но одно обстоятельство всегда неизменно, – любой проект по цифровизации должен вестись при участии опытной профессиональной команды. Если вы хотите правильно организовать работу с данными на своем предприятии и оцифровать процессы, обращайтесь к нам, мы поможем найти правильный подход к решению ваших задач.