Бул изилдөө имараттарды эксплуатациялоо жана тейлөөдө колдонулган реалдуу убакыттагы санарип эгиздерге сенсор маалыматын жеткирген үч ар башка IoT маалымат түтүгүн бирдей шарттарда салыштырат. Алты айлана-чөйрө сенсорунан келген температура, салыштырмалуу нымдуулук жана көмүр кычкыл газынын өлчөөлөрү The Things Network аркылуу бир убакта TTN–AWS–Unity, TTN–Azure–Unity жана TTN–MQTT–Unity түтүктөрүнө өткөрүлгөн. Бардык түтүктөр бир эле сенсорлорду, LoRaWAN инфраструктурасын, JSON маалымат түзүлүшүн, убакыт белгисин, он мүнөттүк өлчөө интервалын жана ошол эле Unity негизиндеги имарат санарип эгизин колдонгон. Ошентип салыштыруудагы негизги өзгөрмө сенсор менен Unityнин ортосундагы маалымат интеграция архитектурасы гана болгон.

Туруктуу телеметрия шарттарында MQTT түтүгү эң төмөн жаңыртуу убактысын жана эң жөнөкөй архитектураны берген. Медианалык жаңыртуу убактысы MQTT үчүн 0,9 секунд, AWS үчүн 2,8 секунд жана Azure үчүн 3,2 секунд деп берилген. Yüzde 95 кечигүү мааниси MQTTде 1,5 секунд, AWSде 4,6 секунд жана Azureда 5,1 секунд. MQTTнин түз publish–subscribe механизми маалыматты аралык сактоо же API суроосу жок Unityге жеткирүүгө мүмкүндүк берген. AWS жана Azure түтүктөрү болсо жогорку кечигүүнүн ордуна туруктуу маалымат сактоо, тарыхый жазууларды суроо, деталдуу журналдар жана системанын күчтүү байкалуучулугун камсыз кылган.

Болжол менен үч жума бою сенсор телеметриясы толугу менен үзүлгөн мезгилде архитектуралык айырмачылыктардын колдонмо катмарындагы таасири жоголгон. Үч түтүктүн баарында Unity акыркы алынган маанилерди көрсөтүүнү уланткан, бирок бул маанилер жаңырган эмес. Изилдөөчүлөр бул абалды “эскирген абал” деп аныкташат. Булут негизиндеги системаларда маалымат базасына жаңы жазуу келбеши, serverless функцияларынын иштебеши жана журналдардын токтошу үзгүлтүктү фондук катмарда көрүнүктүү кылган. MQTT түтүгүндө болсо жаңы билдирүү келбеши, убакыт белгисин текшерүү же heartbeat механизми жок болсо, колдонуучу интерфейсинде түз ката сигналы пайда кылган эмес.

Изилдөөнүн негизги жыйынтыгы — бир эле маалымат түтүгү бардык имарат санарип эгиз колдонмолору үчүн универсалдуу эң жакшы эмес. Ыкчам визуалдаштыруу жана төмөн архитектуралык татаалдык артыкчылыктуу болсо MQTT алдыга чыгат. Тарыхый анализ, тейлөө аудити, укуктук каттоо, маалыматты башкаруу жана ката иликтөө маанилүү болсо AWS же Azure сыяктуу туруктуу булут түтүктөрү артыкчылык берет. Изилдөөчүлөр чыныгы колдонмолордо MQTT негизиндеги ыкчам жеткирүүнү булуттагы сактоо жана мониторинг менен бириктирген гибрид архитектуралар ылайыктуураак болушу мүмкүн экенин белгилешет.

Түркия үчүн мааниси

Түркияда ооруканалар, университет кампустары, мамлекеттик имараттар, соода борборлору, мейманканалар, заводдор жана маалымат борборлору үчүн иштелип чыккан санарип эгиздерде ушундай эле архитектура тандоо маселеси бар. Ички абанын сапатын же энергия керектөөнү жандуу көзөмөлдөө үчүн төмөн кечигүүчү MQTT агымы пайдалуу болушу мүмкүн, ал эми тейлөө тарыхы, ченемдик жазуулар, энергия салыштыруулары жана бузулуу иликтөөлөрү үчүн туруктуу булут сактагычы керек.

