산업용 IoT (Internet of Things) 배포 시 그 어떤 것보다 더 많은 엔지니어링 시간을 잡아먹을 수 있는 문제에 대한 현장 노트 스타일의 분석입니다.

만약 생산 설비 근처에 RFID를 배포해 본 적이 있다면, 아마 이런 상황을 겪어보았을 것입니다: 단일 태그가 1초도 안 되는 사이에 두 번 읽히거나, 심지어 범위 밖에 있는데도 "읽히는" 경우입니다. 산업 현장에 처음 접하는 팀들은 종종 이를 하드웨어 결함이라고 가정합니다. 하지만 대다수의 경우 이는 결코 단순하지 않으며, 이러한 읽기 값이 참이고 사실이라는 가정하에 무언가를 구축하고 있다면 그 이유를 이해하는 것이 매우 중요합니다.

문제는 리더(Reader)가 아니라 환경입니다

이 문제의 주요 원인 중 하나는 환경, 특히 금속입니다. 스탬핑 프레스(Stamping presses), 조립 라인, 그리고 금속 랙(Metallic racks)은 무선 주파수 (RF) 신호를 반사시킵니다. 이러한 반사로 인해 전송 신호가 약간씩 다른 간격으로 안테나에 도달하게 되면서, 단일 태그가 여러 번 읽힐 수 있습니다. 결과적으로 리더는 하나의 태그를 읽는 것이 아니라 약 12번 정도 읽고 있다고 가정하게 됩니다. 여기에 공장 현장에서 매일 읽히는 수십 개의 태그를 더하면, 자신도 모르는 사이에 카운트 기반 로직 (Count-based logic)에서 심각한 문제를 일으키기 시작할 것입니다.

또 다른 덜 명확한 문제는 안테나 중첩 (Antenna overlapping)입니다. 시설에서 하나 이상의 리더를 사용할 때, 가장자리 부분에서 서로 중첩될 수 있습니다. 중첩 구역에 있는 태그는 두 개 이상의 리더에 의해 동시에 읽히게 되며, 사용자가 특정 태그, 안테나 또는 리더 ID를 이미 저장하거나 기록하고 있지 않다면 이는 정확히 두 번의 별개 읽기로 보이게 됩니다.

상상 이상으로 상황을 악화시키는 요인들

일반적인 반응은 이 문제가 사소한 데이터 오염(data-corruption) 정도의 성가신 문제일 뿐이라고 생각하는 것입니다. 하지만 이 문장은 해당 데이터가 WIP(재공품)나 인력/구역 점유 추적기(workforce/zone occupancy tracker)와 같이 카운트 기반 로직(count-based logic)을 사용하는 곳으로 흘러 들어가는 순간 더 이상 사실이 아닙니다. 추가적인 읽기(read)가 발생할 때마다 이를 추가적인 활동으로 간주하기 때문에, 두 시스템 모두 계산 오류가 발생하게 됩니다. 만약 추적성 시스템(Traceability systems)이 각 읽기를 별개의 계보 이벤트(genealogy event)로 사용한다면, 결국 수많은 유효한 읽기 아래에 원본이 아닌 항목들이 가득 찬, 극도로 지저분한 로그를 생성하게 될 것입니다.

이것이 초기 단계의 산업용 IoT 프로젝트 중 상당수가 감지되지 못한 채 넘어가는 지점입니다. 하드웨어는 완벽하고, 네트워크는 양호하며, 모든 연결도 활성화되어 있습니다. 하지만 중복 제거(deduplication) 레이어가 시스템에 구축되지 않았기 때문에, 읽기 데이터를 사용하는 애플리케이션이 해당 특정 문제에 대해 설계되지 않았던 것입니다.

이것이 실제로 해결하는 것

클라우드가 아닌 엣지(edge)에서 중복 제거 수행 – 중복 제거를 위한 가장 효과적인 해결책은 신호가 태그 안테나에 가장 가까울 때 읽기(read)를 제거하는 것입니다. 리더(reader)의 하드웨어에서 설정하거나(보통 특정 시간 동안 동일한 태그를 두 번 읽지 않도록 하는 "읽기 윈도우 설정(read window setting)"이 있습니다), 가벼운 엣지 프로세스(edge processes)를 사용하십시오. 이렇게 하면 추가적인 데이터 오버헤드(data overhead)를 획기적으로 줄일 수 있으며, 상위 시스템(upstream system)이 설계되지 않은 문제를 처리하려고 애쓸 필요를 없애줍니다.

단순한 tagid 대신 tagid+timestamp 버킷(bucket) 고려 – 만약 태그가 5분 또는 10분 후에 실제로 다시 나타난다면, 그것은 중복된 읽기가 아니라 정당한 재진입입니다. 2~3초 범위의 시간 버킷(time bucket)을 사용하면 유효한 읽기가 이 과정에서 걸러지는 것을 방지할 수 있습니다.

읽기 기록 시 리더(Reader)/안테나 ID 기록 - 중첩된 구역(overlapping zones)을 수정하는 가장 간단한 방법은 각 읽기(read)에 대해 리더 또는 안테나 ID를 기록하는 것입니다. 만약 동일한 태그에 대한 두 번의 읽기가 마이크로초(microseconds) 단위 내에 도착하고, 양쪽에 두 개의 안테나가 있어 둘 다 동일한 태그를 읽고 있다면, 이는 읽기 구역 오버플로(read zone overflow)임을 알 수 있습니다. 안테나와의 근접성, 읽기 신호의 강도, 또는 비즈니스 관련 요인 중 선호하는 방법을 사용하여 이 문제를 제거할 수 있습니다.

단순한 카운트 대신 상태 머신(State Machine) 확인 - WIP(재공품)/인력 관리 시스템에서 단순한 카운트를 사용하는 대신, 상태를 인식(state-aware)하도록 만드십시오. 허용되지 않는 변경을 트리거하는 모든 읽기(예: 직원이 이미 체크인한 구역에 다시 진입하는 경우)는 필터링이 필요한 오버플로된 읽기를 나타냅니다.

핵심 요약 (The take-away message)

이것은 특별하거나 생소한 것이 아니며, 대부분 스택(stack)의 적절한 계층에서 규율 있는 데이터 위생(data hygiene)을 유지하는 문제로 귀결됩니다. 문제는 이러한 사항들이 수정하기 너무 늦을 때까지는 전혀 명확하게 드러나지 않는다는 점이며, 이 경우 일반적으로 정확한 결과를 생성하지 못하는 치명적인 시스템을 의미하게 됩니다. 공장 현장에서 RFID를 사용하는 새로운 프로젝트를 막 시작하는 단계라면, 데이터 파이프라인(data pipeline)이 중심 역할을 하기 전에 반드시 이 문제를 고려해야 합니다.

산업용 트래킹 또는 인력 관리 애플리케이션을 위한 RFID, BLE 및 UWB 데이터 구조화에 대한 추가 정보가 필요하다면, Compentra AI의 일반 개요를 확인하십시오.