পাঠ ২৮ · ৫৭-এর মধ্যে · মডিউল ৭
Home / Courses / Microprocessors, Embedded Systems & IoT / রিয়েল-টাইম সিস্টেম

রিয়েল-টাইম সিস্টেম — হার্ড বনাম সফট রিয়েল-টাইম

Real-time systems — hard vs soft real-time
৮ মিনিট পড়া মধ্যম · Intermediate Python সিমুলেশনসহ সম্পূর্ণ বাংলায়

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

  • "রিয়েল-টাইম" শব্দের সঠিক সংজ্ঞা — গতি নয়, বরং সময়ানুবর্তিতার নিশ্চয়তা
  • হার্ড বনাম সফট রিয়েল-টাইম সিস্টেমের পার্থক্য, বাস্তব উদাহরণসহ
  • একটি সত্যিকারের সিমুলেশন যা টাস্ক শ্রেণীবদ্ধ করে ও রিলায়েবিলিটি গণনা করে
  • এই সংজ্ঞাগুলো কীভাবে পরবর্তী পাঠের (L29-L30) RTOS টাস্ক শিডিউলিং-এর ডিজাইন সিদ্ধান্তকে প্রভাবিত করে

১ · "রিয়েল-টাইম" মানে কী

একটি সাধারণ ভুল ধারণা — "রিয়েল-টাইম সিস্টেম" মানে "খুব দ্রুত সিস্টেম"। বাস্তবে, রিয়েল-টাইম সিস্টেমের সংজ্ঞা গতি নিয়ে নয়, নিশ্চয়তা নিয়ে: একটি রিয়েল-টাইম সিস্টেমে প্রতিটি টাস্কের একটি ডেডলাইন থাকে, আর সিস্টেমের সঠিকতা নির্ভর করে ফলাফল সঠিক হওয়ার পাশাপাশি সেটি সময়মতো আসার উপরও। একটি সুপারকম্পিউটার যদি একটি নির্দিষ্ট ডেডলাইনের গ্যারান্টি দিতে না পারে, সেটি রিয়েল-টাইম নয় — অথচ একটি ধীরগতির ৮-বিট মাইক্রোকন্ট্রোলার যদি প্রতিবার নিশ্চিতভাবে তার ডেডলাইনের মধ্যে কাজ শেষ করতে পারে, সেটি একটি রিয়েল-টাইম সিস্টেম।

২ · হার্ড রিয়েল-টাইম বনাম সফট রিয়েল-টাইম

হার্ড রিয়েল-টাইমHard Real-Timeএকটি ডেডলাইন মিস হওয়া মানে সিস্টেম ফেইলিউর — আউটপুট যত সঠিকই হোক, দেরিতে এলে সেটি সম্পূর্ণ মূল্যহীন বা বিপজ্জনক। সিস্টেমে একটি ডেডলাইন মিস হওয়া মানে সম্পূর্ণ সিস্টেম ফেইলিউর — আউটপুট যত সঠিকই হোক না কেন, দেরিতে এলে সেটি মূল্যহীন বা এমনকি বিপজ্জনক। উদাহরণ: গাড়ির এয়ারব্যাগ ডিপ্লয়মেন্ট (সংঘর্ষের কয়েক মিলিসেকেন্ডের মধ্যে না ফুলালে সুরক্ষা কার্যত অকার্যকর), অ্যান্টি-লক ব্রেকিং সিস্টেম-এর ব্রেক-পালস টাইমিং, একটি পেসমেকারের বৈদ্যুতিক পালস।

