Ошибки интерфейса: USS Vincennes и рейс IR655 Иранских авиалиний
Дисклеймер
Сейчас я ступлю на скользкую дорожку журналистики, которая всегда вносит искажения в реальную картину, оперируя лишь доступными вводными, которые сами по себе подвержены искажениям.
Вместе с тем, раскрытие известных трагических событий, в которых пользовательские интерфейсы сыграли определенную (и далеко не всегда определяющую) роль, является довольно значимым, на мой взгляд, способом донести важный, но игнорируемый факт — увлекаясь новыми технологиями, мы редко уделяем значимое внимание возможным последствиям, особенно неочевидным. Ну и, конечно, это может помочь предотвратить повторение ошибок прошлого — мы не всегда учимся на них.
Краткое описание события
3 июля 1988 года ракетный крейсер USS Vincennes, оборудованный боевой информационной управляющей системой (БИУС) Aegis, осуществлял дежурство в Ормузском проливе в условиях вооруженного конфликта между Ираном и Ираком. США в то время поддерживали Ирак, хотя и не находились в условиях войны с Ираном.
Поднятый с борта Vincennes вертолёт был обстрелян иранскими моторными лодками, что послужило поводом к их преследованию, в результате чего крейсер оказался в территориальных водах Ирана.
В это время из аэропорта Бендер-Абасса с опозданием на 27 минут взлетел пассажирский самолёт Airbus 300 Иранских авиалиний, рейс №IR655, с направлением в аэропорт Дубая. На борту находилось 274 пассажира и 16 членов экипажа. Транспондер с идентификацией самолёта был включен после взлёта и работал исправно.
Маршрут проходил над районом боевых действий между американским крейсером и иранскими лодками.
Экипаж USS VIncennes неверно идентифицировал пассажирский лайнер в качестве истребителя F-14, летящего прямо на него с целью атаки. Команда крейсера пыталась связаться с взлетающим самолётом 10 или 11 раз, но в итоге, когда расстояние между ними снизилось до примерно 11 морских миль, был отдан приказ на уничтожение самолёта с помощью двух зенитных ракет.
В результате попадания, спустя семь минут после взлёта самолёт был разрушен на части и упал в воды Персидского залива. Никто из находящихся на борту 290 человек не выжил.
Причины
Были проведены несколько расследований происшествия той или иной степени беспристрастности. В целом, выделяются следующие факторы, повлиявшие на развитие ситуации (номера приводятся для ссылок, а не отражают значимость):
- Вылет самолёта с опозданием, что затруднило его идентификацию.
- Из-за особенностей системы команда крейсера посчитала, что самолёт имеет военный код транспондера, соответствующий истребителям F-14, которые стояли на вооружении Ирана.
- Операторы системы посчитали, что самолёт снижает высоту, то есть заходит в атаку. Меж тем, Аэробус продолжал набирать высоту и БИУС Aegis записала эти сведения в своих логах.
- Высокое психоэмоциональное напряжение экипажа в условиях боевых действий, происходящих с ним в первый раз.
- Ошибка «исполнение сценария» — экипаж судна отрабатывал учебные ситуации при нападении одиночного вражеского самолёта, и стал проецировать этот сценарий на реальную ситуацию, игнорируя сигналы и информацию, противоречащую сценарию. Ситуации ошибочной интерпретации данных не отрабатывались при обучении.
- Отсутствие слаженного взаимодействия военных с гражданскими авиадиспетчерами для идентификации коммерческих самолётов.
- Авиадиспетчеры не были в курсе военной операции и не могли предупредить рейсы об опасных зонах полёта.
- Отсутствие оборудования для переговоров на гражданских частотах у военных. Экипаж USS Vincennes провел 7 или 8 вызовов на военных частотах (фиксируясь на допущении, что самолёт военный) и только три на аварийной частоте, прослушиваемой самолётом.
- Ошибки коммуникации — команда крейсера обращалась к лайнеру как к «неопознанному самолёту» и не называла номер транспондера. Экипаж Аэробуса считал себя опознанным, ибо транспондер работал исправно.
- Также команда обращалась к лайнеру, упоминая его путевую скорость (350 узлов), тогда как приборы самолёта показывали воздушную (приборную) скорость — 300 узлов.
- Аэропорт вылета использовался как для пассажирских, так и для военных самолётов.
- Незадолго до происшествия в воздушном пространстве находился иранский разведывательный самолёт P-3 и экипаж пассажирского лайнера, вероятно, подумал, что американские военные обращаются к нему.
Были и другие факторы, например, отмечаемый многими коллегами воинствующий характер капитана крейсера, что повлияло на ряд предвзятых суждений во время развития ситуации. Но я их опущу, при желании смотрите источники.
Роль пользовательского интерфейса
Для нашей специфики особо значимы пункты №2 и №3 – ошибочное присвоение военного кода транспондеру гражданского самолёта и игнорирование продолжающегося набора высоты.
Игнорирование набора высоты пассажирским лайнером
Начну с игнорирования набора высоты, это более простой кейс, плюс он полезен для последующего объяснения проблем с интерпретацией кода транспондера.
Информационный центр системы Aegis в то время представлял собой рабочие места перед тремя квадратными экранами 42 на 42 дюйма, отображающими карту с целями (на всякий случай отмечу, что цели – это не обязательно то, во что стреляют; это вообще любые объекты, идентифицированные радаром, как свои, так и чужие или нейтральные), и небольшие 12-дюймовые экраны для отображения подробной алфавитно-цифровой информации. Были и множество других мест, но это не так важно.
На тот момент система не отображала тенденций изменения параметров — растёт скорость или высота воздушной цели, либо остаётся постоянной, либо снижается. Для этого персоналу приходилось вручную записывать параметры в свои блокноты или планшеты и сравнивать с теми, что показывала система в настоящий момент.
К слову, один из инженеров, разрабатывающих систему, обратил внимание на отсутствие тенденций, на что получил ответ от начальства, что если бы военным это было нужно, они бы попросили, плюс для отображения не хватает места на экране [1].
Более того, эти ключевые параметры движения показывались не рядом с целью, а только при её выборе – на 12-дюймовом экране, который, как видно даже из фотографии, располагался довольно далеко от ситуационного дисплея по полю зрения. Иными словами, чтобы увидеть параметры, оператор должен был явно, волевым усилием направить взгляд на него. А потом еще и записать или сопоставить с предыдущим записанным.
Разумеется, в условиях стресса, нарастающей угрозы (фактор №4) и предвзятости подтверждения сценария (фактор №5), всё это можно легко забыть сделать, сфокусировав всецело внимание на экран с идущим на тебя «истребителем».
Неверная идентификация кода транспондера
С этой частью чуть сложнее, найти явные скриншоты не получилось, только пояснения из отчётов и исследований. Но по ним можно попробовать реконструировать интерфейс, как и по вышеприведенной фотографии.
При появлении на экране радара взлетающего самолёта он вначале определяется как неидентифицированный – ведь радарные волны просто отражаются от корпуса самолёта, не сообщая никакой информации о рейсе, модели и т.п.
Далее перед оператором стоит задача идентификации – что это за самолёт, является он военным или гражданским, куда направляется и так далее. Идентификация определяется по самым разным параметрам, включая данные от транспондера. К сожалению, судя по отчёту ICAO, данные от транспондера стали единственным источником информации.
Одним из первых действий для идентификации цели было ручное наведение на её положение курсора с помощью трекбола. Наведенная отметка курсора называлась tracking gate (или read-gate), и из указанного места система «слушала» все радиосигналы.
Проблема была в том, что эта отметка не двигалась вместе с целью, и оставалась в районе аэропорта, который, как было описано в факторе 10, также обслуживал военную авиацию. Сразу после взлёта экипаж рейса IR655 включил транспондер, и оператор получил код IFF Mode III, соответствующий гражданскому самолёту. Но по мере удаления лайнера, из отметки стал приходить сигнал от транспондера стоящего там истребителя F-14, выдававшего военный код IFF Mode II. То, что позиция Tracking gate и позиция самолёта не совпадают — не было замечено оператором, но при этом для всех других членов экипажа цель на радаре стала уверенно помеченной как F-14.
Не понятен масштаб карты на ситуационном дисплее, также мне не удалось определить, горела ли отметка Tracking Gate на экране дисплея или скрывалась сразу после указания, в источниках этот аспект не раскрывается. В случае сокрытия отметки ошибку было бы намного сложнее обнаружить, но учитывая факторы стресса и предвзятость исполнения сценария, даже наличие отметки могло не сыграть значимой роли.
Также, сравнивая расстояние между приближающимся самолётом и крейсером с расстоянием между самолётом и аэропортом (на котором осталась отметка), можно высказать предположение, что масштаб мог быть увеличен и отметка оказалась за пределами карты. Хотя это исключительно моя гипотеза.
Независимо от возможных реконструкций ситуационного дисплея, можно предположить, что фокусируясь на истребителе, оператор больше не обращал внимания на состояние и положение tracking gate, и вся команда фиксировалась на угрозе нападения.
Система же не давала никаких тревог о несогласованной связи между источником данных о цели и её положением, или о выходе цели за пределы tracking gate. Согласно источникам, эта проблема не была идентифицирована на этапе тестирований системы, больше внимания уделялось повышению качества радарных изображений.
Интерпретации
Эта часть уже субъективная. Первый вопрос, который возникает – насколько большую роль сыграл пользовательский интерфейс в развитии трагедии? Я бы разделил его на два вопроса, значимых с позиций проектирования подобных систем, да и любых других, критичных по последствиям ошибок.
Первый вопрос — служил ли интерфейс основной причиной происшествия? Можно сказать, что нет, он был лишь одной из многих причин в быстро развивающейся ситуации. Среди основных причин здесь был, в первую очередь, человеческий фактор.
Второй вопрос — но мог ли пользовательский интерфейс системы защитить от ошибок? Здесь можно быть более уверенным, что должное проектирование системы с активным уведомлением оператора о несогласованности информации, плюс явная визуализация данных о характере движения цели — всё это могло повлиять на уверенность оператора в выводах о типе самолёта.
Увы, история не знает сослагательных наклонений. Даже может возникнуть мысль — мол, всё это было давно и такие ошибки никто не делает. К сожалению, это не так.
Описанное выше происшествие и его причины выглядят в ретроспективе логичными и достаточно понятными (а были бы расшифровки событий по времени и скриншоты экранов — и вовсе очевидными). Но что, если попробовать спроецировать их на текущие разработки, где мы еще не имеем должного опыта их применения? Давайте попробуем.
Должен ли проектировщик интерфейса, когда к нему приходит задача, озаботиться тем, что имеющейся информации недостаточно для каких-то неизвестных в данный момент сценариев использования и попробовать идентифицировать эти сценарии и поднять обсуждение? Либо же можно просто выполнить задачу так, как она ему поставлена экспертами/аналитиками/заказчиками — сняв с себя ответственность, «я сделал то, что мне сказали»?
А если проектировщик считает, что, например, было бы полезно «на всякий случай» добавить тенденцию изменения скорости или направление поворота — поможет ли это в крайне редких ситуациях, или же повысит нагрузку на оператора в 100% случаев, а также добавит дополнительные проблемы в интерпретации? Как, например, должна выглядеть тенденция если истребитель взлетает, а потом начинает снижаться в атаку? По какому времени считать её?
Таких вопросов множество и возникают они постоянно, ведь в принципе многие кейсы ситуационной осведомленности сводятся к объему данных и уведомлений. Данных, обрушивающихся — либо еле -еле просачивающихся — на пользователя от различных сенсоров, анализаторов и прочих модулей сложной системы в сложных условиях реального времени.
Система выдаст слишком много — пользователь перестанет справляться, да и соотношение сигнал/шум вырастет и он перестанет обращать внимание, как дровосеки перестали слушать крики мальчика о волках. Выдаст слишком мало — оператор не заметит важного. Ну а если попробовать ввести еще один уровень защиты/фильтрации, в зависимости от распознаваемого системой контекста — обязательно и в нём будут пределы допустимости и какие-либо изъяны.
Что интересно, команда другого корабля, фрегата USS Sides, определила самолёт как гражданский, но поскольку у них не было такой современной системы, как Aegis, они посчитали, что экипаж Vincennes разбирается в ситуации лучше, чем они, и поняли свою ошибку только когда увидели падающие обломки авиалайнера. «Они выстрелили в COMAIR!!!» (то есть в коммерческий самолёт) — было донесение с борта этого судна.
«Титаник непотопляем», а «современные системы не могут ошибаться» — причина множества трагедий, завязанных на переоценивание возможностей технологических новинок.
Чему мы можем научиться?
Что же, попробую сжато перечислить некоторые способы, которые позволят быть готовым к подобным ошибкам, не ограничиваясь (как могло показаться из предыдущего блока) общим «балансируй между количеством и качеством данных».
Необходимо отрабатывать не только запланированные сценарии взаимодействия, но и ситуации заблуждений, ошибок и даже игнорирования — как случайного, так и преднамеренного.
Разумеется, стоит задаваться вопросами, достаточно ли эффективно данные предоставляются пользователю и нет ли в них лакун для оценки ситуации? Могут ли выдаваемые данные формировать ложные выводы или служить для их подтверждения?
Причём всё это не должны быть абстрактные вопросы, стоит создавать список негативных (ошибочных) сценариев и проверять систему на них. Для этого полезно проецировать известные инциденты и механизмы возникающих ошибок на свою предметную область. Это не так сложно, как кажется, хотя и, конечно, требует известных усилий и навыков систематизации и абстрагирования.
Еще эта трагедия наглядно показывает, что если интерпретация имеющейся информации зависит от явных действий пользователя (например, поглядеть в другое место, либо записать заранее и сравнить), то в случае стресса это может легко игнорироваться, восприятие становится намного более буквальным, «что вижу о том и пою». Выдавая какую-то краткую информацию о цели рядом с её отметкой, можно легко заставить пользователя верить, что это самая необходимая для него информация, а более подробные сведения (доступные, например, по клику) являются некритичными и необязательными.
Поэтому нужно выяснять, поддерживаются ли данные другими, дублирующими сведениями, а способы их представления и донесения до пользователя — продублированы другими способами (например, потенциально важная скрытая информация может отображаться «мягкой» визуальной тревогой, а через какое-то время игнорирования она может эскалироваться до более заметной, звуковой).
Ну и, конечно, не стоит внушать пользователям мнение, что система умнее, чем она есть на самом деле. Но это уже совсем немодная философия.
Источники
- Formal Investigation into the Circumstances Surrounding the Downing of Iran Air Flight 655 on 3 July 1988 by William M. Fogarty
- Luke Swartz. Overwhelmed by Technology: How did user interface failures on board the USS Vincennes lead to 290 dead? http://xenon.stanford.edu/~lswartz/vincennes.pdf
- Vincennes. A Case Study by Lieutenant Colonel David Evans, U.S. Marine Corps (Retired) https://web.archive.org/web/20060527221409/http://dolphin.upenn.edu/~nrotc/ns302/20note.html
- Airbus A300B2 EP-IBU, accident in the vicinity of Qeshm Island, Islamic Republic of Iran on 3 July 1988. Report released by ICAO. https://reports.aviation-safety.net/1988/19880703-0_A30B_EP-IBU.pdf
Почитать/посмотреть по теме
- Происшествию посвящена серия «Ошибка идентификации» сериала «Расследования авиакатастроф»
- Dirk Maclean. Shoot, don’t shoot: minimising risk of catastrophic error through high consequence decision-making. ISBN: 9781925062229