Интеграция AOI, маркировки и прослеживаемости при программировании ИС

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

Определите, что необходимо инспектировать и маркировать

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

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

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

Выстройте непрерывную связь данных

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

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

Последовательность управления и обработка брака

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

Любой показатель производительности зависит от компонента, времени программирования, количества активных программирующих станций, корпуса, содержания маркировки, рецепта контроля, носителя и условий процесса. Узкими местами могут стать экспозиция AOI, оценка качества кода, ответ базы данных и цикл маркировки. KINCOTO поможет организовать валидацию на основе образцов, проверяющую как штатную последовательность, так и восстановление после исключений.