Internet of Things आर्किटेक्चर: एक संपूर्ण गाइड

बहुत सी टीमें अभी इसी स्थिति में हैं। बिल्डिंग में स्मार्ट लॉक, ऑक्यूपेंसी सेंसर, कैमरे, डिजिटल साइनेज, HVAC कंट्रोल, कियोस्क, टैबलेट, पेमेंट टर्मिनल, गेस्ट WiFi, स्टाफ डिवाइस और विभिन्न विभागों द्वारा अलग-अलग समय पर खरीदे गए कई सिस्टम हैं। सब कुछ कनेक्टेड है, लेकिन ज़रूरी नहीं कि अच्छी तरह से कनेक्टेड हो।

यहीं पर इंटरनेट ऑफ थिंग्स आर्किटेक्चर एक अमूर्त आरेख बनना बंद कर देता है और एक ऑपरेटिंग मॉडल बन जाता है। यदि आर्किटेक्चर कमज़ोर है, तो डिवाइस अलग-थलग पड़ जाते हैं, डेटा बहुत देर से पहुँचता है, पहचान असंगत होती है, और सुरक्षा भाग्य पर निर्भर करती है। यदि आर्किटेक्चर मजबूत है, तो उसी एस्टेट को सुरक्षित करना आसान, सपोर्ट करना आसान और व्यवसाय के लिए कहीं अधिक उपयोगी हो जाता है।

IoT आर्किटेक्चर क्या है और यह अब क्यों महत्वपूर्ण है

एक होटल निदेशक एक समस्या देखता है। मेहमान तेज़ WiFi चाहते हैं, कमरे ऊर्जा कुशल होने चाहिए, कर्मचारियों को बिना किसी बाधा के सिस्टम के बीच काम करना चाहिए, और कनेक्टेड डिवाइस आसानी से काम करने चाहिए। एक IT निदेशक इसके पीछे की मुख्य समस्या को देखता है। ये सभी परिणाम इस बात पर निर्भर करते हैं कि संगठन के पास डिवाइस, कनेक्टिविटी, प्रोसेसिंग, एक्सेस और एप्लिकेशन के लिए एक सुसंगत आर्किटेक्चर है या नहीं।

IoT आर्किटेक्चर वह खाका है जो यह परिभाषित करता है कि भौतिक डिवाइस डेटा कैसे एकत्र करते हैं, वह डेटा कैसे स्थानांतरित होता है, उसे कहाँ प्रोसेस किया जाता है, सिस्टम उस पर कैसे कार्रवाई करते हैं, और प्रत्येक हिस्से के साथ बातचीत करने की अनुमति किसे है। व्यावहारिक रूप से, यह उन सवालों के जवाब देता है जो संचालन को बनाते या बिगाड़ते हैं। एक थर्मोस्टेट किस नेटवर्क से जुड़ता है। कैमरे के फुटेज का विश्लेषण कहाँ किया जाता है। एक विरासत वाला सेंसर कैसे प्रमाणित होता है। ठेकेदार के चले जाने पर क्या होता है। गेस्ट डिवाइस नैदानिक प्रणालियों या बैक-ऑफिस टूल से कैसे अलग रहते हैं।

यूके में तात्कालिकता वास्तविक है। जुड़े हुए एस्टेट्स की वृद्धि अब सैद्धांतिक नहीं रह गई है। GeeksforGeeks पर IoT आर्किटेक्चर और यूके अपनाने के रुझानों के उद्धृत अवलोकन के अनुसार, यूके में 2023 में 1.2 बिलियन से अधिक IoT कनेक्शन थे, जो 2022 से 35% अधिक है, और 77% यूके व्यवसायों ने अपने IoT सिस्टम के लिए साइबर खतरों की सूचना दी।

वह संयोजन बातचीत को बदल देता है। बिना संरचना के पैमाना परिचालन में बाधा उत्पन्न करता है। संरचना के साथ पैमाना लाभ पैदा करता है।

आर्किटेक्चर ही डिवाइस को एक सिस्टम में बदलता है

अधिकांश विफल IoT प्रोग्राम इसलिए विफल नहीं होते क्योंकि सेंसर खराब थे। वे इसलिए विफल होते हैं क्योंकि उनके आसपास का डिज़ाइन कमजोर था.

एक व्यावहारिक आर्किटेक्चर आपको प्रदान करता है:

• भूमिकाओं का स्पष्ट अलगाव: डिवाइस डेटा एकत्र करते हैं, नेटवर्क उसे ट्रांसपोर्ट करते हैं, गेटवे प्रोसेस करते हैं, एप्लिकेशन प्रस्तुत करते हैं, और आइडेंटिटी एक्सेस को नियंत्रित करती है।
• अनुमानित सुरक्षा सीमाएँ: गेस्ट ट्रैफ़िक, स्टाफ एक्सेस, और मशीन ट्रैफ़िक आपस में मिले हुए नहीं होते हैं।
• परिचालन निरंतरता: ऑनबोर्डिंग, निरसन (रिवोकेशन), निगरानी और समस्या निवारण एक दोहराए जाने वाले पैटर्न का पालन करते हैं।
• व्यावसायिक उपयोगिता: डेटा उन सिस्टमों तक पहुँचता है जो उस पर कार्रवाई कर सकते हैं, चाहे वह BMS हो, CRM हो, या सर्विस डेस्क हो।

व्यावहारिक नियम: यदि किसी कनेक्टेड डिवाइस को केवल "अपवाद बनाकर" ही जोड़ा जा सकता है, तो आर्किटेक्चर अभी तक परिपक्व नहीं है।

यदि आप यह समझना चाहते हैं कि कनेक्टेड एस्टेट कितनी तेज़ी से बढ़ रहे हैं, तो इंटरनेट से कितने डिवाइस जुड़े हैं इसका यह अवलोकन एक उपयोगी बिजनेस-लेवल संदर्भ बिंदु है।

IoT आर्किटेक्चर की बुनियादी परतें

