Инцидент с Therac-25 / forpes.ru

Главная
Инцидент с Therac-25

Инцидент с Therac-25 +73

01.09.2025 13:01

interpres 98 12000 Источник

Когда пристёгиваешь пациента к электронной пушке, способной выстреливать пучком частиц с энергией 25 МэВ, следование процедурам — вопрос жизни и смерти. Оператор, эксплуатировавшая аппарат лучевой терапии в Онкологическом центре Восточного Техаса (East Texas Cancer Center, ETCC), работала с ним достаточно долго для того, чтобы запомнить весь процесс.

21 марта 1986 года оператор пригласила пациента в процедурную. Она проверила его назначение и уложила его на стол Therac-25. Над пациентом находилась диафрагма излучателя — поворотный диск, позволявший выбрать тип излучаемого устройством пучка. Сначала оператор переключила поворотный диск в простой режим оптического лазера, чтобы луч ударил в небольшой участок грудины пациента.

Правильно уложив пациента, она снова повернула поворотный диск. У него было ещё два режима: один позиционировал массив магнитов между пучком и пациентом; магниты должны формировать и нацеливать пучок; второй помещал кусок металла между пучком и пациентом. При подаче пучка электронов мощностью 25 МэВ на металл он создаёт рентгеновское излучение.

В направлении пациента был указан пучок электронов, поэтому оператор установила поворотный диск и вышла из кабинета. В соседнем кабинете, экранированном от излучения, находился пульт управления. Оператор начала вводить направление, чтобы начать процедуру лечения.

Если бы всё происходило точно по процедуре, то она бы могла общаться с пациентом по интеркому и следить за пациентом через видеокамеру. К сожалению, в тот день эта система была сломана. Тем не менее, для пациента эта процедура была не новой, он знал, чего ожидать, поэтому без общения с оператором можно было обойтись. На самом деле, Therac-25 и всё его оборудование всегда было капризным, поэтому «что-то не работает» практически и было частью процедуры.

Оператор выполняла этот процесс так много раз, что научилась вводить направление очень быстро, по крайней мере, на этом устройстве. Возможно, даже слишком быстро. В поле типа пучка она случайно ввела «X» (от «x-ray», рентгеновские лучи). Ошибка была естественной, ведь большинство пациентов подвергалось рентгеновскому лечению, и особой проблемы не представляла: компьютер увидел бы, что поворотный диск находится не в том положении, и отказался облучать пациента дозой. Оператор быстро нажала на клавишу «вверх» на клавиатуре, чтобы вернуться к полю, изменила значение на «E» («electron») и подтвердила ввод всех остальных параметров.

Её палец навис над клавишей «B», пока она проверяла правильность ввода даты. Убедившись, что всё правильно, она нажала на «B» («beam start», «запустить пучок»). Не раздалось никакого шума, впрочем, как и всегда, но спустя секунду на терминале высветилось «Malfunction 54» («Неисправность 54»), а затем «Treatment Pause» («Процедура приостановлена»).

Ошибки никого не удивляли. Рядом с консолью у оператора висела таблица со всеми кодами ошибок. В данном случае, «Malfunction 54» означало ошибку «dose input 2» («ввод 2 дозы»).

Возможно, это ничего не объясняло, но оператор привыкла к загадочности кодов ошибок. А «процедура приостановлена» означало, что следует продолжить процедуру. Согласно информации на терминале, излучение ещё не подавалось, поэтому она нажала клавишу «P», чтобы снять пучок с паузы.

А потом она услышала крик.

У пациента уже было несколько таких сеансов, и он знал, что ничего не должен почувствовать. Однако когда оператор активировала пучок в первый раз, он ощутил жжение, которое позже сравнил с «горячим кофе», пролитым ему на спину. Без интеркома он не мог позвать на помощь, поэтому начал слезать с процедурного стола. Он всё ещё сползал, крича о помощи, когда оператор сняла пучок с паузы; при этом он испытал нечто, похожее на сильнейший удар электрическим током.

Это стало первым диагностическим признаком неполадки. Было решено, что неисправность аппарата вызвала удар током. Пациента отпустили домой, а дозиметрист больницы изучил Therac-25, убедился, что всё работает и нет никаких признаков проблем. Непохоже было, что подобное повторится.

Пациенту прописали дозу в 180 рад в рамках шестинедельной программы лечения, в течение которой он суммарно получил бы шесть тысяч рад. Согласно показаниям Therac-25, пациент получил недостаточную дозу, небольшую долю этого излучения. Никто ещё не знал, что неисправность привела к подаче примерно 16-25 тысяч рад. Казалось, с пациентом всё в порядке, но на самом деле он был мёртв, просто никто этого ещё не знал.

Инцидент в ETCC был не первой и, к сожалению, не последней неисправностью системы Therac-25. В период с июня 1985 года по июль 1987 года произошло шесть инцидентов с аппаратом Therac-25, изготовленным компанией Atomic Energy Canada Limited (AECL). Каждый завершился сильной передозировкой радиации, что привело к серьёзным травмам, увечьям и смертям.

Когда начали происходить первые инциденты, никто точно не понимал, в чём дело. Радиационное отравление сложно диагностировать, особенно если его не ожидаешь. В инциденте в ETCC аппарат сообщал о недостаточной дозе, несмотря на то, что пациент получил передозировку. Когда возникло подозрение на передозировку, дозиметристы больницы даже обратились в AECL, но им лишь сказали, что это невозможно.

Спустя несколько недель в ETCC произошёл второй случай передозировки, и примерно в то же время этой ситуацией заинтересовалось Управление по санитарному надзору за качеством пищевых продуктов и медикаментов США, а также пресса. Поначалу было множество гипотез о причинах инцидентов. Любопытен следующий комментарий из списка рассылки RISKS за 1986 год.

Вот моя гипотеза о произошедшем: подозреваю, что ток в пучке электронов, вероятно, в режиме рентгеновского излучения гораздо больше (потому что в обоих режимах нужны близкие по величине дозы, а генерация рентгеновского излучения выполняется более косвенным образом). Поэтому, думаю, при выборе рентгеновского режима металл устанавливается в позицию и повышается ток пучка. Подозреваю, что в данном случае ток увеличился до того, как металл перешёл в нужное положение, и в пациента попал пучок электронов с очень высоким током.

Как могли допустить возможность подобного? Думаю, что разработчики ПО не посчитали необходимым обеспечить защиту от этого режима отказа. Традиционно проектировщики аппаратов для обеспечения безопасности применяли электромеханические замки. Компьютерное управление аппаратами терапии — достаточно новое слово техники, и оно было добавлено поверх старых электромагнитных механизмов, а не заменило их.

Therac-25 был первым устройством радиотерапии с полностью программным управлением. Как и говорилось в цитате выше, у большинства таких систем есть аппаратные замки, препятствующие подаче пучка, когда мишени сконфигурированы неправильно. В Therac-25 их не было.

ПО состояло из нескольких ключевых модулей, работавших на компьютере PDP-11. Во-первых, в нём были отдельные процессы для обработки каждой ключевой функции системы: пользовательского ввода, регулировки пучка, отслеживания дозировки и так далее. Все эти процессы были реализованы на языке ассемблера PDP-11. Управляла этими процессами ОС реального времени, тоже реализованная на языке ассемблера. Всё это ПО, от отдельных процессов до самой ОС, было создано одним разработчиком.

