Utafiti huu unalinganisha katika hali zilezile njia tatu tofauti za data za IoT zinazobeba data za vihisi kwenda kwenye mapacha dijitali wa wakati halisi wanaotumiwa katika uendeshaji na matengenezo ya majengo. Vipimo vya halijoto, unyevu wa kiasi na dioksidi kaboni kutoka kwa vihisi sita vya mazingira vilihamishwa kwa wakati mmoja kupitia The Things Network kwenda kwenye njia za TTN–AWS–Unity, TTN–Azure–Unity na TTN–MQTT–Unity. Njia zote zilitumia vihisi vilevile, miundombinu ya LoRaWAN, muundo wa data wa JSON, stempu ya muda, muda wa kipimo wa dakika kumi na pacha yuleyule wa kidijitali wa jengo unaotegemea Unity. Kwa hivyo, kigezo kikuu cha ulinganisho kilikuwa tu usanifu wa ujumuishaji wa data kati ya kihisi na Unity.

Katika hali ya telemetria thabiti, njia ya MQTT ilitoa muda wa chini zaidi wa kusasisha na usanifu rahisi zaidi. Muda wa kati wa kusasisha uliripotiwa kuwa sekunde 0,9 kwa MQTT, sekunde 2,8 kwa AWS na sekunde 3,2 kwa Azure. Thamani ya kuchelewa kwa asilimia 95 ilikuwa sekunde 1,5 kwa MQTT, sekunde 4,6 kwa AWS na sekunde 5,1 kwa Azure. Utaratibu wa moja kwa moja wa publish–subscribe wa MQTT uliwezesha data kufikishwa Unity bila hifadhi ya kati au swali la API. Njia za AWS na Azure, kwa kubadilishana na ucheleweshaji mkubwa zaidi, zilitoa hifadhi ya kudumu ya data, uwezo wa kuuliza rekodi za kihistoria, kumbukumbu za kina na uangalizi wa mfumo ulioimarishwa.

Katika kipindi cha takriban wiki tatu ambapo telemetria ya vihisi ilikatika kabisa, athari ya tofauti za usanifu katika tabaka la programu ilitoweka. Katika njia zote tatu, Unity iliendelea kuonyesha thamani za mwisho zilizopokelewa, lakini thamani hizo hazikusasishwa. Watafiti wanaita hali hii “hali iliyochakaa”. Katika mifumo inayotegemea wingu, kutokuwepo kwa rekodi mpya katika hifadhidata, kutofanya kazi kwa kazi za serverless na kusimama kwa kumbukumbu kulifanya kukatika kuonekane nyuma ya mfumo. Katika njia ya MQTT, kutokuwepo kwa ujumbe mpya hakukutoa moja kwa moja ishara ya kosa katika kiolesura cha mtumiaji ikiwa hakukuwa na udhibiti wa stempu ya muda au utaratibu wa heartbeat.

Hitimisho kuu la utafiti ni kwamba hakuna njia moja ya data ambayo ni bora kwa matumizi yote ya mapacha dijitali wa majengo. Ikiwa mwonekano wa papo hapo na ugumu mdogo wa usanifu ni vipaumbele, MQTT hujitokeza. Ikiwa uchambuzi wa kihistoria, ukaguzi wa matengenezo, rekodi za kisheria, utawala wa data na uchunguzi wa hitilafu ni muhimu, njia za wingu zenye hifadhi ya kudumu kama AWS au Azure hutoa faida. Watafiti wanaeleza kwamba katika matumizi halisi, usanifu mseto unaochanganya uwasilishaji wa papo hapo unaotegemea MQTT na hifadhi pamoja na ufuatiliaji unaotegemea wingu unaweza kufaa zaidi.

Umuhimu kwa Uturuki

Katika Uturuki, tatizo hili hili la uchaguzi wa usanifu lipo katika mapacha dijitali yanayoendelezwa kwa hospitali, kampasi za vyuo vikuu, majengo ya umma, vituo vya ununuzi, hoteli, viwanda na vituo vya data. Mtiririko wa MQTT wenye ucheleweshaji mdogo unaweza kuwa muhimu kwa ufuatiliaji wa moja kwa moja wa ubora wa hewa ya ndani au matumizi ya nishati, huku hifadhi ya kudumu ya wingu ikihitajika kwa historia ya matengenezo, rekodi za udhibiti, ulinganisho wa nishati na uchunguzi wa hitilafu.

