Документация

Руководство пользователя СУТР Навигатор

1. Начало работы

Обзор

СУТР Навигатор — система управления требованиями, разработанная для обеспечения соответствия КТ-178С при разработке авиационного программного обеспечения. Система предоставляет инструменты для управления требованиями, трассируемости, контроля изменений, документов жизненного цикла и сертификационных артефактов.

Главная страница

Главная страница представляет четыре ключевые возможности СУТР Навигатор: Редактор документов, Трассируемость требований, Соответствие КТ-178С и Импорт/экспорт. Нажмите «Попробовать бесплатно» для регистрации или «Вход» для входа в систему.

Регистрация

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

Вход в систему

Введите адрес электронной почты и пароль для входа в систему. Используйте флажок «Запомнить меня» для сохранения сессии. Если вы забыли пароль, нажмите «Забыли пароль?» для сброса.

2. Навигация

Боковая панель

После входа рабочее пространство организовано вокруг боковой панели с разделами: Документы, Пространства, Спецификации, Изменения, Сертификация, Документы ЖЦ, Корзина и Настройки. Боковую панель можно свернуть до режима иконок. Используйте Ctrl+K для вызова глобального поиска из любого места.

3. Документы

Управление документами

Раздел «Документы» — это область общего управления документами. Создавайте документы, организуйте их в папки, фильтруйте по типу/статусу/сортировке, ищите по названию, переключайте вид между списком и сеткой. Каждый документ имеет статус (Черновик, Опубликован, Архивный), автора и дату изменения.

Редактор документов

Редактор документов основан на TipTap (ProseMirror) и поддерживает форматирование: заголовки, списки, таблицы, изображения, блоки кода и многое другое. Все изменения сохраняются автоматически с историей версий.

4. Пространства

Рабочие пространства

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

5. Спецификации и требования

Список спецификаций

Спецификации — это контейнеры для требований. Каждая спецификация имеет уникальный код (например, SRS-001), тип (SRS, SDD, HLR, LLR, IRS, STP, STD, SVP) и версию.

Детали спецификации

При открытии спецификации отображаются: заголовок с кодом и статусом, карточки статистики с количеством требований, кнопки действий (Инспекции, Базовые линии, Матрица трассируемости, Анализ покрытия, Импорт, Экспорт) и список требований в режиме Дерево или Таблица.

Табличный вид

Табличный вид предоставляет табличный интерфейс с колонками: Код, Описание, Статус, DAL, Приоритет, Верификация, Безопасность, Производное, Связи и Комментарии. Добавляйте требования, нажав «+ Добавить требование...» внизу таблицы.

Детали требования

Каждое требование имеет: Код (автогенерируемый), Содержание (с форматированием), Статусный процесс (Черновик → На инспекции → Утверждено), Приоритет (MoSCoW), Уровень DAL (A-E), Флаг безопасности, Флаг производного, Метод верификации, Обоснование, Родитель и Трассировочные связи.

6. Трассируемость и покрытие

Матрица трассируемости

Матрица трассируемости показывает связи между требованиями различных спецификаций. Типы связей: SATISFIES (зелёный), DERIVES_FROM (синий), VERIFIED_BY (фиолетовый), IMPLEMENTS (индиго), REFINES (голубой), CONFLICTS (красный), DEPENDS_ON (жёлтый) и TRACES_TO (серый). Подозрительные связи автоматически помечаются при изменении связанных требований.

Работа с подозрительными связями

