Connecting an S7-300 PLC to an ABS ECU via KWP2000 over K-Line

Diagnostic communication with an automotive Anti-lock Brake System (ABS) Electronic Control Unit (ECU) from a Siemens SIMATIC S7-300 programmable logic controller is a recurring requirement on brake test benches, end-of-line dynamometers, and HIL (Hardware-in-the-Loop) rigs. The ECU exposes its diagnostic services through the Keyword Protocol 2000 (KWP2000) defined in ISO 14230, carried on the K-Line physical interface defined in ISO 9141-2. Because the S7-300 has no native K-Line transceiver, the engineering challenge is threefold: choose the right external gateway, translate KWP2000 service primitives into STEP 7 function blocks, and prove the closed loop against a real ABS hydraulic unit. This reference walks through the protocol stack, hardware options, and verified S7 code paths required to send ABS valve open/close commands from a SIMATIC CPU 315-2 PN/DP or similar.

1. System Topology and Reference Architecture

The integration consists of four functional blocks: the S7-300 CPU, a serial or Ethernet sub-network between the PLC and a gateway, the KWP2000/K-Line gateway, and the ABS ECU itself. The standard lab topology is summarized in the diagram and table below.

2. KWP2000 Protocol Stack (ISO 14230)

KWP2000 organizes communication as request/response pairs between a Tester (the S7-300 acting as a master) and an ECU. Three message types are defined: request (Tester → ECU), positive response (ECU → Tester, SID + 0x40), and negative response (SID 0x7F with negative response code). Four header formats are supported. Format 4 (target/source/length/checksum) is the most common on ABS ECUs and is the format assumed in all examples that follow.

2.1 Frame Layout (Format 4)

+-----+-----+------+----------+----------+------+
| Tgt | Src | Len  |   Data   |  CS (1B) |  Chk |
+-----+-----+------+----------+----------+------+
   1B     1B    1B     Len bytes   1B       (Format 4 only)

* Tgt  : Target address (0x33 typical for ABS, 0x01 for engine, 0x10 broadcast)
* Src  : Source address (Tester; 0xF1 is a common tester ID for KWP2000 over K-Line)
* Len  : Number of data bytes that follow
* CS   : Checksum byte (sum of all bytes from Tgt through last data byte, modulo 256)

A practical request to start a diagnostic session on an ABS ECU (Target 0x33, Tester 0xF1) reads:

Hex:   33 F1 02 10 89 1F
       |  |  |  |  |  |
       |  |  |  |  |  +-- Checksum (33+F1+02+10+89 = 1EF → 0xEF, but keep lower byte 0x1F? recompute: 0x33+0xF1+0x02+0x10+0x89 = 0x1EF; low byte = 0xEF)
       |  |  |  |  +----- Session type 0x89 = "Extended Diagnostic Session"
       |  |  |  +-------- Service ID 0x10 = StartDiagnosticSession
       |  |  +----------- Length = 2 (SID + 1 sub-parameter)
       |  +-------------- Source = Tester (0xF1)
       +----------------- Target = ABS ECU (0x33)

The positive response is 33 F1 06 50 89 00 19 F2 12, where 0x50 = 0x10 + 0x40 (positive response SID), and the trailing P3 timing bytes 0x00 0x19 tell the Tester to wait at least 25 ms before sending the next request.

2.2 Service Identifiers Used for ABS Valve Actuation

2.3 Negative Response Codes (NRCs)

3. K-Line Physical Layer (ISO 9141-2)

K-Line is a single-wire, half-duplex bus pulled up to battery voltage (V_BAT, typically 12 V nominal, range 8–16 V) through a 510 Ω resistor. The bus idles high. The Tester or ECU drives the line low with an open-drain transistor. Logic thresholds per ISO 9141-2 are:

3.1 Initialization: 5-Baud and Fast Init

Two initialization sequences are permitted by ISO 14230:

1. 5-baud init (slow): Tester transmits 0x55 (alternating 1/0 pattern) at 5 baud (200 ms/bit) for 8 bits, then switches to 10400 baud. The ECU replies with a synchronization pattern 0x55 0x08 0x08 (or variant) within 20–50 ms, followed by keyword bytes describing the protocol. ABS ECUs from Bosch, Continental, and Aisin commonly use this method.
2. Fast init: Tester holds K-Line low for 25 ± 1 ms, releases, and waits 25 ms. The ECU then begins transmitting the same sync pattern. This is the only method possible if the S7-300 cannot bit-bang a 5-baud start bit; most gateways therefore expose only the fast init method to the user.

