Технический инспектор по EASA CS-FSTD(A) Issue 2: квалификация и надзор за FSTD

Нормативная база CS-FSTD(A) Issue 2 и роли участников

Зачем техническому инспектору понимать нормативную систему

Технический инспектор по FSTD (Flight Simulation Training Device, средство имитации полёта для обучения) работает не только с «железом» и моделями, но и с системой требований, которая определяет:

что именно считается приемлемым уровнем соответствия для конкретного типа FSTD;

кто имеет полномочия квалифицировать устройство и надзирать за ним;

какие доказательства должны быть предоставлены (документы, тесты, отчёты, записи);

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

Эта статья задаёт терминологию и «карту» ролей/документов. В следующих темах курса эти элементы будут использоваться как базовые опорные понятия при разборе процессов квалификации, оценок, QTG и управления конфигурацией.

Что такое CS-FSTD(A) Issue 2 и где оно находится в иерархии документов

Определения, без которых дальше нельзя

FSTD — Flight Simulation Training Device, обобщённое название тренажёрных средств, используемых в подготовке экипажей.

FSTD(A) — FSTD для самолётов (A = Aeroplanes).

CS — Certification Specifications (сертификационные спецификации): технические спецификации/стандарты, которыми обычно пользуются как «признанным способом» доказать соответствие.

Issue 2 — редакция документа (версия требований).

QTG — Qualification Test Guide: набор квалификационных тестов и эталонных данных/допусков, по которым доказывается соответствие устройством заявленному уровню.

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

Иерархия нормативных источников (упрощённая)

Техническому инспектору важно различать «обязательное право» и «технические способы выполнения».

| Уровень | Что это | Кто издаёт | Для инспектора означает | |---|---|---|---| | Регламенты ЕС (Basic Regulation и др.) | Обязательные правовые нормы | ЕС (EUR-Lex) | Полномочия, обязанности участников, рамки надзора | | Implementing Rules (IR) | Обязательные правила выполнения | Европейская комиссия | Процедуры и требования к организациям/надзору | | AMC/GM | Acceptable Means of Compliance / Guidance Material | EASA | Признанные способы соответствия и разъяснения | | CS (например, CS-FSTD(A)) | Технические спецификации | EASA | Детальные технические требования/критерии для оценки FSTD |

Практический вывод для инспектора:

регламенты и IR — отвечают на вопрос «что обязательно сделать и кто за что отвечает»;

CS и QTG — отвечают на вопрос «какими техническими доказательствами подтверждается соответствие».

!Пирамида источников требований — от законодательства до технических тестов

Ключевые документы, с которыми работает инспектор

Ниже — минимальный набор источников, который должен уметь находить и читать технический инспектор FSTD в контексте EASA.

Регламент (EU) 2018/1139 (Basic Regulation)

Регламент (EU) No 1178/2011 (Aircrew)

CS-FSTD(A) Issue 2

Easy Access Rules for Aircrew (Regulation (EU) No 1178/2011)

Примечание по практике применения: инспектор почти всегда работает с «пакетом» — регламент/IR (как правовая основа надзора), далее AMC/GM (как принятые методы/пояснения), и далее CS-FSTD(A) + QTG (как техническая база проверки).

Объект регулирования: какие устройства попадают под CS-FSTD(A)

CS-FSTD(A) описывает технические требования к квалификации самолётных FSTD и принципы подтверждения соответствия через испытания/оценки.

На практике в поле зрения инспектора чаще всего попадают устройства классов/типов, используемых в подготовке по программам ATO, например:

FFS (Full Flight Simulator) — полнофункциональный симулятор полёта;

FTD (Flight Training Device) — тренажёр для обучения полёту (как правило, с меньшей «полнотой» по сравнению с FFS);

FNPT (Flight and Navigation Procedures Trainer) — тренажёр процедур полёта и навигации.

Точный перечень и границы применимости определяются требованиями Aircrew/AMC/GM и конкретным контекстом квалификации. Для инспектора важно не «угадывать» тип, а опираться на:

заявленный оператором уровень квалификации;

состав функций и конфигурацию устройства;

соответствующие разделы CS-FSTD(A) и QTG.

Роли участников и распределение ответственности

Ключевой принцип

Один и тот же FSTD может использоваться в обучении только тогда, когда:

оператор обеспечивает техническую и документальную готовность устройства;

компетентный орган проводит оценку/надзор и принимает решение о квалификации/продлении/ограничениях;

все изменения управляются так, чтобы сохранялась доказанная эквивалентность заявленному уровню.

Участники и их роли

#### EASA EASA в контексте CS-FSTD(A) выступает как разработчик технической базы (CS, AMC/GM), а также как источник разъяснений через публикации и обновления.

Практическая роль для инспектора:

понимать, что CS-FSTD(A) — это «язык» технической проверки;

отслеживать обновления редакций (Issue) и переходные ожидания (если применимо в вашем государстве/органе).

#### Компетентный орган (NAA/CA) Компетентный орган государства-члена (или уполномоченная структура) — это сторона, которая:

проводит оценку (evaluation) FSTD;

принимает решение о квалификации и её условиях (уровень, ограничения, срок, требования к поддержанию);

осуществляет надзор (surveillance), включая периодические проверки, оценку изменений, анализ событий/отказов.

Для технического инспектора компетентного органа это означает ответственность за:

планирование и проведение технической оценки по CS-FSTD(A);

проверку полноты и качества доказательств (включая QTG/отчёты);

фиксирование выводов, несоответствий и условий/ограничений квалификации.

#### Оператор FSTD Оператор — организация, которая владеет/эксплуатирует FSTD и отвечает за его пригодность для обучения.

Типовые обязанности оператора (в контексте ожиданий инспектора):

поддержание устройства в утверждённой/квалифицированной конфигурации;

обеспечение выполнения тестов и ведения QTG/отчётности;

управление изменениями (техническими и программными) и уведомление/согласование с компетентным органом;

обеспечение компетентности персонала, процедур и записей.

#### ATO и пользователи тренажёра ATO (Approved Training Organisation) использует FSTD как часть утверждённых программ подготовки. В зависимости от национальной модели, ATO может быть оператором FSTD или отдельной организацией.

Зона внимания инспектора:

соответствие использования FSTD установленным условиям квалификации (например, какие упражнения/кредиты допускаются);

наличие корректных процедур использования (брифинги, ограничения, отчётность о неисправностях, применение MEL/эквивалентных правил, если это предусмотрено внутренними процедурами).