Katika mfumo utakaojengwa Uturuki, si tu kasi ambayo data inaonyeshwa inapowasili, bali pia jinsi kutokuwepo kwa data kunavyojulishwa kwa mtumiaji inapaswa kuwa kigezo cha usanifu. Katika Unity, paneli ya wavuti au mfumo wa usimamizi wa jengo, muda wa sasisho la mwisho, umri wa data, onyo la rangi kwa data iliyochakaa, ishara ya heartbeat ya kihisi na kengele ya timeout vinapaswa kuonyeshwa. Hasa thamani kama dioksidi kaboni, halijoto, unyevu, shinikizo au hali ya vifaa ambazo huathiri maamuzi ya uendeshaji hazipaswi kutumiwa kama data ya uendeshaji inayoaminika bila kuonyesha wazi kwamba haziko tena za sasa.

Matokeo ya utafiti hayawezi kujumlishwa moja kwa moja kwa majengo na miundombinu yote ya mtandao nchini Uturuki. Uthibitishaji upya unahitajika kwa kutumia gateway tofauti za LoRaWAN, miunganisho ya waendeshaji wa simu, majukwaa ya ndani ya IoT, itifaki za otomatiki za majengo, idadi kubwa zaidi ya vihisi, masafa tofauti ya uzalishaji wa data na senario halisi za matengenezo.

Tatizo kuu la utafiti ni nini?

Pacha dijitali wa jengo haujumuishi tu modeli ya pande tatu. Ili modeli ya kidijitali iweze kuwakilisha hali ya sasa ya jengo halisi, vipimo vya vihisi lazima vifike kwa kuendelea kwenye mazingira ya kidijitali. Ikiwa halijoto, unyevu, dioksidi kaboni, matumizi ya nishati au hali ya vifaa havisasishwi, modeli ya pande tatu inaweza kuendelea kufanya kazi kwa mwonekano; lakini inapoteza uhusiano wake wa muda na jengo halisi.

Kati ya kihisi na pacha dijitali kwa kawaida kuna tabaka nyingi za mfumo:

• Tabaka la kihisi halisi na kipimo.
• Tabaka la mawasiliano la LoRaWAN, Wi-Fi au lingine.
• Tabaka la usimamizi wa mtandao linalotoa usajili wa kifaa, uchambuzi wa data na uelekezaji.
• Tabaka la ujumuishaji wa data linalotumia wingu au broker wa ujumbe.
• Tabaka la programu ya pacha dijitali kama Unity.
• Kiolesura cha kompyuta ya mezani, uhalisia pepe au uhalisia mseto kinachotumiwa na msimamizi wa kituo.

Pengo la utafiti ni kwamba fasihi nyingi za mapacha dijitali hulenga uundaji wa modeli, ujumuishaji wa BIM, mwonekano na uchanganuzi; lakini hushughulikia tabia ya njia ya kati ya data inayobeba data ya kihisi kwenda kwenye programu kama chaguo la utekelezaji la pili. Watafiti wanaeleza kwamba njia ya data ina athari ya moja kwa moja kwa kuchelewa, kudumu kwa data, ugumu wa mfumo, utambuzi wa hitilafu na uhalisia wa muda wa pacha dijitali.

Maswali matatu ya utafiti

1. Ni sifa zipi za usanifu zinazotenganisha njia za data za IoT zinazotegemea wingu na zinazotegemea mtiririko, na sifa hizi zinaathirije usambazaji wa data ndani ya pacha dijitali yuleyule?
2. Athari ya usanifu wa ujumuishaji hubadilikaje mfumo unapohama kutoka telemetria thabiti kwenda kutokuwepo kwa telemetria?
3. Vigezo kama kuchelewa, kudumu, uangalizi na uwazi wa hitilafu vinapaswa kuongoza vipi uchaguzi wa njia ya data katika mapacha dijitali wa majengo?

Tofauti kuu kati ya mkabala wa wingu na MQTT

Kielelezo 1.1 katika ukurasa wa 2 wa utafiti kinaonyesha njia mbili mbadala ambazo data ya kihisi hufikia pacha dijitali. Katika njia ya wingu, data hutumwa kutoka kwa kihisi kwenda kwenye jukwaa la wingu, huchakatwa, huhifadhiwa katika hifadhidata ya kudumu na baadaye huchukuliwa na Unity kupitia API. Katika njia ya MQTT, data ya kihisi huchapishwa kwa broker wa ujumbe na Unity hujisajili kwenye topic husika ili kupokea ujumbe moja kwa moja.

