Bu tədqiqat bina istismarı və texniki xidmətdə istifadə olunan real vaxtlı rəqəmsal əkizlərə sensor məlumatı daşıyan üç fərqli IoT məlumat xəttini eyni şəraitdə müqayisə edir. Altı ətraf mühit sensorundan gələn temperatur, nisbi rütubət və karbon dioksid ölçmələri The Things Network üzərindən eyni vaxtda TTN–AWS–Unity, TTN–Azure–Unity və TTN–MQTT–Unity xətlərinə ötürülüb. Bütün xətlər eyni sensorları, LoRaWAN infrastrukturunu, JSON məlumat quruluşunu, zaman damğasını, on dəqiqəlik ölçmə intervalını və eyni Unity əsaslı bina rəqəmsal əkizini istifadə edib. Beləliklə müqayisənin əsas dəyişəni yalnız sensor ilə Unity arasındakı məlumat inteqrasiya arxitekturası olub.

Sabit telemetri şəraitində MQTT xətti ən aşağı yenilənmə müddətini və ən sadə arxitekturanı təmin edib. Median yenilənmə müddəti MQTT üçün 0,9 saniyə, AWS üçün 2,8 saniyə və Azure üçün 3,2 saniyə kimi bildirilib. Yüzdə 95 gecikmə dəyəri MQTT-də 1,5 saniyə, AWS-də 4,6 saniyə və Azure-da 5,1 saniyədir. MQTT-nin birbaşa publish–subscribe mexanizmi məlumatın aralıq saxlama və API sorğusu olmadan Unity-yə ötürülməsinə imkan verib. AWS və Azure xətləri isə daha yüksək gecikmə qarşılığında davamlı məlumat saxlanması, keçmiş qeydlərin sorğulanması, ətraflı jurnallar və daha güclü sistem müşahidə oluna bilməsi təqdim edib.

Təxminən üç həftə ərzində sensor telemetriyasının tam kəsildiyi dövrdə arxitektura fərqlərinin tətbiq qatındakı təsiri aradan qalxıb. Hər üç xətdə Unity son alınan dəyərləri göstərməyə davam edib, lakin bu dəyərlər yenilənməyib. Tədqiqatçılar bu vəziyyəti “köhnəlmiş vəziyyət” kimi müəyyən edirlər. Bulud əsaslı sistemlərdə məlumat bazasına yeni qeyd gəlməməsi, serverless funksiyaların işləməməsi və jurnalların dayanması kəsintini arxa planda görünən edib. MQTT xəttində isə yeni mesaj gəlməməsi, zaman damğası yoxlaması və ya heartbeat mexanizmi olmadıqda istifadəçi interfeysində birbaşa xəta siqnalı yaratmayıb.

Tədqiqatın əsas nəticəsi tək bir məlumat xəttinin bütün bina rəqəmsal əkiz tətbiqləri üçün universal olaraq ən yaxşı olmadığıdır. Ani vizualizasiya və aşağı arxitektura mürəkkəbliyi prioritetdirsə MQTT önə çıxır. Tarixi analiz, texniki xidmət auditi, hüquqi qeyd, məlumat idarəçiliyi və xəta araşdırması vacibdirsə AWS və ya Azure kimi davamlı bulud xətləri üstünlük verir. Tədqiqatçılar real tətbiqlərdə MQTT əsaslı ani ötürməni bulud əsaslı saxlama və monitorinqlə birləşdirən hibrid arxitekturaların daha uyğun ola biləcəyini qeyd edir.

Türkiyə baxımından əhəmiyyəti

Türkiyədə xəstəxanalar, universitet kampusları, dövlət binaları, ticarət mərkəzləri, otellər, zavodlar və məlumat mərkəzləri üçün hazırlanmış rəqəmsal əkizlərdə eyni arxitektura seçimi problemi mövcuddur. Daxili hava keyfiyyəti və ya enerji istehlakının canlı izlənməsi üçün aşağı gecikməli MQTT axını faydalı ola bilər, texniki xidmət tarixçəsi, qayda qeydləri, enerji müqayisələri və nasazlıq araşdırmaları üçün isə davamlı bulud saxlaması tələb olunur.

