Главная
О нас
Наши собаки
- Репортаж
- Фотоальбом
- Видео
Информация
- Новости
- Статьи
- Ветеринария
- Разное
Юмор
Форум
Контакты

Это интересно

ОКД
ЗКС
ИПО
КНПВ
Мондиоринг
Большой ринг
Французский ринг
Аджилити
Фризби

Опрос

Какой уровень дрессировки необходим Вашей собаке?

	Элементарное послушание в быту
	Чёткое выполнение команд
	Спорт и соревнования

Полезные ссылки

РКФ

Все о дрессировке собак

Стрижка собак в Коломне

Поиск по сайту

Бортовой журнал или книга в самолете? Электронный бортовой журнал самолета требования

Изготовление бортжурналов « АНТЦ "Технолог"

В соответствии с требованиями Международных стандартов ОАО «Аэрофлот-Российские авиалинии» разработана и утверждена новая форма бортжурналов ВС. Согласно Письму заместителя Министра транспорта РФ от 14.08.2007 № БК-18/6084 в бортжурналы, действующие в ОАО «Аэрофлот-Российские авиалинии» и ГТК «Россия», внесены дополнительные требования, изложенные в руководящих документах РФ по содержанию бортжурналов.

На основании Письма от 28.09.2007 № АВ14-396 проводится эксплуатационная проверка бортжурналов новой формы. В процессе эксплуатационной проверки на вертолетах ГА авиапредприятиями были внесены предложения по корректировке, связанной с особенностями выполнения рейсов на вертолетах. В соответствии с Письмом УПЛГ ВС ФАВТ от 09.10.2009 № ВД5.21-772 в ОАО «Авиакомпания «ЮТэйр» проводится эксплуатационная проверка новой формы бортжурналов на вертолетах 1, 2 и 3 класса.

Новая форма бортжурналов соответствует образцам, принятым в международной практике, и отвечает интересам авиакомпаний, осуществляющих международные полеты, а также полеты на внутренних линиях.

АНТЦ «Технолог» предлагает изготовить необходимое количество бортжурналов новой формы для самолетов и вертолетов по Вашему заказу. Каждый журнал рассчитан на 35-50 полетов, содержит 35-50 комплектов рабочих листов (основная белая страница + 2, 3 отрывных страницы: желтого, розового цветов).Рабочие листы содержат Логотип, код ICAO авиапредприятия и нумерацию неисправностей для каждого ВС. Порядок ведения бортжурнала определяется Инструкцией по заполнению бортжурнала ВС, являющейся его составной частью.

Главное отличие предлагаемых бортжурналов — способ изготовления. При использовании копировальной бумаги одной из главных проблем является постраничное соответствие табличных строк и столбцов, которую можно решить при офсетной печати, исключив печать на принтере. Использование программы учета сквозной нумерации неисправностей для каждого воздушного судна позволяет осуществлять дополнительный контроль правильности заполнения бортжурнала.

Для предварительного изучения порядка ведения и принятия решения о проведении эксплуатационной проверки см. копии листов макетов бортжурналов для самолетов (Вариант 1, Вариант 2), разработанных на базе бортжурналов, действующих в ГТК «Россия», и вертолетов. Возможно изготовление бортжурналов по индивидуальному макету Заказчика (пример). Разработка макета и согласование с Заказчиком входят в стоимость бортжурнала. Минимальный заказ – от 30 экземпляров. Срок изготовления – от 15 дней.

Оформить заказ

Наши Заказчики:

centertehnolog.ru

Бортовое программное обеспечение самолета

Основное назначение нормативных документов и стандартов - изложение инструктивных материалов для использования в процессах создания ПО авиационных бортовых систем, которые должны выполнять надлежащие функции с уровнем доверия к безопасности, удовлетворяющим требованиям к летной годности ВС.

Среди международных нормативных документов, содержащих требования к ПО АТ, важнейшим является документ DO-178, впервые сформулированный в 1978 г. В настоящее время используются его усовершенствованные варианты: DO-I78A, действующий с 1985 г., и DO-I78B, действующий с 1993 г., в котором значительное внимание отводится вопросу квалификации инструментального программного обеспечения.

В Украине и России действуют аналоги этих документов: соответственно КТ-178А с 1998 г. и КТ-178В с 2004 г. Дополнениями к этим квалификационным требованиям служат документы РМ-178А и РМ-178В.

Среди стандартов серии ISO, действующих в Украине и относящихся к ПО, главное место занимают два: ДСТУ ISO 9000-3-98 и ДСТУ 3918-1999 (ISO/IEC 12207:1995). Первый посвящен организации и мероприятиям системы качества применительно к ПО, второй процессам ЖЦ ПО. Требования стандартов ISO связаны непосредственно с процедурами сертификации ВС и его компонентов, включая процедуры сертификации ПО.

