পাঠ ৫০ · ৫৭-এর মধ্যে · মডিউল ১১
Home / Courses / Microprocessors, Embedded Systems & IoT / ক্লাউড ও ডিভাইস ম্যানেজমেন্ট

IoT ক্লাউড প্ল্যাটফর্ম ও ডিভাইস ম্যানেজমেন্ট

IoT cloud platforms & device management
৯ মিনিট পড়া মধ্যম · Intermediate Python সিমুলেশনসহ সম্পূর্ণ বাংলায়

এই পাঠে যা শিখবেন

  • IoT ক্লাউড প্ল্যাটফর্মের চারটি মূল স্তম্ভ — ডিভাইস রেজিস্ট্রি, টেলিমেট্রি ইনজেশন, OTA আপডেট, ডিভাইস শ্যাডো/ডিজিটাল টুইন
  • বাস্তব প্ল্যাটফর্মের নাম ও সাধারণ পরিচিতি (নির্দিষ্ট API সিনট্যাক্স ছাড়াই)
  • একটি জেনুইন ডিভাইস-রেজিস্ট্রি + শ্যাডো-রিকনসিলিয়েশন সিমুলেশন
  • এই টপিকটি ../cloud-devops/ কোর্সের সাধারণ ক্লাউড ধারণার সাথে কীভাবে সম্পর্কিত

১ · কেন একটি "IoT ক্লাউড প্ল্যাটফর্ম" আলাদা জিনিস

Cloud Computing & DevOps কোর্সে সাধারণ ক্লাউড ইনফ্রাস্ট্রাকচার (ভার্চুয়াল মেশিন, স্টোরেজ, কনটেইনার, CI/CD) কভার করা হয়েছে। একটি IoT-নির্দিষ্ট ক্লাউড প্ল্যাটফর্ম সেই সাধারণ ইনফ্রাস্ট্রাকচারের ওপর কিছু বিশেষ সমস্যার সমাধান যোগ করে, যা লক্ষ লক্ষ সীমিত-রিসোর্সের ডিভাইস পরিচালনার সাথে সম্পর্কিত — একটি সাধারণ ওয়েব অ্যাপের ব্যাকএন্ডের চেয়ে সম্পূর্ণ ভিন্ন ধরনের চ্যালেঞ্জ। মূল চারটি ক্ষমতা:

  • ডিভাইস রেজিস্ট্রি: প্রতিটি ডিভাইসের একটি ইউনিক পরিচয় (সাধারণত একটি X.509 সার্টিফিকেট বা টোকেন-ভিত্তিক) — কোন ডিভাইস বৈধ, কার কী পারমিশন আছে, তা কেন্দ্রীয়ভাবে ট্র্যাক করা (সাধারণ অথেনটিকেশন নীতি Cybersecurity কোর্সে কভার করা হয়েছে)।
  • টেলিমেট্রি ইনজেশন: লক্ষ লক্ষ ডিভাইস থেকে (প্রায়ই MQTT/CoAP-এর মাধ্যমে, L46-L48) প্রতি সেকেন্ডে আসা সেন্সর ডেটা গ্রহণ করে ডাউনস্ট্রিম ডেটাবেস/অ্যানালিটিক্স সার্ভিসে রুট করা — বিশাল স্কেলে।
  • OTA (Over-The-Air) আপডেট: ফিজিক্যালি প্রতিটি ডিভাইসের কাছে না গিয়ে দূর থেকে ফার্মওয়্যার আপডেট পাঠানো — সাধারণত স্টেজড/ক্যানারি রোলআউট (প্রথমে অল্প কিছু ডিভাইসে, তারপর ধীরে ধীরে বাকি সবার কাছে) ও ব্যর্থ হলে রোলব্যাক সাপোর্টসহ।
  • ডিভাইস শ্যাডোDevice Shadow / Digital Twinএকটি ক্লাউড-সাইড JSON প্রতিচ্ছবি যা একটি প্রকৃত ডিভাইসের অবস্থা প্রতিনিধিত্ব করে — desired (অ্যাপ যা চায়) ও reported (ডিভাইস আসলে কী পাঠিয়েছে) দুটো আলাদা অংশে রাখে। / ডিজিটাল টুইন: একটি ডিভাইস সবসময় সংযুক্ত নাও থাকতে পারে — শ্যাডো একটি অ্যাপকে ডিভাইসের সর্বশেষ পরিচিত অবস্থা দেখতে এবং একটি "কাঙ্ক্ষিত" অবস্থা সেট করতে দেয়, যা ডিভাইস পরবর্তীতে অনলাইনে এলে নিজেই দেখে নেয় ও প্রয়োগ করে।