Трассировочная связь помечается подозрительной автоматически, когда у одного из связанных требований меняется значимое поле — содержимое, обоснование, статус, приоритет, уровень DAL или признак безопасности. Версия требования инкрементируется, а все его трассировочные связи получают признак «подозрительная» с причиной (какие поля изменились) и датой («Подозрительна с»). Признак означает, что связь должна быть ре-валидирована инженером — по КТ-178С §5.5 (трассируемость) и §6.3 (рассмотрения и анализы): изменение наверху могло нарушить корректность связи. Связь остаётся подозрительной, пока человек её не подтвердит, — автоматически пометка не снимается. Порядок действий, чтобы сделать связь не подозрительной: (1) Найдите подозрительные связи — либо на панели трассировочных связей конкретного требования (значок ⚠), либо во вкладке «Подозрительные связи» Матрицы трассируемости / во вкладке «Пробелы» страницы трассируемости проекта; каждая строка показывает откуда, куда, тип, «Подозрительна с» и причину. (2) Откройте оба связанных требования и убедитесь, что связь по-прежнему корректна после изменения — что содержимое, обоснование и верификация остаются согласованными. Это инженерное рассмотрение, а не клик «для галочки». (3) Если связь больше не верна — сначала поправьте требование или связь (или удалите связь, если она ошибочна). (4) Когда связь подтверждена как корректная, нажмите «Снять подозрение» в её строке. Это сбрасывает признак, убирает причину и дату, фиксирует, кто и когда снял подозрение, и пишет запись в журнал аудита (SUSPECT_CLEARED). Требуется право EDIT на исходную спецификацию. (5) Для распределений DAL аналог — обновление распределения: изменение IDAL снимает признак подозрительности, выставленный при изменении FDAL.

Анализ покрытия

Анализ покрытия показывает процент требований, покрытых верификационными мероприятиями. Это поддерживает Таблицу A-7 КТ-178С, выявляя непокрытые требования, полностью покрытые требования и общий процент покрытия.

7. Системная инженерия (Р-4754А / Р-4761)

Системные проекты

Системный проект (Р-4754А / ARP4754A) находится над программным контуром и объединяет спецификации, функции системы, интерфейсы и оценки безопасности одной системы. Дашборд проекта показывает системный DAL (уровень гарантии разработки), число функций, спецификаций и оценок безопасности, привязанные спецификации по доменам (ПО / Аппаратура / Система) и сводку покрытия трассируемостью. СУТР Навигатор хранит артефакты системной инженерии и связи между ними и не диктует методологию обеспечения безопасности.

Функции системы и FHA

Функции системы образуют иерархию, полученную из оценки функциональных опасностей (FHA, Р-4761 / ARP4761). Каждая функция имеет FDAL (функциональный уровень гарантии разработки, A–E), серьёзность отказного состояния (катастрофический / опасный / существенный / незначительный / без последствий) и статус (Выявлена → Проанализирована → Распределена → Верифицирована → Закрыта). Список показывает FDAL и серьёзность рядом, что делает назначение уровня гарантии по серьёзности проверяемым. FHA/PSSA/SSA — это мероприятия оценки безопасности, они отмечаются на оценке, а не на функции.

Распределение DAL: FDAL → IDAL

Распределение DAL отображает каждую функцию системы на спецификации, которые её реализуют, присваивая каждому элементу-исполнителю IDAL (уровень гарантии разработки элемента). IDAL может быть ниже FDAL функции при обосновании архитектурой — независимостью или резервированием элементов; в этом случае требуется обоснование и устанавливается признак независимости (Р-4754А). Вкладка «Матрица» трассируемости показывает функции × спецификации с IDAL в каждой ячейке, помечает ячейки, где IDAL < FDAL, и подсвечивает распределения, ставшие подозрительными после изменения FDAL функции и требующие ре-валидации.

Оценка отказобезопасности (FHA → PSSA → SSA → CCA)

