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


Вывод Гарлингтона вполне отвечает здравому смыслу: проблема носит
комплексный характер и обусловлена прежде всего объективной сложностью
систем типа Ariane. Соответственно, одним лекарством болезнь, приводящая к
появлению ошибок в ПО, вылечена быть не может. Хотя то, что процесс
мониторинга спецификаций, кода и документов с обоснованием проектных
решений при разработке ПО для Ariane 5, оказался неадекватен, отметила и
Комиссия по расследованию аварии. В частности, подчеркнуто, что к процессу
контроля не привлекались специалисты из организаций, независимых как от
заказчика, так и от подрядчика системы, что нарушило принцип разделения
исполнительных и контрольных функций.

Большие претензии были предъявлены не только к процессу тестирования
как таковому, но и к самой его стратегии. а этапе тестирования и отладки
системы было технически возможно в рамках интегрального моделирования
процесса полета исследовать все аспекты работы IRS, что позволило бы почти
гарантированно выявить ошибку, приведшую к аварии. Однако, вместо этого
при моделировании работы всего комплекса IRS рассматривалась как черный
ящик, заведомо выдающий то, что ожидается. Почему? А зачем тестировать то,
что успешно работало в течение многих лет?!

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

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

В данном же случае, возникла систематическая программная ошибка;
"систематическая" в том смысле, что при повторении тех же входных условий,
она обязательно возникнет вновь, ибо тавтология здесь уместна
запрограммирована. Вот почему подключение резервной авигационной Системы
ничего не дало: ведь ПО на нем исполнялось то же самое, соответственно и
обе IRS, и дублирующие друг друга Бортовые Компьютеры с неотвратимостью