1. Taxonomía y fronteras de las cinco subclases

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La actualización suele utilizar programación como mecanismo. La codificación puede escribir parámetros; la parametrización puede distribuirse dentro de un paquete de actualización. La clasificación es funcional: explica la finalidad y la validación, sin exigir que los fabricantes usen los mismos nombres.

En este manual, «programar» no significa necesariamente desarrollar código fuente. En el taller suele significar instalar contenido ejecutable o datos aprobados en una unidad. «ECU» se usa de forma general para unidad de control electrónico y no exclusivamente para la centralita del motor.

Volver al índice ↑

2. Operaciones relacionadas que no son equivalentes

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Las etiquetas comerciales son ambiguas. Antes de pulsar una función, leer qué modifica, cuándo se utiliza, qué condiciones exige y cómo se deshace o recupera si no termina. Una herramienta puede agrupar programación, codificación y aprendizaje en un único asistente de sustitución.

La expresión «reset de adaptaciones» requiere identificar qué valores se eliminan. Un conjunto desgastado puede funcionar peor después del borrado porque pierde compensaciones adquiridas. La necesidad del reset debe estar vinculada a una reparación o procedimiento, no a la esperanza de que desaparezca un síntoma.

Volver al índice ↑

3. Arquitectura de software y memorias

Una ECU puede contener cargador de arranque, aplicación, datos de calibración, configuración, valores aprendidos, registros de diagnóstico e información de identidad o seguridad. Estas categorías no tienen por qué ocupar chips distintos. La memoria no volátil puede incluir flash, EEPROM o emulación de EEPROM; la RAM conserva estados temporales que normalmente se pierden al retirar alimentación.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No asumir que una lectura por diagnosis constituye una copia completa de memoria. Tampoco que una copia binaria permite restaurar una ECU distinta: las identidades, claves, geometrías de memoria, revisiones y protecciones pueden impedirlo. Las funciones de taller deben emplear el contenido y la ruta aprobados.

Volver al índice ↑

4. Identificación y compatibilidad

Registrar VIN, modelo, fecha de fabricación, mercado, motorización, transmisión, tracción, equipamiento y reparaciones relevantes. Para cada ECU afectada, recoger referencia de pieza, revisión de hardware, identificadores de software y calibración, configuración y número de serie cuando sea accesible.

La etiqueta de carcasa y la lectura electrónica son evidencias complementarias. Una unidad reparada, sustituida o reutilizada puede no corresponder a la configuración original. Ante discrepancias, detener la selección de archivos hasta resolverlas.

La compatibilidad tiene varias dimensiones:

• Física: conectores, alimentación, etapas de potencia, sensores y actuadores soportados.
• Lógica: aplicación, formato de datos, bootloader y protocolo diagnóstico.
• Funcional: equipamiento, estrategia y capacidades habilitadas.
• De red: mensajes, unidades participantes y versiones compatibles.
• De servicio: referencia sustituida por otra, procedimiento y acceso disponibles.
• De mercado: configuración autorizada y documentación aplicable.

Una referencia más nueva no demuestra por sí sola que sea una sustitución válida. La cadena de sustitución de piezas debe verificarse en el catálogo y procedimiento correspondientes. Un paquete seleccionado manualmente «por parecido» elimina precisamente las comprobaciones que debería garantizar el sistema de servicio.

Volver al índice ↑

5. Diagnóstico antes de modificar software

Definir el síntoma de forma reproducible: qué ocurre, cuándo, duración, temperatura, velocidad, carga, estado de batería, mensajes y operaciones recientes. Guardar el escaneo completo y los datos de entorno antes de borrar o reiniciar.

Una hipótesis de software gana apoyo cuando el síntoma y la variante coinciden con documentación técnica aplicable, las condiciones de detección son coherentes y se han descartado las causas físicas requeridas. La simple presencia de un DTC o la disponibilidad de una versión posterior no basta.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

El diagnóstico debe plantear una prueba que diferencie alternativas. Si una señal presenta cortes físicos en el conector, actualizar la ECU no corrige esa discontinuidad. Si la configuración indica un sensor no instalado, cambiar el sensor «ausente» tampoco resuelve la identidad de variante.

Volver al índice ↑

6. Documentación, herramientas y alcance real

El conjunto de trabajo comprende información OEM, aplicación de servicio, suscripción cuando proceda, interfaz validada, controladores, firmware de la interfaz y equipo informático compatible. Que una herramienta pueda leer DTC no implica que pueda programar esa ECU ni completar su emparejamiento.

Las interfaces Pass-Thru J2534 proporcionan una vía normalizada de comunicación con aplicaciones compatibles; no contienen por sí solas todos los archivos, licencias o permisos del fabricante. La compatibilidad debe comprobarse para la aplicación y operación concretas. Bosch Diagnostics — J2534 FAQ.

Antes de una sesión, revisar soporte del sistema operativo, versión de aplicación, biblioteca de comunicaciones, interfaz seleccionada y adaptadores requeridos. No actualizar el ordenador o firmware de interfaz en medio de una intervención. Los cambios de entorno deben verificarse antes de conectar el vehículo para escribir.

Distinguir una función declarada comercialmente de una función cubierta en la combinación exacta vehículo/ECU/procedimiento. La programación remota requiere además delimitar quién controla cada paso, quién mantiene el vehículo seguro y dónde se conserva el registro. La persona situada junto al vehículo mantiene las comprobaciones físicas que un operador remoto no puede observar.

Volver al índice ↑

7. Alimentación y estabilidad del puesto

La ECU necesita tensión estable en sus terminales durante toda la operación. La lectura del equipo de soporte no acredita por sí sola lo que llega a la unidad bajo carga. Una batería degradada, un borne deficiente o una masa resistiva pueden producir caídas aunque la tensión media parezca suficiente.

Usar el modo y equipo de soporte indicados por el fabricante del vehículo y la herramienta. La corriente disponible debe cubrir el consumo real y los transitorios dentro de las especificaciones. No emplear un modo de desulfatación, arranque o pulsos que no esté autorizado para esta tarea. No hay una consigna universal válida para todos los sistemas de 12, 24 o 48 V.

Comprobar conexiones, ventilación, alimentación de red y posibilidad de interrupciones. Configurar el ordenador para que no suspenda ni reinicie automáticamente durante la sesión, conforme a las instrucciones de la aplicación. Evitar conexiones USB inestables o adaptadores no validados; utilizar el transporte recomendado, sea cableado o inalámbrico.

En vehículos electrificados, la batería de alta tensión y el convertidor DC/DC no garantizan automáticamente estabilidad de la red auxiliar durante programación. Su estado puede cambiar por estrategia o por el modo de servicio. Confirmar cuándo debe estar activo el vehículo, conectado a carga o aislado: son decisiones específicas del procedimiento, no reglas intercambiables.

Volver al índice ↑

8. Seguridad, autorizaciones y datos

Las rutinas pueden mover dirección, frenos, suspensión, compuertas, ventanillas, transmisión o ventiladores. Otras modifican la capacidad de arranque o deshabilitan funciones mientras trabajan. Delimitar el área, inmovilizar el vehículo según el procedimiento y advertir a quienes compartan el puesto.

Los trabajos sobre SRS, sistemas de freno, refrigerante o alta tensión mantienen sus requisitos físicos aunque se inicien desde una pantalla. La capacidad de ejecutar una rutina no sustituye la formación ni la preparación del sistema.

Las funciones protegidas pueden exigir credenciales personales, autorización del propietario, comprobación de identidad o conectividad con un servicio del fabricante. NASTF ofrece en su ámbito un modelo de acceso seguro para profesionales; no constituye un permiso universal ni sustituye los mecanismos de otras regiones. NASTF — VSP Registry.

Conservar únicamente datos necesarios: VIN, versiones, resultados, identificadores de operación y evidencia técnica. Proteger cuentas y archivos; no incluir contraseñas, tokens o secretos en informes para clientes. Diferenciar consentimiento para reparar de autorización para activar servicios, suscripciones o cambios de equipamiento. Registrar los cambios de funciones que puedan afectar al uso del vehículo.

Volver al índice ↑

9. Finalidad y modalidades de programación

La programación instala contenido que la ECU utilizará para arrancar, controlar o interpretar datos. Puede formar parte de la sustitución de una unidad, de una actualización, de una recuperación o de una campaña. Antes de empezar debe quedar claro si se escribirá la aplicación, determinados bloques, datos auxiliares o una combinación gestionada por el fabricante.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No todas las ECU de recambio se suministran vacías. Algunas contienen software básico, otras llegan preconfiguradas y otras requieren conexión al servidor para completar identidad y datos. Una unidad usada puede tener restricciones adicionales que impidan su reutilización. Confirmarlo antes de desmontar la original.

La clonación de memoria y la programación de servicio son conceptos distintos. Una copia indiscriminada puede trasladar fallos, configuraciones o identidades improcedentes; no debe presentarse como equivalente universal a instalar un recambio por el procedimiento previsto.

