(Posting this one a while after it happened, due to holidays.)

This instalment is about the "Bench Kona" I've built in the shed. Behold its questionable integrity:

You can see the motor and drive unit stack in the foreground, and the battery pack in the background under some junk. These are all the same part assemblies that came out of the crashed Kona, with their original wiring. All of the high voltage connections are exactly the same as in the car, including interlocks and seals.

The bench holds other modules taken from the engine bay and the interior of the car, plus large segments of the original wiring (now unwrapped, cut, spliced, and converted into a tangled mess).

The green wooden bench was "obtainium" that my mate Oli donated. It's far from perfect, but it has the very attractive property that we can cut it, screw into it, and generally mess with it as much as we want.

Why would you do this?

Like every modern car, the Hyundai Kona Electric is absurdly complicated. More than five separate CAN buses, ten or more kilograms of low voltage wiring, probably over one hundred electronic modules (most with their own CPU and firmware), etc.

In order to re-purpose the Kona's powertrain into an EV conversion, we need to find the simplest subset of modules that can work together.

Hence, a reverse engineering experiment: the Bench Kona.

Plan

The rough plan has been:

1. Wire together modules on the bench until the motor turns, and the traction battery can be charged.
2. Progressively remove modules, replacing them with fake CAN messages or other signals. The goal is to find the minimum that will still work.
3. Document this, and design some kind of "Kona meta-VCU" that allows the Kona's VCU (Vehicle Control Unit) to drive the motor in an EV conversion.
4. Celebrate wildly, should this step ever be reached.

It's important to note that absolutely none of the techniques used to wire up the Bench Kona translate over to a real moving vehicle. This is strictly for reverse engineering purposes.

Looming

I was able to drape most of the engine bay wiring loom and some of the cabin loom over the bench. The strategy was to find particular wires in the inter-loom connectors and cut them out when needed. Hopefully, once everything works then it'll be straightforward to remove what's left and dramatically reduce the rats nest qualities of this setup:

A special mention for these lever-action wire connectors:

They're very easy to connect and disconnect, and so far they've been reliable.¹ These ones are from Taobao, but looks like they're also on Aliexpress.

Elsewhere crimp ferrules and screw terminals were used, instead. The label maker came in particularly handy!

Gateway Antics

Hoping that the Kona had been engineered in a modular fashion, I was counting on finding some integration points that could be "sliced" apart without too much impact. This turned out to be partly true, although the Law of Leaky Abstractions seems to also apply to cars.

The first module to eliminate was the Integrated Gateway and Power Module (IGPM):

You may remember this module from Part One, when one of its connectors was accidentally damaged by forward probing...

Bench Kona has to to replicate at least two functions of the IGPM:

1. Switching power to some modules, especially "IG3" which seems to be the power when the car is "half turned on" (for example, when charging).
2. Injecting some of the CAN messages that the IGPM forwards between the different buses.

Switching power turned out to be pretty straightforward. Bench Kona has kept the original engine bay relay box for now. It still provides the main relays, large fuses, and the heavy-duty wiring for the DC/DC Converter and the 12V battery:

A lot of power supply wiring comes out of this box, goes into the IGPM where it's split up into different power domains and individually fused. Then some of these individual power wires come back through the engine bay fuse box. To replace individual IGPM circuits and fuses, Bench Kona has a simple automotive fuse box:

The "IG3" power supply that's normally switched inside the IGPM by firmware has been replaced by... a switch!

Brakes

I also wanted to leave out the "Integrated Electronic Brake" (IEB) module, if possible. This electric brake booster module incorporates ABS and traction control. This means it relies on input from wheel sensors, among other things.

From CAN log analysis it seemed likely that we could spoof the messages from this module, instead.

The Kona also has a redundant hard-wired brake signal, which connects the brake pedal to both the Vehicle Control Unit (VCU, part of the EPCU) and the Smart Key Module (SKM, for "press brake before starting"). The VCU also independently reads the inverse of this signal on a second wire.

Initially a simple switch was used for this, but it turned out to be easier to mount the brake pedal itself, at least for the first version:

Removing the return spring and mounting it like this means it can be pushed back and forward like a lever. Odd, but functional!

The laptop would run a bench_kona.py program that injected the spoofed IEB CAN messages to the bus, with payloads corresponding to the vehicle sitting still with someone's foot on the brake. This seemed safe enough to me at the time.

Narrator: As we shall see, this was not quite safe enough.

Smart Key Module

The Smart Key Module was shaping up to be the trickiest module. It contains a lot of logic around the various keyless entry features and door locks, and switches on the main ignition "IG1" and "IG2" power relays. The Bench Kona only needs a few of these functions, so maybe the SKM could be replaced with some switches for now?

Unfortunately, the SKM also has three hard-wired connections to the VCU:

• "P_STS PWM", not sure what this is.
• "EV Ready Backup" signal.
• "IMMO Signal", assumed to be the vehicle immobiliser signal.

