Шаблон бизнес-приложения на базе конструктора интерфейсов Totum для платформы ORT/CI

                                          том 21 № 2 (67), 2025, ст. 3

Современные промышленные и корпоративные информационные системы предъявляют высокие требования к анализу данных в реальном времени, оптимизации бизнес- процессов и цифровой трансформации предприятий [1]. Индустриальные платформы DATA-TRACK и EXPERT BASE позволяют организовать комплексное управление данными, потоковую обработку информации, оперативную аналитику и визуализацию. В их архитектуру заложены концепции цифровых двойников и Continuous Intelligence (CI), которые обеспечивают непрерывный анализ поступающих данных с использованием AI/ML для более точного контроля и быстрого принятия решений.

Внедрение подхода CI, объединяющего аналитику в реальном времени и технологии машинного обучения, ускоряет реагирование на события, автоматизирует процессы и повышает адаптивность бизнеса к изменениям [2]. Одновременно с этим Object Relations Technique (ORT) реализует объектно-ориентированное моделирование производственных сущностей и их связей в единой модели, находясь в основе аналитической платформы EXPERT BASE. В связке с потоковой платформой DATA-TRACK система EXPERT BASE образует основу комплекса ORT/CI, преобразуя массивы оперативных данных в управленческие решения.

Значительная часть трудозатрат при создании подобных автоматизированных систем приходится на разработку бизнес-приложений, используемых оперативным персоналом предприятия. Пользователи этих приложений – операторы оборудования, мастера, технологи – работают с системой через табличные интерфейсы, осуществляя просмотр и ввод данных [3]. В платформе ORT/CI для этого предусмотрена работа с данными посредством таблиц, а встроенный конструктор интерфейсов даёт возможность создавать пользовательские формы и логику обработки информации без традиционного программирования. Данный инструмент ориентирован в большей степени на аналитиков, чем на разработчиков-программистов. В состав ORT/CI интегрирован открытый no-code конструктор Totum, который служит основой для построения таких интерфейсов [4].

No-code подход подразумевает создание приложений с помощью визуальных средств и настроек вместо написания кода. Эффективность no-code/low-code решений в условиях цифровой трансформации подтверждается современными исследованиями: использование подобных платформ ускоряет разработку и позволяет вовлекать в процесс специалистов без навыков программирования [5]. Totum как no-code платформа именно так и действует – она позволяет создавать адаптивные интерфейсы на основе таблиц через графический вебинтерфейс и простой встроенный язык, практически исключая необходимость ручного кодирования. Благодаря этому даже пользователи без опыта программирования способны самостоятельно разрабатывать рабочие прототипы приложений на Totum [6]. Платформа

Totum обладает широкими интеграционными возможностями (REST API для обмена данными с внешними системами) и средствами автоматизации (внутренние скрипты, планировщик задач), что делает её пригодной для использования в сложных инфраструктурах. Кроме того, Totum распространяется с открытым исходным кодом и бесплатной лицензией, что выгодно отличает её от коммерческих аналогов и снижает затраты на внедрение. Таким образом, выбор Totum в качестве конструктора интерфейсов платформы ORT/CI обусловлен сочетанием её технических возможностей и экономической эффективности.

Целью данной работы является разработка шаблонного бизнес-приложения на базе платформы ORT/CI с использованием конструктора Totum для демонстрации ключевых возможностей этого no-code инструмента в промышленной среде. В создаваемом приложении-шаблоне предусмотрены следующие основные функции интерфейса:

• •    загрузка и ввод сопроводительных данных из описаний объектов ORT;

• •    квитирование (подтверждение) результатов измерений с получением сопутствующих сведений от внешних сервисов (например, температуры воздуха с метеорологического API);

• •    удалённый вызов функций интерфейсного конструктора и доступ к ним через API;

• •    формирование отчётной информации с графическим представлением (графики, диаграммы);

• •    печать сформированных отчётов;

• •    отправка уведомлений об отклонениях контролируемых параметров.

Методы