Modeli ya utegemezi wa tabaka

Kielelezo 3.1 katika ukurasa wa 11 kinaonyesha pacha dijitali unaosaidiwa na IoT kama muundo wa tabaka sita:

1. Tabaka la utambuzi wa kimwili: Vihisi hutengeneza vipimo vyenye stempu ya muda.
2. Tabaka la mawasiliano: Ishara hupitishwa kupitia LoRaWAN au Wi-Fi.
3. Tabaka la usimamizi wa mtandao: Usajili wa kifaa, uchambuzi wa payload na uelekezaji wa TTN hufanyika.
4. Tabaka la ujumuishaji wa data: Usanifu wa wingu au MQTT huandaa data kwa programu.
5. Tabaka la programu: Unity huunganisha data na modeli ya pande tatu ya jengo.
6. Tabaka la mwingiliano wa mtumiaji: Msimamizi wa kituo huona data kupitia skrini, uhalisia pepe au kiolesura cha uhalisia mseto.

Dhana kuu ya modeli ni utegemezi wa wima. Uendeshaji wa tabaka za chini hutegemea uwasilishaji wenye mafanikio wa telemetria kutoka tabaka za juu. Hata mwonekano wa kisasa zaidi wa Unity au miundombinu ya wingu haiwezi kuunda upya data mpya ambayo kihisi hakikuzalisha au ambayo haikufika TTN.

Rejimu ya uwezo na rejimu ya utegemezi

Kielelezo 3.2 katika ukurasa wa 13 kinaonyesha rejimu mbili za uendeshaji za utafiti.

Rejimu ya uwezo: Telemetria thabiti

Data inapowasili bila kukatika, faida maalum za usanifu hujitokeza. Njia za wingu hutoa data ya kudumu, utawala na rekodi za kihistoria, huku MQTT ikitoa ucheleweshaji mdogo, usasishaji wa moja kwa moja na vipengele vichache vya kati.

Rejimu ya utegemezi: Kutokuwepo kwa telemetria

Telemetria mpya isipowasili kutoka tabaka la juu, tabia katika tabaka la programu huanza kufanana. Njia zote huendelea kuonyesha thamani ya mwisho iliyopokelewa. Katika hatua hii, swali la tathmini hubadilika kutoka “ni njia ipi ya haraka zaidi?” kwenda “kukatika kunaonekana kwa uwazi kiasi gani na kunaweza kutambuliwa katika tabaka gani?”

Uwazi wa hitilafu ni nini?

Watafiti wanafafanua uwazi wa hitilafu kama kiwango ambacho kutokuwepo au kuharibika kwa telemetria kunaweza kuonekana wazi kupitia kumbukumbu, tabia ya usasishaji, shughuli za hifadhidata au kiolesura cha mtumiaji.

Uwazi wa hitilafu si sawa na uvumilivu wa hitilafu au urejeshaji. Mfumo unaweza kushindwa kuanzisha tena mtiririko wa telemetria; lakini unaweza kuzuia mtumiaji kuchukulia thamani ya zamani kama mpya kwa kuonyesha wazi kwamba data si ya sasa.

Mbinu kuu zinazopendekezwa ni:

• Kuonyesha muda wa mwisho wa kupokea data kwa mafanikio.
• Kuhesabu umri wa data ya sasa kwa sekunde au dakika.
• Kutoa onyo la rangi kwa data iliyozidi muda uliowekwa.
• Kufuatilia ujumbe wa heartbeat wa kihisi au njia ya data.
• Kutengeneza kengele ya timeout ikiwa hakuna ujumbe mpya.
• Kutenganisha hali za “ya sasa”, “imechelewa” na “imechakaa” kwenye skrini ya Unity.
• Kufuatilia kando hali ya kazi ya wingu, hifadhidata, API na muunganisho wa MQTT.

Usanidi wa uwanja

Utafiti ulifanywa katika chumba cha utafiti kilichochaguliwa ndani ya New Headington Hill Building katika Oxford Brookes University. Kielelezo 4.1a katika ukurasa wa 16 kinaonyesha jengo, na Kielelezo 4.1b kinaonyesha maeneo ya vihisi sita ndani ya chumba. Vihisi havikukusanywa katika sehemu moja; vilisambazwa katika maeneo tofauti ya chumba ili kuchunguza mabadiliko ya mazingira ya ndani.

