"Валерий Аджиев "Мифы о безопасном ПО: уроки знаменитых катастроф" [V]" - читать интересную книгу автора

надлежащую позицию (а он это может сделать в любой момент, так как уверен,
что система позволит коллиматору начать позиционироваться, только если все
параметры заданы и верифицированы), то основываясь на случайно возникшем
нулевом значении Class3, подпрограмма Lmtchk уже не станет вызывать
Chkcol, а значит установить ненулевое значение F$mal будет некому. Иными
словами, в ситуации, когда параметры не установлены должным образом (в
данном конкретном случае "челюсти" коллиматора были еще раскрыты слишком
широко), программная блокировка не сработала: Set Test Up установила
Tphase = 2, что позволило монитору Treat прекратить цикл вызова Set Up
Test, а инициализировать подпрограмму Set Up Done, по существу запускающую
процесс излучения, который и потек бурным потоком, а не узеньким ручейком,
как предполагалось.

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


Некоторые итоги

История с Therac-25 показательна, прежде всего, своей комплексностью:
если в случае с Ariane 5 авария случилась один раз и из-за единственной
ошибки, то катастрофические последствия с Therac-25 проявлялись
неоднократно в течение длительного времени, и были следствием целого
спектра причин, среди которых не только вполне конкретные программистские
"баги", но и дефекты в самой постановке выполнявшегося многие годы проекта.

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

Что же до системной "глобальной особенности", то к ней можно отнести
принципиальную переусложненность построения мультизадачной управляющей
системы. С чисто программистской точки зрения можно отметить, что для
реализации тонкой синхронизации параллельных процессов был выбран механизм
разделения переменных, требующий очень внимательной проработки (это именно
та область, где необходимо выполнять формальное доказательство
правильности алгоритма, благо соответствующие методы разработаны и могут
считаться рутинными для тех, кто ими владеет); получилось же так, что
потенциально опасные в плане возникновения "race conditions" операции типа
"set" и "test" не были сделаны "неделимыми" (indivisible), что и привело к
наложению друг на друга их "критических секций" и соответственно к