Авария в Мексиканском заливе: возможна ли программная ошибка?

Последствием катастрофы на буровой платформе Deepwater Horizon, принадлежащей компании BP и ее субподрядчику, компании Transocean, стала гибель 11 человек, уничтожение самой платформы и серьезное экологическое бедствие. Cейчас, после более чем трехмесячных отчаянных попыток, прорыв скважины на глубине свыше километра взят под контроль. Несмотря на то что виновных в этой катастрофе еще пытаются найти и ни американское правительство, ни пресса не знают точно, что стало причиной взрыва (а, возможно, мы никогда так этого и не узнаем), вполне вероятно, что одной из причин бедствия могла стать ошибка в программном обеспечении.

Причастно ли программное обеспечение?

У нас нет доступа ко всей информации о данном инциденте, однако во внутреннем отчете Transocean, переданном 8 июня 2010 года в комитет конгрессмена Генри Вахсмана в палате представителей Конгресса США, в разделе «Необходимые действия» говорится: «Полная проверка программного обеспечения системы управления. Программный код затребован у производителя для проведения расследования» [1]. По-видимому, при расследовании катастрофы у экспертов возникают вопросы о причастности программного обеспечения.

Кроме того, в статье, появившейся в Houston Chronicle от 19 июля 2010 года, утверждается, что "экраны дисплеев на основной рабочей станции (ее называли A-chair), использовавшейся для управления буровой установкой на Deepwater Horizon, перед инцидентом несколько раз 'зависали'". Стефен Бертон, главный инженер компании Transocean по платформе Deepwater Horizon, заявил: "По существу, экраны могли перестать обновляться, и все данные... оказались бы заблокированы". Он подчеркнул, однако, что жесткие диски были заменены, и ему неизвестно о каких-либо проблемах с оборудованием в день катастрофы [2].

Поговорим о том, как программная проблема могла бы привести к катастрофе с Deepwater Horizon.

Программы на буровых установках

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

Еще одна проблема состоит в том, что большая часть программных компонентов, как правило, доставляется уже после того, как оборудование на буровой платформе смонтировано. Инженеры тестируют интерфейсы в последнюю минуту – если вообще тестируют ПО. Таким образом, интерфейсы оборудования представляют собой слабое звено в системах морских буровых платформ в том, что касается надежности и безопасности, поскольку в отрасли нет стандартов на интерфейсы и приемлемых методов тестирования [3].

Некорректная реакция на программные предупреждения

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

В системе нефтяной буровой платформы наличие множества устройств в сочетании с неэффективным управлением предупреждениями и тестированием приводит к тому, что на экране рабочей станции буровой установки (см. таблицу) появляется большое количество программных предупреждений. В некоторых случаях каждые 10 минут может возникать до 50 предупреждений [4], что значительно выше уровня, рекомендованного отраслевыми стандартами [5-7].

К типичным проблемам, связанным с предупреждениями, относятся ошибки классификации, избыточность, проигнорированные предупреждения, неправильная расстановка приоритетов, надоедливые предупреждения и предупреждения, которые вообще затерялись. Недавно специалисты Athens Group подготовили отчет Failure Modes, Effects, and Criticality Analysis и пришли к выводу, что люди несвоевременно реагируют на критически важные предупреждения по двум причинам:

• предупреждения не классифицированы по приоритету;
• тысячи или даже десятки тысяч предупреждений появляются на экранах ежедневно.

Обычное для буровой установки количество потенциальных тревог просто поражает, например, в одном проекте ученые создали реестр всех предупреждений, полученных от оборудования буровой платформы, — окончательный список занял 90 страниц и содержал свыше 2700 разных предупреждений [8].

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

Случай 1: проигнорированное предупреждение

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

Оценка приоритета предупреждений и их объявления могут помочь не допустить игнорирование предупреждений.

Случай 2: затерявшееся предупреждение

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

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

Случай 3: ошибка калибровки