#### Производитель/поставщик FSTD и OEM Производитель тренажёра и/или OEM (производитель самолёта/компонентов/авионики) участвуют через:

предоставление эталонных данных (в том числе аэродинамика, системы, лётные характеристики — в объёме, допустимом по правам/конфиденциальности);

техническую поддержку по аппаратной/программной части;

выпуск бюллетеней и обновлений.

Важно: наличие «данных от OEM» не заменяет оценку компетентным органом — это лишь часть доказательной базы.

#### Персонал, вовлечённый в квалификацию и поддержание

Инженер/техник FSTD — поддерживает конфигурацию, ведёт диагностику, обеспечивает воспроизводимость тестов.

Специалист по моделям/ПО — отвечает за корректность математических моделей, интеграции обновлений, управление версиями.

Инструкторы/экзаменаторы — важный источник обратной связи: выявляют отклонения поведения устройства от ожидаемого в реальной эксплуатации.

Для инспектора это означает, что оценка — не только «пройти QTG», но и проверить, что у оператора есть люди и процессы, способные удерживать устройство в требуемом состоянии.

!Кто с кем взаимодействует при квалификации и надзоре за FSTD

Роль технического инспектора: границы полномочий и типовые артефакты

Что делает технический инспектор

В терминах практики надзора задача технического инспектора — обеспечить обоснованное решение компетентного органа на основе:

объективных доказательств (QTG-результаты, записи, конфигурационные отчёты);

технических проверок (инспекция, наблюдение выполнения тестов, выборочные проверки, анализ отклонений);

оценки процессов оператора (управление изменениями, дефектами, версиями ПО/моделей).

Чем инспектор обычно оперирует (документы/записи)

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

Заявка/пакет на квалификацию или продление

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

QTG (структура тестов, эталонные данные, допуски, результаты прогонов)

Отчёты об отклонениях и корректирующих действиях

Записи о версиях, изменениях, обновлениях и их влиянии

Журналы неисправностей и технического обслуживания

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

Как CS-FSTD(A) связывается с процессами квалификации и надзора

Даже не углубляясь в конкретные тесты Issue 2, полезно зафиксировать логическую связку:

Оператор заявляет уровень/тип квалификации и предоставляет доказательную базу (включая QTG).

Компетентный орган планирует оценку: что проверять документально, что наблюдать «вживую», какие тесты выбрать выборочно.

По результатам оценки принимается решение: квалификация/продление/ограничения/условия.

Далее идёт период надзора и управление изменениями.

В этой цепочке CS-FSTD(A) Issue 2 играет роль технического эталона: какие характеристики и функции должны быть подтверждены и каким образом это обычно доказывается.

Типовые риски неправильного понимания нормативной базы

Путаница между правовым обязательством (регламенты/IR) и техническим способом соответствия (CS, AMC).

Оценка «только по бумаге» без понимания, что квалификация относится к конкретной конфигурации устройства.

Сведение оценки к «прохождению QTG», без проверки, что процессы оператора способны поддерживать результат во времени.

Недооценка роли ATO/пользователей как источника эксплуатационных отклонений (особенно по системам/авионике/визуальным эффектам).

Итоги

CS-FSTD(A) Issue 2 — ключевой технический документ EASA для квалификации самолётных FSTD.

Инспектор должен уверенно ориентироваться в иерархии: регламент ЕС → implementing rules → AMC/GM → CS → QTG/записи.

Квалификация — это не только тесты, но и проверка процессов, конфигурации и управляемости изменений.

Роли (EASA, компетентный орган, оператор, ATO, производители, персонал) дополняют друг друга; ответственность за результат распределена, но решение о квалификации принимает компетентный орган.

Классы и уровни квалификации FSTD: критерии и ограничения

Как эта тема связана с нормативной базой и ролями участников

В предыдущей статье мы зафиксировали, что технический инспектор принимает решения не «по ощущениям», а опираясь на нормативную систему регламент/IR → AMC/GM → CS → QTG и записи. В этой статье мы разберём, какие именно классы и уровни квалификации FSTD существуют в логике EASA для самолётных устройств и как инспектор читает уровень квалификации: через критерии соответствия и ограничения применения.

Ключевая идея: уровень квалификации — это не «маркетинговый класс тренажёра», а формализованный объём доказанной пригодности, привязанный к конкретной конфигурации и подтверждённый тестами/оценкой.

Нормативные опорные документы, к которым вы будете возвращаться при проверках:

CS-FSTD(A) Issue 2 (страница документа EASA)

Регламент (EU) No 1178/2011 Aircrew (EUR-Lex)

Термины: что означает «класс», «уровень» и «ограничение»

Класс FSTD — тип устройства по назначению и составу функций (например, FFS, FTD, FNPT, BITD).

Уровень квалификации — градация внутри класса, показывающая глубину доказанного соответствия (например, FFS Level D vs Level C).

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

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

Для инспектора важно разделять:

что заявлено (класс/уровень, область применения, опции);

что доказано (через QTG, результаты, анализ отклонений);

что разрешено использовать (через условия/ограничения квалификации и связь с правилами Aircrew).

«Лестница реалистичности»: основные классы FSTD в EASA (самолёты)

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

| Класс | Для чего обычно используется | Суть отличия для инспектора | Тип доказательств (упрощённо) | |---|---|---|---| | BITD (Basic Instrument Training Device) | Базовая приборная подготовка | Ограниченный набор систем/динамики | Базовые проверки функций и процедур, ограниченный QTG | | FNPT (Flight and Navigation Procedures Trainer) | Процедуры, навигация, CRM/MCC (в зависимости от исполнения) | Акцент на процедурности и тренировки задач, а не на полном полётном реализме | Существенная часть проверок — функциональность, процедурность, устойчивость конфигурации | | FTD (Flight Training Device) | Тренировка систем/авионики/процедур на более высоком уровне соответствия | Повышенные ожидания к системной логике и кабине; не обязательно полный полётный реализм FFS | Комбинация функциональных и (в определённом объёме) динамических тестов | | FFS (Full Flight Simulator) | Полный цикл тренировки с высоким уровнем реализма, включая сложные режимы | Наиболее строгие требования к аэродинамике, системам, визуализации, (как правило) motion и др. | Полный набор квалификационных тестов (QTG) + оценка поведения/эффектов |

Важно: класс не равен уровню. Например, FTD высокого уровня может быть «сильнее» по системам, чем FNPT, но всё равно не является FFS, потому что не доказывает полный набор требований к реалистичности полёта.

!Наглядно показывает, что повышение класса/уровня обычно означает рост доказанности по нескольким областям одновременно