इंटरनेट ऑफ थिंग्स आर्किटेक्चर को आसानी से समझने के लिए, इसे एक इमारत के रूप में कल्पना करें। प्रत्येक मंजिल का एक अलग उद्देश्य होता है। यदि निचली मंजिलें अस्थिर हैं, तो पेंटहाउस से कोई फर्क नहीं पड़ता।

परसेप्शन लेयर

यह ग्राउंड फ्लोर है। इसमें वे भौतिक चीजें शामिल हैं जो महसूस करती हैं या कार्य करती हैं।

इसमें ऑक्यूपेंसी सेंसर, थर्मोस्टेट, कैमरे, स्मार्ट लॉक, मेडिकल मॉनिटर, पर्यावरणीय प्रोब, कियोस्क, भुगतान टर्मिनल और एक्चुएटर शामिल हैं। ये डिवाइस वे रॉ सिग्नल उत्पन्न करते हैं जिन पर बाकी स्टैक निर्भर करता है।

यहाँ मुख्य डिज़ाइन चिंता केवल डिवाइस का चुनाव नहीं है। यह विश्वसनीयता है। कमज़ोर फ़र्मवेयर, ख़राब अपडेट पाथ, या सीमित पहचान समर्थन वाले सस्ते सेंसर ऐसी समस्याएँ पैदा करते हैं जिन्हें बाद में स्टैक में पूरी तरह से ठीक नहीं किया जा सकता है। हॉस्पिटैलिटी और रिटेल में, टीमों को अक्सर आधुनिक और लीगेसी उपकरणों का एक मिश्रित एस्टेट विरासत में मिलता है। आर्किटेक्चर को एक नए सिरे से शुरुआत मानने के बजाय उस वास्तविकता को स्वीकार करना होगा।

नेटवर्क लेयर

यह बिल्डिंग की वायरिंग और प्लंबिंग की तरह है। यह डिवाइस, गेटवे, प्लेटफॉर्म और एप्लिकेशन के बीच डेटा ट्रांसफर करता है।

नेटवर्क लेयर में ट्रांसपोर्ट पाथ, वायरलेस और वायर्ड कनेक्टिविटी, गेटवे प्लेसमेंट, ट्रैफ़िक आइसोलेशन और वे नियम शामिल होते हैं जो यह तय करते हैं कि कौन से सिस्टम आपस में बात कर सकते हैं। एक अस्पताल में, इसका मतलब मरीज की निगरानी वाले ट्रैफ़िक को मेहमानों के इंटरनेट एक्सेस से अलग रखना हो सकता है। रिटेल में, इसका मतलब पॉइंट-ऑफ-सेल ट्रैफ़िक को ऑक्यूपेंसी एनालिटिक्स और पब्लिक WiFi से अलग करना हो सकता है।

एक मजबूत नेटवर्क लेयर तीन काम अच्छी तरह से करती है:

• विश्वसनीय रूप से कनेक्ट होता है: डिवाइस बिना किसी लगातार मैन्युअल हस्तक्षेप के ऑनलाइन रहते हैं।
• सही ढंग से सेगमेंट करता है: एक ज़ोन में समझौता दूसरे ज़ोन में नहीं फैलता है।
• सही प्रोटोकॉल मिक्स का समर्थन करता है: सीमित क्षमता वाले डिवाइस और एंटरप्राइज़ एप्लिकेशन की ट्रांसपोर्ट ज़रूरतें एक जैसी नहीं होती हैं।

एज कंप्यूटिंग लेयर

यह स्थानीय उपयोगिता कक्ष है। यह डिवाइसों के करीब रहता है और ट्रैफ़िक के अपस्ट्रीम जाने से पहले समय-संवेदनशील या अधिक-बैंडविड्थ वाले कार्यों को संभालता है।

एज गेटवे शोर को फ़िल्टर करते हैं, डेटा को सामान्य करते हैं, स्थानीय नीति लागू करते हैं, और कभी-कभी तत्काल निर्णय लेते हैं। यह उन वातावरणों में महत्वपूर्ण है जहाँ किसी दूरस्थ क्लाउड सेवा के राउंड ट्रिप की प्रतीक्षा करना एक ख़राब डिज़ाइन विकल्प है। उदाहरण के लिए, एक डोर कंट्रोलर को यह तय करने के लिए कि कोई क्रेडेंशियल मान्य है या नहीं, एक धीमे बाहरी पथ पर निर्भर नहीं होना चाहिए। भवन का कोई अलर्ट केवल इसलिए विलंबित नहीं होना चाहिए क्योंकि एक गेटवे ने स्थानीय स्तर पर प्रसंस्करण करने के बजाय प्रत्येक रॉ इवेंट को आगे बढ़ा दिया।

जब देरी, बैंडविड्थ का उपयोग, या गोपनीयता परिचालन जोखिम बन जाए, तो निर्णयों को घटना के अधिक करीब ले जाएं।

क्लाउड और डेटा प्रोसेसिंग लेयर

यह केंद्रीय नियंत्रण कक्ष है। यह कई साइटों से जानकारी एकत्र करता है, उसे संग्रहीत करता है, उसका सह-संबंध बनाता है, और एनालिटिक्स या व्यावसायिक वर्कफ़्लो को फ़ीड करता है।

क्लाउड लेयर वह जगह है जहां संगठन पूरे एस्टेट-व्यापी विज़िबिलिटी को एकीकृत करते हैं। यह वह जगह भी है जहां वे अक्सर अनजाने में जटिलता पैदा कर देते हैं। यदि प्रत्येक डिवाइस बिना किसी फ़िल्टरिंग के सब कुछ अपस्ट्रीम भेजता है, तो टीमों को अनावश्यक ट्रांसपोर्ट और स्टोरेज के लिए भुगतान करना पड़ता है, जबकि डैशबोर्ड अधिक शोर वाले और इंसिडेंट रिस्पॉन्स धीमे हो जाते हैं।

इस लेयर का उपयोग उन वर्कलोड के लिए सबसे अच्छा किया जाता है जो केंद्रीकरण से लाभान्वित होते हैं:

• क्रॉस-साइट रिपोर्टिंग: विभिन्न स्थानों या इमारतों के प्रदर्शन की तुलना करना
• ऐतिहासिक विश्लेषण: ऑक्युपेसी, संपत्ति के उपयोग, या सेवा की गुणवत्ता में रुझानों की पहचान करना
• व्यावसायिक एकीकरण: IoT घटनाओं को टिकटिंग, CRM, ऑटोमेशन, या डेटा प्लेटफॉर्म से जोड़ना

एप्लिकेशन लेयर

यह वह हिस्सा है जिसे उपयोगकर्ता देखते हैं। डैशबोर्ड, सर्विस पोर्टल, अलर्ट, बिल्डिंग मैनेजमेंट इंटरफेस, स्टाफ ऐप्स और रिपोर्टिंग टूल्स सभी यहीं रहते हैं।

यदि एप्लीकेशन लेयर खराब है, तो हितधारक मान लेते हैं कि पूरा प्रोग्राम ही खराब है। एक साफ़-सुथरा बैकएंड ज़्यादा मददगार नहीं होता यदि फैसिलिटीज टीमें अलार्म पर कार्रवाई नहीं कर सकतीं, फ्रंट-ऑफ़-हाउस टीमें रूम रेडीनेस नहीं देख सकतीं, या ऑपरेशन्स मैनेजर्स वास्तविक घटनाओं और बैकग्राउंड नॉइज़ के बीच अंतर नहीं कर सकते।

सबसे अच्छा एप्लिकेशन लेयर केवल वही प्रस्तुत करता है जिसकी प्रत्येक दर्शक को आवश्यकता होती है। नेटवर्क टीमों को टेलीमेट्री और नीति दृश्यता की आवश्यकता होती है। वेन्यू प्रबंधकों को परिचालन सारांश की आवश्यकता होती है। क्लिनिकल या हॉस्पिटैलिटी कर्मचारियों को वर्कफ़्लो की आवश्यकता होती है, पैकेट-स्तरीय विवरण की नहीं।

प्लेटफ़ॉर्म इन परतों को एक साथ कैसे लाते हैं, इस पर संबंधित दृष्टिकोण के लिए, इंटरनेट ऑफ़ थिंग्स प्लेटफ़ॉर्म के लिए यह गाइड पढ़ने योग्य है।

IoT संचार प्रोटोकॉल को नेविगेट करना

प्रोटोकॉल का चुनाव वह जगह है जहाँ इंटरनेट ऑफ़ थिंग्स आर्किटेक्चर बहुत व्यावहारिक हो जाता है। टीमें MQTT, CoAP, या AMQP को इसलिए नहीं चुनती हैं क्योंकि कोई एक दूसरों की तुलना में अधिक आधुनिक लगता है। वे उन्हें इसलिए चुनते हैं क्योंकि प्रत्येक एक अलग समस्या का समाधान करता है।

गलत प्रोटोकॉल हमेशा तुरंत विफल नहीं होता है। अक्सर, यह घर्षण पैदा करता है। डिवाइस की बैटरी बहुत तेज़ी से समाप्त होती है। गेटवे पर अनावश्यक ट्रैफ़िक बना रहता है। इंटीग्रेशन कमजोर हो जाते हैं। सुरक्षा नियंत्रण पहले से शामिल होने के बजाय बाद में ऊपर से थोपे हुए लगते हैं।

ऑपरेटिंग स्थितियों के साथ शुरुआत करें

होटल के कमरे में बैटरी से चलने वाले ऑक्यूपेंसी सेंसर की ज़रूरतें उस बैकएंड वर्कफ़्लो से बहुत अलग होती हैं जो घटनाओं को CRM या मार्केटिंग ऑटोमेशन सिस्टम में भेजता है। एक को हल्का, कुशल एक्सचेंज चाहिए होता है। दूसरे को टिकाऊ, विश्वसनीय सर्वर-टू-सर्वर मैसेजिंग की आवश्यकता होती है।

Intetics का यह उद्धृत प्रोटोकॉल ओवरव्यू इस अंतर को स्पष्ट रूप से रखता है। MQTT को कम-शक्ति वाले डेटा संग्रह के लिए डिज़ाइन किया गया है, CoAP सीमित क्षमता वाले उपकरणों के लिए उपयुक्त है, और AMQP सर्वर-टू-सर्वर एक्सचेंजों के लिए उपयुक्त है। वही स्रोत यह भी नोट करता है कि MQTT का पब-सब मॉडल हजारों समवर्ती कनेक्शन को संभाल सकता है, जो कि सैकड़ों एक्सेस पॉइंट्स और कई कनेक्टेड एंडपॉइंट्स पर काम करने वाले स्थानों में मायने रखता है।

सामान्य IoT संचार प्रोटोकॉल की तुलना

प्रोटोकॉल	ट्रांसपोर्ट	प्रमुख विशेषता	इसके लिए सर्वोत्तम
MQTT	TCP/IP	लाइटवेट पब्लिश-सब्सक्राइब मैसेजिंग	कम-शक्ति वाले सेंसर, टेलीमेट्री, वेन्यू-व्यापी डिवाइस इवेंट
CoAP	UDP/IP	सीमित डिवाइसों के लिए न्यूनतम ओवरहेड	मेमोरी-सीमित या बैटरी-संवेदनशील एंडपॉइंट्स
AMQP	आमतौर पर TCP/IP	विश्वसनीय अतुल्यकालिक (asynchronous) कतारबद्धता और ब्रोकर डिलीवरी	सर्वर-टू-सर्वर वर्कफ़्लो, एंटरप्राइज़ इंटीग्रेशन
DDS	आमतौर पर IP नेटवर्क पर	रीयल-टाइम वितरित संचार	ऐसे वातावरण जिन्हें तेज़ पीयर-टू-पीयर डेटा एक्सचेंज की आवश्यकता होती है

वास्तविक डिप्लॉयमेंट में क्या अच्छा काम करता है

