Типичная разовая терапевтическая доза радиации составляет до 200 рад.
1000 рад — смертельная доза. Восставшая машина фигачила в беззащитных землян 20 000 рад.
Рассмотрим случай, когда поэтапное, но не согласованное внедрение улушений софта привело к системной ошибке. К худшей в истории программной ошибке.
В Therac-25 аппаратная защита была убрана и функции безопасности были возложены на программное обеспечение.
Как проводилось расследование, что должны намотать на ус проектировщики ИТ-систем, программисты, тестировщики, чтобы не допустить подобного.
Убийца
Therac-25 — аппарат лучевой терапии, медицинский ускоритель созданный канадской государственной организацией Atomic Energy of Canada Limited.
Реклама аппарата для домохозяек.
Убийство
С июня 1985 года по январь 1987 года этот аппарат стал причиной шести передозировок радиации, некоторые пациенты получили дозы в десятки тысяч рад. Как минимум двое умерли непосредственно от передозировок.
Медсестра вспомнила, что в тот день она заменяла «x» на «e». Выяснилось, что если сделать это достаточно быстро, переоблучение случалось практически со 100-процентной вероятностью.
Расследование
Во время ведения судебных дел против AECL прокуратура штата Техас обратилась к Нэнси Ливесон (профессор компьютерных наук Калифорнийского Университета в Ирвайне) как к эксперту для расследования. Она внесла весомый вклад в компьютерную безопасность. Нэнси с Кларком Тёрнером в течение трех лет занимались сбором материалов и реконструкцией событий, связанных с Therac-25. Данный результат важен, так как в большинстве инцидентов по безопасности информация является неполной, противоречивой и неверной.Канадская государственная организация «Atomic Energy of Canada Limited» (далее AECL) выпустила три версии: Therac-6, Therac-20 и Therac-25. 6 и 20 были произведены совместно с французской компанией CGR. Партнёрство прекратилось перед проектировкой Therac-25, но у обеих компаний остался доступ к проектам и исходным кодам ранних моделей.
Программный код в Therac-20 основывался на коде Therac-6. На всех трёх аппаратах был установлен компьютер PDP-11. Предыдущим моделям он не требовался, так как они были спроектированы как автономные устройства. Техник по лучевой терапии настраивал различные параметры вручную, в том числе и положение поворотного диска для настройки режима работы аппарата.
В электронном режиме отклоняющие магниты распределяли луч так, чтобы электроны покрыли большую площадь. В рентгеновском режиме мишень располагалась на пути излучения, электроны наносили по ней удар, чтобы произвести фотоны рентгеновского излучения, направленные на пациента. Наконец, на пути ускорителя можно было расположить отражатель, с помощью которого рентгенотехник мог навести излучение точно на больное место. Если отражатель был на пути, электронный луч не запускался.
На Therac-6 и 20 аппаратные механизмы блокировки не позволяли оператору сделать что-то опасное, скажем, выбрать электронный пучок высокой мощности без рентгеновской мишени на месте.
Попытка активировать ускоритель в неправильном режиме приводила к срабатыванию предохранителей и остановке работы. PDP-11 и сопутствующее оборудование были встроены для удобства. Техник мог ввести рецепт в терминал VT-100, и компьютер, используя сервоприводы, автоматически настраивал поворотный диск и другие устройства.
Сотрудникам больниц нравилось, что компьютер настраивает всё быстрее, чем человек. Чем меньше времени уходило на настройку, тем больше пациентов можно было принять за день.
Когда пришло время сделать Therac-25, AECL решили оставить только компьютерное управление. Они отказались от устройств ручного управления и от аппаратных механизмов блокировки. Компьютер должен был следить за настройками устройства и, в случае обнаружения неполадок, должен был отключать питание всей машины.
Ну ну.
В программном обеспечении Therac-25 были найдены как минимум четыре ошибки, которые могли привести к переоблучению.
- Одна и та же переменная применялась как для анализа введённых чисел, так и для определения положения поворотного круга. Поэтому при быстром вводе данных через терминал Therac-25 мог иметь дело с неправильным положением поворотного круга (состояние гонки).
- Настройка положения отклоняющих магнитов занимает около 8 секунд. Если за это время параметры типа и мощности излучения были изменены, а курсор установлен на финальную позицию, то система не обнаруживала изменений.
- Деление на величину излучения, приводящее в некоторых случаях к ошибке деления на ноль и к соответствующему увеличению величины облучения до максимально возможной.
- Установка булевской переменной (однобайтовой) в значение «истина» производилось командой «x=x+1». Поэтому с вероятностью 1/256 при нажатии кнопки «Set» программа могла пропустить информацию о некорректном положении диска.
Были выявлены потенциальные ошибки — в многозадачной операционной системе не было никакой синхронизации.
Исправления
- Все прерывания, относящиеся к системе дозиметрии, останавливали процедуру, а не ставили ее на паузу. Оператор был обязан заново вводить все параметры.
- Добавлено софтовое выключение «в один клик».
- Добавлено независимое хардверное выключение «в один клик».
- Кодированные сообщения об ошибках заменены осмысленными и на экране выводился текущий уровень облучения.
- Добавили потенциометр, который определяет положение поворотного диска.
- Изменение положения диска и других частей аппарата теперь возможно только тогда, когда оператор удерживает специальную педаль (deadman switch) .
- В режиме рентгеновской терапии отклоняющие магниты для электронной терапии устанавливаются в такую конфигурацию, что отклоняют пучок электронов на 270°.
Производитель сообщил, что программное и аппаратное обеспечение протестировано в течение многих лет. Однако, при разбирательстве выяснилось, что программное обеспечение было проверено минимальным количеством тестов на симуляторе, а большинство времени тестировалась вся система в целом. Таким образом, модульным тестированием пренебрегали, а проводили только интеграционное тестирование.
Было выдвинуто наивное предположение, что повторное использование кода или коробочного продукта увеличит безопасность программного обеспечения в силу длительности их успешного применения. Повторное использование кода не гарантирует безопасность модуля в новой системе, так как её проектирование имеет свои особенности. Переписывание с нуля позволяет получить более простую и прозрачную систему, и как следствие, более безопасную.
В данном случае имело место повторное использование программного кода с Therac-6 и Therac-20. В Therac-6 вообще не было рентгеновской терапии, в Therac-20 применялся механический блокиратор.
После несчастных случаев Therac-25 FDA изменило своё отношение к множеству проблем систем, связанных с безопасностью, и особенно в отношении к программному обеспечению. Как результат, FDA запустило процесс улучшения своих процедур, директив и системы отчетности, и включило в них программное обеспечение. Данный урок был важным не только для FDA, но и для всех промышленных систем, критичных к безопасности.
Еще материалы по теме Therac-25
- My professor investigated the Therac-25 incident and was a part of the prosecution. Got any questions for me to ask him?
- What is the name of the programmer who wrote the Therac-25 software?
- Fatal Defect: Chasing Killer Computer Bugs
- Nancy Leveson, Clark S. Turner An Investigation of the Therac-25 Accidents
- Nancy G. Leveson, Therac-25 Accidents
- Nancy G. Leveson Safeware: System Safety and Computer
- Infusion Pump Software Safety Research at FDA
Заключение
Software Engineering Institute говорит о среднем числе в 1 баг на каждые 100 строк кода и 98% случаев сбоев устройств, случающихся по причинам багов в ПО, легко можно было бы избежать при должном уровне тестирования кода. Зная об этом, хочется примкнуть к движению "дайте код посмотреть". Вроде бы меры после громких случаев приняты, но все равно не очень хочется столкнуться с бормашиной, где в переменной, отвечающей за угловую скорость, «ошиблись на нолик». Уважаемые тестировщики (программисты, разработчики), делайте свою работу хорошо.
UPD
The University of California, Berkeley: Computer Science 61A — Lecture 35: Therac-25
Комментарии (35)
wolowizard
13.09.2016 13:43Заголовок и набор картинок дает основание предполагать, что пост изначально был предназначен для публикации на Пикабу.
DenimTornado
13.09.2016 14:26а. Это стиль MagisterLudi
б. Две картинки и сразу пикабу? Тогда почти весь гиктаймс туда же.wolowizard
13.09.2016 15:00+5На хабре ожидаешь увидеть все-таки более серьезные статьи, иллюстрации в которых связаны с текстом. А с таким стилем появляется ощущение, что читаешь глянцевый журнал — можно просто посмотреть узнаваемые картинки не читая текст вообще. Хотя сама статья интересная.
Tujh
13.09.2016 15:31Ну сама статья то нормально написана, даже рекламу своего продукта не вставляли. А заголовок… на GT «штатный» Ализар и не такое заворачивает порой.
Dziki_Jam
16.09.2016 10:11А ещё автор измеряет дозу радиации в Рентгенах, хотя накопленные дозы измеряются в Греях, а в рентгенах измеряются экспозиционная доза. Экспозиционные дозы люди порой переживали и больше, чем 1000 рентген. Вот этот чел получил 300 000 рентген и остался жив, поэтому это как с электричеством: убивает ток, а не напряжение, потому что ток проходит через тебя. Накопленная радиация остается внутри организма и наносит постоянные повреждения.
TimsTims
13.09.2016 15:16+5> хочется примкнуть к движению «дайте код посмотреть»
Уже обсуждали этот холивар, примерно год назад.
С одной стороны — ну ок, допустим все компании мира раскроют все свои коды(терабайты кодов) для всех. Вы сможете открыть код в блокнотике и почитать, чего же там Therac делает. Но хватит ли вам компетенции разобраться, какая должна подаваться мощность на выход, какие там стоят резисторы, работающие с этой энергией. Хватит ли вам компетенции знать, какие участки тела за что отвечают, как их нужно лечить и какой для всего этого должен быть код?
Продолжая эту тему, предположим, что вы нашли потенциальную ошибку в коде. Что вы будете делать? Напишете производителю. Производитель получает в день по 10 000 таких малосодержательных писем, с темой «у вас тут баг». А если даже тема будет содержательная, то производителю надо будет проверить — действительно ли там ошибка. Это время сотрудников, это деньги, это деньги которые обычная компания лучше направит на продажи, чем починку багов. Поэтому скорее всего, ваши письма будут просто игнорироваться.
Или допутсим вы получили исходный код чипа, который управляет вашим искуственным сердцем. Вы нашли «ошибку», решили перепрошить своё сердце, но хоп — ошибка в коде, чип отрубается, сердце останавливается. Или ты не правильно рассчитал формулу расчета нагрузки на сердца, и твоё сердцебиение вместо должных 90 ударов в минуту — вдруг начало выдавать 50? Стоит ли лезть, если ты нифига не понимаешь в этом? Что ты там увидишь в этом громадном коде?
Подводя итог — в воздухе витает наивное мнение, что если вдруг компании откроют исходный код, то сразу всем станет лучше, т.к. все вдруг ринутся этот код улучшать. В целом, так и происходит с обычным ПО, а что касается медицины, или полетов в космос — сомневаюсь в компетентности общества.
MagisterLudi
13.09.2016 15:43+2Иллюзия контроля — одно из когнитивных искажений, выражающееся в тенденции людей верить в то, что они каким-либо образом могут влиять на события, которые объективно от них не зависят или зависят в гораздо меньшей степени. Эффект проявляется, когда человек заинтересован в положительном исходе события и как-либо вовлечён в событие или ему заранее известен благоприятный исход.
Saffron
13.09.2016 18:09+1> сомневаюсь в компетентности общества.
Зато компания-конкурент с радостью будет закапывать своих противников.
Опять же можно доверить проверку третьей стороне — как в случае трукрипта, где сообщество скидывается, чтобы нанять профессионалов.
Ну и некоторый код так пахнет, что его даже проверять не надо. Видишь код без единого комментария и теста, зато с процедурами по 500 строчек, и сразу понимаешь, что мимо этого куска говна лучше пройти.
Бизнес привык оптимизировать внешний вид приложений, чтобы ни один скриншот в обзорах не отпугнул пользователя. А если обзорщики начнут ещё и скриншоты кода публиковать, придётся вылизывать и его.
saboteur_kiev
13.09.2016 18:57+1Насколько я помню, профессионалы не смогли дать 100% гарантию, что в трукрипте нет закладок. В основном они анализировали последние изменения в коде, а не весь код.
Но вот хакеры точно порадуются открытым исходникам. Я вот помню, как через полгода-год, как утекли исходники win2000, появилось множество весьма жестких руткитов.Saffron
13.09.2016 20:25Ну значит народ начнёт больше платить за безопасность. Сейчас её вроде как не видно, вот денег и не выделяется. А проблема цветёт и пахнет.
Barafu
13.09.2016 23:46+1Профессионалы не могут дать гарантию, что там нет хитроумных закладок. Но по крайней мере там нет http_send(keys, «fbi.gov»);. В открытом коде польза не лично каждому пользователю, что каждый может смотреть, что там написано. Польза в том, что энтузиаст может посмотреть, и таким образом общее количество посмотревших будет намного больше, а косяков намного меньше. Не «Нет», а «намного меньше».
Багтрекеры компаний завалены бесполезными репортами типа «вот то не это» от юзеров, обычно невоспроизводимыми у разработчика. Когда код открыт, то от спецов приходят полезные и чёткие багрепорты, исправлять которые намного проще.
iv_shalin
13.09.2016 15:43-4Ждем развития ИИ до уровня Скайнет
MagisterLudi
13.09.2016 15:44+1Пришла мысль, что в прошлое «проще» отправить не качка 120кг, а парочку «багов».
red75prim
13.09.2016 18:45+1Это точно. Определить какие именно баги были засланы среди сотен тысяч имеющихся будет трудно.
tarasius
13.09.2016 18:49+2А сейчас FDA и ко понавводили столько требований, что поднять стартап на тему медицинского софта почти нереально. И стоит задуматься — хорошо или плохо, что тогда случился этот скандал, который привёл к ситуации, что в других странах медицинский софт более развит, чем в США.
IvanPonomarev
13.09.2016 22:57+2Наверное, это самый показательный пример в истории, чего может стоить «говнокод» (в данном случае — чей-то выпендр с установкой boolean-переменной способом x = x +1). Случай Therac-25 подробно разобран в книге «Наука отладки» (М. Тэллес, Ю. Хсих), рекомендую.
Другой показательный случай, разбор которого ещё ожидает своей статьи на Хабре — это ошибка в коде системы марсоходов Spirit/Opportunity, из-за которых они едва не были потеряны. Можно не сомневаться, что в 2003-м году с дисциплиной разработки в NASA всё обстояло гораздо лучше, чем у создателей Therac-25 в 1985-м. И тем не менее, ни один из тестов не проверял, что случится, когда FLASH-память марсохода окажется заполненной собранными данными больше определённого уровня. Марсоход летел-летел, прилетел, начал делать фото, память заполнилась и система зависла.
Показательно, что ситуацию с марсоходами спасла аппаратная возможность через независимый контур перезапустить систему и загрузить обновление. А ситуацию с Therac-25, наоборот, погубил отказ от аппаратной защиты от переоблучения.
postgrez4ik
14.09.2016 00:09-2Спасибо за статью, но с википедии откровенно абзацы копипастили. Странно, что гугл-транслейт переводит название устройства как: The rac — РАК…
Adamantium
14.09.2016 01:23В блоге PVS Studio как-то привыкли больше к разбору кода более конкретно. В связи с этим вопрос — а есть ли хоть какие-то открыто доступные куски кода, в которые можно ткнуть пальцем и показать «вот здесь ошибка, так как ...»?
olgerdovich
14.09.2016 01:50+1многовато прямых заимствований с русскоязычной википедии, скажем прямо, копипаста.
статью без потери содержания можно было написать так:
«напоминаем, что в истории случился смертоносный программный баг в рентгеновской медицинской технике. пройдите по ссылке https://ru.wikipedia.org/wiki/Therac-25 », далее оставить два последних абзаца этой публикации (дополнительнительные ссылки и заключение)
andrey_aksamentov
16.09.2016 10:11Непонятно: почему этот агрегат имел мощность что бы выдавать смертельное излучение? Это же идиотизм.
rogoz
16.09.2016 15:19Это по сути ускоритель электронов. Он мог жарить опухоль непосредственно пучком электронов, тогда мощность маленькая, плюс пучок мог специально быть несфокусированным. А мог с помощью торможения пучка электронов на металлической мишени генерировать рентген, которым жарилась опухоль. Вот только КПД этого процесса в районе 1%, если не ошибаюсь. Поэтому нужен начальный мощный пучок электронов. Баг в том, что включён типа режим рентгена, но металлической мишени на пути пучка нет, мощный пучок электронов сразу идёт в пациента.
maksqwe
Тут же в мыслях мелькнул желтушный заголовок…
«PVS-Studio спасает людей от заложенных в ПО убийц!»
IvaYan
"Наёмный баг-убийца..."
Tujh
даже PVS не сможет найти подобные ошибки :)
maksqwe
Подобные может и нет, но вы посмотрите сколько и в каких проектах находили дичайшие опечатки которые в каком-то из набороа параметров могли выстрелить и приводили или к порче данных или к краху программы или к неопределенному поведению, так что доля истины в моем заголовке есть.
Tujh
Чаще всего ошибки находятся в малопротестированных или малоиспользуемых участках кода.
Но вообще согласен — статья интересная и полезная.
Andrey2008
Да, в протестированных участках кода редко что-то находится статическим анализатором. Но учтите, что правятся такие ошибки ценой траты времени, сил и здоровья. А многие из них могли быть обнаружены сразу при написании кода.
Dreyk
да ладно, использование булеана в виде "x=x+1" должно же отлавливать
Andrey2008
В С++ если сделать так:
bool a = x;
a = a + 1;
Всё будет хорошо.
А если сделано так, то тут всё равно нельзя ругнуться:
byte a = x;
a = a + 1;
Слишком много ложных срабатываний будет.
Tujh
Читайте года этого бага. В чистом С, без плюсов, булевых переменных и сейчас нет, только инты(байты, слова и т.п.), и ноль или не ноль.
Sirikid
В C99 добавили