Оценки отказобезопасности следуют жизненному циклу Р-4761 / ARP4761: FHA → PSSA → SSA, а также CCA (анализ общих причин). Каждая оценка проходит статусы Черновик → В работе → Завершена → Утверждена и содержит замечания, классифицированные по серьёзности и категории (вид отказа, общая причина, независимость, пробел покрытия, ошибка проектирования). Замечание можно связать с требованиями, которые его парируют или которых оно касается, — это делает результат оценки безопасности трассируемым на набор требований. СУТР Навигатор хранит результаты оценки и связи; сам анализ остаётся зоной ответственности инженера. PSSA отображается как чек-лист разделов (перечень функций, требования безопасности, FMEA, распределение DAL, общий режим, допущения, FTA, распределение вероятностей); каждый раздел либо Нативно — закрывается данными СУТР, либо Документ — закрывается приложенным файлом. FTA и распределение вероятностей по умолчанию — Документ, до появления нативных моделей. Готовность считается по разделам, поэтому доказательство, приложенное документом, засчитывается как закрытие, а не пробел. Для раздела FTA есть нативный редактор дерева неисправностей — стройте вентили и события (Р-4761 D.4) с авто-диаграммой сверху вниз; это закрывает раздел без вложения. Редактор также выполняет количественную оценку (Р-4761 D.11): вероятность верхнего события, минимальные сечения и вероятности узлов по интенсивности отказов λ, времени миссии и логике вентилей; узлы без данных помечаются.

Деревья неисправностей (FTA)

Редактор FTA (открывается из раздела FTA у PSSA) строит деревья неисправностей структурным аутлайном с авто-диаграммой сверху вниз по символам Р-4761 D.4: вентили (И / ИЛИ / Приоритетное И / Блокировка) и события (основное / неразрабатываемое / дом / условное). Задайте интенсивность отказов λ на основных событиях, время миссии на дереве, k для Приоритетного И и условные вероятности. Панель «Анализ» считает количественный результат (Р-4761 D.11): вероятность верхнего события, минимальные сечения с их вероятностями и вероятности узлов; узлы без данных помечаются. Нативное дерево закрывает раздел FTA в PSSA без вложения.

Интерфейсы и ICD

Системные интерфейсы фиксируют связи между элементами (аппаратура ↔ ПО, система ↔ система): тип (данные / сигнал / питание / управление), исходную и целевую спецификации, протокол и детали ICD (Interface Control Document) — шина, формат данных, частота. Изменение интерфейса помечает связанные трассировочные связи подозрительными, чтобы зависимые требования прошли ре-валидацию.

Межуровневая трассируемость: Система ⇄ ПО

Страница трассируемости проекта имеет четыре вкладки: «Матрица» (функции × спецификации с IDAL), «Покрытие», «Пробелы» и «Система ⇄ ПО». Вкладка «Система ⇄ ПО» — это межуровневая матрица требований к системе × требований высокого уровня к ПО (HLR), и она реализует КТ-178С §5.5 (а) — двустороннюю трассируемость между требованиями к системе, отнесёнными к ПО, и требованиями высокого уровня. Вкладка «Покрытие» показывает четыре показателя (функции с распределением DAL, замечания с привязкой к требованиям, покрытие трассируемостью Система → ПО и покрытие верификацией по §6.4). Вкладка «Пробелы» перечисляет требования к системе без трассировки, HLR без вышестоящего требования, открытые замечания и подозрительные связи с указанием причины — связи, помеченные для ре-валидации после изменения связанного требования.

Пробелы и подозрительные связи

Вкладка «Пробелы» — рабочий список для закрытия системного контура: требования к системе без трассировки, орфанные HLR без вышестоящего требования к системе, неверифицированные требования, открытые и непривязанные замечания, подозрительные связи. Требования с признаком «производное» намеренно исключены из списка орфанных HLR — по КТ-178С §5.1.2 (b) / §5.2.2 у производного требования по определению нет вышестоящего требования, поэтому отсутствие трассировки вверх для него не пробел. Трассировочная связь или распределение DAL становятся подозрительными при изменении связанного требования или FDAL функции; после рассмотрения связь ре-валидируется, и пометка снимается.

8. Базовые линии

Базовые линии

Базовые линии фиксируют состояние требований на определённый момент времени. Процесс: Черновик → Ожидание утверждения → Утверждена (или Отклонена). Утверждённые базовые линии неизменяемы. Вы можете сравнить любую базовую линию с текущей версией.

9. Формальные инспекции

Формальная инспекция

