Wiznet makers

요약

인도네시아 폴리테크닉(POLIBATAM)의 PBL 과제로 만들어진 이 프로토타입은 얼굴 인식으로 작업자를 인증하고, 인증된 경우에만 Mitsubishi FX5U PLC로 조립 스테이션을 시작·정지·비상정지할 수 있게 만든 SCADA 시스템입니다. 핵심 연결고리는 ESP32-S3 + WIZnet W5500이 맡는 Modbus TCP 서버 역할로, 안면인식이라는 IT 영역과 PLC 제어라는 OT 영역을 하드웨어 TCP/IP 오프로딩 위에서 안정적으로 잇습니다.

개요

조립 라인은 승인되지 않은 인원이 기계를 조작할 경우 안전사고로 직결되는 환경입니다. 이 프로젝트는 카메라로 얼굴을 인식해 등록된 작업자만 시작 버튼이 동작하도록 하고, 나머지 제어(정지·비상정지·리셋)는 웹 HMI를 통해 원격으로 처리합니다. 대상은 POLIBATAM 실습실의 Assembly Station이며, PC(얼굴인식 서버)·ESP32(통신 게이트웨이)·FX5U PLC(실제 액추에이터 제어)라는 세 개의 이질적인 시스템을 하나의 흐름으로 엮는 것이 과제의 핵심입니다.

도입 배경 / 왜 필요한가

이 저장소 자체가 실제 공장에 도입된 사례는 확인 불가합니다. Star·Fork가 0건이고 외부 보도나 채택 기사가 없어, 학생 PBL 실습 결과물로 판단됩니다.

다만 산업적 필요성 근거는 확인됨입니다. Industry 4.0 환경에서 생체인식 기반 설비 접근통제는 PIN·패스워드 방식보다 누가 기계를 조작했는지 감사 추적이 명확하다는 이유로 이미 자동차·전자 제조 현장에 채택되고 있습니다. 동시에 인도네시아 **개인정보보호법(UU PDP, Law No. 27/2022)**은 얼굴 데이터를 포함한 생체정보를 "특정 개인정보"로 분류해 암호화 등 더 엄격한 보호조치를 요구합니다. 즉 "생체인식 접근통제가 왜 필요한가"는 산업 트렌드와 규제 양쪽에서 확인되지만, "이 프로젝트가 실제 그 요구에 맞춰 도입되었는가"는 별개 질문이며 현재로선 확인할 수 없습니다.

→ Industry 4.0 생체인식 보안 사례: https://blog.mantratec.com/applications-of-biometrics-in-manufacturing-security 

→ 인도네시아 PDP Law 생체정보 규정: https://www.aseanbriefing.com/doing-business-guide/indonesia/company-establishment/personal-data-protection-law

아키텍처

Wi-Fi/웹서버(Core 0)**와 **W5500 이더넷/Modbus(Core 1)를 물리적으로 다른 코어에 배치한 것이 구조의 핵심입니다. 얼굴인식 결과를 받는 HTTP 처리와, PLC와의 실시간 Modbus 통신이 서로의 타이밍에 영향을 주지 않도록 분리했습니다.

기술 배경

Modbus TCP는 산업 자동화에서 가장 널리 쓰이는 통신 프로토콜로, 클라이언트가 서버의 코일(coil)·레지스터(register) 주소를 읽고 쓰는 단순한 요청-응답 구조입니다. 이 프로젝트에서는 ESP32가 서버, FX5U PLC가 클라이언트로 동작하며, 시작·정지·비상정지 명령이 모두 코일 하나의 ON/OFF로 전달됩니다.

W5500 하드웨어 TCP/IP 오프로딩은 MCU가 TCP/IP 스택을 소프트웨어로 처리하지 않고 전용 칩에 위임하는 구조입니다. 8개의 독립 소켓을 지원해 여러 연결을 동시에 관리할 수 있고, 이 프로젝트는 실제로 W5100.readSnSR() 레지스터를 주기적으로 읽어 소켓 상태를 진단하는 방식으로 이 구조를 활용합니다.

