Veri yönetimi ve mimari

IronFlock; ölçeklenebilirlik, güvenlik ve net veri sahipliği hedefiyle tasarlanmış, uçtan uca — edge’den buluta — tam bir veri alma ve depolama altyapısı sağlar. İster binlerce sensörden gelen telemetriyi yönlendirin, ister gerçek zamanlı SCADA arayüzleri oluşturun, IronFlock’un veri mimarisi bilgilerinizin güvenli, izole ve erişilebilir olmasını güvence altına alır.

Mesaj yönlendirmesi ve güvenli realm’ler

IronFlock’un gerçek zamanlı iletişiminin kalbinde sağlam bir mesaj yönlendirme kümesi bulunur. Bu mesajlaşma altyapısı, projenizdeki çeşitli uç cihazları birbirine ve IronFlock bulut altyapısına bağlar.

Sıkı veri güvenliği ve izolasyonu sağlamak için yönlendirme kümesi semantik olarak güvenli realm’lere bölünmüştür. Realm’ler yalıtılmış alt ağlardır — mesajlar bunların içinde kesinlikle sınırlandırılır; yani veriler ve komutlar realm’leri asla terk etmez veya aşmaz.

Uç cihazlarda çalışan uygulamalar, bu mesajlaşma realm’lerinde ironflock-sdk kullanarak aşağıdaki yollardan biriyle iletişim kurabilir:

• Publish/Subscribe (Pub/Sub): sensör telemetrisini veya durum değişikliklerini sürekli yayınlamak için idealdir.
• Remote Procedure Calls (RPC): doğrudan eylem tetiklemek veya cihaz durumunu güvenli bir şekilde sorgulamak için mükemmeldir.

Dinamik olarak sağlanan proje veritabanları

Kalıcı depolama ve tarihsel analiz için IronFlock her proje için özel, fiziksel bir TimescaleDB veritabanı sağlar.

Bu proje veritabanı, projede kurulu her uygulama için merkezi bir veri toplama merkezi olarak görev yapar:

• Uygulama veri arka uçları: projenizde kurulu tüm uygulamaların veri arka uçları bu veritabanının içinde güvenli şekilde saklanır. İkinci bir uygulama kurduğunuzda, birincinin yanına kendi tablolarını ekler — birkaç uygulama çalıştıran bir proje, hepsinin verilerini tek bir yerde toplanmış ve birlikte sorgulanabilir halde bulur.
• Doğrudan veri alımı: cihaz uygulamaları ironflock-sdk ile veri yayınladığında, bu akışlar doğrudan proje veritabanına alınır ve düzenlenir.
• Onaya bağlı okuma erişimi: bir uygulama varsayılan olarak yalnızca kendi verilerini okur, ancak sizin onayınızla bir uygulama aynı projedeki başka bir uygulamanın verilerini de okuyabilir — böylece uygulamalar birbirlerinin okumaları üzerine inşa edilebilir. Bu paylaşımı siz kontrol eder ve istediğiniz zaman iptal edersiniz (aşağıya bakın).

Proje veritabanı operasyonlarınızın tek gerçek kaynağı olarak çalıştığı için gelişmiş yetenekleri açar:

• SQL sorguları: ham tarihsel tablolar üzerinde doğrudan güçlü sorgular yazın.
• Physical AI entegrasyonu: IronFlock AI ajanlarının verilerinizi doğal dilde çıkarmasına, analiz etmesine ve sorgulamasına izin verin.
• Görselleştirme kaynağı: proje veritabanı canlı panolar, IoT panoları ve SCADA panoları için nihai veri kaynağıdır.

Özel dönüşümler

Bir uygulamanın yazdığı tablolar, sormak istediğiniz sorunun biçiminde nadiren olur. Toplam ekipman etkinliği (OEE) kullanılabilirliği, performansı ve kaliteyi bir araya getirir; bir vardiya raporu saatlik aralıklar ister; iki makineyi karşılaştırmak, iki farklı uygulamanın tablolarını birleştirmek demektir. Bir özel dönüşüm böyle bir soruyu bir kez yanıtlar: bir ad altında kaydedilmiş bir SQL sorgusudur ve sonrasında projedeki diğer her tablo gibi davranır.