Формальные инспекции реализуют мероприятие «Рассмотрения и анализы» КТ-178С (§6.3) — формальную инспекцию выходных результатов. Создайте инспекцию, назначьте инспекторов (минимум один независимый по КТ-178С), используйте проверочные перечни КТ-178С и отслеживайте замечания до устранения.

10. Импорт и экспорт

Обмен данными

Форматы экспорта: CSV, XLSX, ReqIF (с трассировочными связями), PDF (Список требований или Матрица трассируемости). Форматы импорта: CSV (с мастером маппинга колонок), ReqIF (с сохранением структуры и связей).

11. Управление изменениями (КТ-178С)

Панель управления

Управление изменениями реализует процесс SCM по КТ-178С. Панель показывает сводную статистику по запросам на изменение (ЗИ) и отчётам о проблемах (ОП).

Запросы на изменение

Запрос на изменение документирует предлагаемую модификацию. Процесс: Черновик → Подан → На рассмотрении → Утверждён → В работе → Проверен → Закрыт (или Отклонён). Поля: Код, Название, Тип, Приоритет, Статус, Инициатор.

Отчёты о проблемах

Отчёт о проблеме документирует дефект или аномалию. Процесс: Открыт → Подтверждён → Анализ → Исправление → Решён → Проверен → Закрыт (или Отложен). Уровни серьёзности по КТ-178С: Катастрофический, Опасный, Существенный, Незначительный, Без эффекта.

12. Сертификация (КТ-178С)

Панель сертификации

Модуль сертификации управляет артефактами, необходимыми для сертификации по КТ-178С, предоставляя обзор конфигурационных единиц, библиотек, релизов и подписей.

Конфигурационные единицы

Конфигурационные единицы (КЕ) — артефакты под управлением конфигурацией. Атрибуты: Номер КЕ, Название, Тип, Версия, Статус и Категория контроля (CC1 для DAL A-C, CC2 для DAL D-E).

Релизы

Релизы отслеживают формальные сборки ПО, привязанные к базовым линиям требований. Процесс: Черновик → Ожидание авторизации → Авторизован → Выпущен → Архивирован. Каждый релиз связан с базовой линией.

Электронные подписи

Электронные подписи обеспечивают утверждения в соответствии с КТ-178С. Каждая подпись содержит: тип, значение, подписываемый объект, временную метку и статус действительности и хранится в неизменяемом журнале. Вместе с базовыми версиями, запросами на изменение (ЗИ) и отчётами о проблемах (ОП) подписи дают проверяемую запись о том, кто и когда что утвердил, — свидетельства управления конфигурацией, ожидаемые по §7 и Таблице А-8 Приложения A.

13. Документы жизненного цикла (КТ-178С)

Список документов

КТ-178С требует документы жизненного цикла: PSAC, SDP, SVP, SCMP, SQAP, SReqS, SDS, SCS, SCI, SECI, SAS, HDD, SVD. Нажмите «Инициализировать шаблоны» для автоматического создания всех документов. Панель показывает количество документов, средства разработки и процент готовности к сертификации.

Детали документа

Каждый документ жизненного цикла содержит структурированные разделы на основе требований КТ-178С. Редактируйте разделы непосредственно в редакторе. Каждый документ показывает прогресс-бар полноты.

Средства разработки (SECI)

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

14. Интеграции (MCP, СКВ)

Интеграция с LLM через MCP

СУТР Навигатор включает встроенный MCP-сервер (Model Context Protocol) — де-факто стандарт подключения больших языковых моделей к корпоративным данным — с примерно двадцатью инструментами. Ассистент может искать требования, выявлять возможные противоречия и дубликаты, оценивать влияние изменения и готовить черновик отчёта об изменениях, работая в рамках той же модели прав, что и пользователь. Граница полномочий явная: ассистент только читает и предлагает — он не верифицирует, не утверждает и не подписывает артефакты; эти решения остаются за инженером. Для такого режима «чтение и подсказка» квалификация инструмента не требуется; квалификация по Р-330 нужна лишь тогда, когда инструмент автоматизирует мероприятие ЖЦ и его выход принимается в зачёт без верификации (КТ-178С §12.2).