Haar Cascade + LBPH는 각각 "얼굴이 어디 있는지 찾는" 검출 알고리즘과 "누구의 얼굴인지 구분하는" 인식 알고리즘입니다. 딥러닝 이전 세대의 경량 알고리즘으로, 이 프로젝트가 PC 한 대만으로 실시간 인증을 처리할 수 있는 이유이기도 합니다.

기술 특징

• 듀얼코어 태스크 분리: Wi-Fi(우선순위 1)와 Modbus/Ethernet(우선순위 2)을 각각 다른 코어에 고정해 SPI 통신 지연을 최소화
• SPI 클럭 다운튜닝: 240MHz 강제 클럭 설정이 "W5500 Instability 유발"이라는 주석과 함께 비활성화되어 있고, SPI 클럭을 8MHz로 낮춰 다중 기기 네트워크에서의 안정성을 확보
• 원자적 플래그 기반 스레드 안전성: std::atomic으로 코어 간 명령 전달을 처리해 레이스 컨디션을 방지

WIZnet 적용 구조

실제 사용된 모델은 W5500입니다. ESP32-S3의 SPI(CS=10, MOSI=11, SCLK=12, MISO=13)에 연결되어 Modbus TCP 서버(port 503) 소켓을 처리하고, emelianov/modbus-esp8266 라이브러리의 ModbusEthernet 클래스가 W5500 위에서 코일·레지스터 테이블을 관리합니다.

주목할 점은 코드가 W5500의 레지스터 레벨 진단까지 활용한다는 것입니다. 3초마다 8개 소켓의 Sn_SR(소켓 상태 레지스터) 값을 읽어 로그로 남기는데, 이는 산업 현장에서 흔한 "연결이 끊겼는지 알 수 없는" 문제를 W5500의 하드웨어 상태 정보로 직접 해결하는 방식입니다.

WIZnet Makers 유사 사례

Guide to Modbus TCP ESP32 Communication... Siemens S7-1200 PLC: 본 프로젝트와 동일한 ESP32+W5500+Modbus TCP 조합으로 실제 상용 PLC와 연동하지만, 역할이 정반대입니다. 이 사례는 ESP32가 클라이언트이고 Siemens PLC가 서버인 반면, 본 프로젝트는 ESP32가 서버이고 FX5U가 클라이언트입니다. 

→ 프로젝트 링크: https://maker.wiznet.io/bruno/projects/guide-to-modbus-tcp-esp32-communication-between-w5500-module-and-siemens-s7-1200-plc-factoryautomat/

esp32-modbus-w5500: ESP32+W5500으로 Modbus TCP 코일을 읽고 쓰는 기본 골격이 동일합니다. 이 사례는 MBAP 헤더를 직접 다루는 학습용 예제인 반면, 본 프로젝트는 라이브러리 기반에 안면인식·듀얼코어까지 결합한 완성형 시스템입니다. 

→ 프로젝트 링크: https://maker.wiznet.io/lawrence/projects/esp32-modbus-w5500/

plc-stm32: W5500을 "산업용 PLC의 유선 이더넷 인터페이스"로 쓰는 목적은 같지만, MCU가 STM32이고 펌웨어 없이 하드웨어 설계만 존재하는 단계입니다. 본 프로젝트는 ESP32 기반으로 펌웨어까지 완성·실측 검증된 상태입니다. 

→ 프로젝트 링크: https://maker.wiznet.io/irina/projects/plc-stm32/

세 사례 모두 **"W5500으로 Wi-Fi 대신 유선 이더넷을 확보해야 PLC 연동이 안정적"**이라는 결론을 공유하며, 이는 WIZnet 채택 이유가 프로젝트 규모나 MCU 종류와 무관하게 일관됨을 보여줍니다.