Разработка шаблонного приложения велась с акцентом на интеграцию без написания нового кода. Общая архитектура решения объединяет потоковую платформу DATA-TRACK, систему EXPERT BASE и конструктор интерфейсов Totum, причём их взаимодействие реализовано средствами конфигурации (настройка API и потоков данных) без разработки специального программного обеспечения. Основными инструментами служили: встроенный конструктор Totum для создания интерфейсов и логики, REST API платформы DATA-TRACK для обмена данными, а также Apache NiFi для оркестрации потоков данных между системами.

Первым шагом стало создание в Totum новой таблицы, структура которой соответствовала атрибутам ORT-сущности «Партия заготовок». Конфигурация выполнялась через веб-интерфейс Totum – были заданы поля таблицы, их типы и свойства, без написания кода вручную. В частности, добавлены колонки: спецификация, номер плавки, профиль, марка стали, количество заготовок, сечение, длина – все эти поля отмечены как обязательные для заполнения. Типы данных (строковые или числовые) выбраны в соответствии с требованиями объектной модели ORT и форматами JSON, возвращаемыми API DATA-TRACK, что обеспечило корректное сопоставление входных данных с колонками таблицы. Созданная таблица в Totum выступает временным хранилищем: в неё кратковременно помещаются сведения о партиях заготовок, поступающие извне, для отображения и возможного редактирования/квитирования оператором; после этого данные могут быть переданы дальше по технологической цепочке (например, в EXPERT BASE для аналитики либо обратно в DATA-TRACK с отметкой о подтверждении).

Для имитации внешнего источника данных на этапе прототипирования использовалась также «постоянная» таблица Totum. Постоянные таблицы создают локальную базу данных и не связаны напрямую с объектной моделью ORT, из-за чего они редко применяются в финальных решениях (ограниченная масштабируемость, недоступность через глобальные запросы). Однако на стадии разработки постоянная таблица оказалась полезна для моделирования внешней системы расчёта партий до появления реальной интеграции. В частности, была создана таблица «Партии заготовок» типa «простая» для ручного ввода тестовых данных, имитирующих результаты расчёта партии. Чтобы внешние модули могли извлекать эти данные через REST, в Totum настроены два эндпоинта (Remotes): partii_zagotovok для выборки всех новых записей (где флаг import_datatrack = false) и partii_zagotovok_set_true для обновления записей (устанавливает import_datatrack = true после обработки). При внешнем GET-запросе к первому эндпоинту возвращаются все необработанные строки из постоянной таблицы, а вызов второго эндпоинта помечает эти строки как импортированные. Такой механизм позволяет интеграционной связке (поток NiFi, см. ниже) единожды получать каждую новую партию из Totum и предотвращает дублирование при повторных запросах.

Доступ к данным системы DATA-TRACK осуществлялся через открытые API-интерфейсы (например, сервис dt-db-api для работы с объектами и их параметрами). Все вызовы API выполнялись с учётом авторизации по токену безопасности, выдаваемому платформой, а ответы содержали данные в формате JSON со всеми параметрами запрошенных сущностей. Для автоматизации извлечения этих данных и загрузки их в Totum был разработан интеграционный конвейер на базе Apache NiFi. Apache NiFi представляет собой платформу визуального программирования потоков данных, позволяющую настроить обмен и преобразование данных посредством связки готовых процессоров без написания кода. В рамках работы в NiFi был сконфигурирован процесс, выполняющий регулярный запрос к API

DATA-TRACK для получения списка партий заготовок и обработку ответа следующим образом: процессор InvokeHTTP обращается к REST-эндпоинту DATA-TRACK (GET-запрос к ресурсу партий заготовок с необходимыми заголовками авторизации и типа контента); далее EvaluateJsonPath (в комбинации с ExtractText) парсит JSON-ответ, извлекая ключевые поля каждой партии – спецификацию, номер плавки, профиль, марку стали, количество, сечение, длину. Полученные сведения через процессоры PutFile/LogAttribute сохраняются во внешний файл либо выводятся в журнал – это использовано на этапе отладки для проверки формата и корректности данных. Подобным образом настроенный поток NiFi автоматически запрашивал актуальные данные из DATA-TRACK, трансформировал ответ и готовил набор записей для дальнейшей загрузки в Totum. Применение NiFi позволило протестировать интеграцию вне среды Totum и может быть расширено для других сущностей или направлений обмена (например, NiFi-процесс способен выгружать данные из Totum во внешние системы благодаря богатому набору процессоров).