Интеграция с СКВ (SVN / Git / Redmine)

Требования можно связывать с артефактами реализации и верификации во внешней системе учёта — системе контроля версий (SVN, Git) и трекере задач (Redmine), — так что требование трассируется на коммиты, тесты, запросы на изменение и отчёты о проблемах, которые его реализуют или верифицируют. Страница «Средства разработки» (SECI) регистрирует задействованные инструменты со статусом квалификации. Это сохраняет связь набора требований с кодом и тестами без дублирования этих артефактов внутри СУТР Навигатор.

15. Настройки

Настройки

Настройки разделены на четыре секции: Профиль (имя, email, аватар, язык), Безопасность (изменение пароля), Уведомления (email-уведомления) и Оформление (настройка темы).

16. Руководство по процессу КТ-178С

Фаза 1: Планирование

Создайте пространство для проекта. Инициализируйте документы ЖЦ (PSAC, SDP, SVP, SCMP, SQAP и др.). Зарегистрируйте средства разработки со статусом квалификации. Заполните планы содержанием проекта.

Фаза 2: Разработка требований

Создайте спецификации (SRS, HLR, LLR, IRS). Напишите требования с уровнем DAL, флагом безопасности, методом верификации и приоритетом. Установите трассировочные связи между спецификациями. Отметьте производные требования с обоснованием.

Фаза 3: Формальная инспекция требований

Переведите требования в статус «На инспекции». Создайте формальную инспекцию, назначьте инспекторов (минимум один независимый по КТ-178С). Используйте проверочные перечни. Устраните замечания и утвердите требования.

Фаза 4: Установление базовых линий

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

Фаза 5: Контроль изменений

Создайте запросы на изменение для изменений после базовой линии. Проведите анализ воздействия. После утверждения ЗИ реализуйте изменения. Проверьте Матрицу трассируемости на подозрительные связи. Создайте отчёты о проблемах для дефектов.

Фаза 6: Верификация

Используйте Анализ покрытия для проверки верификационных связей. Экспортируйте Матрицу трассируемости в PDF для сертификационных доказательств. Экспортируйте требования в ReqIF для обмена с другими инструментами.

Фаза 7: Сертификация

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

Карта соответствия целям (Приложение A)

Эта карта связывает возможности СУТР Навигатор с таблицами целей КТ-178С (Приложение A), а на системном уровне — с Р-4754А / Р-4761. СУТР Навигатор хранит свидетельства и связи, поддерживающие эти цели; сам по себе он их не закрывает — мероприятия ЖЦ (формальные инспекции, испытания, анализы) остаются зоной ответственности проекта.

Возможность СУТР Навигатор	Цель — таблица / раздел	Статус
Планы ЖЦ (PSAC, SDP, SVP, SCMP, SQAP) и журнал	Таблица А-1 (планирование); §11.1–11.5	Есть
Требования (HLR/LLR), производные требования, трассируемость на требования к системе	Таблица А-2 (разработка); §5.1, §5.2, §5.5	Есть
Формальные инспекции требований, статусы, трассируемость §5.5	Таблицы А-3 / А-4 (верификация требований и проектирования); §6.3	Есть
Связи требований с тестами и покрытие трассируемостью; нативное управление тестами	Таблицы А-6 / А-7 (тестирование, покрытие); §6.4	Частично (нативные тесты — в планах)
Базовые версии, версии требований, запросы на изменение, отчёты о проблемах	Таблица А-8 (управление конфигурацией); §7.2.2–7.2.4	Есть
Проверочные перечни формальных инспекций, независимость инспектора	Таблица А-9 (гарантия качества); §8	Есть
Документы ЖЦ, итоговое заключение (SAS), электронные подписи	Таблица А-10 (взаимодействие при сертификации); §11	Есть
Функции системы, FHA, распределение FDAL→IDAL, оценки безопасности	Р-4754А, Р-4761 (системный уровень)	Есть