Ulinganisho uliodhibitiwa ulihakikishwaje?

Njia zote tatu zilipokea data ileile ya kihisi kutoka TTN kwa wakati mmoja. Vihisi, muda wa kutuma, gateway, mchakato wa kuchambua payload wa TTN, sehemu za JSON, stempu ya muda na scene ya Unity havikubadilishwa. Kwa hivyo, ilidhaniwa kwamba tofauti zilizoonekana kati ya AWS, Azure na MQTT zilitokana na tabaka la ujumuishaji wa data.

Stempu ya muda ya kupokea TTN ilitumika kama muda wa kuanza wa pamoja kwa njia zote tatu. Muda wa kusasisha ulifafanuliwa kama muda kati ya kupokelewa kwa ujumbe na TTN na kuonyeshwa kwa thamani husika katika Unity.

Usanifu wa TTN–AWS–Unity

Kielelezo 5.2 katika ukurasa wa 24 kinaonyesha njia ya AWS kwa tabaka kutoka kihisi halisi hadi skrini ya Unity:

1. Kihisi hutuma ujumbe wa LoRaWAN uplink.
2. Gateway hupeleka ujumbe TTN.
3. TTN hutuma data kupitia webhook kwenda AWS API Gateway.
4. Kazi ya Lambda huhakiki na kuchakata data ya JSON.
5. Data huhifadhiwa kwa kudumu katika DynamoDB.
6. Unity huuliza rekodi za hivi karibuni kupitia API Gateway ya pili na kazi ya Lambda.
7. Skripti za C# huandika thamani kwenye kiashiria husika cha kihisi cha pande tatu.

Muundo huu unaweza kuhifadhi rekodi za kihistoria na kuacha alama katika kila hatua. Kwa upande mwingine, API gateway mbili, kazi za uchakataji, hifadhidata na tabaka la swali la Unity huongeza usanidi na utegemezi.

Usanifu wa TTN–Azure–Unity

Kielelezo 5.3 katika ukurasa wa 25 kinaonyesha kwamba njia ya Azure hutekeleza modeli inayofanana inayolenga kudumu kwa kutumia huduma tofauti:

1. TTN hutuma telemetria kwa webhook kwenda kwa kipokezi ndani ya Azure App Service.
2. Kipengele kinachotegemea ASP.NET Core huchakata data.
3. Rekodi huhifadhiwa katika jedwali la data la Azure.
4. Unity huuliza thamani za hivi karibuni kupitia REST API.
5. Skripti za Unity C# husasisha maandishi ya vihisi katika modeli ya pande tatu.

Utafiti unaeleza kwamba mkabala mkuu wa usanifu wa AWS na Azure ni uleule. Hitaji la kuratibu violesura vingi vya huduma katika utekelezaji wa Azure liliunda mzigo mkubwa zaidi wa usanidi katika mpangilio uliosomwa. Matokeo haya hayakuwasilishwa kama ulinganisho wa jumla wa ubora wa Azure dhidi ya AWS.

Usanifu wa TTN–MQTT–Unity

Kielelezo 5.4 katika ukurasa wa 27 kinaonyesha njia ya data iliyo nyoofu zaidi:

1. Ujumbe wa kihisi hufika TTN kupitia LoRaWAN.
2. TTN huelekeza ujumbe kwa seva ya MQTT.
3. Unity hujisajili kwenye topic husika ya MQTT.
4. Ujumbe unapochapishwa, meneja wa MQTT ndani ya Unity huchakata data ya JSON.
5. Thamani huhamishwa moja kwa moja kwenye mwonekano husika bila kusubiri au kuuliza API.

Katika muundo huu hakuna hifadhidata. Ujumbe huchakatwa mara unapopokelewa; ikiwa baadaye maswali ya kihistoria yanahitajika, kipengele tofauti cha hifadhi lazima kiongezwe. Jukumu la udhibiti wa muunganisho, kuunganisha tena na kuamua uhalisia wa data huhamishiwa kwa kiasi kikubwa kwenye programu ya Unity.

Matokeo ya telemetria thabiti

Muda wa kati wa kusasisha wa MQTT ulikuwa chini kwa sekunde 1,9 kuliko AWS na kwa sekunde 2,3 kuliko Azure. Tofauti hii haikutokana tu na jina la itifaki. Kutokuwepo kwa uchakataji wa data wa kati, hifadhi ya kudumu na maswali ya API ya mara kwa mara katika njia ya MQTT kulifupisha njia ya usanifu.

