Ushbu tadqiqot bino ekspluatatsiyasi va texnik xizmatida qo‘llanadigan real vaqt raqamli egizaklariga sensor ma’lumotlarini olib boradigan uch xil IoT ma’lumot quvurini bir xil sharoitlarda taqqoslaydi. Oltita atrof-muhit sensoridan olingan harorat, nisbiy namlik va karbonat angidrid o‘lchovlari The Things Network orqali bir vaqtning o‘zida TTN–AWS–Unity, TTN–Azure–Unity va TTN–MQTT–Unity quvurlariga uzatilgan. Barcha quvurlar bir xil sensorlar, LoRaWAN infratuzilmasi, JSON ma’lumot tuzilmasi, vaqt tamg‘asi, o‘n daqiqalik o‘lchash oralig‘i va bir xil Unity asosidagi bino raqamli egizagidan foydalangan. Shunday qilib, taqqoslashning asosiy o‘zgaruvchisi faqat sensor bilan Unity o‘rtasidagi ma’lumot integratsiyasi arxitekturasi bo‘lgan.

Barqaror telemetriya sharoitida MQTT quvuri eng past yangilanish vaqtini va eng sodda arxitekturani ta’minlagan. Median yangilanish vaqti MQTT uchun 0,9 soniya, AWS uchun 2,8 soniya va Azure uchun 3,2 soniya deb bildirilgan. 95 foizlik kechikish qiymati MQTTda 1,5 soniya, AWSda 4,6 soniya va Azureda 5,1 soniya bo‘lgan. MQTTning to‘g‘ridan-to‘g‘ri publish–subscribe mexanizmi ma’lumotni oraliq saqlash va API so‘rovisiz Unityga yetkazishni ta’minlagan. AWS va Azure quvurlari esa yuqoriroq kechikish evaziga doimiy ma’lumot saqlash, tarixiy yozuvlarni so‘rash, batafsil jurnallar va kuchliroq tizim kuzatuvchanligini taklif qilgan.

Taxminan uch hafta davomida sensor telemetriyasi butunlay uzilgan davrda arxitektura farqlarining ilova qatlamidagi ta’siri yo‘qolgan. Uch quvurning barchasida Unity oxirgi olingan qiymatlarni ko‘rsatishda davom etgan, ammo bu qiymatlar yangilanmagan. Tadqiqotchilar bu holatni “eskirgan holat” deb ataydi. Bulut asosidagi tizimlarda ma’lumotlar bazasiga yangi yozuv kelmasligi, serverless funksiyalar ishlamasligi va jurnallar to‘xtashi uzilishni orqa fonda ko‘rinadigan qilgan. MQTT quvurida esa yangi xabar kelmasligi, agar vaqt tamg‘asi nazorati yoki heartbeat mexanizmi bo‘lmasa, foydalanuvchi interfeysida bevosita xato signalini yaratmagan.

Tadqiqotning asosiy xulosasi shuki, bitta ma’lumot quvuri barcha bino raqamli egizagi ilovalari uchun universal tarzda eng yaxshi emas. Tezkor vizualizatsiya va past arxitektura murakkabligi ustuvor bo‘lsa, MQTT ajralib turadi. Tarixiy tahlil, texnik xizmat auditi, huquqiy yozuv, ma’lumot boshqaruvi va xatoni tekshirish muhim bo‘lsa, AWS yoki Azurega o‘xshash doimiy bulut quvurlari afzallik beradi. Tadqiqotchilar real ilovalarda MQTT asosidagi tezkor uzatishni bulut asosidagi saqlash va monitoring bilan birlashtiradigan gibrid arxitekturalar mosroq bo‘lishi mumkinligini ta’kidlaydi.

Turkiya nuqtai nazaridan ahamiyati

Turkiyada shifoxonalar, universitet kampuslari, davlat binolari, savdo markazlari, mehmonxonalar, fabrikalar va ma’lumot markazlari uchun ishlab chiqiladigan raqamli egizaklarda xuddi shu arxitektura tanlovi muammosi mavjud. Ichki havo sifati yoki energiya iste’molini jonli kuzatish uchun past kechikishli MQTT oqimi foydali bo‘lishi mumkin, texnik xizmat tarixi, me’yoriy yozuvlar, energiya taqqoslashlari va nosozlik tahlili uchun esa doimiy bulut saqlashi zarur.