সফট রিয়েল-টাইমSoft Real-Timeএকটি ডেডলাইন মিস হলে আউটপুটের কোয়ালিটি/ইউজার এক্সপেরিয়েন্স কমে যায়, কিন্তু সিস্টেম সম্পূর্ণ ব্যর্থ হয় না। সিস্টেমে একটি ডেডলাইন মিস হলে আউটপুটের কোয়ালিটি বা ইউজার এক্সপেরিয়েন্স কমে যায়, কিন্তু সিস্টেম সম্পূর্ণ ব্যর্থ হয় না — কাজটি এখনও কিছুটা মূল্যবান থাকে। উদাহরণ: একটি ভিডিও স্ট্রিমের একটি ফ্রেম সামান্য দেরিতে এলে সামান্য কাঁপুনি (jitter) দেখা যায়, কিন্তু ভিডিও পুরোপুরি বন্ধ হয়ে যায় না; একটি সেন্সর নোডের একটি রিডিং সামান্য দেরিতে ক্লাউডে পৌঁছালে ড্যাশবোর্ডে সামান্য পুরোনো ডেটা দেখা যায়, কিন্তু সিস্টেম ক্র্যাশ করে না।

টাস্ক সম্পন্ন হলো — ডেডলাইনের সাথে তুলনা সময়মতো সম্পন্ন (met) স্বাভাবিক কার্যক্রম সফট মিস কোয়ালিটি কমে, ফেইলিউর নয় হার্ড মিস সম্পূর্ণ সিস্টেম ফেইলিউর
একই "ডেডলাইন মিস" ঘটনা — কিন্তু টাস্কের ধরন (হার্ড না সফট) অনুযায়ী এর পরিণতি সম্পূর্ণ ভিন্ন।

৩ · একটি সত্যিকারের সিমুলেশন — টাস্ক শ্রেণীবদ্ধকরণ ও রিলায়েবিলিটি

নিচের কোডে কয়েকটি টাস্কের ডেডলাইন ও প্রকৃত সম্পন্ন-হওয়ার সময় দেওয়া আছে। প্রতিটি টাস্ক হার্ড বা সফট হিসেবে ট্যাগ করা, আর কোডটি genuinely গণনা করে প্রতিটি টাস্ক met, missed-hard, নাকি missed-soft — তারপর হার্ড টাস্কগুলোর জন্য একটি রিলায়েবিলিটি শতাংশ ও সফট টাস্কগুলোর জন্য গড় লেটনেস গণনা করে।

Python
class RTTask:
    def __init__(self, name, kind, deadline_ms, completion_ms):
        self.name = name
        self.kind = kind  # "hard" অথবা "soft"
        self.deadline_ms = deadline_ms
        self.completion_ms = completion_ms

    @property
    def lateness_ms(self):
        return self.completion_ms - self.deadline_ms

    def classify(self):
        if self.completion_ms <= self.deadline_ms:
            return "met"
        if self.kind == "hard":
            return "missed-hard"
        return "missed-soft"


tasks = [
    RTTask("Airbag_Deploy",      "hard", deadline_ms=20,  completion_ms=18),
    RTTask("Airbag_Deploy_Rare", "hard", deadline_ms=20,  completion_ms=24),
    RTTask("ABS_Brake_Pulse",    "hard", deadline_ms=10,  completion_ms=10),
    RTTask("Video_Frame_23",     "soft", deadline_ms=33,  completion_ms=41),
    RTTask("Video_Frame_24",     "soft", deadline_ms=33,  completion_ms=30),
    RTTask("Audio_Buffer_Fill",  "soft", deadline_ms=5,   completion_ms=7),
]

results = []
for t in tasks:
    status = t.classify()
    results.append((t, status))
    print(f"{t.name:<20} kind={t.kind:<5} deadline={t.deadline_ms:>3}ms  completion={t.completion_ms:>3}ms  "
          f"lateness={t.lateness_ms:>4}ms  -> {status}")

hard_tasks = [t for t, s in results if t.kind == "hard"]
hard_missed = [t for t, s in results if t.kind == "hard" and s == "missed-hard"]
soft_tasks = [t for t, s in results if t.kind == "soft"]
soft_missed = [t for t, s in results if t.kind == "soft" and s == "missed-soft"]

hard_reliability_pct = 100 * (len(hard_tasks) - len(hard_missed)) / len(hard_tasks)
avg_soft_lateness = sum(max(0, t.lateness_ms) for t in soft_tasks) / len(soft_tasks)

print()
print(f"হার্ড রিয়েল-টাইম টাস্ক: মোট {len(hard_tasks)}টি, মিস হয়েছে {len(hard_missed)}টি "
      f"-> রিলায়েবিলিটি {hard_reliability_pct:.1f}%")
