Wiznet makers

Overview
FieldLink is a small industrial controller pattern: keep the “must-not-fail” actions local and deterministic (physical STOP, mode interlock), then layer cloud visibility and optional remote control on top. It reports three-phase current (Ia/Ib/Ic) via Modbus RS485, publishes telemetry to MQTT over TLS, and drives a contactor output plus RUN/FAULT indicators.

Main Content

At the edge, the device reads digital inputs for START (NO), STOP (NC), and a mode selector (LOCAL when grounded, REMOTE when open). In LOCAL, remote commands are blocked; in REMOTE, MQTT commands (START/STOP/RESET) are accepted, but the physical STOP remains authoritative in both modes. 
For protection, it includes a DRY_RUN fault rule: if the contactor is ON but no current is detected for ~10 seconds, the controller shuts down and requires a RESET to clear the fault. 
Cloud interaction is intentionally thin: telemetry is JSON published to a per-device topic, and commands are simple strings. A web dashboard consumes the live data and exposes control buttons plus device status and mode indicators.

System Context
This fits sites where pumps must remain operable without the network, but operators still want remote visibility and “only-when-allowed” remote control. The LOCAL/REMOTE interlock turns cloud control into a supervised capability rather than a default authority.

Architecture / Design Considerations

• Hardwired interlock over software policy: LOCAL mode blocks MQTT commands at the device, reducing the blast radius of cloud-side mistakes or credentials leaks.
• Fail-safe STOP (NC): Wiring STOP as normally-closed means broken wiring trends toward “stop,” not “run.” If you cheap out here, you deserve the outage.
• Sensing path matters: The DRY_RUN rule depends on reliable current detection (via Modbus RS485). If sensing is noisy or offline, fault logic becomes either trigger-happy or blind.
• Ethernet note (WIZnet context): The reference hardware is an ESP32-S3 board with Ethernet capability. If your design uses a WIZnet Ethernet controller such as W5500 as the wired interface, the same MQTT-telemetry/control split still applies, but you must treat the Ethernet link as part of the safety boundary (remote commands stay subordinate to LOCAL/STOP).

Possible Implications

• The design encourages a clean separation: cloud provides visibility and optional actuation, while the edge controller enforces site safety rules.
• Extending beyond pumps (fans, compressors, conveyors) is straightforward if you preserve the same interlock philosophy and validate sensing-to-actuation latency.

Conclusion
FieldLink is less about fancy IoT and more about refusing to let the network be in charge of something that can flood a plant or burn a motor. The key idea is simple: local safety first, cloud second, and faults that shut things down when the real world disagrees with “ON.”

전체 개요

FieldLink는 펌프 제어에서 흔히 문제가 되는 “원격 제어 편의성”과 “현장 안전”의 충돌을, 물리 인터락(LOCAL/REMOTE) + 물리 STOP 우선으로 정리한 구조입니다. 디바이스는 3상 전류(Ia/Ib/Ic) 를 Modbus RS485로 수집하고, MQTT(TLS)로 텔레메트리를 올리며, 간단한 원격 명령(START/STOP/RESET)을 받습니다.

문제의식과 기술적 맥락 재구성

현장 펌프는 “돌아가야 할 때는 반드시 돌아가고, 멈춰야 할 때는 반드시 멈춰야” 합니다. 그런데 클라우드나 앱이 끼어들면, 네트워크 장애·계정 유출·오조작 같은 변수들이 제어권에 영향을 주기 쉽습니다. FieldLink는 이를 피하려고 원격은 ‘가능하면 허용’, 안전은 **‘항상 강제’**로 배치한 형태로 보입니다. (추론임: “원격 우선”을 막기 위해 인터락을 가장 앞단에 둔 의도가 핵심으로 읽힙니다.)

기술 흐름 설명

• 디지털 입력 수집
  • START: NO(순간 버튼)
  • STOP: NC(비상정지 성격, 단선 시 정지 방향)
  • MODE: GND면 LOCAL, 오픈이면 REMOTE
• 모드에 따른 제어권 결정
  • LOCAL: MQTT 명령 차단, 수동 START/STOP만 의미 있게 동작
  • REMOTE: MQTT START/STOP/RESET 수용, 수동 버튼도 여전히 동작
  • STOP은 양쪽 모드에서 항상 동작(안전 기능)
• 전류 측정(Modbus RS485)
  • Ia/Ib/Ic를 읽고, 펌프 운전 여부/이상 판단에 사용
• 구동 출력
  • DO1: 메인 접촉기(Contactor) 구동
  • DO2/DO3: RUN/FAULT 표시
• 클라우드 연계(MQTT + Dashboard)
  • 텔레메트리 JSON을 publish
  • command 토픽으로 문자열 명령 수신
  • 웹 대시보드는 전류/상태/모드 및 제어 버튼 제공

왜 이런 구조가 나왔는지에 대한 해설

• 원격 제어는 보조 수단으로 두고, 제어권을 “현장에 두는” 것이 핵심입니다. LOCAL 모드에서 MQTT를 차단하는 정책은, 클라우드가 살아 있어도 현장이 원격을 거부할 수 있게 만듭니다.
• STOP(NC)을 양 모드에서 항상 유효하게 둔 것은 “네트워크나 모드 상태와 무관하게 정지는 가능해야 한다”는 현장 안전 관점의 전형적인 선택입니다.

설계 선택의 배경, 제약 조건, 대안 가능성