Түркияда курула турган системада маалымат келгенде канчалык тез көрсөтүлөрү гана эмес, маалымат келбей калганда бул колдонуучуга кантип билдирилери да дизайн критерийи болушу керек. Unity, веб-панель же имарат башкаруу системасында акыркы жаңыртуу убактысы, маалыматтын жашы, түстүү эскирген-маалымат эскертүүсү, сенсор heartbeat сигналы жана timeout коңгуроосу көрсөтүлүшү керек. Өзгөчө көмүр кычкыл газы, температура, нымдуулук, басым же жабдуу абалы сыяктуу эксплуатациялык чечимдерге таасир берген маанилер актуалдуу эмес экени ачык билдирилмейинче санарип эгиз чыгыштары ишенимдүү эксплуатациялык маалымат катары колдонулбашы керек.

Изилдөөнүн жыйынтыктарын Түркиядагы бардык имарат жана тармак инфраструктураларына түз жалпылоого болбойт. Ар башка LoRaWAN шлюздары, мобилдик оператор байланыштары, жергиликтүү IoT платформалары, имарат автоматташтыруу протоколдору, кыйла көп сенсорлор, башка маалымат өндүрүү жыштыктары жана чыныгы тейлөө сценарийлери менен кайра текшерүү жүргүзүлүшү керек.

Изилдөөнүн негизги көйгөйү эмне?

Имарат санарип эгизи үч өлчөмдүү моделден гана турбайт. Санарип модель физикалык имараттын актуалдуу абалын чагылдырышы үчүн сенсордук өлчөөлөр үзгүлтүксүз санарип чөйрөгө жетиши керек. Температура, нымдуулук, көмүр кычкыл газы, энергия керектөө же жабдуу абалы жаңырбаса, үч өлчөмдүү модель визуалдык түрдө иштей бериши мүмкүн; бирок физикалык имарат менен убакыттык байланышын жоготот.

Сенсор менен санарип эгиздин ортосунда адатта бир нече системалык катмар бар:

• Физикалык сенсор жана өлчөө катмары.
• LoRaWAN, Wi-Fi же башка байланыш катмары.
• Жабдууну каттоо, маалыматты чечмелөө жана багыттоо менен камсыз кылган тармак башкаруу катмары.
• Булут же билдирүү брокерин колдонгон маалымат интеграция катмары.
• Unity сыяктуу санарип эгиз колдонмо катмары.
• Объект менеджери колдонгон иш тактасы, виртуалдык реалдуулук же аралаш реалдуулук интерфейси.

Изилдөөнүн изилдөө боштугу — санарип эгиз адабияты көбүнчө моделдөө, BIM интеграциясы, визуалдаштыруу жана аналитикага көңүл буруп, сенсор маалыматын колдонмого жеткирген аралык маалымат түтүгүнүн жүрүм-турумун экинчи даражадагы ишке ашыруу тандоосу катары карашы. Изилдөөчүлөр маалымат түтүгү кечигүүгө, маалыматтын туруктуу сакталышына, системалык татаалдыкка, ката диагностикасына жана санарип эгиздин актуалдуулугуна түз таасир берет деп ырасташат.

Үч изилдөө суроосу

1. Булут борборлуу жана агымга негизделген IoT маалымат түтүктөрүн айырмалаган архитектуралык өзгөчөлүктөр кайсылар жана бул өзгөчөлүктөр бир эле санарип эгиз ичиндеги маалымат таралышына кантип таасир берет?
2. Система туруктуу телеметриядан телеметриянын жоктугуна өткөндө интеграция архитектурасынын таасири кантип өзгөрөт?
3. Кечигүү, туруктуу сактоо, байкалуучулук жана бузулуу ачыктыгы сыяктуу критерийлер имарат санарип эгиздеринде маалымат түтүгүн тандоону кантип багытташы керек?

Булут менен MQTT ыкмасынын негизги айырмасы

Изилдөөнүн 2. бетиндеги 1.1-сүрөт сенсор маалыматы санарип эгизге эки альтернативдүү жол менен жетерин көрсөтөт. Булут түтүгүндө маалымат сенсордон булут платформасына жөнөтүлөт, иштетилет, туруктуу маалымат базасында сакталат жана кийин API аркылуу Unity тарабынан алынат. MQTT түтүгүндө сенсор маалыматы билдирүү брокерине жарыяланып, Unity тиешелүү темага жазылып билдирүүнү түз кабыл алат.

Катмарлуу көз карандылык модели

11. беттеги 3.1-сүрөт IoT колдогон санарип эгизди алты катмарлуу түзүлүш катары көрсөтөт:

1. Физикалык сезүү катмары: Сенсорлор убакыт белгиси бар өлчөөлөрдү чыгарат.
2. Байланыш катмары: Сигнал LoRaWAN же Wi-Fi аркылуу өткөрүлөт.
3. Тармак башкаруу катмары: Жабдуу каттоосу, payload чечмелөө жана TTN багыттоосу жүргүзүлөт.
4. Маалымат интеграция катмары: Булут же MQTT архитектурасы маалыматты колдонмо үчүн даярдайт.
5. Колдонмо катмары: Unity маалыматты үч өлчөмдүү имарат моделине байланыштырат.
6. Колдонуучу өз ара аракет катмары: Объект менеджери маалыматты экран, виртуалдык реалдуулук же аралаш реалдуулук интерфейси аркылуу көрөт.

Моделдин негизги түшүнүгү — вертикалдык көз карандылык. Төмөнкү катмарлардын иштеши жогорку катмарларга телеметриянын ийгиликтүү жеткирилишине көз каранды. Эң өнүккөн Unity визуалдаштыруусу же булут инфраструктурасы да сенсор таптакыр өндүрбөгөн же TTNге жетпеген жаңы маалыматты кайра түзө албайт.

Мүмкүнчүлүк режими жана көз карандылык режими

13. беттеги 3.2-сүрөт изилдөөнүн эки эксплуатациялык режимин көрсөтөт.

Мүмкүнчүлүк режими: Туруктуу телеметрия

Маалымат үзгүлтүксүз келгенде архитектуралардын өзүнө таандык артыкчылыктары ачылат. Булут негизиндеги түтүктөр туруктуу маалымат, башкаруу жана тарыхый жазуу берет, ал эми MQTT төмөн кечигүү, түз жаңыртуу жана азыраак аралык компонент менен камсыз кылат.

Көз карандылык режими: Телеметрия жоктугу

Жогорку катмарга жаңы телеметрия келбегенде колдонмо катмарындагы жүрүм-турумдар бири-бирине жакындайт. Бардык түтүктөр акыркы алынган маанини көрсөтүүнү улантат. Бул этапта баалоо суроосу “кайсы түтүк ылдамыраак?” дегенден чыгып, “үзгүлтүк канчалык ачык көрүнөт жана кайсы катмарда диагноз коюуга болот?” деген суроого айланат.

Бузулуу ачыктыгы деген эмне?

Изилдөөчүлөр бузулуу ачыктыгын телеметриянын жоктугу же бузулушу журналдар, жаңыртуу жүрүм-туруму, маалымат базасынын кыймылы же колдонуучу интерфейси аркылуу канчалык ачык көрүнөрү катары аныкташат.

Бузулуу ачыктыгы бузулууга чыдамдуулук же калыбына келүү менен бирдей эмес. Система телеметрия агымын кайра баштай албай калышы мүмкүн; бирок маалымат актуалдуу эмес экенин ачык белгилеп, колдонуучу эски маанини жаңы деп кабыл албашына жардам берет.

Сунушталган негизги механизмдер:

• Акыркы ийгиликтүү маалымат алуу убактысын көрсөтүү.
• Учурдагы маалыматтын жашын секунд же мүнөт менен эсептөө.
• Белгиленген убакыттан эски маалыматтар үчүн түстүү эскертүү берүү.
• Сенсор же маалымат түтүгүнүн heartbeat билдирүүлөрүн көзөмөлдөө.
• Жаңы билдирүү келбегенде timeout коңгуроосун чыгаруу.
• Unity экранында “актуалдуу”, “кечиккен” жана “эскирген” абалдарды бөлүү.
• Булут функциясынын, маалымат базасынын, API жана MQTT байланышынын абалын өзүнчө көзөмөлдөө.

Талаа орнотуусу

Изилдөө Oxford Brookes Universityдеги New Headington Hill Building ичинде тандалган изилдөө бөлмөсүндө жүргүзүлгөн. 16. беттеги 4.1a-сүрөт имаратты, 4.1b-сүрөт алты сенсордун бөлмөдөгү жайгашуусун көрсөтөт. Сенсорлор бир чекитке топтолгон эмес; бөлмөнүн ар башка аймактарындагы ички чөйрөнүн өзгөрүшүн байкоо үчүн таралган.

Көзөмөлдөнгөн салыштыруу кантип камсыз кылынган?