Türkiyədə qurulacaq sistemdə yalnız məlumat gələndə nə qədər sürətli göstərildiyi deyil, məlumat gəlmədikdə bunun istifadəçiyə necə bildirildiyi də dizayn meyarı olmalıdır. Unity, veb panel və ya bina idarəetmə sistemində son yenilənmə vaxtı, məlumat yaşı, rəngli köhnəlmiş-məlumat xəbərdarlığı, sensor heartbeat siqnalı və timeout alarmı göstərilməlidir. Xüsusilə karbon dioksid, temperatur, rütubət, təzyiq və ya avadanlıq vəziyyəti kimi əməliyyat qərarlarına təsir edən dəyərlərin aktual olmadığı açıq göstərilmədən rəqəmsal əkiz çıxışları etibarlı əməliyyat məlumatı kimi istifadə edilməməlidir.

Tədqiqatın nəticələri Türkiyədəki bütün bina və şəbəkə infrastrukturlarına birbaşa ümumiləşdirilə bilməz. Müxtəlif LoRaWAN şlüzləri, mobil operator bağlantıları, yerli IoT platformaları, bina avtomatlaşdırma protokolları, daha çox sensor, fərqli məlumat generasiya tezlikləri və real texniki xidmət ssenariləri ilə yenidən doğrulama aparılmalıdır.

Tədqiqatın əsas problemi nədir?

Bina rəqəmsal əkizi yalnız üçölçülü modeldən ibarət deyil. Rəqəmsal modelin fiziki binanın aktual vəziyyətini təmsil edə bilməsi üçün sensor ölçmələri davamlı şəkildə rəqəmsal mühitə çatmalıdır. Temperatur, rütubət, karbon dioksid, enerji istehlakı və ya cihaz vəziyyəti yenilənmədikdə üçölçülü model vizual olaraq işləməyə davam edə bilər; lakin fiziki bina ilə zaman əlaqəsini itirir.

Sensor ilə rəqəmsal əkiz arasında adətən bir neçə sistem qatı mövcuddur:

• Fiziki sensor və ölçmə qatı.
• LoRaWAN, Wi-Fi və ya başqa rabitə qatı.
• Cihaz qeydiyyatı, məlumatın deşifrə edilməsi və yönləndirilməsini təmin edən şəbəkə idarəetmə qatı.
• Bulud və ya mesaj brokerindən istifadə edən məlumat inteqrasiya qatı.
• Unity kimi rəqəmsal əkiz tətbiq qatı.
• Obyekt menecerinin istifadə etdiyi masaüstü, virtual reallıq və ya qarışıq reallıq interfeysi.

Tədqiqatın araşdırma boşluğu rəqəmsal əkiz ədəbiyyatının əsasən modelləşdirmə, BIM inteqrasiyası, vizualizasiya və analitikaya fokuslanması, sensor məlumatını tətbiqə daşıyan aralıq məlumat xəttinin davranışını isə ikinci dərəcəli tətbiq seçimi kimi nəzərdən keçirməsidir. Tədqiqatçılar məlumat xəttinin gecikmə, məlumatın qalıcı saxlanması, sistem mürəkkəbliyi, nasazlıq diaqnostikası və rəqəmsal əkizin aktuallığına birbaşa təsir etdiyini irəli sürürlər.

Üç tədqiqat sualı

1. Bulud mərkəzli və axın əsaslı IoT məlumat xətlərini ayıran arxitektura xüsusiyyətləri hansılardır və bu xüsusiyyətlər eyni rəqəmsal əkiz daxilində məlumat yayılmasına necə təsir edir?
2. Sistem sabit telemetriyadan telemetri yoxluğuna keçəndə inteqrasiya arxitekturasının təsiri necə dəyişir?
3. Gecikmə, qalıcı saxlanma, müşahidə oluna bilmə və nasazlıq şəffaflığı kimi meyarlar bina rəqəmsal əkizlərində məlumat xətti seçimini necə yönləndirməlidir?

Bulud və MQTT yanaşması arasındakı əsas fərq

Tədqiqatın 2. səhifəsindəki Şəkil 1.1 sensor məlumatının iki alternativ yolla rəqəmsal əkizə çatmasını göstərir. Bulud xəttində məlumat sensordan bulud platformasına göndərilir, işlənir, qalıcı məlumat bazasında saxlanılır və daha sonra API üzərindən Unity tərəfindən götürülür. MQTT xəttində sensor məlumatı mesaj brokerinə yayımlanır və Unity müvafiq mövzuya abunə olaraq mesajı birbaşa qəbul edir.

