?

Log in

No account? Create an account

Previous Entry | Next Entry

Новый материал.

Уже более глобальный, чем просто рекомендации по полету на конкретном воздушном судне.

В нем описаны рекомендации операторам по разработке SOPs. Материал основан на соответствующем циркуляре FAA, датированным 2003-м годом, однако, внесено очень много своего.

Скачать по ссылке с Яндекс.Диска



Хотелось бы услышать критику. Материал разрабатывался довольно быстро.

Tags:

Buy for 60 tokens
В силу своей занятой работы свадебным организатором я часто делаю покупки в онлайн магазинах. В магазины хожу только за продуктами и то обычно заказываю готовую еду из кафе и ресторанов или ем на свадьбах. Я много видела рекламы Letyshops и по начала отнеслась к нему скептически ожидая очередного…

Comments

( 20 comments — Leave a comment )
artefact_2014
Apr. 16th, 2015 03:57 pm (UTC)
Уважаемый Денис! Уже несколько лет Вас читаю, но в первый раз решился откомментировать. Я ни разу не летчик, но по своей работе постоянно сталкиваюсь с разработкой, применением и контролем применения стандартных форм документации. Как я вижу, проблемы везде одинаковые.

Я не знаю насколько может быть полезно мое замечание, но хочется отметить, что в тех случаях, когда процедура, принимаемая как "стандартная", подразумевает большую вариативность ее выполнения, разработчики обычно стараются раздробить ее на несколько максимально детализированных процедур - вплоть до разработки узко-специальных TOPs (Technical Operating Procedures). С моей точки зрения - это не совсем верный подход. Возможно более приемлемо изложение порядка действий в рамках иной формы стандартной документации, то есть Policy, которая жестко ограничивает рамки возможных действий, оставляя некоторую свободу для исполнителя внутри себя.

Заранее прошу прощения, если "не в кассу". Но в аналитической лаборатории - работает.
denokan
Apr. 16th, 2015 04:09 pm (UTC)
В данном случае все в кассу, это тоже один из способов написания эффективных процедур.

Собственно говоря, SOP - это обширное понятие, и политики тоже являются своеобразными SOP. Равно, как многие SOPs являются следствием из политик.
artefact_2014
Apr. 16th, 2015 04:25 pm (UTC)
Ну, как сказать... Разумеется, все это типы controlled documents, но это разные типы, для разных случаев. Рискну предположить что в Вашем случае процедура захода на посадку - это SOP, а процедура захода на посадку в конкретном аэропорту - ТОР. Так и главное назначение и отличие policy от procedure будет то, что в процедуре описывается четкая последовательность действий, в то время как policy прежде всего ограничивают то, что делать нельзя ни при каких обстоятельствах. В чем Вы абсолютно правы, так это в том, что SOPs всегда являются детализацией polices. Вопрос в том, когда SOPs необходимы, а когда можно на policy остановиться. Как говорится, "стандартные процедуры могут учитывать все, кроме того, что их можно не выполнять".
cquercus
Apr. 18th, 2015 12:44 am (UTC)
>Собственно говоря, SOP - это обширное понятие, и политики тоже являются своеобразными SOP

Ну не совсем. В аббревиатуре СОП главное слово - процедура. Если брать идеологию ISO 9000, то процедура - это способ существования процесса. Так что процесс и процедура можно сказать одно и то же (разные ипостаси). Процесс - это цепочка действий, приводящая к определенному результату. Именно действий. А вот политики, правила, методики и т.п. - это немного в стороне: зачем эти действия делать, в каких случаях такие, а в каких - эдакие.
Такие вещи полезно различать хотя бы для того, чтобы структурировать информацию.
denokan
Apr. 18th, 2015 06:28 am (UTC)
Вот, например, Stabilized Approach Policy - это политика. Которая, тем не менее, собой определяет направление стандартных действий - то ли дополнительный брифинг провести, то ли на второй круг уйти. Которые в свою очередь тоже расписаны в процедурах.