print(f"সফট রিয়েল-টাইম টাস্ক: মোট {len(soft_tasks)}টি, ডেডলাইন মিস {len(soft_missed)}টি, "
      f"গড় লেটনেস {avg_soft_lateness:.1f}ms")

if hard_missed:
    print("\nসতর্কতা: নিচের হার্ড-রিয়েল-টাইম টাস্কগুলো সিস্টেম ফেইলিউর হিসেবে গণ্য হবে:")
    for t in hard_missed:
        print(f"  - {t.name} (deadline {t.deadline_ms}ms, completed {t.completion_ms}ms)")

    
লক্ষ করুন — Video_Frame_23 তার ডেডলাইন ৮ms মিস করেছে, আর Audio_Buffer_Fill মিস করেছে মাত্র ২ms, কিন্তু দুটোই missed-soft — সিস্টেম চলতে থাকে, শুধু কোয়ালিটি সামান্য কমে। অন্যদিকে Airbag_Deploy_Rare মাত্র ৪ms দেরি করেই missed-hard হিসেবে চিহ্নিত হয়েছে — কারণ এটি হার্ড রিয়েল-টাইম টাস্ক, এখানে "সামান্য দেরি" বলে কিছু নেই, হয় ডেডলাইনের মধ্যে নয়তো ব্যর্থ। রিলায়েবিলিটি মেট্রিকটিও কেবল হার্ড টাস্কের উপর ভিত্তি করে গণনা করা হয়েছে — কারণ সফট টাস্কে "মিস" মানে সিস্টেম ব্যর্থতা নয়, তাই একই মানদণ্ডে মেশানো উচিত নয়।
মূল কথা · Key takeaway

হার্ড রিয়েল-টাইম = ডেডলাইন মিস মানে ব্যর্থতা (সিস্টেম ডিজাইনে ওয়ার্স্ট-কেস টাইমিং গ্যারান্টি করতে হয়), সফট রিয়েল-টাইম = ডেডলাইন মিস মানে কোয়ালিটি ডিগ্রেডেশন (গড় পারফরম্যান্স যথেষ্ট)। L29-L30-এ RTOS টাস্ক শিডিউলিং ও প্রায়োরিটি ইনভার্সন আলোচনায় এই পার্থক্যটিই বুঝিয়ে দেবে কেন একটি হার্ড-রিয়েল-টাইম টাস্কের জন্য প্রায়োরিটি ইনভার্সনের মতো একটি বাগ এত বিপজ্জনক হতে পারে।

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

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

প্র ০১ একটি স্মার্টফোনের টাচস্ক্রিন রেসপন্স কি হার্ড নাকি সফট রিয়েল-টাইম বলে আপনার মনে হয়?

এটি সফট রিয়েল-টাইম। টাচ ইনপুট প্রসেস করতে সামান্য দেরি হলে ইন্টারফেস "ল্যাগি" মনে হয় — ইউজার এক্সপেরিয়েন্স খারাপ হয়, কিন্তু ফোন ক্র্যাশ করে না বা কোনো সুরক্ষাজনিত ব্যর্থতা ঘটে না। তুলনা করুন একটি গাড়ির এয়ারব্যাগ সেন্সরের সাথে — সেখানে একই ধরনের দেরি সরাসরি জীবনহানির ঝুঁকি তৈরি করতে পারে, তাই সেটি হার্ড রিয়েল-টাইম।

প্র ০২ "রিয়েল-টাইম সিস্টেম মানে দ্রুতগতির সিস্টেম" — এই ধারণাটি কেন ভুল?

কারণ রিয়েল-টাইম হওয়ার মূল শর্ত হলো ডেডলাইনের নিশ্চয়তা, গতি নয়। একটি ধীরগতির মাইক্রোকন্ট্রোলার যদি প্রতিবারই তার (হয়তো তুলনামূলক শিথিল) ডেডলাইনের মধ্যে কাজ শেষ করার গ্যারান্টি দিতে পারে, সেটি সত্যিকারের রিয়েল-টাইম সিস্টেম — অথচ একটি অতি দ্রুতগতির সার্ভার যদি মাঝেমধ্যেই অনির্দিষ্টভাবে দেরি করে ফেলে (যেমন গার্বেজ কালেকশন পজ), সেটি রিয়েল-টাইম নয়, তা যত দ্রুতই গড়ে হোক না কেন।