Үч түтүктүн баары бир эле сенсор маалыматын TTNден бир убакта алган. Сенсорлор, жөнөтүү интервалы, шлюз, TTN payload чечмелөө операциясы, JSON талаалары, убакыт белгиси жана Unity сахнасы өзгөртүлгөн эмес. Ошентип AWS, Azure жана MQTT ортосунда байкалган айырмачылыктар маалымат интеграция катмарынан келип чыккан деп кабыл алынган.

TTN кабыл алуу убакыт белгиси үч түтүк үчүн жалпы баштапкы убакыт катары колдонулган. Жаңыртуу убактысы билдирүү TTN тарабынан кабыл алынган учур менен тиешелүү маани Unityде көрсөтүлгөн учурдун ортосундагы убакыт катары аныкталган.

TTN–AWS–Unity архитектурасы

24. беттеги 5.2-сүрөт AWS түтүгүн физикалык сенсордон Unity экранына чейин катмарлар боюнча көрсөтөт:

1. Сенсор LoRaWAN uplink билдирүүсүн жөнөтөт.
2. Шлюз билдирүүнү TTNге өткөрөт.
3. TTN маалыматты webhook аркылуу AWS API Gatewayге жөнөтөт.
4. Lambda функциясы JSON маалыматын текшерип, иштетет.
5. Маалымат DynamoDB ичинде туруктуу сакталат.
6. Unity экинчи API Gateway жана Lambda функциясы аркылуу акыркы жазууларды сурайт.
7. C# скрипттери маанини тиешелүү үч өлчөмдүү сенсор көрсөткүчүнө жазат.

Бул түзүлүш тарыхый жазууларды сактап, ар бир этапта из калтыра алат. Анын ордуна эки API шлюзу, иштетүү функциялары, маалымат базасы жана Unity суроо катмары көбүрөөк конфигурация жана көз карандылык жаратат.

TTN–Azure–Unity архитектурасы

25. беттеги 5.3-сүрөт Azure түтүгү окшош туруктуу сактоого багытталган моделди башка кызматтар менен ишке ашырарын көрсөтөт:

1. TTN телеметрияны webhook аркылуу Azure App Service ичиндеги кабыл алуучуга жөнөтөт.
2. ASP.NET Core негизиндеги компонент маалыматты иштетет.
3. Жазуу Azure маалымат таблицасында сакталат.
4. Unity REST API аркылуу эң жаңы маанилерди сурайт.
5. Unity C# скрипттери үч өлчөмдүү моделдеги сенсор тексттерин жаңыртат.

Изилдөөдө AWS менен Azure ортосундагы негизги архитектуралык ыкма бирдей экени айтылат. Azure ишке ашыруусу бир нече кызмат интерфейсинин ортосунда координацияны талап кылышы каралган орнотууда жогорку конфигурация жүгүн жараткан. Бул жыйынтык жалпы Azure–AWS артыкчылык рейтинги катары берилген эмес.

TTN–MQTT–Unity архитектурасы

27. беттеги 5.4-сүрөт түзүрөөк маалымат түтүгүн көрсөтөт:

1. Сенсор билдирүүсү LoRaWAN аркылуу TTNге жетет.
2. TTN билдирүүнү MQTT серверине багыттайт.
3. Unity тиешелүү MQTT темасына жазылат.
4. Билдирүү жарыяланганда Unity ичиндеги MQTT менеджери JSON маалыматын иштетет.
5. Маани күтүүсүз же API суроосуз тиешелүү визуалга өткөрүлөт.

Бул түзүлүштө маалымат базасы жок. Билдирүү алынган учурда иштетилет; кийин тарыхый суроо керек болсо өзүнчө сактоо компоненти кошулушу керек. Байланышты көзөмөлдөө, кайра туташуу жана маалыматтын актуалдуулугун аныктоо жоопкерчилиги негизинен Unity колдонмосуна өтөт.

Туруктуу телеметрия жыйынтыктары

MQTTнин AWSге салыштырмалуу медианалык жаңыртуу убактысы 1,9 секундга, Azureга салыштырмалуу 2,3 секундга төмөн. Бул айырма протоколдун атынан гана келип чыкпайт. MQTT түтүгүндө аралык маалымат иштетүү, туруктуу сактоо жана мезгилдүү API суроосу жок болгондуктан архитектуралык жол кыскарган.