Dönüşüm oluşturmak bir uygulama geliştiricisi işi değildir. Veri Erişimi yetkisine sahip her proje üyesi — SQL sorgu konsolunu açan yetkinin ta kendisi — bir dönüşüm kaydedebilir; bir pano, hiçbir ham tabloda bulunmayan bir sayıya ihtiyaç duyduğunda IronFlock AI asistanı da istek üzerine bir dönüşüm oluşturabilir. Dönüşümler her uygulamanın dışında, projenin kendi IronFlock alanında yaşar; böylece tek bir dönüşüm, projede kurulu her uygulamanın tablolarını birlikte okuyabilir.

• Sorguyu bir kez yazın. Sorguyu projenin veri görünümündeki sorgu konsolunda geliştirin ve Dönüşüm olarak kaydet’i seçin ya da doğrudan oradaki Dönüşümler sekmesine gidin. Kaynak tablolara databackend_<key>.<table> biçiminde başvurulur — veri ağacının her uygulamanın yanında gösterdiği adlar.
• Nasıl hesaplanacağını seçin. Kalıcılaştırılmış bir dönüşüm sonucunu saklar ve belirlediğiniz bir zamanlamaya göre, en sık dakikada bir olmak üzere yeniden hesaplar. Sade bir görünüm ise her okumada hesaplanır: her zaman günceldir, ama yalnızca kendi sorgusu kadar hızlıdır.
• Ne döndürdüğünü açıklayın. Dönüşümün bir açıklaması vardır ve her sonuç sütunu da kendi görünen adını ve kendi açıklamasını taşır. Bunlar dönüşümle birlikte veritabanında saklanır; widget düzenleyicisinin gösterdiği ve AI asistanının okuduğu şey budur — iyi açıklanmış bir dönüşüm, asistanın aylar sonra bile doğru kullanabildiği dönüşümdür.
• Bir tablo gibi bağlayın. Dönüşüm, widget düzenleyicisinin veri seçicisinde IronFlock başlığı altında, her uygulamanın tablolarının yanında görünür ve aynı canlı kanalı besler: dönüşüm tazelendiğinde, ona bağlı panolar da tazelenir.

İyi davranan bir dönüşüm yazmak

Bir dönüşüm tam olarak kendi SQL’inin seçtiği satırları döndürür. Widget zaman pencereleri, takvim filtreleri ve latest modu tablolar için geçerlidir ve burada yok sayılır; bu da üç alışkanlığı edinmeye değer kılar:

• Zaman aralığını sorgunun içinde sınırlayın, örneğin WHERE tsp > now() - interval '7 days'. Tek bir okuma ayrıca 3000 satırla sınırlıdır; bu nedenle ham geçmişi seçmek yerine sorgunun içinde toplulaştırın.
• Bir zaman serisini en yeniden en eskiye sıralayın (ORDER BY <time column> DESC). Widget’lar satırları böylece eskiden yeniye alır ve bir satır sınırı devreye girdiğinde en yeni satırlar korunur.
• Çizmek veya filtrelemek istediğiniz her sütunu seçin. Bir dönüşümün gizli zaman damgası veya cihaz sütunları yoktur: bir widget yalnızca sorgunun gerçekten döndürdüğünü kullanabilir.

Bir dönüşüm çalışmayı bırakırsa — okuduğu bir uygulama kaldırılmış, kullandığı bir sütun kaybolmuşsa — Dönüşümler sekmesi nedenini gösterir ve diğer dönüşümler çalışmaya devam eder. Bir panoda bir dönüşümü okumak, herhangi bir uygulamanın verisiyle aynı erişim kurallarına tabidir; Veri Erişimi yalnızca kimin dönüşüm yazabileceğini belirler.

Uygulama geliştiricileri bunun yerine dönüşümleri veri şemalarında bildirerek uygulamayla birlikte de gönderebilir — bkz. Dönüşüm Tabloları. Her iki tür de aynı şekilde okunur.

Proje dosya deposu

Bir uygulamanın ürettiği her şey bir tabloya sığmaz. Proje veritabanının yanı sıra her proje, nesneler için özel bir dosya deposu edinir — kamera kareleri, PDF raporları, firmware görüntüleri, ses klipleri, dışa aktarımlar — ve bu depo, veritabanıyla tam olarak aynı ilkelerle yönetilir.

