Почему нельзя задать в ТЗ единый порог точности вместо раздельных FAR и FRR?

Единый порог маскирует главную опасность — пропуск редкого брака. Система, которая верно классифицирует массовый поток годных деталей, но пропускает весь редкий дефект, покажет высокую «точность» и будет бесполезна. FAR (ложная отбраковка) и FRR (пропуск дефекта) задаются раздельно и оба как максимум — только так приёмка отличит рабочую систему от нерабочей.

Что обязательно включить в раздел ТЗ про данные?

Кто собирает изображения (доступ к линии при рабочем освещении), кто размечает (для похожих дефектов нужен контролёр ОТК, а не разметчик общего профиля), сколько примеров минимально на класс, что делать с редкими дефектами, которых пока нет физически, и — критично — кому принадлежат изображения и обученная модель. Без пункта о собственности вы рискуете вендор-локом на весь срок жизни линии.

Зачем в ТЗ отдельно прописывать поведение системы при отказе оборудования?

Иначе недоступная камера или вычислитель могут тихо пропускать весь поток как годный — это худший сценарий, брак уходит клиенту. ТЗ должно требовать при отказе останавливать линию или подавать сигнал оператору, а не продолжать работу «вслепую».

Что такое приёмочная выборка и почему без неё пороги FAR/FRR бесполезны?

Приёмочная выборка — это конкретный набор деталей и его объём, на котором измеряются пороги. Утверждение «0,5% пропусков» на 40 деталях и на 4000 — разные вещи. Без указанной выборки и условий испытаний (то же освещение, та же скорость линии) пороги написаны, но проверить их нечем, и приёмка превращается в спор.

Как составить ТЗ на систему технического зрения для ОТК: разделы, критерии приёмки, чеклист

Структура технического задания на vision-контроль качества: как задать критерии приёмки (FAR/FRR, скорость, разрешение дефекта), описать датасет, железо и интеграцию с MES/PLC так, чтобы пилот прошёл приёмку, а не завис на «доработках».

Как составить ТЗ на систему технического зрения для ОТК

Большая часть провалов пилотов машинного зрения закладывается не в модели и не в камере, а в техническом задании. Формулировка «система должна распознавать брак» невыполнима по определению: нет порога, по которому приёмка отличит рабочую систему от нерабочей, нет описания, какой именно брак и на какой скорости, нет ответственности за данные. Такой пилот не проваливается явно — он бесконечно «дорабатывается», потому что каждая сторона понимала задачу по-своему. Ниже — структура ТЗ, которая закрывает эти дыры: что писать в каждом разделе, как задать измеримые критерии приёмки и где чаще всего теряют проект. Материал — практика внедрения, а не теория; он дополняет наш разбор компьютерного зрения в ОТК и расчёта ROI пилота.

Почему «распознавать брак» — не ТЗ

Техническое зрение принимает бинарное решение о каждой детали: годна или нет. Чтобы это решение можно было принять на приёмке, ТЗ обязано ответить на четыре вопроса до старта работ, а не по их итогу: какой дефект ищем (тип, минимальный размер, где на детали), с какой достоверностью (сколько брака пропустить допустимо и сколько годных забраковать допустимо), на какой скорости (деталей в минуту, при какой скорости конвейера) и что система делает с решением (отбраковка, сигнал оператору, запись в MES). Отсутствие любого из этих четырёх — гарантированный спор на приёмке. «Распознавать брак» не содержит ни одного из них.

Раздел 1. Объект контроля и таксономия дефектов

Начинается ТЗ с описания детали и исчерпывающего списка дефектов, а не с требований к технике. По каждому типу дефекта фиксируется: название, минимальный значимый размер (в миллиметрах или долях), место возможного появления, визуальный признак (скол, трещина, царапина, непровар, посторонний включение, смещение) и критичность — пропуск какого дефекта ведёт к претензии клиента, а какой допустим в пределах ТУ. Именно минимальный размер дефекта, а не «разрешение камеры в мегапикселях», определяет всю оптическую часть: дефект должен занимать несколько пикселей в кадре, иначе он неотличим от шума — подробнее в гайде как выбрать промышленную камеру. Если типов дефекта больше пяти-семи и часть из них встречается редко, это сразу влияет на раздел о данных: редкий дефект нечем обучать, и в ТЗ должен появиться пункт про синтетику (см. синтетические данные для контроля качества).

Раздел 2. Критерии приёмки — сердце ТЗ

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

