FDA, FSMA 204 uyum tarihini Ocak 2026'dan Temmuz 2028'e erteledi. Gıda tedarik zincirleri veya soğuk zincir IoT alanında çalışanlar rahat bir nefes aldı. Ancak donanım tarafında sürekli karşılaştığım sorun: gecikme sensör sorunu değil, veri modeli sorunudur. Şirketlerin her yerde termometreleri var, ancak FDA'nın talep ettiği Kritik Takip Olayları (CTEs) ve Ana Veri Öğelerine (KDEs) sensör verilerini eşleştirecek bir şemaları yok. 20 yıldır soğuk zincir ve lojistik için IoT takip cihazları geliştiriyorum, 100'den fazla ülkeye sevkiyat yapıyorum. Desen hep aynı: bol telemetri, sıfır izlenebilirlik mimarisi.
FSMA 204, Gıda Takip Listesi'ndeki gıdaları işleyen şirketlerden FDA'nın talebi üzerine 24 saat içinde elektronik, sıralanabilir bir takip kayıtları tablosu sunmalarını gerektirir. Sistem şu soruları yanıtlamalı: Verilen lot_kodu = "LOT-2026-04-0042" için:
- Bu lotun geçtiği tüm CTE'ler
- Her CTE'deki KDE'ler (kim, ne, nerede, ne zaman, kimden/kime)
- Her transit segmentine ait sensör telemetrisi
- Anomaliler (sapmalar, veri boşlukları, lot uyumsuzlukları)
Biçim: sıralanabilir tablo Zaman bütçesi: < 24 saat
Çoğu ERP bunu yapamaz. İşlemleri takip eder, izlenebilirlik olaylarını değil.
Dört Katmanlı Mimarinin Çalışan Modeli:
Katman 1: Varlık (Ana Veri) Referans tablolarınız. Yavaş değişir. Konumlar: GLN veya FFRN tanımlayıcı, adres, tür Ürünler: GTIN, açıklama, FTL kategorisi Lotlar: İzlenebilirlik Lot Kodu (TLC), ürün_id, oluşturulma zamanı Aktörler: Yasal varlık, rol (üretici/işleyici/distribütör/perakendeci)
Katman 2: Olay (CTE Kayıtları) Her mülkiyet değişimi veya dönüşüm bir olay kaydı oluşturur. { "cte_türü": "teslim alma", "zaman damgası": "2026-04-15T14:30:00Z", "konum_gln": "0012345000010", "aktör_id": "distribütör-acme", "lot_kodu": "LOT-2026-04-0042", "ürün_gtin": "00012345678905", "kaynak_aktör": "işleyici-freshco", "miktar": 120, "birim": "kasa", "referans_doküman": "SİP-88921", "telemetri_oturum_id": "sess-7f3a9b" }
Yedi temel CTE: yetiştirme, teslim alma, dönüştürme/yaratma, sevkiyat, tekrar teslim alma (sonraki düğümde), ilk kara tabanlı alıcı.
Katman 3: Telemetri (Sensör Verisi) IoT katmanı. Olaylara telemetri_oturum_id üzerinden bağlanan sürekli zaman serisi verisi. { "oturum_id": "sess-7f3a9b", "sensör_id": "GPT29-birim-4471", "okumalar": [ { "ts": "2026-04-15T08:00:00Z", "sıcaklık_c": 2.1, "nem_yüzde": 65, "enlem": 32.78, "boylam": -96.80 }, { "ts": "2026-04-15T08:05:00Z", "sıcaklık_c": 2.3, "nem_yüzde": 64, "enlem": 32.79, "boylam": -96.78 }, { "ts": "2026-04-15T08:10:00Z", "sıcaklık_c": 5.8, "nem_yüzde": 71, "enlem": 32.80, "boylam": -96.77 } ] }
Ana tasarım kararları:
- Zaman damgalarını UTC olarak saklayın. Her zaman.
- Sensör saat sapması gerçek bir sorundur — her iletimde ağ saatine senkronize edin.
- Telemetri için ilişkisel veritabanı yerine zaman serisi veritabanı (InfluxDB, TimescaleDB) kullanın.
- Zaman damgası korelasyonu yerine oturum ID üzerinden bağlayın. Zaman damgaları sapar; oturum ID'leri sapmaz.
Katman 4: Kanıt (Denetim Dışa Aktarımları) Herkesin unuttuğu katman. FDA'nın aslında aldığı budur. Basitleştirilmiş hali: sıralanabilir tabloyu oluşturun SELECT e.cte_türü, e.zaman_damgası, l.adres AS konum, p.açıklama AS ürün, e.lot_kodu, e.kaynak_aktör, a.isim AS gerçekleştiren, anomali.tür AS anomali_işareti FROM olaylar e JOIN konumlar l ON e.konum_gln = l.gln JOIN ürünler p ON e.ürün_gtin = p.gtin JOIN aktörler a ON e.aktör_id = a.id LEFT JOIN anomaliler anomali ON anomali.olay_id = e.id WHERE e.lot_kodu = 'LOT-2026-04-0042' ORDER BY e.zaman_damgası;
Bu sorguyu ilk günden tasarlayın. Çıktıyı üretemiyorsanız, diğer üç katman önemli değildir.
Anomaliler için Tasarım Normal operasyonlar kolaydır. İşte asıl sorunlar: Sıcaklık sapması: Bir okuma eşiği aşar (örneğin, soğutulmuş ürün için >4°C). Otomatik olarak bir anomali kaydı oluşturun: { "tür":
Yapay zeka özeti
Learn how to build a four-layer data model for FSMA 204 cold chain traceability. Understand CTEs, KDEs, and sensor integration to meet FDA compliance by 2028.