• DRY_RUN 보호 로직: “접촉기 ON인데 전류가 없다”를 10초 기준으로 fault로 보고 자동 차단합니다. 이 로직은 단순하지만 효과적입니다.
• 다만 전류 측정이 불안정하거나 Modbus가 자주 끊기면, (추론임) 오탐/미탐이 발생할 수 있어 임계시간/필터링/센서 failover가 운영 안정성의 관건이 됩니다.
• 원격 명령 payload를 단순 문자열로 둔 것은 구현은 쉬워지지만, 운영 레벨에서 “누가/언제/왜”를 추적하기에는 추가 메타데이터가 필요할 수 있습니다. (추론임)

생소한 개념에 대한 풀어쓴 설명

• LOCAL/REMOTE 인터락: 원격 제어 기능이 있어도, 현장 스위치가 “원격을 허용할지”를 최종 결정하는 구조입니다.
• STOP(NC): Normally Closed라서, 선이 끊어지거나 접점이 떨어져도 “정지 방향”으로 동작하는 쪽에 가깝습니다.
• DRY_RUN: 펌프가 공회전하거나 물이 없는 상태로 운전될 때, 부하가 줄어 전류가 기대보다 낮게 나오거나 아예 감지가 안 되는 상황을 이용한 보호 기법입니다.

시스템 구성 및 선택지 해석

• 기준 하드웨어는 ESP32-S3 기반 보드(입출력 절연, RS485 포함, Ethernet/PoE 가능)로 제시되어 있습니다.
• 유선 Ethernet을 쓰는 경우, SPI Ethernet 컨트롤러 기반(WIZnet W5500 등)으로도 유사 패턴을 구성할 수 있는데, 이때도 “원격은 보조, 현장 인터락이 우선”이라는 경계는 그대로 유지되어야 합니다. (추론임: 통신 링크가 바뀌어도 안전 경계가 바뀌면 안 됩니다.)

내부 관점에서의 시사점

• 이 구조의 기존 접근 대비 핵심 차이는 “클라우드가 살아 있어도, 원격 명령이 항상 먹히는 게 아니라 현장이 허용할 때만 먹힌다”는 점입니다.
• 실패 비용이 가장 큰 구간은 DO1(접촉기 구동)과 그에 연동된 fault 판단입니다. 오동작하면 설비 손상/안전사고로 바로 이어질 수 있으니, 입력 배선(STOP/모드), 출력 드라이브, 전류 감지 신뢰도에 품질을 집중해야 합니다.
• 특정 구성요소 제거 시 시스템 성격 변화도 명확합니다. 예를 들어 MODE 스위치를 제거하면 “원격은 보조”가 아니라 “원격이 기본”으로 기울 수 있고, STOP(NC)를 약화시키면 현장 안전의 최후 방어선이 사라집니다. (추론임)
• 전류 감지(모드버스)가 빠지면 DRY_RUN 보호가 무력화되어, 시스템은 사실상 “원격 릴레이 제어기”에 가까워집니다.

FAQ

Q1. 기존 IoT 펌프 제어와 비교했을 때 가장 큰 차별점은 무엇인가요?
A1. 원격 제어를 “기본 권한”으로 두지 않고, LOCAL/REMOTE 스위치로 현장이 최종 허용권을 갖도록 설계되어 있습니다. 즉, 네트워크가 되더라도 현장이 원격을 차단할 수 있어 사고 범위를 줄입니다.

Q2. 왜 MQTT 명령을 LOCAL 모드에서 아예 막아버리나요?
A2. 원격 제어는 편의 기능이지만, 오조작이나 계정 문제, 운영 실수의 피해가 큽니다. LOCAL에서 차단하면 “원격이 불필요한 시간”에 제어권을 현장에 고정할 수 있습니다.

Q3. 이 시스템에서 실패 비용이 가장 큰 판단 지점은 어디인가요?
A3. 접촉기(DO1)를 실제로 켜고 끄는 구간과, 전류 감지 기반 fault 판단이 결합되는 지점입니다. 여기서 오동작하면 설비 손상 또는 안전 문제로 직결될 수 있어, 배선/입출력/센서 신뢰도 검증이 핵심입니다.

Q4. 핵심 신호/데이터 흐름을 한 줄로 요약하면 무엇인가요?
A4. “현장 입력(START/STOP/모드) → 접촉기 출력 → 전류(Modbus)로 상태 검증 → MQTT로 텔레메트리 제공, 원격은 모드에서 허용될 때만 수용” 흐름입니다. 이 순서가 안전 경계를 명확히 해 줍니다.

Q5. DRY_RUN 보호는 왜 중요한가요?
A5. 접촉기가 ON인데 전류가 없으면, 펌프가 실제로 일을 못 하거나(공회전) 계통 이상이 생겼을 가능성이 큽니다. FieldLink는 이를 10초 기준으로 fault 처리하고 자동 차단하는 방식으로 손상을 줄이려 합니다.

Q6. 전류 측정(Modbus RS485)을 제거하면 어떤 일이 생기나요?
A6. DRY_RUN 같은 “현실 기반 검증”이 사라져서, 시스템은 명령을 그대로 실행하는 단순 제어기로 성격이 바뀝니다. 결과적으로 안전 기능이 약해지고 운영자가 더 많은 책임을 떠안게 됩니다.

저자 정보 (Author Information)

• 공개된 저장소 기준으로는 GitHub 계정(또는 그룹) 단위로만 식별되며, 소속/기관의 성격이나 공식 이력은 공개된 정보가 제한적임으로 보입니다.
• 저장소 구성과 문서 수준으로 볼 때, 산업용 제어(펌프/접촉기), RS485(Modbus) 계측, MQTT 기반 원격 모니터링을 묶어 실제 운용 가능한 형태로 정리한 경험이 있는 개발/엔지니어링 성격이 강하게 드러납니다. (추론임)