Прямой ответ: Когда платформа, зависящая от GNSS, изменяет прошивку приемника, аппаратное обеспечение радиочастотного тракта, установку антенны, программное обеспечение платформы, конфигурацию синхронизации или связанный интерфейс, рассматривайте это изменение как новую границу проверки. Запишите, что изменилось, сохраните ссылку на предыдущую конфигурацию, соберите соответствующие доказательства и согласуйте, какая проверочная деятельность все еще требуется, прежде чем делать выводы об обновленной интеграции.
Начните с четкой границы изменений
Запишите запрос на изменение, одобренный объем, затронутую платформу, место установки, идентификаторы приемника и программного обеспечения платформы, а также время, когда пересмотренная конфигурация стала доступной. Держите наблюдаемые факты отдельно от ожидаемых результатов. Запись об изменении не является доказательством того, что интегрированная система была повторно проверена.
Обеспечьте видимость владельцев приемника, радиочастотного тракта и платформы
Команды приемника, радиочастотного тракта и платформы часто хранят разные доказательства. Владелец приемника может определить конфигурацию и записи интерфейса; владелец радиочастотного тракта может определить установленный путь и состояние разъемов; владелец платформы может определить записи программного обеспечения, питания и рабочего контекста. Полезный пакет проверки называет ответственного владельца для каждого источника доказательств и временной диапазон, который он охватывает.
Сохраните ссылку на радиочастотный тракт, не воссоздавая его
Используйте существующую документацию по радиочастотному тракту GNSS для сохранения ссылки на кабель, разъем и установку. Эта статья не назначает потери радиочастотного сигнала, помехи или состояние разъема причиной наблюдаемой проблемы. Она только устанавливает, что измененный радиочастотный тракт должен быть идентифицируем для инженеров-рецензентов.
Захватите доказательства интерфейса и синхронизации
При изменении интерфейса приемника или платформы сохраните соответствующий экспорт конфигурации, сопоставление интерфейсов, эталон синхронизации и доступные необработанные записи. Существующее руководство по документу управления интерфейсом приемника может помочь командам определить доказательства, необходимые для сравнения; это не устанавливает совместимость для непроверенной конфигурации.
Свяжите изменение с записями мониторинга и инцидентов
Если существуют записи мониторинга или инцидента, сохраняйте окно события и версию конфигурации вместе. Руководство по контролю целостности GNSS и контрольный список триажа инцидентов описывают взаимодополняющие практики работы с доказательствами. Ни одна из статей не превращает запись журнала в вывод о первопричине.
Явно определите решение о повторной валидации
Инженерный руководитель должен указать, достаточно ли имеющихся доказательств только для проверки документации, необходима ли проверка интерфейса или следует запланировать контролируемую деятельность по верификации. Не делайте выводов о производительности, устойчивости, помехоустойчивости или эксплуатационной пригодности только на основании записи об изменении. Профиль PNT NIST рассматривает контроль изменений конфигурации и верификацию после интеграции или обновлений как виды деятельности по управлению рисками; это не сертификация продукта и не заявление о производительности ResiNav.
Создайте передачу доказательств, которую можно будет проверить позже
Краткая передача включает ссылку на конфигурацию до и после, ответственных владельцев, временное окно, сохраненные исходные файлы, нерешенные вопросы и следующее решение о проверке. Если требуемая информация неполна, используйте канал RFQ запросить недостающие технические данные, а не заполнять запись предположениями.
Часто задаваемые вопросы
Доказывает ли изменение конфигурации необходимость повторного тестирования платформы?
Нет. Запись об изменении определяет границу проверки. Ответственная инженерная группа решает, подходит ли для измененного объема проверка документации, проверка интерфейса или контролируемая проверочная деятельность.
Какие изменения должны быть видны в пакете доказательств?
Включите изменения, влияющие на проверяемый приемник, радиочастотный тракт, установку антенны, программное обеспечение платформы, конфигурацию синхронизации или интерфейсы, вместе с доступными ссылками до и после.
Может ли журнал мониторинга установить причину проблемы после изменения?
Нет. Журнал мониторинга может сохранить наблюдаемые события и их временную связь с эталонной конфигурацией. Сам по себе он не устанавливает помехи, отказ компонента или другую причину.
Что должно произойти, если требуемые технические данные недоступны?
Оставьте пункт помеченным как нерешенный, укажите требуемый вклад владельца или поставщика и избегайте выводов о совместимости или производительности, пока доказательства не будут рассмотрены.
Справочная структура: NISTIR 8323r1 Foundational PNT Profile. Фреймворк поддерживает только общие практики управления рисками и контроля конфигурации; он не поддерживает заявления, специфичные для продукта.
СЛЕДУЮЩИЙ ШАГ
Преобразуйте доступные сведения о платформе в инженерный обзор.
Используйте раздел «Технологии» для подготовки обсуждения, рассмотрите соответствующие сценарии применения, затем направьте доступные сведения о платформе и приёмнике для подтверждения.