Turkiyada quriladigan tizimda faqat ma’lumot kelganda qanchalik tez ko‘rsatilishi emas, ma’lumot kelmaganda buning foydalanuvchiga qanday bildirilishi ham dizayn mezoni bo‘lishi kerak. Unity, veb panel yoki bino boshqaruv tizimida oxirgi yangilanish vaqti, ma’lumot yoshi, rangli eskirgan-ma’lumot ogohlantirishi, sensor heartbeat signali va timeout ogohlantirishi ko‘rsatilishi kerak. Ayniqsa karbonat angidrid, harorat, namlik, bosim yoki uskunaning holati kabi operatsion qarorlarga ta’sir qiladigan qiymatlar dolzarb emasligi ochiq bildirilmasdan turib, raqamli egizak chiqishlari ishonchli operatsion ma’lumot sifatida ishlatilmasligi lozim.

Tadqiqot natijalarini Turkiyadagi barcha bino va tarmoq infratuzilmalariga bevosita umumlashtirib bo‘lmaydi. Turli LoRaWAN shlyuzlari, mobil operator ulanishlari, mahalliy IoT platformalari, bino avtomatizatsiyasi protokollari, ancha ko‘p sensorlar, boshqa ma’lumot yaratish chastotalari va real texnik xizmat ssenariylari bilan qayta tasdiqlash zarur.

Tadqiqotning asosiy muammosi nima?

Bino raqamli egizagi faqat uch o‘lchamli modeldan iborat emas. Raqamli model fizik binoning joriy holatini ifodalashi uchun sensor o‘lchovlari uzluksiz ravishda raqamli muhitga yetib borishi kerak. Harorat, namlik, karbonat angidrid, energiya iste’moli yoki qurilma holati yangilanmasa, uch o‘lchamli model vizual jihatdan ishlashda davom etishi mumkin; biroq fizik bino bilan vaqt bo‘yicha bog‘lanishini yo‘qotadi.

Sensor bilan raqamli egizak o‘rtasida odatda bir nechta tizim qatlamlari mavjud:

• Fizik sensor va o‘lchash qatlami.
• LoRaWAN, Wi-Fi yoki boshqa aloqa qatlami.
• Qurilmani ro‘yxatdan o‘tkazish, ma’lumotni dekodlash va yo‘naltirishni ta’minlovchi tarmoq boshqaruvi qatlami.
• Bulut yoki xabar brokeridan foydalanadigan ma’lumot integratsiyasi qatlami.
• Unity kabi raqamli egizak ilova qatlami.
• Obyekt menejeri foydalanadigan ish stoli, virtual reallik yoki aralash reallik interfeysi.

Tadqiqot bo‘shlig‘i shundan iboratki, raqamli egizak adabiyoti ko‘pincha modellashtirish, BIM integratsiyasi, vizualizatsiya va analitikaga e’tibor qaratadi; sensor ma’lumotini ilovaga olib boradigan oraliq ma’lumot quvurining xatti-harakatini esa ikkilamchi amalga oshirish tanlovi sifatida ko‘radi. Tadqiqotchilar ma’lumot quvuri kechikish, ma’lumotning doimiyligi, tizim murakkabligi, xatoni tashxislash va raqamli egizakning dolzarbligiga bevosita ta’sir qilishini ta’kidlaydi.

Uch tadqiqot savoli

1. Bulut markazli va oqimga asoslangan IoT ma’lumot quvurlarini ajratib turadigan arxitektura xususiyatlari nimalar va ular bir xil raqamli egizak ichida ma’lumot tarqalishiga qanday ta’sir qiladi?
2. Tizim barqaror telemetriyadan telemetriya yo‘qligiga o‘tganda integratsiya arxitekturasining ta’siri qanday o‘zgaradi?
3. Kechikish, doimiylik, kuzatuvchanlik va nosozlik shaffofligi kabi mezonlar bino raqamli egizaklarida ma’lumot quvurini tanlashni qanday yo‘naltirishi kerak?

Bulut va MQTT yondashuvi o‘rtasidagi asosiy farq

Tadqiqotning 2-sahifasidagi 1.1-rasm sensor ma’lumoti ikki muqobil yo‘l orqali raqamli egizakka qanday yetishini ko‘rsatadi. Bulut quvurida ma’lumot sensordan bulut platformasiga yuboriladi, qayta ishlanadi, doimiy ma’lumotlar bazasida saqlanadi va keyin Unity tomonidan API orqali olinadi. MQTT quvurida esa sensor ma’lumoti xabar brokeriga publish qilinadi va Unity tegishli topicga subscribe bo‘lib, xabarni to‘g‘ridan-to‘g‘ri oladi.

Qatlamli bog‘liqlik modeli

