Bu çalışma, bina işletme ve bakımında kullanılan gerçek zamanlı dijital ikizlere sensör verisi taşıyan üç farklı IoT veri hattını aynı koşullarda karşılaştırmaktadır. Altı çevresel sensörden gelen sıcaklık, bağıl nem ve karbondioksit ölçümleri The Things Network üzerinden eş zamanlı biçimde TTN–AWS–Unity, TTN–Azure–Unity ve TTN–MQTT–Unity hatlarına aktarılmıştır. Bütün hatlar aynı sensörleri, LoRaWAN altyapısını, JSON veri yapısını, zaman damgasını, on dakikalık ölçüm aralığını ve aynı Unity tabanlı bina dijital ikizini kullanmıştır. Böylece karşılaştırmanın temel değişkeni yalnızca sensör ile Unity arasındaki veri bütünleştirme mimarisi olmuştur.

Kararlı telemetri koşullarında MQTT hattı en düşük güncelleme süresini ve en sade mimariyi sağlamıştır. Medyan güncelleme süresi MQTT için 0,9 saniye, AWS için 2,8 saniye ve Azure için 3,2 saniye olarak bildirilmiştir. Yüzde 95 gecikme değeri MQTT’de 1,5 saniye, AWS’de 4,6 saniye ve Azure’da 5,1 saniyedir. MQTT’nin doğrudan yayımla–abone ol mekanizması, verinin ara depolama ve API sorgusu olmadan Unity’ye iletilmesini sağlamıştır. AWS ve Azure hatları ise daha yüksek gecikme karşılığında kalıcı veri saklama, geçmiş kayıtları sorgulama, ayrıntılı günlükler ve daha güçlü sistem gözlemlenebilirliği sunmuştur.

Yaklaşık üç hafta boyunca sensör telemetrisinin tamamen kesildiği dönemde mimari farklılıkların uygulama katmanındaki etkisi ortadan kalkmıştır. Üç hattın tamamında Unity, son alınan değerleri göstermeyi sürdürmüş ancak bu değerler güncellenmemiştir. Araştırmacılar bu durumu “bayat durum” olarak tanımlamaktadır. Bulut tabanlı sistemlerde veritabanına yeni kayıt gelmemesi, sunucusuz işlevlerin çalışmaması ve günlüklerin durması kesintiyi arka planda görünür kılmıştır. MQTT hattında ise yeni mesajın gelmemesi, zaman damgası kontrolü veya heartbeat mekanizması bulunmadığında kullanıcı arayüzünde doğrudan bir hata sinyali üretmemiştir.

Çalışmanın temel sonucu, tek bir veri hattının bütün bina dijital ikizi uygulamaları için evrensel olarak en iyi olmadığıdır. Anlık görselleştirme ve düşük mimari karmaşıklık öncelikliyse MQTT öne çıkmaktadır. Geçmiş analiz, bakım denetimi, yasal kayıt, veri yönetişimi ve hata inceleme önemliyse AWS veya Azure benzeri kalıcı bulut hatları avantaj sağlamaktadır. Araştırmacılar, gerçek uygulamalarda MQTT tabanlı anlık iletimi bulut tabanlı depolama ve izlemeyle birleştiren hibrit mimarilerin daha uygun olabileceğini belirtmektedir.

Türkiye açısından önemi

Türkiye’de hastaneler, üniversite kampüsleri, kamu binaları, alışveriş merkezleri, oteller, fabrikalar ve veri merkezleri için geliştirilen dijital ikizlerde aynı mimari tercih sorunu bulunmaktadır. İç hava kalitesi veya enerji tüketiminin canlı izlenmesi için düşük gecikmeli MQTT akışı yararlı olabilirken bakım geçmişi, mevzuat kayıtları, enerji karşılaştırmaları ve arıza incelemeleri için kalıcı bulut depolaması gereklidir.