Qatlı asılılıq modeli

11. səhifədəki Şəkil 3.1 IoT dəstəkli rəqəmsal əkizi altı qatlı struktur kimi göstərir:

1. Fiziki hiss etmə qatı: Sensorlar zaman damğalı ölçmələr yaradır.
2. Rabitə qatı: Siqnal LoRaWAN və ya Wi-Fi üzərindən ötürülür.
3. Şəbəkə idarəetmə qatı: Cihaz qeydiyyatı, payload deşifrə və TTN yönləndirməsi edilir.
4. Məlumat inteqrasiya qatı: Bulud və ya MQTT arxitekturası məlumatı tətbiq üçün hazırlayır.
5. Tətbiq qatı: Unity məlumatı üçölçülü bina modelinə xəritələndirir.
6. İstifadəçi qarşılıqlı əlaqə qatı: Obyekt meneceri məlumatı ekran, virtual reallıq və ya qarışıq reallıq interfeysində görür.

Modelin əsas müddəası şaquli asılılıqdır. Aşağı qatların işləməsi yuxarı qatlara gələn telemetriyanın uğurla ötürülməsindən asılıdır. Ən inkişaf etmiş Unity vizualizasiyası və ya bulud infrastrukturu belə sensorun heç yaratmadığı və ya TTN-yə çatmayan yeni məlumatı yenidən yarada bilməz.

Qabiliyyət rejimi və asılılıq rejimi

13. səhifədəki Şəkil 3.2 tədqiqatın iki əməliyyat rejimini göstərir.

Qabiliyyət rejimi: Sabit telemetri

Məlumat fasiləsiz gəldikdə arxitekturaların özünəməxsus üstünlükləri ortaya çıxır. Bulud əsaslı xətlər qalıcı məlumat, idarəçilik və tarixi qeyd təqdim edir, MQTT isə aşağı gecikmə, birbaşa yenilənmə və daha az aralıq komponent təmin edir.

Asılılıq rejimi: Telemetri yoxluğu

Yuxarı qatdan yeni telemetri gəlmədikdə tətbiq qatındakı davranışlar bir-birinə yaxınlaşır. Bütün xətlər son alınan dəyəri göstərməyə davam edir. Bu mərhələdə qiymətləndirmə sualı “hansı xətt daha sürətlidir?” olmaqdan çıxır; “kəsinti nə qədər açıq görünür və hansı qatda diaqnostika edilə bilir?” sualına çevrilir.

Nasazlıq şəffaflığı nədir?

Tədqiqatçılar nasazlıq şəffaflığını telemetri yoxluğunun və ya pozulmasının jurnallar, yenilənmə davranışı, məlumat bazası hərəkətləri və ya istifadəçi interfeysi üzərindən nə qədər açıq görünə bilməsi kimi müəyyən edirlər.

Nasazlıq şəffaflığı nasazlığa dözümlülük və ya bərpa ilə eyni deyil. Sistem telemetri axınını yenidən başlada bilməyə bilər; lakin məlumatın aktual olmadığını açıq göstərərək istifadəçinin köhnə dəyəri yeni dəyər hesab etməsinin qarşısını ala bilər.

Təklif olunan əsas mexanizmlər bunlardır:

• Son uğurlu məlumat qəbul vaxtının göstərilməsi.
• Mövcud məlumatın yaşının saniyə və ya dəqiqə ilə hesablanması.
• Müəyyən müddətdən köhnə məlumat üçün rəngli xəbərdarlıq verilməsi.
• Sensor və ya məlumat xətti heartbeat mesajlarının izlənməsi.
• Yeni mesaj gəlmədikdə timeout alarmının yaradılması.
• Unity ekranında “aktual”, “gecikmiş” və “köhnəlmiş” vəziyyətlərinin ayrılması.
• Bulud funksiyası, məlumat bazası, API və MQTT bağlantı vəziyyətinin ayrıca izlənməsi.

Sahə quruluşu

Tədqiqat Oxford Brookes University-dəki New Headington Hill Building daxilində seçilmiş tədqiqat otağında aparılıb. 16. səhifədəki Şəkil 4.1a binanı, Şəkil 4.1b isə altı sensorun otaqdakı yerləşməsini göstərir. Sensorlar tək nöqtədə toplanmayıb; otağın müxtəlif sahələrində daxili mühit dəyişimini izləmək üçün paylanıb.