Кроме этого, при сертификации предприятий авиационной промышленности, в данном случае производственных процессов создания и применения ПО, используется документ АРМАК «Руководство 21.2С», а именно раздел «Элемент 3. Гарантия качества программного обеспечения», который подразделяется на две части: «Часть А. Бортовое ПО» и «Часть Б. ПО для приемки изделий».

К бортовому ПО относится ПО тех электронных систем ВС, которые входят неотъемлемой частью в сертификационный базис ВС определенного типа и установлены на его борту с целью выполнения необходимых для эксплуатации ВС функций. ПО систем, предназначенных, например, для проведения испытаний ВС, хоть и установлено на борту ВС, не является бортовым, а относится к инструментам процессов создания АТ.

Так как функции бортовых цифровых систем реализуются через ПО, то последнее служит объектом особого внимания сертифицирующего органа по причине его непосредственного влияния на безопасность эксплуатации ВС.

Критичность функциональных бортовых систем и уровень программного обеспечения. Главная цель процедур сертификации - это, прежде всего, получение определенных гарантий безопасности: предотвращение смерти, телесных повреждений, ухудшения здоровья людей, потери собственности. Началом работ по сертификации ПО любой сложной технической системы является анализ возможных последствий влияния потери (нарушения) функции системы на безопасность ее работы или использования для человека и собственности. Причем не имеет значения, чем вызвано нарушение функции - ошибкой пользователя, отказом аппаратуры или ошибками проектирования ПО. Важными являются глубина контроля системы, выявление и возможность парирования отказов средствами самой системы или системы более высокого уровня иерархии, необходимость резервирования, реконфигурации. К анализу следствий нарушения функции системы, как правило, приходится возвращаться неоднократно после следующих этапов, так как от правильного определения категории критичности системы зависит жесткость требований к ПО.

Документ КТ-178В определяет пять категорий критичности функциональных систем и соответственно пять уровней ПО. Несмотря на то, что по определению категории критичности системы и уровни ПО жестко связаны, процедура установления уровней допускает отклонения как в одну, так и в другую сторону.

Классификация уровней программного обеспечения по категориям критичности следующая:

ПО уровня А - ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, может привести к катастрофической ситуации для ВС, когда практически невозможно предотвратить гибель ВС и людей. Вероятность возникновения такой ситуации на один час полета должна быть практически невероятной, т. е. меньше чем 10~9;
ПО уровня В ПО такой функциональной системы, отказное состояние которой, возникшее из- за ошибки в ПО, может привести к аварийной ситуации для ВС. Аварийная ситуация характеризуется значительным ухудшением характеристик ВС или превышением его предельных ограничений, а также таким физическим напряжением летного экипажа, при котором он не может точно и полностью выполнить свои функции. Аварийная ситуация может привести к значительным повреждениям ВС, травмам людей или отдельным жертвам. Вероятность возникновения такой ситуации на один час полета должна быть крайне маловероятной, т. е. быть в диапазоне 10 М0~9;
ПО уровня С - ПО такой функциональной системы, отказное состояние которой, возникшее из- за ошибки в ПО, может привести к сложной ситуации для ВС. Сложная ситуация характеризуется заметным ухудшением характеристик ВС, выходом одного или больше параметров за эксплуатационные ограничения, но без достижения предельных ограничений, а также уменьшением способности экипажа справится с этой ситуацией из-за увеличения рабочей нагрузки и по причине появления неблагоприятных условий, которые снижают эффективность действий экипажа. Сложная ситуация может вызвать дискомфорт пассажиров, включая, возможно, травмы. Вероятность возникновения сложной ситуации на один час полета должна быть маловероятной, т. е. быть в диапазоне 10 5-10-7;
ПО уровня D - ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, может привести к усложнению условий полета для ВС. Такая ситуация характеризуется незначительным ухудшением характеристик ВС или небольшим увеличением рабочей нагрузки на экипаж. Такую ситуацию можно предотвратить, например, путем изменения плана полета, а для пассажиров она должна приводить не более, чем к некоторым неудобствам;
ПО уровня Е - ПО такой функциональной системы, отказное состояние которой, возникшее из-за ошибки в ПО, не влияет на эксплуатационные возможности ВС и не увеличивает нагрузки на экипаж. Получение от сертификационного органа подтверждения того, что данное ПО принадлежит к уровню Е, означает, что к нему не применяются положения документа КТ-178В.

Документ КТ-178А определяет три категории критичности функций бортовых авиационных систем:

существенную, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, характеризуется как катастрофическая или аварийная;
важную, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, относится к сложной;
несущественная, если особая ситуация, которая может возникнуть при нарушении выполнения хотя бы одной из функций системы ВС, относится к усложнению условий полета или не имеет последствий.

Соответственно существуют три уровня программного обеспечения:

уровень 1 для категории «критическая» с наиболее высокими требованиями к ПО и максимальным объемом работ, выполнение которых необходимо для доказательства соответствия сертификационным требованиям, и максимальным количеством сопроводительной документации;
уровень 2 - для категории «существенная» с более низкими требованиями;
уровень 3 - для категории «несущественная» с минимальными требованиями.

Уровень ПО зависит не только от категории критичности функции. Немалую роль играют архитектура системы и структура ее программного обеспечения. Например, анализируемая система может иметь резервный аналоговый канал, который целиком дублирует функции цифрового канала. В определенных условиях этого может быть достаточно для снижения уровня ПО. И, наоборот, в случае, когда на одном ВС анализируемая система используется таким образом, что ее отказ отвечает одной категории критичности, а на другом ВС отказ этой же системы приводит к более критическим условиям эксплуатации, разработчик системы может определить более высокий уровень ПО. Важное влияние на определение уровня ПО имеют также методы его проектирования. Например, метод обособления или контроля как метод зашиты от конкретных отказных состояний путем непрерывной проверки правильности выполнения функции, или много-версионный метод, реализация которого предусматривает создание двух или больше компонентов ПО, выполняющих одну функцию разными способами и разным ПО, дает возможность отделить функционально независимые компоненты ПО с целью изоляции отказов.

Упомянутые выше количественные значения вероятности возникновения особых ситуаций не касаются вероятности не выявленных ошибок в ПО. К ПО невозможно применить развитый математический аппарат теории статистики, который лает возможность рассчитывать вероятность событий, так как нет прямой связи между вероятностью возникновения особых ситуаций и вероятностью не выявления ошибок в ПО. Таким образом, уровни ПО или показатели его надежности, основывающиеся на уровнях ПО, не могут быть использованы в процессе оценки безопасности системы, например, так, как используется интенсивность отказов аппаратного обеспечения.

Тем не менее, нормативные документы рекомендуют применять те или другие количественные критерии оценки качества ПО или достижения определенного уровня качества с учетом того факта, что индустрия программных средств накопила большую коллекцию моделей и метрик, которые позволяют оценивать разные характеристики ПО. Больше того, во время разработки и верификации ПО настоятельно рекомендуется вести учет выявленных ошибок и недостатков ПО, а также принятых мер по их устранению.

Процессы разработки, верификации и аттестации программного обеспечения

Главным этапом при создании любого технического продукта является его разработка, включая изготовление опытного образца, его испытания для подтверждения соответствия требованиям и, в конце концов, официальное утверждение его эксплуатационной пригодности. Создание программного продукта полностью соответствует этим процессам.

Приведены процессы создания программного продукта, интересные с точки зрения получения определенных гарантий безопасности. Здесь каждое мероприятие, связанное с разработкой (Р) имеет соответствующее верификационное мероприятие (В). И те, и другие порождают соответствующие документы (Д).

Исходным материалом для инициации процессов создания ПО являются заявленные требования к системе, которые должны быть оформлены в виде соответствующего документа (ДФ <«ноль»>), и которые необходимо преобразовать в требования к ПО (Д1), именно в связи с тем, что реализация функций цифровых электронных систем, как уже отмечалось, осуществляется программными средствами. Процесс разработки требований к ПО (Р1) - это и есть процесс трансформации требований к системе в требования к ПО.

Для облегчения понимания процедуры трансформации, как во время разработки, так и ее верификации, рекомендуется поделить процедуру как минимум на две части: разработку требований высокого уровня и последующую разработку требований низкого уровня.

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

Требования низкого уровня формулируются в терминах инженерии ПО и их получают путем анализа и детализации требований высокого уровня. Требования низкого уровня относятся непосредственно к процедурам кодирования и комплексирования ПО, т. е. это требования к применяемым языкам программирования, компиляторам, к архитектуре и связям ПО, к структуре его компонентов, к классификации программных объектов, к операторному базису, к среде разработки и верификации, а также к стилю программирования.

Сопутствующими документами являются стандарты и другие нормативные документы (Д2) на технические задания, на проектирование, на кодирование, сопровождение. Верификационное мероприятие, завершающее первый этап разработки, - это сопоставление требований к ПО с требованиями к системе с целью проверки совместимости распределения функций между аппаратными и программными средствами и интерфейсами, полноты и адекватности требований к ПО. Рекомендуемая форма документирования - таблица перекрестных ссылок, которая может быть оформлена как отдельный верификационный документ, или быть частью общего документа, описывающего процедуры верификации всех этапов, их результаты, а также возникающие проблемы и меры по их устранению.

Следующие этапы разработки - планирование процессов создания ПО и управления его качеством. Основная цель планирования - определение ресурсов и последовательности действий, обеспечивающих достижение поставленных целей. Тут еще определяется организация (взаимосвязь) процессов. В результате должны быть оформлены пять документов (допускается обоснованное совмещение): план сертификации ПО (ДЗ), план разработки ПО, план верификации, а также планы управления конфигурацией ПО (Д6) и гарантии его качества. Верификационные мероприятия (В2, ВЗ) относятся, в основном, к процедурам согласования планов на этапе утверждения, а также к их коррекции по замечаниям, возникшим на более поздних этапах создания и даже эксплуатации ПО. Содержание документов рассматривается дальше.

