Какую задачу планирования закрывает интеграция
На дискретном и процессном производстве планово-учётный контур почти всегда разорван. ERP держит производственные заказы, нормы расхода и финансовый учёт. MES управляет исполнением в цехе. SCADA и контроллеры (PLC) знают фактические показания линий посекундно. Системы качества фиксируют брак и отклонения. Между этими слоями данные чаще всего переносятся вручную: оператор в конце смены выгружает отчёт из MES в Excel, экономист загружает его в ERP на следующий день.
Бизнес-результат такой схемы предсказуем: план в ERP всегда отстаёт от реальности на смену-сутки. Решения о допзагрузке, переносе заказов и закупке сырья принимаются по устаревшим цифрам. Интеграционная шина закрывает именно этот разрыв: факт выработки, простои и брак попадают в планирование в момент события, а не постфактум.
Почему именно ESB, а не точечные интерфейсы
Стандарт ISA-95 (международный аналог — IEC 62264) формализует, как обмениваются данными бизнес-системы и цех. Он делит ИТ-ландшафт производства на пять уровней: Level 0 — физический процесс, Level 4 — предприятие/ERP, а MES занимает Level 3 как операционный мост. Уровни живут в разном темпе: Level 4 планирует месяцами и неделями, Level 3 — днями и часами, Level 0–2 реагируют за секунды (Symestic, ISA-95).
Из этого следуют два технических канала обмена. B2MML — XML-реализация ISA-95 для транзакционного обмена ERP↔MES (производственные расписания вниз, отчёты о выработке вверх). OPC UA — для непрерывных сигналов с цеха от PLC к операционному слою. Стандарт прямо рекомендует строить стандартизированные коннекторы вместо самописных point-to-point мостов, чтобы снизить связанность гетерогенных площадок (Symestic, ISA-95).
Talend ESB реализует этот подход на открытом стеке: Apache Karaf (рантайм OSGi), Apache CXF (веб-сервисы) и Apache Camel (маршрутизация и медиация) (Talend, Apache ESB). Высокопроизводительная шина обеспечивает интеллектуальную маршрутизацию сообщений по любому из ключевых Enterprise Integration Patterns, а в Talend Studio разрабатываются и публикуются mediation routes, data-, REST- и SOAP-сервисы (Talend ESB Functional Architecture).
Как устроены mediation routes и ETL-потоки
Mediation route в Talend ESB — это инкапсуляция возможностей Apache Camel: компоненты `MessageRouter`, `LoadBalancer`, content-based routing, трансформация и набор endpoint-ов (JMS, file, REST/CXF, JDBC) (Talend ESB Mediation Examples, Manualzz). Принципиальное разделение: ESB подходит для real-time обработки, а Data Integration (ETL) — для пакетной (Talend, Apache ESB). Поэтому в производственной интеграции эти инструменты применяют в паре.
Типовой контур выглядит так:
- SCADA/PLC → шина. Camel-route подписывается на OPC UA / MQTT-топики линий, нормализует теги (выработка, скорость, состояние) и кладёт событие в очередь JMS. Content-based router отделяет события «штука произведена» от «авария/простой».
- Шина → MES. Route обогащает событие контекстом заказа и пишет в MES через REST/SOAP, фиксируя фактический выпуск по операции.
- MES → ERP (B2MML). Mediation route трансформирует подтверждение производства в B2MML/IDoc-сообщение и доставляет в ERP, закрывая операцию и списывая сырьё по факту. Это прямой аналог сценария из академического исследования интеграции MES и ERP в автомобильной цепочке поставок, где двунаправленный обмен реализован через промежуточный документ (IDoc) (Tehnički Vjesnik, 2017).
- Системы качества → ERP/MES. Отдельный поток собирает результаты контроля и измерений; брак и причины отклонений уходят в планирование как корректировка доступного к отгрузке количества.
- ETL-слой. Ночные batch-потоки Talend DI агрегируют посменные показатели OEE, расход сырья и сверяют нормативы — туда, где реальное время избыточно.
ISA-95 здесь задаёт семантику: ERP отправляет вниз `ProductionSchedule` (набор заказов), MES возвращает вверх `ProductionPerformance` с фактическим выпуском и потреблением (Symestic, ISA-95).
Эксплуатация и наблюдаемость
Для промышленного контура критична наблюдаемость интеграции. Apache Camel и Talend ESB предоставляют JMX-интерфейсы для мониторинга маршрутов, endpoint-ов и обработчиков ошибок, а связку обычно дополняют сбором логов в Elasticsearch/Kibana и панелью hawtio (Kai Waehner, Camel & Talend ESB monitoring). Dead-letter-очереди и retry в Camel закрывают типичную проблему цеха — кратковременную недоступность MES или ERP: сообщение не теряется, а доставляется после восстановления.
Архитектурный принцип: ядро не трогаем
Важная инженерная установка такого решения — не модифицировать ядра ERP и MES. Бизнес-логика интеграции (маршруты, трансформации, обогащение, повторы) живёт в сервисах шины рядом с системами, а не внутри них. Используются зрелые международные стандарты (ISA-95/B2MML, OPC UA, EIP), а не самописные форматы обмена. Слабая связанность даёт отчуждаемость: команду интеграции или поставщика MES можно сменить без переписывания всего контура.
Что меняется в бизнес-процессе
Главный результат — не «настроенная шина», а изменённый процесс планирования и учёта. До интеграции цикл «факт в цехе → цифра в ERP» занимал смену-сутки и держался на ручных выгрузках. После — событие из цеха проходит SCADA → MES → ERP за секунды-минуты по стандартизированным маршрутам. План в ERP отражает фактическую выработку, простои и брак в реальном времени, диспетчер и экономист принимают решения по актуальным данным, а человеко-часы на сверку и перенос Excel-отчётов исчезают из процесса.