Ingawa AWS na Azure zilikuwa polepole zaidi, zilikuwa na nguvu zaidi katika kuuliza thamani za kihistoria, kuchunguza mtiririko wa data katika hatua tofauti, kutafuta tabaka ambako hitilafu ilitokea na kuhifadhi rekodi za matengenezo.

Nini kilitokea wakati wa kukatika kwa telemetria kwa wiki tatu?

Katika kipindi cha kukatika, TTN haikupokea ujumbe wa uplink kutoka kwa vihisi. Matokeo yake:

• Webhook ya AWS haikupokea payload mpya.
• Kazi za AWS Lambda hazikufanya kazi na hakuna rekodi mpya iliyoandikwa DynamoDB.
• Webhook na huduma za uchakataji za Azure hazikupokea data mpya.
• Hakuna rekodi mpya iliyoundwa katika jedwali la data la Azure.
• Broker wa MQTT hakuchapisha ujumbe mpya.
• Matoleo yote matatu ya Unity yaliendelea kuonyesha thamani ya mwisho iliyopokelewa.

Katika mifumo ya wingu, rekodi ya mwisho ilihifadhiwa katika hifadhidata, huku katika MQTT thamani ya mwisho iliyoonyeshwa ilibaki kwenye kumbukumbu ya Unity. Hata hivyo, katika hali zote tatu, thamani iliyoonyeshwa haikuwakilisha hali mpya ya mazingira halisi.

Kwa nini hali iliyochakaa ni hatari?

Kwa sababu modeli ya pande tatu ya jengo inaendelea kufanya kazi na skrini haionyeshi kosa, mtumiaji anaweza kudhani mfumo uko wa sasa. Kwa mfano, thamani ya mwisho ya CO₂ katika darasa inaweza kuonekana kubaki katika kiwango kinachokubalika, wakati mazingira halisi yamebadilika kwa sababu ya uingizaji hewa usiotosha. Ikiwa msimamizi wa kituo hajui kwamba data ilipokelewa saa tatu au siku tatu zilizopita, anaweza kufanya uamuzi usio sahihi kuhusu uingizaji hewa au matumizi.

Kwa hiyo, utafiti unaonyesha kwamba uaminifu wa pacha dijitali una vipengele viwili tofauti:

• Usahihi wa anga: Vihisi na vipengele vya jengo vinaonyeshwa katika nafasi sahihi.
• Uhalali wa muda: Thamani inayoonyeshwa inawakilisha hali ya sasa ya mazingira halisi.

Usanifu unatofautianaje wakati wa kukatika?

Jedwali la “sifa za urejeshaji” la utafiti linatumia kwa MQTT maelezo ya kuendelea haraka data inapopatikana tena, na kwa wingu kuhifadhi mwendelezo wa kihistoria. Hata hivyo, muda wa urejeshaji kwa sekunde, urejeshaji wa ujumbe uliopotea au idadi ya kuunganisha tena havikupimwa.

Kwa nini usanifu mseto unapendekezwa?

Mapacha dijitali wengi wa majengo huhitaji mwonekano wa moja kwa moja pamoja na rekodi ya kihistoria. Kwa hiyo, badala ya MQTT pekee au wingu pekee, muundo unaotumia njia zote mbili pamoja unaweza kuzingatiwa:

• MQTT hutuma thamani ya moja kwa moja kwa Unity kwa ucheleweshaji mdogo.
• Ujumbe huo huo huhifadhiwa kwa wakati mmoja kwenye hifadhidata ya wingu.
• Unity hufuatilia muda wa mwisho ujumbe ulipowasili.
• Heartbeat inapokatika, hutoa onyo la hali iliyochakaa.
• Muunganisho wa moja kwa moja ukikatika, mtumiaji anaweza kuona data ya kihistoria; lakini inaonyeshwa wazi kwamba thamani hiyo si ya moja kwa moja.
• Zana za ufuatiliaji za wingu husaidia kuchunguza kama kukatika kumetokea katika kihisi, TTN, uchakataji au tabaka la programu.

Matokeo yanayoungwa mkono na utafiti

