Зеленый робот

Программная документация

Диагностика и восстановление

Модульное интегрированное ПО «Зеленый робот»

Проектная редакция · GR-FP-1.0

D09 · АСУП.466459.100-01 34 03
Редакция 2.0 · 13.09.2026

Диагностика и восстановление ​

Документ

D09 · АСУП.466459.100-01 34 03

Редакция

2.0 · Проектная редакция

Применимость

Функциональный профиль GR-FP-1.0

Продукт

Модульное интегрированное ПО «Зеленый робот»

Обозначения и сокращения раскрыты в словаре этой книги.

1. Порядок диагностики ​

Руководство описывает поиск причины и восстановление программного профиля GR-FP-1.0. Начните с наблюдаемого симптома и исходной операции. Зафиксируйте время, объект, компонент, версию, конфигурацию и command/job/run ID. Сопоставляйте факты по их источнику: интерфейс, прикладной владелец, транспорт, исполнитель и readback.

Рисунок D09.1 — Проверка движется от пользовательского симптома к владельцу операции и подтверждению на цели.

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

2. Карточка отклонения ​

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

3. Интерфейс или приложение недоступны ​

1. Проверьте адрес из паспорта, выбранный объект и пользовательскую сессию.
2. Откройте состояние хоста: процесс, readiness и список приложений.
3. Сопоставьте manifest, регистрацию, маршруты и версию приложения.
4. Проверьте ответ API приложения и его источник данных.
5. После восстановления выполните новое чтение snapshot и подписку.

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

4. Измерения устарели или имеют ошибку качества ​

Откройте показатель и прочитайте значение, единицу, время и качество. Найдите исходный сигнал по карте объекта. Сопоставьте последовательность наблюдений L0/L1/L2. Установите точку, на которой прекратилось обновление или изменилось качество.

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

Для весов отдельно проверяются свежесть и стабильность. ScaleProxy предоставляет /api/state, /api/status и /api/weight; поля weight_fresh, age_ms, active_owner и error_code уточняют причину. Потребитель массы проверяет unit=t на границе адаптера и собственную единицу хранения.

5. Команда задержана или отклонена ​

Откройте исходный command ID. Последовательно проверьте регистрацию запроса, допуск, транспортную квитанцию, результат исполнителя и readback. Для каждого этапа сопоставьте срок и время.

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

6. Ошибки MQTT, доверия и времени ​

Проверьте состояние процесса брокера и readiness, затем listener и сетевой путь. Сопоставьте principal, площадку, цепочку сертификатов, срок и отзыв. Время источника должно соответствовать условиям проверки доверия. Затем проверьте topic, направление и правило доступа.

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

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

7. Ошибки конфигурации и расчётного профиля ​

Для конфигурации прочитайте активную редакцию и digest у владельца и устройства. Сопоставьте base_revision, схему и квитанции validate/stage/apply/readback/commit. При конфликте подготовьте новый кандидат на фактической базе. При нарушении схемы исправьте адресное поле.

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

8. Прерывание установки или обновления ​

8.1. Диагностика задания ​

Откройте job ID в Развёртывание. Прочитайте исходный план, завершённые шаги, текущую цель и код. Сопоставьте digest кандидата, фактический состав и предыдущую редакцию. Проверьте, на каком этапе возникло отклонение: доставка, staging, активация, restart или readback.

8.2. Возобновление ​

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

Для ESP32 и AT32 readback выполняется отдельно. Сопоставьте target, выполняемую программу, присутствие и доступность каждого компонента. Программная копия и порядок загрузки определяются профилем конкретного MCU.

9. История, база или индекс требуют восстановления ​

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

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

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

10. Ошибки аналитики и изображений ​

Для задания M14/Visio прочитайте входной ID, schema, digest, профиль и состояние. Проверьте формат, размер, доступ к источнику, исполнителя и срок. Сопоставьте фактически использованную модель с паспортом. Результат должен соответствовать выходной схеме и ссылаться на исходные данные.

При отказе входа исправьте набор; при тайм-ауте проверьте нагрузку и допустимый ресурс профиля; при расхождении digest восстановите согласованные артефакты. Повтор обработки получает связь с исходным заданием. Для проверки используйте именованный контрольный набор и ожидаемый результат.

11. Ошибка виртуального прогона ​

Откройте run ID и определите, завершилась ли подготовка среды. Проверьте участников, artifact digest, CPU/ABI, периферию, исходный hash, модель времени и seed. Затем откройте первый метод с отклонением и его фактическое наблюдение.

FAIL относится к критерию метода; NOT_RUN содержит причину выполнения другой части программы или отказа подготовки. Для повторения восстановите тот же профиль и исходное состояние. Если меняется модель или артефакт, оформите новый прогон и сопоставьте результаты отдельно.

12. Завершение восстановления ​

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