অ্যাপ / ড্যাশবোর্ড (desired state সেট করে) প্রকৃত ডিভাইস (reported state পাঠায়) ডিভাইস শ্যাডো desired vs reported গণনাকৃত ডেল্টা (পেন্ডিং পরিবর্তন)
অ্যাপ desired state সেট করে, ডিভাইস reported state পাঠায় — শ্যাডো দুটো তুলনা করে জেনুইনভাবে গণনা করে কোন ফিল্ডগুলো এখনও অমিল (ডেল্টা), যা ডিভাইস পরবর্তীতে সিঙ্ক করার সময় প্রয়োগ করে।

২ · বাস্তব প্ল্যাটফর্মের নাম

এই ক্ষমতাগুলো বাস্তবে বেশ কয়েকটি বড় ক্লাউড প্রোভাইডার অফার করে — AWS IoT Core (Amazon, যেখানে "Device Shadow" নামটি সরাসরি এই সার্ভিস থেকেই এসেছে), Azure IoT Hub (Microsoft, একই ধারণা "Device Twin" নামে), এবং ঐতিহাসিকভাবে Google Cloud IoT Core (Google)।

উল্লেখ্য — Google তাদের নিজস্ব Cloud IoT Core সার্ভিসটি ২০২৩ সালে বন্ধ (retire) করে দিয়েছে এবং গ্রাহকদের পার্টনার সলিউশন ব্যবহারের পরামর্শ দিয়েছে। এখানে এটি একটি ঐতিহাসিক ও ধারণাগত উদাহরণ হিসেবে উল্লেখ করা হলো — এর ফিচারসেট (ডিভাইস রেজিস্ট্রি, টেলিমেট্রি, ইত্যাদি) এখনও অন্যান্য প্ল্যাটফর্ম বোঝার জন্য একটি প্রাসঙ্গিক উদাহরণ, তবে বর্তমানে সক্রিয় সার্ভিস হিসেবে বিবেচনা করা উচিত নয়। এই কোর্স কোনো প্ল্যাটফর্মের সুনির্দিষ্ট API সিনট্যাক্স শেখায় না — শুধু ধারণাগত ভূমিকা।

৩ · একটি সত্যিকারের রেজিস্ট্রি ও শ্যাডো সিমুলেশন

নিচে একটি সরল DeviceRegistry (কোন ডিভাইস নিবন্ধিত) এবং একটি DeviceShadow ক্লাস (desired বনাম reported state) লেখা হয়েছে — diff() মেথডটি জেনুইনভাবে গণনা করে কোন ফিল্ডগুলো এখনও অমিল, ঠিক যেভাবে বাস্তব ডিভাইস-শ্যাডো সার্ভিস একটি ডেল্টা/পেন্ডিং-পরিবর্তন হিসেব করে।

Python
class DeviceRegistry:
    """সরল ডিভাইস রেজিস্ট্রি -- কোন ডিভাইস আইডি নিবন্ধিত ও তার পরিচয়পত্র ট্র্যাক করে।"""

    def __init__(self):
        self.devices = {}  # device_id -> {"cert_id": ..., "status": ...}

    def register(self, device_id, cert_id):
        self.devices[device_id] = {"cert_id": cert_id, "status": "registered"}

    def is_registered(self, device_id):
        return device_id in self.devices


class DeviceShadow:
    """একটি একক ডিভাইসের ডিজিটাল প্রতিচ্ছবি -- desired বনাম reported state।"""

    def __init__(self, device_id):
        self.device_id = device_id
        self.desired = {}
        self.reported = {}

    def set_desired(self, **fields):
        self.desired.update(fields)

    def report_state(self, **fields):
        self.reported.update(fields)

    def diff(self):
        """জেনুইনভাবে গণনা করে কোন desired ফিল্ড এখনও reported-এর সাথে মেলে না -- এটাই 'পেন্ডিং ডেল্টা'।"""
        delta = {}
        for key, desired_value in self.desired.items():
            reported_value = self.reported.get(key)
            if reported_value != desired_value:
                delta[key] = {"desired": desired_value, "reported": reported_value}
        return delta


registry = DeviceRegistry()
registry.register("sensor-node-12", cert_id="cert-a1b2c3")
print("রেজিস্ট্রি:", registry.devices)
print("'sensor-node-12' নিবন্ধিত?", registry.is_registered("sensor-node-12"))
print("'sensor-node-99' নিবন্ধিত?", registry.is_registered("sensor-node-99"))