Однако AECL была уверена в этом ПО, потому что оно не было новым. Первые версии ПО были разработаны ещё для Therac-6. Разработка началась в 1972 году, а в 1976 году программы были адаптированы под Therac-25. То же самое ядро применялось и в Therac-20. AECL считала, что ПО должно быть безопасным, ведь им пользовались уже долгое время.

На самом деле, когда AECL проводила собственный внутренний анализ безопасности Therac-25 в 1983 году, компания исходила их следующих допущений:

1) Количество ошибок программирования было снижено благодаря тестированию устройств дистанционной терапии на аппаратном симуляторе и в полевых условиях. Оставшиеся программные ошибки не были включены в анализ. 2) Программное обеспечение не ухудшается от износа, усталости и погрешностей воспроизведения. 3) Причинами ошибок компьютерного ПО становятся сбойные аппаратные компоненты, а ошибки «софта» (случайные) привносятся альфа-частицами или электромагнитным шумом.

Иными словами, «мы уже долгое время пользуемся этим ПО, а ПО всегда копируется и устанавливается идеально. Поэтому все наблюдаемые баги обязательно должны быть временными ошибками, вызванными излучениями или ошибками оборудования».

После второго инцидента в ETCC дозиметрист больницы вывел Therac-25 из эксплуатации и совместно с оператором приступил к воссозданию действий, которые привели к передозировке. Вызвать сообщение об ошибке «Malfunction 54» было непросто, особенно при методических попытках воссоздания конкретных действий, потому что, как оказалось, если вводить данные медленно, проблемы не возникают.

Для передозировки необходимо было вводить данные быстро, со скоростью опытного оператора. Дозиметрист практиковался, пока не смог воссоздать ошибку, а затем сообщил о своих результатах AECL. Пока он замерял величины передозировок, AECL ответила ему: компания сообщила, что не может воссоздать ошибку. По сути, она сказала «на моём компьютере всё работает».

Потренировавшись для достижения нужной скорости, техники AECL вернулись к проверкам и убедились, что могут вызвать передозировку. Когда замеры выполнял дозиметрист больницы, он получил результат около 4000 рад. AECL, проводя похожие тесты, смогла получить передозировки в 25000 рад. Проблема заключалась в том, что в зависимости от момента результат потенциально мог быть случайным.

Имея эту информацию, стало проще выявить первопричину: это было состояние гонки. Когда оператор ошибочно ввела «X» (x-ray), компьютер вычислял последовательность активации пучка для подачи высокоэнергетического пучка с целью генерации рентгеновского излучения. Когда оператор нажала на клавишу «вверх», чтобы исправить свою ошибку, это должно было привести к пересчёту последовательности активации, но если пользователь выполнял ввод слишком быстро, то UI обновлялся, однако пересчёт не происходил.

В середине 1986 года в ситуацию вмешалось Управление по санитарному надзору за качеством пищевых продуктов и медикаментов (Food and Drug Administration, FDA) и потребовало, чтобы AECL разработала и внедрила план корректирующих мероприятий (Corrective Action Plan, CAP). Далее последовал длительный процесс внесения поправок: AECL присылала свой CAP, после чего FDA задавала вопросы, приводившие к новым поправкам в CAP.

Например, FDA проверило первую версию CAP и отметило, что она неполная. В частности, в него не был включён план испытаний. AECL ответила так:

Не существует единого плана испытаний и отчётности для ПО, потому что оборудование и ПО уже многие годы тестировались и эксплуатировались по отдельности.

FDA это не понравилось, и после переписки оно ответило следующим образом:

Мы выражаем озабоченность тем, что вы не намереваетесь выполнять протокол [испытаний] для будущих модификаций программного обеспечения. Мы считаем, что при каждом внесении изменений необходимо проводить тщательные испытания, чтобы гарантировать, что эти изменения не повлияют негативно на безопасность системы.

Пока AECL испытывала проблемы с добавлением в CAP таких сложных задач, как тестирование, она выпустила инструкции, позволявшие временно устранить проблему для предотвращения инцидентов в будущем. К сожалению, в январе 1987 года произошёл ещё один инцидент, вызванный другим программным багом.

В ПО существовала переменная, общая для нескольких процессов, она использовалась, как флаг, определяющий, должен ли коллиматор пучка в поворотном диске проверяться на нахождение в нужном положении. Если значение было не равно нулю, проверка должна была выполняться. К сожалению, ПО выполняло инкремент поля, а поле имело ширину всего в один байт. То есть каждый 256-й инкремент переменная обнулялась, хотя должна была иметь ненулевое значение. Если ошибочный ноль совпадал с действиями оператора, то пучок подавался с максимальной мощностью, когда поворотный диск находился в неправильном положении.

AECL устранила этот баг (код перестал выполнять инкремент и теперь просто задавал значение) и дополнила CAP. Управление FDA признало, что это, вероятно, предотвратит возникновение проблемы, но всё равно не было убеждено полностью. Цитата из внутреннего документа:

Мы заявляем: можно считать, что предложенный CAP устранит недостатки, для ликвидации которых он был разработан. Однако мы не можем сказать, что полностью уверены в безопасности системы в целом…

Переписка продолжилась и привела к созданию множества новых версий CAP. На каждом этапе процесса сотрудники FDA находили проблемы с испытаниями. Процесс испытаний AECL заключался в простом запуске аппарата и проверке правильности его работы. Так как ПО в той или иной версии использовалось уже больше десяти лет, компания не видела никаких причин тестировать ПО, поэтому у неё не было ни возможностей, ни планов по тестированию, когда того потребовало FDA.

В процессе проверки результатов испытаний FDA отметило следующее:

Удивительно, что тестовые данные, представленные для доказательства того, что изменения в ПО для решения проблем с редактированием в интерфейсе Therac-25 реализованы правильно, показывают обратное… Я могу лишь предположить, что исправленная версия некорректна или что данные введены неправильно.

В конечном итоге, программное обеспечение всё-таки исправили. Были внесены изменения в законодательные и регламентирующие документы, чтобы предотвратить подобные инциденты в будущем; по крайней мере, возникающие таким же образом.

Стоит отметить, что весь этот код писал один разработчик. Он уволился из AECL в 1986 году и, к его счастью, никто не раскрыл его личности. Мы могли бы возложить всю вину на него, ведь он принимал каждое техническое решение и кодировал каждый баг, но это было бы несправедливо.

Исходя из того, что AECL по-прежнему не могла объяснить, как тестировать её оборудование, можно понять, что проблема была систематической. Неважно, насколько хорош разработчик ПО; качество программного обеспечения не возникает само по себе только потому, что в компании работают хорошие разработчики. Это конечный результат процесса: этот процесс формирует и практики разработки ПО, но также и тестирование, управление разработкой, продажи и техническое обслуживание.

Хоть к изменениям привели инциденты в ETCC, это не были первые случаи. Дозиметристы разных клиник и раньше сообщали AECL о проблемах. Как минимум один пациент подал исковую претензию. Но эта информация не распространялась в организации; никто не мог собрать данные воедино, чтобы понять, что устройство может быть сбойным.

Мы часто смеёмся над незадачливыми или неопытными программистами. Но какими бы некомпетентными, безрассудными или невежественными они ни были, они являются частью системы, и именно система выдвинула их на их должность.

Сбои в ИТ редко оказываются личными неудачами. Это сбои процессов, систематические и организационные сбои. История AECL и Therac-25 показывает, насколько плохо могут окончиться организационные недосмотры.