Nəzarətli müqayisə necə təmin edilib?

Üç xəttin hamısı eyni sensor məlumatını TTN-dən eyni vaxtda qəbul edib. Sensorlar, göndərmə intervalı, şlüz, TTN payload deşifrə əməliyyatı, JSON sahələri, zaman damğası və Unity səhnəsi dəyişdirilməyib. Beləliklə AWS, Azure və MQTT arasında müşahidə olunan fərqlərin məlumat inteqrasiya qatından qaynaqlandığı qəbul edilib.

TTN qəbul zaman damğası üç xətt üçün ortaq başlanğıc vaxtı kimi istifadə olunub. Yenilənmə müddəti mesajın TTN tərəfindən qəbul edilməsi ilə müvafiq dəyərin Unity-də göstərilməsi arasındakı müddət kimi müəyyən edilib.

TTN–AWS–Unity arxitekturası

24. səhifədəki Şəkil 5.2 AWS xəttini fiziki sensordan Unity ekranına qədər qatlar şəklində göstərir:

1. Sensor LoRaWAN uplink mesajı göndərir.
2. Şlüz mesajı TTN-yə ötürür.
3. TTN məlumatı webhook ilə AWS API Gateway-ə göndərir.
4. Lambda funksiyası JSON məlumatını doğrulayır və işləyir.
5. Məlumat DynamoDB daxilində qalıcı saxlanılır.
6. Unity ikinci API Gateway və Lambda funksiyası üzərindən son qeydləri sorğulayır.
7. C# skriptləri dəyəri müvafiq üçölçülü sensor göstəricisinə yazır.

Bu quruluş tarixi qeydləri saxlaya bilir və hər mərhələdə iz buraxır. Bunun əvəzində iki API keçidi, emal funksiyaları, məlumat bazası və Unity sorğu qatı daha çox konfiqurasiya və asılılıq yaradır.

TTN–Azure–Unity arxitekturası

25. səhifədəki Şəkil 5.3 Azure xəttinin oxşar qalıcı saxlama yönümlü modeli fərqli xidmətlərlə tətbiq etdiyini göstərir:

1. TTN telemetriyanı webhook ilə Azure App Service daxilindəki qəbul edən komponentə göndərir.
2. ASP.NET Core əsaslı komponent məlumatı işləyir.
3. Qeyd Azure məlumat cədvəlində saxlanılır.
4. Unity REST API üzərindən ən yeni dəyərləri sorğulayır.
5. Unity C# skriptləri üçölçülü modeldəki sensor mətnlərini yeniləyir.

Tədqiqatda AWS ilə Azure arasındakı əsas arxitektura yanaşmasının eyni olduğu qeyd edilir. Azure tətbiqinin bir neçə xidmət interfeysi arasında koordinasiya tələb etməsi araşdırılan quruluşda daha yüksək konfiqurasiya yükü yaradıb. Bu nəticə ümumi Azure–AWS üstünlük sıralaması kimi təqdim edilməyib.

TTN–MQTT–Unity arxitekturası

27. səhifədəki Şəkil 5.4 daha düz məlumat xəttini göstərir:

1. Sensor mesajı LoRaWAN üzərindən TTN-yə çatır.
2. TTN mesajı MQTT serverinə yönləndirir.
3. Unity müvafiq MQTT mövzusuna abunə olur.
4. Mesaj yayımlandıqda Unity daxilindəki MQTT meneceri JSON məlumatını işləyir.
5. Dəyər gözləmə və ya API sorğusu olmadan müvafiq vizuala ötürülür.

Bu quruluşda məlumat bazası yoxdur. Mesaj alındığı anda işlənir; daha sonra tarixi sorğulama tələb olunarsa ayrıca saxlama komponenti əlavə edilməlidir. Bağlantı nəzarəti, yenidən qoşulma və məlumatın aktuallığını müəyyən etmə məsuliyyəti əsasən Unity tətbiqinə keçir.

Sabit telemetri nəticələri

MQTT-nin AWS-yə görə median yenilənmə müddəti 1,9 saniyə, Azure-a görə 2,3 saniyə daha aşağıdır. Bu fərq yalnız protokol adından qaynaqlanmır. MQTT xəttində aralıq məlumat emalı, qalıcı saxlama və periodik API sorğusunun olmaması arxitektura yolunu qısaldıb.

