Интеграция ПО БСУ с учётом, диспетчеризацией и 1С

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

Архитектуру строят вокруг производственного задания и уникального номера замеса. АСУ сохраняет технологическую автономность, а диспетчеризация, весовая, лаборатория и учётная система обмениваются строго определёнными данными с подтверждением, журналом ошибок и возможностью восстановления.

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

АСУ отвечает за безопасное выполнение цикла и фактические дозы. Учётная система не должна напрямую управлять клапанами, а производственная программа — самовольно изменять финансовые документы.

В рабочей документации по этому узлу фиксируют перечень систем, владельца каждого справочника, направления обмена, запрещённые операции и ответственность. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: для каждого объекта есть единственный источник истины и формально определённый получатель.

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

Каждый замес также имеет уникальный номер и связь с заказом, линией, временем и оператором. При повторной отправке сообщения система не должна создавать дубль.

В рабочей документации по этому узлу фиксируют форматы идентификаторов, правила уникальности, связь заказа и замесов, обработку повторов и срок хранения. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: любой производственный факт прослеживается до исходного заказа без ручного поиска по названию.

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

Рецепт передают с версией и статусом, а не только с названием. Изменение состава после запуска заказа должно либо создавать новую версию, либо блокироваться по принятой процедуре.

В рабочей документации по этому узлу фиксируют коды, единицы, точность, соответствия справочников, версии рецептов, статусы и правила архивирования. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: обе системы одинаково интерпретируют каждый материал и используют подтверждённую версию рецепта.

Задание содержит объём, рецепт, число замесов, приоритет, транспорт, ограничения времени и дополнительные признаки. АСУ проверяет полноту и технологическую допустимость до постановки в очередь.

Изменение или отмена после начала выпуска обрабатываются отдельным сообщением с учётом уже произведённого количества. Простая перезапись заказа может потерять фактическую историю.

В рабочей документации по этому узлу фиксируют обязательные поля, валидацию, статусы, приоритеты, частичное выполнение, изменение, отмену и подтверждение приёма. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: некорректное задание отклоняется с понятной причиной, а принятое исполняется без повторного ввода.

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

Сообщение формируется после фиксации завершённого цикла и не меняется незаметно. Исправления выполняют корректирующей записью с автором и причиной.

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

Весовая связывает машину, водителя, заказ, массу до и после загрузки и документ отгрузки. Номер транспортного средства нормализуют, чтобы различия в пробелах и алфавите не создавали дубли.

Очередь подачи машин должна быть согласована с производительностью БСУ. Интеграция передаёт готовность, начало загрузки, завершение и отклонения без ручных звонков между оператором и диспетчером.

В рабочей документации по этому узлу фиксируют идентификатор транспорта, статусы очереди, данные взвешивания, связь с заказом, время загрузки и обработку замены машины. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: каждая отгрузка сопоставлена с конкретным транспортом, весом и набором замесов.

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

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

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

Роли разделяют создание заказа, изменение рецепта, ручную корректировку, подтверждение лаборатории и администрирование. Общая учётная запись оператора исключает персональную ответственность.

Журнал сохраняет старое и новое значение, пользователя, время, рабочее место и причину. Критичные изменения требуют дополнительного подтверждения либо электронного согласования.

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

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

Применяют подтверждение доставки, идемпотентность, контроль пропусков и отдельный журнал ошибок. Ручная выгрузка файла рассматривается как регламентированный резерв, а не основной механизм.

В рабочей документации по этому узлу фиксируют локальную очередь, объём буфера, подтверждение, повтор, защиту от дублей, контроль последовательности и резервный канал. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: после восстановления все сообщения доставляются один раз и сверяются без потери производственного факта.

Приёмка охватывает нормальный заказ, изменение, отмену, частичное выполнение, замену транспорта, ошибочный справочник, отказ связи и повторную доставку. Проверяют не только интерфейс, но и итоговые документы.

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

В рабочей документации по этому узлу фиксируют матрицу сценариев, тестовые данные, ожидаемый результат, логи, производительность, резервное копирование и порядок обновлений. Решение принимают не по отдельному паспортному параметру, а после проверки совместной работы с дозатором, исполнительными механизмами и алгоритмом АСУ. Критерий приёмки: все критичные сценарии проходят без дублей, потери данных и нарушения технологической автономности АСУ.

• Бетонные заводы и БСУ — https://mix-vostok.ru/betonnye-zavody
• Программное обеспечение для БСУ — https://mix-vostok.ru/programmnoye-obespecheniye
• Дозаторы — https://mix-vostok.ru/dozatory
• Тензодатчики — https://mix-vostok.ru/tenzodatchiki