Короткие обязательные акценты по тестированию/верификации для прошивки источника сварочного тока. Ссылается на общий контекст проекта (docs/PROJECT_CONTEXT.md) и принуждает к измеримым требованиям, доказательству таймингов, аппаратному shutdown-path (TIM1 BKIN) и fault-injection.
name test-verification-welding-short version 0.3.0 description Короткие обязательные акценты по тестированию/верификации для прошивки источника сварочного тока. Ссылается на общий контекст проекта (docs/PROJECT_CONTEXT.md) и принуждает к измеримым требованиям, доказательству таймингов, аппаратному shutdown-path (TIM1 BKIN) и fault-injection. tags ["stm32g4","freertos","tim1","adc","welding","testing","safety"] project_context docs/PROJECT_CONTEXT.md glossary docs/GLOSSARY.md when_to_use ["архитектура/изменения, влияющие на управление током, измерение, тайминги, аварии","реализация драйверов SPI/DMA/EtherCAT, state machine, регулятора, логгера","ревью PR в критичных модулях control/measurement/safety"] outputs ["Требования (измеримые) + план доказательств + критерии приёмки + fault-injection + инструментирование"] Skill: Тестирование и верификация (коротко) — сварочный источник Где брать «правду» о проекте Используй общий контекст: docs/PROJECT_CONTEXT.md (железо, тайминги, политика safe state, интерфейсы). Термины и определения: docs/GLOSSARY.md . Если есть противоречие — контекст/словарь имеют приоритет, либо предложи правку документов. Миссия Любое изменение должно быть проверяемо тестами и измерениями на железе. Никаких “должно работать” без плана доказательств. Если речь идёт о host/SIL closure, exact имена test target-ов и gate-ов брать только из docs/TEST_PLAN.md и текущих manifest-файлов. Нельзя объявлять host/SIL closure только по тексту DN , плана реализации или комментария в ответе. MUST — обязательные акценты Аппаратный safe state : Критические аварии должны выключать силовую часть аппаратно (TIM1 BKIN/BKIN2 + независимый запрет драйверов DRV_EN/INH, если есть). Избегать авто-рестарта: не полагаться на AOE; восстановление — только осознанное и явно определённое. Доказательство таймингов : Любые обещания “в середине периода”, “раз в период”, “быстро выключим” → только с планом измерений (GPIO/trace/осциллограф). Разделение логики и HAL : Control/measurement/safety логика должна быть юнит-тестируема на ПК без STM32-зависимостей. Надёжность измерений : Не доверять АЦП: диагностика stuck/sat/timeout/битые кадры + политика: единичная ошибка vs устойчивый отказ. Overrun = определённое поведение : Если критический цикл (1 мс и/или шаг управления по PWM) не успел → controlled stop или fault (по политике проекта). Никогда не “работаем вслепую”. Fault-injection обязателен : Для каждой фичи перечислить новые/затронутые отказы и ожидаемую реакцию (выключение, latch, отчёт в статус). SHOULD — желательно (если уместно) HIL до силовых прогонов: эмуляция сигналов измерений/АЦП, сценарии плохого контакта/скачков. Record/Replay: кольцевой лог (внешняя память; по Ground Truth — FRAM по QSPI, см. docs/PROJECT_CONTEXT.md ) с pre-trigger и post-trigger по fault. DFT для платы: тест-пойнты BKIN/DRV_EN/PWM/fault/опорники АЦП, возможность инъекции эталонных уровней. Контракт ответа (что выдавать в каждом релевантном ответе) Измеримые требования : что должно выполняться (единицы, границы, времена). План доказательств : какими тестами это подтвердить (Юнит host / Интеграция on-target / HIL / Силовой стенд). Критерии приёмки : latency/jitter/границы/таймауты. Fault-injection список (минимум 5 для критичных изменений) + ожидаемый safe state / latch / recovery. Инструментирование : какие сигналы/логи снять. Минимум debug-пины: CTRL_TICK, ADC_START, ADC_READY, PWM_APPLY, FAULT_ENTRY + наблюдение BKIN_RAW и PWM_OUT. Риски (топ-3) : как может сломаться и какой тест это поймает. Нельзя Писать “скорее всего успеет/должно работать” без измеримого плана. Делать safety-shutdown зависимым только от RTOS/обычных ISR. Принимать невалидные команды/данные измерений без явной реакции и статуса.