Volver al índice ↑

10. Ciclo lógico de una operación de escritura

Una operación puede incluir identificación, comprobaciones previas, acceso a una sesión específica, autorización, preparación de memoria, transferencia, verificación, activación y reinicio. El orden y la presencia de cada fase dependen de la implementación.

Identificación y compatibilidad
        ↓
Precondiciones y autorización
        ↓
Preparación de la unidad y del contenido
        ↓
Transferencia de bloques
        ↓
Verificación y aceptación
        ↓
Activación / reinicio según procedimiento
        ↓
Configuración, aprendizajes y validación

El porcentaje de progreso es una representación de la aplicación, no una medida directa del estado de toda la ECU. Llegar al 100 % de transferencia puede preceder a comprobaciones, sincronización o activación. Tampoco un intervalo sin cambio de porcentaje demuestra un bloqueo.

Hay que distinguir «archivo descargado al ordenador», «contenido transferido a la ECU», «contenido verificado» y «software activo». Guardar el resultado final de la herramienta y comprobar la identificación posterior. Si se solicita un ciclo de contacto, ejecutarlo en ese momento y de la forma indicada, sin anticiparlo por costumbre.

Volver al índice ↑

11. Redes, transporte y acceso diagnóstico

La comunicación puede atravesar el conector de diagnóstico, una interfaz, un gateway y varias redes antes de llegar al destino. La ECU puede responder a identificación y rechazar programación porque las condiciones, permisos o capacidades requeridos son diferentes.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una sesión de programación puede modificar temporalmente la comunicación normal del vehículo y generar DTC de pérdida de mensajes en otras unidades. Deben identificarse como inducidos solo cuando la secuencia y la comprobación posterior lo respalden.

Los sistemas antiguos pueden utilizar K-Line, KWP u otros métodos. No asumir que una descripción moderna de UDS corresponde a toda la flota. La herramienta guiada debe gestionar direcciones, sesiones, temporización y adaptación al protocolo específico.

Volver al índice ↑

12. Servicios diagnósticos y lectura de registros

UDS incluye familias de servicios para sesiones, lectura y escritura de datos, rutinas, transferencia, reinicio y control de acceso. Sus identificadores ayudan a interpretar una traza, pero no constituyen instrucciones suficientes para programar una ECU. Las direcciones, formatos y precondiciones son específicos. CSS Electronics — Introducción a UDS.

En un registro conviene distinguir la petición de la respuesta, el servicio de la rutina ejecutada y el resultado de transporte del resultado funcional. Una respuesta aceptando iniciar una rutina puede requerir una consulta posterior para conocer su finalización. Una respuesta pendiente requiere respetar la temporización gestionada por la herramienta, no reenviar órdenes indiscriminadamente.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No modificar temporizadores o repetir accesos protegidos para forzar una respuesta. Registrar el texto exacto y el código, si está disponible, y consultar la interpretación de la aplicación. Un mensaje genérico del ordenador puede ocultar una causa más precisa en el log.

Volver al índice ↑

13. Preparación específica y decisión de iniciar

La preparación se cierra antes de la escritura. Confirmar la finalidad, la referencia del procedimiento, las condiciones mecánicas y eléctricas, las versiones actuales y el contenido objetivo. Si el proceso requiere varias unidades, disponer del plan completo, no solo del primer archivo.

1. Guardar escaneo global, identificaciones y configuración accesible.
2. Comprobar aplicabilidad del procedimiento y compatibilidad del recambio, si existe.
3. Verificar software de servicio, interfaz, licencias y conectividad necesaria.
4. Preparar soporte eléctrico, puesto y ordenador.
5. Definir el estado del vehículo, llaves, consumidores y dispositivos conectados.
6. Identificar qué datos se conservan y qué aprendizajes pueden perderse.
7. Confirmar operaciones posteriores, útiles y capacidad de validarlas.
8. Localizar el procedimiento de recuperación o soporte aplicable.

No iniciar si falta un elemento que será obligatorio después: una ECU que se puede programar pero no codificar o calibrar puede dejar el vehículo indisponible. Esta evaluación debe incluir disponibilidad de espacio, alineador, objetivos ADAS, credenciales o componentes adicionales.

El criterio de interrupción antes de escribir es diferente al de una escritura ya activa. Una vez iniciada, no cortar alimentación por un mensaje ambiguo: conservar condiciones y seguir la respuesta prevista por la aplicación, salvo una situación física de emergencia que exija proteger a las personas.

Volver al índice ↑

14. Ejecución supervisada

Durante la programación, observar el estado de la aplicación, la alimentación y los mensajes del vehículo. Evitar abrir puertas, activar consumidores, cambiar de cuenta, desconectar interfaces o iniciar otra herramienta salvo indicación del procedimiento. Las acciones aparentemente inocuas pueden despertar redes o alterar precondiciones.

Registrar hora de inicio, ECU objetivo, paquete, identificador de sesión y eventos. No es necesario capturar cada porcentaje; sí conservar los puntos de cambio de fase, mensajes de excepción y resultado final. Si interviene soporte remoto, registrar su referencia y las instrucciones relevantes sin almacenar secretos.

No interpretar ruidos de relés, activación de ventiladores o avisos transitorios como averías nuevas sin relacionarlos con el modo de programación. A la inversa, no normalizar olor, calentamiento anormal o pérdida de estabilidad eléctrica: son observaciones físicas que requieren evaluación inmediata.

Al finalizar, respetar los ciclos de alimentación y los tiempos indicados. Leer de nuevo la identificación, completar las tareas solicitadas y revisar el conjunto de unidades afectadas. Una captura de «éxito» es evidencia de una fase, no el informe final de reparación.

Volver al índice ↑

15. Fallos e itinerarios de recuperación

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No declarar una ECU irrecuperable únicamente porque no aparece en el escaneo normal. Puede responder por una ruta de recuperación distinta; también puede tener un problema de alimentación o red. La ruta correcta se determina con información técnica y soporte, sin ensayar archivos alternativos al azar.

Tampoco prometer recuperación automática: depende del diseño, fase, contenido y estado físico. Si una acción de recuperación falla, conservar la nueva evidencia y escalar con un expediente completo. Repetir sin cambiar la causa aumenta tiempo y puede complicar el diagnóstico.

Volver al índice ↑

16. Sustitución de módulos y cierre de programación

La sustitución suele requerir más que escribir software. Puede incluir transferencia de configuración, instalación de datos por VIN, vinculación autorizada, ajustes básicos, calibraciones y pruebas. Leer la unidad original antes de retirarla cuando el procedimiento lo indique.

La documentación histórica de Ford FMP ilustra la separación entre instalación programable de un módulo y recuperación de datos As-Built cuando no se ha podido leer la configuración original. Ese ejemplo explica un concepto; no debe trasladarse como secuencia universal a plataformas o herramientas actuales. Ford — FMP User Guide, documento histórico.

Comprobaciones de cierre: la referencia instalada corresponde a la operación, el software activo es el esperado, la configuración coincide con el vehículo, no quedan modos de servicio abiertos y las funciones compartidas se comportan correctamente.

Si el motor arranca pero el control de crucero no funciona, la puesta en servicio puede seguir incompleta. Si desaparecen los DTC pero la función nunca se ha probado, solo se ha comprobado el estado de diagnóstico disponible. Documentar el alcance real y no confundir una unidad comunicante con un vehículo validado.

Volver al índice ↑

17. Parámetros, datasets y variantes

Parametrizar consiste en asignar valores que una aplicación utiliza para describir su entorno o ajustar un comportamiento previsto. Puede tratarse de un único valor, un bloque estructurado o un dataset completo suministrado por el fabricante. No siempre existe acceso individual a cada parámetro desde el equipo de taller.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una ECU con software correcto y dataset incorrecto puede comunicar sin problemas y controlar mal. El error puede aparecer como desviación de respuesta, DTC de plausibilidad o función inhibida. La búsqueda debe incluir la identidad de los datos, no solo el número de versión de la aplicación.

Los términos dataset, archivo de parámetros y calibración pueden solaparse según fabricante. Registrar el nombre exacto que muestra la herramienta y su función, evitando convertir toda escritura de datos en «actualización».

Volver al índice ↑

18. Representación, unidades y trazabilidad

Un número de memoria no tiene significado físico sin tipo de dato, escala, signo, unidad y versión de descripción. «100» puede representar un porcentaje, una temperatura escalada, un índice o un estado. La herramienta debe interpretar correctamente el esquema correspondiente.

En ingeniería, ASAM MCD-2 MC/A2L describe variables, parámetros y su conversión a magnitudes interpretables. No es por sí mismo un archivo de actualización ni una autorización para modificar una ECU de producción. ASAM — MCD-2 MC.

Para un cambio de parámetro registrar:

• Nombre exacto, identificador y unidad.
• Valor anterior, valor solicitado y valor leído después.
• Procedencia de la especificación y revisión documental.
• ECU, aplicación y dataset sobre los que se aplica.
• Condiciones de escritura, persistencia y validación.
• Motivo técnico y operaciones relacionadas.

El separador decimal, las unidades regionales y las conversiones del equipo pueden inducir errores. No copiar un valor de una captura sin comprobar su unidad. Si la interfaz presenta un valor traducido o redondeado, conservar el archivo exportado cuando exista y distinguir resolución mostrada de precisión efectiva.

Volver al índice ↑

19. Selección y validación de conjuntos de datos

La selección debe basarse en la combinación autorizada de hardware, aplicación, vehículo y equipamiento. Un archivo que la ECU acepta no queda automáticamente demostrado como adecuado al vehículo. La comprobación puede exigir contraste con el servidor, referencia de pieza, lista de opciones y características físicas.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Un conjunto de datos puede incluir valores no visibles por separado. Evitar reconstruirlo mediante ajustes aislados extraídos de otro vehículo. La diferencia entre dos datasets puede afectar a funciones que no son evidentes en una prueba breve.

Cuando el sistema asigna datos automáticamente por VIN, verificar que la identidad leída sea correcta y que las modificaciones oficiales del vehículo estén registradas. El VIN no corrige por sí solo una pieza físicamente incompatible ni informa de todo cambio no documentado.

Volver al índice ↑

20. Parametrización de motor, inyección y transmisión

En sistemas que lo requieren, la caracterización de inyectores relaciona el código individual con el cilindro y el componente instalado. Confirmar que el código es legible, válido para esa familia y asignado según la numeración del fabricante. Que un código tenga formato aceptado no demuestra que pertenezca al inyector correcto.

La escritura no repara fugas, retorno excesivo, compresión deficiente ni fallos eléctricos. Después deben efectuarse las comprobaciones y aprendizajes indicados, con condiciones de temperatura y funcionamiento definidas para ese sistema.

En transmisiones pueden existir datos de identificación de mecatrónica, cuerpo de válvulas o elementos caracterizados. Distinguir esos datos de los valores adaptativos aprendidos durante el funcionamiento. Un recambio puede exigir un dataset, codificación y aprendizaje, cada uno con su validación.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La validación de par, emisiones y protección mecánica excede una prueba de arranque. Mantener la configuración aprobada para el conjunto motor-transmisión y sus sistemas de postratamiento.

Volver al índice ↑

21. Parametrización de chasis, carrocería y energía

En chasis, un dataset puede relacionarse con suspensión, dirección, frenos o variante de vehículo. Las diferencias pueden afectar a asistencia, control de estabilidad o gestión de carga. No utilizar una variante deportiva, de otra batalla o de otro mercado como supuesto sustituto de una referencia ausente.

En carrocería pueden existir parámetros de iluminación, remolque, cierre o gestión de consumidores. Confirmar que actuadores, cableado, fusibles y supervisión admiten la función. Un ajuste de salida no convierte una etapa de potencia en apta para una carga diferente.

En gestión de energía, distinguir:

• Declaración de tipo o capacidad de batería, si el sistema permite y exige esa configuración.
• Registro de sustitución, que informa de una batería nueva según el procedimiento.
• Aprendizaje de estado, que depende de mediciones y funcionamiento.

No declarar una batería nueva para encubrir degradación ni introducir una capacidad arbitraria. En alta tensión, la sustitución de componentes y la inicialización del BMS pueden requerir controles adicionales de compatibilidad, aislamiento, equilibrio y estado energético. Una operación de software no acredita la seguridad eléctrica del conjunto.

Volver al índice ↑

22. Procedimiento general de parametrización

1. Definir el dato que necesita cambiar y la razón.
2. Identificar ECU, software, dataset y componente físico relacionado.
3. Leer y guardar los valores actuales mediante la función admitida.
4. Obtener el valor o dataset desde documentación o servicio autorizado.
5. Cumplir precondiciones de alimentación, estado y acceso.
6. Ejecutar la escritura guiada y guardar su resultado.
7. Realizar reinicio, ciclo o confirmación solo cuando se indiquen.
8. Leer de nuevo y verificar persistencia y coherencia.
9. Ejecutar las pruebas físicas y funciones compartidas afectadas.

La lectura posterior debe hacerse desde la ECU cuando sea posible, no solo desde el formulario que retiene el valor escrito. Diferenciar el valor solicitado del efectivamente almacenado. Si la herramienta convierte unidades, comparar en la misma representación.

Cuando se escribe un conjunto completo, comprobar su identificador y las funciones que el procedimiento enumera. No desmontar la coherencia del dataset con cambios individuales posteriores no previstos. Una prueba satisfactoria en reposo puede no cubrir condiciones de marcha, carga, temperatura o suspensión.

Volver al índice ↑

23. Errores de parametrización y diagnóstico

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No revertir automáticamente si la operación alteró dependencias o migró datos. Confirmar si el estado anterior es restaurable por el procedimiento autorizado. En algunos casos la corrección consiste en instalar el conjunto correcto, no en escribir el valor antiguo.

Si una unidad rechaza repetidamente un dataset supuestamente válido, revisar hardware y aplicación antes de atribuir el problema a memoria dañada. Si lo acepta pero el efecto es incorrecto, investigar también el sistema físico. La escritura correcta y el comportamiento correcto son evidencias diferentes.

Volver al índice ↑

24. Validación y control de cambios de parámetros

La validación combina lectura, persistencia, plausibilidad y función. Definir de antemano qué variable debe cambiar, en qué condiciones y con qué criterio. Si no existe acceso de lectura al parámetro, utilizar la evidencia de identificación y verificación prevista por el fabricante, dejando constancia de esa limitación.

Para cambios múltiples, conservar una lista completa. Cuando el procedimiento permita separarlos, evitar modificar simultáneamente variables independientes porque se pierde capacidad de atribuir el resultado. Cuando exija un dataset coherente, mantenerlo como una unidad de cambio.

Un ejemplo didáctico: después de instalar un sensor de altura, el vehículo muestra una altura calculada incoherente. Antes de alterar un parámetro, comprobar referencia, bieleta, orientación, alimentación y señal. Si el componente es correcto y el procedimiento prescribe introducir una medida física, documentar punto de medida, unidad, instrumento y valor. Introducir una cifra para «dejar el vehículo nivelado» puede ocultar un error de montaje.

El informe debe explicar qué dato cambió y qué prueba demuestra su adecuación. «Parametrizado correctamente» sin referencia de conjunto, resultado y validación no permite repetir ni auditar la intervención.

Volver al índice ↑

25. Configuración de variante y equipamiento

La codificación describe cómo debe comportarse una unidad dentro de una configuración admitida. Puede seleccionar tipo de transmisión, lado de conducción, equipamiento, arquitectura de iluminación o presencia de módulos. No equivale a instalar físicamente esos elementos.

La configuración puede residir en una unidad, repartirse entre varias o derivarse de un registro central del vehículo. En consecuencia, escribir un único módulo puede dejar incoherencias con gateway, cuadro, unidad de carrocería o servidor.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una codificación válida estructuralmente puede ser incorrecta funcionalmente. Las comprobaciones de formato no detectan necesariamente que el vehículo carece del sensor, del cableado o del actuador declarado.

Volver al índice ↑

26. Datos de fábrica, estado actual y modificaciones

Conviene conservar tres referencias: configuración de fabricación, configuración leída al entrar en taller y configuración objetivo aprobada. Pueden coincidir, pero no debe suponerse. El vehículo puede haber recibido reparaciones, campañas o reequipamientos legítimos desde su fabricación.

Los datos As-Built u otras descripciones de origen sirven para reconstruir la configuración dentro del proceso correspondiente. Su aplicación exige conocer qué representan y cómo se actualizan en esa plataforma. No son una copia universal de toda la memoria ni una lista completa de estados aprendidos.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Si se desconoce el origen de una modificación, documentarla antes de restaurar valores. Un restablecimiento indiscriminado puede retirar una función legítima o reintroducir una configuración anterior. Resolver la discrepancia mediante catálogo, documentación, inspección física y, cuando corresponda, soporte del fabricante.

Volver al índice ↑

27. Codificación después de sustituir una ECU

Antes de la sustitución, averiguar si la configuración se transfiere desde la unidad original, se descarga por VIN, se calcula a partir del vehículo o se introduce por una función guiada. Si la original está dañada, utilizar la alternativa documentada; no copiar la de otro vehículo de apariencia similar.

La secuencia puede exigir primero programación, después codificación y finalmente aprendizaje o calibración. En otras arquitecturas el asistente gestiona esas fases internamente. Registrar lo que solicita la herramienta y no convertir la secuencia de una marca en una regla general.

Tras codificar, comprobar:

• Identidad y referencia de la unidad instalada.
• Equipamiento reconocido por las unidades dependientes.
• Ausencia de incompatibilidades de variante.
• Funcionamiento de entradas, salidas e indicaciones relevantes.
• Operaciones posteriores pendientes, incluyendo funciones protegidas.

Un módulo de carrocería puede controlar muchas funciones aparentemente ajenas a la avería inicial. La validación debe cubrir las salidas afectadas por la sustitución y el conjunto de configuración, no solo el síntoma que motivó el cambio. Los DTC de equipos ausentes orientan hacia variante o red, pero deben compararse con la instalación real.

Volver al índice ↑

28. Reequipamientos y cambios de funciones

Un reequipamiento técnicamente válido combina piezas, instalación, software, configuración, calibración y documentación. La mera existencia de una opción en la herramienta no demuestra que el fabricante admita activarla en ese vehículo.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Un ejemplo es un módulo de remolque: no basta con activar «remolque instalado». Deben existir instalación compatible, supervisión y coherencia de las funciones que dependen de ese estado. La lista exacta de unidades y operaciones corresponde al fabricante.

Los cambios de iluminación, avisos, asistencia o prestaciones pueden afectar a requisitos de uso y homologación. Verificar la configuración permitida en el mercado correspondiente mediante información aplicable; este manual no determina la legalidad de una modificación concreta. No desactivar una función de seguridad para eliminar un mensaje sin resolver su causa.

Volver al índice ↑

29. Protección de componentes y vinculación

La codificación de equipamiento y la vinculación de seguridad son procesos diferentes. Una unidad puede estar correctamente configurada y seguir limitada porque no está asociada al vehículo por el procedimiento autorizado. Otra puede estar vinculada y tener una variante incorrecta.

El diagnóstico debe distinguir:

1. Incompatibilidad física o de referencia.
2. Aplicación o dataset incorrectos.
3. Configuración de variante incompleta.
4. Protección o vinculación pendiente.
5. Aprendizajes y calibraciones aún no realizados.

Las unidades relacionadas con inmovilización, acceso, componentes protegidos o certificados pueden exigir credenciales y transacciones específicas. Antes de instalar un recambio, verificar si su condición —nuevo, reconstruido o usado— está admitida. No todos los componentes admiten reasignación.

Un error de autenticación puede proceder de permisos, validez temporal, conexión, estado del servidor o requisitos del vehículo. Conservar la referencia de operación y consultar la ruta de soporte. No publicar credenciales ni intentar resolver el rechazo mediante elusión de controles. La reparación requiere completar el proceso legítimo o seleccionar una solución de recambio admitida.

Volver al índice ↑

30. Procedimiento general de codificación

Guardar el estado inicial y definir la configuración objetivo. Verificar la lista física de equipamiento y los requisitos de software. Seleccionar la función guiada correspondiente a sustitución, restauración o reequipamiento; esas finalidades pueden utilizar datos distintos.

Durante la escritura, mantener las precondiciones de alimentación y estado. Después, aplicar únicamente los ciclos y rutinas indicados. Leer la configuración y revisar las unidades asociadas. Si el sistema central distribuye los datos, confirmar que todas las unidades previstas completaron la operación.

La validación debe combinar pruebas de:

• Presencia: se reconoce el equipo correcto.
• Ausencia: no se solicita hardware no instalado.
• Mando: los controles y solicitudes llegan a destino.
• Efecto: la función física e indicaciones son coherentes.
• Persistencia: la configuración permanece tras los ciclos previstos.
• Interacción: las funciones relacionadas responden correctamente.

Evitar usar el borrado de DTC como comprobación principal. Un código puede tardar en reaparecer hasta que se cumpla su condición de detección. La prueba debe ejercitar esa condición cuando sea razonablemente reproducible y segura.

Volver al índice ↑

31. Fallos típicos de codificación

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Un archivo guardado con anterioridad puede no ser restaurable después de una actualización que cambie el esquema. Comparar la estructura y el procedimiento de migración, no solo el nombre del archivo. El formato de una «codificación larga» no debe interpretarse por semejanza entre versiones.

Cuando la configuración recibida es desconocida, reconstruir la evidencia del vehículo y consultar la fuente prevista. Probar combinaciones hasta que desaparezcan los mensajes puede ocultar funciones ausentes y producir una configuración aparentemente limpia pero incorrecta.

Volver al índice ↑

32. Matriz de coherencia y cierre de codificación

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La matriz no implica que todos esos campos sean codificables en cualquier vehículo. Sirve para comprobar que los datos representen el sistema real y que no se haya omitido una dependencia.

El cierre debe conservar la fuente de configuración, el cambio efectuado y el resultado. Si una función requiere prueba dinámica o una condición ambiental no disponible, indicar que esa verificación sigue pendiente. No presentar una comprobación de menús como prueba del comportamiento en carretera.

Volver al índice ↑

33. Los distintos significados de calibración

En taller, calibrar suele establecer o comprobar una referencia funcional: posición cero, orientación de sensor, recorrido, clasificación o relación entre una medida y el sistema físico. En desarrollo, calibrar puede significar ajustar constantes y mapas de la estrategia de control. Además, algunos fabricantes denominan «calibración» al archivo de software distribuido en servicio.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

El manual utiliza «calibración de taller» cuando se refiere a referencias y rutinas de servicio. La calibración metrológica del instrumento y el ajuste de una función del vehículo no son la misma actividad.

ASAM XCP proporciona un marco de comunicación para medición y calibración en sistemas compatibles, especialmente en ingeniería. Su existencia no implica que una ECU de producción permita ese acceso ni que su uso sustituya la diagnosis de servicio. ASAM — MCD-1 XCP.

Volver al índice ↑

34. Precondiciones físicas y calidad de la referencia

Una calibración puede almacenar una referencia incorrecta si se ejecuta sobre un sistema mal montado, una geometría inadecuada o condiciones que el procedimiento no permite. Por ello, comprobar primero la integridad física y después la rutina.

Las precondiciones pueden incluir referencia de piezas, montaje, pares de apriete, altura, carga, presiones de neumáticos, alineación, nivelación del suelo, temperatura, posición de mandos, estado de batería y ausencia de fallos determinados. No todas aplican a todas las funciones.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La precisión del valor mostrado no equivale a exactitud. Introducir una altura con resolución milimétrica no elimina un error de varios milímetros en el punto de medida. Evitar acumular estimaciones cuando la rutina exige una referencia física controlada.

Volver al índice ↑

35. Calibración de ADAS

Los sistemas ADAS pueden requerir calibración estática, dinámica o una combinación, según sensor, reparación y vehículo. Las condiciones de equipamiento, geometría y entorno se consultan para el VIN y la operación. La sustitución de una cámara no es el único posible desencadenante: determinadas intervenciones en vidrio, soportes, carrocería, alineación o suspensión también pueden exigir comprobaciones o calibración. I-CAR — Búsqueda de requisitos OEM de calibración.

En una calibración estática, verificar patrón o reflector, colocación, referencias del vehículo y condiciones del espacio. No existe una distancia universal de objetivo. En una dinámica, cumplir las condiciones de marcha y entorno definidas; no improvisar maniobras para acelerar el aprendizaje.

Registrar motivo, sensor, software, equipo, útil, geometría, condiciones, fase y resultado. Si la rutina falla, anotar qué condición no se ha cumplido antes de repetirla. Un porcentaje detenido puede corresponder a falta de referencias válidas, no a un sensor averiado.

La calibración dinámica y la prueba de funcionamiento posterior tienen finalidades diferentes. Completar una no sustituye automáticamente la otra. I-CAR — Dynamic Calibrations Compared to a Test Drive.

No comprobar frenado automático o evitación de colisiones provocando situaciones de riesgo en vía pública. Utilizar exclusivamente las comprobaciones previstas y los medios adecuados. La ausencia de DTC no demuestra que el sensor esté correctamente orientado en todas las condiciones.

Volver al índice ↑

36. Dirección, estabilidad, frenos y suspensión

Las referencias de ángulo de dirección, guiñada, aceleración, presión o altura pueden influir en varias funciones. Antes de establecer un cero, verificar que el estado físico represente realmente la condición de referencia. Centrar el volante no corrige por sí mismo una alineación incorrecta.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Las rutinas de freno pueden actuar bombas o válvulas. No ejecutarlas con componentes desmontados o sin preparación hidráulica cuando el procedimiento no lo permita. Un ajuste electrónico no sustituye purgado, inspección de fugas ni verificación mecánica.

Tras una intervención en suspensión, comprobar qué otros sistemas utilizan la geometría: nivelación de faros, ADAS, control de estabilidad o dirección. No asumir que cada referencia se actualiza automáticamente al calibrar una sola unidad.

Volver al índice ↑

37. Motor, transmisión y actuadores

El aprendizaje de una mariposa, válvula, actuador o embrague establece características de funcionamiento dentro del sistema previsto. Los requisitos pueden depender de temperatura, tensión, posición, ausencia de DTC y estado mecánico. Una rutina que no termina puede estar revelando un defecto físico, no un problema del equipo.

