কেস স্টাডি: Therac-25

১ · কী ঘটেছিল

Therac-25Therac-25AECL-এর তৈরি একটি কম্পিউটার-নিয়ন্ত্রিত রেডিয়েশন থেরাপি মেশিন, ১৯৮০-এর দশকের মাঝামাঝি সময়ে মোতায়েন করা হয়। ছিল একটি কম্পিউটার-নিয়ন্ত্রিত রেডিয়েশন থেরাপি মেশিন, নির্মাতা প্রতিষ্ঠান AECL, যা ১৯৮০-এর দশকের মাঝামাঝি সময়ে উত্তর আমেরিকার বেশ কয়েকটি ক্লিনিকে স্থাপন করা হয়েছিল। মেশিনটির কাজ ছিল ক্যান্সার রোগীদের নির্দিষ্ট, নিয়ন্ত্রিত মাত্রায় রেডিয়েশন প্রদান করা -- একটি সঠিক ডোজ যা টিউমারকে লক্ষ্য করে অথচ আশেপাশের সুস্থ টিস্যুকে যতটা সম্ভব সুরক্ষিত রাখে।

১৯৮৫ থেকে ১৯৮৭ সালের মধ্যে, অন্তত ছয়টি জ্ঞাত দুর্ঘটনায় Therac-25 রোগীদের উদ্দিষ্ট মাত্রার চেয়ে বহুগুণ বেশি রেডিয়েশন প্রদান করে। বেশ কয়েকজন রোগী মারা যান বা গুরুতর, স্থায়ী শারীরিক ক্ষতির শিকার হন। এই ঘটনাগুলোর সুনির্দিষ্ট মৃত্যুর সংখ্যা নিয়ে বিভিন্ন উৎসে ভিন্নতা আছে, তাই এই পাঠ কোনো একক নির্দিষ্ট সংখ্যা দাবি করবে না -- গুরুত্বপূর্ণ তথ্যটি হলো: একাধিক রোগী প্রকৃত, গুরুতর ক্ষতির শিকার হয়েছিলেন, এবং কয়েকজন মারা যান।

২ · মূল কারণ: একটি সফটওয়্যার রেস কন্ডিশন

মূল প্রযুক্তিগত কারণ ছিল একটি রেস কন্ডিশনRace Conditionযখন একাধিক অপারেশনের ফলাফল তাদের সম্পন্ন হওয়ার আপেক্ষিক সময়ের (টাইমিং) উপর নির্ভর করে, এবং একটি নির্দিষ্ট টাইমিং-ক্রমে একটি নিরাপত্তা-চেক এড়িয়ে যাওয়া সম্ভব হয়। -- যদি একজন অপারেটর নির্দিষ্ট গতিতে ও নির্দিষ্ট ক্রমে চিকিৎসার প্যারামিটার প্রবেশ করান বা সম্পাদনা করেন, তাহলে একটি নিরাপত্তা-চেক এড়িয়ে যাওয়া সম্ভব হতো। আগের মডেলগুলোর বিপরীতে, Therac-25 হার্ডওয়্যার ইন্টারলক (একটি স্বাধীন, হার্ডওয়্যারভিত্তিক নিরাপত্তা-লক যা সফটওয়্যারের সিদ্ধান্তের উপর নির্ভর করে না) সরিয়ে ফেলে কেবলমাত্র সফটওয়্যার সেফটি চেকের উপর নির্ভর করেছিল। ফলে যখন সেই সফটওয়্যার চেক টাইমিং বাগের কারণে ব্যর্থ হয়, তখন কোনো স্বাধীন হার্ডওয়্যার সুরক্ষা-স্তর অবশিষ্ট ছিল না যা বিপর্যয় ঠেকাতে পারতো।

৩ · কেন এটি দ্রুত ধরা পড়েনি

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

৪ · সেফটি-ক্রিটিক্যাল সফটওয়্যার প্র্যাকটিসে স্থায়ী প্রভাব