11-sahifadagi 3.1-rasm IoT qo‘llab-quvvatlaydigan raqamli egizakni olti qatlamli tuzilma sifatida ko‘rsatadi:

1. Fizik sezish qatlami: Sensorlar vaqt tamg‘ali o‘lchovlar yaratadi.
2. Aloqa qatlami: Signal LoRaWAN yoki Wi-Fi orqali uzatiladi.
3. Tarmoq boshqaruvi qatlami: Qurilma ro‘yxati, payloadni dekodlash va TTN yo‘naltirish amalga oshiriladi.
4. Ma’lumot integratsiyasi qatlami: Bulut yoki MQTT arxitekturasi ma’lumotni ilovaga tayyorlaydi.
5. Ilova qatlami: Unity ma’lumotni uch o‘lchamli bino modeliga moslaydi.
6. Foydalanuvchi o‘zaro ta’sir qatlami: Obyekt menejeri ma’lumotni ekran, virtual reallik yoki aralash reallik interfeysida ko‘radi.

Modelning asosiy g‘oyasi vertikal bog‘liqlikdir. Pastki qatlamlarning ishlashi yuqoridan keladigan telemetriyaning muvaffaqiyatli yetkazilishiga bog‘liq. Eng rivojlangan Unity vizualizatsiyasi yoki bulut infratuzilmasi ham sensor umuman yaratmagan yoki TTNga yetib bormagan yangi ma’lumotni qayta yaratolmaydi.

Qobiliyat rejimi va bog‘liqlik rejimi

13-sahifadagi 3.2-rasm tadqiqotning ikki operatsion rejimini ko‘rsatadi.

Qobiliyat rejimi: Barqaror telemetriya

Ma’lumot uzluksiz kelganda arxitekturalarning o‘ziga xos afzalliklari namoyon bo‘ladi. Bulut asosidagi quvurlar doimiy ma’lumot, boshqaruv va tarixiy yozuvlarni taklif qilsa, MQTT past kechikish, to‘g‘ridan-to‘g‘ri yangilanish va kamroq oraliq komponent beradi.

Bog‘liqlik rejimi: Telemetriya yo‘qligi

Yuqori qatlamdan yangi telemetriya kelmasa, ilova qatlamidagi xatti-harakatlar bir-biriga yaqinlashadi. Barcha quvurlar oxirgi olingan qiymatni ko‘rsatishda davom etadi. Bu bosqichda baholash savoli “qaysi quvur tezroq?” bo‘lishdan chiqib, “uzilish qanchalik ochiq ko‘rinadi va qaysi qatlamda tashxis qo‘yish mumkin?” degan savolga aylanadi.

Nosozlik shaffofligi nima?

Tadqiqotchilar nosozlik shaffofligini telemetriya yo‘qligi yoki buzilishi jurnallar, yangilanish xatti-harakati, ma’lumotlar bazasi harakatlari yoki foydalanuvchi interfeysi orqali qanchalik ochiq ko‘rinishi sifatida ta’riflaydi.

Nosozlik shaffofligi nosozlikka chidamlilik yoki tiklanish bilan bir xil emas. Tizim telemetriya oqimini qayta ishga tushira olmasligi mumkin; biroq ma’lumot dolzarb emasligini ochiq ko‘rsatib, foydalanuvchining eski qiymatni yangi deb qabul qilishiga yo‘l qo‘ymasligi mumkin.

Taklif etilgan asosiy mexanizmlar quyidagilar:

• Oxirgi muvaffaqiyatli ma’lumot qabul qilish vaqtini ko‘rsatish.
• Joriy ma’lumot yoshini soniya yoki daqiqada hisoblash.
• Belgilangan muddatdan eski ma’lumotlar uchun rangli ogohlantirish berish.
• Sensor yoki ma’lumot quvuri heartbeat xabarlarini kuzatish.
• Yangi xabar kelmasa timeout ogohlantirishi yaratish.
• Unity ekranida “dolzarb”, “kechikkan” va “eskirgan” holatlarini ajratish.
• Bulut funksiyasi, ma’lumotlar bazasi, API va MQTT ulanish holatini alohida kuzatish.

Maydon qurilmasi

Tadqiqot Oxford Brookes University tarkibidagi New Headington Hill Building binosining tanlangan tadqiqot xonasida o‘tkazilgan. 16-sahifadagi 4.1a-rasm binoni, 4.1b-rasm esa oltita sensorning xona ichidagi joylashuvini ko‘rsatadi. Sensorlar bitta nuqtaga to‘planmagan; xona ichidagi turli zonalarda ichki muhit o‘zgarishini kuzatish uchun tarqatilgan.