En transmisión, diferenciar identificación/parametrización de componentes, adaptación de presiones, aprendizaje de acoplamiento y prueba de funcionamiento. Las condiciones y el orden son específicos. Reiniciar adaptaciones sin reparar desgaste o fallos hidráulicos puede empeorar la calidad de cambio.

En motor, ciertos procedimientos aprenden relaciones de señales o posiciones después de reparaciones concretas. No todos los sistemas requieren la misma operación ni usan el mismo nombre. Consultar qué se aprende y qué condiciones hacen válida la referencia.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una compensación cercana a un límite requiere interpretación con especificaciones y estado del conjunto; no debe etiquetarse universalmente como pieza averiada. Comparar condiciones, repetibilidad y pruebas físicas antes de concluir.

Volver al índice ↑

38. HVAC, confort, SRS y electrificación

En climatización, aprender recorridos de compuertas no repara engranajes rotos ni puertas bloqueadas. Comprobar movimiento real, posición y efecto térmico. La posición leída puede corresponder al motor, no al elemento final.

En confort, los aprendizajes de ventanillas, techo o portón pueden afectar a finales de carrera y protección antiatrapamiento. El ensayo posterior debe seguir el método del fabricante, sin utilizar partes del cuerpo como elemento de prueba. La libertad mecánica y la correcta instalación preceden al aprendizaje.

En SRS, la clasificación de ocupante u otras calibraciones exige condiciones específicas de asiento, objetos, montaje y entorno. No deducir que todas las unidades requieren el mismo procedimiento. Una rutina de software no sustituye las inspecciones y sustituciones exigidas después de una activación o daño.

En vehículos electrificados, distinguir inicialización de control, referencias de sensores y estados estimados de batería. Los procedimientos pueden exigir verificaciones eléctricas, térmicas y de aislamiento independientes. Reiniciar un estimador no recupera capacidad física perdida ni acredita la integridad del paquete.

La regla común es relacionar el resultado electrónico con una comprobación física apropiada. Cuanto más indirecta sea la variable calculada, más importante es conocer cómo se obtiene y qué fallos quedan fuera de su cobertura.

Volver al índice ↑

39. Diagnóstico de calibraciones fallidas

Antes de repetir, clasificar el fallo: no se inicia, no progresa, termina fuera de rango o finaliza pero no resuelve el síntoma. Cada escenario orienta a pruebas diferentes.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La repetibilidad ayuda a separar causas: si el resultado cambia al mover un conector, investigar el circuito; si depende de un área concreta del taller, revisar el entorno; si falla siempre con la misma pieza, verificar su compatibilidad antes de atribuirlo a software.

Una calibración no debe utilizarse para compensar una deformación o un montaje incorrecto fuera de los límites permitidos. El hecho de conseguir aceptación no convierte esa condición en una reparación válida. Conservar resultados fallidos relevantes y el cambio que permitió completar la operación.

Volver al índice ↑

40. Validación de calibración y evidencia

Separar cuatro evidencias: preparación física correcta, finalización de la rutina, estado diagnóstico posterior y verificación funcional. Ninguna reemplaza por completo a las demás.

El registro debe contener ECU/sensor, motivo, procedimiento, versiones, instrumento y útil, condiciones iniciales, mediciones introducidas, resultado, archivo del equipo y alcance de prueba posterior. Para calibración dinámica, describir las condiciones relevantes sin divulgar recorridos o datos personales innecesarios.

Ejemplo de conclusión válida: «Rutina de referencia completada conforme al procedimiento identificado; montaje y geometría comprobados; escaneo posterior sin los fallos asociados; prueba prescrita realizada en las condiciones registradas».

Ejemplo insuficiente: «Calibrado porque no hay testigos».

Si no se pueden cumplir condiciones ambientales o de circulación, no inventar un resultado. Mantener la operación pendiente, explicar la limitación y organizar su finalización. El estado del vehículo para uso o entrega se determina con el procedimiento y las funciones afectadas, no por la conveniencia de cerrar la orden.

El informe debe permitir que otro técnico entienda qué referencia se estableció y con qué evidencia. Guardar solo una imagen del mensaje final elimina información esencial sobre las condiciones que lo hicieron válido.

Volver al índice ↑

41. Cuándo actualizar y cómo justificarlo

Una actualización cambia el software o los datos a un estado aprobado para corregir un problema, cumplir una acción de servicio, mantener compatibilidad o incorporar una función prevista. Debe relacionarse con un objetivo identificable, no con la idea de que cualquier versión posterior reparará cualquier síntoma.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una versión disponible puede no estar destinada a ese vehículo o no incluir cambios relevantes para la avería. La numeración tampoco garantiza orden cronológico comparable entre ramas o mercados.

Antes de actualizar por un síntoma, guardar una prueba inicial que pueda repetirse. Si una campaña obliga a actuar con independencia del síntoma, documentar por separado la realización de la campaña y el diagnóstico de la queja del cliente. Son objetivos distintos y pueden requerir verificaciones diferentes.

Volver al índice ↑

42. Paquetes, integridad y autenticidad

Un paquete puede contener aplicaciones, datos, metadatos, dependencias e instrucciones para el instalador. El sistema puede verificar integridad, autenticidad y compatibilidad antes de permitir activación. No confundir estas comprobaciones:

• Integridad: el contenido no se ha alterado respecto a la referencia comprobada.
• Autenticidad: el contenido procede de una entidad cuya firma o autorización acepta el sistema.
• Compatibilidad: corresponde a ese hardware y estado de software.
• Aplicabilidad: debe instalarse en ese vehículo y operación.

Una suma de comprobación correcta no demuestra por sí sola origen autorizado ni adecuación al vehículo. Una firma aceptada tampoco sustituye las condiciones físicas de instalación o las operaciones posteriores.

Utilizar el canal de distribución previsto. No mezclar archivos de distintas fuentes, renombrarlos para simular compatibilidad ni modificar manifiestos. Cuando el fabricante gestiona automáticamente la selección, registrar identificadores y resultados en lugar de intentar reconstruir el paquete.

Una descarga parcial o una caché defectuosa pueden producir errores antes de que comience la escritura. Determinar la fase mediante logs evita diagnosticar una ECU dañada por un problema situado en el ordenador o servidor.

Volver al índice ↑

43. Dependencias y actualización coordinada

Las unidades intercambian señales y servicios cuyo significado puede depender de versiones compatibles. Una actualización de una ECU puede requerir otras unidades, un gateway, una base de datos o una configuración determinada. El estado objetivo puede ser un conjunto de versiones y no una única versión aislada.

Estado actual identificado
        ↓
Plan OEM de unidades y dependencias
        ↓
Orden de instalación gestionado
        ↓
Migración / configuración / activación
        ↓
Comprobación del conjunto final

En arquitecturas de dominio o zonales, una misma plataforma de cómputo puede alojar varias funciones. Que una aplicación se actualice no significa que todas lo hagan, ni que el número de versión visible describa cada componente interno.

Registrar los módulos incluidos y los excluidos por el plan, así como cualquier paso que no haya terminado. Si solo algunas unidades completan la operación, el vehículo puede quedar en un estado transitorio que exige recuperación coordinada.

No cambiar manualmente el orden indicado ni omitir una actualización dependiente porque la unidad «no presenta fallos». La dependencia puede ser de protocolo, datos o compatibilidad y no aparecer como DTC antes de efectuar el cambio.

Volver al índice ↑

44. Actualización local, remota y OTA

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

En OTA, descarga, preparación e instalación son estados diferentes. La presencia de un paquete descargado no significa que esté activo. La elegibilidad puede depender de hardware, configuración, región y despliegue aprobado. Las condiciones concretas deben consultarse en la información del vehículo. Tesla — Software Updates, ejemplo de gestión OTA.

Una actualización iniciada por el usuario puede dejar funciones temporalmente indisponibles. Coordinarla con las reparaciones del taller y no ejecutar simultáneamente otra operación de escritura salvo que el proceso lo contemple.

Si el vehículo llega después de una OTA con un síntoma, conservar versión, hora aproximada, mensajes y circunstancias. La proximidad temporal orienta la investigación, pero no demuestra causalidad. También pueden haber cambiado condiciones de uso, batería, configuración o componentes físicos.

Volver al índice ↑

45. Migración de datos y operaciones posteriores

Una actualización puede conservar, transformar o restablecer configuración y valores aprendidos. La estrategia depende del diseño y del salto de versión. No asumir que todo se mantiene ni que todo debe borrarse.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una preferencia perdida y una calibración invalidada tienen consecuencias distintas. El informe debe distinguirlas. No restaurar automáticamente todos los archivos antiguos si el fabricante ha cambiado su estructura.