• Katika hali zilezile za kihisi na Unity, njia ya MQTT ilitoa muda wa kusasisha wa chini kuliko njia za AWS na Azure zilizochunguzwa.
• Njia zinazotegemea wingu zilitoa hifadhi ya kudumu na maswali ya kihistoria.
• Njia ya MQTT ilijengwa kwa vipengele vichache vya kati.
• Njia za wingu zilitoa maeneo mengi zaidi ya utambuzi kutokana na kumbukumbu, hifadhidata na rekodi za API.
• Telemetria mpya isipowasili, usanifu wote mitatu uliingia hali iliyochakaa katika Unity.
• Hifadhi ya kudumu haikufidia kutokuwepo kwa data mpya; ilihifadhi tu hali ya mwisho ya kihistoria.
• Katika mapacha dijitali wanaotumia MQTT, udhibiti wa uhalisia wa data na timeout lazima uendelezwe kando katika tabaka la programu.
• Uchaguzi wa njia ya data unapaswa kufanywa si kwa kuchelewa pekee, bali pia kwa kudumu na uwazi wa hitilafu.

Matokeo ambayo utafiti haujathibitisha

• Haijathibitishwa kwamba MQTT ni ya haraka kila wakati katika mitandao yote na matumizi yote ya mapacha dijitali.
• Haijaonyeshwa kwamba AWS au Azure kwa ujumla ni bora kuliko nyingine.
• Utafiti si benchmark huru ya gharama au ubora wa huduma ya AWS–Azure.
• Utendaji katika mifumo mikubwa yenye makumi ya maelfu ya vihisi haujapimwa.
• Upotevu wa sehemu ya paket, data isiyo ya kawaida, telemetria iliyochelewa au hitilafu ya kihisi kimoja havijajaribiwa kando.
• Sababu kuu ya kukatika kwa wiki tatu haijabainishwa.
• Jinsi watumiaji wanavyotafsiri data iliyochakaa haijapimwa kwa jaribio la wasimamizi wa vituo.
• Haijaonyeshwa kwa kiasi ni kwa kiwango gani uwazi wa hitilafu huongeza usalama au usahihi wa maamuzi.
• Usanifu mseto wa MQTT–wingu haukutekelezwa na kulinganishwa katika utafiti huu.
• Matokeo hayawezi kujumlishwa moja kwa moja kwa majengo yote, vihisi, mitandao na usanidi wa wingu katika nchi tofauti.

Mbinu na Matokeo ya Utafiti

Muundo wa utafiti

Vipimo vitano vya tathmini

Mpango wa uchambuzi wa kitakwimu

Utafiti unaeleza kwamba kwa sababu ya zaidi ya uchunguzi 200.000, usambazaji wa kuchelewa ulilinganishwa kwa mbinu zisizo za parametriki:

• Jaribio la Kruskal–Wallis H kwa ulinganisho wa jumla wa njia tatu.
• Jaribio la Mann–Whitney U kwa jozi za njia.
• Marekebisho ya Bonferroni kwa ulinganisho mwingi na \(\alpha=0{,}017\).
• Uwiano wa rank-biserial \(r\) kwa ukubwa wa athari ya vitendo.
• Median, IQR na ucheleweshaji wa asilimia 95 kama takwimu za maelezo.

Hata hivyo, majedwali ya matokeo hayana thamani ya Kruskal–Wallis H, degrees of freedom, thamani za Mann–Whitney U, p-values zilizorekebishwa au matokeo ya uwiano wa rank-biserial. Kwa hiyo, tathmini ya “tofauti ya kitakwimu” haiwezi kukaguliwa kwa uhuru kulingana na mpango wa uchambuzi uliotajwa katika utafiti. Usaidizi wa nambari uliopo unategemea hasa median, utofauti na thamani za ucheleweshaji wa asilimia 95.

Kutofautiana kwa kuripoti

• Thamani za utofauti katika Jedwali 3 ni tofauti na thamani za IQR katika aya inayofuata.
• Kichwa cha jedwali kinaonyesha IQR na utofauti wa muda wa kusasisha kama kipimo kilekile.
• Uhusiano kati ya muda wa swali wa sekunde 10 katika njia ya wingu na ucheleweshaji wa asilimia 95 ulioripotiwa haujaelezwa.
• Kwa njia tatu imepewa “upotevu wa data chini ya %1”, lakini denominator sahihi, idadi ya upotevu na tabaka ambako upotevu ulitokea havijatajwa.
• Ingawa inaelezwa kwamba kiasi cha data kilikuwa sawa katika njia zote tatu, jinsi viwango vya upotevu vilivyohesabiwa hakijaelezwa kwa kina.
• Uwazi wa hitilafu umeainishwa kama “juu”, “wa kati” au “chini”, lakini hakuna mbinu ya kawaida ya kutoa alama iliyowasilishwa.
• Sifa za urejeshaji zimeelezwa kwa ubora, lakini muda halisi wa kuunganisha tena au kurejesha haujapimwa.