Продолжением процесса разработки является процесс проектирования ПО. Здесь требования к ПО высокого уровня уточняются на протяжении нескольких итераций процесса проектирования для формирования архитектуры ПО алгоритмов функционирования, с учетом требований низкого уровня до такой степени, чтобы по ним можно было составить исходный код. Для удовлетворения требований безопасности следует предусмотреть контроль потоков управления и данных, например, предусмотреть сторожевой таймер, проверку на непротиворечивость и перекрестное сравнение потоков, естественно с соответствую щей реакцией на «отказные» состояния. Результаты проектирования фиксируются в документе, описывающем проект ПО.

Верификационное мероприятие В4 - проверка проекта ПО на соответствие требованиям к ПО и стандартам на проектирование, включая проверку алгоритмов функционирования системы. Главной целью верификации проекта является обеспечение его «проверяемости». При этом должны быть учтены, по крайней мере, такие факторы: последовательность выполнения программы, потоки данных и возможное их искажение, потенциальное влияние аппаратных средств на обособление и целостность функций. В верификационном документе Д13 должна быть представлена таблица соответствия проекта ПО требованиям к ПО в виде перекрестного анализа. Отступления от стандартов и требований должны быть отмечены и обоснованы.

Все рассмотренные до сих пор этапы, лаже этап проектирования ПО, можно охарактеризовать как подготовительные. Только в результате процессов программирования (Р5), комплексирования программных компонентов (Р6) и интеграции ПО с аппаратными средствами (Р7) появляется собственно программный продукт в окончательном виде.

Первым результатом процесса, реализующим требования низкого уровня, всегда является исходный код (Д9), который должен трансформироваться в проект ПО. Учет архитектуры ПО в процессе проектирования реализуется в процедурах комплексирования компонентов ПО, а интеграция ПО в целевой вычислитель даст в конце концов, исполняемый объектный код (ДЮ) и соответствующий каталог комплектации ПО (Д11). Неправильные или недостаточные входные данные, выявленные в этих процессах, следует возвратить в предыдущие процессы для внесения исправлений или ясности. Кроме этого, среда создания ПО (она же, чаще всего, и среда его сопровождения) должна быть четко и детально определена и зафиксирована (Д12).

Само собой разумеется, на данном этапе разработки осуществляются наиболее объемные, наиболее сложные по содержанию и наиболее важные верификационные мероприятия (В5, В6, В7) под общим названием - тестирование (испытания) ПО с целью выявления содержащихся в ПО ошибок. Проблема здесь в том, что выявленные ошибки, как правило, устраняются, а не выявленные не могут быть даже спрогнозированы.

Содержание всех трех верификационных мероприятий.

Процесс этот состоит из многих итераций и включает все указанные позиции в каждой итерации и в каждом мероприятии. Результаты процесса фиксируются в документе Д13.

Рассмотрение процессов создания ПО будет неполным, если не упомянуть о планах УКПО и ГКПО. которые должны быть реализованы путем внешних и внутренних аудиторских проверок состояния конфигурации, а также соответствующих организационных и технологических процедур, и отражены в протоколах Д14 и Д15.

Реализация плана сертификации ПО фиксируется документом Д16.

Цикл создания ПО завершается испытаниями подтверждения эксплуатационной пригодности бортовой цифровой функциональной системы (В9). Эти испытания проводятся как часть общего официального удостоверения (аттестации) того, что система на данном ВС в заявленных эксплуатационных условиях функционирует правильно.

Документация для сертификации программного обеспечения. В США с 1987 г. официально существует методика института SEI (Software Engineering Institute), позволяющая определить уровень технологической зрелости предприятий, разрабатывающих ПО и совершенствовать процессы разработки. Первоначально это Capability Maturity

Model (СММ), а позднее - Capability Maturity Model Integration (CMMI). В соответствии с моделью высший («оптимизирующий») уровень технологической зрелости - пятый - отвечает целиком автоматизированному процессу производства ПО на базе математической модели с применением методов параметрической и структурной оптимизации, и организация сосредотачивается на совершенствовании процессов. Одним из признаков низшего первого («первоначального») уровня является зависимость организации от отдельных программистов, а одним из условий перехода со второго («повторяемого») уровня на третий («определенный») - документирование процессов под управлением соответствующей службы во главе с ответственным лицом из состава высшего руководства организации.