टेलीमेट्री-भारी संपत्तियों के लिए MQTT अक्सर सबसे सुरक्षित डिफ़ॉल्ट विकल्प होता है। यह तब बहुत अच्छा काम करता है जब कई डिवाइस बार-बार छोटे पैकेट रिपोर्ट करते हैं और आपको कई सब्सक्राइबर्स के लिए स्केलेबल फैन-आउट की आवश्यकता होती है। एक रिटेल सेंटर या होटल में, इसमें रूम सेंसर, ऑक्यूपेंसी काउंटर, या पर्यावरण की निगरानी शामिल हो सकती है जो कई डाउनस्ट्रीम सिस्टम को डेटा भेजते हैं।

CoAP उन डिवाइस के लिए उपयुक्त है जिनके पास बहुत सीमित पावर या मेमोरी बजट होता है। यदि आपके पास ऐसे सरल सेंसर हैं जिन्हें बैटरी लाइफ बचानी है और मामूली डेटा साझा करना है, तो CoAP एक तार्किक विकल्प है। लेकिन अगर आपकी टीमें डिवाइस लाइफसाइकिल मैनेजमेंट और ऑब्जर्वेबिलिटी को लेकर अनुशासित नहीं हैं, तो यह थोड़ा मुश्किल हो सकता है, क्योंकि सीमित क्षमता वाले डिवाइस में समस्याओं को ठीक करना अधिक कठिन हो सकता है।

AMQP स्टैक में उच्च स्थान पर आता है। यह आमतौर पर छोटे एज उपकरणों के लिए पहली पसंद नहीं होता है, लेकिन यह व्यावसायिक प्रणालियों के बीच विश्वसनीय अतुल्यकालिक (asynchronous) हैंडऑफ के लिए उपयुक्त है। यदि किसी इवेंट को IoT प्लेटफ़ॉर्म से बुकिंग, CRM, सेवा प्रबंधन, या एनालिटिक्स वर्कफ़्लो में ले जाने की आवश्यकता है, तो डिवाइस-उन्मुख प्रोटोकॉल को एंटरप्राइज़ मैसेजिंग भूमिका में खींचने की कोशिश करने की तुलना में AMQP को नियंत्रित करना अक्सर आसान होता है।

सुरक्षा और स्केलेबिलिटी भी प्रोटोकॉल के निर्णय हैं

प्रोटोकॉल का चयन केवल संदेश प्रारूप से अधिक प्रभावित करता है। यह सुरक्षा मॉडल और ऑपरेटिंग ओवरहेड को आकार देता है।

एक मजबूत डिज़ाइन में आमतौर पर शामिल होते हैं:

• एन्क्रिप्टेड ट्रांसपोर्ट: जहाँ प्रोटोकॉल और डिवाइस इसका समर्थन करते हैं, वहाँ TLS/SSL का उपयोग करें।
• फ़ंक्शन द्वारा सेग्मेंटेशन: डिवाइस श्रेणियों और संदेश पथों को अलग करें।
• व्यवहार द्वारा मॉनिटरिंग: केवल डिवाइस की उपस्थिति ही नहीं, बल्कि असामान्य कनेक्शन पैटर्न पर भी नज़र रखें।
• ब्रोकर या गेटवे अनुशासन: प्रत्येक डिवाइस को व्यापक रूप से संचार करने की अनुमति देने से बचें।

एक प्रोटोकॉल जो हल्का है लेकिन खराब तरीके से नियंत्रित है, सपोर्ट घंटों के मामले में महंगा साबित होता है।

एक आम गलती मानकीकरण को बहुत आक्रामक तरीके से अपनाने की कोशिश करना है। कुछ टीमें हर लेयर पर एक ही प्रोटोकॉल को लागू करने की कोशिश करती हैं क्योंकि यह आसान लगता है। व्यावहारिक रूप से, इससे आमतौर पर जटिलता कहीं और बढ़ जाती है। एक मिश्रित वातावरण अक्सर बेहतर प्रदर्शन करता है जब डिवाइस लेयर एक लाइटवेट प्रोटोकॉल का उपयोग करती है और अपस्ट्रीम इंटीग्रेशन अधिक मजबूत मैसेजिंग मॉडल का उपयोग करते हैं।

एज कंप्यूटिंग लेयर की महत्वपूर्ण भूमिका

क्लाउड-फर्स्ट सोच अभी भी कई IoT चर्चाओं में दिखाई देती है, लेकिन व्यस्त भौतिक वातावरण में केवल-क्लाउड डिज़ाइन टिक नहीं पाता है। जैसे ही आपके डिवाइस वास्तविक समय में संचालन का समर्थन करते हैं, एज कंप्यूटिंग परत मुख्य आर्किटेक्चर का हिस्सा बन जाती है, न कि कोई वैकल्पिक सुधार।

कारण सीधा है। स्थानीय निर्णय अक्सर दूर के निर्णयों से बेहतर होते हैं। एक बिल्डिंग गेटवे साइट से बाहर जाने से पहले डेटा को फ़िल्टर, एग्रीगेट और उस पर कार्रवाई कर सकता है। इससे देरी कम होती है, अनावश्यक बैकहॉल ट्रैफ़िक सीमित होता है, और संवेदनशील प्रोसेसिंग को घटना होने के स्थान के अधिक करीब रखा जाता है।

परिचालन की दृष्टि से एज क्यों महत्वपूर्ण है

एज-सक्षम डिज़ाइन की ओर यूके का झुकाव पहले से ही दिखाई दे रहा है। Itransition पर उद्धृत आर्किटेक्चर अवलोकन के अनुसार, 2023 में यूके की तैनाती में एज-सक्षम आर्किटेक्चर का योगदान 52% था, जो 2020 में 28% था। वही स्रोत बताता है कि एज लेयर बैंडविड्थ के उपयोग को 60% तक कम कर सकती है, और यह भी नोट करता है कि यूके के 42,000 होटल कमरों ने IoT गेटवे को एकीकृत किया है।

वे संख्याएँ उसी के अनुरूप हैं जो नेटवर्क टीमें व्यवहार में देखती हैं। जब साइटें स्थानीय स्तर पर स्पष्ट शोर को प्रोसेस करती हैं, तो अपस्ट्रीम सिस्टम अधिक स्वच्छ और संचालित करने में सस्ते हो जाते हैं। वे अधिक उपयोगी भी बन जाते हैं।

अच्छा एज डिज़ाइन तीन सामान्य समस्याओं का समाधान करता है

