تقریباً ۴۰ سال پیش، یک باگ نرم‌افزاری در دستگاه پرتودرمانی Therac-25 باعث مرگ حداقل سه بیمار شد. این فاجعه، که بین ژوئن ۱۹۸۵ تا ژانویه ۱۹۸۷ رخ داد، یکی از مهم‌ترین درس‌های تاریخ مهندسی نرم‌افزار است. Therac-25، دستگاهی نوآورانه برای درمان سرطان، به دلیل شرایط مسابقه (Race Condition) و حذف قفل‌های ایمنی سخت‌افزاری، دوزهای تشعشع ۱۰۰ برابر بیش از حد مجاز به بیماران داد. در این مقاله از آی تی پالس، جزئیات این حوادث، علت باگ، و درس‌های آن را بررسی می‌کنیم.
Therac-25: نوآوری یا فاجعه در انتظار؟
Therac-25، ساخته‌شده توسط شرکت AECL (کانادا)، دستگاهی برای پرتودرمانی بود که دو حالت داشت:
- حالت الکترون: برای تومورهای سطحی، با دوز پایین.
- حالت اشعه X: برای تومورهای عمیق، با دوز بالا.
نوآوری کلیدی: حذف قفل‌های ایمنی سخت‌افزاری مدل‌های قبلی (Therac-20) و واگذاری همه کنترل‌ها به نرم‌افزار. این تصمیم، که برای کاهش هزینه و افزایش سرعت بود، به فاجعه منجر شد. AECL نرم‌افزار را «بی‌نقص» فرض کرد، اما تست‌های ناکافی و عدم مستندسازی، باگ‌ها را پنهان نگه داشت.
جدول حوادث Therac-25
| تاریخ | مکان | شدت جراحات | توضیح |
|---|---|---|---|
| 3 ژوئن 1985 | ماریتا، جورجیا (ETCC) | برداشتن سینه، از کار افتادن بازو (دوز ~16,500 rad) | اولین حادثه؛ اپراتور حالت X را انتخاب کرد، سپس به الکترون تغییر داد. |
| 26 ژوئیه 1985 | انتاریو، کانادا (OHCC) | نیاز به تعویض کامل مفصل ران (دوز ~13,000 rad) | Race Condition فعال شد؛ AECL ابتدا انکار کرد. |
| 21 مارس 1986 | تایلر، تگزاس (YMC) | مرگ (دوز ~16,500 rad) | بیمار 61 ساله؛ AECL نرم‌افزار را «ایمن» خواند. |
| 11 آوریل 1986 | تایلر، تگزاس (YMC) | مرگ (دوز ~16,500 rad) | بیمار 66 ساله؛ FDA تحقیق را آغاز کرد. |
| 17 ژانویه 1987 | یاکیما، واشنگتن (YMC) | مرگ (دوز ~16,500 rad) | آخرین حادثه؛ AECL ماشین‌ها را تعطیل کرد. |
منابع: Wikipedia, Ethics Unwrapped, The Daily WTF, Bugsnag, Blue Goat Cyber.
حداقل سه مرگ مستقیماً به Therac-25 نسبت داده شده، و سه آسیب شدید دیگر (مانند از کار افتادن بازو) رخ داد. AECL ابتدا حوادث را به اشتباه انسانی یا سخت‌افزار نسبت داد، اما تحقیقات FDA (فوریه 1987) باگ نرم‌افزاری را تأیید کرد.
علت باگ: Race Condition و طراحی معیوب
Race Condition چیست؟
- تعریف: باگی زمانی رخ می‌دهد که دو یا چند فرآیند همزمان به یک منبع (مانند متغیر) دسترسی دارند و نتیجه به ترتیب اجرای آن‌ها بستگی دارد.
- در Therac-25: نرم‌افزار از یک flag (پرچم) برای بررسی وضعیت استفاده می‌کرد. اپراتور حالت X (پرقدرت) را انتخاب می‌کرد، اما قبل از آماده شدن، به الکترون (کم‌قدرت) تغییر می‌داد. Race Condition باعث می‌شد flag به 0 بازگردد (به دلیل overflow یکбайتی)، و نرم‌افزار ایمنی را نادیده بگیرد.
عوامل تشدیدکننده
- حذف قفل‌های سخت‌افزاری: مدل‌های قبلی (Therac-6 و 20) قفل‌های فیزیکی داشتند، اما Therac-25 همه را به نرم‌افزار واگذار کرد.
- تست ناکافی: AECL نرم‌افزار را «battle-tested» فرض کرد، اما تست‌های Race Condition انجام نشد.
- عدم مستندسازی: کد بدون کامنت و مستندات کافی بود، که عیب‌یابی را دشوار کرد.
نانسی لیوسون، استاد MIT: «Therac-25 نشان داد که نرم‌افزار بدون تست‌های جامع، می‌تواند کشنده باشد.»
درس‌های Therac-25 برای مهندسی نرم‌افزار
- قفل‌های ایمنی چندلایه: ترکیب نرم‌افزار و سخت‌افزار برای جلوگیری از فاجعه.
- تست‌های جامع: شامل سناریوهای نادر و Race Condition.
- مستندسازی: کد و فرآیندها باید واضح باشند.
- گزارش‌دهی: AECL گزارش‌ها را نادیده گرفت؛ سیستم‌های گزارش‌دهی قوی ضروری است.
این فاجعه منجر به استاندارد IEC 62304 برای نرم‌افزارهای پزشکی شد.
فاجعه Therac-25، که با Race Condition و طراحی معیوب نرم‌افزاری حداقل سه مرگ به بار آورد، یکی از هولناک‌ترین درس‌های تاریخ فناوری است. این حوادث، که از 1985 تا 1987 رخ داد، بر اهمیت تست‌های جامع، قفل‌های ایمنی، و گزارش‌دهی تأکید می‌کند. امروز، استانداردهایی مانند IEC 62304 از تکرار چنین فجایعی جلوگیری می‌کنند، اما Therac-25 هشداری ابدی است. آی تی پالس، مرجع اخبار فناوری و امنیت، شما را با درس‌های تاریخ همراهی می‌کند.
