The low bus speed is not the only constraint. The KBUS limits also how quick one can switch from one device to another, as well as the minimum time between each request to the same device. Further, the real life shows that there is a response time attached to a request. E.g. the response time (the time from the request is transmitted until the device start to respond) for an MSS54 request is typically ~100ms, while it for the MK60 is ~25ms. Taking into account the time to transmit the request, the response time, the time to receive the data and finally the time before a new request can be transmitted, adds up to relatively high numbers. Requesting the IAT, EGT etc from the MSS54 takes ~150ms, and worse, requesting the Lambda Integrators takes ~260ms doing it the standard way. Requesting data from the MK60 takes ~130ms and from the LCM ~190ms. Put into perspective, the MK60 transmits its data onto the CAN bus each 7ms.

Based on these facts, effort have been made to make an adaptiv algorithm for how to extract data from the KBUS in order to get a as high data throughput as possible. E.g. when braking, the bandwith of the KBUS is prioritized to the MK60 (needed when not reading the brake pressures directly from the pressure sensors), and the extract of temperature data from the MSS54 and the data from the LCM is relaxed a bit. Further, the Lambda Integrators are read directly from its RAM address, reducing the request time from ~260ms to ~120ms.

Communicating over the KBUS does also have some other challenges in that there are no access control. The MK60 follows the KWP2000 protocol and have well defined to/from identifiers, but the MSS54 and the LCM does not. Hence, to automatically detect if an external tester is attached to the OBDII port is almost impossible. Due to that fact, a tool function to manually stop the KBUS communication is added. A custom CAN message is sent from the HMI controller to the KBUS2CAN hardware to signal start/stop KBUS communication...