Después de actualizar, seguir las rutinas solicitadas por la aplicación y comprobar las funciones afectadas. Si se requiere un periodo de aprendizaje, registrar qué parte debe completarse en taller y qué comportamiento previsto debe conocer el usuario. No atribuir indefinidamente un síntoma a «adaptación» sin un criterio y plazo de comprobación.

Volver al índice ↑

46. Reinstalación, rollback y recuperación

Reinstalar la misma versión, instalar una versión posterior y volver a una anterior son operaciones diferentes. Cada una puede tener restricciones de compatibilidad, seguridad, memoria y datos. La posibilidad de restauración no debe prometerse antes de comprobar el procedimiento.

Algunos sistemas disponen de bancos alternativos o mecanismos de retorno; otros no. Incluso si existe una imagen anterior, los datos migrados, las dependencias o las restricciones de versión pueden impedir reutilizarla. Un diseño con redundancia tampoco garantiza recuperación ante cualquier fallo físico.

Como ejemplo de alcance específico, el procedimiento Tesla de reinstalación desde pantalla para determinados Model 3 de 2017–2023 describe reinstalar el software existente en ECUs CAN y excluye utilizar esa operación para actualizar el ordenador del vehículo. No debe generalizarse a otros modelos o versiones. Tesla — Software Reinstall, procedimiento específico.

Ante regresión funcional, documentar el síntoma y consultar la solución oficial. Puede consistir en completar configuración, corregir un componente, instalar otra versión aprobada o aplicar una recuperación. «Volver a lo anterior» no es una solución universal ni siempre técnicamente posible.

Volver al índice ↑

47. Gestión de versiones y contexto normativo

Mantener una trazabilidad que permita relacionar vehículo, hardware, software anterior, software final, motivo y resultado. Cuando la herramienta muestre identificadores de calibración, verificación o conjunto de software, conservar su denominación exacta. No equiparar automáticamente números internos, versión comercial y referencias reguladas.

El Reglamento ONU n.º 156 aborda la homologación de vehículos respecto a actualizaciones y sistemas de gestión de actualizaciones. Sirve como contexto de trazabilidad y gestión por parte del fabricante; su aplicabilidad depende del marco y categoría correspondientes. La página enlazada contiene un texto publicado en 2021 y no debe asumirse como consolidación de todas las modificaciones posteriores. UNECE — UN Regulation No. 156.

Para el taller, el criterio práctico es utilizar el procedimiento y paquete aplicables, preservar evidencia y no alterar funciones reguladas mediante archivos no autorizados. Las obligaciones concretas deben verificarse en la documentación vigente del mercado correspondiente.

Una campaña, un boletín técnico y una mejora opcional no tienen necesariamente el mismo alcance. Registrar el tipo de acción y su referencia, evitando presentar como campaña obligatoria cualquier actualización disponible en un menú.

Volver al índice ↑

48. Validación de actualización y seguimiento

La validación comienza por confirmar el estado final de todas las unidades previstas, pero debe llegar al comportamiento que justificó la intervención. Repetir la prueba inicial en condiciones comparables y revisar funciones compartidas afectadas.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

En un fallo intermitente, una prueba breve sin reproducción ofrece evidencia limitada. Relacionar la corrección con el defecto documentado y establecer un seguimiento proporcionado. No afirmar que un problema desapareció definitivamente si no se cubrieron sus condiciones.

Si aparecen síntomas nuevos, conservarlos antes de borrar. Comparar configuración, aprendizajes, estado eléctrico y alcance del paquete. La investigación debe admitir tanto una regresión como una causa física independiente. La conclusión «la actualización lo causó» requiere más que una coincidencia temporal.

Volver al índice ↑

49. Árbol de decisión para elegir la intervención

¿Existe un síntoma, una sustitución o una acción de servicio definida?
 ├─ No → Identificar el objetivo antes de modificar el vehículo.
 └─ Sí
    ¿Hay un defecto eléctrico, mecánico o de red que impida trabajar?
     ├─ Sí → Resolverlo y reevaluar el estado.
     └─ No
        ¿Falta o es incompatible el programa de la ECU?
         ├─ Sí → Programación según procedimiento.
         └─ No → Continuar.
        ¿La variante o equipamiento declarado es incorrecto?
         ├─ Sí → Codificación y comprobación de dependencias.
         └─ No → Continuar.
        ¿Faltan datos específicos del componente o variante?
         ├─ Sí → Parametrización con fuente identificada.
         └─ No → Continuar.
        ¿Una referencia/aprendizaje es obligatorio o está invalidado?
         ├─ Sí → Preparación física y calibración/reaprendizaje.
         └─ No → Continuar.
        ¿Existe una versión aplicable que resuelva el objetivo?
         ├─ Sí → Plan de actualización y validación.
         └─ No → Continuar el diagnóstico; no escribir por ensayo.

Este árbol clasifica necesidades; no fija el orden real de una reparación. Una sustitución puede exigir programación, vinculación, codificación, parametrización y calibración en la secuencia del fabricante. El plan debe reunirlas antes de comenzar.

Si varias hipótesis explican el síntoma, elegir primero pruebas que las diferencien y alteren lo mínimo necesario. Leer identificaciones o medir una alimentación suele conservar más evidencia que reiniciar adaptaciones o borrar registros.

Volver al índice ↑

50. Matriz de operaciones por sistema

La tabla indica posibilidades, no requisitos universales. Cada casilla debe confirmarse para la variante y trabajo concretos.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Una misma denominación de ECU puede cubrir funciones distintas entre plataformas. Identificar la arquitectura real y qué unidad produce, transmite y utiliza cada dato. Esto evita calibrar al consumidor cuando el problema está en el origen de la señal.

Volver al índice ↑

51. Formatos y estándares: qué aportan y qué no

Los estándares facilitan intercambio y comunicación, pero no eliminan la especificidad del vehículo. La existencia de un formato público no convierte todos los archivos en intercambiables.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

ODX describe servicios, datos, comunicación y aspectos de programación o codificación; ayuda a que una herramienta interprete correctamente una ECU. La descripción debe corresponder a su variante. ASAM — MCD-2 D / ODX.

Los nombres de archivo no bastan para conocer qué se escribirá. Conservar los identificadores suministrados por el sistema de servicio y utilizar su validación. No abrir o convertir un paquete para adaptarlo a otra herramienta salvo que exista un proceso expresamente previsto y documentado.

Volver al índice ↑

52. Análisis de fallos por capas

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

La capa donde aparece el mensaje no siempre contiene la causa. Una aplicación puede informar «ECU no responde» porque se desconectó el USB; una ECU puede rechazar calibración porque la temperatura no es válida. El log debe relacionarse con el estado físico y temporal.

Crear una línea de tiempo con eventos del ordenador, herramienta y vehículo. Si sus relojes difieren, registrar el desfase antes de correlacionarlos. No atribuir a una actualización un DTC que ya estaba presente en el escaneo inicial.

Volver al índice ↑

53. Medición, cálculos e interpretación cuantitativa

Los cálculos apoyan decisiones, pero no sustituyen especificaciones ni capturan todos los transitorios.

Caída de tensión: si un tramo presenta una resistencia equivalente de 0,025 Ω y circulan 20 A, la caída idealizada es V = I × R = 0,5 V. El ejemplo muestra por qué una conexión puede parecer correcta sin carga y fallar durante demanda; no fija un límite aceptable.

Consumo de carga: una demanda media hipotética de 18 A durante 40 minutos representa 18 × 40/60 = 12 Ah. No permite deducir por sí sola autonomía de una batería ni dimensionar el soporte: faltan estado real, capacidad utilizable, temperaturas y picos.

Tiempo de transferencia: un archivo de 60 MB a 2 MB/s necesita idealmente 30 segundos de transferencia pura. El proceso real añade preparación, borrado, protocolos, verificaciones, reinicios y otras unidades. No usar ese cálculo como tiempo límite de programación.

Error geométrico: un error angular pequeño puede producir una desviación lateral creciente con la distancia. La relación ideal desviación = distancia × tan(ángulo) explica la sensibilidad de una referencia; no sustituye geometrías, tolerancias ni criterios de calibración del fabricante.

Registrar frecuencia de adquisición y resolución. Un multímetro que muestra un valor estable puede no capturar una caída breve. Elegir el instrumento y método según la pregunta técnica, sin introducir conexiones que perturben la operación.

Volver al índice ↑

54. Organización del trabajo y criterios de parada

Asignar un responsable de la intervención y una única coordinación de mandos. En operaciones remotas, el técnico local confirma las condiciones físicas y ejecuta las acciones que requieren presencia; el operador remoto informa antes de una fase que altere el estado del vehículo.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

«Parar» durante una escritura no significa cortar inmediatamente alimentación. Significa no improvisar nuevas acciones y aplicar la gestión prevista para esa fase. Las emergencias físicas se gestionan priorizando a las personas.

