--- title: "FPGA Slow Control Interlock System (SCIS)" url: "https://maker.wiznet.io/irina/projects/fpga-slow-control-interlock-system-scis/" markdown_url: "https://maker.wiznet.io/irina/projects/fpga-slow-control-interlock-system-scis/md" type: "UCC: User Created Content" author: "daanders03" author_url: "https://github.com/daanders03/SCIS_DataConcentrator" editor: "WIZnet" editor_url: "https://maker.wiznet.io/" original_author: "daanders03" original_url: "https://github.com/daanders03/SCIS_DataConcentrator" published: "2026-07-20" language: "en" likes: 0 views: 167 comments: 0 source: "WIZnet Makers (https://maker.wiznet.io/)" --- # FPGA Slow Control Interlock System (SCIS) > An FPGA-based Slow Control Interlock System on a Cologne Chip GateMate FPGA that ingests measurement data over UDP via dual WIZnet W5500 modules (RX/TX). Original author: daanders03 (source: https://github.com/daanders03/SCIS_DataConcentrator) ## Article **상위프로젝트 존재 상위 프로젝트와의 관계**: 이 글이 다루는 `daanders03/SCIS_DataConcentrator`는 더 큰 SCIS 프로젝트인 **HTI-OVGU/FPGA-centric-SCIS**(마그데부르크대 HTI 연구실, MIT)의 **데이터 컨센트레이터(Data Concentrator)** 구현에 특화된 저장소입니다. 상위 프로젝트는 SCIS를 "**관리 감시 유닛(Supervisory Monitoring Unit)**"이라는 전체 아키텍처 관점에서 기술하고, 이식성(여러 FPGA로 포팅 가능한 HDL 설계)을 강조합니다. 즉 **상위 = 전체 SCIS 아키텍처, 이 글 = 그 안의 데이터 컨센트레이터 상세**로 보시면 됩니다. (상위 프로젝트 소개 글: viktor / [https://maker.wiznet.io/viktor/projects/fpga-centric-slow-control-interlock-system-scis](https://maker.wiznet.io/viktor/projects/fpga-centric-slow-control-interlock-system-scis/)- ) ## 프로젝트가 하는 일 **SCIS(Slow Control Interlock System)** 는 여러 계측 장비에서 오는 측정값을 한곳에 모아, **임계값을 넘으면 즉시 인터록(안전 차단) 신호를 발생**시키는 FPGA 기반 안전 감시 시스템입니다. 핵심은 **Cologne Chip GateMate M1A1 FPGA** 에 구현된 **데이터 컨센트레이터(Data Concentrator)** 이고, 데이터 입출력은 **WIZnet W5500 이더넷**이 담당합니다. (물리 실험·가속기·검출기 계열의 "슬로 컨트롤 + 인터록" 용도로 보입니다.) 동작 흐름: - **Metric Provider / DAQ** 들이 측정값을 **Metric Packet**으로 만들어 전송 — 패킷 = 프로토콜 코드(V01) + 장치 식별자 + 측정값(**Q22.10 부호 고정소수점**) - 이 패킷이 **W5500을 통해 UDP**로 GateMate FPGA에 도착 - FPGA의 **Data Concentrator**가 받아 **Threshold Logic Unit(임계값 로직)** 으로 판정 → 초과 시 **저지연·결정적 인터록** 발생 - 상태는 소프트웨어(**Prometheus + Grafana**)로 모니터링 ![](https://maker.wiznet.io/upload/ckeditor5/624017004%5F1784022050%2Epng) ## COMPONENTS | Component | Notes | Qty | | --- | --- | --- | | Cologne Chip **GateMate M1A1** FPGA Eval Board V3.2 | 데이터 컨센트레이터·인터록 로직 구현 | x 1 | | **WIZnet W5500 Ethernet module (SPI, PMOD)** | UDP 계측 패킷 입출력 — **RX용 1개 + TX용 1개** | x 2 | | ESP32 (테스트용, 필수 아님) | 외부 인터록 신호를 흉내 내는 자극기(개발·검증용) | x 1 | | 64Mb SPI Flash (quad) | 비트스트림 저장(빠른 FPGA 재구성) | x 1 | | Metric Provider / DAQ (외부) | 계측값을 Metric Packet으로 송신 | x N | ## WIZnet이 들어가는 위치 이 프로젝트의 이더넷 플랫폼은 **W5500**이며, 특징적으로 **두 개(듀얼)** 를 사용합니다. - **역할**: 계측 장비의 **Metric Packet을 UDP로 수신**해 FPGA 데이터 컨센트레이터에 공급하고, 경보/텔레메트리를 송신 - **듀얼 구성**: **하나는 RX(수신) 전용, 하나는 TX(송신) 전용** — 각각 **PMOD 핀에 SPI**로 연결해 송·수신 처리량을 분리 확보 - **구현 확인된 것**(README "Working"): W5500 컨트롤러(UDP)에서 **8개 소켓 라운드로빈**, `send_first`/`receive_first` 기본 루틴, RX·TX W5500 분리 운용, 40MHz FPGA sys_clk에서 동작 - **테스트 구성**: GateMate M1A1 Eval Board V3.2 + **W5500 모듈 2개** + 외부 인터록 테스트용 ESP32 1개 ![](https://maker.wiznet.io/upload/ckeditor5/619268624%5F1784533736%2Epng) 즉 W5500은 이 안전 인터록 시스템에서 **계측 데이터를 이더넷(UDP)으로 실어 나르는 통신 계층**이며, 하드웨어 TCP/IP·8소켓·32KB 버퍼를 활용해 FPGA가 판정 로직에 집중하도록 합니다. ## ESP32는 왜 쓰나요? (테스트용 보조 장치) 혼동하기 쉬운데, 이 시스템에서 **ESP32는 핵심 부품이 아니라 개발·검증용 보조 장치**입니다. README의 테스트 구성에 "외부 인터록 assertion 테스트(external interlock assertion testing)"용으로 명시돼 있습니다. - SCIS의 안전 기능 중 하나는 "**외부에서 인터록 신호가 들어오면 즉시 차단**"하는 것입니다(FPGA에 외부 인터록 입력 + 히스테리시스 글리치 필터 존재). - 이 기능을 개발·시험하려면 **인터록 신호를 실제로 만들어 넣어줄 무언가**가 필요합니다. 진짜 계측 장비를 붙이기 전에요. - 그 역할을 **ESP32가 대신**합니다 — 즉 **가짜 외부 인터록 신호를 발생시켜 FPGA가 제대로 차단하는지 확인하는 "신호 자극기(stimulus)"** 입니다. 정리하면, **계측 데이터의 본류는 전부 W5500(UDP)** 이 담당하고 ESP32는 관여하지 않습니다. ESP32는 **운용 필수 요소가 아니라, 동작 검증을 위한 테스트 도구**입니다 ## 데이터 컨센트레이터 (FPGA 내부) - **8-bit AXI-stream** 기반 데이터 흐름 - **Threshold Logic Unit**: 저지연·결정적 인터록 assertion - 외부 인터록 신호용 **히스테리시스 글리치 필터** - **8단계 우선순위**(3-bit USER 필드), Priority FIFO에서 최고 우선순위 우선 readout - **Telemetry Sender**: 이상 시 "INTERLOCK" / "ALMOSTFULL" 경보 전송 - 새 장치 추가는 `threshold_address_generator.py`로 Threshold Lookup Memory에 등록 ![](https://maker.wiznet.io/upload/ckeditor5/619269681%5F1784541865%2Epng) 아래 순서로 신호가 흐릅니다. 1. **입력단**: 여러 **Metric Source(계측 소스 0·1·…·n)** 와 **Ethernet Interface RX Side**(W5500 수신)가 데이터를 올려보냅니다. 별도로 **External Interlock Signal Source**(외부 인터록 신호원)가 오른쪽 경로로 들어옵니다. 2. **Threshold Logic 0~n**: 각 계측 소스는 자기 임계값 로직을 거쳐 "한계를 넘었는가?"를 판정합니다. 외부 인터록 신호는 옆의 **Glitch Filter(히스테리시스 글리치 필터)** 를 거쳐 순간 잡음이 걸러집니다. 3. **첫 번째 Demux**: 판정 결과가 우선순위/목적지에 따라 갈라집니다. 4. **Round Robin Arbitration & Selection of Priority FIFO**: 여러 입력을 라운드로빈으로 공평하게 훑어, 어떤 **Priority FIFO**에 넣을지 고릅니다. 5. **Mux → Priority FIFO 0~n**: 선택된 경로가 **우선순위별 FIFO(대기열)** 에 적재됩니다. 우선순위는 8단계(3-bit)입니다. 6. **Priority Scheduling Logic + Demux**: 스케줄링 로직이 **가장 높은 우선순위부터** 꺼내도록 제어합니다. 7. **Metric Packet Manager**: 위 과정(라운드로빈 수집 → 우선순위 FIFO → 우선순위 스케줄링)을 묶는 관리 블록입니다. 8. **Telemetry Sender**: 최종적으로 상태·경보(예: "INTERLOCK", "ALMOSTFULL")를 만들어 **Ethernet Interface TX Side**(W5500 송신)로 내보냅니다. 9. **Further Interlock Processing**: 외부 인터록 신호원과 글리치 필터를 지난 인터록 경로(그림 오른쪽의 빨간 선)는 별도의 **후속 인터록 처리** 블록으로 이어져, 계측 데이터 경로와 독립적으로 안전 차단을 담당합니다. 핵심은 두 가지입니다. 첫째, **계측 데이터(왼쪽)와 외부 인터록 신호(오른쪽)가 분리된 경로**로 처리되어, 인터록이 데이터 혼잡과 무관하게 결정적으로 동작합니다. 둘째, **입력은 W5500 RX, 출력은 W5500 TX**로 나뉘어(듀얼 구성) 수신 계측과 송신 경보가 서로 방해하지 않습니다. ## 구현 메모 - **툴체인**: OSS-CAD-Suite(YosysHQ, Build 21-01-2026 테스트) — 합성·구현·비트스트림 패킹·업로드. 시뮬레이션은 GHDL + GTKwave. - **빌드**: `make all`(PMOD의 두 W5500용 데이터 컨센트레이터 빌드) · `make w5500_all`(W5500 기능 테스트) · `make sim_spimaster`/`sim_w5500`/`sim_dc`/`sim_all`(시뮬레이션) - **비트스트림**: 64Mb SPI 플래시(quad 모드)에 업로드해 빠르게 재구성 - **언어**: Verilog ~73% / VHDL ~24% (하드웨어 설계 중심) + Python ## 알려진 이슈 / 개발 단계 - **버그**(README 명시): RX용 W5500이 **2KB RX 버퍼를 초과하는 UDP 폭주 시 소켓을 닫는** 경우가 있음 - **백로그**: **TCP 패킷용 W5500 컨트롤러**(AXI-stream tdata에서 UDP 헤더 제거) 추가 예정 - 초기 단계(커밋 7, 스타 0, 릴리스 없음). 저장소에 아키텍처 그림(`etc/figure/`), 재구성 시간 자료(`.xlsx`), 배치도(`placed.svg`) 포함. ## 유사 프로젝트 두 관점으로 나눠 정리했습니다 — **(A) 같은 플랫폼(FPGA + W5500)** 과 **(B) 하는 일이 비슷한 프로젝트(계측 집약·산업 모니터링·안전 제어)**. 모두 maker.wiznet.io에 실재하는 글입니다. ### (A) 같은 플랫폼 — FPGA + W5500 1. **FPGA + W5500 Control Unit (mark)** — Spartan-6 XC6SLX150 + W5500을 중앙 제어로 쓰는 **8채널 종합 계측·제어 시스템**. 측정 데이터를 기록·해석·저장·전달합니다. 2. **EasyDAB v2 (Lihan__)** — Xilinx XC6SLX9 FPGA + **W5500 SPI로 HW TCP/IP 오프로드**, PicoBlaze6 소프트 CPU + **AXI4-Stream** 파이프라인(구조가 SCIS와 유사, 용도는 DAB 방송 변조). 3. **Firewall on FPGA (irina)** — FPGA에서 W5500을 SPI로 구동해 **네트워크 패킷을 하드웨어로 처리**(SCIS는 계측 인터록, 이쪽은 인라인 필터링). 4. **TCP/IP stack design based on FPGA and W5500 (WIZnet Makers)** — FPGA가 W5500을 **TCP/IP 서버**로 구동해 상위 PC와 명령·데이터를 주고받는 기본 예제. | 항목 | SCIS Data Concentrator | FPGA+W5500 Control Unit | EasyDAB v2 | Firewall on FPGA | | --- | --- | --- | --- | --- | | 목적 | 계측 집약 + 안전 인터록 | 8채널 계측·제어 | DAB 방송 변조 | 네트워크 방화벽 | | FPGA | GateMate M1A1 | Spartan-6 | Spartan-6 (XC6SLX9) | Artix-7 계열 | | W5500 | 듀얼(RX/TX), UDP | 중앙 제어 이더넷 | HW TCP/IP 오프로드 | 보조 이더넷 포트 | | 구조 | 8-bit AXI-stream | Verilog 제어 | PicoBlaze6 + AXI4-Stream | HW 규칙 파이프라인 | ### (B) 비슷한 용도 — 계측 집약 · 산업 모니터링 · 안전 제어 (플랫폼 무관) FPGA/W5500 여부와 무관하게, **"여러 계측 데이터를 이더넷으로 모아 → 판정/제어"** 라는 SCIS의 목적과 닮은 프로젝트들입니다. 1. **How to Design a Super Simple Sensor System for Industrial Monitoring (ssekim)** — 산업 모니터링용 모듈형 센서 시스템의 이더넷 서브시스템. **센서 데이터를 이더넷으로 집약**하는 부분이 SCIS의 계측 집약과 가장 유사. 2. **Securing Industrial PLCs with WIZnet W5500 — Open-Source IoT Gateway (Benjamin)** — PLC 데이터를 추출해 W5500 이더넷으로 안전하게 전송하는 산업 IoT 게이트웨이. **HW TCP/IP 오프로드로 MCU가 실시간 작업에 집중, 유선으로 안정적 모니터링·제어** — SCIS의 저지연·결정적 처리와 통함. 3. **Communication with Siemens PLC using M5Stack W5500 LAN Module (Benjamin)** — 산업 제어기(Siemens PLC)의 계측/상태 데이터를 이더넷으로 **수집·시각화**. SCIS의 계측 수집 목적과 유사. 4. **TNN Smart Control (anhtn1980)** — 2계층 LAN으로 명령을 받아 **RS485 릴레이(장비)를 제어**하는 시스템. "네트워크로 받은 판단 → 물리 장비 안전 제어"라는 흐름이 SCIS의 인터록(차단)과 유사. | 항목 | SCIS Data Concentrator | Simple Sensor System | Industrial PLC Gateway | Siemens PLC Comm | TNN Smart Control | | --- | --- | --- | --- | --- | --- | | 하는 일 | 계측 집약 → 인터록 | 센서 데이터 이더넷 집약 | PLC 데이터 수집·전송 | PLC 데이터 수집·시각화 | 명령 수신 → 릴레이 제어 | | 초점 | 저지연 안전 차단 | 산업 모니터링 | 산업 IoT·보안 | 산업 통신 | LAN 기반 장비 제어 | | 네트워크 | W5500(UDP) | W5500 | W5500(HW TCP/IP) | W5500(M5Stack) | W5500(2노드) | ## FAQ **Q: 이 프로젝트는 무엇인가요?** A: GateMate FPGA에 데이터 컨센트레이터를 구현해, 계측 데이터를 모아 임계값 초과 시 저지연 인터록(안전 차단)을 내는 슬로 컨트롤 시스템입니다. **Q: W5500은 어떻게 쓰이나요?** A: 두 개를 써서 하나는 UDP 수신(RX), 하나는 송신(TX) 전용으로 PMOD에 SPI 연결합니다. 계측 Metric Packet을 UDP로 받아 FPGA에 공급합니다. **Q: 왜 W5500을 두 개 쓰나요?** A: 수신과 송신을 물리적으로 분리해 처리량과 결정성을 확보하기 위해서입니다(RX 전용·TX 전용). **Q: 완성된 제품인가요?** A: 아니요. 개발 초기 단계이며, RX 버퍼 초과 시 소켓이 닫히는 버그와 TCP 컨트롤러 추가가 백로그에 있습니다. **Q: ESP32는 왜 들어가나요?** A: 핵심 부품이 아니라 **테스트 전용 보조 장치**입니다. 외부 인터록 신호를 흉내 내 FPGA가 제대로 차단하는지 검증하는 용도이며, 실제 계측 데이터 전달은 전부 W5500이 담당합니다. --- ## What the Project Does **SCIS (Slow Control Interlock System)** is an FPGA-based safety-monitoring system that aggregates measurements from multiple instruments and **asserts an interlock (safety cutoff) the moment a threshold is exceeded**. Its core is a **Data Concentrator** on a **Cologne Chip GateMate M1A1 FPGA**, with the **WIZnet W5500** as the Ethernet platform. (It reads like a "slow control + interlock" system for physics experiments / accelerators / detectors.) Flow: - **Metric Providers / DAQ** send measurements as **Metric Packets** — packet = protocol code (V01) + device identifier + value (**Q22.10 signed fixed-point**) - Packets arrive over **UDP via the W5500** to the GateMate FPGA - The FPGA **Data Concentrator** evaluates them in **Threshold Logic Units** → on exceedance, a **low-latency deterministic interlock** fires - Status is monitored in software (**Prometheus + Grafana**) ![](https://maker.wiznet.io/upload/ckeditor5/624017004%5F1784022050%2Epng) ## Where WIZnet Fits The Ethernet platform is the **W5500**, and notably it uses **two of them (dual)**. - **Role**: **receive Metric Packets over UDP** and feed the FPGA data concentrator; send alerts/telemetry - **Dual setup**: **one W5500 for RX, one for TX**, each connected over **SPI on PMOD pins**, separating receive/transmit throughput - **Working** (per README): W5500 controller (UDP) with **round-robin over 8 sockets**, `send_first`/`receive_first` default routines, separate RX/TX W5500 operation, running at a 40 MHz FPGA sys_clk - **Test rig**: GateMate M1A1 Eval Board V3.2 + **two W5500 modules** + one ESP32 for external interlock-assertion testing ![](https://maker.wiznet.io/upload/ckeditor5/619268624%5F1784533736%2Epng) So the W5500 is the **transport layer that carries measurement data over Ethernet (UDP)**, using its hardware TCP/IP, 8 sockets, and 32 KB buffer so the FPGA can focus on the decision logic. ## Why an ESP32? (a test-only helper) It's easy to misread, but the **ESP32 here is not a core component — it's a development/verification helper**. The README lists it for "external interlock assertion testing." - One of SCIS's safety features is to **assert an interlock the moment an external interlock signal arrives** (the FPGA has an external-interlock input plus a hysteresis glitch filter). - To develop and test that, you need **something that actually generates an interlock signal** — before wiring up real instruments. - The **ESP32 plays that role**: a **stimulus that injects a mock external-interlock signal to check that the FPGA cuts off correctly**. In short, **all real measurement traffic goes through the W5500 (UDP)**; the ESP32 isn't involved in it. The ESP32 is **a test tool for verification, not a required part of the deployed system**. ## Data Concentrator (inside the FPGA) - **8-bit AXI-stream** data flow - **Threshold Logic Units**: low-latency deterministic interlock assertion - **Hysteresis glitch filter** for external interlock signals - **8 priority levels** (3-bit USER field); highest-priority-first readout from Priority FIFOs - **Telemetry Sender**: emits "INTERLOCK" / "ALMOSTFULL" alerts - New devices are added to the Threshold Lookup Memory via `threshold_address_generator.py` ![](https://maker.wiznet.io/upload/ckeditor5/619269681%5F1784541873%2Epng) *Data flows from the inputs at the bottom to the outputs at the top.* 1. **Inputs**: several **Metric Sources (0, 1, …, n)** and the **Ethernet Interface RX Side** (W5500 receive) feed data upward. Separately, an **External Interlock Signal Source** enters on the right-hand path. 2. **Threshold Logic 0–n**: each metric source passes through its own threshold logic to decide "is the limit exceeded?" The external interlock signal passes through the adjacent **Glitch Filter** (hysteresis) to reject transient noise. 3. **First Demux**: results are split by priority/destination. 4. **Round Robin Arbitration & Selection of Priority FIFO**: sweeps the inputs fairly round-robin and chooses which **Priority FIFO** to write to. 5. **Mux → Priority FIFO 0–n**: the selected path is queued into a **per-priority FIFO** (8 levels, 3-bit). 6. **Priority Scheduling Logic + Demux**: the scheduler controls readout **highest-priority first**. 7. **Metric Packet Manager**: the block that bundles the above (round-robin collection → priority FIFOs → priority scheduling). 8. **Telemetry Sender**: finally builds status/alerts (e.g., "INTERLOCK", "ALMOSTFULL") and sends them out via the **Ethernet Interface TX Side** (W5500 transmit). 9. **Further Interlock Processing**: the interlock path (red lines on the right, from the external signal source through the glitch filter) leads to a separate **further interlock processing** block, handling safety cutoff independently of the measurement-data path. Two key points: first, **measurement data (left) and the external interlock signal (right) are processed on separate paths**, so the interlock stays deterministic regardless of data congestion. Second, **inputs use the W5500 RX and outputs use the W5500 TX** (dual setup), so received measurements and outbound alerts don't interfere. ## Implementation Notes - **Toolchain**: OSS-CAD-Suite (YosysHQ, tested Build 21-01-2026) for synthesis/implementation/bitstream; GHDL + GTKwave for simulation. - **Build**: `make all` (data concentrator for the two PMOD W5500s), `make w5500_all` (W5500 functional test), `make sim_spimaster`/`sim_w5500`/`sim_dc`/`sim_all` (simulations) - **Bitstream**: uploaded to a 64 Mb SPI flash (quad mode) for fast reconfiguration - **Languages**: Verilog ~73% / VHDL ~24% (hardware-centric) + Python ## Known Issues / Project State - **Bug** (README): the RX W5500 sometimes closes a socket when bombarded with UDP packets exceeding the 2 KB RX buffer - **Backlog**: a **TCP-packet W5500 controller** (strips the UDP header from AXI-stream tdata) is planned - Early stage (7 commits, 0 stars, no releases). Repo includes architecture figures (`etc/figure/`), reconfiguration-time data (`.xlsx`), and a placement view (`placed.svg`). ## Similar Projects Grouped two ways — **(A) same platform (FPGA + W5500)** and **(B) similar purpose (measurement aggregation · industrial monitoring · safety control)**. All are real maker.wiznet.io posts. ### (A) Same platform — FPGA + W5500 1. **FPGA + W5500 Control Unit (mark)** — A Spartan-6 XC6SLX150 + W5500 as the central controller of an **8-channel measurement & control system**, recording/interpreting/storing/forwarding data. 2. **EasyDAB v2 (Lihan__)** — Xilinx XC6SLX9 FPGA with **W5500 SPI hardware TCP/IP off-load**, a PicoBlaze6 soft CPU and an **AXI4-Stream** pipeline (structurally similar; application is DAB modulation). 3. **Firewall on FPGA (irina)** — Drives the W5500 over SPI to **process network packets in hardware** (SCIS does interlocks; this does inline filtering). 4. **TCP/IP stack design based on FPGA and W5500 (WIZnet Makers)** — An FPGA drives the W5500 as a **TCP/IP server** exchanging commands/data with a host PC. | Item | SCIS Data Concentrator | FPGA+W5500 Control Unit | EasyDAB v2 | Firewall on FPGA | | --- | --- | --- | --- | --- | | Purpose | Measurement aggregation + interlock | 8-channel measure/control | DAB modulation | Network firewall | | FPGA | GateMate M1A1 | Spartan-6 | Spartan-6 (XC6SLX9) | Artix-7-class | | W5500 | Dual (RX/TX), UDP | Central-control Ethernet | HW TCP/IP off-load | Secondary Ethernet port | | Structure | 8-bit AXI-stream | Verilog control | PicoBlaze6 + AXI4-Stream | HW rule pipeline | ### (B) Similar purpose — measurement aggregation · industrial monitoring · safety control (any platform) Regardless of FPGA/W5500, these match SCIS's goal of **"aggregate measurement data over Ethernet → decide/control."** 1. **How to Design a Super Simple Sensor System for Industrial Monitoring (ssekim)** — The Ethernet subsystem of a modular industrial-monitoring sensor system. **Aggregating sensor data over Ethernet** is closest to SCIS's aggregation. 2. **Securing Industrial PLCs with WIZnet W5500 — Open-Source IoT Gateway (Benjamin)** — Extracts PLC data and sends it securely over W5500 Ethernet. **HW TCP/IP off-load frees the MCU for real-time tasks; reliable wired monitoring/control** — matching SCIS's low-latency deterministic processing. 3. **Communication with Siemens PLC using M5Stack W5500 LAN Module (Benjamin)** — **Collects and visualizes** measurement/status data from a Siemens PLC over Ethernet — similar to SCIS's data collection. 4. **TNN Smart Control (anhtn1980)** — A two-tier LAN system that receives commands and **controls RS485 relays (equipment)**. Its "networked decision → physical safety control" flow parallels SCIS's interlock (cutoff). | Item | SCIS Data Concentrator | Simple Sensor System | Industrial PLC Gateway | Siemens PLC Comm | TNN Smart Control | | --- | --- | --- | --- | --- | --- | | What it does | Aggregate → interlock | Aggregate sensor data | Collect/send PLC data | Collect/visualize PLC data | Receive cmd → drive relays | | Focus | Low-latency safety cutoff | Industrial monitoring | Industrial IoT · security | Industrial comms | LAN-based equipment control | | Network | W5500 (UDP) | W5500 | W5500 (HW TCP/IP) | W5500 (M5Stack) | W5500 (2 nodes) | ## FAQ **Q: What is this project?** A: A slow-control system that implements a data concentrator on a GateMate FPGA to aggregate measurements and assert a low-latency interlock (safety cutoff) when thresholds are exceeded. **Q: How is the W5500 used?** A: Two are used — one for UDP receive (RX), one for transmit (TX) — connected over SPI on PMOD. They carry measurement Metric Packets over UDP to the FPGA. **Q: Why two W5500s?** A: To physically separate receive and transmit for throughput and determinism (dedicated RX and TX). **Q: Is it a finished product?** A: No. It's early-stage; a known bug (socket closes on RX-buffer overflow) and a TCP controller are in the backlog. **Q: Why is there an ESP32?** A: It's not a core component but a **test-only helper** — it mimics an external interlock signal to verify the FPGA cuts off correctly. All real measurement data goes through the W5500. --- Source: https://maker.wiznet.io/irina/projects/fpga-slow-control-interlock-system-scis/