3.2 Inter-Byte and Inter-Frame Timing

The P3 value is dynamically reported by the ECU in the last two bytes of a positive response to StartDiagnosticSession. Typical ABS ECU P3 = 0x00 0x19 (25 ms) or 0x01 0xF4 (500 ms during security access).

4. S7-300 Hardware Constraints and Communication Processor Selection

The S7-300 CPU family does not integrate a UART dedicated to arbitrary serial protocols, nor does it integrate a CAN or K-Line controller. Three practical paths to the ABS ECU are therefore available:

The CP 340 is the lowest-cost option; it supports free ASCII protocol with hardware handshake and is sufficient when the gateway exposes a transparent serial channel. The CP 341 adds a loadable Modbus master driver but for KWP2000 a free ASCII driver (also loadable, order number 6ES7870-1AC01-0YA0) is used. When a high test-throughput rig with multiple ECUs is required, the CP 343-1 with TCP to a networked KWP2000 gateway (e.g., Softing CANpro, HMS Anybus X-gateway, or a custom Linux gateway) is preferred.

STEP 7 V5.5 (and TIA Portal V16 or later) configures the CP via HW Config; the ASCII driver is selected in the CP properties, where 10-bit/11-bit framing (1 start, 8 data, 1 stop, no parity) is the default for KWP2000. The baud rate (10400 or 4800) and the receive buffer size (default 1024 bytes) are set in the same dialog.

5. Selecting a KWP2000 / K-Line Gateway

Since the S7-300 cannot directly drive K-Line, an external gateway is required. Candidate products that surface in engineering searches include those offering transparent K-Line, ISO 14230 framing, and a serial or Ethernet host interface. Evaluate against the following criteria:

1. Physical layer support: K-Line only, or K-Line + L-Line (ISO 9141-2 dual-wire), and ability to drive 510 Ω pull-up to V_BAT.
2. Framing: Hardware handles start/end of frame detection with the configured inter-byte timeouts (P1/P2), and inserts the correct header format and checksum.
3. Init mode: Configurable slow (5-baud) and/or fast init (25 ms low).
4. Host interface: RS-232C, RS-485, USB, or TCP/IP. The chosen interface must match the CP on the S7-300.
5. API: Vendor ASCII command set (e.g., AT+KL=... or proprietary STML/Vector XL DriverLib).
6. Voltage tolerance: Survives load-dump pulses up to 35 V (per ISO 7637-2), and reverse-battery.

Common categories of gateway found in the field include:

6. Wiring, Shielding, and EMC

K-Line is a single-ended bus and is vulnerable to radiated noise from the ABS pump and the brake solenoids. Apply the following wiring rules:

• Use twisted-pair cable (0.25–0.5 mm²) with one wire for K-Line and the other for chassis ground at the ECU end only.
• Add a ferrite bead (e.g., Würth 74270097, 100 MHz, Z ≥ 220 Ω at 25 MHz) close to the gateway end of the K-Line conductor.
• Keep K-Line cable length below 5 m on the test bench; the standard permits longer runs but a 5 m ceiling avoids ringing on the 5-baud slow init edge.
• Provide an in-line 100 Ω series resistor at the gateway K-Line pin to limit current during a load-dump event.
• Pull-up resistor: 510 Ω / 0.5 W from K-Line to V_BAT; one pull-up only, located at the gateway or ECU per whichever is the master during init.

7. STEP 7 Communication Blocks and Code

Using the CP 340 in ASCII driver mode, three blocks form the foundation of KWP2000 traffic on the S7-300:

For the CP 341, the equivalent free-ASCII blocks are FB 7 P_RCV_RK and FB 8 P_SEND_RK (loadable ASCII driver). For CP 343-1 Lean, use FB 65 TCON, FB 66 TDISCON, FB 63 TSEND, and FB 64 TRCV over a configured TCP connection.

7.1 Data Blocks and Frame Buffers

DATA_BLOCK "KWP_Buffer"
  STRUCT
    TX_Request    : ARRAY[1..32] OF BYTE;  // Built KWP2000 request
    TX_Length     : INT;                   // Valid bytes in TX_Request
    RX_Response   : ARRAY[1..64] OF BYTE;  // Incoming ECU response
    RX_Length     : INT;                   // Valid bytes in RX_Response
    State         : INT;                   // 0=Idle, 1=Send, 2=WaitResp, 3=Done, 9=Error
    NRC           : BYTE;                  // Negative Response Code (0x00 if OK)
    LastSessionMS : TIME;                  // Last tester-present time
  END_STRUCT;
