Симулятор «мир БВС» — зачем он существует, кому продаёт ценность и по каким числам мы поймём, что он получился¶

Продуктовый домен симулятора: проблема, роли, сценарии использования, границы, уровни зрелости, метрики успеха (включая метрики достоверности — ключевой раздел), связка с планировщиком и требования SIM-BIZ.

Область: /Users/gpb/geoscan/simulate. Соседний сервис — планировщик geoscan (задача 5 ЛЦТ). Источники ТТХ: /Users/gpb/geoscan/docs/task5/10-hardware/fleet.yaml и payloads.yaml — единственная правда. Первоисточники: РЭ Геоскан 201, спецлисты 801 и Gemini, ТЗ хакатона, руководство Mission Planner.

1. Проблема¶

1.1 Формулировка в одну строку¶

Планировщик выдаёт план, который арифметически корректен (длина / скорость + запас), но никто не знает, что произойдёт с этим планом в воздухе. Единственный способ узнать сегодня — вылететь. Вылет необратим, дорог по времени, ограничен погодой и, у 201, физически не отменяем после перевода борта в режим «Катапульта».

1.2 Что именно нельзя проверить без вылета¶

Список дыр, которые расчётом не закрываются, зафиксирован в контекстном дайджесте (01-context-digest.md, 17 пунктов). Ниже — те из них, где цена ошибки выражается числом из ТТХ.

#	Что нельзя проверить расчётом	Почему расчёт не помогает	Цена ошибки в числах источника
P-01	Фактическое покрытие по кадрам, а не по полосам	планировщик считает полосу захвата сплошной лентой; реальность — дискретные кадры с интервалом затвора, который не указан ни для одной нагрузки (A-08)	PF1B footprint 117×78 м при H=100 м; при недостаточной частоте затвора продольное перекрытие 70 % (`payloads.yaml`) не обеспечивается → дыры
P-02	Клиренс над реальным рельефом (CFIT)	план в AGL, DEM в AMSL; ошибка фрейма высот на полигоне 5×5 км с перепадом 50 м даёт фактический клиренс 50 м вместо 100 м	РЭ 201: «не менее 100 м выше рельефа и высотных объектов»; `altitude_agl_min: 100`, `can_fly_below_launch_point: false`
P-03	Высотные препятствия вне геозон (ЛЭП, вышки, трубы)	их нет во входной схеме планировщика — есть только inclusion/exclusion полигоны	РЭ 201 требует клиренс 100 м и над точечными объектами; Q-09 заказчику открыт
P-04	Где борт окажется при потере связи	план не содержит параметра «Время автономного полёта»; числа в РЭ нет вообще	201: радио 40 км при маршруте 210 км → уход за связь штатен; Gemini: 5 км; 801: 10 км (и это видеоканал, а не управление — расхождение R5)
P-05	Выполнимость разворота при реальном радиусе	планировщик считает разворот временем или вообще не считает	R = V²/(g·tanφ) = 137 м при 27,8 м/с и крене 30° → диаметр 273 м против шага галсов 70–120 м
P-06	Снос под ветром и отклонение от ЛЗП	ветер в схеме планировщика — скаляр, все реальные источники дают профиль по высоте	при W/V_a = 0,53 выигрыш галса поперёк ветра ≈18 % (1/√(1−(W/V_a)²)); при \|W⊥\| ≥ V_a линия не держится вообще
P-07	Куда реально сядет 201 на парашюте	коэффициента сноса нет ни в одном источнике (A-09, Q-12)	высота выброса 70 м, радиус автоотцепа 0–300 м (РЭ, раздел «Предстартовая подготовка»)
P-08	Что останется неснятым при срабатывании автовозврата в середине галса	планировщик резервирует 20 % энергии, но порог возврата — напряжение, не процент	порог возврата настраивается в 16,5–20,75 В (РЭ); при сильной разрядке планер теряет скорость и высоту
P-09	Фактическое время оборота на площадке	`turnaround_time_min: 10` в схеме сценария — величина из воздуха	Gemini: заряд 105 мин против 40 мин полёта (2,6 : 1); для катапультного 201 10 мин недостижимы (расхождение D-10)
P-10	Допуск к вылету по метео сверх ветра	слова «дождь», «снег», «обледенение», «туман», «молния», «гроза» не встречаются в РЭ 201 ни разу	жёстко документированы только ветер (201: 12 м/с; 801/Gemini: 10 м/с) и температура (201: −20…+40; Gemini: −15…+40)
P-11	Живучесть плана при отказе борта в момент t	план статичен, перепланирования нет	~30 кодов отказов в РЭ; «АВАРИЯ» и «ОШИБКА КОМПАСА» → немедленная посадка
P-12	Пригодность площадки под катапульту	схема сценария держит `takeoff_heading_deg` как константу площадки	РЭ: сектор ±30°, объекты не выше 0,1·L, запуск строго против ветра — курс есть функция ветра, а не свойство площадки (расхождение D-8)

1.3 Сколько стоит «просто слетать»¶

Статья	Что известно из источников	Что неизвестно
Подготовка 201	сборка ПУ, укладка парашюта с проверкой замка отцепа рывками, натяжение жгутов лебёдкой непосредственно перед стартом, мастер предстартовой подготовки, «Арктика» — снятие натяжения двумя людьми	времени подготовки в РЭ нет (A-BIZ-01)
Обратимость	после перехода в режим «Катапульта» «запрещается брать в руки и переносить БВС»; отмена = полное прохождение мастера заново	—
Погодное окно	ветер 201 ≤ 12 м/с, 801/Gemini ≤ 10 м/с; при 11 м/с доступен 1 борт из 3 (сценарий s09)	статистики повторяемости окон нет (Q-BIZ-05)
Оборот	Gemini: 105 мин заряд / 40 мин полёт; ЗУ Gemini работает 0…+40 °C — летать можно до −15, заряжать нельзя ниже 0 (расхождение D-7)	времени заряда 201 и 801 в источниках нет
Ресурс борта	ТО после 80 полётов или 1 года; АКБ 201 — ≥80 циклов	стоимости лётного часа и стоимости борта в источниках нет (Q-BIZ-01)
Согласование ВП	класс G без разрешения только при: масса 0,25–30 кг, вне НП, светлое время, прямая видимость, H ≤ 150 м над рельефом, вне запретных зон (ФП-138). Иначе — разрешение	сроки получения разрешения для нашего класса работ (все три борта < 30 кг, ВР/МР ≥5/≥3 суток к ним не применяется)
Потеря борта	необратима; резервного борта в парке из трёх нет	цена в деньгах (Q-BIZ-01)

Вывод. Стоимость одной проверки гипотезы «полетит ли этот план» измеряется не деньгами, а необратимостью и погодным окном. Симулятор превращает эту проверку в операцию, которая стоит секунды и повторяется сто раз за ночь.

1.4 Что специфично именно для этого парка¶

Борт	Что делает его непроверяемым на бумаге
Геоскан 201	катапульта + парашют: старт и посадка — не точки, а зоны с геометрией (сектор ±30°, объекты ≤0,1·L; эллипс сноса под куполом с 70 м). Ни одно из этого не выражается координатой в KML. Плюс: 210 км маршрута при 40 км радио → часть полёта штатно вне телеметрии
Геоскан Gemini	40 мин полёта против 105 мин заряда. Любой план длиннее одного вылета упирается не в энергию, а в очередь на зарядном устройстве; ошибка модели оборота меняет makespan в разы. Единственная честная энергомодель парка: 144,7 Вт·ч / 217 Вт
Геоскан 801	единственный носитель тепловизора (640×512, F=9,1 мм). Если сценарий требует ИК, борт не заменяется ничем; его 40 мин и ветер 10 м/с становятся жёстким горлышком всего плана. Вт·ч не указаны — ресурс только по времени