Пропуск дефекта (FRR, escape rate) — доля брака, ошибочно признанного годным. Задаётся как максимум, например «не более 0,5% пропущенных дефектов класса A на приёмочной выборке». Это важнейшая цифра: именно пропущенный дефект доезжает до клиента.
Ложная отбраковка (FAR) — доля годных деталей, ошибочно отправленных в брак. Тоже максимум: слишком строгая система выбрасывает годное и убивает свою же окупаемость.
Разрешение дефекта — минимальный размер дефекта, гарантированно детектируемого, в мм. Привязывается к разделу 1.
Производительность — деталей в минуту при заданной скорости линии, без накопления очереди.
Приёмочная выборка — на каких деталях и какого объёма измеряются FAR/FRR. Без этого пункта пороги невозможно проверить: «0,5%» на 40 деталях и на 4000 — разные утверждения.

Ключевой принцип: FAR и FRR задаются раздельно и оба как максимум. Требовать «точность 99%» бессмысленно — система, которая пропускает весь редкий брак, но верно классифицирует массовый годный поток, покажет 99% «точности» и при этом бесполезна. Раздельные FAR/FRR закрывают эту лазейку.

Раздел 3. Данные и разметка — кто, сколько, чьё

Модель не появляется из воздуха: её обучают на размеченных изображениях с вашей линии. ТЗ фиксирует, кто собирает данные (доступ к линии, время съёмки при рабочем освещении), кто размечает (разметить 5 похожих типов скола способен только контролёр ОТК, не разметчик общего профиля), сколько примеров минимально на класс и что делать с редкими дефектами, которых пока нет физически. Отдельно — принадлежность данных и обученной модели: остаются ли изображения вашего производства и веса модели у вас или у подрядчика. Это не формальность: без пункта о собственности вы рискуете оказаться в зависимости от одного поставщика на весь срок жизни линии.

Раздел 4. Требования к оборудованию

Железо в ТЗ описывается через задачу, а не марками. Камера и оптика — через минимальный размер дефекта и поле зрения; освещение — через требование стабильности и подавления бликов (нестабильный свет — причина плавающего FAR, см. освещение для машинного зрения); интерфейс передачи кадра — через скорость потока (см. CoaxPress, GigE или USB); вычислитель — через требование локального инференса без облака, если политика безопасности цеха этого требует (см. edge-платы для пилота). Правильная формулировка — «камера, обеспечивающая детекцию дефекта 0,3 мм в поле зрения 200 мм», а не «камера не хуже модели X»: первое проверяемо на приёмке, второе привязывает вас к поставщику.

Раздел 5. Интеграция и реакция на решение

Система, которая только «показывает дефект на экране», не меняет процесс — оператор всё так же устаёт и пропускает. ТЗ фиксирует, что происходит с вердиктом: физическая отбраковка (пневмотолкатель, стрелка), сигнал оператору, остановка линии, запись в MES/SCADA. Для записи в MES указывается протокол и формат: какие поля (ID детали, класс дефекта, время, изображение), по какому каналу (OPC UA, REST, сухой контакт на PLC). Здесь же — поведение при отказе: что делает линия, если камера или вычислитель недоступны (пропускать всё как годное — недопустимо, надо останавливать или сигналить). Глубже интеграция разобрана в гайде интеграция AI в MES/SCADA.

Раздел 6. Порядок приёмки и этапы

Приёмка расписывается заранее: на какой выборке и в каких условиях (то же освещение, та же скорость линии) измеряются пороги из раздела 2, кто присутствует, что считается пройденным испытанием. Полезно разбить на два этапа — пилот на одной линии с ограниченной номенклатурой и тираж. Пилот проверяет саму гипотезу и даёт реальные FAR/FRR на вашем браке; масштабирование — уже инженерная задача с известными цифрами. Такой порядок совпадает с логикой внедрения ИИ без остановки производства.

Типичные ошибки в ТЗ

Единый порог «точности» вместо раздельных FAR/FRR — маскирует пропуск редкого брака.
Оборудование марками, а не задачей — привязка к поставщику и неверифицируемость на приёмке.
Молчание про данные и их собственность — проект встаёт на разметке или запирает вас в вендор-локе.
Нет приёмочной выборки — пороги написаны, но проверить их нечем, приёмка превращается в спор.
Система только сигналит, но не влияет на процесс — брак по-прежнему уходит клиенту, ROI отрицательный.
Нет поведения при отказе — недоступная камера тихо пропускает весь поток как годный.

