I've put a Nissan Leaf on a bench before and run it just like you did and would never do it again.
This approach is so much harder than it seems.
"once everything works then it'll be straightforward to remove what's left and dramatically reduce the rats nest qualities of this setup"
We thought the same initially, it turns out the system depends on many more components than you would think.
I imagined the EV system to be like an onion where you can take layers off, not so!It is much more like an egg, once you smash it, you have a few shards that you can re-use but you end up with a mess due to high connectivity between systems. (Leaf refused to turn on without original power steering and wipers connected).
Surprisingly what is more straightforward is putting together your own drivetrain with something like https://openinverter.org and building it back up from first principles. Or you isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach. Both of these are open source projects.
Appreciate the heads-up from someone who has been there before! Like you I was a bit surprised by how much the integration bled across subsystems. I like the egg analogy.
> isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach
For sure, great tips. This is what I've been working towards - at the time of that post I was spoofing the minimum number of CAN messages (still quite a lot), but in the months since I've been gradually replacing modules with spoofed signals by reversing them one at a time. Some of the follow-up blog posts have details about this.
I'm approaching the point of only needing the original motor stack (inverter, charger, etc), the original BMS, and all other modules spoofed out via CAN messages and a few discrete wired signals. The OEM BMS might turn out to be too hard to re-integrate once the battery pack gets split apart, but can cross that bridge when I come to it.
More blog posts (and open hardware & software) to come, I hope!
There is a linked update (this one is months old) about how much wiring he's been able to remove, and how few modules he has left on the bench. Looks like different OEMs have taken different routes regarding how interconnected everything is - fortunately for OP, it looks like Hyundai is less of an interconnected mess
Sounds like the early* days of software engineering, where everything was a big bowl of spaghetti you would never untangle again, compared to modular applications that you have nowadays.
*rumor has it, that most of the software out there is still written like that.
In software engineering, we only ever maintain processes, not artifacts. Software modularity when it exists is usually extremely coarse and rigid when compared to the malleability of electro-mechanical systems.
Got a bug to fix or a feature to implement on a program? Modify the source code, run the build system, use the newly built artifact and discard the old one. Lose this process and you're screwed because the tooling for modifying an extant program is still in the Dark Ages. It's not just about proprietary software that has reached its end of support, given enough time almost any source code tree will bitrot past the point where rebuilding it will require a major overhaul.
When you need to fix or customize a physical artifact like a coffee machine, you usually don't go inside the factory to change the blueprints and manufacture a new one. You just modify the one you have with standardized tools. It also doesn't matter how old the artifact is, even if it's decades out of production it can still usually be disassembled and put back together as if it was fresh out of the assembly line.
The more software bleeds into electro-mechanical systems, the less repairable, versatile and hackable they become.
Since Visual Studio is Windows only, the straightforward solution that I used was to install an old version in a Hyper-V virtual machine.
Then it's a multi-step process where the project is upgraded inside the VM with an ancient VS copy as "far as it'll go", then copied out to the external environment with VS 2022 that also has the 2016 and 2019 "Build Tools" installed. Then the projects can be upgraded to "current day".
In some cases I just gave up and created new empty projects with identical names and GUIDs, then copy-pasted the code files across. It can be simpler and faster.
> Sounds like the early days of software engineering
Sounds much more like they are trying to work with a production system without the source code, the debugers, the compilers, the datasheets, and the documentation.
Plus many of the things they want go directly against the wishes and good judgement of the engineers who made the system. They want to start the car without the steering component. I bet that someone at the manufacturer spent extra energy that you can’t do that. Why? Because under production circumstances if the steering components are not answering that means that something is terribly wrong with the car and it would be dangerous to turn on and accelerate.
Same with the keyless entry component. I bet that there were at least an effort done to make circumventing that hard.
I thought early code was carefully validated on paper with flowcharts and review by someone else before you were allowed anywhere near an expensive CPU cycle.
History doesn't repeat, it rhymes; and it kind of goes in phases or epochs. As Derrida was wont to point out, we show up in the middle of things, just flippantly speaking a language and carrying on as though the language was something we were born with and it's been the same forever because we only know our own "forever".
I popped my cherry on VAX silicon, where stack frames were baked into the silicon. This meant that regardless of language, the stack architecture was a target for the compiler not something it constructed. I fell into the middle of things: VAX silicon was new, and people wrote in e.g. COBOL, FORTRAN, BASIC, Pascal, C because they'd successfully done so before and had libraries and practices which had stood the test of time and had made the jump to successfully infect a new species of silicon.
The successful colonizer libraries and practices had certain rules. "You can't manage heap in BASIC" for example, or that modular compilation units all had to be written in the same language. This is not and never was strictly true, and the people writing code knew it; but it was true enough for code which jumped silicon.
I on the other hand knew about the silicon stack, and could implicitly understand some of the more esoteric compiler pragmas for dealing with that stack (intended for cross-language linking support) and so by disabling certain linker checks and abusing compiler pragmas I could do e.g. memory management in BASIC by isolating the compilation unit where "memory is an array" from the one where "a memory address is an integer" and explicitly telling different lies with compiler pragmas in each.
Fast forward a few years and everybody had learned HTML and then I'm confronted with somebody wanting me to fix a steaming basket of soup machine gun sprayed into different files all with "(c) Macromedia" in them. "Where's your no-code tool which generated this?" I innocently ask. "Wuuut?" is the response. Yea well when you find it, let me know. Let's just say the people who have to fix things like that probably get paid good money and the solves they come up with are comparatively fragile, that code will not (and did not) survive; any more than my silicon-aware hacks (which I was paid quite well for) for VAX will work on modern silicon. Where's all of that shitty VB Wizard code spew? Thankfully gone.
Some of these integrations will not be fixable, but some of the subsystems will survive, and it might be simply because there is no security and it's possible to replay CANbus reliably as a result.
This approach is so much harder than it seems. "once everything works then it'll be straightforward to remove what's left and dramatically reduce the rats nest qualities of this setup" We thought the same initially, it turns out the system depends on many more components than you would think.
I imagined the EV system to be like an onion where you can take layers off, not so!It is much more like an egg, once you smash it, you have a few shards that you can re-use but you end up with a mess due to high connectivity between systems. (Leaf refused to turn on without original power steering and wipers connected).
Surprisingly what is more straightforward is putting together your own drivetrain with something like https://openinverter.org and building it back up from first principles. Or you isolate the inverter and motor and make them believe they are still in the original vehicle by replaying CAN messages, ZombieVerter is a project with that approach. Both of these are open source projects.
Happy tinkering!