Türkiye’de kurulacak bir sistemde yalnız veri geldiğinde ne kadar hızlı görüntülendiği değil, veri gelmediğinde bunun kullanıcıya nasıl bildirildiği de tasarım ölçütü olmalıdır. Unity, web paneli veya bina yönetim sistemi üzerinde son güncelleme zamanı, veri yaşı, renkli bayat-veri uyarısı, sensör heartbeat sinyali ve zaman aşımı alarmı gösterilmelidir. Özellikle karbondioksit, sıcaklık, nem, basınç veya ekipman durumu gibi işletme kararlarını etkileyen değerlerin güncel olmadığı açıkça bildirilmeden dijital ikiz çıktıları güvenilir operasyon verisi olarak kullanılmamalıdır.

Çalışmanın sonuçları Türkiye’deki bütün bina ve ağ altyapılarına doğrudan genellenemez. Farklı LoRaWAN ağ geçitleri, mobil operatör bağlantıları, yerli IoT platformları, bina otomasyon protokolleri, çok daha fazla sensör, farklı veri üretim sıklıkları ve gerçek bakım senaryolarıyla yeniden doğrulama yapılması gerekir.

Araştırmanın temel problemi nedir?

Bir bina dijital ikizi yalnız üç boyutlu modelden oluşmaz. Dijital modelin fiziksel binanın güncel durumunu temsil edebilmesi için sensör ölçümlerinin sürekli biçimde dijital ortama ulaşması gerekir. Sıcaklık, nem, karbondioksit, enerji tüketimi veya cihaz durumu güncellenmediğinde üç boyutlu model görsel olarak çalışmaya devam edebilir; ancak fiziksel bina ile zamansal bağlantısını kaybeder.

Sensör ile dijital ikiz arasında genellikle birden fazla sistem katmanı bulunmaktadır:

• Fiziksel sensör ve ölçüm katmanı.
• LoRaWAN, Wi-Fi veya başka bir haberleşme katmanı.
• Cihaz kaydı, veri çözme ve yönlendirme sağlayan ağ yönetim katmanı.
• Bulut veya mesaj aracısı kullanan veri bütünleştirme katmanı.
• Unity gibi dijital ikiz uygulama katmanı.
• Tesis yöneticisinin kullandığı masaüstü, sanal gerçeklik veya karma gerçeklik arayüzü.

Çalışmanın araştırma boşluğu, dijital ikiz literatürünün çoğunlukla modelleme, BIM bütünleştirmesi, görselleştirme ve analitiğe odaklanması; sensör verisini uygulamaya taşıyan ara veri hattının davranışını ise ikincil bir uygulama tercihi olarak ele almasıdır. Araştırmacılar veri hattının gecikme, veri kalıcılığı, sistem karmaşıklığı, hata tanısı ve dijital ikizin güncelliği üzerinde doğrudan etkili olduğunu ileri sürmektedir.

Üç araştırma sorusu

1. Bulut merkezli ve akış tabanlı IoT veri hatlarını ayıran mimari özellikler nelerdir ve bu özellikler aynı dijital ikiz içindeki veri yayılımını nasıl etkiler?
2. Sistem kararlı telemetriden telemetri yokluğuna geçtiğinde entegrasyon mimarisinin etkisi nasıl değişir?
3. Gecikme, kalıcılık, gözlemlenebilirlik ve arıza şeffaflığı gibi ölçütler bina dijital ikizlerinde veri hattı seçimini nasıl yönlendirmelidir?

Bulut ve MQTT yaklaşımı arasındaki temel fark

Çalışmanın 2. sayfasındaki Şekil 1.1, sensör verisinin iki alternatif yoldan dijital ikize ulaşmasını göstermektedir. Bulut hattında veri sensörden bulut platformuna gönderilir, işlenir, kalıcı veri tabanında tutulur ve daha sonra API üzerinden Unity tarafından alınır. MQTT hattında sensör verisi bir mesaj aracısına yayımlanır ve Unity ilgili konuya abone olarak mesajı doğrudan alır.

Katmanlı bağımlılık modeli

11. sayfadaki Şekil 3.1, IoT destekli dijital ikizi altı katmanlı bir yapı olarak göstermektedir:

1. Fiziksel algılama katmanı: Sensörler zaman damgalı ölçümler üretir.
2. Haberleşme katmanı: LoRaWAN veya Wi-Fi üzerinden sinyal iletilir.
3. Ağ yönetim katmanı: Cihaz kaydı, payload çözme ve TTN yönlendirmesi yapılır.
4. Veri bütünleştirme katmanı: Bulut veya MQTT mimarisi veriyi uygulamaya hazırlar.
5. Uygulama katmanı: Unity, veriyi üç boyutlu bina modeline eşler.
6. Kullanıcı etkileşim katmanı: Tesis yöneticisi veriyi ekran, sanal gerçeklik veya karma gerçeklik arayüzünden görür.

Modelin temel önermesi dikey bağımlılıktır. Alt katmanların çalışması, üst katmanlardan gelen telemetrinin başarıyla iletilmesine bağlıdır. En gelişmiş Unity görselleştirmesi veya bulut altyapısı bile sensörün hiç üretmediği ya da TTN’ye ulaşmayan yeni bir veriyi yeniden oluşturamaz.

Yetenek rejimi ve bağımlılık rejimi

13. sayfadaki Şekil 3.2, çalışmanın iki operasyon rejimini göstermektedir.

Yetenek rejimi: Kararlı telemetri

Veri kesintisiz geldiğinde mimarilerin kendilerine özgü avantajları ortaya çıkar. Bulut tabanlı hatlar kalıcı veri, yönetişim ve geçmiş kayıt sunarken MQTT düşük gecikme, doğrudan güncelleme ve daha az ara bileşen sağlar.

Bağımlılık rejimi: Telemetri yokluğu

Üst katmandan yeni telemetri gelmediğinde uygulama katmanındaki davranışlar birbirine yaklaşır. Bütün hatlar son alınan değeri göstermeye devam eder. Bu aşamada değerlendirme sorusu “hangi hat daha hızlı?” olmaktan çıkar; “kesinti ne kadar açık görülüyor ve hangi katmanda teşhis edilebiliyor?” sorusuna dönüşür.

Arıza şeffaflığı nedir?

Araştırmacılar arıza şeffaflığını, telemetri yokluğunun veya bozulmasının günlükler, güncelleme davranışı, veri tabanı hareketleri veya kullanıcı arayüzü üzerinden ne kadar açık biçimde görülebildiği olarak tanımlamaktadır.

Arıza şeffaflığı, arıza toleransı veya toparlanma ile aynı değildir. Bir sistem telemetri akışını yeniden başlatamayabilir; ancak verinin güncel olmadığını açıkça belirterek kullanıcının eski değeri yeni değer sanmasını engelleyebilir.

Önerilen başlıca mekanizmalar şunlardır:

• Son başarılı veri alma zamanının gösterilmesi.
• Mevcut verinin yaşının saniye veya dakika cinsinden hesaplanması.
• Belirlenen süreden eski veriler için renkli uyarı verilmesi.
• Sensör veya veri hattı heartbeat mesajlarının izlenmesi.
• Yeni mesaj gelmediğinde zaman aşımı alarmı oluşturulması.
• Unity ekranında “güncel”, “gecikmiş” ve “bayat” durumlarının ayrılması.
• Bulut işlevi, veri tabanı, API ve MQTT bağlantı durumunun ayrı izlenmesi.

Saha kurulumu

Araştırma, Oxford Brookes University bünyesindeki New Headington Hill Building içinde seçilen bir araştırma odasında gerçekleştirilmiştir. 16. sayfadaki Şekil 4.1a binayı, Şekil 4.1b ise altı sensörün oda içindeki konumlarını göstermektedir. Sensörler tek bir noktada toplanmamış; odanın farklı bölgelerindeki iç ortam değişimini gözlemlemek amacıyla dağıtılmıştır.

Kontrollü karşılaştırma nasıl sağlandı?

Üç hattın tamamı aynı sensör verisini TTN’den eş zamanlı olarak almıştır. Sensörler, gönderim aralığı, ağ geçidi, TTN payload çözme işlemi, JSON alanları, zaman damgası ve Unity sahnesi değiştirilmemiştir. Böylece AWS, Azure ve MQTT arasında görülen farklılıkların veri bütünleştirme katmanından kaynaklandığı varsayılmıştır.