AWS və Azure daha yavaş olsa da keçmiş dəyərlərin sorğulanması, məlumat axınının müxtəlif mərhələlərdə araşdırılması, nasazlığın hansı qatda baş verdiyinin öyrənilməsi və texniki xidmət qeydlərinin qorunması baxımından daha güclüdür.

Üç həftəlik telemetri kəsintisində nə baş verdi?

Kəsinti dövründə TTN-yə sensor uplink mesajı çatmayıb. Bunun nəticəsində:

• AWS webhook-u yeni payload qəbul etməyib.
• AWS Lambda funksiyaları işləməyib və DynamoDB-yə yeni qeyd yazılmayıb.
• Azure webhook və emal xidmətləri yeni məlumat qəbul etməyib.
• Azure məlumat cədvəlində yeni qeyd yaranmayıb.
• MQTT broker yeni mesaj yayımlamayıb.
• Unity-nin üç versiyası da son alınan dəyəri göstərməyə davam edib.

Bulud sistemlərində son qeyd məlumat bazasında qorunub, MQTT-də isə Unity yaddaşındakı son göstərilən dəyər qalıb. Lakin hər üç halda göstərilən dəyər fiziki mühitin yeni vəziyyətini təmsil etməyib.

Köhnəlmiş vəziyyət niyə təhlükəlidir?

Üçölçülü bina modeli işləməyə davam etdiyi və ekran xəta vermədiyi üçün istifadəçi sistemin aktual olduğunu düşünə bilər. Məsələn, sinif otağındakı son CO₂ dəyəri qəbul edilə bilən səviyyədə qalmış kimi görünə bilər, halbuki real mühit zəif ventilyasiya səbəbindən dəyişmiş ola bilər. Obyekt meneceri məlumatın üç saat və ya üç gün əvvəl alındığını bilmirsə səhv ventilyasiya və ya istifadə qərarı verə bilər.

Tədqiqat buna görə rəqəmsal əkiz etibarlılığının iki ayrı komponenti olduğunu göstərir:

• Məkan dəqiqliyi: Sensor və bina elementlərinin düzgün yerdə göstərilməsi.
• Zaman etibarlılığı: Göstərilən dəyərin fiziki mühitin aktual vəziyyətini təmsil etməsi.

Kəsinti zamanı arxitekturalar necə fərqlənir?

Tədqiqatın “bərpa xüsusiyyətləri” cədvəli MQTT üçün məlumat yenidən başlayanda sürətli davam etmə, bulud üçün isə tarixi davamlılığın qorunması ifadələrini istifadə edir. Lakin saniyə ilə bərpa müddəti, itmiş mesajların kompensasiyası və ya yenidən qoşulma sayı ölçülməyib.

Hibrid arxitektura niyə təklif olunur?

Bina rəqəmsal əkizlərinin çoxu həm ani görüntü, həm də tarixi qeyd tələb edir. Buna görə yalnız MQTT və ya yalnız bulud əvəzinə iki xətti birlikdə istifadə edən quruluş düşünülə bilər:

• MQTT canlı dəyəri aşağı gecikmə ilə Unity-yə göndərir.
• Eyni mesaj eyni vaxtda bulud məlumat bazasına yazılır.
• Unity mesajın son gəlmə vaxtını izləyir.
• Heartbeat kəsiləndə köhnəlmiş vəziyyət xəbərdarlığı verir.
• Canlı bağlantı kəsilərsə istifadəçi tarixi məlumatı görə bilər; lakin tarixi dəyərin canlı olmadığı açıq göstərilir.
• Bulud monitorinq alətləri kəsintinin sensor, TTN, emal və ya tətbiq qatında olub-olmadığını araşdırmağa kömək edir.

Tədqiqatın dəstəklədiyi nəticələr