• Her uygulama otomatik olarak depolama alanı edinir. Bir uygulama kurulduğunda, IronFlock — uygulamanın veritabanı tablolarını sağladığı gibi — projenin dosya deposunda onun için özel bir depolama alanı sağlar. Birkaç uygulama dosyalarını tek bir proje deposunda toplar; her uygulamanın nesneleri diğerlerininkinden net biçimde ayrı tutulur.
• Aynı sahiplik garantileri geçerlidir. Dosyalar, uygulama geliştiricisine değil, proje sahibine aittir. Bunları göz atabilir, indirebilir, sınırlandırabilir ve silebilirsiniz; bir uygulamanın geliştiricisi, uygulamanın projenizde çalışırken topladığı dosyaları göremez.
• Dosyalar doğrudan verilerinize bağlanır. Depolanan bir nesne, bir uygulamanın bir veritabanı sütununa yazabileceği kalıcı, erişimi denetimli bir URL taşır — böylece bir pano widget’ı görüntüyü veya belgeyi hiçbir ek işlem gerektirmeden gösterir ve bir kullanıcının projeye erişimini iptal etmek, onun dosyaları getirme yeteneğini de iptal eder.
• Bütçeyi siz yönetirsiniz. Her uygulamanın depolama ayarları, ne kadar alan kullandığını gösterir ve bir depolama sınırı belirlemenize, bir tabloyu boşaltmanıza veya bir uygulamanın tüm dosyalarını silmenize olanak tanır. Platform dışındaki araçlar için de — DuckDB kullanan bir analist, gecelik bir yedekleme — tek bir uygulamanın dosyalarıyla sınırlı, salt okunur S3 kimlik bilgileri verebilirsiniz.

Dosya deposuna, tabloların hemen yanında göz atılabilir: projenin veri görünümü her uygulama için bir Dosyalar girişi gösterir ve depolanan her nesneyi boyutu, türü ve tarihiyle birlikte listeler. Geliştirici tarafındaki ayrıntılar için — depolama tanımlama, ad alanları, saklama ve SDK çağrıları — Dosya Depolama bölümüne bakın.

Uygulamalar arasında veri paylaşımı

Aynı projedeki uygulamalar varsayılan olarak birbirinden yalıtılmıştır: her biri yalnızca kendi tablolarını ve kendi dosyalarını okur ve yazar. Bu, güvenli bir başlangıç noktasıdır — enerji ölçmek için kurduğunuz bir uygulamanın, siz öyle karar vermedikçe başka bir uygulamanın denetim fotoğraflarını okumakla hiçbir işi yoktur.

Ancak uygulamaların çoğu zaman birlikte çalışması gerekir — bir analitik uygulamasının bir izleme uygulamasının geçmişini okuması, bir raporlama uygulamasının bir kalite uygulamasından fotoğraf çekmesi gibi. IronFlock bunu, tüketen uygulamanın ayarlarında, sizin kontrol ettiğiniz tek bir onay kararıyla mümkün kılar:

• Bir uygulamanın tam olarak hangi sağlayıcıları okuyabileceğini siz onaylarsınız ve uygulamanın erişim istemek için verdiği gerekçeyi görürsünüz. Açık onayınız olmadan hiçbir şey paylaşılmaz.
• Tek bir izin, paylaşımın her iki yarısını da kapsar — sağlayıcı uygulamanın paylaşılan tabloları ve paylaşılan dosyaları. Veritabanı ve dosya izinlerini ayrı ayrı yönetmezsiniz.
• Erişim salt okunurdur. Tüketen bir uygulama başka bir uygulamanın verilerine bakabilir, ancak asla değiştiremez veya silemez.
• İstediğiniz zaman iptal edebilirsiniz ve erişim anında sona erer.

Paylaşıma sunulanın ne olduğu ise uygulama geliştiricisinin kararıdır ve bu karar tablo başına ve dosya ad alanı başına verilir — bir uygulama bazı verileri tamamen dahili tutar ve bunlar hiçbir zaman izin verebileceğiniz bir şey olarak görünmez. Paylaşılabilir olanlar arasından, onu gerçekten paylaşıp paylaşmayacağınıza siz karar verirsiniz. Geliştirici tarafındaki mekanizmalar Diğer Uygulamalardan Veri Tüketme bölümünde belgelenmiştir.

Veri sahipliği ve AB Veri Yasası

IronFlock net bir ilke üzerine kuruludur: proje sahibi, verinin sahibidir — uygulama geliştiricisi değil.

Uygulamalar tarafından üretilen tüm veriler — uç cihazlardan gelen telemetri akışları, olay kayıtları, türetilmiş analizler — proje sahibine ait olan proje veritabanında saklanır. Uygulama geliştiricileri uygulamaları yazar, ancak o uygulamaların bir projede çalışırken ürettiği veriler onu barındıran projenin tek mülküdür.

Bu model, bağlı ürünlerin ve ilgili hizmetlerin kullanıcılarına cihazlarının ürettiği veriler üzerinde tam kontrol veren AB Veri Yasası (EU Data Act) gereksinimleriyle doğrudan örtüşür. IronFlock’ta:

• Özel kontrol. Proje sahipleri proje veritabanı üzerinde tam yönetimsel yetkiye sahiptir — içindeki tüm verileri okuyabilir, dışa aktarabilir, silebilir ve yedekleyebilirler.
• Sessiz veri toplama yok. Uygulama geliştiricileri, açıkça davet edilmediği sürece proje verilerine erişemez. Projeden uygulama geliştiricisine geri giden gizli bir veri hattı yoktur.
• Taşınabilirlik. Tüm veriler standart bir TimescaleDB örneğinde bulunur, bu nedenle SQL ile sorgulayabilir, açık biçimlerde dışa aktarabilir ve istediğiniz gibi taşıyabilirsiniz — proje sahipleri asla satıcı kilitlenmesine takılmaz.
• Ayrıntılı paylaşım. Proje sahipleri, uygulama geliştiricilerini, entegrasyon ortaklarını veya diğer paydaşları projeye davet edebilir ve belirli veri alanlarına ayrıntılı erişim izinleri verebilir. Bu sayede, üçüncü taraf teknik destek, uzaktan bakım veya uzmanlaşmış analitik hizmetlerinden, sahibin tanımladığı ve istediği zaman iptal edebileceği koşullar altında yararlanılabilir.

Özetle: uygulamalar veri üretir, ancak proje sahibi ona sahiptir, onu kontrol eder ve paylaşır. Bu sahiplik modeli, IronFlock platformunun birinci sınıf bir tasarım hedefidir, sonradan eklenmiş bir düşünce değildir.

Devre dışı bırakma: IronFlock veri hattını atlama

IronFlock’un mesajlaşma katmanı ve proje veritabanı önerilen yoldur — gerçek zamanlı yönlendirme, dayanıklı depolama, pano-hazır veri ve yerleşik sahiplik garantilerini kutudan çıkar çıkmaz sağlarlar. Ancak IronFlock, uygulamaları bu hattı kullanmaya zorlamaz.

IronFlock tarafından yönetilen cihazlarda çalışan uygulamalar sıradan konteyner iş yükleridir ve tam ağ ve sistem özgürlüğünü korur. Bir proje sahibi veya uygulama geliştiricisi farklı bir veri işleme yığınını tercih ederse, uygulama şunları yapabilir:

• Harici sistemlere gönderme. Verileri doğrudan üçüncü taraf brokerlara (MQTT, Kafka, AMQP), bulut veri alma uç noktalarına (AWS IoT, Azure IoT Hub, Google Cloud IoT) veya özel REST / gRPC API’lerine gönderir.
• Alternatif depolama kullanma. IronFlock proje veritabanı yerine veya yanında harici veritabanlarına (InfluxDB, MongoDB, S3, müşterinin kendi TimescaleDB’si vb.) yazar.
• Şirket içi sistemlerle köprü kurma. Yerel ağ üzerinden mevcut MES, ERP, historian veya SCADA sistemleriyle doğrudan entegre olur, IronFlock bulutundan geçmez.
• Karma kullanım. Panolar ve AI analitiği için verilerin bir alt kümesini IronFlock’a yayınlarken, tam doğrulukla verileri başka bir yere akıtır.

Bu esneklik, IronFlock’u hem kullanıcıların platformu uçtan uca benimsediği greenfield dağıtımları hem de veri hedeflerinin pazarlığa açık olmadığı mevcut kurumsal veri mimarilerine entegrasyon için uygun hale getirir.

Verileri IoT panolarında ve SCADA panolarında kullanma

Verileri görsel olarak kullanmak basittir. Bir IoT veya SCADA panosunda widget’ları yapılandırırken, bir widget’ın neredeyse her özelliği — başlığı, değerleri veya rengi gibi — proje veritabanınızdan gelen canlı verilere dinamik olarak bağlanabilir.

Board Studio’da bir widget’ı düzenlerken yapılandırma alanının altında bir veri bağlama anahtarı bulunur. Bir tablodan belirli bir sütun seçtiğinizde, o özellik için bir gerçek zamanlı kanal kurmuş olursunuz. Yeni telemetri verileri veritabanına ulaştığı anda, bağlı özellik otomatik olarak gerçek zamanlı güncellenir ve manuel UI yenilemesi gerekmez.

Not: widget özelliklerini veritabanına bağlamanın derinlemesine açıklaması için IoT panoları dokümantasyonundaki veri bağlama bölümüne bakın.