1. विलंबता-संवेदनशील (Latency-sensitive) क्रियाएं
   यदि किसी नियम को तत्काल प्रतिक्रिया की आवश्यकता होती है, तो एज प्रोसेसिंग आमतौर पर बेहतर विकल्प है। डोर एक्सेस, सुरक्षा अलर्ट, स्थानीय पर्यावरण नियंत्रण, और ऑक्यूपेंसी-ट्रिगर क्रियाएं सभी छोटे निर्णय पथों से लाभान्वित होती हैं।

2. बैंडविड्थ की बर्बादी
   प्रत्येक रॉ इवेंट क्लाउड पर भेजे जाने के योग्य नहीं होता है। कैमरे, सघन सेंसर एस्टेट, और लगातार स्टेटस अपडेट लिंक को प्रभावित कर सकते हैं यदि आप हर संदेश को समान रूप से मूल्यवान मानते हैं।

3. डेटा हैंडलिंग सीमाएं
   कुछ संगठन गोपनीयता, लचीलेपन, या परिचालन कारणों से कुछ प्रोसेसिंग को स्रोत के करीब रखना पसंद करते हैं। एज गेटवे केंद्रीय दृश्यता को पूरी तरह से छोड़े बिना इसे संभव बनाते हैं।

क्या न करें

एक कमजोर एज रणनीति आमतौर पर दो चरम सीमाओं में से एक की तरह दिखती है।

या तो गेटवे को एक मूक पास-थ्रू माना जाता है और यह बहुत कम मूल्य जोड़ता है, या फिर यह कस्टम लॉजिक से भरा एक अप्रबंधित मिनी डेटा सेंटर बन जाता है जिसका कोई भी समर्थन नहीं करना चाहता। दोनों ही स्थितियाँ सिरदर्द पैदा करती हैं।

बेहतर पैटर्न एज पर चयनात्मक बुद्धिमत्ता का होना है। आक्रामक रूप से फ़िल्टर करें। अपलिंक व्यवधान के दौरान जो उपलब्ध रहना चाहिए उसे कैश करें। उन फ़्लो पर स्थानीय नीति लागू करें जिन्हें इसकी आवश्यकता है। केंद्रीय प्लेटफॉर्म पर सारांश डेटा और महत्वपूर्ण इवेंट भेजें।

यदि साइट कुछ समय के लिए अपस्ट्रीम कनेक्टिविटी खो देती है, तो बिल्डिंग का कामकाज सुचारू रूप से धीमा होना चाहिए, न कि पूरी तरह से अनुपयोगी हो जाना चाहिए।

यह सिद्धांत हॉस्पिटैलिटी, हेल्थकेयर और रिटेल में सबसे अधिक मायने रखता है। ये परिवेश इसलिए नहीं रुकते क्योंकि कोई केंद्रीय सेवा धीमी है। लोग अभी भी चेक-इन कर रहे हैं, कमरों में प्रवेश कर रहे हैं, वार्डों में घूम रहे हैं, या बिलिंग काउंटर पर भुगतान कर रहे हैं। आर्किटेक्चर को इसका सम्मान करना होगा।

आधुनिक पहचान पैटर्न के साथ आर्किटेक्चर को सुरक्षित करना

पारंपरिक पेरमीटर सुरक्षा एक IoT एस्टेट में बहुत जल्दी विफल हो जाती है। डिवाइस स्थानांतरित होते हैं। ठेकेदार आते-जाते रहते हैं। व्यावसायिक इकाइयों के बीच नई सेवाएं प्रकट होती हैं। गेस्ट एक्सेस, स्टाफ एक्सेस और मशीन एक्सेस सभी एक ही भौतिक बुनियादी ढांचे पर सह-अस्तित्व में रहते हैं। एक बार ऐसा होने पर, "नेटवर्क के अंदर" होना कोई सार्थक विश्वास सीमा नहीं रह जाता है।

यही कारण है कि आधुनिक IoT सुरक्षा पहचान की ओर स्थानांतरित हो गई है। केवल उपयोगकर्ता की पहचान ही नहीं, बल्कि डिवाइस की पहचान, सेवा की पहचान, और दोनों से जुड़ी नीति भी।

पुराना मॉडल मल्टी-यूज़र परिवेशों के अनुकूल नहीं है

एक होटल में, एक ही साइट पर मेहमानों के फोन, कॉन्फ्रेंस AV किट, कमरों के सेंसर, स्टाफ टैबलेट, स्मार्ट टीवी, POS टर्मिनल और इंजीनियरिंग डिवाइस हो सकते हैं। स्वास्थ्य सेवा क्षेत्र में, यह मिश्रण और भी कठिन है। क्लीनिकल सिस्टम, मरीजों की पहुंच वाली सुविधाएं, परिसर के उपकरण और लीगेसी चिकित्सा उपकरणों सभी को अलग-अलग कारणों से नेटवर्क एक्सेस की आवश्यकता होती है।

फ़्लैट ट्रस्ट मॉडल इस स्तर की विविधता में नहीं टिक पाते हैं। साझा पासवर्ड जल्दी अप्रचलित हो जाते हैं। व्यापक VLAN पहुँच का दुरुपयोग होता है। मैन्युअल रूप से डी-प्रोविज़निंग करना बहुत धीमा है। एक बार जब किसी डिवाइस या उपयोगकर्ता को आवश्यकता से अधिक पहुँच मिल जाती है, तो नेटवर्क में लेटरल मूवमेंट करना बहुत आसान हो जाता है।

पहचान ही वह नियंत्रण बिंदु है जो स्केल करता है

एक मजबूत मॉडल प्रत्येक कनेक्शन को सत्यापित करने, वर्गीकृत करने और सीमित करने वाली चीज़ के रूप में मानता है।

इसका आम तौर पर मतलब है:

• आधुनिक डिवाइस मजबूत पहचान नियंत्रणों का उपयोग करते हैं: SSO, प्रमाणपत्र, और निर्देशिका-संचालित एक्सेस ऑनबोर्डिंग और निरसन (revocation) को आसान बनाते हैं।
• पुराने डिवाइस क्षतिपूर्ति नियंत्रणों का उपयोग करते हैं: जहां प्रमाणपत्र-आधारित तरीके व्यावहारिक नहीं हैं, वहां नीतियां उन्हें पूरी तरह से अलग और सीमित करने के लिए होनी चाहिए।
• एक्सेस भूमिका और संदर्भ का अनुसरण करता है: एक स्टाफ डिवाइस, एक अतिथि फोन, और एक थर्मोस्टेट को केवल इसलिए कभी भी एक ही ट्रस्ट ज़ोन में नहीं आना चाहिए क्योंकि वे एक ही SSID साझा करते हैं।
• निरसन (Revocation) स्वचालित होना चाहिए: यदि कोई उपयोगकर्ता छोड़ता है या कोई डिवाइस स्थिति बदलता है, तो बिना टिकट कतार के एक्सेस अपडेट होना चाहिए।

Arm Developer की उद्धृत डिज़ाइन-पैटर्न चर्चा इस बदलाव को दर्शाती है। यह नोट करती है कि यूके की अनुपालन आवश्यकताएं जैसे कि डेटा सुरक्षा अधिनियम 2018 और PSTI 2024 IoT सुरक्षा को नया आकार दे रही हैं, और मानक मिडलवेयर पैटर्न अपर्याप्त साबित हो रहे हैं। वही स्रोत हाइब्रिड दृष्टिकोणों की ओर इशारा करता है जो आधुनिक डिवाइसों के लिए SSO और पुराने डिवाइसों के लिए iPSK को जोड़ते हैं, जिसमें स्वचालित निरसन (revocation) और टेनेंट अलगाव शामिल है, और नोट करता है कि यह Meraki और Aruba जैसे प्लेटफार्मों पर परिनियोजन समय को महीनों से घटाकर हफ्तों में ला सकता है।

ज़ीरो ट्रस्ट व्यावहारिक है, सैद्धांतिक नहीं

कुछ टीमें "शून्य विश्वास" (zero trust) सुनती हैं और एक बहु-वर्षीय परिवर्तन कार्यक्रम के बारे में सोचने लगती हैं। IoT में, यह उससे कहीं अधिक ठोस है।

इसका मतलब है कि हर बार जब कोई डिवाइस या उपयोगकर्ता कनेक्ट होता है, तो कुछ कड़े प्रश्न पूछना:

• यह कौन या क्या है
• इसे कैसे प्रमाणित किया गया था
• इसे कहाँ तक पहुँचना चाहिए
• किसे ब्लॉक किया जाना चाहिए
• पहुँच को कितनी जल्दी वापस लिया जा सकता है

वह दृष्टिकोण इसलिए काम करता है क्योंकि यह वास्तविक परिचालन स्थितियों से मेल खाता है। डिवाइस विविध हैं। संपत्तियां साझा की जाती हैं। परिवर्तन निरंतर है।

लक्ष्य किसी पर भरोसा न करना नहीं है। लक्ष्य डिफ़ॉल्ट रूप से भरोसा करना बंद करना है।

IT निर्देशकों के लिए, इंटरनेट ऑफ़ थिंग्स आर्किटेक्चर सुरक्षा में यही मुख्य बदलाव है। एक कमजोर केंद्र के चारों ओर एक कठिन सुरक्षा कवच बनाना बंद करें। कनेक्शन बिंदु पर पहचान, न्यूनतम विशेषाधिकार (least privilege) और अलगाव (isolation) को असाइन करना शुरू करें।

IoT को अपने एंटरप्राइज़ नेटवर्क में एकीकृत करना

अधिकांश IoT आर्किटेक्चर समस्याएँ किसी ग्रीनफील्ड आरेख पर दिखाई नहीं देती हैं। वे तब सामने आती हैं जब एक लाइव नेटवर्क को गेस्ट एक्सेस, स्टाफ वर्कफ़्लो या अनुपालन नियमों को प्रभावित किए बिना नए डिवाइसों को शामिल करना पड़ता है।

यह विशेष रूप से multi-user enterprise environments में सच है। होटल, शॉपिंग सेंटर, अस्पताल, आवासीय भवन और मिश्रित-उपयोग वाली साइटों सभी में एक बात समान है। विभिन्न समूह एक ही भौतिक इंफ्रास्ट्रक्चर को साझा करते हैं, लेकिन उन्हें एक ही ट्रस्ट बाउंड्री साझा नहीं करनी चाहिए।

सह-अस्तित्व से शुरुआत करें, न कि केवल कनेक्टिविटी से

एक आम गलती IoT रोलआउट को वर्तमान WLAN के साथ एक साधारण जुड़ाव के रूप में मानना है। डिवाइस कनेक्ट होते हैं, पैकेट प्रवाहित होते हैं, और प्रोजेक्ट को लाइव घोषित कर दिया जाता है। फिर सपोर्ट टिकट आने लगते हैं। कोई गेस्ट डिवाइस किसी ऐसी जगह पहुँच जाता है जहाँ उसे नहीं होना चाहिए। किसी सुविधा आपूर्तिकर्ता को एक्सेस की आवश्यकता होती है लेकिन उसे ठीक से अलग नहीं किया जा सकता है। कोई लीगेसी एंडपॉइंट पसंदीदा प्रमाणीकरण विधि का समर्थन नहीं करता है। इमारतों के बीच कर्मचारियों का रोमिंग असंगत हो जाता है।

बेहतर सवाल यह है: कनेक्टेड डिवाइस, उपयोगकर्ता और व्यावसायिक सिस्टम एक-दूसरे के जोखिम को अपनाए बिना एक ही नेटवर्क पर एक साथ कैसे सह-अस्तित्व में रहेंगे?

एक व्यावहारिक एकीकरण मॉडल

अधिकांश एंटरप्राइज़ एस्टेट के लिए, बेसलाइन में ये डिज़ाइन विकल्प शामिल होने चाहिए:

• भूमिका और उद्देश्य के अनुसार ट्रैफ़िक को अलग करें: गेस्ट एक्सेस, स्टाफ एक्सेस, और IoT डिवाइस ट्रैफ़िक को अलग-अलग नीतिगत मार्गों का पालन करना चाहिए।
• आइडेंटिटी को नीति से मैप करें: जहाँ तक संभव हो, कर्मचारियों के लिए डायरेक्ट्री-समर्थित एक्सेस और प्रबंधित उपकरणों के लिए स्पष्ट असाइनमेंट का उपयोग करें।
• विरासत वाले उपकरणों को समझदारी से संभालें: पुराने एंडपॉइंट्स को अक्सर एक अलग ऑनबोर्डिंग पैटर्न की आवश्यकता होती है, लेकिन फिर भी उन्हें मजबूत आइसोलेशन की आवश्यकता होती है।
• साइटों के बीच आवाजाही की योजना बनाएं: यदि उपयोगकर्ता और डिवाइस रोमिंग करते हैं, तो नीति भी उनके साथ स्थानांतरित होनी चाहिए।

इसका सबसे स्पष्ट उदाहरण बिल्ड टू रेंट या स्टूडेंट हाउसिंग है। निवासी घर जैसी सादगी की उम्मीद करते हैं। ऑपरेटरों को एंटरप्राइज़-ग्रेड अलगाव की आवश्यकता होती है। यही समस्या अस्पतालों में स्टाफ, मरीजों, आगंतुकों और मेडिकल डिवाइस के साथ, और हॉस्पिटैलिटी में मेहमानों, कर्मचारियों, कॉन्फ्रेंस आयोजकों और तीसरे पक्ष के आपूर्तिकर्ताओं के साथ सामने आती है।

आइसोलेशन को परिचालन रूप से सरल होना चाहिए

आर्किटेक्ट अक्सर कागज़ पर सेगमेंटेशन सही कर लेते हैं लेकिन ऑपरेशन्स में गलत कर देते हैं। नीतियां तो सही होती हैं, लेकिन ऑनबोर्डिंग इतनी कठिन होती है कि टीमें शॉर्टकट बनाने लगती हैं। शेयर्ड क्रेडेंशियल्स फिर से दिखाई देने लगते हैं। अस्थायी अपवाद स्थायी बन जाते हैं। लोकल एडमिन स्प्रेडशीट बनाए रखते हैं क्योंकि प्लेटफ़ॉर्म मॉडल बहुत अधिक कठोर होता है।

यही कारण है कि सरल, दोहराने योग्य डिवाइस अलगाव महत्वपूर्ण है। समस्या के परिचालन पहलू के लिए WiFi पर IoT डिवाइस सेगमेंटेशन और गैर-मानक उपकरणों को अलग करना का यह विवरण एक उपयोगी संदर्भ है।

क्षेत्र में क्या काम करता है

एक व्यावहारिक एकीकरण डिज़ाइन आमतौर पर किसी एक विधि को हर चीज़ पर थोपने के बजाय कई एक्सेस पैटर्न को मिश्रित करता है।

1. निर्देशिका-आधारित स्टाफ एक्सेस
   स्टाफ उपकरणों को संगठन की निर्देशिका और एक्सेस नीतियों से जुड़ी मजबूत पहचान का उपयोग करना चाहिए। इससे ऑनबोर्डिंग और ऑफबोर्डिंग सुसंगत रहती है और साझा क्रेडेंशियल के साथ होने वाली अव्यवस्था से बचा जा सकता है।

2. स्पष्ट अलगाव के साथ अतिथि और आगंतुक पहुंच
   अतिथि आसानी से कनेक्ट होने चाहिए, लेकिन उनका ट्रैफ़िक व्यावसायिक और उपकरण नेटवर्क से पूरी तरह से अलग रहना चाहिए। सबसे अच्छे आर्किटेक्चर नेटवर्क सीमाओं को समाप्त किए बिना उपयोगकर्ता अनुभव को सुचारू रखते हैं।

3. पुराने या हेडलेस IoT उपकरणों के लिए नियंत्रित ऑनबोर्डिंग
   कुछ उपकरण आधुनिक पहचान वर्कफ़्लो का समर्थन नहीं करेंगे। उन्हें अभी भी विशिष्ट नीति उपचार, प्रतिबंधित पहुंच और स्पष्ट स्वामित्व की आवश्यकता है।

4. रोमिंग मॉडल जो घर्षण को कम करते हैं मल्टी-साइट संपत्तियों में, उपयोगकर्ता बार-बार प्रमाणित नहीं होना चाहते हैं। घर्षण रहित, सुरक्षित रोमिंग अनुभव को बेहतर बनाती है और हेल्पडेस्क लोड को कम करती है, लेकिन केवल तभी जब नीति विभिन्न स्थानों पर बरकरार रहे।

अच्छा एकीकरण डिज़ाइन सपोर्ट के प्रयासों को कम करता है क्योंकि यह अस्पष्टता को हटाता है। नेटवर्क पहले से ही जानता है कि कनेक्शन को क्या करने की अनुमति है।

व्यावसायिक परिणाम आमतौर पर तकनीकी परिवर्तन से बड़ा होता है। मेहमान तेजी से जुड़ते हैं। कर्मचारियों का समय कम बर्बाद होता है। सुविधाएं प्रबंधन टीमें जोखिम भरे अपवादों की मांग किए बिना डिवाइस जोड़ सकती हैं। सुरक्षा टीमों को अधिक स्पष्ट सीमाएं मिलती हैं। आर्किटेक्चर का मुख्य उद्देश्य यही है। इसे लाइव एस्टेट को चलाना आसान बनाना चाहिए, न कि केवल अधिक कनेक्टेड।

निष्कर्ष - सफलता के लिए आपका आर्किटेक्चरल ब्लूप्रिंट

इंटरनेट ऑफ थिंग्स आर्किटेक्चर कोई ऐसा आरेख नहीं है जिसे आप खरीद के बाद फ़ाइल में बंद करके रख दें। यह उन डिज़ाइन निर्णयों का समूह है जो यह निर्धारित करता है कि आपकी कनेक्टेड संपत्ति प्रबंधनीय बनेगी या अराजक।

