IoT আর্কিটেকচার — এজ, ফগ ও ক্লাউড
এই পাঠে যা শিখবেন
- এজ, ফগ ও ক্লাউড — এই তিন-স্তর IoT আর্কিটেকচারের সুনির্দিষ্ট সংজ্ঞা ও ভূমিকা
- কেন "সব ডেটা ক্লাউডে পাঠাও" সবসময় সেরা ডিজাইন সিদ্ধান্ত নয়
- একটি সত্যিকারের গণনা — লোকাল এজ প্রসেসিং কতটা ব্যান্ডউইথ ও সিদ্ধান্ত-লেটেন্সি বাঁচাতে পারে
- এই মডিউল (M10-M12) কোন দিকে এগোবে তার একটি রোডম্যাপ
১ · তিনটি স্তর
এজEdgeIoT ডিভাইস নিজে, বা তার সরাসরি কাছাকাছি — যেখানে সেন্সর ডেটা তৈরি হয় এবং সবচেয়ে দ্রুত সিদ্ধান্তগুলো নেওয়া হয়। হলো IoT স্ট্যাকের সবচেয়ে নিচের স্তর — এই কোর্সের M1-M9 পর্যন্ত যা কিছু শিখেছেন (মাইক্রোকন্ট্রোলার, GPIO, সেন্সর, RTOS) সবই এই স্তরে ঘটে। এজে প্রসেসিং করার সুবিধা হলো তাৎক্ষণিক — কোনো নেটওয়ার্ক রাউন্ড-ট্রিপের অপেক্ষা ছাড়াই সিদ্ধান্ত নেওয়া যায়।
ফগFogএকটি মধ্যবর্তী লোকাল গেটওয়ে/হাব যা একাধিক এজ ডিভাইসের ডেটা একত্র করে, স্থানীয়ভাবে কিছুটা প্রসেস করে, তারপর ক্লাউডের দিকে পাঠায়। হলো এজ ও ক্লাউডের মাঝামাঝি একটি স্তর — একটি লোকাল গেটওয়ে বা হাব ডিভাইস (যেমন একটি স্মার্ট হোম হাব, বা একটি ফ্যাক্টরির লোকাল সার্ভার) যা কাছাকাছি অনেকগুলো এজ ডিভাইসের ডেটা একত্র করে, প্রয়োজনে ফিল্টার/অ্যাগ্রিগেট করে, এবং শুধু গুরুত্বপূর্ণ অংশটুকু ক্লাউডে পাঠায়। M10-এর পরের পাঠগুলোতে (WiFi/BLE, Zigbee/LoRaWAN) এই "গেটওয়ে দরকার কি না" প্রশ্নটি বারবার ফিরে আসবে।
ক্লাউডCloudকেন্দ্রীয়ভাবে হোস্ট করা স্টোরেজ ও কম্পিউট — দীর্ঘমেয়াদী ডেটা রাখা, ভারী অ্যানালিটিক্স, এবং একাধিক সাইট/ডিভাইস জুড়ে সমন্বয়ের জন্য উপযুক্ত। হলো সবচেয়ে উপরের স্তর — এখানে অসীম প্রায় স্টোরেজ ও কম্পিউট পাওয়া যায়, তাই দীর্ঘমেয়াদী ট্রেন্ড বিশ্লেষণ, একাধিক ডিভাইস/সাইট জুড়ে ড্যাশবোর্ড, বা ভারী মেশিন লার্নিং মডেল ট্রেনিং এখানেই হয় — কিন্তু প্রতিটি রিডিং ক্লাউডে পাঠাতে গেলে ইন্টারনেট সংযোগ ও নেটওয়ার্ক লেটেন্সির উপর নির্ভর করতে হয়। M50-এ IoT ক্লাউড প্ল্যাটফর্ম নিয়ে বিস্তারিত আসবে।
Computer Networks কোর্সে সাধারণ নেটওয়ার্কিং লেয়ার ও প্রোটোকল (TCP/IP স্ট্যাক, রাউটিং) বিস্তারিত কভার করা হয়েছে — সেটাই এই কোর্সের ধরে নেওয়া ভিত্তি। M10-M11 সেই ভিত্তির উপর দাঁড়িয়ে শুধু সেই অংশটুকুতে ফোকাস করবে যা কনস্ট্রেইন্ড IoT ডিভাইসের জন্য ভিন্ন/বিশেষ — কম পাওয়ার, কম ব্যান্ডউইথ, আর প্রায়ই লসি (lossy) লিংক।
২ · একটি সত্যিকারের গণনা — এজ প্রসেসিং কতটা বাঁচায়
ধরা যাক একটি সেন্সর নোড প্রতি সেকেন্ডে ৫০টি রিডিং নেয় (যেমন একটি ভাইব্রেশন বা তাপমাত্রা সেন্সর), প্রতিটি রিডিং ২ বাইট (১৬-বিট)। দুটো ডিজাইন তুলনা করা হচ্ছে — প্রতিটি রিডিং সরাসরি ক্লাউডে পাঠানো, বনাম এজেই প্রতি সেকেন্ডে একটি সামারি/গড় মান (৪ বাইট) হিসাব করে শুধু সেটুকু পাঠানো। নিচের কোড সেল ব্যান্ডউইথ ও সিদ্ধান্ত- লেটেন্সি — দুটোই সত্যিই গণনা করে দেখাচ্ছে।
# --- এজ বনাম ক্লাউড: ব্যান্ডউইথ তুলনা ---
samples_per_sec = 50 # সেন্সর স্যাম্পলিং রেট (উদাহরণ: ভাইব্রেশন/তাপমাত্রা সেন্সর)
bytes_per_sample = 2 # প্রতিটি র-স্যাম্পল ১৬-বিট (২ বাইট)
raw_bandwidth_bps = samples_per_sec * bytes_per_sample * 8
aggregation_interval_s = 1 # এজে প্রতি ১ সেকেন্ডে একটি সামারি পাঠানো হয়
bytes_per_aggregate = 4 # সামারি ভ্যালু (যেমন গড়) ৪ বাইটে এনকোড করা
aggregated_bandwidth_bps = (1 / aggregation_interval_s) * bytes_per_aggregate * 8
bandwidth_savings_pct = ((raw_bandwidth_bps - aggregated_bandwidth_bps)
/ raw_bandwidth_bps * 100)
print("=== ব্যান্ডউইথ তুলনা ===")
print(f"র-ডেটা (প্রতিটি স্যাম্পল ক্লাউডে): {raw_bandwidth_bps:.0f} bps")
print(f"এজে অ্যাগ্রিগেট করে পাঠালে: {aggregated_bandwidth_bps:.0f} bps")
print(f"ব্যান্ডউইথ সাশ্রয়: {bandwidth_savings_pct:.1f}%")
# --- এজ বনাম ক্লাউড: সিদ্ধান্ত-লেটেন্সি তুলনা ---
one_way_network_latency_ms = 75 # ক্লাউড রিজিয়নে এক-পথ লেটেন্সি (illustrative)
cloud_processing_ms = 20 # ক্লাউড-সাইড প্রসেসিং সময় (illustrative)
cloud_round_trip_latency_ms = (one_way_network_latency_ms * 2) + cloud_processing_ms
edge_decision_latency_ms = 5 # লোকাল/এজ প্রসেসিং সময় (illustrative)
latency_savings_ms = cloud_round_trip_latency_ms - edge_decision_latency_ms
print("\n=== সিদ্ধান্ত-লেটেন্সি তুলনা ===")
print(f"ক্লাউডে পাঠিয়ে সিদ্ধান্ত: {cloud_round_trip_latency_ms:.0f} ms "
f"(নেটওয়ার্ক {one_way_network_latency_ms * 2} ms + প্রসেসিং {cloud_processing_ms} ms)")
print(f"এজেই সিদ্ধান্ত: {edge_decision_latency_ms:.0f} ms")
print(f"এজ প্রসেসিং দ্রুততর: {latency_savings_ms:.0f} ms")
IoT আর্কিটেকচার একটি একক স্তর নয়, বরং এজ-ফগ-ক্লাউড — তিনটি স্তরের একটি সুচিন্তিত ভাগাভাগি। কোন কাজ কোন স্তরে করা হবে তা নির্ভর করে লেটেন্সি চাহিদা, ব্যান্ডউইথ সীমাবদ্ধতা, ও কম্পিউট প্রয়োজনীয়তার উপর — পরের পাঠগুলোতে (WiFi/BLE, Zigbee/LoRaWAN, সেলুলার IoT) দেখা যাবে ভিন্ন ভিন্ন ওয়্যারলেস প্রোটোকল এই স্তরগুলোর মধ্যে সংযোগ তৈরিতে ভিন্ন ভিন্ন ট্রেড-অফ আনে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ ফগ লেয়ার ঠিক কী ভূমিকা পালন করে যা শুধু এজ বা শুধু ক্লাউড একা করতে পারে না?
ফগ একাধিক এজ ডিভাইসের ডেটা একসাথে দেখতে পারে — একটি একক এজ ডিভাইস শুধু নিজের ডেটা জানে, আর ক্লাউড অনেক দূরে থাকায় প্রতিটি সিদ্ধান্তে নেটওয়ার্ক লেটেন্সি যোগ হয়। ফগ লোকালিভাবে একাধিক ডিভাইসের মধ্যে করিলেশন (যেমন "এই রুমের সবকয়টি সেন্সর একসাথে অস্বাভাবিক রিডিং দিচ্ছে") দ্রুত ধরতে পারে, প্রি-প্রসেসিং/ফিল্টারিং করে ক্লাউডে পাঠানো ডেটার পরিমাণ কমাতে পারে — এজ ও ক্লাউডের মাঝামাঝি একটি বাস্তবসম্মত সমঝোতা।
প্র ০২ যদি এক-পথ নেটওয়ার্ক লেটেন্সি ৭৫ ms থেকে বেড়ে ২০০ ms হয়ে যায়, তাহলে ক্লাউড রাউন্ড-ট্রিপ লেটেন্সি কত হবে, আর এজ প্রসেসিং-এর সুবিধা কীভাবে বদলাবে?
নতুন রাউন্ড-ট্রিপ লেটেন্সি $= (200 \times 2) + 20 = 420$ ms হবে। এজ প্রসেসিং লেটেন্সি অপরিবর্তিত (৫ ms) থাকায় সাশ্রয় $420 - 5 = 415$ ms — অর্থাৎ নেটওয়ার্ক যত দুর্বল/ধীর হয়, এজে প্রসেসিং করার সুবিধা তত বাড়ে। এটাই কেন দুর্বল কানেক্টিভিটির পরিবেশে (গ্রামীণ এলাকা, শিল্প কারখানার ভেতরে) এজ প্রসেসিং বিশেষভাবে গুরুত্বপূর্ণ।
প্র ০৩ সব ডেটা এজেই প্রসেস করে ক্লাউডে কিছুই না পাঠানো কি সবসময় সবচেয়ে ভালো ডিজাইন?
না। এজে শুধু লোকাল, তাৎক্ষণিক সিদ্ধান্তের জন্য যথেষ্ট তথ্য থাকে — দীর্ঘমেয়াদী ট্রেন্ড বিশ্লেষণ, একাধিক সাইট/ডিভাইস জুড়ে তুলনা, বা একটি ভারী মেশিন লার্নিং মডেল ট্রেনিং করার মতো কাজ ক্লাউডের বড় স্টোরেজ ও কম্পিউট ছাড়া সম্ভব নয়। বাস্তব ডিজাইনে তাই সবসময় একটি ভারসাম্য থাকে — তাৎক্ষণিক সিদ্ধান্ত এজে/ফগে, আর ইতিহাস/অ্যানালিটিক্স ক্লাউডে।
অনুশীলন
-
পরীক্ষা করুন: উপরের কোড সেলে
aggregation_interval_s১ থেকে ৫ সেকেন্ডে বদলান — নতুনaggregated_bandwidth_bpsও ব্যান্ডউইথ সাশ্রয় % কত হবে?নতুন
aggregated_bandwidth_bps$= (1/5) \times 4 \times 8 = 6.4$ bps হবে, এবং সাশ্রয় $= (800 - 6.4)/800 \times 100 \approx 99.2\%$ — অর্থাৎ কম ঘন ঘন সামারি পাঠালে সাশ্রয় আরও বাড়ে, কিন্তু বাস্তবে খুব কম ঘন ঘন আপডেটে সিদ্ধান্তের "সতেজতা" (freshness) কমে যায় — একটি বাস্তব ট্রেড-অফ। -
চিন্তা করুন:
samples_per_sec৫০ থেকে ২০০-তে বাড়ালেraw_bandwidth_bpsও ব্যান্ডউইথ সাশ্রয় % কী হবে বলে ধারণা করেন?নতুন
raw_bandwidth_bps$= 200 \times 2 \times 8 = 3200$ bps হবে, এবং সাশ্রয় $= (3200 - 32)/3200 \times 100 \approx 99.0\%$ — যত বেশি স্যাম্পলিং রেট, তত বেশি র-ডেটা তৈরি হয়, আর তাই এজে অ্যাগ্রিগেট করার সুবিধাও (শতাংশে) তত বাড়ে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার, এমবেডেড C, GPIO, টাইমার/PWM/ADC, সিরিয়াল প্রোটোকল, RTOS, সেন্সর/অ্যাকচুয়েটর, IoT আর্কিটেকচার, ওয়্যারলেস প্রোটোকল, MQTT/CoAP ও IoT সিকিউরিটি — বাকি পাঠগুলো শীঘ্রই যুক্ত হবে।
- Computer Networks কোর্স সহোদর কোর্স সাধারণ নেটওয়ার্কিং স্তর ও প্রোটোকলের ভিত্তি সেই কোর্সেই তৈরি হয়েছে — এই কোর্স কনস্ট্রেইন্ড 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 ও আরও অনেক কোর্স — সব এক জায়গায়।