Therac-25

Therac-25 апарат променевої терапії з комп'ютерним управління. Виробництва компанії Atomic Energy of Canada Limited (AECL) у 1982 році. Наступна модель після Therac-6 та Therac-20 (попередні апарати були виготовлені у партнерстві з Compagnie General Radiographique, Франція).

Апарати цієї моделі були причетні до щонайменше шести нещасних випадків між 1985 і 1987 роками, в яких пацієнти отримували масові передозування радіації.[1]:425 Через помилки паралельного програмування він іноді давав своїм пацієнтам дози опромінення, які були в сотні разів більше за необхідні, чим спричиняв загибель або серйозні ушкодження[2].

Ці інциденти підкреслюють небезпеку комп'ютерних систем керування критично важливих для безпеки систем, і вони стали стандартним прикладом досліджень в інформатизації охорони здоров'я та розробці програмного забезпечення. Крім того, самовпевненість інженерів[1] :428 та відсутність належної експертизи для вирішення повідомлених програмних помилок підкреслюють як крайній випадок надмірної впевненості інженерів у результатах їхньої роботи, та недовіра скаргам кінцевих користувачів, що призвело до драматичних наслідків.

Архітектура системи

Апарат пропонував два режими променевої терапії: [3]

  • Пряма електронно-променева терапія, при якій вузький пучок з низьким струмом високоенергетичних (від 5 МеВ до 25 МеВ) електронів був скерований магнітами на зону обробки;
  • Мегавольт-рентгенівська (або фотонна) терапія, яка спрямовувала рентгенівський промінь фіксованої енергії 25 МеВ, що вироблявся шляхом зіткнення пучку у 100 разів більшого струму із ціллю, та пропускався через згладжуючий фільтр і коліматор.

Він також включав режим «підсвічування області», що дозволяв правильно розмістити пацієнта, освітлюючи зону лікування видимим світлом.

Опис проблеми

Інтерфейс користувача Therac-25

Шість задокументованих інцидентів сталися, коли пучок електронів, що генерується в режимі рентгенівських променів, направлявся безпосередньо на пацієнтів. Причиною виявилися дві помилки програми. [3] Одна, коли оператор неправильно обирав рентгенівський режим перед швидким переходом у електронний режим, що дозволило встановити електронний промінь для рентгенівського режиму без того, щоб ціль рентгенівських променів знаходилася на місці. Друга несправність дозволила електронному пучку активізуватися під час режиму "підсвітки області", якщо під час цього не було активовано жодного режиму пучка або не було встановлено цілі.

Попередні моделі мали апаратні блокування для запобігання подібних несправностей, проте Therac-25 прибрав їх, покладаючись на перевірки програмного забезпечення.

Електронний промінь високого струму вражав пацієнтів приблизно в 100 разів більшою від запланованої дозою опромінення та на більш вузькій ділянці, направляючи потенційно смертельну дозу [бета-випромінювання]. Супровідні відчуття були описані пацієнтом Реєм Коксом (Ray Cox) як "сильне ураження електричним струмом", яке змусило його кричати і вибігти з кабінету лікування. [4] Через кілька днів з’являвся радіаційний опік, і пацієнти проявляли симптоми променевої хвороби; у трьох випадках травмовані пацієнти пізніше померли внаслідок передозування. [5]

Причини

Комісія приписувала основну причину загальній поганій архітектурі та поганим практикам розробки програмного забезпечення, а не окремим конкретним помилкам кодування. Зокрема, програмне забезпечення було розроблено таким чином, що було неможливо перевірити його простим автоматизованим способом. [3]

Дослідники, які розслідували аварії, виявили кілька супровдних причин. Вони згадували наступні інституційні причини:

  • AECL не мав незалежного перегляду програмного коду.
  • AECL не враховував розробку програмного забезпечення під час своєї оцінки того, як машина може дати бажані результати та які існували режими відмов. Вони складають частини загальних методик, відомих як моделювання надійності та управління ризиками.
  • Система помітила, що щось не так, і зупинила промінь рентгенівського випромінювання, але на екрані лише відобразилось слово "MALFUNCTION" з номером від 1 до 64 (найчастіше згадується "Malfunction 54"). Посібник користувача не пояснював і навіть не перелічив коди помилок, тому оператор натискав клавішу P, щоб усунути попередження і все одно продовжити.
  • Персонал AECL, а також оператори апарату спочатку не вірили скаргам. Це, ймовірно, було пов’язано із самовпевненістю. [1]:428
  • AECL ніколи не випробовував Therac-25 із поєднанням програмного та апаратного забезпечення, поки його не зібрали в лікарні.