Nazorat qilinadigan taqqoslash qanday ta’minlangan?

Uch quvurning barchasi bir xil sensor ma’lumotini TTNdan bir vaqtda olgan. Sensorlar, yuborish oralig‘i, shlyuz, TTN payload dekodlash jarayoni, JSON maydonlari, vaqt tamg‘asi va Unity sahnasi o‘zgartirilmagan. Shunday qilib, AWS, Azure va MQTT o‘rtasida ko‘rilgan farqlar ma’lumot integratsiyasi qatlamidan kelib chiqqan deb qabul qilingan.

TTN qabul vaqt tamg‘asi uch quvur uchun umumiy boshlanish vaqti sifatida ishlatilgan. Yangilanish vaqti xabar TTN tomonidan qabul qilinishi bilan tegishli qiymatning Unityda ko‘rsatilishi o‘rtasidagi vaqt sifatida ta’riflangan.

TTN–AWS–Unity arxitekturasi

24-sahifadagi 5.2-rasm AWS quvurini fizik sensordan Unity ekranigacha qatlamlar shaklida ko‘rsatadi:

1. Sensor LoRaWAN uplink xabarini yuboradi.
2. Shlyuz xabarni TTNga uzatadi.
3. TTN ma’lumotni webhook orqali AWS API Gatewayga yuboradi.
4. Lambda funksiyasi JSON ma’lumotini tekshiradi va qayta ishlaydi.
5. Ma’lumot DynamoDBda doimiy saqlanadi.
6. Unity ikkinchi API Gateway va Lambda funksiyasi orqali eng so‘nggi yozuvlarni so‘raydi.
7. C# skriptlari qiymatni tegishli uch o‘lchamli sensor indikatoriga yozadi.

Bu tuzilma tarixiy yozuvlarni saqlashi va har bir bosqichda iz qoldirishi mumkin. Buning evaziga ikki API gateway, qayta ishlash funksiyalari, ma’lumotlar bazasi va Unity so‘rov qatlami ko‘proq konfiguratsiya va bog‘liqlik hosil qiladi.

TTN–Azure–Unity arxitekturasi

25-sahifadagi 5.3-rasm Azure quvuri o‘xshash doimiylikka yo‘naltirilgan modelni boshqa xizmatlar bilan amalga oshirishini ko‘rsatadi:

1. TTN telemetriyani webhook orqali Azure App Service ichidagi qabul qiluvchiga yuboradi.
2. ASP.NET Core asosidagi komponent ma’lumotni qayta ishlaydi.
3. Yozuv Azure ma’lumot jadvalida saqlanadi.
4. Unity REST API orqali eng yangi qiymatlarni so‘raydi.
5. Unity C# skriptlari uch o‘lchamli modeldagi sensor matnlarini yangilaydi.

Tadqiqot AWS va Azure o‘rtasidagi asosiy arxitektura yondashuvi bir xil ekanini bildiradi. Azure ilovasining bir nechta xizmat interfeysi o‘rtasida koordinatsiya talab qilishi, o‘rganilgan qurilmada yuqoriroq konfiguratsiya yukini yaratgan. Bu natija umumiy Azure–AWS ustunlik reytingi sifatida taqdim etilmagan.

TTN–MQTT–Unity arxitekturasi

27-sahifadagi 5.4-rasm tekisroq ma’lumot quvurini ko‘rsatadi:

1. Sensor xabari LoRaWAN orqali TTNga yetadi.
2. TTN xabarni MQTT serveriga yo‘naltiradi.
3. Unity tegishli MQTT topicga subscribe bo‘ladi.
4. Xabar publish qilinganda Unity ichidagi MQTT manager JSON ma’lumotini qayta ishlaydi.
5. Qiymat kutish yoki API so‘rovisiz tegishli vizualga uzatiladi.

Bu tuzilmada ma’lumotlar bazasi mavjud emas. Xabar kelishi bilan qayta ishlanadi; keyin tarixiy so‘rov talab qilinsa alohida saqlash komponenti qo‘shilishi kerak. Ulanishni nazorat qilish, qayta ulanish va ma’lumot dolzarbligini aniqlash mas’uliyati katta darajada Unity ilovasiga o‘tadi.

Barqaror telemetriya natijalari

MQTTning median yangilanish vaqti AWSga nisbatan 1,9 soniya, Azurega nisbatan 2,3 soniya past bo‘lgan. Bu farq faqat protokol nomidan kelib chiqmagan. MQTT quvurida oraliq ma’lumotni qayta ishlash, doimiy saqlash va davriy API so‘rovi yo‘qligi arxitektura yo‘lini qisqartirgan.

