1. Loyihaning foni va Modbus TCP tanlash sabablari
IoT loyihasini amalga oshirishda eng avval duch kelgan vazifa - maydondagi turli inshootlardan ma'lumotlarni ishonchli ravishda yig'ish edi.
Maydonlarda PLC, sensorlar, kontroller va boshqa turli ishlab chiqaruvchilar va aloqa usullari bilan bog'liq gibrid uskunalar aralashgan bo'lib, har bir uskunaning holat ma'lumotlarini real vaqt rejimida to'plab, yuqori platformaga uzatish kerak edi.
Sanoat maydonlarida OPC-UA, LS XGT kabi turli xil sanoat protokollari qo'llaniladi. Ulardan eng keng tarqalgani bo'lgan Modbus TCP asosidagi aloqa bo'yicha IoT chet aloqa drayveri implementatsiya qilish tajribasini bo'lishaman.
Modbus oddiy tuzilishga ega bo'lib, sanoat muhitida uzoq vaqt davomida ishlatilgan asosiy sanoat protokoli hisoblanadi. Ayniqsa, ishlab chiqaruvchiga qaramay turli xil uskunalarda qo'llab-quvvatlanishi sababli, dalada qo'llanilishi juda yuqori.
Avvalgi Modbus RTU seriyali (Serial) asosida ishlagan bo'lsa, Modbus TCP TCP/IP asosidagi Ethernet muhitida ishlagani uchun tezlik va kengaytirilish borasida afzalliklariga ega.
Loyihada o'nlab zavodlardan bir necha millisekund darajasida emas, sekundlar orasida ma'lumotlarni to'plash zarur bo'lganligi sababli, tarmoq samaradorligi va ishlov berish samaradorligi juda muhim edi.
Xususan, qirralar muhitida har qanday vaqtda tarmoq aloqasi uzilishi mumkinligi sababli, tarmoq offlayn holatda to'plangan ma'lumotlar ham yo'qolmasligi kerak edi. Shuningdek, qirra muhitining xususiyatidan kelib chiqib, hisoblash resurslari cheklanganligi sababli, CPU foydalanilishi va xotira foydalanilishi ham hisobga olinishi zarur edi. Natijada loyiha quyidagi maqsadlar asosida aloqa drayverini loyihalashtirdi.
- Millisekundda yuqori tezlikda ma'lumot to'plash
- Tarmoq uzilishi holatida ma'lumot yo'qolishini oldini olish
- Real vaqt ma'lumot uzatish tuzilmasini amalga oshirish
- Cheklangan chekka resurslardan samarali foydalanish
- Jihozlarni boshqarish uchun barqaror Write qo'llab-quvvatlash
- Yuqori platformalar bilan moslashuvchan integratsiya tuzilishini ta'minlash
Ushbu loyiha faqat Modbus paketini parslash darajasida emas, balki haqiqiy sanoat muhitida ishonchli ishlashi mumkin bo'lgan ma'lumot to'plash arxitekturasini ishlab chiqish jarayonidir.
2. Modbus TCP protokoli tushunish
Modbus TCP protokoli tuzilmalarini tushunishimiz kerak edi, amalga oshirish jarayoniga kirishishdan oldin.
Modbus asosan Mijoz - Server tuzilmasiga amal qiladi. Odatda Master (Mijoz) so'rov (Request) yuboradi va Slave (Server) javob (Response) qaytaradi.
Masalan, PLC yoki sensor uskunalari Slave roli o'ynaydi, IoT Gateway yoki ma'lumotlarni yig'ish dasturlari esa Master roli o'ynaydi. Modbus ma'lum manzilga (Address) saqlangan qiymatlarni o'qish yoki yozish usuli bilan ishlaydi.
Keng tarqalgan quyidagi funksional kodlar (Function Code) ishlatilgan.
- Holding Register Read
- Input Register Read
- Coil Read
- Single Register Write
- Bir nechta ro'yxatdan o'tkazish yozuvi
Loyihada Holding Register asosidagi ma'lumotlarni ko'rish va ayrim uskunalarni boshqarish uchun yozish funksiyasidan ham foydalanildi. Modbus TCP, mavjud Modbus RTU paketining old qismiga MBAP (Modbus Application Protocol) sarlavhasini qo'shilgan tuzilmasidir.
MBAP Header da quyidagi ma'lumotlar mavjud.
- Transaction Identifier
- Protokol Identifikatori
- Uzunlik
- Birlik identifikatori
Bu orqali TCP asosidagi muhitlarda bir nechta so'rovlarni muvaffaqiyatli ajratish mumkin bo'ldi. Ayniqsa, TCP asosida ishlashi sababli avvalgi Serial aloqa bilan solishtirganda tezligi yuqori va tarmoq tuzilishi moslashuvchanligi juda yaxshi edi. Loyihada bir nechta uskunalarga bir vaqtning o'zida so'rovlarni qayta ishlash zarur bo'lganligi sababli, asinxron asosidagi TCP qayta ishlash tuzilmasi juda muhim edi.
Shuningdek, ba'zi uskunalarda javob kechikishi sodir bo'lgan yoki ma'lum bir vaqt davomida javob to'xtab qolgani sababli, vaqt o'tkazib yuborish va qayta urinib ko'rish tuzilishini ham hisobga oldik.
Natijada, oddiy protokolni amalga oshirishdan tashqari, tarmoq uzilishlari holatini hisobga olgan barqaror aloqa tuzilmasini loyihalash asosiy vazifa bo'lib qoldi.
3. Asinxron asosidagi ma'lumotlarni yig'ish arxitekturasi
Loyihaning eng muhim talablaridan biri millisekund darajasida juda tez ma'lumotlarni yig'ish edi.
Agar yuqori darajadagi ilova har safar ma'lumot zarur bo'lganda asbobga sinxron usulda o'qish so'rovi yuboradigan tuzilmani ishlatsa, tarmoq I/O kutish vaqti tufayli kerakli ishlashni olish qiyin bo'ldi.
Xususan, maydondagi asboblar javob vaqti doimiy bo'lmas edi va tez-tez vaqtinchalik tarmoq kechikishlari yuzaga kelardi.
Ushbu muammoni hal qilish uchun ma'lumotlarni to'plash tuzilmasini asynchronous Polling asosida arxitektura sifatida loyihalashtirdik.
Tuzilish asosan quyidagi bosqichlarga bo'lingan.
1. Asinxron Polling bajarilishi
2. Hodisa (Event) yaratish
3. MQTT Publisher uzatish
4. Yuqori platforma Publish
Avval ichki Polling Thread belgilangan davrda Modbus qurilmalariga asinxron Read so'rovlarini doimiy ravishda amalga oshirdi. To'plangan ma'lumotlar oddiygina darhol yuborilmay, Event ob'ektiga aylantirilgan holda ichki Queue'ga uzatilgan.
Shundan so'ng mustaqil ravishda ishlaydigan MQTT Publisher Queue'ni iste'mol qilib, ma'lumotlarni MQTT Broker'ga chiqaradigan tuzilmani tashkil qildi. Bunday tuzilmadagi eng katta afzallik Read va Publish jarayonlarini butunlay ajratish imkoniyatidir.
Agar MQTT Publishing tezligi pasaysa ham Polling Threadning o'zi ta'sirlanmaydi, shuning uchun ma'lumotlarni yig'ish davrini barqaror saqlab qolish mumkin edi. Shuningdek, Threadlar o'rtasidagi bog'liqlikni kamaytira oldik va har bir qayta ishlash bosqichining mustaqil kengaytirilishi ham mumkin bo'ldi.
Masalan, kelajakda Kafka asosidagi Publish tuzilmasiga o'tish mumkin bo'lsada, Polling tuzilmasi o'zi o'zgarmasligini ta'minlash uchun loyihalashtirildi. Haqiqiy ish muhitida bir vaqtning o'zida o'nlab qurilmalar bo'yicha Pollingni amalga oshirish kerak bo'lganligi sababli Thread Pool asosidagi tuzilma qo'llanildi va CPU va xotira sarfini doimiy ravishda monitoring qilib, optimallashtirish ishlarini ham olib borildi.
4. Ma'lumot yo'qolishining oldini olish va MQTT nosozliklariga qarshi chora-tadbirlar
IoT qirralarida tarmoq nosozliklari juda tez-tez sodir bo'ladi. Ayniqsa, zavod muhitlarida tarmoq sifati barqaror emas yoki tashqi aralashuvlar sababli MQTT Broker ulanishi qisqa vaqt ichida uzilib qolishi holatlari ko'p uchraydi.
Dastlabki amalga oshirish tuzilmasida MQTT ulanishi uzilganda, Queue ichidagi ma'lumotlar butunlay yo'qolish xavfi mavjud edi. Ushbu muammoni hal qilish maqsadida muammolarni bartaraf etish tuzilmasini qo'shimcha ravishda loyihalashtirdik.
Birinchidan, MQTT Publish muvaffaqiyatsiz bo'lganda ma'lumotlar darhol yo'q qilinmasligi uchun alohida InfluxDBga saqlashga asoslangan dastur ishlab chiqdik.
Ya'ni, real vaqtda Publish muvaffaqiyatsiz bo'lgan ma'lumotlar vaqt seriyalari ma'lumotlar bazasida vaqtinchalik saqlash vazifasini bajarish uchun tuzilgan.
Keyin MQTT ulanishi tiklangandan so'ng, saqlangan ma'lumotlarni qayta o'qib, qayta yuborish amalga oshirildi. Ushbu tuzilma orqali tarmoq nosozligi holatlarida ma'lumot yo'qotish minimumga tushirildi.
Ayniqsa, nosozlikni tiklashdan so'ng o'tgan ma'lumotlar va hozirgi real vaqt ma'lumotlarining aralashishini oldini olish uchun alohida MQTT mavzusi ishlatildi.
Masalan, real vaqt ma'lumotlari .../REALTIME/... mavzusi orqali e'lon qilinadi va nosozlikni tiklash ma'lumotlari .../OFFLINE/... mavzusi orqali ajratib e'lon qilinadi.
Buning yordamida yuqori platformalar ma'lumotlarning xarakterini aniq ajratish imkoniyatiga ega bo'ldi va real vaqt tahlil mantiqiga ta'sir qilmasligi mumkin edi. Natijada loyiha nafaqat oddiy real vaqtni qayta ishlashni, balki nosozlik holatlarida ham ma'lumotlarni ishonchli saqlay oladigan tuzilmani yaratishni amalga oshirdi.
5. Motivlar asosidagi yozuvni qayta ishlash va barqarorlikni ta'minlash
Ma'lumotlarni olish (Read) dan farqli o'laroq, uskunani boshqarish uchun Write funksiyasi ancha yuqori barqarorlikni talab qildi. Uskunaning holatini o'zgartiruvchi Write so'rovlar oddiy ma'lumot olishdan farq qilib, haqiqiy uskunaning ishiga bevosita ta'sir etadi.
Masalan, uskunani boshlash, to'xtatish, valfni boshqarish, motorni boshqarish kabi buyruqlar noto'g'ri bajarilganda ishlab chiqarish uskuna nosozligi yoki xavfsizlik avariyasi bilan bog'liq bo'lishi mumkin. Shu sababli, Write funksiyasi asinxron usulda emas, balki sinxron usulda amalga oshirildi.
Write so'rov yuzaga kelganda darhol Modbus Write so'rovini bajaring va uskunadan normal javob (ACK) olguncha so'rov Thread natijani kutishga mo'ljallangan.
Bu struktura tanlanishining sabablari ikki asosiy omildir.
Birinchi aniq sabab-natijani ta'minlash edi.
Uskunalarni boshqarish loji odatda ketma-ket boshqarish shaklida ishlaydi. Ya'ni, oldingi yozish jarayoni muvaffaqiyatli tugatilishi kerak edi, shunda keyingi bosqichni boshqarish mumkin edi.
Agar asinxron uslubda ishlansa, haqiqiy uskunalar holati hali o'zgarmagan bo'lsa, keyingi boshqaruv mantiqi oldinroq bajarilishi xavfi yuzaga keladi.
Ikkinchisi esa darhol xatolarni yaxshilash edi.
Yozish muvaffaqiyatsiz bo'lganda yuqori tizim darhol nosozlik holatini anglishi kerak edi. Modbus uchun Yozish so'rovi normal javobi har doim so'rov ma'lumotlarining Eko qiymatidir. Shuning uchun Yozish so'rovining muvaffaqiyatli o'tkazilgani haqida javob olsangiz ham, haqiqatan ham qiymat qo'llanilganligini tasdiqlash jarayoni zarur edi. Buning uchun Yozish so'rovi javobidan so'ng haqiqiy registr qiymatini yana bir bor ko'rib chiqamiz va talab qilingan qiymat aniq aks etganligini qo'shimcha ravishda tasdiqlash usulidan foydalanildi. Bunday tuzilma orqali haqiqiy ish joylarida ham barqaror uskunalarni boshqarish mumkin bo'ldi.
6. Xulosa
Ushbu Modbus TCP asosidagi IoT aloqa drayverini amalga oshirish tajribasi oddiy protokol ishlab chiqishdan ko'ra ko'proq ma'noga ega edi.
Dastlab, faqatgina Modbus paketlarini yuborish va qabul qilish darajasida o'ylagandim, ammo haqiqiy loyihani amalga oshirish jarayonida eng muhim narsa cheklangan chekka muhitda ma'lumotlarni qanchalik ishonchli to'play olishimiz va yetkazib bera olishimiz ekanligini his qildim.
Xususan, quyidagi elementlar juda muhim edi.
- Asinxron asoslangan yuqori tezlikdagi ma'lumotlarni to'plash
- Tarmoq nosozligini bartaraf etish tuzilishi
- Ma'lumotlarning yo'qolishini oldini olish
- Barqaror uskunalar nazorati
- Cheklangan resurslarni optimallashtirish
- Real-time qayta ishlash va barqarorlik balansı
Amaliy sanoat maydonlarida tarmoq sifati har doim bir xil emas va uskunalarning javob tezligi ham bashorat qilish qiyin. Shuning uchun oddiy funksiyalarni amalga oshirishdan ko'ra, nosozlik holatlarida qanchalik barqaror ishlashi juda muhim bo'ldi.
Ushbu loyiha doirasida Polling tuzilmasini loyihalash, asinxron voqealar bilan ishlash, MQTT-ga asoslangan ma'lumot yetkazib berish, nosozlikni tiklash arxitekturasi kabi turli IoT chekka tizimlarida tajriba qozondim.
Kelajakda Modbusdan tashqari OPC-UA, MQTT Sparkplug, BACnet kabi turli sanoat protokollari muhitida ham shunga oʻxshash arxitekturani kengaytirib qoʻyishingiz mumkin deb umid qilamiz.
Xususan, IoT muhitida oddiy texnologiyalar to'plamidan ko'ra maydon sharoitlari va operatsion barqarorlikni hisobga olgan arxitektura dizayni eng muhim ekanligini yana bir bor tasdiqlaydigan loyiha bo'ldi.
chnsik