Новый материал.
Уже более глобальный, чем просто рекомендации по полету на конкретном воздушном судне.
В нем описаны рекомендации операторам по разработке SOPs. Материал основан на соответствующем циркуляре FAA, датированным 2003-м годом, однако, внесено очень много своего.
Скачать по ссылке с Яндекс.Диска
Хотелось бы услышать критику. Материал разрабатывался довольно быстро.
Уже более глобальный, чем просто рекомендации по полету на конкретном воздушном судне.
В нем описаны рекомендации операторам по разработке SOPs. Материал основан на соответствующем циркуляре FAA, датированным 2003-м годом, однако, внесено очень много своего.
Скачать по ссылке с Яндекс.Диска
Хотелось бы услышать критику. Материал разрабатывался довольно быстро.
Перевод статьи " Мнение: автоматика и бюрократия убивают летные навыки" и публикация оного в одноименной статье в этом блоге заставил меня победить лень и обновить (в связи с вновь появившимися фактами) свой, пожалуй, самый любимый труд - "Сферический пилот в вакууме. О…
Comments
Я не знаю насколько может быть полезно мое замечание, но хочется отметить, что в тех случаях, когда процедура, принимаемая как "стандартная", подразумевает большую вариативность ее выполнения, разработчики обычно стараются раздробить ее на несколько максимально детализированных процедур - вплоть до разработки узко-специальных TOPs (Technical Operating Procedures). С моей точки зрения - это не совсем верный подход. Возможно более приемлемо изложение порядка действий в рамках иной формы стандартной документации, то есть Policy, которая жестко ограничивает рамки возможных действий, оставляя некоторую свободу для исполнителя внутри себя.
Заранее прошу прощения, если "не в кассу". Но в аналитической лаборатории - работает.
Собственно говоря, SOP - это обширное понятие, и политики тоже являются своеобразными SOP. Равно, как многие SOPs являются следствием из политик.
Поэтому и я применил словосочетание "своеобразными SOP". Конечно же, не мешая их с SOP, которые однозначно описывают механику действий для исполнения того или иного процесса.
Кое-где слетело форматирование.
Можно было бы добавить примеры неработающих процедур - и как их сделать работающими.
При выполнении стандартных процедур в кабине нет КВС и второго пилота - есть PF и PM. До сих пор многие КВС об этом забывают в силу сложившихся на советской технике привычек.
Попытка "помочь руками" в выполнении чужой процедуры со стороны любого члена экипажа должна пресекаться, особенно вмешательство в пилотирование без "I have control".
На мой взгляд SOP как руководство по выполнению полётных процедур должно быть свободно от расширенных комментариев мелким шрифтом, в которых указывается необходимость проверки состояния системы и т.п. Каждая такая проверка - это действие. Для обучения и исключения разночтений можно писать расширенный вариант SOP, в котором подробно объяснять каждый шаг. Это два отдельных документа как FCOM и FCTM.
Callouts: стандартные формулировки обычно имеются в FCOM, имхо лучше приводить примеры оттуда (таблица 3-1).
Немного по формулировкам:
Who is responsible for loading cargo, and securing cargo. Точнее было бы сказать Cargo loading. Crew responsibility :) Weight&Balance: preparation, responsibility, crew actions. И остальные по тому же принципу :) Cold temperature correction policy, Windshear conditions recognition and avoidance и т.п.
Было бы здорово оговорить отдельно формат доклада после возвращения члена экипажа в кабину.
Брифинг на заходе: отдельно оговорить briefing update при изменении диспетчерского разрешения (к примеру, заход на параллельную полосу).
Общее впечатление: круто!!! Особенно примеры с выдержками из SOP. Наглядно и чётко. Жду окончательный вариант! :)))
В левой колонке я брал за исходник шаблон из FAA AC, в правой - мой кривой перевод (торопился).
Цель данного проекта - не совсем требования конкретные по тому или иному случаю, сколько направить операторов на "путь истинный", указать, что следовало бы им описать. Так то, конечно, было бы здорово все проработать примерно так же детально, как стабилизированный заход.
Вообще, это работа по проекту Runway Safety в рамках целой ИКАО. В итоге должны родиться какие то рекомендации, а это - как бы побочная работа.
Переслал коллегам, если будут комментарии от них - обобщу и выложу в комментариях.
Искренне желаю удачи! :))
И тебе отдельное спасибо за то, что прочитал и выдаешь предложения!
И вообще - будут какие вопросы, требующие стороннего взгляда или разъяснения - не стесняйся.
При выполнении стандартных процедур в кабине нет КВС и второго пилота - есть PF и PM. До сих пор многие КВС об этом забывают в силу сложившихся на советской технике привычек.
==
Не так.
КВС есть всегда. Это лицо, назначенное на полет в качестве несущего ответственность за безопасный его исход. И как следствие, это лицо наделено авторитетом принимать решения, необходимые для обеспечения такой ответственности. Например, отступать от стандартных процедур.
ВП в качестве PF не имеет права принимать окончательные решения в той или иной ситуации, это всегда право КВС - будь он даже PM в этот момент.
Другое дело (из CRM) - умение КВС грамотно пользоваться своим авторитетом власти, не перегибать палку, уметь собрать все мнения и принять лучший план действий, даже если он родился не в его голове... но решение действовать по этому плану - все равно за КВС.
---
По формату - если ты имеешь в виду таблицу шаблона SOP (?) то я чесал репу, как лучше выделить начало каждого пункта. Маркированный список рябил глаза, поэтому придумал смещать вторую строку (если пункт более одной строки) правее.
Или что-то другое?
---
На мой взгляд SOP как руководство по выполнению полётных процедур должно быть свободно от расширенных комментариев мелким шрифтом, в которых указывается необходимость проверки состояния системы и т.п.
==
Вот с этим сложно согласиться. Очень неудобно разделять "действие" и "следствие/состояние" в разные книги/места. SOPs это всегда компромисс между желанием "высказаться" и объемом, однако, критические вещи желательно размещать перед глазами.
Например, многие пилоты летают на 737 по многу лет и не в курсе, как проверяется гидравлика после включения ее на Before Start Procedure и что должно быть в системе.
Процедура - это ведь не только "что-то включить". Но и "проверить, что получилось в результате".
--
Callouts: стандартные формулировки обычно имеются в FCOM, имхо лучше приводить примеры оттуда (таблица 3-1).
==
FCOM содержит не все коллауты, а только те, которые производитель счел важным там разместить. Значительная част коллаутов должна быть определена оператором, некоторые рекомендации есть в FCTM.
--
Денис, я коряво выразился. Я имею в виду моменты, когда без объяснения или без команды устанавливают другие режимы AFDS, добавляют скорость, изменяют режим работы двигателей на заходе и т.п. У вторых часто слишком мало опыта, чтобы быстро перестроиться и понять, для чего то или иное действие делает КВС.
===
Форматирование: сдвинуты переводы относительно английского текста и т.п. Понятно, что это первый вариант, в окончательном всё будет доработано :)
==
Очень неудобно разделять "действие" и "следствие/состояние" в разные книги/места.
--
Мне это видится так: сначала пишем полный вариант со всеми действиями/состояниями/комментариями, потом из него делаем укороченный вариант без комментариев. Пример для гидравлики:
Полный вариант:
Hydraulic Pump switches: SET AS NEEDED
Hydraulic pressure SYS "A/B", Brakes: VERIFY
System A/B LOW PRESSURE lights: VERIFY
И расшифровываем каждый пункт.
If pushback/towing is expected:
Hydraulic System "A" switches - SET OFF, Hydraulic System "A" Pressure - Check 0.
Hydraulic pressure
SYS "A": VERIFY 2800 psi minimum,
SYS "B": VERIFY 2800 psi minimum,
Brake pressure 2800 psi minimum.
Укороченный вариант:
Hydraulic system switches: AS NEEDED
Hydraulic pressure SYS "A/B", Brakes: VERIFY (Min 2800 psi)
System A/B LOW PRESSURE lights: VERIFY.
Получается этакий SOP Quick Reference Guide. В электронном варианте можно даже гиперссылки сделать на полную процедуру.
Второй вариант написал и использовал для себя в ходе переподготовки. Сделал карточки с процедурами, проверял правильность своих действий в кабине. Возможно, это нужно только для учёбы, в повседневной работе будет достаточно одного документа.
==
Про callouts: я имел в виду в твоём примере написать именно примеры из FCOM :) Про разработку мы с тобой уже обсуждали :))
If pushback/towing is expected:
Hydraulic System "A" switches - SET OFF, Hydraulic System "A" Pressure - Check 0.
===
Не в тему. А зачем ломать самолет, если пин установлен?
В тему. Как описывать процедуру - решает сам оператор. То есть, данный материал не описывает требований к содержанию каждой процедуры, такие нюансы должен определить оператор - в каком виде процедуру предлагать своим пилотам.
Но давай подискутируем.
То, как сделал ты процессе переподготовки - делают, наверное, все. Так действительно, проще... кажется, что проще.
Для переподготовки все эти "меморики и мнемотехники" вполне сойдут. Но дальше, по мере получения опыта, необходимо уже углубляться в детали - и на самом деле, мы (инструкторы) постоянно сталкиваемся с последствиями таких "мнемоник" - один пример я уже привел с гидравликой, но их вагон и маленькая тележка.
То есть, пилот помнит то, что изначально хорошо выучил. При обучении чему то новому проще целое делить на части... вот он на части поделил, стало получаться (и замечаний не последовало! - важно!) - и "забил" на углубление в детали. То есть в итоге картинка не стала целой. И это при том, что пилот использовал SOPs цельные, со всеми этими "маленькими шрифтами".
Теперь свой опыт по обучению SOPs. В нашем АУЦ я неоднократно проводил занятия, натурные - в классах с "кабиной". На них мы тупо зубрили SOP, но на базе "мнемоник". То есть пилот сначала понимает цель каждой процедуры, когда она начинается, структуру процедуры... Так называемый "скелет".
А потом наращивает на него "мясо". И эта "зубрежка" происходит не дома с книжкой, а перед изображением кабины самолета.
А так как это групповое занятие и каждая процедура проговаривается/демонстрируется неоднократно (а были и идеальные группы, у которых следом шли FBS) - обучение очень эффективное.
Или брифинг при полете над высокой местностью, en-route diversion?
UPD - Хотя может и ставится.
И где-то пробегал заголовок в кавычках - они скорее всего лишние.
Edited at 2015-04-24 08:18 pm (UTC)