«No funciona» no es un diagnóstico: es el punto de partida
Llegas al punto y te dicen «el radar no está multando». Es un síntoma, no un diagnóstico. Podría ser el radar, la zona descalibrada, la óptica sucia, el medio lleno, el enlace caído o el reloj desincronizado —cinco cadenas distintas con soluciones distintas. Cambiar piezas al azar hasta que funcione es caro, lento y, lo peor, deja la causa raíz sin identificar para que vuelva.
El troubleshooting profesional es un método: señalar (describir el síntoma con precisión), aislar (reducir en qué cadena está usando descarte ordenado) y verificar (confirmar la causa y que la corrección la soluciona, con prueba). Este OA te da el método y los árboles de decisión de los síntomas que más verás.
El método en tres tiempos
Señala · Aisla · Verifica
1. Señalar
Define el síntoma con datos: QUÉ falla, DESDE cuándo, en QUÉ condiciones (¿solo de noche? ¿solo un carril? ¿tras la tormenta?). Un síntoma bien descrito ya mitad del diagnóstico resuelto.2. Aislar
Usa el árbol de decisión para reducir a una cadena (energía, medición, evidencia, datos). Descarta de lo barato/barato a lo caro: primero configuración y conexiones, después hardware.3. Verificar
Antes de cerrar, confirma la causa (¿explica TODOS los síntomas?) y que la corrección funciona con una prueba real. Documenta el camino de descartes: vale para hoy y para la próxima vez.
Paso 1 de 3
Árboles de los cinco síntomas rey
| Síntoma | Primera rama a descartar | Siguiente | Causa raíz típica |
|---|---|---|---|
| Sin lectura de radar | ¿Equipo encendido y en modo de tráfico? | Zonas/geometría y distancia | Zona descalibrada o haz fuera del carril |
| Imagen oscura/borrosa | Óptica sucia o empañada | Obturación/ganancia e iluminación | Suciedad, o exposición mal ajustada |
| Sin conexión | Físico del enlace (cable/antena/4G) | IP/DNS y servicio del back-office | Enlace caído o credencial/destino mal configurado |
| Falsos disparos | Umbral/límite configurado | Zona que invade otro carril u objeto reflectante | Geometría o umbral mal puestos |
| Reloj desincronizado | Servidor NTP accesible | Zona horaria y batería de respaldo | NTP caído o pila de reloj agotada |
Un equipo «no está midiendo» solo en el carril izquierdo; los demás carriles funcionan. Aplicando señala-aisla-verifica, la primera acción MÁS eficiente es:
Una vez encontrada y corregida la falla, el trabajo terminó; documentar los descartes hechos es burocracia opcional.
Une cada síntoma con su primera rama de descarte según el árbol:
Recuerda una falla real que te hizo perder mucho tiempo. Reescríbela con el método: ¿cómo la SEÑALASTE (qué datos te faltaron)?, ¿por qué rama empezaste a AISLAR (ibas a lo barato o a lo caro)?, ¿VERIFICASTE la causa raíz o «funcionó y ya»? Escribe qué habrías hecho distinto con un árbol de decisión en mano.
La mayoría de las pérdidas de tiempo vienen de no señalar bien el síntoma: «no funciona» esconde si es un carril o todo, de noche o siempre.
Tu texto se guarda sólo en este dispositivo.
- «No funciona» es un síntoma, no un diagnóstico: hay que señalar, aislar y verificar.
- Descarta de lo barato y probable a lo caro: configuración y conexiones antes que hardware.
- La especificidad del síntoma (un carril, solo noche) acota la cadena culpable.
- Muchos «problemas de radar» son geometría, exposición o enlace, no el sensor.
- Documenta descartes y causa raíz: evita repetir el diagnóstico y prueba la resolución.
Siguiente paso: dominas fundamentos, sitio, las tres marcas, evidencia y diagnóstico. El OA final —Taller integrador— te pone delante un caso real completo: elige punto, monta, configura, produce evidencia defendible y defiende tu sistema ante la audiencia que lo revisa.
Comentarios
Inicia sesión para comentar.
Todavía no hay comentarios. Sé la primera persona en opinar.