표에서 드러나듯, 본 프로젝트는 유사 사례들의 "W5500 Modbus 게이트웨이" 골격에 안면인식 인증 계층을 얹은 것이 가장 뚜렷한 차별점입니다.

비즈니스 가치

• 저비용 이종 PLC 연동: 값싼 ESP32+W5500만으로 브랜드가 다른 PLC(FX5U)와 산업표준 프로토콜로 연동 가능함을 실증
• 감사 추적 가능한 접근통제: 누가 기계를 조작했는지 기록되지 않는 공유형 PIN 방식의 한계를 얼굴인식으로 보완
• 원격 모니터링 확장 여지: 웹 HMI 구조를 그대로 확장해 다수 스테이션을 중앙에서 모니터링하는 시나리오로 발전 가능
• 교육용 레퍼런스 아키텍처: IT(얼굴인식)와 OT(PLC 제어)를 하나의 게이트웨이로 통합하는 방법을 보여주는 실습 사례

한계 및 개선 방향

현재 한계

• Modbus TCP는 인증·암호화가 없는 프로토콜이라, 네트워크에 접근하면 누구나 코일을 직접 제어할 수 있습니다.
• Haar Cascade+LBPH는 조명·각도 변화에 취약해 딥러닝 기반 인식보다 오탐률이 높을 수 있습니다.
• Wi-Fi(10.251.64.200)와 Ethernet(192.168.1.50) IP가 코드에 하드코딩되어 있어 배포 환경마다 재컴파일이 필요합니다.
• 얼굴 데이터셋과 trainer.yml이 PC에 암호화 없이 저장되어, 특정개인정보 보호 요건과는 거리가 있습니다.
• Modbus 서버와 웹서버가 모두 단일 ESP32에 있어, 해당 장치가 다운되면 PLC 제어 전체가 중단됩니다.

개선 방향 학생 PBL 과제로서 "동작하는 것"을 우선한 선택들은 충분히 합리적입니다. 다음 단계로는 Modbus TCP 구간에 VPN이나 방화벽 규칙을 더하고, 얼굴 데이터셋을 암호화 저장하며, 두 번째 ESP32나 워치독으로 이중화하는 방향을 고려할 수 있습니다.

FAQ

Q1. 이 시스템을 다른 PLC 브랜드(예: Siemens)에도 적용할 수 있나요? 네. ESP32는 Modbus TCP 서버로만 동작하므로, PLC 쪽에서 Modbus TCP 클라이언트 설정만 맞추면 브랜드와 무관하게 연동 가능합니다.

Q2. Wi-Fi와 유선 이더넷을 왜 동시에 쓰나요? PC↔ESP32 간 명령 전달은 Wi-Fi(HTTP)로, ESP32↔PLC 간 실시간 제어는 W5500 유선 이더넷으로 분리해 산업 통신의 결정성을 확보하기 위함입니다.

Q3. 생체정보 보호는 어떻게 강화할 수 있나요? trainer.yml과 얼굴 이미지 데이터셋을 디스크 암호화하고, 접근 로그를 남기는 것이 최소한의 개선책입니다.

Q4. MCU를 ESP32-S3로 선택한 이유는 확인되나요? README와 코드에서 직접적인 선택 이유는 명시되어 있지 않아 확인 불가입니다. PSRAM·16MB Flash 옵션이 얼굴인식 데이터 처리에 유리했을 것으로 **[추정]**됩니다.

Q5. 도입 난이도는 어느 정도인가요? ESP32 Arduino 개발 경험과 PLC Modbus TCP 설정(래더 로직 아님, 통신 설정) 경험이 있다면 하드웨어 배선과 IP 설정만으로 재현 가능한 수준입니다.

Summary