Помимо пакетной обработки через NiFi, в приложении реализованы прямые вызовы API по требованию пользователя средствами Totum. Конструктор Totum предоставляет встроенные функции для взаимодействия с внешними REST-сервисами из таблиц, что было использовано в финальных этапах конфигурации. В частности, для мониторинга этапа нагрева заготовок была создана отдельная временная таблица с формой фильтрации по дате; кнопка «Подгрузить данные за период» отправляет HTTP-запрос к dt-db-api DATA-TRACK, передавая указанный диапазон дат, и запрашивает список партий, проходивших через печь в этот интервал. Полученный ответ (формат JSON) автоматически сохраняется во встроенном поле data таблицы, после чего заложенные в Totum формулы разбирают JSON и распределяют значения по соответствующим колонкам. Таким образом, реализация обеспечивает динамическую подгрузку данных в реальном времени без вмешательства пользователя в структуру данных. Для предотвращения повторного импорта одних и тех же записей введён дополнительный флаг в модели DATA-TRACK – поле export_datatrack, которое изначально false и переключается в true после выдачи записи через API. При нажатии кнопки загрузки Totum запрашивает только записи с export_datatrack=false (ещё не загруженные), а по мере занесения их в таблицу Totum автоматически отправляет PATCH-запрос к API DATA-TRACK, помечая загруженные партии (export_datatrack=true). Эта логика гарантирует, что при повторных запросах интерфейс получит только новые данные, а ранее импортированные партии не дублируются в таблице.

Результаты

На начальных этапах разработки был проведён анализ возможностей платформы Totum и инфраструктуры ORT/CI, что позволило определить требования к шаблонному приложению и спланировать интеграцию. Непосредственная реализация началась с разработки базового интерфейса для сущности «Партия заготовок» в Totum и настройки обмена данными с платформой DATA-TRACK. В результате настройки таблиц Totum и интеграционных скриптов удалось получить и отобразить в интерфейсе реальные производственные данные. Например, в таблицу Totum были успешно загружены записи о партиях: марка стали SWRCH6R-B, номер плавки 2204959, профиль 5,5 мм, количество 61 шт, сечение 150×150 мм, длина 12000 мм; другая партия – SWRCH6R-B, номер плавки 2253957, профиль 5 мм, количество 50 шт, сечение 130×130 мм, длина 10000 мм. Эти данные корректно отобразились в соответствующих столбцах таблицы Totum, подтвердив правильность сопоставления полей и работу механизма импорта. Оператор интерфейса получил возможность просматривать параметры загруженных партий и при необходимости дополнять или исправлять сопроводительную информацию перед подтверждением.

Дальнейшее внимание было уделено полноценной интеграции между таблицами Totum и базой данных DATA-TRACK. В Totum были реализованы описанные REST-эндпоинты (Remotes) для получения и квитирования данных, что позволило устранить проблему дублирования записей. Теперь при внешнем запросе к API Totum возвращаются только новые (ещё не переданные) строки из постоянной таблицы, после чего автоматически выполняется отметка об их обработке. Параллельно, доработанный API DATA-TRACK (с учётом поля export_datatrack) и логика интерфейса Totum решили задачу дублирования при импорте: при нажатии кнопки загрузки данных запрашиваются лишь необработанные записи, и сразу после их отображения Totum отправляет в DATA-TRACK команду пометить эти записи как выгруженные. В результате даже при повторном использовании функции «Подгрузить данные» уже загруженные ранее партии не дубируются в таблице – каждая партия появляется в интерфейсе единожды. Кроме того, была запланирована интеграция с внешней средой Nucleo для запуска процесса обработки партии из интерфейса (отправка HTTP-запроса с идентификатором партии на запуск конвейера). Однако реализовать данную функцию не удалось из-за отсутствия необходимого метода в Nucleo на тот момент. Эта задача отнесена к числу возможных улучшений, которые предстоит выполнить при развитии системы.