सबसे मजबूत आर्किटेक्चर में कुछ विशेषताएं समान होती हैं। वे स्पष्ट परतों का उपयोग करते हैं। वे फैशन के बजाय परिचालन स्थितियों के आधार पर प्रोटोकॉल चुनते हैं। वे स्पीड, लचीलेपन और नियंत्रण के लिए एज प्रोसेसिंग को एक व्यावहारिक उपकरण के रूप में मानते हैं। वे एक कमजोर होते जा रहे पेरमीटर मॉडल पर भरोसा करने के बजाय पहचान और अलगाव के माध्यम से पहुंच को सुरक्षित करते हैं।

IT निदेशकों के लिए, यह इसलिए महत्वपूर्ण है क्योंकि परिणाम व्यवसाय को दिखाई देते हैं। बेहतर गेस्ट एक्सेस, सुरक्षित डिवाइस ऑनबोर्डिंग, सुव्यवस्थित डेटा प्रवाह और कम परिचालन घर्षण सभी आर्किटेक्चर से शुरू होते हैं। इस ब्लूप्रिंट को सही करें और एस्टेट को स्केल करना, सुरक्षित करना आसान हो जाता है, और यह कहीं अधिक मूल्यवान बन जाता है।

IoT आर्किटेक्चर के बारे में अक्सर पूछे जाने वाले प्रश्न

आर्किटेक्चर को व्यापक रूप से समझने के बाद कुछ सबसे कठिन प्रश्न सामने आते हैं। मुख्य अड़चनें आमतौर पर इस बात को लेकर होती हैं कि शुरुआत कहाँ से करें, क्या मापें, और बिना किसी अनावश्यक निर्माण के समझौते कैसे करें।

IoT आर्किटेक्चर FAQ

प्रश्न	उत्तर
यदि हमारे नेटवर्क में पहले से ही पुराने उपकरण और मिश्रित वेंडर हैं तो हमें कैसे शुरुआत करनी चाहिए?	खोज और वर्गीकरण से शुरुआत करें। पहचानें कि कौन से उपकरण आधुनिक प्रमाणीकरण का समर्थन करते हैं, किनके लिए पूरक नियंत्रणों की आवश्यकता है, और वास्तव में उन्हें किन व्यावसायिक प्रणालियों तक पहुँचने की आवश्यकता है। एक ही बार में सब कुछ मानकीकृत करके शुरुआत न करें। उपकरण वर्गों को अलग करके, नीति क्षेत्रों को परिभाषित करके, और प्रत्येक प्रकार के लिए ऑनबोर्डिंग मार्ग निर्धारित करके शुरुआत करें।
सबसे उपयोगी संकेत क्या हैं कि हमारा आर्किटेक्चर स्केल करेगा?	दिखावटी मेट्रिक्स के बजाय परिचालन संकेतकों को देखें। क्या आप मैन्युअल अपवादों के बिना नए उपकरणों को ऑनबोर्ड कर सकते हैं। क्या आप जल्दी से एक्सेस रद्द कर सकते हैं। क्या आप पता लगा सकते हैं कि किसी उपकरण को कौन सी नीति मिली और क्यों। यदि अपस्ट्रीम लिंक ख़राब हो जाते हैं, तो क्या साइटें आसानी से काम करना जारी रख सकती हैं। स्केलेबल आर्किटेक्चर आमतौर पर कम सहायता घर्षण और अधिक पूर्वानुमानित परिवर्तन प्रबंधन के रूप में दिखाई देता है।
हम अत्यधिक जटिल डिज़ाइन के बिना क्लाउड, एज और सुरक्षा निवेश को कैसे संतुलित करें?	प्रोसेसिंग को वहां रखें जहां व्यावसायिक परिणाम समझ में आता हो। समय-संवेदनशील कार्यों और स्थानीय फ़िल्टरिंग के लिए एज का उपयोग करें। क्रॉस-साइट विज़िबिलिटी और एनालिटिक्स के लिए केंद्रीय प्लेटफ़ॉर्म का उपयोग करें। पूरे समय पहचान-आधारित सुरक्षा का उपयोग करें। यदि कोई लेयर लचीलेपन, नियंत्रण या उपयोगिता में सुधार नहीं करती है, तो यह आर्किटेक्चर के बजाय केवल जटिलता हो सकती है।

निर्णयों का मूल्यांकन करने का एक व्यावहारिक तरीका तीन परीक्षणों के आधार पर प्रत्येक प्रस्तावित परिवर्तन की समीक्षा करना है:

• परिचालन परीक्षण: क्या साइट टीमें लगातार इसका समर्थन करने में सक्षम होंगी
• सुरक्षा परीक्षण: क्या यह अंतर्निहित विश्वास को कम करता है और पहुंच की सुरक्षा को कड़ा करता है
• व्यावसायिक परीक्षण: क्या यह उपयोगकर्ता अनुभव, डेटा की उपयोगिता, या वितरण गति में सुधार करता है

यदि कोई डिज़ाइन इनमें से केवल एक परीक्षा में उत्तीर्ण होता है, तो आमतौर पर उसे और अधिक काम की आवश्यकता होती है।

---

यदि आप हॉस्पिटैलिटी, रिटेल, हेल्थकेयर, या मल्टी-टेनेंट प्रॉपर्टी में एक कनेक्टेड एस्टेट की योजना बना रहे हैं, तो Purple नेटवर्क और आइडेंटिटी के हिस्सों को एक साथ लाने में मदद करता है। Purple मेहमानों और कर्मचारियों के लिए पासवर्डलेस WiFi एक्सेस प्रदान करता है, मल्टी-टेनेंट आइसोलेशन का समर्थन करता है, Entra ID और Okta जैसे प्लेटफॉर्म के साथ एकीकृत होता है, और iPSK जैसे व्यावहारिक नियंत्रणों के साथ संगठनों को विरासत वाले IoT उपकरणों को संभालने में मदद करता है। यह उन टीमों के लिए एक बेहतरीन विकल्प है जो साझा पासवर्ड या जटिल Captive Portal पर निर्भर रहे बिना सुरक्षित एक्सेस, सरल संचालन और बेहतर उपयोगकर्ता अनुभव चाहते हैं।