কেস স্টাডি — একটি স্মার্ট এমবেডেড/IoT ডিভাইস ডিজাইন করা
এই পাঠে যা শিখবেন
- একটি এমবেডেড/IoT ডিভাইসের ডিজাইন প্রক্রিয়াকে কীভাবে সুশৃঙ্খল ধাপে ভাঙা যায়
- মাইক্রোকন্ট্রোলার, সেন্সর, কমিউনিকেশন প্রোটোকল বাছাই করার সময় বাস্তবে কোন ট্রেড-অফগুলো বিবেচনা করতে হয়
- একটি নির্দিষ্ট ডিউটি সাইকেলের জন্য পাওয়ার বাজেট ও ব্যাটারি-লাইফ কীভাবে সত্যিকারের সংখ্যায় গণনা করতে হয়
- ডিজাইনের প্রথম দিন থেকেই সিকিউরিটি বিবেচনা কেন আলাদা করে যোগ করতে হয়
১ · সমস্যা — একটি স্মার্ট সেচ মাটির-আর্দ্রতা কন্ট্রোলার
ধরা যাক আমাদের কাজ হলো একটি ছোট বাগান/গ্রিনহাউজ বেডের জন্য একটি ডিভাইস ডিজাইন করা যা মাটির আর্দ্রতা মাপে, প্রয়োজনে স্বয়ংক্রিয়ভাবে একটি পানির পাম্প চালায়, এবং রিডিং একটি ড্যাশবোর্ডে পাঠায় — যাতে মালিক দূর থেকেও দেখতে পারেন মাটি কতটা শুকনো। ডিভাইসটি বাগানে বসানো থাকবে, তাই এটিকে ব্যাটারিতে চলতে হবে এবং মাসের পর মাস ছাড়াই কাজ করতে হবে — এই একটি বাস্তবতাই বাকি প্রতিটি সিদ্ধান্তকে প্রভাবিত করে।
২ · মাইক্রোকন্ট্রোলার বাছাই (মডিউল ১)
মডিউল ১-এ আলোচিত জনপ্রিয় মাইক্রোকন্ট্রোলার ফ্যামিলিগুলোর (8051, AVR, PIC, ARM Cortex-M, ESP32/ESP8266, RISC-V) মধ্য থেকে এই কাজের জন্য ESP32-জাতীয় একটি চিপ যুক্তিসঙ্গত পছন্দ — কারণ এতে WiFi বিল্ট-ইন থাকায় আলাদা কোনো রেডিও মডিউল যোগ করতে হয় না (কম্পোনেন্ট সংখ্যা কম, বোর্ড সহজ — L01-এর মাইক্রোকন্ট্রোলার-বনাম-মাইক্রোপ্রসেসর যুক্তিরই একটি প্রয়োগ), এবং এতে যথেষ্ট GPIO, একাধিক ADC চ্যানেল ও PWM-সক্ষম টাইমার আছে — যা ঠিক এই কাজের জন্য দরকার। যদি WiFi-এর বদলে অনেক দূরের একটি খেতে বসাতে হতো (কয়েক কিলোমিটার দূরত্ব), তাহলে মডিউল ১০-এর LoRaWAN-সক্ষম একটি চিপ/মডিউল বেশি যুক্তিসঙ্গত হতো — অর্থাৎ MCU বাছাই আসলে কানেক্টিভিটি সিদ্ধান্তের সাথে জড়িত, বিচ্ছিন্ন নয়।
এই স্কেলের ডিভাইসের জন্য একটি মাইক্রোপ্রসেসর + বাহ্যিক RAM/Flash/GPIO চিপ দিয়ে ডিজাইন করার কোনো কারণ নেই — কাজটি ছোট, নির্দিষ্ট, আর মাইক্রোকন্ট্রোলারের একচিপ ইন্টিগ্রেশনই এখানে কম দাম, কম বোর্ড স্পেস ও কম পাওয়ার এনে দেয় (L01-এর মূল তুলনা)। মাইক্রোপ্রসেসর-ভিত্তিক এমবেডেড লিনাক্স ডিজাইন তখনই যুক্তিসঙ্গত হতো যদি ডিভাইসটিকে জটিল ইমেজ প্রসেসিং বা একটি পূর্ণাঙ্গ ফাইলসিস্টেম চালাতে হতো।
৩ · সেন্সর নির্বাচন (মডিউল ৯)
একটি ক্যাপাসিটিভ মাটির-আর্দ্রতা সেন্সর বাছাই করা হয়েছে (রেজিস্টিভ সেন্সরের বদলে — ক্যাপাসিটিভ সেন্সর মাটিতে কম করোশন করে, দীর্ঘমেয়াদে বেশি নির্ভরযোগ্য)। এই সেন্সরের আউটপুট একটি অ্যানালগ ভোল্টেজ, যা ESP32-এর বিল্ট-ইন ADC দিয়ে পড়া হবে — মডিউল ৫-এ শেখা ADC কোয়ান্টাইজেশন গণিত এখানে সরাসরি প্রযোজ্য, আর মডিউল ৯-এর দুই-বিন্দু ক্যালিব্রেশন প্যাটার্ন (শুকনো ও ভেজা অবস্থায় রেফারেন্স রিডিং নিয়ে) ব্যবহার করে raw ADC কোডকে "আর্দ্রতা %" এককে রূপান্তর করা হবে। এই সম্পূর্ণ প্যাটার্নটি এই কোর্সের শেষ পাঠ, ক্যাপস্টোন (L57), এ পুরোপুরি কোড আকারে দেখানো হয়েছে।
৪ · কমিউনিকেশন — লোকাল ও কানেক্টিভিটি (মডিউল ৬, ১০-১১)
স্থানীয়ভাবে, MCU-এর একটি GPIO পিন PWM-এর মাধ্যমে পাম্পের ড্রাইভার ট্রানজিস্টর/রিলে নিয়ন্ত্রণ করে (মডিউল ৫)। যদি সেন্সরটি একটি বাহ্যিক I2C ADC ব্রেকআউট বোর্ড হতো (কিছু বাণিজ্যিক সেন্সর বোর্ড এভাবেই আসে), তাহলে মডিউল ৬-এর I2C প্রোটোকল দিয়ে রিডিং সংগ্রহ করা হতো — L57-এ ঠিক এই বিকল্পটিও সিমুলেট করে দেখানো হয়েছে। দূরবর্তী কানেক্টিভিটির জন্য, যেহেতু ডিভাইসটি বাড়ির WiFi-এর রেঞ্জের মধ্যেই থাকবে, মডিউল ১০-এর WiFi সরাসরি যথেষ্ট (Zigbee/LoRaWAN-এর মতো লো-পাওয়ার WAN দরকার নেই, কারণ দূরত্ব বেশি না) — আর মডিউল ১১-এর MQTT প্রোটোকল বেছে নেওয়া হয়েছে HTTP-এর বদলে, কারণ MQTT-এর পার্সিস্টেন্ট কানেকশন ছোট, ঘনঘন রিডিং পাঠানোর জন্য কম ওভারহেড তৈরি করে (মডিউল ১১-এর HTTP-বনাম-MQTT তুলনার সরাসরি প্রয়োগ)।
৫ · পাওয়ার বাজেট (মডিউল ৮) — একটি সত্যিকারের গণনা
ডিভাইসটি প্রতি ৩০ মিনিটে একবার জেগে ওঠে (ডিউটি সাইকেল), সেন্সর পড়ে, প্রয়োজনে খুব সংক্ষিপ্ত সময়ের জন্য WiFi চালু করে একটি MQTT বার্তা পাঠায়, তারপর আবার ডিপ স্লিপে চলে যায় (মডিউল ৮-এর লো-পাওয়ার মোড ধারণা)। নিচের কোড সেলে মডিউল ৮/L34-এর ব্যাটারি-লাইফ প্যাটার্ন প্রয়োগ করে — সক্রিয় (active), ট্রান্সমিট (transmit) ও স্লিপ (sleep) — তিনটি মোডের ওয়েটেড-এভারেজ কারেন্ট ড্র থেকে সত্যিকারের একটি ব্যাটারি-লাইফ সংখ্যা গণনা করা হচ্ছে।
সূত্রটি হলো —
$$\text{average current} = \frac{I_{active} \cdot t_{active} + I_{tx} \cdot t_{tx} + I_{sleep} \cdot t_{sleep}}{t_{cycle}}$$ $$\text{battery life} = \frac{\text{capacity (mAh)}}{\text{average current (mA)}}$$# মডিউল ৮/L34-এর ব্যাটারি-লাইফ প্যাটার্ন -- এখানে সেচ কন্ট্রোলারের নির্দিষ্ট ডিউটি সাইকেলে প্রয়োগ করা হচ্ছে
active_current_mA = 30 # ADC রিড + কম্পিউট চলাকালীন কারেন্ট (illustrative)
active_time_s = 0.05 # সেন্সর রিড করতে সময়
tx_current_mA = 120 # WiFi জয়েন + MQTT পাবলিশ চলাকালীন কারেন্ট (illustrative)
tx_time_s = 2.0 # WiFi কানেক্ট + বার্তা পাঠাতে সময়
sleep_current_mA = 0.01 # ESP32 ডিপ-স্লিপ মোডে কারেন্ট (illustrative, সাধারণত মাইক্রোঅ্যাম্প রেঞ্জে)
cycle_period_s = 30 * 60 # প্রতি ৩০ মিনিটে একবার চক্র
sleep_time_s = cycle_period_s - active_time_s - tx_time_s
charge_per_cycle_mA_s = (
active_current_mA * active_time_s
+ tx_current_mA * tx_time_s
+ sleep_current_mA * sleep_time_s
)
average_current_mA = charge_per_cycle_mA_s / cycle_period_s
battery_capacity_mAh = 2000 # ২টি AA / একটি ছোট Li-ion প্যাক (illustrative)
battery_life_hours = battery_capacity_mAh / average_current_mA
battery_life_days = battery_life_hours / 24
battery_life_years = battery_life_days / 365
print(f"প্রতি চক্রে সক্রিয় সময়: {active_time_s + tx_time_s:.2f} সে, স্লিপ সময়: {sleep_time_s:.2f} সে")
print(f"গড় কারেন্ট ড্র: {average_current_mA:.4f} mA")
print(f"ব্যাটারি ক্যাপাসিটি: {battery_capacity_mAh} mAh")
print(f"আনুমানিক ব্যাটারি-লাইফ: {battery_life_hours:.1f} ঘণ্টা "
f"= {battery_life_days:.1f} দিন = {battery_life_years:.2f} বছর")৬ · সিকিউরিটি বিবেচনা (মডিউল ১২)
ডিজাইনের প্রথম দিন থেকেই কয়েকটি সিকিউরিটি সিদ্ধান্ত নেওয়া দরকার — WiFi ও MQTT ব্রোকারের ক্রেডেনশিয়াল কখনোই ফার্মওয়্যারে হার্ডকোড করা উচিত নয় (প্রতিটি ইউনিটের জন্য আলাদা, প্রভিশনিং-এর সময় সেট হওয়া ক্রেডেনশিয়াল দরকার), এবং ফার্মওয়্যার আপডেট করার একটি নিরাপদ পথ (OTA — over-the-air) শুরু থেকেই পরিকল্পনা করে রাখা উচিত, কারণ বাগানে বসানো ডিভাইসে বারবার গিয়ে ম্যানুয়ালি রিফ্ল্যাশ করা বাস্তবসম্মত নয়। মডিউল ১২-এর সিকিউর বুট ও এনক্রিপশন ধারণাগুলো এখানে প্রযোজ্য — বিস্তারিত Cybersecurity কোর্সের সাধারণ সিকিউরিটি ভিত্তির উপর দাঁড়িয়ে। পরের পাঠে (L56) এই ধরনের সিদ্ধান্ত না নিলে কী ভুল হয় তা বিস্তারিত দেখা হবে।
একটি বাস্তব এমবেডেড/IoT ডিভাইস ডিজাইন কখনোই একটি বিচ্ছিন্ন সিদ্ধান্ত নয় — MCU বাছাই কানেক্টিভিটিকে প্রভাবিত করে, কানেক্টিভিটি পাওয়ার বাজেটকে প্রভাবিত করে, আর পাওয়ার বাজেট আবার ডিউটি সাইকেল ও তাই MCU-এর লো-পাওয়ার মোড সাপোর্টকে প্রভাবিত করে। এই কোর্সের প্রতিটি মডিউল আসলে এই একই ডিজাইন প্রক্রিয়ার একটি টুকরো।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ যদি ডিভাইসটিকে প্রতি ৩০ মিনিটের বদলে প্রতি ৫ মিনিটে একবার রিডিং পাঠাতে হতো, ব্যাটারি-লাইফের কী হতো বলে আপনার মনে হয়?
চক্র ৬ গুণ বেশি ঘন ঘন হওয়ায় প্রতি একক সময়ে WiFi ট্রান্সমিট ঘটনাও প্রায় ৬ গুণ বেশি হবে, তাই গড় কারেন্ট
ড্র উল্লেখযোগ্যভাবে বাড়বে এবং ব্যাটারি-লাইফ কমবে — যদিও ডিপ-স্লিপ কারেন্ট এখনো এত ছোট যে সম্পূর্ণ
রৈখিক ৬ গুণ কমা নাও হতে পারে। উপরের কোড সেলে cycle_period_s-কে 5 * 60 করে
Run চাপলে সত্যিকারের সংখ্যাটি দেখা যাবে।
প্র ০২ মাটির-আর্দ্রতা সেন্সরের বদলে যদি একটি ক্যামেরা মডিউল দিয়ে গাছের ছবি তুলে পাঠাতে হতো, উপরের ডিজাইন সিদ্ধান্তগুলোর মধ্যে কোনটি বদলাতে হতো?
প্রায় সবগুলোই। একটি ক্যামেরা ছবি অনেক বেশি ডেটা তৈরি করে — সাধারণ ADC রিডিংয়ের বদলে একটি বেশি শক্তিশালী মাইক্রোকন্ট্রোলার (বা এমনকি একটি মাইক্রোপ্রসেসর-ভিত্তিক এমবেডেড লিনাক্স বোর্ড) দরকার হতো, MQTT-এর বদলে বড় পেলোড পাঠানোর উপযোগী একটি প্রোটোকল/স্ট্র্যাটেজি দরকার হতো, আর পাওয়ার বাজেট অনেক বেশি হতো (ছবি তোলা ও পাঠানো অনেক বেশি এনার্জি-খরচী) — ফলে ব্যাটারি-লাইফ অনেক কমে যেত অথবা সোলার চার্জিং যোগ করতে হতো।
প্র ০৩
উপরের কোড সেলে tx_time_s কমিয়ে আনার (যেমন WiFi কানেকশন দ্রুততর করার) সুবিধা কী?
charge_per_cycle_mA_s-এর সূত্রে tx_current_mA * tx_time_s পদটি সবচেয়ে বেশি
অবদান রাখে (কারণ tx_current_mA অন্য দুটোর তুলনায় অনেক বড়) — তাই tx_time_s
কমালে মোট চার্জ খরচ সরাসরি কমবে, এবং তাই গড় কারেন্ট কমে ব্যাটারি-লাইফ বাড়বে। বাস্তবে এটিই কারণ কেন
ইঞ্জিনিয়াররা WiFi কানেকশন সেটআপ সময় কমানো নিয়ে এত মনোযোগ দেন — এটি লো-পাওয়ার ডিজাইনের সবচেয়ে বড়
লিভারগুলোর একটি।
অনুশীলন
-
চিন্তা করুন: উপরের কোড সেলে
battery_capacity_mAhদ্বিগুণ (৪০০০ mAh) করলেbattery_life_days-এর কী হবে বলে আপনার ধারণা?সূত্র অনুযায়ী
battery_life_hours = capacity / average_current— যেহেতুaverage_current_mAক্যাপাসিটির উপর নির্ভর করে না, ক্যাপাসিটি দ্বিগুণ করলে ব্যাটারি-লাইফও ঠিক দ্বিগুণ হবে (≈ ১১৫৬ দিন, ≈ ৩.১৭ বছর)। -
পরীক্ষা করুন: কোড সেলে
sleep_current_mA-কে ০.১ mA করুন (অর্থাৎ ১০ গুণ বেশি লিকি স্লিপ মোড ধরে) এবং Run চেপেaverage_current_mAওbattery_life_daysকতটা বদলায় দেখুন।যেহেতু ডিভাইসটি চক্রের প্রায় পুরো সময় (≈ ১৭৯৮ সেকেন্ড, ১৮০০ সেকেন্ডের মধ্যে) স্লিপ মোডে থাকে,
sleep_current_mA-এর যেকোনো বৃদ্ধি গড় কারেন্টে ভারী প্রভাব ফেলে — ১০ গুণ বৃদ্ধিতে গড় কারেন্ট উল্লেখযোগ্যভাবে বেড়ে যাবে এবং ব্যাটারি-লাইফ বড় অংশে কমে যাবে, প্রমাণ করে কেন ডিপ-স্লিপ কারেন্ট এত গুরুত্বপূর্ণ একটি ডেটাশিট স্পেসিফিকেশন।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ দেখুন L56 এমবেডেড ও IoT ডিজাইনের সাধারণ ভুল — এই পাঠের সিদ্ধান্তগুলো ভুলভাবে নিলে কী সমস্যা হয়।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার থেকে শুরু করে RTOS, সেন্সর/অ্যাকচুয়েটর, 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 ও আরও অনেক কোর্স — সব এক জায়গায়।