- 0xduraki

KW71 Protocol Description

KW71 is part of the broader Keyword Protocol notes.

Background

Protocol exchange, called KeyWord Protocol KW-71, describes the interaction of diagnostic tools (DS) with electronic blocks BMW cars produced before 1995. The DS is used via propriatery BMW ADS cable connector, which stands for “Aktiven Diagnose Stecker” (see BMW Acronyms). These include model E30, E32, E34, E36.

KW-71 protocol is used on early Bosch Engine ECUs (BMW, Opel, Peugeot/Citroen, Volkswagen).

The protocol works by implementing two-line bus serial communication, using a shared 1-wire TxD/RxD busline.

The physical implementation of the Protocol (Keyword-9141) is based on the interaction of two lines, called K and L. In doing so, K-Line is a bidirectional data, and it can be transferred as of DS (Diagnostic Tool) in the car, and from the car to the DS (Diagnostic Tool). Line L is an unidirectional data line, for which data is transmitted only from diagnostic system in the car.

The data on the K and L lines are compatible with the common protocol description of RS232C. Levels of these signals indicates logical operations, meaning that: logical “0” corresponds to the line-circuiting “land”, and a logical “1” corresponds in line to the 12.

Getting Started

The protocol implements a listen-only mode by default, until awakened; which can be done sending a “WAKE UP” request on L-line (RxD).

In vehicle daignostics, the ECUs and other vehicle electronic blocks (EBU, ECM, ABS, Airbag) are all connected in parallel. All of them are inactive until the DS (Diagnostic Service) is instructed to activate the diagnostic features for a specified electronic block. This procedure sent to desired unit is called “WAKE UP” procedure.

Each vehicle has dignostic block which contains unique code (address), for example, EBU contains address 0x10 for engine. If the DS (Diagnostic Service) is going to connect with the EBU, the “WAKE UP” must be sent to the EBUs L-Line via this address, in a sequential code. Doing so allows DS to ensure low-speed diagnostic communication and exchange.

Protocol Description

Below are details of the KW-71 Protocol when addressing one of the DME’s in the BMW E31 850i (EML and EGS uses diff messages).

These ECUs support KW71 protocol:

  • BMW DME 1.x
  • BMW DME 3.x
  • BMW DDE 1.x

Vehicle Bus Signal Data

Busline Operation

All modules sit on a shared TxD/RxD bus (2 wires) and are in listen-only mode until awakened. The awakening or addressing process for the DME’s takes place at the blistering speed of 5bps (8N1) on the RxD line (L-Line).

A single byte ‘0x10’ will awaken DME #1 and ‘0x14’ will awaken DME #2 (850i has 2x (two) DME’s). Since further communications takes place on the single wire TxD line (at 9600bd 8N1), you can only talk to one module at a time and each take turns to talk (see protocol diagram below).

Establish Communication

After sending a wake up command (INPA will try 3 x times before giving up) the DME responds by sending 0x55, 0x00, 0x81 on the TxD line to which diagnostics responds with 0x7E (acknowledge).

At this point the communications channel has been established and both parties can now exchange information on the TXD line (RXD is no longer used). The timing of these messages is critical which later led me to implement this interface using an Arduino (Raspberry cannot reliably maintain the required timing accuracy).

Message Bytes
  • The first byte of every message indicates it’s length. It is the number of additional bytes that follow in the message or you could say it’s total message length minus the first byte.
  • The second byte is a message counter that increments by one for every message sent. It starts at 0x00 and wraps around at 0xFF.
  • The third byte signifies the type of message; for example 0xF6 indicates asci text and 0x09 is a NOP (no operation) or ‘keep alive’ message. The latter does nothing but keep the communication channel alive (without it the DME will go back to sleep mode).
  • The last byte of every message is always 0x03.

The DME and Diagnostics computer (INPA) take turns to transmit 1x message at a time and this process is maintained to keep the exchange alive. If neither have anything useful to transmit they send a NOP message.

No CRC or checksum is sent, instead, every byte sent (except the end of message identifier) is inverted and echoed back to the sender. This is one aspect of this protocol that makes it very inefficient and slow!

Thats it for now. See References below for more details.

References

Projects Implementation

Show More If PDF or link renders dead, please take a look at Infra/NAS => Personal => others => BMW_PDF => [...] in homelab NAS for a backup or alternative.