На більшості виробництв маркувальник  це останній острівець ручного введення в інакше автоматизованому потоці. ERP знає номер партії. MES знає, що зараз іде на лінії. А дату виробництва на пляшку оператор набирає з клавіатури, дивлячись у паперовий наряд.

Це не проблема обладнання. Це розрив в архітектурі даних: маркувальник фізично здатний отримувати дані по мережі, але його ніхто до неї не підключив. Матеріал для тих, хто відповідає за інтеграцію: IT/OT-спеціалістів, автоматизаторів і технічних директорів. Розбираємо три рівні зрілості, потік даних, протоколи, вибір джерела істини для партії та зворотний зв'язок від системи верифікації.
 

Три рівні зрілості

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

Рівень 1. Ручне введення оператором

Оператор набирає дату, партію, зміну на клавіатурі маркувальника або в його інтерфейсі.

  • Джерело істини: паперовий наряд або пам'ять оператора.

  • Контроль: відсутній. Ніхто не порівнює введене з тим, що має бути.

  • Слід в системі: немає. Що фактично надруковано невідомо, крім самого відбитка на продукції.

  • Типовий стан: 70–80% середніх виробництв в Україні.

Рівень 2. Централізовані шаблони на контролері

Макети відбитків зберігаються централізовано, оператор обирає готовий шаблон, ручне редагування полів заблоковано. Дата підставляється з системного годинника, партія  з обраного шаблону або сканованого наряду.

  • Джерело істини: централізована бібліотека шаблонів під контролем технолога.

  • Контроль: оператор не може ввести довільне значення в критичне поле.

  • Слід у системі: частковий — відомо, який шаблон обрано і коли.

  • Ключова властивість: знімає більшу частину ризику без інтеграційного проєкту.

Рівень 3. Автоматична передача з ERP/MES

Маркувальник отримує дані по мережі з системи, яка володіє даними про замовлення й партію, і повертає підтвердження нанесення.

  • Джерело істини: ERP (замовлення, партія, специфікація) + MES (фактичне виконання).

  • Контроль: оператор не вводить нічого; він запускає лінію.

  • Слід у системі: повний по кожній одиниці або партії відомо, що надруковано, коли й чи прочитано.

  • Обов'язковий рівень для: серіалізації, е-акцизу, фармацевтичного контуру, експорту у велику мережу.

Важливо: перехід із рівня 1 на рівень 2 дає непропорційно великий результат за малі гроші. Перехід на рівень 3  це вже проєкт із бюджетом і термінами. Не змішуйте ці два рішення.
 

Загальна схема потоку даних

Читати зверху вниз: дані про партію спускаються з рівня бізнес-систем до друкуючої головки, а підтвердження нанесення і читабельності піднімається назад до самого верху. Ліворуч  заблокована гілка ручного введення, джерело близько 90% помилок у даті.

Чому ручне введення даних  джерело найдорожчих помилок

Ручне введення  найпоширеніша і найдорожча уразливість у всьому маркувальному контурі. Причина в асиметрії: одна помилка в одному символі дає наслідок, непропорційний самій дії.

Реальні механіки відмови:

1. Не перемкнули дату після нуля годин. Зміна працює з 20:00 до 08:00, о полуночі дата має змінитися. Якщо вона підставляється вручну половина партії йде з датою попереднього дня. Формально це продукція з невірним терміном придатності.

2. Не змінили номер партії при переході на нову. Дві різні партії отримують один номер. Прослідковуваність зруйнована: при відкликанні доведеться вилучати обидві.

3. Помилка в терміні придатності. Оператор набрав «+30 днів» замість «+90». Продукція з некоректним терміном у роздрібній мережі це вже не внутрішня проблема.

4. Правильні дані, неправильний макет. Обрано шаблон іншого SKU: дані коректні, але позиція й склад полів не відповідають продукту.

Що робить цю категорію помилок особливо неприємною: жодне «якісне обладнання» від неї не захищає. Маркувальник виконав команду точно. Апарат не знає, що сьогодні друге число, а не перше він друкує те, що йому сказали.

Ціна помилки  не вартість переклеювання етикеток. Це відкликання партії, штраф, претензія мережі й розслідування, у якому доведеться доводити, що це одиничний випадок, а не системна проблема контролю. І довести це без слідів у системі неможливо  саме тому, що дані вводилися вручну.
 

Як технічно виглядає обмін

Рівні за ISA-95

Корисно розкласти контур за класичною моделлю, щоб зрозуміти, хто з ким говорить:


 

Транспорт і протоколи

Що реально використовується на практиці:

  • RS-232 / RS-485 легасі-підключення, досі поширене. Просте, надійне, але без справжнього зворотного зв'язку й погано масштабується.

  • Ethernet, TCP/IP raw socket базовий варіант для більшості каплеструменевих і термоструменевих маркувальників: ASCII-команди у власному протоколі виробника через відкритий сокет.

  • Мови опису друку ZPL/EPL, DPL та аналоги для термотрансферних принтерів і принтерів-аплікаторів. Тут макет описується текстовою командою, а не файлом-картинкою: змінні дані підставляються полями.

  • OPC UA  стандарт де-факто для промислової інтеграції OT/IT. Найкращий вибір, коли маркувальник входить у загальний контур автоматизації лінії.

  • MQTT легка телеметрія: статуси, лічильники, події. Добре для моніторингу, не для передачі критичних завдань.

  • REST/SOAP API рівень обміну з ERP/MES, а не з обладнанням.

  • PackML (ISA-TR88.00.02)  модель станів обладнання. Дає уніфіковані стани й спрощує діагностику лінії.

  • Weihenstephan Standards  якщо ви в напоях, це релевантний стандарт машинних даних.

  • EPCIS 2.0 (GS1)  рівень подій серіалізації: commissioning, aggregation, decommissioning. Обов'язково там, де є унікальний код на одиницю.

