Therac-25 घटना (2021)

 (thedailywtf.com)
2 पॉइंट द्वारा GN⁺ 2025-08-28 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Therac-25 चिकित्सा विकिरण मशीन में घातक दुर्घटना हुई
  • सॉफ्टवेयर खामी के कारण कई मरीज गंभीर अत्यधिक विकिरण के संपर्क में आए
  • मौजूदा सुरक्षा प्रणाली को digital control system से बदलने के बाद समस्या उत्पन्न हुई
  • दोष निदान और संचार की कमी के कारण दुर्घटना के कारण की पहचान में देरी हुई
  • सुरक्षा से जुड़े मुख्य सबक के रूप में algorithm reliability और कठोर testing के महत्व पर ज़ोर दिया गया

Therac-25 घटना का सार

  • Therac-25 एक उपचारात्मक विकिरण चिकित्सा उपकरण था, जिसका व्यापक उपयोग किया जाता था
  • यह उपकरण कैंसर मरीजों पर उच्च मात्रा का विकिरण देने का काम करता था
  • पहले के यांत्रिक interlock सुरक्षा उपकरणों को software-based control system से बदल दिया गया था
  • लेकिन इस बदलाव से software errors होने का जोखिम बढ़ गया

दुर्घटना कैसे हुई

  • कुछ खास कार्य क्रम या तेज़ लगातार input के दौरान प्रोग्राम में खामी उत्पन्न होती थी
  • इसके कारण सुरक्षा प्रणाली ठीक से काम नहीं करती थी, और मरीजों को डिज़ाइन सीमा से अधिक तीव्रता का विकिरण दिया गया
  • 1985~1987 के बीच कई मरीजों में गंभीर overexposure की घटनाएँ हुईं और कुछ की मृत्यु भी हुई
  • शुरुआत में विकिरण मशीन की खराबी के कारण के रूप में software problems को नज़रअंदाज़ करने की प्रवृत्ति थी

समस्या के कारण

  • reliability verification प्रक्रिया में ऐसे सरल tests ही किए गए जो वास्तविक clinical environment को प्रतिबिंबित नहीं करते थे
  • error handling और interlock management की कमी के कारण चरम परिस्थितियों में algorithm errors उत्पन्न हुए
  • निर्माता और अस्पताल के बीच स्पष्ट issue reporting और communication system न होने से, खामी की पहचान और समाधान में देरी हुई
  • इस घटना को safety-centered software design की विफलता माना जाता है

मुख्य सबक

  • सुरक्षा से सीधे जुड़े algorithm design में कठोर verification और defensive programming आवश्यक है
  • test cases की विविधता और वास्तविक उपयोग परिदृश्यों पर आधारित simulation अनिवार्य हैं
  • विभिन्न error handling loops और log systems के व्यवस्थित implementation पर ज़ोर दिया गया
  • जिन क्षेत्रों में उच्च reliability की आवश्यकता होती है, वहाँ केवल software control पर निर्भरता के जोखिम को समझना चाहिए
  • यह घटना विश्वभर के software engineering और medical device उद्योग में algorithm reliability, safety management, और communication systems के महत्व की याद दिलाने वाला एक प्रतिनिधि उदाहरण है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-08-28