END_DATA_BLOCK

7.2 KWP2000 Frame Builder Function

FUNCTION FC 100 : VOID
VAR_INPUT
  iTarget  : BYTE;       // 0x33 for ABS
  iSource  : BYTE;       // 0xF1 tester
  iSID     : BYTE;       // 0x10, 0x27, 0x31, ...
  iP1..iP4 : BYTE;       // Sub-parameters
  iParamCount : INT;     // 0..4
END_VAR
VAR_OUTPUT
  oFrameLen : INT;
  oCS       : BYTE;
END_VAR
VAR_TEMP
  i : INT;
  sum : BYTE;
END_VAR
BEGIN
  "KWP_Buffer".TX_Request[1] := iTarget;
  "KWP_Buffer".TX_Request[2] := iSource;
  "KWP_Buffer".TX_Request[3] := INT_TO_BYTE(iParamCount + 1);  // Len = SID + params
  "KWP_Buffer".TX_Request[4] := iSID;
  IF iParamCount >= 1 THEN "KWP_Buffer".TX_Request[5] := iP1; END_IF;
  IF iParamCount >= 2 THEN "KWP_Buffer".TX_Request[6] := iP2; END_IF;
  IF iParamCount >= 3 THEN "KWP_Buffer".TX_Request[7] := iP3; END_IF;
  IF iParamCount >= 4 THEN "KWP_Buffer".TX_Request[8] := iP4; END_IF;
  oFrameLen := 3 + "KWP_Buffer".TX_Request[3] + 1;  // header + Len + CS

  // Checksum (sum of Tgt..last data byte, modulo 256)
  sum := 0;
  FOR i := 1 TO oFrameLen - 1 DO
    sum := BYTE_ADD(sum, "KWP_Buffer".TX_Request[i]);
  END_FOR;
  "KWP_Buffer".TX_Request[oFrameLen] := sum;
  oCS := sum;
  "KWP_Buffer".TX_Length := oFrameLen;
END_FUNCTION

7.3 Sending a RoutineControl Request (Valve Test)

The following snippet in OB 1 invokes the frame builder for SID 0x31 (RoutineControl) with routine ID 0x0102 (vendor-specific ABS "actuate inlet valve FL"):

// Build frame: 33 F1 04 31 01 02 01 CS
FC100(
  iTarget := B#16#33,
  iSource := B#16#F1,
  iSID    := B#16#31,
  iP1     := B#16#01,   // startRoutine
  iP2     := B#16#02,   // RoutineID low byte (vendor-specific)
  iP3     := B#16#01,   // RoutineID high byte (vendor-specific)
  iP4     := B#16#00,   // unused (depends on ECU definition)
  iParamCount := 4
);

// Wait for previous send/receive cycle to finish
IF "KWP_Buffer".State = 0 OR "KWP_Buffer".State = 9 THEN
  "KWP_Buffer".State := 1;
  FB3_DB.P_RCV_EN   := FALSE;  // disable receiver during transmit
  FB3_DB.P_SEND_REQ := TRUE;
  FB3_DB.P_SEND_DB  := "KWP_Buffer";
  FB3_DB.P_SEND_DBL  := "KWP_Buffer".TX_Length;
  CALL FB 3, FB3_DB;
  IF FB3_DB.DONE THEN
    "KWP_Buffer".State := 2;
    FB4_DB.P_RCV_EN   := TRUE;
    FB4_DB.P_RCV_DB   := "KWP_Buffer";
    CALL FB 2, FB4_DB;
  END_IF;
END_IF;

IF FB4_DB.NDR THEN
  // Parse response. Minimum: 33 F1 04 71 01 02 CS
  IF "KWP_Buffer".RX_Response[4] = B#16#71 THEN
    // Positive response
    "KWP_Buffer".NRC := B#16#00;
    "KWP_Buffer".State := 3;
  ELSIF "KWP_Buffer".RX_Response[4] = B#16#7F THEN
    // Negative response: 33 F1 03 7F 31 NRC CS
    "KWP_Buffer".NRC := "KWP_Buffer".RX_Response[6];
    "KWP_Buffer".State := 9;
  END_IF;