Вибір джерела істини для партії

Найважливіше проєктне рішення. Правило одне: джерело істини має бути єдиним і однонаправленим.

Практичний розподіл:

  • ERP володіє номером партії, SKU, специфікацією і терміном придатності як атрибутом продукту.

  • MES володіє фактом: яка партія фізично виконується на цій лінії в цю хвилину, скільки вже випущено.

  • Маркувальник не володіє нічим. Він виконавець. Будь-яка можливість змінити дані на його рівні  це дірка в архітектурі.

  • Дата виробництва береться з єдиного джерела часу (NTP-синхронізований сервер), а не з годинника окремого апарата. Годинники розходяться, і на межі зміни дати це дає розбіжність між системою і відбитком.

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


Зворотний зв'язок: як система дізнається, що відбиток надрукований і прочитаний

Односторонній обмін  це половина інтеграції. Без зворотного каналу ви знаєте, що відправили завдання, але не знаєте, що вийшло.

Повний цикл виглядає так:

  1. Система передає завдання на маркувальник.

  2. Маркувальник підтверджує прийом завдання.

  3. Головка наносить відбиток, апарат повідомляє факт нанесення й лічильник.

  4. Камера верифікації зчитує відбиток і оцінює клас якості.

  5. Результат зчитування повертається нагору до MES і, за потреби, до ERP.

  6. Нечитабельна одиниця позначається в системі, її ідентифікатор виводиться з обігу, спрацьовує відбраковування.

Що це дає, крім compliance:

  • Маркування стає частиною контролю якості, а не окремою операцією. Дані про клас читабельності це метрика процесу: за її погіршенням видно засмічення головки задовго до появи браку.

  • З'являється доказова база. На будь-яку претензію є відповідь із системи: ось партія, ось відбитки, ось результати верифікації.

  • Закривається серіалізація. Без підтвердження нанесення й читабельності неможливо коректно керувати пулом унікальних ідентифікаторів.

Практичний нюанс: зворотний зв'язок має обробляти три різні події  «надруковано й прочитано», «надруковано, не прочитано», «не надруковано». Третій випадок часто забувають, і при обриві зв'язку система вважає одиниці випущеними, хоча лінія стояла.


З чого почати, якщо ERP у вас є, а інтеграції немає

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

Мінімальний перший крок, у порядку виконання:

  1. Інвентаризація можливостей обладнання. Які інтерфейси фізично є на кожному маркувальнику, чи документований протокол, чи є API. Це один день роботи інженера і воно визначає все подальше.

  2. Централізація шаблонів. Усі макети — в одному місці, під контролем технолога, з версіонуванням. Не в пам'яті кожного апарата окремо.

  3. Блокування ручного редагування критичних полів. Оператор обирає шаблон — не редагує дату, партію й термін. Рольовий доступ: зміна макета вимагає прав технолога.

  4. Автоматична дата з єдиного джерела часу плюс формалізоване правило переходу зміни.

  5. Сканування наряду для вибору шаблону. Оператор сканує штрихкод виробничого завдання — система сама підставляє потрібний макет. Дешево, і прибирає помилку «правильні дані, не той SKU».

  6. Логування. Хто, коли, який шаблон запустив. Мінімальний слід, який уже є доказовою базою.

Ці шість кроків знімають приблизно 80% ризику й не потребують ні зміни ERP, ні промислового middleware. Далі — вже свідоме рішення про повну інтеграцію, з розрахунком під конкретну задачу: серіалізація, е-акциз, вимоги мережі або просто зменшення втрат.


Висновок

Маркувальник — не «принтер у кінці лінії», а вузол у контурі даних. Питання «звідки він бере дані» насправді звучить як «хто є джерелом істини для партії і чи є слід у системі».

Три речі, які варто зафіксувати:

  1. Ручне введення архітектурна уразливість, а не людський фактор. Її не лікують навчанням оператора, її лікують блокуванням поля.

  2. Проміжний рівень існує. Централізовані шаблони й заборона ручного редагування це 80% результату за малі гроші. Не обов'язково робити «все і одразу».

  3. Інтеграція без зворотного зв'язку неповна. Без даних від камери верифікації ви керуєте процесом наосліп.

Обговоріть інтеграцію маркування з вашою ERP/MES. Інженер PROMARK проводить технічну консультацію: інвентаризує інтерфейси наявного обладнання, визначає ваш рівень зрілості, пропонує архітектуру обміну під ваш стек і показує, який мінімальний крок дасть найбільший ефект у вашому випадку. Розмова технічна з вашим IT/OT, а не з відділом закупівель.