• Eyni sensor və Unity şəraitində MQTT xətti araşdırılan AWS və Azure xətlərindən daha aşağı yenilənmə müddəti təmin edib.
• Bulud mərkəzli xətlər qalıcı saxlama və tarixi sorğulama təmin edib.
• MQTT xətti daha az aralıq komponentlə qurulub.
• Bulud xətləri jurnal, məlumat bazası və API qeydləri səbəbindən daha çox diaqnostika nöqtəsi təqdim edib.
• Yeni telemetri gəlmədikdə hər üç arxitektura Unity-də köhnəlmiş vəziyyətə keçib.
• Qalıcı saxlama yeni məlumat yoxluğunu kompensasiya etməyib; yalnız son tarixi vəziyyəti qoruyub.
• MQTT istifadə edən rəqəmsal əkizlərdə aktuallıq və timeout yoxlamasının tətbiq qatında ayrıca hazırlanması tələb olunur.
• Məlumat xətti seçimi yalnız gecikməyə deyil, qalıcı saxlama və nasazlıq şəffaflığına görə aparılmalıdır.

Tədqiqatın sübut etmədiyi nəticələr

• MQTT-nin bütün şəbəkələrdə və bütün rəqəmsal əkiz tətbiqlərində həmişə daha sürətli olduğu sübut edilməyib.
• AWS və ya Azure-un ümumilikdə digərindən daha yaxşı olduğu göstərilməyib.
• Tədqiqat müstəqil AWS–Azure xərc və ya xidmət keyfiyyəti benchmarkı deyil.
• On minlərlə sensor olan böyük miqyaslı sistemlərdə performans ölçülməyib.
• Qismən paket itkisi, nizamsız məlumat, gecikmiş telemetri və ya tək sensor nasazlığı ayrıca sınaqdan keçirilməyib.
• Üç həftəlik kəsintinin kök səbəbi müəyyən edilməyib.
• İstifadəçilərin köhnəlmiş məlumatı necə şərh etdiyi obyekt meneceri sınağı ilə ölçülməyib.
• Nasazlıq şəffaflığının təhlükəsizliyi və ya qərar dəqiqliyini nə dərəcədə artırdığı kəmiyyətcə göstərilməyib.
• Hibrid MQTT–bulud arxitekturası bu tədqiqatda tətbiq edilib müqayisə olunmayıb.
• Nəticələr müxtəlif ölkələrdəki bütün bina, sensor, şəbəkə və bulud konfiqurasiyalarına birbaşa ümumiləşdirilə bilməz.

Tədqiqatın Metodu və Tapıntıları

Tədqiqat dizaynı

Beş qiymətləndirmə ölçüsü

Statistik analiz planı

Tədqiqat 200.000-dən çox müşahidə olduğuna görə gecikmə paylanmalarının qeyri-parametrik üsullarla müqayisə edildiyini bildirir:

• Üç xəttin ümumi müqayisəsi üçün Kruskal–Wallis H testi.
• Xətt cütləri üçün Mann–Whitney U testi.
• Çoxsaylı müqayisə üçün Bonferroni düzəlişi və \(\alpha=0{,}017\).
• Praktik təsir ölçüsü üçün rank-biserial korrelyasiya \(r\).
• Təsviri statistika kimi median, IQR və yüzdə 95 gecikmə.

Bununla belə nəticə cədvəllərində Kruskal–Wallis H dəyəri, sərbəstlik dərəcəsi, Mann–Whitney U dəyərləri, düzəldilmiş p dəyərləri və ya rank-biserial korrelyasiya nəticələri yoxdur. Buna görə “statistik olaraq fərqli” qiymətləndirməsi tədqiqatda göstərilən analiz planına əsasən müstəqil yoxlana bilmir. Mövcud sayısal dəstək əsasən median, dəyişkənlik və yüzdə 95 gecikmə dəyərlərinə əsaslanır.

Hesabat uyğunsuzluqları

• Cədvəl 3-dəki dəyişkənlik dəyərləri ilə sonrakı paraqrafdakı IQR dəyərləri fərqlidir.
• Cədvəl başlığı IQR ilə yenilənmə intervalı dəyişkənliyini eyni meyar kimi göstərir.
• Bulud xəttinin 10 saniyəlik sorğulama intervalı ilə bildirilən yüzdə 95 gecikmələr arasındakı əlaqə izah olunmayıb.
• Üç xətt üçün “%1-dən az məlumat itkisi” verilib, lakin dəqiq məxrəc, itki sayı və itkinin hansı qatda baş verdiyi göstərilməyib.
• Məlumat həcminin üç xətdə eyni olduğu bildirilsə də itki nisbətlərinin necə hesablandığı ətraflı verilməyib.
• Nasazlıq şəffaflığı “yüksək”, “orta” və ya “aşağı” kimi təsnif olunub, lakin standart balvermə üsulu təqdim edilməyib.
• Bərpa xüsusiyyətləri keyfiyyətcə izah olunub, real yenidən qoşulma və ya bərpa müddətləri ölçülməyib.