END_IF;

7.4 TesterPresent Watchdog

KWP2000 sessions time out if no TesterPresent is received within P3. Schedule FC 102 in OB 35 (100 ms cyclic interrupt) to issue 0x3E every 2 s:

// FC 102: TesterPresent
FC100(iTarget := B#16#33, iSource := B#16#F1,
      iSID := B#16#3E, iP1 := B#16#00, iParamCount := 1);
IF "KWP_Buffer".LastSessionMS > T#2s THEN
  CALL FB 3, FB3_DB;       // transmit
  "KWP_Buffer".LastSessionMS := T#0s;
END_IF;

8. Diagnostic Session and Security Access Sequence

A complete ABS valve-actuation sequence follows this order. The S7-300 program must enforce it strictly; reordering causes NRC 0x24 (request sequence error).

1. 0x10 0x89 — StartDiagnosticSession, extended session
2. 0x3E 0x00 — TesterPresent (warm-up, optional)
3. 0x11 0x01 — ECUReset, hard reset (ensures clean state)
4. 0x10 0x89 — Re-enter extended session (reset clears it)
5. 0x27 0x01 — SecurityAccess, requestSeed
6. 0x27 0x02 [key] — SecurityAccess, sendKey (vendor algorithm)
7. 0x31 0x01 0xFF 0x01 — RoutineControl, startRoutine for ABS "release valves to default"
8. 0x31 0x01 0x01 0x02 — RoutineControl, startRoutine for "actuate FL inlet valve"
9. 0x31 0x01 0x01 0x03 — RoutineControl, startRoutine for "actuate FL outlet valve"
10. 0x31 0x02 0x01 0x02 — RoutineControl, stopRoutine for FL inlet
11. 0x31 0x02 0x01 0x03 — RoutineControl, stopRoutine for FL outlet
12. 0x14 0xFF 0xFF 0xFF — ClearDiagnosticInformation (all)
13. 0x19 0x02 — ReadDTCInformation, list by status mask

9. Verification Procedure

After installation, run the following validation steps before connecting a real ABS hydraulic unit. A failed step is a hard stop — do not proceed to the next.

1. Loopback test: Short K-Line to L-Line (or to ground through a 510 Ω resistor) and verify the gateway reports the line toggling. Confirm with an oscilloscope: 0 V low, ~12 V high, rise time < 9.4 µs.
2. ECU power-up handshake: Power the ECU only, then trigger a 5-baud or 25 ms fast init from the S7-300. Verify the ECU replies with 0x55 0x8F 0xFF (or vendor variant) within 50 ms of init release.
3. StartDiagnosticSession positive response: Confirm reception of 0x50 0x89 0xP3hi 0xP3lo at 10400 baud on a logic analyzer. The P3 timing must be ≥ 25 ms and ≤ 100 ms for ABS actuators.
4. SecurityAccess seed/key: Issue 0x27 0x01 and confirm a non-zero seed (typically 4 bytes). Compute the key using the algorithm in the OEM specification, send 0x27 0x02 with the key, and confirm positive response 0x67 0x02. NRC 0x35 indicates an algorithm mismatch.
5. RoutineControl valve test: With brake pressure at 0 bar, send 0x31 0x01 with the FL inlet routine. Listen for the audible click of the solenoid; use a pressure transducer on the FL outlet to confirm pressure decay. Then send 0x31 0x02 to stop the routine; pressure should stabilize.
6. Negative response coverage: Force a known failure (e.g., disconnect the wheel-speed sensor). Re-run the test; the S7-300 program must display the captured NRC and abort cleanly.

10. Troubleshooting Matrix

11. Performance and Timing Notes

A single KWP2000 request at 10400 baud (10 bit/byte, 1 start + 8 data + 1 stop) takes roughly 1 ms per byte on the wire. A typical StartDiagnosticSession request is 6 bytes (~6 ms transmit), and the positive response is 9 bytes (~9 ms receive), plus 25 ms P3 = ~40 ms total per round-trip. The full valve-actuation sequence (13 requests) therefore completes in under 600 ms on the wire; add 100–200 ms for STEP 7 cycle and CP processing gives a < 1 s test cycle. A production brake test bench at 30 s/test cycle has headroom for parallelized gateway pooling if multiple ECUs are tested in one fixture.

12. Safety Considerations

13. Frequently Asked Questions