Лет пять назад встретил мнение о том, какими будут в будущем автоматизированные системы и звучало оно где-то так:
В будущем на автоматизированном заводе не должно быть кроме роботов никого, только один человек и собака. Зачем человек? Чтобы кормить собаку. Зачем собака? Чтобы смотрела за тем, чтобы человек ничего не трогал.
Сейчас обнаружил более оригинальное высказывание (в книге Fatal Defect, 1995), которое походу имеет также корни ещё на лет 10-15 глубже. Итак, шутка, которая ходит среди инженеров-разработчиков автоматизированных систем авионики:
Future automated airplanes will have only a pilot and a dog in the cockpit. The pilot will be included to reassure the passengers while the computers fly the plane. The dog is there to bite the pilot in case he or she touches anything.
Автоматизированные авиалайнеры будущего будут иметь только одного пилота и собаку. Пилот во время полета будет убеждать пассажиров что все хорошо, а собака будет кусать пилота, если он попытается дотронуться до приборов.
Здесь выражается одна из идей автоматизации, что когда процессы становятся все более отлаженными и автоматическими, то это приводит к тому, что от человека ничего не зависит, и вообще он становится не нужным и даже вредным.
В автоматизированных системах такой процесс имеет место, и выражается он в том, что обслуживающий персонал зачастую совершенно не понимает того, что происходит с системой если идет что-то не так. Кроме того, аналогичное явление идет для случаев, когда постепенно назревают проблемы и это происходит незаметно. А в случае аварий ищут разработчиков для выяснения причин.
Приведенная цитата из книги принадлежит Nancy Leveson, она не является её автором, но от себя продолжает её так:
The pilot will also be there so that there's someone to blame in case of an accident.
Пилот также будет тем, кого можно будет обвинить в случае какого-либо происшествия.
Зачастую в случае различных происшествий называется человеческий фактор, формулируясь под видом «чего-то недосмотрели», «чего-то не учли», «не услышали сигнала» и пр.. Пара примеров.
Первый. Более подробное рассмотрение происшествия, описанного ранее. Во время снижения A320 получилось так, что пилоты задали слишком быстрое снижение и из-за этого врезались в гору. Однако за всем этим стоит нечто большее. В авионике за 20 лет до происшествия сделали обязательное правило для установки подсистемы, которая оповещает пилотов об опасности слишком низкой высоты полета. Эти подсистемы автоматически посылают звуковые сигналы с громкостью и частотой в зависимости от высоты полета. Однако в рассматриваемом деле на возможность исправить ситуацию с помощью их сыграло дополнительно два фактора. Во-первых, исторически получилось так, что зачастую реализация данных устройств оповещения была такой, что система до неприличия часто давала ложные срабатывания и поэтому пилоты привыкали к данным звукам и не обращали на них особого внимания. Со временем система улучшалась, но сотрудники авиакомпаний по-прежнему считали, что оповещения часто подвержены ошибкам. Во-вторых, для внутренних авиалиний Франции администрацией было принято решение, что раз это внутренние, то пилоты хорошо знают местность и для них такую систему можно просто не устанавливать. Таким образом получается, что на факт катастрофы повлияло как инженерное решение (слишком часто ложные срабатывания), так и административное (отсутствие оценки реальной опасности). Но в протоколах записано, что виноваты пилоты.
Второй. Нам на лекции как-то Анатолий Коврига рассказывал об одной из схем управления ж.д. стрелками. Со временем эксплуатации выяснился один дефект, который мог приводить (и привел) к опасному отказу (переводу стрелки в случае занятой секции, т.е. потенциально под поездом). Фактически это был инженерный просчет. После происшествия (аварии) схема была пересмотрена и в неё добавлен ещё один элемент — конденсатор, который был призван исключить возможность опасного отказа. Но особенность была в том, что конденсатор в этой схеме был с такими параметрами, что требовал очень аккуратного и регулярного обслуживания. В корпусе проблема была решена, но в реальности получалось так, что если происходит что-то страшное, то оказывался виноватым не разработчик, и не начальник станции, а электромеханик, который обслуживал данную схему и якобы забыл обслужить конденсатор.
В книге Computer Related Risks есть много примеров, когда эксплуатирующаяся система слишком часто давала ложные сигналы об опасности, а из-за этого ей переставали доверять. Впоследствии когда наступал настоящий отказ, то переход на ручное управление или его игнорирование приводило к катастрофе.
Для решения есть ряд путей:
- Обучение обслуживающего персонала — лучшее понимание как работает система у тех, кто с ней работает.
- Создание более дружественного интерфейса и общая минимизация трудностей общения людей и системы — более человеческий интерфейс, разработчики должны писать код для людей (с обратной связью) а не чтобы просто написать и сдать.
- Создание системы принятия решений — для чрезвычайных ситуаций создание БД того, что если что-то произошло, то надо делать так-то.
- Отработка чрезвычайных ситуаций на симуляторе/имитаторе — например в авионике пилотов тренируют на разных сиутациях (отказали закрылки, ушли в штопор, внезапная потеря высоты) и потом они это уже делают более интуиутивно.
- Разработка более корректной и надежной системы как таковой.
Nancy Leveson часто и давно говорит о том, что катастрофа является результатом стечения ряда факторов, и обвинять только один из них является классической ошибкой. В случае с человеческим фактором почему-то получается так, что его очень удобно обвинить во всем.
