Gateway neden kritik katmandır
Sensörler veri üretir. Bulut veri alır. Aralarında gateway oturur ve operasyonel ve güvenlik işinin %90'ı gateway'de olur.Gateway gerçekten ne yapar
- Protokol köprüleme — OT tarafında Modbus RTU, IT tarafında MQTT. Veya saha tarafında LoRa, bulut tarafında HTTPS.
- Edge filtreleme & buffering — gürültülü örnekleri düşür, uplink çöküyken veriyi tut, restore edildiğinde push et.
- Yerel mantık — bulut round-trip'inin izin verdiğinden daha hızlı ateşlemesi gereken alarmlar.
- Güvenlik sınırı — OT-tarafı güvenin bittiği ve IT-tarafı kimlik doğrulamasının başladığı yer.
- Firmware / model dağıtımı — buluttan güncellemeler çekme ve yerel cihazlara push.
- Diagnostic — "sistem gerçekten çalışıyor mu" konusunda tam bakışa sahip yer.
Donanım
Varsayılan:- CM4 tabanlı endüstriyel carrier — gateway gerçek iş yaparken, edge inference veya zengin analitik dahil.
- Endüstriyel x86 mini-PC — gateway sadece-Windows yazılımı çalıştırmalı veya müşterinin IT ekibi x86 belirler.
- ESP32 / STM32 tabanlı gateway — basit "RS-485'i MQTT'ye dönüştür" kullanım durumu için.
Consumer Raspberry Pi tahtası kullanma cazibesi gerçek. Yapmayın. Endüstriyel muhafazalar, eMMC depolama, düzgün güç girişi ve gerçek bir RTC fark yaratır.
Yazılım mimarisi
Gönderdiğimiz desen:- Linux (Debian veya Yocto tabanlı) base.
- Container'laştırılmış uygulama yığını (Docker veya Podman).
- Bir protokol-köprü servisi.
- Offline operasyon için yerel time-series buffer (TimescaleDB-on-edge veya DuckDB).
- Bulut uplink için MQTT istemci (veya HTTPS).
- OTA güncellemeleri ve diagnostic'ler için yerel yönetim agent'ı.
Güvenlik kontrol listesi (tartışılmaz)
- Varsayılan parola yok. Cihaz başına üretilmiş.
- Herhangi bir uplink için TLS. Bulut platformu desteklediğinde mTLS.
- Disk şifreleme (LUKS) — gateway çekip gidebilir.
- Ağ segmentasyonu — gateway hem OT hem IT VLAN'larında arayüze sahip, ama aralarında IP forwarding yok.
- Açık jumphost dışında hiçbir yerden SSH yok. Sadece public-key.
- Rollback kabiliyetli imzalı firmware güncellemeleri.
- Vendor-sağlanan varsayılan servisler (FTP, telnet, embedded web sunucuları) hepsi devre dışı.
Offline operasyon — yapmanız gereken test
Gateway'in uplink'ini bağlantısız bırakın ve davranışı 24 saat, sonra 7 gün gözleyin:- Veri toplamaya devam ediyor mu?
- Yerel buffer doğru doluyor mu?
- Uplink döndüğünde, bulutu boğmadan doğru backfill ediyor mu?
- "Offline'ım" durumunu görünür şekilde yüzeye çıkarıyor mu?
- Çalışmaya devam etmesi gereken yerel mantık çalışmaya devam ediyor mu?
Uyaracağımız bir şey
Üretimde Node-RED. Harika bir prototipleme aracı. Üretim uygulama platformu değil. Müşterinin "MVP" Node-RED akışını çalıştıran devraldığımız her gateway karmakarışık, debug edilemeyen sistem oldu.Devir
Devirde müşteri şunları yapabilmeli:- Dashboard'ta gateway sağlığını görmek.
- Mühendislik dahli olmadan bir veya tüm gateway'lere firmware güncellemesi push etmek.
- Herhangi bir gateway'den son 30 günün buffered verisini okumak.
- Dashboard'tan uzak yeniden başlatma tetiklemek.
Gateway yığınınız neye benziyor? Linux gateway'leri daha sıkı determinizm için embedded RTOS ile değiştiren var mı?
Why the gateway is the critical layer
Sensors generate data. The cloud receives data. Between them sits the gateway, and the gateway is where 90 % of the operational and security work happens.What a gateway actually does
- Protocol bridging — Modbus RTU on the OT side, MQTT on the IT side.
- Edge filtering & buffering — drop noisy samples, hold data when uplink is down, push when restored.
- Local logic — alarms that need to fire faster than the cloud round-trip allows.
- Security boundary — the place where OT-side trust ends and IT-side authentication begins.
- Firmware / model distribution — pulling updates from the cloud and pushing to local devices.
- Diagnostics — the place that has a complete view of "is the system actually working".
Hardware
We default to:- CM4-based industrial carrier — when the gateway is doing real work.
- Industrial x86 mini-PC — when the gateway needs to run Windows-only software.
- ESP32 / STM32-based gateway — for the simple "convert RS-485 to MQTT" use case.
The temptation to use a Raspberry Pi consumer board is real. Don't.
Software architecture
The pattern we ship:- Linux (Debian or Yocto-based) base.
- Containerised application stack (Docker or Podman).
- A protocol-bridge service.
- Local time-series buffer (TimescaleDB-on-edge or DuckDB) for offline operation.
- An MQTT client (or HTTPS) for cloud uplink.
- A local management agent for OTA updates and diagnostics.
Security checklist (non-negotiable)
- No default passwords. Per-device generated.
- TLS for any uplink. mTLS where the cloud platform supports it.
- Disk encryption (LUKS).
- Network segmentation.
- No SSH from anywhere except an explicit jumphost.
- Signed firmware updates with rollback capability.
- Vendor-supplied default services all disabled.
Offline operation — the test you must do
Disconnect the gateway's uplink and observe behaviour for 24 hours, then 7 days:- Does it keep collecting data?
- Does the local buffer fill correctly?
- When uplink returns, does it backfill correctly?
- Does it surface "I am offline" status visibly?
- Does the local logic that needs to keep running, keep running?
One thing we'd warn about
Node-RED in production. It's a wonderful prototyping tool. It is not a production application platform.The handover
At handover, the customer should be able to:- See gateway health on a dashboard.
- Push a firmware update to one or all gateways.
- Read the last 30 days of buffered data from any single gateway.
- Trigger a remote restart from the dashboard.
What does your gateway stack look like?