2. Роли и их работы (jobs-to-be-done)¶

Формат: роль → работа («когда …, я хочу …, чтобы …») → вместо чего симулятор это делает.

Роль	Работа (JTBD)	Вместо чего	Что получает на выходе
Внешний пилот / оператор (РЭ: «к запуску допускаются лица, прошедшие обучение на базе ООО „Геоскан“»)	Когда мне выдали чужой план, я хочу увидеть, где борт пройдёт низко, куда снесёт парашют и что будет при потере связи — до того, как натяну жгуты	вместо «поверить планировщику» и вместо разведывательного вылета	список нарушений с координатами и временем + видео пролёта
Планировщик работ (расчёт)	Когда я выбираю между двумя планами, я хочу сравнить их по факту, а не по оценке решателя	вместо сравнения двух чисел makespan, посчитанных одной и той же моделью	таблица «план vs факт» на оба плана, дельта разложена по причинам
Заказчик съёмки	Когда мне обещают покрытие 100 % и срок, я хочу увидеть, чем это обеспечено	вместо приёмки по факту сдачи материалов (когда переснимать уже поздно)	`coverage_fraction` по кадрам, а не по полосам; карта дыр
Обучаемый оператор	Когда я учусь настраивать предстартовые параметры 201, я хочу ошибиться безопасно	вместо тренировки на реальном борте (необратимо) или отсутствия тренировки вообще	последствия каждого из 4 параметров мастера предстартовой подготовки, измеренные в метрах и минутах
Разработчик алгоритмов планировщика	Когда я меняю эвристику раскладки галсов, я хочу за ночь узнать, не стало ли хуже на 100 сценариях	вместо ручной проверки 3–5 сценариев глазами	регрессионный отчёт: дельта факта по каждому сценарию, красный/зелёный
Жюри хакатона	Когда я оцениваю «обоснованность» и «эффективность маршрутов», я хочу увидеть доказательство, а не скриншот	вместо презентации с картинкой	3D-пролёт в реальных координатах + числа на экране, совпадающие с отчётом валидатора
Ревьюер проекта (один человек на агентов)	Когда агенты сдали код, я хочу проверить результат числом, а не чтением диффа	вместо чтения кода	отчёт симулятора рядом с отчётом валидатора, обе таблицы воспроизводимы по seed

Роль, которой нет и не будет: диспетчер реального воздушного движения. Симулятор не участвует в контуре управления реальными полётами (см. §4).

3. Сценарии использования¶

Нумерация U-01…U-12. Каждый сценарий — строки таблицы: актор, триггер, вход, что делает симулятор, выход, ценность.

U-01. Приёмка плана перед вылетом¶


Актор	внешний пилот / оператор
Триггер	получен файл плана (KML/GeoJSON по схеме `40-formats/03`), до выезда на площадку
Вход	`plan` + `scenario` + `world_snapshot_id` (рельеф, препятствия, зоны) + фактический ветер
Делает	прогоняет каждый вылет по фазам `takeoff…landing`; проверяет клиренс ≥100 м над рельефом и объектами с шагом ≤10 м; проверяет курс старта против ветра и сектор ±30°/0,1·L; проверяет, что порог возврата 16,5–20,75 В не наступает раньше конца задания; строит эллипс сноса парашюта и пересекает его с запретами
Выход	`preflight_report`: список нарушений с (lat, lon, t, фаза, причина, ссылка на пункт РЭ) + вердикт GO/NO-GO + список параметров мастера предстартовой подготовки, которые надо изменить
Ценность	план проверяется за секунды до того, как натянуты жгуты, а не после жёсткой посадки

U-02. Сравнение двух планов¶


Актор	планировщик работ
Триггер	решатель выдал два плана: по `makespan` и по `total_flight_time` (два критерия из ТЗ)
Вход	два `plan` на одном `scenario` и одном `world_snapshot_id`
Делает	прогоняет оба на одном seed и одном ветре; считает факт по обоим; раскладывает дельту «план↔факт» по вкладам: ветер, развороты, набор/снижение, оборот на площадке, автовозврат
Выход	таблица 2×N метрик + столбец «дельта факт−план» + разложение дельты
Ценность	выбор между критериями делается по факту, и видно, какой из планов «красив на бумаге»

U-03. Обучение оператора¶


Актор	обучаемый оператор
Триггер	учебное занятие; допуск к 201 требует обучения (прямое требование РЭ)
Вход	учебный сценарий + свободно редактируемые параметры мастера предстартовой подготовки: радиус автоотцепа парашюта (0–300 м), время автономного полёта (значения в РЭ нет), напряжение возврата (16,5–20,75 В), минимальная высота возврата (100–4000 м)
Делает	проигрывает полёт в 3D с выбранными параметрами; вбрасывает событие (потеря связи, низкое напряжение, нарушение зоны); показывает поведение борта по логике РЭ, а не по логике ArduPilot (это разные вещи: РЭ «НАРУШЕНИЕ ЗОНЫ» → отключение фотокамеры + полёт к месту посадки)
Выход	запись сессии + разбор: где борт оказался, сколько задания потеряно, сработал ли автоотцеп на дереве
Ценность	ошибка в настройке параметра стоит перезапуска симуляции, а не борта

U-04. Регрессионный прогон алгоритма планировщика (headless, 100 сценариев)¶


Актор	разработчик алгоритмов планировщика; CI
Триггер	ночной прогон после merge; или ручной запуск перед сдачей
Вход	набор `sc-*` (борта 1–20, площадь 1–200 км², ВПП 1–5, NFZ 0–20) + планы, выданные текущей версией решателя
Делает	без GUI, без сети, по фиксированному `(world_snapshot_id, seed)`; прогоняет все сценарии; сравнивает факт с предыдущим прогоном
Выход	одна таблица: сценарий, факт-makespan, факт-coverage, нарушения, дельта к baseline, время прогона; и `run_manifest` с sha256 всех входов
Ценность	«стало хуже» обнаруживается ночью на 100 сценариях, а не на защите на одном

U-05. Демонстрация на защите¶


Актор	команда → жюри
Триггер	питч-сессия; критерии ТЗ «эффективность маршрутов и масштабируемость» и «качество демонстрации»
Вход	один подготовленный сценарий смешанного парка, заранее собранный мир, заранее прогнанный батч
Делает	проигрывает план в 3D в реальных географических координатах с зонами; параллельно показывает счётчики факта; по команде включает ветер 8 м/с и повторяет — виден проигрыш галсов вдоль/поперёк
Выход	5-минутный воспроизводимый пролёт + таблица чисел, идентичная отчёту валидатора
Ценность	обоснованность подхода показывается, а не утверждается; числа на экране проверяемы

U-06. Разбор «что было бы, если бы отказала связь»¶


Актор	планировщик работ, оператор
Триггер	вопрос «а если связь пропадёт на дальнем галсе?»; штатная ситуация для 201 (210 км маршрута при 40 км радио)
Вход	план + модель радиовидимости (по рельефу, а не круг R) + параметр «время автономного полёта» (ДОПУЩЕНИЕ, значения в РЭ нет)
Делает	помечает участки вне радиовидимости; для выбранного момента t запускает логику РЭ: таймер → возврат на точку старта на текущей высоте → круговой облёт; считает, сколько задания потеряно и хватает ли энергии на возврат
Выход	карта «зона без связи», момент срабатывания, остаток задания, остаток энергии, точка фактической посадки
Ценность	цена ухода за связь становится числом, а не «ну обычно долетает»