AWS менен Azure жайыраак болгонуна карабастан тарыхый маанилерди суроо, маалымат агымын ар башка этаптарда текшерүү, бузулуу кайсы катмарда пайда болгонун иликтөө жана тейлөө жазууларын сактоо жагынан күчтүүрөөк.

Үч жумалык телеметрия үзгүлтүгүндө эмне болду?

Үзгүлтүк мезгилинде TTNге сенсор uplink билдирүүсү жеткен эмес. Натыйжада:

• AWS webhook жаңы payload алган эмес.
• AWS Lambda функциялары иштеген эмес жана DynamoDBге жаңы жазуу жазылган эмес.
• Azure webhook жана иштетүү кызматтары жаңы маалымат алган эмес.
• Azure маалымат таблицасында жаңы жазуу пайда болгон эмес.
• MQTT broker жаңы билдирүү жарыялаган эмес.
• Unityнин үч версиясы тең акыркы алынган маанини көрсөтүүнү уланткан.

Булут системаларында акыркы жазуу маалымат базасында сакталып калган, MQTTде болсо Unity эс тутумундагы акыркы көрсөтүлгөн маани калган. Бирок үч учурда тең көрсөтүлгөн маани физикалык чөйрөнүн жаңы абалын билдирген эмес.

Эскирген абал эмне үчүн коркунучтуу?

Үч өлчөмдүү имарат модели иштей бергени жана экран ката бербегени үчүн колдонуучу система актуалдуу деп ойлошу мүмкүн. Мисалы, аудиториядагы акыркы CO₂ мааниси кабыл алынуучу деңгээлде көрүнүп турса, чыныгы чөйрө желдетүү жетишсиздигинен өзгөргөн болушу мүмкүн. Объект менеджери маалымат үч саат же үч күн мурда алынганын билбесе, туура эмес желдетүү же колдонуу чечимин кабыл алышы мүмкүн.

Ошондуктан изилдөө санарип эгиз ишенимдүүлүгүнүн эки өзүнчө компоненти бар экенин көрсөтөт:

• Мейкиндик тактыгы: Сенсор жана имарат элементтери туура жерде көрсөтүлүшү.
• Убакыттык жарактуулук: Көрсөтүлгөн маани физикалык чөйрөнүн актуалдуу абалын билдириши.

Үзгүлтүк учурунда архитектуралар кантип айырмаланат?

Изилдөөнүн “калыбына келүү өзгөчөлүктөрү” таблицасы MQTT үчүн маалымат кайра башталганда тез улануу, булут үчүн тарыхый үзгүлтүксүздүк сакталат деген түшүнүктөрдү колдонот. Бирок секунд менен калыбына келүү убактысы, жоголгон билдирүүлөрдү толуктоо же кайра туташуу саны өлчөнгөн эмес.

Гибрид архитектура эмне үчүн сунушталат?

Имарат санарип эгиздеринин көбү жандуу көрүнүштү да, тарыхый жазууну да талап кылат. Ошондуктан MQTT гана же булут гана эмес, эки түтүктү чогуу колдонгон түзүлүш каралышы мүмкүн:

• MQTT жандуу маанини төмөн кечигүү менен Unityге жөнөтөт.
• Ошол эле билдирүү бир убакта булут маалымат базасына жазылат.
• Unity билдирүүнүн акыркы келген убактысын көзөмөлдөйт.
• Heartbeat токтогондо эскирген абал эскертүүсүн берет.
• Жандуу байланыш үзүлсө колдонуучу тарыхый маалыматты көрө алат; бирок тарыхый маани жандуу эмес экени ачык көрсөтүлөт.
• Булут мониторинг куралдары үзгүлтүк сенсордо, TTNде, иштетүүдө же колдонмо катмарында болгонун иликтөөгө жардам берет.

Изилдөө колдогон жыйынтыктар

• Бирдей сенсор жана Unity шарттарында MQTT түтүгү каралган AWS жана Azure түтүктөрүнө караганда төмөн жаңыртуу убактысын берген.
• Булут борборлуу түтүктөр туруктуу сактоо жана тарыхый суроо мүмкүнчүлүгүн берген.
• MQTT түтүгү азыраак аралык компонент менен курулган.
• Булут түтүктөрү журнал, маалымат базасы жана API жазуулары аркылуу көбүрөөк диагностика чекиттерин берген.
• Жаңы телеметрия келбегенде үч архитектура тең Unityде эскирген абалга өткөн.
• Туруктуу сактоо жаңы маалымат жоктугун компенсациялаган эмес; акыркы тарыхый абалды гана сактаган.
• MQTT колдонгон санарип эгиздерде актуалдуулук жана timeout текшерүүсүн колдонмо катмарында өзүнчө иштеп чыгуу керек.
• Маалымат түтүгүн тандоо кечигүүгө гана эмес, туруктуу сактоо жана бузулуу ачыктыгына да негизделиши керек.