AWS va Azure sekinroq bo‘lsa-da, tarixiy qiymatlarni so‘rash, ma’lumot oqimini turli bosqichlarda tekshirish, nosozlik qaysi qatlamda yuz berganini o‘rganish va texnik xizmat yozuvlarini saqlash jihatidan kuchliroq.

Uch haftalik telemetriya uzilishida nima bo‘ldi?

Uzilish davrida TTNga sensor uplink xabari kelmagan. Natijada:

• AWS webhook yangi payload olmagan.
• AWS Lambda funksiyalari ishlamagan va DynamoDBga yangi yozuv yozilmagan.
• Azure webhook va qayta ishlash xizmatlari yangi ma’lumot olmagan.
• Azure ma’lumot jadvalida yangi yozuv hosil bo‘lmagan.
• MQTT broker yangi xabar publish qilmagan.
• Unityning uch versiyasi ham oxirgi olingan qiymatni ko‘rsatishda davom etgan.

Bulut tizimlarida oxirgi yozuv ma’lumotlar bazasida saqlangan, MQTTda esa Unity xotirasidagi oxirgi ko‘rsatilgan qiymat qolgan. Ammo uch holatning barchasida ko‘rsatilgan qiymat fizik muhitning yangi holatini ifodalamagan.

Eskirgan holat nega xavfli?

Uch o‘lchamli bino modeli ishlashda davom etgani va ekran xato bermagani uchun foydalanuvchi tizim dolzarb deb o‘ylashi mumkin. Masalan, auditoriyadagi oxirgi CO₂ qiymati qabul qilinadigan darajada qolib turgandek ko‘rinishi mumkin, holbuki real muhit shamollatish yetishmovchiligi tufayli o‘zgargan bo‘lishi mumkin. Obyekt menejeri ma’lumot uch soat yoki uch kun oldin olinganini bilmasa, noto‘g‘ri shamollatish yoki foydalanish qarorini qabul qilishi mumkin.

Shu sababli tadqiqot raqamli egizak ishonchliligining ikkita alohida komponenti borligini ko‘rsatadi:

• Fazoviy aniqlik: Sensor va bino elementlarining to‘g‘ri joyda ko‘rsatilishi.
• Vaqt bo‘yicha haqiqiylik: Ko‘rsatilgan qiymat fizik muhitning joriy holatini ifodalashi.

Uzilish paytida arxitekturalar qanday farqlanadi?

Tadqiqotning “tiklanish xususiyatlari” jadvali MQTT uchun ma’lumot qayta boshlaganda tez davom etish, bulut uchun esa tarixiy uzluksizlik saqlanishi ifodalarini ishlatadi. Biroq soniyalarda o‘lchangan tiklanish vaqti, yo‘qolgan xabarlarning qoplanishi yoki qayta ulanish soni o‘lchanmagan.

Nega gibrid arxitektura taklif qilinadi?

Bino raqamli egizaklarining ko‘pchiligi ham jonli ko‘rinish, ham tarixiy yozuvni talab qiladi. Shu sababli faqat MQTT yoki faqat bulut o‘rniga ikki quvurni birga ishlatadigan tuzilma ko‘rib chiqilishi mumkin:

• MQTT jonli qiymatni past kechikish bilan Unityga yuboradi.
• Xuddi shu xabar bir vaqtda bulut ma’lumotlar bazasiga yoziladi.
• Unity xabarning oxirgi kelish vaqtini kuzatadi.
• Heartbeat uzilganda eskirgan holat ogohlantirishi beradi.
• Jonli ulanish uzilsa, foydalanuvchi tarixiy ma’lumotni ko‘rishi mumkin; biroq tarixiy qiymat jonli emasligi aniq ko‘rsatiladi.
• Bulut monitoring vositalari uzilish sensor, TTN, qayta ishlash yoki ilova qatlamining qaysi birida ekanini o‘rganishni qo‘llab-quvvatlaydi.

Tadqiqot qo‘llab-quvvatlaydigan natijalar