Nguvu za utafiti

• Kuendesha usanifu wote mitatu kwa wakati mmoja katika hali zilezile za kihisi, TTN na Unity.
• Kutumia jengo halisi na miundombinu ya mawasiliano ya pamoja ya kampasi.
• Kufanya uchunguzi wa muda mrefu wa takriban miezi kumi.
• Kukusanya zaidi ya rekodi 200.000 za telemetria.
• Kuchunguza si tabia ya mfumo thabiti pekee, bali pia kukatika halisi kwa telemetria.
• Kulinganisha kudumu, ugumu wa usanifu na uangalizi pamoja na ucheleweshaji.
• Kufanya uhalali wa muda na hatari ya hali iliyochakaa ionekane katika mapacha dijitali.
• Kufafanua uwazi wa hitilafu kama kipimo tofauti cha tathmini ya usanifu.

Vikwazo vikuu

• Utafiti haujapitiwa na rika.
• Jengo moja na chumba kimoja zimetumika.
• Kuna vihisi sita tu na modeli moja ya kihisi.
• Vihisi vilitengeneza data kila dakika kumi pekee; telemetria ya masafa ya juu ya sekunde haikujaribiwa.
• Programu ya Unity na usanidi wa wingu umewekewa kikomo kwa mfano mmoja wa utekelezaji.
• Miundombinu ya mtandao haikutengwa kwa madhumuni ya udhibiti.
• Sababu kuu ya kukatika haijabainishwa.
• Majaribio yaliyodhibitiwa ya upotevu wa paket, ucheleweshaji au muunganisho wa vipindi hayakufanywa.
• Hakuna ulinganisho wa gharama, usalama, nishati na uwezo wa kupanuka.
• Matokeo ya majaribio ya kitakwimu yameripotiwa kwa upungufu.
• Hakuna kiungo cha hazina wazi kilichotolewa kwa data na msimbo wa uchambuzi.
• Uwazi wa hitilafu haujathibitishwa na wasimamizi halisi wa vituo.
• Mkabala mseto wa MQTT–wingu ni pendekezo la kazi ya baadaye pekee.

Uthibitishaji unaohitajika kabla ya kutumika Uturuki

1. Kusakinisha matumizi katika hospitali, kampasi, viwanda na majengo ya biashara katika maeneo tofauti ya hali ya hewa.
2. Kufanya majaribio ya mzigo na uwezo wa kupanuka kwa mamia au maelfu ya vihisi.
3. Kulinganisha Wi-Fi, NB-IoT, LTE-M na mitandao ya waya ya otomatiki za majengo pamoja na LoRaWAN.
4. Kutekeleza usanifu mseto unaochanganya mtiririko wa moja kwa moja wa MQTT na hifadhi ya wingu.
5. Kuingiza kwa kudhibitiwa kukatika, upotevu wa paket, ucheleweshaji na hitilafu za vihisi kwenye mfumo.
6. Kupima muda wa kutambua kukatika na kurejesha kwa sekunde.
7. Kujaribu muda wa sasisho la mwisho na maonyo ya hali iliyochakaa na wasimamizi wa vituo.
8. Kulinganisha gharama za wingu na seva ya ndani kwa gharama ya jumla ya umiliki.
9. Kutathmini kando KVKK, udhibiti wa ufikiaji, usimbaji fiche wa data na uthibitishaji wa vifaa.
10. Kushiriki data ghafi, msimbo wa Unity, mbinu ya kuchakata stempu ya muda na skripti za takwimu.

Maelezo ya Chanzo na Mbinu

Kichwa kamili cha asili cha utafiti: Evaluation of IoT Data Pipeline Architectures for Real-Time Digital Twins in Building Operations and Maintenance

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

Mpangilio wa waandishi: Muhammad Shahzad ni wa kwanza, Avar Almukhtar wa pili, Muhammad Younas wa tatu na Joe Tah wa nne.