Во время производственной операции в модуле Floating Production, Storage and Offloading начало расти давление топлива в компрессоре. Это изменение автоматически зафиксировано не было, операционный персонал его не заметил, и смещение от нормы продолжало увеличиваться. Чуть позже вибрация компрессора изменила рисунок волны, свидетельствующий об изменениях в поведении. Вибрация была еще ниже уровня тревоги и осталась необнаруженной. Позже, во время аварийного рестарта, температура изолирующего газового пузыря значительно выросла, но это не привело к включению сигнала тревоги, поэтому никаких корректирующих действий предпринято не было. В результате на модуле сжатия газа возник пожар, что привело к остановке производства стоимостью 720 млн долл. В этой ситуации аудит предупреждений мог бы помочь предотвратить проблему, выявив возможные ошибки в путях передачи предупреждений и гарантировав, что при соответствующих обстоятельствах предупреждение будет выдано.

***

Есть большая вероятность, что бурильщик и операторы платформы Deepwater Horizon просто не видели сигналов тревоги, выданных в связи с возникновением проблем, которые в конечном итоге и привели к взрыву. К сожалению, мы не можем в деталях реконструировать программные события, приведшие к разливу нефти, поскольку на платформах нет "черных ящиков". Отдельные буровые платформы оборудованы "регистраторами полетов", но они записывают лишь некоторые сообщения из сети управления бурением. Сети подводной и энергетической систем и системы управления платформой полностью игнорируются, и их работа не протоколируется.

С другой стороны, проблема с тормозами на Toyota Prius в 2010 году была очень быстро списана на программную ошибку, хотя и бездоказательно: фактически, на сегодняшний день никакого программного дефекта не найдено, и сейчас в компании предполагают, что, скорее всего, здесь речь идет об ошибке водителя [10]. Пока никто не утверждает, что причиной разлива нефти стала проблема с программным обеспечением. К сожалению, нефтяная отрасль сейчас находится в таком же состоянии, как и промышленность США в 1970-е годы, — стандарты еще полностью не внедрены, нет универсальных стратегий снижения рисков или жесткого контроля безопасности.

Всем очевидна необходимость создания более качественных стандартов на интерфейсы и тестирование программного обеспечения для технологий добычи нефти с буровых платформ.

Литература

1. Deepwater Horizon Incident — Internal Investigation. draft report, Transocean, 8 June 2010, p. 15; http://energycommerce.house.gov/documents/20100614/Transocean.DWH.Internal.Investigation.Update.Interim.Report.June.8.2010.pdf.
2. B. Clanton, Drilling Rig Had Equipment Issues, Witnesses Say – Irregular Procedures also Noted at Hearing. Houston Chronicle, 19 July 2010; www.chron.com/disp/story.mpl/business/7115524.html.
3. Can You Afford the Risk? The Case for Collaboration on Risk Mitigation for High-Specification Offshore Assets, white paper, Athens Group, Feb. 2010.
4. Achieving Effective Alarm System Performance: Results of ASM Consortium Benchmarking against the EEMUA Guide for Alarm Systems, Abnormal Situation Management Consortium, Feb. 2005; www.applyhcs.com/publications/interface_design/EffectiveAlarmSystemPerformance_CCPS05.pdf.
5. EEMUA 191: Alarm Systems: A Guide to Design, Management and Procurement, Eng. Equipment and Materials Users' Assoc., 1999.
6. ISA 18.2: Management of Alarm Systems for the Process Industries, Int'l Soc. Automation, 2009.
7. NPD YA-711: Principles for Alarm System Design, Norwegian Petroleum Directorate, 2001.
8. Athens Group, How to Stop the Flood of Superfluous Alarms and Achieve Alarm Management Compliance, to appear in Proc. Int'l Assoc. Drilling Contractors World Drilling Conf., 2010.
9. D. Shafer, Would You Like Software with That? Where Do We Stand with Oil and Gas (O&G) Exploration and Production (E&P) Software? white paper, Athens Group, 2005; http://athensgroup.com/nptqhse-resources/articles-and-whitepapers.html.
10. J. Garthwaite, It Wasn't the Software: Toyota Finds Driver Error (Not Code) to Blame. Earth2tech.com, 14 July 2010; http://earth2tech.com/2010/07/14/toyota-finds-driver-error-not-software-to-blame-in-some-runaway-cars.

Дон Шафер (dshafer@athensgroup.com)  – директор Athens Group по безопасности и технологии; Филлип Лапланте (plaplante@psu.edu)  – профессор по программной инженерии Университета штата Пенсильвания.