Изилдөө далилдебеген жыйынтыктар

• MQTT бардык тармактарда жана бардык санарип эгиз колдонмолорунда дайыма ылдамыраак экени далилденген эмес.
• AWS же Azure жалпысынан бири-биринен жакшы экени көрсөтүлгөн эмес.
• Изилдөө көз карандысыз AWS–Azure чыгым же кызмат сапаты benchmarkы эмес.
• Он миңдеген сенсор бар чоң масштабдагы системаларда өндүрүмдүүлүк өлчөнгөн эмес.
• Жарым-жартылай пакет жоготуусу, тартипсиз маалымат, кечиккен телеметрия же бир сенсордун бузулушу өзүнчө тесттен өткөрүлгөн эмес.
• Үч жумалык үзгүлтүктүн түпкү себеби аныкталган эмес.
• Колдонуучулар эскирген маалыматты кантип чечмелери объект менеджерлеринин эксперименти менен өлчөнгөн эмес.
• Бузулуу ачыктыгы коопсуздукту же чечим тактыгын канчалык жогорулатаары сандык түрдө көрсөтүлгөн эмес.
• Гибрид MQTT–булут архитектурасы бул изилдөөдө ишке ашырылып салыштырылган эмес.
• Жыйынтыктар ар башка өлкөлөрдөгү бардык имарат, сенсор, тармак жана булут конфигурацияларына түз жалпыланбайт.

Изилдөөнүн Ыкмасы жана Табылгалары

Изилдөө дизайны

Баалоонун беш өлчөмү

Статистикалык анализ планы

Изилдөө 200.000’ден ашык байкоо болгондуктан кечигүү бөлүштүрүлүштөрү параметрдик эмес ыкмалар менен салыштырылганын айтат:

• Үч түтүктү жалпы салыштыруу үчүн Kruskal–Wallis H тести.
• Түтүк жуптары үчүн Mann–Whitney U тести.
• Көп салыштыруу үчүн Bonferroni түзөтүүсү жана \(\alpha=0{,}017\).
• Практикалык таасир өлчөмү үчүн rank-biserial корреляция \(r\).
• Сүрөттөөчү статистика катары медиана, IQR жана yüzde 95 кечигүү.

Бирок жыйынтык таблицаларында Kruskal–Wallis H мааниси, эркиндик даражасы, Mann–Whitney U маанилери, түзөтүлгөн p маанилери же rank-biserial корреляция жыйынтыктары жок. Ошондуктан “статистикалык жактан айырмаланат” деген баа изилдөөдө айтылган анализ планы боюнча көз карандысыз текшерилбейт. Учурдагы сандык далил негизинен медиана, өзгөрмөлүүлүк жана yüzde 95 кечигүү маанилерине таянат.

Отчеттук шайкешсиздиктер

• 3-таблицадагы өзгөрмөлүүлүк маанилери менен кийинки абзацтагы IQR маанилери айырмаланат.
• Таблица аталышы IQR менен жаңыртуу интервалынын өзгөрмөлүүлүгүн бир эле өлчөм сыяктуу көрсөтөт.
• Булут түтүгүнүн 10 секунддук суроо интервалы менен билдирилген yüzde 95 кечигүүлөрдүн байланышы түшүндүрүлгөн эмес.
• Үч түтүккө “%1’ден аз маалымат жоготуусу” берилген, бирок так бөлүүчү, жоготуу саны жана жоготуу кайсы катмарда болгону көрсөтүлгөн эмес.
• Маалымат көлөмү үч түтүктө бирдей деп айтылганы менен жоготуу катыштары кантип эсептелгени деталдуу берилген эмес.
• Бузулуу ачыктыгы “жогорку”, “орто” же “төмөн” деп классификацияланган, бирок стандарттык упай берүү ыкмасы жок.
• Калыбына келүү өзгөчөлүктөрү сапаттык түшүндүрүлгөн, чыныгы кайра туташуу же калыбына келүү убактысы өлчөнгөн эмес.