TTN alım zaman damgası, üç hat için ortak başlangıç zamanı olarak kullanılmıştır. Güncelleme süresi, mesajın TTN tarafından alınmasıyla ilgili değerin Unity’de görüntülenmesi arasındaki süre olarak tanımlanmıştır.

TTN–AWS–Unity mimarisi

24. sayfadaki Şekil 5.2, AWS hattını fiziksel sensörden Unity ekranına kadar katmanlar halinde göstermektedir:

1. Sensör LoRaWAN uplink mesajı gönderir.
2. Ağ geçidi mesajı TTN’ye iletir.
3. TTN veriyi webhook ile AWS API Gateway’e gönderir.
4. Lambda işlevi JSON verisini doğrular ve işler.
5. Veri DynamoDB içinde kalıcı olarak saklanır.
6. Unity ikinci bir API Gateway ve Lambda işlevi üzerinden son kayıtları sorgular.
7. C# betikleri değeri ilgili üç boyutlu sensör göstergesine yazar.

Bu yapı geçmiş kayıtları saklayabilmekte ve her aşamada iz bırakmaktadır. Buna karşılık iki API geçidi, işleme işlevleri, veri tabanı ve Unity sorgu katmanı daha fazla yapılandırma ve bağımlılık oluşturmaktadır.

TTN–Azure–Unity mimarisi

25. sayfadaki Şekil 5.3, Azure hattının benzer kalıcılık odaklı modeli farklı hizmetlerle uyguladığını göstermektedir:

1. TTN telemetriyi webhook ile Azure App Service içindeki alıcıya gönderir.
2. ASP.NET Core tabanlı bileşen veriyi işler.
3. Kayıt Azure veri tablosunda saklanır.
4. Unity, REST API üzerinden en yeni değerleri sorgular.
5. Unity C# betikleri üç boyutlu modeldeki sensör metinlerini günceller.

Çalışmada AWS ile Azure arasındaki temel mimari yaklaşımın aynı olduğu belirtilmektedir. Azure uygulamasının birden fazla hizmet arabirimi arasında koordinasyon gerektirmesi, incelenen kurulumda daha yüksek yapılandırma yükü oluşturmuştur. Bu sonuç genel bir Azure–AWS üstünlük sıralaması olarak sunulmamıştır.

TTN–MQTT–Unity mimarisi

27. sayfadaki Şekil 5.4, daha düz bir veri hattını göstermektedir:

1. Sensör mesajı LoRaWAN üzerinden TTN’ye ulaşır.
2. TTN mesajı MQTT sunucusuna yönlendirir.
3. Unity ilgili MQTT konusuna abone olur.
4. Mesaj yayımlandığında Unity içindeki MQTT yöneticisi JSON verisini işler.
5. Değer, bekleme veya API sorgusu olmadan ilgili görsele aktarılır.

Bu yapıda veri tabanı bulunmamaktadır. Mesaj alındığı anda işlenir; daha sonra tarihsel sorgu yapılması isteniyorsa ayrı bir depolama bileşeni eklenmelidir. Bağlantı kontrolü, yeniden bağlanma ve verinin güncelliğini belirleme sorumluluğu büyük ölçüde Unity uygulamasına taşınmaktadır.

Kararlı telemetri sonuçları

MQTT’nin AWS’ye göre medyan güncelleme süresi 1,9 saniye, Azure’a göre 2,3 saniye daha düşüktür. Bu fark yalnız protokol adından kaynaklanmamaktadır. MQTT hattında ara veri işleme, kalıcı depolama ve periyodik API sorgusu bulunmaması mimari yolu kısaltmıştır.

AWS ile Azure daha yavaş olmasına rağmen geçmiş değerlerin sorgulanması, veri akışının farklı aşamalarda incelenmesi, arızanın hangi katmanda oluştuğunun araştırılması ve bakım kayıtlarının korunması bakımından daha güçlüdür.