U-07. Подбор старта и посадки под фактический ветер¶


Актор	оператор, планировщик работ
Триггер	прогноз ветра изменился ко дню работ
Вход	площадки, ветер (направление = ОТКУДА дует), рельеф, препятствия
Делает	пересчитывает курс катапультного старта строго против ветра, проверяет сектор ±30° и правило «объекты не выше 0,1·L» по рельефу и препятствиям; строит маршрут посадки из 3 точек с заходом против ветра; пересекает эллипс сноса с дорогами/водой/застройкой
Выход	допустимый диапазон курсов старта/захода на каждую площадку + вердикт «площадка пригодна/непригодна при данном ветре»
Ценность	закрывает расхождение D-8/D-9: курс старта — функция ветра, а не константа площадки

U-08. Проверка клиренса над рельефом и препятствиями (CFIT)¶


Актор	оператор, заказчик съёмки
Триггер	полигон в пересечённой местности или с ЛЭП/вышками
Вход	план с обязательным `altitude_frame` (AGL/AMSL) + DEM + слой препятствий (`terrain_z` + canopy/здания/мачты)
Делает	дискретизирует траекторию шагом ≤10 м, считает превышение над `obstacle_height`; отдельно проверяет «не ниже точки старта» для 201
Выход	профиль клиренса вдоль маршрута, минимум, список точек < 100 м
Ценность	ловит самую дорогую ошибку — путаницу AGL/AMSL, которая вдвое режет клиренс и вдвое меняет GSD

U-09. Отказ борта в момент t — живучесть плана¶


Актор	планировщик работ
Триггер	вопрос «план из трёх бортов — а если один выбыл?» (сценарий s10)
Вход	план + момент отказа t + код отказа (АВАРИЯ / ОШИБКА КОМПАСА → немедленная посадка; ОШИБКА КРЛ → полёт продолжается)
Делает	обрывает вылет по логике кода отказа; считает недоснятую площадь и сдвиг makespan при доборе оставшимися бортами
Выход	«потеряно X км² и Y минут», карта недоснятого
Ценность	устойчивость плана к отказу становится метрикой, а не надеждой

U-10. Калибровка модели по реальной телеметрии¶


Актор	разработчик симулятора
Триггер	заказчик передал лог реального вылета (сегодня такого лога нет — Q-BIZ-02)
Вход	лог (позиция, скорость, напряжение, срабатывания камеры) + план, по которому летели
Делает	прогоняет тот же план, сравнивает траекторию и энергию с фактом, оценивает ошибку модели
Выход	отчёт калибровки: ошибка по времени вылета, по длине трека, по остатку энергии; обновлённые значения допущений
Ценность	единственный способ поднять достоверность выше уровня «сверено с руководством» (см. §6.2)

U-11. Проверка фактического покрытия по кадрам и качества кадра¶


Актор	заказчик съёмки, планировщик работ
Триггер	требование GSD в задании (`quality.gsd_cm`)
Вход	план + модель камеры из `payloads.yaml` (k, размеры матрицы, f) + фактическая траектория с креном и сносом
Делает	срабатывает затвором по факту пройденного пути, строит футпринт каждого кадра с учётом крена и сноса, объединяет и пересекает с полигоном; считает смаз V_g·t_exp
Выход	`coverage_fraction` по кадрам, карта дыр, распределение фактического GSD, доля кадров со смазом выше порога
Ценность	закрывает P-01: «полоса покрыта» и «кадры сомкнулись» — разные утверждения

U-12. Формирование «перечня известных ограничений»¶


Актор	команда → жюри (обязательный раздел документации по п. 5 ТЗ)
Триггер	подготовка сдачи
Вход	все выходные числа прогона с их `fidelity_class` + реестр допущений A-xx
Делает	для каждого допущения варьирует значение на ±20 % и меряет отклик выходных метрик; сортирует допущения по влиянию
Выход	таблица «допущение → на что влияет → насколько (в % метрики) → чем заменить»
Ценность	перечень ограничений перестаёт быть текстом и становится измерением

4. Границы продукта¶

Область	В объёме	Явно ВНЕ объёма	Почему вне	Что вместо
Аэродинамика	кинематическая модель: ветровой треугольник, радиус разворота по крену, ограничения по скоростям из `fleet.yaml`, вертикальные скорости	сертифицируемая аэродинамика уровня X-Plane (поляра, обдувка, срыв)	в источниках нет ни поляры расхода, ни радиуса разворота, ни крена ни для одного борта — модель было бы нечем питать; и она не отвечает ни на один вопрос из §1.2	явно объявленный класс модели «кинематика + энергия по средней мощности» с указанием ошибки
Автопилот	воспроизведение документированного поведения: коды отказов РЭ, пороги возврата, логика «Возврат»/«Посадка», спираль набора, точка ожидания 300 с	HIL/SITL-связка с реальной прошивкой автопилота Геоскан	прошивка и её параметры недоступны; SITL ArduPilot воспроизводит не ту логику (РЭ: НАРУШЕНИЕ ЗОНЫ → камера off + полёт на посадку; ArduPilot: GUIDED → возврат → барражирование) — подмена дала бы ложную уверенность	таблица «пункт РЭ → тест симулятора», расхождения с ArduPilot фиксируются как находки
Управление	приём плана, прогон, выдача чисел	управление реальными бортами, выдача команд на НСУ, любой контур с реальным железом	безопасность полётов; сервис не сертифицирован и не будет; онлайн-контур у заказчика вообще не подтверждён (Q-01)	офлайн-контур «файл → симулятор → отчёт», как и у планировщика
Графика	3D-сцена в реальных координатах: рельеф с отмывкой, объёмные зоны, борт, полоса захвата, вид «с камеры»	фотореалистичный рендер уровня Unreal, Google Photorealistic 3D Tiles	три независимых блокера у Google: покрытие РФ фактически нулевое, ToS запрещает пре-фетч/кэш, Google Cloud закрыт для РФ с 20.03.2024. Плюс требование «`docker compose up` без интернета и без ключей»	гипсометрия + отмывка по Copernicus DEM GLO-30, PMTiles по HTTP Range
Камера	геометрия кадра (футпринт, GSD, перекрытие, смаз), синтетический кадр по подложке и рельефу	физически корректная радиометрия, дисторсия, шум матрицы, атмосферное рассеяние	радиометрия и дисторсия камер в источниках отсутствуют полностью; ИК-радиометрия потребовала бы тепловой модели сцены, которой нет	кадр служит проверкой геометрии покрытия, а не имитацией снимка; помечается `fidelity_class: derived`
Метрики качества плана	факт и дельта «план↔факт»	`coverage_fraction`, `makespan_s` и прочие метрики качества самого плана	их считает валидатор планировщика; дублирование сломало бы принцип независимости	симулятор отдаёт факт, валидатор — норму; расхождение двух — сигнал
Метео	ветер (профиль по высоте), температура, пороги допуска; молния/снег/сеть — как события с настраиваемыми порогами	физически корректная метеомодель (конвекция, обледенение, микропорывы)	пороги по осадкам, снегу, грозе и обледенению в РЭ не заданы вообще — только ветер и температура	события моделируются как переключатели допуска и деградации ТТХ; все пороги — в допущениях
Планирование	нет	построение маршрутов, раскладка галсов, назначение бортов	это работа планировщика; если симулятор начнёт планировать, он перестанет быть независимой проверкой	симулятор только исполняет чужой план
Данные	открытые наборы с совместимой лицензией	FABDEM (CC BY-NC-SA), ArcticDEM 2 м (education/research), Mapbox Terrain-RGB, Cesium ion SaaS	лицензионные блокеры, зафиксированы в `10-world/01`	GLO-30/90, ArcticDEM 10 м, WorldCover, OSM (с вынесением share-alike слоя отдельным артефактом)