Все фазы ЖЦ ПО имеют начало и конец Документация же может существовать вечно. Поэтому сформулировать требования к документации - значит сформулировать требования ко всем вышеописанным процессам создания программного обеспечения. Документация и есть тот самый материальный фактор, по которому сертифицируется ПО. Документация также является основным элементом, тщательно анализируемым при расследовании катастроф или предпосылок аварийных ситуаций.

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

Конкретный перечень документации, необходимой для сертификации ПО, зависит от уровня ПО (от критичности системы) и определяется в процессе согласования плана сертификации с сертификационным органом. Ниже кратко показана суть и уже упомянутых документов.

Д1 «Требования к ПО» - содержит описание трансформации требований к системе в требования к ПО с выделением требований высокого и низкого уровней и с особым вниманием к вопросам безопасности и возможным отказным состояниям. Должны быть определены критерии выполнения функций и возможные ограничения, например: по памяти, по времени, по частоте, по взаимодействию. Особое внимание отводится обособлению компонентов ПО.
Д2 - «Стандарты создания ПО» - множественный перечень. Как минимум - это перечень официально действующих стандартов разработки требований, проектирования, кодирования, испытаний ПО. Вместе со стандартами - это несколько документов.
Их содержание - методы создания, правила структурирования, ограничения на проект (например, исключение рекурсии, динамических объектов, альтернативных обозначений данных), ограничения по сложности (например, вложенность вызовов, использование переходов), по языку и компиляторам, среде и инструментам.
ДЗ - «План сертификации ПО» подается на утверждение в государственный сертификационный орган, определяет порядок действий, методы доказательства соответствия продукта требованиям к нему, к системе, к ВС и необходимую для этого документацию.
Д4 «План разработки ПО» - определяет ЖЦ создания ПО, взаимодействие исполнителей и среду разработки.
Д5 - «План верификации ПО» - определяет этапы (позиции процесса разработки и критерии перехода к процедурам верификации), методы, процедуры, среду и инструменты верификации, включая инструментальные программные средства, инструкции относительно достижения необходимых показателей качества (безопасности) и указания относительно повторных проверок и испытаний после внесения изменений в ПО, которые гарантируют устранение выявленных ошибок.
Д6 - «План управления конфигурацией ПО» - устанавливает правила идентификации единиц ПО и комплектации, базовые версии и их трассируемость на производные версии, правила управления изменениями, правила порядка и учета состояния конфигурации, архивирования, контроля и зашиты данных, обращения единиц ПО.
Д7 - «План гарантии качества ПО» устанавливает сферу действия, распределение ответственности и полномочий инспекций и аудита, других мероприятий, связанных с процессами получения гарантий, включая сообщения о проблемах, их отслеживание и корректирующие действия.
Д8 - «Описание проекта ПО» - содержит подробное описание того, каким образом ПО удовлетворяет предъявляемым к нему требованиям высокого уровня, включая алгоритмы, структуры данных, и как требования к ПО распределяются по задачам и процессам. Кроме этого, приводится описание архитектуры ПО, библиотек, входов/ выходов, потоков данных и управления, распределения ресурсов и связанных с этим ограничений, процедур диспетчеризации, схем между-процессного и межзадачного обмена, прерывания, компонентов ПО, методов их обособления.
Д9 «Исходный код» - содержит исходный код, инструкции компилятора для генерации объектного кода, данные для редактирования связей и загрузки.
Д10 - «Объектный исполняемый код» - содержит код, пригодный для непосредственного выполнения процессором целевого вычислителя, т. е. такой, который загружается в аппаратуру системы авионики.
Д11 — «Каталог комплектации ПО» - определяет конфигурацию продукта как поставляемой единицы. Он должен идентифицировать программный продукт в целом, каждый компонент, соответствующие документы и их носители.
Д12 - «Каталог среды ПО» - содержит описание среды ЖЦ ПО, начиная с этапа специфицирования требований и заканчивая этапом списания продукта из эксплуатации. В каталоге идентифицируются инструменты разработки, верификации, сопровождения программных средств, приводятся данные относительно квалификации инструментария.
Д13 - «Процедуры и результаты верификации» допускается делить на два-три документа, в которых должны быть описаны процедуры рассмотрения, анализа, испытаний на всех этапах разработки, примененные тестовые примеры и результаты проведенных процедур с идентифицированными компонентами ПО. Все проблемы и выполненные корректирующие действия должны быть подробно описаны.
Д14 - «Протоколы УКПО».
Д15 - «Протоколы ГКПО».
Д16 - «Итоговое заключение о ПО» - это основной документ, фиксирующий выполнение «Плана сертификации ПО» и степень соответствия «Требованиям к ПО». Он должен содержать краткие описания системы и ПО, сертификационные условия (договоренности), характеристики, идентификацию и состояние ПО, перечень документации на ПО и заявление о степени выполнения требований к ПО.

avia.pro

О порядке ведения раздела III бортовых журналов приема-передачи самолета (вертолета) (индивидуальные особенности двигателей, систем)

Документ по состоянию на август 2014 г.