Üç haftalık telemetri kesintisinde ne oldu?

Kesinti döneminde TTN’ye sensör uplink mesajı ulaşmamıştır. Bunun sonucunda:

• AWS webhook’u yeni payload almamıştır.
• AWS Lambda işlevleri çalışmamış ve DynamoDB’ye yeni kayıt yazılmamıştır.
• Azure webhook ve işleme hizmetleri yeni veri almamıştır.
• Azure veri tablosunda yeni kayıt oluşmamıştır.
• MQTT broker yeni mesaj yayımlamamıştır.
• Unity’nin üç sürümü de son alınan değeri göstermeye devam etmiştir.

Bulut sistemlerinde son kayıt veri tabanında korunmuş, MQTT’de ise Unity belleğindeki son görüntülenmiş değer kalmıştır. Ancak üç durumda da gösterilen değer fiziksel ortamın yeni durumunu temsil etmemiştir.

Bayat durum neden tehlikelidir?

Üç boyutlu bina modeli çalışmaya devam ettiği ve ekran hata vermediği için kullanıcı sistemin güncel olduğunu düşünebilir. Örneğin bir derslikteki son CO₂ değeri kabul edilebilir düzeyde kalmış görünürken gerçek ortam havalandırma yetersizliği nedeniyle değişmiş olabilir. Tesis yöneticisi verinin üç saat veya üç gün önce alındığını bilmiyorsa yanlış havalandırma veya kullanım kararı verebilir.

Çalışma bu nedenle dijital ikiz güvenilirliğinin iki ayrı bileşeni olduğunu göstermektedir:

• Mekânsal doğruluk: Sensör ve bina elemanlarının doğru yerde gösterilmesi.
• Zamansal geçerlilik: Gösterilen değerin fiziksel ortamın güncel durumunu temsil etmesi.

Kesinti sırasında mimariler nasıl ayrışıyor?

Çalışmanın “toparlanma özellikleri” tablosu MQTT için veri yeniden başladığında hızlı devam, bulut için geçmiş sürekliliğin korunması ifadelerini kullanmaktadır. Ancak saniye cinsinden toparlanma süresi, kayıp mesajların telafisi veya bağlantı yeniden kurma sayısı ölçülmemiştir.

Hibrit mimari neden öneriliyor?

Bina dijital ikizlerinin çoğu hem anlık görüntü hem de geçmiş kayıt gerektirir. Bu nedenle yalnız MQTT veya yalnız bulut yerine iki hattı birlikte kullanan bir yapı düşünülebilir:

• MQTT canlı değeri düşük gecikmeyle Unity’ye gönderir.
• Aynı mesaj eş zamanlı olarak bulut veri tabanına kaydedilir.
• Unity, mesajın son geliş zamanını izler.
• Heartbeat kesildiğinde bayat durum uyarısı verir.
• Canlı bağlantı kesilirse kullanıcı geçmiş veriyi görebilir; ancak geçmiş değerin canlı olmadığı açıkça belirtilir.
• Bulut izleme araçları kesintinin sensör, TTN, işleme veya uygulama katmanında olup olmadığının araştırılmasını destekler.

Çalışmanın desteklediği sonuçlar

• Aynı sensör ve Unity koşullarında MQTT hattı, incelenen AWS ve Azure hatlarından daha düşük güncelleme süresi sağlamıştır.
• Bulut merkezli hatlar kalıcı depolama ve geçmiş sorgulama sağlamıştır.
• MQTT hattı daha az ara bileşenle kurulmuştur.
• Bulut hatları günlük, veri tabanı ve API kayıtları nedeniyle daha fazla teşhis noktası sunmuştur.
• Yeni telemetri gelmediğinde üç mimarinin tamamı Unity’de bayat duruma geçmiştir.
• Kalıcı depolama, yeni veri yokluğunu telafi etmemiş; yalnız son tarihsel durumu korumuştur.
• MQTT kullanan dijital ikizlerde güncellik ve zaman aşımı denetiminin uygulama katmanında ayrıca geliştirilmesi gerekmektedir.
• Veri hattı seçiminin yalnız gecikmeye göre değil, kalıcılık ve arıza şeffaflığına göre yapılması gerekir.

