Системы автоматизации производства связывают план заказа в ERP, выполнение операций в MES и сигналы оборудования через SCADA по согласованным идентификаторам и событиям. Чтобы выбрать состав систем, сначала разберите путь одной партии: от утверждённого задания до принятого факта выпуска. Затем закрепите владельца каждого поля, правила передачи, права на исправления и порядок работы с расхождениями.
Карта систем
Практическая граница такова: ERP хранит деловой план и итог заказа, MES ведёт исполнение в цехе, SCADA собирает состояние процесса и передаёт команды оборудованию в пределах своего контура. Такая карта задаёт вопросы к интеграции, а состав приложений зависит от конкретного производства.
Начните с перечня решений, которыми сотрудники уже пользуются. Название класса продукта само по себе мало говорит о фактической роли: учётная система может содержать сменные задания, а цеховое приложение — складские остатки. Для каждого действия запишите, где возникает исходная запись, где её утверждают и куда возвращается результат. Так проявятся дублирование и пробелы между слоями. Критерии выбора связывайте с рабочим событием, минуя перечень модулей в презентации поставщика.
| Слой | Рабочий вход | Выход для соседнего слоя | Владелец решения |
|---|---|---|---|
| ERP | Заказ, номенклатура, версия плана | Утверждённое задание и приёмка выпуска | Плановик и ответственный за учёт |
| MES | Задание, маршрут, партия, доступные ресурсы | Статус операций, подтверждённый выпуск, отклонение | Начальник смены и технолог |
| SCADA | Теги и состояние технологического процесса | Событие оборудования с отметкой времени | Инженер АСУ ТП |
| Цеховые устройства | Измерения и команды контроллера | Первичный сигнал или исполнительное действие | Ответственный за оборудование |
Это проектная карта обмена, применимость которой зависит от производства. На непрерывном процессе партия может означать иной объект учёта, чем на дискретной линии. Зафиксируйте местное определение партии, единицу измерения и правила связи с заказом. Для схемы достаточно одного маршрута с реальными полями, которые доступны команде: номер заказа, партия, операция, версия задания, состояние оборудования и подпись принимающего сотрудника.
Путь партии
Возьмите один типовой производственный заказ как предмет проектирования, без вымышленного клиента и ожидаемой экономии. Входом служит утверждённая версия плана в ERP. Интеграционный сервис передаёт в MES идентификатор заказа, партию, номенклатуру, нужный объём и маршрут. MES связывает задание с рабочим центром и фиксирует назначение исполнителя. Весь поток удобно описать таблицей состояний: кто создаёт событие, кто вправе менять его статус и какой документ подтверждает переход.
- Плановик выпускает задание в ERP и отмечает его версию. Сервер интеграции проверяет право отправителя и полноту обязательных полей до передачи в MES.
- Начальник смены назначает операцию и подтверждает готовность ресурсов. MES сохраняет ссылку на исходное задание, чтобы позднее сравнить фактическое действие с планом.
- Контур SCADA получает сигнал от оборудования с отметкой времени и техническим идентификатором. Связь сигнала с партией задаёт проектный механизм сопоставления; сам сигнал требует отдельного подтверждения выпуска.
- Оператор подтверждает выполненную операцию и отмечает брак или остановку по утверждённому справочнику причин. Ответственный сотрудник разрешает спорные записи после проверки первичных данных.
- После приёмки MES передаёт в ERP итог по партии и ссылку на журнал операций. ERP отражает подтверждённый факт, сохраняя исходную версию плана для сравнения.
Сигналы оборудования бывают частыми и разнородными. Поэтому в проектной схеме ERP получает итоговое событие, а детальные измерения остаются в техническом журнале с доступной ссылкой. Для сбоя связи определите очередь, повторную передачу по устойчивому идентификатору события и сверку числа принятых записей. Повтор сообщения должен сохранять одну хозяйственную операцию: это требование к проекту интеграции, которое проверяют отдельным испытанием.
Границы данных
Граница между системами проходит по смыслу данных. ERP отвечает за утверждённый план и учётный результат, MES — за контекст выполнения, SCADA — за наблюдаемые параметры и управление процессом в своей зоне. Если каждое приложение правит номер партии, причину остановки и факт выпуска независимо, сверка превращается в ручной поиск последней версии. Назначьте один источник истины для каждого поля и документируйте правила преобразования единиц измерения.
- Общий ключ: заказ, партия и операция с правилами создания и изменения. При дроблении партии сохраняйте связь дочерних записей с исходной.
- Версия: идентификатор плана и маршрута сопровождает каждое событие. Старая версия отправляется на разбор вместо тихой подмены задания.
- Время: храните исходную отметку устройства и момент приёма сервером; расхождение учитывайте при расследовании порядка событий.
- Справочник: коды причин простоя, качества и единицы измерения согласуют владельцы процессов до настройки обмена.
- Доказательство: журнал сохраняет автора действия, исходные значения, причину исправления и ссылку на первичную запись.
В интерфейсе проекта покажите сотруднику источник каждой цифры. Отдельно обозначьте измерение датчика, подтверждение оператора и принятое количество: это разные виды факта. Сервер проверяет полномочия перед записью и изменением статуса; модель, если она помогает суммировать журнал, готовит только черновик. Ответственный человек сверяет спорный вывод с первичным событием и подтверждает решение. Подход к ручной сверке плана и факта раскрыт в материале о производственном плане и простоях.
Нужна карта обмена для вашего цеха и систем?
Права и отклонения
Опишите роли до подключения интерфейсов. Плановик вправе выпускать и отменять задания в ERP, но изменение уже назначенной операции требует уведомления цеха. Начальник смены назначает исполнителя и проверяет доступность рабочего центра. Оператор отмечает собственную работу, технолог разбирает причины брака, инженер АСУ ТП отвечает за технические теги. Права на подтверждение выпуска и исправление задним числом выдавайте разным ролям там, где этого требует внутренний регламент.
| Исключение | Что удержать | Кто решает |
|---|---|---|
| Нет идентификатора партии | Сигнал оставить в журнале разбора, учётную запись отложить | Начальник смены |
| Повтор события | Один принятый факт по ключу события, повтор в аудите | Владелец интеграции |
| Иная версия плана | Передача на сверку, исходное задание сохранено | Плановик и технолог |
| Сбой связи с оборудованием | Локальная запись и последующая сверка очереди | Инженер АСУ ТП |
| Спорное качество | Открытый статус до проверки первичных данных | Ответственный за качество |
Правило «удержать» здесь обозначает проектное состояние; команду остановки оборудования определяет отдельный контур. Безопасность технологического процесса определяет отдельный утверждённый контур управления. При изменении данных оператор указывает причину, система сохраняет прежнее значение, а уполномоченный сотрудник подтверждает исправление. Разбор исключений проводите на тех же идентификаторах, что использует обычный маршрут партии; иначе спорная запись выпадает из общей сверки.
Для руководителя полезен отдельный вид расхождений: задания без назначения, операции без подтверждения и принятые факты без исходного задания. Отчёт показывает ссылки на первичные записи и владельцев открытых вопросов. Формат такой витрины можно связать с производственным дашбордом, сохраняя ручную приёмку там, где данные противоречивы.
Выбор и приёмка
Выбирать систему удобнее после описания границ данных. Составьте короткий реестр существующих ERP, MES, SCADA и устройств; отметьте владельца, доступные интерфейсы, документы по обмену и ограничения доступа. Затем проверьте, какой слой уже ведёт нужное событие и где возникает ручной перенос. Для нового продукта требуйте демонстрацию именно вашего маршрута партии на согласованном наборе обезличенных данных. Рейтинг поставщиков без сопоставимых испытаний здесь мало помогает.
- Согласуйте словарь заказа, партии, операции, статуса и причины отклонения. Зафиксируйте источник каждого поля и ответственного за справочник.
- Пройдите успешный маршрут от утверждения плана до принятого факта. Сверьте идентификаторы, версии, единицы измерения и журнал авторов.
- Повторите передачу одного события, смените версию задания и разорвите тестовое соединение. Проверьте очередь, восстановление и отсутствие двойного учёта.
- Передайте роли пользователям с разными правами. Сервер должен отклонять действия без полномочий; разрешённые исправления оставляют прослеживаемую историю.
- Оформите акт приёмки с открытыми исключениями, владельцами и решением ответственного человека. Итоговая запись в ERP должна ссылаться на подтверждённый факт в MES.
Критерии выбора: покрытие нужных событий, понятный контракт обмена, работа при обрыве связи, управляемые права, доступный аудит и проверяемая выгрузка данных. Сравнивайте варианты по одним сценариям и отмечайте ограничения, которые проявились в испытании. Если задача пока сводится к построению плана, смежный маршрут разобран в статье о планировании производства. Для проектирования связей между системами и регламента приёмки доступна услуга автоматизации бизнес-процессов.
Контур готов к приёмке, когда команда воспроизводит маршрут партии, объясняет происхождение итогового факта, видит каждое отклонение и проверяет полномочия на исправление. Решение о спорной записи остаётся за назначенным сотрудником.