Until/unless these can be spoofed, the Smart Key Module needs to behave as if it is operating normally in a real Kona. This means wiring in all of its various power connections, relay outputs, the car's "push to start" power button, and even some of the antennas:

Plus the bench_kona.py program had to be augmented to send some spoofed BCAN (Body CAN bus) messages to the Smart Key Module's BCAN transceiver, so it thinks that the doors are closed, etc.

And... nothing happens!

After triple checking all my custom wiring, it was time to attach the 12V Battery and manully switch on "IG3" to start powering up. Various CAN messages appeared on the bus, a few relays clicked in, and... nothing else happend.

The power button, attached directly to the Smart Key module, mostly sat silent but occasionally flashed through five mysterious amber blinks:

Attempting to pull diagnostic codes from any of the vehicle components failed, presumably because the "car" was powered off. This left me back at the same awkward spot as last year with the BMW gear selector - a complex electronic system sitting there silent and inscrutable.

RTFM

After trying a lot of things that didn't work, I was reading Hyundai forums online discussing various "won't power on" issues and someone mentioned there was a failsafe "limp home" start method where you press the vehicle key into the power on button. Sure enough, it's right there in the Kona user manual:

Pressing the key against the button, it would now replicate the "five amber blinks" sequence every time. Still, nothing else came to life...

Steering Wheel Lock

Going back to first principles, I started probing all of the inputs and outputs of the Smart Key Module to see if it did anything in particular when the button was pressed. It looks as if it very briefly tried to power up the Steering Wheel Lock module.

This module hadn't been wired in, on the assumption that the Smart Key Module would not consider it a fatal error if it was totally missing.

Turns out the steering wheel (complete with blown airbag) barely fits inside the bench:

After wiring the steering wheel lock's data and power lines³, the car finally powered on:

Such a glorious blue light! 🥳

I heard the tell-tale clunks of the main contactors closing in the traction battery pack, and the Bench Kona even went into Drive. However, the wheels wouldn't turn even with the brake pedal "released".

The bench_kona.py program was spoofing CAN messages saying that someone was standing on the brake. Guessing that's why the motor doesn't turn...

Motion

Next step, update the bench_kona software and add an input to turn the brake on and off. A very sophisticated user interface:

This is a bit clunky as there's a separate hard-wired brake pedal signal as well, but by this point the excitement of a possible breakthrough was making me impatient:

Success? This is the motor in Drive steadily trying to "creep" forward,² and also revving up once or twice due to a gentle accelerator press.

Too much motion

So far the Bench Kona has been put into Drive three times. I only filmed one of the tests, but the other two ended with uncontrolled motor acceleration! 😱😱😱

Seemingly nothing would stop the motor - even switching to Neutral, putting the brake on (via both switch and CAN), or totally stopping all spoofed CAN messages. After twenty or seconds of the motor spinning flat out, the motor controller flagged a "Motor Excess Current" fault code and it came to a stop.

This was both unexpected and terrifying, and I realised how unprepared I'd been for this eventuality.

I think what was happening is that the Vehicle Control Unit is running a control loop that outputs a motor torque request and reads wheel speed data as feedback. Because the bench_kona.py program was reporting fake 0 wheel speeds all round, the VCU's control loop assumed the torque it was requesting from the motor was either too low (when accelerating) or just fine (when not accelerating). So the controller only ever increased the torque request, or kept it at the same level. Even when I simulated pressing the brake it was like "Nothing needs to change, we're not even moving!"

Meanwhile, the electric motor controller (MCU) is receiving the torque requests and frantically trying to achieve the requested motor torque by revving the unloaded motor faster and faster. This is an impossible task as the motor is spinning unloaded, so torque is minimal.

This theory is a bit surprising, because you'd think the VCU would have some failsafe where it also reads RPM from the motor controller (after all, what happens if a driveshaft breaks and the wheels aren't turning on the real car?) It's pure guesswork at this stage, maybe the real logic is very different.

That said, the internet does contain some supporting material. For example, there is a Hyundai patent about motor control that includes this signal diagram:

(APS = Accelerator Position Sensor, BPS = Brake Position Sensor.)

If zero wheel speed is the culprit, then all that's needed for appropriate motor control is to send spoofed wheel speed data that matches the current motor rpm. I think we know where the motor rpm signal is found out in the CAN messages, but I want to do more logging on a real Kona to be 100% sure. I don't ever want to trigger that uncontrolled acceleration state again!

Not to mention that the Bench Kona now needs a few more features added, such as a rudimentary cooling system. It's also past time to write some microcontroller firmware, rather than little desktop Python programs.

After all this, it's also possible that the VCU's black box control logic turns out to be too complicated to adapt into a reliable EV conversion. In that case, adapting something like the openinverter motor control board to the Kona's existing IGBT drivers may be the best way to give these parts a second life. We'll see...

Stay tuned for the next update, hopefully soon!