В AECL отсутствовал процесс разработки ПО. Компания не рассматривала программное обеспечение как нечто большее, нежели компонент системы в целом. В подобных рабочих средах ни один разработчик не может быть полностью успешным при работе над критичными для безопасности системами. Учитывая, что в данной ситуации на кону в буквальном смысле стояли человеческие жизни, главным приоритетом должно было стать проектирование системы, создающей безопасное и качественное ПО. Однако этот приоритет отсутствовал.

Инцидент с Therac-25 — уже древняя история, но с тех пор ПО стало ещё важнее для мира. Мы надеемся, что критичное для безопасности ПО разрабатывается по строгим процедурам, но знаем, что это не всегда так. Относительно недавним примером стали катастрофы Boeing 737MAX. Но, учитывая важность ПО в современном мире, даже более тривиальные программные проблемы могут принимать огромный масштаб. Машинное обучение, усиливающее расовые предрассудки, социальные сети, превращающиеся в источники дезинформации, плохо защищённые IoT-устройства, становящиеся ботнетами — всё это свидетельства того, как ПО взаимодействует с миром и влияет на него.

Надеюсь, что, по крайней мере, эта статья заставит вас задуматься о процессе, который мы применяем для разработки ПО. Настроен ли процесс так, чтобы обеспечивать качество? Какие препятствия он ставит перед качеством продукта? Является ли качество приоритетом, и если нет, то почему? Учитывает ли ваш процесс качество при масштабировании ПО? Возможно, вы знаете режимы отказа своего ПО, но знаете ли вы, какие режимы отказа у вашей организации? Её слепые пятна? Какие используемые ею допущения могут быть не всегда истинны?

Давайте ненадолго вернёмся к состоянию гонки, ставшему причиной инцидентов в ETCC. Оно возникло из-за того, что пользователи слишком быстро нажимали на клавишу «вверх», и система не успевала правильно зарегистрировать внесённые изменения. Пока продолжался процесс согласования CAP с FDA, компания AECL хотела обеспечить безопасную эксплуатацию Therac-25, поэтому публиковала исправления, которые пользователи должны были применять в своих аппаратах.

Вот письмо, которое AECL разослала с целью устранения этого бага:

ТЕМА: ИЗМЕНЕНИЯ В ПРОЦЕДУРАХ ЭКСПЛУАТАЦИИ ЛИНЕЙНОГО УСКОРИТЕЛЯ THERAC-25
С этого момента и до дальнейшего уведомления клавишу, используемую для перемещения курсора обратно при вводе направления (то есть клавишу курсора «вверх» с нарисованной на ней стрелкой вверх) не допускается использовать для редактирования и любых других целей.
Чтобы избежать случайного нажатия на эту клавишу, следует снять клавишный колпачок и при помощи изоляционной ленты или иного изолирующего материала зафиксировать контакты в открытом положении.
За помощью в реализации последнего следует обратиться к местному представителю технической поддержки AECL.
При отключении этой клавиши в случае ввода любых некорректных данных направления следует использовать команду сброса «R» и вводить направление повторно.
В случае использования опции Multiport это также означает, что между портами будет невозможно редактировать мощность дозы, дозировку и время.

С одной стороны, это простая инструкция, которая предотвратила бы повторение инцидентов, аналогичных произошедшим в ETCC. С другой стороны, ужасно представлять, что жизнь пациента зависит от вырванного клавишного колпачка и изоленты.

Эта статья — лишь краткое описание инцидента. Основная часть технических подробностей взята из детального отчёта об инциденте с Therac-25. Это главный источник информации по данной теме, поэтому я рекомендую изучить его целиком. В нём содержится гораздо больше подробностей, в том числе глубокое исследование решений, принятых при разработке ПО, и организационных провалов.

Комментарии (98)