shadow = DeviceShadow("sensor-node-12")
shadow.set_desired(led="on", report_interval_s=30)
shadow.report_state(led="off", report_interval_s=60)  # ডিভাইস এখনও পুরনো সেটিং-এ আছে

print("\n-- সিঙ্কের আগে --")
print("desired :", shadow.desired)
print("reported:", shadow.reported)
delta_before = shadow.diff()
print("গণনাকৃত ডেল্টা (পেন্ডিং পরিবর্তন):", delta_before)

# ডিভাইসটি এখন অনলাইনে এসে ডেল্টা দেখে এবং তা প্রয়োগ করে রিপোর্ট করলো
shadow.report_state(led="on", report_interval_s=30)

print("\n-- সিঙ্কের পরে --")
print("reported:", shadow.reported)
delta_after = shadow.diff()
print("গণনাকৃত ডেল্টা:", delta_after if delta_after else "{} (কোনো অমিল নেই -- সম্পূর্ণ সিঙ্কড)")

    
সিঙ্কের আগে diff() জেনুইনভাবে দুটো ফিল্ডে অমিল খুঁজে বের করে (led ও report_interval_s), কারণ ডিভাইসের reported মান তখনও পুরনো। ডিভাইস আসলে নতুন মান রিপোর্ট করার পর, একই diff() মেথড ফাঁকা ডিকশনারি রিটার্ন করে — এই একই ফাংশনটাই দুটো ভিন্ন ফলাফল দেয় কারণ এটি প্রতিবার সত্যিকারের স্টেট থেকে হিসাব করে, কোনো হার্ডকোড করা উত্তর নয়।
মূল কথা · Key takeaway

একটি IoT ক্লাউড প্ল্যাটফর্ম মূলত "স্কেল সমস্যার" সমাধান — লক্ষ লক্ষ ডিভাইসের পরিচয়, ডেটা, আপডেট ও অবস্থা কেন্দ্রীয়ভাবে পরিচালনা করা, যা একটি সীমিত-রিসোর্সের মাইক্রোকন্ট্রোলার নিজে থেকে করতে পারে না। ডিভাইস শ্যাডো/ডিজিটাল টুইনের desired-vs-reported মডেল সরাসরি সমাধান করে একটি বাস্তব সমস্যা — ডিভাইস সবসময় অনলাইনে নাও থাকতে পারে, তবু অ্যাপকে একটি ব্যবহারযোগ্য "সর্বশেষ পরিচিত অবস্থা" ও একটি "কাঙ্ক্ষিত অবস্থা" দুটোই দিতে হয়।

ভাবনার প্রশ্ন

প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।

প্র ০১ উপরের কোডে যদি shadow.set_desired(led="on")-এর পর ডিভাইস কখনোই report_state() কল না করে (অর্থাৎ অফলাইনই থেকে যায়), তাহলে diff() কী দেখাবে?

diff() সবসময় "led" ফিল্ডটি ডেল্টায় দেখাতে থাকবে (যদি reported["led"] কখনো "on"-এ না মেলে), কারণ ফাংশনটি প্রতিবার সত্যিকারের বর্তমান reported ডিকশনারির সাথে তুলনা করে হিসাব করে — এটাই বাস্তবে দেখায় কীভাবে একটি অফলাইন ডিভাইসের জন্য "পেন্ডিং পরিবর্তন" ক্লাউড-সাইডে জমা হয়ে থাকে, ডিভাইসটি আবার অনলাইনে না আসা পর্যন্ত।

প্র ০২ ডিভাইস রেজিস্ট্রিতে প্রতিটি ডিভাইসের জন্য একটি সার্টিফিকেট-ভিত্তিক পরিচয় থাকা কেন গুরুত্বপূর্ণ, শুধু একটি সহজ ইউজারনেম/পাসওয়ার্ডের বদলে?

কারণ লক্ষ লক্ষ ডিভাইসের প্রতিটির জন্য আলাদা, শক্তিশালী পাসওয়ার্ড ম্যানুয়ালি বরাদ্দ ও নিরাপদে সংরক্ষণ করা বাস্তবে অসম্ভব ও অনিরাপদ — একটি সাধারণ ডিফল্ট পাসওয়ার্ড ব্যবহার করলে একটি ডিভাইস কমপ্রোমাইজড হলে অন্য সব ডিভাইসও ঝুঁকিতে পড়ে (M12-এ IoT সিকিউরিটি চ্যালেঞ্জে আরও বিস্তারিত আসবে)। X.509 সার্টিফিকেট-ভিত্তিক পরিচয় প্রতিটি ডিভাইসকে ইউনিকভাবে ক্রিপ্টোগ্রাফিকভাবে যাচাই করতে দেয়, এবং একটি ডিভাইস কমপ্রোমাইজড হলে শুধু তার একটি সার্টিফিকেট বাতিল (revoke) করা যায়।

