IoT प्रणाली (IoT system) का तार्किक डिजाइन (logical design) कार्यान्वयन (implementation) के निम्न-स्तर को निर्दिष्ट किए बिना संस्थाओं (entities) और प्रक्रियाओं (processes) के एक सार (abstract) को संदर्भित (represent) करता है। यह एक प्रणाली को लागू करने के लिए कार्यात्मक ब्लॉक (Functional Block), संचार मॉडल (Communication Models) और संचार एपीआई (Communication API) का उपयोग करता है।
लेकिन इससे पहले कि आप IoT system के तार्किक डिज़ाइन (logical design) के बारे में जानें, आपको IoT के भौतिक डिज़ाइन (physical design) के बारे में थोड़ा सा जानना होगा।
Internet of Things (IoT) का तार्किक डिजाइन (Logical Design)
- IoT Functional Blocks
- IoT Communication Models
- IoT Communication API
IoT (Functional blocks)
एक IoT सिस्टम में कई कार्यात्मक ब्लॉक (Functional blocks) होते हैं जैसे डिवाइस, सेवाएं, संचार, सुरक्षा और एप्लिकेशन, जो सेंसिंग (sensing), एक्ट्यूएशन (actuation), पहचान (identification), संचार (communication) और प्रबंधन (management) की क्षमता प्रदान करते हैं।
इन कार्यात्मक ब्लॉकों (functional blocks) में ऐसे उपकरण होते हैं जो निगरानी नियंत्रण (monitoring control) कार्य (functions) प्रदान करते हैं, होस्ट (host) और सर्वर (server) के बीच संचार (communication) को संभालते हैं, डेटा के ट्रान्सफर का प्रबंधन करते हैं, प्रमाणीकरण (authentication) और अन्य functions का उपयोग करके सिस्टम को सुरक्षित करते हैं|
एप्लीकेशन (Application)
यह एक इंटरफ़ेस (interface) है जो एक नियंत्रण प्रणाली (control system) प्रदान करता है जो उपयोगकर्ताओं द्वारा सिस्टम की स्थिति और विश्लेषण (status and analyse) को देखने के लिए उपयोग किया जाता है|
प्रबंधन (Management)
यह कार्यात्मक ब्लॉक (functional block) विभिन्न विभिन्न प्रकार के कार्य (function) प्रदान करता है जिनका उपयोग IoT सिस्टम को प्रबंधित करने के लिए किया जाता है।
सेवाएं (Services)
यह कार्यात्मक ब्लॉक (functional block) कुछ सेवाएं प्रदान करता है, जैसे किसी डिवाइस की निगरानी और नियंत्रण (monitoring and controlling a device) और डेटा को प्रकाशित और हटाना (publishing and deleting the data) और सिस्टम को पुनर्स्थापित करना (restore the system)।
संचार (Communication)
यह ब्लॉक क्लाइंट और क्लाउड-आधारित सर्वर के बीच संचार को संभालता है और प्रोटोकॉल का उपयोग करके डेटा भेजता/प्राप्त (send/receive) करता है।
सुरक्षा (Security)
इस ब्लॉक का उपयोग कुछ कार्यों जैसे प्राधिकरण (authorization), डेटा सुरक्षा (data security), प्रमाणीकरण (authentication), 2 step verification, आदि का उपयोग करके IoT सिस्टम को सुरक्षित करने के लिए किया जाता है।
डिवाइस (Device)
इन उपकरणों का उपयोग संवेदन और निगरानी नियंत्रण (sensing and monitoring control) कार्यों को प्रदान करने के लिए किया जाता है जो बाहरी वातावरण से डेटा एकत्र करते हैं।
IoT कम्युनिकेशन मॉडल (IoT Communication Models)
IoT सिस्टम में कई अलग-अलग प्रकार के मॉडल उपलब्ध हैं जो सिस्टम और सर्वर के बीच संचार (communicate) करने के लिए उपयोग किए जाते हैं जैसे अनुरोध-प्रतिक्रिया मॉडल (request-response model), प्रकाशित-सदस्यता मॉडल (publish-subscribe model), पुश-पुल मॉडल (push-pull model) और अनन्य जोड़ी मॉडल (exclusive pair model) इत्यादि।
Request-Response Communication Model
यह मॉडल एक संचार मॉडल है जिसमें क्लाइंट सर्वर को डेटा के लिए request भेजता है और सर्वर अनुरोध (request) के अनुसार प्रतिक्रिया (response) करता है। जब कोई सर्वर अनुरोध (request) प्राप्त करता है तो वह डेटा प्राप्त करता है, संसाधनों को पुनर्प्राप्त (retrieve) करता है और प्रतिक्रिया (response) तैयार करता है, और फिर डेटा को क्लाइंट को वापस भेजता है।
सरल शब्दों में, हम कह सकते हैं कि request-response model सर्वर क्लाइंट (server client) के अनुरोध (request) पर प्रतिक्रिया (response) भेजता है। इस मॉडल में, HTTP क्लाइंट और सर्वर के बीच request-response protocol के रूप में काम करता है।
उदाहरण:-
जब हम किसी ब्राउज़र पर कोई क्वेरी (query) खोजते हैं तो ब्राउज़र सर्वर को एक HTTP अनुरोध (request) सबमिट करता है और फिर सर्वर ब्राउज़र (क्लाइंट) को प्रतिक्रिया (response) देता है।
Publish-Subscribe Communication Model
इस संचार मॉडल में, हमारे पास प्रकाशक (publisher) और उपभोक्ता (consumer) के बीच एक broker होता है। यहां प्रकाशक (publisher) डेटा के स्रोत हैं लेकिन वे उपभोक्ताओं (consumers) से अवगत नहीं होते हैं। वे broker द्वारा प्रबंधित डेटा भेजते हैं और जब कोई उपभोक्ता ब्रोकर द्वारा प्रबंधित किसी विषय की सदस्यता लेता है और जब ब्रोकर को प्रकाशक (publisher) से डेटा प्राप्त होता है तो यह सभी सब्सक्राइब्ड उपभोक्ताओं को डेटा भेजता है।
उदाहरण:-
वेबसाइट पर कई बार हमने अपने ईमेल पते का उपयोग करके उनके न्यूज़लेटर्स (newsletters) की सदस्यता ली। ये ईमेल पते (Email address) कुछ तृतीय-पक्ष सेवाओं (third-party services) द्वारा प्रबंधित किए जाते हैं और जब वेबसाइट पर कोई नया लेख प्रकाशित होता है तो यह सीधे ब्रोकर को भेजता है और फिर ब्रोकर इन नए डेटा या पोस्ट को सभी ग्राहकों को भेजता है।
Push-Pull Communication Model
यह एक संचार मॉडल है जिसमें उत्पादकों (producer) द्वारा डेटा को एक कतार (queue) में push किया जाता है और उपभोक्ता (consumer) डेटा को कतारों (queues) से pull करते हैं। यहां भी उत्पादकों को उपभोक्ताओं की जानकारी नहीं होती।
उदाहरण:-
जब हम किसी वेबसाइट पर जाते हैं तो हमें कई पोस्ट दिखाई देती हैं जो एक कतार (queue) में प्रकाशित होती हैं और अपनी आवश्यकताओं के अनुसार, हम एक पोस्ट पर क्लिक करते हैं और उसे पढ़ना शुरू करते हैं।
Exclusive Pair Communication Model
यह मॉडल क्लाइंट और सर्वर के बीच लगातार कनेक्शन का उपयोग करता है। यहां पहले क्लाइंट और सर्वर के बीच एक कनेक्शन स्थापित किया जाता है और यह तब तक खुला (open) रहता है जब तक क्लाइंट सर्वर से एक करीबी कनेक्शन (close connection) अनुरोध नहीं भेजता।
IoT कम्युनिकेशन API (IoT communication APIs)
REST और WebSocket जैसे इन API का उपयोग IoT में सर्वर और सिस्टम के बीच संचार के लिए किया जाता है।
REST-आधारित संचार API (REST-based communication APIs)
Representational state transfer (REST) API architectural principles के एक set का उपयोग करता है जो वेब सेवाओं (web services) को डिजाइन करने के लिए उपयोग किया जाता है। ये API सिस्टम के संसाधनों (resources) पर ध्यान केंद्रित करते हैं कि request-response communication model का उपयोग करके संसाधन (resource) को कैसे स्थानांतरित किया जाता है। यह API कुछ वास्तुशिल्प बाधाओं (architectural constraints) का उपयोग करता है।
क्लाइंट सर्वर (Client Server)
यहां क्लाइंट को डेटा के भंडारण (storage of data) के बारे में पता नहीं होता क्योंकि यह सर्वर के बारे में चिंतित होता है और इसी तरह सर्वर को यूजर इंटरफेस (user interface) के बारे में चिंतित नहीं होना चाहिए क्योंकि यह क्लाइंट की चिंता है। कोई फर्क नहीं पड़ता कि क्लाइंट सर्वर की प्रतिक्रिया (response) का उपयोग कैसे कर रहा है और कोई फर्क नहीं पड़ता कि सर्वर क्लाइंट के अनुरोध (request) का उपयोग कैसे कर रहा है।
स्टेटलेस (Stateless)
इसका मतलब है कि क्लाइंट द्वारा सर्वर से किये गए प्रत्येक अनुरोध (request) में सर्वर के पास समझने के लिए सभी आवश्यक जानकारी होनी चाहिए। क्योंकि यदि सर्वर क्लाइंट के अनुरोध को नहीं समझ सकता है तो वह अनुरोध डेटा (requested data) को उचित तरीके (proper manner) में response नहीं ला सकता है।
Cacheable
प्रतिक्रिया (response) में, यदि कैश (cache constraints) की कमी दी जाती है तो क्लाइंट बाद के अनुरोध (request) में उस प्रतिक्रिया (response) का पुन: उपयोग कर सकता है। यह अतिरिक्त डेटा (extra data) लोड किए बिना सिस्टम की दक्षता और मापनीयता में सुधार करता है।
एक RESTful web API HTTP और REST सिद्धांतों का उपयोग करके कार्यान्वित (implement) किया जाता है।
वेबसॉकेट आधारित संचार एपीआई (WebSocket based communication API)
इस प्रकार का एपीआई अनन्य जोड़ी संचार मॉडल (exclusive pair communication) का उपयोग करके सर्वर और क्लाइंट के बीच द्वि-दिशात्मक पूर्ण-द्वैध संचार (bi-directional full-duplex communication) की अनुमति देता है। यह API पूर्ण-द्वैध संचार (bi-directional full-duplex communication) का उपयोग करता है, इसलिए इसे हर बार नए डेटा का अनुरोध (request) करने पर नए कनेक्शन सेटअप की आवश्यकता नहीं होती है। WebSocket API सर्वर और क्लाइंट के बीच एक कनेक्शन सेटअप के साथ शुरू होता है और यदि WebSocket सर्वर द्वारा समर्थित है तो यह क्लाइंट को सफल प्रतिक्रिया के साथ प्रतिक्रिया देता है और कनेक्शन के सेटअप के बाद सर्वर और क्लाइंट एक दूसरे को डुप्लेक्स मोड में पूर्ण रूप से डेटा भेज सकते है|
इस प्रकार का API डेटा के ट्रैफ़िक (traffic) और विलंबता (latency) को कम करता है और यह सुनिश्चित करता है कि हर बार जब हम नए डेटा का अनुरोध (request) करते हैं तो यह अनुरोध को समाप्त (terminate) नहीं कर सकता।