AlexXYZ
01.09.2025 13:31
#28781930
1. Неужели было трудно поставить датчик измерения на выходе, который моментально отключал бы оборудование, если оно выдаёт количество излучения, которое, очевидно, будет представлять угрозу для пациента?
2. Обработка ошибок - это прямо домоклов меч программирования во все времена. Программист считает, что пользователь не может ошибиться, а пользователь считает, что программа всё проверяет.
1. AbitLogic
  01.09.2025 13:31
  #28781986
  В прошлом аппарате Therac-20 такая защита была и иногда срабатывала, когда пользовались новички, когда же вводили опытные операторы им не удавалось воспроизвести, не видя никакой системы в появлении бага - списывали на ошибку самой защиты, они прямо так и пишут, что ПО не подвержено деградации и всегда делает одно и то же, а вот аппаратная защита может глючить от излучения
  
  Rust решает эту проблему, он заставляет явно обработать ошибки программиста, а не надеяться на когда-нибудь потом, состояние гонки там можно получить только умышленно и надо очень постараться
  1. apevzner
    01.09.2025 13:31
    #28782684
    Состояние гонки, это не обязательно, когда два потока дерутся за одну переменную, которую забыли защитить мьютексом.
    
    В чуть более общем смысле, состояние гонки - это когда результат зависит от порядка вычислений, а порядок ничем не гарантирован.
    
    Этого можно даже и в одном потоке добиться, если он обрабатывает поток событий, которые могут приходить в разном порядке, по независящим от программы причинам, приводя в итоге к разному результату.
    
    В тривиальном случает, типа забытого мьютекса, Rust, неверное, поможет. В менее тривиальном случае тут логическая ошибка, и нет, увы, Rust не поможет.
    
    AbitLogic
    01.09.2025 13:31
    #28782714
    Не знаю как у вас, в совсем запущенном случае в Rust есть барьеры, которые именно что и делают, что гарантируют порядок операций
    
    А вообще дайте пример этого нетривиального случая однопоточного, посмотрим конкретику, а не пространные рассуждения и предположения, скорее всего это случай с какой-то кривой архитектурой, и средствами языка это не нужно решать, проблемы в голове программиста
    
    baldr
    01.09.2025 13:31
    #28782748
    Мне в голову приходит что-нибудь типа "отправить сообщение на двигатель повернуть заслонку в рабочее положение Х". Примерно так же, как это в статье описано для этого девайса - поворачивается медленно и если успеть за это время перейти к другой операции, то можем её начать ещё до того, как придет сигнал от концевика "заслонка в положении Х".
    
    okhsunrog
    01.09.2025 13:31
    #28782880
    Делаем поворот заслонки асинхронной операцией:
    
    use embassy_time::{Duration, with_timeout, TimeoutError}; async fn do_something() -> Result<(), TimeoutError> { motor.start(); with_timeout(Duration::from_secs(2), valve.wait_for_closed()).await?; motor.stop(); Ok(()) }
    
    Да-да, async сейчас прекрасно поддерживается в embedded Rust
    
    baldr
    01.09.2025 13:31
    #28782994
    Я пропустил момент когда вдруг разговор свернул на Rust. Я приводил чисто пример по связи софта и железа. Вполне может быть что кроме команд "закрыть" и "открыть" в протоколе ничего и не предусмотрено. Однако, операция не мгновенная. Отправили команду закрыть и пошли дальше, а по факту она ещё не завершилась..
    
    Не помню где это было, но читал про какой-то девайс, в котором был похожий случай - операция выполнялась некоторое время и в коде была задержка ожидания, высчитанная в количестве тактов. И при портировании кода на новый (более быстрый) процессор никто не поменял это количество. В результате программа продолжала выполнение ещё до того, как операция выполнялась. Вполне типичная ошибка.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28789796
    О, да! Видел запуск игры, рассчитанной на IBM PC/XT (что-то там про танки, кажется, это был "Абрамс"), на аналоге IBM PC/AT286. Башня танка крутилась как вентилятор! Ну да, процессор на целевой машине имел тактовую частоту 4,7 МГц, если не ошибаюсь, а на той, на которой запустили - как бы не 20. А когда всё это писалось, никто особо не думал, что машины с совместимыми системами команд могут иметь значимо разную частоту. А поскольку MS-DOS - однозадачная система, то есть никто с игрой за процессор не конкурировал, просто поставили пустой цикл на определённое количество повторов. С понятным результатом переноса на более быструю машину.
    
    С железом подобного не наблюдал, но результат тоже представить несложно. А ещё у двигателя заслонки может, к примеру, застыть масло или в редукторе шестерёнки подзаржавеют и всё, даже задержка по отдельному физическому таймеру приведёт к сбою. То есть заслонка закроется - двигатель всё равно докрутит, но вот когда - отдельный интересный вопрос. Или вовсе провод от коммутируемого контакта реле отвалится и никто ничего не узнает, потому реле будет исправно щёлкать.
    
    vanxant
    01.09.2025 13:31
    #28783058
    borrow checker в расте безусловно мощная штука, но от логических и ментальных ошибок никак не спасёт. В данном случае, тупо забыли / не подумали про задержки при исполнении команд реальным железом. Никакими барьерами такое не лечится, пока не будет исправлена цифровая модель управляемого железа.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28789852
    И не только цифровая, но и аппаратная: концевые выключатели, замыкание контактов самими деталями и прочее. И да, цифровая модель, предусматривающая проверку конфигурации оборудования перед началом процедуры. Это если говорить об оборудовании, похожем на описанное в статье.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28789744
    Пример из чисто софтовой "оперы". Я пишу парсеры и в большистве случаев использую прямую отправку запросов на сервер тем или иным способом (стандартные библиотеки для работы с HTTP, библиотеку requests и так далее). И вот тут всё в порядке, потому что последовательность запросов и ответов строго зашита в моём коде. И нет, дело не в том, что я не умею писать многопоточные программы, а именно что в прибитой гвоздями последовательности действий и событий. Но иногда приходится использовать Selenium, который запускает браузер и там уже тыкает в кнопки, ссылки, выпадающие списки, вводит текст в поля ввода и так далее. И вот, в очередной раз запускается парсер, грузится страница, парсер дожидается появления нужного элемента... Но машина оказалась слишком загруженной и JS на странице успевает совершить некоторое действие. Или наоборот, не успевает. И получаем баннер на полэкрана с блокировкой всего остального экрана и клик тыкается не туда, процесс ломается. Или элемент не успевает дорисоваться и кликать ещё некуда. И оказывается, что в мой однозначный и простой процесс, состоящий из простых последовательных действий оказывается замешан асинхронный внешний процесс. И приходится на каждом шаге проверять, догрузился ли нужный элемент, не перекрыла ли его какая-нибудь реклама и так далее. Так кода проверок становится в разы больше, чем колда целевого алгоритма. Такое и писать сложно, и отлаживать - сплошная мука. Но в моём случае можно просто забить: ну упал парсер, ну запустится ещё раз через полчаса и дособерёт пропущенное. А на случай изменений на сайте, которые совсем ломают процесс, имеются дополнительные механизмы контроля, сообщающие человеку, то есть мне, что там и правда есть проблема, требующая моего внимания.
  1. ahdenchik
    01.09.2025 13:31
    #28782840
    Rust решает эту проблему, он заставляет явно обработать ошибки программиста
    
    Checked exceptions уже были 30 лет назад. Rust предлагает те же грабли, но с другого ракурса?
    
    mayorovp
    01.09.2025 13:31
    #28783034
    В данном случае помогли бы не Checked exceptions, а borrow checker совместно с принципом "защищаемые примитивом синхронизации данные хранятся не рядом с ним, а внутри".
  1. Rive
    01.09.2025 13:31
    #28783914
    состояние гонки там можно получить только умышленно и надо очень постараться
    
    Легчайше.
    
    Берём DashMap на M элементов, берём любой его элемент N, затем начинаем в цикле сопоставлять выбранный элемент с текущим I. Как только элемент дойдёт до самого себя (I = N), мы получим гонку (мы пытаемся извлечь ресурс, но он уже занят). В других ЯП подобный перебор не создаст проблем, в Rust уже придётся подумать (например, проверять на тождество элементов по их индексу ещё до извлечения).
    
    Rust, конечно, очень удобен в некоторых моментах и подсвечивает многие места для рутинных проверок, но считать его целиком безопасным всё же не стоит.
    
    blind_oracle
    01.09.2025 13:31
    #28786938
    DashMap всё же внешний крейт, набитый unsafe-ами внутри.
    
    В стандартной библиотеке с этим, всё же, получше, но тоже бывают интересные приколы.
  1. blind_oracle
    01.09.2025 13:31
    #28784436
    2. Раст позволяет сделать .unwrap() и unsafe {} - от дурака никакая система не застрахована :)
  1. SimSonic
    01.09.2025 13:31
    #28786738
    Как защититься от программиста, который уверен, что оно здесь нужно?))
1. mayorovp
  01.09.2025 13:31
  #28782334
  Фиг с ней, с обработкой ошибок. Вернуть прибор в безопасное состояние после обработки ошибок в большинстве случаев довольно просто.
  
  Состояния гонок - вот истинный дамоклов меч.
  1. BlakeStone
    01.09.2025 13:31
    #28783280
    Вообще говоря, для подобных аппаратов следовало бы предусмотреть защиту от гонок – скажем, минимально допустимый интервал ручного набора параметров, при несоблюдении которого параметры не принимались бы и процедура не запускалась бы. Нечто подобное, кстати, существует как в сайтостроении (когда один из видов защиты от ботов – это блокировка незваных посетителей, просматривающих по десять страниц сайта в секунду), так и в протоколах безопасности некоторых стран: к примеру, если морское судно проходит ключевые пункты пограничной территории с чрезмерной скоростью, то ситуация автоматически квалифицируется как внештатная, со всеми вытекающими. Надо полагать, при работе с аппаратурой, способной даже теоретически нанести вред здоровью пациента (а как ясно из публикации – далеко не теоретически), такой вид контроля обязателен.
    
    Aelliari
    01.09.2025 13:31
    #28786084
    скажем, минимально допустимый интервал ручного набора параметров, при несоблюдении которого параметры не принимались
    
    О.о фига костыль, мне такое решение не нравится
    
    p07a1330
    01.09.2025 13:31
    #28790002
    Не костыль, а вполне распространенный в условном вебе lodash.debounce
    Сейчас работаю над проектом, где если спамить кнопку взаимодействия с сервером (условный лайк к сообщению) - он будет отправляться только когда от кнопки отстали, через пару сотен миллисекунд. При этом в UI кажется, что кнопка реагирует мгновенно
    
    mayorovp
    01.09.2025 13:31
    #28790012
    Всё-таки debounce в вебе работает не так - пользователь может менять что угодно, просто последствия будут отложены пока он вносит изменения. А выше предлагался куда более радикальный костыль, запрещающий пользователю взаимодействовать с UI в принципе.
    
    apevzner
    01.09.2025 13:31
    #28787976
    Скорее, у нее должен быть режим редактирования параметров, когда она ничего не делает, а только параметры редактирует, потом она должна переходить в режим проверки параметров, откуда выход либо назад в редактирование, при ошибке, либо в режим подготовки оборудования, когда ничего изменить уже нельзя, а можно только прервать процедуру и обресетить, потом финальный вопрос "ОК?", и потом уже включается режим финальной проверки, и потом режим прожарки, который можно только прервать.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790060
    Для удобства можно ещё в процессе редактирования проводить проверку во время пауз. Ну вот как на сайтах работает подсказка при наборе: пользователь может набирать с любой скоростью, но если возникает пауза, на сайт отправляется запрос, и результат отображается в выпадающем списке. А здесь - именно что уточнение параметров, блокировка недоступных режимов и тому подобное. Но да, основа - настройка отдель, работа аппаратуры отдельно, а между ними - обязательная валидация настроек. И в самой работе оборудования - отдельная фаза в виде приведения оборудования к заданному настройками начальному состоянию.
    
    apevzner
    01.09.2025 13:31
    #28790120
    отдельная фаза в виде приведения оборудования к заданному настройками начальному состоянию.
    
    И отдельная валидация того, что всё оборудование находится в правильном состоянии, и это состояние соответствует введённым параметрам.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790300
    Дыа! Я как-то писал код для торгового автомата (цветы продавал и сами цветы вставлены в ячейки на двух соосно вращающихся столов), но даже там угол проверялся несколькими способами. Мне сильно удивительно, что кто-то додумался не сделать проверки в несколько слоёв на оборудовании, которое оказывает высокоэнергетическое воздействие на организм человека. Причём, с целью вылечить этот организм.
    
    apevzner
    01.09.2025 13:31
    #28790360
    Ну так то цветы. Они денех стоят...
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790420
    А тут дорогущий аппарат, который тоже денег стоит. И пациенты, которые деньги за лечение платят. Чаще всего не напрямую, а через страховые компании, но покупатели аппаратов эти деньги получают и платят за аппараты. А тут, выходит, продали забагованную хрень, работа которой зависит от того, насколько хорошо спал оператор. Не в том смысле, что засыпает на рабочем месте, а в том, насколько бодро он по клавишам щёлкает. И никакого контроля за текущим состоянием оборудования и никакой внутренней синхронизации.
    
    MountainGoat
    01.09.2025 13:31
    #28789684
    Это не так просто сделать, когда есть десяток параметров и каждый может быть в пределах рабочих значений, а в сумме на выходе - полярный лис.