На следующем этапе функциональность интерфейса была расширена для поддержки задач мониторинга производства и удобства пользователя. Разработана новая временная таблица «Партии заготовок в печи», предназначенная для отображения партий, проходящих стадию нагрева. Эта таблица включает форму фильтрации по дате: в верхней части интерфейса добавлены поля «Начальная дата» и «Конечная дата» с выбором через календарь, а также кнопка «Подгрузить данные за период». Пользователь может указать интересующий интервал (пример – выбран период с 01.04.2025 по 21.04.2025) и инициировать загрузку данных; при нажатии кнопки отправляется запрос к API DATA-TRACK, возвращающий все партии, загруженные в печь в заданном диапазоне дат. Логи Totum зафиксировали корректную отправку запроса и пересчёт таблицы при тестовом выборе дат, однако на указанном интервале система-источник не выдала записей (ответ API пришёл пустым). Это свидетельствует либо об отсутствии данных за этот период, либо о том, что API печи ещё не наполнен необходимой информацией. Тем не менее, сам механизм фильтрации и динамической загрузки данных отработал штатно и готов к использованию – как только API начнёт возвращать записи, они автоматически отобразятся в таблице без дополнительной доработки интерфейса.

Дополнительно, в интерфейсе таблицы «заготовки в печи» были активированы стандартные инструменты Totum для экспорта и импорта данных в формате CSV. В верхней панели появились кнопки «CSV-ЭКСПОРТ» и «CSV-ИМПОРТ», позволяющие соответственно выгрузить текущие данные таблицы в CSV-файл либо загрузить данные из внешнего CSV в таблицу. Функция экспорта упрощает сохранение результатов и их последующий анализ во внешних программах (например, Excel). Возможность импорта CSV особенно полезна в условиях отсутствия ответа от API: разработчики воспользовались ей для ручного наполнения таблицы тестовым набором данных и проверки работы фильтров и логики отображения. Тесты подтвердили работоспособность: при нажатии «CSV-ЭКСПОРТ» система корректно сформировала файл (в случае пустой таблицы – с заголовками колонок, но без строк), а опция «CSV-ИМПОРТ» успешно считывает файл нужного формата и добавляет записи в таблицу.

Для контроля работы алгоритмов Totum в процессе интеграции был задействован механизм логирования пересчётов таблицы. В режиме отладки интерфейс выводит подробный журнал выполнения формул и операций при обновлении данных. После реализации кнопки загрузки через API включение флага «Показать логи» позволило проследить последовательность действий: от запроса к внешнему сервису до распределения данных по колонкам. В логе видно, что при нажатии кнопки фиксируется событие пересчёта (RECALC) для соответствующей таблицы, время выполнения операции (порядка нескольких миллисекунд) и флаг изменений (CHANGES: true), указывающий на обновление служебного поля data. Хотя новых строк не добавилось (из-за отсутствия данных), наличие флага CHANGES=true подтвердило, что скрипт вызова API отработал и таблица обработала полученный (пусть и пустой) ответ. Таким образом, команда убедилась в корректности связки интерфейса с внешним API на уровне вызова. В перспективе этот механизм логирования продолжит служить средством мониторинга – любой сбой или задержка при обмене данными будет видна напрямую в интерфейсе Totum, что ускорит обнаружение и устранение проблем.

В результате реализации шаблонного приложения интерфейс Totum был успешно интегрирован с промышленной платформой DATA-TRACK и способен в автоматическом режиме принимать актуальные производственные данные, отображать их для пользователя и передавать обратно в систему сигналы о подтверждении. Ключевые функции выполнены: прототип поддерживает загрузку данных из ORT/CI в режиме реального времени, взаимодействие с внешним API, базовые операции с данными (фильтрация, экспорт/импорт) и подготовлен к расширению визуальными элементами (графики, диаграммы) и оповещениями. Шаблон продемонстрировал жизнеспособность no-code подхода в индустриальной среде, а его функционал может быть расширен и адаптирован под различные сценарии промышленного применения.