Hacker News की राय

  • यह बात रेखांकित की गई कि software quality सिर्फ अच्छे developers होने से नहीं आती, बल्कि यह पूरे संगठन में फैली process का अंतिम परिणाम होती है। यह process केवल development practices ही नहीं, बल्कि testing, management, यहाँ तक कि sales और service को भी प्रभावित करती है। Therac-25 घटना से हमें यह सीख मिलती है कि केवल type system, unit tests, या defensive coding से सारी समस्याएँ हल नहीं होतीं। असली विफलता यह थी कि दुर्घटना की रिपोर्ट, जाँच और सुधार तक पहुँचने में बहुत अधिक समय लगा। हाल ही में Cautionary Tales podcast में भी यह मामला आया था, और Therac-25 में users लगातार अज्ञात errors झेल रहे थे, लेकिन यह बात उन लोगों तक ठीक से नहीं पहुँच रही थी जो इसे ठीक कर सकते थे—यह बात खास तौर पर प्रभावशाली लगी। (podcast लिंक)

    • मैं इस राय से सहमत नहीं हूँ। मुझे aircraft parts design का लंबे समय का अनुभव है, और मूल सिद्धांत सिर्फ एक है: किसी एकल विफलता से दुर्घटना नहीं होनी चाहिए। इसे हासिल करने का तरीका ‘अच्छा software लिखना’ या ‘पर्याप्त testing’ नहीं, बल्कि ‘ऐसी स्वतंत्र प्रणालियाँ रखना है जो software के सबसे खराब व्यवहार को भी रोक सकें’। Therac-25 के मामले में, safety threshold पार होने पर अपने-आप बंद कर देने वाला radiation detection device, और ऐसा physical design होना चाहिए था जिससे अत्यधिक radiation emission भौतिक रूप से संभव ही न हो।

    • मैं भी वही podcast सुझाने वाला था। खासकर अगर आपको software bugs में रुचि है तो यह सुनने लायक है। एक दिलचस्प तथ्य यह है कि शुरुआती manual machines में भी यही defect था, लेकिन fuse के उड़ जाने से वह defect वास्तविक नुकसान में नहीं बदल पाता था। यह Swiss Cheese Model का शानदार उदाहरण है (Swiss Cheese Model संदर्भ)

    • मैं यह रेखांकित करना चाहता हूँ कि अधिकांश software सीधे जीवन-मरण से जुड़ा नहीं होता। ज़्यादातर मामलों में, failure होने पर बस page धीरे खुलता है, report NaN से भर जाती है, या batch job manually शुरू करनी पड़ती है। software quality की वजह से लोगों की वास्तविक मौतें दुर्लभ हैं, और जो developers ऐसा software बनाते हैं, वे अपनी ज़िम्मेदारी को अच्छी तरह जानते होंगे।

    • जिस कंपनी में मैंने काम किया, वह बेहतरीन quality वाले photo और scientific instruments बनाती थी। वे बहुत महंगे थे, लेकिन ग्राहक उसकी कीमत को सही मानते थे। मैंने प्रत्यक्ष रूप से अनुभव किया कि quality सिर्फ process का नतीजा नहीं, बल्कि अंततः ‘culture’ से आती है।

    • बहुत से developers सोचते हैं कि अगर वे high-reliability systems पर काम नहीं कर रहे, तो quality issues उनसे संबंधित नहीं हैं, लेकिन यह पूरी तरह गलत सोच है। मामूली दिखने वाली software failure भी किसी व्यक्ति के जीवन या किसी कंपनी पर भारी असर डाल सकती है। उदाहरण के लिए, यह किसी critical flow को रोक सकती है, जीवन या medical records के data को खराब कर सकती है, या किसी ज़रूरी सामान का payment रुकवा सकती है।

  • लेख की टिप्पणियों में किसी ने कहा कि 80-90 के दशक में medical field में यह धारणा काफ़ी मजबूत थी कि computers खतरनाक होते हैं। 2000 के शुरुआती और मध्य वर्षों तक भी medical records हाथ से कागज़ पर लिखे जाते थे। मैंने ICU के एक electronic patient record experimental project में थोड़े समय के लिए servers manage किए थे, और सभी medical staff इस system से नफरत करते थे। उस समय tablets भी नहीं थे, इसलिए computer पर records देखना या संशोधित करना असुविधाजनक था। सभी दवा prescriptions bedside chart पर सीधे लिखने की आदत थी, जहाँ उन्हें तुरंत देखा और बदला जा सकता था। information loss या access delay घातक हो सकते थे, इसलिए doctors बिना वजह computers से नफरत नहीं करते थे—उन्हें सच में लगता था कि यह pen और paper से अधिक खतरनाक है। बाद में हालात बेहतर हुए होंगे, लेकिन यह बात अब भी ध्यान में रखने लायक है।

    • अब Chipsoft जैसी कंपनियाँ hospital IT जगत पर लगभग एकाधिकार जैसा नियंत्रण रखती हैं। वे बहुत महँगी हैं, फिर भी software quality बेहद खराब है, और vendor जितना बड़ा होता जाता है, विकल्प उतने कम रह जाते हैं। समझ नहीं आता कि हम ऐसे hostile vendors को क्यों सहन करते हैं।

    • आज भी ऐसे मामले होते हैं जहाँ computerized systems के down होने पर medical staff को फिर से pen और paper पर लौटना पड़ता है। यह समझ से परे है कि इन systems में redundancy नहीं होती। और यह कि ये अभी भी commercial products हैं, अपने-आप में चौंकाने वाली बात है।

    • अमेरिका और यूरोप में EMR (electronic medical records) को medical devices के रूप में वर्गीकृत नहीं किया जाता, इसलिए वे कई regulations से मुक्त रहते हैं। संबंधित लेख लिंक

  • इसे UK Post Office scandal से तुलना करना दिलचस्प है। दोनों घटनाएँ बिल्कुल अलग हैं, लेकिन दोनों में एक साझा गलत धारणा थी: ‘software गलत नहीं हो सकता’। developers के नज़रिए से यह बहुत हास्यास्पद लगता है, लेकिन non-experts के लिए software की नाज़ुकता समझना कठिन होता है। एक ऐसा माहौल था जहाँ यह मान लिया जाता था कि software में defect हो ही नहीं सकता, और testing भी ठीक से नहीं की जाती थी।

    • सच तो यह है कि developers भी अक्सर software पर ज़रूरत से ज़्यादा भरोसा कर लेते हैं। मैंने जो भी systems बनाए हैं, उनके बारे में मैं हमेशा मानता हूँ कि वे कभी भी ढह सकते हैं। इसी वजह से मैं कभी self-driving car में नहीं बैठूँगा। HN users को नई technology के beta testers बनना सचमुच बहुत पसंद है, यह मुझे अजीब लगता है। बेशक, self-driving cars के बारे में कहा जाता है कि वे आँकड़ों के हिसाब से अधिक सुरक्षित हैं, लेकिन उसका एक कारण यह भी है कि आसपास के human drivers ज़्यादा सावधानी से चलाते हैं। इसके अलावा self-driving cars एक नई system हैं, जिन पर human supervision और direct intervention जैसी सुविधाएँ या सख्त standards वैसे लागू नहीं होते, और मुझे लगता है कि यही समस्या है।

    • मेरा मानना है कि अधिकतर पारंपरिक electrical और mechanical machines में parts का घिसना मुख्य failure mode था, और software घिसता नहीं है, इसलिए लोगों ने गलत तरह से मान लिया कि वह स्वाभाविक रूप से अधिक reliable है।

    • मुझे लगता है Post Office scandal कहीं अधिक दुर्भावनापूर्ण था। senior executives को shopkeepers से वसूली गई रकम के आधार पर incentives मिलते थे, और उन्होंने courts और ministers से software की reliability के बारे में झूठ भी बोला। Therac-25 उसके मुकाबले एक ईमानदार गलती के अधिक क़रीब था।

  • मुझे आभास हो रहा है कि Therac-25 जैसी घटना फिर होने वाली है। बहुत से लोग AI agents को YOLO mode में चला रहे हैं, इसलिए अगर Claude या Gemini जैसे models को असली hardware से गलत ढंग से जोड़ दिया गया, तो कभी न कभी कोई दुर्घटना होगी ही। agent-based AI अभी embedded systems के लिए पर्याप्त परिपक्व नहीं है, और radiation equipment जैसे क्षेत्रों में AI को लापरवाही से लागू किए जाने की कल्पना ही डरावनी है।

    • UK Post Office Horizon मामले में कई shopkeepers ने आत्महत्या कर ली, और दर्जनों लोगों की ज़िंदगियाँ बर्बाद हो गईं। मेरा मानना है कि Therac-25 घटना से हमें यह सीखना चाहिए कि हर software महत्वपूर्ण है। हर software में किसी न किसी को नुकसान पहुँचाने का जोखिम होता है, इसलिए हमेशा सावधानी बरतनी चाहिए।

    • non-agentic AI भी कुछ परिभाषाओं के हिसाब से पहले ही ‘लोगों को मार रही है’। हाल में AI chatbot से जुड़े ऐसे मामले चर्चा में रहे हैं जहाँ बात आत्महत्या तक पहुँच गई। आगे चलकर यदि medical insurance जैसे महत्वपूर्ण decision-making क्षेत्रों में AI का उपयोग बढ़ता है, तो ‘AI की वजह से मौत’ के मामले और बढ़ सकते हैं। self-driving cars जैसी कई जगहों पर AI पहले ही जानलेवा दुर्घटनाएँ कर चुका है। Excel error जैसे मामूली bugs के भी ऐसे उदाहरण हैं जिनका सामाजिक असर दसियों हज़ार या लाखों लोगों पर पड़ा। लेकिन AI में भी responsibility अक्सर अस्पष्ट रहती है, इसलिए Horizon मामले की तरह जवाबदेही से बच निकलने की काफी गुंजाइश होगी। AI copilot tools भी embedded क्षेत्र में अभी अपर्याप्त लगते हैं।

    • 737 MAX MCAS संकट system-level failure था, लेकिन यह इसी तरह की बड़ी software quality समस्याओं का एक प्रतिनिधि उदाहरण है। मुझे लगता है कि भविष्य में भी ऐसी आपदाएँ दोहराई जाएँगी।

    • Boeing 737 MAX crash भी low-quality software का एक प्रमुख उदाहरण है, जिसने लगभग 350 लोगों की जान ले ली (MCAS जानकारी लिंक)

    • जब मैंने नवीनतम AI agents के साथ embedded काम करने की कोशिश की, तो performance उम्मीद से कम निकली। यहाँ तक कि साधारण CRUD webapp में भी, यदि data model जटिल हो जाए, तो सिर्फ दो-तीन transformation steps के बाद LLM अक्सर उलझ जाता है। उदाहरण के लिए, input में created_at, storage में created_on, और external system को भेजते समय last_modified जैसे अलग field names हों, तो समस्या पैदा हो जाती है।

  • Therac-25 मशीन में VT100 terminal पर कुछ विशेष key inputs देने से पलक झपकते ही अत्यधिक radiation exposure हो सकता था—यह किस्सा बहुत प्रभावशाली लगा। अनुभवी users 8 seconds के भीतर बहुत तेज़ी से keys दर्ज कर सकते थे, और ऐसे में input सही तरह से apply नहीं होती थी, जिससे घातक दुर्घटना हो सकती थी। ऐसे मामलों को देखते हुए आजकल industrial और vehicle interfaces तक में touchscreen की ओर बढ़ता रुझान असहज करता है।

    • UI में user experience बेहतर बनाने के लिए अक्सर optimistic update का इस्तेमाल किया जाता है, जिससे screen पर बदलाव जल्दी दिखता है लेकिन वास्तविक बदलाव बाद में sync होता है। उम्मीद है लोग ठीक से समझेंगे कि किन जगहों पर इस approach की कोई ज़रूरत नहीं है।

    • iOS 11 calculator में अगर आप तेज़ी से “1+2+3” डालें, तो सही calculation नहीं होती थी (संबंधित HN मामला). देखने में मामूली calculator में भी वही failure mode मौजूद था।

  • क्या किसी ने university में Therac-25 या ऐसे safety/ethics case studies पढ़े हैं? मैंने general engineering class में bathtub curve और redundant cooling pump calculations जैसी चीज़ों के साथ यह मामला पढ़ा था, और अब जिज्ञासा है कि क्या आज भी यह सामग्री curriculum में शामिल है।

    • Purdue University में 90 के दशक की शुरुआत के machine interfaces class में ‘hysteresis’ (विलंबित प्रतिक्रिया) की अवधारणा पर ज़ोर दिया गया था। यह ज़रूरी था कि लोग समझें कि analog systems computers की तरह तुरंत बंद नहीं होते, बल्कि operating range के भीतर तरह-तरह के व्यवहार कर सकते हैं।

    • systems engineering class में इससे मिलते-जुलते विषय कवर किए जाते हैं। (MIT class लिंक)

    • मैंने university स्तर या उससे ऊपर के computer science courses में ऐसे मामले पढ़े थे। बाद में medtech में काम करते हुए भी यह बार-बार याद आता रहा।

    • engineering ethics class में मुझे याद है कि हमने वास्तव में सिर्फ Tacoma Narrows और Therac-25 ही पढ़े थे। वह भी केवल 1 घंटे के lecture में।

    • जिज्ञासा के कारण मैंने खुद एक poll बना दिया। जानना चाहता हूँ कि किसने ऐसी classes ली हैं। (poll लिंक)

  • पुराने उपकरणों में hardware interlocks थे। software में समस्या होने पर भी असर बस असुविधा तक सीमित रहता था, लेकिन software की स्थिरता पर अति-विश्वास के कारण लागत घटाने के लिए hardware interlocks हटा दिए गए और निगरानी सिर्फ software पर छोड़ दी गई। अंत में एक मामूली समस्या घातक त्रासदी में बदल गई। यह अलग-अलग स्तरों पर पैदा हुए असंतुलन का प्रतिनिधि उदाहरण है।

  • लेख के पहले commenter एक doctor हैं, computer science graduate हैं, और child abuse prevention से जुड़ी एक professional society के president भी हैं (प्रोफ़ाइल लिंक). लेकिन child abuse medical determination में आज भी गलत data, कमजोर evidence, और exploratory circular reasoning जैसी समस्याओं से बड़े छेद मौजूद हैं। objective truth तक पहुँचना कठिन है, और field में अक्सर कुछ observations के आधार पर ही ‘beyond reasonable doubt child abuse’ मान लेने की प्रवृत्ति होती है। हाल के वर्षों में ऐसे अपूर्ण data के आधार पर high-precision detection का दावा करने वाले black-box AI भी सामने आ रहे हैं, लेकिन गलत data से सही prediction संभव नहीं है (garbage in, garbage out). चिंता है कि inaccurate AI diagnosis से child abuse के झूठे आरोप, परिवारों का टूटना, और गलत सज़ाएँ जैसे गंभीर परिणाम पैदा हो सकते हैं। (संबंधित संदर्भ, clinical paper, AI और data समस्या, research लिंक)

  • 1993 की रिपोर्ट में safety-critical software engineers की qualification की आवश्यकता का उल्लेख है। सिर्फ कुछ programming courses करके कोई अपने-आप को safety-critical software developer नहीं कह सकता, और अनुमान लगाया गया था कि यदि Therac-25 जैसी घटनाएँ दोहराई गईं, तो संबंधित certification अनिवार्य हो जाएगी। UK में तो आवश्यक training curriculum design पर चर्चा भी हुई। लेकिन 32 साल बाद, वास्तविकता उन अपेक्षाओं से बहुत अलग है।

    • मैंने कनाडा में 15 साल तक registered professional software engineer के रूप में काम किया, लेकिन कोई व्यावहारिक लाभ महसूस नहीं हुआ, इसलिए जल्द ही renewal बंद करने वाला हूँ। software development को अधिक structured engineering discipline बनाने की चर्चा कभी थी, लेकिन अब वह लगभग गायब लगती है।

    • safety-critical software classroom में नहीं सीखी जाती; यह लंबे व्यावहारिक अनुभव और training से बनती है। aviation (Do-178) और industry (IEC 61508) जैसे standards मौजूद हैं, लेकिन वास्तविक implementation level budget और schedule पर निर्भर करता है। लेकिन जब दुर्घटना हो जाती है, तो चाहे audit trail मौजूद हो, पीड़ितों के लिए उसका कोई मतलब नहीं रह जाता। हर regulation और rule आखिरकार किसी के बलिदान के बाद ही पैदा होता है।

  • Therac-25 software पूरा का पूरा एक ही developer ने लिखा था, और 1986 में उसके कंपनी छोड़ने के बाद उसकी पहचान कभी सार्वजनिक नहीं हुई। कई पाठक शायद यह कल्पना करें कि ‘developer ने इस त्रासदी से बहुत पैसा कमाया और शानदार retirement जी’, लेकिन उस दौर में developers को आज की तरह पहचान या ऊँची तनख्वाह नहीं मिलती थी। 80 के दशक में tech companies के सितारे salespeople होते थे, और संभव है कि Therac-25 की sales commission उस developer की salary से भी अधिक रही हो। खासकर AECL का स्थान, उस समय का संदर्भ, government-affiliated माहौल, और embedded software का क्षेत्र—ये सब comparatively low pay से जुड़े थे। 1986 में उसकी आय शायद Canada में $30k–50k के आसपास रही होगी, जो आज के मूल्य में भी लगभग US$78k–129k के बीच बैठती है, और stock options भी नहीं थे।