Tədqiqatın güclü tərəfləri

• Üç arxitekturanın eyni sensor, TTN və Unity şəraitində eyni vaxtda işlədilməsi.
• Real bina və paylaşılan kampus rabitə infrastrukturundan istifadə.
• Təxminən on aylıq uzunmüddətli müşahidə aparılması.
• 200.000-dən çox telemetri qeydinin toplanması.
• Yalnız sabit sistem davranışının deyil, real telemetri kəsintisinin də araşdırılması.
• Gecikmədən əlavə qalıcı saxlama, arxitektura mürəkkəbliyi və müşahidə oluna bilmənin müqayisəsi.
• Rəqəmsal əkizlərdə zaman etibarlılığı və köhnəlmiş vəziyyət riskinin görünən edilməsi.
• Nasazlıq şəffaflığının ayrıca arxitektura qiymətləndirmə ölçüsü kimi müəyyən edilməsi.

Əsas məhdudiyyətlər

• Tədqiqat resenziyadan keçməyib.
• Tək bina və tək otaq istifadə olunub.
• Yalnız altı sensor və tək sensor modeli var.
• Sensorlar yalnız on dəqiqədə bir məlumat yaradıb; saniyəlik yüksək tezlikli telemetri sınaqdan keçirilməyib.
• Unity tətbiqi və bulud konfiqurasiyaları tək tətbiq nümunəsi ilə məhduddur.
• Şəbəkə infrastrukturu nəzarət məqsədilə izolyasiya edilməyib.
• Kəsintinin kök səbəbi müəyyən edilməyib.
• Nəzarətli paket itkisi, gecikmə və ya fasiləli bağlantı sınaqları aparılmayıb.
• Xərc, təhlükəsizlik, enerji və miqyaslana bilmə müqayisəsi yoxdur.
• Statistik test nəticələri natamam hesabatlandırılıb.
• Məlumat və analiz kodu üçün açıq depo keçidi verilməyib.
• Nasazlıq şəffaflığı real obyekt menecerləri ilə doğrulanmayıb.
• Hibrid MQTT–bulud yanaşması yalnız gələcək tədqiqat təklifidir.

Türkiyədə tətbiqdən əvvəl tələb olunan doğrulamalar

1. Müxtəlif iqlim zonalarında xəstəxana, kampus, zavod və kommersiya binası tətbiqlərinin qurulması.
2. Yüzlərlə və ya minlərlə sensorla yük və miqyaslana bilmə testinin aparılması.
3. LoRaWAN-dan əlavə Wi-Fi, NB-IoT, LTE-M və kabel bina avtomatlaşdırma şəbəkələrinin müqayisəsi.
4. MQTT canlı axınını bulud saxlama ilə birləşdirən hibrid arxitekturanın tətbiqi.
5. Kəsinti, paket itkisi, gecikmə və sensor nasazlığının nəzarətli şəkildə sistemə verilməsi.
6. Kəsintini aşkarlama və bərpa müddətlərinin saniyə ilə ölçülməsi.
7. Son yenilənmə vaxtı və köhnəlmiş vəziyyət xəbərdarlıqlarının obyekt menecerləri ilə istifadəçi testindən keçirilməsi.
8. Bulud və yerli server xərclərinin ümumi sahibolma xərci ilə müqayisəsi.
9. KVKK, giriş nəzarəti, məlumat şifrələmə və cihaz identifikasiyasının ayrıca qiymətləndirilməsi.
10. Xam məlumat, Unity kodu, zaman damğası emal üsulu və statistik skriptlərin paylaşılması.

Mənbə və Metod Qeydi

Tədqiqatın tam orijinal adı: Evaluation of IoT Data Pipeline Architectures for Real-Time Digital Twins in Building Operations and Maintenance

Müəlliflər: Muhammad Shahzad; Avar Almukhtar; Muhammad Younas; Joe Tah.

Müəllif sıralaması: Muhammad Shahzad birinci, Avar Almukhtar ikinci, Muhammad Younas üçüncü və Joe Tah dördüncü müəllifdir.