Çalışmanın kanıtlamadığı sonuçlar

• MQTT’nin bütün ağlarda ve bütün dijital ikiz uygulamalarında daima daha hızlı olduğu kanıtlanmamıştır.
• AWS veya Azure’un genel olarak diğerinden daha iyi olduğu gösterilmemiştir.
• Çalışma bağımsız bir AWS–Azure maliyet veya hizmet kalitesi benchmarkı değildir.
• On binlerce sensör bulunan büyük ölçekli sistemlerde performans ölçülmemiştir.
• Kısmi paket kaybı, düzensiz veri, gecikmeli telemetri veya tek sensör arızası ayrı ayrı test edilmemiştir.
• Üç haftalık kesintinin kök nedeni belirlenmemiştir.
• Kullanıcıların bayat veriyi nasıl yorumladığı bir tesis yöneticisi deneyiyle ölçülmemiştir.
• Arıza şeffaflığının güvenliği veya karar doğruluğunu ne ölçüde artırdığı nicel olarak gösterilmemiştir.
• Hibrit MQTT–bulut mimarisi bu çalışmada uygulanıp karşılaştırılmamıştır.
• Sonuçlar farklı ülkelerdeki bütün bina, sensör, ağ ve bulut yapılandırmalarına doğrudan genellenemez.

Çalışmanın Yöntemi ve Bulguları

Araştırma tasarımı

Beş değerlendirme boyutu

İstatistiksel analiz planı

Çalışma, 200.000’den fazla gözlem nedeniyle gecikme dağılımlarının parametrik olmayan yöntemlerle karşılaştırıldığını belirtmektedir:

• Üç hat için genel karşılaştırmada Kruskal–Wallis H testi.
• Hat çiftleri için Mann–Whitney U testi.
• Çoklu karşılaştırma için Bonferroni düzeltmesi ve \(\alpha=0{,}017\).
• Pratik etki büyüklüğü için sıra-çift serili korelasyon \(r\).
• Tanımlayıcı istatistik olarak medyan, IQR ve yüzde 95 gecikme.

Bununla birlikte sonuç tablolarında Kruskal–Wallis H değeri, serbestlik derecesi, Mann–Whitney U değerleri, düzeltilmiş p değerleri veya sıra-çift serili korelasyon sonuçları bulunmamaktadır. Dolayısıyla “istatistiksel olarak farklı” değerlendirmesi çalışmada belirtilen analiz planına göre bağımsız biçimde denetlenememektedir. Mevcut sayısal destek ağırlıklı olarak medyan, değişkenlik ve yüzde 95 gecikme değerlerine dayanmaktadır.

Raporlama tutarsızlıkları

• Tablo 3’teki değişkenlik değerleri ile izleyen paragraftaki IQR değerleri farklıdır.
• Tablo başlığı IQR ile güncelleme aralığı değişkenliğini aynı ölçü gibi göstermektedir.
• Bulut hattının 10 saniyelik sorgulama aralığı ile bildirilen yüzde 95 gecikmeler arasındaki ilişki açıklanmamıştır.
• Üç hatta “%1’den az veri kaybı” verilmiş ancak kesin payda, kayıp sayısı ve kaybın hangi katmanda oluştuğu belirtilmemiştir.
• Veri hacminin üç hatta aynı olduğu ifade edilirken kayıp oranlarının nasıl hesaplandığı ayrıntılandırılmamıştır.
• Arıza şeffaflığı “yüksek”, “orta” veya “düşük” biçiminde sınıflandırılmış ancak standart bir puanlama yöntemi sunulmamıştır.
• Toparlanma özellikleri nitel olarak açıklanmış, gerçek yeniden bağlanma veya toparlanma süreleri ölçülmemiştir.

Çalışmanın güçlü yönleri