• Bir xil sensor va Unity sharoitida MQTT quvuri o‘rganilgan AWS va Azure quvurlaridan pastroq yangilanish vaqtini ta’minlagan.
• Bulut markazli quvurlar doimiy saqlash va tarixiy so‘rov imkonini bergan.
• MQTT quvuri kamroq oraliq komponent bilan qurilgan.
• Bulut quvurlari jurnal, ma’lumotlar bazasi va API yozuvlari tufayli ko‘proq tashxis nuqtalarini taklif qilgan.
• Yangi telemetriya kelmaganda uch arxitekturaning barchasi Unityda eskirgan holatga o‘tgan.
• Doimiy saqlash yangi ma’lumot yo‘qligini qoplamagan; faqat oxirgi tarixiy holatni saqlagan.
• MQTT ishlatadigan raqamli egizaklarda dolzarblik va timeout nazorati ilova qatlamida alohida ishlab chiqilishi kerak.
• Ma’lumot quvurini tanlash faqat kechikishga emas, doimiylik va nosozlik shaffofligiga ham asoslanishi kerak.

Tadqiqot isbotlamagan natijalar

• MQTT barcha tarmoqlarda va barcha raqamli egizak ilovalarida doimo tezroq ekani isbotlanmagan.
• AWS yoki Azure umumiy tarzda bir-biridan yaxshiroq ekani ko‘rsatilmagan.
• Tadqiqot mustaqil AWS–Azure xarajat yoki xizmat sifati benchmarki emas.
• O‘n minglab sensorli katta ko‘lamli tizimlarda ishlash o‘lchanmagan.
• Qisman paket yo‘qotilishi, tartibsiz ma’lumot, kechikkan telemetriya yoki bitta sensor nosozligi alohida sinovdan o‘tkazilmagan.
• Uch haftalik uzilishning asosiy sababi aniqlanmagan.
• Foydalanuvchilarning eskirgan ma’lumotni qanday talqin qilishi obyekt menejerlari bilan tajribada o‘lchanmagan.
• Nosozlik shaffofligi xavfsizlik yoki qaror aniqligini qanchalik oshirishi miqdoriy ko‘rsatilmagan.
• Gibrid MQTT–bulut arxitekturasi ushbu tadqiqotda amalga oshirilib taqqoslanmagan.
• Natijalar turli mamlakatlardagi barcha bino, sensor, tarmoq va bulut konfiguratsiyalariga bevosita umumlashtirilmaydi.

Tadqiqotning Usuli va Natijalari

Tadqiqot dizayni

Beshta baholash o‘lchovi

Statistik tahlil rejasi

Tadqiqot 200.000 dan ortiq kuzatuv tufayli kechikish taqsimotlari parametrik bo‘lmagan usullar bilan taqqoslanganini bildiradi:

• Uch quvur uchun umumiy taqqoslashda Kruskal–Wallis H testi.
• Quvur juftlari uchun Mann–Whitney U testi.
• Ko‘p taqqoslash uchun Bonferroni tuzatishi va \(\alpha=0{,}017\).
• Amaliy effekt kattaligi uchun rank-biserial korrelyatsiya \(r\).
• Tavsiflovchi statistika sifatida median, IQR va 95 foizlik kechikish.

Biroq natija jadvallarida Kruskal–Wallis H qiymati, erkinlik darajasi, Mann–Whitney U qiymatlari, tuzatilgan p qiymatlari yoki rank-biserial korrelyatsiya natijalari mavjud emas. Shu sababli “statistik jihatdan farqli” degan baho tadqiqotda ko‘rsatilgan tahlil rejasiga ko‘ra mustaqil tekshirib bo‘lmaydi. Mavjud raqamli qo‘llab-quvvatlash asosan median, o‘zgaruvchanlik va 95 foizlik kechikish qiymatlariga tayangan.

Hisobot nomuvofiqliklari

• 3-jadvaldagi o‘zgaruvchanlik qiymatlari bilan keyingi paragrafdagi IQR qiymatlari farq qiladi.
• Jadval sarlavhasi IQR bilan yangilanish oralig‘i o‘zgaruvchanligini bir xil o‘lchov sifatida ko‘rsatadi.
• Bulut quvurining 10 soniyalik so‘rov oralig‘i bilan bildirilgan 95 foizlik kechikishlar o‘rtasidagi munosabat tushuntirilmagan.
• Uch quvurda “%1 dan kam ma’lumot yo‘qotilishi” berilgan, ammo aniq denominator, yo‘qotish soni va yo‘qotish qaysi qatlamda yuz bergani ko‘rsatilmagan.
• Ma’lumot hajmi uch quvurda bir xil ekani aytilgan, biroq yo‘qotish ko‘rsatkichlari qanday hisoblangani batafsil berilmagan.
• Nosozlik shaffofligi “yuqori”, “o‘rta” yoki “past” deb tasniflangan, ammo standart ball berish usuli taqdim etilmagan.
• Tiklanish xususiyatlari sifat jihatdan izohlangan, real qayta ulanish yoki tiklanish vaqtlari o‘lchanmagan.