(Извлечение)

В целях упорядочения ведения раздела III бортовых журналов для увеличения объема его информации, особенно на самолетах, выполняющих полеты методом "совмещенных эстафет", требую:

1. Ведение записей в разделе III "Индивидуальные особенности самолета (вертолета), двигателей, систем" бортовых журналов приема-передачи летательных аппаратов возложить лично на ведущих инженеров авиационно-технических баз.

2. Записи в разделе III "Индивидуальные особенности самолета (вертолета), двигателей, систем" бортовых журналов приема-передачи летательных аппаратов вести по специальной форме (Приложение 1) и по содержанию согласно типовому перечню (Приложение 2).

3. Указание изучить с летным составом и инженерно-техническим составом АТБ, летных отрядов, ЛИС и ЛИК и обеспечить его выполнение.

Приложение 1 к указанию МГА от 1 ноября 1975 г. N 161/у

------------------------+------------------------+------------------------- ¦ Особенности и ¦ Особенность ¦Особенность аннулирована¦ ¦ (при необходимости) ¦ действительна ¦ ¦ ¦ рекомендации экипажу +----------------+-------+----------------+-------+ ¦ и обслуживающему ¦фамилия ведущего¦дата и ¦фамилия ведущего¦дата и ¦ ¦ персоналу ¦ инженера ¦роспись¦ инженера ¦роспись¦ +-----------------------+----------------+-------+----------------+-------+ ¦ 1 ¦ 2 ¦ 3 ¦ 4 ¦ 5 ¦ +-----------------------+----------------+-------+----------------+-------+ ------------------------+----------------+-------+----------------+--------

Приложение 2 к указанию МГА от 1 ноября 1975 г. N 161/у

ТИПОВОЙ ПЕРЕЧЕНЬ ИНДИВИДУАЛЬНЫХ ОСОБЕННОСТЕЙ ГАЗОТУРБИННЫХ САМОЛЕТОВ (ВЕРТОЛЕТОВ) ГА, ПОДЛЕЖАЩИХ ВНЕСЕНИЮ В РАЗДЕЛЕ III БОРТОВОГО ЖУРНАЛА ПРИЕМА-ПЕРЕДАЧИ САМОЛЕТА (ВЕРТОЛЕТА)

1. Данные по нейтральному положению рулей, элеронов и триммеров.

2. Ограничение полетного посадочного веса (от стандартного).

3. Доработки конструкции, связанные с изменениями правил летной и технической эксплуатации, кратким изложением особенностей и рекомендаций экипажу и обслуживающему персоналу (особенность аннулируется при получении соответствующих дополнений к руководствам по летной и технической эксплуатации).

4. Потребляемый ток на противообледенительные системы крыла, оперения и воздушных винтов.

5. Данные о допуске самолета по категориям захода на посадку.

6. Изменение показаний мембранно-анероидных приборов при переключении с основной на аварийную систему.

7. Данные о виброперегрузках двигателей, замеренные после установки их на самолеты (вертолеты).

8. Тип масла, залитого в шарниры воздушного винта.

9. Значение оборотов взлетного режима (для турбореактивных двигателей по формуляру).

lawru.info

Бортовой журнал — Википедия РУ

Эта статья — о журнале в авиации. О журнале в судоходстве см. Судовой журнал.

Бортовой журнал —технический журнал, в который в установленной форме записываются сведения о воздушном судне, всех произведенных полетах, особых случаях в полете, обнаруженных неисправностях, произведенном техническом обслуживании, замене агрегатов и т. п. Бортжурнал предназначен для контроля технического состояния воздушного судна, контроля произведенных регламентных работ. Также он широко используется при расследовании авиационных инцидентов. За правильность и своевременность заполнения бортового журнала отвечает командир воздушного судна. Бортовой журнал входит в перечень документации, которая в полете обязана находиться на борту воздушного судна. Местонахождение бортжурнала на земле не регламентировано, но, как правило, он также хранится на борту. В гражданской авиации бортовой журнал ведется на английском языке. В военной авиации, а также на воздушных судах, не допущенных до международных рейсов, бортовой журнал ведется на национальном языке.

Разделы бортжурнала

Перечень систем воздушного судна (двигатели, ВСУ, топливная система, гидравлическая система) с указанием типов и серийных номеров.
Список индивидуальных особенностей воздушного судна.
Список произведенных полетов с указанием номера рейса, состава экипажа, точного времени и места взлетов и посадок, времени работы каждого из двигателей на номинальном и взлетном режиме, потраченном топливе, замеченных неисправностях.
Лист замеченных неисправностей.
Лист отложенных неисправностей (MEL).
Перечень бортового имущества.

Поскольку ICAO предъявляет требования только к информации, содержащейся в бортжурнале, конкретную форму документов устанавливает авиакомпания-оператор.

Бортовой журнал и информационные системы авиакомпании