• Üç mimarinin aynı sensör, TTN ve Unity koşullarında eş zamanlı çalıştırılması.
• Gerçek bina ve paylaşımlı kampüs iletişim altyapısının kullanılması.
• Yaklaşık on aylık uzunlamasına gözlem yapılması.
• 200.000’den fazla telemetri kaydının toplanması.
• Yalnız kararlı sistem davranışının değil, gerçek bir telemetri kesintisinin de incelenmesi.
• Gecikme dışında kalıcılık, mimari karmaşıklık ve gözlemlenebilirliğin karşılaştırılması.
• Dijital ikizlerde zamansal geçerlilik ve bayat durum riskinin görünür kılınması.
• Arıza şeffaflığının ayrı bir mimari değerlendirme boyutu olarak tanımlanması.

Temel sınırlılıklar

• Çalışma hakem değerlendirmesinden geçmemiştir.
• Tek bina ve tek oda kullanılmıştır.
• Yalnız altı sensör ve tek sensör modeli bulunmaktadır.
• Sensörler yalnız on dakikada bir veri üretmiştir; saniyelik yüksek frekanslı telemetri test edilmemiştir.
• Unity uygulaması ve bulut yapılandırmaları tek uygulama örneğiyle sınırlıdır.
• Ağ altyapısı kontrol amacıyla izole edilmemiştir.
• Kesinti kök nedeni belirlenmemiştir.
• Kontrollü paket kaybı, gecikme veya aralıklı bağlantı deneyleri yapılmamıştır.
• Maliyet, güvenlik, enerji ve ölçeklenebilirlik karşılaştırması bulunmamaktadır.
• İstatistiksel test sonuçları eksik raporlanmıştır.
• Veri ve analiz kodu için açık depo bağlantısı verilmemiştir.
• Arıza şeffaflığı gerçek tesis yöneticileriyle doğrulanmamıştır.
• Hibrit MQTT–bulut yaklaşımı yalnız gelecek çalışma önerisidir.

Türkiye’de uygulanmadan önce gerekli doğrulamalar

1. Farklı iklim bölgelerinde hastane, kampüs, fabrika ve ticari bina uygulamalarının kurulması.
2. Yüzlerce veya binlerce sensörle yük ve ölçeklenebilirlik testi yapılması.
3. LoRaWAN dışında Wi-Fi, NB-IoT, LTE-M ve kablolu bina otomasyon ağlarının karşılaştırılması.
4. MQTT canlı akışını bulut depolamayla birleştiren hibrit mimarinin uygulanması.
5. Kesinti, paket kaybı, gecikme ve sensör arızasının kontrollü olarak sisteme verilmesi.
6. Kesintiyi algılama ve toparlanma sürelerinin saniye cinsinden ölçülmesi.
7. Son güncelleme zamanı ve bayat durum uyarılarının tesis yöneticileriyle kullanıcı testinden geçirilmesi.
8. Bulut ve yerel sunucu maliyetlerinin toplam sahip olma maliyetiyle karşılaştırılması.
9. KVKK, erişim kontrolü, veri şifreleme ve cihaz kimlik doğrulamasının ayrıca değerlendirilmesi.
10. Ham veri, Unity kodu, zaman damgası işleme yöntemi ve istatistik betiklerinin paylaşılması.

Kaynak ve Yöntem Notu

Çalışmanın tam özgün adı: Evaluation of IoT Data Pipeline Architectures for Real-Time Digital Twins in Building Operations and Maintenance

Yazarlar: Muhammad Shahzad; Avar Almukhtar; Muhammad Younas; Joe Tah.

Yazar sıralaması: Muhammad Shahzad birinci, Avar Almukhtar ikinci, Muhammad Younas üçüncü ve Joe Tah dördüncü yazardır.

Yazar bilgisiyle ilgili belge notu: İncelenen sürümün ilk sayfasında yazar ve kurum bloğu bulunmamaktadır. Yazar sırası SSRN resmî kayıt bilgilerine göre verilmiştir. Dosya metadata’sında yalnız Muhammad Shahzad adı bulunmaktadır.

Eş birinci yazar: Eş katkı veya eş birinci yazar beyanı incelenen sürümde bulunmamaktadır.

