دستگاهی که قرار بود سرطان را درمان کند، بیماران را با خطای نرم‌افزاری کشت

سال‌ها پیش، حذف قفل‌های سخت‌افزاری و خطای کدنویسی در یک دستگاه پرتودرمانی باعث تابش بیش‌ازحد پرتو به بیماران و مرگ ۳ نفر شد.

دستگاه پرتودرمانی Therac-25 که توسط شرکت کانادایی Atomic Energy of Canada Limited (AECL) ساخته شده بود، به یکی از مشهورترین نمونه‌های شکست نرم‌افزار در یک سامانه‌ی ایمنی‌-حیاتی تبدیل شد. این دستگاه از اوایل دهه‌ی ۱۹۸۰ برای درمان سرطان استفاده می‌شد و می‌توانست هم پرتو الکترونی و هم پرتو ایکس تولید کند؛ اما مجموعه‌ای از خطاهای نرم‌افزاری و ضعف‌های طراحی در نهایت به چندین مورد پرتودهی بسیار شدید انجامید.

بین سال ۱۹۸۵ و ۱۹۸۷، دست‌کم ۶ حادثه‌ی مرتبط با Therac-25 ثبت شد. بیماران در برخی موارد به‌جای دوز تجویزشده، مقادیر بسیار بالاتری از پرتو دریافت کردند. سه بیمار در نتیجه‌ی این حوادث جان باختند و سه نفر دیگر دچار آسیب‌های شدید شدند.

یکی از مهم‌ترین مشکلات Therac-25 این بود که برخی قفل‌های ایمنی سخت‌افزاری که در مدل‌های قبلی وجود داشتند، حذف شدند و وظیفه‌ی جلوگیری از وضعیت‌های خطرناک تا حد زیادی به نرم‌افزار سپرده شده بود. یکی از خطاهای کلیدی نیز یک شرایط رقابتی بود؛ یعنی ترتیب بسیار سریع رخدادهای مختلف می‌توانست برنامه را به وضعیتی ببرد که سیستم تصور کند دستگاه در حالت ایمن قرار دارد، در حالی که آماده‌ی تولید پرتو اشتباه بود.

پیام‌های خطای مبهم نیز مشکل را جدی‌تر کردند. برای نمونه، برخی اپراتورها با کدهایی مانند Malfunction 54 مواجه می‌شدند و چون دستگاه ظاهراً درمان را متوقف کرده بود، تصور می‌کردند مشکل جدی نیست. بررسی‌های بعدی همچنین نشان داد که برخی خطاها در ابتدا توسط سازنده به‌راحتی بازتولید نمی‌شدند و گزارش‌های کاربران نیز به اندازه کافی جدی گرفته نشدند.

اهمیت Therac-25 فقط در تعداد قربانیانش نیست؛ این پرونده به یک مطالعه‌ی کلاسیک در مهندسی نرم‌افزار، ایمنی سامانه‌های حساس و اخلاق حرفه‌ای تبدیل شد. بررسی مشهور نانسی لوسون و کلارک ترنر درباره‌ی این حوادث نشان داد که مشکل صرفاً یک باگ منفرد نبود و مجموعه‌ای از ضعف‌ها در طراحی، آزمایش، مستندسازی، رابط کاربری و فرایند واکنش به گزارش‌های کاربران در وقوع فاجعه نقش داشتند.

Therac-25 امروز یادآور یک اصل اساسی در مهندسی سامانه‌های حساس است: نمی‌توان ایمنی را صرفاً به نرم‌افزار سپرد و انتظار داشت یک خطای برنامه‌نویسی هیچ پیامدی نداشته باشد. در پزشکی، هوانوردی و سایر حوزه‌های حیاتی، نرم‌افزار باید در کنار لایه‌های مستقل سخت‌افزاری، آزمون‌های دقیق و سازوکارهای مطمئن نظارتی قرار بگیرد.