В настоящее время практически все авиакомпании используют собственные информационные системы для учета отказов и управления техническим обслуживанием. Поэтому записи в бортжурнале непосредственно после посадки вносятся в ИС авиакомпании. Для этого в бортовых журналах многих авиакомпаний предусмотрены самокопирующиеся страницы. Распространение информационных систем приводит к падению роли бумажного бортового журнала как самостоятельного документа.

Бортовой журнал радиосвязи должен постоянно находиться на борту воздушного судна. По окончании ведения радиосвязи, после каждого полета бортрадист обязан разборчиво записать свою фамилию и расписаться [1].

В военной авиации

В государственной авиации, в соответствии с требованиями Федеральных авиационных правил инженерного-авиационного обеспечения (ФАП ИАО, а также бывшими в действии в соответствующими требованиями НИАС), на каждый летательный аппарат ведётся «Журнал подготовки самолёта (вертолёта)», куда записываются все выполняемые работы — подготовка ВС, заправка, снаряжение, загрузка и центровка, все выполненные или невыполненные вылеты, замечания по работе техники в полёте, устранения неисправностей, монтажно-демонтажные и регулировочные работы, работы по хранению ВС, периодические работы, парковые дни и работы по бюллетеням промышленности, также ежедневное вскрытие и закрытие ВС и т. д. Заносятся подписи ответственных лиц, лётного состава, исполнителей и контролирующих работы. Для военно-транспортных машин при перелётах ведётся два журнала — бортовой и наземный.

ЖПС — является основным отчётным документом за определённый период эксплуатации ВС. Форма журнала стандартизирована, а правила ведения строго регламентированы. Ответственным лицом за ведение журнала является техник самолёта (старший техник корабля).

Нормативные акты

Приложение 6 к Конвенции о международной гражданской авиации.
Наставление по производству полетов гражданской авиации, 1985 г.
Правила заполнения бортового журнала компании «Аэрофлот».
Федеральные авиационные правила инженерно-авиационного обеспечения государственной авиации РФ, 2005 год
Федеральные авиационные правила производства полетов государственной авиации РФ [2]

Примечания

http-wikipediya.ru

Как проверяют самолеты в Европе

По мотивам Европейского рейтинга безопасности авиакомпаний. У нас недавно была публикация по этой теме. Что как и кто проверяет. Для пассажиров интересно тем, что позволяет немного заглянуть внутрь отрасли )

SAFA – БЕЗОПАСНОСТЬ РОССИЙСКИХ САМОЛЕТОВ ДЛЯ ЕВРОПЫ

В последние несколько лет много говорят о программе SAFA — Safety Assessment of Foreign Aircraft, «Оценка безопасности иностранных воздушных судов». Для чего нужна эта программа и кого она касается? Об этом корреспонденту газеты рассказал Валерий Геннадьевич КУЛАВСКИЙ, заместитель генерального директора по качеству и безопасности полётов — начальник инспекции по безопасности полётов S7.

SAFA была разработана в 1996 году как развитие американской программы оценки авиационной безопасности полетов IASA (International Aviation Safety Assessment), введенной в конце восьмидесятых годов прошлого столетия. Главная цель программы — повышение безопасности полетов путем проведения инспекций ВС, которые приземляются в 42 странах — членах ЕКГА (Европейская конференция гражданской авиации).

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

Считается, что цель рамповых проверок по программе SAFA — изучение соответствия перевозчиков и национальных авиационных властей третьих стран требованиям трех приложений к Чикагской конвенции: приложения 1 (лицензирование авиационного персонала), приложения 6 (летная эксплуатация) и приложения 8 (поддержание летной годности воздушного судна). Между тем, в контрольной карте присутствуют также пункты, касающиеся радионавигации и безопасной перевозки грузов.

Проверки выявляют соответствие стандартам ICAO не только отдельных эксплуатантов, но и качества надзорной деятельности национальных авиационных властей, и в случае нарушений замечания выносятся в адрес авиакомпании и в адрес исполнительных органов страны-эксплуатанта.

Проверки ВС проводится выборочно, но есть несколько факторов, которые увеличивают вероятность проведения SAFA. Например, воздушные суда советского производства проверяют чаще, ведь у них больше шансов получить замечания, чем у нового Boeing или Airbus.

Кроме того, если в расписании полётов есть самолет, в котором предыдущая проверка выявила недостатки, то он почти наверняка будет проверен вновь. Какие последствия это может иметь для авиакомпании? Если перевозчик или конкретный самолет получил серьезные замечания, либо есть определенные претензии к тому или иному типу самолета, это означает повторные проверки. «Проблемные» самолеты отслеживаются через базу данных Евроконтроля.