Уровни квалификации: зачем они нужны и что именно «растёт» с уровнем

Логика уровней в EASA нужна, чтобы:

связать права зачёта обучения/проверок с доказанными характеристиками устройства;

стандартизировать ожидания к тестам и допускам;

формализовать ограничения (например, «разрешено для процедур, но не для кредитования определённых упражнений»).

С ростом уровня обычно увеличивается:

глубина и точность валидации динамики полёта и характеристик управления;

полнота и достоверность моделирования систем и отказов;

требования к визуальным/аудио/вибрационным эффектам и их влиянию на обучение;

объём объективных тестов (с эталонными данными и допусками) и строгость допусков;

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

Для инспектора это означает: нельзя «поднять уровень» декларативно — уровень поднимается только после того, как доказательная база (QTG + оценка) подтверждает соответствие более строгим критериям.

Примерная структура уровней для FFS: как читать «Level A–D»

На практике в авиации часто говорят «FFS Level D» как о «верхней ступени». Инспектору важнее другое: какие элементы реализма доказаны и какими тестами.

Обобщённо (без подмены текста CS):

FFS Level A — базовая полнота функциональности и процедурности, ограниченная глубина требований к некоторым эффектам.

FFS Level B — более строгие ожидания по ряду динамических и системных характеристик.

FFS Level C — высокая степень реалистичности, включая расширенные требования к визуализации и поведению.

FFS Level D — максимальная полнота набора требований, включая наиболее строгие ожидания к реалистичности поведения и эффектов (в пределах применимых требований CS и доказательной базы).

Практический ориентир для инспектора:

уровень FFS — это не только «про motion» и не только «про визуалку»;

итоговый уровень определяется совокупностью соответствий по нескольким техническим доменам и качеством доказательств.

Уровни для FTD и FNPT: типовая логика различий

Без привязки к «зубрежке» отдельных пунктов CS полезно держать в голове различие философии:

FTD обычно «растёт» по уровню через точность и полноту систем/авионики/кабины и доказанность соответствий, включая отказные режимы.

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

Для инспектора критично не спутать:

«устройство удобно для обучения» (мнение пользователей),

с «устройство квалифицировано для зачёта конкретных элементов программы» (формальный результат оценки).

Критерии соответствия: из чего инспектор собирает картину «подходит/не подходит»

Домены соответствия, которые почти всегда проверяются

Техническая оценка обычно раскладывается по доменам (с разной глубиной в зависимости от класса/уровня):

Кабина и органы управления: компоновка, индикация, логика взаимодействия.

Системы и авионика: нормальная и отказная работа, логика режимов, предупреждения.

Лётная динамика: устойчивость/управляемость, режимы, отклики, характеристики.

Визуальная система: поле зрения, сцены, ограничения по условиям, синхронизация.

Motion и ощущения (если применимо): качество сигналов, согласование с динамикой.

Инструкторская станция и управление сессией: сценарии, ввод отказов, записи.

Временная согласованность и задержки: лаги управления/индикации, синхронизация подсистем.

Объективные и субъективные элементы

Инспектор обычно видит два типа подтверждений:

Объективные: измеряемые тесты с эталонными данными и допусками (ядро QTG).

Субъективные: оценка поведения/эффектов специалистами (например, «похоже ли» поведение на ожидаемое), обычно как дополнение, а не замена объективных тестов.

Практический вывод: если спор возникает на уровне «кажется/не кажется», инспектор возвращает обсуждение к вопросу какой тест, какие эталонные данные, какой допуск и какой результат.

Ограничения квалификации: какие бывают и почему они важны

Ограничения — это нормальная часть квалификации. Они защищают безопасность и корректность зачёта обучения.

Типовые категории ограничений

По конфигурации: конкретная версия ПО/моделей, состав авионики, тип двигателей, стандарты баз данных.

По области использования: какие упражнения/части программы можно засчитывать, какие — нет.

По условиям среды: погода/освещённость/видимость, ограничения визуальных сцен.

По функциональности: запрет на использование некоторых режимов/отказов для зачёта, если они не доказаны.

По техническому состоянию: временные ограничения при определённых известных дефектах (если допускается внутренними процедурами и не противоречит условиям квалификации).

Как инспектор проверяет, что ограничения «живут» в эксплуатации

Недостаточно написать ограничения в документе. Инспектор обычно ищет подтверждение в том, что:

ограничения отражены в процедурах оператора и понятны персоналу;

ограничения соблюдаются в учебном процессе (например, через настройки, запреты, контроль инструктора);

есть механизм выявления случаев использования «за пределами квалификации» и корректирующие действия.

«Тёмные зоны» при определении уровня: частые ошибки в заявках и оценках

Ниже — типовые ситуации, которые приводят к замечаниям при квалификации/надзоре.

Подмена уровня наличием опции: «есть motion/коллимация/новая визуалка, значит Level D». Неверно: важны тесты, допуски, эталонные данные, стабильность.

Смешение конфигураций: часть доказательств относится к одной версии ПО/БД, а фактическая эксплуатация — к другой.

Неявные ограничения: ограничения «живут» в устных договорённостях, но не формализованы в условиях квалификации и процедурах.

Слабый контроль изменений: изменения «незначительные», но их эффект на QTG/соответствие не оценён.

Практический алгоритм инспектора: как читать квалификацию FSTD «как инженер»

Ниже — минимальный порядок вопросов, который помогает быстро оценить корректность заявленного класса/уровня.

Что именно заявлено? Класс, уровень, тип самолёта/вариант, область применения.

Какая конфигурация квалифицирована? Версии ПО/моделей/БД, состав ключевых подсистем.

Где доказательства? Актуальный QTG, результаты прогонов, отчёты по отклонениям.

Как управляются отклонения? Классификация, корректирующие действия, повторные тесты.

Какие ограничения действуют? И как оператор гарантирует их соблюдение.

Что изменилось с последней оценки? И есть ли оценка влияния изменений.

Этот алгоритм прямо продолжает рамку из первой статьи: квалификация — это не событие «сдали тесты», а состояние, поддерживаемое процессами и контролем конфигурации.

Итоги

Класс FSTD определяет назначение устройства (BITD/FNPT/FTD/FFS), а уровень — глубину доказанного соответствия внутри класса.

Рост уровня означает рост требований к доказанности по нескольким доменам: динамика, системы, кабина, визуализация, (при применимости) motion, а также к воспроизводимости результатов.

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

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

Процесс инспекции и квалификации: от заявки до выдачи заключения

Как эта статья продолжает курс