5. Уровни зрелости¶

M0 — минимально осмысленный симулятор¶


Что умеет	headless, один борт (Gemini — единственная честная энергомодель: 144,7 Вт·ч / 217 Вт); рельеф из GLO-30 в локальной UTM; ветер — константа; исполнение плана по фазам; факт по времени, длине, энергии; покрытие по полосам; отчёт «план vs факт» одной таблицей
Чего не умеет	3D-фронт, камера, отказы, метео-события, несколько бортов
Критерий выхода	сценарий s01 (прямоугольник 1×1 км, GSD 3 см) прогоняется одной командой; два запуска с одним seed дают бит-в-бит одинаковый отчёт; площадь полигона в UTM совпадает с эталоном в пределах 0,1 %; ветровой треугольник воспроизводится с ошибкой ≤0,5 % от аналитической формулы

M1 — демонстрируемый на защите¶

Что умеет всё из M0 + три борта парка (201 / 801 / Gemini) со своими ТТХ из fleet.yaml; 3D-сцена в реальных координатах с объёмными зонами; камера даёт кадр и футпринт; покрытие по кадрам; клиренс над рельефом и препятствиями; катапультный старт против ветра и парашютная посадка со сносом; два failsafe — потеря связи и порог напряжения возврата; батч из 10 сценариев s01–s10

Критерий выхода docker compose up без интернета и без ключей тайл-сервисов поднимает стенд; демо-пролёт 5 минут воспроизводится по (world_snapshot_id, plan, seed); числа на экране совпадают с отчётом валидатора до последнего знака; батч s01–s10 проходит за ≤30 мин; каждое выходное число несёт fidelity_class

M2 — продуктовый¶

Что умеет всё из M1 + 100 сценариев sc-* за ночь; метео-события (порывы, снег, гроза, недоступность сети) с настраиваемыми порогами; радиовидимость по рельефу вместо круга R; деконфликтация бортов; эллипс сноса парашюта с коэффициентом; очередь на площадке и фактический оборот; API возврата чисел в планировщик; отчёт чувствительности к допущениям; авто-генерация «перечня известных ограничений»

Критерий выхода 100 сценариев проходят за ≤8 ч (≤288 с/сценарий, целевая медиана ≤60 с); каждое допущение A-xx имеет измеренную чувствительность выходных метрик; ни одно число не выходит без fidelity_class; мутационный тест ловит ≥95 % заведомо плохих планов (см. §6.2)

6. Метрики успеха¶

6.1 Метрики продукта¶

Метрика	Определение	Целевое значение	Откуда число
`batch_throughput`	сколько сценариев `sc-*` проходит за ночной прогон	100 за ≤8 ч, медиана ≤60 с/сценарий	ДОПУЩЕНИЕ A-BIZ-04: «ночь» = 8 ч; размер батча — из `sc-*` (борта 1–20, площадь 1–200 км²)
`world_build_time`	время первичной сборки мира на 100 км² (DEM → UTM COG + препятствия + тайлы)	≤10 мин первично, ≤30 с повторно из кеша	ДОПУЩЕНИЕ A-BIZ-05, целевое значение, не из источника
`world_build_time` (масштаб)	рост времени сборки от площади	не хуже линейного на диапазоне 1→200 км²	требование масштабируемости из критериев жюри
`plan_fact_divergence`	доля планов, где факт расходится с расчётом планировщика более чем на 10 % по `makespan_s`	измеряется всегда; ≤2 из 10 на наборе s01–s10; каждая дельта >10 % разложена по вкладам	10 % — ДОПУЩЕНИЕ A-BIZ-06; разложение — жёсткое требование, см. SIM-BIZ-06
`coverage_delta`	\|coverage по кадрам − coverage по полосам\|	измеряется всегда; при >5 % планировщик обязан получить сигнал	5 % — ДОПУЩЕНИЕ A-BIZ-07
`violations_found`	число нарушений, найденных симулятором в планах, признанных валидатором корректными	>0 — симулятор окупился; =0 на всех 100 сценариях — повод проверить сам симулятор мутационным тестом	смысл продукта
`demo_reproducibility`	повтор демо-прогона даёт идентичный отчёт	бит-в-бит, 100 % запусков	правило проекта «детерминированный headless»
`cold_start_offline`	`docker compose up` на машине без сети	поднимается, 0 сетевых обращений	требование SIM-GEO-16

6.2 Метрики достоверности — чем мы докажем, что симулятор не врёт¶

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

Пирамида доказательств V1…V6¶

Снизу вверх — от дешёвых и обязательных к дорогим и недоступным сегодня.

Уровень	Что доказывает	Как проверяется	Порог приёмки	Доступен нам?
V1. Аналитические тождества	модель воспроизводит формулы, для которых есть закрытое решение	прогон вырожденных сценариев и сверка с формулой	ошибка ≤0,5 % по каждому тождеству	да, обязателен
V2. Инварианты и консервация	модель не течёт и не дрейфует	замкнутые траектории, энергобаланс, детерминизм	см. таблицу ниже	да, обязателен
V3. Независимая перепроверка	геометрия факта считается двумя независимыми путями	сверка с валидатором планировщика на общих величинах	расхождение по длине маршрута ≤1 %	да, обязателен
V4. Сверка с первоисточником	поведение борта соответствует РЭ, а не нашим представлениям	трассировка «пункт РЭ → тест»	100 % документированных порогов покрыты тестом	да, обязателен
V5. Негативный контроль (мутации)	симулятор ловит плохие планы, а не просто не падает	подсовываем заведомо дефектные планы	детекция ≥95 % мутантов, ложных срабатываний 0 на эталонном корректном плане	да, обязателен
V6. Сверка с реальностью	модель совпадает с фактическим полётом	сравнение с телеметрией реального вылета	ошибка по времени вылета ≤5 %, по длине трека ≤2 %	нет — телеметрии не существует (Q-BIZ-02)

Честная граница. Сегодня симулятор может быть доказан только до V5 включительно. Это надо писать в отчётах и говорить на защите прямым текстом: «модель сверена с руководством по эксплуатации и с независимой геометрией, но не сверена с реальным полётом — реальных логов у нас нет». Любая формулировка сильнее этой — вранье.

V1. Тождества, которые обязаны совпасть¶

Тождество	Формула / значение	Источник	Допуск
Ветровой треугольник	`V_g = √(V_a² − W⊥²) + W∥`	РЭ 201 / `30-domain/05`	≤0,5 %
Невозможность удержания ЛЗП	при \|W⊥\| ≥ V_a линия не держится	там же	факт воспроизводится
Выигрыш галса поперёк ветра	`1/√(1−(W/V_a)²)` ≈ 18 % при W/V_a = 0,53	сценарий s06	≤0,5 %
Радиус разворота	`R = V²/(g·tanφ)` = 137 м при 27,8 м/с и φ=30°	`01-context-digest`	≤0,5 %
GSD	`GSD = H × k`; PF1B `k = 1,9583e-4` → 1,96 см при H=100 м	`payloads.yaml`	≤0,1 %
Футпринт PF1B	117 × 78 м при H=100 м	`payloads.yaml`	≤0,1 %
Энергия Gemini	144,7 Вт·ч / 217 Вт = 40 мин	`fleet.yaml` (derived)	≤1 мин
Площадь в проекции	площадь полигона в UTM vs эталон	правило проекта	≤0,1 %
Round-trip СК	WGS84 → UTM → WGS84	SIM-GEO-06	≤0,05 м

