공장 데이터 추출
실제 공장 현장은 여러 조각이 이어 붙여진 것과 같습니다. 서로 다른 벤더, 서로 다른 세대, 서로 다른 프로토콜의 컨트롤러가 나란히 놓여 있습니다 — 한 스키드에는 Siemens S7, 그 옆에는 Allen-Bradley PLC, 변전소에는 Modbus 에너지 미터와 가변속 드라이브, 포장 라인에는 IO-Link 센서, 작업장에는 CNC 공작기계, 그리고 건물 HVAC를 운영하는 BACnet 컨트롤러가 있습니다. 그 중 거의 어느 것도 다른 것과 데이터를 공유하도록 설계되지 않았습니다.
공장 데이터 추출의 과제는 이 모든 장비에서 신뢰할 수 있고, 이름이 지정되고, 타임스탬프가 찍힌 측정값을 가져와 한 곳에 모으는 것입니다 — 공장을 재배선하거나, 컨트롤러를 교체하거나, PLC 프로그램을 다시 작성하지 않고 말입니다. 실제로 이는 각 장비의 기본 프로토콜로 통신하고, 원시 레지스터와 태그를 단위가 있는 명명된 엔지니어링 값으로 변환하며, 측정값을 신뢰할 수 있는지 알 수 있도록 품질 신호를 첨부하고, 네트워크가 끊겨도 엣지에서 안정적으로 이를 수행하는 것을 의미합니다.
IronFlock은 경량의 엣지 배포형 수집기 앱 제품군 — 프로토콜 제품군마다 하나씩 — 으로 이를 해결합니다. 각 앱은 모든 Linux 게이트웨이에서 일반 Docker 컨테이너로 실행되며, 가능한 것을 자동으로 검색하고, 원시 주소를 명명된 값으로 정규화하며, 장애 중에는 버퍼링하고, 모든 것을 프로젝트의 시계열 데이터베이스로 스트리밍합니다. 모든 수집기는 브라우저에서 완전히 구성되며 데모 모드와 함께 제공되므로, 하드웨어를 연결하기 전에 전체 경험을 평가할 수 있습니다.
브라운필드의 현실
공장 전체를 포괄하는 단일 프로토콜은 없습니다. 실질적인 질문은 항상 “어떤 수집기가 내 장비를 읽는가?” 입니다. 아래 표는 현장에서 발견할 가능성이 높은 장비를 그것을 처리하는 수집기에 매핑합니다.
| 발견할 수 있는 장비 | 일반적인 프로토콜 | 사용할 수집기 |
|---|---|---|
| Siemens S7-1200/1500/300/400, Allen-Bradley Logix, 모든 OPC UA 서버, 그리고 Modbus 장비 | S7comm, EtherNet/IP, OPC UA, Modbus | Industrial Collector |
| IO-Link 마스터와 그 뒤의 스마트 센서 (ifm, Balluff, Pepperl+Fuchs) | HTTP / OPC UA / MQTT 상의 IO-Link | IO-Link Collector |
| 에너지 미터, VFD, 공기 압축기, 인버터, 모든 레지스터 기반 컨트롤러 | Modbus TCP / RTU | Modbus Collector |
| CNC 공작기계 및 작업 현장 장비 (HAAS, Mazak, DMG Mori, Fanuc, Okuma) | MTConnect | MTConnect Collector |
| HVAC, 칠러, 조명, 에너지 미터, 빌딩 관리 시스템 | BACnet/IP | BACnet Collector |
Modbus와 OPC UA는 오늘 작동합니다. IO-Link, MTConnect, BACnet도 마찬가지입니다. Industrial Collector의 Siemens S7(S7comm) 및 Allen-Bradley(EtherNet/IP) 드라이버는 Apache PLC4X 엔진으로 구동되며 여러 장비에서 검증 중입니다 — S7-1200/1500 컨트롤러는 내장 OPC UA 서버를 통해 이미 오늘 읽을 수 있습니다.
IronFlock 수집기가 공유하는 접근 방식
어떤 프로토콜을 수집하든 다섯 개의 앱 모두 내부적으로 동일한 방식으로 작동합니다. 이들은 동일한 프로젝트별 데이터베이스 테이블(gateways, assets, datapoints, measurements, assetstatus)에 쓰고, 측정값을 로컬에 버퍼링했다가 플랫폼으로의 업스트림 링크가 복구되면 순서대로 전달하며, 각 장비를 격리하여 도달할 수 없는 한 대의 머신이 다른 머신을 멈추게 하지 않고, 구성 파일이나 재시작 없이 브라우저에서 실시간으로 구성됩니다. 이는 IronFlock이 어떻게 배포되든 — 관리형 클라우드, 프라이빗 클라우드, 또는 완전히 오프라인인 온프레미스 어플라이언스 — 동일하게 유지됩니다. 아래 각 페이지는 독립적으로 읽힐 수 있도록 이러한 공유 특성을 반복합니다.
알려진 한계
일부 레거시 장비는 아직 직접적인 경로가 없습니다. 레거시 Allen-Bradley MicroLogix / SLC(DF1 상의 PCCC), 여분의 이더넷 포트가 없는 Profibus 전용 셀, 공장 DCS에서만 운영되는 패키지, 그리고 디지털 컨트롤러가 전혀 없는 장비(하드와이어 전용)는 게이트웨이, 프로토콜 브리지, 또는 센서 개조가 필요합니다. 장비가 지원되는지 확실하지 않다면 문의하세요 — 장비가 Modbus나 OPC UA로 통신한다면 거의 확실히 오늘 작동하며, 새로운 드라이버와 프로파일 팩은 요청에 따라 추가됩니다.
수집기
- Industrial Collector — 현장 전체를 위한 하나의 앱: Siemens S7, Allen-Bradley, Modbus, OPC UA를 나란히, 사전 매핑된 장비 프로파일 카탈로그와 함께.
- IO-Link Collector — HTTP, OPC UA 또는 MQTT 상에서 자동 검색 및 자동 IODD 디코딩을 갖춘 IO-Link 마스터와 스마트 센서.
- Modbus Collector — 방대하게 설치된 Modbus 미터, 드라이브, 컨트롤러를 읽는 가장 가벼운 방법.
- MTConnect Collector — 개방형 MTConnect 표준 상에서 무설정 검색을 갖춘 CNC 공작기계와 작업 현장 장비.
- BACnet Collector — 자동 네트워크 및 포인트 검색을 갖춘 BACnet/IP 상의 빌딩 자동화, HVAC, 에너지 시스템.
데이터의 행선지
모든 수집기는 측정값을 프로젝트의 프라이빗 시계열 데이터베이스에 저장하며, 그곳에서 즉시 플랫폼의 나머지 부분에서 사용할 수 있습니다: Data Backend를 통해 쿼리하고 모델링하며, IoT 대시보드 및 SCADA 보드에서 실시간으로 시각화하고, SMS/이메일 알림을 위해 알람 앱으로 관찰하세요. 장비를 온라인으로 가져오고 이러한 앱을 설치하려면 디바이스 관리 및 앱 관리를 참조하세요.
수집에서 인사이트로: 전형적인 구현 패턴
추출은 기반이지 목표가 아닙니다. 아무도 레지스터와 태그 자체를 원하지 않습니다 — 공장이 원하는 것은 OEE 수치, 스핀들이 고장 나기 전의 조기 경고, 제품당 에너지, 저절로 작성되는 교대 근무 리포트입니다. 따라서 전형적인 IronFlock 배포는 깔끔하게 분리된 두 계층으로 구성됩니다:
계층 1 — 수집. 장비에 맞는 수집기 앱을 장비 옆의 게이트웨이에 설치하고, 브라우저에서 기계를 매핑하세요. 이 시점부터 이름이 지정되고, 타임스탬프가 찍히고, 품질 플래그가 붙은 측정값이 프로젝트의 표준화된 데이터베이스에 지속적으로 쌓입니다 — 모든 프로젝트가 동일한 데이터베이스를 가지므로 수집기는 어디에 설치되든 동일하게 동작하고, 프로젝트 소유자는 수집되는 모든 것을 점검할 수 있는 하나의 중심점을 얻습니다. 그 안에서 각 앱의 데이터는 자체의 격리된 스키마에 저장됩니다: 당신에게 속한, 계속 성장하는 단일 자산이며, 기본적으로 앱별로 프라이빗합니다.
계층 2 — 소비. 그 측정값을 의사 결정으로 바꾸는 앱을 설치(또는 구축)하고, 크로스 앱 데이터 액세스를 통해 수집기의 데이터를 읽게 하세요:
- 기성 OEE 대시보드 앱은 기계 상태와 생산 카운터를 소비하여 라인별 가동률, 성능, 품질을 제공합니다 — 단 한 번의 통합 회의 없이, 벽면 화면에 라이브로.
- 예지보전 앱은 수집기가 이미 모아 둔 수개월치 진동, 전류, 온도 이력으로 학습한 다음, 라이브 스트림을 스코어링하여 드리프트가 시작된 베어링을 짚어냅니다.
- 에너지 분석은 Modbus 미터의 소비량과 기계의 생산 카운터를 결합하여 제품당 에너지, 유휴 부하 낭비, 피크 부하 리스크를 리포트합니다.
- 리포팅 및 품질 앱은 같은 테이블을 읽어 교대 근무 일지, 배치 기록, 감사 추적을 자동으로 채웁니다.
- Node-RED 런타임(또는 임의의 범용 워크벤치)은 단일 와일드카드로 모든 프로젝트 데이터를 소비한다고 선언한 다음, 사용 가능한 테이블을 런타임에 검색합니다 — 그래서 엔지니어는 각각에 대한 통합을 작성하지 않고도 현장의 모든 수집기와 분석 앱에 걸쳐 플로우를 연결할 수 있습니다.
각 소비 앱은 어떤 수집기 데이터가 필요한지 — 특정 목록, 또는 전부를 뜻하는 - app: "*" — 를 선언하며, 그 액세스는 프로젝트별 스위치로 승인하거나 철회할 수 있습니다 — 언제나 읽기 전용입니다. 모든 IronFlock 수집기가 동일한 테이블 스키마(gateways, assets, datapoints, measurements, assetstatus)에 쓰기 때문에, 하나의 수집기를 대상으로 작성된 소비 앱은 모든 수집기와 함께 작동합니다: OEE 대시보드는 기계 상태가 S7, Modbus, MTConnect, IO-Link 중 무엇을 통해 도착했는지 신경 쓰지 않습니다.
그 결과는 당신을 가두는 대신 함께 성장하는 아키텍처입니다: 한 라인의 수집기 하나로 시작하고, 준비되면 분석 앱을 추가하고, 어떤 계층이든 독립적으로 교체하거나 확장하세요 — 그리고 기성 앱이 맞지 않으면, 이미 수집하고 있는 데이터 위에 직접 소비 앱을 구축하세요.