В первых двух статьях мы закрепили два ключевых ориентира для технического инспектора:

нормативная «пирамида» регламент/IR → AMC/GM → CS → QTG и записи и роли участников;

различие между классом/уровнем квалификации FSTD и ограничениями, которые определяют допустимое применение в обучении.

Теперь мы соединяем это в один практический процесс: как компетентный орган (и его технический инспектор) проходит путь от заявки оператора до заключения и решения по квалификации, опираясь на CS-FSTD(A) Issue 2 и доказательства в виде QTG и сопровождающей документации.

Опорные источники (для ориентира и поиска первоисточников):

CS-FSTD(A) Issue 2

Regulation (EU) 2018/1139

Regulation (EU) No 1178/2011 (Aircrew)

Участники процесса и что считается результатом

Кто что делает

Оператор FSTD готовит заявку, обеспечивает доступ к устройству, персоналу и данным, выполняет QTG и предоставляет записи.

Компетентный орган организует оценку и принимает решение о квалификации/продлении/изменении условий.

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

Что является «выходом» процесса

В зависимости от ситуации результатом может быть:

выдача или продление квалификации с указанным классом/уровнем и условиями/ограничениями;

выдача квалификации с условиями (например, обязательные корректирующие действия к сроку);

отказ или приостановка до устранения критичных несоответствий;

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

Общая схема процесса: от намерения до решения

!Блок-схема, показывающая этапы, входы и выходы процесса квалификации

Ниже — разбор каждого этапа с позиции технического инспектора: что проверять, какие доказательства ожидать, какие типовые ошибки встречаются.

Предзаявочный этап: подготовка оператора и «правильная заявка»

На практике качество и длительность оценки определяются тем, насколько оператор подготовил:

конфигурацию FSTD как однозначно описанный объект;

доказательства соответствия (QTG, эталонные данные, допуски, результаты);

процессы поддержания (управление изменениями, дефектами, версиями, записями).

Зона внимания инспектора на этом этапе (часто в форме предварительных консультаций):

заявленный класс/уровень реалистичен относительно оснащения и данных;

понятно, какая именно конфигурация будет оцениваться (версии ПО/моделей/баз данных, состав кабины, визуализация, motion, авионика);

известны планируемые «сложные зоны»: обновления, переход на другой стандарт базы данных, изменения визуальной системы, замена оборудования.

Типовой риск: оператор «приносит» QTG, который относится к другой конфигурации, либо не может воспроизвести тесты из-за неполной управляемости версий.

Подача заявки и проверка полноты пакета

Цель этапа

Подтвердить, что пакет документов достаточен, чтобы начать техническую оценку без потери времени на догадки.

Что инспектор ожидает увидеть в пакете (минимально)

описание FSTD: класс/уровень, тип ВС/вариант, состав систем и опций;

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

QTG с эталонными данными, допусками, процедурами выполнения тестов и актуальными результатами прогонов;

перечень известных отклонений (если есть) и их статус;

процедуры оператора по:

- управлению изменениями; - ведению записей; - обработке дефектов и допусков к эксплуатации для обучения.

Практическая проверка полноты: инспектор должен уметь ответить на два вопроса:

что именно будет проверяться как объект квалификации (конфигурация);

чем подтверждается соответствие (структурированные доказательства).

Планирование оценки: что, где и как проверять

На этом этапе технический инспектор формирует план оценки: объём документарной проверки, объём очной инспекции, какие тесты будут свидетельствоваться.

Принципы риск-ориентированного планирования

Факторы, которые обычно увеличивают объём проверки:

заявка на более высокий уровень (например, в рамках класса FFS);

существенные изменения с прошлой квалификации (визуализация, motion, ядро модели, авионика);

недостатки в истории соответствия (повторяющиеся отклонения, слабые записи);

наличие ограничений, которые сложно контролировать в эксплуатации;

«слабые места» в данных (непрозрачное происхождение эталонных данных, устаревшие базы).

Артефакты этапа

план оценки/инспекции;

перечень требуемых демонстраций и выборочных тестов;

согласованный график и список ответственных лиц со стороны оператора.

Документарная оценка: проверка доказательств до выезда

Документарная оценка снижает риск того, что очная часть превратится в «разбор документов на месте».

Что именно проверяется в QTG и сопутствующих материалах

полнота структуры QTG для заявленного класса/уровня;

наличие:

- эталонных данных; - допусков; - процедур выполнения тестов; - результатов прогонов;

прослеживаемость: каждый результат должен быть привязан к версии конфигурации;

управление отклонениями:

- классификация; - обоснование допустимости; - корректирующие действия; - повторные тесты при необходимости.

Признаки проблем в доказательной базе

«идеальные» результаты без истории повторов и разброса там, где ожидаема статистическая вариативность (может быть признаком ручной подгонки или неверной методики);

эталонные данные без ясного происхождения и применимости к варианту ВС;

результаты тестов, выполненные в одной версии ПО, при фактической эксплуатации в другой.

Очная оценка (on-site): инспекция конфигурации и процессов

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

Блоки, которые обычно проверяются на месте

идентификация конфигурации:

- версии ПО/моделей/баз данных; - состав аппаратуры; - серийные номера/идентификаторы ключевых модулей (если применимо);

процедуры оператора:

- кто имеет право менять конфигурацию; - как фиксируются изменения; - как принимается решение о необходимости повторных тестов;

журналы и записи:

- дефекты, простои, временные ограничения; - результаты периодических прогонов QTG;

готовность к демонстрациям:

- доступность эталонных данных; - воспроизводимость условий теста; - компетентность персонала, выполняющего тесты.

Практический критерий

Инспектор должен суметь связать цепочку:

текущая конфигурация → какие доказательства относятся именно к ней → как оператор предотвращает незаметное «уползание» конфигурации.

Свидетельствование тестов: как инспектор наблюдает выполнение QTG

Цель свидетельствования

Не «пересдать QTG за оператора», а убедиться, что:

тесты выполняются по процедурам;

результаты воспроизводимы;

измерения/сбор данных корректны;

отклонения фиксируются честно и управляются по правилам.

Типовые действия инспектора при наблюдении тестов

выборочная проверка критичных тестов (обычно на динамику, системы, задержки/синхронизацию, визуальные эффекты — в зависимости от класса/уровня);

проверка исходных условий теста (масса, центровка, конфигурация самолёта, атмосфера, настройки FSTD);

наблюдение за тем, как система регистрирует параметры и как формируется отчёт;

проверка, что оператор не использует «обходные» методики, которые улучшают цифры, но ухудшают реализм.