প্র ০৩ উপরের কোড সেলে hard_reliability_pct গণনায় সফট টাস্কগুলোকে কেন হিসাবের বাইরে রাখা হয়েছে?

কারণ হার্ড রিয়েল-টাইম রিলায়েবিলিটি মেট্রিকের উদ্দেশ্য হলো "সিস্টেম ব্যর্থতার হার" পরিমাপ করা — আর সফট টাস্কের ডেডলাইন মিস হওয়া সংজ্ঞা অনুযায়ীই সিস্টেম ব্যর্থতা নয়। সফট ও হার্ড টাস্ক একসাথে মিশিয়ে একটি একক শতাংশ বের করলে সংখ্যাটি বিভ্রান্তিকর হতো — একটি ভিডিও ফ্রেমের সামান্য দেরিকে একটি এয়ারব্যাগ মিস করার সমান গুরুত্ব দেওয়া উচিত নয়।

অনুশীলন

  1. চিন্তা করুন: উপরের কোড সেলে ABS_Brake_Pulse-এর completion_ms যদি ১০-এর বদলে ১১ করা হয়, এর classify() ফলাফল কী হবে বলে মনে করেন?

    তখন completion_ms (১১) deadline_ms-এর (১০) চেয়ে বেশি হয়ে যাবে, আর এটি "hard" কাইন্ডের টাস্ক — তাই classify() "missed-hard" রিটার্ন করবে, আর hard_reliability_pct-ও কমে যাবে (৩টির মধ্যে ২টি মিস হওয়ায় ৩৩.৩%-এ নেমে আসবে)।

  2. পরীক্ষা করুন: কোড সেলে একটি নতুন সফট টাস্ক যোগ করুন — RTTask("Sensor_Cloud_Sync", "soft", deadline_ms=1000, completion_ms=1500) — Run চেপে দেখুন avg_soft_lateness কীভাবে বদলায়।

    নতুন টাস্কের লেটনেস হবে ৫০০ms, যা আগের তিনটি সফট টাস্কের (৮, -৩, ২) তুলনায় অনেক বেশি — তাই গড় লেটনেস উল্লেখযোগ্যভাবে বেড়ে যাবে (চারটি মানের গড়, যেখানে ঋণাত্মক লেটনেসগুলো ০ ধরা হয়েছে max(0, ...) দিয়ে), এটি দেখায় একটি একক বড় আউটলায়ার কীভাবে গড় মেট্রিককে ভারীভাবে প্রভাবিত করতে পারে।

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

  • পরবর্তী পাঠ L29 RTOS ফান্ডামেন্টাল — টাস্ক ও শিডিউলিং — একটি সত্যিকারের প্রায়োরিটি-চালিত টাস্ক শিডিউলার তৈরি করা হবে এই সংজ্ঞাগুলোর উপর ভিত্তি করেই।
  • Operating Systems কোর্স সহোদর কোর্স সাধারণ-উদ্দেশ্যের OS প্রসেস/থ্রেড শিডিউলিং (থ্রুপুট, ফেয়ারনেস কেন্দ্রিক) সেই কোর্সে কভার করা হয়েছে — এই কোর্সে রিয়েল-টাইম কনস্ট্রেইন্ট-কেন্দ্রিক শিডিউলিং আলোচনা করা হয়।
  • কোর্সের সম্পূর্ণ সিলেবাস দেখুন ৫৭টি পাঠ সেমাফোর, মিউটেক্স, প্রায়োরিটি ইনভার্সন, বেয়ার-মেটাল বনাম RTOS বনাম এমবেডেড লিনাক্স — বাকি M7 মডিউল আসছে এরপরই।
আগের পাঠ
এমবেডেড সিস্টেমে ইন্টারাপ্ট — প্রায়োরিটি ও লেটেন্সি