Sorumlu yazar: SSRN resmî kaydı Muhammad Shahzad’ı “Contact Author” olarak göstermektedir. İncelenen metinde sorumlu yazar yıldızı veya iletişim e-posta adresi bulunmamaktadır.

Doğrulanabilen kurumsal bağlantılar:

• Muhammad Shahzad — School of the Built Environment, Oxford Brookes University, Birleşik Krallık.
• Avar Almukhtar — School of the Built Environment, Oxford Brookes University, Birleşik Krallık.
• Muhammad Younas — School of Engineering, Computing and Mathematics, Oxford Brookes University, Birleşik Krallık.
• Joe Tah — Professor of Project Management, Oxford Brookes University, Birleşik Krallık.

Kurum doğrulama sınırı: SSRN kaydında yazar kurumları verilmemiştir. Yukarıdaki bilgiler Oxford Brookes University’nin resmî güncel personel ve doktora öğrencisi profillerinden doğrulanmıştır; incelenen sürümde ayrı bir kurumsal eşleştirme tablosu bulunmamaktadır.

DOI:10.2139/ssrn.7193080

Dergi: Hakemli bir dergi adı incelenen sürümde yer almamaktadır.

Yayınevi: Kesinleşmiş nihai yayınevi bilgisi bulunmamaktadır. SSRN bir preprint platformudur ve bu çalışmanın nihai akademik yayınevi olarak değerlendirilmemelidir.

Yayın platformu: SSRN.

SSRN kayıt tarihi: 27 Temmuz 2026.

Yayın yılı: 2026.

Kaynak türü: Gerçek bina ortamında üç IoT veri hattını karşılaştıran uygulamalı mimari, yapı bilişimi ve tesis yönetimi araştırması preprinti.

Hakemlik durumu: Çalışma hakem değerlendirmesinden geçmemiştir. Her sayfada preprint ve hakemlik uyarısı yer almaktadır.

Resmî kaynak:SSRN resmî çalışma kaydı.

Etik onay: Çalışma bina sensörleri ve sistem telemetrisi üzerinde yürütülmüştür. Ayrı bir etik kurul veya etik onay numarası incelenen sürümde yer almamaktadır.

Finansman: Ayrı bir finansman beyanı incelenen sürümde yer almamaktadır.

Çıkar çatışması: Ayrı bir çıkar çatışması beyanı incelenen sürümde yer almamaktadır.

Veri ve kod erişimi: Ham telemetri kayıtları, AWS ve Azure yapılandırmaları, Unity kaynak kodu ve istatistiksel analiz betikleri için açık bir depo bağlantısı incelenen sürümde verilmemiştir.

Üretken yapay zekâ beyanı: Araştırmacılar kaynakları taramak amacıyla Google NotebookLM, yeniden ifade desteği amacıyla Paperpal kullandıklarını; üretilen içeriği gözden geçirip düzenlediklerini ve nihai sorumluluğu üstlendiklerini belirtmiştir.

Bu Türkçe açıklama, çalışmanın 51 sayfalık sürümü; metni, mimari diyagramları, bina ve sensör yerleşim görselleri, değerlendirme tabloları, istatistiksel analiz açıklamaları, kesinti bulguları ve kaynakçası incelenerek hazırlanmıştır. Bilimsel içeriğe çalışma dışında yeni bir performans sonucu eklenmemiştir. Dış kaynaklar yalnızca başlık, yazarlar, DOI, SSRN kayıt tarihi, yayın durumu ve güncel kurumsal bağlantıların bibliyografik doğrulanması amacıyla kullanılmıştır.

Çalışma MQTT’nin kararlı koşullarda daha hızlı olduğunu; AWS ve Azure’un ise veri kalıcılığı ve gözlemlenebilirlik avantajı sunduğunu göstermektedir. Bununla birlikte bütün hatlar yeni telemetri olmadığında bayat duruma geçmiştir. Sonuçlar, gerçek bina dijital ikizlerinde yalnız veri aktarım hızının değil, verinin artık güncel olmadığını açıkça gösterebilme yeteneğinin de temel tasarım gereksinimi olduğunu desteklemektedir.