প্র ০৩ OTA আপডেট কেন সাধারণত একবারে সব ডিভাইসে না পাঠিয়ে "স্টেজড/ক্যানারি রোলআউট"-এ পাঠানো হয়?

কারণ যদি নতুন ফার্মওয়্যারে একটি বাগ থাকে যা কোনো ডিভাইসকে অকার্যকর (bricked) করে দেয়, সেটি একবারে সব ডিভাইসে পাঠালে পুরো ফ্লিটই ঝুঁকিতে পড়ে। প্রথমে অল্প কিছু ডিভাইসে (ক্যানারি) পাঠিয়ে দেখা হয় সবকিছু ঠিকঠাক চলছে কিনা, তারপর ধীরে ধীরে বাকি সবার কাছে রোলআউট করা হয় — এবং সমস্যা দেখা দিলে দ্রুত রোলব্যাক করার সুযোগ থাকে, পুরো ডিভাইস ফ্লিট নষ্ট হওয়ার আগেই।

অনুশীলন

  1. চিন্তা করুন: উপরের কোড সেলে shadow.set_desired(led="on", report_interval_s=30)-এর সাথে একটি নতুন ফিল্ড firmware_version="2.1.0" যোগ করলে, সিঙ্কের আগের diff()-এ মোট কতগুলো ফিল্ড দেখাবে বলে আপনার ধারণা?

    তিনটি ফিল্ড দেখাবে — led, report_interval_s, আর নতুন firmware_version, কারণ reported ডিকশনারিতে firmware_version কী-টিই নেই (তাই self.reported.get(key) None রিটার্ন করবে, যা "2.1.0"-এর সমান নয়), এবং diff() সেটিকেও একটি জেনুইন অমিল হিসেবে গণনা করবে।

  2. পরীক্ষা করুন: উপরের কোড সেলে registry.register("sensor-node-12", ...)-এর পর একটি নতুন লাইনে registry.devices["sensor-node-12"]["status"] = "revoked" যোগ করে Run চাপুন এবং দেখুন এটি রেজিস্ট্রি ডিকশনারির প্রিন্ট আউটপুটে কীভাবে প্রতিফলিত হয়।

    সেই লাইনটি রান করার পর পরবর্তী print("রেজিস্ট্রি:", registry.devices) কলে (কোডে লাইনের ক্রম অনুযায়ী স্থাপন করলে) "status"-এর মান "registered"-এর বদলে "revoked" দেখাবে — বাস্তব প্ল্যাটফর্মেও ঠিক এভাবেই একটি কমপ্রোমাইজড ডিভাইসের সার্টিফিকেট রিভোক করলে তার স্ট্যাটাস আপডেট হয়ে যায়, যদিও প্রকৃত সিস্টেমে এটি একটি নিরাপদ, অডিটেবল API কলের মাধ্যমে করা হয়, সরাসরি ডেটা-স্ট্রাকচার পরিবর্তন করে নয়।

আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ

  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার, এমবেডেড C, GPIO, টাইমার/PWM/ADC, সিরিয়াল প্রোটোকল, RTOS, সেন্সর/অ্যাকচুয়েটর, IoT আর্কিটেকচার, ওয়্যারলেস প্রোটোকল, MQTT/CoAP ও IoT সিকিউরিটি — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
  • Cloud Computing & DevOps কোর্স সহোদর কোর্স সাধারণ ক্লাউড ইনফ্রাস্ট্রাকচার ও DevOps প্র্যাকটিস সেই কোর্সেই কভার করা হয়েছে — এই পাঠ সরাসরি IoT-নির্দিষ্ট ডিভাইস-ম্যানেজমেন্ট প্যাটার্নে যায়।
  • সব Courses দেখুন ABCL TECH C, C++, Python, Java, JavaScript, DSA, DBMS, Discrete Mathematics, System Design, Cybersecurity, Cloud Computing & DevOps, Computer Networks, Operating Systems, Computer Architecture, Design and Analysis of Algorithms ও আরও অনেক কোর্স — সব এক জায়গায়।
আগের পাঠ
IoT-তে HTTP/REST বনাম MQTT/CoAP