1. iiwabor
  01.09.2025 13:31
  #28782402
  Там была проверяющая система, но она, как потом выяснилось, тоже работала некорректно.
  
  А Fault Tree Analysis (анализ дерева отказов) решили не проводить, так как программное обеспечение «зарекомендовало себя как безопасное во время работы на Therac-6 и Therac-20». То, что Therac-25 значительно отличается от предыдущих поколений медицинских ускорителей, решили опустить. Компания-разработчик оценила шанс неправильной работы как почти несуществующий, а возможные ошибки в ПО проигнорировала.
  
  Все ошибки достались Therac-25 от Therac-20 и, вероятно, даже от Therac-6 (в котором рентгеновского режима не было вовсе). На старых системах баги никак не проявляли себя из-за аппаратных решений обеспечения безопасности.
1. nivorbud
  01.09.2025 13:31
  #28784276
  Неужели было трудно поставить датчик измерения на выходе, который моментально отключал бы оборудование, если оно выдаёт количество излучения, которое, очевидно, будет представлять угрозу для пациента?
  
  Невозможно программно учесть всё. Здесь нужна радикальная аппаратная защита, которая вроде и была в предыдущих версиях этого девайса.
  1. mayorovp
    01.09.2025 13:31
    #28784372
    Возможно, но нужна нормальная архитектура, в которой источником информации о текущем состоянии оборудования не является интерфейс пользователя.
    
    nivorbud
    01.09.2025 13:31
    #28784430
    Возможно
    
    Невозможно. Архитектура базируется на куче движков и библиотек, вы не можете гарантировать отсутствие ошибок в стороннем ПО. Даже в микропроцессоре отсутствие вычислительных ошибок невозможно гарантировать.
    
    А аппаратная защита, в отличие от софтовой, может быть простой и надежной.
    
    mayorovp
    01.09.2025 13:31
    #28784518
    Конкретно в данном случае аппаратную защиту без датчика угла поворота диска не сделать. А при наличии такого датчика и софт бы успешно справился.
    
    nivorbud
    01.09.2025 13:31
    #28784610
    Конкретно в данном случае аппаратную защиту без датчика угла поворота диска не сделать.
    
    В предыдущих версиях этого девайса, насколько помню, у диска тупо стояли физические ограничители, что делало невозможным поворот в опасное положение.
    
    А при наличии такого датчика и софт бы успешно справился.
    
    У двух упавших боингов были датчики угловой скорости, на основании показаний которых программно корректировалась неудачная конструкция планера (смещение центра тяжести из-за новых двигателей, насколько помню). Не помогло.
    
    mayorovp
    01.09.2025 13:31
    #28784726
    В предыдущих версиях этого девайса, насколько помню, у диска тупо стояли физические ограничители, что делало невозможным поворот в опасное положение.
    
    В данном случае опасность положения диска зависит от режима работы, так что обойтись механическими ограничителями не получится.
    
    У двух упавших боингов были датчики угловой скорости, на основании показаний которых программно корректировалась неудачная конструкция планера
    
    Представьте, что эта коррекция была сделана в железе. Ну и что бы от этого изменилось-то?
    
    ahdenchik
    01.09.2025 13:31
    #28784746
    В данном случае опасность положения диска зависит от режима работы, так что обойтись механическими ограничителями не получится.
    
    В те времена инженеры ещё умели в аналоговые компьютеры на операционниках
    
    mayorovp
    01.09.2025 13:31
    #28784792
    Да их и сейчас инженеры в универе изучают, но в чём их преимущество?
    
    В аналоговой схеме можно допустить ошибку точно так же как и в программе. Внутреннее устройство ОУ точно так же является чёрным ящиком с неизвестными багами как и сторонняя библиотека.
    
    apevzner
    01.09.2025 13:31
    #28789954
    Преимущество в том, что если есть две независимые системы защиты, основанные на разных принципах, то чтобы прожарить пациента насмерть, обе должны сломаться одновременно. Что существенно менее вероятно, чем поломка любой из них.
    
    А если еще каждое срабатывание системы защиты расследовать, как опасный инцидент, сигнализирующий о потенциальной проблеме в основной системе управления, то будет совсем хорошо...
    
    mayorovp
    01.09.2025 13:31
    #28789994
    Да, две независимые системы защиты помогают. Но это не является преимуществом аппаратной защиты над программной, две программные системы защиты от независимых команд разработчиков тоже будет работать.
    
    Ну и люди, экономящие на датчике угла поворота, никогда не станут делать вторую независимую защиту, так что основная проблема - именно в том, что доэкономились, а не в аппаратных защитах.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790212
    А ведь обычный конечный автомат решил бы проблему. Не идеально, конечно, но самые опасные состояния заблокировал бы наглухо и с надёжностью опущенного рубильника. Но да, о чём говорить с людьми, которые сэкономили даже на датчике угла, как бы он ни был реализован?
    
    mayorovp
    01.09.2025 13:31
    #28790910
    Там и конечного автомата не надо, простое логическое условие. И это условие даже было, только проверяемое им значение не было реальным.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790940
    А электромеханический конечный автомат проверял бы физическое положение деталей машины, то есть работал бы с реальностью напрямую.
    
    nivorbud
    01.09.2025 13:31
    #28785076
    Представьте, что эта коррекция была сделана в железе. Ну и что бы от этого изменилось-то?
    
    Изменилось бы всё - боинги бы не упали, так как, если бы корпус планера физически был бы спроектирован правильно, не было бы проблемы со смещенным центром тяжести и нечего было бы программно корректировать.
    
    mayorovp
    01.09.2025 13:31
    #28785124
    Вы как-то странно представляете себе работу аппаратной защиты.
    
    nivorbud
    01.09.2025 13:31
    #28785152
    Что странного? Сделать нормальную аппаратную конструкцию, чтобы ее нежелательное поведение не приходилось корректировать программными костылями? Это же очевидные вещи.
    
    mayorovp
    01.09.2025 13:31
    #28785184
    Странно что вы не видите разницы между конструкцией в целом, и аппаратной защитой.
    
    nivorbud
    01.09.2025 13:31
    #28785230
    Странно что вы не видите разницы между конструкцией в целом, и аппаратной защитой.
    
    Не надо подменять тезис. В основе обсуждаемых случаев лежат недостатки аппаратной конструкции, которые попытались исправить программным путем. Вот это решение (программные костыли вместо исправления недостатков конструкции) и является корнем проблемы, и именно это я обсуждаю.
    
    baldr
    01.09.2025 13:31
    #28785342
    Эти аппаратные недостатки были следствием компромиссов для решения других проблем - расположение и размер новых двигателей, высота стоек шасси и прочих. Просто так нельзя взять и передвинуть, например, крылья - это ещё больше проблем, а ещё и новых тестов и сертификатов.
    
    nivorbud
    01.09.2025 13:31
    #28785376
    Эти аппаратные недостатки были следствием компромиссов для решения других проблем - расположение и размер новых двигателей...
    
    Именно об этом я и говорю. Такие компромиссы, решаемые программными костылями, чреваты.
    
    Wesha
    01.09.2025 13:31
    #28788266
    А Вы когда-нибудь пробовали свалить По-2?
    
    MountainGoat
    01.09.2025 13:31
    #28789702
    Я пробовал свалить на По-2, но папа поймал за ухо.
    
    apevzner
    01.09.2025 13:31
    #28790464
    Там дело не в том, что Боинг не способен спроектировать планер.
    
    Но если бы они изменили планер, это был бы другой самолёт. С переучиванием пилотов, отдельным допуском и т.п. И авиакомпании подумали бы, стоит ли им его покупать: геморрою много, а ощутимой пользы не так уж и много.
    
    Поэтому Боинг сделал вид, что это не другой самолёт, а модернизация существующей модели. А в таком случае пилоты переучиваются по сильно сокращённой программе, и всем хорошо.
    
    Ну, кроме тех, кто пострадал в катастрофе.
    
    Собственно, это история не про технику, а про бюрократию и коррупцию.
    
    apevzner
    01.09.2025 13:31
    #28785368
    Архитектура базируется на куче движков и библиотек
    
    В программе для PDP-11, которая использовалась в данном случае? Там 64К (килобайта) памяти на всю машину, куда там засовывать движки и библиотеки?
    
    nivorbud
    01.09.2025 13:31
    #28785410
    куда там засовывать движки и библиотеки?
    
    В ардуино с 1КБ ОЗУ прекрасно используются библиотеки. Но не суть. Суть в том, что нельзя гарантировать отсутствие программных ошибок. Даже в микропроцессорах встречаются таковые. Помню, в i386 обсуждали арифметическую ошибку. Поэтому по любому лучше использовать адекватные аппаратные решения, делающих такие опасные ситуации принципиально невозможными. Например, использовать маломощный источник излучения, который даже работая на полную мощь не сможет причинить сильный вред.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790442
    Ну вот тут это принципиально невозможно. Это как пытаться делая цепную пилу для заготовки дров, поставить на неё настолько слабый мотор, чтобы ею нельзя было палец отпилить. Сам смысл аппарата состоит в высокоэнергетическом воздействии на организм. Точечном и строго дозированном воздействии. Но высокоэнергетическом. Несли нельзя причинить вред, то и работать не будет.
