1. Причетна програмне забезпечення?
2. Програми на бурових установках
3. Некоректна реакція на програмні попередження
4. література

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

Причетна програмне забезпечення?

У нас немає доступу до всієї інформації про даний інцидент, проте у внутрішньому звіті 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 Was not 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 .

Дон Шафер ( [email protected] ) - директор Athens Group з безпеки і технології; Філліп Лапланте ( [email protected] ) - професор з програмної інженерії Університету штату Пенсільванія.

Don Shafer, Phillip Laplante. The BP Oil Spill: Could Software be a Culprit? IEEE IT Pro September / October 2010, IEEE Computer Society, 2010. All rights reserved. Reprinted with permission.

Таблиця. Галузеві рекомендації «керованого» рівня попереджень (порівняння з рівнями, передбаченими в дослідженні Abnormal Situation Management Consortium)