ওয়াচডগ টাইমার
এই পাঠে যা শিখবেন
- ওয়াচডগ টাইমার কী এবং কেন প্রায় সব বাণিজ্যিক এমবেডেড প্রোডাক্টে এটি ব্যবহৃত হয়
- কাউন্টডাউন রেজিস্টার, রিলোড ভ্যালু, এবং "petting"/"kicking" এর প্রক্রিয়া
- কেন ওয়াচডগ টাইমআউট মান খুব ছোট বা খুব বড় হলে সমস্যা হতে পারে
- একটি সত্যিকারের Python সিমুলেশন — সুস্থ বনাম হ্যাং হওয়া মেইন লুপে WDT-এর আচরণ
১ · ওয়াচডগ টাইমার আসলে কী সমস্যার সমাধান করে
এমবেডেড ফার্মওয়্যার প্রায়ই সম্পূর্ণ unattended অবস্থায় চলে — বছরের পর বছর কোনো মানুষের হস্তক্ষেপ ছাড়াই (যেমন একটি রিমোট সেন্সর নোড, একটি ইন্ডাস্ট্রিয়াল কন্ট্রোলার)। যদি ফার্মওয়্যারে কোনো বাগের কারণে একটি অসীম লুপ, একটি ডেডলক (L30-এর প্রায়োরিটি ইনভার্সনের মতো), বা কোনো অপ্রত্যাশিত ক্র্যাশ ঘটে, তাহলে ডিভাইসটি চিরতরে "hang" অবস্থায় আটকে যেতে পারে — আর কেউ গিয়ে বাটন চেপে রিস্টার্ট করবে না।
ওয়াচডগ টাইমারWatchdog Timer (WDT)একটি স্বাধীন হার্ডওয়্যার কাউন্টডাউন টাইমার যা নিয়মিত "pet" না করা হলে চিপকে স্বয়ংক্রিয়ভাবে রিসেট করে। এই সমস্যার সমাধান — এটি একটি স্বাধীন হার্ডওয়্যার কাউন্টডাউন রেজিস্টার, সাধারণত CPU থেকে আলাদা একটি ক্লক সোর্স দিয়ে চালিত (যাতে CPU হ্যাং করলেও ওয়াচডগ নিজে চলতে থাকে)। ফার্মওয়্যারের দায়িত্ব হলো নিয়মিত বিরতিতে এই কাউন্টারকে "pet"/"kick" করা — অর্থাৎ এটিকে আবার তার সর্বোচ্চ রিলোড ভ্যালুতে ফিরিয়ে দেওয়া। যদি ফার্মওয়্যার হ্যাং করে যায় এবং pet() কল বন্ধ হয়ে যায়, কাউন্টার ক্রমাগত কমতে কমতে শূন্যে পৌঁছে যায় — আর ঠিক তখনই হার্ডওয়্যার স্বয়ংক্রিয়ভাবে পুরো চিপকে রিসেট করে দেয় (L07-এর রিসেট সোর্সগুলোর একটি)।
২ · কাউন্টডাউন, রিলোড ভ্যালু ও টাইমআউট
বাস্তবে WDT একটি রেজিস্টার হিসেবে বাস্তবায়িত হয় যা প্রতি ক্লক টিকে (বা প্রিস্কেলড টিকে — L18-এর টাইমার/ কাউন্টার ধারণার মতোই) ১ করে কমে। যখন ফার্মওয়্যার pet()/kick() কল করে, রেজিস্টারটি আবার তার সর্বোচ্চ "রিলোড ভ্যালু"-তে ফিরে যায়। রিলোড ভ্যালু ও ক্লক ফ্রিকোয়েন্সি একসাথে ওয়াচডগ টাইমআউট নির্ধারণ করে — এই টাইমআউট এমনভাবে বেছে নিতে হয় যেন স্বাভাবিক অপারেশনের সবচেয়ে ধীর ধাপও pet() কল করার আগেই শেষ হয়ে যায়, কিন্তু আবার এত বড় না হয় যে একটি প্রকৃত হ্যাং ঘণ্টার পর ঘণ্টা ধরে ধরা না পড়ে।
টাইমআউট খুব ছোট হলে — স্বাভাবিক কিন্তু সাময়িকভাবে ব্যস্ত কোনো ধাপ (যেমন একটি বড় সেন্সর ডেটা প্রসেস করা) দুর্ঘটনাক্রমে ওয়াচডগ রিসেট ট্রিগার করতে পারে, যদিও ফার্মওয়্যার আসলে হ্যাং করেনি। টাইমআউট খুব বড় হলে — একটি প্রকৃত হ্যাং ধরা পড়তে বেশি সময় লাগবে, ডিভাইসটি বেশিক্ষণ অকার্যকর অবস্থায় থাকবে। বাস্তব ডিজাইনে এই টাইমআউট বেছে নেওয়া হয় স্বাভাবিক অপারেশনের সবচেয়ে ধীর legitimate ধাপের সময় পরিমাপ করে, তার উপর একটি নিরাপদ মার্জিন যোগ করে।
নিচের কোড সেলে একটি ওয়াচডগ সিমুলেট করা হয়েছে — প্রতিটি "টিক" এ কাউন্টার ১ কমে, এবং মেইন লুপ একটি নির্দিষ্ট বিরতিতে pet() কল করে। দুটি দৃশ্য তুলনা করা হয়েছে: একটি স্বাভাবিক মেইন লুপ (কখনো হ্যাং করে না) এবং একটি যা একটি নির্দিষ্ট টিকে হ্যাং করে যায় (তারপর আর কখনো pet() কল করে না)।
WDT_RELOAD = 100 # ওয়াচডগ কাউন্টার রিলোড ভ্যালু (সিমুলেটেড টিক ইউনিট)
def simulate_watchdog(total_ticks, pet_interval, hang_at_tick=None):
"""
total_ticks : সিমুলেশন সর্বোচ্চ কতো টিক চলবে
pet_interval : মেইন লুপ স্বাভাবিক অবস্থায় প্রতি কত টিকে pet() কল করে
hang_at_tick : কোন টিক থেকে মেইন লুপ হ্যাং করে যাবে (None মানে কখনো হ্যাং করে না)
রিটার্ন করে (reset_occurred, reset_tick, log)
"""
counter = WDT_RELOAD
log = []
for t in range(1, total_ticks + 1):
hung = hang_at_tick is not None and t >= hang_at_tick
counter -= 1 # হার্ডওয়্যার কাউন্টার প্রতি টিকে কমে
if counter <= 0:
log.append(f"tick {t:3d}: WDT_COUNTER = 0 -> !! ওয়াচডগ রিসেট ট্রিগার হলো !!")
return True, t, log
if not hung and t % pet_interval == 0:
counter = WDT_RELOAD
log.append(f"tick {t:3d}: pet() কল হলো, WDT_COUNTER রিলোড -> {WDT_RELOAD}")
return False, None, log
print("=== দৃশ্য ১: স্বাভাবিক (healthy) মেইন লুপ, নিয়মিত pet() কল, কখনো হ্যাং করে না ===")
reset1, tick1, log1 = simulate_watchdog(total_ticks=400, pet_interval=40)
for line in log1[:5]:
print(" ", line)
print(f" ... (মোট {len(log1)}টি pet() কল লগ হয়েছে)")
print(f"রিসেট ঘটলো? {reset1}")
print("\n=== দৃশ্য ২: tick 85-এ ফার্মওয়্যার হ্যাং করে গেলো (এরপর আর pet() কল হয় না) ===")
reset2, tick2, log2 = simulate_watchdog(total_ticks=400, pet_interval=40, hang_at_tick=85)
for line in log2:
print(" ", line)
print(f"রিসেট ঘটলো? {reset2}, ঠিক কোন টিকে: {tick2}")
ওয়াচডগ টাইমার একটি সাধারণ কিন্তু অত্যন্ত কার্যকর রিলায়েবিলিটি মেকানিজম — এটি ফার্মওয়্যারের ভেতরের লজিক না বুঝেই শুধু "নিয়মিত pet() হচ্ছে কিনা" পর্যবেক্ষণ করে হ্যাং শনাক্ত করে এবং স্বয়ংক্রিয়ভাবে রিকভারি (রিসেট) ট্রিগার করে। প্রায়োরিটি ইনভার্সনের (L30) কারণে একটি টাস্ক দীর্ঘ সময় ব্লক হয়ে গেলেও ওয়াচডগ সেটিকে হ্যাং হিসেবে ধরে রিসেট করতে পারে — একটি ঐতিহাসিকভাবে সুপরিচিত উদাহরণ হলো Mars Pathfinder মিশনে ঘটে যাওয়া প্রায়োরিটি-ইনভার্সন-জনিত ওয়াচডগ রিসেট। M35-এ দেখা যাবে ওয়াচডগ কীভাবে রিডানডেন্সি ও চেকসামের পাশাপাশি সামগ্রিক সিস্টেম রিলায়েবিলিটির একটি অংশ গঠন করে।
ভাবনার প্রশ্ন
প্রতিটি প্রশ্ন নিজে কিছুক্ষণ ভাবুন — তারপর "→ উত্তর" চাপুন।
প্র ০১ যদি একজন ডেভেলপার ভুলবশত pet() কলটি মেইন লুপের মধ্যে না রেখে, একটি ইন্টারাপ্ট সার্ভিস রুটিনে (ISR-এ) প্রতি টিকে নিঃশর্তভাবে কল করেন, তাহলে ওয়াচডগ সুরক্ষার কী হবে?
এটি ওয়াচডগকে কার্যত অকার্যকর করে দেবে — কারণ ইন্টারাপ্ট চলতে থাকলে (ISR নিজে ঠিকমতো কাজ করলে) মেইন লুপ হ্যাং করে থাকলেও pet() কল হতেই থাকবে, তাই কাউন্টার কখনো শূন্যে পৌঁছাবে না, রিসেটও ঘটবে না — যদিও মূল অ্যাপ্লিকেশন লজিক (মেইন লুপ) আসলে আটকে আছে। এই কারণে সঠিক প্র্যাকটিস হলো pet() কল সবসময় মেইন অ্যাপ্লিকেশন লজিকের সাথে যুক্ত করা — যেন সেই লজিক সত্যিই এগোচ্ছে তা প্রমাণিত হলেই কাউন্টার রিলোড হয়।
প্র ০২
উপরের কোড সেলে pet_interval-এর মান WDT_RELOAD-এর চেয়ে বড় (যেমন ১৫০)
করলে কী হবে বলে আপনার ধারণা, স্বাভাবিক (হ্যাং না হওয়া) দৃশ্যেও?
তাহলে ফার্মওয়্যার হ্যাং না করেও ভুলবশত রিসেট ট্রিগার হবে — কারণ কাউন্টার প্রতি টিকে ১ করে কমে ১০০
থেকে শুরু হয়ে ১৫০ টিক অপেক্ষা করার আগেই (মাত্র ১০০ টিকেই) শূন্যে পৌঁছে যাবে, অথচ pet() কল তখনো হয়নি।
এটাই দেখায় কেন pet_intervalকে সবসময় WDT_RELOAD-এর চেয়ে যথেষ্ট ছোট রাখতে
হয় — একটি নিরাপদ মার্জিনসহ, যেমন উপরের কোডে ৪০ বনাম ১০০।
প্র ০৩ ওয়াচডগ রিসেট কি একটি বাগ "ঠিক করে দেয়", নাকি শুধু সাময়িকভাবে সিস্টেমকে সচল রাখে?
ওয়াচডগ রিসেট মূল বাগটি ঠিক করে না — এটি শুধু সিস্টেমকে একটি জানা-ভালো (known-good) স্টেটে ফিরিয়ে নিয়ে যায় (চিপ পুনরায় বুট হয়, L07-এর রিসেট সিকোয়েন্স চলে) যাতে ডিভাইসটি সম্পূর্ণ অচল হয়ে না থাকে। মূল বাগ (যে কারণে হ্যাং হয়েছিল) কোডে থেকেই যায় এবং ভবিষ্যতে আবার ঘটতে পারে — তাই ওয়াচডগকে "নিরাপত্তা জাল" হিসেবে দেখা উচিত, ডিবাগিং বা সঠিক কোড লেখার বিকল্প হিসেবে নয়।
অনুশীলন
-
চিন্তা করুন: উপরের কোড সেলে
WDT_RELOAD-এর মান ১০০ থেকে ৫০-এ কমালে (pet_interval=40অপরিবর্তিত রেখে), দৃশ্য ১ (স্বাভাবিক লুপ) কি এখনো কখনো রিসেট ছাড়াই চলবে?হ্যাঁ, তখনও চলবে — কারণ কাউন্টার প্রতি ৪০ টিকে রিলোড হয় এবং রিলোড ভ্যালু (৫০) তার চেয়ে বেশি, তাই কাউন্টার কখনো ১০-এর নিচে নামার আগেই আবার রিলোড হয়ে যাবে। তবে মার্জিন কমে গেছে (৫০-৪০=১০ টিকের বাফার, আগে ছিল ১০০-৪০=৬০ টিক) — বাস্তবে এটি একটি ঝুঁকিপূর্ণ, টাইট মার্জিনের ডিজাইন হবে, সামান্য দেরি হলেই ভুল রিসেট ঘটতে পারে।
-
পরীক্ষা করুন: উপরের কোড সেলে
simulate_watchdog(total_ticks=400, pet_interval=40, hang_at_tick=5)কল করে দেখুন — অর্থাৎ মেইন লুপ প্রায় শুরুতেই হ্যাং করে যায়। Run চেপেreset_tick-এর মান কীভাবে বদলায় দেখুন।যেহেতু কোনো pet() কল হওয়ার আগেই (t=5-তে) হ্যাং হয়ে যাচ্ছে, কাউন্টার তার প্রাথমিক মান
WDT_RELOAD=100থেকে একটানা কমতে থাকবে এবং t=100 টিকে শূন্যে পৌঁছে রিসেট ট্রিগার করবে — কোড সেলটি রান করলে ঠিক এই মানটিইreset_tickহিসেবে প্রিন্ট হবে, যা প্রমাণ করে হ্যাং যত আগে ঘটুক না কেন, ওয়াচডগ সবসময় সর্বোচ্চWDT_RELOADটিকের মধ্যে সেটি ধরে ফেলবে।
আরও পড়ুন · ABCL TECH-এ আপনার পরবর্তী পদক্ষেপ
- পরবর্তী পাঠ: পাওয়ার বাজেটিং ও ব্যাটারি লাইফ এস্টিমেশন L34 L32-এর ওয়েটেড-এভারেজ কারেন্ট গণনাকে ব্যাটারি ক্যাপাসিটির সাথে মিলিয়ে পূর্ণাঙ্গ ব্যাটারি-লাইফ এস্টিমেশন।
- এমবেডেড সিস্টেম রিলায়েবিলিটি ও ফল্ট টলারেন্স L35 ওয়াচডগের পাশাপাশি রিডানডেন্সি, গ্রেসফুল ডিগ্রেডেশন ও চেকসাম দিয়ে সামগ্রিক সিস্টেম রিলায়েবিলিটি।
- কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ মাইক্রোপ্রসেসর আর্কিটেকচার, এমবেডেড C, GPIO, টাইমার/PWM/ADC, সিরিয়াল প্রোটোকল, RTOS, সেন্সর/অ্যাকচুয়েটর, IoT আর্কিটেকচার, ওয়্যারলেস প্রোটোকল, MQTT/CoAP ও IoT সিকিউরিটি।