Поэтому и я применил словосочетание "своеобразными SOP". Конечно же, не мешая их с SOP, которые однозначно описывают механику действий для исполнения того или иного процесса.

i1111i
Apr. 16th, 2015 04:07 pm (UTC)
Надо нам, паксам, тоже прочесть? ). Вдруг пригодится? )
falcon3000
Apr. 16th, 2015 04:44 pm (UTC)
Денис, это очень достойный труд который вряд-ли останется незамеченным! 👍🏻
brother_alik
Apr. 16th, 2015 05:20 pm (UTC)
Денис, читаю и пишу сразу по ходу чтения.

Кое-где слетело форматирование.

Можно было бы добавить примеры неработающих процедур - и как их сделать работающими.

При выполнении стандартных процедур в кабине нет КВС и второго пилота - есть 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. Наглядно и чётко. Жду окончательный вариант! :)))
denokan
Apr. 16th, 2015 05:24 pm (UTC)
Привет, Олег!

В левой колонке я брал за исходник шаблон из FAA AC, в правой - мой кривой перевод (торопился).

Цель данного проекта - не совсем требования конкретные по тому или иному случаю, сколько направить операторов на "путь истинный", указать, что следовало бы им описать. Так то, конечно, было бы здорово все проработать примерно так же детально, как стабилизированный заход.

Вообще, это работа по проекту Runway Safety в рамках целой ИКАО. В итоге должны родиться какие то рекомендации, а это - как бы побочная работа.
brother_alik
Apr. 16th, 2015 05:27 pm (UTC)
Побочная, но очень важная! :)

Переслал коллегам, если будут комментарии от них - обобщу и выложу в комментариях.
denokan
Apr. 16th, 2015 05:29 pm (UTC)
Спасибо!
brother_alik
Apr. 18th, 2015 07:12 am (UTC)
Вчера со Стасом перекинулись парой слов относительно вашей работы сейчас :) КРУТО!! :))
Искренне желаю удачи! :))
denokan
Apr. 18th, 2015 07:43 am (UTC)
Еще раз спасибо! :)

И тебе отдельное спасибо за то, что прочитал и выдаешь предложения!

И вообще - будут какие вопросы, требующие стороннего взгляда или разъяснения - не стесняйся.
denokan
Apr. 18th, 2015 06:37 am (UTC)
---
При выполнении стандартных процедур в кабине нет КВС и второго пилота - есть PF и PM. До сих пор многие КВС об этом забывают в силу сложившихся на советской технике привычек.
==

Не так.

КВС есть всегда. Это лицо, назначенное на полет в качестве несущего ответственность за безопасный его исход. И как следствие, это лицо наделено авторитетом принимать решения, необходимые для обеспечения такой ответственности. Например, отступать от стандартных процедур.

ВП в качестве PF не имеет права принимать окончательные решения в той или иной ситуации, это всегда право КВС - будь он даже PM в этот момент.

Другое дело (из CRM) - умение КВС грамотно пользоваться своим авторитетом власти, не перегибать палку, уметь собрать все мнения и принять лучший план действий, даже если он родился не в его голове... но решение действовать по этому плану - все равно за КВС.

---

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

Или что-то другое?

---
На мой взгляд SOP как руководство по выполнению полётных процедур должно быть свободно от расширенных комментариев мелким шрифтом, в которых указывается необходимость проверки состояния системы и т.п.
==

Вот с этим сложно согласиться. Очень неудобно разделять "действие" и "следствие/состояние" в разные книги/места. SOPs это всегда компромисс между желанием "высказаться" и объемом, однако, критические вещи желательно размещать перед глазами.

Например, многие пилоты летают на 737 по многу лет и не в курсе, как проверяется гидравлика после включения ее на Before Start Procedure и что должно быть в системе.

Процедура - это ведь не только "что-то включить". Но и "проверить, что получилось в результате".

--
Callouts: стандартные формулировки обычно имеются в FCOM, имхо лучше приводить примеры оттуда (таблица 3-1).
==