Tadqiqotning kuchli tomonlari

• Uch arxitekturaning bir xil sensor, TTN va Unity sharoitida bir vaqtda ishlatilishi.
• Real bino va umumiy kampus aloqa infratuzilmasidan foydalanilishi.
• Taxminan o‘n oylik uzunlamasına kuzatuv amalga oshirilishi.
• 200.000 dan ortiq telemetriya yozuvi to‘planishi.
• Faqat barqaror tizim xatti-harakati emas, real telemetriya uzilishi ham o‘rganilishi.
• Kechikishdan tashqari doimiylik, arxitektura murakkabligi va kuzatuvchanlik taqqoslanishi.
• Raqamli egizaklarda vaqt bo‘yicha haqiqiylik va eskirgan holat xavfining ko‘rinadigan qilinishi.
• Nosozlik shaffofligining alohida arxitektura baholash o‘lchovi sifatida ta’riflanishi.

Asosiy cheklovlar

• Tadqiqot ekspert taqrizidan o‘tmagan.
• Bitta bino va bitta xona ishlatilgan.
• Faqat oltita sensor va bitta sensor modeli mavjud.
• Sensorlar faqat har o‘n daqiqada ma’lumot yaratgan; soniyalik yuqori chastotali telemetriya sinovdan o‘tkazilmagan.
• Unity ilovasi va bulut konfiguratsiyalari bitta amalga oshirish misoli bilan cheklangan.
• Tarmoq infratuzilmasi nazorat maqsadida izolyatsiya qilinmagan.
• Uzilishning asosiy sababi aniqlanmagan.
• Nazorat qilinadigan paket yo‘qotilishi, kechikish yoki davriy ulanish tajribalari o‘tkazilmagan.
• Xarajat, xavfsizlik, energiya va masshtablanuvchanlik taqqoslanishi mavjud emas.
• Statistik test natijalari to‘liq hisobot qilinmagan.
• Ma’lumot va tahlil kodi uchun ochiq ombor havolasi berilmagan.
• Nosozlik shaffofligi real obyekt menejerlari bilan tasdiqlanmagan.
• Gibrid MQTT–bulut yondashuvi faqat kelajakdagi ish taklifidir.

Turkiyada qo‘llashdan oldin zarur tasdiqlar

1. Turli iqlim hududlarida shifoxona, kampus, fabrika va tijorat binosi ilovalarini o‘rnatish.
2. Yuzlab yoki minglab sensor bilan yuk va masshtablanuvchanlik sinovi o‘tkazish.
3. LoRaWANdan tashqari Wi-Fi, NB-IoT, LTE-M va simli bino avtomatizatsiyasi tarmoqlarini taqqoslash.
4. MQTT jonli oqimini bulut saqlashi bilan birlashtirgan gibrid arxitekturani amalga oshirish.
5. Uzilish, paket yo‘qotilishi, kechikish va sensor nosozligini nazorat qilinadigan tarzda tizimga kiritish.
6. Uzilishni aniqlash va tiklanish vaqtlarini soniyada o‘lchash.
7. Oxirgi yangilanish vaqti va eskirgan holat ogohlantirishlarini obyekt menejerlari bilan foydalanuvchi sinovidan o‘tkazish.
8. Bulut va mahalliy server xarajatlarini umumiy egalik xarajati bilan taqqoslash.
9. KVKK, kirish nazorati, ma’lumot shifrlash va qurilma autentifikatsiyasini alohida baholash.
10. Xom ma’lumot, Unity kodi, vaqt tamg‘asini qayta ishlash usuli va statistika skriptlarini ulashish.

Manba va Usul Haqida Izoh

Tadqiqotning to‘liq asl nomi: Evaluation of IoT Data Pipeline Architectures for Real-Time Digital Twins in Building Operations and Maintenance

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

Mualliflar tartibi: Muhammad Shahzad birinchi, Avar Almukhtar ikkinchi, Muhammad Younas uchinchi va Joe Tah to‘rtinchi muallifdir.

Muallif ma’lumoti bo‘yicha hujjat izohi: Ko‘rib chiqilgan versiyaning birinchi sahifasida muallif va muassasa bloki mavjud emas. Muallif tartibi SSRN rasmiy qayd ma’lumotlariga ko‘ra berilgan. Fayl metadata’sida faqat Muhammad Shahzad nomi mavjud.

Teng birinchi muallif: Teng hissa yoki teng birinchi muallif bayonoti ko‘rib chiqilgan versiyada mavjud emas.

