El protocolo KWP2000 se ha convertido en un estándar de facto en aplicaciones diagnósticos automotrices. Está estandarizado como ISO 14230-3. KWP2000 describe la implementación de diversos servicios de diagnóstico se puede accethrough el Protocolo. Puede ejecutar KWP2000 en varias capas de transporte como K-line (serie) o Can.
Protocolo de transporte
Como KWP2000 utiliza mensajes de longitud variable byte, un protocolo de transporte es necesario en capas con sólo una longitud de mensaje (corto) bien definido, como CAN. El Protocolo de transporte divide un largo mensaje KWP2000 en piezas que pueden ser transferidos por la red y permite volver a montar las piezas para recuperar el mensaje original.
KWP2000 se ejecuta en CAN en diversos protocolos de transporte como TP ISO (ISO 15765-2), TP 1.6, TP 2. 0 (Volkswagen) y SAE J1939-21. Para KWP2000, el juego de comandos diagnóstico automotriz sólo admite la ISO TP (estandarizado en ISO 15765-2) y protocolos de transporte de VW TP 2.0 específicos del fabricante.
Servicios de diagnóstico
Los servicios diagnósticos disponibles en KWP2000 están agrupados en unidades funcionales e identificados mediante un código de un byte (ServiceId). La norma no define todos los códigos; para algunos códigos, la norma se refiere a otras normas SAE o ISO, y algunos están reservados para extensiones específicas de fabricante. El juego de comandos diagnóstico automotriz es compatible con los siguientes servicios:
• Gestión de diagnóstico
• Transmisión de datos
• Almacenar la transmisión de datos (Diagnostic Trouble Codes)
• Control de entrada y salida
• Activación remota de rutina
Servicios de carga y descarga y extendido no forman parte del juego de comandos diagnóstico automotriz.
Formato de servicio diagnóstico
Servicios de diagnóstico tienen un formato de mensaje común. Cada servicio define un mensaje de solicitud, mensaje de respuesta positiva y un mensaje de respuesta negativa. El mensaje de solicitud tiene la ServiceId como primer byte, además de otros parámetros definidos por el servicio. El mensaje de respuesta positiva tiene un eco de la ServiceId con bit 6 establecido como primer byte, además de los parámetros definidos por el servicio de respuesta.
El mensaje de respuesta negativa suele ser un mensaje de tres bytes: tiene la ServiceId respuesta negativa como primer byte, un eco de la original ServiceId como segundo byte y un ResponseCode como tercer byte. La única excepción a este formato es la respuesta negativa a un servicio de EscapeCode; aquí, el tercer byte es un eco del código de servicio definidos por el usuario, y el cuarto byte es el ResponseCode. El estándar de KWP2000 define en parte la ResponseCodes, pero hay espacio para extensiones específicas de fabricante. Para algunos de los ResponseCodes, KWP2000 define un procedimiento de control de errores. Porque las respuestas positivas y negativas tienen un eco del servicio solicitado, siempre puede asignar las respuestas a su solicitud correspondiente.
Conectar/desconectar
KWP2000 espera una sesión de diagnóstico arrancar con StartDiagnosticSession y con StopDiagnosticSession. Sin embargo, StartDiagnosticSession tiene un parámetro DiagnosticMode que determina el tipo de sesión de diagnóstico. Dependiendo de este tipo, el ECU puede puede apoyar otros servicios de diagnóstico o funcionar en un modo restringido donde no todas las funciones de la ECU están disponibles. Los valores del parámetro DiagnosticMode están fabricante específico y no definido en la norma. Para que una sesión de diagnóstico permanezca activo, debe ejecutar el servicio TesterPresent periódicamente si no se ejecuta ningún otro servicio. Si el servicio TesterPresent falta durante un determinado período de tiempo, se termina la sesión de diagnóstico, y la ECU vuelve al modo de funcionamiento normal.
GetSeed/desbloquear
Un mecanismo de GetSeed/desbloqueo puede proteger algunos servicios de diagnóstico. Sin embargo, los servicios correspondientes se dejó al fabricante y no definidos por la norma.Puede ejecutar el mecanismo de GetSeed/desbloqueo a través del servicio SecurityAccess. Esto define varios niveles de seguridad, pero el fabricante asigna estos niveles a determinados servicios.
Memoria de lectura/escritura
Utilizar los servicios de lectura/WriteMemoryByAddress para carga y descarga de datos a ciertas direcciones de memoria en un ECU. La dirección es una cantidad de tres bytes en KWP2000 y una cantidad de cinco bytes (4 bytes de la dirección y extensión de un byte) en los protocolos de calibración. Los servicios de carga y descarga de unidad funcional son altamente fabricante específico y no está bien definido en la norma, por lo que no son una buena forma de proporcionar un mecanismo de carga y descarga de general.
Mediciones
Utilizar los servicios de ReadDataByLocal/CommonIdentifier para acceder a los datos de la ECU de manera similar a una lista DAQ. Un Local/CommonIdentifier describe una lista de cantidades de ECU que se transfieren de la ECU al probador. La transferencia puede ser único valor o tasa de transferencia periódica, con un medio lento, o rápido. Las tasas de transferencia son fabricante específico; puede utilizar el servicio de SetDataRates para definirlas, pero esta configuración es específica del fabricante. El juego de comandos diagnóstico automotriz soporta medidas de un solo punto.
Diagnostic Trouble Codes
Una característica importante de diagnóstica es la lectura de códigos de averías de diagnóstico (DTC). Define KWP2000