Maelezo ya hati kuhusu taarifa za waandishi: Hakuna kizuizi cha waandishi na taasisi katika ukurasa wa kwanza wa toleo lililochunguzwa. Mpangilio wa waandishi umetolewa kulingana na taarifa rasmi ya rekodi ya SSRN. Metadata ya faili ina jina la Muhammad Shahzad pekee.

Mwandishi mwenza wa kwanza: Hakuna tamko la mchango sawa au uandishi wa kwanza wa pamoja katika toleo lililochunguzwa.

Mwandishi anayewajibika: Rekodi rasmi ya SSRN inaonyesha Muhammad Shahzad kama “Contact Author”. Hakuna alama ya nyota ya mwandishi anayewajibika wala barua pepe ya mawasiliano katika maandishi yaliyopitiwa.

Uhusiano wa kitaasisi unaoweza kuthibitishwa:

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

Kikomo cha uthibitishaji wa taasisi: Rekodi ya SSRN haitoi taasisi za waandishi. Taarifa zilizo hapo juu zimethibitishwa kutoka profaili rasmi za sasa za wafanyakazi na wanafunzi wa udaktari wa Oxford Brookes University; hakuna jedwali tofauti la ulinganifu wa taasisi katika toleo lililochunguzwa.

DOI:10.2139/ssrn.7193080

Jarida: Hakuna jina la jarida lililopitiwa na rika katika toleo lililochunguzwa.

Mchapishaji: Hakuna taarifa iliyothibitishwa ya mchapishaji wa mwisho. SSRN ni jukwaa la preprint na halipaswi kuchukuliwa kama mchapishaji wa mwisho wa kitaaluma wa utafiti huu.

Jukwaa la uchapishaji: SSRN.

Tarehe ya rekodi ya SSRN: 27 Julai 2026.

Mwaka wa uchapishaji: 2026.

Aina ya chanzo: Preprint ya utafiti wa usanifu wa vitendo, informatics ya ujenzi na usimamizi wa vifaa unaolinganishwa njia tatu za data za IoT katika mazingira ya jengo halisi.

Hali ya mapitio ya rika: Utafiti haujapitiwa na rika. Kila ukurasa una onyo la preprint na mapitio.

Chanzo rasmi:Rekodi rasmi ya utafiti wa SSRN.

Idhini ya maadili: Utafiti ulifanywa kwenye vihisi vya jengo na telemetria ya mfumo. Hakuna nambari tofauti ya kamati ya maadili au idhini ya maadili katika toleo lililochunguzwa.

Ufadhili: Hakuna tamko tofauti la ufadhili katika toleo lililochunguzwa.

Mgongano wa maslahi: Hakuna tamko tofauti la mgongano wa maslahi katika toleo lililochunguzwa.

Ufikiaji wa data na msimbo: Hakuna kiungo cha hazina wazi kilichotolewa kwa rekodi ghafi za telemetria, usanidi wa AWS na Azure, msimbo chanzo wa Unity na skripti za uchambuzi wa kitakwimu.

Tamko la akili bandia zalishi: Watafiti wameeleza kwamba walitumia Google NotebookLM kwa ajili ya kupitia vyanzo na Paperpal kwa msaada wa kuandika upya; walipitia na kuhariri maudhui yaliyotengenezwa na kuchukua jukumu la mwisho.

Maelezo haya ya Kituruki yaliandaliwa baada ya kuchunguza toleo la kurasa 51 la utafiti; maandishi, michoro ya usanifu, picha za jengo na mpangilio wa vihisi, majedwali ya tathmini, maelezo ya uchambuzi wa kitakwimu, matokeo ya kukatika na marejeo. Hakuna matokeo mapya ya utendaji kutoka nje ya utafiti yaliyoongezwa kwenye maudhui ya kisayansi. Vyanzo vya nje vilitumika tu kwa uthibitishaji wa kibibliografia wa kichwa, waandishi, DOI, tarehe ya rekodi ya SSRN, hali ya uchapishaji na uhusiano wa sasa wa kitaasisi.

Utafiti unaonyesha kwamba MQTT ni ya haraka zaidi katika hali thabiti; AWS na Azure hutoa faida za kudumu kwa data na uangalizi. Hata hivyo, njia zote ziliingia hali iliyochakaa wakati hakuna telemetria mpya. Matokeo yanaunga mkono kwamba katika mapacha dijitali halisi ya majengo, si kasi ya uwasilishaji data pekee bali pia uwezo wa kuonyesha wazi kwamba data si ya sasa tena ni hitaji kuu la usanifu.