Изилдөөнүн күчтүү жактары

• Үч архитектураны бирдей сенсор, TTN жана Unity шарттарында бир убакта иштетүү.
• Чыныгы имарат жана бөлүшүлгөн кампус байланыш инфраструктурасын колдонуу.
• Болжол менен он айлык узак мөөнөттүү байкоо жүргүзүү.
• 200.000’ден ашык телеметрия жазуусун чогултуу.
• Туруктуу система жүрүм-турумун гана эмес, чыныгы телеметрия үзгүлтүгүн да изилдөө.
• Кечигүүдөн тышкары туруктуу сактоо, архитектуралык татаалдык жана байкалуучулукту салыштыруу.
• Санарип эгиздерде убакыттык жарактуулук жана эскирген абал коркунучун көрүнүктүү кылуу.
• Бузулуу ачыктыгын өзүнчө архитектуралык баалоо өлчөмү катары аныктоо.

Негизги чектөөлөр

• Изилдөө рецензиядан өтө элек.
• Бир имарат жана бир бөлмө колдонулган.
• Болгону алты сенсор жана бир сенсор модели бар.
• Сенсорлор он мүнөттө бир маалымат чыгарган; секунддук жогорку жыштыктагы телеметрия сыналган эмес.
• Unity колдонмосу жана булут конфигурациялары бир ишке ашыруу мисалы менен чектелген.
• Тармак инфраструктурасы көзөмөл үчүн изоляцияланган эмес.
• Үзгүлтүктүн түпкү себеби аныкталган эмес.
• Көзөмөлдөнгөн пакет жоготуусу, кечигүү же үзгүлтүктүү байланыш эксперименттери жүргүзүлгөн эмес.
• Чыгым, коопсуздук, энергия жана масштабдалыш салыштыруусу жок.
• Статистикалык тест жыйынтыктары толук эмес отчеттолгон.
• Маалымат жана анализ коду үчүн ачык репозиторий шилтемеси берилген эмес.
• Бузулуу ачыктыгы чыныгы объект менеджерлери менен текшерилген эмес.
• Гибрид MQTT–булут ыкмасы келечектеги иш сунушу гана.

Түркияда колдонууга чейин керектүү текшерүүлөр

1. Ар башка климаттык аймактарда оорукана, кампус, завод жана коммерциялык имарат колдонмолорун орнотуу.
2. Жүздөгөн же миңдеген сенсор менен жүк жана масштабдалыш тестин жүргүзүү.
3. LoRaWANдан тышкары Wi-Fi, NB-IoT, LTE-M жана зымдуу имарат автоматташтыруу тармактарын салыштыруу.
4. MQTT жандуу агымын булут сактагычы менен бириктирген гибрид архитектураны ишке ашыруу.
5. Үзгүлтүк, пакет жоготуусу, кечигүү жана сенсор бузулуусун көзөмөлдөнгөн түрдө системага киргизүү.
6. Үзгүлтүктү аныктоо жана калыбына келүү убактысын секунд менен өлчөө.
7. Акыркы жаңыртуу убактысы жана эскирген абал эскертүүлөрүн объект менеджерлери менен колдонуучу тестинен өткөрүү.
8. Булут жана жергиликтүү сервер чыгымдарын жалпы ээлик кылуу чыгымы менен салыштыруу.
9. KVKK, жеткиликтүүлүк көзөмөлү, маалымат шифрлөө жана жабдуу аутентификациясын өзүнчө баалоо.
10. Чийки маалымат, Unity коду, убакыт белгисин иштетүү ыкмасы жана статистикалык скрипттерди бөлүшүү.

Булак жана Ыкма Жөнүндө Эскертүү

Изилдөөнүн толук оригинал аталышы: Evaluation of IoT Data Pipeline Architectures for Real-Time Digital Twins in Building Operations and Maintenance

Авторлор: Muhammad Shahzad; Avar Almukhtar; Muhammad Younas; Joe Tah.

Авторлордун ирети: Muhammad Shahzad биринчи, Avar Almukhtar экинчи, Muhammad Younas үчүнчү жана Joe Tah төртүнчү автор.

Автор маалыматы боюнча документтик эскертүү: Каралган версиянын биринчи бетинде автор жана мекеме блогу жок. Авторлордун ирети SSRN расмий каттоо маалыматына ылайык берилген. Файл metadataсында Muhammad Shahzad гана көрсөтүлгөн.