Обсуждение

Разработанный прототип продемонстрировал возможность эффективной интеграции систем оперативного уровня и бизнес-приложений с использованием платформ ORT/CI и концепции непрерывного интеллекта. Применение no-code подхода позволило реализовать полный цикл – от сбора производственных данных до их отображения и формирования управляющего воздействия – без необходимости программирования. Интеграция Totum с системой DATA-TRACK подтвердила практическую реализуемость такого подхода: данные, поступающие через Totum, могут быть оперативно использованы для визуализации, анализа и принятия решений на местах, что создает основу для построения полнофункциональных решений мониторинга и управления в реальном времени.

В ходе работы показано, что разработку подобных интеграционных решений можно существенно ускорить и упростить за счёт применения no-code инструментов. Использование конструктора Totum позволило в сжатые сроки создать действующий прототип интерфейса, а интеграция с системами DATA-TRACK и EXPERT BASE продемонстрировала, что no-code решение способно успешно дополнить экосистему Industry 4.0, обеспечивая пользовательский интерфейс и прикладную логику поверх потоковых данных в реальном времени. Платформа

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

Шаблонное приложение, разработанное на базе Totum, служит практическим доказательством концепции: даже сложные промышленные ИТ-платформы могут быть сопряжены с пользовательскими интерфейсами без написания программного кода, причём специалисты предметной области (технологи, аналитики) способны самостоятельно создавать необходимые приложения. Это существенно сокращает время отклика ИТ-систем на изменения требований бизнеса, снижает затраты на разработку и поддержку, а также повышает эффективность использования производственных данных на всех уровнях – от цеха до управленческого звена. Иными словами, применение no-code подхода в рамках ORT/CI способствует ускоренной цифровой трансформации предприятия, позволяя ИТ-решениям быстрее адаптироваться под новые задачи без длительного цикла классической разработки.

Вместе с тем, прототип выявил и ряд ограничений, которые предстоит преодолеть в дальнейшей работе. Некоторые задуманные функции не были до конца реализованы из-за объективных причин – например, запуск технологического процесса через Nucleo из интерфейса Totum пока невозможен ввиду отсутствия соответствующего метода в интегрируемой системе. Также при тестировании интерфейса обнаружилось отсутствие данных по определённым запросам (как в случае загрузки партий в печи за указанный период), что требует дополнительной настройки или наполнения со стороны источника данных. Эти моменты указывают на необходимость тесного взаимодействия с разработчиками базовой платформы (ORT/CI) для доработки требуемых API и обеспечения полноты данных. Ещё одним направлением развития является автоматизация обмена: на текущий момент обновление данных инициируется вручную (по нажатию кнопки), тогда как в промышленной эксплуатации целесообразно задействовать механизм фонового обновления – например, расписание запуска NiFi-потоков либо триггеры событий DATA-TRACK, чтобы информация в интерфейсе всегда была актуальной.

Перспективы дальнейшего развития включают расширение функциональности шаблона и более глубокое исследование пределов no-code подхода. В частности, планируется реализовать полноценные средства визуализации (оперативные графики, дашборды) на базе

Totum и внедрить систему оповещений о ключевых событиях (например, отклонениях параметров) – эти возможности были заложены в концепцию и частично подготовлены в прототипе, но требуют доводки. Кроме того, представляет интерес сравнение эффективности и трудозатрат no-code разработки с классическим программированием на реальных примерах (например, оценить, насколько быстрее и дешевле удалось создать прототип в Totum по сравнению с гипотетической разработкой аналогичного приложения с нуля). Такое сравнение позволило бы определить границы применимости no-code инструментов в крупных промышленных проектах. Наконец, следующими шагами могут стать масштабирование решения на другие типы ORT-объектов и бизнес-процессов предприятия, а также пилотное внедрение разработанного шаблонного приложения в промышленную эксплуатацию для сбора обратной связи от конечных пользователей. Продолжение этой работы будет способствовать дальнейшему накоплению опыта в области no-code цифровизации и формированию методик интеграции платформ типа ORT/CI с инструментами быстрой разработки интерфейсов.