smart-line

Bağlam ve amaç

smart-line, üretim hattındaki manuel ayırma ve izleme işini tek bir operatör yüzeyinde toplamak için tasarlanmış bir IIoT prototipidir. Amaç yalnızca sensör değerlerini göstermek değildir: ürün akışını, çevresel koşulları, yangın durumunu ve konveyör komutlarını aynı sistemin açık sorumlulukları haline getirmektir.

Proje; cihaz yazılımı, görüntü tabanlı veri toplama, mesajlaşma altyapısı, uygulama API’si ve dashboard arasında sınırları belirgin bir sistem kurar. Bu nedenle web arayüzü, fiziksel cihazlar ve güvenlik davranışı birbirinden bağımsız geliştirilebilir ve test edilebilir.

Nasıl çalışır

ESP32 firmware; ortam ve yangın verisini üretir. Ayrı bir Python vision servisi barkod ve QR sonuçlarını hazırlar; ESP32-CAM ise görüntü akışını sağlar. Cihaz ve vision mesajları, TLS ile korunan MQTT broker üzerinden API’ye ulaşır.

API arka plan servisleri bu mesajları işler, PostgreSQL’e kalıcı kayıtlar yazar ve SignalR ile dashboard’a canlı güncellemeler gönderir. Operatör; güncel ölçümleri, uyarıları, üretim hareketlerini ve konveyör durumunu aynı arayüzden izler. Komutlar doğrudan cihaza gitmez; API içindeki yetkilendirme ve güvenlik akışından geçer.

Sistem tasarımı

Sistem, her biri net bir sorumluluk taşıyan altı parçadan oluşur:

• SmartLine.Firmware, ESP32 sensör okuma, MQTT bağlantısı ve yerel acil-durum latch davranışını yürütür.
• SmartLine.Cam, ESP32-CAM üzerinden MJPEG görüntü akışı sağlar.
• SmartLine.Vision, OpenCV ve kod okuyucularla fiziksel ürün bilgisini MQTT mesajına dönüştürür.
• SmartLine.API, Minimal API, EF Core, PostgreSQL, MQTT tüketicileri ve SignalR hub’ını içerir.
• SmartLine.Dashboard, rol bazlı operasyon, canlı veri ve alarm deneyimini React ile sunar.
• Altyapı katmanı, Mosquitto, sertifikalar, Caddy ve Compose yapılandırmasıyla servis sınırlarını korur.

Bu tasarımda kullanıcı kimliği ile cihaz kimliği ayrıdır. İnsan kullanıcılar Viewer, Operator ve Admin rollerine sahipken cihazlar ayrı bir Device kimlik modeliyle mesajlaşır.

Öne çıkan teknik kararlar

MQTT tarafında anonim veya düz metin bağlantı yerine karşılıklı TLS, kullanıcı bilgisi ve principal tabanlı ACL kullanılır. Böylece broker’a bağlanabilmek, belirli bir topic üzerinde işlem yapabilmek anlamına gelmez.

Konveyör davranışı normal durdurma, acil durdurma ve yönetici resetini ayrı geçişler olarak ele alır. Firmware; cihaz epoch’u, yangın üretimi ve reset üretimini NVS üzerinde kalıcı tutar. Eksik veya bozuk kayıtla açılan bir cihaz güvenli tarafta kalır; yönetici reseti konveyörü otomatik başlatmaz.

API tarafında ağır bir soyutlama katmanı yerine feature odaklı Minimal API yaklaşımı kullanılır. MQTT komut geçişleri tek aktif API örneği varsayımı altında bir kapı mekanizmasıyla sıralanır; bu, iş kurallarının endpoint’lere dağılmasını önler.

Doğrulama ve sınırlar

API için gerçek PostgreSQL Testcontainers kullanan entegrasyon testleri, dashboard için lint ve build kontrolleri, firmware için PlatformIO derlemeleri ve Vision için Python doğrulamaları bulunur. Bu katmanlar ayrı çalıştığı için iletişim sözleşmelerindeki değişiklikler daha erken yakalanır.

Bu bir güvenlik-kritik donanım sertifikasyonu değildir. Servo konumunun güvenli kabul edilmesi motor enerjisini fiziksel olarak kesmez; gerçek bir üretim hattında hardwired acil durdurma devresi ve safety relay gerekir. Ayrıca komut geçişi koordinasyonu tek API instance varsayar; yatay ölçekleme için dağıtık bir güvenlik modeli gerekir.