Что считать корректным результатом

Корректный результат — это не только «в допуске», но и:

привязан к конкретной версии конфигурации;

повторяем при повторном прогоне;

интерпретирован без подмены критериев (например, без несанкционированной фильтрации данных).

Несоответствия и корректирующие действия: как оформлять и закрывать

Зачем формализовать несоответствия

Формализация нужна, чтобы решение по квалификации было:

прослеживаемым;

воспроизводимым;

юридически и технически защищённым.

Типовая логика работы с несоответствиями

фиксация факта и ссылки на требование/критерий, относительно которого возникло отклонение;

оценка влияния:

- на безопасность обучения; - на допустимость зачёта упражнений; - на стабильность соответствия;

определение действий:

- корректирующее действие (изменить модель/ПО/оборудование/процедуру); - компенсирующая мера (временное ограничение применения); - повторное тестирование (какие тесты и в каких условиях);

критерий закрытия: какие доказательства считаются достаточными.

Важное практическое правило

Если отклонение влияет на область применения, инспектор должен требовать, чтобы это отражалось как ограничение квалификации и было внедрено в эксплуатационные процедуры оператора, а не оставалось «знанием инженеров».

Итоговый отчёт технического инспектора: структура и качество

Хороший отчёт — это документ, по которому другой инспектор сможет понять логику решения.

Рекомендуемая структура

объект оценки (класс/уровень, тип ВС/вариант, место установки);

идентификация конфигурации (версии и состав);

объём выполненной оценки (документы, интервью, инспекция, наблюдённые тесты);

сводка результатов:

- какие области соответствуют; - какие отклонения приняты с обоснованием; - какие несоответствия выявлены;

условия и ограничения квалификации (если применимо);

рекомендации по решению (выдать/продлить/ограничить/отложить до устранения).

Частая ошибка отчётов

Фраза уровня «в целом соответствует» без привязки к:

конкретной конфигурации;

конкретным тестам/результатам;

конкретным ограничениям и механизму их соблюдения.

Решение компетентного органа и выдача заключения

Технический инспектор обычно не «выдаёт квалификацию» сам по себе, но его отчёт является основой решения.

Что должно быть однозначно указано в заключении/сертификате

класс и уровень квалификации;

идентификация FSTD и его конфигурации;

срок действия и условия продления (по применимым правилам);

ограничения:

- по применению в обучении/проверках; - по конфигурации; - по среде/сценам/режимам (если применимо);

требования к поддержанию (например, периодичность тестов/отчётности — в рамках принятой системы надзора компетентного органа).

Сводная таблица: этапы, входы, действия инспектора, выходы

| Этап | Основные входы | Ключевые действия инспектора | Основные выходы | |---|---|---|---| | Предзаявочная подготовка | черновое описание конфигурации, намерение по уровню | выявление риск-зон, согласование ожиданий | перечень ожиданий и предварительных требований | | Подача заявки | пакет документов, QTG | проверка полноты и пригодности | подтверждение приёма, запросы на уточнение | | Планирование | история устройства, изменения, риски | план оценки и выборка тестов | план оценки/график | | Документарная оценка | QTG, эталонные данные, записи | анализ прослеживаемости, отклонений, процедур | замечания к документам, список вопросов | | Очная инспекция | доступ к FSTD, персоналу, журналам | проверка конфигурации и процессов | протоколы инспекции | | Свидетельствование тестов | тестовые процедуры и инструменты | наблюдение критичных тестов и методик | протоколы наблюдения, выявленные несоответствия | | Корректирующие действия | план CAPA, повторные тесты | проверка достаточности и закрытия | закрытие/эскалация замечаний | | Отчёт инспектора | все результаты оценки | формирование выводов и рекомендаций | технический отчёт | | Решение и заключение | отчёт + административные материалы | финальная проверка формулировок условий | квалификация/продление/ограничения/отказ |

Типовые «красные флаги» для инспектора

несоответствие между заявленным уровнем и фактически доказанным объёмом (мало эталонных данных, неполный QTG, слабая воспроизводимость);

отсутствие управляемости конфигурации: «мы не уверены, какая версия стоит сейчас»;

ограничения существуют, но не внедрены в эксплуатацию (инструкторы о них не знают, нет контроля);

результаты QTG «в допуске», но методика измерений/условия теста не соответствуют процедурам;

изменения выполняются как «незначительные», но без оценки влияния на тесты и соответствие.

Итоги

Процесс квалификации FSTD — это управляемая цепочка: заявка → план оценки → документарная проверка → очная инспекция и свидетельствование тестов → работа с несоответствиями → отчёт → решение и условия квалификации.

Центральный объект проверки для технического инспектора — конкретная конфигурация FSTD и прослеживаемые доказательства соответствия (прежде всего через QTG и записи).

Ограничения — нормальный инструмент управления риском: они должны быть не только записаны в решении, но и реально соблюдаться в эксплуатации.

Качество отчёта инспектора определяется не объёмом текста, а прослеживаемостью: какие требования проверялись, какими доказательствами, к какой конфигурации это относится и к какому решению приводит.

Технические области оценки: кабина, системы, визуализация, движение, звук, IOS

Зачем инспектору делить оценку FSTD на технические области

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

На практике, чтобы:

не пропускать критичные элементы,

корректно выбирать выборку тестов для свидетельствования,

формулировать ограничения, которые реально можно соблюдать,

технический инспектор раскладывает оценку на технические области (домены). В этой статье мы разберём домены, которые почти всегда входят в оценку по CS-FSTD(A): кабина, системы и авионика, визуализация, движение (motion), звук, IOS (Instructor Operating Station).

Опорный технический источник:

CS-FSTD(A) Issue 2

Нормативный контекст, который определяет, зачем квалификация нужна для применения в подготовке:

Regulation (EU) 2018/1139

Commission Regulation (EU) No 1178/2011 (Aircrew)

Базовый принцип оценки домена

Для каждого домена инспектор отвечает на один и тот же набор вопросов:

Что заявлено оператором (функции, состав оборудования, уровень, опции, ограничения).

Что является конфигурацией именно в этом домене (версии, модели, базы данных, параметры, калибровки).

Какие доказательства соответствия предоставлены (QTG, отчёты, записи, демонстрации).

Как домен удерживается во времени (процедуры, периодические тесты, управление изменениями, журнал дефектов).

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

!Карта доменов оценки и их связь с квалифицированной конфигурацией

Сквозные артефакты: что инспектор обычно запрашивает для всех доменов

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

Описание конфигурации (аппаратная часть и ПО с версиями).

