No-code. Почему это удобно для оптимизации ПО в промышленном IT

Меня зовут Игорь Алексиков, уже почти 5 лет я работаю MES-консультантом в OLSOM, компании- вендоре ПО для производства и логистики.

В этой статье я немного расскажу про MES и производственный IT и покажу, каким образом мы используем продукты, разработанные по принципу no-code для адаптации решений под самые разные процессы на клиентских заводах.

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

Основные процессы на производстве, с которыми мы работаем

Наша MES-система может покрывать довольно широкий спектр процессов на производстве.

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

Если, допустим, на стратегическом уровне (в ERP) запланировано 10К деталей, а в реальности было произведено 8К, информация об этом и о причинах невыполнения плана дойдет до ERP-системы со значительной задержкой при передаче отчетов в электронном, а иногда даже в бумажном виде. Тогда как MES-системы, интегрированные в производственную линию, покажут это в ту же секунду в режиме реального времени и «оповестят» ERP о возможных нестыковках факта и плана.

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

Типичные workflow на заводе по изготовлению автокомплектующих

Основные процессы, которые пользуются популярностью среди наших заказчиков, это сбор факта об изготовлении продукции с различных производственных агрегатов, информации о том, при каких условиях была произведена деталь (температура внутри машины, давление и так далее). Далее — обработка этих данных и предоставление различных отчетностей: информация на веб-ресурсах, рассылка заинтересованным сторонам по почте, отправка отчетности в ERP-системы. Результаты нашего анализа помогают производственным командам правильнее планировать свои ресурсы, мониторить состояние системы и контролировать KPI своих операторов.

Также мы поддерживаем сложные производственные сценарии — контроль жесткой последовательности заказов, где идет контроль каждой детали: в случае, когда на одной линии собираются машины разных комплектаций поставка компонентов должна четко соответствовать списку идущему по конвейеру (чтоб на ваш красные BMW с кожаным салоном не попала синяя дверь с текстильным).

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

Контрагенты и внешние связи, с которыми мы взаимодействуем (ERP, EDI)

MES-системы — промежуточный слой между машинами и различным персоналом на заводе и вне его, поэтому интеграции с разными службами и сервисами завода для нас имеет очень высокий приоритет. Мы выработали свои протоколы коммуникации и взаимодействия с различными машинами по методам PLC, RestAPI и другим коммуникациям. После получения информации от машин, данные необходимо отправлять в ERP-системы для финансовых отчетностей, поэтому мы поддерживаем интеграцию в разные системы, основной является SAP.

Для обмена логистической информацией наш продукт хорошо интегрируется с EDI-системами для получения заказов и отправки накладных. Это помогает максимально избежать бумажного оборота и делает процесс обмена данными мгновенным.

Кратко про принцип low code — no code

С одной стороны, наша работа основывается на общих принципах, регламентах и международных стандартах производства, с другой стороны — мне еще не приходилось встречать два одинаковых завода, поэтому система должна быть достаточно гибкой; прибавьте к этому, что, как правило, большие заводы работают в режиме 24/7, т. е. все нужно делать быстро и желательно сразу на продакшене.

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

Если сравнить структуру блоков и код, который ему соответствует, то получим примерно следующую картинку.

~ 400 строк кода

Основные функции, которые реализованы в нашем продукте — это импорты и экспорты различных заказов и отчетностей, элементы коммуникаций с разными интерфейсами производственных машин и БД, элементы контроля статуса продукции на всех этапах производства, большой спектр перехвата и обработок ошибок во время исполнения ПО, блоки, отвечающие за вывод информации оператором станций.

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

Затем идет этап деливери или поставки, когда система выкатывается в производство. Это может быть работа в поле, непосредственно на производстве. Система интегрируется, отлаживается и запускается в работу. Также процесс поставки может осуществляться удаленно.

Система становится Mission-critical Application, без которой завод уже не может полноценно работать. Информационные потоки диджитализируются, и все замыкается на MES: она становится сердцем производственного процесса.

В чем принцип выигрывает перед обычным алгоритмом

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

Средний срок разработки и внедрения решения — три месяца.

Гибкость. Продукт позволяет быстро подстраиваться под необходимые потребности. Особенно часто это помогает, когда контрагент заказчика меняет какие-то форматы отправления заказов. Мы можем быстро поменять необходимые параметры в системе. А при более больших и сложных изменениях, легко перестроить архитектуру принятия заказов без всякого влияния на процессы текущего производства.

Как происходит замена — на иллюстрации.

Легко переопределить логику регистрации производства, убирая ненужные блоки функционала и добавляя новые.

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

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

Даже после выкладки новой конфигурации, мы можем быстро изменить направление стрелки в конфигурации, и старая логика заработает, как это было раньше. Часто случается, когда заказчик решает временно отказаться от обновления.

Нам очень важно иметь возможность переключаться на старый функционал в случае любых изменений на производстве (напомню, что большинство заводов, с которыми мы сотрудничаем, работают в режиме 24/7, их процессы связаны с их контрагентами и скорость изменений становится чуть ли не первым параметром).

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

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

Профиль специалиста. Для работы MES-консультанта не обязательно знать какие-либо языки, но необходимы такие навыки: быстрое понимание разных бизнес-процессов, их анализ и воплощения их в продукте методами алгоритмического мышления.

При этом одна из проблем, с которой нам приходится бороться, когда проект переходит на этап поддержки, связана именно с простотой использования системы и «человеческим подходом». Разные люди под одну и ту же задачу создают диаграммы разного вида. Потом другим MES-консультантам бывает сложно разобраться в чужой диаграмме, а вопросы очень часто нужно решить как можно более оперативно, чтобы не «положить» работающий завод. Для решения этой проблемы мы работаем над типизацией основных сценариев и диаграмм под них.

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

В данном подходе не нужно хранить в уме, в какой части программного кода храниться нужная функция. Такая диаграмма является самодокументируемой, что помогает найти нужный блок и заменить его. За каждым блоком скрыта большая функциональная логика, о которой не нужно задумываться специалисту во время конфигурации проекта, следовательно, не тратиться много времени на построение своего нового «велосипеда», что помогает соблюдать стандартность решений.

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

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