Built as a Project-Based Learning (PBL) assignment at a polytechnic in Indonesia (POLIBATAM), this prototype authenticates operators by face recognition and only allows them to start, stop, or emergency-stop an assembly station through a Mitsubishi FX5U PLC once authorized. The connecting piece is the ESP32-S3 + WIZnet W5500, which runs as a Modbus TCP server, bridging the IT world of face recognition and the OT world of PLC control on top of hardware TCP/IP offloading.

Overview

On an assembly line, an unauthorized person operating machinery can turn into a safety incident. This project uses a camera to recognize faces so that only a registered operator can trigger the start button, while the rest of the controls (stop, emergency, reset) are handled remotely through a web HMI. The target environment is POLIBATAM's Assembly Station lab, and the core engineering challenge is stitching together three very different systems — a PC running face recognition, an ESP32 acting as a communication gateway, and an FX5U PLC actually driving the actuators — into one coherent flow.

Why This Matters

There's no evidence this repository has been adopted in a real production line. With zero stars and forks and no external coverage, it reads as a student PBL exercise rather than a deployed system — this is unconfirmed.

The broader industrial need, however, is confirmed. In Industry 4.0 settings, biometric access control for machinery is already used on automotive and electronics manufacturing floors, largely because it leaves a clear audit trail of who operated a machine — something shared PINs or passwords can't guarantee. At the same time, Indonesia's Personal Data Protection Law (UU PDP, Law No. 27/2022) classifies facial data as "specific personal data" subject to stricter safeguards, including encryption. So while the need for biometric access control is well established by both industry trends and regulation, whether this particular project was built to meet that need can't be confirmed from what's available.

→ Biometrics in manufacturing security: https://blog.mantratec.com/applications-of-biometrics-in-manufacturing-security 

→ Indonesia's PDP Law on biometric data: https://www.aseanbriefing.com/doing-business-guide/indonesia/company-establishment/personal-data-protection-law

Architecture

The defining design choice is pinning Wi-Fi/WebServer (Core 0) and W5500 Ethernet/Modbus (Core 1) to separate cores. This keeps the HTTP handling for face-recognition results from interfering with the timing of real-time Modbus communication with the PLC.

Technology Background

Modbus TCP is the most widely used industrial communication protocol, built on a simple request-response model where a client reads and writes coils and registers on a server. Here, the ESP32 is the server and the FX5U PLC is the client — every start, stop, and emergency command boils down to flipping a single coil on or off.

W5500 hardware TCP/IP offloading means the MCU delegates the TCP/IP stack to a dedicated chip instead of processing it in software. It supports 8 independent sockets, and this project actually leans on that: it periodically reads the W5100.readSnSR() register to diagnose socket status in real time.

Haar Cascade + LBPH are, respectively, a lightweight detection algorithm ("where is a face in this frame") and a recognition algorithm ("whose face is this"). Both predate deep learning and are light enough to run real-time authentication on a single PC.

Technical Highlights

• Dual-core task separation: Wi-Fi (priority 1) and Modbus/Ethernet (priority 2) are pinned to separate cores to minimize SPI communication latency.
• SPI clock down-tuning: forcing the CPU to 240 MHz is commented out in the code as causing "W5500 instability," and the SPI clock is lowered to 8 MHz for stability across multi-device networks.
• Atomic-flag-based thread safety: cross-core command handoff uses std::atomic to avoid race conditions.

Where WIZnet Fits

The chip actually used is the W5500. It's wired to the ESP32-S3's SPI bus (CS=10, MOSI=11, SCLK=12, MISO=13) and handles the Modbus TCP server socket on port 503, with the ModbusEthernet class from the emelianov/modbus-esp8266 library managing the coil and register tables on top of it.

What stands out is that the code reaches down to register-level diagnostics on the W5500. Every 3 seconds, it reads the Sn_SR (socket status register) values across all 8 sockets and logs them — directly addressing the common industrial-floor problem of "the connection dropped, but nothing tells you" using the W5500's own hardware status information.

Similar Projects on WIZnet Makers