Описание настроек и калибровок, влияющих на поведение.

QTG: тесты, допуски, эталонные данные, результаты.

Перечень открытых отклонений и статус корректирующих действий.

Журналы дефектов и простоя.

Процедуры управления изменениями и критерии повторного тестирования.

Кабина: геометрия, органы управления, индикация, эргономика

Что считается объектом оценки в домене кабины

Кабина в контексте оценки FSTD включает не только внешний вид, но и функциональную и эксплуатационную совместимость с задачами подготовки.

Компоновка рабочих мест и доступность органов управления.

Типы и тактильные характеристики органов управления (там, где применимо).

Работоспособность индикации и её читаемость.

Соответствие логики переключателей ожидаемому поведению систем.

Наличие несогласованностей, способных вызвать неправильные навыки.

На что инспектор смотрит в документах и на месте

Идентификация оборудования (модификации панели, типы дисплеев, конфигурация сидений).

Наличие перечня отличий кабины от самолёта (если отличия допустимы по уровню и компенсированы ограничениями).

Наличие процедур контроля работоспособности кабины перед занятием.

Типовые риски и причины несоответствий

Неявные отличия в расположении или направлении работы органов управления.

Несогласованность маркировки с фактической логикой.

Латентные дефекты ввода (шум, дребезг, неверная зона нечувствительности), влияющие на прохождение QTG и субъективную оценку.

Примеры ограничений, связанных с кабиной

Ограничение на выполнение отдельных упражнений, если орган управления работает иначе, чем в самолёте.

Запрет на зачёт элементов, требующих точного соответствия компоновки (если это критично для конкретной программы).

Системы и авионика: функциональность, режимы, отказы, предупреждения

Что включает домен систем

Под системами и авионикой обычно понимают:

логику работы систем самолёта и взаимодействия систем между собой,

режимы автоматики и индикацию,

предупреждения, сигналы и сообщения экипажу,

отказные режимы и поведение при деградации.

Как инспектор проверяет доказательства

В этом домене особенно важно различать:

демонстрацию функции (она включилась),

и доказательство корректности (она включилась с правильной логикой, при правильных условиях, с правильной индикацией).

Инспектор обычно проверяет:

прослеживаемость тестов QTG к версии авионики и баз данных,

полноту матрицы отказов (что реализовано, что запрещено к использованию, что ограничено),

наличие процедур контроля корректности после обновлений.

Типовые слабые места

Частичные реализации логики (функция работает в типовом сценарии, но неверна в пограничных условиях).

Несогласованность между моделированием системы и индикацией.

Отличия в приоритизации предупреждений и сообщений.

Неуправляемые изменения: обновили компонент авионики, а набор повторных тестов выбран слишком узко.

Практика формулирования ограничений

Если корректность отдельных отказов или режимов не доказана, инспектору важно добиваться, чтобы ограничение было:

однозначным для инструктора,

контролируемым (через запрет выбора отказа в IOS или через процедуру),

отражённым в документах оператора.

Визуализация: поле зрения, сцены, освещение, согласованность с задачами

Что инспектор оценивает в визуальной системе

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

Поле зрения и геометрия изображения.

Качество и корректность сцен (аэродромы, рельеф, ориентиры).

Освещение, погодные эффекты и их применимость.

Временная согласованность изображения с динамикой и движением.

Критичные вопросы конфигурации

Какая версия базы визуальных сцен установлена.

Какие обновления выполнялись с последней квалификации.

Какая конфигурация проекторов, каналов, калибровок и коррекции геометрии применяется.

Типовые риски

Несоответствие сцены заявленному аэродрому или процедурам.

Несогласованность видимости/освещения с ожидаемыми тренировочными задачами.

Задержки или рассинхронизация между визуальным каналом и другими подсистемами.

Часто встречающиеся ограничения по визуализации

Ограничение по условиям (например, запрет на зачёт задач, зависящих от определённых эффектов, если они не доказаны).

Ограничение по перечню аэродромов/сцен.

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

Движение (motion): сигналы, согласование, безопасность и воспроизводимость

Что относится к домену motion

Если FSTD оснащён системой движения, инспектор рассматривает её как домен с высоким риском, потому что здесь сочетаются:

влияние на восприятие экипажа,

возможность формирования неправильных навыков,

требования безопасности (аппаратные и процедурные).

Оцениваются:

корректность и согласованность сигналов движения с динамикой,

повторяемость,

отсутствие опасных режимов,

процедуры обслуживания и проверки.

На что инспектор смотрит при инспекции

Идентификация конфигурации motion (ПО, параметры настройки, профили фильтров).

Наличие процедур безопасного запуска/остановки и аварийного прекращения движения.

Записи о техническом обслуживании, калибровках, инцидентах.

Типовые несоответствия

Согласование «в среднем хорошее», но с ошибками на критичных переходных процессах.

Скрытые изменения параметров настройки без формального контроля.

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

Ограничения по motion

Временное ограничение по применению для конкретных упражнений до выполнения корректирующих действий.

Ограничение по режимам (например, запрет на отдельные профили motion, если их корректность не доказана и они доступны инструктору).

Звук: ауральные подсказки, предупреждения, окружение

Почему звук является отдельным доменом

Звук в FSTD влияет на:

распознавание режимов работы,

корректность реакции на предупреждения,

рабочую нагрузку и ситуационную осведомлённость.

В оценке важны:

наличие и корректность предупреждений,

различимость сигналов,

соответствие уровней и логики включения (в рамках применимых критериев).

Типовые проблемы

Предупреждение есть, но с неправильным приоритетом или задержкой.

Несоответствие каналов (звук приходит не в тот гарнитурный/кабинный канал).

Конфликты после обновлений аудиоподсистемы.

Примеры ограничений

Запрет на зачёт упражнений, завязанных на конкретные предупреждения, если их корректность не доказана.

IOS (Instructor Operating Station): управление сессией, отказы, записи, контроль ограничений

Роль IOS в квалификации и надзоре

IOS для инспектора важен не как удобство инструктора, а как средство управляемости FSTD:

какие отказы и условия инструктор может вводить,

как фиксируются события и конфигурация занятия,

как предотвращается использование за пределами квалификации.

Что проверять в IOS

Идентификация версии IOS и интеграции с подсистемами.

Полнота и корректность библиотеки отказов.

Наличие журналирования: что именно записывается и как это используется для расследования отклонений.

Наличие механизмов контроля ограничений (например, запрет выбора определённых отказов или режимов).

Типовые риски