Тең биринчи автор: Тең салым же тең биринчи автор жөнүндө билдирүү каралган версияда жок.

Жооптуу автор: SSRN расмий каттоосу Muhammad Shahzadды “Contact Author” катары көрсөтөт. Каралган текстте жооптуу автор жылдызчасы же байланыш электрондук почта дареги жок.

Текшерилген мекемелик байланыштар:

• Muhammad Shahzad — School of the Built Environment, Oxford Brookes University, Бириккен Падышалык.
• Avar Almukhtar — School of the Built Environment, Oxford Brookes University, Бириккен Падышалык.
• Muhammad Younas — School of Engineering, Computing and Mathematics, Oxford Brookes University, Бириккен Падышалык.
• Joe Tah — Professor of Project Management, Oxford Brookes University, Бириккен Падышалык.

Мекемени текшерүү чеги: SSRN каттоосунда авторлордун мекемелери берилген эмес. Жогорудагы маалымат Oxford Brookes Universityнин расмий учурдагы кызматкер жана докторант профилдеринен текшерилген; каралган версияда өзүнчө мекемелик дал келтирүү таблицасы жок.

DOI:10.2139/ssrn.7193080

Журнал: Рецензияланган журналдын аты каралган версияда жок.

Басмакана: Бекитилген акыркы басмакана маалыматы жок. SSRN preprint платформасы жана бул изилдөөнүн акыркы академиялык басмаканасы катары каралбашы керек.

Жарыялоо платформасы: SSRN.

SSRN каттоо датасы: 27 Июль 2026.

Жарыяланган жыл: 2026.

Булактын түрү: Чыныгы имарат чөйрөсүндө үч IoT маалымат түтүгүн салыштырган колдонмо архитектура, курулуш информатикасы жана объектти башкаруу изилдөөсүнүн preprintи.

Рецензия абалы: Изилдөө рецензиядан өтө элек. Ар бир бетте preprint жана рецензия эскертүүсү бар.

Расмий булак:SSRN расмий изилдөө каттоосу.

Этикалык жактыруу: Изилдөө имарат сенсорлору жана системалык телеметрия менен жүргүзүлгөн. Өзүнчө этика комитети же этикалык жактыруу номери каралган версияда жок.

Каржылоо: Өзүнчө каржылоо билдирүүсү каралган версияда жок.

Кызыкчылыктардын кагылышы: Өзүнчө кызыкчылыктардын кагылышы билдирүүсү каралган версияда жок.

Маалымат жана кодго жетүү: Чийки телеметрия жазуулары, AWS жана Azure конфигурациялары, Unity булак коду жана статистикалык анализ скрипттери үчүн ачык репозиторий шилтемеси каралган версияда берилген эмес.

Генеративдик жасалма интеллект билдирүүсү: Изилдөөчүлөр булактарды кароо үчүн Google NotebookLM, кайра формулировкалоо колдоосу үчүн Paperpal колдонушканын; түзүлгөн мазмунду карап чыгып редакциялашканын жана акыркы жоопкерчиликти өздөрүнө алганын билдиришкен.

Бул кыргызча түшүндүрмө изилдөөнүн 51 беттик версиясынын тексти, архитектуралык диаграммалары, имарат жана сенсор жайгашуу сүрөттөрү, баалоо таблицалары, статистикалык анализ түшүндүрмөлөрү, үзгүлтүк табылгалары жана булактар тизмеси каралып даярдалды. Илимий мазмунга изилдөөнүн сыртынан жаңы өндүрүмдүүлүк жыйынтыгы кошулган жок. Тышкы булактар аталыш, авторлор, DOI, SSRN каттоо датасы, жарыялоо абалы жана учурдагы мекемелик байланыштарды библиографиялык текшерүү үчүн гана колдонулган.

Изилдөө MQTT туруктуу шарттарда ылдамыраак экенин, AWS жана Azure болсо маалыматты туруктуу сактоо жана байкалуучулук артыкчылыгын берерин көрсөтөт. Бирок бардык түтүктөр жаңы телеметрия жок болгондо эскирген абалга өткөн. Жыйынтыктар чыныгы имарат санарип эгиздеринде маалымат жеткирүү ылдамдыгы гана эмес, маалымат эми актуалдуу эмес экенин ачык көрсөтө алуу жөндөмү да негизги дизайн талабы экенин колдойт.