Reservar tiempo para validación y posibles pasos posteriores. Un presupuesto que solo contempla la transferencia de software infravalora identificación, preparación y puesta en servicio. El informe debe separar tiempo de ejecución automática, trabajo técnico y causa de incidencias sin presentar como reparación una espera de servidor.

Volver al índice ↑

55. Casos prácticos: programación, parametrización y codificación

Los diez casos siguientes son ejemplos sintéticos. La solución concreta siempre depende del procedimiento aplicable.

Caso 1. La programación falla repetidamente durante la escritura

Situación: la identificación funciona, pero la transferencia se interrumpe bajo consumo elevado. Hipótesis: caída de tensión en una conexión. Prueba: registrar alimentación en condiciones representativas y revisar el circuito. Resolución: reparar la conexión, estabilizar el puesto y aplicar recuperación prevista. Validación: completar programación y pruebas posteriores. La lectura de tensión sin carga no habría descartado la causa.

Caso 2. ECU de recambio sin comunicación normal

Situación: la referencia está admitida, pero la unidad no aparece como las demás. Hipótesis: requiere la ruta de instalación inicial. Prueba: confirmar alimentación, red y estado de suministro del recambio. Resolución: ejecutar la instalación documentada. Validación: identificación, configuración y funciones. No concluir «unidad muerta» antes de verificar su estado de servicio.

Caso 3. Funciones ausentes después de instalar un módulo de carrocería

Situación: cierre básico correcto, otras funciones desaparecidas. Hipótesis: configuración incompleta. Prueba: comparar equipamiento y datos iniciales con la configuración final. Resolución: codificación conforme al vehículo y pasos asociados. Validación: matriz de funciones afectadas. Arrancar o comunicar no era una prueba suficiente.

Caso 4. Inyector caracterizado en el cilindro incorrecto

Situación: el código fue aceptado, pero la irregularidad persiste. Hipótesis: asignación de posición equivocada. Prueba: contrastar código físico, numeración OEM y lectura almacenada. Resolución: corregir asignación y realizar operaciones prescritas. Validación: pruebas de funcionamiento y diagnóstico mecánico restante. El formato válido del código no demostraba identidad correcta.

Caso 5. Transmisión con dataset de variante incorrecta

Situación: mecatrónica sustituida, comunicación normal y comportamiento anómalo. Hipótesis: datos incompatibles con el conjunto. Prueba: contrastar referencias y dataset. Resolución: instalar datos aprobados y completar aprendizajes. Validación: condiciones térmicas y de marcha previstas. No modificar adaptaciones para compensar la variante errónea.

Caso 6. Configuración copiada de otro vehículo

Situación: aparecen DTC de equipamiento que no existe. Hipótesis: configuración donante inaplicable. Prueba: inspección de equipos y comparación con fuente del vehículo. Resolución: reconstruir el estado aprobado. Validación: comprobar tanto funciones presentes como equipos declarados ausentes. El parecido entre vehículos no acredita equivalencia.

Caso 7. Acceso denegado interpretado como ECU defectuosa

Situación: lectura normal y rechazo de una función protegida. Hipótesis: autorización insuficiente. Prueba: mensaje exacto, rol y requisitos del servicio. Resolución: completar acceso legítimo. Validación: operación autorizada y puesta en servicio. Sustituir la ECU no habría resuelto la cuenta o permiso.

Caso 8. Batería nueva registrada sin cambiar el tipo requerido

Situación: se ha instalado una batería admitida de características diferentes, pero solo se ejecutó registro. Hipótesis: falta la configuración que esa plataforma exige. Prueba: comparar batería física, requisitos y datos almacenados. Resolución: completar las operaciones aplicables. Validación: coherencia de gestión energética. Registro y configuración eran procesos diferentes.

Caso 9. Función activada sin hardware completo

Situación: un menú aparece después de codificar, pero la función no opera. Hipótesis: falta un componente o instalación. Prueba: lista de reequipamiento aprobada e inspección. Resolución: completar únicamente un reequipamiento admitido o restituir la configuración correcta. Validación: mando, efecto y supervisión. Un menú visible no prueba capacidad física.

Caso 10. Parámetro que vuelve al valor anterior

Situación: el valor aparece cambiado y se restaura tras un ciclo. Hipótesis: autoridad central o escritura sin persistencia. Prueba: seguir el flujo de configuración y leer desde las unidades pertinentes. Resolución: completar la transacción documentada. Validación: persistencia e interacción. No repetir el mismo cambio sin investigar quién gobierna el dato.

Volver al índice ↑

56. Casos prácticos: calibración y actualización

Caso 11. Cámara que no calibra después de sustituir el parabrisas

Hipótesis: soporte, vidrio, montaje o condiciones de referencia incorrectos. Prueba: inspección y requisitos geométricos antes de repetir. Resolución: corregir la condición comprobada y calibrar. Validación: informe y prueba prescrita. El bloqueo de progreso no demostraba avería de cámara.

Caso 12. Dirección con cero aprendido sobre mala alineación

Situación: rutina completada, pero el vehículo deriva. Prueba: neumáticos, alineación y relación volante-ruedas. Resolución: reparación geométrica y operaciones derivadas. Validación: comportamiento y señales coherentes. La aceptación electrónica no certificaba la geometría.

Caso 13. Actuador HVAC aprendido con una compuerta rota

Situación: posición del motor cambia, temperatura de salida no responde. Prueba: relación entre motor y compuerta. Resolución: reparar transmisión mecánica y repetir el aprendizaje indicado. Validación: posición y efecto térmico. La señal de posición no representaba el movimiento final.

Caso 14. Actualización correcta con síntoma original presente

Situación: versión final verificada, pero persiste un corte intermitente. Prueba: reproducirlo y correlacionar señal física. Resolución: reparar el cableado defectuoso demostrado. Validación: ensayo equivalente. La actualización realizada no había probado que el origen fuera software.

Caso 15. Fallo de descarga atribuido al módulo

Situación: la operación termina antes de transferir contenido. Prueba: log de fases y servicio remoto. Resolución: corregir conectividad o acceso y reiniciar la operación conforme a la aplicación. Validación: instalación y pruebas completas. No se había demostrado alteración de la ECU.

Caso 16. Actualización coordinada parcialmente completada

Situación: una unidad termina y otra falla. Prueba: inventario final y plan de dependencias. Resolución: recuperación del conjunto por la ruta prevista. Validación: versiones e intercambios entre unidades. No entregar por el éxito aislado de la primera ECU.

Caso 17. Cambio brusco después de borrar adaptaciones

Hipótesis: se eliminó compensación sin reparar un problema físico o sin completar aprendizaje. Prueba: motivo del reset, estado mecánico e instrucciones. Resolución: corregir la causa y ejecutar lo prescrito. Validación: comportamiento en condiciones pertinentes. No prometer que «se arreglará solo al conducir».

Caso 18. Síntoma posterior a OTA sin relación causal demostrada

Situación: avisos al día siguiente de actualizar. Prueba: versiones, registros y alimentación auxiliar. Resolución: tratar la causa comprobada; escalar si la evidencia apunta a regresión. Validación: función y condiciones originales. La secuencia temporal orienta, pero no decide el diagnóstico.

Caso 19. Clasificación de ocupante rechazada

Hipótesis: condiciones de asiento o montaje incorrectas. Prueba: requisitos OEM, componentes y estado físico. Resolución: corregir la condición, ejecutar calibración y comprobaciones SRS. Validación: resultados y estados prescritos. No simular presencia ni modificar valores para obtener aceptación.

Caso 20. Solicitud de volver a una versión anterior

Situación: una función se comporta de manera distinta tras actualizar. Prueba: configuración, notas de cambio y posibilidad oficial de restauración. Resolución: aplicar la solución admitida, que puede no ser downgrade. Validación: estado final coherente y explicación al usuario. La existencia de un archivo antiguo no acredita que sea restaurable.

Volver al índice ↑

57. Plantillas de recepción y planificación

57.1. Orden técnica inicial

Orden / fecha / técnico responsable:
Vehículo / VIN / mercado / fecha de fabricación:
Motorización / transmisión / arquitectura eléctrica:
Equipamiento relevante y modificaciones documentadas:
Kilometraje / estado energético inicial:
Síntoma descrito / frecuencia / condiciones:
Intervenciones recientes y versiones conocidas:
Objetivo de la operación:
Clase principal y subclases necesarias:
Unidades implicadas y dependencias:
Documentación aplicable / revisión / boletín o campaña:
Escaneo inicial y archivos de evidencia:
Estado físico, eléctrico y de red:
Limitaciones conocidas:

57.2. Plan de intervención

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

57.3. Recursos y recuperación

Aplicación de servicio / versión:
Interfaz / serie / firmware / controlador:
Ordenador / sistema compatible:
Acceso y autorización verificados, sin registrar secretos:
Equipo de soporte eléctrico y configuración prescrita:
Estado de batería y conexiones:
Herramientas físicas y útiles posteriores:
Red y conectividad requeridas:
Datos que se conservan / migran / reinician:
Ruta de recuperación documentada:
Soporte técnico / referencia de contacto:
Criterios para iniciar / aplazar / escalar:
Disponibilidad prevista del vehículo:

Completar los campos con evidencia, no con «OK» indiscriminado. Si un dato no es accesible, indicar «no disponible» y explicar cómo se verificó el requisito asociado.

Volver al índice ↑

58. Plantillas de ejecución por subclase

58.1. Programación y actualización

VIN / ECU / referencia y revisión de hardware:
Software anterior / identificadores de calibración:
Software objetivo / paquete / origen:
Motivo y procedimiento:
Dependencias y orden previsto:
Hora de inicio / fin / identificador de sesión:
Precondiciones verificadas:
Eventos de alimentación o comunicación:
Fase y texto exacto de cualquier error:
Resultado de transferencia / verificación / activación:
Identificación leída después:
Operaciones posteriores realizadas:
Archivos de log y escaneos:
Resultado de validación y pendientes:

58.2. Parametrización

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

58.3. Codificación

Configuración de origen disponible:
Configuración recibida en taller:
Equipamiento físico comprobado:
Configuración objetivo y justificación:
Fuente y método de cálculo/descarga:
Unidades que reciben o dependen del cambio:
Vinculación o protección pendiente/aplicada:
Comparación posterior:
Funciones presentes, ausentes y compartidas comprobadas:
Persistencia y escaneo final:

58.4. Calibración

Sistema / sensor / actuador / referencia:
Motivo de calibración:
Procedimiento y revisión:
Software / configuración correctos:
Montaje, geometría y estado físico:
Equipo / útil / patrón / identificación:
Estado metrológico cuando corresponda:
Puntos de medida / unidades / valores:
Temperatura, carga y condiciones del entorno:
Modalidad estática / dinámica / aprendizaje:
Condiciones de marcha, si procede:
Resultado y fase de fallo, si existe:
Comprobación funcional independiente:
Archivo de informe y limitaciones:

Volver al índice ↑

59. Gestión de incidencias y expediente de soporte

Un expediente útil permite reproducir el contexto sin repetir operaciones arriesgadas ni pedir de nuevo todos los datos. Debe describir qué ocurrió y qué se sabe, separando hechos de hipótesis.

Identificación del vehículo y ECU:
Trabajo solicitado y procedimiento aplicado:
Estado inicial y resultado del escaneo:
Hardware/software/dataset antes de intervenir:
Herramienta, interfaz y versiones:
Identificador de transacción o sesión:
Hora y fase exacta del fallo:
Mensaje íntegro, código y captura:
Estado de alimentación y red observado:
¿Comenzó la escritura? Evidencia:
¿La ECU responde? Por qué función/ruta:
Acciones realizadas después, en orden:
Resultados de cada acción:
Estado actual y condiciones mantenidas:
Archivos adjuntos y datos sensibles excluidos:
Pregunta técnica concreta al soporte:
Respuesta recibida y siguiente paso autorizado por el procedimiento:

No borrar registros para «empezar limpio» antes de que se hayan guardado. No presentar como hecho que la ECU está dañada si solo se dispone de un timeout. Utilizar descripciones observables: «sin respuesta en identificación normal después del reinicio solicitado» es más preciso que «centralita bloqueada».

Si el soporte prescribe una recuperación, registrar su referencia, precondiciones y resultado. Si propone una operación fuera de la cobertura disponible, verificar recursos y aplicabilidad antes de ejecutarla. La urgencia no sustituye una identificación correcta.

Volver al índice ↑

60. Checklists de entrada y salida

60.1. Antes de escribir o ejecutar una rutina

• Objetivo y síntoma definidos con evidencia.
• VIN, variante, hardware y software identificados.
• Procedimiento vigente y aplicable disponible.
• Escaneo, identificaciones y configuración inicial guardados.
• Compatibilidad de recambio, paquete o dataset confirmada.
• Estado físico adecuado para la operación.
• Alimentación y conexiones comprobadas.
• Herramienta, interfaz y entorno informático admitidos.
• Accesos necesarios verificados.
• Estado de contacto, consumidores, llaves y carga definido.
• Dependencias y operaciones posteriores planificadas.
• Útiles y condiciones de calibración disponibles.
• Gestión de incidencias y recuperación localizada.
• Área y personas preparadas para posibles movimientos.

60.2. Antes de cerrar la reparación

• Resultado de cada fase documentado.
• Identificaciones finales verificadas desde el vehículo.
• Configuración y datasets coherentes con el equipo instalado.
• Vinculaciones y funciones protegidas completadas cuando proceda.
• Adaptaciones y calibraciones obligatorias completadas.
• Modos de servicio y herramientas temporales retirados/cerrados.
• Escaneo final guardado e interpretado.
• Fallos inducidos distinguidos de fallos previos o persistentes.
• Prueba inicial repetida en condiciones comparables.
• Funciones compartidas afectadas comprobadas.
• Preferencias o cambios relevantes comunicados.
• Limitaciones y pendientes registrados con precisión.
• Informe final y evidencia archivados de forma protegida.

Las listas ayudan a evitar omisiones; no sustituyen el procedimiento específico. Marcar un elemento como «no aplicable» requiere una razón, especialmente en operaciones de seguridad o puesta en servicio.

Volver al índice ↑

61. Informe final y niveles de evidencia

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Modelo breve de informe

Motivo de entrada:
Hallazgos iniciales relevantes:
Causa o requisito de servicio demostrado:
Intervenciones realizadas, por subclase:
Versiones, datos o referencias antes/después:
Procedimientos y documentación utilizados:
Operaciones posteriores:
Pruebas realizadas y resultados:
Fallos no relacionados o pendientes:
Condiciones no reproducidas:
Cambios de uso/preferencias que debe conocer el cliente:
Seguimiento previsto, si corresponde:
Técnico / fecha / archivos de respaldo:

Evitar frases absolutas como «todas las ECUs perfectas» después de un escaneo. Expresar el alcance: qué unidades se leyeron, qué funciones se probaron y qué condiciones faltaron. Si una intervención resolvió un requisito de campaña pero no una queja distinta, indicarlo claramente.

Los indicadores internos de calidad pueden incluir operaciones con preescaneo conservado, recuperaciones necesarias, pasos posteriores omitidos y retornos por el mismo síntoma. No premiar únicamente la rapidez de transferencia: incentiva saltarse preparación y validación.

Volver al índice ↑

62. Glosario técnico español–inglés U.S.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Traducir por función, no por coincidencia literal. «Calibration file» puede ser un archivo de software; «coding» no suele significar escribir código fuente en el contexto de taller; «programming successful» no equivale a vehículo completamente validado.

Volver al índice ↑

63. Referencias técnicas y límites de uso

Fuentes consultadas para conceptos y ejemplos específicos de esta edición. Se priorizan fabricantes, proveedores técnicos, organismos de normalización y formación especializada. Las páginas generales no son fuentes de límites de servicio universales. Fecha de consulta: 24 de septiembre de 2026.

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Para una intervención real, obtener además: manual de reparación por VIN, diagramas, requisitos de sustitución, catálogo de referencias, boletines/campañas, condiciones de detección de DTC, requisitos de la herramienta y criterios de verificación. La documentación debe conservar su identificación y revisión.

Si una fuente general y el procedimiento específico parecen discrepar, comprobar primero su ámbito, fecha, variante y finalidad. No combinar fragmentos de procedimientos diferentes para crear una secuencia nueva sin respaldo técnico.

Volver al índice ↑

64. Integración en el proyecto AutoMotive y mantenimiento editorial

La clase principal agrupa operaciones que modifican estados lógicos. Las cinco subclases deben relacionarse con los sistemas del vehículo mediante referencias cruzadas, evitando duplicar procedimientos completos en cada categoría. Por ejemplo, una cámara pertenece al sistema ADAS y puede requerir programación, codificación y calibración; esas relaciones son complementarias.

64.1. Ficha recomendada de conocimiento

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

No almacenar contraseñas o secretos de acceso en fichas documentales. Mantener los datos de clientes separados del contenido técnico reutilizable. Los ejemplos didácticos deben identificarse como tales y no convertirse en límites de servicio.

64.2. Criterios de revisión

Actualizar el documento cuando cambien conceptos relevantes, arquitecturas, formatos o fuentes. Los requisitos particulares deben añadirse con ámbito y procedencia, evitando generalizar una experiencia de taller. Revisar enlaces, terminología, coherencia entre subclases y referencias cruzadas.

Los anclajes de capítulos se mantienen estables para facilitar una futura conversión a HTML/PHP e integración con la documentación del proyecto. El Markdown no depende de estilos ni scripts externos para comprender el contenido.

64.3. Historial

En pantallas pequeñas, desplaza la tabla horizontalmente para ver todas las columnas.

Volver al índice ↑