Дослідники також виявили кілька інженерних проблем:

  • Збій ставався лише тоді, коли на терміналі VT-100 було введено певну нестандартну послідовність натискань клавіш, яка керувала комп'ютером PDP-11: "X" щоб (помилково) вибрати режиму фотонів 25MeV з подальшим "курсор вгору","E" щоб (правильно) вибрати режим електронів 25 МеВ, потім "Enter"; усе протягом восьми секунд.[3]
  • Конструкція не мала апаратного взаємоблокування, щоб запобігти роботі електронного променя у високоенергетичному режимі без встановлення цілі.
  • Інженер зробив повторне використання програмного коду зі старих моделей. Такі методи проявляються в так званому програмуванні карґо-культу, коли наявна сліпа залежність від раніше створеного коду, який недостатньо зрозумілий і може бути, а може і не бути доречним. Ці моделі мали апаратні блокування, що маскували дефекти їхнього програмного забезпечення. Ці апаратні засоби безпеки не повідомляли про те, що вони спрацьовували, тому не було жодних ознак наявності несправних програмних команд.
  • Обладнання не передбачало можливості програмно перевірити, чи спрацьовують датчики правильно (див. Розімкнена система автоматичного керування ). Система позиціонування столу була спершу пов'язана з відмовами Therac-25; виробник переглянув це за допомогою зайвих вимикачів, щоб перехресно перевірити їх роботу.
  • Процес управління обладнанням не був належним чином синхронізований із процесом інтерфейсу оператора, так що відбувся стан гонитви, якщо оператор занадто швидко змінював налаштування. Це було упущено під час тестування, оскільки потрібна була певна практика, перш ніж оператори змогли б працювати досить швидко, щоб опинитися у цьому режимі відмови.
  • Програмне забезпечення встановлювало змінну прапорця шляхом його збільшення, а не встановлюючи його на визначене ненульове значення. Інколи траплялося арифметичне переповнення, спричиняючи повернення прапорця до нуля, а програмне забезпечення - до обходу перевірок безпеки.

Програмне забезпечення було написане мовою асемблера, що вимагає більше уваги для тестування та доброї архітектури. Однак вибір мови сам по собі не вказаний як основна причина у звіті. Апарат також використовував власну операційну систему.

Левесон зазначає, що урок, який слід зробити з інциденту, - це не припускати, що повторно використане програмне забезпечення є безпечним: "Часто робиться наївне припущення, що повторне використання програмного забезпечення або використання комерційного нестандартного програмного забезпечення підвищить безпеку, оскільки це програмне забезпечення вже є широко випробуваним. Повторне використання програмних модулів не гарантує безпеку в новій системі, в яку вони встановлюються ... "[3] Ця сліпа віра у погано зрозумілі парадигми, кодовані програмним забезпеченням, відома як програмування карґо-культу. У відповідь на такі випадки, як із Therac-25, було створено стандарт IEC 62304, який впроваджує стандарти життєвого циклу розробки програмного забезпечення для медичних виробів та конкретні вказівки щодо використання програмного забезпечення програмне забезпечення невідомого походження.[6]

Див. також

Посилання

  1. Baase, Sara (2008). A Gift of Fire. Pearson Prentice Hall.
  2. Leveson, Nancy G.; Turner, Clark S. (July 1993). An Investigation of the Therac-25 Accidents. IEEE Computer 26 (7): 18–41.
  3. Levenson, Nancy (1995). Safeware: System Safety and Computers. Appendix A: Medical Devices: The Therac-25. Addison-Wesley.
  4. Casey, Steven. Set Phasers On Stun - Design and Human Error. Aegean Publishing Company. с. 11–16.
  5. Rose, Barbara Wade. Fatal Dose - Radiation Deaths linked to AECL Computer Errors. www.ccnr.org. Процитовано 14 червня 2016.
  6. Hall, Ken (1 червня 2010). Developing Medical Device Software to IEC 62304. MDDI - Medical Device and Diagnostic Industry. Процитовано 12 грудня 2016.

Читати далі

This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.