Müəllif məlumatı ilə bağlı sənəd qeydi: Araşdırılan versiyanın ilk səhifəsində müəllif və qurum bloku yoxdur. Müəllif sırası SSRN rəsmi qeyd məlumatına əsasən verilib. Fayl metadatasında yalnız Muhammad Shahzad adı var.

Bərabər birinci müəllif: Bərabər töhfə və ya bərabər birinci müəllif bəyanı araşdırılan versiyada yoxdur.

Məsul müəllif: SSRN rəsmi qeydi Muhammad Shahzad-ı “Contact Author” kimi göstərir. Araşdırılan mətndə məsul müəllif ulduzu və ya əlaqə e-poçt ünvanı yoxdur.

Doğrulana bilən qurum əlaqələri:

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

Qurum doğrulama sərhədi: SSRN qeydində müəllif qurumları verilməyib. Yuxarıdakı məlumatlar Oxford Brookes University-nin rəsmi aktual əməkdaş və doktorant profillərindən doğrulanıb; araşdırılan versiyada ayrıca qurum uyğunlaşdırma cədvəli yoxdur.

DOI:10.2139/ssrn.7193080

Jurnal: Resenziyalı jurnal adı araşdırılan versiyada yoxdur.

Nəşriyyat: Qəti yekun nəşriyyat məlumatı yoxdur. SSRN preprint platformasıdır və bu tədqiqatın yekun akademik nəşriyyatı kimi qiymətləndirilməməlidir.

Nəşr platforması: SSRN.

SSRN qeyd tarixi: 27 İyul 2026.

Nəşr ili: 2026.

Mənbə növü: Real bina mühitində üç IoT məlumat xəttini müqayisə edən tətbiqi arxitektura, bina informatika və obyekt idarəetməsi tədqiqatı preprinti.

Resenziya statusu: Tədqiqat resenziyadan keçməyib. Hər səhifədə preprint və resenziya xəbərdarlığı var.

Rəsmi mənbə:SSRN rəsmi tədqiqat qeydi.

Etik təsdiq: Tədqiqat bina sensorları və sistem telemetriyası üzərində aparılıb. Ayrıca etik komitə və ya etik təsdiq nömrəsi araşdırılan versiyada yoxdur.

Maliyyələşdirmə: Ayrıca maliyyələşdirmə bəyanı araşdırılan versiyada yoxdur.

Maraqlar toqquşması: Ayrıca maraqlar toqquşması bəyanı araşdırılan versiyada yoxdur.

Məlumat və koda çıxış: Xam telemetri qeydləri, AWS və Azure konfiqurasiyaları, Unity mənbə kodu və statistik analiz skriptləri üçün açıq depo keçidi araşdırılan versiyada verilməyib.

Generativ süni intellekt bəyanı: Tədqiqatçılar mənbələri araşdırmaq üçün Google NotebookLM, yenidən ifadə dəstəyi üçün Paperpal istifadə etdiklərini; yaradılan məzmunu nəzərdən keçirib redaktə etdiklərini və son məsuliyyəti daşıdıqlarını bildiriblər.

Bu Azərbaycan dilində izah tədqiqatın 51 səhifəlik versiyasının mətni, arxitektura diaqramları, bina və sensor yerləşmə görüntüləri, qiymətləndirmə cədvəlləri, statistik analiz izahları, kəsinti tapıntıları və biblioqrafiyası araşdırılaraq hazırlanıb. Elmi məzmuna tədqiqatdan kənar yeni performans nəticəsi əlavə edilməyib. Xarici mənbələr yalnız başlıq, müəlliflər, DOI, SSRN qeyd tarixi, nəşr statusu və aktual qurum əlaqələrinin biblioqrafik doğrulanması məqsədilə istifadə olunub.

Tədqiqat MQTT-nin sabit şəraitdə daha sürətli olduğunu, AWS və Azure-un isə məlumatın qalıcı saxlanması və müşahidə oluna bilmə üstünlüyü verdiyini göstərir. Bununla belə bütün xətlər yeni telemetri olmadıqda köhnəlmiş vəziyyətə keçib. Nəticələr real bina rəqəmsal əkizlərində yalnız məlumat ötürmə sürətinin deyil, məlumatın artıq aktual olmadığını açıq göstərə bilmə qabiliyyətinin də əsas dizayn tələbi olduğunu dəstəkləyir.