---
title: "PBL-MK2025055SB001-ESP32-ModbusTCP"
url: "https://maker.wiznet.io/scott/projects/pbl-mk2025055sb001-esp32-modbustcp/"
markdown_url: "https://maker.wiznet.io/scott/projects/pbl-mk2025055sb001-esp32-modbustcp/md"
type: "UCC: User Created Content"
author: "MorisSintong"
author_url: "https://github.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP"
editor: "WIZnet"
editor_url: "https://maker.wiznet.io/"
original_author: "MorisSintong"
original_url: "https://github.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP"
published: "2026-07-16"
language: "en"
hardware: ["WIZnet W5500"]
likes: 0
views: 163
comments: 0
source: "WIZnet Makers (https://maker.wiznet.io/)"
---

# PBL-MK2025055SB001-ESP32-ModbusTCP

> PBL-MK2025055SB001: Face Detection & Assembly Station SCADA — Where a Face Becomes the Access Key

Original author: MorisSintong (source: https://github.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP)

## Components

- **WIZnet W5500** x 1 ([docs](https://docs.wiznet.io/Product/Chip/Ethernet/W5500))

WIZnet parts: W5500 ([Datasheet](https://docs.wiznet.io/Product/Chip/Ethernet/W5500/datasheet?utm_source=maker&utm_medium=project&utm_campaign=w5500), [product hub](https://maker.wiznet.io/products/w5500/))

## Documents and links

- [git](https://github.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP) (code)

## Article

## 요약

인도네시아 폴리테크닉(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>

## 아키텍처

![](https://maker.wiznet.io/upload/ckeditor5/1051658572%5F1784213777%2Epng)

**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의 하드웨어 상태 정보로 직접 해결하는 방식입니다.

![](https://raw.githubusercontent.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP/main/IMG_20260108_125204.jpg)

## 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 종류와 무관하게 일관됨을 보여줍니다.

| 항목 | 본 프로젝트 | bruno (S7-1200) | lawrence (esp32-modbus-w5500) | irina (plc-stm32) |
| --- | --- | --- | --- | --- |
| MCU | ESP32-S3 | ESP32 | ESP32 | STM32F407 |
| 네트워크 칩 | W5500 | W5500 | W5500 | W5500 |
| ESP32/MCU 역할 | Modbus 서버 | Modbus 클라이언트 | Modbus 클라이언트 | 미상(펌웨어 미구현) |
| 대상 PLC | Mitsubishi FX5U | Siemens S7-1200 | 미지정(일반 슬레이브) | 미상 |
| 부가 기능 | 안면인식 접근통제 | 없음 | 없음 | RS485, 릴레이 출력 |
| 완성도 | 펌웨어+PC HMI 완성 | 튜토리얼 재구성 | 예제 코드 | PCB 설계만 |

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

## 비즈니스 가치

- **저비용 이종 PLC 연동**: 값싼 ESP32+W5500만으로 브랜드가 다른 PLC(FX5U)와 산업표준 프로토콜로 연동 가능함을 실증

- **감사 추적 가능한 접근통제**: 누가 기계를 조작했는지 기록되지 않는 공유형 PIN 방식의 한계를 얼굴인식으로 보완

- **원격 모니터링 확장 여지**: 웹 HMI 구조를 그대로 확장해 다수 스테이션을 중앙에서 모니터링하는 시나리오로 발전 가능

- **교육용 레퍼런스 아키텍처**: IT(얼굴인식)와 OT(PLC 제어)를 하나의 게이트웨이로 통합하는 방법을 보여주는 실습 사례

![](https://raw.githubusercontent.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP/main/IMG_20260108_125654.jpg)

## 한계 및 개선 방향

**현재 한계**

- 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

![](https://maker.wiznet.io/upload/ckeditor5/1051658572%5F1784214146%2Epng)

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.

![](https://raw.githubusercontent.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP/main/IMG_20260108_125204.jpg)

## 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.

| Item | This Project | bruno (S7-1200) | lawrence (esp32-modbus-w5500) | irina (plc-stm32) |
| --- | --- | --- | --- | --- |
| MCU | ESP32-S3 | ESP32 | ESP32 | STM32F407 |
| Network chip | W5500 | W5500 | W5500 | W5500 |
| ESP32/MCU role | Modbus server | Modbus client | Modbus client | Unknown (no firmware) |
| Target PLC | Mitsubishi FX5U | Siemens S7-1200 | Unspecified generic slave | Unknown |
| Extra feature | Face-recognition access control | None | None | RS485, relay outputs |
| Completeness | Firmware + PC HMI complete | Reconstructed tutorial | Example code | PCB design only |

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.

![](https://raw.githubusercontent.com/MorisSintong/PBL-MK2025055SB001-ESP32-ModbusTCP/main/IMG_20260108_125654.jpg)

## 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.

---

Source: https://maker.wiznet.io/scott/projects/pbl-mk2025055sb001-esp32-modbustcp/