IOS позволяет вводить сценарии, которые выглядят правдоподобно, но не соответствуют доказанным моделям.

Нет надёжной фиксации того, какие отказы вводились на занятии.

Инструкторы обходят ограничения через нестандартные комбинации отказов.

Взаимодействие доменов: почему нельзя оценивать их изолированно

FSTD обычно не «проваливается» по одному домену в чистом виде. Чаще проблема проявляется на стыках.

Наиболее важные стыки для инспектора

Системы ↔ IOS: IOS должен вводить отказы так, чтобы системы отрабатывали корректно, а факт ввода фиксировался.

Динамика ↔ Motion ↔ Визуализация: рассинхронизация или задержки дают неправильные сенсорные подсказки.

Системы ↔ Звук ↔ Индикация: предупреждение должно совпадать по условиям, времени и приоритету с индикацией.

Практический приём для свидетельствования

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

Мини-чек-лист инспектора по доменам (для планирования и on-site)

| Домен | Что идентифицировать в конфигурации | Что чаще всего свидетельствовать | Типовые причины ограничений | |---|---|---|---| | Кабина | состав панелей, дисплеев, интерфейсы ввода | выборочные проверки органов управления и индикации в сценарии | эргономические отличия, вводные дефекты, несоответствие маркировки | | Системы/авионика | версия моделей, авионики, баз данных | критичные режимы и отказы, предупреждения | неполная логика режимов, спорные отказы, отсутствие прослеживаемости | | Визуализация | версия сцены, калибровки, конфигурация каналов | сцены/условия, завязанные на упражнение | ограничения по аэродромам, эффектам, условиям | | Motion | версия ПО, параметры профилей, калибровки | тесты на согласование и повторяемость | деградация, неуправляемые изменения параметров | | Звук | конфигурация каналов, версии библиотек/ПО | ключевые предупреждения и их логика | неправильные приоритеты, задержки, неполная реализация | | IOS | версия IOS, библиотека отказов, журналирование | ввод отказов и проверка записей | отсутствие контроля ограничений, нет записей, обход ограничений |

Как домены отражаются в итоговом отчёте инспектора

Чтобы отчёт поддерживал решение компетентного органа (и был пригоден для надзора), по каждому домену целесообразно фиксировать:

Какая конфигурация проверялась (версия и состав).

Какие доказательства рассматривались (QTG, записи, демонстрации).

Какие отклонения выявлены и как они управляются.

Какие ограничения требуются и как оператор обеспечивает их соблюдение.

Итоги

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

По каждому домену важны три вещи: идентификация конфигурации, прослеживаемые доказательства, удержание соответствия во времени.

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

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

QTG, валидационные тесты, документация и непрерывный надзор

Зачем техническому инспектору «держаться за QTG»

В предыдущих статьях курса мы выстроили основу работы инспектора:

нормативная логика правила → CS → доказательства;

классы/уровни квалификации и ограничения;

процесс оценки от заявки до заключения;

домены оценки (кабина, системы, визуализация, motion, звук, IOS).

QTG (Qualification Test Guide) — центральный технический артефакт, который соединяет всё это в проверяемую цепочку: какая конфигурация заявлена → какие требования применимы → какими тестами доказано соответствие → какие результаты получены → какие отклонения приняты и почему.

Опорный документ курса:

CS-FSTD(A) Issue 2 (EASA)

Нормативный контекст применения FSTD в подготовке:

Regulation (EU) 2018/1139 (EUR-Lex)

Regulation (EU) No 1178/2011 (Aircrew) (EUR-Lex)

Термины: что мы называем QTG и валидационными тестами

QTG — структурированный документ/пакет, содержащий перечень квалификационных тестов, методики их выполнения, исходные условия, эталонные данные, допуски и результаты.

Валидационный тест — тест, который подтверждает, что модель/подсистема FSTD воспроизводит поведение самолёта или требуемую функцию в пределах установленных допусков.

Эталонные данные — данные, относительно которых сравнивается FSTD (например, данные лётных испытаний, данные OEM, иные обоснованные источники).

Допуск — граница приемлемого отклонения результата FSTD от эталонных данных.

Прослеживаемость — однозначная связь результат теста → тест → эталонные данные → версия конфигурации FSTD.

Ключевая мысль для инспектора: QTG — это не «папка с графиками», а управляемая система доказательств, привязанная к конкретной конфигурации.

Что инспектор должен уметь «прочитать» в QTG

QTG полезно воспринимать как ответ на четыре практических вопроса:

Что именно тестируется (какая характеристика/функция и в каком домене).

Как именно тестируется (методика, исходные условия, измеряемые параметры).

С чем сравнивается (источник эталонных данных и их применимость).

Что получилось и почему это приемлемо (результат, допуск, отклонения и их обоснование).

!Поясняет, как инспектор проверяет прослеживаемость от требования к результату

Типы тестов, которые встречаются в QTG

Внутри QTG обычно есть смесь тестов, потому что разные домены требуют разных способов доказательства.

Объективные тесты

Объективные тесты дают измеряемый результат и обычно являются «ядром» доказательной базы.

Типовые примеры (на уровне логики, без подмены текста CS):

динамика и управление (отклики на ввод, устойчивость, характеристики в режимах);

точность индикации и навигационных параметров;

задержки и синхронизация (управление, индикация, визуализация, motion);

характеристики визуальной системы (геометрия/поле зрения/соответствие сцен — в объёме применимых требований);

функциональные проверки систем с фиксируемыми параметрами.

Функциональные тесты

Их задача — подтвердить, что функция реализована и воспроизводимо работает в заявленных условиях.

Важно для инспектора: функциональный тест сам по себе не доказывает «реализм», если не определены условия, ожидаемый результат и критерий приемлемости.

Субъективные оценки

Субъективные элементы (например, оценка «правдоподобия» поведения) могут дополнять, но не должны подменять объективные доказательства там, где они ожидаются.

Практическое правило: если спор упирается в «кажется», инспектор возвращается к вопросу какой измеряемый критерий применим и где он закреплён.

Как обычно устроен QTG как документ

Ниже — практическая структура, которую инспектору удобно искать в QTG (названия разделов у разных операторов могут отличаться, смысл — тот же).