Therac-25 আজও সফটওয়্যার ইঞ্জিনিয়ারিং সেফটি ও এথিক্সের সবচেয়ে বেশি উদ্ধৃত কেস স্টাডিগুলোর একটি। এটি নিম্নলিখিত নীতিগুলোকে সেফটি-ক্রিটিক্যাল সিস্টেম ডিজাইনে দৃঢ়ভাবে প্রতিষ্ঠিত করতে সাহায্য করেছে -- রিডানডেন্ট (একাধিক, স্বতন্ত্র) নিরাপত্তা-স্তর রাখা, যাতে একটি স্তর ব্যর্থ হলেও অন্যটি রক্ষা করতে পারে; কনকারেন্ট/টাইমিং-নির্ভর আচরণ বিশেষভাবে কঠোরভাবে পরীক্ষা করা; এবং প্রতিটি অস্বাভাবিক ঘটনা বা এরর-রিপোর্টকে সম্ভাব্য গুরুতর সংকেত হিসেবে দ্রুত ও পুঙ্খানুপুঙ্খভাবে তদন্ত করা। L28-এ আমরা দেখব কেন টেস্টিং একাই কখনো "সম্পূর্ণ নিশ্চয়তা" দিতে পারে না -- Therac-25 এই সীমাবদ্ধতার একটি বাস্তব, মর্মান্তিক উদাহরণ।

৫ · রেস কন্ডিশনের ধরন -- একটি শিক্ষামূলক ইলাস্ট্রেশন

নিচের কোড Therac-25-এর প্রকৃত সোর্স কোড নয় -- এই কোর্সের কাছে সেই কোড নেই, এবং এখানে তা পুনর্নির্মাণের কোনো দাবিও করা হচ্ছে না। বরং এটি একটি ন্যূনতম, সরলীকৃত মডেল যা রেস কন্ডিশন নামক বাগের ধরনটি -- কীভাবে একটি "স্টেল" (পুরনো, আর বৈধ নয় এমন) সেফটি-চেক ফলাফল ব্যবহারের কারণে একটি নিরাপত্তা-চেক কার্যকরভাবে এড়িয়ে যাওয়া সম্ভব হতে পারে -- বোঝার জন্য তৈরি করা হয়েছে।

# শিক্ষামূলক ইলাস্ট্রেশন -- Therac-25-এর প্রকৃত সোর্স কোড নয় (যা এই কোর্সের কাছে নেই এবং
# পুনর্নির্মাণের দাবিও করা হচ্ছে না)। এটি শুধু "রেস কন্ডিশন" নামক বাগের ধরনটি একটি
# ন্যূনতম, সরলীকৃত মডেলে দেখানোর জন্য।

class TreatmentSession:
    def __init__(self):
        self.mode = "স্ট্যান্ডার্ড"  # সেশন সবসময় "স্ট্যান্ডার্ড" মোডে শুরু হয়

def switch_mode(session, new_mode):
    session.mode = new_mode

def safety_check(session):
    # সেফটি চেক শুধুমাত্র "স্ট্যান্ডার্ড" মোডে বিম চালুর অনুমতি দেয়
    return session.mode == "স্ট্যান্ডার্ড"

def commit_beam(check_result):
    return "বিম চালু (beam fired)" if check_result else "বিম বন্ধ (beam blocked)"

def run_safe_interleaving():
    """নিরাপদ ক্রম: কমিটের ঠিক আগ মুহূর্তে সেফটি চেক (পুনরায়) করা হয় -- সবসময় সর্বশেষ অবস্থা দেখেই"""
    session = TreatmentSession()
    switch_mode(session, "হাই-ইনটেনসিটি")   # অপারেটর দ্রুত মোড পরিবর্তন করলেন
    check_result = safety_check(session)     # কমিটের ঠিক আগে চেক -- বর্তমান, আপ-টু-ডেট অবস্থা দেখেই
    return commit_beam(check_result), check_result

def run_race_condition_interleaving():
    """বিপজ্জনক ক্রম: সেফটি চেক আগেই করে ফলাফল সংরক্ষণ করা হয়, তারপর অপারেটর দ্রুত মোড পরিবর্তন করেন --
    কিন্তু কমিট সেই পুরনো (stale) চেক-ফলাফল ব্যবহার করে, নতুন অবস্থার সাথে আর পুনরায় মেলানো হয় না"""
    session = TreatmentSession()
    stale_check_result = safety_check(session)  # তখনো মোড "স্ট্যান্ডার্ড" -- চেক পাস করে (True)
    switch_mode(session, "হাই-ইনটেনসিটি")        # অপারেটর দ্রুত মোড পরিবর্তন করলেন, কিন্তু আর চেক হয়নি
    return commit_beam(stale_check_result), stale_check_result

safe_outcome, safe_check = run_safe_interleaving()
race_outcome, race_check = run_race_condition_interleaving()

print(f"নিরাপদ ইন্টারলিভিং      : সেফটি-চেক ফলাফল={safe_check}, চূড়ান্ত ফলাফল={safe_outcome}")
print(f"রেস-কন্ডিশন ইন্টারলিভিং : সেফটি-চেক ফলাফল={race_check}, চূড়ান্ত ফলাফল={race_outcome}")