V2. Инварианты¶

Инвариант	Проверка	Порог
Детерминизм	два прогона одного `(world_snapshot_id, plan, seed)`	бит-в-бит идентичный отчёт
Отсутствие дрейфа интегратора	100 кругов по замкнутому маршруту при нулевом ветре	отклонение конечной точки ≤1 м
Энергобаланс	Σ(мощность × Δt) по фазам vs израсходованная энергия	невязка ≤0,1 %
Неотрицательность путевой	`V_g > 0` на каждом отрезке	нарушений 0
Строгость времени	`T_факт > L / V_g` строго (время не может быть меньше геометрического минимума)	нарушений 0
Независимость от шага интегрирования	прогон с Δt и Δt/2	расхождение `makespan` ≤0,5 %
Независимость от локальной зоны UTM	полигон на стыке зон 35N/36N	расхождение метрик ≤0,1 %

V3. Независимая перепроверка¶

Величина	Симулятор считает	Валидатор считает	Допустимое расхождение
Длина маршрута	интегрированием траектории	по геометрии плана	≤1 %
Площадь покрытия	объединением футпринтов кадров	буферами полос	расхождение не является ошибкой — это и есть искомая дельта P-01, но обязано быть объяснено
Нарушения NFZ	по фактической траектории	по геометрии плана	симулятор ⊇ валидатор: всё, что нашёл валидатор, обязан найти и симулятор

Правило независимости наследуется от валидатора: симулятор не импортирует код планировщика (coverage/, routing/). Общая реализация воспроизвела бы общую ошибку и промолчала.

V4. Трассировка к первоисточнику¶

Каждый документированный порог РЭ становится тестом. Минимальный перечень:

Пункт источника	Значение	Тест
РЭ 201, ограничения	ветер ≤12 м/с	при W=13 борт не допускается к вылету
801 / Gemini	ветер ≤10 м/с	при W=11 доступен 1 борт из 3 (s09)
РЭ 201	клиренс ≥100 м над рельефом и объектами	траектория ниже → violation
РЭ 201	«БВС не способно выполнять полёты ниже высоты точки старта»	нарушение фиксируется
РЭ 201	потолок 4000 м AMSL	превышение → violation
Gemini	потолок 500 м AGL	превышение → violation
РЭ 201, предстартовая подготовка	напряжение возврата 16,5–20,75 В	значение вне диапазона отвергается; при достижении порога борт сам начинает посадку
РЭ 201	радиус автоотцепа 0–300 м, 0 = выкл	вне диапазона отвергается
РЭ 201	минимальная высота возврата 100–4000 м	вне диапазона отвергается
РЭ 201	высота выброса парашюта 70 м	траектория снижения начинается с 70 м
РЭ 201	запуск строго против ветра, сектор ±30°, объекты ≤0,1·L	старт по ветру → NO-GO
РЭ 201	посадка против ветра, маршрут посадки из 3 точек	отсутствие 3 точек → ошибка плана
РЭ 201	«Возврат» = к точке взлёта на текущей высоте, затем круговой облёт	поведение воспроизводится
РЭ 201	перелёт между элементами — по большей из двух высот; если не набрать по прямой — спираль	воспроизводится
РЭ 201	точка ожидания по умолчанию 300 с	воспроизводится
РЭ 201	НАРУШЕНИЕ ЗОНЫ → камера off + полёт к месту посадки	воспроизводится именно так, не по ArduPilot
РЭ 201	АВАРИЯ, ОШИБКА КОМПАСА → немедленная посадка	воспроизводится
РЭ 201	ОШИБКА КРЛ → полёт продолжается	воспроизводится
РЭ 201	зоны истекли / не верифицированы → вылет блокируется	воспроизводится
РЭ 201	ТО после 80 полётов или 1 года; АКБ ≥80 циклов	учитывается как счётчик ресурса
РЭ 201, цитата	«на холоде литий-полимерные АКБ могут терять до 30 % ёмкости»	дерейтинг применяется, факт помечается
Gemini	ЗУ работает 0…+40 °C при полёте до −15 °C	при T<0 оборот через заряд невозможен
ФП-138	H > 150 м → WARNING (не violation)	предупреждение выдаётся; Gemini+PF1B при GSD 3 см даёт H=153 м

V5. Негативный контроль — кто сторожит сторожа¶

Самая недооценённая проверка. Симулятор, который «всё прогнал и ничего не нашёл», неотличим от симулятора, который ничего не проверяет. Поэтому — мутационное тестирование планов.

Мутант (что ломаем в заведомо корректном плане)	Что симулятор обязан вернуть
сдвинуть галс на 200 м внутрь NFZ	`violations.nfz > 0` с координатой и временем
опустить высоту до 60 м AGL над холмом	нарушение клиренса 100 м
заменить `altitude_frame: AGL` на `AMSL` без пересчёта	нарушение клиренса на полигоне с перепадом ≥50 м
развернуть курс старта на 180° (по ветру)	NO-GO по правилу «строго против ветра»
поставить `turnaround_time_min: 1` для Gemini при втором вылете	нарушение по заряду (105 мин)
назначить ИК-съёмку на Gemini	нарушение совместимости нагрузки (ИК только 801)
убрать из плана маршрут посадки из 3 точек	ошибка плана
растянуть вылет 201 до 200 мин	нарушение endurance (180 мин)
поставить ветер 13 м/с	недопуск всех бортов
сдвинуть точку посадки под ЛЭП	пересечение эллипса сноса с препятствием
задать интервал затвора вдвое реже нужного	падение покрытия по кадрам
поставить шаг галсов 200 м при футпринте 117 м	дыры в покрытии

Порог: детекция ≥95 % мутантов, ложных срабатываний на эталонном корректном плане — 0. Набор мутантов ведётся в репозитории и растёт: каждый реальный дефект, который симулятор пропустил, превращается в нового мутанта.

Маркировка достоверности каждого числа¶

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

Поле	Смысл	Значения
`value`	число	—
`unit`	единица	`s`, `m`, `m/s`, `km2`, `Wh`, `cm/px`
`fidelity_class`	на чём держится	`measured` (прямо из источника), `derived` (посчитано из источников), `assumed` (допущение)
`depends_on`	список допущений A-xx, влияющих на величину	массив ID
`validation_level`	максимальный достигнутый уровень пирамиды	`V1`…`V6`

Правило: величина с fidelity_class: assumed не может быть основанием для вердикта GO — она выводится, но помечается и попадает в перечень ограничений. Вердикты GO/NO-GO опираются только на measured/derived.

Чувствительность к допущениям¶

Для каждого допущения A-xx измеряется отклик метрик на вариацию ±20 %. Приоритетные кандидаты:

Допущение	Что от него зависит	Почему опасно
крейсерская скорость 27,8 м/с (201)	всё время полёта	она assumed, середина диапазона 17,8–36,1; плюс расхождение R4: 180 мин × 210 км дают 19,4 м/с, а не 27,8
время автономного полёта после потери связи	вся модель U-06	числа в РЭ нет вообще
коэффициент сноса парашюта	вся модель посадки 201	отсутствует полностью
минимальный интервал затвора	покрытие по кадрам	не указан ни для одной нагрузки
Вт·ч АКБ 801	энергомодель 801	не указаны; ресурс только по времени
время оборота на площадке	makespan многовылетных планов	`turnaround_time_min: 10` недостижимо для катапультного 201 (D-10)
профиль ветра по высоте	снос, покрытие, энергия	схема планировщика даёт скаляр, реальность — профиль

Если чувствительность метрики к assumed-допущению превышает 10 %, метрика в отчёте помечается как недостоверная и требует ответа заказчика прежде, чем использоваться для вердикта.

7. Связка с основным сервисом¶

7.1 Что симулятор берёт у планировщика¶

Артефакт	Формат	Зачем
`plan`	JSON по `40-formats/03`: `missions[].sorties[].phases[]`, `altitude_frame`, `turn_mode`, `camera_trigger_interval_s`	исполняемое задание
`plan`	KML (OGC 2.2, обязательный `altitudeMode`) / GeoJSON (RFC 7946, 7 знаков)	тот же план в формате сдачи; симулятор обязан уметь оба, чтобы ловить потерю высот при `clampToGround`
`scenario`	JSON: `launch_sites`, `landing_sites`, `fleet`, `tasks`, `airspace`, `weather`, `objective`, `solver`	мир и ограничения
`warnings[]`, `unassigned[]`	из плана	симулятор проверяет, что предупреждения планировщика соответствуют факту

7.2 Что симулятор отдаёт обратно¶

Артефакт	Содержание	Кому полезно
`fact_report`	фактические makespan, время вылетов, длины, энергия, покрытие по кадрам, число кадров	планировщику — для калибровки модели; заказчику — для приёмки
`delta_report`	разложение «факт − план» по вкладам: ветер, развороты, набор/снижение, оборот, автовозврат	планировщику — что именно он недооценивает
`violations[]`	нарушения, невидимые из плана: клиренс, препятствия, снос парашюта, зоны без связи, сближения	планировщику — как новые ограничения решателя
`calibration_hints`	поправочные коэффициенты (например, фактическая доля времени на разворотах)	планировщику — числа вместо допущений
`world_snapshot_id`	идентификатор мира со списком источников, релизов, bbox, CRS, датумов и sha256	обоим — воспроизводимость

7.3 Почему это два сервиса, а не один¶

Причина	Разбор
Независимость проверки	главное. Метод проекта — «валидатор пишется раньше продукта», и валидатор не импортирует код решателя, иначе воспроизведёт его ошибку и промолчит. Симулятор — то же самое, только на уровне физики: общий код = общая ошибка = ложное «всё сходится»
Разные требования ТЗ	ТЗ требует планировщик в браузере на ПК. Симулятор с 3D-сценой, DEM-тайлами и батч-прогонами в эту рамку не помещается и не должен её ломать
Разные ресурсы	планировщик — CPU-решатель с `time_limit_s`; симулятор — GPU/3D на фронте и длинные батчи на бэке. Общий процесс означал бы, что тяжёлый прогон блокирует интерактивное планирование
Разные циклы жизни	план пересчитывается десятки раз в минуту; мир собирается один раз и живёт неделями под своим `world_snapshot_id`
Риск сдачи	симулятор — усиление, а не основа. Если он не успевает к 29.09, планировщик сдаётся целиком и самостоятельно. Монолит такой возможности не даёт
Разные лицензии данных	ODbL-производные (OSM + ML footprints) требуют share-alike и выносятся отдельным артефактом; держать их внутри планировщика — навязывать ему лицензионные обязательства

Направление зависимости — строго одностороннее: симулятор знает о планировщике (читает его выход), планировщик о симуляторе — нет. Планировщик работает и без симулятора; обратное неверно.

8. Требования SIM-BIZ¶