Mas’ul muallif: SSRN rasmiy qaydi Muhammad Shahzadni “Contact Author” sifatida ko‘rsatadi. Ko‘rib chiqilgan matnda mas’ul muallif yulduzchasi yoki aloqa elektron pochta manzili mavjud emas.

Tasdiqlanadigan institutsional aloqalar:

• Muhammad Shahzad — School of the Built Environment, Oxford Brookes University, Birlashgan Qirollik.
• Avar Almukhtar — School of the Built Environment, Oxford Brookes University, Birlashgan Qirollik.
• Muhammad Younas — School of Engineering, Computing and Mathematics, Oxford Brookes University, Birlashgan Qirollik.
• Joe Tah — Professor of Project Management, Oxford Brookes University, Birlashgan Qirollik.

Muassasa tasdiqlash chegarasi: SSRN qaydida muallif muassasalari berilmagan. Yuqoridagi ma’lumotlar Oxford Brookes Universityning rasmiy joriy xodim va doktorant profillaridan tasdiqlangan; ko‘rib chiqilgan versiyada alohida institutsional moslashtirish jadvali mavjud emas.

DOI:10.2139/ssrn.7193080

Jurnal: Ko‘rib chiqilgan versiyada ekspert taqrizidan o‘tgan jurnal nomi mavjud emas.

Nashriyot: Yakuniy nashriyot haqida tasdiqlangan ma’lumot mavjud emas. SSRN preprint platformasidir va ushbu tadqiqotning yakuniy akademik nashriyoti sifatida baholanmasligi kerak.

Nashr platformasi: SSRN.

SSRN qayd sanasi: 27 Iyul 2026.

Nashr yili: 2026.

Manba turi: Real bino muhitida uchta IoT ma’lumot quvurini taqqoslaydigan amaliy arxitektura, qurilish informatikasi va obyekt boshqaruvi tadqiqoti preprinti.

Ekspert taqrizi holati: Tadqiqot ekspert taqrizidan o‘tmagan. Har bir sahifada preprint va taqriz ogohlantirishi mavjud.

Rasmiy manba:SSRN rasmiy tadqiqot qaydi.

Etik tasdiq: Tadqiqot bino sensorlari va tizim telemetriyasi ustida olib borilgan. Alohida etik kengash yoki etik tasdiq raqami ko‘rib chiqilgan versiyada mavjud emas.

Moliyalashtirish: Alohida moliyalashtirish bayonoti ko‘rib chiqilgan versiyada mavjud emas.

Manfaatlar to‘qnashuvi: Alohida manfaatlar to‘qnashuvi bayonoti ko‘rib chiqilgan versiyada mavjud emas.

Ma’lumot va kodga kirish: Xom telemetriya yozuvlari, AWS va Azure konfiguratsiyalari, Unity manba kodi va statistik tahlil skriptlari uchun ochiq ombor havolasi ko‘rib chiqilgan versiyada berilmagan.

Generativ sun’iy intellekt bayonoti: Tadqiqotchilar manbalarni ko‘rib chiqish uchun Google NotebookLM, qayta ifodalash yordami uchun Paperpal ishlatganini; yaratilgan mazmunni ko‘rib chiqib tahrirlaganini va yakuniy mas’uliyatni o‘z zimmasiga olganini bildirgan.

Ushbu turkcha izoh tadqiqotning 51 sahifalik versiyasi; matni, arxitektura diagrammalari, bino va sensor joylashuvi tasvirlari, baholash jadvallari, statistik tahlil izohlari, uzilish natijalari va manbalar ro‘yxati ko‘rib chiqilib tayyorlangan. Ilmiy mazmunga tadqiqotdan tashqari yangi ko‘rsatkich natijasi qo‘shilmagan. Tashqi manbalar faqat sarlavha, mualliflar, DOI, SSRN qayd sanasi, nashr holati va joriy institutsional aloqalarni bibliografik tasdiqlash maqsadida ishlatilgan.

Tadqiqot MQTT barqaror sharoitlarda tezroq ekanini; AWS va Azure esa ma’lumot doimiyligi va kuzatuvchanlik afzalligini taklif qilishini ko‘rsatadi. Biroq barcha quvurlar yangi telemetriya bo‘lmaganda eskirgan holatga o‘tgan. Natijalar real bino raqamli egizaklarida faqat ma’lumot uzatish tezligi emas, balki ma’lumot endi dolzarb emasligini ochiq ko‘rsatish qobiliyati ham asosiy dizayn talabi ekanini qo‘llab-quvvatlaydi.