Чеклист готовности ТЗ

Перед отправкой ТЗ подрядчику проверьте, что в нём есть ответ на каждый пункт: перечень дефектов с минимальными размерами; раздельные максимумы FAR и FRR; приёмочная выборка (какие детали, сколько); производительность в деталях/мин при скорости линии; кто собирает и размечает данные; чья обученная модель; требование к освещению по стабильности; локальный или облачный инференс; протокол записи в MES; реакция на вердикт (отбраковка/сигнал/стоп); поведение при отказе оборудования; два этапа приёмки с условиями испытаний. Если хотя бы один пункт пуст — это будущий спор на приёмке, и дешевле закрыть его сейчас, на бумаге.

Что это значит для внедрения на вашей линии

ТЗ на техническое зрение — это не документ для галочки, а контракт на измеримый результат. Хорошее ТЗ переводит расплывчатое «распознавать брак» в набор порогов, каждый из которых проверяется на приёмке за один день: столько-то пропусков на такой-то выборке, столько-то деталей в минуту, дефект от такого-то размера, запись в MES по такому-то протоколу. Пилот с таким ТЗ либо проходит приёмку, либо честно показывает, что гипотеза не подтвердилась — и то и другое лучше бесконечных «доработок» проекта без критериев. Если нужна помощь с формулировкой критериев приёмки под конкретную деталь и дефекты — это ровно та задача, с которой мы начинаем работу.

Данные нашего каталога Zavod.dev

ТЗ описывает железо через задачу, но прикинуть порядок бюджета помогает реальный каталог. Ниже — данные нашего каталога камер машинного зрения Zavod.dev на момент публикации (тот же снимок, что в гайде по выбору камеры): 16 596 позиций, из них 12 160 (73%) в наличии, медианная цена 4 891 ₽ (25-й перцентиль 1 914 ₽, 75-й — 14 884 ₽). Это ориентир для строки «оборудование» в смете ТЗ ещё до запроса КП.

Каталог Zavod.dev · камер машинного зрения · снимок на 03.07.2026
Позиций в каталоге	16 596
В наличии	12 160 (73%)
Медианная цена	4 891 ₽
Диапазон массового сегмента (25–75%)	1 914 – 14 884 ₽
Топ-производители по числу позиций	OPT Machine Vision (2 990), Hikrobot (2 278), Allied Vision (1 298)

Открыть раздел в каталоге Zavod.dev →

Частые вопросы

Почему нельзя задать в ТЗ единый порог точности вместо раздельных FAR и FRR?: Единый порог маскирует главную опасность — пропуск редкого брака. Система, которая верно классифицирует массовый поток годных деталей, но пропускает весь редкий дефект, покажет высокую «точность» и будет бесполезна. FAR (ложная отбраковка) и FRR (пропуск дефекта) задаются раздельно и оба как максимум — только так приёмка отличит рабочую систему от нерабочей.
Как в ТЗ описать требования к камере, чтобы не привязаться к одному поставщику?: Через задачу, а не марку. Правильная формулировка — «камера, обеспечивающая детекцию дефекта 0,3 мм в поле зрения 200 мм», а не «камера не хуже модели X». Первое проверяется на приёмке измерением, второе привязывает вас к поставщику и не гарантирует результат.
Что обязательно включить в раздел ТЗ про данные?: Кто собирает изображения (доступ к линии при рабочем освещении), кто размечает (для похожих дефектов нужен контролёр ОТК, а не разметчик общего профиля), сколько примеров минимально на класс, что делать с редкими дефектами, которых пока нет физически, и — критично — кому принадлежат изображения и обученная модель. Без пункта о собственности вы рискуете вендор-локом на весь срок жизни линии.
Зачем в ТЗ отдельно прописывать поведение системы при отказе оборудования?: Иначе недоступная камера или вычислитель могут тихо пропускать весь поток как годный — это худший сценарий, брак уходит клиенту. ТЗ должно требовать при отказе останавливать линию или подавать сигнал оператору, а не продолжать работу «вслепую».
Что такое приёмочная выборка и почему без неё пороги FAR/FRR бесполезны?: Приёмочная выборка — это конкретный набор деталей и его объём, на котором измеряются пороги. Утверждение «0,5% пропусков» на 40 деталях и на 4000 — разные вещи. Без указанной выборки и условий испытаний (то же освещение, та же скорость линии) пороги написаны, но проверить их нечем, и приёмка превращается в спор.