ID	Требование	Приоритет	Критерий приёмки	Источник
SIM-BIZ-01	Симулятор принимает выход планировщика без ручной правки: `plan` (JSON по `40-formats/03`), KML и GeoJSON	MUST	все три формата одного плана дают идентичный `fact_report` (расхождение метрик ≤0,1 %); KML с `clampToGround` даёт явную ошибку `KML_ALTITUDE_LOST`, а не молчаливое обнуление высот	`40-formats/01`, `40-formats/03`; ТЗ п. «выгрузка KML/GeoJSON»
SIM-BIZ-02	Headless-режим: полный прогон одной командой, без GUI и без сети	MUST	`docker compose run sim batch --scenarios sc/ --seed N` отрабатывает на машине с отключённой сетью; сетевых обращений — 0	правило проекта «детерминированный headless»; SIM-GEO-16
SIM-BIZ-03	Детерминизм: результат однозначно определяется тройкой (`world_snapshot_id`, `plan`, `seed`)	MUST	два прогона дают бит-в-бит идентичный отчёт; изменение любого элемента тройки отражается в `run_manifest`	правило проекта; R-PS-28
SIM-BIZ-04	Каждая выходная величина несёт `value`, `unit`, `fidelity_class`, `depends_on`, `validation_level`	MUST	схема выхода отвергает величину без любого из пяти полей; доля величин без `fidelity_class` = 0 %	§6.2; правило «всё непроверенное — в известные ограничения»
SIM-BIZ-05	Симулятор не импортирует код планировщика; validator/ не импортирует движок	MUST	CI: 0 рёбер `validator/` → `engine/`, `mission/`, `uav/`, `camera/`, `env/`; 0 рёбер `simulate/` → `coverage/`, `routing/`	`70-plan/01-validator-first.md`
SIM-BIZ-10	Аналитические тождества V1 (V1-01…V1-09)	MUST	round-trip ENU/WGS84 ≤ 0,01 м; площадь ENU/геодезическая, не UTM; остальное — §6.2	§6.2; `30-domain/05`; `payloads.yaml`
SIM-BIZ-06	Отчёт «план vs факт» с разложением дельты по вкладам (ветер, развороты, набор/снижение, оборот, автовозврат)	MUST	сумма вкладов равна полной дельте с невязкой ≤5 %; каждая дельта `makespan` >10 % имеет разложение	§6.1, §3/U-02
SIM-BIZ-07	Батч-производительность: 100 сценариев `sc-*` за ночной прогон	MUST	100 сценариев ≤8 ч (≤288 с/сценарий), медиана ≤60 с	§6.1; ДОПУЩЕНИЕ A-BIZ-04
SIM-BIZ-08	Сборка мира: 100 км² первично и повторно из кеша	SHOULD	первично ≤10 мин, повторно ≤30 с; рост времени от площади не хуже линейного на 1→200 км²	§6.1; ДОПУЩЕНИЕ A-BIZ-05
SIM-BIZ-09	Стенд поднимается `docker compose up` без интернета и без ключей тайл-сервисов	MUST	на изолированной машине фронт открывается, рельеф отображается, прогон проходит	SIM-GEO-16; лицензионные блокеры `10-world/01`
SIM-BIZ-11	Инварианты V2 держатся	MUST	детерминизм бит-в-бит; дрейф ≤1 м на 100 кругов; невязка энергобаланса ≤0,1 %; `V_g>0` и `T>L/V_g` строго; Δt→Δt/2 меняет makespan ≤0,5 %	§6.2/V2
SIM-BIZ-12	Независимая сверка V3 с валидатором планировщика	MUST	длина маршрута расходится ≤1 %; множество нарушений симулятора ⊇ множества нарушений валидатора на всех s01–s10	§6.2/V3
SIM-BIZ-13	Трассировка «пункт первоисточника → тест»: все документированные пороги покрыты	MUST	таблица §6.2/V4 реализована на 100 %; каждый тест ссылается на конкретный пункт РЭ/спецлиста	РЭ 201, спецлисты 801/Gemini, ФП-138
SIM-BIZ-14	Негативный контроль: мутационное тестирование планов	MUST	набор из ≥12 мутантов §6.2/V5; детекция ≥95 %; ложных срабатываний на эталонном корректном плане — 0	§6.2/V5
SIM-BIZ-15	Отчёт чувствительности к допущениям	SHOULD	для каждого A-xx измерен отклик метрик на ±20 %; метрика с откликом >10 % на `assumed`-допущение помечается как недостоверная	§6.2; ТЗ п. 5 «перечень известных ограничений»
SIM-BIZ-16	Модель потери связи: радиовидимость по рельефу и поведение по логике РЭ	MUST	участки вне связи отмечены; по таймеру «время автономного полёта» запускается возврат на точку старта на текущей высоте с круговым облётом; отчёт содержит остаток задания и остаток энергии	РЭ 201; U-06; ДОПУЩЕНИЕ A-BIZ-02 (значения таймера нет)
SIM-BIZ-17	Модель отказа борта в момент t по кодам РЭ	SHOULD	АВАРИЯ и ОШИБКА КОМПАСА → немедленная посадка; ОШИБКА КРЛ → полёт продолжается; НАРУШЕНИЕ ЗОНЫ → камера off + полёт к месту посадки; отчёт даёт недоснятую площадь в км² и сдвиг makespan в с	РЭ 201, раздел «Действия при отказах»; сценарий s10
SIM-BIZ-18	Покрытие считается по кадрам, а не по полосам	MUST	футпринт каждого кадра строится по `payloads.yaml` (k, матрица, f) с учётом крена и сноса; `coverage_delta` к полосному покрытию выводится всегда	P-01; U-11
SIM-BIZ-19	Клиренс над рельефом и препятствиями проверяется дискретизацией ≤10 м	MUST	нарушение «<100 м AGL» для 201 → violation с координатой; «ниже точки старта» → violation; профиль клиренса выводится по всему маршруту	РЭ 201; SIM-GEO-11, SIM-GEO-23
SIM-BIZ-20	Катапультный старт: курс строго против ветра, сектор ±30°, объекты ≤0,1·L	MUST	при старте по ветру — NO-GO; при объекте выше 0,1·L в секторе — NO-GO с координатой объекта; допустимый диапазон курсов выводится для каждой площадки	РЭ 201; расхождение D-8
SIM-BIZ-21	Парашютная посадка: снижение с 70 м, эллипс сноса, проверка пересечений	SHOULD	эллипс строится и пересекается с NFZ, дорогами, водой, застройкой; коэффициент сноса — параметр с `fidelity_class: assumed`	РЭ 201; A-09, Q-12
SIM-BIZ-22	Учёт оборота на площадке по фактическим ТТХ АКБ	MUST	для Gemini интервал между вылетами одного борта ≥105 мин при заряде и ≥0 при смене АКБ; при T<0 °C заряд невозможен (ЗУ 0…+40 °C)	`fleet.yaml`; расхождения D-7, D-10
SIM-BIZ-23	Сравнение двух планов бок о бок на одном мире и seed	MUST	оба критерия ТЗ (`makespan`, `total_flight_time`) прогоняются одной командой; выход — одна таблица с дельтами	ТЗ (два критерия); U-02
SIM-BIZ-24	Учебный режим: редактируемые параметры мастера предстартовой подготовки 201	SHOULD	доступны 4 параметра с валидацией диапазонов: автоотцеп 0–300 м, время автономного полёта, напряжение возврата 16,5–20,75 В, мин. высота возврата 100–4000 м; значение вне диапазона отвергается; последствия каждого измеряются в м и мин	РЭ 201, «Предстартовая подготовка»; U-03
SIM-BIZ-25	Демо-режим: воспроизводимый 5-минутный пролёт в реальных географических координатах	MUST	числа на экране совпадают с `fact_report` до последнего знака; повтор даёт идентичную картинку и числа; работает без сети	критерий жюри «качество демонстрации»; U-05
SIM-BIZ-26	ТТХ берутся только из `fleet.yaml`/`payloads.yaml`, ничего не хардкодится	MUST	CI-проверка: в коде симулятора 0 числовых литералов из перечня ТТХ; подмена значения в YAML меняет результат прогона	правило проекта; `10-hardware/` как источник правды
SIM-BIZ-27	Симулятор не считает метрики качества плана — только факт и дельту	MUST	в выходе отсутствуют `coverage_fraction`/`makespan_s` в роли «оценки плана»; присутствуют `_fact` и `delta_`	`70-plan/01`; §4
SIM-BIZ-28	Симулятор не управляет реальными бортами и не подключается к НСУ	MUST	в коде и конфигурации отсутствуют интерфейсы к железу и MAVLink-выход в реальный канал; документировано в «известных ограничениях»	§4; безопасность полётов
SIM-BIZ-29	Класс модели объявлен явно: кинематика + энергия по средней мощности, не сертифицируемая аэродинамика	MUST	в README и в отчёте есть раздел «класс модели и её границы» с перечнем неучтённых эффектов	§4; отсутствие поляры расхода в источниках
SIM-BIZ-30	Три борта парка (201 / 801 / Gemini) поддержаны со своими ТТХ и совместимостью нагрузок	MUST	ИК-задача на не-801 → нарушение совместимости; LiDAR/геофизика → явная ошибка «нагрузки нет ни у одного борта»; мультиспектр допускается только на 201 и Gemini	`fleet.yaml`, `payloads.yaml`; расхождение «ТЗ требует LiDAR, парк его не имеет»
SIM-BIZ-31	Метео-события (порывы, снег, гроза, недоступность сети) моделируются как пороги допуска и деградация ТТХ	SHOULD	ветер 201 ≤12 м/с и 801/Gemini ≤10 м/с — жёсткие; при −20 °C применяется дерейтинг ёмкости до 30 %; все прочие пороги помечены `fidelity_class: assumed`	РЭ 201 (ветер, температура, цитата про 30 % ёмкости); A-BIZ-03 (прочих порогов в РЭ нет)
SIM-BIZ-32	`run_manifest` на каждый прогон: sha256 входов, `world_snapshot_id`, seed, версии источников данных и их релизы	MUST	по манифесту прогон воспроизводится на другой машине бит-в-бит; манифест содержит источник, релиз, дату, bbox, CRS, вертикальный датум	SIM-GEO-17, SIM-GEO-18; §6.1
SIM-BIZ-33	«Перечень известных ограничений» генерируется из данных, а не пишется руками	SHOULD	раздел документации собирается автоматически из всех величин с `fidelity_class: assumed` и отчёта чувствительности; ручных строк — 0	ТЗ п. 5 (обязательный раздел); U-12
SIM-BIZ-34	Калибровка по реальной телеметрии, если заказчик её передаст	COULD	при наличии лога: ошибка по времени вылета ≤5 %, по длине трека ≤2 %; уровень достоверности величин поднимается до V6	§6.2/V6; Q-BIZ-02

Итого: 34 требования (MUST — 22, SHOULD — 11, COULD — 1).

9. Допущения¶

Каждое допущение — что принято и чем грозит, если неверно. Допущения по ТТХ и геоданным ведутся в 01-context-digest.md (A-01…A-18) и 10-world/01 и здесь не дублируются; ниже — продуктовые.

