Диагностический алгоритм от симптома к гипотезе

Диагностика начинается не с замены «подозрительных» деталей, а с точного описания симптома: что именно не работает, при каких условиях, постоянно или периодически, после какого события и что при этом остаётся исправным. Чем конкретнее symptom, тем меньше пространство гипотез.

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

• Symptom описывают измеримо: «Vout=0 В при Vin=12 В и load=0,5 А», а не «плата мёртвая».
• До подачи питания выполняют visual inspection и безопасные passive checks.
• Проверка питания, reset, clocks/references обычно предшествует сложному анализу данных.
• Каждая гипотеза должна иметь измерение, которое способно её подтвердить или опровергнуть.
• После ремонта исходный symptom воспроизводят заново и проверяют, что причина устранена, а не просто исчезла временно.

Систематический алгоритм похож на binary search: вместо проверки каждого компонента отделяют «исправная часть / неисправная часть» по контрольным точкам. Например, если input regulator выдаёт правильные 5 В, но local 3,3 В отсутствует, бессмысленно начинать с UART.

Hypothesis должна объяснять весь набор фактов. Если предполагаемый «сгоревший controller» не объясняет abnormal current ещё до его питания, гипотеза слабая. Диагностика постоянно обновляет модель устройства по новым измерениям.

Возьмите учебную плату с заранее введённой неисправностью и ведите журнал: symptom → hypothesis → test → result → next hypothesis.

1. Запишите symptom и условия воспроизведения.
2. Нарисуйте функциональные блоки и ключевые rails/signals.
3. Выполните безопасные проверки без питания.
4. Проверяйте блоки в порядке, фиксируя expected/measured.
5. После нахождения причины восстановите узел и повторите полный functional test.

• Начинать с массовой замены компонентов без измерений.
• Путать symptom с причиной.
• Менять несколько переменных одновременно и терять доказательство.
• После случайного восстановления не пытаться воспроизвести исходный fault.

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

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