1. Tomasina
  01.09.2025 13:31
  #28785316
  это удорожает агрегат. Ведь в стоимость входит не только сам датчик, но и доработка ПО, тестирование ПО, и сертификация этого датчика.
  1. AndreyHenneberg
    01.09.2025 13:31
    #28790454
    Ну да, жизнь пациента бесплатна, а за дополнительные контакты и часы работы программиста и инженеров-электронщиков надо платить.

uranik
01.09.2025 13:31
#28782152
Могли бы кнопку "submit" на форму добавить и отправлять все значения оптом на сервер.
1. kipar
  01.09.2025 13:31
  #28782278
  Сервера там не было, один микрокомпьютер и программа на ассемблере. А ошибок там нашли кучу (https://ru.wikipedia.org/wiki/Therac-25#Замеченные_ошибки). Самая главная, на мой взгляд - то что убрали аппаратные цепи безопасности которые были на Therac-20.
  1. tormozedison
    01.09.2025 13:31
    #28783212
    Но был принтер, на чертеже показан.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790536
    А как принтер спасает от неправильной конфигурации оборудования? Принтер - это устройство вывода. Логи писать - да. О том, как пациент обугливается из-за неправильной конфигурации.
    
    tormozedison
    01.09.2025 13:31
    #28790630
    А, прочитал по диагонали, подумал, сервер в контексте места хранения данных для «разбора полётов». Потом прочитал первое сообщение, понял, что речь вообще о другом. Кнопку «принять во внимание все изменения в форме» могли бы сделать и без отдельного сервера.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790752
    Всё ещё не понял, при чём тут принтер. В остальном - да, достаточно было бы сначала закончить редактирование настроек, а потом уже валидировать новый набор настроек и состояние оборудования и только после этого выводить инструменты в рабочее положение и начинать облучение.
    
    Собственно, простой набор контактов в стиле "музыкальной шкатулки" мог бы блокировать запуск излучения пока работает мотор, крутящий барабан и моторы, устанавливающие магниты в нужные положения, а так же, пока барабан не окажется выставлен в нужное положение. А так же блокировал бы подачу повышенной мощности на пушку, если не установлен сектор с мишенью. Это довольно тупой конечный автомат на реле или транзисторах - кому что больше нравится. Я такое за полчаса-час могу если не собрать, то хотя бы начертить. Разве что, с положением магнитов может быть проблема - там они, вероятно, не имеют постоянных положений, но тут я могу только предполагать. Но это тоже относительно легко решается.
    
    mayorovp
    01.09.2025 13:31
    #28790934
    Не нужен там конечный автомат, достаточно просто группы контактов, замыкаемых тем самым крутящимся диском.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790998
    Так это и есть часть конечного автомата. Причём, основная. Если усложнить, то можно сделать подачу питания на излучатель возможной только в нескольких разрешённых состояниях.
    
    mayorovp
    01.09.2025 13:31
    #28791114
    С чего бы? У конечного автомата состояние является его составной частью, поэтому "сделать конечный автомат" означает "добавить элемент памяти с логической обвязкой".
    
    Добавляя же контакты к существующему диску, вы не увеличиваете в системе количество элементов, обладающих состоянием.
    
    tormozedison
    01.09.2025 13:31
    #28791704
    На принтер можно было, помимо стандартной информации: кто лечил, кого лечили, во сколько, с какими параметрами, можно было бы выводить ещё последовательность действий: выдвигаю анод, включаю ускоритель на интенсивности такой-то, жду столько-то секунд, выключаю ускоритель, задвигаю анод. И вот в этой последовательности «выдвигаю анод» и «задвигаю анод» не оказалось, хотя интенсивность была включена такая, которая соответствует выдвинутому аноду. Уже после первого же случая засуетились бы бодрее, может, и поняли бы, как исправить. А если бы ещё и значения всех системных переменных печатались... Или даже так: какие клавиши нажимались, и какие переменные менялись после каждого нажатия.
    
    AndreyHenneberg
    01.09.2025 13:31
    #28791722
    Ну... Если есть лишние пациенты, которых можно потратить на отладку и поиск бага, тогда да. Но только если предусмотрен такой механизм логивания. Так-то можно было бы и обычным способом сливать данные на диск, а там, видимо, и на основной компьютер больницы. Но пациенты - не расходники доктора Гнуса, так что ой.
    
    tormozedison
    01.09.2025 13:31
    #28791810
    О лишних пациентах, понятно, не может быть и речи. После первого случая прекращать эксплуатацию всех выпущенных установок данного типа до выяснения и исправления, только так. Пока не исправлено - только испытания на манекенах. Я о том, что если бы печатался каждый чих, а не только выборочные данные, последующих несчастных случаев могло бы и не произойти, потому что причину поняли бы тут же.
    
    А чтобы не произошёл и первый - вот так. Механизм в стиле музыкальной шкатулки там избыточен, нужен всего один микропереключатель, на который анод, выдвигаясь, нажимает, разрешая включать повышенную интенсивность.
    
    Ещё в плёночных аппаратах для флюорографии была ионизационная камера, через которую заряжался конденсатор, при достижении определённого напряжения на нём труба вырубалась. Здесь могли сделать две камеры с фильтрами, чтобы одна реагировала на сумму беты и рентгена, вторая только на рентген. В дополнение к микропереключателю. И ситуацию «рентгена нет вообще, беты слишком много» считать нештатной и мгновенно отрубать общее питание всей установки.
    
    Сливать на диск - не факт, что он там был. Запросто могла быть программа управления в ПЗУ, статистика только на принтер и больше никуда.
  1. ahdenchik
    01.09.2025 13:31
    #28783306
    микрокомпьютер
    
    Миникомпьютер, DEC PDP

baldr
01.09.2025 13:31
#28782296

Я работаю в IT и это причина, по которой в моём доме:
- механические замки
- механические окна
- роутеры на OpenWrt
- никакого дерьма вроде умного дома
- никакой Алексы, никакого Гугл-Ассистента
- никакого регулирования температуры через интернет

Самая технологичная вещь в моём доме - это принтер из 2004 и я всегда держу рядом заряженный пистолет на случай, если он издаст какой-нибудь непонятный звук.

Старый анекдот
1. Javian
  01.09.2025 13:31
  #28782816
  
  Брудль надолго запомнил этот день. С тех пор он поклялся никогда не запускать программу, которая не была бы совершенна с самого начала. А для того, чтобы не забывать о своей клятве, на его рабочем столе было изображение галактики, самые яркие звезды которой были сгруппированы в надпись
  
  ТВОЙ БЫДЛОКОД НАС ОГОРЧАЕТ
  
  https://habr.com/ru/articles/409979/comments/#comment\_18559241

iiwabor
01.09.2025 13:31
#28782378
С этой машиной была куча проблем:
- race condition. В случае с Therac-25 использовалась одна и та же переменная для двух команд, которые могли выполняться в произвольном порядке, что для описываемого аппарата неприемлемо.
К примеру, в одном из режимов при максимальной интенсивности излучения между пациентом и электронной пушкой должен был устанавливаться «рассеиватель», распределяющий поток. Машина же выполняла не ту последовательность, рассеиватель не устанавливался, и на человека обрушивался мощнейшее облучение. Проверяющая система, в свою очередь, из-за неверной команды (которая, опять же, не проверялась дублирующими системами) неправильно оценивала уровень радиации и «стреляла» вновь.
- некорректные операции с нулем приводили к выводу мощности излучения на максимум, а неверно описанная переменная генерировала неправильное положение поворотного диска с набором инструментов (для разных режимов работы и настройки) 1 раз из 256, что могло привести к многократно завышенному уровню облучения.
- Свою роль играла работа магнитов, которые позиционировали поворотный диск с «прицелами» для разных видов терапии. Если оператор вносил корректировку в мощность и тип излучения слишком быстро, машина не успевала перевести диск. Тогда шансы получить высокую дозу составляли 50 на 50.
  
  Если принять во внимание все возможные ошибки, то окажется, что Therac-25 представлял собой чуть ли не русскую рулетку с радиацией вместо пуль.
Судя по всему программист, который писал код, понятия не имел как работают механизмы машины.

А главная проблема была как всегда - деньги и время на разработку нового оборудования!

Чтобы оптимизировать разработку, создатели Therac-25 использовали старый код — написанный для предыдущих «тераков». Тот, в свою очередь, по данным ряда источников, был написан программистом-самоучкой, который не имел профильного образования.
1. apevzner
  01.09.2025 13:31
  #28785224
  Тот, в свою очередь, по данным ряда источников, был написан программистом-самоучкой, который не имел профильного образования.
  
  Можно подумать, если бы у него был сертификат соответствия чему-нибудь полезному, это предотвратило бы подобные ошибки.
  
  Все программисты ошибаются. Этот, судя по тому, что в принципе потянул проект, не самый худший. Проблема в самонадеянности. Даже в стиральной машине есть механический предохранитель, не дающий открыть дверцу во время стирки. А здесь не было.
  1. AndreyHenneberg
    01.09.2025 13:31
    #28790606
    А в самой тупой микроволновке открывание дверцы обесточивает магнетрон. Видимо, там процессом разработки руководил не инженер, который может представить работу аппарата в целом, даже не сильно разбираясь в отдельных деталях, а какой-то среднепаршивый бюрократ, умеющий писать отчётность, но не более того. И он даже не додумался свести разработчиков железа и программиста.

astenix
01.09.2025 13:31
#28782890
Лечишься, лечишься… а потом Therac-25!
1. tin04ka
  01.09.2025 13:31
  #28785068
  Therac, therac, и в продакшн!

grigr
01.09.2025 13:31
#28783164
У меня вопрос возник. А нафига у этого механизма вообще была физическая возможность стрелять такими убийственными пучками радиации? Почему не сделать физически так, чтобы максимальная доза соответствовала лечению или немного больше??

Это если бы обычные канцелярские степлеры могли выпускать скрепки со сверхзвуковой скоростью, но там стояли специальные ограничители и замедлители, которые иногда бы не срабатывали. И обычные скрепки иногда бы пробивали насквозь людей, стены и улетали бы на другой конец города разрушая все на своём пути. Главное что всего лишь иногда...
1. tormozedison
  01.09.2025 13:31
  #28783206
  Оно решили зачем-то сделать рентгеновскую трубку, работающую без вакуума. В нужный момент выезжал анод, на который направлялся поток электронов такой энергии, чтобы и без вакуума через воздух пролетело. А из-за ошибки анод не выехал, а параметры потока выставились такие, как будто он есть. Могли действительно ускоритель сделать рассчитанным только на режимы, при которых воздействие электронов идёт на пациента непосредственно. И чтобы превысить было невозможно физически. А когда требовалось воздействовать не бетой, а рентгеном - подводить отдельную рентгеновскую трубку, никак с ускорителем не связанную. Интересно другое, у них телекамера не работала. Это потому что тогда применялись передающие трубки с ресурсом всего в 500 часов. Менять приходилось так часто, ещё и залезая на стремянку, плюс каждый раз выполняя юстировку, что однажды на это «забили». А если бы камера работала, там этот выдвижной анод в кадр попадал? Было бы видно, что он не выдвинулся?
  1. grigr
    01.09.2025 13:31
    #28783220
    получается могли сделать именно безопасно. причем даже без костылей в виде замков. но вместо этого песня: в нашем по нет ошибки, а потом давайте замотаем изолентой...
    
    Javian
    01.09.2025 13:31
    #28784318
    Далеко ходить не надо - пример на Хабре как Яндекс колонки уложили ntp сервера в RU.
    
    https://habr.com/ru/companies/yandex/articles/861538/
    
    Wesha
    01.09.2025 13:31
    #28788284
    Да ладно,
    
    apevzner
    01.09.2025 13:31
    #28790092
    Они еще и движение в Москве пытаются уложить своим навигатором (думаю, не только в Москве. Но тут я своими глазами это вижу).
    
    В Москве полно многополосных дорог, у которых время от времени возникает дублёр протяжённостью несколько километров, а потом он назад вливается в основной поток. В принципе, назначение этих дублёров - заранее убрать с основной дороги машины, которые собираются поворачивать, чтобы избежать заторов из-за накопления машин в поворотном ряду. При большом трафике такие заторы имеют тенденцию разрастаться на полдороги, мешая и тем машинам, которые не собираются поворачивать.
    
    Так вот, навигатор Яндекса в часы повышенной нагрузки имеет тенденцию направлять даже прямо едущуе машины с основной дороги на такой дублёр, в объезд пробки на основной дороге. Проблема только в том, что пробка этими объезжающими и создаётся, в месте, где дублёр назад вливается в основную дорогу. И потом от этого места вдоль основной дороги и растекается.
1. apevzner
  01.09.2025 13:31
  #28785250
  Потому, что он двухрежимный. Можно срелять слабым пучком электронов прямо по человеку. А можно стрелять сильным пучком по железке, чтобы вышибить из неё рентгеновское излучение (в этом режиме электроны не долетают до человека). А вот если пучок настроить, как для рентгена, а железку не подсунуть, то будет того-сь.
  1. grigr
    01.09.2025 13:31
    #28785496
    Получается они делают штуку которая может убить человека, потому что он гарантировано на линии выстрела пучка электронов.
    
    При этом они отключают все механические защиты. Отказываются от варианта двух пушек: слабая и мощная где металлический элемент намертво припаян. А переключение режимов иногда глючит. И все зависит от софта написанного одним человеком вообще без тестирования.
    
    А когда были летальные случаи, просто отмазки лепили. У нас все идеально это радиацию через форточку надуло.
    
    Что же может пойти не так у этих сказочных д.. обов
    
    apevzner
    01.09.2025 13:31
    #28790104
    Надо понимать, что вся вообще опасная техника - все эти облучаторы, самолёты, корабли, лифты, эскалаторы, автомобили вот так вот примерно и делаются. И только после того, как убьют некоторое количество человек, производители под давлением властей начинают немножко суетиться...
    
    grigr
    01.09.2025 13:31
    #28790730
    ну как бы да. есть априори опасные приборы и машины - где техника безопасности нужна изначально. иначе сам изобретательно не доживет до релиза.
    
    но всеже, если бы электрочайники или микроволновки к примеру в особых случаях иногда нагревали бы всю кухню на 1000гр за 3 сек. то врядли бы мы пользовались такой херней у себя дома...
    
    думаю сверх избыточная мощность в приборах - это перебор. особенно там где тупо поленились ее ограничить, причем зная о большом риске.
    
    пс
    
    согласен. часто инструкции и техники безопасности пишутся кровью (((
    
    apevzner
    01.09.2025 13:31
    #28790748
    Там не поленились ограничить. Максимальная мощность рассчитана на то, что пучок электронов направят на железку, из которой он выбьет поток рентгеновских лучей, а не прямо на человека.
    
    В принципе, вполне осмысленное техническое решение. Но сочетание, когда пучок электронов рассчитан на рентгеновский режим, а железка не выехала, должно было бы быть запрещенным, с отдельным дополнительным контролем.
    
    grigr
    01.09.2025 13:31
    #28790764
    уже писал повыше:
    там должно было быть либо две пушки 1) слабая, 2) мощная где железка намертво припаяна.
    либо же механические замки, которые зачем-то сняли... и понадеялись на авось.
    
    apevzner
    01.09.2025 13:31
    #28790776
    Ну две пушки, вероятно, заметно дороже/хлопотнее в обслуживании, чем одна.
    
    А замки да, сняли.
    
    grigr
    01.09.2025 13:31
    #28790796
    вероятно да... еще и премию менеджерам дали за оптимизацию... как всегда
    
    AndreyHenneberg
    01.09.2025 13:31
    #28790848
    С двумя пушками ещё и ситуация "странная": по сути, это два экземпляра одного оборудования. Это как второй двигатель ставить на автомобиль, чтобы он ехал на другой передаче.
    
    А вот "замок"... Пока читал комментарии, у меня в голове уже нарисовались прикидки конечного автомата, который бы просто физически не позволил бы подать питание на излучатель до завершения процесса настройки инструментов. А повышенное - пока не будет установлена мишень. Причём, всё это на реле, если уж нужна совсем дубовая надёжность и плевать на то, сколько места всё это займёт.
    
    grigr
    01.09.2025 13:31
    #28790868
    вот вот... а тамошние менеджеры решили, что софт надежен, все работало и так, тесты нафиг, срежем за инженерам, поднимем премию себе. что может пойти не так... хотя учитывая постоянные глюки и сбои. что угодно могло не так пойти

tormozedison
01.09.2025 13:31
#28783184
У Philips был то ли монитор, то ли телевизор, где у CCFL при износе возрастало напряжение возникновения разряда, в какой-то момент он переставал возникать вообще, напряжение на вторичной обмотке трансформатора без нагрузки оказывалось слишком большим, возникали пробои, и всё очень красиво сдыхало. Когда о проблеме стало известно, прошивку чуть подкорректировали. Она подсчитывало, при скольких попытках включить подсветку разряд не возник, и если оно превышало 5, во флеш записывалось: «больше включаться не будем». Предполагалось, что CCFL заменят на новые, а затем сбросят ошибку с пульта. Но инструкцию по сбросу кто-то выложил, и пользователи начали делать это сами. Ничего не меняя, просто нажимая кнопки. До следующих пяти безуспешных попыток, а там опять сбрасывать. Чаще обходясь без последствий, но иногда - добивая трансформаторы... А могли решить не только программно, но и дополнительно аппаратно, поставив параллельно CCFL какой-нибудь компонент, пробивающийся при чуть большем напряжении.

technoParrot
01.09.2025 13:31
#28783412
У Амперки кстати, был ролик про эту историю

https://youtu.be/d3ENbjUTv0I

Aggle
01.09.2025 13:31
#28788440
Отличный и очень подробный разбор ситуации (пожалуй, наиболее полный материал из всех мной прочитанных ранее).

Но пожалуйста, не доверяйте переводить электронному болвану. Перевод комментария ужасен.

one-eyed-j
01.09.2025 13:31
#28792854
пока она проверяла правильность ввода даты

<pedant> Переводчика надо контролировать - тут скорей всего не "даты", а "данных". </pedant>