A-BIZ-01. Время подготовки борта к вылету неизвестно. В РЭ 201 описана процедура (сборка ПУ, укладка парашюта, натяжение жгутов непосредственно перед стартом, мастер предстартовой подготовки), но времени нет ни для одного этапа; для 801 и Gemini нет и процедуры. Грозит: вся аргументация «симулятор экономит часы подготовки» остаётся качественной; модель оборота на площадке опирается только на время заряда, а не на полный цикл. Число просим у заказчика (Q-BIZ-03).
A-BIZ-02. Время автономного полёта после потери радиосвязи принимается настраиваемым параметром без значения по умолчанию. В РЭ параметр описан, диапазон и дефолт не указаны. Грозит: сценарий U-06 даёт не абсолютное число, а семейство кривых «потеря задания vs таймер». Пока значение не получено, вердикты по U-06 не могут быть GO/NO-GO — только сравнительными.
A-BIZ-03. Пороги по осадкам, снегу, грозе, обледенению и туману отсутствуют. Слова «дождь», «снег», «обледенение», «туман», «молния», «гроза» в РЭ 201 не встречаются ни разу; IP-класса бортов нет (IP67 — только у кейса Gemini). Грозит: заказчик просил эмулировать молнию и снег, а пороги допуска под них придётся назначить. Все они помечаются assumed и не используются в вердиктах GO.
A-BIZ-04. «Ночной прогон» = 8 часов. Число организационное, из источников не следует. Грозит: если реальное окно короче, целевые 100 сценариев придётся сокращать или распараллеливать.
A-BIZ-05. Целевое время сборки мира (≤10 мин на 100 км², ≤30 с из кеша) — назначенное. Ни одного бенчмарка на наших данных пока нет. Грозит: цифра может оказаться недостижимой на quantized-mesh; тогда 3D-режим ограничивается меньшей площадью, а батч работает по COG без тайлов.
A-BIZ-06. Порог «существенного» расхождения план↔факт — 10 % по makespan. Грозит: при слишком мягком пороге систематическая ошибка планировщика проходит незамеченной, при слишком жёстком — шум объявляется дефектом. Порог подлежит пересмотру после первых 100 прогонов по фактическому разбросу.
A-BIZ-07. Порог сигнала по расхождению покрытия «кадры vs полосы» — 5 %. Назначен. Грозит: тем же, что и A-BIZ-06.
A-BIZ-08. Ценность симулятора для заказчика измеряется временем и необратимостью, а не деньгами. Стоимости лётного часа, борта и вылета в источниках нет. Грозит: на защите нельзя назвать экономический эффект в рублях; аргументация строится на необратимости вылета, погодном окне и ресурсе (ТО через 80 полётов, АКБ ≥80 циклов).
A-BIZ-09. Обучение операторов — законная роль продукта, но не замена обучению у производителя. РЭ прямо требует: «к запуску допускаются лица, прошедшие обучение на базе ООО „Геоскан“». Грозит: если позиционировать симулятор как тренажёр-заменитель, это прямое противоречие РЭ. Позиционируем как дополнение: отработка настройки параметров задания, не допуск к эксплуатации.
A-BIZ-10. Достоверность симулятора сегодня доказуема максимум до уровня V5 (негативный контроль). Реальной телеметрии нет. Грозит: любое утверждение «симулятор соответствует реальности» неправомерно. Формулировка, которую используем всюду: «сверено с руководством по эксплуатации и с независимой геометрией; с реальным полётом не сверялось».
A-BIZ-11. Жюри оценивает симулятор через критерии основной задачи, а не отдельно. Симулятор усиливает «обоснованность подхода» и «эффективность маршрутов и масштабируемость». Грозит: если симулятор уводит внимание от планировщика, он вредит; отсюда правило §7.3 — планировщик сдаётся самостоятельно даже без симулятора.

10. Открытые вопросы к заказчику¶

Формат: вопрос → что меняется у нас в продукте от ответа. Вопросы по планированию (Q-01…Q-33) ведутся в docs/task5/00-brief/05-questions-to-customer.md и здесь не повторяются — ниже только те, что специфичны для симулятора как продукта.

Q-BIZ-01. Сколько стоит один вылет и сколько стоит потеря борта — в часах бригады и в деньгах? Есть ли внутренняя стоимость лётного часа по типам бортов? → Превращает ценность симулятора из качественной («экономит время») в измеримую. Заодно даёт третий критерий оптимизации планировщику — стоимость, помимо двух критериев ТЗ.

Q-BIZ-02. Есть ли логи реальных вылетов (трек, скорость, напряжение, срабатывания камеры), которые можно использовать для калибровки? Хотя бы один вылет каждого типа борта. → Единственный способ поднять достоверность с V5 до V6. Без ответа симулятор навсегда остаётся «сверенным с руководством, но не с реальностью» — и мы обязаны так и писать в отчётах.

Q-BIZ-03. Сколько времени занимает полный цикл подготовки к вылету — 201 (сборка ПУ, укладка парашюта, натяжение жгутов), 801, Gemini? И сколько занимает оборот между вылетами одного борта? → Закрывает A-BIZ-01 и расхождение D-10 (turnaround_time_min: 10). Напрямую меняет makespan многовылетных планов — то есть один из двух критериев ТЗ.

Q-BIZ-04. Кто у вас реально принимает решение «лететь / не лететь» по готовому плану и по какому чек-листу? Есть ли формализованная процедура приёмки полётного задания? → Определяет форму выхода U-01: свободный отчёт или структурированный чек-лист с теми же пунктами, что у вас. Второе встраивается в процесс, первое — нет.

Q-BIZ-05. Как часто работы срываются или переносятся из-за погоды, и какой фактор чаще всего срывает — ветер, температура, осадки, видимость? → Задаёт приоритет метео-моделирования. Если срывает не ветер (а он у нас единственный документированный порог), то приоритет — тот фактор, а его порог придётся получать от вас (A-BIZ-03).

Q-BIZ-06. Обучаете ли вы операторов и на чём? Был бы полезен тренажёр настройки полётного задания, или обучение целиком закрыто вашими курсами? → Решает судьбу роли «обучаемый оператор» и сценария U-03. Если закрыто — U-03 уходит в COULD и из демо исключается.

Q-BIZ-07. Что вы считаете достаточным доказательством того, что симулятор не врёт? Какой уровень сверки вас убедил бы — совпадение с руководством, совпадение с Geoscan Planner, совпадение с реальным полётом? → Прямо задаёт целевой уровень пирамиды §6.2 и объём работ по достоверности. Самый важный вопрос этого списка: он определяет, что вообще считать готовым продуктом.

Q-BIZ-08. Какие числа из симулятора вы готовы принимать как основание для решения, а какие — только как справку? → Определяет, какие величины обязаны иметь fidelity_class: measured|derived (и, значит, требуют источника от вас), а какие могут остаться assumed.

Q-BIZ-09. Есть ли у вас эталонная пара «план → как он отлетался»? Хотя бы один случай, где план разошёлся с фактом, и известно, почему. → Единственный способ проверить, что наше разложение дельты (SIM-BIZ-06) раскладывает по тем же причинам, которые вы наблюдаете на практике.

Q-BIZ-10. Нужен ли вам симулятор как отдельный продукт, или только как внутренний инструмент проверки планировщика? → Развилка §7.3. Если как продукт — нужны API, роли и UI приёмки (U-01, U-04); если как инструмент — достаточно headless и отчёта, и весь фронт уходит в демо-режим.