FCOM содержит не все коллауты, а только те, которые производитель счел важным там разместить. Значительная част коллаутов должна быть определена оператором, некоторые рекомендации есть в FCTM.
brother_alik
Apr. 18th, 2015 07:11 am (UTC)
ВП в качестве PF не имеет права принимать окончательные решения в той или иной ситуации, это всегда право КВС - будь он даже PM в этот момент.
--
Денис, я коряво выразился. Я имею в виду моменты, когда без объяснения или без команды устанавливают другие режимы 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 :) Про разработку мы с тобой уже обсуждали :))
denokan
Apr. 18th, 2015 07:41 am (UTC)
---
If pushback/towing is expected:
Hydraulic System "A" switches - SET OFF, Hydraulic System "A" Pressure - Check 0.
===

Не в тему. А зачем ломать самолет, если пин установлен?

В тему. Как описывать процедуру - решает сам оператор. То есть, данный материал не описывает требований к содержанию каждой процедуры, такие нюансы должен определить оператор - в каком виде процедуру предлагать своим пилотам.

Но давай подискутируем.

То, как сделал ты процессе переподготовки - делают, наверное, все. Так действительно, проще... кажется, что проще.

Для переподготовки все эти "меморики и мнемотехники" вполне сойдут. Но дальше, по мере получения опыта, необходимо уже углубляться в детали - и на самом деле, мы (инструкторы) постоянно сталкиваемся с последствиями таких "мнемоник" - один пример я уже привел с гидравликой, но их вагон и маленькая тележка.

То есть, пилот помнит то, что изначально хорошо выучил. При обучении чему то новому проще целое делить на части... вот он на части поделил, стало получаться (и замечаний не последовало! - важно!) - и "забил" на углубление в детали. То есть в итоге картинка не стала целой. И это при том, что пилот использовал SOPs цельные, со всеми этими "маленькими шрифтами".

Теперь свой опыт по обучению SOPs. В нашем АУЦ я неоднократно проводил занятия, натурные - в классах с "кабиной". На них мы тупо зубрили SOP, но на базе "мнемоник". То есть пилот сначала понимает цель каждой процедуры, когда она начинается, структуру процедуры... Так называемый "скелет".

А потом наращивает на него "мясо". И эта "зубрежка" происходит не дома с книжкой, а перед изображением кабины самолета.

А так как это групповое занятие и каждая процедура проговаривается/демонстрируется неоднократно (а были и идеальные группы, у которых следом шли FBS) - обучение очень эффективное.
cheral1979
Apr. 16th, 2015 09:47 pm (UTC)
На мой взгляд не хватает брифинга на эшелоне , т. е действия при отказе двигателя . Необходимую стратетегию эшелон и когда необходимо применять другую в зависимости от mora. Ну и в цвете последних событий взаимодействие между летным и кабинным экипажем. Про второе я точно не могу сказать о необходимости сего, т. к в голове пазл не складывается .
denokan
Apr. 18th, 2015 06:40 am (UTC)
Вы имеете в виду аварийный брифинг? (NITS или аналоги?)

Или брифинг при полете над высокой местностью, en-route diversion?
cheral1979
Apr. 20th, 2015 03:31 am (UTC)
Да аварийный . Над любой любой местностью куда летететь , эшелон снижения. На эйрбасе называется стратегия при отказе двигателя
Сергей Измалкин
Apr. 24th, 2015 07:43 pm (UTC)
1.1 - Начиная со второго уровня нумерации точка не ставится )))

UPD - Хотя может и ставится.

И где-то пробегал заголовок в кавычках - они скорее всего лишние.

Edited at 2015-04-24 08:18 pm (UTC)
( 20 comments — Leave a comment )

Profile

denokan
denokan

Latest Month

August 2017
S M T W T F S
  12345
6789101112
13141516171819
20212223242526
2728293031  

Tags

Powered by LiveJournal.com
Designed by yoksel