Guide to Modbus TCP ESP32 Communication... Siemens S7-1200 PLC: Uses the identical ESP32+W5500+Modbus TCP combination to talk to a real commercial PLC, but with the roles reversed. There, the ESP32 is the client and the Siemens PLC is the server; here, the ESP32 is the server and the FX5U is the client. 

→ Project link: https://maker.wiznet.io/bruno/projects/guide-to-modbus-tcp-esp32-communication-between-w5500-module-and-siemens-s7-1200-plc-factoryautomat/

esp32-modbus-w5500: Shares the same basic skeleton of reading and writing Modbus TCP coils over ESP32+W5500. This one hand-builds the MBAP header as a learning exercise, while our project layers a library-based approach plus dual-core design and face recognition on top of it. 

→ Project link: https://maker.wiznet.io/lawrence/projects/esp32-modbus-w5500/

plc-stm32: Shares the goal of using W5500 as a wired Ethernet interface for an industrial PLC, but runs on an STM32 with only hardware design published — no firmware. Our project is ESP32-based with completed, field-tested firmware. 

→ Project link: https://maker.wiznet.io/irina/projects/plc-stm32/

All three cases converge on the same conclusion: wired Ethernet through W5500 beats Wi-Fi for reliable PLC integration — a takeaway that holds regardless of MCU choice or project scale.

As the table shows, the clearest differentiator for this project is layering a face-recognition authentication layer on top of the familiar "W5500 Modbus gateway" pattern seen in the other cases.

Business Value

• Low-cost cross-brand PLC integration: demonstrates that a cheap ESP32+W5500 combo can talk to a different-brand PLC (FX5U) over an industry-standard protocol.
• Auditable access control: face recognition closes the gap left by shared-PIN systems, where there's no record of who actually operated the machine.
• Room to scale into remote monitoring: the same web HMI structure could extend to centrally monitoring multiple stations.
• A teaching reference architecture: shows one concrete way to fuse IT (face recognition) and OT (PLC control) through a single gateway.

Limitations and Future Improvements

Current limitations

• Modbus TCP has no built-in authentication or encryption, so anyone with network access can directly manipulate coils.
• Haar Cascade + LBPH is sensitive to lighting and angle, and can produce more false matches than deep-learning-based recognition.
• The Wi-Fi (10.251.64.200) and Ethernet (192.168.1.50) IPs are hardcoded, requiring a recompile for every new deployment environment.
• The face dataset and trainer.yml are stored unencrypted on the PC, which sits awkwardly against specific-personal-data protection requirements.
• Both the Modbus server and the web server run on a single ESP32, so if that device goes down, PLC control stops entirely.

Improvement directions As a PBL project, prioritizing "getting it working" was a reasonable trade-off. Natural next steps include adding a VPN or firewall rules around the Modbus TCP segment, encrypting the stored face dataset, and adding redundancy through a second ESP32 or a watchdog mechanism.

FAQ

Q1. Can this be adapted to a different PLC brand, like Siemens? Yes. Since the ESP32 only acts as a Modbus TCP server, any PLC that can be configured as a Modbus TCP client will work regardless of brand.

Q2. Why use both Wi-Fi and wired Ethernet at the same time? PC-to-ESP32 commands go over Wi-Fi (HTTP), while ESP32-to-PLC control runs over W5500 wired Ethernet — separating the two keeps the industrial control path deterministic.

Q3. How could biometric data protection be strengthened? At minimum, encrypting trainer.yml and the face image dataset at rest, plus logging access, would be reasonable first steps.

Q4. Is there a documented reason for choosing the ESP32-S3? No explicit reasoning appears in the README or code — this is unconfirmed. The PSRAM and 16MB flash options were likely useful for handling face-recognition data, but that's an [Inferred] conclusion.

Q5. How difficult is this to reproduce? Anyone with ESP32 Arduino experience and familiarity with PLC Modbus TCP configuration (communication setup, not ladder logic) could reproduce it with just wiring and IP configuration.