| Раздел QTG | Что инспектор ищет | Типовые проблемы | |---|---|---| | Идентификация FSTD | тип ВС/вариант, класс/уровень, место установки | несоответствие фактической идентификации на площадке | | Описание конфигурации | версии ПО, модели, базы данных, визуализация, motion, IOS | «размытая» конфигурация, нет версионности, нет дат фиксации | | Матрица тестов | перечень тестов и применимость к уровню | отсутствуют обязательные тесты или есть «дыры» по доменам | | Методики | исходные условия, пошаговое выполнение, параметры записи | «неповторяемые» инструкции, критичные условия не заданы | | Эталонные данные | источник, применимость к варианту, условия получения | неизвестное происхождение, не тот вариант ВС, устаревшие данные | | Допуски | критерии PASS/FAIL, единицы измерения | допуск задан, но не обоснован, либо интерпретируется по-разному | | Результаты | графики/таблицы, дата прогона, подписи | результат не привязан к версии конфигурации | | Отклонения | список DEVIATION, влияние, статус CAPA | отклонения «живут» отдельно и не связаны с ограничениями |

Эталонные данные: применимость важнее «красивого источника»

Инспектор оценивает не только «кто дал данные», но и применимость.

Критичные вопросы:

относится ли эталон к тому же варианту ВС (конфигурация, двигатели, авионика, модификации);

совпадают ли условия (масса, центровка, атмосфера, конфигурация);

описана ли методика получения эталона и его точность;

известна ли версия/дата набора эталонных данных.

Типовой риск: данные формально «от OEM», но относятся к другому стандарту/пакету модификаций, что делает сравнение некорректным.

Допуски и критерии прохождения: что проверяет инспектор

Допуск превращает сравнение в управляемое решение: приемлемо или нет.

Инспектор обычно проверяет:

единообразие единиц измерения и осей графиков;

отсутствие «подмены» допусков при обновлениях (например, допуск «расширили», чтобы пройти тест);

логику применения допусков к конкретным условиям;

наличие правил для ситуаций, когда результат «на границе».

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

Выполнение тестов: воспроизводимость как предмет контроля

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

Что должно быть контролируемо при прогоне теста

исходные условия (масса, центровка, конфигурации систем, атмосфера);

«чистота» окружения (например, отключены ли посторонние сценарии, не влияющие на запись);

инструменты измерения и регистрации (каналы, частота дискретизации, фильтрация);

повторяемость (что будет, если тест повторить).

Типовые нарушения методики, важные для инспектора

ручная «подгонка» исходных условий до «красивого графика», не предусмотренная процедурой;

несанкционированная фильтрация или усреднение;

выполнение теста при другой версии ПО/модели, чем указано в QTG;

замена теста демонстрацией «на глаз», когда требуются объективные данные.

Отклонения, допуски, несоответствия: как это должно жить в документах

В работе инспектора важно разделять три сущности:

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

Отклонение (deviation) принято: тест не проходит строго по допуску, но отклонение документировано, оценено по влиянию, имеет ограничения или план корректирующих действий.

Несоответствие (non-compliance): отклонение неприемлемо для заявленного уровня или не имеет достаточного обоснования/контроля.

Хорошая практика для управляемости:

отклонение связано с конкретным тестом QTG;

описано влияние на обучение и на домены;

определено, нужно ли ограничение квалификации;

определён критерий закрытия (что надо исправить и какие тесты повторить).

Пакет документации помимо QTG: что инспектор обычно требует

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

Ниже — типовой набор артефактов, которыми инспектор «закрывает» вопросы конфигурации и надзора:

конфигурационный перечень с версиями (ПО, модели, базы данных, визуализация, IOS, motion);

журнал изменений (что меняли, когда, кто санкционировал, оценка влияния);

журнал дефектов и ограничений эксплуатации для обучения;

записи по калибровкам и настройкам (особенно визуализация, motion, органы управления);

процедуры управления изменениями и критерии выбора повторных тестов;

план и записи периодических прогонов QTG (что прогоняется регулярно и почему);

сведения о компетентности персонала, который выполняет тесты и выпускает отчёты (в объёме процедур оператора).

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

Непрерывный надзор: как QTG превращается в инструмент контроля во времени

Квалификация — это не разовая проверка, а состояние, которое может «разъехаться» из-за изменений и деградации.

Что обычно составляет непрерывный надзор со стороны компетентного органа

периодические оценки (recurrent evaluation) в соответствии с практикой органа и уровнем риска;

выборочное свидетельствование части тестов QTG (особенно после изменений);

проверка процессов оператора: управление конфигурацией, дефектами, ограничениями;

оценка «стыковых» рисков доменов (например, синхронизация визуализация↔motion↔динамика и IOS↔отказы↔системы).

!Показывает, что надзор — это цикл, а QTG является измерительным контуром

Риск-ориентированный подход: когда надзор усиливается

Объём надзора обычно увеличивают:

существенные изменения (ядро модели, авионика, визуализация, motion, IOS);

«плохая история» отклонений или повторяемых дефектов;

рост числа жалоб пользователей на реализм или стабильность;

признаки деградации по трендам QTG;

заявка на повышение уровня квалификации.

Практический критерий достаточности надзора

Надзор можно считать эффективным, если по любой дате эксплуатации инспектор способен проследить:

какая конфигурация стояла;

какие отклонения были открыты;

какие ограничения действовали;

почему устройство считалось пригодным для заявленного применения.

Как инспектор использует QTG на практике: короткий «полевой» алгоритм

Сверить фактическую конфигурацию на площадке с конфигурацией, указанной в QTG.

Выбрать тесты для свидетельствования с упором на рисковые домены и стыки доменов.

Проверить воспроизводимость методик: исходные условия, регистрация, отчётность.

Просмотреть список отклонений и убедиться, что ограничения внедрены в эксплуатацию (особенно через IOS и процедуры инструктора).

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

Типовые «красные флаги» именно по QTG и документации

QTG «в целом красивый», но нет привязки результатов к версиям конфигурации.

Эталонные данные не имеют ясной применимости к варианту самолёта.

Тесты проходят только у одного исполнителя или только при «особых» настройках.

Отклонения оформлены как «принято», но нет оценки влияния и нет ограничений в обучении.

IOS позволяет выбрать режимы/отказы, выходящие за пределы доказанных, и это не контролируется.

Итоги

QTG — основной технический документ доказательства соответствия, который связывает требования CS-FSTD(A) с конкретной конфигурацией FSTD и измеряемыми результатами.

Валидационные тесты ценны только при наличии контролируемых исходных условий, корректных эталонных данных, прозрачных допусков и воспроизводимой методики.

Документация вокруг QTG (конфигурация, изменения, дефекты, калибровки, процедуры) определяет, способен ли оператор удерживать квалификацию во времени.

Непрерывный надзор — это цикл управления изменениями и деградацией, где QTG используется как измерительный инструмент и источник прослеживаемых доказательств.