SAFA — процедура формальная, но результат во многом зависит от готовности экипажа воздушного судна к ее прохождению. При подготовке к проверке основная задача членов экипажа — отвечать на вопросы инспекторов. Все вопросы стандартные, и при известной подготовленности ответить на них не составит труда. Знание летным составом ответов на вопросы, содержащиеся в контрольной карте, существенно сократит время проверки. При этом если знание экипажем английского языка не позволяет понять задаваемые вопросы, то инспектор отмечает это как нарушение. Формуляры на русском языке воспринимаются как нарушение, хотя нигде в стандартах ICAO не указано, на каком языке должны быть формуляры и техническая документация. Проверяющим запрещено задерживать рейс, если нет серьезной угрозы безопасности полетов. Не допускается контакт инспекторов с пассажирами, а время проверки ограничено продолжительностью подготовки к оборотному рейсу.

Отклонения от норм и стандартов ICAO делятся на три категории в зависимости от тяжести возможного влияния на безопасность полета. Категория 1 — это незначительное несоответствие, которое не влияет на безопасную эксплуатацию ВС. Категория 2 — более значительный недостаток. В тех случаях, когда на воздушном судне допускаются многочисленные несоответствия 2ой категории или они не исправляются, инспекторы должны проинформировать об обнаруженных недостатках полномочный орган эксплуатанта. Категория 3 — несоответствие может повлиять на безопасную эксплуатацию воздушного судна и безопасность пассажиров. В этом случае инспектору следует проинформировать командира о том, что необходимо предпринять меры по устранению несоответствия до вылета воздушного судна.

Любой самолет S7, летающий в европейские страны, может подвергнуться проверке SAFA, поэтому нужно быть к ним готовыми. Важно не только знать методику ответов на основные вопросы инспекторов, но и ОБЯЗАТЕЛЬНО фиксировать в TLB* и CLB** ВСЕ выявленные дефекты ВС. Лётные и кабинные экипажи S7 обратите на это внимание при подготовке к очередному рейсу!

* TLB (Technical Log Book) — бортовой журнал технического состояния ВС (сюда пишут замечания пилоты)** CLB (Cabin Log Book) — бортовой журнал состояния салона и аварийно-спасательного оборудования ВС (сюда пишут замечания бортпроводники)

Сергей АЛЕКСЕЕВ_____________________________________________

В России также проводятся выборочные проверки силами территориальных авиационных властей. Инспектор заходит на тот или иной борт. Проверяет документы, осматривает самолет, задает вопросы. Так что в авиации все под многократным, зачастую, перекрестным контролем. А как иначе.

s7-direct-line.livejournal.com

Бортовой журнал или книга в самолете?, Лайфхаки для путешествий

Наше современное общество все чаще и чаще летает, и главная тому причина экономия времени. Можно ли себе представить, что в далеком прошлом из Екатеринбурга на телегах до Москвы люди добирались месяцы. Сейчас это же расстояние занимает на самолете 2 часа 15 минут.

Но вопрос не в скорости перемещения, а в том, чем себя занять во время полета? В современных лайнерах в спинки кресел установлены телевизоры с разнообразными функциями. В качестве развлечения во время полета можно посмотреть заранее приготовленный фильм на ноутбуке. Лучше всего пользоваться наушниками, ведь в самолете довольно шумно. Кто-то предпочитает спать, а есть люди, кому нравится читать книги во время путешествия. Поговорим же о последней категории людей, тех, кто предпочитает книгу всему остальному.

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

kniga

Практически все авиакомпании мира сейчас вкладывают развлекательные журналы в карманы впереди стоящего кресла. Это позволяет пассажирам не сильно волноваться, чем занять себя в полете. Конечно, для компаний это отличная возможность дать максимально полезную информацию для туристов о том или ином направлении и разрекламировать именно свою авиакомпанию.

Многие пассажиры остаются преданны именно книгам и заранее прихватят с собой легкий роман или детектив, чтобы мысли были отвлечены героями рассказа. И тут возникает вопрос, так что же лучше? Бортовой журнал с красивыми картинками и красочными разворотами или полюбившийся детективный роман? Если вы выбираете роман, то стоит вам напомнить, что книга всегда имела вес, в прямом и переносном смысле, некоторые из них бывают очень тяжелы. А если вы читаете быстро, то и книг с собой нужно брать больше. От этого ваша ручная кладь может вырастить в весе и объеме. Увы, это тот самый весомый аргумент, который у вас всегда будет возникать, если вы собираетесь в отпуск.

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

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

Каждый из нас сам делает выбор, чем заняться во время перелета, но чтение книг или журналов делает перелет менее утомительным и позволяет вам немного отвлечься. Легкого Вам взлета!

Рекомендуем взять в дорогу:

1. "Щегол", Донна Тартт

2. "Монах, который продал свой "феррари", Робин С. Шарма

3. "Заир", Пауло Коэльо

4. "Обитель", Захар Прилепин

5. "Игра престолов", Джордж Рэймонд Ричард Мартин

www.airinme.com